「安全関連システム」とその基本構成、2種類の故障について知ろう：これだけは知っておきたい機能安全（3）（3/4 ページ）
さまざまな産業機器の開発で必要不可欠な機能安全について「これだけは知っておきたいこと」を紹介する本連載。最終回となる第3回は、安全関連システムとその基本構成、機能安全における2種類の故障、機能安全マネジメントなどについて説明する。
故障対策として規格が求めるポイントを知ろう
機能安全規格は、システマチック故障（決定論的原因故障）とランダムハードウェア故障の両方に対し対策を求めています。規格が求める対策は、大まかに分類すると以下の6つがあります。
- 安全ライフサイクル（プロセス）
- マネジメント
- 文書化
- 安全度水準（SIL）の算出と達成
- 機能試験
- 技法の適用
これらのうち「文書化」は設計におけるバグをなくすためのドキュメントの作成をさします。「機能試験」では、実際にランダムハードウェア故障を起こしてみて機能安全を実現できているかを試験します。例えば、ハードウェアに実装された部品を故意に破壊し、その結果として安全な状態で停止するかを確認するのです。これらの他「技法の適用」では、構造化設計、モジュール化、故障検出、故障挿入試験、故障解析、コーディング基準などの技法に沿って設計することが求められます。
IEC 61508では、安全関連システムのハードウェア設計において、自己診断技法や各種故障を抑制する技法、共通原因故障への対策など、具体的な手法を示しています。
ここで確認すべきなのは、ソフトウェアの故障（不具合）は設計に起因するシステマチック故障（決定論的原因故障）であり、ランダムハードウェア故障とは別に区分していることです。ソフトウェアに関する故障（不具合）は、ランダムハードウェア故障に対する確率論的なアプローチを用いません。
IEC 61508では、ソフトウェアの開発に対してはソフトウェア技法を採用しています。内容としては、構造化設計やアーキテクチャ技法を使ったソフトウェアの設計、プロセスの管理などです。ちなみに、これらの設計や管理を確実かつ効率的に行うために各種のツール群も用意されています。実際の安全開発では、これらのツールをいかに活用するかが重要なポイントになります。
機能安全開発はリスクアセスメントから始める
機能安全開発を効率よく進めるには、開発の全容を知る必要があります。開発プロセスの全体的な流れと概要を示したのが以下の図です。
機能安全の開発では、まず、リスク項目をリストアップするリスクアセスメントが必須になります。そして、そのリスクに対する機能目標や安全度目標などの安全要求事項を定義することから始めるのが基本です。
ここでいう安全度目標とは、IEC 61508で定義されているSIL（Safety Integrity Level：安全度水準）のレベルを指します。SILのレベルは1〜4で、レベル4では最も高い安全性が求められます。要求するSILのレベルが定義されないと、そのレベルに合わせた対策が設定できません。求められるSILのレベルは、製品の重要度や異常が発生したときの災害の大きさなどからマネジメント担当者やエンジニアが設定することもあります。
次に、この定義に沿って開発のプロセスや体制、支援ツールなどに関する整備／調達／開発を行います。この後、リスク要因とその回避策についての計画を行います。
リスク要因には、先に説明した「システマチック故障（決定論的原因故障）」と「ランダムハードウェア故障」があります。機能安全開発における安全対策とは、要するにこの2つの故障に対する回避策の開発や実施を意味します。具体的には、システマチック故障についてはハードウェア／ソフトウェアの開発法など、仕組みに起因する安全機能喪失の回避策を実施します。また、ランダムハードウェア故障については、ハードウェアを構成する部品の使い方、稼働に際しての熱、振動、摩耗、劣化などに起因する安全機能喪失の回避策を実施することになります。
システマチック故障およびランダムハードウェア故障に対するリスクの回避策は、その実現程度がSILのレベルによって表現されます。対策の内容をSILによって定量化することで、他の対策と比較が可能になります。
重要なのは、これらの計画や定義、開発プロセスと技法、担当と責務などを文書に書き残すことです。この文書はSP（セーフティプラン）と呼ばれます。このSPによって、機能安全開発の内容を第三者がチェックできるようになります。また、SPは必要な事項をしっかりと処理しているという証であり、規格認証の対象にもなります。
Copyright © ITmedia, Inc. All Rights Reserved.