Figure 10.19: Use case for providing update related information

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Use-Case-Diagramm mit Komponentenkontext auf Architekturebene (AUTOSAR Adaptive Platform Architecture Modeling / AAP-Stereotypen).
• Architektur-Kontext: Spezifiziert die Bereitstellung von Software-Paket- und Update-Informationen im Subsystem Update and Configuration Management (UCM) der AUTOSAR Adaptive Platform (R24-11). Dargestellt ist das Zusammenspiel zwischen dem fahrzeugweiten Orchestrator (VUCM), dem lokalen Update-Management (UCM) und den kryptografischen Sicherheitsdiensten zur Absicherung von Update-Kampagnen.

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenze Adaptive Platform: Definiert die Runtime-Ebene der AUTOSAR Adaptive Platform Instanz.
• Subsystem-Boundary Update and Configuration Management: Kapselt die lokalen Update-Funktionalitäten und beherbergt den Anwendungsfall.
• Entitäten & Komponenten:
  • «aapFunctionalCluster» Vehicle Update and Configuration Management (VUCM):
    • Ausprägung: daemon-based (autonomer POSIX-Dienstprozess).
    • Rolle: Systemweiter Initiator/Client; koordiniert fahrzeugweite Updates über mehrere ECUs und interagiert mit Backend/OTA-Systemen.
  • «aapUseCase» Provide SW Package Update Information:
    • Rolle: Kapselt die Logik zur Ermittlung, Strukturierung und Auslieferung von Paket-Metadaten (z. B. Versionen, Abhängigkeiten, Zustand der Software-Cluster).
  • «aapFunctionalCluster» Cryptography:
    • Ausprägung: daemon-based (autonomer POSIX-Dienstprozess / Crypto-Stack).
    • Rolle: Sicherheitsdienstleister für Integritäts- und Authentizitätsprüfungen.
• Beziehungen & Stereotypen:
  • VUCM ──«aapTriggers»──> Use Case: Unidirektionale Trigger-Beziehung; VUCM stößt den Anwendungsfall aktiv an.
  • Use Case ──«aapParticipates»──> Cryptography: Mitwirkungs-Beziehung; der Use Case nutzt kryptografische Primitive zur Verifikation der Paketinformationen.

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering: VUCM fragt über standardisierte UCM-Services Informationen zu verfügbaren oder installierten Software Packages an (z. B. zur Validierung von Abhängigkeiten vor Beginn einer Update-Kampagne).
2. Paketprüfung & Metadaten-Extraktion: UCM liest das Software Package Manifest bzw. die Header-Informationen des Zielpakets.
3. Kryptografische Verifikation («aapParticipates»):
   • UCM bindet ara::crypto ein.
   • Durchführung der Authentizitäts- und Integritätsprüfung des Manifests (Signaturvalidierung über hinterlegte X.509-Zertifikate bzw. Trust-Anchors, Hash-Abgleich der Metadatenblöcke).
4. Ergebnisbereitstellung: Nach erfolgreicher Krypto-Validierung liefert UCM die verifizierten Paketinformationen (Versionen, Dependencies, Konflikte) synchron oder über ara::core::Future/Polymorphic Callbacks an VUCM zurück. Schlägt die Signaturprüfung fehl, wird der Vorgang mit einem spezifischen Fehlercode (z. B. UcmErrorDomain::kAuthenticationFailed) abgebrochen.

4. Normative Relevanz & Entwickler-Hinweise

• API-Verträge & Service-Interfaces:
  • UCM-Implementierer müssen die Service-Schnittstelle ara::ucm::pkgmgr::PackageManager implementieren; VUCM konsumiert Methoden wie GetSwPackageInfo oder äquivalente Interface-Operationen.
  • Die Interaktion mit Cryptography erfolgt über standardisierte ara::crypto::keys und ara::crypto::cryp Interfaces (u. a. VerifierOpenObject, VerifySignature).
• Prozessmodell & Deployment (daemon-based):
  • Sowohl VUCM, UCM als auch Cryptography müssen im Execution Management (EM) als unabhängige Daemons (Process-Instanzen) mit entsprechenden POSIX-Privilegien und IPC-Endpunkten (D-Bus, Shared Memory oder ara::com) deployt sein.
  • Startabhängigkeiten (StartupConfig): Cryptography muss vor UCM und VUCM betriebsbereit sein (Running-State), um Deadlocks bei frühen Statusabfragen zu verhindern.
• Performance & Constraints:
  • Kryptografische Signaturprüfungen sind rechenintensiv. Die Informationsbereitstellung muss nicht-blockierend/asynchron implementiert werden, um ein Einfrieren des VUCM-Orchestrators zu verhindern.
  • Metadaten und Manifeste dürfen vor erfolgreicher Signaturvalidierung nicht ungeprüft verarbeitet werden (Zero-Trust-Prinzip gegenüber extern eingespeisten Update-Paketen).