LINバスプロトコルの概要

Local Interconnect Network (LIN) バスおよびController Area Network (CAN) バスは、自動車および産業用システムで一般的に使用される通信プロトコルです。 LINとCANは同様の目的を果たしますが、アーキテクチャと機能には大きな違いがあります。 

LINは、自動車ネットワークにおける低コスト、ローエンドマルチプレクス通信用の規格を作成するために開発されました。CANは高帯域の高度エラー処理ネットワークのニーズに対応するものですが、CANの実装に必要なソフトウェアとハードウェアのコストは、パワーウィンドウや座席制御装置など高い性能が求められないデバイスには高額すぎます。LINを使用すると、CANほどの帯域幅や多用途性を必要としないアプリケーションで、コスト効率の高い通信を行うことができます。LINは、ほとんどの低コスト8ビットマイクロコントローラに組み込まれた標準のシリアル汎用非同期送受信回路（UART）を使って、比較的低コストで実装することができます。

昨今の自動車ネットワークでは、主に車体の電子部品の低コストアプリケーションにはLIN、中心となるパワートレインや車体通信にはCAN、アクティブサスペンションなどの高度なシステムにおける高速同期データ通信にはFlexRayという使い分けをしています。 

LINバスでは、LINマスタと1つまたは複数のLINスレーブからなるマスタ/スレーブ方式を採用しています。

 
^{図1:LINメッセージフレーム}

メッセージのヘッダには、フレームの始まりを示すブレークと、スレーブノードがクロック同期に使用する同期フィールドがあります。識別子（ID）は、6ビットのメッセージIDと2ビットのパリティフィールドで構成されます。IDは、特定のメッセージアドレスを示しますが、送信先は示しません。IDを受信して解釈したら、1つのスレーブがメッセージの応答を開始します。それには1～8バイトのデータと8ビットのチェックサムが含まれています。 

マスタはメッセージフレームの順序を制御します。これはスケジュールで固定されています。スケジュールは必要に応じて変更することができます。 

LIN規格にはいくつかのバージョンがあります。バージョン1.3で、バイト層通信が完成し、バージョン2.0と2.1ではさらにメッセージ仕様やサービスが追加されましたが、バイトレベルでLIN 1.3に対応しています。 

¹この機能はAPIによるネイティブサポートはありませんが、機能を組み込むことはできます。 

^{表1: LINバージョン1.3、2.0、2.1の比較}

LINバスは、1つのマスタデバイスと1つまたは複数のスレーブデバイスによるポーリングを使用するバスです。マスタデバイスには、マスタタスクとスレーブタスクの両方が含まれます。スレーブデバイスにはスレーブタスクのみが含まれます。LINバス経由での通信は、全てマスタデバイスのマスタタスクによって制御されます。LINバスでの転送の基本単位はフレームで、ヘッダと応答に分けることができます。ヘッダは常にマスタノードによって送信され、ブレーク、同期（sync）、識別子（ID）の3つのフィールドからなっています。スレーブタスクによって送信され、マスタノードとスレーブノードのいずれかに常駐する応答は、データペイロードとチェックサムで構成されています。 

通常マスタタスクは、ブレーク-同期-IDの順となっているヘッダを送信することで、各スレーブタスクをループ内でポーリングします。LINを起動する前、各スレーブタスクはバスにデータをパブリッシュするか、あるいは受信した各ヘッダIDへの応答としてデータをサブスクライブするよう設定されています。ヘッダを受信したら、各スレーブタスクはIDパリティを検証し、IDをチェックしてパブリッシュとサブスクライブのどちらが必要かを特定します。スレーブタスクが応答をパブリッシュする必要がある場合は、1～8データバイトをバスに送信し、その後チェックサムバイトを送信します。サブスクライブの必要がある場合は、バスからデータペイロードとチェックサムを読み取り、それに応じて内部動作を行います。 

標準のスレーブ-マスタ通信の場合、マスタは識別子をネットワークに送信し、スレーブのうちの1つだけがデータペイロードを含む応答を返します。

マスタ-スレーブ通信は、マスタノード内の別のスレーブタスクによって行われます。このタスクは、バスにパブリッシュされた全てのデータを自己受信し、独立したスレーブノードであるかのように応答します。データバイトを送信するには、マスタはまず内部スレーブタスクの応答を送信したいデータ値でアップデートする必要があります。次に適切なフレームヘッダをパブリッシュし、内部スレーブタスクはそのペイロードをバスに送信します。

^{図2:LINメッセージフレーム}

1.休憩

全てのLINフレームはブレークで始まります。ブレークは、13のドミナントビット（公称）と、その後の1ビット（公称）リセッシブのブレークデリミタからなります。これはバス上の全てのノードに対するフレーム開始通知の役割を果たします。

2.同期

同期フィールドは、ヘッダの中でマスタタスクによって送信される2番目のフィールドです。同期はx55という文字で定義されます。同期フィールドにより、自動ボーレート検出を行うスレーブデバイスがボーレートの周期を計測し、バスト同期するように内部ボーレートを調整することが可能となります。

3.ID

IDフィールドは、ヘッダの中でマスタタスクによって送信される最後のフィールドです。ネットワーク上の各メッセージを識別し、最終的にネットワーク上のどのノードが各送信を受信または応答するかを決定します。全てのスレーブタスクは連続的にIDフィールドをリスンし、パリティを検証して、その特定の識別子に対しパブリッシャかサブスクライバかを特定します。LINバスには全部で64個のIDがあります。ID 0～59は信号を含む（データ）フレーム、60と61は診断データに使用され、62はユーザ定義の拡張用、そして63は将来のプロトコル拡張用に予約されています。IDは保護された1つのIDバイトとしてバス上に送信されます。下位6ビットは未処理のID、上位2ビットはパリティを含んでいます。

^{表2: パリティの計算方法}

4. データバイト

データバイトフィールドは、スレーブタスクにより応答で送信されます。このフィールドには、1～8バイトのペイロードデータバイトが含まれます。 

5.チェックサム

チェックサムフィールドは、スレーブタスクにより応答で送信されます。LINバスでは、8ビットチェックサムフィールドの値を計算するため、2つのチェックサムアルゴリズムの1つの使用を定義します。従来型チェックサムの計算ではデータバイトのみを合計していましたが、拡張チェックサムではデータバイトと保護されたIDを合計します。

LIN 2.0仕様におけるチェックサム計算プロセスは、全ての値を合計し、合計が256以上になるたびに255を減算するとなっています。LIN 2.0仕様については、従来のチェックサムはLIN 1.3スレーブノード用、新方式のチェックサムはLIN 2.0スレーブノード用となっています。さらにID 60～63は常に従来のチェックサムを使うよう指定されています。NI LINインタフェースには、チェックサムのタイプを従来または新方式のいずれかに設定できる属性があります。デフォルト設定は従来型です。LIN 2.0仕様の場合、ID 60～63ではチェックサム属性の設定に関わらず常に従来型が使用されます。

図3は、マスタタスクのヘッダとスレーブタスクの応答によりLINフレームが作成されることを示しています。 

^{図3:LINフレームの作成}

LINバスはポーリングバスなので、各フレームの処理は下記のように公称タイムスロットに割り当てられています。

Tヘッダ_公称 = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
各フレームの処理には、以下のように最大タイムスロットが割り当てられます。
Tヘッダ_最大値 = 14 * Tヘッダ_公称
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum

LINバスは、1つのマスタデバイス（ノード）と1つまたは複数のスレーブデバイス（ノード）をLINクラスタとして接続します。各ノードの動作は、それぞれのノード機能ファイルに記載されています。ノード機能ファイルはシステム定義ツールに入力されるもので、システム定義ファイルはクラスタ全体の動作を記述するLIN記述ファイル（LDF）を生成します。LDFはシステム発生器によって構文解析され、希望のノードで指定した動作を自動で生成します。この時点で、マスタノードのマスタタスクはヘッダをバス上に送信し、LDFで指定したとおり、クラスタ内の全てのスレーブタスク（マスタノードのスレーブタスクも含む）が応答します。

一般用語として、LDFはLINクラスタの動作のスケジュールを構成し作成するのに使用されます。例えば、ボーレートや、ヘッダのマスタタスクの送信における順序や時間遅延、応答される各スレーブタスクの動作などを定義します。NI LINハードウェアとLIN対応のNI-CANフレームAPIでは、LDFをフルサポートしていないため、スケジューリング動作をハードウェアにダウンロードすることはできません。ただし、バスへのアクセス（ヘッダの書き込みや応答のパブリッシュ/サブスクライブ）の低レベルサポートは提供されているため、ユーザがアプリケーションレベルでスケジューリング動作を作成することは可能となっています。NI LINの応答エントリフレームタイプの説明で述べたとおり、NI LINハードウェアにはスレーブタスクの応答を保存するための応答キューがあります。応答キューには64個の応答を入れることができます。それは、LINで指定した64個のIDの各最大数につき1個です。そのため、LINインタフェースのスレーブタスクはLIN仕様で指定された応答時間内にヘッダに確実に応答することができます。

LIN対応NI-CANフレームAPIでは、LINバスとの低レベルでの通信を確実に行うための機能があります。これにより、エンドユーザはLINネットワークの解析や試作などを行う複雑なアプリケーションを開発するための基本機能を利用できるようになります。LIN対応NI-CANフレームAPIはLINの診断や構成、LDF、スケジュールテーブルをネイティブでサポートしていません。ただし、それらのタスクはLIN対応NI-CANフレームAPIを使用するアプリケーションで実装することができます。

LIN 2.0仕様では、エラー検出はスレーブタスクが行い、マスタタスクによるエラーの監視は必須ではないと記載されています。1つのLINフレーム内における複数のエラーの処理や、エラーカウンタの使用も必須ではありません。フレームで最初のエラーが発生すると、次のブレーク-同期のシーケンスが検出されるまで、スレーブタスクはフレームの処理を中断します。ログバスエラー属性がTrueに設定されている場合、バスエラーフレームは読み取りキューに記録されます。ログバスエラー属性がFalseに設定されている場合は、ncWriteNetまたはncWriteNetMultによってエラーが返されます。 

また、LINではネットワークにもエラーをレポートします。LIN 2.0仕様では、送信したフレームのいずれかでスレーブがマスタへのレポートを義務付けられているResponse_Errorステータスビットを定義しています。このビットは、スレーブノードが送受信したフレームの応答フィールドにエラーが含まれている場合に設定されます。このビットは、パブリッシュされたスレーブの応答のいずれかで送信されるとクリアされます。LIN対応NI-CANフレームAPIはResponse_Errorステータスビットをネイティブでサポートしていませんが、エンドユーザがアプリケーションレベルでこの機能を簡単に組み込むことはできます。この手順では、ログバスエラー属性を1に設定し、読み取りキューの中のバスエラーフレームのロギングを有効にします。するとアプリケーションは、応答でエラーが発生したことを示すエラーコードが含まれるバスエラーフレームの読み取りを監視できます。この状況で、アプリケーションはローカル変数にResponse_Errorステータスビットを設定することができます。するとアプリケーションはNI LIN応答エントリフレームタイプを使用して、Response_Errorステータスビットを含むデータでスレーブ応答キューを更新し、ローカル変数のビットをクリアします。

LINには、デバイスをスリープ状態にして電力を節約するメカニズムがあります。LIN 2.0仕様の場合、最初のデータバイトが0の診断的マスタ要求フレーム（ID=60）をマスタが送信することで、全てのスレーブを強制的にスリープモードにすることができます。この特殊なフレームは、go-to-sleepコマンドと呼ばれます。また、LINが4秒以上アクティブでない場合、スレーブは自動的にスリープモードになります。LIN対応NI-CANフレームAPIは極めて柔軟性が高く、ユーザはアプリケーションレベルで自由にLINインタフェースをスリープモードにすることができます。スリープ要求メッセージを含むフレームを受け取るか、4秒間バスがアクティブでないことを示すバス非アクティブフレームを受け取った場合、ユーザはLINスリープ属性をTRUEに設定してLINインタフェースをスリープモードにすることができます。

LINでは、バス経由でデバイスを目覚めさせる機能があります。ウェークアップは、バス上の任意のノード（スレーブでもマスタでも可）によって開始することができます。LIN 2.0仕様では、ウェイクアップ要求を発行するには、バスを250 µs～5 msで強制的にドミナントにします。各スレーブはウェークアップ要求を検出し、100 ms以内にヘッダ処理の準備を完了します。マスタもウェークアップ要求を検出し、スレーブノードの準備ができたらヘッダの送信を開始します（ウェークアップ要求受信後100～150 ms以内）。マスタが最初のウェークアップ要求の受信後150 ms以内にヘッダを発行しない場合、ウェークアップを要求しているスレーブは2回目のウェーブアップ要求の送信を試みることがあります。まだマスタが応答しない場合、スレーブは3回目のウェークアップ要求を発行して150 ms待つことができます。それでも応答がない場合は、あと1.5秒待ってから4回目のウェークアップ要求を発行します。LIN対応NI-CANフレームAPIを使用すると、LINインタフェースがマスタとスレーブのどちらとして動作しているかに関わらず、ウェークアップはLIN 2.0仕様に従って実行されます。

LIN 2.0仕様では、LINフレームをさらに6つのタイプに分類しています。

1. 無条件
2. イベントトリガ
3. 散発
4. 診断
5. ユーザ定義
6. 予約済み

これらのフレームタイプの違いは、送信されるタイミングまたはデータバイトの内容のいずれかによるものです。フレームの分類に関わらず、完全なLINフレームは常にマスタタスクによって送信されるヘッダとスレーブタスクによって送信される応答によって構成されます。LIN対応NI-CANフレームAPIは、それらのLIN特定のフレームタイプを処理するニーズにも対応できます。最もよく使用されるのは無条件フレームタイプです。無条件フレームは信号（データ）を含み、識別子は0～59の範囲になります。

イベントトリガフレームタイプは、1フレームスロット時間内に複数のスレーブから無条件フレーム応答を要求することで、バス帯域幅の節約を試みます。

イベントトリガフレームには、0から59までの範囲のIDが含まれる可能性があります。マスタが無条件フレームについてクエリしている場合、イベントトリガヘッダIDに応答することのできるスレーブは、最初のデータバイトを応答先の保護されたIDとともにロードします。イベントトリガフレームは、以下のように動作します。マスタがヘッダにイベントトリガIDを書き込みます。データがアップデートされている場合、スレーブはイベントトリガIDにのみ応答することがあります。

1つのスレーブだけが応答をパブリッシュした場合、マスタはそれを受信し、最初のデータバイトを見ることで（保護されたIDから）どのスレーブから受信したかがわかります。複数のスレーブが応答をパブリッシュした場合は、衝突が発生し、マスタデバイスのスレーブタスクがバスエラーとして報告します。次にマスタデバイスは、無条件フレームを使って各スレーブから応答をクエリします。 

散発フレームは、何らかの動的動作をLINに対し実行します。常に信号（データ）を含んでおり、IDは0から59までの範囲となります。散発フレームのヘッダは、フレーム内のデータ値（信号）がアップデートされたことをマスタタスクが知った時点でのみ、フレームスロットに送信されます。このような要件のため、散発フレームの応答はマスタデバイスのスレーブタスクが通常パブリッシュすることになります。

診断フレームは、長さが常に8データバイトで、診断または構成データが含まれています。IDは、マスタ要求フレームの60、スレーブ応答フレームの61のいずれかです。62のIDを持つユーザ定義フレームには、どのようなタイプの情報でも含めることができます。予約済みフレームのIDは63で、LIN 2.0クラスタで使用することはできません。

NI-XNET LIN

NI-XNET製品ラインは、高速CAN、LIN、FlexRayインタフェース、最適化されたドライバ、使いやすいAPI、構成およびデバッグユーティリティを組み合わせたものです。NI-XNETインタフェースを使用すると、CAN、LIN、FlexRayネットワークのプロトタイピング、シミュレーション、テストを行うアプリケーションをより短期間でより容易に、C/C++の他にNI LabVIEWおよびLabVIEW Real-Timeでも開発できます。

NI-XNET PCI/PXIおよびCシリーズLINインタフェースには、統合LDFサポート、マスタタスクのハードウェアタイミングスケジューリング、およびフレームと信号の通信も装備されています。 

^{図4:CAN、LIN、およびFlexRay用NI-XNETプラットフォーム}

NI USB LIN

^{図5:NI USB-8506 LIN インタフェース}

USB LINインタフェースデバイスを使用してLINデバイスと通信することもできます。これは、LINネットワークと通信するための低コストのモバイルソリューションです。