Figure 10.20: Use case Cancel Campaign

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use Case Diagram) unter Verwendung des AUTOSAR-Adaptive-UML-Profils mit den Stereotypen «aapUseCase», «aapTriggers», «aapParticipates» und «aapFunctionalCluster».
• Technischer Zweck: Modellierung des fahrzeugweiten Anwendungsfalls "Cancel Campaign" innerhalb des Subsystems Vehicle Update and Configuration Management (Vehicle UCM / VUCM) der AUTOSAR Adaptive Platform (Dokument AUTOSAR_AP_EXP_SWArchitecture, Release R24-11).
• Funktionale Einordnung: VUCM fungiert als fahrzeugzentrierter Master-Orchestrator für Software-Aktualisierungen über heterogene Steuergerätegrenzen hinweg (Adaptive und Classic ECUs). Das Diagramm spezifiziert die zulässigen Initiatoren eines Kampagnenabbruchs sowie die beteiligten Subsysteme und Plattform-Cluster, die zur sicheren Terminierung oder Rückabwicklung (Rollback) interagieren.

2. Komponenten, Entitäten & Schnittstellen

Anwendungsfall

• «aapUseCase» Cancel Campaign: Kapselt die Prozesslogik zur kontrollierten Beendigung einer laufenden, fahrzeugweiten Update-Kampagne.

Auslösende Akteure («aapTriggers»)

• OTA Client (from Actors): Backend-/Telematik-Agent; triggert den Abbruch bei Rückruf der Kampagne durch das OEM-Backend oder bei Verbindungs-/Validierungsfehlern auf Flottendatenebene.
• Diagnostic Application (from Actors): Lokale oder fahrzeugexterne Diagnoseschnittstelle (z. B. Werkstatttester via DoIP / UDS RoutineControl).
• Vehicle Driver Interface (from Actors): Mensch-Maschine-Schnittstelle (HMI); ermöglicht dem Fahrer, eine noch nicht bindend aktivierte Kampagne abzubrechen oder die Einwilligung zu verweigern.

Partizipierende Entitäten («aapParticipates»)

• Flashing Adapter (from Actors): Protokoll- und Bustechnologie-Adapter zur Kommunikation mit unterlagerten Steuergeräten (z. B. Classic Platform ECUs via CAN, LIN oder Ethernet); leitet Abbruch- und Rollback-Kommandos über diagnostische Protokolle weiter.
• «aapFunctionalCluster» Update and Configuration Management daemon-based (UCM): Lokaler UCM-Dämon auf der ausführenden Adaptive-Maschine; bricht lokale Software-Paket-Zustandsübergänge (Transfer, Stream, Process, Activate) ab und führt lokale Rollbacks durch.
• «aapFunctionalCluster» Log and Trace: Plattform-Cluster für auditierbares, standardisiertes Logging des Abbruchereignisses, des auslösenden Akteurs und der Systemzustände.
• «aapFunctionalCluster» Cryptography daemon-based: Dämon-basierter Krypto-Cluster zur kryptografischen Authentifizierung der Abbruchanforderung (Integritäts- und Signaturprüfung gegen unbefugte DoS-Abbrüche) sowie zum Bereinigen temporärer Sitzungsschlüssel.

Strukturierungsgrenzen

• Adaptive Platform: Plattform-Systemgrenze.
• Vehicle Update and Configuration Management: Funktionsgrenze des übergeordneten Kampagnen-Managements, welche die Orchestrierung von UCM und Flashing Adaptern kapselt.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Event-Ingestion:
   • Der Abbruch wird asynchron über eine definierte Service-Schnittstelle (z. B. Method-Call CancelCampaign() via SOME/IP oder IPC) durch den OTA Client, die Diagnostic Application oder das Vehicle Driver Interface initiiert.
2. Kryptografische Verifikation:
   • VUCM konsultiert Cryptography daemon-based, um die Berechtigung und Signatur des Abbruchbefehls zu prüfen (insbesondere bei OTA-Triggern obligatorisch).
3. Zustandsevaluierung:
   • VUCM prüft die aktuelle Kampagnenphase (z. B. Downloading, Transferring, Processing, ReadyToActivate). Abhängig davon wird entschieden, ob ein einfacher Abbruch (Verwerfen von Caches) oder eine Rollback-Sequenz erforderlich ist.
4. Verteilte Orchestrierung:
   • Lokal: Aufruf des lokalen Update and Configuration Management daemon-based via ara::ucm zum Stoppen der lokalen Paketverarbeitung und Bereinigung von Staging-Speichern.
   • Fahrzeugweit: Parallele/sequenzielle Signalisierung an alle involvierten Flashing Adapter, um laufende Programmiersequenzen auf Ziel-ECUs zu terminieren und deren Zielzustand (Safe State oder Rollback auf A/B-Partition) sicherzustellen.
5. Auditing & Abschluss:
   • Persistierung des Abbruchstatus und des auslösenden Akteurs über Log and Trace.
   • Rückmeldung des Gesamtergebnisses (kSuccess, kFailed, kRollbackExecuted) an den auslösenden Akteur.

4. Normative Relevanz & Entwickler-Hinweise

• Zustandsautomaten-Konformität (State Machine Constraints):
  • Entwickler von Kampagnen-Managern und UCM-Clients müssen sicherstellen, dass Cancel Campaign nur in spezifikationsgemäßen Zuständen zulässig ist. Befindet sich ein Steuergerät in einer nicht-unterbrechbaren Flash-Schreibphase (Point of no Return vor Aktivierungsabschluss), darf der Abbruch erst nach Erreichen eines definierten Zwischenzustands oder über einen kontrollierten Rollback-Pfad ausgeführt werden.
• Flashing-Adapter-Vertrag:
  • Jeder implementierte Flashing Adapter muss deterministische Timeouts und idempotente Abbruch-APIs bereitstellen. Kann eine Classic-ECU den Abbruch nicht direkt quittieren, muss der Adapter Fehlercodes an VUCM melden, damit das Fahrzeug nicht in einem teilgeflashten, nicht-verkehrssicheren Zustand verbleibt.
• Security & DoS-Prävention:
  • Die Beteiligung des Cryptography-Clusters erfordert eine strikte Zugriffssteuerung (Access Control / IAM) auf die Abbruch-Schnittstellen. Unauthentifizierte Abbruchanforderungen müssen abgewiesen und als Security-Event via Log and Trace protokolliert werden.
• Diagnose- und HMI-Rückmeldung:
  • Applikationsentwickler (Diagnostic Application, Vehicle Driver Interface) müssen synchrone/asynchrone Return-Typen verarbeiten können. Ein Cancel-Aufruf liefert in der Regel ein Future/Token zurück, da die Rückführung aller Steuergeräte in den Ausgangszustand mehrere Sekunden bis Minuten beanspruchen kann.