企业官网建设流程全解析

1. 项目背景与核心难点拆解

干工控这行的朋友应该都有过这种体验：现场那套SCADA系统用了七八年甚至十几年，PLC、仪表、DCS的数据采集、画面组态、历史趋势都跑得好好的，厂里天天靠它盯着生产。可时代变了，生产部门的要求也变了，光有画面和趋势已经不够，大家要的是异常提前预警、告警推送到手机、故障自动分级通知。这时候你回头看一眼那套老旧SCADA，发现一个很现实的问题：它压根不支持这些功能，甚至连告警推送都没有。

直接换系统？那是伤筋动骨的大工程。老旧系统的点位表动辄几千个，画面组态、历史库、操作权限这些都要迁移，停产周期根本批不下来。更麻烦的是，现场设备还在持续运行，数据链路完全不能断。

我这次做的项目就是解决这个矛盾：在老SCADA系统完全不动的前提下，无损增加告警能力。核心思路是旁路加装边缘计算网关，用一路独立的采集通道把现场设备的数据“抄”一份出来，在网关里做告警规则解析和通知推送。整个过程不碰原有的PLC程序、不改SCADA组态、不断生产，老系统那边一根线都不动。

先把这个项目的核心需求拆开看，其实就三点：

第一，采集要独立。新的告警系统不能在老SCADA的链路上做任何串联操作，否则老系统一旦出问题，责任说不清。旁路方案的本质是让告警系统和原有系统并行存在，各走各的通道。

第二，告警要实时。老旧SCADA里很多告警是靠值班人员盯着画面发现的，人总有走神的时候。边缘计算网关需要做到秒级数据采集和规则判断，第一时间把告警发出去。

第三，通知要落地。光在网关本地亮个灯没用，告警要能推到中控室的大屏、值班组长的手机、运维人员的微信/钉钉/短信。这条链路在老SCADA里是没有的，必须靠边缘网关补上。

2. 为什么选旁路架构：方案选型的取舍过程

接到这个需求时，有人可能会想直接改老SCADA的组态，加几个告警脚本进去。这事理论上可行，但实际操作中坑非常多。老SCADA多是国外品牌或者早期国产组态软件，底层是闭源的，你想在它里面加告警推送逻辑，得看它支不支持外部接口。有些老组态软件连数据库都只能导出CSV，更别提调Webhook了。

换个思路，在PLC和SCADA之间串一个网关，做数据转发，这叫做串接方案。这个方案的问题是：中间任何一个环节出故障，整条数据链路就断了，老SCADA的画面直接僵死。现场工艺人员对这种事是零容忍的，出一次问题以后就别想再碰他们的系统了。

旁路架构为什么安全？本质上是利用网络交换机的镜像口，或者加一个分路器，把现场设备和老SCADA之间的通信报文复制一份给边缘网关。网关只收不改，老系统该收什么还收什么，两边完全隔离。

打个比方，这就好比你家里原来的宽带有线网络跑得好好的，你想加一个Wi-Fi，不是去把网线剪断了重新接一个路由器，而是在光猫旁边并联一台无线路由器，原来的有线口照常工作，无线路由器单独从光猫分出来的口取信号。旁路就是这个道理，老系统和新增系统各走各的路，互不干扰。

方案选型时我还对比过另外一种方式——直接从PLC的编程口或调试口去读数据。很多PLC都带有额外的编程口或者以太网调试口，理论上可以从这里采集数据。但问题在于，很多老现场的设备通信链路是环网或者串行总线，你在设备端多挂一个采集器，会影响原有通信的时序。有些老PLC的编程口在程序运行时会锁死，外部读取会导致PLC进入调试模式，严重的话直接停机。这个风险太大，方案直接否决。

最终确定的旁路链路是：

现场PLC/仪表 <——> 工业以太网交换机 <——> 老SCADA服务器 | +————> 边缘计算网关（旁路镜像采集）

三种方案的对比，整理成表格更方便决策：

3. 边缘计算网关选型与关键参数分析

旁路方案确定后，核心任务就是选一台合适的边缘计算网关。市面上的工业边缘网关产品很多，几百到几万的都有，但真正要满足这个项目的需求，有几个参数是硬指标。

3.1 必须支持端口镜像采集

市面上有些网关标称支持Modbus TCP采集，但那是主动去轮询设备。旁路场景下，网关更多是被动接收交换机镜像过来的报文。这里要区分两种工作模式：

• 主动轮询模式：网关作为Modbus主站，主动去读PLC的寄存器。这种模式不需要镜像口，但会占用PLC的通信带宽，而且需要在网关里配置每个点位地址。
• 被动镜像模式：网关监听交换机镜像口的数据包，从SCADA和PLC的通信报文里解析出点位数据。这种模式完全不占用PLC通信资源，但对网关的协议解析能力要求高。

我这次选的是同时支持两种模式的网关，但实际部署用的是被动镜像模式。原因很简单：老SCADA每隔几百毫秒本来就在轮询PLC，这些报文里已经包含了我们需要的所有点位数据，网关在旁边“监听”就行，完全不需要额外通信开销。

3.2 协议解析范围要匹配现场

老旧系统的通信协议五花八门，Modbus RTU、Modbus TCP是主流，但也可能碰到三菱MC协议、西门子S7协议、欧姆龙FINS这些。选网关前，先弄清楚现场PLC和SCADA之间用的是哪种协议。

我这个项目现场是老旧的Modbus TCP协议，网关解析起来没什么压力。如果你现场是西门子的S7协议，注意要选支持S7-300/400/1200/1500全系列解析的网关，而且解析深度要够，能直接读到DB块的数据。

3.3 算力和内存要求

边缘计算网关毕竟不是普通的路由器，它要承担告警规则判断和告警消息推送的工作。现场点位如果只有三五百个，双核处理器加256MB内存就够用了。如果点位超过两千个，建议上四核加1GB内存的配置，否则在高频率数据刷新下，网关的CPU占用率会飙升，导致告警判断延迟。

3.4 通信接口要够用

边缘计算网关至少要具备以下接口：

• 2个以上千兆以太网口（一个接镜像口，一个接上层网络）
• 支持PoE供电选装（现场取电方便的话更好）
• RS485串口（备用，有些仪表只有串口输出）
• 4G/5G模块插槽（如果告警要通过公网推送，这个就很有必要）

针对这个项目的选型，实际参数配置是这样的：

4. 核心实现：从镜像口配置到告警上线的完整流程

这部分是整个项目的实操核心。从现场勘察到告警真正推送到手机，我按步骤把关键环节写透。

4.1 交换机镜像口配置

旁路方案的第一个关键步骤，是把交换机上连接老SCADA服务器的那个端口配置成镜像源端口，然后指定一个空闲端口作为镜像目的端口，连接到边缘计算网关。

不同品牌的交换机配置命令差异比较大，以最常见的H3C和Cisco为例：

H3C交换机配置命令：

[H3C] mirroring-group 1 local [H3C] mirroring-group 1 mirroring-port GigabitEthernet 1/0/1 both [H3C] mirroring-group 1 monitor-port GigabitEthernet 1/0/2

Cisco交换机配置命令：

Switch(config)# monitor session 1 source interface GigabitEthernet 0/1 both Switch(config)# monitor session 1 destination interface GigabitEthernet 0/2

这里要特别注意：镜像方向一定选both，就是双向流量都要镜像。因为SCADA读取PLC数据是发送读请求报文，PLC回复的报文里才带着实际数据值，两个方向都需要解析。

如果现场交换机不支持端口镜像，比如一些老的傻瓜交换机，那还有一个备选方案：加一个分路器（TAP）。分路器纯物理复制信号，不需要配置，插上就能用，稳定性也高，但需要额外采购设备。有条件的情况下，我还是推荐用镜像口，少一个物理节点少一个故障点。

4.2 网关网络参数规划

接下来给边缘计算网关规划IP。这里有个经验之谈：网关的IP千万不要和老SCADA、PLC在同一网段冲突，哪怕你觉得不会冲突也不要。万一某天有人手动改了一台电脑的IP，正好撞上车位，那现场就热闹了。

建议规划方式：

镜像口配成同网段是为了让网关能直接解析二层的Modbus TCP报文，这里不需要网关主动发包，所以不会和现有设备产生冲突。如果交换机上开了端口隔离或者VLAN策略，要确认镜像口能收到数据。

4.3 点位表映射与告警规则配置

网关拿到数据后，第一件事是把原始报文里的寄存器地址映射成有意义的业务点。这个工作在网关的Web管理界面里完成，有些网关也支持导入Excel点位表，大批量点位还是Excel导入靠谱。

比如现场有一台空压机，它的运行状态存在PLC的保持寄存器40001地址中，0表示停机，1表示运行；排气温度存在40002地址，数值单位是摄氏度。在网关里配置点位：

配置告警规则时，有几个细节值得注意。

死区和回差值必须设置。Modbus TCP的轮询频率高，数据很容易出现瞬时波动。比如压力值正常在0.6MPa，如果告警阈值设成低于0.5MPa就报警，那么系统加压过程中的瞬时抖动就可能导致误报。这时候给告警规则加一个回差值，比如触发值为0.5MPa，恢复值为0.55MPa，可以有效过滤抖动。边缘计算网关的优势就在这里，老SCADA的告警逻辑无法现场修改，而网关里的规则随时可以调。

告警分级和通知策略要结合现场。我一般把告警分成两级：一是设备级告警，比如PLC通信中断、设备停机、温度超限，这类告警直接推送给值班长和维修工；二是系统级告警，比如SCADA服务器CPU过高、控制器故障，这类告警推送给中控室主管和系统管理员。不同级别对应不同的通知渠道，避免信息轰炸淹没关键告警。

4.4 告警通知渠道打通

告警通知是边缘计算网关最核心的附加值。老SCADA没有这个能力，而网关可以做到告警消息秒级推送。通知渠道的配置方式有几种，这里按优先级排序说明。

Webhook推送到钉钉或企业微信。这个是目前最常用、成本最低的方案。在钉钉群里添加一个自定义机器人，拿到Webhook地址后，在网关里填上去，然后在告警规则里绑定“发送到钉钉群”动作。网关内部会把告警信息拼装成JSON格式，通过HTTP POST请求送过去。

钉钉机器人的Webhook地址格式是：

https://oapi.dingtalk.com/robot/send?access_token=xxxxxxxxxxxxxx

网关侧配置告警推送内容模板，发出来的消息能带点位名称、当前值、触发时间、告警等级这些信息。可以配置一个链接触发器，实现首报和恢复通知的联动。

MQTT推送到自建告警平台。如果厂里已经有物联网平台或者数据中台，网关支持MQTT协议就非常方便。网关作为MQTT客户端，把告警消息发布到指定Topic，由平台统一汇总展示。这种方式的好处是告警数据能沉淀下来，做后续分析。

短信网关推送。有些无人值守站场，值班人员不一定在电脑旁边，短信是最可靠的兜底方案。边缘网关支持插4G模块，并内置短信发送接口，告警触发时直接把短信发到指定手机号。注意短信费用问题，一般只对最高级别的告警开短信通知。

结合前面提到的Zabbix告警实践。现在很多工厂的IT运维组都用Zabbix监控工业主机网络设备，告警通知走钉钉或者企业微信Webhook已经很成熟了。边缘计算网关把SCADA设备层的告警也接入同一条Webhook链路，这样中控室和IT运维在一个群里就能同时看到设备告警和IT基础设施告警，避免信息孤岛。

4.5 告警消息的确认与恢复机制

老SCADA做告警，值班人员可以在操作员站上确认消音。旁路加装的边缘计算网关也要考虑这个问题，不然告警只能发出去，无法确认，时间长了会被当成“狼来了”。

网关的告警引擎支持以下状态流转：

• 触发态：告警条件满足，立即推送首报通知
• 保持态：告警避免重复推送，内部进行去抖
• 恢复态：采集值恢复到正常范围，推送恢复通知
• 确认态：人工在网关Web页面或第三方平台确认告警

这里面最关键的是告警去抖逻辑。比如温度在95℃附近来回跳，如果不加去抖，网关会反复发送几十条告警，把钉钉群直接刷屏。去抖时间的设置建议按告警类型区分：对直接停机的联锁信号，去抖可以设短一点，比如5秒；对温度、压力这类缓变量，去抖设30~60秒更合理。

5. 老SCADA和PLC的区别与关系：给非自动化背景读者的知识铺垫

这里单独写一节，因为很多搞IT或者搞管理的朋友看这类项目时，经常会混淆几个概念。简单说清楚SCADA、HMI、PLC分别是什么角色。

PLC是可编程逻辑控制器，本质是现场设备的大脑。它直接控制电机启停、阀门开闭、温度调节这些物理动作，根据传感器输入信号执行程序逻辑。PLC输出端接的可能是接触器、变频器、电磁阀，它运行在设备层。

HMI是人机界面，本质是操作面板。传统意义上，HMI就是触摸屏或工控机上显示的画面，操作员通过它按按钮、看数据、确认报警。HMI直接和PLC通信，一般部署在设备旁边。

SCADA是数据采集与监控系统，本质是工厂级的中枢。它把分布在车间甚至厂区各处的PLC、仪表、DCS的数据汇总到中控室，在同一套画面上统一展示、趋势分析、集中告警、历史归档。SCADA通常跑在服务器上，操作员站通过网络访问。

用一个通俗的类比：

• PLC是现场员工，负责干活
• HMI是贴在工位上的操作说明书和按钮板，员工旁边就有一份
• SCADA是车间主任的控制室，能看到全车间所有工位的状态，哪个工位出问题了它最清楚

本项目加装边缘计算网关，就是在车间主任的会议室里额外放了一套独立的监督设备，它自己装了一套传感器（镜像口）去监听各个工位的情况，发现异常就绕过主任直接打电话给维修队。好处是主任原来的工作不受打扰，维修队也能第一时间收到消息。

这个背景对非自动化专业的同事、领导汇报项目思路时特别有用，建议收藏备用。

6. 旁路加装实施过程中的常见问题与排查技巧

老系统加装旁路，最难的不是技术，而是过程中各种意想不到的现场问题。我把这次实施过程中遇到的一些典型问题和排查方法整理出来，供同行参考。

6.1 镜像口收不到数据

这是实施第一天最容易遇到的问题。交换机镜像口配置好了，网线也插上了，但网关管理界面里显示数据流量为0。

排查顺序：先看网口物理状态，灯亮不亮，网线是不是损坏；再登录交换机看镜像配置是否生效，很多交换机配置完镜像口后需要用display mirroring-group all确认状态；接下来抓包，在网关侧用Wireshark抓一下镜像口进来的报文，看有没有数据帧。

如果交换机配置没问题但依然收不到数据，要重点检查是不是交换机把镜像口设成了单方向镜像。有些工程师图省事只镜像了rx或tx单方向，而Modbus TCP的读响应数据是在另一个方向，漏了就解析不出数值。确认是both双向镜像。

另外，网管型交换机有些默认开了流量抑制（storm-control），异常情况下会丢弃镜像口的广播包，这种时候需要临时关掉抑制策略试一下。

6.2 网关解析出的数据和老SCADA画面对不上

数据能收到了，但网关侧看到的值和老SCADA操作站画面上的值不一致。这种情况通常是寄存器地址对应错了。老SCADA的点表地址可能做了偏移，比如从40001开始，对应Modbus协议地址是0x0000，有些网关的地址填写习惯不一样，填40001还是0x0000得确认清楚。

还有一种是字节顺序问题。Modbus报文里一个16位寄存器的高低位顺序，不同PLC厂家定义不同。同一个寄存器，高位在前和低位在前解析出来的值完全不一样。遇到数值特别离谱、有明显倍数关系（比如差256倍的）的情况，基本就是字节序设置错了。在网关里把点的字节序从AB改成BA再试一下。

6.3 告警误报过多

告警上线后，钉钉群一晚上被刷屏，这是很常见的现象。问题基本出在告警阈值和回差设置不合理。

有一个原则：阈值不要设置在正常值的波动范围内。比如排气温度正常运行在85℃，波动范围可能达到±2℃，你设88℃报警就很容易误报，至少留出5~8℃的余量再设告警线。另外，回差值建议设置为阈值的三分之一以上。阈值100℃触发，回差至少设3℃，恢复值97℃，这样避免温度在阈值边缘震荡时反复报警。

还有一种误报来源是PLC通信瞬间中断。Modbus TCP是TCP连接，当PLC或者交换机的某个端口闪断重连，网关会解析到一堆乱码或者超时，误判为设备故障。这种需要在网关里给通信状态做一个连续判定次数，比如连续3次采集失败才算通信故障，避免偶发性的网络闪断直接报故障。

6.4 旁路网关自身故障了会不会影响老系统

这是工艺方最关心的问题，也是这个方案能实施成功的关键。旁路架构从物理链路上就保证了隔离：网关的网线只接交换机镜像口，交换机做镜像只是把报文复制了一份出来，不会对原有转发造成影响。即使网关断电、网线拔掉、甚至交换机镜像口物理损坏，老SCADA服务器到PLC的数据链路完全不受影响。

不过为了保险起见，我还做了一个冗余措施：在网关的串口调试口接了一个断电短信报警模块。一旦网关断电，无论是因为停电还是有人误拔电源，第一时间给运维人员发短信，不用等巡检发现问题。

6.5 老旧系统兼容性排查

有些老SCADA系统用的是非标准的Modbus实现，比如报文里附带了一些特殊填充字节，或者寄存器寻址不是标准线性布局。这类问题只能在调试阶段逐一确认。每添加一个点位，就对照老SCADA画面上的实际值去反查网关解析结果。点位少的现场可能一两天就能核对完，点位上千的现场建议分区域逐步上线，不要一次性把两千个点全配上。

7. 项目落地后的效果与扩展可能性

旁路加装边缘计算网关完成后，这套系统已经连续运行了几个季度，效果符合预期。告警从原来的“人盯画面”变成了“系统主动推送”，告警响应时间从分钟级压缩到秒级。下面是几个实际场景：

场景一：深夜空压机排气温度异常升高，值班人员原本要靠每小时的巡检记录才能发现。现在温度超过95℃的告警阈值后，网关10秒内就把告警消息推送到维修班的钉钉群，维修人员起床查看趋势图，提前做好维修准备，减少了设备损坏的风险。

场景二：某台老PLC偶尔发生通信闪断，之前这种故障SCADA画面上只会闪一下红色，等人员注意到了可能已经过了半小时。现在网关针对通信状态单独设置告警规则，连续3次失败才报故障，既过滤了抖动，又能让运维第一时间得知PLC通信不稳定，提前检查网线接头和交换机端口。

做完这个项目，我结合实际经验谈谈扩展可能性。

边缘计算网关只是旁路采集的第一步。数据既然已经通过镜像口拿到了，它能做的事情远不止告警一件事。网关内置的存储空间可以保留一定时间的历史数据，未来想上数据分析、设备预测性维护，甚至做一套独立于老SCADA的Web可视化大屏，都可以在这个边缘网关的基础上扩展。数据出口也可以直接给厂里的MES、ERP提供设备状态数据，打通生产管理层和现场控制层的信息通道。

如果现场未来计划对老SCADA系统进行升级，这套旁路网关还能作为一个平滑过渡的桥梁。新老系统并行运行期间，告警、数据采集都走边缘网关，等新系统稳定后再切换过来，生产数据从始至终不断层。

8. 最后分享一点个人体会

做完这个项目，我最大的感受是：老的SCADA系统不一定就要推翻重来，“无损增加新能力”这个思路在工业现场改造中很有价值。很多被淘汰的系统，核心功能其实依然可靠，只是没有跟上智能化、移动化的需求。旁路加装边缘计算网关，让老系统继续干它擅长的事，同时把新能力以独立模块的形式叠加进去，既控制了风险，又快速满足了生产需求。

实际操作中，还要注意和现场技术人员打交道的方式。改造前做一次充分的技术交底是值得的，把旁路架构的隔离原理讲清楚，让工艺和自控团队放心：老系统不会被影响、告警规则可以随时调整。技术方案再好，人不支持也推不动，这一点在老旧系统改造项目中尤为重要。

如果你的现场也有类似的老SCADA系统，也有“想加告警但不敢动老系统”的顾虑，不妨参考这套旁路加装边缘计算网关的思路。投资不大，风险极低，实施周期短，效果却立竿见影。