Figure 12.54: Mapping to reporting mode provider

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Ausschnitt (M2-Ebene) aus der AUTOSAR Adaptive Platform Spezifikation (AUTOSAR_AP_TPS_ManifestSpecification, Release R24-11).
• Technischer Zweck & funktionale Einordnung:
  • Deklaration des Deployment-Mappings für den Reporting Mode Provider des Intrusion Detection System Managers (IdsM).
  • Ermöglicht die formale Bindung zwischen der Plattform-Instanz des IdsM (IdsPlatformInstantiation) und einer anwendungsseitigen Port-Schnittstelle (RPortPrototype) innerhalb eines konkreten Betriebssystem-Prozesses (Process).
  • Steuert auf Plattformebene, über welchen Prozess und Port der IdsM über Betriebs- und Reporting-Modi (z. B. Drosselung, Pufferung oder Alarm-Reporting von Security Events / QSEvs) instruiert wird.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen & Stereotypen

• IdsmReportingModeProviderMapping: Konkretes Manifest-Element, spezialisiert UploadableDeploymentElement. Kapselt das Deployment-Binding für den Reporting-Mode-Provider.
• IdsPlatformInstantiation: Spezialisiert NonOsModuleInstantiation. Repräsentiert die Plattform-Instanz des IdsM-Daemons/Plattform-Services auf der Machine.
• Process: Spezialisiert AbstractExecutionContext. Repräsentiert die Prozessinstanz eines Executables im Adaptive Execution Manifest.
• RPortPrototype: Spezialisiert AbstractRequiredPortPrototype. Beschreibt den client-/anforderungsseitigen Port innerhalb des Software-Designs des Executables.
• IdsmReportingModeProviderInterface: Spezialisiert das abstrakte IdsmAbstractPortInterface (welches von PortInterface erbt; dieses wiederum implementiert ARElement, AtpBlueprint, AtpBlueprintable, AtpType). Definiert den typspezifischen Interaktionsvertrag für die Übermittlung des Reporting-Modes.

Beziehungen & Kardinalitäten

• IdsmReportingModeProviderMapping → IdsPlatformInstantiation:
  • Rollenname: +idsPlatformInstantiation
  • Kardinalität: 0..1 (unidirektionale Assoziation zur Ziel-Plattforminstanz).
• IdsmReportingModeProviderMapping → Process:
  • Rollenname: +process
  • Kardinalität: 0..1 (Assoziation zum ausführenden Prozesskontext).
• IdsmReportingModeProviderMapping → RPortPrototype:
  • Rollenname: +rPortPrototypeInExecutable
  • Kardinalität: 0..1
  • Stereotypen: «instanceRef,atpUriDef» (gezielter Instanzverweis mittels AUTOSAR-URI-Auflösung auf den Port-Prototyp im Kontext des Executables).
• RPortPrototype → PortInterface:
  • Rollenname: +requiredInterface
  • Kardinalität: 0..1, Eigenschaft {redefines atpType}, Stereotyp «isOfType» (Typisierung des R-Ports durch das Interface, konkret realisiert als IdsmReportingModeProviderInterface).

3. Dynamisches Verhalten & Sequenzablauf

• Metamodell-Charakter: Da es sich um ein strukturelles Metamodell für Manifeste handelt, zeigt das Diagramm keine zeitlichen Signalflüsse.
• Laufzeit- und Initialisierungssemantik:
  1. Manifest-Evaluation: Beim Booten der Adaptive Platform liest der IdsM-Daemon das Deployment-Manifest aus.
  2. Endpunkt-Bindung: Anhand von IdsmReportingModeProviderMapping lokalisiert der IdsM den Ziel-Process und den instanziierten RPortPrototype.
  3. Service-Kopplung: Der IdsM bindet die Kommunikationsendpunkte (IPC / Service-Interface).
  4. Modus-Steuerung: Bei Zustandsänderungen im System (z. B. Diagnosemodus, Fahrzeugstillstand, erkannte Anomalien) liefert der Provider-Prozess über das Interface geänderte Reporting-Parameter, welche die Filter-, Pufferungs- und Weiterleitungsstrategien von Qualified Security Events (QSEv) im IdsM rekonfigurieren.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML- / Manifest-Konfiguration:
  • Wird ein externer Prozess zur dynamischen Steuerung der IdsM-Reporting-Modi eingesetzt, muss im Deployment Manifest zwingend ein IdsmReportingModeProviderMapping als UploadableDeploymentElement modelliert werden.
  • Das Attribut rPortPrototypeInExecutable erfordert eine lückenlose «instanceRef»-Kette bis zum Port des Executables, der dem angegebenen Process zugeordnet ist.
• IdsM-Stack-Implementierung (Plattform-Ebene):
  • Ist die Kardinalität 0 (kein Mapping vorhanden), muss der IdsM auf einen statischen Default-Reporting-Modus zurückgreifen.
  • Bei vorhandenem Mapping (1) muss der IdsM-Daemon die Verbindung zu dem über den Prozess bereitgestellten Interface zur Laufzeit auflösen und überwachen.
• Applikations-Entwicklung (Reporting Mode Provider):
  • Der Entwickler des Provider-Prozesses muss sicherstellen, dass die Schnittstelle IdsmReportingModeProviderInterface semantisch korrekt implementiert und der entsprechende Port als RPortPrototype im Software-Component- bzw. Executable-Modell exponiert ist.