La visualización precisa de la hora es una función principal que se espera de un sistema de infoentretenimiento para vehículos. Si bien esto puede parecer engañosamente simple, en especial cuando las expectativas de administración del tiempo y la zona horaria son bajas y deben cumplirse, el tiempo se vuelve complejo rápidamente cuando se debe mostrar una fecha y una hora precisas y confiables sin intervención manual.
Todos los relojes en tiempo real que se suelen usar en el sistema en chip (SoC) contienen cierta deriva, que se acumula con el tiempo y puede generar errores significativos 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 desfase correcto de la hora universal coordinada (UTC).
Se espera que la información de la zona horaria, así como la aplicación del horario de verano, cambien durante la vida útil esperada de un vehículo. Por ejemplo, después de muchos años de implementar el horario de verano, Brasil decidió no iniciar un programa de horario de verano en 2019.
Android proporciona la infraestructura necesaria para negociar las complicaciones de la administración de reglas de zonas horarias. Para obtener más información, consulta Reglas de zonas horarias, que permite a los OEMs 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 OEMs pueden probar las actualizaciones de zona horaria independientemente de las actualizaciones de imagen del sistema.
Nota: AAOS 10 no es compatible con 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 la hora (zona) en los vehículos
Los dispositivos Android administran la hora en formato Unix a nivel del sistema, aplican la compensación de zona horaria deseada y, luego, convierten el valor a la hora local para mostrarla a los usuarios. El ID de zona del usuario actual (a menudo, se conoce como ID de Olson) se almacena como parámetro de configuración. Por ejemplo, Europe/London.
Gran parte del mecanismo que se describe a continuación describe 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 retroceder desde factores como el país, el desfase y el desfase de DST antes de establecer el ID de zona.
El proceso puede ser un desafío. Trabajar hacia atrás en función de la información disponible puede ser ambiguo. Por ejemplo, la regla de zona horaria America/Denver observa el horario de verano, pero adopta el horario de verano de las Montañas Rocosas (MDT) durante el verano, mientras que America/Phoenix sigue reconociendo el MDT.
Radio móvil
La información del sistema (SI) es un aspecto esencial de la interfaz de aire de la evolución a largo plazo (LTE), que transmite la estación base (BS) a través del canal de control de transmisión (BCCH). El TS 36.331 de 3GPP especifica el SystemInformationBlockType16 (SIB16), que contiene información relacionada con el GPS y la hora universal coordinada (UTC), la desviación horaria 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 información). Otros estándares de radio celular tienen funciones equivalentes.
Lamentablemente, lo común en 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 |
|---|---|
|
|
Protocolo de tiempo de red
El protocolo de tiempo de red (NTP) se usa con frecuencia para obtener información de é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 de RadioTuner.getParameters(). El NTP actualiza la hora del sistema cuando se desincroniza y un operador no proporcionó una actualización de NITZ recientemente. Si el usuario habilita AUTO_TIME cuando NITZ no está disponible, el sistema verifica de inmediato la hora de red.
| Ventajas | Desventajas |
|---|---|
|
Simplificación, compatible con Android. |
|
Sintonizador de radio de transmisión
Si bien aprovechar un sintonizador integrado para recuperar la información de la hora y la zona horaria es atractivo, implica desafíos. Muchos 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 celular.
En la ETSI EN 300 401 V1.4.1 (2006-06), sección 8.1, se especifican las funciones de información del servicio que proporcionan información complementaria sobre los servicios de programas de audio y datos para los sistemas de transmisión de audio digital (DAB). En el artículo 8.1.3, se define el formato de la hora y la fecha, así como la información del país y la compensación de hora local.
Del mismo modo, para el sistema de datos de radio (RDS) que se implementa comúnmente en los sintonizadores de FM, el artículo 3.1.5.6 del estándar EN 50067 define el formato de 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.
HD Radio contiene las 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 mensaje 0111). En el artículo 5, se indican claramente las advertencias 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 de la misma manera a otros sistemas:
| … estos datos describen la configuración local en la ubicación de la emisora, que puede ser la misma que la configuración local en el lugar del receptor. Cerca de los límites de las zonas horarias, los consumidores pueden recibir una gran cantidad de estaciones que proporcionan datos diferentes. Por lo tanto, estos datos solo se proporcionan como sugerencias, cuya interpretación y uso deben ser discrecionales y estar sujetos 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 depender de ella de forma exclusiva.
Ventajas Desventajas- Por lo general, está disponible en diferentes estándares de radiodifusión regional.
- 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 forma 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 clientes deRadioManager. 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 de proveedor debe determinar que el HAL admite la función (no asumas su existencia). Las cadenas de parámetros para la llamada a getParameters deben estar organizadas de forma clara para que el uso sea inequívoco en todos los proveedores. Por ejemplo, usa el espacio de nombres de tu organización con 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 además de
setParameters. Por ejemplo:
com.me.timezoneTuner.currenttimezoneEvent.enable
Sistema global de navegación satelital
Por sí solo, el sistema global de navegación por satélite (GNSS) solo puede proporcionar información de tiempo y posición precisas.
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. El GNSS es la opción obvia (y de mejor calidad) para la 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 debe solicitarse el permiso del 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 una 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 inversamente el país o la zona horaria en función de la posición del GNSS obtenida del subsistema de ubicación.
| Ventajas | Desventajas |
|---|---|
|
|
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 deben instalar un par de apps personalizadas y complementarias en el teléfono y en el sistema de infoentretenimiento (IVI) del vehículo. 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 compatibles con 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 del perfil de servicio de hora actual 1.1. Sin embargo, esta opción no aborda un segmento de mercado lo suficientemente grande como para depender exclusivamente de él.
| Ventajas | Desventajas |
|---|---|
|
|
Usa fuentes
Cada proveedor de dispositivos debe determinar qué tan alta debe ser la barra y qué recorridos del usuario considerar más importantes. 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 tiene ventajas y desventajas. Por ejemplo, se debe tomar una decisión de diseño crítica con respecto a la cantidad de resiliencia, en comparación con la visualización ocasional de un mal tiempo, y cómo administrar las desventajas. 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 puede proporcionar una disponibilidad del 100%.
Una opción de configuración manual como resguardo temporal es fácil de ejecutar y, en la práctica, puede ser suficiente para muchos usuarios.