(57)【要約】【課題】メンテナンスに伴う非稼働時間を考慮して稼働計画を立てるために有益な情報、及びメンテナンスを行うか否かの判断を行うための有益な情報を提供することが可能なショベル支援装置を提供する。【解決手段】ショベルの不具合事例に対応して、ショベルの動作状態を表す動作状態データと、プリメンテナンス作業の内容を表すメンテナンス作業データとを含む複数のレコードからなるデータベースが構築されている。メンテナンス作業データは、プリメンテナンス作業に要した作業時間情報を含む。処理装置が、評価対象のショベルから取得された動作状態データと、データベースに含まれているレコードの各々の動作状態データとの比較結果に基づいて、少なくとも１つのレコードを抽出し、抽出された前記レコードに格納されている作業時間情報を出力装置に出力する。【選択図】図３
2016190434.tif 000002
【特許請求の範囲】
【請求項１】
ショベルに出現した故障の予兆の事例に対応して、ショベルの動作状態を表す動作状態データと、プリメンテナンス作業の内容を表すメンテナンス作業データとを含む複数のレコードからなるデータベースにアクセス可能に構成された処理装置と、
出力装置と
を有し、
前記メンテナンス作業データは、プリメンテナンス作業に要した作業時間を表す作業時間情報を含み、
前記処理装置は、
評価対象のショベルから取得された前記動作状態データと、前記データベースに含まれている前記レコードの各々の前記動作状態データとの比較結果に基づいて、少なくとも１つの前記レコードを抽出し、抽出された前記レコードに格納されているプリメンテナンス作業に要した前記作業時間情報を前記出力装置に出力するショベル支援装置。
【請求項２】
前記メンテナンス作業データは、さらに、プリメンテナンス作業において交換した部品を示す交換部品情報を含み、
前記処理装置は、抽出された少なくとも１つの前記レコードの前記交換部品情報を前記出力装置に出力する請求項１に記載のショベル支援装置。
【請求項３】
前記メンテナンス作業データは、さらに、プリメンテナンス作業に要した費用を示す費用情報を含み、
前記処理装置は、抽出された少なくとも１つの前記レコードの前記費用情報を前記出力装置に出力する請求項１または２に記載のショベル支援装置。
【請求項４】
さらに、ショベルからの信号を受信して前記処理装置に転送する受信装置を有し、
前記処理装置は、ショベルで故障の予兆が出現したことを知らせる故障の予兆出現信号を受信すると、前記故障の予兆出現信号を送信したショベルを評価対象のショベルとして、少なくとも１つの前記レコードを抽出し、
抽出された少なくとも１つの前記レコードの前記メンテナンス作業データを前記出力装置に出力する請求項２に記載のショベル支援装置。
【請求項５】
前記処理装置は、前記評価対象のショベルから、実際に行われたプリメンテナンス作業の内容を表す前記メンテナンス作業データを受信すると、前記評価対象のショベルから受信された前記動作状態データと、前記メンテナンス作業データとを、１つのレコードとして前記データベースに追加する請求項４に記載のショベル支援装置。
【請求項６】
さらに、ショベルからの信号を受信して前記処理装置に転送する受信装置を有し、
前記出力装置は、ショベルに信号を送信する送信機を含み、
前記処理装置は、プリメンテナンス作業の見積もりを依頼する見積もり依頼信号を受信すると、前記見積もり依頼信号を送信したショベルを評価対象のショベルとして、少なくとも１つの前記レコードを抽出し、
抽出された少なくとも１つの前記レコードの前記メンテナンス作業データを、前記送信機から、前記見積もり依頼信号を送信したショベルに送信する請求項１乃至３のいずれか１項に記載のショベル支援装置。
【請求項７】
前記処理装置は、ショベルを特定してプリメンテナンス作業の見積もりを依頼する見積もり依頼コマンドが入力されると、前記見積もり依頼コマンドで特定されたショベルを前記評価対象のショベルとして、少なくとも１つの前記レコードを抽出し、
抽出された少なくとも１つの前記レコードの前記メンテナンス作業データを、前記出力装置に出力する請求項１乃至３のいずれか１項に記載のショベル支援装置。
【請求項８】
前記データベースの各レコードは、ショベルの外部環境に依存する外部環境データを含み、前記レコードは、前記外部環境データに基づいて複数のクラスタのいずれかに分類されており、
前記処理装置は、
評価対象のショベルから取得された前記外部環境データが類似する前記外部環境データを持つ前記クラスタを決定し、
評価対象のショベルから取得された前記外部環境データが類似する前記外部環境データを持つ前記クラスタに属する複数の前記レコードから、少なくとも１つの前記レコードを抽出する請求項１乃至７のいずれか１項に記載のショベル支援装置。
【請求項９】
前記データベースは、故障の予兆が出現している事例を、不具合事例に対応するレコードとして含み、当該レコードのメンテナンス作業データとして、プリメンテナンス作業の作業時間を含む請求項１乃至８のいずれか１項に記載のショベル支援装置。
【請求項１０】
前記故障の予兆が出現している事例に対応するレコードのメンテナンス作業データとして、さらに、プリメンテナンス作業で使用した部品を特定する情報を含む請求項９に記載のショベル支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ショベルのメンテナンスの支援を行うショベル支援装置に関する。
【背景技術】
【０００２】
下記の特許文献１に、ショベルに何らかの故障が発生したとき、故障が発生していると推定される複数の被疑部品を表示装置に表示するショベル及びショベル管理装置が開示されている。複数の被疑部品は、優先順位付けされて表示される。このため、容易に故障箇所を絞り込むことが可能である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第２０１３／０４７４０８号
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ショベルが故障に至る前にショベルのプリメンテナンスを行うことが好ましい。ただし、プリメンテナンスに必要となる時間が不明であると、そのショベルの稼働計画を立てにくい。また、ショベルに、稼働可能な程度の軽微な不具合が発生した場合、直ちにプリメンテナンスを行うか、そのまま稼働を継続するか、判断に迷う場合がある。本明細書において、稼働停止までは至らない軽微な不具合、及び直ちに修理することまでは必要とされない軽微な不具合を「故障の予兆」という。これに対し、不具合復旧作業（修理）が必要な状態を「故障」という。また、「故障の予兆」と「故障」とをまとめて「不具合」という。【０００５】
故障の予兆が出現した場合には、現段階で必ずしも不具合復旧作業を行う必要はない。ただし、このまま稼働を継続すると稼働不能な状態に至る危険性があるため、事前に点検作業を行い、必要であれば、事前に部品や消耗品の交換を行うことが好ましい。本明細書において、故障の予兆が出現した場合の点検作業、部品の交換作業を、「プリメンテナンス（予防保全）」という。また、プリメンテナンス、不具合調査、不具合復旧作業（修理）、定期点検等を「メンテナンス」という。【０００６】
故障の予兆が出現した場合、不具合復旧作業が必須ではないため、プリメンテナンスを行うべきか否かの判断を行うことが困難である。【０００７】
本発明の目的は、プリメンテナンスに伴う非稼働時間を考慮して稼働計画を立てるために有益な情報、及びプリメンテナンスを行うか否かの判断を行うための有益な情報を提供することが可能なショベル支援装置を提供することである。
【課題を解決するための手段】
【０００８】
本発明の一観点によると、
ショベルの不具合事例に対応して、ショベルの動作状態を表す動作状態データと、メンテナンス作業の内容を表すメンテナンス作業データとを含む複数のレコードからなるデータベースと、
出力装置と、
処理装置と
を有し、
前記メンテナンス作業データは、メンテナンス作業に要した作業時間を表す作業時間情報を含み、
前記処理装置は、
評価対象のショベルから取得された前記動作状態データと、前記データベースに含まれている前記レコードの各々の前記動作状態データとの比較結果に基づいて、少なくとも１つの前記レコードを抽出し、抽出された前記レコードに格納されている前記作業時間情報を前記出力装置に出力するショベル支援装置が提供される。
【発明の効果】
【０００９】
評価対象のショベルから取得された動作状態データと、データベースに含まれているレコードの各々の動作状態データとを比較することにより、過去の類似の不具合事例に対応するレコードを抽出することができる。出力された作業時間情報から、過去のプリメンテナンス作業に要した作業時間を確認することができる。ショベルのプリメンテナンスを行う場合、この作業時間情報に基づいてショベルの適切な稼働計画を立てることができる。プリメンテナンス作業に予測される作業時間は、稼働可能な程度の軽微な不具合が発生した場合、直ちにプリメンテナンスを行うか、そのまま稼働を継続するかの判断材料として利用することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例によるショベル支援装置のブロック図である。
【図２】図２Ａ及び図２Ｂは、データベースのレコードのフィールド構造を示す図である。
【図３】図３は、評価対象のショベルとショベル支援装置との間の信号送受信シーケンス、及びショベル支援装置の処理フローを示す図である。
【図４】図４は、動作状態データを構成する複数の変数を要素とするベクトル空間を示す図である。
【図５】図５Ａ及び図５Ｂは、ステップＳ３（図３）で出力される画像の一例を示す図である。
【図６Ａ】図６Ａは、図５Ｂの各レコードのリンクボタンをクリックまたはタップしたときに表示される画像の一例を示す図である。
【図６Ｂ】図６Ｂは、図５Ｂの２つのレコードのリンクボタンを選択したときに表示される画像の一例を示す図である。
【図７】図７は、他の実施例によるショベル支援装置、評価対象のショベル、及び管理装置の図である。
【図８】図８は、評価対象のショベル、管理装置、及びショベル支援装置の間の信号送受信シーケンス、及び処理フローを示す図である。
【図９】図９は、さらに他の実施例によるショベル支援装置を説明するための管理装置及び評価対象のショベルの間の信号送受信シーケンス、及び処理フローを示す図である。
【図１０】図１０は、さらに他の実施例によるショベル支援装置、管理装置、及び評価対象のショベルの間の信号送受信シーケンス、及び処理フローを示す図である。
【図１１】図１１は、さらに他の実施例によるショベル支援装置を説明するための管理装置及び評価対象のショベルの間の信号送受信シーケンス、及び処理フローを示す図である。
【図１２】図１２は、データベースのレコードのフィールド構造を示す図である。
【発明を実施するための形態】
【００１１】
図１に、実施例によるショベル支援装置として動作する携帯端末４０のブロック図を示す。携帯端末４０は、処理装置３１、データベース３２、受信装置３３、及び出力装置３４を含む。
【００１２】
処理装置３１は、例えば中央処理ユニット（ＣＰＵ）及びメモリを含み、ＣＰＵが、メモリに格納されているコンピュータプログラムを実行することにより、種々の機能が実現される。
【００１３】
データベース３２は不具合事例に対応する複数のレコードで構成されており、各レコードは、ショベルの動作状態を表す動作状態データ、及びメンテナンス作業の内容を表すメンテナンス作業データを含む。データベース３２の詳細な構成については、後に図２Ａ及び図２Ｂを参照して説明する。
【００１４】
受信装置３３は、複数のショベル２０から通信回線を通して信号及びデータを受信する。受信された信号及びデータは処理装置３１に転送され、処理される。処理装置３１の処理結果が、出力装置３４に出力される。
【００１５】
出力装置３４は、例えば表示装置、送信機等を含む。表示装置は、処理装置３１の処理結果を表示する。送信機は、処理装置３１の処理結果を、他の機器に送信する。
【００１６】
携帯端末４０で支援される対象となるショベル２０が、処理装置２１、入出力装置２２、センサ２３、及び通信装置２４を含む。センサ２３は、ショベルの動作状態を表す種々の動作状態データを検知する。さらに、センサ２３は、ショベル２０の外部環境に依存する外部環境データを検知する。外部環境データには、外気温、気圧等が含まれる。通信装置２４は、通信回線を通して、携帯端末４０と信号及びデータの送受信を行う。
【００１７】
入出力装置２２を通して、操縦者またはショベル２０の管理者が、処理装置２１に指令を与える。入出力装置２２には、スイッチ、タッチパッド、液晶ディスプレイ、タッチパネル等が用いられる。処理装置２１は、センサ２３による検知結果、入出力装置２２から入力された指令、通信装置２４を通して受信された信号及びデータの処理を行う。処理装置２１の処理結果は、入出力装置２２に出力されるか、または通信装置２４を通して携帯端末４０に送信される。
【００１８】
図１では、携帯端末４０がショベル支援装置として動作する例を示したが、図１に示した携帯端末４０の機能の一部を、管理センタに設置されるサーバで実現してもよい。例えば、携帯端末４０のデータベース３２を、管理センタに設置されるサーバで実現し、データベース３２以外の機能を携帯端末で実現してもよい。また、ショベル支援装置を、携帯端末４０に代えて、ショベル２０に搭載された装置で実現してもよいし、図１に示した携帯端末４０の機能の一部を、ショベル２０に搭載された装置で実現し、他の機能を管理センタのサーバで実現してもよい。
【００１９】
その他に、携帯端末４０と管理センタとの両方にデータベース３２の機能を持たせることも可能である。この場合には、両者のデータベースの内容を定期的に同期させることが好ましい。いずれの構成においても、携帯端末４０の処理装置３１は、データベース３２にアクセス可能である。
【００２０】
図２Ａに、データベース３２のレコードのフィールド構造を示す。１つのレコードが、１つの不具合事例に対応する。各レコードは、基本データ、不具合内容、動作状態データ、及びメンテナンス作業データをそれぞれ格納する複数のフィールドで構成される。基本データフィールドには、不具合発生日時情報及び不具合が発生したショベルの機種情報が格納される。不具合内容フィールドには、ギア破損、ポンプ破損、油漏れ、燃料消費率の悪化、振動の増大等の不具合内容が格納される。
【００２１】
動作状態データフィールドは、さらにショベルの動作状態を表す複数のデータを格納する複数のサブフィールドに区分される。例えば、動作状態データのサブフィールドには、エンジン回転数平均値、エンジン回転数標準偏差、エンジントルク平均値、エンジントルク標準偏差、作動油温度、リリーフ弁圧力、振動情報等が格納される。メンテナンス作業データフィールドは、さらに、メンテナンス作業に要した時間情報、メンテナンス作業において交換した部品情報及びその個数、メンテナンス作業に要した費用情報が格納される複数のサブフィールドに区分される。
【００２２】
図２Ｂに、データベース３２の他のレコードのフィールド構造を示す。図２Ｂでは、不具合内容及び機種が同一の複数の不具合事例によって、１つのレコードが構成される。各レコードは、ショベルの機種、不具合内容、件数、動作状態データ、及びメンテナンス作業データを格納するフィールドを含む。件数フィールドには、当該レコードに対応する不具合事例の件数が格納される。動作状態データのサブフィールドには、当該レコードに含まれる複数の不具合事例の平均値が設定される。メンテナンス作業データの作業時間情報及び費用情報のサブフィールドには、それぞれ当該レコードに含まれる複数の不具合事例の作業時間の最大値と平均値、及び費用の最大値と平均値が格納される。交換部品のサブフィールドには、当該レコードに含まれる複数の不具合事例のメンテナンス作業で用いられた全ての交換部品情報、及び交換された部品の個数の最大値と平均値が格納される。
【００２３】
図３に、評価対象のショベル２０と携帯端末４０との間の信号送受信シーケンス、及び携帯端末４０の処理フローを示す。
【００２４】
評価対象のショベル２０から携帯端末４０に、定期的に動作状態データが送信される。携帯端末４０は、ステップＳ１において、評価対象のショベル２０から受信した直近の動作状態データと、データベース３２の各レコードの動作状態データとの類似度を算出する。類似度算出の対象となる複数のレコードとして、図２Ａに示した個々の不具合事例で構成されたレコードを用いてもよいし、図２Ｂに示した不具合内容が同一の複数の不具合事例を１つにまとめたレコードを用いてもよい。類似度の算出方法の一例については、後に図４を参照して説明する。
【００２５】
ステップＳ２において、相対的に類似度の高い複数のレコードを抽出する。ステップＳ３において、抽出された類似度の高いレコードの内容を、類似度の高い順に並び替えて、出力装置３４に出力する。出力内容の一例については、後に図５Ａ及び図５Ｂを参照して説明する。
【００２６】
次に、図４を参照して、ステップＳ１（図３）での類似度の算出方法の一例について説明する。
【００２７】
図４は、動作状態データを構成する複数の変数を要素とするベクトル空間を示す。データベース３２の１つのレコードが、１本のベクトルに対応する。各ベクトルは、正常動作時に取得された複数の動作状態データを表すベクトルの各要素の平均値が１、標準偏差が１になるように正規化される。このため、正常動作時に取得された動作状態データに対応するベクトルの終点は、原点Ｏの近傍に集まる。何らかの不具合が発生しているときに取得された動作状態データに対応するベクトルは、正常動作時に取得された動作状態データに対応するベクトルよりも相対的に長くなる。
【００２８】
図４では、エンジン回転数平均値、エンジン回転数標準偏差、及び作動油温度の３つの要素からなる３次元のベクトル空間が示されているが、実際には、動作状態データを構成するサブフィールドの個数に相当する次元のベクトル空間が定義される。
【００２９】
データベース３２の１つのレコードが、ベクトル空間内の１つのベクトルで表される。図４では、不具合内容が不具合Ａ、不具合Ｂ、不具合Ｃ、不具合Ｄである３つのレコードに対応する３本のベクトルが示されている。例えば、不具合Ａを示すベクトルの方向と不具合Ｄを示すベクトルの方向とはほぼ同一であり、不具合Ａを示すベクトルが不具合Ｄを示すベクトルよりも長い。この２つの事例から、不具合Ａは既に故障に至っていると推察される。また、不具合Ｄは不具合Ａよりも軽度であり、軽度の不具合Ｄを放置すると、重度の不具合Ａに至る危険性が高いことが推察される。このため、不具合Ｄの段階でプリメンテナンス（予防保全）を行うことが望ましい。評価対象のショベル２０から取得された動作状態データも、ベクトル空間内の１本のベクトルとして表される。
【００３０】
評価対象のショベル２０に対応するベクトルと、複数のレコードの各々に対応するベクトルとのなす角度をθで表す。評価対象のショベル２０の動作状態データと、各レコードの動作状態データとの類似度Ｄｓは、角度θの余弦（ｃｏｓθ）で定義される。角度θの余弦を算出することにより、類似度Ｄｓが求まる。なお、評価対象のショベル２０の不具合の程度Ｄａを、ベクトルの長さＬで定義することができる。
【００３１】
図５Ａ及び図５Ｂに、ステップＳ３（図３）で出力される画像の一例を示す。類似度は、図２Ｂに示したデータベース３２を用いて算出されている。図５Ａに示すように、類似度の高い順に並べ変えられて、不具合の程度、類似度、リンクボタン、不具合内容、件数、及びデータベース３２のメンテナンス作業データのサブフィールドの内容が表示される。不具合の程度は、数値で表してもよいし、不具合のレベルで表してもよい。不具合の程度をレベルで表示する場合には、例えば、明らかな不具合が発生している状態をレベルＨ、要注意であることを示すレベルＬ、正常であることを示すレベルＮの３つのレベルに分類してもよい。メンテナンス作業データのサブフィールドには、作業時間情報、費用情報、交換部品情報が含まれる。
【００３２】
図５Ａに示された不具合の程度の大きさから、評価対象のショベル２０に不具合が発生しているか否かを判定することができる。不具合が発生している場合には、類似度の大きさから、どの不具合が発生している可能性が高いか、またはショベルの使用をこのまま継続した場合に、どのような重度の不具合に至る可能性が高いかを認識することができる。さらに、メンテナンスを行う場合には、メンテナンス作業時間、メンテナンス費用、交換部品についての情報を得ることができる。交換部品サブフィールドには、各事例の交換部品情報、及び交換個数が含まれる。
【００３３】
図５Ｂに、図５Ａの各レコードのリンクボタンをクリックまたはタップしたときに表示される画像を示す。レコードのリンクボタンがクリックされると、当該レコードに含まれる不具合事例ごとに、リンクボタン、基本データ、不具合内容、動作状態データ、及びメンテナンス作業データが表示される。表示された内容から、評価対象のショベル２０の動作状態データに最も類似する不具合事例を見つけだすことができる。
【００３４】
図６Ａに、図５Ｂの各レコードのリンクボタンをクリックまたはタップにより選択したときに表示される画像の一例を示す。クリックしたレコードに対応する不具合事例のより詳細な情報が表示される。表示される情報には、不具合発生時のショベルの位置情報、アワーメータ、不具合部位、不具合状況、作業分類、メンテナンス作業の内容、現象（不具合時）、メンテナンス作業に要した作業時間、メンテナンスを担当した担当店の名称、担当者、メンテナンス作業に要した諸経費、使用部品等が含まれる。作業分類の欄には、例えば「プリメンテナンス」、「不具合復旧」、「不具合調査」、「定期点検」等が表示される。諸経費の欄には、運送費、作業費用等の項目ごとに費用が表示される。使用部品の欄には、使用した部品名と、その部品の価格が表示される。この詳細な情報は、メンテナンス作業を行う際に活用することができる。
【００３５】
図５Ｂに表示された内容から、評価対象のショベル２０の動作状態データに類似する複数の不具合事例の情報を比較したい場合がある。この場合には、図５Ｂの２つのレコードのリンクボタンを選択することができる。
【００３６】
図６Ｂに、図５Ｂの２つのレコードのリンクボタンを選択したときに表示される画像の一例を示す。図６Ｂに示した例では、不具合の事例００００１−０００１と事例００００１−０００２の２つが選択された例が示されている。例えば、一方の事例は、「エンジン回転数が落ちやすい」という不具合状況であり、他方の事例は、「操作するとエンジンストール発生」という不具合状況である。
【００３７】
エンジン回転数が落ちやすいという事例では、作業分類の欄の内容からプリメンテナンスが行われたことがわかる。操作するとエンジンストールが発生するという事例では、作業分類の欄の内容から不具合復旧作業が行われたことがわかる。作業内容の欄から、プリメンテナンスでは、燃料フィルタ交換及びエンジンオイル交換が行われたことが分かる。不具合復旧作業では、燃料フィルタ交換、エンジンオイル交換、及びサプライポンプ交換が行われたことが分かる。さらに、不具合復旧作業の作業時間は、プリメンテナンス作業の作業時間より長く、不具合復旧作業に要する費用は、プリメンテナンスに要する費用より高額であることがわかる。
【００３８】
評価対象のショベル２０に、エンジン回転数が落ちやすいという不具合が発生している場合、ショベルの管理者は、このまま稼働を継続すると、エンジンストールが発生するという重度の不具合に至る危険性が高いことを認識することができる。２つの事例の作業時間及び費用の比較結果は、現時点でプリメンテナンスを行うべきか否かを判断するための重要な情報として利用することができる。
【００３９】
また、ショベル２０の稼働計画を立案する管理者は、図５Ａに示した不具合の程度を、プリメンテナンスを行うべきか否かの判断材料として用いることができる。プリメンテナンス作業を行う場合には、類似度の高いレコードの作業時間情報を参考にして、ショベル２０の適切な稼働計画を立案することができる。
【００４０】
プリメンテナンス作業を行うサービス員は、図５Ａに示した交換部品に関する情報に基づいて、プリメンテナンス作業に必要となると推定される交換部品を予め準備しておくことができる。これにより、作業現場に出向く回数を減らすことができる。
【００４１】
上記実施例では、動作状況データの各変数を要素とする多次元ベクトルの方向に基づいて類似度を算出したが、その他の多変量解析手法を用いて類似度を算出することも可能である。例えば、ベイズ推定による多変量解析手法を用いることが可能である。また、評価対象のショベル２０から取得された動作状態データと、データベース３２の複数のレコードの動作状態データとの比較結果に基づいて、将来的に発生する可能性の高いと推察される重度の不具合に対応する少なくとも１つのレコードを抽出する際に、必ずしも「類似度」という評価尺度を用いる必要はない。種々の解析手法を用いて、少なくとも１つのレコードを抽出することが可能である。
【００４２】
次に、図７及び図８を参照して、他の実施例によるショベル支援装置について説明する。以下、図１〜図６Ａ、図６Ｂに示した実施例との相違点について説明し、共通の構成については説明を省略する。
【００４３】
図７に、本実施例による管理装置５０のブロック図、評価対象のショベル２０、及びショベル支援装置として動作する携帯端末４０を示す。本実施例では、図３に示したステップＳ１及びＳ２の処理が、管理センタに配置された管理装置（サーバ）５０で実行される。管理装置５０は、評価対象のショベル２０のみならず、携帯端末４０ともデータ通信を行う。携帯端末４０は、表示画面４１を含む。表示画面４１には、例えばタッチパネルが用いられており、表示画面４１が入力装置を兼ねる。管理装置５０の処理装置３１の処理結果が、出力装置３４の送信機を介して、携帯端末４０に送信される。携帯端末４０は、管理装置５０から受信したデータを、画像として表示画面４１に表示する。
【００４４】
図８に、評価対象のショベル２０、管理装置５０、及び携帯端末４０の間の信号送受信シーケンス、及び処理フローを示す。ショベル２０は、動作状態データに基づいて故障の予兆を検知する機能を有する。故障の予兆の検知には、ニューラルネットワークモデル、クラスタ解析、マハラノビスタグチ法等を用いることが可能である。
【００４５】
ショベル２０は、故障の予兆を検知すると、管理装置５０に故障の予兆出現信号を送信することにより、故障の予兆の出現を通知するとともに、故障の予兆の出現時の動作状態データを送信する。管理装置５０は、ステップＳ１及びＳ２を実行することにより、類似度の高いレコードを抽出する。ステップＳ１及びＳ２の処理は、図３に示したステップＳ１及びＳ２の処理と同一である。
【００４６】
管理装置５０は、抽出された類似度の高いレコードの内容を携帯端末４０に送信する。携帯端末４０は、ステップＳＡ１において、類似度の高いレコードのメンテナンス作業データを、表示画面４１（図７）に表示する。表示画面４１に表示される内容は、図５Ａ、図５Ｂ、図６Ａ、及び図６Ｂに示した内容と同一である。サービス員は、携帯端末４０に表示された内容を確認して、プリメンテナンス作業を実施する。
【００４７】
サービス員がショベル２０のプリメンテナンス作業を実施した後、ステップＳＡ２において、携帯端末４０に、図６Ａ及び図６Ｂに表示されている情報等を入力する。
【００４８】
携帯端末４０は、入力されたプリメンテナンス作業に関する情報を管理装置５０に送信する。ステップＳ４において、管理装置５０は、受信したプリメンテナンス作業に関する情報に基づいて、図２Ａに示した構造のデータベース３２に、新たに不具合事例（故障の予兆の事例）のレコードを追加する。さらに、図２Ｂに示した構造のデータベース３２の対応するレコードの件数に１を加えるとともに、作業状態データ及びメンテナンス作業データの各サブフィールドの値を再計算して、更新する。
【００４９】
図７及び図８に示した実施例では、サービス員が、携帯端末４０を見て、ショベル２０に故障の予兆が出現したことを知ることができる。さらに、プリメンテナンス作業に必要と推定される交換部品、及びその個数に関する情報を得ることができる。サービス員は、必要と推定される交換部品を持って、プリメンテナンス作業の現場に出向くことができる。これにより、交換部品の準備不足等によるプリメンテナンス作業の遅延を抑制することができる。
【００５０】
図７及び図８では、管理装置５０と携帯端末４０とで、プリメンテナンス作業の支援及びデータベース３２の更新を行う例について示した。その他の構成として、管理装置５０の機能と、携帯端末４０の機能とを、１つの携帯端末で実現することも可能である。この場合には、図７に示した管理装置５０と携帯端末４０とを含めてショベル支援装置ということができる。
【００５１】
次に、図９を参照して、さらに他の実施例によるショベル支援装置について説明する。以下、図１〜図６Ａ、図６Ｂに示した実施例との相違点について説明し、共通の構成については説明を省略する。
【００５２】
図９に、評価対象のショベル２０と管理装置５０との間の信号送受信シーケンス、及び処理フローを示す。ステップＳＢ１において、評価対象のショベル２０の入出力装置２２（図１）を通して、プリメンテナンス見積り依頼が行われる。ショベル２０のユーザ、例えば、作業現場の管理者が、入出力装置２２を操作することにより、プリメンテナンスの見積り依頼を行う。
【００５３】
プリメンテナンスの見積り依頼の操作が行われると、ショベル２０は管理装置５０に見積り依頼信号を送信するとともに、直近の動作状態データを送信する。管理装置５０は、受信した動作状態データに基づいて、ステップＳ１及びＳ２を実行することにより、相対的に類似度の高いレコードを抽出する。ステップＳ１及びＳ２の処理は、図３に示したステップＳ１及びＳ２の処理と同一である。
【００５４】
管理装置５０は、類似度の高いレコードの内容を評価対象のショベル２０に送信する。ショベル２０は、ステップＳＢ２において、類似度の高いレコードのメンテナンス作業データ等を入出力装置２２に表示する。表示内容は、図５Ａ、図５Ｂ、図６Ａ、及び図６Ｂに示したものと同一である。ユーザは、ショベル２０の入出力装置２２に表示された内容を、プリメンテナンス作業を行うか否かの判材料として利用することができる。
【００５５】
例えば、入出力装置２２に表示された不具合の程度に基づいて、プリメンテナンス作業を行う必要があるか否かを判断することができる。さらに、入出力装置２２に表示された作業時間情報に基づき、プリメンテナンス作業を行うことによってショベル２０が使用できなくなる時間を予測することができる。本実施例においては、図７及び図８に示した携帯端末４０の機能の一部（ステップＳＡ１）が、評価対象のショベル２０で実現される。この場合には、ショベル支援装置がショベル２０に搭載されているということができる。
【００５６】
次に、図１０を参照して、さらに他の実施例によるショベル支援装置について説明する。以下、図７〜図８に示した実施例との相違点について説明し、共通の構成については説明を省略する。
【００５７】
ステップＳＡ３において、携帯端末４０に、プリメンテナンスの見積り依頼コマンドが入力される。携帯端末４０は、プリメンテナンスの見積り依頼コマンドが入力されると、管理装置５０に、ショベル２０を特定して見積り依頼信号を送信する。一例として、管理装置５０には、管理センタに配置されたサーバが用いられる。
【００５８】
見積り対象のショベル２０の直近の動作状態データがデータベース３２に保存されていない場合、管理装置５０は、動作状態データの送信依頼信号を、見積り対象のショベル２０に送信する。動作状態データ送信依頼信号を受信したショベル２０は、直近の動作状態データを管理装置５０に送信する。見積り対象のショベル２０の直近の動作状態データがデータベース３２に保存されている場合には、動作状態データの送信依頼信号を送信する必要は無い。
【００５９】
管理装置５０は、見積り対象のショベル２０の直近の動作状態データに基づいて、ステップＳ１及びＳ２を実行することにより、相対的に類似度の高いレコードを抽出する。ステップＳ１及びＳ２の処理は、図３に示したステップＳ１及びＳ２の処理と同一である。抽出された類似度の高いレコードの内容が、携帯端末４０に送信される。
【００６０】
携帯端末４０は、ステップＳＡ１において、類似度の高いレコードのメンテナンス作業データを、表示画面４１（図７）に表示する。ステップＳＡ１の処理は、図８に示したステップＳＡ１の処理と同一である。
【００６１】
販売代理店のサービス員は、携帯端末４０に表示されたメンテナンス作業データに基づいて、ショベル２０の所有者であるユーザにプリメンテナンス作業の必要性や、プリメンテナンス作業の費用見積り結果を提示することができる。ユーザは、サービス員から提示された情報を参考にして、プリメンテナンス作業を行うか否かを判断することができる。
【００６２】
図１０に示した実施例によるショベル支援装置として動作するに携帯端末４０と、管理装置５０との機能を、１台の携帯端末で実現してもよい。
【００６３】
次に、図１１及び図１２を参照して、さらに他の実施例によるショベル支援装置について説明する。以下、図１〜図６Ａ、図６Ｂに示した実施例との相違点について説明し、共通の構成については説明を省略する。
【００６４】
図１１に、評価対象のショベル２０と、ショベル支援装置として動作する携帯端末４０との間の信号送受信シーケンス、及び携帯端末４０の処理フローを示す。本実施例においては、評価対象のショベル２０から携帯端末４０に、動作状態データに加えて、外部環境データが送信される。外部環境データには、ショベル２０の作業現場の環境を表すデータ、例えば外気温、気圧等のデータが含まれる。
【００６５】
図１２に、データベース３２の構造を示す。不具合事例に対応する各レコードが、外部環境データを含む。複数のレコードは、外部環境データに基づいてクラスタ分析が行われることにより、複数のクラスタのいずれかに分類されている。クラスタ分析には、周知の手法を適用することができる。クラスタに分類した後、図２Ｂの例と同様に、クラスタごとに同一の不具合内容のレコードをまとめて、１つのレコードとしてもよい。
【００６６】
図１１のステップＳ５において、評価対象のショベル２０の外部環境データと類似する外部環境データを持つクラスタを決定する。ステップＳ６において、評価対象のショベル２０の動作状態データと、データベース３２の類似するクラスタ内の各レコードの動作状態データとの類似度を算出する。その後、携帯端末４０は、ステップＳ２及びＳ３を実行することにより、相対的に類似度の高い少なくとも１つのレコードの内容を出力する。ステップＳ２及びＳ３の処理は、図２に示したステップＳ２及びＳ３の処理と同一である。
【００６７】
図１１及び図１２に示した実施例においては、評価対象のショベル２０の外部環境と類似するクラスタに属するレコードとのみ、動作状態データの類似度が算出される。このため、全てのレコードを類似度算出の対象とする場合に比べて、類似度を算出するための演算量が少なくなる。さらに、評価対象のショベル２０の外部環境と類似する環境下で稼働しているショベルの不具合事例の中から、類似する不具合事例が抽出される。このため、プリメンテナンスに関する適切な情報を得ることができる。
【００６８】
本実施例においては、ショベル支援装置の機能を携帯端末４０で実現した。その他の構成として、ショベル支援装置の機能を、管理センタに設置されるサーバで実現してもよい。または、ステップＳ５、Ｓ６、Ｓ２を管理センタに設置されるサーバで実現し、ステップＳ３を、ショベル支援装置として動作する携帯端末で実現してもよい。
【００６９】
以上実施例に沿って本発明を説明したが、本発明はこれらに制限されるものではない。例えば、種々の変更、改良、組み合わせ等が可能なことは当業者に自明であろう。
【符号の説明】
【００７０】
２０  ショベル
２１  処理装置
２２  入出力装置
２３  センサ
２４  通信装置
３０  ショベル支援装置
３１  処理装置
３２  データベース
３３  受信装置
３４  出力装置
４０  携帯端末
４１  表示画面
５０  管理装置
【図１】
2016190434.tif 000003
【図２】
2016190434.tif 000004
【図３】
2016190434.tif 000005
【図４】
2016190434.tif 000006
【図５】
2016190434.tif 000007
【図６Ａ】
2016190434.tif 000008
【図６Ｂ】
2016190434.tif 000009
【図７】
2016190434.tif 000010
【図８】
2016190434.tif 000011
【図９】
2016190434.tif 000012
【図１０】
2016190434.tif 000013
【図１１】
2016190434.tif 000014
【図１２】
2016190434.tif 000015
【国際調査報告】
2016190434.tif 000016
2016190434.tif 000017
2016190434.tif 000018
2016190434.tif 000019