=Paper=
{{Paper
|id=Vol-1728/paper14
|storemode=property
|title=Deploying Model-Based Systems Engineering in Thales Alenia Space Italia
|pdfUrl=https://ceur-ws.org/Vol-1728/paper14.pdf
|volume=Vol-1728
|authors=Elvira Calio,Fabio Di Giorgio,Mauro Pasquinelli
|dblpUrl=https://dblp.org/rec/conf/ciise/CalioGP16
}}
==Deploying Model-Based Systems Engineering in Thales Alenia Space Italia==
https://ceur-ws.org/Vol-1728/paper14.pdf
Deploying Model-Based Systems Engineering in
Thales Alenia Space Italia
Elvira Caliò, Fabio Di Giorgio Mauro Pasquinelli
Thales Alenia Space Italia Thales Alenia Space Italia
Via Saccomuro, 24 – 00131 Roma, Italia Strada Antica di Collegno, 253 - 10146 Torino, Italia
name.surname@thalesaleniaspace.com name.surname@thalesaleniaspace.com
Copyright © 2016 da Elvira Caliò. Permesso concesso a AISE di pubblicare e utilizzare.
Copyright © held by the authors.
Abstract— In the last decade, Thales Alenia Space started employees and with the goal of fostering a common tooled up
studying the transition of its own systems engineering methods approach and use of the same reference architectures, Thales
from standard requirement and document based ones to has conceived a solution based on these core elements:
innovative approaches taking care of concurrent engineering,
enhanced collaboration, model based system engineering a System Engineering methodology, called Sys-EM,
methods and tools and tool-chains for overall engineering which defines the successive stages of the overall
environments. In the field of system architectures analysis and engineering process,
definition, TAS has deployed internally a tooled-up approach,
which is being extended to other system and multidisciplinary a Model-based engineering method for systems,
engineering activities. hardware and software architectural design, called
ARCADIA
Despite an investment needed to set-up the tooled-up
approach, it allows to relate in a same model customer needs and a THALES internal system modeling tool, Melody
architecture constraints, furthermore ensuring overall document Advance, now released in the Open Source as Capella
consistency with the design by means of automatic (https://www.polarsys.org/capella)
documentation generation from the model, simplifying alignment
in case of model update.
Moreover, traceability links between requirements and model II. ARCADIA AND CAPELLA
facilitate impact analysis for system evolution and maintenance,
and will allow modifying the architecture baseline, taking care of
previous justifications. A. Comparing ARCADIA vs. INCOSE approach
This paper presents an outline of the TAS Model-based ARCADIA (ARChitecture Analysis and Design Integrated
engineering method (ARCADIA), of the use of the related Approach) is a Model-Based engineering method for systems,
tooling, and some examples derived from the application to space hardware and software architectural design. It has been
projects in the Domain Observation and Navigation Italy and in developed by Thales between 2005 and 2010 [2] through an
the Domain Exploration and Science Italy. Observed benefits of iterative process involving operational architects from all the
this approach, additional needs which have been managed (such Thales business domains (transportation, avionics, space, radar,
as the extension of the approach to cover the geometry of the etc.).
physical components) are presented in the conclusions.
Traditionally, emphasis has been put on a good definition
(Abstract) of (mainly functional) requirements, and their allocation to
each product item (broken down in subsystems, software,
Keywords — Systems Engineering; Model-Based; MBSE;
tooled-up approach; Capella.
hardware items...), and associated traceability.
This is clearly necessary, but in many cases, engineering
appears to be reduced to writing requirements and allocating
I. INTRODUCTION them to some breakdown items, with little or no real analysis,
design, check, justification of the relevant breakdown.
As a Large System Integrator, Thales Alenia Space, like most
of the Thales Group Entities, is very focused on System Furthermore, this allocation of requirements is often only
Engineering, which covers most areas of its activity spectrum, considered from the functional viewpoint, neglecting other
covering Observation, Navigation, Space Exploration and "viewpoints" that usually strongly impact this breakdown, as
Science and Telecommunications. for instance time performance allocation and safety drivers.
Besides actively sponsoring the achievement of INCOSE Instead, ARCADIA recommends three mandatory
CSEP (Certified System Engineering Professional) among its interrelated activities, at the same level of importance:
Need Analysis and Modeling The System Requirements and a design activity leads thus
to the definition of a (or more) solution(s) that meets the needs,
Architecture Building and Validation focusing on “how the System will work”. Here, the concept of
Requirements Engineering Viewpoints is stressed both in the INCOSE approach and in
the ARCADIA – Capella one.
At this point, the INCOSE approach foresees the Design
Definition process, aimed at “providing sufficient detailed data
[…] to enable the implementation […]” which is paralleled by
the Physical Architecture step in ARCADIA / Capella.
While this description, as depicted in fig. 2, seems to
dictate a sequential approach, this is not necessarily the case,
with several refinements steps leading to loops and iterations.
This is also conceived in the ISO/IEC TR 24748-1 [2] and
reported in fig. 3.2 in the INCOSE SE Handbook [1], and the
Capella tool supports this by means of traceability between
levels and additional capabilities (e.g. diff/merge, libraries, …).
B. From Method to Tool: Capella
Capella is an Eclipse based Open-Source system modeling
tool, originally developed by Thales Group as Melody-
Advance (part of Orchestra system engineering workbench
solution).
Fig. 1. ARCADIA mandatory interrelated activities
It embeds ARCADIA method to guide users and relies on
These activities will be carried out through the various detailed UML/SysML widely known standards, but uses a natural
steps of the method. engineering semantic (functions, components, data…): Capella
embeds a methodology browser, reminding ARCADIA
principles to the user and providing efficient methodological
guidance
It should be highlighted that SysML is a language, not a
methodology: it provides a vocabulary, but tells nothing about
using one or the other concept, about structuring models or
about following design rules, etc.
The Capella interpretation of the SysML specification is
built on the following main drivers:
Provide engineers all the expression means they need
Avoid overwhelming engineers with unnecessary
complexity
Help engineers following the Thales methodologies
Unify the way systems and software architectures are
Fig. 2. Steps of ARCADIA method modeled across Thales
As such:
It is evident that the first activity, “Need Analysis and A large part of the Capella concepts are directly
Modeling” is strongly related to the first Life Cycle Stage as coming from a subset of UML/SysML ones. For
defined by INCOSE SE Handbook [1], namely the Concept example, classes, properties, parts, ports, interfaces,
Stage, with the same focus on the Stakeholder needs and the actors, interaction model, state machines, etc.
definition of an Operational Concept (OpsCon or “ConOps”) Some concepts are a Thales specialization of
and Business Requirements as an input of the following SysML concepts. For example, a SysML block does
Development Stage. not exist as such in Capella. Instead, it provides
In the Development Stage, again as defined by the SE Actors, Operational Entities, Logical / Physical
Handbook, we pass from the Stakeholder needs to Stakeholder Components, Configuration Items which actually are
Requirements and to System Requirements, i.e. “what the all blocks.
System has to accomplish” to fulfill its Mission.
Some are additions to the SysML specification: enhance competitiveness through standardization and
specialized packages for model structuring, formalization of product reference architecture
traceability links (between each Sys-EM architecture
confirm MBSE advantages and promote its
phases for example), enriched data values deployment in TAS-I
And a few concepts are coming from NAF (NATO
Architecture Framework) subset. A multi-disciplinary engineering team, covering different
competence areas within the Earth Observation Domain, has
been trained and deployed. A preparation phase has been
carried out before starting the project implementation to
identify the best modeling approach versus engineering needs
and model objectives. This step was fundamental to define the
perimeter of the activity and to limit the modeling scope to
what was strictly necessary with respect to the intended use of
the model.
As result of the trade-off, it was decided to concentrate the
modeling effort in the System Analysis and Logical
Architecture steps, with a possible extension toward the
Physical Architecture.
Cooperation among different disciplines was
identified for each step, in particular:
System, Ground Segment and Space Segment
Fig. 3. Capella Methodological Activity Browser engineers for System analysis
Ground Segment, Space Segment, sub-system and
The following sections will detail the application of ARCADIA payload engineers for Logical Architecture modeling
method through Capella tool to two use cases in Thales Space Subsystem, payload, hardware (HW) and software
Division. (SW) engineers for the Physical Architecture
modeling
III. MBSE APPROACH IN THALES ALENIA SPACE ITALIA The EO System modeling activity started with the System
The following sections present two examples of use of the analysis, aimed a defining the system functionalities and the
ARCADIA method in TASI space projects and its interactions with external entities. Within the tool this activity
implementation through the Capella tool. In particular, the first is mainly driven by the identification of:
example shows the application of the method for the System Context, Actors & Capabilities
engineering modeling of an End-to-End Earth Observation
system (including both space and ground segments), while the System Functional breakdown and dataflow
second one shows the application of the method at Segment
System Functional chains and scenarios
level (spacecraft design).
The SAR EO System external actors identified and
A. MBSE applied to an End-to-End Observation System
captured in the Contextual System Actors diagram are shown
In 2014 Thales Alenia Space Italia (TAS-I) Domain in the following figure.
Observation and Navigation Italy started a pilot project for
modeling an End-to-End SAR Earth Observation (EO) System
with Melody Advance (now Capella). It represented one of the
first examples of exploitation in TAS-I of a new system
engineering approach for a very complex system passing from
the traditional “requirement-based system engineering”,
centered on textual requirement database, to a “model-based
system engineering” supporting the formalization of Customer
requirements in a system model.
The main objectives of the activity were identified as
follows:
manage the System complexity within a collaborative
reference environment shared by the team
use of standardized company engineering approach Fig. 4. System context
(ARCADIA) supported by a standard modeling tool
(Melody Advance/Capella).
The primary mission of a SAR EO system is the provision Functional chains may be easily delineated in the model just
of an End-to-End Service able to fast answer to the user needs, selecting the involved functions and functional exchanges, and
based on a flexible architecture generating and distributing that then represented in different graphical ways.
service in terms of SAR products. The End User represents in
this model a variety of users that can access the system in order
to make use of provided services and image products.
The identified system capabilities have been modeled in the
tool and further decomposed into systems functions needed to
accomplish the intended scope. The tool supports the definition
and the visualization of System Functions in a hierarchical
structure, highlighting with different colors the functions to be
guaranteed by external actors (i.e. blue boxes) and the ones to
be implemented by the System itself (green ones).
Fig. 7. Functional chain representation in the System Architecture diagram
Fig. 5. Example of System Functions hierarchical breakdown
A point of strength of Capella tool is the possibility to
represented the model through a variety of diagrams such as
functional scenarios, functional data flow, functional chain
description, exchange scenarios, mode and state diagrams,
etc… Thus, the system engineers may define different
diagrams to focus on their specific needs, the overall model
consistency being guaranteed by the tool at any time.
Fig. 8. Functional chain representation in the Function Scenario
The following figure shows an example of simplified
System Architecture diagram for the modeled EO System.
Main outcome of the System analysis has been the
functional description of system in its entirety, without
allocating the system functions to Space or Ground systems,
but modeling all functional exchanges among them (i.e.
formalization of space to ground functional interfaces).
The Logical Architecture was aimed at refining the System
analysis, by decomposing the system into logical components.
The tool supports the automatic transition of the system
functions into logical functions, to be further refined and
allocated to logical components. At this stage the ground
segment and space segment logical functions have been
identified and allocated, still maintaining the architectural
description independent from its technical implementation.
Functional breakdown, functional dataflow, functional
chains, scenarios and interfaces have been modeled, bringing to
a justified logical architecture design. A simplified example of
the EO System Logical architecture modeling is shown in the
figure.
Fig. 6. System Architecture Diagram
B. MBSE applied to a Spacecraft design
In the last decade, the TAS research and development
(R&D) collaborated with the corporate entities (THALES and
Leonardo), with the customers (e.g. ESA and ASI) and with
other space companies (e.g. in the ECSS technical memoranda
WG) to analyze and define methods to support the spacecraft
design and verification activities along the lifecycle. Examples
are the ASI CEF&DBTE project[6], ESA Virtual Spacecraft
Design initiative[7], the ESA MARVELS study [8] or the EC
FP7 Use-it-wisely project [ref. SECESA paper]. The current
approach follows a theoretical exploration of the main issues
around the application of a complete model-based
environment, associated with the application of some
Fig. 9. Functional chain representation in the System Architecture diagram
components of the overall methodology in different lifecycle
phases.
This paragraph describes the application of Capella as one
The final step to be implemented in the pilot project was
of the potential model-based tools applied to the design of a
the Physical Architecture modeling, aimed at allocating the
spacecraft applied to the early phases of design (namely phases
logical functions to physical functions and components.
A and B1 [ECSS ref.]). An overview of the association of
Different kinds of physical components may be identified and
Capella with team approach, connection with other system
specified in the tool (e.g. HW, HW computer, firmware, SW,
modeling tools and methods is then provided.
SW application, etc…). This modeling step was started for few
subsystems of interest (e.g. satellite thermal control), leaving Spacecraft design is here intended as the definition of a
its complete implementation to future or separate projects. space segment element (following ECSS definition [ref]),
according to the customer specification, leading to a spacecraft
In fact, since Arcadia method may be applied in a recursive
architecture able to provide the breakdown in sub-components
way at each level of system breakdown, a subsystem of the
and allocate the relevant functions and interfaces to each
current system may become a system in a new project/model,
component.
until single discipline subsystems or procurement items/COTS
are identified. This approach has been used during the pilot Current efforts in the space domain have been focused on
project, after the completion of the logical architecture, to the maintenance of the system consistency from a physical
“extract” the ground segment architecture and to continue its point of view, i.e. assuring a controlled exchange of data
modeling as a separate subsystem. between different disciplines, keeping under control the
resulting impact at system level of the mass, power and data
The advantage of this approach is that it allows focusing the
volume (i.e. the system budgets), across the different phases.
attention of the engineering team to the subsystem of interest
while maintaining the consistency with the overall system Capella is not meant to provide these features, even if it is
model. In fact, the tool provides the capability to: possible to enhance it through the development of viewpoints.
However, it complements such existing tools and methods with
isolate and extract in an automatic way all the additional features.
functions and interfaces to be inherited by the new
model Following the ARCADIA method, the following list
provides an example on how Capella may help the spacecraft
cross-check the consistency of the new model with the definition phase:
overall one, highlighting any divergences arisen after
the first extraction. 1) Operational Analysis
Another main advantage in the use Capella is the possibility a) Understand Customer rationale for Mission
to set-up a link between textual requirements and the model. Requirements and eventually provide a formal analysis to
This may be implemented either using the tool intrinsic improve or challenge the requirements and provide
functionality to directly trace requirements or through the use Engineering Change Notices
of other traceability tools available in the tooled-up b) provide an overview of the mission, understanding
environment provided by Thales. In this way, it is possible to the interaction between existing items (especially for
cross-validate the requirements against the architectural design spacecraft acting in an existing environment, or with a crew
solution at different levels, from the System down to the onboard)
components level. In the frame of the pilot project, TAS-I has
2) System Analysis
investigated how to set up a traceability link between DOORS
requirement database (used for EO System Requirements a) Define boundaries between Space Segment
formalization and flow down), the System model and the main (specifically the spacecraft under design), the Ground
documental outputs, to be automatically generated with proper Segment and any Supporting Space Segments (e.g. to provide
tools available in the tooled-up environment. GNSS functions, data relay, etc.)
b) verify phase by phase that the system functions are The effectiveness of Capella usage of course shall be
in place, using functional chains associated at least with:
c) Define system modes and states, combining them Shared Approach in the team: ARCADIA and
with functions and functional chains related tooling (e.g. Capella) shall not be the “System
d) model relevant scenarios for the mission, especially Engineering” or “System Architect” toy. Every single
if connected with specific requirements or to be provided as stakeholder in the system definition may profit from a
reference to different discipline specialists. structured and consistent model.
e) Understand Customer Mission and Spacecraft level Collaboration in the team: the best approach is to let
requirements, allocating them to system functions and as much as possible all the project team members have
eventually provide a proper analysis to improve or challenge a look in the model and being author of the part of
the requirements and provide Engineering Change Notices which everyone is responsible (e.g. the avionic
3) Logical Architecture architecture should be managed by the On-board data
a) allocate functions to subsystems and main logical handling S/S discipline, the Electrical Power
components (e.g. the On-board computer, the AOCS sensors Subsystem discipline, directed by the System
discipline). Concentrating the work in the hand of a
or the Power Storage)
single person, could produce a bottleneck in the
b) Define Exchange Scenarios between subsystem to effectiveness of the tool usage, so that the model is not
support the relevant specialists to understand the functional used during the design, but after the design.
interfaces
c) Decompose the functional exchanges between Collaboration between different teams and
different industrial partners: in the case of complex
Space and Ground Segment, and detail the functional
industrial set-up (especially when the different
exchanges between subsystem and main logical components subsystems are defined by different companies), a
d) Define the main component exchanges. In early collaboration process and data exchange mean shall be
phases they can be simplified as “TM” or “Signal” or “Force”, defined as early as possible. TAS is researching
but in later phases they can be detailed, especially for data efficient ways to improve this type of collaboration [9]
I/F’s, e.g. as packets or with an associated data spec.
Connection with other SE tools: Capella shall be
e) Derive Subsystem level Functional and Interface used in parallel with other System-level tools, e.g. to
Requirements manage the geometry, the exchange of technical
4) Physical Architecture parameters, the interface with discipline analysis tools.
a) Gather the relevant input from the disciplines TAS is studying efficient ways to improve this types of
specific analyses, components selection and architecture interfaces [10]
choices in order to provide a consistent physical architecture at
system level
b) Verify that all the defined functions in previous IV. CONCLUSION
levels are realized by a physical component
c) Define Physical Links as actual connections Several initiatives have been carried out in Thales Alenia
between components (e.g. a wire, a bus, an uplink connection, Space in the last years to study and experiment innovative
etc.) and allocate the related Component Exchanges System engineering practices in order to transform the
d) Define an Avionic Architecture, showing all the “traditional” way of working into a more cooperative tooled-up
approach.
relevant connections to the Power Distribution Unit and to the
On-board Computer Continuous growing of system complexity and proven
e) Allocate functions to Hardware or Software, and benefits deriving from wide collaboration between different
deploy the software to the relevant computing unit engineering disciplines and specialties during the project
lifetime brought to the development of concurrent engineering
f) Derive Equipment level Functional and Interface
practices and, consequently, to the need to provide timely and
Requirements structured access to shared information.
The Spacecraft design is not only devoted to define and
specify the components, but also to prepare the integration, In this framework, Thales Alenia Space has taken benefit
validation and verification activities. In that sense all the from Thales Group MBSE solutions, implementing the tooled-
aforementioned activities should be also coupled with the up approach in several space projects, and continuously
definition of scenarios and functional chains intended to be fostering this approach for all new complex systems.
relevant for subsequent analysis and test activities. The advantages have been already experimented in terms of
A correct functional allocation between components, and overall project consistency, team accessibility with different
also a clear definition of the main scenarios, are a good way to viewpoints, early identification of possible design issues and
anticipate potential issues in the verification philosophy already impact analysis, in case of requirement changes, automatically
in an early project phase. supported by the tool.
Nevertheless, in order to further benefit from this tooled-up Future applications of concurrent engineering methodology integrated
approach additional improvements are needed to fully exploit with knowledge based economic analyses. 3rd International Workshop
on System & Concurrent Engineering for Space Applications (SECESA
the physical level thus supporting the lower level component 2008), 15-17 2008 Rome, Italy
detailed design and support the HW and SW implementation [7] VSD website. https://www.vsd-project.org
specification. [8] M. Pasquinelli, D. Gerbaz, J. Fuchs, V. Basso, S. Mazzini, L. Baracchi,
S. Puri, L. Pace, M. Lassalle, J. Viitaniemi, Model-based approach for
the verification enhancement across the lifecycle of a space system, 6th
International Conference on Systems & Concurrent Engineering for
REFERENCES Space Applications SECESA 2014 Stuttgart, 8-10 October 2014
[9] M. Pasquinelli, V. Basso, L. Rocci, M. Cencetti, C. Vizzi, S. T. Chiadò,
Modelling and Collaboration across Organizations: issues and a solution,
[1] INCOSE Systems Engineering Handbook, fourth edition, INCOSE-TP- 7th Systems Engineering and Concurrent Engineering for Space
2003-002-04-2015 Application Conference Proceedings, 4 October 2016, In press
[2] ISO/IEC/IEEE 15288 – Systems and software engineering – System life [10] G. Garcia, X. Roser, Enhancing Integrated Design Model based process
cycle processes and engineering tool environment : towards an integration of functional
[3] ISO/IEC TR 24748 – Systems and software engineering – Life cycle analysis, operational analysis and knowledge capitalisation into in co-
managemet – Part 1, guide for life cycle management engineering practices, 7th Systems Engineering and Concurrent
[4] Pascal Roques, MBSE with the ARCADIA Method and the Capella Engineering for Space Application Conference Proceedings, 4 October
Tool, hal-01258014 (https://hal.archives-ouvertes.fr/hal-01258014), 2016, In press
January 2016
[5] Capella – https://www.polarsys.org/capella/index.html
[6] Portelli Claudio, Davighi Andrea, Del Vecchio Blanco Carlo, Basso
Valter, Belvedere Giampiero, Rosazza Prin Paolo. ASI CEF+DBTE: