あの事故はなぜ起きたのか!!(5) ―― マネージメント規格IEC61508に基づく安全度水準の求め方
2．ソフトウェア設計における安全度水準の求め方
近代産業システムのあらゆる分野にコンピュータが採用されるようになっています．コンピュータのハードウェア自体の故障は極めてまれになる一方，ソフトウェアは複雑・巨大化し，安全性や信頼性が問題となっています．またコンピュータの安全性には，人間への危害といった直接的な意味のほか，財産保護や社会，環境への影響などの広い意味を含むようになってきています．
ところで，ソフトウェア安全性の権威である米国MIT（Massachusetts Institute of Technology）のLeverson教授の著書「Safeware」（4）では，ソフトウェアに関する7個の神話を挙げていて，このような神話に基づいて設計することが問題を引き起こしていると解説しています．
神話1：コンピュータのコストはアナログ機器や電気機械的装置よりも安い．
神話2：ソフトウェアは簡単に変更できる．
神話3：コンピュータは機械的装置よりも高い信頼性を提供してくれる．
神話4：ソフトウェアの信頼性を高くすれば安全性も高まる．
神話5：ソフトウェアをテストし，また，形式手法採用により，すべてのエラーが除去できる．
神話6：ソフトウェアを再利用すれば安全性が高まる．
神話7：コンピュータは機械的装置よりリスクが少ない．
ソフトウェアを扱った人ならどれもが，なるほどと感じる一方で，神話を信じてひどい目にあった経験を持っている人も多いでしょう．
ソフトウェアの大きな特徴は人間の産物であるということです．基本的に1行1行すべてを人間が書いて検査するしかないのです．つまり人間が工作機械であり，検査装置となっています．ところが人間は必ず間違えます．また，ソフトウェアの検査過程では，すべての入力データとパスのテストを実施するなど高い目標が要求されます．さらに，ハードウェアでは多重化によって一定の信頼性向上が見込めるのに対し，ソフトウェアでは多重化は意味をなしません．
プログラムの自動化はノイマン式コンピュータの発明以来，技術者の夢でした．半世紀以上たっても実現はいまだ夢のようです．もちろん，これらの一部を自動化したり，図式化したり，技術者を楽にしようというツールはいろいろ出ています．しかしプログラムに対する要求がそれ以上に複雑化し，相対的な進歩はまだまだという感があります．
従って設計，製造，検査，運転，保守というライフサイクルにおいて，ソフトウェアについては人間の産物であるということを前提にして安全性を確保しなければなりません．つまりソフトウェアについては，100%の信頼性を期待するのではなくて，危険な間違いが起こりにくいような仕組み（フォールト・アボイダンス技法），あるいは危険な間違いがあっても許容できるような仕組み（フォールト・トレランス技法）を考えなければなりません．IEC 61508には，これらについて多数の技法が推奨されています．
ところでリバソン教授によれば，ソフトウェアの誤りには次の2通りがあるとされています（4）．
① 最初の要求仕様が間違っていた．
② コーディングする時に要求仕様を間違えた．
2番目の誤りに対しては，正しくコーディングできればよいわけですが，人間の産物である以上，完ぺきなソフトウェアを作ることは不可能です．もちろん，ソフトウェアの信頼性を向上させる技法がいろいろ考案されていますが，そもそも，1番目の要求仕様が間違っている場合などには事故が起こり得ます．従ってソフトウェア要求仕様とコーディング結果の安全解析を実施し，危険なソフトウェアを排除する必要があります．
●ソフトウェア安全性への要求
ソフトウェアの故障（不具合）は，いわゆる決定論的故障です．故障（不具合）は製作時に組み込まれており，一般的にはランダム・ハードウェア故障に対する確率論的なアプローチを採用するのが困難です．そこでソフトウェアのような決定論的故障に対してIEC 61508では，
- 安全ライフサイクルの導入
- SILに応じて指定されたソフトウェア技法の採用
- 機能安全評価の実施
- 組織の機能安全管理
- 個人に対するコンピテンシー評価の推奨
などを採用しています．特にソフトウェアの設計製作段階においては，各SILに応じて採用すべき技法，つまりベスト・プラクティス（最善技法）として約100のソフトウェア技法を提示しているのが特徴です（5）．
当該システムのSILに応じて採用すべき技法の数は，図5のように多くなります．これは完全なソフトウェアは存在しないので，故障（不具合）発生を確率論的に捉えて，技法を組み合わせることによって安全性を高める思想です．なお，このように「決定論的故障であるソフトウェアの信頼性・安全性を数量的に評価できる」という主張に対して，理論的根拠がないとの批判も耳にします．どちらが正しいかは今後も時間をかけないと分からないでしょうが，ほかに適切な手法がない以上，今後も続けることになるでしょう．
図5 安全度基準に応じて強く推奨される技法数
●ソフトウェアの安全ライフサイクル
安全関連系ソフトウェアの設計開発フェーズにおいては，図6に示すように，いわゆるVモデルによる開発プロセスが採用されています．このプロセスについては筆者も協力した解説本が出版されています（6）．
図6 ソフトウェア設計開発のVモデル
●ソフトウェア技法一覧
IEC 61508ではソフトウェア製作を10段階に分けて，それぞれに推奨技法を指定しています．そのほかにプログラミングに使用すべき，あるいは使用すべきでない言語が24種類定義されており，合計で100ほどの技法がベスト・プラクティス（最善技法）として規定されています．
10段階のうち，ソフトウェア詳細設計段階における技法を表3に示します．表3中でHRは強い推奨，Rは推奨,―はどちらでもないという意味です．なお1a，1b，1cはどれを選んでもよいことになっています．
100もの技法があり，どれがフォールト・アボイダンス技法で，どれがフォールト・トレランス技法なのかは明記してありません．また，信頼性向上技法と安全性向上技法が混在しており，中には高度な技法もあって，全容を理解するのは困難かもしれません．最近話題のテーマを一つ挙げるなら形式手法でしょうか．数学的原理に基づく形式手法は，1960年代の終わりから，欧州を中心に研究が進められ，筆者の調査では140もの提案がなされてきました．このうち産業界で利用できそうないくつかの手法についての実施例は参考文献を参照してください（7）．
表3 ソフトウェア詳細設計段階での技法
●ソフトウェア安全性を数値で評価するツール
筆者らはIEC 61508の技法に従っている度合いで，ソフトウェアの安全性を安全度水準（SIL）という形で数値化するツールを開発しました（8）．当該のソフトウェアがSILのどのレベルか，あるいは，目標SILに到達するには設計製作のどこが不足しているかが可視化できます．図7に実際の評価の一例を示します．
図7 ソフトウェアの安全性評価例
SIL1/2/3/4に対する到達度を示す．データ提供：名古屋大学 高田教授，ヴィッツ．
参考・引用＊文献
（1） IEC 61508，Functional Safety of Electrical/ Electronic/Pro
grammable Electronic Safety Related Systems，1998~2000年.
（2） JIS C 0508，電気・電子・プログラマブル電子安全関連系の機能安全，日本規格協会，1999~2000年．
（3） エスカレータ事故：壁とのすき間に首挟み，小3けが，毎日新聞，2007年10月17日．
（4） Nancy G. Leveson；SAFEWARE，System Safety and Com
puters, Addison-Wesley，1995.
（5） 吉岡律夫；ソフトウェアの安全性，検査技術，2005年6月号， 日本工業出版．
（6） IPA/SEC編集；組み込みソフトウェア向け開発プロセスガイド，2007年，翔泳社．
（7） 小川ほか；ソフトウェア開発における安全分析，形式手法，工業標準に焦点をあてた安全関連スキルと教育訓練，SSV，2008年．
（8） 吉岡ほか；ソフトウェア安全性評価方法に関する研究，組み込みシンポジウム，2006年．
（9） 温泉施設爆発，朝日新聞，2007年6月20日．
（10） 温泉施設爆発 空調工事にミス，読売新聞，2008年2月28日．
（11） ジェットコースター脱線事故，朝日新聞，2007年5月6日．
（12） 30年間の遊戯設備での事故死，朝日新聞，2007年5月9日．
よしおか・りつお
（株）日本機能安全
tag: 機能安全
