Figure 9.71: Users of the SupervisedEntity interface

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Architekturmodell).
• Technischer Zweck: Spezifikation der architektonischen Abhängigkeiten zwischen zentralen daemon-basierten Functional Clustern (FC) der Adaptive Platform Core Services und dem Functional Cluster Platform Health Management (PHM) über das Interface SupervisedEntity.
• Funktionale Einordnung: PHM überwacht die korrekte zeitliche und logische Ausführung kritischer Plattform-Daemons (Alive-, Deadline- und Logical Supervision). Das Diagramm visualisiert, dass nicht nur reguläre Adaptive Applications (AAs), sondern die fundamentalen System-Daemons selbst als Supervised Entities agieren und Checkpoints an PHM melden.

2. Komponenten, Entitäten & Schnittstellen

• Schnittstelle (Interface / Port):
  • «aapAPI,aapPortInterface» SupervisedEntity: Abstrahiert eine zu überwachende Entität.
    • Operation: + ReportCheckpoint() zur zyklischen oder ereignisdiskreten Übermittlung von Checkpoint-IDs an das PHM.
• Bereitstellende Komponente (Provider / Realization):
  • «aapFunctionalCluster» Platform Health Management (daemon-based): Realisiert das Interface (gekennzeichnet durch die gestrichelte Realisierungsbeziehung mit geschlossenem, nicht ausgefülltem Pfeil). Der PHM-Daemon nimmt Checkpoints entgegen und bewertet Transitions- sowie Timing-Bedingungen.
• Nutzende Komponenten (Consumers / Clients):
  • Alle Clients sind mit dem Stereotyp «aapFunctionalCluster» versehen, arbeiten daemon-based und nutzen die Schnittstelle über eine Abhängigkeit («use», «aapRequiredPort»):
    1. State Management (SM): Koordiniert Zustände und Funktionsgruppen (Function Groups).
    2. Execution Management (EM): Startet, stoppt und überwacht OS-Prozesse.
    3. Diagnostic Management (DM): Behandelt UDS-/DoIP-Diagnosesitzungen und Fehlerspeicher.
    4. Update and Configuration Management (UCM): Steuert Software-Updates und Paketinstallationen.
    5. Cryptography (Crypto): Stellt kryptografische Basisfunktionen und Key-Storage bereit.
    6. Time Synchronization (TS): Synchronisiert Systemzeiten (z. B. via gPTP / IEEE 802.1AS).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung: Beim Hochfahren instanziiert jeder Daemon einen Port bzw. ein Interface-Binding für SupervisedEntity über die lokale PHM-Client-Bibliothek (Library-basierter IPC-Wrapper).
2. Checkpoint-Trigger: Im laufenden Betrieb erreicht ein Daemon deterministische Stellen in seinem Kontrollfluss (z. B. Beenden einer State-Transition in SM, Vollzug eines Prozessstarts in EM, Abarbeitung eines Diagnoserequests in DM oder Sync-Zyklus in TS).
3. Synchroner/Asynchroner Aufruf: Der Daemon setzt ReportCheckpoint(CheckpointId) ab. Der Aufruf wird über atomare Interprozesskommunikation (Shared Memory / atomare Ringpuffer / IPC-Sockets) an den PHM-Daemon transferiert.
4. Verarbeitung im PHM: PHM gleicht den Checkpoint mit dem hinterlegten Überwachungsmodell ab:
   • Alive Supervision: Zählung von Checkpoints innerhalb eines definierten Zeitfensters.
   • Deadline Supervision: Überprüfung der Min/Max-Laufzeit zwischen zwei definierten Checkpoints.
   • Logical Supervision: Validierung des Ausführungspfads anhand des konfigurierten Kontrollflussgraphen (Transition Ring).
5. Fehlerbehandlung: Bei Verletzung (Deadline-Überschreitung, unerlaubte Transition, Ausbleiben) löst PHM eine Recovery Action aus (z. B. Notification an SM, Request an EM zum Prozessneustart oder Triggerung des Hardware-Watchdogs via Platform Watchdog Driver).

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- und Threading-Restriktionen:
  • Da die Clients fundamentale Daemons sind, muss der IPC-Pfad zu ReportCheckpoint() strikt blockierungsfrei (non-blocking / lock-free) sein, um Priority Inversion oder Deadlocks (z. B. zwischen EM und PHM) auszuschließen.
  • Zirkuläre Abhängigkeiten beachten: EM startet PHM; PHM überwacht EM. Fehler im Boot-Bootstrap müssen über Timeout-Fallback-Mechanismen außerhalb von PHM abgefangen werden.
• ARXML-Modellierung & Manifest-Konfiguration:
  • Für jeden Daemon muss im Execution Manifest / Service Instance Manifest ein entsprechender SupervisedEntity-Port typisiert und dessen Checkpoint-IDs numerisch eindeutig vergeben werden.
  • Definition der Health-Monitoring-Regeln (Supervision Rules) und Schwellwerte im PHM-Konfigurationsmanifest.
• Einschränkungen für Plattform-Integratoren:
  • Nicht jeder Checkpoint darf im Hot-Path (z. B. Krypto-Streaming oder High-Rate TS-Pakete) gemeldet werden; Overhead durch Kontextwechsel und Cache-Invalidierung erfordert selektive Instrumentierung auf Makroebene (z. B. Zyklus-Ende oder Zustandswechsel).