Figure 5.4: StateMachine interactions

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Prozessarchitekturdiagramm (Process & Platform Interaction Overview).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R25-11; Spezifikation AUTOSAR_AP_EXP_InterfacesGuidelines (Kapitel 5: State Management Architecture).
• Funktionale Einordnung: Dargestellt ist die übergeordnete Prozess- und Interaktionstopologie des Functional Clusters State Management (SM). Es fungiert als zentraler Plattformkoordinator zwischen Anwendungsdomänen (Adaptive Application), Plattformdiensten (Platform Process) und dem zugrundeliegenden Betriebssystem (Operating system), abstrahiert von konkreten API-Methodensignaturen.

2. Komponenten, Entitäten & Schnittstellen

Zentrale Steuerungseinheit

• State Management («Platform Process»): Zentraler Plattformprozess zur Koordination der System- und Plattformzustände (hellblaue Box).

Plattformprozesse («Platform Process»)

• Execution Manager: Plattformdienst zur Prozesssteuerung, Funktionsgruppenverwaltung und Ausführungskontrolle.
• Platform Health Manager: Plattformdienst zur Laufzeit- und Integritätsüberwachung (Alive-, Deadline-, Logical Supervision).
• Network Manager: Plattformdienst zur Verwaltung der Kommunikationsnetze und Partial Network Clusters (PNCs).
• Update and Configuration Manager: Plattformdienst zur Orchestrierung von Software-Updates, Installationen und Plattform-Rekonfigurationen.

Adaptive Applications («Adaptive Application»)

• SmControlApplication: Spezifische Steuerungsanwendung zur Interaktion mit dem State Management (Zustandsanforderungen und Rückmeldungen).
• Application: Reguläre Adaptive Anwendung, die Statusinformationen und Benachrichtigungen vom State Management empfängt.

Systemebene

• Operating system: Nicht-stereotypisierter Systembaustein (POSIX OS / Kernel), der grundlegende Betriebssystemfunktionen für das State Management bereitstellt.

Interaktionsbeziehungen

• Bidirektionale Kanten: Zwischen State Management und sämtlichen Plattformprozessen (Execution Manager, Platform Health Manager, Network Manager, Update and Configuration Manager), dem Operating system sowie der SmControlApplication.
• Unidirektionale Kante: Vom State Management ausgehend zur generischen Application.

3. Dynamisches Verhalten & Sequenzablauf

1. Anforderungs- und Steuerungsinteraktion (Bidirektional):
   • SmControlApplication interagiert bidirektional mit dem State Management, um übergeordnete Funktions- und Betriebszustände anzufordern und Zustandsquittierungen zu erhalten.
2. Plattformkoordination & Orchestrierung (Bidirektional):
   • Execution Manager: Wechselseitige Abstimmung für das Umschalten von Funktionsgruppen und Maschinenmodi sowie Rückmeldung von Prozessstatus.
   • Platform Health Manager: Austausch von Fehlerindikatoren, Health-Status und deterministischen Recovery-Aktionen.
   • Network Manager: Koordination aktiver Netzwerkmodi (Full-Com / Silent-Com / PNCs) und Rückmeldung von Netzwerkanforderungen.
   • Update and Configuration Manager: Abstimmung über Update-Sitzungen, Vorbereitung von Wartungszuständen und Aktivierung neuer Softwareversionen.
   • Operating system: Direkte Interaktion des State Management mit OS-Diensten (z. B. System-Shutdown, Core-Power-Management, POSIX-Signalbehandlung).
3. Applikationsbenachrichtigung (Unidirektional):
   • Das State Management informiert nachgelagerte Anwendungen (Application) unidirektional über Zustandstransitionen und Plattformereignisse.

4. Normative Relevanz & Entwickler-Hinweise

• Architektonische Rollentrennung: Klare Trennung der Prozessebenen über die Stereotypen «Adaptive Application» (Anwendungsraum) und «Platform Process» (Basisplattformdienste).
• Abstraktion von Methodenebene: Das Diagramm verzichtet auf konkrete API-Signaturen (ara::com, ara::exec::StateClient) zugunsten einer konzeptionellen Interaktionsarchitektur, wodurch Implementierungsdetails entkoppelt werden.
• Betriebssystemintegration: Die explizite Einbindung von Operating system verdeutlicht, dass das State Management neben Plattform-Clustern auch direkte Kernel-/OS-Schnittstellen (wie Shutdown, Reboot oder Watchdog-Anbindung) nutzt.
• Entwickler-Leitlinie: Anwendungsentwickler (Application) konsumieren ausschließlich Zustandsinformationen, während dedizierte Steuerapplikationen (SmControlApplication) oder Plattform-Manager die Systemzustände über standardisierte Cluster-Protokolle aktiv beeinflussen.