estructura ara::diag::GenericUDSService::OperationOutput

La estructura ara::diag::GenericUDSService::OperationOutput sirve en el módulo diag como estructura de salida para los datos útiles de mensajes de respuesta UDS positivos [SWS_DM_00632]. Una aplicación completa la variable de bytes responseData tras la ejecución satisfactoria de un servicio UDS genérico y transfiere la instancia al Diagnostic Management. En este sentido, el identificador de servicio (SID) de UDS no debe estar contenido en responseData, ya que la plataforma lo añade automáticamente [SWS_DM_00632]. La estructura no está prevista para escenarios de error ni para respuestas negativas.

más ›

Contexto

La estructura de datos ara::diag::GenericUDSService::OperationOutput sirve dentro de la AUTOSAR Adaptive Platform en el módulo diag como canal de salida estandarizado para servicios UDS genéricos [SWS_DM_00632]. Está definida en el archivo de cabecera #include "ara/diag/generic_uds_service.h" y actúa como encapsulación para los datos útiles de una ejecución satisfactoria del servicio UDS [SWS_DM_00632]. Los interlocutores principales son la implementación específica de la aplicación del manejador de servicio UDS genérico, así como el Diagnostic Management de nivel superior de la plataforma AUTOSAR_AP_SWS_Diagnostics p. 80. Mientras que el Diagnostic Management asume la coordinación con el comprobador de diagnóstico externo, la validación del protocolo y el framework, OperationOutput proporciona la carga útil aislada para el mensaje de respuesta UDS positivo [SWS_DM_00632].

Ciclo de vida

Las instancias de ara::diag::GenericUDSService::OperationOutput presentan un ciclo de vida fuertemente enfocado y de corta duración. La estructura es instanciada por la aplicación de servicio en el contexto local de una solicitud UDS entrante. A través de la única variable miembro pública responseData de tipo ara::core::Vector<std::uint8_t>, la estructura asume la propiedad completa de los bytes de datos útiles [SWS_DM_00632].

Interpretación: La vida útil de OperationOutput es efímera y está vinculada a la duración del procesamiento de la solicitud respectiva; es previsible que la instancia se transfiera al Diagnostic Management tras completarse mediante valor de retorno o semántica de movimiento, y que se destruya de nuevo tras la serialización en la trama de respuesta UDS. Pregunta Q-c736182a9518978a (abierta) Dado que se trata de un mero objeto de transferencia de datos (DTO) sin lógica de estado interna, no existen transiciones de estado. En cuanto a la concurrencia, OperationOutput no ofrece seguridad de hilos inherente; no obstante, dado que la instanciación y el llenado se realizan de forma aislada por solicitud dentro del contexto de procesamiento, no se requiere sincronización externa en una aplicación de servicio normal.

Ruta de uso

El flujo habitual durante el procesamiento de una solicitud de diagnóstico se divide en los siguientes pasos:

• Recepción: El Diagnostic Management recibe una solicitud UDS de un comprobador de diagnóstico externo y la reenvía a la instancia correspondiente de GenericUDSService AUTOSAR_AP_SWS_Diagnostics p. 81.
• Ejecución del servicio: La aplicación interpreta los parámetros recibidos y ejecuta la función de diagnóstico interna.
• Provisión del resultado: En caso de procesamiento satisfactorio, la aplicación instancia un objeto del tipo OperationOutput y asigna los datos útiles de la respuesta al campo responseData [SWS_DM_00632]. A este respecto, la especificación prescribe de forma vinculante que responseData debe contener exclusivamente los bytes de datos sin el identificador de servicio (SID) [SWS_DM_00632].
• Transferencia: La aplicación transfiere OperationOutput al Diagnostic Management. Interpretación: La transferencia se realiza típicamente como valor de retorno síncrono o incrustada en un valor futuro asíncrono como ara::core::Future. Pregunta Q-2dcf40060cca29a1 (abierta)
• Envío del mensaje: El Diagnostic Management antepone automáticamente el SID positivo, completa el telegrama UDS y transmite la respuesta al comprobador de diagnóstico.

Diagrama de secuencia: Flujo de la generación de respuestas UDS y transferencia mediante OperationOutput. Fuentes: [SWS_DM_00632], AUTOSAR_AP_SWS_Diagnostics p. 81

Escenarios de error

Al utilizar la estructura, deben observarse condiciones límite esenciales y patrones de comportamiento en caso de error:

• Exclusión de respuestas negativas: Según la especificación, OperationOutput representa explícita y exclusivamente el contenido de mensajes de respuesta positivos [SWS_DM_00632]. Interpretación: Si una solicitud de servicio no puede procesarse satisfactoriamente (p. ej., como consecuencia de parámetros no permitidos o condiciones previas no válidas), es previsible que no se genere ningún OperationOutput; en su lugar, la aplicación señaliza un Negative Response Code (NRC) al Diagnostic Management. Pregunta Q-09abb9092c1dc167 (abierta)
• Inclusión errónea del SID: Si el identificador de servicio se inserta erróneamente en responseData, se genera un telegrama UDS con formato incorrecto, ya que el Diagnostic Management antepone de forma autónoma el SID en las respuestas positivas [SWS_DM_00632].
• Asignación de memoria: Dado que responseData está declarado como un vector dinámico (ara::core::Vector), deben tenerse en cuenta posibles cuellos de botella de memoria al asignar cantidades muy grandes de datos útiles [SWS_DM_00632].