Figure 11.26: Scenario: Report Checkpoint

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.
  • «aapInformative» checkAccess(): PHM-interner Validierungsaufruf zur Prüfung der Prozess-Identität und Sendeberechtigung gegen die hinterlegte Zugriffs- bzw. Sicherheitskonfiguration (Identity & Access Management), explizit mit Stereotyp «aapInformative» als informativ gekennzeichnet.
  • «aapInformative» 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), explizit mit Stereotyp «aapInformative» als informativ gekennzeichnet.
  • 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).