Figure 9.3: UCM composite structure - Information related (Part 1)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Service-Datenmodell (Strukturdiagramm für Datentypen, Vektoren und Service-Schnittstellen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R25-11), Spezifikation Update and Configuration Management (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement).
• Technischer Zweck: Definition des statischen Typ- und Schnittstellenmodells für UCM-Statusabfragen (Informational / Getter APIs) des UCM-Kernservice PackageManagement. Das Modell kapselt Identifikatoren, Transferfortschritte, Paketmetadaten, Cluster-Zustände sowie die lückenlose Update-Historie (Audit-Trail) für OTA-Clients bzw. UCM-Master-Instanzen.

2. Komponenten, Entitäten & Schnittstellen

2.1 Service-Schnittstelle

• «interface» PackageManagement (Getter) [SWS_UCM_00131]: Definiert die synchronen/asynchronen Abfragemethoden (ara::com Service-Methoden) für den UCM-Status:
  • GetHistory(unsigned long, unsigned long): HistoryVectorType – Abfrage historischer Update-Aktionen innerhalb eines Zeit- oder Indexfensters.
  • GetId(): UCMIdentifierAndVersionType – Auslesen der UCM-Instanzkennung und Version.
  • GetProgress(TransferIdType): char – Abfrage des Übertragungs-/Verarbeitungsfortschritts für eine aktive Übertragung (im generierten C++-Binding typischerweise ProgressInformationType / Fortschrittswert).
  • GetSwClusterInfo(): SwClusterInfoVectorType – Abfrage des Ist-Zustands aller Software-Cluster auf dem Target.
  • GetSwClusterManifestInfo(SwNameType): SwClusterManifestInfoType – Detaillierte Manifest-Metadaten eines spezifizierten Clusters.
  • GetSwClustersChangeInfo(): SwClusterInfoVectorType – Liste der von aktuellen/anstehenden Updates betroffenen Cluster.
  • GetSwPackages(): SwPackageInfoVectorType – Auflistung aller im UCM bekannten bzw. transferierten Software-Pakete.

2.2 Datenstrukturen & Vektoren («dataType»)

• SwPackageInfoVectorType [SWS_UCM_00040]:
  • Aggregation von SwPackageInfoType mit Kardinalität [1..n].
• SwPackageInfoType [SWS_UCM_00039]:
  • consecutiveBlocksReceived: uint64 – Zähler der kontinuierlich empfangenen Block-Sequenzen.
  • consecutiveBytesReceived: uint64 – Bisher empfangene Gesamtdatenmenge in Bytes.
  • state: SwPackageStateType – Aktueller Transfer-/Verarbeitungsstatus.
  • swClusterName: SwClusterNameType – Assoziierter Software-Cluster.
  • swPackageName: SwPackageNameType – Eindeutiger Paketname.
  • transferId: TransferIdType – Sitzungsgebundene Übertragungs-ID.
  • version: StrongRevisionLabelString – Semantische Versionsbezeichnung des Pakets.
• HistoryVectorType [SWS_UCM_00135]:
  • Aggregation von HistoryType mit Kardinalität [1..n].
• HistoryType [SWS_UCM_00134]:
  • action: ActionType – Ausgeführte Operation.
  • failureError: uint64 – UCM-Fehlercode bei fehlgeschlagenen Operationen (0 bei Erfolg).
  • name: SwClusterNameType – Name des betroffenen Ziel-Clusters.
  • resolution: ResultType – Finales Ergebnis der Update-Transaktion.
  • time: uint64 – POSIX-Timestamp der Transaktionsdurchführung.
  • version: StrongRevisionLabelString – Software-Version nach Abschluss der Operation.
• ProgressInformationType [SWS_UCM_00341]:
  • currentStatus: UpdateStateType – Status des Update-Ablaufs.
  • estimatedDuration: uint32 – Geschätzte Restdauer in Sekunden.
  • progress: uint8 – Prozentualer Fortschritt (0..100 %).

2.3 Primitiven und Typdefinitionen («primitive» / «dataType»)

• TransferIdType [SWS_UCM_00031]: Primitiver Typ (UUID/Ganzzahl) zur eindeutigen Identifikation einer laufenden Transfer-Transaktion (TransferStart).
• SwClusterNameType [SWS_UCM_00071]: String-basierter Typ für den kanonischen Namen eines Software-Clusters.
• SwPackageNameType [SWS_UCM_00362]: Typ zur Kennzeichnung des spezifischen Software-Paketnamens.
• StrongRevisionLabelString [SWS_UCM_00175]: Strikt formatierter String (gemäß SemVer / AUTOSAR-Versionskonventionen).

2.4 Enumerationen («enumeration»)

• SwPackageStateType [SWS_UCM_00038]:
  • kTransferring = 0x00 (Paketübertragung läuft)
  • kTransfered = 0x01 (Paket vollständig übertragen)
  • kProcessing = 0x02 (Inhaltsverarbeitung / Dekomprimierung / Validierung läuft)
  • kProcessed = 0x03 (Verarbeitung erfolgreich abgeschlossen)
  • kProcessingStream = 0x04 (Streaming-basierte direkte Verarbeitung aktiv)
• UpdateStateType [SWS_UCM_00396]:
  • kPreparing = 0x02, kActivating = 0x03, kActivated = 0x04, kRollingBack = 0x05, kRolledBack = 0x06, kCleaningUp = 0x07, kVerifying = 0x08, kRollingBackFailed = 0x09.
• ActionType [SWS_UCM_00132]:
  • kUpdate = 0x00 (Cluster-Update)
  • kInstall = 0x01 (Neuinstallation eines Clusters)
  • kRemove = 0x02 (Deinstallation eines Clusters)
  • kUpdateConfiguration = 0x03 (Reine Konfigurationsänderung)
• ResultType [SWS_UCM_00133]:
  • kActivated = 0x00 (Erfolgreich aktiviert)
  • kActivatedAndRolledBack = 0x01 (Aktiviert, aber wegen Fehler auf Altstand zurückgerollt)
  • kVerificationFailed = 0x02 (Verifikation vor Aktivierung fehlgeschlagen)

3. Dynamisches Verhalten & Sequenzablauf

Das Klassendiagramm bildet den Datenvertrag für den nachfolgenden synchronen Abfrage- und Statuszyklus während einer Update-Kampagne:

OTA-Client / Backend                 UCM (PackageManagement)
        |                                       |
        |--- GetSwPackages() ------------------>| [Liefert SwPackageInfoVectorType]
        |    (Validierung Zustand/Bytes)        |
        |                                       |
        |--- GetProgress(TransferId) ---------->| [Liefert ProgressInformationType]
        |    (Abfrage während Aktivierung/Ver.) | (Zustände: kPreparing -> kActivating -> ...)
        |                                       |
        |--- [Nach Kampagnenabschluss] -------->|
        |--- GetHistory(startTime, endTime) --->| [Liefert HistoryVectorType]
        |    (Auditierung ResultType/ActionType)|

• Trigger & Preconditions:
  • GetProgress setzt eine über TransferStart initiierte, gültige TransferIdType voraus.
  • GetHistory greift auf den persistenten, crash-sicheren Transaktions-Log des UCM-Speichers zu.
• Abbruch- und Fehlerbedingungen:
  • Im Fehlerfall wechselt UpdateStateType von kActivating/kVerifying nach kRollingBack und final nach kRolledBack bzw. kRollingBackFailed.
  • Ein Eintrag in HistoryType registriert bei Abbruch resolution = kVerificationFailed oder kActivatedAndRolledBack unter Angabe des Fehlercodes in failureError.

4. Normative Relevanz & Entwickler-Hinweise

• Service-Contract & Serialisierung (ara::com):
  • Die Vektoren SwPackageInfoVectorType und HistoryVectorType erfordern dynamische Container-Implementierungen (ara::core::Vector), deren Serialisierungs-Overhead über SOME/IP oder IPC bei großen Cluster-Zahlen und langen Historien begrenzt werden muss (Paginierung über Parameter bei GetHistory).
• Streaming-Handling (kProcessingStream):
  • Wenn der UCM direkt aus dem Eingangsstream verarbeitet, signalisiert SwPackageStateType::kProcessingStream, dass keine lokale Komplettkopie des Pakets im Flash gehalten wird. consecutiveBytesReceived dient hierbei dem lückenlosen Nachweis des Stream-Fortschritts.
• Persistenz & Crash-Konsistenz:
  • HistoryType muss persistent gegen unvorhergesehene Spannungsabfälle (Power-Cut during Activation) geschützt sein. Das Feld failureError spiegelt die normativen UCM-Fehlerklassen (ara::core::ErrorCode) als 64-Bit-Ganzzahlwert wider.
• Atomizität der Zustände:
  • Die explizite Trennung von ActionType (kUpdate, kInstall, kRemove, kUpdateConfiguration) und ResultType erzwingt eine zweidimensionale Validierung im OTA-Client: Ein Transaktionserfolg darf erst deklariert werden, wenn resolution == kActivated (0x00) und failureError == 0 vorliegen.