About Jean-Marie Gauthier

Jean-Marie obtained a PhD in computer science applied to Systems Engineering. He is now an MBSE R&D engineer working at Samares-Engineering since 2016. He is an MBSE enthusiast manipulating abstraction for 10 years. His main subjects of interest concern systems science applied to modeling and simulation. He has published several papers in national and international conference. Also, he delivers courses at ISAE-Supaero and CNAM, and he participates to consulting mission with high expected values.

Part 8 – Digital continuity between SysML and Modelica

This article is part of a monthly series entitled “Advanced MBSE with SysML and other languages“.

In the second set of articles, this series explains how to complete the top-level system definition model, formalized in SysML, with other modeling languages and tools, considered as more efficient to perform the system detailed design or certain kinds of system analysis. The focus is put on digital continuity with guidelines concerning coupling semantics and coupling automation between languages and tools.

In this article 8, we present an approach to refine the system definition into a multi-physical specialized architecture with the support of the Modelica language and associated toolbox.

Executive Summary

This article focuses on performing multi-physical modeling with Modelica. It uses a SysML logical architecture to initiate a Modelica model composed of “Partial Models” that can be implemented in different ways. Therefore, partial models play the role of specification for the Modelica engineer. Then, after the design of the subsystems, simulation is performed to assess the system requirements. We show that some requirements are not satisfied, which leads to a request for change for the systems engineer (new interface between the subsystems). Finally, the preferred design is capitalized into the SysML physical architecture.

Context

In the previous articles (part 1 to part 5), we introduced a method based on the SysML notation to support the following systems engineering activities :

SysML focuses on abstraction, requirements, functional decomposition, systems decomposition, allocation, and traceability. Within SysML, and especially in its implementation with Cameo Systems Modeler, it is possible to perform simulation and animation of state machines, activity diagrams, IBDs, or sequence diagrams, and evaluation of parametric diagrams. So, we will show that we can complete the SysML definition with Modelica concepts and use the Modelica toolbox to perform analysis and assessment of the architecture, refine our knowledge and the system specification.

This article starts with the availability of a UAV logical architecture for the agricultural domain . It is illustrated below:

Agri UAV Logical Architecture

Modelica Language Overview

Image from https://www.modelica.org/modelicalanguage

Modelica is an object-oriented and equation-based language dedicated to the modeling and analysis of multi-physical systems. It is a defined by the Modelica Association. The Modelica language relies on both graphical and textual syntax. It makes it possible to combine Differential and Algebraic Equations (DAE) with discrete event systems. This language is well suited to represent flows of energy, signals, or materials, and any continuous interactions.

With Modelica, it is possible to create architectures made of sub-models connected by ports (undirected physical flows and directed signal flows). Models can be causal or acausal, and can represent hybrid systems (discrete and continuous). A good amount of free or commercial Modelica libraries are available for domains such as chemistry, automotive, neural network based AI, etc. The following figure shows examples of signal based components (integrator, PID, …) and physical based components (magnet, spring, tank, …) provided by Simulation X.

Signal library from Simulation X

Physical components library from Simulation X

Application on the Agri UAV case study

To illustrate the full approach, we use a simplified model of an Unmanned Aerial Vehicle (UAV) for agricultural domain. We use the following languages and tools:

SysML in CAMEO Systems Modeler 19.0 SP4
Modelica in Simulation X

The goal is to provide a physical solution for the “Water Container Subsystem” and for the “Treatment Subsystem”. The following figures show the Modelica elements that will be used to design the physical solution of each subsystem.

Systems Requirements and SysML logical architecture

First we start with the following logical architecture made by a systems engineer.

Agri UAV Logical Architecture

In this article, we focus on the following requirements that shall be satisfied by the final architecture. Each of these requirements specifies the valid definition domain for the variables to be observed.

Systems requirements

Note that in some of the requirements (req 3 and 5) we have introduced the notion of derivative. This requirement specifies that when the treatment subsystem is requested to stop, the flow shall continuously decrease. This is illustrated by the example of the following figure. All the curves are valid except the red one, which has a positive derivative at some point in time.

Initiate Logical Architecture in Modelica

The first step is to translate the functional/logical architectures defined in the SysML language toward an initial Modelica architecture in order to focus on the “Water Container Subsystem” and “Treatment Subsystem” with a language well adapted for the formalization and simulation of physical phenomena. This step results in a Modelica model containing Modelica partial models. The main advantage of using partial models to represent logical subsystems resides in their ability to be implemented using variants. Therefore, partial models can be seen as interface contracts that shall be respected by the engineers. Then, each individual model can be implemented with different architectures: this is what we will see next.

Modelica Initial Logical Architecture (Partial model)

In order to perform this translation, each Subsystem (SysML Block) is converted into a Modelica partial model. Each information flow is transformed into a Modelica Signal input or output and the hydraulic flow is converted into hydraulic ports and connectors in Modelica. We have used the SysPhS library (SysML Extension for Physical Interactions and Signal Flows Simulation) to type the ports. This library is available in Cameo Systems Modeler SP4 and has been specially built to specify physical and signal flows independently of the targeted simulation platform. Also, using this extension makes it possible to generate Simulink or Modelica models directly from the SysML model.

In this first structural approach, we propose the following mapping:

Systems Engineering Concept	SysML Concept	Modelica Concept
Function	Block	Partial Model
Technical System Element	Block	Partial Model
Data Port	Proxy Port + Interface Block (SysPhS Signal Interface)	Partial Model
Trigger Port	Proxy Port + Interface Block (SysPhS Signal Interface)	Signal port
Enable/Disable Port	Proxy Port + Interface Block (SysPhS Signal Interface)	Signal port
Energy Port	Proxy Port + Interface Block (SysPhS Physical Interface)	Physical Port
Functional Flow	Connector	Connect equation

Define Physical components that fit with the logical architecture

Once we have created a logical architecture in Modelica that is semantically equivalent to the SysML logical architecture, we can explore the different physical solutions able to refine this logical architecture and we determine the appropriate physical components which satisfy all the requirements presented before.

To design the “Liquid container subsystem” and the “Treatment subsystem” we will use the following elements from a hydraulic library available in Simulation X.

First design of the logical subsystems

Using an available hydraulic library, we perform the following design for the “Water Container Subsystem” and the “Treatment Subsystem”. In addition, we build mock-ups for the other components in order to support simulation (this is not presented here).

Water Container Subsystem Design

Treatment Subsystem Design

The simulation results of this first design allows us to see if the requirements are satisfied or not.

Volume flow (left curve) and Pressure (right curve)

At t = 70s, the stop command is received, then the volume flow (left side) and the pressure (right side) start decreasing. We see that the volume flow can not reach 0.001 l/min in less than 0.5s. Also, the pressure can not reach 0.02 bar in less than 0.5s.

The requirement is not satisfied in the interval [70s; 72s].

Volume flow (left curve) and Pressure (right curve)

From the simulation results, we can see that the first part of the requirement 2 (“Volume Flow Stop Perf 1”) and the requirement 3 (“Perform Stop Perf 1”) are not satisfied. Indeed, the spray does not stop in less that 0,5 s because of remaining pressure in the pipes. The solution can consist in adding valves before each nozzle that can be opened / closed on demand. The valve ensures that there is no remaining flow from the nozzles when it is not required. In addition, it ensures safety in case of failure of the controller or the pump. However it requires the creation of a new interface between the Mission Management subsystem and the Treatment subsystem. Therefore, this would trigger a request for change to the systems engineer to see the impact of creating a new interface between the mission management and the treatment subsystem.

Second design of the logical subsystems

A new interface is created as seen in the following image (valve_cmd).

SysML Logical Architecture with new interfaces (valve_cmd)

The design in Modelica results in the following Treatment Subsystem model:

The following results show that the requirements 2 and 3 are now satisfied by the design.

Feedback in SysML

The physical interfaces of the subsystems can be generated from the Modelica model. Here is an excerpt of the physical architecture that corresponds to a specific Modelica design. Note that we may find a lot of other types interfaces (electrical, mechanical, …). In that case, we suggest creating one IBD per physical viewpoint (physical domain). Now the treatment subsystem is « completely » specified (electrical and mechanical viewpoints are missing). We have identified a design solution that can satisfy the requirements. Hence, physical interfaces and sub-components can be built in SysML and traced to the rest of the model.

Synthesis

In this article we have proposed a coupling method between SysML (a Systems Engineering language) and Modelica (a physical modeling language). The proposed method includes a definition of system requirements and logical architecture using SysML and an initialisation of a partial Modelica model for physical architecting. Finally, when the virtual product can be verified against its requirements, this activity can lead to a change management loop with some updates to perform in the system definition (system requirements) with potential impacts on the SysML model.

Design loop between SysML and Modelica

Going further

First, the initial model has been initiated manually from the SysML model. However, it would be possible to have a seamless code generation of Modelica partial models from the SysML models. Indeed, since partial models play the role of specification (interface contracts), it would be possible to adapt the approach to take into account the full process of configuration and change management.

Second, as Cameo Systems Modeler offers FMI co-simulation capabilities, it would be possible to generate and assemble FMUs from the Modelica models produced for some subsystems with FMUs generated from Simulink models (for the control subsystems). This would make it possible to characterize the co-simulation architecture from the logical architecture.

Enjoy MBSE !

Next articles to come…

January 2021 – Co-simulation of SysML and other models through FMI

Part 4 – Consistency between functional and logical architectures

This article is part of a monthly series entitled “Advanced MBSE with SysML and other languages“.

In the first set of articles, this series explains how to use a modeling approach based on the SysML notation to progressively analyze, structure, refine and derive stakeholder needs and requirements into system architectures and lower-level requirements, down to configuration items containing software and hardware parts.

In the second set of articles, this series will focus on the links to other modeling languages used to detail the design and/or perform detailed analysis and simulations to evaluate, verify or validate the virtual representation of the system.

This fourth article deals with functional and logical architectures. We discuss the following questions: Why do we need a logical architecture? And how do we ensure the consistency between the functional and logical architecture?

Why do we need a logical architecture?

In most industrial practices, and in various industrial domains, systems engineers are used to define one (and sometimes several) functional architecture(s). This architecture formalizes an arrangement of system functions using two viewpoints: the Functional Breakdown Structure (FBS), which shows the decomposition hierarchy as a tree ( “parent” functions and “child” functions) and the connection graph that shows the functional flows between those functions (energy, information, matter).

As an illustration, let us take the AIDA open-source sample case from the Saint Exupery Technological Research Institute in Toulouse: https://sahara.irt-saintexupery.com/AIDA/AIDAArchitecture.

AIDA stands for “Aircrat Inspection by Drone Assistant”. AIDA provides assistance during the inspection of an aircraft before flights: the drone seeks for Aircraft defects.

The drone system contains 9 top-level functions:

Manage mission
Build fight plan relative to aircraft type
Fly to
Retrieve PoI (Points of Interest)
Make and record videos
Check wind force
Monitor UAV control
Sense and avoid obstacles
Emergency landing

The definition of these functions is formalized with Blocks in SysML.

We use an IBD to formalize the functional architecture. Practically, this diagram displays the usage of the functions in their operational context (SysML part properties typed by the previously mentioned blocks), the interfaces (connectors with item flows) between the SOI and the other members of the system context, and the interfaces between usages of functions (also connectors with item flows).

A possible functional architecture for the identified top-level functions is provided below:

Some of the top-level functions are still complex and need to be refined through lower-level functions. So we can build a functional architecture that displays several levels of functions as illustrated below:

When developing a system, it is also common to find a description of the physical components. By “physical components”, we mean a hardware part, a Software piece, or any combination of those elements. It includes processors, sensors, structure, propellers, etc.

The problem comes when we want to allocate our functions to the physical components. In the frame of a complex system, the list of physical components may become very large, especially when this list is not finalized and contains many alternatives. For instance, in order to allocate the “sense wind” function, we may find a lot of different technologies and means to perform the measurement, mixing software and hardware features.

As the final physical architecture shall satisfy all non-functional requirements including reliability and availability, we generally introduce redundancy of safety-critical components to ensure its availability even when there are failures in one of the components. In the end, the number of physical elements to consider for allocation is huge.

Let us take the previous example to illustrate a non exhaustive list of physical components:

The allocation of top-level functions, identified from the needs expressed by the customer and users are hard to allocate to the identified physical components because the abstraction gap between the system functions and the physical components is high. We need an intermediate layer to partition functions into items that represent an abstraction of the final technologies. This is the “logical architecture” layer.

The logical architecture as an intermediate layer

As stated by the INCOSE Systems Engineering Handbook (4 ed.), the logical architecture definition consists in decomposing and partitioning the system into logical elements

[…]. The elements interact to satisfy system requirements and capture systrem functionality. Having a logical architecture mitigates the impact of requirements and technology changes on system design.

The logical architecture is an arrangement of “logical components” that perform the functions. This first allocation is easier to perform because we can group functions with criteria such as cohesion, coupling, design for change, reliability, and performance.

Later, we will have to do a second allocation: allocate logical components on physical components (with technology). This second step is also easier to perform than the direct allocation from functions to physical components because we only have to focus on technologies/products available on the market to satisfy a logical component already defined.

Let’s go back to our AIDA example. Here is a possible set of logical components for our system of interest surrounded by its environment (as in the functional architecture):

Mission management subsystem
Propulsion subsystem
Flight management subsystem
Vision Subsystem

Here is an example with the use of the SysML allocation matrix (within Cameo Systems Modeller environment) to create the allocations of functions to logical subsystems.

How do we create the logical architecture?

When creating a logical architecture, it is possible to connect the logical components directly in the diagram, by using engineering knowledge: it is sometimes already known that 2 components will exchange information or energy. However, the rationale for connecting the 2 components is missing. In the end, the logical architecture may miss interfaces or contain useless interfaces.

Therefore, the logical interfaces shall not be fully independent of the functional interfaces. The logical components reflect the partition of functions and should thus reflect the functional flows. There is a consistency between the functional architecture and the logical architecture.

The next chapter explains this in detail.

Consistency between the Functional architecture and the logical architecture

We return to the AIDA sample case to illustrate this consistency with a few functions and allocations. Instead of looking at the full functional architecture, we will focus on a simple extract with only 3 leaf functions coming from the “manage and record videos” top-level system function:

“Manage Photos Recording”,
“Control Camera Orientation”
“Record Photos and Videos”

Now we want to allocate the 2 first leaf functions to “Mission Management Subsystem” (in blue) and allocate “Record Photos and videos” to “Vision Subsystem” (in red) as illustrated below:

Note: in SysML, we use the SysML allocation matrix to edit (create and delete) these “allocation” relations. The allocation described above leads to the following matrix.

Now we would like to reflect the impact of these allocations on the logical architecture. Practically this means:

Display the functions inside their components
Display the functional flows between functions through the ports of the logical components because we want to respect the “encapsulation principle” of the components (a component can show or not show its internal structure but its ports do not change)
Display the functional flows with the system environment (through the System external ports)

In our example, for the subset of the functional architecture and the 3 allocations, it results in the following logical architecture with the creation of 3 logical flows (in orange):

Logical Architecture result after allocations

We can see that the logical flows (in orange) directly come from the functional architecture: they are deduced / reflected from this functional architecture and from the allocation of functions to the logical components.

Conclusion

There exist a relation between the functional architecture and the logical architecture. A logical subsystem can produce or consume flows if there is one or several functions allocated to it. In addition, some functions may appear directly at the logical layer, e.g., interface function between subsystems, encoding functions, decoding functions, or electrical functions. These functions may make no sense at the functional system level since they depend on the chosen technologies and can be very detailed. But, whatever the abstraction level of the functions, the logical layer shall be consistent with the system functional layer.

Can we automate some of the steps presented above?

Yes !

Overview of the automation

At Samares Engineering, we have created a plugin to automate the update of the logical architecture (display of functions, creation of logical flows) according to the functional architecture and allocation of functions to the logical components. This propagation is done in real-time. And it works in both directions (creation and deletion of allocations, leading potentially to the creation or deletion of logical flows between logical components). So we can ensure that the logical architecture is always consistent with the functional architecture.

We can also show the functions inside each component or hide those functions and only show the components and their logical flows.

Take a look at the video below to see this automation in practice.

Simulation in practice (video)

This video shows how we can ensure consistency between a functional architecture and a logical architecture while editing the allocation of functions to the components, in real-time.

Enjoy MBSE!

Next articles to come…

August 2020 – Minimization of the coupling in the logical architecture
September 2020 – Digital continuity between SysML and Simulink
October 2020 – Digital continuity between SysML and AADL
November 2020 – Digital continuity between SysML and Modelica
January 2021 – Co-simulation of SysML and other models through FMI

Previous articles in the series

April 2020 – Formalization of functional requirements
May 2020 – Derivation of requirements from models: From DOORS to SysML to DOORS again
June 2020 – Early validation of stakeholder needs through simulation