JP2015095141A - 車両状況通知システム - Google Patents

Abstract

【課題】車両に所定の状況が発生した場合に対応するシステムにおいて、運行管理者のみに頼る場合に比べて、より高い確率で当該状況に対応可能となるようにする技術を提供する。
【解決手段】センターサーバ１が、複数の車載機３ａ、３ｂの各々から、当該車載機の搭載先の車両が運行しているか否かがわかる運行有無情報を受信し、受信した運行有無情報を保存する。車載機３ａは、搭載先の車両におけるドライバの眠気発生を検知したことに基づいて、眠気発生情報をセンターサーバ１に通知する。センターサーバ１は、車載機３ａから眠気発生情報を受信した場合、保存された運行有無情報に基づいて、運行中の車両２ｂを通知先車両とし、通知先車両２ｂのドライバに、車両３ａのドライバの眠気発生を通知する。
【選択図】図９

Description

本発明は、車両状況通知システムに関するものである。

従来、ぼんやり運転や居眠り運転による事故を防止するために、ドライバの眠気を検知した際に、音声警報を出力したり、冷風を吹き付けたり、座席を振動させたり、ステアリングの温度を上昇させたりして覚醒誘導を行うシステムがある。しかしこれらの単純な物理的刺激による覚醒誘導方法は、脳の活性化に繋がらず、また、人間の慣れという特性により効果が薄まっていく。

上記問題を解決するために、脳の活性化に有効な人同士の会話を利用した覚醒誘導方法が提案されている。例えば特許文献１に記載の技術では、ドライバのぼんやり運転や居眠り運転を車載装置が検知すると、その車載装置が無線通信でセキュリティセンターに通報する。すると、セキュリティセンターの支援コンピュータとが車載装置と通信し、セキュリティセンターの運行管理者とドライバとの会話が実現し、運行管理者は、休憩をドライバに指示したり、会話そのものによりドライバを覚醒させることができる。

特開２００３−１２３１９８号公報

しかし、発明者の検討によれば、特許文献１のような覚醒誘導方法にも以下のような問題がある。運行管理者は必ずしも２４時間スタンバイしているとは限らず、そもそも居眠り運転の発生が多い午前３〜６時は、運行管理者自身が休眠をとっているケースが多い。したがって、ドライバの眠気発生時に対応すべき運行管理者がいないケースが多いと考えられる。

また、運行管理者が必ずしも２４時間スタンバイしているとは限らないという問題は、ドライバの眠気発生時の対応のみならず、車両の故障発生時等、車両の種々の状況発生時の対応に対しても、同等の悪影響を及ぼす。

本発明は上記点に鑑み、車両に所定の状況が発生した場合に対応するシステムにおいて、運行管理者のみに頼る場合に比べて、より高い確率で当該状況に対応可能となるようにする技術を提供することを目的とする。

上記目的を達成するための請求項１に記載の発明は、複数の車両（２ａ〜２ｄ）にそれぞれ搭載される複数の車載機（３ａ〜３ｄ）と、前記複数の車載機の各々から、当該車載機の搭載先の車両が運行しているか否かがわかる運行有無情報を受信し、受信した前記複数の車両毎の運行有無情報を車両情報データベース（１２）に保存するセンターサーバ（１）と、を備え、前記複数の車載機のうち第１の車載機（３ａ）は、前記第１の車載機の搭載先である第１の車両（２ａ）の所定の状況を検知したことに基づいて、前記所定の状況を検知したことを示す状況発生情報を前記センターサーバに通知し、前記センターサーバは、前記第１の車載機から前記状況発生情報を受信した場合、前記車両情報データベース中に保存された運行有無情報に基づいて、前記複数の車両のうち運行中の車両を通知先車両とし、前記通知先車両のドライバに、前記第１の車両の前記所定の状況を通知することを特徴とする車両状況通知システムである。

このように、第１の車両に所定の状況が発生し、第１の車載機が状況発生情報をセンターサーバに送信すると、センターサーバは、運行中の車両のドライバに当該所定の状況を通知する。当該運行中の車両のドライバは、業務遂行中なので、当該所定の状況の通知に対して何らかの対応ができる可能性が高い。したがって、運行管理者のみに頼る場合に比べて、より高い確率で当該状況に対応可能となる。

なお、上記および特許請求の範囲における括弧内の符号は、特許請求の範囲に記載された用語と後述の実施形態に記載される当該用語を例示する具体物等との対応関係を示すものである。

本発明の第１実施形態に係る車両状況通知システムの構成図である。 センターサーバの構成図である。 車載機の構成図である。 車載機の通常送信処理のフローチャートである。 車両情報の構成図である。 動態情報の構成図である センターサーバの通常受信処理のフローチャートである。 車両情報データベースの構成図である。 第１の事例における車両状況通知システムの作動シーケンス図である。 眠気発生情報の構成図である。 眠気対応処理のフローチャートである。 運行状態と通知優先度の対応関係の図である。 車載機における眠気ドライバ情報受信時のフローチャートである。 車載機における表示例である。 第２の事例における車両状況通知システムの作動シーケンス図である。 本発明の第２実施形態における車両情報の構成図である。 第２実施形態における車両情報データベースの構成図である。 第２実施形態における運行状態と通知優先度の対応関係の図である。 本発明の第３実施形態における車両状況通知システムの作動シーケンス図である。

（第１実施形態）
以下、本発明の第１実施形態について説明する。図１に示すように、本実施形態に係る車両状況通知システムは、複数個の車両２ａ〜２ｄにそれぞれ搭載される複数個の車載機３ａ〜３ｄと、センターサーバ１とを有している。

この車両２ａ〜２ｄは、商用車である。より具体的には、同じ運輸会社が保有するすべての荷物運搬用車両である。各車載機３ａ〜３ｄは、センターサーバ１に対して自機の搭載先の車両２ａ〜２ｄの位置情報等を送信し、センターサーバ１は、それら送信された情報を保存および必要に応じて他の通信機器に送信するようになっている。

図２に示すように、センターサーバ１は、通信部１１、記憶部１２、センター制御部１３を有している。通信部１１は、車載機３ａ〜３ｄ、車両２ａ〜２ｄのドライバが有する携帯端末（例えば携帯電話機）、および、運輸会社の管理用通信端末等と通信するための通信インターフェースである。記憶部１２には、センター制御部が実行するプログラム、および後述する車両情報データベース１２ａが保存されている。センター制御部１３は、記憶部１２に記録されたプログラムを実行することで、後述するＷｅｂサービス処理１３ａおよび眠気対応処理１３ｂを実行する。センター制御部１３としては、パーソナルコンピュータ、ワークステーション等のＣＰＵ、ＲＡＭ、ＲＯＭ等によって実現されていてもよい。

車載機３ａ〜３ｄは、同じ構成および機能を有し、それぞれが、図３に示すように、位置検出部３０、通信部３１、データ読取部３２、マイク３３、スピーカ３４、操作部３５、ディスプレイ３６、眠気検知部３７、および車載制御部３８を有している。

位置検出部３０は、ＧＰＳ受信機、加速度センサ、ヨーレートセンサ等、衛星航法および自律航法で搭載先の車両の現在位置を検出するためのセンサである。通信部３１は、センターサーバ１との通信を可能とするための無線通信インターフェースである。データ読取部３２は、自機の搭載先の車両のドライバの情報が記録された携帯型記憶媒体（例えば、ＳＤカード）を読み取る装置である。

マイク３３は、自機の搭載先車両の運転席に座るドライバの音声が入力可能な構成および配置となっている。スピーカ３４は、自機の搭載先車両の運転席に座るドライバに聞こえるように音声を出力可能な構成および配置となっている。操作部３５は、自機の搭載先車両の運転席に座るドライバが直接操作可能な構成および配置となっている。ディスプレイ３６は、自機の搭載先車両の運転席に座るドライバに視覚情報（文字、画像等）表示する装置であり、例えばＬＣＤによって実現可能である。

眠気検知部３７は、自機の搭載先車両の運転席に座るドライバの眠気レベルを検知するためのセンサである。例えば、眠気検知部３７は、ドライバの顔画像を繰り返し撮影し車載制御部３８に入力するカメラであってもよい。あるいは眠気検知部３７は、ドライバに対して光、音等の知覚信号を発する装置と、この知覚信号に反応してドライバが操作する確認ボタンとの組み合わせであってもよい。前者の場合、車載制御部３８は、カメラから逐次入力されるドライバの顔画像に基づいて、周知の方法でドライバの眠気レベルを算出する。後者の場合、車載制御部３８は、知覚信号に対する確認ボタン操作の遅れ時間が入力されたことに基づいて、遅れ時間に応じたドライバの眠気レベルを算出する。

車載制御部３８は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリ等を有するマイクロコンピュータによって実現される。ＲＯＭに記録されたプログラムをＣＰＵが実行することで、車載制御部３８の後述する種々の処理が実現する。

以下、上記のような構成の車両状況通知システムの作動について説明する。まず、通常運行時の作動について説明する。各車載機３ａ〜３ｄの車載制御部３８は、図４に示す通常送信処理を、車両の主電源（例えばＩＧ）がオンの間、繰り返し（例えば定期的に１分間隔で）実行するようになっている。

各車載制御部３８は、図４の処理において、まずステップ３０１で、フラッシュメモリから車両情報を読み出し、通信部３１を用いて、センターサーバ１に対してこの車両情報を送信する。このとき送信する車両情報の構成は、図５の通りである。すなわち、車両情報は、搭載先車両の車両ＩＤ、搭載先車両を使用するドライバのドライバＩＤ、および搭載先車両の位置情報を含んでいる。

車両ＩＤは、車載制御部３８の搭載先の車両を他の車両と区別するための識別コードであり、あらかじめ車載制御部３８のフラッシュメモリ等に記録されている。なお、車両とその車両に搭載される車載機は、固定的な１対１の関係にあるので、車両ＩＤは、実質的に車載機を他の車載機と区別するための識別コード（すなわち車載機ＩＤ）でもある。

ドライバＩＤは、車載制御部３８の搭載先車両のドライバを他のドライバと区別するための識別コードである。例えば、ドライバが当該搭載先車両に搭乗したときに、自己のドライバＩＤが記録された携帯型記憶媒体（例えばＳＤカード）を当該搭載先車両の車載機のデータ読取部３２に装着する。すると、データ読取部３２が当該ドライバＩＤを読み取り、車載制御部３８が当該読み取られたドライバＩＤをフラッシュメモリに保存する。位置情報は、車載制御部３８の搭載先車両の現在位置を示す情報であり、車載制御部３８が位置検出部３０から逐次取得する。

続いてステップ３０３では、ドライバが操作部３５に対して動態入力操作を行ったか否かを判定する。動態入力操作は、車両の動態に変化を及ぼすような入力操作である。操作部３５は、動態入力操作を受け付けるボタンを複数有する。具体的には、運行開始ボタン、運行終了ボタン、休憩開始ボタン、休憩終了ボタン、休息開始ボタン、休息終了ボタン、荷積み開始ボタン、荷積み終了ボタン、荷卸し開始ボタン、荷卸し終了ボタン、実車ボタン、空車ボタンを有する。

これらの動態入力操作用のボタンのうちいずれか１つが新たに押下された場合、ステップ３０３で動態入力有りと判定し、ステップ３０５に進む。これらの動態入力操作用のボタンが新たに押下されていない場合、ステップ３０３で動態入力なしと判定して今回の図４の処理を終了する。

ステップ３０５では、動態入力操作の内容に基づいて、すなわち、押下された動態入力操作用のボタンの種類に基づいて、フラッシュメモリに保存されている動態情報を更新する。動態情報の構成は、図６のようになっている。すなわち、動態情報は、運行終了時刻、運行開始時刻、休憩・休息情報、荷積・荷卸情報、および実車・空車情報を含んでいる。

ここで、運行とは、車両が業務（例えば荷物の配送）に使用されることをいう。また、休憩とは、車両の運行中にドライバが一時的に比較的短い時間だけ業務を休むことをいう。トイレ休憩等の１時間未満の休みが休憩に該当する。また、休息とは、車両の運行中にドライバが一時的に比較的長い時間だけ業務を休むことをいう。仮眠等のための１時間以上の休みが休息に該当する。また、荷積み、荷卸しとは、それぞれ、車両の運行中にドライバが車両に荷を積む行為および車両から荷を下ろす行為をいう。また、実車とは、車両に積荷が搭載されていない状態をいい、空車とは、車両に積荷が搭載されていない状態をいう。なお、休憩、休息、荷積み、荷卸し中においても、車両が運行中であり続ける。

車載制御部３８は、動態情報の更新を、以下のようにして行う。搭載先車両の運行が終了して運行終了ボタンが押下された場合、運行終了時刻の値現在時刻（日の情報も含む）に書き換える。また、搭載先車両の運行の開始時に運行開始ボタンが押下された場合、運行開始時刻の値を現在時刻（日の情報も含む）に書き換えると共に、休憩・休息情報および荷積・荷卸情報の値を「なし」に変更する。

また、ドライバが休憩を取り始める際に休憩開始ボタンが押下された場合、休憩・休息情報の値を「休憩中」に変更する。また、ドライバが休憩を終了した後に休憩終了ボタンが押下された場合、休憩・休息情報の値を「なし」に変更する。

また、ドライバが休息を取り始める際に休息開始ボタンが押下された場合、休憩・休息情報の値を「休息中」に変更する。また、ドライバが休息を終了した後に休息終了ボタンが押下された場合、休憩・休息情報の値を「なし」に変更する。

また、ドライバが荷積みを始める際に荷積み開始ボタンが押下された場合、荷積・荷卸情報の値を「荷積み中」に変更する。また、ドライバが荷積みを終了した後に荷積み終了ボタンが押下された場合、荷積・荷卸情報の値を「なし」に変更する。

また、ドライバが荷卸しを始める際に荷卸し開始ボタンが押下された場合、荷積・荷卸情報の値を「荷卸し中」に変更する。また、ドライバが荷卸しを終了した後に荷卸し終了ボタンが押下された場合、荷積・荷卸情報の値を「なし」に変更する。

また、車両の積荷が全くない状態から積荷がある状態に変化した場合、ドライバは実車ボタンを押下し、その場合、車載制御部３８は、は、実車・空車情報の値を「実車」に変更する。また、車両の積荷がある状態から全くない状態に変化した場合、ドライバは空車ボタンを押下し、その場合、車載制御部３８は、は、実車・空車情報の値を「空車」に変更する。

ステップ３０５に続いてステップ３０７で、車載制御部３８は、更新された動態情報と搭載先車両の車両ＩＤを通信部３１を用いてセンターサーバ１に送信し、その後、図４の処理を終了する。

このような図４の処理により、各車載機３ａ〜３ｄは、センターサーバ１に対して繰り返し車両情報を送信すると共に、動態情報に変化がある度に車両ＩＤと動態情報を送信する。一方、センターサーバ１では、センター制御部１３が、通信部１１を介して車載機３ａ〜３ｄから車両情報または動態情報を受信する度に、図７の通常受信処理を実行し、ステップ１０１で、受信した情報（車両情報または動態情報）を、車両情報データベース１２に保存し、その後通常受信処理を終了する。

車両情報データベース１２は図８のような構成となっている。すなわち、車両別動態情報、車両別位置情報、車両別ドライバ情報、車両別連絡先情報および、ドライバ別連絡先情報を含んでいる。

車両別動態情報は、車両毎の動態情報を含み、ステップ１０１の処理によって更新される。具体的には、センター制御部１３は、車載機３ａ〜３ｄのうちいずれか１つから車両ＩＤと共に動態情報を受信した場合、ステップ１０１において、受信した動態情報と車両ＩＤとを対応付けて車両別動態情報に記録する。その際、車両別動態情報中で既に同じ車両ＩＤに対応付けられて記録されている動態情報は削除する。したがって、車両別動態情報中には、車両ＩＤ毎に最新の動態情報が保存される。

車両別位置情報は、車両毎の所在位置の履歴を含み、ステップ１０１の処理によって更新される。具体的には、センター制御部１３は、車載機３ａ〜３ｄのうちいずれか１つから車両情報を受信した場合、ステップ１０１において、受信した車両情報に含まれる車両ＩＤと位置情報とを対応付けて、車両別位置情報に追加記録する。このようにすることで、車両別位置情報には、車両ＩＤ毎に過去および現在の所在位置の履歴が記録されることになる。

車両別ドライバ情報は、車両毎にどのドライバが使用しているかを示す情報であり、車両ＩＤとドライバＩＤとが対応付けられて記録されており、ステップ１０１の処理によって更新される。具体的には、センター制御部１３は、車載機３ａ〜３ｄのうちいずれか１つから車両情報を受信した場合、ステップ１０１において、受信した車両情報に含まれる車両ＩＤとドライバＩＤを対応付けて車両別ドライバ情報中に記録する。

その際、車両別ドライバ情報中の対応付けに矛盾が発生しないように、古い対応付け情報は削除する。具体的には、受信した車両情報に含まれる車両ＩＤが、車両別ドライバ情報中で他のドライバＩＤに対応付けられている場合、当該他のドライバＩＤとの対応付けの情報を削除する。また同様に、受信した車両情報に含まれるドライバＩＤが、車両別ドライバ情報中で他の車両ＩＤに対応付けられている場合、当該他の車両ＩＤとの対応付けの情報を削除する。

車両別連絡先情報は、車両毎の、当該車両に搭載された車載機の電話番号が記録されている。この車両別連絡先情報は、センターサーバ１の管理者があらかじめ記憶部１２の車両情報データベース１２に周知の方法で記録させておく。

ドライバ別連絡先情報は、ドライバ毎の、当該ドライバが有する携帯端末の電話番号および電子メールアドレス（例えばｅ−ｍａｉｌアドレス）が記録されていると共に、ドライバ毎の名前も含まれている。このドライバ別連絡先情報は、センターサーバ１の管理者があらかじめ記憶部１２の車両情報データベース１２に周知の方法で記録させておく。

また、センター制御部１３は、Ｗｅｂサービス処理１３ａを実行する。Ｗｅｂサービス処理１３ａの処理内容は以下の通りである。センター制御部１３は、Ｗｅｂブラウザ機能を有する他の通信端末（例えば、同じ運輸会社が保有する管理用コンピュータ）から、車両情報データベース１２ａの閲覧要求を受信すると、車両情報データベース１２ａの内容を当該通信端末に送信する。このようなＷｅｂサービス処理１３ａにより、他の通信端末により車両情報データベース１２ａを閲覧可能となる。このような機能により、車両状況通知システムは運行管理システムとしても機能する。

以上が、通常運行時の作動である。次に、車載機３ａが車両２ａの眠気を検知した場合について、図９〜図１５を参照して説明する。この場合は、通常運行時の作動に加え、以下の作動が実現される。

［第１の事例］
図９は、眠気が検知された第１の事例における状況通知システム全体の作動シーケンスを表している。まず、各車載機３ａ〜３ｄの車載制御部３８は、繰り返し（例えば定期的に１秒周期で）眠気検知部３７から入力された信号に基づいて、車両２ａのドライバの眠気レベルを算出する。眠気レベルの値は、０から１００まで例えば１刻みで算出され、完全に覚醒している場合が０で、完全に寝ている場合が１００で、完全に寝ている状態に近づくほど、値が大きくなる。そして車載制御部３８は、眠気レベルが所定の眠気閾値（例えば５０）を超えた場合にのみ、眠気発生を検知したと判定する。

図９のステップ５００においては、車載機３ａの車載制御部３８が、眠気発生を検知したと判定する。この場合、車載機３ａの車載制御部３８は、眠気発生を検知したと判定したことに基づいて、ステップ５１０で、眠気発生通知を行う。具体的には、通信部３１を用いて、図１０に示す眠気発生情報を、センターサーバ１に送信する。

図１０に示す通り、眠気発生情報は、搭載先車両の車両ＩＤ、搭載先車両を使用するドライバのドライバＩＤ、搭載先車両の位置情報、時刻情報、および眠気詳細情報を含んでいる。時刻情報は、現在時刻の情報である。眠気詳細情報には、眠気発生を検知したと判定した際に用いた眠気レベルが含まれている。

センターサーバ１のセンター制御部１３は、通信部１１を介してこの眠気発生情報を受信すると、眠気対応処理１３ｂを実行する。眠気対応処理においては、図１１に示すように、まずステップ１０５で、眠気ドライバ情報を作成する。

具体的には、まず、受信した眠気発生情報から、車両ＩＤおよびドライバＩＤを読み出す。そして、車両情報データベース１２中の車両別連絡先情報から、当該車両ＩＤに対応した車載機３ａの連絡先電話番号を読み出して眠気ドライバ情報に含める。また、車両情報データベース１２中のドライバ別連絡先情報から、当該ドライバＩＤに対応したドライバの名前を読み出して眠気ドライバ情報に含める。また、眠気ドライバ情報には、ドライバの眠気発生が検知されたことを示す情報も含める。

続いてステップ１１０では、車両情報データベース１２中の車両別動態情報に基づいて、運行中の他車両を特定する。ただし、図１１の処理を開始して以降に後述する眠気ドライバ情報の送信先となったことのある車載機を搭載する車両については、特定する対象から除外する。具体的な特定方法は以下の通りである。

車載制御部３８はまず、車両別動態情報に含まれる動態情報（図６参照）から抽出対象の動態情報を特定する。具体的には、受信した眠気発生情報に含まれる車両ＩＤに対応する動態情報は、抽出対象から除外する。また、図１１の処理を開始して以降に後述する眠気ドライバ情報の送信先となった車載機の車両ＩＤに対応する動態情報も、抽出対象から除外する。その結果残ったすべての動態情報を、抽出対象とする。

そして、抽出対象の動態情報の各々から、車両が運行しているか否かがわかる運行有無情報を抽出する。ここで、抽出する運行有無情報は、運行終了時刻と運行開始時刻の組である。そして、運行終了時刻が運行開始時刻よりも時間的に遅ければ、当該動態情報に対応する車両ＩＤの車両は運行中でないと判定する。これに対し、運行終了時刻が運行開始時刻よりも時間的に早い場合、当該動態情報に対応する車両ＩＤの車両は運行中であると判定する。また、運行終了時刻がデフォルト値または空の値であり、運行開始時刻がデフォルト値でも空の値でもない場合、当該動態情報に対応する車両ＩＤの車両は運行中であると判定する。また、運行開始時刻がデフォルト値または空の値である場合、当該動態情報に対応する車両ＩＤの車両は運行中でないと判定する。図９の事例では、運行有無情報に基づいて、車両２ｂ、２ｃ、２ｄのうち、車両２ｄは運行中でないと判定されると共に、車両２ｂ、２ｃが運行中であると判定される。

続いてステップ１１５では、ステップ１１０で特定された運行中の車両２ｂ、２ｃの通知優先度を割り当てる。通知優先度は、各車両の運行状態に基づいて設定する。運行状態と通知優先度との対応関係は、図１２に示す通りである。つまり、運行状態が「運転中」の通知優先度が最も高い３であり、運行状態が「荷積・荷卸中」の通知優先度が次に高い２であり、運行状態が「休憩・休息中」の通知優先度が最も低い１である。

「運転中」の通知優先度が最も高いのは、眠気ドライバ情報の通知に気づく可能性が最も高いからである。「荷積・荷卸中」の方が「休憩・休息中」よりも高い通知優先度が割り当てられているのは、荷積・荷卸といった作業をしているドライバの方が、休んでいるドライバよりも、眠気ドライバ情報の通知に気づく可能性が高いからである。

各車両２ｂ、２ｃの運行状態は、車両情報データベース１２中で車両２ｂ、２ｃの車両ＩＤに対応する動態情報に基づいて特定する。具体的には、各動態情報（図６参照）中の運行状態情報、すなわち、休憩・休息情報および荷積・荷卸情報に基づいて、運行状態を特定する。

より詳細には、休憩・休息情報と荷積・荷卸情報両方とも値が「なし」ならば、すなわち、ドライバが休みを取っておらず、荷積みも荷卸しもしていない状態であれば、運行状態が「運転中」であると判定する。また、荷積・荷卸情報が「荷積中」または「荷卸中」であれば、運行状態が「荷積・荷卸中」であると判定する。また、休憩・休息情報が「休息中」または「休憩中」であれば、運行状態が「休憩・休息中」であると判定する。図９の事例では、運転中の車両２ｂの通知優先度が３に設定される。また、ドライバが休憩中の車両２ｃの通知優先度が１（休憩中または休息中）に設定される。

続いてステップ１２０では、ステップ１１５で設定した通知優先度に基づいて、最も高い通知優先度が割り当てられた１台の車両を、通知先車両として選択する。図９の事例では、最も通知優先度の高い車両２ｂが、通知先車両として選択される。１度に１台のみを通知先車両として選択するのは、複数台を選んでも、結局のところ眠気車両２ａの車載機３ａと電話回線が繋がるのは１つなので、電話発信したのに通話中だったという事がないようにするためである。

続いてステップ１２５では、通知先車両２ｂの運行状態が、「休憩・休息中」または「荷積・荷卸中」であるかを判定する。図９の事例では、通知先車両２ｂの運行状態は「運転中」なので、「休憩・休息中」でも「荷積・荷卸中」でもないと判定し、ステップ１３５に進む。

ステップ１３５では、ステップ１０５で作成した眠気ドライバ情報を、ステップ１２０で選択した通知先車両に、通知部１１を用いて、送信する（図９のステップ５１５）。この眠気ドライバ情報は、既に説明した通り、眠気が検知された車両２ａのドライバの名前、車載機３ａの電話番号、および、当該ドライバの眠気が検知されたことを示す情報が含まれる。

ステップ１３５に続いては、ステップ１４０で連絡報告を眠気ドライバ情報の送信先から受信したか否かを判定する。受信していないと判定した場合は、ステップ１５０に進み、直前の眠気ドライバ情報の送信後所定のタイムアウト時間（例えば３分）が経過したか否か判定し、経過していなければステップ１４０に戻る。つまり、タイムアウト時間だけ、眠気ドライバ情報の送信先から連絡報告を待つ。

一方、車載機３ｂの車載制御部３８は、センターサーバ１から送信された眠気ドライバ情報を通信部３１を介して受信すると、図１３に示す処理を開始する。そしてステップ３１０では、受信した眠気ドライバ情報に基づく表示をディスプレイ３６に行わせる。図１４にその表示例を示す。

この例では、眠気ドライバ情報に含まれるドライバの名前と、連絡先電話番号（車載機３ａの電話番等）と、当該ドライバの眠気が検知された旨が表示される。また、図１４の表示例には、「ＴＥＬ」ボタンと「閉じる」ボタンが表示されている。車両２ｂのドライバは、運行中かつ運転中なのだから、ほとんどの場合、ステップ３１０の表示にすぐ気づく。

ステップ３１０に続いては、ステップ３１５で、操作部３５に対して「ＴＥＬ」ボタン選択の操作が行われた否かを判定し、行われていなければステップ３２０に進む。またステップ３２０では、操作部３５に対して「閉じる」ボタン選択の操作が行われた否かを判定し、行われていなければステップ３１５に戻る。つまり、「ＴＥＬ」ボタンか「閉じる」ボタンが選択されるまで待機する。車両２ｂのドライバは、車両２ａのドライバに電話をかける場合は、「ＴＥＬ」ボタンの選択操作を行い、何らかの理由で車両２ａのドライバに電話をかけないと決めた場合は、「閉じる」ボタンの選択操作を行う。

図９の事例では、車両２ｂのドライバが電話をかけると決め、操作部３５を用いて「ＴＥＬ」ボタンの選択操作を行う。すると車載制御部３８は、ステップ３２０で「ＴＥＬ」ボタン選択の操作が行われたと判定して、ステップ３２５に進む。

ステップ３２５では、通信部３１を用いて、眠気ドライバ情報に含まれる眠気発生車両２ａの連絡先電話番号（車載機３ａの電話番等）へ、電話発信を行う（図９のステップ５２５）。

すると、眠気発生車両２ａの車載機３ａに車載機３ｂからの電話着信が発生する（図９のステップ５３０）。車載機３ａの車載制御部３８は、通信部３１を介して電話着信があったことを検知すると、オフフックの処理を行って電話発信元との電話回線を繋ぐ。

この電話回線を通じて、車両２ｂのドライバの発話音声は、車載機３ｂのマイク３３で音声信号となって電話回線を伝わり、車載機３ａのスピーカ３４で音声として出力される。また逆に、車両２ａのドライバの発話音声は、車載機３ａのマイク３３で音声信号となって電話回線を伝わり、車載機３ｂのスピーカ３４で音声として出力される。したがって、眠気発生車両２ａのドライバと車両２ｂのドライバとが会話を行えるようになる。

この会話によって、車両２ｂのドライバは、眠気発生車両２ａのドライバに対し、車両２ａを停止させて休憩するよう指示してもよい。あるいは、眠気発生車両２ａのドライバを覚醒させるための会話を促してもよい。後者を行って両者で会話が行われた場合、眠気発生車両２ａのドライバの覚醒に良好に寄与する。人同士の会話は、単なる物理的刺激に比べ、脳の活性化をより強く促す作用があるからである。

なお、車載機３ｂの車載制御部３８では、ステップ３２５で電話発信を行った場合、電話回線が繋がるのを待たず、ステップ３３０に進む。そしてステップ３３０で、通信部３１を用いて、自機の搭載先車両２ｂのドライバのドライバＩＤを含む連絡報告を、センターサーバ１に送信し（図９のステップ５３５）、図１３の処理を終了する。なお、通信部３１は、センターサーバ１への送信と、他の車載機３ａとの電話回線接続を、同時に両立することができるような構成となっている。

センターサーバ１では、センター制御部１３が、ステップ１４０、１５０の繰り返しにおいて、通信部１１を介してこの連絡報告を受信すると、ステップ１４０で連絡報告ありと判定し、ステップ１４５に進む。そしてステップ１４５では、受信した連絡報告に含まれるドライバＩＤを、連絡者のドライバＩＤとして、記憶部１２に記録し（図９のステップ５４０）、図１１の眠気対応処理１３ｂを終了する。

このようにすることで、眠気発生車両に対していずれかの車両のドライバが電話連絡する度に、当該連絡者のドライバＩＤが、記憶部１２に蓄積されていく。このように蓄積されたドライバＩＤの履歴は、後に、運輸外車内の勤務評価に反映させることも可能である。

［第２の事例］
次に、本実施形態の作動の第２の事例について説明する。図１５は、眠気が検知された第２の事例における状況通知システム全体の作動シーケンスを表している。本事例は、車載機３ａの車載制御部３８が眠気発生を検知してから（ステップ５００）、最も通知優先度が高い車載機３ｂに対してセンターサーバ１が眠気ドライバ情報を送信するまで（ステップ５１５）の作動は、第１の事例と全く同じである。

本事例が第１の事例と違うのは、車載機３ｂの車載制御部３８がステップ３１０で図１４に示した表示をディスプレイ３６に行わせた後、何らかの希な理由で車両２ｂのドライバが電話をかけないと決めることである。車両２ｂのドライバは、この決定に続き、操作部３５を用いて「閉じる」ボタンの選択操作を行う。すると車載制御部３８は、ステップ３２０で「閉じる」ボタン選択の操作が行われたと判定して、ステップ３２５、３３０をバイパスして図１３の処理を終了する。

この場合は、連絡報告が車載機３ｂからセンターサーバ１に送信されないので、センター制御部１３が、眠気ドライバ情報を最後に送信してから、ステップ１４０、１５０の実行を繰り返している間に、タイムアウト時間が経過する（図１５のステップ５４５）。その時点でセンター制御部１３は、ステップ１５０にてタイムアウト時間が経過したと判定し、ステップ１１０に戻る。

ステップ１１０では、再度、既に説明した通りの方法で、運行中の他車両を特定する。ただし、図１５の事例においては、車両２ｂには既に眠気ドライバ情報を送信しているので、運行中の他車両として特定されるのは、車両２ｃのみである。また、図１５の事例では、車両２ｃのドライバは、まだ休憩中であり、車両別動態情報では、車両２ｃの車両ＩＤに対応した動態情報には変化がない。

なお、図１５の事例とは異なるが、前回ステップ１１０を実行した後かつ今回ステップ１１０を実行する前に、車両２ｄが運行を開始する場合もあり得る。その場合は、上述の通常運行の作動によって、車両２ｄの動態情報が車両情報データベース１２において変化するので、車両２ｄも運行中の他車両として特定される。

図１５の事例の説明に戻り、ステップ１１０に続くステップ１１５では、既に説明した通り、運行中の車両２ｃの通知優先度を割り当てるが、車両別動態情報に基づく車両２ｃの運行状態は依然として「休憩・休息中」なので、通知優先度が１（休憩中）に設定される。

続いてステップ１２０では、最も高い通知優先度が割り当てられた車両を、通知先車両として選択するが、図１５の事例では、車両２ｃだけにしか通知優先度が割り当てられていないので、車両２ｃが、通知先車両として選択される。

続いてステップ１２５では、通知先車両２ｃの運行状態が、「休憩・休息中」であると判定し、ステップ１３０に進む。

ステップ１３０では、ステップ１０５で作成した眠気ドライバ情報を、ステップ１２０で選択した通知先車両２ｃのドライバが有する携帯端末に送信する。通知先車両２ｃのドライバが有する携帯端末の連絡先は、以下のようにして特定する。

まず、車両情報データベース１２中の車両別ドライバ情報から、通知先車両２ｃの車両ＩＤに対応するドライバＩＤを読み出す。そして、車両情報データベース１２中のドライバ別連絡先情報から、当該ドライバＩＤに対応する電話番号および電子メールアドレスを抽出し、それら抽出したもののうちいずれか１つを、通知先車両２ｃのドライバが有する携帯端末の連絡先とする。例えば、電話番号と電子メールアドレスの両方の抽出に成功した場合は、電子メールアドレスを優先して連絡先とし、電話番号のみ抽出に成功した場合に限り、電話番号を連絡先としてもよい。

なお、電子メールアドレスを連絡先とする場合は、眠気ドライバ情報をテキストデータとして送信すればよい。そうすれば、車両２ｃのドライバは、休憩または休息中で車両２ｃの外にいても、自分が有する携帯端末を操作して着信した電子メールを読んで、眠気ドライバの名前および眠気車両２ａの車載機３ａの連絡先電話番号を知ることができる。

また、電話番号を連絡先とする場合は、当該電話番号を相手とする電話回線を接続し、眠気ドライバ情報を読み上げる音声信号を作成し、当該音声信号を当該電話回線を通じて送ればよい。そうすれば、車両２ｃのドライバは、休憩または休息中で車両２ｃの外にいても、自分が有する携帯端末への電話着信に対してオフフックを行い、電話回線を通じて眠気ドライバの名前および眠気車両２ａの車載機３ａの連絡先電話番号を聞くことができる。

図１５の事例では、この眠気ドライバ情報を知った車両２ｃのドライバは、眠気ドライバ情報中の車載機３ａの連絡先電話番号に電話をすることを決める。そして、電話すると決めたことをセンターサーバ１に知らせるために行動する。

具体的には、電子メールで眠気ドライバ情報を受信した場合は、この電子メールに対する返信として、返信電子メールを送信する（図１５のステップ５５５）。この返信電子メールが、連絡報告に相当する。なお、図１５の事例とは異なるが、車両２ｃのドライバが何らかの希な理由で電話しないと決めた場合は、返信電子メールを送信しない。つまり、連絡報告が送信されない。

また、電話回線を通じて眠気ドライバ情報を聞いた場合は、この電話回線を通じて、車載機３ａの連絡先電話番号に電話する旨を通知する。具体的には、所定の言葉（例えば、「電話します」）を発話することで、携帯端末に、当該言葉の音声信号をセンターサーバ１に送信させる（図１５のステップ５５５）。この場合は、当該言葉の音声信号が、連絡報告に該当する。あるいは、携帯端末の所定の数字ボタンを押下することで、携帯端末に、その数字ボタンに対応したトーン信号をセンターサーバ１に送信させる（図１５のステップ５５５）。この場合は、当該トーン信号が、連絡報告に該当する。なお、図１５の事例とは異なるが、車両２ｃのドライバが何らかの希な理由で電話しないと決めた場合は、蒸気所定の言葉を発することも上記数字ボタンを押下することもなく、電話回線を切断する。つまり、連絡報告が送信されない。

図１５の事例に戻る。上記のように連絡報告が送信された場合、センターサーバ１では、センター制御部１３が、ステップ１４０、１５０の繰り返しにおいて、通信部１１を介してこの連絡報告を受信する。そして、ステップ１４０で連絡報告ありと判定し、ステップ１４５に進む。そしてステップ１４５では、直前のステップ１３０で眠気ドライバ情報を送信した先のドライバのドライバＩＤを、連絡者のドライバＩＤとして、記憶部１２に記録し（図１５のステップ５６０）、図１１の眠気対応処理１３ｂを終了する。このようにすることで、図９の事例１同様に、当該連絡者のドライバＩＤが、記憶部１２に蓄積されていき、それが、事例１と同様の効果をもたらす。

その後、車両２ｃのドライバは、眠気ドライバ情報を受信した携帯端末を用いて、眠気ドライバ情報中の車載機３ａの連絡先電話番号に電話発信を行う（図１５のステップ５６５）。

すると、眠気発生車両２ａの車載機３ａに当該携帯端末からの電話着信が発生する（図１５のステップ５７０）。その後の、車載機３ｂと当該携帯端末との間の電話回線による、車両２ａのドライバと車両２ｃのドライバの会話およびその効果は、図９の第１の事例のステップ５３０以降と同じである。

このように、本実施形態の第１、第２の事例では、センターサーバ１が、車載機３ａから眠気発生情報を受信した場合、運行中の車両２ａ、２ｂのうち１つを通知先車両とし、通知先車両のドライバに、眠気ドライバ情報を通知する。運行中の車両２ｂ、２ｃのドライバは、業務遂行中なので、当該所定の状況の通知に対して何らかの対応ができる可能性が高い。したがって、運行管理者のみに頼る場合に比べて、より高い確率で当該眠気発生の状況に対応可能となる。

また、第２の事例のように、眠気発生車両２ａの車載機３ａに電話発信するドライバが見つかるまで、優先度の順に次々に複数のドライバに眠気ドライバ情報を通知するので、より高い確率で当該眠気発生の状況に対応可能となる。

また、眠気発生車両２ａと同じ運輸会社に所属する車両２ｂ、２ｃのドライバに眠気ドライバ情報を通知するので、運輸会社の従業員間の士気および結束力が高まるという効果もある。

（第２実施形態）
次に、本発明の第２実施形態について、図１６〜図１８を参照して説明する。本実施形態は第１実施形態と３つの点で異なる。１つ目の相違点は、図４のステップ３０１で車載機３ａ〜３ｄの車載制御部３８が送信する車両情報の内容である。２つ目の相違点は、図７のステップ１０１でセンター制御部１３が記録する情報および記録先の車両情報データベース１２の構成である。３つ目の相違点は、図１１のステップ１１５でセンターサーバ１のセンター制御部１３が行う通知優先度割り当ての内容である。これら以外については、第１実施形態と同じである。以下、上記３つの相違点について説明する。

まず、本実施形態の車載機３ａ〜３ｄの車載制御部３８は、ステップ３０１で、図１６に示す構成の車両情報を送信する。すなわち、車両情報は、搭載先車両の車両ＩＤ、搭載先車両を使用するドライバのドライバＩＤ、および搭載先車両の位置情報を含むのは、第１実施形態と同じだが、それらに加え、本実施形態では、眠気詳細情報も含む。この眠気詳細情報は、図９、図１５のステップ５１０で送信される眠気発生情報に含まれる眠気詳細情報と同じである。

このため、車載機３ａ〜３ｄの車載制御部３８は、図４のステップ３０１において、車両２ａのドライバの眠気レベルを、第１実施形態で説明したのと同じ方法で算出する。そして、算出した眠気レベルが第１実施形態で示した所定の眠気閾値（例えば５０）を超えている場合も、当該所定の閾値と同じ場合も、当該閾値を下回っている場合も、算出した眠気レベルを含む眠気詳細情報を、センターサーバ１に送信する。

一方、センターサーバ１では、センター制御部１３が、通信部１１を介してこの眠気詳細情報を含む車両情報を受信すると、図７のステップ１０１で、当該車両情報を、車両情報データベース１２に保存し、その後通常受信処理を終了する。

具体的には、当該車両情報中のドライバＩＤ、搭載先車両の位置情報の保存方法は、第１実施形態と同じである。しかし、当該車両情報中の眠気詳細情報については、図１７に示すように、車両情報データベース１２に、第１実施形態と同じ情報（図８参照）に加え、新たに車両別眠気レベル情報を設けておく。そして、受信した眠気詳細情報中に含まれる眠気レベルを、受信した車両情報に含まれる車両ＩＤと対応付けて、当該車両別眠気レベル情報に記録する。その際、車両別眠気レベル情報中で既に同じ車両ＩＤに対応付けられて記録されている眠気レベルは削除する。したがって、車両別眠気レベル情報中では、車両ＩＤ毎に、当該車両ＩＤに対応する車両のドライバの最新の眠気レベルが、車両情報受信の度に、更新される。

また、センター制御部１３は、図１１のステップ１１５において、ステップ１１０で特定された運行中の車両２ｂ、２ｃの通知優先度を、各車両の運行状態に基づいて割り当てるのは、第１実施形態と同じである。

しかし、本実施形態における運行状態と通知優先度との対応関係は、図１８に示すようなものになる。具体的には、第１実施形態の対応関係（図１２参照）に対して、運行状態が「運転中」の場合について、眠気レベルの値に応じて更に２つに場合分けするよう、変更している。

具体的には、運行状態が「運転中」であり、かつ、運行状態が「運転中」となっている車両のうちで眠気レベルが最大となっている車両に対しては、通知優先度が最も高い４とする。そして、運行状態が「運転中」であり、かつ、運行状態が「運転中」となっている車両のうちで眠気レベルが最大となっていない車両に対しては、通知優先度を２番目に高い３とする。また、第１実施形態と同様、運行状態が「荷積・荷卸中」の通知優先度は次に高い２とし、運行状態が「休憩・休息中」の通知優先度は最も低い１とする。

例えば、本実施形態では、各車両２ｂ、２ｃの運行状態が共に「運転中」であると判定され、かつ、車両別眠気レベル情報によれば、各車両２ｂおよび２ｃの眠気レベルが、それぞれ所定の眠気レベル閾値より小さい４５および５だったとする。この場合は、車両２ｂの通知優先度が４になり、車両２ｃの通知優先度が３になる。

このようになっていると、第１実施形態の第１事例のように、最初に、センターサーバ１から車両２ｂの車載機３ｂに、眠気ドライバ情報が送信される（図９のステップ５１５）。そして、この第１事例のように、車載機３ｂから車載機３ａに電話発信されると（ステップ５２５）、車載機３ｂと車載機３ａとの電話回線が繋がる（図９のステップ５３０）。

そして、この電話回線を通じて、眠気が検知された車両２ａのドライバと、眠気が検知されないまでも眠気レベルが比較的高い車両２ｂのドライバとの会話が実現する。したがって、眠気醒ましの効果が、眠気が検知された車両２ａのドライバのみならず、電話発信側の車両２ｂのドライバにまで及び、一石二鳥となる。このように、運行中の車両のドライバのうちでも、眠気レベルが高いドライバにより高い通知優先度を割り当てることで、眠気醒ましの効率が上がる。

（第３実施形態）
次に、本発明の第３実施形態について、図１９を参照して説明する。本実施形態の車両状況通知システムにおける、センターサーバ１および車載機３ａ〜３ｄの構成は、第１、第２実施形態と同じであり、図１〜図３に示した通りである。

以下、本実施形態の車両状況通知システムの作動について説明する。通常運行時の作動は、第１、第２実施形態と同じである。しかし、車載機３ａが車両２ａの眠気発生を検知した場合は、第１、第２実施形態と異なり、以下のようになっている。

まず、各車載機３ａ〜３ｄの車載制御部３８が繰り返し眠気レベルを算出する処理の詳細は、第１、第２実施形態と同じである。図１９のステップ６００においては、車載機３ａの車載制御部３８が、眠気発生を検知したと判定し、ステップ６１０で、第１実施形態のステップ５１０と同じ方法で、眠気発生情報をセンターサーバ１に送信する。

センターサーバ１のセンター制御部１３は、通信部１１を介してこの眠気発生情報を受信すると、眠気対応処理１３ｂを実行するが、眠気対象処理１３ｂの内容が、第１実施形態とは異なっている。

具体的には、まず、図１１のステップ１０５と同じ方法で、眠気ドライバ情報を作成する。続いて、図１１のステップ１１０と同じ方法で、車両情報データベース１２中の車両別動態情報に基づいて、運行中の他車両を特定する。本実施形態でも、車両情報データベース１２中の車両別動態情報によれば、車両２ａ以外では、車両２ｂ、２ｃのみが運行中であったとする。

その後センター制御部１３は、ステップ６１５で、第１実施形態とは異なり、特定した運行中の他車両２ｂ、２ｃの車載機３ｂ、３ｃのすべてに、上記の眠気ドライバ情報を送信する。続いてステップ６２０で、グループ通話サービス７００の処理を開始する。

グループ通話サービス７００は、当該サービスに参加する複数の車載機を通じて、それら複数の車載機のユーザ（ドライバ）が複同時に会話を行える（グループ通話を行える）ようにするサービスである。ここで、複数の車載機が３台以上であってもよい点が特徴である。

グループ通話サービス７００においてセンター制御部１３が行う主な処理は、以下の通りである。まず、車載機から、車両ＩＤを含む参加申請を受信した場合、当該車両ＩＤを、センター制御部１３のＲＡＭ中のクライアントリストに登録する。そして、クライアントリストに複数（３台以上でもよい）の車両ＩＤが登録されているとき、クライアントリスト中の１つの車両ＩＤに対応する車載機から音声データを受信したとする。その場合、受信した音声データを、クライアントリスト中の、当該１つの車両ＩＤ以外のすべての車両ＩＤ（２台以上でもよい）の車載機に、送信する。

また、眠気発生車両２ａの車載機３ａでは、車載制御部３８が、ステップ６１０で眠気発生通知を送信した後、ステップ６２５に進み、グループ通話サービス７００に参加するための処理を行う。具体的には、通信部３１を用いて、搭載先車両２ａの車両ＩＤを含む参加申請を、センターサーバ１に送信する。これにより、センター制御部１３は、眠気発生車両２ａの車両ＩＤをクライアントリストに登録する。

また、眠気ドライバ情報を受信した車載機３ｂ、３ｃでは、車載制御部３８は、図１３のステップ３１０と同じ処理で、受信した眠気ドライバ情報に基づく表示をディスプレイ３６に行わせる。そして、ステップ３１５、３２０と同じ処理で、「ＴＥＬ」ボタンか「閉じる」ボタンが選択されるまで待機する。また、待機中に閉じるボタンが選択された場合、図１３と同様に、眠気ドライバ情報受信時の処理を終了する。

本事例では、上記待機中に、車両２ｂ、２ｃのドライバのいずれもが、「ＴＥＬ」ボタンを選択したとする。すると、センター制御部１３は、第１実施形態とは異なり、グループ通話サービス７００に参加するための処理を行う。具体的には、通信部３１を用いて、搭載先車両２ｂ、２ｃの車両ＩＤを含む参加申請を、センターサーバ１に送信する（ステップ６３０、６３５）。これにより、センター制御部１３は、車両２ｂ、２ｃの車両ＩＤをクライアントリストに登録する。

その後は、グループ通話サービス７００により、センターサーバ１をサーバとして、車載機３ａ、３ｂ、３ｃを介して、車両２ａ、２ｂ、２ｃの３者のドライバにより、同時会話が実現する。このようにすることで、会話がより賑やかになり、眠気発生車両２ａのドライバの覚醒がより促進される。

また、車載機３ａの車載制御部は、参加申請を送信した後、眠気発生車両２ａのドライバの眠気レベルが上記所定の眠気閾値を下回ったか否かを、繰り返し判定する。そして、当該眠気レベルが上記所定の眠気閾値を下回ったと判定した場合、すなわち、居眠り検知が解消したと判定し（ステップ６４０）、その判定に基づき、通信部３１を用いて、眠気解消通知をセンターサーバ１に送信する（ステップ６４５）。

センターサーバ１では、この眠気解消通知を受信すると、車載機３ａ、３ｂ、３ｃの操作部３５に対して特別な終了操作が行われるのを待たずに、強制的にグループ通話サービス７００を終了する（ステップ６５０）。以後は、グループ通話ができなくなる。このように、ドライバの眠気が解消した段階で、グループ通話サービス７００を打ち切ることで、ドライバが必要もないのにグループ通話をだらだらと継続してしまうことがなくなる。

（他の実施形態）
なお、本発明は上記した実施形態に限定されるものではなく、特許請求の範囲に記載した範囲内において適宜変更が可能である。また、上記各実施形態は、互いに無関係なものではなく、組み合わせが明らかに不可な場合を除き、適宜組み合わせが可能である。また、上記各実施形態において、実施形態を構成する要素は、特に必須であると明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、上記各実施形態において、実施形態の構成要素の個数、数値、量、範囲等の数値が言及されている場合、特に必須であると明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではない。また、上記各実施形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に特定の形状、位置関係等に限定される場合等を除き、その形状、位置関係等に限定されるものではない。例えば、以下のような変形例も許容される。なお、以下の変形例は、任意の組み合わせで、上記実施形態に適用できる。

（変形例１）
上記第１〜第３実施形態では、車載機３ａ〜３ｄの車載制御部３８は、眠気レベルと眠気閾値を比較し、眠気レベルが眠気閾値を超えた場合にセンターサーバ１に眠気発生情報を送信するようになっている。しかし、必ずしもこのようになっていなくてもよい。

具体的には、車載機３ａ〜３ｄの車載制御部３８は、眠気レベルを繰り返し算出し、算出する度に、眠気閾値と比較することなく、その眠気レベルを眠気詳細情報に含む眠気発生情報を送信するようになっていてもよい。その場合、センターサーバ１のセンター制御部１３が、受信した眠気発生情報中の眠気レベルと眠気閾値を比較する。そして比較の結果、眠気レベルが眠気閾値を超えた場合にのみ、第１、第２実施形態では図１１に示す眠気対応処理を実行し、第３実施形態では図１９のステップ６１５以降を実行する。

なお、このような場合、車載制御部３８は、眠気レベルと眠気閾値の比較を行わないが、それであっても、当該眠気閾値を超えた最初の眠気レベルを算出することは、ドライバの眠気発生を検知することに該当する。また、同様に、当該眠気閾値を超えた最初の眠気レベルを含む眠気発生情報は、ドライバの眠気発生を検知したことを示す眠気発生情報に該当する。

（変形例２）
第３実施形態では、センター制御部１３は、眠気ドライバ情報を受信した場合、車両情報データベース１２中で運行中となっているすべての車両の車載機に眠気ドライバ情報を送信するようになっている。しかし、必ずしもこのようになっていなくてもよい。例えば、センター制御部１３は、眠気ドライバ情報を受信した場合、図１１のステップ１１５と同様に運行中の各車両について通知優先度を割り当ててもよい。そして、運行中となっており、かつ、通知優先度が所定基準値（例えば２）以上の車両のドライバに対してのみ、眠気ドライバ情報を送信するようになっていてもよい。

（変形例３）
また、上記第３実施形態において、眠気発生車両２ａの車載機３ａを除き、グループ通話サービス７００に参加する車載機３ｂ、３ｃでは、車載制御部３８が、グループ通話サービス７００に参加することを示す連絡報告を、センターサーバ１に送信してもよい。この連絡報告の内容は、第１、第２実施形態と同じである。この連絡報告を受信したセンターサーバ１は、第１、第２実施形態と同様に、受信した連絡報告に含まれるドライバＩＤを、連絡者のドライバＩＤとして、記憶部１２に記録する。

（変形例４）
上記各実施形態では、車載機３ａが車両２ａのドライバの眠気発生を検知した場合について説明した。この場合は、車両２ａが第１の車両の一例となり、車載機３ａが第１の車載機の一例となる。しかし、他の車載機３ｂ、３ｃ、３ｄが車両２ｂ、２ｃ、２ｄのドライバの眠気発生を検知した場合も、車載機３ａ〜３ｄ間の役割が変わるだけであり、上記各実施形態と同等の効果を得ることができる。この場合は、車両２ｂまたは２ｃが第１の車両の一例となり、車載機３ｂまたは３ｃが第１の車載機の一例となる。

（変形例５）
また、センターサーバ１のセンター制御部１３は、眠気ドライバ情報を受信した後は、Ｗｅｂサービス処理１３ａにおいて、受信した閲覧要求の送信元の通信端末に、眠気ドライバ情報を送信するようになっていてもよい。

（変形例６）
上記第１〜第３実施形態では、車載機３ａが車両２ａについて、「ドライバの眠気発生」という所定の状況を検知したことに基づいて、眠気発生情報をセンターサーバ１に通知するようになっている。この眠気発生情報は、当該所定の状況を検知したことを示す状況発生情報の一例に相当する。

しかし、所定の状況は、必ずしもドライバの眠気発生に限られるものでもなく、車両２ａに発生する状況としてあらかじめ定められたものであればどのようなものでもよい。例えば、所定の状況は、車両２ａにおける事故発生でもよいし、車両２ａにおける故障発生でもよい。この場合も、上記第１〜第３実施形態における眠気を事故または故障に読み替えた作動が実現する。なお、その場合、眠気レベルを読み替えた事故レベルまたは故障レベルの検知方法は、周知である。

また、第１、第２実施形態において眠気を事故または故障に読み替える場合は、図１２に示した運行状態と通知優先度の関係を、実車か空車かに応じて変更させてもよい。つまり、センター制御部１３は、図１のステップ１１５で運行中の車両２ｂ、２ｃの通知優先度を割り当てる際に、図１２のように通知優先度を決定した後、更に通知優先度を修正する。具体的には、各車両２ｂ、２ｃについて、当該車両の車両ＩＤに対応する動態情報に含まれる実車・空車情報が「実車」ならば通知優先度を変更せず、「空車」ならば通知優先度を所定量（例えば３）だけ増加させる。このようにすることで、事故または故障が発生した車両の存在を通知する先の車載機として、空車の車両に搭載された車載機がより優先されるようになる。

またこの場合、センター制御部１３は、ステップ１３０、１３５で、送信される事故ドライバ情報または故障ドライバ情報に、当該事故または故障が発生した車両の現在位置を含めるようにしてもよい。このようにすれば、事故または故障が発生した車両の場所へ、空車の他車両が急行し、事故または故障が発生した車両の積荷を、当該他車両に載せることができる。またこの場合、車載機３ａからセンターサーバ１に送信される動態情報中の実車・空車情報は、運行状態情報の１つとなる。

１ センターサーバ
２ａ〜２ｄ 車両
３ａ〜３ｄ 車載機
１２ 車両情報データベース

Claims (8)

1. 複数の車両（２ａ〜２ｄ）にそれぞれ搭載される複数の車載機（３ａ〜３ｄ）と、
   前記複数の車載機の各々から、当該車載機の搭載先の車両が運行しているか否かがわかる運行有無情報を受信し、受信した前記複数の車両毎の運行有無情報を車両情報データベース（１２）に保存するセンターサーバ（１）と、を備え、
   前記複数の車載機のうち第１の車載機（３ａ）は、前記第１の車載機の搭載先である第１の車両（２ａ）の所定の状況を検知したことに基づいて、前記所定の状況を検知したことを示す状況発生情報を前記センターサーバに通知し、
   前記センターサーバは、前記第１の車載機から前記状況発生情報を受信した場合、前記車両情報データベース中に保存された運行有無情報に基づいて、前記複数の車両のうち運行中の車両を通知先車両とし、前記通知先車両のドライバに、前記第１の車両の前記所定の状況を通知することを特徴とする車両状況通知システム。
2. 前記センターサーバは、前記複数の車載機の各々から、当該車載機の搭載先の車両が運行している場合の運行の状態を示す運行状態情報を受信し、受信した前記複数の車両毎の運行状態情報を前記車両情報データベースに保存し、
   更に前記センターサーバは、前記第１の車載機から前記状況発生情報を受信した場合、前記車両情報データベース中に保存された運行有無情報に基づいて、前記複数の車両のうち運行中の車両を特定し、特定した車両が複数ある場合、前記車両情報データベース中に保存された運行状態情報に基づいて、運行中の複数の車両のうちから１つを通知先車両として選び、選んだ通知先車両のドライバに、前記第１の車両の前記所定の状況を通知することを特徴とする請求項１に記載の車両状況通知システム。
3. 前記センターサーバが、前記複数の車載機の各々から受信して前記車両情報データベースに保存する運行状態情報には、前記複数の車載機の各々の搭載先の車両のドライバが運行の途中で休んでいるか否かを示す情報を含み、
   前記センターサーバは、前記第１の車載機から前記状況発生情報を受信した場合、前記車両情報データベース中に保存された運行有無情報に基づいて、前記複数の車両のうち運行中の車両を特定し、特定した車両が複数ある場合、前記車両情報データベース中に保存された情報のうち、運行中の各車両のドライバが運行の途中で休んでいるか否かを示す情報に基づいて、運行の途中で休んでいないドライバの車両を前記通知先車両として優先的に選ぶことを特徴とする請求項２に記載の車両状況通知システム。
4. 前記センターサーバが、前記複数の車載機の各々から受信して前記車両情報データベースに保存する運行状態情報には、前記複数の車載機の各々の搭載先の車両のドライバが運行の途中で荷積みまたは荷卸し中であるか否かを示す情報を含み、
   前記センターサーバは、前記第１の車載機から前記状況発生情報を受信した場合、前記車両情報データベース中に保存された運行有無情報に基づいて、前記複数の車両のうち運行中の車両を特定し、特定した車両が複数ある場合、前記車両情報データベース中に保存された情報のうち、運行中の各車両のドライバが荷積みまたは荷卸し中であるか否かを示す情報に基づいて、荷積み中でも荷卸し中でもないドライバの車両を前記通知先車両として優先的に選ぶことを特徴とする請求項２または３に記載の車両状況通知システム。
5. 前記センターサーバ（１）は、前記複数の車載機の各々から、当該車載機の搭載先の車両が運行しているか否かがわかる運行有無情報と、当該車載機の搭載先の車両のドライバの眠気レベルの情報とを受信し、受信した前記複数の車両毎の運行有無情報と眠気レベルを車両情報データベース（１２）に保存し、
   前記センターサーバは、前記第１の車載機から前記状況発生情報を受信した場合、前記車両情報データベース中に保存された運行有無情報に基づいて、前記複数の車両のうち運行中の車両を特定し、特定した車両が複数ある場合、前記車両情報データベース中に保存された情報のうち、運行中の各車両のドライバの眠気レベルの情報に基づいて、眠気レベルの高いドライバの車両を前記通知先車両として優先的に選ぶことを特徴とする請求項２ないし４のいずれか１つに記載の車両状況通知システム。
6. 前記センターサーバは、前記複数の車載機の各々から、当該車載機の搭載先の車両のドライバが運行の途中で休んでいるか否かを示す情報を受信して前記車両情報データベースに保存し、
   前記センターサーバは、車両情報データベースに基づいて、前記通知先車両のドライバが運行の途中で休んでいるか否かを判定し、休んでいない場合、前記通知先車両に搭載された車載機に前記第１の車両の前記所定の状況を送信し、休んでいる場合、前記通知先車両のドライバが有する携帯端末に車両の前記所定の状況を送信することを特徴とする請求項１ないし５のいずれか１つに記載の車両状況通知システム。
7. 前記センターサーバは、前記複数の車載機の各々から、当該車載機の搭載先の車両のドライバが運行の途中で荷積み中または荷卸し中であるか否かを示す情報を受信して前記車両情報データベースに保存し、
   前記センターサーバは、車両情報データベースに基づいて、前記通知先車両のドライバが運行の途中で荷積み中または荷卸し中であるか否かを判定し、荷積み中でも荷卸し中でもない場合、前記通知先車両に搭載された車載機に前記第１の車両の前記所定の状況を送信し、荷積み中または荷卸し中である場合、前記通知先車両のドライバが有する携帯端末に車両の前記所定の状況を送信することを特徴とする請求項１ないし６のいずれか１つに記載の車両状況通知システム。
8. 前記センターサーバは、前記第１の車載機から前記状況発生情報を受信した場合、前記車両情報データベース中に保存された運行有無情報に基づいて、前記複数の車両のうち運行中の複数の車両を通知先車両とし、前記複数の通知先車両のドライバに、前記第１の車両の前記所定の状況を通知することで、前記複数の通知先車両のドライバと前記第１の車両のドライバとで同時に会話を行わせることを特徴とする請求項１に記載の車両状況通知システム。

Images