Opcje strefy czasowej

Dokładne wyświetlanie czasu to główna funkcja, której oczekuje się od samochodowego systemu multimedialnego. Może się to wydawać proste, zwłaszcza gdy oczekiwania dotyczące zarządzania czasem i strefą czasową są niskie i muszą zostać spełnione. Jednak gdy trzeba wyświetlać wiarygodną i dokładną datę oraz godzinę bez ręcznej interwencji, czas szybko staje się złożony.

Wszystkie zegary czasu rzeczywistego zwykle używane w układach SOC (system on chip) mają pewne odchylenie, które z czasem się kumuluje i może prowadzić do znacznych błędów, jeśli nie zostanie skorygowane. Ponadto, ponieważ oczekiwania dotyczące dokładnego wyświetlania czasu lokalnego są wysokie, należy uwzględnić prawidłowe przesunięcie względem uniwersalnego czasu koordynowanego (UTC).

Informacje o strefie czasowej oraz stosowanie czasu letniego mogą się zmieniać w przewidywanym okresie eksploatacji pojazdu. Na przykład po wielu latach stosowania czasu letniego Brazylia zdecydowała, że w 2019 r. nie będzie go wprowadzać.

Android zapewnia infrastrukturę potrzebną do radzenia sobie ze złożonością zarządzania regułami stref czasowych. Więcej informacji znajdziesz w artykule Reguły stref czasowych, który umożliwia producentom OEM przesyłanie zaktualizowanych danych reguł stref czasowych na urządzenia bez konieczności aktualizowania systemu. Ten mechanizm umożliwia:

  • użytkownikom otrzymywanie aktualizacji na czas (co wydłuża okres użytkowania urządzenia z Androidem);
  • producentom OEM testowanie aktualizacji stref czasowych niezależnie od aktualizacji obrazu systemu.

Uwaga: AAOS 10 nie obsługuje mechanizmu aktualizacji modułów opartego na APEX, który jest dostępny w wersjach Androida 10 (i nowszych).

Uwaga: aby wdrożyć ten mechanizm, trzeba ponownie uruchomić system.

Źródła informacji o czasie (strefie czasowej) w samochodach

Urządzenia z Androidem zarządzają czasem w formacie Unix time na poziomie systemu, stosują odpowiednie przesunięcie strefy czasowej, a następnie konwertują wartość na czas lokalny, aby wyświetlić ją użytkownikom. Identyfikator strefy bieżącego użytkownika (często nazywany identyfikatorem Olsona) jest przechowywany jako ustawienie. Na przykład Europe/London.

Większość mechanizmu opisanego poniżej dotyczy informacji o czasie. Celem tych standardów jest podawanie użytkownikom aktualnego czasu, a nie opisywanie obowiązujących reguł stref czasowych. Aby określić rzeczywistą strefę czasową, urządzenie musi przed ustawieniem identyfikatora strefy uwzględnić takie czynniki jak kraj, przesunięcie i przesunięcie czasu letniego.

Ten proces może być trudny. Wycofywanie się na podstawie dostępnych informacji może być niejednoznaczne. Na przykład reguła strefy czasowej America/Denver uwzględnia czas letni, ale w lecie stosuje czas MDT (Mountain Daylight Time), natomiast reguła America/Phoenix nadal rozpoznaje MDT.

Radio komórkowe

Informacje systemowe (SI) są istotnym aspektem interfejsu radiowego LTE (Long-Term Evolution), który jest przesyłany przez stację bazową (BS) przez kanał sterowania transmisją (BCCH). Specyfikacja 3GPP TS 36.331 określa blok informacji systemowych typu 16 (SIB16), który zawiera informacje związane z GPS i uniwersalnym czasem koordynowanym (UTC), przesunięciem czasu lokalnego oraz informacje o czasie letnim.

Podobne funkcje można znaleźć w sieciach 2G i 3G, w których można rozgłaszać informacje o tożsamości sieci i strefie czasowej (NITZ) (szczegółowe informacje znajdziesz w specyfikacji 3GPP TS 22.042). Inne standardy radiowe mają równoważne funkcje.

Niestety, większość standardów ma wspólną cechę, że wysyłanie tych informacji jest opcjonalne, więc nie są one powszechnie dostępne we wszystkich sieciach.

Zalety Wady
  • Gdy są dostępne, zawierają większość potrzebnych informacji.
  • Prostota, już obsługiwana przez Androida, gdy radio komórkowe jest udostępniane jako telefon, a nie tylko jako modem danych.
  • Nie wymagają połączenia z internetem.

  • Brak gwarancji, że informacje są rozgłaszane ani że stacja bazowa jest prawidłowo skonfigurowana.

  • W regionach przygranicznych istnieje ryzyko, że zostanie wykryta (w roamingu) wieża komórkowa z sąsiedniego kraju i może zostać przekazana nieprawidłowa strefa czasowa.

  • W niektórych lokalizacjach aktualizacje mogą trwać wiele godzin, a nawet dni.

Protokół czasu sieciowego

Protokół czasu sieciowego (NTP) jest często używany do uzyskiwania stosunkowo dokładnych informacji o czasie epoki systemu Unix. Android obsługuje synchronizację czasu systemowego z czasem serwera NTP jeśli można go udostępnić klientom RadioManager za pomocą ogólnych RadioTuner.getParameters() metadanych. NTP aktualizuje czas systemowy, gdy jest on niesynchronizowany, a operator nie udostępnił ostatnio aktualizacji NITZ. Jeśli użytkownik włączy AUTO_TIME, gdy NITZ jest niedostępny, system natychmiast sprawdzi czas sieciowy.

Zalety Wady

Prostota, obsługiwana przez Androida.

  • Niekompletne, NTP udostępnia tylko 1 potrzebną wartość (czas). Nawet w najlepszym przypadku NTP nie może podać strefy czasowej.

  • Wymaga połączenia z internetem.

Tuner radiowy

Wykorzystanie wbudowanego tunera do pobierania informacji o czasie i strefie czasowej jest atrakcyjne, ale wiąże się z pewnymi wyzwaniami. Wiele standardów transmisji radiowej określa opcje udostępniania potrzebnych informacji. Ogólnie rzecz biorąc, tuner radiowy udostępnia te same informacje co radio komórkowe.

Sekcja 8.1 normy ETSI EN 300 401 V1.4.1 (2006-06) określa funkcje informacji o usługach, które udostępniają dodatkowe informacje o usługach zarówno w przypadku programów audio, jak i danych w systemach DAB (Digital Audio Broadcasting). Sekcja 8.1.3 określa format daty i godziny oraz informacje o kraju i przesunięciu czasu lokalnego.

Podobnie w przypadku systemu RDS (Radio Data System) powszechnie stosowanego w tunerach FM sekcja 3.1.5.6 normy EN 50067 określa format czasu zegarowego i danych (przesyłanych raz na minutę). Ponadto w ramach przesyłanego identyfikatora programu można też pobrać rozszerzony kod kraju (ECC).

Radio HD zawiera odpowiednie opcje w ramach specyfikacji transportu informacji o stacji HD Radio™ Air Interface Design Description Station Information Service w wiadomości z parametrami usługi informacji o stacji Service (SIS) (MSG ID 0111). Sekcja 5 wyraźnie określa słowa ostrzegawcze, których należy przestrzegać podczas próby użycia obsługi zegara w transmisji. Ta sama zasada dotyczy innych systemów:

... te dane opisują lokalne zwyczaje w lokalizacji nadawcy, które mogą się różnić od lokalnych zwyczajów w miejscu odbiorcy. W pobliżu granic stref czasowych konsumenci mogą odbierać wiele stacji udostępniających różne dane. Dlatego te dane są udostępniane tylko jako wskazówki, a ich interpretacja i wykorzystanie powinny być dobrowolne i podlegać kontroli klienta. ..."

Ponadto w przypadku radia HD przynajmniej transmisja tych informacji jest opcjonalna i nie należy na niej polegać wyłącznie.

Zalety Wady
  • Zwykle dostępne w różnych regionalnych standardach transmisji radiowej.
  • Nie wymagają połączenia z internetem.
  • Android nie obsługuje tego od razu.
  • Aby niezawodnie wykrywać informacje, tuner musi być włączony (przynajmniej od czasu do czasu w tle).

  • Niezawodność zależy od nadawcy.

Wskazówki dotyczące implementacji

Android obsługuje synchronizację czasu systemowego z czasem serwera NTP, jeśli można go udostępnić klientom RadioManager. Zalecanym rozwiązaniem jest wykorzystanie funkcji rozszerzenia dostawcy. Implementacja tej funkcji musi nastąpić w warstwie abstrakcji sprzętowej (HAL), po czym można ją udostępnić klientom RadioManager za pomocą ogólnej RadioTuner.getParameters() metody.

Aby rozwiązanie było niezawodne, odbiorca tego rozszerzenia dostawcy musi sprawdzić, czy HAL obsługuje tę funkcję (nie zakładaj, że istnieje). Ciągi parametrów wywołania getParameters muszą być dobrze zorganizowane, aby można ich było używać w sposób jednoznaczny u różnych dostawców. Na przykład użyj przestrzeni nazw swojej organizacji, dodając do niej odpowiednią domenę, np. com.me.timezoneTuner.currenttimezone.

Ze względu na charakter informacji oparty na zdarzeniach do ich odbierania warto użyć wywołania zwrotnego RadioTuner.Callback.onParametersUpdated(). Jeśli ta funkcja ma być konfigurowalna, zaprojektuj zestaw niestandardowych procedur na podstawie setParameters. Na przykład:

com.me.timezoneTuner.currenttimezoneEvent.enable

Sam GNSS (Global Navigation Satellite System) może podawać tylko dokładne informacje o czasie i pozycji.

Geolokalizacja

Rozwiązaniem tego problemu jest wykonanie geokodowania wstecznego i określenie kraju oraz strefy czasowej na podstawie pozycji. GNSS to oczywisty (i najlepszy) wybór informacji o lokalizacji w pojeździe. Interfejs Time Zone API Google oferuje wszystko, co jest potrzebne do przeprowadzenia wymaganej konwersji. Oczywiście wymagane jest połączenie z internetem. Podczas wdrażania rozwiązania online priorytetem musi być ochrona prywatności użytkowników. Wymagana jest zgoda użytkownika na akceptowanie kosztów transmisji danych (lub nie) i należy o nią poprosić.

Można utworzyć odpowiednie rozwiązanie do użytku offline. Lokalna baza danych map o wystarczającej rozdzielczości, aby dokładnie określić kraj i strefę czasową, może się zmieścić w pamięci pojazdu. Dzięki temu i w pełni wdrożonej strategii aktualizowania informacji o strefie czasowej (i kraju) w razie potrzeby można geokodować wstecznie kraj/strefę czasową na podstawie pozycji GNSS uzyskanej z podsystemu lokalizacji.

Zalety Wady
  • Może jednoznacznie określić prawidłową strefę czasową.
  • Nie wymaga połączenia z internetem (w przypadku lokalnej bazy danych).
  • Działa niezawodnie w większości scenariuszy jazdy.
  • Android nie obsługuje tego od razu.
  • Jeśli pojazd znajduje się w pomieszczeniu lub w zadaszonym miejscu, w którym podczas wstępnej konfiguracji nie można uzyskać dobrego sygnału satelitarnego GNSS, nie można uzyskać dokładnych informacji o czasie, lokalizacji, i strefie czasowej.
  • Lokalna baza danych wymaga mechanizmu aktualizacji.
  • Złożoność implementacji.

Telefon połączony przez Bluetooth, Wi-Fi lub USB

Do uzyskiwania danych o czasie i strefie czasowej można używać kilku technologii. W przypadku wszystkich telefonów na telefonie i w samochodowym systemie multimedialnym (IVI) trzeba zainstalować parę niestandardowych aplikacji – główną i towarzyszącą. Następnie można synchronizować czas w wybranym interwale. Na przykład po nawiązaniu połączenia i gdy telefon wykryje nową strefę czasową.

Niektóre telefony obsługujące Bluetooth Low Energy (BLE) umożliwiają pobieranie czasu za pomocą charakterystyki GATT Current Time i specyfikacji profilu Current Time Service 1.1. Ta opcja nie obejmuje jednak wystarczająco dużego segmentu rynku, aby można było na niej polegać wyłącznie.

Zalety Wady
  • Nie wymaga połączenia z internetem.
  • Zmiany strefy czasowej wykryte przez telefon można przekazywać do jednostki głównej.
  • Android nie obsługuje tego od razu.
  • Działa tylko wtedy, gdy telefon jest połączony z jednostką główną.
  • Czas jest tak dobry lub zły, jak podaje go telefon.
  • Implementacja jest złożona.
  • Nie wszystkie telefony obsługują profil usługi BLE GATT Current Time.

Korzystanie ze źródeł

Każdy dostawca urządzeń musi określić, jak wysoko ustawić poprzeczkę i które ścieżki użytkownika uznać za najważniejsze. Tylko dzięki jasnemu zrozumieniu pożądanych najważniejszych wrażeń użytkownika można podjąć najlepszą decyzję. W większości przypadków dostawcy muszą rozważyć kompromis między wygodą a złożonością implementacji.

Każda z opisanych powyżej opcji ma zalety i wady. Na przykład trzeba podjąć ważną decyzję projektową dotyczącą tego, jak duża odporność na sporadyczne nieprawidłowe wyświetlanie czasu jest akceptowalna i jak zarządzać wadami. W pełni automatyczne rozwiązanie, które powinno dobrze działać we wszystkich scenariuszach, musi być oparte na połączeniu kilku źródeł informacji. Żadna pojedyncza opcja nie może zapewnić 100% dostępności.

Opcja konfiguracji ręcznej jako tymczasowe rozwiązanie awaryjne jest łatwa do wdrożenia i w praktyce może być wystarczająca dla wielu użytkowników.