La visualización precisa de la hora es una característica fundamental que se espera de un sistema de información y entretenimiento para automóviles. Si bien esto puede parecer engañosamente simple, particularmente cuando las expectativas de gestión del tiempo y de la zona horaria son bajas y deben cumplirse, el tiempo rápidamente se vuelve complejo cuando se debe mostrar una fecha y hora confiablemente precisas sin intervención manual.
Todos los relojes en tiempo real que se utilizan normalmente en el sistema en chip (SoC) contienen cierta desviación, que se acumula con el tiempo y puede provocar errores importantes si no se corrige. Además, debido a que hay grandes expectativas de que la hora local se muestre con precisión, se debe considerar la diferencia correcta con respecto al tiempo universal coordinado (UTC).
Se puede esperar que la información de zona horaria, así como la aplicación del horario de verano (DST), cambien durante la vida útil prevista de un vehículo. Por ejemplo, después de muchos años de implementar el horario de verano, Brasil decidió no iniciar un horario de horario de verano en 2019.
Android proporciona la infraestructura necesaria para superar las complicaciones de la gestión de reglas de zona horaria. Para obtener más información, consulte Reglas de zona horaria , que permite a los OEM enviar datos actualizados de reglas de zona horaria a los dispositivos sin necesidad de una actualización del sistema. Este mecanismo permite:
- Los usuarios recibirán actualizaciones oportunas (que extienden la vida útil de un dispositivo Android).
- Los OEM probarán las actualizaciones de zona horaria independientemente de las actualizaciones de la imagen del sistema.
Nota: AAOS 10 no es compatible con el mecanismo de actualización del módulo basado en APEX que se proporciona en las versiones de Android 10 (y superiores).
Nota: Para implementar este mecanismo, es necesario reiniciar el sistema.
Fuentes de información horaria (zona) en automóviles.
Los dispositivos Android administran la hora en Unix a nivel del sistema, aplican el desplazamiento de zona horaria deseada y luego convierten el valor a la hora local para mostrarlo a los usuarios. La ID de zona del usuario actual (a menudo denominada ID de Olson) se almacena como una configuración. Por ejemplo, Europa/Londres .
Gran parte del mecanismo que se describe a continuación describe información de tiempo. La intención 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 trabajar a partir de factores como el país, la diferencia y la diferencia de horario de verano antes de configurar la ID de zona.
El proceso puede ser un desafío. Retroceder basándose en la información disponible puede resultar ambiguo. Por ejemplo, la regla de zona horaria América/Denver observa el horario de verano pero adopta el horario de verano de montaña (MDT) durante el verano, mientras que América/Phoenix continúa reconociendo MDT.
radio celular
La información del sistema (SI) es un aspecto esencial de la interfaz aérea de evolución a largo plazo (LTE), que es transmitida por la estación base (BS) a través del canal de control de transmisión (BCCH). 3GPP TS 36.331 especifica SystemInformationBlockType16 (SIB16) que contiene información relacionada con GPS y hora universal coordinada (UTC), compensación de hora local, así como información de 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) (consulte 3GPP TS 22.042 para obtener más detalles). Otros estándares de radio celular tienen características equivalentes.
Desafortunadamente, 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 universalmente en todas las redes.
| Ventajas | Contras |
|---|---|
|
|
Protocolo de tiempo de red
El protocolo de tiempo de red (NTP) se utiliza a menudo para obtener información de tiempo de época Unix relativamente precisa. Android admite la sincronización de la hora de su sistema con la de un servidor NTP si puede exponerse a los clientes de RadioManager a través de los metadatos genéricos RadioTuner.getParameters() . NTP actualiza la hora del sistema cuando no está sincronizado y un operador no ha proporcionado recientemente una actualización de NITZ. Si el usuario habilita AUTO_TIME cuando NITZ no está disponible, el sistema verifica inmediatamente la hora de la red.
| Ventajas | Contras |
|---|---|
Simplicidad, compatible con Android. |
|
Sintonizador de radiodifusión
Si bien aprovechar un sintonizador incorporado para recuperar información sobre la hora y la zona horaria es atractivo, conlleva 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 proporciona la misma información que una radio celular.
ETSI EN 300 401 V1.4.1 (2006-06), sección 8.1 especifica características de información de servicio que proporcionan información complementaria sobre servicios tanto para programas de audio como para datos para sistemas de radiodifusión de audio digital (DAB). La Sección 8.1.3 define el formato de hora y fecha, así como información para el país y la compensación horaria local.
De manera similar, para el sistema de datos de radio (RDS) comúnmente implementado en los sintonizadores de FM, la sección 3.1.5.6 de la norma EN 50067 define el formato de la hora del reloj y los datos (transmitidos una vez por minuto). Además, el código de país ampliado (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 de transporte del servicio de información de la estación de descripción del diseño de la interfaz aérea de HD Radio™ en el mensaje de parámetro del servicio de información de la estación (SIS) (MSG ID 0111). La Sección 5 establece claramente palabras de advertencia que se deben tener en cuenta al intentar utilizar el soporte del reloj de la transmisión. La misma sabiduría se aplica igualmente a otros sistemas:
| ... estos datos describen la costumbre local en el lugar del emisor, que puede ser o no la misma que la costumbre local en el lugar del receptor. Cerca de los límites de los husos horarios, los consumidores pueden recibir una multiplicidad de estaciones que proporcionan datos diferentes. Por lo tanto, estos datos se proporcionan sólo 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 confiar exclusivamente en ella.
- Normalmente está disponible en diferentes estándares de radiodifusión regionales.
- No requiere conectividad a Internet.
- Android no admite esto de fábrica.
- Requiere que el sintonizador esté activado (al menos ocasionalmente en segundo plano) para detectar información de manera confiable.
La confiabilidad depende de la emisora.
Consejos de implementación
Android admite la sincronización de la hora de su sistema con la de un servidor NTP si puede exponerse 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 puede exponerse 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 HAL admite la función (no asuma su existencia). Las cadenas de parámetros para la llamada getParameters deben estar organizadas limpiamente para un uso inequívoco entre proveedores. Por ejemplo, usar el espacio de nombres de su organización prefijándolo con el dominio apropiado, por ejemplo, com.me.timezoneTuner.currenttimezone .
Dada la naturaleza de la información basada en eventos, puede resultar beneficioso utilizar la devolución de llamada RadioTuner.Callback.onParametersUpdated() para recibir esta información. Si esta función debe ser configurable, diseñe un conjunto de rutinas personalizadas además de setParameters . Por ejemplo:
com.me.timezoneTuner.currenttimezoneEvent.enable
Sistema mundial de navegación por satélite
Por sí solo, el Sistema Global de Navegación por Satélite (GNSS) sólo puede proporcionar información precisa sobre la hora y la posición.
Geolocalización
La solución a este inconveniente es ejecutar una codificación geográfica inversa y determinar el país y la zona horaria realizando 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 zona horaria de Google ofrece todo lo que se necesita para ejecutar la conversión requerida. Por supuesto, se requiere conectividad a Internet. ¡Garantizar la privacidad del usuario debe ser una prioridad máxima al implementar una solución en línea! Se requiere y debe solicitarse el permiso de un usuario para aceptar (o no) los costos de uso de datos.
Es factible crear una solución adecuada para uso fuera de línea. Una base de datos de mapas local con suficiente resolución 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 una geocodificación inversa del país/zona horaria según la posición GNSS obtenida del subsistema de Ubicación.
| Ventajas | Contras |
|---|---|
|
|
Teléfono conectado a través de Bluetooth, Wi-Fi o USB
Se pueden utilizar varias tecnologías para aprovechar el teléfono de un usuario para obtener datos de hora y zona horaria. Para todos los teléfonos, se deben instalar un par de aplicaciones personalizadas y aplicaciones complementarias en el teléfono y en el sistema de información y entretenimiento en el vehículo (IVI). Entonces es posible sincronizar la hora en el intervalo deseado. Por ejemplo, al establecer la conexión y cuando el teléfono detecta una nueva zona horaria.
Algunos teléfonos compatibles con Bluetooth Low Energy (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 1.1 del perfil de servicio de hora actual . Sin embargo, esta opción no aborda un segmento de mercado suficientemente grande como para confiar exclusivamente en él.
| Ventajas | Contras |
|---|---|
|
|
Usar fuentes
Cada proveedor de dispositivos debe determinar qué tan alto es el listón y qué recorridos de usuario considera más críticos. Sólo con una comprensión clara de las experiencias de usuario críticas deseadas se puede llegar a la mejor decisión. En la mayoría de los casos, los proveedores deben considerar las ventajas y desventajas entre conveniencia y complejidad de implementación.
Cada opción descrita anteriormente plantea 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 una mala visualización ocasional del tiempo, es aceptable y cómo gestionar las desventajas. Una solución totalmente automática que se puede esperar que funcione bien en todos los escenarios, pero que debe basarse en una combinación de varias fuentes de información. Ninguna opción por sí sola puede proporcionar el 100% de disponibilidad.
Una opción de configuración manual como respaldo temporal es fácil de ejecutar y, en la práctica, puede ser suficiente para muchos usuarios.