Zeitzonenoptionen

Die genaue Anzeige der Uhrzeit ist eine Hauptfunktion, die von einem Infotainmentsystem im Auto 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 ohne manuellen Eingriff ein zuverlässig genaues Datum und eine zuverlässig genaue Uhrzeit 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 vor dem Festlegen der Zonen-ID Faktoren wie Land, Offset und Sommerzeit-Offset berücksichtigen.

Das kann eine Herausforderung sein. Die Rückrechnung anhand der verfügbaren Informationen kann mehrdeutig sein. Die Zeitzonenregel „America/Denver“ berücksichtigt beispielsweise 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 Informationen zur Sommerzeit enthält.

Ähnliche Funktionen sind 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 verfügbar sind.

Vorteile Nachteile
  • Liefert, sofern verfügbar, die meisten der gewünschten Informationen.
  • Einfachheit, die bereits von Android unterstützt wird, wenn das Mobilfunkmodem 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-)Mobilfunksignal 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, sucht das System sofort nach der Netzwerkzeit.

Vorteile Nachteile

Einfachheit, unterstützt von Android.

  • Unvollständig, da NTP nur einen benötigten 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 Mobilfunkradio.

ETSI EN 300 401 V1.4.1 (2006-06), Abschnitt 8.1 gibt Funktionen für Dienstinformationen an, die sowohl für Audioprogramme als auch für Daten für Digital Audio Broadcasting-Systeme (DAB) zusätzliche Informationen zu Diensten liefern. In Abschnitt 8.1.3 wird das Format für Uhrzeit und Datum sowie Informationen zum Ländercode und zur lokalen Zeitverschiebung 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 ist. 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. Dieselbe Weisheit gilt auch für andere Systeme:

… diese Daten beschreiben die lokalen Gepflogenheiten am Standort des Rundfunkanbieters, 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 empfangen, die unterschiedliche Daten liefern. Daher werden diese Daten nur als Hinweise bereitgestellt. Die Interpretation und Nutzung sollte nach Ermessen 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 dieser für Clients von RadioManager zugänglich ist. Die empfohlene Lösung ist die Verwendung der Anbietererweiterungsfunktion. 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 Offline-Nutzung 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 Innenbereich oder an einem überdachten Ort befindet, an 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 ist ü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 der Fall sein.

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 Nutzererlebnisse 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 gehandhabt werden sollen. Eine vollautomatische Lösung, die in allen Szenarien gut funktionieren sollte, aber auf einer Kombination aus mehreren Informationsquellen basiert. 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.