JP2023542609A - コンポーネント間の検査要件の設計符号化 - Google Patents

コンポーネント間の検査要件の設計符号化 Download PDF

Info

Publication number
JP2023542609A
JP2023542609A JP2023508519A JP2023508519A JP2023542609A JP 2023542609 A JP2023542609 A JP 2023542609A JP 2023508519 A JP2023508519 A JP 2023508519A JP 2023508519 A JP2023508519 A JP 2023508519A JP 2023542609 A JP2023542609 A JP 2023542609A
Authority
JP
Japan
Prior art keywords
inspection
requirements
mbd
trigger
assembly
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023508519A
Other languages
English (en)
Inventor
ルブナー、ジョーセフ
Original Assignee
キトフ システムズ リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by キトフ システムズ リミテッド filed Critical キトフ システムズ リミテッド
Publication of JP2023542609A publication Critical patent/JP2023542609A/ja
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41875Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by quality surveillance of production
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/32Operator till task planning
    • G05B2219/32186Teaching inspection data, pictures and criteria and apply them for inspection
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/80Management or planning

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Automation & Control Theory (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Artificial Intelligence (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • General Factory Administration (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Interconnected Communication Systems, Intercoms, And Interphones (AREA)

Abstract

製造物のアセンブリツリーにより定義されるアセンブリレベルの特性が、製造物に対する検査要件の特定(即ち選択及び/又は準備)を支援するトリガ述語として分析される。特に重点が置かれるのは、アセンブリの特定、検査に対するアセンブリの可視性/アクセス性に及ぼす製造の影響、及び検査要件をトリガするアセンブリレベルのセマンティックスの使用、という階層的関係である。特定された検査要件は任意選択的に、オープン(セマンティック)あるいはクローズドである。いくつかの実施形態では、特定された検査要件は検査計画を生成するように構成された自動検査計画システムに提供され、その計画の実行が検査要件を満たす。

Description

本出願は、2020年8月5日出願の米国仮特許出願第63/061、206号の米国特許法35USC§119(e)に基づく優先権の利益を主張し、その内容は参照によりその全体が本明細書に組み込まれる。
本発明は、そのいくつかの実施形態において検査の分野に関し、より具体的には、製造品質管理のための自動検査に関するが、これに限られない。
製造物が関与するような多くの産業において、欠陥がないことを確認するために製品を検査することは有益であり得る。そのような検査はしばしば手作業で(例えば検査員によって)行われ、様々な不正確さや非効率性を生じる可能性がある。
本開示のいくつかの実施形態の一態様によれば、製造物に対する外観検査要件を定義する方法が提供される。この方法は、製造物の設計モデルを含むモデルベース定義(model-based definition:MBD)にアクセスし、MBDによって指定されたコンポーネント間の関係の自動分析に基づいて、製造物のコンポーネントに対する検査要件を特定し、製造物の外観検査の機械プラニング(機械による計画作成)に使用するために、特定された検査要件を符号化することを含む。
本開示のいくつかの実施形態によれば、MBDは設計モデルで指定されたコンポーネント間の階層関係を指定し、特定された検査要件は、MBDで指定されたコンポーネント間の具体的な階層関係を特定する自動分析に基づく。
本開示のいくつかの実施形態によれば、コンポーネント間の階層関係は、製造物のアセンブリ間の関係に対応する。
本開示のいくつかの実施形態によれば、検査要件の特定は、MBDで指定されたコンポーネント間の幾何学的関係を特定する自動分析に基づく。
本開示のいくつかの実施形態によれば、検査要件の特定は、MBDで指定されたコンポーネント特性のパターンを特定する自動分析に基づく。
本開示のいくつかの実施形態によれば、この方法は、検査要件を満たす外観検査計画を生成することと、製造物の少なくとも1つのインスタンスに外観検査計画を実行することとを含む。
本開示のいくつかの実施形態によれば、検査要件は、MBDにより指定された1以上のコンポーネントの検査に関する品質上の懸念を、その品質懸念に対応する特性やアクションの指定なしに指定するオープン検査要件を含む。
本開示のいくつかの実施形態によれば、オープン要件はセマンティック(意味論的)要件である。
本開示のいくつかの実施形態によれば、外観検査計画を生成することは、オープン検査要件を、コンポーネントの特性とそれらの特性の測定アクションとを指定した対応するクローズド検査要件に変換することを含む。
本開示のいくつかの実施形態によれば、変換はMBDを使用する。
本開示のいくつかの実施形態によれば、外観検査計画の生成は、MBDによって指定される階層情報を使用して、検査要件を満たすアクションを実行すべき段階を決定することを含む。
本開示のいくつかの実施形態によれば、外観検査計画の生成は、MBDによって指定される幾何学的情報を使用して、検査要件を満たすアクションを実行すべき段階を決定することを含む。
本開示のいくつかの実施形態によれば、自動処理が、オープン検査要件に基づいて、変換のためにMBDからどの情報を抽出すべきかを決定する。
本開示のいくつかの実施形態によれば、検査要件はオープン検査要件のみを含む。
本開示のいくつかの実施形態によれば、検査要件は、特性と、外観検査計画実行時に特性測定のために遂行される測定アクションとを指定するクローズド検査要件を含む。
本開示のいくつかの実施形態によれば、符号化は検査指定データ要素をMBDに挿入することを含む。
本開示のいくつかの実施形態によれば、MBDは1以上のQIFファイルとして指定され、検査指定データ要素は1以上のQIFファイルの要素を参照して定義される。
本開示のいくつかの実施形態によれば、検査指定データ要素はXMLとして定義される。
本開示のいくつかの実施形態によれば、挿入された検査指定データ要素に基づいて、MBD内の設計仕様を調整することを含む。
本開示のいくつかの実施形態によれば、挿入された検査指定データ要素に基づいて、製造計画を調整することを含む。
本開示のいくつかの実施形態によれば、特定することは、MBD内に定義されたコンポーネント間に指定された階層関係の分析に基づいて、予め定義された検査要件ライブラリから、検査要件を選択することを含む。
本開示のいくつかの実施形態によれば、MBD文書階層の分析は、選択された検査要件の選択条件である述語トリガを特定することを含む。
本開示のいくつかの実施形態によれば、述語トリガの特定は、所定のコンポーネント構成を含むアセンブリを特定することを含む。
本開示のいくつかの実施形態によれば、述語トリガの特定は、アセンブリ内のコンポーネントの可視性を判定することを含む。
本開示のいくつかの実施形態によれば、述語トリガの特定は、アセンブリ内のコンポーネントのアクセス性を判定することを含む。
本開示のいくつかの実施形態によれば、述語トリガの特定は、MBDによって指定された設計階層仕様内のテキストコンテンツの分析を含む。
本開示のいくつかの実施形態によれば、調整入力が述語トリガの特定を修正して、特定の仕方を変化させる。
本開示のいくつかの実施形態によれば、調整入力は、手動による入力を含む。
本開示のいくつかの実施形態によれば、調整入力は、検査方針を符号化するデータを含む。
本開示のいくつかの実施形態によれば、調整入力は、部品在庫、部品供給源、工具状態、工具可用性、作業者訓練状態、労働力配分、の1以上に関する工場状態を記述するデータを含む。
本開示のいくつかの実施形態によれば、本方法は、調整入力に従って、選択を修正することを含む。
本開示のいくつかの実施形態によれば、修正は、特定の検査要件を追加、削除または修正することを含む。
本開示のいくつかの実施形態によれば、調整入力は、手動による入力を含む。
本開示のいくつかの実施形態によれば、調整入力は、検査方針を符号化するデータを含む。
本開示のいくつかの実施形態によれば、調整入力は、部品在庫、部品供給源、工具状態、工具可用性、作業者訓練状態、労働力配分の1以上に関する工場状態を記述する。
本開示のいくつかの実施形態によれば、特定することは、選択された検査要件を準備することを含む。
本開示のいくつかの実施形態によれば、MBD文書は、1以上のQIFファイルを含む。
本開示のいくつかの実施形態によれば、検査要件は、アセンブリが、セマンティック検査エージェントが利用可能なクラスに属することを示すトリガ述語をMBD内で特定することに基づいて選択される、オープン検査要件である。
本開示のいくつかの実施形態の一態様によれば、製造物に対する外観検査要件を定義するシステムが提供される。このシステムは、コンピュータプロセッサとメモリを備え、コンピュータプロセッサはメモリ媒体内の命令にアクセスするように構成され、命令はプロセッサに対して、メモリから製造物の設計モデルを含むモデルベース定義(MBD)にアクセスし、MBDによって指定されたコンポーネント間の関係の自動分析に基づいて製造物のコンポーネントに対する検査要件を特定し、製造物の外観検査の機械プラニングに使用するために特定された検査要件を符号化する、ように指示する。
本開示のいくつかの実施形態によれば、MBDは、1以上のQIFフォーマットファイルを含む。
本開示のいくつかの実施形態によれば、特定された検査要件はXMLファイルとして符号化される。
本開示のいくつかの実施形態によれば、MBDは設計モデルで指定されたコンポーネントの階層関係を指定し、コンピュータプロセッサは、前記MBDで指定されたコンポーネント間の特定の階層関係を特定することにより検査要件を特定する。
本開示のいくつかの実施形態によれば、コンポーネント間の階層関係は、製造物のアセンブリ間の関係に対応する。
別段の定義がない限り、本明細書で使用するすべての技術用語および科学用語は、本開示が属する技術分野の当業者により一般に理解されるものと同じ意味を有する。本明細書に記載のものと類似又は同等の方法及び材料が、本開示の実施形態の実行又は試行に使用可能であるが、例示的な方法及び/又は材料を以下に記述する。矛盾する場合には、定義を含む本発明の明細書が優先される。さらに、材料、方法及び実施例は例示に過ぎず、必ずしも制限的であることを意図するものではない。
当業者には理解されるように、本開示の態様は、システム、方法又はコンピュータプログラム製品として具体化され得る。したがって、本開示の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態(ファームウェア、常駐ソフトウェア、マイクロコードなどを含む)、又はソフトウェアとハードウェアの側面を含む実施形態の形をとり得る。これらはすべて、本明細書においては「回路」、「モジュール」又は「システム」と総称され得る(例えば、方法は「コンピュータ回路」を用いて実施可能である)。さらには、本開示のいくつかの実施形態は、具体化されたコンピュータ可読プログラムコードをそこに有する、1以上のコンピュータ可読媒体内に具体化されたコンピュータプログラム製品の形態をとり得る。本開示のいくつかの実施形態の方法及び/又はシステムの実施は、選択されたタスクを手動、自動又はそれらの組み合わせで実行又は完了させることを含み得る。さらに、本開示の方法及び/又はシステムのいくつかの実施形態の実際の計装機器及び設備によれば、いくつかの選択されたタスクは、ハードウェアによって、あるいはソフトウェアによって、ファームウェアによって、及び/又はそれらの組合せにより、例えばオペレーティングシステムを用いて、実施可能である。
例えば、本開示のいくつかの実施形態による、選択されたタスクを実行するためのハードウェアは、チップ又は回路として実装可能である。ソフトウェアとしては、本開示のいくつかの実施形態による選択されたタスクは、任意の適切なオペレーティングシステムを用いるコンピュータによって実行される複数のソフトウェア命令として実装可能である。本開示のいくつかの実施形態では、方法及び/又はシステムで実行される1以上のタスクは、複数の命令を実行するコンピューティングプラットフォームなどのデータプロセッサ(本明細書ではデジタルビットの複数のグループを用いて動作するデータプロセッサを指して「デジタルプロセッサ」とも呼ばれる)により実行される。任意選択により、データプロセッサには、命令とデータの少なくともいずれかを格納する揮発性メモリと、命令とデータの少なくともいずれかを格納する、例えば磁気ハードディスクとリムーバブル媒体の少なくともいずれかである不揮発性記憶装置と、の少なくともいずれかが含まれる。任意選択的に、ネットワーク接続も提供される。ディスプレイ及び/又はキーボードやマウスなどのユーザ入力装置もまた任意選択で提供される。これらの実装の任意のものを、本明細書では一般的にコンピュータ回路のインスタンスとして指す。
1つ以上のコンピュータ可読媒体の任意の組み合わせが、本開示のいくつかの実施形態のために利用可能である。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体であってよい。コンピュータ可読記憶媒体は、これらに限らないが、例えば、電子、磁気、光学、電磁気、赤外線、又は半導体のシステム、装置又はデバイス、あるいはそれらの任意の適切な組合せであってよい。コンピュータ可読記憶媒体のより具体的な例(非網羅的なリスト)は、1つ以上のワイヤを有する電気接続、携帯型のコンピュータディスケット、ハードディスク、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、消去可能なプログラマブル読み出し専用メモリ(EPROM又はフラッシュメモリ)、光ファイバ、携帯型のコンパクトディスク読み出し専用メモリ(CD-ROM)、光記憶装置、磁気記憶装置、又はこれらの適切な組み合わせを含み得る。本明細書の文脈においては、コンピュータ可読記憶媒体は、命令を実行するシステム、装置又はデバイスにより使用されるか又はそれに接続されるプログラムを、保有又は格納することのできる、任意の有形媒体であってよい。コンピュータ可読記憶媒体は、そのようなプログラムで使用するための情報を保持又は格納することが可能であり、例えば、コンピュータ可読記憶媒体によって記録されてコンピュータプログラムが、例えば、1つ以上の表、リスト、配列、データツリー、及び/又は別のデータ構造などとしてアクセス可能なような構造をしたデータである。本明細書で、デジタルビットのグループとして読み出し可能な形態でデータを記録するコンピュータ可読記憶媒体もまた、デジタルメモリと呼ばれる。いくつかの実施形態において、コンピュータ可読記憶媒体が本質的に読み出し専用でなく、及び/又は読み出し専用状態でない場合には、コンピュータ可読記憶媒体は任意選択的にコンピュータ可読記憶媒体としても使用されることを理解されたい。
本明細書において、データプロセッサがコンピュータ可読メモリに結合されて、そこから命令及び/又はデータを受信し、処理し、及び/又は処理した結果を、同じか又は別のコンピュータ可読記憶メモリに格納するようになっている限りは、データプロセッサはデータ処理動作を実行するように「構成」されると言われる。実行される処理(任意選択的にデータに対して)は、命令により指定される。処理動作は、1以上の他の用語、例えば、比較する、評価する、決定する、計算する、識別する、関連付ける、保管する、解析する、選択する、及び/又は変換する、などにより追加的又は代替的に呼ばれるができる。例えば、いくつかの実施形態において、デジタルプロセッサがデジタルメモリから命令とデータを受信し、命令に従ってそのデータを処理し、及び/又は処理結果をデジタルメモリ内に格納する。いくつかの実施形態において、処理結果を「提供する」ことは、処理結果の送信、格納、及び/又は提示の1つ以上を含む。提示することは任意選択的に、ディスプレイに表示すること、音で示すこと、印刷出力すること、あるいはその他の人間の知覚能力にアクセス可能な形で結果を与えることを含む。
コンピュータ可読信号媒体は、コンピュータ可読プログラムコードがその中に具体化された伝搬データ信号を、例えばベースバンドに、又は搬送波の一部として含み得る。そのような伝搬信号は、これらに限らないが、電磁的、光学的、又はそれらの任意の適切な組み合わせを含む、種々の形態の任意のものであってよい。コンピュータ可読信号媒体は、命令を実行するシステム、装置、又はデバイスで、又はそれに接続して使用するために、プログラムを通信、伝搬又は輸送することのできる、コンピュータ可読記憶媒体以外の任意のコンピュータ可読媒体であってよい。
コンピュータ可読媒体に具体化されたプログラムコード、及び/又はそれによって使用されるデータは、任意の適切な媒体を用いて送信され得る。その媒体には、これらに限らないが、無線、有線、光ファイバケーブル、RFなど、あるいはそれらの任意の適切な組み合わせが含まれる。
本開示のいくつかの実施形態の操作を実行するためのコンピュータプログラムコードは、Java(登録商標)、Smalltalk、C++などのオブジェクト指向プログラミング言語と、「C」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語、を含む、1つ以上のプログラミング言語の任意の組合せで書くことが可能である。プログラムコードは、スタンドアロンソフトウェアパッケージとして、全体がユーザのコンピュータ上で、一部がユーザのコンピュータ上で、一部はユーザのコンピュータ上でかつ一部はリモートコンピュータ上で、あるいは全体がリモートコンピュータもしくはサーバ上で実行されることが可能である。後者の場合には、リモートコンピュータは、ローカルエリアネットワーク(LAN)またはワイドエリアネットワーク(WAN)を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよいし、(たとえば、インターネットサービスプロバイダーを利用したインターネット経由で)外部コンピュータに接続されてもよい。
本開示のいくつかの実施形態を、本開示の実施形態による方法、装置(システム)及びコンピュータプログラム製品の、フローチャート図及び/又はブロック図を参照して以下で説明する。フローチャート図及び/又はブロック図の各ブロック、及びフローチャート図及び/又はブロック図の複数のブロックの組合せは、コンピュータプログラム命令によって実装可能であることが理解されよう。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、又は機械を形成する他のプログラム可能なデータ処理装置のプロセッサに提供されて、コンピュータ又は他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャート及び/又はブロック図の1つ又は複数のブロックで特定される機能/動作を実施するための手段を生成する。
またこれらのコンピュータプログラム命令は、コンピュータ、他のプロブラム可能データ処理装置、又は他の装置を特定の形で機能させるように指示可能なコンピュータ可読媒体に格納することが可能であって、コンピュータ可読媒体に格納された命令が、フローチャート及び/又はブロック図の1つ又は複数のブロックで指定された機能/動作を実施する命令を含む製造品を製造可能とする。
コンピュータプログラム命令はまた、コンピュータや他のプログラム可能データ処理装置や他の装置にロードされて、コンピュータや他のプログラム可能データ処理装置や他の装置に一連の動作ステップを実行させてコンピュータ実装プロセスを生成させることが可能である。そうして、コンピュータや他のプログラム可能装置で実行される命令が、フローチャートおよび/またはブロック図の1つまたは複数のブロックで指定された機能/動作を実施する処理を提供する。
本開示のいくつかの実施形態を、ここに添付図面を参照して例示としてのみ説明する。ここで、図面に対して詳細に具体的な参照をするが、示される細目は一例であって、本開示の実施形態の例示的議論を目的とするものであることが強調される。これに関し、図面と共に行われる説明により、本開示の実施形態がどのように実施され得るかが当業者には明らかとなる。
本開示のいくつかの実施形態による、検査要件を自動的に特定する方法の模式図である。 本開示のいくつかの実施形態による、製造物に対するアセンブリツリーに基づく検査要件を自動的に特定するシステムの模式図である。 本開示のいくつかの実施形態による、オープン検査要件仕様とクローズド検査要件仕様を模式的に比較した図である。 本開示のいくつかの実施形態による、モデルベースの設計文書の態様の模式図である。 本開示のいくつかの実施形態による、アセンブリツリー内のコンポーネントベースのトリガ述語を特定する方法の模式図である。 本開示のいくつかの実施形態による、アセンブリツリー内のテキストベースのトリガ述語を特定する方法の模式図である。 本発明のいくつかの実施形態による、キーボードの検査部分の画像を示す模式図である。 本発明のいくつかの実施形態による、コンピュータケースの一部の画像を示す模式図である。
本発明は、そのいくつかの実施形態において検査の分野に関し、より具体的には、製造品質管理のための自動検査に関するが、これに限るものではない。
(概説)
検査要件の自動的選択
本開示のいくつかの実施形態の広範な態様は、製造物の設計/製造文書から抽出される情報を用いた、製造物の外観検査要件の自動的な選択及び/又は準備に関する。いくつかの実施形態では、これは潜在的な検査要件のライブラリが、1以上のトリガ述語に従って検査要件を意味的にグループ分けするシステム及び/又は方法を使用して可能となる。
例えば、あるグループ化は「Yするものに対して、X1、X2…を検査する」ことを効果的に定義可能である。この定式では、「Y」がトリガ述語であり、「X1、X2…」が検査要件のグループである。トリガ述語及び/又は検査要件はさらにパラメータ化可能であり、パラメータは任意選択的に、例えば、手動の入力、品質方針、及び/又は設計/製造文書(例えば、設計/製造文書によって指定される形状及び/又はコンポーネント間の関係)から収集された入力に従って、提供され得る。設計文書及び/又は製造文書内のトリガ述語を自動的に特定する機能が提供される。
例えば、部品(すなわち製造される製品のコンポーネント(構成要素)として使用され、製造物内での3D姿勢などの特定の属性を有する品目)は、それが何であり、それが何を有し、及び/又は他の1以上のコンポーネントとどのように係わるか、というようなトリガ述語の故に、検査要件に属する可能性がある。トリガ述語は好ましくは、設計/製造計画の所産として得られる文書(例えば、アノテーション付きで、任意選択的に階層化された3Dモデル)から決定される。
特定されたトリガ述語を使用して、意味的にグループ分けされた検査要件を、例えば、検査計画によって満たされる要件として、製造物の品質検査プロセスへ関連付ける。
いくつかの実施形態では、実行される検査は、より具体的には、例えば画像での外観に基づいて行われる製造物検査などの外観検査である。これは例えば、検査物に直接接触して動作する測距装置の使用によって距離を基にした測定を行なう計量検査とは区別することができる。
トリガ述語
本明細書においてトリガ述語とは、何らかのプロセスの文脈内でセマンティック情報(後述)へのリンク(意味上の関連)を意味するとして認識される、与えられた情報セット内の任意の事実(又は事実の複合体)である。
トリガ述語は、ラベル的かつ特性的な側面に従ってさらに特徴づけることが可能である。例示目的で単純化した例としては、赤いボールと青いキューブから成る物体の複合的集合を操作するプロセスが考えられる。このプロセスの文脈内では、赤い物体が特定されれば、それはボールでもある。この文脈において「赤い」ということは、その物体がボールの操作に適したセマンティック特性を有することを認識するためのトリガ述語として使用可能である。プロセスの目的に関しては、その物体は、「ボールであり」、操作に係わるボール様の特性(例えば、それは転がり、その高さの半分の位置が最大である)を有する。あるいは、トリガ述語は、「湾曲した輪郭を有する」というような、それがリンクするセマンティックスにより固有なものであってもよい。このことは、トリガ述語がどのようにして、付随的又はラベル的な側面(「赤い」ということは丸いことには関係がないにも拘らず、例におけるすべての丸い物体に選択可能なタグを与える)、又は固有の/特性的な側面(「湾曲した」ということは丸い物体であることの帰結である)を有し得るかを説明する。どちらの側面も、また2つの側面を組合せ得るトリガ述語と同様に、本開示のいくつかの実施形態で任意選択的に使用される。
本開示は製造物の検査プロセスに関する。いくつかの実施形態において、トリガ述語は、製造物を指定し、あるいはそれ自体は品質検査計画とは別の用途のために存在する、設計/製造文書の態様から特定される。トリガ述語は、製品の「特性」(例えば製品の形状及び/又は組成)を文書化可能であり、又は「ラベル」(例えばコンポーネントの名前及び/又はコンポーネントのアセンブリの名前)を含むことができ、又はそれらの何らかの組み合わせ(例えばテキスト文書化が特性を示すラベルに通常依存している限りにおいて)を含み得る。
本開示のいくつかの実施形態において、トリガ述語は、製造物の設計/製造文書のデータ要素、例えばデータ要素仕様、ラベル、テキスト、及び/又は画像などに由来する。設計/製造文書からのトリガ述語の特定は、例えば、手動操作のコンピュータ入力装置、音声-テキスト変換入力機能、ユーザ動作トラッキング、あるいは別の入力方法の使用を介して、手動で支援され得る。
トリガ述語は、好ましくは設計/製造文書に本来備わったものである。ただし、それらは任意選択的に、特に検査要件に関係する理由で、設計/製造文書に挿入されてもよい。任意選択的に、トリガ述語は設計/製造ファイル自体の外部から調整入力を使用して特定される。任意選択的に、自動的に選択された検査要件は、更なる準備プロセス、例えばパラメータ付与あるいはそれらの除去又は削除(自動及び/又は手動による)を受ける。
トリガ述語とセマンティック情報
本明細書において、セマンティック情報とは、何かを表記(denote)する部分として(例えばコンピュータ処理システムによって実行される)処理に入る情報を示すように使用される。
例えば、3D図面内の頂点と稜の集合から成る特定要素は(例えば、type=”screw”で例示されるようなテキストで符号化された属性を用いてラベル付けすることにより)「ねじ」として更に分類可能である。純粋に構文の問題として、このことは特定の形式的な方法で、例えば、typeとラベル付けされた属性に割り当てられたテキストに基づいて、要素を、要素の選択及びグループに属させることにより、図面の情報を増やすことが可能である。ただしそのラベルは、そのままではその観点でのねじを表記する作用をしない。予想される構文に従って、その図面内で一貫性を持って使用される別のラベルが、同じ構文情報を伝達する。
ただし、トリガ述語として作用する同じラベルが、コンピュータ処理システムに、特定のセマンティック情報を要素に関連付けさせることも可能である。追加的又は代替的に、(らせん形状をした外表面などの)頂点や線自体の属性が、その要素がねじであることを表記し得るトリガ述語となり得る。
表記(denotation)がもたらすセマンティック情報は、処理システムに対して「ねじであることを意味するもの」を具現化し得る。もっと機械的なレベルでは、この意味は、トリガ述語そのものを超える結果(任意選択的には究極的な物理的結果)を付与する。これらの結果は、例えばデジタル符号化され、及び/又は機械のねじに適切なアクションに結び付けることが可能である。セマンティック情報は本明細書においては、特に共通のトリガ述語を介して要素に意味的に関連づけられる場合、セマンティックグループを構成するものとしてまとめて言及され得る。
複数の論理的に符号化された要素にわたって分布する(例えば何かのパターンに適合する)事実もまた、本開示のいくつかの実施形態においてはトリガ述語として作用することができる。例えば、あるアセンブリ要素は、type:車輪である2つの下位要素のそれぞれに取り付けられているという関係を有する、type:車軸である下位要素を含む、として構文的に指定され得る。このパターンはこれによりトリガ述語になり得、これは処理されて、車軸に取り付けられた車輪が、車軸の対向する両端で、その中心において回転するように装着されるというセマンティック情報を示す。検査システムの文脈において、1つの結果は、アセンブリ要素の回転機能のテストの実行であり得る。この種の「分散型事実」から成るパターンは、サブアセンブリに限らない。例えば、トリガ述語には、別々に組み立てられた同じ色の縁要素、あるいは製造物の機能的に特定の(例えば内側、外側、上部、下部)表面に露出された締結具、のような事実が含まれ得る。
オープン/セマンティック仕様
いくつかの実施形態において、セマンティック関連付けの処理は、本明細書においてセマンティック仕様と称する中間要素で媒介される。セマンティック仕様は、トリガ述語とそれにより示そうとするセマンティック情報と「の間」を明示的に関係させるものとして理解できる。一例として、特定のセマンティック仕様が、トリガ述語type=”screw”(これは設計文書のデータの特定ビットのテキストラベルとして定義可能である)を「溝付きヘッドとねじ付きシャフトから成る」というセマンティック情報に結び付けることができる。異なるセマンティック仕様が、トリガ述語size=”M4”を同一のセマンティック情報に結び付け、別の異なるセマンティック情報がトリガ述語type=”screw”を、「合致するねじ穴の存在を暗黙的に示す」のような更なるセマンティック情報に結び付けることが可能である。
さらに、セマンティック仕様は本明細書では、ドメイン固有の意味で、「オープン」(「クローズド」の反対として)であると呼ばれる。セマンティック仕様は、概して上位である。その意味が依存するより下位の基礎要素(プリミティブ)は未記述(「オープン」)のままである。しかしながらこの上位の記述は、セマンティック仕様が下流の適切な機能を有するエージェントによって解釈されるとき、具体的内容に分解される(セマンティック仕様を「クローズにする」)。「オープン」と「クローズド」は特定のドメインに関して定義されるプリミティブに関係する。本明細書に関連する検査仕様のドメインについて、これらのプリミティブは以下でより具体的に記述される。
一例として、トリガ述語type=”screw”の何らかの要素を認識すると、任意選択的に、その要素についてオープンセマンティック仕様rotatable=”true”を(例えば製造物の製造文書内に)生成させる。このことは、後続の処理段階で、恐らくは全般にスクリュー型の物体の回転可能性を再認識することなしに、かつその代わりにセマンティック仕様を直接認識することによって、その要素に「回転のセマンティックス」を適用させ得る。ここで、そのような後段の処理を実行する自動化モジュールもまた「セマンティックエージェント」と称され、具体的に品質検査を目的とする処理の場合には、特に「セマンティック検査エージェント」、あるいは単に「検査エージェント」と称される。
クロースドとオープン(セマンティック)仕様の関係
検査要件特定の具体的な文脈において、検査アクションが実際にどのように実行されるかについての詳細仕様(「プリミティブ」)の指定は延期したままで、セマンティック仕様は(例えば、元のトリガ述語を元とするラベルと、任意選択的にパラメータとによって)1以上の検査アクションを指定する。この延期が可能なことは「オープン」であることの特徴である。これは下位プリミティブに関する詳細についての交信を回避できるので、検査要件仕様の複雑さが軽減されるという潜在的な利点がある。
対照的に、例えば手動の、あるいは「下位の自動化された」品質検査プロセスで使用する場合、検査要件は検査される特性(実際に測定される製造物の特性)と、それらを検証する(すなわち測定を行い、任意選択的に測定結果を評価する)検査アクションとの直接的なリンク付けによって指定される。
そのような要件もまた本明細書では「クローズド」と称される。これらの特性及び/又はアクションは検査の「プリミティブ」を自己完結的に指定し、実用上の曖昧さをほとんど又は全く残さない。特にプリミティブは、その実装によって検査要件が要求する品質レベルが保証されるような詳細な検査プランの作成に使用されるためには、それ以上の説明も単純化も必要としない。外観検査の文脈において、プリミティブな測定には、これらに限らないが、ヒストグラム、勾配、ブロブ分析、形態(例えば距離と角度)及び面法線の測定が含まれる。下位の自動リソースを使用する品質検査(例えば自動計測など)は、クローズド検査要件を特定することで利益が得られる。それは与えられた詳細が、何を測定すべきかを厳密に提示することで、設定と検証における曖昧さの範囲が縮小されるからである。
本開示のいくつかの実施形態において、特定されたトリガ述語を基に選択及び/又は準備された検査要件は、「オープン」であって、意味的に指定される(本明細書では「セマンティック検査要件」とも称する)。実現されるために、セマンティック検査要件は(例えばセマンティック検査要件を処理するように構成された、適切なセマンティック検査エージェントによって)、特性および検査アクションのプリミティブに落とし込まれる。実際には、セマンティック検査要件は、セマンティック検査エージェントの操作によってクローズドとなる。
クローズドとなることは、セマンティック検査要件を、製造ファイルの他の情報と、及び/又はセマンティック検査要件を解釈するドメインナレッジの表現及び/又はインスタンス化と組み合わせることを含み得る。ここでも、有益な検査計画を定義可能とするために後でのプリミティブ(暗黙的又は明示的な)への落とし込みに頼ることは、セマンティック検査要件を「オープン」にする。
「オープン」な検査要件のすべてが必ずしも明示的に特定されるプリミティブへクローズされるわけではない。例えば、オープン検査要件は、ねじヘッドに工具の損傷マークがないことの検証を指定する場合がある。セマンティック検査エージェントにより実施される検証方法は、例えば、ねじヘッドを損傷のあり、なしで分類し、この分類を唯一の出力として生成する機械学習機能を適用することを含み得る。この場合にはまだクローズすべきものがある。なぜなら検査要件は評価すべきプリミティブな幾何学的特性をほとんど又は全く伝達していないし、また機械学習機能は依然としてこれらの特性の特徴に依存する結果を生成するからである。
任意選択的に、本開示のいくつかの実施形態のように決定されたセマンティック検査要件を受信した後、下流の検査計画システム(例えばセマンティック検査エージェント)が最終的に検査要件を「クローズ」する。検査計画システムは、要件をテストする測定について何を実際にどのようにして行うかを特定する計画を立てることによって、このことを行う。任意選択的に、「クローズド」検査要件のリストは実際に作成されない。あるいはリストがあるとしても(例えば検証目的で)、それは検査計画への入力というよりもむしろ検査計画の副産物である可能性がある。
特にオープンとクローズドの検査要件は、それが指定する情報の種類でさらに比較され得る。
・クローズド検査要件は、コンポーネント特性について実行すべき測定アクションを指定する。測定結果は1以上の指定された値と比較され、要件が満たされているかどうかが判定される。
・オープン検査要件は、特定の表記(denotation)(あるいは「クラス」)及び/又は関係を有する1つ又は複数のコンポーネントに関して、(例えばセマンティック検査エージェントにより)評価すべき品質懸念を指定する。
次いで、下流の検査リソース(例えば検査計画設備及び/又はセマンティック検査エージェント)が、懸念項目をコンポーネントの表記及びアノテーションに適した測定値に照合する責任を持つ。本開示のいくつかの実施形態では、アノテーションが検査要件と共に提供される。アノテーションは、いくつかの実施形態では、例えば特定の範囲のアセンブリレベル内で満たされなければならないか、満たされるべきであるというような、要件の階層的有効性に関する表示を含む。例えば、「早すぎる」検査は、検査標的がまだ製造されていないので行えない場合があり、「遅すぎる」検査は、検査標的が少なくとも部分的に隠れてしまっているか、さもなければアクセス困難であるために不可能である場合がある。
オープン(あるいはセマンティック)検査要件とクローズド(あるいは下位)検査要件との違いを説明する一例として、セマンティック検査要件が、「このコネクタが適切に取り付けられていることを確認する」ことであるとする。「コネクタ」が表記であり、「適切に取り付け」が懸念である。この要件をより具体的な検査アクションに変換することは、例えばセマンティック検査エージェントが動作するまでは延期される。コネクタは任意選択的に、そのサブタイプ、例えばRJ45又はDIN-9などの標準タイプ、拡張品番、又は別の仕様などでアノテーション(注釈付け)されている。対照的に、対応する下位の検査要件は、例えば方向角度、距離、はんだ付け位置の寸法、及び可能性としてはそれ以上の詳細を指定することになる。これらの特定のそれぞれは、関連する測定アクションと、許容値の範囲を有する特性である。それ自体が「スマートな」検査リソースであるセマンティック検査エージェントを使用する場合に対比して、これらの特性およびアクションは検査リソースが割り当て可能となる前にさえ明示される。
セマンティック仕様のレベルは例示したものよりもより詳細であることができる(例えば「適切に取り付けられた」という意味に影響する許容値などのパラメータでアノテーションされる)。ただしこれは、実際の測定プロセスに適用される解釈に依存するという意味でまだ依然として「オープン」である。
セマンティック検査要件の検査計画への使用
セマンティック検査仕様は、従来の品質保証(手動で、かつ特に低いレベルの自動化で操作される)の文脈では潜在的な不利を持つ。それは要件の態様を潜在的に曖昧(解釈の余地あるもの)にしたままであるからである。ただし、セマンティック検査要件は検査タスクにおけるハイレベルの予め定められた能力を有する、自動化された品質検査の文脈においては潜在的な利点がある。
特に高性能の検査ツールは検査標的の十分に豊富な(リッチ:rich)データ表現(すなわち検査標的の1以上の一般的クラス/表記など)を具現化可能であるので、セマンティック検査要件の履行(及び「クローズ」)を自律的に計画可能である。例えば、ツールは「適切に取り付けられた」というようなオープン要件を、その要件をクローズするのに必要なテストと評価に変換可能である。リッチデータ表現は、例えばどの特性が検査の懸念に関係するか、またそれらの特性を測定するために検査標的とどのように相互作用するか(例えば画像化するか)に関する情報を与える。
追加又は代替的に、リッチデータ表現は個別の特性のレベルを超えてよりグローバルな評価をするテスト能力を備え得る。例えば、ねじ込みソケットの損傷は、(特性とみなされる)その個別の表面を具体的に参照することなく、むしろ専用の機械学習製品が認識するように構成された、ソケット表面の集合体のパターン又は抽象的に指定される特徴を参照して評価可能である。ここでも再び、テスト要件のオープン仕様ではこの特徴は指定されず、おそらく特定の特徴は全く指定されない。その代わり、検査ツールが、どの特徴が検査要件の伝える懸念に関連しているかを「理解」する。
そのような機能を有する検査ツールを使用して、クローズド検査要件を生成し、それを介して交信することは不要かつ負荷が大きいと思えるかもしれない。特に、機械学習が実装された検査機能では、関連するクローズド検査要件の指定方法に関する知識は、自動検査ツールそのものの外部では入手できないかもしれない。これに対比して、セマンティック検査要件のオープンであることが、検査要件特定そのものの自動化を潜在的に支援する(例えば単純化する)。
上で定義した用語の枠組みに従って、本開示のいくつかの実施形態では、製造物に関するトリガ述語を特定し、その特定されたトリガ述語に従って意味論的にグループ分けされた検査要件を特定する、1以上の方法が提供される。検査要件はクローズドであってもよいし、いくつかの好適な実施形態ではオープンであってもよい。任意選択的に、検査要件は特定されると、設計/製造文書に統合される。
アセンブリツリー階層を用いた検査要件の選択
検査要件の特定を自動化しようとする努力は、いくつかの実施形態においては、タスクの異なる側面にそれぞれ対処するアプローチの集合をもたらし得るということは理解されるであろう。
本開示のいくつかの実施形態の一態様は、製造物のアセンブリツリー及び/又は製品ツリーによって定義される関係特性をトリガ述語として使用して、製造物に関する検査要件の特定(すなわち選択及び/又は準備)を支援することに関する。
いくつかの実施形態において、関係特性は設計階層、及び/又は設計における組み立てられたコンポーネント間の幾何学的関係に基づく。いくつかの関係特性は、例えば設計階層の異なる枝にまたがり、それ自体が幾何形状やアセンブリに関して特定の関係を持たない特性(例えば色、スタイル、部品分類、又は他の特性など)に基づく個別のコンポーネントのグループのような、別の又は追加的なタイプのものである。
本明細書で使用される用語として、アセンブリツリーと製品ツリーは両者ともに、階層的に構成されたリストであって、製造物設計文書の一部として指定され得るものである。階層構造のリーフ(最下層要素)はツリーの部品に対応するコンポーネントであり、上位ノードはコンポーネントグループであり、最終グループは製造物そのものである。2つのツリーは使用法が異なる。製品ツリーはCAD階層を反映する階層構造であり、それに対してアセンブリツリーは製造順序を反映する階層構造である。この2つは同じ階層構造を使用してもよいが、必ずしもそうである必要はない。例えば、CAD階層は、特性又は機能の類似性などの特性に基づいてコンポーネントをグループ化することができ、アセンブリツリーは、アセンブリ工程において(ノードが物理的なアセンブリに対応するように)相互に取り付けられるタイミングに基づいてコンポーネントをグループ化することができる。ここで、「設計階層」という用語は、アセンブリツリーと製品ツリーのいずれか又は両方を含む。
特定された検査要件は任意選択的に、オープン(セマンティック)あるいはクローズドである。任意選択により、特定された検査要件は検査計画を生成するように構成された自動検査計画システムに提供され、その計画のアクションが検査要件を履行する。
本開示のこの態様によれば、製造物内のいくつかのコンポーネントの関係が、検査要件のためのトリガ述語として特別の関連性を有し得る。
本開示のいくつかの実施形態では、製造物の設計階層が品質検査要件を選択するガイドとして使用される。設計階層を分析して、なんらかの特性の存在を探索する。次に分析出力をトリガ述語として使用して、それに基づいてアセンブリに適切な検査要件が割り当てられる。いくつかの実施形態では、分析出力はアセンブリの分類を含む。
いくつかの実施形態では、製造物内の少なくともいくつかのアセンブリが、ほぼ標準的なタイプのユニット、及び/又はほぼ標準的な特徴を有するユニットを備える。サブアセンブリのタイプは、特定の製造ドメイン(例えば特定の産業)内で繰り返される傾向がある。例えば、電子製品のアセンブリは、(数例を挙げるならば)キーボード、コネクタ群、回路基板、又はケースであり得る。家具製品のアセンブリには、枠、引き出し、レール、装飾部分、及びばねユニットなどの品目が含まれ得る。車両製造では膨大な数のアセンブリタイプがあり、例えばシャーシ、ボディ、エンジン、トランスミッション、ドア、及び計器ディスプレイである。これらのそれぞれはまた、それ自身の多数のサブアセンブリで構成されている。
設計及び製造文書内でアセンブリは、任意選択的に(通常そうであるが)タイプによってラベル付けされる。有効なラベルの範囲は、例えば、厳密に管理(例えば予め定義されたオプションリストに対して)されたもの、あるいは、より自由な形式のもの(設計者により入力された説明的な語句などの)であり得る。例えばアセンブリに関連するキーワードなどの、明示的にタイプ特定を行える、その他のテキスト情報も使用され得る。こうして、ラベルとキーワードは、全体として又は部分的に、アセンブリ分類の基礎となり得る。さらには、アセンブリ分類が、検査要件をアセンブリに関連付けるトリガ述語となる。これらの種類のアセンブリ分類は、前述したトリガ述語の「ラベル様の」態様にほぼ対応することに留意されたい。
追加的又は代替的に、アセンブリタイプは、アセンブリクラス呼称などのアセンブリ特徴、及び/又はコンポーネント間の幾何学的関係から、少なくとも部分的に特定することが可能である。タイプ識別はコンポーネント識別子によって直哲的に付与することができる。例えば、複数のコネクタコンポーネントから構成されるアセンブリは、それを基に、コネクタ群として分類可能である。複数のキーキャップから成るアセンブリは、キーボードとして分類可能である。追加的又は代替的に、幾何学性を利用して、コンポーネントの空間的な集合、コンポーネントの空間的近接性、あるいは別の幾何学的基準を基に、アセンブリ指定の助けとすることができる。コンポーネントを基にする特定は、任意選択的に、そのコンポーネントを含む特定のアセンブリレベル、例えば、それを組み込んだ第1又は第2のアセンブリレベルへ限定される。そのアセンブリは次いで他のアセンブリのサブアセンブリとなり、完全な製造物に対応するアセンブリにまで至るからである。
コンポーネントを基にするアセンブリタイプの特定は、1以上のコンポーネントの種類に依存する場合がある。例えば、車軸と2つの車輪の双方を含む第1のアセンブリレベルが、車輪付きの車軸アセンブリに指定され得る。追加的又は代替的に、アセンブリタイプの指定は、製造中に得られる非コンポーネント的特徴に基づいてもよい。例えば板金部品は、成形、切断、及び/又は仕上げの段階の後にしか(検査要件が関係する限りにおいて)ケースパネルになり得ない。
任意選択的に、アセンブリタイプは、そのような特徴に基づき、製造物のアセンブリツリーに沿って取得されるときに最初に特定され、次いで、このタイプが検査要件に関連するトリガ述語として扱われる。ただし、特徴そのものが、任意選択的に十分なトリガ述語であることを理解されたい。
アセンブリが単一のタイプであるべきという特別の制限はないことを理解されたい。アセンブリの分類は、任意選択的に、任意の数のタイプ特定及び/又は特徴に依存する。これによりそれらを単一の、ただし任意選択的には複合的に定義された、トリガ述語にグループ化することができる。追加的又は代替的に、トリガ述語はもっと簡単に定義することが可能であり(例えば、キーボードなどの主要アセンブリ分類として)、特定のキーボードの特徴及び/又はタイプの特定を、キーボードとして表記されたものを絞り込むためのアノテーションとして適用して、より明確な検査要件の特定を可能とすることができる。
アセンブリはまた適用される複数の分類(それによりトリガされる複数の対応する検査要件群に関連して)を有する場合もある。例えば、キーボードとして表記されるアセンブリが、インジケータボードとして表記されることもあり得る(例えば、状態及び/又はキーの押下に応じて点灯するLEDを搭載しているために)。本明細書で提供する説明は、単一ストリームの分析/分類/検査要件の例に特化する。ただし、複数ストリームの実施形態もまた本明細書の範囲内にあることを理解されたい。
本開示の少なくとも1つの実施形態を詳細に説明する前に、本開示はその適用が、以下の説明に提示され、及び/又は図面に示される、構成要素の構造と配置及び/又は方法の詳細に、必ずしも制限されるものではないことを理解されたい。本発明の特徴を含む、本開示で説明される特徴は、他の実施形態が可能であり、又は様々な方法で実行又は実施可能である。
検査要件の特定方法
ここで図1Aを参照する。これは本開示のいくつかの実施形態による、検査要件を自動特定する方法を、模式的に示す図である。任意選択的に、特定された検査要件は、設計及び/又は製造プロセス(製造及び/又は検査の一方又は両方を含む)にリンクされる(例えば、文書レベルでの挿入及び/又はデータ要素への参照によって)。
ブロック110において、いくつかの実施形態では、製品のコンポーネントの関係(例えば図2Aに関連して議論するような階層関係)が分析されて、トリガ述語の存在を判定する。任意選択的に、トリガ述語は設計階層の階層的な性質によって明らかにされる側面を有する。例えばこれは(アセンブリツリーの特定の段階における)アセンブリによって生成される特性に依存する。別の例では、トリガ述語は幾何学的関係であってもよい。例えば、互いに延在する端部を有する2つの部品であって、その端部同士の間にはゼロでない距離の他には何もない2つの部品は、幾何学的に「空隙」を定義する。トリガ述語として重要な空隙は、さらに例えばキーキャップや筐体部品などの特定の呼称を有するコンポーネント間で発生するように限定されてもよい。
ブロック112においていくつかの実施形態では、検査要件のセマンティックグループがトリガ述語に基づいて(例えば検査要件ライブラリ124(図1B)から)選択される。いくつかの実施形態では、1以上の検査要件は設計階層に影響される態様を有する。例えば、検査要件の標的はアセンブリの特定の段階かその後にしか存在せず、あるいはアセンブリの特定の段階かその後では標的が(たとえば隠されていて)検査に使用できない。いくつかの実施形態では、当該態様が検査計画の最適化に関する。例えば、アセンブリの段階が異なれば標的の検査に対するコストのトレードオフが生じ得る。
任意選択的に、いくつかの実施形態ではブロック114において検査要件が準備される。これは任意選択的に、例えば設計文書(幾何形状及び/又はコンポーネント間の関係を含む)からの、及び/又はユーザ入力によるパラメータの集合を含む。収集されたパラメータを使用して、特定の要件に適するような指定情報を検査要件に付加する。
任意選択的に、検査要件自体のセマンティックグループは、検査要件のセマンティック(オープン)仕様を含む。セマンティック仕様は、ハイレベルの予め定義された「専門知識」から成るプロセスによって解釈されるので、これらのセマンティック仕様は他のプロセス(例えば検査計画)の必要性に関する限り、既に完全であり得る。
したがって、セマンティック仕様は任意選択的に、ブロック114内では重要な準備は受けない。その代わり、例えば表記が表す以上の情報を与えるアノテーションを加えることによって、何らかの特別な検査要件を更に準備する価値がある場合がある。これらのアノテーションは、例えば製品文書、工場の状況、及び/又は手動入力により得ることができる。ブロック114での準備は、検査要件の削除、又は検査要件の追加(例えば自動選択で特定されなかった検査要件を手動で追加)に使用することもできる。本開示のいくつかの実施形態において特に関心のあるアノテーションのタイプは、検査要件への設計階層の効果を指定するアノテーションである。例えば(組立中の)いつ検査することが最適か、好ましいか、可能か、及び/又は不可能か、などである。
いくつかの実施形態では、少なくともいくつかの「クローズド」検査要件が提供される。クローズドであっても、ブロック112で説明したようにトリガ述語で表記されている限りは、それらは依然として検査要件の「セマンティックグループ」のメンバである。
クローズド検査要件の提供は、任意選択的にこの段階で、そのライブラリ内の少なくともいくつかの検査要件をクローズド検査要件のテンプレートとして定義することにより行われる。次いでブロック114での準備処理でそのテンプレートを適切に埋める。例えば、アセンブリツリー内のコンポーネントとして記述される特定の部品番号は、部品データベース内の部品番号に関連するメタデータによって(例えば期待値と許容値とで)準備された、クローズド検査要件群に対するトリガ述語である場合がある。
クローズド検査要件を提供することは、高度に自動化された検査リソースと下位の検査リソース(例えば固定された計測装置)とが混在する検査環境においては有効であり得る。追加的又は代替的に、検査要件は、選択と、任意選択的な準備(ブロック114での)とが終わった時点では「オープン」であり、代わりに検査計画の後期の段階において「クローズド」状態に変換され得る。後期の段階において、下位の検査リソースに割り当てられた検査タスクを管理するオープン検査要件が、1以上のクローズド検査要件として再指定される場合がある。
任意選択的に、ブロック116において、特定された検査要件は設計及び/又は製造プロセスにリンクされる。リンク付けは通常、検査要件を指定する新規データ要素を文書レベルで定義することを含む。リンク付けはさらに、設計/製造文書における新規のデータ要素と既存のデータ要素との間の何らかの参照関係を含む。例えば、検査要件がXMLエンコード要素に処理されるとすると、XML要素は文脈上でどのコンポーネント/アセンブリを修飾するかが明らかな場所に挿入され得る。あるいは、XML要素はフィールド値を特定することにより、特定のコンポーネント/アセンブリにリンクする別のセクションを形成する。任意の特定の既存文書へのリンク付けは、任意選択的に2方向を含むいずれかの方向でああってもよく、文書へのリンク付けは任意選択的に複数文書間では多方向である。
設計プロセスへのリンク付けは、「後ろ」方向であり(例えば訂正などにおいて、潜在的に設計プロセスそのものに影響する)、製造及び検査などの製造プロセスへのリンク付け(例えば検査エージェントが使用する検査要件の指定などによる)は「前」方向である。1つのリンク付け(例えばXMLのスニペット)は前方と後方の両方のプロセスに同時にリンク可能である。前方方向か後方方向か(あるいはその両方か)を問わず、リンクは、設計/製造のチェーン内の任意の要素が変更されるときには常に設計/製造のチェーンのどこかの再検討をトリガするように使用することができる。リンク付けは例えばXMLスキーマを使用して指定可能である。そのような任意選択的なXMLスキーマにより指定される検査要件のアノテーションの一例を以下に示す。
「後ろ方向」の意味では、検査要件は、元の設計で暗黙的(あるいはほぼ暗黙的)であったであろうものを明示的にするか、逆に元の設計が曖昧にしたままのものを強調する。検査要件を設計文書に明示的に組み込むことにより、設計そのもの(すなわち設計の将来的な改訂)が影響され得る。例えば、リンク付けによって、製造物の特定のコンポーネントにどの検査費用が関連し得るかを、その設計を検討する者に明らかにする。このことは例えば、設計変更してコストを低減する動機となり得る。潜在的には、検査要件を設計文書にリンク付けすることにより、検査プロセスの廃止、統合、あるいは合理化となり得る設計変更の機会が強調される。
より具体的には、いくつかの実施形態ではこのことはアセンブリツリーの階層に影響し得る。設計検討者(レビュワー)は、どの段階で特定のコンポーネントが検査可能であるかを判断することができ、これは潜在的に、設計変更がこの段階の範囲に影響を与え、製造プロセス及び/又は全体品質の潜在的な改善を可能とすることへの理解につながる。たとえば、早い段階において特別の検査ステーションの設定を必要とする1つの隠れたねじがあるとすると、後で設計を修正してそのねじの上方に、別の検査ステーションでの検査を可能とする窓を設けてもよい。
「前方向」という意味では、検査要件が検査計画に対して一次材料を提示する。さらに、かつ検査計画に特に連携して、検査要件はどのように製造するかに影響を及ぼし得る。例えば、検査タスクはアセンブリラインに沿って製造タスクと混在させることができる。このことは、工具設置や、アセンブリステーション間でのタスクの分散のさせ方や、製造の別の側面へ影響を及ぼし得る。検査要件が、検査要件の実行可能なタイミング(例えば階層アセンブリのどの段階で)についての情報を織り込んでいる限り、それによって製造計画の柔軟性が増し、及び/又は製造効率の向上の機会が提示される可能性がある。
検査要件を特定するシステム
次に図1Bを参照する。これは本開示のいくつかの実施形態による、製造物の設計階層120に基づく検査要件自動特定のためのシステムを模式的に示す。
システムモジュールと入力
概説として、トリガ述語分析器126が設計階層120及びトリガ述語ライブラリ122(構築されているとして)から情報を受信する。そして図1Aのブロック110に対応して、設計階層120内に見いだされるトリガ述語を出力する。検査要件準備器128がトリガ述語を受信し、それを適用して検査要件ライブラリ124からの選択を行い、図1Aのブロック112と114の操作に対応して、選択された検査要件に対して任意選択的にその他の準備作業を行う。準備された検査要件を次いで配布することができる。例えば、設計文書131中に組み込まれるか、検査計画135に提供されるか(任意選択的に「検査計画に」ということは「セマンティック検査エージェントに」提供することを表す)、及び/又は製造計画133への入力として提供されるか、である。
一般的に、検査要件ライブラリ124は、1以上の検査要件のグループをそれぞれのトリガ述語に関連付ける辞書として見なすことができる。検査要件(検査要件ライブラリ124に属する)は、本明細書では概説の一部として定義され議論され、追加的な例が、例えば図2A、図3及び図4の説明と共に提供される。
トリガ述語(任意選択的なトリガ述語ライブラリ122に属する)は、本明細書では概説の一部として定義され議論され、追加的な例が、例えば図2A、図3及び図4の説明と共に提供される。それらは、例えばコンポーネントコンテンツ(例えば図2C)及び/又はテキストコンテンツ(図2B)などを基に、設計階層120内で(例えばトリガ述語分析器126によって)検出可能である。コンポーネントコンテンツは、コンポーネントを特定し、及び/又は特徴づける、任意の設計階層120又は調整入力121コンテンツに関係する。これは例えば幾何形状、テキストコンテンツ、画像コンテンツ、又はそれらの任意の組み合わせに基づいて決定可能である。
テキストコンテンツはコンポーネントコンテンツでもあり得るが、その概念は設計階層120及び調整入力121の任意の他のテキストアノテーションにも拡張される。特に、キーワード、指示、及びコメントは、特定のコンポーネントや設計特徴との関連に拘わらず、検査方針、品質方針、及び/又は製造状況をより一般的に示すことが可能である。
さらに、トリガ述語の特定は、「コンポーネントコンテンツ」及び「テキストコンテンツ」の使用に限らないことを理解されたい。例えば音声やジェスチャによるオペレータの指示を、後述する任意の調整入力121が可能なように、トリガ述語の特定に使用可能である。
検査要件準備器128は任意選択的に、パラメータ、例えば抽出タイプ、許容値、基準、あるいはその他の必要データ、を選択された検査要件に供給する。いくつかの実施形態では、後段のプロセスそのものが、例えば設計階層120のデータへのアクセスもまた使用して、そのような抽出を実行する。
ブロック126でのトリガ述語分析、及び/又はブロック128での検査要件準備をそれぞれ調整するために、調整入力121、123が任意選択的に提供されてもよい。また、検査要件ライブラリ124とトリガ述語ライブラリ124の間、及び/又は見つかったトリガ述語と検査要件ライブラリ124の間に(例えば後述するように)「クロストーク」があることもある。
システムモジュールと入力の間のその他の相互作用
これらの機能ブロック間の任意選択的な相互作用、それらの入力及びそれらの動作を以下で更に説明する。
トリガ述語分析器126への一次入力は、設計階層120そのものと検査要件ライブラリ124を含む。
任意選択的に、別個のトリガ述語ライブラリ122が提供される。これは検査要件ライブラリと設計階層の間の分離を提供することができる。例えば、検査要件ライブラリ124は、ねじという名称のトリガ述語に適用する要件のグループを指定できる。他方、トリガ述語ライブラリは、ねじという名称を、設計階層120でねじ要素を定義するより特定の仕様にリンクさせることができる。トリガ述語ライブラリ122は、トリガ述語の特定に影響し得る、設計階層外部の情報(例えば、ユーザプロンプト及び/又は手順文書)へのアクセス方法の仕様も含み得る。この外部情報は、例えば調整入力121として提供されてもよい。
検査要件ライブラリ124から引き出されたリンクは、トリガ述語ライブラリ122とトリガ述語分析器126との間の別のリンクを囲む円で終端するように示されている。これは、検査要件ライブラリ124が任意選択的にトリガ述語ライブラリ122を修飾するように使用されることを示すものである。例えば、トリガ述語ライブラリ122にフィルタをかけて、入手可能な検査要件群のいずれにも無関係なエントリを除去することが可能である。追加的又は代替的に、リンクは検査要件ライブラリ124そのものを使用し、トリガ述語ライブラリ122のコンテンツの少なくとも一部を提供することを示す。例えば検査要件ライブラリ124はPATHセレクタを定義可能である。これは、辞書検索に有効であるばかりか、設計階層の構築に使用されるXMLコンテキスト内の少なくともいくつかのトリガ述語を完全に指定する。
任意選択的に、設計階層120からの入力は調整入力121で補完される。これらの調整入力121は、トリガ述語分析を導く手動及び/又は補助入力-これは理由に関わらず設計階層自体に存在しない(任意選択で可能であるとしても)入力である-を備えることができる。
補助入力は述語検出情報を設計階層に付加し得る。例えば、設計階層内で定義された、関係はあるが必ずしも設計階層そのものが強調するようなものではない、アセンブリ間の関係である。
そのような関係の一例は、互いに隣り合ってはいるが、それ以外にはアセンブリツリーのアノテーションでは明確な関係のないアセンブリであり、その相対的位置決めが検査対象となり得る。
別の例では、コンポーネントとして使用される部品の代替の組(例えば釣り合った組同士で使用すべき縁部品)があり得、調整入力がこのリンク情報を指定可能である。そのような情報は好ましくは、アセンブリツリーそのものの中で、前もって指定される。
ただし、同一部品番号の2つのバッチが不完全にしか一致しないという供給の問題もあり得、これは結果的にオンザフライ製造の問題となり、検査要件を介することも含む手順の調整によって解決可能である。
さらに別の例では、治具、クランプ、足場、テープ、あるいはその他の外付け部品が製造物に一時的に取り付けられた製造の中間段階があり得る。そのような部品の存在は検査対象となり得るし(例えばあたかも別アセンブリであるかのように)、あるいは、他の何らかのコンポーネントが十分に露出されて検査可能かどうかに影響する可能性もある。これに関する文書は、アセンブリツリーの設計文書には存在しないかもしれない。そのような情報は任意選択的に調整入力121の一部として提供される製造文書を通じて、あるいは手動調整などの別の方法によって提供される。
追加的又は代替的に、調整入力121は直接的または間接的に工場の状態を反映する。例えば部品在庫、部品供給元(サプライヤ)、ツール状態、工具の可用性、作業者熟練度、及び/又は人員配分(例えば作業者の多いシフトか少ないシフトか)などである。これらの条件は、例えば組立て順序の変更などにより、述語の解釈に影響する可能性がある。例えば熟練を要する組立て作業を行う労働者は昼間シフトにしかいない場合があり、検査計画に影響するトリガ述語に、シフトに依存する違いが出る。調整入力は特定のコンポーネントやアセンブリを分析から外す(マスクする)ために使用される場合がある。
追加的又は代替的に、調整入力121はトリガ述語の検出そのものを支援するように使用されることもできる。例えば、特定のトリガ述語が、恐らくはこれまで予測できない条件の組み合わせに基づいていたことにより、自動検出方法がない場合がある。既存の自動検出方法は、間違った正判定又は負判定をしようとする可能性があるが、調整入力を手動で提供することでそれを回避及び/又は解決に役立つことができる。半自動的検出方法は、オペレータの支援を受けて動作するように設計され、トリガ述語の特定を支援するが、完全には実行できない。別の例では、トリガ述語検出が正しいとしても、人間のオペレータが対応する検査要件の生成の必要がないことを容易に知っている場合がある(例えば、トリガ述語が関係ないか、その検査要件トリガは他の検査要件によって本質的に満たされているという理由がある)。
調整入力121は、検査要件準備器128に提供されたアセンブリツリーのバージョンに追加的又は代替的に適用される可能性がある。さらには、図1Bには調整入力121の任意選択的な適用ポイントのすべてが示されているわけではない。例えば、トリガ述語分析器126及び/又は検査要件準備器128の中間結果及び/又は出力に効果的に適用される調整入力も存在し得る。
調整入力123は、任意選択的に調整入力121に関連して記述される任意の入力に対応するが、アセンブリツリー120の設計詳細に特に起因するものは通常除かれる。設計の詳細に起因する修正は検査要件準備器128のジョブの一部であり、それ自身がアセンブリツリー120及び関連する調整入力121へのアクセスを有する。調整入力123は特に検査方針文書及び/又は品質方針文書から導くことが可能であって、これは検査ライブラリ124からのどの検査要件が製造設備の特定の製品、顧客、及び/又は製造プロセスに最も関連すると考えられるかということを具現化する。
ここで図1Cを参照し、これは本開示のいくつかの実施形態による、オープン検査要件仕様とクローズド検査要件仕様を模試的に比較する。本開示のいくつかの実施形態において典型的なプロセスフローは、トリガ述語140を、検査要件を介して検査計画143の構築と実行に結び付ける。
「オープン」検査要件と「クローズド」検査要件との違いは概説で記述した。
簡単に言えば、クローズド検査要件142は、測定可能な特性を適切な測定アクションに関連付ける「下位」の用語で要件を設定する。値が与えられて、測定の出力が特定の要件に合致するかどうかが評価可能となる。測定可能な特性自体が、要件を満たすために何を重視するかに関してほとんど曖昧でないことがあり、場合によっては、測定アクションそのものは指定されない。検査計画の結論において、出力(すなわち成功した場合)は、ブロック145で示されるような判定「特性の測定結果は許容値内である」と同等である。これはクローズド検査要件の用語を直接反映するものである。
一般的に、クローズド検査要件は生成及び適用において柔軟性が小さい傾向にあるので、クローズド検査要件に対するトリガ述語は狭く定義される。
オープン検査要件仕様141は、トリガ述語が示していると理解されるもの(表記)となるように定義される。これはコンポーネント又はアセンブリであってよく、通常、コンポーネント又はアセンブリの特定の特性には関係しない。
特定のアクションを指定する代わりに、オープン検査要件仕様はより一般的には「懸念」に関係する傾向がある。懸念は以下のような上位の事項を示す。
・コンポーネントの存在
・表面が装飾仕様を満たす
・仕様に合致したコンポーネントの一様な外観
・コンポーネントが一組のクラス固有の品質課題を満たす。例えば以下の通り(クラスを下線で強調表示)
ケースが閉じられ、縫い目に沿って適切に取り付けられている。
ねじが締まっていてヘッドが潰れていない。
成形コンポーネントが完全(例えば設計モデル形状に一致)であってバリが出ていない。
コネクタがまっすぐで背景に整合している。
ラベルがまっすぐ配置されて読みやすい。
スナップアセンブリが、相互に正しく配置された嵌め合い部品を有する。
パターン(コンポーネントの)がテンプレートの定義通りである。
トリガ述語が単独で懸念を暗示することもある(例えば、ねじのコンポーネントもねじの懸念を引き出す)が、関係は必ずしも必要ではなく(例えば、ねじは緩いキット部品として提供可能である)、一般的に1対1ではない(例えば、「存在」は必ずしもねじの懸念で暗示される一式のテストの部分ではない)。
検査要件仕様は任意選択的に、その範囲及び適用を更に定義するアノテーション(注釈)を含む。典型的なアノテーションは、トリガ述語が表記するクラス内のサブクラスである。例えば、ねじは、M3ねじ及び/又はプラスねじとしてアノテーション可能である。アノテーションは任意選択的に、例えば製品のモデルベース定義(MBD)に特性として直接的に示されるか、あるいは間接的に示される。MBDは、製品の設計モデル、例えば製品の3D形状モデルを含み、その製品及び/又はその製造プロセスの定義に適切であり得るその他の情報を有する。これは例えば、許容値、部品レベルの材料、アセンブリレベルの部品明細、エンジニアリング構成、及び/又は設計意図などである。いくつかの実施形態では、MBDにはアセンブリツリーが含まれ、これが製品のコンポーネントをアセンブリ及びサブアセンブリの階層に構成する。
間接的な表示の例として、部品の省略呼称(例えば部品番号による)が、部品の特性を示すものとして任意選択的に解釈可能である。例えば、部品番号は複数の連結フィールド(任意選択的に、ダッシュ又は他の文字で区切られた)を含むことができる。特定のクラスの部品に対しては各フィールドの値がさらにサブクラスを指定できる。例えばねじは、異なる組み合わせで構成可能な複数の特徴、例えば、材料、ねじピッチ、シャフト径、シャフト長、ヘッド型、スロット/ソケット型などを有する。したがって、いくつかの実施形態では、設計文書での部品呼称が部品番号付け規則を介して解釈されて、部品そのものをよりよく知ることができる。
アノテーションは、他の方式ででも、例えば、モデルベース定義(MBD)で指定されたアセンブリツリーで示される製造物の階層構造に基づいて、検査要件を変更可能である。アセンブリツリー(例えば、アセンブリツリーと他のMBDデータとの組み合わせから導かれる階層構造及び/又はアセンブリの幾何形状)から、コンポーネント及び/又はアセンブリを、いつ検査できるか、例えばそこに存在して(組み立てられて)いること及び目視可能(後のアセンブリの段階によって隠されていない)であることの両方、を判断可能である。
アノテーションは、設計文書内の情報から得ることが可能であり、任意選択的に「スマートな」部品番号スキームによって補完される。したがって、アノテーションは任意選択的に検査要件そのものから省略され、検査計画は自身が設計文書にアクセスを有するものと仮定して、情報抽出の作業が少なくとも検査計画までは延期される。
ただし、要件の中にアノテーション情報を抽出することが、注目すべきポイントを生成する。アノテーション情報は、複数の情報源(例えば、設計モデル、品質方針、手動による追加、及び/又は画像)のいずれかから要件に取り込まれ、検査計画自身が、より間接的な情報源にアクセスすることを必要とせずに直接的に参照可能な、標準的表現とすることが可能である。アノテーションはそれ自体が直接的な値というよりも参照値として挿入可能であることに留意されたい。例えば、品質方針が定義する呼称を参照によって指定することができる(例えば「表面品質クラスB」)。
検査計画の結論において、出力(すなわち成功した場合)はブロック144で示されるような判定「表記されたタイプ及びアノテーションされたタイプに対する懸念は満たされる」と同等である。このことは、これらの「懸念」によって提起される特性測定値の列挙は、オープン検査要件仕様の場合には検査計画143の制御下にあり、クローズド検査要件仕様は特性測定値の列挙されたリストから始まる、ということに関連する。
次に図2Aを参照し、これは本開示のいくつかの実施形態による、モデルベースの設計文書の態様を模式的に示す。
モデルベースエンタープライズ(MBE)は、製品のアノテーション付きのデジタル3次元(3D)モデルが、その製品のライフサイクルにおけるすべての活動において信頼できる情報源として機能する戦略を記述する、製造業において使用される用語である。符号化された情報が、例えば、形状、トポロジ、寸法、公差(許容値)、材料、仕上げ、溶接コールアウトを指定する。アセンブリツリー及び/又は製品ツリーの情報もまた指定可能である。これらは合わせて製品のモデルベース定義(MBD)を構成する。これらは、例えばf3D PDF, JT, STEP AP242,及び/又は ANSI QIFなどのいくつかの標準MBD対応フォーマットの1つで表現され得る。MBD文書は、製造及び品質検査を含む製品ライフサイクルの下流の活動における使用に好適である。
製造された製品はコンポーネント(構成要素)の集合体で構成される。コンポーネントは、それ自体が(サブアセンブリの)集合体であり得るし、あるいは組立工程に直接投入される部品であり得る。したがって、製品MBDの典型的な態様は、(コンポーネントとなる)部品を指定するコンポーネントの階層構造であり、次にコンポーネントが一体化されて最終製品(それ自体を最終アセンブリとみなし得る)のレベルになるまでの、アセンブリの組み合わせ階層を形成する順序化である。アセンブリツリーは設計の支援となるばかりでなく、好ましくは製造計画のガイドともなる。本開示のいくつかの実施形では、アセンブリツリーは検査要件特定のガイドとしても使用される。
図2Aは、おもちゃの車(遊具)である簡単な製造物のアセンブリツリーを示す。車輪322、車軸324、ボディ310を含む3つの部品(八角形のボックス)がある。アセンブリツリーモデルでは、これらにはそれぞれの識別子a1、p2、p3が与えられる。ある品目を「部品」と呼ぶことは、その部品の、製品コンポーネントしての特定の使い方とは別である。ただし、アセンブリツリーで「部品」として表される物理的に同一のモノが、それらが製品の組み立てに使用される限りはさらに「コンポーネント」(四角形のボックス)としても呼ばれ得る。
コンポーネント名称は、製造物内の異なる(特定の)位置に予定されることにより物理的に同一の部品と区別される。単純にコンポーネント特定された部品であるコンポーネントには、ボディ304、車軸314、左車輪316、右車輪318(それぞれ識別子c1、c4、c5、c6を有する)が含まれる。
アセンブリ(角の丸い四角)は複数の取り付けられたコンポーネントを含む。最終的な製造物は自動車302であり、これもまた識別子a1を有するアセンブリである。別のアセンブリはa2で特定される車輪付き車軸312である。
アセンブリとして表示される物理的なモノは、コンポーネントとしても表示される場合がある。例えばアセンブリ312はコンポーネント、即ち、車輪付き前車軸306及び車輪付き後ろ車軸308(それぞれc2、c3として特定される)でもある。各部品はさらに、その形状を表す3D設計情報に関連付けられ、アセンブリは、コンポーネントの相対的位置を与える3D設計情報に関連付けられる。3D設計情報は、部品及びアセンブリに対応する部分を示すために(例えばアセンブリツリーから)参照可能なマスタ文書として保持され得る。
図1Bのシステムを参照すると、図2Aはアセンブリツリー120に対応する。トリガ述語ライブラリ122は、例えば図2B~図2Cの方法の1つ又は別の方法により(例えばトリガ述語分析器126の動作によって)、図2Aの部品、コンポーネント又はアセンブリのいずれかを識別するトリガ述語を指定可能である。検査要件ライブラリ124は、任意選択的に、図2Aの特定されたいずれかの要素に特有の検査要件を含む。
任意選択的に、図2Aのおもちゃの自動車は、沢山の製品、例えば沢山の様々なおもちゃの車を製造する工場で製造され、その内のいくつかは異なる部品及び/又は追加の部品を有する可能性がある。例えばこの工場は、異なる識別子の車輪、ボディ、及び/又は車軸を使用する製品を組み立てる可能性があり、完全に異なるタイプを有する部品又はアセンブリが存在し得る。製品は共通の特性を持ち得る(例えば、それらの多くもまた、1つのボディと車輪付きの2つの車軸を含む)が、その部品とコンポーネントの一部またはすべてが異なる場合もある。図2Aのおもちゃの自動車は、さらに、例えば異なる色、マーク、又は補助部品の、複数の変形で製造され得る。任意選択的に、工具及びその他のリソース(例えば、ステーション、工場作業者そのもの)が複数の製品間で共有される。反対に、同じ製品が任意選択的に異なる方法で、例えば、車軸314をボディ304の固定スナップに位置合わせする治具のあり、なしのいずれかの方法で製造される。
これらの任意選択的な工場の条件は、検査要件の自動特定に関するいくつかの例の背景として、具体的には以下のようなものが挙げられる。
例えば、多くの異なる型式の車輪付き車軸アセンブリが存在し得、これらはすべて同じ種類のテストを必要とするが、そのテストの細目は全体設計に依存する。例えば、製品が異なればアセンブリレベルでの内輪距離の特性は異なる場合があるが、全品について検査を必要とする。このことは、検査要件ライブラリ124が、アセンブリツリー及び/又は製品ツリーに従って、要件をセマンティックに指定することの潜在的利点を示す。
製品形状の詳細に応じてアセンブリを違う形で検査することが好ましい場合もある。例えば、車軸は真直度を検査すべき場合がある。図2Aの製品はそうではないが、製品によっては、車軸が隠れる底部を車体に配置する場合がある。その結果この特性に対する、最後に検査可能な段階が異なってくる。それはいくつかの実施形態では、3D設計データを例えばアセンブリの各段階で検査して、アセンブリが見える段階は実際にどこなのかを確認することによって、特定される。
より高価なコンポーネント及び/又はアセンブリコストの高い製品の欠陥は早い時期に特定することが好ましい場合がある(例えば無駄を減らすために)。別の製品については、(例えば1つの最終作業ステーションに検査を集中して)検査コストを低く維持することが好ましい場合がある。したがって、特性検査の可能なアセンブリ段階を特定することが、検査計画の最適化を支援する入力の提供となり得る。
製造工程の詳細に応じて、アセンブリを違う形で検査することが好ましい場合がある。例えば、自動組立工程は、システムの停滞を防ぐために既知の良好なコンポーネントの受け入れに依存する場合があるが、対応する手動工程は影響を受けない。別の例では、曲がった車軸は潜在的に組立機械の高速運転の結果であって、低速運転によるものではないと判断されることがあるが、いずれの運転速度もそれ以外では外部因子に依存してそれぞれに好ましい場合がある。この両方のシナリオにおいて、どのタイプの製造が行われるかに依存して、早い段階での検査又は遅い段階での検査が望まれ得る。また、検査の可能な段階の範囲を特定することは潜在的な利点である。それにより、その時の製造条件に対して好適な段階を検査計画が選択可能となる。
次に図2Bを参照する。これは本開示のいくつかの実施形態による、設計階層内のコンポーネントに基づくトリガ述語の特定方法を模式的に示す。
階層ノード230は、設計階層120の特定のアセンブリ又は他のノードの仕様(データ構造、例えばXMLで指定されたデータ構造など)を含む。トリガパラメータ仕様232は、例えばトリガ述語ライブラリ122からの仕様を含む。
手順(例えば図1Bのトリガ述語分析器126によって実行される)の目的は、階層ノード230が、トリガパラメータ仕様232によって定義されるような適切なトリガ述語を符号化するかどうかをテストすることである。この特定の方法では、トリガパラメータ仕様232は特別のタイプであり、これは特定のコンポーネントの存在と、検査に対するアセンブリの特定の「露出」の両方を指定する。この露出は、ブロック212に関して説明するように異なる方法でも指定可能である。
ブロック210において、いくつかの実施形態では、アセンブリ仕様は、それがトリガパラメータ仕様232で言及された1以上のコンポーネントを定義する(「有する」)か否かを照会される。単純な場合には、これは1以上のデータ検索(例えばXPATHクエリのような)を含み、トリガパラメータ仕様232は、特定の特性、部品番号、部分部品番号、キーワード、あるいはその他の文字列を有するコンポーネントを(任意選択的にXML指定の)階層ノード230内から見つけるように調整されたクエリ文字列を指定する。ただし、検索のためのテキストデータの使用には特定の制限はなく、例えば特定の幾何学的特徴をトリガパラメータ仕様232で指定可能である。クエリにはまたコンポーネント間のその他の論理関係を含むことも可能であり、例えば否定クエリ(特定の部品を含まない)、包括的選択肢のクエリ(複数の特定部品の少なくとも1つを含む)、及び/又は排他的選択肢のクエリ(複数の特定の部品の1つのみを含む)である。
コンポーネントテストが失敗すると、フロー図はブロック223で終了し、階層ノード230は与えられたトリガパラメータ仕様232に対するトリガ述語を含む特性を定義しない。
そうでなければ、フロー図はブロック212で継続され、いくつかの実施形態ではアセンブリレベルを検証する。異なるテスト及びテストの組み合わせが可能であるが、ここには代表的な2つのテストがある。
簡単な場合、テストは単に、アセンブリがブロック210のコンポーネントテストを満たす第1のレベルであることを確認するだけである。
追加的又は代替的に、テストは特定の表面、コンポーネントあるいは他の特徴が見えること、例えばアセンブリの外側から(「それを遠方から見た」ときに)見えることを確認する。表面、コンポーネントあるいは他の特徴は、コンポーネントの注目する特徴に適するように選択可能である。製造物の3Dモデルは入手可能であるので、この判定は3D描画ディスプレイで既に使用したものと同様のアルゴリズムを使って行うことができる。例えば描画された空間でアセンブリから別の方向に光線を引き、交差の有無をテストすることにより行うことができる。
テストは任意選択的に、別の判断基準で行われてもよい。例えば、任意選択的にアセンブリ近傍でプローブ形状をした物体を模擬的に移動させることに基づく、プローブへの電気テストポイントのアクセス可能性などである。
レベルテストもまた良好な結果であれば、ブロック221でトリガ述語の生成の信号が送られる。そうでない場合には、ブロック223で「トリガ述語ではない」の信号が送られる。
トリガ述語の結果を与えるアセンブリレベルが2以上である可能性もある。つまり、トリガパラメータ仕様は、任意選択的にトリガ述語がアセンブリの2以上のレベルにおいて生成されるように設計されている。いくつかの実施形態では、これにより、例えば他の検査計画の考慮に従って、任意の有効なアセンブリ段階において検査可能と注釈されたテスト要件が得られる。
次に図2Cを参照する。これは本開示のいくつかの実施形態による、設計階層内おけるテキストベースのトリガ述語特定方法を模式的に示す。
図2Bで説明したように、階層ノード230は設計階層120から選択された特定のアセンブリの仕様を含む。トリガパラメータ仕様232は、例えばトリガ述語ライブラリ122からの仕様を含む。
手順(例えば図1Bのトリガ述語分析器126によって実行される)の目的は、階層ノード230が、トリガパラメータ仕様232によって定義されるような適切なトリガ述語を符号化するかどうかをテストすることである。この特定の方法においては、トリガパラメータ仕様232は汎用テキストフィールドに基づく。これは部品/コンポーネント名(例えば図2Aで指定されるような)に基づくことが可能であるが、これに追加的又は代替的に、アセンブリ仕様内の任意の他のテキスト、すなわちラベル、要素名、キーワード、コメント、あるいはその他のものに基づくことも可能である。特に、階層ノード230は、アセンブリそのものに適用可能なラベル又はキーワードも含み得る。したがって、(図2Bのように)コンポーネント内容に基づいて特定される代わりに、アセンブリは、単純に特定のクラス(例えば、キーボード)に属するとラベル付けされるか、検査プロセスに他の形で関連するコメント/キーワード(例えば、全コネクタは同一の高さ、全部品は同一色、組立後のばりとり)でラベル付けされてもよい。
ブロック234において、テキストフィールドがトリガパラメータ仕様に一致する仕様のコンテンツであるかが分析される。コメント/キーワードは、厳密な文字列一致に基づいて、あるいは、例えば関連する例で訓練された機械学習に基づいた自然言語機能によって特定可能である。任意選択的に、正式に指定された検索(例えばXPATHタイプの検索)が、階層ノード230のテキスト符号化された要素及び/又は特性の特定のためにサポートされる。
ブロック236において、トリガパラメータ仕様への一致の有無が判定される。一致する場合には、ブロック237でトリガ述語の生成の信号が送られる。一致がない場合には、ブロック239で「トリガ述語ではない」の信号が送られる。
キーボードの例
ここで、図3を参照する。これは本開示のいくつかの実施形態による、キーボード500Aの検査部分の画像500を模式的に示す。画像500は自動外観検査システムによって取得されたものである。
キーボードの例は、階層的に定義されたアセンブリ内の物理的位置関係のいくつかの異なる態様を示す例を提供する。検査の特に顕著な標的となる物理的位置関係には、例えば2つのコンポーネントが接する及び/又は近接する境界が含まれ得る。そのような境界は、例えば以下の理由で顕著である。
・それらは特に目につき易く、整列していない場合には美観に影響を及ぼし得る。
・それらは、例えば締結品質を示唆する。不揃いであることは、例えばスナップの閉じ方の不完全さや、ねじの緩みを示す場合がある。
・それらは製品性能へ機能的影響を与える。例えば電気的な接触が失われたり、応力が増えたりすることがある。
・キーボードへのキーキャップ501の配列は、このような考慮事項のいずれかあるいはすべてに影響し得る。例えば、位置ずれしたキーは見た目が悪く、不適切に設置された可能性があり、かつ正しく動作しない可能性がある。
キーボードは、図1A~図1B及び図2B~図2Cのフローチャート及びシステムの実装例として使用できる。
図1Aのブロック110から始めると、キーボードのトリガ述語は、単純に(例えば図2Cの方法に基づいて)キーボードとしての設計仕様における適切な位置にラベル付けされていることであってよい。追加的又は代替的に、キーキャップ501あるいはキーハーネスのようなその他の「キーボード固有の」コンポーネントの存在を使用して、(例えば図2Bの方法に基づいて)「キーボード」検査要件のグループが使用できることを示すトリガ述語を生成可能である。
キーボードアセンブリは、一般的であり、かつ多くの異なる実際の実装に使用されるアセンブリクラスの一例である。詳細には、その寸法及びそのほかの特性(キー配置など)は目に見えて可変である。ただし、それらには十分な共通属性があり、キーボードに対して調整された検査要件の専用セットは、例えば様々な型式のキーボードを組み立てる工場にとっては潜在的な価値を有するものである。
検査要件ライブラリ124は任意選択的に、1つ又は別のタイプのキーボードトリガ述語によってトリガされる検査要件群を含むことができる。キーボードの要件に適合されているので、このグループは任意選択的に、以下の1以上の検査のための要件を含む。
・キーキャップ501への印刷欠陥
・順番に配置されていないキーキャップ501
・キーキャップ501の欠損
・存在するが整列が乱れたキーキャップ501
特に、意味論的に指定されたテスト要件が下流の検査計画プロセスで受け入れられる場合、オペレータは、少なくとも要件の段階ではそれ以上の指定をする必要は殆どない可能性がある。例えば、いくつかの実施形態において、「スマート」検査システムの下流検査エージェント(コンピュータ化されたモジュール)がある場合があり、これは以下を含む方法によって最初の3つの要件のそれぞれを満たすように予め構成されている。
・キーボードの検査要求が存在する「完全部品(golden part)」(検査セットアップの一部として露出される)からなるキーボードを見つけてその画像を撮る
・その画像のキーとその位置を特定する
・その画像内のキーの配置を、キー特定のテンプレートとして使用する
・その画像内のキーへの印刷を、後でのキーボードへのテストに対する参照として使用する
これは直接的には誤った印刷を特定し、副産物としては欠損/順番に配置されていないキーキャップ501を特定する。これらの3つのテストの相乗効果の認識は、品質システム内に効果的に納められて、セマンティック検査要件システムの価値の一部を強調する。
説明のために、テスト結果に明らかな相互の固有性がないか、あるいは何らかの理由で無視できると仮定すると、第1の検査要件は特に個別コンポーネントに係わるものであり、下位のアセンブリレベルにおいて検査されてもよいことに留意すべきである。
例えば、図2Bの方法によって、(例えばキーキャップ型の部品番号を有するコンポーネントであることをトリガとすることにより)キーキャップ専用の検査要件を生成することは可能であろう。この検査要件は複数の階層レベル、例えば未加工のキーキャップコンポーネントそのもののレベル、あるいはキーボードアセンブリの部品となった後のレベル、のいずれにおいても実行に適していると注釈がつけられる。
自動検査プランナは次に、例えば取得する必要のある画像数、及び/又は必要とする検査ステーションの数等の、他のキーボードテストとの相乗効果を認識する選択肢を有する。したがって、この検査要件に対しては、より完備したアセンブリ段階が望ましいものとして選択される可能性がある。
第4の要件に関しては、いくつかの実施形態において、キーキャップの間隔を検証するための最適なテスト計画を生成するように予め構成された、別の「スマート」下流検査エージェントが存在する可能性がある。総当たり手法(例えば、これが実際に「キーボード」であるという意味論的な認識なしの)では、各キーキャップの端を1つずつ特定して、それが設計文書における端に対応することを確認するということが可能である。これは、例えば、キーの上端と下端が混同されたとき、カメラの歪みが不正確に取り込まれたとき、あるいは全てをテストしようとして性能の問題が生じたとき、などに問題を生じる可能性がある。
スマート検査エージェントは、任意選択的に、違う形式で、その特定の問題に適合した方法でテストする。例えば、ボディ下側のキーキャップ端は無関係として特別に除外し、及び/又はキーの列に沿ってテスト線を生成して、それにより(例えばキーの配置ミスによる)不均一を迅速に検出し、他方でレンズのアーチファクトによる全体的な歪みを無視するように構成可能である。
検査エージェントは少数の基本パラメータ、例えばキーキャップの端同士の間の距離514、516、及び中心間の距離515、513を受け取るように構成されてもよい。これは任意選択的に、アノテーションとして検査要件そのものの中へ(例えば検査要件準備器128によって)抽出されるか、あるいは任意選択的に検査エージェント自体によって設計階層120から抽出される。
いくつかのキーキャップ501は、距離/形状が異なるものである。何らかの理由によって、キーボード検査エージェント自体がそれを処理するように設定されていない場合には、キーボードを均一な部分に分割するテスト要件アノテーションが任意選択的に利用可能である。任意選択的に、利用可能な一般規則に当てはまらない少数のキーに対して、「クローズド」テスト要件が生成される。
ケースの例
ここで、図4を参照する。これは本開示のいくつかの実施形態による、コンピュータのケーシング601の一部の画像600を模式的に示す。画像600は自動外観検査システムによって取得された画像を示す。
この例では、トリガ述語は、上部パーツ602と下部パーツ603とが合わせてケーシングを構成するといるラベル(すなわち設計文章内のテキスト)であってよい。次にケーシングラベルが、ケーシングに関係する(検査要件ライブラリ124からの)要件群のトリガ述語となる。
図3のキーボードの例において、議論のために、キーボードに関する深い検索知識を具現化する包括的認識のあるキーボードエージェントと、おそらくはキーキャップエージェントがあることを仮定した。
本例では、検査の実行を促進する汎用のケーシングエージェントはないと仮定する。その代わり、検査要件群が内部で設定されて、より一般的なテスト(ただし本例では依然としてセマンティックに指定される)のプールから引き出される適切なテストを指定する。例えば、表面検査エージェント、色チェック検査エージェント、空隙検査エージェントがあってもよい。
いくつかの実施形態において、検査群によって満たされる要求としてはケーシングに特徴的な以下のものが含まれる:
・外表面検査
・コンポーネント相互における表面外観一様性検査(例えばケーシングアセンブリの不整合を回避するため)
・コンポーネント間空隙検査(例えば、ある関連する公差で幅605となるように設計文書で指定された空隙604について)
これら3つのそれぞれは、任意選択的に例えば以下の様に別々の検査要件として生成される。
ケーシングというトリガ述語を生成したアセンブリから、外表面を有するすべてのコンポーネントが選択され得る。これは、幾何形状、コンポーネント名(パネル、カバーなど)、又は別の基準に基づくことができる。これらのコンポーネントのそれぞれに対して、「表面検査」要件が割り当てられる(少なくとも外表面に対して)。その要件は、特定の表面欠陥の許容範囲(例えば、最大のスクラッチ長さ、スクラッチに沿った表面反射率の最大平均変化、及び/又は表面検査エージェントにとって適切であるその他の基準、などを含む)を有するようにアノテーションすることができる。
同じ選択されたコンポーネント(及び表面)がさらには、色チェック検査エージェントによって実行される、「同じ色」を要求するフラグを立てられる場合もある。このエージェントは、複数のコンポーネントの間での色の一様性を検証するように構成されるであろうし、任意選択的に、例えば照明の角度、強度、撮像の表面角度などの制御も含まれる。
任意選択的に、空隙(すなわち、検査標的としての)は、ケーシングの2つのコンポーネント(例えば前述したようにして特定される)が、互いにある閾値距離未満(例えば2mm)以内で、ある距離(例えば少なくとも2mm)にわたって延在する、外部表面に沿った(設計仕様上の)位置であるとして幾何学的に特定される。任意選択的に、設計された窪み、重なりなどについては必要に応じて調整される。
そのようなすべての空隙領域に対して、(例えば検査要件準備器128の操作によって)検査要件が生成される。例えば、標的までの空隙の広がり、標的の最小幅、標的の最大幅、平行度、参照空隙への類似性(「完全部品」から測定)、及び/又は他の指定された基準を指定する検査要件である。
数値のアノテーション(パラメータ)は任意選択的に、設計文書そのものから得られる。あるいは、いくつかの実施形態では、完全部品の画像から空隙検査装置がパラメータを導出する。
検査要件アノテーションの例
以下はテスト要件仕様(XMLでの)の例である。これは任意選択的に、Part要素として指定された4つのコンポーネント:Blockと、m3、m4、m5でラベル付けされた3つのねじを含むアセンブリ(PartSet要素)に関して生成されたものである。
<PartSet n="4">
<Part id="4" label="Block" >
<Attributes n="3">
<Inspection name="class" value="surface"/>
<Inspection name="sub_class" value="class-b"/>
<Inspection name="inspection" value="surface"/>
</Attributes>
<BodyIds n="1">
<Id>5</Id>
</BodyIds>
</Part>
<Part id="478" label="m3" >
<Attributes n="3">
<Inspection name="class" value="screw"/>
<Inspection name="sub_class" value="M3"/>
<Inspection name="inspection" value="screw,existence,surface"/>
</Attributes>
<BodyIds n="1">
<Id>479</Id>
</BodyIds>
</Part>
<Part id="727" label="m4" >
<Attributes n="3">
<Inspection name="class" value="screw"/>
<Inspection name="sub_class" value="M4"/>
<Inspection name="inspection" value="screw,existence,surface"/>
</Attributes>
<BodyIds n="1">
<Id>728</Id>
</BodyIds>
</Part>
<Part id="1206" label="m5" >
<Attributes n="3">
<Inspection name="class" value="screw"/>
<Inspection name="sub_class" value="M5"/>
<Inspection name="inspection" value="screw,existence,surface"/>
</Attributes>
<BodyIds n="1">
<Id>1207</Id>
</BodyIds>
</Part>
</PartSet>
例えば様々なコンポーネントの幾何形状に対する追加要素は抑制される。XMLは潜在的に、例えばQIFフォーマットのMBDファイルに拡張(extension)として追加することに適している。MBDファイルに挿入されると、テスト要件は、他の任意の設計/製造プロセスへ伝搬されることができ、例えば後の設計改訂、及び/又は製造ステーションの構成に影響可能である。テスト要件はまた設計プロセスにテスト要件を満たす検査計画を入力する一次的な役割も有する。
この例では、Inspection要素が対応する各Part要素のAttributes要素に追加される。これは検査要件(この例ではセマンティック的に指定された)を設計文書に結びつける1つの方法である。
特性定義がname=”class”であるInspection要素の値は、コンポーネントの表記に対応する(例えばsurface又はscrewとして定義されるvalue特性を有する)。
特性定義がname=”sub_class”であるInspection要素の値は、コンポーネントのアノテーションに対応する(例えばclass-b,M3,M4,又はM5として定義されるvalue特性を有する)。これらのサブクラスについては、これらのサブクラスの内容を記述する追加的な要素(例えば下流の自動検査エージェントで実装可能)があると仮定される。任意選択的に、詳細が、上記のように参照によってではなく、個別のパラメータ及び/又はInspection要素のサブ要素として提供される。
name=”inspection”を有するInspection要素のvalue特性は、コンポーネントの検査の懸念(例えばsurface,screw又はexistenceなど)に対応して定義される。これらは任意選択的に、与えられた検査懸念に対して検査を計画及び/又は実行するように特別に構成された特定の下流の自動検査エージェントを参照する。
(通則)
本明細書において量又は値に関して使用される「約」という用語は「±10%以内」を意味する。
用語「備える」、「備えている」、「含む」、「含んでいる」、「有する」、及びそれらの活用形は、「含むがそれに限らない」ことを意味する。
「からなる」という用語は、「含み、かつ限定される」ということを意味する。
「本質的に~からなる」という用語は、組成、方法又は構造が追加的な成分、ステップ及び部分の少なくとも一つを含み得るが、その追加的な成分、ステップ及び部分の少なくとも一つが特許請求の組成、方法又は構造の基本的かつ新規の特性を実質的に変更しない場合に限る、ことを意味する。
本明細書で使用の、単数形の「1つの(a、an)」、「前記(the)」は文脈が明確にそうでないことを指示しない限り、複数の言及も含む。例えば、「1つの化合物」又は「少なくとも1つの化合物」という用語は、複数の化合物を、それらの混合物も含めて含み得る。
「例」及び「例示的」という用語は、本明細書では、「例、実例又は例示に供する」という意味で使用される。「例」又は「例示的」として記述されるあらゆる実施形態は、他の実施形態よりも好適又は有利であるとして、又は他の実施形態の特徴を組み込むことを排除するとして、またはその両方として、必ずしも解釈されるべきではない。
「任意選択的に(optionally)」という用語は、本明細書においては、「ある実施形態では提供され、他の実施形態では提供されない」ことを意味するように使用される。本開示のいずれの特定の実施形態も、そのような特徴が相反しない限り、複数の「任意選択的な」特徴を含み得る。
本明細書で使用の「方法」という用語は、与えられたタスクを達成するための、やり方、手段、技術及び手順を指し、これに限らないが、化学、薬理学、生物学、生化学および医学の専門家に既知であるか又はそれらの専門家により、既知のやり方、手段、技術及び手順から容易に開発される、そのようなやり方、手段、技術及び手順を含む。
本明細書で使用の「対処する(treating)」という用語は、状態の進行を無効にする、実質的に抑制する、遅延させる又は逆行させること、状態の臨床的又は審美的な症状を実質的に改善すること、あるいは、状態の臨床的又は審美的症状の出現を実質的に防止することを含む。
本出願を通して、実施形態は範囲形式を参照して提示され得る。範囲形式の記述は、単に便宜的かつ簡単のためのものであって、本開示の記述の範囲を一定不動の限定として解釈されるべきではないことを理解されたい。従って、範囲の記述は、その範囲内の個別の数値と共にすべての可能な部分範囲を具体的に開示しているものと見なされるべきである。例えば、「1~6」というような範囲の記述は、その範囲にある個別の数字、例えば1、2、3、4、5、6、と共に、「1~3」「1~4」「1~5」「2~4」「2~6」「3~6」などの具体的に開示された部分範囲を有すると見なされるべきである。このことは、範囲の広さに拘わらず適用される。
本明細書に数値範囲(例えば「10~15」、「10から15」、あるいは別のそのような範囲を示すもので結合された任意の数字の対)が示されるときはいつでも、文脈に明確にそうでないことが指示されない限り、示された範囲の限界内の任意の数(分数又は整数)が、その範囲の限界を含めて含まれることが意味される。第1の指定数と第2の指定数と「にわたる/にわたった/の間の範囲の」という句、及び、第1の指定数「から」第2の指定数「まで(to)」、「最大で(第2の指定数)まで(up to)」、「まで(until)」、第2の指定数を「含んでそこまで(through)」「にわたる/にわたった/の間の範囲の」という句は、本明細書では互換可能に使用されて、第1の指定数及び第2の指定数、並びにその間のすべての分数及び整数を含むことを意味する。
本開示の説明は、特定の実施形態とともに提供したが、多くの代替、修正、及び変形が当業者に明らかであることは明白である。したがって、本開示の説明は、添付の特許請求の範囲の精神及び広い範囲内にあるそのような代替、修正及び変形のすべてを包含することが意図されている。
本明細書で言及したすべての刊行物、特許及び特許出願は、各個別の刊行物、特許又は特許出願が具体的かつ個別的に参照により本明細書に組み込まれるように表示された場合と同じ程度に、参照によってその全体が本明細書に組み込まれる。さらに、本出願中のいかなる参照の引用または特定は、そのような参照が本開示に対する先行技術として利用可能であることを認めるものと解釈されるべきではない。セクション見出しに使用される限りでは、それらは必ずしも限定的であると解釈されるべきではない。さらに、本出願のあらゆる優先権書類は参照によりその全体が本明細書に組み込まれる。
特定の特徴は、わかりやすくするために本開示では別々の実施形態の文脈に記述されていても、組み合わせて1つの実施形態で提供され得ることが理解される。逆に、簡潔にするために単一の実施形態の文脈中に記述される本発明の様々な特徴は、別々または適切な部分的組合せで提供されることも、又は本開示の任意の他の説明された実施形態に適切であるとして提供されることも、可能である。様々な実施形態の文脈で記述される特定の特徴は、これらの要素なしではその実施形態が動作不能でない限りは、これらの実施形態の必須の特徴とは見なされない。

Claims (43)

  1. 製造物に対する外観検査要件を定義する方法であって、
    前記製造物の設計モデルを含むモデルベース定義(MBD)にアクセスし、
    MBDによって指定されたコンポーネント間の関係の自動的分析に基づいて、製造物のコンポーネントに対する検査要件を特定し、
    前記製造物の外観検査の機械プラニングに使用するために、前記特定された検査要件を符号化すること
    を含む方法。
  2. 前記MBDは前記設計モデルで指定されたコンポーネント間の階層関係を指定し、前記特定された検査要件は、前記MBDで指定されたコンポーネント間の特定の階層関係を特定する自動的分析に基づく、請求項1に記載の方法。
  3. 前記コンポーネント間の階層関係は、前記製造物のアセンブリ間の関係に対応する、請求項2に記載の方法。
  4. 前記検査要件の特定は、前記MBDで指定されたコンポーネント間の幾何学的関係を特定する自動的分析に基づく、請求項1~請求項3のいずれか一項に記載の方法。
  5. 前記検査要件の特定は、前記MBDで指定されたコンポーネント特性のパターンを特定する自動的分析に基づく、請求項1に記載の方法。
  6. 前記検査要件を満たす外観検査計画を自動的に生成し、
    前記製造物の少なくとも1つのインスタンスに前記外観検査計画を実行すること、
    を含む、請求項1に記載の方法。
  7. 前記検査要件は、前記MBDにより指定された1以上のコンポーネントの検査に関する品質上の懸念を、前記品質上の懸念に対応する特性や動作の指定なしに指定するオープン検査要件を含む、請求項6に記載の方法。
  8. 前記オープン要件はセマンティック要件である、請求項7に記載の方法。
  9. 前記外観検査計画を生成することは、前記オープン検査要件を、前記コンポーネントの特性とそれらの特性の測定動作とを指定する、対応するクローズド検査要件に自動的に変換することを含む、請求項7~請求項8のいずれか一項に記載の方法。
  10. 前記変換は前記MBDを使用する、請求項9に記載の方法。
  11. 前記外観検査計画を生成することは、前記MBDによって指定される階層関係を使用して、前記検査要件を満たす動作を実行すべき段階を決定することを含む、請求項9~請求項10のいずれか一項に記載の方法。
  12. 前記外観検査計画を生成することは、前記MBDによって指定される幾何学的情報を使用して、前記検査要件を満たす動作を実行すべき段階を決定することを含む、請求項9~請求項11のいずれか一項に記載の方法。
  13. 自動的処理により、前記オープン検査要件に基づいて、前記変換のために前記MBDからどの情報を抽出すべきかを決定する、請求項10に記載の方法。
  14. 前記検査要件はオープン検査要件のみを含む、請求項7~請求項8のいずれか一項に記載の方法。
  15. 前記検査要件は、特性と、前記外観検査計画の実行時に前記特性を測定するための測定動作とを指定するクローズド検査要件を含む、請求項6~請求項8のいずれか一項に記載の方法。
  16. 前記符号化は検査指定データ要素を前記MBDに挿入することを含む、請求項1~請求項15のいずれか一項に記載の方法。
  17. 前記MBDは1以上のQIFファイルとして指定され、前記検査指定データ要素は前記1以上のQIFファイルの要素への参照を使用して定義される、請求項16に記載の方法。
  18. 前記検査指定データ要素はXMLとして定義される、請求項17に記載の方法。
  19. 前記挿入された検査指定データ要素に基づいて前記MBD内の設計仕様を調整することを含む、請求項16に記載の方法。
  20. 前記挿入された検査指定データ要素に基づいて製造計画を調整することを含む、請求項16~請求項19のいずれか一項に記載の方法。
  21. 前記特定することは、前記MBD内に定義されたコンポーネント間に指定された階層関係の分析に基づいて、予め定義された検査要件ライブラリから検査要件を選択することを含む、請求項1~請求項20のいずれか一項に記載の方法。
  22. 前記MBD文書の階層の分析は、前記選択された検査要件の選択条件である述語トリガを特定することを含む、請求項21に記載の方法。
  23. 前記述語トリガの特定は、所定のコンポーネント構成を含むアセンブリを特定することを含む、請求項22に記載の方法。
  24. 前記述語トリガの特定は、アセンブリ内のコンポーネントの可視性を判定することを含む、請求項22~請求項23のいずれか一項に記載の方法。
  25. 前記述語トリガの特定は、アセンブリ内のコンポーネントのアクセス性を判定することを含む、請求項22~請求項24のいずれか一項に記載の方法。
  26. 前記述語トリガの特定は、前記MBDによって指定された設計階層仕様内のテキストコンテンツの分析を含む、請求項22~請求項25のいずれか一項に記載の方法。
  27. 調整入力により前記述語トリガの特定を修正して、前記特定の仕方を変化させる、請求項22~請求項26のいずれか一項に記載の方法。
  28. 前記調整入力は、手動による入力を含む、請求項27に記載の方法。
  29. 前記調整入力は、検査方針を符号化するデータを含む、請求項27に記載の方法。
  30. 前記調整入力は、部品在庫、部品供給源、工具状態、工具可用性、作業者訓練状態、労働力配分、の1以上に関する工場状態を記述するデータを含む、請求項27に記載の方法。
  31. 調整入力に従って、前記選択を修正することを含む、請求項21~請求項26のいずれか一項に記載の方法。
  32. 前記修正は、特定の検査要件を追加、削除、または修正することを含む、請求項31に記載の方法。
  33. 前記調整入力が、手動による入力を含む、請求項31~請求項32のいずれか一項に記載の方法。
  34. 前記調整入力は、検査方針を符号化するデータを含む、請求項31~請求項33のいずれか一項に記載の方法。
  35. 前記調整入力は、部品在庫、部品供給源、工具状態、工具可用性、作業者訓練状態、労働力配分の1以上に関する工場状態を記述する、請求項31~請求項34のいずれか一項に記載の方法。
  36. 前記特定することは、追加処理により前記選択された検査要件を準備することを含む、請求項21に記載の方法。
  37. 前記MBD文書は、1以上のQIFファイルを含む、請求項1~請求項36のいずれか一項に記載の方法。
  38. 前記検査要件は、アセンブリが、セマンティック検査エージェントが利用可能なクラスに属することを示すトリガ述語を前記MBD内で特定することに基づいて選択される、オープン検査要件である、請求項1に記載の方法。
  39. 製造物に対する外観検査要件を定義するシステムであって、
    前記システムは、コンピュータプロセッサとメモリとを備え、
    前記コンピュータプロセッサは前記メモリ媒体内の命令にアクセスするように構成され、
    前記命令は前記コンピュータプロセッサに対して、
    前記メモリから前記製造物の設計モデルを含むモデルベース定義(MBD)にアクセスし、
    前記MBDによって指定されたコンポーネント間の関係の自動的分析に基づいて、前記製造物のコンポーネントに対する検査要件を特定し、
    前記製造物の外観検査の機械プラニングに使用するために前記特定された検査要件を符号化する
    ように指示する、システム。
  40. 前記MBDは、1以上のQIFファイルを含む、請求項39に記載のシステム。
  41. 前記特定された検査要件はXMLファイルとして符号化される、請求項39~請求項40のいずれか一項に記載のシステム。
  42. 前記MBDは前記設計モデルで指定されたコンポーネントの階層関係を指定し、
    前記コンピュータプロセッサは、前記MBDで指定されたコンポーネント間の特定の階層関係を特定することにより検査要件を特定する、
    請求項39~請求項41のいずれか一項に記載のシステム。
  43. 前記コンポーネント間の階層関係は、前記製造物のアセンブリ間の関係に対応する、請求項42に記載のシステム。
JP2023508519A 2020-08-05 2021-08-05 コンポーネント間の検査要件の設計符号化 Pending JP2023542609A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202063061206P 2020-08-05 2020-08-05
US63/061,206 2020-08-05
PCT/IL2021/050957 WO2022029787A1 (en) 2020-08-05 2021-08-05 Design encoding of intercomponent inspection requirements

Publications (1)

Publication Number Publication Date
JP2023542609A true JP2023542609A (ja) 2023-10-11

Family

ID=80117118

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023508519A Pending JP2023542609A (ja) 2020-08-05 2021-08-05 コンポーネント間の検査要件の設計符号化

Country Status (6)

Country Link
US (1) US20230297092A1 (ja)
EP (1) EP4193335A1 (ja)
JP (1) JP2023542609A (ja)
CN (1) CN116348825A (ja)
IL (1) IL300371A (ja)
WO (1) WO2022029787A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023227201A1 (de) * 2022-05-24 2023-11-30 Siemens Ag Österreich Computer-implementiertes verfahren und system zur steuerung der herstellung eines produkts
CN116029623B (zh) * 2023-02-17 2023-06-30 希维科技(广州)有限公司 构建检验流模型的方法、设备及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8131055B2 (en) * 2008-01-31 2012-03-06 Caterpillar Inc. System and method for assembly inspection
US9187188B2 (en) * 2013-07-02 2015-11-17 Premium Aerotec Gmbh Assembly inspection system and method
CN112837266A (zh) * 2014-11-24 2021-05-25 基托夫***有限公司 自动检查
WO2016179186A1 (en) * 2015-05-04 2016-11-10 Mitutoyo Corporation Inspection program editing environment providing user defined collision avoidance volumes
CN111027134A (zh) * 2019-11-14 2020-04-17 中国航空工业集团公司西安航空计算技术研究所 一种实现基于mbd的航空复杂结构件的检验方法

Also Published As

Publication number Publication date
EP4193335A1 (en) 2023-06-14
WO2022029787A1 (en) 2022-02-10
IL300371A (en) 2023-04-01
US20230297092A1 (en) 2023-09-21
CN116348825A (zh) 2023-06-27

Similar Documents

Publication Publication Date Title
Mayer et al. IDEF family of methods for concurrent engineering and business re-engineering applications
Armillotta A method for computer-aided specification of geometric tolerances
US8346773B2 (en) Product classification system
WO2018113164A1 (zh) 一种三维检测文件的生成方法及检测方法
JP2023542609A (ja) コンポーネント間の検査要件の設計符号化
JP2007087216A (ja) 階層型辞書作成装置、プログラムおよび階層型辞書作成方法
US8433550B2 (en) Requirements driven feature development process
CN115168971A (zh) 基于构件参数库的装配式建筑设计与建造一体化协同方法
Stephan et al. Using mutation analysis for a model-clone detector comparison framework
Krogstie Capturing enterprise data integration challenges using a semiotic data quality framework
CN114357596B (zh) 一种bim构件资源快捷设计方法及***
US8375352B2 (en) Terms management system (TMS)
CN109086985B (zh) 面向航天器总装的专业测试信息管理***
Barreiro et al. Information model for the integration of inspection activity in a concurrent engineering framework
CN112001047B (zh) 一种基于pmi信息的雷达关键零部件工艺设计方法
CN112100768A (zh) Cad模型审查方法及***
CN109271691B (zh) 一种关键特性的自动提取快速标注方法
Goh et al. An integrated environment for product development using STEP/EXPRESS
CN111581815B (zh) 一种基于xml的工艺模型本体构建方法
CN109872080B (zh) 一种飞机装配协调规则知识管理方法及***
US20110213728A1 (en) Requirements check-in/out tool, called r2db
US20100204961A1 (en) Integrated system design
Mitchell et al. Flower: Viewing data flow in er diagrams
Khedri et al. Incremental variability management in conceptual data models of software product lines
CN112698836B (zh) 一种针对复杂用户评论的代码质量属性判断方法