Figure 9.79: Functional Clusters in category Safety

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm (Strukturdiagramm / Architektur-Übersicht).
• Architektur-Kontext: Übersicht der Functional Cluster der AUTOSAR Adaptive Platform (AP) innerhalb der Cluster-Kategorie Safety gemäß AUTOSAR_AP_EXP_SWArchitecture (Release R25-11).
• Technischer Zweck: Das Diagramm deklariert die funktionale Zuordnung und Bereitstellungsform der sicherheitsrelevanten Cluster der Adaptive Plattform: Platform Health Management (PHM) zur anwendungs- und plattformweiten Zustands- und Laufzeitüberwachung sowie Safe Hardware Acceleration (SHA/SHWA) zur standardisierten, funktional sicheren Anbindung und Nutzung von Hardware-Beschleunigern (z. B. GPUs, NPUs, FPGAs) für sicherheitskritische Workloads.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Komponenten:
  • «aapFunctionalCluster» Platform Health Management: Funktionales Cluster für die funktionale Sicherheit und Plattformüberwachung, deklariert mit dem Stereotypen «aapFunctionalCluster».
  • «aapFunctionalCluster» Safe Hardware Acceleration: Neu hinzugefügtes funktionales Cluster der Kategorie Safety zur sicherheitsgerichteten Abstraktion und Steuerung von Hardwarebeschleunigern (ara::shwa).
• Eigenschaften & Bereitstellungsformen:
  • daemon-based (bei Platform Health Management): Ausführung als eigenständiger Betriebssystemprozess (Daemon) im POSIX-User-Space.
  • Safe Hardware Acceleration (kein daemon-based-Zusatz): Bereitstellung über Bibliotheken (library-based / ara::shwa) zur direkten Integration in Anwendungskontexte mit hardwarenaher Treiberanbindung.
• Schnittstellen & Interaktionen (kontextuell abgeleitet):
  • ara::phm: Client-Bibliothek und IPC-Kommunikation zum PHM-Daemon für Alive-, Deadline-, Logical- und Health-Channel-Supervision.
  • ara::shwa: Standardisierte C++-API für Hardware Acceleration zur Verwaltung von Beschleuniger-Kontexten, Memory-Buffern und deterministischen Ausführungs-Pipelines.
  • Plattforminteraktion: Anbindung von PHM an ara::exec (Recovery Actions) sowie funktionale Überwachung von Beschleuniger-Workloads und Driver-Statusmeldungen im Sicherheitskontext.

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein rein statisches Komponentenschaubild handelt, sind keine Sequenzen dargestellt. Das resultierende Laufzeitverhalten der Safety-Cluster gliedert sich normativ wie folgt:

1. Initialisierung & Lifecycle:
   • Start des PHM-Daemons durch das Execution Management (ara::exec) in einer definierten Funktionsgruppe.
   • Instanziierung und Konfiguration des Beschleuniger-Treibers und der ara::shwa-Kontexte für berechtigte Adaptive Applications.
2. Laufzeitüberwachung (PHM):
   • Alive Supervision: Zyklische Checkpoint-Meldungen (ReportCheckpoint()) über IPC zur Überwachung der Ausführungsfrequenz.
   • Deadline Supervision: Messung von Latenzen zwischen Checkpoints (z. B. auch für asynchrone Berechnungszyklen).
   • Logical Supervision: Validierung korrekter Kontrollfluss-Transitionen.
   • Health Channel Supervision: Entgegennahme von Fehlermeldungen und Status-Events aus Applikationen und Hardware-Treibern.
3. Sichere Hardware-Beschleunigung (Safe Hardware Acceleration):
   • Anforderung von isolierten Speicher- und Rechenressourcen über ara::shwa.
   • Asynchrone Übergabe von Ausführungs-Jobs an Hardware-Beschleuniger und Überwachung der Rückmeldezeiten.
4. Recovery- und Fehlermanagement:
   • Bei Überschreiten von Supervision-Limits oder Treiber-Fehlern triggert PHM über das Execution Management koordinierte Reaktionen (Prozessneustart, Zustandswechsel in einen sicheren Zustand / Safe State).

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- und Ressourcen-Budgetierung (PHM): Da PHM daemon-based implementiert ist, erfordert es einen eigenen Betriebssystem-Prozess mit Echtzeit-Scheduling-Priorität, dedizierten Stack-/Heap-Budgets und zuverlässigen IPC-Kanälen.
• IPC-Latenz & Deadline-Design: Aufrufe an ara::phm aus Applikations-Threads dürfen Echtzeitanforderungen nicht verletzen; die IPC-Kommunikation zum Daemon muss deterministisch ausgelegt sein.
• Hardware-Isolation & Freedom from Interference (Safe Hardware Acceleration): Für Safe Hardware Acceleration müssen Plattform- und Treiber-Entwickler hardwareseitige Speichertrennung (IOMMU/SMMU) sowie deterministische Zugriffsrechte sicherstellen, um Rückwirkungsfreiheit zwischen unterschiedlichen ASIL-Einstufungen zu garantieren.
• API-Konformität: Applikationen dürfen nicht direkt über ungesicherte OS-Treiber-Bypässe auf Beschleuniger-Hardware zugreifen, sondern müssen die standardisierten ara::shwa-Schnittstellen nutzen, um Safety-Zertifizierbarkeit zu gewährleisten.