clase ara::diag::ServiceValidation

El método Confirmation de la interfaz ara::diag::ServiceValidation ([SWS_DM_00775], declarado en ara/diag/service_validation.h) sirve como notificación sobre la finalización y el resultado de una petición de diagnóstico procesada previamente.

Uso y semántica

La función de retrollamada virtual es llamada de forma síncrona por el Diagnostic Management tan pronto como finaliza el procesamiento de la solicitud. No posee valor de retorno (void) y acepta dos parámetros de entrada ([SWS_DM_00775]):

• status (ConfirmationStatusType): Señaliza el estado final o el resultado del procesamiento del servicio ([SWS_DM_00775]).
• metaInfo (const Meta Info &): Contiene la metainformación asociada de la petición de diagnóstico ([SWS_DM_00775]).

Tratamiento de errores y concurrencia

La función está especificada como segura frente a excepciones (exception safe) y declarada con el identificador noexcept ([SWS_DM_00775]). Por lo tanto, las sobrescrituras del lado de la aplicación no deben propagar excepciones hacia el exterior. No hay definidos códigos de error específicos como avisos de DET o DEM para este método. En cuanto a la concurrencia, Confirmation está clasificado como no seguro para hilos (not thread-safe) ([SWS_DM_00775]); el acceso a estados internos de la aplicación dentro de la retrollamada requiere una sincronización adecuada en caso de secuencias paralelas.

Interacción

El disparo de la notificación está vinculado al final del ciclo de vida de una petición de diagnóstico ([SWS_DM_00775]). Este ciclo concluye tan pronto como se haya transmitido o suprimido una respuesta positiva o negativa (AUTOSAR_AP_SWS_Diagnostics §7.3.2.1.2 «Life-cycle of a Diagnostic Conversation»). Interpretación: A nivel de módulo, es probable que el Diagnostic Management no lance la retrollamada Confirmation hasta que la transmisión a través de la capa de transporte se haya confirmado mediante TransmitConfirmation y el resultado kTransmitOk o kTransmitFailed ([SWS_DM_00307], [SWS_DM_00351]). Pregunta Q-97c38586ef5e3704 (abierta)

usar

La función miembro Offer de la clase ara::diag::ServiceValidation (cabecera ara/diag/service_validation.h) activa el reenvío de peticiones de diagnóstico entrantes por parte del Diagnostic Manager (DM) a este manejador de validación específico [SWS_DM_00776]. La llamada se realiza de forma síncrona y sin parámetros de transferencia a través de la firma ara::core::Result<void> Offer() noexcept; [SWS_DM_00776]. Como valor de retorno sirve un ara::core::Result<void>, que está vacío en caso de éxito o encapsula el código de error producido en caso de fallo [SWS_DM_00776].

Manejo de errores

Si el registro falla, el método devuelve un Result erróneo. Si el servicio para la instancia en cuestión ya se había ofrecido previamente, se devuelve el código de error DiagOfferErrc::kAlreadyOffered [SWS_DM_00776]. En este caso se aplica una semántica de reversión, de modo que el estado anterior de la instancia permanece inalterado [SWS_DM_00776].

Concurrencia y restricciones

La función está especificada como segura frente a excepciones (exception safe), pero expresamente como no segura para subprocesos (not thread-safe) [SWS_DM_00776]. Los accesos paralelos a la misma instancia deben ser coordinados por la aplicación invocadora. En cuanto al orden, debe llamarse a Offer antes de que el Diagnostic Manager pueda reenviar peticiones de servicio para su validación [SWS_DM_00776].

Interacción

Ofrecer interfaces a través de Offer es un patrón de diseño consistente del diagnóstico de AUTOSAR Adaptive y se emplea de forma análoga, entre otros, en rutinas ([SWS_DM_00557], [SWS_DM_00594]), servicios UDS genéricos ([SWS_DM_00619]), funciones DoIP ([SWS_DM_00725], [SWS_DM_00735]), así como accesos de seguridad ([SWS_DM_00766]). Mientras una interfaz no se haya puesto a disposición mediante Offer, el DM descarta peticiones o recurre a valores sustitutivos definidos ([SWS_DM_01525], [SWS_DM_01527]). Los paralelismos conceptuales con ara::com están motivados funcionalmente, pero representan una implementación independiente del diagnóstico (AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 «Monitors»).

usar

El método StopOffer() de la clase ara::diag::ServiceValidation (archivo de cabecera ara/diag/service_validation.h) sirve para desactivar el reenvío de mensajes entrantes de petición de Diagnostic Management (DM) a la instancia de validación de servicio [SWS_DM_00777]. La llamada se realiza de forma síncrona, no acepta parámetros de entrada y no proporciona ningún valor de retorno [SWS_DM_00777].

Tratamiento de errores y concurrencia

La función está declarada como noexcept y se considera segura ante excepciones (exception safe), de modo que no se producen excepciones de C++ durante su ejecución [SWS_DM_00777]. Para esta llamada no se han definido códigos de error específicos ni avisos de retorno a la gestión de errores [SWS_DM_00777].

En cuanto a la concurrencia, el método está especificado como no seguro frente a hilos (not thread-safe) [SWS_DM_00777]. Interpretación: La aplicación llamante debe asegurarse de que las llamadas concurrentes en la misma instancia de StopOffer() estén sincronizadas para evitar inconsistencias de datos. Pregunta Q-dde3c015d30a9db1 (abierta)

Interacción

La puesta a disposición y retirada de interfaces mediante Offer() y StopOffer() se orienta según la semántica conocida de ara::com, pero en el ámbito del diagnóstico representa una funcionalidad independiente AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 «Monitors». El patrón para desactivar el reenvío de peticiones desde el DM se utiliza de manera coherente en el estándar para otros manejadores de diagnóstico, como por ejemplo para servicios de autenticación [SWS_DM_01131], control de comunicación [SWS_DM_00810], servicios de descarga [SWS_DM_00793], así como peticiones de reset de la ECU [SWS_DM_01017].

usar

El método virtual ara::diag::ServiceValidation::Validate se llama para cada mensaje entrante de petición de diagnóstico [SWS_DM_00774]. A través de él, el Diagnostic Server (DM) ejecuta comprobaciones de servicio configuradas específicas del fabricante [SWS_DM_01252], así como específicas del proveedor [SWS_DM_01253] según ISO 14229-1. La asignación como comprobación de fabricante o de proveedor se rige por el modelado en el constructor [SWS_DM_00772].

La función acepta los datos de diagnóstico, incluido el Service Identifier (SID), a través de requestData, así como metainformación a través de metaInfo [SWS_DM_00774]. El búfer requestData sigue siendo válido hasta que el ara::core::Future<void> devuelto se cumpla a través de la promesa asociada o se cancele la ejecución [SWS_DM_00774]. Si la validación concluye con éxito sin errores, el Diagnostic Server continúa con el procesamiento de la petición según ISO 14229-1 [SWS_DM_01254].

Tratamiento de errores y condiciones límite

Si la comprobación falla, debe devolverse un NRC adecuado según ISO 14229-1 mediante DiagUdsNrcErrc [SWS_DM_00774]. Si Validate devuelve el error kNoProcessingNoResponse, la instancia del Diagnostic Server descarta el mensaje sin ninguna otra respuesta [SWS_DM_00860].

En cuanto a la concurrencia, Validate está especificado como seguro ante excepciones (exception safe), pero no seguro frente a hilos (not thread-safe) [SWS_DM_00774]. Interpretación: Dado que la función no es segura frente a hilos, es de esperar que el Diagnostic Server serialice las llamadas a la misma instancia o excluya accesos concurrentes. Pregunta Q-e150c15ad709602c (abierta) El contexto de llamada queda establecido por la secuencia de NRC de la norma ISO 14229-1 antes de la ejecución propiamente dicha del servicio [SWS_DM_00772].