CANとはController AreaNetworkの略称です。
1989年にRobert Bosch GmbH社により開発され、ISOで国際的に標準化されたシリアル通信プロトコルです。

CANの主な特徴は、以下の通りです。詳細はCANの特徴を参照してください。

• 低コスト・シンプル（省配線->重量・コスト軽減）
  シリアルバスなので配線を少なくできます。
  センサーを共有できます。
• 信頼性の高い伝送
  簡単な配線
  高度な機能
• リアルタイム能力
  データレート最大1[Mbps]（40mまで）
• 長距離転送
  最大1[km]（50kbps）
• 簡単な利用方法

元来、自動車で使用のために開発されたCANシリアル・バス・システムは、ますます、ビル・オートメーション・医療機器・海洋関係の電子機器での利用が増加しています。産業用フィールド・バスと自動車用バス・システムの要求は、以下のように驚くほどの類似を示します。

• 低コスト
• 電気的に粗悪な環境
• 高いリアルタイム処理能力
• 簡単な利用方法

医療機器製造業者などは安全に対して厳しい要求があるためCANを採用しています。同様の問題は、ロボットや輸送システムなどの安全に関して特別な要求のある他の製造業者も直面しています。

CANの必要性

自動車には既に多数の電子制御機器が搭載されています。これらの電子機器は以下のような要求から高度化・増大してきました。

• お客様からのより高度な安全性・快適性に対する要求
• 政府からの排気ガス低減・低燃費の要求

現在、以下のような制御が行われています。

• エンジンの点火タイミング制御
• ギアボックス
• スロットルバルブ制御
• ABS(Anti-Block System)
• ASC(Acceleration Skid Control)

従来、これらのシステムは単独で使用されていましたが、搭載されるシステムが増大するに従い配線数の増大、センサーの重複などが問題となります。また、さらに高度な性能を追求した結果、これらのシステムを統合して制御する必要が生じます。

統合、もしくは協調して制御する場合には、これらのシステム間でデータ通信を行う必要があります。従来、各機器、もしくはメーカーごとに専用の通信方法を使用していましたが、システムの機能がより複雑になると通信方法が複雑になり開発期間の長期化・高コストになってしまいます。

現在、複数のデバイスを制御する必要のあるシステムはさらに多くなってきています。例えばASCはホイールスピンしたときにエンジントルクを小さくするために、エンジン点火タイミングとスロットル制御を相互に管理する必要があります。
また、電子制御変速機では点火タイミングを調整することによってギアを容易に変更できるように改良することができます。

今後、自動車の最適化を目的とした開発を考える場合、従来の通信システムの制約に打ち勝つ必要があります。これらの問題を解決するためにはシリアルデータバス方式を利用してシステムをネットワーク化することです。このような理由からボッシュはCANを開発しました。

自動車におけるCANの利用分野

典型的な例として以下のような利用分野があります。

CANの産業アプリケーション

産業用フィールド・バスと自動車用バス・システムの要求は、以下のように驚くほどの類似を示します。

• 低コスト
• 電気的に粗悪な環境
• 高いリアルタイム処理能力
• 簡単な利用方法

ルセデス・ベンツ"S"クラスのCAN標準採用や高速な転送速度（最大 1MBit/s）からU.S.商業車メーカーがCANを採用したことが産業界のユーザーに耳をそばだてさせました。農業機械や船がCANを選択しただけで なく、医療器具、織物機械、エレベータ制御などにも採用されています。

織物機械産業は、CAN開拓者の１人です。ある製造業者は、 1990年早期からCANネットワーク経由でリアルタイムに織物機械と通信するモジュールシステムを開発しました。そのうち、いくつかの織物機械製造業者 達は、"CAN Textile Users Group" (後の国際的なユーザー・製造業者グループ"CAN in Automation")に加わりました。織物機械と同様の要求が、包装機械業界・製紙機械工場でもあります。

USAでは多くの事業社が生産ラインや製造機械のセンサーやアクチュエータをネットワーク化するための内部バスとしてCANを利用しています。

医療機器製造業者などは安全に対して厳しい要求があるためCANを採用しています。同様の問題は、ロボットや輸送システムなどの安全に関して特別な要求のある他の製造業者も直面しています。

これまでの高速・高信頼性とは別に、ステーション当たりの低い接続コストはCANの決定的な特徴です。

CANの特徴

CANには以下の特徴があります。

（1）マルチキャスト
全てのデバイスはメッセージを同時に受け取ります。

（2）マルチマスタ
バスが空いていれば、全てのデバイスがメッセージを送信することができます。

（3）システムのフレキシビリティ
ネットワーク内のデバイスにアドレスなどを割り付ける必要はありません。メッセージ（エンジン回転数・温度など）の内容はメッセージに付加されたネットワーク内で固有の識別子（ID）により定義されます。
このようにメッセージのみで認識できるため新規にデバイスを追加・削除してもソフトウェアやハードウェアを変更する必要がありません。
（4）衝突検出方法
オフィスで使用しているLANでは複数のPCが同時にデータを送信した場合、データの衝突が起こります。このとき全てのPCは送信を中止してある時間が経過した後に再度送信を試みます。（CSMA/CD [Carrier Sense MultipleAccess with Collision Detection]）CAN ではメッセージに付加されたIDが優先度も定義します。複数のデバイスが同時にデータを送信した場合、優先度の低いデバイスは送信を止め、優先度の高いデ バイスが送信を続けます。（CSMA/CD+AMP [Carrier SenseMultiple Access with Collision Detection and Arbitration on Message Priority]）
（5）遠隔データ要求
リモートフレームを送出することで他のデバイスに対応するデータフレームを要求することができます。データフレームとリモートフレームは同じIDとなります。
（6）通信速度
最大1MBit/sの通信速度まで利用できます。転送速度は40m以上ではケーブルの長さに依存します。

但し、1つのネットワーク内のデバイスは同じ通信速度に設定しなければなりません。異なる通信速度を持つデバイスを同じネットワーク内に混在させてはいけません。
（7）接続台数
接続可能な台数に理論的な制約はありません。但し、実際にはバスの遅延時間と電気的な負荷により接続台数は制限されます。高速な通信速度になるほど接続可能な台数は少なくなります。

（8）エラー検出・エラー通知・リカバリー機能
全てのデバイスはエラー検出機能（CRC・フレーム チェック・ACKエラー・モニターリング・ビットスタッフ）を備えます。あるデバイスがエラーを検出した場合、"エラーフラグ"を送出して他のデバイスが エラーのあるメッセージを取得することを防ぎ、ネットワーク内のデータを保証します。
メッセージを送出するデバイスがエラーを検知した場合、その送信を終了して自動的に再送信します。次のメッセージを送出するまでの回復時間は最大29ビット分です。

（9）故障時の対応
CANプロトコルには一時的なエラーと恒久的なエラー（故障・断線など）を区別する機能があります。恒久的なエラーが存在するデバイスをネットワークから除外します。

（10）スリープモード/ウェイクアップ
システムの電力消費を低減するためにデバイスをスリープモードにすることも可能です。バスがアクティブになったときにウェイクアップします。

メッセージ

■ フレーム形式

■ データフレーム

送信デバイスがデータを転送する際に使用するフレームです。
フレームの構成は以下のようになっています。

● SOF(Start Of Frame)

データフレームやリモートフレームの開始位置を示します。
ビットレベルは"ドミナント"です。

● Arbitration

このフィールドは標準フォーマットと拡張フォーマットで異なります。

ID：
デバイスのIDを指定します。
標準フォーマット、および拡張フォーマットでは上位7ビットを全てリセッシブにすることは禁止されています。（ID:1111111XXXX）
拡張フォーマットではベースID（ID28-18）と拡張ID（ID17-0）を使用します。

RTR ( Remote Transmission Request BIT ):
データフレームではビットレベルは"ドミナント"です。
リモートフレームでは"リセッシブ"です。

標準フォーマット：

拡張フォーマット：

● Control

データ長を示すコード（DLC）と予約ビット（ｒ0 , ｒ1）を記述します。
予約ビットは"ドミナント"です。

データ長コード（DLC）：　"d"=ドミナント、"ｒ"=リセッシブ

● DATA

0～8バイトのデータを含みます。MSBから転送されます。

● CRC

フレームの転送エラーをチェックします。
CRCシーケンスとCRCデリミタ（区切り）で構成されます。

CRCシーケンス
チェックにはBCH符号を用い、SOF～DATAまでのフィールドに対して計算されます。
受信側でもこの値を用いて計算を行うことにより転送中のエラーを訂正することができます。
ハミング距離=6ですので、最大5ビットのエラーを訂正することができます。

CRCデリミタ
ビットレベルは"リセッシブ"です。

● ACK

ACKはACKスロットとACKデリミタの2ビットで構成されます。
送出デバイスはACKを全て"リセッシブ"で送出します。

ACKスロット
受信側はデータを正常に受け取った場合、これを示すためにACKスロットを"ドミナント"にして送出デバイスに報告します。

ACKデリミタ
ビットレベルは"リセッシブ"です。

EOF
データフレームやリモートフレームの終了位置を示します。
7ビットで構成され、ビットレベルは全て“リセッシブ”です。

■ リモートフレーム

受信デバイスかが希望するデバイスに指定したデータを転送要求するフレームです。
リモートフレームは6つのフィールドで構成され、以下のようになっています。

各フィールドの構成はデータフレームに準じます。
但し、以下に注意してください。

（１）ArbitrationフィールドのRTRは“リセッシブ”です。
（２）DATAフィールドは存在しません。

■ エラーフレーム

エラーを検出したデバイスがエラーを通知するために使用します。
エラーフレームは2つのフィールドから構成され、以下のようになっています。

エラーフラグ

エラーフラグには2種類あります。

1. アクティブエラーフラグ
   6ビットの連続した“ドミナント”
2. パッシブエラーフラグ
   6ビットの連続した“リセッシブ”。他のノードからの“ドミナント”により上書きされます。
   エラーアクティブなデバイスはエラーを検出するとアクティブエラーフラグを転送します。
   このエラーフラグはSOF～CRCデリミタまでのビットスタッフ則やACK、EOFの状態を
   破壊します。この操作により他の全てのデバイスもエラーを検出し、エラーフラグを
   通知します。これにより、最小6ビット、最大 12ビットのエラーフラグが重ね合わされます。
   エラーパッシブなデバイスがエラーを検出するとパッシブエラーフラグを転送します。
   エラーパッシブなデバイスはそのまま6ビット同じ状態が続くまで待ちます。
   この6ビットが完了したときにエラーパッシブフラグを終了します。

エラーデリミタ
8ビットで構成され、ビットレベルは全て"リセッシブ"です。

■ オーバーロードフレーム

デバイスが受信可能状態でないときに発行します。
オーバーロードフレームはオーバーロードフラグとオーバーロードデリミタで構成されます。

オーバーロードフラグ

6ビットの連続した"ドミナント"。
オーバーロードには2つの状態があります。

1. 次のデータフレーム・リモートフレームの遅延が必要な状態
   インターミッションの最初のビットのみでオーバーロードフラグを発行できます。
2. インターミッション中に"ドミナント"ビットを検出
   ドミナントビットを検出した後でオーバーロードフラグを発行できます。

   オーバーロードデリミタ

   8ビットで構成され、ビットレベルは全て"リセッシブ"です。

   ■ インターフレームスペース

   データフレームとリモートフレームを分離します。
   インターフレームスペースはインターミッションとバスアイドルで構成されます。また、直前のメッセージがエラーパッシブなデバイスのものであるとき、サスペンドトランスミッションも構成されます。

   通常：
   
   
   直前メッセージがエラーパッシブ：
   

   インターミッション

   6ビットの連続した"リセッシブ"。
   インターミッション中はデータフレームやリモートフレームを開始できません。

   バスアイドル

   "リセッシブ"でビット長さは決まっていません。どのデバイスもバスにアクセスしていない状態を示します。

   サスペンドトランスミッション

   1. 直前のメッセージがエラーパッシブの場合、インターミッションの後に8ビットの"リセッシブ"を追加します。

      エラーハンドリング

      ■ エラー検出

      次のエラーを検出することができます。

      ビットエラー	データを送出デバイスは同時にバスをモニターしています。モニターしているビットが送出したビットと異なっていた場合、ビットエラーを検出します。
      スタッフエラー	ビットスタッフ則に従わずに連続した6ビットが同じビットレベルの場合に検出されます。
      CRCエラー	CRCシーケンスにトランスミッターで計算されたCRC計算結果が記述されています。レシーバーがCRCを計算して結果が異なる場合にCRCエラーが検出されます。
      フォームエラー	ビット数が固定されたフィールドに不正なビットが含まれている場合、フォームエラーを検出します。
      認証エラー	レシーバーからのACKスロットにドミナントビットが返されない場合、トランスミッターが認証エラーを検出します。

      ■ エラー出力

      エラーを検出したデバイスはエラーフラグを出力します。エラーアクティブなデバイスはアクティブエラ ーフラグ、エラーパッシブなフラグはパッシブエラーフラグを出力します。

      次のエラーを検出したときには直後のビットからエラーフラグを出力します。

      ・ビットエラー
      ・スタッフエラー
      ・フォームエラー
      ・認証エラー
      
      

      次のエラーを検出したときにはACKデリミタの後からエラーフラグを出力します。

      ・CRCエラー

      障害制限

      バスに障害を与えるデバイスは通信状態に応じて以下の状態を推移し、バスへの参加を制限されます。

      エラーアクティブ	通信に参加し、エラーを検出した場合、アクティブエラーフラグを送出します。アクティブエラーフラグが発行されると他のデータフレームを強制的に終了させます。
      エラーパッシブ	通信に参加できますが、エラーを検出した場合、パッシブエラーフラグを送出します。パッシブエラーフラグはアクティブエラーフラグのようにデータフレームを強制的に終了させることはできません。 また、パッシブエラーフラグを送出した後、インターフレームスペースのサスペンドトランスミッションが発行されるまで待たなければなりません。
      バスオフ	バスには影響を与えません（出力機能をオフにします）。

      上記状態を監視するために全てのデバイスには2つのカウンターが搭載されます。
      （１）送信エラーカウンタ(TEC)
      （２）受信エラーカウンタ(REC)

      カウンターの値は以下の規則に従い値が変更されます。
      また、カウンターの値に応じて上記の状態が変化します。

      No	状態	TEC	REC
      1	受信デバイスがエラーを検出。（アクティブエラーフラグやオーバーロードフラグを送出中のビットエラーは除く。）	-	+1
      2	エラーフラグを送出した直後の最初のビットがドミナント。	-	+8
      3	送信デバイスがエラーフラグを送出	+8	-
      4	送信デバイスがアクティブエラーフラグやオーバーロードフラグを送出中にビットエラーを検出	+8
      5	受信デバイスがアクティブエラーフラグやオーバーロードフラグを送出中にビットエラーを検出	-	+8
      6	送受信デバイス共にアクティブエラーフラグ、パッシブエラーフラグ、オーバーロードフラグを送出後には最大連続した7ビットのドミナントを許容します。 アクティブエラーフラグ、オーバーロードフラグでは14ビットの連続したドミナント、パッシブエラーフラグの後の8ビットの連続したドミナント、この後に8ビットの連続したドミナントを検出するたび	+8	+8
      7	送信成功時	If TEC<>0 TEC= -1 If TEC=0 TEC=0	-
      8	受信成功	-	If 1<=REC<=127 REC= -1 If REC=0 REC= 0 If REC>=128 REC= 119～127
      9	TEC、RECが128以上の場合、エラーパッシブ状態へ移行。
      10	TECが256以上の場合、バスオフ状態へ移行。
      11	TEC、RECが127以下になった場合、エラーパッシブからエラーアクティブへ移行。
      12	11ビットの連続したリセッシブビットが128回発行された場合、TEC、RECを0にしてバスオフからエラーアクティブへ移行	0	0