信頼性工学

信頼性工学は、機器が故障することなく機能する能力を重視するシステム工学のサブ分野です。信頼性は、製品、システム、またはサービスが指定された期間、意図された機能を適切に実行する確率、または定義された環境で故障することなく動作する確率として定義されます。^[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 は、その頃に作成されました。この頃、軍事ハンドブック 217 の前身として広く使用されていた規格もRCAによって発行され、電子部品の故障率の予測に使用されました。コンポーネントの信頼性と実証研究 (例: Mil Std 217) のみに重点を置くことは徐々に減少しました。消費者業界で使用されているような、より実用的なアプローチが使用されるようになりました。1980 年代には、テレビはますます固体半導体で作られるようになりました。自動車では、ボンネットの下やダッシュボードにさまざまなマイクロコンピューターが搭載され、半導体の使用が急速に増加しました。大型の空調システムでは電子コントローラーが開発され、電子レンジやその他のさまざまな家電製品も同様でした。通信システムでは、古い機械式スイッチング システムを置き換えるために電子技術が採用され始めました。Bellcoreは通信用の最初の消費者予測方法論を発行し、SAE は自動車用途向けに同様の文書 SAE870050 を開発しました。予測の性質はこの10年間で進化し、ダイの複雑さが集積回路（IC）の故障率を決定する唯一の要因ではないことが明らかになりました。Kam Wongはバスタブ曲線に疑問を投げかける論文を発表しました^{[9] —}信頼性中心のメンテナンスも参照。この10年間で、多くのコンポーネントの故障率は10分の1に低下しました。ソフトウェアはシステムの信頼性にとって重要になりました。1990年代までには、IC開発のペースが加速しました。スタンドアロンのマイクロコンピュータの幅広い使用が一般的になり、PC市場はIC密度がムーアの法則に従って約18か月ごとに倍増し続けるのに貢献しました。信頼性エンジニアリングは、故障の物理的性質を理解する方向に進み、変化しました。コンポーネントの故障率は低下し続けましたが、システムレベルの問題がより顕著になりました。システム思考がますます重要になりました。ソフトウェアについては、信頼性に対してより定性的なアプローチを提供するCMMモデル（能力成熟度モデル）が開発されました。ISO 9000では、認証の設計および開発部分の一部として信頼性の尺度が追加されました。ワールドワイドウェブの拡大により、セキュリティと信頼性に関する新たな課題が生まれました。信頼できる情報が少なすぎるという従来の問題は、価値に疑問のある情報が多すぎるという問題に取って代わられました。消費者の信頼性の問題は、データを使用してオンラインでリアルタイムに議論できるようになりました。マイクロエレクトロメカニカルシステム（MEMS）、ハンドヘルドGPSなどの新しいテクノロジー、携帯電話とコンピュータを組み合わせたハンドヘルド デバイスはすべて、信頼性の維持に課題を抱えています。製品開発期間はこの 10 年間短縮され続け、3 年かかっていた作業が 18 か月で完了するようになりました。つまり、信頼性ツールとタスクを開発プロセス自体とより密接に結び付ける必要がありました。多くの点で、信頼性は日常生活と消費者の期待の一部になっています。

信頼性とは、製品が指定された動作条件下で、顧客の期待を満たすかそれを上回る方法で意図された機能を実行する確率です。^[10]

信頼性工学の目的は、優先順位の高い順に以下の通りである。^[11]

1. エンジニアリングの知識と専門技術を適用して、障害の可能性や頻度を防止または低減します。
2. 障害を予防するための努力にもかかわらず発生した障害の原因を特定し、修正すること。
3. 障害の原因が修正されていない場合に、障害が発生した場合の対処方法を決定します。
4. 新しい設計の信頼性を推定し、信頼性データを分析するための方法を適用します。

優先的に強調する理由は、コストを最小限に抑え、信頼性の高い製品を生み出すという点で、これが最も効果的な作業方法だからです。したがって、必要な主なスキルは、障害の考えられる原因を理解して予測する能力と、障害を防ぐ方法に関する知識です。また、設計とデータを分析するために使用できる方法を知ることも必要です。

「複雑なシステム」の信頼性エンジニアリングには、複雑でないシステムの場合とは異なる、より精巧なシステム アプローチが必要です。その場合、信頼性エンジニアリングには次のものが含まれます。

• システムの可用性とミッション準備の分析および関連する信頼性と保守要件の割り当て
• 機能システム障害分析と派生要件仕様
• ハードウェアとソフトウェアの両方の設計に対する固有の（システム）設計信頼性分析と派生要件仕様
• システム診断設計
• フォールトトレラントシステム（例：冗長性による）
• 予測的および予防的メンテナンス（例：信頼性中心のメンテナンス）
• ヒューマンファクター / ヒューマンインタラクション / ヒューマンエラー
• 製造および組み立てに起因する故障（検出された「0 時間品質」と信頼性への影響）
• メンテナンスによる故障
• 輸送に起因する障害
• ストレージに起因する障害
• 使用（負荷）調査、コンポーネントの応力解析、および派生要件仕様
• ソフトウェア（システム）障害
• 故障/信頼性テスト（および派生要件）
• 現場での障害監視と是正措置
• スペアパーツ在庫（在庫管理）
• 技術文書、注意および警告の分析
• データと情報の収集/整理（一般的な信頼性開発ハザードログとFRACASシステムの作成）
• カオスエンジニアリング

効果的な信頼性工学には、故障メカニズムの基礎を理解する必要があり、そのためには経験、幅広いエンジニアリングスキル、そして多くの異なる専門分野のエンジニアリングに関する優れた知識が求められる。^[12]例えば、

• トライボロジー
• ストレス（力学）
• 破壊力学/疲労
• 熱工学
• 流体力学/衝撃荷重工学
• 電気工学
• 化学工学（例：腐食）
• 材料科学

信頼性は次のように定義されます。

• ある品物が目的に適しているという考え
• 設計、製造、または保守されたアイテムが要求通りに機能する能力
• 設計、製造、保守された品目の集団が要求通りに機能する能力
• アイテムの故障に対する耐性
• 指定された条件下でアイテムが必要な機能を実行する確率
• 物体の耐久性

信頼性リスク評価では、信頼性ブロック図、ハザード分析、故障モード影響解析（FMEA）^{[13] 、} 故障木解析（FTA）、信頼性中心保全、（確率論的）荷重および材料の応力と摩耗の計算、（確率論的）疲労およびクリープ解析、人為的エラー解析、製造欠陥解析、信頼性テストなど、多くの工学的手法が使用されています。これらの解析は、効果を上げるためには、適切に、細部にまで注意を払って行う必要があります。信頼性手法の数が多く、費用もかかり、さまざまな状況で求められる信頼性のレベルも異なるため、ほとんどのプロジェクトでは、特定のシステムに対して実行される信頼性タスク（作業指示書（SoW）の要件）を指定するための信頼性プログラム計画を作成します。

ARP4761などの安全性ケースの作成と一致して、信頼性評価の目標は、コンポーネントまたはシステムの使用が許容できないリスクに関連しないという定性的および定量的な証拠の堅牢なセットを提供することです。基本的な手順は次のとおりです ^{[14] 。}

• 特定の分析またはテストによって、潜在的な条件、イベント、人為的エラー、障害モード、相互作用、障害メカニズム、根本原因など、関連する信頼性の低い「危険」を徹底的に特定します。
• 特定の分析またはテストによって、関連するシステム リスクを評価します。
• リスクを軽減し、許容できるレベルで制御できるような、要件、設計変更、検出ロジック、メンテナンス、トレーニングなどの緩和策を提案します。
• 最善の緩和策を決定し、コスト/利益分析に基づいて最終的な許容可能なリスク レベルについて合意を得ます。

ここでのリスクは、障害インシデント (シナリオ) が発生する確率と重大度の組み合わせです。重大度は、システムの安全性またはシステムの可用性の観点から見ることができます。安全性に対する信頼性は、システムの可用性に対する信頼性とはまったく異なる焦点として考えることができます。可用性と安全性は、システムの可用性を高く保ちすぎると安全でなくなる可能性があるため、動的な緊張関係にある場合があります。エンジニアリング システムをあまりにも早く安全な状態にすると、システムの可用性を妨げる誤報が発生する可能性があります。

最小限の定義では、故障の重大性には、スペアパーツのコスト、工数、物流、損害（二次故障）、および生産損失の原因となる可能性のある機械のダウンタイムが含まれます。故障のより完全な定義は、システム内の人々の負傷、四肢切断、および死亡（鉱山事故、産業事故、スペースシャトルの故障を参照）や、罪のない傍観者の同様の負傷、四肢切断、および死亡（ボパール、ラブキャナル、チェルノブイリ、仙台などの都市の住民、および 2011 年の東北地方太平洋沖地震と津波のその他の被害者を参照）を意味することもあります。この場合、信頼性エンジニアリングはシステム安全性になります。何が許容されるかは、管理当局、顧客、または影響を受けたコミュニティによって決定されます。残留リスクは、すべての信頼性活動が終了した後に残るリスクであり、未確認のリスクが含まれます。したがって、完全に定量化することはできません。

設計や材料の改善、計画的な検査、確実な設計、バックアップの冗長性などの技術システムの複雑さにより、リスクは減少し、コストは増加します。リスクは、ALARA (合理的に達成可能な限り低い) または ALAPA (実際に達成可能な限り低い) レベルまで低減できます。

信頼性プログラムの導入は、単にソフトウェアを購入することではありません。また、信頼性の高い製品とプロセスを確保するために完了しなければならない項目のチェックリストでもありません。信頼性プログラムは、製品とプロセスに固有の複雑な学習および知識ベースのシステムです。これはリーダーシップによってサポートされ、チーム内で開発されたスキルに基づいて構築され、ビジネスプロセスに統合され、実証済みの標準的な作業慣行に従って実行されます。^[15]

信頼性プログラム計画は、特定の (サブ) システムに必要な「ベスト プラクティス」(タスク、方法、ツール、分析、テスト) を正確に文書化するとともに、信頼性評価に関する顧客の要件を明確にするために使用されます。大規模で複雑なシステムの場合、信頼性プログラム計画は別の文書にする必要があります。テストやその他のタスクの人員と予算のリソース決定は、プログラムの成功にとって重要です。一般に、複雑なシステムの効果的なプログラムに必要な作業量は膨大です。

信頼性プログラム計画は、高いレベルの信頼性、テスト可能性、保守可能性、および結果としてのシステム可用性を実現するために不可欠であり、システム開発の早い段階で作成され、システムのライフサイクルを通じて改良されます。信頼性プログラム計画では、信頼性エンジニアの作業だけでなく、他の利害関係者が実行するタスクも指定されます。効果的な信頼性プログラム計画は、その実施に十分なリソースを割り当てる責任を負うトッププログラム管理者の承認を得る必要があります。

信頼性プログラム計画は、信頼性ではなくテスト可能性と保守性の向上に重点を置く戦略によって、システムの可用性を評価および改善するためにも使用できます。保守性の向上は、信頼性の向上よりも一般的に簡単です。保守性の見積もり (修理率) も一般的に正確です。ただし、信頼性の見積もりの​​不確実性はほとんどの場合非常に大きいため、保守性レベルが非常に高い場合でも、可用性の計算 (予測の不確実性の問題) に影響を与える可能性があります。信頼性が制御されていない場合、人材 (保守担当者/顧客サービス能力) 不足、スペアパーツの入手性、ロジスティックの遅延、修理施設の不足、大規模な改修と複雑な構成管理コストなど、より複雑な問題が発生する可能性があります。修理後の保守による障害の「ドミノ効果」によっても、信頼性の問題が悪化する可能性があります。したがって、保守性のみに焦点を当てるだけでは十分ではありません。障害が防止されれば、他の問題はどれも重要ではなくなるため、信頼性は一般に可用性の最も重要な部分と見なされます。信頼性は、スペアパーツのコスト、メンテナンス工数、輸送コスト、保管コスト、部品の陳腐化リスクなどにより、可用性と総所有コスト(TCO) の両方に関連して評価および改善する必要があります。しかし、GM とトヨタが遅ればせながら気付いたように、信頼性の計算で顧客の身体的リスクが十分にまたは正確に考慮されていない場合、TCO には下流の賠償責任コストも含まれます。多くの場合、この 2 つの間でトレードオフが必要になります。可用性と所有コストには最大比率がある場合があります。システムのテスト可能性も、信頼性と保守性をつなぐものであるため、計画で対処する必要があります。保守戦略は、システムの信頼性に影響を与える可能性があります (予防保守や予測保守など) が、システムの信頼性を本来の信頼性以上に高めることはできません。

信頼性計画では、可用性の制御戦略を明確に示す必要があります。可用性だけが重要か、所有コストも重要かは、システムの使用状況によって異なります。たとえば、生産システムの重要なリンクであるシステム (大型石油プラットフォームなど) は、所有コストが可用性のわずかな向上につながる場合でも、通常は非常に高い所有コストが許容されます。プラットフォームが利用できなくなると、高い所有コストをはるかに上回る収益の大幅な損失につながるからです。適切な信頼性計画では、常に RAMT 分析を全体的なコンテキストで取り上げる必要があります。RAMT は、顧客のニーズのコンテキストにおける信頼性、可用性、保守性/メンテナンス、テスト可能性を表します。

どのようなシステムでも、信頼性エンジニアリングの最初のタスクの 1 つは、全体的な可用性のニーズから割り当てられ、さらに重要なことに、適切な設計障害分析または予備的なプロトタイプ テスト結果から導き出された信頼性と保守性の要件を適切に指定することです。明確な要件 (設計可能な要件) は、設計者が特定の信頼性の低いアイテム/構造/インターフェイス/システムを設計することを制限する必要があります。可用性、信頼性、テスト可能性、または保守性の目標 (最大障害率など) のみを設定することは適切ではありません。これは、信頼性要件エンジニアリングに関する大きな誤解です。信頼性要件は、テストと評価の要件、および関連するタスクとドキュメントを含むシステム自体を対象としています。信頼性要件は、適切なシステムまたはサブシステムの要件仕様、テスト計画、および契約書に含まれています。適切な下位レベルの要件を作成することが重要です。^{[16]定量的な最小目標 (}平均故障間隔(MTBF) 値または障害率など) のみを提供するだけでは、さまざまな理由で十分ではありません。理由の 1 つは、複雑なシステムの下位レベルでの定量的な信頼性の割り当て (要件仕様) の完全な検証 (時間内での正確性と検証可能性に関連) が (多くの場合) できないことです。その理由は、(1) 要件が確率的であるという事実、(2) これらすべての確率的要件への準拠を示すには極めて高いレベルの不確実性が伴う、(3) 信頼性は時間の関数であり、アイテムごとの (確率的) 信頼性数値の正確な推定値はプロジェクトのかなり後になって初めて、場合によっては何年も運用した後でしか利用できないからです。この問題を、たとえば航空機の開発における下位レベルのシステムの質量要件の継続的な (再) バランス調整 (これはすでに大規模な取り組みであることが多い) と比べてみてください。この場合、質量はわずか数パーセントしか異ならず、時間の関数ではなく、データは非確率的であり、CAD モデルですでに利用できることに注意してください。信頼性の場合、設計、プロセス、その他のわずかな偏差の結果として、信頼性の低さのレベル（故障率）は数十年（10の倍数）の係数で変化する可能性があります。^[17]開発段階では、多くの場合、大きな不確実性がなければ、この情報を入手できません。このため、この割り当て問題を、大幅な過剰または不足仕様を招かない、有用で実用的かつ有効な方法で行うことはほぼ不可能です。したがって、実用的なアプローチが必要です。たとえば、障害の影響の重大度のみに応じた定量的要件の一般的なレベル/クラスの使用などです。また、結果の検証は、他の種類の要件よりもはるかに主観的な作業です。(定量的)信頼性パラメータ (MTBF の観点から) は、あらゆる設計において、はるかに不確実な設計パラメータです。

さらに、信頼性設計要件は、故障の発生を防ぐ、またはそもそも故障による影響を制限する機能を組み込むように (システムまたは部品の) 設計を推進する必要があります。これは、予測に役立つだけでなく、エンジニアリングの取り組みが一種の会計作業に気を取られないようにします。設計要件は、設計者が「それに合わせて」設計し、分析またはテストを通じて、要件が達成されたことを証明できるほど正確である必要があります。可能であれば、一定の確信度内で達成できます。信頼性要件は、どのようなタイプでも詳細に記述する必要があり、故障解析 (有限要素応力および疲労解析、信頼性ハザード解析、FTA、FMEA、ヒューマン ファクター解析、機能ハザード解析など) またはあらゆる種類の信頼性テストから導き出すことができます。また、検証テスト (必要な過負荷応力など) と必要なテスト時間に関する要件も必要です。これらの要件を効果的に導き出すには、システム エンジニアリングベースのリスク評価および軽減ロジックを使用する必要があります。システムが故障する可能性がある理由と方法についての詳細な情報を含む、堅牢なハザード ログ システムを作成する必要があります。要件はこのようにして導き出され、追跡される。これらの実用的な設計要件は設計を推進するもので、検証目的のみに使用されるものではない。これらの要件（多くの場合、設計上の制約）は、このようにして故障解析や予備テストから導き出される。純粋に定量的（ロジスティック）な要件仕様（例えば、故障率/MTBF目標）のみと比較したこの違いを理解することは、成功する（複雑な）システムの開発において最も重要である。^[18]

保守性要件は、修理のコストと修理時間に対応します。テスト可能性 (テスト要件と混同しないでください) 要件は、信頼性と保守性の間のリンクを提供し、障害モードの検出可能性 (特定のシステム レベル)、分離レベル、および診断 (手順) の作成に対応する必要があります。前述のように、信頼性エンジニアは、システムの開発、テスト、製造、および運用中のさまざまな信頼性タスクとドキュメントの要件にも対応する必要があります。これらの要件は通常、契約の作業明細書で指定され、顧客が請負業者にどの程度の余裕を与えるかによって異なります。信頼性タスクには、さまざまな分析、計画、および障害報告が含まれます。タスクの選択は、システムの重要度とコストによって異なります。安全性が重要なシステムでは、開発全体を通じて正式な障害報告とレビュー プロセスが必要になる場合がありますが、重要でないシステムでは最終的なテスト レポートに依存する場合があります。最も一般的な信頼性プログラム タスクは、MIL-STD-785 や IEEE 1332 などの信頼性プログラム標準に文書化されています。障害報告分析と是正措置システムは、製品/プロセスの信頼性監視の一般的なアプローチです。

実際には、ほとんどの失敗は、次のような何らかの人為的エラーに起因します。

• 経営上の意思決定（例：予算、タイミング、必要なタスクなど）
• システムエンジニアリング: 使用研究 (負荷ケース)
• システムエンジニアリング：要件分析/設定
• システムエンジニアリング: 構成管理
• 仮定
• 計算 / シミュレーション / FEM解析
• デザイン
• 設計図
• テスト（例：不適切な負荷設定や故障測定）
• 統計分析
• 製造業
• 品質管理
• メンテナンス
• メンテナンスマニュアル
• トレーニング
• 情報の分類と整理
• フィールド情報のフィードバック（例：不正確または曖昧すぎる）
• 等

しかし、人間はそのような障害を検出し、修正し、異常な状況が発生したときに即興で対応する能力も非常に優れています。したがって、信頼性を向上させるために設計および製造プロセスで人間の行動を完全に排除するポリシーは効果的ではない可能性があります。一部のタスクは人間が実行した方が適しており、一部のタスクは機械が実行した方が適しています。^[19]

さらに、管理における人為的ミス、データと情報の整理、アイテムの誤用や乱用も、信頼性の低下につながる可能性があります。これが、複雑なシステムで高いレベルの信頼性を実現するには、適切な計画と検証および検証タスクの実行を伴う堅牢なシステム エンジニアリングプロセスに従う必要がある主な理由です。これには、データと情報の共有を慎重に整理し、「信頼性文化」を創出することも含まれます。同様に、「安全文化」を持つことは、安全性が重要なシステムの開発において最も重要です。

信頼性予測は以下を組み合わせます:

• 適切な信頼性モデルの作成（このページの続きを参照）
• このモデルの入力パラメータの推定（および正当化）（例：特定の故障モードまたはイベントの故障率、特定の故障に対するシステムの修復にかかる平均時間）
• システムまたは部品レベルでの出力信頼性パラメータの推定（つまり、システムの可用性または特定の機能障害の頻度） 定量化と目標設定（例：MTBF）を重視すると、達成可能な信頼性に限界があるように思われるかもしれませんが、本質的な限界はなく、より高い信頼性の開発にコストがかかる必要はありません。 さらに、彼ら^{[誰？ ]}は、履歴データからの信頼性の予測は非常に誤解を招く可能性があり、比較は同一の設計、製品、製造プロセス、および同一の動作負荷と使用環境でのメンテナンスにのみ有効であると主張しています。これらのいずれかに小さな変更があっても、信頼性に大きな影響を与える可能性があります。 さらに、最も信頼性が低く重要な項目（つまり、信頼性調査の最も興味深い候補）は、履歴データが収集されてから変更および再設計される可能性が高く、医療業界や保険業界などで使用されている標準的な（リアクティブまたはプロアクティブ）統計的方法とプロセスの有効性が低下します。 もう1つの驚くべき（しかし論理的な）議論は、テストによって信頼性を正確に予測できるようにするには、障害の正確なメカニズムを知っておく必要があり、したがってほとんどの場合は防止できるということです。複雑な信頼性工学の問題を、MTBFや確率の観点から定量化して解決しようとする誤ったルートをたどる場合、誤ったアプローチ（例えば、リアクティブアプローチ）を使用することを、バーナードは「数字ゲームをプレイする」と呼び、悪い習慣とみなしています。^[20]

既存のシステムの場合、責任あるプログラムが発見された障害の根本原因を修正しようとすると、この修正の効果について新しい仮定（それ自体が大きな誤差レベルにさらされる）を立てる必要があるため、当初の MTBF 見積りが無効になる可能性があると言えます。もう 1 つの実際的な問題は、詳細な障害データが一般に入手できないことです。入手できるデータでも、障害（フィードバック）データのフィルタリングが一貫していなかったり、統計誤差（信頼性関連の障害などのまれなイベントでは非常に高い）が無視されていることがよくあります。異なるタイプの根本原因（製造、保守、輸送、システムに起因する、または固有の設計上の障害など）に関連する障害をカウントして比較するには、非常に明確なガイドラインが必要です。異なるタイプの原因を比較すると、見積もりが不正確になったり、改善の焦点についてビジネス上の決定が不正確になったりする可能性があります。

システムの信頼性の適切な定量的予測をテストで行うのは困難で、非常に費用がかかる可能性があります。個々の部品レベルでは、利用可能なテスト予算を使用して多くのサンプル部品をテストできる可能性があるため、信頼性の結果は比較的高い信頼性で得られることがよくあります。ただし、残念ながら、部品レベルのテストで行われた仮定のため、これらのテストはシステムレベルでは有効性に欠ける場合があります。これらの著者は、故障するまで部品レベルまたはシステムレベルの初期テストの重要性と、そのような故障からシステムまたは部品を改善することの重要性を強調しました。一般的な結論は、信頼性の正確で絶対的な予測 (フィールドデータの比較またはテストのいずれかによる) はほとんどの場合不可能であるということです。例外は、疲労破損などの摩耗の問題による故障です。MIL-STD-785 の序文では、トレードオフ研究での比較のみに使用するのでない限り、信頼性の予測は細心の注意を払って使用する必要があると書かれています。

信頼性設計（DfR）は、製品がその使用環境下で、その寿命期間中、信頼性要件を満たすことを保証するためのツールと手順を含むプロセスです。DfRは、製品の信頼性を積極的に向上させるために、製品の設計段階で実装されます。^{[21] DfRは、全体的な}卓越性設計（DfX）戦略の一部として使用されることがよくあります。

信頼性設計は、(システム)モデルの開発から始まります。信頼性および可用性モデルでは、ブロック図とフォールト ツリー解析を使用して、システムのさまざまな部分間の関係をグラフィカルに評価します。これらのモデルには、履歴データから取得した故障率に基づく予測が組み込まれている場合があります。(入力データの) 予測は絶対的な意味では正確ではないことがよくありますが、設計代替案の相対的な違いを評価するのに役立ちます。平均修復時間(MTTR) などの保守性パラメータも、このようなモデルの入力として使用できます。

最も重要な基本的な原因と故障メカニズムは、エンジニアリング ツールで特定および分析する必要があります。設計者には、損傷や過度の摩耗を防ぐ、または損傷や過度の摩耗から保護される、ストレスの少ない設計や製品を生み出すことができるように、パフォーマンスと信頼性に関するさまざまな実用的なガイダンスを提供する必要があります。テストによる信頼性の「パフォーマンス」の検証に加えて、入力負荷 (要件) の適切な検証が必要になる場合があります。

最も重要な設計手法の 1 つは冗長性です。これは、システムの一部に障害が発生した場合でも、バックアップ システムなどの代替の成功パスがあることを意味します。これが究極の設計選択である理由は、新しい部品やシステムに対する信頼性の高い信頼性の証拠が入手できないか、入手するのに非常に費用がかかるという事実に関係しています。冗長性と、高レベルの障害監視、共通原因障害の回避を組み合わせることで、単一チャネル (部品) の信頼性が比較的低いシステムであっても、システム レベルでの信頼性を高くすることができます (ミッション クリティカルな信頼性まで)。このために信頼性のテストは必要ありません。冗長性と併せて、単一の独立したチャネルに異なる設計または製造プロセス (類似部品の異なるサプライヤー経由など) を使用すると、品質の問題 (単一サプライヤーでの初期障害など) に対する感度が低くなり、開発サイクルのあらゆる時点 (初期から長期まで) で非常に高いレベルの信頼性を実現できます。冗長性は、システム エンジニアリングでも適用でき、要件、データ、設計、計算、ソフトウェア、テストを二重チェックして、体系的な障害を克服します。

信頼性の問題に対処するもう 1 つの効果的な方法は、劣化を予測する分析を実行し、予定外のダウンタイム イベントや障害を防止できるようにすることです。これには、 RCM (信頼性中心メンテナンス) プログラムを使用できます。

電子アセンブリでは、故障物理学と呼ばれる異なるアプローチへの移行が進んでいます。この手法は、物理的な静的および動的故障メカニズムを理解することに依存しています。この手法では、故障につながる負荷、強度、応力の変動を非常に詳細に考慮します。これは、クリープ、応力緩和、疲労、確率的設計 (モンテカルロ法/DOE) などの複雑な形状やメカニズムを処理できる最新の有限要素法(FEM) ソフトウェア プログラムの使用によって可能になりました。材料またはコンポーネントを再設計して、故障の可能性を減らし、そのような変動に対してより堅牢にすることができます。もう 1 つの一般的な設計手法は、コンポーネントのディレーティングです。これは、予想される電流に対して通常指定されるよりも太い電線を使用するなど、仕様が予想される応力レベルを大幅に超えるコンポーネントを選択することです。

信頼性エンジニアリングで使用されるタスク、テクニック、分析の多くは、特定の業界やアプリケーションに固有のものですが、一般的には次のようなものが含まれます。

• 破壊の物理学(PoF)
• 組み込みセルフテスト（BIT または BIST）（テスト可能性分析）
• 故障モード影響解析(FMEA)
• 信頼性ハザード分析
• 信頼性ブロック図分析
• 動的信頼性ブロック図分析^[22]
• フォールトツリー分析
• 根本原因分析
• 統計工学、実験計画法（シミュレーション/FEMモデルまたはテストなど）
• スニークサーキット解析
• 加速テスト
• 信頼性成長分析（リアクティブ信頼性）
• ワイブル分析（テストまたは主に「反応型」信頼性用）
• ハイパータバスティック生存モデル
• 有限要素解析（FEA）および/または測定による熱解析
• FEAおよび/または測定による熱誘起、衝撃、振動疲労解析
• 電磁気解析
• 単一障害点（SPOF）の回避
• 機能分析および機能障害分析（例：機能FMEA、FHA、FFA）
• 予測的および予防的メンテナンス:信頼性中心メンテナンス (RCM) 分析
• テスト可能性分析
• 故障診断分析（通常はFMEAにも組み込まれます）
• ヒューマンエラー分析
• 運用上の危険分析
• 予防的/計画的メンテナンス最適化 (PMO)
• 手動スクリーニング
• 統合物流サポート

これらの方法による結果は、部品やシステムの設計、ロジスティクスのレビュー中に提示されます。信頼性は、複雑な部品やシステムに対する多くの要件の 1 つにすぎません。エンジニアリングのトレードオフ研究は、信頼性要件とその他の制約との間の 最適なバランスを決定するために使用されます。

信頼性エンジニアは、故障や危険を説明するために定量的または定性的な方法を使用するかどうかにかかわらず、言語を利用してリスクを特定し、問題を解決します。使用する言語は、機能/アイテム/システムとその複雑な周囲の状況がこれらの機能/アイテム/システムの故障に関連しているという観点から、秩序立った説明を作成するのに役立つ必要があります。システム エンジニアリングでは、問題 (および関連するリスク) を説明する正しい言葉を見つけて、エンジニアリング ソリューションで簡単に解決できるようにすることが非常に重要です。ジャック リングは、システム エンジニアの仕事は「プロジェクトを言語化すること」であると述べています (Ring 他 2000) ^[23]部品/システムの故障の場合、信頼性エンジニアは「いつ」を予測するよりも、「なぜ」と「どのように」に集中する必要があります。故障が「なぜ」発生したか (たとえば、コンポーネントの過度のストレスや製造上の問題による) を理解することは、故障が「いつ」発生する可能性があるかを定量化する (たとえば、MTBF を決定する) よりも、設計とプロセスの改善につながる可能性がはるかに高くなります^[4]。これを実行するには、まず部品/システムに関連する信頼性ハザードを分類して順序付けし（可能であれば何らかの定性的および定量的ロジックに基づいて）、より効率的な評価と最終的な改善を可能にする必要があります。これは部分的には純粋な言語と命題ロジックで行われますが、類似のアイテムに関する経験に基づいても行われます。これは、たとえば、フォールトツリー解析、FMEA解析、ハザード（追跡）ログのイベントの説明に見られます。この意味で、言語と適切な文法（定性分析の一部）は、安全工学やシステム工学全般と同様に、信頼性工学でも重要な役割を果たします。

言語の正しい使用は、多くの障害の根本原因となることが多いヒューマンエラーのリスクを特定または軽減するための鍵となることもあります。これには、システム障害につながる可能性のある体系的なヒューマンエラーを防ぐための、保守マニュアル、操作マニュアル、緊急手順などにおける適切な指示が含まれます。これらは、訓練を受けたまたは経験豊富な技術著者が、いわゆる簡略化された英語または簡略化された技術英語を使用して作成する必要があります。簡略化された英語では、言葉と構造が明確に選択され、あいまいさや混乱のリスクを減らすように作成されています (たとえば、「古い部品を交換する」は、摩耗した部品を摩耗していない部品と交換すること、またはより新しい、できれば改善された設計の部品と交換することをあいまいに指す可能性があります)。

信頼性モデリングは、コンポーネントまたはシステムの実装前にその信頼性を予測または理解するプロセスです。スペアパーツのプロビジョニング、輸送、人員などの物流問題の影響を含む完全なシステムの可用性の動作をモデル化するためによく使用される 2 種類の分析は、フォールト ツリー分析と信頼性ブロック図です。コンポーネント レベルでは、同じ種類の分析を他の分析と組み合わせて使用​​できます。モデルの入力は、テスト、以前の運用経験、フィールド データ、類似または関連業界のデータ ハンドブックなど、多くのソースから取得できます。ソースに関係なく、すべてのモデル入力データは細心の注意を払って使用する必要があります。予測は同じ製品が同じコンテキストで使用された場合にのみ有効であるためです。そのため、予測は多くの場合、代替案の比較にのみ使用されます。

部品レベルの予測では、次の 2 つの別々の調査分野が一般的です。

• 破壊の物理学的アプローチでは、機械的な亀裂の伝播や化学腐食による劣化や破壊など、関連する物理的な破壊メカニズムを理解します。
• 部品応力モデリングアプローチは、システムのコンポーネントの数と種類、および動作中にコンポーネントが受ける応力に基づいて予測を行う経験的な方法です。

信頼性は、指定された条件下で指定された期間内にデバイスが意図された機能を実行する 確率として定義されます。数学的には、次のように表現できます。

$${\displaystyle R(t)=Pr\{T>t\}=\int _{t}^{\infty }f(x)\,dx\ \!}$$、

ここで、は故障確率密度関数であり、は期間の長さです（時間ゼロから始まると仮定します）。 ${\displaystyle f(x)\!}$${\displaystyle t}$

この定義にはいくつかの重要な要素があります。

1. 信頼性は「意図された機能」を前提としています。一般的に、これは故障のない動作を意味します。ただし、システムの個々の部分に故障がなくても、システム全体が意図したとおりに動作しない場合は、システムの信頼性に問題が生じます。システム要件仕様は、信頼性を測定する基準です。
2. 信頼性は、指定された期間に適用されます。実際的には、システムが時間内に故障することなく動作する特定の可能性を持っていることを意味します。信頼性エンジニアリングは、指定された時間内にコンポーネントと材料が要件を満たすことを保証します。時間以外の単位が使用される場合があることに注意してください (例:「ミッション」、「動作サイクル」)。${\displaystyle T\!}$
3. 信頼性は、規定された（または明示的に定義された）条件下での動作に制限されます。無制限の条件でシステムを設計することは不可能であるため、この制約は必要です。火星探査車には、家庭用車とは異なる特定の条件があります。設計とテストの際には、動作環境に対処する必要があります。同じ探査車でも、追加の精査を必要とするさまざまな条件で動作することが求められる場合があります。
4. 信頼性理論とその数学的および統計的基礎に関する注目すべき参考文献としては、Barlow, RE と Proschan, F. (1982) および Samaniego, FJ (2007) の 2 つがあります。

定量的な要件は、信頼性パラメータを使用して指定されます。最も一般的な信頼性パラメータは平均故障時間(MTTF) ですが、これは故障率(これは頻度または条件付き確率密度関数 (PDF) として表されます) または一定期間内の故障数として指定することもできます。これらのパラメータは、上位システム レベルや頻繁に操作されるシステム (車両、機械、電子機器など) に役立ちます。信頼性は MTTF が増加するほど増加します。MTTF は通常時間で指定されますが、マイルやサイクルなどの他の測定単位を使用することもできます。下位システム レベルで MTTF 値を使用すると、特に関連する故障モードとメカニズム (MTTF の F) が指定されていない場合は、非常に誤解を招く可能性があります。^[17]

その他の場合、信頼性はミッションの成功確率として指定されます。たとえば、航空機の定期飛行の信頼性は、システム安全工学でよく使用される無次元確率またはパーセンテージとして指定できます。

ミッション成功の特殊なケースは、単発のデバイスまたはシステムです。これらは、比較的休止状態のままで、一度だけ動作するデバイスまたはシステムです。例としては、自動車のエアバッグ、熱電池、ミサイルなどがあります。単発の信頼性は、1 回限りの成功の確率として指定されるか、または関連パラメータに組み込まれます。単発ミサイルの信頼性は、命中確率の要件として指定される場合があります。このようなシステムの場合、要求時故障確率(PFD) が信頼性の尺度です。これは実際には「使用不可」の数値です。PFD は、修理不可能なシステムの故障率 (発生頻度) とミッション時間から算出されます。

修理可能なシステムの場合、信頼性は故障率、平均修理時間 (MTTR)、およびテスト間隔から得られます。この尺度は需要の種類によって異なるため、特定のシステムに対して一意ではない場合があります。システム レベルの要件に加えて、重要なサブシステムに対して信頼性要件が指定されることがあります。ほとんどの場合、信頼性パラメータは適切な統計的信頼区間とともに指定されます。

信頼性試験または信頼性検証の目的は、設計上の潜在的な問題をできるだけ早く発見し、最終的にシステムが信頼性要件を満たしていることに自信を持たせることです。指定された寿命期間中の予想される使用、輸送、保管など、あらゆる環境における製品の信頼性を考慮する必要があります。^[10]製品を自然または人工の環境条件にさらしてその作用を受けさせることで、実際の使用、輸送、保管の環境条件下での製品の性能を評価し、環境要因の影響度とそれらの作用メカニズムを分析および研究します。^[24]さまざまな環境試験装置を使用して、気候環境の高温、低温、高湿度、温度変化をシミュレートし、使用環境での製品の反応を加速して、研究開発、設計、製造において期待される品質に達するかどうかを検証します。^[25]

信頼性検証は信頼性テストとも呼ばれ、モデリング、統計、その他の方法を使用して、製品の寿命と予想される性能に基づいて製品の信頼性を評価することを指します。^[26]市場に出回っているほとんどの製品には信頼性テストが必要です。たとえば、自動車、集積回路、天然資源の採掘に使用される重機、航空機の自動ソフトウェアなどです。^{[27] [28]}

信頼性テストはいくつかのレベルで実行され、さまざまな種類のテストがあります。複雑なシステムは、コンポーネント、回路基板、ユニット、アセンブリ、サブシステム、システムのレベルでテストされる可能性があります。^[29] （テストレベルの命名法はアプリケーションによって異なります）。たとえば、部品や小さなアセンブリなどの低いレベルで環境ストレススクリーニングテストを実行すると、問題が上位レベルで障害を引き起こす前に検出されます。テストは、フルアップシステムテスト、開発テスト、運用テストを通じて各統合レベルで進められ、プログラムリスクを軽減します。ただし、テストによって信頼性リスクが軽減されるわけではありません。

各テストでは、サンプル サイズ、テスト時間、仮定、必要な判別率に応じて、統計的なタイプ I とタイプ II の両方のエラーが発生する可能性があります。適切な設計を誤って拒否するリスク (タイプ I エラー) と、不適切な設計を誤って受け入れるリスク (タイプ II エラー) があります。

すべてのシステム要件をテストすることが常に実行可能であるとは限りません。システムによっては、テストに法外な費用がかかるもの、観察に何年もかかるもの、複雑な相互作用によって膨大な数のテストケースが発生するもの、限られたテスト範囲やその他のリソースの使用を必要とするテストなどがあります。このような場合、(高度に)加速された寿命テスト、実験計画法、シミュレーションなど、さまざまなテスト手法を使用できます。

信頼性テストでは、望ましい統計的信頼性のレベルも重要な役割を果たします。統計的信頼性は、テスト時間またはテスト対象項目の数を増やすことで高まります。信頼性テスト計画は、最小のテスト ユニット数とテスト時間で、指定された信頼性を指定された信頼性レベルで達成するように設計されています。テスト計画が異なると、生産者と消費者に対するリスクのレベルも異なります。それぞれの側で望ましい信頼性、統計的信頼性、およびリスク レベルが、最終的なテスト計画に影響します。顧客と開発者は、信頼性要件のテスト方法について事前に合意する必要があります。

信頼性テストの重要な側面は、「障害」を定義することです。これは明らかなように思われるかもしれませんが、障害が本当にシステムのせいであるかどうかが明確でない状況は数多くあります。テスト条件の変動、オペレータの違い、天候、予期しない状況により、顧客とシステム開発者の間に相違が生じます。この問題に対処する 1 つの戦略は、スコアリング会議プロセスを使用することです。スコアリング会議には、顧客、開発者、テスト組織、信頼性組織、および場合によっては独立したオブザーバーの代表者が参加します。スコアリング会議プロセスは、作業明細書で定義されます。各テスト ケースはグループによって検討され、成功または失敗として「スコアリング」されます。このスコアリングは、信頼性エンジニアが使用する公式の結果です。

要件フェーズの一環として、信頼性エンジニアは顧客とともにテスト戦略を策定します。テスト戦略では、できるだけ多くのデータを求める信頼性組織のニーズと、コスト、スケジュール、利用可能なリソースなどの制約との間でトレードオフを行います。信頼性テストごとにテスト計画と手順が策定され、結果が文書化されます。

信頼性試験はフォトニクス業界では一般的です。レーザーの信頼性試験の例としては、寿命試験とバーンインがあります。これらの試験は、制御された条件下で、一連のレーザーの非常に加速された老化試験で構成されています。これらの寿命試験から収集されたデータは、意図された動作特性の下でのレーザーの寿命を予測するために使用されます。^[30]

テストする製品やプロセスに応じてテストする基準は多数ありますが、主に最も一般的なものは5つあります。^{[31] [32]}

1. 製品寿命
2. 意図された機能
3. 動作条件
4. パフォーマンスの確率
5. ユーザーの例外^[33]

製品寿命は、分析のために4つの異なる期間に分けることができます。耐用年数は、製品の推定経済的寿命であり、修理費用が製品の継続使用を正当化しなくなる前に使用できる時間として定義されます。保証期間とは、製品が指定された期間内に機能を実行する必要がある期間です。設計寿命とは、製品の設計中に、設計者が競合製品の寿命と顧客の要望を考慮し、製品が顧客の不満を招かないようにすることです。^{[34] [35]}

信頼性テスト要件は、故障確率、故障モード、または影響の最初の推定を正当化する必要がある分析から生じます。テストによって、ある程度の信頼性で証拠を生成できます。ソフトウェアベースのシステムの場合、確率はソフトウェアベースの故障とハードウェアベースの故障が混在します。信頼性要件のテストは、いくつかの理由で問題があります。ほとんどの場合、1 回のテストでは十分な統計データを生成するのに不十分です。複数のテストや長時間のテストは通常​​、非常に高価です。一部のテストは単に非現実的であり、システムのライフサイクル全体にわたって環境条件を予測することは困難です。

信頼性エンジニアリングは、システムが信頼性要件を満たしていることを実証的に証明する現実的で手頃なテスト プログラムを設計するために使用されます。統計的信頼レベルは、これらの懸念の一部に対処するために使用されます。特定のパラメーターは、対応する信頼レベルとともに表現されます。たとえば、 90% の信頼レベルで 1000 時間のMTBF などです。この仕様から、信頼性エンジニアは、たとえば、要件が満たされるか満たされなくなるまでの時間数と障害回数に関する明確な基準を持つテストを設計できます。さまざまな種類のテストが可能です。

要求される信頼性レベルと要求される信頼度レベルの組み合わせは、開発コストと、顧客と製造者の両方に対するリスクに大きく影響します。費用対効果など、要件の最適な組み合わせを選択するには注意が必要です。信頼性テストは、コンポーネント、サブシステム、システムなど、さまざまなレベルで実行できます。また、テスト中および動作中に、極端な温度や湿度、衝撃、振動、その他の環境要因 (信号、冷却、電源の喪失、または火災、洪水、過度の熱、物理的またはセキュリティ違反、その他のさまざまな損傷や劣化などの大惨事など) など、多くの要因に対処する必要があります。何年も使用する必要があるシステムの場合、加速寿命テストが必要になることがあります。

信頼性試験への体系的なアプローチは、まず信頼性の目標を決定し、次に性能に関連する試験を実施して製品の信頼性を判断することです。^[36]現代の産業における信頼性検証試験では、製品の全体的な信頼性性能とどのように関連しているか、個々の試験が保証コストと顧客満足度にどのように影響するかを明確に判断する必要があります。^[37]

加速寿命試験 (ALT テスト)の目的は、より過酷ではあるものの、実際の使用環境に近い環境を提供することで、実験室でより速い速度で現場での故障を誘発することです。このようなテストでは、製品は現場で故障した場合と同じように実験室でも故障することが予想されますが、その時間ははるかに短くなります。加速テストの主な目的は、次のいずれかです。

• 故障モードを発見する
• 高ストレスの実験室寿命から通常のフィールド寿命を予測する

加速テスト プログラムは、次の手順に分けられます。

• テストの目的と範囲を定義する
• 製品に関する必要な情報を収集する
• ストレスを特定する
• ストレスのレベルを判断する
• 加速テストを実施し、収集したデータを分析します。

生活ストレスの関係を判断する一般的な方法は次のとおりです。

• アレニウスモデル
• アイリングモデル
• 逆べき乗法則モデル
• 温度湿度モデル
• 温度非熱モデル

ソフトウェアの信頼性は、信頼性工学の特別な側面です。ソフトウェアの信頼性を高める、つまり障害に強いものにするための基礎と技術に焦点を当てています。システムの信頼性には、定義上、ハードウェア、ソフトウェア、サポート インフラストラクチャ (重要な外部インターフェイスを含む)、オペレーター、および手順など、システムのすべての部分が含まれます。従来、信頼性工学はシステムの重要なハードウェア部分に焦点を当てています。デジタル集積回路技術が広く使用されるようになって以来、ソフトウェアはほとんどの電子機器、したがってほぼすべての今日のシステムでますます重要な部分になっています。そのため、ソフトウェアの信頼性は、システムの信頼性の分野で注目を集めています。

ただし、ソフトウェアとハ​​ードウェアの動作には大きな違いがあります。ハードウェアの信頼性の低さは、ほとんどの場合、コンポーネントまたは材料の故障が原因で、システムが意図した機能を実行できないことが原因です。ハードウェア コンポーネントを修理または交換すると、システムは元の動作状態に戻ります。ただし、ソフトウェアはハードウェアと同じ意味で故障するわけではありません。ソフトウェアの信頼性の低さは、ソフトウェア操作の予期しない結果が原因です。比較的小さなソフトウェア プログラムでも、入力と状態の組み合わせが膨大になり、徹底的にテストすることが不可能になる場合があります。ソフトウェアを元の状態に復元できるのは、同じ入力と状態の組み合わせで同じ意図しない結果が発生するまでです。ソフトウェア信頼性エンジニアリングでは、この点を考慮する必要があります。

ソフトウェアとハ​​ードウェアの障害の原因にはこのような違いがあるにもかかわらず、ソフトウェアで経験することを定量化するために、統計に基づくソフトウェア信頼性モデルがいくつか提案されています。ソフトウェアの実行期間が長くなるほど、最終的にテストされていない方法で使用され、障害につながる潜在的な欠陥が発生する可能性が高くなります (Shooman 1987)、(Musa 2005)、(Denney 2005)。

ハードウェアと同様に、ソフトウェアの信頼性は、適切な要件、設計、実装に依存します。ソフトウェア信頼性エンジニアリングは、意図しない結果を予測して設計するための、規律あるソフトウェア エンジニアリングプロセスに大きく依存しています。ソフトウェア品質エンジニアリングとソフトウェア信頼性エンジニアリングの間には、ハードウェア品質と信頼性の間よりも多くの重複があります。適切なソフトウェア開発計画は、ソフトウェア信頼性プログラムの重要な側面です。ソフトウェア開発計画には、ソフトウェア開発中に使用される 設計およびコーディング標準、ピア レビュー、単体テスト、構成管理、ソフトウェア メトリック、ソフトウェア モデルが記載されています。

一般的な信頼性の指標は、コード行あたりのソフトウェア障害の数 (FLOC) で、通常はコード 1,000 行あたりの障害数として表されます。この指標は、ソフトウェア実行時間とともに、ほとんどのソフトウェア信頼性モデルおよび推定値の鍵となります。理論上は、障害の数 (または障害密度) が減少するにつれて、ソフトウェアの信頼性は向上します。ただし、コード内でのソフトウェア障害の分布方法、その重大度、および障害の発生に必要な入力の組み合わせの確率のため、障害密度と平均故障間隔を直接結び付けることは困難です。それでも、障害密度は信頼性エンジニアにとって有用な指標となります。複雑さなどの他のソフトウェア指標も使用されます。ソフトウェア開発および検証方法の変更は、全体的な欠陥率に劇的な影響を与える可能性があるため、この指標は依然として議論の的となっています。

ソフトウェア テストは、ソフトウェアの信頼性の重要な側面です。最高のソフトウェア開発プロセスであっても、テストされるまでほとんど検出できないソフトウェア障害がいくつか発生します。ソフトウェアは、個々のユニットから統合、完全なシステム テストまで、いくつかのレベルでテストされます。テストのすべてのフェーズで、ソフトウェア障害が発見され、修正され、再テストされます。信頼性の推定は、障害密度やその他の指標に基づいて更新されます。システム レベルでは、平均故障間隔データを収集し、信頼性の推定に使用できます。ハードウェアとは異なり、まったく同じソフトウェア構成でまったく同じテストを実行しても、統計的な信頼性は向上しません。代わりに、ソフトウェアの信頼性では、コード カバレッジなどの異なる指標が使用されます。

ソフトウェア エンジニアリング インスティテュートの能力成熟度モデルは、信頼性と品質を目的としてソフトウェア開発プロセス全体を評価するための一般的な手段です。

構造信頼性または構造物の信頼性は、信頼性理論を構造物の挙動に応用したものです。これは、コンクリート構造物や鉄骨構造物を含むさまざまな種類の構造物の設計と保守の両方に使用されます。^{[38] [39]}構造信頼性研究では、荷重と抵抗の両方が確率変数としてモデル化されます。このアプローチを使用して、構造物の破損確率が計算されます。

安全性に対する信頼性と可用性に対する信頼性は、多くの場合、密接に関連しています。エンジニアリング システムの可用性が失われると、コストがかかる可能性があります。地下鉄システムが利用できない場合、地下鉄の運営者はシステムが停止している時間ごとに損失を被ります。安全性が損なわれると、地下鉄の運営者はさらに損失を被ります。信頼性の定義は、障害が発生しない確率と結びついています。障害は、安全性の損失、可用性の損失、またはその両方を引き起こす可能性があります。重要なシステムで安全性または可用性が失われることは望ましくありません。

信頼性工学は、責任主体に経済的損失をもたらす可能性のある障害を全体的に最小限に抑えることに関係していますが、安全工学は、一般的に人命の損失、負傷、または機器の損傷につながる可能性のある特定の障害の種類を最小限に抑えることに重点を置いています。

信頼性ハザードは、例えば、システムが利用できないことによる生産の損失、スペアパーツの予想外の高需要または低需要、修理コスト、工数、再設計または通常生産の中断などに関連する直接的および間接的なコストにより、企業または顧客の収益損失につながるインシデントに変わる可能性があります。^[40]

安全工学は、多くの場合、非常に特殊で、厳しく規制されている特定の産業、アプリケーション、または領域にのみ関連しています。主に、人命の損失、機器の破壊、環境破壊など、重大な事故につながる可能性のあるシステムの安全性の危険に焦点を当てています。そのため、関連するシステム機能の信頼性要件は、非常に高いことがよくあります。信頼性工学と同じ意味で望ましくない障害を扱いますが、直接的なコストにはあまり重点を置いておらず、障害後の修復措置には関係していません。もう1つの違いは、障害が社会に与える影響のレベルであり、政府または規制機関（原子力、航空宇宙、防衛、鉄道、石油産業など）による厳格な管理の傾向があります。^[40]

安全性は、2oo2 クロスチェック冗長システムを使用して向上できます。可用性は、部品またはシステム レベルで「1oo2」(2 分の 1) 冗長性を使用することで向上できます。両方の冗長要素が一致しない場合は、より許容度の高い要素が可用性を最大化します。安全性については、1oo2 システムに頼るべきではありません。フォールト トレラント システムは、多くの場合、追加の冗長性 (例: 2oo3 投票ロジック) に依存しており、複数の冗長要素が、潜在的に危険なアクションを実行する前に同意する必要があります。これにより、システム レベルで可用性と安全性の両方が向上します。これは、継続的な可用性が必要で、フェイルセーフ モードがない航空宇宙システムでは一般的な方法です。たとえば、航空機では、飛行中の舵や補助翼などの制御面には「安全な」デフォルト位置がないため、常に動作している必要があるフライト コンピューターと制御面 (場合によっては、電気/機械/油圧などの異なる動作モードを含む) に 3 重のモジュール冗長性を使用する場合があります。

上記の 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]な​​どがあります。}

• N. Diaz、R. Pascual、F. Ruggeri、E. López Droguett (2017)。「複数の時間スケールと確率的使用プロファイルの下での経年変化政策のモデル化」。国際生産経済ジャーナル。188 :22–28。doi :10.1016/ j.ijpe.2017.03.009。{{cite journal}}: CS1 maint: multiple names: authors list (link)

• Barlow, RE および Proscan, F. (1981) 信頼性および寿命試験の統計理論、To Begin With Press、Silver Springs、MD。
• ハードウェアの信頼性を簡素化: 5 分以内にワイブル分布を直感的に理解! (Python コード付き)
• ブランチャード、ベンジャミン S. (1992)、「ロジスティクス エンジニアリングおよびマネジメント(第 4 版)」、Prentice-Hall、Inc.、ニュージャージー州イングルウッド クリフス。
• Breitler, Alan L. および Sloan, C. (2005)、アメリカ航空宇宙学会 (AIAA) 空軍 T&E デイズ会議議事録、テネシー州ナッシュビル、2005 年 12 月：「システム信頼性予測: ニューラル ネットワークを使用した一般的なアプローチに向けて」
• Ebeling, Charles E.、(1997)、「信頼性と保守性エンジニアリング入門」、McGraw-Hill Companies、Inc.、ボストン。
• Denney, Richard (2005)「ユースケースで成功する: スマートに作業して品質を実現する」Addison-Wesley Professional Publishing。ISBN。ユースケース主導のソフトウェア開発におけるソフトウェア信頼性エンジニアリングの使用について説明します。
• ガノ、ディーン L. (2007)、「アポロ根本原因分析」(第 3 版)、アポロニアン パブリケーションズ LLC、ワシントン州リッチランド
• ホームズ、オリバー・ウェンデル・シニア『ディーコンの傑作』
• ホースバーグ、ピーター (2018)、「優れた信頼性エンジニアの 5 つの習慣」、Reliability Web
• Kapur, KC、および Lamberson, LR、(1977)、「エンジニアリング設計における信頼性」、John Wiley & Sons、ニューヨーク。
• Kececioglu, Dimitri、(1991)「信頼性エンジニアリング ハンドブック」、Prentice-Hall、ニュージャージー州エングルウッド クリフス
• トレバー・クレッツ(1998)プロセスプラント: 本質的に安全な設計のためのハンドブックCRC ISBN 1-56032-619-0 
• リーミス、ローレンス、(1995)信頼性：確率モデルと統計的手法、1995年、プレンティス・ホール。ISBN 0-13-720517-1 
• リース、フランク(2005)。プロセス産業における損失防止(第 3 版)。エルゼビア。ISBN 978-0-7506-7555-0。
• MacDiarmid, Preston; Morris, Seymour; et al., (1995)、「信頼性ツールキット：商業実務版」、信頼性分析センターおよびローマ研究所、ローマ、ニューヨーク。
• Modarres, Mohammad ; Kaminskiy, Mark; Krivtsov , Vasiliy (1999)、「信頼性工学とリスク分析：実践ガイド」、CRC Press、ISBN 0-8247-2000-8。 
• Musa, John (2005) ソフトウェア信頼性エンジニアリング: より信頼性の高いソフトウェアをより速く、より安く、第 2 版、AuthorHouse。ISBN
• ニューベック、ケン (2004)「実践的信頼性分析」、プレンティス ホール、ニュージャージー
• Neufelder, Ann Marie、(1993)、「Ensuring Software Reliability」、Marcel Dekker、Inc.、ニューヨーク。
• O'Connor, Patrick DT (2002)、「Practical Reliability Engineering (Fourth Ed.)」、John Wiley & Sons、ニューヨーク。ISBN 978-0-4708-4462-5。 
• Samaniego, Francisco J. (2007)「システムシグネチャとエンジニアリング信頼性におけるその応用」、Springer (International Series in Operations Research and Management Science)、ニューヨーク。
• Shouman, Martin、(1987)、「ソフトウェア エンジニアリング: 設計、信頼性、管理」、McGraw-Hill、ニューヨーク。
• トビアス、トリンダーデ、(1995)、応用信頼性、チャップマン＆ホール/CRC、ISBN 0-442-00469-9 
• 信頼性工学のシュプリンガーシリーズ
• ネルソン、ウェイン B.、(2004)、加速テスト - 統計モデル、テスト計画、データ分析、ジョン ワイリー アンド サンズ、ニューヨーク、ISBN 0-471-69736-2 
• Bagdonavicius, V.、Nikulin, M.、(2002)、「加速生命モデル。モデリングと統計分析」、CHAPMAN&HALL/CRC、ボカラトン、ISBN 1-58488-186-0 
• Todinov, M. (2016)、「信頼性とリスクモデル: 信頼性要件の設定」、Wiley、978-1-118-87332-8。

• 航空宇宙レポート番号: TOR-2007(8583)-6889宇宙システムの信頼性プログラム要件、The Aerospace Corporation (2007 年 7 月 10 日)
• DoD 3235.1-H (第 3 版)システムの信頼性、可用性、保守性のテストと評価 (入門書)、米国国防総省 (1982 年 3 月)。
• NASA GSFC 431-REF-000370飛行保証手順: 故障モードおよび影響分析の実行、アメリカ航空宇宙局 ゴダード宇宙飛行センター(1996 年 8 月 10 日)。
• IEEE 1332–1998 IEEE 標準 電子システムおよび機器の開発と製造に関する信頼性プログラム、電気電子技術者協会(1998)。
• JPL D-5703信頼性解析ハンドブック、アメリカ航空宇宙局 ジェット推進研究所(1990 年 7 月)。
• MIL-STD-785Bシステムおよび機器の開発と製造の信頼性プログラム、米国国防総省 (1980 年 9 月 15 日)。(*廃止。2008 年 11 月 13 日の ANSI/GEIA-STD-0009-2008「システムの設計、開発、製造の信頼性プログラム標準」に置き換えられました)
• MIL-HDBK-217F電子機器の信頼性予測、米国国防総省（1991 年 12 月 2 日）。
• MIL-HDBK-217F（通知1）電子機器の信頼性予測、米国国防総省（1992年7月10日）。
• MIL-HDBK-217F（通知2）電子機器の信頼性予測、米国国防総省（1995年2月28日）。
• MIL-STD-690D故障率サンプリング計画および手順、米国国防総省（2005 年 6 月 10 日）。
• MIL-HDBK-338B電子信頼性設計ハンドブック、米国国防総省（1998 年 10 月 1 日）。
• MIL-HDBK-2173海軍航空機、兵器システム、およびサポート機器に対する信頼性中心メンテナンス (RCM) 要件、米国国防総省 (1998 年 1 月 30 日) (NAVAIR 00-25-403 に置き換えられました)。
• MIL-STD-1543B宇宙および打ち上げ機の信頼性プログラム要件、米国国防総省 (1988 年 10 月 25 日)。
• MIL-STD-1629A故障モードの影響および致命度分析の実行手順、米国国防総省 (1980 年 11 月 24 日)。
• MIL-HDBK-781Aエンジニアリング開発、認定、および製造のための信頼性テスト方法、計画、および環境、米国国防総省 (1996 年 4 月 1 日)。
• NSWC-06 (パート A および B)機械設備の信頼性予測手順ハンドブック、海軍水上戦闘センター(2006 年 1 月 10 日)。
• SR-332電子機器の信頼性予測手順、Telcordia Technologies (2011 年 1 月)。
• FD-ARPP-01自動信頼性予測手順、Telcordia Technologies (2011 年 1 月)。
• GR-357電気通信機器に使用されるコンポーネントの信頼性を保証するための一般要件、Telcordia Technologies (2001 年 3 月)。

http://standards.sae.org/ja1000/1_199903/ SAE JA1000/1 信頼性プログラム標準実装ガイド

英国では、英国国防省の支援のもと、防衛基準としてより最新の基準が維持されています。関連する基準には次のものがあります。

DEF STAN 00-40 信頼性と保守性 (R&M)

• パート1: 問題5: プログラムと計画の管理責任と要件
• パート 4: (ARMP-4) 問題 2: NATO R&M 要件文書の作成に関するガイダンス
• パート6: 問題1: 稼働中のR&M
• PART 7 (ARMP-7) 問題1: ARMPに適用されるNATO R&M用語

DEF STAN 00-42 信頼性および保守性保証ガイド

• パート 1: 問題 1: ワンショット デバイス/システム
• パート2: 問題1: ソフトウェア
• パート3: 問題2: R&Mケース
• パート 4: 問題 1: テスト可能性
• パート 5: 問題 1: 稼働中の信頼性の実証

DEF STAN 00-43 信頼性と保守性保証活動

• パート2: 問題1: 稼働中の保守性デモンストレーション

DEF STAN 00-44 信頼性と保守性データの収集と分類

• パート 1: 問題 2: 英国海軍、陸軍、英国空軍におけるメンテナンス データと不具合報告
• パート2: 問題1: データ分類と事件判決 - 一般
• パート3: 問題1: 事件判決 - 海上
• 第4部: 問題1: 事件判決 - 土地

DEF STAN 00-45 第1号: 信頼性中心のメンテナンス

DEF STAN 00-49 発行 1: 信頼性と保守性 MOD 用語定義ガイド

これらは DSTAN から入手できます。SAE、MSG、ARP、IEE など多くの組織によって作成された商用標準も多数あります。

• FIDES [1] FIDES方法論（UTE-C 80-811）は故障の物理学に基づいており、テストデータ、現場からのフィードバック、既存のモデリングの分析によってサポートされています。
• UTE-C 80–810またはRDF2000 [2]。RDF2000方法論はフランスの通信業界の経験に基づいています。

• TC 56 規格: 信頼性

• 信頼性工学に関連するメディア（Wikimedia Commons）
• John P. Rankin コレクション、アラバマ大学ハンツビル校アーカイブおよび特別コレクション、スニーク回路に関する NASA 信頼性エンジニアリング研究。
• ハードウェアの信頼性を簡素化: 5 分以内にワイブル分布を直感的に理解! (Python コード付き)