Figure 9.82: 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-Phase: TransferStart(), TransferData(), TransferExit(), DeleteTransfer().
    • Prozessierungs- & Aktivierungsphase: ProcessSwPackage(), Activate(), Finish(), RevertProcessedSwPackages(), Rollback(), Cancel().
    • Diagnose- & Abfrage-Operationen: GetId(), GetHistory(), GetSwPackages(), GetSwProcessProgress(), 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»). Ermöglicht Polymorphie auf Service-Ebene: VUCM interagiert identisch mit nativen UCM-Knoten und Legacy-Flashing-Knoten.

3. Dynamisches Verhalten & Sequenzablauf

Die Interaktion über die PackageManagement-Schnittstelle folgt dem standardisierten UCM-Zustands- und Transferzyklus:

sequenceDiagram
    autonumber
    participant VUCM as VUCM (Client / RequiredPort)
    participant Provider as UCM / Flashing Adapter (ProvidedPort)

    Note over VUCM,Provider: Phase 1: Transfer & Bereitstellung
    VUCM->>Provider: TransferStart(SoftwarePackageSize)
    Provider-->>VUCM: TransferToken
    loop Blocktransfer
        VUCM->>Provider: TransferData(TransferToken, BlockData)
        Provider-->>VUCM: Result / Progress
    end
    VUCM->>Provider: TransferExit(TransferToken)
    Provider-->>VUCM: Success

    Note over VUCM,Provider: Phase 2: Verifikation & Vorbereitung
    VUCM->>Provider: ProcessSwPackage(TransferToken)
    Provider-->>VUCM: Future / Result
    loop Polling / Notification
        VUCM->>Provider: GetSwProcessProgress(TransferToken)
        Provider-->>VUCM: CurrentProgress
    end

    Note over VUCM,Provider: Phase 3: Aktivierung & Abschluss
    VUCM->>Provider: Activate()
    Provider-->>VUCM: Success / RebootRequired
    VUCM->>Provider: Finish()
    Provider-->>VUCM: Operation Complete

    Note over VUCM,Provider: Fehlerpfade / Abbruch
    alt Fehler vor Aktivierung
        VUCM->>Provider: Cancel() / DeleteTransfer()
    else Fehler nach Aktivierung
        VUCM->>Provider: Rollback() / RevertProcessedSwPackages()
    end

• Dynamische Aspekte:
  • Asynchrone Ausführung: Methoden wie ProcessSwPackage(), Activate() und Rollback() sind langlebige Operationen, die über ara::core::Future / ara::core::Promise abgewickelt werden. Der Client fragt Zwischenzustände zyklisch über GetSwProcessProgress() ab oder überwacht das Notifier-Field CurrentStatus.
  • Fehler- und Rollback-Mechanik: Schlägt eine Paketprüfung fehl, greift Cancel() oder DeleteTransfer(). Tritt nach Activate() ein Validierungsfehler im Gesamtfahrzeug auf, forciert VUCM via Rollback() bzw. RevertProcessedSwPackages() den deterministischen Rücksturz in den Vorzustand.

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.