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

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.

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

• A set of connections among satellites within each FOS, namely, FOS-BS, FOS-WIS, and FOS-DVACS

• A set of connections among FOS-BS, FOS-WIS, and FOS-DVACS.

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:

• Backward compatibility: Compatible with existing SOS environment (also referred to as “As-Is”);

• Forward compatibility: Compatible with future planned SOS environment (or “To-Be”);

• 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¹ 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;

  • Technology enablers identification to ensure synchronization with the required system design features in SOS environment.

  • 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 SOS’s requirements with planned capabilities.

• 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 allowing for accurate costing of the system.

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

Figure 2.

Notional SOSE CONOPS for SATCOM applications.

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:

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

Figure 3.

A process for generating SOSE Architecture alternatives.

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

Table 1.

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

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

1. All Viewpoint (AV): Describes the overarching aspects of architecture context that relate to all viewpoints.

2. Capability Viewpoint (CV): Describes capability requirements, the delivery timing, and the deployed capability.

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

4. Operational Viewpoint (OV): Describes operational scenarios, activities, and requirements that support capabilities.

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

6. Services Viewpoint (SeV): Describes the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.

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

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

Figure 4.

Proposed DODAF-V2.02 views capturing SOS Architecture.

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 POTmLPF components into “Company Capability Component #1” through “#N.” For example, “Company Capability Component #1” includes POTL components.

Figure 5.

A commercial SOSE perspective.

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.

Figure 6.

Military SOSE perspective.

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

A capability view for notional military AOC.

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.

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.

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

Figure 10.

SOS Architecture design and implementation approach.

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

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

Figure 11.

A capability gap analysis framework for capability-based SOS.

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:

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

  • Total Ownership Cost reduction

  • Improve operation effectiveness (see Table 1 for measure of operation effectiveness)

  • Life Management Plans (LMEP)

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.

Table 2.

Description of EBO and associated effects.

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

• Reduce ground system cost

• Improve interoperability

Figure 13.

Technical framework for identifying technology enablers for notional users’ needs.

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

• Government of the Shelf (GOTS) multi-mission Satellite Operation Center (SOC) software suite for Telemetry Tracking & Commanding (TT&C) services: Real-time execution component, Mission planning component, Flight dynamic component, etc.

• COTS Satellite Operations (SATOPS) TT&C services

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

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

• 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

Figure 14.

An integration analysis framework for capability-based SOS.

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.

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

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

Figure 15.

Capability management framework for a notional.

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

Figure 16.

Example of time average heat map of RAI-RFI metric for a notional military enterprise CONOPS [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 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].

Figure 17.

OV-5: typical SOC operational architecture.

Table 3.

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

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.

Table 4.

A notional list of technology enablers and associated suppliers.

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

OV-5: Typical AIP SOS operational activity.

Figure 19.

OV-2: Typical AIP SOS operational node connectivity.

Figure 20.

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

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

Acknowledgments

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.