機能安全の実装がメインストリームに

一般的な電子機器から車載向けデザインへと軸足を移すエンジニアの数は、かつてないほど増えています。自動車の電動化が進み、自動運転の時代が到来することにより、シリコン設計者は今後ますます複雑な車載ICの開発に従事することになるでしょう。しかも自動車は一般的な電子システムとはまったく異なり、万一故障が発生しても危険を引き起こさないことが絶対的な条件として求められます。

このため、車載ICの設計では機能安全への対策が必須となります。機能安全は、これまで軍用あるいは航空宇宙向けデザインを手がけるごく一部のエンジニアにしか関係しない特殊な分野でしたが、自動車向けの電子システムおよびデザインにおける機能安全の実装方法を規定したISO 26262規格の策定により、今ではメインストリームへと広がっています。急成長を続ける車載アプリケーションへの参入企業が増えている現在、機能安全はこれまでよりもはるかに多くのエンジニアに関係するようになっています。

ここで問題となるのは、機能安全に適合しようとすると、設計フローで実行すべき困難なタスクが増えるという点です。現在のように車載ICの開発が盛んになる前は、冗長性などの安全機構を実装するには非常に多くのノウハウが必要とされた上、面積の最適化といった一般的な設計目標との両立も不可能でした。これでは、消費電力、性能、面積が重要な設計目標とされる市場で高い競争力を維持することは望めません。エンジニアは今、機能安全の要件を満たすと同時に、生産性を高めて競争力を維持できる設計ツールを求めています。ISO 26262に適合したICの設計を簡略化する上で大きな効果を発揮するものとして、以下のものが挙げられます。

• 設計ツールまたはツールチェーンのISO 26262認定（ISO 26262セクション8～11で規定）
• 冗長性、エラー訂正、および故障対策などの安全機構の実装支援
• 安全の意図をツールが利用できる形で指定すること（電力の意図を記述するUPFに相当するもの）
• 各ツールに対してバックアップ・ストラテジを確保しておくこと

自動車の機能安全で求められるもの

TISO 26262規格では、安全水準としてASIL（Automotive Safety Integrity Levels） A～Dの4段階を規定しており、比較的安全への影響が少ないシステムにはASIL Aが適用され、故障すると人命が危険にさらされるリスクが高いシステムにはASIL Dが適用されます。最近になって電動化された車載コンポーネントの多くはASIL Dに分類されますが、自動運転車が現実へと近付くにつれ、従来のASIL BおよびCデザインがASIL Dデザインへと移行する現象も見られています。このように、現在では多くのシステム・オン・チップ（SoC）がASIL Dをターゲットに開発されており、これらのSoCは少なくとも10年間にわたって信頼性を維持する必要があります。

ISO 26262の要件に適合するには、使用するEDAツールに対してソフトウェア・ツール認定の評価を実施し、設計ツールによって機能安全の問題がデザインに混入したり、デザインに存在する機能安全の問題を設計ツールが検出できなかったりすることがないことを立証する必要があります。この作業を簡略化するため、EDAベンダはANSI公認の第三者機関に個別ツールまたはツールチェーンに対するISO 26262認定の実施を委託しています。

しかしこうした認定作業は決して簡単なことではありません。たとえばシノプシスは、これまでデジタルおよびカスタム/AMSツールの認定取得にほぼ1年の期間と100人の人員を費やしてきました。認定とは、そのツールで不具合が決して発生しないことを保証するものではなく、考えられる不具合シナリオの1つ1つについて、その不具合を緩和するソリューションの存在が特定されていることを意味します。これらの緩和策は、CoU（Conditions-of-Use）およびAoU（Assumptions-of-Use）として文書化されます。CoUとAoUは機能安全マニュアルの一部に含まれ、セーフティ・クリティカルなデザインの開発に使用するすべてのツールについて、そのユース・ケースに関するガイダンスを提供します。この情報を使用して、企業のソフトウェア・ツール認定に役立てることができます。

ランダム・ハードウェア故障とは、太陽フレアによって発生するシングルイベント・アップセット（SEU）など制御不能な事象を指し、これらはグリッチやステートの喪失を引き起こします。ランダム・ハードウェア故障は完全になくすことができないため、冗長化などの各種安全機能によってそのリスクを軽減することが必要です。なお、安全機構が達成すべき指標の目標値は、ASILのレベルが上がるほど高くなります。たとえば単一箇所における故障検出率（SPFM：Single Point Fault Metric）の場合、デザインが達成すべき指標はASILレベルごとに以下のようにISO 26262で規定されています。

機能安全への対応で必要になる実装工程のほとんどは、ランダム・ハードウェア故障の緩和に関するものです。この工程は、まずランダム・ハードウェア故障の影響を受けやすいロジック・パスを特定することから始めます。これらのパスに存在するすべてのレジスタについて、冗長化するか、エラー耐性を高める必要があります。冗長性の実装方法には以下の3つがあり、どれを選択するかはASILレベルによって決まります。

• 最もASILレベルの高いデザインでは、TMR（Triple Module Redundancy）を使用してエラーを訂正できるようにします。この実装では、故障の影響を受ける1個のレジスタを3個のレジスタおよび多数決ロジックで置き換えます。3個のレジスタのうちいずれか1つでエラーが発生した場合、残り2個のレジスタでエラーが発生していなければ、多数決で2個のレジスタの値が正として採用され、エラーが隠蔽されます。これら3個のレジスタは互いになるべく独立している必要があるため、間隔を空けて配置し、回路の他の部分から電気的に絶縁しておくことが重要です。この方法は、3つの実装方法の中で最も面積が大きくなります。
• 2つ目は、DMR（Dual-Mode Redundancy）を使用する方法です。ただしこの方法はエラーを検出するだけで、訂正はできません。エラーが検出された場合にどのような処理を実行するかを判断するためのロジックを別途実装する必要があります。
• ASILレベルが低いデザインでは、クリティカル・パスにフォールト・トレラント・レジスタを使用し、故障の発生確率を下げるという方法がとられます。この実装は故障を発生しにくくするだけで、故障が発生してもエラーの訂正・検出はされません。この方法は、3つの実装方法の中で最も面積が小さくなります。SPFMの値も低くなりますが、ASIL Bデザインでは問題になりません。

これ以外に、特にプロセッサ・コアを使用したデザインでは、デュアルコア・ロックステップ（DCLS）と呼ばれる安全機構も実装できます。この機構ではエラーは訂正できませんが、いずれか1個のコアでエラーが発生したことは検出できます。同じ入力ロジックを備えた2個のコアを並列に動作させ、それらの出力をコンパレータに入力します。2つの出力値が異なっていると、エラーが発生したことになります。その場合は不一致を示す信号を生成し、故障の影響を無害化できるまでシステムを既知の安全なステートに移行させるなど、システムが何らかの回復措置を実行できるようにします。この場合も、1つのコアのセルまたはバッファをもう1つのコアに配置するのを避け、2つのコアが物理的に完全に切り離されるようにするなど、コア同士が完全に独立したレイアウトとなるように注意する必要があります。また、2つのコアが同じ配線を共有することも避ける必要があります。

自動化によって高い生産性を維持

車載デザインでは以上のような手順が重要となりますが、これらを人手で実行していたのでは、特に車載分野の経験がない設計者の場合、非常に長い時間がかかってしまいます。ISO 26262への適合と市場での競争力を両立させるには、自動化が不可欠です。しかしそのためには、機能安全の意図をツールが理解できる形で表現する必要があります。そうして初めて、ツールはさまざまな安全機構を実装できるようになります。

ツールはまず、セーフティ・クリティカルなパスを解析して、安全回路の使用が必要なパスを特定します。そして特定したパスに対して、冗長性または耐障害性を高めたレジスタを自動的に挿入します。これらのレジスタは適切な分離を考慮して配置され、必要に応じて両側にタップが追加されます。こうすることで、これらのパスはSEUによるエラーの影響を受けにくくなります。他のツールは、ここで適用した変更を尊重する必要があります。というのも、一般にツールは冗長性を排除して最適化を試みようとする傾向があるためです。最後に、必要な回路がすべて正しく作成、配置、配線されたことを確認するための検証工程が必要です。

ここで1つ注意しておきたいのは、バックアップ・ツールを用意する必要があるという点です。事実、バックアップ・ツールを用意しておくことは、安全に関係するエレメントが正しく実装されたことを検証する際のベスト・プラクティスの1つに挙げられます。たとえば合成などのタスクを1つのツールだけを使用して実行していては、そのタスクが正しく実行されたかどうかを確認できません。そこで、確認するための別のツールが必要となります。合成に関して言えば、安全回路の冗長性を確認する機能をサポートするなど、バックアップの役割を果たす検証ツールが数多く存在します。