Opções de fuso horário

A exibição precisa da hora é um recurso essencial esperado de um sistema de infoentretenimento automotivo. Embora isso possa parecer enganosamente simples, principalmente quando as expectativas de tempo e gerenciamento de fuso horário são baixas e precisam ser atendidas, o tempo rapidamente se torna complexo 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 em sistemas em chip (SoC) têm algum desvio, que se acumula com o tempo e pode levar a erros significativos quando não é corrigido. Além disso, como as expectativas de que o horário local seja mostrado com precisão são altas, é necessário considerar o ajuste correto do Tempo Universal Coordenado (UTC).

As informações de fuso horário, bem como a aplicação do horário de verão (DST, na sigla em inglês), podem mudar durante a vida útil esperada de um veículo. Por exemplo, depois de muitos anos implementando o horário de verão, o Brasil decidiu não iniciar um cronograma de horário de verão 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:

  • Os usuários recebem atualizações oportunas, o que aumenta a vida útil de um dispositivo Android.
  • OEMs para testar atualizações de fuso horário independentemente das atualizações da imagem do sistema.

Observação:o AAOS 10 não é compatível com o mecanismo de atualização de módulos 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 o tempo no formato 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 Olson) é armazenado como uma configuração. Por exemplo, Europe/London.

Grande parte do mecanismo descrito abaixo descreve informações de tempo. 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 base em fatores como país, ajuste e ajuste de horário de verão antes de definir o ID da zona.

O processo pode ser difícil. Trabalhar com base nas informações disponíveis pode ser ambíguo. Por exemplo, a regra de fuso horário America/Denver segue o horário de verão, mas adota o horário de verão das Montanhas (MDT) durante o verão, enquanto America/Phoenix continua reconhecendo o MDT.

Rádio celular

As informações do sistema (SI, na sigla em inglês) são um aspecto essencial da interface aérea de Long-Term Evolution (LTE), transmitida pela estação base (BS) no 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 horário local e ao horário de verão.

Funcionalidade semelhante pode ser encontrada em 2G e 3G, em que a identidade da rede e as informações de 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 maioria dos padrões tem em comum o fato de que o envio dessas informações é opcional, então elas não estão disponíveis universalmente em todas as redes.

Prós Contras
  • Quando disponível, fornece a maior parte das informações desejadas.
  • Simplicidade, já compatível com o 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á garantia de que as informações serão transmitidas nem de que a estação base está 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 concluídas.

Network Time Protocol

O Network Time Protocol (NTP) é usado com frequência para obter informações relativamente precisas sobre a época do Unix. O Android é compatível com a sincronização do horário do sistema com o de um servidor NTP se puder ser exposto a clientes de RadioManager pelos metadados RadioTuner.getParameters() genéricos. O NTP atualiza a hora do sistema quando ela sai de sincronia 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 a hora 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.

  • É necessário ter conectividade com a Internet.

Sintonizador de rádio de transmissão

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

A ETSI EN 300 401 V1.4.1 (2006-06), seção 8.1 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, na sigla em inglês). A seção 8.1.3 define o formato de hora e data, além de informações sobre o país e o fuso horário local.

Da mesma forma, para o Sistema de dados de rádio (RDS, na sigla em inglês) comumente implementado em sintonizadores de FM, a seção 3.1.5.6 do padrão EN 50067 define o formato para hora e dados (transmitidos uma vez por minuto). Além disso, o código do 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 especificação HD Radio™ Air Interface Design Description Station Information Service Transport na mensagem de parâmetro do serviço de informações da estação (SIS, na sigla em inglês) (ID da mensagem 0111). A seção 5 explica claramente as palavras de alerta que devem ser seguidas ao tentar usar o suporte de relógio da transmissão. A mesma sabedoria se aplica igualmente a outros sistemas:

... esses dados descrevem o costume local no local da emissora, que pode ou não ser o mesmo do local do destinatário. Perto dos limites de fusos horários, os consumidores podem receber várias estações que fornecem dados diferentes. Portanto, esses dados são fornecidos apenas como dicas, e a interpretação e utilização deles devem ser feitas de forma discricionária, sujeitas ao controle do cliente. ..."

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

Vantagens Desvantagens
  • Normalmente disponível em diferentes padrões regionais de rádio.
  • Não exige conectividade com a Internet.
  • O Android não oferece suporte a isso de imediato.
  • Exige que o sintonizador esteja ativado (pelo menos ocasionalmente em segundo plano) para detectar informações de forma confiável.

  • A confiabilidade depende da emissora.

Dicas de implementação

O Android é compatível com a sincronização do tempo do sistema com o de um servidor NTP se ele 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, na sigla em inglês). Depois disso, ela pode ser exposta aos clientes de RadioManager pelo método genérico RadioTuner.getParameters().

Para que a solução continue robusta, o consumidor dessa extensão de 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 forma clara para uso sem ambiguidade em todos os fornecedores. Por exemplo, usando o namespace da sua organização ao prefixar 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 recebê-las. Se essa facilidade precisar ser configurável, crie um conjunto de rotinas personalizadas com base em setParameters. Exemplo:

com.me.timezoneTuner.currenttimezoneEvent.enable

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

Geolocalização

A solução para esse inconveniente é executar a geocodificação inversa e determinar o país e o fuso horário fazendo uma pesquisa com base na posição. O GNSS é a opção ó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 exigida. É claro que é necessário ter conectividade com a Internet. Garantir a privacidade do usuário deve ser uma prioridade ao implementar uma solução on-line. É necessário pedir a permissão de um usuário para aceitar (ou não) os custos de uso de dados.

É possível criar uma solução adequada para uso off-line. Um banco de dados de mapas local com resolução suficiente para determinar com precisão o país e o fuso horário pode ser armazenado em 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 do subsistema de localização.

Prós Contras
  • Pode determinar sem ambiguidade 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 de imediato.
  • Se o veículo estiver em um local coberto ou em um ambiente interno em que não é possível ter uma boa recepção de satélite GNSS durante a configuração inicial, não será possível obter 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 e obter dados de hora e fuso horário. Em todos os smartphones, um par de apps personalizados e complementares precisa estar instalado no smartphone e no sistema de infoentretenimento no veículo (IVI). Depois, é possível sincronizar o tempo no intervalo desejado. Por exemplo, ao estabelecer a conexão e quando o smartphone detecta uma nova no fuso horário.

Alguns smartphones compatíveis com Bluetooth de baixa energia (BLE) oferecem a opção de recuperar a hora usando a característica de hora atual do GATT e a especificação do perfil do serviço de hora atual 1.1. No entanto, essa opção não atende a um segmento de mercado grande o suficiente 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 à unidade principal.
  • O Android não oferece suporte a isso de imediato.
  • Funciona apenas enquanto o smartphone está conectado à unidade principal.
  • A hora é tão boa ou ruim quanto o que o smartphone oferece.
  • A implementação é complexa.
  • Nem todos os smartphones são compatíveis com o perfil do serviço de hora atual do GATT BLE.

Usar fontes

Cada fornecedor de dispositivo precisa determinar o nível de exigência e quais jornadas do usuário são mais críticas. Só com uma compreensão clara das experiências críticas 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 tem vantagens e desvantagens. Por exemplo, uma escolha de design crítica precisa ser feita em relação à quantidade de resiliência aceitável em comparação com a exibição ocasional de tempo ruim 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ção. Nenhuma opção única pode oferecer 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.