## 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.

Note: we recommend reading the previous article for more details on the relationships between the functional architecture and the logical architecture.

From this matrix with modules, we can now compute a coupling metric regarding the interfaces of the modules.

## Using a Genetic Algorithm to optimize the allocation of functions

Genetic algorithms are algorithms inspired by  evolutionary principles. The main purpose of this kind of algorithm is to explore the solution space of a problem in order to satisfy a set of criteria. The general principles of genetic algorithms are illustrated on the Figure below.

Genetic Algorithm Process

The first step is to create randomly a set of initial subjects (1). This set is called the initial population. The initial population is composed of subjects each representing a possible set of functions allocations. Then, the algorithm evaluates each subject using a fitness function (2). This function makes it possible to give a value, or a rank, to a subject, to estimate its proximity with the “optimal” solution. In our case the fitness function is the coupling equation C. The candidates that are too far from the desired solution are deleted (3).

Then the algorithm evaluates the number of remaining subjects. For instance, if the population size is less or equal to 4, then the algorithm returns the best solution amongst the 4 remaining subjects. On the contrary, if the population size is greater than a specific threshold, then the algorithm continues. And this is where things become interesting…

Here begins the core biomimicry part of the genetic algorithm: the remaining subjects cross over, i.e. they exchange their genes to produce new subjects (4). Finally, the newly created childs are subject to mutation (5): part of their characteristics randomly change. Cross over and mutation are usefull to stay away from local optimum by spreading new subjects through the solution space.

Genetic algorithms are configurable using the following set of parameters:

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

## Part 4 – Consistency between functional and logical architectures

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

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

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

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

# Why do we need a logical architecture?

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

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

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

The drone system contains 9 top-level functions:

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

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

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

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

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

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

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

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

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

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

# The logical architecture as an intermediate layer

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

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

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

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

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

• Mission management subsystem
• Propulsion subsystem
• Flight management subsystem
• Vision Subsystem

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

# How do we create the logical architecture?

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

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

The next chapter explains this in detail.

# Consistency between the Functional architecture and the logical architecture

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

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

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

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

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

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

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

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

Conclusion

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

# Can we automate some of the steps presented above?

Yes !

### Overview of the automation

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

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

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

### Simulation in practice (video)

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

Enjoy MBSE!

# Next articles to come…

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

# Previous articles in the series

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