Applying MBSE to Optimize Satellite and Payload Interfaces in Early Mission Phases

Abstract

The use of model-based systems engineering (MBSE) has been increasingly explored recently in industries that require multi-discipline engineering coordination. In the European space industry, applying MBSE for the engineering of space systems has been an ongoing undertaking on many missions. In the following paper, the MBSE activities in CAMEO conducted during the A/B1 phases of a typical Earth observation satellite engineered by Airbus are discussed in detail in the form of a case study. The analyses shown are based around the modeling of the spacecraft electrical interfaces in CAMEO. This model was used to automate electrical interface control documents (EICDs) and enable the control of electrical interface development. These methodologies were further put in the context of Airbus’ satellite design processes to assess the benefits of an MBSE approach to the current electrical interface engineering procedure and the potential for the reuse of CAMEO models between satellite projects. The reduction in system engineering effort through the reuse of models to modularly create similar satellite systems for efficient concept evaluation and comparison is a clear benefit.

1. Introduction

Model-based systems engineering (MBSE) is a methodology used in systems engineering that emphasizes the use of models to support the full lifecycle of complex system development, from requirements and design to analysis and validation. MBSE replaces the traditional document-centric approach with a model-centric approach, enabling better management of complexity, improved communication among stakeholders, and more efficient system development processes. The term MBSE has been introduced by Wymore [1], where he covered the mathematical framework for system engineering such as algebraic relationships among systems and the structure of requirements. The growing adoption of digital-modeling environments in recent years has driven the increased use of MBSE [2].

The benefits and potential of applying MBSE in the lifecycle are summarized in [3] as follows:

• Improved communication among the stakeholders by using standardized notation, especially SysML, to consider stakeholders viewpoints;
• Improved system understanding by showing interconnections and emphasizing interdependencies;
• Traceability and transparency of design decisions by using one consistent model;
• Overall consistency by preventing the unconscious usage of outdated information and serving as a single source of truth.

However, several research articles from the last years also show that implementing MBSE has various challenges that hinder industry from adopting the methodology to the full degree [4,5,6].

• Tool integration and interoperability: the wide variety of available MBSE tools can lead to fragmentation and compatibility issues;
• Model Management: managing complex and large-scale models require proper configuration management, and governance practices;
• Data Quality and Consistency: maintaining high quality data across models is crucial;
• Integration with Legacy Systems that were not designed with the MBSE approach can be disruptive.

1.1. MBSE for Space Missions

Interface coordination has been a pervasive problem seen throughout the space industry for many years due to its interdisciplinary nature and the sheer number of interfaces that need defining on a satellite [7]. Lessons learned documents from NASA on the pathfinder mission specify this issue as a common thread throughout their projects, and another common thread is that interface control documents (ICDs) require designated coordination efforts from the engineering team, weekly reviews, and the periodic verification of accuracy so that errors do not appear in hardware [8].

In the European space industry, applying MBSE for the engineering of space systems has been an ongoing undertaking.

Table 1. Non-comprehensive list of ESA missions where MBSE has been applied [10].

Mission (Phase) & Purpose	MBSE Software	Goals for MBSE Activities
ARIEL (B1) Science mission studying exoplanets with visible and IR wavelengths	Enterprise Architect (SysML)	Single source of truth for ESA, Industry, Consortia Traceability between requirements, functional, physical architectures
EnVision (B0) Science mission studying the evolution of Venus	CAMEO (SysML), Capella Enterprise Architect (SysML) DOORS	Engineering/management requirements Physical modeling, traceability requirements System budgets
EL3 (B1) Lunar lander adaptable for different missions and payloads	CAMEO (SysML) Capella, DOORS	Single source of truth for ESA, Industry, Consortia, with model centric review process Physical architecture, functional analysis, traceability requirements System budgets
EUCLID (D) Science mission to measure universe expansion and gravity strengths	Enterprise Architect (SysML)	Use MBSE in real mission development to assess benefit and usage SE at mission level using MBSE approach
MSR—Earth Return Orbiter (B2) Component of Mars Sample Return mission to return samples to Earth	CAMEO (SysML) DOORS	Traceability requirements to architectures in early phases Functional, Operational, Physical architectures Interface and verification data integration

reviews the state of MBSE activities on several ESA missions and the software tools used to carry them out. This non-comprehensive overview summarizes the cutting-edge studies that are either completed or ongoing, which may have little information publicly available. Common lessons learned from across the ESA missions highlight the interoperability and exchange of model information as a key issue, as well as a heterogeneous approach across the industry that should be streamlined. A critical lesson from this early stage MBSE study was the importance of automating the extraction of information from the model. Thus, storing information in the model should be conducted in a systematic way with preset locations and formats. This can be performed most efficiently through the creation of a skeleton model that can be populated as the system design evolves [9].

Within companies, particular processes and tools to employ MBSE have been developed. Possibilities for system modeling tools include CAMEO, Capella, Valispace, and Enterprise Architect, where the selection of a particular tool is performed at a company level for the standardization of processes across their missions. At Airbus, the defined standard uses SysML (System Modeling Language) in CAMEO. Many complex satellite missions have used this tool for different applications within their systems engineering teams depending on the project stage, type of analysis desired, and amount of time and budget they are able to invest [10]. However, both in the literature and in previous Airbus projects, there has been very little MBSE implementation in early project stages (phase 0/A/B1) on Earth observation missions.

One of the earliest phase adoptions of MBSE was implemented in the ELCANO mission, which is a complex GNSS mission that studied MBSE uses in Phase 0 with Capella. Here, an operational analysis provided a breakdown of operational scenarios and processes that were used as inputs for system analysis in order to generate deliverable documents. Thus, coded templates for major review documents to describe the complex system could be outputted from the Capella model. A critical lesson from this early stage MBSE study was the importance of automating the extraction of information from the model. Storing information in the model should be conducted in a systematic way with preset locations and formats. This can be performed most efficiently through the creation of a skeleton model that can be populated as the system design evolves [9].

1.2. Identified Engineering Problem: Interface Control

Interface coordination has been a pervasive problem seen throughout the space industry for many years. In [11], Rand et al. also cited issues at the interfaces between systems in the development of a complex multi-payload mission, with early-stage line-by-line ICD review being an important task in their interface coordination work. To eliminate such intensive interface coordination work, standardized interfaces have been studied by Kalmanson et al. [12] for the StarBus satellite platform.

The interfaces between spacecraft and payload have been studied by Klicker in [13], where the focus was on developing a complete and coordinated ICD in a standardized ICD creation process to reduce the need for additional documentation. Klicker’s research highlights the necessity of an accurate ICD as it serves as the source of information for hardware creation and an assurance of compatibility between the spacecraft’s systems and the payload [8,12,13,14,15]. Since the ICD is a living document, updated as the design progresses, versioning is critical and constant coordination is required between systems.

Applying an MBSE approach to interface coordination and ICDs from the early phases of a typical EO mission has not yet been studied but is a potentially valuable use-case for MBSE that should be explored. Since the need for the Sentinel-3 Next Generation Topography (S3NGT) mission to have increased early phase interface coordination aligns with this gap in MBSE research, this was the focus of the work conducted in this case study.

2. Methodology and Approach

2.1. The Sentinel-3 Next Generation Mission

The application of MBSE was studied on the S3NGT mission. The goal of S3NGT is to ensure the continuity of the current Copernicus Sentinel-3 nadir altimeter measurements from 2030 to 2050. Since the current Sentinel-3 constellation temporal and spatial sampling capabilities are insufficient, improving global-scale altimeter sampling is a key objective. Therefore, S3NGT consists of a constellation of two large satellites, flying in formation in a sun-synchronous dawn–dusk (LTAN 6pm) orbit. The payloads include a ka-band across-track interferometer with a low-resolution mode for the open ocean and land ice and a high-resolution mode for the ocean and hydro ice. Additionally, a MWR (microwave radiometer) is foreseen. The constellation can achieve global five-day revisit with an effective ocean spatial resolution of 50 km. The payload measurement geometry is depicted in Figure 1 [16].

The detailed satellite platform units were modeled using heritage estimates. The unit specifications were taken from the Airbus AstroBus product line. The AstroBus standard is a proprietary platform for Earth observation missions and provides a family of products for modular satellite building blocks, all complying with the latest operational standards [17].

2.2. Study Goal and Preliminaries

The focus of this case study was to discover areas and workflows that cause issues during the B2/C/D mission phases that could benefit from additional analyses and adjustments during the A/B1 phases. The success criteria of such a case study included the presentation of a clear reduction in the number of hourly efforts required for tasks that required repetitive work and the coordination of multiple documents. Due to this, the main focus of studying the application of MBSE in CAMEO (version 19SP4) to the S3NGT mission was the assessment of the mission needs, so that “modeling for the sake of modeling” was avoided, and concrete outputs could be provided to the project team. Due to the heritage of the Sentinel-3 mission and other altimetry missions that Airbus had previously built, as well as the substantial experience of the engineering team, many aspects of this mission were already well defined and understood, and there was skepticism from an experienced systems engineering team that well established workflows could be improved with MBSE. As a result, the objective of this early phase MBSE case study was to explore an MBSE approach that had not previously been used, both at Airbus or in the literature, that would focus on solving or improving difficulties in the early phase engineering work.

An approach was taken that involved the interviewing of senior systems engineers [14,18] as well as a review of the literature of previous MBSE work conducted for engineering on satellite missions to identify the traditionally weaker areas of satellite development that could potentially be addressed using MBSE in CAMEO in a case study format. The engineers who participated in interviews had significant (10+ years) experience on Earth observation missions at Airbus, were familiar with the expansive coordination efforts required at all phases of satellite development, and were currently working on the S3NGT mission. It was discovered that new technologies on both platform and payload were often the largest source of schedule delays and coordination issues in later phases of the project. Interface coordination has always presented a challenge due to its interdisciplinary nature and the sheer number of interfaces that need defining on a satellite [7]. Both tasks could benefit from additional analyses and changes in their workflow earlier in the project, as this may reduce the number of issues that arise during later project stages and propagate to other areas of the satellite [11,13].

Applying these findings to the S3NGT mission meant that the integration of the newly developed MWR (microwave radiometer) payload and its interfaces to the platform in terms of the power and data handling should be studied. The MWR was selected as an example payload from the three that would be on-board. The philosophy was to contribute to the creation of a “central source” for the MWR and its interacting platform units, as well as facilitate early interface coordination using the capabilities of CAMEO. On a higher level, the interface engineering methods explored in this study were also contextualized within the Airbus processes for interface engineering to understand the true end-to-end benefits of applying CAMEO during early project phases. Thus, this paper aims to develop new methods in CAMEO that can be used to improve systems engineering work and electrical interface engineering processes starting in a mission’s early phases.

3. Interface Engineering Process

3.1. Interface Coordination

Interface control through translating all the mission’s electrical architecture documents into a detailed CAMEO model was demonstrated. These documents included the satellite’s functional architecture, equipment specifications, interface requirements, and heritage designs that were needed to capture the full electrical architecture (Figure 2). Since there were many different interface types between the units, as well as connections between units within assemblies, it was decided to separate the architecture into distinct IBDs (internal body diagrams) instead of having the entire architecture in one IBD. This would increase clarity, and reduce the complexity of the model, as the architecture could be separated by interface type or by a specific subsystem and its associated interfaces.

The Telemetry and Telecommand (TMTC) units, comprised of the Payload Downlink unit and the TT and C unit were also separated into their own IBD (Figure 3). To validate the interfaces associated with the microwave radiometer, an additional architecture diagram was created. To do this, the radiometer design report was used as the information source. Within this IBD (Figure 4), it could be seen how the payload data flow through the satellite, and how the connected units interact with the radiometer. In this way, interfaces could be traced to ensure that the platform units will collect and distribute payload data as expected and have an overview of the payload integration into the platform. Approximately 1520 interfaces including redundancy and multiplicity were defined at this early phase.

3.2. EICD Generation

From this architectural model (Figure 3 and Figure 4), electrical interface control documents (EICDs) were automatically generated using a CAMEO Whitebox ICD Table (Figure 5). A heritage EICD document was referenced, and it was seen that normally, the information provided included the specific unit name, GDIR interface code, the connected unit, and a note on the purpose of the interface. Additional CAMEO capabilities for end-to-end interface control and tracking were also explored for applications on smaller satellite missions during architecture creation.

3.3. Iterative Process for Harness Database

Additional procedures surround the harness database creation, as the magnitude of interfaces for satellites of this size increases drastically; an EO satellite can have more than 5000 pin-to-pin connections that must be controlled. The EICD makes up one part of a labor intensive and time-consuming electrical interface engineering process.

The system design report and EICD are considered high-level documents that show the systems functional flows without much detail, while the connector bracket design and electrical data sheets contain the routing and physical connections, as well as the pin-to-pin data. From thorough and complete satellite design description, EICD, EDS and connector bracket definition documents, a satellite harness database with every pin-to-pin link and its wire type can be created (Phase C). The harness database-created process is as illustrated in Figure 6. The filling of this database is estimated to take about 1000 h of work. The transfer of information from documents into the harness database is the source of most errors in this process, with the most common being pin-to-pin errors when filling the database. This is where an MBSE approach can be utilized. The automatic generation of the EICD in CAMEO via the linking of the electrical architecture demonstrates that within the electrical interface engineering process, improved workflows are possible to reduce the effort and time spent. This process should be embedded in an overall MBSE methodology.

4. Results

For both larger satellites built by Airbus and smaller satellite missions, traditional EICD creation involves a high amount of effort to compile and harmonize all information, as documentation is taken from various sources. This is where an MBSE approach can be utilized. The automatic generation of the EICD in CAMEO via the linking of the electrical architecture demonstrates that within the electrical interface engineering process, improved workflows are possible to reduce the effort and time spent.

In this method, the EICD is genuinely a live document since it is directly linked to the electrical architecture and will automatically reflect the updated architectural connections created in all diagrams. Therefore, no manual updating of this document is needed. Additional uses of the EICD in processes outside of the interface design procedure also highlights its importance. The EICD is the input to create Failure Detection Isolation and Recovery (FDIR) and Failure Mode and Effects Analysis (FMEA) plans. Its delivery to a different engineering team, which is not involved in the interface engineering process, means that it is especially important for this document to be accurate and present the harmonized interface information as per the design intent.

4.1. Model Reusability

A substantial benefit to using MBSE methods of working is the reusability of models from project to project. However, since reuse scenarios are rarely a simple “copy and paste” scenario, a systematic and standardized procedure is required to maximize the reuse efficiency. The authors of [19] demonstrated that the application of a structured design reuse methodology, including reuse-specific constructs and model elements in SysML, may result in a 15% improvement in system engineering effort.

In the context of this research, model reusability means reusing the CAMEO models for the units created to build the electrical architecture, with all their interfaces and ports. Adding models to a central database accessible to all projects allows for other missions to reuse these units for their own architectures. For example, since the S3NGT mission is a typical EO mission, there will be numerous commonalities with models for other EO missions. Creating a starting point for typical mission types where model elements can be reused, and tailored to the mission if need be, will also reduce the required time to produce a full MBSE model in CAMEO. For EO missions, telecommunications missions, and next generation missions from heritage missions, the reuse capabilities are quite high. This proposed modular model-based interface engineering process, using Airbus AstroBus equipment as an example, is demonstrated in Figure 7.

4.2. System Visualization

An additional benefit of reusability on a system level in the early stages of the satellite design is the compatibility visualization. Using the CAMEO model to see unit compatibility in early design phases enables both a visual and interface-based trade-off between any components modeled in the CAMEO database. Visually, there is typically only a summary of functional connections (shown in the design report) available in the early mission phases (A/B1) that describe the electrical architecture. This diagram is limited, as it is only a high-level description of the system, and therefore has a low visibility of all the information needed to perform thorough trade-offs. The assessment of interface compatibility on a detailed level (mostly concerning the number of available interfaces on the main units and where all other units shall be connected) does not come until the B2/C/D phases of the mission, when the units have already been selected and designed for. The impacts of realizing interface incompatibilities increases in these phases: the work involved for the engineering team to reselect or redesign equipment can cause substantial cost, especially for expensive main units such as the RIU. Using the CAMEO model, the gap between high-level and detailed-level documentation can be bridged already at phase A/B1 by providing an intermediate level of visualization into the design process. An illustration of the concept of system visualization can be seen in Figure 8.

4.3. Harmonized Tool Landscape for Interface Engineering

As discussed in Section 3.3, the EICD is just one facet of the complex electrical interface engineering process at Airbus, the final output of which is a complete harness database that will be translated into hardware. In this context, performing all interface management activities in CAMEO is not the full solution, but part of it. Fully embedding CAMEO into the tool landscape to streamline both the EICD process and its interfaces to the other processes involved in interface engineering is an important step to applying an MBSE methodology to the full procedure. A fully realized MBSE approach in the electrical engineering process could be performed in two ways: a landscape of connected tools that exchange all the required information in compatible formats (Figure 9a), or a single tool that can fulfill all the functions and steps involved (Figure 9b).

This proposed tool landscape would require robust and reliable interfaces between all the tools and the central database of information, which is a difficult cohesion to achieve, especially between software from different providers. The implementation of this landscape would require less adjustment of the current Airbus electrical interface engineering methods, as the work is already separated out by functions and spread between various tools that are used within a specific procedure. Thus, the tool landscape presented in Figure 9a should be considered an evolution of the current tools into a more cohesive workflow with a central database driving its use.

The single tool workflow presented in Figure 9b has not yet been realized, as one single tool to perform all functionalities for end-to-end electrical interface engineering is not presently available at Airbus. Although a single tool would present an ideal MBSE workflow, this is practically much more difficult to realize. If software already exists for this purpose, intensive training would be required as the current workflow for electrical interface engineering would be entirely changed.

4.4. Cost vs. Benefit Analysis

As previously mentioned, the main success criteria for the systems engineering team to claim this study was beneficial included a reduction in the hourly efforts of the electrical interface engineering workflow. Accordingly, a comparative cost vs. benefit analysis was created. This analysis is presented comparatively to the traditional methods, as precise hourly rates for specific engineering tasks on previous missions are not available due to the interconnected nature of many different processes and the participation of multiple personnel. To present a comparative cost vs. benefit analysis of electrical engineering processes conducted with or without CAMEO, to varying degrees,

Table 2. Hourly estimation of effort comparing four different scenarios for EICD creation for main satellite units. Note that all hourly values were given as rough, order of magnitude estimates. Exact numbers cannot be given as EICD creation is conducted throughout multiple phases, with various tasks performed by different personnel. This chart should be used to comparatively understand the effort required for the different methods of EICD generation, particularly the difference in effort when CAMEO is used with or without reusable components, and when full CAMEO use is deployed.

EICD Creation Scenario	Estimated Time	Tasks Involved
1. EICD creation with traditional methods	>140 h Not including functional design	Compile the needed documents Spreadsheet creation of all connections for EICD
2a. EICD in CAMEO-Without previous CAMEO model-With functional architecture previously designed	120 h Not including functional design	Full electrical architecture creation: Create technical components and interfaces Create technical connections Output EICD
2b. EICD in CAMEO-With reusable CAMEO components-With functional architecture previously designed	60 h Not including functional design	Partial electrical architecture creation: Create technical connections Output EICD
3. Full CAMEO use for Electrical Engineering modeling-Electrical architecture designed and modeled fully in CAMEO-With reusable CAMEO components	total <95 h including functional design 20 h (functional architecture) 60 h (technical architecture) <15 h (EICD)	Design of high-level electrical architecture: create functional architecture and model it Create technical architecture Output EICD

compares the time involved in four scenarios for generating an EICD from CAMEO. The time taken in each scenario was estimated by two experts in electrical engineering, who were interviewed about the effort and time taken in their experience for the tasks required in electrical architecture creation on a satellite [18,20].

In the worst case, with the CAMEO model created from scratch, generating an EICD in CAMEO with the methods presented in this study will take 120 h, which is still less than the EICD created with traditional methods. In the best case, and the scenario that is recommended from this study, where all electrical engineering work is performed in CAMEO stemming from the functional architecture and based on pre-made models, all work that culminates in the generation of an EICD will take less than 95 h. In comparison to the traditional method, which involves 140 h of work to only produce an EICD and does not include the hours needed to create the functional architecture in a separate tool, build the more detailed architecture, and compile the documents needed for the EICD, this is a measurable benefit.

4.5. MBSE Shortfalls and Future Work

To continue the work of this study, further investigation to evolve the end-to-end electrical interface engineering process at Airbus is recommended. The CAMEO methodology for creating electrical architecture and EICDs should be continued into phases B2/C/D to understand the benefits and limitations of this method in a complete satellite mission.

On a larger, interdisciplinary scale, an interface between CAMEO and the tools used for other parts of satellite design should be studied. These areas could include, but are not limited to, functional verification, reliability, and RAMS (risk assessment method statement), where information about cross strapping and redundancies is needed, and AOCS, which already has an established tool landscape. The embedment of CAMEO processes into other areas of satellite development eliminates redundant information sources, removes silos between disciplines, and promotes a more holistic MBSE approach. This requires dedicated software engineers to work on the synthesis of robust interfaces both within the electrical interface engineering toolset and between the toolsets of other disciplines.

The following shortcomings of CAMEO were identified throughout the course of this study and must be addressed to advance MBSE evolution. Currently, intensive training is required for navigating the software and creating models. This is especially a barrier for full usage by the engineering team, who cannot dedicate the same amount of time and energy to CAMEO use as a student. A more user-friendly interface for engineers without software or SysML experience should be explored. Such an interface would use intuitive commands, perhaps in a standardized toolbar, and set up the program to mimic other software that is more familiar to engineers (such as SolidWorks and Matlab).

Additionally, the CAMEO interface to the tool landscape has not yet been fully realized. Proper connection to the other tools, such as what has been established with DOORS in this study, will be required so that EICD automation and electrical architecture in CAMEO can be further developed into the required level of detail for hardware production. The reusability aspect of this study was also considered to be a valuable contribution that requires additional work to realize its full benefits. To do this, CAMEO models of all AstroBus equipment and variants should be created with accessibility for all AstroBus platform projects.

Obviously, the full adoption of a model-based way of working would require a large investment in training and a cohesive toolset in the future. Although this case study proposes one application where MBSE can provide an hourly reduction in effort, to realize the full extent of the benefits of this way of working, many gaps remain that should be studied before a definitive conclusion about the efficiency of MBSE vs. traditional engineering work can be made.

5. Conclusions

In summary, the following benefits were seen in this study, which align with the generally perceived MBSE benefits:

• There is a reduction in electrical engineering effort through the automation of electrical interface engineering procedures and documents. For this study, an improvement from 140 h using traditional methods to 120 h (without previous model) or even 60 h (with reusable components) could be estimated for the EICD creation, where the creation time for the functional model was not included. This aligns with the findings from [19], where a structured model reuse effort improved the system engineering effort to 15%.
• There is a practical company implementation of study methods through integrating MBSE methodologies into the company tool landscape.
• There is a reduction in system engineering effort through the reuse of models to modularly create similar satellite systems for efficient concept evaluation and comparison. The ability to efficiently create comparable concepts and versions also improves the communications among different stakeholders.
• There is efficient access to unit information and heritage architectures by using tools, e.g., CAMEO as a central source for equipment across projects. This also increases consistency among concepts and reused systems.

It was assessed that applying MBSE in CAMEO measurably reduces the time and effort involved in the electrical interface engineering process for a satellite system.

The automatic generation and live updating of EICDs from the evolving electrical design is one example of how connecting previously distinct workflows with an MBSE tool can improve efficiency when it is adopted from the early stages of a project, which had not yet been published in the literature or seen in the industry before this point. The demonstrated EICD procedure in CAMEO should be expanded into the end-to-end electrical interface engineering workflow to evolve it into a fully model-based process. This should be conducted by interfacing CAMEO with the other electrical interface design tools or by using one tool with all functionalities combined. The proposed interface engineering process illustrated in this study also satisfies the need within the European space landscape to connect MBSE processes with downstream engineering activities on satellite missions.

Furthermore, the ability to use CAMEO models for equipment between projects reduces rework, allows for engineering continuity, and is especially relevant for the standard Airbus product line for Earth observation satellites. CAMEO reuse for standard Airbus equipment and variants provides the ability to modularly create similar satellite systems. It also has the benefit of giving engineers efficient access to unit information and heritage architectures by using CAMEO as a central source for equipment across projects. Multidisciplinary unit models that extend beyond the electrical interfaces should be explored to further enable modular satellite design and early-stage compatibility assessments.

These conclusions support the claim that a transition to MBSE methods and the use of unified tools will add value when they are applied in the early phases of an earth observation mission.