(57)【要約】【課題】  モニタが故障しても重要な表示ができる車両用マルチモニタシステムを提供すること。【解決手段】  コネクタ２６，３６で車内通信ライン６に接続され、その情報をカーナビAP１６，メータAP１５で処理し、自機器の情報を車内通信ライン６にコネクタ２６，３６で出力するCPU２３，３３と、CPU２３，３３で処理した情報を運転者に表示する液晶モニタ２１，３１とを備える表示装置２，３を車両に複数設け、複数の車載機器に対応した複数種類のアプリケーションを保存し、コネクタ１７で接続した車内通信ライン６を通じて表示装置２，３の情報を入力し、複数種類のアプリケーションを表示装置２，３へコネクタ１７で接続した車内通信ライン６を通じて配信するCPU１１を備える車載サーバ１を車内に設けた。【選択図】        図１
2005221664.tif 000002
【特許請求の範囲】
【請求項１】
車内ネットワークを通じて表示に用いる情報を入力する表示情報入力手段と、
同表示情報入力手段からの情報をアプリケーションで処理する表示情報処理手段と、
同表示情報処理手段で処理した情報を運転者に表示する表示手段と、
自機器の情報を車内ネットワークに出力する表示器情報出力手段と、
を備える表示装置を車両に複数設け、
複数の車載機器に対応した複数種類のアプリケーションを保存しておくAP保存手段と、
車内ネットワークを通じて前記表示装置の情報を入力する装置情報入力手段と、
同装置情報入力手段からの情報により、複数種類のアプリケーションを振り分け、車内ネットワークを通じて、各表示装置へアプリケーションを配信するAP配信手段と、
を備える表示管理装置を車内に設けた、
ことを特徴とする車両用マルチモニタシステム。
【請求項２】
請求項１に記載された車両用マルチモニタシステムにおいて、
前記表示器情報出力手段が出力する表示装置の情報に、表示能力が含まれるようにし、
前記AP配信手段が、
前記装置情報入力手段からの情報により、各表示装置の表示能力を判断する、
ことを特徴とする車両用マルチモニタシステム。
【請求項３】
請求項１または請求項２に記載された車両用マルチモニタシステムにおいて、
前記AP配信手段が、
複数種類のアプリケーションから、優先度に従って配信するアプリケーションを判断する、
ことを特徴とする車両用マルチモニタシステム。
【請求項４】
請求項３に記載された車両用マルチモニタシステムにおいて、
優先度の高いアプリケーションの表示を行っている表示装置に異常があると、優先度の低いアプリケーションの表示を行っている表示装置に優先度の高いアプリケーションの表示を行う変更機能を前記表示装置と前記表示管理装置に設けた、
ことを特徴とする車両用マルチモニタシステム。
【請求項５】
請求項４に記載された車両用マルチモニタシステムにおいて、
車両に搭載される車載機器が、
表示部を有しないようにし、
表示したい情報を、車内ネットワークを通じて前記表示装置に出力する、
ことを特徴とする車両用マルチモニタシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載され乗員に情報を伝達するために表示を行う車両用マルチモニタシステムの技術分野に属する。
【背景技術】
【０００２】
従来において、例えば、車両のセンターコンソールに設置されるモニタでは、地図表示、オーディオの表示を行っている（例えば、特許文献１参照。）。
【特許文献１】特開平７−３０６０５５号公報（第２−３頁、全図）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、従来にあっては、車両が複数のモニタを有する場合であっても、表示する内容は予め決まったものであった。よって、表示を必要とする新たな装置を設ける場合には、表示装置を新たに設ける必要があった。
また、ある装置のモニタが故障等すると、その車載装置の情報は表示できなくなっていた。
【０００４】
本発明は、上記問題点に着目してなされたもので、その目的とするところは、モニタが故障しても重要な表示ができる車両用マルチモニタシステムを提供することにある。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、本発明では、車内ネットワークを通じて表示に用いる情報を入力する表示情報入力手段と、表示情報入力手段からの情報をアプリケーションで処理する表示情報処理手段と、表示情報処理手段で処理した情報を運転者に表示する表示手段と、自機器の情報を車内ネットワークに出力する表示器情報出力手段とを備える表示装置を車両に複数設け、複数の車載機器に対応した複数種類のアプリケーションを保存しておくAP保存手段と、車内ネットワークを通じて前記表示装置の情報を入力する装置情報入力手段と、装置情報入力手段からの情報により、複数種類のアプリケーションを振り分け、車内ネットワークを通じて、各表示装置へアプリケーションを配信するAP配信手段とを備える表示管理装置を車内に設けたことを特徴とする。
【発明の効果】
【０００６】
よって、本発明にあっては、表示装置に故障等が生じて表示ができなくなった場合でも、他の表示装置で表示ができ、車両を使用する人に必要な情報を確実に表示できる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の車両用マルチモニタシステムを実現する実施の形態を、請求項１，２，３，４，５に係る発明に対応する実施例１に基づいて説明する。
【実施例１】
【０００８】
まず、構成を説明する。
図１は実施例１の車両用マルチモニタシステムのブロック図である。図２は実施例１の車両用マルチモニタシステムのクライアント側とサーバ側との通常時の制御処理の流れを示す制御フロー図である。図３は実施例１の車両用マルチモニタシステムのクライアント側とサーバ側との障害時の制御処理の流れを示す制御フロー図である。図４は実施例１の車両用マルチモニタシステムのメータ部のフルカラー表示の表示例を示す説明図である。図５は実施例１の車両用マルチモニタシステムのメータ部のドットマトリックス表示の表示例を示す説明図である。図６は実施例１の車両用マルチモニタシステムのカーナビ部のフルカラー表示の表示例を示す説明図である。図７は実施例１の車両用マルチモニタシステムのカーナビ部のフルカラー表示の表示例を示す説明図である。図８は実施例１の車両用マルチモニタシステムのカーナビ部のドットマトリックス表示の表示例を示す説明図である。
【０００９】
実施例１の車両用マルチモニタシステムの主要な構成は、車載サーバ１、カーナビ部となる表示装置２、メータ部となる表示装置３を車内通信ライン６に接続して構成される。
車載サーバ１（表示管理装置に相当する）には、情報の入出力、処理を行うCPU１１（AP保存手段、装置情報入力手段、AP配信手段に相当する）と、車内ネットワークに接続された表示器を判断し、どの表示器にどのアプリケーションを受け持たせるかを決める初期ロード判断AP１２と、各車載機器の表示に関するアプリケーションであるオーディオAP１３、エアコンAP１４、メータAP１５、カーナビAP１６とをアプリケーションとして備える。
オーディオAP１３、エアコンAP１４、メータAP１５、カーナビAP１６は、ROM等の記憶手段に格納されているものとする。
【００１０】
表示装置２は、情報を表示する液晶モニタ２１（表示手段に相当する）と、情報の入出力、処理を行うCPU２３（表示情報処理手段に相当し、コネクタ２６と共に表示情報入力手段、表示器情報出力手段に相当する）、情報を一時的に記憶するメモリ２２、車載サーバ１から受信したアプリケーションであるカーナビAP２４、自機器の情報を車載サーバ１に送信するためのアプリケーションである初期ロード判断AP２５、車内通信ライン６に接続するためのコネクタ２６で構成される。
【００１１】
表示装置３は、情報を表示する液晶モニタ３１（表示手段に相当する）と、情報の入出力、処理を行うCPU３３（表示情報処理手段に相当し、コネクタ２６と共に表示情報入力手段、表示器情報出力手段に相当する）、情報を一時的に記憶するメモリ３２、車載サーバ１から受信したアプリケーションであるメータAP３４、自機器の情報を車載サーバ１に送信するためのアプリケーションである初期ロード判断AP３５、車内通信ライン６に接続するためのコネクタ３６で構成される。
【００１２】
さらに、車内通信ライン６には、車体を制御するBCM(Body Control Module)、車両装置や車載装置を制御するECM(Electric Control Module)が接続される。
実施例１では、表示装置２，３のコネクタ２６，３６は共通にしておく。また、さらに別の表示装置を設ける場合にも、そのコネクタは共通にする。
【００１３】
次に、作用を説明する。
【００１４】
［通常時の制御処理］
図２は実施例１の車載サーバ１と表示装置２，３で実行される制御処理の流れを示す制御フロー図である。
まず表示装置２，３での処理について説明する。
【００１５】
ステップＳ１０１では、表示装置２，３（クライアント側）のID情報を含むデータを車載サーバ１に送信する。
【００１６】
ステップＳ１０２では、車載サーバ１によって割り当てられた車載機器に対応するアプリケーション（カーナビAP２４やメータAP３４）を車載サーバ１から受信する。
【００１７】
ステップＳ１０３では、受信したアプリケーションを作動させるために必要な専用リソースを車載サーバ１から受信する。
【００１８】
ステップＳ１０４では、割り当てられた車載機器に対応する専用のアプリケーションを起動する。
【００１９】
ステップＳ１０５では、専用アプリケーションの作動によって、自己診断データを車載サーバ１に定期送信する。
【００２０】
次に車載サーバ１での処理について説明する。
【００２１】
ステップＳ２０１では、表示装置２，３（クライアント側）から送信されたID情報を含むデータを受信する。
【００２２】
ステップＳ２０２では、どの車載機器に対応させるかを割り当てた表示装置２，３に対して、その車載機器に対応する専用のアプリケーションを送信する。
【００２３】
ステップＳ２０３では、表示装置２，３が専用のアプリケーションを作動させるために必要なリソースを配信する。
【００２４】
ステップＳ２０４では、表示装置２，３（クライアント側）からの自己診断データを定期的に受信し、表示装置２，３を監視する。
【００２５】
［障害時の制御処理］
図３は実施例１の車載サーバ１と表示装置２，３で実行される制御処理の流れを示す制御フロー図である。
まず、表示装置２，３での処理について説明する。
【００２６】
ステップＳ１１１では、自己診断データを定期的に車載サーバ１に送信する。
この処理において、いずれかの表示装置２，３の自己診断データに異常があるかもしくは、自己診断データが送信されない状態となる。
【００２７】
ステップＳ１１２では、車載機器に対応した専用のアプリケーションを新たに受信する。例えば、メータの表示を行っている表示装置３で異常がある場合には、メータを表示するためのアプリケーションが別の表示装置２で受信されることになる。
【００２８】
ステップＳ１１３では、新たに受信したアプリケーションを作動させるための専用のリソースを車載サーバ１より受信する。
【００２９】
ステップＳ１１４では、新たに専用のアプリケーションを起動させる。
【００３０】
ステップＳ１１５では、新たに起動したアプリケーションが、自己診断データを定期的に車載サーバ１に送信する。
【００３１】
次に、車載サーバ１の処理について説明する。
【００３２】
ステップＳ２１１では、表示装置２，３（クライアント側）からの自己診断データを定期的に受信する。
この場合では、自己診断データに異常があったことを示されるか、自己診断データを定期的に受け取れない状態となっている。
【００３３】
ステップＳ２１２では、異常があった表示装置で作動させたアプリケーションの優先度を判断して、他の機器に割り当てる必要がある場合には、アプリケーションの割り当てを変更して、再度、車載機器に対応する専用のアプリケーションを配信する。
【００３４】
ステップＳ２１３では、再配信した専用のアプリケーションを作動させるために必要なリソースを配信する。
【００３５】
ステップＳ２１４では、再配信し、作動した表示装置２，３からの自己診断データを定期的に受信し、表示装置２，３（クライアント側）を監視する。
【００３６】
［表示の処理について］
〈1〉通常時
実施例１では、ナビゲーション装置とメータ装置を例に説明する。車載されるナビゲーション装置とメータ装置は、液晶ディスプレイのような表示装置部分を持たないようにする。
さらに、メータ装置の様に表示が主要な機能であり、本体を有する必要がない場合には、設けなくてもよい。
よって、図１に示すブロック図には、ナビゲーション装置の本体、及びメータ装置の本体は示さない。
【００３７】
車載サーバ１が接続された車内ネットワークの車内通信ライン６に何を表示させるかを定めていない表示装置２，３を接続すると、表示装置２，３に予め設けた初期ロード判断AP２５，３５がID情報を含む自機器のデータを車載サーバ１にステップＳ１０１の処理で送信する。
車載サーバ１では、表示装置２，３からのデータをステップＳ２０１の処理で受信し、その表示装置２，３の表示能力、カラー表示を行うことができる液晶表示のものか、主に文字を表示するドットマトリックス表示のものか等を判断する。
【００３８】
さらに、設置位置による運転者への優先度も判断する。
次に、車載機器の表示に関して、予め定めた優先度に従って、どのアプリケーションを使用して表示を行なうかを判断するとともに、その判断に従って、カーナビAP１６を表示装置２へ、メータAP１５を表示装置３へステップＳ２０２の処理により配信する。
【００３９】
ステップＳ１０２の処理により、アプリケーションを車内ネットワークから受信した表示装置２，３は、その後にステップＳ２０３の処理により配信されるアプリケーションを作動させるためのリソースをステップＳ１０３の処理で受信して、ステップＳ１０４の処理により起動する。
すると、表示装置２はカーナビ装置の表示部となり、表示装置３はメータの表示部となる。各表示装置では、車内ネットワークを通じて得られるカーナビ表示、メータ表示に必要な情報を各アプリケーションで処理して表示を行う。
【００４０】
このアプリケーションの配信の際には、その表示装置や表示内容に応じて、図４に示すようなカラーのメータ表示、図５に示すようなドットマトリックスでも表示が可能なメータ表示、図６，図７に示すようなカラーのナビゲーション表示、図８に示すようなドットマトリックスのナビゲーション表示が各アプリケーションにより行われる。また、表示能力により異なるアプリケーションとしてもよい。
また、各表示装置２，３は各アプリケーションで行う自己診断データを車載サーバ１にステップＳ１０５の処理で送信し、車載サーバ１はステップＳ２０４の処理で、そのデータを受信して各表示装置２，３の監視を行う。
【００４１】
このように、表示装置側では、アプリケーション及びリソースを備える必要がないため、装置の負荷、メモリ消費が小さくなる。また、装置のコスト低減や省スペースが行える。
【００４２】
〈2〉異常時
このようにして、車載サーバ１によって振り分けられ、カーナビ装置、メータ装置の表示部として表示装置２，３が表示を行っている際に、何らかの異常が、例えば表示装置３に発生したならば、車載サーバ１は、表示装置３からの自己診断データにより、または自己診断データを所定の時間が経過しても受け取れないことにより、異常を検知する。
【００４３】
異常が検知されると、車載サーバ１では、アプリケーションの再振り分けを行う。ここでは、例として表示装置３に異常がある。表示装置３で表示させているメータAP１５とカーナビAP１６を比較すると、メータAP１５で表示させている情報の運転者に対する重要度が高いため、今度は表示装置２にメータAP１５をステップＳ２１２の処理で再配信する。カーナビAP１５は、優先度が低いことをIDデータで識別される他の表示装置が車内ネットワークに接続されている場合には、その表示装置に送信されることになる。
よって、ステップＳ１１２〜Ｓ１１４、Ｓ２１２〜Ｓ２１３の処理によって、今度は表示装置２がメータAP１５によって、メータ装置の表示を行うように変更される。
【００４４】
そのため、車載機器の表示を行っている表示部に異常があり表示ができなくなると、次に優先順位の表示装置が、その表示を行い、運転者に必要な情報を確実に伝達する。
また、異常により表示装置を交換する際にも、車載装置と共に交換する必要がないため、保守・交換などの費用も低くなる。
【００４５】
本実施例１では、表示装置２と表示装置３を例に説明しているが、実際には、カラー表示を行うもの、カラー表示を行わないものを含め多くの表示部が車内には設けられることになる。
そのため、運転者に必要な情報は、位置を変えて、カラー表示をモノクロのドットマトリックス表示に変えても、また、内容を簡略化しても表示されるようになる。
このように車内の表示装置が効率的に使用されると、車内には、ムダに高い表示能力を有する表示装置が設けられなくなる。
【００４６】
次に、効果を説明する。
実施例１の車両用マルチモニタシステムにあっては、下記に列挙する効果を得ることができる。
【００４７】
(1)コネクタ２６，３６で車内通信ライン６に接続され、その情報をカーナビAP１６，メータAP１５で処理し、自機器の情報を車内通信ライン６にコネクタ２６，３６で出力するCPU２３，３３と、CPU２３，３３で処理した情報を運転者に表示する液晶モニタ２１，３１とを備える表示装置２，３を車両に複数設け、複数の車載機器に対応した複数種類のアプリケーション（オーディオAP１３、エアコンAP１４、メータAP１５、カーナビAP１６）を保存し、コネクタ１７で接続した車内通信ライン６を通じて表示装置２，３の情報を入力し、複数種類のアプリケーション（オーディオAP１３、エアコンAP１４、メータAP１５、カーナビAP１６）を表示装置２，３へコネクタ１７で接続した車内通信ライン６を通じて配信するCPU１１を備える車載サーバ１を車内に設けたため、表示内容に優先度を設けて、表示装置が故障して表示できなくなった場合は、自動的にそれ以下の優先度の表示装置に表示内容を代替させることで、ユーザーにとって必要な情報表示を行うことができる。
【００４８】
(2)CPU２３，３３が出力する表示装置２，３の情報に、表示能力が含まれるようにし、車載サーバ１のCPU１１が、車内通信ライン６からのデータにより、各表示装置の表示能力を判断するため、車内の表示装置２，３が効率的に使用される。
【００４９】
(3)CPU１１が、複数種類のアプリケーションから、優先度に従って配信するアプリケーションを判断するため、表示装置２，３の表示能力、設置位置等に合い、且つ重要度を考慮した表示ができる。
【００５０】
(4)優先度の高いアプリケーション（メータAP１５）の表示を行っている表示装置３に異常があると、メータAP１５より優先度の低いアプリケーション（カーナビAP１６）の表示を行っている表示装置２に優先度の高いアプリケーション（メータAP１５）の表示を行う変更機能を表示装置２，３と車載サーバ１に設けたため、故障等が生じても、運転者の必要性の高い情報は確実に表示できる。
【００５１】
(5)車両に搭載される車載機器が、表示部を有しないようにし、表示したい情報を、車内通信ライン６を通じて表示装置２，３に出力するため、異常時の保守・交換が容易にでき、省スペース、コスト低減を行うことができる。
また、表示装置と車載機器が切り離されることは、車載される機器の多様化に対して、表示が無統一的に増加して車両の使用者を混乱させるようなことを起こさず、車内での種々の表示を統一的に効率よく見せることができ、多様化する車載機器を容易に操作することができる。さらに、これらの効果により車載機器の操作フィーリングが向上できる。
【００５２】
以上、本発明の車両用マルチモニタシステムを実施例１に基づき説明してきたが、具体的な構成については、これらの実施例に限られるものではなく、特許請求の範囲の各請求項に係る発明の要旨を逸脱しない限り、設計の変更や追加等は許容される。
【００５３】
例えば、実施例１のマルチモニタシステムに加えて、運転者の操作による切り換えを行うようにして、運転者の交代や状況等にさらによく対応できるようにしてもよい。
【図面の簡単な説明】
【００５４】
【図１】実施例１の車両用マルチモニタシステムのブロック図である。
【図２】実施例１の車両用マルチモニタシステムのクライアント側とサーバ側との通常時の制御処理の流れを示す制御フロー図である。
【図３】実施例１の車両用マルチモニタシステムのクライアント側とサーバ側との障害時の制御処理の流れを示す制御フロー図である。
【図４】実施例１の車両用マルチモニタシステムのメータ部のフルカラー表示の表示例を示す説明図である。
【図５】実施例１の車両用マルチモニタシステムのメータ部のドットマトリックス表示の表示例を示す説明図である。
【図６】実施例１の車両用マルチモニタシステムのカーナビ部のフルカラー表示の表示例を示す説明図である。
【図７】実施例１の車両用マルチモニタシステムのカーナビ部のフルカラー表示の表示例を示す説明図である。
【図８】実施例１の車両用マルチモニタシステムのカーナビ部のドットマトリックス表示の表示例を示す説明図である。
【符号の説明】
【００５５】
１  車載サーバ
１１  CPU
１２  初期ロード判断AP
１３  オーディオAP
１４  エアコンAP
１５  メータAP
１６  カーナビAP
２  表示装置
２１  液晶モニタ
２２  メモリ
２３  CPU
２４  カーナビAP
２５  初期ロード判断AP
２６  コネクタ
３  表示装置
３１  液晶モニタ
３２  メモリ
３３  CPU
３４  メータAP
３５  初期ロード判断AP
３６  コネクタ
６  車内通信ライン
BCM  ボディコントロールモジュール
ECM  コントローラ
【図１】
2005221664.tif 000003
【図２】
2005221664.tif 000004
【図３】
2005221664.tif 000005
【図４】
2005221664.tif 000006
【図５】
2005221664.tif 000007
【図６】
2005221664.tif 000008
【図７】
2005221664.tif 000009
【図８】
2005221664.tif 000010