Future Satellite System Architectures and Practical Design Issues: An Overview

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.


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

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

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

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.

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 1 Drivers with distances up to 30 feet while offering a flexible simple user interface.

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.

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

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.

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

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

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 2 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: • Develop a capability roadmap for the system covering the life of the system following the completion of the rapid prototyping contract phase.
• • 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.

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).
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 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-andsatellite 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 3 : It is being used by DOD as the standard MOSA program assessment and rating tool for DOD space system programs. 3 PART can be found from: https://www.dau.mil/cop/mosa/Lists/Tools/DispForm.aspx? ID=2&Conte ntTypeId =0x01002BC08FCA204040449CF11CB472BEEE1800AA6D1BC9926604469A02D

DB936F94D1F
• MOSA OAAT 4 : 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 5 : 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.

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.

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

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

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.

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

Author details
Tien M. Nguyen 1,2 1 California State University, Fullerton, USA 2 The Aerospace Corporation, El Segundo, USA *Address all correspondence to: tmnguyen57@fullerton.edu; 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.