Figure 14.11: Mapping of the interaction between a Functional Cluster and the IdsM

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR-Metamodell-Ausschnitt (M2, UML-Klassendiagramm).
• Technischer Zweck: Modellierung der Schnittstellen- und Interaktionsbeziehung zwischen einem Functional Cluster (FC) der Adaptive Platform und dem Intrusion Detection System Manager (IdsM) gemäß AUTOSAR_AP_TPS_ManifestSpecification (Kapitel 14, R23-11).
• Funktionale Einordnung: Dient der formalen Zuordnung von Sicherheitsereignissen (SecurityEventDefinition) zu konkreten Instanzen von Plattformmodulen bzw. Functional Clustern (AdaptiveModuleInstantiation), damit sicherheitsrelevante Ereignisse standardisiert an den IdsM gemeldet und dort aggregiert, gefiltert und weitergeleitet werden können (Anforderungsbezug: RS_MANI_00023, TPS_MANI_03324).

2. Komponenten, Entitäten & Schnittstellen

• FunctionalClusterToSecurityEventDefinitionMapping
  • Metamodell-Einordnung: Konkrete Mapping-Klasse; spezialisiert die abstrakte Metaklasse FunctionalClusterInteractsWithFunctionalClusterMapping.
  • Semantik: Bildet die Kopplungsentität zwischen einem meldenden Plattform-Cluster und der Sicherheitsereignis-Definition des IdsM ab.
• AdaptiveModuleInstantiation
  • Metamodell-Einordnung: Abstrakte Metaklasse (kursiv), abgeleitet von AtpStructureElement.
  • Semantik: Repräsentiert die Bereitstellung/Instanziierung eines konkreten Functional Clusters auf einer Ziel-Maschine.
  • Beziehung: Wird von FunctionalClusterToSecurityEventDefinitionMapping über die gerichtete Referenz +moduleInstantiation mit Kardinalität 0..1 adressiert.
• SecurityEventDefinition
  • Metamodell-Einordnung: Konkrete Metaklasse, abgeleitet von IdsCommonElement.
  • Semantik: Definiert den Typ und die Eigenschaften des Sicherheitsereignisses für das Intrusion Detection System.
  • Attribute: + id: PositiveInteger [0..1] – Eindeutiger Identifikator des Security Events innerhalb des IdsM-Kontexts.
  • Beziehung: Wird über die gerichtete Referenz +securityEvent mit Kardinalität 0..1 referenziert.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Modell-Charakter: Rein statisches Deklarationsmodell (keine direkten Ablaufpfade im M2-Diagramm dargestellt).
• Laufzeit-Korrelation:
  1. Detektion: Der über AdaptiveModuleInstantiation instanziierte Functional Cluster (z. B. IAM, Execution Management oder Communication Management) detektiert zur Laufzeit eine Security-Anomalie.
  2. Reporting: Der FC ruft synchron die IdsM-Client-API (ReportSecurityEvent) mit der über SecurityEventDefinition.id konfigurierten Event-ID auf.
  3. Verarbeitung: Der IdsM-Cluster nimmt das Event entgegen, wendet Filterregeln an (Sampling, Thresholding) und leitet qualifizierte Security Event Packages (SEvP) an persistente Speicher oder das On-Board/Off-Board-Backend weiter.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration:
  • Integratoren müssen für jeden Functional Cluster, der Security Events emittieren darf, ein FunctionalClusterToSecurityEventDefinitionMapping im Adaptive-Manifest (System Description / Machine Manifest Context) anlegen.
  • Sowohl moduleInstantiation als auch securityEvent sind modellseitig mit 0..1 optional; für eine funktionale Bindung (TPS_MANI_03324) müssen zur Validierungszeit beide Referenzen aufgelöst sein.
• Toolchain & Codegenerierung:
  • Generatoren leiten aus SecurityEventDefinition.id symbolische Konstanten (Header/Type-Definitionen) für den Quellcode des Functional Clusters ab.
  • Die IdsM-Konfiguration nutzt das Mapping zur Dimensionierung von Event-Puffern, Filterparametern und Authentifizierungsregeln pro Modulinstanz.
• Restriktionen:
  • Die id muss im adressierten IdsM-Namensraum eindeutig sein, um Fehlzuordnungen von Angriffsmustern in der SIEM-Auswertung zu verhindern.