DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-65df2a216c311370 438 × 669 px 1 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 65df2a216c3113704c293fc4edf5763235f7cf1e5ff724fa81d2857750ec494e

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R24-11 → R25-11 keine inhaltliche Änderung Vorgänger: FIG-e8ace08f70677df2

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» Vehicle Update and Configuration Management daemon-based | «aapAPI,aapAraComServiceInterface» | PackageManagement | «aapAccessControlled, aapServiceField» + CurrentStatus | «aapAccessControlled, aapServiceMethod» + Activate() + Cancel() + DeleteTransfer() + Finish() + GetHistory() + GetId() + GetProgress() + GetSwClusterChangeInfo() + GetSwClusterInfo() + GetSwClusterManifestInfo() + GetSwPackages() + ProcessSwPackage() + RegisterSoftwarePackage() + RevertProcessedSwPackages() + Rollback() + TransferData() + TransferExit() + TransferStart() | Adaptive Application «aapFunctionalCluster» Update and Configuration | Management | daemon-based | Flashing Adapter | «use» «aapRequiredPort» | «aapProvidedPort» «aapProvidedPort»

Begleitender Spezifikationstext:

Explanation of Adaptive Platform Software Architecture AUTOSAR AP R25-11 «aapAPI,aapNativeInterface» Logger + IsEnabled(): bool + Log(MsgId, Params) + LogDebug(): LogStream + LogError(): LogStream + LogFatal(): LogStream + LogInfo(): LogStream + LogVerbose(): LogStream + LogWarn(): LogStream + WithLevel(): LogStream «aapFunctionalCluster» Log and Trace «aapAPI,aapNativeInterface» ExecutionClient + Create() + ReportExecutionState(ExecutionState) «aapFunctionalCluster» Execution Management daemon-based «aapFunctionalCluster» Vehicle Update and Configuration Management daemon-based «aapAPI,aapNativeInterface» CryptoStack «aapFunctionalCluster» Cryptography daemon-based «use» «use» «use» Figure 9.98: Interfaces required by Vehicle Update and Configuration Management (part 2) Figure 9.99 shows the interfaces that are required by Vehicle Update and Configuration Management from Update and Configuration Management instances on the local and remote Machine(s) or Flashing Adapters that provide the same service for third-party systems. «aapFunctionalCluster» Vehicle Update and Configuration Management daemon-based «aapAPI,aapAraComServiceInterface» PackageManagement «aapAccessControlled, aapServiceField» + CurrentStatus «aapAccessControlled, aapServiceMethod» + Activate() + Cancel() + DeleteTransfer() + Finish() + GetHistory() + GetId() + GetProgress() + GetSwClusterChangeInfo() + GetSwClusterInfo() + GetSwClusterManifestInfo() + GetSwPackages() + ProcessSwPackage() + RegisterSoftwareP

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_EXP_SWArchitecture S. 146 9.99 Figure 9.99: Interfaces required by Vehicle Update and Configuration Management (part 3)