Part 4 – Consistency between functional and logical architectures

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

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

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

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

Why do we need a logical architecture?

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

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

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

A320 Pre-Flight Checks Procedure

The drone system contains 9 top-level functions:

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

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

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

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

AIDA Top Level Functions

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

AIDA Functional Architecture Details

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

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

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

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

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

The logical architecture as an intermediate layer

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

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

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

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

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

  • Mission management subsystem
  • Propulsion subsystem
  • Flight management subsystem
  • Vision Subsystem
Initial logical architecture

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

How do we create the logical architecture?

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

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

The next chapter explains this in detail.

Consistency between the Functional architecture and the logical architecture

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

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

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

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

First allocations

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

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

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

Logical Architecture result after allocations

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

Conclusion

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

Can we automate some of the steps presented above?

Yes !

Overview of the automation

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

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

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

Simulation in practice (video)

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

Enjoy MBSE!

Next articles to come…

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

Previous articles in the series

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

Part 3 – Early validation of stakeholder needs through functional simulation

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.

This third article puts a spotlight on a way to validate the stakeholder needs. We show how it is possible to use a modeling approach to structure and refine functional needs into a functional architecture. We also show that it is possible to simulate this functional architecture against operational scenarios expressed by the stakeholders. The simulation allows us to monitor some of the key system parameters and provides good support for validating stakeholder needs early in the development cycle.

Functional architecture is useful to support early validation of the system!

Sometimes we hear from some systems engineers that only the physical architecture is really useful to support validation. That is true if we target the end-product. At this stage, we need to get an architecture as close as possible with the reality (a characteristic sometimes called “fidelity”) to limit errors and wrong conclusions from the results of the simulation. But if we focus on the validation of functional requirements, it is not a good idea to wait too long before starting validation because we may be working with a wrong or incomplete capture of functional needs. And we can already do a lot to verify these needs early in the development cycle, even with a purely functional (virtual) representation of the end product.

In order to reach early validation, there are different activities to perform:

  • The identification of the validation objectives
  • The identification of the system functions and their functional interactions with system operational context
  • The internal functional flows to support complete functional chains starting from operational scenarios.

Identification of the validation objectives

First, we need to identify what we want to validate. The most important thing to keep in mind is the rationale of why we developed our system of interest: the mission(s) to support! So let us focus on the mission(s) of our system of interest and check that our system is able to support the mission profile (set of phases and states) and its expected performance in the operational context. You may think that we need to know the complete physical architecture to measure this performance. Yes for the final detailed figures, but we can already approximate some elements and get a first rough idea without the full list of organs. We will see in the next paragraphs that we can add some behavior to the functions and then we can reach good support for the calculation of the system performance.

Identification of the system functions and their functional interactions with the operational context

This activity consists in mixing two approaches: the engineering knowledge of the solution coming from systems engineers experience on one hand, and the needs expressed by the different stakeholders on the other.

The systems engineers will through their experience provide a set of functions often called “technical functions” because they come from the knowledge of the technical solutions/products commonly used in a similar context. The expression of needs coming from the various stakeholders will lead to what we call “service functions” or “required functions”. These functions are generally identified through a set of scenarios that cover the different lifecycle concepts. The functional architecture will arrange the functions so that we can support top-level required functions with technical functions as illustrated below.

Now let us see in practice how we can use a model-based approach to support these activities.

At the French Chapter of INCOSE , called AFIS, in the MBSE technical committee, we have created a working group to discuss the use of functional model simulation as a means to reach early validation of the system functional requirements. We quickly discovered that it would be useful to compare our different approaches through a common sample case. And we have chosen a connected washing machine for this exercise. It is a system that everyone knows, at least as an end-user.

We use this sample case to illustrate the suggested approach.

A sample case to illustrate the use of a functional model simulation as a means for early validation…

Our sample case is a connected wasching machine. The “connected” part means that you can start and monitor the progress of the washing through your smartphone.

The description is available online here: https://www.samsung.com/fr/washing-machines/front-loading-ww90m645opw/

Concerning the functional behavior, we are not specialists and we have extracted knowledge from this web site (in french): https://www.spareka.fr/comment-reparer/electromenager/lave-linge/fonctionnement

Focus on the mission and identification of the operational scenarios

Let us start by looking at the missions / use cases for this system of interest. We want to be able to wash clothes, either directly or remotely (from our smartphone).

According to these use cases we have 2 main scenarios that describe the interactions between house habitants and the connected washing machine. We use “UC diagram” to represent the different system missions and we use “Sequence Diagrams” to represent the interactions, as illustrated below:

Note: these sequence diagrams are simple and this is on purpose. We do not introduce advanced logics like loop, parallel, or alternatives to keep the diagram very simple and easy to review by end-users and customers who are not necessarily familiar with the SysML notation.

From an operational scenario to a validation scenario…

The different operational scenarios defined previously (through Sequence Diagrams) can be reused as skeletons for the future validation of the system. You may ask: “What is the difference between an operational scenario and a validation scenario?” A validation scenario is more detailed than the operational scenario. It contains the same list of interactions but also some additional elements:

  • Concrete values for the different stimuli sent to the system (from external systems or humans)
  • Some delays between interactions in order to reflect human behavior (a human is not a robot that can immediately trigger the stimuli one after the other)
  • Some observations about the system behavior during the mission

We can use an activity diagram to formalize a validation scenario. It can be translated from the operational scenario quite easily:

  • Each input message is translated into a “send signal action” so that we can send a signal to the system
  • Each output message coming back to the operator is translated into an “accept event action” that waits for the arrival of the signal.

Then let us see how we complete this scenario to allow some validation.

  1. The concrete values used as inputs for the stimuli are formalized with the “ValueSpecification” concept and are transmitted to the “send signal actions” through “object flow“. In the example shown below, we load 5 Kg of dirty clothes and 0,1 liter of detergent.
  2. The delays between the human interactions are formalized with the use of “AccceptTimeEvent” with a delay expressed in “relative” mode (after XX seconds).
  3. The observations are detailed in the next paragraph.
Translation of an operational scenario into a validation scenario with some complements

Identification of the functions

We start the identification of the functions by looking at the system operational context. It gives us the inputs and outputs of the system. We can use an Internal Block Diagram (IBD) to represent this context.

The system of interest seen as a black box in its operational context

Note: we distinguish different types of flows: information, energy, and Matter. We use SysML stereotypes (additional semantics to SysML concepts) in order to manage those specialized flows and associated ports. We can associate a given color and a given icon for each stereotype, which makes the reading easier. A legend is available on the top left of the diagram.

Then the functions are identified by following some simple patterns:

  • The interactions from our System with its context (physical environment, other connected systems, and human interactions) are encapsulated with interface functions that are in charge of managing those interactions.
    • in our sample case, we find “Manage Human interaction” and “Manage Water
  • The mission progress is managed by a dedicated function. In our sample case, it is called “Manage Washing Program
  • Finally, we add all the functions required to manage human interactions and to support the mission
    • In our case, we add “Store Water and Clothes” to ensure the human interaction concerning clothes
    • We add “Provide Washing Movement” to clean the clothes.

We represent the usage of those functions as “part properties” inside our System Of Interest (SoI).

Addition of “service functions” to the system seen as a black box

Note: the functions are all enabled by default in this diagram but some may be disabled by other functions in some conditions during system execution. The function adornment would then change with a new symbol as explained in the legend (top left of the diagram).

Support of service functions with technical functions

When we get a good idea of our service functions identified from operational scenarios and from the operational context, we get 2 options: either we are able to specify their behavior (to support functional simulation) or we consider that the function is too complex or has too many objectives and then we refine it with lower-level technical functions. In that case we use our engineering knowledge to identify those technical functions.

In our case, the “manage Water” function is still complex and needs to be refined into lower-level technical functions. From the website used to understand the washing machine behavior, we learn that we need several functions to manage the water. We need to manage the water level, to heat the water and to store the washing detergent. We connect these functions with the external environment (water supply and sewer, human interactions) . We use an IBD to show this refinement:

Observations of the SoI to reach validation objectives – support by function behavior

Now we want to ensure that we can observe our system in order to check that the system behaves as expected and supports the mission performance. Once we have identified all key parameters to monitor we will be able to define the functional behavior required to compute those key parameters and to carry them to the end-user.

What are the key elements we want to observe from our system of interest seen as a black box?

  • First, we want to see the mission progress for which the system is being developed. In our sample case, we want to monitor the state of the program over time: is it filling the water? washing the clothes? purging the water? spinning the clothes?…
    • We use a dedicated function to manage the mission states (as presented previously) and a state machine diagram to represent the different states and their transitions over time
    • This state machine can be simulated using the Cameo Simulation Toolkit as illustrated below
Simulation of the function ” manage washing program” formalized as a state machine diagram

Note concerning the colors:

The “Red” color represents the current active state during the simulation session.
The “Green” color represents all the states that have been simulated since the beginning of the simulation session.
The “yellow” color represents the current transition being triggered (if any)
  • Then we want to verify the Measures of Effectiveness (MoEs). These are the measures used to ensure that the mission is successful in its operational context. We want to be sure that the system will fulfill its mission with accurate performance. In order to do that, we need to monitor the key system parameters used to calculate the MoEs over time: water level, nb turns per minute, remaining time…
    • We use equations and parametric diagrams to bind the system key parameters with the equation parameters when there are continuous flows (like the water flowing in and out).
Equation for calculating the water level over time according to the flow of water
  • Concerning the water level management, we just need to focus on the modes of the function. This can be done through the use of a state machine. Transitions are triggered on key events that come from the control of the washing program steps. And for each “state” we define a simple behaviour with a simple “Activity” element (using the “DoActivity” to reference those activities).
  • Concerning the human interactions, we can use an activity diagram to represent the configuration of the program, as illustrated below:
Use of an acivity diagram to formalize a function behavior
  • Finally, we want to visualize the different MoEs in a synthetic way. We can use plots (provided by Cameo Simulation Toolkit) to show the different curves of the key parameters over time
Plots that show the evolution of key parameters over time

Finalization of the functional architecture

The system functional architecture is finalized by connecting all the system functions with the SoI operational context and with each other using internal flows.

3 kinds of functional flows

Each functional flow can be of 3 different kinds: information, energy or material. By using different icons and colors to represent those different kinds, it gives the reader immediate feedback and makes the diagram easy to read. The reader can easily focus on one given kind.

Functional architecture formalized as an IBD

We want the functional architecture to support simulation. It means that each function must have an associated behavior that can be executed (simulated). According to the function, we can use the different following behaviours:

  • State machine (introduced previously to represent the states of the function “Manage Washing Program” over time)
  • Parametric diagram (introduced previously to represent a differential equation with regards to water level over time)
  • Activity diagram to complete a state machine diagram or to specify some constant values as illustrated previously for function “manage human interaction”

Note: we can also use an opaque behavior to represent an external behavior such a Matlab function or Modelica equation or a Functional Mockup Unit (see FMI standard for more information about that).

Driving the simulation with graphical support

  • Finally, we may also want to drive the simulation using a Human Machine Interface (HMI) mock-up that reflects the future operations performed by the end user. In our case, a person can use his/her smartphone to drive and monitor the progress of the washing.
    • For this purpose we can use dedicated widgets provided by the Cameo Simulation Toolkit to represent the future HMI and bind some system states with panels or images as illustrated below:
HMI to drive and monitor the connected washing machine

Can we automate some of the steps presented above?

Yes.

We have created a plugin to automate the transformations between the operational scenarios and the validation scenarios. We still need to complete those validation scenarios but this is easy to do when the list of interactions has already been translated from the sequence diagrams.

We have also defined a dedicated functional architecture editor (called FAS for “Functional Architecture Synthesis”) that provides support for the choice of the different kinds of functional flows and that can create the function ports automatically when needed to ensure the encapsulation principle (all functional flows are passed through the ports of the parent function).

Simulation in practice (video)

Look at the video at the bottom to see 3 validation scenarios executed through model simulation.

3 validation scenarios grouped into one state machine

In the first scenario, we use the simulation console to monitor the key parameters’ values during the simulation in addition to the plots that show the progress over time.

In the second scenario, focus is put on the HMI used to drive the scenario (representing a smartphone). There is no use of the simulation console: both the control and the monitoring is done through this HMI.

The last scenario is a rainy day scenario. It shows that it is possible to describe dysfunctional scenarios and use them to see how the system behaves in abnormal conditions.

Enjoy MBSE!

Next articles to come…

  • July 2020 -Consistency between functional and logical architectures
  • August 2020 – Minimization of the coupling in the logical architecture
  • September 2020 – Digital continuity between SysML and Simulink
  • October 2020 – Digital continuity between SysML and AADL
  • November 2020 – Digital continuity between SysML and Modelica
  • December 2020 – 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

Part 2 – From textual requirements to model and to textual req again

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.

This second article puts a spotlight on the zig-zag between the top-level system requirements, often expressed as text, the system model that will be used to satisfy those requirements through functional and physical architectures, and the lower-level system requirements that can be partially derived from those architectures. We detail why it is important to clearly define the repository of requirements at each stage of the process. Finally, we demonstrate that we can combine the use of a requirement management tool and of a modeling tool to improve the quality of requirements without duplicating the work.

Functional requirements and functions

The functional analysis consists of analyzing the top-level functional needs and requirements and to build one or several functional architectures that satisfy those requirements.

We start by identifying the main functions that satisfy the different functional requirements and we use a traceability matrix to check that each top-level functional requirement has been taken into account by at least one function. Next, we decompose the main functions into lower-level functions that are easier to understand and to manage. This functional breakdown is recursive, down to the level where the leaf function can be fully performed by a component available on the market or internally, or fully allocated to a subsystem (that will be defined by another team).

Let us take the example of a UAV for healthy agriculture, in charge of spraying a treatment solution on crops attacked by pathogenic agents. One of its top-level functional requirements is to treat while flying. I can define a main function called “Fly and treat” that will be in charge of satisfying this top-level functional requirement.

This main function can be decomposed into 2 functional units that address respectively the flight (Follow flight plan at constant speed) and the treatment (Treat the crop). And we can continue the decomposition of these 2 functions…

Now let us look at the way we can use SysML to perform these two activities: traceability and functional breakdown.

When using the SysML notation, we can formalize a function through different concepts:

  • The “Block” concept is enough if we are only focused on the structural decomposition of the functions (also called functional breakdown)
  • The “Activity” concept is well adapted if we want to use the behavior to identify and decompose the functions
  • A combination of both a block and a behavior definition concept (state machine, activity, opaque function ) is useful when we want to have the flexibility to specify the function and its behavior separately.

In this article we will use the “Block” concept and we will define a “Function” stereotype to distinguish the functions from components (also based on the “Block” concept). The traceability of main functions to top-level system requirements can be achieved through a “Satisfy” requirements matrix. The Functional Breakdown Structure (FBS) of a given main function can be represented either with a Block Definition Diagram (BDD) or with its dual internal representation, the Internal Block Diagram (IBD).

Extract of a traceability matrix from main functions to top level system requirements (left) and FBS as BDD or IBD (right)

For each new function that has been identified, we specify new functional requirements. This gives us two parallel hierarchies that are strongly related: the functional requirements tree and the functions tree.

And then comes the key question: “Where should I store these new functional requirements? In the SysML modeling tool or in my Requirement Management (RM) tool?”

RM tool and SysML Modeling tool – How can we ensure synchronization?

We are used to manage and store the requirements in a Requirement Management tool. For small projects, such a tool could be Microsoft Word or Microsoft Excel but for large projects, we generally use a dedicated commercial solutions (such as DOORS, DOORS Next Generation, Polarion, Jama, Aras Requirements…). Most of the time, the system specification is entirely built from system requirements managed, documented, and reviewed in this requirement management tool.

If we keep this principle of a dedicated tool to manage requirements, this means that we have to add our new functional requirements into this tool. The challenge is to decide how to distribute the activities between the RM tool and the Modeling tool in order to avoid duplicating the efforts and ensure good consistency between the requirements and functions.

The first option is to use the requirement management tool as the only reference to create and maintain the requirements, at any time, and use the modeling tool only to create and maintain the functions. What about the functional requirements just derived from the functions? Should we put them in the RM tool as soon as we identify them? In that case we need to go back and forth between the RM tool and the SysML tool to ensure the consistency between the new functions formalized in SysML and the functional requirements derived from those functions that have to be created or updated in the RM tool. It means that we need to switch between both tools at every change in the functional architecture. It looks painful… and might be an agility killer…

Another option is to create the requirements in the modeling tool, close to the functions they specify, and keep those requirements in the modeling tool until the functional architecture is finalized. If the functional architecture changes (new functions, removed functions, changes in function inputs, outputs, activation in modes, performance…), it is quite easy to adapt the functional requirements because all elements are in the same tool and we can use traceability links to analyze the impacts. When the functional architecture is considered as finalized, then it is time to extract the functional requirements and put them into the RM tool to complete the specification.

If we look at the previous example, we can create a “relation map” diagram that shows the relations between the top-level functional requirement (Fly and Treat), the main functions associated to it, the sub-functions, and a first draft of their associated functional requirements.

Note: The derivation of requirements from a function is an advanced topic that requires some explanation. Here we show the derivation of only ONE basic (draft) requirement for simplification but a function generally leads to the identification of several requirements, built from the combination of function performance criteria and lifecycle “situation” (phase/mode/state… and conditions) in which the function is active. And each of the identified requirements will later be completed to prepare its verification, leading to an improvement of the requirement maturity and quality.

The derivation of requirements will be detailed in a future dedicated article.

Relation map that explains the extended traceability between top level requirements and lower-level requirements through functions

Note: the relation map can be read through the following sequence of relations: the top-level functional requirement (FlyAndTreat) is satisfied by a Function (Block) that is composed of the two sub-functions fly and treat (part properties) that are each typed (defined) by a function (block) that satisfies requirements.

So far, so good. But what happens if one of my colleagues is defining some lower-level functional requirements in the RM tool while I’m defining my functional breakdown in the modeling tool? We are simply doing the same exercise concurrently through 2 different means and in 2 different tools: refine the functional requirements. Double efforts for the same value…

You may smile at this situation but it is something that happens regularly in the industry, especially when the modeling activity has not been defined in the development plan. So it is necessary think about it. The important principle is to ensure that there is only one reference for the modification of the requirements at a given stage of the development process.

When using the second option, we have requirements managed in two repositories. Thus, it is necessary to clarify which requirements can be modified by which tool to conform to this important principle:

  • The top-level functional requirements are defined and maintained in the RM tool and propagated in the modeling tool
  • The lower-level functional requirements are defined and maintained in the modeling tool and propagated later in the RM tool

This approach makes things clear by using only ONE requirement repository at a given stage. It allows an efficient definition of the requirements by using different tools according to each stage.

We suggest 3 different stages to organize the responsibility in the modification of the requirements:

  1. Before the SRR (Systems Requirements Review): the RM tool is used to define and document all top-level system requirements
  2. During the elaboration of the functional architecture: the modeling tool is used to define and document lower-level (refined) functional requirements derived from the functions. This stage ends with the preparation of the Preliminary Design Review (PDR).
  3. Since the preparation of the PDR: the RM tool is used to gather all system requirements including the ones coming from the functional model in order to ease the review of all system requirements and to generate the complete system specification.

In order to support this distributed work on requirements through 2 different tools, we also need to ensure that we can propagate the requirements between tools in an easy way. This question is addressed in the next chapter.

Can we automate the transfer of requirements between tools?

The answer is yes for many situations.

If you use Cameo Systems Modeler as a SysML modeling tool, you may know that 3DS provides a third-party tool called “Cameo Data Hub” that is able to synchronize objects between DOORS and some other RM tools and Cameo Systems Modeler. Clearly this is a good solution to ensure that requirements are aligned between both tools at a given point in time.

But this is not enough. We also need the traceability between top-level and lower-level system requirements. If we place lower-level requirements in DOORS without traceability to top-level requirements, then the modeling may be considered as useless and a waste of time and efforts. Traceability is very important because it gives us a powerful means to analyze a change in top-level requirements and immediately identify the lower-level requirements on which there may be impacts.

The idea is simple: let us extract this traceability from Cameo and let us create direct links between both levels of requirements as we would have done directly in DOORS. A small CSM plugin can do this: extract the traceability chain and recreate the direct links instead of using intermediate modeling elements (the functions).

Automation to capture the extended traceability links between requirements

Once this is done, we can synchronize both the lower-level requirements and their traceability links to top-level requirements between CSM and DOORS.

That’s it! Finally, we get our 2 levels of requirements in DOORS with traceability exactly as if we had worked only in DOORS. But we have in fact used CSM to help us in building a functional architecture as an intermediate step, which leads to a far better quality of the requirements once put back in the RM tool!

Zig zag with synchronization and automation in practice (video)

This short video shows the presented zag zag pattern between the RM tool and the SysML tool in practice.

Note: the derivation of lower-level requirements is very basic in this video (as it was not the main topic and we did not want to spend time on it). There will be additional material on this topic at a later date.

Next articles to come…

  • June 2020 – Early validation of stakeholder needs through simulation
  • July 2020 -Consistency between functional and logical architectures
  • August 2020 – Minimization of the coupling in the logical architecture
  • September 2020 – Digital continuity between SysML and Simulink
  • October 2020 – Digital continuity between SysML and AADL
  • November 2020 – Digital continuity between SysML and Modelica
  • December 2020 – Co-simulation of SysML and other models through FMI

Previous articles in the series

  • April 2020 – Formalization of functional requirements

Part 1 – Formalization of functional needs with SysML

 

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.

 

 

 

 

This first article puts a spotlight on the top-level part of the V Cycle, concerning the translation of stakeholder needs into system requirements. We show how it is possible to use a modeling approach to structure and refine functional needs expressed by the stakeholders of our System of Interest (SoI) and then deduce top-level functions and draft system functional requirements.

 

We need different views

 

For the capture, structure, and synthesis of functional needs, we suggest using the following different views:

 

  • Use Cases view, to define system missions captured from stakeholder needs
  • Operational scenarios view, to show system interactions and expected reactions of the system
  • System context view, to synthesize all external functional interfaces
  • Top-level functions view, to list all the functions derived from operational scenarios or already allocated to the SoI by an enclosing system
  • Operational modes view, that provides boundaries for activation and deactivation of functions
  • Allocation matrix of functions on modes to specify the validity scope of the functions

 

Note: there exists other views useful to capture and structure nonfunctional requirements like Measures of Effectiveness (MoE) and physical constraints. In this article we only focus on the functional needs.

 

 

 

Now we will show how to use SysML to support those different views, but first we introduce the sample case that is used to illustrate the mappings: the AIDA model. AIDA is an open source model defined at St Exupery Research Institute (Toulouse, France) to formalize a drone in charge of aircraft inspection. It was initially developed with Capella. Here we have translated this example to the SysML notation. The drone used for inspection is our System of Interest (SoI) and the aircraft inspection is the main mission the drone contributes to.

 

When using SysML, the Use Cases view directly maps to the Use Cases Diagram (UCD). We use the actors as roles played by external entities that interact with our drone.

 

 

The operational scenarios can be formalized in SysML with interaction diagrams, graphically represented by Sequence Diagrams (SD). We define simple, black-box sequence diagrams showing interactions between main actor (our drone pilot) , the SoI, and the other actors that represent roles played by external entities involved in the scenario. There is no need for other lifelines.

 

We define as many diagrams as needed to translate all the functional needs of the different stakeholders, including our customers and users. The main goal of these diagrams is not to define the execution logic, but rather to identify the required service functions (functions that provide services to the system end-users) expected by the end-users and customers of the future system. Let us illustrate with 2 sequence diagrams:

 

 

The system context view is focused on external functional interfaces. We create this view with SysML by using an Internal Block Diagram (IBD) that shows the system connected to its environment/context. By environment we mean here its physical context with the other systems or external entities that interact with our system of interest. The top-level service functions view can be shown as a tree.

 

 

Finally, the operational modes view can be formalized through a SysML state machine. We use a “mode” stereotype to distinguish those modes from other system states. An allocation matrix is used to define which functions are available in which mode.

 

 

But these different views are not independent !

 

If you create these views independently, you will soon discover that there are several modeling elements that relate to the same concept. You will then realize that your model contains duplicates of the same information, with the possibility of inconsistencies…

 

How can we avoid this issue? By studying the links between the elements and by providing some rules for the organization of the data in the model (parent / child, owner / owned, whole / part…).

 

Here is our suggestion:

 

  • Define your scenarios as behaviors of your use cases. Then you can check that your scenarios use same actors (at least a subset) of the ones associated with your Use case. You can then store your scenarios below the UC as “owned behaviors” and navigation from UC to scenarios is immediate.
  • Initiate and maintain your system context (IBD) external interfaces with messages from the scenarios (at least the messages that go in or out of the SoI). Note: for this you need to map your actors to the elements of your context to enable this mapping of messages to the context elements.
  • Initiate and maintain a list of top-level required functions identified from the scenario messages: external messages will lead to interface functions while reflexive messages on the SoI will lead to system internal functions.
  • Identify modes of your system by looking at the mission profile (stages) and the human interaction steps. This identification is not easy and will probably lead to additional guidance in a future article dedicated to this kid of identification.
  • Once you have both top-level functions and modes, you should allocate functions on modes to specify the validity of the functions validity in accordance with the modes.

 

Here is below an illustrated summary of the mappings that can be made to check and ensure the consistency between the different views:

 

 

Note: when all the semantic mappings have been defined, all the views contribute to the validation of needs or the elaboration of draft functional requirements.

 

 

Note: in a future article we will see how these functional requirements can be completed smoothly with additional conditions, performance, and elements of verification to improve their maturity and reach good quality.

 

Can we automate these mappings?

 

Yes we can. And we did it.

 

We have created a plugin to automate the transformations between the views according to changes done by systems engineers. This is a “live mode”: any change in one Sequence Diagram is immediately reflected in the other views (context, functions…) including the requirements view (agile approach).

 

 

Automations in practice (video)

 

Look at the video to see these automations in practice. Enjoy MBSE !

 

 

 

Next articles to come…

 

  • May 2020 – Derivation of requirements from models: From DOORS to SysML to DOORS again
  • June 2020 – Early validation of stakeholder needs through simulation
  • July 2020 -Consistency between functional and logical architectures
  • August 2020 – Minimization of the coupling in the logical architecture
  • September 2020 – Digital continuity between SysML and Simulink
  • October 2020 – Digital continuity between SysML and AADL
  • November 2020 – Digital continuity between SysML and Modelica
  • December 2020 – Co-simulation of SysML and other models through FMI

 

 

Go to Top