Figure 13.7: Packages distribution to vehicle

1. Diagrammtyp & Architektur-Kontext

Konzeptionelles Architektur-, Prozess- und Datenflussdiagramm im Kontext der AUTOSAR Adaptive Platform, Domäne Update and Configuration Management (UCM). Das Schaubild visualisiert die durchgängige End-to-End-Verteilungskette von Software- und Fahrzeugpaketen (Vehicle Packages) aus einer OEM-Backend-Infrastruktur an ein vernetztes Fahrzeug mit heterogener E/E-Architektur (Adaptive AUTOSAR, Classic AUTOSAR, Non-AUTOSAR/IVI/COTS).

2. Komponenten, Entitäten & Schnittstellen

• OEM Backend:
  • Integrator A repo & Integrator B repo: Externe Integrator-Repositories, liefern Software-Artefakte (Backend package A, Backend package B).
  • Software catalog: Zentraler Backend-Katalog zur Verwaltung von Softwareständen und Erzeugung einzelner Software Package-Artefakte samt Software Package manifest.
  • VIN database: Fahrzeugdatenbank, verwaltet fahrzeugspezifische Konfigurations- und Softwarestände (über Soft list) und speist die Bordnetz-Architektur (Architecture) in die Kampagnenverwaltung ein.
  • Campaign orchestrator: Kampagnensteuerung, wird vom EE System engineer (OEM) (Rolle @dev) konfiguriert; übergibt Orchestrierungsparameter (Campaign orchestration, UCM identifier) an den Packager.
  • Key manager: Schlüsselverwaltung zur kryptografischen Absicherung und Signaturerstellung.
  • Vehicle packager: Generiert das übergeordnete Vehicle package, welches die aggregierten Software-Pakete (Software Package A, Software Package B mit Executables, Data, Manifests, UCM-Manifest und Signaturen) sowie ein Vehicle package manifest und die OEM signature kapselt.
• Fahrzeug (Vehicle Domain):
  • Anbindung über Funkmast (Internet ETSI / Telematik-Gateway).
  • Heterogene Bordnetz-Topologie mit Steuergeräte-Knoten: Adaptive AUTOSAR (Knoten A), Classic AUTOSAR (Knoten C, M), non-AUTOSAR IVI / COTS sowie Netzwerkknoten (N).

3. Dynamisches Verhalten & Sequenzablauf

Der Verteilungs- und Update-Prozess umfasst die Paketgenerierung im Backend sowie den Nachrichtenaustausch mit dem Fahrzeug über zwei Abfragepfade (Pull/Push bzw. Zustandsabgleich) und eine Ergebnisquittierung:

1. Paketbereitstellung im Backend: Integrator-Repos speisen Backend-Pakete in den Software catalog ein. Der Campaign orchestrator verknüpft Systementwickler-Vorgaben mit der Zielarchitektur aus der VIN database und instruiert den Vehicle packager, der unter Hinzuziehung von Schlüsseln des Key manager ein signiertes Vehicle package erzeugt.
2. Versionsabgleich & Auslieferung (Schritte 1 & 2):
   • Pfad 1 (Fahrzeug-getrieben): Das Fahrzeug überträgt seinen aktuellen Versionsstatus an das Backend (1. Q: These are my versions statuses).
   • Pfad 2 (Backend-/VIN-getrieben): Das Fahrzeug bzw. Backend initiiert eine Abfrage basierend auf der Fahrgestellnummer (2. Q: Or what are your versions ? + VIN bzw. Aufforderung 2. Q: Please upload versions list), woraufhin das Backend den Soll-Stand ermittelt (2. A: My last versions for your VIN).
   • Bereitstellung (1&2. A): Das OEM-Backend übermittelt das maßgeschneiderte Vehicle package an das Fahrzeug.
3. Aktivierung & Quittierung (Schritt 3):
   • Das Fahrzeug verteilt und verarbeitet die Pakete auf den Zielknoten (Adaptive UCM, Classic AUTOSAR, IVI/COTS).
   • Das Gesamtergebnis der Aktivierung wird an die VIN database im OEM-Backend zurückgemeldet (3. Activation(s) result(s)), um den Fahrzeugdatenbestand zu aktualisieren.

4. Normative Relevanz & Entwickler-Hinweise

Das Diagramm entstammt dem erklärenden Dokument AUTOSAR_AP_EXP_PlatformDesign und besitzt informativen Charakter zur Einordnung des Vehicle Update and Configuration Management (VUCM / UCM Master). Die normativen Anforderungen an Paketstrukturen und Schnittstellen sind in AUTOSAR SWS Update and Configuration Management sowie AUTOSAR TPS Manifest Specification spezifiziert:

• Entwickler müssen sicherstellen, dass die im Vehicle package eingebetteten Software Package-Artefakte dem AUTOSAR-UCM-Paketformat entsprechen und kryptografisch validierbar sind (OEM signature, UCM signature).
• Der fahrzeugseitige UCM Master muss in der Lage sein, Software-Updates über heterogene Kommunikationsbusse an Classic-ECUs (z. B. via UDS/Diagnostic Log and Trace oder Gateway-Protokolle) und Non-AUTOSAR-Systeme (IVI) zu koordinieren.
• Backend-seitige APIs (Software catalog, VIN database, Campaign orchestrator) sind herstellerspezifisch implementierbar, wohingegen die Übergabeformate (Vehicle Package Manifest, Software Package Manifest) dem AUTOSAR-Standard folgen müssen.