DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_PlatformHealthManagement FIG-2c24c37928c4f465 932 × 631 px 2 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 2c24c37928c4f465f87e74d8a7bb2bba4323b47cd238dd1bfc74093519d12258
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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).

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R23-11 → R24-11 keine inhaltliche Änderung Vorgänger: FIG-d155c847e51eb97d

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Platform Health Management AUTOSAR AP R25-11 7.6 Multiple processes and multiple instances During the application deployment phase, a single Supervised Entity may be instanciated several times: this happens for example when the same C++ object class representing a Supervised Entity is explicitly instanciated inside the code or when the same executable containing the Supervised Entity is started/run multiple times. In such a case, each instance of the Supervised Entity is individually supervised, each Alive Supervision, Deadline Supervision and Logical Supervision generating an instance of Elementary Supervision Status. A specific instance of a Supervised Entity identifies itself at run time via an InstanceSpecifier. The API usage of the ara::core::InstanceSpecifier is specified in SWS_CORE_10200 and chapter "‘InstanceSpecifier data type"’ in [8]. The modelling relation of the InstanceSpecifier and its usage in PHM is explained in detail in the chapter "‘Supervised Entities and Checkpoints"’ in [11]. Figure 7.7: Example of multiple instance of the same Supervised Entity Figure 7.7 shows an example of a single Supervised Entity (called SE_A) belonging to a unique SW Component (SWComponent_X in the example). SWComponent_X is instanciated explicitly twice in the same process (Process 1) and another time in a different process/application (process 2). In such a case, three instances of the Port Prototype representing the Supervised Entity are created. 51 of 107 Do

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_SWS_PlatformHealthManagement S. 48 7.7 Figure 7.7: Example of multiple instance of the same Supervised Entity
R25-11 AUTOSAR_AP_SWS_PlatformHealthManagement S. 51 7.7 Figure 7.7: Example of multiple instance of the same Supervised Entity