システマチック故障とは？
はじめに
機能安全を勉強する前、私はシステマチック故障のことをシステムの故障（ソフトの不具合）と間違った理解をしていました。技術用語を理解することは、専門家になるための第１歩です。
システマチック故障という用語を知らないと 機能安全 の専門家とはいえませんので、説明していきたいと思います。
システマチック故障
システマチック故障（Systematic Failure）とは、設計、開発、製造、運用などのプロセスに起因して発生する故障であり、特定の条件が揃うと確実に発生する決定論的な故障です[1]。
これに対し、ランダムハードウェア故障は確率的に発生し、統計的に管理可能です。
システマチック故障は、以下のような場面で発生します。
開発段階の設計ミス（例：要求仕様の誤解や曖昧な設計）
ソフトウェアのバグ（例：センサーのしきい値設定ミス）
製造プロセスの問題（例：不適切な半田付け、ファームウェア書き換えミス）
運用・メンテナンスミス（例：誤ったソフトウェアアップデート）
具体例
例1：ECUソフトウェアの診断モジュールのバグ
ECU（電子制御ユニット）の診断モジュールが更新されず、古いバージョンのソフトウェアが残っていた。その結果、アクチュエータ（電気、空気、油圧を機械的な動作に変換する装置）作動中に診断（障害を検出すること）モジュールが作動し、誤って故障と判定され、システムが正常動作を停止した。
例2：センサーのしきい値設定ミス
車載システムの、A ECUとB ECUでセンサーのしきい値が異なっていた（A ECUは50未満、B ECUは40未満と設定）。このずれにより、異常な挙動を示す可能性が高まり、安全性が損なわれた。
例3：人工知能（AI）を用いた設計の不可解な挙動
あるFPGA（プログラマブルな回路）を遺伝的アルゴリズムで最適化した結果、論理ブロック同士が電磁干渉を利用するような設計になった。見た目では分からず、通常のテストでは問題が発見されないが、特定の環境下では誤動作を引き起こす可能性があった。
システマチック故障の対策
ISO 26262（自動車向け機能安全規格）では、システマチック故障を防ぐために以下のような方策を提案しています：
V字モデルによる開発プロセスの厳密な管理
要件定義 → 設計 → 実装 → テスト → 妥当性確認（要件満足の確認）と保守の各フェーズでのチェック（レビュー）を徹底。
再利用可能なアーキテクチャの活用
過去に実績のある設計やアーキテクチャを適用することで、設計ミスを防ぐ。
トレーサビリティの確保
仕様から設計、テストに至るまでの変更履歴を明確にし、エラーの追跡を容易にする。大事なのは、トレースをとることでなく、トレースを取りながら、要求仕様が設計に漏れていないか、実装されたものが設計仕様を満たしている（検証されている）かを、要求仕様が満たされている（妥当性確認）かをテストして確認することです。
安全分析（FMEA, FTA）の実施
故障の影響分析（FMEA）や故障ツリー解析（FTA）を用いて潜在的な問題を洗い出し、対策を施す。
セーフティケースの作成
システムの安全性を論証するためのドキュメント（セーフティケース）を作成し、論理的に安全性を証明する。
システマチック故障は、設計や開発プロセスに起因するため、冗長設計では解決できません。適切なプロセス管理と設計手法を組み合わせることで、発生リスクを低減します。
なお、このシステマチック故障は、機能安全に限ったことではなく、ものつくりで大事な考え方です。
参考文献
[1]ISO 26262:2018 の概説 ― システマチック故障を中心として ―,
永島秀文、安全工学,Vol.60 No.1 (2021).
https://www.jstage.jst.go.jp/article/safety/60/1/60_40/_pdf/-char/ja?utm_source=chatgpt.com