(57)【特許請求の範囲】
【請求項１】
製品追跡システムであって、
システム・マネージャ部と照会マネージャ部とを備え、前記システム・マネージャ部がサプライチェーンとして提供される構成部品につき、バージョン変更のタイムスタンプを要素として前記サプライチェーンの時間的な発展を記述するベクトル・データと製品の構成索引データとを生成し、前記ベクトル・データが前記構成索引データを索引付けしており、前記照会マネージャ部が前記製品の各パーツに対応する固有識別コードを戻させ、前記製品の識別値と少なくとも１つのパーツの識別値を含む照会を生成する、情報処理装置と、
前記システム・マネージャ部によって生成された前記ベクトル・データと前記構成索引データとを格納するデータベースとを含み、
前記システム・マネージャ部は、前記照会マネージャ部から照会を受け取り、前記データベースを、前記ベクトル・データおよび前記ベクトル・データにより索引付けされた前記構成索引データを参照して検索を実行する、製品追跡システム。
【請求項２】
前記ベクトル・データは前記データベースに格納され、前記サプライチェーンに対応して索引付けされる、請求項１に記載の製品追跡システム。
【請求項３】
前記製品追跡システムは、前記製品に含まれる前記パーツの階層分析に従った前記製品に含まれる特定パーツの検索システムである、請求項１に記載の製品追跡システム。
【請求項４】
情報処理装置を使用して製品追跡を行う方法であって、前記方法は、前記情報処理装置に対して、
サプライチェーンとして提供される構成部品につき、バージョン変更のタイムスタンプを要素として前記サプライチェーンの時間的な発展を記述するベクトル・データおよび前記ベクトル・データにより索引づけられる製品の構成索引データを生成するステップと、
前記生成されたベクトル・データおよび前記構成索引データを格納するステップと、
照会マネージャ部が前記製品の各パーツに対応する固有識別コードを戻させ、前記製品の識別値と少なくとも１つのパーツの識別値を含む照会を生成するステップと、
照会を受け取り、データベースを前記ベクトル・データおよび前記ベクトル・データにより索引付けされた前記構成索引データを参照して検索するステップと
を実行させる、製品追跡方法。
【請求項５】
さらに、前記サプライチェーンに対応した前記ベクトル・データを作成するステップを含む請求項４に記載の製品追跡方法。
【請求項６】
情報処理装置を使用して製品追跡を行うプログラムであって、前記プログラムは、前記情報処理装置に対して、
サプライチェーンとして提供される構成部品につき、バージョン変更のタイムスタンプを要素として前記サプライチェーンの時間的な発展を記述するベクトル・データおよび前記ベクトル・データにより索引づけられる製品の構成索引データを生成する手順と、
前記生成されたベクトル・データおよび前記構成索引データを格納する手順と、
照会マネージャ部が前記製品の各パーツに対応する固有識別コードを戻させ、前記製品の識別値と少なくとも１つのパーツの識別値を含む照会を生成する手順と、
照会を受け取り、データベースを前記ベクトル・データおよび前記ベクトル・データにより索引付けされた前記構成索引データを参照して検索する手順と
を実行させる、製品追跡のためのプログラム。
【請求項７】
さらに、前記サプライチェーンに対応した前記ベクトル・データを作成する手順を実行させる、請求項６に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、製品管理に関し、より詳細には、本発明は、製品コードに対する新規なデータ構造を用いて効率的かつ迅速に構成部品の検索および追跡を可能とする、製品追跡システム、製品追跡を行うための方法、およびプログラムに関する。
【背景技術】
【０００２】
製造者にあっては、構成部品の追跡は、主要な課題となっている。車といった複雑な製品については、そのような追跡は、末端の製造者はますます責任を持たなくてはならないこととなっている。製造者は、その製品の副次的な構成部品についても責任を有しているが、部品管理のためのデータベースを管理することは、供給連鎖がより拡大し、またより流動的になっているので困難になっている。
【０００３】
他の問題点に加え、上述した環境下でソリューションを提供するために、近年では、エレクトロニック・プロダクト・コード(Electric Product Code: EPC)システムが提案されている。本発明は、EPCグローバル・ネットワーク・スタンダードに適合する企業について、無線周波数識別化(Radio Frequency Identification (RFID)でタグ付けされた部品および製品のために提案されるものである。EPCグローバルは、製品ラベリングのための規格であり、EANインターナショナルおよびユニフォーム・コード評議会(Uniform Code Council: UCC)が協働して管理している。EPCグローバル・ネットワークは、Auto-IDセンタにより開発されたシステムであり、エレクトロニック・プロダクト・コード(Electronic Product Code: EPC)およびRFID技術を普及化させるためのEPCグローバルにより維持されている。EPCグローバル・ネットワークは、下記の基本的なコンポーネントを含んでいる。
（ａ）エレクトロニック・プロダクト・コード（EPC）−ユニバーサル・プロダクト・コード(Universal Product Code: U.P.C)、すなわちバーコードのようにEPCは、製造者、製品、バージョンおよびシリアル番号を識別し、アイテムを固有に識別させる数値のセットを使用する。
（ｂ）IDシステム（EPCタグおよびリーダ）−EPCタグは、アンテナに取り付けられたマイクロチップからなる。EPCは、このタグに記録され、製造プロセス中に適用される。EPCタグは、それらのEPCを、無線周波数を使用する識別を使用してEPCリーダに対して通信する。EPCリーダは、無線周波数を使用してEPCタグと通信し、EPCミドルウェアを用いる局在化した商業情報システムへと情報を提供する。
（ｃ）EPCミドルウェア−サービスのためのこのソフトウェア規格は、EPCリーダまたはネットワーク・リーダまたはビジネス情報システムとの間でデータ交換を可能とする。
（ｄ）オブジェクト・ネーム・サービス（ONS）−ビジネス情報システムは、アイテムに関するEPCを情報に対してマッチングさせる必要がある。ONSは、コンピュータをワールド・ワイド・ウェブ(WWW)のサイトへと向かわせる、このサービスを提供する自動ネットワーク・サービスである。
（ｅ）EPC情報システム（EPCIS)−EPC情報サービスは、ユーザがEPCに基づいて取引を行っているパートナーとデータ交換を可能とする。
【０００４】
加えて、EPCグローバル・ネットワークは、フィジカル・マークアップ・ランゲージ（PML）規格を取り込むように設計されている。PMLは、XMLの拡張であり、物理世界におけるオブジェクトを識別させるためにAuto-IDセンタにより設計された。
【０００５】
EPCグローバルはまた、RosettaNetにより開発されたビジネス−ツウ−ビジネス(B2B)通信におけるebXML（電子ビジネスXML）標準を採用している。RosettaNetは、最近、ユニフォーム・コード評議会UCCに統合され、EPCで識別されるタグ−バーコードを管理する責任を有している。RosettaNetは、工業規格用途に対するebXMLへと拡張しており、B2B設定において通信される情報を詳細化することを可能としている。RosettaNetは、またebMS（ebXMLメッセージ・サービス）をその標準規格に取り込見つつあり、言語ばかりではなく、B2B通信の通信チャネルを提供する。EPCグローバルは、類似のメッセージング・サービスであるEPCメッセージングを提供しており、これもまたebXMLに適合する。
【０００６】
すなわち、供給者と製造者との間の簡単で、直接的な通信チャネルのための基盤は、敷かれているといえる。本発明の技術は、これらの条件を利用しようとするものであり、標準化された通信は、追跡技術を、より堅牢なアプリケーションとすることを可能とする。
EPCグローバル・ネットワークを用いる場合、この技術は、供給者のデータベースの横断的に閲覧することを維持する技術として捉えることができる。データベースのビュー管理として、この要求は特異的なものである。最適化された照会へのレスポンスを閲覧することについては、S. Chaudhuri, R. Krishnamurthy, S.  Potamianos, K. Shimらの”Optimizing Queries with Materialized Views.”, ICDE Proceedings 1995, P. 190-200（非特許文献１）に記載されている。その検討のほとんどは、データソースのアップデートの間にビューを管理することに費やされている。最近のいくつかのプロジェクトでは、Songting Chen, Jun Chen, Xin Zhang and Elke A. Rundensteiner, “Detection and Correction of Conflicting Source Updates for View Maintenance.”, ICDE’ 04, Boston, USA （非特許文献２）に開示されている。本発明者らの知り得る限りでは、いまだデータ供給源の関係が変化する間のビュー管理の問題に取り組んだ者はいないということができる。
【０００７】
ビュー管理に対してバージョンを付するという着想は新規でもなく、またバージョンとしてベクトルを使用するという着想も新規ではない。これらの技術は、Songting Chen, and  Bin Liu and Elke A. Rundensteiner, “Multiversion Based View Maintenance Over Distributed Data Sources”, ACM Transactions on Data source Systems (TODS),２００４年８月アクセプト、２００４年２１月に公開（非特許文献３）において、静的な関係およびメンバを含むデータソースのシステムを管理するための使用されてきている。これまでになされていない新規な技術は、複雑さが進行してゆく構成部品の階層についてデータソース管理に対して、ベクトル・バージョン付けを適用することである。
【非特許文献１】S. Chaudhuri, R. Krishnamurthy, S. Potamianos, K. Shimらの”Optimizing Queries with Materialized Views.”, ICDE Proceedings 1995, P. 190-200
【非特許文献２】Songting Chen, Jun Chen, Xin Zhang and Elke A. Runcensteiner, “Detection and Correction of Conflicting Source Updates for View Maintenance.”, ICDE’ 04, Boston, USA
【非特許文献３】Songting Chen, and  Bin Liu and Elke A. Rundensteiner, “Multiversion Based View Maintenance Over Distributed Data Sources”, ACM Transactions on Data source Systems (TODS),２００４年８月アクセプト
【発明の開示】
【発明が解決しようとする課題】
【０００８】
これまでに上述した技術が知られているが、これらの技術に対しては最終製品により完了される製品の構成部品の詳細なレコードを維持することが望まれていた。より具体的には、既存技術に対し、供給者またはアウトソーシングといった構成の変更に応答してより柔軟性を与え、自動化でき、かつ動的応答性を付与することで既存技術を改善したシステム、方法およびプログラムを提供する技術が必要とされていた。
【０００９】
本発明の対象は製造業であり、より具体的には本発明は、スキーマまたは相対関係がいつでも変化される多層の供給者のデータソースにわたり複雑な製品の部品追跡性を改善することを目的とする。本発明の別の目的は、製造者と供給者との間の変化する関係を管理する手段を提供することにある。さらに、本発明の目的は、供給者が変わる現実世界の設定において、いかなる製品の構成部品でも迅速に追跡することに対処することを目的とする。
【００１０】
本発明により解決される問題を考察するにあたり、製造者と供給者との構成を、下記のように仮定する。製品データベースおよび構成部品の供給者のデータベース{S}が存在するものとする。{S}は、その時点で参照しているデータと過去に参照したデータとの両方を含んでいる。すなわち、{S}を、古い供給者を含むすべての供給者の部品データに関するデータソースの集合とする。加えて、{S}内のデータソースSiに対して、Siで参照されるデータソースは、また{S}内に含まれているものとする。すなわち、{S}は、また、製品の製造者への供給者に対する構成部品の供給者をも再帰的に含んでいるものとする。
【００１１】
製造者は、変更される可能性のあるデータソースのスキーマおよびまた変更される可能性のあるデータソース間の関係の両方について{S}内のいかなるデータにわたって管理できないものとする。
【００１２】
このとき、いくつかの合理的な仮定を、製品追跡問題に適用できるものとする。
（ａ）製品データベースおよびすべての{S}内のデータソースは、追加されるだけであること。
（ｂ）{S}にわたり、製品からのすべての経路は、有限であり、エンドレス・ループが存在しないこと。
これらの仮定のうち（ａ）は、ほとんどの製造アプリケーションでは、製品が製造されてデータソースに追加され、けっして変更されないこと、（ｂ）は構成部品の階層の現実的なモードであり、製品が無限大の部品を有していないことから、上述した仮定は、ほとんどの製造企業で採用されるスキーマであることから妥当なものであると考えられる。
【課題を解決するための手段】
【００１３】
すなわち、本発明は、CIDテーブルとして参照される新規なデータ構造およびベクトル・バージョニング・システムを提供するものである。CIDテーブルは、バージョン化された分散されたテーブルで構成部品を識別するために用いられ、分散されたテーブルは、最終製品の構成部品階層をモデル化する。CIDテーブルは、ベクトル・バージョニング・システム（VVS）によりサポートされ、本発明の方法は、VVSを使用して、製造時点における構成部品の階層構造に沿ってCIDテーブルの構造を適正化する。
【発明の効果】
【００１４】
本発明のバージョニング・システムは、これまで未解決とされてきた、構成部品階層の変化を管理するという問題に対するソリューションを提供する。本発明のバージョニング・システムはまた、弱く関連づけられた参照データソースのシステムを管理するという問題に対する一般的なソリューションを提供することができる。
【００１５】
本発明のCIDテーブルは、データソースのＡと{S}の要素との間の関係が知られている場合に、Ａ内の所定のインデックスが付されたいかなる情報についても効率的に検索することができる。このため、ルックアップ時間がＯ（１）で部品をルックアップするためのソリューションとなる。この問題はまた、これまで未解決な問題であった。CIDテーブルの技術はまた、いかなる情報管理設定においても利用することができる。
【００１６】
本発明の技術の主要な構成は、処理が完全に“インハウス”であることにある。すなわち、すべての計算は局所的に実行され、すべての情報は局所的に格納され、供給者のデータベース内に「足跡」を残さず、むしろ、いかなる新規な通信システムを使用することがなく、また供給者に対して新規な要求を課すこともなく、この技術は既存の種々の規格を使用するのみである。RFIDタグについてのEPCグローバル規格内で機能するように特に設計されてはいるものの、本システムは、また、供給者との間での合意された別の既存の通信にも取り込ませることができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明を図面に示した特定の実施の形態をもって説明する。図１は、本発明の製品追跡システム１０を示しており、製品追跡システム１０は、概ね、オペレーティング・システム１２により与えられる指令に従ってシステムを制御するためのPENTIUM（登録商標）またはPowerPC（登録商標）またはRISCタイプCPU（図示せず）を含むマイクロコンピュータまたはワークステーションを含んでいる。オペレーティング・システムは、Windows（登録商標）XP、Windows（登録商標）200Xサーバ、Windows（登録商標）NT、MacOS（登録商標）、AIX（登録商標）、UNIX（登録商標）、LINUX（登録商標）などを含むいかなる適切なタイプのものから選択することができる。オペレーティング・システムの上部層には、Java（登録商標）アーキテクチャ１４が構築されており、Java（登録商標）は、後述する本発明により生成されるデータ構造の生成をサポートしている。本発明の製品追跡システム１０は、Java（登録商標）アーキテクチャ１４の上に、さらにシステム・マネージャ１６および照会マネージャ２２を備えている。システム・マネージャ１６は、さらにCIDテーブル・マネージャ１８とVVSマネージャ２０とを含んでおり、VVSマネージャ２０は、照会を受けた製品の構成部品の追跡のためのCIDテーブルおよびVVSデータを生成し、サポートしている。システム１０は、照会マネージャ２２を含んでおり、照会マネージャ２２は、特定の製品についての構成部品の追跡について照会要求を受け取って、システム・マネージャ１６と通信している。照会マネージャ２２の目的はシステム・マネージャ１６と製品追跡の照会にあたり通信することである。照会マネージャ２２は、製品のインデックスを使用して照会を処理しており、上述した定義に基づく１つまたはそれ以上のデータソースである{S}内に含まれる情報を要求する。
【００１８】
製品追跡システム１０はさらに、製品データベース２４を備えており、製品データベース２４は、製品識別子（プロダクトid）といった製品データおよび製品タイプ、製造日などの他のデータを格納している。製品データベース２４は、記録または読出し、または記録／読出しの両方のアクセス制御を行うため、本発明の製品追跡システム１０に直接接続されていてもよいし、製造者の工場といった遠隔サイトに配置されていてもよい。
【００１９】
システム・マネージャ１６により生成されたCIDテーブルとVVSとは、追跡データベース２６内に格納される。追跡データベース２６は、少なくとも２つのデータ領域を含んでいる。１つの領域は、CIDテーブル２８を格納していて、特定のVVSデータ３０を指定しており、他の領域は、照会を受けた製品の構成部品の追跡において本質的に使用されるVVSデータを格納している。CIDテーブル２８とVVSデータ３０とを構築するために必要なデータは、供給者のデータソースから定期的にまたはネットワーク３２を通したシステム・マネージャ１６からの要求に応答して取得される。システム・マネージャ１６は、照会マネージャ２２からの照会を受け取ると、システム１０は、例えばプロダクトidにより指定されるVVSデータを参照する。システム・マネージャ１６は、その後、VVSデータにより索引付けされたCIDテーブル２８を、プロダクトidを検索キーとして使用して検索する。目的とする部品が見出されると、システム・マネージャ１６は、照会マネージャに対して検索された結果を返してトランザクションを完了させる。
【００２０】
図２は、典型的な製品−構成部品の関係を指定した図である。製品Ｐは、多くの構成部品Ｗ、Ｆ、およびＥを含んでいる可能性があり、構成品は、図２に示されるように、それぞれさらにサブパーツＷ１、Ｗ２．．．を含んでいる可能性がある。最終製品Ｐは、図２（ａ）に示されるように、多くの構成部品およびサブパーツから構成されているので、製品Ｐは、構成部品およびサブパーツからなる木構造により特徴づけられる。本発明では、構成部品およびサブパーツは、部品に付されたRFIDタグに格納されたEPC規格に適合する９６ビットの固有識別子により表されている。最終製品はまた、最終製品を固有に識別させるための固有識別子または他のプロダクトidによりタグ付けされている。したがって、プロダクト−パーツ木のノードは、固有識別子により置き換えられることになる。
【００２１】
図３は、木構造を有するCIDテーブルの実施の形態のデータ構造を示す。図３に示されるように、車は、idＢ1、idＢ2、およびidＢ3の３つの構成部品を含んでいる。例えば、idＢ1で識別される部品は、ホイールであり、ホイールは、さらに２つの部品idC1、idC2から構成されていて、これらは具体的にはハブとタイヤである。タイヤは、さらにidD4などにより識別されたサブパーツを含んでいる。加えて、木のノードは、すべて固有のプロダクト識別値idAを含んでいるので、木のノードは、プロダクトidと特定の部品とを知るだけで照会することができる。図３に示したCIDテーブルは、小さなサイズのテーブルからなっているので、検索は効率的に行うことができる。
【００２２】
図３は、また、分散CIDテーブルの構造を示している。すべてのサブテーブルは、直接的に最終製品のID番号を参照しており、図３に示した実施の形態では、車が示されている。この特性は、製造者の製品データベースの閲覧によりすべてが検出されるという別の特徴を示すものである。
【００２３】
構成部品の供給ルートは、コスト、品質、供給量および部品のアウトソーシング化といった多くの理由により時々変更される。図４は、供給ルートが変更された構成部品またはサブパーツを示す。ハッチングされた部品は供給ルートが変更されている。図４に示した実施の形態では、ハブといったサブパーツは、新たな供給者から供給され、フレームおよび外装品は、構成部品４として新たな部品名である“ボディ”としてアウトソーシングされている。これらの変更の後、以前のCIDテーブルとは異なるエントリのCIDテーブルが生成される。従来では、CIDテーブルの変更は、システム・マネージャの大きな変更を伴いそしてユーザおよびソフトウェア・メーカに対して大きな資本投資を必要としていた。
【００２４】
CIDテーブルについてのスキーマは、いかなる時点におけるデータソースのシステムバージョンViに依存する。このため、新たなCIDは、すべての新たなバージョンについて生成される。CIDのサイズを小さく維持するために、どの時点でも新たなバージョンが発行できる。具体的には、新たなバージョンは、CIDのサイズが予め設定した限界値ｎに達した時点で発行することができる。
本発明にしたがい、上述した供給連鎖の変更は、新たなベクトル・バージョニング・システムのデータおよびVVSデータの生成を生じさせ、これらのデータは、典型的には、下記の情報を含んでいる。
（１）固有識別子Vi
（２）タイムスタンプtVi
（３）製品および備品のすべてのデータをリストした所与の時間における可変長ベクトルであって、各データが下記の情報を含むベクトル
（４）データソースの固有識別子si
（５）階層レベルにおける親データソースに対する参照；製品についてはこのフィールドは空とされる。
（６）タイムスタンプtsi
（７）このバージョンにおいてtsiが変更されたことを示すフラグ
（８）このデータソースに格納された製品のタイプPsi
【００２５】
データソース間の変更の追跡性を維持するため、本発明者らは、ベクトル・バージョニング・システムを実装させる。このバージョニング・システムは、システム内のすべてのデータソースの追跡性を維持させる、可変長ベクトルに依存する。本発明では、データに対するすべての変更が、製品の検索から検出される。このアプローチは、アップデート・タイムスタンプの意味づけに関連する不明確さを排除することができる。加えて、本発明によるバージョニングは、時間にわたる構成部品の改造における変化を可視化させることができる。ベクトル・バージョニングはまた、構成部品のルックアップの最適化のためのインフラ基盤を提供する。
【００２６】
システムのバージョニングを行うためにベクトルを使用することは、各データソースに関連して情報の独立性を維持する。この特性は、構成部品の階層が相互関連づけされたデータソースの木としてモデル化されるので都合がよく、このため、木のどの枝が変更されたか、およびどの枝が変更されずに同一に維持されているかを検索することを容易とする。ベクトル・バージョニング・システムについての要求される実装手法は、情報をＸＭＬドキュメントとして下記のように格納することである。
<version ID=uniqueID timestamp=time>
<data source ID=uniqueID parent=referenceID
time=timestamp changed=boolean type=referenceID />
…
</version>
製品タイプPsiは、製造者により決定される製品特異的なコードを使用するか、または物理マークアップ・ランゲージ（PML）規格を使用して実装することができる。バージョン・タイムスタンプは、構成部品の階層が変更された時点を参照させる。データソース・タイムは、データソースが変更された最新の時点である。製品の検索からのすべての変更は、製造者の製品データソースから得られる。
【００２７】
本発明のベクトル・バージョニング・システムは、製造時点での製品構造の断面を生成する。システムは、すべての構成部品の供給者の追跡性を維持するタイムスタンプを含む可変長ベクトルに依存している。製品の構造（新たな供給者、アウトソーシングなど）が変更されたどの時点であっても、新規なバージョンが生成される。それぞれのバージョンに対して各製品のすべての部品を索引付けする分散されたテーブルが存在し、テーブルのフォーマットは、ベクトル・バージョニング・システムの情報により決定され、最終製品を製造するために部品がどのようにして統合されたか、の木構造をモデル化している。図５（ａ）においては、VVSデータは、そのデータソースのスキーマを変更しており、この変更がタイムスタンプにより記録される。供給者のデータソースに対する変更は直接製品に影響を与え、これは逆に、ベクトル・バージョニング・システムのデータへと影響を与える。このことは、スキーマの変更通知を受け取ったシステム・マネージャが実行する。
【００２８】
図５（ｂ）は、新規な供給者が追加された場合の実施の形態を示す。製造ラインで実際に構成部品の階層における変更が通知された時点でだけ更新される。製品検査から変更を見出すことにより、バージョン変更における不明確さを無くすることができる。加えて、新規なデータソースに関連して製品データベースに通知または変更を行うことは必要とされない。
【００２９】
図５（ｃ）は、特定の供給者が以後供給しなくなった場合の実施の形態を示した図である。この状況は、Ｂからの最後の構成部品が使用された通知を受けたシステム・マネージャにより実行される。この通知は、Ｂがもはや供給者ではないこと製造サイトに配置された製造マネージャにより発行することができる。図５（ｂ）と図５（ｃ）との相違は重要である。本システムは、物理的に製造ライン上に存在しているので動的に新たな供給者を通知することができる。このため、特に通知は必要とされない。しかしながら、システム・マネージャは、供給者が停止されたたかどうかについて知ることができる類似の方法を有していない。すなわち、当該供給者からの部品の不存在は、発送の遅延である可能性もある。したがって、システム・マネージャは、システムから供給者を削除する特定の通知を受け取る必要がある。
【００３０】
構成部品の階層構造に対するすべての変更は、上述した３つの実施の形態では、排除することができる。例えば、供給者を新規な供給者に置換した時は、図５（ｂ）＋図５（ｃ）に対応し、２つの供給者の業務を単一の新たな供給者にアウトソーシングした場合には、図５（ａ）＋図５（ｂ）＋図５（ｃ）となる。
【００３１】
以下、CIDテーブルの生成および維持についていくつかの擬似コードを使用して説明する。システム・マネージャは、新規な製品が製造される時には常に、製品データベースをチェックしてCIDテーブルを更新する。加えて、システム・マネージャは供給者が停止された、または供給者がデータソースのスキーマを変更したかを通知するコマンドをモニタする。
【００３２】
図６は、新しいバージョンに対応するCIDテーブルを生成する場合の擬似コードを示す。新規なバージョンは、システム・マネージャが、供給連鎖が変更されたことを示すコマンドを受け取った時点で生成される。新規なバージョンは、以前のバージョンに対する追加的な変更を作成することにより生成される。図６に示した擬似コードにおいて、システム・マネージャは、新規なオブジェクトを生成するために古いバージョンをコピーし、その後新規なバージョンの特性を決定するため、受信したコマンドを解釈する。その後、新規なバージョンの新規なオブジェクトを用いて、新規なバージョンのための新規なCIDテーブルとして確立させる。
【００３３】
図７は、特定のバージョンのための新規なCIDテーブルを発行するための擬似コードの例を示す。まず、CIDテーブルを生成するバージョンが宣言され、その後プロダクトidがCIDテーブル内に設定される。その後、対応するバージョンが次のラインで参照されバージョンの対応するクラスが提供される。図８は、特定のバージョン（idVi）および特定のプロダクト（idBa）についての擬似コードの例を示した図である。擬似コードは、まずバージョンおよび製品の製造時をルックアップして、第１のループ内でのバージョンを認定し、第２のループでは、構成部品のid（idDBi）がコラム内に記入される。CIDテーブルは、バージョンに基づいているので、新規なCIDテーブルは、バージョンにおいて示されるデータソースにマッピングする必要がある。このマッピングは、２つのステップによって実行される。第１のステップは、トップ−ダウンでいくつのサブテーブルが分散したCIDテーブルに含まれているかを決定し、第２のステップは、各データソースの親を検索してどのテーブルが他のテーブルを参照しているかを決定する。
【００３４】
これらの２つのステップを、図９に示す、図９（ａ）には、トップ−ダウンステップが示されており、図９（ｂ）は、ボトム−アップステップを示している。各場合において、システム・マネージャが構成部品idおよびサブパーツidを検出した場合、システム・マネージャは、検出されたidを、適切な空フィールドに、所定の順番で記入してゆく。
【００３５】
すべての製品の構成部品の完全なリストを含ませるので、CIDは、新規な製品が製造された時にはいつも生成される。図１０は、新規な固有idの値を有する新規な製品が製造された場合にCIDテーブルをアップデートするための擬似コードを示す。擬似コードのアルゴリズムは、主としてすべての構成部品および製品の副次的な構成部品について、繰り返し検索を実行する。アップデートプロセスは、主にシステム・マネージャにより実行されるが、本発明ではルックアップ・サービス・マネージャといった他のエージェント・ソフトウェアを使用して構成部品idおよびサブパーツidなどの新規な製品のデータを集めることができる。エージェント・ソフトウェアは、SQL言語を使用した簡単な構成として実装でき、SQL言語で製品データベースから構成部品idおよびサブパーツidを、構成部品タイプおよびサブパーツのタイプと共に取得して、CIDテーブルをアップデートするために使用する取得したidと構成分のタイプとをリターンする。図１０に示されるように、CIDのアップデートはまず、CIDオブジェクトに索引iとタイムスタンプtimeを使用してアクセスする。ここで、索引iは、CIDテーブルに索引付けする新たなアイテムの索引である。図１０に示したアルゴリズムは、その後、CID（ｉ）がnullでないか否かをチェックすることにより、iについてCIDテーブル内にサブテーブルが存在するか否かを判断し、その後構成部品およびサブパーツのデータを取得し、CID（ｉ）がnullとなるまでパーツの階層レベルにおけるCIDテーブルにデータを追加する。この呼び出しは、CIDテーブルにリストされた最終製品におけるすべてのサブパーツについて繰り返し検索させるようにさせる。階層における変更は、データソース（idBi）が期待通りにｂｉに等しいか否かを判断することにより検出されると、システム・マネージャは、バージョンが変更されたか否かを決定し、その後関数new version()を呼び出し、その後、new version ()の下でupdateCID (idBi)を再度スタートさせる。関数new version（）を呼び出す前に、バージョン変更通知がシステム・マネージャにより受信される。
【００３６】
CIDテーブルを用いることで、製品−パーツ関係をルックアップすることが可能となる。このようなルックアップは、照会マネージャからのシステム・マネージャへと照会により実行される。図１１は、照会マネージャの擬似コードの例を示した図である。この擬似コードは、CIDテーブルを使用して最終製品についてのパーツのルックアップを完了させる。訂正されたCIDテーブルは、ベクトル・バージョニング・システムに従い、製造時刻を使用して識別される。照会は、ルックアップ・キーとして製品識別子idAiと部品識別子idBiとを含んでいる。その後、タイムスタンプtAi、バージョンViおよびパーツが照会内に設定される。検索後、決定された単一のパーツまたは複数のパーツのデータが、照会マネージャに対し、照会の戻り値として戻される。
【００３７】
図１２は、特定の製品のパーツについての製品追跡のための照会のための実施の形態を示す。照会マネージャ２２は、特定の製品idおよび構成部品またはサブパーツ・タイプまたはそれら双方を指定して照会をシステム・マネージャ１６へと発行する。システム・マネージャ１６は、照会内のパーツのパーツidを取得する。パーツidを決定した後、システム・マネージャ１６は、照会を受け取ってプロダクトid（pid）がリストされたベクトル・バージョニング・システムのデータを、バージョン・アナライザ１６ｂを使用して決定する。バージョン・アナライザ１６ｂは、照会を受けたプロダクトidを含むベクトル・バージョニング・システムのデータのバージョン番号またはバージョンidを決定する。ベクトル・バージョニング・システムのデータが決定されると、システム・マネージャ１６は、検索エンジン１６ａを使用して、決定されたpidをキーについてCIDテーブル（ラベルを必要とする）をベクトル・バージョニング・システムから検索する。検索エンジン１６ａは、SQLアーキテクチャまたはその他の検索アーキテクチャを実装するリレーショナル・データベースを含むいかなる従来のデータベース・ソフトウェアを用いても実装することができる。その後、システム・マネージャ１６は、さらに検索エンジンに対して、CIDテーブル内のパーツの特定パーツについて、パーツの固有識別コード(Uid)を指定して検索を実行させる。検索されたＵidは、システム・マネージャ１６に通知され、システム・マネージャ１６は、その後、Ｕid値を検索の結果として照会マネージャ２２へと戻す。
【００３８】
図１２に示した照会プロセスは、重要な部品の供給連鎖時として製造者とは独立して変更される場合における製品追跡に極めて有用である。本発明によれば、上述した供給連鎖における変更は、パーツ追跡分析に適正に考慮され、指定された製品には指定されたパーツが存在しないという照会結果を戻すような致命的な失敗を生じさせることがない。このような致命的な誤りは、供給連鎖が変更されてしまった場合に予測される。VVSデータおよびCIDテーブルは、また、検索空間を劇的に低下させるので、照会時間およびメモリおよびCPU占有時間などのハードウェア資源を劇的に削減する。
【００３９】
本発明のシステムは、パーツの製造者またはパーツのデータベースにおける索引を知ること無く全パーツのルックアップを行うように容易に拡張できる。この拡張は、典型的にはパーツのタイプについてPMLマークアップ規格を使用して実装することができる。しかしながら、製造者により広く用いられているいかなるマークアップ規格であっても本発明の構成は、可能である。パーツのタイプは、バージョン情報にリストされ、１つ以上の製造者を指定する。これらの製造者は、それぞれパーツタイプ・テーブルに登録されている。CIDテーブルが製品および製品タイプと共に照会された場合（製品および製品の製造者ではなく）、パーツのすべての製造者がチェックされる。後述する２つのアルゴリズムの擬似コードは、上述した拡張を与えることができる。
以下に示す第１の擬似コードは、ユーザ・オンデマンドにパーツ・テーブルを生成するために用いられ、僅かなメモリ領域を用いてシステム・マネージャのソフトウェア・モジュールとして容易に実装することができる。
【００４０】
SystemManager{
createPartTypesTable(idVi) { //version has id=idVi 
partTypesTable = new Mapping(); //from type to a set of database id’s
For each database with id=idDBi in the version with property id=idVi {
partTypesTable .add(type, idDBi);}}}
下記の第２の擬似コードは、パーツ・テーブルを当該バージョンについてパーツが由来するデータベースを識別して正確なCIDテーブル内のレコードに配置するために使用するアルゴリズムを示す。
LookupComponentPartFromProductAndType(index idAi, index type){
timestamp tAi = A.lookupTimestamp(idAi);
version Vi = versions.findVersion(tAi);
record Ai = CID(Vi).lookup(idAi);
index[ ] idDB[ ] = partTypesTable.lookup(type);
index part = null;
for (each idDBi in idDB[ ]){
if (Ai.idDBi != null) { part = Ai.idDBi; }
return part;}
これらのアルゴリズムは、本発明の適用例としてパーツタイプだけが知られている場合のパーツ追跡性を例示するものであって、製造業界にける本発明の別の応用例を例示する。
【００４１】
本発明の技術は、EPCglobal Network規格に適合する企業についてのRFIDによりタグ付けされた部品および製品について特に設計されている。これは、特に、EPCタグをRFIDタグの固有識別値として使用すること、およびEPC ISに通信可能なEPCミドルウェアを使用して、ONSに登録されることを必要とする。最終製造者は、固有識別子をブロードキャストする(EPC)、RFIDタグを含む部品を使用する。最終製品を製造するためにパーツを使用する場合には、RFIDタグが読み取られ、EPCが検出される。EPCは、ONSを使用して検索され、パーツに関連する情報は、EPC ISから呼び出される。EPCは、その後CIDテーブル内にパーツの固有識別子として格納される。パーツのEPCのCIDテーブル内での位置は、ONSを使用して検索され、製造者により決定される。
【００４２】
追加の副次的な部品は、パーツのEPC IS内にリストすることができるが、それら自体についてRFIDタグで個別的にラベルすることはない。この場合には、副次的な構成部品に関連する情報は、EPC ISを通してパーツ製造者から検索される。これとは別に、最終製造者がサブパーツ製造者からこの情報を直接的に検索させる場合（例えば、安全およびライアビリティ契約の一部として）、この情報は、システム・マネージャにより局所的に保存しておくことができる。
【００４３】
最終製品がその製造者がCIDテーブルにない構成部品を含む場合には、新規なバージョンが自動的に生成される。このため、本発明の製品追跡システムによれば、供給連鎖におけるいかなる変更での自動的に対処することができる。パーツのタイプは、PMLマークアップとしてEPC ISから検索され、新規なバージョンを生成するために使用される。バージョンから、問い合わせている最終製品から開始する新規なCIDテーブルが発行される。本発明の構成を使用するパーツのルックアップは容易である。CIDテーブルに格納されたEPCタグからパーツについてのすべての情報が、ONSおよびEPC ISを使用して検索することができる。
【産業上の利用可能性】
【００４４】
本発明のVVSおよびCIDシステムは、製造業界を超えて適用できる。VVSは、ルーズに連携した参照データベースの間において関連性を管理することができる。CIDは、データベース内での情報を索引付けする格納技術を提供する。同時に、これらの技術は、多数のデータベースからのレコードを含むいかなるデータセットについても索引付けおよび追跡性を提供することができる。この技術は、これまで汎用的なソリューションが無かった、ルーズに連携したデータベースの間における索引付けを提供する点で、特に新規なものである。
【００４５】
本発明の技術は、また、多数のパーツが本質的に同一な、例えばクレートまたはロットだけで識別されるような、単純な構成サブパーツのバッチであるような場合にでも適用することができる。この場合、クレートまたはロットIDが、CIDテーブルにおけるパーツの識別子として用いられる。この用途ではまた、リコールについての検索プロセスをスピードアップすることができる。損傷を受けたロットから各パーツを個別的に事後的に検索するのではなく、意図的に生成された固有識別子によることで、一度に単一のロットを参照するすべてのレコードについての検索が可能となる。
【００４６】
本発明の技術は、遠隔的なデータベースへのリクエストがバッチ処理されなければならない状況に対して用いるように容易に拡張することができる。CIDテーブルは、データベースの参照にしたがって分散され、このためのインフラ基盤はすでに確立されている。これは、CIDテーブルの所定の枝が、遠隔的なデータソースから照会のバッチが戻されるまでアップデートされないことを意味する。データソースが連続して使用できない場合や、接続時間が遅いまたは予測できない場合には、CIDテーブルは、特に効果的である。
【図面の簡単な説明】
【００４７】
【図１】本発明の製品追跡システム１０を示した図。
【図２】典型的な製品−構成パーツの関係を示した図。
【図３】木構造を有するCIDテーブルの実施の形態を示したデータ構造を示した図。
【図４】供給ルートが変更された構成部品およびサブパーツを示した図。ハッチングされたパーツがその供給ルートが変更されている。
【図５】ベクトル・バージョニング・システムのデータ構造の実施の形態を示した図。
【図６】新規なバージョンに対応するCIDを生成するための擬似コードを示した図。
【図７】特定のバージョンに新規なCIDテーブルを追加する場合の擬似コードを例示した図。
【図８】特定のバージョン（idVi）および特定の製品（idBa）についての擬似コードを例示した図。
【図９】（ａ）がトップ−ダウン検索を示し、（ｂ）がボトム−アップ検索を示した図。
【図１０】新規な固有のid値(Uid)を有する新規な製品について、CIDをアップデートした場合の擬似コードを例示した図。
【図１１】照会マネージャの擬似コードを例示した図であり、最終製品についての完全なルックアップのためにCIDテーブルを使用している。
【図１２】特定の製品についての照会の実施の形態を示した図。
【符号の説明】
【００４８】
１０−製品追跡システム
１２−オペレーティング・システム
１４−Java（登録商標）アーキテクチャ
１６−システム・マネージャ
１８−CIDテーブル・マネージャ
２０−VVSマネージャ
２２−照会マネージャ
２４−製品データベース
２６−追跡データベース
２８−CIDテーブル
３０−ベクトル・バージョニング・システムのデータ
３２−ネットワーク
【図１】
0004716758.tif 000002
【図２】
0004716758.tif 000003
【図３】
0004716758.tif 000004
【図４】
0004716758.tif 000005
【図５】
0004716758.tif 000006
【図６】
0004716758.tif 000007
【図７】
0004716758.tif 000008
【図８】
0004716758.tif 000009
【図９】
0004716758.tif 000010
【図１０】
0004716758.tif 000011
【図１１】
0004716758.tif 000012
【図１２】
0004716758.tif 000013