Loading article…
信頼性工学は、システム工学のサブ分野であり、機器が故障なく機能する能力を重視します。信頼性は、製品、システム、またはサービスが、指定された期間、意図された機能を適切に実行する確率、または、定義された環境で故障なく動作する確率として定義されます。[ 1 ]信頼性は可用性と密接に関連しており、可用性は通常、コンポーネントまたはシステムが特定の瞬間または時間間隔で機能する能力として説明されます。
信頼性関数は理論的には成功確率として定義されます。実際には、さまざまな手法を用いて計算され、その値は0から1の範囲をとります。0は成功確率がゼロであることを示し、1は確実に成功することを示します。この確率は、詳細な（故障の物理的）分析、過去のデータセット、または信頼性試験や信頼性モデリングによって推定されます。可用性、テスト容易性、保守容易性、および保守は、信頼性プログラムにおいて「信頼性エンジニアリング」の一部として定義されることがよくあります。信頼性は、システム全体の費用対効果において重要な役割を果たすことがよくあります。
信頼性工学は、高レベルの「寿命」工学的不確実性と故障リスクの予測、防止、および管理を扱います。確率的パラメータは信頼性を定義し、影響を与えますが、信頼性は数学と統計だけで達成されるものではありません。[ 2 ] [ 3 ] 「この主題に関するほとんどすべての教育と文献はこれらの側面を強調し、関連する不確実性の範囲が予測と測定のための定量的方法を大幅に無効にするという現実を無視しています。」[ 4 ]たとえば、「故障確率」を方程式の記号または値として表現することは簡単ですが、実際にはその真の大きさを予測することはほぼ不可能であり、それは非常に多変量であるため、信頼性の方程式を持っていることは、信頼性の正確な予測測定を持っていることと同義ではありません。
信頼性工学は、品質工学、安全工学、システム安全と密接に関連しており、分析に共通の手法を用い、互いの情報を必要とする場合がある。システムは信頼性をもって安全でなければならないと言える。
信頼性工学は、システムのダウンタイム、スペアパーツ、修理機器、人員、保証請求のコストによって引き起こされる故障のコストに焦点を当てています。[ 5 ]
「信頼性」という言葉は1816年にまで遡ることができ、最初に確認されたのは詩人のサミュエル・テイラー・コールリッジです。[ 6 ]第二次世界大戦前は、この用語は主に再現性と結びついていました。あらゆる種類の科学におけるテストは、同じ結果が繰り返し得られる場合に「信頼できる」とみなされました。1920年代には、ベル研究所のウォルター・A・シューハート博士が統計的プロセス管理の使用による製品改良を推進しました。[ 7 ]これは、ウォルディ・ワイブルが疲労の統計モデルに取り組んでいた頃です。信頼性工学の発展は、品質と並行した道をたどりました。信頼性という言葉の現代的な用法は、1940年代に米軍によって定義され、期待どおりに特定の期間動作する製品を特徴づけるものとなりました。
第二次世界大戦中、信頼性に関する多くの問題は、当時入手可能だった電子機器の固有の信頼性の低さと疲労に起因していました。1945年、MA MinerはASME誌に「疲労における累積損傷」という画期的な論文を発表しました。軍事における信頼性工学の主な応用分野は、レーダーシステムやその他の電子機器で使用される真空管であり、その信頼性は非常に問題が多く、コストもかさむことが判明しました。IEEEは1948年に信頼性協会を設立しました。1950年、米国国防総省は軍事機器の信頼性手法を調査するために、「電子機器の信頼性に関する諮問グループ」（AGREE）と呼ばれるグループを設立しました。[ 8 ]このグループは、主に3つの作業方法を推奨しました。
1960年代には、部品レベルおよびシステムレベルでの信頼性試験に重点が置かれるようになりました。有名な軍事規格MIL-STD-781はこの時期に制定されました。この頃、RCA社から軍事ハンドブック217の前身となる広く利用されている規格が発行され、電子部品の故障率予測に用いられました。部品の信頼性と経験的研究（例えばMIL-STD-217）のみに重点を置く傾向は徐々に薄れていきました。消費者産業で用いられているような、より実用的なアプローチが採用されるようになったのです。1980年代には、テレビはますます固体半導体で構成されるようになりました。自動車はボンネットの下やダッシュボードに様々なマイクロコンピュータを搭載し、半導体の使用を急速に拡大しました。大型空調システムや電子レンジ、その他様々な家電製品にも電子制御装置が開発されました。通信システムも、従来の機械式交換システムに代わるものとして電子機器を採用し始めました。ベルコア社は通信分野における初の消費者向け予測手法を発表し、SAEは自動車用途向けに同様の文書SAE870050を開発しました。この10年間で予測のあり方は変化し、集積回路（IC）の故障率を決定する要因はダイの複雑さだけではないことが明らかになった。
カム・ウォンはバスタブ曲線に疑問を呈する論文を発表した[ 9 ] ―信頼性中心保全も参照。この10年間で、多くのコンポーネントの故障率は10分の1に低下した。ソフトウェアはシステムの信頼性にとって重要になった。1990年代までに、IC開発のペースが加速した。スタンドアロンのマイクロコンピュータの広範な使用が一般的になり、PC市場はIC密度がムーアの法則に従い、約18か月ごとに倍増し続けるのに役立った。信頼性工学は、故障の物理学の理解に向かうにつれて変化し始めた。コンポーネントの故障率は低下し続けたが、システムレベルの問題がより顕著になった。システム思考がますます重要になった。ソフトウェアについては、信頼性に対するより定性的なアプローチを提供するCMMモデル（能力成熟度モデル）が開発された。ISO 9000は、認証の設計および開発部分に信頼性の測定を追加した。
ワールドワイドウェブの拡大は、セキュリティと信頼性に関する新たな課題を生み出した。かつては信頼できる情報が不足していたという問題があったが、今や疑わしい情報が多すぎるという問題に取って代わられた。消費者の信頼性に関する問題は、データを用いてオンラインでリアルタイムに議論できるようになった。マイクロ電気機械システム（MEMS）、携帯型GPS、携帯電話とコンピュータを組み合わせた携帯端末といった新技術は、いずれも信頼性の維持という点で課題となっている。製品開発期間は10年間を通して短縮し続け、かつて3年かかっていたことが18ヶ月で完了するようになった。これは、信頼性ツールとタスクを開発プロセス自体にさらに密接に結びつける必要があったことを意味する。多くの点で、信頼性は日常生活や消費者の期待の一部となっている。
信頼性とは、製品が特定の動作条件下で顧客の期待を満たすかそれを上回る方法で意図された機能を果たす確率のことである。[ 10 ]
信頼性工学の目的は、優先順位の高い順に次のとおりです。[ 11 ]
優先的に重視する理由は、コストを最小限に抑え、信頼性の高い製品を生み出すという点で、これが最も効果的な作業方法だからです。したがって、求められる主要なスキルは、故障の可能性のある原因を理解し予測する能力と、故障を防止する方法に関する知識です。また、設計やデータを分析するために使用できる手法を知っていることも必要です。
「複雑系」の信頼性工学は、非複雑系とは異なる、より精緻なシステムアプローチを必要とする。その場合、信頼性工学には以下のような要素が含まれる可能性がある。
効果的な信頼性工学には、故障メカニズムの基本を理解する必要があり、そのためには経験、幅広い工学スキル、およびさまざまな専門分野の工学に関する十分な知識が必要となります。[ 12 ]例えば、
信頼性は、以下のように定義できる。
信頼性リスク評価では、信頼性ブロック図、ハザード分析、故障モード影響解析(FMEA) [ 13 ] 、フォールトツリー解析(FTA)、信頼性中心保全、(確率論的) 負荷および材料の応力と摩耗の計算、(確率論的) 疲労およびクリープ解析、ヒューマンエラー解析、製造欠陥解析、信頼性試験など、多くの工学的手法が用いられます。これらの解析は、効果を発揮するために、適切に、かつ細部にまで注意を払って行う必要があります。信頼性手法の数が多く、費用がかかり、状況によって求められる信頼性の度合いが異なるため、ほとんどのプロジェクトでは、特定のシステムに対して実行される信頼性タスク (作業範囲記述書(SoW) の要件) を規定する信頼性プログラム計画を作成します。
例えばARP4761に基づく安全ケースの作成と同様に、信頼性評価の目標は、コンポーネントまたはシステムの使用が許容できないリスクと関連しないことを示す、定性的および定量的な確固たる証拠を提供することです。取るべき基本的な手順[ 14 ]は次のとおりです。
ここでのリスクは、障害発生事象（シナリオ）の発生確率と深刻度の組み合わせです。深刻度は、システムの安全性または可用性の観点から評価できます。安全性のための信頼性は、システムの可用性のための信頼性とは全く異なる焦点であると考えることができます。可用性と安全性は、システムを過度に可用性の高い状態に保つことがかえって危険となる場合があるため、常に緊張関係にあります。エンジニアリングシステムを安全状態に急激に移行させると、誤報が発生し、システムの可用性が損なわれる可能性があります。
最小限の定義では、故障の深刻度には、スペアパーツのコスト、人件費、物流、損傷（二次的故障）、および生産損失を引き起こす可能性のある機械のダウンタイムが含まれます。故障のより完全な定義では、システム内の人々の負傷、切断、死亡（鉱山事故、産業事故、スペースシャトルの故障を参照）や、無関係な傍観者への同様の被害（ボパール、ラブキャナル、チェルノブイリ、仙台などの都市の市民、および2011年の東北地方太平洋沖地震と津波のその他の犠牲者を参照）も意味します。この場合、信頼性工学はシステムの安全性になります。何が許容されるかは、管理当局、顧客、または影響を受けるコミュニティによって決定されます。残留リスクは、すべての信頼性活動が終了した後に残るリスクであり、未確認のリスクが含まれるため、完全に定量化することはできません。
設計や材料の改良、計画的な点検、万全な設計、バックアップ冗長性といった技術システムの複雑化は、リスクを低減する一方でコストを増加させます。リスクは、ALARA（合理的に達成可能な限り低く）またはALAPA（実用的に達成可能な限り低く）レベルまで低減できます。
Implementing a reliability program is not simply a software purchase; it is not just a checklist of items that must be completed that ensure one has reliable products and processes. A reliability program is a complex learning and knowledge-based system unique to one's products and processes. It is supported by leadership, built on the skills that one develops within a team, integrated into business processes, and executed by following proven standard work practices.[15]
A reliability program plan is used to document exactly what "best practices" (tasks, methods, tools, analysis, and tests) are required for a particular (sub)system, as well as clarify customer requirements for reliability assessment. For large-scale complex systems, the reliability program plan should be a separate document. Resource determination for manpower and budgets for testing and other tasks is critical for a successful program. In general, the amount of work required for an effective program for complex systems is large.
A reliability program plan is essential for achieving high levels of reliability, testability, maintainability, and the resulting system availability, and is developed early during system development and refined over the system's life cycle. It specifies not only what the reliability engineer does, but also the tasks performed by other stakeholders. An effective reliability program plan must be approved by top program management, which is responsible for the allocation of sufficient resources for its implementation.
信頼性プログラム計画は、信頼性ではなくテスト容易性と保守性の向上に重点を置く戦略によって、システムの可用性を評価および改善するためにも使用できます。保守性の向上は、一般的に信頼性の向上よりも容易です。保守性の推定値（修理率）も一般的に精度が高くなります。しかし、信頼性の推定値の不確実性はほとんどの場合非常に大きいため、保守性のレベルが非常に高い場合でも、可用性の計算を支配する可能性が高くなります（予測の不確実性の問題）。信頼性が管理されていない場合、人員（保守担当者/顧客サービス能力）の不足、スペアパーツの入手可能性、物流の遅延、修理施設の不足、大規模な改修、複雑な構成管理コストなど、より複雑な問題が発生する可能性があります。信頼性の問題は、修理後の保守に起因する故障の「ドミノ効果」によっても悪化する可能性があります。したがって、保守性だけに焦点を当てるのは十分ではありません。故障が防止されれば、他の問題は重要ではなくなり、そのため信頼性は一般的に可用性の最も重要な部分とみなされます。信頼性は、スペアパーツのコスト、メンテナンスの工数、輸送コスト、保管コスト、部品の陳腐化リスクなどにより、可用性と総所有コスト(TCO) の両方に関連して評価および改善する必要があります。しかし、GM とトヨタが遅ればせながら発見したように、信頼性の計算が顧客の身体的リスクを十分に正確に考慮していない場合、TCO には下流の賠償責任コストも含まれます。多くの場合、この 2 つの間にはトレードオフが必要です。可用性と所有コストの間には最大比率が存在する可能性があります。システムのテスト可能性も計画で考慮する必要があります。これは信頼性と保守性の間のリンクだからです。保守戦略はシステムの信頼性に影響を与えることができます (たとえば、予防保守や予知保全など) が、固有の信頼性を超えることは決してできません。
信頼性計画には、可用性管理のための戦略を明確に盛り込む必要があります。可用性のみを重視するか、所有コストも重視するかは、システムの用途によって異なります。例えば、生産システムの重要なリンクとなるシステム（大規模な石油プラットフォームなど）は、たとえわずかな可用性の向上であっても、所有コストが非常に高くても許容されます。なぜなら、プラットフォームが利用不能になると、莫大な収益損失が発生し、その損失は所有コストを容易に上回ってしまう可能性があるからです。適切な信頼性計画では、常にRAMT分析を全体的な文脈で検討する必要があります。RAMTとは、顧客のニーズを踏まえた信頼性、可用性、保守性／メンテナンス性、およびテスト容易性を指します。
どのようなシステムにおいても、信頼性エンジニアリングの最初のタスクの 1 つは、全体的な可用性ニーズから割り当てられ、さらに重要なことに、適切な設計故障解析または予備プロトタイプテストの結果から導き出された信頼性および保守性要件を適切に指定することです。明確な要件 (設計可能なもの) は、設計者が特定の信頼性の低いアイテム / 構造 / インターフェース / システムを設計しないように制約する必要があります。可用性、信頼性、テスト容易性、または保守性の目標 (最大故障率など) だけを設定することは適切ではありません。これは、信頼性要件エンジニアリングに関する一般的な誤解です。信頼性要件は、テストおよび評価要件、関連するタスクおよびドキュメントを含め、システム自体を対象とします。信頼性要件は、適切なシステムまたはサブシステムの要件仕様、テスト計画、および契約書に含まれます。適切な下位レベルの要件の作成は重要です。[ 16 ]
定量的な最小目標値（例えば、平均故障間隔（MTBF）値や故障率）のみを提供するだけでは、さまざまな理由から不十分です。その理由の1つは、複雑なシステムの下位レベルにおける定量的な信頼性割り当て（要求仕様）の完全な検証（時間的な正確性と検証可能性に関連）が、（1）要求が確率的であること、（2）これらの確率的要求すべてへの適合性を示す際に極めて高いレベルの不確実性が伴うこと、そして（3）信頼性は時間の関数であり、アイテムごとの（確率的）信頼性数値の正確な推定値はプロジェクトのかなり後期、場合によっては長年の運用後になって初めて得られること、の結果として、（多くの場合）できないことです。この問題を、例えば航空機の開発における下位レベルのシステム質量要求の継続的な（再）バランス調整と比較してみてください。これはすでに多くの場合、大規模な事業です。この場合、質量はわずか数パーセントしか異ならず 、時間の関数ではなく、データは非確率的で、すでに CAD モデルで利用可能であることに注意してください。信頼性の場合、設計、プロセス、またはその他のもののごくわずかな逸脱の結果として、信頼性の低さ (故障率) のレベルが数十倍 (10 の倍数) で変化する可能性があります。[ 17 ]開発フェーズでは、情報が非常に不確実で入手できないことがよくあります。このため、この割り当て問題を、過剰仕様または過小仕様の大幅な発生を招かない有用で実用的かつ妥当な方法で実行することはほぼ不可能です。したがって、実用的なアプローチが必要です。たとえば、故障の影響の深刻度のみに依存する定量的要件の一般的なレベル/クラスの使用などです。また、結果の検証は、他のタイプの要件よりもはるかに主観的な作業です。(定量的)信頼性パラメータ (MTBF の観点から) は、あらゆる設計において最も不確実な設計パラメータです。
さらに、信頼性設計要件は、（システムまたは部品の）設計において、故障の発生を防止する機能、あるいは故障による影響をそもそも軽減する機能を組み込むよう促すものでなければなりません。これは予測に役立つだけでなく、エンジニアリングの取り組みが会計作業のようなものに逸れるのを防ぐことにもつながります。設計要件は、設計者が「設計」できるほど正確である必要があり、また、分析やテストを通じて、要件が達成されたことを、可能であれば、明示された信頼度の範囲内で証明できる必要があります。あらゆる種類の信頼性要件は詳細である必要があり、故障解析（有限要素応力・疲労解析、信頼性ハザード解析、FTA、FMEA、ヒューマンファクター解析、機能ハザード解析など）またはあらゆる種類の信頼性テストから導き出すことができます。また、検証テスト（必要な過負荷応力など）と必要なテスト時間に関する要件も必要です。これらの要件を効果的に導き出すには、システムエンジニアリングに基づくリスク評価と軽減ロジックを使用する必要があります。システムが故障する可能性のある理由と方法、あるいは実際に故障した方法に関する詳細な情報を含む、堅牢なハザードログシステムを構築する必要があります。要件はこのようにして導き出され、追跡される。これらの実用的な設計要件は設計を推進するものであり、検証目的のみに使用されるものではない。これらの要件（多くの場合、設計制約）は、このようにして故障解析または予備テストから導き出される。純粋に定量的（ロジスティック）な要件仕様（例：故障率／MTBF目標）との違いを理解することは、成功する（複雑な）システムの開発において極めて重要である。[ 18 ]
保守性要件は、修理費用と修理時間の両方を扱います。テスト容易性（テスト要件とは混同しないように）要件は、信頼性と保守性を結びつけるものであり、特定のシステムレベルでの故障モードの検出可能性、隔離レベル、および診断手順の作成について扱う必要があります。
As indicated above, reliability engineers should also address requirements for various reliability tasks and documentation during system development, testing, production, and operation. These requirements are generally specified in the contract statement of work and depend on how much leeway the customer wishes to provide to the contractor. Reliability tasks include various analyses, planning, and failure reporting. Task selection depends on the criticality of the system as well as cost. A safety-critical system may require a formal failure reporting and review process throughout development, whereas a non-critical system may rely on final test reports. The most common reliability program tasks are documented in reliability program standards, such as MIL-STD-785 and IEEE 1332. Failure reporting analysis and corrective action systems are a common approach for product/process reliability monitoring.
In practice, most failures can be traced back to some type of human error, for example in:
However, humans are also very good at detecting such failures, correcting them, and improvising when abnormal situations occur. Therefore, policies that completely rule out human actions in design and production processes to improve reliability may not be effective. Some tasks are better performed by humans and some are better performed by machines.[19]
Furthermore, human errors in management; the organization of data and information; or the misuse or abuse of items, may also contribute to unreliability. This is the core reason why high levels of reliability for complex systems can only be achieved by following a robust systems engineering process with proper planning and execution of the validation and verification tasks. This also includes the careful organization of data and information sharing and creating a "reliability culture", in the same way, that having a "safety culture" is paramount in the development of safety-critical systems.
Reliability prediction combines:
既存システムの場合、責任あるプログラムが発見された障害の根本原因を修正しようとすると、修正の効果に関する新たな仮定（それ自体も高い誤差レベルを伴う）を立てる必要があるため、当初のMTBF推定値が無効になる可能性があると主張できます。もう一つの実際的な問題は、詳細な障害データが一般的に入手困難であることであり、入手可能なデータも障害（フィードバック）データのフィルタリングが不整合であったり、統計誤差（信頼性関連の障害のような稀な事象では非常に高い）が無視されていることがよくあります。異なる種類の根本原因（製造、保守、輸送、システム起因、または固有の設計上の障害など）に関連する障害をカウントして比較するには、非常に明確なガイドラインが必要です。異なる種類の原因を比較すると、不正確な推定や、改善の焦点に関する誤ったビジネス上の意思決定につながる可能性があります。
システムの適切な定量的信頼性予測をテストによって行うのは困難で非常にコストがかかる場合があります。個々の部品レベルでは、利用可能なテスト予算で多数のサンプル部品をテストできるため、信頼性結果を比較的高い信頼度で得られることがよくあります。しかし、これらのテストは、部品レベルのテストで行われた仮定のために、システムレベルでは妥当性に欠ける可能性があります。これらの著者は、故障するまで部品レベルまたはシステムレベルでの初期テストの重要性を強調し、そのような故障から学び、システムまたは部品を改善することの重要性を強調しました。一般的な結論として、フィールドデータの比較またはテストのいずれによっても、信頼性の正確かつ絶対的な予測はほとんどの場合不可能です。疲労破壊などの摩耗問題による故障は例外となる可能性があります。MIL-STD-785の序文には、信頼性予測は、トレードオフ研究での比較のみに使用しない限り、非常に慎重に使用する必要があると書かれています。
信頼性設計（DfR）は、製品が使用環境下でその寿命期間にわたって信頼性要件を満たすことを保証するためのツールと手順を含むプロセスです。DfRは、製品の信頼性を積極的に向上させるために、製品の設計段階で実装されます。[ 21 ] DfRは、優れた設計（DfX）戦略全体の一部として使用されることがよくあります。
信頼性設計は、（システム）モデルの開発から始まります。信頼性および可用性モデルでは、ブロック図とフォールトツリー解析を用いて、システムの各部分間の関係をグラフィカルに評価します。これらのモデルには、過去のデータから得られた故障率に基づく予測が組み込まれる場合があります。入力データによる予測は絶対的な意味では必ずしも正確ではありませんが、設計案の相対的な違いを評価する上で有用です。例えば、平均修復時間（MTTR）などの保守性パラメータも、このようなモデルの入力として使用できます。
最も重要な根本的な原因と故障メカニズムは、工学的手法を用いて特定・分析する必要がある。設計者には、性能と信頼性に関する多様な実践的な指針を提供し、損傷や過度の摩耗から保護する、あるいはそれらから保護される低ストレス設計および製品を設計できるようにすべきである。信頼性「性能」の試験による検証に加え、入力負荷（要求事項）の適切な検証が必要となる場合もある。
One of the most important design techniques is redundancy. This means that if one part of the system fails, there is an alternate success path, such as a backup system. The reason why this is the ultimate design choice is related to the fact that high-confidence reliability evidence for new parts or systems is often not available, or is extremely expensive to obtain. By combining redundancy, together with a high level of failure monitoring, and the avoidance of common cause failures; even a system with relatively poor single-channel (part) reliability, can be made highly reliable at a system level (up to mission critical reliability). No testing of reliability has to be required for this. In conjunction with redundancy, the use of dissimilar designs or manufacturing processes (e.g. via different suppliers of similar parts) for single independent channels, can provide less sensitivity to quality issues (e.g. early childhood failures at a single supplier), allowing very-high levels of reliability to be achieved at all moments of the development cycle (from early life to long-term). Redundancy can also be applied in systems engineering by double checking requirements, data, designs, calculations, software, and tests to overcome systematic failures.
Another effective way to deal with reliability issues is to perform analysis that predicts degradation, enabling the prevention of unscheduled downtime events / failures. RCM (Reliability Centered Maintenance) programs can be used for this.
For electronic assemblies, there has been an increasing shift towards a different approach called physics of failure. This technique relies on understanding the physical static and dynamic failure mechanisms. It accounts for variation in load, strength, and stress that lead to failure with a high level of detail, made possible with the use of modern finite element method (FEM) software programs that can handle complex geometries and mechanisms such as creep, stress relaxation, fatigue, and probabilistic design (Monte Carlo Methods/DOE). The material or component can be re-designed to reduce the probability of failure and to make it more robust against such variations. Another common design technique is component derating: i.e. selecting components whose specifications significantly exceed the expected stress levels, such as using heavier gauge electrical wire than might normally be specified for the expected electric current.
Many of the tasks, techniques, and analyses used in Reliability Engineering are specific to particular industries and applications, but can commonly include:
これらの手法による結果は、部品またはシステムの設計およびロジスティクスのレビュー時に提示されます。信頼性は、複雑な部品またはシステムに対する多くの要件のうちの1つにすぎません。エンジニアリング上のトレードオフ分析は、信頼性要件とその他の制約との最適なバランスを決定するために使用されます。
信頼性エンジニアは、故障や危険を説明するために定量的または定性的な方法を使用する場合でも、リスクを特定し、問題を解決できるようにするために言語に頼ります。使用する言語は、機能/アイテム/システムとその複雑な周辺を、これらの機能/アイテム/システムの故障に関連して、秩序だった形で説明するのに役立つ必要があります。システムエンジニアリングは、問題（および関連するリスク）を説明する適切な言葉を見つけることに大きく関わっており、それによってエンジニアリングソリューションによって容易に解決できます。ジャック・リングは、システムエンジニアの仕事は「プロジェクトに言語を与えること」だと述べています。(Ring et al. 2000) [ 23 ]部品/システムの故障の場合、信頼性エンジニアは「いつ」を予測するよりも、「なぜ」と「どのように」に重点を置くべきです。故障が「なぜ」発生したか（たとえば、過負荷のかかったコンポーネントや製造上の問題による）を理解することは、故障が「いつ」発生する可能性が高いかを定量化すること（たとえば、MTBFを決定することによって）よりも、使用される設計とプロセスを改善する可能性がはるかに高くなります[ 4 ]。そのためには、まず部品／システムに関連する信頼性ハザードを分類し、順序付けする必要があります（可能であれば、何らかの定性的および定量的論理に基づいて）。これにより、より効率的な評価と最終的な改善が可能になります。これは、純粋な言語と命題論理によって部分的に行われますが、類似の項目に関する経験にも基づいています。これは、例えば、フォールトツリー分析、FMEA分析、およびハザード（追跡）ログにおける事象の説明に見られます。この意味で、言語と適切な文法（定性分析の一部）は、信頼性工学において重要な役割を果たします。これは、安全工学やシステム工学全般においても同様です。
言語の適切な使用は、多くの障害の根本原因となることが多い人的ミスのリスクを特定または軽減する上でも重要です。これには、システム障害につながる可能性のある体系的な人的ミスを防止するための、保守マニュアル、操作マニュアル、緊急手順書などの適切な指示が含まれます。これらは、訓練を受けた経験豊富な技術ライターが、いわゆる簡略化された英語または簡略化された技術英語を使用して作成する必要があります。簡略化された英語では、曖昧さや混乱のリスクを減らすために、単語と構造が意図的に選択され作成されます（たとえば、「古い部品を交換する」という表現は、摩耗した部品を摩耗していない部品と交換すること、またはより新しく、できれば改良された設計の部品に交換することのどちらを指すか曖昧になる可能性があります）。
信頼性モデリングとは、コンポーネントやシステムの実装前に、その信頼性を予測または理解するプロセスです。スペアパーツの供給、輸送、人員配置といった物流上の問題の影響を含め、システム全体の可用性挙動をモデル化するためによく用いられる分析手法として、フォールトツリー分析と信頼性ブロック図の2種類があります。コンポーネントレベルでは、これらの分析手法を他の手法と組み合わせて使用することも可能です。モデルへの入力データは、試験データ、過去の運用経験、現場データ、類似または関連業界のデータハンドブックなど、多くの情報源から得られます。情報源に関わらず、モデルへの入力データはすべて細心の注意を払って使用する必要があります。なぜなら、予測は同一の製品が同一の状況で使用された場合にのみ有効だからです。そのため、予測は多くの場合、代替案の比較に役立てる目的でのみ使用されます。
部品レベルの予測においては、一般的に2つの異なる調査分野が用いられます。
信頼性とは、デバイスが規定された条件下で一定期間内に意図された機能を果たす確率として定義されます。数学的には、これは次のように表すことができます。
、
どこは故障確率密度関数であり、は時間の長さ（時間ゼロから始まると仮定）です。
この定義にはいくつかの重要な要素があります。
多くの場合、構成要素の故障間の統計的依存関係に関する知識は不明であるか、部分的にしか制約されていない。このような不完全な知識をモデル化したい場合、信頼性理論は、特に小規模な多構成要素システムにおいて、固有の分布ではなく、システム故障確率の範囲や境界を特徴付ける分析を可能にする。
定量的要件は信頼性パラメータを使用して指定されます。最も一般的な信頼性パラメータは平均故障時間(MTTF) であり、これは故障率(頻度または条件付き確率密度関数 (PDF) として表現されます) または特定の期間内の故障数として指定することもできます。これらのパラメータは、上位システムレベルや頻繁に稼働するシステム (車両、機械、電子機器など) に役立つ場合があります。信頼性は MTTF が増加するにつれて向上します。MTTF は通常時間で指定されますが、マイルやサイクルなどの他の測定単位でも使用できます。下位システムレベルで MTTF 値を使用すると、特に関連する故障モードとメカニズム (MTTF の F) が指定されていない場合は、非常に誤解を招く可能性があります。[ 17 ]
場合によっては、信頼性は任務成功の確率として定義される。例えば、定期便の信頼性は、システム安全工学でよく用いられるように、無次元の確率またはパーセンテージで定義される。
任務成功の特殊なケースとして、単発式装置またはシステムが挙げられます。これらは比較的休眠状態にあり、一度しか作動しない装置またはシステムです。例としては、自動車のエアバッグ、熱電池、ミサイルなどがあります。単発式装置の信頼性は、一度の成功確率として規定されるか、関連するパラメータに包含されます。単発式ミサイルの信頼性は、命中確率の要件として規定される場合があります。このようなシステムの場合、要求時の故障確率（PFD）が信頼性の尺度となります。これは実際には「利用不可」の数値です。PFDは、修理不可能なシステムの場合、故障率（発生頻度）と任務時間から算出されます。
修理可能なシステムの場合、信頼性は故障率、平均修復時間（MTTR）、およびテスト間隔から求められます。この指標は要求の種類によって異なるため、特定のシステムに対して一意の値をとるとは限りません。システムレベルの要件に加えて、重要なサブシステムに対して信頼性要件が規定される場合があります。ほとんどの場合、信頼性パラメータは適切な統計的信頼区間とともに規定されます。
信頼性試験または信頼性検証の目的は、設計上の潜在的な問題をできるだけ早期に発見し、最終的にシステムが信頼性要件を満たしているという確信を与えることです。指定された耐用年数の間、想定される使用、輸送、保管などのすべての環境における製品の信頼性を考慮する必要があります。[ 10 ]これは、製品を自然または人工の環境条件にさらして動作させ、実際の使用、輸送、保管の環境条件下での製品の性能を評価し、環境要因の影響の程度とその作用機序を分析および研究することです。[ 24 ]さまざまな環境試験装置を使用して、高温、低温、高湿度、気候環境の温度変化をシミュレートし、使用環境における製品の反応を加速させ、研究開発、設計、製造で期待される品質に達しているかどうかを検証します。[ 25 ]
信頼性検証は信頼性試験とも呼ばれ、製品の寿命と期待される性能に基づいて製品の信頼性を評価するためにモデリング、統計、その他の方法を使用することを指します。[ 26 ]自動車、集積回路、天然資源の採掘に使用される重機、航空機の自動ソフトウェアなど、市場に出回っているほとんどの製品は信頼性試験を必要とします。 [ 27 ] [ 28 ]
信頼性テストは複数のレベルで実施でき、テストの種類も様々です。複雑なシステムは、コンポーネント、回路基板、ユニット、アセンブリ、サブシステム、システムレベルでテストできます。[ 29 ] （テストレベルの名称はアプリケーションによって異なります。）たとえば、部品や小型アセンブリなどの下位レベルで環境ストレススクリーニングテストを実行すると、上位レベルで故障が発生する前に問題を検出できます。テストは、統合の各レベルで、フルアップシステムテスト、開発テスト、運用テストを通じて進行し、プログラムのリスクを低減します。ただし、テストは信頼性リスクを軽減するものではありません。
各テストでは、サンプルサイズ、テスト時間、前提条件、および必要な識別率に応じて、統計的な第一種過誤と第二種過誤の両方が発生する可能性があります。優れた設計を誤って棄却するリスク（第一種過誤）と、劣悪な設計を誤って受け入れるリスク（第二種過誤）の両方が存在します。
すべてのシステム要件をテストすることは、必ずしも現実的ではありません。システムによってはテスト費用が莫大にかかる場合があり、故障モードによっては観測に何年もかかる場合があり、複雑な相互作用によって膨大な数のテストケースが発生する場合があり、また、テスト範囲やその他のリソースが限られている場合もあります。このような場合、加速寿命試験、実験計画法、シミュレーションなど、さまざまなテスト手法を用いることができます。
信頼性試験においては、求められる統計的信頼水準も重要な要素となります。統計的信頼水準は、試験時間または試験対象数を増やすことで向上します。信頼性試験計画は、最小限の試験対象数と試験時間で、指定された信頼水準において、指定された信頼性を達成するように設計されています。試験計画が異なれば、製造者と消費者にもたらされるリスクのレベルも異なります。双方の求める信頼性、統計的信頼水準、およびリスクレベルが、最終的な試験計画に影響を与えます。顧客と開発者は、信頼性要件をどのように試験するかについて、事前に合意しておく必要があります。
A key aspect of reliability testing is to define "failure". Although this may seem obvious, there are many situations where it is not clear whether a failure is really the fault of the system. Variations in test conditions, operator differences, weather and unexpected situations create differences between the customer and the system developer. One strategy to address this issue is to use a scoring conference process. A scoring conference includes representatives from the customer, the developer, the test organization, the reliability organization, and sometimes independent observers. The scoring conference process is defined in the statement of work. Each test case is considered by the group and "scored" as a success or failure. This scoring is the official result used by the reliability engineer.
As part of the requirements phase, the reliability engineer develops a test strategy with the customer. The test strategy makes trade-offs between the needs of the reliability organization, which wants as much data as possible, and constraints such as cost, schedule and available resources. Test plans and procedures are developed for each reliability test, and results are documented.
Reliability testing is common in the Photonics industry. Examples of reliability tests of lasers are life test and burn-in. These tests consist of the highly accelerated aging, under controlled conditions, of a group of lasers. The data collected from these life tests are used to predict laser life expectancy under the intended operating characteristics.[30]
There are many criteria to test depends on the product or process that are testing on, and mainly, there are five components that are most common:[31][32]
The product life span can be split into four different for analysis. Useful life is the estimated economic life of the product, which is defined as the time can be used before the cost of repair do not justify the continue use to the product. Warranty life is the product should perform the function within the specified time period. Design life is where during the design of the product, designer take into consideration on the life time of competitive product and customer desire and ensure that the product do not result in customer dissatisfaction.[34][35]
信頼性試験の要件は、故障確率、故障モード、または影響の最初の推定値を正当化する必要があるあらゆる分析から導き出される可能性があります。試験によって、ある程度の確信度で証拠を生成することができます。ソフトウェアベースのシステムでは、確率はソフトウェアとハードウェアの両方の故障の組み合わせになります。信頼性要件の試験は、いくつかの理由から問題があります。ほとんどの場合、単一の試験では十分な統計データを生成するには不十分です。複数の試験や長期間の試験は通常、非常に高価です。一部の試験は単純に非現実的であり、システムのライフサイクル全体にわたって環境条件を予測することは困難です。
信頼性工学は、システムが信頼性要件を満たしていることを示す実証的な証拠を提供する、現実的かつ費用対効果の高いテストプログラムを設計するために用いられます。こうした懸念事項の一部に対処するために、統計的信頼水準が使用されます。特定のパラメータは、対応する信頼水準とともに表現されます。例えば、MTBFが90%の信頼水準で1000時間であるといった具合です。この仕様に基づいて、信頼性エンジニアは、例えば、要件が満たされるか満たされないかの時間と故障回数に関する明確な基準を持つテストを設計することができます。様々な種類のテストが可能です。
要求される信頼性レベルと信頼度レベルの組み合わせは、開発コストと顧客および製造者双方のリスクに大きく影響します。費用対効果など、最適な要求事項の組み合わせを選択するには注意が必要です。信頼性試験は、コンポーネント、サブシステム、システムなど、さまざまなレベルで実施できます。また、試験および運用中は、極端な温度や湿度、衝撃、振動、その他の環境要因（信号、冷却、電力の喪失、火災、洪水、過度の熱、物理的またはセキュリティ上の違反、その他無数の損傷や劣化など）といった多くの要因に対処する必要があります。長期間稼働する必要のあるシステムの場合は、加速寿命試験が必要になる場合があります。
信頼性試験の体系的なアプローチは、まず信頼性目標を決定し、次に性能に関連する試験を実施して製品の信頼性を決定することです。[ 36 ]現代の産業における信頼性検証試験では、製品の全体的な信頼性性能との関連性、および個々の試験が保証コストと顧客満足度にどのような影響を与えるかを明確に決定する必要があります。[ 37 ]
The purpose of accelerated life testing (ALT test) is to induce field failure in the laboratory at a much faster rate by providing a harsher, but nonetheless representative, environment. In such a test, the product is expected to fail in the lab just as it would have failed in the field—but in much less time. The main objective of an accelerated test is either of the following:
An accelerated testing program can be broken down into the following steps:
Common ways to determine a life stress relationship are:
Software reliability is a special aspect of reliability engineering. It focuses on foundations and techniques to make software more reliable, i.e., resilient to faults. System reliability, by definition, includes all parts of the system, including hardware, software, supporting infrastructure (including critical external interfaces), operators and procedures. Traditionally, reliability engineering focuses on critical hardware parts of the system. Since the widespread use of digital integrated circuit technology, software has become an increasingly critical part of most electronics and, hence, nearly all present day systems. Therefore, software reliability has gained prominence within the field of system reliability.
There are significant differences, however, in how software and hardware behave. Most hardware unreliability is the result of a component or material failure that results in the system not performing its intended function. Repairing or replacing the hardware component restores the system to its original operating state. However, software does not fail in the same sense that hardware fails. Instead, software unreliability is the result of unanticipated results of software operations. Even relatively small software programs can have astronomically large combinations of inputs and states that are infeasible to exhaustively test. Restoring software to its original state only works until the same combination of inputs and states results in the same unintended result. Software reliability engineering must take this into account.
ソフトウェアとハードウェアでは障害の原因が異なるにもかかわらず、ソフトウェアで経験することを定量化するために、統計に基づいたいくつかのソフトウェア信頼性モデルが提案されています。ソフトウェアの実行期間が長くなるほど、最終的にテストされていない方法で使用され、障害につながる潜在的な欠陥を示す可能性が高くなります（Shooman 1987）、（Musa 2005）、（Denney 2005）。
ハードウェアと同様に、ソフトウェアの信頼性も、適切な要件定義、設計、実装に依存します。ソフトウェア信頼性エンジニアリングは、意図しない結果を予測し、それに対処するための規律あるソフトウェアエンジニアリングプロセスに大きく依存します。ソフトウェア品質エンジニアリングとソフトウェア信頼性エンジニアリングの間には、ハードウェアの品質と信頼性の間よりも多くの重複があります。優れたソフトウェア開発計画は、ソフトウェア信頼性プログラムの重要な要素です。ソフトウェア開発計画には、ソフトウェア開発中に使用する設計およびコーディング標準、ピアレビュー、単体テスト、構成管理、ソフトウェアメトリクス、ソフトウェアモデルが記述されます。
現代の分散システムやマイクロサービスベースのシステムでは、信頼性に関する考慮事項は、コンポーネントレベルの正確性にとどまらず、ビジネスロジックレベルでのアプリケーションの動作にまで及ぶことが増えています。従来のソフトウェア信頼性エンジニアリングやサイト信頼性エンジニアリング（SRE）は、可用性やレイテンシなどのシステムレベルの指標に焦点を当てていますが、一部の情報源や業界の実務家は、このアプリケーションに焦点を当てた視点をアプリケーション信頼性エンジニアリング（ARE）と呼んでいます。この視点では、エンドツーエンドのユーザー トランザクションとビジネス ワークフローの正確性を重視し、トランザクションの成功率、データの一貫性、複数の相互作用するサービス間でのワークフローの完了などの指標が含まれます。個々のシステム コンポーネントは正常に動作しているように見えても、サービス間の相互作用やロジック エラーによって障害が発生し、ユーザー エクスペリエンスの低下や誤った結果につながる可能性があるシナリオに対処します。
アプリケーションレベルの信頼性に関連する手法には、エンドツーエンドの可観測性、合成トランザクションテスト、およびビジネス上重要なプロセスの検証が含まれ、これらは従来のインフラストラクチャ中心の信頼性手法を補完するものです。
一般的な信頼性指標は、コード行数あたりのソフトウェア障害数（FLOC）であり、通常はコード1,000行あたりの障害数として表されます。この指標は、ソフトウェア実行時間とともに、ほとんどのソフトウェア信頼性モデルおよび推定において重要な要素です。理論的には、障害数（または障害密度）が減少するにつれてソフトウェアの信頼性は向上します。しかし、ソフトウェア障害がコード内でどのように分布しているか、その深刻度、および障害が発生するために必要な入力の組み合わせの確率のため、障害密度と平均故障間隔の間に直接的な関係を確立することは困難です。それでも、障害密度は信頼性エンジニアにとって有用な指標となります。複雑性などの他のソフトウェア指標も使用されます。この指標は、ソフトウェア開発および検証手法の変更が全体的な欠陥率に劇的な影響を与える可能性があるため、依然として議論の的となっています。
ソフトウェアテストは、ソフトウェアの信頼性において重要な側面です。最高のソフトウェア開発プロセスであっても、テストされるまでほとんど検出できないソフトウェアの欠陥が発生する可能性があります。ソフトウェアは、個々のユニットから始まり、統合テスト、そしてシステム全体のテストに至るまで、複数のレベルでテストされます。テストのすべての段階で、ソフトウェアの欠陥が発見され、修正され、再テストされます。信頼性の推定値は、欠陥密度やその他の指標に基づいて更新されます。システムレベルでは、平均故障間隔データを収集し、信頼性の推定に使用できます。ハードウェアとは異なり、まったく同じソフトウェア構成でまったく同じテストを実行しても、統計的な信頼性は向上しません。代わりに、ソフトウェアの信頼性には、コードカバレッジなどの異なる指標が使用されます。
ソフトウェアエンジニアリング研究所の能力成熟度モデルは、信頼性と品質の観点からソフトウェア開発プロセス全体を評価するための一般的な手段である。
構造信頼性、または構造物の信頼性とは、信頼性理論を構造物の挙動に適用することです。これは、コンクリート構造や鋼構造を含むさまざまな種類の構造物の設計と維持の両方で使用されます。[ 38 ] [ 39 ]構造信頼性の研究では、荷重と抵抗の両方が確率変数としてモデル化されます。このアプローチを使用して、構造物の故障確率が計算されます。
安全性の信頼性と可用性の信頼性は、しばしば密接に関連しています。エンジニアリングシステムの可用性が失われると、損失が発生します。地下鉄システムが利用できない場合、地下鉄運営会社はシステムが停止している時間ごとに損失を被ります。安全性が損なわれると、地下鉄運営会社はさらに多くの損失を被ります。信頼性の定義は、故障が発生しない確率と結びついています。故障は、安全性の喪失、可用性の喪失、またはその両方を引き起こす可能性があります。重要なシステムにおいて、安全性または可用性を失うことは望ましくありません。
信頼性工学は、責任を負う主体にとって経済的損失につながる可能性のある故障を全体的に最小限に抑えることを目的としているのに対し、安全工学は、一般的に人命の損失、負傷、または機器の損傷につながる可能性のある特定の種類の故障を最小限に抑えることに重点を置いている。
信頼性の危険は、例えば、システムの利用不能による生産の損失、スペアパーツに対する予想外の高低需要、修理費用、工数、再設計、または通常の生産の中断に関連する直接的および間接的なコストにより、企業または顧客の収益損失につながるインシデントに発展する可能性があります。[ 40 ]
安全工学は、多くの場合、非常に特殊で、特定の厳しく規制された産業、アプリケーション、または分野にのみ関連しています。主に、人命の損失、機器の破壊、環境被害などの重大な事故につながる可能性のあるシステム安全上の危険に焦点を当てています。そのため、関連するシステムの機能的信頼性要件は非常に高い場合が多いです。信頼性工学と同様に望ましくない故障を扱いますが、直接的なコストへの焦点は少なく、故障後の修復措置には関心がありません。もう1つの違いは、故障が社会に与える影響のレベルであり、政府または規制機関による厳格な管理の傾向につながります（たとえば、原子力、航空宇宙、防衛、鉄道、石油産業）。[ 40 ]
2oo2相互チェック冗長システムを使用することで安全性を高めることができます。部品レベルまたはシステムレベルで「1oo2」（1/2）冗長性を使用することで可用性を高めることができます。冗長要素が両方とも不一致の場合、より許容度の高い要素が可用性を最大化します。1oo2システムは安全性を確保する上で決して頼るべきではありません。フォールトトレラントシステムは、多くの場合、追加の冗長性（例：2oo3投票ロジック）に依存しており、複数の冗長要素が潜在的に危険な動作を実行する前に合意する必要があります。これにより、システムレベルで可用性と安全性の両方が向上します。これは、継続的な可用性が必要でフェイルセーフモードを持たない航空宇宙システムで一般的な手法です。たとえば、航空機は、飛行中に方向舵や補助翼などの操縦翼面に「安全な」デフォルト位置がないため、常に動作可能である必要があるため、飛行コンピュータと操縦翼面（場合によっては電気/機械/油圧など異なる動作モードを含む）に三重モジュール冗長性を使用することがあります。
上記の2oo3フォールトトレラントシステムの例では、ミッションの信頼性と安全性の両方が向上します。ただし、この場合のシステムの「基本」信頼性は、非冗長（1oo1）システムや2oo2システムよりも低くなります。基本信頼性エンジニアリングは、システム障害には至らないものの、保守修理作業、物流、スペアパーツなどによる追加コストが発生する可能性のあるすべての障害を対象としています。たとえば、2oo3投票システムで1つの故障したチャネルを交換または修理した場合（システムは動作し続けますが、1つのチャネルが故障しているため、実際には2oo2システムになっています）、基本信頼性は低下しますが、ミッション信頼性は低下しません。たとえば、航空機の尾灯が故障しても、飛行機の飛行は妨げられません（したがって、ミッションの失敗とはみなされません）が、修理する必要があり（関連コストが発生するため、基本信頼性レベルに寄与します）。
耐障害性（冗長性）システムや保護機能を備えたシステムを使用する場合、安全な運用やミッションの信頼性を確保するためには、故障の検出と共通原因故障の回避が極めて重要となる。
品質は保証期間中の製造上の欠陥に焦点を当てることが多い。信頼性は、製品またはエンジニアリングシステムの試運転から廃止までの全ライフサイクルにわたる故障の強度を調査する。シックスシグマは、製造品質の統計的管理にルーツを持つ。信頼性エンジニアリングは、システムエンジニアリングの専門分野である。システムエンジニアリングプロセスは、製造プロセスとは異なる発見プロセスであることが多い。製造プロセスは、最小限のコストと時間で高品質の成果物を達成する反復活動に焦点を当てることが多い。[ 41 ]
日常的に使われる「製品の品質」という用語は、その製品本来の卓越性の度合いを漠然と意味します。業界では、「使用開始時の要件または仕様への適合性」という、より正確な品質の定義が用いられます。最終製品仕様が元の要件と顧客/システムのニーズを適切に捉えていると仮定すると、品質レベルは、仕様を満たす出荷製品ユニットの割合として測定できます。[ 42 ]製造品の品質は、保証期間中の保証請求の件数に焦点を当てることがよくあります。
品質は、製品ライフサイクルの開始時点から保証期間までのスナップショットであり、下位レベルの製品仕様の管理に関連しています。これには、製造ミスが最終的な品質管理をすり抜けた、つまり時間ゼロの欠陥が含まれます。理論的には、品質レベルは、不良品の単一の割合で表すことができます。システムエンジニアリングの一部である信頼性は、長年にわたる故障率の継続的な評価として機能します。理論的には、すべてのアイテムは無限の期間にわたって故障します。[ 43 ]時間の経過とともに発生する欠陥は、信頼性フォールアウトと呼ばれます。信頼性フォールアウトを説明するには、時間の経過に伴うフォールアウトの割合を記述する確率モデルが必要です。これは、寿命分布モデルとして知られています。[ 42 ]これらの信頼性の問題の一部は、製品が仕様に適合していても存在する可能性のある、固有の設計上の問題に起因する可能性があります。完璧に製造されたアイテムでさえ、1つ以上の故障メカニズム（たとえば、人的ミス、機械的、電気的、化学的要因による）により、時間の経過とともに故障します。これらの信頼性の問題は、初期生産中の許容レベルの変動によっても影響を受ける可能性があります。
したがって、品質と信頼性は製造工程と密接に関係しています。信頼性は、軍事、航空、鉄道など、製品のライフサイクル全体を通して故障を重視する顧客層にとって特に重要です。製品仕様に適合しない製品は、一般的に信頼性（MTTFが低い）の面で劣りますが、必ずしもそうとは限りません。この複合的な関係を（統計モデルを用いて）完全に数学的に定量化することは、一般的に非常に困難、あるいは事実上不可能です。製造上のばらつきを効果的に低減できる場合、シックスシグマツールは、品質と信頼性を向上させる最適なプロセスソリューションを見つけるのに役立つことが示されています。シックスシグマはまた、エンジニアリングシステムや製造製品における製造上の欠陥や初期不良に対してより堅牢な製品を設計するのにも役立ちます。
シックスシグマとは対照的に、信頼性エンジニアリングのソリューションは、一般的に信頼性試験とシステム設計に焦点を当てることで見出されます。ソリューションは、さまざまな方法で見出されます。例えば、システムを簡素化して、関連する故障メカニズムをより深く理解できるようにする、材料の応力レベルを詳細に計算して適切な安全率を決定する、システム負荷の異常状態を特定し、それを利用して製造ばらつきに関連する故障メカニズムに対する設計の堅牢性を高める、といった方法です。さらに、信頼性エンジニアリングでは、可用性の高い状況に対応するために冗長性と耐障害性を備えたシステムを設計するなど、システムレベルのソリューションも活用します（上記の「信頼性エンジニアリングと安全エンジニアリング」を参照）。
注：シックスシグマ／品質に関する文献における「欠陥」は、信頼性における「故障」（現場での故障、例：破損した製品）とは異なります。シックスシグマ／品質における欠陥とは、一般的に要求事項（例：基本機能や重要な寸法）への不適合を指します。ただし、これらの要求事項がすべて満たされていても、製品は時間の経過とともに故障する可能性があります。品質は一般的に「要求事項は実際に正しいか？」という重要な問いを問うことには関心がありませんが、信頼性はまさにその問いに関心があります。
システムや部品の製造が始まると、信頼性エンジニアリングは欠陥の監視、評価、修正を試みます。監視には、フォールトツリー解析設計段階で特定された重要なパラメータの電子監視と視覚監視が含まれます。データ収集はシステムの性質に大きく依存します。ほとんどの大企業には、車両、機器、機械の故障データを収集する品質管理グループがあります。消費者向け製品の故障は、返品数で追跡されることがよくあります。休眠状態または待機状態のシステムについては、ランダムサンプルを検査およびテストするための正式な監視プログラムを確立する必要があります。フィールドアップグレードやリコール修理など、システムへの変更には、変更の信頼性を確保するために追加の信頼性テストが必要です。特定のシステム、特に人的要素を含むシステムのすべての故障モードを予測することは不可能であるため、故障は発生します。信頼性プログラムには、効果的な是正措置を実施できるように、故障に関係する因果関係を特定する体系的な根本原因分析も含まれます。可能な限り、システムの故障と是正措置は信頼性エンジニアリング組織に報告されます。
信頼性運用評価に適用される最も一般的な方法の一つに、故障報告・分析・是正措置システム（FRACAS）があります。この体系的なアプローチでは、故障／インシデントの報告、管理、分析、および是正／予防措置に基づいて、信頼性、安全性、およびロジスティクスに関する評価を行います。現在、多くの組織がこの方法を採用し、商用システム（WebベースのFRACASアプリケーションなど）を利用して、故障／インシデントデータのリポジトリを作成し、そこから統計情報を抽出して、正確かつ信頼性の高い信頼性、安全性、および品質指標を把握しています。
組織にとって、すべての最終製品に共通のFRACASシステムを採用することは極めて重要です。また、試験結果を実用的な方法で記録できるシステムであるべきです。現場エンジニアや修理工場エンジニアにとってデータ入力が容易で、かつ保守が容易な統合システムを採用できない場合、FRACASプログラム自体が失敗に終わる可能性が高くなります。
FRACASシステムからの一般的な出力には、現場MTBF、MTTR、スペアパーツ消費量、信頼性向上、故障/インシデントの種類別、場所別、部品番号別、シリアル番号別、症状別の分布などが含まれます。
過去のデータを用いて新しい同等のシステム／製品の信頼性を予測することは、誤解を招く可能性がある。なぜなら、信頼性は使用状況によって左右され、設計／製造におけるわずかな変更によっても影響を受けるからである。
ある程度の複雑さを持つシステムは、営利企業や政府機関といった組織によって開発されます。信頼性エンジニアリング組織は、企業の組織構造と整合していなければなりません。小規模で重要度の低いシステムの場合、信頼性エンジニアリングは非公式なもので構いません。しかし、システムの複雑さが増すにつれて、正式な信頼性機能の必要性が生じます。顧客にとって信頼性は重要であるため、顧客が信頼性組織の特定の側面を指定することもあります。
信頼性組織にはいくつかの一般的なタイプがあります。プロジェクトマネージャーやチーフエンジニアが、1人または複数の信頼性エンジニアを直接雇用する場合があります。大規模な組織では、通常、製品保証組織または専門エンジニアリング組織があり、信頼性、保守性、品質、安全性、ヒューマンファクター、ロジスティクスなどを担当します。このような場合、信頼性エンジニアは製品保証マネージャーまたは専門エンジニアリングマネージャーに報告します。
場合によっては、企業は独立した信頼性組織を設立したいと考えるかもしれません。これは、多くの場合、費用と時間がかかるシステム信頼性が、予算やスケジュールの制約によって不当に軽視されないようにするために望ましいことです。このような場合、信頼性エンジニアはプロジェクトに日々携わりますが、実際には社内の別の組織に雇用され、給与が支払われます。
信頼性エンジニアリングはシステム設計の初期段階において非常に重要であるため、組織の構造に関わらず、信頼性エンジニアが統合された製品チームの一員として働くことが一般的になっている。
信頼性工学の大学院学位を提供している大学もあります。その他の信頼性専門家は通常、大学またはカレッジのプログラムで工学、統計学、数学、または物理学の学位を取得しています。多くの工学プログラムでは信頼性に関するコースを提供しており、一部の大学には信頼性工学のプログラム全体があります。信頼性エンジニアは、州または地方自治体の法律により専門技術者として登録する必要がありますが、すべての信頼性専門家がエンジニアであるとは限りません。公共の安全が危険にさらされているシステムでは、信頼性エンジニアが必要です。信頼性エンジニア向けの専門会議や業界トレーニングプログラムが多数あります。信頼性エンジニア向けの専門組織はいくつかあり、米国品質協会信頼性部門（ASQ-RD）[ 44 ] 、 IEEE信頼性協会、米国品質協会（ASQ）[ 45 ]、および信頼性エンジニア協会（SRE）[ 46 ]などがあります。
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）{{cite journal}}: CS1 maint: 複数の名前: 著者リスト (リンク)http://standards.sae.org/ja1000/1_199903/ SAE JA1000/1 信頼性プログラム規格実施ガイド
英国では、英国国防省の支援の下、防衛規格として維持されている、より最新の規格が存在する。関連する規格は以下のとおりである。
DEF STAN 00-40 信頼性および保守性（R&M）
DEF STAN 00-42 信頼性および保守性保証ガイド
DEF STAN 00-43 信頼性および保守性保証活動
DEF STAN 00-44 信頼性および保守性データの収集と分類
DEF STAN 00-45 第1版：信頼性中心保全
DEF STAN 00-49 第1版：信頼性および保守性に関する改訂版 用語定義ガイド
これらはDSTANから入手できます。また、SAE、MSG、ARP、IEEなど多くの組織が作成した商用規格も多数存在します。
ウィキメディア・コモンズにある信頼性工学関連のメディア