バックナンバーはこちら

today&tomorrow

Technology Update

2017 Aug Summer vol.107

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

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

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

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

自動車も「民生品」としての性格上、携帯電話が10年前に経験したのと同じような変化に直面しています。携帯電話は伝統的なフィーチャーフォンからスマートフォンへと進化する過程でLTE、マルチタッチ・スクリーン、Bluetooth、USB、Lightning、NFC、カメラ、Wi-Fi、フラッシュ・ストレージ、GPSなど数々の新しい機能とインターフェイスを取り込み、高機能なユーザー体験を消費者にもたらしました。この結果、モバイルSoCの設計と検証の複雑さは爆発的に増大しています。同様に、伝統的な自動車は今、USB、Bluetooth、Wi-Fiなど多くのコネクティビティ、およびGPS、パーキング・センサー、自動駐車、ハイブリッド・ドライブトレーン、アクティブ・セーフティなど多くの新しい機能を取り込んだインテリジェント・カーへと進化しつつあり、完全自動運転車および車車間通信という目標に向かって新しい自動化機能とインターフェイスを採用した新車が次々と発表されています。こうした機能面での急成長を支えているのが最先端の半導体デバイスです。現在、平均的な自家用車には約350ドル相当の電子部品が搭載されており、高級車ではその額は約3倍にも達します。しかし車載アプリケーションでは、モバイル、コンピューティング、ネットワーキング・アプリケーションとは違って半導体部品に厳しい安全要件が課せられます。したがって、自動車業界の要求に応えられるように設計および検証メソドロジを見直すことが半導体企業にとって急務となっています。

本稿では、まず伝統的な検証フローに加えて自動車安全検証の実施が必須とされる点など、インテリジェント・カー革命によって半導体検証チームが直面している主な課題について見ていきます。次に、ISO 26262規格の役割、そして自動車安全検証フローを構成するツールとテクノロジについて見ていきます。

自動車安全検証の新たな課題

機能の不具合をゼロにすることはすべての半導体設計に共通する目標ですが、いざ不具合が生じた場合の影響の大きさを考えると、車載ICと他のICではまったく異なります。たとえばスマートフォンがクラッシュしてもせいぜい再起動の手間だけで済みますが、先進運転支援システム(ADAS)を使用して時速100 kmで高速道路を走行中に自動ステアリングによる車線逸脱防止機能が誤動作を起こすと極めて深刻な結果を招きます。機能検証の要件は車載ICもモバイルSoCも似たようなものですが、機能安全の要件は両者でまったく異なっており、車載ICの方がはるかに厳格です。デザインのバグなどによって生じるシステマティック故障については、これらのバグを検証環境でとらえ、デバイスを製造・出荷する前にこれらを見つけて修正することが伝統的な機能検証と機能安全検証の共通する目標となります。しかしランダム故障については目標がまったく異なり、この種の故障が発生してもデバイスの安全メカニズムが故障の影響を正しく管理し、危険な状況の発生を回避できることを確認することが機能安全検証の目標となります。

安全検証は車載半導体開発で最も重要な課題の1つです。車載半導体で要求されるFIT(Failure in Time)レートは通常よりもはるかに厳しく、検証に対する考え方を大きく転換する必要があります。先進運転支援、ドライブトレーン、アクティブ/パッシブ・セーフティなどの新しい機能が登場する中、半導体SoCへの依存性は高まる一方です。これらデバイスが車載システムに採用されるためには、デバイスの徹底的な安全検証が欠かせません。

自動車安全検証は伝統的な機能検証と協調して行う必要があり、これまでとはまったく違った視点とアプローチが必要です。ある機能を完全にインプリメントし、機能仕様への適合が完全に検証できたとしても、それだけでは安全規格への適合は保証されません。機能検証は動作の不具合を考慮に入れていないためです。

Safety critical outputs

画像(仮)

図1:IPレベルの安全検証

たとえば「ポートY1(単一ビットまたはベクター)は、ポートY2がシーケンスB(複数サイクルのイベント・シーケンスなど)を出力している間、決して値Aをとってはならない」という一般的な安全要件を例に考えてみます。デザインのロジックを完璧にインプリメントすれば違反はまったく発生せず、たとえバグがあっても機能検証ですべて見つけて修正できます。しかし安全検証の観点から見ると、異常な高温や長期動作後のエレクトロマイグレーションなどに起因するハードウェア障害によってポートY1のロジック・コーンに縮退故障や過渡故障(ランダム故障)が発生し、値Aが出力されて危険事象が開始するケースも考えられます。あるいはアルファ粒子の影響でデザインのいくつかのステート・エレメントが反転(過渡故障)して危険事象が発生する可能性もあります。このような安全に関するさまざまなシナリオは伝統的な機能検証ストラテジではモデル化できないため、機能安全検証ストラテジを用いて外部から注入された故障としてモデル化する必要があります。また、このブロックの安全要件文書に記載されたとおりにデザインがこれらのシナリオを診断して回復できるかどうかの動作検証も必要です。

このように、機能安全検証では外部事象によって不正な(または予期しない)ステートを強制的に発生させるシナリオをテストする必要があります。デザインに期待される動作(本来の機能を失わずに動作を継続するか、機能を一部失ってでも動作を継続するか、または単に診断情報のみを送信するか)はそのロジック・コーンに関連付けられた安全要件によって異なります。

自動車の安全検証で中心的な役割を果たすのが、シノプシスの故障シミュレーション・ソリューション Z01Xなどを利用した故障シミュレーション・メソドロジです。Z01Xの機能安全検証メソドロジを使用すると、関連する幅広い種類の故障をモデル化し、デザインの安全メカニズムがハードウェアのランダム故障を効果的に管理できているかどうかを短時間で正確に評価できます。ISO 26262規格では、この種の故障シミュレーションに基づいた自動車安全検証メソドロジのフレームワークが定義されています。このフレームワークは、そのような故障がデザインで発生した場合に生じる不合理なリスクを評価し、取り除きます。

カテゴリートップ