徐工集团控制软件开发：从PLC到边缘计算的架构演进
近期趋势：控制软件的架构层级正在上移
在工程机械领域，控制软件从传统的PLC（可编程逻辑控制器）为核心，逐步向工业PC、嵌入式控制器乃至边缘计算节点演进。徐工集团作为国内工程机械龙头企业，其控制软件开发也呈现出类似的架构变化：基础逻辑控制仍保留在PLC层，但数据处理、诊断、远程升级等功能正被剥离到更上层的边缘计算单元中。近期多个行业展会与用户反馈显示，这种分层设计正成为主流选择。
- PLC层：负责设备本体的I/O控制、安全联锁、基础动作循环，严格遵循IEC 61131-3标准。
- 中间层：嵌入式控制器或工业平板，承担状态监测、报警管理、参数自适应调整。
- 边缘层：基于ARM或x86架构的工控机，运行轻量化操作系统，集成AI推理、数据预处理、本地决策。
行业背景：从刚性控制到柔性智能的驱动力
传统工程机械的控制软件长期依赖PLC与专用控制器（如力士乐、派克等品牌）的封闭生态。但随着施工环境复杂化、用户对远程运维和节能降耗需求提升，原有架构暴露出扩展性差、数据孤岛、升级困难等问题。徐工集团在开发新一代控制软件时，面临的主要背景因素包括：
- 设备数字化率提高，单台机械传感器数量从几十个增加至上百个，PLC的扫描周期和内存已无法满足全量数据采集。
- 用户期望“即插即用”式功能插件，例如预测性维护、油耗优化模型，这些无法通过修改PLC梯形图实现。
- 通信协议碎片化（CANopen、J1939、Modbus TCP等），需要一个统一的数据汇集层。
用户关注点：实时性、可靠性与生态兼容
在从PLC向边缘计算的演进中，行业用户普遍关注三个核心维度：
- 实时性保障：PLC的确定性循环时间（通常1–10ms）是安全控制的基础。边缘计算节点若参与控制回路，必须通过TSN（时间敏感网络）或独立硬件中断来保证延迟不高于PLC层。
- 可靠性边界：工程机械工作在振动、高温、高湿环境，边缘计算设备需要达到与PLC同等级的防护（如IP67、宽温设计），且具备断电数据保全能力。
- 存量兼容性：徐工集团拥有大量在役设备采用不同厂家PLC，新架构必须支持多种Fieldbus协议转换，避免造成用户资产浪费。
从用户实际案例反馈看，多数工况下将非实时分析功能上移至边缘层，PLC仅保留核心逻辑，可降低约30%的系统响应抖动概率，同时使控制器CPU负载维持在70%以下。
可能影响：架构变化带来的研发与运维重构
控制软件架构从扁平化走向分层化，将对徐工集团内部开发流程和外部服务模式产生以下潜在影响：
| 领域 | 传统PLC模式 | 引入边缘计算后 |
|---|---|---|
| 软件开发流程 | 电工工程师编写梯形图/ST，硬件绑定 | 软件团队使用C++、Python开发算法，通过容器化部署到边缘节点 |
| 升级方式 | 现场更换EEPROM或刷写固件 | OTA远程推送，支持A/B分区热更新 |
| 数据利用度 | 仅记录故障码与简单统计 | 可存储小时级原始数据，用于模型迭代 |
| 供应商依赖 | 高度依赖PLC品牌生态 | 部分替换为通用硬件+自研中间件，降低锁定 |
需要注意的是，这种演进并非一蹴而就。对于安全等级要求极高的功能（如动臂防倾翻、过载保护），业界仍倾向于保留PLC独立控制链路，边缘计算仅做辅助决策与冗余备份。
后续观察：边缘智能的规模化落地条件
徐工集团控制软件的未来方向，取决于以下三个条件的成熟程度：
- 边缘芯片的工业级验证：当前主流AI芯片（如Jetson、瑞萨RZ系列）已在部分矿区机械中试用，但大规模量产仍需验证抗振动与长寿命。
- 软件中间件标准化：若能在集团内统一边缘计算节点上的数据接口、算法部署框架（类似Eclipse BaSyx或AutomationML），可降低多机型适配成本。
- 用户付费意愿：边缘计算带来的增值功能（如智能称重、自适应行走）是否被施工方接受，直接影响该架构的推广速度。
可以预见，未来两年内，徐工集团的控制软件开发将以“PLC为骨架、边缘计算为大脑”的分工模式为主流，同时持续探索端侧模型压缩与联邦学习在机群协同中的应用可能。业界将密切观察其在实际矿山、港口等复杂场景下的可靠性与经济性平衡点。