I wonder why in the Capella tool, a Component Exchange can be allocated to only one Physical Link.
I’m posting this message in the Arcadia part of the forum because I think it is a restriction due to the ARCADIA method and not the tool (but I may be wrong )
For instance, I design my logical system in LA and have two Logical Components with one exchange between them because in the logical architecture I only express I need to exchange between these components.
When I build my PA, I want to realize this exchange with two physical links. The first one can be created automatically with the Modeling Accelerator or I can create it manually and allocate a CE.
But if the CE is allocated to one PL, it can’t be allocated to the other PL.
So, is it a deliberate choice? and why?
How could I realize one CE with several PL?
Thanks for your answers,
Yes, the restriction rule of accepting only one physical link (PL) to allocate a behavioural component exchange (CE) is a deliberate choice. This is to avoid leaving ambiguities in the model, that would not be acceptable for a trusted architecture definition.
Let us imagine that you allocate one CE to two different PL, PL1 and PL2.
How will it be routed, and which component is in charge of this routing, either via PL1 or PL2 ? This ambiguity needs to be solved in order to fully define architecture.
Different solutions can be considered:
- the source component of CE can be responsible for deciding how to route each exchange item (EI) carried by a CE, by choosing its own path (and explicitely sending each EI to one or the other); in this case, the source component has therefore
two different component ports, one for each path, and
two different CE as well; each CE will be allocated to the single PL for this path. The link of each component port to the apropriate physical port (associated to the relevant PL) will ensure removing any ambiguity.
- or the source component may insert routing information inside the CE EI, and send them through one single port; but in that case,
we lack a routing component somewhere, that will be in charge of decoding the EI routing information, and of sending it to the appropriate PL accordingly; this new component will have two ports and two CE, for the same reason as previously. So you are in the same kind of situation as the former one, now applied to this routing component.
Any other idea of how to solve the ambiguity differently ?
Thank you for this clear answer Jean-Luc.
Unfortunately, I don’t have any better ideas to solve the ambiguity.
I thought about creating an other CE leaving from a different component port; then allocate each CE to a different PL.
But before I wanted to be sure that was a deliberate restriction due to the method.
Yes, your idea seems to be the right one (in my opinion).