Introduction
This article provides introduction and overview of Department of Defense - Systems Engineering Guide for System of Systems as published the United States DoD Undersecretary of Defense AT&L. The goal of this article is to establish for the reader awareness of the publication and its contents as a significant source of information on system of systems engineering.
Citation Information
Undersecretary of Defense [AT&L]. 2008. Systems Engineering Guide for Systems of Systems, Version 1.0. Washington, DC: Office of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems and Software Engineering.
Example in text citations:
(Undersecretary of Defense [AT&L] 2008).
The document can be accessed at: https://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf
Overview
The US Department of Defense - Defense Acquisition Guide (DAG) introduced the need for joint programs to ensure coordination between independently developed systems that will interface with external systems in its 2004 release. In 2006, the Office of Undersecretary of Defense for Acquisition, Technology and Logistics (USD AT&L) initiated a project to define the aspects and considerations that program managers and systems engineers should address to improve the effectiveness of systems within the broader mission or enterprise construct. The resulting publication, Systems Engineering Guide for System of Systems Engineering, published in 2008. Unlike the evolution of DOD systems engineering the team that created this document relied heavily on industry expertise from within and external to DOD projects to guide the SoS lexicon (Undersecretary of Defense [AT&L] 2008).
SoS Definition
The resulting definition of a system of system is consistent with industry publications, including those by INCOSE 2015 and ISO/IEC/IEEE 15288:2015. AT&L (2008) defines an SoS as “a set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities” (4). This document provides a clear set of definitions for the types of SoS that may exist within an enterprise along with unique characteristics associated with each SoS type. The document also provides some insight into how to use systems engineering activities within the DAG for a system of systems.
A conventional system and a system of systems both align to the definition of a system and the art of systems engineering applies to both types of systems where the SE must consider a broad range of factors beyond the technical design (Undersecretary of Defense [AT&L] 2008; INCOSE 2015). The factors that make an SoS more challenging is the scope, complexity and lack of centralized configuration control of systems within the SoS (INCOSE 2015; Undersecretary of Defense [AT&L] 2008).
This document provides four generally accepted SoS types based on the level of governance and control associated with a given SoS. The below definitions are drawn from Undersecretary of Defense [AT&L] (2008).
- Virtual–SoS that lack a central management authority and a centrally agreed upon purpose for the system-of-systems. Large-scale behavior emerges—and may be desirable—but this type of SoS must rely upon relatively invisible mechanisms to maintain it. (Example: the Internet)
- Collaborative–SoS where component systems interact voluntarily to fulfill agreed upon central purposes. The central players collectively decide how to provide or deny service, thereby providing a means for maintaining and enforcing standards. (Example: consortium of university laboratories)
- Acknowledged–SoS component systems have recognized goals and objectives, a designated manager, and resources. However, the constituent systems retain independent ownership, objectives, funding, development, and sustainment. (Example: Navy carrier strike group consisting of various ships and aircraft linked together through voice and data communication networks)
- Directed–SoS designed, built, and managed to fulfill a central purpose, usually over a long period. Component systems can operate independently, but normally work as an SoS. Example: Satellite and ground station tasking, collection, communication, and processing activities. (2)