Opções de fuso horário

A exibição precisa do tempo é um recurso essencial esperado de um sistema de infoentretenimento automotivo. Embora isso pareça enganosamente simples, principalmente quando as expectativas de tempo e gerenciamento de fuso horário são baixas e precisam ser atendidas, o tempo se torna rapidamente complexo quando uma data e hora precisas precisam ser mostradas sem intervenção manual.

Todos os relógios em tempo real normalmente usados no sistema em chip (SoC) contêm alguma deriva, que se acumula ao longo do tempo e pode levar a um erro significativo quando não é corrigido. Além disso, como as expectativas são altas para que o horário local seja exibido com precisão, o ajuste correto do Horário Universal Coordenado (UTC) precisa ser considerado.

As informações do fuso horário, assim como a aplicação do horário de verão, podem mudar durante a vida útil esperada de um veículo. Por exemplo, após muitos anos de implementação do horário de verão, o Brasil optou por não iniciar uma programação de horário de verão em 2019.

O Android oferece 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 em tempo hábil, o que prolonga a vida útil de um dispositivo Android.
  • OEMs para testar 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 nas versões do Android 10 (e mais recentes).

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

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

Os dispositivos Android gerenciam o tempo no horário Unix no nível do sistema, aplicam o deslocamento de fuso horário desejado e convertem o valor para o horário local para exibição aos usuários. O ID de 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 tempo. A intenção desses padrões é fornecer aos usuários o horário atual, não descrever as regras de fuso horário aplicáveis. Para determinar o fuso horário atual, o dispositivo precisa trabalhar com fatores como país, deslocamento e deslocamento de horário de verão 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 America/Denver observa o horário de verão, mas adota o horário de verão da montanha (MDT, na sigla em inglês) durante o verão, enquanto America/Phoenix continua reconhecendo o MDT.

Rádio celular

As informações do sistema (SI) são um aspecto essencial da interface aérea 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 deslocamento de horário local e às informações de horário de verão.

Uma funcionalidade semelhante pode ser encontrada em 2G e 3G, em que as informações de identidade de rede e fuso horário (NITZ) podem ser transmitidas. Para mais detalhes, consulte o 3GPP TS 22.042. Outros padrões de rádio celular têm recursos equivalentes.

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

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

  • Não há garantia de que as informações são transmitidas nem de que a estação base está corretamente configurada.

  • Em regiões de fronteira, é possível que a torre de celular (em roaming) de um país vizinho seja detectada, o que pode 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 receber informações de tempo de época Unix relativamente precisas. O Android oferece suporte à sincronização do horário do sistema com o de um servidor NTP se ele puder ser exposto a clientes de RadioManager pelos metadados RadioTuner.getParameters() genéricos. O NTP atualiza a hora do sistema quando ela sai de sincronização e uma operadora não forneceu uma atualização NITZ recentemente. Se o usuário ativar AUTO_TIME quando o NITZ não estiver disponível, o sistema vai verificar imediatamente o tempo da rede.

Prós Contras

Simplicidade com suporte do Android.

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

  • É necessário ter conexão de Internet.

Sintonizador de rádio de transmissão

Embora aproveitar um sintonizador integrado para extrair informações de horário 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. 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 de 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 data e hora, bem como 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 o horário e os dados (transmitidos uma vez por minuto). Além disso, o código de país estendido (ECC, na sigla em inglês) 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 especifica claramente as palavras de advertência que precisam ser observadas ao tentar usar o suporte de relógio da transmissão. O mesmo princípio se aplica 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 várias estações com dados diferentes. Portanto, esses dados são fornecidos apenas como sugestões, cuja interpretação e utilização devem ser feitas de forma discricionária, 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.

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

  • A confiabilidade depende da emissora.

Dicas de implementação

O Android oferece suporte à 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 é aproveitar 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 aos clientes de RadioManager pelo método genérico RadioTuner.getParameters().

Para que a solução continue robusta, o consumidor dessa extensão do fornecedor precisa determinar se a HAL oferece suporte ao recurso (não presuma a existência dele). As strings de parâmetro para a chamada getParameters precisam ser organizadas de forma clara para uso inequívoco entre os fornecedores. Por exemplo, usando o namespace da sua organização com o prefixo do domínio apropriado, por exemplo, com.me.timezoneTuner.currenttimezone.

Dada a natureza orientada a eventos das informações, pode ser benéfico usar o callback RadioTuner.Callback.onParametersUpdated() para receber essas informações. Se essa facilidade precisar ser configurável, projete um conjunto de rotinas personalizadas sobre setParameters. Exemplo:

com.me.timezoneTuner.currenttimezoneEvent.enable

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

Geolocalização

A solução para esse inconveniente é executar a geocodificação reversa e determinar o país e a zona horária 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 é necessária uma conexão de Internet. Garantir a privacidade do usuário deve ser a principal prioridade ao implementar uma solução on-line. A permissão de um usuário para aceitar ou não os custos de uso de dados é 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 o geocódigo reverso do país/fuso horário com base na posição do GNSS obtida do subsistema de localização.

Prós Contras
  • Pode determinar de forma inequívoca o fuso horário correto.
  • Não requer conectividade de Internet (no caso de um banco de dados local).
  • Funciona de forma confiável na maioria dos cenários de direção.
  • O Android não oferece suporte a isso.
  • Se o veículo estiver em ambientes fechados ou em uma área coberta em que não seja possível receber uma boa recepção de satélite GNSS durante a configuração inicial, não será possível receber informações precisas de horário, 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 coletar 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). É possível sincronizar o tempo no intervalo desejado. Por exemplo, ao estabelecer a conexão e quando o smartphone detecta um novo fuso horário.

Alguns smartphones com suporte para Bluetooth de baixa energia (BLE) oferecem a opção de extrair a hora pela característica GATT Current Time e pela especificação do perfil do serviço de hora atual 1.1. No entanto, essa opção não aborda um segmento de mercado suficientemente grande para ser usado exclusivamente.

Prós Contras
  • Não requer conectividade de 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.
  • O tempo é tão bom ou ruim quanto o que o smartphone oferece.
  • 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 o nível de exigência e quais jornadas do usuário são mais importantes. Só com um entendimento claro 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 a conveniência e a complexidade da 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 à 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 funcione bem em todos os cenários, mas que seja baseada em uma combinação de várias fontes de informações. Nenhuma opção pode oferecer disponibilidade de 100%.

Uma opção de configuração manual como substituto temporário é fácil de executar e pode ser suficiente para muitos usuários.