Figure 9.67: Functional Clusters in category Safety

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm (Strukturdiagramm / Architektur-Übersicht).
• Architektur-Kontext: Repräsentation des AUTOSAR Adaptive Platform (AP) Clusters Platform Health Management (PHM) innerhalb der Cluster-Kategorie Safety gemäß AUTOSAR_EXP_SWArchitecture (Kapitel 9, Release R22-11).
• Technischer Zweck: Das Diagramm deklariert die funktionale Zuordnung und die Implementierungsstrategie des PHM. PHM fungiert als zentrale Instanz für funktionale Sicherheit auf der AP-Laufzeitumgebung und realisiert die Überwachung von Applikationen (Alive-, Deadline- und Logical Supervision sowie Health Channel Monitoring) mit Anbindung an das Execution Management zur Ausführung von Recovery-Aktionen.

2. Komponenten, Entitäten & Schnittstellen

• Entität:
  • «aapFunctionalCluster» Platform Health Management: Repräsentiert das funktionale Cluster der Adaptive Plattform mit dem Stereotypen «aapFunctionalCluster».
• Eigenschaft / Architektur-Merkmal:
  • daemon-based: Kennzeichnung der Bereitstellungsform als eigenständiger Betriebssystem-Prozess (Daemon / Service-Prozess) im User Space des POSIX-Betriebssystems im Gegensatz zu rein bibliotheksbasierten Clustern (library-based).
• Beziehungen & Schnittstellen (kontextuell abgeleitet):
  • In-Process-Bibliothek (ara::phm): Client-Bibliothek, die in die überwachten adaptiven Prozesse gelinkt wird.
  • Inter-Process-Communication (IPC): Asynchrone/synchrone Meldepfade zwischen ara::phm-Clients und dem zentralen PHM-Daemon.
  • Plattformschnittstelle zu ara::exec: Schnittstelle zum Execution Management (EM) zur Auslösung deterministischer Sicherheitsreaktionen (z. B. Prozess-Neustart, Zustandswechsel von Function Groups oder Plattform-Reset).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein rein statisches Komponentenschaubild handelt, sind keine Sequenzen dargestellt. Das resultierende Laufzeitverhalten des Daemons gliedert sich normativ wie folgt:

1. Initialisierung: Start des PHM-Daemons durch das Execution Management (EM) in einer definierten Startphase/Function Group.
2. Supervision-Zyklus:
   • Alive Supervision: Zyklische Checkpoint-Meldungen (ReportCheckpoint()) von Client-Applikationen über IPC; Verifikation gegen konfigurierte Min/Max-Intervalle.
   • Deadline Supervision: Messung der Latenz zwischen zwei definierten Checkpoints innerhalb eines Prozesses.
   • Logical Supervision: Validierung der Transitionen eines Zustandsgraphen (Transition-Topologie) gegen fehlerhafte Ausführungspfade.
   • Health Channel Supervision: Entgegennahme von expliziten Fehlermeldungen/Zuständen aus Applikationen.
3. Recovery Action Pipeline: Bei Überschreitung von Fehlertoleranzen oder Grenzwerten triggert der Daemon über das Execution Management koordinierte Recovery-Strategien (Process Restart, Function Group Transition, Safe State).

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- und Ressourcen-Budgetierung: Da PHM daemon-based ausgeführt wird, muss der POSIX-OS-Integrator einen eigenen Prozess inklusive Scheduling-Priorität (Echtzeitklasse / FIFO / Round Robin), Stack-/Heap-Budgets und IPC-Endpunkten (Domain Sockets, Shared Memory, Message Queues) vorsehen.
• IPC-Latenz & Deadline-Design: Aufrufe an ara::phm aus Applikations-Threads dürfen Echtzeitanforderungen nicht verletzen. Die IPC-Kommunikation zum PHM-Daemon muss deterministisch und nicht-blockierend ausgelegt sein, um Verfälschungen bei Deadline Supervisions zu verhindern.
• Safety-Level & ASIL-Dekomposition: Der PHM-Daemon läuft typischerweise auf dem höchsten geforderten ASIL der überwachten Anwendungen (bis zu ASIL D) und erfordert strenge Speichertrennung (Memory Protection über MMU/MPU) gegenüber ASIL-QM- und niedriger eingestuften Prozessen.
• Konfigurationsartefakte (ARXML): Entwickler müssen Überwachungsentitäten (SupervisedEntity, Checkpoint, AliveSupervision, DeadlineSupervision, LogicalSupervision) und Recovery-Regeln (RecoveryActionWorkItem, PhmRecoveryActionInterface) im AUTOSAR-Manifest modellieren. Der PHM-Daemon wird zur Generierungs-/Build-Zeit vollständig auf Basis dieser Manifeste konfiguriert.