製品データ交換
製品データ交換システムは、複数の協力企業の各自のコンピュータシステム間の技術的製品データのやりとりに利用される。少なくとも協力企業の第１の企業のコンピュータシステムは、各自の技術的製品データを生成するため、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムを含む。システムはまた、複数のデータ管理システムからユーザ選択可能なプロジェクトに関する技術的製品データをインポートし、インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成し、他の協力企業の少なくとも１つにあるコンピュータシステムに交換パッケージを提供するための編集システムを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の協力企業の各自のコンピュータシステム間の技術的製品データをやりとりする製品データ交換システムに関する。本発明はさらに、協力企業間の技術的製品データをやりとりする方法に関する。
【背景技術】
【０００２】
多くの製品供給企業が、顧客、共同開発者、供給業者、委託製造業者、下請け業者、サービス企業などのグローバルネットワークにおいて機能している。各企業はさらに、共同開発者、供給業者、下請け業者などを有するかもしれない。例えば、家電機器の製造及びサービスは、
・装置全体の設計
・電子コンポーネント、ソフトウェアモジュール、ＩＣ及びメカニカルコンポーネントの開発
・電子コンポーネント、ソフトウェアモジュール、ＩＣ、メカニカルコンポーネント及びモジュールの製造／供給
・最終装置の組み立て
・装置のメンテナンス／サービス
のための複数の企業が関係するかもしれない。
【０００３】
製品のライフサイクルにおいて、適切なバージョン、適切な場所、適切な人及び適切なフォーマットによる対応する技術的製品データの利用性が、ビジネスにとって重要である。内部的には、ほとんどの企業は、各種データ管理システムを用いて製品データ及び関連するプロセスを管理し、自らの開発及び製造サイトを介し当該情報を配布する。このようなシステムの具体例として、コンピュータ支援設計／エンジニアリング（ＣＡＤ／ＣＡＥ／ＣＡＳＥ）システム（Ｕｎｉｇｒａｐｈｉｃｓ、Ｐｒｏ／Ｅｎｇｉｎｅｅｒ、ＡｕｔｏＣＡＤ、Ｃａｔｉａ、Ｍｅｎｔｏｒ Ｇｒａｐｈｉｃｓ、Ｃａｄｅｎｅｃｅ、Ａｎｓｙｓ、Ｃｏｎｔｉｎｕｕｓ、Ｔｅｌｅｌｏｇｉｃ Ｓｙｎｅｒｇｙ、ＣｌｅａｒＣａｓｅなど）、ＰＤＭ／ＰＬＭ（Ｐｒｏｄｕｃｔ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ／Ｐｒｏｄｕｃｔ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）システム（Ｍｅｔａｐｈａｓｅ、ＥＤＳ ＴｅａｍＣｅｎｔｅｒ、ｅＭａｔｒｉｘ、ＰＴＣ ＷｉｎｄＣｈｉｌｌ、ＳＡＰ／ＰＬＭ、ＩＢＭ Ｄａｓｓａｕｌｔ Ｅｎｏｖｉａなど）、ＥＲＰ／ＣＲＭ／ＣＳＭ／ＳＣＭ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ／Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ／Ｃｏｍｐｏｎｅｎｔ−ａｎｄ Ｓｕｐｐｌｉｅｒ Ｍａｎａｇｅｍｅｎｔ／Ｓｕｐｐｌｙ Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔ）システム（ＢａａＮ、ＳＡＰ、ＰｅｏｐｌｅＳｏｆｔ、Ａｓｐｅｃｔなど）があげられる。しかしながら、共同開発を促進し、外部パートナー（及びときには内部パートナー）とのチェーン通信を提供するため、技術的製品データの配布及び好感が必要とされる。技術的製品データは、好ましくは、すべての技術分野（ソフトウェア、機械、電子など）を含み、製品ライフサイクル全体をカバーする（すなわち、コンセプト設計から製品陳腐化まで）。企業間の業務データ（価格決定、発注、請求及び支払情報など）のやりとりのため、ｅコマース及びｂ２ｂコマースの規格が開発されている。
【０００４】
技術的製品データのやりとりについては、Ｎｅｍｉ（Ｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｎｉｃｓ Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｉｎｉｔｉａｔｉｖｅ，ｗｗｗ．ｎｅｍｉ．ｏｒｇ）及びＩＰＣ（Ａｓｓｏｃｉａｔｉｏｎ Ｃｏｎｎｅｃｔｉｎｇ Ｅｌｅｃｔｒｏｎｉｃ Ｉｎｄｕｓｔｒｉｅｓ，ｗｗｗ．ｉｐｃ．ｏｒｇ）によって、電子製造供給チェーン通信のＮｅｍｉ／ＩＰＣ Ｐｒｏｄｕｃｔ Ｄａｔａ ｅＸｃｈａｎｇｅ（ＰＤＸ）規格が開発されてきた。この規格は、元の装置メーカー、電子製造サービス及び電子分野の部品供給者の間の製造供給チェーン通信に着目したものである。当該規格は、これに従うデータ管理システム間の直接的なデータ交換を意図したものである（分散アプローチ）。非準拠システムの利用に関する規定は存在しない。
【０００５】
集中アプローチは、分散したグループのエンジニアリング及びプロジェクト管理作業を容易にするよう設計されたＳＡＰ ＣＥＰ（Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｅｎｇｉｎｅｅｒｉｎｇ ａｎｄ Ｐｒｏｊｅｃｔ ｍａｎａｇｅｍｅｎｔ ａｐｐｌｉｃａｔｉｏｎ）から知られている。ＣＥＰは、ＳＡＰの骨組みを用いて責任ある企業（イニシエータ）がプロジェクト関連情報を収集し、ビジネスパートナーによるアクセスのため当該情報を公開する協力環境である。それは、ウェブブラウザ（オンライン）を介しパートナーにＣＥＰアプリケーションに格納されているプロジェクト情報へのアクセスを提供する。ウェブブラウザにより、パートナーはＣＥＰシステムにログインし、イニシエータにより公開された情報を閲覧及び抽出することが可能である。割り当てられた情報をダウンロードするため、参加者はフォルダを選択し、そのコンテンツを自分のローカルＰＣにダウンロードする。ＣＥＰワークエリアは、材料の請求書、プロジェクトプラン及び関連文書などのフォルダ情報へのアクセス及びナビゲーションを可能にする。パートナーは、ダウンロードされた情報をオフラインにより変更することができ、当該変更による設定フォルダをオーナーのＩＴＳサーバにアップロードすることができる。イニシエータ（オーナー）サイトには、ＣＥＰ環境のオーナーのＳＡＰ変更及びライフサイクル管理アプリケーション群への緊密な統合が存在する。ＣＥＰによるデータ構造及び作業方法は、オーナーのＳＡＰシステムに基づくものとなる。ＣＥＰシステムは、外部パートナーがオーナーのＳＡＰシステム（の一部）において作業することを可能にする。それは、他のシステム（又は他のＳＡＰデータベース）をオーナーのＳＡＰシステムに結合し、あるいは複数のシステムの間のデータのやりとりを容易にする手段を提供するものではない。従って、ＣＥＰシステムは、パートナーにオーナーのＳＡＰシステムのデータ構造と作業方法による作業の実行を強制する。これは、データ構造及び作業方法がパートナー自身のＰＤＭ環境と適合しないかもしれないため問題となる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明の課題は、よりオープンな技術的製品データを交換するためのシステム及び方法を提供することである。
【課題を解決するための手段】
【０００７】
本発明の課題を満足させるため、協力企業の第１の企業の少なくとも１つのコンピュータシステムは、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムと、
前記複数のデータ管理システムからユーザ選択可能なプロジェクトに関する技術的製品データをインポートし、前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成し、前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する編集システムと、
を有する。
【０００８】
編集システムは、企業が相異なるデータ管理システムを利用し続け、関連するすべての技術的製品データを１つのパッケージに合成し、当該パッケージをパートナーに提供することを可能にする。データ管理システムは、１つの製品のためのものである必要はなく、また１つの規格に準拠する必要もない。最適化されたデータ管理システムが利用されてもよい。データ管理システムは、例えば、タスクについて最適化されてもよいし（機械部品の設計又はソフトウェアの設計など）、又は企業の価格／パフォーマンス／機能について最適化されてもよい（例えば、多国籍の本格的な分散システム及び開発途上国の小さな企業のシンプルなスタンドアローンシステムなど）。データ管理システムは、専用のものであってもよい。交換パッケージは、任意の適切な方法により提供されてもよい。一般には、一部の技術データファイル（ＣＡＤファイルなど）はその性質上大きなものであるため、パッケージは、例えば、１〜５００メガバイトなどの比較的大きなものとなるかもしれない。従って、パッケージは、好ましくは、ＣＤ−ＲＯＭなどの記録キャリアを介し、又はオフラインの電子ファイル転送を利用して提供される。パッケージは、その全体として転送される。パッケージの要素は、オンラインにより個別に選択及びダウンロードされる必要はない。
【０００９】
従属クレーム２の手段によると、前記協力企業の少なくとも１つのコンピュータシステムは、
技術的製品データに対し処理を実行するさらなるデータ管理システムと、
前記交換パッケージを抽出し、ユーザ選択可能な技術的製品データを前記交換パッケージから前記さらなるデータ管理システムにエクスポートする第２の編集システムと、
を有する。
【００１０】
このように、パッケージを受け取る企業は、それ自体のデータ管理システムを利用し続けることができる。エディタは、企業に関連があり、それのデータ管理システムによりインポート可能なパッケージの上記部分をユーザが抽出することを可能にする。
【００１１】
従属クレーム３の手段によると、前記協力企業の少なくとも１つのコンピュータは、前記交換パッケージを抽出し、前記抽出した交換パッケージの技術的製品データのユーザ選択可能部分をさらなる交換パッケージに合成し、前記さらなる交換パッケージを前記協力企業の少なくとも１つの下請け業者にあるコンピュータシステムに提供する第３の編集システムを有する。
【００１２】
このように、協力企業の「階層」を形成することができる。例えば、モジュールのサプライヤは、当該モジュールの部品の開発／供給をアウトソースするかもしれない。エディタは、企業がそのサプライヤに関連する部品のみを選択することを可能にする。
【００１３】
従属クレーム４の手段によると、前記編集システムは、
技術的製品データを前記交換パッケージに追加する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を削除する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を変更する制御処理と、
のうちの少なくとも１つをユーザが実行することを可能にするよう動作する。
【００１４】
従属クレーム５の手段によると、前記編集システムは、当該編集システムのユーザの制御処理を表すトレーサビリティデータを前記交換パッケージに自動的に挿入するよう動作する。編集システムのユーザは、異なるソースからデータを選択するため、ユーザは知識を追加する。ユーザの処理は、パッケージに記録され、これにより、その後、あるデータがなぜパッケージにあるか、又はないか確定することができる。
【００１５】
従属クレーム６の手段によると、前記トレーサビリティデータは、
追加された技術的製品データについては、該追加された技術的製品データの表示と、
削除された技術的製品データについては、該削除された技術的製品データの表示と、
変更された技術的製品データについては、前記もとの技術的製品データと変更された技術的製品データの両方の表示と、
を有する。このように、パッケージは自己完結的なものである。他のソースには、プロジェクトの関連するあらゆる技術的製品データを有することが照会される必要はない。トレーサビリティは、例えば、元の及び変更されたデータを完全にコピーすることによるなど、任意の適切な方法によりパッケージに搭載されてもよい。あるいは、変更のみが示されるようにしてもよい。
【００１６】
従属クレーム７の手段によると、前記編集システムは、前記複数のデータ管理システムから前記プロジェクトの同一のベースラインに関連する技術的製品データをインポートするよう動作する。ベースラインに関して、受信企業がそれに割り当てられたタスクを実行するのに必要なデータの同一バージョン／改訂に関する整合性があり、完全な技術的製品データ群を意味する。好ましくは、交換パッケージは、パッケージの受信者が、何れのバージョン／改訂が使用に適しているかについて困惑することを避けるため、１つのベースラインに関するデータのみを含む。このベースラインアプローチはまた、ファイルの更新されたバージョンが新たな全体的なベースライン状態に達しないときは交換されないため、ある協力作業中に製品データが交換される必要がある回数を限定する。それはまた、企業が、それ自体正確ではあるが、実際には組み合わされて使用されるべきではない異なるパートナーからの文書について作業するリスクを回避する。なぜなら、それらは異なるバージョンに関するものであり、互換性がないためである。
【００１７】
従属クレーム８の手段によると、前記協力企業の少なくとも１つのコンピュータシステムは、前記交換パッケージを抽出し、前記抽出した交換パッケージの前記技術的製品データの少なくとも１つのエンティティに関連する問題報告データを追加し、拡張された交換パッケージを構成し、前記拡張された交換パッケージを協力企業の少なくとも１つのコンピュータシステムに提供する第４の編集システムを有する。
【００１８】
このように、問題報告データは、問題が報告されたこと、それがどのエンティティに関連するものであるかをパートナーが観察することを可能にする同一のパッケージに搭載される。
【００１９】
従属クレーム９の手段によると、前記編集システムは、以前に提供された交換パッケージに表される技術的製品データに関する変更をカバーするデルタ記述の形式により、技術的製品データをさらなる交換パッケージに表し、前記以前に提供された交換パッケージへの参照を前記さらなる交換パッケージに含めるよう動作する。特に、変更が小さなものである場合、これは変更によるサイズ拡大を限定的なものに維持する。パートナーはより容易に変更を検出することができ、変更をパッケージの完全な以前のバージョンに適用することにより、それらは完全な更新されたバージョンを容易に抽出することができる。
【００２０】
従属クレーム１０の手段によると、前記データ交換パッケージは、ヘッダと、特定のＣＡＤフォーマットなどのデータ管理システムに固有のフォーマットにより技術的製品データを表す任意的な添付とを有する。例えば、ＣＡＤリソースファイル、ソフトウェア設計、回路ボードレイアウトなどは、すべて当該状況に関係するパートナーにより使用されるようなフォーマットにより添付されてもよい。明らかに、同じ状況に関係するパートナー（ＣＡＤシステムを利用した機械部品の設計、ＣＡＭシステムを利用した部品の製造など）が同一の内部フォーマットを用いて実行しない場合、変換が必要となるかもしれない。実際、このようなパートナーは、あるシステムがエクスポートでき、他方のシステムがインポート可能な共通にサポートされるフォーマットに通常は同意することができる。本発明によるシステムでは、同意された共通のフォーマットによる技術的製品データは、添付として交換パッケージに含めることができる。編集システムは、当該フォーマットを完全に解釈する必要はないが、解釈可能であってもよい。所望される場合、編集システムは、共通のフォーマットがパートナー間で同意可能でないインポート／エクスポート変換を実行するかもしれない。
【００２１】
従属クレーム１１の手段によると、前記交換パッケージの技術的製品データは、複数のエンティティに構成され、前記交換パッケージは、各エンティティについて、該エンティティのオーナーシップを有する前記協力企業の１つに関する情報を有し、前記編集システムは、ユーザの制御の下、前記交換パッケージのユーザ選択可能なエンティティのオーナーシップの前記協力企業の他の１つへの移転をトリガーするよう動作する。このように、ある企業から他の企業に製品管理システムの完全なコピーを要することなく、企業間で責任を変更することができる。このような移転は、例えば、製品のライフサイクル中に発生してもよく、例えば、製造企業からサービス企業に責任が移行される。移転はまた、企業が製品のそれの利害を他の企業に移行するときも行われるかもしれない。各エンティティについて、オーナーシップが別々に移転可能である。このように、異なる企業は異なる部品に責任があり、オーナーシップはフレキシブルに移転可能である（オーナーシップが下請け業者に一時的に移転することができる）。好ましくは、オーナーシップの移転は、現在のオーナーの表示、所望のオーナーの表示、及び所望のオーナーへのオーナーシップの移転日の表示を交換パッケージのヘッダのメタデータに含めることにより有効にされる。
【００２２】
従属クレーム１３の手段によると、前記ヘッダのメタデータは、前記プロジェクトのサブプロジェクトに関する状態情報を有し、前記編集システムは、データ管理システムからインポートされたデータ管理固有フォーマットによる状態情報を所定のフォーマットに変換するよう動作する。このように、従来のデータ管理システムは、状態を表示し続けることが可能であり、企業は内部の作業方法を変更する必要なく、パートナー間の良好な理解のため、共通の状態が使用される。
【００２３】
従属クレーム１４の手段によると、前記ヘッダのメタデータは、添付間の関係を表す情報を有する。各データ管理システムは、ときには複雑な固有の関係を有する多数のファイルをすでに有するかもしれない。多様なデータ管理システムからのファイルを１つのパッケージに単にコピーすることは、コンテンツをパートナーにとって理解を極めて困難なものにする。従って、パッケージの追加的情報は、文書間の構造／関係を示す。
【００２４】
従属クレーム１５の手段によると、前記関係は、前記ヘッダのメタデータは、開発者のタスク、メーカーのタスク、サプライヤのタスク又はサービス／メンテナンスのタスクなど、前記協力企業のタスクに関する情報を有する。多数の企業が関係するプロジェクト、特に複数の企業レイヤの階層に関するプロジェクトについて、関係及び関連する責任は明確ではないかもしれない。交換パッケージにタスク情報を明示的に追加することにより、このような問題は回避される。
【００２５】
従属クレーム１６の手段によると、前記ヘッダは、ＸＭＬフォーマットである。これは、専用のエディタを有しない企業が例えば、パッケージをローカルに開いた従来のウェブブラウザを用いて、交換パッケージからデータを抽出及び観察することを可能にする。
【００２６】
本発明の課題を満たすため、編集システムは、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートする手段と、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成する手段と、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する手段と、
を有する。
【００２７】
本発明の課題を満たすため、複数の協力企業の各コンピュータシステムの間の技術的製品データをやりとりする方法は、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートするステップと、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成するステップと、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供するステップと、
を有する。
【００２８】
本発明の課題を満たすため、コンピュータプログラムは、上記方法の各ステップをプロセッサに実行させるよう動作する。
【００２９】
本発明の上記及び他の特徴は、非限定的な例により、以降で説明される実施例を参照して明らかにされる。
【発明を実施するための最良の形態】
【００３０】
図１は、多数の協力企業によるプロジェクトの例を示す。当該プロジェクトは、家電機器などの製品の開発及び製造であるかもしれない。プロジェクトはまた、製品、特に業務用製品のメンテナンス／アフターサービスを含むものであってもよい。従って、プロジェクトは、製品のライフサイクル全体をカバーすることができる（すなわち、コンセプト設計から製品陳腐化まで）。所望される場合には、実際のアプリケーションでは、当該プロジェクトは、ライフサイクルの一部のみに限定されるかもしれない。本発明による交換システムは、技術的製品データのやりとりをカバーするものである。基本的に、技術的製品データは、すべての技術分野（ソフトウェア、機械、電子など）をカバーする。あるアプリケーションでは、必ずしもすべての分野に関与するとは限らないということは理解されるであろう。技術的製品データは、製品データ交換パッケージを用いてやりとりされる。本説明では、このパッケージは、技術的製品データのみに限定される。企業間の業務データ（価格決定、発注、請求及び支払情報など）の交換のため、他のｅコマースやｂ２ｂコマース規格及び交換機構が適用される。実際のアプリケーションではまた、業務データは本発明による交換パッケージに含まれることは理解されるであろう。図１の例では、新たな製品の主要なイノベーション（研究開発など）は、３つのサイトで行われる。イノベーションセンターは、ＩＮ１、ＩＮ２及びＩＮ３として示される。図に示される他のタイプの協力企業は、ＩＣサプライヤＩＣＳ、機械部品サプライヤＭＣＳ、電気部品サプライヤＥＣＳ、化学サプライヤＣＳ、モジュール／サブアセンブリサプライヤＭＳ、委託メーカーＣＭ及びプロジェクトオーナーの工場ＦＡＣＴである。実際のプロジェクトでは、これらの役割の一部は不要であるということは理解されるであろう。また、これらの役割の一部は、複数の協力企業により実行されてもよい。例えば、各々が異なる部品を供給したり、第２のソースとして機能するなど、４つの異なる機械部品サプライヤが関与するようにしてもよい。
【００３１】
実際、２つの協力企業が同一の親会社の一部である可能性があるということは理解されるであろう。例えば、家電（ＣＥ）製造企業は、このＣＥ企業に対するサプライヤ及び／又は共同開発者であるＩＣ製造企業を所有する親会社により所有されているかもしれない。図２は、プロジェクトへの協力のさらなる例を示す。この例では、５つの協力企業２１０、２２０、２３０、２４０及び２５０が関与する。この例では、企業２１０が指導的企業である。それは、構成管理２１２、製品文書管理２１４、問題報告２１６及び変更制御２１８の指導的役割を実行する。外部企業２２０は、機械設計２２２と電気設計２２４を主導する。企業２１０の内部の又は同一の親会社により所有される組織２３０は、ソフトウェア開発２３２を主導する。企業２４０は委託メーカーであり、企業２５０はＩＣサプライヤである。製品データ交換パッケージ２６０は、これらの企業が最適に協調することを保証する。
【００３２】
図３は、本発明による製品交換システム３００のブロック図を示す。本例では、６つのコンピュータシステム３１０、３２０、３３０、３４０、３５０及び３６０が示され、それぞれは各自の協力企業に配置される。基本的に、企業のこのようなコンピュータシステムは、すべて同じ場所に配置可能であるが、それらはまた地理的により分散化されてもよい。コンピュータシステムの少なくとも１つは、複数の相異なるデータ管理システムを有する。例えば、コンピュータシステム３１０は、３つの相異なるデータ管理システム３１２、３１４及び３１６を有する。ここで、「相異なる（ｄｉｓｔｉｎｃｔ）」とは、データ管理システムが、ＣＡＤ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ）、ＰＬＭ（Ｐｒｏｄｕｃｔ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、ＣＡＭ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ）などの異なる役割を実行し、及び／又はシステム間においてデータが自由にやりとり可能ではないという意味において、異なるタイプではあるが同一の役割を実行するということを意味する。各データ管理システムが、各技術的製品データを生成するのに利用される。当業者は、このようなシステムを知っており、このようなデータ管理システムに与えられる技術的データを知っている。例えば、ＣＡＤシステムは、タイトルブロックデータ、パーツリストデータ及びリソースファイルを供給し、ＰＬＭシステムは、技術仕様及び構成管理を供給し、ＥＲＰシステムは、物品マスターデータ及びパーツリストを供給するかもしれない。本説明の残りでは、このようなデータ管理システム（ＤＭＳ）はまた、ＰＤＭ（Ｐｒｏｄｕｃｔ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）システムと呼ばれる。各ＰＤＭシステムは、生成された技術的製品データの一部をアーカイブする機能を実行し、当該データの一部は、それ自体ＣＡＤワークステーション（図３には示されず）のような他のシステム上で生成されたものであるかもしれない。技術的製品データが、作業中の製品の製造に利用される。これは、電気的、機械的又は化学的特徴をカバーするだけでなく、当該製品の動作を制御し、又は当該製品の技術的機能特徴を実行する埋め込みソフトウェアをカバーする。コンピュータシステム３１０はまた、複数のデータ管理システム３１２、３１４及び３１６からユーザ選択可能なプロジェクトに関連する技術的製品データをインポートすることが可能な編集システム３１８を含む。各ＰＤＭシステムは、典型的には、複数のプロジェクトについてパラレル（又はシーケンシャル）に利用されるため、編集システム３１８は、ユーザがプロジェクトの１つを選択し、複数のシステムからプロジェクトのデータを自動収集することを可能にする。編集システム３１８は、これを実行することができるように、ハードディスク上などに追加的なデータを格納する必要があるかもしれない。このようなデータは、例えば、編集システム３１８がＰＤＭシステムから関連するデータを抽出することを可能にする情報にユーザ選択可能なプロジェクトの識別子をマッピングするようにしてもよい。このような情報は、ＰＤＭシステムに用いられるプロジェクト識別子であってもよいし、又はＰＤＭシステムの単なるファイル名リストであってもよい。編集システムのプロジェクトを選択する代わりとして、ユーザは、各データ管理システムにおいてプロジェクトを選択するようにしてもよい。編集システム３１８は、任意の適切な方法によりインポート処理を実行するようにしてもよい。例えば、編集システムは、ＰＤＭシステムにより用いられるデータモデルの知識を有し、この知識を用いてＰＤＭシステム（ＰＤＭシステムのデータベースなど）か直接当該データを抽出するようにしてもよい。ＰＤＭシステムはまた、編集システム３１８によりインポート可能な形式により関連するデータをエクスポートしたかもしれない。編集システム３１８は、インポートされた技術データのフォーマット変換を実行する必要があるかもしれない。以下でより詳細に説明されるように、編集システムは、好ましくは、メタデータをすべての協力企業により解釈可能なフォーマットによる交換パッケージに追加する。相異なるデータ管理システムが抽出する必要があるかもしれないメタデータの一部は、インポートされた技術データを構成し、このためフォーマット変換を伴うかもしれない。編集システム３１８は、インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成する。従って、編集システム３１８は、どのインポートされた技術データが表される必要があって、何れが表されるべきでないかユーザが選択することを可能にする。この選択は、例えば、特定の協力企業を対象とするものであってもよく、例えば、機械部品サプライヤは、ソフトウェア開発に関連するデータを必要とせず、その反対も考えられる。同様に、ＣＡＤファイルは、企業内の内部作業に関連するが、サプライヤには関係のないデータを有するかもしれない。技術データの表現は、直接的な複製又は変換を含む任意の適切な形式をとりうる。編集システム３１８は、交換パッケージをその他の協力企業の少なくとも１つに配置されるコンピュータシステムに提供する。それは、必ずしも必要ではないが、すべての協力企業にそれを供給するようにしてもよい。示されるように、それはまた、企業に固有のパッケージを１つの企業のみに供給するようにしてもよい。パッケージは大変大きなものである可能性があるため（例えば、５００メガバイト）、パッケージは、「オフライン」に供給される。好ましくは、パッケージはコンピュータネットワーク３７０を介し供給される。これは、ダイレクト／賃貸リンクであってもよいが、好ましくは、ブロードバンドインターネット接続が利用される。適切なインターネットプロトコルとして、ＨＴＴＰ／ＳＯＡＰ、ＦＴＰ又は電子メールがある。所望される場合、パッケージはまた、ＣＤ−Ｒ／ＲＷ又はＤＶＤ＋Ｒ／ＲＷなどの記録キャリアを介し供給されてもよい。好ましくは、パッケージはセキュアに提供することにより（例えば、記録キャリアを介し配布するため、インターネット内のＳＳＬや通常の暗号化技術を利用することにより）競争相手の望ましくない処理に対しプロテクトされる。
【００３３】
編集システムは、任意の適切な方法により実現されるようにしてもよい。典型的には、それは編集システムの機能が適切なプログラムによる制御の下でプロセッサ（図示せず）により実行される、ＰＣやワークステーションなどの通常のコンピュータ上で実現される。このプログラムは、ハードディスクやＲＯＭなどのバックグラウンドストレージ（図示せず）から、コンピュータのメインＲＡＭなどのワーキングメモリ又はプロセッサにロードされるようにしてもよい。ユーザは、入力用のキーボード／マウスと出力用のディスプレイ／プリンタなどの任意の適切なユーザインタフェース（図示せず）を介し編集システム３１８を制御することができる。特に、一実施例では、編集システムは、以下の制御処理の少なくとも１つをユーザに実行させる。
・技術的製品データの交換パッケージへの追加
・インポートされた技術的製品データのユーザ選択可能部分の削除
・インポートされた技術的製品データのユーザ選択可能部分の変更
例えば、ユーザはＰＤＭシステムに存在しない技術的製品データを追加してもよいし、又は編集システム３１８によりインポート可能な形式によりエクスポートすることはできない。ユーザは、パッケージが送信される協力企業に関係のないデータなど、技術データの一部を削除するかもしれない。ユーザはまた、ＰＤＭシステムにおいてまだ有効にされていない直近の変更を反映させるためなど、データのユーザ選択可能部分を変更するかもしれない。
【００３４】
本発明の実施例では、協力企業の少なくとも１つのコンピュータシステム３２０は、技術的製品データに対する処理のためのさらなるデータ管理システム３２２を有する。図３の例では、実際に、コンピュータシステム３２０は、３つのＰＤＭシステム３２２、３２４及び３２６を含む。コンピュータシステム３２０は、交換パッケージを抽出するための第２の編集システム３２８を含む。編集システム３２８は、選択可能な技術的製品データを交換パッケージからさらなるデータ管理システム３２２にエクスポートする。それはまた、技術的製品データをその他のＰＤＭシステム３２４と３２６にエクスポートするようにしてもよい。ユーザは、パッケージ内の何れのデータがエクスポートされるか制御することができる。編集システム３１８について説明されたインポート処理と同様に、編集システム３２８は、ＰＤＭシステムのデータベースに直接アクセスすることによりデータをエクスポートするようにしてもよい。複数のＰＤＭシステムが存在する場合、好ましくは、編集システム３２８は、選択されたデータが何れのＰＤＭシステムにエクスポートされるべきかユーザが指定するのを可能にする。当該データはまた、ファイルとしてエクスポートされてもよく、ＰＤＭシステムの通常のインポート機能を介しＰＤＭにロードされてもよい。編集システム３２８は、それがパッケージ内のデータとＰＤＭシステム内の対応するデータとを関連付けることを可能にするデータを必要とするかもしれない。編集システム３２８によるエクスポート処理もまた、データ変換を含むかもしれない。編集システム３２８は、ＰＤＭシステムからインポートし、ＰＤＭシステムへエクスポートすることが可能な多機能編集システムの編集システム３１８と結合されてもよい。所望の場合、協力企業には、企業がパッケージを生成するのでなく抽出することを可能にするなど、限定的な機能の編集システムに供給するようにしてもよい。
【００３５】
本発明の実施例では、協力企業の少なくとも１つのコンピュータシステム３３０は、第３の編集システム３３８を含む。図３の例では、それはまた、必要ではないがＰＤＭシステム３３２を含む。編集システム３３８は、交換パッケージを抽出する。ユーザの制御の下、編集システム３３８は、抽出された交換パッケージの技術的製品データのユーザ選択可能部分をさらなる交換パッケージに表す。それは、さらなる交換パッケージを協力企業の少なくとも１つの下請け業者に配置されるコンピュータシステム３６０に提供する。この協力企業は、例えば、システム３３０を有する企業の下請け業者であってもよい。このように、協力企業間の複雑な関係は、シンプルな方法により生成可能である。上述のように、この編集システム３３８は、編集システム３１８や３２８について説明されたような他の機能と結合される必要はないかもしれない。コンピュータシステム３６０を有する企業は、必ずしも必要ではないが、編集システム３６８とデータ管理システムを有するようにしてもよい。
【００３６】
編集システムのユーザ制御は自動化可能であるということは理解されるであろう。例えば、ユーザは、特定のタスクを一回実行可能であり（パッケージに表される必要があるＰＤＭシステムからインポートされるデータの選択など）、編集システムは、マクロの記録と同様に、以降において当該タスクを繰り返し、再びそれを実行することが可能であるかもしれない。ユーザはまた、スクリプト処理を用いるなど、ユーザ制御タスクを編集システムに「プログラム」してもよい。
【００３７】
図３は、編集システム３４０のさらなる利用を示す。この場合、協力企業のコンピュータシステムは、技術的製品データが編集システムによりエクスポート可能な、又は技術的製品データがインポート可能なＰＤＭシステムを含まない。代わりに、ユーザは、この編集システムを利用して、交換パッケージを抽出し、この交換パッケージのコンテンツを閲覧し、選択された部分をさらなる処理のため、ハードディスクなどのストレージシステムに格納し、及び／又は技術的製品データの選択された部分を印刷することができる。
【００３８】
一実施例では、データ交換パッケージは、ヘッダと、特定のＣＡＤフォーマットなどのデータ管理システムに固有のフォーマットにより技術的製品データを表す任意的な添付を含む。好ましくは、ヘッダはＸＭＬフォーマットによる。ヘッダは、以下でより詳細に説明されるようなメタデータを含むものであってもよい。ＸＭＬの使用は、協力企業がＭｉｃｒｏｓｏｆｔのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒなどの通常のインターネットブラウザを用いてパッケージを閲覧することを可能にする。これは、ブラウザを含むだけのコンピュータシステム３５０について示される。ブラウザにより、システムのユーザは、パッケージの一部を選択し、それらを格納及び／又は印刷することができる。これにより、選択された部分はまた、ＰＤＭシステムにインポートすることができる。一実施例では、本発明によるパッケージは、既存のオープンなデータ交換規格に基づく。特に、パッケージは、本発明による追加的機能が当該規格の拡張により達成可能な電子製造サプライチェーン通信であるＩＰＣ−２５７シリーズに対するＮｅｍｉ／ＩＰＣ Ｐｒｏｄｕｃｔ Ｄａｔａ ｅＸｃｈａｎｇｅ（ＰＤＸ）に基づくものであってもよい。一例となるパッケージの定義による特定の属性は、ＩＰＣ−２５７シリーズと同一のものであってもよい。これらの属性は、ここでは完全には規定されない。当該規格の属性定義は、参照することによりここに含まれる。
［ベースライン及びデルタパッケージ］
一実施例では、製品データ交換パッケージは、プロジェクトの直近の情報又はベースラインを含む。ベースラインは、一貫性を有する製品情報である。ベースラインの技術的製品データの各種バージョン及び改訂は、好ましくは、互いに一貫性を有する。パッケージは、技術的製品データの一のみの固有の改訂又はバージョンしか含まない。技術的製品データの複数の改訂又はバージョンは、好ましくは、同一のパッケージには表されない。なぜなら、何れの改訂が利用に適しているかは、受信機には明らかでないからである。例外は、以下で詳細に説明されるデルタパッケージの利用である。当該パッケージの発行者（すなわち、編集システム３１８を制御するユーザ）は、同一のベースラインパッケージをすべての協力企業に発行するようにしてもよい。これは、例えば、パッケージの大部分の情報がグローバルであるプロジェクトの開始において有用であるかもしれない。発行者はまた、受信者を対象とする、すなわち、受信者に関連するプロジェクトに技術的プロジェクトデータの選択のみを含むパッケージを発行するかもしれない。例えば、特定の機械部分のメーカーのみが、当該部分の製造に関連するデータを取得する必要がある。
【００３９】
製品情報を有するパッケージが配布されると、所有サイトの元の情報は変更されるかもしれない。好ましくは、変更は即座に通信はされない。代わりに、好ましいアプローチは、パッケージに受信者がオーナーが行ったすべての中間的な変更を知る必要なく、当該情報により作業可能となるように製品情報を収集することである。例えば、ソフトウェア開発プロセスでは、オーナーはパートナーにテスト用のバージョン「０．３」を配布する。そのとき、ソフトウェア開発者は、これらの更新をパートナーに配布することなく自らの作業を継続する（及びバージョン「０．４」と「０．５」が作成される）。最終的に、パートナーのテスト結果を受信し、これらをソフトウェアに搭載した後、オーナーはバージョン「０．６」を配布する。なぜなら、これがパートナーが興味を有する次のリリースであるからである。従って、元の情報から新たな情報を導くオーナーにより行われた中間ステップは、通信される必要がなくなる。
【００４０】
ある期間に生じた変更を配布するため、本発明によるデータ交換システムは、以下の２つのアプローチの少なくとも１つをサポートする。
・新たな情報のベースラインを有する新たな製品データ交換パッケージの配布、すなわち、関連する技術的製品データが、パッケージ自体に完全に表される。
・「デルタ」を有する製品データ交換パッケージの配布、すなわち、パッケージが送信された最近の時点からの変更がなされた情報のみの配布。所望の場合、「デルタ」はまた、直前のパッケージより以前のパッケージに規定されるものであってもよい。この場合、識別子（パッケージ名及び日付など）はデルタパッケージに含まれる。受信者は、デルタパッケージを用いて、自分のローカル情報を新たな情報のベースラインに更新する。
【００４１】
図４及び５において、デルタパッケージのコンセプトがさらに示される。図４において、時点ｔ１における関連する製品データは、送信者ＳＮＤから受信者ＲＣＶに送信された交換パッケージにおいて表される。時点ｔ２において、斜線のパターンｃｈを用いて示される変更が、製品データにおいて有効にされる。これらの変更のみを表すデルタパッケージが、ＳＮＤからＲＣＶに送信される。デルタパッケージは、元のパッケージを参照する。図５において、ＰＤＭシステムからの製品データは、パッケージ４２０として編集システムに供給される。ユーザの制御の下、編集システムは、アイテムを追加及び変更し、またパッケージのルート要素に影響を与える。トレーサビリティのため、変更及び追加されたアイテムをさらに含むパッケージ４３０が生成される。パッケージ４３０は、受信者ＲＣＶに供給される。受信者ＲＣＶにおける編集システムが使用され、さらなるアイテムが追加され、パッケージ４６０が生成される。受信者の選択により、更新されたパッケージ４６０の全体が、パッケージ４７０として元の送信者ＳＮＤに供給されてもよいし、あるいは、受信者ＲＣＶによりなされた変更を反映させたデルタパッケージ４８０が送信されてもよい。パッケージ４３０と４６０の変更を反映させたパッケージ４７０の全体が、ＰＤＭシステム４１０にフィードバックされてもよい。あるいは、デルタパッケージ４８０は、パッケージ４３０になされた変更を反映させるデルタパッケージと組み合わされてもよい。その後、組み合わされた変更はＰＤＭシステム４１０にインポートされる。
【００４２】
デルタパッケージは、パッケージの要素に関する以下の属性を用いて処理することができる。
【００４３】
【表１】
［パッケージ構造］
図６は、製品データ交換パッケージ６００に存在しうる以下の主要な要素の概略を与える。
・アイテム６１０は、（最終）製品、モジュール、（架空の（ｐｈａｎｔｏｍ））組立品、パーツ、部品などのそれの製品情報を管理するため組織が利用する一意的に識別されるエンティティを表す。それのライフサイクル中、複数の改訂及びバージョンが生成及び維持されるかもしれない。アイテムは、主として製品の有形部品を表す。アイテムはまた、埋め込みソフトウェア又は埋め込みソフトウェアモジュールを表すものであってもよい。これらのアイテムは、各自の特徴、材料６１２の単一レベル請求者や、アイテムの共同開発者、メーカー、サプライヤ、メンテナンス業者又はサービス提供者のタスク情報６１４と関連付けされる。
・文書６２０は、ファイル内にキャプチャされる１以上のアイテムに関する詳細な製品情報を含む業務文書を表す。具体例として、技術仕様、設計ソースファイル、図面ファイル、製造ファイル、プロジェクトファイル、品質文書、要求仕様及びプロジェクトレポートがあげられる。文書は、各自の文書構造を有することが可能である。さらに、各自の属性、ファイル及びアプリケーション情報並びにアイテムとの関係が、文書と関連付けされる。それのライフサイクル中、複数の改訂及びバージョンが作成及び維持されるかもしれない。
・問題レポート６３０は、現場での問題点、エンハンスメント要求などの通信用に使用される。問題レポートは、問題元、問題オーナー、問題の詳細及び問題の解決状況に関する情報を含む。問題レポートは、問題に影響を与えるアイテム６３２に関連付けされる。
・変更６４０は、変更要求、変更指示及び変更通知を表す。変更の具体例として、エンジニアリング変更、部品リスト変更などがあげられる。変更は影響を与える文書及びアイテムに関連付けされる。さらに、それらは、解決する問題レポート６４４と変更を承認する者６４６と関連付けされる。
【００４４】
従来、異質な設計データ管理システム（ＣＡＤ−ＰＤＭデータベースとファイルサーバなど）の間の複数の設計オーサリングシステム（ＭＣＡＤ、ＥＣＡＤ、ＣＡＳＥツールなど）からのソースデータの交換は、
・ソースファイル間の複雑な相互関係
・ファイルバージョン及び改訂の管理
・ソースが、派生されるデータファイル（各プロット形式による図面及び３次元閲覧ファイルなど）の生成に利用される。派生ファイルと元のソースデータとの間の相互関係が維持される必要がある。
・設計構造は、しばしば製品構造構成情報と部分的に適合するが、完全には適合しない。
による問題がある。
【００４５】
この複雑さは、他の添付と関係することなくファイルがシンプルな添付として実現される最新のオープンな製品データ交換規格により解決されるものではない。技術的製品データ構造の有効なやりとりのため、交換パッケージは、以下の方法の少なくとも１つにより各構造を備える。
・設計ソースファイル（設計オーサリングツールの専用フォーマットによるファイル）は、特殊な文書タイプである設計ソース文書として表される。これは、パッケージの「文書」要素の属性「ｄｅｓｉｇｎＳｏｕｒｃｅＤｏｃｕｍｅｎｔ」を用いることにより実現される。この属性は、設計ソース文書については「ｙｅｓ」、他のすべてのタイプの文書については「ｎｏ」と設定される。
・派生ファイル（例えば、閲覧、印刷、製造用のため、複数のアプリケーションによりサポートされるフォーマットによりソース設計から生成されるファイル）は、文書として表される。
・各文書及び設計ソース文書は、パッケージの属性により表される自らの改訂及びバージョン表示を有する。
・各設計ソース文書は、元の設計オーサリング環境からの以下の情報の少なくとも１つ、すなわち、アプリケーション名、アプリケーションバージョン、ファイル位置の（相対）パス情報を有する。
・設計ソース文書間の「ＢｉｌｌＯｆＤｏｃｕｍｅｎｔｓＩｔｅｍ」関係は、ソース設計の階層、すなわち、設計オーサリングツールにおける処理のため、何れのソースファイルが他の何れのソースファイルを必要とするかを記述する。
・設計ソース文書と文書との間の「ＤｅｒｉｖｅｄＦｒｏｍＦｉｌｅ」関係は、文書が何れのソース設計ファイルから派生されたものであるかを記載する。
・アイテムと設計ソース文書との間の「ＳｐｅｃｉｆｉｅｓＩｔｅｍ」関係は、関連する文書が何れのアイテムに関する詳細情報を有するか記述している。
・設計階層の頂点のパッケージにある設計ソース文書は、もとになるバージョン及び改訂の構成に関する情報を含む。
【００４６】
図７において、パッケージＰｃｋｇの具体例が示される。それは、送信者情報（Ｆｒｏｍ：．．．）、受信者情報（Ｔｏ：．．．）、及び「ここに、私たちのボードの仕様がある」などの任意的な指示／コメントフィールド（Ｉｎｓｔ：）を含む。このパッケージは、製品識別子（Ｐｒｏｄ ｉｄ）、改訂番号（Ｒｅｖ）、説明（Ｄｅｓｃ）及びオーナー（Ｏｗｎ）を有する１つのアイテムＩｔを含む。このアイテムはさらに、各々が各自のフィールドと添付ファイル（Ｆｌｓ）を有する２つの文書Ｄｏｃにより特定される。
［オーナーシップ］
製品データのやりとりは、技術的製品データのコピーが複数の場所に配布される状況をもたらす。元の情報マスターが保持される位置が知られていることが好ましい。一実施例では、製品データ交換パッケージは、オーナーをパッケージの主要な要素に割り当てることによりこの情報を備える。オーナーは、配布された製品情報のマスターを保持及び維持する者又は組織である。好ましくは、製品データ交換パッケージでは、オーナーはアイテム、文書、変更及び問題レポートに割り当てられる。
【００４７】
アイテムのオーナーは、好ましくは、
・アイテムの特徴及び属性
・材料の（単一レベル）請求書 材料の請求書に出現するアイテムは各自のオーナーを有する可能性があることに留意されたい。
・アイテムに関連付けされたタスク情報
を含むすべての基礎となる要素のオーナーである。
【００４８】
文書のオーナーは、好ましくは、
・文書の特徴及び属性
・ファイル及び添付情報
・文書の（単一レベル）請求書 文書の請求書に出現する文書は各自のオーナーを有する可能性があることに留意されたい。
・文書に直接的に関連付けされた開発者のタスク情報
・アイテムとのリンク（「アイテム指定」要素による）
・派生ファイルとのリンク（「ファイルからの派生」要素による）
を含むすべての基礎となる要素のオーナーである。
【００４９】
変更のオーナーは、好ましくは、
・影響を受けるアイテム及び文書とのリンク（「影響を受けるアイテム」及び「影響を受ける文書」要素による）
・解決された問題レポートとのリンク（「解決された問題」要素による）
を含むすべての基礎となる要素のオーナーである。
【００５０】
問題レポートのオーナーは、好ましくは、影響を受けるアイテム（「影響を受けるアイテム」要素による）とのリンクを有するすべての基礎となる要素のオーナーである
オーナーシップ情報は、複数のオーナーからの製品情報が、単一の製品データ交換パッケージにおいて通信されることを可能にする。好ましくは、この情報のオーナーは、変更の配布の責任を有する。これは、以下の図に示される。パートナーとの共同作業中、製品情報のオーナーシップは、１つのサイトから他のサイトにシフトされてもよいということに留意されたい。オーナーシップがシフトすると、新たなオーナーがまた、情報に関してなされた変更を配布する責任を有することとなる。
【００５１】
パートナーとの共同作業中、製品情報のオーナーシップは、１つのサイトから他のサイトにシフトするかもしれない。図８において、一例となるシナリオが与えられる。本例では、ＯＥＭ８００がモジュールを規定する。ＯＥＭ８００内の状態は、システム開発８０２、先行製造８０４及び大量製造８０６であるかもしれない。ＯＥＭは、モジュールのエンジニアリングをモジュール開発者８１０に、それの試験製造を委託メーカー８２０にアウトソースする。モジュール開発者は、対応する製品情報のオーナーとなる。移転後、モジュール開発者は、モジュールのマスター情報と、ＯＥＭ及び委託メーカーへの変更による更新の配布の責任を有する。試験製造段階後、オーナーシップは、モジュールについての責任を継承したＯＥＭに移転される。オーナーシップの移転は、→８３０により示される。その他の矢印は、モジュール製品データの配布を示している。モジュール開発者８１０は、主要な状態として、モジュール開発８１２、サンプル８１４及び試験製造８１６を有するかもしれない。斜線は、図面においてオーナーシップを示す。
【００５２】
本発明によるシステムの一実施例では、オーナーシップの移転を通信するため、以下の情報が製品データ交換パッケージにおいて、ＩＰＣ規格により規定される現在の情報に加えて移転されるアイテム及び／又は文書に追加される。
・属性「オーナーの委託への移転一意的識別子」による新たなオーナー
・属性「オーナー日付の移転」によるオーナーシップの移転が有効となる日付
【００５３】
【表２】
オーナーシップを移転することにより、両方のパートナーは好ましくは、
・送信者が、他のサイトにより所有される製品情報として、オーナーシップが移転された製品情報を扱う。
・受信者が、マスター情報のオーナーとなり、変更による更新を配布する。
ことに同意する。
［問題報告］
開発及び供給チェーンを介した問題（エンハンスメント要求、現場の問題など）の通信が、すべてのビジネスパートナーが適切に応答、通信及び解決策を実現することを可能にするため、可能な限り早急に確立されることが望まれる。本発明による一実施例では、問題レポートが生成され、交換パッケージに含めることができる。好ましくは、当該チェーンのすべての者が問題レポートを生成可能である。問題レポートの作成者は、問題元と呼ばれる。問題元は、必ずしも「問題オーナー」である必要はない。パートナー間の協調モデルに応じて、問題元は問題レポートを何れに送信するか決定されてもよい。例えば、問題レポートは、ＯＥＭにより集中的に収集及び管理されてもよく、また、問題レポートが影響を受けるモジュールの各オーナーに直接提出される分散モデルが同意されてもよい。問題を解決するのに割り当てられた者又は組織が、問題オーナーとなる。問題オーナーは、問題を処理する責任を有する。さらに、問題オーナーは、問題の解と状況をパートナーに通信する責任を有する。図９において、このことがさらに示される。図２において、２つの問題レポートＰＲ１とＰＲ２は、すでにクローズされ、各自の問題の解Ｐ．Ｒｅｓ１とＰ．Ｒｅｓ２が含まれる。問題レポートＰＲ３は変更を要求したが、ＢＯＭ（Ｂｉｌｌ ｏｆ Ｍａｔｅｒｉａｌ）マークアップによる提案された変更ＣＨはまだ承認されていない。問題の通信は、好ましくは、以下の方法により有効とされる。
・問題レポートは、開発又は製造チェーンのすべての者により配布可能である。問題レポートは、問題の説明、詳細の添付及び問題レポートの発信元からのコンタクト情報を含む。
・問題レポートは、常に１以上の影響を受けるアイテムと関連付けされる必要がある。
・各問題レポートは、問題オーナーを取得する。問題オーナーは、問題を処理する責任を有する。異なる応答、すなわち、問題レポートの状況の変更、問題への解法情報への直接的な添付とビジネスパートナーへの解法の通信、１以上の問題を解決するのに必要とされる変更の開始、及びビジネスパートナーによる確認／検証／承認のため、ビジネスパートナーへ通知するための変更の通信が可能である。
・変更は、当該変更において解決される問題へのリンクト、影響を受けるアイテムへのリンクを含む変更要求／変更指示／変更留意情報を記載する。
【００５４】
交換パッケージの問題レポートは、エンティティ「ＰｒｏｂｌｅｍＲｅｐｏｒｔ」を規定することにより処理することができる。以下のテーブルは、オープンな製品データ交換規格による「Ｐｒｏｂｌｅｍ Ｒｅｐｏｒｔ」の実施例に対する可能な属性を指定する。
【００５５】
【表３】
「ＡｆｆｅｃｔｅｄＩｔｅｍｓ」と「ＡｆｆｅｃｔｅｄＩｔｅｍ」要素は、ＰｒｏｂｌｅｍＲｅｐｏｒｔ ｔｏ Ｉｔｅｍｓに関連付けるのに用いられる。
［プロセス状態］
本発明による実施例では、システムは共同開発及びサプライチェーン通信における製品データ交換を利用したパートナーが、自らの内部プロセスに従うことを可能にすることをサポートする。図８において、このことがまた示される。パートナー間の協調モデルは、何れの情報が何れの段階及びマイルストーン中にやりとりされるか規定し、これにより、各パートナーは、適切な時点において必要な入力を有することとなる。パッケージは、パートナーがそのやりとりにおいて製品及び文書のためのそれの内部識別コードを利用することを可能にする。パッケージにおいて、同一の製品又は文書に用いられる異なるコードが関連付けすることが可能である。製品及び文書のライフサイクルの状態（「ドラフト」、「製造のためリリース済み」など）を示すため、オーナーは２つのオプションを有する。
・送信者と受信者が同じ言語を用いてやりとりされる情報の期限を示すことができるように、オーナーの内部状態の所定の状態リストへのマッピング
・オーナーのサイトの状態のパッケージへの直接的な搭載
さらに、オーナーのサイトにおける動作状態を示す（サブ）プロジェクトの状態が、同様の方法によりパッケージに表されてもよい。所定の状態リストは、すべての協力企業について規定された同一の意味を有する。一実施例では、編集システムは、内部状態（協力企業の１つの内部に規定された、又はＰＤＭシステムにより規定されたものなど）を所定の状態に変換することが可能である。このため、ユーザは、編集システムが変換を自動的に実行することができるように、編集システム内に変換テーブルを規定するようにしてもよい。変換は完全なものではないかもしれないため、好ましくは、受信サイトの編集システムは、追加的なフィールドによりオーナーからの状態情報を可視化する。このフィールドはまた、ローカル状態情報に加えて、ＰＤＭシステムにエクスポートされてもよい。ほとんどの場合、送信者からの状態情報を受信者のライフサイクルプロセスにマッピングすることは意味がない。なぜなら、送信者と受信者は異なるプロセスに従うためである。
［タスク情報］
一実施例では、分散された製品データにより実行される必要があるタスクは、製品データ交換パッケージにおいて通信される。この情報を通信する目的は、すべてのパートナーがその他のパートナーの責任により通知可能であるということである。タスク情報は、
・業務パートナーが作業の中断により自らのタスクの範囲内において製品開発データを交換することを可能にする「作業中断」構造の設定
・拡張された事業の問題通知及び変更処理 タスク情報は、何れの者が関連する製品情報が重要となるタスクについて責任を有するか示す。従って、関連する製品の問題レポート及び変更について更新されるタスクに割り当てられるすべての主体を維持することが推奨される。
・データパッケージのさらなる分散される必要がある部分へのサプライチェーンの上流及び下流方向への分割のために利用可能である。
【００５６】
以下の４つのタイプのタスクが区別されてもよい。
・開発者のタスク：製品（モジュール）を開発及びエンジニアリングするためのタスク及び開発データのメンテナンス
・メーカーのタスク：仕様に従う製品（モジュール）の製造又は組み立てタスク 割り当てられたモジュールのサブモジュールは、他のメーカーにアウトソースすることができる。
・サプライヤのタスク：製品（モジュール）を供給するタスク サプライヤのタスクは、メーカー及びサプライヤが同一のコンタクトでない場合割り当てられる。例えば、キャパシタは、フィリップスにより製造され、小売業者により供給されてもよい。
・サービス／メンテナンスタスク：顧客への供給後の製品（モジュール）のアフターサービス／メンテナンスのためのタスク
タスク情報をやりとりする好適な方法は、以下の通りである。
・開始時に、すべてのパートナーに自分の及びその他のパートナーのタスク情報が通知される。これは、製品の主要モジュールと各自の開発、製造、サプライヤ、サービス／メンテナンスタスクを含む製品データ交換パッケージを配布することにより達成される。
・チェーン内のパートナーは、他の何れのパートナーが各自の製品情報を受信しなければならないか判断するため、分散された「作業中断構造」を利用する。さらに、タスク情報は、中断及び供給チェーンの（サブ）委託者へのさらなる配布を可能にするため、製品データ交換パッケージに含まれる。
・タスク情報において変更が発生すると、例えば、あるアイテムの好適なメーカーのリストが１つの好適なメーカーに絞られるなどすると、対応するアイテムのオーナーは、これらのタスク変更をその他のパートナーに通信する責任がある。基本的には、すべてのパートナーがタスクの変更を通知されるべきである。
【００５７】
オーナー情報により、パッケージの受信者は、当該情報についての責任ある主体を決定することができる。
【００５８】
本発明の実施例では、タスク情報は、ＩＰＣ−２５７８規格からの「ＡｐｐｒｏｖｅｄＭａｎｕｆａｃｔｕｒｅｒＬｉｓｔ」及び「ＡｐｐｒｏｖｅｄＳｕｐｐｌｉｅｒＬｉｓｔ」要素を用いて、
・「ＡｐｐｒｏｖｅｄＤｅｖｅｌｏｐｅｒＬＩｓｔ」要素
・「ＤｅｖｅｌｏｐｅｒＰａｒｔ」要素
を追加することにより、パッケージに組み込まれる。
［デルタパッケージの詳細］
デルタパッケージは、エンティティ（タスク情報など）及び属性に応じて、変更されたすべてのアイテム、文書、変更、問題レポート及びそれらの基礎となる要素を含むかもしれない。例えば、アイテムの１つの属性フィールドのみが変更された場合、基礎となるすべての要素及び属性を有する完全なアイテム要素が、デルタパッケージにおいて交換されることに留意されたい。
【００５９】
デルタパッケージは、新たなエンティティ「Ｄｅｌｔａ」を定義することにより生成可能である。このＤｅｌｔａエンティティは、「ＤｅｌｔａＮｅｗ」と「ＤｅｌｔａＯｌｄ」の２つの基礎となる要素を有する。「ＤｅｌｔａＮｅｗ」要素は、変更されたアイテム、文書、変更などを含む。受信者は、これらの要素を用いて以前に受信した情報を更新することができる。「ＤｅｌｔａＯｌｄ」要素は、変更された元のアイテム、文書、変更などを含む。デルタパッケージをやりとりするため、この要素は任意的なものである（受信者は、すでにこの情報を有するため）。当該要素の主な目的は、以下で詳細に説明されるトレーサビリティである。
【００６０】
以下のテーブルは、オープンな製品データ交換規格の一実施例のための「ＤｅｌｔａＯｌｄ」及び「ＤｅｌｔａＮｅｗ」要素の可能な属性を指定する。
【００６１】
【表４】
［トレーサビリティ］
製品コンテンツが拡張された事業を移動するとき、手動による更新プロセスによる情報の変更に対する制御は失われるかもしれない。解決しなければならない問題は、
・送信者のＰＤＭシステムからの選択及びダウンロード後、製品データは、パッケージの送信前に編集システムにおいて変更されてもよい。
・パッケージの受信後、受信者は、それの編集システムを用いてパッケージコンテンツを変更するようにしてもよい。
である。
【００６２】
ある環境において、ある協調モデルにおいては、すべての変更が追跡可能であることが必要とされることが要求されるかもしれない。トレーサビリティ要求を満たすため、以下の情報を追跡することが好ましい。
・パッケージへの製品データベースから製品データを抽出するのに利用されるエクスポートクエリ
・編集システムを用いてパッケージに行われた変更
トレーサビリティ情報は、以下の方法により利用可能である。
・トレーサビリティ情報は、送信者により保持され、送信されたパッケージのコピーを保持する必要なく送信されたパッケージを登録するのに利用可能である。
・トレーサビリティ情報は、パッケージに搭載可能である。パッケージの受信者は、（エディタにおいて）パッケージ送信前にどのような変更がなされたか確認することができる。
【００６３】
トレーサビリティデータは、
・追加された技術的製品データについて：追加された技術的製品データの表示
・削除された技術的製品データについて：削除された技術的製品データの表示
・変更された技術的製品データについて：元のものと変更された技術的製品データの両方の表示
を含む。
【００６４】
これは、上述された「デルタ」要素を利用することにより実行可能である。アイテム、文書、変更、問題レポート、コンタクト、パッケージのメーカー部分、サプライヤ部分又は開発部分が最初に変更されるとき、元の要素は、好ましくは、パッケージの「ＤｅｌｔａＯｌｄ」要素にコピーされる。もとの情報がこのように確保された後、パッケージの要素が編集可能である。このため、「ＤｅｌｔａＯｌｄ」要素は、すべての元の及びそれらの基礎となる要素と属性を含むこととなる。要素が編集される場合、これは、追加的な属性要素「ｄｅｌｔａＥｄｉｔＳｔａｔｕｓ」（それは、「Ｅｄｉｔｅｄ」の値を受け取る）と、「ｄｅｌｔａＯｌｄＩｔｅｍＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ」（「ｄｅｌｔａＯｌｄ」下の対応する要素へのポインタを含む）により示すことができる。このようにして、元の要素と最近編集された要素のみがパッケージに格納される。送信前に複数回要素が編集されたときに発生した可能性のある中間状態は、保持されない。新たな要素がパッケージに生成される場合、例えば、新たなアイテムが製品構造に追加され、又は新たな文書が作成された場合、これは、「Ａｄｄｅｄ」の値を受け取る追加的な属性「ｄｅｌｔａＥｄｉｔＳｔａｔｕｓ」により示される。図５は、パッケージのトレーサビリティ情報がどのように利用可能であるか示す。送信者は、新たなパッケージを生成し、このパッケージを編集する。トレーサビリティのため、送信者は、編集のデルタパッケージと抽出データを保持する（従って、送信者は、常に変更されたパッケージのコピーを保持する必要なくパッケージを再生成することができる）。受信すると、受信者は、パッケージに対するさらなる編集を行う。編集後、受信者は、完全なパッケージを（編集された要素と古い要素と共に）送信し、又は、更新を含むデルタパッケージを送信することができる。何れのアプローチでも、編集されたデータは、送信者のデータ管理システムにフィードバックすることができる。
【００６５】
本発明はまた、コンピュータプログラム、特に本発明を実現するよう構成されたキャリア上のコンピュータプログラムに拡張されるということは理解されるであろう。このプログラムは、ソースコード、オブジェクトコード、部分的にコンパイルされた形式などによるコード中間ソースオブジェクトコードの形式、又は本発明による方法の実現に利用するのに適した他の任意の形式によるものとされてもよい。キャリアは、プログラムを搬送可能な任意のエンティティ又は装置である。例えば、このキャリアは、ＲＯＭ、ＣＤ−ＲＯＭ、半導体ＲＯＭなどの記憶媒体、又はフロッピー（登録商標）ディスクやハードディスクなどの磁気記録媒体を有するものであってもよい。さらに、キャリアは、電気又は光ケーブル、無線又は他の手段を介し伝達可能な電気又は光信号などの送信可能なキャリアであってもよい。プログラムがこのような信号に実現されるとき、キャリアは、このようなケーブルや他の装置又は手段により構成されてもよい。あるいは、キャリアは、プログラムが埋め込まれ、本方法の実行に利用され、又は本方法を実行するよう構成された集積回路であってもよい。
【００６６】
上述の実施例は、本発明を限定するものではなく、例示するためのものであり、添付された請求項の範囲から逸脱することなく当業者は他の多数の実施例を設計可能であるということに留意すべきである。請求項では、括弧内の任意の参照符号は、請求項を限定するものとして解釈されるものではない。動詞「有する」とそれの派生語の使用は、請求項に記載された以外の要素又はステップの存在を排除するものではない。要素に前置される「ある」という冠詞は、当該要素が複数存在することを排除するものではない。本発明は、複数の要素を有するハードウェアにより、また適切にプログラムされたコンピュータにより実現されてもよい。複数の手段を列挙した装置クレームでは、これらの手段のいくつかが単一の同一ハードウェアにより実現されてもよい。ある手段が相互に異なる従属クレームに記載されているという事実は、これらの手段の組み合わせが効果的に利用可能でないことを示すものではない。
【図面の簡単な説明】
【００６７】
【図１】図１は、企業間の世界的な協調を示す。
【図２】図２は、協力企業間の製品データ交換を示す。
【図３】図３は、本発明によるシステムのブロック図を示す。
【図４】図４は、製品データ交換のためのデルタパッケージの利用を示す。
【図５】図５は、デルタパッケージのさらなる利用を示す。
【図６】図６は、製品データ交換パッケージの構造を示す。
【図７】図７は、一例となるパッケージを示す。
【図８】図８は、オーナーシップの移転を示す。
【図９】図９は、問題報告を示す。
【技術分野】
【０００１】
本発明は、複数の協力企業の各自のコンピュータシステム間の技術的製品データをやりとりする製品データ交換システムに関する。本発明はさらに、協力企業間の技術的製品データをやりとりする方法に関する。
【背景技術】
【０００２】
多くの製品供給企業が、顧客、共同開発者、供給業者、委託製造業者、下請け業者、サービス企業などのグローバルネットワークにおいて機能している。各企業はさらに、共同開発者、供給業者、下請け業者などを有するかもしれない。例えば、家電機器の製造及びサービスは、
・装置全体の設計
・電子コンポーネント、ソフトウェアモジュール、ＩＣ及びメカニカルコンポーネントの開発
・電子コンポーネント、ソフトウェアモジュール、ＩＣ、メカニカルコンポーネント及びモジュールの製造／供給
・最終装置の組み立て
・装置のメンテナンス／サービス
のための複数の企業が関係するかもしれない。
【０００３】
製品のライフサイクルにおいて、適切なバージョン、適切な場所、適切な人及び適切なフォーマットによる対応する技術的製品データの利用性が、ビジネスにとって重要である。内部的には、ほとんどの企業は、各種データ管理システムを用いて製品データ及び関連するプロセスを管理し、自らの開発及び製造サイトを介し当該情報を配布する。このようなシステムの具体例として、コンピュータ支援設計／エンジニアリング（ＣＡＤ／ＣＡＥ／ＣＡＳＥ）システム（Ｕｎｉｇｒａｐｈｉｃｓ、Ｐｒｏ／Ｅｎｇｉｎｅｅｒ、ＡｕｔｏＣＡＤ、Ｃａｔｉａ、Ｍｅｎｔｏｒ Ｇｒａｐｈｉｃｓ、Ｃａｄｅｎｅｃｅ、Ａｎｓｙｓ、Ｃｏｎｔｉｎｕｕｓ、Ｔｅｌｅｌｏｇｉｃ Ｓｙｎｅｒｇｙ、ＣｌｅａｒＣａｓｅなど）、ＰＤＭ／ＰＬＭ（Ｐｒｏｄｕｃｔ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ／Ｐｒｏｄｕｃｔ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）システム（Ｍｅｔａｐｈａｓｅ、ＥＤＳ ＴｅａｍＣｅｎｔｅｒ、ｅＭａｔｒｉｘ、ＰＴＣ ＷｉｎｄＣｈｉｌｌ、ＳＡＰ／ＰＬＭ、ＩＢＭ Ｄａｓｓａｕｌｔ Ｅｎｏｖｉａなど）、ＥＲＰ／ＣＲＭ／ＣＳＭ／ＳＣＭ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ／Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ／Ｃｏｍｐｏｎｅｎｔ−ａｎｄ Ｓｕｐｐｌｉｅｒ Ｍａｎａｇｅｍｅｎｔ／Ｓｕｐｐｌｙ Ｃｈａｉｎ Ｍａｎａｇｅｍｅｎｔ）システム（ＢａａＮ、ＳＡＰ、ＰｅｏｐｌｅＳｏｆｔ、Ａｓｐｅｃｔなど）があげられる。しかしながら、共同開発を促進し、外部パートナー（及びときには内部パートナー）とのチェーン通信を提供するため、技術的製品データの配布及び好感が必要とされる。技術的製品データは、好ましくは、すべての技術分野（ソフトウェア、機械、電子など）を含み、製品ライフサイクル全体をカバーする（すなわち、コンセプト設計から製品陳腐化まで）。企業間の業務データ（価格決定、発注、請求及び支払情報など）のやりとりのため、ｅコマース及びｂ２ｂコマースの規格が開発されている。
【０００４】
技術的製品データのやりとりについては、Ｎｅｍｉ（Ｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｎｉｃｓ Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｉｎｉｔｉａｔｉｖｅ，ｗｗｗ．ｎｅｍｉ．ｏｒｇ）及びＩＰＣ（Ａｓｓｏｃｉａｔｉｏｎ Ｃｏｎｎｅｃｔｉｎｇ Ｅｌｅｃｔｒｏｎｉｃ Ｉｎｄｕｓｔｒｉｅｓ，ｗｗｗ．ｉｐｃ．ｏｒｇ）によって、電子製造供給チェーン通信のＮｅｍｉ／ＩＰＣ Ｐｒｏｄｕｃｔ Ｄａｔａ ｅＸｃｈａｎｇｅ（ＰＤＸ）規格が開発されてきた。この規格は、元の装置メーカー、電子製造サービス及び電子分野の部品供給者の間の製造供給チェーン通信に着目したものである。当該規格は、これに従うデータ管理システム間の直接的なデータ交換を意図したものである（分散アプローチ）。非準拠システムの利用に関する規定は存在しない。
【０００５】
集中アプローチは、分散したグループのエンジニアリング及びプロジェクト管理作業を容易にするよう設計されたＳＡＰ ＣＥＰ（Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｅｎｇｉｎｅｅｒｉｎｇ ａｎｄ Ｐｒｏｊｅｃｔ ｍａｎａｇｅｍｅｎｔ ａｐｐｌｉｃａｔｉｏｎ）から知られている。ＣＥＰは、ＳＡＰの骨組みを用いて責任ある企業（イニシエータ）がプロジェクト関連情報を収集し、ビジネスパートナーによるアクセスのため当該情報を公開する協力環境である。それは、ウェブブラウザ（オンライン）を介しパートナーにＣＥＰアプリケーションに格納されているプロジェクト情報へのアクセスを提供する。ウェブブラウザにより、パートナーはＣＥＰシステムにログインし、イニシエータにより公開された情報を閲覧及び抽出することが可能である。割り当てられた情報をダウンロードするため、参加者はフォルダを選択し、そのコンテンツを自分のローカルＰＣにダウンロードする。ＣＥＰワークエリアは、材料の請求書、プロジェクトプラン及び関連文書などのフォルダ情報へのアクセス及びナビゲーションを可能にする。パートナーは、ダウンロードされた情報をオフラインにより変更することができ、当該変更による設定フォルダをオーナーのＩＴＳサーバにアップロードすることができる。イニシエータ（オーナー）サイトには、ＣＥＰ環境のオーナーのＳＡＰ変更及びライフサイクル管理アプリケーション群への緊密な統合が存在する。ＣＥＰによるデータ構造及び作業方法は、オーナーのＳＡＰシステムに基づくものとなる。ＣＥＰシステムは、外部パートナーがオーナーのＳＡＰシステム（の一部）において作業することを可能にする。それは、他のシステム（又は他のＳＡＰデータベース）をオーナーのＳＡＰシステムに結合し、あるいは複数のシステムの間のデータのやりとりを容易にする手段を提供するものではない。従って、ＣＥＰシステムは、パートナーにオーナーのＳＡＰシステムのデータ構造と作業方法による作業の実行を強制する。これは、データ構造及び作業方法がパートナー自身のＰＤＭ環境と適合しないかもしれないため問題となる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明の課題は、よりオープンな技術的製品データを交換するためのシステム及び方法を提供することである。
【課題を解決するための手段】
【０００７】
本発明の課題を満足させるため、協力企業の第１の企業の少なくとも１つのコンピュータシステムは、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムと、
前記複数のデータ管理システムからユーザ選択可能なプロジェクトに関する技術的製品データをインポートし、前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成し、前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する編集システムと、
を有する。
【０００８】
編集システムは、企業が相異なるデータ管理システムを利用し続け、関連するすべての技術的製品データを１つのパッケージに合成し、当該パッケージをパートナーに提供することを可能にする。データ管理システムは、１つの製品のためのものである必要はなく、また１つの規格に準拠する必要もない。最適化されたデータ管理システムが利用されてもよい。データ管理システムは、例えば、タスクについて最適化されてもよいし（機械部品の設計又はソフトウェアの設計など）、又は企業の価格／パフォーマンス／機能について最適化されてもよい（例えば、多国籍の本格的な分散システム及び開発途上国の小さな企業のシンプルなスタンドアローンシステムなど）。データ管理システムは、専用のものであってもよい。交換パッケージは、任意の適切な方法により提供されてもよい。一般には、一部の技術データファイル（ＣＡＤファイルなど）はその性質上大きなものであるため、パッケージは、例えば、１〜５００メガバイトなどの比較的大きなものとなるかもしれない。従って、パッケージは、好ましくは、ＣＤ−ＲＯＭなどの記録キャリアを介し、又はオフラインの電子ファイル転送を利用して提供される。パッケージは、その全体として転送される。パッケージの要素は、オンラインにより個別に選択及びダウンロードされる必要はない。
【０００９】
従属クレーム２の手段によると、前記協力企業の少なくとも１つのコンピュータシステムは、
技術的製品データに対し処理を実行するさらなるデータ管理システムと、
前記交換パッケージを抽出し、ユーザ選択可能な技術的製品データを前記交換パッケージから前記さらなるデータ管理システムにエクスポートする第２の編集システムと、
を有する。
【００１０】
このように、パッケージを受け取る企業は、それ自体のデータ管理システムを利用し続けることができる。エディタは、企業に関連があり、それのデータ管理システムによりインポート可能なパッケージの上記部分をユーザが抽出することを可能にする。
【００１１】
従属クレーム３の手段によると、前記協力企業の少なくとも１つのコンピュータは、前記交換パッケージを抽出し、前記抽出した交換パッケージの技術的製品データのユーザ選択可能部分をさらなる交換パッケージに合成し、前記さらなる交換パッケージを前記協力企業の少なくとも１つの下請け業者にあるコンピュータシステムに提供する第３の編集システムを有する。
【００１２】
このように、協力企業の「階層」を形成することができる。例えば、モジュールのサプライヤは、当該モジュールの部品の開発／供給をアウトソースするかもしれない。エディタは、企業がそのサプライヤに関連する部品のみを選択することを可能にする。
【００１３】
従属クレーム４の手段によると、前記編集システムは、
技術的製品データを前記交換パッケージに追加する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を削除する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を変更する制御処理と、
のうちの少なくとも１つをユーザが実行することを可能にするよう動作する。
【００１４】
従属クレーム５の手段によると、前記編集システムは、当該編集システムのユーザの制御処理を表すトレーサビリティデータを前記交換パッケージに自動的に挿入するよう動作する。編集システムのユーザは、異なるソースからデータを選択するため、ユーザは知識を追加する。ユーザの処理は、パッケージに記録され、これにより、その後、あるデータがなぜパッケージにあるか、又はないか確定することができる。
【００１５】
従属クレーム６の手段によると、前記トレーサビリティデータは、
追加された技術的製品データについては、該追加された技術的製品データの表示と、
削除された技術的製品データについては、該削除された技術的製品データの表示と、
変更された技術的製品データについては、前記もとの技術的製品データと変更された技術的製品データの両方の表示と、
を有する。このように、パッケージは自己完結的なものである。他のソースには、プロジェクトの関連するあらゆる技術的製品データを有することが照会される必要はない。トレーサビリティは、例えば、元の及び変更されたデータを完全にコピーすることによるなど、任意の適切な方法によりパッケージに搭載されてもよい。あるいは、変更のみが示されるようにしてもよい。
【００１６】
従属クレーム７の手段によると、前記編集システムは、前記複数のデータ管理システムから前記プロジェクトの同一のベースラインに関連する技術的製品データをインポートするよう動作する。ベースラインに関して、受信企業がそれに割り当てられたタスクを実行するのに必要なデータの同一バージョン／改訂に関する整合性があり、完全な技術的製品データ群を意味する。好ましくは、交換パッケージは、パッケージの受信者が、何れのバージョン／改訂が使用に適しているかについて困惑することを避けるため、１つのベースラインに関するデータのみを含む。このベースラインアプローチはまた、ファイルの更新されたバージョンが新たな全体的なベースライン状態に達しないときは交換されないため、ある協力作業中に製品データが交換される必要がある回数を限定する。それはまた、企業が、それ自体正確ではあるが、実際には組み合わされて使用されるべきではない異なるパートナーからの文書について作業するリスクを回避する。なぜなら、それらは異なるバージョンに関するものであり、互換性がないためである。
【００１７】
従属クレーム８の手段によると、前記協力企業の少なくとも１つのコンピュータシステムは、前記交換パッケージを抽出し、前記抽出した交換パッケージの前記技術的製品データの少なくとも１つのエンティティに関連する問題報告データを追加し、拡張された交換パッケージを構成し、前記拡張された交換パッケージを協力企業の少なくとも１つのコンピュータシステムに提供する第４の編集システムを有する。
【００１８】
このように、問題報告データは、問題が報告されたこと、それがどのエンティティに関連するものであるかをパートナーが観察することを可能にする同一のパッケージに搭載される。
【００１９】
従属クレーム９の手段によると、前記編集システムは、以前に提供された交換パッケージに表される技術的製品データに関する変更をカバーするデルタ記述の形式により、技術的製品データをさらなる交換パッケージに表し、前記以前に提供された交換パッケージへの参照を前記さらなる交換パッケージに含めるよう動作する。特に、変更が小さなものである場合、これは変更によるサイズ拡大を限定的なものに維持する。パートナーはより容易に変更を検出することができ、変更をパッケージの完全な以前のバージョンに適用することにより、それらは完全な更新されたバージョンを容易に抽出することができる。
【００２０】
従属クレーム１０の手段によると、前記データ交換パッケージは、ヘッダと、特定のＣＡＤフォーマットなどのデータ管理システムに固有のフォーマットにより技術的製品データを表す任意的な添付とを有する。例えば、ＣＡＤリソースファイル、ソフトウェア設計、回路ボードレイアウトなどは、すべて当該状況に関係するパートナーにより使用されるようなフォーマットにより添付されてもよい。明らかに、同じ状況に関係するパートナー（ＣＡＤシステムを利用した機械部品の設計、ＣＡＭシステムを利用した部品の製造など）が同一の内部フォーマットを用いて実行しない場合、変換が必要となるかもしれない。実際、このようなパートナーは、あるシステムがエクスポートでき、他方のシステムがインポート可能な共通にサポートされるフォーマットに通常は同意することができる。本発明によるシステムでは、同意された共通のフォーマットによる技術的製品データは、添付として交換パッケージに含めることができる。編集システムは、当該フォーマットを完全に解釈する必要はないが、解釈可能であってもよい。所望される場合、編集システムは、共通のフォーマットがパートナー間で同意可能でないインポート／エクスポート変換を実行するかもしれない。
【００２１】
従属クレーム１１の手段によると、前記交換パッケージの技術的製品データは、複数のエンティティに構成され、前記交換パッケージは、各エンティティについて、該エンティティのオーナーシップを有する前記協力企業の１つに関する情報を有し、前記編集システムは、ユーザの制御の下、前記交換パッケージのユーザ選択可能なエンティティのオーナーシップの前記協力企業の他の１つへの移転をトリガーするよう動作する。このように、ある企業から他の企業に製品管理システムの完全なコピーを要することなく、企業間で責任を変更することができる。このような移転は、例えば、製品のライフサイクル中に発生してもよく、例えば、製造企業からサービス企業に責任が移行される。移転はまた、企業が製品のそれの利害を他の企業に移行するときも行われるかもしれない。各エンティティについて、オーナーシップが別々に移転可能である。このように、異なる企業は異なる部品に責任があり、オーナーシップはフレキシブルに移転可能である（オーナーシップが下請け業者に一時的に移転することができる）。好ましくは、オーナーシップの移転は、現在のオーナーの表示、所望のオーナーの表示、及び所望のオーナーへのオーナーシップの移転日の表示を交換パッケージのヘッダのメタデータに含めることにより有効にされる。
【００２２】
従属クレーム１３の手段によると、前記ヘッダのメタデータは、前記プロジェクトのサブプロジェクトに関する状態情報を有し、前記編集システムは、データ管理システムからインポートされたデータ管理固有フォーマットによる状態情報を所定のフォーマットに変換するよう動作する。このように、従来のデータ管理システムは、状態を表示し続けることが可能であり、企業は内部の作業方法を変更する必要なく、パートナー間の良好な理解のため、共通の状態が使用される。
【００２３】
従属クレーム１４の手段によると、前記ヘッダのメタデータは、添付間の関係を表す情報を有する。各データ管理システムは、ときには複雑な固有の関係を有する多数のファイルをすでに有するかもしれない。多様なデータ管理システムからのファイルを１つのパッケージに単にコピーすることは、コンテンツをパートナーにとって理解を極めて困難なものにする。従って、パッケージの追加的情報は、文書間の構造／関係を示す。
【００２４】
従属クレーム１５の手段によると、前記関係は、前記ヘッダのメタデータは、開発者のタスク、メーカーのタスク、サプライヤのタスク又はサービス／メンテナンスのタスクなど、前記協力企業のタスクに関する情報を有する。多数の企業が関係するプロジェクト、特に複数の企業レイヤの階層に関するプロジェクトについて、関係及び関連する責任は明確ではないかもしれない。交換パッケージにタスク情報を明示的に追加することにより、このような問題は回避される。
【００２５】
従属クレーム１６の手段によると、前記ヘッダは、ＸＭＬフォーマットである。これは、専用のエディタを有しない企業が例えば、パッケージをローカルに開いた従来のウェブブラウザを用いて、交換パッケージからデータを抽出及び観察することを可能にする。
【００２６】
本発明の課題を満たすため、編集システムは、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートする手段と、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成する手段と、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する手段と、
を有する。
【００２７】
本発明の課題を満たすため、複数の協力企業の各コンピュータシステムの間の技術的製品データをやりとりする方法は、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートするステップと、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成するステップと、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供するステップと、
を有する。
【００２８】
本発明の課題を満たすため、コンピュータプログラムは、上記方法の各ステップをプロセッサに実行させるよう動作する。
【００２９】
本発明の上記及び他の特徴は、非限定的な例により、以降で説明される実施例を参照して明らかにされる。
【発明を実施するための最良の形態】
【００３０】
図１は、多数の協力企業によるプロジェクトの例を示す。当該プロジェクトは、家電機器などの製品の開発及び製造であるかもしれない。プロジェクトはまた、製品、特に業務用製品のメンテナンス／アフターサービスを含むものであってもよい。従って、プロジェクトは、製品のライフサイクル全体をカバーすることができる（すなわち、コンセプト設計から製品陳腐化まで）。所望される場合には、実際のアプリケーションでは、当該プロジェクトは、ライフサイクルの一部のみに限定されるかもしれない。本発明による交換システムは、技術的製品データのやりとりをカバーするものである。基本的に、技術的製品データは、すべての技術分野（ソフトウェア、機械、電子など）をカバーする。あるアプリケーションでは、必ずしもすべての分野に関与するとは限らないということは理解されるであろう。技術的製品データは、製品データ交換パッケージを用いてやりとりされる。本説明では、このパッケージは、技術的製品データのみに限定される。企業間の業務データ（価格決定、発注、請求及び支払情報など）の交換のため、他のｅコマースやｂ２ｂコマース規格及び交換機構が適用される。実際のアプリケーションではまた、業務データは本発明による交換パッケージに含まれることは理解されるであろう。図１の例では、新たな製品の主要なイノベーション（研究開発など）は、３つのサイトで行われる。イノベーションセンターは、ＩＮ１、ＩＮ２及びＩＮ３として示される。図に示される他のタイプの協力企業は、ＩＣサプライヤＩＣＳ、機械部品サプライヤＭＣＳ、電気部品サプライヤＥＣＳ、化学サプライヤＣＳ、モジュール／サブアセンブリサプライヤＭＳ、委託メーカーＣＭ及びプロジェクトオーナーの工場ＦＡＣＴである。実際のプロジェクトでは、これらの役割の一部は不要であるということは理解されるであろう。また、これらの役割の一部は、複数の協力企業により実行されてもよい。例えば、各々が異なる部品を供給したり、第２のソースとして機能するなど、４つの異なる機械部品サプライヤが関与するようにしてもよい。
【００３１】
実際、２つの協力企業が同一の親会社の一部である可能性があるということは理解されるであろう。例えば、家電（ＣＥ）製造企業は、このＣＥ企業に対するサプライヤ及び／又は共同開発者であるＩＣ製造企業を所有する親会社により所有されているかもしれない。図２は、プロジェクトへの協力のさらなる例を示す。この例では、５つの協力企業２１０、２２０、２３０、２４０及び２５０が関与する。この例では、企業２１０が指導的企業である。それは、構成管理２１２、製品文書管理２１４、問題報告２１６及び変更制御２１８の指導的役割を実行する。外部企業２２０は、機械設計２２２と電気設計２２４を主導する。企業２１０の内部の又は同一の親会社により所有される組織２３０は、ソフトウェア開発２３２を主導する。企業２４０は委託メーカーであり、企業２５０はＩＣサプライヤである。製品データ交換パッケージ２６０は、これらの企業が最適に協調することを保証する。
【００３２】
図３は、本発明による製品交換システム３００のブロック図を示す。本例では、６つのコンピュータシステム３１０、３２０、３３０、３４０、３５０及び３６０が示され、それぞれは各自の協力企業に配置される。基本的に、企業のこのようなコンピュータシステムは、すべて同じ場所に配置可能であるが、それらはまた地理的により分散化されてもよい。コンピュータシステムの少なくとも１つは、複数の相異なるデータ管理システムを有する。例えば、コンピュータシステム３１０は、３つの相異なるデータ管理システム３１２、３１４及び３１６を有する。ここで、「相異なる（ｄｉｓｔｉｎｃｔ）」とは、データ管理システムが、ＣＡＤ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ）、ＰＬＭ（Ｐｒｏｄｕｃｔ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、ＣＡＭ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ）などの異なる役割を実行し、及び／又はシステム間においてデータが自由にやりとり可能ではないという意味において、異なるタイプではあるが同一の役割を実行するということを意味する。各データ管理システムが、各技術的製品データを生成するのに利用される。当業者は、このようなシステムを知っており、このようなデータ管理システムに与えられる技術的データを知っている。例えば、ＣＡＤシステムは、タイトルブロックデータ、パーツリストデータ及びリソースファイルを供給し、ＰＬＭシステムは、技術仕様及び構成管理を供給し、ＥＲＰシステムは、物品マスターデータ及びパーツリストを供給するかもしれない。本説明の残りでは、このようなデータ管理システム（ＤＭＳ）はまた、ＰＤＭ（Ｐｒｏｄｕｃｔ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）システムと呼ばれる。各ＰＤＭシステムは、生成された技術的製品データの一部をアーカイブする機能を実行し、当該データの一部は、それ自体ＣＡＤワークステーション（図３には示されず）のような他のシステム上で生成されたものであるかもしれない。技術的製品データが、作業中の製品の製造に利用される。これは、電気的、機械的又は化学的特徴をカバーするだけでなく、当該製品の動作を制御し、又は当該製品の技術的機能特徴を実行する埋め込みソフトウェアをカバーする。コンピュータシステム３１０はまた、複数のデータ管理システム３１２、３１４及び３１６からユーザ選択可能なプロジェクトに関連する技術的製品データをインポートすることが可能な編集システム３１８を含む。各ＰＤＭシステムは、典型的には、複数のプロジェクトについてパラレル（又はシーケンシャル）に利用されるため、編集システム３１８は、ユーザがプロジェクトの１つを選択し、複数のシステムからプロジェクトのデータを自動収集することを可能にする。編集システム３１８は、これを実行することができるように、ハードディスク上などに追加的なデータを格納する必要があるかもしれない。このようなデータは、例えば、編集システム３１８がＰＤＭシステムから関連するデータを抽出することを可能にする情報にユーザ選択可能なプロジェクトの識別子をマッピングするようにしてもよい。このような情報は、ＰＤＭシステムに用いられるプロジェクト識別子であってもよいし、又はＰＤＭシステムの単なるファイル名リストであってもよい。編集システムのプロジェクトを選択する代わりとして、ユーザは、各データ管理システムにおいてプロジェクトを選択するようにしてもよい。編集システム３１８は、任意の適切な方法によりインポート処理を実行するようにしてもよい。例えば、編集システムは、ＰＤＭシステムにより用いられるデータモデルの知識を有し、この知識を用いてＰＤＭシステム（ＰＤＭシステムのデータベースなど）か直接当該データを抽出するようにしてもよい。ＰＤＭシステムはまた、編集システム３１８によりインポート可能な形式により関連するデータをエクスポートしたかもしれない。編集システム３１８は、インポートされた技術データのフォーマット変換を実行する必要があるかもしれない。以下でより詳細に説明されるように、編集システムは、好ましくは、メタデータをすべての協力企業により解釈可能なフォーマットによる交換パッケージに追加する。相異なるデータ管理システムが抽出する必要があるかもしれないメタデータの一部は、インポートされた技術データを構成し、このためフォーマット変換を伴うかもしれない。編集システム３１８は、インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成する。従って、編集システム３１８は、どのインポートされた技術データが表される必要があって、何れが表されるべきでないかユーザが選択することを可能にする。この選択は、例えば、特定の協力企業を対象とするものであってもよく、例えば、機械部品サプライヤは、ソフトウェア開発に関連するデータを必要とせず、その反対も考えられる。同様に、ＣＡＤファイルは、企業内の内部作業に関連するが、サプライヤには関係のないデータを有するかもしれない。技術データの表現は、直接的な複製又は変換を含む任意の適切な形式をとりうる。編集システム３１８は、交換パッケージをその他の協力企業の少なくとも１つに配置されるコンピュータシステムに提供する。それは、必ずしも必要ではないが、すべての協力企業にそれを供給するようにしてもよい。示されるように、それはまた、企業に固有のパッケージを１つの企業のみに供給するようにしてもよい。パッケージは大変大きなものである可能性があるため（例えば、５００メガバイト）、パッケージは、「オフライン」に供給される。好ましくは、パッケージはコンピュータネットワーク３７０を介し供給される。これは、ダイレクト／賃貸リンクであってもよいが、好ましくは、ブロードバンドインターネット接続が利用される。適切なインターネットプロトコルとして、ＨＴＴＰ／ＳＯＡＰ、ＦＴＰ又は電子メールがある。所望される場合、パッケージはまた、ＣＤ−Ｒ／ＲＷ又はＤＶＤ＋Ｒ／ＲＷなどの記録キャリアを介し供給されてもよい。好ましくは、パッケージはセキュアに提供することにより（例えば、記録キャリアを介し配布するため、インターネット内のＳＳＬや通常の暗号化技術を利用することにより）競争相手の望ましくない処理に対しプロテクトされる。
【００３３】
編集システムは、任意の適切な方法により実現されるようにしてもよい。典型的には、それは編集システムの機能が適切なプログラムによる制御の下でプロセッサ（図示せず）により実行される、ＰＣやワークステーションなどの通常のコンピュータ上で実現される。このプログラムは、ハードディスクやＲＯＭなどのバックグラウンドストレージ（図示せず）から、コンピュータのメインＲＡＭなどのワーキングメモリ又はプロセッサにロードされるようにしてもよい。ユーザは、入力用のキーボード／マウスと出力用のディスプレイ／プリンタなどの任意の適切なユーザインタフェース（図示せず）を介し編集システム３１８を制御することができる。特に、一実施例では、編集システムは、以下の制御処理の少なくとも１つをユーザに実行させる。
・技術的製品データの交換パッケージへの追加
・インポートされた技術的製品データのユーザ選択可能部分の削除
・インポートされた技術的製品データのユーザ選択可能部分の変更
例えば、ユーザはＰＤＭシステムに存在しない技術的製品データを追加してもよいし、又は編集システム３１８によりインポート可能な形式によりエクスポートすることはできない。ユーザは、パッケージが送信される協力企業に関係のないデータなど、技術データの一部を削除するかもしれない。ユーザはまた、ＰＤＭシステムにおいてまだ有効にされていない直近の変更を反映させるためなど、データのユーザ選択可能部分を変更するかもしれない。
【００３４】
本発明の実施例では、協力企業の少なくとも１つのコンピュータシステム３２０は、技術的製品データに対する処理のためのさらなるデータ管理システム３２２を有する。図３の例では、実際に、コンピュータシステム３２０は、３つのＰＤＭシステム３２２、３２４及び３２６を含む。コンピュータシステム３２０は、交換パッケージを抽出するための第２の編集システム３２８を含む。編集システム３２８は、選択可能な技術的製品データを交換パッケージからさらなるデータ管理システム３２２にエクスポートする。それはまた、技術的製品データをその他のＰＤＭシステム３２４と３２６にエクスポートするようにしてもよい。ユーザは、パッケージ内の何れのデータがエクスポートされるか制御することができる。編集システム３１８について説明されたインポート処理と同様に、編集システム３２８は、ＰＤＭシステムのデータベースに直接アクセスすることによりデータをエクスポートするようにしてもよい。複数のＰＤＭシステムが存在する場合、好ましくは、編集システム３２８は、選択されたデータが何れのＰＤＭシステムにエクスポートされるべきかユーザが指定するのを可能にする。当該データはまた、ファイルとしてエクスポートされてもよく、ＰＤＭシステムの通常のインポート機能を介しＰＤＭにロードされてもよい。編集システム３２８は、それがパッケージ内のデータとＰＤＭシステム内の対応するデータとを関連付けることを可能にするデータを必要とするかもしれない。編集システム３２８によるエクスポート処理もまた、データ変換を含むかもしれない。編集システム３２８は、ＰＤＭシステムからインポートし、ＰＤＭシステムへエクスポートすることが可能な多機能編集システムの編集システム３１８と結合されてもよい。所望の場合、協力企業には、企業がパッケージを生成するのでなく抽出することを可能にするなど、限定的な機能の編集システムに供給するようにしてもよい。
【００３５】
本発明の実施例では、協力企業の少なくとも１つのコンピュータシステム３３０は、第３の編集システム３３８を含む。図３の例では、それはまた、必要ではないがＰＤＭシステム３３２を含む。編集システム３３８は、交換パッケージを抽出する。ユーザの制御の下、編集システム３３８は、抽出された交換パッケージの技術的製品データのユーザ選択可能部分をさらなる交換パッケージに表す。それは、さらなる交換パッケージを協力企業の少なくとも１つの下請け業者に配置されるコンピュータシステム３６０に提供する。この協力企業は、例えば、システム３３０を有する企業の下請け業者であってもよい。このように、協力企業間の複雑な関係は、シンプルな方法により生成可能である。上述のように、この編集システム３３８は、編集システム３１８や３２８について説明されたような他の機能と結合される必要はないかもしれない。コンピュータシステム３６０を有する企業は、必ずしも必要ではないが、編集システム３６８とデータ管理システムを有するようにしてもよい。
【００３６】
編集システムのユーザ制御は自動化可能であるということは理解されるであろう。例えば、ユーザは、特定のタスクを一回実行可能であり（パッケージに表される必要があるＰＤＭシステムからインポートされるデータの選択など）、編集システムは、マクロの記録と同様に、以降において当該タスクを繰り返し、再びそれを実行することが可能であるかもしれない。ユーザはまた、スクリプト処理を用いるなど、ユーザ制御タスクを編集システムに「プログラム」してもよい。
【００３７】
図３は、編集システム３４０のさらなる利用を示す。この場合、協力企業のコンピュータシステムは、技術的製品データが編集システムによりエクスポート可能な、又は技術的製品データがインポート可能なＰＤＭシステムを含まない。代わりに、ユーザは、この編集システムを利用して、交換パッケージを抽出し、この交換パッケージのコンテンツを閲覧し、選択された部分をさらなる処理のため、ハードディスクなどのストレージシステムに格納し、及び／又は技術的製品データの選択された部分を印刷することができる。
【００３８】
一実施例では、データ交換パッケージは、ヘッダと、特定のＣＡＤフォーマットなどのデータ管理システムに固有のフォーマットにより技術的製品データを表す任意的な添付を含む。好ましくは、ヘッダはＸＭＬフォーマットによる。ヘッダは、以下でより詳細に説明されるようなメタデータを含むものであってもよい。ＸＭＬの使用は、協力企業がＭｉｃｒｏｓｏｆｔのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒなどの通常のインターネットブラウザを用いてパッケージを閲覧することを可能にする。これは、ブラウザを含むだけのコンピュータシステム３５０について示される。ブラウザにより、システムのユーザは、パッケージの一部を選択し、それらを格納及び／又は印刷することができる。これにより、選択された部分はまた、ＰＤＭシステムにインポートすることができる。一実施例では、本発明によるパッケージは、既存のオープンなデータ交換規格に基づく。特に、パッケージは、本発明による追加的機能が当該規格の拡張により達成可能な電子製造サプライチェーン通信であるＩＰＣ−２５７シリーズに対するＮｅｍｉ／ＩＰＣ Ｐｒｏｄｕｃｔ Ｄａｔａ ｅＸｃｈａｎｇｅ（ＰＤＸ）に基づくものであってもよい。一例となるパッケージの定義による特定の属性は、ＩＰＣ−２５７シリーズと同一のものであってもよい。これらの属性は、ここでは完全には規定されない。当該規格の属性定義は、参照することによりここに含まれる。
［ベースライン及びデルタパッケージ］
一実施例では、製品データ交換パッケージは、プロジェクトの直近の情報又はベースラインを含む。ベースラインは、一貫性を有する製品情報である。ベースラインの技術的製品データの各種バージョン及び改訂は、好ましくは、互いに一貫性を有する。パッケージは、技術的製品データの一のみの固有の改訂又はバージョンしか含まない。技術的製品データの複数の改訂又はバージョンは、好ましくは、同一のパッケージには表されない。なぜなら、何れの改訂が利用に適しているかは、受信機には明らかでないからである。例外は、以下で詳細に説明されるデルタパッケージの利用である。当該パッケージの発行者（すなわち、編集システム３１８を制御するユーザ）は、同一のベースラインパッケージをすべての協力企業に発行するようにしてもよい。これは、例えば、パッケージの大部分の情報がグローバルであるプロジェクトの開始において有用であるかもしれない。発行者はまた、受信者を対象とする、すなわち、受信者に関連するプロジェクトに技術的プロジェクトデータの選択のみを含むパッケージを発行するかもしれない。例えば、特定の機械部分のメーカーのみが、当該部分の製造に関連するデータを取得する必要がある。
【００３９】
製品情報を有するパッケージが配布されると、所有サイトの元の情報は変更されるかもしれない。好ましくは、変更は即座に通信はされない。代わりに、好ましいアプローチは、パッケージに受信者がオーナーが行ったすべての中間的な変更を知る必要なく、当該情報により作業可能となるように製品情報を収集することである。例えば、ソフトウェア開発プロセスでは、オーナーはパートナーにテスト用のバージョン「０．３」を配布する。そのとき、ソフトウェア開発者は、これらの更新をパートナーに配布することなく自らの作業を継続する（及びバージョン「０．４」と「０．５」が作成される）。最終的に、パートナーのテスト結果を受信し、これらをソフトウェアに搭載した後、オーナーはバージョン「０．６」を配布する。なぜなら、これがパートナーが興味を有する次のリリースであるからである。従って、元の情報から新たな情報を導くオーナーにより行われた中間ステップは、通信される必要がなくなる。
【００４０】
ある期間に生じた変更を配布するため、本発明によるデータ交換システムは、以下の２つのアプローチの少なくとも１つをサポートする。
・新たな情報のベースラインを有する新たな製品データ交換パッケージの配布、すなわち、関連する技術的製品データが、パッケージ自体に完全に表される。
・「デルタ」を有する製品データ交換パッケージの配布、すなわち、パッケージが送信された最近の時点からの変更がなされた情報のみの配布。所望の場合、「デルタ」はまた、直前のパッケージより以前のパッケージに規定されるものであってもよい。この場合、識別子（パッケージ名及び日付など）はデルタパッケージに含まれる。受信者は、デルタパッケージを用いて、自分のローカル情報を新たな情報のベースラインに更新する。
【００４１】
図４及び５において、デルタパッケージのコンセプトがさらに示される。図４において、時点ｔ１における関連する製品データは、送信者ＳＮＤから受信者ＲＣＶに送信された交換パッケージにおいて表される。時点ｔ２において、斜線のパターンｃｈを用いて示される変更が、製品データにおいて有効にされる。これらの変更のみを表すデルタパッケージが、ＳＮＤからＲＣＶに送信される。デルタパッケージは、元のパッケージを参照する。図５において、ＰＤＭシステムからの製品データは、パッケージ４２０として編集システムに供給される。ユーザの制御の下、編集システムは、アイテムを追加及び変更し、またパッケージのルート要素に影響を与える。トレーサビリティのため、変更及び追加されたアイテムをさらに含むパッケージ４３０が生成される。パッケージ４３０は、受信者ＲＣＶに供給される。受信者ＲＣＶにおける編集システムが使用され、さらなるアイテムが追加され、パッケージ４６０が生成される。受信者の選択により、更新されたパッケージ４６０の全体が、パッケージ４７０として元の送信者ＳＮＤに供給されてもよいし、あるいは、受信者ＲＣＶによりなされた変更を反映させたデルタパッケージ４８０が送信されてもよい。パッケージ４３０と４６０の変更を反映させたパッケージ４７０の全体が、ＰＤＭシステム４１０にフィードバックされてもよい。あるいは、デルタパッケージ４８０は、パッケージ４３０になされた変更を反映させるデルタパッケージと組み合わされてもよい。その後、組み合わされた変更はＰＤＭシステム４１０にインポートされる。
【００４２】
デルタパッケージは、パッケージの要素に関する以下の属性を用いて処理することができる。
【００４３】
【表１】
［パッケージ構造］
図６は、製品データ交換パッケージ６００に存在しうる以下の主要な要素の概略を与える。
・アイテム６１０は、（最終）製品、モジュール、（架空の（ｐｈａｎｔｏｍ））組立品、パーツ、部品などのそれの製品情報を管理するため組織が利用する一意的に識別されるエンティティを表す。それのライフサイクル中、複数の改訂及びバージョンが生成及び維持されるかもしれない。アイテムは、主として製品の有形部品を表す。アイテムはまた、埋め込みソフトウェア又は埋め込みソフトウェアモジュールを表すものであってもよい。これらのアイテムは、各自の特徴、材料６１２の単一レベル請求者や、アイテムの共同開発者、メーカー、サプライヤ、メンテナンス業者又はサービス提供者のタスク情報６１４と関連付けされる。
・文書６２０は、ファイル内にキャプチャされる１以上のアイテムに関する詳細な製品情報を含む業務文書を表す。具体例として、技術仕様、設計ソースファイル、図面ファイル、製造ファイル、プロジェクトファイル、品質文書、要求仕様及びプロジェクトレポートがあげられる。文書は、各自の文書構造を有することが可能である。さらに、各自の属性、ファイル及びアプリケーション情報並びにアイテムとの関係が、文書と関連付けされる。それのライフサイクル中、複数の改訂及びバージョンが作成及び維持されるかもしれない。
・問題レポート６３０は、現場での問題点、エンハンスメント要求などの通信用に使用される。問題レポートは、問題元、問題オーナー、問題の詳細及び問題の解決状況に関する情報を含む。問題レポートは、問題に影響を与えるアイテム６３２に関連付けされる。
・変更６４０は、変更要求、変更指示及び変更通知を表す。変更の具体例として、エンジニアリング変更、部品リスト変更などがあげられる。変更は影響を与える文書及びアイテムに関連付けされる。さらに、それらは、解決する問題レポート６４４と変更を承認する者６４６と関連付けされる。
【００４４】
従来、異質な設計データ管理システム（ＣＡＤ−ＰＤＭデータベースとファイルサーバなど）の間の複数の設計オーサリングシステム（ＭＣＡＤ、ＥＣＡＤ、ＣＡＳＥツールなど）からのソースデータの交換は、
・ソースファイル間の複雑な相互関係
・ファイルバージョン及び改訂の管理
・ソースが、派生されるデータファイル（各プロット形式による図面及び３次元閲覧ファイルなど）の生成に利用される。派生ファイルと元のソースデータとの間の相互関係が維持される必要がある。
・設計構造は、しばしば製品構造構成情報と部分的に適合するが、完全には適合しない。
による問題がある。
【００４５】
この複雑さは、他の添付と関係することなくファイルがシンプルな添付として実現される最新のオープンな製品データ交換規格により解決されるものではない。技術的製品データ構造の有効なやりとりのため、交換パッケージは、以下の方法の少なくとも１つにより各構造を備える。
・設計ソースファイル（設計オーサリングツールの専用フォーマットによるファイル）は、特殊な文書タイプである設計ソース文書として表される。これは、パッケージの「文書」要素の属性「ｄｅｓｉｇｎＳｏｕｒｃｅＤｏｃｕｍｅｎｔ」を用いることにより実現される。この属性は、設計ソース文書については「ｙｅｓ」、他のすべてのタイプの文書については「ｎｏ」と設定される。
・派生ファイル（例えば、閲覧、印刷、製造用のため、複数のアプリケーションによりサポートされるフォーマットによりソース設計から生成されるファイル）は、文書として表される。
・各文書及び設計ソース文書は、パッケージの属性により表される自らの改訂及びバージョン表示を有する。
・各設計ソース文書は、元の設計オーサリング環境からの以下の情報の少なくとも１つ、すなわち、アプリケーション名、アプリケーションバージョン、ファイル位置の（相対）パス情報を有する。
・設計ソース文書間の「ＢｉｌｌＯｆＤｏｃｕｍｅｎｔｓＩｔｅｍ」関係は、ソース設計の階層、すなわち、設計オーサリングツールにおける処理のため、何れのソースファイルが他の何れのソースファイルを必要とするかを記述する。
・設計ソース文書と文書との間の「ＤｅｒｉｖｅｄＦｒｏｍＦｉｌｅ」関係は、文書が何れのソース設計ファイルから派生されたものであるかを記載する。
・アイテムと設計ソース文書との間の「ＳｐｅｃｉｆｉｅｓＩｔｅｍ」関係は、関連する文書が何れのアイテムに関する詳細情報を有するか記述している。
・設計階層の頂点のパッケージにある設計ソース文書は、もとになるバージョン及び改訂の構成に関する情報を含む。
【００４６】
図７において、パッケージＰｃｋｇの具体例が示される。それは、送信者情報（Ｆｒｏｍ：．．．）、受信者情報（Ｔｏ：．．．）、及び「ここに、私たちのボードの仕様がある」などの任意的な指示／コメントフィールド（Ｉｎｓｔ：）を含む。このパッケージは、製品識別子（Ｐｒｏｄ ｉｄ）、改訂番号（Ｒｅｖ）、説明（Ｄｅｓｃ）及びオーナー（Ｏｗｎ）を有する１つのアイテムＩｔを含む。このアイテムはさらに、各々が各自のフィールドと添付ファイル（Ｆｌｓ）を有する２つの文書Ｄｏｃにより特定される。
［オーナーシップ］
製品データのやりとりは、技術的製品データのコピーが複数の場所に配布される状況をもたらす。元の情報マスターが保持される位置が知られていることが好ましい。一実施例では、製品データ交換パッケージは、オーナーをパッケージの主要な要素に割り当てることによりこの情報を備える。オーナーは、配布された製品情報のマスターを保持及び維持する者又は組織である。好ましくは、製品データ交換パッケージでは、オーナーはアイテム、文書、変更及び問題レポートに割り当てられる。
【００４７】
アイテムのオーナーは、好ましくは、
・アイテムの特徴及び属性
・材料の（単一レベル）請求書 材料の請求書に出現するアイテムは各自のオーナーを有する可能性があることに留意されたい。
・アイテムに関連付けされたタスク情報
を含むすべての基礎となる要素のオーナーである。
【００４８】
文書のオーナーは、好ましくは、
・文書の特徴及び属性
・ファイル及び添付情報
・文書の（単一レベル）請求書 文書の請求書に出現する文書は各自のオーナーを有する可能性があることに留意されたい。
・文書に直接的に関連付けされた開発者のタスク情報
・アイテムとのリンク（「アイテム指定」要素による）
・派生ファイルとのリンク（「ファイルからの派生」要素による）
を含むすべての基礎となる要素のオーナーである。
【００４９】
変更のオーナーは、好ましくは、
・影響を受けるアイテム及び文書とのリンク（「影響を受けるアイテム」及び「影響を受ける文書」要素による）
・解決された問題レポートとのリンク（「解決された問題」要素による）
を含むすべての基礎となる要素のオーナーである。
【００５０】
問題レポートのオーナーは、好ましくは、影響を受けるアイテム（「影響を受けるアイテム」要素による）とのリンクを有するすべての基礎となる要素のオーナーである
オーナーシップ情報は、複数のオーナーからの製品情報が、単一の製品データ交換パッケージにおいて通信されることを可能にする。好ましくは、この情報のオーナーは、変更の配布の責任を有する。これは、以下の図に示される。パートナーとの共同作業中、製品情報のオーナーシップは、１つのサイトから他のサイトにシフトされてもよいということに留意されたい。オーナーシップがシフトすると、新たなオーナーがまた、情報に関してなされた変更を配布する責任を有することとなる。
【００５１】
パートナーとの共同作業中、製品情報のオーナーシップは、１つのサイトから他のサイトにシフトするかもしれない。図８において、一例となるシナリオが与えられる。本例では、ＯＥＭ８００がモジュールを規定する。ＯＥＭ８００内の状態は、システム開発８０２、先行製造８０４及び大量製造８０６であるかもしれない。ＯＥＭは、モジュールのエンジニアリングをモジュール開発者８１０に、それの試験製造を委託メーカー８２０にアウトソースする。モジュール開発者は、対応する製品情報のオーナーとなる。移転後、モジュール開発者は、モジュールのマスター情報と、ＯＥＭ及び委託メーカーへの変更による更新の配布の責任を有する。試験製造段階後、オーナーシップは、モジュールについての責任を継承したＯＥＭに移転される。オーナーシップの移転は、→８３０により示される。その他の矢印は、モジュール製品データの配布を示している。モジュール開発者８１０は、主要な状態として、モジュール開発８１２、サンプル８１４及び試験製造８１６を有するかもしれない。斜線は、図面においてオーナーシップを示す。
【００５２】
本発明によるシステムの一実施例では、オーナーシップの移転を通信するため、以下の情報が製品データ交換パッケージにおいて、ＩＰＣ規格により規定される現在の情報に加えて移転されるアイテム及び／又は文書に追加される。
・属性「オーナーの委託への移転一意的識別子」による新たなオーナー
・属性「オーナー日付の移転」によるオーナーシップの移転が有効となる日付
【００５３】
【表２】
オーナーシップを移転することにより、両方のパートナーは好ましくは、
・送信者が、他のサイトにより所有される製品情報として、オーナーシップが移転された製品情報を扱う。
・受信者が、マスター情報のオーナーとなり、変更による更新を配布する。
ことに同意する。
［問題報告］
開発及び供給チェーンを介した問題（エンハンスメント要求、現場の問題など）の通信が、すべてのビジネスパートナーが適切に応答、通信及び解決策を実現することを可能にするため、可能な限り早急に確立されることが望まれる。本発明による一実施例では、問題レポートが生成され、交換パッケージに含めることができる。好ましくは、当該チェーンのすべての者が問題レポートを生成可能である。問題レポートの作成者は、問題元と呼ばれる。問題元は、必ずしも「問題オーナー」である必要はない。パートナー間の協調モデルに応じて、問題元は問題レポートを何れに送信するか決定されてもよい。例えば、問題レポートは、ＯＥＭにより集中的に収集及び管理されてもよく、また、問題レポートが影響を受けるモジュールの各オーナーに直接提出される分散モデルが同意されてもよい。問題を解決するのに割り当てられた者又は組織が、問題オーナーとなる。問題オーナーは、問題を処理する責任を有する。さらに、問題オーナーは、問題の解と状況をパートナーに通信する責任を有する。図９において、このことがさらに示される。図２において、２つの問題レポートＰＲ１とＰＲ２は、すでにクローズされ、各自の問題の解Ｐ．Ｒｅｓ１とＰ．Ｒｅｓ２が含まれる。問題レポートＰＲ３は変更を要求したが、ＢＯＭ（Ｂｉｌｌ ｏｆ Ｍａｔｅｒｉａｌ）マークアップによる提案された変更ＣＨはまだ承認されていない。問題の通信は、好ましくは、以下の方法により有効とされる。
・問題レポートは、開発又は製造チェーンのすべての者により配布可能である。問題レポートは、問題の説明、詳細の添付及び問題レポートの発信元からのコンタクト情報を含む。
・問題レポートは、常に１以上の影響を受けるアイテムと関連付けされる必要がある。
・各問題レポートは、問題オーナーを取得する。問題オーナーは、問題を処理する責任を有する。異なる応答、すなわち、問題レポートの状況の変更、問題への解法情報への直接的な添付とビジネスパートナーへの解法の通信、１以上の問題を解決するのに必要とされる変更の開始、及びビジネスパートナーによる確認／検証／承認のため、ビジネスパートナーへ通知するための変更の通信が可能である。
・変更は、当該変更において解決される問題へのリンクト、影響を受けるアイテムへのリンクを含む変更要求／変更指示／変更留意情報を記載する。
【００５４】
交換パッケージの問題レポートは、エンティティ「ＰｒｏｂｌｅｍＲｅｐｏｒｔ」を規定することにより処理することができる。以下のテーブルは、オープンな製品データ交換規格による「Ｐｒｏｂｌｅｍ Ｒｅｐｏｒｔ」の実施例に対する可能な属性を指定する。
【００５５】
【表３】
「ＡｆｆｅｃｔｅｄＩｔｅｍｓ」と「ＡｆｆｅｃｔｅｄＩｔｅｍ」要素は、ＰｒｏｂｌｅｍＲｅｐｏｒｔ ｔｏ Ｉｔｅｍｓに関連付けるのに用いられる。
［プロセス状態］
本発明による実施例では、システムは共同開発及びサプライチェーン通信における製品データ交換を利用したパートナーが、自らの内部プロセスに従うことを可能にすることをサポートする。図８において、このことがまた示される。パートナー間の協調モデルは、何れの情報が何れの段階及びマイルストーン中にやりとりされるか規定し、これにより、各パートナーは、適切な時点において必要な入力を有することとなる。パッケージは、パートナーがそのやりとりにおいて製品及び文書のためのそれの内部識別コードを利用することを可能にする。パッケージにおいて、同一の製品又は文書に用いられる異なるコードが関連付けすることが可能である。製品及び文書のライフサイクルの状態（「ドラフト」、「製造のためリリース済み」など）を示すため、オーナーは２つのオプションを有する。
・送信者と受信者が同じ言語を用いてやりとりされる情報の期限を示すことができるように、オーナーの内部状態の所定の状態リストへのマッピング
・オーナーのサイトの状態のパッケージへの直接的な搭載
さらに、オーナーのサイトにおける動作状態を示す（サブ）プロジェクトの状態が、同様の方法によりパッケージに表されてもよい。所定の状態リストは、すべての協力企業について規定された同一の意味を有する。一実施例では、編集システムは、内部状態（協力企業の１つの内部に規定された、又はＰＤＭシステムにより規定されたものなど）を所定の状態に変換することが可能である。このため、ユーザは、編集システムが変換を自動的に実行することができるように、編集システム内に変換テーブルを規定するようにしてもよい。変換は完全なものではないかもしれないため、好ましくは、受信サイトの編集システムは、追加的なフィールドによりオーナーからの状態情報を可視化する。このフィールドはまた、ローカル状態情報に加えて、ＰＤＭシステムにエクスポートされてもよい。ほとんどの場合、送信者からの状態情報を受信者のライフサイクルプロセスにマッピングすることは意味がない。なぜなら、送信者と受信者は異なるプロセスに従うためである。
［タスク情報］
一実施例では、分散された製品データにより実行される必要があるタスクは、製品データ交換パッケージにおいて通信される。この情報を通信する目的は、すべてのパートナーがその他のパートナーの責任により通知可能であるということである。タスク情報は、
・業務パートナーが作業の中断により自らのタスクの範囲内において製品開発データを交換することを可能にする「作業中断」構造の設定
・拡張された事業の問題通知及び変更処理 タスク情報は、何れの者が関連する製品情報が重要となるタスクについて責任を有するか示す。従って、関連する製品の問題レポート及び変更について更新されるタスクに割り当てられるすべての主体を維持することが推奨される。
・データパッケージのさらなる分散される必要がある部分へのサプライチェーンの上流及び下流方向への分割のために利用可能である。
【００５６】
以下の４つのタイプのタスクが区別されてもよい。
・開発者のタスク：製品（モジュール）を開発及びエンジニアリングするためのタスク及び開発データのメンテナンス
・メーカーのタスク：仕様に従う製品（モジュール）の製造又は組み立てタスク 割り当てられたモジュールのサブモジュールは、他のメーカーにアウトソースすることができる。
・サプライヤのタスク：製品（モジュール）を供給するタスク サプライヤのタスクは、メーカー及びサプライヤが同一のコンタクトでない場合割り当てられる。例えば、キャパシタは、フィリップスにより製造され、小売業者により供給されてもよい。
・サービス／メンテナンスタスク：顧客への供給後の製品（モジュール）のアフターサービス／メンテナンスのためのタスク
タスク情報をやりとりする好適な方法は、以下の通りである。
・開始時に、すべてのパートナーに自分の及びその他のパートナーのタスク情報が通知される。これは、製品の主要モジュールと各自の開発、製造、サプライヤ、サービス／メンテナンスタスクを含む製品データ交換パッケージを配布することにより達成される。
・チェーン内のパートナーは、他の何れのパートナーが各自の製品情報を受信しなければならないか判断するため、分散された「作業中断構造」を利用する。さらに、タスク情報は、中断及び供給チェーンの（サブ）委託者へのさらなる配布を可能にするため、製品データ交換パッケージに含まれる。
・タスク情報において変更が発生すると、例えば、あるアイテムの好適なメーカーのリストが１つの好適なメーカーに絞られるなどすると、対応するアイテムのオーナーは、これらのタスク変更をその他のパートナーに通信する責任がある。基本的には、すべてのパートナーがタスクの変更を通知されるべきである。
【００５７】
オーナー情報により、パッケージの受信者は、当該情報についての責任ある主体を決定することができる。
【００５８】
本発明の実施例では、タスク情報は、ＩＰＣ−２５７８規格からの「ＡｐｐｒｏｖｅｄＭａｎｕｆａｃｔｕｒｅｒＬｉｓｔ」及び「ＡｐｐｒｏｖｅｄＳｕｐｐｌｉｅｒＬｉｓｔ」要素を用いて、
・「ＡｐｐｒｏｖｅｄＤｅｖｅｌｏｐｅｒＬＩｓｔ」要素
・「ＤｅｖｅｌｏｐｅｒＰａｒｔ」要素
を追加することにより、パッケージに組み込まれる。
［デルタパッケージの詳細］
デルタパッケージは、エンティティ（タスク情報など）及び属性に応じて、変更されたすべてのアイテム、文書、変更、問題レポート及びそれらの基礎となる要素を含むかもしれない。例えば、アイテムの１つの属性フィールドのみが変更された場合、基礎となるすべての要素及び属性を有する完全なアイテム要素が、デルタパッケージにおいて交換されることに留意されたい。
【００５９】
デルタパッケージは、新たなエンティティ「Ｄｅｌｔａ」を定義することにより生成可能である。このＤｅｌｔａエンティティは、「ＤｅｌｔａＮｅｗ」と「ＤｅｌｔａＯｌｄ」の２つの基礎となる要素を有する。「ＤｅｌｔａＮｅｗ」要素は、変更されたアイテム、文書、変更などを含む。受信者は、これらの要素を用いて以前に受信した情報を更新することができる。「ＤｅｌｔａＯｌｄ」要素は、変更された元のアイテム、文書、変更などを含む。デルタパッケージをやりとりするため、この要素は任意的なものである（受信者は、すでにこの情報を有するため）。当該要素の主な目的は、以下で詳細に説明されるトレーサビリティである。
【００６０】
以下のテーブルは、オープンな製品データ交換規格の一実施例のための「ＤｅｌｔａＯｌｄ」及び「ＤｅｌｔａＮｅｗ」要素の可能な属性を指定する。
【００６１】
【表４】
［トレーサビリティ］
製品コンテンツが拡張された事業を移動するとき、手動による更新プロセスによる情報の変更に対する制御は失われるかもしれない。解決しなければならない問題は、
・送信者のＰＤＭシステムからの選択及びダウンロード後、製品データは、パッケージの送信前に編集システムにおいて変更されてもよい。
・パッケージの受信後、受信者は、それの編集システムを用いてパッケージコンテンツを変更するようにしてもよい。
である。
【００６２】
ある環境において、ある協調モデルにおいては、すべての変更が追跡可能であることが必要とされることが要求されるかもしれない。トレーサビリティ要求を満たすため、以下の情報を追跡することが好ましい。
・パッケージへの製品データベースから製品データを抽出するのに利用されるエクスポートクエリ
・編集システムを用いてパッケージに行われた変更
トレーサビリティ情報は、以下の方法により利用可能である。
・トレーサビリティ情報は、送信者により保持され、送信されたパッケージのコピーを保持する必要なく送信されたパッケージを登録するのに利用可能である。
・トレーサビリティ情報は、パッケージに搭載可能である。パッケージの受信者は、（エディタにおいて）パッケージ送信前にどのような変更がなされたか確認することができる。
【００６３】
トレーサビリティデータは、
・追加された技術的製品データについて：追加された技術的製品データの表示
・削除された技術的製品データについて：削除された技術的製品データの表示
・変更された技術的製品データについて：元のものと変更された技術的製品データの両方の表示
を含む。
【００６４】
これは、上述された「デルタ」要素を利用することにより実行可能である。アイテム、文書、変更、問題レポート、コンタクト、パッケージのメーカー部分、サプライヤ部分又は開発部分が最初に変更されるとき、元の要素は、好ましくは、パッケージの「ＤｅｌｔａＯｌｄ」要素にコピーされる。もとの情報がこのように確保された後、パッケージの要素が編集可能である。このため、「ＤｅｌｔａＯｌｄ」要素は、すべての元の及びそれらの基礎となる要素と属性を含むこととなる。要素が編集される場合、これは、追加的な属性要素「ｄｅｌｔａＥｄｉｔＳｔａｔｕｓ」（それは、「Ｅｄｉｔｅｄ」の値を受け取る）と、「ｄｅｌｔａＯｌｄＩｔｅｍＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ」（「ｄｅｌｔａＯｌｄ」下の対応する要素へのポインタを含む）により示すことができる。このようにして、元の要素と最近編集された要素のみがパッケージに格納される。送信前に複数回要素が編集されたときに発生した可能性のある中間状態は、保持されない。新たな要素がパッケージに生成される場合、例えば、新たなアイテムが製品構造に追加され、又は新たな文書が作成された場合、これは、「Ａｄｄｅｄ」の値を受け取る追加的な属性「ｄｅｌｔａＥｄｉｔＳｔａｔｕｓ」により示される。図５は、パッケージのトレーサビリティ情報がどのように利用可能であるか示す。送信者は、新たなパッケージを生成し、このパッケージを編集する。トレーサビリティのため、送信者は、編集のデルタパッケージと抽出データを保持する（従って、送信者は、常に変更されたパッケージのコピーを保持する必要なくパッケージを再生成することができる）。受信すると、受信者は、パッケージに対するさらなる編集を行う。編集後、受信者は、完全なパッケージを（編集された要素と古い要素と共に）送信し、又は、更新を含むデルタパッケージを送信することができる。何れのアプローチでも、編集されたデータは、送信者のデータ管理システムにフィードバックすることができる。
【００６５】
本発明はまた、コンピュータプログラム、特に本発明を実現するよう構成されたキャリア上のコンピュータプログラムに拡張されるということは理解されるであろう。このプログラムは、ソースコード、オブジェクトコード、部分的にコンパイルされた形式などによるコード中間ソースオブジェクトコードの形式、又は本発明による方法の実現に利用するのに適した他の任意の形式によるものとされてもよい。キャリアは、プログラムを搬送可能な任意のエンティティ又は装置である。例えば、このキャリアは、ＲＯＭ、ＣＤ−ＲＯＭ、半導体ＲＯＭなどの記憶媒体、又はフロッピー（登録商標）ディスクやハードディスクなどの磁気記録媒体を有するものであってもよい。さらに、キャリアは、電気又は光ケーブル、無線又は他の手段を介し伝達可能な電気又は光信号などの送信可能なキャリアであってもよい。プログラムがこのような信号に実現されるとき、キャリアは、このようなケーブルや他の装置又は手段により構成されてもよい。あるいは、キャリアは、プログラムが埋め込まれ、本方法の実行に利用され、又は本方法を実行するよう構成された集積回路であってもよい。
【００６６】
上述の実施例は、本発明を限定するものではなく、例示するためのものであり、添付された請求項の範囲から逸脱することなく当業者は他の多数の実施例を設計可能であるということに留意すべきである。請求項では、括弧内の任意の参照符号は、請求項を限定するものとして解釈されるものではない。動詞「有する」とそれの派生語の使用は、請求項に記載された以外の要素又はステップの存在を排除するものではない。要素に前置される「ある」という冠詞は、当該要素が複数存在することを排除するものではない。本発明は、複数の要素を有するハードウェアにより、また適切にプログラムされたコンピュータにより実現されてもよい。複数の手段を列挙した装置クレームでは、これらの手段のいくつかが単一の同一ハードウェアにより実現されてもよい。ある手段が相互に異なる従属クレームに記載されているという事実は、これらの手段の組み合わせが効果的に利用可能でないことを示すものではない。
【図面の簡単な説明】
【００６７】
【図１】図１は、企業間の世界的な協調を示す。
【図２】図２は、協力企業間の製品データ交換を示す。
【図３】図３は、本発明によるシステムのブロック図を示す。
【図４】図４は、製品データ交換のためのデルタパッケージの利用を示す。
【図５】図５は、デルタパッケージのさらなる利用を示す。
【図６】図６は、製品データ交換パッケージの構造を示す。
【図７】図７は、一例となるパッケージを示す。
【図８】図８は、オーナーシップの移転を示す。
【図９】図９は、問題報告を示す。
【特許請求の範囲】
【請求項１】
複数の協力企業の各コンピュータシステムの間で技術的製品データをやりとりするための製品データ交換システムであって、
前記協力企業の第１の協力企業の少なくともコンピュータシステムは、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムと、
前記複数のデータ管理システムからユーザ選択可能なプロジェクトに関する技術的製品データをインポートし、前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成し、前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する編集システムと、
を有することを特徴とする製品データ交換システム。
【請求項２】
請求項１記載の製品データ交換システムであって、
前記協力企業の少なくとも１つのコンピュータシステムは、
技術的製品データに対し処理を実行するさらなるデータ管理システムと、
前記交換パッケージを抽出し、ユーザ選択可能な技術的製品データを前記交換パッケージから前記さらなるデータ管理システムにエクスポートする第２の編集システムと、
を有することを特徴とする製品データ交換システム。
【請求項３】
請求項１記載の製品データ交換システムであって、
前記協力企業の少なくとも１つのコンピュータは、前記交換パッケージを抽出し、前記抽出した交換パッケージの技術的製品データのユーザ選択可能部分をさらなる交換パッケージに合成し、前記さらなる交換パッケージを前記協力企業の少なくとも１つの下請け業者にあるコンピュータシステムに提供する第３の編集システムを有することを特徴とする製品データ交換システム。
【請求項４】
請求項１記載の製品データ交換システムであって、
前記編集システムは、
技術的製品データを前記交換パッケージに追加する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を削除する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を変更する制御処理と、
のうちの少なくとも１つをユーザが実行することを可能にするよう動作することを特徴とする製品データ交換システム。
【請求項５】
請求項１記載の製品データ交換システムであって、
前記編集システムは、当該編集システムのユーザの制御処理を表すトレーサビリティデータを前記交換パッケージに自動的に挿入するよう動作することを特徴とする製品データ交換システム。
【請求項６】
請求項４及び５記載の製品データ交換システムであって、
前記トレーサビリティデータは、
追加された技術的製品データについては、該追加された技術的製品データの表示と、
削除された技術的製品データについては、該削除された技術的製品データの表示と、
変更された技術的製品データについては、前記もとの技術的製品データと変更された技術的製品データの両方の表示と、
を有することを特徴とする製品データ交換システム。
【請求項７】
請求項１記載の製品データ交換システムであって、
前記編集システムは、前記複数のデータ管理システムから前記プロジェクトの同一のベースラインに関連する技術的製品データをインポートするよう動作することを特徴とする製品データ交換システム。
【請求項８】
請求項１記載の製品データ交換システムであって、
前記協力企業の少なくとも１つのコンピュータシステムは、前記交換パッケージを抽出し、前記抽出した交換パッケージの前記技術的製品データの少なくとも１つのエンティティに関連する問題報告データを追加し、拡張された交換パッケージを構成し、前記拡張された交換パッケージを協力企業の少なくとも１つのコンピュータシステムに提供する第４の編集システムを有することを特徴とする製品データ交換システム。
【請求項９】
請求項１記載の製品データ交換システムであって、
前記編集システムは、以前に提供された交換パッケージに表される技術的製品データに関する変更をカバーするデルタ記述の形式により、技術的製品データをさらなる交換パッケージに表し、前記以前に提供された交換パッケージへの参照を前記さらなる交換パッケージに含めるよう動作することを特徴とする製品データ交換システム。
【請求項１０】
請求項１記載の製品データ交換システムであって、
前記データ交換パッケージは、ヘッダと、特定のＣＡＤフォーマットなどのデータ管理システムに固有のフォーマットにより技術的製品データを表す任意的な添付とを有することを特徴とする製品データ交換システム。
【請求項１１】
請求項１記載の製品データ交換システムであって、
前記交換パッケージの技術的製品データは、複数のエンティティに構成され、
前記交換パッケージは、各エンティティについて、該エンティティのオーナーシップを有する前記協力企業の１つに関する情報を有し、
前記編集システムは、ユーザの制御の下、前記交換パッケージのユーザ選択可能なエンティティのオーナーシップの前記協力企業の他の１つへの移転をトリガーするよう動作する、
ことを特徴とする製品データ交換システム。
【請求項１２】
請求項１０及び１１記載の製品データ交換システムであって、
前記編集システムは、現在のオーナーの表示、所望のオーナーの表示、前記所望のオーナーへのオーナーシップの移転日の表示を前記交換パッケージのヘッダのメタデータに含めるよう動作することを特徴とする製品データ交換システム。
【請求項１３】
請求項１０記載の製品データ交換システムであって、
前記ヘッダのメタデータは、前記プロジェクトのサブプロジェクトに関する状態情報を有し、
前記編集システムは、データ管理システムからインポートされたデータ管理固有フォーマットによる状態情報を所定のフォーマットに変換するよう動作する、
ことを特徴とする製品データ交換システム。
【請求項１４】
請求項１０記載の製品データ交換システムであって、
前記ヘッダのメタデータは、添付間の関係を表す情報を有し、
前記関係は、
添付がさらに関連するエンティティにおいて情報を特定し、
添付の情報は、関連する添付の情報から派生され、
添付は、他の添付に階層的に関連付けされる、
ことの１つであることを特徴とする製品データ交換システム。
【請求項１５】
請求項１０記載の製品データ交換システムであって、
前記ヘッダのメタデータは、開発者のタスク、メーカーのタスク、サプライヤのタスク又はサービス／メンテナンスのタスクなど、前記協力企業のタスクに関する情報を有することを特徴とする製品データ交換システム。
【請求項１６】
請求項１０記載の製品データ交換システムであって、
前記ヘッダは、ＸＭＬフォーマットであることを特徴とする製品データ交換システム。
【請求項１７】
請求項１記載の製品データ交換システムにおいて利用され、複数の協力企業の各コンピュータシステムの間の技術的製品データをやりとりする編集システムであって、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートする手段と、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成する手段と、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する手段と、
を有することを特徴とする編集システム。
【請求項１８】
複数の協力企業の各コンピュータシステムの間の技術的製品データをやりとりする方法であって、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートするステップと、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成するステップと、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供するステップと、
を有することを特徴とする方法。
【請求項１９】
請求項１８記載の方法の各ステップをプロセッサに実行させるよう動作するコンピュータプログラム。
【請求項１】
複数の協力企業の各コンピュータシステムの間で技術的製品データをやりとりするための製品データ交換システムであって、
前記協力企業の第１の協力企業の少なくともコンピュータシステムは、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムと、
前記複数のデータ管理システムからユーザ選択可能なプロジェクトに関する技術的製品データをインポートし、前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成し、前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する編集システムと、
を有することを特徴とする製品データ交換システム。
【請求項２】
請求項１記載の製品データ交換システムであって、
前記協力企業の少なくとも１つのコンピュータシステムは、
技術的製品データに対し処理を実行するさらなるデータ管理システムと、
前記交換パッケージを抽出し、ユーザ選択可能な技術的製品データを前記交換パッケージから前記さらなるデータ管理システムにエクスポートする第２の編集システムと、
を有することを特徴とする製品データ交換システム。
【請求項３】
請求項１記載の製品データ交換システムであって、
前記協力企業の少なくとも１つのコンピュータは、前記交換パッケージを抽出し、前記抽出した交換パッケージの技術的製品データのユーザ選択可能部分をさらなる交換パッケージに合成し、前記さらなる交換パッケージを前記協力企業の少なくとも１つの下請け業者にあるコンピュータシステムに提供する第３の編集システムを有することを特徴とする製品データ交換システム。
【請求項４】
請求項１記載の製品データ交換システムであって、
前記編集システムは、
技術的製品データを前記交換パッケージに追加する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を削除する制御処理と、
前記インポートされた技術的製品データのユーザ選択可能部分を変更する制御処理と、
のうちの少なくとも１つをユーザが実行することを可能にするよう動作することを特徴とする製品データ交換システム。
【請求項５】
請求項１記載の製品データ交換システムであって、
前記編集システムは、当該編集システムのユーザの制御処理を表すトレーサビリティデータを前記交換パッケージに自動的に挿入するよう動作することを特徴とする製品データ交換システム。
【請求項６】
請求項４及び５記載の製品データ交換システムであって、
前記トレーサビリティデータは、
追加された技術的製品データについては、該追加された技術的製品データの表示と、
削除された技術的製品データについては、該削除された技術的製品データの表示と、
変更された技術的製品データについては、前記もとの技術的製品データと変更された技術的製品データの両方の表示と、
を有することを特徴とする製品データ交換システム。
【請求項７】
請求項１記載の製品データ交換システムであって、
前記編集システムは、前記複数のデータ管理システムから前記プロジェクトの同一のベースラインに関連する技術的製品データをインポートするよう動作することを特徴とする製品データ交換システム。
【請求項８】
請求項１記載の製品データ交換システムであって、
前記協力企業の少なくとも１つのコンピュータシステムは、前記交換パッケージを抽出し、前記抽出した交換パッケージの前記技術的製品データの少なくとも１つのエンティティに関連する問題報告データを追加し、拡張された交換パッケージを構成し、前記拡張された交換パッケージを協力企業の少なくとも１つのコンピュータシステムに提供する第４の編集システムを有することを特徴とする製品データ交換システム。
【請求項９】
請求項１記載の製品データ交換システムであって、
前記編集システムは、以前に提供された交換パッケージに表される技術的製品データに関する変更をカバーするデルタ記述の形式により、技術的製品データをさらなる交換パッケージに表し、前記以前に提供された交換パッケージへの参照を前記さらなる交換パッケージに含めるよう動作することを特徴とする製品データ交換システム。
【請求項１０】
請求項１記載の製品データ交換システムであって、
前記データ交換パッケージは、ヘッダと、特定のＣＡＤフォーマットなどのデータ管理システムに固有のフォーマットにより技術的製品データを表す任意的な添付とを有することを特徴とする製品データ交換システム。
【請求項１１】
請求項１記載の製品データ交換システムであって、
前記交換パッケージの技術的製品データは、複数のエンティティに構成され、
前記交換パッケージは、各エンティティについて、該エンティティのオーナーシップを有する前記協力企業の１つに関する情報を有し、
前記編集システムは、ユーザの制御の下、前記交換パッケージのユーザ選択可能なエンティティのオーナーシップの前記協力企業の他の１つへの移転をトリガーするよう動作する、
ことを特徴とする製品データ交換システム。
【請求項１２】
請求項１０及び１１記載の製品データ交換システムであって、
前記編集システムは、現在のオーナーの表示、所望のオーナーの表示、前記所望のオーナーへのオーナーシップの移転日の表示を前記交換パッケージのヘッダのメタデータに含めるよう動作することを特徴とする製品データ交換システム。
【請求項１３】
請求項１０記載の製品データ交換システムであって、
前記ヘッダのメタデータは、前記プロジェクトのサブプロジェクトに関する状態情報を有し、
前記編集システムは、データ管理システムからインポートされたデータ管理固有フォーマットによる状態情報を所定のフォーマットに変換するよう動作する、
ことを特徴とする製品データ交換システム。
【請求項１４】
請求項１０記載の製品データ交換システムであって、
前記ヘッダのメタデータは、添付間の関係を表す情報を有し、
前記関係は、
添付がさらに関連するエンティティにおいて情報を特定し、
添付の情報は、関連する添付の情報から派生され、
添付は、他の添付に階層的に関連付けされる、
ことの１つであることを特徴とする製品データ交換システム。
【請求項１５】
請求項１０記載の製品データ交換システムであって、
前記ヘッダのメタデータは、開発者のタスク、メーカーのタスク、サプライヤのタスク又はサービス／メンテナンスのタスクなど、前記協力企業のタスクに関する情報を有することを特徴とする製品データ交換システム。
【請求項１６】
請求項１０記載の製品データ交換システムであって、
前記ヘッダは、ＸＭＬフォーマットであることを特徴とする製品データ交換システム。
【請求項１７】
請求項１記載の製品データ交換システムにおいて利用され、複数の協力企業の各コンピュータシステムの間の技術的製品データをやりとりする編集システムであって、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートする手段と、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成する手段と、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供する手段と、
を有することを特徴とする編集システム。
【請求項１８】
複数の協力企業の各コンピュータシステムの間の技術的製品データをやりとりする方法であって、
各々が各技術的製品データを生成する、ＣＡＤ、ＰＬＭ、ＥＲＰなどの複数の相異なるデータ管理システムからユーザ選択可能なプロジェクトに関連する技術的製品データをインポートするステップと、
前記インポートされた技術的製品データのユーザ選択可能部分を表す交換パッケージを生成するステップと、
前記交換パッケージをその他の協力企業の少なくとも１つにあるコンピュータシステムに提供するステップと、
を有することを特徴とする方法。
【請求項１９】
請求項１８記載の方法の各ステップをプロセッサに実行させるよう動作するコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２００７−５１６５１６（Ｐ２００７−５１６５１６Ａ）
【公表日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願番号】特願２００６−５３９０３３（Ｐ２００６−５３９０３３）
【出願日】平成１６年１１月４日（２００４．１１．４）
【国際出願番号】ＰＣＴ／ＩＢ２００４／０５２３１１
【国際公開番号】ＷＯ２００５／０４８１４６
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願日】平成１６年１１月４日（２００４．１１．４）
【国際出願番号】ＰＣＴ／ＩＢ２００４／０５２３１１
【国際公開番号】ＷＯ２００５／０４８１４６
【国際公開日】平成１７年５月２６日（２００５．５．２６）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]