Figure 13.4: Overview Vehicle Package

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Strukturelles Paketierungs- und Sicherheitslayout / Container-Verschachtelungsdiagramm für Deployment- und OTA-Artefakte.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Update and Configuration Management (UCM, Spezifikationskontext AUTOSAR_EXP_PlatformDesign, Kapitel 13).
• Technischer Zweck: Spezifikation der Kapselung, Aggregation und kryptografischen Absicherung bei fahrzeugweiten Software-Updates. Das Diagramm definiert die strukturelle Entkopplung zwischen dem fahrzeugweiten Steuerungscontainer (Vehicle Package) auf Ebene des UCM Master und den maschinen-/knotenspezifischen Auslieferungseinheiten (Software Package) auf Ebene der UCM Subordinates.

2. Komponenten, Entitäten & Schnittstellen

Entitäten im fahrzeugweiten Kontext (Vehicle Package)

• Vehicle Package: Wurzel-Artefakt einer herstellerweiten Update-Kampagne, typischerweise assembliert durch das OEM-Backend.
  • Signed container: Kapselung der Metadaten zur Integritäts- und Authentizitätsprüfung.
  • OEM authentication tag: Kryptografische Signatur bzw. MAC des OEM-Backends zur Verifikation des gesamten Vehicle-Package-Inhalts durch den UCM Master.
  • Vehicle Package manifest: ARXML-basierte Steuerdatei für den UCM Master. Definiert Kampagnen-Orchestrierung, Fahrzeug-Zulassungsvoraussetzungen (Vehicle State/Safe State), Rollout-Reihenfolge, Ziel-Maschinen/Diagnoseadressen, Repository-URIs und die Mindestversion des UCM Masters (Minimum supported UCM Master version).
  • Software Package manifest A / B: Aus den Backend-Packages extrahierte ARXML-Manifeste der Ziel-Softwarepakete. Sie werden ohne die eigentliche Nutzlast (Payload) im Vehicle Package gebündelt.

Entitäten im knotenspezifischen Kontext (Software Package A / B)

• Software Package (A / B): Physische Übertragungseinheit für ein Steuergerät / eine Adaptive Machine.
  • Software Package Manifest: ARXML-Metadatenbeschreibung des Pakets (Aktionen: Add/Update/Remove, Ziel-SoftwareCluster, Integritäts-Hashes, Größenangaben).
  • Authentication tag (äußere Ebene): Signatur des Paketerstellers (Tier-1 oder OEM-Build-Pipeline) zur Absicherung des Gesamtpakets.
  • SoftwareCluster (A / B): Atomare Deployment- und Lifecycle-Einheit der Adaptive Platform.
    • Signed container (innere Ebene): Payload-Container, separat abgesichert über einen internen Authentication tag.
    • Executables: ELF-Binärdateien der Adaptive Applications.
    • Data: Initialisierungs-, Konfigurations- und Persistenzdaten.
    • Manifests: Service Instance Manifests und Execution Manifests der enthaltenen Prozesse.
    • Software Cluster Manifest: ARXML-Beschreibung der Cluster-Eigenschaften, Cluster-Typ, Versionierung und Abhängigkeiten zu anderen Software Clustern.

Beziehungen & Kardinalitäten

• 1 : n Aggregation: Ein Vehicle Package aggregiert genau ein Vehicle Package manifest und n extrahierte Software Package Manifests (n ≥ 1).
• 1 : 1 Referenz: Jedes extrahierte Software Package manifest im Vehicle Package referenziert über eindeutige Identifier/URIs exakt das zugehörige externe Software Package (dessen Manifest identisch ist).
• 1 : 1 Kapselung: Ein Software Package kapselt genau einen SoftwareCluster (bzw. ein differentielles Delta dieses Clusters).
• Mehrstufige Sicherheitskette: Verschachtelte Authentifizierungsebenen (OEM authentication tag auf Kampagnenebene → Authentication tag auf Paket-Ebene → Authentication tag auf SoftwareCluster-Ebene).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm impliziert die zweistufige Entkopplung von Kampagnen-Validierung und Nutzlast-Download im OTA-Ablauf:

1. Kampagnen-Ingestion: Das OEM-Backend überträgt das Vehicle Package an den UCM Master im Fahrzeug.
2. Authentifizierung Stufe 1: UCM Master validiert den Signed container anhand des OEM authentication tag über den AUTOSAR Crypto Stack (ara::crypto). Bei fehlerhafter Signatur erfolgt sofortiger Abbruch.
3. Vorab-Kompatibilitätsprüfung (Fail-Early-Prinzip):
   • UCM Master parst das Vehicle Package manifest und prüft die Mindestversion (Minimum supported UCM Master version) sowie Fahrzeug-Prärequisiten.
   • Anhand der eingebetteten Software Package manifest A/B validiert UCM Master systemweite Abhängigkeiten, Speicherplatz und Zielkonfigurationen, ohne dass die volumenintensiven Binärdaten der Software Packages zuvor geladen werden müssen.
4. Verteilung & Download-Trigger: UCM Master orchestriert den Transfer der vollständigen Pakete (Software Package A, Software Package B) aus dem Backend/Pufferspeicher zu den jeweiligen UCM Subordinates auf den Ziel-ECUs.
5. Authentifizierung Stufe 2 & Deployment: Der UCM Subordinate empfängt das knotenspezifische Paket, prüft die äußeren und inneren Authentication tags, extrahiert Executables/Manifeste und steuert die Zustandsübergänge (Transfer → Prepare → Activate → Commit).

4. Normative Relevanz & Entwickler-Hinweise

• Standardisierungszwang für Manifeste vs. Container:
  • Alle Manifest-Dateien (Vehicle Package manifest, Software Package Manifest, Software Cluster Manifest) müssen zwingend dem normierten AUTOSAR-ARXML-Schema entsprechen, um hersteller- und werkzeugunabhängig vom UCM Master verarbeitet werden zu können.
  • Das physische Archiv- und Kompressionsformat der Signed container (Payload) ist herstellerspezifisch (z. B. TAR, ZIP oder proprietäre Container).
• Bandbreiten- & Speicheroptimierung: Embedded-Entwickler auf UCM-Master-Systemen müssen im Filesystem-Layout Puffer für das Vehicle Package vorhalten, profitieren aber davon, dass Inkompatibilitäten erkannt werden, bevor Gigabytes an Binärdaten über Automotive-Busse (Ethernet/SOME/IP) gestreamt werden.
• Crypto- & Trust-Anchor-Konfiguration:
  • Der UCM Master benötigt Zugriff auf den OEM-Root-of-Trust zur Verifikation des OEM authentication tag.
  • UCM Subordinates benötigen Zertifikate/Schlüssel zur Verifikation der individuellen Authentication tags (ggf. Tier-1-Zertifikate). Beide Instanzen erfordern die Bereitstellung entsprechender Key-Slots via ara::crypto.
• Software-Modularisierung: Applikations- und Funktionsentwickler liefern Artefakte ausschließlich innerhalb eines SoftwareCluster ab. Die Trennung von Executables, Data und Manifests erzwingt eine saubere Trennung von statischem Programmcode und zustandsbehafteten Daten für A/B-Partitions-Updates.