Figure 13.3: Overview Backend Package

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Physisches Artefakt- und Container-Strukturmodell (hierarchisches Schachtelungs- und Signatur-Layout).
• Technischer Zweck: Standardisierung des Software-Paketformats an der Schnittstelle zwischen Komponenten-Zulieferern (Tier-1/Vendors), dem OEM-Backend und dem fahrzeugseitigen Update-Subsystem.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Subsystem Update and Configuration Management (UCM), spezifiziert in AUTOSAR_AP_EXP_PlatformDesign (Kapitel 13: Update and Configuration Management, Abschnitt 13.3.2 Backend package), gültig für die Releases R21-11 bis R25-11.
• Funktionale Einordnung: Dient der Sicherstellung einer durchgängigen Vertrauenskette (End-to-End Chain of Trust), der Entkopplung von Zulieferer-Payloads und OEM-Integrationsdaten sowie der Einhaltung regulatorischer Homologationsvorgaben (UN ECE R156 / WP.29 SUMS via RXSWIN) bei OTA- und Tester-basierten Software-Updates.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert eine zweistufig verschachtelte Kapselungs- und Authentifizierungsstruktur (Vendor-Ebene gekapselt in Packager-/OEM-Ebene):

1. Äußere Kapselungsebene: Backend Package (OEM- / Packager-Scope)

• Backend Package (Root-Container): Physischer Gesamtcontainer, der im OEM-Backend zur Distribution an das Fahrzeug erzeugt wird.
• Signed Container (äußerer Container): Umschließt das gesamte Zulieferer-Paket (Software Package A) sowie das übergeordnete OEM-Manifest.
• Software Package manifest (äußeres Manifest, dunkelrot): Enthält floskel- und transportrelevante Steuerungsmetadaten für das Zielsystem:
  • Packager: Vendor-ID des Paketierers (OEM/Tier-1).
  • Type Approval: Homologationskennung (z. B. RXSWIN nach UN ECE WP.29).
  • Release Notes & License: Metadaten, rechtliche Parameter (z. B. GPL, MIT, proprietär).
  • Estimated duration of operation: Zeitbudget für Transfer, Dekomprimierung, Integritätsprüfung und Aktivierung.
  • Distribution & Routing: Diagnoseadresse (Diagnostic address) zur Adressierung der zuständigen Ziel-UCM-Instanz im Fahrzeugverbund.
  • Action type: install, update oder remove.
  • Activation action: Zu initiierende Systemreaktion (nothing, restartApplication via Execution Management, reboot via State Management/Machine State).
• Authentication tag (äußeres Tag, violett): Kryptografische Signatur bzw. MAC des Packagers zur Überprüfung der Konsistenz und Authentizität des gesamten Signed container durch die UCM-Instanz.

2. Innere Kapselungsebene: Software Package A (Vendor-Scope)

• Software Package A: Eigenständiges, von einem Zulieferer bereitgestelltes Softwarepaket für einen spezifischen SoftwareCluster.
• Signed container (innerer Container): Umschließt direkt die auszuführende Applikations-Payload:
  • Executables: Kompilierte ELF-Binaries der Adaptive Applications.
  • Data: Statische Konfigurations-, Asset- und Kalibrierungsdateien.
  • manifests: ARXML-Applikationsmanifeste (Execution Manifests, Service Instance Manifests).
• Software Package manifest (inneres Manifest, grau mit roter Kontur): Zuliefererspezifisches Manifest mit Vendor-ID, Cluster-Abhängigkeiten (Dependencies) und Hash-Bäumen der Binaries/Daten.
• Authentication tag (inneres Tag, blau mit roter Kontur): Signatur des Zulieferers zur Validierung der Payload-Unversehrtheit vor der Einbettung ins OEM-Backend.

3. Dynamisches Verhalten & Sequenzablauf

Aus der Kapselung resultiert ein mehrstufiger Erstellungs-, Validierungs- und Entpackungsprozess:

[Vendor Build Pipeline]
   │ Erzeugt Executables, Data, Manifests
   │ Signiert inneren Container -> Vendor Authentication Tag
   ▼
[OEM Backend Pipeline]
   │ Validiert Vendor Authentication Tag
   │ Reichert Paket an (Diagnostic Address, RXSWIN, Activation Action)
   │ Signiert äußeren Container -> Packager Authentication Tag
   ▼
[Fahrzeug: UCM / Transfer]
   │ 1. Empfang via OTA-Client oder UDS (Diagnostic Address)
   │ 2. Verifikation Packager Authentication Tag via ara::crypto
   │    └── Abbruch bei Mismatch (kAuthenticationFailed / kPackageInconsistent)
   │ 3. Auswertung äußeres Manifest (Action type, Duration, Rollout-Checks)
   │ 4. Verifikation inneres Vendor Authentication Tag (Integritätskette)
   │ 5. Payload-Deployment (Executables/Data an Zielpfade)
   │ 6. Orchestrierung der Activation action (Process Restart / Machine Reboot)

• Fehlerpfade: Schlägt die Prüfung des äußeren Tags fehl, wird das Paket sofort verworfen (keine Dekomprimierung). Schlägt die Prüfung des inneren Tags fehl, meldet UCM einen Fehler an das Backend und verhindert die Persistierung in den Software-Cluster-Speicherbereich.
• Synchronisation: Die Ausführung der Activation action wird vom UCM über standardisierte Inter-Process-Communication-Schnittstellen an das State Management (SM) oder Execution Management (EM) delegiert.

4. Normative Relevanz & Entwickler-Hinweise

• Schnittstelle UCM & Crypto Stack (ara::crypto):
  • Das UCM-Modul muss für die Validierung beider Zertifikatsebenen konfiguriert sein: Der Root-of-Trust für den Packager (OEM-Backend) muss zwingend im lokalen Key Storage liegen; der Public Key/Zertifikatspfad des Vendors muss für Multi-Tier-Szenarien auflösbar sein.
• Manifest-Modellierung (ARXML):
  • Applikationsentwickler liefern ausschließlich die Artefakte für den inneren Container samt ExecutionManifest.
  • Das äußere SoftwarePackageManifest darf erst im Release- und Backend-Integrationsschritt erzeugt werden, da Attribute wie Diagnostic address, Homologationsdaten (RXSWIN) und maschinenweite Activation action vom Gesamtfahrzeug-Release abhängen.
• Laufzeit- und Ressourcenbudgetierung:
  • Der Parameter Estimated duration of operation ist bindend für das Watchdog- und Session-Timeout-Handling während des Update-Vorgangs (z. B. UDS RequestCorrectlyReceived-ResponsePending $78).
  • Die Wahl von Activation action = reboot erzwingt eine koordinierte Quiescence-Phase aller funktionellen Prozesse durch das State Management zur Vermeidung von Datenkorruption vor dem Kalt-/Warmstart.