ナビゲーションシステム
【課題】 ユーザインタフェース側の負荷を軽減し、アプリケーションが増えた場合でも負荷が増えるのを防止する。
【解決手段】 利用者への情報出力、利用者からの情報入力を処理し、複数のアプリケーションを搭載したユーザインタフェース（２）と、ナビゲーション装置本体（１）と、ユーザインタフェースとナビゲーション装置本体間の情報伝達を行う通信層（３）とを備えたナビゲーションシステムにおいて、ユーザインタフェースは、各アプリケーションが必要とするナビゲーション装置本体からの情報取得条件を登録し、ナビゲーション装置本体から受信した情報が情報取得条件を満たすか否かを一括して監視する制御ユニットを有している。
【解決手段】 利用者への情報出力、利用者からの情報入力を処理し、複数のアプリケーションを搭載したユーザインタフェース（２）と、ナビゲーション装置本体（１）と、ユーザインタフェースとナビゲーション装置本体間の情報伝達を行う通信層（３）とを備えたナビゲーションシステムにおいて、ユーザインタフェースは、各アプリケーションが必要とするナビゲーション装置本体からの情報取得条件を登録し、ナビゲーション装置本体から受信した情報が情報取得条件を満たすか否かを一括して監視する制御ユニットを有している。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザインタフェースとナビゲーション装置本体との処理を分散し、両者間の情報伝達を通信層を介して行うようにしたナビゲーションシステムに関する。
【背景技術】
【０００２】
従来、ナビゲーションシステムとユーザインタフェースとの間で情報のやりとりを行うようにし、ユーザインタフェースの使い勝手を向上させるようにしたナビゲーション装置が提案されている（特許文献１）。また、ナビゲーション機能以外にも、音楽再生、ビデオ再生、音楽放送、テレビ放送、インターネット等の複数のアプリケーションを搭載し、ユーザインタフェースのパネルにおいて選択利用できるナビゲーション装置も普及している。
【特許文献１】特開２００１−８３９９１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
特許文献１のようなナビゲーションシステムとユーザインタフェースとの間で情報のやりとりを行うようにしたナビゲーション装置においては、ナビゲーションシステムからユーザインタフェースに対して定期通信が行われている。そのため、ユーザインタフェース側に複数のアプリケーションを搭載した場合、ナビゲーションシステムからの情報を必要とするアプリケーションは定期通信を監視し、自ら必要な情報を取得する必要がある。
【０００４】
図５は従来のナビゲーション装置本体とユーザインタフェースとの間の定期通信時の処理を説明する図である。
この例では、車速と方位の情報がナビゲーション装置本体から定期的にユーザインタフェース側に送信され、これをユーザインタフェースのイベント受信部で受信すると、オーディオモジュール、方位検出モジュールで値を確認し、チェック結果を返している様子を示している。例えば、オーディオモジュールでは車速が所定速度に達したか否かをチェックし、所定速度に達した場合には音量を上げる等の制御を行っており、方位検出モジュールでは所定方位に達して逆光状態になったか否か等を検出している。
【０００５】
このように従来のシステムでは、ナビゲーションシステムからの定期通信をユーザインタフェース側の各アプリケーションが、直接監視を行っているためその負荷が大きい。また、アプリケーションが増えるたびに個々のアプリケーションが監視を行うため、ユーザインタフェース側での負荷が非常に大きくなっていた。
【課題を解決するための手段】
【０００６】
本発明は上記課題を解決しようとするものであり、ナビゲーション情報の定期通信を監視するユーザインタフェース側の負荷を軽減し、アプリケーションが増えた場合でも負荷が増えるのを防止することを目的とする。
そのために本発明は、利用者への情報出力、利用者からの情報入力を処理し、複数のアプリケーションを搭載したユーザインタフェースと、ナビゲーション装置本体と、ユーザインタフェースとナビゲーション装置本体間の情報伝達を行う通信層とを備えたナビゲーションシステムにおいて、ユーザインタフェースは、各アプリケーションが必要とするナビゲーション装置本体からの情報取得条件を登録し、ナビゲーション装置本体から受信した情報が前記情報取得条件を満たすか否かを一括して監視する制御ユニットを有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、制御ユニットで一括してナビゲーション情報の定期通信を監視するようにしたので、各アプリケーションの負荷が軽減し、アプリケーションが増えた場合でも監視を行う場所は１つなのでユーザインタフェース側での負荷が増えるのを防止することができる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明の実施の形態について説明する。
図１は本実施形態のナビゲーションシステムを説明する概念図、図２はイベントコントロールユニットの機能を説明する図である。
【０００９】
図１において、ナビゲーション装置本体１とユーザインタフェース（以下、ＵＩ）２とは、それぞれに適した処理機能のＩＣチップを有するハード構成とすることにより処理を分散して性能アップを図っており、ナビゲーション装置本体１とＵＩ２との間の情報伝達は通信層３を介して行っている。
【００１０】
ナビゲーション装置本体１は、ＧＰＳ、ジャイロ等の位置／方位検出、目的地設定等を行う入力部１２からの取得情報と、地図データ、道路データ、案内用データ等のナビゲーションデータに基づいて経路探索等の処理を行っているが、ここではロケーションモジュール１１から車速、位置、方位等の情報を可能な限りリアルタイムで連続して通信層３を介してＵＩ２に対して定期的に送信している場合を示している。
【００１１】
ＵＩ２はナビゲーション装置本体から送られる情報を受信し、各アプリケーションが必要とする状態に達したか否かを一括して監視する制御ユニットとして、イベントコントロールユニット（以下、ＩＣＵ）２１を有し、ここではアプリケーションとしてＨＭＩ（Hard Machine Interface）描画モジュール２２、ＡＵＤＩＯモジュール２３が例示されている。ＨＭＩ描画モジュール２２は、自車位置周辺の地図等を描画しており、車速、位置情報、方位情報を所定のタイミングで必要としている。ＡＵＤＩＯモジュール２３は、車速や位置情報により音量を制御している。
【００１２】
本実施形態では、各アプリケーションは、ＩＣＵ２１に対してナビゲーション装置本体からの情報を取得する条件をコールバック登録しておく。ＩＣＵ２１では、ナビゲーション装置本体から送られる情報を受信し、各アプリケーションが登録した条件を満たすか否か一括して監視し、登録条件を満たしたとき、各アプリケーションに対してその情報を通知する。
【００１３】
このようなＩＣＵの処理の１例について図２により説明する。
例えば、ＡＵＤＩＯモジュールが車速６０ｋｍに達したとき、方位検出モジュールが方位１８度になったとき、それぞれコールバック（情報を通知）することをＩＣＵに対して登録した場合を説明する。ＩＣＵでは、ナビゲーション装置本体から送信される車速、方位情報を受信して監視し、方位１８度になったとき方位検出モジュールに対してコールバック（イベント発行）し、方位検出モジュールは方位１８度の情報を取得する。また、車速が６０ｋｍになったとき、オーディオモジュールに対してコールバック（イベント発行）し、オーディオモジュールは車速６０ｋｍの情報を取得する。もちろん、登録条件を車速６０ｋｍ以上というように設定すれば、図の６１ｋｍにおいてもコールバック（イベント発行）する。
【００１４】
図３は交差点拡大図表示の場合のＩＣＵの処理の例を示す図である。
ナビゲーションシステムでは、案内交差点に所定距離まで接近すると交差点拡大図を表示し、交差点の案内を行っている。図５に示した従来の方法を用いて交差点拡大図を表示する場合、ナビゲーション装置本体で算出された自車位置と交差点間の距離が常にＵＩの交差点拡大図表示アプリケーションでチェックされ、交差点までの予め定められた所定距離（例えば１００ｍ）まで接近した場合に交差点案内が行われることになる。
【００１５】
本実施形態では、図示するように、ＵＩの交差点拡大図表示アプリケーションは、ＩＣＵに予め定められた所定距離（例えば１００ｍ）をコールバック登録する。そして、ナビゲーション装置本体から送られてくるデータがコールバック登録したデータに一致したときにのみＩＣＵから交差点拡大図表示アプリケーションにデータが送られ、交差点拡大図を表示しての案内が開始される。その結果、ＵＩ側での処理の負担を軽減することが可能になる。なお、交差点との距離０ｍをコールバック登録しておくことにより、交差点に到達したとき交差点拡大図を消去する場合の処理負担も軽減される。
【００１６】
図４は方位磁石表示の場合のＩＣＵの処理の例を示す図である。
ナビゲーションシステムでは、地図をヘディングアップ表示（自車の進行方向が画面上方になるような地図表示）を行う際に、自車の移動に従って地図上に地図の向きを示す方位磁石表示を行っている。方位磁石データは複数の図、例えば３０度毎（０度、３０度、６０度……）のように離散的な値のビットマップ図として格納されているが、ナビゲーション装置本体での方位検出はそれよりも詳細な値、例えば１度毎のようにほぼ連続的なデータとして検出されている。
【００１７】
そのため、図５に示した従来の方法を用いて方位磁石表示を行う場合、ナビゲーション装置本体で算出された方位が常にＵＩ側の方位磁石表示アプリケーションでチェックされ、交差点まで予め定められた方位（例えば０度、３０度、６０度……）になった時に方位磁石表示が更新されることになるため、方位磁石表示アプリケーションの処理負担が大きかった。
【００１８】
本実施形態では、方位磁石表示アプリケーションは、ＩＣＵに予め定められた方位（例えば０度、３０度、６０度……）をコールバック登録し、ナビゲーション装置本体から送られてくるデータがコールバック登録したデータに一致したときにのみＩＣＵから方位磁石表示アプリケーションにデータが送られて方位磁石表示されることになるため、ＵＩ側での処理の負担を軽減することが可能になる。
【００１９】
このように、ＩＣＵが無い場合（図５に示した従来例の場合）には、ナビゲーション装置本体側でＵＩ側のモジュール（アプリケーション）を把握し、各モジュールに対して直接イベントを起こし、ＵＩ側では各モジュールが常に受信イベントを直接監視する必要があったが、本実施形態ではナビゲーション装置本体から定期的に送信される情報をＩＣＵが一括して監視し、各アプリケーションが登録した条件に合致したとき各アプリケーションに対して通知するので、各アプリケーションの負荷が軽減し、また、アプリケーションが増えても監視を行うのはＩＣＵ１箇所だけであるので、ＵＩ側の負荷が増えることはない。
【産業上の利用可能性】
【００２０】
本発明によれば、ユーザインタフェース側の負荷が軽減し、アプリケーションが増えた場合でも負荷が増えるのを防止できるので産業上の利用価値は大きい。
【図面の簡単な説明】
【００２１】
【図１】本実施形態のナビゲーションシステムを説明する概念図である。
【図２】イベントコントロールユニットの機能の１例を説明する図である。
【図３】交差点拡大図表示の場合のＩＣＵの処理の例を説明する図である。
【図４】方位磁石表示の場合のＩＣＵの処理の例を示す図である。
【図５】従来のナビゲーション装置本体とユーザインタフェースとの間の定期通信時の処理を説明する図である。
【符号の説明】
【００２２】
１…ナビゲーション装置本体、２…ユーザインタフェース、３…通信層、１１…ロケーションモジュール、１２…入力部、２１…イベントコントロールユニット、２２…ＨＭＩ描画モジュール、２３…ＡＵＤＩＯモジュール。
【技術分野】
【０００１】
本発明は、ユーザインタフェースとナビゲーション装置本体との処理を分散し、両者間の情報伝達を通信層を介して行うようにしたナビゲーションシステムに関する。
【背景技術】
【０００２】
従来、ナビゲーションシステムとユーザインタフェースとの間で情報のやりとりを行うようにし、ユーザインタフェースの使い勝手を向上させるようにしたナビゲーション装置が提案されている（特許文献１）。また、ナビゲーション機能以外にも、音楽再生、ビデオ再生、音楽放送、テレビ放送、インターネット等の複数のアプリケーションを搭載し、ユーザインタフェースのパネルにおいて選択利用できるナビゲーション装置も普及している。
【特許文献１】特開２００１−８３９９１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
特許文献１のようなナビゲーションシステムとユーザインタフェースとの間で情報のやりとりを行うようにしたナビゲーション装置においては、ナビゲーションシステムからユーザインタフェースに対して定期通信が行われている。そのため、ユーザインタフェース側に複数のアプリケーションを搭載した場合、ナビゲーションシステムからの情報を必要とするアプリケーションは定期通信を監視し、自ら必要な情報を取得する必要がある。
【０００４】
図５は従来のナビゲーション装置本体とユーザインタフェースとの間の定期通信時の処理を説明する図である。
この例では、車速と方位の情報がナビゲーション装置本体から定期的にユーザインタフェース側に送信され、これをユーザインタフェースのイベント受信部で受信すると、オーディオモジュール、方位検出モジュールで値を確認し、チェック結果を返している様子を示している。例えば、オーディオモジュールでは車速が所定速度に達したか否かをチェックし、所定速度に達した場合には音量を上げる等の制御を行っており、方位検出モジュールでは所定方位に達して逆光状態になったか否か等を検出している。
【０００５】
このように従来のシステムでは、ナビゲーションシステムからの定期通信をユーザインタフェース側の各アプリケーションが、直接監視を行っているためその負荷が大きい。また、アプリケーションが増えるたびに個々のアプリケーションが監視を行うため、ユーザインタフェース側での負荷が非常に大きくなっていた。
【課題を解決するための手段】
【０００６】
本発明は上記課題を解決しようとするものであり、ナビゲーション情報の定期通信を監視するユーザインタフェース側の負荷を軽減し、アプリケーションが増えた場合でも負荷が増えるのを防止することを目的とする。
そのために本発明は、利用者への情報出力、利用者からの情報入力を処理し、複数のアプリケーションを搭載したユーザインタフェースと、ナビゲーション装置本体と、ユーザインタフェースとナビゲーション装置本体間の情報伝達を行う通信層とを備えたナビゲーションシステムにおいて、ユーザインタフェースは、各アプリケーションが必要とするナビゲーション装置本体からの情報取得条件を登録し、ナビゲーション装置本体から受信した情報が前記情報取得条件を満たすか否かを一括して監視する制御ユニットを有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、制御ユニットで一括してナビゲーション情報の定期通信を監視するようにしたので、各アプリケーションの負荷が軽減し、アプリケーションが増えた場合でも監視を行う場所は１つなのでユーザインタフェース側での負荷が増えるのを防止することができる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明の実施の形態について説明する。
図１は本実施形態のナビゲーションシステムを説明する概念図、図２はイベントコントロールユニットの機能を説明する図である。
【０００９】
図１において、ナビゲーション装置本体１とユーザインタフェース（以下、ＵＩ）２とは、それぞれに適した処理機能のＩＣチップを有するハード構成とすることにより処理を分散して性能アップを図っており、ナビゲーション装置本体１とＵＩ２との間の情報伝達は通信層３を介して行っている。
【００１０】
ナビゲーション装置本体１は、ＧＰＳ、ジャイロ等の位置／方位検出、目的地設定等を行う入力部１２からの取得情報と、地図データ、道路データ、案内用データ等のナビゲーションデータに基づいて経路探索等の処理を行っているが、ここではロケーションモジュール１１から車速、位置、方位等の情報を可能な限りリアルタイムで連続して通信層３を介してＵＩ２に対して定期的に送信している場合を示している。
【００１１】
ＵＩ２はナビゲーション装置本体から送られる情報を受信し、各アプリケーションが必要とする状態に達したか否かを一括して監視する制御ユニットとして、イベントコントロールユニット（以下、ＩＣＵ）２１を有し、ここではアプリケーションとしてＨＭＩ（Hard Machine Interface）描画モジュール２２、ＡＵＤＩＯモジュール２３が例示されている。ＨＭＩ描画モジュール２２は、自車位置周辺の地図等を描画しており、車速、位置情報、方位情報を所定のタイミングで必要としている。ＡＵＤＩＯモジュール２３は、車速や位置情報により音量を制御している。
【００１２】
本実施形態では、各アプリケーションは、ＩＣＵ２１に対してナビゲーション装置本体からの情報を取得する条件をコールバック登録しておく。ＩＣＵ２１では、ナビゲーション装置本体から送られる情報を受信し、各アプリケーションが登録した条件を満たすか否か一括して監視し、登録条件を満たしたとき、各アプリケーションに対してその情報を通知する。
【００１３】
このようなＩＣＵの処理の１例について図２により説明する。
例えば、ＡＵＤＩＯモジュールが車速６０ｋｍに達したとき、方位検出モジュールが方位１８度になったとき、それぞれコールバック（情報を通知）することをＩＣＵに対して登録した場合を説明する。ＩＣＵでは、ナビゲーション装置本体から送信される車速、方位情報を受信して監視し、方位１８度になったとき方位検出モジュールに対してコールバック（イベント発行）し、方位検出モジュールは方位１８度の情報を取得する。また、車速が６０ｋｍになったとき、オーディオモジュールに対してコールバック（イベント発行）し、オーディオモジュールは車速６０ｋｍの情報を取得する。もちろん、登録条件を車速６０ｋｍ以上というように設定すれば、図の６１ｋｍにおいてもコールバック（イベント発行）する。
【００１４】
図３は交差点拡大図表示の場合のＩＣＵの処理の例を示す図である。
ナビゲーションシステムでは、案内交差点に所定距離まで接近すると交差点拡大図を表示し、交差点の案内を行っている。図５に示した従来の方法を用いて交差点拡大図を表示する場合、ナビゲーション装置本体で算出された自車位置と交差点間の距離が常にＵＩの交差点拡大図表示アプリケーションでチェックされ、交差点までの予め定められた所定距離（例えば１００ｍ）まで接近した場合に交差点案内が行われることになる。
【００１５】
本実施形態では、図示するように、ＵＩの交差点拡大図表示アプリケーションは、ＩＣＵに予め定められた所定距離（例えば１００ｍ）をコールバック登録する。そして、ナビゲーション装置本体から送られてくるデータがコールバック登録したデータに一致したときにのみＩＣＵから交差点拡大図表示アプリケーションにデータが送られ、交差点拡大図を表示しての案内が開始される。その結果、ＵＩ側での処理の負担を軽減することが可能になる。なお、交差点との距離０ｍをコールバック登録しておくことにより、交差点に到達したとき交差点拡大図を消去する場合の処理負担も軽減される。
【００１６】
図４は方位磁石表示の場合のＩＣＵの処理の例を示す図である。
ナビゲーションシステムでは、地図をヘディングアップ表示（自車の進行方向が画面上方になるような地図表示）を行う際に、自車の移動に従って地図上に地図の向きを示す方位磁石表示を行っている。方位磁石データは複数の図、例えば３０度毎（０度、３０度、６０度……）のように離散的な値のビットマップ図として格納されているが、ナビゲーション装置本体での方位検出はそれよりも詳細な値、例えば１度毎のようにほぼ連続的なデータとして検出されている。
【００１７】
そのため、図５に示した従来の方法を用いて方位磁石表示を行う場合、ナビゲーション装置本体で算出された方位が常にＵＩ側の方位磁石表示アプリケーションでチェックされ、交差点まで予め定められた方位（例えば０度、３０度、６０度……）になった時に方位磁石表示が更新されることになるため、方位磁石表示アプリケーションの処理負担が大きかった。
【００１８】
本実施形態では、方位磁石表示アプリケーションは、ＩＣＵに予め定められた方位（例えば０度、３０度、６０度……）をコールバック登録し、ナビゲーション装置本体から送られてくるデータがコールバック登録したデータに一致したときにのみＩＣＵから方位磁石表示アプリケーションにデータが送られて方位磁石表示されることになるため、ＵＩ側での処理の負担を軽減することが可能になる。
【００１９】
このように、ＩＣＵが無い場合（図５に示した従来例の場合）には、ナビゲーション装置本体側でＵＩ側のモジュール（アプリケーション）を把握し、各モジュールに対して直接イベントを起こし、ＵＩ側では各モジュールが常に受信イベントを直接監視する必要があったが、本実施形態ではナビゲーション装置本体から定期的に送信される情報をＩＣＵが一括して監視し、各アプリケーションが登録した条件に合致したとき各アプリケーションに対して通知するので、各アプリケーションの負荷が軽減し、また、アプリケーションが増えても監視を行うのはＩＣＵ１箇所だけであるので、ＵＩ側の負荷が増えることはない。
【産業上の利用可能性】
【００２０】
本発明によれば、ユーザインタフェース側の負荷が軽減し、アプリケーションが増えた場合でも負荷が増えるのを防止できるので産業上の利用価値は大きい。
【図面の簡単な説明】
【００２１】
【図１】本実施形態のナビゲーションシステムを説明する概念図である。
【図２】イベントコントロールユニットの機能の１例を説明する図である。
【図３】交差点拡大図表示の場合のＩＣＵの処理の例を説明する図である。
【図４】方位磁石表示の場合のＩＣＵの処理の例を示す図である。
【図５】従来のナビゲーション装置本体とユーザインタフェースとの間の定期通信時の処理を説明する図である。
【符号の説明】
【００２２】
１…ナビゲーション装置本体、２…ユーザインタフェース、３…通信層、１１…ロケーションモジュール、１２…入力部、２１…イベントコントロールユニット、２２…ＨＭＩ描画モジュール、２３…ＡＵＤＩＯモジュール。
【特許請求の範囲】
【請求項１】
利用者への情報出力、利用者からの情報入力を処理し、複数のアプリケーションを搭載したユーザインタフェースと、ナビゲーション装置本体と、ユーザインタフェースとナビゲーション装置本体間の情報伝達を行う通信層とを備えたナビゲーションシステムにおいて、
ユーザインタフェースは、各アプリケーションが必要とするナビゲーション装置本体からの情報取得条件を登録し、ナビゲーション装置本体から受信した情報が前記情報取得条件を満たすか否かを一括して監視する制御ユニットを有することを特徴とするナビゲーションシステム。
【請求項２】
前記制御ユニットは、ナビゲーション装置本体から受信した情報が、各アプリケーションの登録した情報取得条件を満たしたとき、各アプリケーションに対して受信情報を通知することを特徴とする請求項１記載のナビゲーションシステム。
【請求項１】
利用者への情報出力、利用者からの情報入力を処理し、複数のアプリケーションを搭載したユーザインタフェースと、ナビゲーション装置本体と、ユーザインタフェースとナビゲーション装置本体間の情報伝達を行う通信層とを備えたナビゲーションシステムにおいて、
ユーザインタフェースは、各アプリケーションが必要とするナビゲーション装置本体からの情報取得条件を登録し、ナビゲーション装置本体から受信した情報が前記情報取得条件を満たすか否かを一括して監視する制御ユニットを有することを特徴とするナビゲーションシステム。
【請求項２】
前記制御ユニットは、ナビゲーション装置本体から受信した情報が、各アプリケーションの登録した情報取得条件を満たしたとき、各アプリケーションに対して受信情報を通知することを特徴とする請求項１記載のナビゲーションシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００６−２１５６０３（Ｐ２００６−２１５６０３Ａ）
【公開日】平成１８年８月１７日（２００６．８．１７）
【国際特許分類】
【出願番号】特願２００５−２４７３２（Ｐ２００５−２４７３２）
【出願日】平成１７年２月１日（２００５．２．１）
【出願人】（０００１００７６８）アイシン・エィ・ダブリュ株式会社 (3,717)
【Ｆターム（参考）】
【公開日】平成１８年８月１７日（２００６．８．１７）
【国際特許分類】
【出願日】平成１７年２月１日（２００５．２．１）
【出願人】（０００１００７６８）アイシン・エィ・ダブリュ株式会社 (3,717)
【Ｆターム（参考）】
[ Back to top ]