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

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Schnittstellen- und Architekturdiagramm (Mischform aus Komponenten- und Klassendiagramm) der AUTOSAR Adaptive Platform (AP, R23-11).
• Technischer Zweck: Spezifikation der normativen Abhängigkeiten des Functional Clusters Update and Configuration Management (UCM) zu Nachbar-Clustern der Plattform-Schicht (ara-Laufzeitumgebung).
• Funktionale Einordnung: UCM kapselt OTA- und lokale Update-Zyklen (Transfer, Installation, Verifikation, Aktivierung, Rollback). Um zustandslos bzw. idempotent nach Neustarts agieren zu können und zeitliche Validitätsprüfungen durchzuführen, nutzt UCM die standardisierten Schnittstellen der Cluster Persistency (PER) und Time Synchronization (TSync).

2. Komponenten, Entitäten & Schnittstellen

Functional Cluster (Akteure / Bereitsteller)

• Update and Configuration Management
  • Stereotyp: «aapFunctionalCluster», Tagged Value: daemon-based
  • Rolle: Consumer / Client. Läuft als eigenständiger POSIX-Daemon-Prozess auf der Adaptive Machine.
• Persistency
  • Stereotyp: «aapFunctionalCluster»
  • Rolle: Provider; realisiert Dateisystem- und Key-Value-Persistierung (in der Regel als Bibliotheksmodul ara::per implementiert).
• Time Synchronization
  • Stereotyp: «aapFunctionalCluster», Tagged Value: daemon-based
  • Rolle: Provider; stellt über ara::tsync synchronisierte Netzwerkzeitbasen (z. B. IEEE 802.1AS / PTP, CAN-TSyn) bereit.

Schnittstellen & Ports («aapAPI, aapPortInterface»)

1. FileStorage (bereitgestellt durch Persistency):
   • Methoden: DeleteFile(), FileExists(), GetAllFileNames(), GetCurrentFileSize(), GetFileInfo(), OpenFileReadOnly(): ReadAccessor, OpenFileReadWrite(): ReadWriteAccessor, OpenFileWriteOnly(): ReadWriteAccessor, RecoverFile(), ResetFile().
   • Zweck: Verwaltung großer binärer Nutzdaten (Software-Pakete, Target-Images, Differenz-Patches).
2. KeyValueStorage (bereitgestellt durch Persistency):
   • Methoden: DiscardPendingChanges(), GetAllKeys(), GetValue(), KeyExists(), RecoverKey(), RemoveAllKeys(), RemoveKey(), ResetKey(), SetValue(), SyncToStorage().
   • Zweck: Atomare Sicherung von Zustandsmaschinen (UCM State Machine), Paket-Metadaten, Partitionsbelegungen, Versionshistorie und Rollback-Punkten.
3. SynchronizedTimeBaseConsumer (bereitgestellt durch Time Synchronization):
   • Methoden: GetCurrentTime(), GetRateDeviation(), GetTimeWithStatus(): SynchronizedTimeBaseStatus.
   • Events/Notifier: Registrierung/Deregistrierung von Callbacks via Register* / Unregister* für StatusChange, SynchronizationStateChange, TimeLeap, TimePrecisionMeasurement, TimeValidationNotification.
   • Zweck: Audit-Logging, Zertifikats-/Gültigkeitsüberprüfung (Security) und konsistente Zeitstempel für Update-Kampagnen.

Beziehungen & Stereotypen

• UCM → Schnittstellen: Abhängigkeit über gerichtete Assoziationen «use» unter Verwendung von «aapRequiredPort». UCM instanziiert Required Ports zur Bindung an die jeweiligen C++-APIs.
• Cluster → Schnittstellen: Realisierungsbeziehungen (gestrichelte Linien mit geschlossener, nicht ausgefüllter Pfeilspitze). Die Functional Cluster implementieren die kontraktierten Schnittstellen.

3. Dynamisches Verhalten & Sequenzablauf

UCM nutzt diese Schnittstellen phasenspezifisch während des Software-Update-Lebenszyklus:

1. Paket-Transfer & Vorbereitung (FileStorage):
   • Eingehende Software-Pakete werden per OpenFileWriteOnly() gestreamt und abgelegt.
   • GetCurrentFileSize() und GetFileInfo() dienen der Vorabprüfung auf Speicherengpässe (Storage Allocation/Quotas) vor der Extraktion.
2. Transaktions- & Zustandskontrolle (KeyValueStorage):
   • Nach Zustandswechseln (z. B. von TRANSFERRING zu EXTRACTING oder PROCESSING) speichert UCM Zwischenergebnisse via SetValue() und erzwingt das synchrone Schreiben via SyncToStorage(). Dies gewährleistet Absturzsicherheit und Idempotenz gegen plötzlichen Spannungsverlust (Power-Off Safe).
   • Bei Korruption oder Abbruch ermöglichen ResetKey() / RecoverKey() bzw. DiscardPendingChanges() das koordinierte Zurücksetzen.
3. Validierung & Historisierung (SynchronizedTimeBaseConsumer):
   • Vor dem Aktivieren (Activate()) holt UCM via GetTimeWithStatus() die globale UTC-/TSI-Zeit, um Gültigkeitszeiträume von Update-Zertifikaten (Manifest-Signaturen) abzugleichen.
   • Durch RegisterTimeLeapNotifier() reagiert UCM auf drastische Zeitsprünge im Gesamtfahrzeug, um Timeouts und ungültige Update-Zertifikatsvalidierungen abzufangen.

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- und Concurrency-Modell:
  • UCM und TSync sind daemon-based ausgeführt; Zugriffe auf TSync erfolgen über IPC-Mechanismen des Plattform-Stacks.
  • Persistency ist in der Regel als prozessinterne Library implementiert, die Zugriff auf das zugrundeliegende Dateisystem abstrahiert. Datei- und Schlüsselzugriffe müssen thread-sicher und reentrant innerhalb des UCM-Kontexts gehandhabt werden.
• Manifest-Modellierung (ARXML):
  • UCM benötigt im Execution Manifest und Service Instance Manifest explizit deklarierte PRPortPrototype / RPortPrototype für FileStorage, KeyValueStorage und SynchronizedTimeBaseConsumer.
  • Definition separater PersistencyPortPrototypes für Dateispeicher (Mount-Points/Pfade) und Schlüssel-Werte-Datenbanken (z. B. redundante Speicherbereiche für Ausfallsicherheit).
• Restriktionen & Identity and Access Management (IAM):
  • UCM erfordert im Adaptive-Sicherheitskonzept Schreibzugriffsrechte auf dedizierte persistente Speicherpools. Fehlkonfigurationen in den Security-Policies blockieren den Aufruf von SyncToStorage() oder OpenFileWriteOnly() zur Laufzeit mit ara::core::ErrorCode(PerErrc::...).
• Robustheit & Sync:
  • Das Aufrufen von SyncToStorage() blockiert UCM potenziell I/O-seitig; Entwickler müssen I/O-Flaschenhälse beim Flashen/Installieren über asynchrone Worker-Threads oder non-blocking Execution-Pipelines entkoppeln.