Figure 10.19: Use case Activate Campaign and derived use cases

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Anwendungsfalldiagramm (Use Case Diagram), spezifiziert mit dem AUTOSAR Adaptive Platform (AP) UML-Profil («aapUseCase», «aapFunctionalCluster», «aapTriggers», «aapParticipates»).
• Architektur-Kontext: AUTOSAR Adaptive Platform, Release R24-11, Dokument AUTOSAR_AP_EXP_SWArchitecture.
• Technischer Zweck: Modellierung des Vehicle Update and Configuration Management (VUCM / Vehicle Package Management). Das Diagramm definiert die funktionale Dekomposition und Vererbungshierarchie der Use Cases zur Aktivierung von Software-Update-Kampagnen auf Gesamtfahrzeugebene sowie deren Interaktion mit internen Functional Clusters (FCs) und externen Systemakteuren.

2. Komponenten, Entitäten & Schnittstellen

Akteure ((from Actors))

• OTA Client: Extern angebundene Applikation (z. B. Cloud-/Backend-Agent) zur Auslösung von Over-the-Air-Update-Kampagnen.
• Diagnostic Application: Werkstatt-Tester / Diagnosetool (z. B. via DoIP / UDS ISO 14229), das Kampagnen stationär initiiert.
• Flashing Adapter: Protokoll- und Bus-Brücke (z. B. UDS-on-CAN/LIN, Classic-ECU-Flashing-Gateway); fungiert sowohl als Trigger als auch als partizipierender Ausführer.
• Vehicle Driver Interface: HMI-Komponente / Infotainment-Cluster zur Einholung von Fahrerzustimmungen, Anzeige von Restzeiten und Warnhinweisen.
• Vehicle State Manager: Überwacht den globalen Fahrzeugzustand (z. B. Parkbremse, Zündungsstatus, Fahrzustand, HV-Verriegelung) zur Gewährleistung der funktionalen Sicherheit.

Functional Clusters («aapFunctionalCluster»)

• Update and Configuration Management (daemon-based): Zentraler UCM-Daemon (VUCM/UCM-Master), verantwortlich für die Orchestrierung, Zustandsverwaltung und Ausführung von Software-Paketen.
• Log and Trace: Plattformweites DLT-Logging zur manipulationssicheren Nachverfolgung, Fehleranalyse und Erfüllung von Audit-Trails.
• Cryptography (daemon-based): Krypto-Daemon für Signaturprüfungen, Hash-Validierung (Integrität/Authentizität) und Entschlüsselung von Software-Containern/Manifesten.

Anwendungsfälle («aapUseCase») und Beziehungen

• Activate Campaign (Basis-Use-Case):
  • Trigger: Wird ausgelöst über «aapTriggers» von OTA Client, Diagnostic Application oder Flashing Adapter.
  • Beteiligte Instanzen: Interagiert über «aapParticipates» mit Update and Configuration Management, Log and Trace, Cryptography sowie bidirektional mit dem Flashing Adapter.
• Activate Safe Campaign (Spezialisierung 1):
  • Generalisierung: Erbt von Activate Campaign (UML-Generalisierungspfeil).
  • Erweiterung: Bindet zusätzlich den Vehicle State Manager über «aapParticipates» ein, um sicherheitsrelevante Vorbedingungen vor der Aktivierung zu erzwingen.
• Activate Campaign with User Interaction (Spezialisierung 2):
  • Generalisierung: Erbt von Activate Safe Campaign.
  • Erweiterung: Bindet zusätzlich das Vehicle Driver Interface über «aapParticipates» ein (Fahrereinwilligung/Consent Management).

3. Dynamisches Verhalten & Sequenzablauf

1. Kampagnen-Triggerung (Asynchron):
   • Ein primärer Trigger (OTA Client, Diagnostic Application oder Flashing Adapter) sendet einen Aktivierungsbefehl an UCM.
2. Sicherheits- & Benutzer-Gating (Vererbte Pfade):
   • Bei Activate Campaign with User Interaction: UCM/Applikation fordert via Vehicle Driver Interface die Bestätigung des Fahrers an (Consent, Hinweis auf Nichtbenutzbarkeit des Fahrzeugs). Bei Timeout oder Ablehnung bricht die Sequenz ab.
   • Bei Activate Safe Campaign: UCM prüft via Vehicle State Manager die Sicherheitsvorbedingungen (z. B. VehicleSpeed == 0, Gear == P, Ignition == OFF). Verlassen des sicheren Zustands führt zum Abbruch oder Übergang in einen definierten Failsafe-Zustand.
3. Kryptografische Verifikation:
   • UCM fordert den Cryptography-Daemon auf, Manifest-Signaturen und Image-Hashes vor dem Umschalten der Boot-Slots / Partitionen final zu validieren.
4. Verteilung & Ziel-Aktivierung:
   • UCM koordiniert über den Flashing Adapter (sowie lokale UCM-Instanzen) das Umschalten auf die neuen Software-Stände (z. B. A/B-Swap, Reset-Sequenzen).
5. Auditing:
   • Jeder Teilschritt, Statuswechsel und Fehlercode wird synchron/asynchron über den Log and Trace-Cluster protokolliert.

4. Normative Relevanz & Entwickler-Hinweise

• UNECE R156 (Software Update Management System - SUMS): Die Ableitungskette reflektiert direkt gesetzliche Anforderungen. Updates dürfen im Feld nicht ohne Safe-State-Check (Activate Safe Campaign) und ohne explizite Fahrereinwilligung bei fahruntauglichem Zustand (Activate Campaign with User Interaction) aktiviert werden.
• API-Verträge (ara::ucm / ara::sm):
  • UCM-Clients müssen Statusrückmeldungen bereitstellen, die mit dem ara::ucm::pkgmgr::VehiclePackageManagement-Interface konform sind.
  • Das Zusammenspiel mit dem Vehicle State Manager bedingt zwingend eine Integration mit dem Adaptive State Management (ara::exec / ara::sm), um unzulässige Funktionszustände während des Flashens/Aktivierens hardwarenah zu blockieren.
• Fehlerbehandlung & Rollback:
  • Schlägt die Signaturprüfung über Cryptography fehl oder signalisiert der Vehicle State Manager einen Zustandskonflikt, muss UCM transaktional abbrechen und ein Rollback auf den vorherigen Software-Stand sicherstellen.
  • Entwickler von Flashing Adapter-Komponenten müssen synchrone/asynchrone Timeouts vorsehen, um hängende Bus-Teilnehmer (Classic ECUs) an UCM zu melden, ohne den Gesamt-Daemon zu blockieren.