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

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

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

　前回は、機能安全対応に向けた準備作業に焦点を当てた解説を行いました。今回も準備作業の一環と言えなくはないですが、導入に当たって最初の難関であり、本格的な作業でもある機能安全プロセスの実装（構築）について解説してみたいと思います。

自社の責任範囲

　図1はISO 26262が想定している典型的な製品の基本構成です。

図1　車載システムの典型的な構成

　自社向けに機能安全プロセスを実装しなければならない範囲は、当たり前のことですが、自社で開発する製品が対象となる車載システム（アイテム）の中でどのような位置付けにあるのかに大きく依存します。従って、自動車メーカーであれば、ISO 26262の全Partをカバーするようなプロセスが必要になるでしょう。大手サプライヤは、自動車メーカーとほぼ同等のプロセスが必要になる場合もありますし、システム開発（Part4）以降のプロセスで対応できる場合もあります。

　本連載の対象である中小サプライヤは、図1のサブシステムAやB、サブシステムB1やB2、あるいはハードウェア（HW）やソフトウェア（SW）だけを担当していることが多いかと思います。この場合、必要な機能安全プロセスは、おそらくシステム開発（Part4）以降、場合によってはHW開発（Part5）やSW開発（Part6）を中心としたプロセス^＊1）で対応できるかもしれません。

＊1）もちろん、製品開発の管理や支援を規定したPart2やPart8、Part9のプロセスも必要です。

　機能安全プロセスを実装する上では、自社製品の担当範囲がISO 26262の要求事項のどのPartに当たるのかを明確にしておく必要があります。

　特に中小サプライヤの場合、人的にも予算的にも限られたリソースの中で効率良く対応作業を進めなければなりませんので、ターゲットをきちんと絞り込むことは重要です。あらかじめ、さまざまな製品や開発パターンを想定し、全てのケースに対応できるプロセスを作る戦略も中長期的に見れば意義はあるでしょう。しかし、必要最低限の労力で早急に機能安全対応を実現することに重きを置くのであれば、まずは現状想定できる製品や開発パターンに焦点を絞り、そのケースのみに対応したプロセスを実装する方が現実的です。

　表1は製品開発における担当範囲の典型的パターンを示したものです。

対象	車両／アイテム	システム	サブシステム	HW	SW
対象プロセス	Part3 Concept	Part4 System	Part4 System	Part5 Hardware	Part6 Software
典型的な担当割	OEM	OEM、ティア1	ティア1、ティア2	HWメーカー	SWベンダー
主な作業	アイテム定義、H＆R、ASIL割り付け、FSC策定	TSC策定、システム設計、安全分析、アイテム統合、安全妥当性確認、機能安全アセスメント	TSC策定、システム設計、安全分析、HW/SW統合	HW安全要求、HW設計、安全分析、HW統合	SW安全要求、SW設計、安全分析、SW実装、SWテスト
表1　製品開発の典型的な業務分担

　実際の製品開発においては、表1に示したような、大まかかつ固定された担当分けではなく、製品ごとに作業項目レベルでの割り振りが行われることになると思います。この場合、ISO 26262の各Partの範囲を眺めて自社向けの担当範囲を絞り込むよりも、実際の契約案件あるいは、これまでの実績を基にした自社の担当範囲（責任範囲）を想定して絞り込む方が現実に即したプロセスを作れると思います。