特許 7532796 保全管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-05

(45)【発行日】2024-08-14

(54)【発明の名称】保全管理システム

(51)【国際特許分類】

   G05B 19/418 20060101AFI20240806BHJP

【ＦＩ】

G05B19/418 Z

【請求項の数】 10

(21)【出願番号】P 2020021658

(22)【出願日】2020-02-12

(65)【公開番号】P2021128433

(43)【公開日】2021-09-02

【審査請求日】2022-12-07

(73)【特許権者】

【識別番号】000002945

【氏名又は名称】オムロン株式会社

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】▲高▼原 昌利

【審査官】齋藤 健児

(56)【参考文献】

【文献】特開２０１７－１２０５３２（ＪＰ，Ａ）

【文献】特開２０２０－０１３４６４（ＪＰ，Ａ）

【文献】特開２０１９－１２１０５２（ＪＰ，Ａ）

【文献】特開２００９－２５１８２２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０５Ｂ １９／４１８

(57)【特許請求の範囲】

【請求項1】

複数のデバイスが接続された製造システムの保全状態を管理する保全管理システムであって、
前記複数のデバイスの各々の保全状態の管理に必要なパラメータの値を、所定のタイミングで収集するパラメータ収集部と、
前記パラメータ収集部で収集した前記パラメータの値を前記複数のデバイスの各々で記憶する記憶部と、
前記記憶部に記憶した前記パラメータの値から、前記複数のデバイスの各々の保全状態の管理に必要な将来のパラメータの値を前記複数のデバイスの各々で予測するパラメータ予測部と、
前記パラメータ予測部で予測した前記将来のパラメータの値に基づいて、所定期間経過した時点の前記複数のデバイスの各々の保全状態の区分を判断する判断部と、
前記判断部で判断された前記所定期間経過した時点の前記複数のデバイスの各々の保全状態の区分を、前記複数のデバイスの接続関係が識別可能な表示態様で、画面に表示する表示部とを備える、保全管理システム。

【請求項2】

前記判断部は、前記所定期間経過した時点の前記将来のパラメータの値が所定の閾値を超えているか否かに基づいて、前記複数のデバイスの各々の保全状態の区分を判断する、請求項１に記載の保全管理システム。

【請求項3】

前記パラメータ収集部が収集する前記パラメータは、前記複数のデバイスの各々の稼働時間である、請求項１または請求項２に記載の保全管理システム。

【請求項4】

前記複数のデバイスの各々は、センサを含み、
前記パラメータ収集部が収集する前記パラメータは、前記センサが取得する信号の強度である、請求項１～請求項３のいずれか１項に記載の保全管理システム。

【請求項5】

前記パラメータ収集部が収集する前記パラメータは、デバイスの消費電力量である、請求項１～請求項４のいずれか１項に記載の保全管理システム。

【請求項6】

前記表示部は、前記製造システムに含まれる前記複数のデバイスの各々の保全状態の区分を時系列に並べたテーブル形式で表示する、請求項１～請求項５のいずれか１項に記載の保全管理システム。

【請求項7】

前記表示部は、前記製造システムに含まれる前記複数のデバイスのうちの１つのデバイスの保全状態の区分と前記将来のパラメータの値とを時系列に並べたテーブル形式で表示できる、請求項６に記載の保全管理システム。

【請求項8】

前記表示部は、前記製造システムに含まれる前記複数のデバイスの各々をアイコンで表示し、前記複数のデバイスの各々の保全状態の区分を識別可能な表示態様でアイコンに表示し、前記複数のデバイスの各々に対応する前記アイコンを接続させて前記複数のデバイスの接続関係を示すように表示する、請求項１～請求項７のいずれか１項に記載の保全管理システム。

【請求項9】

前記表示部は、前記アイコンに表示させるデバイスの保全状態の区分の所定期間の変更を受け付ける受付手段を表示する、請求項８に記載の保全管理システム。

【請求項10】

前記受付手段は、所定期間単位に移動可能なスライドバーである、請求項９に記載の保全管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

製造システムの保全状態を管理する保全管理システムに関する。

【背景技術】

【0002】

ＦＡ（ファクトリオートメーション）の分野では、ＰＬＣ（プログラマブルロジックコントローラ）などの制御装置を用いて多数のセンサやモーターなどの機器を制御する製造システムが一般的である。

【0003】

近年のＩＣＴ（Information and Communication Technology）の進歩に伴って、制御装置により制御される多くの機器のフィールドレベルのデータを収集したいというニーズが高まっている。

【0004】

このような製造システムの制御装置に関して、特開２０１１－３５６６４号公報（特許文献１）では、制御装置にプロトコル機能を内蔵して、フレーム等の通信データをキャプチャするといったデータの収集ができる製造システムを開示している。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１１－３５６６４号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

上述の特開２０１１－３５６６４号公報に開示されているような製造システムを保全する方法の１つとして、機器が故障する度に機器を交換する事後保全という方法がある。この方法を採用すれば、機器がいつ故障するかは判断できず突然の機器の故障に伴って製造システム全体の稼働を止めてしまう場合があり、生産効率を低下させる可能性があった。そこで、機器が故障する前に事前に交換する予防保全という方法がある。

【0007】

しかし、予防保全を採用した場合、製造システムに接続された多数の機器の状態を定期的かつ個別に確認する作業が必要であり、煩雑であった。また、多数の機器の状態を確認できたとしても、多数の機器に対して適切な交換時期を計画することは容易ではなかった。

【0008】

本開示は係る実情に鑑み考え出されたものであり、その目的は、製造システムに接続された多数の機器の状態を確認し、多数の機器に対して適切な交換時期を計画することが容易な保全管理システムを提供することである。

【課題を解決するための手段】

【0009】

本開示のある局面に従う保全管理システムは、複数のデバイスが接続された製造システムの保全状態を管理する保全管理システムであって、複数のデバイスの各々の保全状態の管理に必要なパラメータの値を、所定のタイミングで収集するパラメータ収集部と、パラメータ収集部で収集したパラメータの値を複数のデバイスの各々で記憶する記憶部とを備える。また、当該保全管理システムは、記憶部に記憶したパラメータの値から、複数のデバイスの各々の保全状態の管理に必要な将来のパラメータの値を複数のデバイスの各々で予測するパラメータ予測部と、パラメータ予測部で予測した将来のパラメータの値に基づいて、所定期間経過した時点の複数のデバイスの各々の保全状態を判断する判断部と、判断部で判断された前記所定期間経過した時点の前記複数のデバイスの各々の保全状態を、画面に表示する表示部とを備える。

【発明の効果】

【0010】

本開示の保全管理システムでは、デバイスの保全状態の管理に必要なパラメータの値を収集し、収集した過去のパラメータの値から将来のパラメータの値を予測し、将来のパラメータの値に基づいて所定期間経過した時点の保全状態を判断し表示することで、製造システムに接続された多数の機器の状態を確認し、製造システム全体の生産性を低下させない各機器の適切な交換時期の計画を容易にすることができる。

【図面の簡単な説明】

【0011】

【図1】本実施の形態に係る保全管理システムの機能的な構成例を示す模式図である。

【図2】本実施の形態に係る保全管理システムが提供するパラメータ収集機能を説明するための模式図である。

【図3】本実施の形態に係る検索装置のハードウェア構成の一例を示すブロック図である。

【図4】光電センサの受光強度を予測するための図である。

【図5】テーブル形式による製造システム全体の保全状態の表示方法を示す図である。

【図6】任意のデバイスに関する詳細情報の表示方法を示す図である。

【図7】製造システム全体の保全状態の表示する処理手順を示す図である。

【図8】アイコンによる製造システム全体の保全状態の表示画面例１を示す図である。

【図9】アイコンによる製造システム全体の保全状態の表示画面例２を示す図である。

【発明を実施するための形態】

【0012】

本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

【0013】

＜適用例＞
まず、本発明が適用される場面の一例について説明する。図１は、本実施の形態に係る保全管理システム１の機能的な構成例を示す模式図である。図１を参照して、保全管理システム１は、少なくとも１つのデバイス３００を含む。「デバイス」は、後述するようなリクエストパケットに対して応答が可能な装置の単位を意味する。典型的には、「デバイス」は、ＩＯユニット、センサユニット、特殊ユニットなどのコントローラに接続され得るユニットを包含するとともに、ＰＬＣ（プログラマブルロジックコントローラ）およびネットワーク通信を中継するカプラユニットなども包含する。ここで、本開示において「各デバイス３００」と表現するときは、保全管理システム１が含む全てのデバイス３００を意味する。一方で、単に「デバイス３００」と表現するときは、単一のデバイス３００を意味する。

【0014】

データベース１０４は、保全管理システム１が含む各デバイス３００の状態の管理に必要なパラメータを記憶するパラメータ履歴１０４４と、各デバイス３００の状態の管理に必要なパラメータを参照するためのインデックス１０４３とを保持する。

【0015】

パラメータ収集部１０６は、任意のデバイス３００から任意のデータを収集するにあたって、予め収集された索引情報（以下、「インデックス」とも称す。）を参照する。パラメータ収集部１０６は、インデックスを自動的に更新することもできる。

【0016】

パラメータ収集部１０６は、所定のタイミングでリクエストパケット４００を生成し、各デバイス３００へ送信する。各デバイス３００は、リクエストパケット４００に応じて、レスポンスパケット４５０をパラメータ収集部１０６へ送信する。

【0017】

レスポンスパケット４５０は、送信元のデバイス３００の状態を示すパラメータの値を含む。パラメータ収集部１０６は、各デバイス３００からパラメータの値を受信することで、パラメータを収集し、パラメータ履歴１０４４へ書き込む。

【0018】

パラメータ履歴１０４４は、各デバイス３００の識別情報と、パラメータの値と、パラメータの値を取得した時間とを保持する。パラメータ履歴１０４４は、その他の情報を記憶してもよく、たとえば、前回交換をした日時等を記憶してもよい。また、パラメータ履歴１０４４は、各デバイス３００の過去の稼働時間の実測値を保持してもよい。保全管理システム１は、過去の最大稼働時間、過去の最小稼働時間に基づいて後述で説明する保全状態を判断するための閾値を定めてもよい。

【0019】

本実施の形態に係る保全管理システム１によれば、保全管理システム１内のパラメータの変化に応じて更新されるインデックス１０４３を参照することにより、保全管理システム１内の任意のデバイス３００の任意の情報を効率的に収集できる。

【0020】

データベース１０４は、パラメータ収集部１０６より収集された状態データを蓄積して保持する。すなわち、パラメータ収集部１０６がデータを収集する回数に伴ってデータベース１０４が保持する状態データのデータ使用容量は増加していく。

【0021】

パラメータ予測部１０７は、データベース１０４が保持する過去のパラメータの値を用いて、将来のパラメータの値を予測する。パラメータの種類、予測の手法に関しての詳細については後述で説明するが、たとえばパラメータの種類がデバイス３００の稼働時間である場合、過去の稼働時間履歴を用いて、将来の稼働時間を予測することが考えられる。

【0022】

判断部１０８は、パラメータ予測部１０７が予測するデバイス３００の将来のパラメータの値に基づいて、所定期間経過時の対象のデバイス３００の保全状態を判断する。所定期間とは、ユーザーが設定することが可能である任意の期間である。保全状態とは、デバイス３００の交換時期を示す状態である。

【0023】

本実施の形態においては、保全状態は「正常」「注意」「警告」「危険」に分類される。保全管理システム１では、判断部１０８によって判断される保全状態を用いて対象のデバイス３００が交換時期に達しているか否かを判断する。保全状態の名前、分類の数等は、ユーザーが任意で設定してもよい。たとえば、保全状態は、「正常」「警告」「危険」の３種類に、または「正常」「危険」の２種類に分類されてもよい。さらに保全状態は、「異常レベル１」「異常レベル２」「異常レベル３」「異常レベル４」「異常レベル５」などのように段階的に、複数に分類されてもよい。なお、分類する状態の数に応じて、保全状態を判断するための閾値の数も変更される。

【0024】

本実施の形態においては、「正常」の保全状態（以下、正常状態とする。）は、交換時期にまだ達していないことを示す状態である。すなわち、正常状態であるデバイス３００は、保全のための交換時期に至っておらず、正常な動作が見込まれるデバイスである。「注意」の保全状態（以下、注意状態とする。）は、交換時期が近いことを示す状態である。すなわち、注意状態であるデバイス３００は、保全のための交換時期が近づいており、ユーザーに注意を促す必要があるデバイスである。「警告」の保全状態（以下、警告状態とする。）は、交換時期であることを示す状態である。すなわち、警告状態であるデバイス３００は、保全のための交換時期に至りユーザーに対して警告が必要なデバイスである。「危険」の保全状態（以下、危険状態とする。）は、交換時期を徒過していることを示す状態である。すなわち、危険状態であるデバイス３００は、保全のための交換時期を徒過しておりユーザーに対して保全上危険なデバイスである。

【0025】

表示部１６２は、所定期間経過時の判断部１０８が判断した任意のデバイス３００の保全状態をユーザーに対して表示する。表示方法に関しての詳細は後述で説明するが、たとえば、テーブル形式で表示することが考えられる。

【0026】

＜概要＞
まず、本実施の形態に係る保全管理システム１が提供するパラメータ収集機能について説明する。図２は、本実施の形態に係る保全管理システム１が提供するパラメータ収集機能を説明するための模式図である。図２を参照して、保全管理システム１は、検索装置１００と、検索装置１００により検索可能な検索対象２とを含む。

【0027】

検索対象２は、典型的には、制御対象を制御する制御装置の典型例であるＰＬＣ２００（プログラマブルロジックコントローラ）と、ＰＬＣ２００に接続される１または複数のデバイス３００とを含む。デバイス３００は、ＰＬＣ２００の管理によって動作する装置を意味し、典型的には、制御対象との間で信号をやり取りする装置である。デバイス３００の一例としては、制御対象から入力信号を取得し、あるいは、制御対象へ出力信号を出力するＩＯユニット、モーターなどを制御するドライバ、ロボットなどを制御するロボットコントローラ、などを含む。制御対象には、ワークを測定するセンサなどが含まれる。

【0028】

ＰＬＣ２００自体も「デバイス」の概念に含まれ得る。また、「デバイス」の概念には、ＰＬＣ２００を細分化したユニットも含まれる。ＰＬＣ２００を構成するＣＰＵユニット、電源ユニット、ＩＯユニットなどは各々取り外し交換が可能であるため、単体のデバイスとして扱う。パラメータ収集部１０６は、ＰＬＣ２００が備えるこれらのユニットの稼働時間等の情報を各々収集できる。

【0029】

各デバイス３００は、データを一時的に保持する作業領域３０２と、各デバイス３００の各種設定を規定するプロファイル３０４と、接続されているセンサなどから取得したデータを格納し、および／または、各デバイス３００において生成されるデータを格納するデータソース３０６とを含む。

【0030】

検索装置１００のパラメータ収集部１０６は、検索対象２のネットワーク内を巡回して各デバイス３００のパラメータの値を、所定のタイミングで自動的に収集する。所定のタイミングとは、典型的には、１日のうちの任意の時間であり、定期的であることが望ましい。

【0031】

たとえば、パラメータ収集部１０６は、正午のタイミングで、毎日、各デバイス３００のパラメータの値を収集する。もちろん、パラメータ収集部１０６は、ユーザーが設定した任意の条件または外部からのデータ検索要求をトリガとして、パラメータの値を収集してもよい。たとえば、パラメータ収集部１０６は、保全管理システム１がいずれかの機器のエラーを検知したことをトリガとして、パラメータの値を収集する。または、パラメータ収集部１０６は、検索装置１００が各デバイス３００の電源投入を検知した場合に、パラメータの値を収集してもよい。

【0032】

パラメータ収集部１０６は、インデックス１０４３とパラメータの値とを各デバイス３００から収集する度にデータベース１０４に蓄積する。パラメータ収集部１０６は、構成情報１０４１、および、デバイスプロファイル１０４２について更新することができてもよい。

【0033】

検索装置１００は、主たる機能構成として、インターフェイス１０２と、データベース１０４と、通信処理部１１０と、制御部１５２と、入力部１６０と、表示部１６２とを含む。制御部１５２は、パラメータ収集部１０６と、パラメータ予測部１０７と、判断部１０８とを含む。

【0034】

インターフェイス１０２は、他の端末との間でデータをやり取りする。パラメータ収集部１０６は、インターフェイス１０２を介して、他の端末からデータ検索要求を受信したことをトリガとして、パラメータの値を収集してもよい。

【0035】

具体的には、インターフェイス１０２は、他の端末からデータ検索要求を受信すると、受信したデータ検索要求をパラメータ収集部１０６へ出力する。インターフェイス１０２は、パラメータ収集部１０６からデータを受信し、検索結果として他の端末へ送信することができる。

【0036】

パラメータ収集部１０６は、定期的に必要なリクエストパケットを生成する。生成されたリクエストパケットは、通信処理部１１０から検索対象２のネットワークへ送信される。パラメータ収集部１０６は、リクエストパケットに応答して返されるレスポンスパケットを通信処理部１１０から受信すると、レスポンスパケットに含まれるデータをデータベース１０４へ出力する。

【0037】

通信処理部１１０は、検索対象２のネットワークおよび該ネットワークに含まれる各デバイス３００との間でデータをやり取りする。図２の構成例においては、通信処理部１１０は、検索対象２のネットワークを統括するＰＬＣ２００を介して、任意のデバイスとの間でデータ（パケット）をやり取りする。

【0038】

データベース１０４は、パラメータの値と、デバイス３００からデータを収集するためのパケットなどを生成するために必要な情報を格納している。より具体的には、データベース１０４は、構成情報１０４１と、デバイスプロファイル１０４２と、インデックス１０４３と、パラメータ履歴１０４４を含む。構成情報１０４１は、検索対象２に含まれる各デバイス３００の接続関係を示す情報を含む。デバイスプロファイル１０４２は、検索対象２に含まれる各デバイス３００の特性を示す情報を含む。インデックス１０４３は、検索を効率化するために用いられる情報であり、検索対象２に含まれる各デバイス３００のパラメータの値を含む。パラメータ履歴１０４４は、各デバイス３００のパラメータの値と、該パラメータの値を収集した時間を含む。

【0039】

＜検索装置１００のハードウェア構成例＞
次に、本実施の形態に係る保全管理システム１を構成する検索装置１００のハードウェア構成例について説明する。

【0040】

検索装置１００は、検索対象２に含まれるＰＬＣ２００またはネットワークに接続される独立した装置として構成してもよいし、ＰＬＣ２００の一部として（すなわち、ＰＬＣ２００と一体化して）構成してもよい。

【0041】

検索装置１００を独立した装置として構成する場合には、ＰＬＣ２００と同様のハードウェア構成を採用してもよいし、汎用的なコンピュータを採用してもよい。汎用的なコンピュータを採用する場合には、コンピュータのプロセッサが検索プログラムを実行することで実現される。

【0042】

図３は、本実施の形態に係る検索装置１００のハードウェア構成の一例を示すブロック図である。図３を参照して、検索装置１００は、制御部１５２と、メインメモリ１５４と、ストレージ１５６と、上位ネットワークコントローラ１５８と、入力部１６０と、表示部１６２と、下位ネットワークコントローラ１６４と、メモリカードインターフェイス１６６とを含む。これらのコンポーネントは、バス１７０を介して接続されている。

【0043】

制御部１５２は、後述するような各種処理を実行する演算処理部に相当し、ＣＰＵやＧＰＵなどで構成される。具体的には、制御部１５２は、ストレージ１５６に格納されたプログラムを読出して、メインメモリ１５４に展開して実行することで、各種処理を実行する。

【0044】

メインメモリ１５４は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置などで構成される。ストレージ１５６は、たとえば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などの不揮発性記憶装置などで構成される。ストレージ１５６には、本実施の形態に係るパラメータ収集処理を実現するための検索プログラム１５６０と、ＯＳ（Operating System）などを含むシステムプログラム１５６４とが格納される。ストレージ１５６には、データベース１０４が格納される。

【0045】

入力部１６０は、タッチパネル、マウス、キーボードなどで構成され、ユーザー操作を受け付ける。表示部１６２は、液晶ディスプレイなどで構成され、制御部１５２による処理結果に応じた画像などを表示する。入力部１６０および表示部１６２が一体化して構成されてもよい。

【0046】

上位ネットワークコントローラ１５８は、ネットワーク接続された任意の情報処理装置からのデータ検索要求などを受付ける。上位ネットワークコントローラ１５８は、図２のインターフェイス１０２として機能する。下位ネットワークコントローラ１６４は、検索対象２に含まれるＰＬＣ２００などとの間でデータをやり取りする。

【0047】

メモリカードインターフェイス１６６は、着脱可能な記憶媒体の一例であるメモリカード１６８を受け付ける。メモリカードインターフェイス１６６は、メモリカード１６８に対してデータを書込み、メモリカード１６８から各種データを読出すことが可能になっている。メモリカードインターフェイス１６６を介して、検索装置１００は、検索プログラム１５６０および自動更新プログラム１５６２をインストールできるように構成されてもよい。

【0048】

図３には、制御部１５２が検索プログラム１５６０を実行することで必要な機能が提供される構成例を示したが、これらの提供される機能の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣ（Application Specific Integrated Circuit）またはＦＰＧＡ（Field-Programmable Gate Array）など）を用いて実装してもよい。

【0049】

図３では、各機能を備える検索装置１００を独立した装置として構成する場合の構成例を示したが、データベース１０４と、制御部１５２と、表示部１６２とが別体の装置に設けられていてもよい。たとえば、ＰＬＣ２００がパラメータ収集部１０６として機能する場合、ＰＬＣ２００は、ＰＬＣ２００自身が備える不揮発メモリ等にパラメータの値を記憶させる。製造システムのサポートをする図示しないサポート装置がパラメータ予測部１０７と、判断部１０８として機能し、保全状態を判断する。図示しない表示用端末が表示部１６２として機能し、サポート装置が判断した保全状態を、表示することとしてもよい。このように、検索装置１００が備える各機能は分離して別体の装置の設けられてもよく、様々な組み合わせで分離することが想定される。

【0050】

＜パラメータの種類＞
本実施の形態におけるパラメータとは、保全管理システム１が含む各デバイス３００であるＩＯユニット、センサユニット、特殊ユニットなどのコントローラに接続され得るユニット、ＰＬＣ（プログラマブルロジックコントローラ）およびネットワーク通信を中継するカプラユニットなどの状態の管理に必要なパラメータをいう。

【0051】

本実施の形態の保全管理システム１では、各デバイス３００の稼働時間および各デバイス３００の消費電力量をパラメータとして扱う。保全管理システム１では、長い時間稼働したデバイスは劣化している可能性が高いため、交換対象として判断する。

【0052】

保全管理システム１は、新規導入時に比べて消費電力が多くなったデバイス３００についても交換対象として判断することができる。デバイス３００がモーターなどである場合、経年による変形等の原因により、動作させるための消費電力が高くなる傾向がある。各デバイス３００は、図示しないタイマおよび図示しない消費電力を検知する消費電力センサを備える。消費電力の測定は、電源ケーブルをクランプして電流測定してもよい。

【0053】

保全管理システム１では、デバイス３００が光電センサ等の信号の送受信をするセンサである場合は、受信する信号の強度をパラメータとして扱う。光電センサは、光を投光する投光器と、当該投光を受光する受光器とを含み、投光器と受光器の間をワークがあるか否かを検知することができる。すなわち、投光器が投光しているにもかかわらず受光器が投光を受光できないとき、光電センサは、ワークがあることを検知する。

【0054】

受光器は、汚れの付着や受光素子の不具合などの原因により、投光を信号に変換できる強度を示す受光強度が低下する。受光強度が一定値まで低下すれば、光電センサは検知できなくなり使用することができなくなる。保全管理システム１では、光電センサのみならずその他のセンサの取得する信号の強度をパラメータとして扱ってもよい。

【0055】

各デバイス３００は、各デバイス３００自身の稼働時間、消費電力、取得する信号の強度をデータソース３０６へ記憶させる。また、各デバイス３００は、各デバイス３００自身のパラメータのみならず、各デバイス３００が制御する制御対象のパラメータの値をデータソース３０６へ記憶させる。たとえばデバイス３００がＩＯユニットである場合、ＩＯユニットは、ＩＯユニットに接続されたセンサなどの稼働時間、消費電力についてＩＯユニットが備えるデータソース３０６へ記憶させる。

【0056】

各デバイス３００は、リクエストパケット４００を受信したとき、稼働時間、消費電力および取得する信号の強度の情報を含むレスポンスパケット４５０を検索装置１００へ送信することができる。検索装置１００は、レスポンスパケット４５０に含まれた稼働時間、消費電力の情報、取得する信号の強度の情報を、パラメータとしてデータベース１０４へ記憶する。

【0057】

本実施の形態の保全管理システム１では、稼働時間、消費電力、取得する信号の強度をパラメータとして扱うが、各デバイス３００が記憶するその他の数値をパラメータとして扱ってもよい。
＜パラメータの予測手法＞
パラメータ予測部１０７は、パラメータ履歴１０４４が記憶する過去のパラメータ値に基づいて、将来のパラメータを予測する。

【0058】

稼働時間のもっとも単純な予測手法として、移動平均法が考えられる。パラメータ予測部１０７は、任意のデバイス３００の過去の一ヶ月単位の平均稼働時間が、５００時間である場合、現在より一ヶ月後の累積平均時間は、現在の累積平均時間から５００時間を加えたものとして予測することができる。パラメータの予測方法として、移動平均法のほかに指数平滑法を用いてもよい。また、過去の月別平均値を使用してもよい。

【0059】

ストレージ１５６は、移動平均法または指数平滑法などを用いた将来のパラメータを計算するための計算プログラムを記憶する。パラメータ予測部１０７は、当該計算プログラムを展開して、実行することで所定の期間経過後の稼働時間を計算することができる。パラメータ予測部１０７は、同一の手法により将来の消費電力を予測する。

【0060】

図４は、光電センサの受光強度を予測するための図である。図４の縦軸は、光電センサの受光強度を示し、横軸は、時間の経過を示す。パラメータ予測部１０７は、過去の光電センサの受光強度に基づいて図４で示すグラフを作成する。当該グラフは、受光強度と時間との関数を示すグラフである。光電センサの受光強度は、時間の経過に伴って徐々に低下する。パラメータ予測部１０７は、当該関数の係数を求めることで、将来の任意の時間においての受光強度を計算により、予測することができる。

【0061】

遮断１と遮断２と遮断３とは、光電センサの投光器と受光器との間をワークが通過したため、受光器が投光を受光できなくなったことを示している。図４では簡略化して表現しているため、遮断回数が３回のみの間に大きく受光強度が下がっているが、実際の運用では、受光強度が下がるまでに多数のワークを測定するため、図４よりも多数の遮断が存在することが想定される。

【0062】

検知閾値とは、光電センサが投光を適切に検知することができることを保証する閾値である。受光強度が検知閾値を下回った場合、光電センサは、投光器と受光器との間にワークが存在しないにもかかわらず、ワークがあると検知する可能性が生じる。閾値Ａ～閾値Ｃは保全状態を判断するために使用される閾値であり、詳しくは後述で説明する。このように将来のパラメータを予測することにより、パラメータ予測部１０７は、所定の期間が経過した時点での各デバイス３００の将来のパラメータの値を予測することができる。

【0063】

以下に、パラメータ予測部１０７が稼働時間を予測する具体的かつ簡易な例を示す。デバイス３００は、サーボモーターである。たとえば、製造システムでは、サーボモーターが３月１日に導入され、３月全体の稼働時間が４００時間、４月全体の稼働時間が６００時間であったとする。よって、デバイス３００であるサーボモーターの１ヶ月の平均稼働時間は、５００時間であり、累積稼働時間は１，０００時間である。

【0064】

５月１日時点において、パラメータ予測部１０７は、サーボモーターの累積稼働時間を、１ヶ月後の累積稼働時間が１，５００時間、２ヶ月後の累積稼働時間は２，０００時間、３ヶ月後の累積稼働時間は２，５００時間、１２ヶ月後の累積稼働時間は７，０００時間であると予測することができる。

【0065】

同様に、パラメータ予測部１０７は、たとえば、６ヶ月後のモーターの回転数あたりの消費電力や、１年後の光電センサの受光強度を予測できる。
＜保全状態の判断手法＞
本実施の形態における保全管理システム１は、保全状態を「正常」「注意」「警告」「危険」の４つに分類する。判断部１０８は、パラメータ予測部１０７が予測した所定期間経過時のパラメータの値に基づいて、各デバイス３００の所定期間経過時の保全状態を判断する。これにより、各デバイス３００の保全状態は分類される。

【0066】

具体的な分類方法として、閾値を用いることが考えられる。たとえば、保全管理システム１では、サーボモーターの稼働時間に、２，２５０時間、３，０００時間および６，０００時間の３つの閾値を設ける。判断部１０８は、パラメータ予測部１０７が所定期間経過時のサーボモーターの稼働時間が２，２５０時間未満であれば保全状態は、正常状態であると判断する。同様に、判断部１０８は、サーボモーターの稼働時間が２，２５０時間以上で３，０００時間未満であれば保全状態は、注意状態であると判断する。

【0067】

判断部１０８は、サーボモーターの稼働時間が３，０００時間以上で６，０００時間未満であれば保全状態は、警告状態であると判断する。判断部１０８は、サーボモーターの稼働時間が６，０００時間以上であれば保全状態は、危険状態であると判断する。

【0068】

２，２５０時間、３，０００時間および６，０００時間の３つの閾値は、各デバイス３００に定められた耐用年数を参考にして設定してもよいし、その他の条件に基づいてユーザーが任意の数値を設定できることとしてもよい。また、パラメータ履歴１０４４が保持する各デバイス３００の過去の稼働時間の実測値に基づいて定めてもよい。保全管理システム１では消費電力、取得する信号の強度についても、同様に閾値を定め、保全状態を判断する。

【0069】

図４に戻り、光電センサの保全状態の判断手法を説明する。閾値Ａ、閾値Ｂ、閾値Ｃは、光電センサの保全状態を判断するための閾値である。判断部１０８は、受光強度が閾値Ａ以上であるとき、保全状態は、正常状態であると判断する。判断部１０８は、受光強度が閾値Ａ未満で閾値Ｂ以上であるとき、保全状態は、注意状態であると判断する。

【0070】

判断部１０８は、受光強度が閾値Ｂ未満で閾値Ｃ以上であるとき、保全状態は、警告状態であると判断する。判断部１０８は、受光強度が閾値Ｃ未満であるとき、保全状態は、危険状態であると判断する。

【0071】

このように、判断部１０８が、所定の期間経過時の各デバイス３００の保全状態を判断することで、ユーザーは任意のデバイス３００について、いつ交換すべきか容易に判断することができる。また、判断部１０８は、１つのデバイスの複数のパラメータに基づいて、当該デバイスの保全状態を判断してもよい。たとえば、判断部１０８は、光電センサの保全状態を、受光強度と稼働時間とを組み合わせて判断する。受光強度が閾値Ｃ未満であって、かつ、稼働時間が特定の時間以上である場合に、判断部１０８は、保全状態が危険状態であると判断する。受光強度が閾値Ｃ未満であっても、稼働時間が特定の時間以上でなければ、判断部１０８は、保全状態が警告状態であると判断する。このように、保全管理システム１では、判断部１０８が、１つのパラメータからのみに限られず、複数のパラメータを用いて、デバイスの保全状態を判断してもよい。もちろん、判断部１０８は、光電センサ以外の他のデバイスにおいても、複数のパラメータを用いて保全状態を判断することができる。

【0072】

以下にて、パラメータ予測部１０７が予測する上述の例を用いて、保全状態を判断する例を示す。上述の通り、パラメータ予測部１０７は、１ヶ月後のサーボモーターの累積稼働時間は１，５００時間、２ヶ月後の累積稼働時間は２，０００時間、３ヶ月後の累積稼働時間は２，５００時間、１２ヶ月後の累積稼働時間は７，０００時間であると予測している。また、サーボモーターの累積稼働時間にかかる閾値は、２，２５０時間、３，０００時間および６，０００時間と設定されている。

【0073】

よって、判断部１０８は、１ヶ月後の保全状態は正常状態、２ヶ月後の保全状態は正常状態、３ヶ月後の保全状態は注意状態、１２ヶ月後の保全状態は警告状態であると判断する。
＜テーブル形式による製造システム全体の保全状態の表示方法＞
図５は、テーブル形式による製造システム全体の保全状態の表示方法を示す図である。図５では、製造システムに接続された各デバイス３００の稼働時間に基づいた保全状態を、２０１９年度の各月単位で表示している。図５で示すテーブルは、検索装置１００が備える表示部１６２に表示してもよいし、ネットワークを介して他の端末に表示させてもよい。

【0074】

図５で示すテーブルはリレーショナルデータベースに準じたテーブルである。当該テーブルは、判断部１０８が判断したデバイス３００の保全状態を含むデータが１行ずつ表示する。以下、左端の列から順に説明する。列「Position」は、各データを識別する識別子として利用される主キーである。列「Node」は、他のテーブルを参照するための外部キーである。

【0075】

列「ベンダ名」は、デバイス３００の製造元の名前を表示する。列「商品名」は、デバイス３００の商品名を表示する。列「累積稼働時間」は、デバイス３００の当該テーブルを表示した時点の累積稼働時間を表示する。列「閾値」は、保全状態を分類するための閾値を表示する。列「注意」が１６００の場合、累積稼働時間が１６００時間以上になれば、判断部１０８は、デバイス３００の保全状態が注意状態であると判断する。

【0076】

列「２０１９年」は、２０１９年度の各月の保全状態を時系列で表示する。列「２０１９年」のセルの両端に設けられた矢印のアイコンをクリック等で選択することで、２０１８年または２０２０年のデータを表示する。

【0077】

図５では、表示部１６２は、商品名が商品Ａ～商品Ｚの各デバイス３００が表示しているが、どのデバイス３００を表示するかは、ユーザーが選択可能である。同様に、表示部１６２は、保全状態は２０１９年度分が表示しているが、どの期間を表示するかはユーザーが選択可能である。

【0078】

図５で表示するデータの内容は、２０１９年５月１日時点での内容である。したがって、累積稼働時間は、各デバイス３００が導入されてから２０１９年５月１日までの稼働時間を示す。列「２０１９年」のうちの５月以降の保全状態は、パラメータ予測部１０７が予測した累積稼働時間に基づいて、判断部１０８が判断した保全状態である。列「２０１９年」のうちの４月以前の保全状態は、実際の累積稼働時間に基づいて、判断した保全状態である。

【0079】

保全状態における注意状態は交換時期が近いことを示し、一般的な製造システムでは、注意状態の期間は、新しいデバイス３００を発注する期間などの交換準備期間として扱われる。一方、警告状態のまま使用することはデバイス３００が故障する可能性があるため、注意状態の期間内で交換準備をし、警告状態になったところで交換をすることが予防保全の考え方として一般的である。

【0080】

この予防保全の考え方に従えば、商品Ａは、７月に交換準備をして８月に交換をする。商品Ｂは、２０１９年内に交換準備をする必要はない。商品Ｃは、５月に交換準備を始め７月に交換をする。商品Ｚは、８月に交換準備を始め１１月に交換をする。

【0081】

しかし、商品を交換するということは、少なくとも製造システムの一部分の稼働を停止させる必要があり、交換の度に、製造システムの稼働を停止させることは製造システム全体の生産性、稼働率を低下させる。

【0082】

そこで、図５で示すテーブル形式で各デバイス３００を時系列で並べて表示することで、より効率的に交換ができる適切な交換時期を計画することができる。

【0083】

具体的には、保全管理システム１では、商品Ａ、商品Ｃ、商品Ｚを同時に交換すべきであることが計画できる。商品Ａ、商品Ｃ、商品Ｚを各々交換すれば３回交換しなくてはならないが、商品Ａ、商品Ｃ、商品Ｚを同時に交換すれば１回の交換で済み、効率的である。図５を参照して、たとえば８月に商品Ａ、商品Ｂ、商品Ｃを交換すればよいことを知ることができる。商品Ａは、８月に警告状態となるため、適切な時期での交換である。

【0084】

商品Ｃが警告状態となるのは７月ではあるが、交換を見送り、８月まで交換を見送る。仮に７月中に故障したとしても、あらかじめ交換準備をすることができるため、比較的に生産性を低下させることなく、交換処理ができる。商品Ｚは、８月の時点では注意状態であるが、１１月に交換するよりも８月で商品Ａと商品Ｃと合わせて交換することで製造システム全体の稼働率を上げることができる。

【0085】

日本では、一般的に８月のお盆期間と１月の正月期間とに工場内で規模の大きいメンテナンスがされる。商品Ｚの保全状態が危険状態となるのが１月の正月期間よりも前であるため、８月のお盆期間に交換すべきであるといった判断をさせることが容易となる。

【0086】

このように、予測した将来の稼働時間の値に基づいて判断する保全状態をテーブル形式で表示することで、製造システム全体の生産性を低下させることなく各デバイス３００の適切な時期を計画することができる。

【0087】

本実施の形態において、保全管理システム１では、交換時期を徒過していることを示す状態を、危険状態であると定義しているが、さらに閾値を設定し分類を設けてもよい。たとえば、図４で、判断部１０８は、受光強度が閾値Ｃ未満となれば一律で危険状態であると判断する。しかし、受光強度が検知閾値未満となった場合、光電センサは、投光を受光できず、光電センサとしての機能をすることができない。そこで、判断部１０８は、受光強度が検知閾値未満となった場合、「要交換」などの直ちに交換が必要である時期を示す状態であると判断してもよい。

【0088】

さらに、保全管理システム１では、ユーザーが交換時期を計画して定めた場合、任意のデバイス３００の交換時期を入力部１６０より受け付け、交換した後の稼働時間を再度予測し直して、表示してもよい。これによれば、保全管理システム１では、交換後のデバイス３００の交換時期を表示することができる。また、制御部１５２は、実際に交換したという情報を入力部１６０から受け付けることで、デバイス３００の総稼働時間を計算し、閾値を自動で調整してもよい。

【0089】

図６は、任意のデバイス３００に関する詳細情報の表示方法を示す図である。図５の商品Ａの行をクリックすることで図６に示す情報を表示する画面へと画面遷移する。下部に表示するテーブルは、保全状態を判断するための詳細な情報を示す。図６のテーブルでは、図５と比べて月別の稼働時間と月別の累積稼働時間とが示されている。

【0090】

４月以前の稼働時間と累積稼働時間は実測値であり、５月以降の稼働時間と累積稼働時間はパラメータ予測部１０７が予測した値である。「２０１９年４月」で示す列を参照すれば、２０１９年４月全体の稼働時間が１５５時間であることがわかり、２０１９年４月１日時点での累積稼働時間が１，２９５時間であることがわかる。したがって、２０１９年５月１日時点での累積稼働時間が１，２９５時間に１５５時間を加算した１，４５０時間である。

【0091】

「２０１９年５月」で示す列を参照して、２０１９年５月１日時点での累積稼働時間が１，４５０時間であることがわかる。中央上部のテーブルを参照して、図６で示す画面を表示する日付は２０１９年５月１日であるため、２０１９年５月全体の稼働時間の実測値は存在しない。しかし、パラメータ予測部１０７によって、２０１９年５月全体の稼働時間が予測される。これにより、２０１９年５月全体の稼働時間が計算できる。

【0092】

計算された２０１９年５月全体の稼働時間は１５９７．２５時間である。判断部１０８は、当該稼働時間と閾値とを比較して保全状態を判断する。１５９７．２５時間は、右側上部のテーブルで示されるよう注意状態となる閾値１，６００時間未満であるため、判断部１０８は、２０１９年６月の保全状態は正常状態であると判断する。

【0093】

このように、詳細情報を表示することにより、保全状態を判断する基準となったパラメータ予測部１０７が予測する稼働時間を確認することができ、より正確な判断をすることができる。
＜処理手順＞
図７は、製造システム全体の保全状態の表示する処理手順を示す図である。制御部１５２は、製造システム全体の保全状態の表示命令を受け付けたか否かを判断する（ステップＳ１００）。製造システム全体の保全状態の表示命令を受け付けていない場合（ステップＳ１００でＮＯ）、処理をステップＳ１００に留める。

【0094】

製造システム全体の保全状態の表示命令を受け付けた場合（ステップＳ１００でＹＥＳ）、制御部１５２は、表示する各デバイス３００の情報と、表示する期間を受け付ける（ステップＳ１１０）。たとえば、入力部１６０が商品Ａ、商品Ｂ、商品Ｃのみの２０２１年度の保全状態を表示するという命令をユーザーから入力された場合、入力部１６０は、商品Ａ、商品Ｂ、商品Ｃというデバイス３００の情報と、２０２１年度という期間の情報を制御部１５２に送信する。

【0095】

制御部１５２は、入力されたデバイス３００の過去のパラメータの値をデータベース１０４から取得する（ステップＳ１２０）。制御部１５２のパラメータ予測部１０７は、過去のパラメータの値に基づいて、入力された期間での将来のパラメータ値を予測する（ステップＳ１３０）。

【0096】

制御部１５２の判断部１０８は、パラメータ予測部１０７が予測したパラメータの値と、設定された閾値とから、各デバイス３００の保全状態を判断する（ステップＳ１４０）。制御部１５２は、入力された期間での各デバイス３００の保全状態を、表示部１６２へ送信し、表示部１６２は製造システム全体の保全状態を表示する（ステップＳ１５０）。
＜アイコンによる製造システム全体の保全状態の表示方法＞
図８は、アイコンによる製造システム全体の保全状態の表示画面例１を示す図である。図８では、ＰＬＣ２００や各デバイス３００をそれぞれアイコン化し、製造システムの全体を俯瞰できるようにシステム構成を図示したうえで、それぞれのＰＬＣ２００と各デバイス３００の稼働時間に基づいた保全状態を表示する。なお、図８で示した表示形式を、以下アイコン形式の表示という。このようなアイコン形式の表示では、図５に示したテーブル形式の表示と異なり製造システムの接続関係を一見して把握することができる。

【0097】

図８で示す製造システムは、ＰＬＣ２００にデバイスＡ～デバイスＧとがデイジーチェーン型のネットワーク構成で接続されている。当該製造システムのネットワークは、Ｅｔｈｅｒｃａｔをプロトコルとして採用する。もちろん、他のプロトコルを用いてもよい。

【0098】

ＰＬＣ２００は、ＣＰＵユニットＵ１と、電源ユニットＵ２と、ＩＯユニットＵ３と、ＩＯユニットＵ４とを備える。デバイスＡは、スレーブターミナルであり、ＰＬＣ２００と同様に、ＣＰＵユニットＵ１と、電源ユニットＵ２と、ＩＯユニットＵ３と、ＩＯユニットＵ４とを備える。デバイスＢ～デバイスＥは、サーボモーターである。デバイスＦおよびデバイスＧは、汎用スレーブである。もちろん、その他の種類のデバイス３００が接続されることが想定される。

【0099】

図８で示す画面の下部に表示されているスライドバーは、図８で示す画面を表示している時から何ヶ月先の製造システムの保全状態を表示するかを示している。図８では、３ヶ月後先の製造システムの保全状態を表示する。制御部１５２は、ユーザーがスライドバーを移動させることによって、対応する時の製造システムの保全状態を表示部１６２に表示させる。もちろん、スライドバーではなく、たとえばユーザーがキーボード等から所定期間を直接入力することで、表示する時を変更させてもよい。

【0100】

表示部１６２は、画面の右上部に保全状態の分類である「注意」「警告」「危険」を表示する。「注意」「警告」「危険」は、それぞれに特有のハッチングが付される。ＰＬＣ２００と各デバイス３００とは、それぞれの保全状態に対応して、分類に対応するハッチングが付される。保全状態が正常状態である場合は、ＰＬＣ２００と各デバイス３００とはなんらハッチングが付されない。

【0101】

図８を参照して、ＰＬＣ２００の電源ユニットＵ２とＩＯユニットＵ４と、デバイスＤとは、注意状態に対応するハッチングが付されている。これにより、ユーザーは図８で示す画面を参照して、ＰＬＣ２００の電源ユニットＵ２とＩＯユニットＵ４と、デバイスＤとの保全状態が、３ヶ月後に注意状態であると判断できる。同様に、デバイスＡのＩＯユニットＵ３とデバイスＦの保全状態は、３ヶ月後に警告状態になる。もちろん、保全管理システム１は、ハッチングではなく色彩を用いて分類を分けて表示してもよい。

【0102】

保全状態の判断手法は、図５で用いた判断方法と同一であり、パラメータ収集部１０６が収集した過去のパラメータに基づいて、パラメータ予測部１０７が将来のパラメータの値を予測し、判断部１０８が保全状態を判断する。すなわち、図８で示す画面を表示するために必要な情報は、図５で示すテーブルを表示するために必要な情報と同一であり、収集方法も同一である。

【0103】

図９は、アイコンによる製造システム全体の保全状態の表示画面例２を示す図である。図８では３ヶ月後の製造システムの保全状態を表示しているのに対して、図９で示す画面は、９ヶ月後の製造システムの保全状態を表示している。期間が経過したことにより、パラメータ予測部１０７は、各デバイス３００の累積稼働時間が３ヶ月経過時点よりも長くなると予測する。

【0104】

図９で示す画面では、ＰＬＣ２００のＩＯユニットＵ４と、デバイスＡのＩＯユニットＵ３と、デバイスＤと、デイバスＦとの保全状態が、危険状態であることを示す。ＰＬＣ２００の電源ユニットＵ２と、デバイスＡのＩＯユニットＵ４との保全状態は、警告状態である。デバイスＢとデバイスＧとの保全状態は、注意状態である。

【0105】

このように、製造システムの接続関係を表示するアイコン形式で、各デバイス３００の保全状態を表示することにより、ユーザーは、実際の各デバイス３００の接続関係を考慮して交換時期を計画することができる。たとえば、図９で示す画面では、デバイスＤを交換する際に、ネットワークトポロジの形態上、デバイスＥとデバイスＦとデバイスＧとが、ネットワークから非接続状態となることをユーザーに一見して把握させることができる。

【0106】

これにより、たとえば図８で既にデバイスＦは警告状態であるが、図９で示す画面では、デバイスＤが危険状態となることがわかる。スライドバーで表示する期間を変更することで、ユーザーは、３ヶ月後経過時にはデバイスＤを交換する必要はないが、９ヶ月後経過時には交換が必要となることを知ることができる。そのため、保全管理システム１は、デバイスＤの交換時と同時にデバイスＦを交換することで、製造システム全体の生産性、稼働率を低下させることのない各デバイス３００の交換時期を容易に計画させることができる。

【0107】

保全管理システム１は、ユーザーからの命令により、図８で示すテーブル形式の表示方法と、図９で示すアイコン形式の表示方法とを、交互に画面遷移させることができる。
＜小括＞
以上のように、本実施の形態の保全管理システム１は、複数のデバイス３００が接続された製造システムの保全状態を管理する保全管理システム１であって、各々のデバイス３００の保全状態の管理に必要なパラメータの値を、所定のタイミングで収集するパラメータ収集部１０６と、パラメータ収集部１０６で収集したパラメータの値をデバイス３００ごとに記憶するデータベース１０４と、データベース１０４に記憶した過去のパラメータの値から、将来のパラメータの値をデバイス３００ごとに予測するパラメータ予測部１０７と、パラメータ予測部１０７で予測した将来のパラメータの値に基づいて、所定期間経過したごとにデバイス３００の保全状態を判断する判断部１０８とを備える。保全管理システム１は、製造システムに含まれる複数のデバイス３００について、少なくとも１つの所定期間経過した時点の判断部１０８で判断した保全状態を表示する表示部１６２とを備える。これによれば、製造システムに接続された多数の機器の状態を確認し、製造システム全体の生産性を低下させない各機器の適切な交換時期の計画を容易にすることができる。

【0108】

また、判断部１０８は、所定期間経過した時点の将来のパラメータの値が所定の閾値を超えているか否かに基づいて、デバイス３００の保全状態を判断する。これによれば、閾値に基づいてデバイス３００の保全状態を判断することができる。

【0109】

さらに、判断部１０８は、所定期間経過した時点の将来のパラメータの値に基づいて、デバイス３００の保全状態の区分を判断する。これによれば、デバイス３００の保全状態を所定の区分に分けて判断することができる。

【0110】

また、パラメータ収集部１０６が収集するパラメータは、各々のデバイス３００の稼働時間である。これによれば、稼働時間に基づいて、保全状態の判断をすることができる。

【0111】

さらに、複数のデバイス３００は、センサを含み、パラメータ収集部１０６が収集するパラメータは、センサが取得する信号の強度である。これによれば、センサが取得する信号強土に基づいて、センサの保全管理を判断することができる。

【0112】

また、パラメータ収集部１０６が収集するパラメータは、デバイス３００の消費電力量である。これによれば、デバイス３００の消費電力量に基づいて、保全状態の判断をすることができる。

【0113】

さらに、表示部１６２は、製造システムに含まれる複数のデバイス３００の各々の保全状態を時系列に並べたテーブル形式で表示する。これによれば、ユーザーは、複数のデバイス３００の全体の交換時期を一括して確認することができ、製造システム全体として効率的な交換時期を計画することができる。

【0114】

また、表示部１６２は、製造システムに含まれる複数のデバイス３００のうちの１つのデバイス３００の保全状態と将来のパラメータの値とを時系列に並べたテーブル形式で表示できる。これによれば、詳細な情報をユーザーに対して表示することができる。

【0115】

さらに、表示部１６２は、製造システムに含まれる複数のデバイス３００の各々をアイコンで表示し、デバイス３００の保全状態を識別可能な表示態様でアイコンに表示し、各々のアイコンを接続させて複数のデバイス３００の接続関係を示すように表示する。これによれば、ユーザーは製造システムの接続関係とともに、各デバイス３００の交換時期を確認することができ、製造システム全体として効率的な交換時期を計画することができる。

【0116】

また、表示部１６２は、アイコンに表示させるデバイス３００の保全状態の所定期間の変更を受け付ける受付手段を表示する。これによれば、ユーザーは、表示する所定期間を変更することができる。

【0117】

さらに、受付手段は、所定期間単位に移動可能なスライドバーである。これによれば、ユーザーは、スライドバーを用いて容易に表示する所定期間を変更することができる。

【0118】

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

【符号の説明】

【0119】

１ 保全管理システム、１００ 検索装置、１０２ インターフェイス、１０４ データベース、１０６ パラメータ収集部、１０７ パラメータ予測部、１０８ 判断部、１１０ 通信処理部、１５２ 制御部、１５４ メインメモリ、１５６ ストレージ、１５８ 上位ネットワークコントローラ、１６０ 入力部、１６２ 表示部、１６４ 下位ネットワークコントローラ、１６６ メモリカードインターフェイス、１６８ メモリカード、１７０ バス、３０６ データソース、４００ リクエストパケット、４５０ レスポンスパケット、１０４１ 構成情報、１０４２ デバイスプロファイル、１０４３ インデックス、１０４４ パラメータ履歴、１５６０ 検索プログラム、１５６２ 自動更新プログラム、１５６４ システムプログラム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】