総まとめ、活用・トラブル事例から学ぶCAN：車載ネットワーク“CANの仕組み”教えます（5）（2/3 ページ）

[増田浩史（ベクター・ジャパン），MONOist]

自動車内におけるCANの使用例

　現在、CANはパワートレイン系やボディ系などさまざまな部分で使用されているが、個々の「ECU（Electronic Control Unit）」はどのように使用されているのだろうか？

　ご存じのとおり、CANの主な用途はECU間でのデータのやりとり（ECU間通信）だ。これについてはデータを周期送信する、何かが発生したときに（イベント）送信するなど、さまざまな通信方式がある。しかし、周期送信もECU内部でのタイマーによるイベントだと考えるとCANは基本的に“イベント型通信”であるといえるだろう。

　これまで主に、ECU間通信で使用されてきたCANであるが、現在では車載ネットワークの基本といえるほど普及し、ECU間のデータ交換だけでなくほかの用途での利用が増えている。例えば、各ECUの故障診断の際、従来使用してきた専用の通信線ではなく、CANを使用・統合した「Diag On CAN（診断通信）」（注1）を用いたり、CAN通信を利用して、ECU内部のデータを書き換えたり（キャリブレーション）、内部値を読み込んだりする「XCP」（注2）などがそれに当たる。

図8　Diag On CAN
※ベクター・ジャパンの資料を基に作成

図9　XCP
※ベクター・ジャパンの資料を基に作成

※注1：Diag On CANとは、各ECUの診断情報交換をCAN通信で行うもの。

※注2：CCP（CANキャリブレーションプロトコル）を改善、統合したもので、CAN以外のプロトコルでも使用可能。CAN通信を使用し計測やキャリブレーションを行える。

　しかし、こうしたさまざまな用途でのCANの利用や、ECUの増加などは、バスへの負荷として影響を与えてしまう。そこで、現在CANでは通信時に1チャンネルを使用するのではなく、2チャンネル以上を使用して多チャンネル化し、必要に応じた通信を別々のチャンネルに流す方式を採用している。

　このCANの多チャンネル化以外にも、ほかの車載ネットワーク用プロトコルを同一車両内で使用するケースも増えてきている。例えば、「LIN」や「FlexRay」などがそれに当たる。具体的には、CANコントローラを使用するとコストへの影響が大きくなるセンサー・アクチュエータ分野にはLINを、イベント型通信ではなくリアルタイム性を重視するような分野にはFlexRayを使用するなど、用途によりさまざまな通信プロトコルを使用するようになってきている。

　こうしたケースでは、同一車両内にそれぞれ異なるプロトコルで構成された車載ネットワークが存在することになるが、個々のネットワークが別々に通信を行うケースはほとんどなく、プロトコルを変換し、必要な情報をほかのネットワークにデータ伝送するためのゲートウェイが設けられている場合が多い。

	関連リンク：
⇒	いまさら聞けない 車載ネットワーク入門

CANにおけるトラブルの例

　次に、CANを採用した際によく発生する（可能性がある）トラブル事例と、解決のヒントをいくつか列挙しよう。

トラブル1：仕様に定義された通信周期と実際の通信周期が異なっている

→CANは「CSMA/CA（Carrier Sense Multiple Access with Collision Avoidance）」を採用しており、CANバスに他ノードからのデータフレームなどが流れている場合は送信待機を行う。このため、極めて正確な周期でのデータ送信が行えない場合も多くある（通信仕様には許容範囲が記載されている場合が多い）。

トラブル2：通信が行えない

→開発初期段階で物理層に終端抵抗が接続されていないことなどが考えられる。また、断線やエラーによるバスオフ状態なども考えられる。

トラブル3：電源投入時にエラーフレームが発生する

→各ノードの初期化中に発生する場合がある。これは、ノードの初期化中などにアクナレッジ送信が行えなかったことなどが考えられる。

トラブル4：測定機器にて測定が行えない

→基本的な設定のため忘れてしまいがちだが、通信速度や信号の特性に合わせた基本設定を行っていないことが考えられる。

トラブル5：エラーフレームが頻発する、または通信が正常に行えない

→CANバスの使用率（バス負荷）が高い場合、通信調停による再送信が頻発している可能性がある。また、物理層の問題により、受信ノードからアクナレッジが返ってきていないことも考えられる。

トラブル6：バスオフが発生しやすい

→送信エラーが頻発することによりバスオフとなるので、配線の確認など物理的な要因がまず考えられる。