(57)【要約】【課題】予期せぬ車両の稼働停止が生じるおそれを低減することができる車両整備管理装置、車両整備管理システム、車両整備管理プログラム及び車両整備管理方法を提供する。【解決手段】  運行後の車両Ｃについての次回の運行の可否に関する情報である次回運行可否データＤ１３を取得する第１取得手段（通信部６２）と、次回運行可否データＤ１３において次回の運行が不可と判定された車両Ｃについて、整備予定日時を特定したデータである整備予定日時データＤ１４を取得する第２取得手段（制御部６１又は通信部６２）と、を備える。【選択図】図１
2020166560.tif 000002
【特許請求の範囲】
【請求項１】
運行後の車両についての次回の運行の可否に関する情報である次回運行可否データを取得する第１取得手段と、
前記次回運行可否データにおいて次回の運行が不可と判定された車両について、整備予定日時を特定したデータである整備予定日時データを取得する第２取得手段と、
を備えることを特徴とする車両整備管理装置。
【請求項２】
前記第２取得手段は、前記車両の稼働予定に関する情報である車両稼働データと、整備工場の整備実施可能日時に関する情報である整備実施可能日時データと、を用いて、前記車両の整備予定日時を特定し、前記整備予定日時データを生成することを特徴とする請求項１に記載の車両整備管理装置。
【請求項３】
前記次回運行可否データと、前記整備予定日時データと、を用いて、前記車両の次回の運行の可否と、次回の運行が不可と判定された車両についての整備予定日時と、を含む点呼記録簿データを生成する点呼記録簿生成手段と、
前記点呼記録簿データを、前記車両の点呼を統括する所定の運行管理者が管理する運行管理者端末に送信する第１送信手段と、
を備えることを特徴とする請求項１又は２に記載の車両整備管理装置。
【請求項４】
前記点呼記録簿データは、前記車両の運行前点検に基づく前記車両の運行可否に係る情報である運行前点検結果データと、前記車両を運転するドライバーの健康状態に関する所定の項目についての判定結果である運行前ドライバー判定データと、をさらに含むことを特徴とする請求項３に記載の車両整備管理装置。
【請求項５】
前記次回運行可否データは、前記車両についての次回の運行の可否に関する情報に加え、前記車両を使用するユーザに対するヒアリングの要否に関する情報を含むことを特徴とする請求項１から４のいずれか一項に記載の車両整備管理装置。
【請求項６】
請求項１から５のいずれか一項に記載の車両整備管理装置と、
整備工場に備えられた整備工場端末と、
を備え、
前記第１取得手段は、前記整備工場端末から前記次回運行可否データを取得することを特徴とする車両整備管理システム。
【請求項７】
運行後の車両の車両状態に関する情報である運行後車両状態データを取得する車載器と、
前記車載器と通信接続され、ドライバーによって管理されるドライバー端末と、
を備え、
前記ドライバー端末は、
前記車載器により取得された運行後車両状態データを用いて、所定の点検項目の充足性について判定し、運行後車両判定データを生成する第１判定手段と、
前記運行後車両判定データを前記車両整備管理装置に送信する第２送信手段と、
を備えることを特徴とする請求項６に記載の車両整備管理システム。
【請求項８】
前記車両整備管理装置は、
前記ドライバー端末から取得した前記運行後車両判定データを、前記整備工場端末に送信する第３送信手段を備えることを特徴とする請求項７に記載の車両整備管理システム。
【請求項９】
前記車両の整備を統括する所定の整備管理者によって管理される整備管理者端末を備え、
前記車載器は、運行前の車両の車両状態に関する情報である運行前車両状態データを取得し、
前記ドライバー端末は、
前記車載器により取得された前記運行前車両状態データを用いて、所定の点検項目の充足性について判定し、運行前車両判定データを生成する第２判定手段と、
前記運行前車両判定データを前記整備管理者端末に送信する第４送信手段と、
を備え、
前記整備管理者端末は、前記運行前車両判定データに基づく前記車両の運行可否に係る情報である運行前点検結果データを、前記車両整備管理装置に送信する第５送信手段を備えることを特徴とする請求項７又は８に記載の車両整備管理システム。
【請求項１０】
前記車両の点呼を統括する所定の運行管理者によって管理される運行管理者端末を備え、
前記車載器は、運行前のドライバーの健康状態に関する情報であるドライバー状態データを取得し、
前記ドライバー端末は、
前記車載器により取得された前記ドライバー状態データを用いて、所定の点呼項目の充足性について判定し、運行前ドライバー判定データを生成する第３判定手段と、
前記運行前ドライバー判定データを前記車両整備管理装置に送信する第６送信手段と、
を備えることを特徴とする請求項７から９のいずれか一項に記載の車両整備管理システム。
【請求項１１】
コンピュータを、
運行後の車両についての次回の運行の可否に関する情報である次回運行可否データを取得する第１取得手段、
前記次回運行可否データにおいて次回の運行が不可と判定された車両について、整備予定日時を特定したデータである整備予定日時データを取得する第２取得手段、
として機能させる車両整備管理プログラム。
【請求項１２】
運行後の車両についての次回の運行の可否に関する情報である次回運行可否データを取得する第１取得ステップと、
前記次回運行可否データにおいて次回の運行が不可と判定された車両について、整備予定日時を特定したデータである整備予定日時データを取得する第２取得ステップと、
を含む車両整備管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両整備管理装置、車両整備管理システム、車両整備管理プログラム及び車両管理方法に関する。
【背景技術】
【０００２】
運送事業者等においては、多数の車両を使用することから、車両の故障がある程度の頻度で必ず生じるところ、従前は、故障した車両の整備は、故障を当該車両のドライバー等が発見し、これが整備工場に連絡されるのを待って行われるのが通常であった。
そこで、車両の故障をドライバーが発見することを支援することを目的としたシステムが知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２００６−５１９７２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、従来のシステムでは、ドライバーによる故障の発見は容易となっても、故障の整備の実施については、ドライバーによる整備工場への連絡に頼らざるを得なかったことから、整備のタイミングを適切なものとすることは難しく、故障の整備の実施によって予期せぬ車両の稼働停止が生じることが多かった。
【０００５】
本発明の課題は、予期せぬ車両の稼働停止が生じるおそれを低減することができる車両整備管理装置、車両整備管理システム、車両整備管理プログラム及び車両整備管理方法を提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、請求項１に記載の発明は、車両整備管理装置において、
運行後の車両についての次回の運行の可否に関する情報である次回運行可否データを取得する第１取得手段と、
前記次回運行可否データにおいて次回の運行が不可と判定された車両について、整備予定日時を特定したデータである整備予定日時データを取得する第２取得手段と、
を備えることを特徴とする。
【０００７】
請求項２に記載の発明は、請求項１に記載の車両整備管理装置において、
前記第２取得手段は、前記車両の稼働予定に関する情報である車両稼働データと、整備工場の整備実施可能日時に関する情報である整備実施可能日時データと、を用いて、前記車両の整備予定日時を特定し、前記整備予定日時データを生成することを特徴とする。
【０００８】
請求項３に記載の発明は、請求項１又は２に記載の車両整備管理装置において、
前記次回運行可否データと、前記整備予定日時データと、を用いて、前記車両の次回の運行の可否と、次回の運行が不可と判定された車両についての整備予定日時と、を含む点呼記録簿データを生成する点呼記録簿生成手段と、
前記点呼記録簿データを、前記車両の点呼を統括する所定の運行管理者が管理する運行管理者端末に送信する第１送信手段と、
を備えることを特徴とする。
【０００９】
請求項４に記載の発明は、請求項３に記載の車両整備管理装置において、
前記点呼記録簿データは、前記車両の運行前点検に基づく前記車両の運行可否に係る情報である運行前点検結果データと、前記車両を運転するドライバーの健康状態に関する所定の項目についての判定結果である運行前ドライバー判定データと、をさらに含むことを特徴とする。
【００１０】
請求項５に記載の発明は、請求項１から４のいずれか一項に記載の車両整備管理装置において、
前記次回運行可否データは、前記車両についての次回の運行の可否に関する情報に加え、前記車両を使用するユーザに対するヒアリングの要否に関する情報を含むことを特徴とする。
【００１１】
請求項６に記載の発明は、車両整備管理システムにおいて、
請求項１から５のいずれか一項に記載の車両整備管理装置と、
整備工場に備えられた整備工場端末と、
を備え、
前記第１取得手段は、前記整備工場端末から前記次回運行可否データを取得することを特徴とする。
【００１２】
請求項７に記載の発明は、請求項６に記載の車両整備管理システムにおいて、
運行後の車両の車両状態に関する情報である運行後車両状態データを取得する車載器と、
前記車載器と通信接続され、ドライバーによって管理されるドライバー端末と、
を備え、
前記ドライバー端末は、
前記車載器により取得された運行後車両状態データを用いて、所定の点検項目の充足性について判定し、運行後車両判定データを生成する第１判定手段と、
前記運行後車両判定データを前記車両整備管理装置に送信する第２送信手段と、
を備えることを特徴とする。
【００１３】
請求項８に記載の発明は、請求項７に記載の車両整備管理システムにおいて、
前記車両整備管理装置は、
前記ドライバー端末から取得した前記運行後車両判定データを、前記整備工場端末に送信する第３送信手段を備えることを特徴とする。
【００１４】
請求項９に記載の発明は、請求項７又は８に記載の車両整備管理システムにおいて、
前記車両の整備を統括する所定の整備管理者によって管理される整備管理者端末を備え、
前記車載器は、運行前の車両の車両状態に関する情報である運行前車両状態データを取得し、
前記ドライバー端末は、
前記車載器により取得された前記運行前車両状態データを用いて、所定の点検項目の充足性について判定し、運行前車両判定データを生成する第２判定手段と、
前記運行前車両判定データを前記整備管理者端末に送信する第４送信手段と、
を備え、
前記整備管理者端末は、前記運行前車両判定データに基づく前記車両の運行可否に係る情報である運行前点検結果データを、前記車両整備管理装置に送信する第５送信手段を備えることを特徴とする。
【００１５】
請求項１０に記載の発明は、請求項７から９のいずれか一項に記載の車両整備管理システムにおいて、
前記車両の点呼を統括する所定の運行管理者によって管理される運行管理者端末を備え、
前記車載器は、運行前のドライバーの健康状態に関する情報であるドライバー状態データを取得し、
前記ドライバー端末は、
前記車載器により取得された前記ドライバー状態データを用いて、所定の点呼項目の充足性について判定し、運行前ドライバー判定データを生成する第３判定手段と、
前記運行前ドライバー判定データを前記車両整備管理装置に送信する第６送信手段と、
を備えることを特徴とする。
【００１６】
請求項１１に記載の発明は、車両整備管理プログラムであって、
コンピュータを、
運行後の車両についての次回の運行の可否に関する情報である次回運行可否データを取得する第１取得手段、
前記次回運行可否データにおいて次回の運行が不可と判定された車両について、整備予定日時を特定したデータである整備予定日時データを取得する第２取得手段、
として機能させる。
【００１７】
請求項１２に記載の発明は、車両整備管理方法であって、
運行後の車両についての次回の運行の可否に関する情報である次回運行可否データを取得する第１取得ステップと、
前記次回運行可否データにおいて次回の運行が不可と判定された車両について、整備予定日時を特定したデータである整備予定日時データを取得する第２取得ステップと、
を含む。
【発明の効果】
【００１８】
本発明によれば、予期せぬ車両の稼働停止が生じるおそれを低減することができる車両整備管理装置、車両整備管理システム、車両整備管理プログラム及び車両整備管理方法を提供することができる。
【図面の簡単な説明】
【００１９】
【図１】実施形態に係る車両整備管理システムの構成を示すブロック図である。
【図２】実施形態に係る車両整備管理システムにおけるデータの流れを示すブロック図である。
【図３】実施形態に係る車両整備管理システムの使用時の流れを示すフローチャートである。
【発明を実施するための形態】
【００２０】
以下、図１から図３に基づいて、本発明の実施形態である車両整備管理システム１００について説明する。
【００２１】
［１  構成の説明］
車両整備管理システム１００は、図１及び図２に示すように、車載器１と、ドライバー端末２と、運行管理者端末３と、整備管理者端末４と、責任者端末５と、管理サーバ６と、整備工場端末７と、を備えて構成されている。また、車両整備管理システム１００を構成する各装置は、図１に示すように、通信ネットワークＮを介して接続されている。
【００２２】
｛（１）車載器｝
車載器１は、主として車両整備管理システム１００のユーザである運送事業者Ｕが管理し、運送に使用する車両Ｃの夫々に取り付けられた、ドライバーＴの健康状態に関する情報である運行前ドライバー状態データＤ７並びに車両Ｃの車両状態に関する情報である運行前車両状態データＤ４及び運行後車両状態データＤ１１を取得するための機器であり、アルコールチェッカー１１と、生体センサ１２と、故障診断機１３と、タイヤセンサ１４と、を含む。
なお、車載器１は、全てが車両Ｃに取り付けられている必要はなく、例えばドライバーＴが携帯する等の形で、点呼・点検時にのみ車両Ｃの車内に持ち込まれるものが含まれてもよい。例えば、アルコールチェッカー１１及び生体センサ１２については、車両Ｃに取り付けることなくドライバーＴが携帯する形として、事務所等車外の場所においても使用できるようにしてもよい。
また、以下においては、各種センサが各々個別に通信部を備え、各通信部から個別にドライバー端末２に検出結果を送信する構成として説明するが、各種センサから一の通信部に有線又は無線で検出結果を一旦送信し、一の通信部が各種センサからの検出結果をまとめてドライバー端末２に送信する構成としてもよい。
【００２３】
（アルコールチェッカー）
アルコールチェッカー１１は、車両Ｃの運転席の所定の位置に備えられ、図１に示すように、アルコール検出部１１１と通信部１１２とを備え、アルコール検出部１１１によって検出したドライバーＴの呼気に含まれるアルコール濃度に関する情報であるアルコールデータＤ７−１を、通信部１１２からドライバー端末２へと送信する。
なお、アルコールチェッカー１１は必ずしも車両Ｃに備えられている必要はなく、例えば、ドライバーＴが携帯して、ドライバー端末２に装着して用いるようにしてもよい。
【００２４】
（生体センサ）
生体センサ１２は、体温センサ１２１と、血圧センサ１２２と、を含み、車両Ｃの車内の所定の位置、例えばハンドルに備えられる。
体温センサ１２１は、図１に示すように、体温検出部１２１１と通信部１２１２とを備え、体温検出部１２１１によって検出したドライバーＴの体温に関する情報である体温データＤ７−２を、通信部１２１２からドライバー端末２へと送信する。
血圧センサ１２２は、図１に示すように、血圧検出部１２２１と通信部１２２２とを備え、血圧検出部１２２１によって検出したドライバーＴの血圧に関する情報である血圧データＤ７−３を、通信部１２２２からドライバー端末２へと送信する。
【００２５】
（故障診断機）
故障診断機１３は、故障診断機本体１３１と、ＯＢＤコネクタ１３２とを含み、車両Ｃの運転席の所定の位置に備えられる。
故障診断機本体１３１は、図１に示すように、診断部１３１１と、通信部１３１２とを含み、ＯＢＤコネクタ１３２を介して取得した車両Ｃの故障の有無に関する情報である運行前故障データＤ４−１及び運行後故障データＤ１１−１を、通信部１３１２からドライバー端末２へと送信する。
【００２６】
故障診断機１３は、車両の運行前又は運行後の点検時に、運行前故障データＤ４−１又は運行後故障データＤ１１−１として、例えば以下の情報を取得する。
ブレーキ・ペダル：踏みしろ及びブレーキの効きについて、関連する故障コードの検出の有無。
パーキングブレーキ・レバー：引きしろ（踏みしろ）について、関連する故障コードの検出の有無。
原動機：かかり具合・異音について、チェンジランプの点灯の有無、関連する故障コードの検出の有無。低速・加速の状態について、チェンジランプの点灯の有無、関連する故障コードの検出の有無。
ウィンドウォッシャ：噴射状態について、液量ウォーニングの点灯の有無、関連する故障コードの検出の有無。
ウィンドウォッシャタンク：液量について、液量ウォーニングの点灯の有無。
ブレーキのリザーバタンク：液量について、ブレーキウォーニングの点灯の有無、関連する故障コードの検出の有無。
バッテリ：液量・電圧について、バッテリーウォーニングの点灯の有無、電圧・電流値の異常の有無、関連する故障コードの検出の有無。
ラジエタ等の冷却装置：液量について、冷却水ウォーニングの点灯の有無、関連する故障コードの検出の有無。
潤滑油：液量について、オイル量ウォーニングの点灯の有無、関連する故障コードの検出の有無。
灯火装置方向指示器：点灯・点滅・汚れ・損傷について、球切れ警告の有無、関連する故障コードの検出の有無。
【００２７】
（タイヤセンサ）
タイヤセンサ１４は、所定のＴＰＭＳ（タイヤ・プレッシャー・モニタリング・システム）が用いられ、図１に示すように、空気圧測定部１４１と通信部１４２とを有し、車両の運行前又は運行後の点検時に、空気圧測定部１４１によって空気圧を測定の上、測定結果に関する情報である運行前空気圧データＤ４−２又は運行後空気圧データＤ１１−２を、通信部１４２からドライバー端末２へと送信する。
【００２８】
｛（２）ドライバー端末｝
ドライバー端末２は、車両整備管理システム１００のユーザである運送事業者Ｕにおいて、車両Ｃの運行を行うドライバーＴの夫々が携帯するスマートフォン、タブレット等の端末であり、車載器１から受信したデータを用いて、所定の判定処理を行う際等に用いられる。
ドライバー端末２は、例えば、制御部２１と、操作部２２と、表示部２３と、記憶部２４と、通信部２５と、映像取得部２６と、を備える。
【００２９】
制御部２１は、ドライバー端末２の動作を制御する部分であり、具体的には、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等を備えて構成され、ＲＡＭの作業領域に展開されたＲＯＭや記憶部２４に記憶されたプログラムデータとＣＰＵとの協働により、ドライバー端末２の各部を統括制御する。
【００３０】
操作部２２は、例えば、文字入力キー、数字入力キー、その他各種機能に対応付けられたキーを有するキーボード等を備え、ドライバーＴからの操作入力を受け付けて、操作入力に応じた操作信号を制御部２１へと出力する。なお、操作部２２は、例えば、表示部２３と一体的に形成されたタッチパネル等であってもよい。
【００３１】
表示部２３は、例えば、ＬＣＤ（Liquid Crystal Display）等のディスプレイを備え、制御部２１から出力された表示制御信号に基づいた画像を表示画面に表示する。
【００３２】
記憶部２４は、ドライバー端末２の運用に必要となる各種情報が記憶される部分であり、例えば、ＨＤＤ（Hard Disk Drive）、半導体メモリ等により構成され、プログラムデータ、各種設定データ等のデータを、制御部２１から読み書き可能に記憶する。
記憶部２４には、ドライバー情報記憶部２４１と、運行前点検プログラム２４２と、運行後点検プログラム２４３と、運行前点呼プログラム２４４と、点呼フォーム２４５と、点検フォーム２４６と、閾値情報記憶部２４７と、が備えられている。
【００３３】
ドライバー情報記憶部２４１には、ドライバー端末２を携帯するドライバーＴの氏名、免許証のＩＣチップ情報、車両整備管理システム１００へのログインＩＤ及びパスワード等が記憶されている。
【００３４】
運行前点検プログラム２４２は、後述の運行前点検に用いられるプログラムであり、運行後点検プログラム２４３は、後述の運行後点検に用いられるプログラムであり、運行前点呼プログラム２４４は、後述の運行前点呼に用いられるプログラムである。
【００３５】
点呼フォーム２４５は、ドライバーＴの点呼時に用いられる入力フォームであり、例えば、脳・心疾患に係る前兆や自覚症状として、
・左胸、左肩から背中にかけて、痛みや圧迫感、締め付けられている感じがする。
・息切れ呼吸がしにくい。
・脈が飛ぶ、胸部の不快感、動悸、めまいなどを感じる。
・片方の手足、顔半分の麻痺、しびれを感じる。
・言語の障害が発生している。
・片方の目が見えない、物が二重に見える、視野の半分が欠ける。
・強い頭痛がする。
といった項目が記載され、ドライバーＴが、問題のある項目がある場合にチェックをつけるようになっている。
さらに、平時の状態との比較として、
・疲れを感じないか。
・気分が悪くないか。
・腹痛、吐き気、下痢がないか。
・眠気を感じないか。
・怪我などで痛みを我慢していないか。
・運転に悪影響を及ぼす薬を服用していないか。
・その他健康状態に関して気になることはないか。
といった項目が記載され、ドライバーＴが、問題のある項目がある場合にチェックをつけるようになっている。
【００３６】
点検フォーム２４６は、車両Ｃの点検時に用いられる入力フォームであり、車両Ｃの状態に関する項目として、例えば、
・ワイパーの拭き取り状態。
・ファンベルトの張り具合、損傷の有無。
・タイヤのディスクホイールの取り付け状態。
・タイヤの亀裂・損傷・摩耗の有無。
・タイヤの溝の深さ。
といった項目が記載され、ドライバーＴが問題のある項目がある場合にチェックをつけるようになっている。
【００３７】
閾値情報記憶部２４７は、所定の点呼項目及び点検項目の充足性の判定の際に用いられる閾値に関する情報である閾値データＤ１５が記憶されたデータベースである。
【００３８】
通信部２５は、車載器１、運行管理者端末３、整備管理者端末４及び管理サーバ６との通信に用いられる部分であり、例えば、通信用ＩＣ（Integrated Circuit）及び通信コネクタなどを有する通信インターフェイスであり、制御部２１の制御の元、所定の通信プロトコルを用いて通信ネットワークＮを介したデータ通信を行う。
【００３９】
映像取得部２６は、ドライバーＴの映像を取得する部分であり、例えば、スマートフォンやタブレット等の端末のインカメラが用いられる。
【００４０】
｛（３）運行管理者端末｝
運行管理者端末３は、車両整備管理システム１００のユーザである運送事業者Ｕにおいて、車両Ｃの点呼を統括する所定の運行管理者Ｏが所在する事務所等に備えられたＰＣ、タブレット等の端末であり、点呼時に、管理サーバ６から受信したデータを、運行管理者Ｏに表示する際等に用いられる。
運行管理者端末３は、例えば、制御部３１と、操作部３２と、表示部３３と、記憶部３４と、通信部３５と、を備える。
【００４１】
制御部３１は、運行管理者端末３の動作を制御する部分であり、具体的には、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えて構成され、ＲＡＭの作業領域に展開されたＲＯＭや記憶部３４に記憶されたプログラムデータとＣＰＵとの協働により、運行管理者端末３の各部を統括制御する。
【００４２】
操作部３２は、例えば、文字入力キー、数字入力キー、その他各種機能に対応付けられたキーなどを有するキーボード、マウス等のポインティングデバイス等を備え、ユーザからの操作入力を受け付けて、操作入力に応じた操作信号を制御部３１へと出力する。なお、操作部３２は、例えば、表示部３３と一体的に形成されたタッチパネル等であってもよい。
【００４３】
表示部３３は、例えば、ＬＣＤ等のディスプレイを備え、制御部３１から出力された表示制御信号に基づいた画像を表示画面に表示する。
【００４４】
記憶部３４は、運行管理者端末３の運用に必要となる各種情報が記憶される部分であり、例えば、ＨＤＤ、半導体メモリ等により構成され、プログラムデータ、各種設定データ等のデータを、制御部３１から読み書き可能に記憶する。
記憶部３４には、運行管理者情報記憶部３４１が備えられている。運行管理者情報記憶部３４１には、運行管理者端末３を使用する運行管理者Ｏの氏名、車両整備管理システム１００へのログインＩＤ及びパスワード等が記憶されている。
【００４５】
通信部３５は、ドライバー端末２及び管理サーバ６との通信に用いられる部分であり、例えば、通信用ＩＣ及び通信コネクタなどを有する通信インターフェイスであり、制御部３１の制御の元、所定の通信プロトコルを用いて通信ネットワークＮを介したデータ通信を行う。
【００４６】
｛（４）整備管理者端末｝
整備管理者端末４は、車両整備管理システム１００のユーザである運送事業者Ｕにおいて、車両Ｃの整備を統括する所定の整備管理者Ｍが所在する事務所等に備えられたＰＣ、タブレット等の端末であり、管理サーバ６から受信したデータを、整備管理者Ｍに表示する際等に用いられる。
【００４７】
整備管理者端末４は、運行管理者端末３と同様に、例えば、制御部４１と、操作部４２と、表示部４３と、記憶部４４と、通信部４５と、を備えて構成され、通信部４５によって、通信ネットワークＮを介して、ドライバー端末２及び管理サーバ６と接続されている。
また、記憶部４４に、整備管理者端末４を使用する整備管理者Ｍの氏名、車両整備管理システム１００へのログインＩＤ及びパスワード等が記憶された、整備管理者情報記憶部４４１が備えられている。
【００４８】
｛（５）責任者端末｝
責任者端末５は、車両整備管理システム１００のユーザである運送事業者Ｕにおいて、ドライバーＴの点呼及び車両Ｃの点呼の両者に責任を有する所定の責任者Ｒが所在する事務所等に備えられたＰＣ、タブレット等の端末であり、後述のように、所定の責任者Ｒが、運送事業者データＤ２につき入力し、管理サーバ６の記憶部６３の運送事業者データベース６３２に登録する際等に用いられる。
【００４９】
責任者端末５は、運行管理者端末３及び整備管理者端末４と同様に、例えば、制御部５１と、操作部５２と、表示部５３と、記憶部５４と、通信部５５と、を備えて構成され、通信部５５によって、通信ネットワークＮを介して、管理サーバ６と接続されている。
また、記憶部５４に、責任者端末５を使用する責任者Ｒの氏名、車両整備管理システム１００へのログインＩＤ及びパスワード等が記憶された、責任者情報記憶部５４１が備えられている。
【００５０】
｛（６）管理サーバ｝
管理サーバ６は、車両整備管理システム１００を提供するシステム提供企業Ｖの所定の場所に備えられたＰＣ、ＷＳ（Work Station）等の情報機器であり、端末間での各種データの送受信の仲介や、各種データの生成、保存等に用いられる。
なお、管理サーバ６は、必ずしも車両整備管理システム１００を提供するシステム提供企業Ｖ自ら保有することを要せず、例えば、クラウドサービスを提供する会社が保有するＰＣ、ＷＳ等の情報機器を利用してもよい。
管理サーバ６は、例えば、制御部６１と、通信部６２と、記憶部６３と、を備えて構成される。
【００５１】
制御部６１は、管理サーバ６の動作を制御する部分であり、具体的には、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えて構成され、ＲＡＭの作業領域に展開されたＲＯＭや記憶部６３に記憶されたプログラムデータとＣＰＵとの協働により、管理サーバ６の各部を統括制御する。
【００５２】
通信部６２は、ドライバー端末２、運行管理者端末３、整備管理者端末４、責任者端末５及び整備工場端末７との通信に用いられる部分であり、例えば、通信用ＩＣ及び通信コネクタなどを有する通信インターフェイスであり、制御部６１の制御の元、所定の通信プロトコルを用いて通信ネットワークＮを介したデータ通信を行う。
【００５３】
記憶部６３は、管理サーバ６の運用に必要となる各種情報が記憶される部分であり、例えば、ＨＤＤ、半導体メモリ等により構成され、プログラムデータ、各種設定データ等のデータを、制御部６１から読み書き可能に記憶する。
記憶部６３には、整備実施可能日時データベース６３１と、運送事業者データベース６３２と、配車情報データベース６３３と、点呼記録簿データベース６３４と、運行可否・整備日時データベース６３５と、点呼記録簿作成プログラム６３６と、整備日時特定プログラム６３７と、が備えられている。
【００５４】
整備実施可能日時データベース６３１は、整備実施可能日時データＤ１が記憶されるデータベースである。
整備実施可能日時データＤ１は、事前に整備工場Ｆにおいて実施することが決まっている車両Ｃの３か月定期点検及び車検のスケジュールや、実施が決まっている故障整備のスケジュール等を踏まえ、整備工場Ｆが車両Ｃの整備につき対応可能な日時を登録したデータである。
【００５５】
運送事業者データベース６３２は、ドライバー勤務データＤ２−１及び車両稼働データＤ２−２からなる運送事業者データＤ２が記憶されるデータベースである。
ドライバー勤務データＤ２−１は、運送事業者Ｕが、自らに属する各ドライバーＴについて、氏名等の各ドライバーＴを特定できる情報と関連付けて、その勤務予定日及び勤務予定時間につき登録したデータである。例えば、平日（月曜から金曜）の午前９時から午後５時まで勤務するドライバーＴであれば、その旨が登録されている。
車両稼働データＤ２−２は、運送事業者Ｕが、自らが管理する各車両Ｃについて、ナンバー等の各車両Ｃを特定できる情報と関連付けて、その稼働予定日及び稼働予定時間につき登録したデータである。例えば、平日（月曜から金曜）の午前９時から午後７時まで稼働する車両Ｃであれば、その旨が登録されている。
【００５６】
点呼記録簿データベース６３４は、点呼記録簿データＤ９が記憶されるデータベースである。
点呼記録簿データＤ９は、運行前点検における整備管理者の承認／不承認の結果、運行前点呼におけるドライバー端末２による所定の項目に係る判定結果、前回の運行後になされた整備工場Ｆの整備士Ｓによる次回運行の可否に係る判定の結果及び運行不可と判定された車両Ｃについての整備予定日時等からなる点呼記録簿に係るデータである。
【００５７】
運行可否・整備日時データベース６３５は、次回運行可否データＤ１３及び整備予定日時データＤ１４が記憶されるデータベースである。
次回運行可否データＤ１３は、運行後点検の結果を元に整備工場Ｆの整備士Ｓが、車両Ｃの次回の運行の可否について判定した判定結果に係るデータである。
整備予定日時データＤ１４は、次回運行可否データＤ１３で次回の運行が不可と判定された車両Ｃにつき、整備を実施する予定の日時につき特定した特定結果に係るデータである。
【００５８】
点呼記録簿作成プログラム６３６は、点呼記録簿データＤ９を作成するためのプログラムである。
整備日時特定プログラム６３７は、整備工場Ｆの整備士Ｓによって次回の運行が不可と判定された車両Ｃにつき、整備を実施する予定の日時につき特定するためのプログラムである。
【００５９】
｛（７）整備工場端末｝
整備工場端末７は、車両整備管理システム１００と連携する整備工場Ｆが保有する、ＰＣ、タブレット等の端末であり、車両Ｃの運行後に行われる運行後点検において取得された車両Ｃに関する運行後車両判定データＤ１２を、整備工場Ｆの整備士Ｓに対し表示すると共に、整備士Ｓによる次回運行可否データＤ１３の入力を受ける際等に用いられる。
【００６０】
整備工場端末７は、運行管理者端末３、整備管理者端末４及び責任者端末５と同様に、例えば、制御部７１と、操作部７２と、表示部７３と、記憶部７４と、通信部７５と、を備えて構成され、通信部７５によって、通信ネットワークＮを介して、管理サーバ６と接続されている。
【００６１】
｛（８）通信ネットワーク｝
通信ネットワークＮは、例えば、インターネット、電話回線網、携帯電話通信網、無線ＬＡＮ通信網等である。
【００６２】
［２  動作の説明］
以下、実施形態に係る車両整備管理システム１００の使用時の流れについて、図２及び３に基づいて説明する。
【００６３】
｛（１）ステップＳ１：事前登録｝
車両整備管理システム１００と連携し、車両Ｃの整備を行う整備工場Ｆと、車両整備管理システム１００を利用するユーザである運送事業者Ｕは、まず以下の事前登録を行う。
【００６４】
（ステップＳ１−１：整備実施可能日時データの登録）
車両整備管理システム１００と連携する整備工場Ｆは、整備実施可能日時データＤ１の登録を行う。
具体的には、整備工場Ｆは、整備実施可能日時データＤ１として、事前に整備工場Ｆにおいて実施することが決まっている車両Ｃの３か月定期点検や車検のスケジュールや、既に実施が決まっている故障整備のスケジュール等を踏まえ、整備工場Ｆが車両Ｃの整備につき対応可能な日時につき、整備工場端末７の操作部７２を用いて入力する。
これらのデータが入力されると、整備工場端末７は、入力されたデータを、通信部７５から、通信ネットワークＮを介して管理サーバ６に送信し、通信部６２によってこれを受信した管理サーバ６においては、制御部６１が、整備実施可能日時データＤ１を、記憶部６３の整備実施可能日時データベース６３１に記憶する。
【００６５】
なお、整備実施可能日時データＤ１としては、常に整備工場Ｆの最新のスケジュールに基づく情報が記憶されている必要があり、整備工場Ｆは、スケジュールの変動があった場合には、その都度登録を行う必要がある。また、例えば、整備工場端末７の記憶部７４に整備工場Ｆのスケジュールが記憶されるデータベースを設け、その記憶内容と、整備実施可能日時データベース６３１の記憶内容が、自動的に、通信ネットワークＮを通じて同期されるようにしてもよい。
【００６６】
（ステップＳ１−２：運送事業者データの登録）
車両整備管理システム１００のユーザである運送事業者Ｕは、運送事業者データＤ２の登録を行う。具体的には、運送事業者Ｕは、責任者Ｒが、ドライバー勤務データＤ２−１及び車両稼働データＤ２−２につき、責任者端末５の操作部５２を用いてして入力する。
これらのデータが入力されると、責任者端末５は、入力されたデータを、通信部５５から、通信ネットワークＮを介して管理サーバ６に送信し、通信部６２によってこれを受信した管理サーバ６においては、制御部６１が、ドライバー勤務データＤ２−１及び車両稼働データＤ２−２からなる運送事業者データＤ２を、記憶部６３の運送事業者データベース６３２に記憶する。
【００６７】
なお、上記の通り、ドライバー勤務データＤ２−１としては、運送事業者Ｕが、自らに属する各ドライバーＴについて、氏名等の各ドライバーＴを特定できる情報と関連付けて、その勤務予定日及び勤務時間につき登録する。例えば、平日（月曜から金曜）の午前９時から午後５時まで勤務するドライバーＴであれば、その旨を登録する。
車両稼働データＤ２−２としては、運送事業者Ｕが、自らが管理する各車両Ｃについて、ナンバー等の各車両Ｃを特定できる情報と関連付けて、その稼働予定日及び稼働予定時間につき登録する。例えば、平日（月曜から金曜）の午前９時から午後７時まで稼働する車両Ｃであれば、その旨を登録する。
【００６８】
運送事業者データＤ２としても、常に最新のデータが登録されている必要があることから、責任者Ｒは、ドライバー勤務データＤ２−１及び／又は車両稼働データＤ２−２に変更があった場合には、その都度登録を行う必要がある。
また、運送事業者データＤ２は、運送事業者Ｕを代理して、整備工場Ｆが整備工場端末７を用いて登録するようにしてもよい。
【００６９】
｛（２）ステップＳ２：配車データの登録｝
車両整備管理システム１００の使用中、車両整備管理システム１００のユーザである運送事業者Ｕの運行管理者Ｏは、車両Ｃの運行の際には、運行の前日に、車両Ｃのそれぞれにつき、翌日の配車データＤ３の登録を行う。
【００７０】
具体的には、運行管理者Ｏは、運行管理者端末３の操作部３２を用いて、通信部３５から、通信ネットワークＮを介して、管理サーバ６の記憶部６３に備えられた運送事業者データベース６３２にアクセスし、車両Ｃの運行を要するルート毎に、ドライバー勤務データＤ２−１から翌日勤務予定のドライバーＴを抽出し、車両稼働データＤ２−２から翌日稼働予定の車両Ｃを抽出した上で、これを配車データＤ３として、運行管理者端末３の操作部３２を用いて入力する。
これらのデータが入力されると、運行管理者端末３は、入力内容を、通信部３５から、通信ネットワークＮを介して管理サーバ６に送信し、通信部６２によってこれを受信した管理サーバ６においては、制御部６１が、配車データＤ３を、記憶部６３の配車情報データベース６３３に記憶する。
【００７１】
これによって、配車情報データベース６３３には、翌日運行予定のルート毎に、担当予定のドライバーＴに関する情報と、使用される車両Ｃに関する情報が、逐一記憶されることとなる。
なお、配車データＤ３についても、運送事業者Ｕを代理して、整備工場Ｆが整備工場端末７を用いて登録するようにしてもよい。
【００７２】
｛（３）ステップＳ３：運行前点検｝
車両Ｃの運行日当日の朝になると、まず、運行前点検が実施される。具体的には以下のとおりである。
【００７３】
（ステップＳ３−１：運行前ドライバーのログイン）
車両Ｃの運行を行うドライバーＴは、配車データＤ３においてその日に自らが使用する予定となっている車両Ｃに乗車し、これを車庫内の所定の点検場所に停車させた上で、ドライバー端末２において運行前点検プログラム２４２を起動し、免許証のＩＣチップによるドライバーＴの特定を行った上で、所定のログインＩＤ及びパスワードを、ドライバー端末２の操作部２２を用いて入力することで、車両整備管理システム１００へのログインを行う。入力を受けたドライバー端末２においては、入力内容をドライバー情報記憶部２４１の記憶内容と対照し、一致した場合にログインを認める。
【００７４】
（ステップＳ３−２：運行前車両状態データの取得）
続いて、車載器１によって、点検に必要な運行前車両状態データＤ４、すなわち運行前故障データＤ４−１及び運行前空気圧データＤ４−２が取得された上で、ドライバー端末２へと送信される。
【００７５】
具体的には、まず、故障診断機１３の故障診断機本体１３１は、診断部１３１１によって、上記のような車両Ｃの故障の有無に関する情報である運行前故障データＤ４−１を取得の上、通信部１３１２からドライバー端末２へと送信する。
【００７６】
また、タイヤセンサ１４は、空気圧測定部１４１によって車両Ｃのタイヤの空気圧に関する情報である運行前空気圧データＤ４−２を取得の上、通信部１４２からドライバー端末２へと送信する。
【００７７】
また、ドライバーＴは、ドライバー端末２の記憶部２４に備えられた点検フォーム２４６を用いて、上記のような所定の点検項目について入力する。具体的には、ドライバーＴは、点検フォーム２４６に記載された所定の項目につき、問題のある項目がある場合に操作部２２を用いてチェックをつける形で、所定の点検項目についての入力を行う。
【００７８】
（ステップＳ３−３：運行前車両状態データに基づく判定）
続いて、運行前車両状態データＤ４を通信部２５によって取得したドライバー端末２において、制御部２１によって、運行前車両状態データＤ４に基づく判定がなされる。すなわち、制御部２１が、本発明における第２判定手段として機能することとなる。
【００７９】
具体的には、まずドライバー端末２の制御部２１は、記憶部２４に備えられた運行前点検プログラム２４２を用いて、故障診断機１３から通信部２５によって取得した運行前故障データＤ４−１に基づき、上記のような所定の故障コード、ランプ・ウォーニング等の点灯、異常・警告等が検出されている箇所がないかを判定する。
【００８０】
続いて、ドライバー端末２の制御部２１は、記憶部２４に備えられた運行前点検プログラム２４２を用いて、タイヤセンサ１４から通信部２５によって取得した運行前空気圧データＤ４−２と、記憶部２４に備えられた閾値情報記憶部２４７に記憶された閾値データＤ１５に含まれるタイヤの空気圧に関する閾値情報と、を対比し、車両Ｃのタイヤの空気圧が基準値の８０％以下となっていないかを判定する。
【００８１】
続いて、ドライバー端末２の制御部２１は、記憶部２４に備えられた運行前点検プログラム２４２を用いて、ドライバーＴによって入力された点検フォーム２４６にチェックがなされた項目がないかについて判定する。
【００８２】
（ステップＳ３−４：整備管理者端末への送信）
ステップＳ３−３の判定がなされると、ドライバー端末２の制御部２１は、ステップＳ３−３における判定結果に係る情報である運行前車両判定データＤ５を、通信部２５から、通信ネットワークＮを通じて、整備管理者端末４へと送信する。すなわち、通信部２５が、本発明における第４送信手段として機能することとなる。
【００８３】
（ステップＳ３−５：判定結果の承認）
運行前車両判定データＤ５を通信部４５によって受信した整備管理者端末４においては、制御部４１が、運行前車両判定データＤ５を受信した旨の通知を、表示部４３に表示する。
【００８４】
これを確認した整備管理者Ｍは、所定のログインＩＤ及びパスワードを、整備管理者端末４の操作部４２を用いて入力することで、車両整備管理システム１００へのログインを行う。入力を受けた整備管理者端末４においては、入力内容を整備管理者情報記憶部４４１の記憶内容と対照し、一致した場合にログインを認める。
【００８５】
整備管理者Ｍがログインすると、整備管理者端末４は、制御部４１が、表示部４３に運行前車両判定データＤ５を表示する。
整備管理者端末４の表示部４３に運行前車両判定データＤ５が表示されると、整備管理者Ｍは、整備管理者端末４に表示された運行前車両判定データＤ５を確認の上、点検に係る判定結果に、閾値を超えた項目や、所定の故障コード、ランプ・ウォーニング等の点灯、異常・警告等が検出されている項目や、ドライバーによってチェックがなされた項目がある場合において、当該車両Ｃの運行が不可能と判断した場合に不承認として、これを操作部４２を用いて入力し、当該車両Ｃの運行が可能と判断した場合に承認として、これを操作部４２を用いて入力する。
【００８６】
（ステップＳ３−６：管理サーバへの送信）
ステップＳ３−５において、整備管理者Ｍによって承認又は不承認の入力がなされると、整備管理者端末４の制御部４１は、承認又は不承認の結果に係る情報（運行前点検結果データＤ６とする。）を、通信部４５から、通信ネットワークＮを介して、管理サーバ６へと送信する。すなわち、通信部４５が、本発明における第５送信手段として機能する。
管理サーバ６は、通信部６２によって運行前点検結果データＤ６を受信する。運行前点検結果データＤ６を受信すると、管理サーバ６は、運行前点検が終了した旨の通知を、通信部６２から、通信ネットワークＮを介して、ドライバー端末２へと送信する。
【００８７】
｛（４）ステップＳ４：運行前点呼｝
運行前点検が終了し、ドライバー端末２に、管理サーバ６から、運行前点呼が終了した旨の通知が送信されると、通信部２５によってこれを受信したドライバー端末２においては、当該通知を、表示部２３に表示する。これを確認すると、ドライバーＴは、ドライバー端末２において、操作部２２を用いて、運行前点呼プログラム２４４を立ち上げる。これによって、運行前点呼が開始される。具体的には以下のとおりである。
【００８８】
（ステップＳ４−１：運行前ドライバー状態データの取得｝
運行前点呼プログラム２４４が起動されると、まず、車載器１によって、点呼に必要な運行前ドライバー状態データＤ７、すなわち、アルコールデータＤ７−１、体温データＤ７−２及び血圧データＤ７−３が取得された上で、ドライバー端末２へと送信される。
【００８９】
具体的には、まず、アルコールチェッカー１１は、アルコール検出部１１１によってドライバーＴの呼気に含まれるアルコール濃度に係る情報であるアルコールデータＤ７−１を取得の上、通信部１１２からドライバー端末２へと送信する。
【００９０】
生体センサ１２のうち体温センサ１２１は、体温検出部１２１１によってドライバーＴの体温に係る情報である体温データＤ７−２を取得の上、通信部１２１２からドライバー端末２へと送信する。
また、生体センサ１２のうち血圧センサ１２２は、血圧検出部１２２１によってドライバーＴの血圧に係る情報である血圧データＤ７−３を取得の上、通信部１２２２から、ドライバー端末２へと送信する。
【００９１】
また、ドライバーＴは、ドライバー端末２の記憶部２４に備えられた点呼フォーム２４５を用いて、上記のような所定の点呼項目について入力する。具体的には、ドライバーＴは、点呼フォーム２４５に記載された所定の項目につき、問題のある項目がある場合に操作部２２を用いてチェックをつける形で、所定の点呼項目についての入力を行う。
【００９２】
（ステップＳ４−２：運行前ドライバー状態データに基づく判定）
続いて、運行前ドライバー状態データＤ７を通信部２５によって取得したドライバー端末２において、制御部２１によって、運行前ドライバー状態データＤ７に基づく判定がなされる。すなわち、制御部２１が、本発明における第３判定手段として機能することとなる。
【００９３】
具体的には、まずドライバー端末２の制御部２１は、記憶部２４に備えられた運行前点呼プログラム２４４を用いて、アルコールチェッカー１１から通信部２５によって取得したアルコールデータＤ７−１と、記憶部２４に備えられた閾値情報記憶部２４７に記憶された閾値データＤ１５に含まれるアルコール濃度に関する閾値情報と、を対比し、ドライバーＴの呼気に含まれるアルコール濃度が所定の閾値を超えていないかを判定する。
【００９４】
続いて、ドライバー端末２の制御部２１は、記憶部２４に備えられた運行前点呼プログラム２４４を用いて、生体センサ１２のうち体温センサ１２１から通信部２５によって取得した体温データＤ７−２と、記憶部２４に備えられた閾値情報記憶部２４７に記憶された閾値データＤ１５に含まれる体温に関する閾値情報と、を対比し、ドライバーＴの体温が、所定の閾値を超えていないかを判定する。
【００９５】
また、ドライバー端末２の制御部２１は、記憶部２４に備えられた運行前点呼プログラム２４４を用いて、生体センサ１２のうち血圧センサ１２２から通信部２５によって取得した血圧データＤ７−３と、記憶部２４に備えられた閾値情報記憶部２４７に記憶された閾値データＤ１５に含まれる血圧に関する閾値情報と、を対比し、ドライバーＴの血圧が、所定の閾値を超えていないかを判定する。
【００９６】
続いて、ドライバー端末２の制御部２１は、記憶部２４に備えられた運行前点呼プログラム２４４を用いて、ドライバーＴによって入力された点呼フォーム２４５に、チェックがなされた項目がないかについて判定する。
【００９７】
（ステップＳ４−３：管理サーバへの送信）
ステップＳ４−２の判定がなされると、ドライバー端末２の制御部２１は、ステップＳ４−２における判定結果に係る情報である運行前ドライバー判定データＤ８を、通信部２５から、通信ネットワークＮを通じて、管理サーバ６へと送信する。すなわち、通信部２５が、本発明における第６送信手段として機能することとなる。
また、この時、ドライバー端末２は、通信部２５から、通信ネットワークＮを通じて、運行管理者端末３に対して、点呼実施依頼を送信する。
【００９８】
（ステップＳ４−４：点呼記録簿データの作成）
通信部６２によって運行前ドライバー判定データＤ８を受信した管理サーバ６においては、制御部６１が、運行前ドライバー判定データＤ８と、ステップＳ３−６において受信した運行前点検結果データＤ６と、車両Ｃが過去に運行されていない新車である場合を除いて、前回の運行時における後述のステップＳ６及びステップＳ７において車両Ｃの運行後に取得された次回運行可否データＤ１３及び整備予定日時データＤ１４と、から、点呼記録簿作成プログラム６３６を用いて、点呼記録簿データＤ９を作成する。すなわち、制御部６１が、本発明における点呼記録簿生成手段として機能することとなる。
これによって、点呼記録簿データＤ９には、氏名等ドライバーＴを特定できる情報及びナンバー等の車両Ｃを特定できる情報と共に、運行前点検における整備管理者の承認／不承認の結果と、運行前点呼におけるドライバー端末２による所定の項目に係る判定結果と、前回の運行後になされた整備工場Ｆの整備士Ｓによる次回運行の可否に係る判定の結果と、前回の運行後に次回の運行が不可と判定された車両Ｃについての整備予定日時と、が記録されることとなる。
【００９９】
（ステップＳ４−５：運行管理者端末への送信）
点呼記録簿データＤ９が作成されると、管理サーバ６の制御部６１は、点呼記録簿データＤ９を、通信部６２から、通信ネットワークＮを通じて、運行管理者端末３へと送信する。すなわち、通信部６１が、本発明における第１送信手段として機能することとなる。
【０１００】
（ステップＳ４−６：点呼の実施）
点呼記録簿データＤ９を通信部３５によって受信した運行管理者端末３においては、制御部３１が、点呼記録簿データＤ９を受信した旨の通知を、表示部３３に表示する。
これを確認した運行管理者Ｏは、所定のログインＩＤ及びパスワードを、運行管理者端末３の操作部３２を用いて入力することで、車両整備管理システム１００へのログインを行う。入力を受けた運行管理者端末３においては、入力内容を運行管理者情報記憶部３４１の記憶内容と対照し、一致した場合にログインを認める。
運行管理者Ｏがログインすると、運行管理者端末３は、制御部３１が、表示部３３に、点呼記録簿データＤ９を表示する。
【０１０１】
運行管理者端末３の表示部３３に点呼記録簿データＤ９が表示されると、運行管理者Ｏは、運行管理者端末３から通信ネットワークＮを通じてドライバー端末２にアクセスし、ドライバーＴとの通話状態を確立するとともに、ドライバー端末２の映像取得部２６を通じて、ドライバーＴの映像をリアルタイムで取得できるようにする。
【０１０２】
その上で、運行管理者Ｏは、所定の点呼作業を行うこととなるが、この際には、上記のように、既に点呼記録簿データＤ９として、運行前点検における整備管理者の承認／不承認の結果と、運行前点呼におけるドライバー端末２による所定の項目に係る判定結果と、前回の運行後になされた整備工場Ｆの整備士Ｓによる次回運行の可否に係る判定の結果と、が表示部３３に表示されているため、運行管理者Ｏは、これらの項目について逐一ドライバーＴに確認すること要しない。
したがって、運行管理者Ｏは、点呼に係る判定結果に、閾値を超えた項目や、ドライバーＴによって問題があるものとしてチェックがなされた項目がある場合に、ドライバーＴの変更の必要がある旨を操作部３２を用いて入力して不承認とし、また、運行前点検において整備管理者Ｍが不承認とした場合及び前回の運行後になされた整備工場Ｆの整備士Ｓによる次回運行の可否に係る判定の結果において運行不可となっていた場合に、車両Ｃの変更の必要がある旨を操作部３２を用いて入力して不承認とし、それ以外の問題のない場合に、承認する旨を操作部３２を用いて入力すれば足りる。
【０１０３】
操作部３２を用いて入力された承認／不承認に係る判断結果に係る情報（運行前点呼結果データＤ１０とする。）は、通信部３５から、通信ネットワークＮを介して、ドライバー端末２及び管理サーバ６へと送信される。
運行前点呼結果データＤ１０を通信部２５によって受信したドライバー端末２においては、制御部２１が、これを表示部２３に表示する。
また、運行前点呼結果データＤ１０を通信部６２によって受信した管理サーバ６においては、制御部６１が、これを点呼記録簿データＤ９に追加する形で記憶部６３に記憶する。
【０１０４】
上記承認がなされると、車両Ｃの運行が可能となり、ドライバー端末２の表示部２３に表示された承認の表示を確認したドライバーＴは、車両Ｃを出庫させる。
不承認となった場合には、ステップＳ２に戻り、運行管理者Ｏは、ドライバーＴの交代及び／又は車両Ｃの交換を行い、改めて配車作業を行うこととなる。
｛（５）ステップＳ５：運行後点検｝
その日の運行が終了し、車両Ｃが車庫に戻ると、運行後点検が実施される。具体的には以下のとおりである。
【０１０５】
（ステップＳ５−１：運行後ドライバーのログイン）
車両Ｃの運行を行うドライバーＴは、運行終了後、その日に自らが使用した車両Ｃに乗車した状態で、これを車庫内の所定の点検場所に停車させた上で、ドライバー端末２において運行後点検プログラム２４３を起動し、免許証のＩＣチップによるドライバーＴの特定を行った上で、所定のログインＩＤ及びパスワードをドライバー端末２の操作部２２を用いて入力することで、車両整備管理システム１００へのログインを行う。入力を受けたドライバー端末２においては入力内容をドライバー情報記憶部２４１の記憶内容と対照し、一致した場合にログインを認める。
【０１０６】
（ステップＳ５−２：運行後車両状態データの取得）
続いて、車載器１によって、点検に必要な運行後車両状態データＤ１１、すなわち、運行後故障データＤ１１−１及び運行後空気圧データＤ１１−２が取得された上で、ドライバー端末２へと送信される。
【０１０７】
具体的には、まず、故障診断機１３の故障診断機本体１３１は、診断部１３１１によって、上記のような車両Ｃの故障の有無に関する情報である運行後故障データＤ１１−１を取得の上、通信部１３１２からドライバー端末２へと送信する。
【０１０８】
また、タイヤセンサ１４は、空気圧測定部１４１によって車両Ｃのタイヤの空気圧に関する情報である運行後空気圧データＤ１１−２を取得の上、通信部１４２からドライバー端末２へと送信する。
【０１０９】
また、ドライバーＴは、ドライバー端末２の記憶部２４に備えられた点検フォーム２４６を用いて、上記のような所定の点検項目について入力する。具体的には、ドライバーＴは、点検フォーム２４６に記載された所定の項目につき、問題のある項目がある場合に操作部２２を用いてチェックをつける形で、所定の点検項目についての入力を行う。
【０１１０】
（ステップＳ５−３：運行後車両状態データに基づく判定）
続いて、運行後車両状態データＤ１１を通信部２５によって取得したドライバー端末２において、制御部２１によって、運行後車両状態データＤ１１に基づく判定がなされる。すなわち、制御部２１が、本発明における第１判定手段として機能することとなる。
【０１１１】
具体的には、まずドライバー端末２の制御部２１は、記憶部２４に備えられた運行後点検プログラム２４３を用いて、故障診断機１３から通信部２５によって取得した運行後故障データＤ１１−１に基づき、上記のような所定の故障コード、ランプ・ウォーニング等の点灯、異常・警告等が検出されている箇所がないかを判定する。
【０１１２】
続いて、ドライバー端末２の制御部２１は、記憶部２４に備えられた運行後点検プログラム２４３を用いて、タイヤセンサ１４から通信部２５によって取得した運行後空気圧データＤ１１−２と、記憶部２４に備えられた閾値情報記憶部２４７に記憶された閾値データＤ１５に含まれるタイヤの空気圧に関する閾値情報と、を対比し、車両Ｃのタイヤの空気圧が基準値の８０％以下となっていないかを判定する。
【０１１３】
続いて、ドライバー端末２の制御部２１は、記憶部２４に備えられた運行後点検プログラム２４３を用いて、ドライバーＴによって入力された点検フォーム２４６にチェックがなされた項目がないかについて判定する。
【０１１４】
（ステップＳ５−４：管理サーバへの送信）
ステップＳ５−３の判定がなされると、ドライバー端末２の制御部２１は、ステップＳ５−３における判定結果に係る情報である運行後車両判定データＤ１２を、通信部２５から、通信ネットワークＮを通じて、管理サーバ６へと送信する。すなわち、通信部２５が、本発明における第２送信手段として機能することとなる。
【０１１５】
｛（６）ステップＳ６：次回運行可否の判定｝
管理サーバ６が、通信部６２によって、運行後車両判定データＤ１２を受信すると、続いて、車両Ｃの次回（多くは翌日）の運行の可否の判定がなされる。
具体的には以下のとおりである。
【０１１６】
（ステップＳ６−１：整備工場端末への送信）
管理サーバ６の制御部６１は、ステップＳ５−４において、運行後車両判定データＤ１２を受信すると、これを、通信部６２から、整備工場端末７へと送信する。すなわち、通信部６２が、本発明における第３送信手段として機能することとなる。
通信部７５によって運行後車両判定データＤ１２を受信した整備工場端末７においては、制御部７１が、これを表示部７３に表示する。
【０１１７】
（ステップＳ６−２：次回運行可否の判定）
表示部７３に運行後車両判定データＤ１２が表示されると、これを元に、整備工場Ｆの整備士Ｓが、車両Ｃの次回の運行の可否について判定する。具体的には、以下の５段階の判定を行い、判定結果である次回運行可否データＤ１３を、操作部７２を用いて入力する。
すなわち、例えば故障診断機１３によって故障コード等が検出されていても、即時の整備が必要な場合もあれば、ひとまず運行の上で問題はなく、後日の整備で足りる場合もある。したがって、故障コード等が検出された場合に必要となる対応は様々であり、全ての故障コード等に対して一律には対応できない。
そこで、このステップで、整備士Ｓによって、運行後車両判定データＤ１２に基づき、車両Ｃにつき、故障に対する整備を行わずに次回の運行が可能であるかが判定され、車両Ｃに対してとられるべき対応が決定されることとなる。
【０１１８】
具体的には、整備士Ｓによって、例えば、以下の５段階の判定がなされ、これら１から５のいずれに該当するかが、次回運行可否データＤ１３として、整備士Ｓによって入力されることとなる。
１  運行不可（要整備）
次回の運行が不可能で、かつ即時の整備が必要な状態である場合。
例えば、車両を動かすことが出来ない状態である場合や、過去の整備実績に鑑みて、車両を動かすことによって路上故障の発生リスクが高いことが想定される場合等である。
２  運行不可（ユーザ（運送事業者Ｕ）からのヒアリングが必要）
次回の運行が不可能で、かつ整備の要否については、運送事業者Ｕからのヒアリングの上決定することを要する場合。
例えば、整備士Ｓとしては、故障コード等の内容及び過去の整備実績に鑑みて、運行不可と判断するが、運送事業者Ｕ側で実車を見て、後述のヒアリングを行った結果次第では、整備が不要となる可能性があり、整備の要否の判断をヒアリングの上行うことを要する場合等である。
３  運行可（ユーザ（運送事業者Ｕ）からのヒアリングが必要）
次回の運行は可能で、かつ整備の要否については、運送事業者Ｕからのヒアリングの上決定することを要する場合。
例えば、整備士Ｓとしては、故障コード等の内容及び過去の整備実績に鑑みて、運行可と判断するが、運送事業者Ｕ側で実車を見て、後述のヒアリングを行った結果次第では、整備が必要となる可能性があり、整備の要否の判断をヒアリングの上行うことを要する場合等である。
４  運行可（次回の３か月定期点検又は車検時に実車確認が必要）
次回の運行は可能で、かつ当面の整備は要しないが、次回の３か月定期点検又は車検時に実車の確認が必要な場合。
例えば、整備士Ｓによって、故障コード等の内容から軽微な故障であると判断でき、乗車に問題は無いが、次回の定期点検又は車検時には状況を確認することを要する場合等である。
５  運行可（異常なし）
全く整備を要する可能性のある異状が発見されない場合。
【０１１９】
なお、運行可否の判定は、必ずしも整備工場Ｆの整備士Ｓによってなされる必要はなく、予め、運行後車両判定データＤ１２と次回運行の可否に係る判定結果との相関関係を示すテーブルを設ける、機械学習によるＡＩを利用する等の方法により、管理サーバ６、整備工場端末７又はその他の所定のサーバにおいて、自動的になされるようにしてもよい。
【０１２０】
（ステップＳ６−３：管理サーバへの送信）
整備士Ｓによって次回運行可否データＤ１３が入力されると、整備工場端末７の制御部７１は、これを通信部７５から、通信ネットワークＮを介して、管理サーバ６へと送信する。整備工場端末７から次回運行可否データＤ１３が送信されると、管理サーバ６は、通信部６２によって次回運行可否データＤ１３を受信する。すなわち、通信部６２が、本発明における第１取得手段として機能することとなる。
【０１２１】
｛（７）ステップＳ７：整備予定日時の特定｝
次回運行可否データＤ１３を通信部６２によって受信した管理サーバ６においては、続いて、運行不可、すなわち、ステップＳ６−２で、段落０１１８における５段階の１又は２と判定された車両Ｃについて、故障に対する整備を実施する整備予定日時の特定がなされる。
具体的には以下のとおりである。
【０１２２】
まず、制御部６１は、記憶部６３に備えられた整備日時特定プログラム６３７を用いて、記憶部６３の運送事業者データベース６３２に記憶された運送事業者データＤ２の車両稼働データＤ２−２から、当該車両Ｃにつき、稼働予定が入っておらず、整備可能な日時につき特定する。
【０１２３】
続いて、制御部６１は、整備日時特定プログラム６３７を用いて、記憶部６３の整備実施可能日時データベース６３１に記憶された整備実施可能日時データＤ１から、整備工場Ｆにつき、整備実施可能な日時を特定する。
【０１２４】
その上で、制御部６１は、整備日時特定プログラム６３７を用いて、当該車両Ｃの整備可能日時と、整備工場Ｆの整備実施可能日時とを対比の上、これらが一致する日時を、当該車両Ｃの整備予定日時として特定する。なお、特定された整備予定日時に係る情報を、整備予定日時データＤ１４とする。すなわち、制御部６１が、本発明における第２取得手段として機能することとなる。
なお、車両Ｃの整備可能日時と、整備工場Ｆの整備実施可能日時とが一致する日時が複数存在する場合には、そのうち直近の日時を、整備予定日時として特定する。
【０１２５】
制御部６１は、車両Ｃの整備予定日時が特定され、整備予定日時データＤ１４が生成されると、同一の車両Ｃについての次回運行可否データＤ１３と整備予定日時データＤ１４とを関連付けて、記憶部６３の運行可否・整備日時データベース６３５に記憶する。
【０１２６】
運行可否・整備日時データベース６３５に次回運行可否データＤ１３と整備予定日時データＤ１４とが記憶されると、これを次回の運行前の点呼記録簿データＤ９に反映させることが可能となる。これによって、当該車両Ｃの次回運行時の運行前点呼におけるステップＳ４−４へとつながることとなり、ステップＳ４−５において、点呼記録簿データＤ９に反映された次回運行可否データＤ１３及び整備予定日時データＤ１４が、運行管理者端末３へと送信されることとなる。
また、整備予定日時データＤ１４は、管理サーバ６の通信部６２から、整備工場端末７へも送信され、整備工場端末７においては、制御部７１が、これを表示部７３に表示し、整備士Ｓ等に、特定された整備日時を通知することとなる。
【０１２７】
なお、整備予定日時の特定は、上記のように管理サーバ６によって行われることが望ましいが、これに限られず、例えば、整備工場端末７や、その他の所定のサーバ、端末等によって行われるようにし、生成された整備予定日時データＤ１４を、管理サーバ６が、通信部６２によって、通信ネットワークＮを介して取得するようにしてもよい。この場合、通信部６２が、本発明における第２取得手段として機能することとなる。
【０１２８】
｛（８）ステップＳ８：ヒアリングの実施｝
ステップＳ６−２で、段落０１１８における５段階の２又は３と判定された車両Ｃについては、後日、運送事業者Ｕ、具体的には、運送事業者Ｕに所属する者のうち、ドライバーＴ、運行管理者Ｏ又は整備管理者Ｍ等の当該車両Ｃを実際に確認できる者から、整備工場Ｆの整備士Ｓが直接話を聞き、実車の状況、すなわち異音等の異常がないかにつき確認させる。
【０１２９】
ステップＳ６−２で、段落０１１８における５段階の２と判定されたケースについては、ヒアリングの結果、予定通り整備が必要であるということとなれば、ステップＳ７において特定された整備予定日時の通りに整備が実施されることとなる。
これに対し、ヒアリングの結果として、整備は不要という結論となった場合には、ステップＳ７において特定された整備予定日時における整備の実施がキャンセルされ、当該車両Ｃは、再び運行に戻ることとなる。
【０１３０】
ステップＳ６−２で、段落０１１８における５段階の３と判定されたケースについては、ヒアリングの結果、整備は不要であるということとなれば、当該車両はそのまま運行に用いられ続けることとなる。
これに対し、ヒアリングの結果として、整備が必要という結論となった場合には、ヒアリング後の適宜の日程において、整備が実施されることとなる。
この場合も、整備士Ｓが、ヒアリングの結果として整備が必要という結論となったという旨を整備工場端末の操作部７２を用いて入力すると、これが通信部７５から通信ネットワークＮを介して管理サーバ６に送信され、通信部６２によってこれを受信した管理サーバ６において、制御部６１が、整備日時特定プログラム６３７を用いて、自動的に整備予定日時を特定することが望ましい。なお、この場合も、整備予定日時の特定は、管理サーバ６によって行われることが望ましいが、これに限られず、整備工場端末７や、その他の所定のサーバ、端末等によって行われ、特定結果を、管理サーバ６が、通信部６２によって取得するようにすることも可能である。
【０１３１】
｛（９）ステップＳ９：整備の実施｝
ステップＳ６−２で段落０１１８における５段階の１と判定された場合、ステップＳ６−２で段落０１１８における５段階の２と判定され、かつステップＳ８のヒアリングの結果として整備が必要という結論となった場合、及びステップＳ６−３で段落０１１８における５段階の３と判定され、かつステップＳ８のヒアリングの結果として整備が必要という結論となった場合には、当該車両Ｃに対して、整備工場Ｆにおいて、故障整備が実施されることとなる。
【０１３２】
［３  効果の説明］
実施形態に係る車両整備管理システム１００によれば、車両Ｃの故障の発見及び次回の運行の可否の判断を、当該車両Ｃの運行後に行い、次回（多くは翌日）の運行前には、当該車両Ｃの次回の運行の可否が明らかとなっていることから、車両Ｃの運行開始前に、故障した車両Ｃの交換等の適切な対応を採ることができ、予期せぬ車両の稼働停止が生じ、運送事業者Ｕの業務に影響が生じるおそれを低減できる。
【０１３３】
また、故障に対する整備が必要となる車両Ｃについては、整備予定日時の特定までがなされることから、適切な日時で、迅速に整備を実施することが可能となる。
【０１３４】
また、車両Ｃの前回運行後の点検に基づく次回の運行の可否に係る情報である次回運行可否データＤ１３及び整備が必要となる車両についての整備予定日時に係る情報である整備予定日時データＤ１４が、運行前点呼実施時に、点呼記録簿データＤ９に予め反映されていることから、運行管理者Ｏは、点呼記録簿データＤ９を確認するのみで次回運行可否データＤ１３及び整備予定日時データＤ１４を確認できることから、運行管理者Ｏの負担を低減できる。
【０１３５】
また、点呼記録簿データＤ９に、運行前の点検の結果に係る情報である運行前点検結果データＤ６及びドライバーＴの健康状態に関する所定の項目についての判定結果である運行前ドライバー判定データＤ８も予め反映されていることで、運行管理者Ｏは、点呼記録簿データＤ９を確認するのみで、運行前点検結果データＤ６及び運行前ドライバー判定データＤ８まで確認できることから、運行管理者Ｏの負担をさらに低減できる。
【０１３６】
また、次回運行可否データＤ１３が、前回運行後の点検に基づく次回運行の可否のみならず、運送事業者Ｕに対するヒアリングの要否についての情報を含むことで、整備の要否が微妙なケースについても、ヒアリングの実施により、適切な対処を行うことが容易となる。
【符号の説明】
【０１３７】
１００  車両整備管理システム
１  車載器
２  ドライバー端末
２１  制御部（第１判定手段、第２判定手段、第３判定手段）
２５  通信部（第２送信手段、第４送信手段、第６送信手段）
３  運行管理者端末
４  整備管理者端末
４５  通信部（第５送信手段）
６  管理サーバ（車両整備管理装置）
６１  制御部（第２取得手段、点呼記録簿生成手段）
６２  通信部（第１取得手段、第２取得手段、第１送信手段、第３送信手段）
７  整備工場端末
Ｃ  車両
Ｔ  ドライバー
Ｏ  運行管理者
Ｍ  整備管理者
Ｕ  運送事業者（ユーザ）
Ｆ  整備工場
Ｄ１  整備実施可能日時データ
Ｄ２−２  車両稼働データ
Ｄ４  運行前車両状態データ
Ｄ５  運行前車両判定データ
Ｄ６  運行前点検結果データ
Ｄ７  運行前ドライバー状態データ
Ｄ８  運行前ドライバー判定データ
Ｄ９  点呼記録簿データ
Ｄ１１  運行後車両状態データ
Ｄ１２  運行後車両判定データ
Ｄ１３  次回運行可否データ
Ｄ１４  整備予定日時データ
【図１】
2020166560.tif 000003
【図２】
2020166560.tif 000004
【図３】
2020166560.tif 000005