在中小型制造企业的数字化转型过程中，商业SCADA软件（如WinCC、iFIX）高昂的授权费用往往是最大的障碍。基于C# WinForm自研轻量级上位机监控系统，成为许多工厂实现数据可视化与设备监控的高性价比选择。本文将从实际项目经验出发，梳理基于C#的SCADA上位机开发全流程。
一、系统架构设计原则
一个可稳定运行的上位机系统，架构设计需贯彻三个原则：分层解耦、容错优先、运维友好。分层解耦是指将通信层、业务逻辑层和UI表现层严格分离。通信层负责与PLC、仪器仪表等下位设备的数据交互，采用独立的线程池管理每个设备的通信链路；业务逻辑层负责数据校验、量程转换、报警判定和存储调度；UI层仅负责数据展示和用户交互，不直接处理通信逻辑。
容错优先意味着系统必须容忍现场网络波动和设备异常。当某台PLC通信中断时，该设备的数据显示区域应自动变为灰色并标记"离线"，而非弹出异常对话框阻塞整个系统。所有通信异常都应记录到日志文件，并在通信恢复后自动重连。
运维友好的核心是配置与程序分离。将设备通信参数（IP地址、端口号、寄存器地址表）、报警阈值、曲线显示范围等可变参数全部放入XML或JSON配置文件，使现场运维人员无需重新编译程序即可调整系统行为。
二、多协议数据采集模块实现
在工业现场，上位机往往需要同时对接多种协议的设备。最常见的是Modbus TCP协议，通过C#的Socket类建立TCP连接后，按照Modbus协议帧格式组装请求报文，发送至PLC的502端口，接收响应后解析出寄存器数值。实现时需注意多线程安全：每个通信通道使用独立的Socket对象和接收缓冲区，通过lock锁保护共享数据字典的写入。
除Modbus TCP外，西门子PLC的S7协议（通过S7.Net开源库）和三菱PLC的MC协议也常被集成。设计时建议抽象统一的IDeviceDriver接口，包含Connect、Read、Write和Disconnect方法。每种PLC协议实现该接口的具体驱动类，业务层通过工厂模式按配置创建设备驱动实例，这样新增协议支持时无需修改上层代码。
对于模拟量信号的采集，还需要在驱动层之上增加一层"工程值转换"。传感器的4-20mA信号经PLC模数转换后是一个0至27648的原始值，需根据传感器的量程（如0至10MPa）线性换算为实际工程值。这些换算系数应存储在配置文件中，便于不同量程传感器的快速适配。
三、实时曲线与可视化控件
实时趋势曲线是SCADA系统的核心可视化元素。在C# WinForm中，推荐使用OxyPlot开源图表库而非Chart控件，因为OxyPlot的渲染性能更高，支持数万数据点的流畅绘制。将实时采集的数据追加到OxyPlot的LineSeries中，设置合适的X轴时间窗口（如最近5分钟），即可实现滚动趋势显示。
历史曲线查询则需要从数据库中按时间范围检索数据。SQLite是轻量级SCADA的理想嵌入式数据库选择，无需安装数据库服务，零配置即可运行。数据存储时按分钟级粒度采样，24小时的数据量约5MB，一年约1.8GB，完全在SQLite的性能舒适区内。查询时使用索引优化过的timestamp字段，500万条记录中检索某一天的数据耗时不超过200毫秒。
四、报警管理与联动机制
报警模块是衡量上位机系统实用性的关键指标。标准报警管理应包含四级报警（低低、低、高、高高），每个报警点可独立设定阈值和延时确认时间。延时确认是指当变量值瞬间越过阈值后需持续超过设定时间（如3秒）才触发报警，这样可有效过滤信号抖动导致的误报警。
报警联动是更高的要求。当触发某报警后，系统除了在界面上弹出红色闪烁的报警条外，还应自动执行预设的联动动作：点亮现场的声光报警器（通过PLC的DO点输出）、向指定手机号发送短信通知（通过短信猫或阿里云短信API）、以及将该时刻前后各10秒的所有变量数据快照写入报警追溯文件。
五、上线前关键测试
开发完成后，上线前务必进行三项关键测试。第一是长时间稳定性测试：让系统连续运行168小时（7天），监控内存占用是否持续增长（内存泄漏检查）和CPU占用是否异常。第二是网络断线恢复测试：人为拔掉网线30秒后插回，验证系统能否在5秒内自动恢复通信。第三是并发压力测试：模拟50个以上的设备同时高频通信的场景，检查数据是否有丢失或乱序。
唯有通过这三项测试的上位机系统，才具备在真实工业现场7x24小时稳定运行的能力。
