機能安全編

株式会社制御システム研究所　森本　賢一

2010.11.25
※記事執筆時は、三菱重工業株式会社　原動機事業本部に在籍

（よい青写真をつくる）
本メルマガ第一回で、設備全体のFMEAとHAZOPのお話をしました。構成要素の故障が、設備に対してどのような影響を与えるのか、リスク分析の一端として行う活動でした。その際のFMEAでは、電子機器は大きな１つの要素であり、計測部分や弁やポンプといった要素を含めた設備全体について、それぞれの故障を分析しました。

今回お話するSystem FMEAは、その活動を対象の電子機器の内部に関して行うものです。スタイルは同じです。システムの内部を大まかなブロックで分割して表し、その故障モード（Failure Mode）を洗い出して、その影響や打ち手を考察する作業です。

このため、System FMEAをする前に、システムの概要（＝青写真）を作成しておく必要があるのですが、私たちにとっては、この青写真をつくることがなかなか難しいです。

以前もお話しましたが、日本のモノづくりの多くの現場では、「青写真」とは、その開発対象のイメージを共有するものです。重要な開発項目や新規採用部分は少し詳細に、担当所掌が変わる部分は明確になるように、おおよその開発フローがイメージできるよう記載することが多いと思います。つまり「業務の勘所」を表すことが多いです。しかし、ここで求められる「システムの概要」とは、System FMEAをするための土台であることを意識しなければなりません。

具体的には、

• ①Failure Modeを意識してブロックに分割する。
• ②Common Cause Failureを起こす可能性のある部位は漏れなく記載する。
• ③ソフトウェアなど「動き・振舞い」についても定義する。

の3つについて留意が必要です。
つまり解析のための青写真なのです。業務の所掌区分や部門間のI/Fなどではなく、構造やそのシステムの原理や特性が図面に明確に現れることを意識しなくてはなりません。

①をより細かく説明すると、『できるだけ単一の機能を１つのブロックにする』と言えます。１つのブロックで様々な機能を包含させてしまうと、そのFailure Modeを洗い出す際に、漏れが出やすくなります。

たとえばCPUチップの場合、バスを調停するコントローラもあれば、プログラムの実行部位もあるでしょうし、これらを１つの大きなブロックで表してしまうと、故障の仕方を議論する際、なかなか簡単にFailure Modeを洗い出すことができません。

②についてはまずは物理的な構造はきちんと表現することです。ラックやバックプレーン、多重化している場合には両者をつなぐ論理的なコネクション、物理的なコネクションなどが挙げられます。冗長化している部位の周辺は特に重要です。何気ないDIP スイッチや押しボタンなど冗長化しているブロックに共通して信号や情報を渡しているものがあれば、それがどれだけ小さな部品でも青写真に記載することが望ましいです。

こう書くと「そんなに、何でもかんでも書いてしまったら、大きな図面になってしまって本質がわからなくなるのではないか？」という危惧があろうかと思います。その通りです。詳細な部品を単に全部記載すればいいのではありません。

適切な青写真を書くためには、予めFMEAやFTA（Fault Tree Analysis）をイメージしておく必要があります。またCommon Cause Failureがどのように全体のシステムに影響するのか、ひいてはそれが影響を与えるPFDave／PFHとは何なのか、それらをイメージしながら書く必要があります。

構想設計とFMEAやFTAという分析は、１度ではなく繰返し、繰返し行うことが望ましいです。プロジェクトの工程を立案する際はこのことを織り込み、スケジュールを立てることをお奨めします。

③については後ほど（構造からはわからないCommon Cause Failure）の項で解説します。


（System FMEAとFTA）
青写真ができたら、そこに表されているすべての部分、ブロック図ならば１つ１つのブロックについて、そのFailure Modeを洗い出します。System FMEAは、ボトムアップ型の分析手法です。個々のブロックの故障が与える影響を積み上げてゆくからです。それに対して、FTA（Fault Tree Analysis）はトップダウン型と言えます。システム全体がもつ機能障害（安全機能が不動作となる状況）が、個々のブロックのどのような障害の結果で生まれるのか、分解してゆく手法だからです。

System FMEAでは、定義した１つ１つの機能ブロックに対して、その故障のモード（故障のおこり方）を洗い出し、それぞれがどのような結果に至るのか、それぞれの故障モードが、危険な状態に繋がらないようにするにはどのようにすべきかを考えます。有効な手立て、防止手立てが見つかれば、それは新しいRequirementとして抽出します。



ハードウェアの弱点を自己診断などのソフトウェアでカバーすることはよくあることです。ここで生まれる「防止手立て」は、構想設計を始める前の要求仕様策定段階で取り決めたRequirement以上に、そのシステムの安全性に重要な意味を持ちます。単にメモとして書きとめるのではなく、きちんとRequirementの管理台帳に記載して後々追跡チェックできるようにすることが大切です。

このSystem FMEAという手法は、複合要因（2つ以上の異なる部位の故障が組み合わさって初めて危険な故障となって顕在化するもの）で発生する危険状態について分析することが苦手です。またCommon Causeに起因する危険状態についても分析することが苦手です。

一方ＦＴＡという手法は、最終的に発生する危険な状態を上位事象（トップ事象）として定義し、それがどのような事象（＝故障や障害）の結果で発生するのか、ANDやORや条件分岐を使って表してゆきます。最終的に青写真で記載している、１つのブロックレベルの障害に分解できれば十分です。したがって前述のSystem FMEAの苦手なところ、すなわち複合要因での危険事象の発生や、Common Causeに起因する危険状態について明示しやすいです。特にサブシステムを多重化している場合などは有用です。

逆にこのFTAという手法では個々のブロックに内在する故障の種類について、深く掘り下げることは苦手です。すべてのコンポーネントの故障モードが、予め想定した上位事象の網ですべて網羅できているかどうかは定かではないからです。このような部分では、System FMEAの活動が重要な意味を持ちます。



このようにSystem FMEAとFTAは、両方行って互いに補う必要があります。当然青写真は、それぞれの手法に耐えうる記述になっていなければなりませんから、System FMEAやFTAをすることで、青写真の表現や記載が変化してゆくでしょうし、その結果再度System FMEAやFTAを行う必要がでてくるかもしれません。つくってしまった青写真を後生大事に一方的に分析するのではなく、分析しながら青写真を深めてゆく、というスタンスが大切です。