Transition from LA to PA motivation

Arcadia
1

Hi,

With Arcadia approach, there is an option to transition LA to PA.
In PA we care about detailed physical components (specific implementation). This is done with modeling physical nodes. But when I transition from LA to PA, all the logical components become physical behavior components rather than physical nodes. Then what is actually the usage?

Simple example: modeling a sensor as logical component with 2 ports (say 2 power supply ports), obviously it has a physical node representation. However that sensor from LA will transition into sensor behaviour component. Not only I do not need a behaviour component at PA, but also I need to model from scratch the physical node (with its 2 power supplies) manually.

Am I missing something ?

2

The transition LA component is considered a behavior one in the PA (kind of echos the “Logical” aspect of it I suppose), then it is indeed up to you to create the actual PA Node at the PA level, giving information on the actual physical/technical nature of your sensor.
Another example: multiple LA components transitioned from the LA layer may be deployed on one single PA Node component at the PA level depending on the technical choices you make.

3

Also, another remark: remember that automatic transition in Capella are just helpers to initialize things. A transitioned LA component to a behavior PA component will probably need some modification (renaming…), as you always need to askyourself the same question: “I have defined this at the LA layer (=“how the system will work to fulfill the need”), how is it going to be realized at the PA layer (=how the system will be developed and build”)". This is true for all layers transitions in Arcadia. If you’re just using the transitions to keep all elements unchanged from the previous layer, then there is no value in going through all these layers, just do everything at the PA layer. Each model at each layer is a separate model, answering a different question, and relations between layers are not “refinement” but “realization” relationship.

4

Thanks for the response! I understand your answer, still it leaves me with open questions on this approach.

The main question I have is - what is the role of the transitioned component within the physical layer ? Do you see it is actually being used within the physical diagram (even if modified) or it is simply serves for traceability, and at physical layer I anyway create also new behaviour components that are more detailed.

Going back to the sensor example:
I know at logical layer I have a sensor. That sensor is implemented by HW element and small CPU element. Each of these are beahviour components at physical layer, because they need to carry some functions (e.g. “sense” and “process and output”, respectively).
In this case, the transitioned LA component named previuosly “sensor” sits in my physical layer, but I am not using it - i created new ones. Of course I could use it as a wrapper for the HW and SW elements, which would be very forced and unnatural (also this approach may not be relevant if at physical layer it is deployed across multiple nodes).

What is your view on this ?

5

Hi @Ron,

When using Capella’s automatic transitioning function (LA to PA) all the software can do is create the physical functional containers, i.e. the behaviour components as analogues of the LA’s logical components. This may be perfectly acceptable for your design. However, as you’ve discovered in most cases this will be unnatural and not an appropriate design choice. And I would suggest using the transitioning function in your case isn’t that helpful. Rather, it would have been more appropriate to create new structures (behaviour and nodes) – which is, in fact, what you did.

These newly created structures can then be justified by linking them back to you logical component “sensor”. Whether you choose put your new behavioural components into a physical node is your choice as the modeller. But if you did you can again link this to your sensor logical component to demonstrate that the node was created in response to something in your logical architecture, in effect creating a many to one mapping.

6

Thank you for your answer, it is more clear now.

Perhaps one motivation for going with the unnatural approach I mentioned of using the transitioned logical component in PA as a “wrapper” for other newly created behaviour components in PA, is to ensure I am consistent with interfaces that I created in LA.
Otherwise, I may justify the structure as you say, but I will not know if I was consisted with interfaces that i designed during phase of LA modeling.

7

Hi Ron.

I came across your post in my search for answers in other areas and thought that it might be helpful to share some insights on how I (eventually) found the answer to the same struggle I had about modelling at this level a while back. I admit that it might be one of a few ways of approaching the problem, but I feel that this has given me the most insight into understanding the modelling process in general, and not just for Arcadia/Capella.

First, let me acknowledge the importance of @woodske statement about justification for lower-level components (logical or physical) through linking. If you are a System Engineer (SE), you should probably be familiar with the very important concept of Traceability, which is exactly what Linking in the model is supposed to accomplish. Traceability is not only important for System Requirements in documents-based SE but, in MBSE, is of equal importance to created model elements. All model elements at lower levels are therefore (and should be) justified and traceable to higher levels. This way, anyone studying the model can easily navigate through the levels of the model and understand why they exist and, if applicable, trace back to the highest-level need, which, in terms of Arcadia should be OA. So, in your case, whether you decide to create them manually at the PA level, or have them transitioned by the tool, completing the traceability linking is of critical importance. In fact, if you don’t do this, the model validation tool in Capella WILL complain with errors due to this “discontinuity” in traceability created by not linking. The difference is that transitioning them using the tool, automatically takes care of the traceability, whereas if you create them manually, you should also make sure to manually complete the traceability (linking), as @woodske describes above.

Now, to address the core of your question I will use an analogy with how functional analysis in Capella is (supposed to be) accomplished:

If you have struggled with functional modelling enough (whether in Capela or otherwise), you should be familiar with the concept of functional breakdown and allocation between SA and LA levels. For example, you have created a function at the SA level that needs to be broken down to leaf functions at the LA level (i.e. leaf logical functions), before you can allocate them to the different logical components in your logical system structure (i.e. at LA level). The system function (at SA level) therefore becomes a “composite” function at the LA level when transitioned. As a footnote: If the leaf functions end up allocated to various different logical components, you have done it correctly, however, if all leaf functions end up allocated to a single logical component, it means you probably already had the logical component in mind when you created the system function at SA level, which is not ideal because it means that you pre-empted the architectural design at SA level, something you should be avoiding in System Engineering.

Now, if you apply the above logic of functional modelling between the SA and LA levels, to the component modelling between LA and PA levels, you should come to the following realization:
A component at the LA level (i.e. logical component) is like the system function described above. Just as you transitioned the function to the LA level to become a composite function for breakdown into leaf functions and eventual allocation to logical components, you should similarly transition the logical component to the PA level to become a “composite” Behavioral PC, then further break it down into “leaf” Behavioral PCs and deploy (allocate) them onto various Node PCs. Behavioral PC deployment is therefore the equivalent of functional allocation. Moreover, likewise to functional allocation, if you end up with all Behavioral PCs deployed onto a single Node PC, you probably already had the Node PC in mind when creating the logical component, which, again, is not ideal because it usually proves that you already had the physical implementation in mind and consequently pre-empted the physical design, something you want to avoid as a SE.

Your description of using the transitioned Behavioral PC as a “wrapper” for the “leaf” Behavioral PCs is therefore, on the right track. If you follow this approach, it should not only take care of traceability (linking), but also consistency of your interfaces between LA and PA.

The day I realized this analogy between functional and logical/physical component modelling in Arcadia/Capella, it opened up a whole new world of understanding modelling and traceability for me as an SE. I hope it helps you as well.

Regards.
Estian.

2 Likes