Figure 9.69: Interface for receiving notifications about qualified security events

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Schnittstellen- und Komponentendiagramm (AUTOSAR Adaptive Platform Architecture Modeling).
• Technischer Zweck: Spezifikation des Service- und Schnittstellenmusters zur Benachrichtigung von Adaptive Applications über qualifizierte Sicherheitsereignisse (Qualified Security Events) durch den Intrusion Detection System Manager (IdsM).
• Architektonische Einordnung: AUTOSAR Adaptive Platform (Release R24-11), Functional Cluster IdsM (AUTOSAR_AP_EXP_SWArchitecture). Der IdsM empfängt rohe Sicherheitsereignisse (Security Events via Sensor-APIs), filtert und qualifiziert diese anhand definierter Schwellwerte/Regeln und leitet die daraus resultierenden qualifizierten Events über eine serviceorientierte Schnittstelle an autorisierte adaptive Anwendungen (z. B. Incident Handler, Logging- oder Gegenmaßnahmen-Services) weiter.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • «aapFunctionalCluster» Intrusion Detection System Manager: Plattform-Kernkomponente, realisiert als eigenständiger Hintergrunddienst (daemon-based). Tritt in diesem Kontext als Client/Konsument der Schnittstelle auf.
  • Adaptive Application: Anwendungs-Komponente im User-Space, die als Event-Empfänger agiert.
• Schnittstellen & Stereotypen:
  • «aapAPI, aapPortInterface» QualifiedEventsReceiver: Dienst-Schnittstelle (Service Interface) für den Empfang qualifizierter Ereignisse.
    • Methoden des Service-Lifecycles:
      • + Offer(): Aktiviert und publiziert die Service-Instanz des Empfängers (ara::com Service Offer).
      • + StopOffer(): Zieht die Service-Bereitstellung zurück.
    • Callback-Methode:
      • «aapCallbackMethod» + OnEventQualification(): Asynchrone Callback-Methode zur Übergabe des qualifizierten Security-Events vom IdsM an die Anwendung.
• Beziehungen:
  • Adaptive Application ⇢ QualifiedEventsReceiver (Interface Realization / gestrichelter Pfeil mit geschlossener, nicht ausgefüllter Spitze): Die Adaptive Application implementiert die Schnittstelle QualifiedEventsReceiver und stellt den Service-Endpunkt bereit.
  • Intrusion Detection System Manager ⇢ QualifiedEventsReceiver (Usage Dependency mit Stereotyp «use» / gestrichelter Pfeil mit offener Spitze): Der IdsM-Daemon bindet sich an den von der Applikation bereitgestellten Dienst und ruft bei Auftreten qualifizierter Events die Callback-Methode auf.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Registrierung & Bereitstellung:
   • Die Adaptive Application instanziiert das Skeleton des QualifiedEventsReceiver-Service-Interfaces.
   • Aufruf von Offer() publiziert die Service-Instanz über die zugrunde liegende IPC/Middleware (ara::com).
2. Service Discovery & Binding durch IdsM:
   • Der IdsM-Daemon findet die bereitgestellte Instanz via Service Discovery (FindService) und verbindet sich als Proxy-Konsument.
3. Event-Trigger & Benachrichtigung:
   • Nach interner Korrelation, Filterung und Verifikation eines Sicherheitsereignisses durch den IdsM triggert dieser die Benachrichtigung.
   • Der Aufruf erfolgt asynchron über OnEventQualification(), wodurch Kontextdaten des qualifizierten Ereignisses an die Applikation übergeben werden.
4. Terminierung:
   • Bei Shutdown oder De-Registrierung ruft die Applikation StopOffer() auf; der IdsM löst das Binding und verwirft anstehende Notifications für diesen Empfänger.

4. Normative Relevanz & Entwickler-Hinweise

• Umkehrung des Client-Server-Musters: Nicht die Anwendung fragt Ereignisse beim IdsM per Polling an, sondern implementiert als Provider das Service-Skeleton (QualifiedEventsReceiver). Entwickler müssen sicherstellen, dass die Skeleton-Instanz vor dem IdsM-Event-Routing fehlerfrei initialisiert und mit Offer() aktiviert ist.
• Nicht-blockierende Callback-Ausführung: Da OnEventQualification() mit dem Stereotyp «aapCallbackMethod» gekennzeichnet ist, darf der Handler im Anwendungskontext keine langwierigen oder blockierenden Operationen ausführen, um den Thread-Pool der Middleware bzw. die Event-Verarbeitungspipeline des IdsM nicht zu blockieren (Entkopplung über interne Anwendungs-Queues zwingend erforderlich).
• Manifest- & Rechtekonfiguration:
  • Im ARXML-Applikationsdesign müssen Service-Interfaces (ServiceContract), Provided Service Ports (PPortPrototype) und Service-Deployment (ara::com IPC-Bindings) für die Adaptive Application modelliert werden.
  • Berechtigungen (IAM / Execution Management) müssen so konfiguriert sein, dass der IdsM-Daemon auf die Service-Instanz der Anwendungsdomäne zugreifen darf.