At the System Analysis level we must capture the fact that our system under design must use an ‘imposed’ interface from a ‘given’ external components that provides fuel. We have therefore a functional exchange “Fuel” between two functions “pump fuel” allocated to the external component and “replenish tank” allocated to the system. We also have a component exchange between the external component and the system to which the Fuel functional exchange is allocated : the ports of this component exchange require and provide an interface, and an Exchange Item of 'exchange mechanism ‘flow’ is allocated to this interface. Finally, we also have an ‘imposed’ physical link “Fuel Pipe” between the external components and the system.
Our question is how to define an Exchange Item Element associated with the exchange item “Fuel” given that it is NOT a ‘data’ item (a ‘type’ or ‘class’), but a physical/material thing. Is there a way to model this EIE without abusing the class/class diagram semantics?
Thanks a lot!
Hi,
Why do you think it is an abuse to create a ‘class’?
Classes are not only for data in my understanding, but a way to classify things.
In one of Voirin’s book, there is an example of a PressurizedFluid exchange item associated with two classes: one called ‘HydraulicFluid’ describing the kind of fluid (viscosity, etc), and one called ‘FluidState’ describing current pressure and temperature.
1 Like
Thank you for your reply, Loic.
You are right of course in that a class diagram is a model of anything, and therefore it can also model Fuel. But capella clearly ‘thinks’ of it as data structure, which would be the obvious thing to do if I am designing some kind of interface for control software, for example. But suppose I want to generate specifications for the physical interface (a physical link which is a pipe connected at certain physical ports that carries the physical exchange of physical fuel, what would be a ‘best practice’ approach? (note that I am non ‘complaining’ about capella: I am certain that people do this all the time with ‘vanilla’ capella). For example I could use contraints, additional properties or property groups and/or combinations of these to describe these specifications, not using an EIE at all. Could you please refer me to some ‘best practice’ for something like this, or just share your thoughts?
Thank you a lot!
Hi.
This confusion is understandable, as the names of some concepts in Capella, and particulairly those used to fine-grain define the exchanges between functions and components, come from languages that were already used by engineers (e.g. UML) and that were oriented to data modelling as they were mostly used on software-intensive systems development.
But I can confirm that for more general complex systems, this language artefacts are used to define Exchange Items Elements, considering Class structures as classifiers as @loic.f stated. What is specific to Arcadia is the “Matryoshka doll” principle of allocating Exchange Items to Functional Exchanges, which are allocated to Component Exchanges, which are allocated to Physical Links or Physical Paths. Each of those having a meaning and usage (functional, behavioral/conceptual, physical).
Interfaces are fully specified once these allocations are done. But the workflow can also start from the definition of the interfaces and their Exchange Items.
There is a chapter in Capella help devoted to Interfaces, I suggest to take a look at it.
PS: what is “vanilla” Capella? 
Thank you both very much for your kind suggestions!
(By ‘vanilla’’ capella I meant plain, out-of-the-box, no special add-ons or configuration Capella 
)
On my side, I usually use the property value to describe some physical properties of a connector or a pipe when the model is simple.
I planned to use the PVMT Add-Ons for a more structured and consistent way of describing those aspects (especially across models).
Now, on the actual properties to use I would tend to stick to existing meta-models (or ontologies). I mean when applicable I would reuse meta-models from UML/Marte or SysPhs for instance.
SysPhs comes with examples of pipe connection but I haven’t tried yet to map this in Capella.
I would like to see more PVMT model shared publicly so that new Add-Ons could be developed and reuse those values. 
I have in my models fuel exchanges, air and coolant, or lubricant… Then EI refers to class where properties are pressure, temperature, mass, nature, and when the property is itself complex, then it refers to a class (primary set then), when the property is simple, it refers to physical quantity.
I still have some points:
1-physical quantity do not refer to dimension nor nature, I miss it and run complicated excel spreadsheets to check it.
2-physical quantity instead uses units: the difference is the multiplier. Dimension may be linked to base unit. To complete my vision I would mention numerical: numerical should describe 1D digital measure or request for a physical quantity when needed. Then it should refer to a multiplied unit (femto to Exa) because in calculation routine you have to decide which multiplier to use. When the dimension is a ratio, then the base unit is 1, float, when it’s natural count 1, integer. In Capella numerical do not use unit… but physical quantity may have numerical literals…, and numerical literals mays have units…
This leads me to suggest to make some changes for next version.
Edit: I have looked several time for more links between “data” and “property values”, that may describe in my mind parameters or variant attribute values… which may be used in “data” processing by functions.
Thanks for your patience.