夜雨聆风
从 PLC 到 HMI,标准化软件架构到底应该怎么分层?
前面两篇我们讲了两件事：
-
为什么 SICAR V5.2值得关注 -
为什么很多企业标准程序做不起来
如果再往下走一步，就会遇到一个更核心的问题：
👉 标准程序的软件架构，到底应该怎么搭？
很多团队的问题不是不知道“要分层”，而是：
👉 看起来分了层，但系统依然是乱的
常见情况是：
-
分层画出来了，代码还是混在一起 -
对象封装了，项目还是越层访问 -
HMI 做了模板，但和 PLC 结构不对应 -
顺控、报警、维护没有真正打通
👉 所以问题不在“有没有架构”，而在“架构有没有落地”
▍一、先统一一个原则：架构不是为了好看，而是为了复用
很多团队一做架构，就容易变成“画图工程”。
但真正有价值的架构，必须经得住这几个问题：
-
换项目还能不能复用？ -
换人还能不能看懂？ -
换设备还能不能接？ -
出问题能不能快速定位？
👉 架构的价值，不在设计，而在长期可用
👉 能复用的架构，才是好架构
▍二、一个更可落地的方式：把系统拆成 5 层
如果用工程可执行的方式来看，一套标准化软件架构，至少要拆成这几层：
-
Core（系统底座层） -
TecUnit（设备对象层） -
Interface（接口层） -
Sequence（顺控层） -
App（项目层）
再往上，对应：
👉 HMI（统一呈现层）
👉 不是为了复杂，而是为了不混在一起
🧩 架构整体示意
（标准化软件分层结构示意：Core / TecUnit / Interface / Sequence / App / HMI）
▍三、每一层到底在做什么（核心部分）
1️⃣ Core 层：统一系统行为
Core 不负责设备动作，而负责：
-
模式管理（自动 / 手动 / 服务） -
权限控制 -
系统状态汇总 -
公共报警与诊断入口 -
HMI 公共接口
👉 Core 的目标只有一个：让系统行为一致
👉 系统不统一，后面全部失控
2️⃣ TecUnit 层：把设备变成“真正的对象”
这一层解决：
👉 设备怎么抽象
典型对象：
-
阀 -
电机 -
辊道 -
升降机 -
轴 / 转台
但关键不在名字，而在边界：
一个合格对象必须有：
-
标准输入 -
标准输出 -
命令接口 -
报警 / 诊断接口 -
HMI 绑定接口
👉 对象不是封装代码，而是定义边界
3️⃣ Interface 层：隔离外部世界
这一层专门处理：
-
RFID -
视觉 -
驱动 -
第三方设备 -
上位系统通信
👉 核心原则：
👉 主流程不关心“怎么通信”，只关心“有没有完成”
👉 接口不隔离，系统一定会被拖乱
4️⃣ Sequence 层：流程组织
这一层解决：
👉 流程怎么走
负责：
-
当前步骤 -
步骤切换 -
异常分支 -
同步控制
原则：
-
只发标准命令 -
只看标准状态 -
不操作底层 IO
👉 顺控负责流程，不负责细节
5️⃣ App 层：留住项目差异
这一层只放：
-
节拍逻辑 -
产品判断 -
客户工艺 -
特殊联锁
👉 标准层要稳定，项目层允许变化
👉 项目逻辑一旦写回底座，标准化就开始崩
▍四、HMI 不是附属，而是架构的一部分
很多团队把 HMI 当“最后补的东西”。
这是一个很大的误区。
👉 用户感受到的系统统一，是从界面开始的
正确做法是：
-
Core → 系统状态 / 模式 -
TecUnit → faceplate / 操作 -
Interface → 设备诊断 -
Sequence → 流程展示 -
App → 工艺页面
👉 PLC 和 HMI 必须是一套结构
👉 界面不统一，系统就不统一
▍五、为什么很多架构最后会失效
1️⃣ 越层访问
👉 一旦允许，分层立即失效
2️⃣ PLC 和 HMI 不同步
👉 看起来有结构，本质还是混乱
3️⃣ 没有样板站
👉 直接铺开，一定返工
4️⃣ 没人守边界
👉 没治理，就没有标准
👉 架构失效，从来不是设计问题，而是执行问题
▍六、如果现在开始，最稳的路径
1️⃣ 先定义分层
2️⃣ 先做一个样板工位
3️⃣ PLC + HMI 同步设计
4️⃣ 建立版本机制
5️⃣ 从“块复用”走向“架构复用”
👉 真正可复制的，是结构，而不是代码
▍结尾
标准程序真正难的，
不是写几个标准块，
而是：
👉 把 PLC 到 HMI 的整套架构组织清楚
👉 标准化做不起来，本质不是技术问题，而是架构问题
下一篇，我们继续往下讲：
👉 企业导入标准化平台，第一步该怎么走
如果你也在做标准程序，但遇到这些问题：
-
架构怎么分层不清楚 -
项目之间越来越不一致 -
HMI 和 PLC 对不上 -
系统越来越重
欢迎一起交流。
我们可以把这件事拆开，重新搭一套更稳的路径。
广州迈控星科技专注工业自动化与 AI 融合落地持续探索标准化软件平台与工程交付的结合路径