Complexity Theory and SE

Principles ofComplex Systems
for Systems Engineering

Sheard:Principles of Complex Systems for SEPage 1 of 15

Sarah A. Sheard

Third Millennium Systems LLC

1027 Challedon Rd.Great FallsVA22066

(703) 759-2803

Abstract. This paper shows how three systems of types well-known to systems engineers can be understood as complex systems, and what principles can and should apply to developing and improving them. This is important because research in complex systems sciences is vibrant and provides critical insight, but if systems engineers do not understand the “complex systems” aspects of the systems they work with daily, they may not be able to interpret these research results as usable.

The three examples are INCOSE, the systems engineering process (such as a company’s standard process), and air traffic control. INCOSE can represent most volunteer organizations and social groups. The systems engineering process for a company, while familiar to most systems engineers, is a systemthat most systems engineers do not realize is a network that can be studied by complex systems methods. Air traffic control may come closest to many systems engineers’ definition of a system.

This paper presents principles of complex systems from a variety of sources, and shows the specific application of one set of principles to one of the examples.

PREFACE

Systems engineering has evolved without much of a formal or theoretical background for its practices; instead it has relied on experientially developed principles and heuristics.[Defoe 1993][Rechtin 1991][Rechtin and Maier 1997]Fortunately, research in the world of complex systems (known to some as complexity theory) is creating that formal theoretical underpinning that systems engineering can begin to utilize: to explain current practices,and to help model existing systems so that predictive explorations can be made. If mathematical models can predict, for example, holistic performance characteristics, then parameters of the system can be optimized via modeling, rather than by trying a number of possibly wrong answers in developed hardware and software. Early determination of good parameters can help keep systems engineering programs on track and avoid derailment due to late “surprises” and the consequent ripple-effect rework that many such programs experience.

This paper presents a number of Complex Systems principles, selected for their applicability to the development and use of man-made engineering-based systems, i.e., systems engineering.

INTRODUCTION

Systems engineers face complexity in the systems they design, in the environments with which the systems interact, and in the organizations and economies that offer them employment. Understanding complexity can help us learn how to improve our systems by understanding how complexity underlies and affects the environments and the systems.

The recentbook Complex Engineered Systems[Braha, Minai, and Bar-Yam 2006] and the papers collected therein serve as a broad-based yet focused introduction to complex systems for systems engineers.As complete as it is, this book is strong on theory, rather than on practical principles of system engineering. Principles of complex systems and complex systems engineering (CSE) are proposed in the many papers within, but not in a way that many systems engineers have the time to decode.Individual systems engineers have learned about complex systems engineering through their academic encounters, but they have not found a venue to discuss the application of these ideas to day-to-day work. Furthermore, many of the principles being stated by the academics seem overly obvious to systems engineers, who have already discovered them experientially; changes from more typical systems engineering has not been explained well. This paper is intended to show examples and to condense such principles into a capsulized summary suitable for broad INCOSE distribution. The hope is that after organizational rework and review, this can grow into a chapter in the INCOSE handbook [Haskins 2006].

Systems-of-Systems. It should be noted that Systems of Systems is a topic of great interest to systems engineers. The topic was originally defined by [M. Maier 1998]; activity related to Systems of Systems has increased greatly in the last three years. The Department of Defense is now working on a Systems-of-Systems Engineering Guide that presumes there is a System-of-Systems program manager and chief engineer. [DoD AT&L 2006]The Systems of System Center of Excellence [SOSECE 2006] initiated annual systems-of-systems engineering conferences in 2005, with the military as sponsor and primary customer. IEEE started offeringannual Systems-of-Systems conferences in 2006.[IEEE 2006]

Systems of systems issues that differ from systems issuesinclude:

Integration of independently operational component systems that were built for other purposes;
Rapid evolution of both user needs and system technologies, which precludes stable requirements;
Multiple disparate stakeholders with conflicting needs and a lack of incentives to participate in the system of systems;
Distributed development and its consequent communication problems, and
Dependence on an integrated computing infrastructure that has extremely high and increasing complexity and therefore possibilities of unintended consequences.

Are systems of systems complex systems? The answer is yes and no. A system that has a program manager and a chief engineer is by definition not a complex system.(See below: complex systems are built of many independent interacting parts that are not managed by a central integrating body.) However, many systems-of-systems issues are similar to complex systems issues. Ad hoc systems-of-systems are pulled together at the last minute by operational personnel and do not have chief system integrators nor a specific development period [Ferris 2006]. Most of these do qualify as complex systems.

BACKGROUND: COMPLEX SYSTEMS

Complex systems is a field of study that is rife with “overloaded” vocabulary. Words like Enterprise and Architecture are given new meanings [Bredemeyer 2006] as understanding and technology evolve, and each new meaning develops a following.Eventually the followers collide in an interdisciplinary task or meeting. Those who hear other people using the same words tend to assume everyone means the same thing, but in this case, since it isn’t true, each group ends up thinking the other side is being stupid (or has a hidden agenda). It is unfortunately rare that such problems are headed off by a close examination of vocabulary and meanings.

As an example, let us look at a use of the term “complex systems”: “All systems that systems engineers work on are complex. If they weren’t, they wouldn’t need to be systems engineered. Why are you making such a big deal out of complexity when we all have worked with it forever? You must be trying to make money.”The answer is that this paper is using a very specific meaning, that developed by scientists doing research in the area of complexity theory and its follow-ons. This paper uses the word “complex systems” as follows:

Complex systems are systems that do not have a centralizing authority and are not designed from a known specification, but instead involve disparate stakeholders creating systems that are functional for other purposes and are only brought together in the complex system because the individual “agents” of the system see such cooperation as being beneficial for them.

A reasonable and short background in chaos and complexity theory for the systems engineer can be found in [Sheard 2005]. Other material from the INCOSE Systems Science Enabler Group, such as[Sheard 2006], is also supportive.

DETAILED DEFINITION OF COMPLEX SYSTEMS

The following detailed definition collates ingredients of definitions from INCOSE [Sheard 2006] and[Haskins 2006],University of Michigan [UMich 2006], ClemsonUniversity[J. Maier 2006], Mitre Corporation [Norman and Kuras 2006], and the New England Complex Systems Institute[Bar-Yam TBD].

Definition of Complex Systems

Complex systems have many autonomous components, i.e., the basic building blocks are the individual agents of the system
There are a large number of useful potential arrangements of their elements
The elements are heterogeneous (differ in important characteristics), i.e. have variety
The system boundary is often hard to pin down
The structure and behavior of a complex system is not deducible, nor may it be inferred, from the structure and behavior of its component parts
Generally the behavior involves nonlinear dynamics, sometimes chaos, and rarely any long-run equilibrium
Often the agents are organized into groups or hierarchies; in which case the structure influences the evolution of the system (See Figure 1, from [Bar-Yam TBD]).
Such structures tend to highlight a number of different scales, any of which can affect the behavior of the complex system.
Complex systems are self-organizing (show a decrease in entropy due to utilizing energy from the environment)
Complex systems adapt to their environment as they evolve
In particular, as they evolve they continually increase their own complexity, given a steady influx of energy (raw resources)and feedback among elements
Their elements change in response to imposed “pressures” from neighboring elements
Complex systems are non-deterministic, i.e., exhibit unpredictable behavior, including chaotic behavior under certain conditions
Complex systems display emergent macro-level behavior that emerges from the actions and interactions of the individual agents
Complex systems can be said to encompass not only one or more system “artifacts” but also the designers and users of the artifacts, in an open DAU system.Figure 2, from [J. Maier 2006] (used with permission), shows this Designer-Artifact-User system and the relationships among components.

Figure 1. Complex Systems, from Bar-Yam [Bar-Yam TBD]

Figure 2. Generic Designer-Artifact-User (DAU) system in context

DEFINITIONS APPLIED TO EXAMPLES OF COMPLEX SYSTEMS

We will look at the following three examples of complex systems and compare them to the definition of complex system and the principles for engineering complex systems.

INCOSE
The systems engineering process within a company
The National Airspace System (air traffic control system)

Systems engineers should be familiar with most of these.

Table 1 shows that all three examples have all attributes listed above and therefore that these are complex systems as defined above.

Table 1. Complex System Examples

INCOSE / SE Process / National Airspace System
Autonomous interacting parts (agents) / Members, CAB companies, working groups, chapters / Process activities, SE artifacts / Airlines, airplanes, airports, air traffic controllers, databases, flying public, navigation aids, pilots, transportation security, towers, etc.
Fuzzy Boundaries / Who in CAB does it include?What about various cross-organizational joint efforts? / Interfaces with program management and with software are particularly fuzzy. Also, company vs. customer process; many more. / Rules for handoffs and sharing of passenger data among various countries; relationship to airlines, e.g. can the NAS require airlines to put equipment such as data transceivers on airplanes so that air traffic control can be more reliable? Frequent flier programs involve hotels, etc.
Structure / Hierarchical formal governance, plus informal / Policies, auditing, change boards / Regulations, certification, laws
Self-organization (emergent order) / Members form interest groups and chapters; also groups of friends / Process activities slip until another activity frees up a resource to perform them / Airlines prefer hubs for maintenance and operational economies; competition forces fares to similar structures
Can’t design or run top-down because... / Volunteer organization; SEs don’t try to fit into predetermined boxes; technology and competitors evolve (e.g. software-intensive systems, SOSs) / Interactions with other changing processes; no one group understands all the activities or rationales. / Airlines can go out of business, buy each other, or go bankrupt. Airlines compete on flight routes. Oil prices are essentially uncontrollable. Poten-tial passengers respond differently to various ticket pricing schemes.
Nonlinearity / Number of attendees at a conference varies signifi-cantly from year to year for reasons not linearly related to conference price. / Small errors in requirements can destroy program progress, particularly when discovered late. / Reducing the flight time between cities (or ticket price) a small amount (to below competitors’) can increase an airline’s number of passengers greatly.
Structure not deducible from structure of component parts / As with any social institution, structure is not tied to human bodies / How activities are laid out in a process is not related to the structure of the activities or how they are documented / Patterns of jet flight (air routes, VFR/IFR rules, hubs, weather delays) are not determinable from the structure of aircraft or even airports.
Energy in and out (examples) / Member dues and fees paid by members from personal or company funds. Members bring energy to INCOSE cause. / Process change boards eliminate low-value activities / Jet fuel, public demand for transportation, stockholders fund airlines, fees fund government; military supplies trained pilots, pilots retire...
Adaptation to surroundings (environment) / INCOSE meetings compete for members with IEEE, AIAA, and other groups, for example by creating certification program. / SE process takes up the slack where other processes fall short; adapt to changing standards (CMMI). / Take new security measures in the face of terror threats. Build new airports with environmental safe-guards. Airplanes bought from competing airplane manufacturers.
Become more complex with time; increasingly specialized / Multiplying and specializing working groups; governance structure includes positions not imagined 10 years ago; certification and certification preparation courses / Create specialized processes for various kinds of programs (large, small, IT-intensive, military, fixed-price). / Rapid evolution to stay ahead of terrorists. Choose bigger airplanes for popular routes. Offer new frequent-flyer privileges; airline personnel specialize jobs, e-tickets, passenger data requirements...
Elements change in response to imposed pressures from neighboring elements / Members may change their working group participation depending on who else is in it; chapters improve to earn chapter awards, members write papers using previous papers as sources. / Later activities must shorten if earlier activities run long. SEs delay new steps if earlier steps are not resolved or anomalies are found. / Airports designated as hubs by airlines can build new terminals and even runways. Airlines adjust prices depending on other airlines’ pricing structures. Flying public adjusts travel plans or ticketing procedures (e.g. back-to-back tickets take advantage of supersaver fares for work trips).
Developer-Artifact-User (DAU) system components / D: Members (same as users)
A: Working group structures, processes for submitting and reviewing symposium papers;
U: Members, paper presenters, participants in working groups, elected and appointed officials. / D: Systems Engineering process group (at least , the description of the process)
A: Process descriptions (usually on-line, can be paper)
U: Those who enact the process. Also, managers and receivers of metrics. / D: Companies who build systems to be used for air traffic control.. FAA acquisition organizations.
A: Air traffic control software and hardware systems. Data recorders, navigational aids, communications devices, airplanes, jetways, baggage loaders, runways, runway information.
U: Flying public, pilots, homeowners (noise levels), employees of airlines and FAA, many others.

COMPLEX SYSTEMS SCIENCE

Key concepts of Complex Systems science are:[Sheard 2006]

Emergence: Emergence is related to the dependence of the whole on parts, the interdependence of parts, and specialization of parts. While studying the parts in isolation does not work, the nature of complex systems can be probed by investigating how changes in one part affect the others, and the behavior of the whole.
Pattern formation: simple mathematical models capture pattern formation such as local activation / long range inhibition.
Multiple (meta-) stable states: Small displacements (perturbations) lead to recovery, and larger ones can lead to radical changes of properties. Dynamics do not average simply.
Multi-scale descriptions are needed to understand complex systems. Fine scales influence large scale behavior.
It is difficult but not impossible to answer the question "How complex is it?"
Behavior (response) complexity: To describe the behavior of a system we try to describe the response function: actions as a function of the environment. However, unless simplifying assumptions are made, this requires an amount of information that grows exponentially with the complexity of the environment.
Contrasts. Complex systems often exhibit contrasting characteristics, including simplicity and complexity, order and disorder, random and predictable behavior, repeating patterns and change
We cannot predict what a complex system will evolve into.

The complex adaptive systems cycleis shown in the first column of Table 2.[Gell-Mann 1994] The other three columns show how our example systems evolve in accordance with this cycle.

Table 2. Complex Adaptive Systems Cycle Applied to Examples

Example:
CAS Cycle: / INCOSE / SE Process / National Airspace System
I. Coarse graining of information from the real world / Understand systems engineering as practiced, and abstracting enough to create principles and advice / Understand what is being done on projects / Extract needs from multiple ATC customers
II. Identification of perceived regularities / Identify repeated patterns in SE work / Note similar activities done by systems engineers to engineer systems / Identify requirements for the next generation ATC system.
III. Compression into a schema / Create principles and guidance, possibly as standards / Document practices as activities, and order abstracted versions into a typical process / Write operational and requirements documents
IV. Variation of schemata / Seek review of guidance from multiple places / Programs tailor standardized processes / Use multiple systems, at least old and new
V. Use of the schema / Communicate guidance and standards to members / Programs use tailored processes / Put new systems in action alongside old systems
VI. Consequences in the real world exerting selection pressures that affect the competition among schemata / CAB member companies choose which activities to include in their systems engineering and choose which standards to use and support. / Programs do better or worse depending in part on how much SE is done and how well...this gets back to the SE process group and successes are captured / Only go to new system if controllers can manage it and it’s better, or at least not obsolete and not worse.

DIFFERENCES BETWEEN SE AND COMPLEX SYSTEMS ENGINEERING