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 7 Solving the Problem Completely, in a Coherent and Optimal Manner ¹

“Nothing is so productive of elevation of the mind as to be able to examine methodically and truly every object which is presented to you in life, and always to look at things to see at the same time what kind of universe this is, and what kind of use everything performs in it, and what value everything has with reference to the whole, and what with reference to man…”

Marcus AURELIUS Meditations, Book III-11

The sequence of technical processes in systems engineering allows us to transform a situation of dissatisfaction, moving from a problem in a given context to the response in the form of an architectural solution. This solution is obtained through the work of a multi-disciplinary team.

Marc and Roger must both direct the technical activities of various individuals with the aim of constructing a coherent and optimal global solution. This means that, at any given moment and as far as possible, the team should share a unique and coherent view of the solution being constructed, and any activity carried out should add to and develop this solution to bring it closer to the final target.

In implementing and directing technical activities in the context of a systems engineering approach, Marc must attempt to:

– Take an iterative and incremental approach: an optimal solution will not be produced all in one go. However, iterations should converge rapidly to the “right” solution. For this to be possible, a certain ...

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 7

Solving the Problem Completely, in a Coherent and Optimal Manner ¹

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.