Zeitzonenoptionen

Die korrekte Anzeige der Uhrzeit ist eine Hauptfunktion, die von einem Infotainmentsystem in einem Auto erwartet wird. Das mag zwar auf den ersten Blick einfach erscheinen, insbesondere wenn die Anforderungen an die Zeit- und Zeitzonenverwaltung gering sind und erfüllt werden müssen, aber die Zeit wird schnell komplex, wenn ein zuverlässig genaues Datum und eine zuverlässig genaue Uhrzeit ohne manuelle Eingriffe angezeigt werden müssen.

Alle Echtzeituhren, die in der Regel in System-on-a-Chips (SoCs) verwendet werden, weisen eine gewisse Abweichung auf, die sich im Laufe der Zeit summiert und bei Nichtkorrektur zu erheblichen Fehlern führen kann. Da die Nutzer erwarten, dass die Ortszeit korrekt angezeigt wird, muss außerdem der korrekte Versatz von der koordinierten Weltzeit (UTC) berücksichtigt werden.

Informationen zur Zeitzone und zur Anwendung der Sommerzeit können sich während der Lebensdauer eines Fahrzeugs ändern. Beispielsweise hat Brasilien nach vielen Jahren der Einführung der Sommerzeit 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. OEMs können damit aktualisierte Zeitzonenregelndaten auf Geräte pushen, ohne dass ein Systemupdate erforderlich ist. Dieser Mechanismus ermöglicht Folgendes:

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

Hinweis:AAOS 10 unterstützt nicht den APEX-basierten Modulaktualisierungsmechanismus, der in Releases von Android 10 und höher verfügbar ist.

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

Informationsquellen für Uhrzeit und Zeitzone in Autos

Auf Android-Geräten wird die Zeit auf Systemebene in Unix-Zeit verwaltet. Die gewünschte Zeitzonenverschiebung wird angewendet und der Wert dann in die lokale Zeit umgewandelt, die für Nutzer angezeigt wird. 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 anhand von Faktoren wie Land, Zeitzonenoffset und Sommerzeit-Offset zurückrechnen, bevor die Zonen-ID festgelegt wird.

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

Mobilfunkradio

Systeminformationen (SI) sind ein wesentlicher Aspekt der Long-Term Evolution (LTE)-Funkschnittstelle, die von der Basisstation (BS) über den Broadcast Control Channel (BCCH) übertragen wird. 3GPP TS 36.331 gibt den SystemInformationBlockType16 (SIB16) an, der Informationen zu GPS und koordinierter Weltzeit (UTC), zum Zeitunterschied zur Ortszeit sowie zu 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 (Details finden Sie in 3GPP TS 22.042). Andere Mobilfunkstandards haben ähnliche Funktionen.

Leider ist das Senden dieser Informationen bei den meisten Standards optional. Sie sind also nicht in allen Netzwerken verfügbar.

Vorteile Nachteile
  • Bietet, sofern verfügbar, die meisten gewünschten Informationen.
  • Einfachheit, bereits von Android unterstützt, wenn das Mobilfunkradio als Smartphone und nicht nur als Datenmodem verfügbar ist.
  • Es ist 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 passieren, dass ein (Roaming-)Mobilfunkmast aus einem Nachbarland genutzt wird und möglicherweise die falsche Zeitzone übermittelt wird.

  • An einigen Orten kann es Stunden oder sogar Tage dauern, bis Updates wirksam 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 dieser über die generischen RadioTuner.getParameters()-Metadaten für Clients von RadioManager freigegeben 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, NTP liefert nur einen erforderlichen Wert (Uhrzeit). Selbst im Best-Case-Szenario kann NTP die Zeitzone nicht angeben.

  • Es ist eine Internetverbindung erforderlich.

Radiotuner für die Übertragung

Der Vorteil eines integrierten Tuners zum Abrufen von Uhrzeit- und Zeitzoneninformationen ist zwar verlockend, es gibt aber auch Herausforderungen. Zahlreiche Standards für die Radioübertragung definieren Optionen für die Darstellung der gewünschten Informationen. Im Allgemeinen liefert ein Radiotuner dieselben Informationen wie ein Mobilfunkradio.

In ETSI EN 300 401 V1.4.1 (2006-06), Abschnitt 8.1 werden Dienstinformationen beschrieben, die zusätzliche Informationen zu Diensten sowohl für Audioprogramme als auch für Daten für DAB-Systeme (Digital Audio Broadcasting) liefern. In Abschnitt 8.1.3 werden das Format für Uhrzeit und Datum sowie Informationen zum Land und zum Zeitunterschied definiert.

Ähnlich definiert Abschnitt 3.1.5.6 des EN 50067-Standards das Format für die 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) im Rahmen der übertragenen Programmkennzeichnung abgerufen werden.

HD Radio enthält entsprechende Optionen als Teil der Spezifikation HD Radio™ Air Interface Design Description Station Information Service Transport in der Parameternachricht des Station Information Service (SIS) (MSG ID 0111). In Abschnitt 5 werden deutlich die Warnungen beschrieben, die bei der Verwendung der Uhrenfunktion der Übertragung beachtet werden müssen. Das gilt auch für andere Systeme:

… diese Daten beschreiben die lokale Gewohnheit am Standort des Senders, die mit der lokalen Gewohnheit am Standort des Empfängers übereinstimmen kann oder auch nicht. In der Nähe von Zeitzonengrenzen können Nutzer mehrere Sender empfangen, die unterschiedliche Daten liefern. Daher dienen diese Daten nur als Hinweise, deren Interpretation und Nutzung im Ermessen des Kunden liegt. ..."

Außerdem ist die Ausstrahlung dieser Informationen zumindest bei HD Radio optional und sollte nicht ausschließlich verwendet werden.

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

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

Tipps zur Implementierung

Android unterstützt die Synchronisierung der Systemzeit mit der eines NTP-Servers, wenn dieser für Clients von RadioManager freigegeben werden kann. Wir empfehlen, die Funktion „Anbietererweiterung“ zu verwenden. Die Implementierung dieser Funktion muss in der Hardware Abstraction Layer (HAL) erfolgen. Anschließend kann sie über die generische Methode RadioTuner.getParameters() für Clients von RadioManager freigegeben werden.

Damit die Lösung robust bleibt, muss der Nutzer dieser Anbietererweiterung prüfen, ob die HAL die Funktion unterstützt. Sie darf nicht einfach davon ausgehen, dass sie vorhanden ist. Parameterstrings für den getParameters-Aufruf müssen für eine eindeutige Verwendung bei allen Anbietern übersichtlich organisiert sein. Sie können beispielsweise den Namensraum Ihrer Organisation verwenden, indem Sie ihm die entsprechende Domain vorangestellt haben, z. B. com.me.timezoneTuner.currenttimezone.

Aufgrund der ereignisbasierten Natur der Informationen kann es vorteilhaft sein, den RadioTuner.Callback.onParametersUpdated()-Callback zum Empfangen dieser Informationen zu verwenden. Wenn diese Funktion konfigurierbar sein soll, entwerfen Sie eine Reihe von benutzerdefinierten Abläufen über setParameters. Beispiel:

com.me.timezoneTuner.currenttimezoneEvent.enable

Das Global Navigation Satellite System (GNSS) kann allein nur genaue Zeit- und Standortinformationen liefern.

Standortbestimmung

Die Lösung für dieses Problem besteht darin, eine umgekehrte Geocodierung auszuführen und das Land und die Zeitzone anhand der Position zu ermitteln. GNSS ist die naheliegende (und beste) Wahl für Standortinformationen in einem Fahrzeug. Die Zeitzonen-API von Google bietet alles, was für die erforderliche Umwandlung erforderlich ist. Natürlich ist eine Internetverbindung erforderlich. Der Schutz der Daten der Nutzer muss bei der Implementierung einer Onlinelösung an erster Stelle stehen. Die Erlaubnis eines Nutzers, die Kosten für die Datennutzung zu akzeptieren oder nicht, ist erforderlich und muss angefordert 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 in den Speicher eines Fahrzeugs passen. Mit dieser Funktion und einer vollständig implementierten Strategie zur Aktualisierung der Informationen zur Zeitzone (und zum Land) kann das Land/die Zeitzone anhand der GNSS-Position, die vom Standort-Subsystem erfasst wird, umgekehrt geocodiert werden.

Vorteile Nachteile
  • Die richtige Zeitzone kann eindeutig ermittelt werden.
  • Erfordert keine Internetverbindung (bei lokaler Datenbank).
  • Funktioniert zuverlässig in den meisten Fahrsituationen.
  • Android unterstützt dies nicht standardmäßig.
  • Wenn sich das Fahrzeug in einem Gebäude oder in einem überdachten Bereich befindet, in dem während der Erstkonfiguration 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 mehrere Technologien, mit denen die Uhrzeit und die Zeitzone eines Nutzers ermittelt werden können. Für alle Smartphones müssen eine benutzerdefinierte App und eine zugehörige App auf dem Smartphone und im herstellereigenen Infotainmentsystem installiert sein. Anschließend können Sie die Zeit im gewünschten Intervall synchronisieren. Beispielsweise beim Herstellen der Verbindung und wenn das Smartphone eine neue Zeitzone erkennt.

Einige Smartphones, die Bluetooth Low Energy (BLE) unterstützen, bieten die Möglichkeit, die Uhrzeit über die GATT-Eigenschaft „Current Time“ und die Current Time Service Profile Specification 1.1 abzurufen. Diese Option spricht jedoch nicht ein ausreichend großes Marktsegment an, um sich ausschließlich darauf zu verlassen.

Vorteile Nachteile
  • Es ist 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 Zeit ist so gut oder schlecht wie die, die das Smartphone bietet.
  • Die Implementierung ist komplex.
  • Nicht alle Smartphones unterstützen das BLE GATT Current Time Service-Profil.

Quellen verwenden

Jeder Geräteanbieter muss selbst entscheiden, wie hoch die Messlatte gelegt werden soll und welche User Journeys er als kritisch erachtet. Nur wenn Sie die gewünschten kritischen Nutzererfahrungen genau kennen, können Sie die beste Entscheidung treffen. In den meisten Fällen müssen Anbieter die Abwägung zwischen Nutzerfreundlichkeit und Implementierungskomplexität berücksichtigen.

Jede der oben beschriebenen Optionen hat Vor- und Nachteile. Beispielsweise muss eine wichtige Designentscheidung getroffen werden, wie robust das Gerät im Vergleich zu gelegentlichen Abweichungen bei der Uhrzeit sein soll und wie mit den Nachteilen umgegangen werden soll. Eine vollautomatische Lösung, die in allen Szenarien gut funktionieren sollte, muss jedoch auf einer Kombination mehrerer Informationsquellen basieren. Keine einzelne Option kann eine Verfügbarkeit von 100% bieten.

Eine manuelle Konfigurationsoption als vorübergehender Fallback ist einfach auszuführen und kann in der Praxis für viele Nutzer ausreichen.