「プロセス実装」のポイント（その1）：機能安全管理プロセス：中小サプライヤのための実践的ISO26262導入（4）（4/4 ページ）

中小サプライヤを対象に、ISO 26262に取り組む上での実践的な施策について紹介する本連載。第4回は、第3回で基礎を解説した「プロセス実装」のうち、Part2の機能安全管理プロセスについて掘り下げる。Part4～6のエンジニアリングプロセスについても、ティア1サプライヤの取るべき対策を紹介しよう。

[DNVビジネス・アシュアランス・ジャパン機能安全部チーム，MONOist] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

エンジニアリングプロセス（Part4～6）

　エンジニアリングプロセスとは、「Part4：システムレベルにおける製品開発」、「Part5：ハードウェアレベルにおける製品開発」、「Part6：ソフトウェアレベルにおける製品開発」といった、設計・開発・テストを中心としたプロセスのことです。前述したように、自社の開発責任範囲によって異なるところで、さまざまななパターンがあると思います。このため、ここでは典型的なパターンを想定して規格要求を絞り込んでから、ポイントとなる要求を掘り下げてみます。

図3　エンジニアリングプロセスの位置付け

ティア1サプライヤA社の場合

　まずは典型的なティア1サプライヤのケースを想定してみましょう。

　ティア1サプライヤのA社の責任範囲はシステムです。自動車メーカーと直接契約しており、開発するシステムは機械部品と電子部品で構成されています。ISO 26262の対象である電子システムは、電子部品メーカーに開発を依頼していて、ハードウェアもソフトウェアも自社では設計・開発・製造を行いません。

　このケースでA社は、Part4のシステムに対する要求を取り込んだエンジニアリングプロセスが必要になりますが、ハードウェア（HW）開発のPart5、ソフトウェア（SW）開発のPart6、そして電子部品の生産に関わるPart7に関しては基本的に対象外となります^＊2）。

＊2）対象外とはいえ、発注先の管理は必要ですから、発注者としてどのようにマネジメントすべきか、そのための管理プロセスはどうするのかという検討は必要です。

　Part4は以下の要求で構成されています。

システムレベルにおける製品開発の開始
技術安全要求の仕様
システム設計
アイテム統合およびテスト
安全妥当性確認
機能安全アセスメント
生産に向けたリリース

　そして、A社の場合、電子システム自体を外部から調達しているため、Part4をさらに絞り込む必要があります。絞り込んだ結果は、図4のようになります。現実の製品開発では、もっと複雑に入り組んでいて、この例のようにきれいに切り分けられるとは限りませんので、前回取り上げたDIAの調整の中で慎重に決める必要があります。

図4　ティア1サプライヤA社の責任範囲とエンジニアリングプロセス

　これらの要求のうち、「アイテム統合及びテスト」や「安全性妥当性確認」、「機能安全アセスメント」などは、基本的に顧客（この場合は自動車メーカー）との調整によって決まるもので、必ずしも対応が必要なプロセスになるわけではありません。しかし、安全確保のための重要な活動になりますので、この連載の後半でもう一度詳しく掘り下げることとし、今回は「技術安全要求の仕様」に焦点を絞りたいと思います。

　技術安全要求は、上位工程からの要求（Part3からの機能安全要求や機能安全コンセプトなど）を基に、具体的にシステムとして実現することを想定した要求に落とし込むための作業です。

　機能安全要求があくまで車両目線（システムをブラックボックス化して、その外側から見て、何をしてほしいのかをまとめる）であるのに対し、技術安全要求はシステム設計者の目線で、上位要求を満たすためには、システム内部での制御、外部との関係性などを分析、整理しなければなりません。このケースでは、発注先の電子部品メーカーにとってのインプットとなるのが技術安全要求となりますから、発注先の設計者が作業に着手できるレベルの情報になっていないといけないわけです。

　技術安全要求には、故障が起きた時でも安全を確保するための機能（安全機構）や潜在故障の回避策、安全状態の詳細化などの作業を含みます。また、対象システムのASILによって作業の違いが出てくるところでもあります。

　多くの場合、製品化済みのシステムには既に安全機構が組み込まれており、大部分の規格要求には対応できると思います^＊3）。しかし、規格が要求している形式で安全要求が階層化、体系化された状態で開発され、その結果として作業成果物（技術安全要求仕様）が存在しているケースは少ないのではないでしょうか。この点が、昨今話題になる「説明責任」、「説明能力」のことで、国内メーカーが抱える典型的課題でもあります。つまり、「規格が要求していることは、十分に検討され、分析しています」と証拠をもって論理的に主張できるかどうかということです。

＊3）故障率をはじめとしたPart5で要求されるHWメトリックについては、これまでのアプローチとは大きく異なります。この点については確実に再分析が必要になると思います。

　この課題は、欧米と日本の開発アプローチの違いからくる面もあり、むやみに規格要求を丸のみするという対応策はお勧めできません。長年築いてきた組織の強みを否定することにもつながるからです。できる限り、設計者を交えて慎重に検討して頂きたいところです。この点を踏まえて、まずは現行製品の仕様を整理し、規格要求に当てはめて、何が足りないのか、それはどこで検討すべきかといった整理から始めてもよいかもしれません。

　また、技術安全要求については、JasParが活動成果としてテンプレートや作成ガイドを一般公開していますので、こちらを参考にするのもよいでしょう（JasParのWebサイト）。

　この後は、発注先の企業が実施する作業に移り、システム設計、ハードウェア開発、ソフトウェア開発へと進みます。そして、発注者としての作業自体は、これまでのやり方と大きく変わるものではないと思いますが、いわゆる「丸投げ」でなく、発注者としての管理業務も明示的に実施しなければなりません。例えば、進捗管理、問題管理などは重要になります。

　発注先の開発が終わると、再び自社の作業「テスト」に戻ってきます。このテストについても、基本的には従来から実施している作業がベースになると思います。とはいえ、細かい規格要求と従来からの作業の対応付けは必要になります。例えば、規格要求にある「要求ベーステスト」は従来から実施しているテストのどれに当たるのか、「フォールト注入テスト（主に安全機構が設計した通りに動くかを見る）」はどんなテストをするのか、といったことの整理をしておくことです。

　また、ISO 26262のエンジニアリングプロセスはV字モデルになっていますから、モノを作りこむ左側の工程と、作り込んだモノを検証する右側の工程が対応することが基本になります。実施するテストが、何を検証するテストなのかが明確になるように整理しておくと分かりやすくなると思います。