機能安全編

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

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

（構想設計で大切なこと＝Requirement Base Design）
いずれの手法でも、そのシステムがどのような機能を実現していれば安全（Safe State）なのか、どのような機能を喪失すれば安全ではないのか、明確な定義が必要です。それがなければFMEAは完結しませんし、FTAはスタートすることが出来ません。

本メルマガでは、リスク分析から安全機能要求と安全完全性要求を作る流れの中で、安全完全性要求の一部である「SIL」という最も代表的で有名な指標をご説明しました。そしてそれを達成するためのPFDave／PFHの算出を中心にお話しして来ました。しかし、これは機能安全を達成するために行なう活動の一部を示したのに過ぎません。

機能安全を達成することに於いて、リスク分析を踏まえ定義するべきものは、SILの指標その数値だけではありません。「どのような状態が安全なのか、どのような機能が維持されることが安全なのか」を明確にするため、安全機能要求ならびにそれを確実に動作させるための安全完全性要求にリストアップした１つ１つの項目が大切です。これがあることで、何をもって安全（Safe State）なのかの定義が明確になり、System FMEAやFTAが行えることとなるからです。その定義を踏まえたうえで、それを数値として評価するための指標がSILであったり、前回お話したＳＦＦやＨＦＴなのです。

このメルマガで繰返し述べていますが、機能安全は「これをやったら安全である」とか「数値を満たす高価な機器を単に組み合わせれば安全である」というものではありません。プラントや設備の構造や原理を深く理解し、そのリスクを分析し、必要な要件を定義することが出来てのち、必要な機器を選定したり、開発設計したりするべきものです。

機能安全は「リスク」の定義を拡張することで、人体や環境だけに的を絞った危険回避から、製品や設備が企業や組織に与える様々な危険を回避するための設計手法となりえます。しかしそれを実現するためには、安全機能要求および安全完全性要求を明確にし、それを適切に構想設計に引き継いでゆくことが必要なのです。機能安全がRequirementベースの設計手法である、というのはこのことから来ています。Requirementはいわば魂のようなものです。

魂であることを鑑みれば、Requirementは規格書や外部の誰かから与えられるものではないことも明白ではないでしょうか。その設備や製品の原理や構造に深く根ざすことなく、どこかから与えられた安全機能要求や安全完全性要求を流用して設計しても、それは意味のない仕様を追いかけることにしかなりません。

構想設計はその魂たるRequirementを実際の設計に反映してゆく最初のステップです。上位で取り纏めた様々なRequirementを確実に設計に結びつけ、また下流の詳細設計に割り当ててゆく役目があります。そして構想設計およびそれを用いたSystem FMEA、FTAなどの分析を通して、新たなRequirementを生み出す役目もあるのです。