AUTOSAR CP入門（その1）RTOSがAUTOSAR理解の壁になっている？：AUTOSARを使いこなす（24）（5/5 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第24回からは、AUTOSAR CP（Classic Platform）の導入拡大の大きな障壁になっているであろう、スケジューラ方式による開発からRTOSを用いた開発への移行で求められる知識をまとめた「AUTOSAR CP入門」をお送りする。

[櫻井剛，MONOist]

1.1.3 AUTOSAR RTEを使用する場合

　さて、AUTOSAR RTEを使用する場合はどうなるでしょうか。

　実は、ツールにInitializationFunctions()やPeriodicFunctions()をRunnable Entity（RE）として登録し、そのトリガー条件や後述のI/F設定などを行えば、それに基づいて、RTOSの場合でのTask Bodyのコード部分（つまり、トリガーが発生したらREを呼び出すメカニズムの部分）をRTEが生成してくれます。REは、AUTOSAR CPでの処理の最小実行単位であり、SW-Cの構成要素の1つです。また、ソフトウェア再利用における最小単位であると言うこともできます^※7）。

※7）古くは構造化設計の時代からも、同じ周期で実行される処理だからといって、機能的な結合のないものをひとまとめにして開発すべきではないが、その後タスクとして組み上げる際にはひとまとめにしてもよいとされてきました（もっと古い文献もあるかと思いますが、例えば、H. Gomaa：A software design method for real-time systems, Communications of the ACM, Vol. 27, Issue 9, pp. 938-949, 1984-09）。スケジューラ方式でのトリガメカニズムと処理の実体が混然一体となったようなものや、RTOSでのタスク／ISRは、ソフトの再利用の単位としては必ずしも最適ではありません。スケジューラ方式を用いた再利用対象の現在のソフトウェアに対して、「再利用の都度の微修正」が発生するなど、「再利用における手間」が発生しているのでしたら、まだ改善の余地がありえます。AUTOSAR RTEを用いることは、よりよい再利用への一歩となり得ます。

　なお、ツールに入力したトリガー条件や後述のI/F設定などの情報は、そのREに対するインタフェース仕様としてAUTOSAR XML形式で記録されます。それらの記録された設計情報から、ISR／Task Body、必要であれば設計書（別途Wordなどで設計書を起こす必要はありません）、そして、REそのものコードスケルトン生成を行うこともできます。

　また、設計情報に変更が必要となった場合には、ツール上で変更すれば、ISR／Task Bodyなどにも反映することができます。よくよく考えれば、ISR BodyやTask Bodyは、意図した処理を起動するための枠組みでしかありませんので、できるだけ人手をかけたくない部分です。その生成を自動化することで、皆さんが取り組みたい部分の開発に注力しやすくなる、ということもできるでしょう。

　以下に参考として、スケジューラ方式でのソフトウェア構造のどの部分が、Osでのタスク／ISRや、RTE上のSW-CでのREに対応するのかを挙げておきます（図5〜7）。

図5　典型的なスケジューラ方式（図1）とタスク／ISR、Runnableとの対比――a．最も単純な例［クリックで拡大］

図6　典型的なスケジューラ方式（図2）とタスク／ISR、Runnableとの対比――b．マイコン内外で不定期に生じるイベントを割込みで受け付ける場合［クリックで拡大］

図7　典型的なスケジューラ方式（図3）とタスク／ISR、Runnableとの対比――c．マイコン内外で不定期に生じるイベントを割込みで受け付け、周期を待たずに処理する場合［クリックで拡大］

1.2 トリガーの生成

　マイコン外部やHW Timerなどからの割り込みは、当然ながらマイコンハードが生成し、割り込み処理のトリガーに使われます。これは、スケジューラ方式でも、RTOS／AUTOSAR RTEを使用する場合のいずれでも同様です。

　しかし、それ以外、つまり「マイコンの内側」部分については、各方式で異なります。

1.2.1 スケジューラ方式の場合

　スケジューラ方式では、割り込み処理側から周期処理／イベント処理（メイン処理）への通知方式は、それぞれが考えて実装しなければなりません。そして、対応する要因と通知方式は実装によりまちまちでしょうから、「異なる設計思想に基づくスケジューラ」間でのソフトウェア再利用の際には、いちいち合わせ込む必要が出てきます。

1.2.2 RTOSを使用する場合

　RTOSを使用する場合には、タスクを起動要求する（Activate Task：図6、7中では「Act」と省略して表記）、またはイベント通知により動作再開させる（Set Event：図6、7中では「Event」と省略して表記）、という2つの標準化された方式がRTOSにより提供されており、それらを使い分けます。また、HWタイマーはマイコンごとに実装が異なりますが、それを模倣し一般化・抽象化したAlarm（図6、7中では「Al」と省略して表記）というメカニズムも提供されています。

　なお、タスク起動要求とイベント通知のどちらも、おおよそ「ハードウェアに用意された割り込み要求フラグ（IRQ）による割り込み要求通知を、OSにより模倣したようなもの」と考えてみると分かりやすいと思います（ここは少々乱暴が過ぎるかもしれませんが）。

1.2.3 AUTOSAR RTEを使用する場合

　REのトリガ条件であるRTE Eventとして、比較的抽象度の高いものが用意されています（表2）。

表2　RTE Eventの一覧（x：Runnableの起動（ACT）要因および動作再開（WUP）要因）［クリックで拡大］

　SW-C開発者は「どのRTE Eventでトリガーされるのか」を考える必要はありますが、一般に、そのトリガーの実現方式、例えば、RTOSでの2方式（タスク起動要求vs.イベント通知）のどれを使うかを考える必要はありません。なお、条件によりジェネレータが方式を自動的に決めるのか、あるいは手作業で選択できるのか（＝それらに関する設定を、SW-C開発者からSW-Cを受け取ったECUソフトウェアのインテグレーターが行う必要があるのか）は、RTEの実装次第です。

次回に続く

　次回は「2．処理の中身（ふるまい）の実現」に進みます。