(57)【要約】【課題】  汎用アプリとの連携を取ることが可能な表示制御装置を提供する。【解決手段】  専用ミドルウェア１３、汎用ミドルウェア１４、及び、インターフェース１５を備え、ナビゲーションの表示部における表示を制御する。このとき、専用ミドルウェア１３は、車両側で用意される専用アプリ１６を実行可能であり、汎用ミドルウェア１４は、外部から配信される汎用アプリ１７を実行可能である。また、インターフェース１５は、専用ミドルウェア１３と汎用ミドルウェア１４との間で必要情報の授受を行う。特に、専用ミドルウェア側処理では、燃料センサからの信号を車両情報として取得し、燃料残量が低下したと判断すると、車両状況としての燃料残量の低下を汎用ミドルウェア１４側へ通知する。そして、汎用ミドルウェア側処理では、燃料残量の低下が通知されると、該当するアプリ１７を起動する。【選択図】図２
2014221620.tif 000002
【特許請求の範囲】
【請求項１】
車両側で用意されるプログラム（１６）を実行可能な専用ミドルウェア（１３）、外部から配信される汎用アプリケーションプログラム（１７）を実行可能な汎用ミドルウェア（１４）及び前記専用ミドルウェアと前記汎用ミドルウェアとの間で必要情報の授受を行うインターフェース（１５）を備え、前記車両に搭載される表示部（４１）の表示を制御する表示制御装置（１０）であって、
前記車両に関連する車両情報を前記専用ミドルウェア側で取得する取得手段（１０ａ）と、
前記取得手段にて取得された前記車両情報に基づく車両状況を、前記インターフェースを介し前記汎用ミドルウェア側へ通知する通知手段（１０ｂ）と、
前記通知手段にて通知された前記車両状況に基づき、前記汎用アプリケーションプログラムの中で当該車両状況に応じた表示を実現するための対象アプリケーションプログラムを汎用ミドルウェア側で起動する起動手段（１０ｃ）と、
を備えていることを特徴とする表示制御装置。
【請求項２】
請求項１に記載の表示制御装置において、
前記起動手段は、複数の対象アプリケーションプログラムがインストールされている場合、当該対象アプリケーションプログラムの中の１つを選択的に起動すること（Ｓ２１０：ＹＥＳ，Ｓ２４０）
を特徴とする表示制御装置。
【請求項３】
請求項２に記載の表示制御装置において、
前記起動手段は、前記対象アプリケーションプログラムをリスト表示し、リスト表示した対象アプリケーションプログラムの１つがユーザによって選択されると、当該選択された対象アプリケーションプログラムを起動すること（Ｓ２２０，Ｓ２３０：ＹＥＳ，Ｓ２４０）
を特徴とする表示制御装置。
【請求項４】
請求項１〜３のいずれか一項に記載の表示制御装置において、
前記起動手段は、前記対象アプリケーションプログラムがインストールされていない場合、前記対象アプリケーションプログラムを外部からダウンロードして起動すること（Ｓ２１０：ＮＯ，Ｓ２４０）
を特徴とする表示制御装置。
【請求項５】
請求項４に記載の表示制御装置において、
前記起動手段は、前記対象アプリケーションプログラムがインストールされていない場合、外部から取得可能な対象アプリケーションプログラムの候補をリスト表示し、リスト表示した対象アプリケーションプログラムの１つが選択されると、当該選択された対象アプリケーションプログラムをダウンロードして起動すること（Ｓ２５０，Ｓ２６０：ＹＥＳ，Ｓ２４０）
を特徴とする表示制御装置。
【請求項６】
請求項１〜５のいずれか一項に記載の表示制御装置において、
前記通知手段は、前記取得手段にて取得された前記車両情報に基づく車両状況を表示し、ユーザからの操作があると、当該車両状況を前記汎用ミドルウェア側へ通知すること（Ｓ１１０，Ｓ１２０：ＹＥＳ，Ｓ１３０）
を特徴とする表示制御装置。
【請求項７】
請求項１〜６のいずれか一項に記載の表示制御装置において、
前記専用ミドルウェアと前記汎用ミドルウェアとの間で必要情報の授受は、当該必要情報の情報量が所定の閾値未満であるときは前記インターフェースだけを介して行われ、前記情報量が所定の閾値以上になると、前記インターフェースを経由し階層下のオペレーティングシステムを介して行われること
を特徴とする表示制御装置。
【請求項８】
請求項１〜７のいずれか一項に記載の表示制御装置の各手段としてコンピュータを機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載される表示部の表示を制御する表示制御装置に関する。
【背景技術】
【０００２】
近年、携帯端末の普及により、車載装置と携帯端末とを連携させる提案が種々なされている。車載装置のアプリケーションプログラム（以下「アプリ」という）は、車両専用のオペレーティングシステム（以下「ＯＳ」という）上で動作するのに対し、携帯端末のアプリは汎用ＯＳ上で動作し、リリースの頻度も高く、また、削除や追加が容易である。従来、携帯端末が接続された場合、前回の接続時のアプリが携帯端末にないときに、同種のアプリを判断して起動する車載装置が提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−９９９２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、携帯端末を車載装置に接続する場合、近距離通信規格などで接続されるのであるが、外乱要因などでデータ通信に不具合が生じる虞があることも否めない。
本発明は、このような課題を解決するためになされたものであり、その目的は、汎用アプリとの連携を取ることが可能な表示制御装置を提供することにある。
【課題を解決するための手段】
【０００５】
上記目的を達成するためになされた本発明の表示制御装置（１０）は、専用ミドルウェア（１３）、汎用ミドルウェア（１４）、及び、インターフェース（１５）を備え、車両に搭載される表示部（４１）の表示を制御する。
【０００６】
専用ミドルウェアは、車両側で用意されるプログラム（１６）を実行可能であり、汎用ミドルウェアは、外部から配信される汎用アプリ（１７）を実行可能である。また、インターフェースは、専用ミドルウェアと汎用ミドルウェアとの間で必要情報の授受を行う。
【０００７】
このように表示制御装置に、専用ミドルウェアだけでなく外部から配信される汎用アプリを実行する汎用ミドルウェアを搭載したため、従来と異なり、携帯端末を接続することなく、リリースの頻度が高く削除や追加が容易な汎用アプリを利用することができる。また、インターフェースを介在させたため、外乱要因などでデータ通信に不具合が生じることがない。さらに、インターフェースの介在により、必要となる情報の授受のみを行うことができ、セキュリティーに関しても有利である。
【０００８】
このとき本発明では、取得手段（１０ａ）が、車両に関連する車両情報を専用ミドルウェア側で取得する。また、通知手段（１０ｂ）は、取得手段にて取得された車両情報に基づく車両状況を、インターフェースを介し汎用ミドルウェア側へ通知する。そして、起動手段（１０ｃ）によって、通知手段にて通知された車両状況に基づき、汎用アプリの中で当該車両状況に応じた表示を実現するための対象アプリが汎用ミドルウェア側で起動される。
【０００９】
このようにすれば、車両に搭載される表示制御装置において、汎用アプリとの連携を取ることができる。
なお、本発明は、表示制御装置の機能を実現するためのプログラムにも特徴があるため、プログラムの発明として実現することができる。
【図面の簡単な説明】
【００１０】
【図１】表示制御装置を含む周辺構成を例示するブロック図である。
【図２】表示制御装置内部のハードウェア及びソフトウェアの構成を例示する説明図である。
【図３】専用ミドルウェア側処理を例示するフローチャートである。
【図４】汎用ミドルウェア側処理を例示するフローチャートである。
【図５】表示部における表示例を示す説明図である。
【発明を実施するための形態】
【００１１】
以下、本発明の一実施形態を図面に基づいて説明する。
図１に示すように、本実施形態の表示制御装置（ＤＣＵ）１０は、ハードウェア及びソフトウェアを統合したドメイン・コントロール・ユニットであり、エアコン２０、オーディオ３０、ナビゲーション４０と接続されている。また、表示制御装置１０は、バスラインを介し、燃料センサ５０と接続されている。エアコン２０、オーディオ３０及びナビゲーション４０もバスラインに接続されており、バスライン上の情報を受信可能となっている。オーディオ３０には、アンプ３１が接続されており、図示しないスピーカを介した音声出力が可能となっている。また、ナビゲーション４０は、カラー液晶ディスプレイなどで構成される表示部４１を有している。
【００１２】
かかる構成により、表示制御装置１０は、エアコン設定画面やオーディオ設定画面をナビゲーション４０の表示部４１に表示させることができる。エアコン設定画面を例に挙げれば、表示制御装置１０は、表示部４１と一体となったタッチパネルからの入力に基づき室温設定を行ったり、図示しない外気温センサに基づきエアコン２０に対し外気温を出力したりする。
【００１３】
図２に示すように、表示制御装置１０は、ハードウェア１１と、汎用ＯＳ１２と、専用ミドルウェア１３と、汎用ミドルウェア１４と、インターフェース１５と、専用ミドルウェア１３上で動作するアプリ１６と、汎用ミドルウェア１４上で動作するアプリ１７とを備えている。
【００１４】
ハードウェア１１には、ＣＰＵ１１ａ及び通信部１１ｂが含まれる。ＣＰＵ１１ａは、汎用ＯＳ１２、専用ミドルウェア１３、汎用ミドルウェア１４、インターフェース１５、及び、アプリ１６，１７を機能させる制御部である。通信部１１ｂは、サーバ６０とのデータ通信を可能にする構成であり、ネットワークを介し、アプリの提供先となるストア７０からのアプリ１７のダウンロードが可能となっている。
【００１５】
汎用ＯＳ１２は、ハードウェア１１の上位に位置するいわゆるプラットフォームである。専用ミドルウェア１３及び汎用ミドルウェア１４は、汎用ＯＳ１２上で動作する。そして、専用ミドルウェア１３と汎用ミドルウェア１４とに介在するのが、インターフェース１５である。インターフェース１５は、必要な情報だけを授受可能に構成されている。
【００１６】
次に、専用ミドルウェア側処理を、図３のフローチャートに基づいて説明する。この専用ミドルウェア側処理は、所定時間間隔で繰り返し実行される。
最初のＳ１００では、燃料残量が低下したか否かを判断する。この処理は、燃料センサ５０からの信号に基づくものである。ここで燃料残量が低下したと判断された場合（Ｓ１００：ＹＥＳ）、Ｓ１１０へ移行する。一方、燃料残量が低下していないと判断された場合（Ｓ１００：ＮＯ）、以降の処理を実行せず、専用ミドルウェア側処理を終了する。
【００１７】
Ｓ１１０では、燃料残量の低下を表示する。一例として、ナビゲーション４０が機能している状態では、図５（ａ）に記号Ｘで示すように、表示部４１における地図表示に重ねて「燃料残量が低下しています」という表示を行うという具合である。
【００１８】
続くＳ１２０では、燃料残量の低下表示に対応するタッチ操作があったか否かを判断する。例えば、地図表示に重ねて表示された「燃料残量が低下しています」という部分がタッチされたときに肯定判断される（図５（ａ）参照）。ここでタッチ操作があったと判断された場合（Ｓ１２０：ＹＥＳ）、Ｓ１３０へ移行する。一方、タッチ操作がないうちは（Ｓ１２０：ＮＯ）、Ｓ１１０からの処理を繰り返す。
【００１９】
Ｓ１３０では、燃料残量の低下を汎用ミドルウェア１４側へ通知する。この処理は、主にインターフェース１５を介し、燃料残量の低下を通知するものである。この通知によって、汎用ミドルウェア１４側では、給油所の検索を行うアプリを起動する。そしてアプリを起動した場合には、その旨を専用ミドルウェア１３側へ通知してくる。
【００２０】
そこで、次のＳ１４０では、アプリが起動されたか否かを判断する。ここでアプリが起動されていないと判断された場合（Ｓ１４０：ＮＯ）、Ｓ１５０にて専用ミドルウェア１３側で燃料残量低下のメッセージを表示し、その後、専用ミドルウェア側処理を終了する。一方、アプリが起動されたと判断された場合（Ｓ１４０：ＹＥＳ）、Ｓ１５０の処理を実行せず、専用ミドルウェア側処理を終了する。
【００２１】
次に、汎用ミドルウェア側処理を、図４のフローチャートに基づいて説明する。この汎用ミドルウェア側処理も、所定時間間隔で繰り返し実行される。
最初のＳ２００では、燃料残量低下の通知があったか否かを判断する。この処理は、図３中のＳ１３０に対応するものである。ここで燃料残量低下の通知があったと判断された場合（Ｓ２００：ＹＥＳ）、Ｓ２１０へ移行する。一方、燃料残量低下の通知がないと判断された場合（Ｓ２００：ＮＯ）、以降の処理を実行せず、汎用ミドルウェア側処理を終了する。
【００２２】
Ｓ２１０では、該当するアプリがインストールされているか否かを判断する。この場合、給油所の検索アプリがインストールされているか否かを判断する。ここで該当するアプリがあると判断された場合（Ｓ２１０：ＹＥＳ）、Ｓ２２０へ移行する。一方、該当するアプリがないと判断された場合（Ｓ２１０：ＮＯ）、Ｓ２５０へ移行する。
【００２３】
Ｓ２２０では、アプリをリスト表示する。例えば図５（ｂ）に記号Ｙで示すごとくである。地図表示に重ねてＡ給油所検索アプリ、Ｂ給油所検索アプリ、Ｃ給油所検索アプリ、・・・という具合にインストールされている給油所検索アプリをリスト表示する。
【００２４】
続くＳ２３０では、アプリが選択されたか否かを判断する。この処理は、Ｓ２２０にて表示される給油所検索アプリがリストから選択されたか否かを判断するものである。ここでアプリが選択されたと判断された場合（Ｓ２３０：ＹＥＳ）、Ｓ２４０へ移行する。一方、アプリが選択されないうちは（Ｓ２３０：ＮＯ）、Ｓ２２０からの処理を繰り返す。
【００２５】
Ｓ２４０では、アプリを起動する。この処理は、該当する給油所検索アプリを起動するものである。アプリの起動により、例えば、自車両の現在位置から近い位置にある給油所が検索され、ナビゲーション４０の表示部４１に表示される。
【００２６】
Ｓ２１０にて否定判断された場合に移行するＳ２５０では、アプリ候補をリスト表示する。この処理は、通信部１１ｂによってサーバ６０を介してストア７０から該当するアプリを検索し、その検索結果を、図５（ｃ）に記号Ｚで示すように、アプリ候補としてリスト表示するものである。
【００２７】
続くＳ２６０では、ダウンロード指示があったか否かを判断する。この処理は、Ｓ２５０にて表示される給油所検索アプリ候補がリストから選択されたか否かを判断するものである。ここでダウンロード指示があったと判断された場合（Ｓ２６０：ＹＥＳ）、Ｓ２４０にてアプリを起動し、その後、汎用ミドルウェア側処理を終了する。一方、ダウンロード指示がないと判断された場合（Ｓ２６０：ＮＯ）、Ｓ２４０の処理を実行せず、汎用ミドルウェア側処理を終了する。
【００２８】
以上詳述したように、本実施形態の表示制御装置１０は、専用ミドルウェア１３、汎用ミドルウェア１４、及び、インターフェース１５を備え、ナビゲーション４０の表示部４１における表示を制御する。このとき、専用ミドルウェア１３は、車両側で用意される専用アプリ１６を実行可能であり、汎用ミドルウェア１４は、外部から配信される汎用アプリ１７を実行可能である。また、インターフェース１５は、専用ミドルウェア１３と汎用ミドルウェア１４との間で必要情報の授受を行う。
【００２９】
このように表示制御装置１０に、専用ミドルウェア１３だけでなく外部から配信される汎用アプリ１７を実行する汎用ミドルウェア１４を搭載したため、従来と異なり、携帯端末を接続することなく、リリースの頻度が高く削除や追加が容易な汎用アプリ１７を利用することができる。また、インターフェース１５を介在させたため、外乱要因などでデータ通信に不具合が生じることがない。さらに、インターフェース１５の介在により、必要となる情報の授受のみを行うことができ、セキュリティーに関しても有利である。
【００３０】
特に、専用ミドルウェア側処理では、燃料センサ５０からの信号を車両情報として取得し、燃料残量が低下したと判断すると（図３中のＳ１００：ＹＥＳ）、車両状況としての燃料残量の低下を汎用ミドルウェア１４側へ通知する（Ｓ１３０）。そして、汎用ミドルウェア側処理では、燃料残量の低下が通知されると（図４中のＳ２００：ＹＥＳ）、該当するアプリ１７を起動する（Ｓ２４０）。
【００３１】
すなわち、車両に関連する車両情報を専用ミドルウェア１３側で取得する取得手段１０ａと、取得手段１０ａにて取得された車両情報に基づく車両状況を、インターフェース１５を介し汎用ミドルウェア１４側へ通知する通知手段１０ｂと、通知手段１０ｂにて通知された車両状況に基づき、汎用アプリ１７の中で当該車両状況に応じた表示を実現するための対象アプリ１７を汎用ミドルウェア１４側で起動する起動手段１０ｃと、を備えている。
【００３２】
これにより、車両に搭載される表示制御装置１０において、汎用アプリ１７との連携を取ることができる。
また、本実施形態では、該当するアプリ１７がある場合（図４中のＳ２１０：ＹＥＳ）、その中の１つを選択的に起動する（Ｓ２４０）。すなわち、起動手段１０ｃは、複数の対象アプリ１７がインストールされている場合、当該対象アプリ１７の中の１つを選択的に起動する。つまり、通知される車両状況に応じて汎用ミドルウェア１４側で起動するアプリ１７を判断するのである。これにより、例えば最新の対象アプリ１７を起動するという具合に、汎用アプリ１７の起動が柔軟になる。
【００３３】
なお、起動する対象アプリ１７は自動的に選択されるものとしてもよいが、本実施形態では、インストールされているアプリ１７をリスト表示し（図４中のＳ２２０）、ユーザによってアプリ１７が選択されると（Ｓ２３０：ＹＥＳ）、当該アプリ１７を起動する。すなわち、起動手段１０ｃは、対象アプリ１７をリスト表示し、リスト表示した対象アプリ１７の１つがユーザによって選択されると、当該選択された対象アプリ１７を起動する。これにより、ユーザが所望するアプリ１７を容易に起動することができる。
【００３４】
さらにまた、本実施形態では、該当するアプリ１７がない場合（図４中のＳ２１０：ＮＯ）、該当するアプリを外部からダウンロードして起動する（Ｓ２４０）。すなわち、起動手段１０ｃは、対象アプリ１７がインストールされていない場合、対象アプリ１７を外部からダウンロードして起動する。これにより、表示制御装置１０において汎用アプリ１７を利用することのメリットが際立つ。
【００３５】
なお、対象アプリ１７のダウンロードは自動的に行うものとしてもよいが、本実施形態では、候補となり得るアプリ１７をリスト表示し（図４中のＳ２５０）、ユーザによってアプリ１７が選択されると（Ｓ２６０：ＹＥＳ）、当該アプリ１７をダウンロードして起動する（Ｓ２４０）。すなわち、起動手段１０ｃは、対象アプリ１７がインストールされていない場合、外部から取得可能な対象アプリ１７の候補をリスト表示し、リスト表示した対象アプリ１７の１つが選択されると、当該選択された対象アプリ１７をダウンロードして起動する。これにより、ユーザが所望するアプリ１７を容易にダウンロードして起動することができる。
【００３６】
また、本実施形態では、燃料センサ５０からの信号を車両情報として取得し、燃料残量が低下したと判断すると（図３中のＳ１００：ＹＥＳ）、その旨を表示し（Ｓ１１０）、これに対するユーザのタッチ操作があると（Ｓ１２０：ＹＥＳ）、車両状況としての燃料残量の低下を汎用ミドルウェア１４側へ通知する（Ｓ１３０）。すなわち、通知手段１０ｂは、取得手段１０ａにて取得された車両情報に基づく車両状況を表示し、ユーザからの操作があると、当該車両状況を汎用ミドルウェア１４側へ通知する。これにより、ユーザが所望するときにだけ汎用アプリ１７を起動することができる。
【００３７】
以上、本発明は、上述した実施形態に何ら限定されるものではなく、その技術的範囲を逸脱しない限り、種々なる形態で実施することができる。
上記実施形態では、燃料センサ５０からの信号に基づいて燃料残量の低下を判断し（図３中のＳ１００）、燃料残量が低下すると（Ｓ１００：ＹＥＳ）、汎用ミドルウェア１４側へ燃料残量の低下を通知するものであった。
【００３８】
これに対して、例えばタイヤ空気圧センサからの信号に基づいてタイヤ空気圧の減少を判断して、汎用ミドルウェア１４側へタイヤ空気圧の減少を通知するようにしてもよい。この場合、汎用ミドルウェア側では、上記実施形態と同様に給油所検索アプリを起動したり、あるいは、ディーラーの修理工場を検索したりすることが考えられる。
【００３９】
つまり、専用ミドルウェア１３側で取得される車両情報に応じ専用ミドルウェア１３から通知される車両状況に基づいて汎用ミドルウェア１４側で関連する対象アプリを起動させるものであればよい。
【００４０】
なお、専用ミドルウェア１３側と汎用ミドルウェア１４側との情報授受は情報の容量によってその経路が異なるようにしてもよい。
つまり、ある所定の閾値よりも大きなデータのやり取りは、各ミドルウェアからインターフェース１５を経て一旦汎用ＯＳ１２を介してなされるようにする。一方閾値未満のデータのやり取りは汎用ＯＳ１２を介さずに、インターフェース１５により直接行うようにする。このようにすれば、小さなデータのやり取りでは特に迅速性が確保され、また大きなデータのやり取りであってもスムーズに処理ができるようになる効果がある。
【符号の説明】
【００４１】
１０…表示制御装置、１０ａ…取得手段、１０ｂ…通知手段、１０ｃ…起動手段、１１…ハードウェア、１１ａ…ＣＰＵ、１１ｂ…通信部、１２…汎用ＯＳ、１３…専用ミドルウェア、１４…汎用ミドルウェア、１５…インターフェース、１６…専用アプリ、１７…汎用アプリ、２０…エアコン、３０…オーディオ、３１…アンプ、４０…ナビゲーション、４１…表示部、５０…燃料センサ、６０…サーバ、７０…ストア
【図１】
2014221620.tif 000003
【図２】
2014221620.tif 000004
【図３】
2014221620.tif 000005
【図４】
2014221620.tif 000006
【図５】
2014221620.tif 000007