AUTOSAR_SWS_PlatformHealthManagement FIG-19712a2bda5c6d10 932 × 630 px 2 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 19712a2bda5c6d10c7479d3716cfd961e9475a5f9b1088cfcdbe9e1739a51618

✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

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)

R19-11 → R20-11 keine inhaltliche Änderung Nachfolger: FIG-4e544c6ccd78d1c5

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Platform Health Management for Adaptive Platform AUTOSAR AP R19-11 contextN>/<shortname of PortPrototype>, where the shortname of the Port Prototype corresponds to the Port representing the Supervised Entity or Health Channel in the meta-model. Figure 7.2: Example of multiple instance of the same Supervised Entity Figure 7.2 shows an example of a single Supervised Entity (called SE_A) belonging to a unique SW Component (SWCompontent_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. 18 of 33 — AUTOSAR CONFIDENTIAL — Document ID 851: AUTOSAR_SWS_PlatformHealthManagement

Vorkommen in AUTOSAR-Releases (4)

Release	Dokument	Seite	Nr.	Bildunterschrift im Dokument
R19-03	AUTOSAR_SWS_PlatformHealthManagement	S. 16	7.2	Figure 7.2: Example of multiple instance of the same Supervised Entity
R19-03	AUTOSAR_SWS_PlatformHealthManagement	S. 16	7.2	Figure 7.2: Example of multiple instance of the same Supervised Entity
R19-11	AUTOSAR_SWS_PlatformHealthManagement	S. 18	7.2	Figure 7.2: Example of multiple instance of the same Supervised Entity
R19-11	AUTOSAR_SWS_PlatformHealthManagement	S. 18	7.2	Figure 7.2: Example of multiple instance of the same Supervised Entity