Figure 13.2: Overview Software Package

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Physisches Artefakt- / Kapselungs-Layout (Packaging & Container Structure Diagram).
• Technischer Zweck: Spezifikation der hierarchischen Kapselungs- und Sicherheitsarchitektur für Software-Bereitstellungen im Functional Cluster UCM (Update and Configuration Management) der AUTOSAR Adaptive Platform (AP).
• Architektonische Einordnung: Trennung der Transport- und Übergabeeinheit (Software Package) von der auf der Adaptive Machine deploybaren und eigenständig versionierten Funktionseinheit (Software Cluster). Das Schema visualisiert das Konzept der mehrstufigen kryptografischen Integritäts- und Authentizitätssicherung (Nested Security Containers).

2. Komponenten, Entitäten & Schnittstellen

Das Schaubild gliedert sich in zwei hierarchisch verschachtelte Security-Container:

1. Äußere Ebene: Software Package (Software Package A)

• Transporteinheit (Delivery Unit): Das Artefakt, welches über Diagnoseschnittstellen (UDS) oder OTA-Dienste an den UCM übertragen wird.
• Signed Container (äußerer Container):
  • SoftwareCluster A: Der gekapselte Nutzlast-Cluster.
  • Software Package Manifest: ARXML-Manifest mit Metadaten zur Paketverarbeitung:
    • Pakettyp (z. B. Neukonfiguration, Update, Deinstallation).
    • Zielsystem-/Machine-Zuweisung, Abhängigkeiten (softwareClusterRequirements), Vor-/Nachinstallationsschritte.
• Authentication tag (äußeres Tag): Kryptografische Signatur (z. B. CMS/PKCS#7, RSA-PSS, ECDSA) oder MAC. Schützt das gesamte Software Package inklusive Software Package Manifest gegen Manipulation während der Übertragung.

2. Innere Ebene: Software Cluster (SoftwareCluster A)

• Bereitstellungseinheit (Deployable Unit): Unabhängig aktualisierbare, lauffähige logische Einheit auf der Ziel-Machine.
• Signed Container (innerer Container):
  • Executables: Binärdateien (ELF-Executables) für POSIX-Prozesse.
  • Data: Kalibrierdaten, Konfigurationsdateien, Persistenz-Init-Daten oder statische Assets.
  • Manifests: Maschinenspezifische Anwendungsbeschreibungen:
    • Execution Manifests (Prozessdefinition, Startup-Konfiguration, Resource-Group-Mapping).
    • Service Instance Manifests (Service-Deployment, IPC-/SOME/IP-Bindings).
  • Software Cluster Manifest: Formales ARXML-Manifest des Clusters (Cluster-Version, Root/Application Cluster Typisierung, Lizenzen, Zustandsabhängigkeiten).
• Authentication tag (inneres Tag): Cluster-spezifische Signatur/MAC. Gewährleistet Integrität und Authentizität der eigentlichen Software-Artefakte losgelöst vom Transportmedium.

3. Dynamisches Verhalten & Sequenzablauf

Aus der Schachtelung ergibt sich die deterministische Verifikations- und Verarbeitungsfolge im UCM (PackageManagement):

1. Ingestion & Transport-Validierung:
   • UCM empfängt Software Package A (via TransferPackage, TransferData, TransferExit).
   • Verifikation des äußeren Authentication tag gegen das hinterlegte Trust Anchor / UCM-Zertifikat.
   • Abbruchbedingung: Ungültige Signatur/MAC führt zum sofortigen Verwerfen des Pakets (kAuthenticationFailed).
2. Paket-Evaluation:
   • Auslesen des Software Package Manifest.
   • Validierung von Abhängigkeiten, Ziel-Plattform-Kompatibilität, Speicherkapazität und Pre-Conditions.
3. Cluster-Extraktion & Payload-Authentifizierung:
   • Entpacken von SoftwareCluster A.
   • Verifikation des inneren Authentication tag über den Crypto Stack (ARA::Crypto).
   • Validierung aller Hashes gegen die im Software Cluster Manifest und den Execution Manifests deklarierten Prüfsummen.
   • Abbruchbedingung: Integritätsverletzung an Binaries/Manifesten triggert Abbruch und Rollback vor Systemaktivierung.
4. Staging & Aktivierung:
   • Übergabe an Execution Management (EM) und State Management (SM) zur Einbindung der Executables in den Boot- bzw. Lifecycle-Pfad.

4. Normative Relevanz & Entwickler-Hinweise

• Build- & CI/CD-Pipelines:
  • Deployment-Generatoren müssen eine zweistufige Signatur implementieren:
    1. Cluster-Inhalt (Binaries, Manifests, Data) bauen, Software Cluster Manifest erzeugen, inneren Container packen und mit dem Cluster-Key signieren.
    2. Software Package schnüren (Software Package Manifest + innerer Container) und mit dem UCM-/OEM-Key signieren.
• Schlüsselmanagement & Mandantentrennung (OEM vs. Tier-1):
  • Die zweistufige Struktur erlaubt getrennte Vertrauensdomänen: Der Tier-1/Zulieferer signiert den Software Cluster (inneres Tag, Schutz geistigen Eigentums und Code-Integrität ab Werk), während der OEM das Transport-Paket für das Gesamtfahrzeug autorisiert (äußeres Tag).
• POSIX & Persistenz-Layout:
  • Entwickler dürfen Pfade für Data und Executables nicht hart codieren. Pfadresolution erfolgt relativ zu den im Manifest deklarierten Mount-Points des Software Clusters auf dem Dateisystem der Adaptive Machine.
• Manifest-Konsistenz:
  • Jede Executable im Container muss eine exakte 1:1-Entsprechung im Execution Manifest besitzen (StartupConfig, Process), da der Execution Manager nicht manifestierte Binaries im Cluster ignoriert bzw. deren Ausführung aus Sicherheitsgründen blockiert.