class ara::diag::DataTransferReadByPullHandler

Die Klasse ara::diag::DataTransferReadByPullHandler dient der Bereitstellung von Datei- oder Verzeichnisdaten, die von der Diagnoseschicht AraDiag im Rahmen einer UDS-Leseoperation aktiv aus der Anwendung abgerufen werden ([SWS_DM_01506]). Der Ablauf umfasst den schrittweisen Datenabruf über Read() bis zum finalen Sitzungsabschluss über ExitRead(). Als strikte Lebenszyklus-Bedingung darf eine Handler-Instanz, die genau einer einzelnen Transfersitzung zugeordnet ist, keinesfalls vor dem Aufruf von ExitRead() zerstört werden ([SWS_DM_01510]).

mehr ›

Kontext

Die Klasse ara::diag::DataTransferReadByPullHandler ([SWS_DM_01506], AUTOSAR_AP_SWS_Diagnostics §8.10.2 „Class: DataTransferReadByPullHandler“) wickelt Datentransfers ab, die durch Diagnoseanforderungen zum Lesen von Dateien oder Verzeichnissen (wie RequestReadFile oder RequestReadDirectory) initiiert wurden. Die Architektur basiert auf einem Pull-Verfahren, bei dem die Diagnoseschicht AraDiag die zu übertragenden Daten aktiv aus der Implementierung abfragt („pulled“).

An der Interaktion sind drei Komponenten beteiligt: der externe UDS-Client (Diagnosetester), das Diagnose-Subsystem AraDiag und die anwendungsspezifische Handler-Implementierung. Der externe Client sendet Leseanfragen, woraufhin AraDiag die Methoden des Handlers aufruft, um schrittweise Datenchunky bereitzustellen und an den UDS-Client zu übermitteln ([SWS_DM_01513]).

Lebenszyklus

Der Lebenszyklus einer Handler-Instanz ist exklusiv an eine einzelne Dateitransfersitzung gebunden. Der Standardkonstruktor ist protected deklariert ([SWS_DM_01507]). Interpretation: Die konkrete Anwendung dürfte daher eine abgeleitete Subklasse implementieren und instanziieren. Frage Q-cb78bc4a1d40968b (offen)

Kopieroperationen sind vollständig deaktiviert: Der Kopierkonstruktor ([SWS_DM_01509]) und der Kopierzuweisungsoperator ([SWS_DM_01512]) sind als gelöscht (=delete) spezifiziert, da Handler für die Einweg-Nutzung innerhalb einer Sitzung bestimmt sind („only one way usage i.e. per single file transfer session“). Verschiebeoperationen (Move Constructor und Move Assignment) sind dagegen als Standardimplementierung definiert und als noexcept deklariert ([SWS_DM_01508], [SWS_DM_01511], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.1.1 „Move Constructor“).

Für die Freigabe gilt eine strikte Vorbedingung: Eine Instanz der Klasse darf keinesfalls zerstört werden, bevor die Methode ExitRead() aufgerufen wurde ([SWS_DM_01510], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.1.2 „Destructor“). Bezüglich der Nebenläufigkeit sind die Schnittstellenmethoden Read() und ExitRead() als nicht threadsicher („not thread-safe“), aber ausnahmesicher (noexcept) definiert ([SWS_DM_01513], [SWS_DM_01514]).

Nutzungspfad

Der reguläre Ablauf eines Datenabrufs gliedert sich in folgende Schritte:

1. Initialisierung: Die Anwendung instanziiert die abgeleitete Handler-Klasse für die anstehende Transfersitzung.
2. Datenabruf: Zur Bereitstellung der Datenblöcke ruft AraDiag die Methode Read() auf ([SWS_DM_01513], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.3.2 „Read“). Die Anwendung erhält eine Speicheransicht response_data (vom Typ ara::core::Span<const ara::core::Byte>) auf einen von AraDiag vorallokierten Puffer, füllt diesen mit den nächsten Dateiinhalten und schließt das ara::core::Future<std::uint32_t> mit der geschriebenen Bytezahl ab. AraDiag fügt diese Daten hinter dem Blocksequenzzähler (blockSequenceCounter) als transferResponseParameterRecord in die positive UDS-Antwort ein ([SWS_DM_01513]). Dieser Schritt wird für nachfolgende Chunks wiederholt.
3. Sitzungsabschluss: Zum regulären Beenden der Übertragung ruft AraDiag ExitRead() auf ([SWS_DM_01514], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.3.1 „ExitRead“). Übergeben werden der Beendigungsgrund exit_type, herstellerspezifische Parameter (transfer_request_parameter_record), meta_info und ein cancellation_handler. Die Implementierung quittiert dies über ein ara::core::Future<ara::core::Vector<ara::core::Byte>>, dessen Rückgabewerte hinter der SID in der positiven Antwort übermittelt werden ([SWS_DM_01514]).
4. Freigabe: Erst nach erfolgtem Aufruf von ExitRead() darf das Handler-Objekt zerstört werden ([SWS_DM_01510]).

Sequenzdiagramm: Typischer Ablauf des Datenabrufs per Pull-Verfahren über AraDiag. Quellen: [SWS_DM_01513], [SWS_DM_01514]

Fehlerszenarien

Treten bei der Datenaufbereitung oder beim Abschluss Fehler auf, meldet die Anwendung dies über das zurückgegebene Future, indem sie es mit einem UDS-Fehlercode (DiagUdsNrcErrc nach ISO 14229-1) bereitstellt ([SWS_DM_01513], [SWS_DM_01514]). AraDiag generiert daraufhin die entsprechende negative UDS-Antwort (NRC) an den Tester.

Für den vorzeitigen Abbruch wird beiden Methoden ein CancellationHandler übergeben ([SWS_DM_01513], [SWS_DM_01514]). Die Anwendung kann über cancellation_handler.IsCanceled() prüfen, ob die Konversation abgebrochen wurde, oder via cancellation_handler.SetNotifier() eine Rückruffunktion registrieren. Die bereitgestellten Puffer (response_data und transfer_request_parameter_record) bleiben bis zur Erfüllung des Promises bzw. bis zum Abbruch über den Handler gültig.

Wird die Instanz vor dem Aufruf von ExitRead() zerstört, liegt eine Verletzung der Spezifikationsvorgabe vor ([SWS_DM_01510]), was zu unvollständigen Transfersitzungen und undefinierten Systemzuständen führen kann.