コンセプトフェーズでは、アイテム(車両レベルの機能)を定義し、ハザードの識別や発生しうる危害を想定し、安全な状態を維持するための方針を決定します。

アイテム定義の工程ではアイテムのスコープを明らかにし、機能や制約、 およびアイテムの構成(初期のアーキテクチャ)を定義します。

つまり、既存システムのシステム要求仕様書とシステム設計書をもとにア イテム定義としてまとめれば良いということです。

ただし、アイテム定義では車両レベルの機能を対象としますが、実際には 既存システムがECU単位で定義されている場合が多いと思います。その場合には、複数ECUの仕様から必要な部分を抽出し、車両レベルの仕様として定義する必要があります。

ハザード分析＆リスクアセスメントでは危険事象を特定し、回避・軽減するための安全目標を定義します。

ハザードは改めて分析しても良いのですが、既存システムのFTAやFMEAで分析した故障の影響をハザードとして使用できます。そして、そのハザードに対してリスクアセスメントを実施し、ASILを決定します。

ただし、既存システムでは、故障の影響が車両レベルまで分析はされていないことも多く、追加の分析が必要となる場合があります。

機能安全コンセプトの工程では、安全目標の実現に必要な機能安全要求を導出し、機能安全要求をアイテムのどの構成要素に配置するか定義します。

「ISO26262」はトップダウンの開発プロセスですが、既存システムのフェールセーフ仕様が安全目標を満たすなら、その仕様からどのように危険事象を回避・軽減するか、どのような警告をするかを整理することにより、ボトムアップのアプローチで機能安全要求を定義することができます。

既存システムのフェールセーフ仕様が安全目標を満たさないのであれば、新たなフォールト検出方法や警告方法などを検討する必要があります。