JP2018185662A - 車両保守計画装置、及び車両保守計画評価方法 - Google Patents

Abstract

【課題】車両の稼働に伴う事象から適切に保守計画を評価する技術の提供を目的とする。【解決手段】車両保守計画装置であって、運送会社と１又は複数の車両とを関連付けた運送会社情報と、整備会社と車両とを関連付けた整備会社情報と、車両と１又は複数の系統及び整備方式とを関連付けた車両情報と、を取得する条件情報取得部と、運送会社に割り当てる運送タスク情報を生成する運送タスク生成部と、運送タスク情報を用いて車両の系統毎に信号値を算出する信号値取得部と、整備方式及び信号値を用いて車両の整備に関する修理タスク情報を生成し、整備会社に割り当てる修理タスク生成部と、運送タスク情報を用いて運送料金を算出するとともに、修理タスク情報を用いて整備料金を算出する集計計算部と、運送料金及び整備料金を含む保守計画評価情報を生成する保守計画評価部と、保守計画評価情報を出力する出力部と、を備えることを特徴とする。【選択図】 図１

Description

本発明は、車両保守計画装置、及び車両保守計画評価方法に関する。

特許文献１には、作業機械の機器診断装置に関する技術が開示されている。同文献の段落［００３１］には、「データ判定部１０１は、機器情報１２１が入力されているかを判定する（Ｓ２０１）。機器情報１２１が入力されている場合には、動作条件データ記憶部１１１ａを参照して機器情報１２１の動作条件情報と一致する動作条件情報があるか否かを判定する（Ｓ２０２）。一致するものが検出された場合には、入力された機器情報１２１を状態診断部１０３に出力し、状態診断部１０３では、診断データベース１１１を参照して機器情報１２１の診断を行い（Ｓ２０３）、診断結果を外部の表示装置等に出力する（Ｓ２０４）。」と記載されている。なお、例えば同文献の段落［０１１６］には、「エンジン４０の性能が低下すると、エンジン回転数が下がる。したがって、エンジン回転数を監視することによりエンジン４０の性能低下（異常）を診断することができる。」と記載されている。

特許第５２２７９５７号

運送に用いられる車両は、稼働することで利益を生むが、同時に劣化が生じる。運送会社にとって、稼働によって生じる費用と収益とをシミュレーションし、保守計画を評価することが望ましい。また他方において、車両の整備会社にとっても、車両の劣化から生じる収益や費用をシミュレーションし、保守計画の評価に用いることが望まれる。

本発明は、上記の点に鑑みてなされたものであって、車両の稼働に伴う事象から適切にビジネスを評価する技術の提供を目的とする。

本願は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下の通りである。

上記課題を解決するため、本発明の一態様に係る車両保守計画装置は、運送会社と１又は複数の車両とを関連付けた運送会社情報と、整備会社と整備を行う前記車両とを関連付けた整備会社情報と、前記車両と当該車両の有する１又は複数の系統及び整備方式とを関連付けた車両情報と、を取得する条件情報取得部と、前記運送会社に割り当てる運送タスク情報を生成する運送タスク生成部と、前記運送タスク情報を用いて前記車両の系統毎に信号値を算出する信号値取得部と、前記整備方式及び前記信号値を用いて前記車両の整備に関する修理タスク情報を生成し、前記整備会社に割り当てる修理タスク生成部と、前記運送タスク情報を用いて運送料金を算出するとともに、前記修理タスク情報を用いて整備料金を算出する集計計算部と、前記運送料金及び前記整備料金を含む保守計画評価情報を生成する保守計画評価部と、前記保守計画評価情報を出力する出力部と、を備えることを特徴とする。

また、本発明の他の態様に係る車両保守計画評価方法は、車両保守計画装置が行う車両保守計画評価方法であって、前記車両保守計画装置は、条件情報取得部と、運送タスク生成部と、信号値取得部と、修理タスク生成部と、集計計算部と、保守計画評価部と、出力部と、を備え、前記条件情報取得部は、運送会社と１又は複数の車両とを関連付けた運送会社情報と、整備会社と整備を行う前記車両とを関連付けた整備会社情報と、前記車両と当該車両の有する１又は複数の系統及び整備方式とを関連付けた車両情報と、を取得する条件情報取得手順を実行し、前記運送タスク生成部は、前記運送会社に割り当てる運送タスク情報を生成する運送タスク生成手順を実行し、前記信号値取得部は、前記運送タスク情報を用いて前記車両の系統毎に該系統の信号値を算出する信号値取得手順を実行し、前記修理タスク生成部は、前記整備方式及び前記信号値を用いて前記車両の整備に関する修理タスク情報を生成し、前記整備会社に割り当てる修理タスク生成手順を実行し、前記集計計算部は、前記運送タスク情報を用いて運送料金を算出するとともに、前記修理タスク情報を用いて整備料金を算出する集計計算手順を実行し、前記保守計画評価部は、前記運送料金及び前記整備料金を含む保守計画評価情報を生成する保守計画評価手順を実行し、前記出力部は、前記保守計画評価情報を出力する表示手順を実行することを特徴とする。

本発明によれば、車両の稼働に伴う事象から適切にビジネスを評価することができる。

上記した以外の課題、構成、及び効果は、以下の実施形態の説明により明らかにされる。

車両保守計画システムの概要を説明するための図である。 車両保守計画装置の機能ブロック図の一例を示す図である。 系統の一例を示す図である。 車両保守計画装置のハードウェア構成例を示す図である。 シミュレーション処理の一例を示すフローチャートである。 シミュレーション条件入力画面の一例を示す図である。 運送タスクの概要の一例を示す図である。 始点及び終点の設定方法の一例を説明するための図である。 １日間に１つの運送タスク情報が割り当てられている場合のスケジューリングの一例を示す。 ３日間に１つの運送タスク情報が割り当てられている場合のスケジューリングの一例を示す。 異常検知処理及び予知メンテナンススケジューリング処理の概要を示す図である 予知メンテナンスの概要を説明するための図（その１）である。 修理タスク生成部により実行される予知メンテナンスのスケジューリング処理の一例を示すフローチャートである。 予知メンテナンスの概要を説明するための図（その２）である。 予知メンテナンスのスケジューリング処理の一例を示す図である。 保守計画評価画面の一例を示す図である。 運送会社の有する車両の予定を含む保守計画評価画面の一例を示す図である。 能力消費の状態を示す保守計画評価画面の一例を示す図である。 異常検知の誤りの問題点を説明するための図である。 虚報見逃し誤り判定処理の概要を示す図である。 真状態情報と誤状態情報の組合せに対する、異常検知と予知メンテナンスの意味の対応表の一例を示す図である。

以下、図面に基づいて本発明の実施形態の例を説明する。図１は、車両保守計画システムの概要を説明するための図である。車両保守計画システムは、車両２０２を有する運送会社２０１と、整備会社２０３と、サービス会社２０４と、を含む事業体により相互に提供されるサービスを評価するために用いられる。

運送会社２０１は、運送業務を請け負う会社であって、１又は複数の車両２０２を有している。車両２０２は、いずれかの運送会社２０１に所属し、運送業務を行う。整備会社２０３は、車両２０２を整備する会社である。サービス会社２０４は、各車両２０２の劣化状況を監視し、劣化状況を該車両２０２の属する運送会社２０１に通知するサービスを行っている。

運送会社２０１が運送業務を請け負うと、いずれかの車両２０２に運送業務を割り当てる。車両２０２の行う運送業務は、車両２０２が運送会社２０１を出発した時に開始し、引取地（始点）で荷物を受け取り、目的地（終点）まで運送し、運送会社２０１に帰社することで終了する。

運送会社２０１は、各車両２０２に対し複数の整備方式のうち少なくとも１つの整備方式を採用している。整備方式は、例えば定期メンテナンス、予知メンテナンス、又は修理である。定期メンテナンスは、定期的に車両２０２を整備会社２０３に整備させる整備方式である。予知メンテナンスは、サービス会社２０４と契約し、該運送会社２０１の有する車両２０２について算出された信号値が所定値以上である場合に、整備会社２０３に整備させる整備方式である。修理は、故障した車両２０２を事後的に整備会社２０３に整備させる整備方式である。運送会社２０１は、例えば車両２０２毎に、採用する整備方式を特定している。

図示しない車両保守計画装置は、運送会社２０１の有する車両２０２や、車両２０２を整備する整備会社２０３、車両２０２に採用される整備方式等を特定したシミュレーション条件の入力を受け付ける。車両保守計画装置は、始点、終点及び荷物の重量に関する情報を含む運送タスク情報を生成し、各車両２０２に割り当てる。車両保守計画装置は、各車両２０２が運送タスク情報に係る運送タスクを実行した場合の車両２０２の劣化度を算出し、運送料金や整備料金を算出する。車両保守計画装置は、該運送料金及び整備料金を含む保守計画評価情報を出力する。

これにより、車両２０２の整備に関する契約内容や、受け付ける運送タスクの状況に応じて、運送会社２０１や整備会社２０３等の費用や収益を含む保守計画評価を適切に行うことが可能となる。

図２は、車両保守計画装置１の機能ブロック図の一例を示す図である。車両保守計画装置１は、ＰＣ、サーバーコンピュータ、又はスマートフォン等の情報処理装置である。車両保守計画装置１は、シミュレーションを行うサービスを提供する事業者の管理範囲内に設置される。

車両保守計画装置１は、制御部１１０と、入力部１２０と、出力部１３０と、通信部１４０と、記憶部１５０と、を備える。制御部１１０は、車両保守計画装置１全体を統括的に制御する。入力部１２０は、キーボードやタッチパネル等の後述する入力装置を介して、情報の入力を受け付ける。出力部１３０は、後述する出力装置を介して情報の出力を行う。例えば、出力部１３０は、保守計画評価情報をディスプレイ等の表示装置に表示させる。通信部１４０は、ネットワークを介して接続される他の端末装置との間で情報の受信や送信を行う。

制御部１１０は、条件情報取得部１１１と、運送タスク生成部１１２と、修理タスク生成部１１３と、異常検知部１１４と、信号値取得部１１５と、保守計画評価部１１６と、集計計算部１１７と、を備える。条件情報取得部１１１は、車両保守サービスのシミュレーションに用いる各情報を、例えば通信部１４０を介して接続された他の端末装置から取得する。条件情報取得部１１１は、入力部１２０を介して情報を取得してもよい。条件情報取得部１１１は、取得した情報を記憶部１５０に記憶させる。

また、条件情報取得部１１１は、入力部１２０又は通信部１４０を介して入力されたシミュレーション条件を取得する。シミュレーション条件については後述する。

運送タスク生成部１１２は、各車両２０２に割り当てる運送タスクに関する運送タスク情報を生成する。詳細は後述するが、運送タスク情報には、例えば荷物の引取地と、目的地と、荷物の重量とが特定されている。一例として、運送タスク生成部１１２は、引取地を示す始点座標と、目的地を示す終点座標と、荷物の重量と、の少なくとも１つに対し一様乱数を用い、運送タスク情報を生成する。

なお、引取地及び目的地を示す情報の代わりに、走行距離を示す情報が運送タスク情報に含まれていてもよい。また、運送タスク情報に含まれる目的地、引取地及び荷物の重量は、入力部１２０又は通信部１４０を介して入力されてもよい。運送タスク生成部１１２は、生成した運送タスク情報を記憶部１５０に記憶させる。

また、運送タスク生成部１１２は、生成した運送タスク情報を車両２０２に割り当てる。具体的には、運送タスク生成部１１２は、運送タスク情報を後述の車両カレンダーの空き領域に割り当て、車両カレンダーを更新する。

修理タスク生成部１１３は、車両２０２の整備に関する情報である修理タスク情報を生成する。修理タスク生成部１１３は、車両２０２に対しシミュレーション条件として入力された整備方式を特定し、整備方式に応じた修理タスク情報を生成する。修理タスク生成部１１３は、生成した修理タスク情報を記憶部１５０に記憶させる。修理タスク情報には、整備対象の系統と整備時期とが特定されている。

例えば、定期メンテナンスの整備方式が入力された車両２０２について、修理タスク生成部１１３は定期的に修理を行うよう整備時期を設定した修理タスク情報を生成し、後述する車両カレンダー及び整備会社カレンダーの空き領域に割り当てる。また、予知メンテナンスの整備方式が入力された車両２０２について、修理タスク生成部１１３は、後述の信号値取得部１１５により取得された信号値を用いて整備対象の車両２０２の系統及び整備時期を特定し、該系統及び整備時期を特定した修理タスク情報を生成し、車両カレンダー及び整備会社カレンダーに割り当てる。

なお、車両２０２の系統は、車両２０２を構成する原動機、操舵系、制動系といった複数の構成要素であって、車両保守計画装置１において車両２０２毎に予め関連付けられて記憶されている。

また、修理タスク生成部１１３は、整備方式に関わらず、劣化度を用いて算出される信号値が所定の閾値（以下、「第１の閾値」とする）を超える系統の車両２０２について、当該系統が故障したものとして整備時期及び整備対象の系統を特定し、修理タスク情報を生成して車両カレンダー及び整備会社カレンダーの空き領域に割り当てる。なお、修理タスク生成部１１３は、修理タスク情報において整備対象の系統が定まっている場合、当該系統のパーツの在庫を有する整備会社２０３に修理タスク情報を割り当てる。

なお、修理タスク生成部１１３は、シミュレーション上、整備時期を途過した場合に、整備が終了したものとして、状態量を運送タスク情報を割り当てる前の値に戻して後述の状態量情報を更新する。

異常検知部１１４は、車両２０２の系統毎に算出された信号値を用いて該系統の状態情報を特定する。状態情報とは、車両２０２の系統の不具合の度合いを示す情報であって、信号値に応じて段階的に定められる。例えば状態情報は、「正常（Normal）」、「警告（Alert）」、「緊急（Urgent）」、及び「故障（Critical）」という４段階のいずれかを示す情報である。なお、本実施形態において、「異常の検知」とは、振動や異音等、既に現れている不具合だけでなく、例えば１００ｋｍ走行後にタイヤ劣化による不具合が生じるというような、不具合の予兆の検知をも意味する。

信号値取得部１１５は、運送タスク情報を用いて車両２０２の系統毎に劣化度を算出する。信号値取得部１１５は、例えば車両２０２の走行距離を用いて劣化度を算出する。

保守計画評価部１１６は、後述の集計計算部１１７により算出された運送料金と整備料金とを用いて保守計画評価情報を生成する。保守計画評価部１１６は、例えば所定の運送会社２０１の費用と収益とを算出し、費用及び収益を含む保守計画評価情報を生成する。また、保守計画評価部１１６は、車両２０２の稼働率を含む保守計画評価情報を生成してもよい。なお、出力部１３０が保守計画評価情報を含む画面情報を生成し、ディスプレイ等の出力装置に表示させる。

また、保守計画評価部１１６は、運送会社２０１の有する車両２０２の車両カレンダーを示す保守計画評価情報を生成してもよい。また、保守計画評価部１１６は、運送会社２０１又は整備会社２０３の能力消費の状態を示す保守計画評価情報を生成してもよい。能力消費については後述する。

集計計算部１１７は、運送タスク情報を用いて運送料金を算出する。また、集計計算部１１７は、修理タスク情報を用いて整備料金を算出する。なお、運送料金は、運送会社２０１の収益として取り扱われる。また、整備料金は、整備会社２０３の収益及び運送会社２０１の費用として取り扱われる。集計計算部１１７は、走行距離や荷物の重量等を用いて運送料金を算出する。また、集計計算部１１７は、パーツ料金や整備に要する作業時間等を用いて整備料金を算出する。

また、集計計算部１１７は、シミュレーションの対象となる保守計画評価情報の生成要求期間に対して運送タスクの割り当てられた時間を集計し、運送会社２０１や車両２０２の稼働率を算出する。また、集計計算部１１７は、整備会社２０３における整備可能台数に対する整備台数の割合を示す稼働率を算出する。

記憶部１５０は、運送会社情報１５１と、車両情報１５２と、整備会社情報１５３と、管理基準情報１５４と、劣化関数情報１５５と、車両カレンダー１５６と、整備会社カレンダー１５７と、運送タスク情報１５８と、修理タスク情報１５９と、整備内容情報１６０と、パーツ情報１６１と、整備会社パーツ在庫情報１６２と、状態量情報１６３と、を記憶している。

運送会社情報１５１は、運送会社２０１の識別子と、運送会社２０１の有する１又は複数の車両２０２の識別子とを関連付けた情報である。運送会社情報１５１は、走行距離や荷物の重量に応じた運送料金に関する情報を含んでいてもよい。本実施形態において、運送会社情報１５１は後述のシミュレーション処理時に取得される。しかしながら、シミュレーション処理開始前に予め記憶部１５０に記憶されていてもよい。

車両情報１５２は、車両２０２の識別子と、車両２０２の有する１又は複数の系統と、整備方式と、車体重量とを関連付けた情報である。また、車両情報１５２は、各系統の残寿命に関する情報を含む。車両情報１５２において、該車両２０２の有する系統と、残寿命に関する情報は、後述のシミュレーション処理の開始前に記憶部１５０に記憶されている。なお、残寿命とは、現時点から系統が故障するまでの長さをいう。残寿命は、現時点を始期とした運送可能時間と考えることができるが、日数であってもよいし、運送可能な運送タスクの数、又は走行可能な距離であってもよい。

本実施形態において、系統の整備方式に関する情報と車体重量とは、シミュレーション処理内において取得され、車両情報１５２に含められる。しかしながら、これらの情報は、シミュレーション開始前に予め車両情報１５２に含まれていてもよい。

図３は、系統の一例を示す図である。車両２０２は、運動、エネルギー変換及び消費が行われる原動機(エンジン)、かじ取り装置、吸気系、バッテリ、電気装置、プラグ、動力伝達装置(パワートレイン)、制動装置(ブレーキ系統)、走行装置(タイヤ含む)、緩衝装置、排気系等の系統により構成される。運転手が使う内装品、車体自体も系統として取り扱う。系統は、例えば原動機のピストンのようにさらに細かく定義されても良い。また電気自動車の機能を備える車両２０２は電動モータなども系統として管理され得る。トラックの荷台、またミキサー車などの各種の装置も系統となり得る。

説明を図２に戻す。整備会社情報１５３は、整備会社２０３の識別子と、整備の対象となる車両２０２（即ち整備を行う車両２０２）の識別子と、を関連付けた情報である。また、整備会社情報１５３は、整備可能な車両２０２の数の単位時間当たりの上限値と、単位時間当たりの実作業費と、単位時間当たりのメニュー価格と、を整備会社２０３毎に含む。

なお、整備会社情報１５３は、取り扱うパーツの一覧やパーツの代金等の情報を含んでいてもよい。本実施形態において、整備会社情報１５３は後述のシミュレーション処理時に取得される。しかしながら、シミュレーション処理開始前に予め記憶部１５０に記憶されていてもよい。

管理基準情報１５４は、車両２０２の系統に対し、状態情報の判定に用いる信号値の閾値を関連付けた情報である。管理基準情報１５４においては、例えば系統の１つである「原動機」に対し、状態情報が「正常」と判定される信号値の閾値と、状態情報が「警告」と判定される信号値の閾値と、状態情報が「緊急」と判定される信号値の閾値と、状態情報が「故障」と判定される信号値の閾値と、が関連付けられている。

後述するシミュレーション処理において、系統について信号値が算出されると、管理基準情報１５４に含まれる閾値と信号値とが比較され、当該系統に関する状態情報が特定される。なお、本実施形態において、管理基準情報１５４は、例えばシミュレーション処理の開始前に予め記憶部１５０に記憶されている。

劣化関数情報１５５については後述するが、劣化度及び信号値の算出に用いられる関数を含む情報である。本実施形態において、劣化関数情報１５５は、例えばシミュレーション処理の開始前に予め記憶部１５０に記憶されている。

車両カレンダー１５６は、車両２０２の予定に関する情報であって、時系列に沿って、運送タスクを実行する予定であるか、修理タスクを実行する予定であるか、等を示す情報が含まれている。以下、「車両カレンダー１５６に運送タスクを割り当てる」と説明する場合、車両カレンダー１５６の空き領域に対し、実行する予定の運送タスクを示す運送タスク情報１５８を関連付けることを意味する。同様に、「車両カレンダー１５６に修理タスクを割り当てる」と説明する場合、車両カレンダー１５６の空き領域に対し、実行する予定の修理タスクを示す修理タスク情報１５９を関連付けることを意味する。

整備会社カレンダー１５７は、整備会社２０３の予定に関する情報であって、時系列に沿って、実行する修理タスクに係る車両２０２の台数を示す情報が含まれている。本実施形態において、車両カレンダー１５６及び整備会社カレンダー１５７は、シミュレーション処理時に作成される。以下、「整備会社カレンダー１５７に修理タスクを割り当てる」と説明する場合、整備会社カレンダー１５７の空き領域に対し、実行する予定の修理タスクを示す修理タスク情報１５９を関連付けることを意味する。

運送タスク情報１５８は、車両２０２により実行される運送タスクに関する情報であって、例えば荷物の引取地と、目的地と、荷物の重量とが含まれている。本実施形態において、運送タスク情報１５８は、シミュレーション処理時に作成される。

修理タスク情報１５９は、整備会社２０３により車両２０２に対して実行される修理タスクに関する情報であって、整備対象の車両２０２や、整備会社２０３、及び整備時期が含まれている。整備対象の系統が特定されている場合には、修理タスク情報１５９は、該系統を特定する情報が含まれる。本実施形態において、修理タスク情報１５９は、シミュレーション処理時に作成される。

整備内容情報１６０は、整備方式を示す情報を含む。本実施形態において、整備内容情報１６０は、例えばシミュレーション処理開始前に予め記憶部１５０に記憶されている。パーツ情報１６１は、車両２０２の系統毎に、整備に用いられるパーツと、該パーツの料金とを関連付けた情報である。整備会社パーツ在庫情報１６２は、整備会社２０３の有するパーツの在庫量に関する情報である。本実施形態において、パーツ情報１６１及び整備会社パーツ在庫情報１６２は、シミュレーション処理開始前に予め記憶部１５０に記憶されている。

状態量情報１６３は、各系統の状態量と、状態量を用いて算出された劣化度及び信号値に関する情報である。シミュレーション処理において、各検知時期における劣化度が算出され、状態量情報１６３が生成される。

図４は、車両保守計画装置１のハードウェア構成例を示す図である。車両保守計画装置１は、ＣＰＵ（Central Processing Unit）１７１と、ＲＡＭ（Random Access Memory）１７２と、ＲＯＭ（Read Only Memory）１７３と、補助記憶装置１７４と、出力装置１７５と、入力装置１７６と、メディア読取装置１７７と、通信装置１７８と、を含み、各構成要素はバスにより接続されている。

ＣＰＵ１７１は中央演算装置であって、ＲＡＭ１７２やＲＡＭ１７３、又は補助記憶装置１７４に記録されたプログラムに従って処理を実行する。制御部１１０を構成する各処理部は、ＣＰＵ１７１がプログラムを実行することにより各々の機能を実現する。

ＲＡＭ１７２は主記憶装置であって、プログラムやデータが一時的に読み出される記憶エリアとして機能する。ＲＡＭ１７３は情報を読み出し可能な不揮発性の記憶装置である。補助記憶装置１７４は、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ、又はＳＳＤ（Solid State Drive）等の書き込み及び読み出し可能な記憶装置である。

出力装置１７５は、車両保守計画装置１に格納されたデータの出力処理を行う装置であって、例えばＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ等の表示装置、又はプリンタ等である。入力装置１７６は、ユーザーからの入力操作を受け付ける装置であり、例えばタッチパネル、キーボード、マウス、マイク等である。なお、入力部１２０は入力装置１７６を用いることができ、出力部１３０は出力装置１７５を用いることができる。

メディア読取装置１７７は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）等の可搬性のメディアから情報を入出力する装置である。通信装置１７８は、車両保守計画装置１を図示しないネットワークに接続するための装置であって、例えばＮＩＣ（Network Interface Card）等の通信デバイスである。

記憶部１５０は、ＲＡＭ１７２、ＲＡＭ１７３又は補助記憶装置１７４によりその機能が実現される。また、記憶部１５０は、ネットワーク上の記憶装置によってその機能が実現されてもよい。

また、車両保守計画装置１の各構成要素の処理は、１つのハードウェアで実行されてもよいし、複数のハードウェアで実行されてもよい。また、車両保守計画装置１の各構成要素の処理は、１つのプログラムで実現されてもよいし、複数のプログラムで実現されてもよい。

次に、車両保守計画装置１において行われるシミュレーション処理について説明する。

図５は、シミュレーション処理の一例を示すフローチャートである。本実施形態において、車両保守計画装置１は、例えば入力部１２０を介したシミュレーション処理の開始指示を受け付けると、本フローチャートの処理を開始する。

まず、条件情報取得部１１１は、シミュレーション条件を取得する（ステップＳ３０１）。具体的には、車両保守計画装置１がシミュレーション処理の開始指示を受け付けると、出力部１３０がシミュレーション条件入力画面を出力装置１７５に表示させる。条件情報取得部１１１は、シミュレーション条件入力画面に対して入力された情報を取得する。

図６は、シミュレーション条件入力画面４０１の一例を示す図である。シミュレーション条件入力画面４０１は、サービス会社入力領域４０２と、運送会社入力領域４０３と、車両入力領域４０４と、整備会社入力領域４０５と、期間入力領域４０６と、条件設定ボタン４０７と、開始ボタン４０８と、キャンセルボタン４０９と、を含む。

サービス会社入力領域４０２は、シミュレーション処理の対象となるサービス会社２０４を特定する情報の入力を受け付ける領域である。図６に示すように、サービス会社入力領域４０２には、追加ボタン、削除ボタン、新規ボタン、及び詳細ボタンが含まれる。追加ボタンの選択を受け付けると、例えば出力部１３０は記憶部１５０に予め記憶されたサービス会社２０４の一覧（図示せず）を含む一覧画面を表示し、サービス会社２０４の選択を受け付ける。

削除ボタンは、サービス会社入力領域４０２に表示されたサービス会社２０４を該領域から削除するボタンである。サービス会社２０４に対応するチェックボックスにチェックが付され、削除ボタンが選択されると、チェックされたサービス会社２０４がサービス会社入力領域４０２において非表示となる。

新規ボタンは、先述のサービス会社２０４の一覧に新たなサービス会社２０４を登録するボタンである。詳細ボタンは、サービス会社２０４の一覧に含まれる情報の編集を受け付けるボタンである。

運送会社入力領域４０３は、シミュレーション処理の対象となる運送会社２０１を特定する情報の入力を受け付ける領域である。図６に示すように、運送会社入力領域４０３には、運送会社２０１の名称を示す情報と、運送会社２０１において実行が可能な運送タスクの数を示す情報と、車両２０２の整備を依頼する整備会社２０３を示す情報と、が関連付けて入力可能に表示される。

また、運送会社入力領域４０３には、追加ボタンと、削除ボタンと、新規ボタンと、詳細ボタンと、が含まれる。追加ボタンの選択を受け付けると、例えば出力部１３０は記憶部１５０に予め記憶された運送会社２０１の一覧（図示せず）を含む一覧画面を表示し、運送会社２０１の選択を受け付ける。削除ボタンは、運送会社入力領域４０３に表示された運送会社２０１を該領域から削除するボタンである。新規ボタンは、先述の運送会社２０１の一覧に新たな運送会社２０１を登録するボタンである。

詳細ボタンは、運送会社２０１の一覧に含まれる情報の編集を受け付けるボタンである。なお、詳細ボタンの選択により表示される図示しない入力画面において、走行距離や荷物の重量に応じた運送料金に関する情報の入力を受け付けてもよい。条件情報取得部１１１は、運送会社入力領域４０３に対して入力された情報を用いて運送会社情報１５１を生成し、記憶部１５０に記憶させる。

車両入力領域４０４は、シミュレーション処理の対象となる車両２０２を特定する情報の入力を受け付ける領域である。図６に示すように、車両入力領域４０４には、車両２０２を特定する情報と、車両２０２を有する運送会社２０１と、車両２０２の総重量と、車両２０２の整備方式と、が関連付けて入力可能に表示される。なお、車両２０２の総重量は、車体重量と荷物の重量との和である。車両入力領域４０４は、車両２０２の総重量に代えて、車体重量又は運送可能な荷物の重量の上限値の入力を受け付けてもよい。

また、車両入力領域４０４には、追加ボタンと、削除ボタンと、新規ボタンと、詳細ボタンと、が含まれる。追加ボタンの選択を受け付けると、例えば出力部１３０は記憶部１５０に予め記憶された車両２０２の一覧（図示せず）を含む一覧画面を表示し、車両２０２の選択を受け付ける。削除ボタンは、車両入力領域４０４に表示された車両２０２を該領域から削除するボタンである。

新規ボタンは、先述の車両２０２の一覧に新たな車両２０２を登録するボタンである。詳細ボタンは、車両２０２の一覧に含まれる情報の編集を受け付けるボタンである。条件情報取得部１１１は、車両入力領域４０４に対して入力された情報を用いて車両情報１５２を生成し、記憶部１５０に記憶させる。

整備会社入力領域４０５は、シミュレーション処理の対象となる整備会社２０３を特定する情報の入力を受け付ける領域である。図６に示すように、整備会社入力領域４０５には、整備会社２０３を特定する情報と、整備会社２０３の整備可能な単位時間（例えば１日）当たりの車両数の上限値と、が関連付けて入力可能に表示される。

また、整備会社入力領域４０５には、追加ボタンと、削除ボタンと、新規ボタンと、詳細ボタンと、が含まれる。追加ボタンの選択を受け付けると、例えば出力部１３０は記憶部１５０に予め記憶された整備会社２０３の一覧（図示せず）を含む一覧画面を表示し、整備会社２０３の選択を受け付ける。削除ボタンは、整備会社入力領域４０５に表示された整備会社２０３を該領域から削除するボタンである。新規ボタンは、先述の整備会社２０３の一覧に新たな整備会社２０３を登録するボタンである。

詳細ボタンは、整備会社２０３の一覧に含まれる情報の編集を受け付けるボタンである。なお、詳細ボタンの選択により表示される図示しない入力画面において、整備工場の取り扱うパーツの一覧やパーツの代金、整備料金、対応可能な整備方式に関する情報の入力を受け付けてもよい。条件情報取得部１１１は、整備会社入力領域４０５に対して入力された情報を用いて整備会社情報１５３を生成し、記憶部１５０に記憶させる。

期間入力領域４０６は、シミュレーションを行う期間の入力を受け付ける領域である。期間入力領域４０６は、図６に示すように、例えばシミュレーションの開始時期と終了時期との入力を受け付ける。なお、シミュレーションを行う期間は、保守計画評価情報の生成要求期間ともいえ、車両保守計画装置１は、入力された期間に実行される運送タスクや修理タスクに関するシミュレーションを行い、保守計画評価情報を生成する。

条件設定ボタン４０７は、シミュレーションの実行結果としてのログファイルの出力等、プログラムの動作を制御するための設定画面（図示せず）の表示指示を受け付けるボタンである。開始ボタン４０８は、各入力領域に入力されたシミュレーション条件の内容を確定し、シミュレーションの開始指示を受け付けるボタンである。キャンセルボタン４０９は、シミュレーションのキャンセル指示を受け付けるボタンであって、キャンセルボタン４０９が選択されるとシミュレーション条件入力画面４０１が閉じ、図５に示すシミュレーション処理が終了する。

なお、図５に示すシミュレーション条件入力画面４０１は一例であって、例えばグラフィカルなインターフェイスによって事業体や車両２０２をアイコン表示し、アイコンを選択及び配置することでシミュレーション条件の入力を受け付けてもよい。また例えば、事業体や車両２０２の名称の入力を受け付けることで、予め記憶部１５０に記憶された情報を参照し、各名称に関連付けられた情報を表示するものであってもよい。

説明を図５に戻す。次に、条件情報取得部１１１は、初期化処理を行う（ステップＳ３０２）。具体的には、条件情報取得部１１１は、ステップＳ３０１においてシミュレーション条件として入力された車両２０２毎に車両カレンダー１５６を生成し、記憶部１５０に記憶させる。また、条件情報取得部１１１は、同様にシミュレーション条件として入力された整備会社２０３毎に整備会社カレンダー１５７を生成し、記憶部１５０に記憶させる。なお、車両カレンダー１５６及び修理カレンダーには、期間入力領域４０６に入力された生成要求期間が含まれており、当該期間における予定はこの時点では空となっている。

また、条件情報取得部１１１は、シミュレーション条件としてサービス会社入力領域４０２に入力されたサービス会社２０４を記憶部１５０に記憶させる。また、条件情報取得部１１１は、シミュレーション条件として運送会社入力領域４０３に入力された情報を用いて運送会社情報１５１を生成し、記憶部１５０に記憶させる。また、条件情報取得部１１１は、車両入力領域４０４に入力された情報を用いて車両情報１５２に整備方式を関連付け、記憶部１５０に記憶させる。また、条件情報取得部１１１は、シミュレーション条件として運送会社入力領域４０３及び整備会社入力領域４０５に入力された情報を用いて整備会社情報１５３を生成し、記憶部１５０に記憶させる。

次に、修理タスク生成部１１３は、定期メンテナンススケジューリングを行う（ステップＳ３０３）。具体的には、修理タスク生成部１１３は、車両情報１５２における各車両２０２の整備方式を参照し、定期メンテナンスの整備方式と関連付けられた車両２０２を抽出する。なお、整備方式が定期メンテナンスである場合、車両情報１５２には定期メンテナンスを行う期間が含まれている。

修理タスク生成部１１３は、抽出した車両２０２（以下、抽出車両とする）毎に以下の処理を行う。まず、修理タスク生成部１１３は、抽出車両と関連付けられた、定期メンテナンスを行う期間を参照して該期間毎に整備候補時期を特定する。修理タスク生成部１１３は、整備会社情報１５３において抽出車両と関連付けられた整備会社２０３及び該整備会社２０３の整備可能な車両２０２の数の上限値を特定し、特定した整備会社２０３の整備会社カレンダー１５７を参照する。

修理タスク生成部１１３は、整備会社カレンダー１５７において整備候補時期に整備を行う車両２０２の数が上限値未満である場合に、整備候補時期を整備時期とし、整備会社カレンダー１５７及び抽出車両の車両カレンダー１５６を更新する。

修理タスク生成部１１３は、整備会社カレンダー１５７において整備候補時期に整備を行う車両２０２の数が上限値以上である場合に、該整備会社カレンダー１５７において車両２０２の数が上限値未満であって、整備候補時期以降、整備候補時期に最も近い時期（例えば翌日）を、新たな整備候補時期に特定する。修理タスク生成部１１３は、新たな整備候補時期を整備時期とし、整備会社カレンダー１５７及び車両カレンダー１５６を更新する。

なお、新たな整備候補時期について、整備を行う車両２０２の数が上限値未満であって、整備候補時期以降、整備候補時期に最も近い時期としたが、これに限られない。例えば整備候補時期以降でなくてもよく、車両２０２の数が上限値未満の適切な時期に新たな整備候補時期が設定されるものであればよい。

次に、運送タスク生成部１１２は、事前分の運送タスク情報１５８の生成及びスケジューリングを行う（ステップＳ３０４）。運送タスク情報１５８の生成については、後に詳述する。本ステップにおいて生成される１又は複数の運送タスク情報１５８には、少なくとも走行距離を示す情報と、荷物の重量を示す情報と、予め定められた走行速度と走行距離とを用いて算出された走行時間を示す情報とが含まれる。

運送タスク生成部１１２は、シミュレーション条件として入力されたシミュレーションの開始時期から所定期間（例えば１日）に空き領域を有する車両カレンダー１５６に係る車両２０２を特定する。運送タスク生成部１１２は、特定した車両２０２の総重量を用いて該車両２０２の運送可能な荷物の重量を特定し、生成した各運送タスク情報１５８に係る重量の荷物が運送可能か否かを判定する。

即ち、シミュレーション開始時期から所定期間の予定に空きがあり、荷物を運送可能な車両２０２を、運送タスクを実行可能な車両２０２として特定する。運送タスク生成部１１２は、生成した運送タスク情報１５８の各々に対し、運送タスクを実行可能な車両２０２を特定する。運送タスク生成部１１２は、特定した車両２０２の車両カレンダー１５６のうち、上述の所定期間内に運送タスクを割り当てる。

なお、本実施形態では、シミュレーションにおいて仮想的に時間を進行させ、仮想時間における時系列において所定期間毎にスケジューリング、即ち運送タスク情報１５８及び修理タスク情報１５９の割り当てを行う。所定期間毎に繰り返しスケジューリングを行う場合に、シミュレーションの開始時期に所定量の運送タスク情報１５８が割り当てられている方が自然であるとの思想に基づき、本ステップにおいて事前に運送タスク情報１５８を割り当てる処理を行っている。しかしながら、本処理を省略し、以下の繰り返し処理においてシミュレーションの開始時期に運送タスク情報１５８を割り当ててもよい。

次に、制御部１１０は、ステップＳ３０６からステップＳ３１７の処理を繰り返す（ステップＳ３０５、ステップＳ３１８）。なお、制御部１１０は、シミュレーション内における時計（以下、「仮想時計」とする）を進行させ、該時計に従った時系列の処理を行う。

まず、制御部１１０は、車両稼働時間であるか否かを判定する（ステップＳ３０６）。具体的には、制御部１１０は、仮想時計における現在時刻が予め定められた車両稼働時間であるか否かを判定する。

なお、労働大臣告示の「自動車運転者の労働時間等の改善のための基準（改善基準告示）」によれば、自動車運転者の最大拘束時間は１日あたり原則１３時間以内とされている。そのため、本実施形態では、例えば８時から２１時までの時間を車両稼働時間として取り扱う。なお、車両稼働時間の設定は本実施形態において必須ではなく、仮想時計の現在時刻に関わらず、以下のステップＳ３０７以降の処理を行うものであってもよい。

制御部１１０が、車両稼働時間であると判定する場合（ステップＳ３０６で「ｙｅｓ」の場合）、信号値取得部１１５は、車両２０２の状態量を更新する（ステップＳ３０７）。具体的には、信号値取得部１１５は、シミュレーション条件として入力された各車両２０２の有する系統の各々について、走行距離等、車両２０２の状態に変化を与える状態量を特定する。信号値取得部１１５は、状態量を用いて、系統の劣化度を算出する。状態量の算出については後述するが、本実施形態において本処理は仮想時計における車両稼働時間の１時間毎に行われるため、状態量算出部は１時間の劣化度を算出して各車両２０２の系統毎に状態量情報１６３に記憶させる。

なお、状態量情報１６３に予め劣化度が記憶されている場合、即ち仮想時計における１時間以上前に劣化度を算出している場合、状態量算出部は既に算出した劣化度に新たに算出した劣化度を加算し、状態量情報１６３を更新する。また、信号値取得部１１５は、劣化度を用いて系統毎に信号値を算出する。信号値の算出については後述する。

次に、異常検知部１１４は、車両故障チェックを実行する（ステップＳ３０８）。具体的には、異常検知部１１４は、ステップＳ３０７で算出した信号値を用いて管理基準情報１５４を参照し、状態情報が「故障」である系統を有する車両２０２の有無を判定する。状態情報が「故障」である系統を有する車両２０２がある場合、異常検知部１１４は故障があることを示す情報を、当該系統を有する車両２０２の車両情報１５２に関連付ける。その後、異常検知部１１４は処理をステップＳ３０９に移行させる。

制御部１１０が、車両稼働時間でないと判定する場合（ステップＳ３０６で「ｎｏ」の場合）、又はステップＳ３０８の処理の後、制御部１１０は、仮想時計の現在時刻が正午であるか否かを判定する（ステップＳ３０９）。なお、以下の処理は仮想時計における所定期間（例えば１日）毎に行われればよく、処理を行うタイミングは仮想時計の正午に限定されないことは、いうまでもない。

制御部１１０が、仮想時計の現在時刻が正午であると判定する場合（ステップＳ３０９で「ｙｅｓ」の場合）、修理タスク生成部１１３は、定期メンテナンスを実行する（ステップＳ３１０）。具体的には、修理タスク生成部１１３は、車両カレンダー１５６を参照し、仮想時計の現在時刻に定期メンテナンスを行う車両２０２を抽出する。修理タスク生成部１１３は、状態量情報１６３を参照し、抽出した車両２０２の整備内容を特定する。

例えば、修理タスク生成部１１３は、信号値が所定値以上の系統を整備対象の系統に特定する。修理タスク生成部１１３は、パーツ情報１６１を参照し、メンテナンスに要するパーツを特定する。修理タスク生成部１１３は、メンテナンス対象の系統について整備を行ったこととして、当該系統の状態量を予め定められた初期値に戻す。なお、初期値とは、当該車両２０２について運送タスク情報１５８を割り当てる前の値といえる。

また、修理タスク生成部１１３は、抽出した車両２０２の整備を行う整備会社２０３を特定し、該整備会社２０３と関連する整備会社パーツ在庫情報１６２を特定する。修理タスク生成部１１３は、メンテナンスに要するパーツを該整備会社２０３の在庫から減算する。

なお、車両カレンダー１５６において、仮想時計の現在時刻に定期メンテナンスを行うことが予定されていない車両２０２については、本ステップで処理が行われない。また、状態量の復旧及びパーツの在庫量の減算は、定期メンテナンスの終了予定の時刻に仮想時計の時刻が達した場合に行われるものであってもよい。

次に、修理タスク生成部１１３は、修理を実行する（ステップＳ３１１）。具体的には、修理タスク生成部１１３は、車両カレンダー１５６を参照し、仮想時計の現在時刻に修理を行う車両２０２を抽出する。なお、本処理開始前（後述するステップＳ３１４）に、信号値が第１の閾値以上の値の系統を有する車両２０２について、修理を行うことを示す修理タスク情報１５９が生成され、車両カレンダー１５６及び整備会社カレンダー１５７に割り当てられている。修理タスク情報１５９には、修理対象となる系統が特定されている。

修理タスク生成部１１３は、修理対象の系統について修理を行ったこととして、当該系統の状態量を予め定められた初期値に戻す。また、修理タスク生成部１１３は、修理対象の車両２０２の整備を行う整備会社２０３を特定し、該整備会社２０３と関連する整備会社パーツ在庫情報１６２を特定する。修理タスク生成部１１３は、メンテナンスに要するパーツを該整備会社２０３の在庫から減算する。

なお、車両カレンダー１５６において、仮想時計の現在時刻修理を行うことが予定されていない車両２０２については、本ステップで処理が行われない。定期メンテナンスの実行の際と同様に、状態量の復旧及びパーツの在庫量の減算は、修理タスクの終了予定の時刻に仮想時計の時刻が達した場合に行われるものであってもよい。

次に、修理タスク生成部１１３は、予知メンテナンスを実行する（ステップＳ３１２）。具体的には、修理タスク生成部１１３は、車両カレンダー１５６を参照し、仮想時計の現在時刻に予知メンテナンスを行う車両２０２を抽出する。なお、本処理開始前（後述するステップＳ３１５）に、信号値が第２の閾値以上第１の閾値未満の値の系統を有する車両２０２について、予知メンテナンスを行うことを示す修理タスク情報１５９が生成され、車両カレンダー１５６及び整備会社カレンダー１５７に割り当てられている。修理タスク情報１５９には、予知メンテナンス対象となる系統が特定されている。

修理タスク生成部１１３は、予知メンテナンス対象の系統について整備を行ったこととして、当該系統の状態量を予め定められた初期値に戻す。また、修理タスク生成部１１３は、予知メンテナンス対象の車両２０２の整備を行う整備会社２０３を特定し、該整備会社２０３と関連する整備会社パーツ在庫情報１６２を特定する。修理タスク生成部１１３は、メンテナンスに要するパーツを該整備会社２０３の在庫から減算する。

なお、車両カレンダー１５６において、仮想時計の現在時刻に予知メンテナンスを行うことが予定されていない車両２０２については、本ステップで処理が行われない。また、定期メンテナンスの実行の際と同様に、状態量の復旧及びパーツの在庫量の減算は、修理タスクの終了予定の時刻に仮想時計の時刻が達した場合に行われるものであってもよい。

次に、運送タスク生成部１１２は、運送タスク情報１５８の生成及びスケジューリングを行う（ステップＳ３１３）。

図７は、運送タスクの概要の一例を示す図である。運送タスク生成部１１２は、運送会社２０１、始点、及び終点を特定する座標を含む運送タスク情報１５８を生成する。図７において、矢印は車両２０２の移動を示し、運送会社２０１から始点までの移動を引取、始点から終点までの移動を運送、終点から運送会社２０１までの移動を帰社とし、それぞれの距離を引取距離、運送距離、帰社距離とする。

引取距離、運送距離、及び帰社距離の和により運送タスクの走行距離が特定しうる。時間についても同様に、引取に要する時間を引取時間、運送に要する時間を運送時間、帰社に要する時間を帰社時間とし、引取時間、運送時間、及び帰社時間の和により運送タスクの走行時間が特定しうる。

また、運送対象の荷物には重量があり、車両２０２は、例えば車両総重量の半分の重さの荷物までなら運送可能と定められている。運送タスク生成部１１２は、運送タスクに応じて荷物の重量が異なるよう、乱数を用いて荷物の重量を設定する。

例えば、運送タスク生成部１１２は、基準の荷物の重量を１トンとし、０トン〜５トンまでの追加重量を一様乱数で発生させる。追加重量が０トンなら、荷物の重量は１トンであり、２トン以上の車両総重量の車両２０２なら運送が可能である。追加重量が３トンなら、荷物の重量は４トンであり、８トン以上の車両総重量の車両２０２なら運送可能である。

なお、運送タスクを割り当てるためには、運送タスクに係る走行時間を求める必要がある。一例において、運送タスク生成部１１２は、運送タスクの始点と終点とを乱数を用いて設定する。

図８は、始点及び終点の設定方法の一例を説明するための図である。本図は２次元空間を想定しており、本実施形態において、始点st、終点enの発生しうる全体領域の範囲は１辺長さomt_rangeの正方形領域内とする。ただし、始点及び終点間の距離を長くなりすぎないように限定するため、全体領域内において、１辺長さomf_frameの正方形領域内（以下、枠領域とする）に始点及び終点を発生させる。

枠領域の左下を左下点lb(left bottom)とすると、左下点lbは全体領域の原点０から、１辺長さomt_lbrangeの正方形領域内に発生させればよい。各領域の辺の長さには以下の関係がある。

関数U([l,u])をl以上、u未満の一様乱数とすれば、始点st、終点enの座標値cv(coordinate value)は式(2)で得られる。

始点、終点、また運送会社２０１の地点の座標値もわかっているため、引取距離D^ta、運送距離D^tr、帰社距離D^reが求まる。図５に示す本実施形態におけるシミュレーション処理では、1時間毎に処理を進めるので、時間と距離の関係を計算で求める。まず車両２０２の標準の移動速度S^std(標準速度)を予め定めておく。引取時間T^taは式(3)で求まる。運送時間T^tr、帰社時間T^reも同様である。

本実施形態では、仮想時計において１時間毎に処理を行うため、時速が1時間当りの移動距離となる。引取速度S^taは式(4)で求めることができる。運送速度S^tr、帰社速度S^reも同様である。

図９は、１日間に１つの運送タスク情報１５８が割り当てられている場合のスケジューリングの一例を示す。本図は、運送タスクを行う車両２０２の車両カレンダー１５６であるともいえる。走行距離が４９０ｋｍであって、そのうち引取距離が９０ｋｍ、運送距離が２７０ｋｍ、帰社距離が１３０ｋｍである。

標準速度を５０ｋｍとすれば、引取時間は約２時間、運送時間は約６時間、帰社時間は約３時間である。８時から順にシミュレーションを実行し、１０時まで引取１００１がスケジューリングされる。１２時から１時間の停止（休憩時間）１００３が予定されるため、運送は１０時から１２時までの運送１００２と、１３時から１７時までの運送１００４とにスケジューリングされる。

また、１８時から１９時まで１時間の停止１００６が予定されるため、帰社についても１７時から１８時までの帰社１００５と、１９時から２１時までの帰社１００７とにスケジューリングされる。

図１０は、３日間に１つの運送タスク情報１５８が割り当てられている場合のスケジューリングの一例を示す。本例では、引取時間が８時間、運送時間が１０時間、帰社時間が９時間である。１日目に２１時で運送を中断し、翌２日目の８時から運送を再開する。翌３日目も同様であり、タスクは１４時で完了する。完了後、車両２０２の運送タスク情報１５８の実行の予定はなく、また修理タスク情報１５９の実行の予定も入っていない。よって３日目の１４時から２１時まで、車両２０２は計画が無いということであり、実質的には停止していることとなる。０時から８時、２１時から０時についても、運送タスク情報１５８に関連して予定が入っていないため、車両２０２は停止していることとなる。

説明を図５に戻す。次に、修理タスク生成部１１３は、修理スケジューリングを行う（ステップＳ３１４）。具体的には、修理タスク生成部１１３は、ステップＳ３０８において、故障があることを示す情報を関連付けられた車両２０２（即ち、信号値が第１の閾値以上である系統を有する車両２０２）である修理対象車両の各々について、以下の処理を行う。

まず、運送タスク生成部１１２は、修理対象車両の車両カレンダー１５６を参照し、仮想時計の現在時刻の日付の翌日以降の運送タスク情報１５８を削除する。なお、運送タスク生成部１１２は、削除した日付に割り当てられた運送タスクを実行可能な他の車両２０２を特定し、該車両２０２の車両カレンダー１５６に運送タスク情報１５８を割り当ててもよい。

また、修理タスク生成部１１３は、パーツ情報１６１を参照し、信号値が第１の閾値以上である系統の修理に要するパーツを特定する。修理タスク生成部１１３は、整備会社パーツ在庫情報１６２を参照し、特定したパーツを在庫に有する整備会社２０３を抽出する。

修理タスク生成部１１３は、抽出した整備会社２０３について整備会社カレンダー１５７を参照し、仮想時計の現在時刻の日付の翌日以降の日程において、修理を行う車両２０２の数が上限値に達しておらず、かつ最も現在時刻の日付に近い空き時期を有する整備会社２０３を、修理を行う整備会社２０３として特定する。また、修理タスク生成部１１３は、当該時期を整備時期に特定する。

修理タスク生成部１１３は、修理を行う整備会社２０３の整備会社カレンダー１５７のうち、特定した整備時期に修理タスク情報１５９を割り当てる。また、修理タスク生成部１１３は、修理対象車両２０２の車両カレンダー１５６のうち、特定した整備時期に修理タスク情報１５９を割り当てる。なお、割り当てられた修理タスク情報１５９には、整備対象となる系統が関連付けられている。

次に、異常検知部１１４は、異常検知を行う（ステップＳ３１５）。

図１１は、異常検知処理及び予知メンテナンススケジューリング処理の概要を示す図である。本図は、異常検知及び予知メンテナンススケジューリング処理の概念について説明するために用いられる。本図は、異常検知をサービス会社２０４にて行い、運送会社２０１及び整備会社２０３において予知メンテナンスを行う実態を示すものであるが、車両保守計画装置１は本図における処理を模擬的にシミュレーションする。車両保守計画装置１において行われる処理については、後に詳述する。

まず、サービス会社２０４は、予め契約している運送会社２０１の車両２０２を監視し、当該車両２０２の各系統の状態を検知するよう設置されたセンサから発生した信号値を受信する（ステップＳ１２２１）。

次に、サービス会社２０４は、信号値を用いて、各系統の状態を判定する（ステップＳ１２２２）。サービス会社２０４は、信号値を用いて管理基準情報１５４に相当する情報を参照し、各系統がどの状態情報であるかを判定する。また、サービス会社２０４は、信号値が第２の閾値以上第１の閾値未満である場合に、当該系統を有する車両が予知メンテナンスの対象であると判定する。

なお、第２の閾値は、管理基準情報１５４において、「警告」の状態情報と関連付けられている。即ち、信号値が第２の閾値以上、第１の閾値未満である系統については、「警告」又は「緊急」の状態情報が関連付けられる。

次に、サービス会社２０４は、予知メンテナンスの対象となる系統、及び該系統を有する車両２０２を特定した通知を運送会社２０１に対して出力する（ステップＳ１２２３）。通知を受け付けた運送会社２０１は、通知により特定される系統について、車両カレンダー１５６を参照し、修理や予知メンテナンスの予定が含まれていない場合に、当該系統に関する初回の通知であると判定する。運送会社２０１は、初回の通知であると判定する場合に、ステップＳ１２２５に処理を進行させる。

次に、サービス会社２０４は、整備会社２０３に通知を行う（ステップＳ１２２４）。具体的には、サービス会社２０４は、整備会社情報１５３を参照し、予知メンテナンスの対象であると判定された車両２０２の整備を行う会社として予め定められた整備会社２０３を特定し、第２の閾値以上第１の閾値未満である信号値を発生した系統を特定した通知を行う。

なお、運送会社２０１には、該運送会社２０１の有する車両２０２の系統毎に残寿命を示す情報が記憶されている。予知メンテナンスの対象である系統については、すぐに故障の状態になる訳ではなく、残寿命が尽きるまでに整備を行えば足りる。

次に、運送会社２０１は、整備会社２０３との間で日程の調整を行う（ステップＳ１２２５）。運送会社２０１は、整備会社２０３の整備会社カレンダー１５７を参照し、予知メンテナンスの対象となる系統の残寿命の終期以前であって、該終期に最も近い空き日程を予知メンテナンスの整備時期に特定する。

整備時期において、予知メンテナンスの対象の系統を有する車両２０２に運送タスクが割り当てられている場合、運送会社２０１は当該車両２０２の車両カレンダー１５６から整備時期を含む日程の運送タスク情報１５８を削除する。運送会社２０１は、削除した運送タスクを実行可能な他の車両２０２に運送タスクを割り当ててもよい。

また、予知メンテナンスの対象の系統を有する車両２０２に定期メンテナンスが予定されている場合、運送会社２０１は定期メンテナンスの修理タスク情報１５９を車両カレンダー１５６から削除する。また、運送会社２０１は、定期メンテナンスを予定していた整備会社２０３の整備会社カレンダー１５７からも、修理タスク情報１５９を削除する。運送会社２０１は、予知メンテナンスの対象となる系統を特定した修理タスク情報１５９を生成し、該系統を有する車両２０２の車両カレンダー１５６について、特定した整備時期に修理タスクを行うよう車両カレンダー１５６を更新する。また、運送会社２０１は、整備会社２０３の整備会社カレンダー１５７について、特定した整備時期に修理タスクを行うよう整備会社カレンダー１５７を更新する。

なお、ステップＳ１２２３において、予知メンテナンスの対象となる系統を有する車両２０２について、既に予知メンテナンスが予定されている場合、既に予定されている予知メンテナンスの整備時期が、ステップＳ１２２１において信号値を発生した系統の残寿命内であるか否かを判定する。残寿命内であると判定する場合、運送会社２０１は、既に定められた予知メンテナンスの修理タスク情報１５９に当該系統に関する情報を加えて、車両カレンダー１５６及び整備会社カレンダー１５７を更新する。

既に予定されている予知メンテナンスの整備時期が、残寿命の終期より後である場合、運送会社２０１はステップＳ１２２５と同様に予知メンテナンスのスケジューリングを行う。

その後、整備会社２０３が予知メンテナンスに係る整備を行う（ステップＳ１２２６）。具体的には、運送会社２０１はステップＳ１２２１において受け付けた信号値に関する情報を削除するとともに、整備を行った整備会社２０３の有するパーツの在庫情報について、整備に用いたパーツの在庫量を減算する。

説明を図５に戻す。ステップＳ３１５において、異常検知部１１４が異常を検知するために、まず信号値取得部１１５がシミュレーション条件において特定された各車両２０２の系統毎に、劣化度を算出する。

各系統は、運送タスクの実施に伴い劣化する。ここで、運送タスクの実施に伴い変化する変数を状態変数とする。状態変数として、走行距離、走行時間、走行負荷、燃料消費量が挙げられる。走行距離は、移動に伴う１時間毎の速度の値を積算する。走行時間は移動の１時間毎に１を積算する。走行負荷は重量と走行距離の積(t・km)であって、１時間毎に積算される。

引取、帰社では重量は車体そのものの重量(車体重量)であり、運送では車体重量と荷物の重量(積載重量)の和である。車体重量は、シミュレーション条件として入力を受け付けた車両総重量から、運送タスク情報１５８に含まれる荷物の重量を減算することで算出可能である。なお、車体重量は、シミュレーション条件として入力された車両総重量の２分の１としてもよい。

燃料消費量は、例えば単位としてはリットルであり、走行距離と燃費(km/l、１リットルでの走行距離)の積であるが、さらに走行負荷を車体重量で除した重みをかけて、荷物重量を加味してもよい。状態変数の値が状態量である。

劣化度deteriorationは、状態変数state_variableの関数として定義される。劣化度を求めるための関数は、劣化関数情報１５５より取得する。

関数fは、１変数でなくても、複数の状態変数の多変数をとってもよく、パラメータでも調整し得る。状態変数は走行距離mileage、走行時間travelling_time、走行負荷acc_travel_load、燃料消費量fuel_consumptionである。

ただ関数fを複雑に捉える必要もなく、例えば以下の式のように原動機の劣化度を決めてもよい。

これは走行距離で原動機の劣化を管理することとなる、定期メンテナンスと関連して、経時メンテナンスのようなメンテナンス方式といえる。

異常検知の判定を行うため、劣化度より信号値を生成する。これは、現実に機械などの劣化を自動で判定するために、センサなどを設け、センサからの出力の信号で不具合を判定することに相当する。また信号値にする際に乱数を入れることで、ノイズのようなばらつきやセンサ特有の信号の変化を再現することができる。信号値取得部１１５は、算出した劣化度及び信号値を状態量情報１６３に格納する。

式(8)は信号値signalの算出式の一例を示す。

ここで、a、bは実数の係数(coefficient)と切片(intercept)、COEF_R、INTR_Rは係数、切片へのばらつきを加えるための乱数生成処理/関数である。具体的には、乱数を導入しない定数１を返す関数、一様乱数、標準正規乱数(平均０、標準偏差１の正規分布を発生確率とする乱数)、片側(０以上を返す)標準正規乱数、指数乱数(指数分布を発生確率とする乱数)等である。

得られた信号値を用いて管理基準情報１５４を参照し、系統毎に状態情報（AlarmStatus）を特定する。本実施形態において、状態情報は「正常」の「Normal」から、警告の「Alert」、緊急の「Urgent」、そして故障を意味する致命的の「Critical」までの、４段階で定義される。ランク判定は式(9)で表現される。

状態情報（AlarmStatus）は信号値の該当する範囲で決まるので、下側と上側の閾値threshould、すなわち下限値lower_limitと上限値upper_limitを持つ。また信号値はある値を基準として上側、下側に変化するものであるので、上upperと下lowerの方向を持つ。信号値が０以上の値しか取らず、また基準となる値が０である場合、上の方向のみでよい。式(9)の２段目が上方向、３段目が下方向の判定である。

インデックスiは各状態情報に対応しており、Normalが１、Alertが２、Urgentが３、Criticalが４となる。

なお、車両２０２の状態情報を特定するために、必ずしも信号値を用いる必要はなく、劣化度を用いて管理基準情報１５４を参照することにより状態情報を特定してもよい。正常、警告、緊急、又は、故障等の状態が定まれば、修理を行うか予知メンテナンスを行うかの判定が可能であり、即ち修理タスク情報１５９の生成が可能となる。この場合、式(9)の信号値signalを劣化度deteriorationと置けばよい。

また、異常検知のためには、劣化度を算出せずに、状態変数から直接に信号値を求めてもよい。これは、センサ信号の値は暗に機械的な劣化と対応することから、移動(走行)の実施でセンサ信号の変化を直接に取得することと対応している。その場合、計算上は式(5)を式(8)に代入すればよい。なお、異常検知部１１４は、特定された状態情報を系統毎に状態量情報１６３に格納する。

次に、修理タスク生成部１１３は、予知メンテナンススケジューリングを行う（ステップＳ３１６）。

図１２は、予知メンテナンスの概要を説明するための図（その１）である。図１２（ａ）は、系統が故障した場合のスケジューリングの一例を示す。図１２に示す上から下に向かう方向へと時間が経過する。

故障が発生すると、車両２０２は運送を停止せざるをえず、運送タスクの実施中である場合、運送タスクの実施が中断する。車両２０２の修理が完了するまで、運送タスクはキャンセルされる。運送タスクのキャンセルは運送会社２０１の損失となる。車両２０２の故障時点で、速やかに他の車両２０２に運送タスクを割り当てることができなければ、運送会社２０１にとって機会的な損実となる。

図１２（ｂ）は、図５に示すステップＳ３１５において、予知メンテナンスの対象として特定された車両２０２について行われる予知メンテナンスのスケジューリングの概要を示す。第２の閾値以上の信号値が算出された系統については、異常が検知されたものと取り扱われる。異常が検知された系統の残寿命が、車両情報１５２を参照することにより特定される。該系統を有する車両２０２は、残寿命が尽きるまで走行可能である。

車両保守計画装置１において、残寿命により特定される対象車両２０２の走行可能期間のうち、対象車両を整備する整備会社２０３の日程に空きがあるか否かが確認される。図１２（ｂ）に示す整備会社２０３は、１日につき２台の車両２０２の整備が可能である。また、同図において、黒く塗りつぶされた四角形は既に整備予定があることを示し、白抜きで表現された四角形は空きがあることを示している。車両保守計画装置１において、車両２０２の走行可能期間における整備会社２０３の空き日程を整備候補時期として抽出する。

また、車両保守計画装置１において、整備候補時期に運送タスクを実行可能な他の車両２０２の有無が判定される。整備候補時期において、運送タスクを実行可能な他の車両２０２がある場合、当該他の車両２０２に運送タスクが割り当てられる。

図１３は、修理タスク生成部１１３により実行される予知メンテナンスのスケジューリング処理の一例を示すフローチャートである。本図は、図５に示すステップＳ３１６において行われる処理の詳細を示すものである。図５に示すステップＳ３１５において、複数の系統について異常が検知された場合、修理タスク生成部１１３は異常が検知された各系統について以下の処理を行う。なお、異常が検知された系統を対象系統、該系統を有する車両２０２を対象車両として説明する。

まず、修理タスク生成部１１３は、対象系統の残寿命を取得する（ステップＳ１３０１）。具体的には、修理タスク生成部１１３は、車両２０２情報を参照し、異常が検知された系統の残寿命を取得する。

次に、修理タスク生成部１１３は、走行可能期間の整備会社２０３の空き時期を抽出する（ステップＳ１３０２）。具体的には、修理タスク生成部１１３は、整備会社情報１５３を参照し、対象系統を有する対象車両を整備する整備会社２０３を特定する。修理タスク生成部１１３は、仮想時計において現時点から残寿命が尽きるまでの間の走行可能期間における、特定した整備会社２０３の空き時期を、整備会社カレンダー１５７を参照することにより抽出する。

次に、修理タスク生成部１１３は、対象車両２０２及び他の車両２０２の空き時期を抽出する（ステップＳ１３０３）。具体的には、修理タスク生成部１１３は、走行可能期間における対象車両２０２の空き時期を、対象車両２０２の車両カレンダー１５６を参照することにより抽出する。また、修理タスク生成部１１３は、他の車両２０２の車両カレンダー１５６を参照し、走行可能期間における他の車両２０２の空き時期を抽出する。

なお、本実施形態において、本ステップでは対象車両２０２と同じ運送会社２０１に属する他の車両２０２の空き時期を抽出する。しかしながら、他の車両２０２は、対象車両２０２とは異なる運送会社２０１に属する車両２０２であってもよい。

次に、修理タスク生成部１１３は、整備会社２０３の空き時期と、対象車両２０２又は他の車両の空き時期との組合せを抽出する（ステップＳ１３０４）。具体的には、修理タスク生成部１１３は、ステップＳ１３０２において抽出した整備会社２０３の空き時期と、ステップＳ１３０３において抽出した対象車両２０２の空き時期とが一致する時期を抽出する。また、修理タスク生成部１１３は、ステップＳ１３０２において抽出した整備会社２０３の空き時期と、ステップＳ１３０３において抽出した他の車両２０２の空き時期とが一致する時期を抽出する。

次に、修理タスク生成部１１３は、まだ特定していない組合せのうち、最も遅い組合せを特定する（ステップＳ１３０５）。具体的には、修理タスク生成部１１３は、ステップＳ１３０４において抽出した整備会社２０３と対象車両２０２との空き時期の組合せ、及び整備会社２０３と他の車両２０２との空き時期の組合せのうち、まだ特定されていない組合せであって、最も時期の遅い組合せを特定する。

次に、修理タスク生成部１１３は、特定した組合せが、対象車両２０２の空き時期による組合せであるか否かを判定する（ステップＳ１３０６）。具体的には、修理タスク生成部１１３は、ステップＳ１３０５において特定した組合せが、対象車両２０２の空き時期と整備会社２０３の空き時期との組合せである場合に、処理をステップＳ１３０７に進行させる。

修理タスク生成部１１３が、対象車両２０２の空き時期による組合せであると判定する場合（ステップＳ１３０６で「ｙｅｓ」の場合）、修理タスク生成部１１３は、整備時期を特定し、修理タスク情報１５９を生成する（ステップＳ１３０７）。具体的には、修理タスク生成部１１３は、組合せに係る時期を整備時期として特定し、当該整備時期及び対象の系統を特定した修理タスク情報１５９を生成する。

即ち、修理タスク生成部１１３は、第２の閾値以上の信号値が算出された系統を有する車両２０２について、整備会社２０３の整備する車両数が上限に達しておらず、該系統の残寿命までの期間のうち最も遅い時期であって、かつ信号値の算出に係る仮想時計の現在時以降の時期を整備時期に特定して、修理タスク情報１５９を生成する。

修理タスク生成部１１３は、対象車両２０２の車両カレンダー１５６の整備時期を示す箇所に、修理タスク情報１５９を割り当てる。また、修理タスク生成部１１３は、組合せに係る整備会社２０３の整備会社カレンダー１５７の整備時期を示す箇所に、修理タスク情報１５９を割り当てる。その後、修理タスク生成部１１３は、本フローチャートの処理を終了する。即ち、図５に示すステップＳ３１７に処理が進行する。

修理タスク生成部１１３が、対象車両２０２の空き時期による組合せでないと判定する場合（ステップＳ１３０６で「ｎｏ」の場合）、修理タスク生成部１１３は、他の車両２０２が運送タスクの実行が可能であるか否かを判定する（ステップＳ１３０８）。特定された組合せが、対象車両２０２の空き時期による組合せでない場合、該組合せは整備会社２０３と他の車両２０２との空き時期の組合せである。修理タスク生成部１１３は、組合せに係る時期における対象車両２０２の車両カレンダー１５６を参照し、対象車両２０２に割り当てられた運送タスク情報１５８を特定する。

修理タスク生成部１１３は、運送タスク情報１５８における荷物の重量を特定する。また、修理タスク生成部１１３は、組合せに係る他の車両２０２の車両情報１５２を参照して車体重量を特定し、特定した重量の荷物を該他の車両２０２が運送可能であるか否かを判定する。修理タスク生成部１１３は、他の車両２０２において荷物の運送が可能である場合に、処理をステップＳ１３０９に進める。

修理タスク生成部１１３が、他の車両２０２が運送タスクの実行が可能であると判定する場合（ステップＳ１３０８で「ｙｅｓ」の場合）、修理タスク生成部１１３は、整備時期を特定し、修理タスク情報１５９を生成する（ステップＳ１３０９）。本ステップにおいて行われる処理は、ステップＳ１３０７において行われる処理と同様であるため、説明を省略する。

図１４は、予知メンテナンスの概要を説明するための図（その２）である。図１４（ａ）は、整備日程の調整の一例を示す。車両Ａが対象車両２０２であって、残寿命の終期に近い日程において、整備会社２０３と他の車両２０２との空き日程がある場合、対象車両２０２の運送タスクが他の車両２０２に割り当てられる。結果として、空き日程に車両Ａの修理タスクが実行される。

なお、本処理において、残寿命の終期に近い時期を整備時期に特定するのは、残寿命の期間は運送が可能であるため、なるべく遅い時期に整備を行う方が経済的であって、かつ１車両における総整備回数を削減しうるためである。

説明を図１３に戻す。次に、運送タスク生成部１１２は、他の車両２０２について運送タスク情報１５８を生成する（ステップＳ１３１０）。具体的には、運送タスク生成部１１２は、ステップＳ１３０９において特定された整備時期に対象車両２０２が実行する予定であった運送タスク情報１５８を特定し、ステップＳ１３０５において特定された組合せに係る他の車両２０２の車両カレンダー１５６の整備時期に該当する箇所に格納する。

また、運送タスク生成部１１２は、整備時期において対象車両２０２の車両カレンダー１５６に格納された運送タスク情報１５８を削除する。運送タスク生成部１１２は、その後本フローチャートの処理を終了する。

図１４（ｂ）は、運送タスクの調整の概要を示す図である。本図において、車両Ａが対象車両２０２であって、車両Ｂが組合せに係る他の車両２０２である。車両Ｂに空き時期がある場合、車両Ａの運送タスクを車両Ｂに割り振ることが可能である。即ち、車両Ａに替わって車両Ｂが運送を行うこととなる。

説明を図１３に戻す。修理タスク生成部１１３が、他の車両２０２が運送タスクの実行が可能でないと判定する場合（ステップＳ１３０８で「ｎｏ」の場合）、修理タスク生成部１１３は、ステップＳ１３０５において特定された組合せの特定を終了する（ステップＳ１３１１）。その後、修理タスク生成部１１３は処理をステップＳ１３０５に戻す。結果として、ステップＳ１３１１において特定を終了した組合せを除く他の組合せのうち、最も時期の遅い組合せがステップＳ１３０５で特定される。

図１５は、予知メンテナンスのスケジューリング処理の一例を示す図である。本図において、車両Ａが対象車両２０２であって、車両Ｂが車両Ａと同じ運送会社２０１に属する他の車両２０２であって、整備会社Ｃは車両Ａを整備する会社として予め整備会社情報１５３に記憶されている整備会社２０３である。整備会社Ｃは１日当たり２台まで整備が可能である。

車両Ａにおいて、第２の閾値以上の信号値が算出（即ち異常が検知）されてから、当該信号値に係る残寿命が尽きるまでの期間が走行可能期間として扱われる。修理タスク生成部１１３は、走行可能期間の整備会社２０３の空き時期を抽出する。その結果、整備候補時期を示す情報として、「ｒ１」と、「ｒ２」と、「ｒ３」と、「ｒ４」と、「ｒ５」とが抽出される。

また、修理タスク生成部１１３は、走行可能期間の対象車両２０２の空き時期を抽出する。整備会社２０３の四角形は１日当たりの整備予定車両２０２の有無を示している。車両Ａの「ｔ１」は、整備会社２０３の四角形１つ分の１．５倍の大きさであり、これは運送タスク「ｔ１」が１．５日に渡ることを示している。修理タスク生成部１１３は、所定期間（例えば１日）未満の空き時期は、空き時期とみなさない。図１５に示す一例において、車両Ａは、走行可能期間に１日間の空き時期を有さないため、修理タスク生成部１１３は対象車両２０２の空き時期を抽出しない。

また、修理タスク生成部１１３は、走行可能期間の他の車両２０２の空き時期を抽出する。修理タスク生成部１１３は、車両Ｂの走行可能期間の空き時期を示す情報として、「ｂ１」と、「ｂ２」とを抽出する。

次に、修理タスク生成部１１３は、整備会社２０３の空き時期と、対象車両２０２又は他の車両２０２の空き時期との組合せを抽出する。その結果、「ｒ１：ｂ１」と、「ｒ４：ｂ２」と、「ｒ５：ｂ２」との組合せが抽出される。

次に、修理タスク生成部１１３は、抽出した組合せのうち最も時期の遅い組合せを特定する。その結果、最も時期の遅い組合せである「ｒ５：ｂ２」の組合せが特定される。

当該組合せに係る時期に該当する車両Ａの運送タスクは「ｔ４」である。運送タスク生成部１１２は、「ｔ４」の運送タスク情報１５８を参照し、当該運送タスクを車両Ｂが実行可能であるか否かを判定する。「ｔ４」を車両Ｂが実行可能であると判定されると、修理タスク生成部１１３は、「ｒ５：ｂ２」に相当する時期を整備時期に特定して修理タスク情報１５９を生成し、車両Ａの車両カレンダー１５６及び整備会社Ｃの整備会社カレンダー１５７に格納する。

また、運送タスク生成部１１２は、「ｔ４」の運送タスクを車両Ｂが実行するよう運送タスク情報１５８を生成し、車両Ｂの車両カレンダー１５６に格納する。

説明を図５に戻す。制御部１１０が、仮想時計の現在時刻が正午でないと判定する場合（ステップＳ３０９で「ｎｏ」の場合）、又はステップＳ３１６の処理の後、制御部１１０は仮想時計を１時間進める（ステップＳ３１７）。その後、ステップＳ３１８において処理がステップＳ３０５に戻り、仮想時計が１時間進んだ状態でステップＳ３０６からステップＳ３１６の処理が繰り返される。なお、繰り返して処理を行った結果、シミュレーション条件として入力されたシミュレーションの終了時期に達した場合、制御部１１０は処理をステップＳ３１９に進行させる。

シミュレーションの終了時期に達した場合、集計計算部１１７は、集計計算処理を行う（ステップＳ３１９）。具体的には、集計計算部１１７は、運送タスク情報１５８を用いて運送料金を算出するとともに、修理タスク情報１５９を用いて整備料金を算出する。なお、本処理開始前に、制御部１１０は保守計画評価情報の生成対象となる運送会社２０１又は整備会社２０３の指定を受け付けている。

保守計画評価情報の生成対象として、運送会社２０１の指定を受け付けた場合、集計計算部１１７は、指定された運送会社２０１の有する車両２０２の車両カレンダー１５６において、保守計画評価情報の生成要求期間に割り当てられた運送タスク情報１５８を参照することにより、指定された運送料金を算出する。集計計算部１１７は、例えば運送距離と荷物重量に応じて運送料金を算出する。一例として、集計計算部１１７は、運送距離１ｋｍあたり１００円の基本料金に対して、運送距離１ｋｍ、荷物重量１トン毎に１００円の重量加算料金を加算することにより、運送料金を算出する。なお、運送距離及び荷物の重量は、運送タスク情報１５８を参照することにより特定可能である。

例えば運送距離２００ｋｍ、荷物重量が４トンの場合、２００ｋｍ×１００円＝２００００円の基本料金に対して、２００ｋｍ×４トン×１００円＝８００００円の重量加算料金が加算され、運送料金が１０００００円となる。算出された運送料金は、運送会社２０１に対しては収益として取り扱われる。

また、集計計算部１１７は、燃料消費量を算出する。燃料消費量は、例えば燃料１リットル当たりの走行距離である燃費と、燃料の１リットル当たりの価格とを用いて算出される。また、集計計算部１１７は、高速道路利用等により生じる費用を算出してもよい。燃料消費量は運送会社２０１に対しては費用として取り扱われる。

このほか、集計計算部１１７は、記憶部１５０の図示しない領域に記憶された運転手の単位時間当たりの作業費に、稼働時間を乗じて得た運転手の総作業費を、費用として計上してもよい。また、集計計算部１１７は、シミュレーション条件として入力されたサービス会社２０４を特定する情報毎に、予め定められたサービス料金を、費用として計上してもよい。

なお、運送料金及び燃料消費量の算出方法はこの限りでない。例えば運送タスクの単位数量当たりの平均金額に、保守計画評価情報の生成要求期間内に実行された運送タスクの量を乗じることにより、運送料金を算出してもよい。

また、集計計算部１１７は、整備会社カレンダー１５７において、保守計画評価情報の生成要求期間に割り当てられた修理タスク情報１５９を参照することにより、整備料金を算出する。集計計算部１１７は、例えば整備会社情報１５３を参照することにより整備会社２０３の単位時間当たりのメニュー価格を特定し、整備に要した時間を乗じることにより、整備料金を算出する。整備料金は、運送会社２０１に対しては費用として取り扱われ、整備会社２０３に対しては収益として取り扱われる。

また、集計計算部１１７は、整備費用を算出する。集計計算部１１７は、例えば整備会社情報１５３を参照することにより整備会社２０３の単位時間当たりの実作業費を特定し、整備に要した時間を乗じることにより、総作業費を算出する。集計計算部１１７は、整備に要したパーツの価格と総作業費とを加算することにより、整備費用を算出する。整備費用は、整備会社２０３にとって費用として取り扱われる。

なお、後述する保守計画評価情報の出力処理において、保守計画評価部１１６は、車両２０２や整備会社２０３の稼働率を含む保守計画評価情報や、車両２０２の予定を含む保守計画評価情報や、運送会社２０１又は整備会社２０３の能力消費の状態を示す保守計画評価情報を生成することができる。これらの保守計画評価情報を生成する場合、保守計画評価部１１６は、ステップＳ３１９による処理よりも前に、生成する保守計画評価情報の種別と、保守計画評価の対象となる運送会社２０１又は整備会社２０３を特定した表示指示の入力を受け付ける。

車両２０２の稼働率を指定した保守計画評価情報の表示指示を受け付けた場合、集計計算部１１７は、ステップＳ３１９において、表示指示において特定された運送会社２０１の有する車両２０２の運送タスクの走行時間である稼働時間と、運送時間と、整備に要する時間である保守時間と、車両２０２が走行することができない期間であるダウンタイムとを算出する。

整備会社２０３の稼働率を指定した保守計画評価情報の表示指示を受け付けた場合、集計計算部１１７は、整備会社における整備可能台数に対する単位時間当たりの整備台数の割合を稼働率として算出する。

運送会社２０１の能力消費の状態を示す保守計画評価情報の表示指示を受け付けた場合、集計計算部１１７は、保守計画評価情報の生成要求期間における、運送会社２０１の有する車両２０２の稼働状態を示す能力消費量を算出する。集計計算部１１７は、例えば生成要求期間における単位時間（例えば１日）当たりの稼働車両数を算出する。

整備会社２０３の能力消費の状態を示す保守計画評価情報の表示指示を受け付けた場合、集計計算部１１７は、保守計画評価情報の生成要求期間における、整備会社２０３の稼働状態を示す能力消費量を算出する。集計計算部１１７は、例えば生成要求期間における単位時間（たとえば１日）当たりの整備車両数（即ち修理タスクの数）を算出する。

次に、保守計画評価部１１６は、保守計画評価情報を出力部１３０に出力させる（ステップＳ３２０）。具体的には、保守計画評価部１１６は、保守計画評価情報として、運送料金及び整備料金を表示する保守計画評価画面の表示情報を生成し、出力部１３０に出力させる。保守計画評価部１１６は、その後本フローチャートの処理を終了する。

図１６は、保守計画評価画面の一例を示す図である。図１６（ａ）は、指定された運送会社２０１に対して、当該運送会社２０１の有する車両２０２のすべてに予知メンテナンスを行うようシミュレーション条件の入力を行った場合と、当該車両２０２に定期メンテナンスを行うようシミュレーション条件の入力を行った場合と、当該車両２０２に定期メンテナンス及び予知メンテナンスを行わず、故障が生じた場合に修理を行うようシミュレーション条件の入力を行った場合と、の費用及び収益を表示する保守計画評価画面の一例である。

なお、費用及び収益を含む保守計画評価画面については、運送会社２０１の費用及び収益に限定されるものではない。例えば整備会社２０３の費用及び収益であってもよい。

図１６（ｂ）は、車両２０２の稼働率を示す保守計画評価画面の表示指示を受け付けた場合の、保守計画評価画面の一例を示す図である。

図１６（ｂ）は、指定された運送会社２０１に対して、当該運送会社２０１の有する車両２０２のすべてに予知メンテナンスを行うようシミュレーション条件の入力を行った場合と、当該車両２０２に定期メンテナンスを行うようシミュレーション条件の入力を行った場合と、当該車両２０２に定期メンテナンス及び予知メンテナンスを行わず、故障が生じた場合に修理を行うようシミュレーション条件の入力を行った場合と、の各々に対して、稼働時間、運送時間、保守時間、及びダウンタイムの生成要求期間に対する割合である稼働率を表示する保守計画評価画面の一例である。

なお、稼働率については円グラフを用いて表示してもよい。また、稼働率は、稼働時間、運送時間、保守時間、及びダウンタイムの、走行可能期間に対する割合であってもよい。

また、整備会社２０３の稼働率を指定した保守計画評価情報の表示指示を受け付けた場合、保守計画評価部１１６は、算出した整備会社２０３の稼働率を示す保守計画評価情報を生成し、出力部を介して出力させる。

図１７は、運送会社２０１の有する車両２０２の予定を含む保守計画評価画面の一例を示す図である。保守計画評価部１１６は、指定された運送会社２０１の有する車両２０２の車両カレンダー１５６を参照し、保守計画評価情報の生成要求期間における各車両２０２の運送タスク及び修理タスクの実行状況を示す保守計画評価画面を生成する。

図１７は、車両２０２のガントチャートを示す図であって、横軸を時間軸とし、縦軸に車両２０２を表示している。ガントチャートは、車両の稼働予定を示している。黒い四角形６０１が運送タスクの量を示し、白い四角形６０２が修理タスクの量を示している。

図１８は、能力消費の状態を示す保守計画評価画面の一例を示す図である。図１８（ａ）は、運送会社２０１の能力消費の状態を示す保守計画評価画面の一例である。本図は、横軸を時間軸とし、縦軸を運送会社２０１の実行する運送タスクの量としている。本図において、黒い四角形７０１は運送タスクがある状態を示している。保守計画評価部１１６は、集計計算部１１７の算出した単位時間当たりの稼働車両数を用いて、運送会社２０１の能力消費の状態を示す保守計画評価画面を生成する。

図１８（ｂ）は、整備会社２０３の能力消費の状態を示す保守計画評価画面の一例である。本図は、横軸を時間軸とし、縦軸を整備会社２０３の実行する修理タスクの量としている。本図において、黒い四角形７０２は修理タスクがある状態を示している。保守計画評価部１１６は、集計計算部１１７の算出した単位時間当たりの修理タスクの量を用いて、整備会社２０３の能力消費の状態を示す保守計画評価画面を生成する。

なお、整備会社２０３の能力消費の状態を示す保守計画評価画面には、整備会社２０３の整備可能な車両数の上限値を示す情報が表示されていてもよい。付言すると、シミュレーション条件において整備会社２０３の整備可能な車両数の上限値を入力しない場合、修理タスクのスケジューリングにおいて整備会社２０３の能力による制限が考慮されない。そのため、運送会社２０１の必要とする整備会社２０３の能力、即ち運送会社２０１により実行が要求される単位時間当たりの修理タスクの量を認識することができる。

本実施形態において生成される保守計画評価情報により、車両２０２の整備方式による収益及び費用の違いを認識することができる。これにより、整備方式による保守計画評価を適切に行うことが可能となる。また、車両２０２の稼働率を含む保守計画評価情報を生成することにより、整備方式による所要時間の違いを認識することができる。その場合に、車両２０２の予定を示す保守計画評価情報を表示すれば、生成要求期間における車両２０２の予定を認識することが可能となる。

また、運送会社２０１及び整備会社２０３における能力消費量を用いて保守計画評価情報を生成することにより、シミュレーションにおいて運送会社２０１や整備会社２０３の有する能力のうちどの程度が活用されたかを認識することができる。

なお、保守計画評価画面のグラフィックスについては、図１６、図１７、及び図１８に示す態様に限定されるものではない。

＜変形例＞

次に、車両保守計画装置１の変形例について説明する。車両２０２に関する異常検知処理において、不具合が発生していないにも係わらず不具合が検知されたものとして運送会社２０１に虚報が通知される事や、不具合が発生していながら不具合が検知されない見逃しが生じる事等の、検知の誤りが発生するおそれがある。

本変形例における車両保守計画装置１の異常検知部１１４は、状態情報に対し所定の数式を用いることにより、誤状態情報を生成する。修理タスク生成部１１３は、状態情報と誤状態情報の組合せに応じて、修理タスク情報１５９を生成する。以下、上述の実施形態と異なる点について説明する。

図１９は、異常検知の誤りの問題点を説明するための図である。図１９（ａ）は、不具合がないにも関わらず、「緊急」を示す状態情報が特定された系統を有する車両２０２に関する図である。「緊急」を示す状態情報が特定されたため、修理タスク生成部１１３は該系統の残寿命までに整備会社２０３の空き時期に、予知メンテナンスを予定する修理タスク情報１５９を生成する。

また、運送タスク生成部１１２は、該車両２０２の運送タスクをキャンセルする。実際には、修理タスクにおいて系統の整備を必要としないため、サービス会社２０４から運送会社２０１へと送信される、予知メンテナンスを行うことを示す通知は、「虚報」であると考えられる。運送会社２０１は、整備対象の車両２０２について運送タスク実行による収益を得ることができず、また整備会社２０３に対しても点検費用が発生することになるため、虚報によって生じる損失は看過できない。

図１９（ｂ）は、不具合があるにも関わらず、「緊急」を示す状態情報が特定されなかった系統を有する車両２０２に関する図である。「緊急」を示す状態情報が特定されなかった結果、該系統は故障し、該系統を有する車両２０２に割り当てられた運送タスクは中断せざるを得なくなる。この場合、予知メンテナンスが必要であったにも関わらず、「緊急」の状態情報が生成されなかったため、異常検知において「見逃し」があったと考えられる。

また、当該車両２０２は修理を余儀なくされるため、予知メンテナンスにおける整備よりも、故障の修理に要する費用の方が高額である場合、運送会社２０１の支払う費用はより高額となる。運送会社２０１にとっては、ダウンタイムの間に該車両２０２に運送タスクを割り当てることができないため、見逃しによる運送タスク実行の機会損失が発生する。また、実行中の運送タスクの中断により、罰金等の予期しない損失が発生する可能性がある。

図２０は、虚報見逃し誤り判定処理の概要を示す図である。本図は、虚報見逃し誤り判定の概念について説明するために用いられる。本図は、虚報見逃し誤り判定をサービス会社２０４にて行う実態を示しているが、車両保守計画装置１は本図における処理を模擬的にシミュレーションする。

まず、図１１に示すステップＳ１２２１と同様に、サービス会社２０４は、予め契約している運送会社２０１の車両２０２を監視し、当該車両２０２の各系統の状態を検知するよう設置されたセンサから発生した信号値を受信する（ステップＳ１３０１）。

次に、サービス会社２０４は、信号値を用いて、異常状態を判定する（ステップＳ１３０２）。ステップＳ１３０２の異常状態判定処理は、真の判定処理（ステップＳ１５０１）と、誤状態情報生成処理（ステップＳ１５０２）とを有する。真の判定処理は、図１１に示すステップＳ１２２２において行われる処理と同様である。真の判定処理の結果、対象車両２０２の有する各系統の状態情報が特定される。以下、真の判定処理の結果特定される状態情報を、「真状態情報」として説明する。

誤状態情報生成処理において、サービス会社２０４は、真状態情報を用いて誤状態情報を生成し、誤状態情報を運送会社２０１に通知する（ステップＳ１３０３）。また、サービス会社２０４は、誤状態情報を整備会社２０３に通知する（ステップＳ１３０４）。ステップＳ１３０５及びステップＳ１３０６において行われる処理は、図１１に示すステップＳ１２２５及びステップＳ１２２６において行われる処理と同様であるため、説明を省略する。

サービス会社２０４における異常状態の判定処理（ステップＳ１３０２）は、車両保守計画装置１において行われる異常検知処理（図５に示すステップＳ３１５）に対応している。上述の実施形態と同様に、車両保守計画装置１の異常検知部１１４は信号値取得部１１５により取得された信号値を用いて系統毎に状態情報を特定する。特定された状態情報は、真状態情報として取り扱う。

同ステップにおいて、異常検知部１１４は、真状態情報に対して所定の数式を用いて誤状態情報を生成する。具体的には、真状態情報^trueAlarmSatus_i(i=1..4)が誤状態情報^falseAlarmStatus_j(j=1..4)に変換される確率(誤り確率)を^falsep_i ^jとする。式(11)は行列表現であり、式(12)を満たす。

右下添え字のインデックスiは真状態情報、右上添え字のインデックスjは誤状態情報を特定するインデックスである。誤り確率は範囲[0,1]の値となり、一切の誤りが無い場合は^falsep=Eの単位行列となる。誤状態情報への変換では範囲[0,1)の一様乱数を生成し、インデックスiの真状態情報に応じて乱数値rを、式(14)で確率の範囲で判定して、インデックスjを定めて、誤状態情報である^falseAlarmStatusを求める。インデックスjの値が誤状態情報を特定する識別番号である。

ここで、^falseP_i ^jは誤異常状態に関する累積誤り確率を意味し、式(12)の通りに、^falseP_i ⁴=1である。インデックスjは１から４までの整数であり、特にj-1=0 (j=1)の場合、累積誤り確率は0、もしくは存在しないと扱う。

図２１は、真状態情報と誤状態情報の組合せに対する、異常検知と予知メンテナンスの意味の対応表の一例を示す図である。真状態情報が「故障（Critical）」の場合、誤状態情報に関わらず系統を故障として取り扱う。また、誤状態情報が「故障（Critical）」であったとしても、真状態情報が「故障（Critical）」でない限り故障として取り扱わず、「緊急（Urgent）」として取り扱う。

真状態情報が「正常（Normal）」であるにも関わらず、誤状態情報が「警告（Alert）」、又は「緊急（Urgent）」となる場合、虚報の発生と考え、整備が不要であると取り扱う。真状態情報が「警告（Alert）」、又は「緊急（Urgent）」であるにも関わらず、誤状態情報が「正常（Normal）」となる場合、見逃しの発生と考え、予知メンテナンスを行う。真状態情報が「警告（Alert）」、又は「緊急（Urgent）」であって、誤状態情報が真状態情報と一致する場合には、正しい判定がなされているものと取り扱う。

また、真状態情報が「緊急（Urgent）」であって、誤状態情報が「警告（Alert）」である場合において、真状態情報に応じた整備が予定されている場合、整備が不十分であるものと取り扱う。また、真状態情報が「警告（Alert）」であって、誤状態情報が「緊急（Urgent）」である場合において、真状態情報に応じた整備が予定されている場合、過剰な整備が予定されているものと取り扱う。

図５のステップＳ３１６において、真状態情報と誤状態情報の組合せに応じて実行する整備を特定して修理タスク情報１５９を生成し、対応する車両カレンダー１５６及び整備会社カレンダー１５７に格納する。

図５のステップＳ３１９で行われる集計計算処理において、誤り判定の組合せ毎に運送料金及び整備料金を算出することで、誤り判定の保守計画評価への影響を考慮した保守計画評価情報を生成することができる。

以上、本発明に係る各実施形態及び変形例の説明を行ってきたが、本発明は、上記した実施形態の一例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態の一例は、本発明を分かり易くするために詳細に説明したものであり、本発明は、ここで説明した全ての構成を備えるものに限定されない。また、ある実施形態の一例の構成の一部を他の一例の構成に置き換えることが可能である。また、ある実施形態の一例の構成に他の一例の構成を加えることも可能である。また、各実施形態の一例の構成の一部について、他の構成の追加・削除・置換をすることもできる。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、図中の制御線や情報線は、説明上必要と考えられるものを示しており、全てを示しているとは限らない。ほとんど全ての構成が相互に接続されていると考えてもよい。

また、上記の車両保守計画装置１の機能構成は、理解を容易にするために、主な処理内容に応じて分類したものである。構成要素の分類の仕方や名称によって、本願発明が制限されることはない。上述に示す通り、車両保守計画装置１の構成は、処理内容に応じて、さらに多くの構成要素に分類することもできる。また、１つの構成要素がさらに多くの処理を実行するように分類することもできる。

１：車両保守計画装置、１１０：制御部、１１１：条件情報取得部、１１２：運送タスク生成部、１１３：修理タスク生成部、１１４：異常検知部、１１５：信号値取得部、１１６：保守計画評価部、１１７：集計計算部、１２０：入力部、１３０：出力部、１４０：通信部、１５０：記憶部、１５１：運送会社情報、１５２：車両情報、１５３：整備会社情報、１５４：管理基準情報、１５５：劣化関数情報、１５６：車両カレンダー、１５７：整備会社カレンダー、１５８：運送タスク情報、１５９：修理タスク情報、１６０：整備内容情報、１６１：パーツ情報、１６２：整備会社パーツ在庫情報、１６３：状態量情報、１７１：ＣＰＵ、１７２：ＲＡＭ、１７３：ＲＯＭ、１７４：補助記憶装置、１７５：出力装置、１７６：入力装置、１７７：メディア読取装置、１７８：通信装置、２０１：運送会社、２０２：車両、２０３：整備会社、２０４：サービス会社、４０１：シミュレーション条件入力画面、４０２：サービス会社入力領域、４０３：運送会社入力領域、４０４：車両入力領域、４０５：整備会社入力領域、４０６：期間入力領域、４０７：条件設定ボタン、４０８：開始ボタン、４０９：キャンセルボタン、６０１・７０１・７０２：黒い四角形、６０２：白い四角形、１００１：引取、１００２・１００４：運送、１００３・１００６：停止、１００５・１００７：帰社

Claims (20)

1. 運送会社と１又は複数の車両とを関連付けた運送会社情報と、整備会社と整備を行う前記車両とを関連付けた整備会社情報と、前記車両と当該車両の有する１又は複数の系統及び整備方式とを関連付けた車両情報と、を取得する条件情報取得部と、
   前記運送会社に割り当てる運送タスク情報を生成する運送タスク生成部と、
   前記運送タスク情報を用いて前記車両の系統毎に信号値を算出する信号値取得部と、
   前記整備方式及び前記信号値を用いて前記車両の整備に関する修理タスク情報を生成し、前記整備会社に割り当てる修理タスク生成部と、
   前記運送タスク情報を用いて運送料金を算出するとともに、前記修理タスク情報を用いて整備料金を算出する集計計算部と、
   前記運送料金及び前記整備料金を含む保守計画評価情報を生成する保守計画評価部と、
   前記保守計画評価情報を出力する出力部と、を備えることを特徴とする、車両保守計画装置。
2. 請求項１に記載の車両保守計画装置であって、
   前記条件情報取得部は、前記車両の予定に関する車両カレンダーと、前記整備会社の予定に関する整備会社カレンダーと、前記保守計画評価情報の生成要求期間とを取得し、
   前記運送タスク生成部は、前記運送タスク情報を前記車両カレンダーの空き領域に割り当て、
   前記修理タスク生成部は、前記車両に割り当てられた前記運送タスク情報を用いて算出された前記信号値と、該車両に対し関連付けられた整備方式と、を用いて特定された整備時期を特定した前記修理タスク情報を生成し、前記車両カレンダー及び前記整備会社カレンダーの空き領域に割り当て、
   前記保守計画評価部は、整備対象の前記系統の前記生成要求期間における整備に要する前記整備料金を用いて前記保守計画評価情報を生成することを特徴とする、車両保守計画装置。
3. 請求項２に記載の車両保守計画装置であって、
   前記運送タスク生成部は、引取地を示す始点座標と、目的地を示す終点座標と、荷物の重量と、の少なくとも１つに対し乱数を用いて前記運送タスク情報を生成するとともに、前記車両カレンダーのうち予め定められた車両稼働時間の前記空き領域に前記運送タスク情報を割り当てることを特徴とする、車両保守計画装置。
4. 請求項１に記載の車両保守計画装置であって、
   前記集計計算部は、前記車両について算出された前記運送料金と、該車両について算出された前記整備料金と、を用いて前記運送会社又は前記整備会社の収益及び費用を特定し、
   前記出力部は、前記収益及び費用を含む保守計画評価画面を出力することを特徴とする、車両保守計画装置。
5. 請求項１に記載の車両保守計画装置であって、
   前記集計計算部は、前記運送会社の有する前記車両について算出された前記運送料金を用いて該運送会社の収益を特定するとともに、該車両について算出された前記整備料金を用いて該運送会社の費用を特定し、
   前記保守計画評価部は、前記収益及び前記費用を含む前記運送会社の前記保守計画評価情報を生成することを特徴とする、車両保守計画装置。
6. 請求項１に記載の車両保守計画装置であって、
   前記集計計算部は、前記車両情報に含まれる前記整備方式毎に、前記車両又は前記整備会社の稼働率を算出し、
   前記出力部は、前記稼働率を含む保守計画評価画面を出力することを特徴とする、車両保守計画装置。
7. 請求項２に記載の車両保守計画装置であって、
   前記集計計算部は、前記生成要求期間における前記運送会社又は前記整備会社の稼働状態を示す能力消費量を算出し、
   前記出力部は、前記能力消費量を含む保守計画評価画面を出力し、
   前記運送会社の前記能力消費量は、該運送会社の有する前記車両の稼働状態を示す値であることを特徴とする、車両保守計画装置。
8. 請求項２に記載の車両保守計画装置であって、
   前記保守計画評価部は、前記車両カレンダーに割り当てられた前記運送タスク情報と前記修理タスク情報を用いて保守計画評価情報を生成し、
   前記出力部は、前記保守計画評価情報により特定される前記車両の稼働予定を示すガントチャートを含む保守計画評価画面を出力することを特徴とする、車両保守計画装置。
9. 請求項１に記載の車両保守計画装置であって、
   前記出力部は、前記運送会社に対し整備を依頼する前記整備会社の入力を受け付ける運送会社入力領域と、前記車両に対し該車両を有する前記運送会社と前記整備方式との入力を受け付ける車両入力領域と、を含むシミュレーション条件入力画面を表示し、
   前記条件情報取得部は、前記シミュレーション条件入力画面に対して入力された情報を用いて前記運送会社情報と前記整備会社情報と前記車両情報とを取得することを特徴とする、車両保守計画装置。
10. 請求項１に記載の車両保守計画装置であって、
    前記信号値を用いて、前記系統の状態を示す状態情報を特定する異常検知部を備え、
    前記条件情報取得部は、前記信号値に応じて段階的に定められた複数の前記状態情報を含む管理基準情報を取得し、
    前記信号値取得部は、前記運送タスク情報を用いて特定される走行距離を用いて前記信号値を算出し、
    前記異常検知部は、前記管理基準情報において前記信号値と対応する前記状態情報を特定し、
    前記修理タスク生成部は、前記状態情報及び前記整備方式を用いて整備対象の前記系統を特定することを特徴とする、車両保守計画装置。
11. 請求項１０に記載の車両保守計画装置であって、
    前記異常検知部は、前記状態情報に対して所定の数式を用いて誤状態情報を生成し、
    前記修理タスク生成部は、前記状態情報と前記誤状態情報との組合せに応じて前記修理タスク情報を生成することを特徴とする、車両保守計画装置。
12. 請求項２に記載の車両保守計画装置であって、
    前記修理タスク生成部は、前記修理タスク情報において特定された前記整備時期後の前記車両の状態を示す値である状態量を、該系統に係る前記車両に対し前記運送タスク情報を割り当てる前の値に戻すことを特徴とする、車両保守計画装置。
13. 請求項２に記載の車両保守計画装置であって、
    前記車両情報は、定期メンテナンス、予知メンテナンス、又は事後の修理の少なくともいずれか１つを含む前記整備方式が前記車両に関連付けられ、
    前記整備会社情報は、整備が可能な前記車両の数の上限値が前記整備会社に関連付けられ、
    前記修理タスク生成部は、前記定期メンテナンスを示す前記整備方式が関連付けられた前記車両について、予め定められた期間毎に整備候補時期を特定して前記整備会社カレンダーを参照し、前記車両の数が前記上限値に達しておらずかつ前記整備候補時期以降の最も近い時期を前記整備時期に特定して前記整備会社カレンダー及び前記車両カレンダーを更新することを特徴とする、車両保守計画装置。
14. 請求項２に記載の車両保守計画装置であって、
    前記整備会社情報は、整備が可能な前記車両の数の上限値が前記整備会社に関連付けられ、
    前記信号値取得部は、ある検知時期における前記信号値を算出し、
    前記修理タスク生成部は、第１の閾値以上の前記信号値が算出された前記系統に係る前記車両について、前記整備会社カレンダーを参照し、前記車両の数が前記上限値に達しておらずかつ前記信号値に係る前記検知時期以降該検知時期に最も近い時期を前記整備時期に特定して前記整備会社カレンダー及び前記車両カレンダーを更新することを特徴とする、車両保守計画装置。
15. 請求項２に記載の車両保守計画装置であって、
    前記車両情報は、前記系統毎に残寿命を示す値を含み、
    前記整備会社情報は、整備が可能な前記車両の数の上限値が前記整備会社に関連付けられ、
    前記信号値取得部は、ある検知時期における前記信号値を算出し、
    前記修理タスク生成部は、第２の閾値以上の前記信号値が算出された前記系統に関する車両について、前記整備会社カレンダーを参照し、割り当てられた前記修理タスク情報に係る前記車両の数が前記上限値に達しておらず、かつ当該系統に係る前記残寿命までの期間のうち最も遅い時期であって、かつ第２の閾値以上の前記信号値の算出に係る前記検知時期以降の時期を前記整備時期に特定して前記整備会社カレンダー及び前記車両カレンダーを更新することを特徴とする、車両保守計画装置。
16. 請求項２に記載の車両保守計画装置であって、
    前記車両情報は、前記系統毎に残寿命を示す値を含み、
    前記信号値取得部は、ある検知時期における前記信号値を算出し、
    前記修理タスク生成部は、第２の閾値以上の前記信号値が算出された前記系統に関する前記車両を整備対象車両として特定し、
    前記整備対象車両と同じ前記運送会社に関連付けられた前記１又は複数の前記車両の前記車両カレンダーと前記整備会社カレンダーを参照し、前記車両と前記整備会社とにおいて予定の入っていない１又は複数の空き時期を抽出するとともに、前記空き時期のうち前記残寿命までの期間中最も遅い時期を整備時期に特定し、
    前記整備時期に係る前記車両が前記整備対象車両でない場合に、該整備時期において前記整備対象車両に割り当てられた前記運送タスク情報を前記整備時期に係る前記車両に割り当てるとともに、前記整備対象車両に割り当てられた前記運送タスク情報を削除し、
    前記整備対象車両の前記車両カレンダーと前記整備会社カレンダーとの前記空き時期に、前記信号値の算出に係る前記系統の前記修理タスク情報を割り当てることを特徴とする、車両保守計画装置。
17. 請求項１に記載の車両保守計画装置であって、
    前記条件情報取得部は、整備に用いられるパーツ及び該パーツの価格を前記系統に対し関連付けたパーツ情報を取得し、
    前記車両情報は、前記系統の整備に要する前記パーツが関連付けられ、
    前記修理タスク生成部は、前記信号値を用いて特定した整備対象の前記系統を特定した前記修理タスク情報を生成し、
    前記集計計算部は、前記修理タスク情報に含まれる前記系統の整備に用いる前記パーツの価格と、前記信号値に応じて定められる作業時間に予め記憶された時間単価を乗じた作業費と、を用いて前記整備料金を算出することを特徴とする、車両保守計画装置。
18. 請求項１７に記載の車両保守計画装置であって、
    前記集計計算部は、前記整備会社について算出された前記整備料金を用いて前記整備会社の収益を特定するとともに、前記整備会社の用いた前記パーツの価格と前記作業費とを用いて前記整備会社の費用を特定し、
    前記保守計画評価部は、前記収益及び前記費用を含む前記整備会社の前記保守計画評価情報を生成することを特徴とする、車両保守計画装置。
19. 請求項１に記載の車両保守計画装置であって、
    前記条件情報取得部は、整備に用いられるパーツの在庫量を前記整備会社毎に関連付けた整備会社パーツ在庫情報を取得し、
    前記修理タスク生成部は、前記信号値を用いて整備対象の前記系統を特定し、特定した前記系統の整備に用いる前記パーツの在庫を有する前記整備会社に対し前記修理タスク情報を割り当てることを特徴とする、車両保守計画装置。
20. 車両保守計画装置が行う車両保守計画評価方法であって、
    前記車両保守計画装置は、条件情報取得部と、運送タスク生成部と、信号値取得部と、修理タスク生成部と、集計計算部と、保守計画評価部と、出力部と、を備え、
    前記条件情報取得部は、運送会社と１又は複数の車両とを関連付けた運送会社情報と、整備会社と整備を行う前記車両とを関連付けた整備会社情報と、前記車両と当該車両の有する１又は複数の系統及び整備方式とを関連付けた車両情報と、を取得する条件情報取得手順を実行し、
    前記運送タスク生成部は、前記運送会社に割り当てる運送タスク情報を生成する運送タスク生成手順を実行し、
    前記信号値取得部は、前記運送タスク情報を用いて前記車両の系統毎に該系統の信号値を算出する信号値取得手順を実行し、
    前記修理タスク生成部は、前記整備方式及び前記信号値を用いて前記車両の整備に関する修理タスク情報を生成し、前記整備会社に割り当てる修理タスク生成手順を実行し、
    前記集計計算部は、前記運送タスク情報を用いて運送料金を算出するとともに、前記修理タスク情報を用いて整備料金を算出する集計計算手順を実行し、
    前記保守計画評価部は、前記運送料金及び前記整備料金を含む保守計画評価情報を生成する保守計画評価手順を実行し、
    前記出力部は、前記保守計画評価情報を出力する表示手順を実行することを特徴とする、車両保守計画評価方法。

Images