estructura ara::diag::UploadService::OperationOutput

La estructura ara::diag::UploadService::OperationOutput sirve como parámetro de salida para devolver datos útiles de una respuesta de diagnóstico positiva en servicios de subida [SWS_DM_00796]. El software de aplicación instancia el objeto tras la realización satisfactoria de una operación de subida y completa el miembro responseData con los bytes de datos que se van a enviar [SWS_DM_00796]. En este caso, el contenido de responseData no debe contener ningún Service Identifier (SID) y debe cumplir los requisitos específicos de la operación de servicios como UploadData o RequestUploadExit. Interpretación: En caso de error no se utiliza la estructura, sino que se señaliza un estado de respuesta negativo. Pregunta Q-52a8538825bc0a30 (abierta)

más ›

Contexto

La estructura ara::diag::UploadService::OperationOutput actúa como contenedor de datos para los datos útiles de una operación de diagnóstico satisfactoria en el marco del servicio de subida del vehículo [SWS_DM_00796]. Su responsabilidad primordial consiste en encapsular los datos para un mensaje de respuesta positivo («positive response message») y reenviarlos a la plataforma [SWS_DM_00796].

En el sistema global interactúan en este sentido tres componentes: el cliente de diagnóstico externo (comprobador), el entorno de ejecución de diagnóstico del sistema Adaptive (ara::diag) y la implementación específica de la aplicación de UploadService [SWS_DM_00796]. Tan pronto como el comprobador solicita una operación de servicio UDS, ara::diag delega el procesamiento al proveedor de servicios competente de la aplicación, que devuelve el resultado a la capa de plataforma a través de OperationOutput [SWS_DM_00796].

Diagrama de contexto: Interacción entre el cliente de diagnóstico, el entorno de ejecución ara::diag y UploadService en la provisión de datos de respuesta. Fuentes: [SWS_DM_00796], AUTOSAR_AP_SWS_Diagnostics, p. 74.

Ciclo de vida

La estructura OperationOutput está concebida como un mero objeto de transferencia de datos sin lógica de estado propia y se proporciona a través de la cabecera #include "ara/diag/upload.h" [SWS_DM_00796]. Su ciclo de vida se divide en las siguientes fases:

• Creación: La instanciación tiene lugar en la aplicación dentro de la operación de diagnóstico en ejecución tan pronto como los datos de subida solicitados se hayan recopilado satisfactoriamente. Interpretación: Es previsible que el objeto se cree localmente en la pila de la aplicación de servicio. Pregunta (abierta)
• Llenado: La lógica de la aplicación asigna al miembro público responseData de tipo ara::core::Vector<std::uint8_t> los datos útiles que se deben suministrar [SWS_DM_00796].
• Transferencia de propiedad: El objeto se transfiere a ara::diag como resultado de la operación. Interpretación: Es previsible que esta transferencia se realice por valor o con semántica de movimiento, con lo que la responsabilidad de los datos pasa a la plataforma. Pregunta (abierta)
• Destrucción: Tras la serialización de los datos útiles en el mensaje de respuesta UDS, el entorno de ejecución libera la estructura.

En cuanto a la concurrencia, OperationOutput no ofrece sincronización interna. No obstante, dado que las instancias se crean de forma dedicada por llamada a operación y se procesan localmente en el hilo de ejecución, no se requiere una gestión de estado compartida.

Ruta de uso

El flujo habitual para la provisión de datos de respuesta mediante OperationOutput comprende una secuencia fija de pasos de interacción:

1. Un comprobador externo envía una solicitud de subida (como UploadData o RequestUploadExit) a la unidad de control [SWS_DM_00796].
2. La gestión de diagnóstico ara::diag procesa la cabecera del protocolo y llama a la operación correspondiente de la instancia de aplicación de UploadService [SWS_DM_00796].
3. La aplicación procesa la solicitud, crea una instancia de OperationOutput y completa responseData con los datos útiles [SWS_DM_00796]. En este sentido, responseData debe contener exclusivamente los datos útiles sin el Service Identifier (SID) [SWS_DM_00796]. En función de la operación, varían el contenido requerido, así como la posición inicial de los datos en el mensaje de respuesta positivo [SWS_DM_00796].
4. La estructura se devuelve a ara::diag.
5. La capa de plataforma genera el mensaje de respuesta UDS completo y lo transmite al comprobador [SWS_DM_00796].

Diagrama de secuencia: Secuencia de llamadas para el retorno de datos de diagnóstico mediante OperationOutput. Fuentes: [SWS_DM_00796], AUTOSAR_AP_SWS_Diagnostics, p. 74.

Escenarios de error

La estructura OperationOutput está especificada exclusivamente para ejecuciones satisfactorias y mensajes de respuesta positivos [SWS_DM_00796]. Si una operación falla (por ejemplo, debido a rangos de direcciones no válidos o errores de secuencia en UploadData), OperationOutput no se utiliza. Interpretación: Los flujos erróneos se notifican previsiblemente a ara::diag mediante códigos de error de diagnóstico independientes (NRC), por lo que se prescinde de crear o rellenar la estructura de salida. Pregunta Q-fa3daf3152f7131c (abierta)

Como condición previa para el retorno, se aplica que responseData comprende exactamente los bytes requeridos por la operación de servicio respectiva y no contiene identificadores de protocolo antepuestos [SWS_DM_00796]. Como poscondición, la gestión de diagnóstico asume los datos para la finalización de la comunicación por bus [SWS_DM_00796].