Figure 13.5: Packaging steps

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Phasen- und Artefakt-Flussdiagramm (Deployment- und Packaging-Pipeline) im Funktionscluster Update and Configuration Management (UCM) der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Spezifikation des mehrstufigen Prozesses zur Transformation von Applikations-Quellcode, Persistenzdaten und ARXML-Modellbeschreibungen in kryptografisch abgesicherte Software Packages (SWCL-Ebene) und fahrzeugweite Vehicle Packages (OEM-Ebene) für OTA-Kampagnen (ara::ucm).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Rollen (Swimlanes)

• OEM (Develop SW): Stellt übergeordnete Systemmodelle bereit (Service, machine, SWCL designs in ARXML).
• Developer (Develop SW): Liefert Applikationsquellcode (Source code) und Initialisierungs-/Konfigurationsdaten für Persistenz (Data(PER)).
• Tier 1 Integrator (Integrate SW / Create SW pkg / Integrator Packager): Kompiliert Executables, assembliert Ausführungs- und Service-Instanz-Manifeste, bindet Vendor-Erweiterungen ein und packt/signiert das Backend Package.
• OEM Packager / OEM Backend / OEM Integrator: Re-zertifiziert bzw. aggregiert Software Packages, generiert das Vehicle Package und orchestriert die fahrzeugweite Update-Kampagne.

Entitäten & Datenstrukturen

• ARXML-Spezifikationen:
  • Service, machine, SWCL designs: Formale System-/Architekturmodelle.
  • Execution, service instance manifests: Binden Binaries an Prozesse, CPU-Cores, cgroups und definieren Service-Deployment/Endpunkte.
  • Software Package manifest(ARXML): Standardisierte Metadaten (Dependencies, Versionen, Rollback-Strategien, Ziel-SWCL).
• Laufzeit-Payload:
  • Executables: ELF-Binaries für die Zielarchitektur (POSIX/OS).
  • Data(PER): Initial- und Migrationsdaten für das Persistency-Cluster (ara::per).
  • Vendor specific extensions / formats (blauer Marker): Proprietäre Container-, Archivierungs- (z. B. OSTree, SquashFS) oder Manifestformate des Plattform-Zulieferers.
• Container- & Sicherheitsstrukturen:
  • Software Package A (Signed container): Gekapselte Binaries, Persistenzdaten und Manifeste, abgesichert über einen Authentication tag (MAC/Signatur).
  • Backend Package: Durch den Zulieferer geschnürtes Zwischenpaket, signiert mit dem Integrator Authentication tag.
  • Vehicle Package: Vom OEM-Backend geschnürtes Gesamtpaket, enthält referenzierte Software Packages, deren ARXML-Manifeste sowie den Vehicle Package manifest container zur UCM-Master-Steuerung.

Beziehungen & Kardinalitäten

• 1..* (Executable apps → SW Package): Ein Software Package bündelt eine oder mehrere ausführbare Anwendungen (Executables + Manifeste) eines Software Clusters.
• 1..* (Software Package A → Vehicle Package): Ein fahrzeugweites Update-Paket aggregiert n Software Packages verschiedener ECUs/Prozessoren.
• 1..* (Software Package manifest(ARXML) → Vehicle Package): Sämtliche normativen Paket-Manifeste der enthaltenen SWCLs werden im Vehicle Package konsolidiert.

3. Dynamisches Verhalten & Sequenzablauf

1. Entwicklung & Modellbereitstellung (Develop SW):
   • OEM definiert Service-, Machine- und Software-Cluster-(SWCL)-Architektur in ARXML.
   • Entwickler implementiert Quellcode gegen die generierten Plattform-Interfaces (ara::*) und definiert persistente Datenstrukturen.
2. Software-Integration (Integrate SW):
   • Zusammenführung von Code/Objektdateien, Persistenzdateien und Konfiguration der Ausführungs- sowie Service-Instance-Manifeste.
3. Erstellung des Software-Pakets (Create SW pkg):
   • Übersetzung zu Ziel-Binaries (Executable).
   • Einbindung herstellerspezifischer Metadaten (Vendor specific extensions) und der SWCL-Design-Vorgaben.
4. Zulieferer-Paketierung (Integrator Packager):
   • Innere Signierung: Payload (Executables, Data, Manifeste) wird in einen signierten Container gepackt, das herstellerspezifische Software Package manifest beigefügt und mit dem Authentication tag versehen.
   • Formale Manifestierung: Parallele Generierung des normativen Software Package manifest (ARXML) aus dem SWCL-Design.
   • Äußere Signierung: Kapselung in das Backend Package und Signierung durch den Tier-1 (Integrator Authentication tag).
5. OEM-Integration & Kampagnen-Erstellung (OEM Packager):
   • Validierung und Übernahme des Software Package A in das OEM-Backend.
   • Generierung des Vehicle Package, bestehend aus den ARXML-Paketmanifesten und dem Vehicle Package manifest container.
   • Übergabe an die Campaign orchestration zur Ausrollung über die Backend-OTA-Pipeline an den UCM-Master im Fahrzeug.

4. Normative Relevanz & Entwickler-Hinweise

• Standardisierungsgrenze vs. Vendor-Spezifika:
  • Standardisiert sind ausschließlich die ARXML-Manifeste (Software Package manifest (ARXML), Execution-/Service-Instance-Manifeste) sowie das UCM-Interface (ara::ucm::pkgmgr).
  • Das physikalische Containerformat (Archive, Kompression, Chunking) innerhalb von Software Package A ist herstellerspezifisch (blau indiziert). Toolchains müssen zur UCM-Target-Implementierung kompatibel sein.
• Dual-Authentication-Architektur:
  • Das Design erzwingt eine zweistufige Vertrauenskette: Die Integrität des Zulieferers (Integrator Authentication tag) wird im Backend oder beim Staging geprüft, während der innere Authentication tag und das Vehicle Package manifest die Authentizität gegenüber dem fahrzeuginternen UCM-Master sicherstellen.
• Granularität auf Software Cluster (SWCL):
  • Updates werden nicht auf Dateiebene, sondern streng pro Software Cluster ausgeführt. Applikationsentwickler dürfen keine zirkulären Abhängigkeiten zwischen SWCLs einziehen, da diese die UCM-Zustandsmaschinen (kPresent → kProcessing → kReady → kActivating) blockieren.
• Persistenz-Migration (Data(PER)):
  • Persistenzdaten im Paket müssen versioniert sein. Entwickler müssen bei Schemaänderungen Migrationsalgorithmen gemäß ara::per-Spezifikation vorsehen, da UCM die alten Datenbereiche bei SWCL-Updates isoliert oder migrieren muss.