Figure 10.15: Use cases for transferring and processing SW packages

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Anwendungsfalldiagramm (Use Case Diagram) mit AUTOSAR-Adaptive-Plattform-Metamodell-Stereotypen («aap...»).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R24-11), Cluster Update and Configuration Management (UCM).
• Technischer Zweck: Spezifikation der Systemgrenzen und funktionalen Abhängigkeiten des UCM-Clusters für den Software-Aktualisierungspfad auf Machine-Ebene. Das Diagramm modelliert, wie externe Fahrzeug-Update-Orchestrierungsinstanzen elementare Update-Phasen anstoßen und welche fundamentalen Adaptive Platform Functional Clusters (APFC) dabei zur Ausführung hinzugezogen werden.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Klassifikation

• Systemgrenze / Scope:
  • Update and Configuration Management (UCM): Kern-Cluster der Adaptive Platform zur lokalen Verwaltung, Installation, Verifikation und Aktivierung von Software-Paketen.
• Akteure / Trigger:
  • Vehicle Update and Configuration Management (VUCM): «aapFunctionalCluster», Ausprägung daemon-based. Repräsentiert die fahrzeugweite Update-Koordination (OTA-Client / Gateway-Ebene), die Machine-lokale UCM-Instanzen steuert.
• Anwendungsfälle («aapUseCase»):
  • Transfer SW Package: Empfang, Pufferung und persistente Ablage eingehender Software-Pakete (Payload & Metadaten/Manifest).
  • Process SW Package: Integritäts- und Authentizitätsprüfung, Dekomprimierung, Entschlüsselung, Validierung von Abhängigkeiten sowie Vorbereitung des Ziel-Dateisystems.
• Partizipierende Functional Clusters («aapFunctionalCluster»):
  • Persistency (ara::per): Bibliothek/In-Process. Bereitstellung von Dateisystem- und Key-Value-Speicher zur transienten/permanenten Sicherung fragmentierter Update-Datenpakete.
  • Log and Trace (ara::log): Standard-Diagnose- und Auditing-Instanz zur Nachverfolgung von Update-Zuständen, Fortschrittsindikatoren und Fehlerursachen.
  • Cryptography (ara::crypto): Ausprägung daemon-based (Crypto-Treiber/HSM-Kapselung). Verantwortlich für Signaturprüfung (Authentizität/Integrität) und Payload-Entschlüsselung.

Relationen & Stereotypen

• Trigger-Beziehungen («aapTriggers»):
  • VUCM → Transfer SW Package: Initiiert den Datentransfer auf die Ziel-Machine.
  • VUCM → Process SW Package: Triggert nach vollständiger Übertragung die Validierung und Verarbeitung.
• Partizipations-Beziehungen («aapParticipates»):
  • Transfer SW Package → Persistency: Speicherung der Chunk-Datenströme auf persistenten Medien.
  • Transfer SW Package → Log and Trace: Protokollierung von Transferfortschritt und Transferfehlern.
  • Process SW Package → Log and Trace: Audit-Trail über Validierungsschritte und Fehlercodes.
  • Process SW Package → Cryptography: Durchführung asymmetrischer Signaturvalidierungen und Entschlüsselungsoperationen.

3. Dynamisches Verhalten & Sequenzablauf

1. Transferphase (Transfer SW Package):
   • Trigger: Asynchroner Aufruf durch VUCM (z. B. via ara::ucm-Serviceschnittstelle TransferStart / TransferData / TransferExit).
   • Ablauf: UCM nimmt segmentierte Datenblöcke entgegen, verifiziert die Chunk-Reihenfolge und persistiert die Rohdatenblöcke über ara::per in einem dedizierten Staging-Bereich.
   • Monitoring: Jeder Blocktransfer bzw. Transferabbruch generiert Trace-Events über ara::log.
   • Abschluss: Erfolgreicher Abschluss (TransferExit) liefert ein eindeutiges TransferId-Handle an VUCM zurück.
2. Verarbeitungsphase (Process SW Package):
   • Trigger: Aufruf durch VUCM unter Referenzierung der TransferId (z. B. ProcessSwPackage).
   • Ablauf: UCM liest das Software Package Manifest aus der Persistenz. Übergabe der Zertifikatsketten, Hashes und Signaturen an ara::crypto (Crypto Daemon / HSM).
   • Kryptografische Prüfung: Validierung gegen hinterlegte Root-Zertifikate; schlägt die Prüfung fehl, bricht UCM mit Fehlermeldung via ara::log ab und meldet den Status PackageProcessingFailed an VUCM.
   • Paketextraktion: Bei erfolgreicher Krypto-Validierung erfolgt die Dekomprimierung und Vorbereitung des Ziel-Dateisystems für den nachfolgenden Aktivierungsschritt (Activate).

4. Normative Relevanz & Entwickler-Hinweise

• UCM-Dienstarchitektur: UCM operiert machine-lokal als Daemon. Entwickler von fahrzeugweiten Update-Funktionen müssen sicherstellen, dass die Kommunikation zwischen VUCM und UCM über standardisierte Adaptive-Service-Interfaces (ara::com / SOME/IP) gemappt ist.
• Ressourcenallokation & ara::per-Dimensionierung:
  • Der Staging-Bereich unter ara::per muss für mindestens die maximale Größe des größten zu erwartenden Software-Pakets plus Metadaten ausgelegt sein (A/B-Partitionierung oder redundanter Puffer).
  • Schreibzyklen (Flash Endurance) und Quotas für transiente Update-Speicher müssen im Execution Manifest der UCM-Applikation restriktiv konfiguriert werden.
• Crypto-Integration:
  • ara::crypto ist als Daemon modelliert: Krypto-Schlüssel für Signaturprüfungen dürfen niemals im UCM-Anwendungsraum liegen, sondern müssen über gesicherte Key-Slots (HSM/SecOC/Crypto Stack) via Key-UUIDs referenziert werden.
  • CPU-intensive Kryptooperationen (Hashing großer Images) erfordern asynchrone Bearbeitungsmuster im UCM-Daemon, um ein Blockieren des Service-Dispatchers zu verhindern.
• Zustandssynchronisation: Die Trennung von Transfer und Process erzwingt eine strikte State-Machine im UCM (kIdle → kTransferring → kTransferred → kProcessing → kProcessed). Übergänge müssen idempotent und stromausfallsicher (power-fail safe) in der Persistenz nachgeführt werden.