AUTOSAR CP入門（その1）RTOSがAUTOSAR理解の壁になっている？：AUTOSARを使いこなす（24）（3/5 ページ）
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第24回からは、AUTOSAR CP（Classic Platform）の導入拡大の大きな障壁になっているであろう、スケジューラ方式による開発からRTOSを用いた開発への移行で求められる知識をまとめた「AUTOSAR CP入門」をお送りする。
1．処理の起動
1.1 トリガーの受け取りと、トリガーに対応した処理の起動
1.1.1 スケジューラ方式の場合
何らかの処理を行うきっかけ（トリガー）としては、マイコンのコア内部で生じた異常や処理要求などの通知（デバイスにより呼称は変わりますが、例えば例外、内部割り込み、ソフトウェア割り込みなど）や、マイコン内に含まれる周辺回路からのコアへの通知（例えば、外部割り込み、A/D変換完了割込み、受信完了割り込み、HW Timer割り込み、ハード故障割り込みなど）があります。また、電源投入後のリセット（power-on rese：POR）の解除などの初期化タイミングもありますね。
これらを「動作ライフサイクル」「発生タイミングが予測可能か否か」という観点で整理してみると、以下のように分類することができます。
- a）初期化イベント
- b）初期化完了後のイベント
- b1）初期化完了後の、あらかじめ設定された時刻で発生する時間イベント（周期的な繰り返し、または、単発）
- b2）初期化完了後の、マイコン内外で不定期に生じるイベント
従来のスケジューラ方式のソフトウェアアーキテクチャは、これらのイベントを図1のような構造で受け付け、処理の起動につなげていました。
図1の構造では、外部入力割り込みやA/D変換完了割り込みを使用する代わりに、周期処理（図中のPeriodic Functions）内で、外部からの入力（GPIOやA/D値、あるいは割り込み要求（IRQ）フラグなど）を定期的に参照（ポーリング：polling）することで、イベント発生有無を知ることができます。そして、イベントが発生したら、それに対応する処理を実行します。
図2の構造では、外部入力割り込みやA/D変換完了割り込みを使用する構造です。ただし、それらの割り込みを受け付けても、処理要求フラグ（図2のEV Flag）をセットするだけで、次の周期処理実行タイミング（「メイン周期」などと呼ばれることもあります）を迎えるまで対応した処理の本体を実行しません（実質、図1でのポーリング処理とあまり変わりません）。割り込み処理（図2のINT）内では、CANメッセージなどの受信データの格納などを行うだけにとどめ、その中身に応じた処理は、周期処理（図2のPeriodic Functions：「メイン処理」「（最）低優先処理」などと呼ばれることもあります）の内部で実行するのが一般的です。
図3の構造では、イベントが発生した際に、次の周期処理実行タイミングを待たずに済むようにしたものです。何を優先するかで構造が異なる場合もありますが、図3の構造の場合には、「周期処理の実行タイミングの周期ブレ（jitter）をできるだけ抑える」ということを、「イベントに対する処理の開始遅延を減らす」ということよりも優先したものとなります（Simulinkでよくみられるデジタル信号処理理論に基づく定周期制御モデルを実現する場合や、モーター制御用のPWM出力更新などの場面での利用が典型例となるでしょう）。
さて、これらの「やりたいこと」が同じだった場合、RTOSやAUTOSARを採用したアーキテクチャではどうなるのでしょうか。
Copyright © ITmedia, Inc. All Rights Reserved.