スピンオフ：CANを「自立分散イベントバス」として理解する（アプリエンジニア向けフィールドネットワーク入門）
スピンオフ：CANを「自立分散イベントバス」として理解する
（ソフトウェアエンジニア向けフィールドネットワーク入門）
本記事は
「ソフトウェアエンジニアがフィールドネットワークを理解する」スピンオフです。
シリーズ全体は記事末尾のリンク一覧から参照できます。
はじめに
第3回で DeviceNet を扱った際、
- アドレス共有がない
- I/O ピンのような使い方になる
- 設定項目が極端に少ない
といった特徴がありました。
その背景にあるのが、
CAN（Controller Area Network） という通信方式です。
本記事では、
CAN を厳密な規格解説としてではなく、
「こういうものだろう」
と理解するための整理
としてまとめています。
CANを一言で言うと
自分なりに整理すると、
CAN は次のような仕組みだと理解しています。
CANは、
中央の調停者を持たず、
各ノードが対等な立場で
イベントを投げ合う
自立分散型のメッセージバス
通信というより、
システム全体で共有されたイベントループ
に近い印象です。
マルチキャスト通信との違い
最初は、
CAN はマルチキャスト通信に近いのでは？
と感じました。
一般的なマルチキャスト通信
- ルータやスイッチが
「誰がどのグループを購読しているか」
を管理する - 必要なノードにだけ配信される
CANの場合
- 配信を管理する装置が存在しない
- すべてのメッセージが
全ノードに届く - 各ノードが
IDを見て処理するかを判断する
つまり CAN では、
「欲しいかどうかは
ノード自身が決める」
という設計になっています。
CAN IDは「宛先」ではなく「意味」
CAN フレームにはIP アドレスのような 宛先情報 が存在しません。
あるのは CAN ID だけです。
この ID は、
- 誰に送るか
ではなく - 何の情報か
- どれくらい重要か（優先度）
を表しているように見えます。
そのため、
CAN ID = イベントの種類
と考えると理解しやすいです。
EtherNet/IP のインスタンス ID との近さ
この「ID が意味を持つ」という考え方は、
EtherNet/IP を触ったことがある人なら
少し見覚えがあるかもしれません。
EtherNet/IP では、
- 通信相手は IP アドレスで指定しますが
- 実際にやり取りする内容は
クラス / インスタンス / 属性 ID
によって識別されます。
この インスタンス ID も、
「誰に送るか」ではなく
「どのデータ・どの機能か」
を表す識別子です。
その意味では、
CAN ID は
EtherNet/IP における
インスタンス ID に近い役割
を持っていると考えることができます。
ただし、
- EtherNet/IP には
明確な宛先（IPアドレス） が存在する - CAN には
宛先の概念自体がない
という点が、両者の大きな違いです。
Windowsのイベントループに近い感覚
CAN の仕組みは、
Windows アプリケーションの
イベントループにも少し似ています。
- 何かが起きるとイベントが流れる
- すべてのイベントはいったん届く
- 各アプリ（ノード）が
自分に関係あるものだけ処理する
ただし CAN には、
- OS のような管理者
- イベント配信を制御する存在
はありません。
OS のいないイベントループ
という表現が、一番しっくり来ました。
主従関係のない自立分散システム
CAN には、
- マスター
- サーバ
- ブローカー
といった 中心的な存在 がいません。
すべてのノードが対等で、
- 必要だと思えばイベントを投げる
- 必要だと思えばイベントを拾う
という動きをします。
ただし無秩序ではなく、
- 同時に送信が起きた場合は
- ID（優先度）によって自然に順序が決まる
という共通ルールがあります。
車載CANではメーカーごとに取り決めがある
車載CANの世界では、
- インターネットのような
世界共通の取り決めがあるわけではなく - 各メーカーや車種ごとに
CAN ID とその意味が決められている
という形が一般的なようです。
「このバスに接続するなら、
この取り決めに従ってね」
という前提で、すべての ECU が設計されています。
なぜDeviceNetがI/Oっぽく見えるのか
ここまで整理すると、
- アドレス共有がない
- ビット単位で意味を持つ
- 設定が少ない
といった DeviceNet の特徴は、
CAN 由来の思想
だと理解できます。
CAN はもともと、
- 少量のデータ
- 明確な意味
- 即時性重視
のための仕組みなので、
結果として I/O バスの延長のように使われます。
ソフトウェアエンジニア向けの言い換え
ソフトウェア開発者向けに言い換えると、
- RPC ではない
- API でもない
- 共有メモリでもない
代わりに、
イベント駆動メッセージングを
極限まで単純化したバス
と捉えると、CAN はかなり理解しやすくなります。
まとめ
- CAN は中央管理者を持たない
- 全ノード対等の自立分散システム
- メッセージは全配信
- 受信するかどうかはノードが判断
- ID は「意味」と「優先度」を持つ
- EtherNet/IP のインスタンス ID と
発想が近い部分がある - DeviceNet の思想的な下地になっている
CAN を理解すると、
- DeviceNet がなぜあの形なのか
- フィールドネットワークがなぜ割り切った設計になっているのか
が、後から腑に落ちてきます。
本記事は、「厳密な定義」ではなく「理解のための整理」
として読んでもらえれば幸いです。
Discussion