CANネットワークとCANopenスタックの使用

かつて、最大の信頼性でノード間でデータを送信できる組み込みシステムを開発するという課題に直面しました。 それから私は最初にCANについて学びました。



この記事では、CANとは何か、それを使った私の経験について簡単に説明したいと思います。 おそらく、私の記事を読んだ後、組み込みシステムを開発している人々は、この標準がまだ自分の見解になっていないなら、この標準に興味を持つでしょう。 さらに、CANコントローラーは現在多くのマイクロコントローラーに搭載されています。



CAN（Controller Area Network）は、自動化および産業で使用されるネットワーク用にBoschが作成した標準です。 この規格は、工業生産、スマートホームテクノロジー、および自動車産業で幅広く応用されています。 さまざまなセンサーと制御デバイスを単一のネットワークに接続するのに非常に適しています。

原則として、CANネットワークは、すべてのノードがデータを送受信できるバス型ネットワークです。

低速ですが、高い信頼性があります。



次に、標準を表面的に説明し、そのようなネットワークの実際の使用について説明します。

標準

この規格では、リンク層と物理層の基本要件について説明しています。

物理レベルでの主なことは、ビットが「 支配的 」および「 劣勢 」として送信されるための要件です。 支配的な信号は単一であると見なされ、劣性の信号はゼロと見なされます。 主な要件は、支配的な信号と劣勢な信号を同時に送信する場合、すべてのノードが支配的な信号を受信する必要があることです。 調停メカニズムはこの原則に基づいています。 したがって、伝送にはさまざまなメディアを使用できますが、実際には、差動ペアが最も頻繁に使用されます。



ネットワーク伝送はフレーム単位で発生します。 標準には、基本と高度の2種類のフレームがあります。

基本フレームには11ビットの識別子が含まれ、拡張フレームには29ビットが含まれます。 フレームには、送信要求ビット、送信されたデータの長さに関する情報、およびデータ自体も含まれます。 フレームごとに0〜8バイトを占有できます。 フレームには補助情報も含まれていますが、プログラマーにとっては重要ではありません。その追加はネットワークコントローラーのハードウェアに実装されているためです。

最初は、識別子はどのノードにも結び付けられておらず、送信者と受信者ではなくメッセージを特徴づけます。 識別子は、メッセージの優先度も示します。 優先度は、識別子のドミナントビットによって決定されます。 したがって、10000000000は01000000000よりも優先されます。



CANの主な利点は、その信頼性です。 イーサネットでの衝突検出メカニズムとは対照的に、衝突解決メカニズムを使用します。これにより、衝突によって帯域幅を失うことがなくなります。

その本質は、各ノードがネットワークをリッスンし、空いていれば転送を開始できるという事実にあります。 同時に、彼はネットワークを聞き続けています。 劣性ビットを送信するときに、支配的なビットが受信されると、優先度の高い別のノードが同時に送信を開始します。 この場合、送信は終了します。



さらに、伝送制御、パディングビット、チェックサムの使用、フィールド値のチェックなどのエラー検出メカニズムが使用されます。 開発者は、伝送エラーの検出に失敗する確率を4.7×10-11と見積もっています。



この標準はトップレベルのプロトコルを記述していないため、商用とオープンの両方でいくつかの実装が作成されています。

それらの中で最も有名なもの：

-CANopen

-DeviceNet

-CANキングダム



この標準に関するさらに詳細な情報はインターネットで簡単に見つけることができるので、ついにCANopenの説明に取りかかります。

CANopen

すでに書いたように、マイクロコントローラーの信頼できるネットワークを作成する必要があったとき。 オプションを検討した後、CANネットワークにとどまることが決定されました。 CANopenはトップレベルのプロトコルとその実装として選択されました。CANopenNodeはオープンであり、必要なデバイスに簡単に移植できるためです。 CANopenNodeはLGPLでライセンスされています。



CANopenプロトコルのハイライト：

-プロトコルは標準識別子で動作します。 ネットワークには最大127個のノードを含めることができます。

-各ノードには一意のネットワーク番号が割り当てられます。

-プロトコルは、ネットワークマスターの存在を必要としません（ただし、ネットワーク内の1つのノードでのみ使用可能な機能があり、条件付きでマスターと呼ぶことができます）

-OD（オブジェクト辞書）-オブジェクトの辞書。 SDOを使用してネットワーク経由でアクセスできる変数のソートされたリストが含まれています。

-SDO（Service Data Objects）-オブジェクトの辞書にアクセスするためのメカニズム。 ネットワークノードのオブジェクトにアクセスするには、このノードでいわゆるSDOサーバーが実行されている必要があります。 通常、マスターと呼ばれるSDOクライアントはネットワーク上に1つしか存在できず、どのサーバーからでもデータを受信できます。

-PDO（プロセスデータオブジェクト）-ノード間の迅速な相互作用のためのオブジェクト。 最大8バイトのデータを含めることができ、1つのフレームで送信されます。 各PDOには、独自の識別子が（特定の範囲で）割り当てられます。 PDOは、条件付きで着信（RPDO）と発信（TPDO）に分けられます。 最初は、各ノードに4つのRPDOと4つのTPDOがあると想定されていますが、1つのノードが最大512のPDOを送受信できるようになるまで、ノード間で再配布できます。 ただし、この場合、他のノードに十分な識別子がありません。

PDOは、特定のイベントの発生時にタイマーによって、または制御プログラムからの送信の直接要求によって送信できます。

-NMT（ネットワーク管理）-ネットワークマネージャー。 このタイプのメッセージは、ノードをさまざまな状態（初期化、動作中、事前動作中、停止）に変換することができ、ネットワーク動作（ハートビートメカニズム）の監視にも役立ちます。

-ハートビート-ハートビートとして変換されます。 このメカニズムの本質は、各ノードが各ノードに固有の特定のメッセージをネットワークに送信することです（IDは、ネットワーク内のノード番号を特定の番号に追加することによって取得されます）。 特定のIDを持つノードがまだアクセス可能であるかどうかを知りたいノードは、これらのメッセージを受信して​​処理するだけです。 興味のないノードからのメッセージは無視できます。

-緊急メッセージ-プロトコルは、緊急メッセージの送信を提供します。

-EDS（電子データシート）-オブジェクトの辞書をカスタマイズできる特別なテキストファイル。 そのようなファイルの生成に役立つプログラムがあります。

CANopenNode

CANopenNodeは、マイクロコントローラで使用するために純粋なCで記述されたCANopenプロトコルのオープン実装です。



次に、CANopenNodeを使用する際に直面しなければならなかった機能について説明します。

1. 32ビットコントローラーを使用し、CANopenNodeは元々8/16ビット用に作成されました。 このため、オーバーフローが発生し、結果としてゼロにリセットされるのではなく、1つの場所でタイマーが異常終了しました。これは、タイマーが大きくなり続け、すべてのノードが新しいハートビートの待機時間を超えるというエラーがハートビートメカニズムで発生したためです。

2.私の仕事は、大量のデータを転送できるようにすることでした。 同時に、複数のコントローラーがこのデータを送信し、残りがそれを受信する可能性があります。 SDOメカニズムを放棄し（8バイトを超えるデータを送信できるのは1つのコントローラーのみであるため）、制御情報の形式でPDOの最初の2バイトを使用する独自のアドインを作成する必要がありました。

3.パラグラフ2からの解決策は、対話の参加者を一意に識別する必要があるという事実につながりました。これは、識別子を使用してのみ実行できます。

それは、おそらく、仕事の中で最も薄い瞬間でした。 「マスター」の数を4人に制限することが決定されました。 これらの4つのノードは、入力および出力用に127個のPDOを受け取りました。 残りのノードは、4つのインバウンドおよびアウトバウンドPDOで機能しました。 さらに、PDO識別子は、「スレーブ」ノードが1つの発信メッセージを持ち、それぞれが特定の「マスター」と各「マスター」から1つの着信メッセージのみを読み取るように配布されました。 マスターはそれぞれ、「フォロワー」のいずれかに個人的に連絡するための1つのチャネルを持ち、それらのどれが彼に連絡しているかを正確に知っていました。

CANを使用する人々のフォーラムでさえ、CANopenをこのように構成できないという認識があるため、この概念は最も困難でした。

4.このプロトコルの識別子の設定は、コード内で行われます。 さらに、特定のノードによって読み取りおよび受信されるノードのIDは、それに依存します。 したがって、外出先でIDを変更することは、このプロトコルでは困難に思え、追加の作業が必要です。

結論の形で

最終的に、このプロトコルは自分のタスクにうまく適合せず、独自の実装を作成する必要があるという結論に達しました。 ただし、このプロトコルの理解に費やした時間の間に、CANネットワークと連携する原理をはるかによく理解しました。 信頼性の高い配信を最大限に活用する動作中のアプリケーションをすばやく入手する必要がある場合、アプリケーションを既存の多くのシステムと互換性が必要な場合、CANネットワークをデバッグするための既製のツールが必要な場合は、CANopenが非常に適しています。



どんな質問にも答えて、批判や追加を受け入れます。そして、誰かが興味を持っているなら、私はいくつかのポイントをより詳細に掘り下げることができます。

ご清聴ありがとうございました！

いくつかのCAN関連リソースへのリンク

www.can - cia.org- （英語）国際機関CAN in Automation。

sourceforge.net/projects/canopennode- （英語）CANopenNodeプロジェクト



UPD：

私は別の興味深い点を付け加えるのを忘れていました。 直接接続した2つのコントローラーでネットワークをデバッグしました。

1.コントローラーの1つをフラッシュすると、2番目のネットワークでエラーが発生し始めました（電球が頻繁に点滅し始めました-CANopenスタックで定義された動作）。 コントローラの通常の再起動中に、これは発生しませんでした。 おそらくこれは特定のコントローラーの特異性ですが、念のため、覚えておく価値があります。

2. CANopenプロトコルは、特定のIDを持つメッセージが再送信される前に送信されなかった場合、エラーも発生するように設計されています。 さらに、各ホストは毎秒ハートビートメッセージを送信します。 したがって、何も送信しなくても、ネットワークエラーが発生する可能性があります。