Figure 10.23: Provide Vehicle Update Information

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Use-Case-Diagramm (Anwendungsfalldiagramm) mit AUTOSAR-spezifischer Stereotypisierung («aapUseCase», «aapFunctionalCluster», «aapTriggers», «aapParticipates»).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R24-11), Subsystem Vehicle Update and Configuration Management (VUCM).
• Technischer Zweck: Spezifikation der Systemgrenzen, externen Akteure und internen Platform-Cluster für den Anwendungsfall „Provide Vehicle Update Information“. Dieser Use Case dient der Bereitstellung von Zustands-, Versions- und Kampagneninformationen über anstehende, laufende oder abgeschlossene Software-Updates im gesamten Fahrzeugverbund (Fahrzeugstatus, Kampagnenfortschritt, Pre-Conditions, Software-Cluster-Versionen).

2. Komponenten, Entitäten & Schnittstellen

Akteure ((from Actors))

• OTA Client (Trigger-Akteur): Backend-Anbindung (Telematik/Cloud), die Kampagnenstatus, Over-the-Air-Manifeste und Rollout-Feedback abfragt bzw. anstößt.
• Diagnostic Application (Trigger-Akteur): Werkstättentester oder On-Board-Diagnose-Applikation (z. B. via DoIP/UDS-Dienste wie ReadDataByIdentifier für Update-/Versionsstatus).
• Vehicle Driver Interface (Trigger-Akteur): HMI-/Kombiinstrument-/Infotainment-Schnittstelle, die dem Fahrer Update-Bereitschaft, Sicherheitsabfragen (User Consent), geschätzte Dauer und Installationsstatus visualisiert.
• Flashing Adapter (Teilnehmender Akteur): Protokoll- und busabhängiger Adapter (z. B. CAN, LIN, FlexRay, Ethernet), der fahrzeugweit heterogene Steuergeräte (insb. Classic-AUTOSAR- und Non-AUTOSAR-Nodes) anbindet und deren spezifischen Firmware-/Update-Status meldet.

Systemgrenzen & Funktionscluster

• Systemgrenze Adaptive Platform: Beherbergt die Plattform-Dienste und das Subsystem Vehicle Update and Configuration Management.
• Subsystem Vehicle Update and Configuration Management: Kapselt die fahrzeugweite Orchestrierungslogik für Updates.
• Use Case «aapUseCase» Provide Vehicle Update Information: Zentraler Interaktionsknoten für Informationsabfragen und Statusaggregation.
• «aapFunctionalCluster» Update and Configuration Management (daemon-based): Kernplattform-Dienst (UCM/VUCM-Daemon) zur Verwaltung von Manifesten, Software-Clustern, Abhängigkeiten, Historie und Rollback-Zuständen.
• «aapFunctionalCluster» Cryptography (daemon-based): Plattform-Dienst (ara::crypto-Daemon) zur Verifikation von Signaturen, Authentizitätsprüfungen der Update-Metadaten und Integritätsvalidierung von Versionsauskünften.

Assoziationen & Stereotypen

• «aapTriggers»: Gerichtete Trigger-Beziehungen von OTA Client, Diagnostic Application und Vehicle Driver Interface auf den Use Case.
• «aapParticipates»:
  • Bidirektionale Interaktionsbeziehung zwischen Flashing Adapter und dem Use Case (Einholung von Statusdaten nachgelagerter ECUs).
  • Assoziationen des Use Cases zu den ausführenden Plattform-Daemonen: Update and Configuration Management (Datenhaltung, Orchestrierung) und Cryptography (Kryptografische Absicherung).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering Phase: Ein autorisierter Client (OTA Client, Diagnostic Application oder Vehicle Driver Interface) fordert über standardisierte ARA-Dienstschnittstellen (ara::com bzw. diagnostische Adapter) den Fahrzeug-Update-Status an.
2. Kryptografische Verifikation: Das UCM-Subsystem bindet Cryptography ein, um sicherzustellen, dass die vorliegenden Kampagnen-Metadaten und Versionsstände signiert und unverfälscht sind.
3. Status-Aggregation (Plattform & Subsysteme):
   • Lokale Software-Cluster-Zustände werden direkt aus der internen UCM-Zustandsdatenbank abgefragt.
   • Remote- bzw. Sub-ECU-Zustände werden über den Flashing Adapter synchronisiert/abgefragt.
4. Validierung von Vorbedingungen (Pre-Conditions): Bereitstellung von Sicherheitszuständen (z. B. Fahrzeug im Stillstand, Batterieladestand ausreichend, Zündung aus).
5. Rückmeldung: Aggregierte Zustandsinformationen (z. B. Status READY, UPDATING, SUCCESS, Fehlercodes, Versionsdifferenzen) werden an den anfragenden Trigger-Akteur zurückgemeldet.

4. Normative Relevanz & Entwickler-Hinweise

• API-Schnittstellen:
  • UCM Service Interfaces: Applikationsentwickler binden UCM über standardisierte C++-Schnittstellen (ara::ucm bzw. ara::vucm) an. Informationsabfragen erfolgen typischerweise über Methoden wie GetHistory(), GetSwClusterDescription(), GetSwProcessDescription() oder spezifische VUCM-Kampagnen-APIs.
  • HMI / Driver Interface: Muss asynchrone Statusaktualisierungen (Events/Fields über ara::com) verarbeiten können, da Zustandsänderungen während des Updates nicht-blockierend signalisiert werden.
• Rollen- & Rechteverwaltung (IAM): Zugriffe durch OTA Client, Diagnostic Application und Vehicle Driver Interface unterliegen dem Adaptive Identity and Access Management (ara::iam). Jeder Akteur benötigt explizit deklarierte Zugriffsrechte auf die UCM-Informationsmethoden im Execution/Service-Manifest.
• Flashing-Adapter-Implementierung:
  • Entwickler von Flashing Adaptern müssen einheitliche Zustandsmodelle für proprietäre oder Classic-ECUs bereitstellen, damit das VUCM fahrzeugweit homogene Statusmeldungen generieren kann.
  • Timeouts und unvollständige Rückmeldungen einzelner Busknoten müssen im Adapter abgefangen und als Fehlerzustand gemeldet werden.
• Daemon-Abhängigkeiten: Da UCM und Cryptography als daemon-based Functional Clusters definiert sind, müssen die entsprechenden Prozesse (ara::ucm, ara::crypto) im Startup Manifest via Execution Management (ara::exec) in den erforderlichen Machine States vor dem Start der Client-Anwendungen instanziiert und betriebsbereit sein.