Hi,
I am dealing with this issue. I’v got a PC Node hosting a Behavorial component.
In this Behavior PC i have a simple Physical function and 2 Behavior PC. See image below.
I wonder if it makes sense to have a simple Physical Function dealing with Behavior PC or if i should include this function in a new Behaviour Component ?
I have not seen a similar case in the ARCADIA method book.
Could anyone enlighten me as to what is better?
Thank!
Hello,
To me PC01 is no more leaf component and this is why PF10 should not be allocated there. As parent of PC1 and PC2, PC01 shall execute PF11, PF12 and PF13.
PF10 is not allocated by PC1 nor PC2: Then there is another part of PC01 which is not PC1 nor PC2: we can call it PC3 and require it to allocate PF10.
Division of a block: function/component/node shall be a partition: the union of the children=the parent.
Other question (I understand this is an example still) Why FP12 and FP13 are separated, and why define FE2 and FE3?
If you need it, then PC2 should be broken down, and each child get its requirement to convert entries into deliveries (function)
If PC2 has to be leaf, then how define FE2 and 3 contents? This should be owned by PC2 design owner: your supplier?
Regards
Thank you for your review.
If i understand well, you say that a behavior PC can only be composed of leaves or of other behavorial components. The rule you suggest is that only leaf can be allocated.
Could you explain more about the reasons for this rule?
For the part :
If PC2 has to be leaf, then how define FE2 and 3 contents? This should be owned by PC2 design owner: your supplier?
I don’t understand your question.
Thank
At first you have your system as an unique component to which you make requirements including requirements to produce sent items having received other items.
During Logical architecture, for functional reason, (modes, functional diversity) you split your system to detach what vary with each parameter, from what do not vary. You may detach some component to follow necessary technology split. What you do the is a partition: you set a new parting line. One part is on the east side, the other part is on the west side. So in a breakdown, if the east side child exists, the west side one exists as well and should be named.
When a parent allocates a function, this is the complete parent, not the forgotten part not being include in its children. So the requirement to produce items applies to this parent. The situation introduces a blur about: shall the children participate? how?
The other question is : at the end of the process, you will have defined components as configuration items, owning node components playing behavior component roles which shall fulfill functions. Each stakeholder we can call supplier that will have to continue the engineering work has to understand the requirements that hit their part(s).
In the case that the requirements cannot be split between your components, my position is : your system was not dividable in subsystems. You may split the designed product, not the expected product, and then the system. The design of the components have to be done at once. Frequently split between designed component comes from manufacturing issues or optimisation.
About the just split:
The reason to split a function is because all the function cannot be allocated by the same component. Splitting more creates functional exchange inside the component. What you do then is making a requirement to the component to produce items that you don’t see outside: what for? If you don’t have an answer it’s just unnecessary requirement (and driven cost with may be or at least reason for invoice from supplier) If you have an answer, it shoudl be then in the lower layers, you may split your component and make them allocate the leaf functions. Behavior component are not material, just roles. It may happen that a node plays several components which do have mutual exchanges. The exchange requirement shall be made clear that it’s at the subsystem boundary, nowhere else.
Hoping it helps (long text…sorry)
Thierry
