Opções de fuso horário

A exibição precisa da hora é um recurso principal esperado de um sistema de infoentretenimento automotivo. Embora isso possa parecer enganosamente simples, principalmente quando as expectativas de gerenciamento de hora e fuso horário são baixas e precisam ser atendidas, a hora rapidamente se torna complexa quando uma data e hora confiáveis e precisas precisam ser exibidas sem intervenção manual.

Todos os relógios em tempo real normalmente usados no system on chip (SoC) contêm algum desvio, que se acumula ao longo do tempo e pode levar a erros significativos quando não corrigidos. Além disso, como as expectativas são altas de que a hora local seja exibida com precisão, o ajuste correto do Tempo Universal Coordenado (UTC) precisa ser considerado.

As informações de fuso horário, bem como a aplicação do horário de verão (DST), podem mudar durante a vida útil esperada de um veículo. Por exemplo, depois de muitos anos implementando o DST, o Brasil optou por não iniciar um cronograma de DST em 2019.

O Android fornece a infraestrutura necessária para negociar complicações do gerenciamento de regras de fuso horário. Para mais detalhes, consulte Regras de fuso horário, que permite que os OEMs enviem dados de regras de fuso horário atualizados para dispositivos sem exigir uma atualização do sistema. Esse mecanismo permite:

  • Que os usuários recebam atualizações em tempo hábil (que estendem a vida útil de um dispositivo Android).
  • Que os OEMs testem as atualizações de fuso horário independentemente das atualizações da imagem do sistema.

Observação:o AAOS 10 não oferece suporte ao mecanismo de atualização de módulo baseado em APEX fornecido em versões do Android 10 (e mais recentes).

Observação:para implementar esse mecanismo, é necessário reiniciar o sistema.

Fontes de informações de hora (fuso horário) em carros

Os dispositivos Android gerenciam a hora no horário Unix no nível do sistema, aplicam o ajuste de fuso horário desejado e convertem o valor para a hora local para exibição aos usuários. O ID da zona do usuário atual (geralmente chamado de ID de Olson) é armazenado como uma configuração. Por exemplo, Europe/London.

Grande parte do mecanismo descrito abaixo descreve informações de hora. O objetivo desses padrões é fornecer aos usuários a hora atual, não descrever as regras de fuso horário aplicáveis. Para determinar o fuso horário real, o dispositivo precisa trabalhar com fatores como país, ajuste e ajuste de DST antes de definir o ID da zona.

O processo pode ser um desafio. Trabalhar com base nas informações disponíveis pode ser ambíguo. Por exemplo, a regra de fuso horário América/Denver observa o DST, mas adota o horário de verão das montanhas (MDT) durante o verão, enquanto América/Phoenix continua reconhecendo o MDT.

Rádio celular

As informações do sistema (SI) são um aspecto essencial da interface aérea de Long-Term Evolution (LTE), que é transmitida pela estação base (BS) pelo canal de controle de transmissão (BCCH). O 3GPP TS 36.331 especifica o SystemInformationBlockType16 (SIB16), que contém informações relacionadas ao GPS e ao Tempo Universal Coordenado (UTC), ao ajuste de tempo local e às informações de DST.

Funcionalidades semelhantes podem ser encontradas em 2G e 3G, em que as informações de identidade de rede e fuso horário (NITZ) podem ser transmitidas (consulte 3GPP TS 22.042 para mais detalhes). Outros padrões de rádio celular têm recursos equivalentes.

Infelizmente, a característica comum entre a maioria dos padrões é que o envio dessas informações é opcional, portanto, não está universalmente disponível em todas as redes.

Prós Contras
  • Quando disponível, fornece a maioria das informações desejadas.
  • Simplicidade, já com suporte do Android quando o rádio celular é exposto como um smartphone, não apenas como um modem de dados.
  • Não exige conectividade com a Internet.

  • Não há garantias de que as informações sejam transmitidas nem de que a estação base esteja configurada corretamente.

  • Em regiões de fronteira, é possível captar uma torre de celular (em roaming) de um país vizinho e transmitir o fuso horário errado.

  • Em alguns locais, as atualizações podem levar horas ou até dias para serem feitas.

Network Time Protocol

O Network Time Protocol (NTP) é usado com frequência para receber informações de horário de época Unix relativamente precisas. O Android oferece suporte à sincronização do horário do sistema com o de um servidor NTP se puder ser exposto a clientes de RadioManager pelos metadados genéricos RadioTuner.getParameters(). O NTP atualiza o horário do sistema quando ele fica dessincronizado e uma operadora não forneceu uma atualização do NITZ recentemente. Se o usuário ativar AUTO_TIME quando o NITZ não estiver disponível, o sistema vai verificar imediatamente o horário da rede.

Prós Contras

Simplicidade, com suporte do Android.

  • Incompleto, o NTP fornece apenas um valor necessário (hora). Mesmo no melhor cenário, o NTP não pode fornecer o fuso horário.

  • Exige conectividade com a Internet.

Sintonizador de rádio de transmissão

Embora o uso de um sintonizador integrado para recuperar informações de hora e fuso horário seja interessante, há desafios envolvidos. Vários padrões de transmissão de rádio definem opções para expor as informações desejadas. De modo geral, um sintonizador de rádio de transmissão fornece as mesmas informações que um rádio celular.

A seção 8.1 da ETSI EN 300 401 V1.4.1 (2006-06) especifica recursos de informações de serviço que fornecem informações complementares sobre serviços para programas de áudio e dados para sistemas de transmissão de áudio digital (DAB). A seção 8.1.3 define o formato de data e hora, bem como informações sobre o país e o ajuste de tempo local.

Da mesma forma, para o Radio Data System (RDS) comumente implementado em sintonizadores FM, a seção 3.1.5.6 do padrão EN 50067 define o formato de hora e dados do relógio (transmitidos uma vez por minuto). Além disso, o código de país estendido (ECC) também pode ser recuperado como parte da identificação do programa transmitido.

O HD Radio contém opções correspondentes como parte da descrição de design de interface aérea HD Radio™ especificação de transporte de serviço de informações de estação na mensagem de parâmetro de serviço de informações de estação (SIS) (ID de mensagem 0111). A seção 5 explica claramente as palavras de advertência que precisam ser consideradas ao tentar usar o suporte de relógio da transmissão. A mesma lógica se aplica igualmente a outros sistemas:

... esses dados descrevem o costume local no local da emissora, que pode ou não ser o mesmo que o costume local no local do receptor. Perto dos limites de fuso horário, os consumidores podem receber uma multiplicidade de estações que fornecem dados diferentes. Portanto, esses dados são fornecidos apenas como dicas, cuja interpretação e utilização devem ser discricionárias, sujeitas ao controle do cliente. ..."

Além disso, pelo menos para o HD Radio, a transmissão dessas informações é opcional e não deve ser usada exclusivamente.

Prós Contras
  • Normalmente disponível em diferentes padrões regionais de rádio de transmissão.
  • Não exige conectividade com a Internet.
  • O Android não oferece suporte a isso.
  • Exige que o sintonizador seja ativado (pelo menos ocasionalmente em segundo plano) para detectar informações de maneira confiável.

  • A confiabilidade depende da emissora.

Dicas de implementação

O Android oferece suporte à sincronização do horário do sistema com o de um servidor NTP se puder ser exposto a clientes de RadioManager. A solução recomendada é usar o recurso de extensão do fornecedor. A implementação dessa funcionalidade precisa ocorrer na camada de abstração de hardware (HAL), após a qual ela pode ser exposta a clientes de RadioManager pelo método genérico RadioTuner.getParameters().

Para que a solução permaneça robusta, o consumidor dessa extensão do fornecedor precisa determinar se a HAL oferece suporte ao recurso (não presuma que ele exista). As strings de parâmetro para a chamada getParameters precisam ser organizadas de maneira limpa para uso inequívoco em todos os fornecedores. Por exemplo, usando o namespace da sua organização, prefixando-o com o domínio apropriado, por exemplo, com.me.timezoneTuner.currenttimezone.

Devido à natureza orientada a eventos das informações, pode ser útil usar o callback RadioTuner.Callback.onParametersUpdated() para receber essas informações. Se essa instalação puder ser configurada, crie um conjunto de rotinas personalizadas acima de setParameters. Por exemplo:

com.me.timezoneTuner.currenttimezoneEvent.enable

Por si só, o Sistema Global de Navegação por Satélite (GNSS) só pode fornecer informações de hora e posição precisas.

Geolocalização

A solução para esse inconveniente é executar a geocodificação reversa e determinar o país e o fuso horário fazendo uma pesquisa com base na posição. O GNSS é a escolha óbvia (e de melhor qualidade) de informações de localização em um veículo. A API Time Zone do Google oferece tudo o que é necessário para executar a conversão necessária. É claro que a conectividade com a Internet é necessária. Garantir a privacidade do usuário precisa ser uma prioridade ao implementar uma solução on-line. A permissão de um usuário para aceitar custos de uso de dados (ou não) é necessária e precisa ser solicitada.

É possível criar uma solução adequada para uso off-line. Um banco de dados de mapa local com resolução suficiente para determinar com precisão o país e o fuso horário pode caber no armazenamento de um veículo. Com isso e uma estratégia totalmente implementada para atualizar as informações de fuso horário (e país) conforme necessário, é possível fazer a geocodificação reversa do país/fuso horário com base na posição do GNSS obtida no subsistema de localização.

Prós Contras
  • Pode determinar de maneira inequívoca o fuso horário correto.
  • Não exige conectividade com a Internet (no caso de um banco de dados local).
  • Funciona de maneira confiável na maioria dos cenários de direção.
  • O Android não oferece suporte a isso.
  • Se o veículo estiver em um local fechado/uma área coberta em que uma boa recepção de satélite GNSS não seja possível durante a configuração inicial, será impossível receber informações precisas de hora, local, e fuso horário.
  • O banco de dados local precisa de um mecanismo de atualização.
  • Complexidade da implementação.

Smartphone conectado por Bluetooth, Wi-Fi ou USB

Várias tecnologias podem ser usadas para aproveitar o smartphone de um usuário para receber dados de hora e fuso horário. Para todos os smartphones, um par de apps personalizados e complementares precisa ser instalado no smartphone e no sistema de infoentretenimento no veículo (IVI). Em seguida, é possível sincronizar a hora no intervalo desejado. Por exemplo, ao estabelecer a conexão e quando o smartphone detecta um novo fuso horário.

Alguns smartphones que oferecem suporte ao Bluetooth de baixa energia (BLE) oferecem a opção de recuperar a hora pela característica de hora atual do GATT e pela especificação do perfil de serviço de hora atual 1.1. No entanto, essa opção não atende a um segmento de mercado suficientemente grande para ser usada exclusivamente.

Prós Contras
  • Não exige conectividade com a Internet.
  • As mudanças de fuso horário detectadas pelo smartphone podem ser transmitidas para a unidade principal.
  • O Android não oferece suporte a isso.
  • Funciona apenas enquanto o smartphone está conectado à unidade principal.
  • A hora é tão boa ou ruim quanto o que o smartphone fornece.
  • A implementação é complexa.
  • Nem todos os smartphones oferecem suporte ao perfil de serviço de hora atual do BLE GATT.

Usar fontes

Cada fornecedor de dispositivo precisa determinar qual é o nível de exigência e quais jornadas do usuário são consideradas mais importantes. Somente com uma compreensão clara das experiências críticas do usuário desejadas é possível chegar à melhor decisão. Na maioria dos casos, os fornecedores precisam considerar as vantagens e desvantagens entre conveniência e complexidade de implementação.

Cada opção descrita acima apresenta vantagens e desvantagens. Por exemplo, uma escolha de design crítica precisa ser feita em relação à resiliência, em comparação com a exibição de hora ruim ocasional, e como gerenciar as desvantagens. Uma solução totalmente automática que pode funcionar bem em todos os cenários, mas precisa ser baseada em uma combinação de várias fontes de informações. Nenhuma opção pode fornecer 100% de disponibilidade.

Uma opção de configuração manual como um fallback temporário é fácil de executar e pode, na prática, ser suficiente para muitos usuários.