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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Нет никаких гарантий, что информация будет транслироваться или что базовая станция будет правильно настроена.

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

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

Сетевой протокол времени

Network Time Protocol (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 содержит соответствующие опции как часть спецификации Station Information Service Transport Design Description HD Radio™ в сообщении параметров Station Information Service (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, полученной из подсистемы Location.

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

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

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

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

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

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

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

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

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