A exibição precisa do tempo é um recurso central esperado de um sistema de infoentretenimento automotivo. Embora isso possa parecer enganosamente simples, especialmente quando as expectativas de gerenciamento de tempo e fuso horário são baixas e devem 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 em Systems-on-Chip (SoC) contêm algum desvio, que se acumula com o tempo e pode levar a erros significativos quando não corrigidos. Além disso, como as expectativas são altas de que o horário local seja exibido 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, depois de muitos anos implementando o horário de verão, o Brasil optou por não iniciar um cronograma de horário de verão em 2019.
O Android fornece a infraestrutura necessária para negociar as complicações do gerenciamento de regras de fuso horário. Para obter 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. Este mecanismo permite:
- Os usuários recebem atualizações oportunas (que prolongam a vida útil de um dispositivo Android).
- OEMs para 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 superior).
Observação: para implementar esse mecanismo, é necessária uma reinicialização do sistema.
Fontes de informação de tempo (zona) 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 a hora local para exibição aos usuários. O ID da zona do usuário atual (muitas vezes referido como ID Olson) é 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, não descrever as regras de fuso horário aplicáveis. Para determinar o fuso horário real, o dispositivo deve voltar a partir de fatores como país, deslocamento e deslocamento do horário de verão antes de definir a ID da zona.
O processo pode ser um desafio. Voltar a 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 das montanhas (MDT) durante o verão, enquanto America/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) pelo 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 têm recursos equivalentes.
Infelizmente, a semelhança entre a maioria dos padrões é que o envio dessas informações é opcional e, portanto, não está disponível universalmente em todas as redes.
| Prós | Contras |
|---|---|
|
|
Protocolo de tempo de rede
Network Time Protocol (NTP) é freqüentemente usado para obter informações relativamente precisas de tempo de época do Unix. O Android oferece suporte à sincronização do horário do sistema com o de um servidor NTP se puder ser exposto aos clientes do RadioManager por meio do genérico RadioTuner.getParameters() atualiza o horário do sistema quando 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. |
|
Sintonizador de rádio de transmissão
Embora seja atraente aproveitar um sintonizador integrado para recuperar informações de fuso horário e horário, há desafios envolvidos. Numerosos padrões de transmissão de rádio definem opções para expor as informações desejadas. De um modo geral, um sintonizador de rádio broadcast 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 suplementares 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 as informações de diferença de horário local e do país.
Da mesma forma, para o sistema de dados de rádio (RDS) comumente implementado em sintonizadores de FM, a seção 3.1.5.6 do padrão EN 50067 define o formato 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 as opções correspondentes como parte da descrição do design da interface aérea do HD Radio™, especificação de transporte do serviço de informações da estação na mensagem de parâmetro do serviço de informações da estação (SIS) (MSG ID 0111). A Seção 5 descreve claramente as palavras de advertência que devem ser observadas 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 que o costume local no local do receptor. Perto dos limites do fuso horário, os consumidores podem receber uma multiplicidade de estações fornecendo dados diferentes. Portanto, esses dados são fornecidos apenas como dicas, cuja interpretação e utilização devem ser feitas de forma discricionária, sujeitas ao controle do cliente. …" |
Além disso, pelo menos para HD Radio, a transmissão dessas informações é opcional e, portanto, não deve ser considerada exclusivamente.
| Prós | Contras |
|---|---|
|
|
dicas de implementação
if pode ser exposto aos clientes do RadioManager através dos metadados genéricosRadioTuner.getParameters() . Portanto, a solução recomendada é aproveitar o recurso de extensão do fornecedor. A implementação dessa funcionalidade deve ocorrer na camada de abstração de hardware (HAL), após a qual pode ser exposta aos clientes do RadioManager por meio do método genérico RadioTuner.getParameters() . Para que a solução permaneça robusta, o consumidor dessa extensão de fornecedor deve determinar que o HAL oferece suporte ao recurso (não assuma 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 de sua organização prefixando-o com o domínio apropriado como em "com.me.timezoneTuner.currenttimezone"
Dada a natureza orientada a eventos das informações, pode ser benéfico usar o retorno de chamada RadioTuner.Callback.onParametersUpdated() para receber essas informações. Caso esse recurso deva ser configurável, crie um conjunto de rotinas customizadas sobre setParameters . Por exemplo:
com.me.timezoneTuner.currenttimezoneEvent.enable
Sistema Global de Navegação por Satélite
Por si só, o Sistema Global de Navegação por Satélite (GNSS) só pode fornecer informações de tempo (muito) precisas, bem como a posição.
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 de fuso horário do Google oferece tudo o que é necessário para executar a conversão necessária. Claro, a conectividade com a Internet é necessária. Garantir a privacidade do usuário deve ser uma prioridade ao implementar uma solução online! A permissão de um usuário para aceitar os custos de uso de dados (ou não) é 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, pode-se fazer geocodificação reversa do país/fuso horário com base na posição GNSS obtida do subsistema de localização.
| Prós | Contras |
|---|---|
|
|
Telefone conectado via Bluetooth, Wi-Fi ou USB
Várias tecnologias podem ser usadas para alavancar 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 In-Vehicle Infotainment (IVI). É então possível sincronizar o tempo 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 GATT Current Time e da Current Time Service Profile Specification 1.1 . No entanto, esta opção não atende a um segmento de mercado suficientemente grande para ser invocado exclusivamente.
| Prós | Contras |
|---|---|
|
|
Usando fontes
Cada fornecedor de dispositivo deve determinar o quão alto um padrão deve ser definido e quais jornadas do usuário devem ser consideradas mais críticas. Somente com uma compreensão clara das experiências críticas do usuário desejadas, a melhor decisão pode ser tomada. 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 com relação a quanta resiliência, em comparação com a exibição ocasional de tempo ruim, é aceitável e como gerenciar as desvantagens. Uma solução totalmente automática que pode funcionar bem em todos os cenários, mas deve ser baseada em uma combinação de várias 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.