「CANのWindowsソフトウェアへの導入」

今までのWindowsアプリ開発の中で、お客様の要望によりCAN通信機能を具備することになった案件がありました。開発期間は2006年2月〜2006年8月で、ある状態監視装置へ設定データを作成しダウンロードするWindowsアプリケーションの案件でした。自分はその時にCANを全く知らなかった為に、「CANとは何？」から勉強することになりました。 CANとはとてもユニークな調停という仕掛けを持っているプロトコルです。 簡単ではありますが、CANについて概要を御紹介させて頂きたいと思います。

CAN（キャン） というのは「Controller Area Network」の略です。車載ネットワークを構築する目的に開発されたシリアル通信プロトコルで、ドイツのBOSCH（ボッシュ）という会社で開発されました。 現在では車の制御だけではなく、船舶、鉄道車両、工場、工作機械、医療器械、エレベータの制御にも使用されています。また、FAでよく使用されている「DeviceNet」もCANから発展したものです。

CANはバス接続であり、1つのバス上に複数の端末が接続します。バス接続である為、どれか1つの端末が送信を行うと全部の端末が受信を行いますが、自身に関係のないメッセージは無視します。CANには次のような優れた特徴があります。

（1）. 配線が簡単であり、低コストで済む。

（2）. 伝送の信頼性が高い。

（3）. 端末の追加・削除が容易である。

（4）. 送信の衝突検出機能がある。（調停）

CANのデータ伝送フレームの中には、Arbitration field（アービトレーションフィールド）と呼ばれる調停の際の判定に用いられる部分があります。（12ビットまたは32ビットで構成されます）このアービトレーションフィールドの送信の時に、送信したデータがバス上にきちんと出ているかを1ビットずつ端末が自ら監視しながら、送信の可不可を判定します。

表1. 衝突時の調停

上記の表は端末Aと端末Bが同時に送信を開始して、アービトレーションフィールドをバス上に送信した場合の動きを示しています。
ちなみに、バス上で信号線の電位差がない場合の状態レセシブといい論理上（1）を表し、バス上で信号線の電位差がある場合の状態をドミナントといい論理上（0）を表します。どちらの端末も1ビット送信する度にバス上に自分が送信したデータが出ているか再確認しながら、送信を続けます。

上記では4ビット目までは、どちらも異常を検知することなく送信を続けています。
5ビット目になると端末Aはドミナント出力を行い、端末Ｂはレセシブ出力を行いますが、ここでどちらが出力を続けるか優先が決まります。
ドミナント出力とレセシブ出力では、ドミナント出力の方がバス上に出力されます。
端末Bは自分がレセシブ出力を行ったにも関わらず、バス上にドミナント出力がされていることを知ると以降は常にレセシブ出力を行って、再送のタイミングを待つようになります。アービトレーションフィールド12ビットが0に近いものが、伝送上優先されます。

CAN通信用のカードは各メーカよりいろいろな製品が発売されていますが、今回使用した製品はInterface（インターフェース）社のCSI-485220というPCカードです。
開発したソフトウェアの概要は「ターゲットの状態監視装置とCAN通信を行って設定内容をアップロードしたりダウンロードしたり、編集などを行うシステム」です。
ノートパソコンでの運用を前提としているので、PCカードで通信します。

ドライバは製品付属のものを使用しましたので、CAN通信自体の導入はさほど困難ではありませんが、通信時間の短縮には工夫が必要でした。
設定データは2メガバイト以上の容量があり、ダウンロード・アップロードの時間を短縮する為に、データ圧縮を行って通信量を減らしています。データ圧縮はデータの初期化コード（0xff）が連続している場合に、送信側はその連続バイト数を送信し、受信側はその値から実データを復元する方法で行っています。

図1. システム構成

CAN通信のWindowsアプリへの導入は初めてでしたが、次のようなことを学ぶことができました。

（1）

各メーカより豊富に通信カードが出回っており、それらの使用で簡単に通信機能を実装できる。

（2）

CAN仕様自体が大変に信頼性が高く、制御システムのネットワークの構築に向いていて、各分野で使用広がっていること。

（3）

1つのデータ送信フレームで8バイトしかデータが送信できない為、大量データのやりとりを行うのにはあまり向いておらず、データの圧縮などの工夫が必要。