Figure 3.71: 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), Zeitstempel (IdsmTimestampProviderInterface) oder Kontextdaten (IdsmContextProviderInterface) bereitstellen, den Reporting-Modus des IdsM konfigurieren (IdsmReportingModeProviderInterface) sowie qualifizierte Sicherheitsereignisse vom IdsM empfangen (IdsmQualifiedEventReceiverInterface).

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):
  • IdsmQualifiedEventReceiverInterface: Spezialisiert IdsmAbstractPortInterface. Typisiert Ports für Empfängerkomponenten, die vom IdsM qualifizierte und aggregierte Security Events zur Weiterleitung oder Persistierung entgegennehmen.
  • IdsmReportingModeProviderInterface: Spezialisiert IdsmAbstractPortInterface. Typisiert Ports, über die der Reporting-Modus des IdsM bereitgestellt oder gesteuert wird (z. B. Umschaltung des Detaillierungsgrads oder Aktivierungsstatus der Berichterstattung).
  • SecurityEventReportInterface: Spezialisiert IdsmAbstractPortInterface. Typisiert Ports von On-Board-Sensoren (SWCs, OS, Netzwerk-Stacks), um Security Events direkt an den IdsM zu übermitteln.
  • 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.

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. Reporting-Modus-Steuerung: Über ein IdsmReportingModeProviderInterface erhält der IdsM Vorgaben zum aktiven Reporting-Modus, wodurch das Weiterleitungs- und Filterverhalten zur Laufzeit beeinflusst wird.
2. Event-Triggering (asynchron/synchron): Eine Sensor-Komponente detektiert eine Sicherheitsanomalie (z. B. ungültige CAN-/Ethernet-Frames, Authentifizierungsfehler) und meldet das Event über einen RPort mit SecurityEventReportInterface an den IdsM (PPort).
3. 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.
4. Qualifizierung & Weitergabe: Der IdsM filtert und aggregiert das Ereignis zu einem qualifizierten Security Event und gibt dieses über ein IdsmQualifiedEventReceiverInterface an registrierte Empfänger 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, IdsmReportingModeProviderInterface, IdsmQualifiedEventReceiverInterface) verwendet werden.
  • Diese Interfaces werden als Typen für RPortPrototype bzw. PPortPrototype in AdaptiveApplicationSwComponentType referenziert, um IdsM-Kommunikationsendpunkte zu modellieren.