😺

IOT層と通信プロトコル、PLC動向について

2024/02/14に公開

筆者は何者?

  • 製造業で働く生産技術のエンジニアです

  • 国内外で新規号口ラインの立ち上げ経験(企画、購買、生産準備、LO)があります

  • Go,Pythonが書ける

  • サーバー・ネットワーク構築、生産設備の制御、NCプログラムなどが好きです

IOT層と求められる応答速度について

ネット上にはIOTに関して色々な記事が散見されますが、
中にいる人間としてまとめてみたくなったので書いてみます

特にIOT層別に求められる応答速度や通信プロトコルの選択肢について
新しく工場を建てるなら現在のベストプラクティスは何か? を身勝手に語りたいと思います

※工場ネットワークやIOTには正解はありません。あくまで個人の感想です

IOT層とは

工場IOTでは、↓のような構成で表現されることが多いです

※諸説ありますが、通信プロトコルの視点で見ればこの4つの分離で問題ないでしょう

※CloudはGCPの絵が書いてありますが、私が使っているだけで特に意味はないです

※通信はアプリケーション層のプロトコルを示しています

  • L1:デバイスレベル

主にPLCとPLC配下のデバイス群との通信で使われる層です

求められる応答速度:数ms~数百ms

データの送信量/msg:基本は 数bit

死活停止:必須
※通信相手先が死んでいたら自分が確実に異常で止まる必要があるかどうか

プロトコル:Modbus,Profinet,CC-Link,DeviceNet,IO-Link,EtherCat,IO など

個人的に好き:EtherCat

  • L2:マシンレベル

主にPLCとPLC間の通信で使われる層です

求められる応答速度:数百ms程度が一般的

データの送信量/msg:数bit~数百kbytes

死活停止:必須

プロトコル: FL-NET,EtherCat,EtherNet/IP,EtherNet など

個人的に好き:EthernetIP

  • L3:サーバーレベル

主にサーバー間、建屋間などの通信で使われる層です

求められる応答速度:製造業としては10秒以内くらいであれば問題ない

データの送信量/msg:数百kbytes ~ 数Mbytes

死活停止:不要

プロトコル: HTTP,HTTPS,MQTT,FTP,SFTP など

個人的に好き:MQTT,SFTP

  • L4:インターネットレベル

クラウドの世界、Webの世界、読者層が一番馴染みがある?層です

求められる応答速度:製造業としては10秒以内くらいであれば問題ない

データの送信量/msg:数百kbytes ~ 数Mbytes

死活停止:不要

プロトコル: 目的による

おすすめ:目的によるが、組織的にPubSubモデルを使うべきかと思います

  • IOT層まとめ
求められる応答速度 データの送信量/msg 死活停止 プロトコル
L1 数ms~数百ms bit 必須 Modbus,Profinet,CC-Link,DeviceNet,IO-Link,EtherCat,IO
L2 数百ms程度 bit~数百kbytes 必須 FL-NET,EtherCat,EtherNet/IP,EtherNet
L3 10秒以内 数百kbytes ~ 数Mbytes 不要 HTTP,HTTPS,MQTT,FTP,SFTP
L4 10秒以内 数百kbytes ~ 数Mbytes 不要 目的による

ITとOT

↑で述べたIOT層は、OT(Operational Technology)とIT(Information Technology)に大別できます

OT:L1,L2

IT:L3,L4

ITは、一般的なWebの世界と同じ考えが適用できます

OTは、製造業特有、製造業でも業界や慣習の違いによって要求が異なります。

OTは「通信相手のデバイスが死んでいたら自分の装置は確実に異常で止まる必要がある」という特性があります

ITはむしろ相手が死んでいても自分は動いていてくれた方がいい場合が多いです

そのためEtherNet/IPやEtherCatなどのプロトコルでは、死活監視が標準でサポートされています

工場運営とITとOTの溝

さてDX戦略を進める上で、IT層とOT層の融合が必ず必要になってきます
IT層は、技術進化も早く、選択肢も多いです。OT層も独自の進化を遂げてきており、選択肢がなくて困るということはないでしょう

課題はIT層とOT層の融合です

OPC-UAなどの統一規格は生まれてはいますが、windo*sに媚びているような感じがしてどうも好きになれません

また、特定の会社名を出すのは控えますが、デバイスメーカーが提供するIOTデバイス商品(色んなPLCと接続できます!色んなプロトコルに対応してます!という商品)は、
同時接続台数が数十台程度で、大規模な工場ではこれらデバイスを大量に導入することでL2層が複雑化・サイロ化します

ただでさえ工場は装置のメンテで精一杯なのに通信網が複雑になった生産ラインでは、生産性が上がることはないでしょう。

工場のシステム運営では

  • 通信網はシンプル
  • デバイス、PLCを一元管理
  • ビッグデータなどのデータはできるだけクラウド

などを満たすようにシステム構築することが求められます

PLCのニーズの変化

上記の要望を満たしたいとなると、PLCの役割が大きくなります

PLCは唯一OT層とIT層の両方に属する装置だからです
近年、各社のPLCはIT層へのデータ連携方法が増えてきております。
この流れに乗れないPLCは次世代で選ばれることはないでしょう。

通信網をシンプルにするためにPLCが自立的に発信し、IT側のデータをセキュアに受信することが求められます。
PLCを選ぶ基準をまとめると個人的にはこんな感じになります

  • OT層の主要プロトコルをサポートしていること
  • http,mqtt,ftp,sftpなどのIT層のプロトコルをサポートしていること
  • IT層のライブラリが各言語別で公開されていること
  • PLC側のIT層とのインターフェースが公開されており、サーバー側から一元管理できること
  • PLC側から自律的にデータ送信できること(httpならpost、mqttならpublishなど)

これを書いた時点では、まだどのPLCも満たしていないです

まとめ

  • IOT層と通信プロトコルの世界について、要件と選択肢をまとめました

  • ITとOT層の融合が課題

  • PLCの役割が非常に重要

GitHubで編集を提案

Discussion