Embedded Software & Rhapsody

Das Wichtigste in Kürze

Warum entwickelt man Software mit Modellen statt nur mit Quellcode?

Quellcode beschreibt, wie ein System technisch umgesetzt ist. Bei Embedded Software reicht diese Sicht in vielen Projekten nicht aus, weil das eigentliche Verhalten über Zustände, Ereignisse, Zeitbedingungen, Schnittstellen und Reaktionen verteilt ist. Ein Steuergerät reagiert zum Beispiel nicht nur auf einzelne Eingaben, sondern befindet sich in Betriebszuständen, wechselt zwischen Modi, verarbeitet Fehlersituationen und kommuniziert mit anderen Komponenten. Wenn diese Zusammenhänge nur im Quellcode stehen, entstehen schnell Abhängigkeiten, die schwer zu überblicken sind.

Modelle machen diese Zusammenhänge explizit. Zustandsautomaten zeigen, welche Zustände ein System einnehmen kann, welche Ereignisse Zustandswechsel auslösen und welche Aktionen dabei ausgeführt werden. Ablaufmodelle beschreiben, in welcher Reihenfolge Funktionen, Prüfungen oder Kommunikationsschritte stattfinden. Schnittstellenmodelle legen fest, welche Signale, Datenstrukturen oder Aufrufe zwischen Komponenten ausgetauscht werden. Dadurch entsteht eine Ebene, auf der Fachlogik, Softwarearchitektur und Implementierung miteinander abgeglichen werden können.

In Projekten mit Rhapsody geht es daher nicht darum, Quellcode zu ersetzen, sondern ihn mit einer präzisen Beschreibung des Softwareverhaltens zu verbinden. Das Modell kann als Ausgangspunkt für die Implementierung dienen, etwa wenn daraus Code erzeugt wird. Es kann auch als Analysewerkzeug eingesetzt werden, wenn bestehende Software verstanden, dokumentiert oder umstrukturiert werden soll. In beiden Fällen hilft die Modellierung dabei, Annahmen sichtbar zu machen: Welche Zustände existieren? Welche Übergänge sind erlaubt? Was passiert bei ungültigen Eingaben? Welche Schnittstelle besitzt die Verantwortung für eine bestimmte Reaktion?

Für PICKPLACE ist diese Arbeitsweise besonders dann nützlich, wenn ein Projekt nicht nur aus Programmierung besteht, sondern zunächst eine fachliche und technische Klärung benötigt. Dazu gehören Fragen nach der Aufteilung von Funktionen, nach Abhängigkeiten zwischen Softwaremodulen, nach Timing-Vorgaben oder nach dem Umgang mit Fehlerfällen. Das Modell dient dabei als gemeinsame Arbeitsgrundlage für Entwicklung, Review, Test und Dokumentation.

Ein weiterer Grund für modellbasierte Entwicklung liegt in der Änderbarkeit. Embedded Software wird häufig über mehrere Entwicklungsstände hinweg angepasst. Neue Varianten, zusätzliche Signale, geänderte Sensorik oder andere Betriebsmodi verändern das Verhalten des Systems. Wenn das Verhalten in Modellen beschrieben ist, können Auswirkungen einer Änderung gezielter betrachtet werden. Ein geänderter Zustandsübergang, eine neue Bedingung oder eine zusätzliche Schnittstelle ist im Modell sichtbar und kann mit der Implementierung abgeglichen werden.

Wann ist Embedded Software & Rhapsody eine geeignete Kombination?

Rhapsody ist in Projekten sinnvoll, in denen Softwareverhalten nicht mehr zuverlässig durch einzelne Funktionen oder einfache Programmabläufe beschrieben werden kann. Das betrifft Steuergeräte und Maschinen, die mehrere Betriebsarten besitzen, auf Ereignisse reagieren, zeitliche Abläufe einhalten müssen oder verschiedene Schnittstellen gleichzeitig bedienen. Wenn ein System zwischen Start, Normalbetrieb, Diagnose, Fehlerzustand, Abschaltung und Servicefunktionen wechselt, eignet sich ein Zustandsmodell häufig besser als eine rein textuelle Beschreibung.

Bei Steuergeräten spielen Schnittstellen eine zentrale Rolle. Eingänge aus Sensoren, Kommunikationsdaten, Bedienereingaben und interne Statusinformationen beeinflussen die Ausgänge und Reaktionen des Systems. Rhapsody kann helfen, diese Beziehungen in Modellen abzubilden. Dabei wird geklärt, welche Komponente welche Daten verarbeitet, welche Ereignisse ausgelöst werden und welche Funktion auf welche Bedingung reagiert. Diese Klärung ist besonders nützlich, wenn mehrere Entwicklungsbeteiligte an unterschiedlichen Teilen der Software arbeiten.

Für Maschinen ist die Abbildung von Betriebsabläufen ein typischer Einsatzfall. Eine Maschine besitzt oft definierte Sequenzen: Initialisierung, Referenzfahrt, Freigaben, Prozessschritte, Stopps, Störungen und Wiederanlauf. Solche Abläufe lassen sich mit Zustandsautomaten oder Aktivitätsmodellen beschreiben. Das Modell zeigt dann, welche Bedingungen erfüllt sein müssen, bevor ein Schritt ausgeführt wird, und welche Reaktion bei Abbruch, Fehler oder Bedienereingriff erfolgt.

Rhapsody kann auch bei echtzeitnahen Systemen eingesetzt werden, wenn die Reihenfolge und Reaktionslogik der Software klar beschrieben werden muss. Dabei ersetzt das Modell nicht die technische Prüfung von Laufzeiten, Speicherbedarf oder Plattformverhalten. Es schafft jedoch eine Grundlage, um Reaktionen, Ereignisse und Verantwortlichkeiten zu ordnen. Auf dieser Basis kann anschließend geprüft werden, ob die vorgesehene Architektur zur Zielhardware, zum Betriebssystem, zu Kommunikationszyklen oder zu vorhandenen Softwarekomponenten passt.

Ein weiterer Projektkontext ist die Weiterentwicklung bestehender Software. In vielen Embedded-Projekten existiert bereits Quellcode, dessen Verhalten nur teilweise dokumentiert ist. Dann kann Reverse Engineering eingesetzt werden, um Strukturen und Abläufe aus dem vorhandenen Stand zu rekonstruieren. Das daraus entstehende Modell dient nicht als Selbstzweck, sondern als Arbeitsmittel: Es unterstützt die Bewertung, welche Teile der Software weiterverwendet werden können, wo Abhängigkeiten bestehen und welche Bereiche vor einer Erweiterung bereinigt werden sollten.

Rhapsody ist weniger hilfreich, wenn ein System sehr klein ist, kaum Zustände besitzt oder die Anforderungen bereits mit geringem Aufwand direkt im Code nachvollziehbar sind. Auch bei Projekten, in denen keine Pflege der Modelle vorgesehen ist, muss der Einsatz abgewogen werden. Ein Modell erzeugt nur dann Nutzen, wenn es mit Architektur, Code und Dokumentation verbunden bleibt. PICKPLACE betrachtet deshalb nicht nur das Werkzeug, sondern auch den Projektablauf: Wer pflegt das Modell? Wie werden Änderungen übernommen? Welche Modellteile dienen der Codegenerierung, welche der Dokumentation und welche der Analyse?

Wie kann modellbasierte Entwicklung Tests und Dokumentation unterstützen?

Tests benötigen eine klare Beschreibung des erwarteten Verhaltens. Modelle können diese Beschreibung liefern, weil sie Zustände, Übergänge, Bedingungen und Aktionen sichtbar machen. Aus einem Zustandsautomaten lässt sich ableiten, welche Betriebszustände getestet werden müssen, welche Ereignisse Zustandswechsel auslösen und welche Fälle zu Fehlerreaktionen führen. Damit wird die Testplanung konkreter als bei einer rein allgemeinen Anforderungsliste.

Für Embedded Software ist diese Verbindung zwischen Modell und Test besonders nützlich, weil viele Fehler erst in bestimmten Kombinationen auftreten. Ein System reagiert möglicherweise korrekt im Normalbetrieb, aber nicht nach einem vorherigen Fehlerzustand oder während eines Übergangs zwischen zwei Modi. Ein Modell hilft, solche Pfade zu identifizieren. Daraus entstehen Testfälle für erlaubte Zustandswechsel, nicht erlaubte Übergänge, Grenzbedingungen, Timeout-Situationen oder Reaktionen auf fehlende Eingangsdaten.

Auch Schnittstellen lassen sich aus Modellen besser prüfen. Wenn ein Modell beschreibt, welche Komponente welche Signale erwartet und welche Ausgänge daraus entstehen, können Testfälle die Datenflüsse gezielt abdecken. Bei kommunizierenden Komponenten kann geprüft werden, ob Nachrichten, Parameter oder Statusinformationen an der richtigen Stelle verarbeitet werden. Das Modell unterstützt damit sowohl Komponententests als auch Integrationstests.

Für die Dokumentation liefert modellbasierte Entwicklung eine technische Beschreibung, die näher an der Architektur liegt als ein nachträglich geschriebener Fließtext. Zustandsdiagramme, Ablaufmodelle und Schnittstellenübersichten zeigen, wie die Software aufgebaut ist und wie sie sich verhalten soll. Diese Dokumentation kann für Reviews, Übergaben, Wartung und Fehlersuche genutzt werden. Sie hilft auch neuen Projektbeteiligten, den Einstieg in bestehende Embedded Software zu verkürzen, weil zentrale Zusammenhänge nicht ausschließlich aus Quellcode gelesen werden müssen.

Rhapsody kann in diesem Zusammenhang als Werkzeug für Modell-Dokumentation dienen. Dabei geht es nicht nur um das Erstellen von Diagrammen, sondern um die konsistente Beschreibung von Softwarebausteinen, Beziehungen und Verhaltensregeln. Wenn Modelle gepflegt werden, können Änderungen an Zuständen, Schnittstellen oder Abläufen nachvollziehbar dokumentiert werden. Dadurch entsteht eine Verbindung zwischen Entwicklungsentscheidung, Modellstand und Implementierungsstand.

Bei der Codegenerierung kann das Modell zusätzlich Teil der Umsetzung werden. Dann ist zu klären, welche Modellteile direkt in Code überführt werden und welche manuell ergänzt werden. Diese Grenze muss im Projekt sauber festgelegt werden, damit erzeugter Code, handgeschriebener Code und Modell nicht auseinanderlaufen. Tests müssen anschließend auf dem tatsächlichen Zielsystem oder in einer geeigneten Testumgebung nachweisen, dass das implementierte Verhalten dem Modell entspricht.

Technische Einordnung von Forward und Reverse Engineering

In Rhapsody-Projekten treten häufig zwei Arbeitsrichtungen auf: Forward Engineering und Reverse Engineering. Beim Forward Engineering wird das Modell als Ausgangspunkt der Entwicklung verwendet. Architektur, Zustände, Schnittstellen und Abläufe werden modelliert und anschließend in Implementierung überführt. Je nach Projekt kann das teilweise über Codegenerierung erfolgen oder als Grundlage für manuell geschriebenen Code dienen.

Beim Reverse Engineering steht bestehender Quellcode im Mittelpunkt. Ziel ist es, vorhandene Strukturen zu verstehen und in Modelle zu überführen. Das ist besonders dann hilfreich, wenn Dokumentation fehlt, wenn Software über längere Zeit gewachsen ist oder wenn eine Migration vorbereitet werden soll. Das Modell zeigt dann, welche Abhängigkeiten im Code vorhanden sind, welche Komponenten miteinander gekoppelt sind und welche Bereiche vor einer Erweiterung genauer untersucht werden müssen.

Beide Richtungen können in einem Projekt kombiniert werden. Ein bestehender Softwarestand wird zunächst analysiert und modelliert. Anschließend werden neue Funktionen, geänderte Abläufe oder eine überarbeitete Architektur im Modell beschrieben und in die Implementierung übertragen. Dabei muss festgelegt werden, welche Elemente aus dem alten Stand übernommen werden, welche umgebaut werden und wo neue Schnittstellen entstehen.

Typisches Setup

• Modellierungstool IBM Rhapsody
• Requirements Tool IBM DOORS
• RTOS FreeRTOS
• IDE IAR Embedded Workbench
• Static Analysis Polyspace

Unsere Leistungen

PICKPLACE unterstützt Projekte rund um Embedded Software & Rhapsody bei der technischen Klärung, Modellierung und Vorbereitung der Umsetzung. Der Schwerpunkt liegt auf nachvollziehbaren Modellen, die Architektur, Verhalten, Schnittstellen und Implementierung miteinander verbinden.

Zu unseren Leistungen gehört die Aufsetzung von Forward Engineering. Dabei strukturieren wir gemeinsam mit dem Projekt die Modellbasis, beschreiben Softwarekomponenten, Zustände, Abläufe und Schnittstellen und klären, welche Modellteile für Codegenerierung oder Implementierung verwendet werden sollen. Wir achten darauf, dass Modellierungstiefe, Projektziel und vorhandene Entwicklungsumgebung zusammenpassen.

Beim Reverse Engineering analysieren wir bestehende Embedded Software und überführen relevante Strukturen in ein Modell. Dazu gehören Zustandslogik, Funktionsaufteilung, Datenflüsse und Schnittstellenbeziehungen. Das Ergebnis dient als Grundlage für Bewertung, Erweiterung, Redesign oder Dokumentation vorhandener Softwarestände.

Ein weiterer Leistungsbereich ist die Modell-Dokumentation. PICKPLACE erstellt und pflegt Modelle so, dass sie für Entwicklung, Review, Test und Übergabe verwendbar sind. Dazu gehören Zustandsdiagramme, Ablaufbeschreibungen, Schnittstellenübersichten und Architekturansichten, soweit sie für das konkrete Projekt benötigt werden.

In der Architekturentwicklung unterstützen wir bei der Aufteilung von Softwarefunktionen, bei der Definition von Komponentenverantwortlichkeiten und bei der Abstimmung zwischen Modell, Code und Zielsystem. Wir klären technische Abhängigkeiten, etwa zu Hardware, Betriebssystem, Kommunikationsschnittstellen oder bestehenden Softwaremodulen. Dadurch entsteht eine belastbare Grundlage für Implementierung, Testplanung und weitere Entwicklungsschritte.