SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space and Airborne Systems

The objective of this chapter is to (i) define System-of-Systems Enterprise (SOSE), SOSE Concept of Operations (CONOPS), and SOSE Architecture (SOSEA) CONOPS assessment, and (ii) discuss their differences using examples from existing space and airborne systems. The chapter also describes the SOS design challenges and presents an SOSE Architecture design approach addressing these challenges. In addition, DOD Architecture Framework Version 2.02 (DODAF-v2.02) views will be discussed along with a recommendation for a set of key DODAF views to capture system architecture artifacts with practical examples involving SOS Enterprise architectures for notional space-based communications system and manned airborne Intelligence, Surveillance, and Reconnaissance (ISR) platform.


Introduction
Currently, from a combined space and airborne perspective, one can categorize existing "enterprises" as: (i) military enterprise, (ii) civilian enterprise, and (iii) commercial enterprise for space and airborne applications. This chapter uses existing U.S. Department of Defense (DOD) and The International Council on Systems Engineering (INCOSE) definitions on System-of-Systems (SOS) and Family-of-Systems (FOS) [1][2][3] to define these enterprises through the use of practical examples and design scenarios. Figure 1 illustrates the space SOSE concept in general. As an example, current commercial space enterprise consists of (i) • System architecture design is very challenging in SOS environment because of the transition from "requirement-based" to "capability-based" to avoid stovepipe solution. For a stovepipe requirement-based system design, a set of technology enablers 1 is chosen at the time of the design, and the system requirements are derived from that selected set of technology enablers and then they are flown-down to subsystems and associated hardware, software, and middleware components. For requirement-based system design, the architecture trade space is well defined due to known technology enablers. But for capability-based system design, the architecture trade space is unknown to systems designers due to unknown technology enablers. The following challenges described below are the by-products of this transition; 1   signals 1 and 2 are interfering with the datalinks 1 and 2, hence the Commercial Satellite Node 4 and Civilian Satellite Node 5 are considered as Radio Frequency Interference (RFI) nodes. As shown in this SOSE CONOPS, the SOSEA design issue here is to identify an existing Commercial Satellite Node, represented by a commercial Satellite of Interest (SaOI) Node X, that can enhance the resiliency 2 of the military network consisting of MIL-Node 1, MIL-Node 2, and MIL-Node 3 [4].

SOSEA alternative solutions description
Using similar approach presented in Section 2.1, this section defines the concept of SOSEA alternative solutions using space SOSE examples. For the SOSE CONOPS presented in Figure 2, there are many possible SOSEA alternative solutions based on existing commercial satellites' availability. As an example, a quick survey was conducted to collect data for this notional construction of a SOSE commercial space database, the following commercial satellites and Ground Stations (GS) are found to be available: • SPACEWAY Satellites 2 and 3 and ARSAT satellite 2; there is a total of three commercial satellites available, namely, Commercial Satellite Nodes 6, 7, and 8, respectively.
• U.S. Universal Space Network (USN) GS in California and U.S. Orbital Tracking Corp GS in California; there is a total of two GS available, namely, commercial GS Nodes 3 and 4, respectively.
For the notional SOSE CONOPS described in Figure 2, there are six possible (3 × 2) SOSEA alternative solutions. Figure 3 describes a process for deriving a set of potential SOSEA alternative solutions for this example. Thus, a system architecture solution optimization is dependent on: • SOSE environment, that is, depending on the SOSE CONOPS.
• SOSEA alternative solutions. As explained above, for this notional CONOPS, there are six potential SOSEA alternative solutions.
2 U.S. DOD uses Resilient Capacity addressing Avoidance, Robustness, Reconstitution, and Recovery [4]. Recently, the author has introduced two additional resiliency metrics addressing RFI problems. The first metric is Resilience Assessment Index against RFI (RAI-RFI) and the second metric is Spectrum Resiliency Assessment Index (SRAI) [8,9].

Proposed SOSEA evaluation metrics
Defining SOSE Architecture evaluation metrics, such as Quality-of-Service (QoS) or Measure of Goodness (MoG), for assessing alternative system architecture solutions in a complex SOS environment is not a trivial task. The QOS of a system architecture solution can be defined in terms of the Resilient Capacity (see Footnote 3) for a complex military space systems network or a Package Error Rate (PER) for a commercial satellite systems network. Based on past experience, Table 1 presents a notional set of metrics for typical space SOS military applications. 3 This set of metrics can be used for assessing MoG of the six notional SOSE military architecture alternative solutions discussed in Section 2.2. The set of metrics presented in Table 1 emphasizes 3 The tailoring of this metrics for civilian and military applications is straight forward.  on the Critical Operational Issues (COIs) for meeting the users' (or warfighter's) needs. One of the key COIs is the "Technology Feasibility Issue" that addresses the compatibility issues of the new system with existing/legacy SOSE services and joint Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) assets, see COI #2 of Table 1. As indicated in Table 1, the notional criteria for meeting the COI # 2 are: • Compatibility matrix: Captures interfaces and industry standards that are compatible among required HW/SW, SOSE systems, and joint C4ISR assets; • Connectivity matrix: Captures connectivities among all nodes.

SOSEA perspectives and capability view
This section is organized as follows: Section 3.1 describes the current U.S. DODAF Version 2.02 artifacts; Section 3.2 presents a SOSEA perspective for commercial and civilian applications; Section 3.2 presents a SOSEA perspective for military applications; and Section 3.3 discusses SOSE capability components and SOSE integrated capability.

U.S. DODAF artifacts
DoDAF Version 2.02 is the most current version for the U.S. department of defense [3]. For all U.S. DOD programs, the architecture components are expected to conform to DoDAF artifacts to the maximum extent possible. The conformance ensures the reuse of information, architecture artifacts, models, and viewpoints can be shared with common understanding [3]. DODAF artifacts include EIGHT viewpoints [3]: i. All Viewpoint (AV): Describes the overarching aspects of architecture context that relate to all viewpoints.
ii. Capability Viewpoint (CV): Describes capability requirements, the delivery timing, and the deployed capability.
iii. Data and Information Viewpoint (DIV): Describes data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.
iv. Operational Viewpoint (OV): Describes operational scenarios, activities, and requirements that support capabilities.
v. Project Viewpoint (PV): Describes the relationships between operational and capability requirements and the various projects being implemented. PV also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process. vii. Standards Viewpoint (StdD): Describes the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems.
viii. Systems Viewpoint (SV): For Legacy support, SV describes the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.
As described in [3], there can be many DODAF artifacts associated with each view. This chapter proposes a set of key DODAF views and associated artifacts that can be used to provide a systematic way of describing a system architecture in an SOS environment. Figure 4 proposes an approach to capture system architecture artifacts using DODAF-V2.02 views in a SOS environment.
For examples, as shown in Figure 4, OV-1 and OV-4 are used to capture a system or a SOS CONOPS; OV-2, SV-1, and SV-2 for capturing system or a SOS design structure; OV-5, SV-4, SV-4a, SV-4b, SV-5a, SV-5b, and SV-5c for capturing system or SOS operations; and OV-3 and SV-6 for capturing system or a SOS Information Exchange Requirements (IER).

Civil and commercial perspective: POTmLPF
From a combined civilian and commercial perspective, the enterprise domains usually consist of seven key components, namely, Policy (P), Organization (O), Training (T), material (m), Leadership (L), Personnel (P), and Facility (F). This is also referred to as POTmLPF. A civilian/commercial enterprise solution should address the impacts across these components. The material enterprise solutions address the "m" and "F" components, and the non-material solutions address the "P," "O," "T," "L," and "P" components. Figure 5 describes a perspective for a commercial enterprise. For civilian enterprise, one replaces "Company" in Figure 5 by "Civilian Agency" (e.g., NASA or NOAA). This figure shows that a commercial (or civilian) enterprise can be organized across POTmLPF components and these components can be represented by DODAF views as illustrated in Figure 4. Furthermore, a commercial enterprise can also be organized by grouping Systems of Systems -Engineering, Modeling, Simulation and Analysis 8 POTmLPF components into "Company Capability Component #1" through "#N." For example, "Company Capability Component #1" includes POTL components.

Military perspective: DOTmLPF-P
Military enterprise domain usually consists of eight key components, namely, Doctrine (D), Organization (O), Training (T), material (m), Leadership (L), Personnel (P), Facility (F), and Policy (P). This is also referred to as DOTmLPF-P. Figure 6 presents a perspective for military enterprise. Similar to commercial enterprise, a military enterprise can also be organized across DOTmLPF-P components, or by grouping DOTmLPF-P components into "Enterprise Capability Component #1" through "#N," and these components can be represented by DODAF views as shown in Figure 4.

SOSE capability view and integrated capability component
As shown in Figure 6, for a military SOSE, the SOSE "Capability Component" is defined as a group of any of the DOTmLPF-P components belonging to that   enterprise, and that these capability components will contribute to the overall SoSE "Integrated Capabilities Component." The DODAF SOSE Capability View is defined as a view that one can use to graphically describe these SOSE capability components. The DODAF CVs are recommended for capturing these capability components and the overall SOSE integrated capabilities (labeled as "Overall Military Integrated Enterprise Capabilities," Figure 6). As an example, the military SOSE capabilities are made up by grouping various capability components across all DOTLmPF-P domains. The architecture models used in the design of a system in a SOS environment shall be developed such that they can (i) generate integrated SoSE capabilities, and (ii) be used to analyze capability gaps. During the design process, these models must be able to generate SOSE capability components that are synchronized with the customer's changing needs. This synchronization process may require consensus among customer's stakeholders to ensure meeting customer's needs through a system life cycle.
As an example, Figure 7 shows an example of the eight key "SOSE Capability Components" for a notional Airborne Operation Center (AOC). These SOSE Capability Components will be key drivers in the determination of the integrated SOS Capabilities and SOS Requirements for the notional operation center. In general, the SOS Capabilities can be classified into two categories, namely, (i) Existing SOS capabilities (As-Is), and (ii) Future SOS Capabilities (To-Be). Furthermore, the SOS requirements can be classified into material and non-material  requirements. The "Material" requirements include Facility, system hardware, software, and middleware requirements. The "Non-Material" requirements include D, P, O, P, T, and L. Figure 8 provides an example of the decomposition of the notional eight key SOS Capability Components into desired capabilities for the notional military air operation center described in Figure 7. For this example, the SOSE Capability Component titled "Target Development Capability" component is decomposed into four desired capabilities, namely, Find, Fix, Track, and Publish Target. Figure 9 provides the "Functional Decomposition" of desired "Find-Fix-Track" Capabilities to "System Requirements" for flowing-down to hardware and software components' requirements. In the example shown in Figure 9, the "Target Development Capability" component with the desired "Track" performance can be met by using existing Phase Locked Loop (PLL) and Kalman filtering technology enablers.

System architecture design and analysis in SOS environment
This section describes an approach to develop and design a system architecture solution in a SOS environment. Using the proposed approach, the architecture solution will meet customer's requirements for interfacing with existing "as-is" legacy and "to-be" systems. The approach presented here focuses on the use of only OVs and SVs presented in Figure 4 for capturing the system architecture products, including hardware, software, and middleware components. These components will be captured in a Bill of Material (BOM), which will be used for Rough Order of Magnitude (ROM) costing estimate of the system solution early during the design cycle. Figure 10 describes the proposed approach for a system architecture design and implementation in a SOS environment. As shown in Figure 10, the approach starts with the box labeled "Enterprise Needs" where requirements (or needs) are provided by customer (or users) of the system and/or SOS. Next, the box labeled "Capability Gap Analysis" is performed to determine the "functional gaps" between the required "SOS Enterprise Needs" and existing systems' capabilities. For space applications, the box labeled "Identify Technology Enablers (TEs)" is to conduct a survey of space industry to identify a set of potential TEs that can be used to fill the identified functional gaps. At this point, a set of alternative SOS Enterprise Architectures (SOSEA) is derived and assessed to determine the best solution. The box labeled "SOS Architecture Design and Assessment" uses the identified TEs and the SOSEA CONOPS (box labeled "SOSE CONOPS Development"), for the design and select the best system architecture solution from a SOS perspective, namely, a SOS Architecture solution. For traditional "SOS Architecture Design," the approach is based on the "Requirement-Based Architecture Design" approach, which requires a given set of system requirements. 4 For this approach, the architecture trade space is defined by the systems requirements based on a selected set of technology enablers and a corresponding set of specified values for the Measure Of effectiveness (MOEs) as shown in Table 1. As an example, for the MOEs, a set of Key Performance Parameters (KPPs) for SATCOM network can be Bit Error Rate (BER), Packet Error Rate (PER), and Packet Loss Rate (PLR).
For long-term customer's needs, the TEs are usually unknown, and the traditional SOS Architecture design approach is no longer applicable, the SOS engineers use "Capability-Based Architecture Design" approach. This approach evolves the "As-Is" architecture to the "End-State" (or "To-Be") architecture solution by going through "Increment" steps. For this approach, the end-state capabilities are derived based on the identified capabilities to fill the "functional gaps" for long-term customer's needs. The increment steps are defined by decomposing the "end-state" capabilities into smaller sets of capabilities that can be addressed by the current TEs at each increment.
The box labeled "System Block Diagram in DODAF-V2.02" uses the SOS Architecture solution derived from the box labeled "SOS Architecture Design and Assessment" and the box labeled "SOS Integration Analysis" to generate a system block diagram using only OVs and SVs (see Section 5.3) with (i) all internal connectivities among subsystems and their hardware, software, and middleware components are identified with actual products' names, and (ii) external SOS connectivities with other systems are identified along with existing Commercial of the Shelf (COTS) interfaces and industry standards. The box labeled "System Interconnect Diagram" captures all required subsystems and their hardware, software, and middleware components and their internal connectivities among 4 This is also referred to as "Level A" specification. Level A specification is based on a set of selected technology enablers. themselves. Finally, the box labeled "BOM (ROM Baseline)" is an excel spreadsheet that captures required subsystems and their actual COTS products for all hardware, software, and middleware components and their ROM cost estimate for the overall system.
The following subsections, Sections 4.1, 4.2, 4.3, and 4.4, provide proposed baseline approaches for "Capability Gaps Analysis," "Identify Technology Enablers," "SOS Integration Analysis," and Capabilities Management, respectively. Figure 11 presents a proposed baseline approach for capability gaps analysis. The flow of this proposed approach is straight forward. The three key features that make this approach unique are:

Capability gap analysis for capability-based SOS
• Key Feature 1: Conversion of existing system requirements into required current system/SOS capabilities.
• Key Feature 2: Development of a matrix to align existing system requirements with current system/SOS capabilities.
• Key Feature 3: Prioritization of the capability gaps (also referred to as functional gaps) based on mission objectives, performance (e.g., KPPs), technology, and cost requirements.
The next step after the capability gap analysis is the generation of the required capabilities to fill the identified functional gaps. This is also a nontrivial task, as pointed out in Section 3.4, the framework for constructing the capability generation models must be able to generate the required SOS capabilities (to fill the gaps) that are synchronized with the customer's changing needs. For a military enterprise, Figure 12 proposes an enterprise capability planning framework for generating required capabilities that can be synchronized with changing customer's needs. The salient features associated with this proposed framework are: • Each of the proposed capabilities generated from this framework is evaluated using Advanced Modeling and Simulation (AM&S) tools to ensure alignment with the identified functional gap and desired operational effects. Example of AM&S tools include SOS AM&S models that can be used to characterize SOS TPMs (e.g., SOS Resilient Capacity, SOS Spectrum Resiliency, etc., see Section 5.1 for more details) for a specified space mission.
• Capability-to-Requirement Conversion and Requirement-to-Capability Alignment processes to ensure system requirements and required customer's/ users' capabilities are always synchronized.
• Generation of required capabilities is focused on generating Effects-Based Operation (EBO) capabilities.
• For military applications, generating of required capabilities is based on: ○ Improve operation effectiveness (see Table 1 for measure of operation effectiveness)

○ Life Management Plans (LMEP)
The proposed approach focuses on generating the required capabilities using operational EBO approach. Table 2 illustrates (a) EBO physical action, and (b) EBO kind of effects. For EBO approach, it is critical to define performance measure and develop corresponding advanced modeling and simulation tools to evaluate and assess EBO effects. Note that one can modify the framework presented in Figure 12 for civilian and commercial enterprises. Figure 13 describes a baseline approach for identifying required Technology Enablers (TEs) for a selected SOSEA solution. The approach assumes a notional  user's needs for space (or airborne) systems. The key step here is the identification of the "Design Features" to meet the Needs. The needs here can be mission needs, or warfighter needs or customers' needs. In this proposed approach, these needs have been translated to "Business Needs." As an example, the business needs for this notional users' needs are ( [5], also see Section 5.  Figure 14 shows an integration analysis framework for (i) identifying potential SOS integrations problems, and (ii) recommending corresponding solutions for  the identified integration problems. As described in Figure 14, the proposed SOS integration analysis allows for incremental architecture solutions discussed earlier and provides the following six outputs:

Integration analysis for capability-based SOS
• Output 1: Identify integration problems and recommend solutions • Output 2: Integration score against scenarios (or use cases). This score allows the designers understand the effectiveness of the proposed system architecture solution(s) against the threats or "loading" on the systems and network of systems (SOS) • Output 3: Identify gaps and problems: The gaps here are the internal and external interface gaps in the presence of various threats or loading scenarios • Output 4: Propose required capability for seamless integration and improve interoperability • Output 5: Propose evolution alternative(s) in terms of interoperability and affordability.
• Output 6: Recommend optimum SOS Architecture solution in terms of interoperability and affordability The proposed SOS integration analysis is flexible, agile, and robust and is applicable for any SOS Enterprise because of the following features: • Compatibility matrix: This matrix is used to track internal and external interfaces ensuring interfaces (i) among internal subsystems and their components are compatible, and (ii) among systems and SOS are compatible. Compatibility matrix is also used to identify the incompatibility among interfaces of any SOS Enterprise.

Figure 14.
An integration analysis framework for capability-based SOS.
• Loading scenarios are used in the development of the SOSE CONOPS, where the desired system and SOS loading factors are clearly defined. Loading factors can be the number of users, or data rates, or the number of missile fires, etc.
• Generating alternative SOS Architecture solutions using compatibility matrix. This concept provides a flexible and agile approach for generating practical and implementable SOS Architecture alternatives.

Capability management framework
A flexible and robust framework to manage systems and SOS capabilities and system requirements for a notional military enterprise is illustrated in Figure 15. The proposed framework allows for managing both current/legacy systems requirements and mid-term/long-term systems' capabilities at the enterprise level. The framework ensures capturing system requirements and system capabilities using the existing standard documentation approach and allocating increment requirements for evolving "as-is" to "to-be" systems effectively. Currently, for U.S. military enterprise using capability-based architecture approach, the system capabilities are documented in the Initial Capability Document (ICD), the Capability Development Document (CDD), and the Capability Production Document (CPD) depending on the acquisition phase of the system life cycle [6,7]. For requirement-based architecture approach, the system requirements are usually documented in Technical Requirement Document (TRD) and/or System Requirements Document (SRD), which are/is derived from System Specification Document (SSD) and/or ICD [7].

Examples on notional SOSE Architecture solutions
This section provides three examples related to the design, modeling, simulation, and analysis of a system in SOSE environment. Section 5.1 describes a notional commercial system solution that can be used to augment existing military system for increased resiliency against radio frequency interference threats. Using the  architecture design approach presented in this chapter, Sections 5.2 and 5.3 present notional architecture solutions for a typical Satellite Operation Center (SOC) and a notional airborne Intelligence, Surveillance, and Reconnaissance (ISR) platform, respectively.

A notional SOS solution for increased SOS resiliency
As indicated in Footnote 3, the author has defined and developed two new resiliency metrics addressing Radio Frequency Interference (RFI) problems. The first metric is Resilience Assessment Index Against RFI (RAI-RFI) and the second metric is Spectrum Resiliency Assessment Index (SRAI). Mathematical models for these two metrics can be found in [8,9]. This section inverts the question addressed in the notional SATCOM SOSE CONOPS described in Figure 2. Instead of addressing the question related to the optimum commercial satellite location in space, it addresses the question related to an optimum location for a ground system solution given that the SaOI Node X in space will be defined as one of the three civilian satellites given in the notional SOSE CONOPS presented in Figure 16. The SOSEA design issue here focuses on the identification of an existing Military or Civilian Ground Tracking Station (GTS) that can enhance the resiliency of the satellite operations supporting a notional military satellite network described in SOSE CONOPS presented in Figure 16 [9]. This notional SOSE CONOPS includes 6 military GEO satellites and 8 military GTSs, three civilian satellites, and 15 civilian GTS. Using the RAI-RFI mathematical model presented in [6,7], Figure 16 shows a time average heat map of the RAI-RFI metric [6,7]. The heat map shows the potential optimum GTS locations for improved resiliency [9]. Figure 17 illustrates an operational view using DODAF OV-5 for a typical SOC operational architecture [5]. The design question here is to upgrade existing SOC using Commercial of the Shelf (COTS) and Government of the Shelf (GOTS) Hardware (HW), Software (SW), and Middleware (MW) TEs. Using the above Figure 16. Example of time average heat map of RAI-RFI metric for a notional military enterprise CONOPS [9]. architecture design approach, one can develop Table 3 to capture the identified business needs, desired SOC design features (to meet the needs), required TEs, and stake holder and user's benefits [5].

A notional satellite operation center architecture solution
From the required TEs presented in the sixth column of Table 3, a notional list of potential TEs that meets the design criteria is presented in Table 4 [5]. To identify an optimum SOC Architecture solution for the upgrade, the SOS designer needs to conduct a survey to understand the risks associated technology readiness level and market availability of each identified TE and perform an architecture trade study. Using the notional survey results, in Ref. [5], it is shown that the optimum architecture solution for the SOC upgrade is a combination of TE-1, TE-2, TE-4, TE-5, and TE-6.

A notional airborne ISR platform architecture solution
This section presents how a DODAF views presented in Figure 4 can be used to capture a typical Airborne ISR Platform (AIP) architecture solution operating in a notional SOS environment. The notional SOS environment considered here includes: (i) Military user nodes that can be on ground or surface or air, and   (ii) Commercial ground nodes that can be a ground broadcast news or a commercial mobile user. Figure 18 describes a DODAF OV-5 for typical AIP SOS operational activity. Figure 19 illustrates a DODAF OV-2 for typical AIP SOS operational node connectivity. Figure 20 illustrates a DODAF SV-1 for typical AIP SOS interface in the notional SOS environment.

Conclusion
This chapter describes SOSE, SOSE CONOPS, SOSEA alternative solutions, SOSEA CONOPS assessment, and SOSEA design approach through examples using typical and/or notional space and airborne systems in a typical SOS operational environment. The SOSE environment considered is a combination of military, civilian, and commercial operational environments. As pointed out throughout the chapter, examples for military applications can be tailored for civilian and commercial applications and vice versa. Similarly, examples for airborne systems can also be tailored for space systems considering transmission delay for satellite systems is much longer than airborne systems. The SOSEA approach proposed in this chapter has been used by the author for the design, modeling, simulation, and analysis of space and airborne systems for actual military and commercial programs.