OPS-SAT: Reverse Engineering mit MBSE bei ESA

Modellierung im Systems Engineering hat viele Vorteile. Doch wenn eine Organisation noch nicht (viel) Erfahrung in der modellbasierten Systementwicklung (MBSE) hat, dann ist dieses Vorgehen riskant. Die European Space Agency (ESA) hat beim OPS-SAT einen interessanten Zwischenweg gewählt: Das Team entwickelte den Satellit traditionell, also dokumentenbasiert. Dieses Vorgehen ist bei ESA sehr ausgereift. Doch nach dem erfolgreichen Deployment des Satelliten investierte ESA die Zeit, über Reverse Engineering ein Modell zu erstellen, welches die Basis für weitere Nachfolgeprojekte sein soll.

Peter Gersing beschrieb dieses Projekt in seiner Keynote der MESCONF 2023.

OPS-SAT

Mit dem OPS-SAT setzt ESA einen neuen Ansatz für den Bau von Satelliten ein. Zum einen setzt OPS-SAT auf Standardkomponenten. Zum anderen setzt ESA auf das CubeSat-Format, einem Formfaktor, der auf Würfeln mit einer Kantenlänge von 10 cm basiert. Der im Titelbild abgebildete Satellit hat eine Größe von 10 x 10 x 40 cm.

Nachdem OPS-SAT in der Umlaufbahn war, hat die ESA eine „Lessons Learned“-Analyse durchgeführt. Trotz der sehr gut organisierten und strukturierten Dokumentation ihrer Missionen führten die schnelle Entwicklung und die vielen OTS-Komponenten zu großen Herausforderungen, um die Dokumentation konsistent und auf dem neuesten Stand zu halten.

Um diese Herausforderungen in Nachfolgeprojekten besser zu meistern, führte ESA ein Reverse-Engineering-Projekt durch. Dies wurde von Peter Gersing geleitet, der für GPP Communication arbeitet und MBSE-Expertise beisteuerte.

Wer mehr wissen will, hier ist der Executive Summary Report: Application of MBSE to reverse-engineer OPS-SAT and improve OPS-SAT2

Warum MBSE Reverse Engineering?

Im Rahmen einer Reevaluierung ihrer Technologiestrategie untersuchte ESA unter anderem die Ansätze und Methoden in der Entwicklung. Modellbasiertes Systems Engineering wurde dabei als ein vielversprechender Weg erkannt. Zunächst hatte ESA die Schmerzpunkte in der Entwicklung identifiziert, die mit MBSE aufgelöst werden könnten:

• Miskommunikation
• Fehlende funktionale Analyse
• Keine automatische Berücksichtigung von Änderungen in Anforderungen
• Inkonsistente Definitionen und Begrifflichkeiten
• Keine einzige Wahrheitsquelle („Single Source of Truth“)
• Fehlende/unvollständige Dokumentation
• Steile Lernkurve für neue Teammitglieder
• Fehlende Kontrolle über die Konfiguration

Vom Einsatz von MBSE versprach sich das Team folgendes:

• Klare Kommunikation mit präziser standardisierten Sprache (bspw. SysML)
• Klares Vorgehen dank standardisierter MBSE-Methodik
• Anforderungen und Beziehungen werden präzise im Modell erfasst
• Struktur und Verhalten werden präzise im Modell erfasst
• Diagramme sind leichter zu lesen und sind eindeutig
• Software Architektur und Deployment werden präzise im Modell erfassts

Zwar hat ESA viel Erfahrung mit dokumentenbasierten Systems Engineering. Dennoch war die bestehende Dokumentation sehr heterogen. Es gab natürlich Diagramme, doch dies waren Bilder, keine Sichten auf ein Modell. Weiterhin verwendeten viele Diagramme unterschiedliche, oft eigene Standards.

Mehr zu diesem Thema ist im Executive Summary Report zu finden.

Modelliert wurde, wenn überhaupt, nur punktuell. Wiederverwendung war nicht wirklich möglich.

Reverse Engineering Process

Das ESA-Team hat ein eigenes, angepasstes MBSE Framework für diese Projekt erstellt. Es basiert auf einem Raster, wie viele andere andere MBSE-Ansätze auch.

Auffällig ist, dass kein logisches Design vorgesehen ist. Dies hat sich bei ESA bewährt und funktioniert besonders gut beim Reverse-Engineering, da das physikalische Design ja bereits existiert.

Auch interessant ist, dass Requirements nicht auf die verschiedenen Ebenen heruntergebrochen werden. Auch das hatte sich nicht bewährt.

Modellierung mit Enterprise Architect

Als Werkzeug hat das Team Enterprise Architect ausgewählt. Das Team hat frühzeitig erkannt, dass viele Stakeholder das Modell nur begutachten oder reviewen wollen. Daher gab es einen HTML-Export, welches die Stakeholder dazu nutzen konnten. Im Executive Summary Report sind einige Screenshots zu sehen.

Für dieses Projekt beschränkte sich der Scope auf den eigentlichen Satelliten. Natürlich wurde der Systemkontext erstellt. Dieser enthielt Ground Station, Sun, Star, Earth und GNSS (Positionierungssignal). Doch die Kontextelemente selbst,wie bspw. die Bodenkontrolle, wurden nicht modelliert.

Die Arbeit des Reverse Engineering von OPS-SAT hat 2 Jahre gedauert und wurde von 2 Personen durchgeführt, was von den Teilnehmern als schnell wahrgenommen wurde.

Aufwand: 2 Jahre, 2 Personen

Fazit

Das Team war zufrieden mit dem Ergebnis und sieht die folgenden drei Lernpunkte:

• Reverse Engineering ist ein hervorragender Ansatz um MBSE einzuführen, und um ein ganzheitliches Verständnis vom entwickelten System zu gewinnen
• Diagramme des Modells ermöglichen schnelle Reviews mit den Experten für einen maximalen Wissenstransfer
• Wiederverwendung des Modells stellt einen Vorsprung für die nächste Mission dar und ermöglicht es, zu optimieren, statt von ganz vorne anzufangen.

Zum Zeitpunkt der Keynote war noch nicht genau klar, wie das Vorgehen beim Nachfolgeprojekt aussehen soll. Das Team hat entschieden, dass es ein separates OPS-SAT-2-Modell geben soll, welches aus dem erstellten Modell abgeleitet wird. Doch darüber hinaus ist unklar, ob vollständig modellbasiert gearbeitet werden wird oder ob das Modell lediglich punktuell herangezogen wird.

Ich werde mit Spannung verfolgen, wie das OPS-SAT-2-Team das Modell nutzen wird.

Bildquellen: ESA