車載ネットワーク（13）LINの節電機能・エラー処理・発振子

節電機能

車載ネットワークでは「節電」は重要なテーマだ。限られたバッテリー電力と発電量の範囲内で動作しなければならない。LIN は限られた電力を有効に使うため、「ネットワーク管理」として Sleep と Wake Up 機能を規定している。必要な時だけ Wake up (目覚め)し、電力消費を削減することが狙いだ。その他のネットワーク管理機能はアプリケーションに任され、特に規定していない。

LIN 規格では、その他のネットワーク管理機能の例として、「Limp Home」管理はアプリケーションに残してあげた・・・と書かれている。面白い表現だ。

Wake up/Sleep 機能は、LIN 規格バージョンにより、タイムアウト時間などのパラメータが異なる。特に断りのない限り、LIN 2.1 規格のパラメータで説明を進める。

スレーブノードの状態遷移

スレーブノードの状態遷移は、次の3つのフェーズで構成されている。電源接続やリセットで「Initializing」に移行し、初期化を完了すると「Operational」に移行する。「Go To Sleep」コマンドを受信すると「Bus sleep mode」に移行し節電モードになる。節電モードからの復帰は「Wake Up」信号の受信だ(図1)。

Go to sleep コマンド

Go to sleep コマンド(フレーム)は、マスタタスク(マスタノード)がスレーブタスク(マスタノード/スレーブノード)に Bus Sleep Mode への移行を要求するブロードキャストコマンドだ。LIN バスは非アクティブ状態になる。しかし、スレーブノードに省電力モードを強制するのではなく、移行するか否かはスレーブタスクのアプリケーションに任されている。

マスタノードは、マスタからスレーブへの動作要求フレーム(Protected Identifier Field: 0x3C)、Data Byte1 に 0x00、2~8 Data Byte に0xFFを格納し送信する(図2)。要求フレームを検知したスレーブノードは、スリープモードに移行し通信を停止する。しかし、スレーブノードは Data Byte1 の0x00 を確認するが、Data Byte2~8 の0xFF を無視するようになっている。これは、LIN 規格の 1.x では Data Byte2~8 の 0xFF 設定が明記されていないためだ。この辺りにも、互換性を取る工夫と苦悩が見える。

Go to sleep コマンド配信完了後、LIN バス上に Wake Up 信号が送信され、スリープモードが解除されるまでLIN バスは非アクティブ状態が維持される。

Bus Sleep Mode モードへは、マスタが送信する Go to sleep コマンドで移行するのが一般的だ が、LIN バスの非アクティブ状態が 4~10秒続くと Bus Sleep Mode に移行する。いわゆる「バスアイドルタイムアウト」だ。バスタイムアウト時間やバスタイムアウトから復帰する時間は、LIN のバージョンで異なる。ここも注意が必要だ。規格バージョンによる違いは、表1 を参照いただきたい。

Wake up

スリープ中の任意のノードは、Wake up 信号を送信し、LIN バスの目覚ましを要求することができる。Wake up 信号は、0.25m秒~5m秒の間バスを強制的にドミナント状態にすることで始まり、バスがリセッシブ状態に戻る(信号立上げ↑)ことで有効になる。すべてのスレーブノードは、Wake up 信号(0.15m秒より長いドミナントの後にリセッシブに遷移)を検出後、100m秒以内に初期化を完了し、送受信の準備を完了しなければならない。送信側の信号幅は 0.25m秒~5m秒の幅があり、検出側は0.15m秒と短くなっている。これは、クロック誤差や検出遅れを考慮したマージンだ(図3)。

マスタノードは、スレーブの準備が整ったところでヘッダ送信を開始し、Wake up の要因を調べる(図4)。マスタが送信する Break field は Wake up 信号として機能するため、マスタノードは通常のヘッダを送信することがある。しかし、この場合は、スレーブノードの送受信準備が完了していないことがあるため、スレーブノードはコマンドを処理できないことがある。

ノードが Wake up 信号を送信したにも関わらず、マスタノードがフレーム送信を開始しない (Brake field を検出できない)場合、または Wake up 信号から 150m秒~250m秒以内に別のノードからの Wake up 信号を受信できない場合は、新しい Wake up 信号を送信する必要がある。この操作は連続して3回まで繰り返すことができる。これを Wake up 信号の1ブロック送信と呼ぶ(図5) 。Wake up 信号の連続送信が起きる理由として、LIN バス上の全てのノードが Wake up に反応していないことが考えられる。

これとは逆に、Wake up 信号送信を繰り返すノードが、バス信号をうまく読み取れていないことが考えられる。つまり、このノードが故障中でその他のノードは実は正常に動作しているケースだ。このようなケースに備え、3回目の Wake up 要求後、4回目の Wake up 信号を送信 する前に少なくとも 1.5 秒待つ仕組みになっている。1.5 秒の空き時間を作ることで、他のノードは障害の起きているノードに邪魔されず通信ができる(図6)。

バージョンによるパラメータの違い

パラメータ	LIN 規格名称	LIN 1.3	LIN 2.0	LIN 2.1
Bus Idle タイムアウト時間	TTIME_OUT	25,000Tbit	4秒	4秒~10秒
Wake up 信号幅	TWUSIG	TWUSIG 8Tbit	0.25m秒~5m秒	0.25m秒~5m秒
Wake up 信号デリミタ	TWUDL	4~64Tbit	100m秒	100m秒
Wake up 信号送信後タイムアウト時間	TTOBRK	最大 128Tbit	150m秒	150m秒~250m秒
Wake up 信号3回送信後タイムアウト時間	TT3BRK	最小 15,000Tbit	1.5秒	1.5秒

エラー処理

エラー	検出ノード		エラー内容
	マスタ	スレーブ
Bit-Error	〇	〇	送信ノードはバスを監視し、送信ビットと受信ビットが異なると Bit- Error になる。Bit-Error を検出すると、次バイトから送信を停止
Checksum-Error	〇	〇	受信した全データ バイトの CRC 演算(反転modulo-256)とChecksum の 加算結果が 0xFF でない場合 Checksum-Error になる
Identifier-Parity-Error	〇	〇	Protected Identifier Field の Parity0 または Parity1 が算出値と一致しない 場合、Identifier-Parity-Error になる
Slave-Not-Responding-Error	〇		マスタがヘッダ送信後、所定のタイムアウト時間内にスレーブからレスポン スを受信できない場合、Slave-Not-Responding-Errorになる
Inconsistent-Synch-Field-Error		〇	Sync byte field があらかじめ設定されたビットレート許容範囲外の場合、 Inconsistent-Synch-Field-Error になる
Physical-Bus-Error	〇		LIN バスが、電源や GND 等にショートし、有効なメッセージを送信できな い場合、Physical-Bus-Error になる

発振子

マイクロプロセッサや通信の基準クロックになる発振子には様々な方式がある。一般的には水晶振動子が使われるが、LIN 規格では水晶振動子以外にも、精度の低いセラミック振動子やRC 発振器の使用を許している。

RC発振器の発振周波数は、抵抗とコンデンサの掛け算で決まる。抵抗やコンデンサは、製造時のバラツキ、温度変化や経年変化で、±5%~±10% 程度の誤差がある。LIN 規格では、クロッ ク精度を±14% 以内と決めているが、抵抗やコンデンサの誤差を考えると、ある程度部品精度を選ぶ必要がありそうだ。

コストや周波数精度を考えると、マイクロプロセッサに埋め込まれたシリコン振動子の利用が広がりそうだ。マイクロプロセッサのシリコン上に発振回路を形成しているため、低コストで場所を取らない。発振周波数も GHz オーダまで対応でき、精度も±数%で収まる。少なくとも、スレーブノード(±14%)で使えそうだ。最近、セラミック振動子並みの精度の製品も発表されている。今後は、マスタノード(±0.5%)での使用も可能になりそうだ。

セラミック振動子の周波数精度は、±0.1 % 程度だ。水晶発振子より精度は落ちるが、小型で安価だ。一般的な水晶振動子の周波数精度は±30ppm程度で、RC発振器やセラミック振動子に比べはるかに精度が高い。もちろん車載機器に使用することはないが、温度償回路内蔵の TCXO 、発振回路全体を恒温槽に入れたOCXOなどがある。

更に高精度、高安定なセシウム、水素メーザ、ルビジウムなどの原子時計がある。国の標準時、GPSやVLBI(超長基線電波干渉計)などで使用する。