Figure 7.6: Example of multiple instance of the same Supervised Entity

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Struktur- und Instanziierungsdiagramm / Komponenten-Deployment-Modell (AUTOSAR Adaptive Platform, UML-angelehnt).
• Technischer Zweck: Visualisierung des Kardinalitäts- und Identifikationsmodells bei Multi-Instanziierung von Software-Komponenten (SwComponentType) mit integrierter Überwachungsentität (Supervised Entity, SE) im Platform Health Management (ara::phm).
• Funktionale Einordnung: Veranschaulicht die Ableitung eindeutiger Laufzeit-Repräsentationen von SE-Ports aus dem abstrakten AUTOSAR-Designmodell über OS-Prozess- und Komponenteninstanzgrenzen hinweg gemäß AUTOSAR AP R19-11.

2. Komponenten, Entitäten & Schnittstellen

• SWComponent_X (Typ-Ebene, oben links):
  • Wiederverwendbarer Software-Komponententyp (Template / Entwurfsebene).
  • Beinhaltet den Port-Prototyp SE_A (PortPrototype), welcher semantisch eine Supervised Entity repräsentiert.
• SE_A:
  • Repräsentiert die funktionale Überwachungsentität (Supervised Entity) bzw. den zugehörigen Health Channel innerhalb der Komponenten-Definition.
• Prozess- und Anwendungs-Kontexte (Instanz-Ebene, unten):
  • App1 / Process 1 (Betriebssystem-Prozess 1):
    • Multi-Instanz-Szenario innerhalb desselben virtuellen Adressraums:
      • SWComponent_X (Instance_1) mit zugewiesenem SE_A-Port.
      • SWComponent_X (Instance_2) mit zugewiesenem SE_A-Port.
  • App2 / Process 2 (Betriebssystem-Prozess 2):
    • Isolierter Prozesskontext einer separaten Adaptive Application:
      • SWComponent_X (Einzelinstanz) mit zugewiesenem SE_A-Port.
• Kardinalitäten & Zuordnungsrelationen:
  • 1:N-Instanziierung: Ein Software-Komponententyp SWComponent_X mit 1 SE_A-Port wird 3× instanziiert.
  • Daraus resultieren zur Laufzeit exakt 3 eigenständige, disjunkte Port-Prototyp-Instanzen für SE_A.

3. Dynamisches Verhalten & Sequenzablauf

• Diagrammart: Statisches Instanz- und Allokationsdiagramm (kein zeitlicher Sequenzfluss).
• Laufzeit- und Identifikationsmechanismus:
  • Jede Instanz von SE_A sendet Checkpoint-Transitionsdaten (Alive-, Deadline- oder Logical-Supervision-Events) über die ara::phm-Schnittstelle an den PHM-Dienst.
  • Die Adressierung und Unterscheidung erfolgt über hierarchische, vollqualifizierte Kontextpfade der Form: $$\text{<Process Context>} / \text{<RootSwComponentPrototype>} / \dots / \text{<ShortName of PortPrototype>}$$
  • Konkrete Adressierungsauflösung im PHM:
    1. Process1/.../Instance_1/SE_A
    2. Process1/.../Instance_2/SE_A
    3. Process2/.../SWComponent_X/SE_A
  • Der PHM-Daemon führt für jede der 3 Instanzen einen vollständig autonomen Zustandsautomaten (Local Supervision Status).

4. Normative Relevanz & Entwickler-Hinweise

• ARXML / Execution & Service Instance Manifest:
  • Entwickler müssen sicherstellen, dass im Execution Manifest und Service Instance Manifest jeder Komponenten-Instanz ein eindeutiger InstanceSpecifier zugewiesen wird.
  • Die Port-Konfiguration für die Supervised Entity darf nicht kollidieren, wenn zwei Instanzen derselben Komponente im selben Prozess (Process 1) koexistieren.
• C++-API (ara::phm):
  • Bei der Erzeugung des ara::phm::SupervisedEntity-Objekts im Quellcode muss der applikationsspezifische ara::core::InstanceSpecifier übergeben werden (z. B. Initialisierung via Port-Name/Instanz-Pfad).
  • Ein global statischer Zugriff auf eine unqualifizierte SE_A-Instanz ist unzulässig; Instanzen müssen thread- und kontextsicher instanziiert werden.
• Safety- & Monitoring-Isolation:
  • Fehlverhalten (z. B. Deadline-Verletzung oder Checkpoint-Ausfall) in Instance_1 führt zur Degradation ausschließlich des lokalen Status von Instance_1.
  • Eine Verfälschung des Überwachungszustands von Instance_2 im selben Prozess wird durch die strikte Trennung der Instanz-Identifikatoren auf Meta- und Laufzeitebene verhindert (Failure Containment).