clase ara::diag::DataTransferReadByPullHandler

La clase ara::diag::DataTransferReadByPullHandler sirve para proporcionar datos de archivos o directorios que la capa de diagnóstico AraDiag recupera activamente de la aplicación en el marco de una operación de lectura UDS ([SWS_DM_01506]). El flujo comprende la recuperación progresiva de datos mediante Read() hasta la finalización definitiva de la sesión mediante ExitRead(). Como condición estricta del ciclo de vida, una instancia del manejador asignada exactamente a una única sesión de transferencia no debe destruirse en ningún caso antes de la invocación de ExitRead() ([SWS_DM_01510]).

más ›

Contexto

La clase ara::diag::DataTransferReadByPullHandler ([SWS_DM_01506], AUTOSAR_AP_SWS_Diagnostics §8.10.2 «Class: DataTransferReadByPullHandler») gestiona transferencias de datos iniciadas por solicitudes de diagnóstico para la lectura de archivos o directorios (como RequestReadFile o RequestReadDirectory). La arquitectura se basa en un procedimiento pull en el que la capa de diagnóstico AraDiag solicita («pulled») activamente a la implementación los datos que se van a transmitir.

En la interacción intervienen tres componentes: el cliente UDS externo (tester de diagnóstico), el subsistema de diagnóstico AraDiag y la implementación del manejador específica de la aplicación. El cliente externo envía solicitudes de lectura, tras lo cual AraDiag invoca los métodos del manejador para suministrar secuencialmente fragmentos de datos y transmitirlos al cliente UDS ([SWS_DM_01513]).

Ciclo de vida

El ciclo de vida de una instancia del manejador está vinculado exclusivamente a una única sesión de transferencia de archivos. El constructor por defecto está declarado protected ([SWS_DM_01507]). Interpretación: por tanto, es probable que la aplicación concreta implemente e instancie una subclase derivada. Pregunta Q-cb78bc4a1d40968b (abierta)

Las operaciones de copia están completamente deshabilitadas: el constructor de copia ([SWS_DM_01509]) y el operador de asignación por copia ([SWS_DM_01512]) están especificados como eliminados (=delete), ya que los manejadores están destinados a un uso de una sola vía dentro de una sesión («only one way usage i.e. per single file transfer session»). En cambio, las operaciones de movimiento (constructor de movimiento y asignación por movimiento) están definidas como implementación estándar y declaradas como noexcept ([SWS_DM_01508], [SWS_DM_01511], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.1.1 «Move Constructor»).

Para la liberación rige una condición previa estricta: una instancia de la clase no debe destruirse bajo ninguna circunstancia antes de que se haya invocado el método ExitRead() ([SWS_DM_01510], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.1.2 «Destructor»). En lo que respecta a la concurrencia, los métodos de interfaz Read() y ExitRead() están definidos como no seguros para hilos («not thread-safe»), pero seguros ante excepciones (noexcept) ([SWS_DM_01513], [SWS_DM_01514]).

Ruta de uso

El flujo regular de una recuperación de datos se divide en los siguientes pasos:

1. Inicialización: la aplicación instancia la clase de manejador derivada para la sesión de transferencia pendiente.
2. Recuperación de datos: para proporcionar los bloques de datos, AraDiag invoca el método Read() ([SWS_DM_01513], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.3.2 «Read»). La aplicación recibe una vista de memoria response_data (del tipo ara::core::Span<const ara::core::Byte>) sobre un búfer preasignado por AraDiag, lo llena con el siguiente contenido del archivo y completa el ara::core::Future<std::uint32_t> con el número de bytes escritos. AraDiag inserta estos datos tras el contador de secuencia de bloque (blockSequenceCounter) como transferResponseParameterRecord en la respuesta UDS positiva ([SWS_DM_01513]). Este paso se repite para los fragmentos posteriores.
3. Finalización de sesión: para concluir la transmisión de forma regular, AraDiag invoca ExitRead() ([SWS_DM_01514], AUTOSAR_AP_SWS_Diagnostics §8.10.2.1.3.1 «ExitRead»). Se transfieren el motivo de finalización exit_type, parámetros específicos del fabricante (transfer_request_parameter_record), meta_info y un cancellation_handler. La implementación acusa recibo de esto mediante un ara::core::Future<ara::core::Vector<ara::core::Byte>>, cuyos valores de retorno se transmiten tras el SID en la respuesta positiva ([SWS_DM_01514]).
4. Liberación: el objeto manejador solo puede destruirse una vez realizada la invocación de ExitRead() ([SWS_DM_01510]).

Diagrama de secuencias: flujo típico de recuperación de datos mediante el procedimiento pull a través de AraDiag. Fuentes: [SWS_DM_01513], [SWS_DM_01514]

Escenarios de error

Si se producen errores durante la preparación de los datos o al finalizar, la aplicación lo notifica a través del Future devuelto proporcionándolo con un código de error UDS (DiagUdsNrcErrc según ISO 14229-1) ([SWS_DM_01513], [SWS_DM_01514]). A continuación, AraDiag genera la respuesta negativa de UDS (NRC) correspondiente hacia el tester.

Para la cancelación anticipada se transfiere a ambos métodos un CancellationHandler ([SWS_DM_01513], [SWS_DM_01514]). La aplicación puede comprobar mediante cancellation_handler.IsCanceled() si la conversación se ha cancelado o registrar una función de devolución de llamada a través de cancellation_handler.SetNotifier(). Los búferes proporcionados (response_data y transfer_request_parameter_record) permanecen válidos hasta el cumplimiento del promise o hasta la cancelación a través del manejador.

Si la instancia se destruye antes de la invocación de ExitRead(), se produce una infracción del requisito de la especificación ([SWS_DM_01510]), lo que puede dar lugar a sesiones de transferencia incompletas y a estados indefinidos del sistema.