Figure 7.6: SMControlApplication and StateManagement Process started together

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Struktur- und Architektur-Deployment-Diagramm mit AUTOSAR-Adaptive-Metamodell-Stereotypen (<<FunctionGroup>>, <<FunctionGroupState>>, <<Process>>, <<StateMachine>>).
• Funktionale Einordnung: Veranschaulicht das gemeinsame Deployment und Startverhalten des Plattformprozesses State Management und einer übergeordneten Steuerungsapplikation (SMControl Application) innerhalb desselben Funktionsgruppenzustands sowie die daraus resultierende Kontroll- und Verwaltungshierarchie über andere Funktionsgruppen im AUTOSAR-Adaptive-System.

2. Komponenten, Entitäten & Schnittstellen

• <<FunctionGroup>> D: Übergeordnete funktionale Gruppe (Instanziierungs- und Lebenszyklusbereich für Plattform- und Basiskomponenten).
  • <<FunctionGroupState>> A: Spezifischer Ziel- und Betriebszustand von FunctionGroup D.
• <<Process>> State Management: Ausführbare Prozessinstanz des State-Management-Clusters (AP Core).
  • <<StateMachine>>: Gekapselter, interner Zustandsautomat innerhalb des State-Management-Prozesses zur Regelauswertung, Transitionsüberwachung und Arbitrierung.
• <<Process>> SMControl Application: Separater Prozess (typischerweise OEM-/Applikations-Logik wie z. B. Mode Request Coordinator, Power State Handler oder Vehicle State Manager).
• <<FunctionGroup>> A: Unabhängige, funktionale Zielgruppe (z. B. Applikationscluster oder Subsystem).
  • <<FunctionGroupState>> B: Konkreter Betriebsmodus/Zustand von FunctionGroup A.
• Schnittstellen & Beziehungen:
  • <<control>>: Gerichtete Kontrollbeziehung von SMControl Application auf die interne <<StateMachine>> von State Management (Zustandsanforderungen, Trigger, Ereignismeldungen via IPC/ara::com).
  • <<manage>>: Gerichtete Managementbeziehung von der <<StateMachine>> (via State Management) auf <<FunctionGroup>> A / <<FunctionGroupState>> B (Steuerung via Execution Management API).

3. Dynamisches Verhalten & Sequenzablauf

1. Gemeinsamer Start (Co-Start):
   • Das Execution Management (EM) schaltet FunctionGroup D in den FunctionGroupState A.
   • Beide Prozesse (State Management und SMControl Application) werden in diesem Zustand simultan bzw. deterministisch gemäß ExecutionManifest gestartet.
2. Initialisierung & Bereitschaftsmeldung:
   • Beide Prozesse durchlaufen ihre Initialisierung und melden ihre Betriebsbereitschaft via ara::exec::ApplicationClient::ReportApplicationState(ApplicationState::kRunning) an das EM.
3. Trigger-Phase (<<control>>):
   • SMControl Application ermittelt intern oder über externe Busnachrichten (z. B. CAN/LIN/Ethernet) einen Zustandswechselbedarf.
   • Die Applikation sendet einen State-Request/Trigger an den State Management-Prozess.
4. Zustandstransition (<<StateMachine>>):
   • Der interne Zustandsautomat prüft Guards, Sicherheitsbedingungen, Timeouts und Vorbedingungen.
5. Funktionsgruppensteuerung (<<manage>>):
   • State Management initiiert über den ara::exec::StateClient (Methode SetState) den asynchronen Wechsel von FunctionGroup A in den FunctionGroupState B.
   • State Management überwacht die Rückmeldung (ara::core::Future) des Execution Managements über den erfolgreichen Abschluss aller Prozess-Aktivierungen/Terminierungen innerhalb von FunctionGroup A.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration (ProcessExecutionManifest):
  • Sowohl State Management als auch SMControl Application müssen in ihren jeweiligen Process-Modellen der identischen ModeDeclarationGroup (FunctionGroup D) und dem Zustand FunctionGroupState A zugeordnet werden.
  • Fehlt die synchrone Deklaration im Manifest, startet das EM die Prozesse zeitversetzt oder in unterschiedlichen Systemphasen, was zu Timeout-Fehlern führt.
• Startup-Synchronisation & Verbindungsaufbau (<<control>>):
  • Da beide Prozesse gleichzeitig hochfahren, darf SMControl Application nicht von einer sofortigen Verfügbarkeit des State-Management-Dienstes ausgehen.
  • Implementierungspflicht: Asynchrones Service-Matching via ara::com::runtime::ResolveService bzw. FindService-Handler mit Retry-Mechanismus oder verzögerter Triggerung erst nach Erhalt des Service-Availability-Events.
• API-Verträge:
  • Interaktion <<manage>> erfordert funktionale Berechtigungen für den State Management-Prozess zur Nutzung von ara::exec::StateClient auf FunctionGroup A.
  • Applikative Prozesse dürfen ara::exec::StateClient normativ nicht direkt aufrufen; alle Funktionsgruppen-Zustandswechsel müssen über den zentralen Arbitrierungs- und State-Machine-Pfad des State Managements kanalisiert werden.
• Sicherheits- & Architektur-Isolation (ASIL):
  • Die physische Trennung in zwei <<Process>>-Entitäten erlaubt unterschiedliche ASIL-Einstufungen sowie Speicherschutz (MMU) zwischen generischem AUTOSAR-Plattform-Stack (State Management) und fahrzeugspezifischer Kundenlogik (SMControl Application).