これからプラント分野の機能安全（IEC-61511)に取り組む方を対象に、この規格がどのような取り組みなのかを知っていただくための連載です。要件の背景や具体的な取り組み例を知っていただき、本格的な勉強につなげていただければ幸甚です。
本記事は工業技術社月刊「計装」2017年4月号から連載した記事に一部追記し、編集部ご了解のもと掲載しています。掲載記事は本誌をご覧ください。＃8回はランダム故障について解説します。
コンピュータは信用ならない
安全完全性を高めるために、人に起因する障害（システマティック故障）を取りのぞくための活動を、前回＃7回まででお話ししました。今回からは、ハードウェア（電子部品）にランダムに発生する物理的な障害について見ていきます。
1.ソフトエラーとハードエラー
コンピュータやFPGA[1]の内部は、小さなトランジスタによって作られたANDやORの集合体ですから、結局電磁リレーの集まりみたいなものです。しかし内部は電磁リレーのような機械構造ではなく、半導体（化学物質）のパターン内の電荷の配置が信号やデータ（０や１）を表します。
電荷が変化すれば信号やデータが変化します。外部からの影響でビット反転する心配をしなければなりません。（図１）もちろん今に始まった話ではなく、昔か宇宙ではそのような障害の心配をしていましたが、地上でも心配する時代になってきました。半導体部品の微細加工が進んでいるのも理由の一つです。
このような障害をソフトエラー[2]といいます。永続的に壊れる故障をハードエラーといいますが、ソフトエラーは構造的なダメージがないため、再起動したり処理が進んで電荷の配置がリフレッシュすると「エラーが起こっていた状態」を失ってしまいます。電荷が一時的に影響を受けるだけですから、後で本当に発生したかどうかを確認したり証明することはできません。
たった１ビットといえど侮れません。（そもそも１ビットだけかどうかもわかりませんが）もしもそれが、条件分岐IF文の変数ならば、間違った条件分岐をして違う処理に入ってしまいます。これはプログラムの書き間違い、つまりバグではありません。
このような特殊なエラー以外でも、通信データが配線経路上でノイズなどの影響でビットが化けてしまうこともありえます。インターネットで、世界中のホームページの画面が一瞬で間違いなく表示されますが、実はあれ、パソコンの通信処理プログラムや表示するブラウザが、受け取ったデータにエラーがある場合は自動的に再送信を要求しているのです。通信経路でビット化けは（ある一定の確率で）必ず起こります。
なにかのトラブルが起きてしまった後、たとえば本当にソフトエラーが発生したのか、否発生していなかったのかを議論することは困難で不毛です。素子が劣化して動作が不安定な場合も、「その事故の瞬間」にどのような状態だったのかを確定的に述べることはできません。このためクリティカルな処理（安全完全性が必要な処理）には、あらかじめ対策を仕組みとして組み込んでおくことが必要です。そうしないと万一の事故の際の製造物責任の裁判では極めて不利です。
たとえば、条件分岐は、”１１１１”と”００００”の４ビットで判断するようにすれば、１ビットぐらい変化してもそれが間違たデータであると検知できる（検知できるので間違った処理に行かないようにできている）と主張できそうです。
2.ロバストな設計とリスクベースデザイン
ソフトエラーなどのビット化けは、コンピュータ（半導体、LSI）のすべての演算や記憶、通信経路で発生しうる故障ですから、いたるところで発生する（かもしれない）と想定しなければなりません。
「できるだけ動作が安定している素子＝品質が高い」ことや「プログラムが間違っていないこと＝品質が高い」はもちろん大切ですが、確実に動くのかどうか（完全性）という意味では道半ばです。前述のような仕掛けが適切に搭載され、コンピュータや電子素子の誤動作に強い仕組み（構造）になっていることが制御システムには不可欠です。これは素子やプログラムの品質というよりも、それ以前に、求める機能を「どのように実現したのか」という実現の手法、アプローチ、構造に基づくものだともいえます。
制御回路をブロック図で示す市販ツールでは、モデルブロック図を右クリック一発でC言語コードに変換して吐き出してくれます。これは機能をC言語で表現しているものですが、完全性のための仕組み[3]が適切に組み込まれているととは話が別です。完全性のためには動作するハードウェアや、タスク起動の方法などと関係した仕組みの検討が必要だからです。
同じ安全に関するタスク（プログラム）でも、タイマー割込みでタスクが起動するものと、通信完了割り込みでタスクが起動するものとでは、安全完全性達成に必要な仕組みは異なるでしょう。高度な自動制御の機能を、安全が（安全完全性が）必要な分野に容易に展開できない（してはならない）理由はここにあります。逆に言えば、安易に展開してはならないのです。
このような電子システムにランダムに発生する障害が発生しても、必要な安全機能が損なわれないための設計をロバストな設計といいます。システムに発生するかもしれない故障を網羅的に洗い出し想定外をなくす努力の後に耐性のある仕組みを考える必要があります。このような構想設計を、私はリスクベースドデザインと呼んでいます。このプロセスの結果確認としてPFDやPFHの値を用いて評価します。[4]
以前お話しした本質安全[3]とは大きく異なることが感じられたでしょうか。本質安全設計で基準となる物理現象は原理として確定的です。このため安全の対策では優先的に必要とされます。確率的に誤動作するコンピュータ（LSI、集積回路）を用いた安全の仕組みは本質安全対策の「次の一手」として、機能安全という別枠で議論することが望ましいと現代では考えられています。コンピュータによる安全確保の仕組みがにはIEC-61508の考え方が必要となります。自動車やインフラのみならず身の回りの電化製品の安全規格にも広がっている背景です。[5][6]
ロバストな設計なるものは、製品を作り上げた後に実験ラボで「ほらロバストでしょ！」と証明することはとても難しいです。様々な電子部品の故障や、特にCPUのような演算部品でランダムに（確率的に）発生するエラーに対し、しっかり対処できる十分な仕組みを備えているのか、そもそも本当に万一のエラーを網羅的に想定しているのか、それは完成した製品をいくら眺めても判断つくものではありません。もちろん、設計図（製造図書）をいくら眺めても判断つきませんよね。このような論点のため、機能安全が必要な分野においては、「作ってしまってから安全完全性を証明する」ことはとても難しいのです。
詳細設計を開始する前に、安全完全性が必要なシステムのアーキテクチャを見える化し、それに対して網羅的なリスク分析をした事実を残し、そこからこつこつと積み上げた対障害のための設計ルールや基準、仕組みの明確化。そしてそれを最後のモノづくりまで一貫していることの証明（トレーサビリティ）をもって、それがあるレベルまで高められたと評価する活動が機能安全の活動です。
この活動は開発当初の１回だけで終わるものではなく、部品の変更や機能の拡張などに応じて繰り返し実施する必要があります。部品が変われば障害の発生の仕方が変わるかもしれませんし、機能が拡張されれば故障の影響が拡大するかもしれないからです。毎回新たに０からシステムの障害解析をし直すことはとても労力がかかります。システムの障害解析やリスク分析は、初回の議論をしっかり記録継承し、永続的に維持してゆくことが必要です。
機能安全の最後の試験では、この最初の「障害の想定」が試験のテストケース（試験項目）設定の根拠の一部になります。最初の活動を適切に実施しておかないと、最後の評価試験で何をテストすべきなのかすら、決まらないことになります。
システマティック故障に対処するために、前回、プロジェクトのスタート前にFSMS（Functional Safety Management System）をしっかり作る必要性を解説しました。ランダム故障の観点においても、機能安全の活動とは、作った後ではなく「作る前のプロセス」が問われるのです。
人がしでかす「システマティック故障」と電子システムに発生する「ランダムハードウェア故障」の両方をどのように想定し、それに対してどのように取り組もうと（最初に）考え、どのぐらい確実に最後まで実施したのかを記録として残し第三者に証明する作業です。
上記のお話を踏まえていただければ、「システムの安全完全性」とは、前提や条件に基づいた構想設計段階での「想定」の上で出てくるお話だと分かるでしょう。手放しで、「どのような使い方をしてもSIL3！」という製品はありえません。ある条件や想定の上で積み上げたのが、SILであり認証です。
製品のSafety Manualには、「この使い方の範囲でSIL認証取りました」とう記載があります。プラント計装エンジニアリングで使用する際は、この条件を逸脱できません。逸脱した使い方をした場合、そのPLCは安全PLCではなく単なるPLCになってしまいます。そのような使い方で万一事故が発生し訴えられた場合、それはPLCメーカの瑕疵ではなく、使う側、エンジニアリング側の瑕疵として認定されるでしょう。
（図２）にある「Application program safety requirements」のInputに、「Safety manuals of the selected SIS.」が記載されているのはその所以です。Safety Manualは、据え付け後運用段階で読むものではなく、SISを「発注する前に読んで」、自分たちの使い方にマッチした製品か「事前にチェックするべき図書」です。Safety Manualを「購買契約したら見せてもらえるマル秘図書」として扱うのは大きな間違いです。
次回は、システムの多重化など、システムエンジニアリングでのランダム故障対策を見てゆきます。
脚注
[1]FPGA(field-programmable gate array), ANDやORなどの論理回路の基本要素や汎用演算ブロックやメモリブロックなどの接続を書き換えることで、特定の機能を実現することができる電子素子。
[2] 小林和淑；半導体の耐性試験-加速器によるシングルイベント耐性の実測評価-,日本加速器学会「加速器」Vol.13, No. 4, 2016.
[3]安全完全性のための仕組み, IEC 61508ｰ2 Annex “Techniques and measures for E/E/PE safety-related systems – control of failures during operation”
[4] IEC, Functional safety of electrical/electronic/programmable electronic safety-related systems –Part 2: Requirements for electrical/electronic/programmable electronic safety related systems, IEC 61508-2 Ed 2.0, Apr. 2010.
[5] ISO, Safety of machinery —General principles for design — Risk assessment and risk reduction, ISO 12100, Nov. 2010.
[6] IEC, Household and similar electrical appliances –Safety–Part 1: General requirements, IEC 60335 Ed. 5.1, Annex R (normative) Software evaluation. Dec. 2013.
（株）制御システム研究所は、TUV-SUDの公式パートナー／機能安全エキスパートです。