Figure 5.3: Interfaces required by Communication Management from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

UML-Komponenten- und Schnittstellendiagramm im Kontext der AUTOSAR Adaptive Platform (SWS Communication Management, Kapitel 5 „Dependencies to other Functional Clusters“). Es spezifiziert die funktionale Kopplung des daemon-basierten Communication Management (CM / ara::com) an den Intrusion Detection System Manager (IdsM) zur Meldung von sicherheitsrelevanten Vorfällen über eine standardisierte Plattform-Schnittstelle.

2. Komponenten, Entitäten & Schnittstellen

• Communication Management («aapFunctionalCluster», Tag daemon-based, hellblau): Konsumenten-Rolle; zentraler Daemon zur Abwicklung serviceorientierter Kommunikation (IPC, SOME/IP).
• Intrusion Detection System Manager («aapFunctionalCluster», Tag daemon-based, gelb): Provider-Rolle; nimmt Security Events (SEv) entgegen und führt Filterung sowie Aggregation durch.
• EventReporter («aapPortInterface,aapAPI»): Serviceorientiertes Schnittstellenelement mit der Operation + ReportEvent().
• Beziehungen:
  • Das Communication Management greift über eine gerichtete Nutzungsabhängigkeit («use», gestrichelter Pfeil mit offener Spitze) auf EventReporter zu.
  • Der Intrusion Detection System Manager implementiert EventReporter (UML-Schnittstellenrealisierung, gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Erkennung eines Kommunikations- oder Security-Verstoßes im Communication Management Daemon (z. B. unvollständige SOME/IP-Nachrichten, unautorisierter Dienstzugriff, fehlerhafte Serialisierung, PDU-Längenanomalien oder unplausible Adressmuster).
2. Aufruf: Der CM-Daemon bindet die Schnittstelle EventReporter und setzt den Methodenaufruf ReportEvent() ab. Dabei werden Ereignis-ID (Security Event Definition ID) und kontextbezogene Nutzdaten (wie Senderidentität, PDU-Header, Zeitstempel) übergeben.
3. Senke: Der IdsM-Daemon verarbeitet den Event gemäß konfigurierter Filter- und Qualifizierungsregeln zur Persistierung oder Weiterleitung an übergeordnete Instanzen.

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- und Deployment-Modell: Beide Functional Clusters sind als eigenständige Daemons (daemon-based) im POSIX-Betriebssystem modelliert. Der Aufruf ReportEvent() erfordert Interprozesskommunikation (IPC).
• Port-Modellierung: Das Interface ist als «aapPortInterface,aapAPI» deklariert; im ARXML-Modell ist für CM ein korrespondierender RPortPrototype und für den IdsM ein PPortPrototype vorzusehen.
• Blockierfreiheit: Der Aufruf von ReportEvent() darf den regulären Kommunikationsfluss des CM-Daemons (z. B. SOME/IP-Routing) nicht unzulässig blockieren; die Implementierung erfordert eine gepufferte bzw. nicht-blockierende Übergabe.