módulo ara::tsync — Time Synchronization

El clúster funcional Time Synchronization proporciona a la AUTOSAR Adaptive Platform bases de tiempo consistentes y sincronizadas en toda la red (AUTOSAR_AP_SWS_TimeSynchronization p. 16). A través de interfaces estandarizadas, las aplicaciones adaptativas consultan estados de tiempo atómicos o introducen, como fuentes de tiempo activas, nuevas correcciones de tiempo y de tasa en el sistema global. Al mismo tiempo, las callbacks notifier registradas monitorizan continuamente los cambios de estado y los saltos de tiempo de los relojes subyacentes ([SWS_TS_01009]). Mecanismos avanzados para la validación de datos de medición y valores de frescura aseguran la integridad temporal frente a errores de transmisión y manipulaciones.

más ›

El clúster funcional Time Synchronization (tsync) proporciona en la AUTOSAR Adaptive Platform bases de tiempo consistentes y sincronizadas en toda la red (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Como servicio en segundo plano basado en demonio, abstrae mecanismos de sincronización específicos del hardware y del bus (como IEEE 802.1AS gPTP) y abastece a clústeres centrales como Log and Trace, el Intrusion Detection System Manager (IdsM), así como a servicios de actualización a través de interfaces estandarizadas (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Diagrama de contexto: integración del clúster Time Synchronization basado en demonio en la AUTOSAR Adaptive Platform y sus relaciones de interfaz con clústeres consumidores y aplicaciones. Fuentes: AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

Para el acceso de lectura, las aplicaciones utilizan la interfaz SynchronizedTimeBaseConsumer ([SWS_TS_01001]). El método GetTimeWithStatus() devuelve una instantánea atómica del tipo SynchronizedTimeBaseStatus, a partir de la cual se pueden consultar el tiempo global, el tiempo local continuo de creación, el estado de sincronización y los UserData recibidos ([SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176]). Para evitar el polling, las aplicaciones se registran a través de callbacks notifier para cambios de estado y saltos de tiempo ([SWS_TS_01010], [SWS_TS_01014]).

Diagrama de secuencia: desarrollo de una consulta de tiempo síncrona a través de la interfaz de consumidor y lectura de propiedades de instantáneas atómicas. Fuentes: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Las aplicaciones proveedoras de tiempo controlan el comportamiento del sistema mediante SynchronizedTimeBaseProvider: SetTime() desencadena transmisiones inmediatas en el bus, mientras que UpdateTime() ajusta el reloj inicialmente a nivel local ([SWS_TS_01101], [SWS_TS_01107], [SWS_TS_01108]). Mecanismos complementarios como Time Validation ([SWS_TS_00420], [SWS_TS_00421]) y la gestión nativa Freshness Value Management (FVM) protegen contra errores de deriva y de reproducción (replay) ([SWS_TS_14198]). En caso de error, los códigos TsyncErrc (p. ej., kDaemonConnectionLost) señalan pérdidas de conexión, mientras que la falta de mensajes de sincronización se indica como kTimeOut en el objeto de estado ([SWS_TS_00901], [SWS_TS_01050]).

más ›

El clúster funcional Time Synchronization (tsync) proporciona en la AUTOSAR Adaptive Platform bases de tiempo coordinadas y sincronizadas en toda la red, y desacopla los procesos de aplicación de los protocolos de sincronización de tiempo específicos de hardware y bus (AUTOSAR_AP_SWS_TimeSynchronization p. 16). El sistema constituye el fundamento informático para sistemas distribuidos en los que deben garantizarse secuencias de eventos consistentes, registros de trazas reproducibles y ciclos de cómputo deterministas más allá de los límites de las unidades de control (AUTOSAR_AP_EXP_SWArchitecture p. 83).

Diagrama de contexto: integración del clúster Time Synchronization basado en demonio en la AUTOSAR Adaptive Platform y sus relaciones de interfaz con clústeres consumidores y aplicaciones. Fuentes: AUTOSAR_AP_SWS_TimeSynchronization p. 16, AUTOSAR_AP_EXP_SWArchitecture p. 83, AUTOSAR_AP_EXP_SWArchitecture p. 83

Límites del sistema y rol del clúster Time Synchronization basado en demonio

La arquitectura funcional de Time Synchronization está implementada como un clúster basado en demonio (daemon-based), el cual opera en segundo plano como un servicio central de la plataforma (AUTOSAR_AP_SWS_TimeSynchronization p. 16). Este demonio interactúa directamente con las interfaces del sistema operativo subyacente y procesa datos de sincronización de tiempo basados en red, como gPTP (IEEE 802.1AS) o sincronizaciones de tiempo de bus clásicas (AUTOSAR_FO_PRS_TimeSyncProtocol p. 68). Frente al contexto de aplicación, el clúster encapsula completamente la compensación matemática de deriva y desfase (offset) de los relojes de hardware.

Numerosos clústeres funcionales centrales de la Adaptive Platform acceden a tsync a través de interfaces de servicio estandarizadas (AUTOSAR_AP_EXP_SWArchitecture p. 83). Por ejemplo, Log and Trace se apoya en la base de tiempo sincronizada para dotar a los eventos del sistema de registro y DLT de marcas de tiempo globales fiables (AUTOSAR_AP_EXP_SWArchitecture p. 59; AUTOSAR_AP_SWS_LogAndTrace p. 15). Asimismo, módulos relevantes para la seguridad como el Intrusion Detection System Manager (IdsM), así como los servicios de actualización (UCM y Vehicle UCM), recurren de forma obligatoria a la interfaz C++ de SynchronizedTimeBaseConsumer para gestionar informes forenses sólidos y transacciones de actualización consistentes a través de los límites de las unidades de control (AUTOSAR_AP_EXP_SWArchitecture p. 125; AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 16; AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement p. 11).

Interfaces consumidoras y consultas de tiempo con estado

Para el acceso de lectura a una base de tiempo sincronizada, las aplicaciones emplean la clase de interfaz SynchronizedTimeBaseConsumer ([SWS_TS_01001]). La clase implementa la semántica de movimiento (move) ([SWS_TS_01003], [SWS_TS_01004]), pero excluye explícitamente cualquier copia ([SWS_TS_01005], [SWS_TS_01006]). En tiempo de ejecución, GetRateDeviation() permite la lectura directa de la desviación de frecuencia actual del reloj ([SWS_TS_01008]).

El elemento central de cada consulta síncrona es la operación GetTimeWithStatus() ([SWS_TS_01009]). En lugar de devolver valores de tiempo brutos aislados, el método genera una instantánea intrínsecamente consistente del tipo SynchronizedTimeBaseStatus (EXP_SWArchitecture p. 81). Esta instantánea congela el instante exacto de creación en tiempo global ([SWS_TS_01055]), así como en tiempo local continuo mediante GetCreationLocalTime() ([SWS_TS_14176]). Los instantes de tiempo se representan aquí en el tipo estandarizado de C++ Chrono Timestamp con resolución de nanosegundos sobre la base de std::int64_t ([SWS_TS_01251], [SWS_TS_01261], [SWS_TS_01262]).

A partir de la instantánea, además del tiempo, también se pueden determinar el estado de comunicación y sincronización a través de GetSynchronizationStatus() ([SWS_TS_01053]), un posible salto de tiempo mediante GetLeapJump() ([SWS_TS_01054]) y datos de usuario específicos de la aplicación a través de GetUserData() ([SWS_TS_01056]). No existe un constructor por defecto para el objeto de estado ([SWS_TS_01061]), mientras que los constructores de movimiento y copia garantizan su paso seguro entre subprocesos (thread-safe) a las rutinas de aplicación llamantes ([SWS_TS_01057], [SWS_TS_01058]).

Diagrama de secuencia: desarrollo de una consulta de tiempo síncrona a través de la interfaz de consumidor y lectura de propiedades de instantáneas atómicas. Fuentes: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture p. 225

Notificaciones basadas en eventos y monitorización de la sincronización

Para evitar bucles de polling, SynchronizedTimeBaseConsumer proporciona un patrón de diseño observador controlado por eventos mediante callbacks notifier (AUTOSAR_AP_EXP_SWArchitecture p. 226). Las aplicaciones se registran con callbacks de tipos seguros para cambios de estado específicos ([SWS_TS_14221], [SWS_TS_14222]). Con cada nuevo registro, el nuevo notifier sobrescribe el manejador registrado previamente ([SWS_TS_01010]).

Para cambios de estado agregados existe RegisterStatusChangeNotifier() ([SWS_TS_01010]), complementado por UnregisterStatusChangeNotifier() ([SWS_TS_01011]). Si una aplicación reacciona principalmente al cambio del estado de sincronización (p. ej., pérdida de conexión con el Grandmaster), se utiliza RegisterSynchronizationStateChangeNotifier() ([SWS_TS_01012]). Los saltos de tiempo hacia el futuro (kTimeLeapFuture) o hacia el pasado (kTimeLeapPast) que superen un valor de umbral configurado se notifican mediante RegisterTimeLeapNotifier() ([SWS_TS_01014], [SWS_TS_01051]).

Para aplicaciones mecatrónicas de alta precisión se encuentra además disponible RegisterTimePrecisionMeasurementNotifier() ([SWS_TS_01018]). La callback pasa una estructura TimePrecisionMeasurement que contiene valores exactos de segundos y nanosegundos directamente antes (locSeconds, locNanoSeconds) y después de la sincronización (glbSeconds, glbNanoSeconds), el retardo de ruta calculado pathDelay, así como la máscara de bits timeBaseStatus ([SWS_TS_01401], [SWS_TS_01403], [SWS_TS_01406], [SWS_TS_01408]). El clúster Time Synchronization no realiza aquí ninguna gestión de colas (queuing); el almacenamiento en búfer debe implementarse, en caso necesario, dentro de la callback de la aplicación ([SWS_TS_01018]).

Diagrama de secuencia: registro y flujo de notificación asíncrono ante cambios de sincronización y saltos de tiempo. Fuentes: [SWS_TS_01010], [SWS_TS_01012], [SWS_TS_01014], AUTOSAR_AP_EXP_SWArchitecture p. 226

Diagrama de estados: ciclo de vida del estado de sincronización de una base de tiempo según SWS_TS_01050. Fuentes: [SWS_TS_01050], AUTOSAR_SWS_TimeSync p. 25

Suministro de bases de tiempo y ajuste de frecuencia por parte de proveedores

Si una Adaptive Application actúa como fuente de tiempo activa (Time Master) —por ejemplo, mediante la conexión a un receptor GNSS o a un reloj de referencia externo—, utiliza la clase SynchronizedTimeBaseProvider ([SWS_TS_01101]). La interfaz permite el establecimiento explícito de nuevos valores de tiempo mediante dos semánticas diferentes: SetTime() y UpdateTime() (EXP_SWArchitecture p. 80).

La invocación de SetTime() no solo restablece el valor del reloj interno, sino que fuerza el envío inmediato de los mensajes de sincronización actualizados en el bus del vehículo ([SWS_TS_01107]). Por el contrario, UpdateTime() actualiza la hora inicialmente solo a nivel local; la transmisión al bus tiene lugar de forma diferida en el ciclo sucesivo regular del protocolo de transferencia de tiempo ([SWS_TS_01108]). Ambos métodos aceptan, además de la marca de tiempo, UserData estructurados con el fin de distribuir por toda la red información adicional que acompaña a la sincronización ([SWS_TS_01112], [SWS_TS_01113]).

Para el ajuste fino de osciladores de cuarzo y la prevención de saltos de fase abruptos, SetRateCorrection() permite aplicar un factor relativo de corrección de frecuencia ([SWS_TS_01110]). De forma complementaria, GetRateDeviation() proporciona la desviación de reloj presente en ese momento ([SWS_TS_01111]), mientras que GetCurrentTime() lee el valor de tiempo absoluto del reloj independientemente del estado de sincronización actual ([SWS_TS_01109]).

Aseguramiento de la integridad mediante Time Validation y Freshness Value Management

En entornos de conducción altamente automatizados y críticos para la seguridad, no basta con la mera adopción de valores de tiempo; la corrección y la protección contra manipulaciones de las marcas de tiempo deben validarse continuamente (AUTOSAR_AP_SWS_TimeSynchronization p. 38). Para ello, tsync ofrece interfaces de callback para Time Validation: los consumidores se registran mediante RegisterTimeValidationNotification() ([SWS_TS_01016]), y los proveedores de forma análoga mediante el método específico de proveedor ([SWS_TS_01114]).

Las interfaces de validación ConsumerTimeBaseValidationNotification y ProviderTimeBaseValidationNotification entregan conjuntos de datos de medición detallados a aplicaciones de monitorización especializadas ([SWS_TS_01300], [SWS_TS_01301]). En la estación maestra, SetMasterTimingData() proporciona la marca de tiempo de egreso (syncEgressTimestamp) y el número de secuencia (sequenceId) de las tramas de sincronización enviadas ([SWS_TS_00421], [SWS_TS_14141], [SWS_TS_14142]). En el nivel esclavo, SetSlaveTimingData() entrega las marcas de tiempo de ingreso correspondientes (syncIngressTimestamp), el campo de corrección recibido (correctionField), así como el retardo de ruta medido (pDelay) ([SWS_TS_00420], [SWS_TS_14152], [SWS_TS_14153], [SWS_TS_14155]). Para mediciones de retardo punto a punto (peer-to-peer), SetPdelayInitiatorData() y SetPdelayResponderData() proporcionan por completo los instantes de entrada y salida de los paquetes de solicitud y respuesta ([SWS_TS_00422], [SWS_TS_00423], [SWS_TS_14160], [SWS_TS_14170]).

Para proteger contra ataques de reproducción (replay) y asegurar los mensajes de tiempo transmitidos, la plataforma integra Freshness Value Management (FVM) mediante interfaces nativas en el espacio de nombres apext::tsync ([SWS_TS_14198], EXP_SWArchitecture p. 83). Durante el arranque, Initialize() inicializa el plugin FVM correspondiente ([SWS_TS_14200]). Antes del envío, la pila invoca GetTxFreshness() para consultar valores de contador recientes ([SWS_TS_14199]), mientras que en la recepción se utiliza GetRxFreshness() para la verificación y autenticación ([SWS_TS_14198]). Los datos se transportan aquí a través del FVContainer estandarizado ([SWS_TS_14195], [SWS_TS_14196]).

Diagrama de secuencia: flujo de validación de datos de medición de temporización entre maestro, esclavo y aplicación validadora externa. Fuentes: [SWS_TS_00420], [SWS_TS_00421], AUTOSAR_AP_SWS_TimeSynchronization p. 38

Configuración, vinculación de procesos y modelado de manifiestos

La asignación y vinculación funcional del clúster se realiza de forma declarativa en los manifiestos de modelo AUTOSAR (AUTOSAR_AP_TPS_ManifestSpecification p. 590). En el Machine Manifest, el demonio de la plataforma se instancia sobre una Machine concreta mediante el elemento de metamodelo TimeSyncModuleInstantiation, y administra allí los objetos TimeBaseResource físicos y virtuales (AUTOSAR_AP_TPS_ManifestSpecification p. 590).

En el nivel de aplicación, los procesos declaran sus necesidades de bases de tiempo mediante prototipos de puerto (RPortPrototype para consumidores o PPortPrototype para proveedores) (AUTOSAR_AP_TPS_ManifestSpecification p. 599). El constructo de metamodelo TimeSyncPortPrototypeToTimeBaseMapping vincula estos puertos de manera individual por proceso con las bases de tiempo definidas en la máquina (TPS_ManifestSpecification p. 599; AUTOSAR_AP_TPS_ManifestSpecification p. 600). En tiempo de ejecución, la instanciación se lleva a cabo en el código mediante el ara::core::InstanceSpecifier con seguridad de tipos, mediante el cual la pila vincula la base de tiempo configurada correcta ([SWS_TS_01001], [SWS_TS_01101]).

Comportamiento en caso de error

Las situaciones de error en el cluster de sincronización de tiempo se señalan a través del modelo de errores estandarizado de la Adaptive Platform (ara::core::Result y ara::core::ErrorCode) ([SWS_TS_00910]). Para las operaciones regulares de base de tiempo, la enumeración TsyncErrc define los códigos de error ([SWS_TS_00901]). Si, por ejemplo, se interrumpe la comunicación entre procesos con el daemon de la plataforma, se devuelve el código de error kDaemonConnectionLost ([SWS_TS_00901]).

A través del dominio de errores global TsyncErrorDomain se pueden inspeccionar códigos de error ([SWS_TS_00905], [SWS_TS_00906], [SWS_TS_00907]) o, con las excepciones de C++ habilitadas, lanzarse mediante ThrowAsException() como TsyncException ([SWS_TS_00903], [SWS_TS_00908], [SWS_TS_00909]). Para el Freshness Value Management existe un dominio de errores independiente TsyncFvmErrorDomain con la enumeración TsyncFvmErrc ([SWS_TS_14201], [SWS_TS_14202]). Si la inicialización falla, Initialize() proporciona el error kFVInitializeFailed ([SWS_TS_14200]), mientras que si los contadores para las verificaciones de autenticación no están disponibles, se notifica kFVNotAvailable ([SWS_TS_14202]).

A nivel funcional, el cluster no señala necesariamente la pérdida de mensajes de tiempo mediante errores síncronos de la API, sino que marca la base de tiempo en el objeto de estado con el estado de comunicación kTimeOut ([SWS_TS_01050]) o establece el bit correspondiente en timeBaseStatus ([SWS_TS_01403]). Interpretación: por lo tanto, la aplicación debería tener siempre la obligación de verificar activamente el estado de validez de la instantánea tras GetTimeWithStatus() antes de utilizar los valores medidos para bucles de control críticos para la seguridad. Pregunta Q-0cd9bb48452ae3db (abierta)

Más evidencia detallada

Los requisitos fundamentales y los puntos de especificación del módulo tsync se pueden asignar a los siguientes aspectos principales:

• Interfaces de tiempo de ejecución para consumidores y proveedores: las operaciones de ciclo de vida y de consulta se basan en [SWS_TS_01001] hasta [SWS_TS_01019], así como en las funciones de proveedor [SWS_TS_01101] hasta [SWS_TS_01115] (EXP_SWArchitecture p. 80, EXP_SWArchitecture p. 81).
• Estructuras de estado y representación del tiempo: definición de SynchronizedTimeBaseStatus, SynchronizationStatus y LeapJump según [SWS_TS_01050] hasta [SWS_TS_01062], así como tipos Chrono estándar de conformidad con [SWS_TS_01251] hasta [SWS_TS_01265]."
• Time Validation y adquisición de datos de medición: definición de las estructuras de medición y de las devoluciones de llamada de notificación de conformidad con [SWS_TS_00420] hasta [SWS_TS_00423], así como [SWS_TS_14140] hasta [SWS_TS_14174] (AUTOSAR_AP_SWS_TimeSynchronization p. 38).
• Extensión de seguridad FVM: autenticación y verificación de frescura a través de las interfaces [SWS_TS_14195] hasta [SWS_TS_14213] (AUTOSAR_AP_EXP_SWArchitecture p. 83).
• Modelado de manifiestos: configuración declarativa y asignación de procesos y prototipos de puerto a bases de tiempo de conformidad con AUTOSAR_AP_TPS_ManifestSpecification p. 590 y AUTOSAR_AP_TPS_ManifestSpecification p. 599.