セーフティクリティカルなアプリにおけるマルチコア競合の解決方法

クルマ専用低消費電力GPU IPを立ち上げたImagination Technologies

マルチコアでセーフティクリティカルなシステムを構築する際の課題

航空機器向けのセーフティクリティカルなシステムにおいて、その計算能力のスループットを上げながらサイズ、重量、消費電力を小さくできるという利点から、マルチコアプロセッサの採用が徐々に進んでいます。

マルチコアならば多数の機能を統合型航空電子機器(IMA)に組み込めるようになります。IMAの目標はソフトウェアの更新・改善・追加を通じて、効率的かつ信頼性の高いシステム機能を、手頃なコストで保守・増強できるようにすることですが、この目標を達成するのは非常に難しい場合があります。

その原因は、複数のプロセッサコアが同じ共有リソースに同時にアクセスしようとすることで、変動性が大きくなるからです。セーフティクリティカルなアプリケーションで第一に懸念されるのは、そのような共有リソースの競合によって、あるコアで実行中のアプリケーションが別のコアで実行中のアプリケーションに競合し、確定性、サービス品質、そして究極的には安全性にマイナスの影響を及ぼしてしまうことです。マルチコア競合を軽減する汎用的な方法がなければ、ソフトウェアを変更または追加するごとに大がかりな再テストとシステム全体の分析が必要になってしまうため、IMAの目標に反することになります。
シングルコアでの解決方法

シングルコアのプロセッサでは、複数個のセーフティクリティカルなアプリケーションが同じプロセッサ上で実行され、メモリ空間とプロセッサ時間はアプリケーション間で厳密にパーティショニングされます。

メモリ空間のパーティショニングはプロセッサのメモリ管理ユニット(MMU)の監視下で、メモリの重複しない部分を、特定時間内に実行されるアプリケーション専用として割り当てます。タイムパーティショニングはメジャーフレームと呼ばれる一定の時間枠を、パーティション時間窓という一続きの小時間枠に分割します。アプリケーションはそれぞれ1個以上のパーティション時間窓を割り当てられ、その窓の長さと個数はアプリケーションの最悪実行時間(WCET)と必要な繰り返し回数によって決まります。オペレーティングシステムはその割り当て時間中、アプリケーションがプロセッサコアにアクセスできることを保証します。
マルチコア競合の原因

マルチコアプロセッサでは、アプリケーションはコアごとにタイムパーティショニングされますが、他のコアにあるアプリケーションと同時に実行することができます。問題は、同時に動作するアプリケーションがプロセッサ上で共有されているリソースにアクセスしなければならない点です。

マルチコアプロセッサのアーキテクチャにはメモリコントローラ、DDRメモリ、I/O、共有キャッシュ、そしてそれらをつなぐ内部ファブリックなどの共有リソースが必ずあります(図1)。あるプロセッサコアが使用中の共有リソースに別のプロセッサコアがアクセスしようとすると、共有リソースの競合となります。その結果発生する遅延による影響で、重要度の高いアプリケーションは所定の機能を時間制限内に実行することができなくなるかもしれません。DMAエンジンはコアごとに並列で実行できるため、これも競合の発生源となりえます。

マルチコア競合の問題に直接対応するため、FAA、EASA、TCCAその他の航空当局が支援するCertification Authority Software Team(CAST)はマルチコアシステムの指針を「CAST-32A」というポジションペーパーの形で公表しました。

CAST-32Aはマルチコアプロセッサを使用する場合の懸念を解消するために必要な目標10個を規定しています。その中でマルチコア競合に直接関係する目標の1つを達成するには、1つのプロセッサコア上で実行されるソフトウェアアプリケーションに影響を与えうる競合経路をすべて特定し、選択した緩和手法の効果を検証しなければなりません。

本当の意味でマルチコア競合源をすべて特定するには、マルチコアプロセッサのサブシステムについて、どう動くか、どうやり取りするかなど深い知識が必要です。そういった知識にはDDRの構造、メモリコントローラのスケジューリング優先度、キャッシュ置き換えポリシー、マルチコア・インターコネクトのアービトレーションの仕組み、ハードウェア初期化と設定オプションなど、ハードウェアについての詳細な知識が含まれます。

マルチコア競合とその緩和方法について理解を深めることは、安全性だけでなく、セキュリティに関連することでもあります。あるアプリケーションの可用性が他のアプリケーションの影響を受けうる場合は、安全でもセキュアでもありません。もう少し深く掘り下げると、色々なセキュリティ攻撃が実行されるのに必要とされる隠れたタイミングは、多くの場合マルチコア競合の原因と同じです。マルチコア競合はしっかりと押さえ込むことが肝心です。

●マルチコアプロセッサで競合が発生した際の影響を考える
マルチコア競合の影響は甚大になりうる

このようなマルチコア競合への懸念は、共有リソースへのアクセスは1回で1マイクロ秒にも満たないことが多いので、考えすぎではないかとも思えます。

しかしこの小さな変化はすぐに積み上がっていきます。また、競合が繰り返されると一時的なサービス拒否にもなってしまいます。

リソースアクセスを公平にしたいちばん簡単な形で考えると、2個のコアが同じリソースに、同時かつ同じ方法でアクセスしようとした場合、各コアはリソースの帯域幅を半分ずつ取ります。同様に、コアが4個だった場合はそれぞれ4分の1ずつ取ります。設計保証レベルがもっとも高い(DAL A)アプリケーションに4倍長く割り当てるだけでは妥当とはまったく言えません。さらに、アクセスは必ずしも同じタイプではなく、その割り当てアルゴリズムも誰もが望むような公平なものとは限らないことも、事態を複雑にします。

複数のコアがDRAMにアクセスすることを考えます。DDRコントローラの共有リソースアービトレーションとスケジューリング優先度では、公平性は担保されず、競合の影響は一次関数的な増え方ではないことがあります。

動作の種類とその組み合わせ(リード、ライト、コヒーレンシートラフィック、ブロードキャストなど)や、どのコアで実行されているかなどによって、競合の影響は大きく変わります。例えば、メモリへの書き込み動作は、アーキテクチャによっては読み込みに対して不釣り合いに大きな競合をすることがあります。

マルチコア競合によって長くなる最悪実行時間(WCET)はせいぜい2～3倍程度だという主張もありますが、Power Architectureのコアでのテストでは、競合するコアが1個だけでも、競合を受けるコアのWCETが8倍にもなってしまう場合があることが判明しました。競合源が複数のコアからDDRメモリにオンチップのインターコネクト経由でアクセスするだけの場合でも、クアッドコアのシステムでWCETが12倍以上になる現象が見られました。このような増え方は、同時に実行されるI/OアクセスやDMAエンジンの影響では説明がつきません。
コア当たりのメモリ帯域幅

図2は、別々のプロセッサ上にあるDAL AとDAL CのアプリケーションがDRAMに同時にアクセスしようとした場合の、メモリ帯域幅の例です。

理想としては、DAL Aのアプリケーションが帯域幅の大半を取るべきです。競合緩和を何もしなければ、帯域幅は均等に分割されると予測されます。しかし、Power Architectureで観察された実際の結果では、DAL Cのプロセスがある特定の動作を実行する場合、競合するコアが1個だけでも、帯域幅の大半、DAL Aプロセスの8倍近くまで占有してしまうことが分かります。

マルチコア競合を緩和する方法

マルチコア競合を軽減・緩和する方法には色々あります。理論的には、できる限り競合を減らして競合緩和の作業を簡単にするのが理想です。実際のところ、競合軽減手法のほとんどでは、必然的にアプリケーションが厳しく制限されたり、システム全体の効率やスループットが大きく削られたりします。

例えば、各コアで実行されるアプリケーションをDAL B以上に制限した場合、よくテストされた、信頼できるアプリケーションだけが存在し、暴走や未知の競合などは起こりにくくなると考えられます。I/Oをすべてタイムパーティショニングされたコア1個に移動させるという方法もありますが、この場合既存のアプリケーションを書き直したり他のコアの稼働率を下げたりする必要が出てきます。この方法でI/Oアクセスの問題は解決できても、DDRメモリの競合というさらに大きな問題には対応できません。よほど小さくてコア内部のキャッシュメモリも使い切らないのでもない限り、どんなアプリケーションでもDDRメモリにアクセスしなければなりません。

DMAエンジンは注意深い管理で対応可能なリソースです。I/Oのタイミングを管理して、DMA転送を実行することで、DMAエンジンが原因となる競合は減らせます。

マルチコア競合の大部分は、緩和することができます。しかし減らすことはできません。緩和のやり方は、「対症療法」から共有リソースの利用を監視して厳しく制御する細かい粒度の共有リソースアクセス自動制御まで幅があります。単純ですが非効率的なやり方としては、最大の競合を想定してWCETを新たに見積もって、そのWCETに対してパーティション時間窓を与え、アプリケーションがその時間窓内で完了するかどうか徹底的にテストします。この方法の最大の欠点は、もっと有効な方法ならWCETが競合のない場合の1.5倍程度で済むところ、10倍近くにもなってしまい、マルチコアのスループットがほとんど活かせないことです。また、この方法ではアプリケーションを更新または追加した場合WCETも変化するのでリグレッションテストが必要となり、メンテナンスコストも高くなることがあります。

もっと賢いやり方は、共有リソースへのアクセスを監視し、コアに割り当てられた閾値を超えた時にアクセスを制限する方法です。この方法は、マルチコアプロセッサのほとんどに用意されているハードウェアカウンタで実現できる上、マクロレベルでは比較的シンプルなやり方です。アプリケーションごとに、そのパーティション時間窓に対して閾値が設定され、その閾値を超えたら、そのアプリケーションは一時停止されます。この方法は粒度が大きく、不正な動作をするアプリケーションを捕まえるのには適していますが、もっとよくある事象である、重要度の低いアプリケーションが重要度の高いアプリケーションから帯域幅を奪ってしまうという状態には効きません。それには、パーティション時間窓よりもずっと短いタイムスライスに閾値を設定する、細かい粒度での制御が必要です。

細かい粒度の制御でなら、重要度の低いアプリケーションは共有リソースへの帯域幅を理想的な閾値まで抑えられ、重要度の高いアプリケーションはそのパーティション時間窓の最初から最大の帯域幅が割り当てられます。

●マルチコア競合を緩和する方法
マルチコア・リアルタイムOS「INTEGRITY-178 tuMP」

マルチコア・リアルタイムOS「INTEGRITY-178 tuMP」は、高いプロセッサ使用率、アプリケーションの移植性、および真のIMAを実現しながらマルチコア競合を緩和し、DO-178 B/C DAL A準拠のセーフティクリティカルな動作を保証するという課題をクリアすることを明確に目指して開発されました。INTEGRITY-178 tuMPはARM、Intel、Power Architectureをサポートし、IMAの信条である統合性、移植性、メンテナンスおよび再利用による高い機能性と低いライフサイクルコストの実現を約束します。

リアルタイムOS INTEGRITY-178 tuMPは安全性とセキュリティの両方で認証を得た高保証オペレーティングシステムです。メモリ空間や処理時間、プロセッサリソースをパーティショニングしてセーフティクリティカルなアプリケーションがリアルタイムの期限までに完了することを保証します。

2002年に、INTEGRITY-178はDO-178 Level Aの目標準拠を認証された世界初の商用のパーティショニング強制リアルタイムOSとなりました。大部分のコードが再利用できる形で、マルチコア・リアルタイムOS INTEGRITY-178 tuMPが2010年に顧客向けにリリースされました。

今のところ、Future Airborne Capability Environment(FACE)Technical Standardの最新版、Edition 3.0に準拠した唯一のリアルタイムOSです。マルチコアプロセッサ上のコアすべてで高い稼働率を達成できるのは、リアルタイムOSでサポートされる色々なマルチプロセシング・ソフトウェアアーキテクチャから選んでアプリケーションを複数のコア上で同時実行できるからです。システムソフトウェアアーキテクトは、マルチコア・リアルタイムOS INTEGRITY-178 tuMPを使えば非対称型マルチプロセシング(AMP)、対称型マルチプロセシング(SMP)、バウンドマルチプロセシング(BMP)などを自由に組み合わせて、タイムパーティショニングした形でマルチコアをサポートすることができるようになります。

BMPはSMPを拡張して制約を加えたもので、アプリケーションのタスクを特定コアのグループから移動しないように拘束し、複数のコアの共時動作を厳密に制御しやすくなります。個別のIMAアプリケーションのAMP、SMP、BMPの動作条件はビルド時に定義されます。これらの定義は、パーティションスケジュール内でいつ、どのように実行されるかも含めて、システムのソフトウェアアーキテクトが固定的なシステム設定ファイルを使って管理します。BMPのサポートはARINC 653 Part 1 Required Services (Supplement 4) の最新バージョンに準拠することが求められ、INTEGRITY-178 tuMPはSupplement 4に準拠している唯一のARINC 653リアルタイムOSです。
細かい粒度帯域幅割り当てでマルチコア競合を緩和

前述のように、マルチコア競合緩和の最善策は共有リソースの帯域幅を各コアに割り当て、その割り当てを非常に細かく分けた時間枠で使わせることです。こうした細かい粒度の監視と共有リソース帯域幅の強制割り当ては今のところオペレーティングシステムレベルでなければできません。

INTEGRITY-178 tuMPは帯域幅割り当て・監視(BAM)機能を備え、競合経路を観察し影響を緩和します。600人月を超えるマルチコア競合解析と緩和方法の研究開発の成果を元に、BAMはチップレベルで各コアに接続されているインターコネクトの帯域幅割り当てを監視します。

チップレベル・インターコネクトはコアと共有リソースとの間のやり取りの中心にあるものなので、共有リソースの監視と使用制限強制をするのに最適な場所です。ハイレベルのフォルト検出による従来のやり方とは異なり、Green Hills SoftwareがINTEGRITY-178 tuMPに実装した帯域幅割り当て・監視機能の内部構造は、非常に短い時間でのコアの共有リソース制限を可能にします。この手法では、BAMはパーティション時間窓の期間中にリソースを食うコアの帯域幅を絞ります。そのため、それ以外のプロセスは、そのリソースを食うコアが割り当てられたパーティション時間窓を使い切るのを待つ必要がなくなります。

システムアーキテクトはアプリケーションの機能要件や設計保証レベルを元に、各コアにどのくらい帯域幅を割り当てるか判断します。特定のコアのアプリケーションで所定のBAM時間内に帯域幅の閾値に達したら、そのコアは次のBAMが定義する時間単位が来るまで共有リソース使用から除外されます。この仕組みでは、コア0で実行されるDAL Aのアプリケーションには全帯域幅の60%を割り当て、残り3つのコアにはそれぞれ15%、15%、10%のように割り当てることができます(図3)。BAMはDO-178C DAL Aを目標として開発されており、競合の問題を緩和してシステム統合ができるようになります。

帯域幅を的確に割り当てるには、アプリケーションの解析とテストが必要です。その解析を支援するために、Green Hills Softwareは競合生成ライブラリ、DMA生成ライブラリ、および帯域幅レポートライブラリを用意しました。競合生成ライブラリ、およびDMA生成ライブラリはプロセッサ・アーキテクチャに合わせてカスタマイズされ、数百もの競合プロファイルから最悪シナリオの競合を模擬できます。特定のアプリケーションが使用していないコア上でこれらのライブラリをアプリケーションとして同時に実行すると、マルチコアの最悪実行時間(WCET)が新たに設定されます。DMAエンジンとその他のコアの両方で最悪の競合を生成する機能がないと、マルチコアのWCETを安易に過小評価してしまうことがありえます。

帯域幅レポートライブラリは競合生成ライブラリとDMA生成ライブラリを使って、DMA競合の考慮後に空き帯域幅を測定により確認します。空き帯域幅を知ることで、BAMの帯域幅割り当て閾値を決められるようになります。帯域幅レポートライブラリは指定の数のコア上で競合生成ライブラリとDMA生成ライブラリを同時に実行します。数百の競合プロファイルの中から特定のサブセットを選んで、想定用途に近い計測ができるようにしたり、カスタムの競合プロファイルを自作したりできます。空き帯域幅を左右するのは、プロセッサのモデルに加えて、メモリの種類、クロック周波数、設定レジスタ、それにどの競合プロファイルを選んで最終用途に調整したか、などです。
マルチコア競合緩和の実際

以下の2つの図は、BAMを有効にした時にタイミング特性がどう改善されるかを示したものです。データはPower Architectureのクアッドコアプロセッサで計測したもので、アプリケーション実行時間はシングルコアで実行し、他のコアはアイドル状態の場合の実行時間との比です。

テストするアプリケーションはコア0で実行され、残りのコアで競合生成ライブラリが実行されます。図4は競合するコアが増えるにしたがって、コア0のアプリケーションの実行時間がどう延びていくかを示しています。コア1個で競合生成ライブラリが実行されると、アプリケーション実行時間は7倍以上に跳ね上がります。競合するコアがもう1つ、また1つと追加されると、実行時間は13倍を超えるに至りました。この最悪条件の動作は、平均的なケースで予想される2倍、3倍、4倍と線的に増えていくのよりもさらに悪いものです。

競合を緩和するために、システムアーキテクトはBAMで各コアに最大帯域幅割り当てを設定します。競合するコアの使える帯域幅を制限すると、テスト対象アプリケーションの実行時間も短くなり、競合コア数が増えてもほぼ一定になりました。テスト対象アプリケーションに共有リソースの総帯域幅の80%を割り当てると、実行時間はシングルコア動作の場合の1.4倍程度になり、さらに同時実行コアが増えていってもその水準を維持しました。図5は、80%割り当ての時に実行時間が1.4倍で、割り当てが50%の場合、25%の場合の性能も示しています。注目すべきことに、25%の割り当てで、他のコアとほぼ同じ割合だった場合でも、アプリケーションは競合緩和なしの場合の2.5倍もの性能を出しています。

BAMでクリティカルなシステムのコア使用率を最適化

競合生成ライブラリ、DMA生成ライブラリ、帯域幅レポートライブラリ、およびBAM実行時間機構は、システムインテグレータがマルチコアの最悪実行時間の判断、競合の緩和、マルチコアシステムの認証をするために必要なツールです。

Green Hillsが提供するこの競合緩和機能は、認証リスクを軽減し、検証・解析業務を合理化して開発期間を短縮するほか、長期間のメンテナンスとシステム増強にかかるコストを削減します。

このようなマルチコア競合緩和策がないと、アプリケーションの追加・更新後のシステム再検証ではすべてのアプリケーションをひとつずつ再検証しなければならない可能性が非常に高くなります。その結果、システムレベルの解析手法でIMAの意図を達成することが難しくなります。マルチコアのIMAシステムでIMAアーキテクチャの利点をすべて活かそうとするなら、帯域幅割り当てや監視などの機能は必須です。

セーフティクリティカルなシステム全体で考えると、BAMはリスクを軽減してクリティカルなシステムの開発・統合・配備・保守をシンプルにします。BAMはクリティカルなシステムでコア使用率を最適化できるので、省面積、軽量、省エネルギーを実現するだけでなく、計算能力の余裕も生まれます。この帯域幅割り当て・監視機能はIMAのOEMや開発者にとって必須の機能です。