Non-data Exchange Item Elements in Interfaces

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!

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!


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? :smile:

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 :slight_smile:)

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. :angel:

Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.