Opciones de zona horaria

La visualización precisa de la hora es una función principal que se espera de un sistema de infoentretenimiento automotriz. Si bien esto puede parecer engañosamente simple, en especial cuando las expectativas de administración de tiempo y zonas horarias son bajas y deben cumplirse, el tiempo se vuelve complejo rápidamente cuando se debe mostrar una fecha y hora precisas de manera confiable sin intervención manual.

Todos los relojes en tiempo real que se usan normalmente en los sistemas en chip (SoC) contienen cierta desviación, que se acumula con el tiempo y puede generar errores significativos si no se corrige. Además, dado que se espera que la hora local se muestre con precisión, se debe tener en cuenta el desplazamiento correcto desde la hora universal coordinada (UTC).

Se espera que la información de la zona horaria, así como la aplicación del horario de verano (DST), cambien durante la vida útil esperada de un vehículo. Por ejemplo, después de muchos años de implementar el DST, Brasil decidió no iniciar un programa de DST en 2019.

Android proporciona la infraestructura necesaria para negociar las complicaciones de la administración de reglas de zona horaria. Para obtener más detalles, consulta Reglas de zonas horarias, que permite a los OEM enviar datos actualizados de reglas de zonas horarias a los dispositivos sin requerir una actualización del sistema. Este mecanismo permite lo siguiente:

  • Los usuarios reciben actualizaciones oportunas (que extienden la vida útil de un dispositivo Android).
  • Los OEM pueden probar las actualizaciones de zona horaria independientemente de las actualizaciones de imagen del sistema.

Nota: AAOS 10 no admite el mecanismo de actualización de módulos basado en APEX que se proporciona en las versiones de Android 10 (y versiones posteriores).

Nota: Para implementar este mecanismo, es necesario reiniciar el sistema.

Fuentes de información de hora (zona) en los automóviles

Los dispositivos Android administran la hora en hora Unix a nivel del sistema, aplican el desplazamiento de zona horaria deseado y, luego, convierten el valor a la hora local para mostrarlo a los usuarios. El ID de zona del usuario actual (a menudo denominado ID de Olson) se almacena como un parámetro de configuración. Por ejemplo, Europe/London.

Gran parte del mecanismo que se describe a continuación detalla la información de tiempo. El objetivo de estos estándares es proporcionar a los usuarios la hora actual, no describir las reglas de zona horaria aplicables. Para determinar la zona horaria real, el dispositivo debe analizar factores como el país, la diferencia horaria y la diferencia horaria del horario de verano antes de establecer el ID de zona.

El proceso puede ser un desafío. Trabajar en sentido inverso según la información disponible puede ser ambiguo. Por ejemplo, la regla de zona horaria America/Denver observa el horario de verano, pero adopta la hora de verano de las Montañas (MDT) durante el verano, mientras que America/Phoenix sigue reconociendo la MDT.

Radio móvil

La información del sistema (SI) es un aspecto esencial de la interfaz de aire de Long-Term Evolution (LTE), que la estación base (BS) transmite a través del canal de control de transmisión (BCCH). El 3GPP TS 36.331 especifica el SystemInformationBlockType16 (SIB16), que contiene información relacionada con el GPS y la hora universal coordinada (UTC), el desfase horario local y la información del horario de verano.

Se puede encontrar una funcionalidad similar en 2G y 3G, donde se puede transmitir información de identidad de red y zona horaria (NITZ) (consulta 3GPP TS 22.042 para obtener más detalles). Otros estándares de radio celular tienen funciones equivalentes.

Desafortunadamente, la mayoría de los estándares tienen en común que el envío de esta información es opcional, por lo que no está disponible de forma universal en todas las redes.

Ventajas Desventajas
  • Cuando está disponible, proporciona la mayor parte de la información deseada.
  • Simplicidad, ya que Android admite la radio celular cuando se expone como un teléfono, no solo como un módem de datos.
  • No requiere conectividad a Internet.

  • No se garantiza que se transmita la información ni que la estación base esté configurada correctamente.

  • En regiones fronterizas, es posible que capte una torre celular (de roaming) de un país vecino y que, potencialmente, muestre la zona horaria incorrecta.

  • En algunas ubicaciones, las actualizaciones pueden tardar horas o incluso días en realizarse.

Protocolo de hora de red

El Protocolo de hora de red (NTP) se suele usar para obtener información relativamente precisa sobre la hora de época de Unix. Android admite la sincronización de la hora del sistema con la de un servidor NTP si se puede exponer a los clientes de RadioManager a través de los metadatos genéricos de RadioTuner.getParameters(). El NTP actualiza la hora del sistema cuando se desincroniza y un operador no proporcionó recientemente una actualización de NITZ. Si el usuario habilita AUTO_TIME cuando NITZ no está disponible, el sistema verifica de inmediato la hora de la red.

Ventajas Desventajas

Simplicidad, compatible con Android.

  • Incompleto: El NTP solo proporciona un valor necesario (hora). Incluso en el mejor de los casos, el NTP no puede proporcionar la zona horaria.

  • Se requiere conexión a Internet.

Sintonizador de radio

Si bien es atractivo aprovechar un sintonizador integrado para recuperar información de hora y zona horaria, existen desafíos. Numerosos estándares de transmisión de radio definen opciones para exponer la información deseada. En general, un sintonizador de radio de transmisión proporciona la misma información que una radio celular.

La sección 8.1 de ETSI EN 300 401 V1.4.1 (2006-06) especifica las funciones de información del servicio que proporcionan información complementaria sobre los servicios para el programa de audio y los datos de los sistemas de Radiodifusión de Audio Digital (DAB). La sección 8.1.3 define el formato de fecha y hora, así como la información sobre el país y el desfase horario local.

Del mismo modo, para el Radio Data System (RDS) que se implementa comúnmente en los sintonizadores de FM, la sección 3.1.5.6 del estándar EN 50067 define el formato para la hora y los datos (que se transmiten una vez por minuto). Además, el código de país extendido (ECC) también se puede recuperar como parte de la identificación del programa transmitido.

La radio HD contiene opciones correspondientes como parte de la especificación HD Radio™ Air Interface Design Description Station Information Service Transport en el mensaje de parámetros del servicio de información de la estación (SIS) (ID de MSG 0111). En la sección 5, se explican claramente las palabras de advertencia que se deben tener en cuenta cuando se intenta usar la compatibilidad con el reloj de la transmisión. La misma sabiduría se aplica por igual a otros sistemas:

… estos datos describen la costumbre local en la ubicación de la emisora, que puede ser igual o no a la costumbre local en el lugar del receptor. Cerca de los límites de las zonas horarias, los usuarios pueden recibir una gran cantidad de estaciones que proporcionan datos diferentes. Por lo tanto, estos datos se proporcionan solo como sugerencias, cuya interpretación y utilización deben ser discrecionales y estar sujetas al control del cliente. …"

Además, al menos en el caso de la radio HD, la transmisión de esta información es opcional y no se debe confiar en ella exclusivamente.

Ventajas Desventajas
  • Por lo general, está disponible en diferentes estándares regionales de radio de transmisión.
  • No requiere conectividad a Internet.
  • Android no admite esta función de forma predeterminada.
  • Requiere que el sintonizador esté encendido (al menos ocasionalmente en segundo plano) para detectar información de manera confiable.

  • La confiabilidad depende de la emisora.

Sugerencias para la implementación

Android admite la sincronización de la hora del sistema con la de un servidor NTP si se puede exponer a los clientes de RadioManager. La solución recomendada es aprovechar la función de extensión del proveedor. La implementación de esta funcionalidad debe ocurrir en la capa de abstracción de hardware (HAL), después de lo cual se puede exponer a los clientes de RadioManager a través del método genérico RadioTuner.getParameters().

Para que la solución siga siendo sólida, el consumidor de esta extensión del proveedor debe determinar que el HAL admite la función (no suponga su existencia). Las cadenas de parámetros para la llamada getParameters deben estar organizadas de forma clara para un uso inequívoco en todos los proveedores. Por ejemplo, usa el espacio de nombres de tu organización agregándole el prefijo del dominio adecuado, por ejemplo, com.me.timezoneTuner.currenttimezone.

Dada la naturaleza basada en eventos de la información, puede ser beneficioso usar la devolución de llamada RadioTuner.Callback.onParametersUpdated() para recibir esta información. Si esta función debe ser configurable, diseña un conjunto de rutinas personalizadas sobre setParameters. Por ejemplo:

com.me.timezoneTuner.currenttimezoneEvent.enable

Por sí solo, el sistema global de navegación por satélite (GNSS) solo puede proporcionar información precisa sobre la hora y la posición.

Ubicación geográfica

La solución a este inconveniente es ejecutar la geocodificación inversa y determinar el país y la zona horaria a través de una búsqueda basada en la posición. El GNSS es la opción obvia (y de mejor calidad) para obtener información de ubicación en un vehículo. La API de Time Zone de Google ofrece todo lo que se necesita para ejecutar la conversión requerida. Por supuesto, se requiere conexión a Internet. Garantizar la privacidad del usuario debe ser una prioridad cuando se implementa una solución en línea. Se requiere y se debe solicitar el permiso de un usuario para aceptar (o no) los costos de uso de datos.

Es factible crear una solución adecuada para el uso sin conexión. Una base de datos de mapas local con resolución suficiente para determinar con precisión el país y la zona horaria puede caber en el almacenamiento de un vehículo. Con esto y una estrategia completamente implementada para actualizar la información de la zona horaria (y el país) según sea necesario, se puede realizar la geocodificación inversa del país o la zona horaria en función de la posición del GNSS obtenida del subsistema de ubicación.

Ventajas Desventajas
  • Puede determinar de forma inequívoca la zona horaria correcta.
  • No requiere conectividad a Internet (en el caso de la BD local).
  • Funciona de manera confiable en la mayoría de las situaciones de conducción.
  • Android no admite esta función de forma predeterminada.
  • Si el vehículo se encuentra en el interior o en un área cubierta donde no es posible una buena recepción de satélites GNSS durante la configuración inicial, no se puede obtener información precisa sobre la hora, la ubicación y la zona horaria.
  • La base de datos local necesita un mecanismo de actualización.
  • Complejidad de la implementación

Teléfono conectado a través de Bluetooth, Wi-Fi o USB

Se pueden usar varias tecnologías para aprovechar el teléfono de un usuario y obtener datos de hora y zona horaria. En todos los teléfonos, se debe instalar un par de apps personalizadas y complementarias en el teléfono y en el sistema de infoentretenimiento del vehículo (IVI). Luego, es posible sincronizar la hora en el intervalo deseado. Por ejemplo, cuando se establece la conexión y cuando el teléfono detecta una nueva zona horaria.

Algunos teléfonos que admiten Bluetooth de bajo consumo (BLE) ofrecen la opción de recuperar la hora a través de la característica de hora actual de GATT y la especificación del perfil de servicio de hora actual 1.1. Sin embargo, esta opción no abarca un segmento de mercado lo suficientemente grande como para depender exclusivamente de ella.

Ventajas Desventajas
  • No requiere conectividad a Internet.
  • Los cambios de zona horaria que detecta el teléfono se pueden transmitir a la unidad principal.
  • Android no admite esta función de forma predeterminada.
  • Solo funciona mientras el teléfono está conectado a la unidad central.
  • La hora es tan buena o mala como la que proporciona el teléfono.
  • La implementación es compleja.
  • No todos los teléfonos admiten el perfil de servicio de hora actual de GATT BLE.

Usa fuentes

Cada proveedor de dispositivos debe determinar qué tan alto debe establecer el estándar y qué recorridos del usuario considera más críticos. Solo con una comprensión clara de las experiencias críticas del usuario deseadas se puede tomar la mejor decisión. En la mayoría de los casos, los proveedores deben considerar las ventajas y desventajas entre la conveniencia y la complejidad de la implementación.

Cada opción descrita anteriormente presenta ventajas y desventajas. Por ejemplo, se debe tomar una decisión de diseño crítica con respecto a cuánta resiliencia, en comparación con la visualización ocasional de la hora incorrecta, es aceptable y cómo administrar los inconvenientes. Una solución completamente automática que se espera que funcione bien en todas las situaciones, pero que debe basarse en una combinación de varias fuentes de información. Ninguna opción por sí sola puede proporcionar un 100% de disponibilidad.

Una opción de configuración manual como alternativa temporal es fácil de ejecutar y, en la práctica, puede ser suficiente para muchos usuarios.