組み込みシステム設計者のためのLIN2.0マイコン実装術（中編）　――使用するCPU性能に応じたオプション選び

2．プロトコル詳細――スケジュール，エラー処理

　LINプロトコルの主要な特性はスケジュール・テーブルを使用することです．これにより，クラスタは時間軸で保証された動作を行えます．ただし，仕様書ではスケジュールを乱す要因が二つ規定されています．一つはイベント・トリガ・フレーム，もう一つはスポラディック・フレームです．

● スロットのスケジューリングはクラスタ仕様で決まる

　イベント・トリガ・フレームにより複数のスレーブが応答してバス上で衝突が発生してしまった場合，マスタは無条件フレームで個々のスレーブに対して問い合わせを行って，これを解決しなければなりません．ということは，バス衝突に伴ってスレーブ・ノードの数だけ臨時にスロットが必要になるわけです．だからといって，それだけの空きスロットをあらかじめスケジュールしておいたのでは，少なくとも時間的メリットはなくなってしまうように思われます^注6．

　一方，スケジュールを変更してフレームを挿入すれば，クラスタの時間保証が壊れてしまいます．これはスポラディック・フレームも同じで，散発的な信号の変更などが起こるたびにスロットを挿入すれば，それだけ後のスケジュールに遅れが出てしまいます．

　このことについてプロトコル仕様書の"SCHEDULES "では，「スポラディック・フレームやイベント・トリガに関連づけされる無条件フレームはスケジュール・テーブルに割り当てられない場合がある」と記述しています．

　つまり，ここはクラスタの仕様に依存することになります．スポラディック・フレームの使用条件の成立や，イベント・トリガによる衝突によって起こるスケジュールの変更（の頻度）が，クラスタの時間的仕様のマージン内かどうかで判断します．時間的にそれほど厳しくないクラスタであれば，臨時のフレームに対してスケジュール変更するとか，スロットを挿入するといった方法が簡単かもしれません．一方，時間周期を厳密にしたい場合，あらかじめ空きスロットをスケジュールしておくべきでしょう．

　イベント・トリガで衝突が発生した場合，スポラディック・フレーム・スロットで順番にスレーブにアクセスしていくというのも一つの方法です．図7の例では，最初のスロットで衝突が発生し，2番目と3番目のスロットで各スレーブに個別にアクセスする場合を示しました．この2番目と3番目のスロットのような個別アクセス用に，スポラディック・フレーム・スロットを利用することができます．この場合，イベント・トリガによる衝突時のフォローのためだけに空きスロットをスケジュールする必要がなくなり，スロット・スケジュールをより効率的に運用することができます．

 注6；例えば，四つのスレーブ・ノードがクラスタに接続されているとする．イベント・トリガ・フレームで問い合わせを行う場合，衝突を検出すると無条件フレームを4回出す必要がある．だからといって，イベント・トリガの後にスケジュール・テーブルに四つの空きフレーム・スロットを作ったのでは，衝突が起こらなかった場合にその時間は何もできないため，むだになる．