車載電子システム向け機能安全メソドロジ
序
自動運転技術の開発競争は日々ニュースを賑わしていますが、この新分野は車載電子システムのSOC開発に対して多くの進化を驚くほどの短期間でもたらしてきました。完全自動運転システムの露払いと言ってしまうと語弊がありますが、先進的運転支援システム(ADAS: Advanced Driver Assistance System)は、車載電子システムにおける量や複雑度というものを指数関数的に増大させています[Leen]。最近の高級車では車間距離制御や衝突回避、自動パーキングなどの最新の機能のいくつかの実装のために最大90ものECU(Electronic Control Unit)を搭載しているとのレポートもあります[Munir]。ADASではレーダーやレーザーレーダー(ライダー)、カメラ/センサーからもたらされるデータの処理を行い、周囲の状況の認識を行うことが必要ですが、これらの処理は大きな計算量となるため、処理速度や低消費電力の要求を満たすためには勢い最先端のプロセスノードで作成することとなります。また、先端技術の採用はプロセス誤差や静電気放電(ESD)、エレクトロマイグレーション(EM)などの品質的な課題も重要になります。
安全性は耐リスクの観点から車載システムの基本的要求項目となってきています。安全性は既存の二つの標準規格で定義されます。そのひとつはIEC(International Electrotechnical Commission) により一般的な電子機器向けに制定されたIEC 61508であり、もうひとつはISO(International Organization for Standardization)により車載電子システム向けに制定されたISO 26262です。2007年にその概要が示され2011年には正式に発行されて以来、ISO 26262は自動車関連エンジニアの間で急速にガイドラインとして認知されてきています[Munir]。
これらの標準規格への適合は、従来は自動車メーカーやシステムサプライヤーの関心事項でした。しかし、複雑さの増大は自然と分割統治の手法を必須とし、これら「上流」メーカーだけでなく、サプライチェーンのすべてのプレーヤーが機能安全および品質保証の標準準拠であることが求められてきており、それはサプライチェーンの一端を占める半導体の設計フローにも求められることになってきています。
機能安全の基本
このセクションでは、機能安全の基本的要素、そのライフサイクルと解析手法を概観します。
機能安全とは
ISO 26262: Road Vehicles—Functional Safetyは、より一般的な標準規格であるIEC 61508 functional safety standardの自動車業界向け子規格とも言えるものであり、電気/電子(E/E)システムを搭載した重量3500Kg以内の量産乗用車の安全関連システムのための標準規格です[Beckers]。
ISO26262では、機能安全とは「電気/電子(E/E)システムでの機能不全のふるまいにより引き起こされるハザードによる不合理なリスクがないこと」と定義されます。この定義は下記のFig. 1のような事象のチェーンとして表現することができます。
故障の分類とハードウェアランダム故障のメトリクス
ISO26262では、E/E部品の機能不全は2種類の故障に分類されます。
- システマティック故障(決定論的故障):開発、製造、メンテナンスにおいて、決定論的に誘発される故障であり、プロセスの問題と言えます。バグや仕様漏れなどがシステマティック故障の例です。これらの故障は通常は開発・製造・メンテナンスのプロセスに起因し、デザインの書き換え、製造プロセスの手直し、操作手順や文書化の改善等で解決することが可能です。この典型的な対策には、トラッキング/トレーサビリティの確立があります。上記の手法に対してはすべてISO 26262-2:2011に記載されている機能安全管理の実施が求められます。
- ランダム故障(偶発的故障):ハードウェアランダム故障はハードウェア部分にライフタイム中に偶発的に発生します。通常「故障」として思い浮かべるものであり、製造条件や使用条件に左右されます。ハードウェアランダム故障はさらに固定故障(例:固着(stuck-at)故障)と間欠故障(例:シングル イベント アップセット (SEU))に分類することができます。
ランダム故障の対策としては、機能不全を検出訂正するためのセーフティメカニズムを付加します。ISO 26262:1-2011の用語集・用語定義では、セーフティメカニズムとは、不具合や障害が発生した場合にそれを検知・制御することで安全状態を保つ/安全状態へ移行ための技術的な解決手法と述べられています。セーフティメカニズムの例を挙げますと、以下のようなものがあります。
エラー訂正符号(ECC)
巡回冗長検査(CRC)
ハードウェア冗長
組み込み自己テスト(BIST)
ハードウェアランダム故障の検出の観点からのセーフティメカニズムの効果を定量化する尺度としては、次の3つのメトリクスがあります。
– Single-point fault metric (SPFM)
– Latent fault metric (LFM)
– Probabilistic metrics for hardware failures (PMHF)
これらの3つのメトリクスはハードウェア部品の機能安全においてISO26262では必須となる数値であり、このホワイトペーパーではそれらの数値をどのように解析し、また、どのように目標値に合致させるかについて述べていきます。
3つのメトリクスについては、ISO 26262-5:2011のAnnex D, C.2, C.3 および9.2節にその定義が記載されています。
- Single-point fault metric: このメトリクスはアイテム/ファンクションのsingle-point faultsに対する耐性を検出率として示しています。
- Latent fault metric: このメトリクスはアイテム/ファンクションのlatent faultsに対する耐性を検出率として示しています。
- Probabilistic metric of hardware failures: このメトリクスはハードウェアランダム故障の発生確率を示しています。
正確ではないかもしれませんが、直感的な言い方をしますと、single-point faultは直接にセーフティゴールを逸脱しうる影響を与えうる故障であり、latent faultはそれ自体は検出できない故障であるが、他の故障がハザードを引き起こしうるような故障です。
ASIL
車両レベルのある機能(例:アンチロックブレーキシステム)の機能不全を考えたとき、ハザードの分類と特定、そして人身への危害や物への被害のリスクの大きさの見積もりを行います。リスクは危害/被害の重大度、曝露可能性、回避可能性の観点毎に見積もり、この結果に基づき、automotive safety integrity level (ASIL)を決定します。ASILとは、リスクを許容可能なまでに十分小さくするために必要なレベルと言うこともできます。Fig.2に機能不全とその影響可能性からASILを決定する手順例を示します。ASIL Aがリスクを削減する手間が最もかからないレベルであり、一方ASIL Dが最も重大なレベルとなります。
ハードウェア部品では、Table 1に示すように、ASILに合わせてハードウェアランダム故障に関するメトリクスを達成しなくてはなりません。またシステマティック故障に対応するには、開発プロセスについての厳密性の準拠(例:トレーサビリティ、プロセス品質、文書化)が求められます。
機能安全ライフサイクルの全てのフェーズはISO26262に沿って定義され文書化されなくてはなりません。Fig.3にコンセプトフェーズおよび開発フェーズの手順を示します。aの列が手順を、bの列が対応する機能安全のアクティビティを、cの列がその例を記しています。コンセプトフェーズは多くの場合、自動車メーカーにより行われ、車両レベルでの機能を実現するためのシステムを定義します。これは、ISO26262の用語ではアイテムと呼ばれます(例:自動緊急ブレーキシステム)。ASILはこのレベルで定義され、セーフティゴールおよびこのセーフティゴールの達成に必要な機能安全要件を作成します。システムレベルの製品開発フェーズが開始された段階で、各安全要件は機能安全に関わるハードウェアおよびソフトウェアに対しての技術的安全要求仕様に詳細化されます。セーフティゴールは車両レベルで定義が開始され、各ハードウェアサブシステムにハードウェア故障メトリクスが定義・割り当てされるまで、開発チェーンのなかでマッピングや詳細化がなされることになります。
機能安全解析
機能安全解析は製品単位(例:IP、SoC)で安全レベルが達成できるかを評価するもので、定量的評価(例:FMEDA:failure mode effect and diagnostic analysis)、タイミング解析、定性的アセスメント(例:DFA: dependent failure analysis)から成ります。
FMEDA
FMEDAはハードウェアの故障モード、故障レート、診断機能を定義するための階層的アプローチです。部品の機能を元に、FMEDAではパーツレベル、サブパーツレベル、基本サブパーツレベル(詳細レベルに依存)、故障モードに階層化されます。各故障モードはセーフティゴールに関わるか否かで分類されます。FMEDAを実施するには、故障モードについて次の要素が入力として必要になります。
- 故障レート(FR: failure rate):当該部品が故障しうるレート(信頼性)
- セーフティメカニズム(SM: safety mechanism):当該故障モードを検出するセーフティメカニズムがあるか否か
- 診断カバレッジ(DC: diagnostics coverage):セーフティメカニズムが故障を検出する効果度
機能安全の準備度合いの評価として、ハードウェアアーキテクチャメトリクスであるSPFM、LFM、PHFMがFMEDAの出力となります。すなわち、部品がどれだけ信頼しうるか(逆に言うと、どれだけ故障しやすいか)、そしてセーフティメカニズムがどれだけ故障を検出してシステムを安全状態とするかが、先のアーキテクチャメトリクスとして算出されることになります。
故障レートは部品の信頼性の尺度であり、FITを単位として記されます。FITレートは10億時間の動作時間における故障の発生確率です。もしあるデバイスのFITレートが1であれば、そのデバイスは10億時間の平均故障時間(MTTF: mean time to failure)を持つと言えます。
ISO26262では、ハードウェアの故障レートの見積もりは、以下の3つの方法のいずれかを使用します。
- 信頼性データブックの数値を用いる(例:IEC61709、IEC TR62380)
- フィールドでの実績から導出する(例:フィールドからの返品率での解析)
- 試験検査成績から導出する
Table2に単純化したFMEDAテーブルを示します。このテーブルに見えるように、各故障モードのFR、SM、DCを組み合わせて計算することでSPFM、LFM、FITレートを得ることが出来ます。最終的なメトリクスは各列の総計として与えられます。メトリクスの列ごとの解析を行うことで、どの部品に対してより機能安全を高めねばならないかがわかります。Table 2では固定故障の例を示していますが、同様のやり方で間欠故障についても解析することができます。
タイミング解析
ここまでのハードウェアアーキテクチャメトリクスの説明では時間的制約について述べていませんでしたが、セーフティメカニズムの評価を完全に行うためにはタイミング的なパフォーマンスも含めることは明白でしょう。実際のところ、システムは故障を検出し安全状態に遷移することは、システムレベルのハザードを引き起こさないある時間内(この時間をFTTI : fault tolerant time intervalと呼びます)に行われなくてはなりません。Fig.4に、FTTIおよびFTTIのうち故障を検出する時間であるDTI: diagnostic test intervalについて図示します。参考までに、全システムのFTTIが100msとして、CPUでの故障検出のためのDTIとしては10ms前後が割り当てられる、というような例があります。
DFA
ハードウェアランダム故障の解析と合わせて、特にシステムが共有リソースを持つような場合、他の観点からの解析としてDFA(dependent failure analysis)があります。従属故障(dependent failure)の解析は、共通原因故障およびカスケード故障の解析としても知られていますが、必要な独立性や要素間の非干渉が確保されないために安全要件もしくはセーフティゴールを逸脱しうる状況をつくるような単一の原因の特定を目的としています。ISO26262では、従属故障の原因のリストおよびそのような故障の制御もしくは緩和のためのガイドラインが示されています。共通リソースの偶発的ハードウェア故障を原因とする従属故障としては、クロックや電源、共通リセット論理などがあります。物理的な原因としては短絡やラッチアップ、クロストーク等があります。ISO26262では、対処手法として以下のものがあげられています。
- 共通リソースの独立監視(例:クロック監視)
- スタート時のセルフテスト
- 多様性の導入(例:マスターとチェッカーのクロック間の遅延)
- 特殊なセンサーによる間接監視(例:共通原因センサーとしての遅延ライン)
- 故障回避手法(例:物理的な分離・隔離)
機能安全要件と設計フロー
機能安全では、リスク削減が十分であるかどうかを判断する尺度として、信頼性と予防安全の2つの観点があります。
このホワイトペーパーでは、一般的なRTL-GDSフローにおいてどのように機能安全が確保されるかにフォーカスして述べていきます。このセクションでは、ハードウェア設計・検証における要求されるリスク削減、言い換えると要求されるハードウェア機能安全メトリクスをどのように達成するかについて、機能安全解析の用法を述べます。
FMEDAを用いることで、機能安全ターゲットを満たすハードウェアについての解析を行い、このなかの故障モードとそのメトリクスを見ることで、制約を満たすためにどのような設計努力に注力すべきかが見えてきます。また、セーフティメカニズムの診断カバレッジを直接的かつより正確に得るための故障注入キャンペーンを実施するための指標ともなります。一方、DFAは独立性を保障し共通原因故障を排除することで、RTL-GDSフローにおいて正しい安全メトリクスを得ることができます。
消費電力、面積、機能安全メトリクス、パフォーマンスの観点から注意深く解析し、それらの間で最善のコスト対効果のトレードオフとなるようにセーフティメカニズムの選択を行わなくてはなりません。セーフティメカニズムは、ソフトウェアスタック内のひとつとして実装されるソフトウェアテストかもしれませんし、RTLとして記述したもしくはデザインフロー内で自動挿入されるハードウェア実装かもしれません。この章では、特に後者について述べていきます。
設計と実装
デザインフロー内で自動生成されるセーフティメカニズムとして最も目にするものはBIST(Built-In Self-Test)でしょう。ランダムロジックのテストのためのBIST技法には大きく分けて二つのカテゴリがあります。それぞれ安全メトリクスやパフォーマンスの観点から差異があります。
- オンラインBIST:テストは回路が実動作(ミッションモード)中に実施されます。DTI内で完了させるため、厳密なタイミング要求が必要となります。SPFMの改善が可能です。
- オフラインBIST:テストは回路が実動作中以外、例えばエンジン起動時のパワーオンリセット中に実施されます。タイミング要求についてはやや緩めにできます。LFMの改善が可能です。
BISTの実装では、実速度テストの可否、消費電力、面積オーバヘッド、配線長、カバレッジなどの課題があります[Wang]。テスト圧縮の技法と組み合わせることで、品質とリソースの効率的シェアリングが可能となります[Pateras]。
BIST挿入時のテストカバレッジ見積もりは、ISO26262で求められる診断カバレッジとは関連しているとは言えますが、完全に一致はしません。そのため、機能安全検証においては厳密な診断カバレッジを測定する必要があります。Fig.5に示す衝突被害軽減ブレーキ(AEB: Automatic Emergency Braking)の例では、複雑なマイクロプロセッサではよくある問題となるCPUキャッシュ内で累積される故障を回避するためにBISTが使用されます。
セーフティメカニズムの他の例としてモジュール三重冗長構成(TMR:triple modular redundancy)があります。SEU故障に感受性のある論理(メモリーセル)は三重化され、その多数決の結果を正しい値として出力します[Ruano]。Fig.6にフリップフロップレベルでのモジュール三重冗長構成を示します。この技法により、三重化された順序素子部分のSPFMおよびLFMの両方を改善可能です。
安全アーキテクチャがハードウェア冗長性に拠る場合、DFAを実施して、物理的要因を起因とする共通原因故障についての解析を行い、論理的独立性を物理的独立性と紐付けることが必要です。
冗長性に拠るセーフティメカニズムとしては、Table 2でも述べたデュアルコアロックステップ(DCLS: Dual-core lockstep)もあります。共通リソース(例:電源、クロック、リセット信号)および単一の物理故障要因の両方が共通原因故障となりうるため、高い診断カバレッジを達成するには特殊な設計手法を用いる必要があります。
Fig.7に機能レベルでの共通原因故障に対する対策例として、タイミング多様性や出力反転などの技法を挙げています。また、クロストークの回避やリングバリアなどを使った冗長ブロック間の確実な隔離も重要です。同値レジスタの間隔配置やパワードメインでの配線等の配置配線の制約を上手に使用することで物理的な独立性を担保できます。
Fig.8に Cadence® Innovus™ Implementation Systemを使用して、機能安全に関する配線制約の有無による差を示します。底部左側での機能を、コピーして冗長性を持たせるために上部右側に配置しています。底辺左側の機能の配線は上部右側に行かないように制約を与えることで、コピーされた冗長部は物理的に独立となり、DFAでの要件を満たすことができます。
検証
IPやSoCのために予備的にFMEDAを作成した段階で、ISO 26262:2011-5, Annex Dの Table D.3からTable D.9を使い、low, medium, highの3段階でセーフティメカニズムの診断カバレッジの見積もりを開始できます。ECCのようないくつかの標準的なセーフティメカニズムでは解析的に診断カバレッジを計算できますが、一部の論理でのみ正確な値を出すことができるという制限が存在します。例えば、ECCではデータセルに対しての診断カバレッジは正確に見積もれますが、メモリの前にあるデコーダに対してはうまく適用できません。ASIL-Dのような高いASILが要求される場合、このような誤差は許容できず、故障注入によるより正確なDC算出手法が必要になります。
カスタムなハードウェアセーフティメカニズムや、ソフトウェアセーフティメカニズム(STL:standard test library)を用いている場合、先ほどのようなテーブルを参照することはできませんので、例えば故障注入シミュレーションにより診断カバレッジを計測することになります。故障注入シミュレーションは、診断カバレッジの計測以外にも、Fig.4で説明したようなDTIやFault Reaction Timeの評価や、故障の影響の解析も行うことができます。
機能安全検証は、通常の機能検証と同様の準備から始まります。セーフティメカニズムの診断カバレッジ計測のための故障注入キャンペーンでは、故障の影響を観測する観測点(observation points)およびセーフティメカニズムの反応を観測する診断点(diagnostic points)をまず定義します。Fig.7では観測点はCPUマスターの可観測出力(primary outputs)に置かれ、診断点は比較器のアラーム出力に置かれます。故障が観測されたタイミングと検出されたタイミングの差がDTIを決定します。
故障は観測点および診断点での影響の判定により、以下のような分類が可能です。
─ Dangerous Detected:故障の影響が観測点と診断点の両方で観測されます。機能出力は故障の注入で影響を受けますが、セーフティメカニズムで故障の検出に成功しているとの意味です。
─ Dangerous Undetected:故障の影響が観測点において観測されますが、診断点では観測できません。言い換えますと、当該故障は機能出力に影響を与えますが、セーフティメカニズムでの検出に失敗しています。
─ Safe:故障は観測点に対し影響を与えません。Safeであると言うためには、機能検証において十分高いカバレッジを達成するだけの診断パタンが与えられることが必要であることに留意ください。
故障注入キャンペーンのセットアップでは、どこに故障を注入するかがきわめて重要です。セーフティメカニズムはある特定の故障モードを対象としますが、この故障モードに関連する論理にのみ故障を注入すべきです。
ツールに対する信頼度の証明
システマティック故障対策のための機能安全管理の一環として、安全に関わる開発で使用するツールに対して、その信頼度について証明する必要があります。ツール信頼度(Tool Confidence Level: TCL)は、ツールの不具合が検出されることの保証の度合いを示したものです。TCLはTCL1, TCL2, TCL3の三段階があり、TCL1が最も高度な信頼度であり、追加の品質証明が不要で、ASILに関わらず開発に使用できます。TCLは、ISO 26262-8:2011のTable 3にまとめられているように、当該ツールの不具合が機能安全目標に与える影響度およびその不具合の検出可能性の二点からなる評価尺度に基づいて決定します。使用するツールのTCL情報はある製品が機能安全要求の達成度の観点からISO26262準拠であるか否かを示すために必要となります。
まとめ
自動運転車両の開発競争とそれに伴う電子回路の複雑さ増大は、機能安全への責任が自動車メーカーやシステムサプライヤーだけでなく、半導体メーカーやツールベンダーにも求められるようになってきています。このホワイトペーパーでは機能安全の基礎および新しい安全尺度についての設計メソドロジ観点でのソリューションをご紹介しました。
参考文献
・Beckers, Kristian, et al. “Systematic derivation of functional safety requirements for automotive systems.” International Conference on Computer Safety, Reliability, and Security. Springer, Cham, 2014.
・Benso, Alfredo, et al. “A high-level EDA environment for the automatic insertion of HD-BIST structures.” Journal of Electronic Testing 16.3 (2000): 179-184.
・Chang, Yung-Chang, et al. “Assessing automotive functional safety microprocessor with ISO 26262 hardware requirements.” 2014 International Symposium on VLSI Design, Automation and Test (VLSI-DAT). IEEE, 2014.
・IEC. “Functional Safety - Standards, ed. 1.0.” 2007.
・International Electrotechnical Commission (IEC). “Functional safety of electrical / electronic / programmable electronic safety-related systems.” Basic Safety Publication. 2010.
・Ismail, Azianti and Won Jung. “Research trends in automotive functional safety.” International Conference on Quality, Reliability, Risk, Maintenance, and Safety Engineering (QR2MSE). IEEE, 2013.
・“ISO 26262: Road vehicles — Functional safety.” International Standard. 2011.
・Leen, G. and , D. Heffernan. “Expanding automotive electronic systems.” IEEE Computer, vol. 35 (1) (2002):88-93.
・Maurer, Markus, et al. Autonomous driving: technical legal and social aspects. Springer Publishing Company Incorporated, 2016.
・Munir, Arslan. “Safety Assessment and Design of Dependable Cybercars: For today and the future.” IEEE Consumer Electronics Magazine 6.2 (2017): 69-77.
・Pateras, Steve, and Ting-Pu Tai. “Automotive semiconductor test.”2017 International Symposium on VLSI Design, Automation and Test (VLSI-DAT). IEEE, 2017.
・Ruano, O., A. Maestro, and P. Reviriego. “A methodology for automatic insertion of selective TMR in digital circuits affected by SEUs.” IEEE Transactions on Nuclear Science 56.4 (2009): 2091-2102.
・Wang, Laung-Terng, Cheng-Wen Wo, and Xiaoqing Wen. “VLSI test principles and architectures: design for testability.” (2006).
アレッサンドラ ナーディ(ケイデンス)
アントニーノ アーマート(ケイデンス)
日本語訳 後藤 謙治(日本ケイデンス)
この記事に関する問い合せ先:
コーポレート・マーケティング部
E-mail:cdsj_info@cadence.com
Latest Issue
- ハイパフォーマンス・コンピューティングとコンシューマ機器に向けた次世代のメモリ規格DDR5に対応するケイデンスのIP
- CDNLive Japan 2018開催のご案内
- 編集後記
- Innovus 18.1: 待望のメジャー・アップデート、遂にリリース! ~業界をリードするデジタル設計ソリューションの新機能を搭載~
- Tempus-ECO ver.18.1最新機能のご紹介 ~ Multi-Level Clock Skewing ~
- ダミーフィルの影響をインデザインで解消 – Virtuoso IPVS SignOff Fill & Density Analysis
- 新時代の幕開け、アドバンストメソドロジ対応ツール Virtuoso ICADVM18.1
- アナログIC用信頼性考慮設計ソリューション「 Legato Reliability Solution 」
- オートモーティブ電子システムデザイン・セミナー開催レポート
- 東アジアのお客様は英語の資料を要求してきましたよ
Archive
2023 Issues
2022 Issues
2021 Issues
2020 Issues