Figure 7.1: Health Channel configuration

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm (Metamodell- / Konfigurationsausschnitt, Paketrahmen HM_HealthChannel).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R20-11), Spezifikation Platform Health Management (PHM).
• Technischer Zweck: Definition der Metamodell-Struktur für die Health-Channel-Supervision. Im Gegensatz zu kontrollflussbasierten Mechanismen (Alive-, Deadline- und Logical-Supervision über Checkpoints) dient der Health Channel der statischen und zustandsbasierten Überwachung diskreter System-, Hardware- oder Applikationszustände (z. B. Sensorausfall, Speicherfehler, interne Degradation).

2. Komponenten, Entitäten & Schnittstellen

• HealthChannel (Klasse):
  • Repräsentiert einen logischen Überwachungskanal innerhalb des PHM.
  • Attribute:
    • Name: Eindeutiger Bezeichner des Überwachungskanals.
    • ID: Numerische Kennung zur internen Adressierung und Laufzeit-Identifikation bei IPC-/API-Aufrufen.
    • HealthStatusInitValue: Initialer Gesundheitszustand, der dem Kanal beim Systemstart bzw. vor dem Eintreffen der ersten Statusmeldung zugewiesen wird.
• HealthStatus (Klasse):
  • Repräsentiert einen diskreten, gültigen Zustandswert, den der zugehörige Kanal annehmen kann (z. B. OK, DEGRADED, FATAL_ERROR).
  • Attribute:
    • Name: Symbolischer Bezeichner des Zustands.
    • ID: Numerischer Enumerate-Wert, der über die Laufzeitschnittstelle übertragen wird.
• Beziehungen & Kardinalitäten:
  • Komposition (HealthChannel ◆--- HealthStatus): Ein HealthChannel besitzt die vollständige Existenzabhängigkeit (Lebenszyklus-Hoheit) über seine zugeordneten HealthStatus-Instanzen. Ein Zustandswert existiert nur im Kontext seines Kanals (1 zu $1..\ast$).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung: Beim Hochfahren der Adaptive Application und des PHM-Daemons befindet sich der Kanal im Zustand HealthStatusInitValue.
2. Laufzeit-Trigger (Meldung): Eine überwachte Entität (Applikation, Treiber oder HW-Monitor) meldet ihren Status via IPC/API (ReportHealthStatus(HealthChannelId, HealthStatusId)) synchron an die lokale PHM-Laufzeitbibliothek.
3. Validierung & Zustandsübergang: Der PHM-Daemon prüft, ob die gemeldete HealthStatusId Teil der für den Kanal konfigurierten HealthStatus-Menge ist. Bei Übereinstimmung wechselt der Kanalzustand.
4. Auswertung & Recovery: Der aktuelle Zustand speist die PHM-Regel-Engine (Supervision Condition / Logical Expression):
   • Verlässt der Kanal den Normalzustand oder nimmt einen definierten Fehlerstatus ein, wird die zugeordnete Recovery Action getriggert (z. B. Prozessneustart über Execution Management, Transition über State Management oder Fehlereintrag via Diagnostic Management).
   • Bei Meldung unkonfigurierter IDs greift die Fehlerbehandlung des PHM (z. B. Reporting an die Logging/Security-Infrastruktur).

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsvertrag (ARXML):
  • Für jeden Kanal müssen alle erwarteten Statuswerte inklusive Initialzustand (HealthStatusInitValue) lückenlos im Manifest modelliert werden. Nicht deklarierte IDs zur Laufzeit führen zu API-Fehlern (ara::phm-Fehlercodes) und verwerfen die Meldung.
• API & Applikations-Entwicklung (ara::phm):
  • Applikationen instanziieren ein kanalbezogenes Interface-Objekt (z. B. ara::phm::HealthChannel).
  • Die Aufrufe sollten zustandsändernd oder bei Erreichen kritischer Degradationsstufen erfolgen; sie erfordern deterministische Zuordnung der im Manifest definierten numerischen IDs zu lokalen Enums.
• Stack- & Plattform-Integration:
  • Der PHM-Daemon muss threadsicher und nicht-blockierend ausgelegt sein, um Meldungen mehrerer Channels aus verschiedenen Prozessen/Kernen ohne Priority-Inversion zu konsolidieren.