Capella Based System Engineering Modelling and Multi-Objective Optimization of Avionics Systems.pdf

Capella Based System Engineering Modelling and
Multi-Objective Optimization of Avionics Systems
Leandro Batista
ENSTA PARISTECH
828, Bvd des Maréchaux
91762 Palaiseau,
FRANCE
leandro.batista@ensta-paristech.fr
Omar Hammami
ENSTA PARISTECH
828, Bvd des Maréchaux
91762 Palaiseau,
FRANCE
hammami@ensta.fr
Abstract - Capella is a system engineering public domain tool
which has been recently released by THALES. It is a model
based systems engineering tool that implements the Architecture
Analysis & Design Integrated Approach (ARCADIA)
framework. This paper proposes a process specification, design
and optimization of a distributed avionics system. Capella is used
as a design tool for Distributed Integrated Modular Avionics
(DIMA). The DIMA architecture has interesting power, weight
and cost metrics which are highly demanded by aerospace
industry. The main challenges faced by DIMA system architects
are related to functions allocation and device physical allocation.
This problem refers to the system functions translation into tasks
and further hardware allocation. These problems are hard to
solve manually due to the high number of functions in modern
systems. The design and development of DIMA systems can be
dramatically improved using optimization techniques. Moreover,
allocation strategies based on different figure of merit can be
evaluated at a smaller cost. In this paper we develop a simplified
DIMA model using the Capella tool and the framework
ARCADIA. The model is extended using viewpoints for
specifying additional system constraints. Model parameters are
extracted to specify a binary integer problem for the system
allocation process automation. Different cost functions are
evaluated for a simple study case.
Keywords—architecture, multi-objective optimization, system
engineering, distributed integrated modular avionics.
I. INTRODUCTION: SYSTEM COMPLEXITY TRENDS
Model based systems engineering (MBSE) is next frontier
for systems engineering and for modeling tools. In last decade
we have seen the development of many domain specific
languages (DSL) that can be used for systems engineering
activities. After these efforts, it is known that adopting a
modeling language is not enough to successfully deploy a
MBSE methodology. It is also necessary to create or adopt a
systems engineering process. Recently, THALES has open
sourced the framework ARCADIA (Architecture Analysis &
Design Integrated Approach) with the associated workbench
Capella [1][2].
In this paper we propose a method to optimize the tasks of
interface definition, function allocation, and system
configuration based in the architecture models generated by
Capella tool.
The next section describes the state of the art for MBSE
and architecture optimization methods. Section III describes
the main characteristics of Distributed Integrated Modular
Avionics (DIMA). Section IV and V present the ARCADIA
framework and simplified DIMA model is explored. Sections
VI and VII describe the optimization method using the
simplified DIMA model. Section VIII present the results for a
simplified study case and section IX propose future
improvements for the methodology and summarize the results.
II. STATE OF THE ART
The DIMA architecture has attractive power, weight and
cost metrics. These characteristics are highly demanded for
aerospace applications. Moreover, the DIMA architecture
enables a better resources management leading to an
optimized system deployment. Reusability, maintainability
and flexibility are a few sample of DIMA features.
Due to the highly integrated nature and increasingly
growing complexity of DIMA systems, new processes and
tools are required in order to take advantage of all features of a
distributed system. This is even more important for system
interface definition, resource allocation process, system
configuration and minimizing the cost of change.
The DIMA design is described in literature by two
resource allocation problems: devices installation locations
and functional resource allocation. The general method
develops function and physical model, define different figure
of merit and apply different optimization heuristics [3][4]. The
methods used are based on linear integer programming in
order to calculate the exact Pareto frontier. As mentioned by
the authors, the proposed methods are not scalable due to the
complexity nature of the problem. They don’t work for the
complex real networks with hundreds of tasks and tens of
constraints. The architecture is described using a cyber-
physical model and no systems engineering modeling
language is used.
Real implementation is found in literature. An
implementation of the OpenFlow protocol is done using
COTS switches and the results are validated to a state of the
art real equipment. It is also provided data from the highest
loaded switch of a real aircraft [5]. In this case no optimization
was used to allocate functions and equipment.
978-1-5090-0793-6/16/$31.00 ©2016 IEEE

Genetic algorithms have been used to cope with the
complexity of DIMA design [7]. These methods are
computationally efficient for calculating the Pareto front. They
are bio-inspired algorithms that simulates the natural selection,
mutation and crossover processes.
To compose the DIMA allocation problem, many cost
functions are found in literature. The performance measures
used by the optimization heuristics are mass, ship set costs,
operational interruption costs and initial provisioning costs.
There are also some metrics related to end-to-end delay and to
resources consumption [3-8].
III. AVIONICS SYSTEMS
Traditional avionics systems are designed and built using
federated architectures. In this approach each function is
carried out by a line replaceable unit (LRU) in the avionics
platform. The information sharing in a federated architecture
is implemented using dedicated interfaces. The Figure 1 shows
an example of federated architecture. In this example each
blue rectangle represents a LRU and each arrow represents a
communication interface between the LRU’s. These interfaces
usually are implemented as a serial communication bus or a
discrete line.
Figure 1 - Federated Architecture
Adding a new function to a federated architecture is
usually done by a new LRU integration. This process includes
deploying a dedicated wiring in order to provide the required
communication for each interface.
Aerospace manufacturers use the federated architecture
approach for several decades and it is still largely used by
legacy systems. New stringent market requirements pushed
the aeronautical industry to deliver solutions with constant
increasing weight, power and cost constraints. Moreover,
customers demand product customization, integrated solutions
to be delivered in a challenging time to market schedule.
The Distributed Integrated Modular Architecture (DIMA)
has been developed to provide a better approach to the severe
scenario constraints. The Figure 2 shows a simplified view of
an DIMA architecture.
Figure 2. Integrated Modular Avionics
Each LRU in an DIMA architecture can fulfill more than
one function within different partitions with different design
assurance levels. The different systems and functions share a
common communication bus. These shared resources allow a
reduction in weight and power to the avionics systems. The
number of LRU and quantity of wiring can be reduced due to
the shared resources. Another advantage of DIMA architecture
is the spare computational time optimization. In a federated
architecture, it is not possible to share the spare computational
time. DIMA architecture provides the capability to deploy
highly integrated system functions based on shared data. The
main benefit of DIMA is to provide a better resource
management in comparison to the federated architecture
approach.
Traditionally the aerospace industry describes the system
functions in a text requirement base. These functions are
usually manually allocated to systems. With the increasing
complexity of modern aircraft, the design space grows
exponentially. This scenario leads to a high cost to explore
different solutions and generally the development team focus
on finding any feasible solution.
New processes and tools should be developed to manage
the complexity of the high integration level of DIMA
architectures. There are several approaches to solve the
physical allocation and function problem using optimization
techniques. These methods are based in a system function
model breakdown and a physical model definition.
In this paper we propose a method to help DIMA
architects to define the necessary models to build an optimized
architecture.
IV. MBSE, ARCADIA AND CAPELLA
THALES has developed the Arcadia MBSE method for
architectural design. The method focuses on complex
architecture definition, functional analysis and early
evaluation [1][2]. The Figure 3 describes the Arcadia
engineering phases. The first layer is dedicated to operational

analysis (OA) by analyzing customer needs and goals,
expected missions and activities, beyond system requirements.
The outputs are an operational architecture describing and
structuring this need, in terms of actors/users, their operational
capabilities and activities, and operational scenarios. The
second design level is the system analysis (SA) which focuses
on the system perimeter to define how it can satisfy the
operational needs. The outputs of this stage are a functional
analysis describing the need, the interactions with the users
and external systems and system requirements.
Figure 3. ARCADIA General flow
The logical architecture (LA) layer describes the solution
that is the architectural design. The physical architecture (PA)
refers to the selection of physical components to composed the
system of interest. The Arcadia method promotes the use of
multi-viewpoints enabling evaluation of the architecture
according to different stakeholders. A viewpoint is a set of
specific constraints, figures of merit and analysis rules defined
by specialists. Multi-viewpoints are used by architects to
orchestrate trade-offs between different technology domains to
achieve a common feasible solution.
The logical architecture intends to identify the system
building blocks, their functional contents, relationships and
properties, excluding implementation or technical and
technological issues. The resulting component breakdown and
interfaces are the best compromise between functional
allocation and integration of all major non-functional
constraints and design drivers. The physical architecture layer
makes the logical architecture evolve according to
implementation, technical and technological constraints and
choices. It introduces rationalization, architectural patterns,
new technical functions and components.
The ARCADIA framework also provides a domain
specific language (DSL) similar to UML/SysML and NAF
standards. The DSL ensures the communication between the
different stakeholders. Moreover, the DSL is suited to process
large models and it helps in the automatic transition to the
following model level.
The Capella software is an ARCADIA dedicated modeling
workbench. It provides a guided and iterative experience
trough the ARCADIA process. For each model change,
Capella automatically propagates the information for all model
elements keeping all instances synchronized. The tool also
helps during the transition between the different modeling
phases providing an automatic and incremental transition.
The collaboration between the different specialties is
achieved by constructing Capella viewpoints. A viewpoint is
the formal specification of a system constraint and it is
propagated to different model levels with automatic
traceability. Using a viewpoint allows the system designer to
perform an impact analysis of a specific constraint. Cost,
mass, power and safety are examples of constraint that can be
analyzed using viewpoints.
V. CAPELLA MODELLING
The project we are developing is intended to achieve a
seamless integration of the different tools used along the
design chain. This synthesis process starts in the requirement
analysis and go all the way to find the possible solutions,
which are optimal for the specific project. This flow needs
interactions of specific tools dedicated for each step of the
processes [9][10]. In this paper we develop a simplified
system model to demonstrate the concepts of integrating
optimization tools with model based systems engineering.
The first step is to develop a DIMA model using the
ARCADIA process and the Capella tool. The modeling
process starts with an operational analysis of DIMA system in
order to identify the operational actors and its operational
activities. The simplified operational model is shown in Figure
4.
Figure 4. DIMA Operational Architecture model
The operational architecture model describes the user
needs and activities. The operational activity ‘Define route’

expresses pilot’s need for requesting a new direction to follow.
This is requested to the operational entity Aircraft using an
interaction ‘Requested route’. Once the route is defined, the
pilot needs to monitor the route followed by the aircraft.
Since the operational analysis is finished, the Capella can
automatically export the developed model to the next step, i.e.
the system analysis phase. The Figure 5 shows the system
architecture model where it is defined what the system needs
to do in order to comply with operational activities. This
model defines the main functions performed by the system and
its interfaces.
Figure 5. System Architecture – High Level functions
The system functions are detailed during the system
analysis phase. Figure 6 shows the system function breakdown
diagram for the considered example. In this step, the system
functions are arranged in a hierarchical manner following the
level of detail.
Figure 6. DIMA System analysis
Capella has also the capability to describe functional data
flow for this detailed model.
Figure 7 - System Function Breakdown
The diagram shown in Figure 8 provides a small sample of
the detailed functional dataflow diagram. It is important to
notice that the Capella tool propagates all changes to the
different diagrams of the same development phase. In the case
that a new function is added to system data flow diagram,
Capella automatically adds this function for the function
breakdown model.
Figure 8. Functional Dataflow
The Figure 9 shows a system analysis scenario for the
DIMA model. This scenario describes the simple use case
when the pilot sets a waypoint and the system reacts to this
action. This diagram shows all the performed functions and its
interface messages. This allows a better understand of the event
chain due to a user action.
Figure 9. System analysis scenario

VI. CAPELLA MODELLING BASED OPTIMIZATION
Long-established systems engineering processes are
strongly based on textual requirements databases. Despite the
developments in MBSE, the adoption of this new
methodology by industrial projects remains a big challenge.
Figure 10 – Textual Bridge – Linking MBSE and MBD
Figure 10 shows the traditional integration of MBSE and
model based design (MBD). In this process the artifacts
generated by MBSE are manually translated to textual
requirements modules. This formal requirement database
constructs the bridge between the high level models designed
by MBSE and the detailed models created by MBD
methodology.
After translation, these requirements are also linked to the
upper-level model. This manual approach is feasible for small
requirements database. For complex systems with thousands
of requirements, the manual translation and traceability steps
are very expensive tasks demanding an important number of
man-hours to keep information synchronized.
Once the requirements are translated and traced, a snapshot
of the database is created in order to freeze the requirements.
This important change management step creates a discrepancy
between the MBSE and the requirements database in the
course of time. This can lead to unnecessary work due to
mismatch between these two levels.
A specialist constructs the design model from the
baselined requirements. This model is manually constructed
taking into account the functional requirements and all known
problem constraints. The development process fundamentally
consists of finding any feasible solution.
Usually the design model is validated before starting
assembling the system. The validation process basically
consists of comparing the simulation results and textual
system constraints. The validation usually is done manually,
but can be automated depending on the structure of text
requirements. This step is also error prone due to manual
actions and also due to mismatch between different baselines.
In this paper we propose a new method for bridging the
gap between MBSE and MBD. The Figure 11 shows the
proposed design process.
Figure 11 – General system design process
A. Capella Model
Following the ARCADIA process, during the logical
architecture stage, it identifies the logical entities and its
relations. At this level, it is possible to group the logically
related functions and to decide how the logical functions will
be realized. The function constraints are defined based on
simulation, previous experience and stakeholder’s
requirements. The following step is to allocated the modelled
functions to a physical architecture.
The Capella logical architecture model is then parsed in
order to extract the desired functions and its constraints.
Figure 11 shows that the Capella model is automatically
exported to two different modules: System Complexity and
Design Space Exploration Engine.
The main objective of automatically parsing the Capella
model is to avoid to manually translate the high level artifact
into text requirements. This can lead to a reduction of errors
and necessary man-hours to accomplish this task.
B. System Complexity
The system complexity order can be estimated based on
the total number of constraints, number of functions to be
allocated and number of resources available. In this paper we
do not provide a formal definition of system complexity.
Although the system complexity order notion is used to
choose the optimization model and corresponding solution
algorithm.
C. Design Space Exploration Engine
In the traditional design process, an expert manually
constructs a feasible solution based on functional requirements
and system constraints. Manually finding a feasible solution is

demanding increasingly resources due to the rise of system
complexity. Besides, even for low complexity systems, few
design alternatives are usually evaluated.
In order to automate this step, the design problem is
modelled as an optimization problem. In this paper, we
modelled the functional allocation problem but the
methodology can be extended for different design problems.
The optimization model approach includes the functional
requirements and the system constraints exported from
Capella. Then the design problem is solved using an
optimization algorithm.
After all, the main objective of this step is to find the
solutions which compose the Pareto front. Moreover, we aim
to expose the existing trade-offs between design variables. In
the context of multi-objective optimization, we are also
interested in computationally efficient algorithms to explore
the design space. The choice of the optimization model and
corresponding solution algorithm is based on the system
complexity order.
D. Parametric Design Model
The automation of the design process is based on the
ability to explore different solutions for a defined design
pattern. The parametric model is built to link with the
optimization algorithm. This approach allows the designer to
choose the desired fidelity level based on the system maturity
or available resources.
The avionics function allocation model is described in
section VII. This model is used to explore de design space and
find the Pareto front for this multi-objective optimization
problem.
E. Simulation
This step is the evaluation of the parametric design model.
Based on the model formulation, the functional requirements
and the constraints are evaluated in this stage. The generated
results are consolidated in the system validation step.
F. System Validation
In this step the simulation results are compared to the
functional requirements and system constraints exported from
Capella. This stage is also responsible for evaluating the
existing trade-offs between the design variables and its impact
to system requirements and constraints.
In this phase, the optimization results are consolidated and
the architect can choose either a solution in the Pareto front set
or update the specification model and run a new optimization
cycle. The iterative nature of this process allows the system
designer to cope with the lack of information in the early
stages of the development. As the system maturity increases,
new simulation models can be integrated to this optimization
process enhancing the accuracy of the solution and narrowing
the design space.
VII. OPTIMIZATION MODEL
In this paper we are investigating the function realization
using an DIMA architecture. In this context, each logical
function is transformed to a software task in a DIMA
hardware [3][4][6]. The set of functions can be expressed as a
task set, where functions are converted to N software tasks.
= ( , , … , )
These tasks have to be allocated to DIMA hardware
complying with all the necessary constraints and resources.
During the function analysis, an estimate of processing time is
done for each function. This value can be estimated from
previous experience or can be obtained from a detailed
function model simulation. For each function a value of
required processing time is specified. The function interfaces
also require resources related to communication bandwidth for
input and output messages. Based on the function exchanges
elaborated during system analysis, it is possible to calculate
the amount bandwidth required for each task. The resource set
required for each task is composed by all exigencies for the
task to execute correctly. For a generic model, the task has
demanded resources.
= ( , , … , )
The DIMA architecture has the RDC that provides the
computing power and required interfaces to execute software
tasks. Each device has its own available resources that are
consumed for each assigned task. The available resource set
for a single data concentrator describes the maximum
available resources. The Capella function model contains the
required processing time and exchange interfaces. In term of
DIMA resources, this information is translated as CPU time,
input bandwidth and output bandwidth. A device has
available resources.
= ( , , … , )
The software mapping solution requires that each task
shall be allocated only once. Moreover, the resources
demanded by all allocated tasks in a single device cannot
exceed its capacity. This problem can be stated as a binary
integer programming with objective functions.
min ( ), ( ), … , ( )
=
≤
The solution vector is composed by binary variables that
correspond to a specific allocation relationship between a task
and a device. For the general case where we have N tasks and
M devices.
= ( , , … , , , , … , , … , )
The equality constraint can be used to express that each
task can be assigned only once. To capture this requirement,
we set the following equation for a task .
∑ = 1

During the allocation process it is imperative to comply
with the maximum available resources for each device. This is
captured by the model using the inequality constraints. The
resource required by all tasks allocated to device shall be
less than or equal to available resources.
∑ . ≤
The cost function can be defined by different figures of
merit found in the literature. The total mass of the shipset is
used as a cost function for our optimization problem. The total
weight is considered here because it may have a relevant
impact in the aircraft performance. There are several other
cost functions related operational cost and maintenance issues.
VIII. CASE STUDY
A Capella logical architecture model containing 500
functions was created for validation purpose. This model is
used to explore the software mapping problem. For the sake of
simplicity, the system model takes into consideration only the
CPU time. The CPU time is the amount of processing time
demanded for the considered task. Each function was assigned
a random execution time with uniform distribution. The
optimization model was build using these functions exported
from Capella with the following constraints:
1. Maximum device CPU allocation shall be less than
80%;
2. Each function shall be allocated only once;
3. The initial platform processing time shall be 20%
greater than total functions execution time;
The first constraint assures a provision to system growth.
During the design phase usually the system maturity level is
usually low. So this can guarantee that new functions can be
added to the system. The second constraint is intended to
allow a single allocation for each function. It means that
redundancy management, for example, shall be performed at
Capella design level. The third constraint is related to the
quantity of available devices in the platform. The number of
devices to be considered in the initial optimization problem is
calculated using the following equation:
= 1.2 ∗ ∑
Where is the normalized task execution time for task .
This formulation enables the system architect to find an
optimal solution based on a set of defined cost functions. In
this study case, we use a single unitary cost function to find a
valid architecture that minimizes the number of switches in the
platform. The optimization model evaluated in this study case
is the following:
min
∑ = 1, ∀ ∈ 1, … ,
∑ . ≤ 0.8, ∀ ∈ 1, … ,
= 1.2 ∗ ∑
= 1, . . ,
This problem was solved for = 500 using the GNU
Linear Programming Kit (GLPK) included in Octave 4.0.3
compiled for 32-bit architecture. The Figure 12 shows the
execution time in seconds in function of the number of tasks
and the Figure 13 shows the memory allocation for GLPK.
Figure 12 - GLPK execution time
Figure 13 - GLPK Memory Allocation
From these results, we find that the execution time increase
exponentially with the number of tasks. The same behavior is
verified for memory allocation. In this study case, we
considered, for sake of simplicity, a single constraint and a
single cost function. For systems larger than 500 tasks, the
algorithm did not find a solution due to memory allocation
limitations.
IX. FUTURE WORK
In future works we encourage the development of more
detailed DIMA models, the construction of new figure of

merit and the development of new viewpoints integrated to
Capella.
Another interesting field of research includes the
formalization of system complexity. This is an important
milestone for choosing the optimization algorithm used by
search engine.
For future developments we intend to achieve a seamless
integration of the different tools used along the design chain.
X. CONCLUSION
In this paper we presented a design method linking model
based systems engineering to architectural synthesis using
optimization techniques. This link is traditionally done using a
textual requirements database manually written. The proposed
solution aims to automatically extract functional requirements
and systems constraints from Capella model. Then this
information is used by a simulation engine in order to explore
the design space and find the Pareto front solutions.
This solution discovery process is automated using an
optimization algorithm. This approach allows the architect to
evaluate a large number of feasible solutions. Besides, the
method exposes the existing trade-offs between the design
variables. The proposed method also eliminates the manual
requirements translation. This approach can empower the
system architect with the necessary framework to cope with
the increasing complexity of modern systems.
We also described the ARCADIA framework with its
associated tool Capella. It was developed a simple DIMA
model in order to demonstrate the model concept. A binary
programming model was constructed to automate the synthesis
process. In this paper we simulated systems with single
constraint and single objective. From the results, we can
conclude that GLPK can be used for exploring low complexity
systems design space. Adding more constraints and new
objectives for high complexity systems will demand the
evaluation of different solution algorithms.
XI. ACKNOWLEDGMENT
The research that led to this article was funded by the
Brazilian National Research Council (CNPq) under grant
204962/2014-5. The authors wish to thank all those who
supported the efforts of Capella development.
REFERENCES
[1] J-L.Voirin, S.bonnet V.Normand and D.Exertier, “From initial
investigations up to large-scale rollout of an MBSE method and its
supporting workbench: The THALES experience”, in Proc. of the 25th
Annual INCOSE international symposium, Seattle, USA, July 13-16,
2015.
[2] S.Bonnet, J-L.Voirin, V.Normand and D.Exertier, “Implementing the
MBSE Cultural Change: Organization, Coaching and Lessons Learned”,
in Proc. of the 25th
Annual INCOSE international symposium, Seattle,
USA, July 13-16, 2015.
[3] B. Annighöfer, E. Kleemann and F. Thielecke, "Automated selection,
sizing, and mapping of Integrated Modular Avionics Modules," 2013
IEEE/AIAA 32nd Digital Avionics Systems Conference (DASC), East
Syracuse, NY, 2013, pp. 2E2-1-2E2-15.
[4] C. Zhang and J. Xiao, "Modeling and optimization in Distributed
Integrated Modular Avionics," 2013 IEEE/AIAA 32nd Digital Avionics
Systems Conference (DASC), East Syracuse, NY, 2013, pp. 2E1-1-2E1-
12.
[5] P. Heise, F. Geyer and R. Obermaisser, "Deterministic OpenFlow:
Performance evaluation of SDN hardware for avionic networks,"
Network and Service Management (CNSM), 2015 11th International
Conference on, Barcelona, 2015, pp. 372-377.
[6] X. Zheng, N. Huang, Y. Zhang and X. Li, "Performability optimization
design of virtual links in AFDX networks," 2016 Annual Reliability and
Maintainability Symposium (RAMS), Tucson, AZ, 2016, pp. 1-6.
[7] X. Li, N. Huang and F. Zhao, "A genetic algorithm based configuration
optimization method for AFDX," Reliability, Maintainability and Safety
(ICRMS), 2014 International Conference on, Guangzhou, 2014, pp. 440-
444.
[8] A. Amari, A. Mifdaoui, F. Frances and J. Lacan, "Worst-case timing
analysis of AeroRing A Full Duplex Ethernet ring for safety-critical
avionics," 2016 IEEE World Conference on Factory Communication
Systems (WFCS), Aveiro, Portugal, 2016, pp. 1-8.
[9] O.Hammami, “ SYNSYS-ME: Seamless System Engineering to
Mechanical Flow Through Multiobjective Optimization and
Requirements Analysis”, IEEE Syscon, Mar.31-Apr.3, 2014, Ottawa,
Canada.
[10] Mian Chen, Omar Hammami A System Engineering Conception of
Multi-objective Optimization for Multi-physics System, Multiphysics
Modelling and Simulation for Systems Design and Monitoring Applied
Condition Monitoring Volume 2, 2015, pp 299-306 Springer-Verlag.

Capella Based System Engineering Modelling and Multi-Objective Optimization of Avionics Systems.pdf

More Related Content

Similar to Capella Based System Engineering Modelling and Multi-Objective Optimization of Avionics Systems.pdf (20)

Recently uploaded (20)

Capella Based System Engineering Modelling and Multi-Objective Optimization of Avionics Systems.pdf