Figure 9.75: Interfaces for supervision

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellendiagramm gemäß AUTOSAR Adaptive Platform (AAP) Softwarearchitektur.
• Architektur-Kontext: Spezifiziert im Dokument AUTOSAR_EXP_SWArchitecture (Kapitel 9, Functional Cluster Platform Health Management, PHM). Es definiert die strukturelle Entkopplung und Interaktion zwischen einer Nutzer-Applikation (Adaptive Application) und dem zentralen, prozessbasierten PHM-Daemon (daemon-based) zur Laufzeitüberwachung der Kontrollfluss- und Zeitintegrität.

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» Platform Health Management daemon-based:
  • Architekturelle Komponente / Server-Cluster der AUTOSAR Adaptive Platform.
  • Läuft als eigenständiger Hintergrundprozess (Daemon) im POSIX-Betriebssystem.
  • Implementiert die Überwachungsalgorithmen (Alive-, Deadline- und Logical Supervision) sowie das Health-Monitoring.
• Adaptive Application:
  • UML-Komponente, die einen Anwendungs- bzw. Plattformprozess darstellt.
  • Agiert als überwachte Einheit (Supervised Entity bzw. Host der Entität).
• «aapAPI, aapPortInterface» SupervisedEntity:
  • Formale Schnittstelle, die sowohl als plattformspezifisches Port-Interface als auch als C++-Klassen-API (ara::phm::SupervisedEntity) typisiert ist.
  • Operationen: + ReportCheckpoint() (parametrisiert über eine eindeutige Checkpoint-ID).
• Beziehungen & Stereotypen:
  • Schnittstellen-Realisierung: Gestrichelter Pfeil mit geschlossener Spitze von Platform Health Management daemon-based zu SupervisedEntity – der PHM-Daemon implementiert das Backend für den Schnittstellenvertrag.
  • Nutzungsbeziehung: Gestrichelter Pfeil mit offener Spitze und Annotation «use» / «aapProvidedPort» von Adaptive Application zu SupervisedEntity – die Applikation greift clientseitig auf diese Schnittstelle zu, um ihren Ausführungsfortschritt mitzuteilen.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung: Die Adaptive Application instanziiert lokal das API-Objekt ara::phm::SupervisedEntity (gebunden an die im ARXML konfigurierte Instanz-Referenz).
2. Trigger (Normalpfad): Erreichen eines definierten Programmpunkts im Code der Adaptive Application.
3. Synchroner API-Aufruf: Die Anwendung ruft ReportCheckpoint(checkpointId) auf.
4. IPC-Transport: Der Aufruf wird über eine optimierte, nicht-blockierende Interprozesskommunikation (IPC, z. B. POSIX Shared Memory oder Domain Sockets) aus dem Adressraum der Anwendung in den Platform Health Management-Daemon übermittelt.
5. Supervision-Auswertung (Daemon-seitig):
   • Alive Supervision: Prüfung, ob Checkpoints innerhalb definierter Toleranzfenster in vorgegebener Häufigkeit eintreffen.
   • Deadline Supervision: Validierung von Mindest- und Höchstlaufzeiten zwischen zwei korrelierten Checkpoints.
   • Logical Supervision: Prüfung der Transitionen im Kontrollflussgraphen gegen definierte Vorgänger-/Nachfolger-Relationen.
6. Eskalation / Fehlerbehandlung: Bei Verletzung der Überwachungsbedingungen triggert der PHM-Daemon konfigurierte Recovery Actions (z. B. Meldung an den Execution Management (EM) Cluster zur Prozess-Restrukturierung/Neustart oder Eintrag in den Fehlerspeicher via Diagnostic Management).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::phm):
  • Aufrufe von ReportCheckpoint() müssen strikt deterministisch und thread-sicher sein. Sie dürfen im Applikations-Thread keinen blockierenden I/O auslösen, um Echtzeitanforderungen nicht zu verletzen.
• Daemon-basierte Latenz & Timing-Budget:
  • Die Kennzeichnung daemon-based bedingt IPC-Overhead. Entwickler dürfen Deadlines nicht feingranularer als die System-IPC-Latenz und den Scheduling-Jitter des Zielbetriebssystems auslegen.
• Modellierung im Adaptive Manifest:
  • Jede SupervisedEntity und deren zugehörige Checkpoint-IDs müssen im ARXML (Execution- / Service-Instance-Manifest) lückenlos deklariert und den Prozessen zugeordnet werden.
  • Diskrepanzen zwischen statisch generierten/konfigurierten IDs und im C++-Code gemeldeten Werten führen zur Verletzung der Logical Supervision und lösen automatische Schutzmaßnahmen aus.
• Prozessisolation:
  • Durch die Entkopplung in einen eigenen Daemon bleibt die Überwachungsinstanz auch bei Segfaults oder Hängern der Adaptive Application voll funktionsfähig und kann den Ausfall deterministisch melden.