I’m really stuck for a couple of days in something with Capella and I would be grateful if you can provide support or recommend me something to read regarding the topic of “Model Instances REC/RPLs”… because I also didn’t find anything in the references that help me with my problem.
Just to give you a hint about the context, if I have a certain set of data for e.g. “Inf DATA” and there are many subsystems using these sets/components.
My issue now that in the physical layer as you know, when you see from the subsystem’s perspective you could have several components which might be used by several subsystems–>REC/RPL
The drop appeared that for this only one such as this “Inf” I have 3 RPLs, and if I continued in that way with the idea of having many many subsystems, the model will be loaded with a huge number of elements and it would end up in a mess!
So if you just know another way that you can share with me, that do the job more efficiently without loading the model with tens of elements, I would be really thankful.
I am sorry but I have trouble understanding your use case. Maybe it could help if you provided a precise, illutsrated example? It is not clear to me what is data, what is component and what is subsystem in your context.
okey, sorry for the inconvenience, I will try to use other words to clarify the issue.
In the project at the physical layer there are many physical functions such as “Maintain X Data” that need to be allocated to all the subsystems we have… So in order to realize that rather than creating every time a new “Maintains…” , REC/RPLs is one way to deal with this issue. But they eat up a lot of model space and it will end up with huge number of model elements, so that I’m looking for some other ways in Capella to actually create instantiate such functions. So I guess that there’s another way of doing the same job that I heard of, maybe by creating another separate project for it or something.
I hope that I explained it this time a bit clearer, so that you can help me figure this out!
If I understand your case, the “Maintain X data” function is provided by a lot of different components. So it seems right to define a REC fo this function in order be able to instanctiate it several times with RPL and to update the RPLs from the REC if necessary. But I don’t understand why “they eat up a lot of model space and it will end up with huge number of model elements” is an issue? I guess if the REC of “Maintain X data” function references a lot of elements (I guess it’s just one function with all these function ports and maybe the exchange items allocated to the function ports) is because it is necessary to describe this function and it is wanted to retrieve all these model elements in the different RPLs?
Maybe that wouldn’t be an issue if it was small project and small number of functions… But if it’s in tens and might be in hundreds because it’s a big project… Then i think that there’s another way in Capella for dealing with this… It’s not one function of course… Otherwise I wouldn’t ask at all!
And moreover, as you said “it’s necessary to describe this function…”
It would not reduce the number of RPLs, it would eliminate the need of creating RPLs. The idea is that instead of creating 4 RPLs and allocate them to PC1 to 4 below:
You would create a specification pattern in a dedicated view:
It all depends on what you want to capture with your model, and on which kind of analysis you want to perform ultimately. Pretty often, it is not necessary to model all instances of elements, but only the distinctive ones.
Therefore, the first question is not really how do you multiply the number of function instances, but why to you need to model all these (instances of) components in the first place?
If the number of components is “manageable”, then the number of functions will be too. This is called representing your architecture in “extension”. Don’t worry about the size of the model.
If the number of components is not manageable (you have tens or hundreds of them), then you need to think in terms of “representative instances” or “patterns”. It is called representing you architecture “in comprehension”. This is where you will make use of concepts like constraints, roles, cardinalities, to indicate how your model/diagrams are to be interpreted.
Thanks @SBonnet for illustrating the concept beyond it , and I think now I’m thinking in the way of representative instances more, but I just was losing the right recipe.
Hi Juan, thanks a lot for providing me this alternative and I tried it out, but I faced a problem, how could i represent the exchanges between functions, I mean which is exchanging with other subsystems?
Hi. Not sure I understand the question well. If you want to show the Exchange Items allocated to the Functional Exchanges, there is a filter doing that.
, and I think now I’m thinking in the way of representative instances more, but I just was losing the right recipe.