módulo ara::log — Log and Trace

El cluster funcional Log and Trace proporciona la infraestructura central para el registro y rastreo en la AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace p. 13. Las aplicaciones y los demonios de plataforma generan mensajes de registro de forma flexible mediante flujos de datos con seguridad de tipos o mediante llamadas a funciones modeladas altamente eficientes con una mínima sobrecarga de verificación [SWS_LOG_00204]. El filtrado de mensajes se lleva a cabo mediante niveles de detalle configurables por cada contexto, mientras que el reenvío se efectúa hacia el backend de DLT, herramientas ARTI o la consola local [SWS_LOG_00021].

más ›

El cluster funcional Log and Trace (ara::log) constituye la infraestructura básica universal para el registro estructurado, las salidas de diagnóstico y el rastreo cercano al hardware en la AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace p. 13. Cada instancia de Logger representa un contexto propio dentro de un proceso y se registra automáticamente en el backend central de registro en el momento de su creación EXP SWArchitecture p. 57. Además de las aplicaciones, servicios básicos de plataforma como Execution Management, Platform Health Management y Persistency integran obligatoriamente la interfaz Logger para la documentación operativa AUTOSAR AP EXP SWArchitecture p. 58.

Diagrama de contexto: Integración del cluster Log and Trace como infraestructura central de registro y rastreo para aplicaciones adaptativas y clusters funcionales de la plataforma. Fuentes: AUTOSAR AP SWS LogAndTrace p. 13, AUTOSAR AP EXP SWArchitecture p. 58, SWS LogAndTrace p. 21, AUTOSAR AP SWS OperatingSystemInterface p. 21

El módulo distingue entre dos formas de interacción fundamentales:

• Registro no modelado: un patrón fluent builder genera, mediante métodos vinculados a la severidad (como LogInfo() o LogError()), un objeto temporal LogStream que concatena tipos escalares, cadenas de caracteres, códigos de error y modificadores de formato con seguridad de tipos, transmitiendo el búfer a más tardar en el destructor o a través de Flush() [SWS_LOG_00067], [SWS_LOG_00039], [SWS_LOG_00262].
• Registro modelado: a través de la interfaz de llamada única Logger::Log(id, args...) se envían mensajes declarados previamente en el manifiesto, lo que permite un filtrado altamente eficiente sin instanciación de objetos cuando el umbral está inactivo [SWS_LOG_00204], PlatformDesign p. 74.

Diagrama de secuencia: Flujo del registro no modelado por flujos mediante LogStream hasta la transmisión del búfer al backend de registro. Fuentes: [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign p. 74

Para evitar tiempo de cómputo innecesario, el nivel de notificación activo se puede verificar previamente mediante IsEnabled(logLevel) o adaptar en tiempo de ejecución a través de SetThreshold(threshold) [SWS_LOG_00070], [SWS_LOG_00255]. Además del reenvío a canales DLT a través de Ethernet o a herramientas ARTI, en caso de faltar una configuración de modelo la consola actúa como mecanismo de respaldo [SWS_LOG_00021], mientras que el estado de conexión de diagnóstico externo puede supervisarse de forma asíncrona mediante RegisterConnectionStateHandler [SWS_LOG_00098], [SWS_LOG_00205].

más ›

Arquitectura de sistema y rol funcional de Log and Trace

El cluster funcional Log and Trace (ara::log) forma el subsistema transversal central para la captura, el reenvío y el filtrado estandarizados de mensajes de diagnóstico, rastreo y registro en la AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace p. 13. La interfaz de programación Logger proporciona la API de C++ uniforme de la plataforma, la cual es consumida como infraestructura base tanto por procesos específicos de la aplicación (Adaptive Applications) como por los clusters funcionales fundamentales de la plataforma AUTOSAR AP EXP SWArchitecture p. 58. Entre estos demonios del sistema consumidores se encuentran, entre otros, Execution Management para la documentación del ciclo de vida de los procesos AUTOSAR AP EXP SWArchitecture p. 50, Platform Health Management para la supervisión de estados AUTOSAR AP SWS PlatformHealthManagement p. 16, Time Synchronization para referencias temporales de alta precisión AUTOSAR AP SWS TimeSynchronization p. 17, así como Update and Configuration Management durante las actualizaciones de software AUTOSAR AP EXP SWArchitecture p. 141.

Desde el punto de vista arquitectónico, cada instancia de logger encapsula un contexto unívoco (Context ID) dentro de un ámbito de aplicación o de proceso; este contexto se registra automáticamente en el backend de registro al crearse y se da de baja automáticamente al cerrarse la aplicación EXP SWArchitecture p. 57. El backend de registro reenvía los mensajes formateados a canales de salida configurados (p. ej., sumideros de protocolo DLT a través de Ethernet según el manifiesto de máquina) o a búferes locales, recurriendo por defecto a la consola del sistema operativo si no existe un modelo de despliegue [SWS_LOG_00021], SWS LogAndTrace p. 21. Además, una arquitectura desacoplada de adaptadores permite al sistema operativo (POSIX/OS) proporcionar métricas internas del kernel y de planificación a través de la AUTOSAR Run-Time Interface (ARTI) sincronizadas con los mensajes de ara::log AUTOSAR AP SWS OperatingSystemInterface p. 21.

Diagrama de contexto: Integración del cluster Log and Trace como infraestructura central de registro y rastreo para aplicaciones adaptativas y clusters funcionales de la plataforma. Fuentes: AUTOSAR AP SWS LogAndTrace p. 13, AUTOSAR AP EXP SWArchitecture p. 58, SWS LogAndTrace p. 21, AUTOSAR AP SWS OperatingSystemInterface p. 21

Instanciación, gestión de contexto y control de umbrales

La provisión de un contexto de logger se realiza a través de las funciones de fábrica ara::log::CreateLogger, ya que el constructor predeterminado de la clase Logger está eliminado [SWS_LOG_00259]. Las aplicaciones pueden instanciar loggers o bien programáticamente indicando un ID de contexto (ctxId), una descripción (ctxDescription) y, opcionalmente, un nivel de registro por defecto [SWS_LOG_00021], [SWS_LOG_00263], o bien derivarlos en función de la instancia a través de un elemento del modelo mediante ara::core::InstanceSpecifier [SWS_LOG_00256]. El destructor de Logger gestiona la baja del registro de forma segura para subprocesos [SWS_LOG_00260].

La granularidad y la prioridad de los mensajes se representan jerárquicamente mediante la enumeración LogLevel: kFatal (error irrecuperable del sistema), kError (error con degradación funcional), kWarn (advertencia ante un comportamiento previsto comprometido), kInfo (información operativa general), kDebug (diagnóstico detallado) y kVerbose (rastreo exhaustivo) [SWS_LOG_00018], ManifestSpecification p. 416. Para optimizar el tiempo de ejecución, se pueden evitar preparaciones de datos de registro computacionalmente intensivas comprobando previamente, a través de la consulta IsEnabled(logLevel), si el nivel de registro en cuestión está actualmente activado en el contexto [SWS_LOG_00070]. El umbral de notificación activo de una instancia de logger se puede adaptar dinámicamente en tiempo de ejecución mediante SetThreshold(threshold) si es necesario [SWS_LOG_00255].

Registro no modelado y composición de mensajes basada en flujos

Para mensajes no modelados, ara::log proporciona una interfaz fluida basada en el patrón de diseño Builder PlatformDesign p. 74. El punto de entrada se efectúa a través de funciones miembro específicas de la severidad de la instancia Logger, a saber LogFatal(), LogError(), LogWarn(), LogInfo(), LogDebug() y LogVerbose(), o a través de WithLevel(logLevel), las cuales devuelven un objeto LogStream temporal y ligero [SWS_LOG_00064], [SWS_LOG_00065], [SWS_LOG_00066], [SWS_LOG_00067], [SWS_LOG_00068], [SWS_LOG_00069], [SWS_LOG_00131]. A continuación, los datos se añaden concatenados al búfer de mensajes interno a través del operador de inserción de flujo con seguridad de tipos (operator<<) [SWS_LOG_00040].

La interfaz de flujo admite una amplia gama de tipos nativos de C++ y de AUTOSAR sin errores manuales de formato:

• Tipos enteros (con y sin signo de 8 a 64 bits), así como valores booleanos [SWS_LOG_00040], [SWS_LOG_00041], [SWS_LOG_00042], [SWS_LOG_00043], [SWS_LOG_00044], [SWS_LOG_00045], [SWS_LOG_00046], [SWS_LOG_00047], [SWS_LOG_00048].
• Tipos de coma flotante de precisión simple y doble (float, double) [SWS_LOG_00049], [SWS_LOG_00050].
• Cadenas de caracteres UTF-8 terminadas en nulo y ara::core::StringView [SWS_LOG_00051], [SWS_LOG_00062].
• Tipos específicos de la plataforma como LogLevel en formato de texto [SWS_LOG_00063], objetos de error ara::core::ErrorCode [SWS_LOG_00124], intervalos de tiempo std::chrono::duration [SWS_LOG_00125], referencias de modelo ara::core::InstanceSpecifier [SWS_LOG_00126], punteros sin procesar [SWS_LOG_00127] y secuencias de bytes mediante ara::core::Span<const ara::core::Byte> [SWS_LOG_00128].

Los metadatos y los formatos se pueden controlar con precisión: mediante WithLocation(file, line) se captura el origen del código fuente [SWS_LOG_00129], WithTag(tag) añade palabras clave funcionales [SWS_LOG_00132], y WithPrivacy(value) establece un nivel de confidencialidad a través de los 8 bits inferiores [SWS_LOG_00258]. Los argumentos formateados con nombre y unidad física se encapsulan mediante la plantilla auxiliar Arg [SWS_LOG_00201], [SWS_LOG_00203], respaldada por las ayudas de formateo Dflt, Hex, Dec, Oct, Bin, DecFloat, EngFloat, HexFloat y AutoFloat de la enumeración Fmt [SWS_LOG_00206], [SWS_LOG_00208], [SWS_LOG_00209], [SWS_LOG_00211], [SWS_LOG_00217], [SWS_LOG_00225], [SWS_LOG_00226].

En cuanto al ciclo de vida, LogStream es un objeto de solo movimiento (move-only): el constructor de copia y el operador de asignación por copia están eliminados [SWS_LOG_00174], [SWS_LOG_00175], mientras que el constructor de movimiento está declarado para admitir la Return Value Optimization (RVO) [SWS_LOG_00176]; el operador de asignación por movimiento está eliminado [SWS_LOG_00177]. Al salir del ámbito de validez, el contenido del búfer se envía automáticamente al framework de logging mediante el destructor ~LogStream() [SWS_LOG_00262]. Si un objeto LogStream se va a utilizar sucesivamente para varios mensajes dentro del mismo ámbito, la transferencia del búfer debe activarse de forma explícita mediante Flush(), inicializando así un flujo de mensajes nuevo [SWS_LOG_00039]. Interpretación: Es probable que la gestión interna del búfer de LogStream vacíe y reinicialice el búfer para los operadores de streaming posteriores en el mismo ámbito tras llamar a Flush(), sin que sea necesaria la destrucción de la identidad del objeto. Pregunta (abierta)

Diagrama de secuencia: Flujo del registro no modelado por flujos mediante LogStream hasta la transmisión del búfer al backend de registro. Fuentes: [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign p. 74

Registro modelado y bifurcación hacia el rastreo ARTI

A diferencia de la construcción paso a paso de mensajes no modelados, ara::log define para mensajes modelados en el manifiesto una interfaz de llamada única altamente eficiente mediante Logger::Log(id, args...), así como Logger::LogWith(attrs, msgId, params...) [SWS_LOG_00204], [SWS_LOG_00133]. Todos los argumentos se pasan en una única llamada a función, lo que reduce al mínimo la sobrecarga en tiempo de ejecución en caso de mensajes suprimidos: justo después del paso de parámetros, una única condición comprueba el umbral y retorna de inmediato si no se alcanza el nivel de registro configurado PlatformDesign p. 74.

Dentro de la llamada a Log, la ruta de procesamiento se bifurca: además de la ruta clásica de serialización DLT (buildDltMessage(), filtrado mediante máscara de registro y transferencia al sumidero), existe una ruta dedicada para el rastreo cercano al hardware a través de la AUTOSAR Run-Time Interface (ARTI) mediante TraceArti(msg_id, params...) [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace p. 42. Se asume que el reenvío a TraceArti se resuelve en tiempo de compilación mediante especializaciones de plantilla estáticas para garantizar la mínima sobrecarga de tiempo de ejecución exigida. El backend de ARTI filtra según criterios propios basados en MsgId y elude por completo el almacenamiento en búfer de DLT, lo que permite un rastreo crítico en tiempo real sin perturbar el subsistema de logging regular AUTOSAR AP SWS LogAndTrace p. 42.

Diagrama de actividades: flujo de control y filtrado al emitir mensajes modelados entre el backend DLT y el rastreo ARTI. Fuentes: [SWS_LOG_00204], [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace p. 42, PlatformDesign p. 74

Monitorización de conexiones de clientes e integración de diagnóstico

Log and Trace no solo proporciona canales de salida locales, sino que también monitoriza el estado de los clientes de diagnóstico externos (p. ej., DLT Viewer a través de Ethernet), representados por la enumeración ClientState: kUnknown (-1, backend DLT aún no listo), kNotConnected (no se detectó ningún cliente remoto) y kConnected (conexión con cliente externo activa) [SWS_LOG_00098]. Esto permite a las aplicaciones supeditar un rastreo costoso a la presencia física de una herramienta de análisis.

Para el seguimiento asíncrono del estado, las aplicaciones registran una función de retrollamada mediante ara::log::RegisterConnectionStateHandler utilizando el alias de función ConnectionStateHandler = std::function<void(ClientState)> [SWS_LOG_00205], [SWS_LOG_00265]. El framework de logging admite en este contexto exactamente un registro de manejador activo: una nueva llamada a RegisterConnectionStateHandler sobrescribe sin restricciones una retrollamada instalada previamente [SWS_LOG_00205].

Diagrama de estados: transiciones de estado del cliente externo según ClientState. Fuentes: [SWS_LOG_00098], [SWS_LOG_00205], [SWS_LOG_00265]

Comportamiento en caso de error

El módulo impone la seguridad funcional y la robustez principalmente mediante comprobaciones de tipos estáticas en tiempo de compilación y garantías estrictas de excepciones:

• Errores en tiempo de compilación (ill-formed): La llamada a Logger::Log(id, args...) es no válida (ill-formed) si los argumentos pasados no coinciden exactamente con la signatura del mensaje declarada en el manifiesto [SWS_LOG_00204]. Del mismo modo, el uso de Arg() con tipos que no son aritméticos, ni booleanos, ni convertibles a StringView o Span<const Byte> provoca una interrupción de la compilación [SWS_LOG_00201]. La función WithPrivacy(value) impone además que el tipo de parámetro sea un tipo entero o una enumeración [SWS_LOG_00258].
• Prohibiciones de construcción y asignación: Para descartar duplicaciones involuntarias de búferes o conflictos de recursos, el constructor de copia y el operador de asignación por copia de LogStream, así como el operador de asignación por movimiento, están explícitamente eliminados [SWS_LOG_00174], [SWS_LOG_00175], [SWS_LOG_00177].
• Integridad en tiempo de ejecución durante la instanciación: Si la resolución de ara::core::InstanceSpecifier en el modelo de máquina o de aplicación falla en CreateLogger(is) o si este no hace referencia a un elemento de modelo admisible, el sistema notifica una InstanceSpecifierMappingIntegrityViolation [SWS_LOG_00256].
• Sumideros de respaldo tolerantes a fallos: Si en tiempo de ejecución no está disponible ningún modelo de despliegue o conexión de red con el servicio DLT, el framework cambia automáticamente a la consola local como sumidero de salida predeterminado, de modo que no se pierda información de diagnóstico de forma silenciosa [SWS_LOG_00021], [SWS_LOG_00263]. Al emitir un core::ErrorCode en la consola, la representación se realiza mediante el nombre de dominio y el valor numérico del error [SWS_LOG_00124].
• Seguridad ante excepciones: Todos los operadores de streaming, consultas de umbrales y el destructor ~LogStream() están declarados como noexcept para garantizar que el registro no propague en ningún momento excepciones no controladas hacia los bloques funcionales de la aplicación [SWS_LOG_00040], [SWS_LOG_00070], [SWS_LOG_00262]; en cambio, el destructor ~Logger() formalmente no está especificado como noexcept [SWS_LOG_00260].

Más evidencia detallada

La arquitectura y el comportamiento del módulo Log and Trace están fijados en las siguientes referencias de la especificación de AUTOSAR:

• Especificación de interfaz del cluster: Las signaturas C++ normativas, los operadores de flujo y los métodos de contexto de Logger y LogStream están definidos en la especificación de Log and Trace [SWS_LOG_00021], [SWS_LOG_00039], [SWS_LOG_00064], [SWS_LOG_00204], AUTOSAR AP SWS LogAndTrace p. 13.
• Diseño de la plataforma y rendimiento: La comparación arquitectónica entre el patrón Builder y la llamada única altamente eficiente para mensajes modelados se expone en Platform Design PlatformDesign p. 74.
• Dependencias a nivel de plataforma: El uso vinculante de la interfaz Logger por parte de clusters funcionales de la plataforma se detalla en los respectivos documentos de arquitectura AUTOSAR AP EXP SWArchitecture p. 58, AUTOSAR AP EXP SWArchitecture p. 50, AUTOSAR AP SWS PlatformHealthManagement p. 16.
• Modelo de manifiesto y de despliegue: La configuración de los canales de registro DLT, asignaciones de procesos y terminales de máquina está regulada en la especificación del manifiesto SWS LogAndTrace p. 21, ManifestSpecification p. 416.
• Adaptadores de sistema operativo y ARTI: La vinculación de búferes de rastreo nativos del sistema operativo a ara::log y la adquisición cercana al hardware mediante TraceArti están especificadas en la arquitectura de OSI y de rastreo [SWS_LOG_20000], AUTOSAR AP SWS OperatingSystemInterface p. 21, AUTOSAR AP SWS LogAndTrace p. 42.