JP2020126317A - 車両用装置、車両用装置の時刻同期方法 - Google Patents

Abstract

【課題】１つのＣＰＵモジュール上で複数のＯＳを同時に動作させる場合において、各ＯＳの時刻を同期させる。【解決手段】実施形態の車両用装置１は、１つのＣＰＵモジュール１００上で複数のＯＳを同時に動作させるものである。このとき、各ＯＳはそれぞれ独自の時計機能に基づいて動作する。そして、車両用装置１は、いずれかのＯＳ上で行われる時刻の変更を各ＯＳに通知して各ＯＳの時刻を同期させる同期部としてのＴＭＭ２０２を備えている。【選択図】図１

Description

本発明は、車両用装置、車両用装置の時刻同期方法に関する。

車両には、ユーザに時刻を提示したり車載システムを正しく動作させたりするために時計機能が設けられている。そして、例えば特許文献１には、外部のネットワークタイムプロトコルサーバと同期させることにより、正確な時刻を保つようにすることが開示されている。以下、ネットワークタイムプロトコルをＮＴＰとも称する。

特開２０１８−１１２４２５号公報

さて、近年の車両用装置では、１つのハードウェアモジュール上で複数のオペレーティングシステムを同時に動作させるものがある。以下、オペレーティングシステムをＯＳとも称する。このような車両用装置では、例えばリアルタイム性を必要とするアプリケーションや画像等を表示するアプリケーションなどを、要求される処理速度や特性に応じて各ＯＳに割り振って動作させている。そして、各ＯＳは、それぞれ独自の時計機能を有しており、各アプリケーションは、自身が実装されているＯＳの時計機能を利用して動作する。

しかしながら、従来では、例えばあるＯＳのアプリケーションで時刻が変更されたとしても、その変更を他のＯＳに反映させることは行われていなかった。そのため、各ＯＳは、時刻がずれたままの状態、つまりは、時刻が同期していない状態で動作する可能性があった。

そして、各ＯＳの時刻が同期していない状態では、例えばあるＯＳで収集する車両情報を別のＯＳで時系列的に記録するダイアグ機能に不具合が生じることが懸念される。また、近年では情報の提供と娯楽の提供とを行う車載インフォテイメント機能を備えたものが広まりつつあるが、あるＯＳで現在時刻を表示するアプリケーションを実行し、他のＯＳで経路案内のアプリケーションを実行している場合には、異なる時刻が表示されてユーザが混乱することが懸念される。

本開示の目的は、上記した事情に鑑みてなされたものであり、１つのＣＰＵモジュール上で複数のＯＳを同時に動作させる場合において、各ＯＳの時刻を同期させることができる車両用装置、車両用装置の時刻同期方法を提供することにある。

本開示の車両用装置は、１つのハードウェアモジュール（１００）上で複数のオペレーティングシステム（２００、３００）を同時に動作させるものであって、各オペレーティングシステムはそれぞれ独自の時計機能（２０１、３０１）に基づいて動作するものであり、いずれかのオペレーティングシステム上で行われる時刻の変更を各オペレーティングシステムに通知して、各オペレーティングシステムの時刻を同期させる同期部（２０２）を備えている。このような構成により、各オペレーティングシステムの時刻を同期させることができる。

車両用装置の構成を機能ブロックとして模式的に示す図 表示画面の一例を模式的に示す図 ダイアグ情報の一例を模式的に示す図 起動時における時刻を設定する流れを示す図 ＧＮＳＳに基づく時刻の変更態様を模式的に示す図 アプリケーションにおける時刻を変更する処理の流れを示す図 ＴＭＭにおける時刻を変更する処理の流れを示す図 ＴＭＭスレッドにおける時刻を変更する処理の流れを示す図 ユーザの操作に基づく時刻の変更態様を模式的に示す図 携帯端末との接続に基づく時刻の変更態様を模式的に示す図 ＤＣＭに基づく時刻の変更態様を模式的に示す図

以下、実施形態について図面を参照しながら説明する。
図１に示すように、車両用装置１は、ハードウェアモジュールとして１つのＣＰＵモジュール１００を備えており、そのＣＰＵモジュール１００上で複数のオペレーティングシステム、ここでは、ＯＳ２００とＯＳ３００の２つが動作する仮想化環境として構成されている。以下、オペレーティングシステムを、ＯＳと称する。これらＯＳ２００およびＯＳ３００は、ハイパーバイザ４００上で同時に動作する。

ＣＰＵモジュール１００には、物理的なハードウェアとしてＣＰＵ１０１、Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍモジュール１０２（以下、ＧＮＳＳモジュール１０２）、ＲｅａｌＴｉｍｅＣｌｏｃｋ１０３（以下、ＲＴＣ１０３）、Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍｏｄｕｌｅ１０４（以下、ＤＣＭ１０４）、および各種のインターフェース群１０５などが設けられている。なお、ＣＰＵモジュール１００上に実装されているハードウェアはこれらに限定されず、例えばコンピュータプログラムを記憶するメモリなどの記憶部等も実装されている。

ＣＰＵ１０１は、車両用装置１の主たる制御部を構成しており、本実施形態では複数のコア１０１Ａを備えている。各コア１０１Ａは、一般的な仮想化環境と同様に、ＯＳ２００およびＯＳ３００で必要とされる処理能力に応じて適切な数がそれぞれ割り当てられている。コア１０１Ａの数や割り当ては、必要とされる性能等に応じて適宜選択される。

ＧＮＳＳモジュール１０２は、全球測位衛星システムの人工衛星から信号を受信するものであり、受信した信号に基づく位置の特定、および時刻の特定に用いられる。ＧＮＳＳモジュール１０２は、例えばGlobal Positioning System、GLObal NAvigation Satellite System、Galileo、準天頂衛星システム、BeiDou Navigation Satellite Systemなどの各種の方式のうち、対象となる方式に対応するものが設けられている。

ＲＴＣ１０３は、リアルタイムクロックであり、時計機能を実現する。このＲＴＣ１０３は、車両用装置１における基準となる時刻を保持している。以下、ＲＴＣ１０３に保持されている時刻を、便宜的に車両用装置１の基本時刻と称する。ＲＴＣ１０３は、図示しないバックアップ電池が接続されており、車両用装置１の電源が切られた場合でも時刻を保持し続ける。このＲＴＣ１０３は、グリニッジ標準時を記憶している。

ＤＣＭ１０４は、車両用のデータ通信装置であり、車両の外部に設けられているセンターとの間、あるいは、車両に設けられている他のＥｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ５０（以下、ＥＣＵ５００）との間やで通信を行う。例えば、ＤＣＭ１０４は、ＥＣＵ５００から収集した車両情報をネットワーク経由でセンターに送ったり、センターからの情報を受信してユーザに報知したり、万が一事故が発生した場合には自動でセンターに接続して事故が発生した位置や時刻を伝えたりする。

インターフェース群１０５は、車内で各種の通信を行うインターフェースで構成されている。インターフェース群１０５は、有線方式や無線方式あるいは双方の方式のものを備えている。例えば、インターフェース群１０５は、ＥＣＵ５００やメータ５０１との間で通信を行うＣＡＮインターフェースや、ユーザが所有する携帯端末５０２との間で通信を行うＵＳＢのような有線インターフェースや近距離無線インターフェースを備えている。

また、ＣＰＵモジュール１００は、表示装置５０３に接続されている。表示装置５０３は、車両用装置１の操作メニューや基本時間あるいは各種のアプリケーションの実行結果などを表示する。ただし、表示装置５０３は１つに限らず、車両用装置１に複数接続することができる。

また、ＣＰＵモジュール１００は、ユーザの操作が入力される操作装置５０４に接続されている。この操作装置５０４は、操作スイッチや表示装置５０３の画面に設けられているタッチパネル、あるいはそれらを組み合わせたものとして構成されている。なお、メータ５０１を例えば液晶パネルで構成し、ＣＰＵモジュール１００で速度計や回転数計の画像の生成処理や表示処理を行う構成とすることもできる。つまり、車両用装置１に接続される表示装置５０３は、１つに限定されず、複数個に接続する構成とすることができる。

次にＯＳ２００およびＯＳ３００について説明する。なお、ＯＳ２００、ＯＳ３００上では各種のコンピュータプログラムが実行されるが、説明の簡略化のために、本実施形態ではＯＳ２００およびＯＳ３００で実行されるコンピュータプログラムをアプリケーションと称している。ただし、特定の機能を有するアプリケーションについて説明する場合には、例えば後述するように、位置アプリ２０４や時計アプリ２０５等とも称する。

さて、１つの車両用装置１で複数のＯＳを動作させる場合、リアルタイム性能が要求されるＯＳと、マルチメディア処理などの汎用的な処理が得意なＯＳとを混在させることが一般的に行われている。

本実施形態の場合、ＯＳ２００として、いわゆるリアルタイムＯＳを採用している。このＯＳ２００は、ＯＳ３００に比べて相対的にリアルタイム性に優れており、高い処理速度が必要とされるアプリケーションが実行される。このとき、ＯＳ２００は、時計機能に相当するシステムクロック２０１に基づいて動作する。つまり、ＯＳ２００は、ＯＳ３００とは共有されていない独自の時計機能を有している。システムクロック２０１に保持されている時刻は、ＯＳ２００の基本時刻になる。

このＯＳ２００上では、例えば同期部としてのＴｉｍｅ Ｍａｎａｇｅｍｅｎｔ ｍｏｄｕｌｅ２０２（以下、ＴＭＭ２０２）、サーバ側となるＮｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ ｄａｅｍｏｎ２０３（以下、ＮＴＰＤ２０３）、位置アプリ２０４、時計アプリ２０５などが実装されている。ただし、ＯＳ２００上に実装されているアプリケーションはこれらに限定されず、ＯＳ２００および車両用装置１の動作や制御に必要となるＭｉｓｃｅｌｌａｎｅｏｕｓアプリ２０６（以下、ＭＩＳＣ２０６）が実装されている。

ＴＭＭ２０２は、ＯＳ２００とＯＳ３００との間で時刻を同期させる同期部として機能する専用のアプリケーションである。このＴＭＭ２０２は、詳細は後述するが、ＲＴＣ１０３からの時刻の読み出し、ＲＴＣ１０３が保持している時刻の書き替え、各アプリケーションからの時刻の変更要求の受け付け、および、変更要求を受け付けた後に他方つまりは自身が動作するＯＳ２００とは異なる別のＯＳ３００に対して時刻の変更を通知する機能を備えている。

このＴＭＭ２０２は、ＯＳ２００に実装されている。そのため、車両用装置１内では、ＯＳ２００がマスターとなり、ＯＳ３００がスレーブとなる態様で時刻の同期が行われる。なお、ＣＰＵモジュール１００上に３以上のＯＳが構築されている場合には、いずれか１つのＯＳがマスターとなり、他のＯＳはスレーブとすることで同様の環境を構築できる。

ＮＴＰＤ２０３は、いわゆるＮｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌサーバ（以下、ＮＴＰサーバ）として機能するアプリケーションである。このＮＴＰＤ２０３は、ＯＳ３００側に設けられているクライアント側のＮＴＰＤ３０３からの要求に応じて自身が保持している時刻を提供する。つまり、車両用装置１内では、ＮＴＰを利用した時刻の同期が行われている。

位置アプリ２０４は、ＧＮＳＳモジュール１０２を利用するアプリケーションである。位置アプリ２０４は、例えば現在位置の特定および正確な時刻の特定を行う機能を備えている。つまり、位置アプリ２０４は、車両用装置１の外部から時刻を取得可能なアプリケーションである。換言すると、位置アプリ２０４および後述する時刻を取得可能な他のアプリケーションは、ＲＴＣ１０３に保持されている車両用装置１の基本時間を正確なものに変更または修正することができる正確な時刻を取得できるアプリケーションである。

位置アプリ２０４は、特定した時刻に基づいて車両用装置１の時刻を変更する機能を備えている。ただし、後述するように、本実施形態では位置アプリ２０４による時刻の変更は、本実施形態ではＴＭＭ２０２を介して行われる構成となっている。

時計アプリ２０５は、基本時刻を表示する機能や、ユーザからの時刻の変更を受け付ける機能などを備えたアプリケーションである。つまり、時計アプリ２０５は、車両用装置１の外部からの時刻の取得ここでは時刻の設定が可能なアプリケーションである。この時計アプリ２０５は、例えば図２に示すように、表示装置５０３の画面５０３Ａに、現在時刻Ｍ１を例えば２０１０年１月１日、１０：００ａｍのように表示する。なお、現在時刻等の表示態様は図２に示す例に限定されず、ユーザが認識可能な表示態様であればよい。

また、時計アプリ２０５は、ユーザによる時刻の変更操作を受け付ける。この変更操作には、例えば各国や地域の時間に合わせる操作や、ユーザ自身が時刻を設定する操作が含まれる。ただし、後述するように、本実施形態では時計アプリ２０５による時刻の変更は、ＴＭＭ２０２を介して行われる構成となっている。

このＯＳ２００は、ソフトウェアで実現されているサービスバス２０７によってＯＳ３００との間で各種の通信可能に構成されている。ＯＳ３００は、いわゆる汎用ＯＳであり、ＯＳ２００に比べて相対的に処理速度が必要とされないアプリケーションや、画像や動画など汎用的な処理が必要となるアプリケーションなどが実行される。このとき、ＯＳ３００は、時計機能を実現しているシステムクロック３０１に基づいて動作する。つまり、ＯＳ３００は、ＯＳ２００とは共有されていない独自の時計機能を有している。

このＯＳ３００上では、例えばシステム設定アプリ３０２、クライアント側となるＮＴＰＤ３０３、ＨＭＩアプリ３０４、ナビゲーションアプリ３０５、電話アプリ３０６、テレマティックスアプリ３０７、ダイアグアプリ３０８などが実装されている。ただし、ＯＳ３００上に実装されているアプリケーションはこれらに限定されず、ＯＳ３００および車両用装置１の動作や制御に必要となる各種のＭＩＳＣアプリ３０９が実装されている。

システム設定アプリ３０２は、ＯＳに対する各種の設定を行うアプリケーションである。このシステム設定アプリ３０２には、ＯＳ内の各種の設定を行うアプリケーションが含まれている。また、このシステム設定アプリ３０２の１つとして、ＯＳ内の時刻の変更に関連する処理を行うＴＭＭスレッド３１０が実装されている。

ＴＭＭスレッド３１０は、ＯＳ２００のＴＭＭ２０２からの通知を受け取るアプリケーションである。ＴＭＭスレッド３１０は、詳細は後述するが、ＴＭＭ２０２との間で通信を行うことにより、ＴＭＭ２０２から通知された時刻の変更を例えばシステムクロック３０１やクライアント側のＮＴＰＤ３０３などのアプリケーションに通知する機能を備えている。システムクロック３０１が保持する時刻は、ＯＳ３００の基本時刻になる。なお、ＴＭＭスレッド３１０も、同期部を構成するプログラムの一部であると言える。

ＮＴＰＤ３０３は、いわゆるＮＴＰクライアントとして機能するアプリケーションである。ＮＴＰＤ３０３は、ＯＳ２００側に実装されているサーバ側のＮＴＰＤ２０３と通信することによってＯＳ３００側の基準となる時刻を取得する。

ＨＭＩアプリ３０４は、ヒューマンマシンインターフェースを提供するアプリケーションである。このＨＭＩアプリ３０４は、例えば車両用装置１の操作メニューなどを表示するとともに、操作装置５０４から入力された操作を受け付ける。つまり、ＨＭＩアプリ３０４は、ＯＳ側の時計アプリ２０５と連係することにより車両用装置１の外部から時刻を取得、ここではユーザによる設定が可能なアプリケーションである。

ナビゲーションアプリ３０５は、目的地までの経路案内などのいわゆるカーナビゲーションを実現するアプリケーションである。ナビゲーションアプリ３０５は、例えば図２に示すように、目的地が設定されると、目的地マークＭ２、経路案内画面Ｍ３、現在時刻Ｍ４、目的地までの経路Ｍ５、予想所要時間Ｍ６あるいは予想到着時刻Ｍ７などを表示する。なお、図２はナビゲーション画面の一例であり、表示する情報や表示形式はこれに限定されない。

電話アプリ３０６は、ユーザが所有する携帯端末５０２を車両用装置１側から利用可能にするアプリケーションである。電話アプリ３０６は、携帯端末５０２に設定されている時刻の取得、いわゆるハンズフリー通話、携帯端末５０２が受信したメールの表示など、車両用装置１と携帯端末５０２とを連係させて動作する処理を行う。つまり、電話アプリ３０６は、車両用装置１の外部から時刻を取得可能なアプリケーションである。ただし、電話アプリ３０６が行う処理はこれらに限定されない。

テレマティックスアプリ３０７は、速度や位置あるいは車両の振れなどの車両情報の収集、外部のセンターから時刻を含む情報の取得などを行うアプリケーションである。つまり、テレマティックスアプリ３０７は、車両用装置１の外部から時刻を取得可能なアプリケーションである。テレマティックスアプリ３０７は、収集した車両情報に基づく解析や故障や事故が発生した場合のセンターへの通報などの処理を行う。ただし、テレマティックスアプリ３０７が行う処理はこれらに限定されない。

ダイアグアプリ３０８は、車両用装置１のログを記録するアプリケーションである。ダイアグアプリ３０８は、収集した車両情報を時系列的に記録したり、アプリケーションで生じたイベントなどを記録したりする処理を行う。ただし、ダイアグアプリ３０８が行う処理はこれらに限定されない。

ダイアグアプリ３０８は、例えば図３に一例を示すように、ＯＳ２００側で取得された現在位置情報Ｍ１０と、ＯＳ３００側で他のＥＣＵ５００から収集した例えば速度等の車両情報Ｍ１１とをタイムスタンプＭ１２を付してログＭ１３として記録する。図３の場合、２０１０年１月１日の午前１０時００分００秒に、北緯３４．９９１０２２度、東経１３７．００９８７５度の位置を、速度２０．００ｋｍ／ｈで走行していることが記録されている。なお、図３に示すログＭ１３は一例であり、ダイアグアプリ３０８が収集および記録する情報やその記録態様はこれに限定されない。

ハイパーバイザ４００は、仮想化環境において１つまたは複数のＯＳを動作させるアプリケーションである。本実施形態の場合、ハイパーバイザ４００は、ＯＳ２００が備える機能により実現されている。そのため、車両用装置１は、厳密に言えばＣＰＵモジュール１００上でＯＳ２００が動作し、そのＯＳ２００のハイパーバイザ機能上でＯＳ３００が動作する構成となっている。

このハイパーバイザ４００上には、ＯＳ２００およびＯＳ３００が動作する際に利用される仮想ＲＴＣ４０１や、仮想ＲＴＣ４０１よりも詳細な時計機能を実現する仮想ＨＩＧＨ プレシジョン Ｅｖｅｎｔ Ｔｉｍｅｒ４０２（以下、仮想ＨＰＥＴ４０２）などが実装されている。ただし、図１では図示を省略しているが、ハイパーバイザ４００上には各種のハードウェアを仮想化した他の仮想デバイスも実装されている。ハイパーバイザ４００上で動作する仮想デバイスやＯＳの数や種類はこれらに限定されない。

次に、上記した構成の作用について説明する。
まず、車両用装置１の起動時において時刻を設定するシーケンスに基づいて、各ＯＳの時計機能にどのようにして初期の時刻が設定されるのかを説明する。

車両用装置１の電源がオンされると、ＣＰＵモジュール１００上ではＯＳが最初に起動する。なお、本実施形態では上記したようにハイパーバイザ４００がＯＳ２００の機能として提供されていることからＯＳ２００が最初に起動することになるが、一般的な仮想化環境の場合にはハイパーバイザ４００が最初に起動することになる。

ＯＳ２００が起動すると、ＴＭＭ２０２が動作を開始する。動作を開始したＴＭＭ２０２は、図４に矢印４Ａにて示すようにＲＴＣ１０３から時刻を取得する。そして、ＴＭＭ２０２は、取得した時刻を矢印４Ｂにて示すようにシステムクロック２０１に設定し、システムクロック２０１からサーバ側のＮＴＰＤ２０３が矢印４Ｃにて示すように時刻が取得される。このようにして、ＯＳ２００側の基本時刻は設定および保持される。

さて、ＯＳが起動すると、ハイパーバイザ４００も動作を開始する。このとき、仮想ＲＴＣ４０１および仮想ＨＰＥＴ４０２に時刻が設定される。そして、ハイパーバイザ４００上でＯＳ３００が起動すると、矢印４Ｄにて示すように、クライアント側のＮＴＰＤ３０３がサーバ側のＮＴＰＤ２０３にアクセスして時刻を取得する。その後、矢印４Ｅにて示すように、取得した時刻がシステムクロック３０１に設定され、ＯＳ３００側にも基本時刻が設定および保持される。

このため、ＯＳ２００およびＯＳ３００は、起動した時点ではそれぞれの基本時刻が同期している。そして、ＯＳ２００はシステムクロック２０１に基づいて動作し、ＯＳ３００はシステムクロック３０１に基づいて動作する。このとき、例えば図２に示したように現在時刻Ｍ１を表示しつつナビゲーション画面にも時刻を表示する場合には、現在時刻Ｍ１はＯＳ２００側のシステムクロック２０１が保持する基本時間に基づいた時刻が表示され、ナビゲーション画面の現在時刻Ｍ４はＯＳ３００側のシステムクロック３０１が保持する基本時間に基づいて表示される。

さて、従来では、例えばＯＳ２００側のアプリケーションで時刻が変更されたとしても、その変更をＯＳ３００側に反映させることは行われていなかった。そのため、ユーザやアプリケーションによって時刻の変更が行われた場合、あるいは、仮想化環境に特有の事例としてＯＳ２００側の処理能力を高めるためにＯＳ３００側の処理速度を低下させるような場合などにおいては、ＯＳ間で時刻のずれが生じた状態、すなわち、ＯＳ間で時刻の同期がとれていない状態となる可能性があった。

そして、ＯＳ間で時刻の同期がとれていない状態では、車両用装置１に各種の問題が発生するおそれがある。例えば図２の例であれば、１つの画面上に異なる時刻が表示されてしまい、ユーザが混乱するおそれがある。また、例えば図３に示す例であれば、位置と速度とのタイムスタンプがずれてしまい、データ解析時に不具合が生じるおそれがある。また、ＮＴＰの仕様により、１０００ｍｓｅｃ以上のずれが発生しているとＮＴＰを利用した時刻の同期させることができなくなるため、ＯＳ間で時刻を同期させること自体ができなくなるおそれがある。

そこで、車両用装置１は、各ＯＳの時刻を同期させる同期部ここではＴＭＭ２０２により、各ＯＳの時刻を同期させる構成となっている。以下、車両用装置１の基本時刻が変更される幾つかの要因と、その要因に対するＴＭＭ２０２の動作とを説明する。ただし、要因が異なる場合であってもアプリケーションの動作、ＴＭＭ２０２およびＴＭＭスレッド３１０の処理の流れは基本的には共通しているため、いずれの要因についても、時刻の変更に関連する処理を抽出した図６から図８を参照して説明する。また、各要因において処理が重複する部分については詳細な説明は省略する。

＜ＧＮＳＳに基づく基本時刻の変更＞
ＧＮＳＳは、人工衛星から発射される信号を用いて現在位置や時刻の特定を行うことができる。車両用装置１の場合、ＧＮＳＳモジュール１０２で信号を受信し、位置アプリ２０４によって現在位置の特定および時刻の特定を行っている。このとき、ＧＮＳＳで利用される時刻は非常に正確であるため、特定した時刻を基本時刻として設定すれば、車両用装置１の基本時刻を正確に維持することができる。

ところで、位置アプリ２０４は、ＯＳ２００上で動作するアプリケーションである。このため、位置アプリ２０４によってＯＳ２００の基本時刻を変更しても、その変更は、ＯＳ２００内で完結しており、ＯＳ３００には反映されない。そのため、本実施形態の位置アプリ２０４は、時刻を特定すると、その時刻をＴＭＭ２０２に通知し、基本時刻の変更をＴＭＭ２０２に委ねる構成となっている。

具体的には、位置アプリ２０４は、図５に矢印５Ａにて示すようにＧＮＳＳモジュール１０２からデータを受け取ると、位置および時刻を特定する。続いて、位置アプリ２０４は、図６に示すように、ステップＳ１において時刻を変更するか否かを判定する。位置アプリ２０４は、例えば前回の変更からごく短時間しか経過していない場合などには、ステップＳ１においてＮＯとなり、時刻を変更しないという判定をする場合もある。

一方、位置アプリ２０４は、時刻を変更すると判定した場合には、ステップＳ１においてＹＥＳとなり、図５に矢印５Ｂにて示すように特定した時刻に変更するように、ステップＳ２においてＴＭＭ２０２に時刻の変更要求を通知する。この変更要求は、変更すべき時刻のデータ、あるいは、変更すべき時刻を特定可能なデータとしてＴＭＭ２０２に通知される。

このとき、ＴＭＭ２０２は、図７に示すように、ステップＴ１においていずれかのアプリケーションからの変更要求を受け付けたか否かを判定している。そして、ＴＭＭ２０２は、変更要求を受け付けていないと判定した場合には、ステップＴ１においてＮＯとなり、ステップＴ１に移行して変更要求を待機する。この図７に示す処理の流れが、同期処理の基本的な流れに相当する。

一方、ＴＭＭ２０２は、変更要求を受け付けたと判定した場合には、ステップＴ１においてＹＥＳとなり、図５に矢印５Ｃにて示すように、ステップＴ２においてＲＴＣ１０３の時刻を変更する。続いて、ＴＭＭ２０２は、図５に矢印５Ｄにて示すように、ステップＴ３においてシステムクロック２０１の時刻を変更し、図５に矢印５Ｅにて示すように、ステップＴ４においてＮＴＰＤ２０３に時刻の変更を通知する。この場合、ＴＭＭ２０２から直接的にＮＴＰＤ２０３に時刻の変更を通知する構成とすることもできる。

そして、ＴＭＭ２０２は、図５に矢印５Ｆにて示すように、ステップＴ５においてサービスバス２０７を経由してＯＳ３００に時刻の変更を通知する。より具体的には、ＴＭＭ２０２は、他のＯＳ３００上で動作しているＴＭＭスレッド３１０に対して時刻の変更を通知する。

ＯＳ３００側で動作しているＴＭＭスレッド３１０は、図８に示すように、ステップＵ１において時刻の変更が通知されたか否かを判定している。ＴＭＭスレッド３１０は、時刻の変更が通知されていないと判定した場合には、ステップＵ１においてＮＯとなり、ステップＵ１に移行して通知を待機する。

一方、ＴＭＭスレッド３１０は、変更の通知を受け付けたと判定した場合には、ステップＵ１においてＹＥＳとなり、図５に矢印５Ｇにて示すように、ステップＵ２においてクライアント側のＮＴＰＤ３０３を再起動させる。そして、再起動したＮＴＰＤ３０３は、図５に矢印５Ｈにて示すようにサーバ側のＮＴＰＤ２０３から時刻を取得し、矢印５Ｉにて示すように取得した時刻をシステムクロック３０１に設定する。これにより、ＯＳ３００のシステムクロックには、ＯＳ２００側と同期した時刻が設定および保持される。

このように、車両用装置１は、ＧＮＳＳに基づいて基本時刻を変更する際、ＯＳ２００側、より厳密に言えばＲＴＣ１０３に生じる時刻の変更をＴＭＭ２０２によってＯＳ３００側に通知している。これにより、各ＯＳ間で時刻が同期される。

＜ユーザの操作に基づく基本時刻の変更＞
車両用装置１は、ＧＮＳＳを備えていない構成の場合、ＧＮＳＳによる時刻の特定はできないためユーザが現在時刻を設定する必要がある。また、ＧＮＳＳを備えている構成の場合であっても、ユーザによっては、表示される時刻を敢えて正確な時刻よりも進めておくことで予定に遅れないようにするといった状況が想定される。そのため、車両用装置１には、ユーザの操作によって基本時刻を変更する処理を行う時計アプリ２０５が実装されている。

この時計アプリ２０５は、ＯＳ２００上で動作するアプリケーションである。このため、時計アプリ２０５によって基本時刻を変更しても、その変更は、ＯＳ２００内で完結してしまい、ＯＳ３００には反映されない。そのため、本実施形態の時計アプリ２０５は、時刻が設定されると、その時刻をＴＭＭ２０２に通知し、基本時刻の変更をＴＭＭ２０２に委ねる構成となっている。

具体的には、ユーザによって時刻の設定あるいは変更の操作が行われた場合、図９に矢印９Ａにて示すように、操作装置５０４の入力を受け付けるＨＭＩアプリ３０４から、サービスバス２０７を経由して操作内容が時計アプリ２０５に通知される。この操作内容には、ユーザが設定した時刻が含まれている。つまり、時計アプリ２０５は、操作内容が時刻を変更するものである場合、図６に示すように時刻を変更すると判定し、ステップＳ１においてＹＥＳとなり、図９に矢印９Ｂにて示すように、ステップＳ２においてＴＭＭ２０２に時刻の変更要求を通知する。

ＴＭＭ２０２は、上記したＧＮＳＳに基づく基本時刻の変更と同様に、図７に示すように変更要求を受け付けたと判定した場合には、ステップＴ１においてＹＥＳとなり、図９に矢印９Ｃにて示すようにステップＴ２においてＲＴＣ１０３の時刻を変更し、矢印９Ｄにて示すようにステップＴ３においてシステムクロック２０１の時刻を変更し、矢印９Ｅにて示すようにステップＴ４においてＮＴＰＤ２０３に時刻の変更を通知する。そして、ＴＭＭ２０２は、図９に矢印９Ｆにて示すように、ステップＴ５においてサービスバス２０７を経由してＯＳ３００に時刻の変更を通知する。

ＯＳ側で動作しているＴＭＭスレッド３１０は、図８に示すように変更の通知を受け付けたと判定すると、ステップＵ１においてＹＥＳとなり、図９に矢印９Ｇにて示すようにステップＵ２においてクライアント側のＮＴＰＤ３０３を再起動させる。そして、再起動したＮＴＰＤ３０３は、図９に矢印９Ｈにて示すようにサーバ側のＮＴＰＤ２０３から時刻を取得し、矢印９Ｉにて示すように取得した時刻をシステムクロック３０１に設定する。これにより、ＯＳ３０１のシステムクロックには、ＯＳ２００側と同期した時刻が設定および保持される。

このように、車両用装置１は、ユーザの操作に基づいて基本時刻を変更する際、ＯＳ２００側、より厳密に言えばＲＴＣ１０３に生じる時刻の変更をＴＭＭ２０２によってＯＳ３００側に通知している。これにより、各ＯＳ間で時刻が同期される。

また、ＧＮＳＳを備える構成の場合には、ユーザが設定した時刻とそれまで記憶していた基本時刻との差分は、オフセット時間として記憶される。これにより、例えば位置アプリ２０４によって時刻の変更が行われたとしても、表示される時刻はオフセット時間が加算されたものとなる。このとき、ＲＴＣ１０３には、正確な時刻が設定される。したがって、表示される時刻を敢えて進めておきたいというユーザの要望に応えつつ、車両用装置１としては正確な時刻で動作することができるようになる。

一方、ＧＮＳＳを備えていない構成の場合には、ユーザが設定した時刻は、車両用装置１の基本時間として設定される。この場合、携帯端末５０２と接続されて正確な時刻を取得できたり、ＤＣＭ１０４により正確な時刻を取得できたりした場合には、車両用装置１の基本時間を更新する構成とすることができるし、上記したようにオフセット時間として扱う構成とすることもできる。

＜携帯端末５０２との接続に基づく基本時刻の変更＞
車両用装置１は、上記したようにユーザが所有する携帯端末５０２と連係して動作することができる。そして、携帯端末５０２は、通信回線を介して正確な時刻を保持していると考えられる。換言すると、携帯端末５０２の時刻を取得すれば、車両用装置１の基本時刻を正確な時刻にすることができると考えられる。そのため、車両用装置１には、接続された携帯端末５０２に記憶されている時刻に基づいて車両用装置１の基本時刻を変更する処理を行う電話アプリ３０６が実装されている。

この電話アプリ３０６は、ＯＳ３００上で動作するアプリケーションである。このため、電話アプリ３０６によって基本時刻を変更しても、その変更は、ＯＳ３００内で完結してしまい、ＯＳ２００には反映されない。そのため、本実施形態の電話アプリ３０６は、携帯端末５０２と接続されて時刻を特定すると、その時刻をＴＭＭ２０２に通知し、基本時刻の変更をＴＭＭ２０２に委ねる構成となっている。

具体的には、電話アプリ３０６は、車両用装置１に携帯端末５０２が通信可能に接続された場合、携帯端末５０２に記憶されている時刻を取得する。そして、電話アプリ３０６は、正確な時刻を取得できたことから、図６に示すように時刻を変更すると判定し、ステップＳ１においてＹＥＳとなり、図１０に矢印１０Ａにて示すようにステップＳ２においてＴＭＭ２０２に時刻の変更要求を通知する。

ＴＭＭ２０２は、上記したＧＮＳＳに基づく基本時刻の変更と同様に、図７に示すように変更要求を受け付けたと判定した場合には、ステップＴ１においてＹＥＳとなり、図１０に矢印１０Ｂにて示すようにステップＴ２においてＲＴＣ１０３の時刻を変更し、矢印１０Ｃにて示すようにステップＴ３においてシステムクロック２０１の時刻を変更し、矢印１０Ｄにて示すようにステップＴ４においてＮＴＰＤ２０３に時刻の変更を通知する。そして、ＴＭＭ２０２は、図１０に矢印１０Ｅにて示すように、ステップＴ５においてサービスバス２０７を経由してＯＳ３００に時刻の変更を通知する。

ＯＳ３００側で動作しているＴＭＭスレッド３１０は、図８に示すように変更の通知を受け付けたと判定すると、ステップＵ１においてＹＥＳとなり、図１０に矢印１０Ｆにて示すようにステップＵ２においてクライアント側のＮＴＰＤ３０３を再起動させる。そして、再起動したＮＴＰＤ３０３は、図１０に矢印１０Ｇにて示すようにサーバ側のＮＴＰＤ２０３から時刻を取得し、矢印１０Ｈにて示すように取得した時刻をシステムクロック３０１に設定する。これにより、ＯＳ３００のシステムクロック３０１には、ＯＳ２００側と同期した時刻が設定および保持される。

このように、車両用装置１は、携帯端末５０２と接続された際、従来ではＯＳ３００側にのみ生じる時刻の変更を、ＴＭＭ２０２によってＯＳ２００側に通知することにより、ＲＴＣ１０３への時刻の変更の反映と、各ＯＳ間での時刻の同期とを実現している。

＜ＤＣＭ１０４に基づく基本時刻の変更＞
車両用装置１は、上記したようにＤＣＭ１０４を備えている。このＤＣＭ１０４は、通信回線を介してセンターと通信可能に構成されており、センター側から時刻を取得することができる。つまり、車両用装置１は、ＤＣＭ１０４で取得した時刻に基づいて、基本時刻を正確な時刻にすることができると考えられる。そのため、車両用装置１には、ＤＣＭ１０４を介して取得した時刻に基づいて車両用装置１の基本時刻を変更する処理を行うテレマティックスアプリ３０７が実装されている。

このテレマティックスアプリ３０７は、ＯＳ３００上で動作するアプリケーションである。このため、テレマティックスアプリ３０７によって基本時刻を変更しても、その変更は、ＯＳ３００内で完結してしまい、ＯＳ２００には反映されない。そのため、本実施形態のテレマティックスアプリ３０７は、時刻を特定すると、その時刻をＴＭＭ２０２に通知し、基本時刻の変更をＴＭＭ２０２に委ねる構成となっている。

具体的には、テレマティックスアプリ３０７は、ＤＣＭ１０４を介して時刻を取得すると、正確な時刻を取得できたことから、図６に示すように時刻を変更すると判定し、ステップＳ１においてＹＥとなり、図１１に矢印１１Ａにて示すようにステップＳ２においてＴＭＭ２０２に時刻の変更要求を通知する。

ＴＭＭ２０２は、上記したＧＮＳＳに基づく基本時刻の変更と同様に、図７に示すように変更要求を受け付けたと判定した場合には、ステップＴ１においてＹＥＳとなり、図１１に矢印１１Ｂにて示すようにステップＴ２においてＲＴＣ１０３の時刻を変更し、矢印１１Ｃにて示すようにステップＴ３においてシステムクロック２０１の時刻を変更し、矢印１１Ｄにて示すようにステップＴ４においてＮＴＰＤ２０３に時刻の変更を通知する。そして、ＴＭＭ２０２は、図１１に矢印１１Ｅにて示すように、ステップＴ５においてサービスバス２０７を経由してＯＳ３００に時刻の変更を通知する。

Ｏ３００Ｓ側で動作しているＴＭＭスレッド３１０は、図８に示すように変更の通知を受け付けたと判定すると、ステップＵ１においてＹＥＳとなり、図１１に矢印１１Ｆにて示すようにステップＵ２においてクライアント側のＮＴＰＤ３０３を再起動させる。そして、再起動したＮＴＰＤ３０３は、図１１に矢印１１Ｇにて示すようにサーバ側のＮＴＰＤ２０３から時刻を取得し、矢印１１Ｈにて示すように取得した時刻をシステムクロック３０１に設定する。これにより、ＯＳ３００のシステムクロックには、ＯＳ２００側と同期した時刻が設定および保持される。

このように、車両用装置１は、ＤＣＭ１０４を介して取得した時刻に基づいて、従来ではＯＳ３００側にのみ生じる時刻の変更を、ＴＭＭ２０２によってＯＳ２００側に通知することにより、ＲＴＣ１０３への時刻の変更の反映と、各ＯＳ間での時刻の同期とを実現している。

以上のように、車両用装置１は、時刻を同期させる同期部としてのＴＭＭ２０２によって、ＣＰＵモジュール１００上で動作する複数のＯＳ２００、ＯＳ３００の時刻を同期させている。なお、本実施形態で例示したアプリケーション以外によって時刻を変更する場合も、ＴＭＭ２０２を用いることにより同様にＯＳ間の時刻を同期させることができる。

以上説明した車両用装置１によれば、次のような効果を得ることができる。
車両用装置１は、１つのＣＰＵモジュール１００上でＯＳ２００、ＯＳ３００のような複数のＯＳが同時に動作する仮想化環境が構築されている。このとき、ＯＳ２００およびＯＳ３００ＯＳは、それぞれのシステムクロック、つまりは、独自の時計機能に基づいて動作する。この場合、一般的には、あるＯＳ上で行われる変更は、そのＯＳ内で完結しており、他のＯＳに通知されることはない。そのため、あるＯＳ上で時刻が変更されても、その変更は他のＯＳには反映されず、ＯＳ間で時刻の同期がとれていない状態になるおそれがある。

これに対して、車両用装置１は、同期部に相当するＴＭＭ２０２により、いずれかのＯＳにおいて行われる時刻の変更を他のＯＳに通知して各ＯＳの時刻を同期させている。このような同期部を備えることにより、車両用装置１は、いずれかのＯＳ上で行われる時刻の変更が他のＯＳにも通知される。そして、時刻の変更が通知されれば、通知された側のＯＳで時刻の変更を行うことができる。

したがって、ＣＰＵモジュール１００上で動作する複数のＯＳ間で時刻を同期させることができる。そして、ＯＳ間の時刻が同期されれば、１つの表示装置５０３に異なる時刻が表示されてユーザが混乱したり、ログのタイムスタンプが時系列にならない等の不具合が発生したりするおそれを低減することができる。また、車両用装置１に複数の表示装置５０３が接続される構成の場合にも、各表示装置５０３に異なる時刻が表示されることを防止できる。

また、いずれかのＯＳ上で行われる時刻の変更を他のＯＳに通知することで各ＯＳの時刻を同期させる同期処理を含む時刻同期方法、あるいは、車両用装置１の制御部つまりはＣＰＵモジュール１００に、同期処理を実行させるコンピュータプログラムによっても、ＣＰＵモジュール１００上で動作する複数のＯＳ間で時刻を同期させることができ、１つの表示装置５０３に異なる時刻が表示されてユーザが混乱したり、ログのタイムスタンプが時系列にならない等の不具合が発生したりするおそれを低減することができる。

車両用装置１は、ＣＰＵモジュール１００上に車両用装置１の外部から時刻を取得するアプリケーションが実装されている。そして、同期部は、時刻を取得するアプリケーションが取得した時刻に基づいて時刻を変更するとともに、時刻を変更したことを各ＯＳに通知する。つまり、各アプリケーションは、実際に時刻を変更する処理を、ＴＭＭ２０２に委ねている。これにより、正確な時間を保持することができるとともに、時刻が変更された際の各ＯＳへの通知を確実なものにすることができる。

このとき、時刻を取得するアプリケーションは、時刻の変更を要求する変更要求を同期部に通知する。そして、同期部は、変更要求を受け付けると、ＲＴＣ１０３の時刻を変更するとともに、ＲＴＣ１０３の時刻を変更したことを各ＯＳに通知する。これにより、取得した正確な時刻に基づいて車両用装置１の基本時間を変更することができるとともに、その正確な時刻に基づいて各ＯＳの基本時刻が変更される。したがって、車両用装置１の全体で時刻を同期させることができる。また、実際に時刻を変更する処理をＴＭＭ２０２に委ねることにより、換言すると、車両用装置１の基準となるＲＴＣ１０３の時刻の変更を同期部に限定する構成とすることにより、時刻が変更された際の各ＯＳへの通知を確実なものにすることができる。

同期部としてのＴＭＭ２０２は、いずれか１つのＯＳ上にアプリケーションとして実装されている。つまり、同期部は、ソフトウェアで実現されているため、追加のハードウェアや既存のハードウェアの変更が不要となる。したがって、車両用装置１に同期部を設けることが容易となるとともに、既存の装置に対しても容易に同期部を設けることができる。

車両装置には、車両用装置１の外部から時刻を取得するアプリケーションとして、実施形態の位置アプリ２０４のように、衛星測位システムからの時刻の変更を受け付けるアプリケーションが実装されている。これにより、ＧＮＳＳに基づいて正確な時刻を取得すれば、その正確な時刻を各ＯＳおよび車両用装置１の基本時間として設定することができる。したがって、車両用装置１を正確な時刻に基づいて動作させることができる。

車両用装置１には、車両用装置１の外部から時刻を取得するアプリケーションとして、実施形態の時計アプリ２０５のように、ユーザからの時刻の変更を受け付けるアプリケーションが実装されている。これにより、ユーザが所望する時刻を車両用装置１の基本時間として設定することができる。したがって、車両用装置１をユーザが所望する時刻に基づいて動作させることができる。

車両用装置１には、車両用装置１の外部から時刻を取得するアプリケーションとして、実施形態の電話アプリ３０６のように、携帯端末５０２からの時刻の変更を受け付けるアプリケーションが実装されている。携帯端末５０２は、通信回線を介して正確な時刻を取得していると考えられる。そのため、携帯電話と接続して正確な時刻を取得すれば、その正確な時刻を各ＯＳおよび車両用装置１の基本時間として設定することができる。したがって、車両用装置１を正確な時刻に基づいて動作させることができる。

車両用装置１には、車両用装置１の外部から時刻を取得するアプリケーションとして、実施形態のテレマティックスアプリ３０７のように、ＤＣＭ１０４からの時刻の変更を受け付けるアプリケーションが実装されている。ＤＣＭ１０４は、通信回線を介して正確な時刻を取得していると考えられる。そのため、ＤＣＭ１０４に基づいて正確な時刻を取得すれば、その正確な時刻を各ＯＳおよび車両用装置１の基本時間として設定することができる。したがって、車両用装置１を正確な時刻に基づいて動作させることができる。

また、車両用装置１は、サーバ側となるＮＴＰＤ２０３とクライアント側となるＮＴＰＤ３０３とを実装し、ＮＴＰにより時刻を同期させている。これにより、時刻の同期を既存のプロトコルを用いて容易に行うことができるとともに、通知に要する時間によって各ＯＳの時刻に僅かなずれが生じてしまうことも防止できる。

また、時刻が変更された場合にはクライアント側のＮＴＰＤ３０３を再起動しているため、ＮＴＰの仕様を超える時刻のずれが生じている場合であっても、各ＯＳの時刻を同期させることができる。

実施形態ではＴＭＭ２０２から時刻を変更したことをＴＭＭスレッド３１０に通知する例を示したが、変更した時刻をＴＭＭスレッド３１０や他のＯＳに通知する構成とすることもできる。

実施形態では同期部としてのＴＭＭ２０２をＯＳ２００に実装する例を示したが、ＴＭＭ２０２をハイパーバイザ４００に実装する構成とすることもできる。すなわち、同期部は、各ＯＳを動作させるハイパーバイザ４００上にアプリケーションとして実装することができる。このような構成によっても、上記した実施形態と同様に、各ＯＳの時刻を同期させることができる。

また、実施形態では、サーバ側のＮＴＰＤ２０３をＯＳ２００に実装し、ＯＳ２００つまりはハイパーバイザ４００上で動作するＯＳが時刻を同期する際のマスターとなる例を示したが、サーバ側のＮＴＰＤ２０３をハイパーバイザ４００に実装し、各ＯＳにクライアント側のＮＴＰＤ３０３を実装する構成とすることもできる。すなわち、ハイパーバイザ４００を、時刻を同期する際のマスターとする構成とすることもできる。このような構成によっても、上記した実施形態と同様に、各ＯＳの時刻を同期させることができる。

実施形態ではＯＳ２００の機能によりハイパーバイザ４００を実装する例を示したが、ＣＰＵモジュール１００上に専用のハイパーバイザ４００を実装し、その上で複数のＯＳを動作させる一般的な仮想化環境の構成においても、実施形態で示した方法やプログラムにより、各ＯＳ間で時刻を同期させることができる。その場合、実施形態のようにＴＭＭ２０２やサーバ側のＮＴＰＤ２０３をＯＳ上に実装する構成とすることもできるし、ハイパーバイザ４００上に実装する構成とすることもできる。

実施形態ではＴＭＭスレッド３１０によりクライアント側のＮＴＰＤ３０３を再起動する例を示したが、クライアント側のＮＴＰＤ３０３に時刻の再取得を通知し、再取得できなかった場合に再起動する構成とすることもできる。

実施形態では１つのＣＰＵモジュール１００上に１つのＣＰＵ１０１が設けられている構成を例示したが、１つのＣＰＵモジュール１００上に複数のＣＰＵ１０１を設け、ハイパーバイザ４００を複数のＣＰＵ１０１上で動作させるいわゆるマルチプロセッサの構成とすることもできる。つまり、１つの車両用装置１に構築されている１つの仮想化環境に同期部を設ける構成とすることができる。このような構成によっても、実施形態と同様に各ＯＳの時刻を同期させることができる。

本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に含まれるものである。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

図面中、１は車両用装置、１００はハードウェアを構成するＣＰＵモジュール、２００はオペレーティングシステム、２０１は時計機能を構成するシステムクロック、２０２は同期部を構成するＴＭＭ、３００はオペレーティングシステム、３０１は時計機能を構成するシステムクロック、４００はハイパーバイザ、２０４は時刻を取得するアプリケーションである位置アプリ、２０５は時刻を取得するアプリケーションである時計アプリ、３０４は時刻を取得するアプリケーションであるＨＭＩアプリ、３０６は時刻を取得するアプリケーションである電話アプリ、３０７は時刻を取得するアプリケーションであるテレマティックスアプリを示す。

Claims (10)

1. １つのハードウェアモジュール（１００）上で複数のオペレーティングシステム（２００、３００）を同時に動作させる車両用装置であって、
   各オペレーティングシステム（２００、３００）は、それぞれ独自の時計機能（２０１、３０１）に基づいて動作するものであり、
   いずれかのオペレーティングシステム（２００、３００）上で行われる時刻の変更を各オペレーティングシステム（２００、３００）に通知して各オペレーティングシステム（２００、３００）の時刻を同期させる同期部（２０２）を備える車両用装置。
2. 前記ハードウェアモジュール上には、車両用装置（１）の外部から時刻を取得するアプリケーション（２０４、２０５、３０４、３０６、３０７）が実装されており、
   前記同期部は、時刻を取得するアプリケーションが取得した時刻に基づいて時刻を変更するとともに、時刻を変更したことを各オペレーティングシステムに通知する請求項１記載の車両用装置。
3. 前記ハードウェアモジュール上には、車両用装置の外部から時刻を取得するアプリケーションが実装されており、
   前記同期部は、前記変更要求を受け付けると、前記ハードウェアモジュールに設けられているリアルタイムクロック（１０３）の時刻を変更するとともに、前記リアルタイムクロックの時刻を変更したことを各オペレーティングシステムに通知する請求項１または２記載の車両用装置。
4. 前記同期部は、いずれか１つのオペレーティングシステム上にアプリケーションとして実装されている請求項１から３のいずれか一項記載の車両用装置。
5. 前記同期部は、各オペレーティングシステムを動作させるハイパーバイザ（４００）上にアプリケーションとして実装されている請求項１から３のいずれか一項記載の車両用装置。
6. 車両用装置の外部から時刻を取得するアプリケーションとして、衛星測位システムからの時刻の変更を受け付けるアプリケーション（２０４）が実装されている請求項２から５のいずれか一項記載の車両用装置。
7. 車両用装置の外部から時刻を取得するアプリケーションとして、ユーザからの時刻の変更を受け付けるアプリケーション（２０５、３０４）が実装されている請求項２から６のいずれか一項記載の車両用装置。
8. 車両用装置の外部から時刻を取得するアプリケーションとして、携帯端末からの時刻の変更を受け付けるアプリケーション（３０６）が実装されている請求項２から７のいずれか一項記載の車両用装置。
9. 車両用装置の外部から時刻を取得するアプリケーションとして、車両に設けられているデータ通信装置からの時刻の変更を受け付けるアプリケーション（３０７）が実装されている請求項２から８のいずれか一項記載の車両用装置。
10. １つのハードウェアモジュール（１００）上で複数のオペレーティングシステム（２００、３００）を同時に動作させる車両用装置（１）において各オペレーティングシステムの時刻を同期させる同期方法であって、
    各オペレーティングシステムは、それぞれ独自の時計機能（２０１、３０１）に基づいて動作するものであり、
    いずれかのオペレーティングシステム上で行われる時刻の変更を各オペレーティングシステムに通知して各オペレーティングシステムの時刻を同期させる同期処理を含む車両用装置の時刻同期方法。

Images