制造业SCADA项目POC测试清单：我踩过的坑，你可以直接跳过
去年帮一个做食品加工的朋友选SCADA系统，前前后后折腾了三个月。供应商PPT做得天花乱坠，Demo演示行云流水，结果真正上了产线才发现一堆问题——报警延迟、协议不兼容、画面卡顿、数据丢点……
后来复盘，核心问题就一个：POC阶段测得太粗了。
很多制造企业选SCADA，要么完全不做POC，听完演示就签合同；要么做了POC但测试项太随意，就看看画面好不好看、能不能连上PLC，完全没有覆盖到真实生产场景下的关键指标。
这篇文章，我把自己这两年参与过的几个SCADA选型项目中积累的POC测试清单整理出来，尽量做到拿来就能用。不管你是甲方的IT负责人、自动化工程师，还是乙方的售前，都可以参考。
一、POC之前：先把需求锚点定清楚
很多人一上来就开始测功能，这是不对的。POC不是功能演示，是验证系统在你的真实场景下能不能跑得动、跑得稳。
所以第一步，先回答这几个问题：
-
你的核心监控场景是什么？ 是产线设备联动控制，还是环境参数监测，还是能耗管理？不同场景对实时性、数据量、报警逻辑的要求完全不同。
-
你的设备底层长什么样？ PLC品牌是西门子为主还是多品牌混合？现场总线用的Modbus、Profinet还是OPC UA？有没有老旧设备需要兼容？
-
你的"不可妥协项"是什么？ 比如食品行业可能是审计追溯，化工行业可能是报警响应时间，离散制造可能是多产线并发性能。
把这些想清楚，再列POC测试项，才不会"测了一堆但没测到点上"。
二、POC测试清单（完整版）
下面这份清单分成7个大类，每个类别下面有具体的测试项和判断标准。建议打印出来，POC现场逐项打勾。
第1类：协议兼容性与数据采集
这是最基础也最容易翻车的环节。
- PLC连接测试：用你产线上真实的PLC（不是供应商自带的Demo PLC），测试能否正常建立通信。重点关注连接建立时间和断线重连机制。
- 多协议并发：如果你的现场同时存在Modbus TCP、OPC UA、S7等多种协议，要同时连接测试，看系统在多协议并发下是否稳定。
- 老旧设备兼容：很多工厂都有用了十几年的老PLC或仪表，协议版本老旧。这个必须在POC阶段验证，别等上线了才发现连不上。
- 数据采集精度：对比SCADA采集到的数值和PLC/仪表端的原始数值，误差是否在可接受范围内。特别注意浮点数精度问题。
- 采集频率上限：把采集周期调到你实际需要的最小值（比如100ms），观察系统CPU和内存占用，以及是否出现数据丢点。
踩坑经验：有一次我们测一个国产组态软件，Demo环境下OPC UA连接完全没问题，但换成客户现场的Beckhoff PLC后，死活连不上。最后发现是OPC UA安全策略配置不兼容。所以一定要用真实设备测。
第2类：实时性与报警响应
这是SCADA的命脉，尤其是涉及安全生产的场景。
- 端到端报警延迟：从PLC触发报警信号，到SCADA画面上弹出报警提示，测量这个完整链路的延迟。建议测10次取平均值。
- 参考标准：一般工业场景 < 2秒，关键安全场景 < 500ms
- 报警风暴测试：同时触发50-100个报警，观察系统是否卡顿、报警是否丢失、排序是否正确。
- 报警联动动作：测试报警触发后的联动功能——声光提醒、短信/邮件通知、自动控制指令下发，每个环节都要验证。
- 画面刷新率：在监控画面上放置200-500个动态数据点，观察画面刷新是否流畅，有没有明显的"跳变"或"卡帧"。
- 远程控制延迟：如果需要远程下发控制指令（如启停设备、调节参数），测量从操作到设备响应的延迟。
踩坑经验：报警风暴是很多系统的软肋。我见过一个项目，正常情况下报警响应很快，但一旦同时触发30个以上报警，系统直接卡死了。这种场景在实际生产中并不罕见——比如一个总线故障可能导致几十个点同时报警。
第3类：性能与承载能力
别只测"能不能用"，要测"能用多久、能扛多大"。
- 标签容量测试：按你实际的点数规模（建议按未来3年规划的1.5倍）配置标签，观察系统性能变化。
- 1000点以下：基本所有系统都能扛
- 1000-5000点：开始拉开差距
- 5000-20000点：真正考验系统架构
- 历史数据写入性能：模拟每秒写入500-1000条历史记录，持续运行24小时，观察数据库增长速度和查询响应时间。
- 历史数据查询性能：在积累了一定量的历史数据后（比如模拟1个月的数据量），测试趋势图加载速度和报表生成时间。
- 多客户端并发：同时打开5-10个监控客户端，观察服务器负载和各客户端的响应速度。
- 72小时稳定性测试：这个很关键。让系统在接近真实负载下连续运行72小时，观察是否有内存泄漏、服务崩溃、数据丢失等问题。
踩坑经验：72小时测试真的不能省。我们有一个项目，系统前两天跑得好好的，第三天凌晨服务自动崩了，原因是内存泄漏。如果POC只测了半天，这个问题根本发现不了。
第4类：画面组态与易用性
这部分不只是"好不好看"的问题，更关系到后期的开发效率和维护成本。
- 组态效率：让你的工程师（不是供应商的人）独立完成一个典型监控画面的搭建，记录所需时间和遇到的问题。
- 组件丰富度：检查是否有你行业需要的专业组件（阀门、泵、管道、仪表盘等），还是需要大量自定义开发。
- 动画与交互：测试组件的动画效果（颜色变化、旋转、流动等）是否流畅，交互逻辑（点击弹窗、下钻跳转等）是否好用。
- 多分辨率适配：如果你有大屏、工控机、平板等多种终端，测试同一画面在不同分辨率下的显示效果。
- 导入导出能力：能否导入CAD/Visio图纸？能否导出为HTML/图片？这些在实际项目中经常用到。
第5类：数据对接与集成能力
SCADA不是孤岛，它需要和你的其他系统打通。
- 数据库对接：测试与你现有数据库（MySQL、PostgreSQL、SQL Server等）的连接和读写性能。
- API接口：是否提供REST API或WebSocket接口？能否方便地被MES、ERP等上层系统调用？
- 数据源类型：除了PLC直连，是否支持MQTT、HTTP、Kafka等数据源？这对物联网场景很重要。
- 数据导出：历史数据能否方便地导出为Excel、CSV？报表能否自动生成和推送？
- 单点登录：如果你的企业有统一认证系统（LDAP、AD等），测试能否对接。
第6类：安全与合规
越来越多的制造企业开始重视这一块，尤其是涉及等保要求的项目。
- 权限管理：是否支持细粒度的角色权限控制？比如操作员只能看、班长能确认报警、管理员能改参数。
- 操作审计：所有操作（登录、参数修改、报警确认、控制指令）是否有完整的日志记录，且不可篡改。
- 数据传输加密：SCADA服务器与客户端之间、与PLC之间的通信是否支持加密（TLS/SSL）。
- 备份与恢复：测试系统配置和历史数据的备份恢复流程，记录恢复所需时间。
- 冗余切换：如果系统支持双机热备，测试主服务器故障时的自动切换时间和数据连续性。
第7类：部署与运维
这部分决定了系统上线后你的运维压力。
- 安装部署时间：从零开始，完成服务器端+客户端的完整部署需要多长时间？
- 国产化适配：如果有国产化要求，测试在国产操作系统（麒麟、统信等）和国产数据库（达梦、人大金仓等）上的运行情况。
- 升级机制：系统升级是否需要停机？升级后原有配置和数据是否完整保留？
- 技术支持响应：在POC期间故意提几个技术问题，观察供应商的响应速度和解决问题的能力。这是对未来售后服务的预演。
- 文档与社区：产品文档是否完善？是否有活跃的技术社区或论坛？遇到问题能不能自己查到解决方案？
三、POC评分建议
光测不够，还得有量化的评分标准，不然最后几个系统比下来，全凭感觉拍板。
我的做法是给每个大类设一个权重，然后每个测试项打1-5分：
| 测试类别 | 建议权重 | 说明 |
|---|---|---|
| 协议兼容性与数据采集 | 20% | 基础中的基础，连不上一切白搭 |
| 实时性与报警响应 | 20% | 安全生产的底线 |
| 性能与承载能力 | 15% | 决定系统能跑多远 |
| 画面组态与易用性 | 15% | 影响开发效率和用户体验 |
| 数据对接与集成 | 10% | 决定系统的扩展天花板 |
| 安全与合规 | 10% | 等保和审计的硬要求 |
| 部署与运维 | 10% | 影响长期运维成本 |
权重可以根据你的行业和项目特点调整。比如化工行业可以把"实时性与报警响应"调到25-30%，离散制造可以把"画面组态与易用性"调高一些。
四、几个容易被忽略的POC细节
最后补充几个我觉得很重要但经常被忽略的点：
1. 一定要用你自己的工程师来操作
供应商的工程师对自家产品了如指掌，他们演示当然丝滑。但你的工程师才是未来真正使用这个系统的人。让他们在POC阶段就上手操作，能暴露出很多易用性问题。
2. 测试环境要尽量接近真实环境
别在供应商的实验室里测完就算了。最好把系统搬到你的工厂里，连上你的PLC、走你的网络、用你的数据库。环境差异是很多"POC通过但上线翻车"的根本原因。
3. 关注"第二天"的问题
很多系统第一天跑得很好，问题出在持续运行之后。所以72小时稳定性测试不能省，数据积累后的查询性能也要测。
4. 把供应商的技术支持也纳入评估
POC期间你遇到的问题，供应商多久响应？是远程就能解决还是必须现场支持？解决问题的态度和能力如何？这些都是未来合作体验的预演。
5. 别忘了算总账
软件授权只是冰山一角。硬件投入、实施开发、培训、年度维护、未来扩容——把5年的总拥有成本（TCO）算清楚，才能做出理性的决策。有些系统看着便宜，但后期每加一个功能模块都要额外付费，5年算下来反而更贵。
写在最后
SCADA选型是个技术活，也是个体力活。但只要POC阶段测得扎实，后面的路就会顺很多。
这份清单不一定完美，每个行业、每个项目都有自己的特殊需求。但至少它能帮你建立一个系统化的测试框架，避免"拍脑袋选型"的尴尬。
如果你正在做SCADA选型，建议把这份清单转给你的项目团队，大家一起过一遍，根据自己的实际情况增删调整。
有什么问题或者补充，欢迎评论区交流。选型路上，少踩一个坑就是赚到。
