Figure 7.33: Example for StateMachineState VerifyUpdate for an Agent

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Zustandsdiagramm (State Machine Diagram) zur Spezifikation des Verhaltens eines State Management Agents im Metamodell der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Visualisierung des Systemverhaltens bei Software-Aktualisierungen (UCM – Update and Configuration Management). Dargestellt ist das Zusammenspiel zwischen dem Verifikationszustand (VerifyUpdate), dem regulären Startzustand (Initial State), den zugeordneten Aktionslisten (ActionLists) zur Steuerung von Funktionsgruppen (Function Groups) sowie der Isolation externer Einflüsse (Sperrung von externen Zustandsanforderungen und Netzwerk-Handles).
• Funktionale Einordnung: Das Diagramm konkretisiert die Anforderungen RS_SM_00001 (Steuerung von Applikations- und Funktionsgruppenzuständen) und RS_SM_00005 (UCM-Unterstützung) gemäß SWS_SM_00637 und SWS_SM_00638.

2. Komponenten, Entitäten & Schnittstellen

• <<StateMachine>> State Machine X: Kapselnder Zustandsautomat eines dedizierten SM-Agents zur Überwachung und Steuerung einer Funktionsdomäne oder Maschine.
• Pseudozustand (Initial / Decision Point): Startknoten (schwarzer Vollkreis) mit deterministischer Verzweigung beim Bootvorgang – abhängig vom Boot-Flag/Reset-Grund (regulärer Start vs. UCM-Verifikationsstart).
• <<StateMachineState>> Initial State: Regulärer Betriebszustand nach dem Initialisieren des Agents.
• <<StateMachineState>> VerifyUpdate: Spezifischer Verifikationszustand zur Absicherung und Validierung neu eingespielter Softwarepakete vor der finalen Aktivierung.
• <<ActionList>>: Metamodell-Element zur sequenziellen Ausführung von Systemkommandos beim Zustandswechsel:
  • In Initial State:
    • FG_1::On: Aktiviert Funktionsgruppe 1.
    • FG_2::Off: Deaktiviert Funktionsgruppe 2.
    • SYNC: Synchronisationsbarriere (Execution Management Barrier). Nachfolgende Aktionen werden erst nach positiver Quittierung der vorherigen Transitionen ausgeführt.
    • FG_3::Off: Deaktiviert Funktionsgruppe 3 nach erfolgreichem SYNC.
  • In VerifyUpdate:
    • FG_1::Verify, FG_2::Verify, FG_3::Verify: Versetzt alle relevanten Funktionsgruppen simultan in den Verifikationszustand (Start minimaler Selbsttests/Diagnoseprozesse).
• Externe Schnittstellen & Entitäten (Blockierte Interaktionen):
  • <<ServiceInterface>> RequestState: Port/Schnittstelle für externe Zustandsanfragen via ara::com. Im Zustand VerifyUpdate mit Status Blocked versehen (Schnittstelle weist Anfragen zurück oder ignoriert sie).
  • <<NmNetworkHandle>> Partial Network Y: Netzwerkmanagement-Handle (ara::nm) zur Aktivierung/Freigabe von Teilnetzen. Im Zustand VerifyUpdate mit Status Blocked versehen (Unterdrückung von Buskommunikation/Wakeup-Requests).

3. Dynamisches Verhalten & Sequenzablauf

1. Systemstart / Verzweigung:
   • Beim Systemstart ermittelt der State Management Agent (via UCM-Persistenz oder Boot-Argumente), ob ein Software-Update verifiziert werden muss.
   • Regulärer Pfad: Eintritt in Initial State. Die ActionList schaltet FG_1 auf On und FG_2 auf Off, wartet an der SYNC-Barriere auf die Bestätigung durch das Execution Management (EM) und setzt erst danach FG_3 auf Off.
   • Update-Verifikationspfad (SWS_SM_00637): Direkter Eintritt in den Zustand VerifyUpdate.
2. Ausführung in VerifyUpdate:
   • Die zugehörige ActionList fordert für FG_1, FG_2 und FG_3 den Zustand Verify beim EM an, sodass nur verifikationsrelevante Prozesse gestartet werden.
3. Isolationsmechanismus (SWS_SM_00638):
   • Solange VerifyUpdate aktiv ist, werden eingehende RequestState-Methodenaufrufe über das <<ServiceInterface>> explizit verworfen, verzögert oder mit einem Fehler quittiert (Blocked).
   • Das Teilnetzwerk (Partial Network Y) bleibt inaktiv; Anforderungen am <<NmNetworkHandle>> werden unterdrückt (Blocked), um unzulässigen Busverkehr während ungetesteter Softwarestände zu verhindern.
4. Transition nach Verifikation:
   • Nach erfolgreichem Abschluss der Integritäts- und Funktionsprüfung (Rückmeldung an UCM) schaltet der Automat über die Transition von VerifyUpdate nach Initial State um, womit die Blockaden aufgehoben und die Standard-Betriebszustände über die reguläre ActionList etabliert werden.

4. Normative Relevanz & Entwickler-Hinweise

• SM-Konfiguration (ARXML):
  • Entwickler müssen für jeden Agenten sicherstellen, dass VerifyUpdate als gültiger Zustand im State-Machine-Modell deklariert ist.
  • In der Manifest-Modellierung müssen die Triggereigenschaften so konfiguriert werden, dass externe RequestState-Trigger sowie Network-Handle-Requests in diesem Zustand maskiert bzw. geblockt werden.
• Synchronisationsverhalten (SYNC):
  • SYNC erzwingt blockierendes/synchrones Warten auf das Execution Management. Entwickler müssen Timeouts in der ActionList-Abarbeitung absichern, um Deadlocks bei hängenden Prozessen in FG_1 oder FG_2 zu vermeiden.
• Applikations-Design (Clients von RequestState):
  • Adaptive Applications müssen darauf vorbereitet sein, dass Serviceaufrufe an RequestState während der Verifikationsphase abgewiesen werden (Rückgabe spezifischer Error-Codes wie z. B. SM_SERVICE_NOT_AVAILABLE oder Ablehnung der Zustandsanforderung).
• Partielles Netzwerk & Diagnose:
  • Da Partial Network Y blockiert ist, dürfen Verifikationsprozesse keine externe Buskommunikation auf diesem Handle voraussetzen. Etwaige Diagnoserückmeldungen an UCM müssen über lokale IPC-Kanäle oder dedizierte UCM-Verbindungen abgewickelt werden.