System-of-Systems Architecture

The system-of-systems (SoS) architecture approach designs a highly complex system by decomposing it into many smaller and easier to design systems [B30, B31]. These smaller systems interact with each other to provide a unique capability that none of the individual systems can accomplish on its own [B32]. A SoS has five key characteristics [B33]:

• Operational independence of systems

• Managerial independence of systems

• Geographical distribution

• Emergent behavior

• Evolutionary development

Systems are individually developed and evolved, as the architecture of a SoS is the system interfaces [B34, B35]. A recent example is the Defense Advanced Research Projects Agency’s (DARPA’s’) System of Systems Integration Technology and Experimentation (SoSITE) [B36] project, called System-of-systems Technology Integration Tool Chain for Heterogeneous Electronic Systems (STITCHES) [B37, B38].

The INTERSECT SoS architecture consists of different architectural views similar to other SoS standards and efforts, such as the U.S. Department of Defense Architecture Framework (DoDAF) [B5], the United Kingdom Ministry of Defence Architecture Framework (MoDAF) [B39] the 4+1 Architectural View Model [B40] and the IEEE 42010 Standard on systems and software engineering [B41]. The INTERSECT SoS architecture views are based on a hybrid model of the DoDAF and the 4+1 view model:

• The Logical View addresses the logical composition and interactions between the different systems in the overall system. By decomposing the overall system into logical systems, subsystems, services, capabilities and activities, it simplifies the overall design and makes it easier to architect the interactions between the different components.

• The Operational View describes the tasks, activities, procedures, information exchanges/flows from the perspective of the real-world operations stakeholders, i.e., systems administrators, maintenance, facility engineers, system managers, instrument scientists. The operational view captures restrictions that may be necessary to reflect facility constraints and procedures. The intent of the view is to capture the elements needed for the operation and usage of the distributed resources in the SoS.

• The User View is a representation of the SoS that illustrates different human interactions. It does not include interactions between systems themselves. This view highlights the human facing functionality required from the overall system. A person’s view changes depending on their role, which is specific to a context.

• The Data View is a representation of the system from the perspective of data needs and the data framework that needs to exist to support SoS. The data view is a specification for all data aspects of the system as a whole, and includes the conceptual, logical, and physical data models.

• The Physical View provides a mapping of the SoS architecture onto the physical infrastructure. This view enables system designers to determine how to decompose and place the various system components onto the resources that make up the overall system. It provides the understanding of the attributes of the overall system, and allows the it to be configured based on the constraints and capabilities of the underlying components.

• The Standards View defines the standards supported by the SoS and its corresponding views and architecture elements that are impacted by each standard. Such standards are versioned and include messaging standards of the SoS and external standards, such as instrument-specific standards. The standards view defines the set of rules governing the arrangement, interaction, and interdependence of systems.

The INTERSECT SoS architecture addresses different groups, both within and outside of an organization, such as architects, developers, administrators, and end users. The view model enables various stakeholders to establish the impact of the architecture from their own perspective. For each stakeholder role, individual stakeholder concerns can be addressed by the views of the INTERSECT SoS architecture (see Table 3).

Table 3 Stakeholder roles and the INTERSECT SoS architecture views that address them.

Role/View	Logical	Operational	User	Data	Physical	Standards
Application software developers	X		X	X		X
Infrastructure software developers		X		X	X	X
End users	X		X
Security Engineers		X		X	X
Communications engineers				X		X
System-of-system engineers	X	X		X	X	X
Chief engineers /scientists	X		X	X		X
Lead System Integrator		X		X	X
System Integration and test engineers	X	X	X	X		X
External test agencies	X	X	X	X	X
Operational system managers		X	X	X
Maintainers		X	X
Representatives of standardization activities	X	X		X		X

Architectural Views

• Logical View
  • Systems, Subsystems, and Services
  • Adapters for External Resources and Services
  • Error and Failure Notification and Handling
  • Error and Failure Resilience
• Operational View
  • Service Monitoring
  • Health and Diagnostics
  • Approval Processes
  • Cybersecurity
• User View
  • User Roles
  • User Interfaces
  • User Processes
• Data View
  • Entity-Relationship Data Model
  • Messages
  • Object Model
• Physical View
  • Developing the Physical View
• Standards View
  • Internal Standards
  • External Standards