Opções de fuso horário

A exibição precisa do tempo é um recurso essencial esperado de um sistema de infoentretenimento automotivo. Embora isso possa parecer aparentemente simples, especialmente quando as expectativas de gerenciamento de horário e fuso horário são baixas e precisam ser atendidas, o tempo rapidamente se torna complexo quando uma data e hora precisas e confiáveis ​​devem ser exibidas sem intervenção manual.

Todos os relógios de tempo real normalmente usados ​​no sistema no chip (SoC) contêm algum desvio, que se acumula ao longo do tempo e pode levar a erros significativos quando não corrigido. Além disso, como são altas as expectativas de que a hora local seja exibida com precisão, o deslocamento correto do Tempo Universal Coordenado (UTC) deve 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, 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 fornece a infraestrutura necessária para lidar com as complicações do gerenciamento de regras de fuso horário. Para obter detalhes, consulte Regras de fuso horário , que permitem que os OEMs enviem dados atualizados de regras de fuso horário para dispositivos sem exigir uma atualização do sistema. Este mecanismo permite:

  • Os usuários receberão atualizações oportunas (que prolongam a vida útil de um dispositivo Android).
  • OEMs devem testar atualizações de fuso horário independentemente das atualizações de 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 superiores).

Nota: Para implementar este mecanismo, é necessária uma reinicialização do sistema.

Fontes de informação de horário (fuso) em carros

Os dispositivos Android gerenciam o horário no horário Unix no nível do sistema, aplicam o deslocamento de fuso horário desejado e, em seguida, 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 Olson ID) é armazenado como uma configuração. Por exemplo, Europa/Londres .

Grande parte do mecanismo descrito abaixo descreve informações de tempo. A intenção desses padrões é fornecer aos usuários a hora atual e não descrever as regras de fuso horário aplicáveis. Para determinar o fuso horário real, o dispositivo deve trabalhar a partir de 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 América/Denver observa o horário de verão, mas adota o horário de verão das montanhas (MDT) durante o verão, enquanto América/Phoenix continua a reconhecer o MDT.

Rádio celular

A informação do sistema (SI) é um aspecto essencial da interface aérea Long-Term Evolution (LTE), que é transmitida pela estação base (BS) através do canal de controle de transmissão (BCCH). 3GPP TS 36.331 especifica o SystemInformationBlockType16 (SIB16) que contém informações relacionadas a GPS e Tempo Universal Coordenado (UTC), deslocamento de horário local, bem como informações de horário de verão.

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

Infelizmente, o ponto em comum entre a maioria dos padrões é que o envio desta informação é opcional, por isso 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á suportada pelo Android quando o rádio celular é exposto como telefone, não apenas como modem de dados.
  • Não requer 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.

  • Nas regiões fronteiriças, é possível captar uma torre de celular (roaming) de um país vizinho e potencialmente transmitir o fuso horário errado.

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

Protocolo de horário de rede

O Network Time Protocol (NTP) é frequentemente usado para obter informações de tempo de época Unix relativamente precisas. O Android suporta a sincronização da hora do sistema com a de um servidor NTP se puder ser exposto aos clientes do RadioManager por meio dos metadados genéricos RadioTuner.getParameters() . O NTP atualiza a hora do sistema quando ele fica fora de sincronia e uma operadora não forneceu recentemente uma atualização do NITZ. Se o usuário ativar AUTO_TIME quando NITZ não estiver disponível, o sistema verificará imediatamente o horário da rede.

Prós Contras

Simplicidade, suportada pelo Android.

  • Incompleto, o NTP fornece apenas um valor necessário (tempo). Mesmo na melhor das hipóteses, o NTP não pode fornecer o fuso horário.

  • Requer conectividade com a Internet.

Sintonizador de rádio de transmissão

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

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). A Seção 8.1.3 define o formato de hora e data, bem como informações sobre a diferença de horário do país e local.

Da mesma forma, para o Radio Data System (RDS) comumente implementado em sintonizadores FM, a seção 3.1.5.6 da norma EN 50067 define o formato da hora do relógio e dos dados (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 especificação de transporte do serviço de informações da estação, descrição do projeto da interface aérea do HD Radio™, na mensagem de parâmetro do serviço de informações da estação (SIS) (MSG ID 0111). A Seção 5 explicita claramente palavras de advertência que devem ser atendidas 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 igual ao costume local no local do receptor. Perto dos limites do fuso horário, os consumidores podem receber uma multiplicidade de estações que fornecem dados diferentes. Portanto, estes 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 HD Radio, a transmissão desta informação é opcional e não deve ser considerada exclusiva.

Prós Contras
  • Normalmente disponível em diferentes padrões regionais de rádio de transmissão.
  • Não requer conectividade com a Internet.
  • O Android não suporta isso imediatamente.
  • Requer que o sintonizador esteja ligado (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 suporta a sincronização da hora do sistema com a de um servidor NTP se puder ser exposto a clientes do RadioManager . A solução recomendada é aproveitar o recurso de extensão do fornecedor. A implementação desta funcionalidade deve ocorrer na camada de abstração de hardware (HAL), após a qual pode ser exposta aos clientes do RadioManager através do método genérico RadioTuner.getParameters() .

Para que a solução permaneça robusta, o consumidor desta extensão do fornecedor deve determinar se o HAL suporta o recurso (não assuma a sua existência). As sequências de parâmetros para a chamada getParameters devem ser organizadas de forma limpa para uso inequívoco entre fornecedores. Por exemplo, usando o namespace da sua organização prefixando-o com o domínio apropriado, por exemplo, com.me.timezoneTuner.currenttimezone .

Dada a natureza das informações orientada a eventos, pode ser benéfico usar o retorno de chamada RadioTuner.Callback.onParametersUpdated() para receber essas informações. Se esse recurso for configurável, projete um conjunto de rotinas customizadas sobre setParameters . Por exemplo:

com.me.timezoneTuner.currenttimezoneEvent.enable

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

Geolocalização

A solução para este inconveniente é executar a geocodificação reversa e determinar o país e o fuso horário fazendo uma pesquisa baseada na posiçã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, é necessária conectividade com a Internet. Garantir a privacidade do usuário deve ser uma prioridade máxima ao implementar uma solução online! A permissão de um usuário para aceitar (ou não) custos de uso de dados é necessária e deve ser solicitada.

É viável criar uma solução adequada para uso offline. Um banco de dados de mapas locais 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 geocodificar reversamente o país/fuso horário com base na posição GNSS obtida do subsistema Localização.

Prós Contras
  • Pode determinar inequivocamente o fuso horário correto.
  • Não requer conectividade com a Internet (no caso de banco de dados local).
  • Funciona de forma confiável na maioria dos cenários de direção.
  • O Android não suporta isso imediatamente.
  • Se o veículo estiver em um ambiente interno/área coberta onde não seja possível uma boa recepção de satélite GNSS durante a configuração inicial, será impossível obter informações precisas sobre hora, localização e fuso horário.
  • O banco de dados local precisa de um mecanismo de atualização.
  • Complexidade de implementação.

Telefone conectado via Bluetooth, Wi-Fi ou USB

Várias tecnologias podem ser usadas para aproveitar o telefone de um usuário para obter dados de horário e fuso horário. Para todos os telefones, um par de aplicativos personalizados e aplicativos complementares devem ser instalados no telefone e no sistema de informação e entretenimento no veículo (IVI). É então possível sincronizar a hora no intervalo desejado. Por exemplo, ao estabelecer a conexão e quando o telefone detecta um novo fuso horário.

Alguns telefones que suportam Bluetooth Low Energy (BLE) oferecem a opção de recuperar a hora por meio da característica de hora atual do GATT e da especificação de perfil de serviço de hora atual 1.1 . No entanto, esta opção não abrange um segmento de mercado suficientemente vasto para ser exclusivamente invocado.

Prós Contras
  • Não requer conectividade com a Internet.
  • As alterações de fuso horário detectadas pelo telefone podem ser retransmitidas para a unidade principal.
  • O Android não suporta isso imediatamente.
  • Funciona apenas enquanto o telefone está conectado à unidade principal.
  • O tempo é tão bom ou ruim quanto o que o telefone oferece.
  • A implementação é complexa.
  • Nem todos os telefones suportam o perfil BLE GATT Current Time Service.

Usar fontes

Cada fornecedor de dispositivos deve determinar o nível de exigência a ser definido e quais jornadas do usuário considerar mais críticas. Somente com uma compreensão clara das experiências críticas desejadas do usuário é que se pode chegar à melhor decisão. Na maioria dos casos, os fornecedores devem considerar as compensações entre conveniência e complexidade de implementação.

Cada opção descrita acima apresenta vantagens e desvantagens. Por exemplo, uma escolha crítica de design deve ser feita em relação a quanta resiliência, em comparação com uma exibição ocasional de tempo ruim, é aceitável e como gerenciar as desvantagens. Uma solução totalmente automática que possa funcionar bem em todos os cenários deve, no entanto, basear-se numa combinação de diversas fontes de informação. Nenhuma opção pode fornecer 100% de disponibilidade.

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