namespace apext::diag::uds_transport

El espacio de nombres apext::diag::uds_transport proporciona la interfaz de transporte en C++ para desacoplar la gestión genérica de diagnóstico de los protocolos de transporte UDS específicos AUTOSAR_AP_SWS_Diagnostics §7.1 «UDS Transport Layer». Los complementos de protocolo se derivan de la clase base UdsTransportProtocolHandler y pasan por un ciclo de vida estricto compuesto por construcción, inicialización, inicio y detención ordenada [SWS_DM_00329]. Los mensajes entrantes se notifican mediante IndicateMessage y, si hay capacidad disponible, reciben un UdsMessagePtr con memoria administrada para asumir los datos útiles. Una condición marginal fundamental es que, tras la detención, no deben realizarse más llamadas a la gestión de diagnóstico con excepción del mensaje de confirmación.

más ›

Contexto

El espacio de nombres apext::diag::uds_transport define la interfaz de transporte estandarizada en C++ (Transport Protocol API) para la gestión de diagnóstico (DM) en la AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_Diagnostics §7.1 «UDS Transport Layer». La arquitectura separa funcionalmente el núcleo genérico de la gestión de diagnóstico de las capas de transporte y de red concretas. De este modo, se pueden integrar como complementos modulares protocolos estandarizados como DoIP, así como protocolos de transporte futuros o específicos del fabricante (por ejemplo, para CAN, CAN-FD o FlexRay) AUTOSAR_AP_SWS_Diagnostics §7.1 «UDS Transport Layer».

La instancia mediadora central la constituye la clase UdsTransportProtocolMgr, que coordina la interacción entre las instancias del Diagnostic Server y los protocolos de transporte conectados. Los complementos de protocolo concretos se derivan de la clase base abstracta UdsTransportProtocolHandler AUTOSAR_AP_SWS_Diagnostics §7.1.1 «Support of UDS Transport Layer» [SWS_DM_00315]. Las instancias individuales de los gestores se direccionan mediante UdsTransportProtocolHandlerID [SWS_DM_00336], mientras que los canales de comunicación se identifican mediante el tipo ChannelID [SWS_DM_00337]. Para admitir consultas periódicas de datos según el servicio ISO 0x2A, la interfaz incorpora adicionalmente la clase UdsTransportProtocolPeriodicHandler.

Ciclo de vida

La gestión de diagnóstico controla el ciclo de vida de cada instancia de UdsTransportProtocolHandler en un orden estrictamente predeterminado [SWS_DM_00329]:

1. Creación: El DM instancia el complemento de protocolo a través del constructor UdsTransportProtocolHandler::UdsTransportProtocolHandler [SWS_DM_00329].
2. Inicialización: El DM invoca UdsTransportProtocolHandler::Initialize [SWS_DM_00329]. A excepción de la consulta de GetPeriodicHandler, el DM no debe invocar ningún otro método en el gestor antes del retorno exitoso de kInitializeOk [SWS_DM_01746].
3. Inicio y funcionamiento: Tras una inicialización correcta, el gestor se activa con UdsTransportProtocolHandler::Start. Solo después de esta llamada el DM procesa notificaciones sobre canales reactivados mediante UdsTransportProtocolMgr::ChannelReestablished [SWS_DM_01744].
4. Terminación: Si el DM pasa al estado ApplicationState.kTerminating, invoca UdsTransportProtocolHandler::Stop para todos los complementos activos [SWS_DM_00333]. Tras el retorno de esta llamada, el complemento solo debe invocar UdsTransportProtocolMgr::HandlerStopped [SWS_DM_01741]. El DM espera activamente esta confirmación [SWS_DM_00340].

Diagrama de estados: Fases del ciclo de vida y condiciones de transición de una implementación del gestor de protocolos de transporte. Fuentes: [SWS_DM_00329], [SWS_DM_00333], [SWS_DM_00340], [SWS_DM_01741], [SWS_DM_01744], [SWS_DM_01745], [SWS_DM_01746]

Ruta de uso

Durante el funcionamiento continuo, el reenvío de mensajes de diagnóstico entrantes se lleva a cabo mediante una interacción coordinada entre el gestor y el administrador:

1. Indicación de mensaje: Si el gestor recibe datos en un canal (ChannelID [SWS_DM_00337]), invoca UdsTransportProtocolMgr::IndicateMessage. Al hacerlo, puede transferir datos útiles preliminares en payloadInfo; se recomiendan al menos los dos primeros bytes para una detección temprana de solicitudes funcionales AUTOSAR_AP_SWS_Diagnostics §7.1 «UDS Transport Layer».
2. Asignación de búfer: Si el DM está listo para la recepción, IndicateMessage responde con un std::pair compuesto por IndicationResult::kIndicationOk y un puntero inteligente válido UdsMessagePtr [SWS_DM_00309] [SWS_DM_00385]. El objeto UdsMessage referenciado posee una capacidad mínima de un byte [SWS_DM_00385]. El búfer se administra como std::unique_ptr con un eliminador específico del núcleo del DM y no es seguro para subprocesos [SWS_DM_00303]. Para accesos de lectura existe el equivalente constante UdsMessageConstPtr [SWS_DM_00304].
3. Transferencia de datos: El gestor escribe los datos de diagnóstico recibidos en el búfer proporcionado, cuya secuencia de bytes está tipada mediante el tipo ByteSpan (alias para ara::core::Span<ara::core::Byte> [SWS_DM_00338]). Presumiblemente, la provisión de la clase separada UdsTransportProtocolPeriodicHandler a través de GetPeriodicHandler sirve para desacoplar el servicio de transmisión periódica 0x2A de la ruta habitual de mensajes UDS. Pregunta Q-230ef0b7c384c594 (abierta)

Diagrama de secuencia: Flujo de indicación de mensaje y asignación de búfer entre el gestor, el administrador y el núcleo del DM. Fuentes: AUTOSAR_AP_SWS_Diagnostics §7.1 «UDS Transport Layer», [SWS_DM_00303], [SWS_DM_00309], [SWS_DM_00385], [SWS_DM_00386]

Escenarios de error

La especificación define estados de error y condiciones previas concretos para la conexión de transporte:

• Inicialización fallida: Si UdsTransportProtocolHandler::Initialize devuelve el resultado kInitializeFailed, el DM cancela inmediatamente el proceso de inicialización para este gestor y no invoca más métodos en él [SWS_DM_01745].
• Rechazo por núcleo de diagnóstico ocupado: Si el DM está bloqueado debido al procesamiento en curso de un servicio de la misma conversación Tester-Present y no se trata de un Tester-Present funcional con payloadInfo 0x3E 0x80, IndicateMessage devuelve el resultado kIndicationOccupied junto con un nullptr en lugar de un búfer de mensajes [SWS_DM_00386].
• Llamadas no permitidas tras la terminación: Si un complemento invoca un método de UdsTransportProtocolMgr distinto de HandlerStopped tras el retorno de Stop, esto infringe las especificaciones del protocolo [SWS_DM_01741]. Asimismo, el DM ignora señales como ChannelReestablished si se reciben antes de la llamada exitosa a Start [SWS_DM_01744].