Figure 12.1: Exemplary vehicle software update scenario

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Verteilungsdiagramm (Deployment Diagram) mit Komponenten- und Manifest-Spezifikationen, formal erweitert um AUTOSAR Adaptive Platform Functional Clusters («aapFunctionalCluster») mit Daemon-Semantik.
• Technischer Zweck: Abbildung der entkoppelten Software-Update-Architektur gemäß AUTOSAR AP Release R23-11 / R24-11 mit Trennung von fahrzeugweitem Kampagnenmanagement (VUCM) und maschinenlokalem Updatemanagement (UCM).
• Funktionale Einordnung: Heterogene Deployment-Architektur mit dedizierten Daemon-Instanzen auf POSIX-Ebene für Ingress/Gateway-Knoten (gateway: Machine), sekundäre HPC-Knoten (machine1: Machine) und Classic-Platform-ECUs (ecu1: ECU).

2. Komponenten, Entitäten & Schnittstellen

• Externe Entitäten (Off-Board):
  • :Backend System: OTA-Server / Flottenmanagement zur Übertragung von Vehicle Packages.
  • :Diagnostic Client: Werkstattiagnose-Tester via DoIP/UDS.
• Fahrzeugknoten & Ausführungsumgebungen (On-Board):
  • «device» Vehicle: Gesamtfahrzeugnetzwerk.
  • «device» gateway: Machine:
    • Beherbergt «executionEnvironment» :Adaptive Runtime.
    • «executable» OTA Client Application: Nimmt Backend-Updates entgegen.
    • «executable» Vehicle Update and Configuration Management: Eigenständiges Executable für die fahrzeugweite Update-Koordination.
    • «executable» Update and Configuration Management: Lokales UCM-Executable für die Gateway-Maschine.
  • «device» machine1: Machine:
    • Beherbergt «executionEnvironment» :Adaptive Runtime.
    • «executable» Update and Configuration Management: Lokales UCM-Executable für machine1.
  • «device» ecu1: ECU:
    • «executionEnvironment» :Classic Platform (CP BSW, RTE, DCM/Bootloader).
• AUTOSAR Functional Clusters & Komponenten (Off-Node/Modell-Ebene):
  • OTA Client: Software-Komponente für OTA-Funktionalität.
  • «aapFunctionalCluster» Vehicle Update and Configuration Management (Eigenschaft: daemon-based): Funktionaler Cluster für fahrzeugweites Paketmanagement (ehemals UCM Master).
  • «aapFunctionalCluster» Update and Configuration Management (Eigenschaft: daemon-based): Funktionaler Cluster für maschinenlokales Software-Paket-Management (ehemals UCM Subordinate).
• Manifest-Abhängigkeiten («manifest»):
  • OTA Client Application → OTA Client.
  • Gateway Vehicle Update and Configuration Management → Functional Cluster Vehicle Update and Configuration Management.
  • Gateway Update and Configuration Management → Functional Cluster Update and Configuration Management.
  • machine1 Update and Configuration Management → Functional Cluster Update and Configuration Management.
• Schnittstellen & Busse: Unveränderte physikalische und logische Topologie (Funk/OBD extern, Ethernet/SOME/IP inter-Machine, Bus/UDS zur Classic ECU).

3. Dynamisches Verhalten & Sequenzablauf

• Ingestion & Entgegennahme: :Backend System liefert das Fahrzeugpaket an die OTA Client Application (oder :Diagnostic Client injiziert Pakete via DoIP).
• Fahrzeugweite Koordination (VUCM): Die OTA Client Application übergibt das Gesamtpaket an das dedizierte Executable Vehicle Update and Configuration Management (VUCM-Daemon). VUCM validiert das Vehicle Package, prüft fahrzeugweite Abhängigkeiten und extrahiert die zielspezifischen Software Packages.
• Verteilung an lokale UCMs:
  • VUCM sendet das lokale Software-Paket für das Gateway an das maschinenlokale Executable Update and Configuration Management auf demselben Knoten (Inter-Process-Communication).
  • VUCM überträgt über Ethernet (ara::com / SOME/IP) Teilpakete an das Executable Update and Configuration Management auf machine1.
  • VUCM steuert das Update von ecu1 über klassische Diagnosedienste (UDS via DCM/Flash Bootloader).
• Verarbeitung & Aktivierung: Die lokalen UCM-Daemons auf Gateway und machine1 verarbeiten, verifizieren und aktivieren die Software-Pakete gemäß VUCM-Ablaufplan inklusive koordinierter Rollback-Fähigkeit.

4. Normative Relevanz & Entwickler-Hinweise

• AUTOSAR-Spezifikationsbezug: AUTOSAR AP Release R23-11 / R24-11 (SWS Vehicle Update and Configuration Management, SWS Update and Configuration Management, EXP Software Architecture).
• Architektur-Refaktorisierung (VUCM vs. UCM): Die funktionale Trennung zwischen Fahrzeug-Koordination und lokaler Knoten-Aktualisierung ist nun normativ als zwei getrennte «aapFunctionalCluster» standardisiert. VUCM ersetzt das frühere Konzept des "UCM Master", während UCM nun rein maschinenlokal agiert.
• Prozesstrennung auf dem Gateway: Auf dem Gateway-Knoten laufen nun zwei separate Daemons (Vehicle Update and Configuration Management und Update and Configuration Management). Beide Executables müssen separat im Execution Manifest instanziiert und konfiguriert werden.
• Daemon-Based Design: Beide Cluster sind explizit als daemon-based gekennzeichnet, d. h. sie laufen als persistente Hintergrunddienste unter POSIX und stellen serviceorientierte Schnittstellen bereit.