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

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

■ソフト開発プロセスの定義

　ISO 26262では、車載電子システムを構成するハードウエアとソフトウエアで起きる故障について、それぞれ異なる定義を行っている。ハードウエアの故障は、部品や材料の劣化などによって、偶発的に発生するものとしてとらえられている。このため、統計的手法で故障の発生頻度を推定することによって、安全を確保することになる。高田氏は、「ハードウエアの故障については、これまで自動車業界で行ってきたFMEA（Failure Mode and Effect Analysis）などの応用で対応することができる。このため、ハードウエア開発において規格準拠を目的として大幅な変更を迫られることはないだろう」と語る。

　これに対して、ソフトウエアの故障は、設計の誤りや検証漏れなど、人間が開発プロセスにおいて作り込んでしまうものだとされている。ISO 26262では、このような人為的な故障を回避するための開発プロセスを定義している。

　すでに、ISO 26262への準拠に役立つソフトウエア開発プロセスのフレームワークとして知られているものがある。それは、CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）とAutomotive SPICE（以下、A-SPICE）の2つだ。特に、2005年に発表されたA-SPICEは、ISO 26262との親和性が高いとされている。

　NECのコンサルティング事例によれば、既存のソフトウエア開発プロセスへのA-SPICEの適用については、1年間あれば、旧開発プロセスのほとんどの領域をカバーすることが可能だという。ただし、「ISO 26262では、A-SPICEがカバーしていないモデルベース開発や形式手法などについても対応しなければならない」（坪井氏）ことには注意する必要がある。

■技術情報の管理

　ISO 26262は、開発プロセスの全体に対して、機能安全に関する技術情報を管理するためのプロセスも規定している。開発プロセスに携わるすべての技術者に正しい技術情報を提供できるようにしなければ、最終的な車載電子システムの機能安全を確保することはできないからだ。　

　技術情報の中でも重要なのが、開発するシステムに関するすべての情報の源となる要求仕様書である。しかし、「日本の自動車メーカーの要求仕様書は、きちんとした内容になっていないことが多い。要求仕様書として、C言語で記述したプログラムのソースコードを渡されたことがあるというサプライヤもいるくらいだ。要求仕様書と、その変更履歴がはっきりしていなければ、第三者は、開発したシステムの機能安全がどのように達成されたかを確認することはできない」（高田氏）という。

　米IBM社は、ISO 26262に準拠する上で役立つツールとして、要求管理ツール「Rational DOORS」、ソフトウエア開発におけるデータ連携プラットフォーム「Rational Team Concert（RTC）」などを展開している。日本アイ・ビー・エムでソフトウエア事業 ラショナル事業部の事業部長を務める渡辺公成氏は、「多くの場合、機能安全に関する技術情報を管理するプロセスというのは、新たに追加されるものだ。しかし、プロセスが増えるからといって、開発人員を増やすことは難しい。当社のツールを使えば、このプロセスを効率的に管理することが可能になる。DOORSでは、要求仕様書のデジタル化を行ったり、その変更履歴を容易に追跡したりすることができる。また、RTCを導入すれば、メカ系システムの開発に用いられるPDM（製品情報管理）ツールのように、ソフトウエアの各コンポーネントの情報の管理を行えるようになる」と強調する。

■人員整備と体制構築

図3　ISO26262に対応するための開発体制（提供：ボッシュ）　RobertBosch社における事例を示している。

　ここまで紹介した取り組みに加えて、ISO 26262は、機能安全に関する事柄を統括する人員の配置や、専門の部署の設置にも言及している。

　ドイツRobert Bosch社は、他社に先駆けてISO 26262に対して積極的な取り組みを行っている企業として知られている。同社は、各事業部に、製品の安全に関する代表者を置くとともに、ISO 26262の各パートで記述されている内容を担当する専門家も用意している（図3）。また、各事業部には、その事業部のことと、ISO 26262の1つのパートのことをよく理解している人員も配置する。そして、製品の安全に関する代表者は、各事業部を横断する「RB Safety Team」を構成し、ISO 26262の各パートの専門家も「Team ISO 26262」として連携する。さらに、各事業部に配置したISO 26262の1つのパートについてよく知る人員は、そのパートの専門家を軸にして、事業部を横断する「Expert Team」としての連携も行う。ISO 26262に関する決定については、各事業部のトップから構成される「RB Safety Control Board」が最終的な認可を行うことになる。Robert Bosch社が、ISO 26262に準拠するための体制に割いている人員数は、約120人に達する。

　日本法人ボッシュの越智氏は、「われわれ日本法人も、ドイツ本社と連携することによって、ISO 26262への対応を進めることができている。日本の自動車業界に対しては、欧州におけるISO 26262関連情報を積極的に提供することを、当社の存在感を高めるための一助としたい」と述べている。

■求められる証明

　現在、日本の自動車業界におけるISO 26262への取り組みは、同規格に関する情報収集を終えて、どのように対応するか具体策を検討する段階に入っている。一方、同規格の策定が進められている欧州では、機能安全を実現するための開発プロセスを用いた試作開発を行う段階や、Robert Bosch社のように会社全体で組織的に取り組む段階に入っている企業も多い。

　ドイツの認証機関TÜV SÜD社の日本法人であるテュフズードジャパンのオートモーティブ部で機能安全エンジニアを務める竹市正彦氏は、「欧州の中でもドイツの自動車業界は、機能安全に対する取り組みが最も進んでいる。すでに多くの企業が、ISO 26262のベースとなっているIEC 61508に準拠した開発プロセスを採用している。そして、ISO 26262が正式に規格化されれば、ドイツの自動車メーカーは、同規格に準拠できるようにすることをサプライヤに要求するだろう。つまり、ドイツの自動車メーカーに部品を納入している日本のサプライヤにとって、ISO 26262への対応は急務なのだ」と語る。

　ドイツの自動車メーカーは、日本のサプライヤに対して、納入される電子システムを用いて開発した自動車をISO 26262に準拠させるのに必要な証明（エビデンス）を求めることになる。竹市氏は、「TÜV SÜD社は、ドイツ運輸建設省自動車局（KBA）が機能安全規格の認証を行うことを認可している機関だ。このような機関の認証があれば、ドイツの自動車メーカーもISO 26262に対する証明として認めてくれる。日本法人である当社としては、このような観点から日本のサプライヤの欧州市場での事業展開を後押しできると考えている」と説明する。

　また、ISO 26262の認証を取得する際に、ソフトウエアの開発に用いるツールが問題になる可能性がある。これについて竹市氏は、「例えば、独自に開発したツールを利用していると、その開発ツールがISO 26262に対応できるものであることを確認する作業から始めなければならなくなる。その場合、認証取得に時間がかかるだけでなく、結果として認証を取得できない可能性すらある。そこで、TÜV SÜD社は、開発したソフトウエアをISO 26262に準拠させる仕組みを持ったツールを認定している。このようなツールを用いれば、ツールに関する検証が不要になるので、認証を取得しやすくなるだろう」と説明した。