｢派生開発｣を続けながら、自動車の機能安全規格「ISO26262」に対応する時のポイント
機能安全規格「ISO26262」への準拠に向けて、自動車メーカーや部品メーカーでの対応も佳境を迎えています。製品の『派生開発』と並行して機能安全規格対応を行うにはどうしたらよいのでしょうか？これまでの弊社の経験をもとに説明します。
目次
機能安全規格『ISO26262』とは？
安全であるとは、製品が使用される環境において受容できないリスクがない状態のことです。『機能安全』とは、機能的な工夫を付加することによってこの安全を確保することをいいます。例えば、システムを構成する部品に故障が発生した場合でもそれを検出して危害を回避、軽減するための工夫を導入することで安全な状態を確保できます。
「ISO26262」は自動車分野向けに策定された機能安全規格で、自動車の電気/電子システムにどのような安全機能を組み込むか、その安全機能を実現するためにどのような手順で開発や管理を行うべきかを体系化したものです。
つまり、「ISO26262」に準拠することにより、自社の製品が安全面を十分に考慮して開発されたことや、自社に機能安全を考慮した開発が行える能力があることを示すことができます。
「派生開発」をしながら「機能安全」対応をするポイント
「ISO26262」で示されているプロセスはトップダウンの流れで説明されており、新規開発の場合にわかりやすい内容となっています。
しかし、実際の開発のほとんどが既存システムをベースとした派生開発であるため、現実的にはシステムへの新たな機能の追加、既存機能の変更、性能向上を行うのと同時に、機能安全規格に対応するためには、既存の仕様で規格の要件を満たせるのか、要件を満たすように改善する必要があるのかを見極めなければなりません。『派生開発』と規格対応を同時に行うのは非常に苦労するので、まずは既存のどの成果物が規格で求められる成果物となるのかを把握することが重要です。
「ISO26262」Part3とPart4のプロセスと既存システムの仕様との関係、および規格対応時に改善が必要と思われるポイントについて、実例を用いて解説します。
Part3：コンセプトフェーズ
コンセプトフェーズでは、アイテム(車両レベルの機能)を定義し、ハザードの識別や発生しうる危害を想定し、安全な状態を維持するための方針を決定します。
アイテム定義
アイテム定義の工程ではアイテムのスコープを明らかにし、機能や制約、 およびアイテムの構成(初期のアーキテクチャ)を定義します。
つまり、既存システムのシステム要求仕様書とシステム設計書をもとにア イテム定義としてまとめれば良いということです。
ただし、アイテム定義では車両レベルの機能を対象としますが、実際には 既存システムがECU単位で定義されている場合が多いと思います。その場合には、複数ECUの仕様から必要な部分を抽出し、車両レベルの仕様として定義する必要があります。
ハザード分析＆リスクアセスメント
ハザード分析＆リスクアセスメントでは危険事象を特定し、回避・軽減するための安全目標を定義します。
ハザードは改めて分析しても良いのですが、既存システムのFTAやFMEAで分析した故障の影響をハザードとして使用できます。そして、そのハザードに対してリスクアセスメントを実施し、ASILを決定します。
ただし、既存システムでは、故障の影響が車両レベルまで分析はされていないことも多く、追加の分析が必要となる場合があります。
機能安全コンセプト
機能安全コンセプトの工程では、安全目標の実現に必要な機能安全要求を導出し、機能安全要求をアイテムのどの構成要素に配置するか定義します。
「ISO26262」はトップダウンの開発プロセスですが、既存システムのフェールセーフ仕様が安全目標を満たすなら、その仕様からどのように危険事象を回避・軽減するか、どのような警告をするかを整理することにより、ボトムアップのアプローチで機能安全要求を定義することができます。
既存システムのフェールセーフ仕様が安全目標を満たさないのであれば、新たなフォールト検出方法や警告方法などを検討する必要があります。
Part4：システムレベルの製品開発
システムレベルの開発では、機能安全要求を技術安全要求へと具体化し、機能安全以外の本来の機能と合わせてシステム設計を行います。
技術安全要求の定義
技術安全要求の定義では、実際の物理的なアーキテクチャで機能安全要求を実現することを想定して、機能安全要求を技術的な要求へ具体化します。さらに、技術安全要求をハードウェアで実装するのか、あるいはソフトウェアで実装するのかを特定します。
技術安全要求も機能安全要求と同様に、既存システムのフェールセーフ仕様を利用して、ハードウェア・ソフトウェアのどのような機構で安全を確保しているかを整理することにより、技術安全要求を定義することができます。
システム設計
システム設計では、技術安全要求のシステム構成要素（ハードウェアま たはソフトウェア）への配置を定義します。ここでは単純に技術安全要求を配置するだけでなく、安全機構を本来の機能とは独立して配置することで、ASIL対応に開発コストをかける箇所の局所化を検討します。
今回のサンプルではアクセルペダルセンサを二重化し、センサの故障時にモータ電流を遮断する安全機構を定義しています。更に、本来の機能で故障が起きても安全機構に波及しないよう、安全機構を独立したマイコンに配置し、ASILが求められる箇所をサブマイコンに限定しています。
トレーサビリティの構築
『ISO26262』では上流から下流の成果物まで｢トレーサビリティ｣を構築することが求められるので、ツールを用いてアイテム定義からシステム設計、それ以降の下流工程の成果物までを関連付けて管理します。
下図はその一例です。エンジン制御アイテムで定義した成果物内の要素を個別にツールへ登録し関連付けています。システムレベルの製品開発で定義した安全機構であるサブアクセルペダルセンサにはPart5のハードウェア設計やPart6のソフトウェア設計で作成した成果物の要素などが関連付けられます。
「機能安全」対応・「派生開発」をうまく乗り切るために
『派生開発』で機能安全対応を行うには、全てを一から作成するのではなく、既存システムの成果物を、機能安全プロセスとの関係を把握した上で活用することが重要です。しかし、現場では制御仕様書やソースコードなど下流工程の成果物はあるものの、システム視点での要求やアーキテクチャといった上流工程の成果物が作成・整備されていないことも多いと思います。
各種仕様書がトレース可能な状態で整備されていると、機能安全対応に限らず、『派生開発』で仕様の追加・変更を正確に、かつ効率的に行えます。
規格で求められているからという理由ではなく、開発の品質を高める目的で取り組み、仕様書が開発組織で共有できる状態を維持していただきたいと思います。
コンサルタントが教える成功の秘訣
機能安全というと、特別厳密な作り方や基準が求められているように思われる方も多いのではないでしょうか。しかし、実際には、設計根拠の論理的な説明が必要だったり、トレーサビリティをきちんと取ったりなど、一般の開発においても要求されていることが多くあります。このような基本的なことをきちんと実施することは、組織あるいは個人のスキルアップの機会になる、と前向きに捉えて、チャレンジしていただきたいと思っています。
エクスモーションでは、これまでさまざまな技術の導入と支援を実施してきました。その中で、機能安全にも生かせる実践的なノウハウを数多く持っています。また、現場ごとの状況に合わせた提案も得意としております。
ぜひ、私たちにお任せください。
機能安全iso26262関連サービス
機能安全成果物作成サービス
機能安全規格『ISO26262』のコンセプトフェーズ(Part3)/システム開発(Part4)/ソフトウェア開発(Part6)において、機能安全規格に準拠するために必要となる成果物を作成します。
開発プロセス導入支援サービス
お客様の組織構造や既存の開発プロセスを考慮して、機能安全規格『ISO26262』のコンセプトフェーズ(Part3) / システム開発(Part4) / ソフトウェア開発(Part6) / サポートプロセス(Part8)を実施する開発プロセスをどのようにすればよいかをご提案します。
要求 / 設計仕様書作成サービス
機能安全規格『ISO26262』の入力となる成果物（既存システムの要求仕様書や設計書）が必要な場合、制御仕様書やソースコードといった下流の成果物からリバースしてシステムの要求仕様書や設計仕様書を作成します。
機能安全対応支援iso26262関連ソリューション
｢機能安全｣対応支援
こちらからお願いします
