近年の自動車、産業機械、医療機器、家電製品に至るまで、さまざまな分野でCAN（Controller Area Network）が採用されています。このブログ記事では、CANの規格や動作の仕組みについて徹底解説します。初心者にもわかりやすく解説していますので、ぜひ最後までご覧ください。
CANの概要
基本的なこと
CAN（Controller Area Network）は、1980年代にBosch社が開発した通信方法です。特に自動車や産業機器で使われ、エンジンやブレーキなどの電子制御ユニット（ECU）が情報をやり取りするために利用されます。この仕組みでは、複数の機器（デバイス）で通信でき、それぞれがデータを送受信できる特徴があります。
世界で使われるCAN
CANは当初自動車業界向けでしたが、その後標準化が進められ国際規格ISO11898、ISO11519に登録されました。現在では自動車業界だけでなく、工場の機械（FA機器）や医療機器、さらには航空機や宇宙開発分野でも活用されています。
今後の展望
とはいえ、近年はEthernet TSNが台頭しており、高速用途はEthernet TSN、低速用途はLINという新しい規格に押さえられているため、今後の動向には注意が必要かもしれません。
CANの通信速度は1Mbpsほどですが、安全を考慮して500kbpsに抑えられていることが多いです。発展させた規格もありますが、他の新しい規格とのメリット・デメリットをよく見ておく必要があるでしょう
CAN通信利用のメリット
配線がシンプル
CANはわずか2本の通信線のみで実現できます。この配線の少なさはコスト削減やケーブルの軽量化につながり、大きなメリットです。特に近年は自動車も大量のECUが搭載され、ケーブルの数も膨大になるので影響も大きいです。
複雑なやりとりが可能
わずか2本の通信線なので配線はシンプルになりますが、膨大なデバイスが存在するようなケースではデバイス間の協調が問題になりがちです。2本の通信線は差動信号として扱われるため、送信と受信が同時にできないというデメリットもあります。
しかしCANにおいてはデバイス間の通信の競合や、送信と受信を分けるためのルール（プロトコル）に工夫がされており、複雑な通信が可能となっています。具体的な内容については後述します。
前提知識
ドミナントとリセッシブ
通信線が差動信号であることは先に述べたとおりです。2本の通信線の電圧の差分を取り、その差が大きければ"0"、小さければ"1"として扱います。この"0"のときを「ドミナント（優性）」、"1"のときを「リセッシブ（劣性）」といいます。
誰かがドミナントにしているとき、リセッシブは無視されるため「優性」「劣性」になっているのです。
「リセッシブ」は「レセシブ」と言われることもあります
接続方式（トポロジー）
CANの通信線はバス接続です。つまり、複数のデバイスが通信線を共有します。通信線は通常「リセッシブ」状態になっており、バス上のいずれかのデバイスが信号線を駆動して「ドミナント」状態にすることで通信が開始されます。バス上のデバイスのことを「ノード」と言います。
この通信開始は早いもの勝ちとなっており、誰かが「ドミナント」状態にしたことを検出したら、他のデバイスは受信に専念するわけです。（厳密には少し違いますが、誰が通信するかを決定する仕組みはややこしいため、本記事では割愛します）
CANはバス接続で、通信開始は早いもの勝ち！
NRZ（Non Return to Zero）
CANでは通信線がドミナントであれば"0"、リセッシブであれば"1"と単純に解釈します。逆に"0"を送りたければ通信線をドミナントにし、"1"を送りたければリセッシブにします。通信期間中はゼロ電圧に復帰しません。
このような符号形式をNRZ（Non Return to Zero）と呼びます。これを「符号形式」と言うと違和感があるかもしれませんが、最も単純な符号形式として位置づけられています。
同期の取り方
CANは非同期（調歩同期）シリアル通信の一種です。通常のUARTであればスタートビットによってデバイス間の同期を取っていますが、CANではリセッシブからドミナントへの変化を見て同期を取っています。
「非同期」は同期を取らないという意味ではなく、クロックなど同期信号が信号線に含まれない、という意味と考えてください
ビットスタッフィング
BRZという符号形式の都合上、"0"が連続する場合はずっと信号もドミナント状態を維持します（"1"が連続する場合もリセッシブが維持されます）。このままだといつまでたっても同期を取るタイミングが訪れず、積み上げ誤差によって通信が異常になることがあります。
これを避けるために設けられているのが「ビットスタッフィング」です。
CANでは、5回連続でドミナント、あるいはリセッシブ状態になっている場合に、現在の状態と逆の状態を1ビットだけ挟むことになっています。この挟むビットのことを「スタッフビット」といい、スタッフビットを挟む動作のことを「ビットスタッフィング」といいます。これにより、少なくとも10ビットあればどこかで同期が取れることになります。
この「5回連続」にはスタッフビットも含まれます。
CAN通信の仕組み
フレーム構成
UARTではスタートビット、データビット、パリティビット、ストップビットの構成を「フレーム」と呼んでいますが、CAN通信ではビット列の役割によって「フレーム」の種類が分かれています。CAN通信のフレームには次の種類があります。
- データフレーム：送りたいデータの本体が含まれているフレームです。
- リモートフレーム：送って欲しいデータを、任意のノードに要求するためのフレームです。（近年は使用頻度が低い）
- オーバーロードフレーム：直近のフレームの送信終了後、時間を稼ぐために使われるフレームです。（近年は使用頻度が低い）
- エラーフレーム：通信エラーの発生を知らせるためのフレームです。
いずれのフレームも送られていないとき、通信線はリセッシブ状態になります。（バスアイドル状態といいます）
フレームに含まれる「ID」は識別子のことですが、ノードを指すとは限らないことに注意してください
データフレーム
バス上に存在するノード数の増加に伴い、IDのとれる範囲を増やした「拡張フォーマット」と、それ以前から存在する「標準フォーマット」の二種類があります。図で説明しますが、デジタル信号のレベルのイメージなっており、Hi側がリセッシブ、Lo側がドミナントのイメージで解釈してください。
標準フォーマット
標準フォーマットのビット構成は次のようになっています。
- SOF（Start Of Frame）：1ビットサイズで必ずドミナントです。フレームの開始を示します。またこれにより同期が取られます。UARTでいうスタートビットにあたります。
- ID：データの内容や送信ノードを識別するための数値です。11ビットで示されます。
- RTR（Remote Transmission Request）：1ビットサイズで、リモートフレームと区別するために使います。データフレームではドミナントです。
- コントロールフィールド：6ビットサイズです。上位2ビットは予約でドミナント固定です。下位4ビットでデータのバイト数を示します。下位4ビットをDLC（Data Length Code）といいます。
- データフィールド：実際のデータ内容です。0～8バイト（0～64ビット）サイズです。
- CRC（Cyclic Redundancy Check）：CRCそのものの15ビットと、デリミタ（終端のこと）の1ビットで構成されます。デリミタは必ずリセッシブです。
- ACK（Acknowledgement）：ACKを示す1ビットと、デリミタの1ビットで構成されます。ACKのビットは受信側がドミナントに駆動します。
- EOF（End Of Frame）：7ビットサイズで、全てリセッシブです。フレームの終了を示します。UARTのストップビットが長くなった感じです。
EOFに続いてリセッシブを3ビット送受信します（ITM：Intermission）。その後バスアイドル状態に戻ります。
拡張フォーマット
標準フォーマットとの違いだけを次に示します。
- ID→Base ID：呼び名が変わります。サイズは標準フォーマットと同じ11ビットです。
- SRR（Substitute Remote Request Bit）：1ビットサイズで必ずリセッシブです。BASE IDの直後に配置されます。
- IDE（Identifier Extention Bit）：1ビットサイズで必ずリセッシブです。SRRの直後に配置されます。
- Extension ID：IDEの直後の18ビットを使い、拡張IDを示します。
この後にRTRが入り、以降は標準フォーマットと同じです。IDは全体で29ビットサイズになります。
リモートフレーム（使用頻度低）
データフレームから、データフィールドを除いたフォーマットになっています。データフレームとの違いはRTRで、こちらのRTRはリセッシブです。（これで標準フォーマットと区別しています）
データフィールドはありませんが、DLCは要求するデータのDLCを設定します。拡張フォーマットは存在しません。
リモートフレームの使用頻度が低いのは、近年はポーリング方式という「送信が成功するまで一定間隔でデータを送り続ける」という方式が用いられることが多く、バスの使用効率を考慮するとリモートフレームのメリットが無いためです。
オーバーロードフレーム（使用頻度低）
データの受信側が、処理が終わるまでの時間稼ぎをするためのフレームです。
図中でオーバーロードフラグが6～7ビットとありますが、信号線上には7ビットのドミナントが見られることがあるためです
データフレーム送信後のITMの期間中に、6ビットサイズのドミナント（オーバーロードフラグ）を送信します。その後に8ビットサイズのリセッシブ（オーバーロードデリミタ）を送信し、続いてITM（3ビット）を送信して時間を稼ぎます。それでも時間が足りないときはこのITMの期間中にまたオーバーロードフレームを送り・・・というように重ねて遅らせることもできます。
オーバーロードデリミタが8ビットなのは、データフレームやリモートフレームの末尾であるACKデリミタとEOFの合計サイズと一致させるためです。
昔はCPU性能が低く、ITMの期間が終わってバスアイドルになると受信側の処理が終わらないうちに次の通信が始ってしまうことがあったため、受信側がオーバーロードフレームを送ることでみんなを待たせていたわけです。
そのため最近はあまり使われなくなっています。
エラーフレーム
データフレーム、あるいはリモートフレームを送受信しているノードがエラーを検出したとき、それを知らせるために送信するフレームです。
エラーを検出したノードは、信号線を6ビット期間、強制的にドミナントにします。これによりスタッフビットが検出できないというエラーを発生させます。その後、8ビット期間、リセッシブにします。この8ビット期間というのは、データフレームやリモートフレームの末尾であるACKデリミタとEOFの合計サイズと一致するようになっています。
エラーフレームの直後にもITMの期間があります。（データフレームの項目を参照）
スタッフビットが検出できないエラーをわざと発生させている都合上、エラーを検出したノード以外のノードもエラーフレームを出すため、信号線上のドミナントは最大12ビット期間現れます。
エラーフレームがいつ送信されたかによってエラー種別を判別できます。エラー種別は次のとおりです。
- ビットエラー：送信したビットと信号線の状態を監視した結果が異なっていたときに、送信側が発するエラーです。
- ACKエラー：ACKのタイミングで、どのノードもドミナントにしなかったときに、送信側が発するエラーです。
- CRCエラー：データフレームのCRCと、受信したデータから算出したCRCが異なっていたときに、受信側が発するエラーです。
- スタッフィングエラー：正しくビットスタッフィングされていなかったときに、受信側が発するエラーです。
- フォーマットエラー：必ずリセッシブになっていないといけないビットがドミナントだったとき、受信側が発するエラーです。
CRCエラーだけは、エラー検出時にすぐエラーフレームを出すとフォーマットエラーと区別できないため、EOFの直前にエラーフレームを発します。
エラーカウントによる「退場」
エラーが発生する要因によっては、何度リトライしてもエラーになり続けることがあります。こうなると、エラーが発生する度にエラーフレームでバスが占拠されてしまい、以降の通信に支障をきたします。
それを防ぐために、送信側や受信側をバスから締め出す仕組みがあります。それがエラーカウントです。
詳しい解説は割愛しますが、各ノードには送信エラーカウンタと受信エラーカウンタがあり、カウンタがある値を超えると前者の場合は以降の送信が、後者の場合は以降の受信が禁止されます。いわば「退場処分」です。
カウンタは必ず1つずつ加算されるわけではなく、重大なエラーの場合は8が加算されることもあります。
また、退場とされる前の段階でも「やばい」という状態はわかるため、その状態はノードで保持されるようになっています。機器の点検時には「やばい」状態でも原因を探す必要が出てきます。
おわりに
CAN通信について、重要なところを解説しました。本来のバス調停（通信権争い）はかなりややこしいため省きましたが、ポイントは押さえたつもりです。
一度で全て理解するのは難しいでしょうし、実際に信号線を観察したり、プロトコルアナライザで見てみる等の補強が必要だとは思いますが、本記事がCAN通信の理解への一助となれば幸いです。
