Figure 5.3: Interfaces required by Vehicle Update and Configuration Management from Update and Configuration Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Service Interface Realization Diagram) auf Basis des AUTOSAR Adaptive Platform (AP) Metamodells («aap...»-Stereotypen).
• Technischer Zweck: Spezifikation der Service-orientierten Schnittstellenabhängigkeit zwischen dem fahrzeugweiten Update-Koordinator (Vehicle Update and Configuration Management – VUCM) und den lokalen Update-Ausführungsinstanzen (Update and Configuration Management – UCM bzw. Flashing Adapter).
• Funktionale Einordnung: VUCM fungiert als fahrzeugzentraler Master/Orchestrator für Over-the-Air (OTA) Kampagnen. Das Diagramm definiert das Service-Interface PackageManagement, über welches VUCM heterogene Steuergeräte (Adaptive ECUs via UCM-Daemon sowie Classic/Legacy ECUs via Flashing Adapter) einheitlich ansteuert.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Vehicle Update and Configuration Management («aapFunctionalCluster», daemon-based):
  • Service-Konsument (Client). Benötigt den Service PackageManagement über einen Required Port («use», «aapRequiredPort»).
• Update and Configuration Management («aapFunctionalCluster», daemon-based):
  • Service-Provider (Server) auf Adaptive-Zielknoten. Implementiert und exponiert PackageManagement über einen Provided Port («aapProvidedPort»).
• Flashing Adapter (gekapselt in Adaptive Application):
  • Alternativer Service-Provider («aapProvidedPort»). Dient als Brücken-/Adapter-Applikation zur Einbindung von Classic AUTOSAR (CP) ECUs oder Non-AUTOSAR-Knoten (z. B. via UDS/DoIP), indem er das standardisierte PackageManagement-Interface nach außen bereitstellt und intern in proprietäre oder UDS-Diagnosedienste übersetzt.

Schnittstelle: PackageManagement

• Stereotypen: «aapAPI, aapAraComServiceInterface» (Deployment über ara::com).
• Service Field:
  • + CurrentStatus («aapAccessControlled, aapServiceField»): Exponiert den aktuellen Zustandsstatus des UCM/Adapters (Getter/Notifier-Pattern).
• Service Methods («aapAccessControlled, aapServiceMethod»):
  • Transfer & Payload-Handling: TransferStart(), TransferData(), TransferExit(), DeleteTransfer()
  • Paketregistrierung & -verarbeitung: RegisterSoftwarePackage(), ProcessSwPackage(), GetProgress(), Cancel(), RevertProcessedSwPackages()
  • Aktivierung & Rollback: Activate(), Rollback(), Finish()
  • Metadaten, Inventar & Diagnose: GetId(), GetHistory(), GetSwClusterInfo(), GetSwClusterChangeInfo(), GetSwClusterManifestInfo(), GetSwPackages()
• Sicherheits-Stereotyp: Alle Methoden und das Field tragen «aapAccessControlled», was eine zwingende Absicherung über das Adaptive Identity and Access Management (IAM) vorschreibt.

3. Dynamisches Verhalten & Sequenzablauf

Die Methoden modellieren den standardisierten Lebenszyklus einer Software-Aktualisierung über ara::com:

[Transfer- / Bereitstellungs-Phase] --> [Process-Phase]        --> [Activation-Phase]   --> [Abschluss]
TransferStart()                         ProcessSwPackage()         Activate()               Finish()
  ↓                                       ↓                          ↓ (oder Rollback())
TransferData() [Loop]                   GetProgress()              CurrentStatus überwachen
  ↓                                       ↓ (oder Cancel()/
TransferExit()                            RevertProcessedSwPackages())
(oder RegisterSoftwarePackage())

1. Transfer- und Registrierungs-Phase:
   • Standard-Transfer: Initialisierung via TransferStart(), blockweise Datenübertragung via TransferData(), regulärer Abschluss via TransferExit() oder Abbruch via DeleteTransfer().
   • Direkte Registrierung: Mittels RegisterSoftwarePackage() kann ein bereits auf dem Dateisystem oder extern bereitgestelltes Software-Paket direkt registriert werden, ohne den Streaming-Transfer über ara::com zu durchlaufen.
2. Process-Phase (Verarbeitung & Verifikation):
   • Entpacken, Integritäts- und Signaturprüfung sowie Installation via ProcessSwPackage().
   • Generische Fortschrittsüberwachung laufender asynchroner Operationen über GetProgress().
   • Abbruch laufender Vorgänge über Cancel() oder Rücknahme vorbereiteter Pakete über RevertProcessedSwPackages().
3. Activation-Phase & Abschluss:
   • Aktivierung und Umschaltung auf die neuen Software-Stände mittels Activate().
   • Kontinuierliche Überwachung des Systemzustands über das Feld CurrentStatus.
   • Bei Fehlern Rückfall auf den vorherigen Softwarestand via Rollback().
   • Nach erfolgreicher Verifikation endgültige Bestätigung und Bereinigung temporärer Ressourcen via Finish().
4. Zustands- & Metadatenabfragen (querschneidend):
   • Statusüberwachung über CurrentStatus.
   • Abfrage von ECU-/UCM-Kennungen (GetId()), Update-Historie (GetHistory()), Paketlisten (GetSwPackages()) sowie Software-Cluster-Zuständen (GetSwClusterInfo(), GetSwClusterChangeInfo(), GetSwClusterManifestInfo()).

4. Normative Relevanz & Entwickler-Hinweise

• Proxy/Skeleton-Generierung (ara::com):
  • VUCM generiert den Client-Proxy (PackageManagementProxy), UCM und Flashing Adapter instanziieren das Skeleton (PackageManagementSkeleton).
  • Signal-/Method-Binding muss via ARXML konsistent für SOME/IP bzw. IPC konfiguriert sein (Instanz-IDs, Service-IDs, E2E-Protection).
• IAM-Konfiguration (Access Control):
  • Da alle Schnittstellenelemente als «aapAccessControlled» deklariert sind, muss im Execution Manifest / Access Control List (IAM) der Prozesskontext des VUCM explizit berechtigt werden, jede einzelne dieser Methoden und das Field CurrentStatus aufzurufen. Nicht autorisierte Aufrufe werden vom IAM-Subsystem geblockt.
• Implementierungsanforderung Flashing Adapter:
  • Der Flashing Adapter muss als vollwertige Adaptive Application fungieren und den Zustandsautomaten von PackageManagement vollständig emulieren. UDS-Transferroutinen (z. B. RoutineControl $31, RequestDownload $34, TransferData $36, RequestTransferExit $37) müssen deterministisch auf die Methoden TransferStart(), TransferData(), TransferExit() etc. abgebildet werden.
• Fehlerbehandlung:
  • Methoden geben ara::core::Future mit ara::core::Result<void, UcmErrorDomainErrc> zurück. Entwickler müssen Fehlercodes (z. B. InsufficientMemory, AuthenticationFailed, InvalidPackageManifest) auf VUCM-Ebene für fahrzeugweite Kampagnenentscheidungen abfangen.