c1.jpgcoverdownload.e-bookshelf.de/download/0000/8137/27/l-g-0000813727... · c4o6.ni.za tialoat...

File AttachmentC1.jpg

File Attachmentcover.jpg

Simulation and Modeling of Systems of Systems

Simulation and Modeling of Systems of Systems

Edited by Pascal Cantot

Dominique Luzeaux

First published 2011 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc. Adapted and updated from Simulation et modlisation des systmes de systmes : vers la matrise de la complexit published 2009 in France by Hermes Science/Lavoisier LAVOISIER 2009

Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address:

ISTE Ltd John Wiley & Sons, Inc. 27-37 St Georges Road 111 River Street London SW19 4EU Hoboken, NJ 07030 UK USA

www.iste.co.uk www.wiley.com

ISTE Ltd 2011 The rights of Pascal Cantot and Dominique Luzeaux to be identified as the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.

____________________________________________________________________________________ Library of Congress Cataloging-in-Publication Data

Simulation et modelisation des systemes de systemes. English Simulation and modeling of systems of systems / edited by Pascal Cantot, Dominique Luzeaux. p. cm. Includes bibliographical references and index. ISBN 978-1-84821-234-3 1. Systems engineering--Data processing. 2. Computer simulation. I. Cantot, Pascal. II. Luzeaux, Dominique. III. Title. TA168.S522813 2011 003--dc22

2011006656

British Library Cataloguing-in-Publication Data A CIP record for this book is available from the British Library ISBN 978-1-84821-234-3 Printed and bound in Great Britain by CPI Antony Rowe, Chippenham and Eastbourne.

Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Simulation: History, Concepts, and Examples . . . . . . . . . . . 1 Pascal CANTOT

1.1. Issues: simulation, a tool for complexity. . . . . . . . . . . . . . . . . . . 1 1.1.1. What is a complex system? . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.2. Systems of systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.3. Why simulate? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.4. Can we do without simulation?. . . . . . . . . . . . . . . . . . . . . . 12

1.2. History of simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.1. Antiquity: strategy games . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.2. The modern era: theoretical bases . . . . . . . . . . . . . . . . . . . . 15 1.2.3. Contemporary era: the IT revolution . . . . . . . . . . . . . . . . . . 18

1.3. Real-world examples of simulation. . . . . . . . . . . . . . . . . . . . . . 24 1.3.1. Airbus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.2. French defense procurement directorate . . . . . . . . . . . . . . . . 26

1.4. Basic principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1.4.2. Typology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

1.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 1.6. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapter 2. Principles of Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Pascal CANTOT

2.1. Introduction to modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.2. Typology of models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.2.1. Static/dynamic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.2.2. Deterministic/stochastic . . . . . . . . . . . . . . . . . . . . . . . . . . 59

vi Simulation & Modeling of Systems of Systems

2.2.3. Qualities of a model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.3. The modeling process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.3.1. Global process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 2.3.2. Formulation of the problem . . . . . . . . . . . . . . . . . . . . . . . . 68 2.3.3. Objectives and organization. . . . . . . . . . . . . . . . . . . . . . . . 70 2.3.4. Analysis of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.3.5. Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 2.3.6. Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 2.3.7. Coding/implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2.3.8. Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 2.3.9. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 2.3.10. Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 2.3.11. Use of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 2.3.12. Final report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 2.3.13. Commissioning/capitalization. . . . . . . . . . . . . . . . . . . . . . 90

2.4. Simulation project management. . . . . . . . . . . . . . . . . . . . . . . . 91 2.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 2.6. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Chapter 3. Credibility in Modeling and Simulation . . . . . . . . . . . . . . . 99 Roland RABEAU

3.1. Technico-operational studies and simulations . . . . . . . . . . . . . . . 99 3.2. Examples of technico-operational studies based on simulation tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.2.1. Suppression of aerial defenses . . . . . . . . . . . . . . . . . . . . . . 101 3.2.2. Heavy helicopters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.3. VV&A for technico-operational simulations . . . . . . . . . . . . . . . . 102 3.3.1. Official definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.3.2. Credibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.3.3. Key players in the domain. . . . . . . . . . . . . . . . . . . . . . . . . 105

3.4. VV&A issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.4.1. Elements concerned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.4.2. Verification and validation techniques . . . . . . . . . . . . . . . . . 114 3.4.3. VV&A approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 3.4.4. Responsibilities in a VV&A process . . . . . . . . . . . . . . . . . . 141 3.4.5. Levels of validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 3.4.6. Accreditation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

3.5. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 3.5.1. Validation techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 3.5.2. Validation approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 3.5.3. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

3.6. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Table of Contents vii

Chapter 4. Modeling Systems and Their Environment . . . . . . . . . . . . . 159 Pascal CANTOT

4.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 4.2. Modeling time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

4.2.1. Real-time simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 4.2.2. Step-by-step simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 161 4.2.3. Discrete event simulation . . . . . . . . . . . . . . . . . . . . . . . . . 162 4.2.4. Which approach? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 4.2.5. Distributed simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

4.3. Modeling physical laws. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 4.3.1. Understanding the system . . . . . . . . . . . . . . . . . . . . . . . . . 163 4.3.2. Developing a system of equations . . . . . . . . . . . . . . . . . . . . 164 4.3.3. Discrete sampling of space . . . . . . . . . . . . . . . . . . . . . . . . 165 4.3.4. Solving the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

4.4. Modeling random phenomena . . . . . . . . . . . . . . . . . . . . . . . . . 166 4.4.1. Stochastic processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 4.4.2. Use of probability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 4.4.3. Use of statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 4.4.4. Random generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 4.4.5. Execution and analysis of results of stochastic simulations . . . . . 175

4.5. Modeling the natural environment . . . . . . . . . . . . . . . . . . . . . . 178 4.5.1. Natural environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 4.5.2. Environment databases . . . . . . . . . . . . . . . . . . . . . . . . . . 178 4.5.3. Production of an SEDB . . . . . . . . . . . . . . . . . . . . . . . . . . 180 4.5.4. Quality of an SEDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 4.5.5. Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 4.5.6. Multiplicity of formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

4.6. Modeling human behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 4.6.1. Issues and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 4.6.2. What is human behavior? . . . . . . . . . . . . . . . . . . . . . . . . . 194 4.6.3. The decision process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 4.6.4. Perception of the environment . . . . . . . . . . . . . . . . . . . . . . 197 4.6.5. Human factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 4.6.6. Modeling techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 4.6.7. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

4.7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Chapter 5. Modeling and Simulation of Complex Systems: Pitfalls and Limitations of Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Dominique LUZEAUX

5.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 5.2. Complex systems, models, simulations, and their link with reality . . . 209

viii Simulation & Modeling of Systems of Systems

5.2.1. Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 5.2.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 5.2.3. The difficulty of concepts: models, modeling, and simulation . . . 215

5.3. Main characteristics of complex systems simulation . . . . . . . . . . . 218 5.3.1. Nonlinearity, the key to complexity . . . . . . . . . . . . . . . . . . . 218 5.3.2. Limits of computing: countability and computability. . . . . . . . . 223 5.3.3. Discrete or continuous models . . . . . . . . . . . . . . . . . . . . . . 226

5.4. Review of families of models . . . . . . . . . . . . . . . . . . . . . . . . . 228 5.4.1. Equational approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 5.4.2. Computational approaches . . . . . . . . . . . . . . . . . . . . . . . . 232 5.4.3. Qualitative phenomenological approaches . . . . . . . . . . . . . . . 237 5.4.4. Qualitative structuralist approach: application of category theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

5.5. An example: effect-based and counter-insurgency military operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 5.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 5.7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Chapter 6. Simulation Engines and Simulation Frameworks . . . . . . . . . 253 Pascal CANTOT

6.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 6.2. Simulation engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

6.2.1. Evolution of state variables . . . . . . . . . . . . . . . . . . . . . . . . 254 6.2.2. Management of events and causality . . . . . . . . . . . . . . . . . . 255 6.2.3. Simulation modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 6.2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

6.3. Simulation frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 6.3.1. Some basic points on software engineering . . . . . . . . . . . . . . 260 6.3.2. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 6.3.3. Obstacles to framework use. . . . . . . . . . . . . . . . . . . . . . . . 270 6.3.4. Detailed example: ESCADRE . . . . . . . . . . . . . . . . . . . . . . 272

6.4. Capitalization of models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 6.5. Conclusion and perspectives. . . . . . . . . . . . . . . . . . . . . . . . . . 291 6.6. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Chapter 7. Distributed Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Louis IGARZA

7.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 7.1.1. The principle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 7.1.2. History of distributed simulations . . . . . . . . . . . . . . . . . . . . 297 7.1.3. Some definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 7.1.4. Interoperability in simulation . . . . . . . . . . . . . . . . . . . . . . . 300

Table of Contents ix

7.1.5. Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 7.1.6. Advantages and limitations of distributed simulation. . . . . . . . . 303 7.1.7. Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

7.2. Basic mechanisms of distributed simulation . . . . . . . . . . . . . . . . 305 7.2.1. Some key principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 7.2.2. Updating attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 7.2.3. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 7.2.4. Time management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 7.2.5. Dead reckoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 7.2.6. Multi-level modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 7.2.7. Section conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

7.3. Main interoperability standards . . . . . . . . . . . . . . . . . . . . . . . . 312 7.3.1. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 7.3.2. HLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 7.3.3. DIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 7.3.4. TENA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 7.3.5. The future of distributed simulation: the LVC AR study. . . . . . . 324 7.3.6. Other standards used in distributed simulation. . . . . . . . . . . . . 325

7.4. Methodological aspects: engineering processes for distributed simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

7.4.1. FEDEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 7.4.2. SEDEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 7.4.3. DSEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

7.5. Conclusion: the state of the art: toward substantive interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 7.6. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Chapter 8. The Battle Lab Concept . . . . . . . . . . . . . . . . . . . . . . . . . 333 Pascal CANTOT

8.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 8.2. France: Laboratoire Technico-Oprationnel (LTO) . . . . . . . . . . . . 336

8.2.1. Historical overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 8.2.2. Aims of the LTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 8.2.3. Principles of the LTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 8.2.4. Services of the LTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 8.2.5. Experimental process . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 8.2.6. Presentation of an experiment: PHOENIX 2008 . . . . . . . . . . . 345 8.2.7. Evaluation and future perspectives of the LTO . . . . . . . . . . . . 349

8.3. United Kingdom: the Niteworks project . . . . . . . . . . . . . . . . . . . 350 8.4. Conclusion and perspectives. . . . . . . . . . . . . . . . . . . . . . . . . . 351 8.5. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

x Simulation & Modeling of Systems of Systems

Chapter 9. Conclusion: What Return on Investment Can We Expect from Simulation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Dominique LUZEAUX

9.1. Returns on simulation for acquisition . . . . . . . . . . . . . . . . . . . . 355 9.2. Economic analysis of gains from intelligent use of simulations . . . . . 357

9.2.1. Additional costs of the SBA . . . . . . . . . . . . . . . . . . . . . . . 358 9.2.2. Additional costs from unexpected events or bad planning . . . . . . 364

9.3. Multi-project acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 9.4. An (almost) definitive conclusion: conditions for success . . . . . . . . 368 9.5. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Author Biographies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

List of Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Introduction

In fields such as aeronautics, transport, telecommunications, banking, or defense, systems are becoming increasingly complex, containing more and more components, with significant heterogeneity and disparate lifecycles. The update process that follows the increasingly rapid obsolescence of sub-systems requires a priori mastery of architectures of systems of which we do not know the component configuration. Risk mitigation in the different phases of the project (from the expression of need to implementation, or even withdrawal, considering environmental protection constraints) thus becomes an essential consideration throughout the whole lifecycle of the system.

Needs have also evolved. Demands in terms of performance, interoperability, cost, security, and reliability have reached a level where each project becomes a technical and managerial challenge. It is, therefore, necessary to attain new levels of flexibility and reactivity in exploring system concepts. The changeable nature of the environment and the necessary capacity of the system to adapt to different evolutions contribute to its complexity. Moreover, the generalization of information and communication technologies pushes towards the interconnection of systems, leading to systems of systems, reinforced by the context of globalization of exchanges giving rise to shared developments between economic partners: this raises questions of integration, coherency, and interoperability of one system with a higher-level system. Finally, budget, time, profitability, and time to market constraints require mastery of acquisition costs: the utility of reuse becomes evident.

With such a wide variety of constraints, particular tools and processes are needed in the area of system engineering and system-of-systems engineering. Among these tools, modeling and simulation have already proven their utility and demonstrated possibilities of reducing cycle time, resource usage, and risks associated with system acquisition, while improving the quality of the systems in question and reducing global possession costs. However, the expected gains can

xii Simulation & Modeling of Systems of Systems

only be achieved if modeling and simulation are used in the light of suitable processes, which typically take their inspiration from convergent engineering.

This work is neither an encyclopedia nor a simulation manual, although it does contain certain didactic aspects. It aims to allow the reader be they an engineer, project manager, sponsor, or manager to acquire a basic grounding in the field of simulation and to understand how simulation can help in mastering the challenges of complex systems and systems of systems. This work will also show situations in which simulation does not help; simulation not only has many qualities but also has specific limitations and constraints.

Each chapter may be read independently, but we would strongly recommend reading Chapter 1 first. Chapter 1 gives a first cultural overview of simulation. A brief historical summary shows the origins of the discipline, followed by an explanation of the broad basic principles of simulation. Examples taken from areas particularly concerned with complex system problems (e.g. aeronautics and defense) give an initial glimpse of the uses of simulation by large companies

Chapter 2 describes a typical model and simulation engineering process, followed by a detailed explanation of each step, illustrated by numerous examples to assist understanding.

Chapter 3 is dedicated to the reliability of data, models, and simulations. When decisions (e.g. design choices) are based on the results of a simulation, it is important to know how far the results of the simulation in question can be trusted. This consideration is of fundamental importance and demands particular attention, as much from the developer of the simulation as from the user or purchaser.

Chapter 4 deals with techniques used in modeling different aspects of a system. This section is slightly more technical, but it is important to understand what demands can reasonably be made of a simulation (and what we can reasonably expect to pay), and what this implies, for example, in terms of data collection, technology, development time, or processing power.

Chapter 5 tackles the specific case of complex systems. Without going into the mathematical detail often found in articles dealing with complexity, the principal characteristics are pointed out, information that we should keep in mind when concerned with the modeling and simulation of systems of this kind. In spite of being aware of precautions necessary when using complex systems, frequent users of models and simulations can easily revert to old habits, ignoring the traps and limitations found when using simulations.

Introduction xiii

Chapter 6 covers the software engineering aspect of simulations and describes how simulations are built, based on a foundation software infrastructure known as a host structure, which notably provides the core of the simulation, the simulation driver. This chapter provides an understanding of the development and operation of simulations from an IT viewpoint alongside strategies for use when developing and acquiring a simulation system.

Chapter 7 is based on Chapter 6 by dealing with a particular architecture, that of distributed simulations, which are particularly well suited to modeling complex systems and systems of systems, but which have their own specific set of problems. A good deal of work is currently being undertaken on these simulation construction techniques, which present numerous possibilities for development as long as they are used correctly.

Chapter 8 concerns a new concept in system capacity and system-of-system engineering: battle labs, laboratories of engineering, system and system-of-system architecture. Battle labs use a variety of tools and techniques, including simulation, in addition to processes and an organization. Although the battle lab concept is relatively new, their great potential is already evident.

Finally, Chapter 9, which serves as a conclusion, goes back over certain cost aspects linked to simulation, used in an integrated manner in the engineering process for increasingly complex systems.

We, the editors, hope that this work will assist the reader in understanding simulation in the context of complex system and system-of-systems engineering, a area in which it constitutes a valuable tool, albeit one with its own specificities, pitfalls, and limits, the mastery of which is essential to use the tool to its full potential.

We would like to thank those individuals and businesses or organizations, other than the contributing authors, who have helped us in the creation of this work (with a very special mention for Jean-Louis Igarza for the dynamism and energy he communicated to several generations, including some of his managers!), especially Christian Sautereau, Stphane Chaigneau, Eric Lestrade, Eric Pdo, Jrme Martinet, the ONERA, THALES Training & Simulation, SOGITEC, EADS, MBDA, and, more generally, the members of the ADIS group (Armes, DGA, Industriesur la Simulation)1.

1 Armed Forces, DGA (Defense Procurement Directorate) and Defense Industry on Modeling and Simulation.

xiv Simulation & Modeling of Systems of Systems

Finally, we would like to dedicate this work to the memory of our colleagues and friends Guy Zanon and Pierre Bouc, early contributors on distributed simulation and the validation of simulation, who actively participated in the development of the concepts presented in Chapters 3 and 7.

We hope you enjoy reading this work and gain as much pleasure from reading it as we did in writing it.

Pascal CANTOT and

Dominique LUZEAU March 2011

Chapter 1

Simulation: History, Concepts, and Examples

1.1. Issues: simulation, a tool for complexity

1.1.1. What is a complex system?

The world in which we live is rapidly advancing along a path toward complexity. Effectively, the time when component parts of a system could be dealt with individually has passed: we no longer consider the turret of a tank in isolation but consider the entire weapon system, with chassis, ammunition, fuel, communications, operating crew (who must be trained), maintenance crew, supply chain, and so on. It is also possible to consider the tank from a higher level, taking into account the interactions with other units in the course of a mission.

We thus pass from a system where a specific task is carried out to a system of systems accomplishing a wide range of functions. Our tank, for example, is now just one element in a vast mechanism (or force system), which aims to control the aeroterrestrial sphere of the battlefield.

Therefore we must no longer use purely technical system-oriented logic, but use system-of-systems-oriented capacity-driven logic1 [LUZ 10, MAI 98].

Chapter written by Pascal CANTOT. 1 [LUZ 10] defines a system of systems as follows: a system of systems is an assembly of systems which could potentially be acquired and/or used independently, for which the developer, buyer and/or the user aim to maximize performance of the global value chain, at a given moment and for a conceivable group of assemblies. We shall consider another definition, supplied by Maier, later on, which approaches the concept by extension rather than intension.

2 Simulation & Modeling of Systems of Systems

This is also true for a simple personal car, a subtle mixture of mechanics, electronics, and information technology (IT), the conception of which considers manufacturing, marketing, and maintenance (including the development of an adequate logistics system) and even recycling at the end of the vehicles useful life, a consideration which is becoming increasingly important with growing awareness of sustainable development and ecodesign. Thus, the Toyota Prius, a hybrid vehicle of which the component parts pollute more than average, has an end-of-life recycling potential, which is not only high, but also organized by the manufacturers who, for example, offer a bonus for retrieval of the NiMH traction battery, the most environmentally damaging of the cars components. In this way, the manufacturer ensures that the battery does not end up in a standard refuse dump, but instead it follows the recycling process developed at the same time as the vehicle. In spite of this, the manufacturer is able to remain competitive.

These constraints place the bar very high in engineering terms. Twenty years ago, systems were complicated, but could be simplified by successive decompositions which separated the system into components that were easy to deal with, for example, a gearbox, a steering, and an ignition. Once these components were developed and validated, they could simply be integrated following the classic V model. Nowadays, engineers are confronted more and more often with complex systems, rendering a large part of the development methods used in previous decades invalid and necessitating a new approach.

Thus, what is a complex system? Complex systems are nothing new, even if they have gained an importance in the 21st century. The Semi-Automatic Ground Environment (SAGE) aerial defense systems developed by the United States in the 1950s, or Concorde in the 1960s, are examples of complex systems even if they were not labeled as such. SAGE can even be considered a system of systems. However, the methods involved were barely formalized, leading to errors and omissions in the system development processes. In 1969, Simon [SIM 69] defined a complex system as being a system made of a large number of elements which interact in a complex manner. Jean-Louis Le Moigne gave a clearer definition [LEM 90]: The complexity of a system is characterized by two factors: on the one hand, the number of constituent parts, and on the other, the number of inter-relations.

Globally, then, we shall judge the complexity of a system not only by the number of components but also by the relationships and dependencies between components. A product of which a large proportion is software thus becomes complex very rapidly. Other factors of complexity exist, for example, human involvement (i.e. multiple operators) in system components, the implication of random or chaotic phenomena (which make the behavior of the system non-deterministic), the use of very different time scales or trades in sub-systems, or the

Simulation: History, Concepts, and Examples 3

rapid evolution of specifications (changeable exploitation environment). An important property of complex systems is that when the sub-systems are integrated, we are often faced with unpredicted emergences, which can prove beneficial (acquisition of new capacities) or disastrous (a program may crash). A complex system is therefore much more than the sum of its parts and associated processes. Therefore, it can be characterized as non-Cartesian: it cannot be analyzed by a series of decompositions. This is the major (but not the only) challenge of complex system engineering: mastery of these emergent properties.

On top of the intrinsic complexity of systems, we find increasingly strong exterior constraints that make the situation even more difficult:

increasing number of specifications to manage;

increasingly short cycles of technological obsolescence; system design is increasingly driven by new technologies;

pressure from costs and delays;

increasing necessity for interoperability between systems;

larger diversity in product ranges;

more diverse human involvement in the engineering process, but with less individual independence, with wide (including international) geographic distribution;

less acceptance of faults: strict reliability constraints, security of individuals and goods, environmental considerations, sustainable development, and so on.

To manage the growing issues attached to complexity, we must perfect and adopt new methods and tools: modern global land-air defense systems could not be developed in the same way as SAGE developed in the 1950s (not without problems and major cost and schedule overruns). Observant readers may point out that a complex system loses its complexity if we manage to model and master it. It is effectively possible to see things this way; for this reason, the notion of complexity evolves with time and technological advances. Certain systems considered complex today may not be complex in the future. This work aims to contribute to this process.

1.1.2. Systems of systems

In systems engineering, numerous documents, such as the ISO/IEC 15288 norm, define processes that aim to master system complexity. These processes often reach their limits once we reach a situation with systems of systems. If we can, as a first step, decompose a system of systems hierarchically into a group of systems which


cooperate to achieve a common goal, the aforementioned processes may be applied individually. However, to stop at this approach is to run considerable risks; by its very nature, a system of systems is often more than the sum of its parts.

It would, of course, be nave to restrict the characterization of systems of systems to this property, but it is the principal source of their appeal and of risks. A system of systems is a higher-level system which is not necessarily a simple federation of other systems.

Numerous definitions of systems of systems can be found in current literature on this subject: [JAM 05] gives no less than six, and Chapter 1 of [LUZ 10] gives more than 40. In this case, we shall use the most widespread definitions, based on the so-called Maier criteria [MAI 98]:

operational independence of constituent systems (which cooperate to fulfill a common operational mission at a higher level, i.e. capacitive);

functional autonomy of constituent systems (which operate autonomously to fulfill their own operational missions);

managerial independence of constituent systems (acquired, integrated, and maintained independently);

changeable design and configuration of the system (specifications and architectures are not fixed);

emergence of new behaviors exploited to improve the capacities of each constituent system or provide new capacities (new capacities emerge via the cooperation of several systems not initially developed for this purpose);

geographical distribution of the constituent systems (from whence the particular and systematic importance of information systems and communication infrastructures in systems of systems).

As a general rule, the main sources of difficulties in mastering a system of systems are as follows:

intrinsic complexity (by definition);

the multi-trade, multi-leader character of the system, which poses problems of communication and coordination between the various individuals involved, who often come from different cultural backgrounds;

uncertainty concerning specifications or even the basic need, as mastery of a system of systems presents major challenges for even the most experienced professionals. This difficulty exists on all levels, for all involved in the acquisition process, including the final user and the overseer, who may have difficulties


expressing and stabilizing their needs (which may legitimately evolve due to changes in context, e.g. following a dramatic attack on a nation or a major economic crisis), making it necessary to remain agile and responsive regarding specifications;

uncertainty concerning the environment, considering the number of people concerned and the timescale of the acquisition cycle, which may, for example, lead to a component system or technology becoming obsolete even before being used. This is increasingly true due to the growing and inevitable use of technologies and commercial off-the-shelf products, particularly those linked to information and communications technology which leads to products becoming obsolete with increasing speed.

To deal with these problems, a suitable approach, culture, and tools must be put into place. Simulation is an essential element of this process but is not sufficient on its own. Currently, there is no fully tested process or magic program that is able to deal with all these problems, although the battle lab approach does seem particularly promising as it has been developed specifically to respond to the needs of system-of-systems engineering. This approach involves battle labs and is described in detail in Chapter 8.

1.1.3. Why simulate?

As we shall see, a simulation can be extremely expensive, costing several million euros for a system-of-systems simulation, if not more. The acquisition of the French Rafale simulation centers, now operational, cost around 180 million euros (but generates savings as it removes the need to buy several Rafale training aircraft, with one aircraft costing more than double the price of the centers before even considering the maintenance costs involved in keeping them operational). The American JSIMS inter-army program was another example of this kind, but it was stopped after over one billion dollars of investment. These cases are, admittedly, extreme, but they are not unique. Some of these exceedingly costly simulation systems are themselves complex systems and have been known to fail. If, then, a simulation is so difficult to develop, why simulate?

First, a word of reassurance: not all simulation programs are so expensive, and not all are failures. By following rigorous engineering procedures, notably, and a number of the processes described in the present work, it is possible to guarantee the quality of simulations, as with all industrial products. Second, simulation is not obligatory but is often a necessary means to an end. We shall review the principle constraints that can lead to working with simulations to achieve all or part of a goal.


1.1.3.1. Simulating complexity

Those who have already been faced with system engineering, even briefly, will be aware of just how delicate a matter the specification and development of current systems is. The problem is made even trickier by the fact that current products (military or civilian) have become complex systems (systems of systems). We do not need to look as far as large-scale air traffic control systems or global logistics to find these systems; we encounter them in everyday life. Mobile telephone networks, for example, may be considered to be systems of systems, and a simple modern vehicle is a complex system. For these systems, a rigorous engineering approach is needed to avoid non-attainment of objectives or even complete failure.

In this case, simulation can be used on several levels:

simulation can assist in the expression of a need, allowing the client to visualize their demands using a virtual model of the system, providing a precious tool for dialog between the parties involved in the project, who often do not have the same background, and guaranteeing sound mutual understanding of the desired system;

this virtual model can then be enriched and refined throughout the system development process to obtain a virtual prototype of the final system;

during the definition of the system, simulation can be used to validate technological choices and avoid falling into a technological impasse;

during testing of the system, simulations developed during the previous stages can be used to reduce the number of tests needed and/or to extend the field of system validation;

when the system is finally put into operation, simulations can be used to train system operators;

finally, if system developments are planned, existing simulations facilitate analysis of their impact on the performance of the new system.

These uses show that simulation is a major tool for system engineering, to the point that nowadays it is difficult to imagine complex system engineering without simulation input. We shall not go any further into this subject at present as we shall discuss it later, but two key ideas are essential for the exploitation of simulation in system engineering:

Simulation should be integrated into the full system acquisition process to achieve its full potential: this engineering concept is known as simulation-based acquisition (SBA, see [KON 01]) in America and synthetic environment-based acquisition (see [BOS 02]) in the United Kingdom (the different national concepts have different nuances, but the general philosophy is similar).


The earlier simulation is used in a program; the more efficient it will be in reducing later risks.

To understand the issue of risk reduction, we shall provide a few statistics: according to the Standish Group [STA 95], approximately one-third of the projects (in the field of IT) do not succeed. Almost half of all projects overrun in terms of cost by a factor of two or more. Only 16% of projects are achieved within the time and cost limitations established at the outset, and the more complex the project, the further this figure decreases: 9% for large companies, which, moreover, end up deploying systems which lack, on average, more than half of the functionality initially expected. We have, of course, chosen particularly disturbing figures, and recent updates to the report have shown definite improvements, but the 2003 version [STA 95] still shows that only one-third of projects are achieved within the desired cost and time limitations. This represents an improvement of 100%, but there is stillroom for a great deal of progress to be made.

1.1.3.2. Simulation for cost reduction

Virtual production is costly, admittedly, but often cheaper than real production. The construction of a prototype aircraft such as the Rafale costs hundreds of millions of euros. Even a model can be very expensive to produce. Once the prototype or model arrives, tests must be carried out, which in turn carry their own costs in terms of fuel and the mobilization of corresponding resources. Finally, if the test is destructive (e.g. as in the case of missile launches), further investment is required for each new test.

For this reason, in the context of ever-shrinking budgets, the current tendency is toward fewer tests and their partial replacement by simulation, with the establishment of a virtuous simulation-test circle [LUZ 10]. The evolution of numbers of tests during the development of ballistic missiles by the French strategic forces, a particularly complex system, is explained in this respect:

The first missile, the M1, was developed in only 8 years, but at great cost. Modeling was used very little, and a certain level of empiricism was involved in the tests, of which there were 32 (including nine failures).

For the M4, slightly more use was made of simulation, but major progress was essential due to the implementation of a quality control process. Fourteen tests were carried out, including one failure.

During the development of the M51, which represented a major technological leap forward, simulation was brought to the fore to reduce flight and ground tests, with the aim of carrying out less than 10 tests.


Nevertheless, it should be highlighted that, contrary to all too widespread beliefs, simulation is not in principle intended to replace testing: the two techniques are complementary. Simulation allows tests to be optimized, allowing better coverage of the area in which the system will be used with, potentially, fewer real tests. Simulation is not, however, possible without tests, as it requires real-world data for parameters for models and for validation. Without this input, simulation results could rapidly lose all credibility.

Figure 1.1 illustrates this complementarity: it shows the simulation and a test of armor penetration munitions, carried out with the OURANOS program at the Gramat research center of the Defense Procurement Directorate (Direction gnrale de larmement, DGA). The simulation allows a large number of hypotheses to be played out with minimum cost and delay, but these results still need to be validated by tests, even if the number of tests is reduced by the use of simulation. Chapter 3 gives more detail on the principle of validation of models and simulations.

Figure 1.1. Comparison of simulation and real test (DGA/ETBS)

One area in which simulation has been used over the course of several decades is in the training of pilots. The price range of a flight simulator certified by the aviation authorities (Federal Aviation Administration (FAA), USA; Joint Aviation Authorities (JAA), Europe; and so on) is sometimes close to that of a real airplane (from 10 to 20 million euros for an evolved full flight simulator and approximately 5 million euros for a simplified training-type simulator2). The Rafale simulation center in Saint-Dizier, France, costs a trifling 180 million euros for four training simulators. Obviously, this leads to questions about whether this level of investment is justified. To judge, we need a few more figures concerning real systems. To keep to the Rafale example, the catalog price of one airplane is over 40 million euros, meaning it is not possible to have a large number of these aircraft. Moreover, a certain number must be reserved for training. The use of simulation for a large part 2 A very basic trainer for a precise task, for example, learning to use navigation instruments, can cost less (tens of thousands of euros), but for our purposes, we shall refer to complete systems (full flight and/or full mission).


of the training reduces the number of aircraft unavailable for military operations. Indeed, approximately 50 aircraft would be needed to obtain the flight equivalent of the Rafale Training Center (Centre de simulation Rafale, CSR) training. Moreover, the real cost of an airplane is considerably more than its catalog price. Frequent maintenance and updates are required, alongside fuel, all of which effectively doubles or triples the total cost of the system over its lifespan. An hours flight in a Mirage 2000 aircraft costs approximately 10,000 euros, and an hour in a Rafale costs twice that figure3. The military must also consider munitions; a simple modern bomb costs approximately 15,000 euros, or more depending on the sophistication of the guiding system. A tactical air-to-ground missile costs approximately 250,000 euros.

An hour in a simulator costs a few hundred euros, during which the user has unlimited access to munitions. We need not continue . Moreover, the simulator presents other advantages: there is no risk to the students life in case of accident, environmental impact (and disturbance for the inhabitants of homes near airfields) is reduced, and the simulator offers unparalleled levels of control (e.g. the instructor can choose the weather, the time of flight, and simulate component failures).

In this case, why continue the training using real aircraft? Simulation, as sophisticated as it may be (and in terms of flight simulators, this can go a long way) cannot replace the feelings of real flight. As in the case of tests, simulation can reduce the number of hours of real flight while providing roughly equivalent results in terms of training. For the Rafale, a difficult aircraft to master, between 230 and 250 h of flight per year, are needed for pilots to operate efficiently, but the budget only covers 180 h. Without simulation, the Rafale pilots could not completely master their weapons systems. We are therefore dealing with a question of filling a hole in the budget rather than an attempt to reduce flight hours. Note, though, that in civil aviation, so-called transformation courses exist, which allow pilots already experienced in the use of one aircraft to become qualified on another model of the same range through simulation alone (although the pilot must then complete a period as a co-pilot on the new aircraft).

1.1.3.3. Simulation of dangerous situations

Financial constraints are not the only reason for wishing to limit or avoid the use of real systems. Numerous situations exist where tests or training involves significant human, material, or environmental risks.

To return to the example of flight simulation, international norms for the qualification of pilots (such as the Joint Aviation Requirements) demand that pupils

3 The cost per hour of flight of the Rafale aircraft is a subject of controversy. From Cour des Comptes [CCO 04], we estimate the figure to be 35,000 euros per hour for the first aircraft, but the figure is certainly lower nowadays.


be prepared to react to different component failures during flight. It is hard to see how this kind of training could be carried out in real flight, as it would put the aircraft and crew in grave danger. These breakdowns are therefore reproduced in the simulator to enable the pupil to acquire the necessary reflexes so that the instructor can test the pupils reactions.

On a different level, consider the case of inter-army and inter-ally training: given the number of platforms involved, the environmental impact would be particularly significant. Thus, the famous NATO exercise, Return of Forces to Germany (REFORGER), training which measured the capacity of NATO to send forces into Europe in the case of conflict with the Soviet Union and its allies involved, in the 1988 edition, approximately 97,000 individuals, 7,000 vehicles, and 1,080 tanks, costing 54 million dollars (at the time), of which almost half was used to compensate Germany for their environmental damage. In 1992, the use of computer simulations allowed the deployment to be limited to 16,500 individuals, 150 armored vehicles, and no tanks, costing a mere 21 million dollars (everything is relative ). The most remarkable part of this is that the environmental damage in 1992 cost no more than 250,000 dollars.

1.1.3.4. Simulation of unpredictable or non-reproducible situations

Some of our readers may have seen the film Twister. Setting aside the fictional storyline and Hollywood special effects, the film concerns no more, no less than an attempt by American researchers to create a digital simulation of a tornado, a destructive natural phenomenon which is, alas, frequent in the United States. As impressive as it is, this phenomenon is unpredictable, thus difficult to study, hence the existence of tornado chaser scientists, as seen in the film. In this movie, the heroes try to gather the data required to build and validate a digital model. This appears to be very challenging, as tornadoes are unpredictable and highly dangerous, and their own lives are threatened more than once. However, the stakes are high; simulation allows better understanding of the mechanisms which lead to the formation of a tornado, increasing the warning time which can be given.

Simulation thus allows us to study activities or phenomena that cannot be observed in nature because of their uniqueness or unpredictability. The dramatic tsunami of December 2004 in the Indian Ocean, for example, has been the subject of a number of simulation-based studies. The document [CEA 05], a summary of works published by the French Alternative Energies and Atomic Energy Commission (Commissariat l'nergie atomique et aux nergies alternatives, CEA), shows how measurements were carried out, then the construction of digital models, which enabled events to be better understood and, whether we can avoid repetition of the terrible consequences of the tsunami, which left around 200,000 dead, is still in question.


1.1.3.5. Simulation of the impossible or prohibited

In some cases, a phenomenon or activity cannot be reproduced experimentally. A tsunami or a tornado can be reproduced on a small scale, but not, for example, a nuclear explosion.

On September 24, 1996, 44 states, including France, signed the Comprehensive Test Ban Treaty (CTBT). By August 2008, almost 200 nations had signed. By signing and then ratifying the treaty 2 years later, France committed itself to not carrying out experiments with nuclear weapons. Nevertheless, the treaty did not rule out nuclear deterrence, nor evolutions in the French arsenal; how, though, can progress be made without tests?

For this reason, in 1994, the CEA and, more specifically, the directorate of military applications launched the simulation program. With a duration of 15 years and a total cost of approximately 2 billion euros, the program consists of three main sections:

An X-ray radiography device, Airix, operational since 2000, allows us to obtain images of implosion of a small quantity of fissionable material, an event which allows a nuclear charge to reach critical mass and spark a chain reaction and detonation. Of course, as these experiments are carried out on very small quantities, there is no explosion. To measure these phenomena over a duration of 60 ns (i.e. thousandths of a second), the most powerful X-ray generator in the world (20 MeV) was developed.

The megajoule laser (LMJ) allows thermonuclear micro-reactions to be set off. Under construction near Bordeaux at the time of writing, the LMJ allows the conditions of a miniature thermonuclear explosion to be reproduced by focusing 240 laser beams with a total power of 2 million joules on a deuterium and tritium target. The project is due for completion in 2012.

The TERA supercomputer has been operational since 2001 and is regularly updated. One of the most powerful centers of calculation in Europe, TERA-10, the 2006 version, included more than 10,000 processors, giving a total power of 50,000 teraflops (billions of operations on floating-point numbers per second), and was classed at number 7 on the global list of supercomputers (according to the Top 500 list, www.top500.org).

Moreover, to provide the necessary data for the simulation program (among other things), President Jacques Chirac took the decision in 1995 to re-launch a program of nuclear tests in the Pacific, a decision which had major consequences for the image of France with other countries.

http://www.top500.org


This allows us to measure the scale of the most important French simulation program of all time, which aims to virtualize a now prohibited activity; in this case, simulation is essential, but it is not simple to put into operation, nor is it cheap.

1.1.4. Can we do without simulation?

Simulation is a tool of fundamental importance in systems engineering. We should not, however, see it as a magic solution, a miraculous program which is the answer to all our problems far from it.

Simulation, while presenting numerous advantages, is not without its problems. What follows is a selection of the principal issues.

Simulation requires the construction of a model, which can be difficult to construct, and the definition of parameters. If the system being modeled does not already exist, the selection of parameters can be tricky and may need to be based on extrapolations of existing systems, with a certain risk of errors.

The risk of errors is considerably reduced by using an adequate process of checks and validation, but processes of this kind are costly (although they do provide considerable benefits, as with any formalized quality control process).

In cases where a system is complex, the model is generally complex too, and its construction, as well as the development of the simulation architecture, requires the intervention of highly specialized experts. Without this expertise, there is a serious risk of failure, for example, in choosing an unstable, invalid, or low-performing model.

The construction of a model and its implementation in a simulation are expensive and time consuming, factors which may make simulation inappropriate if a rapid response is required, unless a pre-existing library of valid and ready-to-use models is available in the simulation environment.

The implementation of a complex model can require major IT infrastructures: note that the worlds most powerful supercomputers are mainly used for simulations.

The correct use of simulation results often is not an easy task. For example, when simulating a stochastic system a fairly frequent occurrence when studying a system of systems results vary from one implementation to another so that data from several dozen implementations of the simulation are sometimes required before reliable results can be obtained.

Other methods that can help resolve problems without resorting to simulation exist. These methods are generally specific to certain types of problem but can provide satisfactory results.


After all, 100 years ago, we got along without simulation. Admittedly, systems were simple (non-complex) and designed empirically, for the most part, with large security margins in their specifications. Reliability was considerably lower than it is today. Nevertheless, one technique used is still frequently encountered: real tests on models or prototypes, that is, the construction of a physical model of the system. For example, we could build a scale model of an airplane which could be put in a wind tunnel to study the way the air moves around the model, from which the behavior of the full-scale aircraft in the same circumstances can be deduced. This scaling down is not necessarily without its problems, as physical phenomena do not always evolve in a linear manner with the scale of the model, but the theoretical process is relatively well understood. On the other hand, the uses of this kind of model are limited: they cannot accomplish missions, nor can a wind tunnel reproduce all possible flight situations (without prohibitively expensive investment in the installation). Flying models can be built, for example, NASAs X43A, a 3.65 m long unpiloted model airplane, equipped with a scramjet motor and able to fly at Mach 10. Of course, numerous simulations were used to reach this level of technological achievement, but the time came when it was necessary to pass to a real model: the results of the simulations needed to be validated, in a little-understood domain, that of aerobic hypersonic flight. Moreover, from a marketing point of view, a model accomplishing real feats (the model in question has a number of entries in the Guinness Book of Records) is much easier to sell to the public and to backers than a computer simulation, much less credible to lay people (and even to some experts).

Models are therefore useful, even essential, but can also be expensive and cannot reproduce all the capacities of the system. A prototype would go further toward reproducing the abilities of the real system, but it is also too expensive: each of the four prototypes of the Rafale costs much more than the final aircraft, produced in larger numbers.

Using models, we are able to study certain aspects of the physical behavior of the system in question. The situation is different if the system under study is an organization, for example, the logistics of the Airbus A380 or the projection of armed forces on a distant, hostile territory. There are still techniques and tools other than simulation which can be used to optimize organizations, for example, constraint programming or expert systems, but their use is limited to certain specific problems.

For the qualification of on-board computer systems and communication protocols, mathematical formal systems (formal methods), associated with ad hoc languages (Esterel, B, Lotos, VHDL, and so on), are used to obtain proof of validity of system specifications (completeness, coherence, and so on). These methods are effective, but somewhat ungainly and their operation requires a certain level of expertise. These methods also cannot claim to be universal.


Finally, simulation does not remove the interest of collaborative working and making use of the competences of those involved in the system throughout its life. This is the case of the technico-operational laboratory (laboratoire technico-oprationnel, LTO) of the French Ministry of Defense, a main actor in the development of systems of systems for defense. We shall discuss this in Chapter 8. When dealing with a requirement, the work of the LTO begins with a period of reflection on the subject by a multi-disciplinary work group of experts in a workgroup laboratory (laboratoire de travail en groupe, LTG). Simulation is used as a basis for reflection and to evaluate different architectural hypotheses. The LTO is a major user of defense simulation, but it has also shown that by channeling the creativity and analytical skills of a group of experts using rigorous scientific methods, high-quality results may be obtained more quickly and at lower cost than by using simulation.

Simulation, then, is an essential tool for engineering complex systems and systems of systems, but it is not a magic wand; it comes with costs and constraints, and if used intelligently and appropriately, it can produce high-quality results.

1.2. History of simulation

Simulation is often presented as a technique which appeared at the same time as computer science. This is not the case; its history does not begin with the appearance of computers. Although the formalization of simulation as a separate discipline is recent and, indeed, unfinished, it has existed for considerably longer, and the establishment of a technical and theoretical corpus took place progressively over several centuries.

The chronology presented here does not pretend to be exhaustive; we have had to be selective, but we have tried to illustrate certain important steps in technical evolution and uses of simulation. It is in the past that we find the keys of the present: in the words of William Shakespeare, whats past is prologue.

1.2.1. Antiquity: strategy games

The first models can be considered to date from prehistoric times. Cave paintings, for example, were effectively idealized representations of reality. Their aim, however, was seemingly not simulation, so we shall concentrate on the first simulations, developed in a context which was far from peaceful.

Even before the golden age of Pericles in Greece and the conquests of Alexander the Great, a sophisticated art of war developed in the East. Primitive

c1.jpgcoverdownload.e-bookshelf.de/download/0000/8137/27/l-g-0000813727... · c4o6.ni.za tialoat...

Documents