Figure 9.92: Users of the Update and Configuration Management interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Service Interface Specification gemäß AUTOSAR Adaptive Platform Metamodell).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11. Verortung in den Systemdiensten (Functional Clusters). Das Diagramm spezifiziert die Service-Beziehung zwischen fahrzeugweiter Update-Koordination (Vehicle Update and Configuration Management / VUCM) und lokaler Instanz-Aktualisierung (Update and Configuration Management / UCM).
• Technischer Zweck: Definition des Servicevertrags über ara::com für die Client-Server-Interaktion: VUCM agiert als Orchestrator/Client, der über die Standardschnittstelle PackageManagement die atomare Verteilung, Installation, Verifikation und Aktivierung von Software-Paketen auf dem lokalen UCM-Daemon steuert.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Entitäten (Functional Clusters):
  • Vehicle Update and Configuration Management («aapFunctionalCluster», Ausprägung: daemon-based): Client-Instanz (R-Port). Aggregiert und dirigiert fahrzeugweite Updates über mehrere ECUs/Instanzen hinweg.
  • Update and Configuration Management («aapFunctionalCluster», Ausprägung: daemon-based): Server-Instanz (P-Port). Verwaltet lokale Software-Cluster, Speicherpartitionen (A/B-Swap) und State-Transitions auf Maschinenebene.
• Schnittstelle (Service Interface):
  • Update and Configuration Management::PackageManagement («aapAPI, aapAraComServiceInterface»): Zentrales Service Interface für UCM.
  • Service Field («aapAccessControlled, aapServiceField»):
    • + CurrentStatus: Repräsentiert den aktuellen UCM-Zustand (z. B. kIdle, kReady, kProcessing, kActivating, kActivated, kRollingBack). Überwacht via Notifier/Getter.
  • Service Methods («aapAccessControlled, aapServiceMethod»):
    • Transfer-Lebenszyklus & Registrierung: TransferStart(), TransferData(), TransferExit(), DeleteTransfer(), RegisterSoftwarePackage().
    • Verarbeitung & Ausführung: ProcessSwPackage(), RevertProcessedSwPackages(), Activate(), Finish(), Rollback(), Cancel().
    • Diagnose & Informationsabfrage: GetHistory(), GetId(), GetProgress(), GetSwClusterChangeInfo(), GetSwClusterInfo(), GetSwClusterManifestInfo(), GetSwPackages().
• Beziehungen & Stereotypen:
  • «aapProvidedPort»: Realisierungsbeziehung (gestrichelte Linie mit geschlossener Pfeilspitze) vom UCM-Daemon zum Service Interface (Server/Provider).
  • «aapRequiredPort» / «use»: Abhängigkeitsbeziehung (offene Pfeilspitze) von VUCM zum Service Interface (Client/Consumer).
  • «aapAccessControlled»: Sämtliche Felder und Methoden unterliegen dem Identity and Access Management (IAM) der Adaptive Platform; Zugriffe erfordern entsprechende Manifest-Berechtigungen (Process Execution Manifest / Service Instance Manifest Grants).

3. Dynamisches Verhalten & Sequenzablauf

Die Methoden und Felder bilden die UCM-State-Machine ab:

1. Vorbereitungsphase (Transfer & Registrierung):
   • Client initiiert Blocktransfer via TransferStart() (liefert Transfer-ID/Blockgröße).
   • Chunkweiser Nutzdaten-Upload über synchrone/asynchrone Aufrufe von TransferData().
   • Abschluss der Übertragung mit TransferExit(); Bereinigung bei Fehlern über DeleteTransfer().
   • Alternativ direkte Registrierung bereits lokal bereitgestellter Pakete über RegisterSoftwarePackage().
2. Verarbeitungsphase (Processing):
   • Aufruf von ProcessSwPackage(). UCM prüft Signatur, Abhängigkeiten und Software Cluster Manifest (GetSwClusterManifestInfo()).
   • Fortschrittsüberwachung über Polling von GetProgress() oder Auswertung des CurrentStatus-Fields.
   • Rückabwicklung unvollständiger oder fehlerhafter Staging-Schritte via RevertProcessedSwPackages() oder Cancel().
3. Aktivierungs- & Validierungsphase (Activation & Commit):
   • UCM synchronisiert mit Execution Management (EM) und State Management (SM); Aufruf von Activate() schaltet aktive Partition/Executable-Set um.
   • Nach erfolgreichem System-Health-Check bestätigt VUCM den Vorgang persistent mittels Finish().
   • Schlägt die Funktionsvalidierung fehl, stellt Rollback() den vorherigen konsistenten Software-Cluster-Zustand wieder her.

4. Normative Relevanz & Entwickler-Hinweise

• Client-/Applikations-Entwicklung (VUCM / OTA-Clients):
  • Implementierung erfolgt als ara::com-Service-Proxy (ara::ucm::pkgmgr::proxy::PackageManagementProxy).
  • Asynchrone API-Semantik: Methodenaufrufe liefern ara::core::Future / ara::core::Result. Fehlerfälle werden über typsichere UcmErrorErrc-Enums transportiert (z. B. InsufficientMemory, AuthenticationFailed, InvalidPackageManifest).
• Identity & Access Management (IAM):
  • Aufgrund des Stereotyps «aapAccessControlled» scheitert jeder Methodenaufruf zur Laufzeit mit Zugriffsverweigerung (kAccessDenied), wenn die Client-Applikation im Execution Manifest nicht explizit für das Service Interface und die konkrete Method/Field-ID berechtigt ist.
• Plattform- & Stack-Integration:
  • UCM-Daemon muss vor ProcessSwPackage() und Activate() Schnittstellen zum State Management (SM) bedienen, um Applikationen geregelt anzuhalten und System-Safestates zu garantieren.
  • Das Field CurrentStatus erfordert IPC/Network-Binding-Ressourcen für Events/Field-Notifications (Skeleton-seitige Zuweisung und Pufferung).