Figure 10.1: Sequence diagram showing the update process

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-2.x-Sequenzdiagramm (Interaktionsübersicht / High-Level Sequence Diagram mit ref-Interaktionsreferenzen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Update and Configuration Management (UCM).
• Technischer Zweck: Definition des standardisierten, dreiphasigen Makro-Ablaufs für Software-Aktualisierungen (OTA oder über standardisierte Fahrzeugdiagnose wie DoIP/UDS) auf einer Adaptive Machine. Es kapselt die Interaktion zwischen der auslösenden Applikation und dem UCM-Kernservice.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Akteure:
  • Diagnostic Application (OEM specific): Service Consumer (Client). Repräsentiert die applikative Instanz, welche die Software-Aktualisierung steuert (z. B. OEM-spezifischer OTA-Client-Daemon oder Diagnosetester-Adapter).
  • :UCM mit Stereotyp «ServiceProvider»: Service Provider. Die Kerninstanz des UCM-Clusters (C++-Namespace ara::ucm), die als Service-Server über ara::com standardisierte Schnittstellen bereitstellt (vorrangig ara::ucm::pkgmgr::PackageManagement).
• Strukturierte Interaktionselemente (ref Interaction Use Frames):
  • Data transmission: Kapselt das Session-Handling und den blockweisen Transport des Software-Pakets (.swp) in den persistenten Speicher des UCM.
  • Processing: Kapselt die Integritäts-/Authentizitätsprüfung, Manifest-Validierung, Abhängigkeitsanalyse und Vorinstallation/Dekomprimierung.
  • Activation: Kapselt die koordinierte Umschaltung auf den neuen Softwarestand unter Einbindung von State Management (ara::sm) und Execution Management (ara::exec).

3. Dynamisches Verhalten & Sequenzablauf

Der Prozess erzwingt eine strikt sequentielle Pipeline:

1. Phase 1: ref Data transmission (Datenübertragung)
   • Start: Client initiiert die Übertragung via TransferStart(); UCM allokiert Speicher und liefert ein TransferId-Handle zurück.
   • Transfer: Iterative Übertragung von Datenblöcken über TransferData(TransferId, DataBlock).
   • Ende: Validierung der empfangenen Blockanzahl und Abschluss via TransferExit(TransferId).
2. Phase 2: ref Processing (Verarbeitung)
   • Trigger: Client ruft ProcessSwPackage(TransferId) auf.
   • Ablauf: Asynchrone Abarbeitung im UCM. UCM prüft kryptografische Signaturen, Zertifikatsketten, Hardware-/Software-Kompatibilität sowie Zielabhängigkeiten (SoftwareCluster).
   • Monitoring: Client pollt den Verarbeitungsfortschritt über GetSwProcessProgress(TransferId).
3. Phase 3: ref Activation (Aktivierung)
   • Trigger: Aufruf von Activate().
   • Ablauf: UCM wechselt in den Zustand ACTIVATING und fordert über ara::sm die Umschaltung der Funktionsgruppe/des Systems an (z. B. A/B-Partitions-Swap, gezielter Prozess-Restart via ara::exec).
   • Abschluss/Rollback: Verifikation des Neuanlaufs; bei Erfolg finaler Abschluss via Finish(), bei Verifikationsfehlern Initiierung eines Fallbacks via Rollback().

• Abbruch- und Fehlerpfade: Ein Scheitern in Phase 1 oder 2 führt über TransferExit() bzw. RevertProcessSwPackage() zur Freigabe allokierter Ressourcen, ohne die aktuell laufende Softwarekonfiguration zu korrumpieren.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::ucm::pkgmgr::PackageManagement): Methodenaufrufe unterliegen strikten Vorbedingungen. Ein Methodenaufruf aus Activation scheitert mit Fehlern wie PackageManagementErrorDomain::kNotProcessed oder kInvalidPackageManifest, wenn Processing nicht erfolgreich abgeschlossen wurde.
• Entkopplung & Background-Updates: Durch die Trennung von Data transmission / Processing und Activation kann das Herunterladen und Verifizieren vollständig im Hintergrund während des regulären Fahrzeugbetriebs erfolgen. Die eigentliche Activation erfordert in der Regel ein sicheres Wartungsfenster (Safe State).
• Zustandsmodell-Konformität: Entwickler von OEM Diagnostic Applications müssen die UCM-Zustandsmaschine beachten (IDLE → TRANSFERRING → PROCESSING → READY_FOR_ACTIVATION → ACTIVATING → ACTIVATED).
• Asynchrone Schnittstellen: Sämtliche zeitintensiven Methodenaufrufe sind in der C++-API typischerweise über ara::core::Future abgebildet, um Blockaden des Client-Threads zu verhindern.