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 la administración de la hora y la zona horaria son bajas y se deben cumplir, la hora se vuelve compleja rápidamente cuando se debe mostrar una fecha y hora confiablemente precisas sin intervención manual.

Todos los relojes en tiempo real que se usan normalmente en el sistema en chip (SoC) contienen cierta desviación, que se acumula con el tiempo y puede generar un error significativo si no se corrige. Además, debido a que las expectativas son altas de que la hora local se muestre con precisión, se debe considerar el desplazamiento correcto de la hora universal coordinada (UTC).

Se puede esperar 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 zona horaria, que permite a los OEMs enviar datos actualizados de reglas de zona horaria 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 OEMs prueban 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, se requiere un reinicio del sistema.

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

Los dispositivos Android administran la hora en la 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 (que suele denominarse 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 describe la información de la hora. 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 retroceder a partir de factores como el país, el desplazamiento y el desplazamiento de DST antes de establecer el ID de zona.

El proceso puede ser un desafío. Retroceder en función de la información disponible puede ser ambiguo. Por ejemplo, la regla de zona horaria America/Denver observa el DST, pero se adopta al horario de verano de las Montañas (MDT) durante el verano, mientras que America/Phoenix continúa reconociendo el 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 transmite la estación base (BS) a través del canal de control de transmisión (BCCH). 3GPP TS 36.331 especifica el SystemInformationBlockType16 (SIB16), que contiene información relacionada con el GPS y la hora universal coordinada (UTC), la compensación de tiempo local, así como la información de DST.

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 móvil tienen funciones equivalentes.

Lamentablemente, lo que tienen en común la mayoría de los estándares es 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 compatible con Android cuando la radio móvil se expone como un teléfono, no solo como un módem de datos.
  • No requiere conectividad a Internet.

  • No hay garantías de que se transmita la información ni de que la estación base esté configurada correctamente.

  • En las regiones fronterizas, es probable que capte una torre de telefonía celular (en roaming) de un país vecino y que transmita la zona horaria incorrecta.

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

Protocolo NTP

El protocolo NTP suele usarse para obtener información de la hora de la época de Unix relativamente precisa. 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 RadioTuner.getParameters(). 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, NTP proporciona solo un valor necesario (hora). Incluso en el mejor de los casos, NTP no puede proporcionar la zona horaria.

  • Requiere conectividad a Internet.

Sintonizador de radio de transmisión

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

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

Del mismo modo, para el sistema de datos de radio (RDS) que se implementa comúnmente en los sintonizadores de FM, la sección 3.1.5.6 de la norma EN 50067 define el formato de hora y datos (transmitidos 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.

HD Radio contiene las opciones correspondientes como parte de la descripción del diseño de la interfaz de aire de HD Radio™ especificación de transporte del servicio de información de la estación en el mensaje de parámetro del servicio de información de la estación (SIS) (ID de MSG 0111). En la sección 5, se indican 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 igualmente a otros sistemas:

... estos datos describen la costumbre local en la ubicación de la emisora, que puede ser la misma o no que la costumbre local en el lugar del receptor. Cerca de los límites de la zona horaria, los consumidores pueden recibir una multiplicidad 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, sujetas al control del cliente. ..."

Además, al menos para HD Radio, la transmisión de esta información es opcional y no se debe depender de 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 esto de inmediato.
  • 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 de 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 la HAL admite la función (no supongas su existencia). Las cadenas de parámetros para la llamada getParameters deben estar bien organizadas para un uso inequívoco en todos los proveedores. Por ejemplo, usa el espacio de nombres de tu organización agregando el prefijo con el 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 de 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 mediante una búsqueda basada en la posición. GNSS es la opción obvia (y de mejor calidad) de información de ubicación en un vehículo. La API de Time Zone de Google ofrece todo lo necesario para ejecutar la conversión requerida. Por supuesto, se requiere conectividad 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 posible crear una solución adecuada para el uso sin conexión. Una base de datos de mapas local con la 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 geocodificar de forma inversa el país o la zona horaria en función de la posición de 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 caso de una base de datos local).
  • Funciona de manera confiable para la mayoría de las situaciones de conducción.
  • Android no admite esto de inmediato.
  • Si el vehículo está 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, es imposible obtener información precisa de 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 la hora y la zona horaria. Para todos los teléfonos, se debe instalar un par de apps personalizadas y apps complementarias en el teléfono y en el sistema de infoentretenimiento en el 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) proporcionan la opción de recuperar la hora a través de la característica de hora actual de GATT y la especificación de perfil del servicio de hora actual 1.1. Sin embargo, esta opción no aborda un segmento de mercado lo suficientemente grande como para depender de ella exclusivamente.

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

Usar fuentes

Cada proveedor de dispositivos debe determinar qué tan alto debe establecer el límite y qué recorridos del usuario considera más críticos. Solo con una comprensión clara de las experiencias del usuario críticas deseadas se puede tomar la mejor decisión. En la mayoría de los casos, los proveedores deben considerar las compensaciones 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 las desventajas. Una solución completamente automática que se puede esperar que funcione bien en todas las situaciones, pero que debe basarse en una combinación de varias fuentes de información. Ninguna opción puede proporcionar una disponibilidad del 100%.

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.