1. HOME
  2. コラム
  3. コラム
  4. 「派生開発」を続けながら、自動車の機能安全規格「ISO26262」に対応する時のポイント

「派生開発」を続けながら、自動車の機能安全規格「ISO26262」に対応する時のポイント

  • LINEで送る
  • このエントリーをはてなブックマークに追加
「派生開発」を続けながら、自動車の機能安全規格「ISO26262」に対応する時のポイント

機能安全規格「ISO26262」への準拠に向けて、自動車メーカーや部品メーカーでの対応も佳境を迎えています。製品の『派生開発』と並行して機能安全規格対応を行うにはどうしたらよいのでしょうか?これまでの弊社の経験をもとに説明します。

機能安全規格『ISO26262』とは?

安全であるとは、製品が使用される環境において受容できないリスクがない状態のことです。『機能安全』とは、機能的な工夫を付加することによってこの安全を確保することをいいます。例えば、システムを構成する部品に故障が発生した場合でもそれを検出して危害を回避、軽減するための工夫を導入することで安全な状態を確保できます。

「ISO26262」は自動車分野向けに策定された機能安全規格で、自動車の電気/電子システムにどのような安全機能を組み込むか、その安全機能を実現するためにどのような手順で開発や管理を行うべきかを体系化したものです。

つまり、「ISO26262」に準拠することにより、自社の製品が安全面を十分に考慮して開発されたことや、自社に機能安全を考慮した開発が行える能力があることを示すことができます。

「派生開発」をしながら「機能安全」対応をするポイント

「ISO26262」で示されているプロセスはトップダウンの流れで説明されており、新規開発の場合にわかりやすい内容となっています。

しかし、実際の開発のほとんどが既存システムをベースとした派生開発であるため、現実的にはシステムへの新たな機能の追加、既存機能の変更、性能向上を行うのと同時に、機能安全規格に対応するためには、既存の仕様で規格の要件を満たせるのか、要件を満たすように改善する必要があるのかを見極めなければなりません。『派生開発』と規格対応を同時に行うのは非常に苦労するので、まずは既存のどの成果物が規格で求められる成果物となるのかを把握することが重要です。

「ISO26262」Part3とPart4のプロセスと既存システムの仕様との関係、および規格対応時に改善が必要と思われるポイントについて、実例を用いて解説します。

Part3:コンセプトフェーズ

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

車載開発~「派生開発」を続けながら機能安全規格「ISO26262」に対応するには:Part3:コンセプトフェーズ|【3-5:アイテム定義】システム要求仕様書・システム設計書⇒システムのスコープを明らかにする⇒アイテム定義(機能一覧・非機能要求一覧・アイテム構成)⇒【3-7:ハザード分析およびリスクアセスメント】FMEA・FTA⇒ハザードを識別する⇒ハザード定義⇒危険事象を決定する⇒危険事象⇒危険事象に対してASILを決定する⇒ASILの決定⇒危険事象に対する安全目標を決定する⇒安全目標・安全状態⇒【3-8:機能安全コンセプト】システム要求仕様書・システム設計書⇒機能安全要求を導出する⇒機能安全要求⇒機能安全要求を対応するアーキテクチャ要素に配置する⇒機能安全コンセプト

アイテム定義

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

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

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

車載開発~「派生開発」を続けながら機能安全規格「ISO26262」に対応するには:Part3:コンセプトフェーズ(アイテム定義)【エンジン制御アイテム】機能要求一覧:①トルクの発生(ドライバによるアクセルペダルの踏み込み量に従って、エンジンでトルクを発生させる)②アイドルエンジン回転数の維持(アイドル中、適切なエンジン回転数を維持する)/非機能要求一覧:①環境(可能な限り燃費を向上させること)/アイテムの構成:アクセルペダル-エンジン制御システム(アクセルペダルセンサ-エンジンECU(-メインマイコン(信号変換回路:メイン-CPU(アクセル開度率算出部-目標トルク算出部-スロットルパルプ制御部))-モータ制御回路)-スロットルモータ)-スロットルパルプ/エレメントの説明:①アクセルペダル(車両を加速させるためにドライバが踏むペダル)②アクセルペダルサンサ(アクセルペダルの踏み込み量を検知するセンサ)/制約/法規/既知のハザード

ハザード分析&リスクアセスメント

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

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

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

車載開発~「派生開発」を続けながら機能安全規格「ISO26262」に対応するには:Part3:コンセプトフェーズ(ハザード分析&リスクアセスメント)【FMEA】アクセルペダルセンサ:オープン(センサ値が0から変化しなくなる⇒意図せず減速する)ショート(センサ値が最大値から変化しなくなる)⇒センサを二重化する【リスクアセスメント結果】HZD.ENG.01:意図せず加速する~高速道路の走行中、先行車が存在するE4:(高速走行中に意図せず加速し、先行車と衝突する⇒ブレーキ操作で減速できる:C2⇒高速走行中であり危害は大きい:S3⇒ASIL:C)/信号待ちで停車している状態からの発進時:E4:(発進時、ブレーキペダルを放した時に意図せず先行車よりも加速することで、先行車と衝突する⇒ドライバの足がブレーキをすぐに踏める位置にあるため、ブレーキで回避できる:C1⇒速度は大きくないため危害は少ない:S1⇒ASIL:QM)【安全目標一覧】HZD.ENG.01:意図せず加速する~HZE.ENG.01:高速走行中に意図せず加速し、先行車と衝突する~ASIL:C~SG.ENG.01:意図しない加速が発生しないようにする~SS.ENG.01:暴走しない駆動力に制限している状態

機能安全コンセプト

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

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

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

車載開発~「派生開発」を続けながら機能安全規格「ISO26262」に対応するには:Part3:コンセプトフェーズ(機能安全コンセプト)【機能安全要求仕様】安全目標SG.ENG.01:意図しない加速が発生しないようにする、ASL:C、【機能安全要求】FSR.ENG.01:意図しない加速を引き起こすフォールトを検出した場合、急加速が発生せず退避走行ができるような所定のエンジントルクを発生するようにする、ASIL:C、理由:急加速を防ぐことで事故に至らないようにするため、説明:退避走行とは、フォールトが発生した時に安全な場所まで車を運転することである<フォールトの検出>【アクセル踏込量のフォールト検出】~機能安全要求~FDR.ENG.01.01:ドライバのアクセルペダルの踏み込み量を正しく取得できなくなるようなフォールトを検出する、ASIL:C、理由:フォールトにより誤ってドライバが加速を要求していると判定してしまうと、加速が発生するように制御してしまうため、説明:例えば、アクセルペダルセンサにフォールトが発生するとドライバのアクセルペダルの踏み込み量を正しく取得できなくなる、配置するエレメント:アクセルペダル、エンジンECU【エンジントルク推定のフォールト検出】~機能安全要求~FSR.ENG.01.02:現在のエンジントルクを正しく推定できなくなるようなフォールトを検出する、ASIL:C、理由:誤って、実際発生しているよりも少ないエンジントルクが発生していると判定することで、エンジントルクを増加するように制御してしまうため、説明:例えば、スロットルポジションセンサーにフォールトが発生するとエンジントルクを正しく推定できなくなる、配置するエレメント:エンジンECU<機能の縮退>【エンジントルクの抑制】~機能安全要求~FSR.ENG.01.11:エンジンを制御することで、急加速が発生せず退避走行ができるような所定のエンジントルクを発生するようにする、ASIL:C、理由:急加速を防ぐことで事故に至らないように、かつ安全な場所まで退避できるようにするため、説明:エンジントルクを発生しないようにするとエンジンが停止して退避走行ができなくなる、配置するエレメント:エンジンECU

Part4:システムレベルの製品開発

システムレベルの開発では、機能安全要求を技術安全要求へと具体化し、機能安全以外の本来の機能と合わせてシステム設計を行います。

車載開発~「派生開発」を続けながら機能安全規格ISO26262に対応するには:Part4:システムレベルの製品開発|【Part3成果物】安全目標、安全状態。機能安全コンセプト(機能安全要求)。アイテム定義。システム要求仕様書、システム設計書⇒【4-6:技術安全要求の定義】技術安全要求を定義する、安全環境を定義する、ASILの分解的に要求を分解する、潜在的な故障の回避策を検討する⇒技術安全要求仕様:技術安全確認要求仕様、環境条件、制約、外部インタフェース、安全機構、でコンポジション要求(独立性要求)、潜在的故障の回避策⇒【4-7:システム設計】システマティック故障を特定する⇒システマティック故障発生原因⇒故障回避策の検討と複雑性回避の検討を行う⇒システマティック故障回避検討結果。ランダムハードウェア故障を検出し、制御する手段を特定する⇒故障率・診断率の目標値、システム基本設計(安全機構以外)、ランダム故障検出方法⇒システム構成を検討し、要求をハード・ソフトに割り当てる⇒システム設計仕様(技術安全コンセプト)、ハード・ソフトインタフェース仕様←FMEA、FTA、システム設計書

技術安全要求の定義

技術安全要求の定義では、実際の物理的なアーキテクチャで機能安全要求を実現することを想定して、機能安全要求を技術的な要求へ具体化します。さらに、技術安全要求をハードウェアで実装するのか、あるいはソフトウェアで実装するのかを特定します。

技術安全要求も機能安全要求と同様に、既存システムのフェールセーフ仕様を利用して、ハードウェア・ソフトウェアのどのような機構で安全を確保しているかを整理することにより、技術安全要求を定義することができます。

車載開発~「派生開発」を続けながら機能安全規格ISO26262に対応するには:Part4:システムレベルの製品開発(技術安全要求の定義)技術安全要求仕様【機能安全要求】FSR.ENG.01.01:ドライバのアクセルペダルの踏み込み量を正しく取得できなくなるようなフォールトを検出する。ASIL:C【技術安全要求】TSR.ENG.01:アクセルペダルセンサにセンサ値が異常な値になるようなフォールトが発生していることを検出する。ASIL:C。理由:アクセルペダルセンサにフォールトが発生した時に、急加速を発生させないようにするため。説明:センサにフォールトが発生すると、信号が入力されなかったり、実際の踏み込み量とは無関係の値が入力されたりする。<H/Wへの要求:アクセルペダル踏み込み量の計測>【サブアクセルペダルセンサの搭載】~技術安全要求~TSR.ENG.01.01:システムに、メインのアクセルペダルセンサとは別にサブのアクセルペダルセンサを搭載する。ASIL:C。配置するエレメント:エンジンECU・サブアクセルセンサ【メインアクセルペダルセンサによるアクセルペダル踏込量取得】~技術安全要求~TSR.ENG.01.02:メインアクセルペダルセンサで、ドライバによるアクセルペダルの踏み込み量を計測する。ASIL:A(C)。配置するエレメント:メインアクセルセンサ【サブアクセルペダセンサによるアクセルペダル踏込量取得】~技術安全要求~TSR.ENG.01.03:サブアクセルペダルセンサで、ドライバによるアクセルペダルの踏み込み量を計測する。ASIL:B(C)。配置するエレメント:サブアクセルセンサ<H/Wへの要求:デジタルデータへの変換>【メインアクセルペダルセンサ値のデジタルデータ変換】~技術安全要求~TSR.ENG.01.11:メインアクセルペダルセンサの値をデジタルデータに変換する。ASIL:C。配置するエレメント:信号変換回路(メイン)【サブアクセルペダルセンサ値のデジタルデータ変換】~技術安全要求~TSR.ENG.01.12:サブアクセルペダルセンサの値をデジタルデータに変換する。ASIL:C。配置するエレメント:信号変換回路(サブ)

システム設計

システム設計では、技術安全要求のシステム構成要素(ハードウェアま たはソフトウェア)への配置を定義します。ここでは単純に技術安全要求を配置するだけでなく、安全機構を本来の機能とは独立して配置することで、ASIL対応に開発コストをかける箇所の局所化を検討します。

今回のサンプルではアクセルペダルセンサを二重化し、センサの故障時にモータ電流を遮断する安全機構を定義しています。更に、本来の機能で故障が起きても安全機構に波及しないよう、安全機構を独立したマイコンに配置し、ASILが求められる箇所をサブマイコンに限定しています。

車載開発~「派生開発」を続けながら機能安全規格ISO26262に対応するには:Part4:システムレベルの製品開発(システム設計)機能安全対応後のシステム設計書構造図:アクセルペダル⇒エンジン制御システム(ASILなし:アクセルペダルセンサ、ASILあり:サブアクセルペダルセンサ⇒エンジンECU(⇒メイン(サブ)マイコン(ASILなし:信号変換回路(メイン)ASILあり:信号変換回路(サブ)⇒CPU(ASILなし:アクセル開度率算出部・目標トルク算出部・スロットルバルブ制御部、ASILあり:フォールト検出部・フェールセーフ判定部))⇒ASILなし:モータ制御回路、ASILあり;モータ電流遮断回路)スロットルモータ)→スロットルバルブ

トレーサビリティの構築

『ISO26262』では上流から下流の成果物まで「トレーサビリティ」を構築することが求められるので、ツールを用いてアイテム定義からシステム設計、それ以降の下流工程の成果物までを関連付けて管理します。

下図はその一例です。エンジン制御アイテムで定義した成果物内の要素を個別にツールへ登録し関連付けています。システムレベルの製品開発で定義した安全機構であるサブアクセルペダルセンサにはPart5のハードウェア設計やPart6のソフトウェア設計で作成した成果物の要素などが関連付けられます。

車載開発~「派生開発」を続けながら機能安全規格ISO26262に対応するには:『トレーサビリティ』の構築【ISO26262 Part3】<アイテム>エンジン制御アイテム⇒<エレメント>アクセルペダルセンサ⇒<ハザード>意図せず加速する⇒<安全目標>意図しない加速が発生しないようにする⇒<機能安全要求>ドライバのアクセルペダルの読み込み量を正しく取得できなくなるようなフォールトを検出する⇒【ISO26262 Part4】<技術安全要求>2つのアクセルペダルセンサで読み込み量を計測し両者の値を比較することでフォールトを検出する⇒<技術安全要求>システムに、メインのアクセルペダルセンサとは別にサブのアクセルペダルセンサを搭載する⇒<エレメント>サブアクセルペダルセンサ

「機能安全」対応・「派生開発」をうまく乗り切るために

『派生開発』で機能安全対応を行うには、全てを一から作成するのではなく、既存システムの成果物を、機能安全プロセスとの関係を把握した上で活用することが重要です。しかし、現場では制御仕様書やソースコードなど下流工程の成果物はあるものの、システム視点での要求やアーキテクチャといった上流工程の成果物が作成・整備されていないことも多いと思います。

各種仕様書がトレース可能な状態で整備されていると、機能安全対応に限らず、『派生開発』で仕様の追加・変更を正確に、かつ効率的に行えます。

規格で求められているからという理由ではなく、開発の品質を高める目的で取り組み、仕様書が開発組織で共有できる状態を維持していただきたいと思います。

サービスに関するご相談は
こちらからお願いします
  • LINEで送る
  • このエントリーをはてなブックマークに追加