CAN通信いろいろ

##・はじめに
CAN通信は主に自動車業界で使われている。航空関係でもチラホラつかわれているらしい。
ポイントは品質大事!!な業界での採用が多いこと。
通信の信頼性が高い、ハーネスの減少(=コストの削減)、などが主な特徴。

##・CAN通信は車内LANの一種
CANは制御系車内LANのデファクト・スタンダード！
車内LANといっても1種類だけではなく、
通信速度や信頼性，配線の物理的な性質などが異なる複数の方式があり、
用途によって使い分けられている。

膨大かつ複雑な配線量が増えたことで，その重量増加が燃費を悪化される原因になっていました。また，配線のためのスペースが拡大したことで，そのしわ寄せで車内空間が狭くなってしまうといった悪影響も出てきました。本来は燃費を良くしたり，快適な車内空間を実現したりするためのECUの搭載が，逆にデメリットを与えるようになり。。
これらの問題を解消するために配線量の削減が必要不可欠になりました。
ここで登場してきたのが車内LANです。

##ポイント
ポイント1：マルチマスタ通信である
　CANはいずれのノードからも自由に通信が開始できるマルチマスタ方式です。通信開始のタイミングはイベントが起こることにより開始されます。ここでいうイベントとは，各ノードで通信を行う必要が発生したときのことを示します。内容は各自動車メーカーのシステム仕様により異なります。

　CANでは複数のノードで同時にイベントが発生した場合，各ノードの信号を用いて調停を行うことにより，通信の衝突を回避しています。このしくみについては後述します。

ポイント2：バス型のトポロジである
　CANのトポロジはバス型です。最大ノード数は通信速度に依存しますが，1Mビット/秒の場合に最大30ノードとなります。これは規格で決まっています。

ポイント3：差動伝送方式を用いる
　CANでは伝送路に載るノイズの影響を考慮し，2本の信号線の電圧差で“０”，“１”を判断する差動伝送方式を採用しています。それぞれの信号線をCANH，CANLと呼び，この電圧の差でバスレベルを決定しています。その差動により，論理“0”と“1”が決定されます。論理“0”のバス状態をドミナント，論理“1”のバス状態をリセッシブと呼びます。
　通信距離は通信速度に依存しますが，1Mビット/秒の場合で最大40mです。こちらも規格で決まっています。

ポイント4：高速版規格と低速版規格がある
　CANには通信速度の異なる二つの規格があります。一つはHigh-speed-CANです。High-speed-CANはISO11898として規格化されており，通信速度は最大1Mビット/秒，最小125kビット/秒となっています。もう一つはLow-speed-CANです。Low-speed-CANはISO11519として規格化されていて，最大125kビット/秒となっています。現在，普及している通信速度としては，高速なものから順に500kビット/秒，250kビット/秒，125kビット/秒，83.3kビット/秒，33.3kビット/秒などがあります。

ポイント5：エラーカウンタで状態遷移
　CANでは5種類のエラー検出に対応しています。各ノードはエラーカウンタを持っています。エラーが発生すると，決められた定数分だけカウンタをインクリメント（増加）させます。逆に通信が成功すると，やはり決められた定数分だけカウンタをデクリメント（減少）させます。このエラーカウンタの値によって通信状態をノードごとに遷移させます。こうしてノードごとに通信制限をかけるしくみになっております。
各ノードはエラーカウンタを持っており，その値によって状態を遷移させています。エラーカウンタはそれぞれのノードに送信用のTEC（transmit error count）と受信用のREC（receive error count)が存在します。状態は次の3種類となります。

　（1）エラーアクティブ
　　バスに正常に参加している状態です。

　（2）エラーパッシブ
　　エラーが頻発しており，バスに悪影響を与えている状態です。

　（3）バスオフ
　　自らをバスから切り離した状態です。バスに復帰する場合は復帰条件を満たす必要があります。

・イベント発生時に通信を開始する「イベントドリブン型」
イベントドリブン型では衝突することがある。
このためLINではマスタが通信のタイミングを管理することで，
CANでは各ノードが送信する信号を用いて調停を行うことで，これを回避している。
・一定周期で通信を行う「タイムトリガ型」
タイムトリガ型では通信開始のタイミングが衝突することはない。

##CAN通信の基本構成

##・CAN通信関連の開発業務
[ドライバ層]
最近はAutosarと呼ばれる車業界で標準化されたモノを使う風潮にあり、
このドライバ層を意識する機会や必要性は少なくなってくるとは思います。
筆者はほとんど触ったことはありません。
とはいえCANトランシーバから、CANのどのレジスタに受けてるかくらいは、
マイコンのUMを見ながらドライバ層のソフトと見比べて理解しておく、くらいは
しておいた方が良いかもしれません。
新規に改造する機会は少ないと思いますができるに越したことはないでしょう。

[MW/APL層]
多くはここの開発になるかと思います。
CANIDが追加になったり、既存のCANIDに信号を追加したり。
CANドライバより各ECUのCAN情報(データ部 8byte)を取得(もしくは送信)。
↓
受信の場合はバッファに受け、分解能などを考慮。
データ部(8byte)の情報が仕様書に書いてある。
↓
受けたCAN受信から制御用の処理に渡したり、ECUの故障状態の判定などに使用。
大体上記の流れだと思います。

##・CANプロトコル
重要なのはデータ部が8byteであるということ。
あとは通信速度がHighSpeed(500KB)かLowSpeed(125KB)か。
CANFDというデータ部64Byteで通信速度1MBの、CANの進化版も最近ちょこちょこ
採用されているのを見かけます。

##・CAN関連で使用するツールの紹介
CANoe/CANalyzer
→実際のECU間の送受信を模擬できる。CANデータの送受信確認などで使用。使用頻度は多い。

CANape
→CANプロトコルを使用したデータの書き換えや、ROMの書き換え、RAMデータのモニタに使用。
使用頻度は多い。

RAMScope
→バスオフや送受信トラブル、データ数十usなどのスパンでRAMの確認をしたいときに使用。
使用頻度はまあまあ。

オシロスコープ
→ハード/ソフト要因の問題の切り分けなどに使用。使用頻度は少なめ。