多アーム船舶溶接の検査とトレーサビリティ：データだけでなく溶接部を追跡する

有用な記録は溶接の決定を追跡します

造船の溶接セルは、単純な質問を未解決のままにして、多くのデータポイントを生成する可能性があります。つまり、この結果はどの実際の溶接を表しているのか、そしてその溶接は受入れられたのかということです。 トレーサビリティは、ダッシュボード上のチャネルの数ではなく、アイデンティティとステータスから始まります。必要な記録は、識別可能な作品の図面要件、操作、検査、およびリリースの決定を結び付ける必要があります。

複数のアームが一つの組立品を共有する場合、この点はさらに重要です。TitanWeld の船舶向け概要では、基本協調単位あたり二つのアームを使用し、現在の上限は四つのユニット・八つのアームです。高度な個別設計が必要であり、プロジェクトに合わせて構成しなければなりません。一つのアームに計画された溶接が中断され、別の承認済み作業で完了することもあります。その履歴を通じて、溶接の識別情報は一貫して維持する必要があります。

以下のレコード構造は提案されたエンジニアリング手法です。これは、特定のトレーサビリティデータベース、自動検査システム、またはサードパーティ認証が提供されたコンセプトに含まれていることを意味するものではありません。プロジェクトは、データ収集を許容されるシステム範囲の一部として扱う前に、必要な情報、インターフェース、保持および解放の権限を指定する必要があります。

要件と実行に別の ID を使用する

制御されたマップ内の各溶接または定義された溶接セグメントに永続的な識別子を割り当てます。これをアセンブリ、図面リビジョン、コンポーネント参照、および必要な接合部の詳細にリンクします。ロボットの内部プログラムの番号付けに依存せずに、物理的な溶接箇所を特定できるように、識別子を十分意味のあるものにしておきます。パスが再生成されたり、ユニットの割り当てが変更された場合でも、品質レコードは有用なままでなければなりません。

各実行試行に独自の操作 ID を与えます。通常のパス、中断されたパス、再起動および修復は、区別可能なイベントを残しながら、同じ必要な溶接を参照できます。以前の試行を削除するのではなく、どの操作が別の操作に取って代わるか、または完了したかを記録します。この構造は、受入れられた結果がどのように達成されたか、介入後にどの領域が検査されたかを説明するのに役立ちます。

粒度を意図的に定義します。すべてのコントローラー補間点を個別の生産アイテムとして記録することは役に立ちませんが、パネル全体を 1 つの溶接として扱うと、局所的な例外が隠蔽されます。図面と検査計画を使用して、完成と合格を決定する必要があるレベルを選択します。記録は、整備者、オペレーター、検査員が行った実際の決定を裏付けるものでなければなりません。

溶接を制御された入力にリンクします

溶接記録は、作業に使用された図面と WPS のリビジョン、および品質システムを通じて適用される手順の認定範囲を示す必要があります。 TWI は、 WPS が溶接変数を定義し、認定レコードによってサポートされていると説明しています。 [1] ローカルロボットレシピ名は実行参照として保持できますが、それが唯一のプロセス定義になるべきではありません。

プロジェクトに必要なレベルで材料と消耗品の情報を関連付けます。異なる識別子を持つ分離された並列一覧を作成する代わりに、可能な場合は既存のヤードシステムを使用します。搬入時の状態のリリースと治具またはセットアップ参照が合意された受入れ方法の一部である場合は、それらを記録します。重要な点は、操作が使用された実際の入力に関連付けられる可能性があるということです。

最新のファイルへのリンクを単に保存するのではなく、リビジョンを保存します。将来の図面の変更により、以前の製造記録がまだ存在しない命令を使用したように見えてはなりません。実装では、管理されたアーカイブまたは別の承認された文書管理方法を使用できますが、履歴関係は再構築可能である必要があります。

プロセスデータが実際に何を意味するのかを把握する

合意されたレコードの使用にどの操作値とイベントが必要かを決定します。チャネルごとに、そのソース、単位、サンプリングまたは集計方法、および溶接セグメントとの関係を定義します。電源によって測定された電流値、指令された移動速度、および計算された熱入力推定値は、異なる種類の情報です。すべての値を直接測定された事実として提示するのではなく、それに応じてラベルを付けます。

Fronius は、コンポーネントレベルの溶接データの文書化と溶接システムとの関連付けについて説明します。 [2] この外部の例は、考えられるデータ管理カテゴリを示しています。これは、特定の製品または統合が TitanWeld のプロジェクトにインストールされていることを確立するものではなく、また、保存された値の検査の意味を確立するものでもありません。

アラームとギャップを解釈するために十分なコンテキストを保持します。レコードが欠落している場合は、溶接が行われなかったか、接続が失敗したか、またはログパスの外で操作が完了したことを意味する可能性があります。これらの状況では、さまざまな対応が必要になります。システムが不完全なデータ記録を識別する方法と、他の裏付け資料がプロジェクトの品質要件に十分であるかどうかを誰が判断できるかを定義します。

プロセス監視を検査とは別にする

プロセストレースは、記録された値が選択した範囲内にとどまっていることを示すことができます。別途確立され適用可能な検証基準がなければ、完成した溶接のあらゆる品質特性を証明することはできません。検査計画では、検査と合格に使用される基準を定義する必要があります。監視結果と検査官のリリースとの区別がつかなくなるような、自動的に緑色のステータスになることは避けてください。

TWI は、目視検査を他の検査技術を補完するものであり、適用可能な基準と結びつけていると説明しています。 [3] 溶接試験に関するガイダンスでは、破壊的方法と非破壊的方法も区別されています。 [4] プロジェクトは、責任ある品質および分類プロセスを通じて必要な組み合わせを選択する必要があります。この記事では、普遍的な NDT 割合や許容クラスについては説明しません。

検査結果を検査した物理的な場所に添付します。確立された品質システムを通じて、方法、レポートの参照、ステータス、および必要な人員または機器の参照を含めます。写真を使用する場合は、一般的な画像ファイル名に依存するのではなく、ビューと場所を特定します。見栄えの良いビーズの写真は依然として有用な裏付け裏付け資料ですが、その検査範囲は明確でなければなりません。

モデルステータスの明示的な遷移

溶接は、計画中、準備完了中、進行中、中断中、完了中、検査待ち、承認中、または修理が必要な場合があります。ヤードの用語を使用しますが、リリースに関連する区別は保持してください。プロジェクトで定義された承認プロセスがその移行を明示的にサポートしない限り、完成したロボットプログラムは自動的に承認された作業を意味するべきではありません。

どの役割または検証済みのシステムアクションが各ステータスを変更できるかを定義します。オペレータは修正されたセットアップを確認し、検査機能は受入れを記録し、認定エンジニアは処理を承認します。正確な責任はプロジェクトにあります。ソフトウェアは、アイテムが保持されていた理由を消去する可能性のある未差別の完了ボタンを提供するのではなく、それらを反映する必要があります。

変化の背後にある裏付け資料とそれが起こった時間を記録します。ステータスが修正された場合は、承認された監査方法を通じて以前のエントリと修正の理由を保持します。目的は管理上の負担を増やすことではありません。それは、あいまいな状態によって未完成または未検討の作業が製造ルートから放置されることを防ぐためです。

中断・修復した作業を履歴として保存

アークが予期せず停止した場合は、イベントを関連する操作および溶接位置に関連付けます。わかっていることと不明な点を記録します。コントローラの位置は有用な基準点を特定する可能性がありますが、それを許容可能な溶着溶接の正確な境界として自動的に扱うべきではありません。回収および検査方法は、必要に応じてその境界を確立する必要があります。

修理の場合は、最初の所見、許可された指示、準備、修理作業、その後の検査を結び付けます。元の溶接記録をきれいな最終パスに置き換えないでください。品質へのこだわりと生産努力の両方を説明するには歴史が必要です。また、繰り返し発生するプロセスの問題と、個別の受信状態やセットアップの問題を区別するのにも役立ちます。

承認されたリカバリデモンストレーション中にレコード構造をテストします。オペレータが正しい残りの作業を選択できること、修理がその親溶接のアイデンティティを保持していること、および受入れにより適切な項目が閉じられていることを確認します。ワークの配置では完成しているように見えるデータベーススキーマであっても、作業現場のインターフェイスがユーザーに中断のたびに無関係な新しいジョブを開始するよう促した場合、失敗する可能性があります。

複数のユニットとクロックソースの設計記録

複数のユニットが同時に事象を発生させる場合があります。各記録で共通の組立品をどう特定し、ユニット、アーム、作業をどう区別するかに合意してください。分析に必要な精度で時刻を同期するか、別の方法で整合させます。要件は使用目的に合わせる必要があります。生産順序の確認と詳細な施工調査では、必要な時間分解能が異なる場合があります。

利用できない接続と制御された再起動を計画します。何がローカルに保持されるか、何が転送の成功を示すか、重複または遅延したレコードがどのように調整されるかを確立します。これらは議論のためのインターフェイス要件であり、特定のオフラインモードを約束するものではありません。指定されたレコードを解放することが不可欠である場合、システムはそれを提供できないときに同意された応答を必要とします。

中央のダッシュボードが完全性を証明すると仮定することは避けてください。必要な溶接識別子を、受け取った操作および検査の記録と照合します。この比較により、主要な縦断的操作が広範なデータを生成した場合でも、ショートリターンの欠落が明らかになる可能性があります。この記録は、最も多忙な部門が作成したエントリーの量ではなく、その物理的な作業の範囲によって判断されるべきです。

受入れエクスポートをセル外で使用できるようにする

造船所が合意されたシステムを使用して読み取り、保持できるエクスポートを指定します。文書の改訂と現在のステータスとともに、アセンブリ、溶接、操作、検査の識別子の明確なマッピングを含めます。必要に応じて詳細なデータを保持しますが、レビュー担当者が例外を見つけてリリースの決定を理解できるようにするための簡潔な記録も提供します。

通常の溶接、中断、修理、またはその他の合意された例外を含む代表的なアセンブリを使用してエクスポートをテストします。受領側能に、関係がエクスポートおよびインポートで存続することを確認させます。治験に参加しなかった人でも、何が溶接されたのか、何が検査されたのか、そしてなぜそれが受入れられたのかを特定できるかどうかを確認してください。これは、 トレーサビリティ要件の実用的なユーザビリティテストです。

プロジェクト契約で、保存、アクセス、および変更管理の責任を設定します。担当者や明示された目的なしに情報を収集することは避けてください。関連する図面や手順を特定できない、管理されていない大規模なアーカイブよりも、品質計画に関連付けられた小規模で信頼性の高い記録の方が役立ちます。本番システムは、最初のキャプチャだけでなく、レコードの長期的な意味もサポートする必要があります。

特定の実稼働学習でループを閉じる

記録を使い、特定の回し溶接部、治具の設定、検出時の例外、繰り返す再開処理など、繰り返し発生する箇所と原因を特定します。施工条件を変更する前に、担当する技術部門と傾向を確認してください。ダッシュボード上の相関関係は調査の出発点であり、一つのパラメータが観察された不完全部を引き起こした証明ではありません。

承認された改善により手順、プログラム、設備が変更された場合は、新しい改訂とそれを裏付ける裏付け資料を記録してください。実際に作成した構成で古い作成履歴を保存します。これにより、後続の結果を正直に比較できるようになり、カウント対象のアセンブリに展開されなかった変更が改善の原因であると考えることを回避できます。

最後のトレーサビリティテストは直接的です。承認された溶接を選択し、その要件、入力、実行、例外、検査を再構築します。次に、必要な溶接を選択し、その受入れ状態が見つかることを確認します。これら 2 つの方向により、大規模なデータダッシュボードでは隠れてしまう可能性がある欠落リンクが明らかになります。プロジェクト固有の記録システムは、すべての部門およびすべてのアセンブリにわたってこれらの決定を一貫してサポートする場合に価値があります。

プロジェクト検討チェックリスト

• 各溶接 ID をその図面および手順のリビジョンにリンクします。
• アセンブリ、材料、および関連するプロセス情報を記録します。
• 該当する試験方法と合格基準を確認します。
• 観察、処置、修理、再検査を同じ接合部に関連付けます。
• 記録が取得できること、およびプロセスログが受入れの裏付け資料に代わらないことを確認します。