JP2008090762A - 分散した部品木から故障部品の組み合わせを求める方法、システム - Google Patents

Abstract

【課題】製品全体の全部品データを検索することなく、確度の高い故障原因の部品を見つけること。
【解決手段】既知の故障製品の集合から分散した部品ツリー上の部品データに順にアクセスし、故障製品のなかで支持度の高い部品属性値を抽出する。この過程では、故障製品に使われている部品の部分集合も求める。これらの支持度の高い部品属性値、および故障製品に使われている部品集合は部品タイプをノードとするツリーとして表現する。次に、部品タイプのツリー上の支持度が高い２つの部品属性値に対して、その２つの部品属性値をとることが故障原因となるルールの情報利得を計算する。この計算は、２つの部品の共通の親部品に対して局所的に行い一定の情報利得があるものを故障原因として出力する。これらの２つの部品属性の選び方はツリー上の距離が近いものから評価し最初に見つかったものを故障原因の候補とする。
【選択図】図２

Description

本発明は、分散した部品木から故障部品の組み合わせを求める方法、システムに関する。更に詳しくは、分散した部品木と故障製品の集合から故障原因である部品特性の組み合わせを求める方法、システム、およびプログラムに関する。

自動車工業のような複雑な製品を大量に生産する製造業において、品質管理は重要な課題のひとつである。しかし、企業活動のグローバル化や巨大化により部品管理・品質管理に使われるデータベースが分散化し、グローバルで分野を超えた品質管理が困難になりつつある。

一方、製品自体の複雑化により、多大なコストを伴うリコールにつながるような製品のトラブルも増えている。そのようなコストを低減させるには、故障が顕在化する早期において故障原因を特定し必要な手段を実施することが必要である。

製造業において品質を管理する方法は、その開発や製造のプロセスとそれに関係するデータを管理するしくみに依存する。例えば、自動車業界では、設計時や生産時に部品表と呼ばれるデータを作成しそれらをプロセスの実行や品質問題の解決に利用している。ただし、設計時に使われる部品表（Ｅ−ＢＯＭ；Ｅｎｇｉｎｅｅｒｉｎｇ Ｂｉｌｌ Ｏｆ Ｍａｔｅｒｉａｌｓ）と、生産時に使われる部品表（Ｍ−ＢＯＭ；Ｍａｎｕｆａｃｔｕｒｉｎｇ ＢＯＭ）は、その目的が違うことから別々のものが使われることが普通である。同様に、同じ生産に関する部品表でも工場や部品サプライヤによってデータベースを別々に持ち互換性がないことが多い。

例えば、設計時の部品表は部品の設計データしかないので、故障の原因は特定の部品であるということ以上のことは言えない。これからリコールのような故障の影響範囲を調べると、その設計によって生産された製品すべてが該当することになる。リコールはコストがかかるので対象となる製品が絞れないとコストが高くなってしまう。

そこで、生産における部品データのようにあるロットの（あるいは固有の製造番号を持つ）製品はどのロットの部品を使うかという管理データがあると、例えば、特定のロットの部品のみが原因であるということができる。これは、その特定のロットのみを使った製品をリコール対象にすればいいので、設計時の部品表よりも品質管理方法としてはすぐれている。

ただし、前述したように工場が違ったり、部品サプライヤのデータはアクセスすることができなかったりするので、特定のサプライヤの部品ということまではわかってもロットなどの詳細はわからなくなる。そこで何らかの情報基盤を整備してこれらの分散した品質管理データに統一的にアクセスできるようにし、これらのデータを追跡できるようにして品質管理を行うことが考えられている。

このような個別製品レベル、部品ロットレベルの追跡は有効であるが、分散データソースに大量の部品データが存在するとすべてのデータにアクセスし追跡することは現実的ではない。特に、単一の部品が原因でなく複数の部品の組み合わせが原因の場合、既知の故障製品から追跡できる個々の部品のロット番号のみを集めても組み合わせが本当に問題かどうかを知ることは困難である。

一方、データマイニングや決定木を用いた故障診断システムの技術でも既知の故障製品とそのデータを与えて故障原因や故障するルールを導出することができる（例えば、特許文献１参照）。
特開２００５−１８２４６５号公報

しかしながら、上記のようなデータマイニングや決定木の技術もデータ（テーブル、トランザクションなど）へのアクセスは容易で自由に行えると仮定しており、データソースが分散していることから製品全体や部品全体へのアクセスが不可能であるという前提を置いた技術はない。

例えば、故障原因となる部品の属性値の組み合わせは、一般に与えられたデータセット（トランザクション）から共通のアイテム（故障製品に使われている部品の属性）を発見するデータマイニングの手法により発見することができる。ただし、一般的に使われる確信度などを用いた手法で故障原因を特定しようとすると、すべての部品とそのすべての属性を１テーブルにまとめてすべてアクセスする必要があり、しかも故障した製品のみならず正常な製品を含むような大量の製品を対象にデータを集める必要がある。なぜなら、データマイニングの手法でよく知られた確信度やリフトなどの値を計算するには故障していない大量の製品の部品データも取得する必要があるからである。これは、部品データが複数の工場や部品サプライヤに分散してあるような状況を考えると明らかに現実的ではない。決定木の構築に使われる情報利得の計算に関しても同様である。

図１は、製品と部品のデータソース間の関係を示したものである。ここで、生産された製品（図ではＰＤ）は、それを構成する部品は何かというデータを分散されたデータソース（ＤＳ）に持ち、製品番号を与えればそれを構成する部品とそのロット番号などの属性値（Ｌ）を検索することができるとする。ただし、異なるデータソース間のデータはその関係を定義して追跡することにより全データを得ることができる。関係は基本的に一方向で定義されている。

ここで、製品に品質上の問題が発生し故障が発生したとすると、故障がすべて顕在化するのではなく、一部の製品が既知の故障の製品であるとわかるだけである。例えば、故障製品として報告された製品の製造番号が与えられるだけである。このような品質問題のうち、特に異なるデータソース（例えば異なる部品サプライヤ）に属する複数の部品の組み合わせが故障原因であるかどうかを、既知の故障製品から分散した部品データベースに存在する部品属性データ（例えば各部品のロット番号など）を追跡することによって特定することが求められる。また、故障原因を特定することにより、まだ顕在化していない故障を予測し、例えば、製品のリコール対象を求めたりすることを可能にすることも課題である。

そこで本発明では、製品の品質を分散された部品木データで管理するシステムにおいて、異なるデータソース（例えば多様な部品サプライヤ）に属する複数の部品の組み合わせが故障原因であるかどうかを、既知の故障製品から部品木上にある部品属性データ（例えば各部品のロット番号など）を追跡することによって特定することを課題とする。特に、アクセスコストのかかる製品全体の全部品データを検索することなく、確度の高い故障原因を見つけることを目的とする。

本発明では、以下のような解決手段を提供する。

本発明の１つの形態では、
部品の属性値を保持する部品表データから故障原因の候補となる部品属性値の組み合わせを求める方法であって、故障製品の集合から支持度が所定の値よりも高い部品属性値を抽出するステップと、前記支持度が所定の値よりも高い部品属性値の組み合わせが故障原因であるとするルールの情報利得を計算するステップと、前記情報利得が所定の閾値より大きいものを選択するステップと、を含む方法を提供する。

また、前記支持度が所定の値よりも高い部品属性値を抽出するステップにおいて、各部品の故障製品に使われている部品の部分集合も合わせて求める。更に、前記情報利得を計算するステップにおいて、各部品情報が異なる場所に分散している場合に、２つの部品の共通の親部品の集合を、それぞれの属性値を持つ２つの部品から追跡して求め、故障製品に使われている共通の親部品の部分集合から、２つの部品属性値を持つことが故障原因とするルールの情報利得を部品表データの一部の部分木情報だけを使って計算することを、上記の方法に加えて提供する。

この方法は、下記のように表すこともできる。

既知の故障製品の集合（現在故障と報告された製品の集合）から分散した部品木上の部品データを順にアクセスし、故障製品の中で支持度（Ｓｕｐｐｏｒｔ）の高いアイテム（故障製品に高頻度に共通に現れる部品属性値）を抽出する。この過程では、それぞれの部品において、故障製品に使われている部品の部分集合も同時に求める。これらの支持度の高い部品属性値、および、故障製品に使われている部品集合は部品タイプをノードとする木として表現される。なお、部品属性値は単一の値のみならず、連続した値の離散値集合や連結した値域もひとつの値として扱う。

更に、部品タイプの部品木上の支持度が高い２つの部品属性値に対して、その２つの部品属性値をとることが故障原因となるルールの情報利得（Ｉｎｆｏｒｍａｔｉｏｎ Ｇａｉｎ）を計算する。この計算は、製品全体の全部品データを追跡して計算するのではなく、２つの部品の共通の親部品に対して局所的に行い一定の情報利得があるものを故障原因として出力する。また、これらの２つの部品属性の選び方は部品木上の距離が近いものから評価し最初に見つかったものを故障原因の候補とする。

本発明では、例えば、故障している製品のデータベースがありその１レコードが１台の製品に対応しいろいろな部品に関する属性を持っているとしたとき、属性とその値が与えられたとき、全レコード数に対してその属性値を持つレコード数の割合を、その属性値をとることによって製品が故障していることの「支持度」と呼ぶ。また、「情報利得」とは、製品のある属性値が、製品が故障することと統計的に相関があることの度合い、を意味する。なお、「支持度」、「情報利得」の一般的定義については、データマイニングの専門書を参照されたい。

上記の方法は、各ステップの機能をコンピュータに実行させるプログラム、またはそのブログラムを実装した情報処理システムで実施され得る。

本発明によれば、通常のデータマイニングの手法や部品追跡では、パフォーマンス的に困難なデータソースに分散した複数の部品の組み合わせを、故障原因として発見することができる。このとき、すべてのデータや部品を追跡することなく比較的容易にアクセスできる局所的な部品データだけから、情報利得の高い組み合わせを計算することができる。この結果、品質問題が発生した場合のリコール処理で対象製品を必要最小限に絞ることが可能になったり、根本原因分析を容易にしたり、あるいは、品質問題を事前に予測し、製品品質の向上や開発・保守コストの削減につなげたりすることができる。

以下、本発明の実施形態について、図や数式を参照しながら説明する。

製品で使われる部品とその属性をすべて求めるのは、データソースが分散しているため困難である。しかし、ある１つの部品に関するデータは１つのデータソース内にあるので比較的容易に大量の部品データにアクセスすることができる。また、部品全体でなければ一部の部品を局所的に追跡することも容易である。この追跡は、製品や親となる部品からそれに使われる（子供の）部品を調べることもできるし、その逆に特定の属性値（ロット番号）を持つ部品の親部品（製品）をすべて求める、というような追跡もできるとする。

以下、この問題をより具体的に説明する。

ここで、Ａを生産された製品の全体集合としたとき、Ａの要素（ＰＤｐと表す。詳しくは後述の［アルゴリズムや問題定義に使われる記号の定義］を参照）の個数（例えば１００万台生産された製品）に比べて十分小さなサイズ（例えば、１００台）の故障が判明した製品の集合Ｆが与えられたとする。この各故障製品ＰＤｐから部品木に従って部品ｐＰ_ｉｊを追跡することができる。ここでｉは部品木の何層目か（０層目が製品そのもの）、ｊは同じ層で何番目の部品かを表す。また、製品ＰＤｐ、または部品ｐＰ_{（ｉ−１）ｊ}に部品ｐＰ_ｉｊが組みつけられていることをＰＤｐ→ｐＰ_ｉｊ，ｐＰ_{（ｉ−１）ｊ}→ｐＰ_ｉｊと表すこととする。更に、各部品にはロット番号などの属性がついており、この属性値はＬｔ（ｐＰ_ｉｊ）で表すとする。ひとつの部品に複数の属性値が定義されていてもよい。

本発明の目的は、製品ＰＤｐに組みつけられている２つの部品の属性が、それぞれある値を同時にとるときＰＤｐが故障するというルールを求めることである。このルールの情報利得（Ｉｎｆｏｒｍａｔｉｏｎ Ｇａｉｎ）ＩＧ（）が十分に高いことが条件である。情報利得ＩＧ（）は、ルールを適用する前後の、製品が故障するか故障しないかのエントロピーの減少度合いから計算される。エントロピーは故障する確率をｐで表すと、−ｐｌｏｇ（ｐ）−（１−ｐ）ｌｏｇ（１−ｐ）から計算できることがよく知られている。情報利得が十分に高いかどうかは適当なエントロピーの差分の閾値を定めることで決めることができる。この閾値は製品のシステムエンジニアリング情報や品質に関する統計情報から決めることもできるし、本アルゴリズムを実行しながら経験的に決めることもできる。

図２は、本発明の１つの実施形態である情報処理システムの構成の一例を示したものである。このシステムでは、製品製造工場システム１０、１次サプライヤシステム（２０、３０）、２次サプライヤシステム４０がネットワーク５０を介して接続されている。図では簡略化のために２次サプライヤまでしか示していないが、３次サプライヤ、４次サプライヤなどより多くのサプライヤシステムを含むことができる。以下、これらの各システムを、データソースとも呼ぶことにする。

各データソースは、制御部としての、ＣＰＵ（１１ａ、２１ａ、３１ａ、４１ａ）、記憶部（１１ｂ、２１ｂ、３１ｂ、４１ｂ；メモリ、ハード・ディスク上のデータベースも含む）、ネットワーク・コントローラ（１１ｃ、２１ｃ、３１ｃ、４１ｃ）などから構成され、このようなデータソースはインターネットなどのネットワーク５０で結ばれている。ネットワーク５０はデータソース間で同一のネットワークでも異なるものでもよい。ネットワーク・コントローラ（１１ｃ、２１ｃ、３１ｃ、４１ｃ）は、同一のネットワークに対しては共通にできるので１つであってもよいし、異なるネットワークが３つ以上接続されていれば３つ以上存在してもよい。各データベースには部品データ（小円）の一部が格納されており、部品の構成が木構造（ツリー構造）で表されている。木の親子関係は破線矢印で表されている。データソースのルートの部品はその親の部品を管理するデータソースの葉ノードに仮想ノード（破線の小円）として表される。葉ノードと仮想ノードは異なるデータソースに配置されるが、論理的に同じ関係があり破線の矢印で結ばれている。各ＣＰＵは同じデータソース内のメモリとデータベースに低コストで自由にアクセスし処理をすることができるが、別のデータソースにアクセスする場合は、ネットワーク上の通信を必要とし、処理するデータ量に制限がありアクセス時間が比較的かかるなどの問題がある。なお、実線の矢印は処理を進める際のデータへのアクセスや制御の呼び出しを表す。

製品をルート（Ｒｏｏｔ）とするデータソース１０はユーザ・インターフェース・コントローラ１２も持ち、まず、はじめに品質問題を起こした製品のリストを入力として受け取る。ＣＰＵ１１ａは、後で述べるアルゴリズムを実行するが、自分のメモリ外の部品データを処理する必要がある場合は、ネットワーク５０を通じて処理依頼内容や部品ＩＤなどの必要な情報を送信して、その部品データがあるデータソースのＣＰＵに処理を依頼する。処理が終わると処理結果を依頼されたＣＰＵから依頼元のＣＰＵに返信され、依頼元のＣＰＵは処理を継続する。製品のデータソース１０は、すべての処理が完了するとユーザ・インターフェース・コントローラ１２を介して処理結果をユーザに通知し処理を終える。

［システムレベルの処理手順］
図２におけるシステムレベルの処理手順について説明する。生産された製品はすべてどのような部品から組みつけられているかという生産の履歴が保存されている。論理的には、図中の破線で示したようにある製品や部品に組みつけられている部品を木構造で表現し、部品を表す各ノードには、その部品が持つ製造上の特徴、すなわち、ロット番号、製造手段、場所、時間、作業者などの属性値を保存している。物理的には１つのデータベースにすべての部品の情報が保存されているのではなく、その部品を製造する工場やサプライヤが保存している。別のサプライヤの部品を検索（追跡）する場合は、自分のハード・ディスクの対応する箇所にそのサプライヤのネットワーク情報（ネットワーク上のアドレス）や部品ＩＤが記録されているので、それを読み出し、ネットワークを通じて該当するサプライヤに情報取得を要求する。要求を受け取ったサプライヤは部品ＩＤを基に該当する情報を自分のハード・ディスクから読み出し、結果をネットワーク上の通信により元の製品製造工場（ＯＥＭ）や上位部品サプライヤに返す。論理的な木を複数のノードにまたがって追跡する場合も同様にこのような手順を繰り返すことによって情報取得を行う。更には、木のルート（すなわち製品）に向かってトレースすることもできる。これは、同様なネットワーク情報や部品ＩＤが親のノード（部品）に対しても格納されていれば同様な手順で可能である。

以下では、このシステム上の要素を用いて手順を説明する。このシステムでは、機能上、（１）部品属性値抽出部、（２）情報利得計算部、（３）情報利得選択部の３つに分けて説明する。

（１）＜部品属性値抽出部＞
故障した製品ＩＤの集合をもらって、それぞれの故障製品に使われている部品を上記のシステム上で追跡し、部品の属性値で頻出するものを求める。詳細は以下の（ア）〜（ウ）のとおりである。

（ア）製品製造工場システム１０に、故障製品ＩＤの集合が入力として渡される。製品製造工場システム１０では、自分のハード・ディスクに、各ＩＤの製品がどの部品から組み立てられたかという情報を持っているが、部品自体の属性情報はないので、上記のシステム説明で書いたようにネットワーク通信で、それぞれの部品の１次サプライヤシステム２０、３０にその部品ＩＤの集合をパラメータとして計算要求を出す。

（イ）計算要求を受け取った１次サプライヤシステム２０では、故障製品に使われた部品ＩＤの集合を受け取って、それらの部品の属性値で頻出するものがないかを計算する。これは、ハード・ディスクに保存されている部品データベースから部品ＩＤで検索し、各属性値をカウントすることによって支持度を求めることで計算できる。あらかじめ決められた閾値より大きい支持度を持つ部品とその属性値を、製品製造工場システム１０に返信する。製品製造工場システム１０は受け取った部品とその属性値を頻出する部品属性として記録する。

（ウ）サプライヤの部品を生産する上で、更に下位の２次サプライヤシステム４０の部品を使っている場合は、（ア）と同様にして更に２次サプライヤシステム４０に下位部品のＩＤ集合をパラメータとして計算要求を出す。２次サプライヤシステム４０は、（イ）と同様に頻出する部品属性値を計算し答えを製品製造工場システム１０に通知する。すべての部品を調べ終わるまでこれを繰り返す。

（２）＜情報利得計算部＞
上記（１）で求めた頻出する属性値を持つ部品の任意の２つの組み合わせについて、その組み合わせにより故障するというルールが統計的に意味があるかどうかの情報利得を計算する。情報利得が高いものを選ぶと、故障原因と思われる２つの部品属性の組み合わせが求まる。詳細は以下の（ア）から（エ）のとおりである。

（ア）ある２つの部品の組み合わせを考える。それらの部品を共通に組みつけている共通部品を求める。このような部品の組み付け関係の情報は製品製造工場で把握しており検索することができる。

（イ）その共通部品のサプライヤに対して２つの部品の種類とそれぞれの頻出する属性値をパラメータとして計算要求をネットワーク通信で送る。

（ウ）共通部品のサプライヤでは（イ）の計算要求を受け取り、その２つの属性値を持つ２つの部品を両方とも使う共通部品のＩＤの集合を計算する。その計算方法は以下の方法のうち何れかで、頻出する属性値を持つそれぞれの部品を使っている集合を求めて、その積を計算することによって行う。

（ｉ）受け取った部品が何れも直接共通部品に組みつけられているものなら、それらの属性値を検索して直接該当する共通部品ＩＤの集合を計算することができる。このとき、必要な属性を下位のサプライヤに問い合わせる必要があれば、ネットワークを通じて検索条件（頻出する属性値を持つこと）を送信して、下位サプライヤで該当検索を行い、結果を返信してもらうことにより行う。

（ｉｉ）もし、受け取った部品の両方、あるいは、片方が直接組み付けている部品でない場合は、その部品から共通部品までの逆トレースを行う必要がある。まず、その部品を製造し属性情報を保持しているサプライヤを探す。これは、製品製造工場システム１０に問い合わせてもよいし、下位サプライヤシステムに対して順々に問い合わせていってもよい。次に、そのサプライヤシステムに対し頻出する属性値を渡して処理の開始を要求する通信を行う。サプライヤシステムでは要求を受け取りその属性値を持つ部品ＩＤの集合を計算する。次に集合の各要素毎に共通部品までの逆トレースをする。

（エ）共通部品のサプライヤでは、頻出する部品を両方とも使った共通部品のＩＤ集合と、上記（１）で既に求めてある故障した製品に使われている共通の部品の集合から、情報利得を求めることができる。これは、共通部品全体の中で故障しているというエントロピーと、頻出する属性値をもつ部品を使っている共通部品の中で故障しているというエントロピー（これは前記２つの集合の積で求めることができる）の差を求めることで計算できる。エントロピーの計算方法は、通常の情報量の定義で与えられているとおりである。

（３）＜情報利得選択部＞
（オ）上記（２）の（エ）で計算した情報利得があらかじめ決められた閾値より大きければ、その２つの属性値を持つ部品が故障原因の可能性があるということで、製品製造工場システム１０に結果を返信する。
（カ）そして、製品製造工場システム１０は、上記（２）の（ア）（イ）および（オ）の受信を、すべての組み合わせについて繰り返し、受け取った答えをまとめて故障原因の可能性のある２つの部品とその属性値の組み合わせを得ることができる。

［アルゴリズムや問題定義に使われる記号の定義］
以下に、各ＣＰＵで連携して処理されるアルゴリズムの更に詳細を説明する。本明細書と図面で用いる記号は、次のように定義する。この定義中で、下線付きの文字は集合を表すものとする。

ＰＤ_ｓ≡ シリアル番号ｓを持つ製品

Ａ≡ すべての製品の集合

Ｆ≡ 故障した製品の集合。本発明では与えられるものとする。

ｐＰ_ｉｊ≡ 製品ＰＤ_ｐに組みつけられているｉ番目の層のｊ番目の部品。特に、ｐＰ_０ｊはＰＤ_ｐと同じである。

ｐＰ_ｉｊ→ｐＰ_{（ｉ＋１）ｋ}≡ 部品木においてｐＰ_{（ｉ＋１）ｋ}はｐＰ_ｉｊのｋ番目の子供。特にプロダクトＰＤ_ｐに組みつけられている部品はＰＤ_ｐ→＊→ｐＰ_ｉｊと書く。

Ｌ_ｔ（ｐＰ_ｉｊ）≡ 部品ｐＰ_ｉｊの属性ｔの値

ＦＩＳ _ｓ ≡ 頻出アイテム集合（Ｆｒｅｑｕｅｎｔ Ｉｔｅｍ Ｓｅｔ））｛Ｌ_ｔ（）＝Ｌ，Ｌ_ｕ（）＝Ｍ，．．｝。製品の部分集合Ｓにおける故障製品に頻出する属性（Ｌ_ｔ（）、Ｌ_ｕ（）など）とその値の集合。ここで、Ｌ，Ｍなどはその属性値で、単一の値のみならず連続値の集合や離散値の集合も含む。この後のアルゴリズムでは、ＦＩＳは木で表現されＬ_ｔ＝Ｌなどの部品属性とその値はノードに付加される。

ｓｕｐ_ｓ（Ｌ_ｔ（）＝Ｔ）≡ ｜｛ＰＤ_ｐ ∈Ｓ｜∃ｉ∃ｊ（Ｌ_ｔ（ｐＰ_ｉｊ）∈Ｔ）｝｜／｜Ｓ｜。ただし、ＴはＬ_ｔ（）の値域でかつＳ⊂Ａ

Ｐ _ｉｊ≡ 部品Ｐ_ｉｊの集合

Ｐ _ｉｊ｜Ｃ≡ 条件Ｃを満たす部品Ｐ_ｉｊの集合

Ｐ _ｉｊ｜Ｆ ≡ 故障製品の集合Ｆに組みつけられている部品Ｐ_ｉｊの集合。特にＰ _０１｜Ｆ ＝Ｆ

Ｈ（Ｆ，Ｓ）≡ 製品部分集合Ｓにおいて故障しているエントロピー

Ｈ（Ｆ，Ｐ _{ｒｑ”｜Ｌｔ（）＝Ｌ∧Ｌｕ（）＝Ｍ”}）＝−ｐｌｏｇ（ｐ）−（１−ｐ）ｌｏｇ（１−ｐ）。ただし、ｐ＝｜｛Ｐ_ｒｑ｜Ｐ_ｒｑ→＊→Ｐ_ｉｊかつＬ_ｔ（Ｐ_ｉｊ）＝Ｌ∧Ｐ_ｒｑ→＊→Ｐ_ｋｌ∧Ｌ_ｕ（Ｐ_ｋｌ）＝Ｍ｝∩｛Ｐ_ｒｑ｜ＰＤｐ∈Ｆ ∧ ＰＤｐ→＊→ｐＰ_ｒｑ｝｜／｜｛Ｐ_ｒｑ｜Ｐ_ｒｑ→＊→Ｐ_ｉｊ∧Ｌ_ｔ（Ｐ_ｉｊ）＝Ｌ∧Ｐ_ｒｑ→＊→Ｐ_ｋｌ∧Ｌ_ｕ（Ｐ_ｋｌ）＝Ｍ｝｜。

Ｈ（Ｆ，Ｐ _ｒｑ）＝−ｑｌｏｇ（ｑ）−（１−ｑ）ｌｏｇ（１−ｑ）。ただし、ｑ＝｜｛Ｐ_ｒｑ｜ＰＤｐ∈Ｆ ∧ ＰＤｐ→＊→ｐＰ_ｒｑ｝｜／｜Ｐ _ｒｑ｜

ＩＧ（Ｆ，Ｓ１→Ｓ２）≡ 情報利得；Ｈ（Ｆ，Ｓ１）−Ｈ（Ｆ，Ｓ２）
ＩＧ（Ｆ，Ｐ _ｒｑ→Ｐ _{ｒｑ｜”Ｌｔ（）＝Ｌ∧Ｌｕ（）＝Ｍ”}）＝Ｈ（Ｆ，Ｐ _ｒｑ）−Ｈ（Ｆ，Ｐ _{ｒｑ”Ｌｔ（）＝Ｌ∧Ｌｕ（）＝Ｍ”}）

［アルゴリズムの説明］
本発明では、大きく２つのステップで課題を解決する。以下に、その基本アルゴリズムを示す。

第１のステップ（ＦＩＳ（Ｆｒｅｑｕｅｎｔ Ｉｔｅｍ Ｓｅｔ） ｂｕｉｌｄｉｎｇ ｓｔｅｐ；ＦＩＳ導出ステップと呼ぶ）では、故障製品の限られた集合（初期に故障と報告された製品の集合）のみから分散した部品データを部品木に従って順にアクセスし、故障製品の中で支持度の高いアイテム（故障に共通に現れる部品属性値）をはじめに抽出する。この過程では、各故障製品から使われている部品を追跡し、故障製品に使われている部品集合も同時に求める。これらの支持度の高い部品属性、および、故障製品に使われている部品集合は部品木として表現される。この部分木をＦＩＳと表す。

第２のステップでは、２つの部品属性値を選びその値を両方ともとるときに故障するというルールの情報利得をＦＩＳから計算する（ｒｕｌｅｓ ｄｅｒｉｖａｔｉｏｎ ｓｔｅｐ；ルール導出ステップと呼ぶ）。このとき、製品全体のデータを追跡するのではなく、２つの部品の共通の親部品を求め、その部品で故障した製品に使われている部品集合、２つの部品属性値を取る部品を使っている部品集合、部品の全体集合を求めて、これらからルール適用前後のエントロピーを計算しその差分から情報利得を計算する。

第１のステップ（ＦＩＳ導出ステップ）の基本アルゴリズムの詳細は以下のとおりである。まず、結果となる故障原因部品木ＦＩＳを初期化する（ＦＩＳは集合と考えて空集合とする）（１）。次に、製品の部品木をルート（製品そのもの）から順に辿っていく（２，３）。まずＦＩＳに対応するノードを加える（４）。与えられた故障製品の集合（Ｆ）から辿られる対応部品の集合（Ｐ _ｉｊ｜Ｆ ）を求め、ＦＩＳに添付する。実際には、木のルートから順にＰ _ｉｊ｜Ｆ を求めているので、ひとつ上の親ノードにある集合の部品から１レベル追跡するだけでＰ _ｉｊ｜Ｆ を求めることができる（５）。ここで、部品Ｐ_ｉｊにロット番号などの部品属性値がなければ次の部品に処理を移す。もし、属性があればそれを部品から属性値への関数と考えてＬ（）で表す（６）。ここで連結した属性値を作成して返す副手続きｇｅｔＨｉｇｈＳｕｐｐｏｒｔＡｔｔｒｉｂｕｔｅＳｅｔ（）を使って、故障した製品（Ｆ）における支持度（故障した製品の属性がその値になっている割合）が高いものを選択し、ＦＩＳのノードに添付する（７）。

図３は、自動車の部品（エンジン、シリンダ、ピストン）を例にとって、第１のステップを模式的に表したものである。符合６０が報告された故障車の集合（ここでは、簡単化して車１と車２の２台しかない）、符号７０、８０、９０が、各部品のＰ _ｉｊ｜Ｆ 、ロット１やロットＡなどが支持度の高い部品属性値（それぞれ、シリンダとピストンのロット番号である）である。こうして求めた故障部品の集合や支持度の高い属性は故障原因部品木１０６に添付していき、すべての部品を調べ終わったら、第１のステップは終了する。できあがった故障原因部品木１０６が第１のステップのアウトプットである。

より具体的に説明すると、エンジンサプライヤ２０は、車メーカ１０から故障車に使われているエンジン１とエンジン２という情報をもらう。それぞれのエンジンに２つのシリンダが使われているが、ロット１は４つのシリンダのうち３つも使われているので支持度は０．７５と高いので候補に入れるが、ロット２の支持度は０．２５なので候補に入れない。同様に、ピストンサプライヤ３０では、故障車に使われているシリンダがシリンダ１１、１２、２１、２２であるという情報を上位のエンジンサプライヤ２０からもらい、これらのシリンダのうちロットＡのピストンの支持度が０．５であるので候補に入れるが、ロットＢ、ロットＣの支持度は０．２５で低いので候補に入れない。エンジンサプライヤ２０は、故障車によく現れる部品の特性としてロット１のシリンダを求めたので、その情報を車メーカ１０に送信する。ピストンサプライヤも同様にロットＡのピストンがよく使われていることを車メーカ１０に送信する。

［副手続き ｇｅｔＨｉｇｈＳｕｐｐｏｒｔＡｔｔｒｉｂｕｔｅＳｅｔ（）］
故障製品に使われている部品集合（Ｐ _ｉｊ｜Ｆ ）、その属性（Ｌ）、および、最小支持度（ｍｉｎ−ｓｕｐ）を与えて、その集合に含まれる部品の属性値で最小支持度以上の支持度を持つ属性値の集合を返す。ただし、属性値の連結集合（連続したロット番号の集合など）が条件を満たす場合はそのような連結集合も値のひとつに入れる。

結果となるべき集合Ｖを初期化し（１）、故障した製品が持つ部品の属性値の集合をＴとする（２）。Ｔの部分集合について小さいものから順に以下の処理をする（３）。まず、Ｔの部分集合で連結していないものを除く（４）。このとき、経験ルールなどを用いて、更に属性値として無意味な部分集合も除く。残った部分集合を属性値とみなしてその支持度（集合の場合は、元を含むものをアイテムとして数える）を計算する。支持度は故障製品の集合Ｆのうち、その属性値を取る部品を１個でも含む製品の個数の割合である。もし、支持度が与えられたｍｉｎ−ｓｕｐ以上であれば、その属性値をＶに加える（５）。すべての連結集合について調べ終わったら、Ｖを返す（６）。

図４は、自動車のシリンダ部品を例にしたｇｅｔＨｉｇｈＳｕｐｐｏｒｔＡｔｔｒｉｂｕｔｅＳｅｔ（）の動作の模式図である。ここで、図中のｓｕｐ（Ｌｏｔ１）はＬｏｔ１の支持度を表す。この図では、シリンダのロット番号としてＬｏｔ１、Ｌｏｔ２、Ｌｏｔ３などがあるが、ここでｍｉｎ−ｓｕｐ＝１を満たすのは、Ｌｏｔ１、｛Ｌｏｔ２，Ｌｏｔ３｝であることを示している。ただし、Ｌｏｔ２，Ｌｏｔ３は連続値である。

なお、第１のステップのメインからｇｅｔＨｉｇｈＳｕｐｐｏｒｔＡｔｔｒｉｂｕｔｅＳｅｔ（）を呼ぶ際に指定するｍｉｎ−ｓｕｐは、その部品の予測されている故障率（ε＜＜１）から計算できる。すなわち、故障率のぶんだけその属性値をとらないものがあると仮定している（１−ε）。

第２のステップであるルール導出ステップ（Ｒｕｌｅ Ｄｅｒｉｖａｔｉｏｎ ステップ）］の詳細を以下に説明する。
まず、２つの部品の共通の最小親ノード（共通の親ノードで２つの部品から最も近いノード）を求める。次に、２つの部品属性値を持つ部品集合をそれぞれの部品で求め、これらの２つの部品を両方とも使っているような共通の最小親ノードの部品集合を追跡によって求める。共通の最小親ノードの部品上で、ここで求めた２つの部品を両方とも使っている部品集合と第１のステップで求めてある故障製品に使われている部品集合の積から、この２つの属性値を同時にとることによって製品が故障するというエントロピーを計算する。更に、共通の最小親ノードの部品総集合と第１のステップで求めてある故障製品に使われている部品集合からルール適用前のエントロピーを求めることができる。これらのエントロピーの差から情報利得を計算することができる。情報利得が一定の値より高いものを故障原因の候補として出力する。

（１）本発明の結果となるｒｅｓｕｌｔ ｒｕｌｅ ｓｅｔ（Ｏ）を空集合に初期化しておく。次の（２）以降で結果の条件を満たすルール（故障を起こすような複数部品のロット番号などの組み合わせ）が追加されていく。

（２）ＦＩＳ導出ステップで求めた故障原因木上の与えられた最小支持度を満たす部品の属性値のすべての組み合わせを次の（３）以降で検査をするループの開始である。（３）以降で部品Ａと部品Ｂという部品のＬ、Ｍというロット番号に着目するとする。

（３）現在見ている２つの部品Ａと部品Ｂを組みつけている共通の部品で最小のもの（部品木上の距離が最も近いもの）を求める。これは、Ｅ−ＢＯＭ（デザインレベルの部品表）と呼ばれる製品管理システムでよく使われるデータベースを用いることによって求めることができる。この共通部品をＣとする。
（４）部品Ｃ上のデータで、ＦＩＳ導出ステップで既に求めてある故障製品に使われた部品やロットＬ、ロットＭを使用している部品の集合から、部品Ａと部品Ｂのロット番号がそれぞれＬ、Ｍのときに故障しているという情報利得を計算する。

この情報利得の計算を更に詳しく説明する。部品Ｃの部品総数と故障製品に使われている部品Ｃの部品数（この集合はＦＩＳ導出ステップで既に求めて故障原因木に添付しておいた）がわかるので、部品Ｃの部品上で、製品が故障しているかどうかのエントロピーは、以下の式で表される。

Ｐ＝（故障製品に使われている部品Ｃの部品数）／（部品Ｃの総部品数）
とすると、−ＰｌｏｇＰ−（１−Ｐ）ｌｏｇ（１−Ｐ）で計算できる。これは情報量のエントロピーの計算方法としてよく知られている。

次に、情報利得を計算するために、部品Ｃに部品Ａのロット番号Ｌと部品Ｂのロット番号Ｍの部品が両方とも組みつけられている部品Ｃの部品を追跡によって求め、その部品集合内で同様なエントロピーを計算する。すなわち、

Ｑ＝（部品ＡのロットＬと部品ＢのロットＭを両方使っている部品Ｃの部品で故障製品にも使われている数）／（部品ＡのロットＬと部品ＢのロットＭを両方使っている部品Ｃの部品数）
とすると、同様に−１−Ｑ）ｌｏｇ（１−Ｑ）−ＱｌｏｇＱで計算できる。これらのエントロピーの差をとったものが情報利得である。これは、部品Ａと部品Ｂのロット番号の組み合わせが製品が故障していることにどのくらい寄与しているかを表す。

（５）この情報利得が決められた値より大きければ、部品Ａと部品Ｂのロット番号Ｌ、Ｍを結果の集合に加える。

（６）次の組み合わせのループに移る。

（７）結果の集合を検査し、（５）で使う情報利得の閾値を調整する。すなわち結果が不足すれば閾値を減少させ、結果が多すぎれば閾値を増やして、（１）以下を繰り返す。

図５は、部品木の一部分だけを使った情報利得の計算方法を例で説明するための図である。（２）以下で考える部品は部品Ａと部品Ｂのロット番号ロットＡ、ロットＢの集合１３１，１３２とする。なお、参考に、ＦＩＳ導出ステップで求めた故障製品に使われているロットＡ、ロットＢの集合を１２２，１２３の線で示している。１３１，１３２の集合に対する１２２，１２３の集合の割合がそれぞれの支持度で、これが最小支持度以上である条件を満たしている。

ここで、部品Ａと部品Ｂを共通に組みつけている部品Ｃを見つける（図５の中央の集合１３０）。このような部品は部品Ｃよりも上のレベルの部品ですべて当てはまるが、そのような最小の部品（部品木上で部品Ａと部品Ｂに最も近いもの）を選ぶとする。

次に、部品Ｃの部品で、部品ＡのロットＡの部品と部品ＢのロットＢの部品を使っているものを部品トレース機能で求める。図５では、矢印で組み付け関係を示している。この矢印を逆に辿る。一般的にはこのようなトレースはコストがかかるが、部品Ｃと部品Ａ、部品Ｂは部品木上で近いので、リモートなアクセスが必要としてもコストは相対的に小さい。中央の符号１３１で示す集合が求めた部品Ｃの部品集合（Ｃａｆとラベルをつけてある）である。なお、ＦＩＳ導出ステップで、部品Ｃの故障製品に使われている部品集合（Ｃｆ）は既に求められている。

ここで、部品Ｃの部品全体、Ｃｆ部分集合１２１、Ｃａｂ部分集合１３０をから、目的とする情報利得を計算することができる。なお、正しい計算は部品追跡機能を使って製品の集合（図５の左端）で同様な計算をする必要があるが、本願発明の課題で述べたように、製品までの部品追跡はデータソースが分散しているためにこれは困難である。従って、本発明では、アクセスコストが比較的低コストの近隣データソースからだけで部品Ａ、部品Ｂ、部品Ｃの部品追跡を行い、情報利得を計算することができる。

［実施例１］
図６は、自動車生産会社における、故障発見、解析、原因特定、リコール対象プロセスの実装例である。

図６のプロセス１では、修理工場や生産現場などから品質に問題がある事例（正常に動作しない、異音がするなど）が報告される。プロセス２では、そのような報告からテキストマイニングなどの手法を用いて特定の原因と思われる事例から故障車の既知集合を求める。本発明の故障製品集合Ｆには、明らかに２つ以上の独立した故障原因が混じっていないことが仮定できる。プロセス３が本発明による故障原因となる部品属性の組み合わせを求めるプロセスである。

より具体的には、プロセス３では、図７で示すようなＧＵＩを用いて品質技術者が操作を行う。まず画面上の“ｃａｒＶＩＥＷ”ノードをクリックし、プロセス２で求めた故障車の集合（具体的には製造番号）を入力する。自動車の部品が部品木上に表示されているので技術者の経験や知識から怪しい部品のノードをクリックし、その部品の属性を表示したり、その支持度をグラフ表示したりする。もし、故障した製品に使われている部品の属性値の支持度が高い場合は、属性をクリックしてマークをつける。これを他の部品でも繰り返し、その後、本発明の第２のステップを実行し、情報利得の高い部品の組み合わせを自動的に画面に表示する。このとき、情報利得をグラフ表示し、最も疑わしい組み合わせを故障原因として決定する。もし、組み合わせで疑わしいものがない場合は、今度は単一の部品で同じことを繰り返し疑わしい単一部品を決定する。このとき、情報利得などの視覚化情報や技術者の経験、知識を用いてより的確な故障原因を特定することができる（プロセス４）。

プロセス５では、プロセス４の結果を用いて、部品表などの品質管理データを用いて故障する可能性がある自動車を決定する。プロセス６で、必要最低限の車両のみを対象にして回収・修理などのリコールのプロセスを実行する。

［実施例２］
実施例１と同様なプロセス（１〜４）により故障原因となる部品の組み合わせを発見することができる。このような情報から、製品開発のエンジニアが根本原因分析を実行することにより、より容易にエンジニアリング上の根本問題（例えば、２つの部品のエンジニアリング・パラメータ（寸法、出力など）の不一致など）を特定し、必要な対応（再設計、生産方法の変更など）を迅速に行うことができる。

更には、このような解析が、新たな品質問題の発生を事前に予測し適切な事前対応を行うことにより製品開発のコストを抑えることを可能にする。

［本発明で適用可能かつ効果が期待できる対象データの性質］

（１）故障原因に対して故障製品が統計的に意味を持つぐらいの限定的な数の故障製品を生じさせる場合（これは、ひとつの原因で故障製品がたった１つしかない場合（例えば故障原因となるあるロットの部品から１台の製品しかできない場合）や、製造された製品がすべて故障する可能性がある場合（例えば設計上の問題）は本発明が適用できないことを示す）。

（２）更に、これらの原因（となる部品）が自明でなく、かつ、故障製品の実機を取り寄せて物理的な解析が困難な場合。例えば、ユーザからの回収がユーザの協力が得られなくて困難、物理的に巨大で移動が困難、エンジニアを派遣したり現地での解析が困難、故障製品そのものが滅失、など。

（３）部品ごとの生産履歴データが分散している。それらの追跡に手間がかかる。

（４）故障の症状などのデータ処理を通して、故障の原因は１つと仮定できる。すなわち、２つ以上の独立した原因が混在した故障製品の集合を与えられることはない。例えば、「エンジンから異音がする」、「ワイパーが動かない」、「ドアが開かない」、などの症状を分析し特定の症状のものだけに絞ることにより可能である（１００％１つに絞れるわけではないが）。

（５）ここで対象にしたい各部品の属性（ロット番号など）は、互いに異なる部品の属性値の間に相関がない。もし、そうでないとすると、例えば、４月に生産された製品の全部品が単一のロット番号をそれぞれとるとすると、４月に生産された製品に故障が発生しても本発明で答えを出すことができない。すべての部品のロット番号の支持度は単一の値をとるため高くなり、それぞれの情報利得もすべて同じになるからである。すべての部品のロット番号が一様に同じ値をとっているのは不自然なので、この仮定は十分に現実的である。

（６）故障している製品に頻出する属性値を持つ部品のＩＤから製品へ逆トレースするコストが高く、かつ、トレースの精度も悪い。

（ア）一般に部品表は組み付け作業にも使われるものなので、どの部品にどのサブ部品を組みつけたかという詳細情報を含む。多くの場合、１対１のマッピングが実現されておりインデックス、ポインタも完備しているので、順方向のトレースは容易にかつ精度を高く行える。ところが、逆方向に関しては、ある部品がどこに使われたかという情報が必要であるが、このような情報は逆ポインタのような形でダイレクトにデータベースに格納されていることはなく、データベースの検索（インデックスやポインタに比べるとコストがかかる）が必要である。特に、下位サプライヤの部品が上位サプライヤの部品のどれに使われているかは、下位サプライヤではわからず上位サプライヤにネットワークを通じて同様な検索を依頼する必要があり、更に通信コストが上乗せされる。

（イ）更に、逆トレースでは、データ保持の管理性、経済性などの観点から、１対１のマッピングになっていないことも多い。例えば、このロット部品はこのロットとこのロットのサブ部品を組みつけているというように、部品単体で見ると多対多の関係でしか追跡できないことがある。この場合、コストがかかるだけでなく、逆トレースした結果の精度（この部品を使っている製品を求めたいのに、実際には使っていない製品まで含まれてしまう、など）が悪くなる。これには膨れ上がることによる計算量の増大に加えて、計算結果の精度も悪くなるというデメリットがある。

［本発明の適用可能な問題とその部品属性の具体例］
（１）製造上の問題、あるいは、サプライヤロットの差異に起因する故障原因の発見
例：製造上のばらつきが原因で、たまたま２つの部品の組み合わせで発生するような故障。例えば、エンジンのピストンとシリンダ部品の直径サイズの不適合により予想外の磨耗が生じ、エンジンの異常振動となる。ピストンとシリンダの直径はサプライヤ（複数ある場合）、ロット番号、加工作業者、製造機械などによって決まる。特に、ロット番号は他の属性と相関する値を付与することが多いので、ロット番号を属性として本発明を適用することにより、ピストンとシリンダの特定の組み合わせで問題を起こすことがわかる。

（２）２つの部品の組み合わせのうち片方あるいは両方の設計変更による不具合原因の発見
例：同じくエンジンのピストンとシリンダの不適合。今度は、ピストンの設計を変更し、部品番号のマイナー番号が１つ増加したとする。ところが、設計変更により特定のロットのシリンダとの干渉が発生し最悪破損に至る。この場合は、部品番号も属性と考えると、シリンダのロット番号とピストンの部品番号を属性として組み合わせを発見することができる。なお、新製品の設計そのものの問題は、製造された製品全体に故障が発生するはずなので、本明細書での説明の対象外とする。

［本発明によるシステムパフォーマンス向上］
以下、本発明のシステムパフォーマンスの向上について試算する。ここでは、以下の前提条件を置く。

（自動車製造業における計算の前提）
・ある車種で年間１０万台生産（日に約３００台）、完成製品車の部品管理は平均的に１０年としておよそ１００万台分である。

・１台の完成車に使われる部品点数は数１０万点、だたし、データベースで管理する必要がある重要部品は５万点である。

・上記の重要部品のうち、ＯＥＭ（製品製造工場）が直接扱う部品は数百点と仮定する。部品階層としては３〜５層までとし、１つの部品に子部品が１０〜１００点ほど組みつけられるとする。平均的に４層の部品階層で１層目が１００個の部品、２層目と３層目が１０個の部品、４層目が５個の部品から組みつけられるとモデル化すると下記の式のように約５万点の重要部品から１台の完成車ができることになる。
１＊１００＊１０＊１０＊５

・各サプライヤは１〜１０個程度の部品を扱うとし、１次サプライヤは５０程度、２次サプライヤ、３次サプライヤはそれぞれ親部品に対し３〜４社ずつ、５０＊３＊３でおよそ５００のサプライヤがあり、それぞれの組み付けられている部品やその詳細な情報は各サプライヤにあるとする。ただし、ＯＥＭや親部品の会社は自分たちが組み立てに使用する部品のＳｅｒｉａｌ番号またはロット番号は把握しているとする。

・ＯＥＭと各サプライヤ（５００社）はインターネットで結ばれ、サプライヤポータルと呼ばれるＷｅｂベースのシステムで、通常の取引だけでなく部品に関する品質情報などを交換している。ＨＴＴＰだけでなくＷｅｂサービスのプロトコルも使いＷｅｂアプリケーションとして情報交換が実装されている。インターネットの通信は、Ｔ１（１．５Ｍｂｐｓ）またはＥ１（２Ｍｂｐｓ）であるので、２５６Ｋバイト／ｓｅｃ程度の通信速度と仮定する。

・１つの部品の属性として、部品番号、ロット番号、シリアル番号以外に製造年月日、作業者、作業方法、組み付け部品、作業履歴、などがあり、１部品あたりのレコードはおよそ５００バイトとする。

まず、通常のＯＥＭが本発明と同じ課題を解く場合は、データマイニングでよく知られたアプリオリ（およびその改良アルゴリズム）を用いるのが普通と思われる。この場合、ＯＥＭの処理コンピュータ上からすべての部品データにアクセスできる必要がある。最も効率のよいアプリオリ・アルゴリズムを用いてもすべてのレコードに最低１回はアクセスする。部品点数が５万点、１部品あたり５００バイトなのでデータベースサイズは１００万台ｘ５万部品ｘ５００バイト＝数１０Ｔバイトにもなる。オリジナルのデータは５００社のサプライヤに分散しているのでそのつどアクセスしたのでは数１０Ｔバイトの通信になり不可能である（５００バイトのうち必要なデータだけを送ったとして数１０バイトになったとしても数１０〜１００万秒＝数週間かかる）。現実的には、その日の生産した情報だけを１日に一回バッチで送るとすれば、３００台ｘ５万部品ｘ５００バイト＝７．５Ｇバイト、約３０分ですむが、その場合でも数１０Ｔバイトのデータベースを総アクセスする必要がある。高速の２次記憶（例えば毎秒１００Ｍ〜１Ｇバイトの転送速度）があったとしても、数１０Ｔバイトのアクセスには数万〜１０万秒＝数時間〜数日程度になり１日でも早く不具合を発見する目的からは容認できない。また数１０Ｔバイトものデータベースを維持するコストも大きい。

次に、１箇所に集中管理されているデータベースをマイニングするのでなく、各分散したデータベースを順にアクセスして確信度や情報利得などの計算をすることを考える。本発明の解決手段の１つである部品表の一部の情報（部分木）を使用した計算（以下、部分木計算と呼ぶ）の有効性を確認するため、ここでは部分木計算を使わない場合をまず試算する。

まず、故障部品のロットで頻出するもの（支持度が大きいもの）を計算する。ここで故障が報告されている台数を１０００台とし、各サプライヤへは１台あたり２０バイトほどの部品の製造番号が送られる。また、１台あたり１００個の１次部品があるとする。ＯＥＭ（製品製造工場）から１次サプライヤへの通信は、１０００ｘ２０ｘ１００＝２Ｍバイト、１秒以内の通信である。各サプライヤでは数１００万程度の部品データ（データベースサイズとしては数百Ｍバイト）の検索であるが、検索対象は１０００台分（数Ｍバイト）の特定のロットの支持度を計算するだけであるので、検索と計算時間は数秒程度と考えられる。次に２次サプライヤに１０００台の故障製品に使われた部品の製造番号が同様に送られる１０００ｘ２０ｘ１０＝０．２Ｍバイト（ここで、１次部品１個に１０個の２次部品があるとする。また、１００社の１次サプライヤの処理は並列に行われることに注意すると、実質１社の１次サプライヤの時間だけを考えればよい）、２次サプライヤでの同様な処理時間と合わせても数秒であろう。３次サプライヤ、４次サプライヤも同様である。支持度の高い部品のロットをＯＥＭに報告する通信も時間的には問題はない。以上を考慮すると、ＯＥＭにすべての支持度の高い部品のロット番号が集められる時間はおよそ１０分以内と考えられる。

次に、支持度の高い部品の組み合わせの情報利得（確信度でもよい）を計算する。４次サプライヤの異なる２部品のロット番号の組み合わせを考えるとする。また、１ロットあたりの部品数は数１０〜１０００程度とし、特に下の階層のロットあたりの部品数が多くなる傾向があるので、１〜４次部品のロットサイズの平均をそれぞれ１０、１０、１００、１０００個とする。

ここで本発明の部分木計算を考慮しないとすると、ＯＥＭの製品レベルまで逆トレースすることになる。４次部品のロットに使われている製品の場合、１０００ｘ１００ｘ１０ｘ１０＝１千万台以上になる。実際は、該当製品や親部品に使われない部品もあるので、もう少し限られた数になる。仮に１０分の１から半分ぐらいが使われるとすると１００ｘ５０ｘ５ｘ５＝数１０万の部品データとなる。各部品情報は数１０バイトとしても数１００Ｍバイトものデータ量になり、転送速度を考えると１０〜２０分ほどの時間がかかることになる（逆トレースの場合、各レイヤーのサプライヤは基本的に１社なので、並列に通信や計算ができないことに注意）。

更に、ＯＥＭでは１００万台分のデータベースから数１０万台分のデータにアクセスすることになるが、これは検索のヒット数が多いため時間がかかると考えられる（総アクセスほどではないが総レコード数の数十％にもなりデータ転送量だけでも数百Ｍバイトになる）。仮にＯＥＭでの計算が３０分ほどかかるとすると、本発明の部分木計算を考慮しない場合でも支持度が高い部品の組み合わせ１つにつき１時間程度の時間で終了し、組み合わせが複数あっても数時間以内に計算が終わることがわかる。すなわち、数日から数週間かかる計算が数時間程度で計算できることになり、部分木計算を考慮しない場合でも分散データベース上のトレーサビリティを使うことで大きな効率改善が達成できることがわかる。

最後に、本発明の部分木計算の局所的な計算による効率向上を試算する。前半の支持度が高い部品のロットを求める手順は同じである（１０分程度の時間）。

次に、４次サプライヤの部品２つの組み合わせを計算する。共通のサプライヤは３次サプライヤとしてもよい。故障に相関する２つの部品の組み合わせは木の上でまったく離れたところにあるよりは、物理的・論理的に近いところにあると考えるのが妥当であるからである。

３次サプライヤは組み合わせた部品とロット番号がわかると、該当４次サプライヤからデータをもらう必要はない。つまり、ＯＥＭから４次部品のロット番号の組み合わせの情報をもらうと、自分の局所的なデータベースだけからそのロットを使っている部品集合を計算することができる。４次部品のロットサイズは１０００個と仮定しているので、１００万個の部品データベースから１０００〜２０００程度までの３次部品データを検索することになる。これと、故障製品からの順方向にトレースしてきた故障製品に使われている３次部品データもおよそ１０００個（１つの製品に２つ以上使われていると２０００個以上）程度のデータ量であり、これらの積集合の計算も問題なく行われる。一般的に、この程度のデータベース検索と計算なら数分程度の時間と思ってよい。ここで、計算結果の情報利得が所定の閾値より大きければ部品のロット番号の組み合わせを故障原因の候補としてＯＥＭに返送する。

各組み合わせは、異なる３次サプライヤで並列に計算できることに注意すれば、本発明の部分木計算を用いた場合、組み合わせがいくつあっても１０〜１５分程度で答えが求まることになる（２つの組み合わせを同一のサプライヤで計算する場合を除く）。以上をまとめると図８のようになる。図８は、従来手法（アプリオリ）と本発明の手法のシステムパフォーマンスを比較した図である。

なお、経済効果について言及すると、通常のアプリオリを用いた方法では結果が出るまでに数日を要し、１日に３００台の生産が行われ市場に出荷されるため、もしこの３００台がリコール対象になるような場合、１台あたりのリコール費用を１０万円と見積もれば、１日あたり３０００万円、３日で１億円、１０日で３億円という費用が余計にかかることになる。

また、部分木計算の効果は４〜５時間の計算時間を１０分程度までに早めることができる。この場合、リコール費用に換算すると大きな額にはならないが、一方、人命にかかわるような危険度の高い不具合の場合は、万一事故がおきた場合は損害賠償のみならず企業の信頼性やイメージなどへの計り知れないダメージとなり、金額に換算できるものではない。また、企業の信頼度への損害は保険も利かない。この場合、１時間あるいは１分でも早い解決が望ましいことは明らかである。

また、本発明が、製品が事故を起こしたような特別な場合にのみ使われるのではなく、日常的に、サプライヤの品質評価などのメトリクスを計算する（故障ではないが品質の低い製品からトレースしてサプライヤを特定する）アプリケーションを考えると、計算時間が数時間から１０分程度に短縮されるのはＩＴの効率化という面で非常に意味のあることである。

［情報利得をローカルに計算することの有効性の議論］
ある部品の組み合わせが故障することの情報利得を計算するのに、製品レベルまで逆トレースして計算することと、途中の共通親部品のレベルでローカルに計算することは同じではない。ここでは、実用上、この計算方法で問題がないことを議論する。

まず、製品レベルで計算すると意味がある相関関係があるという結果が出るのに、ローカルに計算するとそうはならない場合がある。例えば、図９に示すように、ある部品Ｃは大半が故障製品に使われており、かつ、すべて同じ属性の部品Ａ，Ｂから組み立てられている場合を考える。

この場合、共通親部品の大半が故障製品に使われているため、当然、その組み付け部品である部品Ａと部品Ｂの組み合わせも共通親部品Ｃの大半を占める。そのため、共通親部品Ｃ内におけるもともとのエントロピーが極端に低い（ほとんどが故障する）ので、情報利得はほとんど得られない。しかし、図９からわかるように明らかに部品Ａのロットａと部品Ｂのロットｂの組み合わせは故障することに寄与する。

ただし、この場合、共通親部品Ｃ単体で故障の原因になることは明らかであり、Ｃが故障と相関が大きいことはすぐに計算できる。しかし、実際には部品Ｃ、部品Ａ、部品Ｂ、または、その組み合わせが原因かどうかは、このようなデータマイニングのような手法から決定することができない。一般的には、技術者による調査や他製品まで含めた解析などを用いる必要がある。

次に、上記のケースとは逆に、図１０に示すように、ローカルには情報利得が高く出るのに、実際は別の共通親部品が多数あり、別のところでは相関が出ないということがある。この場合、製品レベルまで逆トレースして計算すると、あまり情報利得が高くならないことになる。

図１０では、共通親部品Ｃだけを見た場合、Ｃ内では部品Ａのロットａと部品Ｂのロットｂの組み合わせが故障することに対して相関が高いことを示している。ところが、同じ部品の同じロットが別の共通親部品Ｃ’にも使われており、Ｃ’内で情報利得を計算すると逆にエントロピーが増大することがある。

このような場合、すべての共通の親部品を調べなければ間違った結論に至る恐れがある。ひとつの解決策は、すべての共通の親部品に関して情報利得を計算し、すべてで増大する（すべての親部品での情報利得が高い場合のみ寄与があるとするルールで１つでも情報利得が増えない場合は寄与しないとする）か、多数決をとることなどで解決できる。

［情報処理装置のハードウェア構成］
図１１は、図２の情報処理システムの各データソースを情報処理装置１０００とし、そのハードウェア構成を示したものである。以下は、コンピュータを典型とする情報処理装置として全般的な構成を説明するが、その環境に応じて必要最小限な構成を選択できることはいうまでもない。

情報処理装置１０００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１０、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）１０６０、パラレルポート１０８０、ＵＳＢポート１０９０、グラフィック・コントローラ１０２０、ＶＲＡＭ１０２４、音声プロセッサ１０３０、Ｉ／Ｏコントローラ１０７０、ならびにキーボードおよびマウス・アダプタ１１００などの入力手段を備える。Ｉ／Ｏコントローラ１０７０には、フレキシブル・ディスク（ＦＤ）ドライブ１０７２、ハード・ディスク１０７４、光ディスク・ドライブ１０７６、半導体メモリ１０７８、などの記憶手段を接続することができる。

音声プロセッサ１０３０には、増幅回路１０３２およびスピーカ１０３４が接続される。また、グラフィック・コントローラ１０２０には、表示装置１０２２が接続されている。

ＢＩＯＳ１０６０は、情報処理装置１０００の起動時にＣＰＵ１０１０が実行するブートプログラムや、情報処理装置１０００のハードウェアに依存するプログラムなどを格納する。ＦＤ（フレキシブル・ディスク）ドライブ１０７２は、フレキシブル・ディスク１０７１からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供する。

光ディスク・ドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この際は各ドライブに対応した光ディスク１０７７を使用する必要がある。光ディスク・ドライブ１０７６は光ディスク１０７７からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供することもできる。

情報処理装置１０００に提供されるコンピュータ・プログラムは、フレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカードなどの記録媒体に格納されて利用者によって提供される。このコンピュータ・プログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、または通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、情報処理装置１０００にインストールされ実行される。コンピュータ・プログラムが情報処理装置に働きかけて行わせる動作は、既に説明した装置における動作と同一であるので省略する。

前述のコンピュータ・プログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としてはフレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカードの他に、ＭＤなどの光磁気記録媒体、テープ媒体を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハード・ディスクまたは光ディスク・ライブラリなどの記憶装置を記録媒体として使用し、通信回線を介してコンピュータ・プログラムを情報処理装置１０００に提供してもよい。

以上の例は、情報処理装置１０００について主に説明したが、コンピュータに、情報処理装置で説明した機能を有するプログラムをインストールして、そのコンピュータを情報処理装置として動作させることにより上記で説明した情報処理装置と同様な機能を実現することができる。従って、本発明において１つの実施形態として説明した情報処理装置は、方法およびそのコンピュータ・プログラムによっても実現可能である。

本発明の装置は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実施では、所定のプログラムを有するコンピュータ・システムでの実施が典型的な例として挙げられる。かかる場合、該所定のプログラムが該コンピュータ・システムにロードされ実行されることにより、該プログラムは、コンピュータ・システムに本発明にかかる処理を実行させる。このプログラムは、任意の言語、コード、または表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接実行すること、または（１）他の言語、コード、もしくは表記への変換、（２）他の媒体への複製、の何れか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体を含むプログラム製品もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハード・ディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭなどの任意のコンピュータ可読媒体に格納することができる。かかるプログラムは、コンピュータ可読媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記録媒体に格納することもできる。

以上、本発明を実施形態に則して説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態または実施例に記載されたものに限定されるものではない。

製品と部品のデータソース間の関係を示した図である。 本発明の１つの実施形態である情報処理システムの構成の一例を示した図である。 自動車の部品（エンジン、シリンダ、ピストン）を例にとって、第１のステップを模式的に表した図である。 自動車のシリンダ部品を例にしたｇｅｔＨｉｇｈＳｕｐｐｏｒｔＡｔｔｒｉｂｕｔｅＳｅｔ（）の動作の模式図である。 部品木の一部分だけを使った情報利得の計算方法を例で説明するための図である。 自動車生産会社における、故障発見、解析、原因特定、リコール対象プロセスの実装例を示した図である。 自動車生産会社における、本発明を利用した故障発見、解析、原因特定、リコール対象プロセスのＧＵＩ画面例を示した図である。 従来手法と本発明の手法のシステムパフォーマンスを比較した図である。 共通部品Ｃは大半が故障製品に使われており、かつ、すべて同じ属性の部品Ａ，Ｂから組み立てられている場合を示す図である。 ローカルには情報利得が高く出るのに、実際は別の共通親部品が多数あり、別のところでは相関が出ない場合を示す図である。 情報処理装置１０００のハードウェア構成を示した図である。

符号の説明

１０ 製品製造工場システム
１１ａ、２１ａ、３１ａ、４１ａ ＣＰＵ
１１ｂ、２１ｂ、３１ｂ、４１ｂ 記憶部
１１ｃ、２１ｃ、３１ｃ、４１ｃ ネットワーク・コントローラ
１２ ユーザ・インターフェース・コントローラ
２０、３０ １次サプライヤシステム
４０ ２次サプライヤシステム
５０ ネットワーク
１０００ 情報処理装置

Claims (15)

1. 部品の属性値を保持する部品表データから故障原因の候補となる部品属性値の組み合わせを求める方法であって、
   故障製品の集合から支持度が所定の値よりも高い部品属性値を抽出するステップと、
   前記支持度が所定の値よりも高い部品属性値の組み合わせが故障原因であるとするルールの情報利得を計算するステップと、
   前記情報利得が所定の閾値より大きいものを選択するステップと、
   を含む方法。
2. 前記支持度が所定の値よりも高い部品属性値を抽出するステップにおいて、連続する属性値を１つの属性値とみなして前記部品属性値を選択する、請求項１に記載の方法。
3. 前記支持度が所定の値よりも高い部品属性値を抽出するステップにおいて、各部品の前記故障製品に使われている部品の部分集合も合わせて求める、請求項１に記載の方法。
4. 前記情報利得を計算するステップにおいて、各部品情報が異なる場所に分散している場合に、
   ２つの部品の共通の親部品の集合を、それぞれの属性値を持つ２つの部品から追跡して求め、
   前記故障製品に使われている共通の親部品の前記部分集合から、２つの部品属性値を持つことが故障原因とするルールの情報利得を前記部品表データの一部の部分木情報だけを使って計算する、
   請求項３に記載の方法。
5. 前記所定の閾値の決定は、前記閾値を漸次増加させて部品属性値の組み合わせを絞り込む、請求項１に記載の方法。
6. 部品の属性値を保持する部品表データから故障原因の候補となる部品属性値の組み合わせを求める情報システムであって、
   故障製品の集合から支持度が所定の値よりも高い部品属性値を抽出する部品属性値抽出部と、
   前記支持度が所定の値よりも高い部品属性値の組み合わせが故障原因であるとするルールの情報利得を計算する情報利得計算部と、
   前記情報利得が所定の閾値より大きいものを選択する情報利得選択部と、
   を備える情報システム。
7. 前記部品属性値抽出部は、連続する属性値を１つの属性値とみなして前記部品属性値を選択する、請求項６に記載の情報システム。
8. 前記部品属性値抽出部は、各部品の前記故障製品に使われている部品の部分集合も合わせて求める、請求項６に記載の情報システム。
9. 前記情報利得計算部は、各部品情報が異なる場所に分散している場合に、
   ２つの部品の共通の親部品の集合を、それぞれの属性値を持つ２つの部品から追跡して求め、
   前記故障製品に使われている共通の親部品の前記部分集合から、２つの部品属性値を持つことが故障原因とするルールの情報利得を前記部品表データの一部の部分木情報だけを使って計算する、
   請求項８に記載の情報システム。
10. 前記所定の閾値の決定は、前記閾値を漸次増加させて部品属性値の組み合わせを絞り込む、請求項６に記載の情報システム。
11. 部品の属性値を保持する部品表データから故障原因の候補となる部品属性値の組み合わせを求めるコンピュータ・プログラムであって、
    コンピュータに、
    故障製品の集合から支持度が所定の値よりも高い部品属性値を抽出するステップと、
    前記支持度が所定の値よりも高い部品属性値の組み合わせが故障原因であるとするルールの情報利得を計算するステップと、
    前記情報利得が所定の閾値より大きいものを選択するステップと
    を実行させるコンピュータ・プログラム。
12. 前記支持度が所定の値よりも高い部品属性値を抽出するステップにおいて、連続する属性値を１つの属性値とみなして前記部品属性値を選択する、請求項１１に記載のコンピュータ・プログラム。
13. 前記支持度が所定の値よりも高い部品属性値を抽出するステップにおいて、各部品の前記故障製品に使われている部品の部分集合も合わせて求める、請求項１１に記載のコンピュータ・プログラム。
14. 前記情報利得を計算するステップにおいて、各部品情報が異なる場所に分散している場合に、
    ２つの部品の共通の親部品の集合を、それぞれの属性値を持つ２つの部品から追跡して求め、
    前記故障製品に使われている共通の親部品の前記部分集合から、２つの部品属性値を持つことが故障原因とするルールの情報利得を前記部品表データの一部の部分木情報だけを使って計算する、
    請求項１３に記載のコンピュータ・プログラム。
15. 前記所定の閾値の決定は、前記閾値を漸次増加させて部品属性値の組み合わせを絞り込む、請求項１１に記載のコンピュータ・プログラム。
    

Images