Figure 12.9: Example how IDs have to be in sync

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Hybrides Architekturschaubild, bestehend aus UML-Metamodell-Ausschnitten (Klassen-/Objektdiagramm) und korrespondierendem C++-Applikationscode.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP, Releases R20-11 / R21-11), Spezifikation TPS_ManifestSpecification (Kapitel 9.3.3 Supervision deployment).
• Technischer Zweck: Visualisierung des durchgängigen Identifikator- und Namensraum-Abgleichs (ID Synchronization) für das Platform Health Management (PHM). Dargestellt ist die Konsistenzkette zwischen VFB/Application-Design (abstrakte Checkpoints), Applikations-Quellcode (ara::phm-Aufrufe) und Deployment-Konfiguration (maschinen-/prozessspezifische Überwachungsparameter).

2. Komponenten, Entitäten & Schnittstellen

Design-Ebene (Design)

• RootSWC: RootSwComponentPrototype: Top-Level-Komponenteninstanz der Software-Architektur.
• AdaptiveApplication: AdaptiveApplicationSwComponentType: Software-Komponententyp der Applikation, referenziert über «isOfType» als +applicationType.
• Se_B: RPortPrototype: Required-Port der Komponente (+port), typisiert über «isOfType» als +requiredInterface.
• SupervisedEntity_B: PhmSupervisedEntityInterface: Port-Interface zur Definition einer zu überwachenden Entität.
• CP1: PhmCheckpoint / CP2: PhmCheckpoint: Kompositionsbestandteile (+checkpoint) des Interfaces mit Entwurfs-Attributen:
  • CP1: checkpointId = 21
  • CP2: checkpointId = 22

Deployment-Ebene (Deployment (Configuration))

• PHM: PlatformHealthManagementContribution: Zentrales Aggregat der PHM-Konfiguration auf Maschinen-/Instanzebene.
• Se_B_Cp1: SupervisionCheckpoint / Se_B_Cp2: SupervisionCheckpoint: Konkret instanziierte Überwachungspunkte (+checkpoint), jeweils mit zugewiesener checkpointId (21 bzw. 22).
• Metamodell-Beziehung <<instanceRef, atpUriDef>>: Gerichtete Modellierungsreferenzen von den Deployment-Elementen (Se_B_Cp1, Se_B_Cp2) auf die Ziel-Checkpoints im Design (CP1, CP2) im Kontext des konkreten Port-Instanzpfads.

Applikationscode-Ebene (ApplicationCode)

• SupervisedEntity seB: Laufzeit-Instanz des PHM-C++-APIs (ara::phm::SupervisedEntity), instanziiert über den Instanzpfad "RootSWC/AdaptiveApplication/Se_B".
• seB.ReportCheckpoint(21): Synchroner Aufruf zur Laufzeit-Meldung eines Checkpoints unter Angabe der numerischen ID.

3. Dynamisches Verhalten & Sequenzablauf

1. Instanziierung & Binding:
   • Zur Initialisierung instanziiert die Adaptive Application das Objekt SupervisedEntity über den hierarchischen Manifest-Pfad (RootSWC/AdaptiveApplication/Se_B).
   • Der PHM-Dienst bindet das Applikationsobjekt an die im Deployment konfigurierte PlatformHealthManagementContribution.
2. Checkpoint Reporting (Laufzeit-Trigger):
   • Die Applikation erreicht den definierten Funktionspunkt und setzt den Aufruf seB.ReportCheckpoint(21) ab.
   • Der Aufruf transportiert die ID 21 via IPC/Prozessgrenze an den PHM-Dienst.
3. PHM-Auswertung & Zustandsprüfung:
   • Der PHM-Daemon mappt den meldenden Prozess/Port auf SupervisedEntity_B und validiert checkpointId == 21 gegen Se_B_Cp1.
   • Ausführung der konfigurierten Überwachungsalgorithmen:
     • Alive Supervision (Häufigkeit im Zyklus),
     • Deadline Supervision (Laufzeit zwischen CP1 und Folge-CP),
     • Logical Supervision (Zulässigkeit der Transition im Kontrollflussgraphen).
4. Fehlerbehandlung:
   • Meldet die Applikation eine nicht synchronisierte ID (z. B. unkonfiguriert oder falsche Reihenfolge), erkennt PHM eine Überwachungsverletzung und triggert konfigurierte Recovery-Aktionen (z. B. Notification an Execution Management / State Management zum Prozess-Neustart).

4. Normative Relevanz & Entwickler-Hinweise

• Normative Anforderungen: Erfüllt [TPS_MANI_03623] und [TPS_MANI_03624] – die numerischen Werte von PhmCheckpoint.checkpointId (Design), SupervisionCheckpoint.checkpointId (Deployment) und dem Parameter in ReportCheckpoint() müssen strikt wertgleich sein.
• Keine automatische Semantik-Garantie im Compiler: Da ReportCheckpoint(uint32_t/Id) ein numerisches Literal entgegennimmt, erkennt der C++-Compiler ID-Diskrepanzen zum Manifest nicht automatisch.
• Best Practice für Embedded-Entwickler:
  • Niemals "Magic Numbers" (21, 22) direkt im Code hardcodieren.
  • Nutzung der aus dem ARXML-Design generierten Typen/Konstanten bzw. typsicheren Enums des Plattform-Generators.
• String-Bindung des Instanzpfads: Der Konstruktor-String "RootSWC/AdaptiveApplication/Se_B" bindet den Code hart an die Modellhierarchie. Jedes Refactoring im ARXML (z. B. Umbenennung des RPortPrototype oder der Instanz) bricht das Binding zur Laufzeit, falls Pfad-Konstanten nicht aus dem Manifest generiert werden.
• Tooling-Validierung: CI-Pipelines müssen statische Prüfungen integrieren, die ARXML-Design, Deployment-ARXML und C++-Konstanten vor der Binary-Erstellung auf Kongruenz abgleichen.