「機能安全」の導入で何が変わるのか？：ISO 26262 準拠に向けての課題を探る（2/5 ページ）

自動車向けの機能安全規格ISO 26262の策定作業が最終段階に入った。この規格では、機能安全を実現し、それを証明するために必要となる開発プロセスが定められる。では、その新たな開発プロセスは、従来の開発プロセスとどのように異なり、それを適用する際にはどのようなことが課題になるのだろうか。本稿ではまずこの点を明らかにする。加えて、機能安全を実現する上でポイントとなるマイコンについて、各メーカーの取り組みの様子を紹介する。

[本誌編集部 取材班，Automotive Electronics]

従来と異なる開発手法

　ISO 26262は、機能安全の考え方に基づいた、安全な自動車の電子システムを開発するのに有効な手法を体系化したものである。その内容は、現在有償で公開されているドラフトでも、パート1からパート10まで総計約400ページという膨大なものとなっている。紙幅の都合上、そのすべてについて解説するわけにはいかないので、以下では、ISO 26262への準拠を目指す上で知っておくべきことやポイントとなる事柄などを6項目ピックアップして説明することにしよう。

■ハザード分析

　1つ目の項目は、車載電子システムのASIL（Automotive Safety Integrity Level：安全性要求レベル）を評価するハザード分析である。ASILとは、各車載電子システムで起こり得るさまざまな障害（ハザード）を避けるのに達成しなければならない安全性のレベルを、A〜Dの4段階で表現したものだ。Aがいちばん低く、Dがいちばん高い。

表1　ASILのレベル決定表　

　ASILを算出する際には、対象となる障害について、障害によって被る危害の大きさを示す危害度S（severity）、障害と関連する動作の実行頻度を示す発生頻度E（exposure）、障害が発生したときの制御性を示す制御難易度C（controllability）という3つの指標を検討する。SにはS0（危害なし）〜S3（致命傷）、EにはE0（ほぼ発生しない）〜E4（頻繁）、CにはC0（誰でも制御できる）〜C3（制御不可能）までのレベルがある。そして、表1に示すような3つの指標の組み合わせからASILを算出することができる（S0、E0、C0は、ほぼ問題がない状態なので表1には現れない）。

　例えば、「市街地で走行している最中にブレーキが故障する」という障害のASILは、以下のように算出される。危害度は致命傷レベルのS3、市街地ではブレーキが頻繁に使用されることから発生頻度はE4、ブレーキが故障した状態では自動車を制御することはほぼ不可能なのでの制御難易度は最も高いC3となる。これらの指標を表1に当てはめると、ASILはDであることがわかる。

　ハザード分析では、このようにして車載電子システムのさまざまな障害についてASILの評価を行う。ハザード分析は、自動車メーカーにおける自動車開発プロセスの最初の段階である構想段階で行われなければならない。

■開発手法におけるギャップ

図1　自動車開発のV字プロセスにおける要素（提供：NEC）　

　図1は、自動車開発のV字プロセスにおいて、自動車メーカーの車両レベルでの要件設計から、ティア2サプライヤが行う車載電子システムのソフトウエア開発までの要素を分解して示したものだ。

　ISO 26262という規格は、基本的に、最終製品である車両が準拠すべきものだ。そういう意味では、ISO 26262に準拠する際の対応の主体は、自動車メーカーになる。ただし、車両レベルでの最終的な評価結果だけでなく、車両開発にかかわるすべてのプロセスについてさまざまな規定が存在している。つまり、自動車メーカーだけでなく、プロセスチェーンにかかわるすべてのサプライヤが、ISO 26262で規定されているプロセスに準拠する必要があるわけだ。これに関連して、NECの坪井氏は、「ISO 26262に準拠するためには、プロセスチェーン全体で、自動車メーカーと各サプライヤがどのようなことを行わなければならないかという責任範囲を明確にする必要があるだろう」と指摘している。

　ISO 26262の規格策定が行われている欧州では、自動車開発のプロセスチェーンにおける責任範囲が比較的明確に定められている。名古屋大学大学院 情報科学研究科教授の高田広章氏は、「欧州では、自動車メーカーが要求仕様設計を行い、ティア1サプライヤがその仕様に基づくシステムを開発するというように、役割分担がはっきりと分かれている」と語る。また、ボッシュの先端技術開発部で電気＆電子システム統合推進グループのセクション・マネージャーを務める越智純一氏も、「欧州の自動車メーカーは、開発のプロセスチェーンにおける責任の所在をはっきりさせるために、サプライヤとの間でDIA（Development Interface Agreement：開発協働契約書）を結んでいる」と説明する。このようなこともあって、欧州では、ISO 26262に準拠した開発プロセスは導入しやすい。

　一方、日本の自動車業界では、「すり合わせ開発」と呼ばれる開発手法が主流である。すり合わせ開発では、自動車メーカーとサプライヤとの間で密接なやりとりを行うことにより、高い品質を達成できるというメリットが得られると言われている。しかし、どこまでが自動車メーカーの責任範囲で、どこからがサプライヤの責任範囲なのかが切り分けされていないと言うこともできる。つまり、日本特有のすり合わせ開発は、ISO 26262に準拠した開発プロセスの導入に対する障壁になってしまうのだ。

図2　ISO26262への準拠による安全性への効果（名古屋大学大学院高田広章氏の資料を基に作成）　赤で示すように、現状、高いレベルで真の安全性を実現できていない自動車メーカーであっても、ISO26262に準拠することにより、真の安全性を高めることができるし、証明できる安全性も得ることができる。一方、現在の日本の自動車メーカーは、緑色の丸印で示すように、すでに高いレベルの真の安全性を実現できているが、証明できる安全性を持っていない。目指すべきは、真の安全性と証明できる安全性の向上である（?）。日本の自動車メーカーがISO26262に準拠する場合には、真の安全性のレベルを落とさずに、証明できる安全性も得られるような開発プロセスを導入する必要がある（?）。導入方法を誤ると、証明できる安全性は得られるものの、従来実現していたレベルよりも、真の安全性を落としてしまう可能性がある（?）。

　日本アイ・ビー・エムでISO 26262のコンサルティングを担当するシニアマネージングコンサルタントの片井正行氏は、「すり合わせ開発というのは、最終製品の高い品質を達成することに向けて、プロセスチェーン全体のベクトルを合わせる開発手法だ。しかし、すり合わせ開発では、どこからどこまでを誰が責任を持って行ったのか不明確であるため、その高い品質によって達成した安全性をどのようにして作り上げたのかを第三者に示すことが難しい。ISO 26262では、安全性を証明する上で、責任範囲が明確であることが前提となるため、この点が、すり合わせ開発に同規格を適用する上での課題になってしまう」と指摘する。

　このように、日本の自動車業界で用いられている開発手法は、ISO 26262に準拠しやすいものだとは言えない。だからといって、欧州的な開発手法を新たに導入することも現実的ではない。高田氏は、「日本の自動車業界の開発手法によって、真の安全性（最終的にその製品が達成した安全性）を高いレベルで確保できていることは確かだ。今後は、その長所を生かしながら、ISO 26262に準拠する方法を、各自動車メーカーが考えていかなければならないだろう（図2）。個人的には、プロセスチェーンに携わるすべての技術者が、最終製品に対する責任を持っているという意識を共有しながらも、実際の責任範囲は明確にするというアプローチでなければ、日本の長所は生かせないのではないかと見ている」という。また坪井氏は、「機能安全に対応する開発ツールを導入するなどして一気に開発手法を変えることで、ISO 26262に準拠することは可能だ。しかし、そういった急激な変化に、プロセスチェーン全体が即座に対応できるとは言えない。加えて、日本で用いられている開発手法の基底にある考え方は、一種の企業文化のようなものでもある。このようなことも大切にしながら、ISO 26262に準拠するためのスケジュールを立てて、徐々に適合範囲を広げていくほうが問題は起きにくいのではないか」と述べる。