
同じ2本の通信線に、複数の制御機器が同時につながる。
それでも重要な信号が優先され、異常なノードは自ら通信から離脱します。
この仕組みを理解せずに配線やID設計を行うと、ノイズ、通信停止、誤動作の原因を切り分けにくくなります。
CAN通信とは、車載機器や産業機器で使われる、高信頼な分散制御向けの通信方式です。
本記事では、CANバス、終端抵抗、ID、エラー検出、CANopenとの違いまで実務目線で解説します。
- 1. CAN通信とは:分散制御に強いシリアル通信
- 2. CANバスの基本構造:2本線差動とマルチマスター
- 3. CANのIDとフレーム:優先順位を決める中心要素
- 4. 終端抵抗と配線:CAN通信で最初に確認する場所
- 5. エラー検出の仕組み:CANが制御用途に強い理由
- 6. CANopenとは:CANの上で動く上位プロトコル
- 7. CAN通信とCANopenの違い:どちらを選ぶべきか
- 8. 実務での設計ポイント:ID・周期・負荷を見積もる
- 9. CAN通信トラブルの切り分け:配線から順に確認する
- まとめ
1. CAN通信とは:分散制御に強いシリアル通信
CANはController Area Networkの略です。
複数の制御装置が同じ通信線を共有し、短い制御データを高速にやり取りするための通信方式です。
車載ネットワークで有名ですが、産業機械、搬送装置、医療機器、ロボット周辺機器でも使われます。
通信方式としてはシリアル通信の一種ですが、単純な一対一通信とは考え方が大きく異なります。
CANでは、送信者と受信者を固定せず、同じバス上の全ノードがメッセージを監視します。
必要なノードだけが、自分に関係するIDのデータを取り込みます。
一言でいうと何をする通信か
CAN通信とは、制御機器どうしが短い状態情報や指令値を共有するための通信です。
たとえば、モータドライバ、センサユニット、操作パネル、制御基板を同じ通信線につなげます。
各機器は、速度指令、位置情報、異常状態、スイッチ状態などをメッセージとして送受信します。
点対点で個別に配線するよりも、配線本数を減らしながら複数機器を連携できます。
車載だけでなく産業機器にも使われる理由
CAN通信が広く使われる理由は、ノイズ環境に比較的強く、異常検出の仕組みを持つためです。
モータ、インバータ、リレー、ソレノイドが動く現場では、通信線にノイズが乗りやすくなります。
CANは差動信号、エラー検出、再送制御、優先順位制御を組み合わせて、制御用途に必要な堅牢性を確保します。
マイコン同士を接続する場合にも、単純なUARTより信頼性を高めやすい方式です。
2. CANバスの基本構造:2本線差動とマルチマスター
CAN通信の配線は、基本的にCAN_HとCAN_Lの2本で構成されます。
この2本の電位差を使って信号を表すため、外部ノイズの影響を打ち消しやすくなります。
同じ2本線に複数のノードを並列接続する構成を、CANバスと呼びます。
RS-485と同じように差動信号を使いますが、通信制御の考え方は異なります。
CAN_HとCAN_L:差動信号でノイズに強くする
差動信号では、1本の線の電圧だけで0と1を判断しません。
CAN_HとCAN_Lの差を見て、バス状態を判断します。
外部ノイズが2本の線に同じように乗った場合、差分としては小さくなります。
そのため、単線の信号よりもノイズの多い環境で安定しやすくなります。
ただし、差動だから絶対にノイズで壊れないわけではありません。
ケーブルの引き回し、シールド、グランド、終端抵抗の扱いが悪いと、通信エラーは普通に発生します。
マルチマスター:どのノードからでも送信できる
CANでは、特定の親局だけが通信を支配するとは限りません。
各ノードは、バスが空いていれば自分のタイミングで送信できます。
このように、複数のノードが送信権を持つ構成をマルチマスターと呼びます。
マルチマスター方式では、複数ノードが同時に送信を始める可能性があります。
CANでは、IDの優先順位を使って衝突を壊さずに調停します。
ブロードキャスト:宛先ではなくIDで意味を判断する
CANメッセージは、基本的にバス上の全ノードへ流れます。
各ノードは、そのメッセージIDを見て、自分が処理すべきデータかどうかを判断します。
これは、送信先アドレスを指定する通信とは発想が異なります。
たとえば、「モータ速度現在値」というIDを流せば、表示器も制御器も必要に応じて同じ情報を利用できます。
この性質は、設備内で状態情報を共有する用途と相性がよいです。
3. CANのIDとフレーム:優先順位を決める中心要素
CAN通信で最も重要な設計要素はIDです。
IDは単なる番号ではなく、メッセージの意味と通信上の優先順位を表します。
CANのデータフレームには、ID、制御情報、データ、エラーチェック情報などが含まれます。
ID設計が雑だと、通信は動いても保守性が悪くなります。
IDは宛先ではなくメッセージの種類を示す
CANのIDは、基本的には送信先アドレスではありません。
「このデータは何を意味するか」を表す識別子として使います。
たとえば、IDごとに「速度指令」「速度現在値」「異常コード」「入力状態」などを割り当てます。
受信側は、必要なIDだけを受け取り、不要なIDは無視します。
この考え方を理解すると、CANのブロードキャスト性を設計に活かしやすくなります。
IDが小さいほど優先順位が高い
CANでは、複数ノードが同時に送信を始めた場合、IDによる調停が行われます。
一般的に、数値の小さいIDほど優先順位が高くなります。
高優先度のメッセージは送信を継続し、低優先度のメッセージは送信をいったん待ちます。
この仕組みにより、非常停止、異常通知、重要な制御情報を優先させる設計ができます。
一方で、重要度の低いデータに高優先度IDを割り当てると、肝心の制御データを圧迫します。
標準IDと拡張IDの違い
CANには、標準IDと拡張IDがあります。
標準IDは11ビットのIDを使い、拡張IDは29ビットのIDを使います。
小規模な機器間通信では、標準IDで十分な場合が多いです。
多数のノードや複雑なメッセージ体系を扱う場合は、拡張IDが使われることがあります。
ただし、IDが長ければ必ず良いわけではありません。
データ量、互換性、既存機器の仕様を確認して選定する必要があります。
| 項目 | 標準CAN ID | 拡張CAN ID |
|---|---|---|
| ID長 | 11ビット | 29ビット |
| 向く用途 | 小〜中規模の制御ネットワーク | 大規模・複雑なメッセージ体系 |
| 注意点 | ID数に制約があります。 | 対応機器と通信負荷を確認します。 |
4. 終端抵抗と配線:CAN通信で最初に確認する場所
CAN通信のトラブルでは、プログラムより先に配線を確認すべき場面が多くあります。
特に重要なのが、終端抵抗、バス形配線、スタブ長、グランドの扱いです。
CANは電気的なバス通信なので、論理設計だけでなく物理配線の品質が通信安定性を左右します。
終端抵抗はなぜ必要か
CANバスでは、通信線の端で信号が反射すると波形が乱れます。
終端抵抗は、この反射を抑えて波形を安定させるために入れます。
一般的には、バスの両端に120Ωの終端抵抗を入れます。
両端に120Ωが入っている場合、電源を切った状態でCAN_HとCAN_L間を測ると、おおよそ60Ωになります。
この確認は、現場で配線状態をざっくり見るときに有効です。
終端抵抗は両端だけに入れる
終端抵抗は、各機器に何個も入れればよいものではありません。
バスの物理的な両端にだけ入れるのが基本です。
途中のノードに終端抵抗を入れると、合成抵抗が下がりすぎて通信波形が崩れることがあります。
逆に、片側だけ、またはどちらにも終端がない場合も、反射で通信が不安定になります。
通信できたりできなかったりする場合は、最初に終端抵抗の位置と数量を確認しましょう。
スタブ配線は短くする
CANバスでは、幹線から各ノードへ短い枝線を出すことがあります。
この枝線をスタブと呼びます。
スタブが長いと、そこでも反射や波形乱れが発生しやすくなります。
高速通信ほど、スタブの影響は大きくなります。
基本方針は、幹線をできるだけまっすぐ通し、ノードへの枝線を短くすることです。
I/O配線と同じ感覚で自由に分岐すると、通信品質を落とす原因になります。
関連記事
5. エラー検出の仕組み:CANが制御用途に強い理由
CAN通信は、単にデータを送るだけの通信ではありません。
送信データの異常を検出し、異常なノードを通信から切り離すための仕組みを持っています。
この自己監視性が、制御用途でCANが使われる大きな理由です。
複数の方法で通信エラーを検出する
CANでは、ビットレベルの異常、フレーム形式の異常、CRCによるデータ異常などを検出します。
受信ノードは、受信したフレームが正しいかを確認します。
異常を検出すると、エラーフレームによってバス上の他ノードにも異常を知らせます。
これにより、誤ったデータがそのまま制御に使われるリスクを抑えます。
ただし、エラーが検出できるからといって、原因が自動で分かるわけではありません。
ACKで受信成立を確認する
CANでは、送信されたフレームを正常に受信したノードがACKを返します。
送信側は、ACKが返らない場合、正常に受信されなかったと判断します。
配線断線、終端不良、通信速度設定ミス、受信ノード不在などがあると、ACKエラーが出ることがあります。
立ち上げ時にACKエラーが続く場合は、まず相手ノードが本当に同じ通信速度で動いているか確認します。
エラーカウンタとバスオフ
CANコントローラは、送信エラーや受信エラーの回数を内部で管理します。
エラーが増えると、ノードは通常状態から警告状態、さらに受動的な状態へ移ります。
重大な異常が続くと、バスオフ状態になり、自ら通信から離脱します。
これは、壊れたノードがバス全体を妨害し続けることを防ぐための仕組みです。
保全時には、バスオフの有無だけでなく、そこに至った原因を確認する必要があります。
6. CANopenとは:CANの上で動く上位プロトコル
CANとCANopenは同じ意味ではありません。
CANは物理層とデータリンク層を中心とした通信の土台です。
CANopenは、そのCANの上で機器を標準的に扱うための上位プロトコルです。
フィールドバスの一種として、ドライブ、I/O、センサ、計測機器などで使われます。
CANは道路、CANopenは交通ルール
CANとCANopenの違いは、道路と交通ルールに例えると分かりやすいです。
CANは、車が走る道路や信号の伝わり方に相当します。
CANopenは、どの車線をどう使い、どの標識に従い、どんな手順で運転するかを決めるルールです。
CANだけでも独自通信は作れます。
しかし、機器間の意味づけや設定手順を標準化したい場合は、CANopenが有利です。
PDOとSDO:高速データと設定データを分ける
CANopenでは、代表的な通信としてPDOとSDOがあります。
PDOはProcess Data Objectの略で、制御中に繰り返し使う入出力データに向きます。
たとえば、デジタル入力状態、アナログ値、速度指令、位置現在値などです。
SDOはService Data Objectの略で、設定値の読み書きやパラメータ変更に向きます。
頻繁に流すデータと、必要時だけ読みに行くデータを分けることで、通信負荷を整理できます。
オブジェクトディクショナリで機器情報を整理する
CANopen機器は、オブジェクトディクショナリと呼ばれるデータ表を持ちます。
ここには、機器の設定値、状態、入出力データ、通信設定などが整理されます。
ユーザーは、インデックスとサブインデックスを指定して、必要な項目を読み書きします。
この仕組みにより、メーカーが違っても共通の考え方で機器を扱いやすくなります。
CANだけの独自実装では、この部分を自分たちで設計する必要があります。
7. CAN通信とCANopenの違い:どちらを選ぶべきか
CAN通信とCANopenの違いを整理すると、CANは低レベルの通信方式、CANopenは機器制御用の標準化された通信規約です。
どちらが優れているというより、目的が異なります。
自社基板同士を小規模につなぐ場合と、市販ドライブやI/O機器を組み合わせる場合では、選び方が変わります。
違いを比較表で整理する
| 比較項目 | CAN通信 | CANopen |
|---|---|---|
| 位置づけ | 通信の土台です。 | CAN上で動く上位プロトコルです。 |
| データの意味 | 設計者が自由に決めます。 | 標準的な構造に従って扱います。 |
| 設定方法 | 独自仕様になりやすいです。 | SDOやオブジェクトディクショナリを使います。 |
| 向く用途 | 自社内の専用通信に向きます。 | 市販機器の接続や保守性重視に向きます。 |
| 注意点 | 仕様管理を自社で行う必要があります。 | プロファイル理解と設定作業が必要です。 |
CANだけで十分なケース
小規模な基板間通信や、メッセージの種類が少ない装置では、CANだけで十分な場合があります。
たとえば、自社マイコン基板同士で数種類の状態情報を共有する用途です。
この場合、ID割付、周期、データ配置、エラー時処理を自社仕様として明確に決めます。
仕様が小さければ、CANopenを入れるよりも軽量で分かりやすい設計にできます。
ただし、後から機器が増える場合は、独自仕様の拡張性を慎重に考える必要があります。
CANopenが向くケース
市販のドライブ、リモートI/O、センサ、アクチュエータを組み合わせる場合は、CANopenが向きます。
標準的な機器プロファイルや設定手順が用意されているため、機器交換や保守の考え方を整理しやすくなります。
CC-LinkやPROFINETと同じように、現場機器をネットワーク化する選択肢の一つとして考えます。
ただし、CANopenだから設定が不要になるわけではありません。
PDOマッピング、ノードID、通信速度、NMT状態、ハートビートなどを理解して設定する必要があります。
関連記事
8. 実務での設計ポイント:ID・周期・負荷を見積もる
CAN通信を安定させるには、配線だけでなく通信設計も重要です。
特に、ID設計、送信周期、通信負荷、異常時動作を事前に決めておく必要があります。
PLCやマイコンで扱う場合も、単に送受信できたかだけでなく、制御周期との関係を確認しましょう。
ID設計:重要度と意味を先に決める
IDは、後から適当に追加していくと管理できなくなります。
最初に、制御指令、状態通知、異常通知、設定系データを分類します。
異常停止に関わる情報や高速制御に必要な情報には、高い優先順位を与えます。
一方で、表示用データや保全用データは、優先順位を下げても問題ない場合があります。
ID一覧表を作り、ID、送信元、データ意味、周期、バイト配置を明記しておくと保守性が上がります。
送信周期:速ければよいわけではない
制御データは速く送りたくなりますが、すべてを短周期にするとバス負荷が増えます。
バス負荷が高くなると、低優先度メッセージの遅れや欠落が目立ちやすくなります。
速度指令、入力状態、温度値、保全情報では必要な更新周期が異なります。
たとえば、制御に使うデータは短周期、温度や診断情報は長周期に分けます。
PLCスキャンタイムとの関係も考え、通信周期だけを短くしすぎないことが大切です。
通信負荷:ID数とデータ長から概算する
CANバスの余裕を見るには、送信周期とフレーム数から通信負荷を概算します。
厳密な計算にはビットスタッフィングなどの要素もありますが、初期設計では安全側に余裕を見ます。
通信負荷が高い場合は、不要な周期送信を減らす、データをまとめる、優先順位を見直すといった対策を行います。
複数の周期タスクで通信する場合は、イベント駆動型の送信も検討できます。
ただし、イベント送信だけにすると、相手機器が生存確認しにくくなることがあります。
周期送信とイベント送信を組み合わせる設計が現実的です。
9. CAN通信トラブルの切り分け:配線から順に確認する
CAN通信が不安定なとき、いきなりソフトを疑うと遠回りになることがあります。
まずは、通信速度、終端抵抗、配線極性、グランド、ノードID、エラー状態を順番に確認します。
特に立ち上げ直後は、設定ミスと配線ミスが多くを占めます。
通信できないときの確認順序
最初に、全ノードの通信速度が一致しているか確認します。
次に、CAN_HとCAN_Lが入れ替わっていないか確認します。
そのうえで、電源OFF状態でCAN_HとCAN_L間の抵抗を測定します。
両端終端が正しく入っていれば、おおよそ60Ωになるはずです。
この時点で大きく外れていれば、終端抵抗の不足、過多、断線、接続ミスを疑います。
通信はできるが時々止まる場合
時々止まる場合は、波形品質、ノイズ、通信負荷、バスオフを疑います。
モータ起動時だけエラーが増えるなら、電源ノイズや配線経路の影響を確認します。
特定の動作時だけ止まるなら、そのタイミングで高優先度メッセージが集中していないか確認します。
診断ログにエラー種類や発生時刻を残しておくと、原因切り分けが容易になります。
デバウンス処理と同じく、入力の揺らぎを通信異常と誤認しない整理も必要です。
ネットワーク選定を見直すべきケース
CANは堅牢な通信ですが、大量データや高速な設備間通信には向かない場合があります。
画像データ、長いログ、上位システム連携まで同じ通信に載せると、設計が苦しくなります。
設備全体のデータ連携には、OPC UAやMQTTのような上位連携向け技術を組み合わせる考え方もあります。
高速な産業Ethernetが必要な場合は、EtherNet/IPなど別方式との使い分けを検討します。
CANは、あくまで短い制御データを堅実に流す近距離ネットワークとして考えると使いやすいです。
まとめ
CAN通信は、複数の制御機器が同じ2本線を共有し、短い制御データを高信頼にやり取りする通信方式です。
差動信号、IDによる優先順位、終端抵抗、エラー検出の仕組みを理解すると、現場トラブルを切り分けやすくなります。
CANopenは、CANの上で機器の設定やデータ交換を標準化する上位プロトコルです。
自社基板間の小規模通信ならCANだけ、市販機器を組み合わせるならCANopenが有力な選択肢になります。
実務では、通信速度、終端抵抗、ID設計、送信周期、バス負荷、エラー時動作をセットで確認することが重要です。
配線だけ、プログラムだけで判断せず、物理層と通信設計の両方から安定化を進めましょう。