最初の難関「プロセス実装」にいかにして挑むべきか：中小サプライヤのための実践的ISO26262導入（3）（2/3 ページ）

中小サプライヤを対象に、ISO 26262に取り組む上での実践的な施策について紹介する本連載。第3回は、ISO 26262の導入に当たって最初の難関となる「プロセス実装」について解説する。「テーラリング」や「DIA（開発インタフェース協定）」という、ISO 26262で頻出する用語についても取り上げる。

[DNVビジネス・アシュアランス・ジャパン機能安全部チーム，MONOist]

契約上欠かせないプロセス領域（1）

　ISO 26262のPart8の5節「分散開発でのインタフェース」には、製品開発に先立って自動車メーカーとサプライヤ、あるいはサプライヤ間で合意しておくべきさまざまな要求事項が規定されています^＊2）。この中には、開発を依頼する上で必要な機能仕様などの技術情報だけでなく、担当範囲やそのプロセス、テーラリング（コラム記事「プロセスのテーラリング」を参照）の内容などの管理的な要素も含まれます。つまり、これから契約する機能安全関連製品では、少なくともここで示され、合意し、割り当てられた担当範囲（責任範囲）の作業に関しては自社の機能安全プロセスとして実装（構築）されている必要があるわけです。

＊2）この合意事項のことを開発インタフェース協定（DIA）と呼んでいます。

プロセスのテーラリング

　テーラリングとは要求されているプロセスを一定の制約範囲の中で順番を入れ替えたり、統合したり、省略したりすることを許す考え方で、プロセスを無制限にカスタマイズすることではありません。当然、テーラリングをする場合は、その正当性を示す必要があります。安易な作業の省略や変更が可能なことを意味するものではありません。

　ここでいうテーラリング内容とは、テーラリングした結果の開発プロセスのことを指します。テーラリングしないのであれば、もともとの機能安全開発プロセスがこれに当たります。作業の統合や省略、支援ツールによる代替などがあれば、その結果（プロセス）がテーラリング内容になります。粒度にもよりますが、一般的には開発計画書や安全計画書にテーラリング内容を表すことになります。

部品認定による再利用

　基本的には以上のような考え方で担当範囲を絞り込み、関連する規格要求事項を満足できるよう機能安全プロセスを定義して行くことになりますが、その上で、いくつかの例外的扱いがありますので、少し触れておきたいと思います。

　通常、機能安全関連製品を開発する場合、対応する規格Partの要求事項を満たしたプロセスで開発作業を実施しなければなりません。しかし、ISO 26262のPart8の12節と13節には、それぞれ「SWコンポーネント認定」と「HWコンポーネント認定」についての条件と認定方法が述べられています。この条件に合致する場合に限り、機能安全関連製品の構成要素であっても、全面的な規格対応をしなくてもよいとされているのです。

　例えば、中間的な複雑さのHWコンポーネントや市販されているソフトウェアライブラリなどは、それぞれ対応するPart（HWであればPart5、SWであればPart6）の要求事項に準拠した製品であることを証明しなくても、ISO 26262のPart8の認定条件を満たし、採用する側の認定があれば機能安全関連製品の中に組み入れてもよいということです。この場合、これらの部品のみを提供しているサプライヤは機能安全プロセスを構築する必要はなくなります。しかしながら、この部品に対する責任は採用する側が持つことになりますので、提供する側としてもできる限りの安全対策をしておく必要はありますし、安全に対するそれなりの論証も必要になります。

　特に、中間的な複雑さのHWコンポーネントについては、何をもって中間的な複雑さとするのかなど、実際には明確な線引きが難しく、非常に悩ましいところです。また、SWコンポーネントについても、再利用技術は長年ソフトウェア業界が取り組んできて、なかなか成果を挙げられていない難しいテーマでもありますので、単にコスト面から見た安易な再利用にならないような考慮が必要でしょう。いずれにしても、認定によるメリットやそれに伴うリスク／責任など、採用側と供給側で慎重に検討する必要があるのではないかと思います。

「ARIANE5」の事故

　欧州宇宙機構（ESA）が1996年に打ち上げた「ARIANE（アリアン）5」ロケットが直後に爆発するという事故がありました。これは、前世代の「ARIANE4」で使われてきた実績のあるソフトウェアを再利用したことが直接の原因であると言われています。修正を加えない完全な再利用でしたが、そのソフトウェアにデータを渡す側のセンサーが新しくなっており、形式が違うデータを受け取ったソフトウェア側が誤作動してしまったために事故が発生しました。もちろん、このような重大なミスをなぜ最後まで気付かなかったのかというプロセス上の問題もありますが、ソフトウェアの再利用に関する非常に重い教訓となった事故です。

　表2は、例外的なものを含めたサプライヤの典型的パターンと、それぞれに必要な機能安全プロセスを整理したものです。

サプライヤ	供給者として必要な機能安全プロセス
HWの基本部品を供給するサプライヤ（例：トランジスタや抵抗器など）	特になし（従来通りのプロセス）
HWコンポーネントとして認定された製品を供給するサプライヤ	ISO 26262：Part8 13節の認定に必要な情報を提供するためのプロセス（例：テスト記録や分析結果など）
SWコンポーネントとして認定された製品を供給するサプライヤ	ISO 26262：Part8 12節の認定に必要な情報を提供するためのプロセス
複雑なHWコンポーネントを供給するサプライヤ	ISO 26262：Part5を中心にした機能安全プロセス
ソフトウェアシステムを供給するサプライヤ	ISO 26262：Part6を中心にした機能安全プロセス
システム（サブシステム）を供給するサプライヤ（例：SWが組み込まれたセンサーなど）	ISO 26262：Part4、Part5、Part6を中心とした機能安全プロセス
表2　供給者に必要な機能安全プロセス