Figure 3.68: Abstract base-class IdsmAbstractPortInterface

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm (M2-Metamodellauszug der AUTOSAR Adaptive Platform).
• Technischer Zweck: Modellierung der Vererbungshierarchie für Port-Interfaces im Kontext des Intrusion Detection System Manager (IdsM).
• Architektur-Kontext: Definition der spezialisierten Schnittstellentypen, über die Adaptive Applications oder Plattformdienste sicherheitsrelevante Ereignisse an den IdsM melden (SecurityEventReportInterface) sowie Zeitstempel (IdsmTimestampProviderInterface) oder Kontextdaten (IdsmContextProviderInterface) für forensische Sicherheitsanalysen bereitstellen.

2. Komponenten, Entitäten & Schnittstellen

• PortInterface (Abstrakte Basisklasse):
  • Stereotypen: «ARElement», «AtpBlueprint», «AtpBlueprintable», «AtpType».
  • Funktion: Grundlegendes Metamodellelement zur Modellierung von typisierten Port-Schnittstellen. Durch «ARElement» ist es als eigenständiges Artefakt in einem ARPackage deklarierbar.
• IdsmAbstractPortInterface (Abstrakte Basisklasse):
  • Spezialisierung: Erbt via Generalisierung von PortInterface.
  • Funktion: Gemeinsamer abstrakter Basistyp für alle IdsM-spezifischen Port-Schnittstellen im Manifest-Metamodell.
• Spezialisierte Schnittstellen (Konkrete Metaklassen):
  • IdsmTimestampProviderInterface: Spezialisiert IdsmAbstractPortInterface. Typisiert Ports, über die der IdsM Zeitstempel abfragt, um Sicherheitsereignisse manipulationssicher zu synchronisieren/datieren.
  • IdsmContextProviderInterface: Spezialisiert IdsmAbstractPortInterface. Typisiert Ports, über welche der IdsM erweiterte Laufzeit- und Umgebungskontexte (z. B. Fehlerspeicher-Zustand, Netzwerkstatus) zur Anreicherung gemeldeter Events anfordert.
  • SecurityEventReportInterface: Spezialisiert IdsmAbstractPortInterface. Typisiert Ports von On-Board-Sensoren (SWCs, OS, Netzwerk-Stacks), um Security Events direkt an den IdsM zu übermitteln.

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Metamodell-Klassendiagramm handelt, ist kein Sequenzfluss direkt dargestellt. Aus den Schnittstellen resultiert folgendes Laufzeitverhalten:

1. Event-Triggering (asynchron/synchron): Eine Komponente detektiert eine Sicherheitsanomalie (z. B. ungültige CAN-/Ethernet-Frames, Authentifizierungsfehler) und triggert über einen RPort mit SecurityEventReportInterface die Meldung an den IdsM (PPort).
2. Kontext- und Zeitstempel-Abfrage:
   • Falls konfiguriert, ruft der IdsM synchron oder asynchron über ein IdsmTimestampProviderInterface einen qualifizierten Zeitstempel ab.
   • Der IdsM pollt bzw. ruft Callback-Methoden über ein IdsmContextProviderInterface auf, um systemspezifische Zustandsdaten vor der Persistierung/Weiterleitung zu erfassen.
3. Filterung & Aggregation: Der IdsM filtert (Thresholding/Sampling), aggregiert das Event und leitet es an das Security Event Memory (SEM) oder das Backend weiter.

4. Normative Relevanz & Entwickler-Hinweise

• Modellierung im ARXML-Manifest:
  • Entwickler dürfen IdsmAbstractPortInterface nicht direkt instanziieren (Abstraktionsgrad im Metamodell). Es müssen die konkreten Subtypen (SecurityEventReportInterface, IdsmContextProviderInterface, IdsmTimestampProviderInterface) verwendet werden.
  • Diese Interfaces werden als Typen für RPortPrototype bzw. PPortPrototype in AdaptiveApplicationSwComponentType referenziert.
• API- und Stack-Generierung:
  • Generatoren erzeugen aus diesen Definitionen die C++-Klassen/Proxy-Skeleton-Architektur bzw. die AUTOSAR Runtime for Adaptive Applications (ara::core / ara::idsm).
• Konfigurationsbindungen:
  • Jedem SecurityEventReportInterface müssen die entsprechenden Security Event IDs (SEv-Definitionen) über das System- bzw. Applikationsmanifest zugeordnet werden.
  • Anbieter von Kontext oder Zeitstempeln müssen deterministische Antwortzeiten garantieren, um Latenzen in der IdsM-Pipeline zu vermeiden.