Future Satellite System Architectures and Practical Design Issues: An Overview

Abstract

This chapter discusses existing and future trends on the design and build of “Modular” and “Open” satellite Bus and mission payload along with practical design issues associated with the use of Modular Open System Approach (MOSA). Existing modular Bus and mission payload architectures for typical commercial, civilian, and military satellite systems will be discussed. The chapter provides space industry views on “Open” versus “Close” interfaces design and addresses the challenges associated with open interfaces using Open System Architecture (OSA) approach using MOSA principles. The system interfaces discuss in this chapter include (i) internal to satellite Bus and mission Payload (PL), (2) between satellite Bus and mission payload, and (3) external to both satellite Bus and mission payload.

1. Background and introduction

Typical commercial and civilian satellite systems take about 2–3years to build and launch [1, 2, 3, 4], while military systems take between 7 and 10 years [5, 6]. A typical production flow for assembling and launching of a space vehicle is presented in Ref. [6] and redrawn in Figure 1 as introduction steps for better understanding of the design, build and launch of a satellite system. This chapter focuses on practical design issues for satellite Bus’ and mission PL’s system/subsystem components builds, and corresponding interface-design’s challenges associated with satellite Bus integration, mission PL integration, and satellite system integration. A survey of existing commercial, civilian and military satellite systems revealed that a typical satellite Bus includes the following modular components [7, 8, 9, 10, 11, 12, 13, 14, 15, 16]:

• Bus Subsystem 1—Bus TX/RX Antenna Subsystem (BAS): Provide Bus’s Receive (RX)/Transmit (TX) antennas and associated Bus’s antenna beam control functions;

• Bus Subsystem 2—Bus Communication RF Front-End-Back-End Subsystem (BCom-RFS): Provide Low Noise Amplifier (LNA), High Power Amplifier (HPA), satellite Bus Down/Up Radio Frequency (RF)-to-Intermediate Frequency (IF) conversion, and Analog-to-Digital/Digital-to-Analog conversion functions—Note that typical HPAs are Traveling Wave Tube Amplifier (TWTA) and Solid State Power Amplifier (SSPA), and some advanced satellite transponders use Linearized TWTA (L-TWTA) or L-SSPA in the RF Back-End Subsystem;

• Bus Subsystem 3—Bus Command & Data Handling Subsystem (BC&DHS): On-board computer that interfaces with all Bus components;

• Bus Subsystem 4—Bus Telemetry-Tracking & Command Subsystem (BTT&CS): Process uplink satellite Bus command data, perform satellite tracking functions and provide downlink Bus telemetry reporting satellite Bus’s heath and conditions;

• Bus Subsystem 5—Bus Electrical Power Subsystem (BEPS): Provide and regulate Bus power;

• Bus Subsystem 6—Bus Thermal Control Subsystem (BTCS): Maintain Bus’ thermal environments;

• Bus Subsystem 7—Bus Altitude and Determination Control Subsystem (BADCS): Provide satellite stabilization, control and positioning;

• Bus Subsystem 8—Bus Propulsion Subsystem (BPS): Provide propulsion functions for satellite maneuvering;

• Bus Subsystem 9—Bus Communication Security Subsystem (BCOMSEC): Provide Bus data encryption and decryption functions to protect data from intruders. Typically, BCOMSEC is tightly coupled with BTT&CS;

• Bus Subsystem 10—Bus Structure & Mechanism Subsystem (BS&MS): Provide structure and mechanism to mount all satellite Bus components.

Figure 1.

A typical satellite system production flow (redrawn from [6]).

Similarly, our survey also revealed that a typical mission PL consists of the following modular components [7, 8, 9, 10, 11, 12, 13, 14, 15, 16]:

• PL Subsystem 1—PL PAS: Similar to BPAS but for mission PL;

• PL Subsystem 2—PL Com-RFS: Similar to BCom-RFS but for mission PL;

• PL Subsystem 3—PL Digital Processing Subsystem (PDPS): Provide mission specific processing functions. For SATCOM missions, specific processing functions can be dynamic resources control, channelization processing, etc. For PNT missions, the functions can be time transfer processing functions. For imaging/sensing missions, the functions can be image preprocessing functions;

• PL Subsystem 4—PL C&DHS: Similar to BC&DHS but for mission PL;

• PL Subsystem 5—PL TT&CS: Similar to BTT&CS but for mission PL;

• PL Subsystem 6—PL EPS: Existing PLs use power supply from satellite BEPS;

• PL Subsystem 7—PL TCS: Maintain PL’s thermal environments;

• PL Subsystem 8—PL ADCS: Existing PLs use ADCS from the satellite BADCS;

• PL Subsystem 9—PL PS:: Existing mission PLs use PS from the satellite BPS;

• PL Subsystem 10—PL COMSEC: Similar to BCOMSEC but for mission PL;

• PL Subsystem 11—PL Frequency & Timing Subsystem (PFTS): Provide reference frequency and timing functions to meet specific mission requirements;

• PL Subsystem 12—PL Transmission Security Subsystem (TRANSEC): Provide security functions to combat unintentional and/or intentional Radio Frequency Interference (RFI) (e.g., frequency hopping/de-hopping, frequency spreading/de-spreading);

• PL Subsystem 13—PL Specific Mission Suite (SMS): Provide specific mission PL processing functions depending on whether the mission is Satellite Communications (SATCOM) mission or Position Navigation and Timing (PNT) mission or Imaging/Sensing mission [7, 8, 9, 10, 11, 12, 13, 14, 15, 16];

• PL Subsystem 14—PL Structure & Mechanism Subsystem (BS&MS): Provide structure and mechanism to mount all mission PL components.

In practice, the above satellite Bus modular components can be found in the following typical satellite Busses [7, 11, 14]:

• Loral Satellite Bus 1300 or Loral 1300

• Lockheed Martin (LM) A2100A/AX-Land Mobile/AX-High Power

• Boeing 702HP/HP-GEM/MP/702SP and 502.

For achieving optimum weight and power, existing satellite Bus and mission PL are tightly coupled together with customized interface design. The industry trends for the design and build of future satellite systems are moving toward OSA using MOSA principles, in which the satellite Bus is loosely coupled with the mission PL using “Open” and widely accepted interface standards. The key communication linkage between a satellite Bus and a mission PL is the communication data Bus. Currently, majority of satellite Busses employ the standard 1553 data Bus for data communications among Bus components, and between the satellite Bus and mission PL components. The communications over 1553 data Bus is limited to 1 Mega bit per second (Mbps). Recently, there was an advanced development effort that was funded by the U.S DOD to develop new 1553 standards called 1553 Enhanced Bit Rate (EBR–1553) increasing the speed to 10 MB/s [17]. The EBR-1553 requires a star/hub topology to provide the higher data rate and additional components to implement the architecture. For data rates larger than 10 Mbps, space industry trend is moving toward SpaceWire data Bus that was recently developed in Europe for use in commercial satellites and scientific spacecraft [18].

The objective of this chapter is three-fold: (1) Provides an overview of existing modular satellite Bus, mission PL architectures and related communication data Busses, (2) Discusses future trends on the modular and open design and build of satellite Bus and mission payload using MOSA principles, and (3) Addresses the practical design challenges associated with “Modular” and “Open” design for future satellite Bus and mission PL. The chapter is organized as follow: (i) Section 2 describes existing modular satellite Bus and mission PL architectures and related communication data Busses; (ii) Section 3 presents industry view on “Open” and “Close” interfaces for connecting satellite system components and existing popular standards; (iii) Section 4 discusses the interface design challenges and provides an overview of MOSA and related DOD Guidance and assessment tools for MOSA implementation; (iv) Section 5 provides examples how to transition modular satellite Bus and mission PL architectures to modular-and-open architectures using MOSA implementation approach and tools in Section 4; and (v) Section 6 concludes the chapter with remarks on the benefits associated with the proposed approach.

2. Existing satellite systems, related interfaces and standards

Figure 2 describes an overview of existing satellite systems, consisting of a satellite Bus, a mission PL and a typical set of interfaces between the Bus and PL using a standard data Bus. A typical set of interfaces between the satellite Bus and a mission PL includes seven interface types, namely: (i) Physical & Mechanical Interface, (ii) Electrical/Power/Cable Interface, (iii) Grounding Interface, (iv) Software & Data Interface, (v) Electromagnetic Compatibility (EMC)/ Electromagnetic Interference (EMI)/Electromagnetic Pulse (EMP) and Electro Static Discharge (ESD) Interface, (vi) Thermal Interface, and (vii) Frequency & Timing (F&T) Interface. This section focuses on satellite Bus and mission PL architectures and the data interfaces between them. Subsections 2.1 and 2.2 describe existing satellite Bus and mission PL architectures along with related interfaces and industry standards, respectively. Subsection 2.3 discusses existing standard 1553 data Bus and the pushes from space industry moving toward military standard 1553-B data Bus (MIL-STD-1553-B) and high-data-rate SpaceWire data Bus.

Figure 2.

Overview of existing satellite Systems using standard 1553 data bus.

2.1 Existing satellite bus, related interfaces and standards

As described in Section 1, existing satellite Bus architecture includes typical 10 modular components, namely, BAS, BComRFS, BC&DHS, BTT&CS, BEPS, BTCS, BADCS, BPS, BCOMSEC and BS&MS. A functional description for each of these modular Bus components is also described in Section 1. Figure 3 illustrates a notional block diagram for existing modular satellite Bus architecture. The figure shows that space industry has used the modular design concept to architect the satellite Bus, where common functions are group together and then isolate or separate from the other group of functions. As an example, BAS consists of a group of antenna components and control functions (e.g., antenna pointing, beamforming, etc.), which is separated and isolated from BComRFS. It is important to note that the figure also shows how these satellite Bus components are connected together, i.e., the lines with arrows connecting them. These lines represent the interfaces among the Bus components, where the interface can be any of the seven interface types described above. Below is a list of some of the existing interfaces and associated standards for existing satellite Bus based on National Aeronautical and Space Administration (NASA), European Space Agency (ESA), U.S. DOD and international Consultative Committee for Space Data System (CCSDS) standards [19, 20, 21, 22, 23, 24, 25, 26]:

• Typical NASA Electrical/Power/Cable Interface Standards [19, 20]:

  • Satellite Bus shall protect its own electrical power system via overcurrent protection devices on its side of the interface.

  • Satellite Bus shall deliver a maximum transient current on any Power Feed Bus of 100% (that is, two times the steady state current) of the maximum steady-state current for no longer than 50 ms.

  • Bus Survival Heaters, which are elements of the Bus thermal subsystem, shall be required to have power to heat certain satellite Bus components during off-nominal scenarios when the BEPS power is not fully energized.

• Typical U.S. DOD EMC/EMI/EMP/ESD Interface Standards [21]:

  • Power line conducted emissions for satellite Bus equipment shall meet the EMC interface specification specified in SMC Standard Handbook, SMC-S-008, Section 6, 6.01, 6.02, 6,03, 6.04, 6.05, 6.06, 6.07, and 6.08.

  • Power line conducted susceptibility for satellite Bus equipment shall meet the EMC interface specification specified in SMC Standard Handbook, SMC-S-008, Sections 6, 6.10, 6.11, 6.12, 6.13, 6.14, 6.15, 6.16, 6.17, 6.18 and 6.19.

  • ESD susceptibility for satellite Bus equipment shall meet the EMC interface specification specified in SMC Standard Handbook, SMC-S-008, Section 6, 6.43.

  • EMP susceptibility for satellite Bus equipment shall meet the EMC interface specification specified in SMC Standard Handbook, SMC-S-008, Section 6, 6.45.

• Typical NASA Grounding Interface Standards [20, 22]:

  • Satellite Bus EPS should ground in a way that reduces introducing stray currents or ground loop currents into the satellite Bus components.

  • Satellite Bus ground interface shall follow NASA single-point ground or multiple-point ground architecture.

• Typical NASA Thermal Interface Standards [19, 20]:

  • A conductive heat transfer of 15 W/m2 or 4 W shall be considered small enough to meet the intent of being thermally isolated.

• Typical Software & Data Interface Standards [19, 20, 23, 24, 25, 26]:

  • Satellite Bus command and telemetry data formats shall be NASA Unified S-Band (USB)/CCSDS standards or U.S. DOD Space-Ground Link Subsystem (SGLS) standards. Note that (i) most of NASA and ESA standards are CCSDS compliance for interoperability purpose, and (ii) some military systems have both USB and SGLS capabilities.

  • Satellite Bus “Safe Mode” is a combined satellite Bus components hardware and software configuration that shall be designed to protect the components from possible internal or external harm while making minimal use of satellite Bus resources (e.g., power).

  • Satellite Command SAFE Mode shall be required to protect and preserve satellite Bus components under anomalous and resource constrained conditions.

  • Satellite Bus components shall respond to uplink commands from the Satellite Operation Center (SOC) to suspend and resume the transmission of the Components’ telemetry data. For commercial satellite systems, SOC can also control the mission PL.

Figure 3.

Existing notional modular satellite bus architecture.

For military applications, majority of satellite Busses are usually designed using contractor’s custom designed interfaces and very tightly couple together to reduce weight, size and power. It is for this reason, current military satellite BTT&CS component also include the COMSEC component. For commercial applications, satellite developers are also concerned with weight, size and power reduction, but they are also concerned with component refresh and upgrade without redesigning the satellite Bus, hence commercial satellites tend to use modular Bus components and widely accepted interface standards to connect the internal Bus components. Industry views on the “open” and “close” interfaces will be addressed in Section 4.

2.2 Existing mission payload, related interfaces and standards

As pointed out in Section 1, existing mission PL architecture consists of 14 modular components, but there are three PL components that rely on the satellite Bus’ design, namely, PL EPS, PL ADCS and PL PS. Therefore, the mission PL architecture usually has 11 modular components, including PL AS, PL Com-RFS, PDPS, PL C&DHS, PL TT&CS, PL TCS, PL COMSEC, PFTS, PL TRANSEC, PL SMS and PL S&MS. A functional description for each of these mission PL modular components is also provided in Section 1. Figure 4 presents a notional block diagram for existing modular mission PL architecture. Similar to the satellite Bus design, the space industry has also applied the modular design concept to architect the mission PL. Below is a list of some of the existing interfaces and associated standards for existing mission PL leveraged from NASA, ESA, U.S. DOD and international CCSDS standards [19, 20, 21, 22, 23, 24, 25, 26]:

• Typical NASA Electrical/Power/Cable Interface Standards [19, 20]:

  • Sizing all components of the mission PL power harness, such as the wires, connectors, sockets, and pins to the peak power level shall be required by the mission PL equipment in addition to satellite Bus to prevent damage to the power harnessing.

  • PL Survival Heaters shall be required to have power to heat certain mission PL components during off-nominal scenarios when the BEPS power is not fully energized.

• Typical U.S. DOD EMC/EMI/EMP/ESD Interface Standards [21]: Similar to satellite Bus discussed above but for mission PL.

• Typical NASA Grounding Interface Standards [20, 22]: Similar to satellite Bus discussed above but for mission PL.

• Typical NASA Thermal Interface Standards [19, 20]:

  • The mission PL thermal design should be decoupled from the satellite Bus at the mechanical interface between the satellite Bus and neighboring mission payload to the maximum practical extent.

  • A conductive heat transfer of 15 W/m2 or 4 W shall be considered small enough to meet the intent of being thermally isolated.

• Typical Software & Data Interface Standards [19, 20, 23, 24, 25, 26]:

  • Mission PL command and telemetry data formats shall be NASA USB/CCSDS standards commercial applications or U.S. DOD SGLS standards for military applications. Some military systems have both USB and SGLS capabilities.

  • PL “Safe Mode” is a combined mission PL components hardware and software configuration that shall be designed to protect the PL components from possible internal or external harm while making minimal use of satellite Bus resources (e.g., power).

  • PL Command SAFE Mode shall be required to protect and preserve mission PL components under anomalous and resource constrained conditions.

  • Mission PL components shall respond to uplink commands from Mission Control Center (MCC) to suspend and resume the transmission of the mission PL components.

  • Mission PL shall be responsible for on-board mission data storage capabilities.

Figure 4.

Existing notional modular Mission payload architecture.

For most commercial applications, the MCC can be merged with the SOC, and the mission PL TT&CS (PTT&CS) and PL CD&HS (PCD&HS) components can be incorporated into satellite (i) Bus TT&C (BTT&CS) and (ii) Bus CD&HS (BCD&HS) components, respectively. Similar to the satellite Bus interfaces design, for military applications, the mission PL components are tightly coupled using contractor’s custom designed interfaces. For commercial applications, the mission PL components are loosely coupled using widely accepted open interfaces.

2.3 Existing data busses

Subsections 2.3.1 and 2.3.2 provide an overview of standard 1553 and SpaceWire communication data Busses, respectively.

2.3.1 Standard 1553 data bus

Existing commercial, civilian and military satellite data Busses have been using Military Standard 1553B (MIL-STD-1553B) data Bus for communications among satellite Bus and mission PL components. Figure 5 describes a typical MIL-STD-1553B System [17, 27, 28]. This figure uses MIL-STD-1553B terminologies: (i) the Bus Controller (BC) is considered as an Intelligent Terminal (IT) that is located in the satellite mission computer, which is usually referred to as a Satellite Bus C&DH component, and (ii) Remote Terminal (RT) is considered as a slave terminal that is located in satellite platform components, which can be located in any satellite Bus or mission PL components.

Figure 5.

Typical civilian and commercial MIL-STD-1553B satellite Systems.

Figure 5 shows a typical commercial satellite system with RTs located in both satellite Bus and mission PL components. As an Example, the RTs located in satellite components are BAS, BADCS, BTCS and BTT&CS; and RTs located in the mission PL components are PAS, PTCS, PDPS, PTRANSEC, and PFTS. For military applications, the Mission Computer (MC) can be located in both satellite Bus and mission PL, where the MC in the satellite Bus is responsible for all control functions associated with the satellite operations and MC in the mission PL is responsible for all control functions related to the mission PL operations.

2.3.2 Standard SpaceWire data bus

SpaceWire (SpW) is an industry standard with protocol derived from IEEE-1355 and ECSS-E50-12C managing by the international SpW working Group [18, 29, 30]. The SpW standard is a self-managing serial protocol that provides a high-speed data rates from 2 to 400 Mbps, and low power serial interface using LVDS¹ Drivers with distances up to 30 feet while offering a flexible simple user interface. Figure 6 illustrates typical uses of SpW data Bus with a PCD&HS, a SpW Router and SpW cables for connecting mission PL components. Some examples of existing satellite programs employed SpaceWire standard are: TacSat (part of the U.S. Operationally Responsive Space Program), NASA Lunar Reconnaissance Orbiter (Orbiting the Moon taking high resolution images), ESA Sentinel-3 (a pair of satellites providing operational Earth observation services using optical and microwave instruments), and Japanese NEC NEXTTAR (one of the first spacecraft designed using SpW for all of its onboard communications).

Figure 6.

Typical civilian and commercial SpaceWire satellite Systems.

3. Industry view: open vs. close interfaces and standards

Figure 7 presents the space industry view on open and close interface design. This view separates the interface design into two categories, namely, Contractor Proprietary Interface and Contractor Non-Proprietary Interface. Under this view, the interface standards are then classified into two categories, namely, Preferred and Non-Preferred Interface Standards. Based on this view, Section 3.1 defines open interface design, and Section 3.2 defines close interface design. Section 3.3 provides a list of existing popular open standards widely accepted by space industry.

Figure 7.

Industry view on open and closed interfaces design.

3.1 Open Interface design

From Figure 7, the open interface design falls into the contractor non-proprietary design category. For the interface design to be open, the interface design shall not be contractor proprietary and that the interface shall use either popular open interface standards widely accepted by space industry or open interface standards with little market support and narrowly used by space industry. Thus, a popular open interface design is a non-proprietary design that uses popular open interface standard that is widely used by space industry. The benefits of open interface design for the satellite buyers are (i) improving competition allowing various space vendors (or contractor) to build open satellite Bus and mission PL subsystem components, (ii) ease of refresh and technology upgrade allowing to swap subsystem components without impacting the overall system, (iii) ease of adapting to new requirements and operational threats, (iv) incorporating innovation by allowing operational flexibility to configure and reconfigure a mission PL quickly to meet rapidly changing operational requirements, (v) enabling cost saving and cost avoidance during the design and sustainment phases by reusing technology and Software/Hardware/Middleware (SW/HW/MW) components, and using existing standardized HW/SW/MW parts and modules, and (vi) improving interoperability where severable HW/SW/MW modules can be changed independently.

3.2 Close interface design

As shown in Figure 7, the close interface design shall fall into contractor proprietary category. For an interface design to be close, it shall be contractor proprietary and that the interface shall use either close interface standards with little market support narrowly used by space industry or popular closed interface standards widely used by space industry. Thus, a popular close interface design is a contractor proprietary design that uses popular closed interface that is widely used by space industry. The key benefits of close interface design are the potential reduction of weight, size, power and manufacturing cost.

3.3 Popular open standards

Based on Figure 7, the criteria for popular open standards are (i) publicly available and widely used by both satellite Bus and mission PL vendors, (ii) community and/or industry consensus-based that are matured and stable, and (iii) technically adequate for all future commercial, civilian and military satellite systems. Following is a list of current popular standard organizations and widely adopted open standards [18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]:

• Consultative Committee for Space Data Systems (CCSDS) Standards: is a multi-national forum for the development of communications and data systems standards for spaceflight. The goal is to enhance governmental and commercial interoperability and cross-support, while also reducing risk, development time and project costs.

• AIAA Space Plug-and-play Avionics (SPA) Standard: SPA is a set of AIAA standards developed for spacecraft platform, subsystem, and component (including payload) developers for integrating plug-and-play characteristics into spacecraft structures, avionics, and hardware and software components to promote their rapid integration. The SPA community anticipates adding protocols (e.g., Ethernet as SPA-E) as the PnP capabilities are normalized.

• MIL-STD-1553 Standard: is a military standard published by the United States Department of Defense that defines the mechanical, electrical, and functional characteristics of a serial data Bus.

• SpaceWire Standard: is a spacecraft communication network standard based in part on the IEEE 1355 standard of communications. It is coordinated by the European Space Agency (ESA) in collaboration with international space agencies including NASA, Japanese Space Agency (JAXA) and Russian Federal Space Agency (RKA).

• NASA/SMC/Aerospace Hosted Payload Interface Design (HPID): this design guideline provides a prospective Instrument Developer with technical recommendations to assist them in designing an Instrument or Payload that may be flown as a hosted payload on commercial satellites flown in Low Earth Orbit (LEO), or Geostationary Earth Orbit (GEO).

• SQL for databases specified in ANSI ISO/IEC 9075–1, ISO/IEC 9075–2, ISO/IEC 9075–3, ISO/IEC 9075–4, ISO/IEC 9075–5.

• HTML for presentation layer specified in XML 1.0 www.webstandards.org.

• XML for data transfer.

• Web Services for remote system calls.

• U.S. Space and Missile Systems Center (SMC) approved a project for developing Common Payload Interface Specification (CoPaIS) standard for satellite-to-payload Command and Data Handling (C&DH) interface intended for all future SMC procured medium to large satellites [31].

• Other popular standards: MIL-STD-1553B, CAN Bus, RS-422 (TTC-B01 Protocol)/EIA/TIA-422, RS-422 (PC-Protocol).

4. Interfaces design challenges and MOSA implementation

This section addresses the design challenges and is divided into four subsections, including: (i) Subsection 4.1 discusses interface design and practical design issues; (ii) Subsection 4.2 introduces MOSA concept; (iii) Subsection 4.3 presents DOD MOSA guidance and the U.S. Naval Open Architecture (NOA); and (iv) Subsection 4.4 discusses MOSA tools and approach for MOSA implementation that addresses the design issues identified in Subsection 4.1.

4.1 Interface design and practical design challenges

The interfaces between satellite subsystem components can be SW, HW or MW interfaces. The design and build of these interfaces are well incorporated into any satellite subsystem components “Design Product” and associated “Design Process”.

The Design Product includes System Architecture, Interface Product, Independent Verification and Validation (IV&V) Test Plan, Schedule, Design Approach, Acceptance Criteria, and System-Built Product.

For MOSA, the Design Process is expected to incorporate MOSA into: Architecture Process, Interface Management, IV&V Process, and System Engineering and Integration (SE&I) Process. The Interface Product and its open interface design using MOSA along with the Interface Management are the key challenges in the development of open-and-modular satellite systems. The key design challenges for the design and build of open-and-modular satellite systems are:

• Challenge 1: Determination of Key Open Subsystem (KOSS): This is also known as KOSS Selection. Ideally, all modular subsystem components should be made open. But this is not practical, because some interfaces need to be customized using close interface design due to weight, size and power reduction requirements. The key challenge here is to identify a set of criteria that can be used for KOSS selection. Subsections 4.3 and 4.4 will address this challenge.

• Challenge 2: Designation of Key Interfaces for the Selected KOSS: Satellite system designers need to identify a subset of selected set of KOSS components that can be designated as key interfaces. The key challenge here is to identify a business case for the designated key interfaces. Subsections 4.3 and 4.4 will describe selection criteria and tool to address this challenge.

• Challenge 3: Selection of Open Standards for the Designated Key Interfaces: Selection of the popular and open standards for the designated key interfaces is also a potential challenge for the designers. The selection should be based on the cost, required technical specification and availability of “open” products in the market and their usage by space industry. SubSection 3.3 above provides a list of some existing open and popular standards. Subsection 4.4 will discuss how to resolve this challenge by developing a business case to justify the selection of key interfaces and associated open standards.

• Challenge 4: Management of Key Open Interfaces: Not all identified key interfaces in Challenge 2 can be designated an open interface standard at the initial system design phase due to market unavailability. Hence, managing these interfaces can be a potential challenge ensuring that they will be “open” by the time of Full Operational Capability (FOC) deployment. Section 4.3 discusses DOD guidance for managing key interfaces for military satellite system development.

4.2 Introduction to MOSA

U.S. DOD recommends OSA design using MOSA principles for future military satellite system development with a goal to achieve a balance between business and technical objectives that make a business sense in terms of (i) increase competition and lower system acquisition cost, and (ii) lower sustainment cost over its life cycle. MOSA design approach requires to implement five MOSA principles, including two Business (B) and three Technical (T) principles [1, 2]. Figure 8 captures these five B and T principles. Recently, U.S. Navy augmented MOSA principles with addition five Naval Open Architecture (NOA) principles, including two business and three technical principles as shown in Figure 8 [3].

Figure 8.

MOSA and U.S. NOA approach.

Subsections 2.1 and 2.2 provide current implementation of the Technical principle 1 (T1) for the modular design of satellite Bus and mission PL, respectively. The remaining Subsections 4.3 and 4.4 discuss the implementation of T2, T6, Business principle 3 (B3), and B4 using DOD guidance for addressing the challenges presented in Subsection 4.1.

4.3 DOD guidance

MOSA mandated the space system technical requirements be based on the maximum extent practicable on open standards as indicated in Section 3.2 of the U.S. DOD Guidebook for Program Managers [1]. The book provides MOSA² guidelines and contract language for generating a Request for Proposal (RFP) [1]. At the minimum, the RFP shall incorporate the following MOSA tasks that can help to minimize the MOSA implementation risk in the design, build and test of new satellite systems:

• Design the open system architecture using open interfaces. Implement the open interfaces using open standards for connecting HW-to-HW, and SW-to-SW.

• The satellite system design shall accommodate growth and provide open interface standards to allow future reconfiguration and addition of new capabilities without large-scale redesign of the system.

• Develop a capability roadmap for the system covering the life of the system following the completion of the rapid prototyping contract phase.

• Address “Commercial Off the Shelf/Non-Developmental Item and Open System Software Licenses,” including Open Source Software, Verification of Open Architecture, Modular Open Systems Approach Metrics to be Reported, Modular Open System Approach Analysis Report.

• Generate Open System Management Plan (OSMP) to capture all MOSA activities, technology roadmaps; Define and track MOSA metrics; Update roadmap. Following is a list of MOSA metrics that should be used to demonstrate an open satellite system:

  • $\text{Percentage}\left(\%\right)\text{Open}\mathrm{Key}\text{Interfaces}=\frac{\text{Number Open}\mathrm{Key}\text{Interfaces}}{\text{Total Number}\mathrm{Key}\text{interfaces}}$

  • Number and location of private extensions on open interfaces;

  • Contractor use of company private extensions on open standard middleware;

  • Open Software Design Tool Kits/Component Design Tool Kits (OSDTK/CDTK) will be provided with a minimum of Government Purpose Right (GPR); Minimal license fees may apply for COTS items;

  • Percentage of Chief Engineers, IPT Leads and program team members on architecture, software, logistics and Test & Evaluation trained in Open Systems Architecture and the MOSA tools;

  • Future Competition Strategy included in the OA Business plan within the OSMP;

  • MOSA (or OSA) requirements flowed down to sub-tier suppliers and recorded in IBM Rational^® DOORS^® requirements database or an MBSE digital model.

  • Design a system that consists of hierarchical collections of software, hardware, and firmware Configuration Items (CI’s). Document in the MOSA Analysis Report its modularization choices for the system design and any tradeoffs performed in accordance with the OA verification plan.

  • Document any processes or applications necessary to support MOSA in the MOSA Analysis Report.

The above U.S. DOD’s guidance encourages the satellite system designers to consider the above MOSA items in the design and build of the modular and open satellite Bus and mission payload for future space systems. The following section presents a proposal for assisting the satellite system designers to implement these MOSA items along with assessment tools provided by U.S. DOD.

4.4 MOSA implementation and assessment tools

It is observed that the U.S. DOD, U.S. civilian agencies (e.g., NASA, NOAA, etc) and U.S. satellite manufacturers/suppliers (e.g., LM, Boeing, Northrop Grumman (NG), Raytheon, L3, etc) are investigating approaches for the modular and open design and build of satellite Busses and mission PL’s using MOSA modular and open design principles. Figure 9 proposes an approach to design and build of future modular and open satellite Busses and mission PLs, and allowing the satellite buyers to: (i) Buy the satellite Bus (see Path A of the figure) and mission PL (see Path B) from different satellite manufacturers/suppliers, (ii) Have an option to choose a third satellite vendor to integrate the satellite Bus and mission PL (see Path C).

Figure 9.

Proposed implementation approach for design and build of satellite Systems allowing buyers to acquire satellite bus and Mission PL independently.

The proposed MOSA implementation approach shown in Figure 4 consists of six basic steps that are incorporated into three execution paths, namely, Path A, Path B and Path C:

• Path A is for the satellite Bus manufacturer/supplier. This path has three basic steps:

  • Step I-A: Develop Modular satellite Bus Architecture (MoBA). The MoBA subsystem components are described in Sections 1 and 2 (see Figure 3).

  • Step II-A: Designate KOSS’s and select open standards for all internal satellite Bus subsystem components. Open interface standards selection and designation of KOSS are discussed in Sections 3 and 4.

  • Step III-A: Design and build Open Modular satellite Bus System (OMoBS). This step is achieved by identifying all potential KOSS’s from the satellite Bus to any mission PL’s, i.e., the selected KOSS’s should be independent of mission types. The satellite Bus manufacturer is responsible for integrating all Bus components and have the satellite Bus ready for sale.

• Path B is for the mission PL manufacturer/supplier. This path also has three basic steps that are similar to Path A:

  • Step I-B: Develop Modular Mission PL Architecture (MoPA). The MoPA subsystem components are also described in Sections 1 and 2 (see Figure 4).

  • Step II-B: Designate KOSS’s and select open standards for all internal Mission PL subsystem components. Open interface standards selection and designation of KOSS for mission PL are also discussed in Sections 3 and 4.

  • Step III-B: Design and build Open Modular Mission PL System (OMoPS). This step is achieved by identifying all potential KOSS’s from the any mission PL’s to satellite Bus, i.e., the selected KOSS’s should be independent of mission types. The mission PL manufacturer is responsible for integrating all mission PL components and have the PL ready for sale.

• Path C is for the satellite system integrator. This path has additional three new steps:

  • Step IV: The system integrator works with satellite Bus and mission PL manufacturers to develop a satellite system interface specification specifying all “open” and “close” interfaces between the mission PL-and-satellite Bus. All open interfaces between the mission PL-and-satellite Bus shall be selected to meet the business and performance objectives approved by the buyer. The system integrator performs satellite Bus and mission PL integration using the approved interface specification.

  • Step V: System integrator performs system test and verification subject to buyer’s approval.

  • Step VI: System integrator delivers the satellite system to the buyer.

DOD has also developed MOSA tools to assist MOSA implementation and assessment of military satellite Bus and mission PL “Openness”. These tools can also be used for civilian and commercial applications. The DOD tools include MOSA Program Assessment and Rating Tool (PART), Open Architecture Assessment Tool (OAAT), and Key Open SubSystem (KOSS) Tool:

• MOSA PART³: It is being used by DOD as the standard MOSA program assessment and rating tool for DOD space system programs.

• MOSA OAAT⁴: Assist U.S. Navy program managers in assessing the “openness” of their programs. It aligns to the Open Architecture Assessment Model (OAAM) as approved by Assistant Secretary of The Navy (ASN) for Research, Development and Acquisition (RDA), which serves as the Navy Acquisition Executive. Other DOD agencies have also been using OAAT since the tool can provide a reproducible and objective method of conducting program assessments.

• MOSA KOSS Tool⁵: One of the key MOSA principles is the Business Principle number 4, namely, Designate Key Interfaces (see Figure 8, B4). The identification of KOSS’s is an important task in realizing open systems. This MOSA principle requires the system designers to compromise between cost and performance by selecting a set of KOSS’s with their associated interfaces that can be assigned widely used open standards allowing for easy and affordable update and frequent refresh. MOSA KOSS tool provides guidance for KOSS’s identification and selection. The tool makes use of system capability road map, system requirements and Subject Matter Expert (SME), program’s sponsor and warfighter knowledge to identify the system/subsystem components expected to have a high volatility over the system life cycle. The tool specifies the key interfaces as those either side of volatile components. The tool will help the satellite system designer to identify and rank KOSS’s components that will meet both programmatic and technical requirements.

5. Future resilient and robust satellite system architectures

This section demonstrates how to use Steps II-A and II-B of the proposed MOSA implementation approach presented in Section 4.4 for the design and build of future resilient and robust satellite systems. Subsections 5.1 and 5.2 present potential modular-and-open satellite Bus and mission PL architectures, respectively.

5.1 A potential modular open satellite bus architecture solution

To demonstrate how to transition the notional modular satellite Bus system architecture presented in Figure 3 to a modular-and-open satellite Bus architecture, this subsection provides an example for the transition of three modular Bus subsystems, namely, BC&DH (Bus Subsystem 3), BTT&C (Bus Subsystem 4) and BEPS (Bus Subsystem 5). These modular Bus subsystems are decomposed to subsystem component-level and analyzed for consideration as potential KOSS’s for open interface standardization. Table 1 summarizes the decomposition and analysis results for these three satellite Bus subsystems.

Modular satellite Bus subsystem component	Modular satellite Bus subsystem and component description	Recommendation for open interface Standardization (potential KOSS)
BC&DHS Component No.	Bus Command & Data Handing Subsystem (C&DHS)
BC&DHS-1	Command Authentication Processing Unit (Sync Word Frame Lock, Unparsed Command)	Recommend for Interface standardization
BC&DHS-2	System Timing Unit
BC&DHS-3	Fault Management Processing Unit (Execute Stored CMD Sequence, Monitor System Health)	Not recommended for interface standardization due to many variations between systems
BC&DHS-4	Bus Resource Management Processing Unit (Managing Internal and External Bus Data)	Recommend for open interface standardization
BC&DHS-5	Memory Storage Unit
BC&DHS-6	Spacecraft Control Processor
BC&DHS-7	Bus Telemetry Conditioning Processor	Not required; software driven functions. Should be considered in software interface analysis.
BC&DHS-8	Bus Cyber Security Unit	Recommend for open interface standardization
BTT&CS Component No.	Bus Tracking-Telemetry & Command Subsystem (TT&CS)
BTT&CS-1	TT&C Waveforms/MODEM	Recommend for open interface standardization
BTT&CS-2	TT&C Antenna Assembly for S-Band/L-Band	Not recommended for interface standardization.
BTT&CS-3	TT&C RF Front-End and Back-End Assembly	Recommend for open interface standardization
BTT&CS-4	Unified S-Band (USB) RX/TX Assembly
BTT&CS-5	SGLS S-Band RX/TX Assembly
BTT&CS-6	SGLS Base Band Signal Processing (USB Mode1, 2)	Recommend for open interface standardization
BTT&CS-7	In Band TT&C Processor Located at Private Station	Not recommended for interface standardization due to many variations between systems
BTT&CS-8	Power Controller Assembly	Recommend for open interface standardization
BEPS Component No.	Bus Electrical Power Subsystem; (EPS)
BEPS-1	Solar Array (SA)	Recommend for open Interface standardization.
BEPS-2	Battery Assembly (BA)	Not recommended for interface standardization; Battery size will vary depending on the mission profile. Additional batteries could potentially require customized interfaces to tie all batteries to power bus.
BEPS-3	Solar Array Drive Assembly (SADA)	Recommend for open Interface standardization.
BEPS-4	Transient Filter Unit (TFU)	Not recommended for interface standardization
BEPS-5	Bus Power Regulation Unit (BPRU)	Recommend for open Interface standardization.; .
BEPS-6	Fuse Box Assembly (FBA)
BEPS-7	Pyro Relay Assembly (PRA)

Table 1.

Satellite bus subsystems decomposition and potential KOSS.

In practice, the preliminary KOSS analysis results shown in Table 1 should be finalized by the system designer using DOD KOSS tool discussed in Section 4.4. As shown in Table 1, standardizing the BC&DH data interfaces will probably provide the biggest return on investment since the BC&DH subsystem interfaces with each onboard system. Incorporation of the timing interface along with the data interface will minimize the amount of connections, thus reducing overall system mass. Any interfaces that require a significant amount of analysis or Non-Recurring Engineering (NRE) hours is not a good candidate for standardization. The fault management processing interface is in this category, and it is not recommended for standardization.

5.2 A potential modular open Mission payload architecture solution

This subsection provides an example for the transition of the notional modular mission PL architecture presented in Figure 4 to a modular-and-open mission PL architecture. Table 2 summarizes the decomposition and KOSS analysis results for four mission PL subsystems, including PAS (PL Subsystem 1), CPCom-RFS (PL Subsystem 2), PDPS (PL Subsystem 3) and PFTS (PL Subsystem 11).

Modular mission PL subsystem component	Modular mission PL subsystem and component description	Recommendation for open interface standardization (potential KOSS)
PAS Component No.	PL Antenna Subsystem (PAS)
PAS-1	PL RF Antenna Configuration (PRAC)	Not recommended for interface standardization due to many variations between systems
PAS-2	Beam Forming Unit (BU)
PAS-3	Antenna Controller (AC)	Recommend for Open Interface standardization
PCom-RFS Component No.	PL Com RF Front-End/Back-End Subsystem (CPCom-RFS)
PCom-RFS-1	PL LNA Component	Not recommended for interface standardization due to many variations between systems/subsystems
PCom-RFS-2	PL HPA Component
PCom-RFS-3	Multi-RF Wideband Receiver (RX)
PcCm-RFS-4	PL Up/Down Converters	Recommend for Open Interface standardization
PCom-RFS-5	Tunable IF Down Converters
PDPS Component No.	PL Digital Processing Subsystem (PDPS)
PDPS-1	PL ADC/DAC	Not recommended for interface standardization due to many variations between systems
PDPS-2	FPGA Processor
PDPS-3	PL MOD and DEMO (Optional)
PDPS-4	Digital Network Switch (Optional)
PDPS-5	PL System Controller
PTFS Component No.	P/L Frequency and Timing Subsystem (PFTS)
PFTS-1	Atomic Clock Unit (ACU)	Not recommended for interface standardization; ACU and CM&CU will vary depending on mission type and mission requirements
PFTS-2	Clock Monitoring & Control Unit (CM&CU)
PFTS-3	Frequency Generation & Up conversion Unit	Recommended for Interface standardization.
PFTS-4	Timing Variation and Frequency Stability	Not recommended for interface standardization

Table 2.

Mission payload subsystems decomposition and potential KOSS.

The mission PL digital processing system is not recommended for interface standardization due to many variations between systems and subsystems. Multi-RF Wideband RX Up/Down Converters and Tunable IF Down Converters require a significant amount of analysis or NRE hours and are also not a good candidate for standardization. Again, DOD KOSS tool should be used to finalize the KOSS analysis results presented here for actual design and build of the satellite systems.

6. Conclusion

The chapter provides an overview of existing modular satellite Bus and mission PL architectures and associated standards for communication data Busses. The chapter defines open and close interfaces along with industry approved popular standards and discusses the interface design challenges. Moreover, the chapter provides an overview of MOSA and related DOD guidance and assessment tools to address the interface design challenges. Examples for the design and build of modular-and-open satellite Bus and mission PL architectures are also presented. The intent of this chapter is to provide an innovative approach for the satellite system designer to design and build of the next generation satellite achieving a balance between business and technical objectives that make a business sense for both the satellite manufacturers and buyers in terms of lower system acquisition and sustainment costs over its life cycle. The MOSA implementation approach presented here allows the satellite manufacturers to build the satellite Bus and mission PL separately for more production, flexibility, and market competition. Concurrently, the approach also allows the satellite buyers to buy satellite Bus at high volume with reduced unit costs and less schedule risk. Another benefit for the satellite buyer is the adaptability of changing the requirements on the mission PL without impacting the satellite Bus.

Acknowledgments

Although the preparation of this work was not funded by The Aerospace Corporation, but the author acknowledges the work presented in this chapter was based on his knowledges accumulated over the years from many space programs at The Aerospace Corporation, Raytheon and Jet Propulsion Laboratory. In addition, the author would like to express his appreciation to Aerospace’s manager, Ms. Navneet Mezcciani, for her professional support.

Conflict of interest

The preparation of this chapter was not funded by the Aerospace Corporation, and it was done by the authors using his own time and resources, thus it does not represent the Aerospace Corporation’s view on the DOD guidance for MOSA implementation and the proposed system architecture solutions.

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.