Same Component part of Multiple Components

Capella
1

Hello, I’m currently developing Boundary Diagrams in Logical Architecture, and my intention is to have multiple diagrams representing interfaces for systems. Each Boundary Diagram has a main logical component considered the representing the “top” level, and multiple logical components inside this block.

The issue I’m facing is the logical components inside the blocks are part of multiple Boundary Diagrams, but when I re-add the block to the main logical component for each diagram, it gets moved to the corresponding block structure (which is obvious).

I would like to create multiple representations of the same element and be able to see the connections for all of them at the same time. For example: Clicking in a Logical Component it will show all the connections for all diagrams at the same time.

Is REC/RPL a possible solution? How can I click in just one REC and see the connections for all RPL at the same time?

2

Hi Bruno,

Just talked about your question with Stéphane, and some things are not very clear to us in your question.

If I understand well, you would like a way to “group” logical components, where one logical component could be in several groups at the same time, is that correct? Could you provide details, and maybe an illustration of what you’re trying to do, and why?

This sounds like the semantic browser to me. Can you be more precise on why it is not enough?

Martin Le Bourgeois
ObeoSoft Canada

3

Hi Martin, see picture attached. Both diagrams live in the same Project. Let me know if this clarifies.

Boundary Diagram
Boundary Diagram1030×558 115 KB

4

Thanks for clarifying.

Having a Logical Component with two parent components is for sure not possible in Capella, because in Arcadia, Logical Component can only be decomposed in a hierarchy. This fits with the physical reality of systems (where a component can only be contained by one other).

So the question I would ask may be: Will the component (L4 Machine Power Control in this case) actually be duplicated in the system? Then, you can have different solutions:

  • Pick only one parent for your component, and then add some component exchanges with the other components
  • You can also probably use REC-RPL as you mentioned already. This would probably be more suitable if the component is actually duplicated

And also, this a more fundamental question: Why do you need the component to have two different parents (in the sense of how did you get there while modeling)? I don’t know if my point is really clear, but to give you an example: Is it because it contributes to different capabilities of the system? Because in that case, maybe it would be better modeled with functional chains and LABs, or something in that vein. What I mean is that, depending on the exact reason for it, there might be another mechanism in Arcadia and Capella to model what you want, if you take a step back.

But maybe someone with a better knowledge of Arcadia/Capella can provide a more efficient insight.

I hope this helps!

Martin Le Bourgeois
ObeoSoft Canada

5

Hey Martin, thanks for your answer. “Machine Power System” and “Machine Motion System” are separate systems, that I’m representing as Logical Components. I’m using LABs to create these diagrams already. L4 MACHINE CONTROL is a sub-system, that is part of both systems at the same time.

Solution 1 might be good, but it will differ to our diagrams, since I’ll need to move the block to outside of the Logical Component. Using REC-RPL does not feel correct, because it will create a separate component… Using generalized component can be a solution for this?

6

How can the L4 Machine Control sub-system be part of 2 systems at the same time? I mean, physically?

7

It is logically contributing to both, not physically located in both. They are logical relationships

8

So the words “contributing” and “logical relationship” sounds different to me, it sounds more like there is a relationship (and interfaces) between your sub-system and the others rather than it is “part of both systems”. Hierarchy of components in Capella express containment, not collaboration.

Of course, you are better placed than me to make this choice as I don’t know the details here. But it probably comes down to a modelling choice. I am not sure why you want to model a sub-system that contributes to 2 systems as being part of the 2 systems. The sub-system logically contributes to both systems, ok, but logically this system is going to be somewhere, contained by someone, and there be a logical interface between them. From my understanding, this is what would make sense to me from an architectural standpoint.

“Using generalized component can be a solution for this?” → I would generally discourage users to use Capella in that mode, although it is technically possible. But then, from a modelling standpoint, how does that differ than using REC/RPLs? From a semantic standpoint, a generalized component is abstract and the 2 instances of this generalized components will mean that they are not the same component as well. But maybe I am not understanding well what you mean here.

Maybe another idea: you may be in the process of modelling a sub-system (L4 Machine Control) that, in the end, is going to be developed and build in both systems (in the idea that your company is providing/developing both systems, and that you just want to say that both system use the same “L4 Machine Control” sub-system from a logical standpoint, but physically they end up being a duplication of the same sub-system). In that case, for me, REC-RPL are exactly for that: It is a mechanism in Capella to enable reuse of modelling element. You create a REC “L4 Machine Control”. You could even move it in a library as a reusable asset in your organization, and then instantiate when need in all your systems.

(And final comment, please note that in Capella, there is supposed to be one SOI per Capella model. It looks like you are implying that you have multiple systems (SOIs) in your LAB, and that’s ok right, as long as you are aware of why you are doing it, like if you are actually modeling a SOS case).

Stephane

9

Hi Bruno,

just another solution i can propose, because i also encountered this issue. The usage of creating a diagram using “contextual elements” option (under properties tab) is very efficient for this case:

in one diagram you represent the systems (the “parents” only) with their interfaces/exchanges.

in another diagram(s) you specify, per “parent” the list of elements that are in context to it (which removes the need for parent-child thing) which allows you to share elements in two different context diagrams. Then you are not showing all in one diagram, but then you can create diagram links to show the contextual diagram in the parent diagram if its really important.

In my opinion parent/child representation is an old-fashioned way, which mostly have meaning in the physical layer.

Ron

1 Like
10

Hi, I work with Bruno and just joined so I could chime in. This option looks like it may potentially work well.

We are trying to reconcile the automotive (AIAG) format of boundary diagrams, in which the elements inside a boundary are the only contributors to that boundary’s functionality - aka the causes of failure when you get to your FMEAs - with using MBSE. Ultimately, we would like to not have separate boundary diagrams elsewhere, but since those diagrams are strongly focused on cause of failure / contributor to functionality, we’re struggling with the difference between them as Bruno has shown here. Thank you everyone who has made suggestions so far!