book

Complex Systems and Systems of Systems Engineering

by Dominique Luzeaux, Jean-René Ruault, Jean-Luc Wippler

October 2011

Intermediate to advanced

449 pages

13h

English

Wiley

Read now

Unlock full access

Cover
Title Page
Copyright
Author Biographies
Introduction
PART 1: ENGINEERING LARGE-SCALE COMPLEX SYSTEMS AND EMERGENCY SITUATION MANAGEMENT
Chapter 1: Engineering Large-scale Complex Systems
1.1. Introduction1.2. The notion of service in large complex systems1.3. Architecture: a key concept1.4. Towards resilient systems1.4.1. Resilience: definitions1.4.2. Resilience versus dependability1.4.3. Engineering resilience1.4.3.1 Engineering resilience during system use1.4.3.2 Engineering resilience in the system design phase1.4.3.3 Conclusion1.5. Development of relationships between participants1.6. Complexity: plurality of viewpoints for systems engineering1.7. The maintenance and logistics of systems of systems1.8. Perspectives and lines of enquiry1.8.1. Contextual elements1.8.2. Factors of influence1.8.3. Trends, issues and challenges in systems engineering1.8.3.1. Issue 1: very large heterogeneous systems1.8.3.2. Issue 2: very large autonomous systems1.8.3.3. Issue 3: modeling and simulation around the system perimeter1.8.3.4. Issue 4: virtual prototyping of very large systems1.8.3.5. Issue 5: verification, validation and qualification of systems1.8.3.6. Issue 6: knowledge management throughout the system’s lifecycle1.8.3.7. Issue 7: human-centered agile design1.8.4. Development of the engineering process1.8.5. Themes of research1.8.5.1. Modeling: development, analysis and model inversion1.8.5.2. Automatic proof (for decision-making in evolutive multi-system contexts)1.8.5.3. Design of software-intensive complex systems with consideration of the human factor1.8.5.4. Co-design of materials and software1.9. Conclusion1.10. Bibliography
Chapter 2: Management of Emergency Situations: Architecture and Engineering of Systems of Systems
2.1. Introduction2.2. Main concepts of systems engineering2.3. Context of the emergency situation management scenario2.3.1. Global context: Tairétalet2.3.2. Synthesis of the Dubbus accident report2.3.3. Decision of the Tairétalet authorities2.3.4. Analysis of context and participants involved2.3.5. Results of studies on existing resources2.3.6. Emergency situation management scenario: perimeter and architecture2.3.7. Reference operational scenario2.3.8. Alternative operational scenarios2.3.9. Perimeter and component systems of the system of systems2.3.10. System dimensions: lines of development2.4. Architecture of component systems of the system of systems2.4.1. Detecting an accident: the accident detection system2.4.2. Evaluating the gravity of an accident, coordinating the emergency services and allocating casualties to hospitals: the regional call center2.4.3. Casualty evacuation: emergency service centers and hospitals2.4.4. Continuous improvement of emergency situation management2.4.5. Systems engineering for the regional call center, emergency service centers and hospitals2.4.6. Specificities of system of systems engineering2.5. Conclusion2.6. Acknowledgements2.7. Bibliography
PART 2: CASE STUDY: ANTARCTICA LIFE SUPPORT FACILITY
Chapter 3: Introduction to the Antarctica Life Support Facility Case Study
3.1. Why Antarctica?3.2. Fictional context of the study3.2.1. The Antarctica mission3.2.2. The cast of characters3.3. Some data on the Antarctic and Adélie Land3.3.1. Geography3.3.2. Climate3.3.3. Biological patrimony3.3.4. Location of the life support facility3.4. Bibliography

Chapter 4: Finding the Right Problem
4.1. What system are we dealing with?4.1.1. Purpose and missions4.1.2. The system perimeter4.2. System lifecycle4.3. Who does the system involve?4.4. Creating a working framework4.5. Gathering information4.6. Modeling the context4.7. Understanding and defining goals4.8. Modeling the domain4.9. Defining stakeholder requirements and constraints4.10. Things to remember: stakeholder-requirements engineering4.11. Bibliography
Chapter 5: Who Can Solve the Problem?
5.1. Consultation and selection5.1.1. Establishment of an acquisition plan5.1.2. Creating an initial list of companies5.1.3. Organizing and launching a request for information5.1.4. Selecting companies for the call to tender5.1.5. Preparing and launching the call to tender5.1.6. Selecting a partner company5.2. Responding (and winning)5.2.1. Approaching the problem5.2.2. Advancing into the unknown5.2.3. Where should we start?5.2.4. Doing it all simultaneously5.3. Committing to a “right” definition of the system to be created5.3.1. From stakeholder requirements to technical requirements5.3.2. Covering the whole of the System’s lifecycle5.3.3. Accounting for stakeholder expectations and constraints5.3.4. Remaining realistic5.3.5. Removing major risks5.3.6. Facing identified threats5.3.7. Use of precise terminology5.4. Creating the list of technical requirements5.4.1. Creating the necessary model5.4.2. Expressing the “right” technical requirements5.4.2.1. Succinctness5.4.2.2. Formalization5.4.2.3. Structure5.4.3. Compliance with the specification5.5. Things to remember: technical requirements engineering5.6. Bibliography
Chapter 6: Solving the Problem
6.1. General approach6.2. Functional design6.2.1. A brief introduction to functional design6.2.2. Application6.2.2.1. Mission support6.2.2.2. Life support6.2.2.3. Heating6.3. Physical design6.3.1. Identifying physical components6.3.2. Allocation of functions to identified components6.3.3. Grouping components by sub-system6.3.4. Architecture of (some) sub-systems6.3.4.1. “Life support” sub-system6.3.4.2. “Technical support” sub-system6.3.4.3. “Base supervision” sub-system6.3.5. Sub-systems architecture of the life support facility6.4. Interfaces6.4.1. Waste management6.4.2. Centralized supervision6.4.3. Other types of interactions between components6.5. The “playing fields” of the systems architect6.6. EFFBDs6.6.1. An informal introduction to EFFBD diagrams6.6.2. Syntax and structure of EFFBDs6.6.3. Formalization of EFFBDs6.6.4. Verification and validation of EFFBDs6.7. Things to remember: architectural design6.8. Bibliography
Chapter 7: Solving the Problem Completely, in a Coherent and Optimal Manner
7.1. Making the right technical decisions at the right level and the right time7.1.1. Formalizing possibilities7.1.2. Using a multi-criteria analytical approach7.1.2.1 Adopting a decision model7.1.2.2 Creating possible solutions7.1.2.3 Evaluating possible solutions7.1.2.4 Identifying the best solution(s)7.1.3. Reinforcing and optimizing choices7.1.4. Things to remember7.2. Integrating disciplines7.2.1. Integrating dependability7.2.2. Integrating the human factor7.2.3. Things to remember7.3. Bibliography
Chapter 8: Anticipating Integration, Verification and Validation
8.1. Positioning integration, verification and validation8.2. Integration, verification and validation in the system’s lifecycle8.3. Analyzing input8.4. Establishing an integration, verification and validation strategy8.4.1. Identifying integration, verification and validation objectives8.4.2. Stages of integration, verification and validation8.5. Defining the infrastructure8.5.1. Platforms8.5.2. Tools8.5.3. Data8.6. Integration, verification and validation organization8.7. Choosing techniques8.7.1. Review8.7.2. Testing8.7.3. Traceability8.8. Things to remember: integration, verification and validation8.8.1. Activities linked to engineering8.8.2. Anticipation8.8.3. A multi-faceted approach8.8.4. Strategy: a key point8.8.5. The IVV manager: a high-pressure role8.9. Bibliography
Chapter 9: Conclusion to the “Antarctica Life Support Facility” Case Study
9.1. “Before we can manage a solution, we need to find one!”9.2. “Modeling isn’t drawing!”9.3. Implementing systems engineering9.4. Acknowledgements9.5. Bibliography
Conclusion
List of Authors
Index

Content preview from Complex Systems and Systems of Systems Engineering

Chapter 2 Management of Emergency Situations: Architecture and Engineering of Systems of Systems ¹

2.1. Introduction

This chapter is given over to an emergency situation scenario. Our aim is to carry out engineering studies and create the architecture for a system of systems with the objective of improving the general treatment of road accident victims in order to reduce mortality and handicap rates within a region.

The topic of this case study is relevant at European level in light of the eCall and OASIS projects, at national level in France with the ACTIF¹ project [CER 09], and for private organizations with several recent initiatives, including that of the NCOIC.² However, while the treatment of the subject aims to be credible, it is not realistic. The means of tackling the case study, its structure, scenario and hypotheses are fictitious and have been created for instructional and educational reasons, considering structural characteristics of systems of systems. The concepts contained in this case study can easily be transposed to other domains as long as consideration is given to their relevance and capacity for implementation in a relevant manner in these different domains.

In the first section, after a brief overview of the main concepts of systems engineering, we shall present the context of the emergency situation management scenario. We shall then describe the events surrounding a major accident that led to a decision being taken by the authorities of the (fictional) ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781118601488Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Complex Systems and Systems of Systems Engineering

by Dominique Luzeaux, Jean-René Ruault, Jean-Luc Wippler

Chapter 2

Management of Emergency Situations: Architecture and Engineering of Systems of Systems ¹

2.1. Introduction

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.