CADデータ交換への論理的アプローチ
データ交換とサプライチェーン
CADデータ交換とは、共同設計/エンジニアリング/製造企業間で3D設計データを移動することを通常指します。これを次のように考えることができます。CADデータ交換の階層がOEMを頂点とし、その下にTier 1サプライヤー、そのさらに下に上位サプライヤーの下請業者がある三角形である場合、CADデータ交換の流れは上下双方向に流れるストリームとして見ることができます。
しかし、データの流れを双方向のストリームとして記述できるにもかかわらず、データの内容は変化します。通常、OEMと上位サプライヤー間で移動するデータは、上位サプライヤーと下請業者間で移動するものとは異なります。一般に、OEMと上位サプライヤーの間で移動するデータは非常に大きくて複雑です。それはネイティブのCADデータであるか、STEPであるか、JTのようなビジュアライゼーションフォーマットかもしれません。
サプライチェーンの下流のエンジニアリングには、ツール設計と製造、ツールホルディングの設計と製造、上位サプライヤーレベルで作成されるコンポーネントに不可欠な小さな部品の設計と製造が含まれます。これらの項目は、納期に関わる重要なパスにしばしば含まれており、このレベルでのCADデータ交換プロセスの最適化が非常に望ましいです。
既存のCADデータ交換プロセスはどれほど効率的か？
CADデータ交換の特徴の一つは、問題が起こるためには特別なスキルと専門知識が必要であることです。一部の企業では、CADデータ交換の役割に専念する人々がいます。他の多くのことと同様に、プロセスが自動化され、主要スタッフの依存を最小限にできる場所で、CADデータ交換は最も効率的です。CADデータ交換がピーク時間外に行われ、照明を使用しない環境で行われ、利用可能なリソース全体で負担を分散できる場合、節約が図られます。 CADデータ交換監査履歴を自動化することで、さらなる価値を追加できます。
複数の異なる種類のCADデータがCADデータ交換を強制する
共同企業間のCADデータ交換の複雑さが設計/製造業界にとって十分な挑戦ではないかのように、しばしば重要な内部的なオーバーヘッドがあります。特に自動車や航空宇宙のサプライチェーンにおいては、多くの企業が複数のCADシステムを持っています。2つのアクティブなシステムを持つことはかなり一般的であり、3つが存在することは珍しいことではありません。この記事の執筆時点では、これらは通常CATIA、NX、Creoですが、CADDSがまだ存在している可能性もありますし、アクティブな設計システムでなくても、大量のCADDSデータが存在するかもしれません。
異なるタイプのCADシステムが2つまたは3つ存在することで、データを翻訳せずにより多くの顧客と相互運用性を可能にすることを議論することができますが、CADデータの翻訳が行われるポイントを単に移動させるだけです。プロジェクトは利用可能なリソースを簡単にオーバーフローさせることができ、リソースがCADシステムであれば、一つのCADシステムから別のCADシステムにオーバーフローすることは理にかなっています。
CADデータ交換、または次に何と呼ばれるにしても、それは単純なプロセスではありません。これは、人々がデータ交換のライフサイクルで発生する可能性のある一般的な問題を浮き彫りにし、それを回避するのを助ける試みです。それはデータ交換の決定版ガイドを意図したものではありませんが、実務経験とデータ交換分野の知識から構築されたヒントとコツです。
データの受信
受信することを期待しているものを知り、受け取ったときにそれを確認する
「外国」のデータをインポートまたは翻訳する必要がある場合、受信する予定のものを知っていると役立ちます。これにより、計画を立て、到着時に十分な時間と適切な翻訳ツールがあることを確保することができます。
それを見ることができますか？それが単一の部品ではなくアセンブリであるかどうかわかりますか？必要かもしれない色や他の属性データが含まれていますか？ファイルはどのくらいの大きさですか？この人物やこのソースからデータを扱ったことがありますか？通常業務と同じように見えますか、それとも新しい何かですか？
受信したものを理解する
正しいファイルタイプですか？圧縮ファイルですか？それはネイティブのCADファイルまたはSTEPファイルですか？翻訳プログラムがSTEPファイルを翻訳するように設計されているときに、ネイティブCADファイルを投入して、翻訳プログラムが動作しないと言う恥ずかしい事態を避けましょう。単純なことが見過ごされることがよくあります。例えば、ファイル拡張子を確認し、圧縮されたデータが解凍されていることを確認してください。定期的なデータ交換の要件がある場合、プロセスを定義し、送信者と受信者の両方が毎回同じ方法でデータを交換することをお勧めします。さまざまな人からさまざまなファイルを受け取るような相互運用性の仕事がある場合でも、プロセスの定義を試してみる価値があります。それによって誤解を避け、時間と労力を節約できます。
入ってくるデータを注意深く扱う
共同作業のために企業間で送信されるデータのほぼすべてには、どちらかの企業、または両方の知的財産が含まれています。このようなデータは注意を払って扱うべきです。電子ファイルは、安全な場所に保管され、メモの電子メールインボックスに添付されたまま放置されるべきではなく、公開FTPサイトのディレクトリに保存されるべきでもありません。理想的には、データを受け取ったときに、どのデータが到着したかを記録し、データを安全な場所に置き、送信者に安全に受信されたことを知らせるプロセスがあるべきです。同様のプロセスは、USBドライブやDVDなどの物理メディアで受け取ったデータにも適用されるべきです。机の上に放置されたまま封筒から取り出されるべきではなく、安全なメディアストアに保管されるべきです。
必要なものだけを翻訳する
仕事に必要以上のデータを受け取るのは珍しいことではありません。極端な例として、ヒンジのメーカーがドアヒンジの適切な配置とフィットを保証するために車の半分の車体を受け取るかもしれません！それほど悪くはないことがよくありますが、そうなることもあります。理想的な状況は、事前に送信組織と十分な対話を行い、必要なデータを正確に合意してそのデータのみを送信することです。
しかし、時にはそれができないことがあります。これが生み出す問題の1つは、大きなファイルをどのように扱うかです。自分のCADシステムと直接互換性のない大きなCADファイルを受け取るのは良くありません。大きいとは何ですか？50メガバイトまたは100メガバイトのCADファイルは珍しくなく、IGESやSTEPファイルは数ギガバイトのサイズになることがあります！ファイルが大きければ大きいほど、翻訳が失敗する可能性が高くなります。翻訳を行っているマシンがメモリ切れになるかもしれません。このようなデータ量を扱う必要があることはめったにありませんし、そのような大きなファイルを送信することが避けられるのであれば、それは助けになります。
そのようなファイルを受け取る場合、いくつかの対策が可能です。送信者にサブアセンブリのセットとしてアセンブリを提供するように依頼することもできますが、これは商業的にセンシティブで、送信者に否定的なサインを送る可能性があり、実用的ではないかもしれません。送信者がファイルを分解したり、あなたのために簡単にするためにファイルの一部を削除することができないかもしれません。おそらくこれが最後の手段です。
使用している翻訳ツールに非常に精通している場合、必要なジオメトリだけを翻訳できるかもしれません。例えば、レイヤリングの慣習が使用されている場合があり、必要なレイヤーを翻訳するか、不要なレイヤーを除外することができます。必要なジオメトリがサーフェースジオメトリである場合、解決策はサーフェースのみを翻訳することかもしれません。要するに、翻訳ツールの能力を知っていれば、大きなファイルを管理し、時間を節約し、仕事を完了するのに役立ちます。
成功したかどうかを知る方法
データ交換において、翻訳プログラムが限定された警告のみを発し、ファイルを生成した場合、通常成功したと仮定します。この仮定をすることは危険です。この段階で確実にわかることは、ファイルが作成され、ターゲットCADシステムに読み込まれる可能性があることです。これまでに起こったことから、元のCADモデルと同等のものが生成されたかどうかを判断することはできません。ファイルを検証するさまざまな方法があり、それぞれに長所と短所があります。完全に健全なモデルを持っているかもしれませんが、それが元のものと同じであるとは限りません。元の物性情報を送信者に求め、比較することができますが、それが同じであるように見えても、形状が異なるかもしれません。ソースモデルを視覚的に検査し、目的地モデルと視覚的に比較するだけで問題を確認するのに十分な場合がありますが、違いが見えなくても存在しないわけではありません。検証は難しい分野です。
幸いなことに、現在のところ、大半の翻訳プログラムがほとんどの時間働き続け、この種の問題があまり発生しないようにデータを交換できるようになりました。特に、時々いくつかのファイルを交換するだけの場合においては。この問題の真の規模は不明です。
検証の必要性は、翻訳されたデータの使用目的によって異なります。高価なツールを作成するために複雑な形状が使用される場合や、目視チェックを行わない多数のファイルを取り扱う場合、翻訳の精度と完全性の問題は非常に重要です。1万件以上のファイルが翻訳され、将来の利用のために必要とされる移行プロジェクトでは、単なるアーカイブ目的ではありません。手動チェックは非常に高価であり、時間と費用の両方の観点から禁止的であり、自動化手続きが必要です。幸いなことに、解決策は存在します。この投稿はそれらを説明するのに適した場所ではありませんが、SpinFire Convertは直接質問する人々に技術的および「ユースケース」詳細を提供できます。
翻訳が失敗したときに何をすべきか
失敗中に生成されたエラーメッセージが問題の明確な説明を提供しない限り、いくつかの対策を試みる必要があります。
最初に行うべきことは、テストファイルを通して翻訳プログラムを実行することです。正常であると知られているファイルが問題なく通過すれば、問題がソースファイルにあることを示します。逆に、正常に翻訳されることが知られているファイルが失敗する場合、翻訳プログラムに問題があると考えられます。ライセンスの問題やアクセス権限の問題、またはパスの変更などが考えられます。このような問題は通常、少しの時間と労力で解決されます。
テストファイルが翻訳プログラムを問題なく通過する場合、課題は受信ファイルにあります。最初の判断は、自分で解決しようとするか、それとも送信者に戻すか、翻訳プログラムのサプライヤーに助けを求めるかです。
問題を自分で解決することを決定した場合、ここから始めることができます。
ソースデータを表示できるツールを持っている場合は、それを使用してソースファイルが無欠かどうか確認してください。表面間のギャップや欠落している表面は明らかであり、壊れたファイルの兆候かもしれません。
ファイルサイズを確認し、送信者に確認を依頼してください。最初のコピーの過程で問題が生じた可能性があります。
翻訳プログラムが生成したログファイルを理解している場合、これを調べることでいくつかの手がかりが得られます。どの段階で翻訳プログラムが失敗したかを確認することは、層やエンティティタイプを選択的に翻訳することで回避できるソースファイルの問題を示すことがあります。実際には、翻訳プログラムのログファイルを読んで理解できる人々はほとんどいません。この領域に足を踏み入れたくないと思うのも無理はありません。
もう一つのオプションはファイルを別の形式に翻訳しようとすることです。複数の翻訳プログラムを持っている場合、問題のあるファイルが別の形式に問題なく変換されることがあるかもしれません。それはもちろん、そのファイルを望む形式に変換できる場合にのみ役立ちますし、もちろん誰も複数回の翻訳の過程で何が失われたかを知りません。しかし、時にはうまくいくこともあります。
あなたの翻訳プログラムの会社は通常、ソースファイルを調査するツールを持っており、それが問題の原因であることを教えてくれるでしょう。
別のオプションは、翻訳プログラムのサプライヤーのサポートセンターに連絡することです。あなたはメンテナンスに支払い済みですよね？今、望む形式のファイルを作成することを妨げる唯一のものはソースファイルに欠陥があることです。そうである場合、ファイルを最初に送信した人に戻す以外に選択肢はほとんどありません。
データの送信
高品質なデータのみを送信する
あなたのビジネスパートナーが送信したファイルを正常にインポートするためには、可能な限り最高の品質のファイルを送信することを確認してください。あなたの設計ソフトウェアにあるすべての「チェック」ルーチンを通してそれらを実行します。エラーがある場合、たとえそれがあなたのCADパッケージに違いがなくても、翻訳では致命的な問題になる可能性があります。例えば、CADパッケージがソリッドを作成する場合、表面に隙間があっても、翻訳された部品が他のパッケージに読み込まれ、データを固体として表現する保証はありません。ソリッドが重要である場合、隙間のある表面ではなく、ソリッドを送信してください。
この種の問題は、この問題を「修正」する翻訳プログラムを誕生させましたが、このアプローチにはいくつかの潜在的な問題があります。例えば、修正に形状の変更が必要な場合、それは設計変更を構成し、それが起こるべきかどうかであるべきですか？最良の相互運用性は、高品質のソースファイルとともに機能し、設計変更の問題が発生しません。
データの使用目的を知り、可能であれば軽量データを送信する
ネイティブのCADモデル、IGES、STEP、軽量形式（JT、3DXML、Creo View、3D PDFなどを含む）の形でデータを交換する方法はいくつもあります。実際、軽量データを送信するだけで目標を達成できることを知っている場合、それが最良の方法です。軽量データの作成は迅速で、ファイルが小さく、目的地のCADシステムに読み込まれることはめったにありません。
テッセレーションデータを作成するオプションがある場合、それはパッケージング、急速なプロトタイピング、ステレオリソグラフィーの使用、およびおおよその衝突検出に使用できます。それだけが欲しいなら、テッセレーションデータを送信するだけです。ただし、軽量形式はテッセレーションデータのみで構成されていると間違えないでください。一部の軽量形式には、正確なBREPジオメトリが含まれており、元のCADファイルで達成されたほぼすべてのことに使用できます。
最も重要なのは、軽量データ形式による相互運用性は、知的財産を外部に移転することを制限する最良の方法の一つであることです。したがって、技術的に十分かつ商業的に理想的であると主張されるかもしれません。
受信者が必要とするデータのみを送信する
一対一のデータ交換では、受信者が必要とするデータを正確に知り、それを最適な形式で送信することができます。これは、プロジェクトデータを送信するプロジェクトで、設計をコンテキストで行うサプライヤーや、ボディシェイプのツールを作成するサプライヤー、またはロボティック作業セルを作成するサプライヤーの数に送信する場合により難しくなります。これらの場合の理想的な解決策は、各サプライヤーに必要な形式でデータを送信することですが、このプロセスが自動化されない限り、時間と労力の面で高コストがかかる可能性があります。多用途のプロジェクトデータの送信は、このような大きなファイルが時折送信される理由の一つです。可能であれば、サプライヤーが必要とするものだけを送信することが良いとされています。
フィーチャーと履歴はどうなる？
フィーチャーと履歴が含まれたデータを送信するかどうかの判断は難しいものであり、企業方針による場合もあります。モデルにフィーチャーと履歴を含めて送信することが、企業機密情報と知的財産を妥協する最も可能性の高い方法であることに疑いはありません。
トレードオフは、受信者に完全に修正可能なデータセットを提供する必要があると考えられます。しかし、実際にはそうではありません。これまでのところ、フィーチャーと履歴の翻訳は完全に効果的ではなく、かなり頻繁にモデルが完成する前に大幅なオペレータの相互作用を必要とします。一部の最新のモデリング技法は、翻訳されたジオメトリを直接編集することで非常に効果的であるため、履歴を翻訳することにはまったく価値がないことを示すかもしれません。
結論
CADデータ交換は、現代の共同エンジニアリングの特徴です。
ここでの提案の大半は、この作業の一部としてCADデータ交換が行われることを発見する人々の大半に知られているものです。この目的は、CADデータ交換に影響を与える数学的または技術的な問題を挙げることではなく、相互運用性を改善するためにできる既知の、しかしもしかしたら忘れられていることを再び思い出させることです。
CADデータ交換のニーズに対応するための、利用可能なソリューションについて詳しく知るには、SpinFire Convertのページを訪問してください。