Sincronización de hora

La plataforma de vehículos definidos por software (SDV) de AAOS define mecanismos estándar para la generación de informes de fuentes de tiempo desde las unidades de control electrónico (ECU) y superficies estándar para exponer información de tiempo en instancias de SDV. En esta página, se proporcionan detalles y orientación sobre el estándar de SDV.

Arquitectura del reloj

La plataforma de SDV tiene dos relojes estándar:

  • Reloj UTC: Este es el reloj estándar de la hora universal coordinada. Por lo general, SOME/IP lo proporciona desde las ECU al tiempo de ejecución de la plataforma. Los casos de uso incluyen la actualidad de los certificados, los diagnósticos y V2X.

  • Reloj monotónico de red: Es un indicador de reloj no decreciente y muy preciso que proporcionan las ECU y que la arquitectura más amplia del vehículo usa para garantizar que los eventos estén coordinados. Las ECU proporcionan esta información a la plataforma de SDV a través de gPTP. Este reloj también se conoce como reloj estable.

Los relojes de la plataforma del SDV tienen requisitos arquitectónicos específicos:

  • Entrega de reloj: Cada instancia de VM obtiene acceso al mismo indicador de reloj monotónico que proporcionan las ECU.

  • Integridad del reloj: Se espera que la entrada del reloj monotónico de la red sea una fuente confiable para coordinar eventos en todos los servicios. La defensa contra posibles vulnerabilidades del sistema, como ataques de repetición o inversión de tiempo, se basa en la integridad del reloj monotónico.

  • Uso de alarmas: Las APIs de reloj de la plataforma de SDV no se deben usar para eventos con una frecuencia alta de ocurrencia (mayor que 100 Hz) o una latencia inferior a 10 ms entre la programación y la hora del evento. Las APIs de alta frecuencia o baja latencia deben usar un controlador de kernel.

APIs de Clock

El reloj monotónico de la red se expone a través de la API de clock_gettime(3) estándar:

// Network monotonic clock uses standard Linux API.
// This is represented as a dynamic clock in clock_gettime(3)
clock_gettime(clockid_t id, &timespec)

Este reloj se proporciona a través de un mecanismo de red PTP a todas las VMs y se registra como un reloj dinámico para fines de clock_gettime(3).

El reloj UTC se representa con CLOCK_REALTIME en clock_gettime(3).

Controlador de dispositivo opcional

Los OEM tienen la opción de exponer un bloqueo de dispositivo Linux para propiedades de tiempo adicionales. Expón esto con el control de permisos a través de sepolicy:

# in device/OEM/target/sepolicy/time/file_contexts
/dev/sdvtime u:object_r:time_device:s0

Los OEM son responsables del desarrollo y las capacidades del controlador de dispositivo Linux personalizado que expone las APIs al bloque del dispositivo.

Notificaciones y devoluciones de llamada

Las notificaciones y las devoluciones de llamada para los componentes de tiempo en el SDV son capacidades de Userland proporcionadas por el OEM. La plataforma de SDV no proporciona APIs específicas para estas funciones.

Debe haber hasta un servicio OEM por VM que requiera la función de sincronización de hora, que controle todos los cambios de hora pertinentes que se deben supervisar. Por ejemplo, cuando cambia el estado de confianza de la fuente de hora actual:

  • Se espera que los cambios en los estados de la fuente de tiempo sean eventos de baja frecuencia, por lo que un servicio del OEM puede verificar los cambios a través de sondeos, por ejemplo, una vez por minuto.

  • Las ECU comunican el estado de confianza del reloj UTC a través de la red, por ejemplo, a través de SOME/IP.

  • Un servicio del OEM publica temas de Data Tunnel específicos para mostrar estos cambios a los suscriptores.

  • Los OEM personalizan la política de autorización para los servicios y determinan cuáles pueden suscribirse a estos temas de Data Tunnel para escuchar los cambios de estado de tiempo confiables.

Estado y manejo de errores

Los códigos de error siguen las convenciones de las APIs de Linux estándar involucradas, por ejemplo:

  • Si clock_gettime() falla, se devuelve -1 y se configura errno, lo que implica que no se admite la operación del reloj o que la fuente del reloj subyacente no está lista.

  • Si fopen() falla, se devuelve un puntero nulo y se establece errno, lo que implica que el dispositivo de bloqueo no está disponible.

  • Si falla una llamada a ioctl(), se devuelve -1 y se establece errno, lo que implica que el código de solicitud especificado no tiene una respuesta coincidente del controlador subyacente.