🔌

第2回：EtherNet/IP を WebAPI のモデルで理解する（フィールドネットワークをソフトウェア視点で整理する）

に公開
Network
Web API
PLC
EtherNet/IP
cip
tech

第2回：EtherNet/IP を WebAPI のモデルで理解する

（フィールドネットワークをソフトウェア視点で整理する）

はじめに

この記事は「ソフトウェアエンジニアがフィールドネットワークを理解する」シリーズの第2回です。
第1回では、私自身がアプリケーションエンジニアとして工場ネットワークに向き合う中で必要だった背景や考え方を整理しました。

本記事では、EtherNet/IP を WebAPI の概念になぞらえて理解するための技術的整理 を行います。
メーカー資料は設定中心で概念的説明が少ないため、構造が把握しづらいという課題があります。
そのため、ソフトウェアエンジニアの視点から、EtherNet/IP の各要素を WebAPI の概念にマッピングして整理します。

WebAPI ⇔ EtherNet/IP の対応表

EtherNet/IP を WebAPI の構造に置き換えて理解すると、
どこに何が対応しているかが一気に見通しやすくなります。

WebAPI の概念 内容 EtherNet/IP の対応 説明 種類
エンドポイント /device/10/status CIP Path（Class/Instance/Attribute） データ位置 URI
ルート /api/v1 Connection Point（Assembly 番号） Implicitの入口 URI
名前付きアクセス tank/level タグ通信 名前でアクセスできる上位API URI
ID直指定 /id/0x04/100/3 インスタンスID通信 数値で手動指定 URI
HTTPメソッド GET / POST CIP Service（0x0E/0x10/0x01…） 操作の種類 URI
API解決 Router / Resolver タグResolver / EDS CIP Path 解決 URI
REST通信 同期 GET/POST Explicit（Class3） 単発要求 通信
WebSocket通信 ストリーミング Implicit（Class0/1） 周期 I/O 通信
JSON / Schema 型定義 タグ / STRUCT / Assembly データ構造 データ構造

1. URI（エンドポイント）としての EtherNet/IP

1.1 CIP Path は「データの住所」

WebAPI のエンドポイント：

/device/10/status

EtherNet/IP（CIP）では：

Class    = 0x0F
Instance = 10
Attribute= 3

CIP Path = Class / Instance / Attribute の組み合わせでデータを特定する URI

1.2 Connection Point（Assembly）は “ルートエンドポイント”

Implicit（周期 I/O）通信では、通信開始時に
Assembly 番号（例：100,150,1） を指定します。

これは WebAPI の /api/v1 のような
ルートの入口 に相当します。

※ タグ通信では自動設定されるため通常は意識しません。

1.3 タグ通信 = 名前ベースのAPI

Tank.Level
Motor.Start

このように“タグ名”を指定するだけでデータへアクセスできます。

内部では：

タグ名 → CIP Path（Class/Instance/Attr）

へ自動で変換されています。

アプリ側からは、変数名だけでアクセスできる“名前ベースのAPI”のように扱えます。

1.4 インスタンスID通信 = 低レイヤ REST

こちらは自分で数値IDを明示的に指定する方式です。

Class = 0x04
Instance = 100
Attribute = 3

WebAPI で言えば：

/internal/4/100/3

のように 低レイヤの REST API を直接叩く 感覚に近いです。

1.5 CIP Service = HTTPメソッド

HTTP CIP 意味
GET 0x0E 単一属性の取得
POST/PUT 0x10 単一属性の書込み
GET ALL 0x01 複数属性の取得
BATCH 0x32 一括呼出し

1.6 EDS / Resolver = API仕様書とルーター

  • タグ通信：CPU が CIP Path を自動解決
  • インスタンスID通信：EDS（Electronic Data Sheet）が仕様書
  • Assembly の構造も EDS に記述されています

Swagger/OpenAPI ドキュメントのような役割です。

2. 通信方式（REST と WebSocket）

2.1 Explicit（Class3） = REST API

  • 単発の GET/SET
  • タグ通信の内部でも利用される
  • 設定値・状態確認向け

REST API とほぼ同じ構造です。

2.2 Implicit（Class0/1） = WebSocket（ストリーミング）

  • RPI（周期）でデータを PUSH
  • 高速（1〜10ms）更新
  • Connection Point が入口
  • Assembly をバイト列で送受信

WebSocket のストリーミング通信に非常に近い方式です。

3. データ構造（JSON / Schema）

EtherNet/IP で扱うデータ構造：

  • タグ（Tag）
  • STRUCT（構造体）
  • 配列（Array）
  • Assembly（I/O用構造体）

WebAPI における JSON / Schema に相当します。

Explicit では属性単位で読み書きし、
Implicit では Assembly（構造体）がバイト列としてやり取りされます。

まとめ

EtherNet/IP の本質は「WebAPI と同じ構造」です。

  • URI = CIP Path
  • ルート = Connection Point
  • 名前付き = タグ通信
  • ID指定 = インスタンスID通信
  • メソッド = CIP Service
  • REST = Explicit
  • WebSocket = Implicit
  • JSON = Assembly / STRUCT

このように対応づけることで、
ソフトウェアエンジニアでも EtherNet/IP の概念を直感的に理解できます。

シリーズの続きでは、他のフィールドネットワークについても
同じモデルで整理していく予定です。

Discussion