System of Systems Pain—So How Do You Spell R-E-L-I-E-F?

System of Systems (SoS)A system of systems (SoS) brings together a set of systems for a task that none of the systems can accomplish on its own. Each constituent system keeps its own management, goals, and resources while coordinating within the SoS and adapting to meet SoS goals. ISO/IEC/IEEE 15288 Annex G (ISO, 2015)

In a paper titled “System of Systems Pain Points” presented at the 2014 INCOSE International Symposium, Dr. Judith Dahmann reported on the results of the INCOSE System of Systems Working Group survey regarding the “pain points” of the system of systems practice. A number of these are responsive to management with the use of true system models based in a strong metamodel. In this blog, we will explore the use of such models in relieving the pain created by systems of systems.

With apologies to Dr. Dahmann and her colleagues, the pain points are partially summarized below in the aspects that are relevant to this discussion.

SoS Authorities. The typical organizing structure of a system in the traditional systems engineering practice is largely absent among systems of systems. This means that systems engineers must rely on a view that looks across the individual system boundaries to create a picture of the operation of the entire system of systems. With different stakeholders, owners, processes and approaches, this can be challenging.

Leadership. The issues in a system of systems revolve around implementing direction and control across the collection of previously unrelated systems from the system of systems level.

Perspectives. A system of systems is most often comprised of systems that are already up and running in pursuit of their own purposes. That may impose some limitations on how—and how well—they can serve the purposes of the system of systems. In addition, they may well present issues related to how they will interact with the other constituent systems.

Capabilities and Requirements. Beginning with “live” systems as elements turns the “usual” process on its head. The systems engineer starting with already running entities has a significant challenge in adapting to their constraints while taking as much advantage of their capabilities as possible.

Autonomy, Interdependencies and Emergence. The complexity of the system of systems is magnified by the fact that, not only do the entity systems experience internal emergence, but they also create emergence among them at the system of systems level. This complexity on complexity makes predicting outcomes particularly problematic.

Testing, Validation, and Learning. With multiple systems in various lifecycle and development stages, it is extremely difficult to get traditional end-to-end predictive analysis through system testing. This makes accurate, high fidelity modeling one of the few avenues by which to capture system of systems performance without disrupting the constituent systems.

System of Systems Principles. Because the design of systems of systems is a new and relatively uncharted area of endeavor, the systems engineer attempting to bring to bear the power of systems thinking and systems design principles is plowing new ground. Rubrics and heuristics are few and far between.

In her paper, Dr. Dahmann raised questions related to these pain points. Some of these highlight the opportunity for the model-based systems design of systems of systems. The particular questions that stand out are:

1. How can SE address SoS capabilities and requirements?
2. What are effective approaches to integrating constituent systems?
3. How can SE address the complexities of SoS interdependencies and emergent behaviors?

These questions raise issues that model-based systems engineering can address provided that the responsible systems engineers are properly equipped to do so. The power that is needed is best provided through the use of a modeling tool offering a proven metamodel in which to instantiate the solution model under consideration.

A strong systems metamodel provides the conceptual framework in which to build the model, whether at a system or system of systems level. It introduces and maintains discipline and rigor to the modeling process.

This is critically important in dealing with the complexity inherent in systems of systems. Perhaps the best example of this criticality can be seen in the area of emergent behavior in a system of systems. Many of the component systems are complex systems themselves. This means that they are characterized by emergent behaviors which are either “strong” or “weak.” “Strong emergence” is used to describe unexpected emergence; that is, emergence not observed until the system is simulated or tested or, more alarmingly, until the system encounters in operation a situation that was not anticipated during design and development. (Dahmann, 2014, p. 115) “Weak emergence” is that which is desirable or tolerated. In either case, the constituent systems have originally been designed to produce, control or accept their internal emergence given the purpose for which they were designed.

However, in a systems of systems setting, the purpose of the new system is likely to be very different from those of the component systems. In addition, the internal emergence of the constituent systems is augmented by the emergence, strong and weak, that is produced when they are combined with each other. As hard as it is to model, observe, and predict the behavior of the individual, complex components, it becomes exponentially harder to do that at the system of systems level. But this ability to predict is critical to the avoidance of the “unexpected emergence . . . not observed . . . until the system encounters in operation a situation that was not anticipated during design and development.” Hence the painful questions, “What are effective approaches to integrating constituent systems?” “How can SE address SoS capabilities and requirements?” and “How can SE address the complexities of SoS interdependencies and emergent behaviors?”

The best hope for the answers to these questions lies in the discipline and rigor of a model developed in the framework of a strong, proven metamodel. The guidance and structure of a good systems metamodel assures consistency and completeness. The result is a complete and consistent model of the solution system design. A complete, consistent model of the entire system of systems provides the most accurate view into its likely resulting behavior. This view enables the design team to predict and plan for the behavior of the system of systems. It also allows the team to reenter the design if it encounters an unanticipated situation in its operational environment, diagnose the problem, and make adjustments to deal with that obstacle in a way or ways that will produce the desired results. The strength of the metamodel proven in its application provides the framework in which such a model can be constructed.

In a sufficiently robust tool, the solution design is automatically measured up against the metamodel verifying its completeness and consistency. Such a model is the best hope for success—relief from the pain of systems of systems. In the words of the popular commercial, when we journey into the hyper-complex world of systems of systems, we’d best “not leave home without it.”

Leave a Reply