Gauthier Fanmuy

Eric Goubault · Daniel Krob

François Stephan
Editors

Complex
Systems
Design
& Management
Proceedings
of the Seventh International Conference
on Complex Systems Design
& Management,
csd&m Paris 2016

123
Complex Systems Design & Management
Gauthier Fanmuy ⋅ Eric Goubault
Daniel Krob ⋅ François Stephan
Editors

Complex Systems Design

& Management
Proceedings of the Seventh International
Conference on Complex Systems Design &
Management, CSD&M Paris 2016

123
Editors
Gauthier Fanmuy Daniel Krob
Dassault Systèmes CESAMES
Vélizy-Villacoublay Paris
France France

Eric Goubault François Stephan

École Polytechnique IRT SystemX
Palaiseau Palaiseau
France France

ISBN 978-3-319-49102-8 ISBN 978-3-319-49103-5 (eBook)

DOI 10.1007/978-3-319-49103-5
Library of Congress Control Number: 2016956186

© Springer International Publishing AG 2017

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt from
the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, express or implied, with respect to the material contained herein or
for any errors or omissions that may have been made.

Printed on acid-free paper

This Springer imprint is published by Springer Nature

The registered company is Springer International Publishing AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface

Introduction

This volume contains the proceedings of the Seventh International Conference on

“Complex System Design & Management” (CSD&M 2016; see the conference
website: http://www.2016.csdm.fr/ for more details).
The CSD&M 2016 conference was jointly organized during December 13–14,
2016 at the Chesnaie du Roy at Vincennes (France) by the two following founding
partners:
1. The non-profit organization Center of Excellence on Systems Architecture,
Management, Economy and Strategy (CESAMES),
2. The Ecole Polytechnique—ENSTA ParisTech—Télécom ParisTech—Dassault
Aviation—DCNS—DGA—Thales “Engineering of Complex Systems” chair.
The conference benefited of the permanent support of many academic organi-
zations such as Ecole Polytechnique, CentraleSupélec, ENSTA ParisTech and
Télécom ParisTech which were deeply involved in its organization.
We also would like to thank the conference partners: Dassault Aviation, DCNS,
Digiteo Labs, Direction Générale de l’Armement (DGA), Institut de Recherche
Technologique (IRT) SystemX, MEGA International and Thales which were the
main industrial and institutional sponsors of the conference.
We are also grateful to several non-profit organizations such as Association
Francaise d’Ingénierie Systeme (AFIS) and International Council on Systems
Engineering (INCOSE) which strongly supported our communication effort.
All these institutions also helped us a lot through their constant participation to
the organizing committee during the one-year preparation of CSD&M 2016.
Many thanks therefore to all of them.

v
vi Preface

Why a CSD&M Conference?

Mastering complex systems requires an integrated understanding of industrial

practices as well as sophisticated theoretical techniques and tools. This explains the
creation of an annual go-between forum at European level (which did not existed
yet) dedicated to both academic researchers and industrial actors working on
complex industrial systems architecture and engineering. Facilitating their meeting
was actually for us a sine qua non condition in order to nurture and develop in
Europe the science of systems which is currently emerging.
The purpose of the “Complex Systems Design & Management” (CSD&M)
conference is exactly to be such a forum, in order to become, in time, the European
academic–industrial conference of reference in the field of complex industrial
systems architecture and engineering, which is a quite ambitious objective. The last
six CSD&M Paris conferences—which were all held the last trimester of the year
from 2010 to 2015 in Paris—were the first steps in this direction. In 2015, there
were almost 300 participants who came from 20 different countries which measures
the growing success of the CSD&M conference.

Our Core Academic—Industrial Dimension

To make the CSD&M conference this convergence point of the academic and
industrial communities in complex industrial systems, we based our organization on
a principle of complete parity between academics and industrialists (see the con-
ference organization sections in the next pages). This principle was first imple-
mented as follows:
• the program committee is composed of 50 % academics and 50 % industrialists,
• the invited speakers came in a balanced way from numerous professional
environments.
The set of activities of the conference followed the same principle. They indeed
consist of a mixture of research seminars and experience sharing, academic articles
and industrial presentations, software and training offers presentations, etc. The
conference topics cover in the same way the most recent trends in the emerging
field of complex systems sciences and practices from an industrial and academic
perspective, including the main industrial domains (aeronautic & aerospace,
transportation & systems, defense & security, electronics & robotics, energy &
environment, healthcare & welfare services, media & communications, software &
e-services), scientific and technical topics (systems fundamentals, systems archi-
tecture & engineering, systems metrics & quality, systemic tools) and system types
(transportation systems, embedded systems, software & information systems, sys-
tems of systems, artificial ecosystems).
Preface vii

The 2016 Edition

The CSD&M Paris 2016 edition received 46 submitted papers, out of which the
program committee selected 16 regular papers to be published in the conference
proceedings. A 29 % acceptance ratio was reached which guarantees the high
quality of the presentations. The program committee also selected 17 papers for a
collective presentation during the poster workshop of the conference.
Each submission was assigned to at least two program committee members, who
carefully reviewed the papers, in many cases with the help of external referees.
These reviews were discussed by the program committee during an online meeting
by the May 30, 2016 and via the EasyChair conference management system.
We also chose nine outstanding speakers with various industrial and scientific
expertise who gave a series of invited talks covering all the spectrum of the con-
ference during the two days of CSD&M Paris 2016. The conference was organized
around a common topic: Challenges & Opportunities of Systems Engineering in a
Changing World. Each day proposed mix invited keynote speakers presentations
and a “la carte” program comprising accepted papers presentations and conference
partners’ workshops.
Furthermore, we had a poster workshop, for encouraging presentation and dis-
cussion on interesting but “not-yet-polished” ideas. CSD&M Paris 2016 also
offered booths and presentations to provide each participant a good vision of the
latest engineering and technological news.

Paris, France Gauthier Fanmuy

August 2016 Eric Goubault
Daniel Krob
François Stephan
Conference Organization

Conference Chairs

General Chair
Daniel Krob, Incose Fellow, CESAMES and Ecole Polytechnique, France

Organizing Committee Chair

François Stephan, IRT SystemX, France

Program Committee Co-Chairs

Gauthier Fanmuy, Dassault Systemes, France (industrial co-chair)
Eric Goubault, Ecole Polytechnique, France (academic co-chair)

Program Committee

The program committee consists of 21 members (10 academic and 11 industrial) of

high international visibility. Their expertise spectrum covers all of the conference
topics.

Academic Members

Co-Chair
Eric Goubault, Ecole Polytechnique, France

Members
Aleida Aleti, Monash University, Australia
Eric Bonjour, ENSGSI, France
Thao Dang, Verimag, France
Mike Hinchey, University of Limerick, Ireland
Daisuke Ishii, Fukui University, Japan

ix
x Conference Organization

Claire Pagetti, Onera, France

Antoine Rauzy, Norwegian University of Science and Technology, France
Donna Rhodes, MIT, USA
Rafael Wisniewski, Aalborg University, Denmark

Industrial Members

Co-Chair
Gauthier Fanmuy, Dassault Systemes, France

Members
Sylvain Chabroux, LGM, France
Alain Dauron, Renault, France
Jeremy Dick, SyntheSys, UK
Jean-Paul Fardel, Airbus, France
Ali Koudri, IRT SystemX, France
Pascal Lamothe, PSA, France
Nicolas Gueit, Snecma, France
Garry Roedler, LMCO, France
Sven-Olaf Schulze, Unity AG, Germany
Lucio Tirone, Aster S.p.A., Italy

Organizing Committee

The organizing committee consists of 18 members (academic and industrial) of

high international visibility. The organizing committee is in charge of defining the
program of the conference, identifying keynotes speakers and has to ensure the
functioning of the event (sponsoring and communication).

Chair
François Stephan, IRT SystemX, France

Members
Emmanuel Arbaretier, Airbus, France
Philippe Bourguignon, Engie, France
Alain Carof, DCNS, France
Etienne De Pommery, IRT SystemX, France
Johan D’Hose, Systematic Paris Region, France
Eric Duceau, Airbus, France
Brigitte Dueme, INRIA, France
Didier Dumur, Centralesupelec, France
Pascal Foix, Thales, France
Bruno Foyer, IRT SystemX, France
Vincent Gauthier, Telecom ParisTech, France
Conference Organization xi

Omar Hammami, ENSTA, France

Michel Pinget, Dassault Aviation, France
Pascal Poisson, Alstom Transport, France
Garry Roedler, INCOSE, USA
Alain Roset, La Poste, France
Sylvie Tonda Goldstein, Ecole Polytechnique, France

Invited Speakers

Thierry Brizard, Executive Vice President Technology, CGG, France

Paul Eremenko, Chief Technology Officer, Airbus Group, France and Germany
Alan D. Harding, INCOSE President, UK
Paulien Herder, Head of the Engineering Systems and Services Department at the
Faculty of Technology, Policy and Management, Delft University of Technology,
Netherlands
Thierry Jean-Marius, Head of Systems Engineering Department, Airbus Safran
Launchers, France
Virginie Maillard, Vice President Research, Renault, France
Garry Roedler, Incose Fellow and Engineering Outreach Program Manager,
Lockheed Martin Corporation, USA
Matthew Silver, CEO and Founder, Cambrian Innovation, USA
Henri Verdier, Interministerial Director of the Digital Technology and the Infor-
mation and Communication System of the French government (DINSIC), France
Acknowledgements

We would like to thank all members of the program and organizing Committees for
their time, effort, and contributions to make CSD&M Paris 2016 a top-quality
conference. Special thanks addressed to the CESAMES non-profit organization
team which managed permanently with huge efficiency all the administration,
logistics and communication of the CSD&M Paris 2016 conference (see http://
www.cesames.net/).
The organizers of the conference are also greatly grateful to the following
sponsors and partners without whom the CSD&M Paris 2016 event would not exist:
• Founding Partners
– CESAMES—Center of Excellence on Systems Architecture, Management,
Economy and Strategy,
– Ecole Polytechnique—ENSTA ParisTech—Télécom ParisTech—Dassault
Aviation—DCNS—DGA—Thales “Engineering of Complex Systems”
Chair.
• Academic Sponsors
– Ecole Polytechnique,
– CentraleSupélec,
– ENSTA ParisTech,
– Télécom ParisTech.
• Industrial and Institutional Sponsors
– Airbus Apsys,
– Dassault Aviation,
– DCNS,
– Digiteo labs,
– Direction Générale de l’Armement (DGA),
– Institut de Recherche Technologique IRT SystemX,
– MEGA International,

xiii
xiv Acknowledgements

– PPI,
– Thales.
• Supporting Partners
– Association Française d’Ingénierie Système (AFIS),
– International Council on Systems Engineering (INCOSE).
• Participating Partners
– Anylogic,
– CCES—MIT,
– IBM Analytics,
– No Magic Europe,
– Obeo,
– PragmaDev,
– The CoSMo Company.
Contents

Part I Regular Papers

Challenges for MBSE and PLE for Legacy Product-Based
System Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Michael Schäfer, Friedemann Bitsch, Stephan Weißleder
and Florian Wartenberg
The Trans-Alaska Pipeline System: A Systems Engineering
Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Robert S. Swarz
MBSE, PLM, MIP and Robust Optimization for System
of Systems Management, Application to SCCOA French
Air Defense Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Thomas Peugeot, Nicolas Dupin, Marie-Joëlle Sembely
and Catherine Dubecq
Disruptive Innovation in Complex Systems: The Ambition
of Combining Systems Engineering and Design Thinking . . . . . . . . . . . . 41
Arnaud Durantin, Gauthier Fanmuy, Ségolène Miet and Valérie Pegon
Validation of Industrial Cyber-Physical Systems:
An Application to HVAC Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Thao Dang, Alie El-Din Mady, Menouer Boubekeur, Rajesh Kumar
and Mark Moulin
Modelling and Simulation of the Dynamics of Complex
Socio-Cyber-Physical Systems and Large Scale Systems
of Systems all Along Their Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Nguyen Thuy
Defining a Distributed Architecture for Smart Energy
Aware Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Guillaume Habault, Jani Hursti and Jean-Marie Bonnin

xv
xvi Contents

Incremental Modeling Methodology of Railway

System Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Melissa Issad, Leila Kloul and Antoine Rauzy
Automated Piping with Standardized Bends in Complex Systems
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Samuel Vogel and Stephan Rudolph
Assessment of Resilience in Desalination Infrastructure
Using Semi-Markov Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Abdulaziz Khiyami, Andrew Owens, Abdelkrim Doufene,
Adnan Alsaati and Olivier de Weck
A Discrepancy-Based Framework to Compare Robustness
Between Multi-attribute Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Juste Raimbault
Complexity Management for Engineered Systems Using
System Value Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Kaushik Sinha, Narek R. Shougarian and Olivier L. de Weck
Empirical Studies in Decision Rule-Based Flexibility Analysis
for Complex Systems Design and Management . . . . . . . . . . . . . . . . . . . . 171
Michel-Alexandre Cardin, Yixin Jiang and Terence Lim
Requirements Quality Analysis: A Successful Case Study
in the Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Elena Gallego, Hugo-Guillermo Chalé-Góngora, Juan Llorens,
José Fuentes, José Álvarez, Gonzalo Génova and Anabel Fraga
Systems Engineering Education for East Africa . . . . . . . . . . . . . . . . . . . . 203
Solomon Gebreyohannes, Tadilo Endeshaw Bogale, William Edmonson
and Lakemariam Yohannes Worku
Systems Engineering Human Capital Development:
Objectives and Research Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Jon Wade

Part II Posters
System Engineering Education for Confirmed Engineers:
The FAIS Case Study—A 6 Years Feedback . . . . . . . . . . . . . . . . . . . . . . 229
Omar Hammami

Integration of Systems Engineering Approach

in Product-Lifecycle-Management by Means
of a Mechatronic System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Vahid Salehi, Lukas Burseg, Kristin Paetzold, Abdo Chahin, Jihad Taha
and Thomas Rieger
Contents xvii

Performance Analysis of SDL Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Mihal Brumbulli and Emmanuel Gaudin
Prerequisites for the Modelling and Analysis of a Product
Development Process Using Network Theory . . . . . . . . . . . . . . . . . . . . . . 235
Abdo Chahin, Julian Hoffmeister, Kristin Paetzold and Vahid Salehi
Challenges of Agile Development: A Cause-and-Effect Analysis . . . . . . . 237
Tobias Sebastian Schmidt and Kristin Paetzold
MBSE and MBSA with Capella and Safety Architect Tools . . . . . . . . . . 239
Marc Sango, Frédérique Vallée, Anne-Catherine Vié, Jean-Luc Voirin,
Xavier Leroux and Véronique Normand
Resilience Analysis on Infrastructure Networks
with Heterogeneous Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
C.Y. Lam and K. Tai
Direct Democracy as the Keystone of a Smart City Governance
as a Complex System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Claude Rochet
Fast and Extensive Model Based Project Plan Building
in Nuclear Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Christian Marie, Gilles Beuzelin, Samuel Boutin and Eric Nicole
B4B, a System of System Development Based on Systems
Engineering Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Yann Chazal, Philippe Toussaint and Do-Hieu Trinh
Categorizing Technical Change in a System: Resolving Some
of the Shortcomings in Henderson & Clarck’s (1990) Framework . . . . . 249
Mohammadreza Arasti and Mahdi Khaleghi
Exploring Early Stage Cost-Estimation Methods Using
Off-the-Shelf Tools: A Preliminary Study . . . . . . . . . . . . . . . . . . . . . . . . . 251
Haifeng Zhu, Narek Shougarian, Greg Ojard, Kaushik Sinha,
Oliver de Weck and Eileen Arnold
A Framework for Understanding the Complexity of Regional
Production Networks: A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Larissa Statsenko and Vernon Ireland
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
 Part I
Regular Papers
Challenges for MBSE and PLE for Legacy
Product-Based System Environments

Michael Schäfer, Friedemann Bitsch, Stephan Weißleder

and Florian Wartenberg

Abstract Model-Based System Engineering (MBSE) and Product Line Engi-

neering (PLE) are well-known approaches in industry for the management and
design of the architecture of complex systems. The railway signalling business has
some specific characteristics that need to be considered in system engineering:
railway signalling systems have a long life time and new systems have to integrate
interfaces to many types of legacy railway safety products. This situation has led to
different technical system approaches: railway infrastructure companies as cus-
tomers prefer either turn-key projects fulfilled by one supplier or tend to define
individual subsystems that can be integrated to a complete system. This article
shows how Thales masters both approaches by using the method ARCADIA and
the open source modelling tool Capella in the specific case of pre-existing sub-
systems and how the resulting variability is handled. An outlook will be given to
extensions that allow an early safety analysis of models and will provide support for
automatic test design.

M. Schäfer (✉) ⋅ F. Bitsch

Thales Deutschland, Geschäftsbereich Transportation Systems, Thalesplatz 1,
71254 Ditzingen, Germany
e-mail: [email protected]
F. Bitsch
e-mail: [email protected]
S. Weißleder ⋅ F. Wartenberg
Thales Deutschland, Geschäftsbereich Transportation Systems, Schützenstraße 25,
10117 Berlin, Germany
e-mail: [email protected]
F. Wartenberg
e-mail: [email protected]

© Springer International Publishing AG 2017 3

G. Fanmuy et al. (eds.), Complex Systems Design & Management,
DOI 10.1007/978-3-319-49103-5_1
4 M. Schäfer et al.

1 Introduction

1.1 History of Railway Signalling Systems

Railway signalling systems have been developed for more than 150 years to ensure
the safe movement of trains [1, 2], offering the following basic functionalities:
(a) Provide a safe running path for each train in the railway network, avoiding
collisions between different trains.
(b) Ensure that the train speed does not exceed a specific speed limit and espe-
cially that a train comes to stop in front of a signal at danger. This functionality
avoids derailments due to excessive speed as well as collisions due to signals
passed at danger.
In the past, separate systems have been developed for these basic functions: For
providing a safe running path the so-called “interlocking” was invented. In the last
150 years the realizing technology has evolved from mechanical via electrical to
software based systems, but the basic signalling and interlocking principles have
remained the same.
Systems that control the correct movement of a train are called train control
systems. Accidents, where trains wrongly passed a signal showing a danger aspect,
have led to country dependent control systems that warn the train driver or auto-
matically stop the train in such a situation. A unique European solution, the
European Train Control System ETCS [3] has been developed over the last
20 years.
This historical evolution leads to a complex legacy environment for any new
railway signalling application. New applications and systems have to be compatible
with the installed base of signalling systems. Typical examples are:
• New computer based interlocking systems have to provide interfaces to a
neighbouring railway station equipped with a mechanical interlocking built in
1900.
• New ETCS systems need to be combined with existing relay interlocking sys-
tems built in the 1950s.
Beside these legacy problems a manufacturer is confronted with two other
issues: On the one hand all legacy or new interfaces differ from country to country.
Even if they are generally standardized (e.g. ETCS) the required functionality is
different for each country. So systems need to be adapted for every railway
infrastructure company. On the other hand, systems grow more and more together.
In the past interlocking train control systems were operated by different staff and
have been loosely coupled. To save expenses by reducing the number of staff,
systems get more and more coupled to automate and integrate operation.
Challenges for MBSE and PLE … 5

1.2 Different Architectural Approaches

Faced with these problems, railway infrastructure operating companies like DB

Netz, NetworkRail or SNCF Réseau follow different approaches:
One type of infrastructure company selects a complete renewal of all compo-
nents of the railway signalling system all at once. An example is the Danish
re-signalling programme [4]: From 2017 to 2021 the complete signalling system in
the whole country will be replaced by an ETCS based system. A huge amount of
money and the willingness to adapt long-term grown operational procedures to the
new system concept are basic preconditions for this approach.
In comparison to this revolutionary approach, other operating companies agreed
on a common architectural model specified in the European initiative EuLynx [5].
This architecture can be regarded as an extension of ETCS towards interlocking
systems. But because of the different operational concepts the operating companies
agreed on an interface model only: The detailed functions of each subsystem may
differ from railway operator to railway operator. This evolutionary approach has the
advantage that an upgrade of the railway system can be done step-by-step migrating
to the EuLynx architecture. But it takes time and does not solve the problem of the
large heterogeneity of the installed base.

2 Existing Approaches in System Engineering

Confronted with the diversity in the landscape of legacy systems described above,
Thales selected in the past classical system engineering to manage the complexity of
the systems. This chapter describes these approaches and the resulting consequences.

2.1 Requirements Management

Thales decided first to apply the methods of classical requirements engineering to

cover the complexity. Customer requirements were transferred to system require-
ments and were distributed as requirements to the different subsystems:
This method ensured that no customer requirements defined by the railway
operating company were missing. It also provided a good basis for testing the
overall system as well as the different subsystems. But as Fig. 1 shows, this process
has some disadvantages:
(a) Customer requirements are typically non-homogenous. In some areas cus-
tomers are very experienced, so their requirements tend to be detailed. These
requirements can be allocated nearly directly to a subsystem (shown as
magenta in Fig. 1). In other areas (esp. the newer ones like ETCS) you may
receive as supplier only very rough and fuzzy requirements that need to be
6 M. Schäfer et al.

Fig. 1 Refinement of
requirements

detailed and interpreted before they can be processed further. Concerning the
legacy systems to be interfaced both variants exists: Some customers describe
them in detail, while others may only provide a single requirement that a
specific legacy system needs to be adapted.
(b) The refinement process is not only a requirements management process but
also becomes an architectural process. Requirements are allocated to subsys-
tems as functions and interfaces between the subsystems are defined, which
are typically architectural tasks and not requirements management tasks
(shown in orange in Fig. 1).
(c) Because the system requirements form the interface towards the customer,
every detail that needs to be discussed with the customer is contained in the
system requirements specification. This leads to an explosion of the number of
requirements objects. The following list shows some examples:
• North-South Railway Saudi-Arabia: 2,730 valid requirements
• Danish re-signalling Programme: 5,600 valid requirements
It is obvious that this number can only be handled by persons that are deeply
involved in a project. For newcomers these documents are nearly unreadable.
(d) Every system requirements specification is customer specific. A product line
management approach was not applied, because each project organisation
used to run requirement engineering to issue their perception of what the
system of interest should do in support of the expected operational capabilities
of the single customer. This approach hinders reuse: the same requirements
could be interpreted differently, the same property can be described by dif-
ferent requirements sets. Functionality existing in different variants is not easy
transferable, because already the system requirements specifications differ in
form and content. This is a major problem concerning the legacy environment:
A legacy interface realized for specific customer could not be easily trans-
ferred to a different customer, not to mention the case that this interface needs
to be adapted.
Several approaches have been implemented to overcome this situation. One
promising approach was to use Use-Cases in a textual form instead of classical
Challenges for MBSE and PLE … 7

requirements. This approach leads to better understanding and structuring of cus-

tomer requirements, but it does not solve the problem that architectural tasks were
done with the wrong methodology of requirements management.

2.2 Modelling in UML/SysML

In parallel to the approach of requirements management, modelling of system

architectures with UML or SysML was started. These architectural drawings focus
on a reverse engineering of the existing system architecture. They show the logical
or the physical structure of the overall system and help people (from supplier and
customer) to get a better understanding of how all the subsystems already men-
tioned in the System Requirements Specification are combined together.
But in combination with the classical requirements process listed above, several
issues came up, that led to the fact that the modelling was regarded only as an
additional task:
(a) Because the functionality was already defined and allocated in the require-
ments specification, the system architectural models and figures contain only
boxes describing the system components and the (physical) interfaces but not
their functionality. Often the tools are only used as drawing tools without
relying on the specific advantages of a model in the background. An example
is given in Fig. 2, which shows the high-level logical component structure of
the system, the interfaces between the components and the surrounding actors.

Fig. 2 UML component diagram of a signalling system

8 M. Schäfer et al.

(b) UML and SysML are languages for modelling, they provide many different
views, but they do not provide a methodology that helps system architects to
know what to model in a diagram. This led even more so than in the area of
requirements management to the problem that models and diagrams differ
from project to project.
(c) The project-centric view results often in the case that legacy systems, even if
they contribute largely to the system functionality, have been modelled only as
external actors. This results in the problem that the next project, which needs
this functionality (e.g. in a new implementation) could not reuse the model.

2.3 Results of Classical System Engineering

Classical System Engineering helped Thales to develop and deliver new railway
signalling systems also in large and complex legacy environments. But it demon-
strates also the limits of this methodology:
Handling of requirements specifications and system models becomes complex
and heterogeneous. Legacy systems could be integrated, but the whole approach
shows no concept for reusability.

3 Model-Based System Engineering and Product Line

Approach

3.1 ARCADIA and Capella as a Basis

The system architecture methodology ARCADIA (ARChitecture Analysis and

Design Integrated Approach) is a well-known methodology that empowers system
engineers to solve the problems listed above. An overview of the methodology is
given in [6].
Two major aspects of the methodology are the basis to overcome the issues
described above:
ARCADIA is a methodology that is view point driven. It provides four basic
views of the system necessary for the different stakeholders as shown in Fig. 3:
(a) The operational view, showing the customer’s needs
(b) The system view showing what the system should provide
(c) The logical architecture showing how the subsystems provide this
functionality
(d) The physical architecture showing the implementation of the functionality
ARCADIA is a “supplier-oriented” method in contrast to “customer-oriented”
methods like “Zachman” or “NAF”, which focus more on users capability,
Challenges for MBSE and PLE … 9

Fig. 3 Views of ARCADIA

acquisition and deployment. ARCADIA targets detailed solution definition and

assessment:
• separating need and solution by applying different views,
• supporting stakeholders collaboration,
• dealing with complexity management,
• architecture evaluation, enforcing “correct by construction” modelling
Detailed Information about ARCADIA and the associated meta-model is pro-
vided in [7].
ARCADIA is a functional driven methodology. ARCADIA integrates the
functional aspects originally covered by the requirements management directly with
architectural aspects of subsystem allocation and implementation.
Capella is an Eclipse-based open source tool implementing the methodology of
ARCADIA [8]. It was originally developed by Thales as an internal tool called
Melody, so both names Capella and Melody are sometimes used as synonyms.

3.2 Reference System Architecture for High-Level PLE

ARCADIA as a method and Melody/Capella as a tool have been already applied in

railway signalling business [9]. But this approach shows also that the methodology
needs to be supplemented:
10 M. Schäfer et al.

A specialisation of the methodology with railway signalling in mind was nec-

essary. Although ARCADIA is a good framework for the system architecture it
provides a lot of variants for the different viewpoints. For railway signalling sys-
tems, adequate modelling means were defined based on the available set. How this
could be achieved is explained in detail in [10] for the model of the signalling
system for the Passenger Rail Agency of South Africa “West Cape Region” (RSA
project). The major result was that for each view (operational, system need analysis,
logical architecture, and physical architecture), the model should be separated into
three different but interrelated areas:
• Static architecture.
• Functional split
• Behaviour specification
The static architecture contains the structural description of the system. On the
different views of ARCADIA this results in:
• Operational view: Operational architecture diagrams showing the operational
entities in the system context and their relations.
• System view: System context diagrams illustrating the external system rela-
tionships and defining the outside border of the system.
• Logical view: Architectural diagrams describing the logical structure of the
subsystems including their interconnections.
• Physical view: Architectural diagrams including the realization of the logical
subsystems using software and hardware components.
The application of the functional split is an essential change to existing
approaches. The system functions defined in the system view of ARCADIA are
distributed on the subsystems of the static architecture. This functional split helps
the architects to find a meaningful division into subsystems. So both areas are
linked together as shown in Fig. 4 by the red arrows.

Fig. 4 Functional split in ARCADIA

Challenges for MBSE and PLE … 11

The behaviour specification is the description of the detailed behaviour of each

function.
Looking at the legacy environment described above in Chap. 2 it is essential to
have this environment in mind. The borders and the functionality of existing sys-
tems have to be modelled in order to use the approach in legacy environments. But
it is necessary not only to model the existing architecture, but also to keep a
meaningful sub-division in mind. This leads to the fact that sometimes system
functions need to be split into more logical functions than originally intended to
provide a possibility to model legacy subsystems as well as new subsystems, too.
This approach leads to the next step, the introduction of variants to achieve
reusability. Product Line Engineering with feature based variants is a
well-established method to handle variability in software engineering [11]. The
product line extension of the architecture of the Thales railway signalling system is
called Reference System Architecture. Based on the modelling rules defined above
a model is created that defines a standard architecture for a railway signalling
system consisting of interlocking and train control systems. To enable Product Line
Engineering this Reference System Architecture contains high level variants:
Depending on a feature selection, either a legacy interlocking system or an inte-
grated interlocking could be selected, as shown in Fig. 5 for a simplified example of
route and signal handling.
Figure 5 shows that on the logical architecture level due to appropriate dimen-
sioning of the subsystems no variant exists. Only on the physical level do different
variants exist that can be selected during composition of a specific solution. It has to
be stated clearly that not all possible variants are handled on this high system level.
Detailed behavioural variants e.g. of interlocking logic or in the calculation of a
movement authority in the train control system will be handled by (software)
product line engineering on subsystem level. This approach helps to manage and
reduce complexity and heterogeneity in way that they are only visible when needed.

4 Future Work

4.1 Model-Based Safety Analyses

Currently Thales is working on an approach to extend the ARCADIA methodology

for safety analysis techniques. Safety analysis shall be based on the models of the
System Architectural Design and the System Definition. It has to be avoided that
safety engineers develop implicitly own system definitions for their safety analysis
e.g. for the Technical Safety Report or for the architecture of Fault Trees. Therefore
in our approach the fault tree analysis is based on the models in Capella. For that
reason the model is enriched with corresponding failures and possibly also with
failure rates (failure injection).
12 M. Schäfer et al.

Fig. 5 Variants in railway signalling reference architecture

In order to identify errors in the manual Fault Tree analysis a fault tree is also
automatically derived from the model and the result with the minimal cut sets can
be used for the verification of the manual creation of the Fault Tree. On the basis of
the derived fault tree structure and the specified failure rates in the model hazard
rates can be calculated automatically.
For that purpose relevant parts of the Capella model are transformed into a
formal framework, which is manually supplemented to a complete formal model by
specifying the comprehensive internal behaviour of components in a formal
language.
This formal model can then be also used for formal verification of safety
requirements by model checking. Different model checking techniques shall be
combined so that the most effective technique for the respective model structure can
be chosen. In this way the correctness of the system definition in relation to the
safety requirements can be shown.
As a consequence it is ensured that the safety case has the same basis as the
system definition used in system engineering.