Facebookで知り合いの書き込みにコメントしたら、どうもソフトウェアにおける「故障モード」って整理されてない／一般的なものが存在しないようだと判明。探せば見つかるのかもしれないが、広まっているものがないように思えた。 ちなみに、CiNiiで「ソフトウェア FMEA」で検索すると19件、「ソフトウェア 故障モード」で検索すると7件ヒットした。未公開などの中に良い情報があるかもしれないが、読める論文だと、故障モードが詳細すぎる気がする。（今回ブログに書いたのは、それも理由。） またCiNiiで「FMEA」で検索すると249件、「ソフトウェア 故障モード」で検索すると119件ヒット。 と言うことで、自分の勉強も兼ねて、ソフトウェアにおける「故障モード」について考えてみた。本来は実機器や実システムでの故障モードを考えるべきとか考えるのが普通だけど、多少一般化できないかとの思いで記述。 ちなみに自分自身の「故障モード」やFMEAでの経験だけど、知識として知ってはいても実践はほとんど無い。実践と言っても、概算を机上で考えて重要そうなものを書き出す程度。装置やシステム全体のFMEAを全部記述して算出まで行うのは自分も経験無いし、ハード屋さんのそれも見たことがないように思う。（ハード屋さんは、MTBF算出の方が結構重要だったと思う。）
故障モードを具体的にイメージできそうに思ったものが左の二つ。
それぞれ、左の書籍での記載からである。
構成部品での故障を識別できる文言で記載し、上位構成要素（上位システムとか全体を含む）への影響を記載してある。他に発生頻度や重要度を記述し、その対応の必要性を検討する。例示したものは、分かりやすいと感じた。 ただし最初で述べたアクセスしやすい論文では、ソフトウェアのFMEAではトップダウンでのFTA手法と対比を意識するためか、細部の部品での故障に拘ることがあるようだ。ここで例示したような基板やある程度の機能の括りで考えた方が良い（と考える）。 また、記述する”故障モード”であるが、ソフトウェアの場合でのバグ分類のように分類する時／人がいる。仕様漏れで誤作動といった具合。それもおかしい。むしろユーザーとかサービスマン目線で考えるべきだ。（製造時のFMEAを検討する時があるけど、その件とは別で、あくまで一般的な故障モードでの話し。） 上記を敢えて書くのは、特にシステムの場合は、メカやエレキから構成される機器（サブシステム）や基板などが存在し、システムや機器の故障モードを考える場合は、メカやエレキによる故障モードと構成部品や故障の粒度を似たものにすべきであるためである。そうしないと”ちぐはぐ”になり、FMEAの結果を見るサービスマンなどが混乱してしまったり対応の検討も悪いものになる。 また、昨今ではクラウドを利用したソフトウェア開発が少なくない。その際にHDDやメモリーの故障は避けて通れないし、むしろそれを前提に設計する。それと同次元で、ソフトウェアの故障も考えて検討する意味でも、故障の粒度は似たものがよい。 さて、一般的な”故障モード”について。前述の「FMEA手法と実践事例」などでも記載されているが、「IEC 60812;FMEA」での”一般的な故障モード”は以下の4つ。
速めに動作
規定された時間に動作しない
規定された時間に停止しない
動作中の故障
ちなみにJIS Z 8115では以下のように表現している。
故障モード 故障状態の形式による分類。例えば，断線，短絡，折損，摩耗，特性の劣化など。
「FMEA手法と実践事例」では、IEC 60812;FMEAなどをもとに、それらを少し詳細化したり、電気系の機器ならこのような故障モード、電子部品ならこのような故障モードというのが参考として書かれている。例えば、電気系機器や電子部品での故障モードとしては、開放（断線）、短絡（出力が0）などである。 なお、従来のFMEAの考えは構成部品が上位へどう影響するの目線での検討であった。ところが、ソフトウェアの場合は、自分たちの構成部品でないものの影響で全体がダウンするなどがありえる。PCでの自分たちのソフト以外がメモリーやCPUリソースを喰ってしまい、PC全体がダウンするようなケースである。ある意味では、（自分たちの関与しない）他の構成部品からの”攻撃”で、自分たちの構成部品がダウンしてしまう。ウィルスが端的な例である。 ネットワークが絡むと更に”攻撃”への意識が必要な場合がある。具体的にはDoS攻撃などである。一般回線でない機器内のバス結合に近い状況でも、特定の構成部品の故障が結合路へ思わぬ負荷をかけたり、他の構成部品を故障や不正動作を誘発することがある。 CAN(車載ネットワーク)やフライバイワイヤー（航空機の操縦・飛行制御システム）のように、人命などに関わる機器での構成部品間のネットワーク経由での結合が普及している。特殊な通信経路や形態もあるが、汎用的なネットワークケーブルによるLANでのシステムも少なくない。また、機器内にそれらのネットワークを持つと同時に、サービスマン用やクラウドとの接続でWANと繋がる場合も多い。ネットワークに絡む故障モードは、大きな課題でもあり意識が必要とだろう。 他の構成部品や自分たちと関係しない部品やネットワーク経由の処理が、自システムや自システムに影響を及ぼす故障は、FTAでの検討も一つの方法かもしれない。FTAはトップダウン思考なのでマッチしやすいとの考えであり、FTAとFMEAとのハイブリッド的に考えた方が良いとの考えは組織体によるかと思われる。ただし個人的には、冒頭で述べたように、そう全体を整理することはないので、FMEAで”全体”（あるいは他からの影響）というものを構成部品に加えてボトムアップ的なFMEA前提で考える方がよいと思うのだが、、、｡ さて、FMEAの検討の際によく利用されるのが、HAZOP(IEC HAZOP)であろう。以下で、HAZOPでのガイドワードをしめす。ちなみにこの一覧は、名古屋工業研究所の小川氏などによる表の、分類～外れの表現部分の抜粋である。
| 分類 | 誘導語 | 外れの表現 |
| 存在 (existence) | 無 (no) | 質文は量が無い |
| 方向 (direction) | 逆 (reverse) | 質文は量が反対方向 |
| 他 （ｏｔｈｅｒ ｔｈａｎ） | その他の方向 | |
| 量 (quantity) | 大 (more) | 量的な増大 |
| 小 (less) | 量的な減少 | |
| 質 (quality) | 類 (as well as) | 質的な増大 |
| 部 (part of) | 質的な減少 | |
| 時間 (time) | 早 (early) | 時間が早い |
| 遅 (late) | 時間が遅い | |
| 順番 (order) | 前 (before) | 順番が前(事前) |
| 後 (after) | 順番が後(事後) |
それらを踏まえて、ソフトウェアの故障モードの私案を示してみる。冒頭で述べたように本来は具体的な機器やシステムでのソフトウェア構成部品の故障モードで考えるべきだけど、ここでの故障モードはある程度汎用的と思われるものにしている。
| 故障モード | 備考 |
| ソフトウェアが存在しない（本来より少ない） | 起動してない、起動後(他とのバージョン不整合などにより)自身でexit、killされた、、、 |
| ソフトウェアが本来より多い | （規定以上の）二重起動、終了せず |
| ソフトウェアが動いていない | ハングアップ、（一定時間）応答無し、起動後自身でループなどで停止 |
| リターン値が異なる | 正しくない値をリターン |
| リターン値が異常 | 範囲外や型異常 |
| リターン個数が異なる | 多い、少ない |
| リターンデータが異なる | 浮動小数点の微少部分、画像・音声データの微量部分、、 |
| リターンデータが異常 | リターンフォーマット異常 |
| リターンタイミングが異なる | 早い、遅い、順番が異なる、タイミングがブレル |
| アクセス異常 | アクセスすべきでないものへアクセス。DBへのアクセス、フラグ／GUIなどデータ領域へのアクセス、他ソフトとの通信、他デバイスとの通信 |
| アクセス方法が異常 | 物理的／論理的にアクセス方法がマッチしてない |
| アクセスしてない | 物理的／論理的にアクセスしてない |
| アクセスデータ書き込みの値が正しくない値 | 間違った値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信 |
| アクセスデータ書き込みが異常値 | 異常値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信 |
| アクセスデータ読み込みの結果が異なる／異常 | 間違ったデータを取り込む。DBからの読み込み、データ領域からの読み込み、他ソフトとの通信、他デバイスとの通信 |
| アクセスデータへのアクセスタイミングが異なる | 早い、遅い、順番が異なる、タイミングがブレル |
さほど多くない。逆に、もっと個数を絞っても良いかもしれない。（既に述べた、PCなりシステムがダウンするのは、これとは別に構成部品＝全体として故障モードを考えればよい。そちらでの故障モードの個数は、多くても数個だろう。） Facebookを契機にソフトウェアにおける「故障モード」を考えてみたけど、自分なりに気づきも出てきて勉強になったと言える。故障（モード）の検出を分かりやすくするには、どうしたらいいか。ここで示した故障モードでも、うまく区別しきれない状況もあり故障モードとして統合した方が良いのか、あるいは区別できる方法を考えるべきか、、、、。今回のをたたき台にして、ブラッシュアップすることも頭の隅に入れておきたい。
