OPS-SAT: Reverse engineering with MBSE at ESA

Modeling in the Systems Engineering has many advantages. However, if an organization does not yet have (much) experience in model-based system development (MBSE), this approach is risky. The European Space Agency (ESA) took an interesting intermediate route with OPS-SAT: The team developed the satellite traditionally, i.e. document-based. This approach is very mature at ESA. However, after the successful deployment of the satellite, ESA invested the time to create a model via reverse engineering, which is to form the basis for further follow-up projects.

Peter Gersing described this project in his keynote speech at MESCONF 2023.

OPS-SAT

With the OPS-SAT ESA is using a new approach for the construction of satellites. On the one hand, OPS-SAT relies on standard components. On the other hand, ESA relies on the CubeSat-format, a form factor based on cubes with an edge length of 10 cm. The satellite shown in the cover picture has a size of 10 x 10 x 40 cm.

After OPS-SAT was in orbit, ESA conducted a "lessons learned" analysis. Despite the very well-organized and structured documentation of its missions, the rapid development and the many OTS components led to major challenges in keeping the documentation consistent and up to date.

To better master these challenges in follow-up projects, ESA carried out a reverse engineering project. This was led by Peter Gersing, who works for GPP Communication works and MBSE-expertise.

If you want to know more, here is the Executive Summary Report: Application of MBSE to reverse-engineer OPS-SAT and improve OPS-SAT2

Why MBSE Reverse Engineering?

As part of a re-evaluation of its technology strategy, ESA examined the approaches and methods used in development, among other things. Model-based systems engineering was recognized as a promising approach. Initially, ESA identified the pain points in development that could be resolved with MBSE:

• Miscommunication
• Lack of functional analysis
• No automatic consideration of changes in requirements
• Inconsistent definitions and terminology
• No single source of truth ("Single Source of Truth")
• Missing/incomplete documentation
• Steep learning curve for new team members
• Lack of control over the configuration

The team expected the following from the use of MBSE:

• Clear communication with precise standardized language (e.g. SysML)
• Clear procedure thanks to standardized MBSE methodology
• Requirements and relationships are precisely captured in the model
• Structure and behavior are precisely captured in the model
• Diagrams are easier to read and are clear
• Software architecture and deployment are precisely captured in the model

ESA has a lot of experience with document-based systems engineering. Nevertheless, the existing documentation was very heterogeneous. There were of course diagrams, but these were images, not views of a model. Furthermore, many diagrams used different, often proprietary standards.

More on this topic can be found in the Executive Summary Report to find.

Modeling was only done selectively, if at all. Reuse was not really possible.

Reverse Engineering Process

The ESA team has created its own customized MBSE framework for this project. It is based on a grid, like many other MBSE approaches.

It is noticeable that no logical design is provided. This has proven itself at ESA and works particularly well for reverse engineering, as the physical design already exists.

It is also interesting that requirements are not broken down to the various levels. This had also not proved successful.

Modeling with Enterprise Architect

As a tool, the team has Enterprise Architect selected. The team recognized early on that many stakeholders would only want to examine or review the model. Therefore, there was an HTML export that the stakeholders could use for this purpose. Some screenshots can be seen in the Executive Summary Report.

For this project, the scope was limited to the actual satellite. Of course, the system context was created. This included Ground Station, Sun, Star, Earth and GNSS (positioning signal). However, the context elements themselves, such as ground control, were not modeled.

The work of reverse engineering OPS-SAT took 2 years and was carried out by 2 people, which was perceived as fast by the participants.

Effort: 2 years, 2 persons

Conclusion

The team was satisfied with the result and sees the following three learning points:

• Reverse engineering is an excellent approach to implement MBSE and to gain a holistic understanding of the developed system
• Diagrams of the model enable quick reviews with the experts for maximum knowledge transfer
• Reusing the model provides a head start for the next mission and makes it possible to optimize instead of starting from scratch.

At the time of the keynote, it was not yet clear exactly how the follow-up project would proceed. The team has decided that there will be a separate OPS-SAT-2 model, which will be derived from the model created. However, it is also unclear whether the work will be completely model-based or whether the model will only be used selectively.

I will be following with interest how the OPS-SAT-2 team will use the model.

Image sources: ESA