DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_TPS_ManifestSpecification FIG-a97fd648c3814fab 522 × 281 px 1 Release(s)

Figure 3.43: Modeling of Supervised Entities and Checkpoints

SHA-256 Inhalts-Fingerabdruck: a97fd648c3814fabaccd9257eaca7a04818e1fcd80c78e6727c3a50aece2c051
✦ 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

UML-Klassendiagramm zur Spezifikation von PhmSupervisedEntityInterface und PhmCheckpoint sowie deren Einbettung in die Vererbungshierarchie der AUTOSAR-Port-Schnittstellen im Kontext des Platform Health Management der AUTOSAR Adaptive Platform (TPS Manifest Specification).

2. Komponenten, Entitäten & Schnittstellen

  • PortInterface: Übergeordnete Schnittstellenklasse mit den Stereotypen «ARElement», «AtpBlueprint», «AtpBlueprintable» und «AtpType».
  • PlatformHealthManagementInterface: Abstrakte Zwischenklasse (kursiv dargestellt), die per Generalisierung von PortInterface erbt.
  • PhmSupervisedEntityInterface: Konkrete Schnittstellenklasse für überwachte Entitäten, die per Generalisierung von PlatformHealthManagementInterface erbt.
  • PhmCheckpoint: Klasse mit dem Stereotyp «AtpFeature»; besitzt das optionale Attribut + checkpointId: PositiveInteger [0..1].
  • Beziehung: Komposition von PhmSupervisedEntityInterface zu PhmCheckpoint mit der Rollenbezeichnung +checkpoint und der Multiplizität 0..*.

3. Dynamisches Verhalten & Sequenzablauf

Statisches Strukturdiagramm ohne explizite Ablauf- oder Sequenzdarstellung. Die Modellierung legt fest, dass eine überwachte Entität (PhmSupervisedEntityInterface) null bis beliebig viele Checkpoints instanziieren und besitzen kann, die zur Laufzeit von PHM zur Überwachung (Alive-, Deadline- oder Logical Supervision) herangezogen werden.

4. Normative Relevanz & Entwickler-Hinweise

Normative Spezifikation der Checkpoint-Modellierung und Schnittstellenhierarchie. PhmSupervisedEntityInterface ist über PlatformHealthManagementInterface als spezialisiertes PortInterface und damit als ARElement, AtpBlueprint sowie AtpType typisiert. Checkpoints werden über die Komposition +checkpoint mit Multiplizität 0..* eingebunden. Das Attribut checkpointId an PhmCheckpoint ist optional mit Multiplizität [0..1] definiert, sodass Checkpoint-IDs modellseitig weggelassen oder implizit vergeben werden können.

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

R23-11 → R24-11 normative Änderung Vorgänger: FIG-e14edc2c0fc71d17
  • PhmSupervisedEntityInterface: Vererbungshierarchie explizit modelliert; erbt über Generalisierung von der abstrakten Klasse PlatformHealthManagementInterface.
  • PlatformHealthManagementInterface: Als eigene abstrakte Schnittstellenklasse dargestellt; erbt über Generalisierung von PortInterface.
  • PortInterface: Als übergeordnete Klasse mit den Stereotypen «ARElement», «AtpBlueprint», «AtpBlueprintable» und «AtpType» in die Vererbungshierarchie eingefügt.
R24-11 → R25-11 keine inhaltliche Änderung Nachfolger: FIG-a277a43bdacd44c9

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

PhmSupervisedEntityInterface AtpFeature | PhmCheckpoint | + checkpointId: PositiveInteger [0..1] | ARElement AtpBlueprint AtpBlueprintable | AtpType | PortInterface | PlatformHealthManagementInterface | +checkpoint | 0..*

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_TPS_ManifestSpecification S. 134 3.43 Figure 3.43: Modeling of Supervised Entities and Checkpoints