Figure 9.101: Interfaces for Upload and Download

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Architekturmodell).
• Technischer Zweck: Spezifikation der Service-Schnittstellen für blockbasierte Datentransfers (ISO 14229-1 UDS Services: 0x34 RequestDownload, 0x35 RequestUpload, 0x36 TransferData, 0x37 RequestTransferExit) im Adaptive Platform Functional Cluster Diagnostic Management (DM).
• Architektur-Einordnung:
  • Das Schaubild visualisiert die Entkopplung zwischen dem Plattform-Daemon (Diagnostic Management, daemon-based) und der Anwendungslogik (Diagnostic Application innerhalb einer Adaptive Application).
  • Die Anwendungs-Software stellt die Datenbereitstellung bzw. Datensenke via P-Port bereit; der zentrale Diagnose-Daemon fungiert als Service-Konsument («use») und wickelt das Transportprotokoll (DoIP, UDS) extern ab, während er interne Transfers an die Applikation delegiert.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Akteure:
  • Adaptive Application / Diagnostic Application: Applikativer Container bzw. Diagnose-Software-Komponente, die als Server für Up-/Download-Logik agiert.
  • «aapFunctionalCluster» Diagnostic Management (daemon-based): Plattform-Dienstkomponente der Adaptive Platform. Terminiert externe UDS-Sessions und routet Datentransfers zu den registrierten Applikations-Handlern.
• Schnittstellen (Port Interfaces):
  • DownloadService («aapPortInterface»):
    • Offer() / StopOffer(): Registrierung/Deregistrierung des Service-Handlers am Diagnose-Daemon.
    • RequestDownload(): Validierung von Speicheradresse, Datenformat und unkomprimierter/komprimierter Datenlänge (UDS Service 0x34).
    • DownloadData(): Verarbeitet eingehende Datenblöcke mit Blocksequenzzähler (UDS Service 0x36).
    • RequestDownloadExit(): Terminiert den Download und prüft die finale Integrität/Transfer-Parameter (UDS Service 0x37).
  • UploadService («aapPortInterface»):
    • Offer() / StopOffer(): Lifecycle-Steuerung des Handlers im Daemon.
    • RequestUpload(): Initiiert das Auslesen von Speicherbereichen über UDS Service 0x35.
    • UploadData(): Bereitstellung des jeweils nächsten Datenblocks inklusive Block-Counter (UDS Service 0x36).
    • RequestUploadExit(): Schließt den Upload-Prozess ab (UDS Service 0x37).
• Beziehungen & Stereotypen:
  • Diagnostic Application realisiert beide Interfaces über «aapProvidedPort» (P-Ports).
  • Diagnostic Management konsumiert beide Interfaces über «use»-Abhängigkeiten (R-Port-Äquivalent auf Daemon-Seite via ara::com oder IPC-Mechanismus).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Registrierung:
   • Die Diagnostic Application ruft Offer() auf DownloadService bzw. UploadService auf, um die Verarbeitungsbereitschaft beim Diagnostic Management-Daemon via IPC anzumelden.
2. Transfer-Initialisierung:
   • Der Daemon empfängt einen externen Diagnose-Request (0x34 bzw. 0x35), parst Header/Subfunktionen und ruft synchron oder asynchron (ara::core::Future) RequestDownload() bzw. RequestUpload() an der Applikation auf.
   • Die Applikation verifiziert Adressbereiche, Allokationen und Zugriffsrechte und liefert die maximale Blocklänge (bzw. UDS NRCs wie 0x31 Request Out Of Range, 0x33 Security Access Denied) zurück.
3. Zyklischer Datentransfer (0x36 TransferData):
   • Sequenzielle Iteration: Für jeden empfangenen/angeforderten Block delegiert der Daemon an DownloadData() (persistieren/flashen) bzw. UploadData() (auslesen).
   • Der Block Sequence Counter (BSC) wird validiert; Fehler führen zum Abbruch oder NRC 0x73 (Wrong Block Sequence Counter).
4. Transfer-Abschluss:
   • Der Tester sendet 0x37 RequestTransferExit. Der Daemon leitet diesen an RequestDownloadExit() bzw. RequestUploadExit() weiter. Die Applikation führt abschließende Prüfungen durch (z. B. CRC/Signature Check, Finalisierung des Flash-Speichers).
5. Deregistrierung:
   • Bei Shutdown oder Zustandswechsel meldet sich die Applikation mittels StopOffer() am Daemon ab.

4. Normative Relevanz & Entwickler-Hinweise

• API-Design (ara::diag):
  • Entspricht dem C++ API-Muster von ara::diag::DownloadService und ara::diag::UploadService. Methoden geben typischerweise ara::core::Future<OperationOutput> zurück, um non-blocking I/O bei Flash-/NVM-Schreiboperationen zu gewährleisten.
• Puffer- und Speichermanagement:
  • Datenblöcke (DownloadData / UploadData) erfordern die strikte Einhaltung der verhandelten maximalen Blockgröße (maxNumberOfBlockLength). Entwickler müssen Zero-Copy- oder Shared-Memory-Puffer über IPC berücksichtigen, um Latenzen bei großen Firmware-Updates (FOTA) zu minimieren.
• NRC-Handling:
  • Applikationen müssen Fehlerzustände als ara::diag::DiagnosticErrorDomain-Codes zurückgeben, die der Daemon direkt in die normativen UDS-Negativantworten (NRCs gemäß ISO 14229-1) übersetzt.
• Zustandssynchronisation:
  • Das State-Handling (z. B. aktiver Download-Zustand, Überwachung von Session-Timeouts S3_server) obliegt dem Daemon. Bricht die UDS-Session extern ab, bricht der Daemon den Transfer intern ab; der Handler muss reentrant sein bzw. Transaktionen sicher zurückrollen.