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

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

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

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

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

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

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

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

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

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

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

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

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

Системная информация (SI) является важным аспектом радиоинтерфейса Long-Term Evolution (LTE), передаваемым базовой станцией (BS) по широковещательному каналу управления (BCCH). Стандарт 3GPP TS 36.331 определяет блок системной информации типа 16 (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 не может предоставить информацию о часовом поясе.

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

тюнер радиовещания

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

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

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

HD Radio содержит соответствующие параметры в рамках спецификации транспортного уровня службы информации о станции HD Radio™ Air Interface Design Description Station Information Service Transport в сообщении параметров службы информации о станции (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) может предоставлять только точную информацию о времени и местоположении.

Геолокация

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

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

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

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

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

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

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

Используйте источники

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

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

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