バックナンバーはこちら

today&tomorrow

Technology Update

2017 Aug Summer vol.107

自動車機能安全検証の課題

シノプシス ベリフィケーション・グループ、自動車機能安全ソリューション・テクノロジ担当スタッフ・エンジニア Brian Davenport

シノプシス ベリフィケーション・ソリューション担当シニア・プロダクト・マーケティング・マネージャー Prapanna Tiwari

シノプシス ベリフィケーション・グループ シミュレーション/カバレッジ/自動車機能安全検証製品担当プロダクト・マーケティング・ディレクター David Hsu

IPの検証

現在の半導体設計において、デザインの再利用は欠かすことができません。しかし社内設計者であれサードパーティの設計者であれ、車載向けIPの検証では特有の課題に直面します。安全目標(ASILレベルなど)の異なるターゲット環境にまったく同じIPブロックを使用することもできなくはありません。現在はコンフィギュレーション可能なIPが一般的ですが、安全要件はターゲット・アプリケーションごとに異なるため、IPレベルでの検証はより複雑な作業となります。

一般に、IPレベルでの安全検証は以下のアプローチで実行します。

  • IPのすべての入力が有効な値を持つシナリオを想定する。
  • ターゲット・アプリケーションでセーフティ・クリティカルとなる出力ポートを特定する。
  • これらのセーフティ・クリティカルな出力のロジック・コーンで発生した故障が、ターゲット・アプリケーションで必要とされる方法で管理されることを検証する。
  • 故障の管理方法は、ターゲット・アプリケーションの要件による。
    (例)
    – 故障を検出し、診断情報と一緒に報告する。
    – 故障から回復した後にデータを外部へ送信する。
    – ホスト環境と何らかのハンドシェイクを実行して故障を管理、緩和する。
  • IP成果物の一部としてFMEDAレポートと安全マニュアルを生成する。

車載IPユーザーは、機能要件だけでなく安全要件も判断基準としてIPブロックを評価します。しかしIPベンダがターゲット(特定の車両、アイテム、アプリケーション)を限定せずにIPブロックを開発する場合、IPベンダはそのIPブロックが使用される最終アプリケーションにおいてIPユーザーの要求が満たされるように、デザインに対して適用される安全要件を仮定せざるを得ません。これはSEooC(Safety Element out of Context)の開発として知られており、ISO 26262規格にはIPブロックの安全メカニズムの品質を評価するための要求事項が定義されています。また、従来のIP成果物に加え、IPブロックの安全確保のために必要なすべての手順を実行したことをFMEDA(故障モード影響診断解析)レポートおよび安全マニュアルで示します。既存のIPを車載アプリケーションに使用する場合は、IPの再検証が必要です。

機能安全検証におけるトレーサビリティ

車載システムの検証のもう1つの側面として、機能安全のトレーサビリティがあります。サブシステムの期待される動作、およびその検証を追跡するだけでなく、デザインに対する変更がすべてのサブブロックのデザイン階層を通じてデザインの動作にどのように影響するかまで追跡する必要があります。

検証フロー全体でトレーサビリティを確保することにより、すべての安全要件が適切にテストされ、必要に応じて適切な修正がなされたことの証拠を提供します。検証チームは安全要件を個々のテスト結果およびカバレッジ目標までトレースできるだけでなく、複数のリグレッション・テストを適切な安全目標の合否条件にマップできるようにする必要があります。このエビデンスは最終的にISO 26262に準拠したFMEDAレポートに文書化されます。

カテゴリートップ