DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-8ba88db5c3893244 460 × 351 px 1 Release(s)

Figure 11.19: Scenario: Report Checkpoint

SHA-256 Inhalts-Fingerabdruck: 8ba88db5c38932445d96a3212527d01ca4d605fc70686ac74ab65b69f3b15941
✦ 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: UML-Sequenzdiagramm mit bedingter Verzweigung (alt-Fragment).
  • Technischer Zweck: Spezifikation des Kontrollflusses bei der Meldung eines Überwachungspunktes (Checkpoint) durch eine Applikation an das Laufzeitüberwachungssystem unter Einbeziehung von Zugriffsvalidierung und sicherheitsrelevanter Anomalieerfassung.
  • Funktionale Einordnung: AUTOSAR Adaptive Platform (AP R23-11), Zusammenspiel des funktionalen Sicherheitsclusters Platform Health Management (PHM) mit dem Security-Cluster Intrusion Detection System Manager (IdsM) sowie einer instanziierten Adaptive Application.

2. Komponenten, Entitäten & Schnittstellen

  • Akteure / Lebenslinien:
    • :Adaptive Application: Prozessinstanz im User-Space, instrumentiert mit Checkpoints zur Kontrollfluss- und Lebendigkeitsüberwachung.
    • «aapFunctionalCluster» :Platform Health Management: Zentraler Systemdienst zur Überwachung von Alive-, Deadline- und Logical Supervisions.
    • «aapFunctionalCluster» :Intrusion Detection System Manager: Zentraler Plattformdienst zur Erfassung, Filterung und Weiterleitung von Security-Ereignissen (Security Events).
  • Operationen & Schnittstellen:
    • ReportCheckpoint(): Interaktionsaufruf (IPC/API, i. d. R. ara::phm) von der Applikation an das PHM mit Übergabe der Checkpoint-ID.
    • checkAccess(): PHM-interner Validierungsaufruf zur Prüfung der Prozess-Identität und Sendeberechtigung gegen die hinterlegte Zugriffs- bzw. Sicherheitskonfiguration (Identity & Access Management).
    • handleReportedCheckpoint(): PHM-interne Routine zur Aktualisierung der Überwachungsmodi (z. B. Hochzählen von Alive-Countern, Timer-Stopp/Start bei Deadlines, Graph-Traversierung bei Logical Supervisions).
    • ReportEvent(): Standardisierte API-Interaktion (ara::idsm) zur Übergabe eines definierten Security Events (SEv) an den IdsM bei unautorisiertem Zugriff.

3. Dynamisches Verhalten & Sequenzablauf

  1. Trigger: Die :Adaptive Application erreicht im Kontrollfluss einen Messpunkt und ruft synchron/asynchron ReportCheckpoint() auf dem :Platform Health Management auf.
  2. Autorisierungsprüfung: PHM führt unverzüglich die interne Routine checkAccess() aus, um zu verifizieren, ob der aufrufende Kontext (Prozess/UID/PID) für diese spezifische Checkpoint-ID autorisiert ist.
  3. Bedingte Verzweigung (alt):
    • Pfad [access granted]: Bei erfolgreicher Autorisierung ruft PHM intern handleReportedCheckpoint() auf. Der Status der zugeordneten Supervisions (Alive/Deadline/Logical) wird aktualisiert; keine Benachrichtigung externer Security-Cluster.
    • Pfad [access denied]: Ist der Prozess nicht autorisiert (z. B. Prozess-Spoofing, korrumpierter Kontext), bricht PHM die Checkpoint-Auswertung ab und meldet den Vorfall via ReportEvent() an den :Intrusion Detection System Manager.

4. Normative Relevanz & Entwickler-Hinweise

  • Manifest- & Konfigurationspflichten:
    • Checkpoints müssen im ARXML-Datenmodell (HealthChannelAction, SupervisedEntity, Checkpoint) modelliert und eindeutig einer Applikation bzw. einem Executable zugeordnet sein.
    • Berechtigungen müssen in den Zugriffsregeln (IAM/Security Profiles) des PHM gepflegt sein; Diskrepanzen zwischen Applikationscode und Manifest führen unmittelbar zu access denied.
  • Einfluss auf die Applikationsentwicklung:
    • Applikationen dürfen Checkpoint-IDs nicht generisch oder dynamisch wählen; unzulässige oder nicht zugeordnete IDs provozieren Security-Meldungen im System.
    • Instrumentierung mit ReportCheckpoint() muss strikt deterministisch erfolgen, um Timing- und Kontrollflussfehler zu vermeiden.
  • Einfluss auf Plattform-/Stack-Entwickler:
    • Das PHM muss eine performante Prozessauthentifizierung bereitstellen (z. B. via Peer-Credentials über Unix Domain Sockets), damit checkAccess() minimalen Overhead auf die Echtzeitausführung hat.
    • Für den IdsM muss eine dedizierte Security Event Definition (SEv) für fehlgeschlagene Checkpoint-Zugriffe parametriert sein, inklusive Context-Data-Payload (z. B. fehlerhafte ID, anfragende Prozess-ID).

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

R23-11 → R24-11 redaktionell Nachfolger: FIG-0aaa2ebc8b17d424
  • Interne Methode checkAccess(): Ergänzung des Stereotyps «aapInformative» über dem Methodenaufruf auf der Lebenslinie :Platform Health Management.
  • Interne Methode handleReportedCheckpoint(): Ergänzung des Stereotyps «aapInformative» über dem Methodenaufruf auf der Lebenslinie :Platform Health Management innerhalb des [access granted]-Zweigs.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

:Adaptive Application «aapFunctionalCluster» | :Platform Health | Management | «aapFunctionalCluster» | :Intrusion Detection System | Manager | alt | [access granted] | [access denied] | checkAccess() | handleReportedCheckpoint() | ReportEvent() | ReportCheckpoint()

Begleitender Spezifikationstext:

Explanation of Adaptive Platform Software Architecture AUTOSAR AP R23-11 «aapFunctionalCluster» :Platform Health Management :Watchdog loop checkSupervisions() AliveNotification() Figure 11.18: Scenario: Manage Watchdog Figure 11.18 shows the default scenario for Manage Watchdog. Platform Health Management regularly checks its supervisions. Platform Health Management also calls the method AliveNotification() cyclically in order to report aliveness to the Watchdog. 11.5.1.2 Report Checkpoint 11.5.1.2.1 Scenario: Report Checkpoint :Adaptive Application «aapFunctionalCluster» :Platform Health Management «aapFunctionalCluster» :Intrusion Detection System Manager alt [access granted] [access denied] checkAccess() handleReportedCheckpoint() ReportEvent() ReportCheckpoint() Figure 11.19: Scenario: Report Checkpoint Figure 11.19 shows the default scenario for Report Checkpoint. The Adaptive Application reports a checkpoint to Platform Health Management by calling the method ReportCheckpoint(). After that, Platform Health Management checks if the Adaptive Application is allowed to report the checkpoint. Then, Platform Health Management handles the reported checkpoint internally depending on the type of the supervision mode. If access is denied, Platform Health Management reports this event to Intrusion Detection System Manager by calling the method ReportEvent(). 178 of 198 Document ID 982: AUTOSAR_AP_EXP_SWArchitecture

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_SWArchitecture S. 178 11.19 Figure 11.19: Scenario: Report Checkpoint