安全性とセキュリティを考慮したプレシリコンでのコンカレント・ソフトウェア開発と検証
Frank Schirrmeister
Cadence Design Systems, Inc.
Joe Fabbre and Max Hinson
Green Hills Software LLC
概要:実際のシリコンが入手可能となる前に、ソフトウェアとSoC双方の設計とテストを同時に行うことにより、組み込みデバイスの構築にかかる時間とコストを削減できます。信頼できるSoCモデルでアプリケーションを実行することは、それがより早期に開始できればよりよい、ということは、論を待ちません。シリコンの前にソフトウェアとSoCの開発パスをマージすることで、時間とお金を節約し、組み込み製品をより早く市場に投入できる大変貴重なチャンスを得ることが可能になります。ここでは、安全性とセキュリティが重要なシステムのためのSoCおよびソフトウェアのコンカレント開発と検証向けの新しいプレシリコンの一連のフローについて説明します。このフローは、SoC検証最初期の機能シミュレーション(Arm Fastモデルを備えた仮想プロトタイプ)からRTLエミュレーションおよびFPGAプロトタイプのステージを介してシリコンに至る一連のパスを連続的にサポートする、機能安全認証を取得したRTOSおよび高度なC / C ++開発ツールによって構成されます。この継続的かつ収束したフローにより、より多くの安全性、セキュリティ、および検証された信頼性がもたらされ、最初のシリコンの時点で主要な顧客とパートナーのための成熟したソフトウェア有効化基盤を構築することが可能となります。
I. 最初に
1兆台のデバイスが接続されている世界がそれほど遠くない未来に現実となると予想されていますが、このような世界ではハードウェア/ソフトウェアシステムにおけるセキュリティと安全性が極めて重要となります。ある調査[1]では、エラーを修正するための相対的なコストは、それが見つかったフェーズに大きく依存するとしています。要件フェーズと比較して、設計フェーズでのコストは3〜6倍、コーディングフェーズで10倍、開発およびテストフェーズで15〜40倍、受け入れフェーズで30〜70倍、テストおよび運用フェーズでは40〜1000倍になる可能性があります。図1 [2]では、自動車や航空防衛の分野でよく使用されるVチャートを使い、システムコスト観点からのソフトウェアの修正の影響を示しています。
図1:システム開発コストに占めるSW作り直しの影響
シリコン関連の検証とソフトウェア開発のコストは急速に増大しており、現在ではシステム全体の開発コストの60%以上を占めています。これは、16 nm以下のより小さなジオメトリノードで特に当てはまります[3]。さらに、シリコンIPプロバイダー、チップサプライヤー、システムインテグレーター、システムハウスの間の業界ダイナミクスの変革により、会社の境界を越えて、ハードウェアとソフトウェアをまたいで、より複雑な共同開発が必要になってきています。
ソフトウェアプロジェクトの場合、業界の平均バグ欠陥率はコード1,000行あたり約1〜25、マイクロソフトでの例では、内部QAでは10〜20、出荷されたコードで0.5、およびクリーンルーム開発による内部QAでは1,000行ごとに3つのバグ、出荷されたコードでは0.1となっています [4]。さらに、Google Chrome、FireFox、Linuxカーネル、OpenSSL、Python、PHPなどの広く使われるアプリケーションでの脆弱性との相互作用によっては、多くの欠陥や脆弱性は発見されません。
これらのバグ率は一見小さく見えるかもしれませんが、最新の自動車のような巨大で複雑なシステムでは、あっという間に大きな値となってしまいます。例えば、過去5年にわたって、1,000行あたり0.05件の脆弱性が発見され、かつ、0.15個の未発見の脆弱性があるとします。最近の自動車でのソフトウェアコード量は5000万行を超えており、これは、5年間で最大2,500の脆弱性がプラットフォームで発見されることを意味します。さらに、7,500もの発見されていない脆弱性が存在する可能性があり、ゼロデイ攻撃の大きな危険が危惧されます。
自動車などの多くの業界では、製品リリース日程は決まっています。プロジェクトでスケジュール遅延が発生すると、機能の削減や人員を増やして対応することは多くの場合、困難です。このとき、往々にして採られる解決策は、安全性とセキュリティを犠牲にすることです。残念ながら、これはよくあることであり、攻撃者に門戸を開く可能性があります。たとえば、自動車業界では、攻撃者が遠隔から車両をコントロールできるようなセキュリティホールがここ数年、明らかになっています。最高レベルの安全性とセキュリティを達成することは困難ですが、適切なシステム設計および開発プロセスにより到達は可能です。
II. ソフトウェアに対する安全性とセキュリティの考慮
ユビキタスな接続性とシステムの複雑化が進む時代において、強力なセキュリティなしに十分なレベルの安全性を実現することはもはや不可能です。適切に設計されたシステムアーキテクチャにより、この複雑さを緩和し、安全性とセキュリティを向上させることが可能となります。
安全でセキュアなシステムを開発するための最も効果的なアプローチは、システムをいくつかの独立したコンポーネントに分割することから始めます。そして、それぞれのコンポーネント毎に、そのサイズ、複雑さ、必要リソース、および安全性とセキュリティについての要件を分析します。安全性およびセキュリティの認証が必要なコンポーネントは、非常に小さく、シンプルで、システムの他のコンポーネントから隔離されていなくてはなりません。これにより、これらのコンポーネントは、テストと認証の処理がはるかに簡単になります。一方、重要ではないコンポーネントは、認証を受ける必要がないため、大きく複雑になりえます。
安全またはセキュリティが重要なコンポーネントを重要でないコンポーネントから適切に分離することは重要です。このような分離をきちんと行わないと、システム設計が損なわれる可能性があります。セパレーションカーネルは、アプリケーションレベルのプログラム間のリソースの分離を保証することで、重要なデバイスドライバーやアプリケーションと、安全性やセキュリティ観点からは重要度の低いアプリケーションを確実に分離できるようになります。さらに、セパレーションカーネルは、重要なリアルタイムアプリケーションを安全かつセキュアにゲストオペレーティングシステム上で実行するために必要な分離を提供します。図2では、そのようなアーキテクチャ例を示しています。
図2:分離されたアーキテクチャと仮想化の例
セキュリティは多面的であり、単なるアーキテクチャ設計以上のものに対処する必要があります。セキュアブート、キーストレージ/インフラストラクチャ、ソフトウェア更新システム、保存中/転送中のデータの暗号化のような機能は、安全でセキュアなシステムを作り上げる上では必須の要件です。図3は、ソフトウェアスタックにおける信頼チェーンが、ブートローダーにはじまりオペレーティングシステム、デバイスドライバー、ミドルウェア、ユーザーアプリケーションの一連の流れのなかでどのように構築されているかを示しています。
図3:ソフトウェアスタックにおける信頼チェーン
III. ハードウェアに対する安全性とセキュリティの考慮
ハードウェアの場合、安全性とセキュリティは、図4に示すように、セーフティメカニズムの組み込みやASIL規格に準じたハードウェアメトリックの達成を含め、従来の設計/検証と実装のフローにリンクする必要があります。安全性のメトリクス、電力-パフォーマンス-エリア(PPA)、検証時間、および自動化を考慮する必要があります。
機能安全計画は、機能要件と故障モードを収集し、それぞれのFIT値を推定し、故障モードをセーフティゴールへとマッピングします。故障影響解析の一連の作業の要件定義、計画、最適化、および実行は、設計時における機能安全の最適化、そして実装時における機能安全を意識した配置配線と相互作用されます。
図4:ハードウェアに対する安全性とセキュリティ
図5は機能安全検証管理の実施とハードウェア故障の分析の例を示しています。中央のコックピットから、作業全体のフローをコントロールし、各操作および作業が実行されます。フォールトセッションの結果は、シミュレーションやエミュレーションなどの動的エンジンでの実際の実行から収集され、蓄積され、検出分類などのさまざまな属性を可視化して表示します。
図5:機能安全検証キャンペーンの管理と解析例
ソフトウェアとハードウェアの開発者がシステム設計のプロセスの早い段階で一緒に作業できる場合、安全性、セキュリティ、パフォーマンスを最適化する機会はたくさんあります。ロックステップコア、ECCメモリ、スペクトル緩和、組み込みセルフテスト(BIST)などのいくつかの機能はソフトウェアではなくハードウェアで実装されるでしょう。これにより、設計、記述、テスト、認定されるべきソフトウェア量が減り、そしてバグの数が減ります。また、ハードウェアリソースに対するソフトウェアの必要性も減少します。
IV. ハードウェア-ソフトウェア早期統合開発によるシフトレフトの実現
図6および7では、様々な計算サブシステム、特定アプリケーション専用部品、インターコネクト、ペリフェラルなどのコンポーネントが、シミュレーション、エミュレーション、プロトタイピング等の動的検証エンジンに、どのように開発サイクル中にマッピングされるかを示しています。
図の左、設計フローの早い段階では、トランザクションレベルの仮想プロトタイプが行われます。レジスタ精度でのSystemC記述を使い、後工程でのボードレベルでの検証で使用するソフトウェアと同じものを実行することができます。ただし、この実行は、機能的には正確ですが、詳細なタイミングまでは表現していません。パフォーマンス解析のためには、サイクル精度に至るタイミング情報を使用できますが、モデルの精度とパフォーマンスのトレードオフを慎重に検討する必要があります。
図6:ソフトウェア開発におけるハードウェアモデルとしての動的検証エンジン
右に目を向けて、レジスタ転送レベル(RTL)では、シミュレーション、エミュレーション、プロトタイピングの手法を示していますが、実行パフォーマンス、デバッグ能力、精度、検証立ち上げ期間(実行モデルが機能的に正しく実行されるまでの時間)についてそれぞれの手法毎に異なるトレードオフが提供されます。シミュレーションおよびエミュレーションは、当初はハードウェア検証に焦点を当てている一方、プロトタイピングではソフトウェア開発に焦点を当てています。チップが入手可能になった時点で、ソフトウェア開発は実際のシリコンを使用するフェーズに移行できます。
図7に示されているように、ソフトウェアは、ハードウェアアブストラクションレイヤ、オペレーティングシステム、仮想化レイヤ、ドライバ、ミドルウェア、ユーザーアプリケーションのようないくつかのレイヤで、計算サブシステム上で実行されます。これにより、ハードウェアおよび初期の生産版ソフトウェアの同時および詳細なデバッグと分析が、シミュレーションまたはエミュレーションにより実行できるようになります。
自動車業界向けのISO 26262などの機能安全規格では、故障注入の技法を用いて安全性検証を改善することを推奨しています。たとえば、ハードウェア障害を挿入し、ソフトウェアがどのように応答するかを分析するようなことを行います。ただし、実際のシリコンに故障を注入することには制限があります。製品レベルの品質のソフトウェア開発をハードウェア設計のフェーズでより早く行うことで、故障注入がはるかに容易になります。製品レベルの品質のRTOSをハードウェアのシミュレーションモデル上で実行することにより、故障注入のプロセスが簡単になるだけでなく、テストできる範囲をより広くすることが可能です。
図7:ハードウェア/ソフトウェア協調検証・デバッグ
ハードウェアの検証が、実際に製品で使用される、安全性とセキュリティ上クリティカルなRTOSと伴に実行されることも重要です。多くの場合、シリコンが利用可能になる前に、新しいSoC設計で実行される唯一のソフトウェアはベアメタルまたは単純なLinuxディストリビューション程度です。これにより、ハードウェアが基本レベルで動作していることを確認できますが、この種のテストを回避してしまういくつかの問題が存在するでしょう。RTOSはLinuxとは異なるやり方でハードウェアを使用するため、チップが出来上がる前のシミュレーション/エミュレーションでRTOSを実行することで、これらの問題を明らかにすることができます。
V. 結論
Cadence Design SystemsとGreen Hills Softwareは、SoCおよびシステム設計者がハードウェア/ソフトウェアの協調設計・検証を行うための必要なツールをご提供してきました。図8はXcelium SystemCシミュレーションを土台としたCadence Virtual System Platformを使用したArmベースの仮想プラットフォームを示しています。ここで、仮想プラットフォームは、ソフトウェアを早期に立ち上げの一例として、OS(この場合はLinux)を実行しています。仮想プラットフォームはソフトウェア開発用のGreen Hills Multi IDEおよびデバッガに接続されています
図8:Green Hills Software製MULTI Debuggerを用いたLinuxのブート例
この環境では、実際のシリコンが出来上がる前に、C / C ++開発ツールと検証エンジン上でのRTOSを使用することができます。言い換えますと、ソフトウェアの開発スケジュール全体を「シフト=レフト」化することができるようになり、プレシリコン開発エンジン、仮想プロトタイピング、RTLシミュレーション、エミュレーション、FPGAベースプロトタイピングを活用して、ソフトウェアアプリケーション、ミドルウェア、RTOS、デバイスドライバーをシリコン入前に開発およびデバッグできるようになります。また、初期バージョンの開発ボードの絶対数は往々にして少ないことが問題になりますが、より多くの開発者の方が同時にコードを開発/テストできるような環境を構築できます。機能安全認証済みのRTOSおよびC / C ++コンパイラを使用することで、デザインプロセスの最初期から安全性とセキュリティを確保することが可能となり、実際にシリコンが提供された段にはより完全なソフトウェアを作り出すことが可能になります。プロセッサメーカーは、製品品質レベルのRTOSを搭載したテスト済みデバイスを発売することすら可能となります。
図9:TLMモデルの自動生成
このような仮想プラットフォーム環境の開発における主要な課題は、トランザクションレベルモデル(TLM)の開発です。TLMはソフトウェアが実行されるデザイン記述であり、プロセッサ、ペリフェラル、インターコネクトの構造を示します。さまざまな効率的なモデルの生成と組み立てを可能にするツールが各種提供されています。図9は、IP-XACT記述からSystemC TLMモデルのためのコードスケルトンを自動生成するフローを示しています。C-API、テストソフトウェア、インターフェースおよび機能ドキュメント、I / Oおよびレジスタ定義、read/write関数などが自動的に作成され、開発する必要があるブロックの持つべき機能の追加に注力することができます。
VI. 今後の展開
早期のハードウェア/ソフトウェア統合により、実際にシリコンが提供されるよりも前より、ソフトウェア/ハードウェア間の相互作用をより深く見通すことができるようになります。これにより、ハードウェア設計の品質が向上し、シリコンのリスピンを削減することで数百万ドルものコストの削減もあり得、最終的なハードウェアのパフォーマンス、安全性、およびセキュリティを大きく向上することができます。
ハードウェアの品質、パフォーマンス、安全性、およびセキュリティの向上は、システム設計者に大きなメリットをもたらします。ハードウェアに実装される機能が多く、その誤りが少ないほど、必要なソフトウェアは少なくなります。ソフトウェア開発の開始時間の前倒しと相まって、安全でセキュアな製品レベル品質のシステム提供を大きく前倒しすることが可能となります。
参考資料
- Error Cost Escalation Through the Project Life Cycle, NASA,
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf,
downloaded November 2019 - US Army Aviation
- IBS 2018, Volume 27, No. 7, Design Activities and Strategic Implications.
- Code Complete, Second Edition by Steve McConnell
翻訳:
テクノロジーセールスリード
システム&ベリフィケーション
後藤 謙治
Latest Issue
- 検証作業における人工知能との新しい協力関係
- 編集後記
- Virtuosoプラットフォーム、最新バージョン20.1をリリース
- AWR Design Environmentを活用した増幅器設計
- 集積型RFパッシブ・デバイスのモデリングについての考察 EMX Planar 3D Simulatorの紹介(前編)
- 集積型RFパッシブ・デバイスのモデリングについての考察 EMX Planar 3D Simulatorの紹介(後編)
- Cadence OrbitIO - 2.5D/3DICソリューション
- Sigrity2019 Hotfix002アップデートのご紹介
- デジタル設計・サインオフ関連webinarのビデオをCadence Online Support (COS) 上でオンデマンド配信しています!
Archive
2023 Issues
2022 Issues
2021 Issues
2020 Issues