CAN

HMS は、CANベースのシステム対応製品として
最大級のラインアップを持つ企業のひとつです


HMS の製品とサービスは次のことを実現します。

  • すぐに使えるモジュールまたはプロトコルスタックを使用して、 CAN および CAN ベースの上位層プロトコルを柔軟かつ容易にお客様のデバイスに実装
  • CAN と他の産業用ネットワークの接続
  • PC と CANを接続し、PCベースの制御、設定、解析を実現
  • お使いのシステムを解析、メンテナンス

CAN テクノロジー概要

CAN Products and Services

PC Interfaces
 

PC と CAN の接続

Ixxat PC CAN インターフェース は、PC ベースのアプリケーションと CAN を容易に接続可能です。

  • 制御、解析、設定アプリケーションに
  • 様々なカード形状と PC インターフェース規格に対応
  • パワフルなドライバーパッケージ 

PC CAN インターフェース

 
 CAN Infrastructure Components

システムとデバイスの相互接続

CAN をベースとしたシステムの相互接続に、HMS はさまざまな リピーター、ゲートウェイ、ブリッジ を幅広く取り揃えています。

  • シンプルな配線で省コスト
  • システム拡張が可能
  • フィルターや変換機能
  • システム信頼性の向上、ガルバニック絶縁による回線保護
  • 長距離のブリッジング、Bluetooth やEthernet を使用して容易にシステムアクセス

CAN リピーター
CAN ブリッジ・ゲートウェイ

 
CAN Tools
 

解析と設定

CAN 製品の開発、システム設定、トラブルシューティングに、ツール製品を豊富に取り揃えています。

  • canAnalyser – CAN および CAN FD のメッセージやシグナルを容易に解析、送信、ログ
  • CAN トラブルシューティング – パワフルな小型ツール及び PC ベースのツール

canAnalyser
CAN 診断及びトラブルシューティング


IO Modules for CAN, CANopen and EtherCAT
 

デジタル・アナログ IO シグナルの接続

デジタル・アナログ IO シグナルを CAN や CANopen のシステムに接続するために、堅牢な筐体の IO モジュールを提供します。

  • CAN および CANopen に対応
  • 1台で容易にデジタル・アナログチャネルを設定可能

IO モジュール

CAN – 概要

 

CAN の歴史

低価格で高パフォーマンスな電子部品により、自動車業界はイグニッションや通信制御、アンチロック・ブレーキ・システム(ABS)などさまざまな機能エリアに自律的な電子制御ユニット(ECU)を導入することが可能になりました。 

すると、運転行動を向上させるさらなる機能改善のために、デバイス間の制御されたデータ交換を介してさまざまな制御装置に分散したすべてのプロセスの同期が必要となりました。

また自動車業界におけるデジタル通信システムの導入は、増加するボディコンポーネントや接続が必要な便利なカーエレクトロニクス(エアコンやシートミラー調節、パワーウィンドウ、盗難防止システム、ライトやドアロックなど)により、さらに進むこととなりました。

自動車の分野では、デジタル通信システムは主にケーブル配線の量や長さを削減したり、車内からフロントドアまでのグロメット部分など配線が難となる箇所を減らしてきました。

電磁妨害の強い環境におけるデータ伝送のセキュリティに対する高い要求により、適切な通信コンセプトの開発が必要でした。

これが、 Controller Area Network (CAN) プロトコル開発の背景であり、1983 年 Bosch 社により開発が始まりました。

その後、CAN は車以外にも幅広いアプリケーションに採用され、現在に至ります。

  • 特定用途自動車(ごみ収集車や消防車)
  • 公共交通機関(鉄道や電車、トラム、バス)
  • 農業 & 林業 (トラクターなど)
  • 軍用
  • 航空 & 海洋
  • ビル(エレベーター)
  • 建設機械(クレーン、掘削機など)

 

バストポロジー、参加者(ノード)の数

CAN ネットワークは、通常両端に 120 Ω の終端抵抗を持つライン型構造です(下図参照)。 スタブは限定的な拡張が許容され、自動車用アプリケーションではスター型バスも可能です。各ネットワークの参加者の数はプロトコルによって制限されず、使用されるコンポーネントのパフォーマンスに依存します。

CAN リピーターは、CAN ネットワークを拡張する場合に複数使用することができます。リピーターは 2 つまたはそれ以上の
CAN バスシステムのセグメントを物理的に接続したり、ツリー型やスター型トポロジーの実装、長いドロップラインを追加する必要がある場合に便利です。また、ガルバニック絶縁されたリピーターを使用することでネットワークセグメントを電気的に分離することが可能です。 

CAN-Technology-Line-Structure
図: CAN ネットワークのライン型トポロジー

 

CAN 電文

CAN バス上の通信は、「コントロールビット」と「データビット」の両方を含む「電文」を介して行われ、このような電文の「標準的な」設定をフレームといいます。

  • データフレーム: データソース(送信者)の主導で、送信者から 1 つ以上の受信者にデータを送信
  • リモートフレーム: 「リモートフレーム」 を介してバスサブスクライバー(受信者)はデータソースのある特定メッセージの送信をリクエストすることができます。
  • エラーフレーム: エラーフレームは、すべてのサブスクライバー(送信者または受信者)に伝送時に検出されたエラーを表示します。
  • オーバーロードフレーム: オーバーロードフレームを介して、CAN コントローラーはオーバーロードを知らせます。現在ではコントローラーの性能がよくなり、実装されません。

 

Producer-Consumer 方式によるメッセージ交換 

特定の 2 つのサブスクライバー間でメッセージが交換される「ノード志向の」送信と違い、CAN メッセージの送信は、「Producer-Consumer 方式」 に基づいています。サブスクライバー(Producer)から送信されたメッセージは、他のすべての参加者(Consumer)によって読み出されます。このため、メッセージは行き先でマークされるのではなく、ユニークな「メッセージID」でマークされます。ネットワークのすべてのサブスクライバーにメッセージを送信することを「ブロードキャスティング」といいます。

CAN-Technology-Format
図: 11 ビット ID (標準フォーマット、CAN 仕様 2.0A)

  • SOF: Start of Frame = 1 つのドミナントビット
  • RTR: Remote Transmission Request –  RTR ビットが設定された場合はリモートフレームを定義
  • IDE: Identifier Extension, 1 ビット
  • r0: 予約されたビット
  • DLC: Data Length Code = 4 ビット (データフィールドのバイト数、0 ~ 8 バイト、値 9 ~ 15 は非対応)

 

 

メッセージID は、CAN メッセージの内容を表しており、デバイスではありません。例えば計測システムでは、温度や電圧、圧力のパラメータに個別の ID が割り当てられる場合があります。しかしながら、データの合計がデータフィールドの最大長を超えない限りにおいて、いくつかのパラメータはひとつの ID にまとめることができます。

受信するデバイスは、関連するメッセージかどうかを ID に基づいて決定し、バス上で利用可能なメッセージストリームから除外します。 

CAN ID の標準フォーマットは、通常 11 ビットです。従って、システムごとに 2,048 の異なるメッセージを識別可能です。これはほとんどのアプリケーションに十分な数となります。しかしながら、トラックや SAE J1939 の特別なアプリケーションには、29 ビット ID (拡張フォーマット)を使用することで、最大 5 億 1200 万種のメッセージを定義することが可能です。

 

メッセージフォーマット

メッセージの始まり(図参照)は、リーディングドミナントビットによって開始され、11 ビット長のメッセージ ID が続き、さらにデータメッセージとデータリクエスト電文(リモートフレーム)とを識別するビットが送られます。

リモートフレームを介して、ネットワークノードがシステムの他のノードによる特定のメッセージ送信を行う場合があります。コントロールフィールドがこのメッセージの送信フォーマット(標準/拡張)とそれに続くデータバイトを指定します。

CAN メッセージのデータフィールドは、0~8 データバイトを収納します。このデータフィールドに 15 ビット CRC セグメントが続き、このセグメントにより受信者が受信メッセージを確認することが可能です。メッセージの送信者は Acknowledge (ACK)フィールドで、送信したメッセージが少なくとも 1 つのネットワークノードからエラーすることなく受信されたことを確認します。送信者側の障害の切り離しに使用されるこの確認は、ネットワーク上でエラーのないすべての受信ノードが ACK スロットでドミナントビットを送信することにより行われます。

End-of-frame field (EOF) は、最終的に CAN メッセージが完全にエラーすることなく送信完了したことを意味します。

 

CAN-Technology-Data-Frame

図: CAN メッセージの標準フォーマット(データフレーム)

  • Start of Frame (SOF) = 1 つのドミナントビット
  • Arbitration Field, ID セグメント(11 ビットまたは 29 ビット + 2 ビット)と RTR (Remote Transmission Request)で構成される
  • Control Field (CTRL) = 6 ビット
    • Identifier Extension (IDE) = 1 ビット
    • Reserved = 1 ビット
    • Data Length Code (DLC) = 4 ビット(データフィールドのバイト数、0 ~ 8 バイト、値 9 ~ 15 非対応)
  • Data Field  (DATA) = 0 ~ 8x8 ビット
  • Checksum (CRC) = レセシブ CRC デリミタビットに続く15 ビット 
  • Acknowledgment Field (ACK) = 2 ビット、ACK スロットとレセシブ ACK デリミタで構成される
  • End of Frame (EOF) = 7 ビット(レセシブ)
  • Intermission (IFS – Intermission Frame Space) = 3 ビット、連続したメッセージを分離する最小ビット数

 

マルチマスター方式、イベント指向のメッセージ送信

バスがフリーになるとすぐに CAN ネットワークの各参加者(ノード)がメッセージ送信を開始することができます。1 つ以上のネットワークノードが同時にメッセージの送信を開始する場合もあります。この場合、確かに 1 つのノードだけがメッセージ送信を続けるようにする選択プロセス(バスアービトレーション)が必要となります。
各ノードがメッセージ送信を開始することができるため、すべてのネットワーク参加者の間で直接情報送信が可能です。その結果、サイクリックメッセージ送信に比べてバス負荷が低く、データ通信速度の要件も低下します。

ロスレス、ビット単位のアービトレーション

「アービトレーション(調停)」は、CAN バス上でのスムーズで確かなメッセージ伝送を保証します。「アービトレーションフェーズ」では、同時に送信されたメッセージのうちどのメッセージが高い優先度を持つかが決定されます。このメッセージを送信するネットワークノードだけが、調停後にメッセージの送信を続行することができます。最も小さなメッセージ ID を持つメッセージが最も優先されます。

アービトレーションフェーズ(メッセージ ID、RTR(リモート・トランスミッション・リクエスト)ビットの送信を含む)では、各ノードがバス上のシグナルレベルを監視します。

仮にレセシブレベル(レセシブビット)を持つ 1 つのネットワークノードがドミナントバスレベル(ドミナントビット)を検出した場合、送信プロセスを即時中断し、受信状態へと切り替えます。それぞれのバスアービトレーションと同様に、メッセージが送信されると、この手続きが「ロスレスな」バスアクセスを確実にします。

 

CAN-Technology-Arbitration

図: ロスレスの原理、ビット単位のバス・アービトレーション

ノード 1、2 および 3 が同時にアービトレーションプロセスを開始します。2 の時に、ノード 2 が送信されたレセシブレベルをバスが保持していないことを検出し、アービトレーションプロセスを完了します。 3 の時に、ノード 1 が中止します。 4 (アービトレーションプロセスの最後)の時に、ノード 3 がデータを送信します。

 

優先度指向の通信

上記のアービトレーションプロセスは、バスがフリーになるといつでも最も高い優先度を持つメッセージがすぐに送信されることを保証します。
優先度指向の通信原理により、データ通信に利用可能な周波数帯の非常に効率的な使用を可能にします。優先度の低いメッセージは、優先度の高いメッセージの送信を遅延させることなくバスを 100% 使用します。通信速度 1 Mbit/s の最も高い優先度のメッセージには、最大遅延が 130 となります。一方で、CAN システムを設計する際に、高い優先度メッセージがバスをずっと占有するわけではないことに気をつける必要があります。いわゆる「送信ブロック時間」(CANopen のインヒビットタイム)の導入によって可能です。

 

ビットレートとバス長

CAN に使用されるビット単位のアービトレーション原理は、バスネットワークにあるすべてのノードのローカルビットレベルをビットタイムインターバル内に比較する必要があります。

バス上でシグナルが分散(伝播)するのに必要なシグナルの伝播時間はバス長に比例するため、必要となるビットインターバルの時間はバス長に応じて長くなります。
最大限可能なネットワークサイズは、基本的にバスメディアで必要なシグナル伝播時間のみによって決定されます。例えば、1 Mbit/s でのネットワークスパンは 40m、80 kbit/s で 1000 m を超えるネットワークサイズとなります。


CAN-Technology-Data-Rate
図: データ転送速度 対 ケーブル長の比率
点線はデータ転送速度 400 kbit/ 以下、ライン長 100 m 以上を表しています。緑色のエリアは、電気的トランジットタイムや他の限定的なパラメーターを考慮せずに許容された使用範囲です。

最大バス長(バス拡張)と最大ビットレートは逆に振舞います。100 m 以上のバス長には、次の式を使うことができます。

ボーレート (Mbit/s) x バス長 (m) = 60

 

エラー検出と故障分離

CAN プロトコルの主な特長のひとつに、送信エラーの検出に高い能力を持つことが挙げられます。 これにより CAN は自動車内の制御装置をネットワークでつなぐ非常に高い基準に対処できるのです。
エラー検出の高い能力は、いくつかの手段を組み合わせて実現されています。 最も効果的な手段のひとつに、メッセージの送信者によるバスレベルの監視(「ビットモニタリング」)があります。この方法で、全体に有効なすべてのエラーが検出されます。また、それぞれのメッセージ受信者も CRC セグメントや固定フォーマットエレメントを使用して
受信したメッセージをチェックします。このように、ローカルで有効なエラーも検出されるのです。

送信エラー検出の他、CAN プロトコルは故障ノードの検出し分離するメカニズムを持っています。これにより不具合のあるネットワークノードがメッセージ伝送をコンスタントに妨害することはありません。

 

エラーシグナル送信

サブスクライバー指向の送信による通信コンセプトと違い、メッセージ指向のプロトコルとして CAN は各ノードが正確を期してバス上に送信されたそれぞれのメッセージをチェックする、「エラーシグナル送信の原理」を採用しています。
送信または受信するノードがエラーを検出すると、このノードはエラーメッセージ(エラーフレーム)を他のすべてのノードに送信して知らせます。 このメッセージには、通常ドミナントビットシーケンスとして(他には無効な)同じ極性の 6 ビットの組み合わせが含まれます。すべてのノードがエラーシグナルを検出し、すでに受信したメッセージの一部を破棄します。このように、ネットワークのすべてのサブスクライバーに一貫したデータセットが確保されます。
ある送信ノードがエラーフレームを送信または受信すると、追加のバスアービトレーションによってすぐにその前に送信したメッセージを再び送信しようとします。
エラーシグナル送信のメカニズムは、メッセージ交換が正確かつネットワークで動いているすべてのサブスクライバーと確実に一致させることができます。
エラーシグナルの送信は、エラーが検出された後すぐ行われるため、非常に短時間でエラーから回復することが保証されます。エラーが検出された時にのみバスが追加で占有されるということは、Acknowledging メソッドに比べ追加のバス負荷がかなり低いという利点があります。

 

上位層プロトコル

ISO 11898 規格で定められている上述の CAN プロトコルは、データ通信の OSI モデルのレイヤー1/2 に対応します。しかしながら、ネットワークの実現にはさらなる機能が必要になります。
組み込みシステムや産業オートメーションのアプリケーションには、CANopen と DeviceNet の 2 つの規格があります。CANopen は組み込みネットワークのアプリケーションにおいて主要な規格であり、DeviceNet は主に産業オートメーションの分野で使用されています。商用車の分野では、SAE J1939 も使用されています。