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

*Tien M. Nguyen*

## **Abstract**

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.

**Keywords:** SOS Enterprise (SOSE), SOSE CONOPS, SOSE Architecture (SOSEA) design, SOSE integration, compatibility matrix, SOSEA evaluation metrics, SOSE capability component, capability gap analysis framework, capability management framework, requirements-based, capability-based, integration analysis framework

## **1. 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–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) FOS of Broadcasting Satellites (FOS-BS), (ii) FOS of Wideband Internet Satellites (FOS-WIS), and (iii) FOS of Data, Video, Audio Communications Satellites (FOS-DVACS). For commercial space enterprise, the SOS environment can be defined as:


#### **Figure 1.** *Space SOS Enterprise definition.*

Similarly, the definition for military space enterprise includes: (i) FOS of communications satellites, (ii) FOS of sensing/imaging satellites, and (iii) FOS of Position-Navigation-and-Timing (PNT) satellites. For civilian space enterprise, it includes: (i) FOS for near-Earth missions, (ii) FOS for deep space missions, and (iii) FOS for earth surveillance missions. The same definitions can be derived for the airborne enterprises.

As the space and airborne operational environment is moving from "system" to "SOS" environment, the system (or SOS) engineers face many challenges when designing a new system that can operate within a SOS environment. Some of the key challenges are:


**55**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

○ Technology enablers identification to ensure synchronization with the

○ Capability gap analysis: Analyzing capability gaps and generating solution to fill the gap should be synchronized with changing customer's needs.

○ SOS integration analysis to ensure early identification of potential integration issues between the new system with existing SOS environment.

○ SOS capabilities management ensuring synchronization between existing

• A robust, agile, and flexible SOSE Architecture design approach leading to a system architecture solution that (i) meets customer's requirements for seamless interfacing with both existing/legacy and future systems, and (ii) can identify desired architecture products early during the concept design cycle

This chapter will describe a SOSEA design approach that can address the above

Section 2.1 describes SOSE CONOPS, Section 2.2 discusses SOSEA alternative solutions, and Section 2.3 proposes a potential set of SOSEA assessment metrics for

This subsection provides a description of SOSE CONOPS through an example using the space SOSE definition presented in Section 1. **Figure 2** presents a notional SOSE CONOPS for Satellite Communication (SATCOM) applications. The figure illustrates the connections among military, civilian, and commercial SOS Enterprises. This SOSE CONOPS shows: (i) Military satellite Node 1 (MIL-Node 1), MIL-Node 2, and MIL-Node 3 communicating with Military Gateway 1 (MIL GW 1), MIL GW 2, MIL GW 3, User Mobile Terminal 1, and User Mobile Terminal 2; (ii) MIL-Node 2 communicating with MIL GW 1 and MIL GW 2 through the datalinks 1 and 2, respectively; (iii) Commercial Satellite Node 4 talking to Commercial Satellite Gateway 1 through RF signal 2; and (iii) Civilian Satellite Node 5 talking to Civilian Satellite Gateway 2 through RF signal 1. For this notional SOSE CONOPS, the RF

challenges. The chapter is organized as follows: (i) Section 2 describes SOSE CONOPS, SOSEA alternative solutions, and associated SOSEA evaluation metrics; (ii) Section 3 discusses U.S.DODAF, SOSEA perspectives across enterprise domains, SOSE capability components, and SOSE integrated capability. This section also presents a perspective on enterprise domains, including Doctrine (D), Organization (O), Training (T), material (m), Leadership (L), Personnel (P), Facility (F), and Policy (P), abbreviated as DOTmLPF-P; (iii) Section 4 proposes an approach for the design of a system in a SOSE environment that can address all the challenges discussed above; (iv) Section 5 provides examples on notional SOSEA alternative solutions using the proposed approach described in Section 4 for typical spacebased communications system and manned airborne Intelligence Surveillance Reconnaissance (ISR) platform; and (v) Section 6 concludes the chapter with remarks on future design and analysis of SOSE space and airborne systems.

required system design features in SOS environment.

SOS's requirements with planned capabilities.

allowing for accurate costing of the system.

**2. SOSE CONOPS and SOSEA alternative solutions**

evaluating alternative architecture solutions.

**2.1 SOSE CONOPS description**

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

<sup>1</sup> Technology Enabler (TE) is defined as the technology that concretely fulfills the required user's capabilities (or warfighter's capabilities for military systems). Examples of TE for space applications are: Software Defined Radio (SDR) modem, Beamforming network, Digital Channelizer and Beamformer (DCB), Adaptive Linearizer, etc.


This chapter will describe a SOSEA design approach that can address the above challenges. The chapter is organized as follows: (i) Section 2 describes SOSE CONOPS, SOSEA alternative solutions, and associated SOSEA evaluation metrics; (ii) Section 3 discusses U.S.DODAF, SOSEA perspectives across enterprise domains, SOSE capability components, and SOSE integrated capability. This section also presents a perspective on enterprise domains, including Doctrine (D), Organization (O), Training (T), material (m), Leadership (L), Personnel (P), Facility (F), and Policy (P), abbreviated as DOTmLPF-P; (iii) Section 4 proposes an approach for the design of a system in a SOSE environment that can address all the challenges discussed above; (iv) Section 5 provides examples on notional SOSEA alternative solutions using the proposed approach described in Section 4 for typical spacebased communications system and manned airborne Intelligence Surveillance Reconnaissance (ISR) platform; and (v) Section 6 concludes the chapter with remarks on future design and analysis of SOSE space and airborne systems.

## **2. SOSE CONOPS and SOSEA alternative solutions**

Section 2.1 describes SOSE CONOPS, Section 2.2 discusses SOSEA alternative solutions, and Section 2.3 proposes a potential set of SOSEA assessment metrics for evaluating alternative architecture solutions.

#### **2.1 SOSE CONOPS description**

This subsection provides a description of SOSE CONOPS through an example using the space SOSE definition presented in Section 1. **Figure 2** presents a notional SOSE CONOPS for Satellite Communication (SATCOM) applications. The figure illustrates the connections among military, civilian, and commercial SOS Enterprises. This SOSE CONOPS shows: (i) Military satellite Node 1 (MIL-Node 1), MIL-Node 2, and MIL-Node 3 communicating with Military Gateway 1 (MIL GW 1), MIL GW 2, MIL GW 3, User Mobile Terminal 1, and User Mobile Terminal 2; (ii) MIL-Node 2 communicating with MIL GW 1 and MIL GW 2 through the datalinks 1 and 2, respectively; (iii) Commercial Satellite Node 4 talking to Commercial Satellite Gateway 1 through RF signal 2; and (iii) Civilian Satellite Node 5 talking to Civilian Satellite Gateway 2 through RF signal 1. For this notional SOSE CONOPS, the RF

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

Similarly, the definition for military space enterprise includes: (i) FOS of communications satellites, (ii) FOS of sensing/imaging satellites, and (iii) FOS of Position-Navigation-and-Timing (PNT) satellites. For civilian space enterprise, it includes: (i) FOS for near-Earth missions, (ii) FOS for deep space missions, and (iii) FOS for earth surveillance missions. The same definitions can be derived for

As the space and airborne operational environment is moving from "system" to "SOS" environment, the system (or SOS) engineers face many challenges when designing a new system that can operate within a SOS environment. Some of the

• Backward compatibility: Compatible with existing SOS environment (also

• Forward compatibility: Compatible with future planned SOS environment (or

• 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

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 chal-

lenges described below are the by-products of this transition;

<sup>1</sup> Technology Enabler (TE) is defined as the technology that concretely fulfills the required user's capabilities (or warfighter's capabilities for military systems). Examples of TE for space applications are: Software Defined Radio (SDR) modem, Beamforming network, Digital Channelizer and Beamformer

is chosen at the time of the design, and the system

**54**

the airborne enterprises.

*Space SOS Enterprise definition.*

referred to as "As-Is");

of technology enablers1

(DCB), Adaptive Linearizer, etc.

key challenges are:

**Figure 1.**

"To-Be");

**Figure 2.** *Notional SOSE CONOPS for SATCOM applications.*

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 resiliency2 of the military network consisting of MIL-Node 1, MIL-Node 2, and MIL-Node 3 [4].

## **2.2 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:


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:


**57**

**Table 1.**

**Figure 3.**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

*A process for generating SOSE Architecture alternatives.*

**2.3 Proposed SOSEA evaluation metrics**

set of metrics for typical space SOS military applications.3

<sup>3</sup> The tailoring of this metrics for civilian and military applications is straight forward.

*Notional SOSEA technical performance metrics (TPMs) for military space applications.*

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

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

This set of metrics can be

<sup>2</sup> 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].

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*

#### **Figure 3.**

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

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 resiliency2

military network consisting of MIL-Node 1, MIL-Node 2, and MIL-Node 3 [4].

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

• 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,

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

• SOSEA alternative solutions. As explained above, for this notional CONOPS,

<sup>2</sup> 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

• 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,

• SOSE environment, that is, depending on the SOSE CONOPS.

there are six potential SOSEA alternative solutions.

**2.2 SOSEA alternative solutions description**

*Notional SOSE CONOPS for SATCOM applications.*

commercial GS Nodes 3 and 4, respectively.

to be available:

**Figure 2.**

respectively.

optimization is dependent on:

Resiliency Assessment Index (SRAI) [8, 9].

of the

**56**

*A process for generating SOSE Architecture alternatives.*


#### **Table 1.**

*Notional SOSEA technical performance metrics (TPMs) for military space applications.*

#### **2.3 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

<sup>3</sup> 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:


## **3. 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.

## **3.1 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]:


**59**

**Figure 4.**

*Proposed DODAF-V2.02 views capturing SOS Architecture.*

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

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

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

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

For examples, as shown in **Figure 4**, OV-1 and OV-4 are used to capture a system

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

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

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

functions.

Exchange Requirements (IER).

engineering processes, and systems.

artifacts using DODAF-V2.02 views in a SOS environment.

**3.2 Civil and commercial perspective: POTmLPF**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*


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

#### **3.2 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

**Figure 4.**

*Proposed DODAF-V2.02 views capturing SOS Architecture.*

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

notional criteria for meeting the COI # 2 are:

**3. SOSEA perspectives and capability view**

context that relate to all viewpoints.

timing, and the deployed capability.

requirements that support capabilities.

Defense Acquisition System process.

supporting operational and capability functions.

SOSE integrated capability.

**3.1 U.S. DODAF artifacts**

viewpoints [3]:

services.

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

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

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

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

i.All Viewpoint (AV): Describes the overarching aspects of architecture

iii.Data and Information Viewpoint (DIV): Describes data relationships

ii.Capability Viewpoint (CV): Describes capability requirements, the delivery

and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and

iv.Operational Viewpoint (OV): Describes operational scenarios, activities, and

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

vi.Services Viewpoint (SeV): Describes the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or

**58**

POTmLPF components into "Company Capability Component #1" through "#N." For example, "Company Capability Component #1" includes POTL components.

## **3.3 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**.

## **3.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

**Figure 5.**

*A commercial SOSE perspective.*

**61**

**Figure 8.**

*notional military AOC.*

**Figure 7.**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

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

*Example of the functional decomposition of key SOSE capability components to desired capabilities for a* 

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

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

needs through a system life cycle.

*A capability view for notional military AOC.*

**Figure 6.** *Military SOSE perspective.*

#### *SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*

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

#### **Figure 7.**

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

**3.4 SOSE capability view and integrated capability component**

**3.3 Military perspective: DOTmLPF-P**

shown in **Figure 4**.

POTmLPF components into "Company Capability Component #1" through "#N." For example, "Company Capability Component #1" includes POTL components.

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

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

**60**

**Figure 6.**

*Military SOSE perspective.*

**Figure 5.**

*A commercial SOSE perspective.*

*A capability view for notional military AOC.*

#### **Figure 8.**

*Example of the functional decomposition of key SOSE capability components to desired capabilities for a notional military AOC.*

#### **Figure 9.**

*Example of the functional decomposition of desired capabilities to subsystem requirements for a notional military AOC.*

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.

### **4. 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

**63**

at each increment.

**Figure 10.**

technology enablers.

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

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

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),

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

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 <sup>4</sup> This is also referred to as "Level A" specification. Level A specification is based on a set of selected

For this approach, the architecture trade

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

a given set of system requirements.4

*SOS Architecture design and implementation approach.*

Packet Error Rate (PER), and Packet Loss Rate (PLR).

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*

#### **Figure 10.**

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

requirements. The "Material" requirements include Facility, system hardware, software, and middleware requirements. The "Non-Material" requirements include

*Example of the functional decomposition of desired capabilities to subsystem requirements for a notional* 

**4. 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

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

**62**

D, P, O, P, T, and L.

**Figure 9.**

*military AOC.*

*SOS Architecture design and implementation approach.*

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

<sup>4</sup> 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.

## **4.1 Capability gap analysis for capability-based SOS**

**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:


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:

	- DOTLmPF-P trade analysis for best solution: material vs. non-material solutions

**65**

effectiveness)

**Figure 12.**

**Figure 11.**

*planning purpose.*

○ Life Management Plans (LMEP)

for civilian and commercial enterprises.

**4.2 Technical framework for identifying technology enablers**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

○ Improve operation effectiveness (see **Table 1** for measure of operation

*Proposed framework for generating military SOSE capabilities and associated technical solutions for enterprise* 

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**

**Figure 13** describes a baseline approach for identifying required Technology Enablers (TEs) for a selected SOSEA solution. The approach assumes a notional

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

*A capability gap analysis framework for capability-based SOS.*

○ Total Ownership Cost reduction

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*

#### **Figure 11.**

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

"SOS Integration Analysis," and Capabilities Management, respectively.

**4.1 Capability gap analysis for capability-based SOS**

all system.

this approach unique are:

rent system/SOS capabilities.

ogy, and cost requirements.

with current system/SOS capabilities.

salient features associated with this proposed framework are:

5.1 for more details) for a specified space mission.

users' capabilities are always synchronized.

Operation (EBO) capabilities.

○ Total Ownership Cost reduction

solutions

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 over-

The following subsections, Sections 4.1, 4.2, 4.3, and 4.4, provide proposed baseline approaches for "Capability Gaps Analysis," "Identify Technology Enablers,"

**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

• Key Feature 1: Conversion of existing system requirements into required cur-

• Key Feature 2: Development of a matrix to align existing system requirements

• Key Feature 3: Prioritization of the capability gaps (also referred to as functional gaps) based on mission objectives, performance (e.g., KPPs), technol-

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

• 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

• Capability-to-Requirement Conversion and Requirement-to-Capability

• Generation of required capabilities is focused on generating Effects-Based

• For military applications, generating of required capabilities is based on:

○ DOTLmPF-P trade analysis for best solution: material vs. non-material

Alignment processes to ensure system requirements and required customer's/

**64**

*A capability gap analysis framework for capability-based SOS.*

#### **Figure 12.**

*Proposed framework for generating military SOSE capabilities and associated technical solutions for enterprise planning purpose.*


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.

#### **4.2 Technical framework for identifying technology enablers**

**Figure 13** describes a baseline approach for identifying required Technology Enablers (TEs) for a selected SOSEA solution. The approach assumes a notional

#### *Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*


#### **Table 2.**

*Description of EBO and associated effects.*

#### **Figure 13.**

*Technical framework for identifying technology enablers for notional users' needs.*

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.2):


Examples for the selected TEs that meet these business needs are [5]:


## **4.3 Integration analysis for capability-based SOS**

**Figure 14** shows an integration analysis framework for (i) identifying potential SOS integrations problems, and (ii) recommending corresponding solutions for

**67**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

the identified integration problems. As described in **Figure 14**, the proposed SOS integration analysis allows for incremental architecture solutions discussed earlier

• 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

• 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

• Output 5: Propose evolution alternative(s) in terms of interoperability and

• Output 6: Recommend optimum SOS Architecture solution in terms of

The proposed SOS integration analysis is flexible, agile, and robust and is

• 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

applicable for any SOS Enterprise because of the following features:

• Output 1: Identify integration problems and recommend solutions

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

and provides the following six outputs:

*An integration analysis framework for capability-based SOS.*

systems (SOS)

**Figure 14.**

interoperability

affordability.

Enterprise.

interoperability and affordability

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*

#### **Figure 14.**

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

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

Examples for the selected TEs that meet these business needs are [5]:

• COTS Satellite Operations (SATOPS) TT&C services

**4.3 Integration analysis for capability-based SOS**

• Government of the Shelf (GOTS) multi-mission Satellite Operation Center (SOC) software suite for Telemetry Tracking & Commanding (TT&C)

• COTS Open Source Middleware: Active MQ, VMware with Vsphere, etc.

**Figure 14** shows an integration analysis framework for (i) identifying potential SOS integrations problems, and (ii) recommending corresponding solutions for

services: Real-time execution component, Mission planning component, Flight

notional users' needs are ([5], also see Section 5.2):

*Technical framework for identifying technology enablers for notional users' needs.*

• Reduce ground system cost

dynamic component, etc.

• Improve interoperability

**Figure 13.**

**Table 2.**

*Description of EBO and associated effects.*

**66**

*An integration analysis framework for capability-based SOS.*

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:


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 15.**

*Capability management framework for a notional.*


#### **4.4 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].

## **5. 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

**69**

**Figure 16.**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

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,

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 loca-

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

tions for improved resiliency [9].

**5.1 A notional SOS solution for increased SOS resiliency**

**5.2 A notional satellite operation center architecture solution**

**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

*Example of time average heat map of RAI-RFI metric for a notional military enterprise CONOPS [9].*

respectively.

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.

## **5.1 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].

## **5.2 A notional satellite operation center architecture solution**

**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].*

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

• 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

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

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

and implementable SOS Architecture alternatives.

**5. Examples on notional SOSE Architecture solutions**

**4.4 Capability management framework**

*Capability management framework for a notional.*

**Figure 15.**

Document (SSD) and/or ICD [7].

**68**

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

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.

#### **Figure 17.**

*OV-5: typical SOC operational architecture.*


**71**

**Figure 18.**

*OV-5: Typical AIP SOS operational activity.*

**Table 4.**

**5.3 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

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

*A notional list of technology enablers and associated suppliers.*

#### **Table 3.**

*Synchronizing user needs with business needs, design features, and technology enablers.*

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*


#### **Table 4.**

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

stake holder and user's benefits [5].

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

for the SOC upgrade is a combination of TE-1, TE-2, TE-4, TE-5, and TE-6.

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

**70**

**Table 3.**

**Figure 17.**

*OV-5: typical SOC operational architecture.*

*Synchronizing user needs with business needs, design features, and technology enablers.*

*A notional list of technology enablers and associated suppliers.*

**Figure 18.** *OV-5: Typical AIP SOS operational activity.*

#### **5.3 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.

**Figure 19.** *OV-2: Typical AIP SOS operational node connectivity.*

**73**

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space…*

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.

The author would like to express his appreciation to Prof. Charles Lee and Prof. Alfonso Agnew, Chair, Department of Mathematics at California State University,

The preparation of this chapter was not funded by the Aerospace Corporation, and it was done by the author using his own time and resources; thus it does not represent the Aerospace Corporation's view on SOS, SOSE and SOSE Architecture.

The author wishes to thank his wife, Thu-Hang Nguyen, for her enormous

© 2020 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/ by/3.0), which permits unrestricted use, distribution, and reproduction in any medium,

patience and boundless support during the preparation of this chapter.

1 California State University in Fullerton, California, USA

\*Address all correspondence to: tnguyen57@aol.com

2 The Aerospace Corporation, United States

provided the original work is properly cited.

*DOI: http://dx.doi.org/10.5772/intechopen.92674*

**6. Conclusion**

**Acknowledgements**

**Conflict of interest**

**Author details**

Tien M. Nguyen1,2

**Notes/thanks/other declarations**

Fullerton.

**Figure 20.** *SV-1: Typical AIP SOS interface in a notional SOS environment.*

*SOS Enterprise, SOSE CONOPS, SOSE Architecture Design Approach: A Perspective on Space… DOI: http://dx.doi.org/10.5772/intechopen.92674*

## **6. Conclusion**

*Systems-of-Systems Perspectives and Applications - Design, Modeling, Simulation…*

the notional SOS environment.

(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

**72**

**Figure 20.**

**Figure 19.**

*OV-2: Typical AIP SOS operational node connectivity.*

*SV-1: Typical AIP SOS interface in a notional SOS environment.*

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.

## **Acknowledgements**

The author would like to express his appreciation to Prof. Charles Lee and Prof. Alfonso Agnew, Chair, Department of Mathematics at California State University, Fullerton.

## **Conflict of interest**

The preparation of this chapter was not funded by the Aerospace Corporation, and it was done by the author using his own time and resources; thus it does not represent the Aerospace Corporation's view on SOS, SOSE and SOSE Architecture.

### **Notes/thanks/other declarations**

The author wishes to thank his wife, Thu-Hang Nguyen, for her enormous patience and boundless support during the preparation of this chapter.

## **Author details**

Tien M. Nguyen1,2

1 California State University in Fullerton, California, USA

2 The Aerospace Corporation, United States

\*Address all correspondence to: tnguyen57@aol.com

© 2020 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/ by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

## **References Chapter 5**

[1] Dahmann J, Lane JA, Rebovich G Jr, Baldwin KJ. A Model of Systems Engineering in a System of Systems Context. MITRE Corporation; 2008. Available from: https://www.researchgate.net/ publication/228576609\_A\_model\_of\_ systems\_engineering\_in\_a\_system\_of\_ systems\_context

[2] Henshaw M, Dahmann J, Lawson B. Systems of systems. In: System Engineering Book of Knowledge (SEBoK); 2019. Available from: https://www.sebokwiki.org/wiki/ Systems\_of\_Systems\_(SoS)

[3] Department of Defense Architecture Framework. DODAF Version 2.02; 2011. Available from: https://dodcio.defense. gov/Portals/0/Documents/DODAF/ DoDAF\_v2-02\_web.pdf

[4] Burch R. A method for calculation of the resilience of a space system. In: IEEE Military Communications Conference Proceedings; 2013

[5] Nguyen TM, Andy Guillen. Acquisition war-gaming applications for acquiring future ground satellite control systems. Poster Presentation. 2017 Ground System Architecture Workshop (GSAW). The Aerospace Corporation; 2017

[6] DOD Instruction 5000.02; 2013. Available from: https://www.dau.edu/ guidebooks/Shared%20Documents%20 HTML/DoDI%205000.02.aspx

[7] Nguyen TM, Guillen AT, Matsunaga SS.A resilient program technical baseline framework for future space systems. Vol. 9469. Invited Paper. Pham KD, Chen G, editors. In: 2015 SPIE Conference Proceedings, Sensors and Systems for Space Applications VIII; 2015

[8] Nguyen TM, Lee CH, Freeze T, Guillen AT. Systems-of-Systems enterprise architecture CONOPS assessment approach and preliminary results. In: Chen G, Pham KD, editors. Invited Paper. Vol. 9469. To be published in: 2020 SPIE Conference Proceedings, Sensors and Systems for Space Applications VIII; 2020

System-of-Systems Enterprise

CONOPS Assessment Decision

*Thomas O. Freeze,Tien M. Nguyen and Charles H. Lee*

This chapter discusses the implementation of System-of-Systems Enterprise Architecture (SOSEA) CONOPS assessment framework and models in Matlab, and presents preliminary results concerning SOSEA resiliency in the presence of a notional Radio Frequency Interference (RFI) scenario. The chapter provides an overview of the SOSEA CONOPS Assessment Framework, and discusses related SOS Resiliency Models including Resilient Assessment Index Against RFI (RAI-RFI), Spectrum Resiliency Assessment Index (SRAI), and Resilient Capacity (RC).

**Keywords:** SOS enterprise architecture, CONOPS, resilient capacity, resilience assessment index against radio frequency interference, spectrum resiliency

In 2011, The Department of Defense (DOD) established a formalized concept of resilience for space systems and Systems-of-Systems (SOS) [1]. They define resilience as the ability of an architecture to support the functions necessary for mission success in spite of hostile action or adverse conditions. Similarly, in Enhancing Space Resilience Through Non-Material Means McLeod, et al. define resilience as "an attribute of a system that generally indicates its ability to maintain critical operations in the face of adverse disruptions" [2]. However, they acknowledge that there is much room for variation to this definition depending on circumstances and priorities. Gregory Edlund splits resilience evaluations into two broad categories of either being analytic or deterministic [3]. For Edlund, analytic models are geared more towards attempting to measure or score a system's resilience. Deterministic models are focused more on characterizing a system's breaking points, which Edlund argues may be more useful in practice. This chapter addresses the modeling

The U.S. Military uses communications satellite systems to facilitate beyond line-of sight communications. For decades, the satellite space has been largely uncontested. However, the orbital space around the Earth has become more congested as technology advances. Such advances make the space environment more accessible to various organizations. Third party un-intentional interferences with the military satellite communication system are a growing and serious threat as more and more government, commercial, and civilian entities enter the orbital space environment. This chapter discusses three models to analyze different

assessment index, satellite communication, satellite operation

**1. Background and introduction**

of SOS Enterprise Resiliency and its metrics.

Support Tools

**Abstract**

**75**

[9] Freeze T, Nguyen TM, Lee C. SOS Enterprise CONOPS assessment decision support tools. In: Nguyen TM, editor. SOS Design—Engineering, Modeling, Simulation and Analysis; Intech Open Publisher; 2020 [Unpublished]

## **References Chapter 5**
