産業用モノのインターネットにおけるModbusの高度なアプリケーション:エッジコンピューティング、MQTTブリッジ、クラウドプラットフォームアクセス
従来の産業オートメーションがモノのインターネット技術と出会うとModbus産業用モノのインターネット製造業のデータアーキテクチャを再構築している。1979 yearに誕生したModbusプロトコルは、シンプルでオープンで信頼性の高い機能により、今日でも産業用フィールドデバイスの相互接続のデファクトスタンダードとなっています。しかし、現場のModbusデータをクラウドに送信してインテリジェントな分析を行うには、OT(運用技術)とIT(情報技術)のギャップを埋める必要があります。本稿ではmodbus.cnシリーズの主要なchapterは、体系的に説明されます。Modbusエッジコンピューティング、Modbus MQTTプロトコルの変換とModbusクラウドプラットフォーム読者を助ける完全な技術プログラムへのアクセスIIoT Modbus着陸能力を持つ。
OTからITへ:産業用データフローアーキテクチャの進化
アーキテクチャを理解することは、産業用モノのインターネットにおけるModbusアプリケーションをマスターするための前提です。従来のプラントのデータフローは、フィールド機器層(センサ/アクチュエータ)、制御層(PLC/DCS)、監視層(SCADA/HMI)、管理層(MES)、エンタープライズ層(ERP)の5つの層にminかれています。この古典的なパデューモデルでは、Modbusプロトコルは主に最初の3層でアクティブであり、データはプロトコル変換とセマンティック変換を通じて層ごとにアップストリームされる。
産業用モノのインターネットの出現は、この層ごとの配信アーキテクチャを破壊しました。エッジコンピューティングゲートウェイを使用すると、オンサイトのModbusデータは、MQTTやその他のIoTプロトコルの形で、中間層を直接“横断”してクラウドプラットフォームに直接送信できます。このフラットアーキテクチャは、データレイテンシを大幅に低減し、データ密度を向上させ、ビッグデータ分析とAIアルゴリズムを産業シナリオに実装することを可能にします。
最新のIIoT 3層アーキテクチャ
| 階層レベル | 主な設備·システム | Communicationプロトコル | データの特徴 |
|---|---|---|---|
| エッジレイヤ | PLC、センサ、エッジゲートウェイ | Modbus RTU/TCP、OPC UA | 高周波、リアルタイム、ローカルクローズドループ |
| プラットフォームレイヤ | IoTプラットフォーム、時系列データベース、ルールエンジン | MQTT、HTTP、AMQP | 中程度の頻度、構造化、持続性 |
| アプリケーションレイヤCloud/App | BIカンバン、AIモデル、デジタルツイン | HTTPS、WebSocket、gRPC | 集約、分析、視覚化 |
この構造では、Modbusエッジコンピューティングゲートウェイは、OTの世界とITの世界の架け橋として重要な役割を果たし、Modbusデータ収集、プロトコル変換、データ前処理、安全な転送を担当します。
Modbusデータ収集の主な課題
Modbusデータを産業用モノのインターネットに接続する際、エンジニアは複数の課題に直面します。これらの課題を理解することは、適切なソリューション設計の前提です。
課題1:大量かつ分散したデータ
中規模の工場では、数百台のModbusデバイスがあり、それぞれに数十から数百のレジスタがあります。200 台のインバータを例にとると、各デバイスは10の重要なパラメータ(周波数、電流、電圧、temperature、アラームコードなど)を読み取り、各ポーリングは約30msで、フルラウンドは6 秒かかります。秒単位のデータ収集を実現するには、並列化戦略とマルチシリアルポート方式が必要です。
課題2:プロトコルの違いと異種統合
フィールドデバイスはModbusプロトコルに基づいていますが、異なるアドレスマッピング、異なるバイトエンディアン、異なるデータフォーマット(整数/浮動小数点/BCDコード)など、ベンダーによって実装に違いがあります。これらの違いは、手動設定では個別に対処できますが、大規模なIIoT展開では自動化され標準化された設定管理で対処する必要があります。
課題3:ネットワークの信頼性
工場フロアのネットワーク環境はデータセンターよりもはるかに悪く、電磁干渉、高温、振動はすべてネットワークの安定性に影響します。Modbus RTU(RS-485)は、干渉防止能力が高いにもかかわらず、長距離マルチノードの複雑な配線では、終端抵抗マッチング、グランドループ、コモンモード干渉などの問題が依然として頻繁に発生しています。
課題4:リアルタイム性とスループットのバランス
Modbus RTUは典型的なリクエスト-レスポンスプロトコルであり、マスタは一度に1つのリクエストしか処理できません。多数のスレーブステーションのシナリオでは、ポーリングサイクルが長く、高周波データ収集のニーズを満たすことが困難です。ソリューションには、マルチシリアルポート並列、RTUの代わりにModbus TCP、エッジ側のデータキャッシュとバッチエスカレーションメカニズムの導入などがあります。
エッジコンピューティングゲートウェイの選択と展開
エッジコンピューティングゲートウェイは、産業用IoTデータアーキテクチャの最も重要なハードウェアノードです。適切なゲートウェイの選択は、システムの信頼性、スケーラビリティ、およびメンテナンスコストを直接決定します。以下は、Modbusエッジコンピューティングゲートウェイのコア選択要素。
ハードウェア仕様要件
| パラメータ | 最小要件は | 推奨設定 | 説明書は |
|---|---|---|---|
| CPU | ARM Cortex-A7シングルコア | Cortex-A72クアッドコア以上 | エッジAI推論をサポートするために必要な計算能力の向上 |
| メモリメモリ | 256MB | 1-2GB | Node-RED + MQTT Broker + Data Cacheの実行 |
| ストレージ:Storage | 4GB eMMC | 16-32GB e + SDカード拡张 | ローカルキャッシュオフデータ |
| シリアル番号 | 1×RS-485 | 2-4×RS-485(アイソレーション) | マルチバス並列収集 |
| イーサネット(イーサネット) | 1×10/100M | 2×10/100/1000M | WAN + LANの分離 |
| 4G/5G | Optionオプション | CAT4とCAT1 | リモートサイトワイヤレスアクセス |
| 動作温度は | -20°C~70°C | -40°C~85°C | 屋外/極端な条件 |
メインストリームエッジゲートウェイ製品の比較
| 製品の種類 | プラットフォームは | Modbusのサポート | MQTTサポート | シーンに適して |
|---|---|---|---|---|
| アドバンテックECU-1251 | WISE-EdgeLink | RTU/TCPデュアルモード | ネイティブサポート | 中小規模の工場 |
| MOXA UC-8100 | ThingsProパッケージ | RTU/TCPデュアルモード | 組み込みBroker | 過酷な環境 |
| タグ:AR650 | Edge Computing IEF | プロトコル·プラグインのサポート | 関数計算のサポート | エンタープライズレベルの導入 |
| Raspberry Pi + Node-RED | オープンソースビルド | node-red-contrib-modbus | mosquitto/EMQX | プロトタイプ検証/小規模 |
| IG 90 2のレビュー | Device Manager | RTU/TCPデュアルモード | 組み込みBroker | 価格の選択。 |
導入のベストプラクティス
- 現地収集の原則エッジゲートウェイをできるだけModbusデバイスの近くに配置し、RS-485バスの長さを短縮し(推奨200 m以下)、配線コストと干渉を削減します。
- 隔離保護のために:RS-485ポートは、コモンモード電圧によるゲートウェイの損傷を防ぐために光電絶縁する必要があります。複数のデバイスがバスを共有する場合は、すべてのデバイスが共有されるか、絶縁型 RS-485リピータを使用してください。
- ローカルキャッシュとブレークポイントの継続:エッジゲートウェイのローカルストレージキャッシュポリシーを設定し、クラウドプラットフォームへのネットワーク接続が中断された場合、データをローカルに一時的に保存します。ネットワーク復旧後に履歴データを自動的に転送し、データが失われないようにします。
- OTAリモートアップグレード:OTA(Over-The-Air)ファームウェアアップグレードをサポートするゲートウェイ製品を選択して、構成変更によるオンサイトOperationを回避します。
Modbus → MQTTプロトコル変換
Modbus MQTTプロトコル変換は、IIoTデータアーキテクチャ全体の最も重要な技術リンクです。Modbusはリクエスト-レスポンスのポーリングプロトコルであり、MQTTはパブリッシュ-サブスクライブベースの非同期メッセージングプロトコルです。この2つの変換は、単なるフォーマットマッピングではなく、コミュニケーションパラダイムの根本的な変化を伴います。
変換アーキテクチャ設計
// Modbus → MQTTプロトコル変換
������������� Modbus RTU/TCP Д ― ― ― ― ― ― ― ― ― ― ― ―
│ Modbusデバイス│ ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── │ │ │
PLC/センサー │ │ │ │ │ │ │
3------------------- │ ‥ ── ── ── ── ── ── ── ── ── ── ── ── ── ── ──
│ │ポールスケジューラ │ │ │ │
������������� │----------------
│ Modbusデバイス│ ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── ── │ │ │ │
インバータ/計器器│ │----------------
3------------------- │ │フォーマットコンバータ │ │ │ │
│----------------
│ │ MQTTクライアント│ │
│
3---------------------
MQTT(TCP/SSL)
▼ ▼ ▼
Д ― ― ― ― ― ― ― ― ― ― ― ―
タグMQTTブローカー │ │ │
EMQX/Mosquitto │
3---------------------
│ │ │
▼ ▼ ▼
Д ― ― ― ― ― ― ― ― ― ― ― ―
│ IoTクラウドプラットフォーム │ │ │
│データ消費者 │ │ │
3-------------------Sparkplug B仕様:産業用MQTT規格
Eclipse Sparkplug Bは、MQTT上に構築された産業用IoT通信仕様であり、産業シナリオにおける従来のMQTTのデータコンテキストの欠如に対処します。Sparkplug Bは、統一データ符号化フォーマット(Googleプロトコルバッファ)、トピック名前空間(spBv 1.0/グループID/メッセージタイプ/エッジノードID/デバイスID)、およびセッション状態管理メカニズム(誕生/死亡メッセージ)を定義しています。
Sparkplug B仕様を使用すると、Modbusデータのセマンティクスが転送中に失われることはありません。例えば、レジスタ40001の温度値単位0.1°Cは、Sparkplug Bメッセージに変换された后、完全なメタデータMetric Name Temperature、Data Type Float、Unit °C、Timestamp、およびフラグを搬送する。
コア変換ロジックの実装
// Python擬似コード:Modbus RTU → MQTTブリッジコアロジック
minimalmodbusのインポート
インポートpaho.mqtt.clientをmqttとしてインポート
JSONをインポート
輸入時間の延長
# Modbusの構成
instr = minimalmod.Instrument/dev/ttyUSB01
instrument.serial.baudrate = 96 00
instrument.serial.bytesize = 8
instrument.serial.parity = 'E'
instrument.serial.stopbits = 1
# MQTTの設定
mq_= mq.Client "modbus_gate_01"
mqtt_client.connect "mqtt-broker.local" 1883
#レジスタマッピングテーブル{アドレスTTトピック、データ変换关数}
register_map = {
0 "plant1/pump1/temperature" lambda v v / 10.0
1 "plant1/p1/ure" v
2 "plant1/p1/flow_" v
3 "plant1/p1/" lambda v v / 10.0
10 "plant1/pump1/status" lambda v v #ビット状態
}
while True
for addr topic transform in register_map.items
try
raw_value = instrument.read_register
converted = transform(raw_value)
payload = json.dumps {
value"converted
“timestamp”int time.time * 1000
quality"0 # 0=Good
})
mqtt_client.publish topic payload qos=1
exException as e
print f"Error reading register {}{e}"
time.sleep 1 #収集間隔Node-RED Modbusデータストリーム処理
Node-REDは、産業用モノのインターネットの分野で広く使用されているNode.jsベースのビジュアルデータフロープログラミングツールです。node-red-contrib-modbusノードを使用すると、コードを記述することなくModbusデータの収集、変換、配布が可能になります。以下は完全なフローの例です。
Full Flow:Modbusデータ収集→処理→ストレージ→クラウドへ
// Node-RED Flow JSON(インポートしてすぐに使用)
[
{
“id”“modbus-read”
“type”“modbus-read”、
“name”“読み取りポンプパラメータ”
“topic”“pump”、
“showStatusActivities”false
“showErrors”true
"unitid" 1
“dataType”“HoldingRegister”
“adress”0 //開始アドレス(40001に対応)
“quantity”6 //6レジスタを読み込む
“rate”1000 //1000msごとに読み取り
“rateUnit”“ms”、
“delayOnStart”true
[w][]] //データノードに接続
},
{
“id”“format”、
“type”“function”、
“name”“データの书式化と変换”
"func""//Modbusレジスタ配列を構造化オブジェクトnに変換"
+ "const data = msg.payload;n"
+ [const temperature = data0] / 10.0; // 0.1°C解像度n"
+ > const pressure = data1] / 100.0; // 0.01MPa分解能n"
+ “const flow” = data2] / 100.0; // 0.01m 3/h解像度n"
+ “const current” = data3] / 10.0; // 0.1A解像度n"
+ “const alarm” (データ4); //アラームコードn"
+ const runtime " (データ5); //実行時間時間nn"
+ "msg.payload = {n"
+ " device 'pump_01' n"
+ " timestamp Date.now n"
+ " metrics {n}
+ " temperature n"
+ " pressure pressure n"
+ " flow flow、n"
+ " current current n"
+ " alarm alarm n"
+ " runtime runtimen"
+ " “N”
+ “N”とは
+ “return msg;”
“outputs”1
[w "" al-check "、"mqtt-out"、" influx-out "]]
},
{
“id”“al-check”
“type”“function”、
“name”“アラーム判断”、
"func""const alarm = msg.payload.metrics.alarm;n"
+ "if al!== 0)“N”
+ " msg.payload = {n"
+ " device msg.payload.device n"
+ " al_code aln "
+ " timestamp msg.payload.timestamp n"
+ " severity alarm10'HIGH''LOW' n '
+ " “N”です
+ " return msg;n"
+ “n”
+ "return null; //アラームがない場合は送信しない"
[wires][mqtt-alarm]]
},
{
“id”“mqtt-out”、
“type”“mqtt out”
“name”“MQTTデータエスカレーション”、
“topic”“plant/pump/data”
“qos”“1”、
“retain”“false”
“broker”“local-mqtt”
},
{
“id”“mqtt-alarm”
“type”“mqtt out”
“name”“MQTTアラームエスカレーション”
“topic”“plant/pump/al”
“qos”“2”、
“retain”“true”
“broker”“local-mqtt”
},
{
“id”“influxdb-out”、
≪ type | type | emdw ≫ ≪ influxdb out | emdw ≫
“name”“InfluxDBストレージ”
“≪ influxdb | local-influxdb | emdw ≫”
“database”“pump_metrics”
“measurement”“pump_data”
retentionPolicy autogen
}
]高パフォーマンスのポーリングポリシー
数十から数百のModbusスレーブを管理する必要がある場合、Node-REDのシリアルポーリングがパフォーマンスのボトルネックになる可能性があります。以下の最適化戦略により、ポーリング効率が3-10 倍向上します。複数のModbusリードノードを使用して異なるシリアルポートを接続して並列取得を実現します。重要度の異なるデバイスに異なるポーリング周波数を設定します(重要デバイスでは500ms、一般デバイスでは5秒)。Linkノードを使用してデータを統合処理パイプラインに集約します。データ変更検出(データ変更がデッドゾーンしきい値を超えた場合にのみ後続処理をトリガーします)を導入し、無効なデータ転送とストレージを削減します。
主流のクラウドプラットフォームアクセススキーム
ウィルはModbusクラウドプラットフォームデータアクセスは、IIoT展開の最後の1マイルです。以下は、3つの主要なIoTプラットフォームの完全なアクセススキームです。
Alibaba Cloud IoTプラットフォームアクセス
Alibaba Cloud IoTプラットフォームは、エンタープライズクラスのインスタンスとパブリックインスタンスの2つのモードを提供し、デバイス直接接続とゲートウェイプロキシの2つのアクセスモードをサポートします。Modbusデバイスは、通常、エッジゲートウェイ(Link IoT Edge)を介してアクセスされます。Link IoT EdgeにはModbusドライバが組み込まれており、デバイスモデリング、ドライバ構成、ポイントマッピングをクラウド上で行うことができ、ゼロコードのModbus Data on Cloudを実現します。
//Alibaba Cloud IoTデバイスShadow JSON(Modbusデータモデルの例)
{
“deviceName”“pump_station_01”
“productKey”“a1xxxxxxxxxx”
“”{
"pump1_temp"{
“value”42.5、
“time”168800000000
“”“modbus_40001”
“scale”0.1
“unit”“°C”
},
"pump1_pressure"{
“value”0.35
“time”168800000000
“source”“modbus_40002”
“”0.01
“unit”-“MPa”
}
}
}Huawei Cloud IoTプラットフォームへのアクセス
Huawei Cloud IoTDA(デバイスアクセスサービス)は、エッジIEFまたは組み込みプロトコルアダプタリングフレームワークを介してModbusデバイスにアクセスします。Huawei CloudのModelArts AIプラットフォームとの深い統合により、収集したModbusデータをモデルトレーニングと推論に直接使用できるようになります。IoTDAのルールエンジンを通じて、ModbusデータをDIS(データアクセスサービス)、OBS(オブジェクトストレージ)、FunctionGraph(関数コンピューティング)などの複数のHuawei Cloudサービスにリアルタイムでルーティングするためのデータフロールールを定義することができます。
ThingsBoardオープンソースプラットフォーム
ThingsBoardは最も人気のあるオープンソースIoTプラットフォームで、Community Edition、Professional Edition、Cloud Hosted Editionがあります。ThingsBoard Gatewayコンポーネントを使用すると、Modbusデバイスのデータ収集とエスカレーションをゼロコードで実現できます。Gatewayは、シリアルパラメータ、デバイススレーブアドレス、レジスタマッピング、データ変換ルールを含むJSONプロファイルを介してModbusコネクタを定義します。
{
“master”{
“sl”[
{
“host”“192.168.1.100”
“port”502
“type”“t”
“method”“socket”、
“out”35
“beOrder”“BIG”、
“wordOrder”“BIG”、
“retries”true
“retryOnty”true
“retryOnInvalid”true
“pollPeriod”5000
“unitId”1、
“deviceName”“Pump Station 01”
“sendDataOnlyOnChange”false、
[attributes"]
“timeseries”[
{
“tag”“temperature”、
“address”0
“type”“4x” //レジスタを保持する
“registerCount”1
“plier”0.1
“unit”“°C”
},
{
“tag”“pressure”、
“address”1
“type”“4x”
“registerCount”1
“plier”0.01
“unit”-“MPa”
}
]
}
]
}
}データストレージのシナリオ
Modbusデバイスは、典型的な時系列データ(高周波書き込み、タイムレンジクエリ、データ圧縮、ダウンサンプリングなどの典型的な特徴を持つタイムスタンプ付き数値のシーケンス)を生成します。適切な時系列データベースの選択は、IIoTシステムのパフォーマンスを保証するための鍵です。
InfluxDBとTDengineの比較
| プロパティ | InfluxDB | TDengine |
|---|---|---|
| 開発言語の開発 | Go | C |
| ストレージエンジン | TSMツリーの開発 | 自己学習型ストレージ |
| 書き込みパフォーマンス | ミディアム·ミディアム | 非常に高い10x+ InfluxDB |
| クエリ·パフォーマンス{{くえりぱふぉーまんす}} | よしよし。 | 優秀(スーパーテーブル最適化) |
| 圧縮率は | 5-10x | 10-20x |
| SQL互換性{{SQLごかんせい}} | SQLクラス(InfluxQL/Flux) | 標準SQL拡張{{ひょうじゅんSQLかくちょう}} |
| クラスターサポート | 有料版のサポート | オープンソースサポート |
| コミュニティ活動のレベル | 非常にアクティブ。 | 急速な成長 |
| ローカリゼーション | いいえ、いいえ | はい(国内代替案) |
| 100,000ポイント/秒 | より高い。 | 低いです。 |
TDengineスーパーテーブルの設計例
--スーパーテーブルの作成:1つのポンプステーションは1つのサブテーブルに対応し、統一スキーマ管理を行う
CREATE STABLE pump_metrics
TSは TIMESTAMP
temperature FLOAT
pressureより FLOAT
flow_rate FLOAT
現在の状況 FLOAT
パワーパワー FLOAT、
alarm_code INT
TAGS
station_id INT、
pump_id INT、
Location(ロケーション) BINARY 64
rated_FLOAT
);
--サブテーブルの作成(デバイスごとに1つ)
CREATE TABLE pump_s01_p01 USING pump_metrics
TAGS 1、1、'1番ポンプ-1番ポンプ'、37.0;
CREATE TABLE pump_s01_p02 USING pump_metrics
TAGS 1、2、'1番ポンプ-2番ポンプ'、55.0;
--お問い合わせ:No.1ポンプ場のtemperatureが45°Cを超えるポンプ
SELECT station_id pump_id temperature ts
pump_metricsより
temperature45.0の場所
station_id = 1
AND TS = NOW-1 h;
ダウンサンプリング:直近24時間の5分ごとの平均温度
SELECT AVG temperature、AVG pressure
pump_metricsより
WHERE TS = NOW-24 h
INTERVAL 5m;エッジAI:Modbusデータの異常検出
インダストリアルIoTの究極の価値は、データ収集と監視だけでなく、データに基づくインテリジェントな意思決定にもあります。エッジ側に軽量AIモデルを展開することで、Modbusデータのリアルタイム異常検出を可能にし、“事後警報”から“事前警報”への飛躍を実現します。
統計的手法:3σ原理とスライドウィンドウ
異常検出の最も単純な方法は、統計的原理に基づいています。安定したデータ(一定速度で動作するポンプ電流など)については、3σ原理(ライダ基準)を使用して明らかな外れ値を検出することができます。具体的な実装は、スライドウィンドウ(例えば、最近の100データポイント)を維持し、ウィンドウ内のデータの平均と標準偏差を計算し、新しいデータポイントが平均から標準偏差の3 倍以上逸脱した場合に異常と判断することです。
// Pythonスライディングウィンドウ+ 3σ異常検出エッジゲートウェイローカル実行
NumpyをNPとしてインポート
コレクションからのインポートdeque
class AnomalyDetector
def__init__self window_size =100 sigma=3.0
self.= deque =_size
sigma = sigma
def check self value
self..append value
if len self.window threshold_upper or value threshold_lower
return is_anomaly {
'mean' mean 'std' std
'upper' threshold_upper
'lowerth_l
}
# 使用例:Modbusが読み取った温度値の監視
_detector = AnomalyDetector
vibration_detector = AnomalyDetector_size=100、ma =4.0ルールに基づく複合判断
単纯な値検出はを生じ易い。より実用的な方法は、複数のModbusデータポイントを組み合わせて複合判断を行うことです。例えば、ポンプ軸受故障の初期の特徴は、“振動増加+ 温度上昇+電流増加”の3つが同時に発生することです。この多次元共同判定は誤検出率を大幅に低減できる。
セキュリティアーキテクチャ設計
産業用モノのインターネットのセキュリティ問題は無視できません。Modbusプロトコル自体にはセキュリティメカニズムがありません。認証、データ暗号化、整合性チェック(CRCのみ:改ざん防止)はありません。IIoTアーキテクチャでは、プロトコル自体の欠点を多層セキュリティメカニズムで補う必要があります。
4層防衛モデル
| 階層レベル | セキュリティ対策 | 説明書は |
|---|---|---|
| 物理的分離層 | ネットワークゲート、一方向絶縁装置 | OTとITネットワークの物理的分離 |
| ネットワークトランスポート層 | TLS 1.3、IPSec VPN | MQTT CommunicationTLS暗号化の強制 |
| 認証レイヤー | X.50 9証明書とTocken認証 | 偽造防止のためのデバイス双方向認証 |
| 監査層の適用 | 運用ログ、トラフィック監査 | 全リンクが追跡可能 |
MQTT TLS暗号化設定
// EMQX Broker設定:TLS +クライアント証明書認証を有効にする
listeners.ssl.default {
bind = "0.0.0.0 8883"
ssl_{
keyfile = "/etc/emqx/ts/server.key"
certfile = "/etc/emqx/certsserver.crt"
cacertfile = "/etc/emqx/certs.crt"
verify = verify_peer #クライアント书
fail_if_no_peer_cert = true
ver = tlsv1.3 tlsv1.2]
サイファー ==[
“TLS_AES_256_GCM_SHA384”
“TLS_AES_128_GCM_SHA256”
“ECDHE-ECDSA-AES256-GCM-SHA384”
]
}
}
//Edge Gateway MQTT TLSクライアントの設定
mqtt_client.tls_set
ca_certs ="/etc/gateway/certs/ca.crt"
certfile="/etc/gateway/certsclient.crt"
keyfile="/etc/gateway/ts/.key"
cert_reqs= ssl.CERT_IRED
tls_version= ssl.PROTOCOL_1_3
)
mqtt_client.connect "mqtt-broker.local" 8883実用例:ポンプステーションの遠隔監視システム
以下は本物です。ポンプステーションの遠隔監視システム完全なアーキテクチャケースは、Modbus産業用モノのインターネット技術のフルスタック着陸を示しています。
プロジェクトの背景と要件
- カバレッジ:水道会社に属する12の分散ポンプステーション、最大距離80 km
- 設備の種類:各ステーションに2-4 台のポンプ(インバータを含む)、流量計、圧力トランスミッタ、レベル計
- プロトコル:すべてのデバイスはModbus RTU(RS-48 5)、ユニファイドボーレート96 00でCommunicationします。
- 取得周波数:クリティカルデータ(周波数、電流、圧力)1 Hz、セカンダリデータ(積算量、temperature)0.1 Hz
- 核心需要:远隔リアルタイム監視、履歴データ照会、異常警報、運行保守報告書、モバイル端末アクセス
システムアーキテクチャ設計
//ポンプステーションの遠隔監視システムアーキテクチャ
ポンプ駅サイト(12个所)
�������������
│ PLC(デルタDVP)∧ ― ― RS-485 ― ― ►インバータ│
│ │ │ │-------RS-485-►流量計│
│ │ │ ●---------RS-485-►圧力トランスミッタ
│ │ │ │---------------------------------------------------------------------------------------------------------------------------20 mA--------------------------------------------------------------------------------------------------------------------------
│ │ │ ▼ ▼ ▼ │ │ │
アドバンテックECU-1251エッジゲートウェイ │ │ │
Modbusマルチステーションポーリング │ │ │
Node-REDデータの前処理 │ │ │
ローカル7日間のデータキャッシュ │ │ │
→ → MQTT(TLS)→クラウドプラットフォーム │ │ │
│ 4G無線通信 │ │ │
└──────────────────────────────────────┘
クラウドプラットフォームレイヤHuawei Cloud
�������������
IoTDA-► Kafka-► Flinkフロー計算 │ │ │
│ │ │ TDengineストレージに対応
│ │ │ アラームルールエンジンを参照。 │ │ │
│ │ │ │ │ │
│アプリケーションサービス │ │ │
Spring BootバックエンドAPIの概要 │ │ │
Vue.jsのフロントエンド監視画面 │ │ │
● ● ●小型プログラム移動 │ │ │
└──────────────────────────────────────┘主な実装ポイント
- アドレスマッピングの標準化統一されたModbusアドレスマッピング仕様を開発し、12のポンプステーションが同じレジスタ割り当て方式(40001-40010 固定ストレージ圧力、流量およびその他のコアパラメータなど)を使用して、ゲートウェイの構成とその後のメンテナンスを簡素化します。
- ネットワークの再接続メカニズム:エッジゲートウェイはローカルSQLiteデータベースを構成し、ネットワークが中断されると自動的にローカルストレージモードに切り替わり、ネットワーク復旧後にすべての履歴データを時間順に転送し、データ損失ゼロを確保します。
- 階層化された警告ポリシー:1級警報(機器停止、圧力超過)はリアルタイムで運用·保守担当者の携帯電話にプッシュされます。2級警報(高温、振動の増加)は監視画面に送信されます。3級警報(パラメータのわずかなオフセット)は傾向分析のために記録されます。
- データ品質モニタリング各Modbusデータポイントの収集成功率、通信遅延、数値妥当性を監視するデータ品質指標システムを確立し、データ品質が低下した場合に自動的に運用と保守の指示をトリガーします。
今後の動向と展望
Modbusプロトコルは40年以上の歴史がありますが、産業用モノのインターネットの時代にはまだ生きています。注目すべきテクノロジートレンドはいくつかあります。
OPC UA over Modbus
OPC UAは、インダストリー 4.0のコア通信規格であり、情報モデリング、セキュアCommunication、セマンティック相互運用性を提供します。ますます多くのデバイスがModbusとOPC UAの両方をサポートし始めている。実際のアーキテクチャでは、Modbusはフィールドデバイス層の低コスト相互接続を担当し、OPC UAは上位システムへの標準化されたデータインタフェースを提供する。エッジゲートウェイのプロトコルコンバータ(Modbus → OPC UA)が重要なコンポーネントになります。
TSNとModbus TCP(タイムセンシティブネットワーク)
TSNは、産業用イーサネットに決定論的遅延を提供するためにIEEE 80 2.1タスクグループによって定義されたイーサネット規格のセットです。TSN上のModbus TCPは、将来のリアルタイム制御シナリオの重要な技術ルートになるでしょう。TSNは、標準イーサネットの遅延不確実性を解決し、モーション制御などのリアルタイム要件の高いシナリオでModbus TCPを使用することができます。
5 G + Modbusワイヤレス
5 Gの3つの主要なシナリオ(e MBB大帯域幅、u RLLC低遅延、mMTC 大接続)では、u RLLCは産業制御のための無線可能性を提供します。Modbus TCPを5 Gネットワーク上に搭載し、無線フィールド機器相互接続を実現することで、配線コストを削減し、生産ラインの柔軟性を向上させることができます。5 G LAN(ローカルエリアネットワーク)技術は、PLC間およびPLCとエッジゲートウェイ間のワイヤレスModbus TCP Communicationを実現するために、産業用イーサネットを直接置き換えることができます。
FAQよくある質問
Q 1:Modbusゲートウェイのポーリング速度の上限は何ですか?昇格するには?
単一のRS-485バスのModbus RTUポーリング速度は、ボーレート(9600 bpsで約1ms/文字)、メッセージ長(読み書きには約8-25バイト)、スレーブ応答時間(1-50ms)、フレーム間隔(3.5文字時間)によって制限されます。例えば、10個のレジスタを読み取ると、メッセージは約30バイト、通信時間≈(30×11)/96 00 + 20ms ≈ 55msになります。シングルバス200 台のデバイスは、各読み取り10ポイント、約18秒を完了することができます。ボーレートの115200への増加、RTUの代わりにModbus TCPの使用、RS-485並列化の多重化、重要データのみの読み取りポイントの削減、パケット分割戦略(重要デバイス高周波、非重要デバイス低周波)などが含まれます。
Q2:MQTT Brokerはエッジまたはクラウドに導入すべきですか?
2レベルのブローカーアーキテクチャを推奨します。エッジ側に軽量MQTTブローカー(MosquittoやNanoMQなど)を展開し、すべてのModbusゲートウェイのローカルデータ集約とローカルアプリケーション(HMI、ローカル監視画面など)のデータ配信を行います。クラウドにエンタープライズグレードのMQTTブローカー(EQXクラスタなど)を展開し、MQTTブリッジモードを介してエッジブローカーとデータを同期します。このアーキテクチャの利点は、クラウドがダウンしてもローカル監視が影響を受けないこと、エッジからクラウド間のMQTT接続が1つだけでネットワークオーバーヘッドが削減されること、Cloud Brokerがすべてのサイトのデータルーティングと権限を一元的に管理できることです。
Q 3:産業シナリオでのNode-REDの信頼性はどのくらいですか?
Node-REDは、プロトタイプ検証や小規模生産環境(50 台未満)でうまく機能します。しかし、大規模な産業展開(100以上のデバイス、10,000以上のデータポイント)では、以下の問題に注意する必要があります。単一プロセスのNode.jsのCPUボトルネックは、クラスタモードまたは複数のNode-REDインスタンスの分割によって解決できます。再起動後にフロー状態が失われ、外部ストレージ(SQLiteなど)で状態を永続化する必要があります。長時間実行した後にメモリリークが発生する可能性があり、PM 2プロセス管理ツールで自動再起動とヘルスモニタリングを実現することをお勧めします。ミッションクリティカルなシナリオでは、純粋なオープンソースのビルドを置き換えるために、Advantech WISE-EdgeLinkやMOXA ThingsProなどの商用エッジコンピューティングプラットフォームを使用することをお勧めします。
Q 4:Modbusデータをクラウドにアップロードした後、レポートでデータを追跡する方法は?
データトレースの鍵は、元のModbusデータのコンテキスト情報を保持することです。データをエグレードする际には、各データポイントは次のメタデータを携帯する必要があります。デバイス固有のID Device ID、レジスタアドレス、生の値RValue、変换された工程値Value、取得タイムスタンプミリ秒までの精度、データフラグGood/Bad/Uncertain。時系列データベース例えばTDengineは設備IDをタグTagとしてサブテーブルを作成することをサポートし、問合せ時に設備別、時間帯別、レジスタアドレス別に柔軟なデータの遡及と比較分析を行うことができる。
おわりにまとめ
Modbus産業用モノのインターネットテクノロジーの活力は、表面的な高度性ではなく、実際のシナリオで問題を解決できるかどうかにあるということです。Modbusプロトコルは、ミニマルな設計、広範なデバイスサポート、ライセンスコストゼロにより、産業用OTの世界とITの世界をつなぐ自然な架け橋となります。採択されたModbusエッジコンピューティングゲートウェイ、Modbus MQTTプロトコルブリッジと合理的Modbusクラウドプラットフォームアーキテクチャ設計により、Modbusのシンプルで信頼性の高い機能を維持しながら、モノのインターネットとクラウドコンピューティングがもたらすインテリジェンス機能を楽しむことができます。
1979 yearにModiconがModbusプロトコルをリリースしてから40年以上が経ちました。40年以上にわたり、無数のCommunicationプロトコルが出現したり消滅したりしましたが、Modbusは世界中の数億の産業機器で活躍し続けています。IIoT ModbusModbusの終わりではなく、インテリジェンスの時代の始まりです。すべての読者がmodbus.cnでこの古典的なプロトコルをより広範な産業用IoTシナリオに適用できることを願っています。
続きを読むお勧めmodbus.cn上の関連記事シリーズ:
- Modbusエッジコンピューティングゲートウェイ選択完全ガイド
- ModbusからMQTT Sparkplug Bへの変換
- Node-RED Modbusデータ可視化チュートリアル
- TDengine + Modbus産業用モノのインターネットデータストレージソリューション
- 主流 PLCでのModbusプログラミングの実践ガイド
- 産業用モノのインターネットModbusセキュリティシステム
テクノロジーの道では、modbus.cnが同行します。
Leave a Reply