Figure 12.55: Mapping to qualified event receiver

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Metamodell-Klassendiagramm (AUTOSAR Adaptive Platform Manifest Specification, Kapitel Deployment / Security).
• Architektur-Kontext: Intrusion Detection System Manager (IdsM) der AUTOSAR Adaptive Platform (AP). Das Diagramm spezifiziert das deklarative Deployment-Mapping (IdsmQualifiedEventReceiverMapping) zwischen einer plattformweiten IdsM-Instanziierung (IdsPlatformInstantiation), dem adressierten Laufzeit-Prozess (Process) und dem konkreten Empfänger-Port (RPortPrototype), über den qualifizierte Security-Events (QSEv) empfangen werden.

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Klassen & Hierarchien:

• IdsmQualifiedEventReceiverMapping
  • Spezialisierung von: UploadableDeploymentElement (Teil des manifestierten, updatefähigen Software-Deployments).
  • Rolle: Zentrales Konfigurations- und Mapping-Artefakt zur Verknüpfung von IdsM-Plattforminstanz, Prozesskontext und Empfänger-Port-Instanz.
• IdsPlatformInstantiation
  • Spezialisierung von: NonOsModuleInstantiation.
  • Rolle: Spezifische Instanziierung des IdsM-Plattformmoduls auf der Adaptive Machine.
• Process
  • Spezialisierung von: AbstractExecutionContext.
  • Rolle: Betriebssystem-Prozesskontext (POSIX-Prozess), in dem die empfangende Software-Komponente bzw. das Executable zur Laufzeit instanziiert wird.
• RPortPrototype
  • Spezialisierung von: AbstractRequiredPortPrototype.
  • Rolle: Client-/Empfänger-Port (Required Port) innerhalb der Software-Architektur des Executables zur Entgegennahme von IdsM-Events.
• IdsmQualifiedEventReceiverInterface
  • Spezialisierung von: IdsmAbstractPortInterface → PortInterface (welches wiederum von ARElement, AtpBlueprint, AtpBlueprintable, AtpType erbt).
  • Rolle: Formales Schnittstellen-Design für den Empfang qualifizierter Security-Events durch autorisierte Consumer/Sinks.

Assoziationen, Stereotypen & Kardinalitäten:

• IdsmQualifiedEventReceiverMapping → IdsPlatformInstantiation:
  • Rolle: +idsPlatformInstantiation, Kardinalität 0..1.
  • Semantik: Referenziert die IdsM-Plattforminstanz, welche die qualifizierten Events bereitstellt/routet.
• IdsmQualifiedEventReceiverMapping → Process:
  • Rolle: +process, Kardinalität 0..1.
  • Semantik: Bestimmt den Ziel-Prozesskontext, in dem der referenzierte Port existiert.
• IdsmQualifiedEventReceiverMapping → RPortPrototype:
  • Rolle: +rPortPrototypeInExecutable, Kardinalität 0..1.
  • Stereotyp: «instanceRef, atpUriDef».
  • Semantik: Kontextualisierte Instanzreferenz (Instance Reference via AUTOSAR URI-Definition) auf den konkreten RPortPrototype innerhalb des Executable-Hierarchiebaums.
• RPortPrototype → PortInterface:
  • Rolle: +requiredInterface, Kardinalität 0..1 mit Property {redefines atpType}.
  • Stereotyp: «isOfType».
  • Semantik: Typisiert den Port gegen das Interface (konkret IdsmQualifiedEventReceiverInterface).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein strukturelles Metamodell für den Generierungs- und Konfigurationszeitpunkt (Design-/Manifest-Time) handelt, existiert im Diagramm kein direkter Sequenzablauf. Die abgeleitete Laufzeitsemantik gestaltet sich wie folgt:

1. Initialisierung / Bindung: Beim Start des POSIX-Prozesses durch den Execution Management (EM) Stack bindet die ARA-Middleware (bzw. das IdsM-Framework) den generierten Empfänger-Proxy/Skeleton anhand des Manifest-Mappings an die IdsM-Plattforminstanz.
2. Event-Weiterleitung: Tritt im System ein qualifiziertes Security-Event auf (z. B. nach Filterung und Aggregation im IdsM), serialisiert/routet der IdsM-Dienst das Event IPC-basiert an den über +process und +rPortPrototypeInExecutable deklarierten Endpunkt.
3. Zustellung: Die Applikation empfängt das Event asynchron über die typisierte IdsmQualifiedEventReceiverInterface-C++-Methodik/Callback-Signatur.

4. Normative Relevanz & Entwickler-Hinweise

• Execution- & Service-Manifest (ARXML):
  • Konfigurationsverantwortliche müssen IdsmQualifiedEventReceiverMapping im Execution/Deployment-Manifest definieren, sobald eine Adaptive Application oder ein Plattform-Service qualifizierte IdsM-Events verarbeiten soll (z. B. Onboard-SIEM, Incident Handler oder Telematik-Uploader).
  • Durch das Stereotyp «instanceRef, atpUriDef» muss der Pfad zum RPortPrototype bezüglich des Executables/Root-SwComponent-Prototyps konsistent und über vollständige AUTOSAR-Instanzpfade (URIs) aufgelöst sein.
• Typ-Integrität:
  • Der referenzierte RPortPrototype muss zwingend über eine Spezialisierung von IdsmQualifiedEventReceiverInterface typisiert sein ({redefines atpType}). Fehlkonfigurationen (z. B. Binding an gewöhnliche ara::com-Interfaces ohne IdsM-Semantik) müssen vom Model-Validator / Code-Generator abgewiesen werden.
• Prozess-Isolation (POSIX):
  • Da Process (AbstractExecutionContext) referenziert wird, garantiert das Mapping dem Code-Generator und der Runtime die korrekte Allokation prozesslokaler IPC-Ressourcen (POSIX Domain Sockets / Shared Memory / ARA::COM-Bindings) zwischen der IdsM-Plattforminstanz und dem anwendungsseitigen Empfänger-Port.