Product Line Engineering and Model Based Systems Engineering – Overview
This article is part of a monthly series entitled “Product Line Engineering and Model-Based Engineering“.
Part 9 – Co-Simulation of SysML and others models through FMI
This article is part of a monthly series entitled “Advanced MBSE with SysML and other languages“.
In this article 9, we explain how to distribute some sub-systems of a logical architecture to a set of suppliers and to integrate and co-simulate their behavioural models in the SysML tool with the FMI standard.
This is the first article about using the FMI standard for co-simulation, but not the last! There is a lot to say about using FMI, and this article 9 can be considered as an introduction on using FMI in extended enterprise, through a fairly simple sample case. At the end of this article, we mention some challenges and advanced topics that we plan to work on during 2021, and this work will lead to other articles.
Context
In the previous articles (part 1 to part 8), we introduced a method based on the SysML notation to support the following systems engineering activities:
- Formalization of functional needs
- Refinement and definition of systems requirements
- Early validation of stakeholder’s needs using Functional Simulation
- Definition of Functional and Logical Architectures
- Optimization of Logical Architectures
- Digital Continuity between SysML and Simulink
- Digital Continuity between SysML and AADL
- Digital Continuity between SysML and Modelica
This article starts with the availability of an Aircraft Inspection By Drone Assistant (AIDA model inspired from the IRT St Exupery case study) logical architecture. It is illustrated below:
The different subsystems (logical components) will be assigned to different suppliers. We expect each supplier to develop a behavioural model of the assigned subsystem before developing the real subsystem. The idea is to integrate all the behavioural models provided by the different suppliers into a central repository, and to co-simulate all those models (simulate all those models concurrently) to evaluate the global behaviour and validate that it behaves as expected. We will use the FMI standard for co-simulation. This is explained in the next paragraphs, before we show the practical steps for integration and co-simulation of the behavioural models through FMI.
Functional Mock-Up Interface (FMI) Standard Overview
The Functional Mock-Up Interface (FMI) is a standardized interface to exchange dynamic models issued from various simulation tools and package the model as a combination of an XML model description file, executable binary files and eventually C code files into a single zipped file.
https://fmi-standard.org/
This makes it possible to extract models from several different simulation tools, and integrate heterogeneous models into a single simulation tool and provide the model as a “black-box” for preservation of intellectual property when it is required.
Introduction
- All components that need to support FMI shall comply with a standard interface that brings services to perform a time step in a model: set input data, progress in the behaviour from one time step – fmiDoStep (or fmi3doStep in the most recent version 3), and get results (output data)
- Basically, an FMI-compliant component is packaged into a Functional Mockup Unit (FMU), which is a zipped file (*.fmu) containing:
- modelDescription.xml
- Implementation in source and/or binary files that complies with FMI services
- Additional resources if necessary
In the next paragraph we present the model description file and the principles of FMI for both model exchange and co-simulation, with a particular focus on co-simulation.
Model Description file structure
The modelDescription file structure is presented below:
Model description structure (from FMI specification)
Principles of model sharing with FMI
- FMI for Model Exchange:
This approach is proposed to extract model data from a simulation tool without its solver. It is then possible to re-integrate the extracted model in another tool where an appropriate solver is available.
Note: As our article will focus on FMI for Co-Simulation, we do not go into detail on the Model-Exchange principles in this article. If you are interested in more details about Model Exchange, please refer to the FMI Standard.
- FMI for Co-Simulation
This approach makes it possible to extract an executable simulation model from a specific tool. The executable is then used as a component library to be integrated in a wider environment. This mode is particularly useful to integrate several models coming from different suppliers to evaluate the overall consistency of the complete system.
FMI for Co-Simulation
- FMI for Co-Simulation Export:
- C code and xml file generation with embedded solver
- Archives (.zip) sources and binaries into a .fmu file
FMU for Co-Simulation Export
- FMI for Co-Simulation Import:
- Requires a Master-Algorithm (MA) which synchronizes fmu exchanges
- FMUs can be connected to the other parts of the model
FMU for Co-Simulation Import
The Master Algorithm executes individual FMUs at regular communication time steps (hC) and propagates the model outputs to their connected models. This mechanism is called by standardized FMI APIs as illustrated below:
Systems Design and Supply chain process
As explained in the introduction of the article, we want to perform early Verification and Validation of system requirements and verify the global behaviour that is split between the different subsystems. We distribute the subsystems definition models to different suppliers (specialists of different domains) and request them to provide a detailed behavioural model that is compliant with the FMI standard.
This process is illustrated in the figure below:
We collect the different models provided as executable files (“black-box”) to preserve the supplier Intellectual Property (IP). From the integrator side, we can now integrate those potentially heterogeneous models (i.e.: developed with different simulation tools and solvers) into a single tool and verify the overall execution of the different models and their interoperability. This is possible thanks to the FMI standard that ensures this interoperability.
Note: This article briefly presents the co-simulation of different logical components developed in a well-defined sequence from mature specifications. In industrial reality, it may happen that the subsystem behavioural models are developed concurrently with the system architecture definition. We do not give details about the full industrial process of exchange with suppliers and gap analysis for alignment with definition models when both definition and detailed behaviour have been defined concurrently. If you want to know more about this industrial process, you can look at our CSDM 2020 conference joint article with Renault: “Applying Model Identity Card for ADAS V&V“.
Illustration on AIDA case study
In our example we use the AIDA Unmanned Aircraft Vehicle System. The logical architecture of the UAV System is shown in the figure below:
It is possible to define verification criteria based on requirements formalized by SysML constraints, as illustrated below for controller accuracy (0.5m):
Now we provide specifications to our suppliers (including a SysML model of the context of each subsystem and requirements on the expected behaviour). Suppliers will have to develop the behavioural models.
Note: we illustrate the full process for only two subsystems (UAV Control station and UAV system) and one external system (Air gravity) to limit the size of this article. But what is shown can be applied in the same way to many other subsystems and external systems.
- AV Control Station – Behavioural Model Provider:
This actor is in charge of developing and to providing the behavioural model of the UAV Control Station with a dedicated focus on the Build Flight Plan function behaviour. In this example, the UAV Control Station Model provider uses the MATLAB / Simulink 2019b tool and wants to provide the UAV Control Station behavioural model as a “black-box” executable model to the System Integrator using the FMI for Co-Simulation 2.0 export capability integrated in MATLAB / Simulink.
- UAV System (vehicle) – Behavioural Model Provider:
This actor is in charge of developing and to providing the behavioural model of the UAV System and in particular of the UAV Control Position and attitude functions behaviour. This behavioural model is developed using the MATLAB / Simulink 2019b tool and is provided as a “black-box” executable model to the System Integrator using the FMI for Co-Simulation 2.0 export capability integrated in MATLAB / Simulink.
- Environment – Air Terrestrial Gravity – Behavioural Model Provider:
This actor is in charge of developing and to providing the behavioural model of the UAV Environment, especially of the Air / Terrestrial Gravity. This model is required to model the effects of the external environment on the UAV System. We suppose that OpenModelica v1.16.2 is used to develop these models and to export the behavioural model using the FMI for Co-Simulation 2.0 export capability integrated in OpenModelica.
This responsibility sharing is summarised in the figure below:
Generation of Functional Mock-Up Unit from MATLAB/Simulink
Each supplier shall develop its behavioural models and define its associated interfaces:
When a supplier has finalised the Simulink behavioural model and has tested it through simulation, it is then possible to create a MATLAB/Simulink project and share its contents as an FMU for Co-simulation:
Generation of Functional Mock-Up Unit from OpenModelica
When a behavioural model has been developed and simulated successfully on the supplier side, the Modelica model can be exported as an FMU:
The supplier should configure the FMI options in the OMEdit configuration window:
Finally, the supplier can export Functional Mock-Up Unit for Co-Simulation.
Assembly and execution of Functional Mock-Up Units in Cameo
When all the Functional Mock-Up Units have been received from suppliers as “black-box” executable models, the System Integrator can assemble these models. We can use the Cameo Systems Modeler tool and the Cameo Simulation Toolkit features to verify interface compatibility and the overall behaviour execution.
To perform this action, Cameo systems Modeler (CSM) offers a drag & drop feature of an FMU into a SysML IBD (Internal Block Diagram) and proposes the following import menu:
When all the FMUs have been imported into the Cameo Systems Modeler project, it is possible to assemble them together and check the consistency of the interfaces in regards to the established specification:
In order to simulate this model, it was necessary to “break” the feedback loop between Air Terrestrial Gravity and UAV System. This was done by inserting a “delay” component, which introduces a discrete delay (1/z) configured to 1 communication step size. This kind of annoying effect may appear depending on the tool used for FMU integration and on the underlying co-simulation master algorithm. We propose to address this topic in more detail in a future article.
Next, the System Integrator is in charge of configuring the Simulation execution and especially the communication step size and the simulation duration. This configuration is done in the Simulation Configuration Diagram, as illustrated below:
Now, before starting the simulation execution, it is necessary to launch the MATLAB Console for each MATLAB/Simulink FMU (at least for MATLAB/Simulink 2019b models) and execute the ShareMATLABforCosimFMU command (where communication between MATLAB FMU and MATLAB runtime is required).
During simulation, the results can be observed from plots available in Cameo Systems Modeler, and it is possible to verify requirement compliance using co-simulation results inside Cameo:
In the execution results, we can observe that the requirement (constraint) concerning the maximum error of 0.5 m between the target position and the real position is verified for the Y coordinate (constraint is respected, in green) but not for the X coordinate (constraint is violated, in red).
This approach makes it possible to detect requirement violations during co-simulation execution, which would have been very hard to detect without co-simulation, or that would have been detected later in the product verification, perhaps too late…
Synthesis
In this example, we have illustrated the capability to perform execution of heterogeneous FMUs (Modelica and MATLAB/Simulink) and co-simulate their execution within Cameo Systems Modeller. This capability allows for Systems Verification while collecting Systems artifacts behaviours from suppliers as Functional Mock-Up Units.
Then, the Systems Engineer can integrate these models in a co-simulation environment and define the appropriate communication time-step (hC) size for the FMUs communication. To define the appropriate time-step size, the Systems Engineer should consider the overall expected parameters, such as the overall simulation time, and signal and behaviour dynamics / periods.
Going further
In this article, the initial model was 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.
Next, 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.
Then, it should be interesting to explore the usage of FMI standard companions such as System Structure & Parametrization (SSP) which supports standardization of co-simulation graph and configuration and Distributed Co-Simulation Protocol (DCP) which supports the standardization of communication protocols for co-simulation distributed on several execution nodes such as computers.
Finally, we plan to contribute to different initiatives (like the AFIS/NAFEMS working group) that aim at bridging the gap between system definition models developed by system architects with an MBSE approach, and detailed behavioural models sometimes called “simulation models” developed by domain specialists. The idea is to leverage the integration of those different models to address different purposes including feasibility, evaluation of performances, verification of system requirements and validation of expected behaviour.
Next articles about FMI/FMU
We consider the use of the FMI standard as a key practice to leverage the MBSE approach in extended enterprises. In future articles we plan to address the following complementary topics:
- Complex multi-physical model: in the current article, we addressed simplified Modelica and MATLAB/Simulink models for the Flight Control System. In a future article we plan to address a more complex multi-physical model which will combine discrete state machines behavioural models, control-command systems and physical acausal systems (pipes, fluids, mechanics, …).
- Mixing virtual and real systems: we plan to explore a progressive integration of real systems in combination with co-simulated systems to allow for an incremental Verification and Validation process.
- Connect operational scenarios with a simulated environment: we intend to detail the links between scenarios defined at the operational and functional architectural levels, scenarios used for Verification and Validation and to automate/link Simulation Environment and associated results.
- Provide feedback on the identification of the communication step size: Detail more complex models and give best practices to define the accurate value for the communication step size.
Enjoy MBSE !
Part 7 – Digital continuity between SysML and AADL
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. Focus is put on digital continuity with guidelines concerning coupling semantics and coupling automation between languages and tools.
In this article 7, we start from a System Definition model developed with SysML and we present an approach, which uses real-time architecture specialised language to refine this definition into an Electric / Electronics and Software Architecture. We use AADL (Architecture Analysis Description Language) as an example, but we could use languages with similar concepts and purposes such as AUTOSAR (used in automotive industry) or UML MARTE.
We present the allocation of timing budgets on SysML models, starting from operational scenarios, and through the concept of Functional Chains. We refine these timing requirements through the definition of physical components and a physical architecture formalised with AADL.
Executive Summary
Context elements
In the previous articles (part 1 to part 5), we have introduced a method based on the SysML notation to support the following systems engineering activities :
- Formalization of functional needs
- Refinement and definition of systems requirements
- Early validation of stakeholder’s needs using Functional Simulation
- Definition of Functional and Logical Architectures
- Optimization of Logical Architectures
This article starts with the availability of a logical architecture for a case study called AIDA (that comes from the Saint Exupery Research Institute). It is illustrated below:
AIDA Logical Architecture
End to End Timing requirements and Functional Chains concept in SysML
End to end timing requirements are very important non-functional requirements (amongst others) to consider in order to reduce the solution space and to choose the appropriate physical solution. An end to end timing requirement generally specifies the acceptable maximum timing duration expected from an input to a specific output (of a function or a system) following a specific flow path in a specific operational scenario. End to end timing requirements may be imposed by a Stakeholder Requirement or may emerge as a System Requirement to satisfy a Stakeholder Requirement.
Functional chains are playing a key role to specify end to end timing requirements. A functional chain may be seen as an abstraction of a set of execution paths from an SoI’s input to an SoI’s output. In this article, we propose to formalise a functional chain with a SysML block, and the end-to-end timing requirement with a time duration constraint element directly available in the SysML notation, as illustrated below:
End to end timing requirement on a functional chain
Then, we propose to show the realisation of the functional chain with a SysML IBD Diagram. This diagram allows to visualise the end-to-end flow from the selected function/System input(s) to the selected function/System outputs. Each function’s input and output that participate in the functional chain are linked with a dependency link
As an example, the following IBD diagram focuses on the functional chain that controls the position of the UAV and the required thrust value. The end to end timing requirement applies to the whole functional chain, which means in our example that the final solution shall take less than (or equal to) 10 ms to perform the loop. Therefore, it is necessary to divide the timing budget and to allocate a time duration to each function in order to find a solution that can satisfy this requirement.
Functional chain for control loop
In practice, the proposed process consists for the System Engineer in defining timing requirements as budgets for all the elements of the overall chain. Then, Systems Designers will have to demonstrate how their selected design meets these execution budgets. This is where we suggest to use AADL language to refine timing properties induced by selected hardware components and software properties. The next paragraph quickly presents the AADL language and the following paragraph provides an application on our example.
AADL Language overview
AADL (Architecture Analysis and Design Language) is a language dedicated to the modeling and analysis of real-time, safety critical, embedded systems. It is a standard published by the Society of Automotive Engineers as reference AS5506C.
The AADL language relies on both graphical and textual syntax and it includes the following concepts and extensions:
In this article, we focus on the following Base Standard concepts:
- Structure Concepts:
- Abstract Components
- Software Components (Processes, Threads and Subprograms)
pictures from AS5506C standard
-
- Software Timing properties (periods, priorities, …)
- Hardware Components (Processors, Devices and Buses)
pictures from AS5506C standard
-
- AADL Ports
pictures from AS5506C standard
-
- Data Types
- Connections Properties
- End to End flows and associated latency requirements:
- concept of end to end flow (from specific input to specific output) and definition of latency requirements
- concept of latency on flows
- Bindings:
- concept of mapping of functions (abstract components) to software elements
- concept of mapping of software components to hardware components elements
Application on the AIDA case study
To illustrate the full approach, we use a simplified model of an Unmanned Aerial Vehicle (UAV) based on the AIDA case study developed at the St-Exupery Research Institute. We use the following languages and tools:
- CAMEO Systems Modeler 19.0 SP4
- AADL Inspector from Ellidiss
- STOOD for AADL from Ellidiss
And Hardware architecture has been defined with inspiration from crazyflie aadl architectural model.
The AIDA Logical Architecture in SysML has been recalled at the beginning of this article. Here we put the focus on the UAV system and in particular the co-design of the electric/electronic and distributed software architecture.
The functional goal is to control the actual position of the UAV to fit the expected trajectory around the aircraft. Therefore, one must find the right control parameters so that the UAV can follow the expected trajectory within an expected maximum timing latency. Then, we want to verify the compliance of the selected hardware and software architecture to the timing requirements.
Recall of the AIDA Functional and Logical Architectures
The AIDA Functional Architecture is defined in SysML and presented below:
AIDA Functional Architecture
In this functional architecture, we detail the position and attitude control functions, as well as the compute thrust and generate thrust functions of the UAV.
The logical architecture is established with regards to emerging systems and sub-systems decomposition. In this example, we decompose the UAV into the following subsystems:
- Perception Subsystem
- Flight Management Subsystem
- Propulsion Subsystem
- Mission Management Subsystem
Then, we allocate the functions to the subsystems as follows:
AIDA Logical Architecture
Definition of Timing Requirements (end to end latency) in SysML
Next, we define the expected maximum latency of the measurement to thrust force control (performance of the control loop) in a specific functional chain defined in SysML, as presented below:
Functional Chain for Control Loop
This chain is extended with the duration constraint property defined with a range of valyues between min and max values. In our example: 0ms .. 10ms.
Initiate Logical Architecture in AADL
From this step, we perform the design of this system using the AADL language to support software design by taking into account hardware constraints and performing timing verification.
The first step is to translate the functional/logical architectures and functional chains defined in the SysML language toward a logical architecture using the AADL language. This step results in an AADL System Implementation using Abstract Components and end to end flows as illustrated below:
Resulting AADL Architecture from SysML Logical Architecture
In order to perform this translation, we convert our SysML Flow of Information of type “Trigger” into Event and Flow of Information of type “Data” in AADL Data exchanges. The functional chain is converted to the equivalent concept of AADL end to end flow with latency specification.
In this first structural approach, we propose the following mapping:
| System Engineering Concept | SysML Concept | AADL Concept |
|---|---|---|
| Function | Block | Abstract Component |
| Technical System Element | Block | Abstract Component |
| Trigger Port | Port | Event Port |
| Enable/Disable Port | Port | Event Port |
| Any other Port (Data, Material or Energy) | Port | Data Port |
| Internal Dependency Relation | Dependency | Flow path |
| End to End Functional Chain from operational scenario | Block, IBD | End to end flow |
| Functional Chain Duration | Time Duration Constraint | Latency |
| Functional Flow | Connector | Port Connection Feature |
Define Hardware / Software components that fit with the logical architecture
Once we have created a logical architecture in AADL that is semantically equivalent to the SysML logical architecture, we can start exploring the physical architecture definition using AADL concepts.
We initiate the Physical Architecture from the Logical Architecture and start to design Physical Components (defined as System Components in AADL), one for each Subsystem:
- Mission Mgt Sub-System
- Perception Sub-System
- Flight Mgt Sub-System
- Propulsion Sub-System
Now we can explore the different physical technical solutions able to refine this logical architecture and we determine the appropriate physical components (hardware and software) which satisfy all the requirements (functional and non-functional such as timing requirements or expected temperature range, safety level of selected devices, constraints due to selected solutions, …).
This exploration space is wide and shall be done carefully with regards to the compatibility of the physical interfaces. In the following example, we select a design solution to minimise the cost and timing execution of the Flight Control Management from Targeted Attitude and Position input up to the generation of the Thrust Force. The engineering goal is to move the UAV with an expected maximum timing budget of 10 ms.
With this design, we propose a mapping from Sub-Systems to Physical Components as follows:
- Mission Mgt and Flight Mgt are implemented by the FlightMgtController System Electronic Control Unit (Hw and Sw components)
- Propulsion Sub-System is implemented by a PropulsionMgt System which is composed of 4 Electrical Motors and associated Propeller / Power adapter.
- Perception Sub-System is implemented by a Sensors_Module System which is composed of an integrated circuit which implements 3 sensors (accelerometer, gyroscope, magnetometer).
Note : In the Logical Architecture, the Perception Sub-System shall eprform the following internal functions:
- SenseAttitudePosition
- FuseData
According to the expected performance and available/selected technologies, some sensors may provide hardware support for FuseData. In the proposed solution we perform the selection based on costs, so we decide to perform FuseData using dedicated software and we allocate the FuseData function to the Flight Controller instead of Sensors module.
Define Hardware / Software architectures and bind them to the logical architecture
Then, we can design the software architecture while taking into account hardware constraints, and study the technical solutions to implement the logical components (selection of appropriate devices and processors, decompose functions into several processes, allocate processes to one or more processors, define interaction between the software and hardware elements, …). At this stage, hardware and software engineers shall analyse the suitability of the architecture regarding functional and non-functional requirements (such as timing requirements).
For this article, we propose a simplified electronic architecture using the following physical components :
- One MPU9250 device for Attitude/Position sensing usable with I2C interface. This device integrates the following sensors:
- Accelerometers : Digital-output triple-axis accelerometer with a programmable full-scale range of ±2g, ±4g, ±8g and
±16g and integrated 16-bit ADCs - Gyroscope : Digital-output X-, Y-, and Z-Axis angular rate sensors (gyroscopes) with a user-programmable full-scale range of ±250, ±500, ±1000, and ±2000°/sec and integrated 16-bit ADCs
- Magnetometer: 3-axis silicon monolithic Hall-effect magnetic sensor with magnetic concentrator
- Accelerometers : Digital-output triple-axis accelerometer with a programmable full-scale range of ±2g, ±4g, ±8g and
- One 32 bits FlightController Processor for FlightControl functions execution: STM32F7x5
- One 32 bits Connectivity Processor for Connectivity features (BlueTooth Low Power mode): STM32WX5
- 4 electrical motors controlled by PWM outputs from the Main Processor
- 1 UART bus for communication between the Main Processor and Companion
With those choices, we suggest the following AIDA HW Architecture:
AIDA Hardware Architecture in STOOD for AADL
For software design, we suggest decomposing the software in 2 processes (connectivity and flight management). This is mainly due to the following elements:
- Different criticality level between the 2 software applications
- Different timing constraints between the 2 software applications
- Limited computing power to execute the both applications on one processor
- The main processor does not support all the required connectivity and interfaces
That is the reason why, in this proposal, we have performed the following decomposition:
- One Process dedicated to the Connectivity Stack (focus on communication interfaces with Uav Ctl Station and Pilot)
- One Process dedicated to FlightMgt related functions:
- Thread MissionModesMgt: implements RetrievePOI and MissionMgtModes functions
- Thread FlightControlLoop
- ControlUAVAttitude: implements Control UAV Attitude function
- ControlUAVPosition: implements Control UAV Position function
- ComputeThrust: implements Compute Thrust function
- Thread Driver I2C MPU9250: implements the interface with the Attitude Sensors Devices and functions of Perception Subsystem (AcquireAttitudePosition and FuseData)
- Thread CommunicationMgt: implements the communication interface with the Connectivity processor
- Thread Propeller Interface: implements the interface with the electrical motor command (PWM)
The proposed AIDA SW Architecture is presented below:
AIDA SW Breakdown Structure
AIDA SW Architecture in Ellidiss STOOD for AADL
Finally, we can perform the binding in a 3 steps process:
1. Allocate Software Processes to Hardware Processes
2. Perform correspondence/allocation between Abstract components (translated from SysML logical components) and Hw/Sw components.
3. Verify the consistency of the design by checking that all the logical components are bound to the Processes and the hardware components.
AIDA UAV Hw/Sw Architecture
Perform Timing Analysis thanks to AADL
Now, it is possible to use integrated AADL analysis (static analysis, scheduling analysis) thanks to some AADL compatible simulation tools such as AADL Inspector.
We can analyze the compliance to the expected end to end timing requirements :
And then, perform scheduling analysis with appropriate simulator to check the suitability of the technical solution parameters. Indeed, defining appropriate scheduling properties may be difficult to achieve because hardware elements have physical limits (sensors sampling time, …) and software timing properties (priorities, worst case execution time, data transmission delays, periods …) are not obvious to determine. Moreover, you may encounter feasibility issues to satisfy the allocated timing budget if the System Engineer does not have these constraints in mind.
In this example of scheduling simulation, we can observe that some deadlines are missed , which was not obvious to determine in the initial allocation phase.
Feedback in SysML
The Systems Architect has to analyse the impacts of change requests from the proposed hardware/software solutions.
In this example, the systems engineer has performed an initial allocation of functions to logical components based on his initial knowledge. Then, the Hardware / Software Design team has performed analysis of existing components, devices and software components which exist as libraries. In our case, the analysis has shown that there is a mismatch between initially expected interfaces and provided interfaces by the selected sensor device (which implements Perception Subsystem). So, Hardware/Software design team performs a proposal to change initial allocation of FuseData function from Perception Subsystem to Flight Control Management subsystem.
So we update the Logical Architecture in SysML accordingly, as shown in the following figure:
Modified Logical Architecture after AADL analysis.
In addition, some timing budgets between subsystems can be adjusted regarding the feasibility of the proposed solutions when possible. Some changes in timing requirements or in interface definitions may have consequences on other engineering specialities or on other components. So, this impact analysis is not always straight forward (rather iterative).
Synthesis
In this article we have proposed a coupling methodology between SysML (a Systems Engineering language) and a hardware/software design language (AADL). Note that this method can easily be tuned for other languages with similar concepts (real-time, scheduling, …) such as AUTOSAR or UML MARTE.
The proposed method includes a definition of system requirements using SysML (including end to end timing requirements with the Functional Chains concept) and an initialisation a specialised model for hardware/software architectures (and associated network topologies). This translation allows to study the definition of the detailed design in the AADL language in order to benefit from suitable concepts and various timing analysis capabilities available in AADL toolboxes.
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.
Perspectives
To complete this present work, we will later refine the analysis of the mapping between Data Types defined at System Level and Resulting Data Types from the selected design (in particular, study the influence of selected implementation types like how to implement a Real value from system to a fixed point 32 bits data and verify the suitability of the selected implementation type regarding accuracy requirements).
In other further works, we plan to investigate how to create an initial physical architecture in SysML model by defining components libraries (ECUs, sensors, mechanical components, …), network topologies and how to convert this in AADL “world”. Then, we will propose adequate automations to perform the “bridge” from SysML to AADL based on mappings (still to refine).
We also intend to explore in more detail the other AADL language capabilities and associated annexes such as the behavioural annex (how to initiate AADL modes management from SysML behavioural description) or Error Modelling Annex (how to coordinate Systems Safety Analyses, Systems Engineering model and Safety Analyses for hardware/software design in AADL).
Enjoy MBSE !
Acknowledgements
We are warmly grateful for the support of the Ellidiss company and in particular Pierre Dissaux concerning the AADL modeling and simulation activity in the context of this article.
A special thanks to Jerôme Hugues for his advice and interesting discussions about these topics.
Next articles to come…
- November 2020 – Digital continuity between SysML and Modelica
- January 2021 – Co-simulation of SysML and other models through FMI
Part 6 – Digital continuity between SysML and Simulink
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. Focus is put on digital continuity with guidelines concerning coupling semantics and coupling automation between languages and tools.
In this article 6, we start from a System Definition model developed with SysML and we present an approach, which uses Simulink to define or refine part of the system’s behaviour such as the control loop of the system in its environment. We discuss 2 different ways of using Simulink.
Executive Summary
Context elements
In the previous articles (part 1 to part 5), we introduced a method using the SysML notation to support the following systems engineering activities :
- Formalization of functional needs
- Refinement and definition of systems requirements
- Early validation of stakeholder’s needs using Functional Simulation
- Definition of Functional and Logical Architectures
- Optimization of Logical Architectures
This article starts with the availability of a logical architecture for a case study called AIDA (coming from the Saint Exupery Research Institute). It is illustrated below:
From a Logical Architecture to a Detailed Definition using Simulink
Once a logical architecture has been defined, Systems Engineers start to communicate it to the various specialists involved in the system detailed definition (software engineers, mechanical engineers, command-control engineers, hardware engineers, …). These specialists will have to analyze the system requirements (including interfaces definition, expected behavior and associated performance) and will verify the requirements feasibility (is there a solution that can satisfy all of these requirements?).
In this article we focus on the Control Engineer. This specialist applies Control theory to one or several components of the system architecture and on its environment. He needs to define equations, reuse operators and generic components from libraries and toolboxes, use solvers and timed simulation, access optimization tools, use matrices based computations, etc. All these features are offered by math based simulation tools. Among these tools, we choose to restrict our focus to the usage of the MathWorks MATLAB/Simulink/System Composer suite as it is the most commonly used in the industry today, as far as we know.
Transition between SysML and MathWorks Simulink
In the next paragraph we detail a process to refine the definition of internal control. It contains the following steps:
- Definition of interface requirements in the SysML model,
- Export/translation of data to the Simulink (and SystemComposer) tool,
- Refinement of the interfaces and of the expected behavior in the Simulink model thanks to the component libraries and the support of simulation,
- Feedback to the Systems Architect about changes or refinements needed on system requirements and on the system architecture,
- Impact analysis of the change requests and update of the system definition model.
Transition from the SysML Logical Architecture to a Simulink behavioral model: the “traditional” approach
In this first approach, the Logical Architecture of the SysML model is translated into a Simulink model while preserving the allocation of system functions to logical components (subsystems). Simulink component libraries are used to refine the functional behavior. Then, the time-based simulation is used to verify that interfaces between system functions and between subsystems are consistent, and that it exists a solution that can satisfy the system functional and performance requirements. The interface definitions can be confirmed or refined by the control engineer.
Transition from the SysML Logical Architecture to a Simulink architecture model: the “new” System Composer approach
In the second approach, we still transition to Simulink but with 2 different steps and usages of Simulink. First we use System Composer (Simulink facet) to characterize and assess the architecture, thanks to features like multi-views, filtered view and analysis. Second, we use the “more traditional” Simulink component libraries to refine the function’s behavior.
The expected benefit of using the System Composer facet is a better separation of concerns: in the first step, the logical architecture can be characterized with the support of stereotypes on ports or on connectors, and assessed with the support of analysis features like “dynamic consistency checks of interfaces”. In the second step, the different components and their allocated functions can be refined, especially for the behavior, with the support of a wide diversity of generic component libraries, patterns and other useful features.
Note: each step has its own interest and may be performed by different users with different experiences.
Application on the AIDA case study
To illustrate and give elements of comparison between these 2 scenarios, we use a simplified model of control for the trajectory of an Unmanned Aerial Vehicle (UAV) based on the AIDA case study developed at the St-Exupery Research Institute. The AIDA Logical Architecture in SysML has been recalled in the context at the beginning of this article. Here we put the focus on the control loop between the perception subsystem, the Flight Management Subsystem and the Thrust Management Subsystem.
The goal is to control the actual position of the UAV to fit the expected trajectory around the aircraft. Therefore, one must find the right control parameters so that the UAV can follow the expected trajectory within a minimum error margin (that shall be defined in the performance requirements).
Simulink model initialisation
First, we define the scope of the transformation between the SysML logical architecture and the Simulink Model because we do not need to translate the full SysML model. We restrict the scope of this transformation to the sole functions and components useful for the UAV trajectory control loop (including the Air / Terrestrial Gravity model to reflect the physical environments effect on the control loop).
Note: in this SysML model, ports have been split (for instance current x and current y which rely on a Current Position flow) in order to be able to use the automations available in the tool.
Concerning the specification of the interface types and units, the SysML tool (Cameo Systems Modeler) provides access to the ISO 80000 Standard Units :
Translation of the logical architecture from SysML to Simulink/System Composer
The SysML logical architecture can be translated to the MathWorks Simulink modeling environment through two different methods:
- With System Composer:
With this method, it is possible to create a logical architecture semantically equivalent to the SysML model (same components and interfaces) as illustrated below:
One of the main benefits of this approach is the preservation of the stereotypes initially defined in the SysML model. For example, in the Functional Architecture model of our case study, we have defined the following stereotypes on function inputs and outputs: Information, Energy, Material.
Within System Composer, it is possible to define the same stereotypes and apply them to the System Architecture (functions or component interfaces) :
System Composer also offers a feature to filter different views of the same system architecture, which is very useful to ease the architecture reviews:
- Without System composer, using direct transition from the SysML tool to Simulink:
With this method, we can use some automations available out of the box in Cameo Systems Modeler (the SysML tool we have used) to create the Simulink Model skeleton from the SysML filtered model (model filtered with the UAV trajectory scope).
If data types and units have been specified in SysML, the automated transition propagates the data types and units in the Simulink model:
But without system composer, the additional semantics defined in the SysML model through the stereotypes are lost.
In both cases (with or without system composer), the resulting model contributes to the specification for the control engineer.
Simulink model refinement and simulation
Next, we complete the functions behavior with existing assets/knowledge in control such as PID controllers and we refine the associated parameter values thanks to the support of the simulation.
Change requests on requirements and architecture
Once the simulation seems to satisfy the requirements expressed at the logical level, it is possible to derive new lower-level requirements. For instance, it may be possible to add requirements on stability, or on expected control accuracy. The PID’s parameters can be finalized only in a physically realistic environment. However, the simulation gives an idea of the feasibility and and of the range of values to be implemented later.
Feedback in SysML
The Systems Architect has to analyse the impacts of change requests from the control engineer. Some changes in requirements or in interface definitions may have consequences on other engineering specialties or on other components. So, this impact analysis is not always straight forward.
Discussions on the two possible transitions and synthesis
This discussion is based on the use of the following tools and configurations:
- Cameo Systems Modeler (CSM) V19SP4 (SysML tool)
- MATLAB/Simulink 2020a
From SysML Logical Architecture to Simulink with the “traditional” (direct) approach
From SysML Logical Architecture to Simulink with the “System Composer” (new) approach
Synthesis
If your MBSE method is still in the definition stage, and if there is a need to go from SysML logical architecture to Simulink in order to benefit from mathematical-based simulation tools, it is clear for us that System composer is the right target from SysML. System Composer is the MathWorks tool that can preserve the SysML stereotypes put on the logical architecture (components and interfaces) and thus provides good support for architecture views and analysis in the Simulink environment. As soon as we can get some automation to support this transition between SysML and System Composer and some features to check in a static way the consistency of interfaces, we strongly recommend this way of transitioning from SysML to Simulink.
Else, in case you need to go from SysML to Simulink today, with the capabilities provided by Cameo Systems Modeler V19SP4 and MATLAB/Simulink 2020a, it is probably more efficient to use the “traditional” (direct) transition from SysML to Simulink, thanks to the automations that exist to support part of this transition.
Perspectives
In this article we have discussed the transition from a Logical Architecture formalized in SysML, to a Simulink model limited to the structure (components, their allocated functions, and their associated interfaces). Note that export from Cameo Systems Modeler to Simulink (with direct transition) also supports the translation of behavioral elements such as constraint blocks and state machines. Those aspects will be detailed in a future article.
Concerning multi-physical aspects, we plan to explore the usage of the SysPhs standard which is available in Cameo System Modeler through the SysPhsLibrary to support the automated transition of physical elements (structure and behavior) to MathWorks tools.
Additionally, we plan to explore in further detail the change analysis process that is performed when there are updates of the System Logical Architecture in the SysML model, and the possible consequences on the Simulink model. We will focus on the method but also on the tools able to support the difference/merge between SysML and Simulink models.
Finally, we will address in a future article (planned for January 2021) how to perform co-simulation between a SysML behavioral model and other behavioral models using the FMI for Co-Simulation standard.
Part 5 – Coupling optimization of logical architecture using genetic algorithm
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 architecture 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.
In the previous article, we explained how it is possible to define a Logical Architecture from a Functional architecture, using an allocation matrix between functions and logical components.
In this article, we go a step further by extracting the coupling metric between functions from the Functional Architecture (using an N² diagram technique) and using an optimization algorithm to minimize the coupling between logical components.
It is possible to consider several criteria with this method such as end to end latency requirements on interfaces. In this case, the algorithm tries to find the best solution that satisfies the coupling minimization, allocation constraints, and also timing constraints. In this article, we will focus on coupling minimization only.
Minimizing the coupling between components, a good systems engineering practice!
Among Systems Engineering best practices, as stated in many standards, it is key to minimize the coupling between the sub-systems in order to master the product complexity. For instance, in the IEC 61508:2000 we find:
“The interfaces between subsystems are kept as simple
as possible and the cross-section (i.e. shared data, exchange of information) is minimised.“.IEC 61508:2000 – Functional safety of electrical/electronic/
programmable electronic safety-related systems – Part 7:
Overview of techniques and measures
Are there any techniques or methods to support systems architects in minimizing the coupling between components?
Yes, to achieve such minimization, a well-known method consists of using Coupling Matrices (also called N 2 diagrams) and then reorganize them to identify architectures with minimal coupling.
Let us first explain how an N² diagram is defined, and let us illustrate that explanation with a case study. Secondly we will focus on the computation of the N² diagram to identify coupling optimization.
The coupling between components concerns the dependencies between the components. As explained in the previous article (part 4), the dependencies between the logical components mainly stem from the functional interfaces. So it is no surprise that we first start with the functional dependencies, use them to compute a coupling metric, and finally suggest an allocation of functions to components that minimizes the coupling.
Introduction to the N² diagram method
The N 2 chart, also referred to as N 2 diagram, N-squared diagram or N-squared chart, is a diagram in the shape of a matrix, representing functional or physical interfaces between system elements. It is used to systematically identify, define, tabulate, design, and analyze functional and physical interfaces. It applies to system interfaces and hardware and/or software interfaces.
[2] Wikipedia: https://en.wikipedia.org/wiki/N2_chart
In the previous article, we explained how it is possible to define a Logical Architecture from a Functional architecture, using an allocation matrix between functions and logical components.
Here below is an example of an N² diagram for a project with 9 functions that have dependencies.
In this matrix, the “1” represents an existing interface between the function of the concerned row and the function of the concerned column. The “0” indicates that there is no relation between those functions. In this example the matrix is symmetric, indicating that all the links are bi-directional. This is not the standard rules of the N² chart, which are better explained by the following figure.
Illustration of how to read an N² diagram
The placement of the “1” (above or below the diagonal) determines which function is the source and which function is the target of the link.
The use of a coupling matrix is mentioned by the INCOSE SE handbook as a useful practice :
Coupling matrices (also called N 2 diagrams) are a basic method to define the aggregates and the order of integration (Grady, 1994). They are used during architecture definition, with the goal of keeping the interfaces as simple as possible… Simplicity of interfaces can be a distinguishing characteristic and a selection criterion between alternate architectural candidates. The coupling matrices are also useful for optimizing the aggregate definition and the verification of interfaces.
Systems Engineering Handbook 4th edition 2015 in chapter 4.4.2.6 Coupling matrix
From this matrix we can compute a coupling value regarding the interfaces defined between the Logical Components (deduced from the interfaces between functions allocated to these components). The coupling value represent an evaluation of the coupling complexity between logical components based on the following formula derivated from software coupling metrics in Dhama, “Quantitative models of cohesion and coupling in software”, Journal of Systems and Software vol; 29, Apr, 1995
`"Coupling"(C_(M_(k))) = 1-1/(d_(i)+2*c_(i)+d_(o)+2*c_(o)+w+r)
`
`"Coupling Value" (C_(v)) = sum_(k=1)^n[C_(M_(k))]
`
where the parameters are defined as follows:
- `M_(k)`: logical component under consideration
- `d_(i)`: number of input data parameters
- `c_(i)`: number of input control parameters
- `d_(o)`: number of ouput data parameters
- `c_(o)`: number of ouput control parameters
- `w`: number of modules called (fan-out)
- `r`: number of calling the module under consideration (fan-in)
Now, let us see an illustration on a case study.
A sample case to illustrate the definition and use of the N² diagram
Our sample case is based on a case study elaborated within IRT St-Exupery called AIDA (Aircraft Inspection by Drone Assistant). This example was initially developed in a Capella environment and is available at https://sahara.irt-saintexupery.com/AIDA/AIDAArchitecture. For this article, we have translated the sample case to the SysML language.
In the previous article (part 4), we used this sample case to show how we can initialize the logical architecture from the functional architecture with the use of an allocation matrix between functions and logical components. In this article, we use it again, but this time we explain how to use optimization techniques to determine automatically the “best fit” to minimize the coupling. In other words, we want to define one or several possible allocations (illustrated by allocation matrices) between functions and logical components that minimize the coupling between the components.
Let us see this in practice.
N² diagram from the Functional Architecture
In the previous article (part 4) we showed a possible functional architecture elaborated for this sample case. We recall it in the figure below:
For this functional architecture, we can extract 2 N 2 diagrams for the leaf functions by analyzing their dependencies:
- Data/energy/material flows
- Control (Enable/Disable or Trigger) flows
The results are displayed in the 2 figures below:
N² matrix for data/energy/material flow
N² matrix for control flow
Now we want to define a logical architecture that minimizes the number of interfaces between its subsystems.
Optimization of allocation between functions and logical components
From a functional N² diagram to a logical architecture…
To perform optimization between components, we analyze the functions to functions coupling matrices introduced previously and we use them as input for a genetic algorithm presented later in this article. This algorithm will progressively iterate over different possible logical architectures and will calculate the coupling between components. In the end, it will select the architectures that minimizes the coupling metric.
Let us look at a possible logical architecture. How do we define it? We simply define the components (or modules) as groups (or partitions) of functions.
As an example, in the figure below, the orange color part of the figure illustrates an allocation (or partition) strategy of the 9 functions into 3 modules: M1, M2, and M3. In this figure, we are not interested in the internal structure of each module, which is why we do not represent the functional interfaces between functions of the same module. However, we want to see the functional interfaces between functions allocated to different modules because it will give us the logical interfaces. If we focus on the M3 module, we see in green the M3 inputs, and in blue the M3 outputs.
Example of coupling analysis for 3 modules (green highlight on Module 3 inputs, blue highlight on Module 3 outputs)
Note: we recommend reading the previous article for more details on the relationships between the functional architecture and the logical architecture.
From this matrix with modules, we can now compute a coupling metric regarding the interfaces of the modules.
Using a Genetic Algorithm to optimize the allocation of functions
Genetic algorithms are algorithms inspired by evolutionary principles. The main purpose of this kind of algorithm is to explore the solution space of a problem in order to satisfy a set of criteria. The general principles of genetic algorithms are illustrated on the Figure below.
Genetic Algorithm Process
The first step is to create randomly a set of initial subjects (1). This set is called the initial population. The initial population is composed of subjects each representing a possible set of functions allocations. Then, the algorithm evaluates each subject using a fitness function (2). This function makes it possible to give a value, or a rank, to a subject, to estimate its proximity with the “optimal” solution. In our case the fitness function is the coupling equation C. The candidates that are too far from the desired solution are deleted (3).
Then the algorithm evaluates the number of remaining subjects. For instance, if the population size is less or equal to 4, then the algorithm returns the best solution amongst the 4 remaining subjects. On the contrary, if the population size is greater than a specific threshold, then the algorithm continues. And this is where things become interesting…
Here begins the core biomimicry part of the genetic algorithm: the remaining subjects cross over, i.e. they exchange their genes to produce new subjects (4). Finally, the newly created childs are subject to mutation (5): part of their characteristics randomly change. Cross over and mutation are usefull to stay away from local optimum by spreading new subjects through the solution space.
Genetic algorithms are configurable using the following set of parameters:
- Initial population size – a key parameter to ensure enough coverage of the solution space at the begining
- Max generation number – parameter to ensure that the algorithm ends even if the population grows.
- Percentage of survivor – the percentage of the worst subjects to delete
- Percentage of parents – the percentage of subjects that cross over
- Percentage of child to mutate – the percentage of new subjects to mutate after the cross over
- Percentage of gene to mutate – the percentage of genes to mutate for each new subject
What about constraints on allocations?
In practice, systems engineers already have good ideas of some allocations between functions and components or have constraints that exist on fixed allocations (for different reasons including security, performance…). So the genetic algorithm shall consider these first predefined allocations.
We have defined our genetic algorithm to be able to take as input a predefined partial allocation matrix with existing constraints. These constraints are considered by the algorithm that will then define possible logical architectures respecting the given constraints.
Selection of the “best” logical architecture that minimizes coupling
The genetic algorithm presented previously gives us one or several possible logical architectures that minimize the coupling between components while conforming to the functional architecture and eventual allocation constraints. We can use the results to generate or complete the allocation matrix between our functions and the components as presented below.
Allocation Matrix
Thanks to the completion of this allocation matrix, we can deduce a logical architecture, as explained in the previous article (part 4) that shows the different logical subsystems with their allocated functions and keeps the functional flows coming from the functional architecture.
Logical architecture after allocation of functions using GA
Can we automate some of the steps presented above?
Yes!
At Samares Engineering, we have investigated automation of the different following steps :
- Extracting the initial N² Matrix from the functional architecture (for both data/energy/material and control flows)
- Exploring candidate logical architectures (functional to logical allocation) to automatically find the candidate architectures where the coupling metric is at a minimum value using the genetic algorithm.
- Defining allocation constraints (for example UAV control position function can be forced to be allocated to the Flight Control System).
Enjoy MBSE!
Acknowledgements
We are warmly gratefull to Yash Khetan and Minghao Wang for their contribution. It was great to work with both of you. See you!
Next articles to come…
- 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 functional simulation
- July 2020 – Consistency between functional and logical architectures