(57)【特許請求の範囲】
【請求項１】
バスの運行に関連したアプリケーションプログラムをオペレーティングシステム上で実行する車載用運行支援装置において、
前記アプリケーションプログラムを前記オペレーティングシステム上で実行する制御手段と、
予め設定された所定時刻になったか否かの検出を行うタイマー手段と、
前記アプリケーションプログラムおよび前記アプリケーションプログラムにおいて利用されるバスの運行に必要なデータが記録される記録手段と、
前記記録手段に記録される前記アプリケーションプログラムや前記記録手段に記録される前記バスの運行に必要なデータを、更新するための更新データを、記録することが可能なバス管理サーバとのデータ交信を行う通信手段と
を有し、
前記オペレーティングシステムは、前記アプリケーションプログラムが前記制御手段において実行されていない場合に、システムをスリープ状態にする機能を有し、
前記制御手段は、
前記タイマー手段の検出結果に基づいて前記所定時刻になったか否かを判断し、
前記所定時刻になったと判断した場合に、前記システムが前記スリープ状態であるか否かを検出し
前記システムが前記スリープ状態である場合に、前記通信手段を用いて前記バス管理サーバとデータ交信を行って前記更新データを取得し、取得した当該更新データに基づいて前記記録手段に記録されるデータを更新すること
を特徴とする車載用運行支援装置。
【請求項２】
前記制御手段は、
前記記録手段に記録された前記更新データに、バスの運行時間を示すダイヤ情報が含まれるか否かを判断し、
該ダイヤ情報が含まれると判断した場合には、現在の時刻が当該ダイヤ情報に示される運行時間内に含まれるか否かを判断し、
当該運行時間に含まれる場合には、前記記録手段に記録されているデータを、前記更新データに更新する処理を行わないこと
を特徴とする請求項１に記載の車載用運行支援装置。
【請求項３】
前記制御手段は、前記更新データを取得する場合において、前記バス管理サーバとのデータ交信によって、前記バス管理サーバに、前記記録手段に記録される前記アプリケーションプログラムよりも新しいアプリケーションプログラムか、前記記録手段に記録される前記バスの運行に必要なデータよりも新しいバスの運行に必要なデータかの、いずれかのデータが記録されているかを判断し、いずれかのデータが記録されている場合に、前記バス管理サーバより該当するデータを受信し、前記記録手段に記録される前記アプリケーションプログラムあるいは前記バスの運行に必要なデータを、受信されたデータに更新すること
を特徴とする請求項１又は請求項２に記載の車載用運行支援装置。
【請求項４】
前記制御手段は、取得した前記更新データに基づいて前記記録手段に記録されるデータを更新する場合において、取得した前記更新データが前記オペレーティングシステムの再起動を必要とするデータであるか否かを判断し、前記オペレーティングシステムの再起動を必要とするデータである場合には、当該更新データに基づいて前記記録手段に記録されるデータを更新した後に、前記オペレーティングシステムを再起動させること
を特徴とする請求項１乃至請求項３のいずれか１項に記載の車載用運行支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バスの運行に関連したアプリケーションを実行するシステムを備えた車載用運行支援装置に関する。
【背景技術】
【０００２】
路線バス等の交通手段において、近年では、利用者がバスの到着時刻の遅れや次に到着するバスの到着予定時刻等を携帯端末等で確認することが可能となっている。このようなバスロケーションサービスを実現するために、各バスには、GPSアンテナを用いて自車両の位置を検出する位置検出処理や、バスの運行状況を管理するバス管理サーバに対して検出された車両位置を送信する送信処理等を行うための車載用運行支援装置が設置されている。さらに車載用運行支援装置は、バスの運行に必要とされる音声案内を車内に放送する音声出力処理や、バス停名称を車内表示板に表示する表示処理等も行っている。
【０００３】
このように、バス運行処理に必要とされるシステムが複雑かつ膨大なものとなってきているため、今日では、車載用運行支援装置のシステム構築において車載用のオペレーティングシステム（ＯＳ）を採用し、バスの運行に関連したアプリケーションをオペレーティングシステム上で実行することによって、システム更新の柔軟性とシステムの拡張性との向上を図っている。
【０００４】
このようなシステム構成を採用してアプリケーションの改良やデータの更新を行うことにより、バス運行のサービス向上に対応するシステムを容易に実現することができるが、一方でシステムの複雑化に伴って、頻繁なアプリケーションのバーションアップや、運行データの更新処理が必要とされるようになっていた。
【０００５】
このようなシステムのデータ更新処理を、人手を用いて車載用運行支援装置毎に個別に行う場合には、多数の人材が必要とされると共に、更新処理にある程度の時間が必要とされるため、バス会社におけるデータ更新処理の処理負担が増大してしまうという問題が発生していた。このよう問題を解決するために、例えば、無線通信技術を用いて車載用運行支援装置がバス管理サーバ等より更新データを取得し、自動的にデータの更新を行うシステムが提案されている（例えば、特許文献１参照）。
【特許文献１】特開２００４−３４８５４５号公報（第１０−１１頁、第２図）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、システムのデータ更新をバスの営業時間中に行ってしまった場合には、データ更新前の情報とデータ更新後の情報とに不具合が生じてしまい、システムが正常に作動しないおそれがあった。
【０００７】
また、アプリケーションの更新やオペレーションシステムに用いるドライバの更新等を行う場合、更新内容をシステムに反映させるために、車載用運行支援装置を再起動させる必要があり、営業時間中にシステムの再起動を行わせることはバス運営の混乱を避けるためにも回避する必要があった。
【０００８】
さらに、バスの営業時間は、そのバス毎に異なっており、日中だけ運行が行われる近距離路線バスの他、夜間に運行が行われる夜間路線バスも存在するため、バス会社において一律にデータの更新時間を決定することが困難であった。
【０００９】
本発明は、上記問題に鑑みてなされたものであり、バスの運営状況を判断した上で、バスの運行に支障が生じないようにデータの更新を行うことが可能な車載用運行支援装置を提供することを課題とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明に係る車載用運行支援装置は、バスの運行に関連したアプリケーションを実行するためシステムを備えた車載用運行支援装置であり、所定時間に前記システムを起動させるシステム起動手段と、前記バスの運行に必要な更新データが存在するか否かを判断する更新情報判断手段と、前記更新情報判断手段により前記更新データが存在すると判断された場合に、前記更新データを取得する更新データ取得手段と、前記バスのダイヤ情報に基づいて前記バスの営業状態を判断する状態判断手段と、前記状態判断手段に基づいて、前記バスが営業状態にないと判断した場合に、前記更新データの更新処理を行うデータ更新手段とを備えることを特徴とする。
【００１１】
また、前記データ更新手段は、前記状態判断手段により前記バスが営業状態にあると判断した場合に、前記更新データの更新処理を行わず、前記システム起動手段により起動されるシステムの起動時間の変更を行うものであってもよい。
【００１２】
さらに、前記状態判断手段は、前記更新データ取得手段により取得された更新データにダイヤ情報が含まれている場合には、当該ダイヤ情報に基づいて前記バスの営業状態を判断するものであってもよい。
【００１３】
また、前記システムの再起動を行うシステム再起動手段を備え、該システム再起動手段は、前記更新データ取得手段により取得された更新データにシステムの再起動を必要とする更新データが存在するかを判断し、再起動を必要とする更新データが存在すると判断するとともに、前記データ更新手段により当該更新データの更新処理が行われた場合に、前記システムの再起動処理を実行するものであってもよい。
【００１４】
さらに、前記更新データを記録したバス管理サーバとのデータ交信を行う通信手段を備え、前記更新情報判断手段が、前記通信手段を介して前記バス管理サーバにアクセスすることによって、更新処理を行う必要のある前記更新データが当該バス管理サーバに存在するか否かを判断し、前記更新データ取得手段が、前記更新情報判断手段によって前記更新データが前記バス管理サーバに存在すると判断された場合に、当該更新データを前記通信手段を介して前記バス管理サーバより取得するものであってもよい。
【発明の効果】
【００１５】
本発明に係る車載用運行支援装置によれば、更新情報判断手段が、バスの運行に必要な更新データが存在するか否かを判断し、更新データ取得手段が前記更新データを取得してデータ更新手段がデータの更新処理を行うので、人手に頼ることなくデータの更新処理を自動で行うことができ、バス会社のデータ更新負担を低減させることができる。
【００１６】
特に、状態判断手段がバスのダイヤ情報に基づいてバスの営業状態を判断し、バスが営業状態にないと判断した場合に、データ更新手段がデータの更新処理を行うので、バスの運行支援システムのように、営業時間中にデータ更新を行うことによってトラブル等が発生するおそれがあるシステムにおいても、バスの営業が行われていない時間に、データの更新作業を自動的に行うことができ、データの更新作業に伴うトラブルの発生を低減させることができる。
【００１７】
また、状態判断手段によりバスが営業状態にあると判断された場合には、更新データの更新処理を行わずに、システム起動手段により起動されるシステムの起動時間の変更を行うので、データ更新作業を行うことができない場合であっても、再度システムを起動させることによってデータの更新処理を行うことができる。
【００１８】
さらに、更新データ取得手段により取得された更新データにダイヤ情報が含まれている場合には、当該ダイヤ情報に基づいてバスの営業状態を判断するので、最新のダイヤ情報に基づいてバスの営業状態を判断することができる。
【００１９】
また、更新データにシステムの再起動を必要とする更新データが存在するか否かを判断し、再起動を必要とする更新データが存在すると判断するとともにデータ更新手段により更新データの更新処理が行われた場合、つまり、データの更新処理を行うことができるとダイヤ情報に基づいて判断できた場合にシステムの再起動処理を実行するので、データの更新処理および再起動処理の最中に営業が開始してしまってシステムにトラブルが生じてしまうことを回避することができる。
【００２０】
また、定期的にシステムの再起動行うことによって、アプリケーションの実行に伴うメモリの断片化や不十分なメモリの解放などに起因する処理速度の低下やシステムの不安定化を改善することが可能となる。
【００２１】
さらに、通信手段を用いてバス運行システムと交信を行うことにより、更新データの有無判断、更新データの取得処理を行うので、データ更新処理における処理負担の軽減を図ることが可能となる。特に、通信部による通信が無線通信技術を用いたものである場合には、各バスの車載用運行支援装置にデータ交信用の有線ケーブル等を接続することなくデータ更新処理を行うことができるので、データ更新処理における処理負担のより一層の軽減を図ることが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明に係る車載用運行支援装置を、図面を用いて詳細に説明する。
【００２３】
図１は、本発明に係る車載用運行支援装置１と、車載用運行支援装置１を備えたバスの運行管理を行うバス管理サーバ３とにより構成されるバス運行システム２の概略構成を示したブロック図である。
【００２４】
車載用運行支援装置１は、各バスにそれぞれ１台ずつ設置されており、車載用運行支援装置１には、制御部１０と、通信部１１と、記録部１２とが備えられている。
【００２５】
制御部１０は、図示を省略するＣＰＵやメモリ等により構成されており、バスの運行に適したオペレーションシステムに基づいて、各種アプリケーションの処理を実行する。例えば、制御部１０は、バス会社毎にカスタマイズされた広告用の音声データやバス停名称の音声データ等を車内放送するためのアプリケーションや、次のバス停名称や目的地別の運賃等を車内表示板に表示させるためのアプリケーション等を実行する。
【００２６】
また、制御部１０は、バス管理サーバ３と通信を行うことによって、バスの運行に必要なデータの更新情報、アプリケーションのバージョンアップ情報、車載用運行支援装置１のハード（通信部１１等）をシステムで制御するために必要なドライバの更新情報を取得し、この更新情報等に基づいてデータ更新処理が必要か否かの判断を行う。
【００２７】
ここで、バスの運行に必要なデータには、バス毎の運行時刻を示すダイヤ情報が含まれている。各バスは、バス毎に予め運行スケジュールが決められている。車載用運行支援装置１は、バスの運行スケジュールを示すバス毎のダイヤ情報を、バス管理サーバより毎日取得し、このダイヤ情報に基づいて、適切な音声案内や表示案内等のアプリケーション処理を実行する。
【００２８】
また、制御部１０にはタイマー１３が内蔵されており、指定された時間にスリープ状態から起動（レジューム）して各種処理を実行することが可能となっている。なお、制御部１０は、バス支援処理に迅速に対応できるように、基本的には常に電源がＯＮされた状態が保たれており、必要に応じてシステムをスリープおよび起動（レジューム）させることが可能となっている。さらに、制御部１０は、車載用運行支援装置１のシステムを一度終了して、再度一から起動し直す処理（再起動処理）を行うことが可能となっている。
【００２９】
通信部１１は、例えば、携帯電話や無線LAN等の無線通信技術を用いてバス管理サーバ３との通信を行う機能を備えている。通信部１１は、制御部１０の指示に基づいて、バス管理サーバ３と情報の交信を行う。
【００３０】
記録部１２は、ハードディスクあるいは大容量メモリ等であって、バス運行に必要な情報やアプリケーションプログラム等が記録されている。制御部１０は、通信部１１を介して取得した情報を記録部１２に記録するとともに、記録部１２に記録される各種情報を用いてバス運行の支援処理を行う。
【００３１】
バス管理サーバ３は、バス会社の営業所等に設置されており、少なくとも営業が終了して車庫等にバスが停車された状態において、各バスの車載用運行支援装置１と交信を行うことが可能な位置に設置される。バス管理サーバ３には、記録装置３１が備えられており、各車載用運行支援装置１に適した更新データやダイヤ情報データ等が記録されている。
【００３２】
次に、車載用運行支援装置１によるデータの更新処理について説明する。図２は、車載用運行支援装置１の制御部１０がデータ更新を行うための処理を示したフローチャートである。
【００３３】
まず、制御部１０は、現在の時間が、データの更新作業を行うのに適した時間として予め設定された時間（所定時間）になったか否かを、タイマー１３によって判断する（ステップＳ．１）。まだ、所定時間になっていない場合（ステップＳ．１でＮｏの場合）、制御部１０は、タイマー１３によって設定された時間になるまで、同様の処理を繰り返し実行する。
【００３４】
所定時間になった場合、制御部１０は、システムがスリープ状態であるかあるか否かの判断（状態判断）を行う（ステップＳ．２）。システムがスリープ状態でない場合（ステップＳ．２でＮｏの場合）、後でデータ更新作業を開始することができるように、タイマー１３により設定される起動時間を変更して（ステップＳ．３）、データの更新処理を終了する。
【００３５】
このように、制御部１０は、システムがスリープ状態あるか否かに基づいて、データの更新処理やアプリケーションのアップデート処理を行うことが可能であるか否かを判断する。例えば、既にシステムが起動されている場合、バスの運行支援を行うためのアプリケーションが既に実行されている可能性があり、このようにアプリケーションが実行されてバスの運行支援処理が開始されている場合（バスの営業が行われている場合）には、データの更新処理やアップデート処理に伴うシステムの停止やエラー等の発生等を回避するため、データの更新処理やアップデート処理を直ぐには行わない。制御部１０は、タイマーにより設定される起動時間を変更してデータ更新処理を終了することによって、変更した起動時間（具体的にはバスの営業時間でないと思われる時間帯）に、データ更新処理を再度実行することができるようにする。
【００３６】
システムがスリープ状態であると判断した場合（ステップＳ．２でＹｅｓの場合）、制御部１０は、システムがスリープ状態になる直前の状態（サスペンド処理されることによって保存された直前の状態）をメモリより読み出して、スリープ状態になる直前の状態にシステムを戻す（いわゆる、レジューム復帰、システムの起動処理：ステップＳ．４）。
【００３７】
システムのレジューム復帰後、制御部１０は、通信部１１を介してバス運行システム４に更新データ等が存在しないか否かの問い合わせを行う（ステップＳ．５）。更新データ等が存在しない場合（ステップＳ．５においてＮｏの場合）、制御部１０は、直前の状態をメモリに保存（いわゆる、サスペンド処理、ステップＳ．６）した後に、システムをスリープ状態にして（ステップＳ．７）、データ更新処理を終了する。
【００３８】
システムをスリープ状態とするのは、上述したように、バスの営業を開始する際に迅速にシステムが稼働を始めるようにするためであり、サスペンド処理を行うのは、上述したようにシステム起動時にシステムを直前の状態に戻すためである。
【００３９】
更新データ等が存在する場合（ステップＳ．５においてＹｅｓの場合）、制御部１０は、通信部１１を介してバス運行システム４より更新データ等を取得し、記録部１２に保存する（ステップＳ．８）。制御部１０は、保存した更新データ等から、車両のダイヤ情報を取得し（ステップＳ．９）、ダイヤ情報より、データの更新処理を行う間にバスの営業が開始されないか否かの判断を行う（ステップＳ．１０）。
【００４０】
ダイヤ情報より、営業が開始されるおそれがあると判断した場合（ステップＳ．１０においてＹｅｓの場合）、制御部１０は、取得した更新データ等に基づくデータ更新を行うことなく、タイマー１３により設定される起動時間を変更し（ステップＳ．１１）、システムのサスペンド処理を行った後に（ステップＳ．６）、システムをスリープ状態にして（ステップＳ．７）、システム更新処理を終了する。
【００４１】
このように、ダイヤ情報に基づいて、データ更新作業中に営業が開始されるか否かの判断を行うことによって、更新処理中に営業が開始されてしまい、システムの運行支援処理に支障が生じてしまうことを回避することができる。
【００４２】
ダイヤ情報より、営業が開始されるおそれがないと判断した場合（ステップＳ．１０においてＮｏの場合）、制御部１０は、取得した更新データ等の中に、システムの再起動を必要とするデータ、例えばドライバの更新データや、アプリケーションのアップデート情報データ等が含まれているか否かの判断を行う（ステップＳ．１２）。
【００４３】
システムの再起動を必要とするデータが含まれている場合（ステップＳ．１２においてＹｅｓの場合）、制御部１０は、ドライバの更新データ、アップデート情報データ等を用いてシステムの更新処理を行った後に（ステップＳ．１３）、システムの再起動処理を行うことによって、システムのシャットダウン、システムのリセット、システムの再起動という一連の処理を実行させる（ステップＳ．１３）。
【００４４】
また、システムの再起動を必要とするデータが含まれていない場合（ステップＳ．１２においてＮｏの場合）、制御部１０は、更新データを用いて必要な情報の更新を行う（ステップＳ．１５）。例えば、ダイヤ情報の更新等は、システムの再起動を必要としないデータの更新に該当する。
【００４５】
このようにして、データの更新処理（ステップＳ．１３、ステップＳ．１５）が終了した後、制御部１０は、システムのサスペンド処理を行い（ステップＳ．６）、システムをスリープ状態にして（ステップＳ．７）、システム更新処理を終了する。
【００４６】
以上説明したように、本発明に係る車載用運行支援装置を用いることによって、車載用運行支援装置の制御部１０が、自動的に更新データが存在するか否かを判断してデータの更新処理を行うので、人手に頼ることなくデータの更新処理を行うことができ、バス会社のデータ更新負担を低減させることができる。
【００４７】
特に、バスの運行支援システムのように、営業時間中にデータ更新を行うことによってトラブル等が発生するおそれがあるシステムでは、営業時間外にデータの更新作業を行う必要があり、一般的には深夜等の限られた時間にしかデータの更新を行うことができないという問題がある。しかしながら、本発明に係る車載用運行支援装置では、制御部１０が、所定の時間、具体的にはバスの営業が行われていない時間に、データの更新作業を自動的に行うので、データの更新作業に伴うトラブルの発生を低減させることができる。
【００４８】
さらに、システムの再起動が必要となるようなデータ更新処理が必要な場合には、データの更新作業に加えてシステムの再起動作業が必要とされるため、データ更新処理にある程度の時間が掛かってしまう。このため、本発明に係る車載用運行支援装置では、取得したバスのダイヤ情報に基づいて、データの更新作業およびシステムの再起動作業を行っている間にバスの営業が行われないことを判断してデータ更新処理を実行するので、データ更新および再起動中に営業が開始してしまってシステムにトラブルが発生してしまうことを回避させることが可能となる。
【００４９】
また、データの更新作業においてシステムのスリープ状態等からバスが営業状態にあると判断した場合や、ダイヤ情報からデータ更新作業中に営業が開始されるおそれがあると判断した場合には、制御部１０が、タイマー１３により設定される起動時間を変更するので、データ更新処理を行うことができなかった場合であっても、その後にデータ更新処理を確実に行うことができる。
【００５０】
さらに、制御部１０は、無線通信技術を用いてバス運行システムと交信を行うことにより、新データの有無判断、更新データの取得処理を行うので、各バスの車載用運行支援装置にデータ交信用の有線ケーブル等を接続することなくデータ更新処理を行うことができ、データ更新処理における処理負担の軽減を図ることが可能となる。
【００５１】
また、定期的なシステムの再起動を、制御部１０によって自動的に行うことによって、アプリケーションの実行に伴うメモリの断片化や不十分なメモリの解放などに起因する処理速度の低下やシステムの不安定化を改善することが可能となる。
【００５２】
さらに、データ更新処理を行った後に、システムのサスペンド処理およびスリープ状態処理を行うことによって、後に運行支援処理を実行する場合に迅速にシステムを稼働させることができる。
【００５３】
以上、本発明に係る車載用運行支援装置について、図面を用いて詳細に説明を行ったが、本発明に係る車載用運行支援装置は上述した実施形態に限定されるものではない。当業者であれば、特許請求の範囲に記載された範疇内において各種の変更例または修正例に想到しうることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【００５４】
例えば、上述した実施形態では、無線通信技術を用いて制御部１０がバス運行システムとの更新を行い、更新データの有無を判断することとしたが、必ずしも無線通信技術を用いる必要はない。一例として、車載用運行支援装置に携帯式のメモリカード等を読み取るためのスロット等を設けて、バスの営業終了後にバスの運転手がそのスロットに更新データ等が記録されたメモリカードをセットした状態でバスを車庫に停車させるようにしてもよい。このようなメモリカードを利用することによって、制御部１０がスロットにセットされたメモリカードの中身を読み出して更新データの有無を判断し、必要に応じてメモリカードから更新データを読み出すような構成とすることができる。
【００５５】
また、上述した実施形態では、システムがスリープ状態にあるか否かにより、バスの営業状態を判断することとしたが（図２のステップＳ．２参照）、必ずしもシステムのスリープ状態だけで判断する必要はなく、例えば、車両のアクセサリ電源（ＡＣＣ）の状態や、エンジンが始動されているか否か等によりバスの営業状態を判断するようにしてもよい。
【図面の簡単な説明】
【００５６】
【図１】本実施形態に係る車両用運行支援装置およびバス運行システムの概略構成を示したブロック図である。
【図２】本実施形態に係る車両用運行支援装置の制御部が行うデータ更新処理を示したフローチャートである。
【符号の説明】
【００５７】
１     …車載用運行支援装置
２     …バス運行システム
３     …バス管理サーバ
１０   …制御部（システム起動手段、更新情報判断手段、更新データ取得手段、状態判断手段、データ更新手段、システム再起動手段）
１１   …通信部
１２   …記録部
１３   …タイマー
３１   …記録装置
【図１】
0004749192.tif 000002
【図２】
0004749192.tif 000003