Figure 7.37: Start-up Sequence to Initial State or ContinueUpdate state

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML 2.x Sequenzdiagramm (Interaktionsdiagramm) mit Interaktionsrahmen (Startup) und kombiniertem Fragment (alt für bedingte Verzweigungen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R24-11), Spezifikation AUTOSAR_AP_SWS_StateManagement (SM).
• Funktionale Einordnung: Spezifiziert die deterministische Initialisierungs- und Anlaufsequenz des State-Management-Daemons (ara::sm) beim Booten der Adaptive Machine. Das Diagramm definiert das Laufzeitverhalten an der Schnittstelle zwischen Execution Management (ara::exec), Persistenz (ara::per), dem Update and Configuration Management (ara::ucm) sowie den serviceorientierten Kommunikationsschnittstellen (ara::com).

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Stereotypen:
  • «API» ExecutionClient: Lokale C++-Klassenbibliothek (ara::exec::ExecutionClient), über die ein Prozess seinen Lebenszyklusstatus an das Execution Management meldet.
  • «Process» State Management: Der zentrale Adaptive-Core-Prozess zur Verwaltung von Systemzuständen, Function Groups und Regelausführungen.
  • «State Machine» Controller: Interne Steuerungsinstanz/Zustandsmaschine innerhalb des SM-Prozesses, zuständig für Transitionen und Abarbeitung von Aktionslisten.
  • «Service» StateMachineService: Bereitgestellte ara::com-Dienstschnittstelle (Service Interface / Skeleton) zur aktiven Zustandsbeeinflussung durch autorisierte Client-Applikationen (SMControlApplication).
  • «Service» StateMachineNotification: Bereitgestellte ara::com-Dienstschnittstelle (Field/Event-basiert) für Broadcasts und Statusbenachrichtigungen an externe Konsumenten.
• Kardinalitäten & Beziehungen:
  • 1:1-Bindung zwischen State Management und internem Controller.
  • 1:n-Beziehung zu SMControlApplication-Clients über das Service-Interface StateMachineService.
  • Synchrone Methodenaufrufe prozessintern (start()), synchrone Interprozess-Meldung via API (Report()), asynchrone Service-Discovery-Veröffentlichung (offer()).

3. Dynamisches Verhalten & Sequenzablauf

1. Pre-Check (Update-Session-Abfrage):
   • SM führt prozessintern RetrieveUpdateSessionStatus() aus. Gemäß SWS_SM_00204 wird geprüft, ob im nicht-flüchtigen Speicher (Persistency) ein persistiertes Flag für eine aktive Update-Sitzung hinterlegt ist (z. B. nach einem UCM-gesteuerten Warmstart/Reboot).
2. Lebenszyklus-Meldung:
   • SM ruft ExecutionClient::Report(kRunning) auf. Erst mit diesem Call gilt der Prozess gegenüber dem Execution Management als fehlerfrei gestartet.
3. Verzweigung via alt-Fragment:
   • Zweig [Normal startup] (Regulärer Kalt-/Warmstart):
     • SM ruft Controller::start() auf.
     • Der Controller führt synchron die ActionItemList des Zustands Initial aus (Aktivierung der regulären Function-Group-Zustände).
     • Der Controller ruft offer() für StateMachineService und StateMachineNotification auf (SWS_SM_00618).
     • Rückkehr zum SM-Prozess; das System ist im regulären Betrieb.
   • Zweig [Startup during active update session] (Start bei laufendem UCM-Update):
     • SM ruft Controller::start(ContinueUpdate) auf (SWS_SM_00662).
     • Der Controller arbeitet die ActionItemList des Zustands ContinueUpdate ab. Hierbei werden ausschließlich essenzielle Plattform-Prozesse gestartet (insbesondere UCM, ara::per, minimale Kommunikationsstacks); Standard-Applikationen bleiben inaktiv.
     • Der Controller ruft offer() für StateMachineService und StateMachineNotification auf (SWS_SM_00618).
     • Schutzmechanismus/Verriegelung: Die funktionale Schnittstelle des Controllers ist blockiert. Externe Applikationen (SMControlApplication) können die Services via ara::com zwar abonnieren, Steuerungsanfragen (Method Calls) werden vom SM jedoch synchron mit dem Fehlercode kUpdateInProgress abgewiesen (SWS_SM_00663).
4. Post-Condition:
   • Das State Management wechselt in den Dispatcher-Betrieb: Eingehende Events und Service-Requests werden angenommen und zugehörige ActionLists sequenziell abgearbeitet.

4. Normative Relevanz & Entwickler-Hinweise

• Plattform- & Stack-Entwickler:
  • SWS_SM_00204: Das Persistieren des Update-Status muss crash-sicher und transaktional sein. Tritt vor RetrieveUpdateSessionStatus() ein Power-Loss auf, muss der Zustand konsistent rekonstruierbar bleiben.
  • SWS_SM_00618: Services dürfen erst nach vollständiger Abarbeitung der systemspezifischen Initialisierungsaktionen via OfferService() freigegeben werden, um Race-Conditions mit früh anfragenden Clients zu verhindern.
  • Das Reporting von kRunning an den Execution Manager muss frühzeitig im Bootstrap erfolgen, um Watchdog-/Startup-Timeout-Reaktionen durch ara::exec zu vermeiden.
• Applikations-Entwickler (SMControlApplication):
  • SWS_SM_00663 (API-Vertrag): Steuerungsapplikationen müssen explizit auf den Fehler kUpdateInProgress ausgelegt sein. Dieser Rückgabewert ist kein interner Systemfehler, sondern ein regulärer Zustand. Requests dürfen bei kUpdateInProgress nicht in unkontrollierte Retry-Schleifen verfallen, sondern müssen Back-off- bzw. Warte-Strategien implementieren.
• System-Integratoren & Konfiguration (ARXML):
  • In der StateManagement-Modellierung müssen die States Initial und ContinueUpdate mit disjunkten ActionListen belegt werden.
  • Die ActionItemList für ContinueUpdate darf nur Function Groups starten, die für das UCM-Update zwingend erforderlich sind. Das Starten regulärer Applikationen in diesem Pfad verletzt die Update-Integrität und kann zu Ressourcenkonflikten führen.