Figure 7.2: Mappings of Elementary Supervisions to Global Supervisions which are not supported

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Formales Architektur- und Metamodell-Restriktionsdiagramm (Mapping-Constraint-Diagramm) zur Spezifikation unzulässiger Konfigurationstopologien.
• Funktionale Einordnung: AUTOSAR Adaptive Platform, Platform Health Management (PHM) gemäß SWS PHM (R23-11, R24-11, Kapitel Supervision Concepts).
• Technischer Zweck: Definition der harten semantischen Modellierungs- und Konfigurationsgrenzen bei der Aggregation von elementaren Überwachungsinstanzen (Elementary Supervisions) zu globalen Überwachungen (Global Supervisions) im Zusammenspiel mit dem Execution Management (EM) und dessen Function Groups. Das Schaubild grenzt zulässige von verbotenen strukturellen Abhängigkeiten ab.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Rollen

• Function Group (Function Group 1, Function Group 2): Laufzeit- und Lebenszyklusdomänen des Execution Managements (EM). Eine Function Group definiert deterministische Prozesszustände (FunctionGroupStates) für die ihr zugewiesenen Prozesse.
• Process (Process A bis Process D): Betriebssystem-Prozessinstanzen adaptiver Applikationen (ara::core::Process), die jeweils einer spezifischen Function Group zugeordnet sind.
• Elementary Supervision: Basale Überwachungsmechanismen pro Prozess:
  • AliveSup_* (Alive Supervision – im Schaubild als AliceSup_ typographiert): Zykluserkennung über Checkpoint-Häufigkeit innerhalb eines Referenzintervalls.
  • DeadlineSup_* (Deadline Supervision): Latenzüberwachung zwischen Start- und Ziel-Checkpoint.
  • LogicalSup_* (Logical Supervision): Graphbasierte Kontrollflussprüfung von Checkpoint-Transitionen.
• Global Supervision (GS_1, GS_2, GS_3): Zustandssynthese-Einheit im PHM-Daemon zur Konsolidierung des Gesundheitsstatus mehrerer elementarer Überwachungen zu einem kumulativen Überwachungszustand.

Beziehungen, Kardinalitäten & Restriktionsregeln

• Restriktion 1 – Kein Cross-Function-Group-Mapping (Linkes Teildiagramm):
  • Eine GlobalSupervision (GS_2) darf niemals Elementary Supervisions aus Prozessen aggregieren, die unterschiedlichen Function Groups angehören (Process C aus Function Group 1 + Process D aus Function Group 2).
  • Regel: Jede GlobalSupervision besitzt einen strikten Geltungsbereich (Scope) innerhalb genau einer Function Group. M:N-Beziehungen über Function-Group-Grenzen hinweg sind prohibited (0..* → 1 nur innerhalb derselben FG).
• Restriktion 2 – Keine 1:N-Mehrfachzuordnung einer Elementary Supervision (Rechtes Teildiagramm):
  • Eine konkrete ElementarySupervision (LogicalSup_1 aus Process A) darf nicht zeitgleich mehreren Global Supervisions (GS_1 und GS_2) zugeordnet werden.
  • Das Mapping ElementarySupervision → GlobalSupervision ist eine N:1-Projektion bezogen auf denselben Auswertungszustand.
• Zulässige Heterogenität (Rechtes Teildiagramm, Process C):
  • Verschiedene Elementary Supervisions desselben Prozesses (AliveSup_3 vs. DeadlineSup_3 / LogicalSup_3) dürfen disjunkt auf unterschiedliche Global Supervisions (GS_1, GS_2) innerhalb derselben Function Group verteilt werden.

3. Dynamisches Verhalten & Sequenzablauf

Die Restriktionen resultieren direkt aus den deterministischen Laufzeitanforderungen des PHM-Daemons:

1. Lebenszyklus-Entkopplung & State Transitions:
   • Function Groups werden über das State Management (SM) und Execution Management (EM) zustandsgesteuert (z. B. State Off, Verify, Running).
   • Befindet sich Function Group 1 in Transition, während Function Group 2 im Nominalbetrieb läuft, wäre der Zustand einer übergreifenden Global Supervision (GS_2, linkes Bild) mathematisch und sicherheitstechnisch undefiniert (State Inconsistency).
2. Evaluation & Fehlerakkumulation:
   • Die Elementary Supervisions ermitteln prozesslokal elementare Statuswerte (OK, FAILED, EXPIRED).
   • Die Global Supervision aggregiert diese Werte zyklisch in ihrem spezifischen Task-Kontext. Ein mehrfaches Einspeisen desselben Prüfpfads (LogicalSup_1 in GS_1 und GS_2, rechtes Bild) würde zu redundanter Fehlerfortpflanzung, doppelten Recovery-Aktionen und unauflösbaren Prioritätskonflikten bei Reaktionsmaßnahmen (Health Channel Actions) führen.

4. Normative Relevanz & Entwickler-Hinweise

• Modellierung & AUTOSAR XML (ARXML):
  • In der PlatformHealthManagementContribution (ARPackage) müssen Generatoren und Validatoren Konsistenzprüfungen implementieren:
    • Validator-Check 1: Jede GlobalSupervision darf nur Referenzen auf ElementarySupervision besitzen, deren übergeordnete ProcessToMachineMappingInstance derselben FunctionGroupSet-Hierarchie angehört.
    • Validator-Check 2: Die Ref<ElementarySupervision> innerhalb der GlobalSupervision-Kollektion muss partititioniert / kollisionsfrei sein (GS_i ∩ GS_j = ∅ bezüglich referenzierter Elementary Supervisions).
• Applikations- & Stack-Entwickler:
  • Applikationen melden Checkpoints rein über die standardisierte API (ara::phm::SupervisedEntity::ReportCheckpoint). Weder Applikation noch Checkpoint-Id wissen von der Global Supervision.
  • Architekten müssen Überwachungsziele bereits im Systementwurf prozess- und funktionsgruppenkonform schneiden. Funktionsübergreifende Überwachungen, die mehrere Function Groups umspannen, können nicht über PHM Global Supervisions gelöst werden, sondern müssen auf höherer Ebene über das State Management mittels aggregierter Recovery-Events synchronisiert werden.