News and Views 2016 Winter / Vol. 16: オートモーティブ

ISO 26262認証にかかるコストを抑える

はじめに

機能安全という考え方は、多くの産業分野で用いられています。それぞれの分野に特化した規格や表現が存在し、その多くは国際電気標準会議が制定したIEC 61508を手本としています。IEC 61508は元来、発電所を対象に制定されたものですが、現在では工作機械や産業ロボットにおいても採用されています。この他に、IEC 62304はIEC 61508をベースに医療機器に向けて制定したもの、ISO 26262は道路を走る車両の電気システムに向けて制定したもの、EN 50128は鉄道における信号方式、制御方式に向けて制定したものなどがあります。

図1. IEC 61508とそれを基に制定された産業別標準規格図1. IEC 61508とそれを基に制定された産業別標準規格

機能安全の定義も、産業分野によって異なります。IEC 61508では、「安全全体の一部であり、システムや装備がその入力に対して正しく動作することに依存する」としています。一般道路を走る車両向けISO 26262では、「電気電子システムの誤動作による障害によって許容することのできないリスクが発生しないこと」となっており、農業用トラクタや耕運機向けISO 25119では、「操作する人や周囲にいる第三者に負傷を負わせる不合理なリスクを生じさせないように動作するシステム」となっています。

ISO 26262とASIL

ISO 26262では、自動車特有のリスクを分析し、ASIL(Automotive Safety Integrity Level)によってリスクの重要度を分類します。ASIL AからASIL D(最も厳しい規定)までの4段階で分類され、各レベルは次の3つの要素に鑑みて決定されます。

  • Severity: 障害発生時の負傷の重症度を、S0(負傷なし)からS3(生死に関わる、致命傷になり得る)までに分類
  • Probability of Expose: 障害が発生する可能性を、E0(発生し得ない)からE3(高い確率で発生)までに分類
  • Controllability: 障害が発生した際に運転者に与えられる制御性を、C0(制御可能)からC3(制御が困難、もしくは制御不可能)までに分類

S、E、Cの各レベルは、搭載される技術に対するものではなく、運転者や他の道路利用者に対する危険性を規定するものであり、ハザード解析(FMEAなど)を用いて決定します。科学のように誰が算出しても一意的に数値化できるものではなく、人や企業により異なる可能性があります。しかしその目的は、決定したレベルに応じて安全確保に必要なシステムを開発することであり、またOEMからサプライヤまでを含めた自動車業界全体で安全に対する対策を標準化することにあります。

自動車業界として機能安全を実現する枠組み

自動車業界は、サプライヤの連鎖で成り立っています。OEMはTier-1サプライヤからコンポーネントを調達し、Tier-1サプライヤはTier-2サプライヤから調達します。ここで言うコンポーネントは、部品やソフトウェアコンポーネントを指しています。

サプライヤとの協業のなかで機能安全を実現するために、ISO 26262ではSEooC(Safety Element out of Context)というコンセプトを定義しています。実のところ、コンポーネントサプライヤは自社のコンポーネントが一部として使われるシステム全体の機能安全コンセプトを知らない場合がほとんどです。しかし、提供するコンポーネントはシステムの機能安全メカニズムを実現する一部となるため、システムが目指すASILに見合うコンポーネント開発が求められます。

図2. BSWを例にしたSEooCに関連するISO 26262のスコープ図2. BSWを例にしたSEooCに関連するISO 26262のスコープ

そこで、サプライヤはコンポーネントが使用されるコンテキストに対する想定を定義、ドキュメント化して提供します。このドキュメントは、セーフティマニュアルと呼ばれます。

セーフティマニュアルでは、以下を記載します。

  • コンポーネントの機能安全のメカニズム
  • コンポーネントによって満たされる安全要件の想定
  • コンポーネントの構成、その他のコンポーネントとの統合、使用における必須事項
  • 統合後に実行しなくてはならないモジュールテスト
  • モジュールにより機能安全に影響を及ぶす可能性のある既知の問題

基本的に、セーフティマニュアルは、コンテキスト外にあるものをどのようにコンテキスト内に統合し、機能安全を実現するべきかを定義するものです。逆に言えば、コンポーネントを使用する顧客に対し、要件/条件を負わせることにもなります。その他の用途として、コンポーネント開発で使用した設計やテストに関するファイル群、すなわちアーティファクトを提供し、顧客が第三者による安全認証を受ける際に役立ててもらうこともできます。

SEooCのコンセプトは、コンポーネントサプライヤとその顧客の双方にとってメリットをもたらします。サプライヤは最終使用を考えずに、コンポーネント実現の技術と品質に注力できます。また顧客は、システムとしての本質的な価値に注力できます。製品のライフサイクルを考慮して、ソフトウェアやハードウェアをサポートする第三者と契約を結ぶことも可能です。カスタムの成果物が必要な場合には、DIA(Development Interface Agreement)を締結します。

DIAでは、安全に関する管理者とそのコンタクト詳細、安全実現に向けた責任と役割分担、やり取りする作業上の成果物や必要とされる時期、データの交換手法、第三者による監査を実施するかどうか、およびその時期などについて、双方で合意します。

機能安全レベルの混在

運転者に対してさまざまな情報を提供するデジタルクラスタを例の1つにとってみると分かりやすいのですが、デジタルクラスタには単にスピードや回転数の表示だけでなく、タイヤの空気圧に関する警告やエンジン室内の温度やバッテリ残量など、さまざまな情報が表示されています。

ここでのスピードや回転数の表示は、最も厳しいASIL Dに当てはまらないかも知れません。しかし、空気圧に関する警告は、表示されなければ制御不可能なC3を含むASILになる可能性があります。機能が集約される部分においては、機能安全レベルも混在する可能性があることになります。

図3. デジタルクラスタの機能集約において安全認証対象の分離を図る図3. デジタルクラスタの機能集約において安全認証対象の分離を図る

図3.に示すクラスタは、左側の安全認証対象となるソフトウェアと右側の高付加価値のグラフィックス表示を1つのSoCで実現しながら、異なる安全レベルが混在する例です。例えば、左側のソフトウェア部分は、SEooCの考えに沿って認証済みRTOSであるNucleusを使い、レンダリングなどを含めて安全認証を受ける必要があるソフトウェア、右側のソフトウェア部分は、Linuxなどの複雑なOSや3次元表示などの複雑なレンダリングを伴う必ずしも安全認証を必要としないソフトウェアに分類されるとします。これらが混在する場合、開発者はSEooCをベースとして認証を受けると同時に、混在する他のシステムからの影響を受けないことをどうやって保証するかに注力します。これはFFI(Freedom From Interference)という考え方で、ソフトウェアにおいては不正なポインタアクセスなどによってメモリが上書きされない、正しくない割込みで時間的遅延が発生しない、データの改ざんがないなどの項目に照らし合わせて開発します。こうすることで、システム全体の安全認証を受けるのではなく、コスト効率良く安全認証を受けられます。

まとめ

日本国内におけるコンポーネントサプライヤとその顧客間では、いわゆる「すり合わせ型」と呼ばれる調整方法によって安全を実現してきた歴史があります。しかしISO 26262、とりわけSEooCコンセプトは、自動車業界全体として安全を実現するために、パートナー間協業の形式化を目指したものと言えます。

コンポーネントを使用する顧客側は、システムとしての安全コンセプト、それにコンポーネントを適合させる責任があります。一方でコンポーネントサプライヤは、求められるASILレベルでSEooCとして提供し、必要に応じてDIAに準ずる責任があります。大切なことは、サプライヤと顧客間での安全への取組みを早期に、できればRFQと同時に開始できれば理想的です。さらに、FFIの考え方を取り入れ、コストを抑えながら安全認証を取得するといったことが重要となってきます。