Figure 5.2: Interfaces required by Vehicle Update and Configuration Management from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Architektur-Strukturdiagramm (Komponentendiagramm-Abstraktion der AUTOSAR Adaptive Platform Architecture).
• Technischer Zweck: Spezifikation der normativen Abhängigkeiten und konsumierten C++-Programmierschnittstellen (Native Interfaces / Functional Cluster APIs), die das Functional Cluster Vehicle Update and Configuration Management (UCM) zur Laufzeit von anderen Plattform-Clustern der AUTOSAR Adaptive Platform (AP) einfordert.
• Funktionale Einordnung: UCM steuert als Plattform-Dienst Software-Aktualisierungen, Rollbacks und Zustandsabfragen für Adaptive Applications. Zur Ausführung dieser Aufgaben benötigt UCM fundamentale Plattform-Dienste: Lebenszyklusmeldung an das Prozessmanagement, kryptografische Verifikation der Update-Pakete sowie standardisiertes Logging.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Functional Clusters

• Vehicle Update and Configuration Management («aapFunctionalCluster», daemon-based):
  • Konsument (Client). Läuft als eigenständiger POSIX-Daemon-Prozess im Betriebssystem.
• Log and Trace («aapFunctionalCluster»):
  • Provider für strukturiertes, gefiltertes Plattform-Logging (ara::log).
• Execution Management («aapFunctionalCluster», daemon-based):
  • Provider für Prozessüberwachung, State Management und Startup/Shutdown-Zyklen (ara::exec).
• Cryptography («aapFunctionalCluster», daemon-based):
  • Provider für kryptografische Primitive, Schlüsselverwaltung, Signaturen und Zertifikatsprüfung (ara::crypto).

Schnittstellen («aapAPI,aapNativeInterface»)

• Logger (realisiert durch Log and Trace):
  • + IsEnabled(): bool – Abfrage aktiver Log-Filter.
  • + Log(MsgId, Params) – Strukturierter Log-Aufruf.
  • + LogDebug(): LogStream, + LogError(): LogStream, + LogFatal(): LogStream, + LogInfo(): LogStream, + LogVerbose(): LogStream, + LogWarn(): LogStream – Severity-spezifische Streaming-Operatoren.
  • + WithLevel(): LogStream – Dynamische Severity-Zuweisung.
• ExecutionClient (realisiert durch Execution Management):
  • + Create() – Factory-Methode / Konstruktor zur Instanziierung des Client-Objekts.
  • + ReportExecutionState(ExecutionState) – Synchrone/asynchrone Zustandsübermittlung (z. B. kRunning, kTerminating) an den EM-Daemon.
• CryptoStack (realisiert durch Cryptography):
  • Schnittstellenabstraktion für ara::crypto (Hashing, Signaturprüfung, Schlüsselzugriff).

Beziehungen

• Interface Realization (gestrichelte Linie mit geschlossener, weißer Dreiecksspitze):
  • Log and Trace → Logger
  • Execution Management → ExecutionClient
  • Cryptography → CryptoStack
• Dependency («use», gestrichelte Pfeillinie):
  • Vehicle Update and Configuration Management → Logger
  • Vehicle Update and Configuration Management → ExecutionClient
  • Vehicle Update and Configuration Management → CryptoStack

3. Dynamisches Verhalten & Interaktionsmuster

Da es sich um ein statisches Abhängigkeitsmodell handelt, spiegeln die Schnittstellen die folgenden synchronen und prozessübergreifenden Abläufe im UCM-Lebenszyklus wider:

1. Bootstrap & Alive-Reporting:
   • Nach dem Start des UCM-Prozesses durch den POSIX-Kernel/EM instanziiert UCM via ExecutionClient::Create() die Client-Instanz.
   • UCM meldet den Betriebszustand via ReportExecutionState(ExecutionState::kRunning) per IPC an den Execution Management Daemon. Bei Ausbleiben greift das EM-Deadline-Monitoring.
2. Paketverifikation (Update-Phase):
   • UCM empfängt ein Software Package.
   • UCM ruft synchrone/asynchrone Methoden des CryptoStack auf, um Manifest-Signaturen gegen hinterlegte Root-Zertifikate (Authentizität) und SHA-Hashes der Payload-Container (Integrität) zu validieren.
3. Traceability & Audit-Pfad:
   • Bei jedem Statustransfer (Transferring, Updating, Verifying, Activating, RollingBack) generiert UCM Diagnose- und Audit-Einträge über Logger::LogInfo(), Logger::LogWarn() oder Logger::LogError(), welche durch Log and Trace an POSIX-Standardkanäle oder DLT (Diagnostic Log and Trace) weitergeleitet werden.
4. Terminierung:
   • Vor dem Neustart nach Aktivierung eines Updates signalisiert UCM via ReportExecutionState(ExecutionState::kTerminating) das geordnete Herunterfahren an EM.

4. Normative Relevanz & Entwickler-Hinweise

• Link- und Build-Konfiguration:
  • Die UCM-Binary muss gegen die nativen C++-Client-Bibliotheken linken (libara_exec.so, libara_log.so, libara_crypto.so bzw. herstellerspezifische Implementierungen).
• IPC- und Daemon-Architektur:
  • ExecutionClient und CryptoStack operieren als Thin-Clients; die eigentliche Ausführung und Schlüsselverwaltung geschieht im Sicherheitskontext der jeweiligen Daemons via IPC (Domain Sockets / Shared Memory). Fehlerzustände der IPC müssen über ara::core::Result<T> im UCM abgefangen werden.
• Manifest- & Berechtigungskonfiguration:
  • Im Execution Manifest (.arxml) des UCM müssen Zugriffsrechte für den ExecutionClient konfiguriert sein (Berechtigung zum Melden von Execution States).
  • Im Cryptographic Key Management Manifest muss UCM den Truststore-/Key-Slot-Zugriff zugewiesen bekommen, um die Hersteller-/OEM-Schlüssel für die Signaturprüfung ansprechen zu können.
• Einschränkung:
  • UCM darf Validierungsoperationen nicht anwendungsseitig selbst nachimplementieren, sondern ist normativ an die Schnittstellen des CryptoStack gebunden, um Hardware-Sicherheitsmodule (HSM) oder Trust-Zonen transparent einbinden zu können.