DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_PlatformHealthManagement FIG-6a62f08d78f1c4c7 575 × 382 px 1 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 6a62f08d78f1c4c79b82a076bf4d86b447dd4ae9703e3aee40c17bf850bd5f56

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-description@2 · erstellt am 2026-10-07

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 Nachfolger: FIG-7bd3876b5d795907

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 R23-11 5 Dependencies to other Functional Clusters This chapter provides an overview of the dependencies to other Functional Clusters in the AUTOSAR Adaptive Platform. Section 5.1 “Provided Interfaces” lists the interfaces provided by Platform Health Management to other Functional Clusters. Section 5.2 “Required Interfaces” lists the interfaces required by Platform Health Management. A detailed technical architecture documentation of the AUTOSAR Adaptive Platform is provided in [11]. 5.1 Provided Interfaces «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» Figure 5.1: Interfaces provided by Platform Health Management to other Functional Clusters Figure 5.1 shows interfaces provided by Platform Health Management to other Functional Clusters within the AUTOSAR Adaptive Platform. Table 5.1 provides a complete list of interfaces provided to other Functional Clusters within the AUTOSAR Adaptive Platform. Interface Functional Cluster Purpose D

Vorkommen in AUTOSAR-Releases (2)

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