I have recently learned by mistake that physical node components can be “owned” by another physical node component but not necessarily be a sub-component of the parent.
I was curious to know when and why this concept would be used in Arcadia?
My other question is how do i remove a physical node component from being owned by another?
Thank you.
Hi
Can you explain more? I mean what real situation is it supposed to represent?
About owning removal: I suppose that in a PAB showing the concerned NPCs, if you drag the child out of the parent, it should remove the link (The update is marked up by transitory grey color of concerned domains)
Regards
Thierry
My apologies.
I would like to know more about real situations when PC1 would “own” another PC e.g. PC2, even though PC2 is not part of PC1 component breakdown as shown by the semantic browser?
Why would a modeller do this in Physical Architecture?
Why does the Semantic Browser show these two attributes, ‘Component Breakdown’ and ‘Owned Components’?
Ok then, may I can say my point of view about PC owning others…
The complete work we do with Capella is breaking down the system we want to build in components . We have several trees: functions, behavioral components and node components. System Analysis sets the boundaries, Logical architecture breaks down the logical system in components, and physical architecture breaks down the system in node components. EPBS enable adjusting the subsystems scope, based on node breakdown tree. The main questions there are:
- When physical link are parts, where put them, with which node, or as single part?
- Do I gather several nodes as one supplier contract and then on component?
After this we have now the Product Breakdown Structure. All contents are expected product items.
Then we do product engineering: confirm relation expected component to designed product, including new product, which enables design verification. As a result we have now the “Engineering Bill Of Materials” which is a structured list of required contents of the system to support expectations as on duty. Several of “Configuration Items” may be linked to the same designed product, meaning that his product has several applications. The structure of the EBOM follows usually the variant/option tree (not functional breakdown): it’s a bill, not a breakdown. From this when products are really physical, manufacturing engineering will develop manufacturing operation, sequence and tool. This sets up several bills:
-Manufacturing Bill Of Materials: required material to build one unit, this include material loss and packaging items. The product is as delivered (in its box, the box is include, user’s manual as well)
-Bill Of Processes: The list and valued operation time that need to be done to build one unit.
These two are unit cost driver
Then comes the Bill Of Tools which list all specialized tool necessary to manufacture. It may include standard ones pending on manufacturing situation.
In each structure, the parent owns its children, but only there. NPC, CI, design product and manufactured product are several view of the same item, which is not owned by the same in each view.
1 Like