Physical Architecture - Normal vs Deploy Physical Components

[dsryzhov.gmail.com_o]

I will try to explain my understanding. Some some simple example will illustrate the difference.
Simple Example of Behaviour PC is a software program.
Example Node PC is a computer hardware.
Behavior PC can be deployed on Node PC. In this example this means that software can be deployed on the hardware.
Another example from mechanical system.
Let’s build model of a house.
There are many systems and components in a house: constructions and engineering systems, user systems, …
There are many rooms and walls that accomodate different behaviour components.
In this case room or wall can be modeled as NodePC. Furniture, engineering systems components, air volumes and so on can be modeled
as behaviour PCs. When you deploy behaviur components to the node pc you say that some components
are situated in the room (Node PC). (room runs this components)
Another example of Node PC is building wall. For building wall can be deployed components from different behaviour systems:
construction components, electrical wires, insulation components, pump tubes and so on.
When you deploy these behaviour components to node pc you say that this node runs this behavor PC.
For Node PC hierarchy of node PCs can be defined.
Computer->Mother board->Processor->Core
Buidling->Building level->Room/Room Zone (->Wall->Wall section)
In Capella you can deplot your behaviour PC on any level of node PC’s hierarchy.
Behaviour PCs constitutes another hierarchy
When you deploy from behavior PC to node pc you map elements of two different hierarchies.
Principal near the same as for function allocations to components (logical components or physical behaviour components )
function -> behavior component -> node
There are three types of exchange types

• functional exchange between functions
• component exchanges between logical/physical behaviour components
• physical exchanges between node pc’s
  Examples of this exchanges
• remote fuction call
• program link between 2 software components
• physical Ethernet cabel conection between 2 computers that
  In Capella you define allocations between this exchange types
  function excgange -> component exchange -> node exchange
  When you make your desing you say
  that
• this functions exchange some information
• this functions exchange information over this component’s exhcnges/interfaces
• this components exchange is realized by this physical media (cabel, air, …)
  one physical can run different behavior components exchanges
  one components exchange can run different fuctional exchanges
  Hope this will help
  Regards,
  Dmitry
  Regards,
  Dmitry

[sergio.feo.gmail.com]

Thank you very much for your answer! I find the house analogy very useful. If I may I would like to follow up with some clarification questions.
So, in this analogy, what would be a “deploy node PC” as opposed to a “node PC”?
Same for the behavior PCs: when you say deploy a behavior PC into a node PC, are you referring to “behavior PCs” or to “deploy behavior PCs”? what would the difference between those two?
Best regards,
Sergio

[dsryzhov.gmail.com_o]

In fact there are only two elements Behavioural PC and Node PC
There are no such elements Deploy Behavioural PC or Deploy Node PC
Deploy Behavioural PC = Create Behavioural PC + Deploy it to Node PC (two action in one)
Deploy Node PC = Create Node PC + Deploy it to another Node PC (two action in one)
It’s a tool to make two action more quickly.
Yes, you can deploy one node pc to another node pc in addition to simple hierarchy betwee node pc’s
I’ve not used this possibility yet and not very well understand now to explain.
I assume that you can have any amount of node pc’s hirarchies and can map their elements by deployment.

[SBonnet]

This is a good summary Dmitry, thanks!
Capella in its current version allows to deploy Nodes in Nodes and Behaviors in Behaviors. This will change in 2017. We came to the conclusion that these possibilities are too confusing.
We are also going to prevent the “on-the-fly” change of the kind of PC. Again, because it leads to inconsistencies where Behavior and Node could be mixed in one given containment hierarchy

[sergio.feo.gmail.com]

Thanks a lot Dmitry and Stephane for your information. I had already noticed the workaround of changing the PC type after creation to bypass the creation restrictions imposed by the editor and was still wondering whether it is a bug or a feature. To recapitulate, the source of my confusion is the four possibilities offered by the editor Node PC, Deploy Node PC, Behavior PC and Deploy Behavior PC.
I hope we agree on the following to conclude this thread:
The grammar that results from the editor is currently (please pardon the abuse of notation)
Root ::== NodePC*.BehaviorPC* NodePC ::== NodePC*.DeployBehaviorPC*.DeployNodePC* BehaviorPC ::== BehaviorPC*.DeployBehaviorPC* DeployNodePC ::== DeployNodePC*.NodePC*.DeployBehaviorPC* DeployBehaviorPC ::== DeployBehaviorPC*.BehaviorPC*
where ‘.’ stands for sequence concatenation and '’ is the Kleene closure operator.
The expected grammar for the 2017 version would then look something like
Root ::== NodePC.BehaviorPC* NodePC ::== NodePC*.DeployBehaviorPC* BehaviorPC ::== BehaviorPC*.DeployBehaviorPC* DeployNodePC ::== DeployBehaviorPC* DeployBehaviorPC ::== DeployBehaviorPC*
The difference between using “Deploy” and “Non-deploy” PCs is the creation of a deploy relation between the container and a PC. The semantics attributed to this relation (from Dmitry’s analogy) is: B is deployed in container A <==> A “runs” B. Where “runs” expresses that the container is the model of the physical platform A that performs or supports the behavior modeled by B. In other words, A is necessary to perform B. B is what we are designing, A is an existing component that enables B.
Any comments or corrections on your part are greatly appreciated.
Cheers,
Sergio

[SBonnet]

Sorry but I don’t feel comfortable with your notation…
Quote:
In other words, A is necessary to perform B. B is what we are designing, A is an existing component that enables B.
This is correct. B could be designed and developed by the same organization, but the current model is not the place where this is done.
For the rest, I cannot simplify more than
There are only two kinds of PC: Node and Behaviour
They should not be mixed in the same containment hierarchy(visible in breakdown diagrams)
The relationship between Nodes and Behavior is a deployment one. If on a PAB the borders of the Behavior appearing on a Node are not rounded, there is a modeling error (this is what the next versions of Capella will prevent)
As Dmitri wrote, there are accelerators in the palette of the PAB, and the “Deploy Behavioural PC” tool actually create a Behavioural PC and then deploys it to Node PC (two action in one)
The “Deploy Node PC” tool of the PAB will be removed in a next version

[sergio.feo.gmail.com]

This is of great help. Thank you very much!
I am very pleased to be able to learn and discuss the ins and outs of Capella in such an efficient manner and with competent interlocutors. I will be more than happy to give back as much as I can.
Cheers,
Sergio