Creating RPLs without load the model with tens/hundereds of elements

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.

1 Like

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!

Thanks a lot in advance.

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…”

Hi. Often when you think you need to replicate a model element a thousand of times, it is smarter to model a “pattern” and add a constraint that says under what conditions the pattern shall be applied. You may want to look Semantics for a function in Capella - Capella - Eclipse Capella Forum (mbse-capella.org) and Multiplicity in Models - Capella - Eclipse Capella Forum (mbse-capella.org).

1 Like

Sorry, I didn’t get how that can reduce the model elements “RPLs” allocated to each subsystem?

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:

image

You would create a specification pattern in a dedicated view:

And use the constraint element to document the specification:

When you look at the constraint in the Semantic Browser, you see the elements that are constrained by it:

Of course, the complete and formal way to do it would be to use REC and RPLs and allocate them. This is only a less formal alternative.

1 Like

I agree with @JNavas.

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.
1 Like

Thanks a lot @JNavas for the clarification, I will try it out. Thanks for giving the time too!

Thanks @SBonnet for illustrating the concept beyond it :slight_smile: , 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.

Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.