Does anyone have a recommendation for best practice when trying to capture Fluid Flow or Forces as Functional Exchanges?
The challenge I have is that in these types of Functional Exchanges their flow direction can change depending on the systems state. This means selecting a direction for a functional exchange can be challenging.
Ideally I would like to show if these exchanges are flowing or not flowing and their direction for each given system state.
Hi James,
I am not sure Functionnal Exchanges can be bi-directional. So you may have to create 2 exchanges between your functions.
Then you may you ES diagrams to show which one is flowing depending on your modes/states. Just my 2 cents.
Stephane
1 Like
Hello,
I would suggest to specify Flow characteristics as Flow-type Exchange Items. These can be then allocated to Functional Exchanges in each desired direction (Functional Exchanges are uni-directional).
In order check the consistency of Functional Exchanges and system’s Modes & States, you may want to consider the use of Configurations:
https://www.youtube.com/watch?v=74eKWrSs8hI. This extension may help you to represent in an explicit way which functional model elements (Functions, Functional Exchanges) are available in a given combination of Modes and States.
Hope it helps,
Thank you both for your replies!
For the system I’m working on (a gas turbine) there are a
lot of functional exchanges like this. For this reason I was hoping to avoid having Functional Exchanges going in both directions. I’m worried that doubling all of these flows will quickly make the model unmanageable, the diagrams harder to create (especially when it comes to routing all of the lines) and more difficult to read.
I really like the look of the Configurations add-on. This extension definitely provides exactly the functionality I’m looking for. Since the webinar, in October 2018, I have not seen any more information about it. Does anyone know if the add-on is still being progressed and if it is being made available?
Even if you create a lot of Functional Exchanges, you don’t need to show them all the time: you can use Categories to regroup them, you can only show the Component Exchanges (which allocate Functional Exchanges), or even only Physical Links.
And maybe you don’t need to create a lot of Functional Exchanges neither. If all your exchanges occur simultaneously, you can characterize what is flowing with Exchange Items, allocate several Exchange Items to a single Functional Exchange (meaning everything flows at the same time), hence reducing the number of Functional Exchanges. Of course, whether this makes sense will depend on the system you are designing.
Hope it helps.
Hi,
To me, for continous flows, we have to consider where is the driving function (source) and the driven one (target). Exchange items carried may have negative values when physically the flow inverts. if the cause direction changes, then I would choose as a source the one that is closiest to system control, and as target the second.
It can be forces and torques, speeds, materials heat exchange…
Hoping helping
I would like to share some “problems” with functional directions that I understand.
In first case problems can be solved by adding additional visual notation on diagrams.
But in the second case meta model should be enhanced to add flexibility for functional exchange direction definition.
- Reverse data “flow” in synchronous call
I would like to add another example. It shows “negative” data flow
in direction opposite to functional exchange.
Functional exchange can be used to model synchronous operation calls.
In this case an exchange item with Operation type is added to function exchange.
For this exchange item we can add exchange item elements.
These elements can be of several types: input, output, in/out and return.
In some cases only the return exchange item element is used.
In this case data “flows” in the negative direction of functional exchange.
And it’s also not obvious from notation.
As a result, the direction of functional exchange does not define data flow direction.
It only defines what function initiates this exchange.
Yes it does not change depending on system state (as for flow)
For asynchronous calls modeling additional functional exchange is used to model reverse data ( function results). All the time I have a desire to use additional reverse functional exchanges to model result data for synchronous calls also. It’s easier to interpret in data flow diagrams.
- Additional visual notation to show reverse flows
In scenarios there is a possibility to show the return branch for synchronous calls. It would be great to have additional visual information about reverse data flow on the data flow diagrams also.
On data flow diagrams some visual notation should be used to show reverse data exchange.
It’s possible to create a new viewpoint that will add additional visual notation for data flow diagrams.
Functional exchange information (exchange types, their direction) can be analyzed and
-
it can shows two lines (for flows, synchronous calls)
-
or shows ports without direction information
- Functional exchange direction based on property
There is another problem with functional exchange directions.
On the operation analysis stage one information flow direction can be defined.
When transitioned to system analysis stage functional exchange transitions with the same direction.
But on system analysis stage system implementation decisions can be made and Push\pull method selected. It can result in the need to change functional direction. There is no easy way to do it in Capella now. Capella meta-model does not provide way to change direction/
It would be great to be able to define the direction of functional exchange by it’s property.
In this case it could be possible to use three types: positive, negative and bidirectional.
I think it’s possible not to change the current Capella meta model (source and target attributes in functional exchange element) but to enhance it by adding additional property to functional exchange. After that this property could be used for adding additional visual notations on diagrams. I think that it’s also possible to do on the viewpoint level.