2015年に発売したAUTOSAR開発体験キットには、「基本編」「COMスタック編」の2つのパッケージがありましたが、2020年11月に新パッケージとして「メモリ保護編」を発売しました。本コラムでは、この「メモリ保護編」についてご紹介します。
メモリ保護とは
第1回のコラム(※1)で説明したように、近年、自動車に搭載されるECUの高度化、複雑化が進んでいます。しかし、ECUの数が増えたことにより、物理的に自動車内に配置するスペースが枯渇するという問題も起きています。そこで、複数のECUの機能を1つのECUに統合する「ECU統合」が必要となってきています。AUTOSARを用いて開発されたECUであれば、ECU統合する際、各ECUに配置されたSW-C(Software Component)を1つのECUにまとめればよいので、SW-Cの修正は不要となります(AUTOSARのメリット)。しかし、SW-C単位で分割されていても、1つのマイコン上で動作させるには、コアやメモリを共有して使用することになります。そのため、あるSW-Cの不具合が他のSW-Cの動作を阻害する、不具合の伝搬を発生させる恐れがあります。例えば、安全レベルの異なるSW-Cが混在するケースを考えてみます。安全レベルの低いSW-Cに不具合があり、安全レベルの高いSW-Cのメモリ領域を破壊してしまい、その結果、人命等の安全を脅かしてしまうといった致命的な問題を引き起こす可能性があります。すべてのアプリケーションを高い安全レベルで開発できればよいですが、一般的に安全レベルの高いソフトウェアは開発コストが高いので、ECU全体の開発コストが肥大化する問題があります。車載システムでは、機能安全という考え方を用いて安全性を確保することが一般的となっています。車載向けの機能安全規格であるISO26262では、FFI(Freedom From Interference)により、前述の不具合の伝搬を防止することが求められています。FFIは、異なる安全レベルのアプリケーションが1つのECUに混在する場合に、安全レベルの低いアプリケーションから安全レベルの高いアプリケーションへの従属故障を防ぐ仕組みであり、以下の影響がないことを求めています。
・メモリ(破壊や意図しないアクセス)
・タイミング(処理実行の妨害)
・通信(情報のやりとり妨害)
上記において、1つ目のメモリに関する従属故障を防止する仕組みが“メモリ保護”です。前述のように、不正なメモリ領域破壊などの不具合が発生し、他の安全レベルのアプリケーションが管理するメモリ領域へアクセスしようとしても、メモリ保護機能により、不正なアクセスを防止することで、故障の伝搬を防止することが可能となります。
AUTOSARにおけるメモリ保護
MPU(Memory Protection Unit)
AUTOSARにおいて、メモリ保護はOSの機能として実現されます。OSの仕様書(※2)では、MPUを用いてメモリ保護を実現することが規定されています。一般的に、MPUを搭載したマイコンでは、処理実行時の動作モードとして、特権モードと非特権モードがあり、非特権モードの場合、MPUの保護領域で許可したメモリ領域およびアクセス権でのみ、メモリアクセスが可能となります。OSがタスク実行時にMPUを制御することにより、意図しないメモリアクセスを防止することができ、メモリ保護を実現できるというわけです。
※２「Specification of Operating System AUTOSAR Release 4.0.3」
OSアプリケーション(OSAP)
OSによるメモリ保護を行うには、まずタスクやアラームといったOSオブジェクトを、OSアプリケーション(以後、OSAP)というグループに分けます。OSAPには、信頼OSAPと非信頼OSAPの2種類があり、信頼OSAPは特権モードで動作し、非信頼OSAPは非特権モードで動作します。非特権モードにおいては、MPUで許可したメモリ領域にのみアクセス可能となるため、他のOSAPが管理するメモリ領域を保護することが可能となります。つまり、高い安全レベルのSW-Cを信頼OSAP、低い安全レベルのSW-Cを非信頼OSAPへ割り当てることで、FFIを実現することができるわけです。異なる非信頼OSAP間でもメモリ保護は有効なので、3段階以上の安全レベルが混在する場合でも、FFIに対応することが可能です。
「メモリ保護編」の紹介
メモリ保護の概念は分かっていても、実際に使おうとすると、不明なことが多くあります。
・MPUの仕様はマイコンによって異なるけど、 OSのメモリ保護はどうやってコンフィギュレーションすればいいの？
・非信頼OSAPからアクセス可能なメモリ領域や、アクセス権などはどのように決めればいいの？
・AUTOSARにおけるメモリ配置の手法であるメモリマッピングは、どのような仕組みで意図したアドレスへコードや変数を配置するの？
AUTOSAR開発体験キットの「メモリ保護編」は、上記のような不明点の解決にご活用いただけます。
開発環境
「メモリ保護編」は、AUTOSAR開発体験キットの「基本編」に同梱している評価ボードを使用します。この評価ボードのマイコン(RX63N)には、MPUが搭載されています。また、TOPPERSプロジェクトからは、メモリ保護に対応したAUTOSAR OSであるATK2-SC3(※3)が公開されています。当社は、ATK2-SC3をRX63Nにポーティングすることにより「メモリ保護編」を開発しました。「メモリ保護編」では、RX63Nを題材として、MPUによるメモリアクセスの制御方法についても解説しています。
コンフィギュレーション
AUTOSARでは、非信頼OSAPの動作時にメモリ保護を行うこと自体は規定されていますが、どのメモリ領域へアクセス可能とするかを、どのようにコンフィギュレーションするかは規定されていません。メモリ保護のコンフィギュレーションは「Basic Softwareのコンフィギュレーション仕様の仕組み(※4)」で説明したように、ベンダごとに独自のコンテナ／パラメータを規定することで実現されています。
例えば、TOPPERS/ATK2では、セクション単位、オブジェクト単位、メモリ領域単位など、かなり細かいコンフィギュレーション方法が規定されています(※5)。ルネサスエレクトロニクス社のRV850では、メモリ領域単位でのコンフィギュレーション方法が規定されています(※6)。
「メモリ保護編」では、使用するコンパイラ仕様による制約と、直感的に設定内容を理解できることから、メモリ領域単位でのコンフィギュレーション方法により学習を行います。
※4 「AUTOSARによる開発 ～Basic Softwareのコンフィギュレーション仕様の仕組み」
※5 「ATK2外部仕様書」
※6 「RV850リアルタイム・オペレーティング・システムユーザーズマニュアル 機能編」10.1.3 メモリ・アクセス保護機能
メモリマッピング
メモリ保護を実現する際には、各関数や各変数を、どのメモリ領域に配置するかが重要なポイントとなります。
「メモリ配置の仕組み(※7)」で説明したように、AUTOSARでは、メモリマッピングという独自のメモリ配置の仕組みがあります。「メモリ保護編」では、このメモリマッピングを使用したメモリ配置に対応しており、メモリマッピング自体も学習することができます。
※7 「AUTOSARによる開発 ～メモリ配置の仕組み Memory Mapping（メモリ マッピング）」
メモリ保護の学習用に、是非「メモリ保護編」をご活用ください！
