About sébastien DUBE

Sebastien has a master degree (engineer) in Embedded Systems (Electronics, Embedded Software, Control, ...). He has 20 years experience in embedded systems engineering (Systems Engineering, Safety Critical Embedded Software Development, Project Management, Quality, ...) in many industrial sectors (Automotive, Railway, Defence, Buildings, ...) and he has contributed to several industrial standards such as AUTOSAR or FMI. He is now Systems Engineering expert at Samares-Engineering and is active member of AFIS community.

Using Unified Architecture Framework (UAF) for a Space Mission Modelling

Accelerate Systems Design

Introduction

This article explores the application of the Unified Architecture Framework (UAF) in the context of aerospace, specifically focusing on mission engineering for a Mars Exploration and Sample Return mission. 

With the increasing complexity of space missions, the need for a robust framework that can manage various interrelated systems and organizations is more critical than ever. UAF, with its specialized viewpoints and elements, offers a structured approach to modeling Systems of Systems (SoS), ensuring that all aspects of the mission are aligned with the broader strategic objectives. 

Systems of Systems definition (SoS) according to INCOSE Systems Engineering Handbook Edition 5:

A set of systems or system elements that interact to provide a unique capability that none of the constituent systems can accomplish on its own. 

To perform mission analysis, it is crucial to define the different aspects, including strategic goals for the overall mission, expected capabilities, different phases and steps, expected tasks to be performed and interactions between different the systems and the human operators needed to achieve the expected capabilities at the mission level. 

UAF Standard

Overview of UAF standard

The Unified Architecture Framework (UAF) is an architecture framework proposed by the Object Management Group (OMG). This standard has been built from a long history of different architecture frameworks (NAF, DoDAF, MoDAF, …) defined by different organizations and governments. These different frameworks all present similar concepts; the intent of UAF is to provide a standardized representation compatible with all of these frameworks that can be used for architectural description in Industry, Government, and Defense Organizations and thus can adapt to different needs. The origin of the UAF standard is illustrated in the figure below (from OMG): 

Overview of UAF relation/origin to other frameworks from OMG UAF Wiki 

In the domain of aerospace engineering, UAF provides significant advantages, which are particularly valuable from the mission engineering point of view. 

UAF makes it possible to handle the task of accurately storing, representing, analyzing and formatting the concepts and data related to the coordination of various systems during their duty. In a space mission context, these systems are often spacecrafts, communication networks, ground control stations, etc. They need to perform as expected and to be correctly interfaced. 

UAF has the ability to represent different levels of abstraction: through the different domains the user is invited to gradually decompose their problem and structure their solution. The framework benefits from enhanced traceability between domains, supporting decision-making, and ensuring that all mission components work harmoniously toward the successful completion of mission objectives. 

UAF concepts

The Unified Architecture Framework defines ways of representing an enterprise architecture that enables stakeholders to focus on specific areas of interest in the enterprise while retaining sight of the big picture. 

UAF is well documented on the OMG website: https://www.omg.org/spec/UAF/1.2/About-UAF/

OMG Specifications are free to implement and UAF is no exception: many tool vendors such as CATIA, Sparx Systems, and PTC […] implement UAF in their own tool. 

For this article, we will illustrate with the Magic System of Systems Architect V2022 tool from Dassault Systèmes.

Currently, the latest version of UAF is V1.2. However the upcoming release of SysML V2 will quickly be met by the release of UAFML V2, taking into account, apart from the new KerML kernel, a solid implementation of the concepts of the DoD Mission Engineering Guide (MEG_doc). 

Normative specification documents

  • UAF Domain Metamodel (DMM): establishes the underlying foundational modeling constructs to be used in modeling with UAF. It provides the definition of concepts, relationships, and UAF Grid view specifications. The UAF DMM is the basis for any implementation of UAF including non-UML/SysML implementations. 
  • Unified Architecture Framework Modeling Language (UAFML): provides the modeling language specification for implementing the UAF DMM using UML/SysML. 

Informative specification documents

  • UAF Sample Problem, Appendix B, using a search and rescue example. 
  • The Enterprise Architecture Guide (EAG) for UAF, Appendix C, provides a structured approach to construct an enterprise architecture (EA) using the UAFML. 

UAF proposes some different viewpoints to support different domains during the mission analysis (defined as part of the Concept of Operations (ConOps)) which are illustrated in the figure below: 

UAF domains simplified view 

The framework proposes to decompose the architecture using different domains. Here are explanations for the main ones: 

  • Strategic: This domain defines the main Strategic Goals, expected Capabilities , Strategic Phases of the mission, project or Enterprise level. Finally, at this stage, it is possible to define the specific Measures of Effectiveness (MoE) to specify the required efficiency of the mission. 
  • Operational: This domain defines the operational structure and behavior, including identification of “Performer” Entities (Stakeholders) and their associated activities and actions to support the mission execution and completion of the overall capabilities. 
  • Services: This domain defines services to fulfill the capabilities. Services may be distributed over different stakeholders and systems. 
  • Resources: This domain defines different physical resources which contribute to the mission,. A resource can be composed of systems, natural resources, components, etc. 
  • Personnel: This domain defines human actors, their interactions, and organizational dependencies. 
  • Actual Resources: This domain defines a specific solution class which uses efficient collaboration between human actors and systems to realize the expected mission goals and associated capabilities. 
  • Project: This domain defines the project organization needed to execute the mission including the associated project roadmaps. 

The modeling of these domains is supported by a “grid” view (from UAF V1.2 – Appendix C) illustrated below: 

UAF Grid view from UAF V1.2 – Appendix C

A simplified version of the related concepts (from UAF V1.2 – Appendix C) is presented below:

Simplified view of the UAF DMM from UAF V1.2 – Appendix C

UAF vs SysML

In the context of Systems Modelling, there are other existing languages dedicated to the System of Interest definition (such as SysML, or ArcML). 

As stated before, implementations of UAF may be based on other language notations such as SysML, in particular when using UAFML, which is a SysML specialization (for example using the tool Magic System of Systems Architect).  UAF has been designed to support Enterprise Architecture/Mission level and Systems interactions (with definitions for involved functions, resources and personnel), whereas SysML is a generic system definition language providing the key concepts and semantics for Requirements, Structure, Behavior and Parametric definitions. However, SysML on its own does not propose any specific structured framework (this should be completed by following a specific methodology).  

As UAF is wide and proposes many concepts which might be complex or not useful for System of Interest definition, we suggest to limit the usage of UAF to the mission level as a support for Mission definition down until the selection of the System of Systems architecture and associated needs & requirements for each individual systems. Then, we recommend to use Systems Engineering languages completed with the appropriate methodology to perform definition of each System of Interest (SOI) using separation of concerns between Needs Analysis & Solutions. 

When both enterprise and system-level perspectives are essential, UAFML and SysML can complement each other. UAFML provides the broader context, while SysML delves into the specific details. 
 

In this article, we propose to address the definition of the Mission level (ConOps) with the UAF framework for the MARS exploration mission. Then, we will propose in a second article the definition of one of its systems (Exploration ROVER) using the SysML language and our internal Samares methodology and profile.   

Application on a case study – MARS Exploration mission

Mission Context

The Mars Exploration and Sample Return mission model developed using UAF is an example of how this framework can be applied to manage the complexity of a multi-system, multi-organization space project. The modeled mission is strongly inspired by the Mars 2020: Perseverance Rover and Mars Sample Return missions developed by the National Aeronautics and Space Administration and the European Space Agency. These missions are illustrated in the pictures below: 

Illustration of NASA Perseverance ROVER Mission (Mars Exploration)
Illustration of ESA Mars Sample Return Mission

Both of these missions require collaboration between different space systems (Mars landing system, Orbiter, Perseverance Rover, Rocket, ..) and also with the Ground Operations systems operated by human actors to monitor and control the execution of the Mission. 

We apply UAF to the MARS Exploration mission and capture the main mission goals, expected mission efficiency, the contributions of the various systems and human actors involved, their interactions, and how they contribute to the overall mission objectives through the use of some of the proposed viewpoints as illustrated in the figure below: 

Selected UAF domains and views for the Mars Exploration & Sample Return missions

Strategic Analysis

As stated in the UAF overview, the Strategic Analysis intends to define main strategic goals and expectations from the mission point of view. To perform this, we start by identifying the expected capabilities and associated relations with the Strategic Phases from the mission perspective: 

Capabilities required for Mars Exploration
Capabilities required for Sample retrieval
Strategic Structure of Mission Phases and their associated Capabilities

In these diagrams, we have decomposed the different capabilities expected from MARS Rover mission and Sample Retrieval defined as capabilities. Then, we have decomposed the mission in different strategic phases : 

  • For takeoff, travel and landing on Mars (context of ROVER Perseverance NASA Mission) 
  • For exploring the Mars surface using the Rover (context of ROVER Perseverance NASA Mission) 
  • For launching a new rocket and appropriate systems to retrieve samples on Mars and come back to earth. (context of Mars Sample Return ESA Mission) 

In fact, Perseverance ROVER mission and Pars Sample return are 2 different missions but using some common systems (in particular ROVER). That is the reason why, we have decided to decompose them as 2 different phases (occuring at different time frame). 

Finally we used the UAF Strategic Viewpoint to define some associated Measures of Effectiveness and define some requirements for specific capabilities as illustrated below: 

Strategic Contraints Definition Diagram

Operational Architecture

The Operational (Op) viewpoint intends to provide a description of the requirements, operational behavior, structure, and exchanges required to support (i.e., exhibit) the capabilities. 

We first started with Operational Entities (OperationalPerformers) identification which contribute to the mission. It can be noticed that the identified performers are defined as generic entities and do not focus on their specific technology. We also define the interactions between entities: 

Operational Structure
Operational Internal Connectivity

Then, we defined the associated Process flow involving the different Entities in the diagram below:

Operational Process Flow

In order to verify the adequacy of these Process activities to support the defined capabilities, we established the following traceability matrix: 

Traceability matrix between Capabilities and Processes

Resources Architecture

The Resources (Rs) domain intends to define the solution architectures to implement operational requirements. It captures a solution architecture consisting of resources, e.g. organizations, software, artifacts, capability configurations, natural resources. In our case study, we defined the physical structure and the expected systems interfaces of one of possible solution class: 

Resources Internal Connectivity for overall mission

Then, we define the mapping between operational performers and Resources and also responsibility sharing between humans and physical resources (in particular for the Operations Center activities) :

Physical Resources to Operational Performers Mapping
Relations between Resources, Processes and Organization/People

Mission Requirements

As a result of this analysis, we established a requirement set for one of the specified systems – The Rover Transport – in the diagram below: 

ROVER Mission Requirements

This requirement set will be used as the starting point to define the various Systems of Interest (SoI) that collaborate for this mission. Each of those SoI will start or adapt their definition to comply with this requirement set. They will use SysML based method and tools. This will be detailed in a future article. 

Verification & Validation using Simulation

Once the architecture of the Mission is finalized, we can define the main physical equations and perform a tradeoff analysis to explore the performance of different solution classes. To do this, we established a Parametric diagram that can be seen below: 

ROVER Transport to Mars equations

Then, we can define a specific Graphical User Interface to simulate the mission efficiency and visualize the results:

Graphical User Interface
Simulation Results

Conclusion and future work

With this article, we have illustrated the usage and benefits of UAF to define the Concept of Operations (ConOps), including the overall mission analysis which describes the collaboration between different systems to achieve a common goal. To complete this work, we would like to further explore the following things: 

  • Explore the benefit of additional UAF viewpoints, including Personnel, Services and Actual Resources
  • Complete the definition of Measures of Effectiveness (MoE) and their relations/equations with the System’s Measures of Performance (MoP) 
  • Perform Design Space Exploration using the MDA-MDO technique to define and assess the efficiency of different solution classes  
  • Trace our UAF model with a System of Interest model (Rover Exploration system) 
Acknowledgements
We are very grateful to Louis Brial for his internship work and his contribution to this article and its associated contents.  

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:

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.

  • EnvironmentAir 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

  • This article focuses on performing Software and Hardware co-design. In fact, satisfaction of timing requirements by selected design is highly influenced by end to end architecture and delays, execution times induced by selected devices, processors, network topologies and software scheduling properties. These elements cannot be analyzed independently and should be analyzed as a whole.

  • SysML is a good language to define requirements and it is recommended to define timing requirements (timing budgets) at system level. Then, it is possible to verify the compliance of the selected detailed architecture using analysis languages such as AADL.

  • AADL is an appropriate (and industrial domain agnostic) language to define the hw/sw architecture of embedded real-time and safety critical systems. It offers capabilities of analysis related to hw/sw architecture properties (latency, scheduling, …) and makes it possible to verify the suitability of the selected design to achieve the System Requirements.    

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 :

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

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

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

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

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

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

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
  • 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

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

  • This article focuses on Control Engineering. This discipline requires analyzing / detailing several interdependent elements defined in the System Architecture (such as control functions, input signals time/frequency response, external environment behavior models fidelity to the real physical environment, …) to verify the consistency of the interfaces and verify that the behavior complies with the requirements. Those activities require usage of existing knowledge and assets available in mathematical-based simulation tools like MathWorks Simulink.

  • The communication between the Systems Architect and the Control Engineer is key to get a fast and clear transition between the SysML and the MathWorks MATLAB/Simulink models.

  • There are 2 different ways to transition from SysML to Simulink. The “new” way uses System Composer to initialize an architecture model from the SysML model. System Composer can preserve the stereotypes defined in SysML and provides features useful to assess the architecture like “multi views” and “architecture analysis”. This is the way we recommend for the future.

    Today, some important features like “static consistency check of the interfaces” are still missing, and there is no automation to support the transition between SysML and System Composer. So the “traditional” transition to Simulink, even if it does not preserve SysML stereotypes and does not provide features to characterize and assess the architecture, remains useful. And there is some automation to support this transition. 

  • When using Simulink, the Control Engineer verifies the system architecture, the interfaces, and the behavior, to ensure that the requirements can be satisfied. If this is not the case, the Control Engineer shall propose a change to either adapt the architecture or refine the requirements. This change will be managed by the System Architect in the SysML model and it should be reflected in the Simulink model in order to maintain the consistency of the overall system definition.

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 :

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:

  1. Definition of interface requirements in the SysML model,
  2. Export/translation of data to the Simulink (and SystemComposer) tool,
  3. Refinement of the interfaces and of the expected behavior in the Simulink model thanks to the component libraries and the support of simulation,
  4. Feedback to the Systems Architect about changes or refinements needed on system requirements and on the system architecture,
  5. 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

  • Interests of this “traditional” transition:

    1. It is possible ot perform digital continuity between some SysML tools and Simulink: during a simulation session started in CSM (the SysML tool), the Cameo Simulation Toolkit (CST) can call a Simulink model from a SysML block. In practice, CST gives the hand to Matlab, which runs the Simulink model. A the end of the Simulink model function, CST can retrieve data from the Simulink model and make it available for use in the SysML model or visualization in the simulation console.
    2. Co-Simulation of SysML and Simulink models using FMI standard (will be detailed in a future article): both SysML behavioral model and Simulink behavioral model are simulated concurrently through their respective solvers (in fact there is an orchestrator that drives both simulations time step by time step)
  • Issues with this “traditional” transition:

      1. Stereotypes defined in the SysML model are lost after translation into the Simulink model. There is no simple way to retrieve those stereotypes, even with additional automation, because the Simulink meta model does not handle stereotypes.
  • Additional remark :

    Most of SysML tools provide automation to generate a Simulink model from a SysML IBD representing the logical architecture, but the translation of buses from a SysML Logical Architecture model is generally not implemented -> An automation could be developed to fix this issue.

From SysML Logical Architecture to Simulink with the “System Composer” (new) approach

  • Interests of this “new” transition:

      1. Ability to keep SysML stereotypes when translated into System Composer and to use them to create several architectural views (for isntance electrical view, mechanical view, control view…)
      2. Assess the architecture in terms of consistency of interfaces thanks to the availability of stereotypes put on ports and connectors and the use of dynamic checks.
  • Issues with this “new” transition:

      1. Static consistency between ports is not ensured today (will come in a future version).
      2. No transformation available between CSM and System Composer.
        1. No automation available out of the box in CSM V19SP4 to export a SysML model as a System composer model.
        2. No available import of a SysML model from System composer so far.

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.

L’attribut alt de cette image est vide, son nom de fichier est image-22.png.

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 for Functions Allocation

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:

  1. Initial population size – a key parameter to ensure enough coverage of the solution space at the begining
  2. Max generation number – parameter to ensure that the algorithm ends even if the population grows.
  3. Percentage of survivor – the percentage of the worst subjects to delete
  4. Percentage of parents – the percentage of subjects that cross over
  5. Percentage of child to mutate – the percentage of new subjects to mutate after the cross over
  6. 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

 

Go to Top