简介这份文档面向工业自动化、SCADA系统开发与运维人员以及希望了解第四代Web SCADA架构的技术学习者系统讲解具备Web功能的SCADA系统原理与实现。内容围绕Internet技术、面向对象技术、DNA神经元技术等内核展开重点剖析Action Web SCADA系统的软件基础与硬件特点包括OPC与WebOPC通信机制、WebViewI/O信号转换器、WVC16接口控制模块以及远程访问、多途径报警、仪器虚拟化、脚本语言扩展等八项优势并给出与PLC/DCS无缝对接或独立安装的部署思路。资源包共1个doc文件约4.54MB以图文文档形式呈现便于按章节查阅与整理笔记。目前已有309人学习适合需要理解Web SCADA体系结构、选型依据与远程监控方案的技术人员参考。1. 从一份“WEBscada系统.doc”说起把 PLC 数据搬上浏览器到底要几步车间里那台跑了八年的西门子 S7-1200 还在稳定输出可每次想看实时曲线都得跑到中控室那台装了组态软件的工控机上。老板一句“能不能手机上也能看”就把“WEBscada系统”这个需求摆到了桌面上。所谓 WEBscada本质是把传统 SCADA 的采集、监控、报警能力从 C/S 组态软件搬到 B/S 架构里——浏览器打开就能看不用装客户端。它要解决的核心问题只有一个怎么把 OPC、Modbus、以太网接口上的 PLC 数据稳定、低延迟地送到网页上。适合谁做非标项目调试的一线工程师、想给老设备加远程监控的运维、以及被“SCADA 如何与 PLC 连接”卡住过的开发者。这篇不聊虚的从协议选型一路讲到浏览器刷新把能抄的代码和踩过的坑都摊开。2. 协议选型OPC UA、Modbus TCP 和原生以太网到底怎么挑2.1 先搞清楚数据从 PLC 到浏览器要过几道手一条完整的 WEBscada 链路通常是四段PLC或传感器、数控机床→ 采集网关/服务 → 数据服务层 → 浏览器前端。第一段是设备侧协议第二段是采集程序第三段是数据缓存与接口第四段是可视化。很多人一上来就纠结前端用 ECharts 还是 Three.js其实真正决定项目能不能落地的是第一段和第二段——协议选错后面全是返工。设备侧协议主流就三类。OPC UA 是现在新建项目的首选西门子、倍福 TwinCAT3、汇川 Codesys 系 PLC 都原生支持自带信息模型和订阅机制不用轮询。Modbus TCP 是老设备改造的救命稻草三菱 FX 系列加个以太网模块、国产仪表、电表基本都认它缺点是只有寄存器地址没有语义。原生以太网协议比如西门子 S7 通信、三菱 MC 协议性能最好但绑定品牌跨品牌项目会把自己锁死。选型判断很简单新项目、多品牌、要语义化 → OPC UA老设备、点位少、预算紧 → Modbus TCP单一品牌、高频采集比如振动监测要毫秒级→ 原生协议。我一般会先问一句“现场有几家品牌的 PLC”答案超过两家OPC UA 基本就定了。2.2 用 Python 跑通 OPC UA 读取 PLC 的最小闭环先装依赖opcua这个库注意不是python-opcua那个已经停止维护是目前维护最活跃的。pip install opcua下面这段是最小可运行示例连西门子 S7-1500 的 OPC UA 服务端读一个变量并订阅变化from opcua import Client import time # 西门子 PLC 的 OPC UA 端点端口默认 4840 url opc.tcp://192.168.0.10:4840 client Client(url) # 如果 PLC 开了匿名以外的认证这里要填用户名密码 # client.set_user(operator) # client.set_password(xxxx) try: client.connect() # 节点 ID 因 PLC 组态而异西门子通常在 ServerInterfaces 下 node client.get_node(ns3;s\DB_Data\.\Temperature\) print(当前值:, node.get_value()) # 订阅数据变化时回调比轮询省资源 class SubHandler: def datachange_notification(self, node, val, data): print(f变化 - {val}) handler SubHandler() sub client.create_subscription(500, handler) # 500ms 发布间隔 sub.subscribe_data_change(node) time.sleep(30) # 观察 30 秒 finally: client.disconnect()逻辑说明Client建立会话后get_node用 NodeId 定位变量create_subscription的 500 是发布周期毫秒不是采集周期——真正采集由服务端按你组态的最小采样间隔决定。参数上ns3是命名空间索引西门子组态时每个 DB 块会分配写错就报BadNodeIdUnknown。订阅比轮询的优势在点位多时特别明显1000 个点轮询要 1000 次请求订阅只有一次会话加服务端推送。2.3 Modbus TCP 读取老设备改造的寄存器映射表Modbus 没有语义全靠地址表。以三菱 FX5U 加以太网模块为例读 D 寄存器用功能码 03保持寄存器读 X/Y 用 01/02线圈和离散输入。from pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.0.20, port502) client.connect() # 读 D100 开始的 10 个保持寄存器slave1 是从站号 rr client.read_holding_registers(address100, count10, slave1) if not rr.isError(): # 寄存器是 16 位两个拼一个 32 位浮点时要处理字节序 print(原始寄存器:, rr.registers) client.close()参数说明address100对应 D100但注意有些库从 0 开始计数有些从 1 开始差一位就全错。count一次别超过 125 个寄存器Modbus 协议单帧上限。字节序是最大的坑——三菱和西门子的 32 位浮点高低字顺序相反读出来是乱码时先怀疑字节序用struct.unpack(f, ...)和f各试一次。2.4 采集频率和以太网吞吐量的现实边界热搜里有人问“千兆网以太网吞吐量 100mbps”这其实是把链路带宽和有效数据率搞混了。千兆网理论 1000Mbps但 Modbus TCP 单次请求响应往返通常 520ms一次读 100 个寄存器约 200 字节有效数据算下来有效吞吐也就几 Mbps。真正限制采集频率的是 PLC 扫描周期和协议往返不是网线。经验值Modbus TCP 轮询周期别低于 100ms否则 PLC 通信负载会拖慢主程序OPC UA 订阅可以做到 50ms 甚至更低但要看 PLC 的发布间隔组态。点位超过 500 个建议分多个采集进程或网关单进程串行轮询会积压。3. 把采集服务写成能长期跑的后台缓存、接口与断线重连3.1 为什么不能采集完直接推给前端新手最容易犯的错是采集线程直接 WebSocket 推浏览器。一旦浏览器刷新或断网采集就断而且多个页面同时看会重复采集。正确做法是采集与展示解耦采集服务只管把数据写进缓存Redis 或内存队列前端通过接口读缓存。这样采集是常驻的前端来去自由。缓存结构我一般用 Redis 的 Hashkey 是设备编号field 是点位名value 是带时间戳的 JSON。保留最近 1 小时原始数据用 List历史趋势落时序库InfluxDB 或 TDengine。别小看这一步没有缓存层报警和趋势回放都做不了。3.2 一个带断线重连的采集循环骨架import time import redis import json from opcua import Client r redis.Redis(host127.0.0.1, port6379, db0) def collect_loop(): while True: client Client(opc.tcp://192.168.0.10:4840) try: client.connect() node client.get_node(ns3;s\DB_Data\.\Temperature\) while True: val node.get_value() payload {value: val, ts: time.time()} r.hset(dev:plc01, temperature, json.dumps(payload)) time.sleep(1) except Exception as e: print(采集异常5 秒后重连:, e) time.sleep(5) finally: try: client.disconnect() except Exception: pass collect_loop()逻辑说明外层while True保证任何异常都不会让进程退出这是长期运行服务的底线。finally里再包一层 try 是因为断线状态下disconnect本身也可能抛异常。重连间隔 5 秒是经验值太短会在 PLC 重启时疯狂重试太长数据空洞大。参数上time.sleep(1)是采集周期按点位重要程度调整关键点位可以单独开高频线程。3.3 前端拿数据的接口设计后端用 FastAPI 暴露一个读缓存的接口前端定时拉或走 WebSocket 推送from fastapi import FastAPI import redis, json app FastAPI() r redis.Redis(host127.0.0.1, port6379, db0) app.get(/api/point/{dev}/{point}) def get_point(dev: str, point: str): raw r.hget(fdev:{dev}, point) if not raw: return {ok: False, msg: 无数据} return {ok: True, data: json.loads(raw)}参数说明接口按设备和点位两级定位方便前端复用。返回里带ok字段是习惯前端不用靠 HTTP 状态码判断业务成败。如果点位多别一个点一个请求加个批量接口一次取整个 Hash。3.4 时间戳统一别让前端和 PLC 各说各话PLC 的时间戳、采集服务的时间戳、浏览器显示的时间戳三者不一致是趋势图错位的元凶。我的做法是采集时统一打服务器时间戳PLC 内部时间只做参考不参与展示。如果必须用 PLC 时间先确认 PLC 是否接了 NTP没接的话时钟漂移一天能差几分钟。前端展示时区统一用本地时区别混 UTC。4. 避坑与排查WEBscada 落地时最常翻车的 5 个地方4.1 现象OPC UA 连不上报 BadTimeout 或 BadConnectionClosed原因八成是端口或安全策略。西门子 PLC 的 OPC UA 服务默认可能没开或者只允许加密连接而客户端用了匿名明文。也可能是防火墙挡了 4840 端口。解决先在 PLC 组态里确认 OPC UA 服务器已启用安全策略勾上“无”调试阶段确认 4840 端口通——用telnet 192.168.0.10 4840试。生产环境再上证书别一上来就搞加密调试阶段会被证书信任链折腾到怀疑人生。4.2 现象Modbus 读出来全是 0 或者明显不对的数值原因地址偏移或字节序。地址差一位是高频错误字节序错会让浮点数变成天文数字。解决先用 Modbus 调试工具比如 Modbus Poll单独验证地址确认能读到正确值再写代码。浮点数用struct.unpack两种字节序都试哪个合理用哪个。寄存器数量别超 125超了就分两次读。4.3 现象采集服务跑几天就内存暴涨然后崩原因订阅回调里不断往 List 里塞数据没设上限或者异常对象被闭包持有无法回收。解决缓存一定要设 TTL 或最大长度Redis 用LTRIM保留最近 N 条。回调函数里别做重活只写缓存。定期用memory_profiler看一眼涨得不对劲就查引用。4.4 现象浏览器页面开着数据却不动了原因WebSocket 断了没重连或者后端采集进程挂了但接口还在返回旧缓存。解决前端加心跳和重连逻辑后端接口返回里带数据时间戳前端判断超过阈值就标红提示“数据可能已过期”。别让用户看着一个不动的数字以为是设备停了。4.5 现象多个页面同时打开PLC 通信负载飙升原因每个前端连接都触发了一次独立采集。解决采集和展示必须解耦前端只读缓存。如果一定要推送用发布订阅模式一个采集源广播给所有订阅者而不是每个连接单独采。5. 进阶用 OPC UA 信息模型把“点位表”变成“设备对象”前面都是把 PLC 当寄存器堆来读点位一多ns3;sDB_Data.Temperature这种字符串满天飞维护起来是灾难。OPC UA 真正的价值在信息模型——你可以把一台设备建模成对象下面挂温度、转速、报警状态等变量前端按对象树遍历新增设备不用改代码。具体做法是在采集服务里维护一份设备描述文件YAML 或 JSON把 NodeId 和业务语义映射起来devices: - id: plc01 name: 一号注塑机 protocol: opcua endpoint: opc.tcp://192.168.0.10:4840 points: - key: temperature node: ns3;sDB_Data.Temperature unit: ℃ type: float - key: speed node: ns3;sDB_Data.Speed unit: rpm type: int采集服务读这份配置动态建订阅前端拿到的就是带单位、带语义的数据。新增设备只改配置不改代码这是 WEBscada 从“能看”到“好维护”的分水岭。验证方法也简单拿一台设备做样板把配置跑通然后复制配置改地址看能不能零代码接入第二台。如果还要改 Python说明抽象没做够。最后说个我自己的习惯每次现场调试先不写前端用 OPC UA 客户端工具和 Modbus 调试器把数据读通确认数值、单位、刷新频率都对再动代码。这个顺序能省掉至少一半的扯皮——数据不对时你能立刻分清是设备问题还是自己代码问题。WEBscada 这方向值得做但别一上来就追求大屏炫酷先把一条链路跑稳剩下的都是复制粘贴。希望帮到你。本文还有配套的精品资源点击获取 WEBscada系统实战：PLC数据上浏览器的协议选型与采集避坑
简介这份文档面向工业自动化、SCADA系统开发与运维人员以及希望了解第四代Web SCADA架构的技术学习者系统讲解具备Web功能的SCADA系统原理与实现。内容围绕Internet技术、面向对象技术、DNA神经元技术等内核展开重点剖析Action Web SCADA系统的软件基础与硬件特点包括OPC与WebOPC通信机制、WebViewI/O信号转换器、WVC16接口控制模块以及远程访问、多途径报警、仪器虚拟化、脚本语言扩展等八项优势并给出与PLC/DCS无缝对接或独立安装的部署思路。资源包共1个doc文件约4.54MB以图文文档形式呈现便于按章节查阅与整理笔记。目前已有309人学习适合需要理解Web SCADA体系结构、选型依据与远程监控方案的技术人员参考。1. 从一份“WEBscada系统.doc”说起把 PLC 数据搬上浏览器到底要几步车间里那台跑了八年的西门子 S7-1200 还在稳定输出可每次想看实时曲线都得跑到中控室那台装了组态软件的工控机上。老板一句“能不能手机上也能看”就把“WEBscada系统”这个需求摆到了桌面上。所谓 WEBscada本质是把传统 SCADA 的采集、监控、报警能力从 C/S 组态软件搬到 B/S 架构里——浏览器打开就能看不用装客户端。它要解决的核心问题只有一个怎么把 OPC、Modbus、以太网接口上的 PLC 数据稳定、低延迟地送到网页上。适合谁做非标项目调试的一线工程师、想给老设备加远程监控的运维、以及被“SCADA 如何与 PLC 连接”卡住过的开发者。这篇不聊虚的从协议选型一路讲到浏览器刷新把能抄的代码和踩过的坑都摊开。2. 协议选型OPC UA、Modbus TCP 和原生以太网到底怎么挑2.1 先搞清楚数据从 PLC 到浏览器要过几道手一条完整的 WEBscada 链路通常是四段PLC或传感器、数控机床→ 采集网关/服务 → 数据服务层 → 浏览器前端。第一段是设备侧协议第二段是采集程序第三段是数据缓存与接口第四段是可视化。很多人一上来就纠结前端用 ECharts 还是 Three.js其实真正决定项目能不能落地的是第一段和第二段——协议选错后面全是返工。设备侧协议主流就三类。OPC UA 是现在新建项目的首选西门子、倍福 TwinCAT3、汇川 Codesys 系 PLC 都原生支持自带信息模型和订阅机制不用轮询。Modbus TCP 是老设备改造的救命稻草三菱 FX 系列加个以太网模块、国产仪表、电表基本都认它缺点是只有寄存器地址没有语义。原生以太网协议比如西门子 S7 通信、三菱 MC 协议性能最好但绑定品牌跨品牌项目会把自己锁死。选型判断很简单新项目、多品牌、要语义化 → OPC UA老设备、点位少、预算紧 → Modbus TCP单一品牌、高频采集比如振动监测要毫秒级→ 原生协议。我一般会先问一句“现场有几家品牌的 PLC”答案超过两家OPC UA 基本就定了。2.2 用 Python 跑通 OPC UA 读取 PLC 的最小闭环先装依赖opcua这个库注意不是python-opcua那个已经停止维护是目前维护最活跃的。pip install opcua下面这段是最小可运行示例连西门子 S7-1500 的 OPC UA 服务端读一个变量并订阅变化from opcua import Client import time # 西门子 PLC 的 OPC UA 端点端口默认 4840 url opc.tcp://192.168.0.10:4840 client Client(url) # 如果 PLC 开了匿名以外的认证这里要填用户名密码 # client.set_user(operator) # client.set_password(xxxx) try: client.connect() # 节点 ID 因 PLC 组态而异西门子通常在 ServerInterfaces 下 node client.get_node(ns3;s\DB_Data\.\Temperature\) print(当前值:, node.get_value()) # 订阅数据变化时回调比轮询省资源 class SubHandler: def datachange_notification(self, node, val, data): print(f变化 - {val}) handler SubHandler() sub client.create_subscription(500, handler) # 500ms 发布间隔 sub.subscribe_data_change(node) time.sleep(30) # 观察 30 秒 finally: client.disconnect()逻辑说明Client建立会话后get_node用 NodeId 定位变量create_subscription的 500 是发布周期毫秒不是采集周期——真正采集由服务端按你组态的最小采样间隔决定。参数上ns3是命名空间索引西门子组态时每个 DB 块会分配写错就报BadNodeIdUnknown。订阅比轮询的优势在点位多时特别明显1000 个点轮询要 1000 次请求订阅只有一次会话加服务端推送。2.3 Modbus TCP 读取老设备改造的寄存器映射表Modbus 没有语义全靠地址表。以三菱 FX5U 加以太网模块为例读 D 寄存器用功能码 03保持寄存器读 X/Y 用 01/02线圈和离散输入。from pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.0.20, port502) client.connect() # 读 D100 开始的 10 个保持寄存器slave1 是从站号 rr client.read_holding_registers(address100, count10, slave1) if not rr.isError(): # 寄存器是 16 位两个拼一个 32 位浮点时要处理字节序 print(原始寄存器:, rr.registers) client.close()参数说明address100对应 D100但注意有些库从 0 开始计数有些从 1 开始差一位就全错。count一次别超过 125 个寄存器Modbus 协议单帧上限。字节序是最大的坑——三菱和西门子的 32 位浮点高低字顺序相反读出来是乱码时先怀疑字节序用struct.unpack(f, ...)和f各试一次。2.4 采集频率和以太网吞吐量的现实边界热搜里有人问“千兆网以太网吞吐量 100mbps”这其实是把链路带宽和有效数据率搞混了。千兆网理论 1000Mbps但 Modbus TCP 单次请求响应往返通常 520ms一次读 100 个寄存器约 200 字节有效数据算下来有效吞吐也就几 Mbps。真正限制采集频率的是 PLC 扫描周期和协议往返不是网线。经验值Modbus TCP 轮询周期别低于 100ms否则 PLC 通信负载会拖慢主程序OPC UA 订阅可以做到 50ms 甚至更低但要看 PLC 的发布间隔组态。点位超过 500 个建议分多个采集进程或网关单进程串行轮询会积压。3. 把采集服务写成能长期跑的后台缓存、接口与断线重连3.1 为什么不能采集完直接推给前端新手最容易犯的错是采集线程直接 WebSocket 推浏览器。一旦浏览器刷新或断网采集就断而且多个页面同时看会重复采集。正确做法是采集与展示解耦采集服务只管把数据写进缓存Redis 或内存队列前端通过接口读缓存。这样采集是常驻的前端来去自由。缓存结构我一般用 Redis 的 Hashkey 是设备编号field 是点位名value 是带时间戳的 JSON。保留最近 1 小时原始数据用 List历史趋势落时序库InfluxDB 或 TDengine。别小看这一步没有缓存层报警和趋势回放都做不了。3.2 一个带断线重连的采集循环骨架import time import redis import json from opcua import Client r redis.Redis(host127.0.0.1, port6379, db0) def collect_loop(): while True: client Client(opc.tcp://192.168.0.10:4840) try: client.connect() node client.get_node(ns3;s\DB_Data\.\Temperature\) while True: val node.get_value() payload {value: val, ts: time.time()} r.hset(dev:plc01, temperature, json.dumps(payload)) time.sleep(1) except Exception as e: print(采集异常5 秒后重连:, e) time.sleep(5) finally: try: client.disconnect() except Exception: pass collect_loop()逻辑说明外层while True保证任何异常都不会让进程退出这是长期运行服务的底线。finally里再包一层 try 是因为断线状态下disconnect本身也可能抛异常。重连间隔 5 秒是经验值太短会在 PLC 重启时疯狂重试太长数据空洞大。参数上time.sleep(1)是采集周期按点位重要程度调整关键点位可以单独开高频线程。3.3 前端拿数据的接口设计后端用 FastAPI 暴露一个读缓存的接口前端定时拉或走 WebSocket 推送from fastapi import FastAPI import redis, json app FastAPI() r redis.Redis(host127.0.0.1, port6379, db0) app.get(/api/point/{dev}/{point}) def get_point(dev: str, point: str): raw r.hget(fdev:{dev}, point) if not raw: return {ok: False, msg: 无数据} return {ok: True, data: json.loads(raw)}参数说明接口按设备和点位两级定位方便前端复用。返回里带ok字段是习惯前端不用靠 HTTP 状态码判断业务成败。如果点位多别一个点一个请求加个批量接口一次取整个 Hash。3.4 时间戳统一别让前端和 PLC 各说各话PLC 的时间戳、采集服务的时间戳、浏览器显示的时间戳三者不一致是趋势图错位的元凶。我的做法是采集时统一打服务器时间戳PLC 内部时间只做参考不参与展示。如果必须用 PLC 时间先确认 PLC 是否接了 NTP没接的话时钟漂移一天能差几分钟。前端展示时区统一用本地时区别混 UTC。4. 避坑与排查WEBscada 落地时最常翻车的 5 个地方4.1 现象OPC UA 连不上报 BadTimeout 或 BadConnectionClosed原因八成是端口或安全策略。西门子 PLC 的 OPC UA 服务默认可能没开或者只允许加密连接而客户端用了匿名明文。也可能是防火墙挡了 4840 端口。解决先在 PLC 组态里确认 OPC UA 服务器已启用安全策略勾上“无”调试阶段确认 4840 端口通——用telnet 192.168.0.10 4840试。生产环境再上证书别一上来就搞加密调试阶段会被证书信任链折腾到怀疑人生。4.2 现象Modbus 读出来全是 0 或者明显不对的数值原因地址偏移或字节序。地址差一位是高频错误字节序错会让浮点数变成天文数字。解决先用 Modbus 调试工具比如 Modbus Poll单独验证地址确认能读到正确值再写代码。浮点数用struct.unpack两种字节序都试哪个合理用哪个。寄存器数量别超 125超了就分两次读。4.3 现象采集服务跑几天就内存暴涨然后崩原因订阅回调里不断往 List 里塞数据没设上限或者异常对象被闭包持有无法回收。解决缓存一定要设 TTL 或最大长度Redis 用LTRIM保留最近 N 条。回调函数里别做重活只写缓存。定期用memory_profiler看一眼涨得不对劲就查引用。4.4 现象浏览器页面开着数据却不动了原因WebSocket 断了没重连或者后端采集进程挂了但接口还在返回旧缓存。解决前端加心跳和重连逻辑后端接口返回里带数据时间戳前端判断超过阈值就标红提示“数据可能已过期”。别让用户看着一个不动的数字以为是设备停了。4.5 现象多个页面同时打开PLC 通信负载飙升原因每个前端连接都触发了一次独立采集。解决采集和展示必须解耦前端只读缓存。如果一定要推送用发布订阅模式一个采集源广播给所有订阅者而不是每个连接单独采。5. 进阶用 OPC UA 信息模型把“点位表”变成“设备对象”前面都是把 PLC 当寄存器堆来读点位一多ns3;sDB_Data.Temperature这种字符串满天飞维护起来是灾难。OPC UA 真正的价值在信息模型——你可以把一台设备建模成对象下面挂温度、转速、报警状态等变量前端按对象树遍历新增设备不用改代码。具体做法是在采集服务里维护一份设备描述文件YAML 或 JSON把 NodeId 和业务语义映射起来devices: - id: plc01 name: 一号注塑机 protocol: opcua endpoint: opc.tcp://192.168.0.10:4840 points: - key: temperature node: ns3;sDB_Data.Temperature unit: ℃ type: float - key: speed node: ns3;sDB_Data.Speed unit: rpm type: int采集服务读这份配置动态建订阅前端拿到的就是带单位、带语义的数据。新增设备只改配置不改代码这是 WEBscada 从“能看”到“好维护”的分水岭。验证方法也简单拿一台设备做样板把配置跑通然后复制配置改地址看能不能零代码接入第二台。如果还要改 Python说明抽象没做够。最后说个我自己的习惯每次现场调试先不写前端用 OPC UA 客户端工具和 Modbus 调试器把数据读通确认数值、单位、刷新频率都对再动代码。这个顺序能省掉至少一半的扯皮——数据不对时你能立刻分清是设备问题还是自己代码问题。WEBscada 这方向值得做但别一上来就追求大屏炫酷先把一条链路跑稳剩下的都是复制粘贴。希望帮到你。本文还有配套的精品资源点击获取