AUTOSAR CP入門（その2）インタフェースの切り方次第で再利用性も変わる？：AUTOSARを使いこなす（25）（1/5 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第25回は、「AUTOSAR CP入門」のその2として「処理の中身（ふるまい）の実現」をについて取り上げる

[櫻井剛，MONOist]

前回のおさらい

　前回から、「スケジューラは分かるが、リアルタイムOS（RTOS）はいまひとつ」という皆さんに向けてのAUTOSAR CP（Classic Platform）入門を、おおよそ以下の構成でスタートしています。

1. 処理の起動
2. 処理の中身（ふるまい）の実現
3. SW-Cとその他の要素（RTE、BSW、HW）とのインテグレーション
4. 従来と同じことしかできないの？（いいえ、違います！）

⇒連載「AUTOSARを使いこなす」バックナンバー

　この新たなAUTOSAR CP入門の第1弾となる前回は、以下のような内容を取り上げました。

• 1．処理の起動
  • 1.1 トリガーの受け取りと、トリガーに対応した処理の起動
    • 1.1.1 スケジューラ方式の場合
    • 1.1.2 RTOSを使用する場合
    • 1.1.3 AUTOSAR RTEを使用する場合
  • 1.2 トリガーの生成
    • 1.2.1 スケジューラ方式の場合
    • 1.2.2 RTOSを使用する場合
    • 1.2.3 AUTOSAR RTEを使用する場合

　要約するとこんなところでしょうか。

• アプリケーション、つまり、AUTOSARのソフトウェアアーキテクチャ（図1）でのApplication Layerに含まれる各種ソフトウェアコンポーネント（SW-C）を開発するだけであれば、RTOSに関する詳細知識は必ずしも必須ではない^※1）
• ソフトウェア開発対象であり、また再利用の対象である処理本体（正確には、処理実行の最小単位）は、SW-CのRunnable Entity（RE）として実装され、処理を行うきっかけ（トリガー）により起動される
  • 処理本体REは、RTE（Runtime Environment）の一部として自動コード生成されるTaskBodyや、ISR Bodyから呼び出される（各Bodyは手書きする必要のない部分、また、特に理由がなければISRではなくTaskを使用する）
  • Taskは、おおよそ、「マイコンのハードが持つ割り込み優先度のさらに下位側に、RTOSによって付け加えられた、割り込み処理群を模倣したようなもの」であり、ISR（割込み処理）と同様に、優先度に基づくイベントドリブンな処理実行を実現できる
  • REのトリガーは、時間イベントや受信など幾つかのものに標準化されており（表1）、それらは、RTE（RTE内のTask BodyやISR Bodyおよびその下にあるRTOSと各種BSW（Basic Software））、そして、それらで抽象化されるハードウェアの部分により実現（トリガー生成）される

図1　AUTOSAR CPのソフトウェアアーキテクチャ［クリックで拡大］

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

　今回は、「2．処理の中身（ふるまい）の実現」からです。

※1）インテグレーションを行うインテグレーターには、RTOSに関する詳細知識が求められます。