从 PLC 到 HMI，标准化软件架构到底应该怎么分层？

前面两篇我们讲了两件事：

• 为什么 SICAR V5.2 值得关注
• 为什么很多企业标准程序做不起来

如果再往下走一步，就会遇到一个更核心的问题：

标准程序的软件架构，到底应该怎么搭？

很多团队的问题不是不知道“要分层”，而是：

看起来分了层，但系统依然是乱的

常见情况是：

• 分层画出来了，代码还是混在一起
• 对象封装了，项目还是越层访问
• HMI 做了模板，但和 PLC 结构不对应
• 顺控、报警、维护没有真正打通

所以问题不在“有没有架构”，而在“架构有没有落地”

一、先统一一个原则：架构不是为了好看，而是为了复用

很多团队一做架构，就容易变成“画图工程”。

但真正有价值的架构，必须经得住这几个问题：

• 换项目还能不能复用？
• 换人还能不能看懂？
• 换设备还能不能接？
• 出问题能不能快速定位？

架构的价值，不在设计，而在长期可用

能复用的架构，才是好架构

二、一个更可落地的方式：把系统拆成 5 层

如果用工程可执行的方式来看，一套标准化软件架构，至少要拆成这几层：

• 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 的整套架构组织清楚

标准化做不起来，本质不是技术问题，而是架构问题

下一篇，我们继续往下讲：

企业导入标准化平台，第一步该怎么走