Modeling volume interfaces

[JNavas]

Dear all,
When following Arcadia/Capella to architect mechanical systems (e.g. a pump), we are commonly confronted to the fact that such systems are in interface with the place in which they will be operating (e.g. the pump room) and hence they “consume” volume from this place.
At identifying external entities in SA or LA stages in Arcadia, we identify the “Room” stakeholder (as well as other such as logistics teams that transport the pump to the site) and want to express the “interfaces” between the pump and the room. However we are not sure about:

• Whether or not Component Exchanges are suitable for representing this interface
• If so, what is exchanged ? volume ? It is not really a flow…
• if not, which is the proper way to represent these “interfaces”
  We think that these aspects may be better represented by Non Functional Requirements. But in that case, to which Arcadia object should they be allocated and how to represent them in diagrams such as LAB or SAB?
  Thank you in advance for your comments.

[JVoirin]

Hello Juan,
I agree with you that component exchanges are not adapted to express the volume occupied by a component or a device inside a room. It rather looks like a feature, a characteristic of the device, that has to be confronted to the available amount of this characteristic or feature. Similar to weight for example.
I would not consider the room as an actor either, because there is no evidence of interaction with the system in terms of functional behaviour (there can hardly be a function that needs the volume as an input or delivers the volume as an output, here, right?).
So at SA level it could just be kept as requirements;
at architecture level (LA or PA), it could be an attribute of a logical component and then of a physical implementation component (node); to keep it simple, you could consider defining a component propertyValue with its actual value, and you could associate a constraint to the component, to express the maximum acceptable volume as imposed by the room.
Later on, you could consider having more complex representations by using a dedicated viewpoint (with specific component attributes, representations, gauges, computing formulas and emphasising compliance with constraint on diagrams…) but for the moment it might be enough for you, I guess.
Regards,
Jean-Luc

[JNavas]

Dear Jean-Luc,
Thank you for your answer.
So, if I understand well, you advice to rather use requirements, constraints and PropertyValues to include this information in the architecture model. And then use viewpoints to perform analysis tasks (i.e. calculating the volume consumption).
Regarding consider the room as an actor, I agree with you that there is no functional interaction between them. However, if we consider the pump during its whole lifecycle, and in particular by considering it during installation phase, it is clear that the room is a stakeholder of the pump: is it is too big or it has a given geometry it may not be able to enter into the room. Due to this fact, I would consider including it as an external entity of the system. What is your opinion ?
Best regards,
Juan

[JVoirin]

Juan, your question is interesting and opens wider perspectives than just this subject, especially such questions as “which kinds of artefacts are necessary for engineering and architecture design ? Which models contribute and how ? How are artefacts spread among those models ?”
In order to address this volume constraint correctly, you have (as for most engineering concerns):
first to capture related requirements (let us say in Doors)
then to find the appropriate representation(s) - possibly models - that will help you, not only to formalise or document this constraint, but also to design the solution and check it against this constraint
and to relate both to each other.
Arcadia and Capella are approriate for capturing [operational, functional and associated non-functional] need, and define a solution based on component breakdown, functional contents and behaviour allocation, conceptual interface definition, and check of related properties/constraints. This is very well adapted at least to initial, high level architecture analysis, design and sharing. You can usually go up to the detailled synopsis you usually draw. But to go further up to detailled design and realisation, you usually change your representations, adding 3D views, or wiring/routing representations, …
Similarly, for component volume, geometry, form factor… considerations, Arcadia and Capella are probably not appropriate, when compared to a 3D CAD tool. So my vision would be to use them for the former purpose, but to switch to your favorite CAD authoring tool to address geometry issues.
So in Capella model you will have traceability links between requirements and the relevant component (submitted to these constraints), described in terms of functional contents, interface and behaviour;
this component in Capella could be linked (by your own workbench, PLM or so) to the corresponding component in your CAD tool, for navigation/impact analysis purpose;
in the CAD tool, the room will be modelled, and that CAD component as well; the CAD tool will allow taking into account the geometry issues;
Here and only here in CAD tool you will be able to check that your design meets the volume and room requirements; so this is where the romm needs to appear;
the initial requirement should be linked to this CAD component as wellas to the Capella component, or even instead.
Just to summarise: The Arcadia/Capella model will be your “entry portal” and “touring/navigation map” to browse and exploit your engineering data and assets, while mastering complexity. But it is not intended to carry the whole of them.
Don’t try to put all your engineering assets inside the Capella model, but rather focus on what you will be able to check and justify with it - and choose another
complementary tool when and where it is more relevant.