被忽略的工业软件：自动控制的核心与工程实践反思

1. 被忽略的工业软件：一个老生常谈却始终没解决的老问题

干了十几年自动化，从最早的继电器柜子到后来的DCS、PLC、PC控制，我最大的感受就是：硬件越来越花哨，软件却始终是那个拖后腿的短板。彭瑜老师那篇《漫谈自动控制与被忽略的工业软件》我反复读了好几遍，每读一次都觉得扎心。他讲的核心其实就一句话——自动控制这门学科，骨子里是软件驱动的，但工业界从上到下，从教育到工程实践，都把软件当成了硬件的附属品。

你去看任何一个自动化展，展台上摆的都是伺服电机、变频器、IO模块、机械臂，参数表上写的是响应时间、转矩、防护等级。软件呢？要么藏在触摸屏后面，要么被压缩成一张光盘塞在包装盒里。但真正在现场干活的人都知道，一个项目能不能按时交付、能不能稳定运行，八成取决于软件——PLC程序的结构、SCADA的组态逻辑、PC控制里的任务调度、通信协议的匹配。硬件选型错了顶多是多花点钱，软件架构错了那就是无底洞。

这篇文章我想从一线从业者的角度，把彭瑜老师提到的“被忽略的工业软件”这个命题拆开揉碎，结合自动控制的核心原理、PLC与PC控制的路线之争、IEC 61131标准的实际落地情况，以及当下工业软件在工程实践中的真实处境，聊一聊为什么我们总是低估软件的价值，以及在实际项目中怎么把这块短板补上。不管你是刚入行的PLC编程新手，还是做了多年系统集成的老手，都能从中找到一些共鸣和可操作的东西。

2. 自动控制与工业软件的本质关系拆解

2.1 自动控制的核心从来都是算法与逻辑

很多人学自动控制原理，上来就是传递函数、根轨迹、频域分析，胡寿松那本教材翻来覆去地做题。这些当然重要，但到了工业现场你会发现，真正决定系统性能的往往不是PID参数整定得多精妙，而是软件架构能不能支撑起实时性、确定性和可维护性。

举个例子，一个冷库监控系统，控制逻辑本身很简单：温度高于上限启动压缩机，低于下限停机，加上化霜逻辑和报警。但如果你用PLC梯形图写，几百个梯级堆在一起，没有功能块划分，没有状态机设计，后期改一个化霜条件就得翻遍整个程序。这就是典型的“控制理论没问题，软件工程出了问题”。自动控制原理教你的是“怎么算”，工业软件要解决的是“怎么组织这些算出来的东西”。

彭瑜老师反复强调一个观点：自动控制学科的本质是信息处理。传感器采集的是信息，控制器处理的是信息，执行器输出的是信息。硬件只是信息的载体，软件才是信息的灵魂。但我们的教育体系把自动控制归到了电气工程下面，课程设置偏硬件、偏电路、偏电机，软件工程、数据结构、操作系统这些课要么不开，要么敷衍了事。结果就是培养出来的工程师，画电路图很熟练，写状态机就头疼。

2.2 工业软件为什么总是被当成“附属品”

这个问题我琢磨了很久，觉得根源在于工业软件的交付形态太隐蔽了。你买一台变频器，能看到电路板、散热片、接线端子，觉得钱花得值。你买一套SCADA软件，拿到的是一个授权文件和一个安装包，心里就犯嘀咕：这玩意儿凭什么卖这么贵？

但实际项目里，SCADA组态的工作量往往比硬件接线大得多。一个中等规模的污水处理厂，上位机画面可能上百张，每张画面上的阀门、泵、仪表都要跟PLC变量一一对应，还要做报警、趋势、报表、权限管理。这些工作全是软件层面的，但甲方在验收的时候，看到的是画面好不好看、操作顺不顺手，根本不会去想背后有多少逻辑在支撑。

更关键的是，工业软件的复用性远低于硬件。一个西门子S7-1500的CPU，换个项目还能用；但一个项目的PLC程序，换个工艺就得重写。这种“一次性”的特征让很多人觉得软件不值钱，因为没法标准化、没法批量生产。但恰恰是这种非标特性，才更需要工程化的方法来管理——模块化设计、版本控制、代码审查、自动化测试，这些软件工程的基本功，在工业自动化领域几乎是空白。

2.3 IEC 61131标准的理想与现实

IEC 61131标准出来的时候，大家都觉得救星来了。五种编程语言——梯形图、功能块图、顺序功能图、结构化文本、指令表——总有一款适合你。但实际用起来，情况完全不是那么回事。

梯形图（LD）确实是电气工程师的舒适区，画起来跟继电器逻辑图一模一样，上手快。但梯形图写复杂算法就是灾难，一个矩阵运算能用几百个梯级堆出来，可读性极差。结构化文本（ST）像Pascal，写算法很舒服，但很多老电工看不懂。功能块图（FBD）适合做信号流处理，顺序功能图（SFC）适合做流程控制，但真正在项目里把这五种语言混着用的团队少之又少。

我见过太多项目，不管什么逻辑全用梯形图怼，因为“别人都这么写”。结果就是程序越写越长，扫描周期越来越慢，最后连在线监控都卡。IEC 61131给了你工具箱，但没人教你怎么选工具。这背后还是那个老问题：工业软件的教育和培训，远远落后于硬件。

3. PLC与PC控制：两条路线的真实较量

3.1 PLC的护城河到底在哪里

PLC能统治工业控制几十年，靠的不是算力，而是确定性和可靠性。一个西门子S7-1200，扫描周期稳定在几毫秒，抖动极小，因为它的操作系统是专门为实时控制设计的，任务调度简单粗暴但有效。你让它跑个PID，它不会因为后台在更新系统而延迟响应。

但PLC的短板也很明显：算力有限、内存有限、开放性差。你想在PLC上跑个复杂的模型预测控制，或者做个数据分析和机器学习，基本不可能。西门子的S7-1500算是性能很强的了，但跟一台普通工控机比，算力还是差了几个数量级。而且PLC的编程环境是封闭的，博途、GX Works、Sysmac Studio，各玩各的，代码复用和版本管理都很原始。

3.2 PC控制的诱惑与陷阱

PC控制（或者说软PLC）的思路很直接：既然工控机算力强、开放性好、能用高级语言，为什么不用PC来做控制？倍福的TwinCAT就是典型代表，把Windows系统改造一下，加个实时扩展，就能跑PLC程序，还能同时跑视觉、数据库、通信中间件。

听起来很美，但实际用起来坑不少。首先是实时性问题，Windows不是实时操作系统，TwinCAT虽然做了实时扩展，但如果你在同一个系统上跑了个吃CPU的桌面程序，实时任务还是可能被影响。其次是稳定性问题，PLC可以七年不关机，工控机呢？硬盘坏了、系统崩了、病毒入侵了，都是事。最后是维护门槛，PLC坏了电工能换，工控机坏了得找IT。

我个人的经验是：高速、高精度的运动控制，老老实实用PLC或专用控制器；复杂算法、数据密集、需要跟IT系统深度集成的场景，考虑PC控制。但不管选哪条路，软件架构的设计都是第一位的。

3.3 混合架构的实践与取舍

现在越来越多的项目采用混合架构：PLC做底层实时控制，PC做上层数据分析和人机交互，两者通过OPC UA或Modbus TCP通信。这种架构的好处是各取所长，坏处是通信成了新的瓶颈。

OPC UA协议本身很强大，支持复杂数据类型、安全认证、信息建模，但它的开销也大。一个OPC UA的订阅，如果采样周期设得太短，服务器CPU占用率会飙升。Modbus TCP简单轻量，但没有语义信息，读上来的就是一堆寄存器，还得自己映射。

我在一个数控机床数据采集项目里试过两种方案：用OPC UA直接读机床的变量，配置简单但延迟在100ms左右；用Modbus TCP轮询，延迟能压到20ms但需要自己解析数据格式。最后选了Modbus TCP，因为机床的实时状态数据对延迟敏感，而OPC UA的语义信息在这个场景里用不上。协议选型没有绝对的好坏，只有适不适合。

4. 工业软件在工程实践中的核心细节

4.1 PLC程序架构：从“能跑”到“好维护”

很多PLC程序的问题不是功能不对，而是结构太烂。我见过一个项目，主程序里塞了三千多个梯级，没有任何子程序调用，所有逻辑平铺直叙。这种程序能跑，但改一个参数就得全篇搜索，加一个功能就得从头到尾捋一遍。

好的PLC程序架构应该像盖房子：有地基（硬件配置和IO映射）、有承重墙（核心控制逻辑）、有隔断（功能模块划分）、有装修（人机界面和报警）。具体来说，我习惯把程序分成这几层：

• 硬件层：IO模块的读写、模拟量缩放、通信接口初始化。这一层尽量用厂商提供的标准功能块，不要自己造轮子。
• 设备层：每台设备（电机、阀门、仪表）封装成一个功能块，对外只暴露启动、停止、状态、故障几个接口。设备内部的逻辑（比如电机的星三角启动时序）封装在功能块里，外部不需要关心。
• 工艺层：根据工艺流程调用设备功能块，实现联锁、顺序控制、PID回路。这一层是程序的核心，也是最需要跟工艺工程师反复确认的部分。
• 管理层：报警处理、趋势记录、生产统计、通信上传。这一层的数据量最大，但实时性要求最低，可以放在慢速任务里执行。

这样分层的好处是改一层不影响其他层。换个电机型号，只改设备层的功能块；调整工艺参数，只改工艺层；增加一个报表，只改管理层。听起来很简单，但真正在项目里坚持这么做的团队不多，因为前期设计费时间，后期改起来又觉得“直接改快一点”。

4.2 SCADA与PLC的通信：那些年踩过的坑

SCADA和PLC的连接，看起来就是配个IP地址、选个协议、建几个变量，但实际操作中问题层出不穷。我整理了几种最常见的坑和排查思路：

注意：Modbus TCP的寄存器地址在不同厂商的PLC里定义不一样，西门子的V区、三菱的D区、欧姆龙的DM区，映射到Modbus地址时一定要查手册，不要凭经验猜。

还有一个容易被忽略的点是通信负载。SCADA如果每100ms轮询一次，每次读几百个变量，PLC的通信任务会占用大量CPU时间，影响控制任务的扫描周期。我的做法是把通信分成两类：关键状态量用短周期（200-500ms），比如电机的运行状态、故障信号；非关键数据用长周期（2-5s），比如温度、液位、累计产量。这样既能保证实时性，又不会把PLC压垮。

4.3 从梯形图到结构化文本：什么时候该换语言

梯形图不是万能的，但很多人就是不愿意换。我总结了一个简单的判断标准：

• 逻辑关系简单、以开关量为主：用梯形图，直观、好调试、电工能看懂。
• 涉及数学运算、循环、数组操作：用结构化文本，代码量少、可读性好。
• 流程控制、状态机：用顺序功能图，步骤清晰、便于跟工艺人员沟通。
• 信号处理、滤波、PID：用功能块图，数据流一目了然。

但现实是，很多PLC编程软件对ST的支持并不好。三菱的GX Works2里ST编辑器功能很弱，西门子的博途稍微好一点但编译速度慢。而且ST程序的在线调试不如梯形图直观，看不到能流的变化。所以我的建议是：核心逻辑用梯形图，算法和数据处理用ST，两者混用但界限清晰。

5. 实操过程：一个冷库监控系统的软件设计实录

5.1 需求分析与IO清单整理

假设我们要做一个冷库监控系统，控制对象包括：两台压缩机、两台冷凝风机、两台蒸发风机、一个化霜加热器、一个膨胀阀。监测对象包括：库温、蒸发温度、冷凝温度、吸气压力、排气压力、电流。

第一步不是写程序，而是整理IO清单。这个清单要包含：信号名称、信号类型（DI/DO/AI/AO）、PLC地址、量程、工程单位、报警上下限。这份清单是后面所有工作的基础，也是跟甲方确认需求的最好工具。

这份清单看起来简单，但实际项目中经常因为量程写错、地址冲突、报警值不合理而返工。我的经验是：IO清单必须让工艺工程师签字确认，不然后面改起来扯皮。

5.2 程序架构设计与功能块封装

根据前面的分层思路，我把程序分成四个部分：

硬件层：调用厂商提供的模拟量输入处理功能块，把IW64~IW72转换成实际的温度值和压力值。这里要注意滤波，模拟量信号容易受干扰，我一般用一阶低通滤波，时间常数设2-5秒。

设备层：封装压缩机、风机、化霜加热器的功能块。以压缩机为例，功能块接口包括：启动命令、停止命令、故障复位、运行状态、故障状态、运行时间。内部逻辑包括：启动延时、最小运行时间、最小停机时间、故障联锁。

工艺层：实现冷库的制冷逻辑。核心是一个状态机：待机→制冷→化霜→排水→待机。制冷状态下，根据库温与设定值的偏差，决定开几台压缩机。化霜状态下，关闭压缩机，打开化霜加热器，等蒸发温度升到设定值后进入排水状态。

管理层：报警处理、数据记录、通信上传。报警分三级：提示、警告、故障。提示只在画面上显示，警告需要操作员确认，故障触发停机并记录。

5.3 关键参数的计算与设置

冷库控制里最关键的参数是化霜周期和化霜退出条件。化霜周期太短，能耗高；太长，蒸发器结霜严重，制冷效率下降。一般根据库温、湿度、开门频率来设定，经验值是每4-6小时化霜一次。

化霜退出条件通常有两个：蒸发温度达到设定值（比如10℃）或化霜时间超过上限（比如30分钟）。两个条件取先到者。这里有个坑：如果蒸发温度传感器坏了，化霜会一直进行，把冷库变成烤箱。所以必须加化霜超时保护，时间上限到了强制退出并报警。

PID参数整定也是类似。冷库的温度控制惯性大、滞后明显，PID参数不能太激进。我一般先用经验值：比例带10-20℃，积分时间300-600秒，微分时间30-60秒。然后根据实际响应曲线微调。如果温度波动超过±2℃，说明比例带太小；如果温度恢复太慢，说明积分时间太长。

5.4 调试现场的真实记录

调试那天，压缩机启动后库温下降很慢，蒸发温度一直在-35℃左右，明显偏低。检查膨胀阀开度，发现开度只有20%。手动开到50%，蒸发温度回升到-25℃，库温开始正常下降。

问题出在过热度控制上。膨胀阀的开度是根据过热度自动调节的，过热度设定值是5K，但实际过热度到了15K，说明膨胀阀开度不够。原因是过热度传感器的安装位置不对，贴在了回气管的弯头处，测量值偏高。把传感器移到直管段后，过热度回到5K，膨胀阀开度自动调整到45%，系统运行正常。

这个案例说明：软件逻辑再对，传感器装错了也是白搭。工业软件不是孤立的，它跟硬件、工艺、安装质量紧密相关。做软件的人不能只盯着屏幕，得去现场看、去摸、去听。

6. 常见问题与排查技巧实录

6.1 PLC程序调试中的典型故障

问题一：程序下载后PLC报错，但错误代码看不懂。

这种情况我遇到太多次了。西门子的PLC报错信息还算详细，三菱的就比较简略。我的排查顺序是：先看硬件组态有没有报错（模块是否识别、地址是否冲突），再看程序编译有没有警告（变量未使用、数据类型不匹配），最后看运行时有没有访问越界（数组下标超限、指针错误）。

问题二：模拟量输入值跳动大，不稳定。

先排除硬件问题：用万用表测传感器输出是否稳定，检查屏蔽线是否接地，检查信号线是否跟动力线走在一起。如果硬件没问题，那就是软件滤波没做好。我一般用滑动平均滤波，窗口大小8-16个采样点，既能平滑波动又不会引入太大延迟。

问题三：通信突然中断，重启后恢复。

这种间歇性故障最难查。我的做法是：在PLC程序里加通信状态监测，记录每次中断的时间戳和错误码；在SCADA端加心跳检测，超时自动重连；在网络交换机上开端口镜像，用Wireshark抓包分析。十有八九是网络风暴、IP冲突或交换机过热。

6.2 SCADA组态的避坑指南

SCADA组态看起来简单，但细节极多。我列几个最容易踩的坑：

• 变量命名混乱：今天用中文，明天用拼音，后天用英文缩写。后期维护的时候自己都看不懂。建议统一用“设备类型_设备编号_信号类型”的格式，比如“COMP_01_RUN”。
• 画面刷新率设置不当：所有画面都设100ms刷新，结果CPU占用率爆表。应该根据数据变化频率设置，温度、液位这类慢变量设1-2秒刷新就够了。
• 报警泛滥：一个传感器抖动触发几百条报警，操作员直接忽略。应该加报警延时和死区，比如温度超过上限持续5秒才报警，回差2℃才复位。
• 权限管理缺失：操作工能改PID参数，工程师能改系统配置，没有区分。应该按角色分配权限，关键参数修改要记录日志。

6.3 工业软件与IT系统集成的边界问题

现在很多项目要求把PLC数据上传到MES或云端，这就涉及到工业软件和IT系统的集成。最大的问题是数据语义不一致。PLC里一个变量叫“IW64”，MES里要的是“1号冷库温度”，中间需要一个映射层。

我的做法是在SCADA或边缘网关里做信息建模，把PLC的原始地址映射成有语义的标签，再通过OPC UA或MQTT上传。这样IT系统不需要关心PLC的地址，只需要按标签名订阅数据。但要注意数据频率，IT系统通常不需要毫秒级的数据，1秒或5秒一次就够了，上传太频繁会把网络和数据库压垮。

提示：OPC UA的信息建模功能很强大，但配置复杂。如果项目规模不大，用MQTT加JSON格式更简单直接。关键是跟IT团队确认好数据格式和频率，不要自己拍脑袋决定。

7. 工业软件的未来：从“附属品”到“核心资产”

7.1 软件定义自动化不是口号

“软件定义”这个词在IT圈已经喊了很多年，在工业圈才刚刚起步。但趋势很明显：硬件的差异化越来越小，软件的差异化越来越大。同样一套PLC和伺服，不同团队做出来的设备，性能、稳定性、易用性可以差出好几倍。

软件定义自动化的核心是把控制逻辑从硬件中解耦出来。以前换个PLC品牌，程序要重写；以后用IEC 61131标准加运行时环境，程序可以跨平台移植。以前改个工艺参数要重新下载程序；以后参数存在数据库里，运行时动态加载。这些在IT领域早就实现了，工业领域只是走得慢一点。

7.2 工程师的能力模型需要更新

我招人的时候，最看重的不是会不会写梯形图，而是有没有软件工程的思维。具体来说：会不会用版本控制（Git）、会不会写单元测试、会不会做代码审查、会不会设计状态机、会不会分析算法复杂度。这些技能在纯IT领域是基本功，在工业自动化领域却是稀缺品。

当然，工业软件工程师还得懂工艺、懂硬件、懂现场。一个只会在办公室写代码的人，做不好工业软件。但一个只懂现场接线、不懂软件设计的人，也做不好工业软件。未来的自动化工程师，必须是软硬兼修的复合型人才。

7.3 给一线从业者的几点实在建议

如果你正在做工业软件相关的工作，不管是PLC编程、SCADA组态还是PC控制开发，我有几个建议：

第一，把程序当代码写，不是当图纸画。用版本控制管理程序，每次修改都提交记录；用模块化设计降低耦合，一个功能块只做一件事；用命名规范提高可读性，让别人能看懂你的程序。

第二，多学一点软件工程的知识。设计模式、重构、测试驱动开发，这些在IT领域成熟的方法论，在工业软件里同样适用。不用学得太深，但基本概念要有。

第三，保持对硬件的敬畏。软件再厉害，也得靠硬件执行。了解传感器的原理、执行器的特性、通信的物理层，能帮你写出更靠谱的程序。

第四，多去现场。坐在办公室想出来的逻辑，到了现场往往行不通。多跟操作工聊天，多观察设备的实际运行，你会发现很多在图纸上看不到的问题。

彭瑜老师说的“被忽略的工业软件”，本质上是一个认知问题。大家都觉得软件是虚的，硬件是实的。但真正做过项目的人都知道，软件才是那个决定成败的关键。希望这篇文章能让更多同行意识到这一点，也希望我们这一代自动化人，能把工业软件的地位提上去，把软件工程的方法用起来。毕竟，自动控制的核心是信息处理，而信息处理的载体，就是软件。