Figure 9.90: Interfaces required by Vehicle Update and Configuration Management (part 3)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Service-Schnittstellendiagramm (AUTOSAR Adaptive Platform Architecture Modeling).
• Technischer Zweck: Spezifikation der Service-Schnittstelle PackageManagement zur fahrzeugweiten Software-Aktualisierung sowie Darstellung der Bereitstellungs- und Nutzungsbeziehungen zwischen dem fahrzeugweiten Orchestrator (VUCM), dem lokalen Update-Manager (UCM) und externen/nicht-adaptiven Zielen über Adapter.
• Funktionale Einordnung: Verortung in der AUTOSAR Adaptive Platform (Release R23-11), Domäne Update and Configuration Management. Das Diagramm definiert, wie der Functional Cluster Vehicle Update and Configuration Management (VUCM) über standardisierte Service-Ports auf standardkonforme Update-Dienste zugreift – unabhängig davon, ob das Ziel ein lokaler Adaptive Platform UCM-Daemon oder eine Classic Platform / Fremd-ECU via Flashing Adapter ist.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Vehicle Update and Configuration Management (VUCM):
  • Stereotyp: «aapFunctionalCluster» (Ausprägung: daemon-based).
  • Rolle: Service-Konsument (Client), orchestriert kampagnenweite Multi-ECU-Updates auf Gesamtfahrzeugebene.
  • Port: Besitzt einen Client-Port mit Stereotyp «aapRequiredPort».
• PackageManagement:
  • Stereotypen: «aapAPI, aapAraComServiceInterface».
  • Definition: Service-Vertrag im Namensraum ara::ucm::pkgmgr zur Steuerung des Software-Package-Lifecycles.
  • Service-Field («aapAccessControlled, aapServiceField»):
    • + CurrentStatus: Zustandsattribut des UCM/Adapters (Getter-, Setter-/Notifier-Semantik via ara::com).
  • Service-Methods («aapAccessControlled, aapServiceMethod»):
    • Transfer- & Registrierungs-Phase: TransferStart(), TransferData(), TransferExit(), DeleteTransfer(), RegisterSoftwarePackage().
    • Prozessierungs- & Aktivierungsphase: ProcessSwPackage(), Activate(), Finish(), RevertProcessedSwPackages(), Rollback(), Cancel().
    • Diagnose- & Abfrage-Operationen: GetId(), GetHistory(), GetSwPackages(), GetProgress(), GetSwClusterInfo(), GetSwClusterChangeInfo(), GetSwClusterManifestInfo().
• Update and Configuration Management (UCM):
  • Stereotyp: «aapFunctionalCluster» (Ausprägung: daemon-based).
  • Rolle: Nativer Service-Provider auf der lokalen Adaptive Platform Instanz (Machine).
  • Port: Stellt das Service-Interface über einen Server-Port mit Stereotyp «aapProvidedPort» bereit.
• Flashing Adapter (innerhalb Adaptive Application):
  • Stereotyp: Adaptive Application (Host-Prozess) kapselt die Komponente Flashing Adapter.
  • Rolle: Gateway-/Proxy-Provider. Implementiert dieselbe PackageManagement-Dienstschnittstelle, übersetzt Methodenaufrufe jedoch fahrzeugspezifisch in Diagnosedienste (z. B. UDS over DoIP / CAN ISO-TP gem. ISO 14229-1), um Classic AUTOSAR ECUs oder Mikrocontroller ohne eigenen UCM-Stack zu aktualisieren.
  • Port: Server-Port mit Stereotyp «aapProvidedPort».

Beziehungen & Abhängigkeiten

• VUCM → PackageManagement: Verwendungsabhängigkeit («use», «aapRequiredPort»). VUCM bindet als ara::com-Proxy dynamisch oder statisch an die Instanzen des Dienstes.
• UCM → PackageManagement: Schnittstellenrealisierung («aapProvidedPort»). UCM implementiert das Interface nativ als ara::com-Skeleton.
• Flashing Adapter → PackageManagement: Schnittstellenrealisierung («aapProvidedPort»). Der Flashing Adapter implementiert das Interface ebenfalls als ara::com-Skeleton, um nicht-adaptive Ziele transparent einzubinden.

3. Dynamisches Verhalten & Sequenzablauf

• Paketübertragung & Registrierung (Transfer-/Ingestion-Phase): VUCM überträgt Software-Pakete entweder klassisch blockweise über TransferStart(), TransferData() und TransferExit() (bzw. bricht mit DeleteTransfer() ab) oder registriert bereits lokal im Dateisystem bzw. Speicher abgelegte Pakete direkt über die Methode RegisterSoftwarePackage().
• Paketverarbeitung (Processing-Phase): Mittels ProcessSwPackage() initiiert VUCM die Validierung und Installation der Software-Cluster. Der Fortschritt sämtlicher asynchroner Vorgänge wird verallgemeinert über die Methode GetProgress() abgefragt; Statusänderungen werden über das Field CurrentStatus publiziert.
• Aktivierung & Abschluss (Activation-Phase): Activate() steuert das Umschalten auf die neuen Software-Versionen. Nach erfolgreichem Test schließt Finish() das Update ab, bereinigt temporäre Zustände und aktualisiert die Versionshistorie (GetHistory()).
• Fehlerbehandlung & Rollback: Bei Fehlern oder Abbruch (Cancel()) versetzen Rollback() oder RevertProcessedSwPackages() das Gesamtsystem zurück in die vorherige funktionale Softwarekonfiguration.
• Adapter-Protokolltransformation: Der Flashing Adapter setzt die Aufrufe der PackageManagement-Schnittstelle weiterhin auf spezifische UDS-Diagnosedienste für Classic-ECUs um, wobei auch registrierte Pakete direkt in nachgelagerte Flash-Sequenzen eingespeist werden können.

4. Normative Relevanz & Entwickler-Hinweise

• Access Control («aapAccessControlled»):
  • Alle Methoden und das Feld tragen den Stereotyp «aapAccessControlled».
  • Entwickler müssen zwingend IAM-Manifeste (Identity and Access Management) konfigurieren. Jeder aufrufende Prozess (VUCM) benötigt explizite Grant-Policies für die Schnittstelle; unberechtigte Aufrufe werden vom ara::com-Binding auf IPC/SOME/IP-Ebene verworfen.
• Abstraktion durch den Flashing Adapter:
  • Bei der Integration von Classic AUTOSAR ECUs muss der Applikationsentwickler den Flashing Adapter so entwerfen, dass UDS-Routinen (z. B. RoutineControl, TransferData Service 0x36, RequestTransferExit 0x37) 1:1 auf die PackageManagement-Methoden abgebildet werden.
  • Der Adapter muss UDS-Puffergrößen und Blocksequenzzähler transparent kapseln.
• Idempotenz & TransferTokens:
  • Aufrufe von TransferData() erfordern ein aktives, kryptografisch verifiziertes oder transaktionales Token (TransferToken), das von TransferStart() bezogen wird.
• Manifest- & Typ-Konsistenz:
  • Methoden wie GetSwClusterManifestInfo() und GetSwClusterChangeInfo() verlangen standardkonforme Serialisierung der Software-Cluster-Manifeste.
  • Für OEM-spezifische Flash-Abläufe muss das CurrentStatus-Feld zu jedem Zeitpunkt mit dem internen UCM-Zustandsautomaten synchronisiert sein, da VUCM hiervon den fahrzeugweiten Go/No-Go-Status ableitet.