DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_PlatformHealthManagement FIG-7bd3876b5d795907 575 × 382 px 1 Release(s)

Figure 5.1: Interfaces provided by Platform Health Management to other Functional Clusters

SHA-256 Inhalts-Fingerabdruck: 7bd3876b5d7959079010c682e66bab3e2c9be6489834cc4724d824a6d97d52d1

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ 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

  • Diagrammtyp: UML-Komponentendiagramm mit Schnittstellenrealisierung und Abhängigkeiten (AUTOSAR Adaptive Platform Schnittstellendiagramm).
  • Technischer Zweck: Darstellung der vom Functional Cluster Platform Health Management (PHM) bereitgestellten Schnittstelle gegenüber anderen daemon-basierten Functional Clusters der AUTOSAR Adaptive Platform (AP R23-11).
  • Architektur-Einordnung: PHM dient als zentrale Instanz für funktionale Sicherheit (Safety) und Verfügbarkeit auf der Adaptive Platform. Das Diagramm spezifiziert die Plattform-Interdependenzen: Kern-Daemons der Plattform werden als Supervised Entities (SE) modelliert, um deren korrekte zeitliche und logische Ausführung durch PHM überwachen zu lassen (Alive-, Deadline- und Logical Supervision).

2. Komponenten, Entitäten & Schnittstellen

  • Bereitstellender Functional Cluster:
    • «aapFunctionalCluster» Platform Health Management (Attribut: daemon-based): Realisiert («realize», gestrichelte Linie mit geschlossener Pfeilspitze) die Schnittstelle SupervisedEntity.
  • Bereitgestellte Schnittstelle:
    • «aapAPI,aapPortInterface» SupervisedEntity:
      • Methode: + ReportCheckpoint()
      • Dient als Programmierschnittstelle bzw. typisierter Port zur Meldung von Kontrollpunkten (Checkpoints) an den PHM-Daemon.
  • Konsumierende Functional Clusters:
    • Alle Konsumenten sind als «aapFunctionalCluster» mit dem Eigenschaftswert daemon-based typisiert:
      • Execution Management (EM)
      • Diagnostic Management (DM)
      • State Management (SM)
      • Update and Configuration Management (UCM)
      • Time Synchronization (TS)
    • Beziehungsart: Jeder konsumierende Cluster greift über eine gerichtete Abhängigkeit («use») unter Verwendung eines «aapRequiredPort» auf die SupervisedEntity-Schnittstelle zu.

3. Dynamisches Verhalten & Sequenzablauf

  • Trigger & Aufrufmuster:
    1. Checkpoint-Erreichung: Ein daemon-basierter Cluster durchläuft während seines Arbeitszyklus (z. B. zyklische Tasks in TS/EM oder Zustandsübergänge in SM/UCM) definierte Programmpunkte.
    2. Aufruf von ReportCheckpoint(): Der Daemon ruft synchron über die lokale Bibliotheksbindung (ara::phm::SupervisedEntity::ReportCheckpoint(CheckpointId)) den Checkpoint auf.
    3. IPC-Weiterleitung & Validierung: Die Meldung wird an den PHM-Daemon übermittelt. PHM bewertet den Checkpoint anhand hinterlegter Regeln:
      • Alive Supervision: Einhaltung definierter Meldefrequenzen innerhalb eines Referenzzeitraums.
      • Deadline Supervision: Einhaltung maximaler/minimaler Latenzen zwischen zwei Checkpoints.
      • Logical Supervision: Einhaltung der korrekten Kontrollfluss-Reihenfolge gemäß Transition-Graph.
    4. Fehlerreaktion: Bei Regelverletzung eskaliert PHM den Zustand (z. B. Meldung an State Management zur Einleitung von Recovery-Aktionen oder Neustart über Execution Management).

4. Normative Relevanz & Entwickler-Hinweise

  • Plattform-Integration & Binding:
    • Die Schnittstelle wird im Quellcode über die C++-Klasse ara::phm::SupervisedEntity eingebunden. Da alle beteiligten Cluster daemon-based sind, muss der IPC-Kanal zwischen den Client-Bibliotheken der Daemons und dem PHM-Daemon robust, latenzarm und deterministisch ausgelegt sein.
  • ARXML-Modellierung:
    • Für jeden überwachten Plattform-Daemon muss im Manifest (ExecutionManifest / ServiceInstanceManifest) ein PHMContribution mit entsprechenden SupervisedEntity-, Checkpoint- und Supervision-Regeln (AliveSupervision, DeadlineSupervision, LogicalSupervision) konfiguriert werden.
    • Konsumierende Daemons benötigen im Software-Komponentenmodell einen korrespondierenden RPortPrototype mit typisiertem PortInterface.
  • Implementierungs-Einschränkungen:
    • Da Deadlocks zwischen Kernkomponenten vermieden werden müssen, darf ReportCheckpoint() nicht blockierend implementiert sein.
    • Zirkuläre Abhängigkeiten beachten: Fällt PHM selbst aus oder gerät EM in einen Fehlerzustand, müssen statische Fallback-Mechanismen (z. B. Hardware-Watchdog) greifen, da PHM sich für Recovery-Aktionen wiederum auf EM bzw. SM stützt.

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

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

Keine inhaltlichen Änderungen erkennbar.

R24-11 → R25-11 keine inhaltliche Änderung Nachfolger: FIG-ea096371f5a5c338

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» Platform Health Management daemon-based | «aapFunctionalClust... Execution Management daemon-based | «aapFunctionalClust... | State Management | daemon-based | «aapAPI,aapPortInterface» | SupervisedEntity | + ReportCheckpoint() | «aapFunctionalClust... Diagnostic Management daemon-based | «aapFunctionalClust... | Time Synchronization | daemon-based | «aapFunctionalCluster» Update and Configuration | Management daemon-based | «use» «aapRequiredPort» | «use» «aapRequiredPort» «use» «aapRequiredPort» «use» «aapRequiredPort» «use» «aapRequiredPort»

Begleitender Spezifikationstext:

Specification of Platform Health Management AUTOSAR AP R24-11 5 Dependencies to other Functional Clusters This chapter defines the dependencies of this functional cluster to other functional clusters. AUTOSAR decided not to standardize interfaces which are exclusively used between functional clusters to allow efficient implementations which might depend e.g., on the used operating system. The goal of this chapter is to provide an informative guideline for the interactions between functional clusters without specifying syntactical details. This ensures compatibility between documents specifying different functional clusters and supports parallel implementation of different functional clusters. Details of internal interfaces are up to the platform provider. Additional internal interfaces, parameters, and return values can be added. A detailed technical architecture documentation of the overall AUTOSAR Adaptive Platform is provided in [10]. 5.1 Provided Interfaces This section provides an overview of the public interfaces provided by this functional cluster towards other functional clusters. «aapFunctionalCluster» Platform Health Management daemon-based «aapFunctionalClust... Execution Management daemon-based «aapFunctionalClust... State Management daemon-based «aapAPI,aapPortInterface» SupervisedEntity + ReportCheckpoint() «aapFunctionalClust... Diagnostic Management daemon-based «aapFunctionalClust... Time Synchronization daemon-based «aapFunctionalCluster» Update and Configur

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_SWS_PlatformHealthManagement S. 14 5.1 Figure 5.1: Interfaces provided by Platform Health Management to other Functional Clusters