Checkliste zur Validierung von UML-Zeitdiagrammen in sicherheitskritischen Echtzeitprojekten

Im Bereich sicherheitskritischer Echtzeitsysteme ist Präzision nicht nur eine Präferenz, sondern eine Überlebensvoraussetzung. Ob bei der Entwicklung von Steuergeräten für Kraftfahrzeuge, medizinischen Geräten oder Luft- und Raumfahrtavionik: Die Vorhersagbarkeit des Systemverhaltens bestimmt das Sicherheitsintegritätsniveau. UML-Zeitdiagramme dienen als kritisches Artefakt in diesem Ökosystem und visualisieren die zeitlichen Beziehungen zwischen Ereignissen, Signalen und Objekt-Lebenslinien. Ein Diagramm, das optisch korrekt erscheint, kann jedoch die für die Zertifizierung erforderlichen strengen Anforderungen nicht erfassen.

Dieser Leitfaden bietet einen umfassenden Rahmen zur Validierung von UML-Zeitdiagrammen in sicherheitskritischen Kontexten. Wir konzentrieren uns auf strukturelle Integrität, zeitliche Genauigkeit und Rückverfolgbarkeit, ohne auf spezifische kommerzielle Tools zu setzen. Ziel ist es sicherzustellen, dass das Modell die physische Realität der Hardware- und Software-Ausführungsumgebung präzise widerspiegelt.

📋 Warum Validierung in sicherheitskritischen Umgebungen von Bedeutung ist

Sicherheitsstandards wie ISO 26262 für Kraftfahrzeuge und IEC 61508 für Industriesysteme verlangen strenge Verifizierungsprozesse. Zeitdiagramme werden häufig verwendet, um Worst-Case-Ausführungszeiten (WCET), Interrupt-Latenzen und Kommunikationsfristen zu definieren. Wenn ein Zeitdiagramm fehlerhaft ist, wird die nachfolgende Codegenerierung oder Simulation unzutreffend sein, was potenziell zu Systemausfällen führen kann, die Benutzer oder die Umwelt gefährden könnten.

Validierung unterscheidet sich von Verifizierung. Verifizierung fragt: „Bauen wir das Produkt richtig?“ (Prüfung gegen das Design). Validierung fragt: „Bauen wir das richtige Produkt?“ (Prüfung gegen Benutzeranforderungen und Sicherheitsvorgaben). Im Kontext von Zeitdiagrammen stellt die Validierung sicher, dass die modellierten zeitlichen Einschränkungen tatsächlich mit den physikalischen Fähigkeiten des Prozessors und des Kommunikationsbusses übereinstimmen.

🔍 Phase 1: Vorbereitung vor der Validierung

Bevor das Diagramm selbst geprüft wird, muss der grundlegende Kontext festgelegt werden. Ein Zeitdiagramm kann nicht im luftleeren Raum existieren; es stützt sich auf das in Zustandsautomaten definierte Verhalten und das in der Systemarchitektur festgelegte Zeitbudget.

• Anforderungsabgleich:Stellen Sie sicher, dass jede Einschränkung im Diagramm einer spezifischen Sicherheitsanforderung zugeordnet ist. Es dürfen keine nicht rückverfolgbaren zeitlichen Einschränkungen existieren.
• Kontextdefinition:Definieren Sie den Umfang des Diagramms. Handelt es sich um eine einzelne Funktion, ein Teilsystem oder das gesamte System? Klarheit verhindert Scope Creep und Mehrdeutigkeiten.
• Zeitreferenzrahmen:Bestätigen Sie, ob die Zeit absolut (Uhrzeit) oder relativ (seit dem Auslöser) ist. Die Vermischung ohne explizite Markierungen führt zu Berechnungsfehlern.
• Ausführungsumgebung:Dokumentieren Sie die angenommene Prozessor-Geschwindigkeit, Taktzyklen und Interrupt-Prioritäten. Das Diagramm muss die spezifische Hardware-Konfiguration widerspiegeln.

🏗️ Phase 2: Strukturalvalidierung

Die Struktur eines UML-Zeitdiagramms bestimmt, wie Objekte über die Zeit interagieren. Strukturelle Fehler führen häufig zu logischen Deadlocks oder Race Conditions, die während des Tests schwer zu erkennen sind.

2.1 Objekt-Lebenslinien und Instanznamen

• Einzigartigkeit:Jede Lebenslinie muss eine eindeutige Kennung haben. Duplizierte Namen können Rückverfolgungstools verwirren.
• Konsistenz:Stellen Sie sicher, dass die Namen exakt mit der Dokumentation der Systemarchitektur übereinstimmen. Wenn die Architektur es „Sensor_Module“ nennt, darf das Diagramm nicht „Sensor“ verwenden.
• Aktivierungsstriche:Überprüfen Sie, ob die Aktivierungsstriche (Rechtecke auf Lebenslinien) den Zeitraum der Steuerung korrekt darstellen. Sie sollten beginnen, wenn eine Operation aufgerufen wird, und enden, wenn die Operation zurückkehrt oder das Signal gesendet wird.
• Zerstörungsereignisse:Wenn ein Objekt zerstört wird, stellen Sie sicher, dass das „X“-Symbol korrekt platziert ist. Eine vorzeitige Zerstörung kann zu Nullzeiger-Ausnahmen im generierten Code führen.

2.2 Bereich und Parallelität

Echtzeitsysteme verarbeiten häufig mehrere Aufgaben gleichzeitig. UML ermöglicht dies durch kombinierte Fragmente, insbesondere parallele Bereiche.

• Parallele Bereiche:Stellen Sie sicher, dass parallele Bereiche (gekennzeichnet mit „par”) die Hardware-Nebenläufigkeit korrekt abbilden. Stellen Sie sicher, dass die Parallelität der tatsächlichen Anzahl verfügbarer CPU-Kerne oder Interrupt-Kontexte entspricht.
• Interferenz:Prüfen Sie auf gemeinsam genutzte Ressourcen zwischen parallelen Bereichen. Wenn zwei parallele Prozesse denselben Speicheradressen ohne Synchronisation zugreifen, ist das Diagramm unsicher.
• Wachbedingungen:Wenn Wachbedingungen in Bereichen verwendet werden, stellen Sie sicher, dass sie logisch korrekt sind. Eine Wachbedingung, die immer wahr oder immer falsch ist, untergräbt den Zweck des bedingten Ablaufs.

⏱️ Phase 3: Zeitliche Validierung

Dies ist der Kern der Validierung von Zeitdiagrammen. Zeitliche Fehler sind die häufigste Ursache für Nichtdeterminismus in sicherheitskritischen Systemen.

3.1 Zeitliche Einschränkungen und Werte

• Maßeinheiten:Geben Sie die Zeiteinheit explizit an (ms, µs, Zyklen). Mehrdeutigkeit ist hier eine häufige Ursache für kritische Fehler.
• Bereich vs. Punkt:Sicherheitskritische Systeme erfordern oft Bereiche (Min/Max). Stellen Sie sicher, dass das Diagramm die Intervallschreibweise unterstützt und nicht feste Punkte, wo Variation möglich ist.
• WCET-Analyse:Jeder dargestellte Ausführungspfad muss eine dokumentierte Worst-Case-Ausführungszeit haben. Wenn ein Pfad nicht analysiert wurde, kann er nicht in einem zertifizierten Diagramm dargestellt werden.
• Jitter:Berücksichtigen Sie Jitter in der Kommunikation. Wenn ein Signal alle 10 ms erwartet wird, lassen Sie Toleranz zu. Das Diagramm sollte die maximal zulässige Abweichung widerspiegeln.

3.2 Einhaltung von Fristen

Einschränkungsart	Validierungsprüfung	Sicherheitsauswirkung
Harte Frist	Überprüfen Sie, ob das Signal vor Zeitpunkt T eintrifft.	Systemausfall / Funktionsverlust
Weiche Frist	Überprüfen Sie, ob das Signal mit minimaler Verschlechterung eintrifft.	Leistungsverschlechterung
Periodizität	Überprüfen Sie, ob wiederkehrende Intervalle konstant sind.	Zeitdrift / Oszillation
Latenz	Überprüfen Sie die Reaktionszeit vom Auslöser bis zur Aktion.	Instabiler Regelkreis

3.3 Zeit-Ausdrücke

• Komplexe Ausdrücke:Vermeiden Sie übermäßig komplexe mathematische Ausdrücke in Zeitbeschränkungen. Halten Sie sie einfach genug, um mathematisch verifiziert zu werden.
• Abhängigkeiten:Wenn eine Zeitbeschränkung von einem anderen Ereignis abhängt (z. B. „Zeit = T1 + T2″), stellen Sie sicher, dass die Abhängigkeitskette geschlossen und definiert ist.
• Überlauf:Stellen Sie sicher, dass Zeitwerte die Kapazität der zugrunde liegenden Datentypen (z. B. 32-Bit-Ganzzahlen) nicht überschreiten. Dies kann zu Wrap-Around-Fehlern führen.

📡 Phase 4: Nachrichtenfolge und Interaktionsvalidierung

Der Datenfluss bestimmt die Zustandsänderungen. Eine falsche Nachrichtenreihenfolge kann zu inkonsistenten Systemzuständen führen.

4.1 Synchrone vs. asynchrone Signale

• Pfeiltypen:Unterscheiden Sie klar zwischen durchgezogenen Pfeilen (synchrone Aufrufe) und gestrichelten Pfeilen (asynchrone Signale). Eine falsche Vermischung impliziert ein blockierendes Verhalten, wo keines existiert.
• Rückgabewerte:Bei synchronen Aufrufen muss das Rückgabesignal berücksichtigt werden. Ein fehlender Rückruf kann dazu führen, dass der Aufrufer unendlich hängt.
• Fire-and-Forget (Absenden ohne Warten):Bei asynchronen Signalen muss bestätigt werden, dass der Sender nicht auf eine Antwort wartet. Dies ist entscheidend für nicht-blockierende Echtzeitaufgaben.

4.2 Verlorene oder duplizierte Signale

• Kommunikationsmedium:Modellieren Sie das Kommunikationsmedium (Bus, Netzwerk, Interrupt). Berücksichtigt das Diagramm den Nachrichtenverlust?
• Zeitüberschreitungen:Wenn ein Signal möglicherweise nicht ankommt, ist ein Zeitüberschreitungsmechanismus modelliert? Ein fehlender Timeout ist eine häufige Fehlerursache in sicherheitskritischen Systemen.
• Wiederholungssendung:Bei kritischen Nachrichten muss überprüft werden, ob die Wiederholungssendelogik im Diagramm dargestellt ist, falls das Protokoll dies erfordert.

⚠️ Phase 5: Ausnahmebehandlung und Fehlerzustände

Der normale Betrieb ist nur ein Teil der Geschichte. Sicherheitskritische Systeme müssen Ausfälle angemessen handhaben.

• Ausnahmepfade:Jede Operation sollte einen zugehörigen Ausnahmepfad haben. Wenn eine Funktion fehlschlägt, was passiert dann mit der Zeitplanung?
• Wiederherstellungszeit:Modellieren Sie die Zeit, die für die Wiederherstellung nach einem Fehler erforderlich ist. Dies erhöht das gesamte Latenzbudget.
• Fail-Safe-Zustände:Stellen Sie sicher, dass das Diagramm zeigt, wie das System in einen sicheren Zustand übergeht (z. B. das Stoppen eines Motors), wenn Zeitverletzungen auftreten.
• Watchdog-Timer:Überprüfen Sie, ob die Interaktion mit dem Watchdog-Timer dargestellt ist. Das System muss zurückgesetzt werden, wenn die Ausführung des Diagramms das Watchdog-Limit überschreitet.

🔗 Phase 6: Rückverfolgbarkeit & Dokumentation

Ein validiertes Diagramm ist nutzlos, wenn es nicht auf Anforderungen zurückverfolgt oder auf die Implementierung weiterverfolgt werden kann.

• Anforderungsverknüpfungen:Jede Zeitbeschränkung sollte mit einer Anforderungs-ID verknüpft sein. Dies ermöglicht es Prüfern, die Abdeckung zu verifizieren.
• Implementierungsabbildung:Stellen Sie sicher, dass das Diagramm den tatsächlichen Quellcode-Funktionen zugeordnet ist. Funktionsnamen im Diagramm sollten mit Code-Signaturen übereinstimmen.
• Versionskontrolle:Zeitdiagramme entwickeln sich weiter. Stellen Sie sicher, dass das Versioning verwaltet wird, um zu verhindern, dass ein veraltetes Modell für Produktionscode verwendet wird.
• Änderungsprotokolle:Dokumentieren Sie, warum eine Zeitbeschränkung geändert wurde. Lag dies an einer Hardwareänderung oder einer Anforderungsaktualisierung?

🛠️ Häufige Fallstricke, die vermieden werden sollten

Selbst erfahrene Ingenieure geraten beim Modellieren von Zeit in Fallen. Seien Sie wachsam gegenüber diesen häufigen Problemen.

• Ignorieren der Interrupt-Latenz:Gehen Sie davon aus, dass die CPU immer verfügbar ist. In der Realität können Interrupts die Aufgabenexecution um mehrere Mikrosekunden verzögern. Modellieren Sie den Interrupt-Overhead.
• Überoptimistische Zeitplanung:Verwenden Sie Best-Case-Szenarien anstelle von Worst-Case-Szenarien. Sicherheitsmargen müssen basierend auf den denkbar schlechtesten Bedingungen berechnet werden.
• Ignorieren von Datenabhängigkeiten:Zwei Aufgaben können parallel sein, aber wenn eine von Daten der anderen abhängt, sind sie effektiv sequenziell. Modellieren Sie Abhängigkeiten korrekt.
• Statisch vs. Dynamisch:Mischen Sie nicht die statische Zeitanalyse mit dynamischen Simulationsannahmen. Sie dienen unterschiedlichen Validierungszwecken.
• Menschliche Fehler bei manueller Eingabe:Bei manueller Eingabe von Werten sollte eine Peer-Review implementiert werden. Ein einziger Tippfehler in einem Zeitwert kann den Sicherheitsnachweis ungültig machen.

🔄 Kontinuierliche Validierungsstrategie

Validierung ist kein einmaliges Ereignis. Da sich das System weiterentwickelt, muss sich auch das Zeitdiagramm mit ihm weiterentwickeln.

• Regressionstests:Wenn sich Anforderungen ändern, führen Sie die Validierungsliste erneut für das aktualisierte Diagramm durch.
• Hardware-in-the-Loop:Vergleichen Sie die Vorhersagen des Diagramms mit der tatsächlichen Hardware-Leistung. Abweichungen müssen behoben werden.
• Regelmäßige Überprüfung:Planen Sie regelmäßige Überprüfungen der Zeitdiagramme ein, um sicherzustellen, dass sie weiterhin die aktuelle Systemarchitektur widerspiegeln.
• Automatisierte Prüfungen:Wenn die Modellierungsumgebung dies unterstützt, verwenden Sie Skripte, um Syntax und grundlegende Einschränkungen automatisch zu validieren.

📊 Zusammenfassung der Validierungsliste

Um ein robustes sicherheitskritisches Design sicherzustellen, verwenden Sie die folgende Zusammenfassung als schnelle Referenz während Ihres Überprüfungsprozesses.

• ✅ Kontext:Sind Geltungsbereich und Zeiteinheiten definiert?
• ✅ Struktur:Sind Lebenslinien und Aktivitätsbalken korrekt?
• ✅ Nebenläufigkeit:Sind parallele Bereiche hardwaregenau?
• ✅ Zeitplanung:Sind WCET und Jitter berücksichtigt?
• ✅ Fristen:Werden harte und weiche Fristen unterschieden?
• ✅ Signale:Sind synchrone und asynchrone Signale klar definiert?
• ✅ Ausnahmen:Sind Fehlerpfade und Zeitüberschreitungen modelliert?
• ✅ Nachverfolgbarkeit:Sind Anforderungen an Randbedingungen gekoppelt?
• ✅ Überprüfung:Wurde das Diagramm einer Peer-Review unterzogen?

Die Einhaltung dieser umfassenden Checkliste stellt sicher, dass Ihre UML-Zeitdiagramme nicht nur grafische Darstellungen sind, sondern zuverlässige Baupläne für sichere, deterministische Echtzeitsysteme. Durch die strenge Validierung jedes Elements reduzieren Sie das Risiko von Laufzeitfehlern und bringen Ihr Design mit den höchsten Sicherheitsstandards in Einklang.

Denken Sie daran, dass das Diagramm eine Vereinbarung zwischen dem Entwurf und der Implementierung ist. Wenn die Vereinbarung fehlerhaft ist, wird auch die Ausführung fehlerhaft sein. Widmen Sie dieser Validierungsphase die erforderliche Zeit und Ressourcen, da sie das Fundament der Systemzuverlässigkeit bildet.