連載
» 2008年07月09日 00時00分 UPDATE

車載ネットワーク“CANの仕組み”教えます(2):CAN通信におけるデータ送信の仕組みとは? (1/3)

CANを理解するうえで欠かせないフレーム。今回はデータフレームとリモートフレームの構造や使われ方、通信調停を解説する

[増田浩史(ベクター・ジャパン),@IT MONOist]

 今回のテーマは、CAN(Controller Area Network)のデータ送信の仕組みだ。CAN通信を理解するうえで欠かせない“フレーム”と呼ばれる通信の単位について見ていこう。

 CANには、「データフレーム」「リモートフレーム」「エラーフレーム」「オーバーロードフレーム」と呼ばれる4種類の異なる情報を表すフレームが定義されている。

 今回はこれらのフレームのうち、

  • データフレーム
  • リモートフレーム

について、その構造と使われ方、これらに関連する通信調停について解説していく。


※注:CANの前提知識については、前回「CANプロトコルを理解するための基礎知識」を参照のこと。


データフレーム

 CAN通信において、データを送信する際の転送フォーマットをデータフレームという。そして、このデータフレームの形式には“標準フォーマット”と“拡張フォーマット”の細部で異なる2種類のフォーマットが存在する。

 まずは、基本となる標準フォーマットから解説しよう。

標準フォーマット

 図1に標準フォーマットのデータフレーム構造を示す。

データフレーム(標準フォーマット) 図1 データフレーム(標準フォーマット)
※ベクター・ジャパンの資料を基に作成

 図1に描かれている上の線は“リセッシブ”を、下の線は“ドミナント”をそれぞれ表しており、ドミナントにしか線がない部分はドミナント固定、リセッシブにしか線がない部分はリセッシブ固定となっている。ちなみに、両方に線があるものは送信されるデータによってドミナントかリセッシブか変化するものだ。

 各部の数値は、何ビット分使用するかの長さ(ビット長)を表している。また、CANでは通信が行われていない場合、バスはリセッシブとなっており、これを“バスアイドル”と呼んでいる。

 ノードからデータフレームが送信されるとき、最初に送信される部分は“開始”を表すためにドミナント状態とする。この部分を「SOF(Start Of Frame)」と呼ぶ。SOFがバスアイドルのリセッシブからドミナントへ変化することにより、受信側ノードは同期を行うことができる。

 SOFに続き送信されるのは、「ID(識別子:Identifier)」だ。このIDはデータ内容や送信ノードを識別するために使用されるが、別の働きとして通信調停の優先順位を決定している。標準フォーマットでは11ビット長でIDを構成しているが、後述する拡張フォーマットでは、このID(ベースID)と拡張IDの18ビット長でIDを構成している。11ビット長の場合、IDの範囲は0x0〜0x7FFとなり、2048種類の識別が可能だ。

 IDの後は「RTR」だ。これは“Remote Transmission Request”の略で、データフレームとリモートフレームを識別するために使用される。データフレームの場合には、RTRはドミナントとなっている。なお、RTRもIDと同様に通信調停に使用される。

 RTRに続くのは「コントロールフィールド」で、このコントロールフィールドは各1ビット長の予約ビットr1、r0と4ビット長の「DLC(Data Length Code)」から構成される。標準フォーマットの場合、予約ビットr1、r0はともにドミナント固定になっている。

 DLCは、コントロールフィールドに続く「データフィールド」において、何バイトのデータが送信されるかを表している。DLCの設定範囲は0〜8となっており、データフィールドでは1バイト単位で0〜8バイト(0〜64ビット)のデータを送信できる。データフィールドは、送信されるデータの部分で、前述のようにDLCによって設定されたデータ長となる。また、データフィールド内では全バイトは最上位ビット(MSB)より送信される。データフィールドは1バイトごとに長さを設定できるが、どのような形式でデータを割り当てるかについては設計者が決定できるようになっている。例えば、1バイトのデータを割り当てる場合では、そのまま1バイトとして使用、4ビット分をそれぞれ1ビットずつ使用、残り4ビットをまとめて使用、8ビットをそれぞれ1ビットずつ使用などが可能である。

 データフィールドの後は、「CRC(Cyclic Redundancy Check)シーケンス」が送信される。CRCシーケンスは15ビット長であり、送信ノードがSOF、ID、コントロールフィールド、データフィールドの送信値より演算して、CRCシーケンスで演算結果を送信する。そして、受信ノードが送信ノードと同様にSOF、ID、コントロールフィールド、データフィールドの受信値から演算して、その結果を比較することで正常に受信できたかどうかの判断を行う。

 CRCシーケンスの後には「CRCデリミタ」が送信される。これはCRCシーケンスの終了を表す区切り記号で、1ビット長のリセッシブ固定となっている。なお、CRCシーケンスとCRCデリミタを併せて「CRCフィールド」と呼ぶ。

 続いて、「ACK(Acknowledgement)スロット」が送信される。このACKスロットは1ビット長で送信ノードはこの部分でリセッシブの送信を行う。ただし、受信ノードがCRCフィールド部分まで正常に受信できた場合は、ACKスロットのタイミングでドミナントを確認応答として送信することになっている。CANではドミナントとリセッシブが同時に送信された場合はドミナントが優先され、ドミナントとなる。このことより、正常に通信を行っているCANネットワークにおいてACKスロットはドミナントとなっている。しかし、このACKスロットは1ビット長しかもたないために、CANネットワーク上の受信ノードがすべて正常に受信を行えたかの判断には使用できない。あくまでも、送信ノードから送信されたデータフレーム(CRCフィールドまでの部分)を正常に受信できたノードが存在することしか分からない。

 ACKスロット後には「ACKデリミタ」が送信される。これはACKスロットの終了を表す区切り記号で、1ビット長のリセッシブ固定となっている。CRCフィールドと同様に、ACKスロットとACKデリミタを併せて「ACKフィールド」という。

 データフレームの終わりには「EOF(End Of Frame)」が送信される。EOFは7ビット長のリセッシブ固定となっている。前回「CANプロトコルを理解するための基礎知識」で解説を行った“ビットスタッフィングルール”は、SOF〜CRCシーケンスの終わりまでの範囲で適用することとなっているため、バスアイドル中やEOFは適用外となる。

 データフレームの範囲はSOF〜EOFまでだが、図1ではEOF終了後に「ITM(Intermission)」という表記がある。このITMはデータフレームには含まれない。ITMは3ビット長のリセッシブ固定となっており、このITM終了後にバスアイドル状態となる。CANが採用する“CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)”では、バスアイドル状態でないと各ノードは送信することができないが、次回以降解説を行う「オーバーロードフレーム」では、ITMにおいて唯一送信可能となっている。

拡張フォーマット

 次に、データフレームのもう1つのフォーマットである“拡張フォーマット”の構造について解説する。

 図2に拡張フォーマットのデータフレーム構造を示す。標準フォーマットと比較するとIDからRTRの間に異なる部分が見つけられるはずだ。ここでは、その差異部分を中心に見ていこう。

データフレーム(拡張フォーマット) 図2 データフレーム(拡張フォーマット)
※ベクター・ジャパンの資料を基に作成

 標準フォーマットにおけるIDは拡張フォーマットで「ベースID」と呼ばれ、11ビット長であり、この部分は標準フォーマットと同一である。

 ベースIDに続くのは「SRR(Substitute Remote Request Bit)」で、1ビット長のリセッシブ固定となっている。

 SRRの後には「IDE(Identifier Extension Bit)」が送信され、これも1ビット長のリセッシブ固定である。

 IDEに続き送信されるのは拡張IDで18ビット長である。ベースIDと拡張IDを併せて29ビット長となり、これによりIDを表す。拡張フォーマットの29ビット長IDの範囲は0x0〜0x1FFFFFFFとなり、536870912種類(約5億4000万種)を使用することが可能となる。主にSAE J1939で使用されている(注)。

※注:SAE J1939はトラック・バスの制御とネットワーク通信のために開発されたプロトコルで、現在ではトラック・バスに限らず、建設機械や農業機械などのディーゼルエンジン搭載車両や、船舶用電子機器など幅広く利用されている。


       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.