Difference between revisions of "Architecting Approaches for Systems of Systems"

From SEBoK
Jump to: navigation, search
(Interoperability)
(Interoperability)
Line 57: Line 57:
  
 
==Interoperability==
 
==Interoperability==
[[Interoperability]] within a SoS implies that each system can communicate and interact (control) with any other system regardless of their hardware, 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 such as 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 environment (Jamshidi, 2009a).
+
[[Interoperability (glossary)|Interoperability]] within a SoS implies that each system can communicate and interact (control) with any other system regardless of their hardware, 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 such as 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 environment (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:  
 
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:  

Revision as of 15:50, 16 August 2012

A key part of SE for SoS is composing systems to meet SoS needs. This may include simply interfacing systems and leveraging their existing functionality. It may require changing systems functionality, performance or interfaces. These changes may occur incrementally as a SoS evolves over time to meet changing SoS objectives. SoSE supports these changes by developing and evolving a technical framework that acts as an overlay to the systems which comprise the SoS. This framework provides the architecture for the SoS. The SoS architecture defines how the systems work together to meet SoS objectives and only considers details of the individual systems when they 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 including 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 of the SoS architecture and may require that migration to a SoS architecture will 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 of the impact of SoS characteristics on SoS architecting and 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.

Second, 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 when 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.

Third, 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 where safety, for example, is threatened through unintended interactions among 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. In parallel, there is 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).

Modelling and simulation is conducted to analyse 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 JAVAL 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. To the degree that 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 when considering system of systems engineering and management (Wells and Sage 2008). A potential approach to engineering of SoS can be the open systems approach to SoSE (Azani 2009). The open systems principles listed by Azani (Azani 2009) are:

  • Open interface principle: open systems have permeable boundaries that allow them to exchange mass, energy, and information with other systems.
  • Synergism principle: the co-operative interaction between constituent systems so that their combined effect is greater than the sum of the 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: energy and mass (material) are conserved within the SoS.
  • Reconfiguration principle: the SoS reconfigures and adapts 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.
  • Modularity principle: 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 (Azani 2009) has elaborated the open systems development strategies and principles utilized by biotic SoS, discussed their implications for engineering of man-made SoS, and introduced an integrated SoS development methodology for engineering and development of adaptable, sustainable, and interoperable SoS based on open systems principles and strategies.

(Hitchens, 2003, 107) has expressed the principles of open systems rather differently, in the context of systems life cycles, as the seven principles of 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 should be at a level of detail sufficient to be implementable by independent parties. Compliance with open standards is intended to ensure consistent results (Henshaw, et. al., 2011). These support 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 easy improvement and update of system capabilities by adding or changing components. However, Henshaw et. al. (2011) also note that open architecture represents a commercial challenge (rather than a technical one) and that establishing open architecture approaches to acquisition can be far from easy because of issues associated with 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 those SoS 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 as discussed within 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 has been explored extensively by the defense community, and the concepts of networks and network analysis extend beyond information sharing (Dickerson and Mavris 2009). For instance in U.S. Navy work on C4ISR as part of a SoS (Owens 1996) the term network included organizational aspects of C2 structure as well as communications.

Differences in architecting of 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 hence 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 up-front analyses to explore sensitivities through modeling, simulation, analysis, and/or laboratory experimentation to identify 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 the 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, 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 such as 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 environment (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:

  • 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 challenge 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 a service, standards for SoSE is an area of needy 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; within engineering the concept of a universally agreed-upon set of guidelines for interoperability is important. Such 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 relevant to SoS mature, standards will be required to ensure these four levels of the SoS Standardization are met (Jamshidi 2009b).

Interoperability is a key area for standardization and one effort to provide a semantic and syntactic interoperability standard was the development by US DoD C4ISR organization’s Levels of Information System Interoperability (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) as a strategy for DoD to adopt open IT standards and to influence these appropriately through participation in relevant 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.

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

  • The paper defines and clarifies basic concepts of enterprise architectures. Then an overview on architectures for enterprise integration developed since the middle of the 1980s is presented. The main part of the paper focuses on the recent developments on architectures for enterprise interoperability. The main initiatives and existing works are presented. Future trends and some research issues are discussed and conclusions are given at the end of the paper.

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

  • This is the paper in which the five characteristics of, or criteria for, Systems of Systems are defined. It is the most frequently cited paper for SoS definition.

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,

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

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