정확한 시간 표시는 자동차 인포테인먼트 시스템에 요구되는 핵심 기능입니다. 이는 특히 시간과 시간대 관리의 기대치가 낮고 충족되어야 할 때 언뜻 간단해 보일 수 있지만 수동 개입 없이 확실하게 정확한 날짜와 시간을 표시해야 하는 경우 시간은 금세 복잡해집니다.
일반적으로 단일 칩 시스템(SoC)에서 사용되는 모든 실시간 시계에는 드리프트가 포함되어 있고 이 드리프트는 시간이 지남에 따라 누적되므로 수정하지 않은 채로 두면 심각한 오류가 발생할 수 있습니다. 또한 현지 시간이 정확하게 표시될 것이라는 기대치가 높기 때문에 협정 세계시(UTC)로부터의 정확한 오프셋을 고려해야 합니다.
시간대 정보뿐만 아니라 일광 절약 시간(DST) 적용이 차량의 예상 수명 동안 변경될 수 있습니다. 예를 들어 수년간 DST를 시행한 브라질은 2019년 DST를 폐지하기로 했습니다.
Android는 시간대 규칙 관리의 정보 표시 협상에 필요한 인프라를 제공합니다. 자세한 내용은 시간대 규칙을 참고하세요. 이 규칙을 통해 OEM은 시스템 업데이트 없이 업데이트된 시간대 규칙 데이터를 기기에 푸시할 수 있습니다. 이 메커니즘으로 다음 작업을 할 수 있습니다.
- 사용자가 시기적절하게 업데이트를 받게 되므로 Android 기기의 유용한 전체 기간이 연장됩니다.
- OEM이 시스템 이미지 업데이트와 별개로 시간대 업데이트를 테스트합니다.
참고: AAOS 10에서는 Android 10 이상 버전에서 제공되는 APEX 기반 모듈 업데이트 메커니즘을 지원하지 않습니다.
참고: 이 메커니즘을 구현하려면 시스템 재부팅이 필요합니다.
자동차의 시간(대) 정보 소스
Android 기기는 시스템 수준에서 Unix 시간으로 시간을 관리하고 원하는 시간대 오프셋을 적용한 후 값을 현지 시간으로 변환하여 사용자에게 표시합니다. 현재 사용자의 시간대 ID(Olson ID라고도 함)가 설정으로 저장됩니다. 예: 유럽/런던
아래에 간략히 설명된 메커니즘의 대부분은 시간 정보를 설명합니다. 이러한 표준의 목적은 사용자에게 현재 시간을 제공하는 것이지 관련 시간대 규칙을 설명하는 것이 아닙니다. 실제 시간대를 확인하려면 시간대 ID를 설정하기 전에 기기에서 국가, 오프셋, DST 오프셋과 같은 요소를 확인해야 합니다.
이 프로세스는 까다로울 수 있습니다. 사용 가능한 정보에 기반하여 다시 작업하는 것은 명확하지 않을 수 있습니다. 예를 들어 시간대 규칙 미국/덴버는 DST를 준수하지만 여름에는 산악 여름 시간(MDT)을 채택하는 반면 미국/피닉스는 MDT를 계속 사용합니다.
셀룰러 라디오
시스템 정보(SI)는 기지국(BS)에서 방송 제어 채널(BCCH)을 통해 전송하는 LTE(Long-Term Evolution) 무선 인터페이스의 필수 요소입니다. 3GPP TS 36.331은 GPS 및 협정 세계시(UTC) 관련 정보와 현지 시간 오프셋, DST 정보까지 포함된 SystemInformationBlockType16(SIB16)을 지정합니다.
유사한 기능을 2G 및 3G에서 확인할 수 있으며 이러한 네트워크에서는 네트워크 ID 및 시간대(NITZ) 정보를 브로드캐스트할 수 있습니다(자세한 내용은 3GPP TS 22.042 참고). 기타 무선 라디오 표준에도 동일한 기능이 있습니다.
안타깝게도 대부분의 표준 간 공통점은 이 정보의 전송이 선택사항이라서 모든 네트워크에서 보편적으로 사용할 수 없다는 것입니다.
| 장점 | 단점 |
|---|---|
|
|
네트워크 시간 프로토콜(NTP)
네트워크 시간 프로토콜(NTP)은 비교적 정확한 Unix 에포크 시간 정보를 얻는 데 자주 사용됩니다. Android는 NewNetworkTimeUpdateService를 사용하여 처음부터 NTP 서버와 시스템 시간의 동기화를 지원합니다. NTP에서는 시스템 시간이 동기화되지 않고 최근 이동통신사에서 NITZ 업데이트를 제공하지 않았다면 네트워크 시간을 모니터링하고 시스템 시간을 업데이트합니다.
NITZ를 사용할 수 없을 때 사용자가 AUTO_TIME을 사용 설정하면 시스템은 네트워크 시간을 즉시 확인합니다.
| 장점 | 단점 |
|---|---|
|
단순성은 Android에서 지원합니다. |
|
방송 라디오 튜너
기본 제공되는 튜너를 활용하여 시간과 시간대 정보를 검색하는 것이 좋지만 어려운 점도 있습니다. 수많은 라디오 방송 표준은 원하는 정보를 노출하는 옵션을 정의합니다. 일반적으로 방송 라디오 튜너는 무선 라디오와 동일한 정보를 제공합니다.
ETSI EN 300 401 V1.4.1(2006-06), 8.1항은 디지털 오디오 방송(DAB) 시스템용 오디오 프로그램 및 데이터 서비스 관련 추가 정보를 제공하는 서비스 정보 기능을 명시합니다. 8.1.3항은 국가 및 현지 시간 오프셋 정보와 함께 시간과 날짜 형식을 규정합니다.
마찬가지로 FM 튜너에서 일반적으로 구현되는 무선 데이터 시스템(RDS)의 경우 EN 50067 표준 3.1.5.6항에서 시계 시간 및 데이터(분당 한 번 전송됨) 형식을 규정합니다. 또한 확장된 국가 코드(ECC)도 전송된 프로그램 식별의 일부로 검색할 수 있습니다.
HD 라디오에는 SIS(Station Information Service) 매개변수 메시지(MSG ID 0111)의 HD Radio™ Air Interface Design Description Station Information Service Transport 사양의 일부로 상응하는 옵션이 포함되어 있습니다. 5항은 방송의 시계 지원을 사용하려고 할 때 유의해야 하는 사항을 명시합니다. 다른 시스템에도 동일하게 적용되는 사항입니다.
| ... 이러한 데이터는 방송사가 있는 위치의 현지 관습을 설명하며 이는 수신자가 있는 위치의 현지 관습과 동일하거나 동일하지 않을 수 있습니다. 시간대 경계 근처의 소비자는 서로 다른 데이터를 제공하는 여러 방송을 수신할 수 있습니다. 따라서 이러한 데이터는 힌트로만 제공되고 데이터의 해석과 활용은 고객의 관리에 따라 자유재량으로 이뤄져야 합니다. …" |
또한 적어도 HD 라디오의 경우 이 정보의 방송은 선택사항이므로 전적으로 의존해서는 안 됩니다.
| 장점 | 단점 |
|---|---|
|
|
구현 도움말
현재 BroadcastRadio Hal 2.0은 시간(대) 메타데이터를 처리하는 조항을 제공하지 않습니다. 따라서 공급업체 확장 프로그램 기능을 활용하는 것이 좋습니다.
이 기능의 구현은 하드웨어 추상화 계층(HAL)에서 발생해야 하며 이후 일반 RadioTuner.getParameters() 메서드를 통해 RadioManager의 클라이언트에 노출될 수 있습니다.
솔루션을 안정적으로 유지하려면 이 공급업체 확장 프로그램의 소비자가 HAL에서 이 기능(존재한다고 가정하면 안 됨)을 지원한다고 판단해야 합니다. getParameters 호출의 매개변수 문자열은 공급업체에서 명확하게 사용하도록 깔끔하게 구성되어야 합니다. 예를 들어 "com.me.timezoneTuner.currenttimezone"과 같이 적절한 도메인을 접두사로 지정하여 조직의 네임스페이스를 사용합니다.
정보의 이벤트 기반 특성을 고려하면 이 정보를 수신하는 데 RadioTuner.Callback.onParametersUpdated() 콜백을 사용하는 것이 좋을 수 있습니다. 이 기능이 구성 가능해야 하는 경우 setParameters 외에 일련의 맞춤 루틴을 설계하세요. 예:
com.me.timezoneTuner.currenttimezoneEvent.enable
글로벌항법위성시스템
글로벌항법위성시스템(GNSS)은 자체적으로 매우 정확한 시간 정보와 위치만 제공할 수 있습니다.
Geolocation
이 불편을 해결하는 방법은 역 지오코딩을 실행하고 위치에 기반한 조회를 실행하여 국가와 시간대를 확인하는 것입니다. GNSS는 차량에 선택할 수 있는 가장 적절한 위치 정보이며 가장 우수합니다. Google의 <aclass="external" l10n-attrs-original-order="href,class" l10n-encrypted-href="6z2vbshndiNBlkSF5nuHzqXc57TIW5VywCkhSp4WUypzRwGNXACB5ltAIGicGTa2qjmYZJAor4qTntaXrxsSZqMZz/kq5DDJnT+TJu5E3bE=">Time Zone API 는 필수 변환을 실행하는 데 필요한 모든 사항을 제공합니다. 물론 인터넷 연결이 필요합니다. 온라인 솔루션을 구현할 때 사용자 개인 정보 보호를 최우선으로 해야 합니다. 데이터 사용량 비용을 수락하거나 수락하지 않는 사용자 권한이 필요하므로 권한을 요청해야 합니다.</aclass="external">
오프라인 사용에 적합한 솔루션을 만들 수 있습니다. 국가와 시간대를 정확하게 확인하기에 충분한 해상도를 갖춘 현지 지도 데이터베이스가 차량 저장소에 적합할 수 있습니다. 이 데이터베이스와 필요에 따라 시간대 및 국가 정보를 업데이트하는 완전히 구현된 전략을 적절히 적용하면 위치 하위 시스템에서 가져온 GNSS 위치에 기반하여 국가/시간대를 역 지오코딩할 수 있습니다.
| 장점 | 단점 |
|---|---|
|
|
블루투스, Wi-Fi 또는 USB를 통해 연결된 휴대전화
사용자의 휴대전화를 활용하여 시간과 시간대 데이터를 얻는 데는 다양한 기술을 사용할 수 있습니다. 모든 휴대전화의 경우 맞춤 애플리케이션과 호환 앱 한 쌍이 휴대전화 및 차량용 인포테인먼트(IVI) 시스템에 설치되어 있어야 합니다. 그러면 원하는 간격으로 시간을 동기화할 수 있습니다. 연결 시 및 휴대전화에서 새로운 시간대를 감지할 때를 예로 들 수 있습니다.
저전력 블루투스(BLE)를 지원하는 일부 휴대전화에서는 GATT 현재 시간 특성 및 현재 시간 서비스 프로필 사양 1.1을 통해 시간을 검색하는 옵션을 제공합니다. 그러나 이 옵션은 전적으로 의존하기에 충분히 큰 시장 부문을 다루지 않습니다.
| 장점 | 단점 |
|---|---|
|
|
소스 사용
모든 기기 공급업체는 기준을 얼마나 높게 설정할지와 어떤 사용자 경험을 가장 중요하게 고려할지 판단해야 합니다. 원하는 중요한 사용자 환경을 명확하게 파악한 경우에만 최선의 결정을 내릴 수 있습니다. 대부분의 경우 공급업체는 편의성과 구현 복잡성 사이의 절충안을 고려해야 합니다.
위에서 설명한 각 옵션에는 장단점이 있습니다. 예를 들어 가끔 발생하는 좋지 않은 시간 표시와 비교할 때 수용할 수 있는 탄력성의 정도 및 단점 관리 방법과 관련하여 중요 설계를 선택해야 합니다. 모든 시나리오에서 잘 작동할 것으로 예상되는 완전 자동 솔루션은 여러 정보 소스의 조합에 기반해야 합니다. 단일 옵션으로는 100% 가용성을 제공할 수 없습니다.
임시 대체로서 수동 구성 옵션은 실행하기 쉽고 실제로 많은 사용자에게 충분할 수 있습니다.