Architecting Approaches for Systems of Systems

A key part of systems engineering (SE) for system of systems (SoS) is the composition of systems to meet SoS needs. This may include simply interfacing systems and leveraging their existing functionality or it may require changing the systems functionality, performance or interfaces. These changes occur incrementally, as a SoS evolves over time to meet changing SoS objectives. System of Systems Engineering (SoSE) supports these changes by developing and evolving a technical framework that acts as an overlay to the systems of which the SoS is composed. This framework provides the architecture for the SoS. The SoS architecture defines how the systems work together to meet SoS objectives and considers the details of the individual systems and their impact the SoS performance or functionality.

The Role of System of Systems Architecting

An architecture is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE Std 610.12).

In a SoS, the architecture is the technical framework for the systems comprising the SoS which designates how the systems will be employed by the users in an operational setting (sometimes called the concept of operations (CONOPs or CONOPs), the internal and external relationships and dependencies among the constituent systems and their functions and, finally, the end-to-end functionality and data flow as well as communications among the systems.

Because SoS largely comprise extant independent systems, these place constraints on the SoS architecture and may require that migration to a SoS architecture be incremental. Developing a SoS architecture requires consideration of technical feasibility for the constituent systems as well as the needs of the SoS itself. Architecture data for the constituent systems can also be important data for architecting the SoS.

Maier (1998) provides a conceptual discussion on the impact of SoS characteristics on SoS architecting. Additionally, the US DoD SE Guide for SoS (2008) describes practical considerations in developing and evolving a SoS architecture as a core element of SoSE.

Challenges in Architecting SoS

In the case of a new system development, the systems engineer can begin with a fresh, unencumbered approach to architecture. However, in a SoS, the systems contributing to the SoS objectives are typically in place when the SoS is established and the SoS engineer needs to consider the current state and plans of the individual systems as important factors in developing an architecture for the SoS. This, along with the fact that constituent systems may be complex systems in their own right, leads to a set of challenges to architecting SoS.

First, as noted above, the managerial and operational independence of constituent systems can pose major challenges for the SoS architecture. Because systems are likely to continue to face new functional requirements and the need for technology upgrades independent of the SoS, there is an advantage to a SoS architecture, which is loosely coupled; that is, it has limited impact on the individual systems, allowing for changes in functionality and technology in some systems without impact on others or on the SoS objectives. Dagli and Kilicay-Ergin (2009) have suggested that SoS architecting should be considered to be an evolutionary process.

Secondly, the independence of the constituent systems also means that these systems are typically not designed to optimize SoS objectives. In the area of trust for example, a system may severely constrain access to services to provide a level of security and a SoS may depend on free exchange of those services. (Rebovich 2009) has articulated this difficulty as a fundamental problem of SoS:

"From the single-system community's perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an (sic) SoS seen as a net gain from the viewpoint of single-system stakeholders."

Finally, as introduced in the article Emergence, there are risks associated with unexpected or unintended behavior resulting from combining systems that have individually complex behavior. These become serious in cases which safety, for example, is threatened through unintended interactions among the functions provided by multiple constituent systems in a SoS.

Finally, the development and implementation of a SoS architecture may be significantly constrained by a reluctance to make changes or invest in the constituent systems, which could be very mature (e.g. in sustainment) or currently productively supporting other uses. In this case, approaches such as gateways and wrapping may be used to incorporate these systems into the SoS without making significant changes in the other systems.

Architecture Analysis

Large-scale systems integration has grown in importance and correspondingly, there has been a growing interest in SoS concepts and strategies. The performance and functioning of groups of heterogeneous systems has become the focus of various applications including military, security, aerospace, distributed energy, healthcare, and disaster management systems (Lopez 2006; Wojcik and Hoffman 2006). There is an increasing interest in exploiting synergy between these independent systems to achieve the desired overall system performance (Azarnoush, et. al. 2006).

Modeling and simulation is conducted to analyze architecture effectiveness and to verify architectural features. In the literature, researchers have addressed the issues of coordination and interoperability in a SoS (Abel & Sukkarieh 2006; Sahin et. al. 2007). In order to study SoS characteristics and parameters, one needs to have realistic simulation frameworks properly designed for system of systems architecture. There are some attempts to develop simulation frameworks for multi-agent systems using Discrete Event Simulation (DEVS) tools (Zeigler, et. al. 2000a). In these research efforts, the major focus is given to DEVS architecture with JAVA. In (Mittall, 2000b), DEVS state machine approach is introduced. Finally, DEVS Modeling Language (DEVSML) is developed by using XML based JAVA in order to simulate systems in a net-centric way with relative ease. Sahin et. al. (2007) have recently introduced a discrete event XML based SoS simulation framework based on DEVS and JAVA.

The Open Approach to SoS Engineering

As noted above, one of the key challenges with SoS architecting is that the constituent systems of a SoS may not have been designed, developed and employed with regard to their role in the SoS, which constrains SoS architecture options. The degree to the architecture which overlays these constituent systems and supports the SoS end-to-end capabilities can be based on open standards; the SoS may be able to benefit from open architecture for future evolution.

The critical challenge of moving from SoS, as a concept to the engineering of SoS, is the significant technological, human, and organizational differences in consideration system of systems engineering and management approaches (Wells and Sage 2008). A potential approach to engineering a SoS can be the open systems approach to SoSE (Azani 2009). The following open systems principles are listed by Azani (2009):

• Open interface principle - Open systems have permeable boundaries that allow them to exchange mass, energy, and information with other systems;
• Synergism principle – The notion that designates that the co-operative interaction between constituent systems has a greater effect in their combined efforts than the sum of their individual parts. Essentially, this is what gives rise to emergence;
• Self-government principle - This implies that the SoS maintains and develops its internal order without interference from external sources. This could be through cybernetic control, homeostasis, or self-organization;
• Emergence principle - In this case, this refers to the occurrence of novel and coherent structures, patterns, and properties during the self-organization of the SoS;
• Conservation principle – This principle states that energy and mass (material) are conserved within the SoS;
• Reconfiguration principle – This refers to the SoS reconfiguring and adapting itself to sustain itself against changes in its environment;
• Symbiosis principle - The systems within the SoS have a symbiotic relationship to each other; more transparently, the successful development and sustainment of a SoS depends on symbiotic collaboration between the stakeholders of the systems of which it is comprised; and
• Modularity principle - This holds that each level and each system is to some extent independent of others. In SoS design, the development of independent modular systems that interoperate with each other through standardized interfaces enables greater flexibility to promote better evolution of the SoS.

Azani (2009) elaborates on the open systems development strategies and principles utilized by biotic SoS, discusses the implications of engineering of man-made SoS, and introduces an integrated SoS development methodology for the engineering and development of an adaptable, sustainable, and interoperable SoS based on open systems principles and strategies.

Hitchens (2003, 107), on the other hand, discusses the principles of open systems rather differently in terms of their systems life cycles, as the seven principles that he addresses are system reactions, system cohesion, system adaptation, connected variety, limited variety, preferred patterns, and cyclic progression. This description takes a systems dynamics approach to show how open systems evolve; the description is applicable to natural and man-made systems.

The enablers of openness include open standards and open specifications, which draw from consensus amongst a community of interest, and are published by, and freely available within, that community. An open specification must ensure that its detail-level is allows for it to be implementable by independent parties. Compliance with open standards is intended to ensure consistent results (Henshaw, et. al., 2011). This parallels the notion of open systems architecture, which is an open specification of the architecture of a system or system of systems for the purpose of acquiring specified capabilities. As a general feature of good design (for a system or system of systems), an open system architecture should allow for the quick and easy improvement and updating of the system capabilities, by adding or changing components. However, Henshaw et. al. (2011) also denote that open architecture represents a commercial challenge (rather than a technical one) and that establishing open architecture approaches to acquisition can be challenging, due to issues involving protection of intellectual property (IP) and commercial advantage.

Networks and Network Analysis

Because networks are such a common component of SoS, they warrant specific attention. In SoS that are based on an underlying network, communications and information exchange typically constitute a SoS in its own right. This enabling SoS requires architecting like any other SoS, which will be addressed in this section. In the case of an enabling network SoS, the ‘user’, the end-to-end functionality of the larger SoS and enabling network SoS is driven by these user needs. The relationship between SoSE concepts and network enablement, as well as the concepts of networks and network analysis that extend beyond information sharing, have been explored extensively by the defense community (Dickerson and Mavris 2009). For instance, during the U.S. Navy’s work on command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) as part of a SoS (Owens 1996), the term network included organizational aspects of command and control (C2) structure as well as communications.

Differences in the architecting of an enabling network SoS derive from the fact that these SoS are typically built on commercial technologies and architectures, which are changing rapidly in today’s dynamic technological environment. In addition, these enabling networks are often shared among SoS and hence may further constrain the overall SoS architecture. For example, many SoS (for cost and convenience) expect to operate over the internet, and therefore must consider characteristics of the internet in the expectations for performance and security provided by use of a shared enabling infrastructure.

Enabling network SoS architecting is particularly well-served by the initial analysis that explores sensitivities through modeling, simulation, analysis, and/or laboratory experimentation and identifies scalability issues or divergent behavior (e.g., concerning requirements or usage assumptions, assumed network bandwidth, or others), beyond which performance starts to break down. This type of analysis provides a basis for network architecture decisions.

In directed SoS, because of the top-down control, there is the option for creating a specialized network for the particular SoS. In the other types of SoS, if the constituents are already supported by some type of a network then the overall SoS networking approach typically needs to accommodate these since the constituent systems are likely to need to continue to use their current approach to support their original users.

Interoperability

Interoperability within a SoS implies that each system can communicate and interact (control) with any other system regardless of their hardware and software characteristics or nature. This implies that each constituent member (and potential new members) of a SoS should be able to communicate with others without compatibility issues in the operating systems, communication hardware, and so on. For this purpose, a SoS needs a common language the SoS’s systems can speak. Challenges here are to work towards a common language for exchange of information and data among systems of a SoS. Examples of such system are XML (eXtensible Markup Language), as one potential candidate (Jamshidi, 2009a).

However, interoperability must be achieved at many levels and not just at the data/network level. There are a number of frameworks that describe the levels of interoperability. From military applications, the NCOIC (Network Centric Operations Industry Consortium) Interoperability Framework (NCOIC 2008) covers three broad levels of interoperability, subdivided into further layers as indicated below:

• Network Transport
  • Physical Interoperability
  • Connectivity and Network Interoperability

• Information Services
  • Data/Object Model Interoperability
  • Semantic/Information Interoperability
  • Knowledge/Awareness of Actions Interoperability

• People, Processes and Applications
  • Aligned Procedures
  • Aligned Operations
  • Harmonized Strategy/Doctrine
  • Political or Business Objectives

This spectrum of interoperability layers requires appropriate coherence at each layer consistent with the SoS shared goals.

There exist interoperability frameworks in other fields of activity. An example is the European Interoperability Framework (European Commission 2004), which focuses on enabling business (particularly e-business) interoperability and has four levels within a political context:

• Legal Interoperability
• Organizational Interoperability
• Semantic Interoperability
• Technical Interoperability

The interoperability between the component systems of a SoS is a fundamental design consideration for SoS that may be managed through the application of standards.

Standards

Standards of system of systems engineering is perhaps the greatest challenge facing SoSE community. The reason for this assertion is that in SoSE, many areas of systems engineering have yet to fully address other challenges of SoSE. It is a challenging to establish standards for SoS when the architecture, network centricity, control, modeling, simulation, etc. for SoS are yet to mature. Johnson (2009) has surveyed the literature on standards and specifies that currently, with exception of IT service, standards for SoSE is an area of that needs the consideration of organizations like NIST and ISO. This is perhaps the reason that there are currently no standards specifically written for SoS or SoSE products, processes, management, or other endeavors (Johnson 2009); however, there are many standards that address aspects of SoS management (such as ISO 20000 IT service management and the draft ISO 55000 Asset Management) and Interoperability.

Much of the current work in SoS is being done in engineering and acquisition; in the area of engineering the concept of a universally agreed-upon set of guidelines for interoperability is important. These guidelines provide four levels of standardization: compatibility, interchangeability, commonality, and reference (Johnson 2009), which are relevant to the SoS environment through the creation of compatibility, similarity, measurement, and symbol and ontological standardization. As the various disciplines that are relevant to SoS mature, standards will be required to ensure that these four levels of the SoS standardization are met (Jamshidi 2009b).

Interoperability is a key area for standardization. One effort to provide a semantic and syntactic interoperability standard, Levels of Information System Interoperability, was developed by the US DoD C4ISR organization (DoD 1998). Overall, open standards are viewed as an effective way to reduce the risks associated with lack of interoperability in SoS. An open standard is a standard that is consensus-based amongst a community of interest and is published by and freely available within that community of interest (Henshaw et. al 2011). This has been emphasized in the software domain; for instance (Hall 2007), the suggested that the DoD adopt open IT standards and to influence these appropriately through participation in standards developing organizations and/or standards setting organizations in the area of information and communications technologies.

References

Works Cited

Abel, A. and Sukkarieh, S. 2006. "The Coordination of Multiple Autonomous Systems using Information Theoretic Political Science Voting Models." In the Proceedings of the IEEE International Conference on System of Systems Engineering, 24-26 April, Los Angeles.

Azani, C. 2009. A Multi-criteria Decision Model for Migrating Legacy System Architectures into Open Systems and Systems-of-Systems Architectures. Washington, DC, USA:Defense Acquisition University.

Azarnoush, H., B. Horan, P. Sridhar, Madni, A.M., and M. Jamshidi. 2006. "Towards optimization of a real-world robotic-sensor system of systems". In the Proceedings of the World Automation Congress (WAC), July 24-26. Budapest, Hungary.

Cloutier, R.M., J. DiMario, and H.W. Polzer. 2009. "Net-Centricity and System of Systems". Chapter in (Jamshidi 2009a)

Dagli, C.H. and Kilicay-Ergin, N. 2009, "System of Systems Architecting". Chapter in (Jamshidi 2009a)

Dickerson, C.E. and D. Mavris. (2009) Architecture and Principles of Systems Engineering. New York, NY, USA:CRC Press, Auerbach Publications.

DoD. 1998. Levels of Information System Interoperability. Washington, DC, USA: C4IST Interoperability Working Group, US Department of Defense.

Hall, J. 2007. Openness – An Important Principle For The Stewardship of DoD IT Standards. Assistant Deputy Under Secretary of Defense (LMR/LPS), and DoD Standards Executive, in DSPO Journal pg. 4-7, Mar/Jan. http://www.dsp.dla.mil/app_uil/content/newsletters/journal/DSPJ-01-07.pdf

Henshaw, M. (ed.) ...et al. (2011) Assessment of open architectures within defence procurement issue 1: systems of systems approach community forum working group 1 - open systems and architectures. London: Crown owned copyright. (http://hdl.handle.net/2134/8828)

Hitchins, D.K. 2003. Advanced Systems Thinking, Engineering and Management. Norwood, MA, USA: ARTECH HOUSE, INC. (ISBN 1-58053-691-0).

IEEE. 1990. Standard Glossary of Software Engineering Terminology, Std 610.12-1990. Washington, DC: Institute of Electrical & Electronics Engineers (IEEE). (ISBN 1-55937-067-X).

Jamshidi, M. (ed.) 2009. Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA:CRC Press. (ISBN 978-1-4200-6588-6)

Johnson M. 2009. "System of Systems Standards," in System of Systems Engineering - Innovations for the 21st Century. Hoboken, NJ, USA: Wiley.

Lopez D. 2006. "Lessons Learned From the Front Lines of the Aerospace." In the Proceedings of the IEEE International Conference on System of Systems Engineering, 24-26 April, Los Angeles, CA, US.

Mittal, S. 2000. "DEVS Unified Process for Integrated Development and Testing of Service Oriented Architectures." Ph. D. Dissertation, Univ. Arizona.

NCOIC. 2008. "NCOIC Interoperability Framework (NIF(R))". Available at: https://www.ncoic.org/technology/deliverables/nif/

Owens, W.A. 1996. "The Emerging U.S. System-of-Systems." In The National Defense University, Institute of National Security Studies, Number 63, Washington D.C. February.

Rebovich, Jr., G. 2009. Chapter 6: Enterprise System of Systems. Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA: CRC Press, pg. 169.

Sahin, F., M. Jamshidi, and P. Sridhar. 2007. "A Discrete Event XML based Simulation Framework for System of Systems Architectures." In the Proceedings of the IEEE International Conference on System of Systems, 16-18 April 2007, San Antonio, TX, US.

U.S. Department of Defense, 2008, Systems Engineering Guide for Systems of Systems. Version 1.0. August. Washington. DC

Wells, G.D. and A.P. Sage. 2008. Engineering of a System of Systems. Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA: CRC Press.

Wojcik, L.A. and K.C. Hoffman. 2006. "Systems of Systems Engineering in the Enterprise Context: A Unifying Framework for Dynamics." In the Proceedings of the IEEE International Conference on System of Systems Engineering, 24-26 April 2006, Los Angeles, CA, US.

Zachmann, J. 1987. A framework for information systems architecture. IBM SYSTEMS JOURNAL, 26(3).

Zeigler, B.P., T.G. Kim, and H. Praehofer. 2000. Theory of Modeling and Simulation. New York, NY, USA: Academic Press, .

Primary References

Chen, D., G. Doumeingts, F. Vernadat. 2008. "Architectures for Enterprise Integration and Interoperability: Past, Present and Future." Comput.Ind. 9;59(7):647-659.

Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." Systems Engineering 1(4): 267-284.

Additional References

Dickerson, C.E., S.M. Soules, M.R. Sabins, and P.H. Charles. 2004. Using Architectures for Research, Development, and Acquisition. Washington, DC: Office of the Assistant Secretary of The Navy (Research Development And Acquisition). ADA427961. Available at: http://handle.dtic.mil/100.2/ADA427961

European Commission. 2010.Annex to the Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Region, Towards interoperability for European public services. Available at: http://ec.eupora.eu/isa/strategy/doc/annex_ii_eif_en.pdf

Giachetti, R.E. 2010. Design of Enterprise Systems, Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press,

Rhodes, D.H., A.M. Ross, and D.J. Nightingale. 2010. Architecting the System of Systems Enterprise: Enabling Constructs and Methods from the Field of Engineering Systems. Institute of Electrical and Electronics Engineers.

MITRE. 2012. "Architectures Federation." In Systems Engineering Guide. MITRE Corporation. http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/engineering_info_intensive_enterprises/architectures_federation.html. Accessed 11 September 2012.

Mittal, S. 2000a. "Extending DoDAF to Allow DEVS-Based Modeling and Simulation." Journal of Defense Modeling and Simulation (JDMS). 3(2).

Valerdi R., Axelband E., Baehren T., Boehm B., Dorenbos D., et al. 2008. "A research agenda for systems of systems architecting". International Journal of System of Systems Engineering. 1 (1-2): 171-188.

Zeigler, B.P, D. Fulton, P. Hammonds, and J. NutaroJ. 2000. "Framework for M&S–Based System Development and Testing in a Net-Centric Environment." ITEA Journal of Test and Evaluation. 26(3), 21-34.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus