◎はじめに
社会システムの高度化・複雑化とともに、それらに対する畏怖から「安心・安全」が重要視されている。その社会要請への対応の1つが本講演のテーマの「機能安全」である。産業機器や車載システムをはじめとして多くの産業分野で「機能安全」を取扱う標準規格が策定されており、それらへの早急な対応が産業界に求められている。「機能安全」に対応する際に特に注目されるのが「ソフトウェア」である。これは、「システム」や「ハードウェア」は従来より安全への取組みがなされているが「ソフトウェア」分野は安全への取組みの日が浅く、その取組みに誤解が生じやすいためである。本講演では、これらの誤解を解消すべく組込みソフトウェアを取巻く状況と機能安全との関係について解説された。

◎講師紹介
講師の金田氏は大手電機メーカにて原発・再処理プラント向けの監視制御用計算機システム開発に従事され、マイコンが登場した30年程前に安全系のデジタル化対応の指針・規格策定に参画された。現在は産学公連携コーディネーターとして安全系をはじめ多くの領域で企業指導に当たっておられるとのこと。（ちなみに産学官でなく産学”公”であるのは、自治体（公）である東京都の所属のため。）

◎講演内容
講演は下記の7章で構成されており、組込みシステム／ソフトウェア開発を取巻く状況を理解した上で機能安全への取組みを理解する流れとなっている。
１．組込みシステムの状況
２．機能安全が生まれた背景
３．リスクについて、用語と概念の整理
４．機能安全規格の概要
５．機能安全の認証対策
６．ソフトウェアの安全設計手法
７．業務プロセスの整備

以下、トピックを紹介する。

・組込みシステム開発（安全分析）の課題
安全系の規格では、安全分析の手法としてFMEA、FTA、HAZOPなどの適用が推奨されているが、これらはソフトウェアが本格的にシステムに組込まれ始めた1970年以前に提案された”ソフトウェアの特性を考慮していない”手法である。ソフトウェアのシステムにおける役割が重要化している現在では、ソフトウェアの特徴を考慮した手法が必要である。（Nancy G.Levesonらによる主張 Ex. 2015/6/18 IPA/SEC特別セミナー http://sec.ipa.go.jp/seminar/20150618.html これらに代わる手法として彼・彼女らはSTAMPを提案している。）

・機能安全が生まれた背景
従来よりシステム（機械、電気機器）の不備を原因とする大事故が発生しており、蒸気機関の時代から機械、電気の安全対策がなされてきた。近年、ソフトウェアがシステムの信頼性・安全性に係るようになり、機械系だけでなくソフトウェアを含めた電気･電子機器の安全対策の必要が生じ1998年にIEC61508が策定された。（このIEC61508 で初めて「Functinal Safty（機能安全）」という言葉が使用された。）

・安全規格認証取得策
1.ハザード、リスクを明確にする。
範囲が広いと大変になるので、主要なものに絞り込むことが肝要。
2.対象製品の構成要素を安全系と非安全系に分離し、安全関連系を特定(限定)する。
3.安全系に安全規格取得済みの部品・製品を利用して認証対象を更に絞り込む。
4.ドキュメントを整備する。
各種設計文書、マニュアル、議事録など。
5.エビデンスを整備・蓄積する。
安全系の分析・設計根拠や検査結果などの安全系説明文書など。

・安全規格認証取得時の注意事項（抜粋）
・機能安全マネジメントは品質マネジメントと異なりISO9000を取得していても簡略
化されることはない。
・誤解の無いように用語等の定義、説明を行う。
・CMMIやSPICEの認証を取得していれば機能安全認証の要求事項はかなりの範囲で
満足するが、「安全」の観点を取入れてドキュメント化する。

・ソフトウェアの安全性
ハードウェアの安全性は部品の故障率で示される。部品の故障は部品固体のランダム故障や経年劣化によるものであるので、実体が1つであり経年劣化しないソフトウェアに対してハードウェアの故障率の考えを適用することは困難である。このため故障＝不具合（バグ）を決定論的故障（システィマティック故障）とよぶ設計・製造時の不具合作り込みとして取扱われ、安全設計のほか開発プロセスが評価されることとなる。ソフトウェアの安全設計は確立していないが、制御用計算機システムの安全確保策事例を参照するのがよい。（IAEAの査察官は「日本のシステムが最も厳しい基準であり、それをクリアしている」と感想を漏らしたとのこと。）

・安全性の確保
品質管理だけでは安全性の確保は難しく、システムのライフサイクル全体にわたって多重に管理する必要がある。設計においては、想定外の自体を想定して設計する必要があり、1つのリスクに対して複数の対処策を講じる必要がある。

・ソフトウェアの機能安全対策
ソフトウェアの特性を理解した上で、
常日頃安全に対する感度を高め、
ソフトウェアを工業製品としての管理を徹底し、
適切な外部機関やツールを活用する。

◎質疑応答
Q:ソフトウェアの本質安全とは？
A:”無い”が現時点での結論。
ソフトウェアは保護的対策を担うものであるため、リスクを取除く本質安全は適用
できない。（取除くとソフトウェアそのものが無くなる。）
また、ソフトウェアはCPUが停止すると動作しないので、最後は外部の電気・電子
または機械的な対応が必要となる。

※R-Map研究会的解釈
本質安全の原文は”Inherent safe”であるが、その訳語として「本質安全」が
適切であるかは議論がある。「本質安全」は”「機能安全」でない”という意図が
ある。”Inherently safe design”を「本質的安全設計」として安全方策（危険除去
設計、フールプルーフ、フェールセーフ、冗長設計（ISO12100））とする場合があ
り、制御安全はこちらの立場を取っている。

◎受講感想
組込みシステム／ソフトウェアの状況と課題を下地にすることで、特に組込みソフトウェアの機能安全対応を整理し俯瞰するには適した内容であった。ADASや自動運転を例に出すまでもなくシステムへの安心・安全要求は高まっているが、それに対する「銀の弾丸」は存在せず、対応するシステムの安全実現（リスク排除）に地道に愚直に取組むことが必須であることを改めて認識した。（そのような活動が「銀の弾丸」なのであろう。）その上で、機能安全は、まったく新しい取組みでなく従来の技術や活動をベースにして、それらを今の時代に適合するように熟成・改善させることが肝要であると考える。

R-Map実践研究会の特別講演だけに聴講された方々の安全への意識は高く、講義内容は”極めて当たり前”のこととして受け取られているように感じた。特に、質疑応答の本質安全の議論は興味深く非常に勉強となった。

経験豊富な金田氏の言葉は1つ1つに含蓄に富んだ重みを感じよいものをいただいた気持ちになった。金田氏をはじめとする先人たちの経験と智慧を受継ぎ活かして行くことが後進の課題であると感じた次第である。

以上

執筆者：宿口雅弘