Figure 7.32: Requesting update session within StateMachine approach

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (alt/Bedingungsblöcke).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) in Interaktion mit dem Update and Configuration Management (UCM) bzw. fahrzeugweiten Zustandsüberwachungs-Services.
• Technischer Zweck: Spezifikation des Protokollablaufs zur Anforderung einer Software-Aktualisierungssitzung (UpdateSession) im Rahmen des StateMachine approach (State-Handling via definierter Zustandslogik). Das Diagramm regelt die Durchsetzung von Update-Vorbedingungen (Fahrzeugzustand/Sicherheit), das Setzen von Notifiern und das Verhindern paralleler Update-Sitzungen.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • «Service» UpdateRequest: Service-Schnittstelle (Client-seitig typischerweise durch UCM konsumiert, Server-seitig von State Management bereitgestellt), über die Aktualisierungszyklen initiiert werden.
  • State Management: Zentraler AP-Funktionscluster zur Koordination von Maschinen- und Funktionsgruppenzuständen sowie der Validierung von Update-Bedingungen.
  • «Service» UpdateAllowedService: Service-Schnittstelle (bereitgestellt von fahrzeugbezogenen Sicherheits-/Zustandsmodulen), welche autorisiert, ob ein Update zulässig ist (z. B. Fahrzeug im Stillstand/sicherer Halt).
• Felder (Fields) & Attribute:
  • field UpdateAllowed: Zustandsfeld (Default: kUpdateNotAllowed; gesetzt auf kUpdateAllowed via Setter-Methode).
  • field ResetMachineNotifier: Notifier-Feld innerhalb von UpdateRequest, welches den Zustand für Maschinenresets signalisiert (hier Initialwert/Reset auf kIdle).
• Methoden & Signale:
  • RequestUpdateSession(): Synchrone/asynchrone Service-Methode auf State Management zur Anforderung der Update-Session.
  • UpdateAllowed::Set(kUpdateAllowed): Setter-Aufruf zur Freigabe des Update-Modus.
  • Rückgabewerte / Fehlercodes: OK, kRejected, kNotAllowedMultipleUpdateSessions.

3. Dynamisches Verhalten & Sequenzablauf

1. Szenario: Update-Session nicht zulässig (update session is not allowed)
   • Vorbedingung: field UpdateAllowed == kUpdateNotAllowed (Initialer Default-Wert).
   • Trigger: Client ruft UpdateRequest::RequestUpdateSession() auf.
   • Verhalten (SWS_SM_00630): State Management prüft UpdateAllowed, lehnt den Request unmittelbar ab.
   • Antwort: Rückgabe von kRejected an den Aufrufer.
2. Szenario: Update-Session zulässig (update session is allowed)
   • Freigabe: UpdateAllowedService setzt über UpdateAllowed::Set(kUpdateAllowed) das Feld UpdateAllowed = kUpdateAllowed.
3. Unterfragment: Erstmalige Anforderung (first time requesting)
   • Trigger: Client ruft RequestUpdateSession() auf.
   • Verhalten (SWS_SM_00659): State Management akzeptiert den Request und setzt das Feld ResetMachineNotifier via Event/Notification explizit auf kIdle (field ResetMachineNotifier = kIdle).
   • Zustandssicherung (SWS_SM_00631): Eine einmal etablierte Update-Session ist geschützt: Nachfolgende Wertänderungen an field UpdateAllowed (z. B. temporäres Rückfallen auf kUpdateNotAllowed) beeinflussen die bereits laufende Update-Session nicht mehr.
   • Antwort: Positive Bestätigung OK.
4. Unterfragment: Folgeanforderungen ([any futher request])
   • Trigger: Erneuter Aufruf von RequestUpdateSession(), während bereits eine Session aktiv ist.
   • Verhalten (SWS_SM_00209): Parallel laufende Update-Sessions sind strikt untersagt (Mutual Exclusion).
   • Antwort: Ablehnung mit dem Fehlercode kNotAllowedMultipleUpdateSessions.

4. Normative Relevanz & Entwickler-Hinweise

• UCM- & Client-Entwicklung:
  • Aufrufer von RequestUpdateSession() müssen sowohl kRejected als auch kNotAllowedMultipleUpdateSessions defensiv abfangen und geeignete Retry- oder Rollback-Mechanismen implementieren.
  • Ein erneuter Aufruf von RequestUpdateSession() vor Abschluss der laufenden Session führt zwingend zu einem Fehler.
• State-Management- & Richtlinien-Konfiguration (Integrator):
  • Das Default-Verhalten (kUpdateNotAllowed) erzwingt eine explizite Aktivierung durch den fahrzeugspezifischen UpdateAllowedService (Safety-Gate).
  • Gemäß SWS_SM_00631 muss die State-Machine-Implementierung eine Entkopplung vorsehen: Ein Entzug der Update-Erlaubnis während einer laufenden Session darf keinen inkonsistenten Zustand oder sofortigen Abbruch der aktiven Session innerhalb des SM erzwingen; Abbrüche müssen über dedizierte UCM-Rollback-Pfade gesteuert werden.
• Notifier-Synchronisation:
  • Das Rücksetzen von ResetMachineNotifier auf kIdle signalisiert allen beteiligten Komponenten, dass zu Beginn der Session keine veralteten Reset-Trigger anstehen.