1July 2014

Technical Article

AUTOSAR、マルチコアへ ～ そこに至る安全な道とは ～

マルチコアアーキテクチャー導入の最大の理由は、クロック速度を上げずに処理能力を増やせる点にあります。ただし、それが可能になるのは、アプリケーションソフトウェアが十分並列化できた場合に限られます。この話でよく引き合いに出されるのが「アムダールの法則」です。たとえばデュアルコアプロセッサーと並列化率が50%のソフトウェアの場合、これで増加する処理能力は、多くてもシングルコアのアーキテクチャーの30%に過ぎません。実現しうる最大の処理能力を発揮させるため、開発者はあらゆる

努力を払ってコア間のリソース共有を最小限に抑え、ソフトウェアモジュールを分配しなければなりません。これに関わるリソースとしてハードウェアレジスターが挙げられますが、ほとんどの場合はデータ領域もこれに関係します。コア間でのリソース利用で問題になるのは、アクセスの調停よりも、共有リソースへの同時アクセスが発生したときの待機状態をどう避けるかです。そのような状態では独立したデータ処理が失われ、並列処理は力を発揮できません。

ISO 26262に準拠した機能安全

　ISO 26262で規定されている機能安全要求の実装は、現在では自動車設計の開発プロセスにとって不可分のものとなって

います。ECUの機能に対する要求には、ハザード分析とリスク分析に基づいて安全との関連性が査定された後、適切なASIL (Automotive Safety Integrity Level) が割り当てられます。マルチコアのソフトウェアアーキテクチャーで安全関連の機能を実装する必要がある場合、この点はどうなるのでしょうか。これに答える前に、安全関連の多くのプロジェクトで使われているマルチコアプロセッサーのロックステップの概念について、いくつか要点を説明しましょう。

ロックステップモード

ロックステップモードでは、2つのコアが同じコードを実行します。独立したコンパレーターがその結果を比較し、違いがあればトラップを生成します。この次のステップはそのハードウェアと、ECUの安全コンセプトによって異なります。ハードウェアの設計は、トラップの発生後も安全な状態を保証するものでなければなりません。2つのコアが同じコードを実行するため、エラー処理を除いて、マルチコアソフトウェア用の拡張は不要です。言い換えれば、コアを複数使ってはいるものの、この状態ではマルチコアアーキテクチャーは、目的である処理能力の向上には貢献していません。

現在、車載ECUのソフトウェア開発における2大トピックと言えば、マルチコアプロセッサーへと向かうコンピューターアーキテクチャーのトレンド、そしてISO 26262で要求されている安全規格です。それぞれ単独でも十分に複雑なトピックですが、両者が1つになった時には、どのような事態が生じるのでしょうか。

2July 2014

Technical Article

マルチコアアーキテクチャーと分散ソフトウェア

マルチコアアーキテクチャーは処理能力の向上に使用できますが、安全関連のシステムにおいては、ASILデコンポジションなどのダイバーシティーアルゴリズムの実装に使われます。開発者はソフトウェアモジュールを、並列化可能性に基づき、安全コンセプトに従って、AUTOSARで定義されているOSアプリケーションに割り当てます。これはISO 26262で定義されているパーティショニングにあたり、それぞれがECU内の領域に対応します。そしてそこでは、モジュールが相互に干渉することなく (Freedom from Interference：無干渉)、動作できなければなりません。マルチコアのECUでは、OSアプリケーションは異なるプロセッサーコアに割り当てられます (図1)。開発者の立場から言えば、パーティショニングの目的が並列化であろうとデコンポジションであろうと、あまり違いはありません。その役目は、OSアプリケーション同士の無干渉を保証することです。これには、ランタイムモニタリングと、安全に関わるメモリー内容の誤修正を回避することが欠かせません。

ランタイムモニタリング

AUTOSARでは、スケーラビリティークラス2でランタイムモニタリングが規定されています。ただし、安全関連のアプリケーションの場合はこれでは不十分です。AUTOSARオペレーティングシステムは、過剰な実行時間を必要とするタスクや、割り込み不可の時間が長すぎるタスクがないかを調べます。しかし、タスクのシーケンスとタスクのトリガーを正しく安全に構成するのは、開発者にとって非常に複雑な作業であり、なかなか実現できるものではありません。TTTechとベクターはこれに代わる解決策を提供しています。それはASIL-Dに準拠して開発されたプログラムフローのモニターで、タスクの実行時間とシーケンス、そしてそれらに含ま

れている機能を監視するというものです。このプログラムフローモニターのインスタンスは、コアごとに作成されます。モニターは、ソフトウェアに組み込まれているチェックポイントを経由して、機能の実行に関する情報を受け取ります (図2)。プログラムの安全関連の部分が正しく処理された場合にのみ、これらのチェックポイントは正しい順序で、正しいタイミングで通過されます。中央のWatchdog Managerがすべてのモニターのステータス

メッセージを収集し、Watchdogのトリガーをかけます。。タスクはコアの境界を越えて相互に依存していることが多いため、各コアを個別に管理することは不可能です。さらに、AUTOSAR仕様では、全コアの一括再起動しか許可されていません。したがってWatchdog Managerは、そのECU全体に対する中央モジュールとして開発する必要があります。対照的に、実際のモニターは各コア上で独立して動作し、それぞれのステータス情報を、コアの境界を越えてWatchdog Managerに提供できます。

メモリー保護とECU内の安全な通信

完全な無干渉は、メモリー保護ユニット (MPU：Memory Protection Unit) がハードウェアに装備されている場合にのみ可能です。これによって、アプリケーションの各部分は、事前定義されたメモリー領域以外にはアクセスできなくなります (図3)。これらのメモリー領域はコアごとに個別に定義されますが、ハードウェアのリソース (RAMなど) は、他のコアと共有しなければなりません。ここで中心的な役割を果たすのがオペレーティングシステムです。オペレーティングシステムは、タスクの変更が生じるたびにMPUを再プログラムし、メモリーパーティションの変更を有効にする必要があります。オペレーティングシステムのこの部分はコンテキストの変更を担当しますが、同時にそれは安全関連コンポーネントであり、必要とされる最高水準の安全性レベルを、常に維持しなければなりません。

図1： 開発者はタスクをOSアプリケーションにまとめてグループ化し、それらをコアに分配します

3July 2014

Technical Article

これによってタスク間のデータ交換と、他のコアでの割り込みサービスルーチンが可能になります。

標準ソリューションの使用

このように、ISO 26262で定義されている機能安全をマルチコアECUで実現するのは楽な仕事ではありません。とはいえ、なにもゼロからスタートする必要はありません。すでにあるものを正しく利用すればよいのです。ベクターとTTTechは、ASIL-Dまでのマルチコアアーキテクチャーに対応するオペレーティングシステム、RTE、プログラムフローモニターをECU開発者向けに提供しています。一般に、マルチコアシステムはシングルコアのコンセプトのもの

よりはるかに複雑です。しかし、ベーシックソフトウェアの構成に関しては必ずしもそうではありません。プロセッサーコアへのソフト

そのためのアプローチの1つが誤った上書きからデータを守ることであり、もう1つが、タスクおよびプロセッサーコア間でデータが正しく交換されるようにすることです。AUTOSARのアーキテクチャーモデルでは、2つのタスク間のデータ交換は仮想機能バス (VFB：Virtual Function Bus) を介して行われます。VFBはランタイム環境 (RTE：Runtime Environment) によって実装されます。

RTEには、その他にもマルチコアアーキテクチャーを持つ安全関連ECUに対して充足すべき要求があります。メモリーパーティション間の通信を許可すると同時に、その通信パスがコアの境界をまたぐ (コア間) のか、それとも同一コア内で実行されている2タスク間のもの (コア内) なのかを識別できなければならないのです。コア間のデータ転送には新たな調停の仕組みが必要になります。そこでオペレーティングシステムは、IOC (Inter-OS-Application Communicator) という機能をRTEに提供します。

図2：アプリケーション内のチェックポイントに加え、フローを監視することで正しいシーケンスを保証します

図3：メモリー保護ユニットにより、アプリケーションの各部分は事前定義されたメモリー領域以外にはアクセスできなくなります

4July 2014

Technical Article

提供元：

見出し画像および図1～ 3：Vector Informatik GmbH

リンク：

ベクターのAUTOSARソリューションwww.vector-japan.co.jp/autosar-solutions

ベクター･ジャパンwww.vector-japan.co.jp

Dr.-Ing.Helmut Brock

1999年にVector Informatikに入社、現在はオペレーティングシステムのプロダクトマネージャー。

Dipl.-Ing.(FH) Joachim Kalmbach

2006年にVector Informatikに入社、現在は組込ソフトウェア部門のプロダクトマネージャー。専門分野はAUTOSARとマルチコア。

ウェアの分配が済めば、あとは最適なツールを利用することで、シングルコアアーキテクチャーに負けないほど簡単にマルチコアシステムを構成できます。開発者はタスクや割り込みサービスルーチンなどをグループ化してコンテナ、すなわちOSアプリケーションにまとめます。そしてそれらをプロセッサーコアに割り当てます (図1)。ベクターの構成ツールであるDaVinci Configurator Proを使用すれば、この作業をわずか数クリックで完了できます。ソフトウェアモジュール間の適切な通信方法 (コア内/コア間) の構成は、統合されているRTEジェネレーターが自動的に処理します。つまり、マルチコアECU用の数々のサポートが、ベーシックソフ

トウェアや構成ツールなどの形ですでに利用できるようになっているのです。ソフトウェアアーキテクチャーの作成と、プロセッサーコアへのソフトウェアコンポーネントの分配をツールで的確に支援することははるかに難しく、現状では一般に、バリアントの評価までが限界です。当面は、ECU開発者の専門知識と経験に頼らざるを得ない状況が続くのではないでしょうか。

本稿は2014年6月にドイツで発行されたElektronik automotiveに掲載されたベクター執筆による記事を和訳したものです。

執筆者：

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社営業部 （組込ソフトウェア関連製品） TEL: 03-5769-7808E-Mail: EmbeddedSales@jp.vector.com