Functions in systems model

regis casteran

Published in

seatwork

8 min readSep 9, 2019

About functional decomposition in systems modeling tools

Introduction

Scope

This article deals with functional decomposition performed by a system engineer / architect using modeling tool during the system analysis to define the functional architecture of the system.

It considers a function F1 of a system defined as follows:

F1_out:F1_out type = F1 (F1_in:F1_in type)

That a system engineering / architect would like to decompose into two sub-functions F1.1 and F1.2 defined as follows:

F1.1_out:F1.1_out type = F1.1(F1_in:F1_in type)

F1_out:F1_out type = F1.2(F1.1_out:F1.1_out type)

Modeling tools referenced in this article have been selected based on the experience of the contributors to this article. They are used in their basic configuration with the provided meta-model (SysML or non-SysML) but without any additional plugins nor automation scripts.

If you are interested in adding a new modeling tool experience to this article, please contact me.

SysML version used in this article is the version 1.5 specified in ISO/IEC 19514:2017: “Information technology — Object management group systems modeling language (OMG SysML)”

Disclaimer

This article is not exhaustive: it does not deal with a comparison of all the modeling tools available in the market for systems engineering in terms of features.

This article is not a guidance in modeling functional decomposition: it does not detail the rationale of the different used methodologies.

If you are interested in adding a new methodology to this article, please contact me.

Acknowledgements

Special thanks for their contributions to this article to:

Samuel Boutin for ArKItect inputs
Guillaume Finance for Enterprise Architect [EA] inputs
Philippe Leblanc for Rational Rhapsody Architect [RRA] inputs
Pascal Roques for Capella inputs
Olivier Casse for Cameo Systems Modeler [CSM] inputs

Definitions

Function: transformation of inputs to outputs, by means of some mechanisms, and subject to certain controls, that is identified by a function name. (from IEEE Std 1320.1–1998 (R2004) IEEE Standard for Functional Modeling Language — Syntax and Semantics for IDEF0.2.1.53)

Action: (not atomic) user action resulting in the creation, modification or suppression of an element or a diagram.

Action could be already a process. For example click somewhere to get the menu, then select « add new », then fill in the name « x », then click OK, then put the object at the right place… This article do not consider this level of detail.

Element: (model) element (including link) that is created, modified or deleted by a user action in a diagram.

In this article, we have a function F1, two sub-functions (F1.1 and F1.2) and 3 flows (F1_in, F1.1_out and F1_out). So there will be basically at least 6 elements in the resulting model.

Diagram: (model) view that displays a set of elements and that is created, modified or deleted by a user action.

Synthesis

The following table presents the number of actions, elements and diagrams required to model the decomposition of the function F1:

Required actions, elements and diagrams to model F1 decomposition

The SysML modeling tools present nearly the same numbers of required actions, elements and diagrams to model a function decomposition in their basic configuration, because they are relying on the SysML standard.

The non-SysML modeling tools are more efficient to model a function decomposition regarding the number of required elements (and therefore the number of actions), because they handle the instantiation and inheritance mechanisms between the elements in the meta-model, instead of letting the user to deal with them explicitly.

Functional decomposition in SysML modeling tool

Enterprise Architect

Enterprise Architect [EA] from Sparx Systems is primarily a UML modelling tool for software analysis, design and implementation. It also supports numerous standards such as BPMN and SysML. EA is Windows application completed with a dynamic Web solution, Prolaborate. Specific SysML features have been integrated in EA to cater for the BDD/IBD consistency.

The SysML profile available in EA starting with the unified edition is used to model the decomposition of the function F1 with a block diagram:

Block diagram for the decomposition of the function F1

It requires 21 actions to create 20 new elements and 1 diagram as follows :

Create the block diagram (1 action)
Define F1, F1.1 and F1.2 (3 actions)
Link F1.1 and F1.2 to F1 (2 actions)
Define the interfaces for each block (9 actions for 3 interface blocs, 3 flow properties and 3 value types)
Add ports to each block (6 actions)

Then it requires additional 5 actions to create an internal block diagram and 3 new elements to link the sub-functions F1.1 and F1.2:

Internal block diagram for the decomposition of the function F1

Create the internal block diagram (1 action)
Synchronize the internal block diagram to display the parts F1.1 and F1.2 with their ports (1 action)
Link the F1 ports with “delegate” links to the sub-functions ports (2 actions)
Link the sub-functions ports with a “connector” link (1 action)

Please note that the internal block diagram is automatically synchronized with the related block diagram to display the F1 ports at its creation.

Cameo System Modeler

Cameo System Modeler [CSM] from NoMagic is an industry leading cross-platform collaborative Model-Based Systems Engineering (MBSE) environment, which provides smart, robust, and intuitive tools to define, track, and visualize all aspects of systems in the most standard-compliant SysML models and diagrams

The SysML profile available in CSM is used to model the decomposition of the function F1 with a block diagram:

It requires 21 actions to create 20 new elements and 1 diagram as follows :

Create the block diagram (1 action)
Define F1, F1.1 and F1.2 (3 actions)
Link F1.1 and F1.2 to F1 (2 actions)
Define the interfaces for each block (9 actions for 3 interface blocs, 3 flow properties and 3 value types)
Add ports to each block (6 actions)

Then it requires additional 4 actions to create an internal block diagram and 3 new elements to link the sub-functions F1.1 and F1.2:

Create the internal block diagram (1 action)
Link the F1 ports with “delegate” links to the sub-functions ports (2 actions)
Link the sub-functions ports with a “connector” link (1 action)

Please note that the internal block diagram is automatically synchronized with the related block diagram to display the parts F1.1 and F1.2 with their ports, and the F1 ports, at its creation.

Rational Rhapsody Architect for Systems Engineers

Rational Rhapsody Architect for Systems Engineers [RRA] from IBM is a modeling environment based on UML providing a visual development environment for systems engineers creating real-time or embedded systems.

The SysML profile available in RRA is used to model the decomposition of the function F1 with a block diagram:

It requires 27 actions to create 20 new elements and 1 diagram as follows :

Create the block definition diagram (1 action)
Define F1, F1_1 and F1_2 (3 actions)
Link F1_1 and F1_2 to F1 (2 actions)
Define the interfaces for each block (9 actions for 3 interface blocs, 3 flow properties and 3 blocks)
Add ports to each block (12 actions to create 6 proxy ports, then to specify its type for each of them)

Please note that there is no possibility in RRA to drag and drop any types to create the corresponding instance. Therefore additional actions are required to “type” the created proxy ports.

Then it requires additional 6 actions to create an internal block diagram and 3 new elements to link the sub-functions F1.1 and F1.2:

Create the internal block diagram (1 action)
Drag and drop F1_1 and F1_2 parts (2 actions)
Synchronise the internal block diagram to display the F1 ports (1 action)
Link the F1 ports with “dependency” links to the sub-functions ports (2 actions)
Link the sub-functions ports with a “connector” link (1 action)

Functional decomposition in non-SysML modeling tool

ArKItect SEA

Systems Engineering Advanced [SEA] is a single engineering database to synchronize, verify the consistency and completeness of all system engineering data. It offers an easy-to-use collaborative environment for the modelling of complex systems and for the definition of systems specifications.

The view “Functional Architecture” is used to model the function F1:

It requires 3 actions to create F1, F1_in and F1_out (3 actions).

Then another action is required to expand F1 definition in order to create F1.1 and F1.2 (3 actions):

Once F1.1 and F1.2 are created, the user has to allocate F1_in and F1_out on F1.1 and F1.2 respectively (2 actions).

At least the user has to define F1.1_out between F1.1 to F1.2 (1 action):

Same diagram to allocate F1_in, F2_in and to define F1.1_out

Please note that the definition of F1_in, F1_out and F1.1_out is equivalent here to the definition of the corresponding types F1_in type, F1_out type and F1.1_out type for SysML modeling tool.

Capella

Capella is an open source solution for model-based systems engineering.

The System Data Flow Blank [SDFB] diagram is used to create F1, the enabling functions A 2 and A 3, and F1_in and F1_out as follows:

SDFB diagram to create F1, A2 and A3, and F1_in and F1_out

It requires 6 actions to create 5 elements and 1 diagram as follows:

Create the SDFB (1 action)
Create F1, A2 and A3 (3 actions)
Link F1, A2 and A3 (2 actions)

Please note that the definition of F1_in, F1_out and F1.1_out is equivalent here to the definition of the corresponding types F1_in type, F1_out type and F1.1_out type for SysML modeling tool.

Then the user has to clone this diagram into another SDFB diagram to keep a diagram where F1 is not decomposed (so called blackbox view — 1 action).

At least the user has to resize the function F1 in this new SDFB diagram to allocate F1_in and F1_out to subfunctions F1.1 and F1.2, and to create F1.1_out as follows: