JPH06222922A - エキスパートシステム - Google Patents

Abstract

(57)【要約】 【目的】故障診断における一つの知識表現モデルを確立
し、これをロボットコントローラ等の装置等の故障診断
に応用可能なエキスパートシステムを提供すること。 【構成】エキスパートシステムを構成する知識ベース全
体を５ブロックに分割する。「状態遷移ブロック」を最
上位の故障診断木として、その下に「状態解析ブロッ
ク」、「部位解析ブロック」、「マニュアル知識ブロッ
ク」及び「部位確認ブロック」をおく。これにより、推
論の流れをコントロールすることが容易となり、装置等
の故障診断用エキスパートシステムを実現できる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、装置等の故障診断を行
うエキスパートシステムに関する。

【０００２】

【従来の技術】エキスパートシステム（以下ＥＳとす
る）は、推論機構，知識ベース，データベース及びユー
ザーインターフェイスを有しており、専門家が持ってい
る専門領域の問題解決の知識を集めて、その思考過程を
まねた「推論制御」により解を導く、コンピュータによ
る支援システムのことである。

【０００３】

【発明が解決しようとする課題】しかし、現実には専門
家の知識や問題解決の思考過程を明確化していく作業は
困難を伴う。信頼性の高いＥＳを実現するには、対象と
する領域の知識を収集するだけでなく、この表現方法を
最適化し、専門家と同様な解を得るための推論制御方法
を確立することが必要である。

【０００４】本発明の課題は、故障診断における一つの
知識表現モデルを確立し、これをロボットコントローラ
等の装置等の故障診断に応用可能なエキスパートシステ
ムを提供することにある。

【０００５】

【課題を解決するための手段】本発明は、ロボットコン
トローラ等の故障診断ＥＳの知識ベース開発の中で、知
識をいくつかのブロックすなわち状態遷移、状態解析、
部位解析、部位確認、マニュアル等の知識のブロック手
段に分けたものである。

【０００６】即ち、第１の発明としては、推論機構，知
識ベース，データベース及びユーザーインターフェイス
を有する装置等の故障診断エキスパートシステムであっ
て、知識ベースの構造を、装置等の正常動作した動作状
態と未知の動作状態とを峻別する状態遷移ブロック手段
と、異常状態から１又は２以上の異常部位の候補を挙げ
る部位解析ブロック手段と、候補に挙がった異常部位を
確認して特定する部位確認ブロック手段とに分けたこと
を特徴とする。

【０００７】また第２の発明としては、推論機構，知識
ベース，データベース及びユーザーインターフェイスを
有する装置等の故障診断エキスパートシステムであっ
て、知識ベースの構造を、装置等の正常動作した動作状
態と未知の動作状態とを峻別する状態遷移ブロック手段
と、異常状態を解析する状態解析ブロック手段と、状態
解析ブロック手段における異常状態から１又は２以上の
異常部位の候補を挙げる部位解析ブロック手段とに分け
たことを特徴とする。ここで、上記の場合において、状
態遷移ブロック手段における異常に関する告知情報に基
づいて故障部位を提示するマニュアル知識ブロック手段
を有することが好ましい。また状態遷移ブロック手段に
おける異常に関する告知情報に基づいて異常部位の候補
を前記部位確認ブロック手段に送るマニュアル知識ブロ
ック手段を有することが好ましい。

【０００８】

【作用】かかる発明によれば、故障診断を対象として、
上記の推論形式を基にした知識のブロック化は、専門家
の故障診断の思考過程に合致しており、知識の全体構成
が見通の良い、知識ベースの構築手法である。これによ
り、推論の流れをコントロールすることが容易となり、
ロボットコントロータ等の故障診断に応用するに実現性
がある。

【０００９】

【実施例】次に、本発明の実施例に係るロボットコント
ローラ故障診断用エキスパートシステムを添付図面に基
づいて説明する。

【００１０】〔ロボットコントローラ故障診断用ＥＳの
構成〕本ＥＳは、ロボットコントローラの異常症状から
故障部位を判定するものであり、代表的な分析型問題を
対象とした対話型コンサルテーションシステムである。

【００１１】・システム構成 本ＥＳのシステム構成を図１に示す。利用者は故障した
コントローラに関する簡単な情報を入力して、ＥＳから
の質問に答える。ＥＳは故障部位を判定し、さらに故障
に関するデータベースを作成する。ＥＳは基本的に、推
論機構、知識ベース、データベース、ユーザインターフ
ェースの四つの部分から構成されている。

【００１２】推論機構は、知識表現と密接な関係があ
り、様々な形式が研究されている。ここでは、既存の開
発ツールを利用し、前向きおよび後ろ向きの両方向推論
形式を採用している。

【００１３】知識は知識ベースとデータベースにより表
現され、以下の知識からなる。

【００１４】知識ベース：設計情報、診断事例、担当者
の保守情報 データベース：顧客情報、納品機種、出荷時の調整デー
タなど ユーザインターフェースは、知識ベースの入力や保守を
容易にしたり、推論機構とＥＳ利用者のやりとりを行う
機能である。

【００１５】・システムの実現 ＥＳは使用する開発ツールに大きく左右されるが、現有
のコンピュータが利用できて、比較的汎用的な開発ツー
ルである「ＮＥＸＰＥＲＴ ＯＢＪＥＣＴ」を選択し
た。システム構成は次の通りである。

【００１６】コンピュータ：Ｓｕｎ ＳＰ２ 開発ツール ：ＮＥＸＰＥＲＴ ＯＢＪＥＣＴ Ｖｅｒ．２ 開発言語 ：Ｃ言語 知識ベースを構成する個々のルールは図２に示す構造で
ある。左辺が条件部であり、右辺は上が仮説で下が動作
部である。ルールの基本となる知識は、マニュアル・設
計者・診断事例であり、これらからデータを集めてひと
つひとつの事実に分解し収集した。この時点では約１５
００の知識であった。これを、内容の同じものやデータ
として不完全なものを除いて、約３００の知識にまとめ
た。

【００１７】データベースは、パソコンのデータベース
を移植した。ロボット納品時に、ロボットとコントロー
ラに関してその構成と調整データを機能仕様書として作
成し、パソコンに入力している。このデータを更新の都
度、データ変換してＥＳのコンピュータに移植できるよ
うにした。

【００１８】ユーザインターフェースは、ＥＳ利用者の
希望を盛り込むことが重要であると考えて自作した。こ
の特徴は、複数の機能仕様書を同時に参照できること
と、推論の過程を後戻り可能にしたことである。

【００１９】〔知識表現モデルの検討〕 ・故障診断木の作成 ロボットコントローラが故障した場合、利用者は故障部
位を探すために、まず点検を行う。コントローラの自己
診断機能により、文字表示パネルやＬＥＤ表示で故障部
位を性格に絞り込めることが理想的であるが、実際には
ケーブルやコネクタ、モーターの発熱、センサーの機能
などを点検することが必要になる。

【００２０】点検を主体に、知識を整理する方法は、因
果マトリクスと故障診断木による知識表現が、故障の因
果関係を表現しており適しているといえる。マトリクス
は、知識の表現がわかりやすいが、現在これに適した開
発ツールがなく、技術的にも完成されていないと言われ
ている。そこで、点検結果を分岐点の判断にした故障診
断木による知識表現を採用した。以下、ルールをツリー
構造で表現した故障診断木を基に推論形式の検討をし
た。

【００２１】作成した故障診断木の一部分を図３に示
す。この図では、分岐点となる部分を四角の枠で囲って
ある。たとえば、オペパネ（オペレータパネル）表示で
は、正常の表示なのか、表示自体が異常なのか、または
エラー表示なのかを点検によって確認し、次の点検に進
む。

【００２２】・故障診断木に基づく推論の問題点 第一段階は、仮説推論を推論形式として利用した。図４
は仮説推論のリンク形式を示す。ルール間のリンクは、
仮説のみから他のルールの条件部にリンクしている。具
体的には、ルール１の仮説１がルール４の条件部にリン
クしており、ルール２、３についても同様である。ま
た、ルール４の仮説４がルール５の条件部にリンクして
いる。仮説推論では、リンクによりルール間を関連づけ
ている。このリンクを利用して、１００ルールほどの、
故障診断木で整理された知識を表現した。

【００２３】ＥＳを動作させてみると、正しい結論は得
られたものの以下の三つの問題が認められた。第一は質
問の順番の問題、第二は複数リンクの問題、第三は保守
性の問題である。

【００２４】第一の問題は、質問の順番であるが、コン
ピュータから人に問い合わせる質問の順番が的を射てい
ないことである。

【００２５】第二の問題は、ネットワーク上の複数リン
クの問題である。図３に、オペパネ系点検の項目が二ヵ
所ある。このオペパネ系点検というルールは一組だけ入
力しておき両方からリンクされているが、開発ツール内
部のネットワーク図にはどちらか片方しかリンク線を引
くことができない。これは開発ツールの推論機構の基本
的特性が原因である。このことはルールの修正・追加時
に、関係するルールを自動検索でなく、人手で探さなけ
ればならないという不便さを招く。

【００２６】第三の問題は、故障診断木が複雑になり保
守性が悪くなる問題である。故障診断木を基に知識ベー
スを作成して、故障部位を探すことはできた。しかし、
この方法のままでルール数を増やすと、故障診断木の構
造が複雑になりすぎることが分かってきた。複雑な構造
でもコンピュータの推論としては問題ないが、新たな故
障例が発生して、人間がルールを追加をする場合には問
題となる。今後の保守性を考えると、できる限り分かり
やすい構成にしなければならない。

【００２７】・問題点の解決策の検討 上記の、三つの問題を解決するために、（１）質問順番
の制御、（２）リンク方法の改善、（３）知識ベースの
ブロック化を検討した。ここでは、（１）（２）を説明
し、（３）は問題が大きいので、これについては後述す
る。

【００２８】（１）質問順番の制御 推論の順番の問題を具体的にあげると、ＥＳの質問が、
「オペパネ表示正常か」をした後で、「オペパネ表示異
常か」という質問を出してくるということである。現実
には、後の質問は無意味である。この原因は、「オペパ
ネ正常表示」と「オペパネ表示異常」の一つが真になっ
ても、他の真偽が確定していないためである。このた
め、複数の選択肢から一つを選択する場合には、一つの
ルールが真となったら他のルールは全て偽となるような
処理を追加した。

【００２９】また、無駄な質問を行わないようにするた
めに、点検の時系列的な流れに沿って質問を出すことを
検討した。これについては以下で説明する。

【００３０】（２）リンク方法の改善 上述の推論では、ルール間のリンクが不十分であるた
め、ＦＴＧ（Forward Through Gates ）を推論形式とし
て用いた。ＦＴＧは、ルールの左辺の条件部に同じ条件
を入れておくと、共通の条件を持つ全てのルールを取り
出して評価を行う推論形式である。すなわち、ＦＴＧで
はリンクがなくても同じ条件を持つ複数のルールを評価
することができる。図５において、ルール１が評価され
ると、条件Ａを持つルール２も評価されることになる。
結果として、ＦＴＧでは複数のリンクがあるのと同等の
動作をさせることができる。このため、複数の場所にリ
ンクする構造の故障診断木に対応することができた。

【００３１】〔知識のブロック化〕 ・状態遷移ブロックの導入 知識を効率よく表現するためには、知識ベースをいくつ
かのクラスに分類し、各クラスに適した表現モデルが必
要と言われている。ここで知識ベースの分割を検討し
た。

【００３２】立ち上げ時のロボットコントローラの状態
は、「電源投入」から始まり、「システムローディン
グ」、「サーボＯＮ」と順番に遷移し最後は「自動運
転」までの８状態である。この状態を、一本の故障診断
木では表現がしにくいが、分割と同時にこの問題も解決
することを検討した。故障部位の絞り込みの条件に、時
系列的な因果関係を考慮すると、知識ベース全体が整理
しやすくなると同時に、無駄な質問をなくす効果もある
と考えたからである。

【００３３】分割した故障診断木を「状態遷移ブロッ
ク」とした。故障がこの動作状態のとこのステップで発
生したかに応じて、条件付けをして、故障診断を行う構
成とした。このブロックの導入により、コントローラの
正常動作した部分と未知な部分の切り分けを行い、この
あとに推論するルールの選択を的確にすることができ
た。

【００３４】前記の「状態遷移ブロック」以外の知識ベ
ースを「部位確認ブロック」とした。これは、最初に試
作した故障診断木に対応したもので、最終的に故障部位
を決定する。前記の「状態遷移ブロック」を上位の故障
診断木として、その下に「部位確認ブロック」の故障診
断木を形成した。診断の流れとしては、「状態遷移ブロ
ック」で装置の正常動作した部分の情報を持った上で
「部位確認ブロック」に入り、故障部位の診断を行う構
成とした。

【００３５】・推論制御方法の検討 故障診断木の変更にともない、推論形式も変更する必要
がある。「状態遷移ブロック」の状態を全て順番にたど
るのは、質問が多くなり好ましくない。そこで、任意の
状態にジャンプする機能が必要になる。また、一つの木
から他の木へ推論がジャンプできるようにしなければな
らない。このようなニーズには、ＦＡＥ（Ｆｏｒｗａｒ
ｄ Ａｃｔｉｏｎ Ｅｆｆｅｃｔ）といわれる推論形式
で対応可能と決められた。

【００３６】図６は、ＦＡＥを使うときの推論形式を示
す。ＦＡＥはルールの動作部でデータの変更があると、
そのデータを左辺で使用しているルールを全て、評価す
るための順番待ちのリスト（以下評価リストと略す）に
入れる推論制御である。ルール１が評価されると、仮説
でリンクされたルール２が評価リストに入ると同時に、
Ａが真になるためＡを条件に持つルール３も評価リスト
に入る。

【００３７】ＦＡＥによる知識表現を、図７に示し、推
論の流れを説明する。ルール２、３の左辺の条件の一つ
に、共通の条件Ａがあり、これらのルールが評価リスト
に入ったとする。このとき、ルール３のＢが真になる
と、ルール５、６が評価リストに入り、ルール２のＣが
真になると、ルール８、９が評価リストに入る。このよ
うに、推論の流れは、ルールのリンクを順次たどること
も、離れたルールに移ることも、分岐するときのルール
の条件により制御が可能になった。故障診断木に対応さ
せると、ルール２、３の組とルール５、６の組それにル
ール８、９の組が、各々点検項目に相当する。また、ル
ール１、４、７は枝である。

【００３８】このように、推論の流れは、図７の右側か
ら左側に流れる。複数のルールの同時質問で確認を行っ
て、状態遷移の順番をたどりながら、あるいは飛び越し
て、故障部位の絞り込みの条件を得ることが出来るよう
になった。また、この条件を設定後に、ＦＡＥによって
「部位確認ブロック」の任意のルールへ推論がジャンプ
できることを可能にした。

【００３９】・知識ブロックの最終構成 推論のジャンプをＦＡＥで実現することによって、一本
の故障診断木を分割しても動作させることができた。し
かし、二つの知識ブロックではブロック化は不十分であ
り、更に、機能単位にブロック化をはかり、知識を整理
した。この目的のもとに検討した結果、知識ベース全体
を大きく５ブロックに分割することにした（図８）。
「状態遷移ブロック」を最上位の故障診断木として、そ
の下に「状態解析ブロック」、「部位解析ブロック」、
「マニュアル知識ブロック」それに「部位確認ブロッ
ク」である。

【００４０】ここで、新たに追加した三つのブロックに
ついて簡単に説明する。状態解析ブロックは、異常状態
が暴走なのかサーボダウンなのかなどにより解析する知
識である。ロボットは複数の可動軸を有するが、異常状
態は各軸に共通しており、この共通する部分をまとめる
ことにした。診断事例の中で、特定軸の異常状態からあ
る故障部品をさがし出した例の場合、この事例のルール
の入力を、各軸ごとに入れるのではなく、状態解析ブロ
ックに一つだけ入れれば良くなるのである。また、この
知識ブロックは、部位には直接関係しないで、状態を詳
しく解析する機能であり、ロボットコントローラの数機
種に対して共通の知識とすることができる。

【００４１】部位解析ブロックは、故障状態から故障部
位の特定を行うために、推論を展開し解析する知識であ
る。このブロックは、前述の部位確認ブロックが異常の
確認を行うのに対して、異常の可能性のある部位を解析
する機能として分割した。ある特定の軸が暴走している
とき、この軸に関連する部位だけを解析し、他の軸や関
連のない部位は解析しないように確認するべき部位を制
限することができる。

【００４２】マニュアル知識ブロックは、表示パネル等
から得られる情報を基にして、ユーザが簡易に診断を行
うためのマニュアル化されている知識である。この知識
は、機種ごとのマニュアルに対応しており、各々機種ご
との知識ブロックを構成した。この知識は、マニュアル
を作成したときに決定されていて、ルールの入力後には
基本的に変更がない。

【００４３】・知識ブロックの推論の流れ 前述したように知識をブロック化したとき、知識ブロッ
ク単位の推論の流れは、基本的に次のようになる。最初
に「状態遷移ブロック」で、電源投入後どの段階まで正
常に動作したかを調べる。次に、異常発生に関して表示
パネル等にエラーメッセージなどがある場合には「マニ
ュアル知識ブロック」を利用する。異常表示がない場
合、また表示があっても故障部位を特定できない時は
「状態解析ブロック」で、どのような状態にあるかを調
べる。この故障状態から「部位解析ブロック」で、可能
性のある故障部位を解析し特定する。この故障部位の可
能性を「部位確認ブロック」で確認し決定する。このよ
うに、知識ベースを分割することで、推論の流れをコン
トロールすることが容易となった。

【００４４】〔評価〕本例で得られた知識表現モデルに
基づき作成された知識ベースに加え、データベース、ユ
ーザインターフェース機能を開発して、ＥＳとして完成
することができた。評価は、実際の診断事例数十例を使
い正しい故障部位を見つけられるか確認を行った。その
結果、全ての診断事例とＥＳの推論は同じ結論が得られ
た。また、使用上特に不都合を感じるようなおかしな質
問もなかった。本例で述べた「状態遷移」の導入と、知
識を機能・特徴ごとのブロックに分割する知識ベース作
成の方法は、故障診断システム開発においてその有効性
が評価できた。

【００４５】問題の一般性については、故障診断木に基
づく推論の問題点として三点あったが、第二の複数リン
クの問題はＥＳ開発ツール固有の問題といえる。しか
し、他の問題は故障診断ＥＳの一般的な問題であり、本
例で述べた知識のブロック化は、推論制御を考慮した知
識表現モデルとして有効であるといえる。

【００４６】知識ベースの知識源に関しては、設計情
報、診断事例、担当者の保守情報があるが、状態遷移ブ
ロックとマニュアル知識ブロック以外はほとんどが診断
事例である。診断事例が得られなければ知識ベースの性
能が上がらないという問題がある。設計情報から、より
多くの故障診断に有効な知識を得ることが課題である。

【００４７】知識ベース構築において、一本の故障診断
木からスタートし、ここにある問題点を解決し一つの知
識表現方法を確立できた。しかし、より多くの知識量や
情報量を扱った問題や、別の推論制御方法では違った答
えが出てくる筈である。実用的なＥＳを開発するために
は、専門家から知識を如何に規則として取り出すか、事
例をどのような形で表現すべきか等の問題を含め、多く
のアプローチを試みる必要がある。

【００４８】ＥＳの構築のアプローチのひとつとして、
知識ベースにおける知識表現に関し、故障診断木を基に
した推論形式の検討を行った。一本の故障診断木に基づ
く推論には、質問の順番、複数リンク、保守性の問題が
発生した。これらの問題に対し、仮説推論にＦＴＧとＦ
ＡＥによる推論形式を加えることと、知識のブロック化
により、解決出来ることが判明した。

【００４９】

【発明の効果】以上説明したように、本発明は、故障診
断を対象として上記の推論形式を基にした知識のブロッ
ク化した点に特徴を有するものである。この知識のブロ
ック化は、推論制御用ブロックとして「状態遷移」の導
入と、機能・特徴ごとに知識を分割することが有効であ
る。具体的なブロック手段は、「状態遷移ブロック手
段」を最上位の故障診断木として、その下に「状態解析
ブロック手段」、「部位解析ブロック手段」、「マニュ
アル知識ブロック手段」それに「部位確認ブロック手
段」である。また、このブロック化は、専門家の故障診
断の思考過程に合致しており、知識の全体構成が見通の
良い、知識ベースの構築手法である。これにより、推論
の流れをコントロールすることが容易となり、ロボット
コントロータ等の故障診断に応用するに実現性がある。

【図面の簡単な説明】

【図１】本発明の実施例に係るロボットコントローラ用
エキスパートシステムのシステム構成をブロック図であ
る。

【図２】同実施例における知識ベースを構成する個々の
ルールの構造を示す図である。

【図３】同実施例における故障診断木の一部分を示す図
である。

【図４】同実施例における仮説推論のリンク形式を示す
図である。

【図５】同実施例におけるＦＴＧによる推論形式を示す
図である。

【図６】同実施例におけるＦＡＥによる推論形式を示す
図である。

【図７】同実施例におけるＦＡＥによる知識表現を示す
図である。

【図８】同実施例における知識ブロックの最終構成を示
す図である。

Claims (4)

【特許請求の範囲】
1. 【請求項１】推論機構，知識ベース，データベース及び
   ユーザーインターフェイスを有する装置等の故障診断エ
   キスパートシステムであって、 前記知識ベースの構造は、前記装置等の正常動作した動
   作状態と未知の動作状態とを峻別する状態遷移ブロック
   手段と、異常状態から１又は２以上の異常部位の候補を
   挙げる部位解析ブロック手段と、候補に挙がった異常部
   位を確認して特定する部位確認ブロック手段とを有する
   ことを特徴とするエキスパートシステム。
2. 【請求項２】推論機構，知識ベース，データベース及び
   ユーザーインターフェイスを有する装置等の故障診断エ
   キスパートシステムであって、前記知識ベースの構造
   は、前記装置等の正常動作した動作状態と未知の動作状
   態とを峻別する状態遷移ブロック手段と、異常状態を解
   析する状態解析ブロック手段と、状態解析ブロック手段
   における異常状態から１又は２以上の異常部位の候補を
   挙げる部位解析ブロック手段とを有することを特徴とす
   るエキスパートシステム。
3. 【請求項３】請求項１又は請求項２において、前記状態
   遷移ブロック手段における異常に関する告知情報に基づ
   いて故障部位を提示するマニュアル知識ブロック手段を
   有することを特徴とするエキスパートシステム。
4. 【請求項４】請求項１又は請求項２において、前記状態
   遷移ブロック手段における異常に関する告知情報に基づ
   いて異常部位の候補を前記部位確認ブロック手段に送る
   マニュアル知識ブロック手段を有することを特徴とする
   エキスパートシステム。