Complex Systems Design & Management: Proceedings of the Tenth International Conference on Complex Systems Design & Management, CSD&M Paris 2019 [1st ed. 2020] 978-3-030-34842-7, 978-3-030-34843-4

Table of contents :
Front Matter ....Pages i-xvi
Front Matter ....Pages 1-1
Gas Turbine Design at Rolls-Royce – Exploring the Limitations of a Systems Engineering Approach (Jonathan Holt, David Elam, James Tooke)....Pages 3-13
Managing the Complexity of Processing Financial Data at Scale - An Experience Report (Sebastian Frischbier, Mario Paic, Alexander Echler, Christian Roth)....Pages 14-26
Verification of BPMN Models (Mihal Brumbulli, Emmanuel Gaudin, Frédéric Berre)....Pages 27-36
Synchronization of System Architecture, Multi-physics and Safety Models (Michel Batteux, Jean-Yves Choley, Faïda Mhenni, Luca Palladino, Tatiana Prosvirnova, Antoine Rauzy et al.)....Pages 37-48
Managing Margins Under Uncertainties Surrogate Modelling and Uncertainty Quantification (Kyle Hall, Peter Schroll, Sanjiv Sharma)....Pages 49-63
Implementing Organizational Cybernetics for the Next Generation of Digital Business Models (Alan Martin Redmond, Loic Chanvillard)....Pages 64-78
Identifying Focal Points in IT Project Governance Using a Synthetic and Systems Thinking Approach (Rani Yesudas, Mahmoud Efatmaneshnik, Keith Joiner)....Pages 79-92
MAESTRIA: A New Tool to Support Collaborative Building and Sharing of an Integration, Verification, Validation, and Qualification Strategy (Patrick Esteve, Benoit Langlois, Lyes Chabani, Willy Platzer, Jacky Mouchoux)....Pages 93-102
School Shootings in the U.S. – Where to Begin (Bruce A. Normann, Mo Mansouri)....Pages 103-116
Smart Component Modeling for Complex System Development (Philipp Helle, Sergio Feo-Arenis, Andreas Mitschke, Gerrit Schramm)....Pages 117-128
Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems (Steffen O. P. Blume, Michel-Alexandre Cardin, Giovanni Sansavini)....Pages 129-140
A Multiobjective Systems Architecture Model for Sensor Selection in Autonomous Vehicle Navigation (Anne Collin, Afreen Siddiqi, Yuto Imanishi, Yukti Matta, Taisetsu Tanimichi, Olivier de Weck)....Pages 141-152
Simulation Architecture Definition for Complex Systems Design: A Tooled Methodology (Jean-Patrick Brunet, Henri Sohier, Mouadh Yagoubi, Mathieu Bisquay, Pascal Lamothe, Pascal Menegazzi)....Pages 153-163
Towards a Cross-Domain Modeling Approach in System-of-Systems Architectures (Boris Brankovic, Christoph Binder, Dieter Draxler, Christian Neureiter, Goran Lastro)....Pages 164-175
Safety Demonstration of Autonomous Vehicles: A Review and Future Research Questions (Tchoya Florence Koné, Eric Bonjour, Eric Levrat, Frédérique Mayer, Stéphane Géronimi)....Pages 176-188
Front Matter ....Pages 189-189
Model-Based Specification for System Development with Suppliers (Phanikrishna Thota, Simon Hancock, Mario Noriega-Fogliani, Rodrigo Jimenez)....Pages 191-191
Applications of Systems Thinking for Scooter Sharing Transportation System (Christina Caches, Mo Mansouri)....Pages 192-192
Collaborative Decision-Making Challenges in the Dutch Railway System (N. Jakubeit, M. Rajabalinejad, A. J. J. Braaksma, L. A. M. van Dongen)....Pages 193-193
Understanding Stakeholder Interactions Impacting Human Spaceflight Funding Levels (Brian M. Gardner, Mo Mansouri)....Pages 194-194
Back Matter ....Pages 195-196

Citation preview

Guy André Boy Alan Guegan · Daniel Krob Vincent Vion Editors

Complex Systems Design & Management Proceedings of the Tenth International Conference on Complex Systems Design & Management CSD&M Paris 2019

Complex Systems Design & Management

Guy André Boy Alan Guegan Daniel Krob Vincent Vion •

•

•

Editors

Complex Systems Design & Management Proceedings of the Tenth International Conference on Complex Systems Design & Management, CSD&M Paris 2019

123

Editors Guy André Boy Laboratoire Génie Industriel University of Paris-Saclay Gif-sur-Yvette, France Daniel Krob CESAMES Paris, France

Alan Guegan Sirehna Bouguenais, France Vincent Vion Route de Gizy - CC VV163 Velizy-Villacoublay, France

ISBN 978-3-030-34842-7 ISBN 978-3-030-34843-4 https://doi.org/10.1007/978-3-030-34843-4

(eBook)

© Springer Nature Switzerland AG 2020 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, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

Preface

Introduction This volume contains the proceedings of the 10th International Conference on “Complex Systems Design & Management” (CSD&M 2019)—refer to the conference Web site https://www.2019.csdm.fr/ for more details. The CSD&M 2019 conference was organized by CESAM Community from December 12 to 13, 2019, at the Cité Internationale Universitaire de Paris (France) and managed by Center of Excellence on Systems Architecture, Management, Economy & Strategy (CESAMES). The conference also benefited from the technical and financial support of many organizations such as Airbus, ArianeGroup, IRT SystemX, MEGA International, and Renault. Our sincere thanks, therefore, to all of them. Many other organizations were involved in the CSD&M 2019 committees. We would like to thank all their members who helped a lot through their participation and contribution during the one-year preparation of the conference.

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 exist before—both dedicated to 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. Its aim is to progressively become 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 nine CSD&M conferences—which were all held in the last part of the

v

vi

Preface

year from 2010 to 2018 in Paris—were the first steps in this direction. In 2018, participants were again almost 230 to attend our two-day conference which proves that the interest for architecture and systems engineering does not fade.

Our Core Academic—Industrial Dimension To make the CSD&M conference a convergence point between the academic and industrial communities in complex industrial systems, we based our organization on a principle of parity between academics and industrialists (see the conference organization sections in the next pages). This principle was first implemented as follows: – program committee consisted of 50% academics and 50% industrialists, – 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 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 (aeronautics and aerospace, transportation and systems, defense and security, electronics and robotics, energy and environment, healthcare and welfare services, and media and communications, and software and e-services), scientific and technical topics (systems fundamentals, systems architecture and engineering, systems metrics and quality, systemic tools), and system types (transportation systems, embedded systems, software and information systems, systems-of-systems, and artificial ecosystems).

The 2019 Edition The CSD&M 2019 edition received 25 submitted papers, out of which the program committee selected 16 regular papers to be published in the conference proceedings. The program committee also selected five 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 that took place by July 3, 2019, and was managed via the EasyChair conference system. We also chose several outstanding speakers with industrial and scientific expertise who gave a series of invited talks covering all the spectrum of the conference during the two days of CSD&M 2019. The conference was organized around a common topic: “Systems engineering through the ages”. Each day

Preface

vii

proposed various invited keynote speakers’ presentations and a “à la carte” program consisting in accepted paper presentations and in different sessions (sectorial tracks on Day 1 and thematic tracks on Day 2). Furthermore, we had a “poster workshop,” to encourage presentation and discussion on interesting, but “not-yet-polished,” ideas. Finally, CSD&M 2019 also offered booths presenting the last engineering and technological news to participants. August 2019

Guy André Boy Alan Guegan Daniel Krob Vincent Vion

Conference Organization

Conference Chairs General Chair Daniel Krob

CESAMES and Ecole Polytechnique, France

Organizing Committee Chair Alan Guegan

Sirehna, France

Program Committee Co-chairs Guy André Boy (Academic Co-chair) Vincent Vion (Industrial Co-chair)

CentraleSupélec & ESTIA Institute of Technology, France PSA, France

Program Committee The program committee consists of 20 members (ten academics and ten industrialists) of high international visibility. Their expertise spectrum covers all of the conference topics. Academic Members Co-chair Guy André Boy

CentraleSupélec & ESTIA Institute of Technology, France

ix

x

Members Jutta Abulawi Alain Bernard Eric Bonjour Michel-Alexandre Cardin Donna Rhodes Antoine Rauzy Paul Schreinemakers Rob Vingerhoeds Bernard Yannou

Conference Organization

Hamburg University of Applied Sciences, Germany Ecole Centrale de Nantes, France ENSGSI, France Imperial College London, UK MIT, USA Norwegian University of Science and Technology, France EMEA INCOSE, Netherlands ISAE-SUPAERO, France CentraleSupélec, France

Industrial Members Co-chair Vincent Vion

PSA, France

Members Christophe Alix Alain Dauron Pierre de Chazelles Bernardo Delicado Jérémy Dick Nicolas Gueit Olivier Hayat Jonathan Holt Toby Lawrence

Thales, France Renault, France Airbus, France MBDA, Spain Costain Group, UK Safran Aircraft Engines, France PSA, France Rolls Royce, UK Jaguar Land Rover, UK

Organizing Committee The organizing committee consists of 17 members (academics and industrialists) of high international visibility. The organizing committee is in charge of defining the program of the conference and of identifying the keynote speakers. The organizing committee also has to ensure the functioning of the event (sponsoring, communication…). Chair Alan Guegan

Sirehna, France

Members Emmanuel Arbaretier Jean-François Bigey

APSYS, France MEGA International, France

Conference Organization

Philippe Bourguignon Philippe Bouteyre François Coallier Eric Duceau Gauthier Fanmuy Pascal Foix Jean-Luc Garnier Philippe Gicquel Omar Hammami Fabien Mangeant Luca Palladino Richard Schomberg Amaury Soubeyran Pierre Thory

xi

Engie, France TechnipFMC, France Ecole de Technologie Supérieure, France Airbus, France Dassault Systèmes, France Thales, France Thales, France AFIS, France ENSTA ParisTech, France Renault, France Safran, France EDF, France Airbus, France Sextant, France

Invited Speakers Plenary Sessions Alain Tropis Olivier De Weck Michael Webber Florian Guillermet Marc Peyrichon Antoine Rauzy Alexandre Corjon

Daniel Krob

SVP Digital Design Manufacturing & Services, Airbus Professor of Aeronautics, Astronautics and Engineering Systems, MIT Chief Science and Technology Officer, Engie Executive Director, SESAR Joint Undertaking Responsible for Leading System Engineering, Naval Group Professor, Norwegian University of Science and Technology Alliance Global VP Engineering Electrics/Electronics and System, Renault-Nissan Institute Professor at Ecole Polytechnique, President of CESAMES—INCOSE Fellow

“New Mobilities” Track Ariel Sirat Franck Davoine Michael Jastram

Director, IRT AESE Saint Exupery CNRS Researcher, Heudiasyc, UTC Compiègne, Labex MS2T Senior Solutions Architect, Jama Software

xii

Conference Organization

“Energy” Track Alain Poincheval Jan Andreas Thierry Chevrot

President, TechnipFMC CEO, Anleg GmBH Digiref Project Manager, Total E & P

“Smart Cities” Track Guillaume Farny Serge Salat Gauthier Fanmuy

Director, ATEC ITS FRANCE President, Urban Morphology and Complex Systems Institute Systems Engineering Role Portfolio Director, Dassault Systèmes

“Modeling, Simulation, Visualization” Track Marco Ferrogalini Philippe Duluc

Vice President, Head of Modeling and Simulations (MBSE), Airbus CTO, Big Data & Security, Atos

“Industry 4.0” Track Oussama Cherif Jean-Marc Chatelanaz Paul Labrogère

Innovation Director, Five Group VP, Full Track & Trace, Renault CEO, IRT SystemX

“Systems-of-Systems” Track Jakob Axelsson André Ayoun Michael Pfenning

Senior Research Leader for Systems-of-Systems, RISE SICS System Engineering expert, ArianeGroup Senior Product Manager for Systems Engineering, Aras

“Product Line Engineering” Track Jérôme Javelle Khalid Kouiss Nicolas Cottereau

VP Methods & Tools, Airbus R & D Engineer, Faurecia Country Manager & Sigmetrix Channel Manager, Maplesoft

Acknowledgements

We would like to thank all members of the program and organizing committees for their time, efforts, and contributions to make CSD&M 2019 a top-quality conference. Special thanks go to the CESAM Community team who permanently and efficiently managed the administration, logistics, and communication of CSD&M 2019 conference (see http://cesam.community/en). • Founding partners – CESAM Community managed by Center of Excellence on Systems Architecture, Management, Economy & Strategy (CESAMES). • Industrial and institutional partners – – – –

Airbus Group, ArianeGroup, IRT SystemX, Renault.

• Participating engineering and software tools companies – – – – – – – – – – –

APSYS Airbus, Aras, Dassault Systèmes, Digital Product Simulation, Geeglee, Intland Software, Jama Software, Maplesoft, MathWorks, MEGA International, Obeo,

xiii

xiv

Acknowledgements

– – – –

Persistent Systems, PragmaDev, Pure-systems, Siemens Digital Industries Software.

Contents

Regular Papers Gas Turbine Design at Rolls-Royce – Exploring the Limitations of a Systems Engineering Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jonathan Holt, David Elam, and James Tooke

3

Managing the Complexity of Processing Financial Data at Scale - An Experience Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sebastian Frischbier, Mario Paic, Alexander Echler, and Christian Roth

14

Verification of BPMN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mihal Brumbulli, Emmanuel Gaudin, and Frédéric Berre Synchronization of System Architecture, Multi-physics and Safety Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Michel Batteux, Jean-Yves Choley, Faïda Mhenni, Luca Palladino, Tatiana Prosvirnova, Antoine Rauzy, and Maurice Theobald

27

37

Managing Margins Under Uncertainties Surrogate Modelling and Uncertainty Quantification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kyle Hall, Peter Schroll, and Sanjiv Sharma

49

Implementing Organizational Cybernetics for the Next Generation of Digital Business Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alan Martin Redmond and Loic Chanvillard

64

Identifying Focal Points in IT Project Governance Using a Synthetic and Systems Thinking Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rani Yesudas, Mahmoud Efatmaneshnik, and Keith Joiner

79

MAESTRIA: A New Tool to Support Collaborative Building and Sharing of an Integration, Verification, Validation, and Qualification Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick Esteve, Benoit Langlois, Lyes Chabani, Willy Platzer, and Jacky Mouchoux

93

xv

xvi

Contents

School Shootings in the U.S. – Where to Begin . . . . . . . . . . . . . . . . . . . 103 Bruce A. Normann and Mo Mansouri Smart Component Modeling for Complex System Development . . . . . . 117 Philipp Helle, Sergio Feo-Arenis, Andreas Mitschke, and Gerrit Schramm Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Steffen O. P. Blume, Michel-Alexandre Cardin, and Giovanni Sansavini A Multiobjective Systems Architecture Model for Sensor Selection in Autonomous Vehicle Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Anne Collin, Afreen Siddiqi, Yuto Imanishi, Yukti Matta, Taisetsu Tanimichi, and Olivier de Weck Simulation Architecture Definition for Complex Systems Design: A Tooled Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Jean-Patrick Brunet, Henri Sohier, Mouadh Yagoubi, Mathieu Bisquay, Pascal Lamothe, and Pascal Menegazzi Towards a Cross-Domain Modeling Approach in System-of-Systems Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Boris Brankovic, Christoph Binder, Dieter Draxler, Christian Neureiter, and Goran Lastro Safety Demonstration of Autonomous Vehicles: A Review and Future Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Tchoya Florence Koné, Eric Bonjour, Eric Levrat, Frédérique Mayer, and Stéphane Géronimi Posters Model-Based Specification for System Development with Suppliers . . . . 191 Phanikrishna Thota, Simon Hancock, Mario Noriega-Fogliani, and Rodrigo Jimenez Applications of Systems Thinking for Scooter Sharing Transportation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Christina Caches and Mo Mansouri Collaborative Decision-Making Challenges in the Dutch Railway System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 N. Jakubeit, M. Rajabalinejad, A. J. J. Braaksma, and L. A. M. van Dongen Understanding Stakeholder Interactions Impacting Human Spaceflight Funding Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Brian M. Gardner and Mo Mansouri Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Regular Papers

Gas Turbine Design at Rolls-Royce – Exploring the Limitations of a Systems Engineering Approach Jonathan Holt1(B) , David Elam2 , and James Tooke2 1 Complex Systems, System Design, Rolls-Royce plc, PO Box 31, Moor Lane,

Derby DE24 8BJ, UK [email protected] 2 System Design, Rolls-Royce plc, PO Box 31, Moor Lane, Derby DE24 8BJ, UK {David.Elam,James.Tooke}@rolls-royce.com

Abstract. The development of a civil aerospace gas turbine engine within the required timescale and resource constraints presents a considerable challenge. How does a team of hundreds of engineers organize itself, not just to design the thousands of high technology components required, but to manage their interactions in order to ensure that the engine operates according to customer expectations and continues to function safely even in the event of a malfunction? In organizing the work, some elements map onto established systems principles, fitting well the model of a functional system. Other elements map less well and present a challenge to current thinking, which this paper explores. UK Origin Material: Export Control Classification: Not Export Controlled

1 Introduction In recent years, Rolls-Royce’s civil aerospace business has met with unprecedented success, taking it from a relatively small provider of engines to specific customers to a market leading position in powerplant for wide-bodied airliners. At the same time this progress has been achieved, the market continues to transform. Product service lifecycles are becoming shorter, necessitating increased product development activity and in order to achieve a lower carbon future, aerospace propulsion systems will require more radical architecture change than in the past [1]. This all adds up to a considerable increase in the volume and rate of product development activity. It is necessary to manage ever-increasing levels of technical challenge, ever increasing levels of interaction and emergent behaviour and to do so faster and at lower cost than ever before. A modern civil airliner gas turbine engine is a unique product. Success relies upon high temperature, high pressure, high velocity and tight tolerances. A turbine can rotate at 15,000 rpm, glowing white hot in a gas stream capable of melting it and passing 0.25 mm

© Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 3–13, 2020. https://doi.org/10.1007/978-3-030-34843-4_1

4

J. Holt et al.

from an equally hot casing whilst under a load of many tonnes. Success also relies on the intended interaction of many functions and the management of many other unintended interactions. This combination of difficult engineering and ‘interaction density’ represents a huge challenge. If design and development work is to proceed efficiently each member of the team must have clear accountabilities. The engineering must cover, not only all of the subsystems and components, but also all the intended and unintended emergent behaviours brought about by their interactions. Sufficient effort must be expended on integration of the product; engineers must be allocated to the work in an efficient way. Hence the overall work must be divided up into manageable tasks, each allocated to an integrated product team (IPT) led by a system integrator. Introduction of Systems Engineering principles has brought us to the point of placing considerable emphasis on interaction and emergence as the design proceeds. Nonetheless standard System Engineering principles seem to be challenged by the need to divide up the work. Some design tasks appear to behave as functional systems in which inputs are processed by resources within a defined boundary, but for others this is not the case, or at least not fully the case. This paper outlines how the task of designing a gas turbine is divided up and shares what we have discovered about how Systems Engineering practices need to be adapted in order to achieve success. Whilst aircraft propulsion is perhaps an extreme case, we believe that the principles and experiences described here may have relevance in the design of many products. The paper is organized as follows. Section 2 outlines a gas turbine and its product breakdown. Section 3 addresses the organization breakdown structure which Rolls-Royce uses to manage the design activity. Section 4 describes two examples of design tasks, one fitting standard Systems Engineering principles, the other less so. Section 5 proposes how Systems Engineering practice may be adapted to suit, and the paper ends with some conclusions and open questions for further discussion.

2 The Gas Turbine and Its Product Breakdown 2.1 Subsystems Figure 1 shows diagrammatically and in simplified form the main elements of a two shaft gas turbine. As can be seen from the key each group of elements is managed together as a subsystem; each subsystem has its own organization responsible for research, design, manufacture or procurement and support in-service.

Gas Turbine Design at Rolls-Royce

5

Fig. 1. Simplified layout of an aerospace gas turbine engine

2.2 Emergence and Integration However, the engine must be viewed as far more than a collection of components. The emergent properties and behaviours are extremely important. The following are examples: Thrust. The purpose of the engine is to propel an aircraft and thrust is itself an emergent property; it is developed as a consequence of the fan and the turbines, whose behaviours in turn depend upon all the other elements shown. Performance. The efficiency with which fuel input to the engine is converted to thrust output depends upon the efficiency of the various subsystems, and also upon how they are matched together to operate as a whole. Since fuel efficiency is key to market performance, engine performance is a key area of system analysis and design. Secondary Air System. ‘Secondary’ air is drawn from the compressors and moves through the central part of the engine within the gas path, looking after the cooling, sealing and bearing load management. Fuel, Oil and Heat Management. As fuel and lubricating oil move through the system, they pick up heat. Some of this is intentional. For example the fuel takes heat from the oil, returning it to the combustor, for a small efficiency return. However, the temperature of both the oil and fuel and the surfaces they contact must be carefully managed to ensure chemical stability and therefore the long term reliability of the relevant systems. Structural. The integrity, safety and reliability of the engine depends upon management of the steady state and vibration loads on the various structural elements both during normal operation and in the event of failures such as that of a rotating element leading to a large out of balance load. Emergent properties such as these and many others are managed through the design process by Product Systems and Design Topics. Figure 2 illustrates the examples above. These are characterized by the need to work a ‘whole engine’ level, coordinating the contributions of the various subsystems and trading them to optimize the overall system design.

6

J. Holt et al.

Fig. 2. Aerospace gas turbine emergent properties

3 Organizing to Do the Work Efficiently 3.1 Organizational Breakdown Structure Figure 3 shows the main features of the organizational approach adopted at Rolls-Royce for Aerospace design within engine projects.

Fig. 3. Rolls-Royce Aerospace design organizational breakdown structure

Gas Turbine Design at Rolls-Royce

7

The large System Design organization is accountable for the Whole Engine, Product System and Design Topic activities. Each subsystem has its own design organization which looks after the subsystem level together with the component commodities which go to make up the subsystem, whether components are manufactured in-house or procured from a supplier. 3.2 Designing Product Systems and Design Topics The design integration tasks associated with emergence were formerly executed with varying degrees of success using a diversity of technically based approaches. The adoption of Systems Engineering principles has brought order to this, together with a higher level of confidence that important considerations have not been missed. The term Product System was adopted for such integration tasks. (Systems Engineering principles have been used for many years in Control Systems, are now in use in at least some other subsystems and are now also increasingly influencing Whole Engine design.) The standard approach to Product Systems requires the IPT to develop for each Product System (amongst other work products): • An Operational Requirement: a succinct statement of the purpose of the system. • A System Boundary: clearly distinguishing between elements of the engine in the system whose resources are used to deliver the Operational Requirement from those elements of the engine outside the system. • Context and Functional Flow Diagrams [2, 3]: identifying the functional flows crossing the Product System boundary – both inputs and outputs - then mapping out the functions to be performed by the system to convert the inputs to outputs. • A full requirements capture for the Product System, with requirements flowed down from the overall product architecture and across from other Product systems and Subsystems. • A functional failure mode and effect analysis [4] considering how the functions could fail to be executed correctly as a means of improving the design. • A Product System Architecture: mapping the functions onto the proposed physical resources included in the system. • A Verification and Validation Strategy: outlining how each Product System requirement will be verified and the system shown to be fit for purpose. For some design tasks, this approach of treatment as a system works very well. But for others, treating the activity required as the design of a system creates tension. In many cases, what is required is to ‘ensure the whole engine design is correct from the perspective of x’, where x could be performance, vibration, noise, environmental protection (i.e. engine protection from rain, hail, ice, volcanic ash or ingested foreign objects) and so on. The issue here that these aspects of engine behaviour are not systems and cannot fully be treated as such. Hence although a standardized approach is needed to manage these kinds of emergence, a standard systems approach does not work unmodified. As a result, at Rolls-Royce, some Product Systems have been re-designated as Design Topics. The approach adopted and list of work products required has been modified to suit.

8

J. Holt et al.

4 Product System and Design Topic Examples Before discussing the modifications needed to the Systems Engineering process to serve Design Topics in more detail, an example Product System and Design Topic are presented in this section, to provide an appreciation of how the difference works out in practice. 4.1 The Turbine Tip Clearance Control (TTCC) Product System Turbine systems work best when their blade tips are passing as close as possible to the surrounding casing. Tip gaps lead to loss of efficiency as air ‘leaks past’ the blades without imparting work to the rotor. Leaking hot air is also a source of erosion to the blade tips, substantially increasing the engine maintenance costs. Close clearances are particularly desirable during the cruise flight phase of a long-haul application, because that is where the majority of fuel is burned. The turbine rotors and stators operate at a range of temperatures depending upon the engine operating conditions, and the thermal time constants of the various elements also differ. This means that to achieve close tip clearance an active compensation system is needed. The approach chosen is to cool the casing as required to achieve optimal clearance using a stream of cool air obtained from the engine fan duct. The system is shown diagrammatically in Fig. 4.

Fig. 4. Turbine Tip Clearance Control (TTCC) system

Air is drawn into the system via an inlet behind the fan. It is modulated by a butterfly valve and passes along a duct an annular manifold arranged around the turbine casing. Air from the manifold impinges upon the casing via impingement holes in the manifold inner casing, and is then exhausted into the core zone around the engine casings to eventually exit at the rear of the engine. The valve is actuated hydraulically using fuel from the fuel system under the control of a servo valve. The Engine Electronic Controller executes a software algorithm to modulate the air flow as required to achieve the correct turbine tip clearance based upon current engine and environmental conditions.

Gas Turbine Design at Rolls-Royce

9

The Operational Requirement for TTCC states: the system shall control turbine tip clearances throughout the flight, across the operating envelope and throughout a service interval prior to overhaul. Figure 4 shows the boundary diagram used to analyse and design the system. The context and top level functional flow diagrams are shown in Fig. 5. Note how the context diagram shows the whole system functionality as one item. By contrast the functional flow diagram decomposes the system functionality into its constituent high level linked functions, with the entities external to the system remaining entirely consistent. The analysis would then go on to decompose each function in the latter diagram further using the same approach.

Deterioration effect upon target closure

Op an erati d c ng on sta dit ion te s

4. Detect & Annunicate Failures

Failure conditions

Heat

Flight & operating conditions & history

3. Manage Deterioration

rts

1. Determine required Clearances

et Targ e closur Failure conditions

po

Su

Actuation Motive Power Source

2. Cool Casings

TCC actuation flow

g

L ort n pp tio ec nv ad Co rt Lo / t en ppo d m a u e R g S pin g, Im oolin C at,

He

ation Actu flow Actu ation Pre ation ss temp ure, Actu ation erature, flow

TCC actuation pressure & flow

nt/ me ling ge oo pin n c Im ctio iant d e nv Ra eat o c h

in at er op ns nd itio t a nd gh co

d oa

Actuation Motive Power Source

Heat

Turbine Casing

Control System

re

Load

Control System

air

Fli

ort Supp

Front core zone

ng

re

Su

t ian

Turbine Casing

Actu

Lo pport

oli

ilu

Scheduling

ad

Support Arrangement

Status Information

Co

Fa

TTCC System

Rear core zone

Fan Duct

Exhaust Air

Convection Heating, Support Load Convection Cooling, Support Load

Rear Core Zone

Re co duce olin g

Front core zone

g, coolin ction d Convepport Loa g, Su tin a e h ction d Conve pport Loa Su

Coolin g Air Back Press ure

Fan duct

Fig. 5. Turbine tip clearance control system context and functional flow diagrams

This approach works because the resources used to achieve the Operational Requirement are limited to the TTCC Turbines, Externals and Controls subsystems. Notice for example that although for simplicity the EEC is shown in Fig. 4 as contained entirely within the TTCC system, in reality it is only the software functions executing the TTCC logic which are really within the system; the other software functions and communicating parameters are outside. Turbine Tip Clearance Control can be regarded as a system because the Operational Requirement can be articulated in the form: The System shall . 4.2 The Shaft Order Vibration Design Topic All elements of a gas turbine engine vibrate in a variety of ways. Shaft Order Vibration refers to vibrations due to and related to the rotation of the engine main shafts, of which a typical large aerospace engine has two or three. These need to be managed during the design process to ensure all affected elements exist and operate within stress levels consistent with their required lives. The Shaft Order Vibration Operational Requirement is stated as: All elements of the engine shall operate correctly for their declared lives when subject to operational vibration levels. The Topic Boundary is depicted in Fig. 6. Notice here that the boundary diagram includes, with a few exclusions, the whole engine.

10

J. Holt et al.

Fig. 6. Shaft order vibration boundary diagram

5 Design Topic Systems Engineering 5.1 Why Do Design Topics Exist? The distinction between Product Systems and Design Topics arises because of the need to divide up the work required to design a gas turbine engine in order to execute it. A gas turbine as a whole is a functional system. It takes in fuel and air and outputs thrust. It could therefore be viewed as a ‘giant product system’. In breaking the work down, some individual Product Systems are identified, but much of the rest of the work takes the form of Design Topics managing non-functional concerns which arise elsewhere in the system, as depicted in Fig. 7. Product Systems may be viewed as systems within the product whereas Design topics are viewpoints on the design of the product as a whole.

Fig. 7. Relationship of product systems and design topics to the product

For example, the vibration design topic views the design of the engine from a vibration perspective. It is also noticeable that where Product System IPTs tend to be led by integration generalists, Design Topics are usually led by technical specialists, for example in engine performance, stress or vibration.

Gas Turbine Design at Rolls-Royce

11

5.2 Developing a Design Topic As for a Product System, a standard approach has been developed for Design Topics. Compared to a Product System there are both similarities and differences. The following is a summary of Design Topic work products, equivalent to that for Product Systems in Sect 3.2. • An Operational Requirement. Here the subject is more likely to be the product as a whole and focus will be on how it shall be (as opposed to what a group of elements within the product shall do). • A Topic Boundary: as with the Product system, this should clearly distinguish elements in the topic scope and whose behaviour needs to be constrained in order to deliver the Operational Requirement from those which are not. Topic Boundaries tend to be broader than Product System Boundaries, and may encompass the whole engine (as in the example in Sect 4.2). • Context and Functional Flow Diagrams: because a Design Topic is non-functional, no purpose or benefit has been demonstrated for these; they are not produced. • A full requirements capture for the Design Topic, with requirements and solution space constraints flowed down from the overall product architecture and potentially also across from other Product systems and Subsystems. • Failure modes assessment: because of the lack of functionality, a standardized approach equivalent to FFMEA has not yet been identified. It may however still be possible and is certainly desirable to conduct some kind of failure assessment. • A Design Topic Architecture: defining the strategy from the perspective of the Design Topic probably including design rules, leading to levying of derived requirements upon other Product Systems and Subsystems. • A Verification and Validation Strategy: essentially similar to that for a Product System, outlining how each Design Topic requirement will be verified and the engine shown to be fit for purpose from the perspective of the Design Topic.

5.3 Physical Constraints and Non-functional Interactions The distinction between Product Systems and Design Topics has become an important feature of thinking around design integration or gas turbine engines at Rolls-Royce. Yet the authors know of no references to this dilemma in the external Systems Engineering literature, and have been pondering this lack. Our view is that the need for Design Topics arises from the level of physical constraint and non-functional interaction inherent in the product. Classical Systems Engineering has been heavily influenced by products relying upon software for much of their functionality. If the product under consideration were a software system, the need to consider physical constraints and non-functional interactions would be minimal or absent. For example it might be limited to the risk of the processor overheating. In a gas turbine engine, as we have seen, the product is to a very great extent dominated by these constraints and interactions. It is impossible to do something with one element of a gas turbine without side effects being felt and needing to be managed in several other areas of the system. Modern gas turbine control

12

J. Holt et al.

systems are heavily software-based and gas turbine Product Systems (as opposed to Design Topics) generally involve a substantial control system element.

6 Conclusions and Discussion Points 6.1 Conclusions (1) Rolls-Royce’s design integration approach for gas turbine engines has been outlined. Examples of the design approach have been presented, with work products summarized in each case. (2) Because of the level of physical constraint and non-functional interaction inherent in a gas turbine, the design work breakdown needs to consist of both Product Systems, which are well modelled as functional systems and for which classical Systems Engineering tools work well, and Design Topics, which fit the functional system model less well, and for which classical tools only partly work.

6.2 Discussion Points There is more thinking to do in this area and, we believe, more useful discoveries to be made. The following brief discussion points are raised in the hope of continuing the conversation. (1) There is more to discover about how to handle non-function interaction and constraint at operation time. Current Systems Engineering approaches seem to lack the ability to do this. (2) In particular, there is a need to establish safety criticality of non-functional behaviours, in order to rigorously pursue practices such as those given in ARP4754A [5]. FFMEA [4] is an approach used within Rolls-Royce to achieve this for a functional system. The language and thought patterns have yet to be discovered to achieve the equivalent for Design Topic. (3) Product Systems and Design Topics are represented in this paper as mutually exclusive, but this is clearly a simplification of reality. Further thought is required on how to handle ‘mixed’ tasks. (4) Our studies of the gas turbine engine design process suggest it is time for systems engineering as a discipline to expand and fully break free from its software-based roots. Acknowledgements. All endeavours at Rolls-Royce including this paper are a result of teamwork. The contributions of many colleagues with whom the authors have discussed the concepts described here are hereby gratefully acknowledged. As is apparent from multiple references, the Systems Engineering approach at Rolls-Royce draws heavily upon training material developed by Stuart Burge of Burge Hughes Walsh.

Gas Turbine Design at Rolls-Royce

13

References 1. Whurr, J., Beecroft, P.: Rolls-Royce’s long term civil aircraft propulsion system concept and technology strategy. In: International Society of Air-breathing Engines Conference 2017, Manchester, UK, 3 to 8 September 2018 2. Burge, S.: The Systems Engineering Tool Box. Context Diagram (CD). https://www. burgehugheswalsh.co.uk/Uploaded/1/Documents/Context-Diagram-Tool-Draft-2.pdf 3. Burge, S.: The Systems Engineering Tool Box. Functional Modelling (FM). https://www. burgehugheswalsh.co.uk/Uploaded/1/Documents/Functional-Modelling-Tool-Draft-2.pdf 4. Burge, S.: The Systems Engineering Tool Box. Functional Failures Modes and Effects Analysis (FFMEA). https://www.burgehugheswalsh.co.uk/Uploaded/1/Documents/FFMEA-Toolv2.pdf 5. SAE. ARP 4754A. Aerospace Recommended Practice 4754 Rev A, December 2010

Managing the Complexity of Processing Financial Data at Scale An Experience Report Sebastian Frischbier(B) , Mario Paic, Alexander Echler, and Christian Roth vwd: Vereinigte Wirtschaftsdienste GmbH, Frankfurt, Germany [email protected]

Abstract. Financial markets are extremely data-driven and regulated. Participants rely on notifications about significant events and background information that meet their requirements regarding timeliness, accuracy, and completeness. As one of Europe’s leading providers of financial data and regulatory solutions vwd processes a daily average of 18 billion notifications from 500+ data sources for 30 million symbols. Our large-scale geo-distributed systems handle daily peak rates of 1+ million notifications/sec. In this paper we give practical insights about the different types of complexity we face regarding the data we process, the systems we operate, and the regulatory constraints we must comply with. We describe the volume, variety, velocity, and veracity of the data we process, the infrastructure we operate, and the architecture we apply. We illustrate the load patterns created by trading and how the markets’ attention to the Brexit vote and similar events stressed our systems. Keywords: Financial data · Big data · Event-driven architecture Enterprise architecture · Quality of information · Infrastructure

1

·

Introduction

There are many ways to decide on financial market investments: Intuition, psychology, tapping into social media, following recommendations of analysts and influencers, or quantitative analysis of trends and correlations. While the former approaches usually sound more intriguing as they come with a certain enigma, quantitative analysis of financial data is the prevailing tool used by market participants. Thus, having access to reliable, accurate, fresh, and complete information about financial markets is vital to participants. The general public is usually more familiar with the delayed market data provided via public websites, teletext, on television or as end-of-day aggregations on the daily newspapers’ financial pages. For professional users, however, far more diverse data-driven solutions are available to support them in their decisions. These solutions give targeted insights with high information density. Examples are portfolio management systems that constantly check portfolios with individual investment strategies against real-time data to give recommendations for c Springer Nature Switzerland AG 2020  G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 14–26, 2020. https://doi.org/10.1007/978-3-030-34843-4_2

The Complexity of Processing Financial Data at Scale

15

redeploying capital (and manage the subsequent orders directly upon approval) or market data terminals that enable experts to combine real-time market data insights with historic and reference data for in-depth analysis. The raw data fuelling these solutions is provided as continuous streams of structured and unstructured data by various sources, e.g., exchanges, financial institutions, capital management and investment companies, rating agencies. Financial data vendors and solution providers collect this data, purge, and enrich it before providing the resulting condensed information at different levels of quality of information (QoI) to subscribers. vwd is one of Europe’s leading providers of data-driven financial solutions. Founded in 1949 as a news agency our products and their supply chain are nowadays completely digital. We provide solutions ranging from market data-heavy products to advisory and regulatory solutions offered as cloud-based Softwareas-a-Service (SaaS) that help our customers to focus on their core business while being compliant with regulations. Our customers are private and public financial institutions, investment and portfolio manager, the news media in print and television as well as the general public. As a group we serve customers out of 14 locations in six countries. While some of our subsidiaries provide solutions directly to end users, most of our customers are intermediaries on the financial markets. Directly and indirectly 30 million users rely on our information on a daily basis to form an opinion on financial markets. The challenges we face when processing financial data at scale are thus representative and generalizable. In this paper we give practical insights about the complexity of processing financial data at scale when catering to an industry that is highly regulated and competitive. We illustrate ten challenges generalised from the volume, variety, velocity, and veracity of the data we process, the historically grown heterogeneous IT application landscape we operate, and the major regulatory constraints we have to comply with as a financial solution provider. In particular we show how regular patterns and the attention of markets to singular pivotal events reflect in demand and supply for financial data streams using our observations of the Brexit vote and the final ballot Trump vs. Clinton (2016) as examples. In Sect. 2 we identify the challenges C1–C10 by describing the diversity of financial data in general (Sect. 2.1) and the streams processed by vwd in particular (Sect. 2.2), the major challenges on an IT compliance level (Sect. 2.3), and the systems we operate (Sect. 2.4). In Sect. 3 we outline how vwd addresses the resulting complexity: we describe the infrastructure we operate, the architectural patterns we apply (Sect. 3.1), and the organizational measures we took for software development, innovation management, and compliance (Sect. 3.2). We summarize our contributions and point out ongoing research in Sect. 4.

2

The Complexity of Processing Financial Data at Scale

As an international solution provider to the financial industry we do have to face several challenges – primarily stemming from the financial data feeds we process, the regulatory constraints we have to comply with, and the historically grown

16

S. Frischbier et al.

heterogeneous IT systems we operate. Thus, we first give a brief introduction about those aspects of financial data that are relevant for the scope of this paper. 2.1

Background: Financial Data Feeds

The umbrella term financial data denotes a wide spectrum of unstructured and structured data with quite differing information density about financial instruments and their issuers. Examples for financial instruments (short: instruments) are securities/stocks, funds, futures, currencies, or indices. Please note that most but not all instruments are traded via exchanges or other platforms – take over the counter (OTC) securities as an example. Unstructured and semi-structured financial data ranges from general news and corporate information to notifications about specific performance-related decisions by publicly traded companies (e.g., mergers, acquisitions) that must be instantly published as ad-hoc messages. Structured financial data is provided as market data at various levels of granularity and quantifies the value and prospect of a certain instrument. In its purest and finest-granular form market (tick ) data carries information about the current trading value of a certain instrument instance (also called symbol ) at a given point in time at a specific exchange or trading platform. The most common properties used to denote this value are bid, ask, bid size, ask size, timestamp. Market data can also contain aggregations (e.g., weighted averages) or Key Performance Indicators (KPIs) with high information density that quantify the risk/performance of an instrument in a given context (e.g., spread, betas) based on complex reasoning using historic and reference data (metadata). The most important drivers of complexity when processing financial data are the value of its information, how it is provisioned, and how it is represented. Quality and Value of Information. The QoI of market data can be quantified using objective metrics such as granularity, correctness, completeness1 , timeliness, order, and availability. For data providers, QoI properties are cost drivers with costs proportionally linked to the level of required QoI. On the consumer side, the value of information (VoI) for market data with certain QoI properties depends on the purpose this information is intended to be used for by each consumer [7]. Thus, VoI is highly subjective and creates complexity on the provider’s side as soon as a data provider has to serve a large number of diverse consumers. Provisioning. Market data is provided in a subscription-based manner as streams or bulk loads. Typical data sources are the various exchanges but also financial institutions like national banks. Data is provided as feeds where a feed is a continuous stream of event types by a certain data source and/or market segment. A feed can be provided by a single exchange/issuer or by an intermediary financial data vendor that bundles feeds from several providers. Feeds are denoted as full if data is provided without any artificial degradation in timelines or granularity. Contrastingly, a feed is delayed if the delivery of notifications is delayed 1

Completeness here refers to the number of properties available per notification but also to the completeness of notification sequences in a stream.

The Complexity of Processing Financial Data at Scale

17

by a factor; only certain notifications are forwarded based on prioritisation in throttled feeds. Consequently, aggregated feeds deliver data at lower granularity with intra-day or end-of-day aggregations being the most prominent examples. Subscriptions are made based on data source (e.g., feed, exchange) and quality dimensions such as granularity (e.g., tick, average), timeliness (e.g., real-time, delayed, intra-day, end-of-day), and completeness (e.g., full, throttled). Larger feeds are often split into channels that deliver different market segments; order is always assumed. The predominant way of delivering financial data feeds is still via direct dedicated lines using multicast and we notice that data sources even increase the use of multicast nowadays. Some feeds are also available via public internet. In most cases they have to be split up along exchanges, market segments or instrument groups into different single feeds to compensate for the lower bandwidth and higher latency of public internet connections. Representation. Exchanges, markets, trading platforms, and trade-reporting entities are identified using a global Market Identifier Code (MIC) standardised in ISO10383. Financial instruments are associated with an alpha-numeric identifier. For stocks/securities this can be an exchange -dependent abbreviation called the (ticker) symbol or an international identifier such as the International Securities Identification Number (ISIN) that is standardised in ISO6166. However, different data sources may use variations of these identifiers or identifiers change over time due to mergers so that the same instrument instance is represented by different symbols based on their context. For example, the stock of Apple orse Frankfurt3 while Inc. is known as AAPL on NASDAQ2 but as APC on B¨ being associated with the ISIN US0378331005 as a unique identifier; moreover market data about this stock is available as AAPL.OQ (Reuters)4 or AAPL:US (Bloomberg)5 . Hence, data must be mapped and normalized at runtime. 2.2

Challenges Processing Financial Data at vwd

For the sake of simplicity we organize the description of concrete challenges (C1–C4) we generalize from the financial data we process at vwd along the four dimensions of Big Data [9]: volume, variety, velocity, and veracity. (C1) Volume: The Overall Volume Increases but Varies Throughout the Day. Over the years the total volume of raw feed data processed in our ticker plant has significantly increased. In particular between 2003 and 2008 we observed an exponential increase that has turned from progressive to degressive since: the average number of daily notifications (excluding unstructured data such as news and ad-hoc messages) rose from 167 million (2003) to 937 million (2006) to 8,303 million (8.3 billion) in 2008. One explanation is the decline of floor trading at 2 3 4 5

https://www.nasdaq.com/symbol/aapl. http://en.boerse-frankfurt.de/stock/Apple-share. https://www.reuters.com/finance/stocks/overview/AAPL.OQ. https://www.bloomberg.com/quote/AAPL:US.

18

S. Frischbier et al.

NASDAQ London Frankfurt Tokyo Sydney

0

1000

2000

3000

4000

the exchanges since 2004 in favour of electronic trading. Nowadays we process on average around 18 billion notifications per day and 700,000 per second (peak rate of more than 1 million events/sec). All notifications and reference data are stored as historical prices so we can provide data for the past decades. Traffic varies massively on a global and local level throughout the day. On a global level, volume differs by time zones while it also varies throughout the local trading day and per exchange. In Fig. 1 we show the rate of notifications received over two days for selected feeds from the exchanges London (UK, blue), Sydney (AU, orange), Tokyo (JPN, purple), NASDAQ (US, green), and B¨ orse Frankfurt (GER, black). Data points are averaged over 10 min windows to smooth the plot and highlight the recurring pattern: data generated by trading on a certain exchange resembles as satchel with most activity before and after an exchange’s opening time; there is less activity around local lunch time. Please notice the explicit 1 h lunch break in Tokyo (purple). We chose these exchanges as they are fairly representative for their geographic area and of comparable order of magnitude in the chosen feeds. Please note that these numbers represent only limited market segments of the actual exchange and the measured feeds might provide different products and instrument types.

00:00

09:00

15:30

22:00

09:00

15:30

22:00

Time of day Frankfurt, Germany (GMT+1)

Fig. 1. Selected load received from different exchanges. Processing capacity must take the combined peak rates into account that vary massively over 24 h.

Apart from the expected peaks, announced and unannounced singular events are a separate challenge. Around the Brexit vote (June 23rd 2016) the total volume of financial data consumed and published by us increased by 50%. While

The Complexity of Processing Financial Data at Scale

19

our systems did scale to cope with this overhead, some systems of our subscribers did not. For the final ballot of the US presidential elections 2016 Trump vs. Clinton (November 8th 2016) we dealt with an even higher volume for days. (C2) Variety: Sources, Formats, Protocols, Types, Properties, Notification Sizes. We receive notifications bundled in various feeds about 120 stock exchanges, 35 futures and commodities exchanges, 180 OTC contributors and more than 500 capital management and investment companies. The data is received and provided in custom binary or XML formats, via REST (JSON), or via bulk uploads in various file formats. The core processing systems at vwd process market data regarding 30 million symbols and 3 million ISINs together with reference data and unstructured data with news and ad-hoc messages. During a typical day 98% of all received notifications are ticks, followed by reference data (0.16%) and news (0.001%). The size of these notifications (w/o news) varies between 20 bytes and 250 bytes with the average around 100 bytes. The average notification size also varies per time of day: they are larger in the morning as the open notifications arrive, often resetting the daily statistics fields like day high/low, or total volume/turnover. In the evening there are fewer quotes and larger types of notifications are more common, e.g., statistics or static data. (C3) Velocity: Timeliness Matters for Data Feeds and Bulk-Data. Velocity for financial data is primarily about low-latency processing of feeds and timeboxed batch-processing of bulk-data. The internal benchmark we define for low-latency processing of incoming feeds is an end-to-end latency within our ticker plant of 40 ms per notification. In addition to processing feeds and deriving complex indicators we do enrich bulk-data provided by customers such as internal ratings, portfolios or scenario data that is fed back into their systems after we have run complex simulations. As these computations have to be finished within a given time frame they result in batch-processes with very elastic resource requirements. (C4) Veracity: QoI and Uncertainty of the Rendered Information. For financial data veracity thus addresses QoI and its value (VoI) to subscribers that directly translates to costs. For our customers VoI is a function of objective data quality properties of the data they have subscribed to and their own subjective preferences that are based on the purpose subscribers intend to use their subscribed data for. For example, customers using terminal solutions usually value timeliness over completeness, i.e., they prefer single notifications to be dropped completely if the information displayed on the terminal then reflects most recent events. Conversely, customers who feed the same type of notifications into their analytical systems for in-depth analysis value completeness over timeliness, i.e., they prefer a delayed complete event stream over a timely but incomplete one. Summarizing Challenges C1–C4. The characteristics of financial data pose a challenge to our processing systems: we must enrich & push a large variety of data (C2) efficiently to our customers with as little delay and interruption as

20

S. Frischbier et al.

possible (C3) as its value is based on individual expectations about timeliness and completeness (C4). The large daily volume of data with its massive variations (C1) is an amplifying factor as our systems have to elastically scale to deal with peak rates that amount to several orders of magnitude of the average load. 2.3

Challenges Regarding Compliance

Financial markets are a highly regulated domain. Subsequently we do have to deal with a wide range of constraints based on European and national legislation, domain-specific regulations, and commercial license agreements for the data we process. For illustration we use examples that have a significant impact on our software development life-cycle, our application landscape, and its operations. (C5) Legislation: Most prominently, the General Data Protection Regulation (GDPR) has emphasized the importance of data locality, minimal usage, and protection for personal data while extending the scope of latter’s definition. This impacts all companies active in Europe in regard to their business processes, procedures for handling data, and the software systems used. In addition to such general legislation we also do have to be aware of strict national laws applying only to the financial sector. Examples are the Swiss Bankengesetz (BankG) or the German Gesetz u ¨ber das Kreditwesen (KWG) for countries we are present. They all emphasize that outsourcing organizations remain fully responsible and accountable for the services they outsource to service providers like us. (C6) Regulations: Some services we provide rate as outsourcing agreements with organizations that are subject to further requirements by regulatory bodies. On EU level, the European Banking Authority (EBA) defines guidelines for financial institutions and financial products. Noteworthy for us in this context are in particular the refined guidelines for outsourcing arrangements [4]. On a national level, the German Federal Financial Supervisory Authority (BaFin), Luxemburg’s Commission de Surveillance du Secteur Financier (CSSF) or the Swiss Financial Market Supervisory Authority (FINMA) define additional requirement catalogues, such as BaFin’s Minimum Requirements for Risk Management for Banks [1] or CSSF’s guidelines regarding IT outsourcing relying on a cloud computing infrastructure [3]. All these regulations focus on the transparency, accountability, and reliability of the outsourced services and their operations. This results in additional requirements regarding reporting, change & incident management, business continuity management (BCM), and IT security: specific incident and compliance reporting requires further documentation and processes; identity and access management (IAM) based on the principles of least privilege and separation of duties (SoD) between operations and development has to be enforced on the physical as well as digital level and regularly reported about. (C7) Licenses: Data is the raw material of our industry. We need to maintain detailed individual license agreements with our various data sources and also with our customers about the content we process. These contracts govern service

The Complexity of Processing Financial Data at Scale

21

levels and penalties under which data of a certain quality is provided to us, can be redistributed by us, and consumed by our customers. This requires us to implement detailed runtime monitoring, metering, and fine-granular reporting about data provisioning and consumption down to the end user as this is essential for cost management along our digital supply chain. Summarizing Challenges C5–C7. From a compliance perspective strict requirements about transparency and availability due to regulations (C6) and license management (C7) create a tension with general legislation (C5) that enforces minimal data usage and confidentiality. This adds complexity to our software development life-cycle (SDL) and our infrastructure & operations organization as we need to adhere to non-functional requirements such as data locality. 2.4

Challenges Regarding IT Governance

In regard to IT governance the main challenges result from the heterogeneity of our system landscape, the need to combine pull- and push-based architectural patterns, and the scalability needed to deal with very elastic workloads. (C8) Heterogeneity: vwd has always grown both organically (new digital products and by attracting new customers) and inorganically (mergers and acquisitions, M&A). On the technological level, this evolution increased the heterogeneity of IT systems to govern and operate massively over time – in particular as our complete supply chain and product portfolio are digital. In general, increases in heterogeneity and complexity resulting from mergers & acquisitions are more apparent but also when growing organically new digital products tend to introduce new technology stacks while existing products rely on legacy technologies that need to be maintained. Without active governance, increasing diversity leads to technical debt along the complete technology stack and inertia. For example, at a certain point in time our Operations team had to maintain 14 different Linux distributions and versions due to acquired legacy applications that depended on specific configurations to support a myriad legacy product families with customized versions implemented in various programming languages. (C9) Pull and Push: We need to deliver data streams to our customers, alert them about specific events and derive additional insights from the processed data on-the-fly. This requires a push-based approach [8]. Other products, however, require a pull-based approach as they rely on static data being pulled from data sources on demand or as they are triggered by a customer’s actions. (C10) Scalability, Resilience, and Elasticity: The workloads we process can vary massively in volume, variety, velocity, and veracity. Thus, we have to provide the necessary capacity in our infrastructure and enable our application landscape to elastically scale with any workload. We notice that research on expressive benchmarks for our domain is sparse [2]. Regulatory constraints do also require our systems to run in multiple locations for disaster resilience which requires distributed state management and additional data synchronisation.

22

S. Frischbier et al.

Summarizing Challenges C8–C10. Historically grown systems induce general IT governance challenges (C8) that are amplified by the fact that the data we process and the regulatory constraints we have to comply with require us to fuse pull- and push-based approaches in our architecture (C9) while operating a distributed highly elastic IT system landscape (C10).

3

How vwd Processes Financial Data at Scale

At vwd we address the complexity of processing financial data at scale on the technological and organizational level. In this section we outline the architectural patterns we apply to our production systems, the physical infrastructure we operate across continental Europe, and the main organizational measures we take to allow for rapid development while complying with regulations. 3.1

Technology: Modular Platform and Hybrid Infrastructures

On the technological level we directly address challenges C1–C4 regarding data management, C5–C7 regarding compliance, and C8–C10 regarding IT governance: we operate an extensive geo-distributed infrastructure and apply a modular platform approach to our production systems that combines the two complimentary paradigms of event-based systems (EBS) and service-oriented architectures (SOA) into an event-driven architecture (EDA). Technology big Picture. The three main components of this approach are illustrated in Fig. 2: the target architecture of our customer-facing vwd Cloud (left,

Event-driven Architecture

Geo-distributed Infrastructure Public Cloud

User interfaces Microservices

Backend

Message Bus

DBs

Locations

vwd data center

vwd data center

Containers

DC1

DC2

Permissioning

Feeds

Public Cloud

…

…

vwd Ticker Plant (distrib. EBS)

Enrichment

EStore

vwd Ticker Plant FH

FH

FH

FH

Monitoring

P/S Brokers

Permissioning

vwd Cloud

Information flow

vwd Cloud (SOA)

Raw data feeds Customer data centers & systems Legend

Dark fiber connection

Pub/Sub Network Broker

FH Feed Handler

Fig. 2. Big picture vwd event-driven architecture (left) with containerized serviceoriented vwd Cloud (top) and vertically integrated distributed Ticker Plant (bottom); excerpt of geo-distributed physical infrastructure (right).

The Complexity of Processing Financial Data at Scale

23

top) focuses on decoupling systems and infrastructure by using open and commercial platforms, containerization, and microservices based on Docker Swarm and Kubernetes. Close to the data sources distributed event-based systems of our Ticker Plant developed inhouse for feed processing (left, bottom) are vertically integrated with our physical infrastructure (right): as we control the complete technology stack we can customize network protocols and align software with hardware for maximum processing performance. A Reactive Architecture. On the architecture level we combine push-based EBS and pull-based SOA for three reasons: First, to directly address challenges C1–C4 stemming from the push-based characteristics of financial data streams and those regarding licensing (C7). Second, to address the IT governance challenges C8 & C9 by using a modular service-oriented architecture that reduce heterogeneity and allow for integrating legacy pull-based applications. Third, leverage the scalable and distributed nature of the resulting EDA to address C10 and implement disaster resilience strategies based on regulations (C6) that require a geo-distributed setup without deteriorating the quality of our services. SOA: vwd Cloud (C8, C9, C10). Our customer-facing production systems (c.f., Fig. 2, top left) are implemented by choreographing containerized microservices. This approach massively reduces the heterogeneity of our system landscape from a development perspective by encapsulating business functionality into services exposed only via a homogeneous interface and accessible via an encrypted protocol. Legacy applications are integrated by exposing their functionality via a REST service as facade (e.g., Oracle’s REST Data Service); the legacy system behind this facade can be optimized or replaced to reduce operational heterogeneity without impacting depending services [5]. With this platform approach we transparently combine pull- and push-based systems, easily reuse and recombine existing functionality for products to exploit synergies, and reduce complexity on the infrastructure level by consolidating and standardizing systems. EBS: vwd Ticker Plant (C1–C4, C6, C10). As shown in the red explosion view (Fig. 2, middle) information flows from our ticker plant (bottom) to data-driven services hosted on our vwd Cloud (top); each logical component is implemented using multi-tier architectures and is distributed across locations (bottom, left). Feed handler (FH) instances in the ticker plant are subscribed to the data sources to receive, check, purge, and normalize the incoming feeds. Each FH is tailored to match the specific protocol, syntax, and semantics of its feed(s) and scales horizontally. Frequent enrichment and normalization done is adding standard properties if they are not available in the original notification, e.g., total volume, open/close, or day high/low. The normalized data is fed into our event store (EStore) layer together with other reference data provided by customers or contributors. The EStore layer combines in-memory and relational databases. Complex events are detected in the Enrichment component and KPIs are derived by fusing real-time data with historic & contextual data from databases.

24

S. Frischbier et al.

Distributed PubSub Broker Network (C1, C3, C4, C6, C10). We push normalized data via a distributed content-based publish/subscribe broker network (blue overlay network in Fig. 2) that is deployed across locations and inter-companyborders [6]. With this decentralised network we address disaster resilience and minimize traffic (through application-level multicast and filtering by finegranular subscriptions). Throttling or delaying streams intentionally degrades QoI for those subscribers only entitled to less-granular/-timely data. Permissioning (C7). Managing the entitlement of customers to receive data from certain feeds, metering the consumption, and subsequent reporting back to data sources and authorities is handled by our central Permissioning system. A Hybrid Multi-site Infrastructure. Our systems run on a hybrid infrastructure with gigabit connectivity owned and operated by us for most parts [6]. Geo-Distributed Physical infrastructure (C6, C10). For regulatory and performance reasons we operate a geo-distributed physical infrastructure out of various locations as illustrated on the right hand side of Fig. 2: dedicated data centers, collocation sites, managed hosting environments, and public cloud platforms. The overall setup is designed for disaster resilience, i.e., one unavailable site can be compensated by another. While our primary production sites are in continental Europe we are also present with our own hardware on-site at local exchanges such as Hong Kong or London for connectivity and due to local regulations. Gigabit Connectivity (C1, C3, C4, C10). We connect our locations with redundant dedicated dark fiber gigabit lines. These also connect us with most of our contributors and customers as this is the predominant mode for exchanging financial data streams due to their volume and latency requirements; same to connect our locations to global public cloud providers. This way we can use these resources transparently within our network. Currently, one dedicated public cloud connection has 10 Gbit bandwidth but connections can be trunked. Resource Pools (C1, C3, C4, C6, C8, C10). Within our sites we operate cascading tiers of several hundreds of physical and virtualized servers per site. While we heavily rely on virtualization for optimized resource utilization, security, resilience, and scalability we operate different resource pools based on the workload to be processed: dedicated physical servers for processing data feeds and legacy monolithic applications, virtual desktop environments for providing hosted terminals to customers, private cloud platforms for containerized systems (vwd Cloud), and public cloud environments to exploit resource elasticity for batch processing and burst-outs. Internally we use gigabit lines and software defined networks (SDN): 10 Gbit for traffic-intensive platforms and 1 Gbit for less utilized environments. Regarding storage we apply a mix of centralized and decentralized hyperconverged storage solutions (e.g., CEPH). Long-term storage is a crucial topic for us from a product and compliance perspective as we have to keep certain data for regulatory reasons up to ten years. Thus we combine on-site and off-site storage pools which are continuously synchronised.

The Complexity of Processing Financial Data at Scale

3.2

25

Organization: Balance Agility with Regulatory Accountability

Organizational structures and measures set the frame for technical design decisions and tooling to fully realize their potential—and vice-versa. Thus we apply a two-speed approach for our production systems to address C6, C8, and C10 by balancing the need for reliably improving legacy systems (slow track) with fast innovation to develop new products using agile methodologies such as SCRUM (fast track). As a key enabler for this approach we have completely restructured our organization: we reduced hierarchies, broke down technology- and locationbased silos and instead created cross-location DevOps teams. A company-wide framework of IT policies describes how our processes and procedures align with legal and regulatory requirements in regard to information security, service design, open source license management, and operations (C5, C6). Automation embeds these guiding principles directly in the implementation and execution of a process without the need for procedural documentation; Infrastructure as Code (IaC) and CI/CD pipelines guarantee the required accountability of releases.

4

Conclusion, Ongoing and Future Work

In this paper we outlined the challenges arising from processing financial data at scale. We identified ten key challenges C1–C10 that stem from data management, IT governance, and (IT) compliance. In particular we contributed insights into the processing of financial data streams along the dimensions of volume, variety, velocity, and veracity used in the context of Big Data. We outlined how these challenges are addressed at vwd on a technical and organizational level: using a geo-distributed physical infrastructure to run an event-driven platform that combines SOA and EBS paradigms to seamlessly integrate legacy systems while allowing for rapid development of new products using agile approaches. As part of ongoing work we evaluate open platforms such as Kafka, NATS, and STORM for the use in our ticker plant [2]. We do also assess the sweetspot in our core processing technology stack to apply virtualisation on a host- and an applicationlevel (containerization) to benefit from increased portability and scalability. As part of future work we address the existing research gap regarding benchmarks for EBS that are suitable for the use in financial data stream processing scenarios.

References 1. BaFin: Minimum requirements for risk management for banks. https://www.bafin. de/dok/11681598 (2018). Accessed 09 May 2019 2. Coenen, M., Wagner, C., Echler, A., Frischbier, S.: Benchmarking financial data feed systems. In: DEBS 2019, pp. 252–253. ACM (2019). https://doi.org/10.1145/ 3328905.3332506 3. CSSF: Circular CSSF 17/654. https://www.cssf.lu/fileadmin/files/Lois reglements/ (2017). Circulaires/Hors blanchiment terrorisme/cssf17 654eng upd 19 714.pdf Accessed 09 May 2019

26

S. Frischbier et al.

4. EBA: Final report on EBA guidelines on outsourcing arrangements. https://eba. europa.eu/documents/10180/2551996/EBA+revised+Guidelines+on+outsourcing+ arrangements. Accessed 12 Feb 2019 5. Frischbier, S., Buchmann, A., P¨ utz, D.: FIT for SOA? Introducing the FIT-metric to optimize the availability of service oriented architectures. In: CSDM 2012, pp. 93–104. Springer (2012). https://doi.org/10.1007/978-3-642-25203-7 6 6. Frischbier, S., Paic, M., Echler, A., Roth, C.: A real-world distributed infrastructure for processing financial data at scale. In: DEBS 2019, pp. 254–255. ACM (2019). https://doi.org/10.1145/3328905.3332513 7. Frischbier, S., Pietzuch, P., Buchmann, A.: Managing expectations: runtime negotiation of information quality requirements in event-based systems. In: ICSOC 2014, pp. 199–213. Springer (2014). https://doi.org/10.1007/978-3-662-45391-9 14 8. Hinze, A., Sachs, K., Buchmann, A.: Event-based applications and enabling technologies. In: DEBS 2009. ACM (2009). https://doi.org/10.1145/1619258.1619260 9. Saha, B., Srivastava, D.: Data quality: the other face of big data. In: ICDE 2014, pp. 1294–1297. IEEE, March 2014. https://doi.org/10.1109/ICDE.2014.6816764

Verification of BPMN Models Mihal Brumbulli1(B) , Emmanuel Gaudin1 , and Frédéric Berre2 1 PragmaDev, 18 rue des Tournelles, 75004 Paris, France

{mihal.brumbulli,emmanuel.gaudin}@pragmadev.com 2 DGA, 16 bis, Avenue Prieur de la Côte d’Or, 94110 Arcueil, France [email protected]

Abstract. Models of complex systems and systems of systems are described with NAF (NATO Architecture Framework) or DoDAF (DoD Architecture Framework). Business Process Model Notation (BPMN) is part of NAF and allows describing the behavior of the different participants in the model. This notation is used by the French Army as well as its main suppliers to describe the interactions between participants involved in a mission. It is therefore important the models are correct. The VeriMoB project is a research project financed by the DGA (Direction Générale de l’Armement) in collaboration with Eurocontrol and Airbus DS who provided some real use cases. The project aims at developing a tool that will help users to verify their BPMN models. This tool covers three main aspects: a static verification, an interactive execution, an automatic exploration of the possible scenarios. This paper will present the results from this project.

1 Introduction Business Process Model Notation (BPMN) is a notation standardized by the Object Management Group (OMG). [1] BPMN is a widely used language to describe processes and interactions between different participants in a complex organization. A process consists of a sequence of tasks executed by several participants to fulfil a specific mission. A set of complex alternative constructions in the model allows exploring the possible variations in the scenarios. The model should eventually be able to describe all possible situations and interactions in the organization. BPMN is used to describe a wide variety of systems such as air traffic control, satellite constellations, or army forces coordination. Inherent to the complexity of such systems it is paramount to make sure the models are functionally correct. In practice that means each possible scenario described must make sense and is agreed by all involved parties. In practice the different stakeholders gather in the same room and go through the different alternatives described in the model. The model is corrected and eventually everybody will agree. But these meetings are time consuming and error prone because interpretation is made by humans. The basic principles of the notation are very simple and straight forward. The model describes a succession of tasks realized one after the other. When there is an alternative, a gateway symbol is used to describe an exclusive, an inclusive, or a parallel choice of path. A hierarchy of scenario can also be described using the call activities and information between participants is exchanged via message flows. Even though the basic concepts © Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 27–36, 2020. https://doi.org/10.1007/978-3-030-34843-4_3

28

M. Brumbulli et al.

are easy to understand there is a number of subtle semantic variations in the standard that makes it tricky to interpret. Also the information on which the paths are selected depends on conditions that are described in natural language. In the end it is quite probable that the same model might be interpreted differently by two different readers. A tool that can interpret the notation and replay a set of scenarios would be of great help to speed up the verification process and settle down the real meaning of the model. On the other hand there are mature languages that do not suffer any form of interpretation such as the ITU-T standard Specification and Description Language (SDL). [2] Thanks to its precise action language and execution semantic it is possible to execute an abstract SDL model without any further consideration on its final implementation. Globally speaking it appears BPMN and SDL are based on a similar concept, to describe the dynamic interactions between different participants. The idea of the VeriMoB project is therefore to use the existing SDL execution tools technologies on BPMN models in order to verify them. This project was funded by the French Army (DGA) in collaboration with Eurocontrol and Airbus DS who provided some real use cases. This paper will go through the different steps the project went through: importing the BPMN, viewing the BPMN, executing the BPMN, and tracing its execution.

2 Motivation and Objectives The DGA (Direction Générale de l’Armement) is the French government defense procurement and technology agency responsible for the program management, the development and the purchase of weapon systems for the French army. The agency, in cooperation with the European Defense Agency, coordinates the different equipment manufacturers in France and in Europe. Its missions are to prepare future defense systems, to provide technical and scientific expertise, to evaluate and try defense systems, and to promote them internationally. The CATOD (Centre d’Analyse Technico-Opérationnelle de Défense) is the operational technical expertise and analysis bureau within the agency. In the framework of the MASD (Maîtrise du Système de Défense) aiming at controlling the defense system, the CATOD is committed to define an architecture framework that serves as a reference to integrate all defense systems models. This integration requires the various models to be syntactically correct and semantically verified. The VeriMoB project is part of this verification process that will help to ensure the different architecture models developed within this framework are consistent and sound.

3 Related Work There is a substantial set of tools supporting BPMN. While all of them provide the ability to edit the different diagrams, some of them provide sharing capabilities dedicated to large organizations, and a few provide execution facilities and simulation features. The simulation features are actually referring to statistical simulation that includes capabilities and statistical input information computed automatically.

Verification of BPMN Models

29

In [3] the authors evaluate the model against the real system through history logs. Even though that is interesting to make sure the system conforms to the model, it does not help to verify beforehand that the BPMN model is actually correct. The Business Process Simulator BIMP is an on line simulation tool supported by the University of Tartu and the Estonian Research Council. [4] The model is uploaded and a simulation scenario is defined. As a result the tool will estimate the costs of the system and of each individual process, as well as potential bottlenecks and resource utilization. This will help in optimizing the model but not verifying it. In [5] the authors investigate how to make sure a new version of a BPMN model does not suffer from regression through the use of model checking techniques. This process will verify that some properties are still valid when the model is modified, but that does not verify the model in the first place against the same properties and it does not address the verification of functional properties. In [6] a list of BPMN simulation tools are evaluated to optimize performance of the model. BIMP is considered simplistic, Bizagi is considered user friendly, BPSim was evaluated the most complete, BonitaSoft was in an early phase of development, and Visual Paradigm suffers from its UML origin and has pretty limited possible inputs. Because they are simulation tools that target performance optimization the inputs are statistical laws. Their unique goal is to optimize the throughput of the model or the necessary resources. In [7] the BPMN description is transformed to PIF (Process Intermediate Format) which is then transformed to LNT (LOTOS New Technology) to be fed into CADP (Construction and Analysis of Distributed Processes) verification tool from INRIA. Even though the paper does not mention it, it is very unlikely the BPMN semantics are respected through the multiple transformations. In the end the limitation of the CADP tool will end up with a very experimental result. In [8] the authors present an overview of business process models verification tools. Among the numerous references in the paper two aspects of the model can be verified: the syntactic correctness to prevent improper usage of the modeling elements, the structural correctness to prevent wrong dynamic behavior. For each verification tool the coverage of the different aspects is described but the correctness of the behavior is not addressed. The investigation of the state of the art around BPMN shows that the VeriMoB project addresses a unique verification capability that no other tool offers. It might be interesting to discuss the vocabulary used in this domain. Usually a simulation is the execution of a model step by step. In BPMN world, simulation is often understood as a statistical set of inputs providing a statistical set of outputs in order to evaluate the necessary resources for a whole system throughput. For that reason we will preferably use the term execution instead of simulation.

4 Importing the Model BPMN comes with a standardized XML schema that produces light files that are human readable. Therefore importing a BPMN model was quite straight forward.

30

M. Brumbulli et al.

The second step was to provide a viewer of the model so that when execution takes place the user can see where he is in the model. The XML for the BPMN contains the necessary graphical information for each symbol so that did not lead to any interpretation of the imported model. The viewer required quite some work mainly because of missing font and formatting information in BPMN XML files produced by other tools, but in the end the resulting model is very similar to the original one generated by said tools. Then came the time of static analysis of the model in order to build a solid Abstract Syntax Tree (AST) that will lay the basis for byte code generation and execution. A number of verifications are done during that analysis, including all rules defined in the BPMN standard with some additions: • Make sure each message flow has an identified sender and an identified receiver that is not a “black box” pool or a call-activity. In these cases the analysis will try to find the actual sender and/or receiver in another diagram defining the pool (i.e., with the same pool as “white box”) or the process referenced by the call-activity. • Make sure events (start, end, intermediate, and boundary) of type message have an incoming/outgoing message flow. • Make sure there are no deadlocks, so that execution does not block or loop indefinitely. Because of the requirements of the use cases the verification level needed to be customized to allow some model constructions. An example of this is the possibility to have message flows between lanes, which are not allowed by the BPMN standard.

5 Executing the Model Because of the existing set of tools around SDL, the first attempt was to generate some intermediate byte code based on the SDL semantic so that most of the existing features would be directly available. As our investigations on the BPMN semantic progressed it turned out the translation from one notation to the other became quite tricky. So we evaluated the complexity of generating byte code from the BPMN AST as well as the possibility to execute the BPMN model directly from the AST without going through some byte code generation. In the end we evaluated the pros and cons of the different solutions and decided to move with a direct execution from the AST. With that choice we get more control over the semantic of execution, and that turned out to be quite useful as we dug deeper in the BPMN. At first sight BPMN looks fairly simple but as we implemented the proper execution semantic it turned out to be quite a challenge. One of the key reasons is that the notation is flow oriented where most of the other notations are participant oriented. So when starting execution of a model, it is not the participants that are started but a set of flows. That semantic variation creates a major difference with existing execution tools and requires a specific approach.

Verification of BPMN Models

31

In this flow oriented approach another main aspect needs to be taken into consideration. The flow is based on the concept of tokens,1 and some of the gateways can duplicate a token or split it in several tokens representing several flows. In order to illustrate the semantic and the problems that are inherited from this approach a set of simple constructions are presented below. The BPMN standard refers to tokens to describe the presence of the flow in the execution. In Fig. 1 is presented a basic exclusive gateway which is the most natural flow construction. The flow arrives through branch 0A to the forking gateway and can either go to branch 1A to task 1 or branch 2A to task 2. After that the flow reaches the merging gateway and continues to branch 0B. In Fig. 2 is presented an inclusive gateway example. In that case, when the flow arrives to the forking gateway through branch 0A, the user can decide it will continue on branch 1A and/or on branch 2A. If both branches are selected this will create two parallel flows: one going through task 1 and the other one going through task 2. After that, when reaching the merging gateway, the flows will merge when they both arrive at the gateway, and then continue to branch 0B.

Fig. 1. An exclusive gateway example.

Fig. 2. An inclusive gateway example.

1 The BPMN standard describes the execution semantics using tokens. However, execution tools

are not required to implement any form of token.

32

M. Brumbulli et al.

In Fig. 3 is presented a parallel gateway example. In that case, when the flow arrives to the forking gateway through branch 0A, it will automatically be followed by two parallel flows in branch 1A and branch 2A. Both flows will merge synchronously in the merging gateway before continuing through branch 0B.

Fig. 3. A parallel gateway example.

The above examples make complete sense because the forking gateway and the merging gateway are of the same type. But when different gateway types are combined the outcome might be misunderstood. In Fig. 4 the forking gateway is an exclusive one. That means there will be a flow in either branch but not in both. Since the merging gateway is a parallel one, it will wait for both flows from branch 1B and branch 2B to continue to branch 0B. One could think this a deadlock situation but it is not, because another flow can actually come from task 0B and go through the other branch. The merging gateway will then receive both flows and will continue to branch 0B.

Fig. 4. An exclusive forking gateway followed by a parallel merging gateway.

In Fig. 5 a simple loop is modeled. This looks fairly simple but hides a major problem. Task 1 acts as an implicit exclusive merging gateway and task 2 acts as an implicit parallel forking gateway. That means each time the flow goes through task 2, a flow goes to the end symbol and another goes to task 3. That is actually an infinite loop.

Verification of BPMN Models

33

Fig. 5. A loop example.

In Fig. 6 the executor provides a way for the user to select the branch to execute. A set of colors is used to show the possible branch to execute in purple, the currently executed branch in yellow, the executed branch in green. The graphical display makes the semantic of the model clear and understandable. The user can click a purple edge or shape based on the current context of execution, and observe the colors being updated to indicate the result of the selected action. The step-by-step method allows a fine grained control over the execution of the model.

Fig. 6. The status of branches as shown in the executor.

In Fig. 7 the infinite loop issue clearly appears as there is always a flow that never reaches the end symbol, because the implicit parallel forking gateway duplicates the flow at each iteration.

34

M. Brumbulli et al.

Fig. 7. Infinite loop as shown in the executor.

6 Tracing the Model As the user selects a branch or another, the VeriMoB tool can trace the choices of the user in a Message Sequence Chart (MSC) often called Sequence Diagram. The path of messages, flows, and tasks are displayed live during the execution in the resulting diagram. The idea is to produce a clear documentation of the scenario that can be read by everybody where the BPMN can only be read by modeling specialists. There is also some ongoing work to use the execution trace as an input scenario that could be played back on the model. This would substantially reduce the time required to prevent any type of regression. Figure 8 shows the execution of a model,2 while Fig. 9 is the trace of the executed scenario.

Fig. 8. Execution of the Close Air Support model.

2 The “Close Air Support” model is used by the DGA for training proposes.

Verification of BPMN Models

35

Fig. 9. An execution trace of a Close Air Support model.

7 Conclusions VeriMoB project was aiming at verifying BPMN models. For that matter a set of tools have been developed including a syntactic analyzer, a dynamic execution engine, and a tracing mechanism. Out of the different use cases involved in the VeriMoB project, it turned out all models were actually semantically not correct. Not only the VeriMoB helps to make sure the model is correct, it also helps to document the different scenarios the modeler were willing to express. The development of a verification tool of the architecture descriptions, designed in the modeling framework of the MASD, provides the necessary software functionalities to qualify each model for their future use. The practical use of such a software module finalizes the modeling with a necessary verification in order to appreciate the technical and operational consistency of the architecture of the defense system. The iterative integration of the difference architectures within a unique framework leads to a representation of the defense system structure. The double verification, syntactic and semantic, of each model assesses their technical and operational consistency to be integrated in the defense system.

36

M. Brumbulli et al.

In the second part of the project some automatic verification of the model will be investigated with the collaboration of ENSTA Bretagne. The idea is to automatically verify a set of properties in the model.

References 1. OMG: OMG Business Process Model and Notation (BPMN). Version 2.0.2. OMG Standard, Object Management Group (2013). http://www.omg.org/spec/UML/2.5 2. ITU-T: Specification and Description Language – Overview of SDL-2010. ITU-T Recommendation, International Telecommunication Union – Telecommunication Standardization Sector (2011). http://handle.itu.int/11.1002/1000/11387 3. Allani, O., Ghannouchi, S.: Verification of BPMN 2.0 process models: an event log-based approach. Proc. Comput. Sci. 100, 1064–1070 (2016) 4. BIMP: BIMP - The Business Process Simulator (2019) 5. Aguilar, J., Hasebe, K., Mazzara, M., Kato, K.: Model Checking of BPMN Models for Reconfigurable Workflows. CoRR abs/1607.00478 (2016) 6. Freitas, A., Pereira, J.: Process simulation support in BPM tools: The case of BPMN (2015) 7. Krishna, A., Poizat, P., Salaün, G.: VBPMN: automated verification of BPMN processes. In: 13th International Conference on integrated Formal Methods (iFM 2017) (2017) 8. Suchenia, A., Wisniewski, P., Ligeza, A.: Overview of verification tools for business process models. In: Communication Papers of the 2017 Federated Conference on Computer Science and Information Systems, FedCSIS 2017, Prague, Czech Republic, 3–6 September 2017, pp. 295– 302 (2017)

Synchronization of System Architecture, Multi-physics and Safety Models Michel Batteux1 , Jean-Yves Choley2 , Fa¨ıda Mhenni2 , Luca Palladino5 , Tatiana Prosvirnova3,4(B) , Antoine Rauzy6 , and Maurice Theobald5 1 IRT SystemX, Palaiseau, France Quartz Laboratoire, Supmeca, Saint-Ouen, France Laboratoire Genie Industriel, CentraleSup´elec, Gif-sur-Yvette, France 4 ONERA/DTIS, UFTMiP, Toulouse, France [email protected] 5 SAFRAN Tech, Chˆ ateaufort, France Norwegian University of Science and Technology, Trondheim, Norway 2

3

6

Abstract. To face the growing complexity of technical systems, engineers have to design models in order to perform simulations. To avoid inconsistencies, the integration of different models coming from various engineering disciplines is one of nowadays main industrial challenges. In this article we present model synchronization, a framework to ensure consistency between models coming from different engineering domains, based on S2ML (System Structure Modeling Language). We show how the introduced framework can be used to handle consistency between system architecture models (using SysML language), safety models (using AltaRica 3.0 language) and multi-physics simulation models (using Modelica language). Keywords: Heterogeneous models · Model synchronization structuring · AltaRica · SysML · Modelica

1

· Model

Introduction

Technical systems are getting more and more complex. To face the increasing complexity of systems, engineers are designing models. These models have different maturity levels and are designed at different abstraction levels and for different purposes. The integration of models coming from various engineering disciplines, such as system architecture, control, multi-physics simulation, automatic code generation, safety and performances analyses, is one of today’s industrial challenges. Collaborative data bases (PDM/PLM) and tools to set up traceability links between models provide a support to manage models in version and configuration, but not to ensure consistency between them. Model transformation techniques (e.g. [3,7,10,12]) assume a master/slaves’ organization of models, which is not realistic in practice. c Springer Nature Switzerland AG 2020  G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 37–48, 2020. https://doi.org/10.1007/978-3-030-34843-4_4

38

M. Batteux et al.

In this article we present model synchronization – a framework to ensure consistency between models coming from different engineering domains. In this approach each engineering discipline uses its own modeling languages and tools which makes it possible to have flexibility and to be efficient in conducting virtual experiments on the system under study. The framework is based on the thesis that systems engineering modeling formalisms are made of two parts: – An underlying mathematical framework, which aims at capturing some aspects of the system behavior, e.g. differential equations for Modelica [5] and Matlab-Simulink, Data-Flow equations for Lustre, Guarded Transition Systems for AltaRica 3.0; – A structuring paradigm that makes it possible to build and organize models by assembling parts into hierarchical descriptions. Behavioral descriptions are specific to each engineering domain. On the contrary, the structures of models reflect to some extent the structure of the system under study. Therefore, our framework focuses on structural comparisons and is based on S2ML (System Structure Modeling Language) [1]. Models from different engineering domains cannot be compared directly. First, they are abstracted into a pivot language (S2ML). Second, their abstractions are compared. To support model synchronization we develop the SmartSync platform, which is used to compare S2ML abstractions of heterogeneous models. To illustrate our proposal we use a case study – an Electro-Mechanical Actuator (EMA) of an aileron for a small aircraft. We show how the introduced framework can be used to handle consistency between system architecture models (designed in SysML [4]), multi-physics models (designed in Modelica [5]) and safety models (designed in AltaRica 3.0 [2]). This work continues the work on model synchronization presented in [9] and [6]. An interesting study [8] uses model synchronization techniques with hierarchical graphs. The remainder of this article is organized as follows. Section 2 introduces the case study. Section 3 describes the model synchronization framework. Section 4 presents the results. Finally, Sect. 5 concludes this article and discusses future works.

2

Case Study

The considered case-study is an Electro-Mechanical Actuator (EMA) for general aviation small aircraft. The EMA is intended to actuate the aileron, replacing the usual rod, cables and lever mechanisms. The proposed actuator is driven by the aircraft electrical networks, controlled by the on-board FCC (Flight Control Computers) with a set point consistent with the pilot instructions, taking into account the aileron feedback position and the EMA feedback. There are different relevant kinematic architectures such as a 4-bars with a crank and rod mechanism, a 3-bars with an electric cylinder or a direct drive

Synchronization of System Architecture, Multi-physics and Safety Models

39

with a motor and a gearbox mounted on the axis of the revolute joint between the wing and the aileron. In this work, we will focus on the 3-bars architecture. This architecture is illustrated in Fig. 1. Linked to the wing and the aileron with two spherical joints, the EMA is made up of a housing that encapsulates all the components, a DC motor controlled by a Micro Controller Unit (MCU) (not represented), a gearbox and a screw and nut assembly to transform the gearbox output rotation into a translation of a rod that will in turn push or pull the aileron.

Fig. 1. EMA 3-bars architecture.

3 3.1

Model Synchronization Principle

Integration of engineering models can be achieved by model synchronization process, i.e. the process by which one can ensure that two possibly heterogeneous models are “speaking” about the same system. Two models, written into two different languages, can generally not be directly compared. The idea is thus to abstract them into a pivot language and to compare their abstractions (see Fig. 2). The synchronization of models goes in two steps. The first step of model synchronization process is the abstraction, which consists in extracting the common part that can be compared from the models. The second step is to compare the abstractions. The third step, the so-called concretization, consists in eventually adjusting initial models if inconsistencies have been detected. 3.2

S2ML as a Pivot Language

S2ML (System Structure Modeling Language) [1] aims at providing a structuring paradigm of systems engineering modeling languages. It unifies concepts coming from object-oriented and prototype-oriented programming languages. As heterogeneous models can be essentially compared by their structure, S2ML is a perfect candidate as a pivot language for the abstraction. S2ML is made of the four basic elements: ports, connections, blocks and attributes. Ports are basic objects of models (e.g. variables, events, parameters).

40

M. Batteux et al.

Fig. 2. Model synchronization: principle.

Connections are used to describe relations between ports (e.g. equations, transitions, assertions). Blocks are containers composed of ports, connections and other blocks. Attributes are couples (name = value) used to associate information to ports, connections and blocks. Example: Consider a non repairable component (NRComponent) in AltaRica 3.0 having a Boolean state variable vsWorking and a failure event evFailure. Its S2ML abstraction would be as illustrated in Fig. 3. class NRComponent port vsWorking(kind="variable", type="Boolean", init="true"); port pLambda(kind="parameter", type="Real", value="1.0e-5"); port evFailure(kind="event", delay="exponential(pLambda)"); connection [ evFailure, vsWorking ](type="transition", guard="vsWorking", action="vsWorking := false"); end

Fig. 3. S2ML code for the block NRComponent.

The class NRComponent contains three ports vsWorking, evFailure and pLambda having different attributes, and a connection, which represents the transition labeled by the event evFailure. In S2ML, ports, connections and blocks are interpreted by themselves. But a particular modeling language, implementing S2ML as its structuring paradigm, can give a concrete interpretation to ports, connections and blocks. For example, in AltaRica 3.0 variables, parameters, events and observers are interpreted by ports; transitions and assertions are interpreted by connections, blocks are interpreted by blocks. S2ML provides three relations: composition, inheritance and aggregation. Composition is the simplest structural relation: a system composes a component means that the component “is part of” the system. In S2ML, the composition is represented by adding different components within the code of the system as shown in the example below. Example: In the example given in Fig. 4, the block EMASystem 1 contains blocks ElectricPower, MCU and Motor and also other blocks, ports and connections not represented here.

Synchronization of System Architecture, Multi-physics and Safety Models

41

class Motor extends NRComponent; port vfFromMCU (type ="Boolean", reset = "false"); port vfToGearbox (type="Boolean", reset = "false"); connection assertion [vfToGearbox, vsWorking, vfFromMCU]; end block EMASystem_1 // ports block ElectricPower extends NRComponent; port vfToMCU ( type = "Boolean", reset = "false"); connection assertion[ vfToMCU, vsWorking]; end block MCU extends NRComponent; // the remainder of the block MCU end Motor Motor; // the remainder of the block EMASystem_1 end

Fig. 4. S2ML abstraction of the AltaRica 3.0 model of the EMA system.

Inheritance makes it possible to an element (block or class) to acquire all the properties of another element without explicitly duplicating them. Inheritance implements the “is a” relation between modeling elements. In S2ML, the inheritance is represented by the keyword “extends”. Example: In the AltaRica 3.0 model of the EMA system, all the components extend the class NRComponent (see Fig. 3) as they may fail in operation. In the example given in Fig. 4, the block ElectricPower extends the class NRComponent defined previously. It contains all the ports and connections of the class NRComponent and adds a port vfToMCU and a connection assertion. Aggregation is a “uses” relation between modeling components. It makes it possible to represent components which are not a part of the subsystem and may be shared by several subsystems. The clause “embeds” in S2ML refers to an aggregation. S2ML also proposed two different ways to reuse modeling elements: Prototype/Cloning and Class/Instance mechanisms. The first way comes from prototype-oriented programming languages. A block is a container for ports, connections and other blocks. Each block is a prototype, i.e. it has a unique occurrence in the model. A system may contain similar components or subsystems. To avoid duplicating the description of a block, it is possible to clone an already existing one. In S2ML, the cloning of a block is obtained by the keyword “clones”. The second way to avoid duplicating the description of a block originates from object-oriented programming languages and consists in declaring a model of the duplicated block in a separate modeling entity, the so-called class, and then in instantiating this class wherever we need to use it again. Obviously, the class is referred to by the keyword “class” in S2ML. Each instance of the class is obtained by writing the name of the class followed by names of the created instances. Example: In the example given in Fig. 4 a class Motor is defined. It is instantiated inside the block EMASystem 1.

42

M. Batteux et al.

Unfolded Model. Any hierarchical model is semantically equivalent to an unfolded (also called instantiated) one. An unfolded S2ML model is a model made of a hierarchy of nested or aggregated blocks, connections and ports. This model is obtained by applying recursively rewriting rules, the so-called unfolding rules. These rules resolve inheritance, classes instantiation, blocks cloning and paths of aggregated elements. An unfolded (or instantiated) model is used in the comparison step of the model synchronization. 3.3

SmartSync Platform

The proposed platform for model synchronization SmartSync is illustrated in Fig. 5. The first step of the model synchronization is the abstraction, which consists in translating models into S2ML. This step is still done manually for the moment but it can be automated. In the next step, the abstractions of the different models are compared two by two and a report of the comparison is generated. This report is then analyzed by the members of the different teams that built the initial models. Together, they produce a matching file that matches the same elements in the two models. The next step of the comparison process consists in comparing the initial models using the matching file. Another report is then generated that contains a list of inconsistencies. This report is analyzed again by the members of both teams. The matching file is updated with new corresponding elements. The updated matching file is used again in the comparison of the model abstractions and so on. The process iterates until all the inconsistencies have been resolved. At each iteration, if an inconsistency is detected, one or both models should be updated.

Fig. 5. Models synchronization process.

The outcome of the model synchronization is twofold. First, it allows to detect model inconsistencies in which case models need to be updated. Second, it allows to validate the model consistency. Models can then be used to produce performance indicators and so on. Different types of comparators (see [11] for an interesting survey on model comparison techniques) for S2ML models can be defined, for instance:

Synchronization of System Architecture, Multi-physics and Safety Models

43

– Dictionary, which consists in matching the names of different elements (ports, nested/aggregated blocks and connections); – Structural, which consists in matching the names of different elements and the structure of the model; – Topological, which consists in matching the names of different elements, the structure of the model and the connections between ports. Note that the choice of abstractors and comparators depends on the system under development and the level of maturity of the project.

4

EMA Case Study: Model Synchronization

We present a collaborative design of the EMA system introduced in Sect. 2. The collaboration is between three teams: system architecture, multi-physics simulation and safety. Each team performs different activities. The first activity is modeling, i.e. the creation of models, which is performed independently by members of each team using different modeling languages and tools. The second activity is model synchronization, i.e. the verification of consistency between models that ensures that models are describing the same system. This activity is performed by the members of both teams (for example, system architecture and safety teams) and involves the SmartSync platform. The results of this activity can be twofold: models can be validated or inconsistencies can be detected. 4.1

Modeling

The EMA system is modelled from three different points of view: system architecture, multi-physics simulation and safety.

Fig. 6. SysML and Modelica models of the EMA system.

System architecture model is created using SysML [4] with a particular focus on system physical architecture. The internal block diagram representing the

44

M. Batteux et al.

EMA physical architecture is given Fig. 6 on the left. It has been done using SysML plugin of MagicDraw modeling tool. This model has no redundancies and does not represent the system environment. The incidence sensor is supposed to be a part of the block Motor ; it is represented by a port Motor Position of the block Motor connected to the port Motor Position of the block MCU. The multi-physics model of the EMA is designed with Modelica [5] modeling language and the OMEdit tool1 . Its graphical representation is given Fig. 6 on the right. It represents not only the EMA system itself but also its environment (e.g. the wing, the aileron, the pilot commands, etc.) in order to be simulated. The safety model is created using AltaRica 3.0 modeling language [2] and the OpenAltaRica platform2 . Figure 7 shows the graphical representation of the AltaRica 3.0 model of the EMA system. This model is an extended reliability block diagram, where blocks represent system components and their failures, connections between blocks – the propagation of failures. The block Observer models the failure condition – loss of the aileron incidence control.

Fig. 7. Graphical representation of the AltaRica 3.0 model of the EMA system.

4.2

Synchronization of System Architecture and Multi-physics Models

First, both models are abstracted, i.e. transformed into S2ML. For SysML internal block diagrams the transformation is quite simple: blocks/parts are transformed into S2ML blocks, ports into S2ML ports and connections between ports are transformed into S2ML connections between the corresponding S2ML ports. For Modelica the choice has been done to completely abstract the internal behavior of each Modelica class, only variables involved in the “connect” clause are considered. Thus, Modelica classes are transformed into S2ML classes, instances of classes are transformed into instances of the corresponding S2ML classes, variables involved in the “connect” clause are transformed into S2ML ports, “connect” clauses between variables are transformed into connections 1 2

https://openmodelica.org/. https://www.openaltarica.fr/.

Synchronization of System Architecture, Multi-physics and Safety Models

45

between the corresponding ports in S2ML. All the other Modelica elements (variables, parameters, equations, etc.) are not considered in the S2ML abstraction. In the next step, the abstractions are compared and a report is generated. This report is analyzed by members of both teams. The following differences are detected: – Different names of blocks (e.g. the block Motor in the SysML model corresponds to the block dcpm in the Modelica model); – SysML block corresponding to several Modelica blocks (e.g. the block BallScrewAndNutAssembly in the SysML model corresponds to the blocks idealGearR2T1, prismatic1, bodyBox3 and bodyBox4 in the Modelica model); – Elements of the multi-physics simulation model not represented in the system architecture model (e.g. blocks world, Aileron, wing have no equivalent in the system architecture model as they are part of the system environment). All the differences are listed in the matching file, which makes it possible to establish the correspondence between the two models. The following table shows an extract of a matching file. Type Model1 (SysML)

Model2 (Modelica)

block

main.EMASystem 1

main.EMA 3bars BF sin2PID

block

BallScrewAndNutAssembly idealGearR2T1, prismatic1, bodyBox3, bodyBox4

block

EMAAileronJoint

spherical1

block

EMAWingJoint

universal1

block

Gearbox

idealGear1

block

MCU

PID, signalVoltage1

block

Motor

dcpm

block

forget

wing

block

forget

Aileron

block

forget

world

...

...

...

The first column is the element type (port, block, aggregated block or connection). The second column is the name of the element of the first model, the third column is the name of the corresponding element in the second model. When there is no correspondence, the keyword forget is used. It is possible to add a fourth column with comments to justify matching decisions. As we can see, for example the block wing of the Modelica model has no correspondence in the system architecture model because it belongs to the system environment but it is needed to be able to perform multi-physics simulations. The block MCU in the SysML model corresponds to two blocks in the Modelica model: PID and signalVoltage1. The produced matching file is used to compare again the abstractions of the system architecture and multi-physics simulation models. In the next step of the comparison, new differences are detected. They are analyzed again by the members of both teams and several inconsistencies are detected. Some of them are summarized in the following table.

46

M. Batteux et al.

Type Model1 (SysML)

Model2 (Modelica)

block

EMASystem 1

EMA 3bars BF sin2PID

block

EMAWingJoint

universal1

port

MechanicalActionHW

port

WingMechanicalAction

port

Comments

Error in SysML frame a frame b

block

Gearbox

port

AdaptedMechanicalRotPower flange a

port

MechanicalRotPower

flange b

block

Motor

dcpm

port

MechanicalAction

port

MechanicalRotPower

port

RegulatedElectricalPower

pin ap

port

forget

pin an

...

...

...

Error in SysML

idealGear1

Not implemented in Modelica flange

There is an error in SysML model: the connection MechanicalActionHW between Housing and EMAWingJoint has to be replaced by a connection between BallScrewAndNutAssembly and EMAWingJoint. As we can see, one of the possible outcomes of the model synchronization is the detection of inconsistencies. In this case initial models should be adjusted. There are other approaches to create links between SysML and Modelica models, for instance ModelicaML [10]. 4.3

Synchronization of System Architecture and Safety Models

As previously, first, both models are abstracted. For AltaRica 3.0 the transformation is straightforward, as the language uses S2ML as its structural paradigm. State and flow variables, events and parameters are abstracted to S2ML ports; transitions and assertions are transformed into connections; different structural constructs like inheritance, cloning, instantiation, etc. are transformed into their equivalents in S2ML. Then the abstractions are compared and a report is generated. This report is analyzed by members of both teams. The following differences are detected: – Different names of blocks (e.g. the block BallscrewAndNutAssembly in the SysML model corresponds to the block BallsCrewNutAssembly in the AltaRica 3.0 model); – Different names of ports (e.g. the port Motor.RegulatedElectricPower in the SysML model corresponds to the port Motor.vfFromMCU in the AltaRica 3.0 model); – Elements of the system architecture model not represented in the safety model (e.g. Motor.MechanicalActionHM has no correspondence in the safety model); – Elements of the safety model not represented in the system architecture model (e.g. state variables, failure events, parameters, etc. have no equivalent in the system architecture model). The following table shows an extract of a matching file.

Synchronization of System Architecture, Multi-physics and Safety Models Type Model1 (SysML)

Model2 (AltaRica 3.0)

block EMASystem 1

EMASystem 1

port ElectricalPower port InstructionAndFeedback block forget

ElectricPower.vfToMCU Instructions.vfToMCU Observer

block BallScrewAndNutAssembly

BallScrewNutAssembly

block EMAAileronJoint

EMAAileronJoint

port port port port port

AileronMechanicalAction MechanicalTransmissionPower forget forget forget

vfOut forget evFailure pLambda vsWorking

...

...

...

47

As we can see, the block Observer of the safety model has no correspondence in the system architecture model because it represents safety related information (i.e. the failure condition to study). The port ElectricalPower in the SysML model corresponds to the port ElectricPower.vfToMCU in the AltaRica 3.0. It is important to note that the block ElectricPower of the safety model has no equivalent in the architecture model. In the system architecture model this block is not represented as it belongs to the system environment, whilst the safety analyst decided to represent it in his model because the failure of the electric power causes the occurrence of the failure condition. The produced matching file is used to compare again the abstractions of architecture and safety models. In the next step of the comparison, new differences are detected. They are analyzed again and the matching file is populated with new matching information. Models are compared again. Finally, no more differences are detected. The consistency between system architecture and safety models is verified. The matching file establishes the correspondence between the two models.

5

Conclusion and Perspectives

In this article, we presented experiments on the synchronization of system architecture, multi-physics simulation and safety models of an electro-mechanical actuator for an aileron of a small aircraft. We showed that model synchronization can be used to ensure the consistency of heterogeneous models, designed within different formalisms and different modeling environments. To support model synchronization, we developed the SmartSync platform, which relies on S2ML as a pivot language. With SmartSync, we studied the EMA system. We checked consistency between system architecture and safety models and detected inconsistencies between system architecture and multi-physics simulation models. The process of making models consistent is iterative and involves

48

M. Batteux et al.

representatives of the engineering disciplines at stake. The SmartSync platform helps not only to check the consistency between models, but also to detect inconsistencies within models and to support the dialog between stakeholders. As future works, we plan to improve the SmartSync platform, notably by developing new comparison algorithms and abstraction methods.

References 1. Batteux, M., Prosvirnova, T., Rauzy, A.: From models of structures to structures of models. In: 4th IEEE International Symposium on Systems Engineering, ISSE 2018, Rome, Italy, October 2018 2. Batteux, M., Prosvirnova, T., Rauzy, A.: Altarica 3.0 in 10 modeling patterns. Int. J. Crit. Comput. Based Syst. (IJCCBS) 9, 133 (2019). https://doi.org/10.1504/ IJCCBS.2019.10020023 3. David, P., Idasiak, V., Kratz, F.: Reliability study of complex physical systems using sysml. Reliab. Eng. Syst. Saf. 95(4), 431–450 (2010) 4. Friedenthal, S., Moore, A., Steiner, R.: A Practical Guide to SysML: The Systems Modeling Language. Morgan Kaufmann/The MK/OMG Press, San Francisco (2011) 5. Fritzson, P.: Principles of Object-Oriented Modeling and Simulation with Modelica 3.3: A Cyber-Physical Approach. Wiley-IEEE Press, Hoboken (2015) 6. Legendre, A., Lanusse, A., Rauzy, A.: Toward model synchronization between safety analysis and system architecture design in industrial contexts. In: Marco Bozzano, Y.P. (ed.) Model-Based Safety and Assessment, Proceedings of the 5th International Symposium, IMBSA 2017, Trento, Italy, 11–13 September 2017, vol. 10437, pp. 35–49. Springer, Cham (2017). https://doi.org/10.1007/9783-319-64119-5 3 7. Mauborgne, P., Deniaud, S., Levrat, E., Bonjour, E., Mica¨elli, J.P., Loise, D.: Operational and system hazard analysis in a safe systems requirement engineering process – application to automotive industry. Saf. Sci. 87, 256–268 (2016) 8. Missaoui, S., Mhenni, F., Choley, J., Nguyen, N.: Verification and validation of the consistency between multi-domain system models. In: 2018 Annual IEEE International Systems Conference (SysCon), pp. 1–7, April 2018. https://doi.org/10. 1109/SYSCON.2018.8369561 9. Prosvirnova, T., Saez, E., Seguin, C., Virelizier, P.: Handling consistency between safety and system models. In: IMBSA 2017 (International Symposium on ModelBased and Assessment), Trento, Italy, pp. 19–34 (2017). https://doi.org/10.1007/ 978-3-319-64119-5 2 10. Schamai, W., Fritzson, P., Paredis, C., Pop, A.: Towards unified system modeling and simulation with ModelicaML: modeling of executable behavior using graphical notations. In: Proceedings of the 7th International Modelica Conference (2009). https://doi.org/10.3384/ecp09430081 11. Stephan, M., Cordy, J.R.: A survey of model comparison approaches and applications. In: MODELSWARD 2013 - Proceedings of the 1st International Conference on Model-Driven Engineering and Software Development, Barcelona, Spain, 19–21 February 2013, pp. 265–277 (2013). https://doi.org/10.5220/0004311102650277 12. Yakymets, N., Julho, Y.M., Lanusse, A.: Sophia framework for model-based safety analysis. In: Actes du congr`es Lambda-Mu 19 (actes ´electroniques). Institut pour la Maˆıtrise des Risques, Dijon, France, October 2014

Managing Margins Under Uncertainties Surrogate Modelling and Uncertainty Quantification Kyle Hall1 , Peter Schroll2 , and Sanjiv Sharma1(B) 1

2

Airbus Operations Ltd, Bristol, UK [email protected] Airbus Operations SAS, Bristol, UK

Abstract. Engineers account for uncertainties by using Design Margins, typically by introducing them implicitly. Although methods for quantifying uncertainty are well established at discipline level, they are not applied systematically. A hierarchy of assumed independent design margins makes it difficult to deduce architect level margins. Further, the implicit application of margins and reserve factors also obfuscates the mutualisation of the margins. Therefore, uncertainty aggregation is difficult, in the quantitative sense, leading to potential over design. Quantifying these uncertainties, making them explicit and aggregating them correctly enable the discovery of appropriate margins to manage the identified risks and opportunities. We show how uncertainties, arising at different levels in a design process, may be aggregated to provide variations in the performance metrics of a complex system. The approach is illustrated through a case study based on a notional aircraft; the performances metric chosen for this example is the cruise fuel consumption.

1

Introduction

During the early stages of a complex system’s design lifecycle, multiple sources of uncertainties arise due to many factors, for example: • variations in its perceived and intended operating context; both random and due to potential (unknown) unintended usage • inherent variations in the system elements, e.g. tolerances at the interfaces • emergent behaviours due to complex interactions amongst the system elements • the perceived benefits of incorporating new technology into the product may be imprecisely known, and • definitions & decisions that are yet to be taken. On one hand, the random variations give rise to aleatoric uncertainties, against which the behaviour of the system needs to be resilient. On the other c Springer Nature Switzerland AG 2020  G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 49–63, 2020. https://doi.org/10.1007/978-3-030-34843-4_5

50

K. Hall et al.

hand, the evolving definition and outcomes of future decision gives rise to knowledge deficits (epistemic uncertainties), against which the system definition needs to be robust. Whilst the knowledge deficits may be removed over time, random variations persist. Indeed the aleatoric uncertainties may also have aspects of epistemic uncertainties, because, initially, the random variations may be imprecisely known, but become better characterised over time, e.g. the distributions or the limits of the variations may become more concisely defined. In order to cater for these uncertainties, the definition of the design needs to be flexible enough to allow its definition to evolve within a prescribed scope; changes outside the prescribed scope may result in the costly activity of rearchitecting and redesigning the system. Such nugatory activities are referred to as loopbacks in the Set-Based Design literature [1]. Whilst the flexibility of the design can be accounted for by adopting a SetBased Design paradigm, the uncertainties are typically taken into account by including an evolving margin or reserve factor. As more information becomes known and the definition of the complex system design matures, the margins and reserve factors are refined accordingly. The focus of this article is on the quantification and propagation of parametric uncertainties and their use in setting design margins on the quantities of interest. The following sub-sections provide the context & motivation followed by a brief description of the enabling concepts – items that are needed to for interactively explorating the uncertainties to set margins. Section 2 describes the process and method for quantifying uncertainty & propagating their effects to the properties of interest. The case study to illustrate the approach is described in Sect. 3; the subsections discuss the results and reflect on the scalability of the approach for a wider application. 1.1

Context and Motivation

Consider a design property whose numerical value shall be less than a particular upper limit, e.g. structural loading and specific fuel consumption. For such cases, a lower value is perceived to be better; however, too low a value may lead to an over design. Therefore, how do we set appropriate margins such that the likelihood of exceeding some upper limit is minimised, whilst ensuring that the design meets other requirements (i.e. avoiding over-design)? The numerical values that a particular property may take on can be represented as a distribution of values. For a continuous property, normalised as a probability, the distribution is known as its Probability Density Function (PDF). Note that a property’s PDF may change depending on the system architecture and component sizing; it is not always an invariant. One example of the PDF for the property that ‘shall be less than a particular value’ is shown in Fig. 1a. The red bold ‘wall’ represents the value that should never be exceeded. The decision may then be posed as “what shall the value of the margin M0 be such that the probability of exceeding the upper limit is made acceptably small?” The margin, M0 , that potentially answers this question is shown in Fig. 1a as a dashed black ‘wall’.

Managing Margins Under Uncertainties Surrogate Modelling

51

If the two PDFs (f1 and f2 ) arise from two different solutions for the same system architecture, then it is clear that the solution that produced f2 is superior to the one that resulted in f1 . This is because the area under the PDF of f2 to the right of margin is smaller than that of the PDF for f1 ; therefore, the likelihood of exceeding the margin is less for a solution that resulted in the PDF f2 . There is no loss of generality in the above statements because the converse is also true. A design property whose numerical value shall be greater than a particular value (Fig. 1b) is reasoned in a similar way. Examples of such properties are material strength and specific range – i.e. the selected material must be stronger than some lower limit; the specific range of a vehicle must be greater than that of a competing product, respectively. Again, the question that arises is the mirror image: “how do we set margins on these types of constraints such that the likelihood of being below a particular value is minimised?”

(a) Margin where a property shall be less than a particular value

(b) Margin where a property shall be greater than a particular value

Fig. 1. Example Probability Density Functions (PDF) for a notional property

The distribution of values that a property has is typically determined through the analyses of the system elements, which may have arisen from domain-specific design activities. In this paper, we approach the aggregation of the uncertainties from these lower level engineering activities via surrogate models. Essentially, the surrogate models allow the integration of the multi-disciplinary analyses to produce the PDFs for the types of ‘properties of interest’ described above. In this article, the term figures of merit (FOM) is used to represent those properties of interest that are independent of the way a complex system is structured (i.e. solution-independent). For example, Specific Fuel Consumption is the quantity of fuel burned, in unit time, to produce a given engine output. This figure of merit is equally applicable to different ways a system requirement for a

52

K. Hall et al.

vehicle1 might be implemented; it indicates the efficiency of the prime mover to convert fuel into power. Therefore, the FOM, Specific Fuel Consumption, may be used to assess the feasibility of a number of competing solutions to a set of given system requirements. 1.2

Linking Product Strategy to Modelling & Simulation

The company’s product strategy defines the selection and initialisation of the FOMs. The concerns of the different stakeholders is expressed as a four-level model (Fig. 2). The information produced at any of the levels needs to be traceably linked to its adjoining levels to maintain the context and relevance of the information. Product Strategy addresses the business aspects of the product to be developed. The focus of this layer is on the overall product and the intended operational environment. The organisation’s Product Development Process (PDP) drives the activities performed in this layer. The customer-facing requirements give rise to the FOMs that concern the market; e.g. cost of ownership, range, and specific fuel burn. Similarly, the business-facing requirements give rise to the FOMs that concern the business; e.g. non-recurring costs, recurring costs, rate of manufacture and profitability of the product.

Fig. 2. Traceable association between product strategy and modelling & simulation

1

A set of FOMs are needed to ensure that all the requirements for the system are met - e.g. a bicycle, car, train, aeroplane require not only the Specific Fuel Consumption, but also the distance to be travelled, the expected speed of travel, the payload to be carried, etc.

Managing Margins Under Uncertainties Surrogate Modelling

53

Engineering Strategy addresses the design, development, manufacture, maintenance and eventual retirement of the product. The FOMs in this layer arise primarily from the desired performance characteristics of the product. (Multi-) Disciplinary Analysis addresses the different engineering disciplines that envisage the design of the system and structural elements that constitute the product. The numerical values obtained from the analyses are aggregated to quantify the various FOMs. The uncertainties associated with the numerical values is also assigned and appropriate margins are applied to the design parameters. Modelling & Simulation Execution is the environments to manage the domain-specific computational processes that are used to calculate the properties, capabilities and behaviours for the above layer – (Multi-) Disciplinary Analysis. The links amongst these layers need to ensure the continuity of the information such that they are shared in the context in which they arose. The software tools for Simulation Execution, the Simulation Business Process Management and Product Development Management environments share data and information seamlessly across the layers. Further, the Simulation Process and Data Management (SPDM) infrastructure enables the management of the process and data in the third and fourth layers, whilst also providing the window into the evolving data as the design progresses. The Architecture Cockpit (see Subsect. 1.3) provides the multidisciplinary window into the evolving product definition. The ‘digital thread’ between the SPDM and the Architecture Cockpit is maintained using the MoSSEC2 standard. The MoSSEC standard also provides the mechanism to declare and share uncertainties imposed on the design parameters as PDFs, and the placement of the margins arising from the assessments of the uncertainties. 1.3

Architecture Cockpit

The Architecture Cockpit is the name given to a set of user interface environments that allows multiple users to instigate, evaluate and interact with the evolving product data and information. The current implementation comprises four main modules: Study Management provides the interface for the users to describe, initiate, plan, launch and manage design studies. These studies allow domain-specific modelling and simulations processes to provided the requested data and information. Systems Exploration allows key Programme actors to visualise & explore product and associated enabling systems, thereby building links to orchestrate associated studies. The exploration of the design space is a significant feature of Systems Exploration. 2

MoSSEC: Modelling and Simulation information in a collaborative Systems Engineering Context (ISO/CD 10303-243) (https://www.iso.org/standard/72491.html).

54

K. Hall et al.

3-D Web Viewer provides an interactive view to the geometrical description of the product. Open to other web-based modules is an application-programming interface to provide means for extending the functionality of the Architecture Cockpit when further needs are identified. It provides that flexibility for generating dedicated viewpoints and is extensible to open-source or Airbus proprietary web-based modules. The key capability of the Architecture Cockpit is to interface and interact with the latest product information in ‘real time’. The additional viewpoints needed for managing margins, shown schematically in Fig. 4, is an example of the extensibility of the Architecture Cockpit. The diagram shows an instance of the Domain-Specific Analyses platforms interconnected to share data amongst the analyses models and the Architecture Cockpit. This is a simplified schematic of the lower two layers of Fig. 2 connected to the Architecture Cockpit. The use of the Architecture Cockpit for margins management needs to integrate information from different studies such that the uncertainties can be aggregated. One then needs to assess the correlations between the uncertain parameters to identify possible dependencies (interdependent parameters need to be treated differently from independent parameters). Further, one needs to determine the parameters that most contribute to the FOMs. Based on the available data, assessments are made on the likelihood of the FOMs violating the design intent, and decision is taken further analyses or transitioning to the next stage of the design process.

2

Quantifying and Propagating Uncertainties for Setting Margins

Uncertainty Quantification is the application of Probabilistic techniques to quantify uncertainties in Risks and Opportunities; whilst Management is the identification and implementation of strategies for minimising the quantified Risks, or more positively, maximising the quantified Opportunities. Uncertainties arise from many sources that may be loosely categorised into two groups: Epistemic (lack of knowledge) and Aleatoric (noise, natural randomness). In this work, our intention is on identifying and quantifying aleatoric uncertainties. The design parameters are divided into two classes: design variables and random variables, as shown in Fig. 5. The design variables are those that can be set and controlled to some desired precision (although the cost of precision may be high!). The random variables are those are not controllable but, nonetheless, affect the response (FOM) (Fig. 3). As described above, the Modelling and Simulation process performed at the domain-specific processes are interlinked, either tightly-coupled or looselycoupled (Fig. 6). There is a third topology: uncoupled simulations; these arise when the simulation activities are performed across the extended enterprise.

Managing Margins Under Uncertainties Surrogate Modelling

55

Fig. 3. User-facing functionality of the Architecture Cockpit

The ability to propagate uncertainties through these System of Analyses is implemented by using surrogate models. The process for quantifying and aggregating uncertainties, Fig. 7, starts by initializing the PDF for each random variable. If prior information is available, then the PDFs are determined by the existing data. Where prior information is not available, then various methods of expert judgment may be used to estimate the PDFs. These PDFs are used to create multiple samples of the random variables, which with particular values of the design parameters for the inputs to the surrogate models. Depending on the use of the models, the outputs from these surrogate models are the various FOMs. A set of appropriate surrogate models needs to be generated such that the time and computational expense is negated when many thousands of model executions are to be performed. Surrogate models belong to a class of data-driven models and require trusted data to build them. The data is obtained through physical or

56

K. Hall et al.

Fig. 4. Operational functions of the Architecture Cockpit

Fig. 5. Types of variables

computational experiments. These experiments are directed by using Design of Experiments to ensure that the design space is sufficiently covered to provide data over the area of interest. The surrogate model uses these input and output datasets to replicate the data to the desired accuracy. Various forms of surrogate models can be created to deal with multi-inputs, multi-outputs representations; e.g. neural networks, polynomial regressions and Gaussian Process Emulators. The following section describes how these methods can be applied through an illustrative case study (Fig. 8).

Fig. 6. Simulation coupling topologies

Managing Margins Under Uncertainties Surrogate Modelling

57

Fig. 7. Simplified process for quantifying parametric uncertainties

Fig. 8. Simplified process for building surrogate models

3

Illustrative Case Study

Consider a case where an aircraft design has an operation scenario shown in Fig. 9. The diagram shows a typical flight path that an aircraft would take from start of take-off roll to reaching cruise height. Four FOMs that arise in such a scenario are Side-Line Noise, Flyover Noise, Emissions and Cruise Fuel Consumption. At the early design stages, each one of these FOMs will have a degree of uncertainty. We wish to quantify the uncertainties and place design margins to ensure that the aircraft exhibits the desired behaviour, with an acceptable level of confidence. As described above, the first step is to create a sampling scheme (Design of Experiments) to produce a set of design and random variables as input to an experiment; our experiments are performed computationally. Further, we assume that the associated simulations are computationally-expensive process; therefore, it cannot be executed many thousands of times to produce statistically significant output datasets. This sampled dataset is then used to construct a surrogate model such that the response of the surrogate model is sufficiently accurate for its intended use. The inputs for the surrogate models can then be separated into design variables and random variables. For each set of design variables, a sample of random variables are injected into the surrogate model to provide a distribution of the

58

K. Hall et al.

Fig. 9. Diagrammatic description of the case study

outputs. The PDF of the FOM thus formed provides information for statistical analyses (for example, estimating the likelihood of exceeding a margin); conversely placing a margin such that the likelihood of exceeding an upper limit is made as small as possible. For the illustration of the margin management method, we use the Cruise Fuel Consumption as our FOM. 3.1

Data Generation

The data for this investigation was generated using the AirCADia [2,3] design environment, working in conjunction with Cranfield University as part of a study to explore the effects of aleatoric uncertainties in a multi-dimensional design space. To explore the limits and central regions of the design space a three level full factorial analysis was processed through the AirCADia [2,3] environment using the design and uncertainty parameters shown in Tables 1 and 2. Table 1. Design Parameters for processing in the AirCADia [2, 3] environment. Parameter

Parameter name Unit Processed values

Wing Reference Area

SW

Wing Aspect Ratio

AR W

Sea Level Static Thrust SLST

ft2

1300,1350,1400

N/A 9,10,11 lb

26000,29000,32000

Fan Pressure Ratio

FPR

N/A 1.5,1.65,1.8

Overall Pressure Ratio

OPR

N/A 30,35,40

Bypass Ratio

BPR

N/A 6,7,8

The AirCADia environment estimated the numerical values of the FOMs listed in Table 3. Note that EPNLdB (Effective Perceived Noise Level in decibels) is the unit of measurement for noise levels.

Managing Margins Under Uncertainties Surrogate Modelling

59

Table 2. Uncertainty Parameters for processing in the AirCADia [2, 3] environment. Parameter

Parameter name Processed values

Fuel Flow Factor

R FFFSUB

1,1.1,1.2

Drag Factor

R FCDSUB

1,1.1,1.2

Empty Weight Calibration R EWMARG

3.2

0.01,0.03,0.05

Building and Testing the Surrogate Model

By using the trusted dataset above, it becomes possible to produce a surrogate model that facilitates a continuous design space, constrained by the upper and lower limits highlighted in Tables 1 and 2. Further by withholding a small subset of data from the models training set for validation purposes, the models reliability can be assessed; considering correlations between predicted and known values. Table 3. Figures of Merit resulting from the processing within the AirCADia [2, 3] environment. Parameter

Unit

Flyover Noise

EPNLdB

Sideline Noise

EPNLdB

Cruise Fuel Consumption lb Emissions (NOx)

3.3

lb

Exploring the Design Space Along Perpendicular Facets

Considering a single design iteration at the “corner” of a multi-dimensional hypercube design space; perpendicular facets of the design space can be explored, through the use of three dimensional plots such as heat maps and contour plots. As such for this illustrative case study, it was possible to consider the perpendicular facets about the point indicated in Table 4; corresponding to a particular figure of merit, in this case Cruise Fuel Consumption as illustrated in Fig. 10. With this approach and assuming set values for the uncertainties, it can be seen that Cruise Fuel Consumption can be interpolated along the perpendicular facets. In fact it becomes possible to introduce an upper (45000) and lower margin (40000) for fuel consumption; representing margins on customer expectations and engineering cost respectively. Further, analysis of Fig. 10, under these margin conditions reveals regions of potential designs, such as the design point marked with a green cross. However, in line with the overview of quantifying uncertainties above, it is invalid to consider an epistemic uncertainty as having some fixed value; rather by definition these uncertainties can only be described by distributions determined through prior knowledge of the system being modelled or by Structured Expert Judgement.

60

K. Hall et al.

Table 4. Initial design iteration used for exploring perpendicular facets of the design space. Parameter

Value

Wing Reference Area (S W)

1300 ft2

Wing Aspect Ratio (AR W)

9

Sea Level Static Thrust (SLST)

26000 lb

Fan Pressure Ratio (FPR)

1.5

Overall Pressure Ratio (OPR)

30

Bypass Ratio (BPR)

6

Fuel Flow Factor (R FFFSUB)

1.05

Drag Factor (R FCDSUB)

1.10

Empty Weight Calibration (R EWMARG) 0.04

3.4

Uncertainty Analysis About One Design

Through expert judgement of the situation, the uncertainties within this system can be represented as triangular distributions within the limits defined earlier in Table 2, with modal values of each distribution being taken from the values used earlier in Table 4 (Fig. 11).

Fig. 10. An array of plots indicating the Cruise Fuel Consumption along perpendicular facets.

Managing Margins Under Uncertainties Surrogate Modelling

(a) Fuel Flow Factor (R_FFFSUB)

61

(b) Drag Factor (R_FCDSUB)

(c) Empty Weight Calibration (R_EWMARG)

Fig. 11. Uncertainty distributions

Processing these distributions through the surrogate model, a representative distribution for the set of design parameters marked in Fig. 10 can be produced, as illustrated in Fig. 12. From this it can be interpreted that although the modal expected outcome falls within the margins, as discussed earlier, the approximated percentage confidence in occurrence calculated by Monte Carlo sampling is 62.86%. Consequently the modal value within the uncertainty distribution cannot be used as a reliable metric in interpreting the design space. 3.5

Uncertainty Analysis About Perpendicular Facets

Combining both the perpendicular facets approach and the uncertainty analysis above; each pixel of Fig. 10 can be processed again through the surrogate

Fig. 12. Representative distribution about a singular set of design parameters.

62

K. Hall et al.

model and the percentage confidence of upholding the aforementioned margins determined. Figure 13 depicts the percentage confidence in complying with the assigned margins through the associated heat map, along with the contour lines from Fig. 12 to illustrate the modal cruise fuel consumption. 3.6

Reflections on the Case Study Results

Through this process a concept of Uncertainty aggregation has been illustrated, whereby it is possible to conceptualise how the low level uncertainty distributions feed through the design margin analysis of a single point in the design space, to result in the capability of visualising confidences across multiple dimensions of the design space. Through this analysis the process of managing risks and opportunities is simplified, with the minimal risk areas being indicated by high values in percentage confidence with minimal gradient changes across the plots. With reference to Fig. 13, it is apparent by the high gradients along regions of changing Bypass Ratio and Fan Pressure Ratio, that these engine parameters have a significant effect on the cruise fuel consumption of the design, as expected for the engine design parameters. Further to this study, it becomes possible by this approach to process in parallel the margin analysis for further figures of merit, and produce a higher level visualisation of the geometric mean confidence in upholding all margins across all FOMs.

Fig. 13. Percentage confidence in complying with assigned margins.

Managing Margins Under Uncertainties Surrogate Modelling

4

63

Summary and Conclusions

The intention of this article was to show how uncertainties can be quantified and propagated to provide possible variations of properties of interest and Figures of Merit. These variations then allow estimations of margins under uncertainties; or the placement of margins at the early stages of the design lifecycle. One limitation in the approach is that the input variables (design and random) were treated as independent. Further research work is underway to identify which variables are dependent and how to deal with their dependencies. For complex systems, the ability to determine whether the dependent behaviour is purely coincidental or has some, as yet unknown, causation is not an easy task. We also showed the processes needed to generate information for creating surrogate models. One question that often arises is “how many samples are needed to build a good enough surrogate model?” Such a question is not easy to answer because it depends on the complexity of the system; both in terms of its dimensionality and in terms of its emergent behaviours. The visualisation methods shown have helped to translate the statistical analyses into engineering information for decision-making. For a single FOM, the approach was illustrative; however, in real situations there are many FOMs and their interactions are also complex. One approach was the method for visualising higher dimensional design spaces using arrays of graphs – interactive use of this approach may be needed to understand the complexity of the information displayed.

References 1. Yannou, B., Yvars, P.-A., Hoyle, C., Chen, W.: Set-based design by simulation of usage scenario coverage. J. Eng. Des., 33 p. (2013). https://doi. org/10.1080/09544828.2013.780201.hal-00801604v2. https://hal.archives-ouvertes. fr/hal-00801604v2/document. Accessed 25 July 2019 2. Guenov, M.D., Nunez, M., Molina-Crist´ obal, A., Sripawadkul, V., Datta, V., Riaz, A.: Composition, management, and exploration of computational studies at early design stage. In: Vasile, M., Becerra, V.M. (eds.) Computational Intelligence in Aerospace Sciences, vol. 244. American Institute of Aeronautics and Astronautics, Reston (2014) 3. Guenov, M.D., Nunez, M., Molina-Crist´ obal, A., Datta, V., Riaz, A.: AIRCADIA – An Interactive tool for composition and exploration of aircraft computational studies at early design stage. In: Proceedings of the 29th Congress of the International Council of the Aeronautical Sciences (ICAS), St. Petersburg, Russia, 7–12 September 2014

Implementing Organizational Cybernetics for the Next Generation of Digital Business Models Alan Martin Redmond1(B) and Loic Chanvillard2(B) 1 Pôle SCS, Sophia Antipolis, France

[email protected] 2 Safe Cluster by Pegase & Risques, Antenne Alpes Maritimes, France

[email protected]

Abstract. ETSI identified that “future work will take into consideration heterogeneous networks using LTE, 5G fixed and WiFi technologies that will include developer friendly and standard APIs, standard based interface among multi-access hosts and an alignment with NFV architecture”. However, the term added value requires disruptive technology that can provide value from a customer perspective which leads to characterizing the value stream for the products service(s). The main synthesis of this paper is to investigate disruptive IoT technology opportunities and user needs for securing interoperable connections of the next generation of digital business models. The following objectives will be analysed and presented; (i) the customer objectives (identifying the system requirements and system design) for wireless communications; (ii) IoT System dynamics and its value chain; (iii) protocols, open API economy, and market analytics; (iv) electronic transactions within the finance sector; and (v) security. The outcome of this paper will inform the reader of the operational requirements assessments needed to provide Seamless Mobility through the management process of organizational cybernetics.

1 Introduction “Every system life cycle consists of multiple aspects, including the business aspect (business case), the budget aspect (funding), and the technical aspect (product)” [1]. This paper within the context of INCOSE “Vee model” reviews the stakeholders needs, system requirements and defines the logical architecture of generating digital business models. The secondary research identifies the current disruptive technologies that can lead to networks seamless mobility (infrastructure, market drivers and security). Whereas the methodology section highlights how information can be used by a system to control the development process through feedback mechanisms before detailing a cross-cutting technical method “mapping model” to define limitations and needed improvements. The modeling system provides support analysis, causal analysis, and scenario analysis that describes the relationships among the physical systems and that of a business model.

© Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 64–78, 2020. https://doi.org/10.1007/978-3-030-34843-4_6

Implementing Organizational Cybernetics for the Next Generation

65

2 Disruptive Technology 2.1 VNF – Virtualized Network Function and SDN – Software Defined Networks [2] referred to SDNs as the software that controls the entire network management and operations that of IoT network elements. It is based on virtualization and behaves to control the network in a centralized manner. The SDN controller is consider as the brain of the entire network while residing on multiple servers. Its function is to reduce the burden of network operators by avoiding configuration errors across the entire network and enable heterogeneous devices to connect seamlessly to networks. The SDN controller communicates with the control and management planes using the northbound interface. It can control the entire network as a single logical entity. The architecture of VNFs is based on having a network hypervisor however; the virtual layer in the form of the hypervisor is located on the device itself. Such hypervisors create virtual machines (VMs) on the physical hardware which is referred to as virtual infrastructure that can be accessed using an open standard Application Performance Interface (API). These open APIs are accessed through programming languages to create VNFs. Such devices can be controlled by SDN controllers and the architecture of VNF consists of; (a) physical hardware; (b) virtual hypervisor layer – bare metal hardware that manages CPU power, memory, and storage capacity; and (c) virtual machine. It has also been acknowledged that the advantages of VNF and SDN architectures relates to the general-purpose COTS based servers that can be used for Big Data handling and computation. The physical layer processing of the cellular mobile networks can be implemented in such COTS servers. In their opinion this will transform the entire telecommunication industry by dramatically reducing capital investment and energy consumption via cloud-based servers. 2.2 MEC – Multi-access Edge Computing for IT Services [3] identifies the abilities of MEC, based on providing IT services environment and cloud-computing at the edge of the mobile network. The network is in close proximity to the subscribers which reduces latency, ensures highly efficient network operation, service delivery, and offers an improved user experience. The overall concept is that the ETSI Industry Specification Group (ISG) will produce specifications that enable hosting of applications, including third party applications, in a multi-vendor MEC environment. ETSI have highlighted 5 user cases for MEC for which 3 specific cases have been identified in this paper to illustrate the added value of MEC with that of key technologies for end-applied-markets. In Fig. 3 Digital Business Model for a connected society; these 3 case studies become transparent i.e. autonomous car drivers, insurances, mobile pay users, banks … have operational and functional requirements leading to technology needs and locks in Cloud, cryptography and the need for computational data processing, protocols and sensors.

66

A. M. Redmond and L. Chanvillard Table 1. MEC use cases (adapted from [2])

Case study

Scenario

Solution

Assistance for intensive computation service

Current computation requires several wireless devices or sensors made to be as low cost as possible and remain operational for a long period of time. The challenge is that these wireless devices require further instruction or feedback based upon its feeds and because of the low cost, computational power is often neglected

Offloading the computational data processing to a MEC server, can improve the performance of the device with low processing power and improve battery performance

IoT Gateway service

IoT devices and sensors are constrained from the point of processor and memory. The connection requires real-time capabilities meaning grouping of devices and sensors is needed for efficient service

The MEC server supports a low latency aggregation point to manage the various protocols, distribution of messages and for the processing of analytics required by IoT devices and sensors

Connected Vehicles service

The use of technologies such as Dedicated Short-Range Communications (DSRC) for short distance and Long-Term Evolution (LTE) for long distances has increased the connected vehicles services. The intended advantages of increasing safety, efficiency, transportation by exchanging operational data is reliant on the communication of vehicles and road side sensors. The challenge is that such uses increases the volume of data and latency requirements

Storing and processing data centrally satisfies the requirements of some use cases but is unreliable and slow for all uses. By locating the MEC server at the roadside units can enhance the performance reliability of services for connected vehicles

[4] outlines the features of 4 key MEC Market drivers: (i) many use cases; IoT, vehicle, health, retail, augmented reality, accelerated video, and caching services; (ii) technical integration; low latency, proximity, virtualization, and QoE; (iii) industry collaboration; cloud, network and standards; and (iv) business transformation; new market, faster time to market and revenue generation. However; the ecosystem is deemed to be complex because of the use of Communication Service Providers (CPS), enterprises deploying private LTE networks, providers of edge platforms, and third-party application developers. The concept of CPSs relates to the notion that third parties could develop and create value from information using MEC. It is also accepted that there are interoperability issues due to the complexity of MEC and that 5G is dependent on such technology, as MEC Application Performance Interface.

Implementing Organizational Cybernetics for the Next Generation

67

2.3 IoT Authentication [5] identified that some manufactures have produced and sold IoT devices that do not include sufficient security features, thus resulting in serious economic harm. In particular for securing networks it is recommend that security measures for IoT applications should use context-aware authentication (CAA), also known as adaptive authentication where contextual information and machine-learning algorithms continuously evaluate risk of malice without requesting authentication from the user. For example; if the risk is high, then the subscriber (or hacker) would be requested for a multi-factor token to continue having access. The problem with IoT is that even if device passwords are secure, communication between devices can be hacked and of course IoT has many protocols, such as Bluetooth, Zigbee, Z-Wave, 6LoWPAN (Low power Wireless Personal Area Networks), Thread, Wi-Fi, cellular, NFC, SigFox, Neul (the Gaelic word meaning Cloud), and LoRaWAN. Manufactures will need to review their situation based on the protocol, available computing resources and strength of encryption possibly IPsec (Internet Protocol Security), and/or Transport Layer security (TLS)/Secure Socket layer (SSL). An alternative to encryption is Society of Automotive Engineers (SAE) J2735 Basic Safety Message (BSMs) which is a wireless communication for cars to avoid collisions.

3 Organizational Change In Systems Engineering principles terms such as Value-Stream Mapping (VSM) for software engineering is used to analyse requirements, use cases, change request or defect report through the “development process” [6] and “Information flow analysis” (an analysis of information flows in the development process) [7]. The following two sections will investigate control behaviour and requirement analysis within the context of organizational change. 3.1 Organizational Cybernetics “Cybernetics studies the flow of information through a system and how information is used by the system to control itself through feedback mechanisms [8]”. SEBoK has further credited cybernetics to been used as a set of founding principles for all of the significant system disciplines. Cybernetics is the science of control behavior and it can be decomposed into two basic mechanisms; (i) negative feedback – maintaining system state against a set objectives or levels; and (ii) positive feedback – forced growth or contraction to new levels. The process is associated with that of two views; a black box system view that focuses on the whole system were control is achieved by balancing inputs with outputs in order to reduce speed of responses; and a white box system view that concentrates on the system elements and their relationship. The concept is to embed control mechanisms in to such a structure in order to provide more responsive control and transfer risk to stability [9]. The next section will show the use of feedback loops and the recursion structure of organizational change for transferring needs into requirements.

68

A. M. Redmond and L. Chanvillard

3.2 Transformation of Needs into Requirements [10] identified that “Systems Science brings together research into all aspects of systems with the goal of identifying, exploring, and understanding patterns of complexity that cross disciplinary fields and areas of application”. Moreover, it forms the basis of theories applicable to all types of systems (e.g., in nature, society, and engineering) and in reference to organizational change it can help to provide a common language and intellectual base for System Engineering to create practical system concepts, principles, and patterns. Such tools enhance integrated systems approach (systems thinking) to solving complex problems by combining “science of systems” and “systems approach to science”. [11] recognized that the system approach is designed to examine the whole system, whole lifecycle, and whole stakeholder community, and that the purpose of the system must be achieved without causing any negative unintended consequences”. The following steps explain the process of Fig. 1 Organizational workflow for transforming needs in to requirements; starting from left and moving to right and progressing within an iterative and incursion manner based on constant loop backs to refine the system elements (loops and steps are numerated on the diagram); Step 1 – Exploratory research; This is the first component of data input for the Business or Mission Analysis Process. It comprises of identifying the stakeholders needs which involve exploring ideas and technologies. ISO/IEC/IEEE 15288 identifies it as “to define the stakeholder requirements for a system that can provide the capabilities needed by the users and other stakeholders in a defined environment.” Step 2 – the Business or Mission Analysis Process; The Business Analysis initiates the life cycle of the system of Interest (SOI - contains system elements, interconnections, and the environment in which they are placed) by defining the problem domain”. An output of the project planning process is the project constraints of the business analysis. And an output of the decision management process is the decision management strategy of the project planning process. “The purpose of the Business Analysis process is to define the business problem or opportunity and determine the potential solution”. Loop 1 - the Project Assessment & Control; Between Step 1 and Step 3 (Enterprise) is the Project Assessment & Control (loop). This technical management process “assesses if the plans are aligned and feasible; ensure the performance is according to plans and schedules, within projected budgets, to meet technical objectives”. At this stage the Project Assessment and Control process is also connected to Project planning with recommended techniques such as Agile Release Train – “a virtual organization (5 to 12 teams) that plans, commits, and executes together” [12] and Earned Value Analysis – an objective method to measure project performance in terms of scope, time and cost. Step 3 – Enterprise; The Enterprise step is composed of ConOps – which describes the organizations assumptions or series of operations of the business in using the system to be developed, Operational Requirements Document (ORD) - which defines the overall requirements for one system, how it interacts with other systems, and a systems performance goals, and requirement analysis” – which includes the OpsCon that is prepared at business level and summarizes business needs from an operational viewpoint. The process moves from this step to a key decision gate stage ‘concept’.

Implementing Organizational Cybernetics for the Next Generation

69

Step 4 – Concept; At the Concept stage the stakeholder’s needs will have been refined through the System Requirement Review (SRR) where the requirements are necessary to be feasible, complete and accurate. The proposed solutions should be validated to ensure they are viable; this stage is iterative and requires continuous feedback. Loop 2 – Risk Management; Between the decision gate of concept and step 5 (Business Management) is the Risk Management Loop. “The purpose of risk management is to identify, analyze, treat and monitor the risk continually”. Step 5 – Business Management; This main factors contributing to Business Management is; (i) interface control document – identifying the expected interactions of the system with systems external to the system (control) boundary; (ii) Systems Requirements Review; (iii) System Design review; (iv) Non-Functional Requirements and; (v) Cost Effective Capability – “Better Buying Power: Mandate for Restoring Affordability and Productivity in Defense spending” [13]. The Business Management process is connected to the Statement of Objectives (SOO - support the achievement of the contractual objectives). The SOO is influenced by the stakeholder’s requirements elicitation which is an output of the ConOps document and the techniques used such as; focus groups, interviews and the delphi method. The SOO is also linked to; Configuration Management – manages and controls system elements and configuration over the life cycle; Information Management – takes the project requests from configuration management and transforms them into strategies, reports, records and creates a repository; and Project Planning where it acts as an input to strategy documents. Business Management is also connected to Decision Management and Measurement. Loop 3 - the Project Assessment & Control; Between Step 5 and Step 6 development there is an iterative loop to assess if the plans are aligned and feasible; ensure the performance is according to plans and schedules, within projected budgets, to meet technical objectives. Step 6 – Development; The decision gate of Step 6 Development process requires: refine system requirements; create solution description; Build System; and Verify and Validate System. Step 7 – Business Operation & system; This process is connected to Integration process which involves the verification and validation actions, it is embedded within the Risk Management Process and also connected to both Configuration and Information management. Business Operation & system. Loop 4 – Measurement; The measurement process comprises of; cost effective analysis and affordability; trade space throughout the system life cycle; cost effective capability; measurement and feedback control system. Step 8 – System and Systems Elements; These are items that are placed. under formal control. System/Systems elements refer to requirements, constraints, operating scenarios, etc. Designers perform the design definition of each concerned system element and inversely SE must provide feedback to design engineers to improve knowledge and know-how. Consequently, system and system elements require; risk management; information management; configuration management; decision management; project assessment and control; and measurement prior to the System Requirements and Architect Definition Process.

Fig. 1. Organizational workflow for transforming needs in to requirements (based on the authors personal experience)

70 A. M. Redmond and L. Chanvillard

Implementing Organizational Cybernetics for the Next Generation

71

4 The Next Generation of Digital Business Models The Technical Process of a Systems Life Cycle as per ISO/IEC/IEEE 15288; identifies that the following phase after the Stakeholder Needs & Requirements Definition is System Requirements Definition process (“this process function is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user”). This topic was partially explored in the previous section through the step process. Business models are identified at the business requirements phase and further analyzed as part of the system analysis process. However, in developing architecture, description models are usually developed to define stakeholders’ concerns such as cost models and they should always be updated. Figure 2 Mapping IoT Business Model takes into consideration the 9 key components of a business model (as highlighted in bold); (a) key partners; (b) key activities; (c) key resources; (d) value propositions; (e) customer segments; (f) customer; (g) channels; (h) cost structure; and (i) revenue streams. The business model canvas in Fig. 2 is for obtaining the most efficient digital market streams and is explained within the context of knowledge obtained from ETSI (European Telecommunication Standards Institute) specifications and associated working groups. Figure 2 diagram includes 20 clusters nodes connected to the main 9 nodes of the business model. The cluster nodes are interchangeable and are compiled in reference to those identified from the Business Model Canvas Poster http://www.businessmodelalchemist. com/tools. Within the 20 cluster nodes is the key telecommunication requirement input components. • Node 1 Key Partners; is connected to node 2 Key Activities. Node 1 is dependent on; stakeholders association; software developers; public authorities; and equipment manufactures. • Node 2 Key Activities; is dependent on node 1 Key Partners and node 3 Key resources. Node 2 is comprised of; Software and IoT development; and marketing. • Node 3 Key Resources; is dependent on; planning tools; control algorithm; and orchestration management. • Node 4 Value Propositions; comprises of more efficient network environment; more efficient equipment; and consultancy services. • Node 5 Customer; is dependent on node 6 Channels which consists of both sales and products. Node 5 also requires the input of service support. • Node 7 Customer Segments; is initially dependent on customer equipment manufactures however it is also dependent on the node 8 Cost Structure which is based on new services and more complex equipment. Node 8 is financially dependent on node 9 Revenue Stream which requires performance improvements; security services; contracts; reduced TCO (Total Cost of Ownership), and increased elasticity. Node 9 Revenue Stream is also dependent on cost effective solutions such as mobile operators to reduce congestion using multi-RAT, this feed is connected to more efficient network equipment which loops back to node 4 Value Propositions. • Within the course of the mapping process of Fig. 2 four key input components were highlighted; Node 4 Value propositions relies on more efficient equipment which is

72

A. M. Redmond and L. Chanvillard

dependent on coverage overlapping various wireless networks (LTE, WiFi) – this service relates to heterogeneity radio network integration built using 5G networks as a cost-effective solution for mobile operators to reduce network congestion due to the explosion of growth traffic with mobile devices. The coverage overlapping various wireless networks is connected to transfer different services simultaneously by using multiple networks. [14] solution is to integrate the multi-RAT with SDN to make the multi-RAT network more manageable and adaptable. Their performance test results showed a significant reduction in response times when the multi-RAT network traffic is unbalanced, where the throughput (data packets – transmission of data) degradation of adapting the multi-RAT with SDN is 4.15% on average. The original requirement business models for phones is to have “one phone, one number, one bill”. For example; providing connecting wireless to wire line infrastructure i.e. delivering seamless connection across multiple location, multiple devices and multiple types of use. The vision for Fixed Mobile Convergence (FMC) is to enable network traffic to be transported seamlessly between different types of networks. And the three key enabling technologies for such a service are; • SIP (Session Initiation Protocol) – a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions (voice, chat, interactive games, and virtual reality) between users; • IMS (IP Multimedia Subsystem) – architecture standard that enables multiple realtime applications such as voice, video, games to run across a single network (designed originally by 3GPP); • UMA/CAN (Unlicensed Mobile Access) – allowing subscribers to switch between fixed and mobile networks i.e. provide access to Global System for Mobile Communications and General Packet Radio Service over unlicensed spectrum technologies, including Bluetooth and Wifi [15]. Ochaney highlighted the 4 features of FMC; (i) unified service of fixed and mobile – with one phone, one number and one bill; (ii) seamless roaming - between cellular, Wi-Fi, WiMAX and whatever wireless technology comes next; (iii) more reliable – mobile service with wider coverage at lower cost, closer integration between public and enterprise phone networks; and (iv) friendly user interfaces easier to make and manage calls (the user has a choice to select the type of network depending upon cost and convenience).

73

Fig. 2. Mapping IoT business model (created using Vensim PLE)

Implementing Organizational Cybernetics for the Next Generation

74

A. M. Redmond and L. Chanvillard Table 2. Global value chain (derived from Fig. 2)

Table 2 illustrates both Horizontal and Vertical value chains. The former representing coordination amongst devices facilitating the formation of market segment, not only to reach needed economies of scale but also to provide opportunities to add value to existing products (upgrading). The latter involves interactions with other devices of the chain to establish linkages, find synergies and exchange information in order to improve the performance of the chain as a whole.

5 Electronic Transactions Within the Finance Sector In 2014 the Regulation 910/2014 was published on electronic identification and trust services (commonly called eIDAS). Moreover, ETSI has also being securing websites access and payment services. In a progressive move the European Banking Authority and Open Banking Europe, have adapted ETSI standard 119 495 for trust infrastructures with new payments services. For cloud-based signatures ETSI specifications include; TS 119 431 part 1; TS 119 431 part 2 and TS 119 432 which support the creation of electronic signatures in the cloud and avoid the need for specialized user software and secure devices [16]. ETSI have also considered the development of algorithms variant for 5G as the usual radio interface algorithms in 3G and 4G use 128-bit key, 5G will focus on 256-bit keys that offer greater resistance to attacks. Furthermore, the future of secure encrypted information for bank accounts, identity information and military security will require new quantum safe cryptographic techniques. In 2017 ETSI Guide (EG) to Quantum Cryptography was published offering best practices advice to organizations such as banks [17]. Figure 3 illustrates the system thinking approach of this paper. It identifies all of the key features within a digital connected ecosystem comprising of mobile internet

Implementing Organizational Cybernetics for the Next Generation

75

infrastructure with edge computing and applications services as the distributed system technology. The process requires the creation and enhancement of the open API economy for Smart Cities connected to IoT. The Big Data analytics coupled with Data mining will identify markets. However, customer requirements are “King” and the developments of its portfolio will depend on cybersecurity and access to finance.

Fig. 3. Digital business model for a connected society

6 Conclusion The overall concept of this paper is to identify network challenges and potential solutions in order to create a secure integrated digital business model. The paper has presented facets of achieving such a physical architecture and through documents referenced to ETSI it has also provided guidance for physical elements such as performance, reliability, and security. The opening section of this paper presented the advantages of VNF and SDN architectures that can transform the entire telecommunication industry. The identified solution is to integrate the multi-RAT (physical connection) with SDN to make the multiRAT network more manageable and adaptable. Table 1 highlighted the main attributes of MEC (Edge Cloud) relevant to providing a digital business model for a connected society. Various protocols and standards for IoT Authentication which is also connected to electronic transactions within the finance sector were investigated. The output provided ensured that encrypted information for bank accounts, will require new quantum safe cryptographic techniques. The process model presented in Fig. 1 adapted the techniques

76

A. M. Redmond and L. Chanvillard

of organizational cybernetics to transform needs into requirements, these specific needs were reconfigured as the papers methodology to potentially develop Digital Business Model architecture. The mapping sequence of Fig. 2 listed the main features of a standard business model with that of the main technologies of wireless networks in order to create a value chain that incorporates mobile service with wider coverage at lower cost, and closer integration. Figure 3 summarized all of the key components of this papers findings in order to present a system architecture of the design process.

List of abbreviations API BS CAA ConOps COTS CPU CPS DSRC EG eIDAS ETSI FMC 3GPP HTTP IMS IoT IPsec ISG LoRaWAN LoWPAN LTE MEC multi-RAT NFC OpsCon ORD QoE SAE SEBoK SDN SIP SMTP SOI SOO

Application Performance Interface Basic Safety Message Context-Aware Authentication Concept Operations Commercial Off-The-Shelf Central Processing Unit Communication Service Providers Dedicated Short-Range Communications ETSI Guide Electronic Identification and Trust Services European Telecommunications Standard Institute Fixed Mobile Convergence 3rd Generation Partnership Project Hypertext Transfer Protocol IP Multimedia Subsystem Internet of Things Internet Protocol Security Industry Specification Group Long range wide area networks (media access control (MAC) protocol for wide area networks) Low power Wireless Personal Area Networks Long-Term Evolution Multi-access Edge Computing Multiple Radio Access Technology Near Field Communications System Operational Concept Operational Requirements Document Quality of Experience Society of Automotive Engineers Systems Engineering Body of Knowledge Software Defined Networks Session Initiation Protocol Simple Mail Transfer Protocol System of Interest Statement of Objectives

Implementing Organizational Cybernetics for the Next Generation

SRR SSL TCO TLS UMA/CAN VMs VNF VSM Wifi WiMAX

77

System Requirement Review Secure Socket layer Total Cost of Ownership Transport Layer security Unlicensed Mobile Access Virtual Machines Virtualized Network Function and Value-Stream Mapping Local Area Wireless Technology Worldwide Interoperability for Microwave Access

References 1. Haskins, C. (ed.) INCOSE: Systems Engineering Handbook, A Guide for System Life Cycle Processes and Activities, 4th edn., p. 26. Wiley, Hoboken (2015a) 2. Almustafa, K., Alenezi, M.: Cost analysis of SDN/NFV architecture over 4G infrastructure. In: The 8th International Conference on Emerging Ubiquitous Systems and Pervasive Networks, Science Direct (2017). Proc. Comput. Sci. 113, 130–137 3. European Telecommunication Standard Institute (ETSI): ETSI GS NGP 001 V1.1.1, Group Specification, Next Generation (NGP); Scenarios Definitions (2016) 4. Reznik, A.: An Update on our Mult-Access Edge Computing ISG, The Standard, News from ETSI – Issue 2 (2017) 5. Corser, G., Fink, G.A., Aledhari, M., Bielby, J., Nighot, R., Mandal, S., Aneja, N., Hrivnak, C., Cristache, L.: Internet of Things (IOT) security best practices. IEEE Internet Technology Policy Community White Paper (2017). Internetinitiative.ieee.org 6. Ali, N.B., Petersen, K., de França, B.B.N.: Evaluation of simulation-assisted value-stream mapping for software product development: two industrial cases. Inf. Softw. Technol. 68, 45 (2015) 7. Ali, N.B., Petersen, K., Schneider, K.: FLOW-assisted value-stream mapping in the early phases of large-scale software development. J. Syst. Softw. 111, 213–227 (2016) 8. SEBoK v. 1.9.1. https://www.sebokwiki.org/wiki/Cybernetics_(glossary). Accessed 16 Oct 2018 9. Ashby, W.R.: Chapter 11. Introduction to Cybernetics. Wiley, London (1956) 10. Haskins, C. (ed.) INCOSE: Systems Engineering Handbook, A Guide for System Life Cycle Processes and Activities, 4th edn., pp. 47–103. Wiley, Hoboken (2015b) 11. Senge, P.M.: The Fifth Discipline: The Art and Practice of the Learning Organization, 2nd edn. Doubleday Currency, New York (2006) 12. Singh, A.: Agile Release Train, digité How Work really Gets Done (2017). https://www.digite. com/blog/agile-release-train-art/ 13. Carter, A.: Better Buying Power: Mandate for Restoring Affordability and Productivity in Defense Spending, Memorandum for Defense Acquisition and Logistics Professionals, Under Secretary of Defense for Acquisition, Technology, and Logistics (2011) 14. Yang, S.N., Ho, S.W., Lin, Y.B., Gan, C.H.: A multi-RAT bandwidth aggregation mechanism with software-defined networking. J. Netw. Comput. Appl. https://doi.org/10.1016/j. jnca.(2015)11.003 15. Ochaney, M.: Fixed Mobile Convergence, LinkedIn SlideShare (2014). https://www. slideshare.net/MiteshOchaney/fixed-mobile-convergence-fmc-33401126

78

A. M. Redmond and L. Chanvillard

16. Pope, N.: New trust services helping in the fight against fraud, Standards for New types of “Trust Services” Provide an Important Toolset to Encounter Growing Internet Fraud, Enjoy The ETSI MAG, Internet Security: Dream or Reality? p. 10 (2019) 17. ETSI: The Standards People, A Connected World, Annual Report, April 2018, Security, Standards for Secure, Reliable Communications (2018)

Identifying Focal Points in IT Project Governance Using a Synthetic and Systems Thinking Approach Rani Yesudas, Mahmoud Efatmaneshnik(B) , and Keith Joiner University of New South Wales, Canberra, ACT, Australia [email protected], {M.Efatmaneshnik,k.joiner}@adfa.edu.au

Abstract. An effective project governance framework enables the project stakeholders to take the right actions to guide a project to success, and an efficient governance framework does so elegantly by a minimum number of actions necessary for the project success. Project governance provides direction in identifying the critical elements for project success and with techniques to measure its progress. There are several standards and tools available for the management of IT projects, yet there is an increase in the number of projects failing to attain the objective, deadline and budget. Complexities and uncertainties have increased in IT projects with the need to achieve innovation and the need for using emergent technologies. This situation makes it difficult for project proponents to assure project governance approaches for success. This article first analyses IT project life cycle activities and various reported IT project successes and failures. Then the systems thinking approach is applied to synthesise factors that can lead to failure at each stage of a project lifecycle. This information is then mapped to a complex system governance model to identify the order in which activities should be performed to obtain optimal results irrespective of the nature of the project.

1 Introductions In recent years, there has been an increase in ICT-related projects due to automation of complex manual processes; replacement of aging legacy systems with innovative systems that use advanced technologies; and conversion of decentralised and isolated systems to centralised and integrated systems for better management. These changes have increased the complexities and uncertainties in ICT projects whereby many organisations fail to meet objectives, keep the expenses within the allocated budget and meet the project deadlines. Conventional project management practices no longer suffice to provide project success when there are emergent properties that limit predictability. For large and complex projects, project governance should have a combination of Project Management (PM) and Systems Engineering (SE) approaches and principles to effectively manage complexities with through-life agility and referencing [1, 2]. Project governance benefits from the inclusion of modern complex SE techniques. The necessity is due to the fact that in such projects, schedule and budget can be quite sensitive to technical faults at the engineering level. Complexity in to context of IT projects can be due to a combination of factors including: technical and budget uncertainties, the © Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 79–92, 2020. https://doi.org/10.1007/978-3-030-34843-4_7

80

R. Yesudas et al.

sheer scale of the project (project size), lack of proficiency and experience with similar projects of mangers and technical staff, supply chain uncertainties and complications etc. A complex systems governance framework includes project, program and strategic management elements with efficiencies and measures to converge the organisational and project-level governance goals [3]. Complex SE techniques have benefitted from Systems Thinking and Integrated Product Team (IPT) approaches. System thinking takes into consideration the project environment and its effects, and IPT involves all key stakeholders and integrates different viewpoints into the whole system lifecycle [1, 4]. Based on the context, systems thinking allows for different levels of analysis and synthesis [5] and IPT allows for integration of business, technical, economic and other motivational aspects of the program [6]. However, it has also been noted that there are barriers for organisations to directly apply systems thinking into their governance process. It requires the project stakeholders to recondition their existing practices to obtain the right balance between responsive synthetic and rigorous systemic approaches [7]. These difficulties make many businesses continue using conservative practices though they are aware of the impact it has on the quality and timeliness of the deliverables. The ongoing issue of identifying the right approach to complex project governance requires an easy-to-use framework that can be applied to any project/program decisionmaking irrespective of the nature of use, environment and people involved. This paper discusses how the synthetic and systems thinking approach can be used to identify the key failure elements at each stage of the IT project life cycle. It then uses an existing governance model for complex systems, which is based on systems thinking, to identify the metasystem functions in that model that can limit such synthesised failures. This synthesised results are further analysed to generate an ordered list of activities that will provide optimal results at each stage of the project life-cycle irrespective of the nature of the project. This ordered list of activities can be used as a framework by organisations that wish to apply a systems thinking approach to its IT project governance.

2 Background and Literature Review In the project management body of knowledge (PMBOK), the PMI has divided project activities into the five phases: Project Conception and Initiation; Project Definition and Planning; Project Development and Deployment; Project Performance Monitoring and Control; and Project Closure [8]. The PMI has also described an analytical and structured approach in the way the phases are used for managing the project activities. These phases and approaches also apply to IT projects. However, due to the complexities and nature of the current ICT projects, a systematic reductionist approach may not always provide success to the project undertaken. The definition of project success has grown beyond the ‘Iron Triangle’ [9]. Various researchers and industry practitioners have created detailed taxonomies that define project success. Four important success criteria presented by Aaron et al. are: efficiency of the project, effect of the project on its end-users, the impact of the project in direct business and organisational success, and preparedness for the future [10]. Han et al. have further elaborated on this work by adding success factors that are determined by the lifecycle, and macro-micro dimensions of the project. They have detailed that for project

Identifying Focal Points in IT Project Governance

81

success to be complete both success factors and success criteria need to be considered and that both objective and subjective means need to be used to measure success [11]. With the increasing dimensions for project success, achieving project success became a challenge as many projects were reported to have failed in at least one of the required criteria. In 2014, the Standish Group, famous for reporting on IT industry projects, listed that only 16.2% of the surveyed 8,380 IT projects succeeded. The rest of the projects either got delayed, were over budget or got cancelled [12]. Focusing solely on the Iron Triangle also resulted in situations equivalent to the aphorism ‘the operation was successful, but the patient died’ [1]. Like industry, academic research also turned to meta-analysis of IT project successes and failures to try to isolate where best to focus improvement of resources [13–17]. Chow and Cao [17] conducted a meta-analysis of agile software projects and they identified 19 failures factors which they classified into ‘organizational’, ‘people’, ‘process’, and ‘technical’ categories. They also identified 36 success factors and for the classification of success factor they had ‘project’ as an additional category. Further they did a multiple regression analysis on data from 109 Agile projects and identified that ‘a correct delivery strategy’, ‘a proper practice of Agile software engineering techniques’, and ‘a high-caliber team’ are the three main success factors. The next set of factors that identified project success were a ‘good Agile project management process’, ‘an Agile-friendly team environment’, and ‘a strong customer involvement’ [17]. Gupta et al. [13] reviewed 111 articles and identified the top ten reasons of IT project failure as: ‘poor communication, incompetent project manager, inadequate organization support, inadequate task definitions, lack of knowledge, poor participation and hostile culture’. However, none of these studies identifies which areas in the project life-cycle and related activities needed attention to prevent the failures or a governance framework to help institutionalise this better decision-making. Currently, industry practitioners must apply various standards, process definitions, and tools to identify suitable mechanisms for governing their complex projects, such as those from the overlapping stables of project management, systems engineering, cybersecurity and so forth. The complexities that arise from the integration of multiple techniques also reduce the visibility of gaps and errors in the chosen process and decisions. It would be highly beneficial for the management team to have a less complicated framework that provides more fundamental considerations for decision-making in project governance. Too and Weaver [18] proposed a conceptual framework for project governance based on five main themes: ‘governing relationships’, ‘governing change’, ‘governing the organization’s people’, ‘financial governance’, and ‘viability and sustainability’. Their proposed framework displays a link between governance system, management system and project delivery system. The four main elements they identified for improving performance of projects are ‘portfolio management’, ‘project sponsorship’, ‘Project Management Office’, and ‘projects and program support’. They also insist on the importance of identifying and providing clarity for the roles, responsibilities and accountabilities for these elements [18]. This framework provides information on the necessary factors; however, it does not provide a list of considerations that will guide activities at each stage of a project lifecycle. The research reported in this article aims to prioritise the focus of such considerations, and ‘focal points’ for decision-making at each stage of the project life cycle irrespective

82

R. Yesudas et al.

of the nature of the project. For this purpose, a complex governance model is required. After analysing the few generic conceptual governance models that exist, the Complex Systems Governance (CSG) model developed by Keating and Bradley [19] was found suitable for the analysis in this article. Table 1 represents the nine metasystem functions of CSG. It operates at a conceptual level beyond the systems it has to integrate. The numbering of these functions are chosen to show the relevance of them for example that M5* and M5’ are necessary for M5 and are its subfunctions. Table 1. Nine metasystem functions of CSG [19] • M5 - Policy & Identity - providing overall direction by maintaining balance between current and future focus • M5* - Relevant Context – identifying context of the system and factors (positive and negative) that affect the implementation • M5’ - Strategic Monitoring - identifying elements to strategically monitor the system and in establishing their measuring mechanisms • M4 - System Development - identifying system development strategies and techniques and in analysing future capabilities and design alternatives • M4* - Learning and Transformation – Generating system transformation plans based on the identified errors, emergence and modifications requirement • M4’ - Environmental Scanning - Identifying external factors that will affect the performance of the current and future system • M3 - System Operations - Identifying and implementing mechanisms for maintaining control over operation performance • M3* - Operational Performances - Identifying variance to the expected behaviour in the system that will require treatment and system level response • M2 - Information & Communication - Identifying mechanisms to establish and maintain consistent and transparent information exchange between project stakeholders

Keating et al. propose a pathological identification approach for the use of the CSG model. This approach enables better governance by accretion of specific functions that will correct any identified pathologies [20, 21]. The CSG model was developed in part from cybernetics and therefore has a comprehensive coverage of aspects required by an IT project.

3 Research Method The research reported in this article used a analytic-synthetic approach which is a deductive learning approach from the premises [20]. Applying synthetic thinking to understand project governance requirements provides the benefits of ‘world views’ and ‘mental models’ which cannot be obtained solely from analysis [2]. This study is restricted to desk/secondary research, and hence a meta-analysis of reported IT project lifecycles, success factors and failures was conducted, and the sources were mainly limited to articles published in academic journals and conferences. Thus is takes a quantitative approach to analyzing those data. This information was used to synthesise the failure

Identifying Focal Points in IT Project Governance

83

possibilities at each stage of the project lifecycle. The synthesised failure list was further mapped with the 9 metasystem functions of the CSG model. The mapping results were ordered and ranked to identify which metasystem functions had priority in each stage of project life-cycle.

4 Research Findings Sources [13–17] were systematically analysed to initially identify factors and work functions that are mandatory at each stage of the project life-cycle for its effective functioning. Secondly, the reported failures and success factors for various IT projects were analysed to create a common list of factors that affected most of the projects analysed. Finally, all this information was consolidated to generate a list of failures that affect each stage of a project lifecycle. This synthesised information is then mapped with the 9 metasystem functions of CSG. This information is then used to further classify the metasystem functions for identifying the resource allocation and priority of activities at each stage of project life-cycle. This analysis led to a proposed project governance framework. The list of activities identified applies to any project irrespective of the domain or it’s environment. Based on the nature of the project, the intricacies and complexities of activities that need to be undertaken at each stage will vary. The list reported in this article reduces the complications often faced by most practitioners on where and how to start the planning of an innovative and complex project. These functions are further classified into 4 Tiers based on the score received. The definition of the Tier levels is detailed in Table 4. The metasystem functions are then ordered in a descending manner based on the values each function received. Figure 1 illustrates a Pareto chart representation of the scores received for ‘Stage 1 - Project Conception and Initiation’ (Tables 2 and 3). Table 2. Synthesized list of project failures for each stage of project lifecycle Stages of an IT Project Life Cycle Project Conception and Initiation

1. Failure to identify and manage change required 2. Size and complexity of project 3. Absence of an influential champion and Change agent 4. Lack of Executive support and project sponsorship 5. Negativity in Company and Organisation Culture and Management 6. Failure to identify legal, political and geographical implications

Project Definition and Planning

7. Lack of Project Manager with skills to run the project 8. Failure to manage business case, and to estimate and manage budget and time frame for the project 9. Failure to manage Requirements and scope 10. Failure to identity project and risk management 11. Inability to assign accountability for a work function to a project member (continued)

84

R. Yesudas et al.

Table 2. (continued) Stages of an IT Project Life Cycle Project 12. Lack of skills and involvement in team members Development 13. Unable to identify suitable external contractors and and Deployment manage them 14. Lack of involvement of end-users for system design and development 15. Skilled Staff leaving the project 16. Technological risks – over focus and under focus 17. Lack of focus on testing 18. Scope creep and changes during the development phase 19. Failure to identify and include non-functional requirements Project Performance Monitoring and Control

20. Lack of skills to monitor and maintain the system 21. Lack of system flexibility to update the system to changing environment and technology 22. Lack of skills in team members to update a live system based on change request from end user 23. User resistance to the change in system 24. Lack of end-user training 25. Technology being outdated after deployment

Project Closure

26. Gathering lessons learnt 27. Difficulty in bringing a closure (freeze significant changes to the project scope) and hand-over

28. Lack of Effective and Efficient Communication

Table 3. Mapping the synthesized failure list to the 9 Metasystem functions of CSG CSG functions ID of the Synthesised Project Failure

Count

M5

1, 2, 3, 4, 5, 6, 7, 9, 25, 27, 28

11

M5*

1, 2, 6, 7, 9, 10, 11, 13, 18, 19, 21, 22, 23, 25, 27, 28

16

M5’

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 14, 17, 18, 19, 20, 21, 22, 23, 24, 25, 25 26, 27, 28

M4

2, 7, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19, 21, 22, 28

15

M4*

2, 6, 7, 9, 12, 15, 16, 21, 23, 24, 26, 27, 28

13

M4’

2, 4, 5, 6, 12, 15, 16, 18, 19, 24, 28

11

M3

2, 10, 12, 13, 14, 15, 16, 17, 18, 20, 26, 28

12

M3*

2, 17, 18, 20, 23, 28

6

M2

All the listed failures

28

Identifying Focal Points in IT Project Governance

85

Table 4. Classification applied to the CSG metasystem functions activities Tiers

Percentage

Description

Tier 1 100–71%

• Activities of metasystem functions identified in Tier 1 should be the initial set of activities carried out at each stage of the project life cycle • There is less flexibility in the order in which the activities can be carried out • 50% of resources at each stage of the project life cycle should be dedicated to the tasks of metasystem functions identified in Tier 3

Tier 2 70–41%

• Activities of metasystem functions identified in Tier 2 should be given secondary focus. The findings from Tier 1 activities will influence the direction of these activities • T here is a medium level of flexibility in the order in which the activities can be carried out • 30% of resources at each stage of the project life cycle should be dedicated to the tasks of metasystem functions identified in Tier 2

Tier 3 40–1%

• Activities of metasystem functions identified in Tier 3 should be the last set of activities carried out at each stage of the project life cycle. The findings in Tier 1 and Tier 2 will influence the direction of these activities • There is a higher level of flexibility in the order in which the activities can be carried out • 15% of resources at each stage of the project life cycle should be dedicated to the tasks of metasystem functions identified in Tier 3

Tier 4 Miscellaneous • 5% of resources is allocated to activities in this Tier • This Tier includes metasystem functions that do not appear the above three Tiers (that obtained a value of zero as part of the analysis) • Their Tier also includes activities related to verification of continuity from one stage of the project life cycle to the next stage • If the activities related to a Tier is completed earlier than the allocated time, it can be transferred to the tasks in the next Tier • If no metasystem function is identified for a tier, the effort allocated for that tier can be allocated to the remaining Tiers. Allocation can be based on 60% for the higher Tier and 40% for the lower Tier

The next section lists the metasystem functions and the related activities that are relevant to each stage of project lifecycle and the Tier in which they appear. The management team that will be involved in this process are classified as: top management team (TMT – mostly involved in activities related to corporate governance), middle management team (MMT – mostly involved in activities related to program governance) and project management team (PMT – mostly involved in activities related to project governance) (Tables 5, 6, 7, 8 and 9).

86

R. Yesudas et al.

Fig. 1. Metasystem function scores for Stage 1 of project lifecycle Table 5. Tiered list of activities for the ‘Project Conception and Initiation’ stage Stage 1 - Project Conception and Initiation Tier 1 - M2; M5; M5’ • First the TMT should gather information about the necessity of the project and its added benefits to the organisation and its business • The MMT should use the above information to set the context for the project and how to scope it with the available resources. If there are gaps identified, this information should be discussed with the TMT to choose a viable option • The MMT along with the PMT should then identify the elements that are required for strategic monitoring of the project. MMT should focus on identifying the elements and PMT should focus identifying ways to measure the identified elements Tier 2 - M4’; M5* • The PMT should identity environmental elements which should be monitored throughout the project life cycle and confirm it with MMT. • The PMT should use the information collected from the above activities to finalise the context and scope of the project. The output of this activity will become the main foundation for the project. The information documented from this activity should be approved by MMT and TMT to step to the next level Tier 3 - M4*; M4; M3; M3* • The PMT should then scan for previous project experiences to identify a development and deployment strategy that is most beneficial for project • PMT should conduct a SWOT analysis of the preferred technologies and architectures along with their alternatives to identify feasibility of the proposed solution. This information should be finalised with the MMT • PMT should then identify the operations that need to be monitored. This should be followed by identification of mechanism for monitoring the performance of identified operational elements (continued)

Identifying Focal Points in IT Project Governance

87

Table 5. (continued) Stage 1 - Project Conception and Initiation Tier 4 • The activities in Tiers 1–3 should enable in creating the blue print for the project. This information should be discussed among TMT, MMT and PMT to be finalised and approved. In this tier, using the finalised information, the project charter should be generated. After this point, most project decisions will be mostly made by PMT

Table 6. Tiered list of activities for the ‘Project Definition and Planning’ stage Stage 2 - Project Definition and Planning Tier 1 - M2; M5’, M5* • First the PMT should generate a detailed requirement specification which should then help in the generation of detailed design specification and Project test plan. The PMT should involve the Project Lead (PL), Test Lead (TL) and Technical Writer (TW) to create a detailed set of specifications that can be referred throughout the project development • The PMT should then engage the Quality Assurance Team (QAT) to use the artifacts generated in above activity and stage 1 activities to create a list of elements that need to be monitored for strategic operations • Then PMT should identify if the design specifications, test plan and strategic operations monitoring plan confirms with the system context that is defined in the project scope Tier 2 - M4 • The PMT along with the Project lead should identify the team members who will work on development and testing of the team. They should develop a feasible timeline and work breakdown structure and identify ways to measure progress. The Project Lead should take care to maintain a healthy work balance for all members involved. They should train the project members to efficiently perform their task Tier 3 - M5, M4*, M3 • The PMT should verify and confirm that design specification generated are covered by the policy and identity statements generated in the Stage 1. Modifications required should be escalated to MMT. MMT should discuss with TMT and update the policy documents to reflect the necessary changes • The PMT should confirm that the development strategy chosen is the most suitable one based on the knowledge documents that exist in the organisations • The PMT should generate an operation plan based on the specification generated Tier 4 - M4’, M3* • The PMT should generate a list of environmental elements which will be monitored as the system development progresses • The PMT should generate a list of operational elements which will be monitored

88

R. Yesudas et al.

Table 7. Tiered list of activities for the ‘Project Development and Deployment’ stage Stage 3 - Project Development and Deployment Tier 1 - M2; M4, M3 • PL should use the information gathered from Stage 3 to guide and educate the team members on how the project should be developed and deployed • The system developers and testers should work on the system development and testing as per the system design and test plan. Any issues noted should be raised to the PL. In this stage along with ICT component developed, deliverables should include system and test reports. The PL and TL should regularly report to the PMT about the progress of the project and deviations noted in expected behaviour. The ongoing test reports should be used to identity the deviations in project behaviour. PMT will have to identify and approve measures to rectify the deviations. This activity should be cyclically be performed until the project progresses to a deployment stage • The PL should check the earlier generated operation plan to ensure that the planned system operations now align with the operations of the developed the system. Any deviations noted should be escalated to the QAT and PMT. QAT should identify if deviations are acceptable or if remediation measures are required. PMT should act upon the suggestions of QAT and direct the PL on the actions to be taken Tier 2 - M5’, M4’ • PL should verify that the strategic monitoring metrics set by the QAT is met and the system meets the required quality. If elements that were not listed earlier are identified it should be escalated with the QAT for making modifications to the existing list. Then the verifications should again be performed to the updated list • PL should verify the system environment to identify for new developments. If any emergence is identified, they should be discussed with the PMT for updating the existing list. Then the verifications should again be performed to the updated list Tier 3 - M5*, M4*, M3* • The PMT should verify the developed and deployable system with respect to the system context that was updated in Stage 2. Any deviations noticed should be reported and discussed with MMT. If MMT recommends updates to the system, that information should be transferred to the PL to be applied to the system. PMT should verify and confirm any further updates made to the system • The PMT should update the knowledge documents based on the experience of the current project’s processes. The issues faced and how they were overcome should be documented • PL should generate monitoring metrics for the list of operational elements that were identified in Stage 2. The PMT should identify the System Operations Team (SOT) who will perform all the related activities Tier 4 - M5 • The PMT should check the policy and identity documents to identify, if further modifications are required. The modifications required should be escalated to MMT. MMT should discuss with TMT and update the policy documents to reflect the necessary changes • At this stage, the system is ready for deployment and all the management teams should be familiar with the system that is developed and deployed

Identifying Focal Points in IT Project Governance

89

Table 8. Tiered list of activities for the ‘Project Performance Monitoring and Control’ stage Stage 4 - Project Performance Monitoring and Control Tier 1 - M2; M5’ • The PMT should train the SOT to perform the monitoring and system control. SOT should be provided with a template to report on anomalies identified • The PMT should verify the elements in the strategic monitoring plant to ensure that it also includes elements related to operational efficiency of the system. If elements have been noted as missing, the QAT should be involved to identify the actions required. Any updates to the strategic monitoring plan also require a system scan with the updated plan Tier 2 - M5*, M4* • The SOT should perform confirm that the monitored system performance matches with the documented system context. Any deviations noted should be escalated to the PMT to identify remedial measures • PMT should gather in the information provided by SOT and other Project team members to generate and update the knowledge articles maintained by the organisation Tier 3 - M4, M3*, M5, M4’, M3 • Any updates to the system that is noted at the operational stage is noted by SOT and escalated to PMT. PMT directs the PL on the actions to be taken to modify the system • PL should update the list of operational elements with the newly identified items and their monitoring strategies should also be devised. SOT should perform the system scan with the updated list • The PMT should check if updates are required in the policy and identity documents for modifications made in the system • The SOT should inspect the system’s operational environment to identify for new developments. If any emergence is identified, they should be discussed with the PMT for updating the existing list. Then the verifications should again be performed with the updated list • SOT should identify if new elements need to be added to the operational plan as the system is monitored. If new elements identified, they should be discussed with the PMT for updating the existing list. Then the verifications should again be performed with the updated list Tier 4 At this stage all the management teams should be familiar with the system functioning and performance. All management teams should have regular review meeting to identify issues and discuss relevant matter

90

R. Yesudas et al. Table 9. Tiered list of activities for the ‘Project Closure’ stage

Stage 5 - Project Closure Tier 1 - M2, M5’, M4* • PMT should discuss with MMT about the need to close the project as requirements become almost static • PMT should update the MMT with strategic performance of the system to identify future plans • PMT should report on the lessons learnt from managing the project Tier 2 - M5, M5*, M3 • PMT should update MMT with the policy and identity modifications that were required at each stage of the project lifecycle • PMT should update MMT with the changes made to the system context at each stage of the project lifecycle • PMT should update MMT with the operational report of the system and the modifications that were made on the system to improve its operations Tier 3 - M4, M4’, M3* • PMT should update MMT with the efficiency of the development strategy chosen and scope for future improvements in the system • PMT should provide MMT with a report on the effect of the environment and how the monitoring strategies applied helped in avoiding problems in the system • PMT should update MMT with the efficiency of the operational monitoring strategies chosen and scope for future improvement Tier 4 • Based on the information provided by PMT, MMT should create a high-level report on the project and processes involved and discuss with TMT • MMT should bring the project a closure and PMT should store all the related documentations for future use

Table 10. Tier 1 list for all stages of project lifecycle Tier 1 Metasystem Functions for all Project Stages Project Conception and Initiation

M2, M5, M5’

Project Definition and Planning

M2, M5’, M5*

Project Development and Deployment

M2, M4, M3

Project Performance Monitoring and Control M2, M5’ Project Closure

M2, M5’, M4*

Intersection of All Project Stages

M2

Identifying Focal Points in IT Project Governance

91

5 Discussion and Conclusion Better governance of complex projects is often recommended to reduce the chances of failure however development and maintenance of governance functions is costly. For this reason, this paper sought to prioritize those governance functions for different project life cycle stages as a tool to contain and reduce the costs associated with development and maintenance of governance. The goal here is first to make governance more efficient or focused so as to reduce its associated costs, but second to increase the effectiveness of governance practices by focusing the resources on the most critical functions. This article reported on the required list of activities that need to be performed at each stage of the project life cycle to reduce the instances of projects facing the performance issues that are often reported in current ICT projects. Table 10 lists the top priority (Tier 1) metasystem functions that affect the project success. Rather unsurprisingly the Information and Communications (M2) metasystem function exists in the Tier 1 for all stages of the Project Life Cycle. This confirms that communication plays a quintessentially important role in the success of ICT projects. As such an effective strategy for communication is required for each stage of a project life, as clearly illustrated in the top priority governance framework functions in Table 10 for each project phase.

References 1. Locatelli, G., Mancini, M., Romano, E.: Systems engineering to improve the governance in complex project environments. Int. J. Proj. Manag. 32(8), 1395–1410 (2014) 2. Pourdehnad, J.: Synthetic (integrative) project management: an idea whose time has come. Bus. Strat. Ser. 8(6), 426–434 (2007) 3. Muller, R.: Project Governance. Routledge, New York (2017) 4. Pyster, A., Olwell, D.H., Hutchison, N., Enck, S., Anthony Jr., J.F., Henry, D.: Guide to the systems engineering body of knowledge (SEBoK) v. 1.0. 1. Guide to the Systems Engineering Body of Knowledge (SEBoK) (2012) 5. Kapsali, M.: Systems thinking in innovation project management: a match that works. Int. J. Proj. Manag. 29(4), 396–407 (2011) 6. Kossiakoff, A., Sweet, W.N., Seymour, S.J., Biemer, S.M.: Systems Engineering: Principles and Practice, 2nd edn. Wiley Online Library (2011) 7. Beasley, R.: 4.3. 1 the barriers to systems thinking. In: INCOSE International Symposium, vol. 22, no. 1, pp. 517–531. Wiley Online Library (2012) 8. PMI: A guide to the project management body of knowledge (PMBOK guide). Project Management Institute (2011) 9. Ogunlana, S.O.: Beyond the ‘iron triangle’: Stakeholder perception of key performance indicators (KPIs) for large-scale public sector development projects. Int. J. Proj. Manag. 28(3), 228–236 (2010) 10. Shenhar, A.J., Dvir, D., Levy, O., Maltz, A.C.: Project success: a multidimensional strategic concept. Long Range Plan. 34(6), 699–725 (2001) 11. Han, W.S., Yusof, A.M., Ismail, S., Aun, N.C.: Reviewing the notions of construction project success. Int. J. Bus. Manag. 7(1), 90 (2012)

92

R. Yesudas et al.

12. Standish Group: CHAOS Report: 21st Anniversary Edition (2014). https://www. standishgroup.com/sample_research_files/CHAOSReport2014.pdf 13. Gupta, S.K., Gunasekaran, A., Antony, J., Gupta, S., Bag, S., Roubaud, D.: Systematic literature review of project failures: current trends and scope for future research. Comput. Ind. Eng. 127, 274–285 (2019) 14. Dwivedi, Y.K., et al.: IS/IT project failures: a review of the extant literature for deriving a taxonomy of failure factors. In: International Working Conference on Transfer and Diffusion of IT, pp. 73–88. Springer (2013) 15. Antony, J., Gupta, S.: Top ten reasons for process improvement project failures. Int. J. Lean Six Sigma 10(1), 367–374 (2019) 16. Taherdoost, H., Keshavarzsaleh, A.: A theoretical review on IT project success/failure factors and evaluating the associated risks (2018) 17. Chow, T., Cao, D.-B.: A survey study of critical success factors in agile software projects. J. Syst. Softw. 81(6), 961–971 (2008) 18. Too, E.G., Weaver, P.: The management of project management: a conceptual framework for project governance. Int. J. Proj. Manag. 32(8), 1382–1394 (2014) 19. Keating, C.B., Bradley, J.M.: Complex system governance reference model. Int. J. Syst. Syst. Eng. 6(1–2), 33–52 (2015) 20. Cellucci, C.: The analytic-synthetic method. In: Rethinking Logic: Logic in Relation to Mathematics, Evolution, and Method, pp. 75–94. Springer (2013)

MAESTRIA: A New Tool to Support Collaborative Building and Sharing of an Integration, Verification, Validation, and Qualification Strategy Patrick Esteve1(B) , Benoit Langlois1 , Lyes Chabani1 , Willy Platzer1 , and Jacky Mouchoux2 1 Thales Global Services, 19-21 Avenue Morane Saulnier, 78140 Velizy-Villacoublay, France

{patrick.esteve,benoit.langlois,lyes.chabani, willy.platzer}@thalesgroup.com 2 Thales LAS FRance, 2 Avenue Gay Lussac, 78995 Elancourt, France [email protected]

Abstract. A recurring issue in bids and projects is the definition of an optimized integration, verification, validation, and qualification (IVVQ) strategy which can be easily communicated and shared between all the stakeholders. No existing tool has been identified so far in order to ensure continuity and consistency of the data engineered from the Product Breakdown Structure (PBS) up to the integration and test sequence and schedule of a solution (PERT diagram). After a de-risking phase, the tool MAESTRIA has been developed under Eclipse, based on a specific meta-model and implementing the major steps of this value chain. Subsequently, the graphical representation of the IVVQ strategy, once it is defined, can efficiently be exploited for visual management.

1 Introduction Thales is a French company with the technological expertise and decades of experience in serving 5 very demanding markets: Defense and Security, Digital Identity and Security, Aerospace, Space and Ground Transportation. Its major shareholders are the French state (27.0%) and Dassault Aviation (25.9%). With 80,000 employees in 68 countries, Thales is a global company. More than the half of its revenue comes from its international subsidiaries. It’s the 10th largest defense contractor in the world and a major actor in all the markets it’s involved. Thales provides complex solutions like defense systems or state, city and critical infrastructure protection systems. It built all telecom constellations operating today and has supplied 50% of the International Space Station. It also equipped 160 Air Traffic Management control centers in the world and represents almost 25% of the total value of the Rafale combat aircraft. Engineering includes all technical activities related to bids, products and projects throughout the life cycle of a product line or a solution. It faces many challenges to bring innovative solutions and creating value for its customers in increasing conditions of competitiveness. © Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 93–102, 2020. https://doi.org/10.1007/978-3-030-34843-4_8

94

P. Esteve et al.

More than 32 000 engineers of 111 domains are involved in the delivery of Thales solutions. Thales also has more than 100 development centers around the world to ensure collaboration and agility between teams or with customers. Thales Corporate Engineering (TCE) is in charge of the Group engineering strategy. It delivers standard Engineering Environments (E2) and defines the Engineering Management System (EMS) which describes: • “What to do” through the reference system Chorus 2.0 which includes the “Design, Develop, and Qualify (DDQ)” process and its related decision reviews and lifecycles, documents, and roles. The DDQ process addresses the system, software, and hardware engineering activities. • “How to do”, expressed in an additional portfolio of engineering practices (a.k.a. eTUP) making the link between the activities in the process and the tools in the Engineering Environment (E2) which support these activities. A set of 13 engineering communities completes the EMS and enables knowledge sharing. Besides the EMS and the multidisciplinary engineering workbench Orchestra, the E2 also encompass the infrastructure (networks, cloud…) and a set of services for the tailoring, deployment, tool support, and maintenance of the E2 and the assessment of the engineering maturity of the entities. The Thales engineering governance is based on business line (BL) or country axis. Each organization (BL or country) defines and manages its engineering strategy and performance plan according to the Group strategy. They tailor the EMS according to their specific constraints and needs. Integration, verification, validation [1] and Qualification (IVVQ) activities are part of the DDQ process: • • • •

Integration builds the product, Verification determines that the “product is built right”, Validation determines that the “right product is built”, Qualification establishes that the product can be reproduced, deployed, utilized, and supported.

They are placed under the responsibility of an IVVQ Manager. The IVVQ process area is covered by 23 specific engineering practices in the eTUP portfolio. The IVVQ job family has about 6000 people. The IVVQ engineering community counts 900 members from more than 70 sites around the world. It hosts a Network of Coaches (46 coaches to date) from the 7 Global Business Units of the Group. The skilled members of this network can share their experience and provide bids, projects and product lines with expertise and advice, based on a catalog of services.

2 The Genesis of MAESTRIA The IVVQ strategy is part of the development strategy of the product or solution. As such, it contributes to “orient” the architecture and development during the bid and the project phases of the product or solution development.

MAESTRIA: A New Tool to Support Collaborative Building

95

Taking into account the Voice of Customer and the Voice of Business, the IVVQ strategy turns out to be a key driver for pulling the value to the customer and the other stakeholders of the product or solution. The IVVQ strategy must not only enable to ensure the conformity of the product or solution with the customer requirements, but also to incrementally deliver the expected value on time to the stakeholders. The IVVQ strategy has to acknowledge the trade-offs between needs, costs, schedules and risks. The IVVQ strategy focuses on mitigating risks and detecting and eliminating errors and defects as early in the lifecycle as possible. In addition, it should ensure that subsystems and components are properly tested and characterized and have achieved adequate levels of performance and integrity before being brought into the system-level integration and test environment. By the Solution Engineering Manager’s delegation, the elaboration of the IVVQ strategy is part of the mission of the IVVQ Manager, within constraints provided by many roles: the customer, the Project Manager, the Architect, the Project Design Authority, the Production Manager, the suppliers of the solution elements and those of the IVVQ enabling elements (e.g., the test benches, tools, simulators, or data). Consequently, building an IVVQ strategy is quite complex and may make use of a majority of IVVQ practices, as shown in the figure below (Fig. 1).

Fig. 1. How to build an IVVQ strategy (from the Thales IVVQ Handbook)

96

P. Esteve et al.

It requires the collaboration of all the roles quoted above. A high level IVVQ strategy must be done as early as the bid phase, within limited time and budget, gathering inputs from various sources and heterogeneous media. The IVVQ strategy is refined, detailed and optimized at the project start in order to establish the IVVQ plan. As a consequence, it must be global, robust, explainable, transferable, and adaptive. These issues led to formalize a basic use case for MAESTRIA, the tool to support this tricky practice. The basic use case of MAESTRIA is the following: “Quickly building a system integration, test, and acceptance high level strategy and schedule shared in a co-engineering way during the bid phase or at the project start”.

3 The Rationale of MAESTRIA The approach consists in a tooled standard for building and sharing the IVVQ strategy of a solution. It aims to: • Optimize the assembly and test [2] activities until acceptance, • Prepare the test strategy in production, for a whole life cycle optimization. The proposed method makes it possible to display: • The different elements of the solution, • The required assembly and test operations and milestones, • The necessary environments (for example: mechanical or thermal stress, harbor or sea trials…), • The associated enabling systems (e.g., benches and tools), • The associated input or output data sets. The need in a standardized graphical representation of the IVVQ strategy has been satisfied since years all over the Group entities by using tools such as PowerPoint or Visio. Nevertheless, such tools prove to be limited in terms of collaboration and data exchange, forcing the IVVQ Manager to manually process and exchange redundant information, apart from his Engineering Environment (Fig. 2). This standard aims to support the IVVQ Manager in gathering relevant contributions of the roles involved in the definition of the assembly and test strategy; solution architect, test system architect, discipline engineering managers, acquisition requesting party, also taking into account the constraints of the industrial manager. This graphic standard is simple, intuitive and adaptable. It enables collaborative sharing between the different development and industrialization roles, in a spirit of co-engineering, during the Orient activity (bid phase and at project start).

MAESTRIA: A New Tool to Support Collaborative Building

97

Fig. 2. IVVQ strategy: co-engineering

Moreover, this standard enables to share with the Project Manager as well as the Customer. This approach enables the optimization of test activities in terms of effort and schedule. The link between test strategy and scheduling makes it possible to add to this graphic standard the temporal data useful for the optimization of the schedule, and to consolidate the incremental deliveries according to the right need (Fig. 3).

Fig. 3. MAESTRIA Tool Set

98

P. Esteve et al.

It favors collective intelligence by gathering the actors around a standard understandable by all. The graphic standard as well as the tool chain, relies on a software solution and compatible with any standard workstation.

4 Tool Chain for IVVQ Strategy Building The tool chain for IVVQ strategy building is made of three tools: • The PBS editor (Thales template), • MAESTRIA to edit IVV trees, • The Project Management (PM) Tool for scheduling. Each tool provides a set of capabilities as depicted below: • The PBS editor is an Excel-like editor which respects the Chorus 2.0 PBS template. • MAESTRIA is an Eclipse workbench built with Kitalpha [3], an open-source Eclipse project. • The PM tool is a project management tool able to import and export data which conform to the Microsoft Office Project 2007 XML Data Interchange Schema [4] (Fig. 4).

Fig. 4. The IVVQ strategy tooled process

The tooled process is the following: • The PBS (tree of PBS components) is initialized with the PBS editor. • Once imported in a new MAESTRIA project, the PBS tree is enriched with various elements: possible additional components, tests, milestones, assets, activities, activity groups for decomposition of IVV tree in sub-levels. For facility of use, MAESTRIA

MAESTRIA: A New Tool to Support Collaborative Building

• • • •

99

is a graphical tool. It is recommended to start defining the best assembly tree pattern, then to build the complete ideal IVV tree based on the release plan and including the test means, then finish with the IVV PERT diagram, considering resources and other constraints at different levels of granularity (from a high level project strategy to a detailed PERT diagram). When it is mature enough, the whole tree is imported in the PM tool for scheduling (dates, durations, critical path, risks). Once scheduling is complete, the project is reimported thanks to a merge function in MAESTRIA, enriched with its planning information. This cycle of mutual enrichment between MAESTRIA and the PM tool is repeated as many times as necessary. At any time, snapshots of the diagram can be exported at the graphical or Excel formats.

The interest of MAESTRIA is to build incrementally IVV trees and to validate them within a team and between teams. Its intuitive interface eases the appropriation of the tool and communication, for instance inside Obeya rooms. The interest of a smooth integration with a project management tool is to unify two practices and to convergence more efficiently towards realistic IVV trees.

5 Added Values Competitiveness Competitiveness is the main Group initiative addressed by this project. This standard supports trade-offs between different stakeholders to converge on an optimized strategy (Fig. 5).

Fig. 5. An example of optimization with MAESTRIA

100

P. Esteve et al.

This standard makes it possible also to quickly share the test strategy with the customer and other stakeholders, and to identify and confirm incremental deliveries according to their right needs. This is true for an internal customer as well as for a platformer who can run his own tests with interim the deliveries of the product. The activities on the critical path of the test strategy PERT diagram can be particularly studied regarding the customer’s needs. Going Global This standard makes it possible to describe the contracting activity in terms of delivered product but also in terms of tests performed by the contractor on this product. It makes it possible to confirm the scope of subcontracting regarding the testability criterion, test coverage, and the capability of the subcontractor to perform them. Diversity & Inclusion The graphic standard with its associated grammar is intuitive, supported by a software graphic edition tool that does not require specific training. A student, an apprentice quickly adopted the standard. Leadership & Governance This initiative was driven by the need to share the test strategy in co-engineering in order to optimise it by benefiting from collective intelligence. The different points of view in development and in production are taken into account for a global optimization. The materialization of the calendar and technical risks through this representation enables in particular the IVVQ Manager to build a back-up plan to secure a strategy regarding to the potential events. The test strategy representation is well adapted to visual management during both its preparation and implementation (using an Obeya room or any other lean management technique).

6 Future Work and Perspectives MAESTRIA has immediately met a real success to the IVVQ Managers community of Thales. Sponsored by the Corporate, the E2 Definition Board and supported by Engineering Maturity Leaders and Quality Departments, it has spread very rapidly in pilot bids and projects in different Thales business units. MAESTRIA is made available in the Thales Inner-Source Software (TISS) community for deployment and contributions to add-on development. Moreover, many functional extensions of MAESTRIA have rapidly been imagined by early adopters beyond the basic use case formulated in Sect. 2: • Visual monitoring of requirement conformity, product maturity, and IVVQ activity earned value is a quick win: an IVVQ strategy PERT diagram is already implemented in a project managed through a visual management.

MAESTRIA: A New Tool to Support Collaborative Building

101

• Implementation of the IVVQ strategy supported by Orchestra: connecting MAESTRIA with the test management tool of Orchestra (a.k.a. Vivaldi) would enable to link strategy elements with requirement coverage, test specifications, test campaigns, test metrics, and test document production. • Openness to various scheduling tools deployed in projects (Microsoft Project [ref 6], Primavera [7]) and bids (QDV [5]). • PERT diagram optimization according to cost by connecting MAESTRIA to estimation tools (e.g., Thales tool True Planning). • Support of functional integration based on scenarios and functional chains from a design model (Capella), and impact analysis of design changes on the integration tree. • Link with lean engineering techniques (decision tree, knowledge gaps, key decisions), which sequence design decisions impacting the assembly and integration trees. • Expanded to other process areas: solution installation and deployment, product industrialization and production, test bench development, or lean startup innovation approach and integration of Minimum Viable Products. • Link with Thales Product And Lifecycle Management (PALMA) and Digital Twin, in order to address various configuration states of a product (e.g., as design, as built, as deployed…), following exploratory studies from the Technical Directorate. • Advanced strategy optimization capability: testability analysis, sizing parameters trade-off, decision, assumption, simulation, etc. Besides these potential functional capabilities, the mid- and long-term roadmap of MAESTRIA may envisage different directions: • Integration into the current and future E2, • Improvement of collaborative aspects by enabling multi-users simultaneous access, multi-site sharing, and e-Obeya, • Porting from the current Eclipse world towards a web-based technology, • Following the project Clarity route towards Open-Sourcing.

7 Conclusion Thales engineers expressed the need for an easy-to-use tool to define, schedule and share an IVVQ strategy with other Engineering Domains. MAESTRIA, thanks to a graphic interface based on EMF allows defining IVVQ strategy based on diagrams, with very user-friendly interface, a standardized syntax, a robust meta-model, and ability to link it with powerful scheduling tools like Microsoft Project. Its system of data exchange with the scheduling tools based on the PBS of a solution allows to define an integration strategy and to schedule it by taking into account all the constraints it term of resources, skills, tests means, risks… Its ability to produce easily shareable IVVQ strategy models is a major asset for co-engineering activities. It allows refining, sharing and identifying the key activities with all the stakeholders at the bid and project phases.

102

P. Esteve et al.

Furthermore, its software architecture which was designed from the beginning to enable collaborative work and its future integration in the Engineering Environment of Thales allows considering a large number of new use cases. In the future, by exchanging information with modelling, test management, defects management, and monitoring tools, it can become an end-to-end decision support tool for systems integration and test activities. MAESTRIA has been quickly and easily handled by the Thales pilot projects and developed in collaboration with them to best fit their needs in terms of features and UX design. All the feedbacks are quite positive, and the tool is now implemented on major bids and projects within Thales. MAESTRIA has clearly filled a gap in the Thales suite of engineering tools and is set to be generalized and used by all Thales projects. The enthusiastic welcome reserved by the early adopters of Thales is promising and brings many changes and expansion perspectives.

References 1. ISO/IEC/IEEE 15288:2015 - Systems and software engineering — System life cycle processes 2. ISO/IEC 24748–6 - Systems and software engineering — A Guide to System Integration Engineering 3. Kitalpha. https://polarsys.org/kitalpha/ 4. Microsoft: XML Schema for the Project Element 5. Translate this page QDV – Advanced Estimating Tools. https://quick-devis.com/en/ 6. Microsoft Project. https://www.microsoft.com/france/office/project/ 7. Primavera. https://www.oracle.com/applications/primavera

School Shootings in the U.S. – Where to Begin Bruce A. Normann(B) and Mo Mansouri School of Systems and Enterprises, Stevens Institute of Technology, Hoboken, NJ 07030, USA {bnormann,Mo.mansouri}@stevens.edu

Abstract. This paper focuses on a four-phase approach for describing the process whereby a school shooter realizes the activities leading up to the attack Desire to Act, Authority to Act, Means to Act, and Opportunity to Act. Greater emphasis is given to the first two phases, and the concept of ‘Authority to Act’ is examined closely. Confronted with the awful reality of a school shooting, one of the most difficult questions in everyone’s mind is, “How could they do such a thing”? The answer lies in the belief that they have the authority to act and a better understanding of this component may one day provide enhanced tools for prevention. A systems thinking approach is used to discover key relationships within the problem set that lead to new insights into the true nature of the problem. This paper will use this modern set of tools to investigate the causal factors which influence school shooters.

1 Introduction School shootings, especially those that are carried out by students or young adults pose a difficult challenge for policy makers and law enforcement. It’s never difficult to find the shooter; their tactics rarely favor escape. Instead, it’s the signs pointing to and leading up to the tragedy that frequently escape detection. Even in an increasingly connected society, where sharing of your innermost thoughts and desires on social media is commonplace, especially amongst the young, prevention of school shootings is rare. Law enforcement and the criminal justice system have always been a very loosely coupled control mechanism and terroristic events are usually so singular and isolated that few opportunities exist to disrupt the chain of events. Complex problems have always existed and yet, the thought patterns, structures, and philosophy needed to solve them have evolved slowly. A reductionist approach and search for independent variables has blindered analysts away from a holistic understanding that has room for both paradox and linear logic. A systems thinking approach can often be used to discover key relationships within the problem set that lead to new insights into the true nature of the problem. This paper will use this modern set of tools to investigate the causal factors which influence school shooters.

2 Investigative Approach Are school shootings an emergent property of a system, as we sometimes view terrorism today, or are school shootings a system unto itself? By changing this paradox from an © Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 103–116, 2020. https://doi.org/10.1007/978-3-030-34843-4_9

104

B. A. Normann and M. Mansouri

‘OR’ to an ‘AND’, a more robust analysis can begin. School shootings are both a property and a system, and can be viewed/analyzed in multiple ways, including these two. School shootings have many similarities with terror attacks. The tools and techniques are very similar, as is the mindset of the perpetrator during the planning and execution of the attack. There seems to be a lack of correlation in the formative processes that lead up to the decision to act, however. There has been considerable research and discussion on the root causes of terrorism and what factors cause some individuals to become involved at various levels in terrorism. However, very little of that research has crossed domains and been applied to the challenging task of understanding the causes of school shootings. A subset of terror attacks, suicide bombings, seems to have some additional characteristic traits in common with school shootings [1]. Looking at the event holistically, there is an external reaction that is absolutely identical in both cases and it creates a unique perspective for analysis. Beginning the analysis of internal causal factors from an external perspective may seem unusual, but the reaction to terrorist attacks is such an integral component to the whole concept, that considerable leverage is possible. The terrorist act is broken down into four phases: Desire to Act, Authority to Act, Means to Act, and Opportunity to Act. Greater emphasis is given to the first two phases, and the concept of ‘Authority to Act’ is examined closely. Confronted with the awful reality of a school shooting, one of the most difficult questions in everyone’s mind is, “How could they do such a thing”? The answer lies in the belief that they have the authority to act and a better understanding of this component may one day provide enhanced tools for prevention.

3 Background School Shootings – Where to Start? You start at the beginning, obviously, but where was that beginning? Maybe if we can find the beginning, we can find the end. A slight modification on the familiar post-Watergate question promotes a useful path of inquiry for this paper: “What did we learn, and when did we learn it?” Additionally, how can we unlearn this abhorrent behavior? I say ‘we’, because society is probably implicated in some way as either an enabler or one of the ‘silent forces’ that drive deep-seated change. Unlearning is hard – for individuals, for organizations, and for societies. Culture eats process for breakfast [2] and it’s abundantly clear that culture is one of the most persistent and durable constructs that are examined in systems thinking. Why do we care more about school shootings? Is it because we accept the rationale for factional mass shootings – hate crimes, religious wars, political playbooks, sectarian violence, fanaticism, or just the odd crazy person on the loose, with a densely worded manifesto in his backpack? The world has accepted all of these scenarios as normal. We are comfortable with the media storylines and we rationalize all of the horror and our own personal fears away as “…the world we live in, today”. That’s well and good for an adult population that can prioritize and compartmentalize the events of the day, but what happens when young minds, in their formative years institutionalize the concept of terrorism in their world view? In an increasingly globalized world have we transitioned from a perspective that mainly saw IRA and Basque separatist terrorists as ‘other people-not me’ to a more

School Shootings in the U.S. – Where to Begin

105

integrated viewpoint that says ‘those kids living in the war-torn regions of the Middle East are just like me’? This sense of identification is critical to the process of getting from a viewpoint that says, “Those terror attacks make no sense to me.” to one where “I understand what they’re trying to do.” and finally to an empathic perspective where a large number of people who are largely disconnected from the situation are saying, “I feel the same way they do.” There is also a time-based element at work that is critical in developing an understanding of the causal factors for school shootings. It takes time for cultural influences to develop and spread, and then it takes even more time for them to get firmly entrenched in the thought processes of individuals and society. Subtle shifts may occur over a decade or more, but generational change can be more sudden and complete. It may seem difficult to build solid linkages between a step-change in terrorist activities in the 1970’s, and an increasingly immersive media coverage of the attacks, to another step-change in school shootings (which are generally not treated as terroristic acts) twenty years later. The inability to change twenty or more years of recent history may keep a great number of analysts away from considering this influence, but systems thinking demands an integrative approach. Using a lesson from the Quality management discipline, the sum of all the components in a Fishbone (Ishikawa) Diagram [3] is a whole fish. These types of additive method frequently provide a stronger foundation for problem identification. Another aspect of terrorism that may be linked to the school shooting pattern is the rise of suicide bombing. Pape [4] identifies 315 suicide attacks in the period of 1980–2003 that were “…carried out as parts of eighteen organized coercive campaigns…aimed at gaining specific political concessions from a named target government.” The goals of these attacks are quite different from those of school shooters, at least on the surface. If you replace the “target government” with the physical and personal embodiment of the school’s organizational and cultural structure, then the parallels are clearer. The timeline of the increased popularity of this tactic also reinforces the development of an empathic response as discussed above, where a generation of youth experienced this terrifying phenomenon as normal. These factors all reinforce the ‘Authority to Act’ component of the causal chain, mentioned in the Investigative Approach above. The primary goal of this paper is to investigate one of the toughest questions that remains unanswered, “How could they even think to do such a thing”? The answers to the question of “Why did they do it?” are often used to describe a rationale, but there are millions of people who have suffered similar transgressions, and may indeed have the desire and motivation to lash out in a violent attack, but there are multiple governance forces in action that deny them the internal authority to act on those desires. There are unique aspects to this component that are not as well understood as the other elements in the causal chain. Most policy and interdiction efforts today are focused on the last two elements of the chain – taking away the means by confiscating guns [5, 6], and reducing opportunity by hardening targets [7]. The sheer numbers involved with these efforts – more than 10 million AR-15 style rifles in circulation [8, 9] and almost 100,000 school buildings to protect [10] make these efforts challenging, from both an implementation and policy perspective. A focus on mental health issues will probably help understand the “Desire to Act” element, but my hope is that more systems thinking

106

B. A. Normann and M. Mansouri

focus and research on the Authority component will help drive targeted research in the mental health area, which already has a well-grounded body of knowledge on internal governance mechanisms and patterns that can be applied.

4 Causal Chain Looking at the chain of events that typically lead up to a terrorist attack, they can be described and arranged in sequence, as shown in Fig. 1 below. Each layer represents a narrowing process, where most of the individuals don’t transition from one stage to the next. Millions may have the desire to strike out violently against their oppressors or tormentors, but very few can genuinely develop and sustain the authority to act. The biggest difference between organized terror campaigns and individual attacks like school shootings is the lack of a reinforcing force that the collective provides to the group members who are actually carrying out the attacks. This factor is considered highly significant for suicide bombers, who generally receive a high level of support through all four of these phases [11, 12]. Interestingly, the one attack in modern times (Columbine) that is recognized as the archetype of school shootings was carried out by a pair of attackers, while the majority of attacks since then have involved only a single aggressor who planned it in isolation.

DESIRE TO ACT AUTHORITY TO ACT MEANS TO ACT OPPORTUNITY TO ACT Fig. 1. Causal chain of events

As discussed above in the latter part of the introduction, the third and fourth phases have some relatively straightforward mechanisms for interdiction, and even though the scale and scope of the commonly proposed solutions represent a serious challenge, the first two phases are of primary interest in this paper. 4.1 Desire to Act Hudson [13] posits three main hypotheses for the origin of terrorism: • Frustration-Aggression Hypothesis • Negative Identity Hypothesis • Narcissistic Rage Hypothesis

School Shootings in the U.S. – Where to Begin

107

There is general disagreement in the academic community on causal factors, particularly on the mental fitness of terrorists. Many argue that the evidence supports the idea that terrorists are acting rationally and sanely and that [14] “the outstanding common characteristic of terrorists is their normality.” Few analysts say the same things about school shooters, even though the motivational factors described for their actions routinely fall into the same three categories mentioned above: Frustration-Aggression, Negative Identity, and Narcissistic Rage. These behavior patterns are all relatively easy to identify and when combined with other contributing factors, it’s possible that many more school shooters could have been recognized days, weeks or months before they actually carried out their plans. According to a recent study on active shooters (a somewhat broader category) in the United States between 2000–2013 by the FBI [15]: • Only 25% of the 63 active shooters had ever been diagnosed with a mental illness • Active shooters were experiencing 3–4 major stressors in the year before they attacked • Each active shooter displayed 4–5 concerning behaviors over time, that were observed by others, including leakage of violent intent • 83% of those who observed these concerning behaviors discussed the issue directly with the individual • 54% of those who observed these concerning behaviors did not report it • 41% of those who observed these concerning behaviors reported it to law enforcement In 80% of the cases there was a primary grievance identified, and in half of those, a precipitating or triggering event related to the grievance that accelerated the planning and implementation of the attack [16]. There does seem to be some clear evidence and numerous studies that factors related to the Desire to Act can be identified, quantified, and used as a tool for preventative strategies. Unfortunately, the issue of scale presents serious challenges to the effective use of this approach. Studies suggest [17] that nearly half of the U.S. population experiences diagnosable symptoms of mental illness over their lifetime. 4.2 Authority to Act Narrowing down the millions of people who may have some desire to act violently against the institution and occupants of any unspecified school to those who, given the means and opportunity, will actually plan and implement an attack, requires examining those individuals who have determined in their own mind that they have the moral authority to act. Recognizing that there are probably dozens of possible thought patterns that can combine to form an authentic belief in an individual granting that authority, we will examine three concepts here: Normalization over time, Empathic response, and Leveraging victimhood. 4.2.1 Normalization Over Time It all started with Columbine. Or did it? Maybe Columbine reinforced an existing narrative, an existing storyline that doesn’t seem related to school shootings? It didn’t seem related then and it still evades correlation today because it is obscured by the many

108

B. A. Normann and M. Mansouri

agenda-driven biases that cloud our vision today? Examining the evolution of terror strategies, Crenshaw observes that: “Organizations arrive at collective judgments about the relative effectiveness of different strategies…on the basis of observation and experience, as much as on the basis of abstract strategic conceptions derived from ideological assumptions – allowing for social learning” [18]. If we can agree that the globalism trends of the late 20th century started with the media and the intimacy that television brought to international reporting, can we also say that social learning began to cross cultural boundaries in that same time period? Millions of U.S viewers were continually exposed to reporting on terrorist acts that was initially shocking, but became increasingly normalized over time. Even if we disregard the rationale of the terror campaigns, and whether or not the ideological motivations made any sense to the US viewing audience, the sheer amount of coverage virtually guaranteed that over time, a generation of viewers would consider terroristic strategy and tactics to be the new normal. In addition to learning that violent terrorist attacks were normal, viewers also learned that the strategy was successful. Of the 13 suicide bombing campaigns that started and ended in the time frame of 1980–2003, “… seven correlate with significant policy changes by the target state toward the terrorists’ major political goals” [19] (Fig. 2).

Fig. 2. Completed suicide bombing campaigns, 1980–2003.

As the violence continued, and evolved into deadlier and more abhorrent forms, a generation of children learned the following lessons, among others: • • • • •

Grievance-based violence is normal Mass killings of innocents is normal Individuals have power over society Victims have power over their tormentors The older generations do not understand terrorism and are paralyzed by it

School Shootings in the U.S. – Where to Begin

109

• Ramping up the violence is an effective strategy • Society won’t change unless it is forced to These lessons get absorbed slowly, but for the generations born in the 1970’s and 80’s, it was all they knew. I propose that it is no coincidence that the first terrorist-style school shooting occurred in 1999 and was carried out by teenagers who had spent their whole lives learning the lessons listed above. Once those lessons are learned, and then incorporated into the culture, the likelihood of them being unlearned is small. 4.2.2 Empathic Response It’s one thing to adjust your thinking and expectations around the behavior of others, but human beings have a natural tendency towards empathy. It’s normally encountered as a balancing force – we are hard-wired to identify with other members of our species, our societies, and our communities. Media in all forms has been an enabling tool for centuries, whether used deliberately or not, to aid in generating a common understanding between societies and cultures that don’t have extensive, direct connections. A sea change occurred in the 1970’s with live and near-real time television reporting from international war zones. Vietnam was the first major conflict that streamed into our living rooms, bringing us face-to-face with the victors and the vanquished on the modern battlefield. It also brought us a real first-hand taste of asymmetric warfare and the complexities of a war based on game theory instead of brute force. The combination of mass media reporting, the rise of investigating reporting, where there is an attempt to develop an understanding of multiple viewpoints and integrate them, coincided with increased conflict in the Middle East and the media outlets responded with hundreds of in-depth reports on who was doing what, and why. That last part was new – conflicts in the past always had a well-defined set of antagonists and protagonists. The new world of international terrorism needed explanation. It seemed important to ‘get to know’ who was bombing whom, and why. Always why…. In their effort to understand and to educate, the media provided a ready-built platform for terrorist organizations to get their message out to the world. A generation of viewers took the explanations at face value; having accepted the normalcy of the situation they didn’t block the message like their parents were doing. The older generation refused to accept the legitimacy of the terrorist groups – they just couldn’t get their hearts and minds past the horror of the attacks. The kids were paying attention to the message though, and they weren’t afraid to explore the possibility that there was some level of moral equivalency between the oppressor and the oppressed. The Soviet invasion of Afghanistan, followed by Chechen terrorist attacks certainly turned some heads in the West. For a brief moment, even the older generations were driven down the path of understanding, nay even supporting the goals and tactics of a modern terrorist organization. When the shoe was on the other foot, they were finally able to make the leap from ‘This makes no sense.’ to ‘I understand what’s going on.’ and lastly to ‘I would do the same thing if it was me.’

110

B. A. Normann and M. Mansouri

4.2.3 Leveraging Victimhood Terrorism is fundamentally about leveraging you victim status. In the shifting strategies of the 1980’s, when suicide bombing became common, the role of victim moved from the numerator in the calculus of public opinion to the exponential factor. Margalit [20] explains the concept well: “Suicide bombing has an additional value: that of making yourself the victim of your own attack., and thereby putting your tormentors to moral shame. The idea of the suicide bombing, unlike that of an ordinary attack, is perversely, a moral idea in which the killers, in acting out the drama of being the ultimate victim, claim for their cause the moral high ground.” School shootings, like most active shooter scenarios, are almost always about settling grievances where the shooter is extracting revenge for their own victimhood [16] (Fig. 3).

Fig. 3. Primary grievance for active shooters

School shooters not only get to strike at the source of their anger, but they also take satisfaction in the knowledge that the diffuse, and highly networked social constructs that support the institution are very vulnerable to disruption. I’m sure nothing made the Parkland shooter more contented than hearing about the multiple suicides among the affected populations, over a year after the event. Is there a better paradigm of success for a terrorist than knowing that their target is destroying themselves from within, for many years after the initial attack? Further linkage between the school shooter and suicide bombers is the fact that many school shootings end in suicide, either by the shooter’s own hand, or ‘suicide by cop’. Indeed, the overwhelming impression of the perpetrators is that they are looking for closure, to close an enduring wound. Once the attack is over, they are literally and morally spent, and have no desire to escape and either bask in the glory of their revenge or

School Shootings in the U.S. – Where to Begin

111

attempt to return to a lost sense of normalcy. Whatever reward they might have imagined for themselves after it was all over seems to vanish during the act. Also, since the attack is a one-time event, there is no ‘tit-for-tat’ escalation in the school shooter population, because there does not seem to be any centralized target for the shooters to respond against. Although, if the Parkland shooter held a grudge against the Broward County Sherriff’s office, after dozens of negative interactions, he certainly set up a long-term hostile scenario for them. 4.3 Shaping Forces When examining trends, it’s often useful to understand where increases due to positive shaping forces or reductions due to balancing forces are occurring. The general trends for active shooter attacks and school shootings in general are fairly steady, but the trend is completely dependent on the time period chosen. The chart from the FBI [21] in Fig. 4 shows the period from 2000–2017, and it looks like a significant rising trend. The most important information that these charts show, is that there are definitely some balancing forces in play, otherwise the trends would be exponential in nature.

Fig. 4. 250 Active shooter incidents in the U.S. from 2000 to 2017, Source: FBI

A similar set of statistics from Northeastern University [22] in Fig. 5, showing data from 1976–2011, displays a more stable trend, although still rising slightly.

112

B. A. Normann and M. Mansouri

Fig. 5. Mass shootings in America 1976–2011, Data from James Alan Fox, Northeastern University.

A New York Times’s analysis [23], shown in Fig. 6 identified 111 school shooting cases that met the FBI definition for an active-shooter scenario, excluding episodes that were more correctly characterized as targeted attacks, gang shootings, and suicides.

Fig. 6. 111 school shooting cases, 1970–2019.

Again, a slight rising trend can be observed. None of the data suggests exponential growth in the number of incidents. Data on number of injuries and lethality show similar trends, but are outside the scope of this article.

School Shootings in the U.S. – Where to Begin

113

5 Shifts in Law Enforcement Strategy Efforts to create a ‘profile’ of a terrorist have had mixed success, at best. The focus for detection has shifted to later phases in the causal chain (Fig. 1). For example, Hudson found that the US Secret Service now looks for motives and behavior as key indicators [13]. The U.S. Secret Service once watched for people who fit the popular profile of dangerousness—the lunatic, the loner, the threatener, the hater. That profile, however, was shattered by the assassins themselves. In interviews with assassins in prisons, hospitals, and homes, the Secret Service learned an important lesson—to discard stereotypes. Killers are not necessarily mentally ill, socially isolated, or even male. Now the Secret Service looks for patterns of motive and behavior in potential presidential assassins. The same research methodology applies to potential terrorists. Assassins, like terrorists in general, use common techniques. Missing from this description is the transition to a state where the killer has granted themselves the authority to act. Generally, there is a change in behavior at that point and planning begins in earnest. That is when specific evidence may be generated, as information and materials are gathered and many of those transactions can be detected and monitored. The time period for the planning phase varies considerably, as shown in Figs. 7 and 8 below [24].

Fig. 7. Pre-attack behaviors of active shooters in the United States between 2000–2013.

The time spent preparing is generally much shorter, and is biased towards the shorter time periods.

114

B. A. Normann and M. Mansouri

Fig. 8. A study of the pre-attack behaviors of active shooters in the united states between 2000–2013.

6 Conclusion While nothing is easier than to denounce the evildoer, nothing is more difficult than to understand him. – Fyodor Mikhailovich Dostoevsky: Crime and Punishment Systems thinking has emerged as a powerful tool to examine, define, and develop solution spaces that map to very difficult problems, particularly those problems that have a paradoxical nature or those that do not fit clearly into existing thought structures. The ability of school shooters (and their terrorist cousins, suicide bombers) to carry out mass murder amongst a population that they were once a member of, just doesn’t fit into the rational psyche of modern society. This paper focused on the second phase of the proposed causal chain – the Authority to Act, primarily because it is the least understood of all the phases. Answering the question, “How could they do such a thing?” is a nearly impossible task, and the ability to detect any unique behaviors and attributes of someone who has already made that decision in their head may prove useful in prevention and interdiction. The vast majority of people have a governance mechanism that prevents them from making that transition from motivation and desire to act to the state where they have been granted permission to commit mass murder. Some of those governance mechanisms have external foundations and some are purely internal. A study of those mechanisms, as they acted upon the community of school shooters, is recommended for future research. The methodology applied by Schoenenberger, Schenker-Wicki, and Beck [25] demonstrates a potential approach for a more detailed analysis.

References 1. Bloom, M.: Dying to Kill: The Allure of Suicide Terror, p. 77. Columbia University Press, New York (2005) 2. Culture Eats Strategy for Breakfast: Peter Drucker? Giga Information Group? Mark Fields? Eli Halliwell? Richard Clark? Anonymous? https://quoteinvestigator.com/2017/05/23/cultureeats/

School Shootings in the U.S. – Where to Begin

115

3. Fishbone (Ishikawa) Diagram, American Society for Quality – Resources. https://asq.org/ quality-resources/fishbone 4. Robert, A.: Pape, Dying to Win, p. 14. Random House Inc., New York (2005) 5. Sarlin, B.: Dem congressman: Force gun owners to get rid of assault weapons. NBC News, 3 May 2018. https://www.nbcnews.com/politics/congress/dem-congressman-forcegun-owners-sell-assault-weapons-n871066 6. Noack, R.: New Zealand’s Jacinda Ardern ‘does not understand’ why US has failed to toughen gun laws. Washington Post, 15 May 2019. https://www.washingtonpost.com/world/ 2019/05/15/why-wont-us-change-its-gun-laws-new-zealands-jacinda-ardern-says-i-do-notunderstand/?utm_term=.626844d7f1e3 7. Wamsley, L.: Florida Approves Bill Allowing Classroom Teachers To Be Armed. NPR, 2 May 2019. https://www.npr.org/2019/05/02/719585295/florida-approves-bill-allowingclassroom-teachers-to-be-armed 8. Yablon, A.: How Many Assault Weapons Do Americans Own? The Trace, 22 September 2018. https://www.thetrace.org/2018/09/how-many-assault-weapons-in-the-us/ 9. Irby, K.: Nobody knows exactly how many assault rifles exist in the U.S. – by design. McClatchy Washington Bureau, Washington, DC, USA, 23 February 2018. https://www. mcclatchydc.com/news/nation-world/national/article201882739.html 10. https://nces.ed.gov/fastfacts/display.asp?id=84 11. Bloom, M.: Dying to Kill: The Allure of Suicide Terror, p. 88. Columbia University Press, New York (2005) 12. Victor, B.: Army of Roses: Inside the Palestinian Women Suicide Bombers. Rodale Press, New York (2003) 13. Hudson, R.A.: The Sociology and Psychology of Terrorism: Who Becomes a Terrorist and Why? A Report Prepared under an Interagency Agreement by the Federal Research Division, Library of Congress, Washington, DC, USA, p. 43, September 1999 14. Crenshaw, M.: The causes of terrorism. Comp. Polit. 13, 379–399 (1981) 15. Silver, J., Simons, A., Craun, S.: A Study of the Pre-attack Behaviors of Active Shooters in the United States Between 2000–2013. Federal Bureau of Investigation, U.S. Department of Justice, Washington, D.C., USA, p. 7 (2018) 16. Silver, J., Simons, A., Craun, S.: A Study of the Pre-attack Behaviors of Active Shooters in the United States Between 2000–2013, p. 22 (2018) 17. Kessler, R.C., Berglund, P., Demler, O., Jin, R., Merikangas, K.R., Walters, E.E.: Lifetime prevalence and age-of-onset distributions of DSM-IV disorders in the National Comorbidity Survey Replication. Arch. Gen. Psychiatry 62(6), 593–602 (2005) 18. Crenshaw, M.: The logic of terrorism: terrorist behavior as a product of strategic choice. In: Reich, W. (ed.) Origins of Terrorism: Psychologies, Ideologies, Theologies, States of Mind, p. 8. Cambridge University Press, Cambridge (1990) 19. Robert, A.: Pape, Dying to Win, p. 46. Random House Inc., New York (2005) 20. Margalit, A.: The Suicide Bombers. The New York Review of Books, vol. 50 no. 1, 16 January 2003. http://www.nybooks.com/articles/15979#fnr1 21. Quick Look: 250 Active Shooter Incidents in the United States from 2000 to 2017. FBI Active Shooter Resources. https://www.fbi.gov/about/partnerships/office-of-partnerengagement/active-shooter-incidents-graphics 22. Smith, G.: Gun Facts, Version 7.1 (2017). http://www.gunfacts.info/. Data sourced from study by James Alan Fox, Northeastern University, “Mass Shootings in America: Moving Beyond Newtown,” Homicide Studies, 2013 23. Cai, W., Patel, J.K.: A Half-Century of School Shootings Like Columbine, Sandy Hook and Parkland. New York Times, 11 May 2019

116

B. A. Normann and M. Mansouri

24. Silver, J., Simons, A., Craun, S.: A Study of the Pre-attack Behaviors of Active Shooters in the United States Between 2000–2013, pp. 13–14 (2018) 25. Schoenenberger, L., Schenker-Wicki, A., Beck, M.: Analysing terrorism from a systems thinking perspective. Perspect. Terror. 8(1) (2014). http://www.terrorismanalysts.com/pt/index. php/pot/article/view/323/html

Smart Component Modeling for Complex System Development Philipp Helle1(B) , Sergio Feo-Arenis2 , Andreas Mitschke1 , and Gerrit Schramm1 1

Airbus Central R&T, Hamburg, Germany [email protected] 2 Airbus Central R&T, Munich, Germany

Abstract. This paper presents a proposal for a change in the aircraft development process to cope with the increasing complexity of products and pressure from the market to develop aircraft faster. The key process change is a deviation from the traditionally linear development approach and the inclusion of an out-of-cycle component development phase, where components of an aircraft are developed preemptively, outside of a program development effort. These so-called smart components are then adapted to the specific needs of a program within the more linear cycle. Furthermore, it describes a metamodel for modeling the so-called smart components based on proven MBSE principles and exemplifies this approach with a small case study. Keywords: Model-based systems engineering development · Aircraft development process

1

· Component-based

Introduction

The ever-increasing complexity of products has a strong impact on time to market, cost and quality. The number of components, functions and interactions in complex systems is increasing with every product generation [8]. The traditional development process has been proven to yield reliable and safe products but is time and cost intensive [11]. Originally, Boeing had the objective to reduce the B787 development cost from $10 to $6 billion and development time from six to four years and ended up with a duration of eight years and nine months and a total cost of $32 billion [22]. The estimated development time for the A380 was five years with an estimated total cost of $14.4 billion [1]. Eventually, a two-year delay of the delivery resulted in additional costs of approximately $6 billion [18]. The current development processes, in particular for aircraft and aircraft systems, thus require an update to cope with the increasing complexity and business requirements for faster and cheaper aircraft development. Recently, model-based systems engineering (MBSE) emerged as a trend in complex systems engineering with expectations that it will help manage the increasing complexity and reduce the development time of complex systems [5]. c Springer Nature Switzerland AG 2020  G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 117–128, 2020. https://doi.org/10.1007/978-3-030-34843-4_10

118

P. Helle et al.

It is expected to “become the “norm” for systems engineering execution” [8] and “is rapidly emerging in the aerospace industry as the predominant way to practice the synthesis and architecture development for complex systems” [6]. This paper presents a proposal for a change in the aircraft development process to include an out-of-cycle component development phase, in which components of an aircraft are developed independently of the traditional linear development process. They are then adapted to the specific needs of a program within the more linear cycle. Furthermore, it describes a metamodel for modeling these so-called smart components based on proven MBSE principles [14]. The methodology is developed in an aeronautic context but is, in general, independent of any specific domain. This paper is structured as follows: Sect. 2 provides background information regarding the current approach for aircraft and aircraft systems development and discusses its shortcomings. Based on this, Sect. 3 will describe the envisaged process change before Sect. 4 will describe the metamodel developed to support this process change. Section 6 illustrates the application of the metamodel with a small example. Section 7 wraps everything up with a conclusion and a brief outlook. 1.1

Related Work

Paper [7] describes a framework and prototype tool called AirCADia for “interactive composition and exploration of innovative aircraft design studies” [7]. AirCADia also tries to integrate system architecture description with design space exploration based on the set based design (SBD) approach. Modelica models are used for the lower-level computations. In [10], a rapid analysis and trades environment is described. It integrates the standard SysML modeling tool MagicDraw for architecture definition with ModelCenter using a ModelCenter extension called MBSEPak that converts the SysML model so that the analysis workflows can be run in ModelCenter using an analytical engine of the designers’ choice. The work presented in [2] examines the component-based software engineering paradigm and infers that it has a strong impact on the overall life-cycle process. More specifically, that the process for system development has to be separated from component development since “the components should already have been developed and possibly used in other products when the system development process starts”. A comparison of the bottom-up component-based development paradigm with a more traditional top-down model-based paradigm in a complex systems engineering context is presented in [20]. Here, the authors endorse a combination of the two approaches. The overview of architecture frameworks and modeling languages for MBSE given in [14] concludes that “important future directions in MBSE aim at improving decision-making during the system design process, ensuring consistency between heterogeneous models as well as an efficient synthesis of system architectures and system architecture families”.

Smart Component Modeling for Complex System Development

2

119

Current Aircraft Development Process

As described by [17], the overall life-cycle of modern aircraft systems is of a linear nature and consists of Design, Development, Production, Operation, Support, and Disposal. As depicted by Fig. 1, according to established systems engineering principles, the system design process is divided into four major phases: conceptual design, preliminary design, detailed design, and test & evaluation.

Fig. 1. Major aircraft design activities [17]

The starting point for the current design process are requirements based on customer needs and certification regulations. Based on those requirements, initial design concepts are elaborated and assessed according to their feasibility, and evaluated against key performance indicators such as operating cost, weight, and range. A few candidate concepts are then selected and refined in a preliminary design phase. After a more profound analysis, one of the design alternatives is chosen and further refined during the detailed design phase. To support the assessment of design concepts, various models describing different aspects of the aircraft system are developed. However, developing models to describe design alternatives is usually expensive and time consuming. In practice, when a new aircraft program is launched, time pressure tends to lead to a situation where only very few alternative design concepts are defined and assessed.

3

Out-of-Cycle Development Method

To address this challenge, it is suggested to introduce a new out-of-cycle phase (see Fig. 2). This phase is independent from an aircraft program. Within this phase, a set of pre-designed and pre-verified aircraft systems and components are defined and stored in a library. When a new aircraft program is launched, these components are used to setup different design concept alternatives quickly. This will save time and allows the definition and analysis of a greater number of design alternatives, including more radical design concepts. Since the models are defined outside of an aircraft program when requirements are not yet fixed, the models have to be parametric. In case models originate from previous programs, effort is required to make them parametric. Alternatively, the models may also be defined from scratch in a parametric way based on anticipation of future needs and technology trends.

120

P. Helle et al.

Fig. 2. To-Be process with Out-of-Cycle Phase

The requirements for the methodology supporting this new out-of-cycle process are as follows: – The methodology shall be based on MBSE principles. – The methodology shall be independent from any specific application domain. – The methodology shall enable a product-line oriented product development, i.e., the metamodel must allow modeling of different variants of a product and ensure a consistent configuration and parametrization. – The methodology shall enable inclusion of already existing domain models, i.e., models in a domain-specific modeling language. – The methodology shall enable automatic verification of models, i.e., it shall be possible to check if the built models adhere to the modeling paradigm and to user-defined constraints. – The methodology shall enable consistent modeling not only of the product itself but also of the context, such as the industrial system used to build the product and allow the creation of relationships between the modeled artifacts.

4

Smart Component Modeling

The out-of-cycle development method described in Sect. 3 requires a new MBSE paradigm for modeling, which is called smart component modeling. A smart component model (SCM ) is a parametric model of a component. An SCM is a self-contained model that can be developed out of cycle and enables capturing of all information relevant to the development of the component. SCMs are foreseen to be stored in a repository, called the SCM Library. This enables sharing and reuse. When the in-cycle phase of an aircraft or aircraft system development starts, the assets in the SCM Library are pulled and used as pre-defined and pre-verified components for a new development.

Smart Component Modeling for Complex System Development

121

The SCM metamodel defines all objects and relations between them that are required to capture information related to smart components in models. The development of the SCM metamodel was driven by internal use cases and inspired by existing modeling languages such as the Systems Modeling Language (SysML) [12]. To avoid confusion, the following disambiguation is necessary: – The SCM metamodel governs the elements and relations that were identified in the scope of smart component modeling. – An SCM model is an instance of the SCM metamodel, i.e., a model that adheres to the principles defined by the SCM metamodel and contains instances of the metamodel elements. – SCMModel is a class in the SCM metamodel for modeling a smart component model, i.e., a parametric model of a component. In the following sections, the most important classes in the SCM metamodel and their relations are briefly described. All metamodel elements (except Annotation) inherit from the abstract class SCMElement. This allows them to share the common properties id, description and label which are all string type properties. The id property is used to store a unique identifier for each element. The description property can be used to store a description as a free text. The label, which does not have to be unique, is displayed in the model browser and on diagrams in order to identify an element. 4.1

Models

An SCMModel can be decomposed into other SCMModels. This relation is modeled as a block-part relation in a fashion similar to SysML. Every Part must be typed by an SCMModel. An SCMModel can have a reference to an ancestorModel to indicate that the SCMModel is a variant of the ancestorModel. An SCMModel may also contain diverse properties. PerformanceModelReferences specify external models that are used to calculate parameters and characteristics. PerformanceModelReferences point to a model manifest1 file. BehavioralModelReferences are used to include external models that define the behavior of a model. BehavioralModelReferences also point to a manifest file that defines the BehavioralModelReference. Additionally, a model may contain AggregationNodes. 4.2

Parametric Elements and Relations

The elements Parameter and Characteristic are used for configuration and sizing of a model. Parameters can be set, i.e. they are inputs to a model, and Characteristics are calculated, i.e. they are outputs of a model. Both are subclasses of TypedElement and are thus typed by a PropertyType (see Sect. 4.3). 1

A manifest file describes not only the location of the model, but also the inputs and outputs mapped to parameters and characteristics and a solver that can be used to execute the model.

122

P. Helle et al.

Parameters and Characteristics can be connected with ParametricConnectors to represent a data flow between the connected elements. This flow can either be lateral, i.e., the Characteristic of one Part becomes the Parameter of another Part or vertical, i.e., a Parameter of one Part becomes a Parameter of another Part or the Characteristics of one or more Parts are aggregated into a Characteristic of the container SCMModel. AggregationNodes can be used to define how multiple incoming Edges are aggregated into a single output. AggregationNodes and ParametricConnectors can specify calculations on the transported data. The concept of Parameters and Characteristics enables sizing and trade-off studies during design time and ensure a consistent configuration of all Parts of an SCMModel since the Parameters are passed along the model hierarchy in a top-down fashion. 4.3

Type System

In order to ensure syntactic and semantic consistency of smart component models, the need for appropriate typing information becomes apparent. Extensive type systems for object oriented programming are available (see, e.g. [4]), but they have proven to be too unwieldy for the limited needs of the SCM approach. Programming languages include types for references or pointers which are not necessary in our context. Conversely, most typing systems for programming languages do not include information on quantities, units or scales that are required to refine the data types in an engineering context. An available solution for the specification of numeric values is the conceptual model for Quantities, Units, Dimensions and Values (QUDV) provided as a schema in the SysML specification to define systems of units and quantities in models. Libraries are available that populate the schema according to the SI system of measurements as standardized in ISO-80000 [9]. Given that additional models in the landscape around SCM may be specified in SysML, we consider it convenient to adopt elements of QUDV to provide compatibility. We thus opted for a simplified type system with elements inspired from both typical programming-language-style types and QUDV. The syntax of our type specifications in Backus-Naur form is shown below: Type ::= Quantity | String | Object | List | Enum Quantity ::= NumericType UnitSpec UnitSpec ::= ’[’ Unit ’]’ |  NumericType ::= Decimal | Integer Object ::= Object ’{’ (Identifier ’:’ Type)+ ’}’ List ::= List Type  Enum ::= Enum ’{’ Identifier+ ’}’ Here,  denotes an empty string and U nit is any unit identifier as defined by ISO-80000. We also, for the sake of compactness, abuse the notation to denote

Smart Component Modeling for Complex System Development

123

valid alphanumeric identifiers as in e.g. the Java language with Identif ier and valid literals for a given type with V alue. All SCMElements that can be typed, inherit from the abstract class TypedElement. This contains a reference to PropertyType and the optional attribute valueSpecification that enables the specification of additional range restrictions on the specified type. The range restrictions follow the simple syntax: ValueSpec ::= (’(’ | ’[’) (Value|) ’,’ (Value|) (’)’ | ’]’) | { Value+ } | ’Object’ ’{’ Identifier ’:’ ValueSpec ’}’ |  This allows to (optionally) specify interval ranges that can be open in either direction, sets of values and object field value specifications. The implementation of the type system functionality uses XText to enable specifying types and value specifications in text form as the content of ordinary string attributes and interpreting them according to the syntax shown above. The type specifications and value constraints allow performing static checks in order to provide immediate feedback to the user in the case of a syntactic inconsistency. Finally, values returned by calculation services through performance or behavioral model references can be checked against their type specifications to make sure that those services provide consistent data. The syntactic and semantic checks described here are made part of the continuous integration process for models, where each new version is checked and the calculation results are updated, verified and stored in an automated manner, triggered by changes in the versioning control system. 4.4

Ports and Connectors

Ports are used to represent interfaces of the component that is represented by a SCMModel. They specify how the component that is described by the SCM can be connected to other components during run-time, i.e. when the component (not the model) exists. Depending on the kind of component (software, hardware, etc.), Ports can be of diverse nature (mechanical connections, software interfaces, etc.). Ports are typed by a PortType. PortTypes can be refined using FlowItems, which in turn are typed by a PropertyType. This enables a precise interface specification. Connectors are used to model connections between ports of a SCMModel, a Part or a BehavioralModelReference. A Part displays all the Ports that the SCMModel by which it is typed has. 4.5

Constraints

Constraints are a way to impose restrictions on models. The SCM metamodel separates between two different types of constraints: user-defined constraints and metamodel constraints. User-defined constraints are modeled using the Constraint class. A Constraint has a relation context to a SCMModel to indicate the context in which it is to be evaluated and a property constraintSpecification to contain the actual specification of the constraint. The current prototype

124

P. Helle et al.

uses the Object Constraint Language (OCL) [13] as constraint specification language. Metamodel constraints are built into the metamodel and enable checking whether the model adheres to metamodel restrictions, e.g., that all Parts are typed by an SCMModel.

5

Implementation

The Eclipse Modelling Framework (EMF) [19] is a modeling framework and code generation facility for building tools and other applications based on a structured data model. EMF provides tools and runtime support to produce a set of Java classes from a model specification, along with a set of adapter classes that enable viewing and editing of the model, and a basic editor. EMF is the basis for the Obeo Designer2 tool, which builds on the Eclipse Sirius project [21] and allows the definition of graphic editors based on a defined EMF metamodel. This enables rapid prototyping of modeling solutions, which is ideal for a research/prototyping environment such as Airbus Central R&T. Changes to the metamodel are almost instantly available in the SCM Workbench, our prototype SCM modeling tool. On the other hand, EMF and Obeo Designer are mature and have been proven in industrial practice, e.g. Capella, the modelling tool from Thales that implements the Arcadia method is built with EMF and Obeo Designer as well [16]. 5.1

Supporting Tool Infrastructure

The SCM approach is supported by a tool infrastructure that follows the microservice paradigm [3], i.e., a software architecture for building applications by the orchestration of small, independent services, that are communicating via light-weight mechanisms, such as REST (Representational State Transfer) over HTTP (Hypertext Transfer Protocol) [15]. The microservices approach allows new services to be developed and used quickly and enables continuous integration and delivery (CI/CD) in a scalable environment running in an internal cloud infrastructure. Currently, the following main services are implemented to support the SCM approach: – The SCM Library, that is responsible for storing, versioning and providing concurrent access to SCM models. – The SCM Engine, that can interpret SCMs, check constraints and run parametric calculations either as a single simulation run or as a Design of Experiments setup with multiple samples. – The Performance Model API, that serves as a glue between model references, which are part of SCMModels and external domain-specific models with their own solver or simulation engine. 2

https://www.obeodesigner.com/en/.

Smart Component Modeling for Complex System Development

6

125

Example and Evaluation

To develop the smart component modeling methodology, several use cases were examined, one of them being a commercial aircraft. This section shows an example of a simplified version of an aircraft cabin to illustrate the smart component modeling approach. Aircraft cabins consists of decks. On each deck a number of seats and modules of different types are installed. Cabin, deck, module and all kinds of module types are modeled as SCMModels. The relation between cabin, deck, module and seat row is a model-part composition where the relation between cabin module and the module types is a variant relation as depicted by Fig. 3 in a hierarchy diagram. The model-part relation also has an associated multiplicity to denote the number of parts in a model, e.g., a cabin can have one or two decks.

Fig. 3. Hierarchy view

Figure 4 shows the structural view of a cabin. A deck is mechanically connected to the aircraft frame, which is not part of this Package. The corresponding interface is delegated from cabin to the deck. This delegation has some dynamic since a cabin SCMModel may contain more than one deck. Therefore, this connection has a multiplicity corresponding to the multiplicity of the Part deck. The parameter view shows the parametric relations in an SCMModel. Figure 5 shows three different kinds of relations: Delegations represent a relation from the Parameters of a SCMModel to Parameters of its sub-models (Parts, PerformanceModelReferences or BehavioralModelReferences). Aggregations represent a relation from Characteristics of a sub-model to Characteristics of its owner SCMModel. Transfers represent a lateral relation between Characteristics and Parameters of different sub-models of the same parent SCMModel.

126

P. Helle et al.

Fig. 4. Structure view

Fig. 5. Parameter view

All parametric relations can have associated calculation functions that describe how data is translated along the connector. As an example the “Cabin Configuration” Parameter is an object containing an array of objects of “Deck Configuration” PropertyType. The calculation function that is associated with the edge from the Parameter “Cabin Configuration” of the SCMModel Cabin to the Parameter “Deck Configuration” of the Part Deck selects the element indexed by the correct deck number. Another example is the transfer of “Number of Seats” from each deck to one “Revenue Model”. The connectors will accumulate the number of seats of each type from each individual deck and expose only the calculated result to the “Revenue Model”. A further example is the aggregation to the “Number of Seats” Characteristic of the SCMModel Cabin. Here, not only the corresponding outputs of each deck but also their results are accumulated, thereby providing the total sum of seats in the whole cabin. The Cabin example showed that the modeling and top-down flow of parameters helps to ensure that all the models that are part of the hierarchical structure of one top-level SCMModel have one consistent view of the configuration and variability options. It also prevents sub-models from having a configuration that is not in-line with the rest. Furthermore, the ability to define a flow of information through parametric models simultaneously within the model that contains the structure and the overall hierarchy of a component ensures that the same data is used for trade-offs and sizing experiments as well as for the actual

Smart Component Modeling for Complex System Development

127

architecture definition. Additionally, the abstraction of different model languages and tools on the basis of the PerformanceModelAPI enables reuse of already existing domain models and allows engineers to build performance models in the modeling language and tools that is most suitable for the job.

7

Conclusion

Past experience shows that current aircraft and aircraft system development processes are not suitable for keeping up with the rising complexity of products. Those processes are under pressure from market-driven demands for faster, and from business-driven demands for cheaper aircraft programs. In this paper, we presented a proposal for a change from a traditionally linear development approach to one that includes a parallel, out-of-cycle component development phase. This approach requires new modeling methods to ensure that the developed components are parametric so that they can be adapted to program-specific needs. To this end, we developed the new smart component modeling approach, enabled by a formal metamodel and a supporting tool infrastructure based on state-ofthe-art IT architecture principles. The resulting approach is not specific only to the aircraft development domain. The metamodel is stable now and current work is focused on additional services in the supporting tool environment and a more thorough evaluation of the approach in the use cases. The presented approach is developed as a prototype within Central R&T, a cross-divisional and cross-national Airbus research organization, and upon completion will be transferred to the organization responsible for industrialization and deployment into the Airbus engineering organization.

References 1. Chase, J., Darot, J., Evans, A., Evans, S., Fernandes, P., Markish, J., Speller, T.: The business case for the very large aircraft, p. 589 (2001). https://doi.org/10. 2514/6.2001-589 2. Crnkovic, I., Chaudron, M., Larsson, S.: Component-based development process and component lifecycle. In: 2006 International Conference on Software Engineering Advances (ICSEA 2006), p. 44, October 2006. https://doi.org/10.1109/ICSEA. 2006.261300 3. Dragoni, N., Giallorenzo, S., Lafuente, A.L., Mazzara, M., Montesi, F., Mustafin, R., Safina, L.: Microservices: yesterday, today, and tomorrow, pp. 195–216. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-67425-4 12 4. ECMA: Standard 335 - Common Language Infrastructure (CLI) - Partitions I to VI. ECMA International, 6th edn. (2012) 5. Estefan, J.: Survey of Model-Based Systems Engineering (MBSE) methodologies. Technical report, International Council on Systems Engineering (2007) 6. Evans, J.W., Groen, F.J., Wang, L., Austin, R., Witulski, A., Cornford, S.L., Feather, M., Lindsey, N.: Towards a framework for reliability and safety analysis of complex space missions (2017). https://doi.org/10.2514/6.2017-1099

128

P. Helle et al.

7. Guenov, M.D., Nunez, M., Molina-Crist´ obal, A., Datta, V.C., Riaz, A.: Aircadia– an interactive tool for the composition and exploration of aircraft computational studies at early design stage. In: 29th Congress of the International Council of the Aeronautical Sciences, St Petersburg, pp. 7–12 (2014) 8. International Council on Systems Engineering (INCOSE): A World in Motion Systems Engineering Vision 2025, July 2014 9. International Organization for Standardization: ISO/IEC 80000 - Quantities and units. Standard, International Organization for Standardization, Geneva, CH, November 2009 10. Kulkarni, T., DeBruin, K., Nelessen, A., Reilley, K.A., Peak, R., Edwards, S.J., Mavris, D.N.: A model based systems engineering approach towards developing a rapid analysis and trades environment (2016). https://doi.org/10.2514/6.20165472 11. Murman, E.M., Walton, M., Rebentisch, E.: Challenges in the better, faster, cheaper era of aeronautical design, engineering and manufacturing. Aeronaut. J. 104(1040), 481–489 (2000) 12. Object Management Group: OMG Systems Modeling Language (OMG SysML), v1.2. OMG, Needham, MA (2008) 13. OMG: OMG Object Constraint Language (OCL), Version 2.3.1, January 2012 14. Reichwein, A., Paredis, C.: Overview of architecture frameworks and modeling languages for model-based systems engineering. In: Proceedings of ASME. pp. 1–9 (2011) 15. Rodriguez, A.: Restful web services: the basics (2008). http://www.gregbulla.com/ TechStuff/Docs/ws-restful-pdf.pdf 16. Roques, P.: MBSE with the ARCADIA method and the Capella tool. In: 8th European Congress on Embedded Real Time Software and Systems (ERTS 2016), Toulouse, France, January 2016 17. Sadraey, M.H.: Aircraft Design: A Systems Engineering Approach. Wiley, New York (2012) 18. Stark, J.: Product Lifecycle Management: Volume 1: 21st Century Paradigm for Product Realisation. Springer, Cham (2016). https://doi.org/10.1007/978-3-31917440-2 19. Steinberg, D., Budinsky, F., Merks, E., Paternostro, M.: EMF: Eclipse Modeling Framework, 2nd edn. Pearson Education, London (2008) 20. Torngren, M., Chen, D.J., Crnkovic, I.: Component-based vs. model-based development: a comparison in the context of vehicular embedded systems. In: 31st EUROMICRO Conference on Software Engineering and Advanced Applications, pp. 432–440, August 2005. https://doi.org/10.1109/EUROMICRO.2005.18 21. Viyovi´c, V., Maksimovi´c, M., Perisi´c, B.: Sirius: a rapid development of DSM graphical editor. In: IEEE 18th International Conference on Intelligent Engineering Systems, INES 2014. pp. 233–238, July 2014. https://doi.org/10.1109/INES.2014. 6909375 22. Zhao, Y.: Why 787 slips were inevitable? Rutgers University, New York (2013)

Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems Steffen O. P. Blume1,2 , Michel-Alexandre Cardin3 , and Giovanni Sansavini1(B) 1

3

Department of Mechanical and Process Engineering, ETH Z¨ urich, Z¨ urich, Switzerland [email protected] 2 Future Resilient Systems, Singapore-ETH Centre, Singapore, Singapore [email protected] Dyson School of Design Engineering, Imperial College London, London, UK [email protected]

Abstract. We present a simulation-based approach to capture the interactions between train operations and passenger behavior during disruptions in urban rail transit systems. The simulation models the full disruption and recovery cycle. It is based on a discrete-event simulation framework to model the network vehicles movement. It is paired with an agent-based model to replicate passenger route choices and decisions during both the undisrupted and disrupted state of the system. We demonstrate that optimizing and flexibly changing the train dispatch schedules on specific routes reduces the impact of disruptions. Moreover, we show that demand uncertainty considerably changes the measures of performance during the disruption. However, the optimized schedule still outperforms the non-optimized schedule even under demand uncertainty. This work ties into our ongoing project to find flexible strategies to enhance the system resilience by explicitly incorporating uncertainties into the design of rail system architectures and operational strategies.

Keywords: Urban rail assignment

1

· Disruption simulation · Dynamic transit

Introduction

Many cities rely on large-scale metropolitan rail networks to transport millions of passengers each day. However, expanding complexity is taking its toll on their resilience to disruptions. Despite many operational and technological improvements, disruptions remain inevitable and are potentially more catastrophic to the ever-growing urban population. Moreover, the uncertainties associated with the system operations and passengers’ behavior during both undisrupted and This research was conducted under the Future Resilient Systems program at the Singapore-ETH Centre and funded by the National Research Foundation of Singapore. c Springer Nature Switzerland AG 2020  G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 129–140, 2020. https://doi.org/10.1007/978-3-030-34843-4_11

130

S. O. P. Blume et al.

especially disrupted conditions make it ever more complex to understand the impact of disruptions. In designing pre-emptive and immediate disruption recovery strategies, it is therefore imperative to consider the effects of control actions on passenger flows and assess how demand uncertainty propagates into the performance of the system during disruptions. A large body of literature has been devoted to modeling passenger flows, train operations, their interactions, as well as schedule optimizations. To name a few, Cats [1] developed an agent-based dynamic transit assignment model and simulation platform known as BusMezzo that explicitly models individual passengers as they travel through the network on public transport vehicles. Much work has followed, that builds on this simulation platform to assess the effects of real-time transit information [2,3], or the planning of excess system capacity to reduce the impact of disruptions and congestion in [4] and [5], respectively. Moreover, other works have demonstrated the use of agent-based models for dynamic passenger assignment modelling of congestion dynamics [6] and station closures [7]. At the same time, other research has looked at schedule optimization during disruptions, focusing on system-wide rolling stock rescheduling [8] and the effects of passenger advice [9], train trip short-turning based on estimating the duration of a disruption [10], or train trip re-timing and changing stop sequences [11]. For further work on schedule optimization, we refer to the review on rail schedule optimization in [12]. Despite the exhaustive list of work, the effects of passenger demand uncertainty and severe system disruptions on system performance has found little attention. The overarching aim of our ongoing work is to find flexible strategies that can enhance the resilience of urban rail systems, while explicitly accounting for the uncertainties in the system. Here, we present our initial stages of developing a simulation test bed and testing control strategies for disruption recovery. Moreover, we present the effects of demand uncertainty on the system performance.

2

Simulation-Based Disruption Analysis

The starting point is an urban rail simulation testbed consisting of a network with station nodes, line links, and travelling passengers. In what follows, we describe the basic structure of the simulation, the measure of performance, and a more detailed description of the simulation inputs and optimization approach. 2.1

Urban Transit System Model

Every line of the rail network has varying routes that define the exact stop sequence that a train follows when dispatched into the network. Trains operate along their routes according to their assigned trip schedule information, defining the time of first dispatch at their starting station, travel times between stations, as well as dwell times at stations.

Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems

131

Passenger inflow is controlled according to a specified access rate per origin station. The passenger origin-destination (OD)-matrix consists of the choice probabilities for a particular destination given an origin. When accessing a station, every passenger chooses a destination according to a categorical choice model that incorporates the OD-matrix probabilities. Passenger route choice assumes the shortest-travel-time path between the origin and destination. All system elements are implemented as agents – One agent for every train and every passenger, and a single agent for the system controller. The passenger and train agents are able to interact with each other, such that passenger invehicle travel times are governed by the train operations (i.e., a train delay will also result in an arrival delay of on-board and waiting passengers). Moreover, the simulation incorporates a disruption generator, that triggers station closures or track disruptions. Station closures do not allow any passenger ingress, egress, or transfer, and trains pass through the station without alighting or boarding passengers. Directional track disruptions cause impassable tracks either along links or at stations, such that any train upstream of the disruption location cannot traverse and pass through, whereas trains downstream of the location can continue to travel. Incident reports about the location of these disruptions are relayed to the system controller, who makes decisions on ensuing system alerts (i.e., passenger announcements). The passenger announcements include information on which stations or which lines have been closed. Line closure information includes all routes affected by the track disruptions. The controller can react with control actions. In this analysis, the possible control actions are restricted to adjusting the train headway (i.e., the time interval between consecutive trains) – the control parameters are the train dispatch headway and the duration of the window during which to adjust the headway. The passengers process the information they receive from the system controller and decide if they either stick with their current itineraries or re-route. These decisions depend on whether a passenger is affected by a disruption and whether re-routing the itinerary is possible. If the passenger is unaffected by a disruption, they will proceed with their current itinerary as planned. However, if the disruption does affect the passenger, one of three options exist: (1) replan their itinerary; (2) proceed to the furthest possible station on the current itinerary; (3) or exit the system at the next possible station. If the original destination or a destination within its vicinity is reachable, the affected passenger will always choose to re-route their itinerary. Only if the destination station is unreachable, the passenger will decide to continue until the furthest reachable station on the current itinerary. If the passenger cannot reach any further on the current itinerary, they will exit the system at the next possible station. Passengers are also able to observe disruptions if they are immediately affected, even if the system controller has not announced any alerts for the particular station or line. For instance, a passenger transferring to a station that just closed, will recognize that the station is closed and will find a different journey itinerary according to the same decision criteria mentioned above under items (1) to (3).

132

S. O. P. Blume et al.

All other passengers will be unaware of the station closure until the controller announces an alert. Passengers make egotistic re-routing decisions, that is, re-routing decisions of individual passengers are not influenced by the decisions of other nearby passengers and vice versa. Future and extended work could consider interactions between passengers and how the decision of one passenger affects “neighboring” passengers’ decisions. 2.2

The Objective Function – Minimization of Aggregated Delays

The system level of service is measured as an aggregate travel delay penalty summed over all passengers. The total travel delay penalty Ψt , normalized by the total number of simulated passengers P , is computed at the end of the simulation run according to    1  Ψt = ψc + ψi , (1) P Pc

Pi

where Pc is the set of passengers, who have completed their trip by the end of the simulation run time, and Pi is the set of passengers, who have not reached their destination by the end of the simulation run time. Respectively, ψc is the travel delay penalty due to completed passenger trips, and ψi is the travel delay penalty due to incomplete passenger trips. Since passengers re-route their itineraries according to the disruption information they receive, they may choose to find a new destination d∗ that is located within a specified radius from the original destination d. We thus distinguish between passengers who have reached or are on their way to their original destination and those who have re-routed to a new destination. The contribution to the total travel delay penalty from a completed passenger trip is defined as  (tod∗ − tod ) , if d∗ = d, ψc = (2) |tod∗ − tod |, if d∗ = d, where tod∗ denotes the actual travel time between origin o and the completed journey destination d∗ , and tod denotes the expected travel time between the origin and the originally planned destination d. If a passenger exits a station that is not the originally planned destination, it can happen that the travel time to the re-routed destination is shorter than the expected. In this case, we assume that the remaining time (i.e., penalty) to get to the originally planned destination is at least the difference between the expected travel time and actual travel time. Hence, we use the absolute value in Eq. (2). The travel delay penalty due to a passenger trip that has not completed by the end of the simulation run time is defined as  (to• + t• d∗ − tod ) , if d∗ = d, (3) ψi = |to• + t• d∗ − tod |, if d∗ = d,

Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems

133

where to• is the current travel time of the passenger when the simulation ends, and t• d∗ is the expected remaining travel time from the current location to either the re-routed or original destination d∗ The objective is to minimize the total travel delay penalty by informing passengers about station or line closures so they can re-route their itineraries and implementing control strategies such as adjusting the train headway on selected lines to increase passenger throughput. 2.3

The Simulation Inputs and Optimization Framework

The simulation builds on the discrete-event simulation library SimPy [13] and is programmed in Python 3.6. The simulation reads in train schedule information from GTFS (General Transit Feed Specification) schedule data [14]. Additionally, station-level passenger inflow rates need to be defined at the desired time granularity. Similarly, the simulation requires a pre-defined OD-matrix to generate a destination choice for every passenger entering at a specified origin. The route choice model implements the RAPTOR (Round-based Public Transit Optimized Router) algorithm [15] to generate the shortest travel path between every OD-pair at a given departure time. We modified the RAPTOR algorithm to include station or route-closure information. The aim of this analysis is to find the optimal parameter values for the train headways that minimize the total time penalty of completed and incomplete trips in the event of a disruption. The optimization process is carried out via a metamodel-based bayesian optimization approach [16]. The metamodel is a multi-dimensional Gaussian Process (GP) regression model [17], with multiple input features and a single output variable. The input features are parameter values for the train headway and control window duration for each of the considered routes. The output is the total time penalty at the end of the simulation run. The Gaussian Process prior covariance is a multi-dimensional Matern kernel [17]. The metamodel-based optimization starts with a predefined number of presample points of the parameter values, generated from a Latin-Hypercube design and maxi-min Monte Carlo optimization of the distance between sample points. The simulation is run on these pre-sample points and the GP model is fit to the output. To find the next sample point of parameter values, the method uses an acquisition function that measures the utility of a new sample point by trading off parameter space exploration with finding the optimal values. In this analysis we define the acquisition function in terms of the expected improvement. The new-found sample point is put through the simulation to generate the next output to be appended to the ensemble of previously determined samples. The optimization process then repeats.

3

The Test Network and Test Cases

The test network is a reduced set of lines belonging to the New York City (NYC) subway system [18]. The reduced network layout is shown in Fig. 1a. Trains operate according to the openly accessible trip schedule information provided

134

S. O. P. Blume et al.

Fig. 1. Test network consisting of 4 lines and 104 stations. The map in (a) shows the full network layout; (b) shows the boxed frame in (a), indicating the disruption locations and timings.

by the Metropolitan Transport Authority (MTA) of NYC [18]. Some of the trip schedules are modified to be less frequent to account for the reduced set of lines as well as to demonstrate more succinctly the effects of disruption mitigation measures. Passenger inflow data is gathered and processed from the published turnstile counts at every station of the NYC subway system [19]. The actual entry count data are scaled by a factor of 10−2 to reduce the number of passenger agents and keep computational cost in check. Consequently, train capacities are also reduced by a factor of 10−2 , i.e., from 1500 to 15 passengers. The passenger origin- destination (OD) matrix is based on an estimation model that maps between the historical entry and exit counts to find an estimate for every OD probability coefficient. The simulation runs a two-hour window, starting at 8:00 am on a typical weekday. During the simulation run time, we trigger an arbitrary unplanned disruption scenario predominantly affecting the southbound direction of line F in Fig. 1. Namely, a station disruption (i.e., the station is inaccessible by passengers) is reported at 8:30 am at station D15 (“47–50 Streets - Rockefeller Centre”), along with a southbound track disruption (i.e., a disrupted track does not allow any trains to pass through the link) between stations G14 (“Jackson Heights - Roosevelt A venue”) and B04 (“21st Street - Queensbridge”). The link disruption is unidirectional; that is, the northbound tracks from station B04 to G14 remain in service. Both the station closure and track disruption last for one hour. Figure 1b shows the locations of the disruptions and their timings. The controller alerts passengers about the station and line closures 400 s after the first incident report is collected, whereas control actions are executed instantaneously when disruptions occur. The particular control actions enforced in this test network involve the train dispatch headway on lines G and 7, and the duration of the schedule adjustment. The reduced sub-network and disruption scenario are hypothetical. By slicing the full-scale network down to the sub-component, we disregard process

Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems

135

interactions that would otherwise exist with the remainder of the full-scale network. Simulation results were not validated against a real-world scenario, since reliable real-world validation data is only available for the full-scale network. Nonetheless, this test case serves to demonstrate the approach and informs scalable strategies to implement into to the full-scale network.

4

Results and Discussion

The proceeding results analysis considers four cases. In all cases, the station-level passenger inflow rates are time dependent. The rates vary in 5-minute intervals according to the measured and processed count data at each station. Case 1 defines the baseline result. It models the undisrupted network and resulting passenger flow to gain an understanding of the “typical” network operations. Case 2 assesses the impact of the disruption on the passenger link flow levels under two different passenger behavior assumptions: (i) in the first instance, passengers are unaware of any disruptions in the network, and proceed along their itineraries as planned, waiting and travelling on trains as they arrive; (ii) in the second instance, passengers re-plan their itineraries once they either observe a disruption or they receive an alert announcement. Case 3 uses the passenger re-planning assumption in Case 2 (ii). Additionally, Case 3 assesses how train headway adjustment on selected routes can improve the passenger service level during the disruption, given that passengers will re-route through those routes that are unaffected by the disruption. Case 4 discusses the effect of passenger demand uncertainty on the system performance. The system is analyzed under the same disruption scenario as in Case 1 through to 3. However, Case 4 places a negative binomial distribution over the time-dependent station-level inflow rates to introduce an additional noise component. The inflow rates are taken as the mean parameter of the negative binomial distribution. The negative binomial dispersion parameter is fixed to φ = 0.01. Another source of demand uncertainty arises from the destination choice model. Every passenger chooses a destination according to a categorical distribution, given their origin station and corresponding probabilities in the ODmatrix—In Case 1 through to 3, the random seed for the destination choice model is fixed to produce repeatable samples. Other sources of demand uncertainty, such as the possibility to choose from different route options, or operational uncertainties such as train travel times between stations, are not considered in this analysis. 4.1

Case 1: The Undisrupted Network

The simulated two-hour window results in 1632 passengers trips. Figure 2 shows the total southbound link flow levels summed over the two-hour simulation window under undisrupted conditions. Under the normal undisrupted operations, the travel delay penalty Ψt is 54 s per passenger.

136

S. O. P. Blume et al.

Fig. 2. Southbound link flow levels in the undisrupted network. The circular arrow indicates the southbound flow directions. The indicated numbers are the flow levels (passengers/2-h) on selected link segments of the F, 7, G, and L line, respectively.

4.2

Case 2: Link Flow and Travel Delay Under Disruptions

When modelling the effect of a disruption on the transit system performance, the assumed travel behavior of passengers has significant influence on the resulting aggregate passenger flows and performance metrics. The diagrams in Fig. 3a and b illustrate the consequences of the two different assumption scenarios during disrupted conditions. Northbound flows are not shown as they are only marginally affected by the disruptions. By assuming that passengers will not re-plan their itineraries, the southbound link flow on line F in Fig. 3a noticeably reduces under disrupted conditions. This is owed to the fact that the southbound tracks on line F are disrupted for an hour, hence not allowing any trains to move southbound upstream of the disrupted link. Since passengers do not re-plan their itineraries, fewer passengers travel through the affected location during the simulated time window. The total travel delay penalty is Ψt = 775 s per passenger under no-re-planning. Conversely, under the assumption that passengers can re-plan their itineraries, the passenger flow re-distributes considerably. Particularly, the total link flow on the green G line in southbound direction in Fig. 3b noticeably increases. Moreover, the southbound flow on line 7 on link sections parallel to the disrupted section of line F reduces. Overall, the total travel delay penalty increases to Ψt = 810 s per passenger, if passenger re-plan their itineraries. We note that the travel delay penalty is larger if passengers change their itineraries (Ψt = 810 s), versus holding on to their original itineraries and waiting for the disruption to cease (Ψt = 775 s). On the one hand, this reflects the effects of the model assumptions by virtue of the longer travel durations along re-planned paths versus the longer wait times at stations. On the other hand, it informs the design of control strategies regarding how to react during the disruption scenario. In fact, these results suggest that recommending to passengers to re-plan their itineraries will result in an overall larger travel delay penalty with the current system schedule and disruption scenario in effect. This is in line

Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems

(a) Disrupted network, No re-planning

137

(b) Disrupted network, Re-planning

Fig. 3. Southbound link flow levels under disrupted conditions. Pane (a) shows the link flow under the assumption that passengers stick to their itineraries; Pane (b) assumes that passengers re-plan their itineraries when receiving a disruption alert.

with other work which showed that real-time information provision in disrupted networks can result in negative effects on passenger welfare [3]. 4.3

Case 3: Optimizing the Train Headway

In Case 3, passengers re-plan their itineraries as a result of the controller decision to close line F in southbound direction and the station closure at 47–50 Streets Rockefeller Centre. We observe that these disruptions along line F cause significant changes in link flow levels along southbound G and 7 trains, due to passengers re-routing their journeys. Moreover, re-routing passenger itineraries result in an increase in the overall travel delay penalty as seen in Sect. 4.2. Consequently, our objective is to test whether adjusting the train headway on lines G and 7 can reduce the travel delay penalty, given that passengers replan their itineraries along these routes. We devise an optimization procedure that aims to minimize the total travel delay penalty per passenger, by finding the optimal adjustment of the train headways on lines G and 7. The headway is adjusted in both north- and southbound direction, minding that a limited number of trains are available per line and dispatching trains in one direction from a terminal that is not connected to a depot requires that trains arrive in time from the other direction. We follow the Bayesian simulation-based optimization approach described in Sect. 2.3. First, we create 5 Latin-Hypercube pre-samples and run the Bayesian optimization routine for 100 iterations. The headways can vary between 2 to 20 min. The duration of the schedule adjustment per line and direction is constrained between 0 min to 1 h. The optimized schedules are illustrated in Fig. 4. It shows the original and new dispatch times of trains in north- and southbound directions along lines G and 7. For line G, the optimized headways are 2 min over a window of approximately 6 min in both directions. The adjusted headway on line 7 is approximately

138

S. O. P. Blume et al.

Fig. 4. The optimized train dispatch schedule for lines G and 7 in both north- and southbound direction. Route identifiers indicate the line, direction, and additional route stop sequence specification (e.g., “7N2” stands for line 7, northbound, stop sequence 2). For line 7, the headway is adjusted to the same interval on all routes that go in the same direction. Blue squares mark the pre-disruption scheduled dispatch times; magenta circles mark additionally injected trains recommended by the optimization for obtaining the desired headway; red crosses represent trains in the original schedule that are cancelled; finally, green triangles mark the realized dispatch times – the realized dispatch times can be different from the scheduled or injected dispatch times, given the possible unavailability of trains at depots; here, all scheduled and injected trains are dispatched as planned, except the first scheduled trains during the disruption window. Vertical dashed lines indicate the start and end of the disruptions on line F.

5 min over a 30-min window in northbound direction, and 10 min over a 40-min window in southbound direction. Therefore, the original schedule is restored 40 mins after the disruption. The optimized schedule reduces the total travel delay penalty to Ψt = 695 s. The optimized schedule and passenger re-planning outperforms the strategy of not recommending to passengers to re-route (Ψt = 770 s with the adjusted schedule), as well as reduces the travel delay penalty with respect to the original schedule (Ψt = 810 s). 4.4

Case 4: Effects of Passenger Demand Uncertainty

Figure 5 plots the variation of the total travel delay penalty Ψt , due to the uncertainty in passenger demand. The boxplots are based on 100 Monte Carlo runs for each of the assumptions in Case 2, assuming either passenger re-planning (Case 2(ii)) or not (Case 2(i)), and Case 3, which assumes passenger re-planning and the optimized schedule. The uncertainty stems from variation in passenger inflow at stations, and the categorical destination choice model. Figure 5 shows that the total travel delay considerably varies in all cases, independent of whether we assume passenger re- planning or not, or put in effect the optimized schedule. However, the optimized schedule with adjusted train headway consistently reduces the total travel delay. The variation in system performance highlights the “flaw of averages” [20], and underscores that optimizing the system and schedules should consider the inherent passenger demand uncertainty. Flexible strategies that adapt to the changing system condition and performance requirements could potentially perform better in dealing with this uncertainty. However, this flexibility requires

Dynamic Disruption Simulation in Large-Scale Urban Rail Transit Systems

139

Fig. 5. Boxplots of the system performance uncertainty, measured in terms of the variation of the total travel delay penalty Ψt . The plots differentiate between three scenarios: Case 2(i): The original default schedule and no passenger re-planning; Case 2(ii): The original default schedule including passenger re-planning; and Case 3: The optimized schedule including passenger re-planning.

enablers, such as the necessary control systems and system architectures to swiftly implement actions such as the analyzed headway adjustment or other strategies such as short-turning, expressing, or dead-heading.

5

Conclusion

We present a simulation-based approach to model the dynamic re-routing of passengers and train schedule adjustment during disruptions in an urban rail transport system. Based on a small-scale test network, we demonstrate an optimization procedure to adjust train dispatch schedules and reduce the impact of disruptions. We show that it is possible to reduce the total travel delay penalty by adjusting the train headway on selected train routes. We assume that passengers re-route due to real-time disruption alerts, as well as consider rolling stock constraints regarding the available trains for dispatch and train on-board capacities. At last, we show that demand uncertainty considerably changes the resulting travel delay penalty. Nonetheless, the adjusted train headway reduces the overall travel delay even under demand uncertainty. Ongoing work involves finding flexible designs that explicitly include the demand uncertainty together with controller uncertainty and imperfect vehicle operations into the optimization of train operations and network architectures to further reduce the performance draw-down and augment the recovery process during disruptions.

References 1. Cats, O.: Dynamic modelling of transit operations and passenger decisions. Ph.D. thesis. KTH - Royal Institute of Technology, Sweden (2011) 2. Cats, O., Koutsopoulos, H.N., Burghout, W., Toledo, T.: Effect of real-time transit information on dynamic path choice of passengers. Transp. Res. Rec. 2217(1), 46– 54 (2011) 3. Cats, O., Jenelius, E.: Dynamic vulnerability analysis of public transport networks: mitigation effects of real-time information. Netw. Spat. Econ. 14(3–4), 435–463 (2014)

140

S. O. P. Blume et al.

4. Cats, O., Jenelius, E.: Planning for the unexpected: the value of reserve capacity for public transport network robustness. Transp. Res. Part A 81, 47–61 (2015) 5. Cats, O., West, J., Eliasson, J.: A dynamic stochastic model for evaluating congestion and crowding effects in transit systems. Transp. Res. Part B 89, 43–57 (2016) 6. Othman, N.B., Legara, E.F., Selvam, V., Monterola, C.: A data-driven agent-based model of congestion and crowding effects in transit systems. J. Comput. Sci. 10, 338–350 (2015) 7. Yin, H., Han, B., Li, D., Wu, J., Sun, H.: Modeling and simulating passenger behavior for a station closure in a rail transit network. PLoS ONE 11(12), e0167126 (2016) 8. Kroon, L., Mar´ oti, G., Nielsen, L.: Rescheduling of railway rolling stock with dynamic passenger flows. Transp. Sci. 49(2), 165–184 (2014) 9. Hurk, E.v.d., Kroon, L., Mar´ oti, G.: Passenger advice and rolling stock rescheduling under uncertainty for disruption management. Transp. Sci. 52(6), 1391–1411 (2018) 10. Ghaemi, N., Zilko, A.A., Yan, F., Cats, O., Kurowicka, D., Goverde, R.M.P.: Impact of railway disruption predictions and rescheduling on passenger delays. J. Rail Transp. Plan. Manag. 8, 103–122 (2018) 11. Zhu, Y., Goverde, R.M.P.: Railway timetable rescheduling with flexible stopping and flexible short-turning during disruptions. Transp. Res. Part B 123, 149–181 (2018) 12. Cacchiani, V., Huisman, D., Kidd, M., Kroon, L., Toth, P., Veelenturf, L., Wagenaar, J.: An overview of recovery models and algorithms for real-time railway rescheduling. Transp. Res. Part B 63, 15–37 (2014) 13. Scherfke, S., L¨ unsdorf, O.: SimPy. https://bitbucket.org/simpy/simpy/src/ default/. Accessed 23 May 2019 14. The General Transit Feed Specification. https://www.gtfs.org/. Accessed 23 May 2019 15. Delling, D., Pajor, T., Werneck, R.F.: Round-based public transit routing. Transp. Sci. 49(3), 591–604 (2014) 16. Frazier, P.I.: A tutorial on Bayesian Optimization, pp. 1–22. arXiv 1807.02811v1 (2018) 17. Rasmussen, C.E., Williams, C.K.I.: Gaussian Processes for Machine Learning. MIT Press, Cambridge (2006) 18. Metropolitan Transport Authority, MTA Static Data Feeds. http://web.mta.info/ developers/developer-data-terms.html#data. Accessed 23 May 2019 19. Metropolitan Transport Authority, Turnstile Data. http://web.mta.info/ developers/turnstile.html. Accessed 30 Aug 2018 20. Savage, S.: The Flaw of Averages, San Jose Mercury News (2000)

A Multiobjective Systems Architecture Model for Sensor Selection in Autonomous Vehicle Navigation Anne Collin1(B) , Afreen Siddiqi1 , Yuto Imanishi2 , Yukti Matta3 , Taisetsu Tanimichi4 , and Olivier de Weck1 1

3

Massachusetts Institute of Technology, Cambridge, MA 02139, USA [email protected], {siddiqi,deweck}@mit.edu 2 Hitachi America, Ltd., Farmington Hills, MI 48335, USA [email protected] Hitachi Automotive Systems Americas, Inc., Farmington Hills, MI 48335, USA [email protected] 4 Hitachi Automotive Systems, Ltd., Hitachinaka, Ibaraki 312-8503, Japan [email protected]

Abstract. Understanding and quantifying the performance of sensing architectures on autonomous vehicles is a necessary step towards certification. However, once this evaluation can be performed, the combinatorial number of potential sensors on the vehicle limits the efficiency of a design tradespace exploration. Several figures of merit emerge when choosing a sensor suite; its performance for a specific autonomy task, its monetary cost, energy consumption, and contribution to the latency of the entire system. In this paper, we present formulations to evaluate a sensor combination across these dimensions for the localization and mapping task, as well as a method to enumerate architectures around the Pareto Front efficiently. We find that, on a benchmarked environment for this task, combinations with LiDARs are situated on the Pareto Front.

1

Introduction

Over the past few years, many agencies and private companies have announced plans to leverage autonomous vehicle technology to improve our transportation networks. The great safety implications posed by the use of autonomous vehicles in open environments prompts a robust quantification of their performance. Concurrently, automotive manufacturers face cost pressure, driving the choice of components on the vehicle. In the context of company-owned vehicles operated together as a fleet, the environment cars drive in, as well as the routes they take, can be controlled. The sensors used on the car for many different functions, such as obstacle recognition or scene recognition, can therefore be adjusted to the environment the vehicle is supposed to drive in. Intuitively, current car prototypes carry a combination of sensor types, such as LiDARs, radars, and camera systems, facing different c Springer Nature Switzerland AG 2020  G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 141–152, 2020. https://doi.org/10.1007/978-3-030-34843-4_12

142

A. Collin et al.

directions, in order to create redundancy and maximize sensory input. This sensor architectural choice is also influenced by system level metrics; cost, energy consumption rate, and data rate influencing the system’s latency. However, there currently exists no model to quantify the trade-offs between these different figures of merit, and to explore the architectural space efficiently without enumerating all potential solutions. This papers offers such a model for the navigation task of the vehicle. After the literature review in Sect. 2, a methodology to obtain satisfactory sensor architectures is presented. First, the evaluation Sect. 3.2, gathers techniques from different fields to produce quantifiable figures of merit. Second, the enumeration Sect. 3.3, extends recent advances in submodular function optimization to multiobjective optimization and trade-off analysis, with guarantees on the quality of the proposed solution. Resulting architectures are shown in Sect. 4.

2 2.1

Related Work Systems Approaches to Autonomous Vehicle Architecture

The multi-disciplinary nature of autonomous vehicle systems calls for system methods to quantify their overall performance and safety [1]. System architecture models support decisions involving the selection of components in the system [2]. In this work, we are interested in the sensor selection problem for the Simultaneous Localization and Mapping (SLAM) function in an autonomous vehicle. Choosing a subset of sensors among a list of candidates is a combinatorial problem [3], for which a solution cannot be found in a polynomial amount of time. [4] develops a vehicle architecture model, where latency is minimized under safety and reliability constraints, using functional task assignments as design variables. However, sensors are absent from this model. Sensor architectures need to be adapted to the driving environment [5], nevertheless there exists few models that assess efficiently sensor choice and placement on autonomous vehicles. [6] provides a method to evaluate different sensor combinations, but does not offer a method to enumerate efficiently a large number of designs. 2.2

Sensor Evaluation and Selection

The ability to evaluate a proposed architecture is crucial to the systems architecture process for two reasons; first, it is necessary to set relevant requirements for the architecture. Second, a growing performance indicates that the space search is progressing towards improving designs [7]. The following paragraphs draw on literature from different fields to present the evaluation of sensor systems with regards to two of the metrics of interest: SLAM performance and latency. SLAM Performance. An autonomous system needs to estimate its position in the world along with the position of landmarks in its environment [8], but

Multiobjective Sensor Selection for SLAM

143

GPS information is unfortunately at times not available in urban settings [9]. Sensors installed on the car enable the detection of landmarks in the environment, leading to an estimate on the car’s ego position and landmark positions. This estimate is updated as more measurements come through the sensors. The accuracy of the position estimate is assessed through its comparison with the ground truth of the car and landmark positions [10], however this ground truth is usually not available when driving in open environments. Alternatively, sensor systems can be characterized by the precision they yield, meaning the amount of uncertainty around the estimate. Assuming that the probability distribution is centered around the real value, the smaller the uncertainty volume around the estimate, the more precise the estimation is. The size of the uncertainty ellipsoid is captured by the determinant of the covariance matrix, the equivalent of the D-optimality criterion in Bayesian experimental design [11]. This evaluation metric has been exploited more in details in [12], due to its monotonous, submodular nature, a property which will be detailed further in the methodology. Latency. This metric is defined as the time between the start of the first task and the first time the last task produces an output. It is assumed to be approximated as a deterministic quantity based on a small number of metrics influenced by sensors, such as memory capacity. The choice of sensors has an influence on the system’s latency through the amount of information they send to the system. A trade-off already emerges from these two first figures of merit; an additional sensor brings more information on the landmark positions and reduces uncertainty, but also increases computation time. This might slow the control actions of the car to a point where it becomes unsafe. For the purpose of the evaluation performed in this work, the physics of this system have been simplified to a linear function described in [13,14]. In our model, the specific attributes through which sensors influence latency are Random Access Memory (RAM) requirements and clock cycle. For example, A SLAM estimation algorithm using information from more sensors will have a higher clock cycle. This algorithm’s output is needed to compute the path the car is supposed to take. A slow position information message corresponds to old information for the path planner. The choice of processing hardware can reduce the overall latency, for the same given set of sensors, which is taken into account in the presented model. Thus, RAM requirements and clock cycle are the two metrics used in this work to capture latency. Sensor Selection Problems. Sensor selection topics have been explored in other fields. [15] proposes a method to select an optimal sensing architecture to monitor the health of complex systems. [16] presents a convex relaxation to find the set of sensors minimizing the size of the uncertainty ellipse. The design variables can be individual measurements [17], or sensors themselves [12]. Submodularity, described in the enumeration methodology section, is a key property leveraged in recent sensor selection problems [18].

144

3

A. Collin et al.

Methodology

This section shows which sensors can be selected in our combination, followed by the equations to assess the performance of a given sensor combinations for our four metrics. Finally, a method to explore the sensor combination tradespace is presented. 3.1

Sensor Library

Since different types of sensors lead to different measurement noise characteristics, three types of sensors are considered herein: radars, LiDARs, and stereo cameras. The sensor library presented in Table 1 contains realistic sensors; the information source for each model is included in the table. Table 1. Attributes of considered sensors (*Field of View). The energy consumption listed here is referred to as passive energy in this work. Sensor

Range (m) FOV* (rad) Cost ($) Energy (W) Source

Mid-Range Radar

160

0.1

2,830

6.6

[19]

Long-Range Radar

250

0.0698

1,493

4.5

[20]

Long Range LiDAR

120

2π

100,000

60

[21]

Mid-Range LiDAR

100

2π

4,000

8

[22]

Wide angle stereo cam

50

π/2

2,990

5

[23]

HD2K stereo cam

20

1.33

449

2

[24]

Low res. stereo cam

20

1.52

449

2

[24]

Radars are characterized by a long range and a narrow field of view. LiDARs have a 360◦ field of view, but can be really expensive and with a high energy consumption. LiDARs and radars provide direct information about depth and bearing for a landmark. For stereo cameras, these attributes need to be calculated from the image input, and have a depth-dependent noise characteristic: the further the landmark, the higher the noise. Additionally, each sensor type but the LiDARs, can be placed facing any of twelve cardinal directions on the car; for example, 11 o’clock to 1 o’clock represent a front placement on the car. The sensor library is therefore composed of sensor (type, placement) pairs, thus containing 62 elements. A sensor provides range and bearing information about a landmark if it falls within the sensor’s range and FOV. 3.2

Evaluation

SLAM Performance. The precision of the SLAM estimate is evaluated through the volume of the uncertainty ellipsoid, which is captured by the log

Multiobjective Sensor Selection for SLAM

145

determinant of the covariance matrix between all unknowns [25]. Factor graph models provide a modular representation of the SLAM problem [26], and rapid inference capabilities. Figure 1 shows the link between the addition of a sensor and the factor graph. A sensor provides information about l2 from pose x1, which updates the estimate on x1. When l2 is seen again from x2, this information is used together with the previous information about l2 to update both the l2 and x2 estimates. The graph grows with the number of measurements. The sparsity pattern of I, the SLAM system information matrix, is the adjacency matrix of the graph considering factors as undirected edges, thus its log determinant changes with the addition of measurements through sensors on the vehicle [27]. The log determinant of the information matrix I = Σ −1 is easily accessible via a sum of diagonal elements [27]. Minimizing the size of the uncertainty ellipsoid is equivalent to maximizing the log determinant of the information matrix.

Prior factor φ Inertial odometry factor ψ

l1

l2

Range & bearing factor ρ

m ρ1,1

φx0

x0

ψ0,1

x1

l ρ1,2

ψ1,2

m ρ2,2

x2

Fig. 1. Factor graph representing three car poses and two landmarks. Poses are connected via odometry factors, while landmarks and the poses are correlated through range and bearing measurements provided by sensors. Two distinct types of range and bearing factors are depicted. From [6].

The objective function of the systems architecture model is therefore max

x1 ,...,xk ∈S

J = log det I(x1 , .., xk )

(1)

where k potential sensors are available, and {xi } is a binary variable representing the selection of sensor i. Latency. RAM usage and clock cycle are used here to capture the notion of latency induced by different sensor selections. RAM stores the dynamic variables of the SLAM problem. The higher the range and Field of View (FOV) of a sensor, the more measurements it performs, regardless of its noise levels. The variables stored in our representation of the SLAM model are the vehicle states variables X, 3 degrees of freedom, and the landmark measurements L, 2 degrees of freedom. If the vehicle travels through np poses, that there are nl landmark positions to estimate, and its sensor combination yields m measurements; (3 · np + 2 · nl )2 + m variables are stored. The

146

A. Collin et al.

variable storage is converted into a RAM requirement, with variables of 4 bytes. The RAM requirement (Mb) is: R(x1 , ..., xk ) = 4 · 10−6 · ((3 · np + 2 · nl )2 + m(x1 , ..., xk ))

(2)

As for the clock cycle required to perform the SLAM inference with a specific sensor combination, this inference is directly performed on a personal computer with a 3,1 GHz Intel Core i7. The inference only uses one thread, and the CPU time is recorded at each evaluation. The clock cycle (-) is: C l(x1 , ..., xk ) = Clock Rate ∗ Cpu Time(x1 , ..., xk )

(3)

Energy Consumption. Three sources of energy consumption are retained in this model to compare the impact of different sensor selections. First, the passive energy of the sensor, as advertized by the supplier. Second, the energy consumption of the memory bank needed to store the data produced by the sensor. Each terabyte of storage consumes about 2.67 W of energy. Third, there is a 77% overhead on energy consumption for cooling [28]. We assume that only the storage bank is inside the car and needs to be cooled. The energy consumption (W) is: k (x1 ,...,xk ) (4) E (x1 , ..., xk ) = i=1 Passive Energy(xi ) + 0.77 ∗ 2.67∗R10 6 Cost. The cost is simply added over the different sensors chosen. The cost ($) is: C (x1 , ..., xk ) =

k 

C(xi )

(5)

i=1

3.3

Enumeration

Submodular Function Maximimization. This paragraph introduces submodular function optimization properties to the systems engineering community, as, to the authors’ knowledge, it has not been used in systems architecture yet. Definition 1. A function f : 2V → R is submodular if for every A ⊆ B ⊆ V and e ∈ V \ B it holds that f (A ∪ {e}) − f (A) ≥ f (B ∪ {e}) − f (B) Submodular functions are defined on a finite space, and exhibit the diminishing returns property. As proven in [29], J, defined in Eq. 1, is submodular monotone. Intuitively, this property indicates that for each sensor added to the architecture, the SLAM performance increases by a smaller and smaller amount. Submodular monotone functions are particularly relevant for systems architecture problems in which the architect adds elements improving the performance by a lower and lower margin while increasing costs. This class of problems exhibits an asymptotic Pareto Front, as notionally depicted in Fig. 2. The submodular function, with design elements of positive

Multiobjective Sensor Selection for SLAM

147

uniform cost, converges to an asymptotical value, shown in grey. The asymptote is the maximum performance the system could ever achieve, constrained by the underlying physics of the system, or a requirement on an ancillary function. In the case of sensor selection, the uncertainty around the system cannot go below 0.

Fig. 2. Notional plot of a Pareto Front generated for a submodular function f.

The optimization problem in Eq. 1 is NP-hard because of its combinatorial nature, even with a constraint. A heuristic, called the greedy algorithm and presented in Algorithm 1, has been proven to lead to solutions within a known bound of the optimal performance [30] for a selection of maximum size l.

Algorithm 1. The Greedy Algorithm Savailable = {x1 , ..., xk } available sensors set Sselect ← ∅ while |Sselect | ≤ l do bestSensor ← arg max f (Sselect ∪ {e}) − f (Sselect ) e∈Savailable

Sselect ← Sselect ∪ {bestSensor} end while

Application to Tradespace Search. Our goal is to map the relationship between the four objectives previously detailed. They are discrete functions, and most of them are non-linear, non convex. Sensor shapes or interactions do not preclude their use with one another, hence the lack of physical constraints in the model. Constraint-satisfaction methods such as conflict directed A∗ [31] would therefore require long computational times to approach a good solution. The lack of constraints can be leveraged by using an evolutionary algorithm such as a genetic algorithm or simulated annealing. However, they both require agile parameter tuning for convergence, and do not provide guarantees to find a solution close to the optimum. As tradespace exploration of sensing architectures for autonomous vehicles is very recent, the lack of intuition and validation data on the optimal behaviour of the system prevents the use of methods that do not provide convergence guarantees.

148

A. Collin et al.

Instead, the intrinsic shape of the SLAM performance function is leveraged, and we use the greedy algorithm for submodular monotone function optimization, which guarantees a near-optimal solution. The greedy algorithm has been presented in its single-objective optimization form, but this paper introduces a method to convert it into a tradespace exploration tool, even though the other metrics are not, themselves, submodular monotone.  A budget constraint on our sensor selection is represented as v∈S c(v) ≤ C for some budget C. The multi-objective optimization problem is re-formulated as performance constrained by RAM usage, clock cycle, energy, and cost: max

x1 ,...,xk ∈S

log det I(x1 , .., xk )

s.t.

R(x1 , ..., xk ) ≤ R, R ∈ R C l(x1 , ..., xk ) ≤ Cl , Cl ∈ R E (x1 , ..., xk ) ≤ E, E ∈ R C (x1 , ..., xk ) ≤ C, C ∈ R

This master problem is then subdivided into 4 different optimization subproblems, one for each constraint [32]. For each of the sub-problems, the greedy algorithm is used to find a near-optimal solution for the constrained problem. The constraints are then relaxed step by step. The search for each of the sub-problems can be ran in parallel. The architectures found independently can be evaluated across all dimensions, populating the tradespace with more points. Even though this technique does not allow the complete mapping of the Pareto front, it provides information about the best architectures in each dimension separately. The relaxation of several constraints at once creates a new combinatorial problem, with the high number of possible combined constraint relaxations, and is therefore not explored here. The non-dominated architectures are close to the five-dimensional Pareto Front.

4

Results

Results are obtained using the greedy algorithm, as well as a cost-benefit variant dividing performance by cost to select the next sensor [33]. The mapped tradespace for our specific sequence, extracted from the KITTI dataset [23], which involves driving straight and a turn to the right, is presented in Fig. 3. In each of the plots, the “cost” of the “cost-benefit” algorithm is adapted to the other metric at play; monetary cost, energy, or one of the latency metrics. They each show the SLAM performance of different architectures as a function of their cost, energy consumption, RAM usage or clock cycle. Each dot represents a sensor combination. For all, ideal architectures are in the upper left corner; good performance, low value for the other metric. The costbenefit variant finds architectures on the bottom of the Pareto Fronts, whereas

Multiobjective Sensor Selection for SLAM

149

Normalized SLAM precision - constraints tradespace 1.0

1.0

0.9

0.9

0.8

0.8

0.7

0.7

0.6

0.6 0.5

0.5 0.4

0.4 0.3

0.3 0.2

0.2 0.1

0.1 0.0 0

40,000

80,000

120,000

160,000

Cost (-)

0.0 0

20

40

60

Cost ($)

80

100

120

140

160

180

200

220

240

260

Energy (W)

1.0

1.0

0.9

0.9

0.8

0.8

0.7

0.7

0.6

0.6

0.5

0.5

0.4

0.4

0.3

0.3

0.2

0.2

0.1

0.1

0.0

0.0 1.72e+6

1.74e+6

1.76e+6

1.78e+6

RAM Usage (Bytes)

RAM Usage (Bytes)

1.80e+6

0.00e+0

8.00e+6

1.60e+7

2.40e+7

3.20e+7

4.00e+7

ClockCycle (-)

Clock Cycle (-)

Fig. 3. Architectures generated by the uniform (orange dots) and the cost-benefit (blue dots) greedy algorithms for sequence KITTI 03. The y-axes represent normalized SLAM performance. The Pareto front is shown by a red dashed line. The numbers 1, 2, and 3 represent three different architectures, placed in each dimension.

Algorithm 1 finds architectures with a higher SLAM performance on the Pareto Fronts. In Figure (a), the gap between the cost of the Long Range LiDAR and the other sensors explains the gap between architectures around point 3 and the rest of the points on the Pareto Front. The energy consumption difference is lower. The numbered architectures are shown in Fig. 4. Architecture 1 is on the Pareto front for the last two FOMs, but not for energy or cost. It is constituted of 12 Low Resolution stereo cameras placed all around the car, seven High Resolution cameras facing all but the south east direction, five Long Range radars

150

A. Collin et al.

facing front, right, and back. The lack of LiDAR, or expensive stereo camera, makes it a low cost architecture, and the high number of sensors raises its performance to some extent. However, a large amount of stereo cameras costs more, and consumes more energy, than a small LiDAR. RAM usage, and the clock cycle remain smaller than for an architecture with the same SLAM precision containing a LiDAR. Architecture 2 and 3 contain a LiDAR, which raises performance, and all the other metrics. The largest difference between 2 and 3 is the use of the Long-Range LiDAR in 3, increasing mainly cost and energy for a low SLAM performance increase. The higher number of sensors on 2 increase RAM usage to the extent that it is not on the Pareto Front in (c). System requirements would appear in Fig. 3 as horizontal or vertical lines signifying the limits of acceptable performance for each metric. For example, focusing on subfigure (a), if SLAM precision is required to be at least above 0.97, and the acceptable budget is 30,000, then architecture 2 should be chosen. A key conclusion is that, in spite of its cost, the Long Range LiDAR is present on the overall Pareto Front.

Fig. 4. Selected architectures in the tradespace. Green boxes represent stereo cameras (light green for low res, green for wide angle, dark green for HD), yellow boxes are LiDARs, and blue boxes are long range radars, light blue are mid range radars.

5

Conclusion

In this paper, we present a novel method in systems engineering to explore tradespaces with a combinatorial number of solutions, where one of the figures of merit presents a diminishing returns property. This method is applied to sensor selection for localization and mapping in autonomous vehicles, but can be extended to any architecture problem where the Pareto front presents a diminishing slope of constant sign. Even though the greedy algorithms are heuristics, they reach architectures within a known bound of the optimum. Future work entails defining such a metric to quantify the performance of sensing suites for other tasks, such as obstacle recognition.

Multiobjective Sensor Selection for SLAM

151

Acknowledgements. The authors would like to thank Antonio Ter´ an Espinoza, Dr. Vasileios Tzoumas, and Professor Luca Carlone, from MIT.

References 1. Koopman, P., Wagner, M.: IEEE Intell. Transp. Syst. Mag. 9(1), 90 (2017). https://doi.org/10.1109/MITS.2016.2583491 2. Crawley, E., Weck, O.D., Eppinger, S., Magee, C., Moses, J., Seering, W.: MIT Engineering Systems Symposium, Cambridge, p. 30 (2004). http://esd.mit.edu/ symposium/pdfs/monograph/uncertainty.pdf 3. Selva, D., Cameron, B., Crawley, E.: Syst. Eng. 19(6), 477 (2016). https://doi.org/ 10.1002/sys.21370. http://doi.wiley.com/10.1002/sys.21370 4. Zheng, B., Liang, H., Zhu, Q., Yu, H., Lin, C.W.: 2016 IEEE Computer Society Annual Symposium on VLSI (ISVLSI), vol. 2016, pp. 53–58. IEEE, September 2016. https://doi.org/10.1109/ISVLSI.2016.126. http://ieeexplore.ieee. org/document/7560172/ 5. Meng, H., Zhang, W.B.: 2017 IEEE Intelligent Vehicles Symposium (IV), pp. 317– 321. IEEE (2017). https://doi.org/10.1109/IVS.2017.7995738, http://ieeexplore. ieee.org/document/7995738/ 6. Collin, A., Teran Espinoza, A.: 2018 IEEE International Conference on Vehicular Electronics and Safety (ICVES) (ICVES 2018), Madrid, Spain (2018) 7. Ross, A.M., Hastings, D.E.: INCOSE International Symposium, vol. 15, no. 1, p. 1706 (2005). https://doi.org/10.1002/j.2334-5837.2005.tb00783.x. http://doi. wiley.com/10.1002/j.2334-5837.2005.tb00783.x 8. Durrant-Whyte, H., Bailey, T.: IEEE Robot. Autom. Mag. 13(2), 99 (2006). https://doi.org/10.1109/MRA.2006.1638022. http://ieeexplore.ieee.org/lpdocs/ epic03/wrapper.htm?arnumber=1638022 9. Jo, K., Jo, Y., Suhr, J.K., Jung, H.G., Member, S.: IEEE Trans. Intell. Transp. Syst. 16(6), 3377 (2015). https://doi.org/10.1109/TITS.2015.2450738 10. Zhao, Y., Vela, P.A.: 2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp. 1183–1189. IEEE (2018). https://doi.org/10. 1109/IROS.2018.8593641. https://ieeexplore.ieee.org/document/8593641/ 11. Chaloner, K., Verdinelli, I.: Stat. Sci. 10(3), 273 (1995). https://doi.org/10.1214/ ss/1177009939. http://projecteuclid.org/euclid.ss/1177009939 12. Collin, A., Teran Espinoza, A.: arXiv preprint arXiv:1907.08541 (2019). https:// doi.org/10.13140/RG.2.2.11386.24001 13. Collin, A., Siddiqi, A., Yuto, I., Rebentisch, E., Tanimichi, T., De Weck, O.L.: Submitted (2018) 14. Imanishi, Y., Collin, A., Siddiqi, A., Rebentisch, E., Tanimichi, T., Matta, Y.: SAE International, pp. 1–12 (2019). https://doi.org/10.4271/2019-01-0473. https:// www.sae.org/content/2019-01-0473/ 15. Chamov, I., Ranieri, J., Vetterli, M., de Weck, O.L.: 2016 IEEE Aerospace Conference, pp. 1–8. IEEE (2016). https://doi.org/10.1109/AERO.2016.7500713. http:// ieeexplore.ieee.org/document/7500713/ 16. Joshi, S., Boyd, S.: IEEE Trans. Signal Process. 57(2), 451 (2009). https://doi. org/10.1109/TSP.2008.2007095. http://ieeexplore.ieee.org/document/4663892/ 17. Carlone, L., Karaman, S.: Attention and anticipation in fast visual-inertial navigation (2018)

152

A. Collin et al.

18. Krause, A., Leskovec, J., Guestrin, C., VanBriesen, J., Faloutsos, C.: J. Water Resour. Plan. Manag. 134(6), 516 (2008). https://doi.org/10.1061/(ASCE)07339496(2008)134:6(516). http://ascelibrary.org/doi/10.1061/ 19. Bosch: Mid-range Radar Sensor (MRR) (2019). https://www.bosch-mobilitysolutions.com/en/products-and-services/passenger-cars-and-light-commercialvehicles/driver-assistance-systems/predictive-emergency-braking-system/midrange-radar-sensor-(mrr)/ 20. Continental, ARS 408-21 Premium Long Range Radar Sensor 77 GHz. Technical report (2017) 21. Glennie, C., Lichti, D.D.: Remote Sens. 2(6), 1610 (2010). https://doi.org/10.3390/ rs2061610. http://www.mdpi.com/2072-4292/2/6/1610 22. Velodyne: Velodyne LiDAR - Puck (2019). https://velodynelidar.com/vlp-16.html 23. Geiger, A., Lenz, P., Stiller, C., Urtasun, R.: Int. J. Robot. Res. (IJRR) 32, 1231– 1237 (2013) 24. StereoLabs: What is the camera focal length and field of view? (2019). https:// support.stereolabs.com/hc/en-us/articles/360007395634-What-is-the-camerafocal-length-and-field-of-view-25 25. Carrillo, H., Reid, I., Castellanos, J.A.: IEEE International Conference on Robotics and Automation, pp. 2080–2087 (2012). https://doi.org/10.1109/ICRA. 2012.6224890 26. Chiu, H.P., Zhou, X.S., Carlone, L., Dellaert, F., Samarasekera, S., Kumar, R.: Proceedings - IEEE International Conference on Robotics and Automation, pp. 663–670 (2014). https://doi.org/10.1109/ICRA.2014.6906925 27. Dellaert, F., Kaess, M.: Found. Trends Robot. 6(1–2), 1 (2017). https://doi.org/ 10.1561/2300000043. http://www.nowpublishers.com/article/Details/ROB-043 28. Lin, S.C., Zhang, Y., Hsu, C.H., Skach, M., Haque, M.E., Tang, L., Mars, J.: Proceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems - ASPLOS 2018, pp. 751– 766 (2018). https://doi.org/10.1145/3173162.3173191. http://dl.acm.org/citation. cfm?doid=3173162.3173191 29. Tzoumas, V., Jadbabaie, A., Pappas, G.J.: 2016 American Control Conference (ACC), vol. 2016, pp. 191–196. IEEE, July 2016. https://doi.org/10.1109/ACC. 2016.7524914. http://ieeexplore.ieee.org/document/7524914/ 30. Nemhauser, G.L., Wolsey, L.A., Nemhausert, G.L.: Source Math. Oper. Res. 3(3), 177 (1978). https://doi.org/10.1287/moor.3.3.177. http://www.jstor.org/stable/3689488 31. Williams, B.C., Ragno, R.J.: Discrete Appl. Math. 155(12), 1562 (2007). https://doi.org/10.1016/j.dam.2005.10.022. https://linkinghub.elsevier.com/ retrieve/pii/S0166218X06004628 32. Papalambros, P.Y., Wilde, D.J.: Principles of Optimal Design. Cambridge University Press, Cambridge (2000). https://doi.org/10.1017/CBO9780511626418. http://ebooks.cambridge.org/ref/id/CBO9780511626418 33. Leskovec, J., Krause, A., Guestrin, C., Faloutsos, C., VanBriesen, J., Glance, N.: Proceedings of the 13th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining - KDD 2007, p. 420. ACM Press, New York (2007). https://doi.org/10.1145/1281192.1281239. http://portal.acm.org/citation. cfm?doid=1281192.1281239

Simulation Architecture Definition for Complex Systems Design: A Tooled Methodology Jean-Patrick Brunet1(B) , Henri Sohier1 , Mouadh Yagoubi1 , Mathieu Bisquay1 , Pascal Lamothe2 , and Pascal Menegazzi3 1 IRT SystemX, 8 avenue de la Vauve, 91120 Palaiseau, France

{jean-patrick.brunet,henri.sohier,mouadh.yagoubi, mathieu.bisquay}@irt-systemx.fr 2 PSA Groupe, Rueil-Malmaison, France [email protected] 3 Valeo, Paris, France [email protected]

Abstract. For the design of complex systems like in the automotive industry, the use of Model Based Systems Engineering (MBSE) is being considered as a promising solution in order to formalize and communicate information. Numerical simulation is also routinely used as a tool to answer potential design questions that arise. However the link between MBSE and simulation still needs further improvement. In this work, a tooled methodology is proposed in order to enhance the link between system architecture and numerical simulation. In a first step, a solicitation package is formalized and implemented in a SysML-based tool to define the simulation needs. In a second step, a tool that allows to define the simulation architecture and to pilot the execution of the simulation is developed. We show that thanks to the proposed process and exchange format between the system and simulation architects, model reuse and agility is improved in a complex systems design.

1 Introduction 1.1 Context The research presented in this paper was conducted within the AMC project (Agility and Design Margin) which is taking place in the research institute IRT SystemX. One of the main objectives of this project is to propose a tooled methodology for simulation based complex system design. We focus on design questions that can be answered by numerical simulation as this later has been considered as an efficient tool for decision-making in the design of complex systems. The simulation is considered as a complex system that may deviate from the original system it represents. This deviation can be explained by the need to account for different specifications that are specific to the simulation. Such specifications might be the implementation of physical phenomena or balance between accuracy and speed for example. The complex task of linking system and simulation architecture led to the emergence of a fairly new role, the simulation architect [1]. The simulation architect has a key role in the proposed methodology as he interprets the needs © Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 153–163, 2020. https://doi.org/10.1007/978-3-030-34843-4_13

154

J.-P. Brunet et al.

from the system architect in order to specify a suitable simulation that would provide the required results for decision. In a standard V-Model (Fig. 1) multiple needs can be expressed during the design phase and the simulation architect will need to answer each of those within the context of the system. The global process begins with the definition of high level stakeholders needs. Then, the system architect defines the system architecture by developing SysML diagrams at the operational, functional and physical levels. Following the need in terms of simulation, the system architect formulates his solicitation to the simulation architect based on a formalism that we have proposed in a previous work [2]. This solicitation package would contain the system information as well as required initial QCD (Quality Cost Delay) requirements for the simulation. Once received, the simulation architect constructs the elements of the simulation architecture progressively, using the new methodology we propose in this paper. If needed, he will interact with the system architect to alter the initial requirements to better match the simulation possibility and system needs. The resulting simulation is then integrated in a simulation framework connected to a decision support tool. This serves a double purpose, analyzing and post-treating the results of the simulation with a close collaboration between the system and simulation architects and if needed, generating new results with minor modifications of the specification (e.g.: minor change of actuation distance etc.…). Once the collected data are sufficient, the system architect can take the final decision and the process end. In the AMC project different industrial partners (PSA group, Renault, Valeo, Airbus) and software providers (Sherpa engineering, Digital Product Simulation, Siemens) are involved in defining and improving the proposed process. For this, a practical design problem is used: The early design of an autonomous vehicle passing traffic light.

Fig. 1. Details of the simulation based decision cycle in a system V-model.

1.2 Industrial Problem One of the two industrial problems considered in the project AMC is the design of an autonomous vehicle which can pass traffic lights. Such industrial problem is important as it allows the different partners of the project to share a common language, to identify

Simulation Architecture Definition for Complex Systems Design

155

the current needs in terms of methods and tools, and to validate new solutions. The considered vehicle has a sensor which provides the color and the distance to a traffic light within a certain range subject to uncertainties. The vehicle then follows a control algorithm to adapt the speed to the traffic light and anticipate possible color changes. The speed is reduced when approaching the traffic light to avoid brutal or even unreachable decelerations. Furthermore, when the color of the traffic light changes to orange, the vehicle stops if it cannot pass the traffic light within one second. In the use case considered in this paper, the system architect defined four parameters: two for the characterization of the sensor and two for the control. Setting those parameters impacts two important decision criteria: the cost of the sensor and the total energy consumption of the vehicle. The system architect formulates the design question as a multi-objective optimization problem and transfers the solicitation package to the simulation architect, who will design the simulation architecture, perform said simulation(s) and provide the results to the system architect in order to take a decision regarding the design of the vehicle.

2 Agility in Complex Conception Cycle As mentioned in the previous section, the system architect will regularly request simulation to obtain sufficient data in order to take decision. In some cases the link between system engineering and simulation is very direct, with no important change between system and simulation architectures. In the STIMULUS tool [3] formal textual requirement and state diagrams can be tested using random variables, and CIL4Sys applications [4] allow testing of formal sequences and state diagrams through on the shelf or simple plant simulation models and user defined environments. However, complex simulation models are often required for the representation of physical systems with both controls laws and physical phenomena. It usually, then, becomes more difficult to mix system and simulation as they would need to involve different peoples and topologies. MBSE being considered a semi-formal or even informal language, automation and communication between the different stakeholders is complex [5]. Currently the information needed to be transferred from the system to the simulation actors are ill defined with no specific and readily available format, as SysML in the case of system engineering. It is commonplace to use a document-based process (emails or written documents) to provide those information leading to loss of traceability and lack of standardization. We presented a new tooled methodology in a previous article [2], which aims at enhancing the link between system architects and simulation experts by formalizing simulation needs by exploiting the SysML diagrams of the system architecture. Starting from this formalization of the simulation needs by the system architect, a new tooled methodology is proposed in this paper, extending our previous work, enabling the definition of the simulation. The aim of our tooled methodology is to formalize the exchanges between system and simulation architects in order to limit the loss of information, leverage past simulations, formalize requests for new models and give the system architect access to the right data for a supported decision. This methodology is presented in Fig. 2. The solicitation as described in Sect. 3 is sent to the simulation architect who can then assemble a simulation architecture based on specifications indicated for each system function. In order to do so, he can

156

J.-P. Brunet et al.

use past simulations associated to system specifications close to the one requested in the solicitation (with the help of computerized inferences) or, if no existing model match the specification he can generate a new model through the use of the MIC (Model Identity Card) standard [6–8]. The generated MIC will define all necessary requirement in order for a model provider to create a matching model. Once the simulation architect validates a simulation architecture corresponding to the solicitation, he will generate and link the corresponding simulation to a simulation framework. This framework will allow to generate results for a decision support tool within the specified scope of the model. The system architect, in collaboration with the simulation architect, will then be able to analyze the results and either take a final decision or use the knowledge gained to alter the initial solicitation and repeat the whole process. This allows for fast agile loops within the global V-cycle of the system design process. Agility is also improved on the simulation side, where the simulation is developed iteratively in function of the changing needs from the system side. For each step of said process, we proposed a tooled methodology: one dedicated to the System Architect (described in Sect. 3), another for the Simulation Architect (described in Sect. 4). We believe that through the proposed methodology, true agile cycles can be implemented within a MBSE based design cycle by furnishing a formal framework for exchanges between the stakeholders (system architect, simulation architect, and model providers). Allowing for faster exchange of information, it improves information based decision making and more generally accelerates the cycles.

Fig. 2. Proposed methodology for the simulation definition.

Simulation Architecture Definition for Complex Systems Design

157

3 Solicitation Package from the System Architect 3.1 Current Practice and Alternative The development of a system, considered here to be supported by a model of the system architecture, can raise various questions requiring simulation. Such question is sometimes manually summarized in a textual document, whether it is a Word document or an email. This textual document occasionally includes diagrams illustrating the system to simulate. It is often challenging to have a complete and clear question. Furthermore, textual documents make it much harder to identify questions which have already been answered and which were similar, preventing from efficiently re-using past simulations. Textual documents finally make it hard to validate that the system is correctly represented in the simulation, and that the simulation results correctly answer question. Instead of this documental approach disconnected from any model of the system architecture, the process described in this paper first uses the concept of solicitation from the system architect. This concept was introduced in [2]. The solicitation is a documented question of the system architect, directly based on the model of the system architecture. Indeed, the model of the system architecture precisely aims at sharing information about the design of the system with different types of people, from mechanical designers to electrical designers, and it is also perfectly suited for a collaboration with simulation exerts. 3.2 Content of the Solicitation Package The system architect can use the system architecture to communicate three types of information in his solicitation: the part of the system related to the question and which needs to be simulated, the question itself, as well as the environment scenarios to be tested. The part of the system related to the question is important as the question is generally not about the full system. For example, when the question is about the ability of an autonomous vehicle to pass traffic lights, the air conditioning system may typically be ignored. When describing the part of the system related to his question, the system architect should choose the appropriate level of detail. For example, in the case of an autonomous vehicle passing traffic lights, he may choose not to take into account the internal components and the exact way the sensor works to output the color and distance of a traffic light. The question asked by the system architect in his solicitation can be, amongst others, a request for validation. For instance, a system architect may want to check that the average energy consumption of a car is below a standard reference. The question can also be a request for optimization. A system architect may want to find the best design parameters to minimize one or more performance criteria, like the average energy consumption or the production cost. Whatever the question is, its formulation can be supported by the model of the system architecture. The model includes for example the requirements to be tested in a validation, or the unset parameters whose values are to be explored in an optimization. Furthermore, the system architect may also want to monitor specific properties of the system, like its speed or its instantaneous consumption, which he can also select in the model of the system architecture.

158

J.-P. Brunet et al.

Finally, the environment scenarios are also an important part of the solicitation. The environment scenarios generally start as a rough description of the environment and its evolution during the test. In the case of an autonomous vehicle, it can first be decided to have a straight road with a traffic light at 500 m. In the process described here, this rough description is part of the solicitation of the system architect. The environment scenario is then progressively refined when the simulation is developed, up to the exact properties of the road for example. The environment scenario can be defined thanks to the model of the system architecture which characterizes the system’s environment, including roads and traffic lights. However, while the model shows that there can be a traffic light on the side of the road, the system architect must specify in his solicitation that the test should include a traffic light at 500 m. Thus, the formulation of the solicitation is facilitated by the model of the system architecture as it includes various necessary information. Furthermore, the solicitation is not only generated as a textual document, but also as a model. While numerical continuity is generally lost with a textual document, the model of the solicitation has multiple logical links with the model of the system architecture it comes from. 3.3 Implementation of the Solicitation Package Using the model of the system architecture to formulate the solicitation requires new software functions. Indeed, it relies on the processing of numerous and complex relationships between the data of the model, from state diagrams to sequence diagrams and bloc diagrams. Some of these software functions have already been prototyped as a plugin in an existing SysML editor called PhiSystem, provided by Sherpa Engineering and based on Papyrus. Figure 3 shows the menu added to the top bar. The menu first makes it possible to copy the system architecture, which is a practical solution to associate the solicitation to a certain version and configuration of the system. The menu also offers a quick access to diagrams as well as summaries of information at the different levels of the system architecture (operational, functional, and physical) in order to select the perimeter of the question and the necessary level of detail. The menu finally allows to ask a question based on the requirements of the system, and to hide the part of the system which is not related to the question.

Fig. 3. Menus added to the top bar in PhiSystem.

Simulation Architecture Definition for Complex Systems Design

159

For example, if the objective of a system architect is to optimize the control and sensor properties of an autonomous car to minimize both the cost and the energy consumption when passing traffic lights, he can first go to “Use case diagram” in the top-bar menu of Fig. 3 and select the use case “To pass traffic light”. The implemented software functions automatically find the related data and highlight the perimeter of the question in the menu “Functions connection (IBD - Internal Block Diagram)”, as shown in Fig. 4. The level of detail can be set in the menu “Functions hierarchy (BDD- Block Definition Diagram)”.

Fig. 4. Perimeter of the system related to the solicitation.

4 Proposed Methodology for the Simulation Architecture Definition The solicitation defined in the previous section allows to carry the simulation needs (quality, cost and delivery) from the system to the simulation. The simulation architect will then need to define the simulation architecture. This would entail finding existing models, pre/post-processing functions, specify missing models or functions and ensure that the final architecture correctly represents the system and responds to the needs expressed in the solicitation. The simulation architect needs to convert the assembly of system functions into a coherent assembly of models and software functions. In order to keep a consistent approach to those simulation blocks, it is chosen to describe them through the properties of the “Model Identity Card” (MIC) which was initially presented in [9]. The MIC aims at fully specifying a simulation model independently of its execution, as such it can be used to identify an existing simulation model (useful in a reuse case) or to specify requirement for a provider. This approach allows to create consistent architectures mixing existing, reworked, or specifically created models each connected through the ports properties defined in their MIC. The entire workflow of simulation can be validated through the ports properties.

160

J.-P. Brunet et al.

Once assembled the final simulation generated from this simulation architecture will itself be described as a MIC model. The MIC format allows to recursively describe all the internal models of the simulation architecture keeping a traceability of its construction. It is important to note that, at the moment, while a MIC model contains an indication of its validity scope through the indication of range for each variable, it does not contain indication on its accuracy. This might be added in future evolution of the format. The following sections aim at describing the tools put into place to assist the simulation architect in creating, validating, executing and reporting the simulation architecture that correspond to a specific solicitation. 4.1 Developed Components a. Solicitation package import module This tool aims at eliminating the uncertainty in information and traceability incurred in document or email request. The solicitation generated by the system architect is sent, unaltered to the simulation architect tool which will then extract information on the simulation needs, scope and granularity as well as start the traceability of the associated simulation architecture. b. Models library Existing simulation models are stored in a library that link both the MIC and the system function (or functions) matching the given model. This aims at facilitating the reuse of previous simulation work by offering visibility of existing models as well as proposing inference type associations to link system function in the new architecture to semantically close ones from previous work. Figure 5 represents the process of creating a new simulation architecture using the proposed tool. A representation of the filtered system architecture is present in the top with the simulation architecture situated below it. On the right, the models library is displayed. In this figure, the simulation architect already started the creation of the simulation architecture with two system functions (represented in green in the architecture) already associated to some simulation models. Based on the needs, some simulation models have also been added with no direct association to the system functions. At the step shown in the figure, the simulation architect has selected a system function (in red) that he wants to associate to a model. The models library tool (panel on the right of the figure), based on inferences at the system level, proposes a previously used simulation model called “ElectricVehicle” that could be used to simulate this function. The simulation architect selected it (reason for which the simulation model has a green outlay) and the system presented the other system blocs that would also be fulfilled by this model (in orange). In the case a system function would not have a suitable existing model, the simulation architect can choose to create a specification MIC that would be added to the simulation architecture. Upon having an associated model with that MIC it would be added to the models library for future reuse.

Simulation Architecture Definition for Complex Systems Design

161

Fig. 5. Screenshot of the tool during the simulation architecture definition process.

c. Simulation Architecture Verification and creation tool As presented in Fig. 5 the simulation architecture tool allows the simulation architect to progressively define the simulation architecture while maintaining consistency with the system architecture. While new models are added to the simulation architecture, the tool uses the MIC attributes to check the consistency of the model. This is insured through proposing automated links between similar ports (matching dimensions, units and directions), thus verifying that linked models possess compatible ports. Once the whole architecture is verified by the tool and correspond to the specification made by the simulation architect, it can be sent to the model transformation module. Currently, the validation of the simulation performance (QCD) is insured by the simulation architect. In future iteration, it could be imagined that said validation would be at least partially automated through this module (precision within range, validity of the output …). d. Model Transformation Module Once the simulation architecture is finalized, the MICs it includes correspond to known models in the models library. This allows this tool to use the formal description of the simulation architecture to generate a valid simulation by assembling the models. As the MIC also contains the type of environment on which the model needs to be executed, this module also allows to prepare the environment for the execution of the simulation. e. Computer aided Decision Making Upon creating the simulation, this module enables the simulation architect to specify the input parameters and variables and run it accordingly. The results are then displayed

162

J.-P. Brunet et al.

according to the needs of visualization extracted from the solicitation and the users’ specifications. The results are automatically extracted and displayed. The tool also enables running the simulation using different inputs, post processing the results and highlight the advantages of each architecture through direct visual comparison. The system architect (with the eventual expertise of the simulation architect) can compare the results to the needs defined in the solicitation. He then can either take a final decision upon the given solicitation or use the knowledge gained to alter the initial solicitation and restart an iteration of the process.

5 Conclusion This work further refines the role and tools of the simulation architect. It presents a methodology where the system and simulation architects have distinct, complementary roles within the conception cycle. The presented methodology simplifies and formalizes exchanges between the system architecture and the simulation in complex systems design. Through the use of the solicitation package, the system architect is able to communicate a clear, formal and exhaustive request to the simulation architect. This remove doubts or inconsistencies that can arise from improperly defined demand. From this solicitation package and through the developed tool, the simulation architect is capable to define, validate, run and analyze a simulation model that is tailored to answer the requirement set by the system architect. This methodology also simplify the reuse of prior simulation model by using formal description of those (MIC) and association with prior system function. By presenting those prior model in a standardized and centralized library associated with computer generated suggestion, the workload associated with reuse and validation of prior model can be greatly reduced. Lastly, this proposed methodology also facilitate agile project management during the conception cycle. By allowing centralized, traceable, standardized communication between the shareholders of the project as well as facilitating reuse and simplifying validation of new simulations against the solicitation package, we ensure faster simulation iteration during the conception cycle. As a future work, we aim to explore the impact of this novel methodology on the whole conception cycle, by considering state-of-the-art agile methods.

References 1. Retho, F.: Collaborative methodology for virtual product building to support aerial vehicles with electrical propulsion design (2015) 2. Sohier, H., Guermazi, S., Yagoubi, M., Lamothe, P., Maddaloni, A., Menegazzi, P., et al.: A tooled methodology for the system architect’s needs in simulation with autonomous driving application. In: SysCon 2019, pp. 735–742 (2019) 3. argosim. Requirements Simulation with STIMULUS - ARGOSIM [Internet]. https://www. argosim.com/home/stimulus-for-requirements/. Accessed 24 May 2019 4. CIL4Sys Engineering – Home [Internet]. http://cil4sys.com/. Accessed 24 May 2019

Simulation Architecture Definition for Complex Systems Design

163

5. Rauzy, A.B., Haskins, C: Foundations for model-based systems engineering and model-based safety assessment. Syst. Eng. [Internet]. 22(2), 146–155 (2019). http://doi.wiley.com/10.1002/ sys.21469. Accessed 24 May 2019 6. Sirin, G., Paredis, C.J.J., Yannou, B., Coatanea, E., Landel, E.: A model identity card to support simulation model development process in a collaborative multidisciplinary design environment. IEEE Syst. J. [Internet], 9(4), 1151–1162 (2015). http://ieeexplore.ieee.org/document/ 7004782/. Accessed 24 May 2019 7. Sirin, G., Retho, F., Yannou, B., Callot, M., Dessante, P., Landel, E.: Multidisciplinary simulation model development: early inconsistency detection during the design stage. Advances in Engineering Software (2017) 8. Fontaine, G.: Modélisation théorique et processus associés pour Architectes Modèle dans un environnement multidisciplinaire (2017) 9. Sirin, G.: Supporting multidisciplinary vehicle modeling towards an ontology-based knowledge sharing in collaborative model based systems engineering environment [Internet] (2015). http:// www.theses.fr/2015ECAP0024/document

Towards a Cross-Domain Modeling Approach in System-of-Systems Architectures Boris Brankovic(B) , Christoph Binder(B) , Dieter Draxler(B) , Christian Neureiter(B) , and Goran Lastro(B) Center for Secure Energy Informatics, Salzburg University of Applied Sciences, Urstein S¨ ud 1, 5412 Puch/Salzburg, Austria {bbrankovic.its-m2017,christoph.binder,dieter.draxler, christian.neureiter,goran.lastro}@fh-salzburg.ac.at

Abstract. Modeling a System is a challenging task, especially if more than one domain has to be considered. The scenario of Cross-Domain Modeling arises more and more in the future concerning Smart Cities, as the Electric Vehicle (EV) needs to be integrated into the Smart Grid (SG) and accordingly the Grid faces an emergent behaviour, regarding the energy-management. State of the art Frameworks like Smart Grid Architecture Model (SGAM), Automotive Reference Architecture Model (ARAM), or Reference Architecture Model Industrie 4.0 (RAMI 4.0) consider all these aspects and are used to model such systems, but the combination of these domains is still an issue. The Software Platform Embedded Systems (SPES) Framework provides a base for the modeling of systems belonging to certain domains and with proven modelingtheories a new approach towards the modeling of System of Systems (SoS)-Architectures is needed. Therefore, this paper concerns the problems of modeling SoS-Architectures and investigates the possibility to combine domains and to map them to the SPES-Framework.

1

Introduction

The constantly rising complexity in modern information systems is not a completely new topic, but has been a matter of science and research since several decades. To mention an example, the authors of [11] outline on how to deal with this complexity by exemplifying a system from a scientific perspective. Additionally, several approaches for measuring or modeling such a system, tailored to its development, are introduced. One of the main findings of their work and the underlying concepts proposed in [24] is the need for using a variety of diagrams in order to address all aspects of a complex system, but also create a mutual basis. Thus, the classification scheme introduced in [12] can be applied to classify a system based on its complexity. However, latest advances in technologies in the area of Internet of things (IoT) resulted in the emerging of new possibilities and products like Cyber-physical Systems (CPSs). This means, modern information c Springer Nature Switzerland AG 2020  G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 164–175, 2020. https://doi.org/10.1007/978-3-030-34843-4_14

Towards a Cross-Domain Modeling Approach

165

systems not only form a system themselves, but constitute of multiple subsystems, making up the popular term of the so-called SoS. The traits proposed in [15] and [9] can be used when describing the peculiarities of such a SoS. Summarizing these aspects and the ones mentioned before, developing current and future systems is a challenging task including various individual issues. Hence, the concepts of Model Based Systems Engineering (MBSE) have proven to be a suitable methodology for approaching this problem. Supported by Model Driven Architecture (MDA), Domain Specific Systems Engineering (DSSE) is an example for such a comprehensive approach tailored to model-driven system development in the Smart Grid domain [17]. By doing so, it makes use of a specifically designed Domain Specific Language (DSL) and a corresponding development process [19]. Based on the findings of developing and using the DSL, a technology and knowledge transfer to other domains has been promoted. Thus, in [6], a methodology for model-based development of Industry 4.0 based systems is introduced, whereas [10] specifies all domain-specific features needed for modeling the system of an automotive vehicle. However, as proposed by [1], the amalgamation of the addressed domains with each other and several others is taking place under the so-called term Smart Cities. This is mainly supported by the ubiquitous data evaluation of IoT devices throughout the whole life-cycle in order to achieve their key functionalities. Moreover, this means that a smart component crosses multiple domains during its planning, development and utilization in the Smart City. An example for a method tailored to domain-independent engineering of systems has been provided with the introduction of SPES, as proposed in [21]. This model-driven approach enables MBSE on different viewpoints and multiple granularity layers. According to these considerations, this paper introduces a method for combining system architectures in the automotive, industrial and Smart Grid domain by using the concepts of SPES. Therefore, the first step to approach this is to map the layers of ARAM, the RAMI 4.0 and the SGAM to the viewpoints of SPES in order to create a common basis. The application and evaluation of this approach is assured by a real-world case study. For this scenario, a use case representing an EV is considered to be a suitable example, since the automotive architecture can be modeled according to ARAM, its manufacturing by using RAMI 4.0 and its behavior as well as integration into the Smart Grid with the help of SGAM. Therefore, this contribution is structured as following: In Sect. 2 an overview of SPES, ARAM, RAMI 4.0 and SGAM is given. Subsequently, the approach to address the problem statement is described in Sect. 3. The implementation itself is stated in Sect. 4, whose applicability is demonstrated in Sect. 5. Finally, in Sect. 6 the results of the conducted study are summarized and then a conclusion is given.

2 2.1

Related Work Software Platform Embedded Systems (SPES)

The SPES Modeling-Framework is used for model-based development of systems. It addresses challenges that develop in application domains. Based on

166

B. Brankovic et al.

certain requirements, as well as fundamental principles defined in [21], it forms a core concept, which provides a new way of thinking while performing modeling activities. An example would be meeting the characteristics of a specific system, while considering the requirements from the application domains. Therefore, two major approaches, Abstraction-Layers and Views and Viewpoints, are defined by the previously mentioned core concept, which form a two-dimensional engineering space, as proposed in [21]. The horizontal axis Viewpoints is separated into four sections, Requirements Viewpoint, Functional Viewpoint, Logical Viewpoint and Technical Viewpoint, each section provides different templates for modeling during the engineering process. The vertical axis Abstraction Layers provides the possibility to model a System under development (SUD) or a design element, on different abstraction layers. 2.2

Automotive Reference Architecture Model (ARAM)

Today’s power grids are currently heading towards a major change. The introduction of communication technologies leads to the transformation towards the so called SG. Basically in SGs, sub-systems are geographically distributed, operational managerial and operational independent, heterogenic and interdisciplinary without a final state and with the ability to show emergent behavior. These, characteristics are defining a SoS [9]. In future, a bulk of those sub-systems are EVs, which in certain scenarios also might raise emergent behavior within the SG [16]. For this reason, when developing EV architectures, such systems need to be treated on an more holistic point of view with a strong connection to the SG. Therefore, such an extension of the system boundary leads to the introduction of new stakeholders into the development process of EV architectures. To enable interdisciplinary, model-based and domain specific systems engineering within the automotive domain the Automotive Reference Architecture Model framework has been developed [10]. The three-dimensional structure allows to model EV architectures on different points of view. The top most viewpoint is the Business Viewpoint. The requirements and functions are governed by the Function Viewpoint. Physical aspects of the system are modelled on the lower three layers. Whereas, the physical components are part of the Physical Viewpoint. The E/E architecture is framed by the E/E Viewpoint and the exchanged data objects are modelled in the Information Viewpoint. 2.3

Reference Architecture Model Industrie 4.0 (RAMI 4.0)

Similar to ARAM, the three-dimensional model has been mainly developed to create a common understanding and a mutual basis for enabling the discussion of systems based on Industry 4.0. The architecture itself is structured in Life Cycle & Value Stream, Hierarchy Levels and Interoperability Layers [13]. In more detail, the horizontal axis of RAMI 4.0 deals with the different states an asset may have during its time of usage. Thus, the aim is collecting data referring to the component throughout its whole life-cycle. In the second axis, the vertical integration within a factory is represented by the Hierarchy Levels.

Towards a Cross-Domain Modeling Approach

167

Well known under the term automation pyramid. Finally, the top-down arrangement of the layers enables the structuring of the system according to the feature of its components across six viewpoints. Thus, the Business Layer defines processes and boundaries of the system, resulting in the elaboration of requirements. Those requirements build the base for the future development of the system, in particular the specification of services displayed on the Function Layer. The Information Layer deals with handling all kind of data, whereas the Communication Layer contains connections and interfaces within the system components. Following this principle, the Integration Layer enables the digitalization of components by specifying Human-Machine Interfaces (HMIs). At last, the Component Layer implements the physical viewpoint and therefore enables the real-world representation of the component. 2.4

Smart Grid Architecture Model (SGAM)

The energy domain gained more and more importance over the past years. New challenges arise, as Distributed Energy Resources (DER) like Photo-Voltaic (PV) Systems, or Wind-Turbines, which are dispersed over the entire power grid, react sensibly to changes e.g. the weather. This highly dynamic characteristic puts current grids to the test and therefore a move towards a SG is needed. SGAM has been developed by the members of CEN, CENELEC and ETSI, in the context of the European Commission’s Mandate M/490 [22]. It provides a Framework, which contains all necessary standards and information, needed for the development of a SG Architecture. The three-dimensional Model presented in [22], is based on the NIST Domain Model [20], the GWAC Interoperability Stack [23] and the automation pyramid. The dimensions contain the following elements, Domain, Interoperability (Layer) and Zone. The x-axis, described as Domains, contains five sections, which are present in a modern power grid. It breaks down a SG-System on the basis of the NIST Domain Model, where in contrast to that the y-axis, portrayed as Zones, illustrates the functionality on basis of the automation pyramid. To ensure a degree of interoperability between certain elements, five interoperability layers are established. These layers are derived accordingly to [23] and after [22] divided as follows: Business Layer, Function Layer, Information Layer, Communication Layer and Component Layer.

3 3.1

Approach Agile Design Science Research Methodology

The Agile Design Science Research Methodology (ADSRM) fosters creative research by simultaneous development of both, the problem- and solution-space [8]. Basically, this approach allows to start from very uncertain requirements. The artifacts as well as the requirements are evolving in each iteration, whereas each iteration itself delivers a solution of the planned artifacts. The first input with respect to this research is an appropriate case study. The case study is

168

B. Brankovic et al.

the input for the requirements process, which delivers the requirements for each iteration loop. Based on these requirements, the artifacts are developed. Further, the artifacts are applied to model the case study, which further delivers in each iteration an architecture model of the case study. Through iterations the case study is modeled and therefore delivers input for the development of the artifacts itself. This step-by-step modeling is repeated until the artifacts and the model reaches a level, which allows the evaluation by domain experts. The final model and the artifacts are the input for the second stage of evaluation. Basically, the evaluation by domain experts is done based on the presentation of the artifacts and the model. The findings from the evaluation serve as input for the next iteration in the ADSRM. The process of charging an EV serves as case study for developing the artifacts. Further, charging an EV delivers input for modeling in each architecture domain. The automotive architecture can be modeled using ARAM, its manufacturing using RAMI 4.0. The integration into the SG together with the charging behavior can be modeled using the SGAM framework. Thus, also all three frameworks serve as main input for the task of requirements engineering. This task delivered a set of requirements, which need to be considered during the development. One main requirement is that the consolidation of the different domain frameworks to allow cross-domain modeling needs to be based on a framework, which is able to address the aspects within all three domains. This framework should serve as interface between the different other frameworks. Therefore, the main task of development with respect to ADSRM is to first map the frameworks coming from different domains on the SPES framework [7]. Based on this, the following main artifacts can be developed. • Mapping between DSSE Frameworks and SPES. • Interfaces between the different domain frameworks based on SPES. 3.2

Case Study

One input of the ADSRM is a suitable case study. Therefore, the chosen study is the charging system with respect to EVs charging at a Level II charging station, classified after the Society of Automotive Engineers (SAE), with the development of the SAE J1772 standard [2]. A first model of a case study of the breaking system of an EV has been implemented in [10]. To enable further considerations about charging an EV at a charging station, this case study has been extended. This includes an extension of the decomposition into additional sub-systems. In an conventional EV the main components for AC charging at a Level II charging station are usually a On-Board Charger, Battery Management System (BMS), Inverter and the High Voltage Battery. The components are connected to each other through electrical high voltage connections as well as communication connections such as CAN. As the High-Voltage Battery is crucial for EVs since it needs to fit along the other parts of the car, it therefore has an impact on the power grid during runtime and needs to be produced according to these aspects. Hence, the BMS is considered as main component in the proposed

Towards a Cross-Domain Modeling Approach

169

case-study. Typically the BMS acts as interface between the On-Board Charger and the High-Voltage Battery. Thus, the BMS is capable of detecting certain information about the cell-capacity. With this information one is capable of knowing how the High-Voltage Battery behaves in specific operational situations. To give an example herefore, a variety of battery packs exist, which are formed from different battery system structures [14]. Multiple cells are combined in order to achieve specific values, e.g. stored amount of energy, and with certain design parameters, provided by the BMS, it is possible to determine how a certain pack performs and where room for improvement exists.

4

Implementation

Mapping ARAM to SPES - As outlined in Sect. 2.2, the ARAM framework is built upon five viewpoints [10]. The viewpoints are looking at the vehicle from different perspectives. As the SPES framework also allows modeling systems of the automotive domain, a mapping between the viewpoints of ARAM and SPES is possible. However, no one-to-one relation between the viewpoints can be established. As the Requirements Viewpoint of the SPES framework is basically for context, requirements, stakeholder and goals modeling, it is possible to map the Business Viewpoint of ARAM one-to-one on this viewpoint. The mapping of the Functional Viewpoint to SPES is much more challenging. As described in [10] the Functional Viewpoint considers the vehicle from the perspective of the functional architecture as well as of the logical architecture. But, within SPES those are part of two separate viewpoints. Thus, the ARAM Functional Viewpoint is split up and mapped to both of them. The functional architecture part of ARAM is mapped to the SPES Function viewpoint and the logical architecture part is mapped to SPES Logical Viewpoint. However, the most challenging is the one from the lower three viewpoints. As all three of them describe the system from a technical point of view, it is necessary to summarize them in the SPES Technical Viewpoint. Basically, the ARAM physical viewpoint is the main technical viewpoint in SPES. Further, as SPES is not restricted to the four main viewpoints, it is possible to define additional ones. This allows the mapping of the information and E/E viewpoint on the technical one through the definition of them as sub-viewpoints. To be able to model also mechanic and thermal related aspects, the authors of this paper also introduce a Mechanical and Thermal Viewpoint as sub-viewpoints to the Technical Viewpoint. Mapping RAMI 4.0 to SPES - As previously explained, this framework also offers different layers dealing as viewpoints for dividing a system. However, since structuring a manufacturing system is a complex task entailing a lot of different challenges, RAMI 4.0 introduces six abstraction layers, containing an additional one in contrast to ARAM and SGAM. This means, the mapping of these layers to the SPES concepts needs to take care of several aspects. However, considering the first two layers is more or less straightforward. As explained in [5], the task of the Business Layer is to elaborate the requirements by specifying the system context as well as identifying the stakeholders. Consequently, this layer can

170

B. Brankovic et al.

be transformed to the Requirements Viewpoint one-to-one. The same principle can be applied to the Function Layer by mapping it to the equally called Function Viewpoint of SPES. This is the point where the mapping process becomes increasingly challenging. Since the Information and Communication Layer of RAMI 4.0 deal with exchanging the data and defining the interfaces or protocols for their exchange, this belongs to the development of the technical architecture, more precisely the Technical Viewpoint of SPES. However, with the third viewpoint defining the logical architecture of the system, the concepts of the RAMI Integration Layer seem to be suitable for its mapping. This is underlined by describing surrounding systems like the Information and Communication Technology (ICT) Infrastructure or HMIs. Finally, the Asset Layer is again part of the Technical Viewpoint due to containing components of the real world and their exact definition. Summarized, the transformation of RAMI 4.0 to SPES results in one-to-one mapping of the Business, Function and Integration Layer, while the remaining layers are combined to the Technical Viewpoint. Mapping SGAM to SPES - According to Sect. 2.4, the SGAM framework provides five interoperability layers [22], needed to enable a clear representation of the architecture model introduced by [23]. Therefore, these layers give insights into the decomposition of a Smart-Grid system, with a main focus on interoperability. Because the SPES framework considers modeling of systems in the energy domain, it is suitable for SGAM and thus a potential mapping of the mentioned layers onto the SPES Viewpoints can be realized. Although, the mapping between the layers and the viewpoints cannot be done one-by-one. SPES uses its specified Requirements Viewpoint as starting point for modeling a system, which generally is used to describe its context, requirements, needs of stakeholders and the modeling of certain goals. Concerning SGAM, a one-by-one mapping of the top-layer, defined as Business Layer, onto the Requirements Viewpoint can be performed. The underlying Function Layer in SGAM must be mapped onto the Functional Viewpoint and Logical Viewpoint of SPES. According to [19] the approach Functional Analysis decomposes primarily defined High Level Use Cases (HLUCs) from the Business Layer into Primary Use Cases (PUCs) and combines them with Logical Actors, which form the Function Layer. The explained approach is therefore located on the Functional Architecture as well as on the Logical Architecture. Another approach explained in [19], defined as Architecture Development, explains the transformation from the logical model to the technical, which covers the lowest three layers in SGAM. Thus, the mapping from the logical components onto the physical ones is done, which concerns inter alia the Information Layer, Communication Layer and the Component Layer. Because, the technical aspects are considered in this step, these layers can be mapped to the Technical Viewpoint of SPES. Mapping Results - Summarized, Fig. 1 outlines the relations of the SPES viewpoints and the corresponding domain-specific reference architectures. According to this figure, it is apparent that a one-by-one mapping of the Business Viewpoint, or Layer respective, of the considered frameworks ARAM, RAMI 4.0 and SGAM, can be realized.

Towards a Cross-Domain Modeling Approach

171

Fig. 1. Mapping of the frameworks to SPES-Matrix.

As the given image defines the complete mapping between the mentioned domains, a potential common interface between the frameworks is identified. For a better understanding, this interface can be illustrated by a common Requirements Viewpoint i.e. the frameworks are internally connected through it. Therefore, each domain is represented as Application Domain, this principle was first introduced by [18], where each of these Application Domains (ADs) represents a certain system context. Further, these ADs are connected through Application Domain Interrelations (ADIs), which enable a holistic view on a SoS architecture (e.g. Smart City), consisting of multiple ADs, covering the architectural and functional aspect [18].

5

Application

As explained above, the goal is to evaluate the mapping by modeling the BMS of an EV with the help of SPES. First, modeling the EV architecture is done under consideration of the ARAM framework. This allows to create a model of the whole EV from the perspective of the automotive domain. Second, within the SG, EVs play an important role in certain use cases. For example, in power grids it is from high importance to keep the equilibrium between energy production and consumption. But, through the introduction of weather dependent energy production, such as wind turbines or photovoltaic systems, the equilibrium can be disturbed. One counter measure is for example to introduce load shifting through rate-based charging of EVs [3]. Such a demand side management scenario is modeled using SGAM. The charging behavior itself is modeled in behavioral diagrams, such as an activity diagram [4]. Last, the production of the single components of the EV, is modeled using the RAMI 4.0 framework.

172

B. Brankovic et al.

For example, the production of the High-Voltage Battery needs different resources and is done in an industry 4.0 production line. Within this, the complete value chain can be modeled, which further delineates the different states the High-Voltage Battery has along the time of usage. Basically, it starts with the idea by the input of certain design parameters. Those parameters, as specified in Sect. 3, may come from the ARAM model of the EV, which might be for example the size and number of cells, provided by the BMS. Further, the production of the battery is also modeled with respect to the machines needed in a factory. According to these considerations, the modeled case study is explained in more detail in the following section. Case Study Model - According to [21] the Requirements Process Model is chosen as suitable approach to define the Requirements Viewpoint. This viewpoint is seen by the mapping in Sect. 4 as common interface with respect to the considered Frameworks ARAM, RAMI 4.0 and SGAM. The realization of the model is done with the Modeling-Software IBM Rhapsody 1 , as it supports the SysML-Profile, needed for Systems-Engineering tasks. The Model regarding the case-study, deals with the charging-process of an EV at a Level II Charging Station with the main focus on the BMS. After the definition of the system-context and the goals, concerning the case-study, appropriate scenarios are needed, where each fulfills at least one defined goal. Those scenarios, are illustrated in Fig. 2, where the main Use-Case, defined as HLUC, describes the overall scenario of the study. Based on this HLUC, a Business Use Case is specified, primary concerning the BMS and to derive meaningful Requirements from it. Furthermore, regarding to the defined case-study, the Charging Station itself represents the architectural aspect of the model and as it is depicted in Fig. 2, for each AD, a certain PUC is defined. These PUCs are fulfilled by this very Charging Station and represent the functional aspect. Depending on the domain, the PUCs are assigned to the corresponding Function Viewpoint. As proposed by [18], the information included in these PUCs is transported to services in the higher layers. Concerning SPES, the allocation from one viewpoint to another inducts an equal operation. In both cases, a traceability through the entire model is given by the aforementioned operational activity. Therefore, the PUCs can be used to enable a modeling across the considered domains and further for a decomposition into additional Sub-Systems. Hence, the refinement of certain Requirements, derived from the HLUC, is applicable to all levels of abstraction, as the Requirements Process Model remains the same.

1

https://www.ibm.com/us-en/marketplace/rhapsody-designer-for-systemsengineers.

Towards a Cross-Domain Modeling Approach

173

Fig. 2. Case study model illustrated with common requirements viewpoint.

5.1

Findings

The Case-Study Model in Sect. 5 shows the application of a suitable model concerning the mapping results stated in Sect. 4. Therefore, a modeling across domains is feasible by choosing a common Requirements Viewpoint and separating the considered domains into ADs. Further, the definition of PUCs makes it possible to address the according domain and to model the system, by considering the respective context, as the PUCs represent the functional aspect of the system and can be applied on all layers of abstraction.

6

Conclusions and Future Work

The presented approach outlines the first step towards cross-domain modeling of complex SoS under the term Smart Cities. This is done by making use of already established architecture frameworks regarded to domain-specific systems engineering. Thus, the goal is to combine the automotive architecture of an EV by

174

B. Brankovic et al.

using the ARAM as well as its manufacturing and integration into the Smart Grid according to RAMI 4.0 and SGAM. Therefore, first the respective reference architecture model needs to be analyzed in terms of its specific characteristics and its possibilities to delineate a system, which is stated in Sect. 2. This enables the elaboration of similarities and links between each model of the EV in order to define the corresponding interfaces. A suitable method for uniting those domainspecific approaches to work across domains is considered to be SPES. Therefore, in Sect. 4, the mapping of each architecture to the concepts of SPES is described in more detail and the interfaces to combine each other are defined. Subsequently, the result is evaluated by applying a real-world case study making use of an EV. The outcome of this work can contribute to various different follow-up projects inter alia the modeling of a Smart-City concerning different domains and with that the development of a suitable Framework.

Acknowlegdements. The support for valuable contributions of Robert Bosch GmbH and LieberLieber Software GmbH is gratefully acknowledged. The financial support by the Federal State of Salzburg is also gratefully acknowledged.

References 1. Alavi, A.H., Jiao, P., Buttlar, W.G., Lajnef, N.: Internet of Things-enabled smart cities: state-of-the-art and future trends. Measurement 129, 589–606 (2018) 2. Angelov, G., Andreev, M., Hinov, N.: Modelling of electric vehicle charging station for DC fast charging. In: 2018 41st International Spring Seminar on Electronics Technology (ISSE), pp. 1–5 (2018) 3. Balakumar, P., Sathiya, S.: Demand side management in smart grid. In: 2017 IEEE International Conference on Electrical, Instrumenation and Communication Engineering (ICEICE), Karur, India (2017) 4. Binder, C., Gross, J.A., Neureiter, C., Lastro, G.: Investigating emergent behavior caused by electric vehicles in the smart grid using co-simulation. In: 2019 14th Annual Conference System of Systems Engineering (SoSE), Anchorage, Alaska, USA. IEEE (2019, in press) 5. Binder, C., Neureiter, C., Lastro, G.: Towards a model-driven architecture process for developing Industry 4.0 applications. Int. J. Model. Optim. 9(1), 1–6 (2019) 6. Binder, C., Neureiter, C., Lastro, G., Uslar, M., Lieber, P.: Towards a standardsbased domain specific language for Industry 4.0 architectures. In: Complex Systems Design and Management, Paris, France, pp. 44–55. Springer, Cham (2019) 7. Broy, M., Gleirscher, M., Kluge, P., Krenzer, W., Merenda, S., Wild, D.: Automotive Architecture Framework: Towards a Holistic and Standardised System Architecture Description. Technical report, Technische Universit¨ at M¨ unchen and IBM Corporation (2009) 8. Conboy, K., Gleasure, R., Cullina, E.: Agile design science research. In: Donnellan, B., Helfert, M., Kenneally, J., VanderMeer, D., Rothenberger, M., Winter, R. (eds.) New Horizons in Design Science: Broadening the Research Agenda, pp. 168–180. Springer, Cham (2015) 9. DeLaurentis, D.: Understanding transportation as a system-of-systems design problem. In: 43rd AIAA Aerospace Sciences Meeting and Exhibit, Reno, Nevada, p. 123 (2005)

Towards a Cross-Domain Modeling Approach

175

10. Draxler, D., Neureiter, C., Lastro, G., Schwartzkopff, T., Boumans, M.: A domain specific systems engineering framework for modelling electric vehicle architectures. In: 2019 IEEE Transportation Electrification Conference and EXPO Asia-Pacific, Jeju, Korea (2019) 11. Flood, R.L., Carson, E.R.: Dealing with Complexity: An Introduction to the Theory and Applications of the Systems Science. Plenum Press, New York (1993) 12. Haberfellner, R., de Weck, O., Fricke, E., V¨ ossner, S.: Systems Engineering Grundlagen und Anwendung, 13 edn. Orell F¨ ussli (2015) 13. Hankel, M., Rexroth, B.: The Reference Architectural Model Industrie 4.0 (RAMI 4.0). ZVEI (2015) 14. Lelie, M., Braun, T., Knips, M., Nordmann, H., Ringbeck, F., Zappen, H., Sauer, D.: Battery management system hardware concepts: an overview. Appl. Sci. 8, 534 (2018) 15. Maier, M.W.: Architecting principles for systems-of-systems. Syst. Eng. J. Int. Counc. Syst. Eng. 1(4), 267–284 (1998) 16. Nadeje, K., Strasser, B., Pichler, M., Wendt, A., Kiensberger, G.: Smart Grids ¨ - Modellregion Salzburg - Building to Grid. Technical report, Osterreichische Forschungsf¨ orderungsgesellschaft FFG (2013) 17. Neureiter, C.: A Domain-Specific, Model Driven Engineering Approach for Systems Engineering in the Smart Grid. MBSE4U - Tim Weilkiens, Hamburg, Germany (2017) 18. Neureiter, C., Rohjans, S., Engel, D., D¨ anekas, C., Uslar, M.: Addressing the complexity of distributed smart city systems by utilization of model driven engineering concepts. In: Proceedings of VDE Kongress 2014, pp. 1–6 (2014) 19. Neureiter, C., Uslar, M., Engel, D., Lastro, G.: A standards-based approach for domain specific modelling of smart grid system architectures. In: Proceedings of International Conference on System of Systems Engineering (SoSE 2016), Kongsberg, Norway, pp. 1–6 (2016) 20. Office of the National Coordinator for Smart Grid Interoperability: NIST Framework and Roadmap for Smart Grid Interoperability Standards Release 1.0. Technical report, National Institute of Standards and Technology (2010) 21. Pohl, K., Broy, M., Daembkes, H., H¨ onninger, H.: Advanced Model-Based Engineering of Embedded Systems. Springer, Cham (2016) 22. Smart Grid Coordination Group: Smart Grid Reference Architecutre. Technical report, CEN-CENELEC-ETSI Smart Grid Coordination Group (2012) 23. The GridWise Architecture Council: GridWise Interoperability Context-Setting Framework. Technical report (2008). http://www.gridwiseac.org 24. Vemuri, V.: Modeling of Complex Systems: An Introduction. Academic Press, New York (2014)

Safety Demonstration of Autonomous Vehicles: A Review and Future Research Questions Tchoya Florence Koné1(B) , Eric Bonjour2 , Eric Levrat3 , Frédérique Mayer2 , and Stéphane Géronimi4 1 Université de Lorraine/Groupe PSA, Nancy, France

[email protected] 2 Université de Lorraine, laboratoire ERPI, 8 rue Bastien Lepage, 54000 Nancy, France

{eric.bonjour,frederique.mayer}@univ-lorraine.fr 3 Université de Lorraine, Laboratoire CRAN, UMR CNRS 7039, Faculté des Sciences et

Technologies, BP 239, 54506 Vandoeuvre les Nancy, France [email protected] 4 Groupe PSA, Vélizy A, Route de Gizy, 78140 Vélizy-Villacoublay Cedex, France [email protected]

Abstract. The safety demonstration and validation of Autonomous vehicles (AVs) remains a challenging activity. In this paper, we firstly review what those challenges are and how they affect the safety validation of the AV. Then, we particularly focus on the simulation-based validation process, which seems to be inevitable among the recommended safety validation approaches. We show what is actually done and required in terms of scenarios generation, their assessment taking into account uncertainty and the simulation architecture to test and validate them. Finally, we end our review by summarizing key research questions that need to be addressed to help with this safety validation issue.

1 Introduction An automated vehicle (AV) is a vehicle, which is able, according to the conditions of its operating environment and the level of automation, to move with or without human intervention. The Society of Automotive Engineers [1] (SAE) identifies six levels of automation: No Automation (Level 0), Driver Assistance (Level 1), Partial Automation (Level 2), Conditional Automation (Level 3), High Automation (Level 4), and Full Automation (Level 5). For its operation, an automated vehicle collects information about its environment, processes them, plans its trajectory and decides on actions to be performed. To implement this, manufacturers use specific technologies such as sensors and localization systems, communication systems and intelligent control systems. These embedded technologies are sometimes new, difficult to specify and have functional performance limitations regarding environmental conditions. This affects standard safety validation procedures, which face new challenges and are now limited. In fact, the ISO 26262 standard, which has been considered since 2011 as the reference in the automotive field with regard to the guarantee of functional safety, is no longer sufficient. Also, conventional validation techniques such as validation by “miles needed to be driven”, are irrelevant. © Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 176–188, 2020. https://doi.org/10.1007/978-3-030-34843-4_15

Safety Demonstration of Autonomous Vehicles

177

Kalra et al. [2] showed that it would require hundreds of millions of kilometers or sometimes hundreds of billions of kilometers, to carry out validation tests by this method. In addition, formal proof based approaches are not suitable for complex systems because of the combinatorial explosion regarding proof algorithms [3]. Another approach is about simulation-based method. It has also been proved to be difficult because of the amount of test cases that have to be generated [3]. However, it remains the most promising method. This seems to be obvious given the difficulty of carrying out experiments, especially in urban areas. In the light of all the above elements, some questions are overwhelming. How are the challenges for AVs safety validation looking for? How to ensure the safety demonstration of AVs by simulation-based method? In this paper, we present a general review of existing works about these questions and we summarize other research questions that need to be addressed to deal with this issue. The remainder of the paper is organized as follows: Before exploring the safety validation with simulation, Sect. 2 comes back in more detail to challenges in AVs safety validation. Section 3 deals with the first objective to be addressed in safety validation by simulation process: the generation of the scenarios needed for simulation. Then, Sect. 4 is about the statistical assessment of scenarios with the consideration of uncertainty. Section 5 gives an overview about the simulation framework with regard to the safety demonstration and testing system. Section 6 summarizes the conclusion and future research questions that could be addressed to contribute in AV safety demonstration.

2 Challenges in AV Safety Validation The first difficulties related to the AVs were publicized in 2004, with the DARPA Grand Challenge, organized by the DARPA, the Defense Advanced Research Projects Agency. This is the first competition in the world involving self-driving and unmanned ground vehicles. Lessons learned [4] at the end of the DARPA project included the development of much more powerful sensors, the impossibility of validating vehicles in a real and dynamic environment, and the maintaining of the driver in the loop to deal with unexpected scenarios. However, the awareness of the complexity related to the validation of AVs began with the arrival of the first systems that initiated the projects of autonomous driving, namely ADAS (Advanced Driver Assistance Systems). Because of their usefulness especially for the protection of the road users, these systems quickly attracted increased interest. The importance of such utility therefore required that these systems be robust and reliable. However, they were based on detection systems and faced a large number, or even infinite number, of parameters that can be identified during a mission profile. Conventional methods have quickly proved to be insufficient or obsolete for their validation. In this section, we mainly focus on the difficulties in safety validation of AVs with regard to technological issues, the presence of uncertainties and the limitation of ISO 26262 standard.

178

T. F. Koné et al.

2.1 Specificities and Technological Issues AVs use specific technologies such as sensors and localization systems, communication systems and intelligent control systems (especially with self-learning AI algorithms) to achieve their mission. These are the subject of many works in order to make them successful but problems still remain. First, manufacturers encounter geolocation and perception issues. In fact, what makes perception right and accurate is the quality of sensors. This quality depends on parameters such as sensitivity, linearity, noise, selectivity, saturation, bandwidth or geometric resolution. Sensors performance and limitations may vary according to their parameters configuration. Some sensors are more suitable to the detection of nearby objects like ultrasonic sensor and 3D camera but they have some disadvantages in rainy conditions. Long-range radar and LIDAR are appropriate to detect remote objects but with a restricted measurement angle for the radar and poor performance for the Lidar in fog and snow conditions. In addition to weather conditions, sensors are also sensitive to many other factors like sand, salt or dust. Li et al. [5] stated that the environment is complex and factors such as the alternation of structured and unstructured roads, heavy shadow, pavement distress, dirt, puddles, the frequent change in the appearance of a road, the curvature of roads, accentuate the challenge in road detection. All those limitations and performance variations have to be taken into account while testing AVs. The validation process has to check that AVs can detect nearby or distant objects, ensure that they will perform successfully in poor weather conditions or degraded environment configurations. Then, trajectory planning and decision-making is another issue. The planning module has to deal with both “innate dynamic constraints and restricted planning space” [6]. Indeed, the dynamics of the environment constrains the system to make a decision within a bounded time; otherwise, the AV could be dangerous or in danger due to its passivity [7]. The ability of the system to react in a dynamic environment, face the question of ethics by making moral decisions and act quickly must be tested for the AV validation. Finally, the use of V2X communications is envisaged for the AV but this can also be the subject of various dysfunctions or threats like data interception, connection hijacking, jamming of transmissions, and denials of service and therefore needs to be considered in the validation. 2.2 Difficulty in Compensating for the Presence of Uncertainties The main characteristic of the behavior of autonomous systems is related to the treatment of the uncertainty with which they are confronted [8]. Uncertainty can be classified in different categories: (1) epistemic uncertainty related to the lack of knowledge about the environment, (2) uncertainty of sensor measurements, (3) interpretation uncertainties generated by sensor fusion algorithms and associating levels of confidence with different objects, (4) decision-making uncertainties concerning the various arbitrations possibly contradictory among which the system must decide; for “sensitive” scenarios, and (5) uncertainties related to the dynamics of evolution of the system and the environment. Uncertainty prevents designers from defining test cases with precision and completeness. It therefore appears that, to demonstrate the safety of AVs, a more effective strategy has to be defined taking into account these different categories of uncertainty.

Safety Demonstration of Autonomous Vehicles

179

2.3 Limitation of the ISO 26262 Standard ISO 26262 deals with the safety of a vehicle in terms of the absence of unreasonable risk due to a malfunction of electrical and electronic systems. However, in the case of AVs, it does not take into account safety breaches, in the absence of default, caused by the performance limitations, of decision-making components [3]. This standard provides a V-cycle safe development and test process, which is difficult to apply to the development of safe autonomous vehicles [9]. According to Koopman et al. this process is now facing five major challenges. The first one is the absence of the driver in the decision-making loop. Indeed, in a traditional engineering approach (of a vehicle with driver), the manufacturer does not care much about the deviations in the behavior of road users (other vehicles, pedestrians, etc.) that the vehicle can meet on the road or the environment in general. The manufacturer transfers this responsibility to the driver. This is no more possible with AVs. The other challenges are about the complexity of the requirements, the presence of non-deterministic algorithms, inductive learning algorithms and fail-operational systems, which are not in the scope of this standard. In addition, the validation of the self-adaptive behavior of AVs makes it impossible to predict all situations in the design process [10]. Therefore, manufacturers can no longer limit their safety analysis to this standard and have to think about new certification approaches. Work is underway to fill this need. One of them is the development of the Safety Of The Intended Functionality (SOTIF) standard. It is a reference that aims at providing a complement to the ISO 26262 by focusing on the safety of the functional performance of systems. It targets specific characteristics such as sensing and processing of complex algorithms, whose dysfunctions may be due to performance limitations of desired functions. The actual edition of the future reference is mainly dedicated to emergency intervention systems (e.g. emergency braking systems) and Advanced Driver Assistance Systems (ADAS), but can be considered for higher levels of automation with additional measures. The purpose of SOTIF’s activities is to reduce the known dangerous scenarios and show that the residual risk due to unknown potentially dangerous scenarios is acceptable. However, the combinatorial explosion of potentially chaotic situations makes the completeness of physical tests difficult to conceive in an experimental way [2]. It becomes necessary to explore the universe of critical situations with other strategies, and in particular by simulation.

3 Scenarios Generation for Simulation-Based Validation Simulation appears to be a promising way to address the impossibility of carrying out only road and track tests for the validation of AVs. In this section, we review the activities performed in the context of the validation of AVs by simulation: the scenarios identification in industrial domain, the concepts definition and their modeling, and the scenarios generation. 3.1 Scenarios Identification in the Industrial Domain Work is going on to determine the relevant scenarios needed for the validation of autonomous vehicles.

180

T. F. Koné et al.

The first identification strategy concerns the use of experience. The main goal of this approach is to use previous experiences based on prior driving functions like ADAS systems or manual driving systems to identify a first list of scenarios that manufacturers qualify to be relevant. Returns from drivers can be used to complete this list; they are suitable to inform the manufacturers about events or misuses they observed during driving. In the same way, accident databases are helpful for identifying critical situations that may be a challenge for AV. As not all scenarios can be derived from previous experiences due to the complexity of the AV, others strategies have to be used. One strategy is to use specific driving to collect information and target specific scenarios. Another one, refers to the knowledge of the experts about the technologies implemented on the AV. It should also be noted that governments are busy revising regulations, defining the procedures to be followed by manufacturers to validate and deploy their AVs, and identifying some scenarios that need to be tested by manufacturers. Added to previous approaches, due to the difficulties in validating AVs, all the actors around the AV (customers and suppliers) join together in working group to share knowledge and define common generic scenarios. 3.2 Concepts Definition and Their Modeling In order to handle the identification and generation of the scenarios for AVs validation, manufacturers have to clearly define what a scenario is and what it is made up of. From combinatorial approaches [11] to ontology-based approaches [12–14], through the concept of maneuvers [15, 16] methods are multiplying to bring answers. Concepts that mostly appear in the context of these works are scene, situation, event and scenarios. Authors generally adopt definitions that are consistent with their generation approach or they propose new ones according to their own vision. To make sure that definitions are common to all, work is going on to set up a consensus on all these concepts used for scenario generation. Authors [17] reviewed existing definitions [14, 18] of the terms “scene, situation and scenario” and suggested new ones for each of them in the context of Autonomous vehicle. The definitions proposed by Ulbrich et al. have been considered as reference in the primarily version of the Safety of The Intended Functionality (SOTIF). However, they are still subject to discussion. 3.3 Scenario Generation AVs will face a multiplicity of real situations due to the variations of environmental conditions related to traffic conditions, weather, infrastructure, or other road users’ behaviors. Since it is difficult to predict all these situations, manufacturers have to identify new ways to approach and master the scenario generation process. To do that, different solutions have been proposed in the literature. The first one consists in addressing the AV deployment by level of automation. In this way, the vehicle is limited to a number of tactical maneuvers and can perform its mission in an identified area called ODD (Operational Design Domain). The ODD describes the specific operating domain in which the system is designed to function properly. Therefore, scenarios to be generated are limited to this ODD and the generation space can be mastered. In the same logic, another approach is

Safety Demonstration of Autonomous Vehicles

181

the identification of AVs use cases. Since there may be many use cases for AVs, authors generally choose those they consider relevant or consistent with their purpose [19, 20]. Thus, these use cases are studied carefully to generate the scenarios necessary for their evaluation. In addition, some authors propose to focus on special situations: highway situations, intersections situations [21], vulnerable users [22]. Other approaches are based on the possible maneuvering of the vehicles to create dynamics between scenarios and imagine future scenarios [16]. The last identified method is about the prioritization of the scenarios. Menzel et al. [23], proposed a classification for scenarios in three levels of abstraction that can be converted into each other: functional, logical and concrete scenario. The functional scenario describes all the entities and their relations in a linguistic scenario notation understandable by human. The second one, logical scenario; uses the functional scenario to describe it on a state space level with the help of parameter ranges. Finally, concrete scenario permit to add concrete values to precedent parameters defined in logical scenarios. The proposed approaches have proved their necessity. However, they do not give means to ensure the completeness of situations that the vehicle will encounter. Therefore, manufacturers need a complete generation strategy, which includes this estimation or which offers the possibility of extrapolating the generation to scenarios that one would not have thought of.

4 Quantification of Uncertainty - Probabilistic Evaluation of Scenarios and Their Coverage There are exiting methods to address uncertainties [24]: probability theory; fuzzy set or possibility theory and evidence theory. Some have been applied into the design by improving the AV capabilities according to categories of uncertainties they may face. In fact, Althoff et al. [25] presented a method for the safety assessment of trajectories. In the proposed method, the future trajectories are represented as directed graphs and the uncertain states of the obstacles are represented by probability distributions. The safety assessment of the trajectories result in determining their collision probability in dynamic and uncertain environment. Another application is a system design for preventive traffic safety in intersection situations [21]: “it exploits the developed overall probabilistic framework for modeling and analysis of intersection situations under uncertainties in the scene, in measured data or in communicated information.” The intersection situations involve all traffic participants. In their work, Laugier et al. [26], aim at assessing risk of collision for the ego-vehicle. They used a probabilistic approach for the analysis of dynamic scenes and collision risk assessment. The approach takes into account the uncertainties in modelling the environment, detecting and tracking dynamic objects. The last example [27] deals with a situational assessment method to improve the decision-making of Intelligent alternative-energy vehicles (IAVs). The method takes into account the risks of uncertainty in a dynamic traffic environment and the risks assessment is done within and beyond the prediction horizon. It is based on a stochastic model of the environment, an estimation of the collision probability based on trajectory prediction, and the collision probability for the

182

T. F. Koné et al.

planned maneuvers and trajectories. Risk is finally assessed by taking into account the collision time, the mass of vehicles, as well as the relative velocity. One of the identified methods, [28] addresses the consideration of the uncertainty during the overall safety verification of the system. M. Althoff proposes to use the reachability analysis technique for the safety verification of dynamical systems. It consists, for a set of initial states and parameters, in calculating the exact or approximate set of states that can be reached by a system. If the achievable set does not interfere with any set of dangerous states, the safety of the system is guaranteed. To apply it to the safety of AV, he extends the concept to stochastic analysis “stochastic reachability analysis” which will measure the probability of reaching a set of dangerous states. To do this, he use some methods including Markov chains, which approximately computes the stochastic reachable set of arbitrary dynamics. All these methods, by taking into account uncertainty, help with the safety improvement of the capabilities or performance of the systems under development. However, we can barely find some methods which tackle the way of quantifying uncertainties related to scenarios execution during AV safety validation. AV and its operating environment are subjects to uncertainties, and these uncertainties must be evaluated and quantified because they influence the confidence people will have in the validation strategy.

5 Simulation Framework The simulation framework is based on two dimensions: the specification of the validation system and its architecture. 5.1 Specification of an AV Safety Demonstration and Testing System The required system to test and validate the safety of AVs must be able to deal with specific aspects. In the simulation-based toolchain proposed by Hallerbah et al. [29] the safety issue is addressed by the identification of critical scenarios based on a set of metrics that depends on traffic or safety related requirements. Another procedure may be integrated in the test system to manage safety critical scenarios like the scenario-based risk analysis proposed by Galizia et al. [30]. Then, about modules to be integrated, Sun et al. [31] presented a system to test and evaluate the behavior of Unmanned ground vehicles that first includes the test content design, which is modular and designed stage by stage with a level of complexity that is progressive. The system also contains a hierarchical test environment design developed according to the levels of the test content design, the test methods and the evaluation method. In addition, to carry out the testing framework and the test procedure, manufacturers may need to define some guiding principles like the isolation of testing variables, the characterization of the test environment for test repeatability [32]. Other aspects may be incorporated like taking into account uncertainty and the overall evaluation of the level of confidence to attribute to the AV in correlation to its future acceptation.

Safety Demonstration of Autonomous Vehicles

183

5.2 Simulation Architecture for Safety Validation In the automotive engineering literature, architectures have been proposed to tackle the verification and validation of Autonomous systems. First, Sarmiento et al. [33] propose an automated method for generating scenarios. The method starts by the use of RNL (Restricted-form of Natural Language) for the description of the scenarios, and then deduces some Petri-Net models that are used as input to generate the scenarios. It includes a scenarios verification module, a method of model transformation (defined as mapping rules) and criteria for browsing the reachability tree of Petri-Nets to generate scenarios. Then, Mullins et al. [34] developed a testing method of autonomous vehicles, which deals with the issues of the dimensionality of the configuration space and the computational expense of high-fidelity simulations. The method is focused on finding performance boundaries of the system to generate challenging scenarios. It combines the adaptive sampling algorithm with a software-in-the-loop simulation to generate test scenarios. The resulting tool is called RATP (Range Adversarial Planning Tool). Scenarios are clustering according to their similar behaviors using performance type and then boundary sets of these clusters are identified. This helps test engineers with the evaluation of the «trending behaviors of the system». Another test framework for automated driving systems is also proposed by the Department of Transportation, [32]. The proposed test framework targets both Blackbox and White-box testing and each of the core scenario components can be used for both of them. The structure of the test procedures includes aspects such as test subject and purpose, test personnel, facilities, and equipment, test scenario (Input, Initial conditions, Execution, Data measurement and metrics). Guiding principles are defined to carry out the testing framework and the test procedure. Tactical maneuver behaviors, Operational Design Domain (ODD) elements, object and event detection and response (OEDR) capabilities and Failure mode behaviors are identified as the main components of a scenario. In complement to simulation architecture, track testing and open-road testing architectures have been proposed. Finally, Hallerbach et al. [29] propose a simulation-based toolchain for the identification of critical scenarios which consist of a model in the loop testing procedure. The simulation environment includes a vehicle dynamics simulation, a traffic simulation and a cooperation simulation. Newly developed traffic metrics are used in combination with standard safety metrics to determine the criticality of scenarios. The authors defined “critical scenarios as scenarios that need to be tested, regardless, whether the requirements are functional or non-functional.” Questions addressed by the simulation-based toolchain are: the typology of scenarios that have to be tested according to the vehicle development process, the functional and non-functional requirements needed for the evaluation, the consistency of the test with the test environment, the advantages and constraints of a specific test environment. Concrete scenarios are created thanks to a parameter variation module applied to the parameters of logical scenarios. Then tailored metrics are used to classify those concrete scenarios into critical or not critical. Overall, these architectures provide ways to describe, formalize and generate scenarios, and deal with the identification of challenging or critical scenarios and their classification. They also discuss the test structure and the test process. However, none

184

T. F. Koné et al.

of them gives an estimate of the uncertainty associated with the generated scenarios. They also do not give the final level of confidence of the AVs based on the simulated scenarios.

6 Conclusion and Future Research Questions This paper reviewed the question of AV safety validation. First, we identified the difficulties related to the validation process. Then, we focused on the activities related to the simulation-based validation method. Whereas this review can help manufactures to identify the challenges faced by the AVs validation and the necessary activities to process this validation by simulation means, it also produces several research questions that need to be investigated in future work: • Are the concepts retained by the consortium and their definitions suitable to be applied directly to simulation scenarios generation? • Does the validation process take into account the limitations and variations of the performance of the system properly? • How to quantify uncertainty related to scenarios execution and correlate this quantification to the confidence manufacturers can attribute to AVs at the end of the validation process? • Does the identified and selected scenarios be sufficient to test and validate the AVs? Which road tests have to be planned to complete the validation? • How to set up a simulation architecture able, on the one hand, to handle the generation of scenarios taking into account the uncertainty and, on the other hand, to manage the AV safety validation by evaluating, based on the simulated scenarios, the AV safety level? These questions showed that a lot of work is yet to be done in the AV safety validation activity. However, this review does not intend to be exhaustive. Other issues are, for instance, the resistance of AVs against communication attacks, the safety demonstration of AI algorithms, ethical aspects of AV decision-making, the acceptance of AVs by the populations and the reengagement of the driver when there is a failure to hedge the system-level safety for AVs [10]. Authors’ Position Although, many ADAS/AD are already in the street, it must be mentioned that, we still have the driver in the loop to ensure the controllability of the vehicle in critical situations. High or fully AV, which are currently deployed, have someone in the vehicle to take back control in case of performance limitation and are mainly dedicated to the procedure of tests (Open road testing, Track testing); therefore they cannot be placed on the market as long as the safety and regulation issues are not solved. The current challenges for AVs validation are due to the mixed environment, in which they will evolve. The AV will have to deal with the deviations in the behavior of road users (other vehicles, pedestrians, etc.) that it can meet on the road or the environment in general.

Safety Demonstration of Autonomous Vehicles

185

The classification of the SAE about the six levels of automation is a response to deal with the complexity of the environment, as it means that, the deployment of the AV has to be done by defined Operational Design Domain (ODD). This shows that we are aware that the AV will face some situations, in which it could not be able to react, and for which there still be a risk of loss of controllability of the vehicle. This classification also means that, the more we advance in levels of automation, the less the human driver gets involved in the driving task. In other words, the importance of the driving responsibility is now affected to the AV, which is now the guarantor of the vehicle control. Therefore, before reaching one hundred percent of penetration rate for fully AV, the driver will still be the best resort to ensure controllability of the vehicle. So, we believe that the less we will have non-automated vehicles, the less the risk due to their behavioral deviations will be. This may be possible if the penetration rate of fully and safe AV is accelerated. But, due to the difficulties we identified in this review, this is currently not possible. Acknowledgment. This work has been carried out under the financial support of the French National Association of Research and Technology (ANRT in French – convention CIFRE N° 2017/1246) as well as Groupe PSA.

Appendix: Typology of Contents See Tables 1, 2, 3 and 4. Table 1. Classification of papers wrt the AV engineering aspect they addressed Perception Planning/Decision The automated Challenges in Uncertainty Other module module vehicle safety AV safety and risk systems assessment/validation demonstration assessments 5

6, 7, 25, 27

2, 4, 8, 16, 28, 30, 32 9, 10

21, 24, 25, 26, 27, 28, 29, 30

7, 11, 24, 25, 27, 31

Table 2. Classification of papers wrt to the addressed AV solution (The level of automation) ADAS L1 (Driver Assistance), L3 ADS (Conditional ADAS L2 (Partial Automation) Automation), L4 ADS (High Automation)

L5 ADS: Fully automation

3, 11, 16, 26

2, 4, 5, 6, 8, 9, 16, 28

16, 30

186

T. F. Koné et al. Table 3. Classification of papers wrt the addressed safety demonstration method Open road testing Track testing Simulation-based method 2

4

3, 8, 29, 33, 34

Table 4. Classification of papers wrt the addressed scenarios modelling approaches Concepts definitions

Ontology-based method

Concepts of maneuvers

Use cases definitions

Combinatorial test

14, 17, 23

12, 13, 14

15, 16

19, 20

11

References 1. NHTSA. https://www.nhtsa.gov/technology-innovation/automated-vehicles#issue-road-selfdriving 2. Kalra, N., Paddock, S.M.: Driving to Safety. RAND Corp. www.rand.org (2014). https://doi. org/10.7249/RR1478 3. Raffaëlli, L., Vallée, F., Fayolle, G., et al.: Facing ADAS validation complexity with usage oriented testing. In: ERTS (2016). http://arxiv.org/abs/1607.07849 4. Alexander, L., Allen, S., Bindoff, N.L.: Handbook of Intelligent Vehicles, vol. 1 (2013). https://doi.org/10.1017/CBO9781107415324.004 5. Li, Q., Chen, L., Li, M., Shaw, S.L., Nüchter, A.: A sensor-fusion drivable-region and lanedetection system for autonomous vehicle navigation in challenging road scenarios. IEEE Trans. Veh. Technol. 63(2), 540–555 (2014). https://doi.org/10.1109/TVT.2013.2281199 6. Liu, W., Weng, Z., Chong, Z., et al.: Autonomous vehicle planning system design under perception limitation in pedestrian environment. In: CIS-RAM, pp. 159–166 (2015). https:// doi.org/10.1109/ICCIS.2015.7274566 7. Petti, S., Bank, E.I., Fraichard, T.: Safe motion planning in dynamic environments, September 2005 (2014). https://doi.org/10.1109/IROS.2005.1545549 8. Zhao, L., Arbaretier, E., Tlig, M., et al.: Validations par Virtualisation et Simulation: de nouveaux champs méthodologiques et techniques pour une ingénierie de conception sûre des systèmes autonomes (2019) 9. Koopman, P., Wagner, M.: Challenges in autonomous vehicle testing and validation. SAE Int. J. Transp. Saf. 4(1), (2016). https://doi.org/10.4271/2016-01-0128 10. Koopman, P., Wagner, M.: Autonomous vehicle safety: an interdisciplinary challenge. IEEE Intell. Transp. Syst. Mag. 9(1), 90–96 (2017). https://doi.org/10.1109/MITS.2016.2583491 11. Duan, J., Gao, F., He, Y.: Test scenario design for intelligent driving system, August 2018. https://doi.org/10.1007/s12239 12. Geng, X., Liang, H., Yu, B., Zhao, P., He, L., Huang, R.: A scenario-adaptive driving behavior prediction approach to urban autonomous driving. Appl. Sci. 7(4), 426 (2017). https://doi. org/10.3390/app7040426 13. Bagschik, G., Menzel, T., Maurer, M.: Ontology based scene creation for the development of automated vehicles (2017). http://arxiv.org/abs/1704.01006

Safety Demonstration of Autonomous Vehicles

187

14. Geyer, S., Kienle, M., Franz, B., et al.: Concept and development of a unified ontology for generating test and use-case catalogues for assisted and automated vehicle guidance. IET Intell. Transp. Syst. 8(3), 183–189 (2013). https://doi.org/10.1049/iet-its.2012.0188 15. Bach, J., Otten, S., Sax, E.: Model based scenario specification for development and test of automated driving functions. In: Intelligent Vehicles Symposium Proceedings, pp. 1149– 1155, August 2016. https://doi.org/10.1109/IVS.2016.7535534 16. Zhou, J., Re, L.: Reduced complexity safety testing for ADAS & ADF. IFAC-PapersOnLine 50, 5985–5990 (2017). https://doi.org/10.1016/j.ifacol.2017.08.1261 17. Ulbrich, S., Menzel, T., Reschka, A., Schuldt, F., Maurer, M.: Defining and substantiating the terms scene, situation, and scenario for automated driving. In: IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC 2015 (2015). https://doi.org/10.1109/ITSC. 2015.164 18. Dickmanns, E.D.: Dynamic vision for perception and control of motion (2007). https://doi. org/10.1007/978-1-84628-638-4 19. Wachenfeld, W., Winner, H., Gerdes, J.C., et al.: Use cases for autonomous driving. In: Autonomous Driving. Technical, Legal and Social Aspects, pp. 519–521 (2016). https://doi. org/10.1007/978-3-662-48847-8 20. Wilbrink, M., Schieben, A., Markowski, R., et al.: Designing cooperative interaction of automated vehicles with other road users in mixed traffic environments. Definition of interACT use cases and scenarios (1), 0–73 (2017) 21. Weidl, G., Breuel, G.: Overall probabilistic framework for modeling and analysis of intersection situations. In: Networked Vehicles (2012). https://link-springer-com.bases-doc.univlorraine.fr/content/pdf/10.1007%2F978-3-642-29673-4_24.pdf. Accessed 18 Oct 2017 22. Merdrignac, P.: Système coopératif de perception et de communication pour la protection des usagers vulnérables (2015) 23. Menzel, T., Bagschik, G., Maurer, M.: Scenarios for development, test and validation of automated vehicles (2018). http://arxiv.org/abs/1801.08598 24. Lopez, I., Sarigul-Klijn, N.: A review of uncertainty in flight vehicle structural damage monitoring, diagnosis and control: challenges and opportunities. Prog. Aerosp. Sci. 46(7), 247–273 (2010). https://doi.org/10.1016/j.paerosci.2010.03.003 25. Althoff, D., Weber, B., Wollherr, D., Buss, M.: Closed-loop safety assessment of uncertain roadmaps. Auton. Robots 40(2), 267–289 (2016). https://doi.org/10.1007/s10514-015-9452-1 26. Laugier, C., Paromtchik, I., Perrollaz, M., et al.: Probabilistic analysis of dynamic scenes and collision risks assessment to improve driving safety. IEEE Intell. Transp. Syst. Mag. 3 (2011). https://doi.org/10.1109/mits.2011.942779 27. Xie, G., Zhang, X., Gao, H., Qian, L., Wang, J., Ozguner, U.: Situational assessments based on uncertainty-risk awareness in complex traffic scenarios. Sustainability 9(9), 1582 (2017). https://doi.org/10.3390/su9091582 28. Althoff, M.: Reachability analysis and its application to the safety assessment of autonomous cars (2010). https://doi.org/10.1017/CBO9781107415324.004 29. Hallerbach, S., Xia, Y., Eberle, U., Koester, F.: Simulation-based identification of critical scenarios for cooperative and automated vehicles, pp. 1–12 (2018). https://doi.org/10.4271/ 2018-01-1066 30. De Galizia, A., Bracquemond, A., Arbaretier, E.: A scenario-based risk analysis oriented to manage safety critical situations in autonomous driving, pp. 1357–1362 (2018) 31. Sun, Y., Yang, H., Meng, F.: Research on an intelligent behavior evaluation system for unmanned ground vehicles, pp. 1–23 (2018). https://doi.org/10.3390/en11071764 32. DOT - Department of Transportation. A Framework for Automated Driving System Testable Cases and Scenarios, September 2018

188

T. F. Koné et al.

33. Sarmiento, E., Leite, J.C.S.P., Almentero, E., Sotomayor Alzamora, G.: Test scenario generation from natural language requirements descriptions based on Petri-Nets. Electron. Notes Theor. Comput. Sci. 329, 123–148 (2016). https://doi.org/10.1016/j.entcs.2016.12.008 34. Mullins, G.E., Stankiewicz, P.G., Hawthorne, R.C., Gupta, S.K.: Adaptive generation of challenging scenarios for testing and evaluation of autonomous vehicles. J. Syst. Softw. 137, 197–215 (2018). https://doi.org/10.1016/j.jss.2017.10.031

Posters

Model-Based Specification for System Development with Suppliers Phanikrishna Thota1(B) , Simon Hancock1 , Mario Noriega-Fogliani2 , and Rodrigo Jimenez2 1 Airbus Operations, Ltd., Pegasus House, Filton, Bristol BS34 7PA, UK

{Phanikrishna.Thota,Simon.Hancock}@airbus.com 2 AKKA, New Filton House, 20 Golf Course Lane, Bristol BS34 7QW, UK

Abstract. Authoring, validating and communicating system requirements becomes even more important when the development is contracted to an external supplier. This paper illustrates the process of creating and communicating a model-based specification as an alternative to a text-based one in a real-world project called OnePRESS, a digital platform to monitor aircraft tyre inflation pressure. The logical part of the specification is broken down functionally and allocated to the top-level product breakdown. The interfaces for each such function are drawn while considering the actual design as a black-box. An executable Simulink model is then created using library blocks with unique identification, where each library block forms a requirement and are configuration-controlled. A test model is assembled by combining the library blocks and Operational Scenarios are used to validate the assembled test model. The validated model and the associated libraries are delivered to the supplier, and form the basis for the system development.

.

© Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, p. 191, 2020. https://doi.org/10.1007/978-3-030-34843-4_16

Applications of Systems Thinking for Scooter Sharing Transportation System Christina Caches(B) and Mo Mansouri School of Systems and Enterprises, Stevens Institute of Technology, Castle Point on Hudson, Hoboken, NJ 07030, USA [email protected]

Abstract. The scooter sharing system is a service that enables individuals to rent electric scooters for short term rides. The scooters are mostly electric motor scooters but there are some that are electric kick start. The purpose of this system is to transport people short distances in a safe and efficient way. This research was done to define and analyze the scooter sharing transportation system. System thinking is applied to understand, engineer and innovate the scooter sharing system. The scooter transportation system is defined as an interdependent constituent system that applies systemic tools and diagrams like systemigrams. These tools allow for the system properties to be studied along with the interrelationships. There will be different models of the scooter transportation system examined. The stakeholders will be examined to view the interconnections within the system.

.

© Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, p. 192, 2020. https://doi.org/10.1007/978-3-030-34843-4_17

Collaborative Decision-Making Challenges in the Dutch Railway System N. Jakubeit(B) , M. Rajabalinejad, A. J. J. Braaksma, and L. A. M. van Dongen University of Twente, De Horst 2, 7522LW Enschede, The Netherlands [email protected]

Abstract. In the context of systems integration, the railway system needs to pay more attention to organizational interoperability. Companies along the value chain collaborate at the interfaces to accomplish the shared purposes of the system. These collaborations between different stakeholders having different interests and backgrounds demonstrate a demand for an integral approach towards decision-making. This paper investigates in which environment of system change projects within the Dutch Railway system, shared awareness between decision-makers could possibly enhance collaborative decisions. First, a literature review on organizational interoperability and system performance boundaries was conducted. Moreover, the concept of shared situational awareness was introduced to identify its applicability in an organizational context. Afterwards, interviews with key stakeholders of the Dutch Railway system were carried out to recognize the environment in which shared awareness may facilitate integral decision-making. It shows application possibilities in an organizational setting, keeping in mind certain constraints imposed by the environment.

.

© Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, p. 193, 2020. https://doi.org/10.1007/978-3-030-34843-4_18

Understanding Stakeholder Interactions Impacting Human Spaceflight Funding Levels Brian M. Gardner(B) and Mo Mansouri School of Systems and Enterprises, Stevens Institute of Technology, 525 River Street, Hoboken, NJ 07030, USA {bgardne1,mmansour}@stevens.edu

Abstract. Human space exploration is an important endeavor for mankind. Exploration helps us to better understand our environment, offers the possibilities of new resources and the development of technologies to benefit humanity. Due to the complex nature of human spaceflight, programs are generally funded by governments using public funds. This paper uses a systems thinking framework to identify the key stakeholders in the human spaceflight funding system of interest, illuminate the interrelationships between the stakeholder’s interests and demonstrate stakeholder influence on human spaceflight funding levels. The systems thinking assessment of the human spaceflight funding system results in a Causal Loop Diagram which can be used as the starting point for a systems dynamic model.

.

© Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, p. 194, 2020. https://doi.org/10.1007/978-3-030-34843-4_19

Author Index

B Batteux, Michel, 37 Berre, Frédéric, 27 Binder, Christoph, 164 Bisquay, Mathieu, 153 Blume, Steffen O. P., 129 Bonjour, Eric, 176 Braaksma, A. J. J., 193 Brankovic, Boris, 164 Brumbulli, Mihal, 27 Brunet, Jean-Patrick, 153 C Caches, Christina, 192 Cardin, Michel-Alexandre, 129 Chabani, Lyes, 93 Chanvillard, Loic, 64 Choley, Jean-Yves, 37 Collin, Anne, 141 D de Weck, Olivier, 141 Draxler, Dieter, 164 E Echler, Alexander, 14 Efatmaneshnik, Mahmoud, 79 Elam, David, 3 Esteve, Patrick, 93 F Feo-Arenis, Sergio, 117 Frischbier, Sebastian, 14

G Gardner, Brian M., 194 Gaudin, Emmanuel, 27 Géronimi, Stéphane, 176 H Hall, Kyle, 49 Hancock, Simon, 191 Helle, Philipp, 117 Holt, Jonathan, 3 I Imanishi, Yuto, 141 J Jakubeit, N., 193 Jimenez, Rodrigo, 191 Joiner, Keith, 79 K Koné, Tchoya Florence, 176 L Lamothe, Pascal, 153 Langlois, Benoit, 93 Lastro, Goran, 164 Levrat, Eric, 176 M Mansouri, Mo, 103, 192, 194 Matta, Yukti, 141 Mayer, Frédérique, 176 Menegazzi, Pascal, 153

© Springer Nature Switzerland AG 2020 G. A. Boy et al. (Eds.): CSDM 2019, Complex Systems Design & Management, pp. 195–196, 2020. https://doi.org/10.1007/978-3-030-34843-4

196 Mhenni, Faïda, 37 Mitschke, Andreas, 117 Mouchoux, Jacky, 93 N Neureiter, Christian, 164 Noriega-Fogliani, Mario, 191 Normann, Bruce A., 103 P Paic, Mario, 14 Palladino, Luca, 37 Platzer, Willy, 93 Prosvirnova, Tatiana, 37 R Rajabalinejad, M., 193 Rauzy, Antoine, 37 Redmond, Alan Martin, 64 Roth, Christian, 14

Author Index S Sansavini, Giovanni, 129 Schramm, Gerrit, 117 Schroll, Peter, 49 Sharma, Sanjiv, 49 Siddiqi, Afreen, 141 Sohier, Henri, 153 T Tanimichi, Taisetsu, 141 Theobald, Maurice, 37 Thota, Phanikrishna, 191 Tooke, James, 3 V van Dongen, L. A. M., 193 Y Yagoubi, Mouadh, 153 Yesudas, Rani, 79