This may be a bit of a naive question, but what purpose is the behaviour component serving in the physical architecture. Attached below is a screenshot from this video explaining physical architecture. Why not have the physical functions directly map to the node physical component ?
Image comes from this video
In theory, blue boxes are behaviour components hosting Functions. Typically they would be software deployed on hardware.
@StephaneLacrampe Why not let that be decided later. Perhaps a System-Subsystem transition is done, and these details are decided in the logical level of the subsystem model. I think I would prefer just allotting the physical functions directly to the node pc and have the downstream engineers decide how to group and classify
I don’t know well enough the reason of this choice, and I see your point. Maybe other with deeper knowledge on Arcadia can answer.
@georgesavio In your image above you have a 1:1 mapping between components and behavioural components. You have named your behavioural components the same as your physical nodes. This isnt the intended usage - because, as you say, they would be redundant.
They are intended to represent behaviour. This could be a few different things;
Software Groupings
For hardware I often take the group of functions that are allocated to the behavioural component and summarise them as a noun verb pair (the opposite of function naming which is verb noun). For example, the behavioural for an oil pump that the function of is filter oil and pump oil might be oil pumping. This oil pump might have other behaviours such as measurement sensing. Note the using of “ing” words in the behaviours.
Abstract concepts. I use them to represent the space between components. For example, using the oil pump example, there is the node PC of pump housing and the node PC of the gears. But what represents the space between the components that the oil flows through; the behavioural component.
In a simple system, there may be a close alignment between behavioural components and node PCs. In a more complex system, with sub-systems there is likely to be more behavioural components per sub-system (represented by node PCs).
So they certainly have their use; however I understand that for a simpler system or at a sub-system level they start to loose their meaning. I do see in the future a version of ARCADIA/Capella where there is no logical level, and functions can be allocated directly onto Node PCs, but with behaviours still an option. For 95% of Capella/ARCADIA users this would probably be sufficient. With the additional semantic depth for the 5%. However, this would be a major carve up/investment in the tool and would need a significant backing by industry to develop.
Hope this helps,
Josh
Thanks for the explanation. Most of the components that are in the system I’m working on are fairly “simple” in terms of functionality. Furthermore they are envisioned to be COTS, so I think there is probably not a lot of value addition in categorizing the behaviours (I could be wrong, I’ll find out as I delve deeper). There are however a few components (mostly electronics boards) which will have a range of expected behaviours, so it could benefit from categorizing behaviour. It might be slightly awkward but the usage of this framework would still work
If you are using COTS components, think of the behavioural components as the constant need, and the node PCs as the actual part numbers that you will pick off the shelf.
There is a distinction between functions, behaviours and physical links. Lets say you are sending some data (a list of names):
The functional exchange is a list of names
The behavioural exchange could be in what form the list is sent; a .txt file, an excel file, hand written, audio transmission, morse code etc.
The physical link is the actual means of tranmission. A USB stick, ethernet, carrier pigeon, VHF signal at 160mhz etc.
Josh
Never heard of Capella models with Physical Links for representing carrier pigeons, but curious to see a webinar on this topic @JoshWedgwood " 
@JoshWedgwood are there any example models that go through behaviour components and ports (in particular making it’s difference from physical links and ports clearer) more extensively. I think a more detailed example will help make it fully click
Thanks for sharing this. I think if there was a concrete example it would make things very clear and finally click
@georgesavio looking back again to your example, your behavioural components do match with the physical nodes, very much the same.
Think, and consider, the Logical Architecture the (LA) as the “How the system should work”, independently of any technology. The LA represents an abstraction layer and refines the System Analysis (SA) starting to define a solution, defining behaviour and breaking down the system.
In your example, Fuse as behavioural node. Considering fuse it is constraining the Physical Architecture - PA to develop, research or procure commercial of-the-shelf (COTS).
What is the expected behaviour for the fuse? Maybe “Device Protection”?
The LA should be fairly stable across a project project, on the other hand, Physical Architecture - PA is dependent on technology readiness (TRL) and prone to changes as the technology evolves or physical elements are changed by others due to trade-off-studies, and potentially the need to identify new functions at PA related only to that technology and not captured at LA.
In the same webpage you can read further the LA and PA:
I hope it helps,
HĂ©lder Castro
I got that, I meant in the article you shared. A single end to end example containing hosting physical components, behaviour components, physical functions, physical links, component exchanges and functional exchanges
I would also recommend the book “Systems Architecture Modeling with the Arcadia Method: A Practical Guide to Capella” by Pascal Roques. It helped me a lot with fundamentals and gives a pretty nice end to end example.
