Figure 13.6: Packages distribution to vehicle

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Artefakt- und Toolchain-Ablaufdiagramm (Software-Release- und Packaging-Pipeline).
• Technischer Zweck: Darstellung des mehrstufigen Aggregations- und Signierprozesses zur Erstellung von Software-Paketen im Rahmen des Update and Configuration Management (UCM) der AUTOSAR Adaptive Platform.
• Funktionale Einordnung: Veranschaulicht die vorgelagerte Build-/Release-Phase (Außerhalb des Fahrzeugs / Backend-Vorbereitung). Zulieferer-Artefakte werden zu einem logischen Software Cluster (SoftwareCluster, kurz: SWCL) gebündelt, über standardisierte UCM-Packaging-Tools verpackt, zur Traceability signiert und in einem Repository für das OEM-Backend bereitgestellt, bevor sie via OTA oder Werkstatt-Tester an den fahrzeuginternen UCM Master übertragen werden.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Rollen:
  • Vendor B / Vendor C: Unabhängige Tier-1/Tier-2-Zulieferer, die spezifische Teillieferungen erbringen.
  • Integrator: Hauptverantwortliche Integrationsinstanz (Tier-1 oder OEM-Softwarehaus); aggregiert Fremd- und Eigenartefakte, führt das Packaging aus und signiert das finale Paket.
  • Adaptive Autosar UCM developer (OEM, vendor): Stellt dem Integrator die normkonforme Werkzeugkette (Packager) zur Verfügung.
• Dargestellte Artefakte & Datenstrukturen:
  • Executable: Kompilierte Binärdateien (ELF-Executables) für das Ziel-POSIX-Betriebssystem.
  • Persistency: Persistenz-Konfigurationen und -Speicherstrukturen (Schemas, Initialisierungsdaten, Key-Value- oder File-Storage-Definitionen gemäß ara::per).
  • Configuration files: Manifeste (v. a. ExecutionManifest, ServiceInstanceManifest) und System-/Netzwerkkonfigurationen.
  • SWCL (SoftwareCluster): Zentrale AUTOSAR Adaptive Deployment- und Update-Einheit, die logisch zusammengehörige Executables, Manifeste und Ressourcen versionsgenau kapselt.
  • Packager: Tooling-Komponente, welche die SWCL-Bestandteile in ein archiviertes, komprimiertes und manifest-beschriebenes Software-Paket überführt.
  • Backend package: Distributionsfertiges Software-Paket inklusive SoftwarePackageManifest, Payload und kryptografischen Metadaten.
  • Integrator repository: Artefakt-Repository des Integrators, aus welchem der OEM die Pakete für Backend-/Flotten-Kampagnen abruft.
• Kardinalitäten & Beziehungen:
  • n : 1 Aggregation: Mehrere diskrete Lieferungen (Vendor B, Vendor C, Integrator) fließen in ein einzelnes SWCL ein.
  • 1 : 1 Transformation: Ein SWCL wird durch genau einen Packager in ein Backend package gewandelt.
  • Asymmetrische Abhängigkeit: Der Packager wird extern bereitgestellt (provide) durch den Plattform-/UCM-Entwickler.

3. Dynamisches Verhalten & Sequenzablauf

1. Artefakt-Bereitstellung (Zulieferer-Ebene):
   • Vendor C steuert Binaries (Executable) und Persistenzmodelle bei.
   • Vendor B liefert Konfigurationsdateien/Manifeste und Persistenzmodelle zu.
   • Der Integrator steuert eigene/plattformbezogene Executable-Anteile bei.
2. Cluster-Kompilation & Aggregation:
   • Zusammenführung aller Artefakte und formalen ARXML-Beschreibungen zum Gesamtsystem SWCL.
   • Auflösung von Abhängigkeiten zwischen den Prozessen innerhalb des Software-Clusters.
3. Packaging & Signierung:
   • Der Packager generiert das standardisierte Paketformat.
   • Der Integrator versieht das Paket mit einer digitalen Signatur ("Integrator signing package for traceability"), um Herkunft, Vollständigkeit und Nachverfolgbarkeit in der Lieferkette abzusichern.
4. Bereitstellung für Backend/OEM:
   • Ablage des Backend package im Integrator repository.
   • Freigabe für das OEM-Backend ("Available for OEM") zur weiteren Vorbereitung von OTA-Kampagnen (z. B. Hinzufügen der OEM-Signatur zur Fahrzeug-Authentifizierung).

4. Normative Relevanz & Entwickler-Hinweise

• UCM-Paketstandard: Das erzeugte Backend package muss dem AUTOSAR UCM Software Package Format entsprechen (enthält u. a. SoftwarePackageManifest.arxml, Rootfs-Deltas bzw. Tar/Zip-Container).
• Zulieferer-Entkopplung: Entwickler von Sub-Komponenten (Vendor B/C) müssen strikt gegen die standardisierten Adaptive-Schnittstellen (ara::*) und Manifest-Modelle entwickeln. Eine direkte Abhängigkeit zum Build-System des Integrators entfällt; die Übergabe erfolgt rein über definierte Artefakte (Executable, Persistency, Configuration).
• Signature Chaining & Trust Anchor: Die im Bild genannte Signatur des Integrators dient primär der Traceability in der Supply Chain. Embedded-Entwickler auf Fahrzeugseite (UCM Subordinate / UCM Master) prüfen typischerweise gegen im Fahrzeug hinterlegte OEM-Trust-Anchors (X.509 / PKI). Das OEM-Backend muss das Integrator-Paket entweder re-signieren oder als Teil einer Zertifikatskette validierbar machen.
• Persistenz-Kompatibilität: Da persistente Daten über Software-Updates hinweg erhalten bleiben müssen (ara::per), müssen Persistenz-Artefakte Migrationsstrategien (Update-Handler, Initial-Data-Schemas) enthalten, um Datenverlust beim SWCL-Upgrade im Fahrzeug zu verhindern.