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()
  • Paketverarbeitung: ProcessSwPackage(), GetSwProcessProgress(), 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-Phase]       --> [Process-Phase]        --> [Activation-Phase]   --> [Abschluss]
TransferStart()            ProcessSwPackage()         Activate()               Finish()
  ↓                          ↓                          ↓ (oder Rollback())
TransferData() [Loop]      GetSwProcessProgress()     CurrentStatus überwachen
  ↓                          ↓ (oder Cancel()/
TransferExit()               RevertProcessedSwPackages())

1. Transfer-Phase (Payload-Streaming):
   • Synchron/Asynchron: VUCM initialisiert die Session mit TransferStart(), streamt Pakete blockweise über TransferData() und schließt die Übertragung mit TransferExit() ab. Bei Fehler: Abbruch über DeleteTransfer().
2. Verarbeitungsphase (Staging & Verifikation):
   • Aufruf von ProcessSwPackage(). Der UCM/Flashing-Adapter dekomprimiert, validiert Signaturen/Manifeste und bereitet die Partitionen vor.
   • Statusabfrage asynchron/pollend über GetSwProcessProgress() und Feld CurrentStatus. Abbruch über Cancel() bzw. RevertProcessedSwPackages().
3. Aktivierung & Verification:
   • Synchroner/asynchroner Trigger von Activate(). UCM koordiniert mit dem State Management (SM) bzw. der Flashing Adapter führt den Reboot/UDS-Reset der Ziel-ECU aus.
   • Tritt ein Fehler auf oder schlägt die Selbstprüfung fehl, veranlasst VUCM Rollback().
4. Finalisierung:
   • Finish() markiert das Software-Update als persistent und bereinigt temporäre Update-Ressourcen.

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.