• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版

HOMEスキルアップ識者が指南、スキルアップの勘所 > ソフトウエア開発のISO26262対応、利点とは何か?

識者が指南、スキルアップの勘所

ソフトウエア開発のISO26262対応、利点とは何か?

ビジネスキューブ・アンド・パートナーズ シニアコンサルタント 山内 誠 氏

  • 2016/06/03 17:42
  • 1/2ページ
ビジネスキューブ・アンド・パートナーズ シニアコンサルタント 山内 誠 氏
[画像のクリックで拡大表示]

 車載電子システムに求められる機能安全規格「ISO 26262」への対応が日本の製造業で本格化し始めた。中でも、ソフトウエアの開発プロセスの重要性が増している。「技術者塾」は「ISO 26262 実践セミナー ソフトウエア開発編」(2017年8月4日)の講座を開講する。講師であるビジネスキューブ・アンド・パートナーズシニアコンサルタントの山内 誠 氏に、ISO26262とは何か、利点は何か、さらに失敗事例などを聞いた。(聞き手は近岡 裕)

──初めて学ぶ人にも分かるように、改めて基本的なところから教えてください。機能安全規格「ISO 26262」とは何であり、何を目指すものなのでしょうか。また、ISO 26262とソフトウエア開発プロセスとの関係を分かりやすく教えてください。

山内氏: ISO 26262は、一言で言えば「車載電子システム向けの機能安全規格」です。

 自動車は今、あらゆる機能が車載電子システムによって実現されています。車載電子システムの増加が自動車の利便性や快適性を高める一方で、そこに内在する不具合や故障によって、人に危害を与える可能性も高まっています。

 車載電子システムの分野に限らず、電子システムに起因した安全上のリスクを回避したり低減したりするための技術の総称が「機能安全」です。ISO 26262は、安全性の高い車載システムを開発するための実施事項や達成事項を体系的にまとめたもの、という位置づけです。

 このISO 26262の「要求事項」を大まかに分類すると、[1]危険な事象につながる故障や誤動作を抑制する「安全設計」に関するものと、[2]同じく危険な事象につながる設計の誤りや問題の見逃しを抑制する「プロセスアプローチ」に関するもの、が存在します。

 ソフトウエア開発プロセスに関しては、このうちの後者(プロセスアプローチ)に関連する考え方になります。ただし、設計されたソフトウエアが上位システムの安全性を脅かさないことを裏付けるために、前者(安全設計)の取り組みも必要となります。

──ISO 26262に対応すると、誰にとってどのようなメリットがあるのでしょうか。

山内氏:ISO 26262への対応そのものが、完成車メーカーから部品メーカーに対して取引条件のような形で要求されます。そのため、「部品メーカーがビジネスを獲得する条件を満たす」ということが直接的なメリット、あるいは目的となります。

 しかし、私としては、ISO 26262への対応によって得られるメリットをもっと本質的に捉えてほしいと思っています。

 前述の安全設計やプロセスアプローチといったISO 26262の多岐にわたる要求事項を全て満たすことは、当然ながら楽なことではありません。しかし、安全性を向上させ、その根拠を明確に示すことができるようになることは、「国際的な競争を勝ち抜くために非常に重要なこと」であると考えています。

──逆に、ISO 26262に対応しない場合は、どのようなデメリットがあるのでしょうか。

山内氏:先にも述べましたが、ISO 26262に対応しないということは、直接的には「完成車メーカーの取引条件を満たさない」ということになります。従って、ビジネスを継続する上での大きなデメリットとなってしまいます。

 加えて、「安全性の根拠を明確に示すことができない」状態にもなります。そのため、市場で製品事故が発生した際に、企業としての信頼性を大きく失うことにもつながりかねないと思います。

──ISO 26262に対応するとはどういうことでしょうか。イメージを知りたいと思います。具体的な事例を挙げて、どのように対応させていくのか教えてもらえませんか。

山内氏:私自身、以前は開発者として製品に関する安全設計を担当していました。このときに、「ISO 26262が要求しているレベルは、それをはるかに超える厳しさである」ということを最初の印象として記憶しています。それでも、対応目標を明確に定め、それに向けて段階的に改善を展開することで対応を進めることができました。

 ISO 26262に対応する前から、センサーが故障した際の振る舞いなどについては、製品の基本機能を侵害しないことをFTA(Fault Tree Analysis:故障の木)とFMEA(Failure Mode and Effect Analysis:故障モード影響解析)を使って確認していました。しかし、この際の着眼点は、センサー故障時に「センサーを停止する」といった制御を明確にする意味合いが強く、故障時の制御が安全か否かという観点では明確に分析を行えていませんでした。

 その後、ISO 26262への対応を進める中で、センサー故障時の制御が安全目標を侵害していないことを観点とする分析を新たに行いました。これにより、「センサーを停止する」で終わっていた分析を、「安全状態になるようにセンサーを停止する」ところまで分析を行い、設計を見直しました。

 設計の見直しと簡単に言いましたが、最初は安全を“後付け”で考えてしまい、システム構成を複雑にしてしまった失敗もありました。これは安全性ではなく、信頼性を高めていただけでした。

 結果的に、製品アーキテクチャーを根本的に見直し、基本機能と安全機能を融合させることで、基本機能を損なうことなく安全性の高い製品を開発することができました。ISO 26262への対応は、私に重要な気付きを与えてくれたと言えるでしょう。

 今回の技術者塾の講座では、私自身がISO 26262への対応をきっかけに気付いた設計のノウハウなどもご紹介していきたいと考えております。

おすすめ