Zeitzonenoptionen

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

Alle Echtzeituhren, die typischerweise in System-on-Chip (SoC) verwendet werden, weisen eine gewisse Abweichung auf, die sich im Laufe der Zeit ansammelt und zu erheblichen Fehlern führen kann, wenn sie nicht korrigiert wird. Da außerdem hohe Erwartungen an die genaue Anzeige der Ortszeit bestehen, muss der korrekte Versatz zur koordinierten Weltzeit (UTC) berücksichtigt werden.

Es ist zu erwarten, dass sich die Zeitzoneninformationen sowie die Anwendung der Sommerzeit (DST) während der erwarteten Lebensdauer eines Fahrzeugs ändern. Nach vielen Jahren der Einführung der Sommerzeit entschied sich Brasilien beispielsweise dafür, im Jahr 2019 keinen Sommerzeitplan einzuführen.

Android bietet die erforderliche Infrastruktur, um Komplikationen bei der Verwaltung von Zeitzonenregeln zu bewältigen. Einzelheiten finden Sie unter Zeitzonenregeln , die es OEMs ermöglichen, aktualisierte Zeitzonenregeldaten an Geräte zu übertragen, ohne dass eine Systemaktualisierung erforderlich ist. Dieser Mechanismus ermöglicht:

  • Benutzer erhalten zeitnahe Updates (die die Nutzungsdauer eines Android-Geräts verlängern).
  • OEMs können Zeitzonen-Updates 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: Um diesen Mechanismus zu implementieren, ist ein Systemneustart erforderlich.

Zeit-(Zonen-)Informationsquellen in Autos

Android-Geräte verwalten die Zeit auf Systemebene in Unix-Zeit, wenden den gewünschten Zeitzonenversatz an und konvertieren den Wert dann zur Anzeige für Benutzer in die Ortszeit. Die Zonen-ID des aktuellen Benutzers (oft als Olson-ID bezeichnet) wird als Einstellung gespeichert. Zum Beispiel Europa/London .

Ein Großteil des unten beschriebenen Mechanismus beschreibt Zeitinformationen. Der Zweck dieser Standards besteht darin, Benutzern die aktuelle Uhrzeit bereitzustellen, und nicht darin, die geltenden Zeitzonenregeln zu beschreiben. Um die tatsächliche Zeitzone zu ermitteln, muss das Gerät vor dem Festlegen der Zonen-ID Faktoren wie Land, Offset und DST-Offset berücksichtigen.

Der Prozess kann eine Herausforderung sein. Die Rückführung auf der Grundlage der verfügbaren Informationen kann unklar sein. Beispielsweise gilt in der Zeitzonenregel „Amerika/Denver“ die Sommerzeit, im Sommer wird jedoch die Sommerzeit (Mountain Daylight Time, MDT) übernommen, wohingegen „Amerika/Phoenix“ weiterhin MDT anerkennt.

Mobilfunk

Systeminformationen (SI) sind ein wesentlicher Aspekt der Long-Term Evolution (LTE)-Luftschnittstelle, die von der Basisstation (BS) über den Broadcast Control Channel (BCCH) übertragen wird. 3GPP TS 36.331 spezifiziert den SystemInformationBlockType16 (SIB16), der Informationen zu GPS und der koordinierten Weltzeit (UTC), dem lokalen Zeitversatz sowie DST-Informationen enthält.

Ähnliche Funktionen sind in 2G und 3G zu finden, wo Netzwerkidentitäts- und Zeitzoneninformationen (NITZ) übertragen werden können (Einzelheiten siehe 3GPP TS 22.042). Andere Mobilfunkstandards verfügen über entsprechende Funktionen.

Leider haben die meisten Standards gemeinsam, dass das Senden dieser Informationen optional ist und daher nicht in allen Netzwerken allgemein verfügbar ist.

Vorteile Nachteile
  • Sofern verfügbar, werden die meisten gewünschten Informationen bereitgestellt.
  • Einfachheit, die bereits von Android unterstützt wird, wenn Mobilfunk als Telefon und nicht nur als Datenmodem genutzt wird.
  • Erfordert keine Internetverbindung.

  • Es gibt keine Garantie dafür, dass die Informationen gesendet werden oder dass die Basisstation ordnungsgemäß konfiguriert ist.

  • In Grenzregionen besteht die Gefahr, dass ein (Roaming-)Mobilfunkmast aus einem Nachbarland abgeholt und möglicherweise die falsche Zeitzone übermittelt wird.

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

Netzwerkzeitprotokoll

Network Time Protocol (NTP) wird häufig verwendet, um relativ genaue Unix-Epochenzeitinformationen zu erhalten. Android unterstützt die Synchronisierung seiner Systemzeit mit der eines NTP-Servers, wenn diese über die generischen RadioTuner.getParameters() -Metadaten für Clients von RadioManager verfügbar gemacht werden kann. NTP aktualisiert die Systemzeit, wenn sie nicht mehr synchronisiert ist und ein Netzbetreiber kürzlich kein NITZ-Update bereitgestellt hat. Wenn der Benutzer AUTO_TIME aktiviert, wenn NITZ nicht verfügbar ist, prüft das System sofort die Netzwerkzeit.

Vorteile Nachteile

Einfachheit, unterstützt von Android.

  • Unvollständig, NTP liefert nur einen benötigten Wert (Zeit). Selbst im besten Fall kann NTP die Zeitzone nicht bereitstellen.

  • Erfordert eine Internetverbindung.

Rundfunk-Radio-Tuner

Die Nutzung eines integrierten Tuners zum Abrufen von Zeit- und Zeitzoneninformationen ist zwar verlockend, bringt jedoch auch Herausforderungen mit sich. Zahlreiche Rundfunknormen definieren Möglichkeiten zur Darstellung der gewünschten Informationen. Im Allgemeinen liefert ein Radiotuner die gleichen Informationen wie ein Mobilfunkradio.

ETSI EN 300 401 V1.4.1 (2006-06), Abschnitt 8.1 spezifiziert Dienstinformationsfunktionen, die zusätzliche Informationen über Dienste sowohl für Audioprogramme als auch für Daten für Digital Audio Broadcasting (DAB)-Systeme bereitstellen. Abschnitt 8.1.3 definiert das Format für Uhrzeit und Datum sowie Informationen zum Länder- und lokalen Zeitversatz.

In ähnlicher Weise definiert Abschnitt 3.1.5.6 der Norm EN 50067 für das Radiodatensystem (RDS), das häufig in FM-Tunern implementiert ist, das Format für Uhrzeit und Daten (einmal pro Minute übertragen). Darüber hinaus kann im Rahmen der übermittelten Programmkennung auch der erweiterte Ländercode (ECC) abgerufen werden.

HD Radio enthält entsprechende Optionen als Teil der HD Radio™ Air Interface Design Description Station Information Service Transport- Spezifikation in der Station Information Service (SIS) Parameter Message (MSG ID 0111). Abschnitt 5 enthält eindeutige Warnhinweise, die beachtet werden müssen, wenn versucht wird, die Taktunterstützung der Sendung zu nutzen. Die gleiche Weisheit gilt gleichermaßen für andere Systeme:

... diese Daten beschreiben die örtlichen Gepflogenheiten am Standort des Senders, die mit den örtlichen Gepflogenheiten am Standort des Empfängers übereinstimmen können oder auch nicht. In der Nähe von Zeitzonengrenzen können Verbraucher eine Vielzahl von Stationen empfangen, die unterschiedliche Daten bereitstellen. Daher werden diese Daten nur als Hinweise bereitgestellt, deren Interpretation und Nutzung im Ermessen des Kunden erfolgen sollte und der Kontrolle unterliegt. ...“

Darüber hinaus ist die Ausstrahlung dieser Informationen zumindest für HD-Radio optional und sollte nicht ausschließlich erfolgen.

Vorteile Nachteile
  • In der Regel für verschiedene regionale Rundfunkstandards verfügbar.
  • Erfordert keine Internetverbindung.
  • Android unterstützt dies nicht standardmäßig.
  • Erfordert, dass der Tuner eingeschaltet ist (zumindest gelegentlich im Hintergrund), um Informationen zuverlässig zu erkennen.

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

Tipps zur Umsetzung

Android unterstützt die Synchronisierung seiner Systemzeit mit der eines NTP-Servers, wenn es für Clients von RadioManager verfügbar gemacht werden kann. Die empfohlene Lösung besteht darin, die Anbietererweiterungsfunktion zu nutzen. Die Implementierung dieser Funktionalität muss in der Hardware-Abstraktionsschicht (HAL) erfolgen. Anschließend kann sie über die generische RadioTuner.getParameters() Methode für Clients von RadioManager verfügbar gemacht werden.

Damit die Lösung robust bleibt, muss der Verbraucher dieser Anbietererweiterung feststellen, dass die HAL die Funktion unterstützt (gehen Sie nicht davon aus, dass sie existiert). Parameterzeichenfolgen für den getParameters Aufruf müssen sauber organisiert sein, damit sie herstellerübergreifend eindeutig verwendet werden können. Verwenden Sie beispielsweise den Namespace Ihrer Organisation, indem Sie ihm die entsprechende Domäne voranstellen, beispielsweise com.me.timezoneTuner.currenttimezone .

Angesichts der ereignisgesteuerten Natur der Informationen kann es von Vorteil sein, den Rückruf RadioTuner.Callback.onParametersUpdated() zum Empfangen dieser Informationen zu verwenden. Wenn diese Funktion konfigurierbar sein soll, entwerfen Sie eine Reihe benutzerdefinierter Routinen zusätzlich zu setParameters . Zum Beispiel:

com.me.timezoneTuner.currenttimezoneEvent.enable

Das Globale Navigationssatellitensystem (GNSS) allein kann nur genaue Zeitinformationen und Position liefern.

Geolokalisierung

Die Lösung für dieses Problem besteht darin, eine umgekehrte Geokodierung durchzuführen und das Land und die Zeitzone durch eine Suche basierend auf der Position zu bestimmen. GNSS ist die offensichtlichste (und qualitativ hochwertigste) Wahl für Standortinformationen in einem Fahrzeug. Die Zeitzonen-API von Google bietet alles, was zur Durchführung der erforderlichen Konvertierung erforderlich ist. Natürlich ist eine Internetverbindung erforderlich. Die Wahrung der Privatsphäre der Nutzer muss bei der Implementierung einer Online-Lösung oberste Priorität haben! Die Zustimmung eines Benutzers zur Übernahme von Datennutzungskosten (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 zur genauen Bestimmung des Landes und der Zeitzone passt in den Speicher eines Fahrzeugs. Damit und mit einer vollständig implementierten Strategie zur Aktualisierung der Zeitzonen- (und Länder-)Informationen nach Bedarf kann man das Land/die Zeitzone basierend auf der vom Standort-Subsystem erhaltenen GNSS-Position rückwärts geokodieren.

Vorteile Nachteile
  • Kann die richtige Zeitzone eindeutig bestimmen.
  • Erfordert keine Internetverbindung (im Falle einer lokalen Datenbank).
  • Funktioniert zuverlässig in den meisten Fahrszenarien.
  • Android unterstützt dies nicht standardmäßig.
  • Wenn sich das Fahrzeug in Innenräumen/in einem überdachten Bereich befindet, in dem während der Erstkonfiguration kein guter GNSS-Satellitenempfang möglich ist, ist es unmöglich, genaue Zeit-, Standort- und Zeitzoneninformationen zu erhalten.
  • Die lokale Datenbank benötigt einen Aktualisierungsmechanismus.
  • Komplexität der Implementierung.

Telefon über Bluetooth, WLAN oder USB verbunden

Mehrere Technologien können verwendet werden, um das Telefon eines Benutzers zu nutzen, um Zeit- und Zeitzonendaten abzurufen. Für alle Telefone müssen ein Paar benutzerdefinierter Apps und Begleit-Apps auf dem Telefon und dem IVI-System (In-Vehicle Infotainment) installiert sein. Anschließend ist es möglich, die Zeit im gewünschten Intervall zu synchronisieren. Zum Beispiel beim Verbindungsaufbau und wenn das Telefon eine neue Zeitzone erkennt.

Einige Telefone, die Bluetooth Low Energy (BLE) unterstützen, bieten die Möglichkeit, die Uhrzeit über das GATT Current Time-Merkmal 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 verlassen zu können.

Vorteile Nachteile
  • Erfordert keine Internetverbindung.
  • Per Telefon erkannte Zeitzonenänderungen können an die Haupteinheit weitergeleitet werden.
  • Android unterstützt dies nicht standardmäßig.
  • Funktioniert nur, wenn das Telefon mit der Haupteinheit verbunden ist.
  • Die Zeit ist so gut oder schlecht wie das, was das Telefon bietet.
  • Die Umsetzung ist komplex.
  • Nicht alle Telefone unterstützen das BLE GATT Current Time Service-Profil.

Nutzen Sie Quellen

Jeder Geräteanbieter muss festlegen, wie hoch die Messlatte anzusetzen ist und welche User Journeys er als am kritischsten erachtet. Nur mit einem klaren Verständnis der gewünschten kritischen Benutzererlebnisse kann die beste Entscheidung getroffen werden. In den meisten Fällen müssen Anbieter den Kompromiss zwischen Benutzerfreundlichkeit und Implementierungskomplexität berücksichtigen.

Jede oben beschriebene Option bringt Vor- und Nachteile mit sich. Beispielsweise muss eine entscheidende Designentscheidung im Hinblick darauf getroffen werden, wie viel Belastbarkeit im Vergleich zu gelegentlich schlechter Zeitanzeige akzeptabel ist und wie mit den Nachteilen umgegangen werden kann. Eine vollautomatische Lösung, von der man erwarten kann, dass sie in allen Szenarien gut funktioniert, muss jedoch auf einer Kombination mehrerer Informationsquellen basieren. Keine einzelne Option kann eine 100-prozentige Verfügbarkeit bieten.

Eine manuelle Konfigurationsmöglichkeit als temporärer Fallback ist einfach durchzuführen und kann in der Praxis für viele Benutzer ausreichend sein.