前回のその2に続いて解説します。
6. ソフトウェアの安全性・信頼性
機能安全は元は化学工場の事故などプラントの安全性に根ざしており、機械構造物などのハードウェアを対象にして作られてきたものです。ハードウェア故障は確率的に捉えることができるため、機能安全は確率論がベースとなっていますが、ソフトウェアも含めた機能安全をどのように考えるかについては問題も指摘されてきました。
自動車のISO26262が制定された際にも「従来のIEC61508は、ハードウェアの確率論的故障に偏重している」という批判も出され、近年のソフトウェアを含むコンピュータ制御の実態に合っていないと言われてきました。
こうした経緯もありIEC61508もEd2でかなり改訂され、確率論だけでなく決定論的な考え方が取り入れられてきました。ソフトウェアの故障（つまりバグ）は確率論的に発生するわけではないからです。そこでIEC61508などの規格では、プロセスをきちんと定めそれを確実に行うことで保証しようということになっています。
実際問題ソフトウェアの信頼性、安全性はどう担保できるのか、学者や研究者の間でもいろいろなことが言われていますが、実際のものづくりサイドの感覚としては、ソフトウェアはどんなにテストしても100％の信用があるとは言い難いとの前提で扱われていると思います。同じプログラムで制御されるのであれば、ハードウェアのように冗長構成をとっても同じようにバグが現出するはずであり、同じプログラムを並べても無意味なので、例えばNバージョンプログラムやハードウェアとの組合せによるダイバーシティ（多様性）で考えることになります。ですが、当然コストもかさみますから、これが要求されるものは限られています。
7. ビジネスとしての機能安全
機能安全は認証機関が中身を検査してお墨付きを与えるというスキームになっていて、TUV（ドイツ）、SGS（スイス）、DNV（ノルウェー）などが知られています。これは国の法令や規制というわけではなく、あくまでも専門機関としての認証なのですが、万が一事故などで訴訟沙汰になった場合に備えた一種の保険のような意味合いもあります。
一方この機能安全の認証には長い時間と高額な費用が発生するため、こうした認証機関としては有力なビジネスとなっているという面もあります。また近年の傾向としてサイバーセキュリティ対策もクローズアップされるようになってきています。セキュリティ対策は場合によっては安全機能に影響を与える可能性もあるため、その取り扱いに関しては今後も注視する必要があるでしょう。
次回に続きます。
