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

1. Diagrammtyp & Architektur-Kontext

UML-Komponenten- und Schnittstellendiagramm der AUTOSAR Adaptive Platform (SWS Communication Management, Kapitel 5 „Dependencies to other Functional Clusters“). Es dokumentiert die funktionalen Cluster-Abhängigkeiten des daemon-basierten Communication Management gegenüber dem Intrusion Detection System Manager (IdsM) sowie dem Execution Management (EM).

2. Komponenten, Entitäten & Schnittstellen

• Communication Management («aapFunctionalCluster», Tag daemon-based, hellblau): Konsumenten-Daemon mit zwei ausgehenden «use»-Abhängigkeiten.
• Schnittstellen:
  • EventReporter («aapPortInterface,aapAPI»): Serviceorientiertes Interface mit der Operation + ReportEvent().
  • ExecutionClient («aapAPI,aapNativeInterface»): Native Programmierschnittstelle (ara::exec::ExecutionClient) mit den Operationen + Create() (statische Factory-Methode, unterstrichen) und + ReportExecutionState(ExecutionState).
• Realisierende Functional Clusters:
  • Intrusion Detection System Manager («aapFunctionalCluster», Tag daemon-based, gelb): Realisiert EventReporter.
  • Execution Management («aapFunctionalCluster», Tag daemon-based, rot): Realisiert ExecutionClient.

3. Dynamisches Verhalten & Sequenzablauf

1. Prozessinitialisierung & Lebenszyklusmeldung:
   • Beim Start instanziiert der CM-Daemon über die statische Methode ExecutionClient::Create() ein lokales Client-Objekt.
   • Sobald die internen Kommunikationsdienste (z. B. SOME/IP-Daemon, plattforminterne IPC-Kanäle) initialisiert und empfangsbereit sind, meldet der CM-Daemon seinen Betriebszustand über ReportExecutionState(ExecutionState::kRunning) an das Execution Management.
   • Bei geordneter Terminierung wird analog ein entsprechender Endzustand an EM gemeldet.
2. Sicherheitsüberwachung:
   • Tritt während des laufenden Betriebs ein sicherheitsrelevantes Ereignis (z. B. Protokollverletzung, unautorisierter Service-Zugriff, PDU-Framing-Fehler) auf, ruft der CM-Daemon EventReporter::ReportEvent() auf.
   • Der Intrusion Detection System Manager nimmt das Ereignis entgegen, filtert und aggregiert es.

4. Normative Relevanz & Entwickler-Hinweise

• Lifecycle-Pflicht (ara::exec): Da Communication Management als eigenständiger Prozess (daemon-based) betrieben wird, muss die Zustandsmeldung via ExecutionClient::ReportExecutionState() verbindlich erfolgen, um Watchdog-Timeouts oder Prozessabbrüche durch das Execution Management zu verhindern.
• Koexistenz von Schnittstellentypen: Veranschaulicht die Kombination einer nativen Programmierschnittstelle (ExecutionClient als «aapAPI,aapNativeInterface» im Adressraum des Daemons) mit einem serviceorientierten Port-Interface (EventReporter als «aapPortInterface,aapAPI»).
• Deployment & Konfiguration: Erfordert im Execution Manifest die Definition des entsprechenden Prozesses inklusive Startup-Konfiguration für EM sowie die Bereitstellung eines RPortPrototype für EventReporter zur Interaktion mit dem IdsM-Daemon.