Figure 5.2: Interfaces required by Update and Configuration Management from Functional Clusters Persistency and Time Synchronization

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Schnittstellen- und Komponentendiagramm (AUTOSAR Adaptive Platform Metamodell, Cluster Interaction View).
• Architektur-Kontext: Spezifiziert die Abhängigkeiten des Funktionsclusters Update and Configuration Management (UCM) zu den Basis-Clustern Persistency (PER) und Time Synchronization (TS) in der AUTOSAR Adaptive Platform (Release R25-11).
• Funktionaler Zweck: UCM fungiert als zentrale Instanz für Software-Aktualisierungen (Fahrzeug-/ECU-Updates, Rollback, Aktivierung). Für die transaktions- und stromausfallsichere Zustandsverwaltung benötigt UCM Persistenzmechanismen; für kryptografische Zertifikatsprüfungen, Logging und Transaktionszeitstempel benötigt UCM eine abgesicherte, netzwerkweit synchronisierte Zeitbasis.

2. Komponenten, Entitäten & Schnittstellen

Funktionscluster («aapFunctionalCluster»)

• Update and Configuration Management: Konsumierender Cluster, als Hintergrunddienst (daemon-based) ausgeführt.
• Time Synchronization: Bereitstellender Cluster, als Hintergrunddienst (daemon-based) implementiert; liefert konsistente Zeitbasen.
• Persistency: Bereitstellender Cluster (typischerweise statisch/dynamisch gelinkte Library innerhalb des UCM-Prozesskontexts); kapselt Datei- und Schlüssel-Wert-Speicherung.

Schnittstellen («aapAPI, aapPortInterface») & Methoden

• SynchronizedTimeBaseConsumer (bereitgestellt von Time Synchronization):
  • Zeit- und Statusabfrage: GetRateDeviation(), GetTimeWithStatus(): SynchronizedTimeBaseStatus.
  • Notifier-Lifecycle: RegisterStatusChangeNotifier(), UnregisterStatusChangeNotifier(), RegisterSynchronizationStateChangeNotifier(), UnregisterSynchronizationStateChangeNotifier(), RegisterTimeLeapNotifier(), UnregisterTimeLeapNotifier(), RegisterTimePrecisionMeasurementNotifier(), UnregisterTimePrecisionMeasurementNotifier(), RegisterTimeValidationNotification(), UnregisterTimeValidationNotification().
• FileStorage (bereitgestellt von Persistency):
  • Datei-Management: DeleteFile(), FileExists(), GetAllFileNames(), GetCurrentFileSize(), GetFileInfo(), RecoverFile(), ResetFile().
  • Stream-/Handle-Zugriff: OpenFileReadOnly(): ReadAccessor, OpenFileReadWrite(): ReadWriteAccessor, OpenFileWriteOnly(): WriteAccessor.
• KeyValueStorage (bereitgestellt von Persistency):
  • Daten-CRUD: GetValue(), SetValue(), KeyExists(), RemoveKey(), RemoveAllKeys(), GetAllKeys(), GetCurrentValueSize().
  • Transaktions- & NVM-Kontrolle: SyncToStorage(), DiscardPendingChanges(), RecoverKey(), ResetKey().

Beziehungen & Stereotypen

• «use» «aapRequiredPort»: Gerichtete Abhängigkeiten von UCM zu den drei Schnittstellen. UCM deklariert R-Ports für SynchronizedTimeBaseConsumer, FileStorage und KeyValueStorage.
• Schnittstellenrealisierung (Interface Realization): Gestrichelte Pfeile mit geschlossener Dreiecksspitze von den implementierenden Clustern (Time Synchronization bzw. Persistency) zu den jeweiligen Port Interfaces.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungs- & Wiederanlaufphase (Power-On / Reset):
   • UCM fragt via KeyValueStorage::GetValue() die letzte persistierte Zustandsmaschine ab (z. B. laufende Installation, verifizierter Status, SwCluster-Versionen).
   • UCM meldet über SynchronizedTimeBaseConsumer::RegisterSynchronizationStateChangeNotifier() Callbacks an, um Ereignisse bei Verlust oder Wiederherstellung der Zeitsynchronisation zu empfangen.
2. Pakettransfer & Validierung (Transfer / Process):
   • Eintreffende Software-Pakete/Images werden über FileStorage::OpenFileWriteOnly() und den resultierenden WriteAccessor sequenziell auf das Zielmedium geschrieben.
   • UCM ruft SynchronizedTimeBaseConsumer::GetTimeWithStatus() auf. Vor der Verarbeitung prüft UCM, ob der Zeitstempel valide ist (SynchronizedTimeBaseStatus), um die Gültigkeitsdauer (NotBefore / NotAfter) von X.509-Zertifikaten sowie Signaturen gegen Replay-Angriffe abzusichern.
3. Zustandssicherung & Commit:
   • Zwischenzustände (kTransferring, kTransferred, kProcessing) werden atomar via KeyValueStorage::SetValue() aktualisiert und mit SyncToStorage() synchron auf den NVM-Speicher geflusht.
4. Fehlerfall & Rollback:
   • Bei Abbruch oder fehlschlagender Verifikation setzt UCM Teildateien über FileStorage::DeleteFile() oder ResetFile() zurück bzw. ruft KeyValueStorage::DiscardPendingChanges() oder ResetKey() auf, um einen konsistenten Vorzustand wiederherzustellen.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration:
  • Für UCM müssen im Execution- und Service-Instance-Manifest RPortPrototype-Instanzen für die drei Schnittstellen konfiguriert werden.
  • Das Persistency-Manifest muss entsprechende Port-Mappings für FileStorage (Mountpoints, Quotas, Storage-Pfade) und KeyValueStorage definieren.
  • Das Time-Synchronization-Manifest muss UCM an die geforderte SynchronizedTimeBase (z. B. IEEE 802.1AS / PTP oder CAN-TS) binden.
• Transaktionsintegrität & Blockierverhalten:
  • KeyValueStorage::SyncToStorage() erzwingt einen Flush auf physischen Flash/eMMC. Wegen hoher I/O-Latenzen darf dieser Aufruf nicht in harten Echtzeit- oder reaktiven Dispatch-Threads blockieren, sondern muss im UCM-Worker-Thread isoliert werden.
  • Uncommitted Key-Value-Änderungen überleben einen harten Spannungsabfall nicht, solange SyncToStorage() nicht erfolgreich quittiert wurde.
• Robustheit gegenüber Time-Base-Verlust:
  • Entwickler müssen zwingend den Rückgabewert von SynchronizedTimeBaseConsumer::GetTimeWithStatus() auf den Status TIMEOUT, SYNC oder UNSYNC auswerten. Liegt keine synchronisierte Zeit vor, muss UCM zeitkritische Update-Phasen blockieren oder in eine definierte Fehlerbehandlung übergehen.
• Redundanz- & Recovery-Mechanismen:
  • Die Methoden RecoverFile() und RecoverKey() greifen auf konfigurierte Redundanzmechanismen (z. B. M-out-of-N-Storage, CRC) von ara::per zurück. Diese müssen im Manifest explizit aktiviert sein, damit die Methoden im Fehlerfall greifen.