Figure 7.1: Allowed mappings of Elementary Supervisions to Global Supervisions

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptuelles Architektur- und Mapping-Diagramm (Struktur- und Allokationsmodell) der AUTOSAR Adaptive Platform (AP).
• Funktionale Einordnung: Verortet im Subsystem Platform Health Management (PHM) (ara::phm). Es definiert die zulässigen Topologien für die Konsolidierung von elementaren Überwachungsmechanismen (Elementary Supervisions) zu übergeordneten Aggregationsinstanzen (Global Supervisions) unter Berücksichtigung von Prozess- und Funktionsgruppen-Grenzen (Function Groups der Execution Management Domäne).

2. Komponenten, Entitäten & Schnittstellen

• Function Group (FunctionGroup):
  • Übergeordnete Zustands- und Lebenszyklusdomäne des Execution Management (ara::exec).
  • Dargestellt sind zwei disjunkte Instanzen: Function Group 1 und Function Group 2.
• Process (Process):
  • POSIX-Betriebssystemprozesse, zugeordnet zu genau einer Funktionsgruppe:
    • Function Group 1: Process A, Process B, Process C.
    • Function Group 2: Process D.
• Elementary Supervisions (Elementare Überwachungen):
  • Innerhalb der Prozesse instanziierte Überwachungsentitäten, gespeist über die Checkpoint-API (ReportCheckpoint):
    • AliveSup_* (Alive Supervision): Frequenz- und Zykluszeitprüfung von Checkpoints.
    • DeadlineSup_* (Deadline Supervision): Latenzmessung zwischen Start- und Ziel-Checkpoint.
    • LogicalSup_* (Logical Supervision): Graphbasierte Sequenz- und Pfadprüfung (Transitionsüberwachung).
• Global Supervision (GlobalSupervision):
  • PHM-Aggregationslogik, die die Einzelzustände mehrerer elementarer Überwachungen zu einem kumulativen Gesundheitsstatus (OK, FAILED, EXPIRED, STOPPED) zusammenführt.
  • Dargestellt: GS_1, GS_2 (beide in Function Group 1), GS_3 (in Function Group 2).

Kardinalitäten & Struktur-Beziehungen

• Prozessübergreifendes Mapping (n:1): Elementary Supervisions aus unterschiedlichen Prozessen (Process A, Process B) dürfen derselben Global Supervision (GS_1) zugeordnet werden (linkes und rechtes Szenario).
• Dispersives Mapping (1:n / n:m): Elementary Supervisions desselben Prozesses können auf verschiedene Global Supervisions aufgeteilt werden (rechtes Szenario: Process A teilt AliveSup_1/DeadlineSup_1 zu GS_1 und LogicalSup_1 zu GS_2 zu).
• Strikte Isolationsgrenze: Es existiert kein Mapping über Funktionsgruppengrenzen hinweg. Eine Global Supervision bindet ausschließlich Elementary Supervisions, deren Quell-Prozesse derselben Function Group angehören (GS_1, GS_2 ⊂ Function Group 1; GS_3 ⊂ Function Group 2).

3. Dynamisches Verhalten & Sequenzablauf

• Trigger & Zustandsevaluation:
  1. Applikationsprozesse (Process A–D) melden Checkpoints über das Interface ara::phm::SupervisedEntity synchron an den PHM-Dämon.
  2. PHM evaluiert lokal die Zähler, Timer und Kontrollflussgraphen der jeweiligen Elementary Supervisions.
  3. Zyklische Aktualisierung der Global Supervision: Der Status jeder Global Supervision wird deterministisch aus den Zuständen der zugeordneten Elementary Supervisions aggregiert.
• Lebenszyklus-Kopplung an Function Group States:
  • Wechselt eine Funktionsgruppe ihren Zustand (z. B. Transition von Running nach Off), werden alle zugehörigen Global Supervisions (GS_1, GS_2) und deren Elementary Supervisions atomar aktiviert, suspendiert oder zurückgesetzt.
  • Eine funktionsgruppenübergreifende Überwachung ist zur Laufzeit ungültig, da asynchrone Zustandswechsel der Funktionsgruppen zu undefinierten Aggregationszuständen (z. B. Bewertung suspendierter Prozesse) führen würden.
• Eskalationspfade:
  • Erreicht eine Global Supervision den Status EXPIRED, löst PHM über hinterlegte Health Channel Actions definierte Gegenmaßnahmen aus (z. B. Recovery Action via ara::exec::StateClient zur Anforderung eines Function-Group-Zustandswechsels oder Fehlermeldung an das Recovery Management).

4. Normative Relevanz & Entwickler-Hinweise

• Modellierung im ARXML-Manifest (HealthManagementModel):
  • Konfiguration über SupervisionCheckpoint, AliveSupervision, DeadlineSupervision, LogicalSupervision und GlobalSupervision.
  • Validierungsregel (Syntax/Semantik-Check im Tooling): Jede GlobalSupervision darf über Referenzen (SupervisionMapping) ausschließlich ElementarySupervision-Elemente adressieren, deren beinhaltende ProcessToMachineMapping-Instanzen dieselbe FunctionGroup referenzieren.
• Architektur- und Design-Implikationen:
  • Modularität: Funktionslogiken, die prozessübergreifend zusammenarbeiten (z. B. Sensor-Fusion über Process A und Process B), können in einer gemeinsamen GlobalSupervision gebündelt werden, solange sie demselben Systemmodus (Funktionsgruppe) unterliegen.
  • Feingranulare Diagnostik: Wie im rechten Schaubild dargestellt, müssen logisch getrennte Fehlerpfade innerhalb eines Prozesses (z. B. kritischer Kontrollfluss LogicalSup_1 vs. unkritischer Alive-Zähler AliveSup_1) in separate Global Supervisions geroutet werden, um differenzierte Wiederanlauf- oder Degradations-Strategien zu steuern.
• Einschränkung für Funktionsentwickler:
  • Soll eine End-to-End-Überwachung über verschiedene Funktionsgruppen hinweg erfolgen, kann dies nicht direkt über eine Global Supervision modelliert werden; hierfür muss die Aggregation auf Ebene von Health Channels oder über das übergeordnete State Management (ara::sm) realisiert werden.