Figure 5.3: Communication Group Abstract for State Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm (Component Diagram mit Paket-Tag cmp Later).
• Dokumentenkontext: AUTOSAR Adaptive Platform (Release R22-11), Spezifikationsdokument AUTOSAR_EXP_ARAComAPI (Explanation of ara::com API).
• Funktionale Einordnung: Konzeptionelle Darstellung einer Gruppenabstraktion („Communication Group Abstract“) zwischen State Management (SM) und der Kommunikations-Middleware (COM / ara::com). Der Paket-Präfix cmp Later kennzeichnet ein weiterführendes Entwurfsmuster zur Entkopplung: State Management steuert und überwacht den Energie-/Ausführungsmodus (ApplicationPowerMode) nicht über direkte Punkt-zu-Punkt-Verbindungen zu jedem Prozess, sondern aggregiert über die Kommunikationsschicht für eine Gruppe aktiver Clients.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Akteure:
  • SM (State Management): Funktionale Cluster-Komponente der Adaptive Platform Foundation zur Orchestrierung von Maschinen-, Funktionsgruppen- und Applikationszuständen.
  • COM (ara::com / Communication Management): Middleware-Daemon bzw. Kommunikationsschicht, die als Vermittler und Aggregator für Kommunikationsgruppen fungiert.
  • Active Client 1, Active Client 2, Active Client 3: Adaptive Applications (AAs) bzw. Service-Endpunkte, die zu einer gemeinsamen Ausführungs- oder Power-Gruppe gehören.
• Ports & Schnittstellen:
  • Port ApplicationPowerMode: An SM und an den Clients modellierter Port zur Übertragung von Soll-/Ist-Zuständen des Leistungs- und Kommunikationsmodus.
• Beziehungen, Assoziationen & Datenflüsse:
  • SM ↔ COM: Bidirektionale Abhängigkeit (gestrichelte Linie mit Pfeilen an beiden Enden). Austausch von aggregierten Client IDs (1:n-Menge) und dem zugehörigen Gruppenmodus ApplicationPowerMode.
  • COM ↔ Active Client [1..3]: Bidirektionale Abhängigkeiten (gestrichelte Pfeile). 1:1-Zuordnung je Client über die individuelle Client ID zur individuellen Signalisierung und Rückmeldung des ApplicationPowerMode.

3. Dynamisches Verhalten & Sequenzablauf

• Top-Down-Modussteuerung (SM → COM → Clients):
  1. Trigger: State Management fordert einen Zustandswechsel für eine Applikationsgruppe an (z. B. Übergang in einen reduzierten Betriebsmodus / Suspend / Standby).
  2. Gruppenauflösung: SM adressiert die Anforderung über COM für die Menge der zugeordneten Client IDs.
  3. Verteilung: COM dispatcht die ApplicationPowerMode-Änderung parallel oder sequenziell an die registrierten Endpunkte (Active Client 1..3) unter Verwendung der jeweiligen Client ID.
• Bottom-Up-Quittierung & Registrierung (Clients → COM → SM):
  1. Client-Registrierung: Clients melden sich bei der Initialisierung mit ihrer eindeutigen Client ID an der Kommunikationsgruppe in COM an.
  2. Statusquittung: Jeder Client bestätigt das Erreichen des angeforderten ApplicationPowerMode asynchron an COM.
  3. Aggregation: COM konsolidiert die Rückmeldungen der einzelnen Client IDs und meldet den aggregierten Gruppenstatus an SM zurück.
• Interaktionscharakter: Asynchrone Interprozess-Kommunikation (IPC / Skeleton-Proxy-Mechanismen), entkoppelt von synchronen blockierenden Aufrufen.

4. Normative Relevanz & Entwickler-Hinweise

• Architekturmuster & Entkopplung: Applikationsentwickler implementieren keine proprietären SM-Steuerkanäle. Die Steuerung von Kommunikationsbereitschaft und Power-Modes erfolgt über standardisierte Middleware-Events/Zustände der Plattform.
• Status des Diagramms (cmp Later / EXP-Dokument): Als Bestandteil eines „Explanation“-Dokuments (EXP_ARAComAPI) und gekennzeichnet mit cmp Later besitzt das Schaubild informativen, designleitenden Charakter und definiert keine bindenden SWS-Anforderungen (keine expliziten SWS-Item-IDs).
• Identifikatoren-Management (Client ID): Für Middleware- und Integrationsentwickler erfordert dieses Muster eine konsistente Zuweisung deterministischer Client IDs über die Bereitstellungsbeschreibungen (Execution Manifest / Service Instance Manifest).
• Fehlerbehandlung: Implementierungen des Aggregators in COM müssen Timeouts und Deadlock-Strategien vorsehen (z. B. wenn ein Active Client nicht auf die ApplicationPowerMode-Umschaltung reagiert), um eine Blockade des gesamten SM-Zustandsübergangs zu verhindern.