La visualización precisa del tiempo es una característica central que se espera de un sistema de información y entretenimiento automotriz. Si bien esto puede parecer engañosamente simple, particularmente cuando las expectativas de administración de la hora y la zona horaria son bajas y deben cumplirse, el tiempo se vuelve rápidamente complejo cuando se debe mostrar una fecha y hora precisas y confiables sin intervención manual.
Todos los relojes en tiempo real que se utilizan normalmente en Systems-on-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 hay muchas expectativas 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), cambie 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 horario de horario de verano en 2019.
Android proporciona la infraestructura necesaria para negociar las complicaciones de la administración de reglas de zona horaria. Para obtener más información, consulte Reglas de zona horaria , que permite a los OEM enviar datos de reglas de zona horaria actualizados a los dispositivos sin necesidad de actualizar el sistema. Este mecanismo permite:
- Usuarios para recibir actualizaciones oportunas (que extienden la vida útil de un dispositivo Android).
- OEM para probar 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 proporcionado en las versiones de Android 10 (y posteriores).
Nota: Para implementar este mecanismo, se requiere reiniciar el sistema.
Fuentes de información horaria (zona) en automóviles
Los dispositivos Android administran la hora en la hora de Unix a nivel del sistema, aplican la compensación de zona horaria deseada y luego convierten el valor a la hora local para mostrárselo a los usuarios. El ID de zona del usuario actual (a menudo denominado ID de Olson) se almacena como una configuración. Por ejemplo, Europa/Londres .
Gran parte del mecanismo descrito 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 compensación y la compensación de horario de verano antes de configurar la ID de la zona.
El proceso puede ser un desafío. El trabajo retroactivo basado en la información disponible puede ser ambiguo. Por ejemplo, la regla de zona horaria América/Denver observa el horario de verano pero adopta el horario de verano de la montaña (MDT) durante el verano, mientras que América/Phoenix continúa reconociendo el horario de verano.
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 el SystemInformationBlockType16 (SIB16) que contiene información relacionada con el GPS y el tiempo universal coordinado (UTC), el desplazamiento de la hora local, así como 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) (consulte 3GPP TS 22.042 para obtener más detalles). Otros estándares de radio celular tienen características equivalentes.
Desafortunadamente, la característica común entre la mayoría de los estándares es que el envío de esta información es opcional y, por lo tanto, no está disponible universalmente en todas las redes.
| ventajas | Contras |
|---|---|
|
|
Protocolo de tiempo de red
El protocolo de tiempo de red (NTP) se usa a menudo para obtener información de tiempo de época de Unix relativamente precisa. Android admite la sincronización de la hora de su sistema con la de un servidor NTP si se puede exponer a los clientes de RadioManager a través del RadioTuner.getParameters() genérico actualiza la hora del sistema cuando no está sincronizado y un operador no ha proporcionado recientemente una actualización 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, 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 radiodifusión proporciona la misma información que una radio celular.
ETSI EN 300 401 V1.4.1 (2006-06), sección 8.1 especifica las funciones de información de servicio que brindan información adicional sobre 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 la hora y la fecha, así como la información sobre el país y la diferencia horaria local.
De manera similar, para el Sistema de datos de radio (RDS) comúnmente implementado en sintonizadores de FM, la sección 3.1.5.6 del estándar EN 50067 define el formato para la hora del reloj y los 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 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ámetros del servicio de información de la estación (SIS) (MSG ID 0111). La Sección 5 explica claramente las palabras de advertencia que deben tenerse en cuenta al intentar utilizar el soporte de 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 del emisor, que puede o no ser la misma 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 brindan diferentes datos. 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, por lo tanto, no debe confiarse exclusivamente en ella.
| ventajas | Contras |
|---|---|
|
|
Consejos de implementación
si se puede exponer a los clientes de RadioManager a través de los metadatos genéricosRadioTuner.getParameters() . Por lo tanto, 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 HAL admita la característica (no asuma su existencia). Las cadenas de parámetros para la llamada getParameters deben estar organizadas de manera limpia para un uso inequívoco entre los proveedores. Por ejemplo, usar el espacio de nombres de su organización prefijándolo con el dominio apropiado como en "com.me.timezoneTuner.currenttimezone"
Dada la naturaleza de la información basada en eventos, puede ser beneficioso utilizar la devolución de llamada RadioTuner.Callback.onParametersUpdated() para recibir esta información. En caso de que esta función deba ser configurable, diseñe un conjunto de rutinas personalizadas además de setParameters . Por ejemplo:
com.me.timezoneTuner.currenttimezoneEvent.enable
Sistema global de navegación por satélite
Por sí solo, el Sistema global de navegación por satélite (GNSS) solo puede proporcionar información (muy) precisa sobre la hora y la posición.
Geolocalización
La solución a este inconveniente es ejecutar una 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 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! El permiso de un usuario para aceptar costos de uso de datos (o no) es requerido y debe ser solicitado.
Es factible crear una solución adecuada para el uso fuera de línea. Una base de datos de mapas locales 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 revertir la geocodificación del país/zona horaria en función de 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 usar 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 debe instalar un par de aplicaciones personalizadas y aplicaciones complementarias en el teléfono y en el sistema de infoentretenimiento 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) brindan la opción de recuperar la hora a través de la característica de hora actual GATT y la especificación 1.1 del perfil de servicio de hora actual . Sin embargo, esta opción no se dirige a un segmento de mercado lo suficientemente grande como para confiar exclusivamente en él.
| ventajas | Contras |
|---|---|
|
|
Usando fuentes
Cada proveedor de dispositivos debe determinar qué tan alto debe establecer el listón y qué viajes de usuario considerar más críticos. Solo 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 compensaciones entre la conveniencia y la complejidad de la implementación.
Cada opción descrita anteriormente presenta ventajas y desventajas. Por ejemplo, se debe hacer una elección de diseño crítica con respecto a cuánta resiliencia, en comparación con la visualización ocasional de tiempo deficiente, es aceptable y cómo manejar las desventajas. Una solución totalmente automática de la 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.