Figure 11.2: Sequence diagram showing the data transmission

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm) mit geschachtelten loop-Kombinationsfragmenten (Combined Fragments).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Update and Configuration Management (UCM) gemäß AUTOSAR_AP_SWS_UpdateAndConfigurationManagement (Release R23-11).
• Technischer Zweck: Spezifikation des standardisierten Übertragungsprotokolls für Software-Pakete (Software Packages) über die Service-Schnittstelle PackageManagement (ara::ucm::pkgmgr::PackageManagement). Es bildet die Streaming- bzw. Chunking-Phase des Paket-Downloads (angelehnt an UDS ISO 14229-1 Services 0x34 RequestDownload, 0x36 TransferData, 0x37 RequestTransferExit) auf serviceorientierte Inter-Process-Communication (ara::com) ab.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • UCM Client: Service Consumer (Client). Generische applikative Instanz, welche die Software-Paketübertragung steuert und initiiert (z. B. OEM-spezifische Diagnose-Applikation, OTA-Client-Daemon oder Update-Orchestrator).
  • «ServiceProvider» :PackageManagement: Service Provider Lifeline. Die UCM-Kerninstanz, welche die standardisierte Service-Schnittstelle ara::ucm::pkgmgr::PackageManagement bereitstellt.
• Methoden & Signaturen (ara::com-Methodenaufrufe):
  • TransferStart(PackageSize: uint64) → (TransferId: TransferIdType, BlockSize: uint64): Initialisiert die Übertragungssitzung für ein einzelnes Software-Paket. Liefert die eindeutige Session-ID (TransferId) und die maximal zulässige Blockgröße (BlockSize) für Chunks zurück.
  • TransferData(TransferId: TransferIdType, ByteVectorType: ara::core::Span<const Byte> / ara::core::Vector<uint8_t>, blockCounter: uint64) → TransferDataReturnType: Sukzessiver Datenblock-Transfer.
  • TransferExit(TransferId: TransferIdType) → TransferExitReturnType: Schließt die Übertragung eines Software-Pakets ab.
• Interne Operationen / Selbstaufrufe (UCM-intern):
  • storeData(byteVector): Persistierung der empfangenen Chunks im zugewiesenen temporären Staging-/Swap-Speicherbereich.
  • checkTransferredPackage(): Integritäts- und Authentizitätsprüfung (z. B. Dekomprimierung, Validierung von Manifest, Signatur, SHA-256/SHA-512 Hash) nach vollständigem Empfang aller Blöcke.

3. Dynamisches Verhalten & Sequenzablauf

• Äußere Schleife (loop for each Software Package):
  • Wird für jedes zu installierende Software-Paket innerhalb einer Update-Kampagne durchlaufen.
  • 1. Initialisierung: Die Diagnose-Applikation ruft synchron oder asynchron via ara::core::Future die Methode TransferStart mit der Gesamtgröße PackageSize auf. UCM allokiert Ressourcen, generiert ein TransferId-Handle und meldet die verarbeitbare Blockgröße BlockSize zurück.
• Innere Schleife (loop for each segment of a Software Package):
  • Aufteilung des Pakets in diskrete Segmente ≤ BlockSize.
  • 2. Datenübertragung: Sequentieller Aufruf von TransferData(TransferId, ByteVectorType, blockCounter).
  • 3. Persistierung & Bestätigung: UCM führt synchron storeData(byteVector) aus, validiert den sequentiellen Zählerstand (blockCounter) und bestätigt den Block mit TransferDataReturnType (Erfolgsstatus oder UcmErrorDomain-Fehlercodes wie BlockReceivedOutOfOrder / InvalidTransferId).
• Abschluss & Validierung:
  • 4. Beendigung des Chunks-Streams: Nach Übertragung des letzten Segments ruft die Diagnose-Applikation TransferExit(TransferId) auf.
  • 5. Verifikation: UCM führt checkTransferredPackage() aus. Bei erfolgreicher Verifikation wechselt das Paket intern in den Zustand TRANSFERRED (bereit für ProcessSwPackage).
  • 6. Rückmeldung: UCM quittiert mit TransferExitReturnType (oder Fehlern wie PackageInconsistent, AuthenticationFailed, InsufficientMemory).

4. Normative Relevanz & Entwickler-Hinweise

• Puffer- und Speichermanagement:
  • Die Diagnostic Application muss die vom UCM in TransferStart zurückgegebene BlockSize zwingend einhalten; das Überschreiten führt zu Laufzeitfehlern (SizeTooLarge).
  • Der Applikationsentwickler muss Zero-Copy- oder Shared-Memory-Mechanismen (ara::com IPC) berücksichtigen, um Serialisierungs-Overheads bei großen Binaries im ByteVectorType zu minimieren.
• Robuste Blockzählung (blockCounter):
  • Der blockCounter beginnt normativ bei 1 und muss monoton inkrementiert werden. UCM prüft Paketverluste oder doppelte Blöcke; Abweichungen führen zum Abbruch der Übertragung.
• Fehlerbehandlung & Timeouts:
  • Schlägt checkTransferredPackage() fehl, muss UCM die allokierten Ressourcen bereinigen; die Applikation muss über TransferExitReturnType (ara::core::Result) die genaue Ursache evaluieren.
  • Bei Verbindungsabbruch oder Timeout greift das UCM-interne Session-Management (Inaktivitäts-Timeout führt zum Verfall der TransferId).
• Zustandsübergang im UCM-Lifecycle:
  • TransferExit vollzieht keinen Software-Austausch, sondern finalisiert ausschließlich den Transfer. Der Rollout (Aktivierung/Installation) erfordert nachfolgend separate Aufrufe der UCM-Service-Methoden (ProcessSwPackage, gefolgt von Activate im Rahmen des UCM State Handlings).