Simulation and Modeling of Systems of Systems

Pascal Cantot, Dominique Luzeaux

• Publisher: Wiley-ISTE
• Year: 2013
• ISBN:
  9781118616956
• Edition: 1
• Topic: Technology & Engineering
• Subtopic: Electrical Engineering & Telecommunications
• Index: Technology & Engineering

Systems engineering is the design of a complex interconnection of many elements (a system) to maximize a specific measure of system performance. It consists of two parts: modeling, in which each element of the system and its performance criteria are described; and optimization in which adjustable elements are tailored to allow peak performance. Systems engineering is applied to vast numbers of problems in industry and the military. An example of systems engineering at work is the control of the timing of thousands of city traffic lights to maximize traffic flow. The complex and intricate field of electronics and computers is perfectly suited for systems engineering analysis and in turn, advances in communications and computer technology have made more advanced systems engineering problems solvable. Thus, the two areas fed off of one another. This book is a basic introduction to the use of models and methods in the engineering design of systems. It is aimed at students as well as practicing engineers.

The concept of the "systems of systems" is discussed extensively, after a critical comparison of the different definitions and a range of various practical illustrations. It alsoprovides key answers as to what a system of systems is and how its complexity can be mastered.

Chapter 1

Simulation: History, Concepts, and Examples 1

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].

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 vehicle’s 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 car’s 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 interrelations”.

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 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 naïve 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...

Table of contents

• Cover
• Title Page
• Copyright
• Introduction
• Chapter 1: Simulation: History, Concepts, and Examples
• Chapter 2: Principles of Modeling
• Chapter 3: Credibility in Modeling and Simulation
• Chapter 4: Modeling Systems and Their Environment
• Chapter 5: Modeling and Simulation of Complex Systems: Pitfalls and Limitations of Interpretation
• Chapter 6: Simulation Engines and Simulation Frameworks
• Chapter 7: Distributed Simulation
• Chapter 8: The Battle Lab Concept
• Chapter 9: Conclusion: What Return on Investment Can We Expect from Simulation?
• Author Biographies
• List of Authors
• Index