製品設計エンジニアのための故障解析方法:主要な質問と是正措置(パート3)

この故障解析シリーズのパート1とパート2では、故障がどこから来ているのか、それに対処するためにツールキットにどのようなツールを用意するのかについて説明しました。 今、難しい部分が来る:動作するようにすべてのそれらのツールを置く。 その中核となる障害分析は、出力が失敗する原因となった入力のセットと、それを修正するためにどのような是正措置を取るかを特定することです。 失敗を見つけて識別するためにすべてのハードワークをしたのであれば、あなたのプロセスを開始するために取ることができるいくつかの手順に

通常、ビルド中または信頼性テスト中に障害が見つかり、それらを見つけて修正するのに短い時間しかありません。 問題を認識したら、次の質問をして、障害分析を実行するときの考えを整理してください:

  • 故障モードとは何ですか?
  • 失敗はどれくらい重要ですか?
  • 失敗は繰り返し可能ですか?
  • あなたの仮説は何ですか?
  • 他に潜在的な要因はありますか?
  • どのようなデータがありますか?
  • どのようなデータが必要ですか?
  • 提案された解決策はありますか?
  • あなたの解決策をテストする方法はありますか?
  • あなたの解決策は他のチームに影響を与えますか?
  • 意図しない結果はありますか?

典型的な故障分析を説明するために、上記の質問をシナリオ例で順を追って説明します。

例:ウェアラブルフィットネス追跡ウォッチ

新しいウェアラブルフィットネスウォッチがEVTビルドで評価されています。 ビルド中にいくつかの小さな問題が切り取られますが、一般的にデバイスは動作します。 ただし、ビルド後、ドロップテスト中に障害が検出されます。 そこで、故障分析を開始します。

故障モードとは何ですか?

失敗を見つけるのは簡単な場合もありますが、より多くの場合、失敗の症状しか見られず、根本的な原因が実際に何であるかを確認できないことがあ この時計の例では、落下テストイベントにより、テストされた6台のデバイスのうち10台で表示が失敗することがわかります。 私たちが知っているのは、dropイベントの後に表示に何か問題が発生したことですが、なぜ失敗が発生したのかはまだわかりません。 まず、デバイスがどの状態にあるかを調べることから始めます。

  • 障害モードは、障害が発生したデバイスで同じように表示されますか?
    • 異なる種類の表示障害がある場合、dropイベントは複数の障害モードを公開している可能性があり、それぞれに根本原因がわずかに異なる可能性があ
    • 画面が白くなったのか?
    • 特定の行または列に行がありますか?
    • カバーレンズ割れましたか?
    • ディスプレイが割れましたか?
    • デバイスの残りの部分は機能しているように見えますか? -充電、モーター、タッチなど?
  • 失敗した特定のテストは何でしたか?
    • 時計はどの高さから落ちたのですか?
    • デバイスはどの基板に落としたのですか?
    • 失敗はどのような方向に起こったのでしょうか?
  • 観察できる他の明白な問題はありますか?
    • 装置の周囲に機械的な損傷はありますか?

サンプルを慎重に調べた後、4つの故障のうち6つは花崗岩基板上で行われたテストから来ており、2つはパーティクルボード基板から来ており、すべて1メートルのテーブルの高さから落下した。 障害の5では、ディスプレイが白に変わり、応答しないままになります。 6回目の失敗は、カバーレンズが割れたが、まだ画像を示していた。 デバイスの2では、カバーレンズにいくつかの擦り傷が表示されることがあり、デバイスの3では、一方の端にハウジングにいくつかの傷があります。

失敗はどれくらい重要ですか?

障害の重大度は低から高まで、その間には多くのレベルがあります。 時には、マイナーな問題のように見えるものは、より大きなものに風船。 典型的なウェアラブルは、その所有者によって使用され、虐待されます。 ユーザーがウォッチをオフにするたびに、ドロップイベントの潜在的な機会があります。 この場合、ディスプレイが応答しないドロップ失敗は、解決すべき重大な問題のように思えます。 応答しないディスプレイは、デバイスが使用できなくなり、高いリターン率と不幸な顧客の両方になります。 この問題は注意が必要であり、プログラムが次の手順に進む前に解決する必要があります。

失敗は繰り返し可能ですか?

再現性は、同じプロセスが一貫して失敗を引き起こす可能性があることを意味します。 ウェアラブルの場合、6つのデバイスのうち10つが失敗し、5つのデバイスのうち6つが同じように失敗しました。 これは、1つの失敗が再現可能であり、残りの失敗は、現時点では監視すべきではあるが取り組むべきではない1回限りの問題である可能性が高いこ それでも、データを少し深く掘り下げることによって、応答しない表示の問題が本当に再現可能かどうかを調べる必要があります。

  • 同じドロップ方向で障害が発生しますか?
    • 落下試験の手順は、通常、毎回同じ方法で実行されます。 それは、前面、次に背面、次に4つの側面、次に角から始まるかもしれません。 前面の落下が常に問題を引き起こす場合、障害が前面の落下の特定の向きによるものであるか、または同じ高さの落下から問題が発生するかどうかは不明である。
    • これに対抗するために、信頼性チームに別のシーケンスを使用するか、失敗した向きを最後に配置するユニットをより多くテストさせます。
  • 故障したすべてのユニットは、故障前に同じ信頼性テストのウォーターフォールを持っていましたか?
    • 良好な信頼性試験計画では、多くの場合、デバイスを前提条件とするために最初に環境試験が行われます。 一部はシステムに衝撃を与えるか、または付着力の結束を弱めることができる熱浸るか、または温度の循環テストを通って置かれます。
    • 新しいユニットと事前処理されたユニットで障害が発生した場合、障害はローカライズされた問題のように見えます。 そうでない場合は、落下試験の前に製品がどのような条件にさらされたかを理解する必要があるかもしれません。

あなたの仮説は何ですか?

私たちの時計には、2つ以上の根本的な問題があるかもしれません。 最初は、ディスプレイが白に変わり、応答しないままであることです。 ディスプレイ自体、ディスプレイコネクタ、またはディスプレイケーブルの機械的衝突または破損の問題を指すシステムから電源が切断されたと推測 または、バッテリまたは電源管理への接続により、デバイスが故障する可能性があります。

他に潜在的な要因はありますか?

多くの場合、挑戦的な失敗には多くの原因があり、時間を集中する場所を明確に特定することが困難になります。 失敗の分析の間にあなたの最初の仮説との問題があったら、調査するために可能な区域のリストを意見を出し合いなさい。

ウェアラブルでは、EVTビルドは私たちが何かを一緒に入れているのは初めてです。 多くの場合、ディスプレイモジュールやその他の主要コンポーネントのようなサブコンポーネントは、まだファイナライズされていないパラメータで製造されています。 このように、コネクタ、ディスプレイ、または機械的なアセンブリはすべて、ディスプレイの障害の原因となる可能性があります。

他の誤差の原因を排除するために、製造プロセスパラメータ、測定データ、組立写真をソートする必要があるかもしれません。 私たちは、追加情報を探すために私たちの上流のサプライヤーに深く飛び込む必要があるかもしれません。 この例では、ディスプレイが長い間生産の標準コンポーネントであり、大きなディスプレイの変更はなく、機械設計に焦点を当てるべきであることを示唆していると仮定しましょう。

故障解析にはどのようなデータがありますか?

ウェアラブルの信頼性障害では、仮説の検証に役立つ可能性のあるアクセス可能なすべての情報を収集する必要があります。 故障は機械的テスト中に発生したため、故障したユニットを物理的に検査し、特に故障の向きで、テストの前後の写真と高速ビデオを見直すことから始

明らかな変形や破損を探しています。 可能であれば、故障したデバイスのいくつかを検査し、内部に何か問題があるかどうかを確認するためにそれらを開く必要があります。 落下前にアセンブリと明らかに間違って何かがあったら単位の写真の前後に私達を示す。 高速ビデオは私達が目の瞬きより速く起こる材料の圧縮そして伸張を観察することを可能にする。 衝撃後にディスプレイとハウジングが反対方向に移動する場合は、さらに調査する価値があるかもしれません。

さらに、ディスプレイモジュールに関するIQCレポートと、メカニカルハウジングを含むアセンブリの主要部分の測定FAI/Cpkレポートを確認したいと思います。 実際の部品が、初期公差解析で使用した寸法と公差とどのように比較されるかを調べています。

これらのデータセットを組み合わせると、最初の仮説を洗練し、失敗分析調査を続けるうちに欠けているデータを考えることができるはずです。

故障解析にはどのようなデータが必要ですか?

我々はデバイスに物理的にアクセスできるが、デバイスを分解するまで何が間違っているのかはまだ分からない。 私達が3つの腕時計を開けるとき、私達は2のうち3の板に板コネクターが緩んで来たことが分った。 最後のものは、私たちは適切に分解することができず、コネクタの状態が何であるかを知ることができませんでした。 しかし、私たちが開いた2つのものは同じ問題を示したので、なぜコネクタが緩んだのかを探求したいと思うでしょう。

シミュレーションを見直し、コネクタやその他の嵌合部品が経験する力に焦点を当てたいと思います。 また、力保持のためのコネクタ仕様を確認し、これらのディスプレイと主回路基板のコネクタが仕様を満たしているか、それを超えていることを独 また、ベンダーがコネクタの低コストバージョンを使用していたり、さまざまな理由で間違ったコネクタを使用していたりする可能性があるため、コネクタのロットコードと部品番号を確認したいと考えています。

異なるディスプレイベンダーや他の構成が同じように動作するかどうかを確認するために、より多くのデバイスをテストする必要があ

提案された解決策はありますか?

私たちのウェアラブルでは、ディスプレイコネクタとそれを取り巻く機械的なアセンブリを関心のある領域として狭めています。 チームはアセンブリの分析に時間を費やし、いくつかの解決策を提案しました。 これらは次のとおりです:

  1. コネクターと主要なハウジング間の空隙をとるためにコネクター上の圧縮性の泡の小さい部分を加えること。
  2. コネクタにエポキシ樹脂を使用します。
  3. コネクタをしっかり固定するために、金属ブラケットといくつかのネジを追加します。
  4. ディスプレイFPCとボードのコネクタを変更します。

これらのソリューションにはそれぞれ長所と短所があり、テストには追加の作業が必要です。 オペレーションチームがディスプレイが標準コンポーネントであり、新しいコネクタに移動するとコストとリードタイムが大幅に増加すると言った後、オプ

機械的なソリューションには、設計およびアセンブリの変更が必要であり、機械的および電気的性能にも下流の影響を及ぼす可能性があります。

発泡溶液では、公称条件および落下試験条件のギャップの大きさを確認して、適切な材料を選択する必要があります。 泡がまた表示の下側で押すなら、私達はスクリーンを歪めるために後ろから余りに懸命に押さないことを確かめるべきです。

エポキシソリューションは簡単な修正かもしれませんが、プロセス構成や材料の選択についてのワームの缶を開くことができます。 さらに、部品がエポキシ化されると、このステップが組立ラインで実行されると、その後何かがうまくいかない場合、この組立全体を投げ出す必要があ

金属ブラケットでは、ブラケットを取り付けるスペースを見つけて、短絡の心配がないことを確認する必要があります。 ネジで取り付けると、途中に痕跡がたくさんある可能性が高いため、表示ルーティングがより困難になります。

あなたの解決策をテストする方法はありますか?

フォームとエポキシの二つのソリューションを試作するのは簡単かもしれません。 しかし、両方とも、特にビルドが完了した後に、いくつかのリスクが伴います。 私達は泡かエポキシを加えるためにある装置を分解する必要があります。 分解中に、私たちが調査しようとしているオプションよりも、制御されていない組立プロセスに関連する別の問題を導入する可能性が常にあります。 しかし、プロトタイプが約束を示している場合、これは解決策に自信を得るための迅速な方法になります。

金属ブラケットはCADでシミュレートしたり、一部の機械加工部品で近似することができますが、既存のハウジングで機能的に改造することは困難で ボードはネジボスに対応するように変更する必要があり、ボード自体に穴を開ける必要があるため、次のビルドの前に機能するプロトタイプを作ることはまずありません。 そのため、代わりに、機械的なモックアップとシミュレーションの組み合わせに依存して、設計変更がどのように実行されるかを近似することがで

あなたの解決策は他のチームに影響を与えますか?

他のチームに影響を与えるウェアラブルのためのすべての修正。 他の人にとって最も破壊的ではないのは、コネクタの後ろに泡を追加する可能性が高いことです。 これはテストするのが簡単なオプションで、他のチームによる最小限の変更または評価のみが必要です。 同時に、発泡体がコネクタが緩んで飛び出るのを防ぐのに十分であるかどうかは不明である。 また、フォームがディスプレイにあまりにも多くの力を加えると、ドロップイベント中にディスプレイの圧力ポイントとして機能したり、ディスプレイを押し上げてカバーレンズの端をクモの亀裂にさらすことによって私たちを傷つける可能性があります。

エポキシ溶液は、エポキシを適切に分配できるようにするために、組立プロセスに投資する必要があります。 液体接着剤プロセスは、それがプロトタイピングの価値があるかもしれないが、我々はこのオプションを使用しないことを望むかもしれないので、確定 また、歩留まり損失が高くなる可能性が高く、リワークがより困難になるため、製品のコストにヒットする可能性があります。

板金ブラケットは、実装に最も時間がかかり、電気チームが基板トレースを再度レイアウトする必要があります。 さらに、金属シールドが意図しない放射線を引き起こしたり、製品内の無線信号を妨害したりするかどうかを評価する必要があります。

意図しない結果はありますか?

問題を解決するために設計を変更すると、解決しようとしている問題に巻き込まれやすく、他に何が間違っているかを設計を評価するのを忘れる この例では、プリント回路基板に穴を開け、コネクタの上にブラケットをボルトで固定すると、ボードのこの領域が弱くなり、落下試験中にコネクタが緩んでしまう代わりに、ボード自体が壊れる可能性があり、解決しようとしていたものよりも大きな故障を引き起こす可能性があります。

この障害分析例のレビュー:

利用可能なデータのレビュー、仮説の作成、テストのプロセスを通じて、問題の潜在的な根本原因を発見しました。 私たちは、コネクタが定格よりも多くの力を経験し、コネクタの上部とハウジングとの間の設計されたエアギャップのために、エアギャップが一時的に大きくなったときに落下イベント中に緩んでくるだろうと考えています。 この問題を解決するために、テストと実装のための3つの可能な解決策を特定しました。 次にどの方法を選択するかは、ソリューションがどの程度うまく機能し、スケジュールやプロジェクトコストにどのように影響するかに依存します。

是正措置の監視

アクションコースが選択されると、チームは設計変更のプロセスを経るだけでなく、次のビルドでソリューションを実装し監視するための計画を策定する必要があります。

オプションを維持するために、チームはブラケットを追加し、フォームを準備するために設計変更を進めることにしました。 これは、電気チームのためのツールの変更とレイアウト作業に必要な小さなスケジュールヒットが発生しますが、うまくいけば、余分なEVTビルドの数を一つ

テストする大きな脆弱性があることを知って、チームはこの問題のデータ収集に優先順位を付けるようにビルドを手配することができます。 このビルドには、フォームだけの構成、金属ブラケットだけの構成、およびフォームとブラケットを一緒に含む構成が含まれる場合があります。

ビルドの前に、チームは新しいFMEAを実行し、新しい設計から潜在的な問題が発生する可能性がある場所を予測することができました。 Fmeaを出発点として使用すると、チームは変更が実装されている重要な変換でより多くのチェックステップを手配することができます。 オンサイトのエンジニアは、これらの手順でビルドに細心の注意を払うことを奨励する必要があります。

例えば、チームは新しいブラケットを組み立てるのがいかに難しいかを観察する必要があります。 この設計変更では、近くの部品を損傷することなく部品を適切に配置するために、新規または更新された治具が必要になる場合があります。 さらに、ブラケット自体の鋭角によりアセンブリか信頼性のテストの間に屈曲ケーブルへの損傷を与えることができる従って私達は収穫の放射性降下物のあらゆる印があるかどうか機能試験所の結果を早く点検するべきである。

最後に、新しいビルドからの最初のバッチのデバイスを信頼性テストのために割り当てるように手配する必要があります。 私たちは信頼性チームと協力して、テストする必要があるユニットの数を決定し、ソリューションに自信を持って合格することができます。 ビルドが進行中である間、新しい問題が発生しないことを確認しながら、1つまたは複数の構成が問題を解決するかどうかをより明確に把握できま

結論

ウェアラブルの例は、比較的簡単な問題であっても、障害分析中に考慮すべきことがたくさんあることを示しています。 信頼性レポート、物理デバイス、ビルドデータ、さらにはアップストリームベンダーからのデータは、何が間違っていたのか、それを修正する方法を理解しようとす

実際のプログラムでは、エンジニアは多くの異なる問題に直面し、それらをすべて並行して解決しなければなりません。 多くの場合、次のビルドの前にすべての問題について深いダイブ分析を実行する時間はほとんどありません。 したがって、小さな問題を迅速に排除して、特定のアーキテクチャで重要な課題に集中できるようにすることが重要です。 エンジニアが異種のデータセットを収集して接続するのに役立つツールは、潜在的な根本原因を特定し、同じ時間でより多くの問題を解決するのに非常 解決策が見つかると、コスト、スピード、実装の容易さについて精査され、誰もが最善の行動方針がどうなるかについて異なる意見を持つことになります。 根本的な原因が発見され、解決策が提案された後でさえ、これは障害が発生する可能性のある新しいベースラインを設定するだけです。 あなたが意図しない結果のホストを導入することができるので、本当のテストは次のビルドになります。 このプロセスは、時間がなくなるまで、または理想的な世界では、すべての問題を解決するまで繰り返されます。

Instrumentalは、故障解析のすべてのステップに伴う摩擦を軽減するためのユニークなツールセットを作成しました。 人工知能を介して製品データを収集し、画像を実行することにより、それらを停止するには遅すぎる前に可能な異常を見つけることができます。 また、製造最適化プラットフォームに重要なデータを保存して追跡し、失敗したテストデータと製品組立情報との相関を追加することもできます。 小さな失敗に費やす時間と労力を削減するだけでなく、大きな問題を解決するためにデータを収集して変換し、最終的に製品をより良くするように 故障解析プロセスの改善にどのように役立つかについての詳細は、当社にお問い合わせください。

Write a Comment

メールアドレスが公開されることはありません。