TyroneGit/NASOpenClawRunTime

Fork 0

Files

小橙 29ba1a3c83 feat(drafts): SCADA软文 · 角度C · 4平台改写（知乎/小红书/公众号/CSDN）

2026-04-20 23:54:58 +00:00

7.1 KiB

Raw Blame History

【CSDN】制造业数据孤岛怎么破？——基于 SCADA 的多协议设备接入实战笔记

来源母版：2026-04-20_master_上位机-多品牌协议整合.md 改写平台：CSDN / 博客园

正文

制造业数据孤岛怎么破？——基于 SCADA 的多协议设备接入实战笔记

背景：工厂里最贵的浪费，是设备"语言不通"

在工厂做 MES 系统集成的人，几乎都会遇到一个共同问题：设备层采集做不下去，系统层逻辑再漂亮也没用。

西门子 PLC 用 S7 协议，施耐德变频器用 Modbus，ABB 机器人用 EtherNet/IP，国产设备各有各的私有协议。一条产线上可能同时存在五六个品牌，每多一个品牌，就要多一套驱动的开发工作量。

本文记录一次真实的工厂上位机改造项目中，设备层通讯接入的全流程实践。

一、项目概况

项目要素	内容
设备规模	120+ 节点
品牌构成	西门子 S7-1200/1500、施耐德 Modbus TCP、ABB EtherNet/IP、汇川伺服等
行业	3C 电子制造
通讯调试周期	2 周
上位系统	SCADA + OEE + 生产追溯
数据指标	OEE 提升 42%，能耗下降 15%

二、协议层架构设计

2.1 常见工业协议对比

协议	典型品牌	传输层	数据模型	开发难度
西门子 S7 (ISO-on-TCP)	西门子全系列	TCP 102	Pdu 结构	中等，需处理连接管理
Modbus TCP	施耐德、ABB、汇川	TCP 502	寄存器寻址	较低，格式简单
OPC UA	主流厂商	TCP 4840	信息模型	较高，配置复杂但通用性强
EtherNet/IP	罗克韦尔	TCP 44818	CIP 报文	中等，文档质量一般
Profinet	西门子	实时以太网	IO 数据	高，实时性要求严

2.2 分层接入架构

我们采用的架构是协议网关 + 统一数据中台 + SCADA 应用层：

[设备层]  西门子 S7 / 施耐德 Modbus / ABB EtherNet/IP / 汇川
   ↓
[协议网关层]  各协议驱动模块 → 统一 JSON 数据格式
   ↓
[数据中台层]  实时数据库 + 历史存储 + 数据翻译
   ↓
[SCADA 应用层]  Dashboard / OEE 计算 / 告警策略 / 趋势分析

为什么这样分层？

核心思路是把协议差异消解在网关层，上层应用不需要关心底下跑的是什么协议。设备换了品牌，只需要换驱动模块，上层逻辑不用动。

2.3 西门子 S7 驱动要点

# S7 协议连接示例（Python snap7）
import snap7
from snap7.util import get_int, get_real

client = snap7.client.Client()
client.connect('192.168.1.10', 0, 1)  # IP, rack, slot

# 读取 DB1.DBD0 (Real 类型，4字节)
db_number = 1
start = 0
amount = 4
data = client.db_read(db_number, start, amount)
value = get_real(data, 0)  # 浮点数

# 读取 DB1.DBW2 (Int 类型，2字节)
data = client.db_read(db_number, 2, 2)
value = get_int(data, 0)  # 整数

踩坑记录：

西门子 S7 需要注意 rack 和 slot 参数，错误会导致连接建立不上
S7-1200 默认不允许 PUT/GET 访问，需要在 TIA Portal 里手动开启
大量数据点读取时建议用 BSEND/BRECV 批量方式，减少通讯开销

2.4 施耐德 Modbus TCP 驱动要点

# Modbus TCP 读取示例
from pymodbus.client import ModbusTcpClient

client = ModbusTcpClient('192.168.1.20', port=502)

# 读取保持寄存器 0-9 (Holding Registers, 地址偏移 0)
result = client.read_holding_registers(0, 10, unit=1)
registers = result.registers  # List[int]

# 解析浮点数（Modbus 浮点数格式需要注意字节顺序）
high = registers[0]
low = registers[1]
value = struct.unpack('>f', struct.pack('>HH', high, low))[0]

踩坑记录：

Modbus 寄存器地址有三种模式（0x, 4x, 3x），需要和设备厂家确认
施耐德 PLC 有时默认开启 Modbus RTU over TCP，需要注意切换
某些设备对请求间隔有要求，轮询间隔不能太短

2.5 数据建模：从设备数据到 OEE

原始设备数据需要经过翻译才能成为 OEE 计算因子：

# 设备状态映射
STATUS_MAP = {
    0: 'running',      # 运行中
    1: 'idle',         # 待机
    2: 'setup',        # 换型
    3: 'maintenance',  # 维护
    4: 'fault'         # 故障
}

# OEE 计算
def calc_oee(availability, performance, quality):
    """
    OEE = 可用率 × 表现率 × 质量率
    典型目标：85%+
    """
    return availability * performance * quality

# 示例
availability = 0.92    # 可用率 92%（故障停机少）
performance = 0.88     # 表现率 88%（速度损失少）
quality = 0.97         # 质量率 97%（不良品少）

oee = calc_oee(availability, performance, quality)
print(f"OEE: {oee:.2%}")  # 输出: OEE: 78.43%

三、2 周交付是怎么做到的

很多工厂觉得设备接入是个无底洞，其实是因为没有系统化的方法。

第一周：协议层跑通

Day 1–2：现场勘察，梳理设备清单和通讯参数
Day 3–4：完成西门子 S7 驱动调试，建立基准数据
Day 5：完成施耐德 Modbus 驱动，与 S7 数据统一建模

第二周：数据层和应用层打通

Day 8–9：ABB EtherNet/IP 接入，与已有数据模型对接
Day 10–11：OEE 计算逻辑上线，Dashboard 首版发布
Day 12–13：告警策略配置，微信/邮件推送测试
Day 14：联调测试，移交文档

关键不是加班，是每层有验收节点，发现问题当天解决，不把问题留到下周。

四、交付数据

指标	改造前	改造后
设备数据采集率	约 35%	95%+
OEE	基准值	提升 42%
综合能耗	基准值	下降 15%
故障响应时间	人工巡检，平均 >25min	< 300ms 自动告警
停线时间	基准值	减少 40%

五、经验总结

协议层是基础：协议跑通了，后面的数据建模、OEE 计算、告警策略都是顺水推舟；协议跑不通，上面全是白搭。
分层架构减少维护成本：设备品牌更换只需要换驱动层，应用层不用动。我们这个项目后来客户换了 ABB 机器人型号，只花了两天重新配置驱动，应用层零改动。
数据建模要提前：设备数据点少则几十个，多则几百个，提前定义好数据字典和翻译规则，交付时少返工。
告警要分级：把所有告警都设成最高级等于没设告警。分级推送（微信 / 短信 / 邮件）让不同角色收到不同级别的告警。

六、代码仓库

本文相关协议驱动和数据建模代码已脱敏整理，有兴趣的朋友可以联系作者了解。

作者：上海橙轩智能（Orpaon）官网：www.orpaon.com 本文数据来源：官网项目案例（已脱敏）

评论区引导

你的工厂用的是哪个品牌的 PLC？协议接入遇到过什么坑？欢迎评论区说说。

7.1 KiB Raw Blame History Unescape Escape