Figure 10.53: Mapping to context provider

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-2.0-Klassendiagramm (AUTOSAR M2-Metamodell).
• Kontext & Zweck: Spezifiziert im AUTOSAR Adaptive Platform Manifest (AUTOSAR_AP_TPS_ManifestSpecification, Kapitel 10, Bezug: RS_MANI_00069, TPS_MANI_01441). Das Diagramm definiert das Metamodell für das Deployment des Intrusion Detection System Managers (IdsM). Es modelliert die semantische und instanzbezogene Bindung eines Applikations- oder Plattform-Ports (PPortPrototype), der Sicherheitskontextdaten liefert (IdsmContextProviderInterface), an den zugehörigen Ausführungskontext (Process oder IdsPlatformInstantiation).

2. Komponenten, Entitäten & Schnittstellen

Metaklassen und Schnittstellenhierarchie (M2)

• PortInterface (Generalisierung: ARElement, AtpBlueprint, AtpBlueprintable, AtpType):
  • Abstrakter Basistyp für alle Port-Schnittstellen im AUTOSAR-Metamodell.
• IdsmAbstractPortInterface (spezialisiert PortInterface):
  • Abstrakte Basisschnittstelle für IdsM-spezifische Interaktionsmuster.
• IdsmContextProviderInterface (spezialisiert IdsmAbstractPortInterface):
  • Konkretes Interface zur Definition von Kontext-Provider-Operationen für IdsM-Sicherheitsereignisse (Security Events).
• PPortPrototype (spezialisiert AbstractProvidedPortPrototype):
  • Bereitgestellter Port an einem Executable/Software-Component-Prototype.
  • Beziehung zu PortInterface: +providedInterface 0..1 {redefines atpType} mit Stereotyp «isOfType». Typisiert den Port typischerweise mit IdsmContextProviderInterface.

Ausführungskontexte

• AbstractExecutionContext:
  • Abstrakte Basisklasse für Rechen- und Ablaufkontexte auf der Adaptive Platform.
• Process (spezialisiert AbstractExecutionContext):
  • Repräsentiert einen konkreten POSIX-Laufzeitprozess eines Executables auf einer Adaptive Machine.
• NonOsModuleInstantiation:
  • Abstrakte Basisklasse für Plattformmodule außerhalb der Standard-POSIX-Prozessabstraktion.
• IdsPlatformInstantiation (spezialisiert NonOsModuleInstantiation):
  • Konkrete Instanziierung des IdsM-Plattform-Stacks auf System-/Machine-Ebene.

Deployment & Mapping

• UploadableDeploymentElement:
  • Basisklasse für Manifest-Elemente, die als Teil von Software-Paketen deploybar/aktualisierbar sind.
• IdsmContextProviderMapping (spezialisiert UploadableDeploymentElement):
  • Zentrales Mapping-Element zur Bindung des Ports an den Laufzeitkontext.
  • Assoziationen & Kardinalitäten:
    • +pPortPrototypeInExecutable [0..1]: Gerichtete Assoziation auf PPortPrototype mit Stereotypen «instanceRef,atpUriDef». Adressiert den Port instanzgenau innerhalb eines Executables über URI-basierte Modellreferenzen.
    • +process [0..1]: Gerichtete Referenz auf den zugehörigen Applikationsprozess (Process).
    • +idsPlatformInstantiation [0..1]: Alternative gerichtete Referenz auf eine plattformweite Instanz (IdsPlatformInstantiation).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches M2-Strukturmodell handelt, ist kein Sequenzablauf direkt im Diagramm enthalten. Das abgeleitete Laufzeitverhalten gestaltet sich wie folgt:

1. Manifest-Parsen & Binding: Beim Starten der Machine bzw. des Process durch das Execution Management (EM) wertet der IdsM-Core das IdsmContextProviderMapping aus.
2. Context Provider Resolution: Über die instanceRef (pPortPrototypeInExecutable) wird der IPC-Endpunkt des Prozesses aufgelöst, der das IdsmContextProviderInterface implementiert.
3. Security Event Enrichment (IdsM-Laufzeit): Tritt ein Security Event auf, fordert der IdsM über die bereitgestellte Schnittstelle zusätzliche Umgebungsdaten (z. B. Task-/Thread-ID, Nutzerkontext, Prozessstatus) vom Context Provider an.
4. Kontext-Zuordnung: Durch die Verknüpfung mit Process oder IdsPlatformInstantiation wird das Event im IdsM eindeutig dem Verursacher bzw. Ausführungskontext zugeordnet, bevor ein Qualified Security Event (QSEv) serialisiert und via IdsR (IdsM Reporter) weitergeleitet wird.

4. Normative Relevanz & Entwickler-Hinweise

• Exklusivität der Bindung (TPS_MANI_01441):
  • IdsmContextProviderMapping muss semantisch konsistent konfiguriert werden: Der Port darf im selben Mapping nicht gleichzeitig an Process und IdsPlatformInstantiation gebunden werden (gegenseitiger Ausschluss je nach Applikations- vs. Plattform-Kontext).
• Applikations-Entwicklung (Adaptive Application):
  • Stellt eine Anwendung Sicherheitskontexte für IdsM bereit, muss ihr Software-Design einen PPortPrototype mit Typisierung («isOfType») auf IdsmContextProviderInterface enthalten. Der entsprechende C++-Skelett-/Service-Handler muss implementiert werden.
• Manifest- & Integrations-Konfiguration:
  • Das Mapping ist Teil des Execution Manifests bzw. Service Instance Manifests.
  • Verwendung von «instanceRef,atpUriDef»: Erfordert im ARXML eine vollständige Pfadauflösung (context-Hierarchie) bis zum PPortPrototype im jeweiligen Executable.
• IdsM-Stack & Codegeneratoren:
  • Generatoren nutzen dieses Mapping zur Erzeugung statischer Dispatch-Tabellen oder IPC-Proxies im IdsM-Daemon, um Kontext-Abfragen ohne dynamische Dienstsuche deterministisch an den jeweiligen OS-Prozess zu routen.