class ara::diag::DataTransferWriteHandler

Die Klasse ara::diag::DataTransferWriteHandler dient in AUTOSAR Adaptive der anwendungsseitigen Verarbeitung von schreibenden Dateitransfers, die durch RequestWriteFile in den Modi AddFile, ResumeFile oder ReplaceFile angestoßen wurden [SWS_DM_01539]. Eingehende Datenpakete werden asynchron über Write() in den Speicher geschrieben und die Sitzung anschließend mittels ExitWrite() abgeschlossen. Eine Instanz ist strikt an eine einzelne Übertragungssitzung gebunden und darf keinesfalls vor dem Aufruf von ExitWrite() zerstört werden [SWS_DM_01541].

mehr ›

Kontext

Die abstrakte Basisklasse ara::diag::DataTransferWriteHandler definiert in der AUTOSAR Adaptive Platform die Schnittstelle für schreibende Dateitransfers [SWS_DM_01539] (AUTOSAR_AP_SWS_Diagnostics §8.10.6 „Class: DataTransferWriteHandler“). Sie dient der anwendungsseitigen Verarbeitung von Datenübertragungen, die im Rahmen von RequestWriteFile über die Betriebsmodi AddFile, ResumeFile oder ReplaceFile angestoßen wurden.

Innerhalb der Diagnosearchitektur interagiert der Handler mit dem externen UDS-Client, der Diagnose-Middleware und der Anwendung. Der Client übermittelt segmentierte Datenblöcke, die von einer abgeleiteten Implementierung des Handlers entgegengenommen und im Anwendungsspeicher abgelegt werden [SWS_DM_01546]. Vermutlich übernimmt das Diagnose-Management der Plattform dabei die UDS-Protokollkoordination und reicht die Nutzdaten über die Handler-Schnittstelle an die Zielanwendung weiter. Frage Q-484dc9dd80e56af4 (offen)

Lebenszyklus

Die Instanziierung von ara::diag::DataTransferWriteHandler erfolgt ausschließlich durch spezialisierte Unterklassen der Anwendung: Der parameterlose Konstruktor ist mit protected und noexcept=default definiert [SWS_DM_01540], was eine direkte Instanziierung der Basisklasse verhindert. Eine Handler-Instanz ist strikt an eine einzelne Dateiübertragungssitzung gebunden („one way usage i.e. per single file transfer session“). Aus diesem Grund sind der Kopierkonstruktor [SWS_DM_01544] (AUTOSAR_AP_SWS_Diagnostics §8.10.6.1.2.1 „DataTransferWriteHandler“) und der Kopierzuweisungsoperator [SWS_DM_01545] gelöscht (=delete).

Verschiebeoperationen sind hingegen zulässig: Sowohl der Verschiebekonstruktor [SWS_DM_01542] (AUTOSAR_AP_SWS_Diagnostics §8.10.6.1.1.1 „Move Constructor“) als auch der Verschiebezuweisungsoperator [SWS_DM_01543] sind mit noexcept=default implementiert und gelten als ausnahmesicher (exception safe).

Für den Abbau der Instanz gilt eine bindende Vorbedingung: Eine Instanz dieser Klasse darf keinesfalls zerstört werden, bevor die Methode ExitWrite() aufgerufen wurde [SWS_DM_01541] (AUTOSAR_AP_SWS_Diagnostics §8.10.6.1.1.2 „Destructor“). Erst nach vollständiger Durchführung von ExitWrite() darf der virtuelle Destruktor ~DataTransferWriteHandler() aufgerufen werden. Die Elementfunktionen und der Destruktor sind als nicht threadsicher (not thread-safe) spezifiziert [SWS_DM_01541], [SWS_DM_01546], [SWS_DM_01547].

Zustandsdiagramm: Lebenszyklus und Aufrufabfolge einer DataTransferWriteHandler-Instanz. Quellen: [SWS_DM_01541], [SWS_DM_01544].

Nutzungspfad

Der reguläre Ablauf eines schreibenden Transfers umfasst das schrittweise Empfangen von Datenblöcken und den anschließenden Abschluss der Sitzung:

• Für jedes eintreffende Datensegment ruft das Diagnosesystem die rein virtuelle Methode Write() auf [SWS_DM_01546] (AUTOSAR_AP_SWS_Diagnostics §8.10.6.1.3.2 „Write“). Die Daten werden als ara::core::Span<ara::core::Byte> übergeben. Die Gültigkeit dieses Speicherbereichs bleibt bestehen, bis das zugehörige Promise erfüllt oder die Operation abgebrochen wird. Die Anwendung hängt die Daten an den internen Puffer an und liefert ein ara::core::Future<void> zurück.
• Nachdem alle Segmente übertragen wurden, ruft die Plattform die rein virtuelle Methode ExitWrite() auf [SWS_DM_01547] (AUTOSAR_AP_SWS_Diagnostics §8.10.6.1.3.1 „ExitWrite“). Übergeben werden der Beendigungsgrund (DataTransferExitType), fahrzeugherstellerspezifische Parameter (transferRequestParameterRecord), metaInfo sowie ein CancellationHandler.
• Die Methode ExitWrite() gibt ein ara::core::Future<ara::core::Vector<ara::core::Byte>> zurück. Bei erfolgreichem Abschluss werden die darin enthaltenen Daten als transferResponseParameterRecord hinter der Service-ID in die positive UDS-Antwortnachricht eingefügt [SWS_DM_01547].

Sequenzdiagramm: Aufrufsequenz von Write- und ExitWrite-Operationen während einer Transfersitzung. Quellen: [SWS_DM_01546], [SWS_DM_01547].

Fehlerszenarien

Fehler während der Datenverarbeitung und des Transfers werden über standardisierte Rückgabewerte und Abbruchmechanismen verwaltet:

• Schlägt das Schreiben eines Datenblocks oder das Beenden des Transfers fehl, wird das jeweilige Future mit einem ara::core::ErrorCode aus DiagUdsNrcErrc bereitgestellt [SWS_DM_01546], [SWS_DM_01547]. Dies führt zur Generierung einer entsprechenden negativen UDS-Antwort (NRC gemäß ISO 14229-1) an den Client.
• Beide Methoden stellen einen CancellationHandler bereit. Die Anwendung kann über cancellationHandler.IsCanceled() prüfen, ob die Konversation abgebrochen wurde, oder mittels cancellationHandler.SetNotifier() eine Benachrichtigungsfunktion registrieren, die bei Abbruch der Konversation ausgeführt wird [SWS_DM_01546], [SWS_DM_01547].
• Wird die Instanz vor dem Aufruf von ExitWrite() zerstört, liegt ein Verstoß gegen die spezifizierte Lebenszyklusregel vor [SWS_DM_01541], was vermutlich zu undefiniertem Systemzustand und unvollständigen Dateien führt. Frage Q-cc032c11ac89a5b1 (offen) Zudem führt ein ungeschützter nebenläufiger Zugriff zu Dateninkonsistenzen, da die Schnittstelle explizit nicht threadsicher ist.