Параметры часового пояса

Точное отображение времени — основная функция автомобильной информационно-развлекательной системы. Хотя это может показаться обманчиво простым, особенно когда ожидания относительно управления временем и часовыми поясами невелики и должны быть выполнены, время быстро становится сложным, когда необходимо отображать надежно точные дату и время без ручного вмешательства.

Все часы реального времени, обычно используемые в системах на кристалле (SoC), содержат некоторый дрейф, который накапливается с течением времени и может привести к значительной ошибке, если его не исправить. Кроме того, поскольку ожидается, что местное время будет отображаться точно, необходимо учитывать правильное смещение от всемирного координированного времени (UTC).

Можно ожидать, что информация о часовом поясе, а также применение летнего времени (DST) изменятся в течение ожидаемого срока службы транспортного средства. Например, после многих лет внедрения летнего времени Бразилия решила не вводить график летнего времени в 2019 году.

Android предоставляет инфраструктуру, необходимую для устранения сложностей управления правилами часовых поясов. Дополнительные сведения см. в разделе Правила часовых поясов , которые позволяют OEM-производителям передавать обновленные данные правил часовых поясов на устройства, не требуя обновления системы. Этот механизм позволяет:

  • Пользователи получают своевременные обновления (которые продлевают срок службы устройства Android).
  • OEM-производители должны тестировать обновления часовых поясов независимо от обновлений образа системы.

Примечание. AAOS 10 не поддерживает механизм обновления модулей на основе APEX, представленный в версиях Android 10 (и более поздних версиях).

Примечание. Для реализации этого механизма необходима перезагрузка системы.

Источники информации о времени (зоне) в автомобилях

Устройства Android управляют временем в формате Unix на уровне системы, применяют желаемое смещение часового пояса, а затем преобразуют значение в местное время для отображения пользователям. Идентификатор зоны текущего пользователя (часто называемый идентификатором Олсона) сохраняется как настройка. Например, Европа/Лондон .

Большая часть механизма, описанного ниже, описывает информацию о времени. Целью этих стандартов является предоставление пользователям текущего времени, а не описание применимых правил часового пояса. Чтобы определить фактический часовой пояс, устройство должно учитывать такие факторы, как страна, смещение и смещение летнего времени, прежде чем устанавливать идентификатор зоны.

Этот процесс может оказаться непростой задачей. Обратные действия на основе доступной информации могут быть неоднозначными. Например, правило часового пояса в Америке/Денвере соблюдает летнее время, но летом переходит на горное летнее время (MDT), тогда как Америка/Феникс продолжает признавать MDT.

Сотовая радиосвязь

Системная информация (SI) является важным аспектом радиоинтерфейса долгосрочного развития (LTE), который передается базовой станцией (BS) по широковещательному каналу управления (BCCH). 3GPP TS 36.331 определяет SystemInformationBlockType16 (SIB16), который содержит информацию, относящуюся к GPS и всемирному координированному времени (UTC), смещению местного времени, а также информацию о летнем времени.

Аналогичные функции можно найти в 2G и 3G, где может передаваться информация об идентификаторе сети и часовом поясе (NITZ) (подробности см. в 3GPP TS 22.042). Другие стандарты сотовой радиосвязи имеют аналогичные функции.

К сожалению, большинство стандартов объединяет то, что отправка этой информации не является обязательной, поэтому она доступна не во всех сетях.

Плюсы Минусы
  • Если доступно, предоставляет большую часть необходимой информации.
  • Простота, уже поддерживаемая Android, когда сотовая связь используется как телефон, а не только как модем для передачи данных.
  • Не требует подключения к Интернету.
  • Нет никаких гарантий, что информация будет транслироваться или что базовая станция будет правильно настроена.

  • В приграничных регионах существует вероятность подключения (роуминговой) вышки сотовой связи из соседней страны и потенциально передачи неправильного часового пояса.

  • В некоторых местах для установки обновлений могут потребоваться часы или даже дни.

Протокол сетевого времени

Протокол сетевого времени (NTP) часто используется для получения относительно точной информации о времени эпохи Unix. Android поддерживает синхронизацию своего системного времени с временем NTP-сервера, если его можно предоставить клиентам RadioManager через общие метаданные RadioTuner.getParameters() . NTP обновляет системное время, когда оно не синхронизировано, и оператор связи в последнее время не предоставил обновление NITZ. Если пользователь включает AUTO_TIME когда NITZ недоступен, система немедленно проверяет сетевое время.

Плюсы Минусы

Простота, поддерживаемая Android.

  • Неполный, NTP предоставляет только одно необходимое значение (время). Даже в лучшем случае NTP не сможет указать часовой пояс.

  • Требуется подключение к Интернету.

Радиовещательный тюнер

Хотя использование встроенного тюнера для получения информации о времени и часовом поясе является привлекательным, есть и проблемы. Многочисленные стандарты радиовещания определяют варианты предоставления желаемой информации. Вообще говоря, тюнер радиовещания предоставляет ту же информацию, что и сотовая радиосвязь.

ETSI EN 300 401 V1.4.1 (2006-06), раздел 8.1 определяет функции служебной информации, которые предоставляют дополнительную информацию об услугах как для аудиопрограмм, так и для данных для систем цифрового аудиовещания (DAB). Раздел 8.1.3 определяет формат времени и даты, а также информацию о смещении времени страны и местного времени.

Аналогично, для системы радиоданных (RDS), обычно реализуемой в FM-тюнерах, раздел 3.1.5.6 стандарта EN 50067 определяет формат времени и данных (передаваемых один раз в минуту). Кроме того, расширенный код страны (ECC) также может быть получен как часть передаваемой идентификации программы.

HD Radio содержит соответствующие опции как часть описания конструкции радиоинтерфейса HD Radio™ в спецификации транспорта информационной службы станции в сообщении с параметрами информационной службы станции (SIS) (MSG ID 0111). В разделе 5 четко излагаются предостерегающие слова, которые следует учитывать при попытке использовать тактовую поддержку вещания. Та же мудрость в равной степени применима и к другим системам:

... эти данные описывают местные обычаи в месте нахождения вещательной компании, которые могут совпадать, а могут и не совпадать с местными обычаями в месте получателя. Вблизи границ часовых поясов потребители могут принимать множество станций, предоставляющих разные данные. Поэтому эти данные предоставляются только в качестве подсказок, интерпретация и использование которых должны осуществляться по усмотрению и под контролем клиента. ..."

Кроме того, по крайней мере для HD Radio, трансляция этой информации не является обязательной и на нее не следует полагаться исключительно.

Плюсы Минусы
  • Обычно доступно в различных региональных стандартах радиовещания.
  • Не требует подключения к Интернету.
  • Android не поддерживает это из коробки.
  • Требует включения тюнера (хотя бы изредка в фоновом режиме) для достоверного обнаружения информации.
  • Надежность зависит от вещателя.

Советы по внедрению

Android поддерживает синхронизацию своего системного времени с временем NTP-сервера, если оно может быть доступно клиентам RadioManager . Рекомендуемое решение — использовать функцию расширения поставщика. Реализация этой функциональности должна происходить на уровне аппаратной абстракции (HAL), после чего она может быть доступна клиентам RadioManager через общий метод RadioTuner.getParameters() .

Чтобы решение оставалось надежным, потребитель этого расширения поставщика должен убедиться, что HAL поддерживает эту функцию (не предполагать ее существование). Строки параметров для вызова getParameters должны быть четко организованы для однозначного использования разными поставщиками. Например, используя пространство имен вашей организации, добавив к нему префикс соответствующего домена, например com.me.timezoneTuner.currenttimezone .

Учитывая событийно-ориентированный характер информации, может быть полезно использовать обратный вызов RadioTuner.Callback.onParametersUpdated() для получения этой информации. Если это средство должно быть настраиваемым, создайте набор пользовательских процедур поверх setParameters . Например:

com.me.timezoneTuner.currenttimezoneEvent.enable

Сама по себе Глобальная навигационная спутниковая система (ГНСС) может предоставлять только точную информацию о времени и местоположении.

Геолокация

Решением этого неудобства является выполнение обратного геокодирования и определение страны и часового пояса путем поиска на основе местоположения. GNSS — это очевидный (и лучший) выбор информации о местоположении в транспортном средстве. API часовых поясов Google предлагает все необходимое для выполнения необходимой конверсии. Конечно, необходимо подключение к Интернету. Обеспечение конфиденциальности пользователей должно быть главным приоритетом при внедрении онлайн-решения! Разрешение пользователя принимать (или нет) расходы на использование данных требуется и должно быть запрошено.

Вполне возможно создать подходящее решение для автономного использования. База данных местных карт с достаточным разрешением для точного определения страны и часового пояса может поместиться в багажнике автомобиля. Благодаря этому и полностью реализованной стратегии обновления информации о часовом поясе (и стране) по мере необходимости можно выполнить обратное геокодирование страны/часового пояса на основе положения GNSS, полученного из подсистемы местоположения.

Плюсы Минусы
  • Может однозначно определить правильный часовой пояс.
  • Не требует подключения к Интернету (в случае локальной БД).
  • Надежно работает в большинстве сценариев вождения.
  • Android не поддерживает это из коробки.
  • Если автомобиль находится в помещении или на крытой территории, где хороший прием спутников GNSS невозможен во время первоначальной настройки, невозможно получить точную информацию о времени, местоположении и часовом поясе.
  • Локальной базе данных нужен механизм обновления.
  • Сложность реализации.

Телефон подключен через Bluetooth, Wi-Fi или USB

Чтобы использовать телефон пользователя для получения данных о времени и часовом поясе, можно использовать несколько технологий. Для всех телефонов на телефоне и в бортовой информационно-развлекательной системе (IVI) должна быть установлена ​​пара специальных приложений и сопутствующих приложений. После этого можно синхронизировать время с нужным интервалом. Например, при установлении соединения и когда телефон обнаруживает новый часовой пояс.

Некоторые телефоны, поддерживающие Bluetooth Low Energy (BLE), предоставляют возможность получения времени с помощью характеристики текущего времени GATT и спецификации профиля службы текущего времени 1.1 . Однако этот вариант не затрагивает достаточно большой сегмент рынка, на который можно полагаться исключительно.

Плюсы Минусы
  • Не требует подключения к Интернету.
  • Изменения часового пояса, обнаруженные телефоном, могут быть переданы на головное устройство.
  • Android не поддерживает это из коробки.
  • Работает только пока телефон подключен к головному устройству.
  • Время так же хорошо или плохо, как и то, что дает телефон.
  • Реализация сложна.
  • Не все телефоны поддерживают профиль службы текущего времени BLE GATT.

Использовать источники

Каждый поставщик устройств должен определить, какую высокую планку следует установить и какие действия пользователя следует считать наиболее важными. Только при четком понимании желаемого критического пользовательского опыта можно принять лучшее решение. В большинстве случаев поставщики должны учитывать компромисс между удобством и сложностью реализации.

Каждый описанный выше вариант имеет свои преимущества и недостатки. Например, необходимо сделать критический выбор конструкции в отношении того, насколько допустима устойчивость по сравнению с периодическим плохим отображением времени и как справиться с недостатками. Полностью автоматическое решение, которое, как можно ожидать, будет хорошо работать во всех сценариях, но должно быть основано на сочетании нескольких источников информации. Ни один вариант не может обеспечить 100% доступность.

Вариант ручной настройки в качестве временного резерва прост в реализации и на практике может быть достаточным для многих пользователей.