Figure 9.76: Interfaces required by Update and Configuration Management (part 1)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Port-Interface-Architekturdiagramm der AUTOSAR Adaptive Platform (Standard: R22-11, AUTOSAR_EXP_SWArchitecture).
• Technischer Zweck: Spezifikation der funktionalen Abhängigkeiten des Functional Clusters (FC) Update and Configuration Management (UCM) zu den Basis-Diensten der Adaptive Platform (Persistency und Time Synchronization) über standardisierte ARA-Schnittstellen (AUTOSAR Runtime for Adaptive Applications).
• Funktionale Einordnung: UCM steuert als zentraler Daemon OTA-Updates, Software-Installationen, Rollbacks und Validierungsschritte. Für die transaktionssichere Zustandsverwaltung und verlässliche Zeitstempelung greift UCM über Client-Ports (RequiredPort) auf die standardisierten APIs benachbarter FCs zu.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Functional Clusters

• «aapFunctionalCluster» Update and Configuration Management (daemon-based):
  • Konsument der Dienste; implementiert als Hintergrundprozess (Daemon) im OS-Kontext.
• «aapFunctionalCluster» Persistency:
  • Bereitsteller persistenter Speicherabstraktionen für relationale Daten, Konfigurationen und Binärdateien.
• «aapFunctionalCluster» Time Synchronization (daemon-based):
  • Bereitsteller einer netzwerkweit synchronisierten Zeitbasis (z. B. via IEEE 802.1AS / gPTP).

Schnittstellen («aapAPI, aapPortInterface»)

1. SynchronizedTimeBaseConsumer:
   • Schnittstelle zur synchronisierten Zeitbasis.
   • Lese-Operationen: GetCurrentTime(), GetRateDeviation(), GetTimeWithStatus(): SynchronizedTimeBaseStatus.
   • Asynchrone Notifier-Registrierung: RegisterStatusChangeNotifier(), RegisterSynchronizationStateChangeNotifier(), RegisterTimeLeapNotifier(), RegisterTimePrecisionMeasurementNotifier(), RegisterTimeValidationNotification() (jeweils mit komplementärem Unregister...).
2. FileStorage:
   • Block-/Datei-basierte Persistenzschnittstelle (ara::per).
   • Dateioperationen: DeleteFile(), FileExists(), GetAllFileNames(), GetCurrentFileSize(), GetFileInfo(), RecoverFile(), ResetFile().
   • Zugriffs-Handler: OpenFileReadOnly(): ReadAccessor, OpenFileReadWrite(): ReadWriteAccessor, OpenFileWriteOnly(): ReadWriteAccessor.
3. KeyValueStorage:
   • Schlüssel-Wert-basierte Persistenzschnittstelle (ara::per).
   • Schlüssel-Operationen: DiscardPendingChanges(), GetAllKeys(), GetValue(), KeyExists(), RecoverKey(), RemoveAllKeys(), RemoveKey(), ResetKey(), SetValue(), SyncToStorage().

Beziehungen & Stereotypen

• Port-Kopplung: UCM bindet alle drei Schnittstellen über «use» «aapRequiredPort» (Client-Rolle) ein.
• Realisierung:
  • Persistency implementiert FileStorage und KeyValueStorage via Interface-Realisierung (gestrichelte Vererbungslinie).
  • Time Synchronization implementiert SynchronizedTimeBaseConsumer via Interface-Realisierung.

3. Dynamisches Verhalten & Sequenzablauf

• Persistente Datenhaltung (UCM ↔ Persistency):
  • Metadaten & Transaktionszustände (KeyValueStorage): Atomare Sicherung des Update-Fortschritts (Package-States: kTransferring, kTransferred, kInstalled). Änderungen werden via SetValue() vorbereitet und mittels SyncToStorage() physisch im Non-Volatile Storage festgeschrieben. Im Fehlerfall ermöglichen RecoverKey() oder DiscardPendingChanges() das Rollback unvollständiger Transaktionen.
  • Software-Artefakte & Manifeste (FileStorage): Streaming empfangener Payload-Archive über OpenFileWriteOnly() / ReadWriteAccessor. Prüfung existierender Binaries via FileExists() / GetFileInfo().
• Zeitüberwachung & Gültigkeit (UCM ↔ Time Synchronization):
  • Zertifikats- & Kampagnenvalidierung: Abruf von Systemzeit und Synchronisationsstatus via GetTimeWithStatus(), um kryptografische Zeitfenster (NotBefore/NotAfter von Update-Zertifikaten) abzusichern.
  • Ereignisgesteuertes Verhalten: UCM registriert Callbacks (Notifier) für Zeitsprünge (RegisterTimeLeapNotifier) und Synchronisationsverlust (RegisterSynchronizationStateChangeNotifier). Tritt während eines Flashing- oder Aktivierungsschritts ein Zeitabriss ein, kann UCM deterministisch in einen sicheren Fehlerzustand wechseln.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Modellierung (AUTOSAR ARXML):
  • Für UCM müssen im Application Execution Manifest bzw. Service Instance Manifest entsprechende RPortPrototypes definiert werden, die auf die jeweiligen PortInterfaces verweisen (ara::per::FileStorage, ara::per::KeyValueStorage, ara::tsync::SynchronizedTimeBaseConsumer).
• Startup-Dependencies im Execution Management (EM):
  • Da UCM als Daemon läuft und zwingend auf TimeSync und Persistency angewiesen ist, müssen im EM Startup Dependencies bzw. Execution Dependencies hinterlegt werden. UCM darf erst in den Zustand Running überführt werden, wenn Persistency und Time Synchronization betriebsbereit gemeldet sind.
• Fail-Safe- & Crash-Recovery-Anforderungen:
  • Bei Spannungsverlust (Power-Cut) während des Schreibens von SwPackages muss RecoverFile() bzw. RecoverKey() von der zugrundeliegenden Persistency-Implementierung vollumfänglich unterstützt werden (z. B. durch redundante Sektoren, Journaling oder A/B-Speicherbänke).
  • Entwickler dürfen Zeitstempel für Sicherheitsentscheidungen nicht isoliert auswerten; der Rückgabewert SynchronizedTimeBaseStatus muss zwingend auf Flags wie kSynchronized oder kTimeout geprüft werden.