Fallbeispiel SeaLion: Satellitenentwicklung mit Docs-as-Code

Die SysML v2 bringt eine Textnotation mit, die für viele Diskussionen sorgt. Das Team vom SeaLion-Projekt der Old Dominion University hat nicht geredet, sondern gemacht: Das Projekt ist ein gemeinsames CubeSat-Vorhaben mehrerer US-Universitäten. Ziel war es, den Entwicklungsprozess durch ein modellbasiertes, textbasiertes Dokumentationssystem (Docs-as-Code) effizienter und zugänglicher umzusetzen. Allerdings ohne SysML v2.

SeaLion

Auf SeaLion wurde ich über das kürzlich (2023) veröffentlichte Paper Model Based Systems Engineering with a Docs-as-Code Approach for the SeaLion CubeSat Project aufmerksam. Ziel von SeaLion war es, einen 3U-CubeSat mit drei verschiedenen wissenschaftlichen Nutzlasten zu entwickeln und ins All zu bringen. SeaLion sollte nicht nur Hardware fliegen, sondern auch neue Methoden der Systementwicklung erproben, insbesondere einen modellbasierten Docs-as-Code-Ansatz.

SeaLion hat drei von den Hochschulen beigesteuerte Nutzlasten:

• Impedanzsensor zur Plasmadiagnostik
• Multispektraler „Pixel Sensor“
• Ausfahrbare Kompositstruktur

Der Start von SeaLion ins All war ursprünglich für 2023 geplant, wurde aber leider mehrfach verschoben, Zuletzt im Herbst 2024. Eigentlich ist dieses Jahr ein Start vorgesehen, doch bei den aktuellen Budgetkürzungen bei NASA würde ich mich nicht wundern, wenn dieses Projekt auch erst einmal auf der Strecke bleibt.

Docs-as-Code

Der Docs-as-Code-Ansatz ist in der Softwarewelt längst etabliert: Entwickler pflegen Dokumentationen in Markdown, versionieren sie mit Git, und Continuous Integration (CI) sorgt für aktuelle Builds und Artefakte. Genau dieses Prinzip überträgt das SeaLion-Team auf Systemarchitektur und Dokumentation.

Dabei diente Mach 30 Modeling Language (M30ML) als Grundlage. M30ML basiert auf YAML und ist damit sowohl menschen als auch maschinenlesbar. Die gesamte Systemarchitektur wurde als Code gepflegt, von Anforderungen, Architektur, über User Stories bis hin zu Telemetrie-Datenstrukturen. Diagramme, Tabellen und PDFs wurden automatisch generiert.

Hier das Beispiel einer User Story, die als eigene YAML-Datei in gitHub verwaltet wird:

id: 4.1
name: Request Satellite Health Data
actor: Ground Station Operator 
behavior: request satellite health data packet
rationale: verify/validate AODS sensors & GPS data are within nominal parameters
derivedFrom:
- "2-UserStories/4-RequestTelemetryData.yaml"
example: Request satellite health data packet to verify or validate state vector corresponding to expected orbit profile based on pre-computed orbit propagation model

User Story Request Satellite Health Data in YAML (Quelle: gitHub)

Anwendungsfälle

Im Paper wurden die folgenden Anwedungsfälle angesprochen:

1. Stakeholder-Analyse und Anforderungserhebung: Anforderungen werden in YAML in Textdateien erfasst.
2. Traceability: Automatisiert generierte UML-Diagramme zeigen Abhängigkeiten zwischen Anforderungen, User Stories und Datenstrukturen.
3. Technische Dokumentation: Tabellen und Diagramme werden direkt aus den Modellen generiert, keine Redundanz.
4. Review- und Änderungsmanagement: Git Pull Requests ermöglichen kollaboratives Reviewen von Anforderungen und Architekturelementen.
5. Onboarding neuer Teammitglieder: Anwender können mit einem beliebigen Texteditor arbeiten und brauchen lediglich eine kurze Einführung in YAML

SysML v2 ist (noch) nicht genug

Das Team hat verschiedene Modellierungssprachen evaluiert, darunter auch SysML v2. Das Team entschied sich aus den folgenden Gründen dagegen:

• Kein Docs-as-Code: Auch wenn SysML v2 eine Textnotation unterstützt, ist nicht vorgesehen, Dateibasiert zu arbeiten. Damit wird das aus der Softwareentwicklung stammende Paradigma nicht wirklich gut unterstützt.
• Fehlende Werkzeuge: Die heute verfügbaren Werkzeuge wurden als zu schwergewichtig wahrgenommen. Allerdings hat sich seit 2023 eine Menge geändert.
• Zu kompliziert: Für dieses Projekt empfand das Team die SysML v2 für viel zu kompliziert. Auch wenn viele der Sprachfeatures ignoriert würden, so hätte sich daraus dennoch ein hoher Schulungsaufwand ergeben.

M30ML ist eine Erweiterung der LinkML-Spezifikation. Es ist leichtgewichtig, Git-kompatibel und YAML-basiert. Diese Sprache ist nicht nur für Systemingenieure gedacht, sondern gezielt so gestaltet, dass auch Nicht-Ingenieure produktiv damit arbeiten können.

Die M30ML erlaubt eine semantisch fundierte, aber zugängliche Modellierungssystematik. In SeaLion wurde das zusätzlich durch das „Distributed OSHW Framework (DOF)“ erweitert, das die Baugruppenstruktur des CubeSats abbildet. Dazu gehören auch Assembly-Anleitungen, Schnittstellen und Stücklisten.

Werkzeuge

Die eingesetzten Tools im SeaLion-Projekt sind bewusst einfach gehalten:

• Visual Studio Code: Der Editor der Wahl.
• YAML: Als Notationsformat für alle Architekturelemente.
• Jinja2 & Shell-Skripte: Zur automatischen Generierung von Dokumenten.
• Git/GitHub: Für Versionierung, Kollaboration und Review-Prozesse.
• PlantUML: Für automatische UML-Diagramme.
• asciidoctor / LaTeX: Für die Ausgabe in menschenlesbarer Form.

Für ein offenes Forschungsprojekt hatten diese Werkzeuge viele Vorteile. Alle sind kostenlos (die meisten auch quelloffen) und ermöglichen Arbeiten offline.

Schwächen

Die Autoren gehen zwar auch die Schwächen ein, doch meiner Meinung nach nicht stark genug. Leider ist erkennbar, dass zwar die akademischen, nicht aber industriellen Herausforderungen erkannt wurden.

• Hohe Abhängigkeit von Teamkommunikation: Wie so oft war die Kommunikation schwer, wobei primär die von gitHub vorgegebenen Möglichkeiten genutzt wurden, einschließlich Workflow-Features.
• Nachträgliches Modellieren kostet Zeit: Entscheidungen, die vor Einführung des Modells getroffen wurden, mussten aufwändig übertragen werden.
• Mangel an Schulungsmaterial: Neuen Mitgliedern die Einarbeitung schwer, da die Dokumentation minimal und teilweise unvollständig war.
• Komplexität bei fortgeschrittenen Features: Die Modellierung von Komponenten und Schnittstellen erfordert zusätzliche Tools, die es zum Teil noch nicht gab.

Für den Einsatz in der industriellen Praxis sehe ich jedoch noch viel mehr Hürden:

• Skalierung: Das Projekt bestand aus ein paar Dutzend Artefakten, während industrielle Projekte mit Tausenden (oder Zehntausenden) von Artefakten jonglieren müssen
• Features & Usability: Um breite Akzeptanz zu erlangen, erwarten Anwender wichtige Features wie das Einbetten von Bildern in Anforderungen und nutzerfreundliche, zweckbestimmte Werkzeuge.
• Integration: In der aktuellen Werkzeugkette wird nur ein kleiner Teil des V-Modells abgedeckt, es fehlen PLM, Testintegration und vieles mehr.
• Rollen & Rechte: Die von gitHub im Rahmen dieses Konzept bereitgestellten Features reichen für ein industrielles Zugriffsmodell nicht aus.

Diese Probleme sind nicht unlösbar, allerdings nicht im Rahmen von Forschungsprojekten. Meiner Meinung nach sind Werkzeugherstellen in der besten Position dazu. In der Softwareentwicklung haben viele Unternehmen erfolgreiche Geschäftsmodelle auf Docs-as-Code aufgebaut, wie neben gitHub auch GitLab, Read the Docs, MkDocs oder Atlassian.

Fazit: Ein Anfang auf einem weiten Weg

SeaLion zeigt, dass Docs-as-Code auch im Systems Engineering möglich ist. Auch wenn unklar ist, wie weit dieser Ansatz für das industrielle Umfeld geeignet sein könnte, ist es hilfreiche, ein echtes Fallbeispiel zu haben.