Zeitzonenoptionen

Die genaue Anzeige der Uhrzeit ist eine Kernfunktion, die von einem Infotainmentsystem für Kraftfahrzeuge erwartet wird. Das mag täuschend einfach erscheinen, insbesondere wenn die Erwartungen an die Zeit- und Zeitzonenverwaltung gering sind und erfüllt werden müssen. Die Zeit wird jedoch schnell komplex, wenn ein zuverlässig genaues Datum und eine zuverlässig genaue Uhrzeit ohne manuellen Eingriff angezeigt werden müssen.

Alle in System-on-a-Chip (SoC) verwendeten Echtzeituhrwerke weisen in der Regel eine gewisse Drift auf, die sich im Laufe der Zeit ansammelt und ohne Korrektur zu erheblichen Fehlern führen kann. Außerdem wird erwartet, dass die Ortszeit korrekt angezeigt wird. Daher muss der richtige Versatz zur koordinierten Weltzeit (UTC) berücksichtigt werden.

Zeitzoneninformationen sowie die Anwendung der Sommerzeit können sich während der erwarteten Lebensdauer eines Fahrzeugs ändern. Nachdem in Brasilien viele Jahre lang die Sommerzeit eingeführt wurde, wurde 2019 beschlossen, keinen Sommerzeitplan zu starten.

Android bietet die Infrastruktur, die für die Verwaltung von Zeitzonenregeln erforderlich ist. Weitere Informationen finden Sie unter Zeitzonenregeln. Damit können OEMs aktualisierte Zeitzonenregeln auf Geräte übertragen, ohne dass ein Systemupdate erforderlich ist. Dieser Mechanismus ermöglicht Folgendes:

  • Nutzer erhalten zeitnah Updates, die die Nutzungsdauer eines Android-Geräts verlängern.
  • OEMs können Zeitzonenupdates unabhängig von System-Image-Updates testen.

Hinweis:AAOS 10 unterstützt nicht den APEX-basierten Modulaktualisierungsmechanismus, der in Versionen von Android 10 (und höher) bereitgestellt wird.

Hinweis:Für die Implementierung dieses Mechanismus ist ein Systemneustart erforderlich.

Quellen für Zeit- und Zeitzoneninformationen in Autos

Auf Android-Geräten wird die Zeit auf Systemebene in Unix-Zeit verwaltet. Dann wird der gewünschte Zeitzonen-Offset angewendet und der Wert wird in die Ortszeit umgerechnet, um ihn Nutzern anzuzeigen. Die Zonen-ID des aktuellen Nutzers (oft als Olson-ID bezeichnet) wird als Einstellung gespeichert. Beispiel: Europe/London.

Ein Großteil des unten beschriebenen Mechanismus bezieht sich auf Zeitinformationen. Diese Standards sollen Nutzern die aktuelle Uhrzeit anzeigen, nicht die geltenden Zeitzonenregeln beschreiben. Um die tatsächliche Zeitzone zu ermitteln, muss das Gerät Faktoren wie Land, Offset und Sommerzeit-Offset berücksichtigen, bevor die Zonen-ID festgelegt wird.

Das kann eine Herausforderung sein. Die Rückrechnung anhand der verfügbaren Informationen kann mehrdeutig sein. Beispiel: Die Zeitzonenregel „America/Denver“ berücksichtigt die Sommerzeit und wechselt im Sommer zur Mountain Daylight Time (MDT), während „America/Phoenix“ weiterhin MDT verwendet.

Mobilfunkradio

Systeminformationen (SI) sind ein wichtiger Aspekt der LTE-Luftschnittstelle (Long-Term Evolution), die von der Basisstation (BS) über den Broadcast Control Channel (BCCH) übertragen werden. In 3GPP TS 36.331 wird der SystemInformationBlockType16 (SIB16) angegeben, der Informationen zu GPS und koordinierter Weltzeit (UTC), zum lokalen Zeitversatz sowie zu Sommerzeit enthält.

Eine ähnliche Funktion ist in 2G und 3G verfügbar, wo Informationen zur Netzwerkidentität und Zeitzone (NITZ) übertragen werden können (siehe 3GPP TS 22.042 für Details). Andere Mobilfunkstandards haben entsprechende Funktionen.

Leider ist das Senden dieser Informationen bei den meisten Standards optional, sodass sie nicht in allen Netzwerken universell verfügbar sind.

Vorteile Nachteile
  • Liefert, sofern verfügbar, die meisten der gewünschten Informationen.
  • Simplicity, das bereits von Android unterstützt wird, wenn das Mobilfunkmodul als Telefon und nicht nur als Datenmodem bereitgestellt wird.
  • Keine Internetverbindung erforderlich.

  • Es gibt keine Garantie dafür, dass die Informationen übertragen werden oder dass die Basisstation richtig konfiguriert ist.

  • In Grenzregionen kann es vorkommen, dass das Gerät ein (Roaming-)Funksignal von einem Mobilfunkmast aus einem Nachbarland empfängt und dadurch möglicherweise die falsche Zeitzone angezeigt wird.

  • An einigen Standorten kann es Stunden oder sogar Tage dauern, bis Aktualisierungen vorgenommen werden.

Network Time Protocol

Das Network Time Protocol (NTP) wird häufig verwendet, um relativ genaue Informationen zur Unix-Epochenzeit zu erhalten. Android unterstützt die Synchronisierung der Systemzeit mit der eines NTP-Servers, wenn sie Clients von RadioManager über die generischen RadioTuner.getParameters()-Metadaten zur Verfügung gestellt werden kann. NTP aktualisiert die Systemzeit, wenn sie nicht mehr synchron ist und ein Mobilfunkanbieter in letzter Zeit kein NITZ-Update bereitgestellt hat. Wenn der Nutzer AUTO_TIME aktiviert, während NITZ nicht verfügbar ist, prüft das System sofort die Netzwerkzeit.

Vorteile Nachteile

Einfachheit, unterstützt von Android.

  • Unvollständig, da NTP nur einen erforderlichen Wert (Zeit) liefert. Selbst im Best-Case-Szenario kann NTP die Zeitzone nicht angeben.

  • Es ist eine Internetverbindung erforderlich.

Radio-Tuner

Die Verwendung eines integrierten Tuners zum Abrufen von Zeit- und Zeitzoneninformationen ist zwar verlockend, birgt aber auch Herausforderungen. Zahlreiche Radiosendestandards definieren Optionen zum Bereitstellen der gewünschten Informationen. Im Allgemeinen liefert ein Rundfunk-Tuner dieselben Informationen wie ein Mobilfunk-Radio.

ETSI EN 300 401 V1.4.1 (2006-06), Abschnitt 8.1 enthält Spezifikationen für Dienstinformationen, die zusätzliche Informationen zu Diensten für Audioprogramme und Daten für DAB-Systeme (Digital Audio Broadcasting) bereitstellen. In Abschnitt 8.1.3 wird das Format für Uhrzeit und Datum sowie Informationen zum Land und zum lokalen Zeitversatz definiert.

Ähnlich definiert Abschnitt 3.1.5.6 des EN 50067-Standards das Format für Uhrzeit und Daten (einmal pro Minute übertragen) für das Radio Data System (RDS), das häufig in FM-Tunern implementiert wird. Außerdem kann der erweiterte Ländercode (Extended Country Code, ECC) als Teil der übertragenen Programm-ID abgerufen werden.

HD Radio enthält entsprechende Optionen im Rahmen der Spezifikation HD Radio™ Air Interface Design Description Station Information Service Transport in der SIS-Parameternachricht (MSG ID 0111). In Abschnitt 5 werden deutlich Warnhinweise aufgeführt, die bei der Verwendung der Uhrunterstützung der Übertragung beachtet werden müssen. Dasselbe gilt für andere Systeme:

… diese Daten beschreiben die lokalen Gepflogenheiten am Standort des Rundfunksenders, die mit den lokalen Gepflogenheiten am Standort des Empfängers übereinstimmen können, aber nicht müssen. In der Nähe von Zeitzonengrenzen können Nutzer eine Vielzahl von Sendern mit unterschiedlichen Daten empfangen. Daher werden diese Daten nur als Hinweise bereitgestellt. Die Interpretation und Nutzung sollte nach Ermessen und unter Kontrolle des Kunden erfolgen. …“

Außerdem ist die Übertragung dieser Informationen zumindest für HD Radio optional und sollte nicht ausschließlich verwendet werden.

Vorteile Nachteile
  • In der Regel für verschiedene regionale Rundfunkstandards verfügbar.
  • Keine Internetverbindung erforderlich.
  • Android unterstützt dies nicht standardmäßig.
  • Der Tuner muss eingeschaltet sein (zumindest gelegentlich im Hintergrund), damit Informationen zuverlässig erkannt werden können.

  • Die Zuverlässigkeit hängt vom Sender ab.

Tipps zur Implementierung

Android unterstützt die Synchronisierung der Systemzeit mit der eines NTP-Servers, wenn sie Clients von RadioManager zur Verfügung gestellt werden kann. Die empfohlene Lösung ist die Verwendung der Anbietererweiterung. Die Implementierung dieser Funktion muss in der Hardware-Abstraktionsschicht (Hardware Abstraction Layer, HAL) erfolgen. Danach kann sie Clients von RadioManager über die generische Methode RadioTuner.getParameters() zur Verfügung gestellt werden.

Damit die Lösung robust bleibt, muss der Consumer dieser Anbietererweiterung feststellen, dass das HAL die Funktion unterstützt (nicht davon ausgehen). Parameterstrings für den getParameters-Aufruf müssen übersichtlich organisiert sein, damit sie von allen Anbietern eindeutig verwendet werden können. Verwenden Sie beispielsweise den Namespace Ihrer Organisation, indem Sie ihm die entsprechende Domain voranstellen, z. B. com.me.timezoneTuner.currenttimezone.

Da die Informationen ereignisbasiert sind, kann es sinnvoll sein, den RadioTuner.Callback.onParametersUpdated()-Callback zu verwenden, um sie zu empfangen. Wenn diese Funktion konfigurierbar sein soll, entwerfen Sie eine Reihe benutzerdefinierter Abläufe auf Grundlage von setParameters. Beispiel:

com.me.timezoneTuner.currenttimezoneEvent.enable

Das Global Navigation Satellite System (GNSS) allein kann nur genaue Zeitinformationen und Positionen liefern.

Standortbestimmung

Die Lösung für dieses Problem besteht darin, die umgekehrte Geocodierung auszuführen und das Land und die Zeitzone anhand der Position zu ermitteln. GNSS ist die offensichtliche (und qualitativ beste) Wahl für Standortinformationen in einem Fahrzeug. Die Time Zone API von Google bietet alles, was für die erforderliche Konvertierung benötigt wird. Dazu ist natürlich eine Internetverbindung erforderlich. Der Schutz der Nutzerdaten muss bei der Implementierung einer Onlinelösung höchste Priorität haben. Die Einwilligung eines Nutzers, die Kosten für die Datennutzung zu akzeptieren (oder nicht), ist erforderlich und muss eingeholt werden.

Es ist möglich, eine geeignete Lösung für die Offlinenutzung zu erstellen. Eine lokale Kartendatenbank mit ausreichender Auflösung, um das Land und die Zeitzone genau zu bestimmen, kann im Speicher eines Fahrzeugs untergebracht werden. Mit dieser und einer vollständig implementierten Strategie zum Aktualisieren der Zeitzonen- und Länderinformationen nach Bedarf kann das Land/die Zeitzone anhand der GNSS-Position, die vom Standort-Subsystem abgerufen wird, rückwärts geocodiert werden.

Vorteile Nachteile
  • Die richtige Zeitzone kann eindeutig ermittelt werden.
  • Keine Internetverbindung erforderlich (bei lokaler Datenbank).
  • Funktioniert in den meisten Fahrsituationen zuverlässig.
  • Android unterstützt dies nicht standardmäßig.
  • Wenn sich das Fahrzeug bei der Erstkonfiguration in einem Innenraum oder einem überdachten Bereich befindet, in dem kein guter GNSS-Satellitenempfang möglich ist, können keine genauen Informationen zu Uhrzeit, Standort und Zeitzone abgerufen werden.
  • Die lokale Datenbank benötigt einen Aktualisierungsmechanismus.
  • Komplexität der Implementierung.

Smartphone über Bluetooth, WLAN oder USB verbunden

Es gibt verschiedene Technologien, mit denen Zeit- und Zeitzonendaten über das Smartphone eines Nutzers abgerufen werden können. Auf allen Smartphones muss ein Paar aus benutzerdefinierter App und Companion-App auf dem Smartphone und auf dem Infotainmentsystem installiert sein. Anschließend können Sie die Zeit im gewünschten Intervall synchronisieren. Das kann beispielsweise beim Herstellen der Verbindung und beim Erkennen einer neuen Zeitzone durch das Smartphone passieren.

Einige Smartphones, die Bluetooth Low Energy (BLE) unterstützen, bieten die Möglichkeit, die Zeit über das GATT Current Time Characteristic und die Current Time Service Profile Specification 1.1 abzurufen. Diese Option deckt jedoch kein ausreichend großes Marktsegment ab, um sich ausschließlich darauf zu verlassen.

Vorteile Nachteile
  • Keine Internetverbindung erforderlich.
  • Vom Smartphone erkannte Zeitzonenänderungen können an das Infotainmentsystem weitergeleitet werden.
  • Android unterstützt dies nicht standardmäßig.
  • Funktioniert nur, wenn das Smartphone mit dem Infotainmentsystem verbunden ist.
  • Die Zeitangabe ist so gut oder schlecht wie die Informationen, die das Smartphone liefert.
  • Die Implementierung ist komplex.
  • Nicht alle Smartphones unterstützen das BLE GATT Current Time Service-Profil.

Quellen verwenden

Jeder Geräteanbieter muss selbst festlegen, wie hoch die Anforderungen sein sollen und welche Nutzeraktionen als besonders wichtig gelten. Nur wenn die gewünschten kritischen Nutzeraktionen klar verstanden werden, kann die beste Entscheidung getroffen werden. In den meisten Fällen müssen Anbieter die Kompromisse zwischen Benutzerfreundlichkeit und Implementierungskomplexität abwägen.

Jede der oben beschriebenen Optionen hat Vor- und Nachteile. So muss beispielsweise eine wichtige Designentscheidung darüber getroffen werden, wie viel Robustheit im Vergleich zu gelegentlich schlechter Zeitanzeige akzeptabel ist und wie die Nachteile zu bewältigen sind. Eine vollautomatische Lösung, die in allen Szenarien gut funktionieren sollte, aber auf einer Kombination aus mehreren Informationsquellen basieren muss. Keine einzelne Option kann eine Verfügbarkeit von 100% bieten.

Eine manuelle Konfigurationsoption als temporärer Fallback ist einfach auszuführen und kann in der Praxis für viele Nutzer ausreichend sein.