- 1. 别上来就选Vereinbarung
- 2. 三种Vereinbarung，用一句话说清
- 3. 12 条Auswahl标准，工程硬指标
- 4. 1. AusrüstungAnzahl：轮询的数学天花板
- 5. 2. Kommunikation模型：轮询 vs Ereignisse驱动
- 6. 3. 带宽和Verzögerung:物理层决定下限
- 7. 4. Daten模型复杂度：从Register.zu对象
- 8. 5. 安全性：谁在裸奔
- 9. 6. 互Operationen性：和谁家Die Ausrüstung说话
- 10. 7. 开发周期和团队技能
- 11. 8. 硬件成本：芯片级的价格schlecht
- 12. 9. 云接入：Vereinbarung的天生基因
- 13. 10. 历史遗留：改不动就别改
- 14. 11. Ausrüstung发现：谁知道总线上有什么
- 15. 12. Firmware-Upgrade和配置管理
- 16. 决策路径，走一遍
- 17. 混合架构：真实项目的玩法
- 18. 经典组合：Modbus RTU → 网关 → MQTT → 云
- 19. OPC UA 作为聚合层
- 20. 双通道：MQTT 上报 + Modbus TCP 本地控制
- 21. 什么时候不需要混合
- 22. Vereinbarung组合速查表
- 23. 没人会替你说的真相
别上来就选Vereinbarung
每个论坛都在问同一个问题：「我这个项目用 Modbus 还是 MQTT？要不要上 OPC UA？」
回答永远是——先告诉我你的现场有几台Ausrüstung、走什么物理层、Daten往哪去。
Vereinbarung选型不是选哪个更先进，是选哪个在你这Szene下出的问题最少。Modbus 1979 Jahr诞生，MQTT 1999 Jahr，OPC UA 2006 Jahr——三个Vereinbarung都没死，说明各有各的饭碗。你需要的不是「哪个最好」的结论，是一套工程决策框架，让你三Unterteilung钟内自己得出结论。
三种Vereinbarung，用一句话说清
**Modbus RTU/TCP**：Hauptstation挨个问Von der Station，一问一答。帧Das Format固定，Adresse+Funktionscode+Daten+CRC。Von der Station不会主动说话，必须等Hauptstation叫它。
打个比方：军训Bezeichnung。教官叫一个学Nr.，Studenten报一声「zu」。再叫下一个。全班 30 个人，一个一个来，秩序井然。教官累点没关系，但如果有 500 个人？等叫zu最后一排已经过去二十Unterteilung钟了。
**MQTT**：发布/订阅模型。Ausrüstung自己决定什么时候上报，不需要有人来问。Broker 是邮局，Ausrüstung往主题里扔消息，谁订阅谁收zu。
现场类比：微信群。Der Sensor在群里发了一条「我超标了」，所有订阅了这个群的Das System同时看zu。不用等谁问。
**OPC UA**：面向对象的工业互Operationen框架。不只是传输Daten，还自带语义模型——告诉你这段Daten是「Elektrische Motoren电流」，单位是安培，取值范围 0-100，精度 0.1。还有安全通道、认证证书、方法调用。
像外语翻译官：西门子 PLC 说德语，罗克韦尔说英语，三菱说日语，OPC UA 负责翻译成通用语，还附带一本详细的语法说明书。
三种Vereinbarung不打架。真实项目里它们经常混着用。
12 条Auswahl标准，工程硬指标
1. AusrüstungAnzahl：轮询的数学天花板
Modbus RTU 在 9600 bps 下，读一个保持Register.（Funktionscode 03），Hauptstation发 8 Bytes，Von der Station回 7 Bytes（Adresse+Funktionscode+Anzahl der Bytes+2 BytesDaten+2 Bytes CRC），共 15 Bytes。加上 3.5 Charaktere的帧间隔（约 4ms @ 9600）和Von der StationAntwort延迟（通常 10-50ms，保守取 20ms）：
每台Von der Station单次轮询Zeit = 帧传输Zeit + 帧间隔 + Von der StationAntwort延迟
帧传输Zeit = 15 × 11 bit ÷ 9600 = 17.2ms（11 bit/Charaktere：1 Anfang位+8 Datenplatz+1 Prüfstand.+1 Stoppen Sie Platz）
单台轮询 ≈ 17.2 + 4 + 4 + 20 = 45.2ms
200 台Von der Station，每台读 10 ein Register.（多Register.Lesen的帧更长，一帧大概能塞 125 ein Register.），实际单轮询大约 60-80ms/台。
**200 台 × 70ms = 14 秒。**你在控制室里看着屏幕，HMI 上的Daten 14 秒才Erfrischen一次。报警信Nr.在路上走了 14 秒才被你看zu。
这还是理论最优值。实际工程里，Von der StationAntwort超时、重试、线路质Quantität下降都能让这个数字翻倍。
**结论：Ausrüstung < 50 台，Modbus RTU 轮询周期在 2-3 秒以内，对大多数监控Szene够用。超过 100 台，要么上 Modbus TCP（Ethernet不吃Die Serie带宽的亏），要么改用 MQTT。**
2. Kommunikation模型：轮询 vs Ereignisse驱动
Modbus 是轮询。你每隔 N 秒问一圈，报警信Nr.可能在两次轮询之间产生，但你必须等zu下一圈才看zu。
Szene：污Wasserbehandlung站，进水 pH 值突然从 7 跌zu 4。Modbus 的轮询周期是 5 秒，最坏情况——pH Der Sensor刚被问完就超标，你要等接近 5 秒才知道。5 秒对于工艺保护来说，太长了。
MQTT 是Ereignisse驱动。Der Sensor检测zu异常，立刻发布消息。Broker 在同一秒内转发给监控Das System。延迟取决于网络延迟+Broker 处理Zeit，通常在 100ms 以内。
OPC UA 支持订阅模式（MonitoredItem）。客户端Registrierung关心的Daten点，设定采样间隔和触发条件。变化>阈值才推送，不是傻轮询全Quantität。
**结论：如果你的报警AntwortZeit要求 < 1 秒，Modbus 轮询做不zu，选 MQTT 或 OPC UA 订阅。**
3. 带宽和Verzögerung:物理层决定下限
| 物理层 | 典型速率 | 适合Szene |
|---|---|---|
| RS-485 (Modbus RTU) | 1200-115200 bps | 本地总线，<1200 米 |
| Ethernet (Modbus TCP) | 100 Mbps | 工厂局域网 |
| 4G Cat.1 | 上行 5 Mbps | Fern entfernt终端，有基站覆盖 |
| NB-IoT | 上行 ~60 kbps | 低功耗广域，日DatenQuantität < 1KB 的Szene |
| LoRa | 0.3-50 kbps | 超远距离，极低功耗 |
RS-485 的 1200 米极限我见过能达zu的——前提是高质Quantität屏蔽双绞线、9600 bps、只有一台Ausrüstung、没有变频器在旁边。车间现场，变频器一开，KommunikationFehler.率飙升，你就得降Porter Rate加屏蔽加隔离。
Modbus RTU 在 9600 bps 下，传输密度大概 800 Bytes/秒（去掉Anfang位Stoppen Sie Platz开销）。MQTT 走 4G，几十 KB 不是问题。OPC UA 的BinärsystemCodierung效率还不错，但Verbindung建立时的证书交换和会话协商要吃掉几百 KB。
**结论：本地总线，带宽不是瓶颈。Fern entfernt接入，Modbus RTU 不直接走公网——你没见过有人把 RS-485 线从北京拉zu石家庄的。必须过网关。**
4. Daten模型复杂度：从Register.zu对象
Modbus 的Daten模型只有四种：线圈（位）、离散输入（位）、保持Register.（16 位字）、输入Register.（16 位字）。没别的了。没有浮点数、没有Charaktere串、没有Zeit戳、没有数组结构体——除非你自己在多ein Register.上Codierung。
一台变频器的Daten：BetriebStatus（位）、设定频率（浮点数，占 2 ein Register.）、实际频率（浮点数）、输出电流（浮点数）、母线电压（整数）、BetriebZeit（32 位，2 ein Register.）、报警代码（位掩码）。全用 Modbus Register.实现，你需要维护一份 Excel 表格记录哪ein Register.对应什么Parameter、用什么Codierung。散落在十台变频器上就是几百ein Register.的映射表。
MQTT 也好不zu哪去——JSON 自由Das Format，但各厂家对「频率」这个Feld叫 freqency、freq、Hz、output_freq 的都有。没有标准，你自己定约定。
OPC UA 的信息模型（IM）从Vereinbarung层解决了这个问题：每个Daten点有 Type、Unit、Range、EngineeringUnits。一个 MotorType 对象下面有 Current、Temperature、Speed——自带语义，不是裸Register.。
**结论：Daten点 < 50 个、Typus简单（全是整数/Schalter!Quantität），Modbus Registerabbildung完全够用。超过 200 个点、涉及复杂对象模型，OPC UA 帮你省掉一半的Dokumentation维护工作Quantität。**
5. 安全性：谁在裸奔
Modbus 的设计Jahr代（1979 Jahr）没人考虑网络安全。RTU 帧上没有认证Feld，任何接入 RS-485 总线Die Ausrüstung都能发Befehl——关泵、改Parameter、写Register.。TCP 版本多了一层 TCP Verbindung，但也没有内置 TLS。
MQTT 可以通过 TLS 加密传输，Username/Password 认证，Broker 端还能做 ACL 控制哪些客户端能发布/订阅哪些主题。
OPC UA 的安全模型是三件套：证书认证（X.509）+ 消息签名 + 消息加密。还支持用户令牌（用户名密码/证书/匿名）。从Verbindung建立zuDaten传输，全链路加密。
有一次我去某水厂做排查，发现他们的 Modbus TCP 网关公网端口开着，扫进去就能直接写变频器启停Register.。没开玩笑，这种事在中小Unternehmen非常多。
**结论：公网传输、Fern entfernt运维、涉及关键基础设施的Szene——别用裸 Modbus。至少要过 MQTT+TLS 的网关。如果已经有 OPC UA 能力，直接用它的安全通道。**
6. 互Operationen性：和谁家Die Ausrüstung说话
最理想情况是所有Ausrüstung都跑同一种Vereinbarung——你西门子我施耐德他 AB，都用 Profinet 就完了。现实不是这样。
Modbus 的优势恰恰在这里：几乎所有 PLC 都支持 Modbus RTU/TCP，不管是西门子 S7-1200 的 CM1241 模块还是三菱 FX 系列的 RS-485 口。Ausrüstung厂商也乐意支持——不用付版税，实现简单，几天就能调通。
MQTT 的互Operationen性靠约定主题结构和 JSON Das Format。但各家的约定可能不同。**Sparkplug B 规范**补了这个坑——定义了标准主题命名空间、DatentypCodierung、Ausrüstung出生/死亡消息。
OPC UA 的互Operationen性是Vereinbarung内置的：配套规范（Companion Specification）覆盖了机器人、注塑机、CNC、风力发电等几十个行业。西门子的 OPC UA Server 和罗克韦尔的 OPC UA Client 能直接对话，不需要写映射层代码。
但话说回来：OPC UA 的配套规范还在发展中，不是所有Ausrüstung都支持。有些厂商的 OPC UA 实现就是个皮包——结点能浏览，实际Daten更新频率跟不上。
**结论：和多种品牌 PLC/DCS 互Operationen是硬需求→OPC UA。Ausrüstung全是国产电表/Der Sensor→Modbus RTU 就够。需要Cloud-Plattform对接→MQTT。**
7. 开发周期和团队技能
这是被严重低估的一条。
Modbus 开发：找个Die Serie库，发 8 Bytes，收 7 Bytes，调两天，通了。Vereinbarung栈代码Quantität几百行。你用 Python 的 pymodbus 或者 C# 的 NModbus，上午装包下午就能读写Register.。三天之内做完一个 Modbus Hauptstation驱动的工程师大有人在。
MQTT 开发：装个 paho-mqtt 库，Broker Adresse、端口、主题，三行代码连上。发布/订阅各两行。一天上手。Broker 部署（Mosquitto/EMQX）半小时Erledigt.
OPC UA 开发：这件事我要说实话——不简单。Adresse空间建模、证书管理、安全策略配置、订阅/方法调用，学习曲线比前两者陡得多。你用 UAExpert 客户端连上 Server 是一回事，自己写一个vollständig的 OPC UA Server 是另一回事。工业上通常用 KepServerEx、Siemens OPC UA Server 这些成熟产品，调 SDK 的居多，从头写的不多。一个团队如果没有 OPC UA 经验，预留 2-4 周做Techniken验证。
**结论：3 天开发→Modbus。1 天开发→MQTT。有专人且项目允许学习成本→OPC UA。**
8. 硬件成本：芯片级的价格schlecht
RS-485 收发器（MAX485/SP3485）批Quantität价不zu 1 块钱人民币。加上两个 120Ω 终端电阻、一个 TVS 保护管，BOM 成本 3 块钱以内。STM32F103 单片机的 UART 外设直接驱动，连外部 PHY 都不需要。
MQTT 的最小硬件需求：网络栈（WiFi/Ethernet/4G 模块）+ TCP/IP Vereinbarung栈。ESP32 自带 WiFi+BLE，批Quantität价大概 12-15 块，跑 FreeRTOS+LwIP+paho MQTT 毫无压力。如果是 4G 模组（合宙 Air724UG 大概 20 块），也能跑 MQTT AT 指令。
OPC UA 对硬件有要求。一个最小 OPC UA Server（支持安全策略 Basic256Sha256、支持 1000 个变Quantität节点）大概需要 256KB RAM + 512KB Flash。你可以在 STM32H7（Cortex-M7, ~30 块）上跑 open62541 的 embedded 版本，但不是「点个灯」那么简单。Industrielle Ebene OPC UA 网关通常用 ARM Cortex-A 系列的 Linux 板（比如全志 T113-i，四五十块起）。
| Vereinbarung | MCU 价格区间 | 典型硬件平台 |
|---|---|---|
| Modbus RTU | ¥3-10 | STM32F103 / GD32 |
| MQTT (WiFi) | ¥12-20 | ESP32 |
| MQTT (4G) | ¥25-40 | 合宙 Air724UG + MCU |
| OPC UA (轻Quantität) | ¥30-80 | STM32H7 / i.MX RT |
| OPC UA (vollständig) | ¥80-200 | 全志/瑞芯微 Linux 板 |
**结论：做一个售价 50 块的 Modbus RTU Temperatur FeuchtigkeitDer Sensor，换 OPC UA 方案硬件成本就兜不住。做一台售价 5000 的Das industrielle Netzwerk，OPC UA 的那点硬件成本根本不是事。**
9. 云接入：Vereinbarung的天生基因
Modbus 是为本地总线设计的。你不可能直接把 RS-485 怼zu阿里云 IoT 平台上。必须过网关——Modbus RTU → 网关（做Vereinbarung转换）→ MQTT/HTTP → 云端。
MQTT 天然适合云接入。AWS IoT Core、阿里云 IoT、EMQX Cloud、ThingsBoard——所有主流 IoT 平台的Die一公民都是 MQTT。主题路由灵活，遗嘱消息（Last Will）解决Ausrüstung离线检测，保留消息（Retained）确保新上线的订阅者立刻拿zu最新Status。
OPC UA 的 Client/Server 模式不太适合云——广域网延迟高，UA 的安全握手和会话管理吃不消。但 OPC UA 有一个 Pub/Sub 扩展（2018 Jahr发布），支持 UDP 多播和 MQTT Broker 传输，专门解决云接入问题。不过目前实际部署的 OPC UA Pub/Sub 案例还不多，mehr.是 OPC UA Server → 边缘网关 → MQTT → 云的间接路线。
**结论：你的Daten终点是云端→MQTT，别犹豫。本地 SCADA/Historian→OPC UA。既上云又本地监控→MQTT+OPC UA 组合。**
10. 历史遗留：改不动就别改
最Häufig的Szene：一个污Wasserbehandlung厂，200 台 Modbus RTU 电表（威胜/科陆/林洋），已经在 RS-485 总线上跑了五Jahr。你现在要上云做能耗管理平台。
把这 200 台电表全换了？不现实。预算是一回事，关键是它们根本没坏。用 Modbus-MQTT 网关是最合理的方案：电表继续跑 Modbus RTU，网关做轮询采集，Daten打包成 JSON 走 MQTT 上云。电表这端是稳稳当当的 Modbus，云端是现代 IoT 架构——两头都不吃亏。
同样道理：某汽车厂的涂装车间有 50 台 AB PLC，全跑 EtherNet/IP。你想加一个 MES Das System，让这些 PLC 的Daten能被 MES 读zu。方案 A：每台 PLC 配 Modbus TCP 模块。方案 B：加一台 KepServer / Ignition 的 OPC UA 网关，聚合 EtherNet/IP 的Daten后暴露 OPC UA Schnittstelle。方案 B 不改现场Ausrüstung一根线。
**结论：已有Ausrüstung跑什么Vereinbarung就尊重什么Vereinbarung。用网关做桥接，不要想着把现有Ausrüstung全升级——那是钱多烧的。**
11. Ausrüstung发现：谁知道总线上有什么
Modbus 没有Ausrüstung发现机制。你要知道von der Station Adresse 1 zu 247 上zu底挂了哪些Ausrüstung？唯一的方法：挨个发Funktionscode 03（Lesen Sie das Register）或 08（诊断），等回应。超时不回就认为没Ausrüstung。这个过程叫「Adresse扫描」——在 9600 bps 下扫完 247 个Adresse需要几十秒，而且某些Ausrüstung对UnbekanntRegister.的Lesen会报异常。
MQTT 本身也没有Ausrüstung发现。Ausrüstung上线发一条消息zu特定主题，但这靠的是约定的业务逻辑，不是Vereinbarung层面的机制。Sparkplug B 规范加了Ausrüstung出生/死亡消息，但需要Empfang方主动监听。
OPC UA 内置了发现服务（Discovery Server，默认端口 4840）。客户端Verbindung Discovery Server，问「你下面Registrierung了哪些 Server」，拿zu列表和端点 URL，再去Verbindung。局域网内还能用 mDNS（组播 DNS）自动发现 OPC UA Server。
**结论：Ausrüstung经常换、网络拓扑动态变化→OPC UA 的发现服务省你很多配置Zeit。Ausrüstung固定不变、装了就不动→Modbus 手动配一遍也不碍事。**
12. Firmware-Upgrade和配置管理
Modbus 只定义了Daten读写。Firmware-Upgrade？没有标准Funktionscode。有些厂商用Funktionscode 0x41-0xFF 的Custom definiert区实现，但每家都不一样，互相不通。
MQTT 同理——传输固件包可以，但Das Format和流程你自己定。
OPC UA 有标准的方法调用（Method Call）。你可以定义一个「升级固件」方法，接受固件文件 URL 和版本Nr.Parameter，返回升级进度和Ergebnis。Device Integration 配套规范（DI）还定义了标准Die Ausrüstung管理模型。
**结论：批QuantitätAusrüstungFirmware-Upgrade是核心需求→OPC UA 的方法调用比你自创一套Vereinbarung靠谱。偶尔升级、现场人员 USB 线怼上去就行→Modbus 够用。**
决策路径，走一遍
你的项目
│
├── AusrüstungAnzahl > 100？
│ ├── 是 ──→ 需要Ereignisse驱动（报警 < 1s Antwort）？
│ │ ├── 是 ──→ 需要多种品牌互Operationen？
│ │ │ ├── 是 ──→ 【OPC UA】
│ │ │ └── 否 ──→ 【MQTT】
│ │ └── 否 ──→ 【Modbus TCP】（配高性能Hauptstation，轮询周期可接受）
│ │
│ └── 否 ──→ 需要上云？
│ ├── 是 ──→ 【MQTT】
│ └── 否 ──→ 公网传输 / 需要安全？
│ ├── 是 ──→ 【OPC UA / MQTT+TLS】
│ └── 否 ──→ 【Modbus RTU】
│ 最简单的方案永远最好不是所有Szene都走zu底选一种Vereinbarung。大多数时候你选的是组合。
混合架构：真实项目的玩法
经典组合：Modbus RTU → 网关 → MQTT → 云
底层电表、Der Sensor跑 Modbus RTU，用一台Eingebettet网关（比如华为 AR650、映翰通 IG902、或者你自己用Raspberry Pi+Node-RED 攒的）做Vereinbarung转换：
┌──────────┐ RS-485 ┌──────────┐ MQTT/TLS ┌─────────────┐
│ 电表 ×50 │───────────→│ Modbus- │───────────→│ 云 IoT 平台 │
│ Modbus │ Modbus RTU│ MQTT 网关│ │ (Ali/AWS) │
│ RTU │ │ │ │ │
└──────────┘ └──────────┘ └─────────────┘网关做两件事：轮询采集 50 台电表的电压/电流/功率/电能，按一Unterteilung钟间隔打包成 JSON，走 MQTT 发布zu云端。电表不换，云端是现代的。这种架构在Verteilung光伏监控和能耗管理平台上已经被验证无数次。
OPC UA 作为聚合层
工厂里 50 台 Modbus TCP Von der Station（Unterteilung布在五个车间），上层 MES 要统一取Daten。中间放一台 OPC UA Server 网关，跑 KepServer 或者自己用 open62541 写的程序：
┌────────────┐
│ MES Das System │
└─────┬──────┘
│ OPC UA Client
▼
┌──────────────────┐
│ OPC UA Server │ ◄── 聚合网关
│ (KepServerEx等) │
└──┬───┬───┬───┬──┘
│ │ │ │ Modbus TCP
▼ ▼ ▼ ▼
50台 Modbus TCP Von der Station (PLC/仪表)好处：MES 只对接一个 OPC UA Schnittstelle，不用关心每台Ausrüstung的 IP Adresse和Registerabbildung。网关内部做了Daten聚合和Adresse空间建模。
双通道：MQTT 上报 + Modbus TCP 本地控制
某Smart Landwirtschaft大棚：50 个 LoRa Temperatur FeuchtigkeitDer Sensor通过 LoRa 网关→MQTT 上报zuCloud-Plattform做趋势Unterteilung析。同时大棚里的风机、卷帘Elektrische Motoren走 Modbus TCP，本地触摸屏（HMI）直接控制。Cloud-Plattform也可以发 MQTT Befehl给网关，网关转 Modbus TCP 指令控制风机启停。
┌──────────┐ LoRa ┌────────┐ MQTT ┌──────────┐
│ Der Sensor×50 │───────→│ LoRa │───────→│ Cloud-Plattform │ ← DatenUnterteilung析
└──────────┘ │ 网关 │ └────┬─────┘
└───┬────┘ │ MQTT 控制指令
│ Modbus TCP ▼
┌───┴────────────┐
│ 本地 HMI + PLC │ ← 实时控制
│ (风机/卷帘) │
└────────────────┘为什么这么设计？Der Sensor上报DatenQuantität小但频率高（每Unterteilung钟），MQTT 省流Quantität。风机控制要求低延迟（< 500ms 必须Antwort），Modbus TCP 直连最可靠。Cloud-Plattform的Unterteilung析Ergebnis→控制指令的回路走 MQTT，可以接受几百毫秒的延迟。
什么时候不需要混合
如果你的项目不超 30 台Ausrüstung、不需要上云、不需要Fern entfernt运维——一台 PLC 带 Modbus RS-485 总线和一块 HMI 屏幕，三根线（A/B/GND），够了。不要为了「先进性」把架构搞复杂。工程里简洁就是可靠性。
Vereinbarung组合速查表
| Szene | Ausrüstung数 | 上云 | 实时性 | 多品牌 | 推荐方案 |
|---|---|---|---|---|---|
| 污Wasserbehandlung厂本地监控 | 30 台仪表 | 否 | 秒级够 | 否 | Modbus RTU |
| Verteilung光伏电站 | 500 台逆变器 | 是(4G) | 报警秒级 | 是 | Modbus RTU + MQTT 网关 |
| 汽车焊装车间 MES | 200 台Ausrüstung | 否 | 是 | 是(西门子为主) | OPC UA |
| Smart Landwirtschaft大棚 | 50 Der Sensor+10 Der Executor | 是(LoRa+4G) | 控制百毫秒 | 否 | MQTT Sensor + Modbus TCP Actuator |
| Gebäude selbst kontrollieren | 100 个 DDC Der Controller | 可选 | 秒级够 | 是(HVAC多品牌) | Modbus TCP / BACnet + OPC UA |
| Fern entferntAusrüstung运维 | Unterteilung散各地 | 是 | 非实时 | 否 | MQTT + TLS |
| 单机Ausrüstung（变频器+HMI） | < 10 | 否 | 毫秒级 | 否 | Modbus RTU |
没人会替你说的真相
Modbus 没有安全机制，这是真的。它的帧就是明文，CRC 只管传输出错不管恶意篡改。有人把 Modbus Der TCP-Port暴露在公网上，跟把工厂大门敞开没什么区别。
Modbus 没有Ereignisse驱动。你要Ereignisse？自己想办法轮询得快一点。
Modbus 没有标准Daten模型。A 厂的电表把电压放 40001 Register.，B 厂放 40002。你的代码里zu处都是 if-else 判断Ausrüstung型Nr.。
但 Modbus 活了四十多Jahr不是靠Funktion强，是靠够简单。能在 8 位单片机上跑，能在零下三十度稳定Betrieb，能一个下午调通。MQTT 出现了，OPC UA 出现了，它没死，因为还有大QuantitätSzene不需要高级Funktion——30 台Ausrüstung、一个厂房、本地 HMI，Modbus RTU 一条线穿zu底，什么叫 over-engineering？硬上 OPC UA 就叫 over-engineering。
反过来，如果你面对的是 500 台AusrüstungVerteilung部署在 50 公里范围内、需要Cloud-PlattformUnterteilung析、要求报警推送——抱着 Modbus 不放就是在给自己找麻烦。这时候 MQTT 加 Modbus 网关是最务实的Auswahl。
如果你在一个多品牌 PLC 混用的工厂，需要 MES Das System对上层暴露统一Schnittstelle——OPC UA 是标准答案。
哪个Vereinbarung都不是完Schön.，你选的是在你这Szene下最不坏的那个。这行的智慧在于：知道什么时候够用就好，知道什么时候必须升级。
Antwort veröffentlichen