namespace <ExtendedDataRecord-Namespace>

El espacio de nombres namespace <ExtendedDataRecord-Namespace> agrupa en el módulo diag de AUTOSAR Adaptive Platform interfaces como DiagnosticExtendedDataRecordInterface para la provisión de Extended Data Records específicos de la aplicación para entradas de la memoria de averías. Interpretación: es probable que la aplicación instancie y registre la interfaz durante la inicialización para atender solicitudes de lectura entrantes del gestor de diagnóstico de forma asíncrona con datos contextuales y de contadores actualizados. Pregunta (abierta) En este sentido, el acceso concurrente desde el subsistema de diagnóstico exige una provisión de datos segura para subprocesos y una respuesta oportuna para evitar tiempos de espera agotados (timeouts) de protocolo.

más ›

Contexto

En el módulo diag de AUTOSAR Adaptive Platform, el espacio de nombres namespace <ExtendedDataRecord-Namespace> asume la encapsulación lógica de interfaces para proporcionar datos de diagnóstico ampliados. En el diagnóstico vehicular según ISO 14229 (UDS), los Extended Data Records (EDR) desempeñan un papel fundamental, ya que asocian a una entrada de la memoria de diagnóstico (DTC) información adicional específica, como contadores de frecuencia de averías, contadores de envejecimiento o datos de estado específicos del fabricante. Interpretación: el identificador <ExtendedDataRecord-Namespace> probablemente sirva como marcador de posición formal para espacios de nombres configurados de forma específica para el modelo, en los que se generan interfaces de diagnóstico específicas de la aplicación para elementos de registros de datos. Pregunta Q-96107a4ff53015bb (abierta) La clase principal DiagnosticExtendedDataRecordInterface (indicada en el modelo como <ExtendedDataRecordElementInterface>) actúa como capa de abstracción entre el gestor de diagnóstico de AUTOSAR y la aplicación ejecutora, la cual mantiene los valores de estado físicos o lógicos.

Ciclo de vida

La duración y la gestión del estado de los objetos de tipo DiagnosticExtendedDataRecordInterface están estrechamente acopladas al ciclo de vida del componente de aplicación que los proporciona. Interpretación: la instanciación y la gestión del ciclo de vida de la instancia de la interfaz probablemente sigan el patrón de proveedor de servicios habitual de ara::diag, en el que la aplicación crea la interfaz durante su fase de inicialización y la pone a disposición del framework de diagnóstico. Pregunta Q-9968bfe101348d1f (abierta) Durante la fase operativa de funcionamiento, la instancia permanece activa en memoria para atender solicitudes de lectura entrantes de datos de diagnóstico. En un apagado ordenado del software funcional, la instancia debe desregistrarse o destruirse antes de que finalicen los subsistemas dependientes. Dado que las solicitudes de diagnóstico pueden llegar de forma asíncrona a través del demonio de diagnóstico, la implementación de la clase de interfaz requiere un diseño seguro para subprocesos a fin de proteger los accesos de lectura simultáneos a datos de estado internos de la aplicación.

Ruta de uso

Un flujo de uso típico comprende la definición, la provisión y la ejecución de la consulta de registros de datos. Al principio, la aplicación funcional instancia la implementación concreta de DiagnosticExtendedDataRecordInterface y la vincula al puerto configurado. Si posteriormente un tester de diagnóstico externo introduce una solicitud de lectura para un Extended Data Record determinado mediante un comando UDS (por ejemplo, el servicio 0x19 para consultar información de averías), el gestor de diagnóstico la delega en la interfaz registrada. Interpretación: la interfaz probablemente esté concebida como una interfaz de servicio a través de la cual el gestor de diagnóstico recupera el contenido actualizado de los registros de datos en caso de ser necesario. Pregunta Q-00d5498b4380bf74 (abierta) La aplicación recopila los valores de datos requeridos, los codifica en el formato de datos especificado y devuelve el resultado al gestor de diagnóstico, el cual ensambla el mensaje de respuesta UDS para la herramienta de prueba.

Escenarios de error

Durante el funcionamiento de las interfaces de registros de datos pueden producirse diversas situaciones de error que el software de la aplicación debe gestionar de manera específica. Si la instancia de la interfaz no está completamente registrada en el momento de una solicitud de diagnóstico o se encuentra en un estado de transición, el gestor de diagnóstico no puede reenviar la solicitud a la aplicación y suele responder al tester con un código de respuesta negativo (NRC). Si la provisión de los datos dentro de la aplicación se retrasa más allá de una ventana temporal definida, existe el riesgo de que se produzcan tiempos de espera agotados (timeouts) de protocolo en la interfaz de diagnóstico. Además, la interfaz debe ser robusta frente a valores de medición no disponibles temporalmente, notificando accesos a datos no válidos o estados de error al gestor de diagnóstico a través de los mecanismos de error previstos, en lugar de desencadenar excepciones no controladas en el proceso.