Figure 10.11: Use case for Report Checkpoint

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use-Case-Diagramm) mit strukturellen Systemgrenzen (Adaptive Platform und Funktionscluster-Scope Platform Health Management).
• Technischer Zweck: Das Diagramm spezifiziert die architekturelle Rolle des Use Cases Report Checkpoint innerhalb des Clusters Platform Health Management (PHM). Es visualisiert normativ, dass nicht nur reguläre Anwendungsprozesse (Adaptive Application), sondern auch plattforminterne, prozessbasierte Systemdienste (Functional Clusters) als Supervised Entities agieren und Checkpoints an das PHM melden müssen, um eine durchgängige Alive-, Deadline- und Logical-Supervision nach ISO 26262 zu gewährleisten.

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenzen & Use Case:
  • Systemgrenze Adaptive Platform: Umfasst alle plattforminternen Dienste und Subsysteme.
  • Subsystem-Scope Platform Health Management: Kapselt die Überwachungs- und Auswertelogik für funktionale Sicherheit.
  • Kern-Entität: «aapUseCase» Report Checkpoint – Repräsentiert die funktionale Schnittstelle/Aktion zur Meldung von Kontroll- und Lebenszeichenpunkten.
• Akteure & funktionale Cluster:
  • Adaptive Application (from Actors): Externer Anwendungsakteur im User Space.
  • Plattform-Cluster («aapFunctionalCluster», jeweils typisiert als daemon-based):
    • Lifecycle & Core: Execution Management (EM), State Management (SM)
    • Diagnostics & Maintenance: Diagnostic Management (DM), Update and Configuration Management (UCM)
    • Security: Cryptography (Crypto), Intrusion Detection System Manager (IdsM)
    • Infrastructure & Com: Time Synchronization (TS), Communication Management (CM)
• Beziehungen & Stereotypen:
  • «aapTriggers»: Assoziation von Adaptive Application sowie von DM, UCM, EM, SM, TS, Crypto und CM auf den Use Case Report Checkpoint. Jeder dieser Akteure/Dienste stößt aktiv die Meldung von Checkpoints an.
  • «aapParticipates,aapTriggers»: Spezifische duale Assoziation zwischen Intrusion Detection System Manager (IdsM) und Report Checkpoint. Der IdsM fungiert primär als Trigger (Überwachung des IdsM-Daemons selbst) und partizipiert gleichzeitig funktional an der Auswertung von Anomalien bzw. Sicherheitsereignissen im Kontext von Plattform-Integritätsverletzungen.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung: Jeder überwachte Daemon-Prozess sowie die Adaptive Application initialisiert zur Laufzeit eine Instanz der SupervisedEntity über die C++-API von ara::phm.
2. Checkpoint-Trigger:
   • Erreichen eines definierten Programmzustands (z. B. Ende eines Rechenzyklus, erfolgreicher Empfang/Versand von PDUs in CM, Abschluss einer Krypto-Operation in Crypto).
   • Synchroner Aufruf der API-Methode (z. B. ara::phm::SupervisedEntity::ReportCheckpoint(CheckpointId)).
3. Transportpfad: Meldungsübergabe über latenzarme, lokale Inter-Process-Communication (IPC / Shared-Memory-Ringpuffer) an den PHM-Daemon.
4. PHM-Interne Verifikation:
   • Alive Supervision: Prüfung der Einhaltung von Meldefrequenzen innerhalb definierter Zeitfenster.
   • Deadline Supervision: Überprüfung minimaler/maximaler Übergangslaufzeiten zwischen zwei korrelierten Checkpoints.
   • Logical Supervision: Graphbasierte Validierung der Kontrollfluss-Reihenfolge (Transitionen).
5. Reaktion/Eskalation: Bei Verfehlen eines Checkpoints oder unzulässigem Pfad erfolgt keine direkte Behebung im Melder, sondern die Zustandsmeldung/Eskalation an State Management (SM) zur Einleitung von Recovery-Aktionen (z. B. Funktionsdegradierung, Fail-Safe-Zustand, Prozess-Neustart via EM).

4. Normative Relevanz & Entwickler-Hinweise

• Keine Ausnahme für Plattformdienste: Stack- und Plattform-Entwickler müssen interne Daemons (CM, DM, Crypto etc.) identisch zu Applikationen als überwachte Entitäten modellieren. Plattformdienste dürfen im Safety-Kontext keine unüberwachten Black-Boxes darstellen.
• Manifest-Modellierung (ARXML):
  • Jeder Checkpoint (PHMCheckpoint) und jede überwachte Entität (PHMSupervisedEntity) muss in den Manifesten (HealthChannel, SupervisedEntityInterface) explizit definiert und konfiguriert werden.
  • Für jeden Prozess müssen Überwachungsalgorithmen (Alive-, Deadline-, Logical-Supervision) verbindlich parametriert sein.
• API & Laufzeitverhalten:
  • Der API-Aufruf ReportCheckpoint muss zwingend nicht-blockierend und reentrant sein, um die Ausführung harter Echtzeit-Cluster (insbesondere Time Synchronization und Communication Management) nicht durch IPC-Jitter oder Mutex-Contention zu blockieren.
  • Entwickler müssen sicherstellen, dass Checkpoints an deterministischen Stellen im Kontrollfluss platziert werden; fehlerhaft bedingte Verzweigungen führen unweigerlich zu Logical-Supervision-Verletzungen.