Hi all,
I’m quite new with Capella (though not with systems engineering).
I’m trying to figure out how I can best model common shares scalable resources, and show their relationship with the functions that depend on them.
My main focus is computing resources and storage resources.
I read in this thread (Common resources modelling) an approach that basically identifies the function for the resource and then add exchanges to all functions that use the resource.
Although this was my original idea, someone at work recommended against this, predominantly because the model would become too complex due to the many exchanges. He suggested using sequence diagrams and/or constraints. However, when doing a safety/security analysis, this relationship would not show up easily.
Soo now I’m wondering what is wisdom?
Any suggestions for this?
Maybe some more expert than I am would help here, but bringing my 2 cents…
Probably there is no definite answer to this, as it depends on how you’re going to use your model. If you’re going to use it for Safety/Security Analysis and that it is key that this relationship shows up, then you should model these relations. This may add some complexity to the model, but as suggested in the thread you’re pointing to, you would build dedicated diagrams to manage these relations (Like Computing Resource DataFlow Diagram, or more than one if it is too much in one diagram). And hide them from other diagrams for improved readability. Would that make your model “too complex”? I don’t know, it depends what is meant by “too complex”.
If indeed it makes the model “too complex”, but still you need these functional exchange and links to exist at some point for your Safety Analysis, one could imagine a more sophisticated solution, like you could have your “Computing Resource” function (or component) and list in the description all the functions it is supposed to link to. And then you could have a python script that would automatically add these relations in the model by reading the function description. And another one that removes these relations when you’re done with your analysis. I am just brainstorming ideas here, this may be a bad idea in your context - or not.
Stephane
If you really need to track each and every resource input to each function I would suggest you use a dedicated view to it. E.g.: define a specific view for each component to specify which resource inputs are used by each function.
In this example there are two subsystems LC1 and LC2 who performs functions and interact with each other and uses resources from an external actor (could be internal doesn’t change the example).
Resources view for LC1 (only includes functions and functional exchanges related to resources):
Architectural view excluding resources (includes all architecture features excluding resources):
Obs.: For the resources view you should use the ‘unsynchronize’ feature of the diagram so that functional exchanges unrelated to the resources are not shown in the diagram automatically (e.g. the FEs connecting LogicalFunction 9 and LogicalFunction 10).
Thanks for the suggestions.
For most resources this is an acceptable approach. Although there’s alevel of commodity added as a result, it’s within reasonable visits for most resources.
There’s one exception though: one of the resources is an I/O conversion function. This is easier to model on a parameter basis, as parameters can flow through that function directly. However, with tens of thousands of parameters going through that function, that would make the model immensely bigger and more complex, exponentially more so than for eg computing resources.
The same applies for data transportation services.
I’d imagine there is a different way to deal with functions that affect functional exchanges. Any suggestions on how to deal with that?
Can you add more detail or rephrase the problem with the I/O Conversion function? Capella has Exchange Items that can be allocated to functional exchanges and be reused (like flow specifications, flow properties or interfaces in SysML) to add more flexibility and detail to data flowing through functions. Can you explain in other words the problem?
Hi Guarita,
Thanks for responding.
The system I’m modeling is providing several common shareable resources. One of those is interface resources. In this case the resource function is responsible for converting Ethernet interfaces to, e.g. CAN interface, and the other way around. It only converts from Ethernet to something else, or from something else to Ethernet. It does not convert data between non Ethernet interfaces.
The simplest way to model this, is to include the conversion function in the functional chain in series with the functional exchanges within that chain. However, when you deal with thousands of parameters, that quickly results in thousands of functional exchanges, or at best hundreds of grouped together cleverly. This exponentially complicated the model.
I was thinking of keeping the resource functions separate from the functional chain, as the relationship is indirectly implied in the physical architecture, where the resource functions have their own behavior component located on the physical component node. The physical component node may or may not include behavior components for other functions that use other resource functions (eg computing resources). If the systems use other resources on the same physical component node, then I could create a behavior component exchange, but if IO conversion is the only resource function used, then No exchanges can be created, and for safety and security analyses it may not be obvious (other than by looking at the model) that the system under analysis is using the io conversion function.
I don’t understand the part where you say:
You only need one functional exchange in a function pair (for each needed direction) to be able to represent flow between functions in functional chains. Can you provide a diagram with an example following the idea you had in mind when sending the last reply but with a low number of exchanges, maybe 5, so I can understand the problem?
See if the example below helps somehow, it is just a guess:
I can traverse as many functional chains as I want through the function in the middle and I’ll only use the same functional exchanges. If I need to express specifically which parameters are passed on each functional chain I can use Exchange Items and specify in the Functional Chain Description which items are exchanged at each Functional Exchange involvement (instance). Not a problem.
The only way I see you would be obligated to create numerous Functional Exchanges is if you had a large number of functions using the converter function, then, maybe you’d might have to reconsider if that level of detail is necessary and maybe abstract these functions to a lower number of functions.
