Figure 12.2: Exemplary deployment of Software Packages on a Machine

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Verteilungsdiagramm (Deployment Diagram) / Software-Packaging- und Schichtenstrukturmodell der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext & Zweck:
  • Formalisierung der Auslieferungs- und Installationsgranularität von Softwarekomponenten auf einer «device» Machine mittels des Update and Configuration Management (UCM).
  • Strukturierung der Software in logische SoftwareCluster via Manifest-Artefakte mit Festlegung der Verantwortlichkeiten (machineVendor, platformVendor, user/OEM) und Abhängigkeitshierarchien für Deployment, Versionierung und OTA-Updates.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «device» Machine: Physische oder virtualisierte Recheneinheit (ECU / SoC / VM).
  • Bootloader / Hypervisor (Rolle: machineVendor): Hardware-nahe Initialisierungsinstanz unterhalb der Platform-Grenze.
• «software package» (Deployment-Container):
  • Platform Core Package (Rolle: platformVendor):
    • Tag: Multiplicity = 1 (exakt eine Instanz pro Machine; nicht entfernbar).
    • Tag: SoftwareCluster.category = PLATFORM_CORE.
  • Platform Package (Rolle: platformVendor):
    • Tag: Multiplicity = * (0..n optionale/erweiternde Plattform-Pakete).
    • Tag: SoftwareCluster.category = PLATFORM.
  • Application Package (Rolle: user):
    • Tag: Multiplicity = * (beliebig viele Applikations-Pakete).
    • Tag: SoftwareCluster.category = APPLICATION_LAYER.
• Funktionale Cluster («aapFunctionalCluster», daemon-based) & Systemkomponenten:
  • Zugeordnet zu Platform Core Package (über «manifest»-Assoziation):
    • Execution Management (EM): Prozessstart, Lifecycle, Deterministic Client.
    • State Management (SM): Funktions-/Zustandssteuerung der Machine.
    • Update and Configuration Management (UCM): Paketverwaltung, A/B-Partitioning, Update-Orchestrierung.
    • Platform Health Management (PHM): Alive-/Deadline-/Logical-Supervision.
    • Operating System (Rolle: machineVendor): POSIX-kompatibles OS (PSE51/PSE52).
    • Watchdog (Rolle: machineVendor): Hardware-Watchdog-Treiber/Anbindung.
  • Zugeordnet zu Platform Package (über «manifest»-Assoziation):
    • Diagnostic Management (DM): UDS-/DoIP-Server-Daemon.
    • Cryptography (Crypto): Crypto-Treiber/Daemon, Key Storage.

Relationen & Abhängigkeiten

• Paket-Abhängigkeiten (Dashed Arrows):
  • Application Package → Platform Core Package (zwingend) und optional Application Package → Platform Package.
  • Platform Package → Platform Core Package (Plattform-Erweiterungen basieren stets auf dem unteilbaren Kern).
• Manifest-Mapping («manifest»):
  • Verknüpft die kompilierte Binär- und Konfigurationsrepräsentanz der Dämonen/Bibliotheken deklarativ mit dem jeweiligen SoftwareCluster.

3. Dynamisches Verhalten & Lifecycle

Obgleich ein statisches Deployment-Diagramm dargestellt ist, bedingt die Struktur deterministische dynamische Abläufe:

• Bootstrapping & Anlaufsequenz:
  1. Bootloader / Hypervisor initialisiert Hardware und startet das Operating System.
  2. OS startet den Init-Prozess des Platform Core Package: Execution Management übernimmt die PID-1-nahe Kontrolle.
  3. EM instanziiert State Management, PHM und UCM basierend auf dem Machine Manifest und Execution Manifest.
  4. Nach Erreichen des entsprechenden Machine/Function Groups State startet EM nachgelagerte Dämonen (Platform Package) und Application Packages.
• Update- & Konfigurations-Workflow (UCM):
  • Updates erfolgen clusterweise. Ein Platform Core Package kann im laufenden Betrieb nicht deinstalliert (TransferExit → ProcessSwPackage), sondern nur atomar im Ganzen aktualisiert werden (z. B. Dual-Bank/A-B-Swapping via Bootloader/UCM).
  • Application Packages können unabhängig hinzugefügt, aktualisiert oder deinstalliert werden, sofern ihre semantischen Abhängigkeiten (Version Constraint auf SoftwareCluster.category = PLATFORM / PLATFORM_CORE) erfüllt sind.
• Fehlerbehandlung:
  • Watchdog-Fehler triggern Recovery-Eskalation über PHM → SM → EM (bis hin zum Machine Reset / Rollback auf die vorherige Core-Partition).

4. Normative Relevanz & Entwickler-Hinweise

• Multiplizitäts-Invariante: Es darf pro Machine exakt ein SoftwareCluster mit category = PLATFORM_CORE existieren (Multiplicity = 1). Ein System ohne PLATFORM_CORE ist ungültig.
• Mindestumfang PLATFORM_CORE:
  • Muss zwingend Execution Management, State Management und UCM beinhalten. Grund: Ohne diese drei Cluster ist weder Prozess-Supervision noch das Einspielen/Entpacken weiterer Software Packages möglich.
• Manifest-Modellierung (ARXML):
  • Entwickler müssen sicherstellen, dass jedes SoftwarePackage exakt einem SoftwareCluster zugeordnet ist.
  • In SoftwareCluster ist category typkonform auf PLATFORM_CORE, PLATFORM oder APPLICATION_LAYER (bzw. APPLICATION) zu setzen.
• Lieferanten- & Integrationsschnittstelle (Role Segregation):
  • machineVendor liefert OS, BSP, Watchdog-Treiber und Bootloader.
  • platformVendor liefert die standardisierten AUTOSAR AP Functional Cluster und muss POSIX-OS-Calls kapseln.
  • user (Applikationsentwickler) darf ausschließlich gegen APPLICATION_LAYER-Pakete entwickeln und über standardisierte ARA-APIs (ara::com, ara::exec, ara::phm etc.) mit den Dämonen kommunizieren – direkter Zugriff auf OS- oder Plattform-Treiber ist normativ untersagt.