clase apext::diag::uds_transport::UdsTransportProtocolMgr

usar

El método ChannelReestablished de la clase apext::diag::uds_transport::UdsTransportProtocolMgr sirve como notificación de respuesta de una implementación del protocolo de transporte UDS al Diagnostic Management (DM) de que un canal de comunicación vuelve a estar disponible tras un (re)inicio [SWS_DM_00313]. La implementación del protocolo de transporte llama a este método exactamente una vez tan pronto como se detecta la nueva disponibilidad del canal de red representado por ChannelID [SWS_DM_00358]. Como parámetro se transfiere globalChannelId, que consta de la tupla formada por el propio handlerIdent y el ChannelID [SWS_DM_00358].

Zusammenspiel y ciclo de vida

El requisito para la notificación es una llamada previa a NotifyReestablishment [SWS_DM_00313], [SWS_DM_00356]. El caso de uso típico es la ejecución de un reinicio de ECU (servicio UDS 0x11) con la opción de una respuesta positiva tras el reinicio [SWS_DM_00326]. Para garantizar la notificación incluso tras un reinicio del DM, el protocolo de transporte debe guardar de forma persistente la solicitud de notificación [SWS_DM_00359].

Tratamiento de errores y concurrencia

La función no posee valor de retorno y está especificada como noexcept (exception safe) [SWS_DM_00313]. Dado que la interfaz está clasificada como no segura para subprocesos (not thread-safe) [SWS_DM_00313], es probable que los manejadores llamadores deban sincronizar el acceso de forma externa. Pregunta Q-aaf14893457cceb6 (abierta) Como restricción temporal, se aplica que el DM solo puede procesar la llamada a ChannelReestablished tras la llamada a UdsTransportProtocolHandler::Start [SWS_DM_01744].

El método HandleMessage sirve para transferir un mensaje de solicitud UDS válido y completamente recibido desde la capa de transporte a la capa de sesión del Diagnostic Management ([SWS_DM_00311]). Esto corresponde al servicio T_Data.ind según la norma ISO 14229-2 ([SWS_DM_00311], AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.2 «HandleMessage»).

Invocación y parámetros

Tan pronto como la implementación del protocolo de transporte ha llenado la carga útil del búfer solicitado previamente mediante IndicateMessage ([SWS_DM_00388]), invoca HandleMessage en la instancia de apext::diag::uds_transport::UdsTransportProtocolMgr ([SWS_DM_00345]). Como argumento se pasa message de tipo UdsMessagePtr. Mediante la semántica de std::unique_ptr, la propiedad del mensaje UDS vuelve al núcleo genérico de DM ([SWS_DM_00311]). La función no proporciona ningún valor de retorno.

Semántica, concurrencia y tratamiento de errores

• Asincronía: la llamada debe retornar de inmediato («instantly returns») ([SWS_DM_00311]). Interpretación: es de prever que el procesamiento propiamente dicho de la solicitud de diagnóstico continúe de forma asíncrona en el núcleo de DM dentro de un contexto de ejecución independiente. Pregunta Q-b8dd1a5f3d2dcdf0 (abierta)
• Caso de error: el método está declarado como noexcept y es seguro frente a excepciones ([SWS_DM_00311]). Si la recepción o el llenado del mensaje fallan, no debe realizarse ninguna llamada a HandleMessage; en su lugar, el error debe notificarse mediante NotifyMessageFailure ([SWS_DM_00310]).
• Seguridad para subprocesos: la operación está especificada como not thread-safe ([SWS_DM_00311]). Los emisores de la llamada deben sincronizar los accesos paralelos a la misma instancia.

Interacción

La interfaz pertenece a la capa del protocolo de transporte y debe distinguirse del método de procesamiento de servicios del lado de la aplicación ara::diag::GenericUDSService::HandleMessage ([SWS_DM_00618]).

El método de retrollamada virtual puro HandlerStopped de la interfaz de gestión apext::diag::uds_transport::UdsTransportProtocolMgr sirve como notificación de un plugin de transporte UDS al Diagnostic Manager (DM) de que su ejecución ha finalizado y todos los recursos y conexiones de red asociados se han liberado por completo [SWS_DM_00314]. Se espera esta llamada como reacción obligatoria del manejador a una llamada previa de UdsTransportProtocolHandler::Stop() [SWS_DM_00314], [SWS_DM_00323].

Contexto de llamada y parámetros: El plugin afectado se identifica durante la llamada a través del parámetro de entrada handlerId del tipo UdsTransportProtocolHandlerID [SWS_DM_00314]. El método no tiene valor de retorno (void) y garantiza una total seguridad contra excepciones (exception safe) gracias a su especificación como noexcept [SWS_DM_00314]. Para esta interfaz no se definen códigos de error específicos, reacciones ante fallos ni notificaciones a DET o DEM.

Flujo y restricciones: Si el Diagnostic Manager cambia al estado ApplicationState.kTerminating durante el apagado, primero llama a Stop() en cada implementación del protocolo de transporte UDS iniciada [SWS_DM_00333]. Tras el retorno de Stop(), rige una prohibición estricta de llamada: el plugin manejador ya no puede invocar ningún otro método hacia UdsTransportProtocolMgr, a excepción de HandlerStopped [SWS_DM_01741], [SWS_DM_00323]. Antes de la finalización definitiva del proceso del DM, este espera la llegada de la retrollamada HandlerStopped correspondiente con el handlerId adecuado [SWS_DM_00340]. La interfaz se indica como no segura para subprocesos (not thread-safe) [SWS_DM_00314]. Interpretación: Dado que el DM espera la llegada de la retrollamada por separado, es probable que la finalización efectiva de las conexiones de red en el plugin se ejecute de forma asíncrona respecto al retorno del método Stop(). Pregunta Q-40829d46bd661337 (abierta)

El método IndicateMessage [SWS_DM_00309] de la clase apext::diag::uds_transport::UdsTransportProtocolMgr es llamado de forma síncrona por un UdsTransportProtocolHandler cuando se debe señalizar el inicio de la recepción de un mensaje UDS y el manejador lo admite. El llamador transmite la dirección de origen y destino (sourceAddr, targetAddr), el tipo de direccionamiento type (físico o funcional), el ID de canal globalChannelId, el tamaño total previsto size, así como, opcionalmente, una vista de bytes de los datos útiles ya recibidos (payloadInfo). Se recomienda proporcionar al menos dos bytes en payloadInfo para que el Diagnostic Management Core pueda reconocer solicitudes funcionales como Tester-Present (lógica de bypass) incluso durante el procesamiento en curso AUTOSAR_AP_SWS_Diagnostics §7.1 «UDS Transport Layer».

Como valor de retorno, la llamada síncrona y segura contra excepciones devuelve un std::pair compuesto por IndicationResult [SWS_DM_00384] y un UdsMessagePtr [SWS_DM_00309]:

• Aceptación: Si el mensaje se puede procesar, el DM Core devuelve IndicationResult::kIndicationOk junto con un UdsMessagePtr válido cuya capacidad mínima es de al menos un byte [SWS_DM_00385].
• Rechazo y casos de error: Si el DM está ocupado, responde con kIndicationOccupied y nullptr [SWS_DM_00386]. En caso de una dirección de destino no válida, se devuelve kIndicationUnknownTargetAddress con un puntero nulo. Otros valores de estado definidos son kIndicationOverflow [SWS_DM_00384].

En cuanto a concurrencia y tiempo de vida, el método está especificado como no seguro para subprocesos (not thread-safe) [SWS_DM_00309]; por lo tanto, las llamadas deben realizarse sincronizadas en consecuencia. La vista transmitida a través de payloadInfo es efímera y solo debe utilizarse dentro de esta llamada a función [SWS_DM_00309].

En el curso posterior, al devolver kIndicationOk, la capa de transporte llena el búfer proporcionado a través de GetPayload [SWS_DM_00301] hasta el límite de capacidad o la longitud completa del mensaje [SWS_DM_00388]. Tras el llenado correcto, se llama a HandleMessage [SWS_DM_00345]. Si la recepción del mensaje falla prematuramente, el manejador debe devolver el búfer al DM a través de NotifyMessageFailure [SWS_DM_00310].

usar

El método virtual puro NotifyMessageFailure se proporciona a través del encabezado apext/diag/uds_transport/protocol_mgr.h en la interfaz apext::diag::uds_transport::UdsTransportProtocolMgr [SWS_DM_00310]. Sirve para que la implementación del protocolo de transporte indique al Diagnostic Management que un mensaje señalado previamente a través de IndicateMessage() ha fallado y que ya no se producirá ninguna llamada final a HandleMessage() [SWS_DM_00345] [SWS_DM_00310]. Como parámetro se transfiere el puntero message de tipo UdsMessagePtr, devolviéndose con ello el mensaje afectado a la capa de sesión [SWS_DM_00310]. No existe valor de retorno (void).

Tratamiento de errores y concurrencia

La función está declarada como noexcept y segura frente a excepciones [SWS_DM_00310]. No lanza excepciones y notifica las interrupciones de transmisión puramente a través de la interfaz de parámetros. En lo que respecta a la concurrencia, el método está clasificado como no seguro para subprocesos (not thread-safe) [SWS_DM_00310]. Interpretación: es probable que los llamadores deban garantizar una sincronización externa en caso de procesamiento paralelo a nivel de protocolo de transporte. Pregunta Q-8d9b3a3561b9b6ac (abierta)

Interacción y secuencia

En el flujo normal, tras un IndicateMessage() correcto, el protocolo de transporte llena la carga útil del UdsMessage [SWS_DM_00388] y la reenvía a través de HandleMessage() al Diagnostic Management [SWS_DM_00345]. Sin embargo, si la transmisión falla (por ejemplo, en caso de errores durante la recepción de una solicitud multitrama), se llama en su lugar a NotifyMessageFailure [SWS_DM_00310]. Esto evita llamadas de procesamiento posteriores e influye en la gestión de sesiones: mientras que el temporizador S3Server se detiene al inicio de la recepción [SWS_DM_00383], un error de recepción de un mensaje multitrama hace que el temporizador S3Server se reinicie y comience a contar nuevamente desde el principio (SWS Diagnostics §7.3.2.7 «Session handling» / [SWS_DM_00310]).

usar

El método virtual puro PeriodicTransmitConfirmation es parte de la clase apext::diag::uds_transport::UdsTransportProtocolMgr y se declara mediante el archivo de cabecera apext/diag/uds_transport/protocol_mgr.h [SWS_DM_01069]. Sirve para confirmar mensajes de diagnóstico periódicos enviados así como para transmitir la cantidad de mensajes enviados correctamente AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.6 «PeriodicTransmitConfirmation».

En la llamada se transfieren dos parámetros de entrada, mientras que el método no devuelve ningún valor de retorno:

• messages (ara::core::Vector<UdsMessageConstPtr>): La misma lista ordenada de mensajes que fue transferida previamente al método UdsTransportProtocolPeriodicHandler::PeriodicTransmit() [SWS_DM_01069].
• numberOfSentMessages (std::size_t): La cantidad de mensajes transferidos correctamente de la lista messages [SWS_DM_01069].

Tratamiento de errores y seguridad frente a excepciones

Respecto a la seguridad frente a excepciones, la interfaz está especificada como exception safe y provista del identificador noexcept [SWS_DM_01069]. Por lo tanto, no lanza excepciones C++. En la especificación no se definen códigos de error específicos ni mensajes de error a través de DET o DEM para esta función de confirmación.

Concurrencia y condiciones de contorno

Según la especificación, la función está clasificada como no segura frente a hilos (not thread-safe) [SWS_DM_01069]. Por lo tanto, las llamadas concurrentes en la misma instancia no están protegidas y deben ser coordinadas por la entidad llamante.

Interacción

La función enlaza directamente con el flujo de envío periódico: recibe la confirmación sobre los mensajes efectivamente enviados tras una llamada a UdsTransportProtocolPeriodicHandler::PeriodicTransmit() AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.6 «PeriodicTransmitConfirmation». A nivel de requisitos, la función está asignada al requisito aguas arriba RS_Diag_04215 [SWS_DM_01069].

usar

El método virtual puro TransmitConfirmation de la interfaz apext::diag::uds_transport::UdsTransportProtocolMgr sirve para notificar al Diagnostic Management (DM) la finalización de una orden de envío iniciada previamente por el DM mediante UdsTransportProtocolHandler::Transmit [SWS_DM_00312] [SWS_DM_00348]. La función implementa el servicio primitivo T_Data.con conforme a la norma ISO 14229-2 [SWS_DM_00312].

En la llamada se pasan dos parámetros [SWS_DM_00312]:

• message (UdsMessageConstPtr): puntero al mensaje UDS que se proporcionó previamente en IndicateMessage() y cuya transmisión se acusa [SWS_DM_00312].
• result (TransmissionResult): indica el resultado de la transmisión. Si la capa de red pudo emitir con éxito la respuesta UDS a la red, el valor debe establecerse en kTransmitOk; de lo contrario, en kTransmitFailed [SWS_DM_00351] SWS Diagnostics §7.1.1.3 «Confirmation Result».

El método no tiene valor de retorno (void) y está declarado como noexcept, por lo que debe ejecutarse de forma segura frente a excepciones [SWS_DM_00312].

Concurrencia y comportamiento del sistema

La interfaz está especificada explícitamente como no segura para subprocesos [SWS_DM_00312]. Por tanto, es de prever que las llamadas desde contextos concurrentes de red o de manejadores requieran una sincronización externa por parte de la implementación del protocolo de transporte. Pregunta Q-e540ca89c3f61ecb (abierta)

Asimismo, la llamada influye en la gestión de la autenticación: si un cliente se encuentra en la sesión estándar y en el estado kAuthenticated, el Diagnostic Server lo cambia al estado kDeAuthenticated si no se recibe ninguna nueva solicitud tras el último TransmitConfirmation durante un tiempo de authenticationTimeout [SWS_DM_01210].