Figure 10.15: Use case Report Checkpoint

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use Case Diagram) mit Kontextgrenzen (System Boundaries) und domänenspezifischen Stereotypen der AUTOSAR Adaptive Platform («aapUseCase», «aapFunctionalCluster», «aapTriggers», «aapParticipates,aapTriggers»).
• Technischer Zweck: Spezifikation der Interaktionsbeziehungen für den Anwendungsfall Report Checkpoint innerhalb des Functional Clusters Platform Health Management (PHM).
• Funktionale Einordnung: Definiert die Melderolle für Laufzeitüberwachungen (Alive Supervision, Deadline Supervision, Logical Supervision). Es verdeutlicht, dass die Integritätsüberwachung durch das PHM nicht auf Applikationsebene (Adaptive Application) beschränkt ist, sondern symmetrisch auch für alle zentralen, daemon-basierten Plattform-Cluster (Self-Supervision der Adaptive Platform) gilt.

2. Komponenten, Entitäten & Schnittstellen

• System- und Subsystemgrenzen:
  • Adaptive Platform: Umfasst alle plattforminternen Dienste sowie den Ziel-Use-Case.
  • Platform Health Management: Kapselt den Kern-Anwendungsfall «aapUseCase» Report Checkpoint.
• Akteure (Actors):
  • Adaptive Application (from Actors): Repräsentiert Standard-Anwenderprozesse im User Space außerhalb der Core-Plattform.
• Funktionale Cluster («aapFunctionalCluster», alle annotiert als daemon-based):
  • Diagnostic Management (DM)
  • Update and Configuration Management (UCM)
  • Execution Management (EM)
  • State Management (SM)
  • Intrusion Detection System Manager (IdsM)
  • Time Synchronization (TS)
  • Cryptography (Crypto)
  • Communication Management (CM)
• Beziehungen & Stereotypen:
  • «aapTriggers»: Unidirektionale Trigger-Beziehung. Sieben funktionale Cluster sowie die Adaptive Application initiieren aktiv das Melden eines Kontrollpunktes an den PHM-Use-Case.
  • «aapParticipates,aapTriggers»: Kombinierte Assoziation am Intrusion Detection System Manager. Der IdsM fungiert sowohl als auslösende Entität (Reporting eigener Checkpoints) als auch als partizipierende Entität (Schnittstelle zur Korrelation von Anomalien/Angriffsmustern mit Integritätsverletzungen des PHM).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering:
   • Ein überwachter Thread (innerhalb einer Adaptive Application oder eines Plattform-Daemons) erreicht einen instrumentierten Programm- bzw. Kontrollflussknoten.
2. API-Aufruf & IPC-Transport:
   • Der Thread ruft synchron die lokale C++ API auf: ara::phm::SupervisedEntity::ReportCheckpoint(CheckpointId).
   • Die Meldung wird über einen optimierten, nicht-blockierenden IPC-Kanal (Shared Memory, Unix Domain Sockets oder FIFO) an den zentralen PHM-Daemon übermittelt.
3. PHM-Laufzeitauswertung:
   • Alive Supervision: Inkrementierung des Zählers im laufenden Überwachungsfenster (Soll-Bereich für Ausführungsfrequenz).
   • Deadline Supervision: Validierung des Zeitdifferenzintervalls zwischen zwei definierten Checkpoints gegen minimale und maximale Latenzschwellen (minDeadline, maxDeadline).
   • Logical Supervision: Prüfung auf deterministische Einhaltung des modellierten Zustandsübergangsgraphen (Erkennung unzulässiger Programmsprünge).
4. Fehlerbehandlung / Eskalation:
   • Bei Regelverletzung determiniert das PHM einen fehlerhaften Gesundheitsstatus (Health Channel / Local Supervision Status).
   • Eskalation an State Management (Trigger für Fallback-Betriebszustände) bzw. an Execution Management (Prozess-Neustart oder Recovery-Aktionen) sowie Logging/Security-Audit via DM / IdsM.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::phm):
  • Implementierende Prozesse müssen gegen die ara::phm-Bibliothek linken und mindestens eine Instanz von ara::phm::SupervisedEntity instanziieren.
  • ReportCheckpoint-Aufrufe müssen deterministisch, seiteneffektfrei und echtzeitfähig sein; Blockaden im überwachten Prozess durch IPC-Jitter sind durch Implementierung lock-freier Übertragungsstrukturen auszuschließen.
• Plattform-Design (Daemon-Symmetrie):
  • Entwickler von Platform Services (DM, SM, UCM etc.) müssen ihre Daemons als reguläre Supervised Entities im ARXML-Manifest deklarieren, um die ASIL-Einstufung durch gegenseitige Überwachung sicherzustellen.
• ARXML-Modellierung & Manifeste:
  • Jede im Code verwendete CheckpointId muss exakt im Execution Manifest (PHMSupervisedEntityInterface, PHMCheckpoint) typisiert und mit den Überwachungsregeln (AliveSupervision, DeadlineSupervision, LogicalSupervision) verknüpft sein.
• Sicherheitskopplung (IdsM):
  • Die gesonderte Rolle «aapParticipates,aapTriggers» beim IdsM erfordert bei sicherheitskritischen ECUs eine Verknüpfung von PHM-Anomalien (z. B. Manipulationsversuche durch falsche Kontrollflussübergänge) mit Security Events (ara::idsm).