2. 工业设备软件的分层模型

工业设备软件之所以要分层，根本原因在于“变化速度不同”。硬件型号、传感器接口、执行器时序、控制算法、工艺配方、人机交互方式，这几类内容的变更频率和责任人完全不同。如果把它们揉在一个大循环里，任何一处硬件替换或界面调整都可能牵动整机逻辑。分层模型的目标，就是让每一层只对相邻层负责，把变化限制在局部。

下面按自底向上的顺序，说明五层的职责划分与典型形态。需要先明确一个约定：本文所说的“上层”指更靠近操作人员和业务的一端，“下层”指更靠近物理硬件的一端；调用方向通常是上层调用下层，数据/事件方向则可能双向流动。

硬件抽象层（HAL）：把“寄存器”变成“接口”

硬件抽象层直接面对芯片外设、总线控制器和板级资源，它的职责不是实现业务，而是把具体硬件细节封装成一组稳定的、与芯片型号无关的接口。典型形态包括：GPIO 读写、ADC 采样通道、PWM 占空比设置、I2C/SPI/CAN 收发、定时器计数、看门狗喂狗等。

以某款基于 STM32 的控制器为例，HAL 层可能提供这样的接口语义：hal_adc_read(channel) 返回 0～4095 的原始码值，hal_pwm_set(channel, duty_permille) 接受 0～1000 的千分比。注意这里刻意不暴露“哪个寄存器、哪一位”，因为一旦上层直接操作寄存器，换芯片就等于重写全部逻辑。HAL 的验收标准是：同一组接口在两种不同 MCU 上都能编译通过并跑通基本读写。

设备驱动层：把“接口”变成“设备语义”

驱动层建立在 HAL 之上，负责把通用接口组合成具体设备的可理解行为。它关心的是“这台设备是什么、怎么初始化、怎么读一次有效值、异常时怎么恢复”。典型对象包括温度变送器、伺服驱动器、变频器、称重模块、编码器、气动阀岛等。

驱动层的典型形态是“设备对象 + 状态机”。例如一个 Modbus RTU 温度变送器驱动，内部会维护：从站地址、波特率、寄存器映射、量程上下限、断线判定阈值。对外暴露的可能是 temp_driver_read(&value)，返回 0 表示成功，负值表示超时或 CRC 错误。驱动层还要处理单位换算：把寄存器里的 0～65535 映射为 -50.0～150.0 ℃，并做越限标记。这样上层拿到的就是带物理意义的量，而不是裸数据。

实时控制层：把“设备语义”变成“闭环行为”

实时控制层是工业设备软件区别于普通信息系统的关键一层。它承担周期性的采样、计算、输出，并保证时序确定性。典型形态包括：1 ms 或 10 ms 的控制任务、PID 调节、前馈补偿、斜坡函数、联锁逻辑、急停处理。

以一个温度闭环为例：控制周期 100 ms，采样来自驱动层的温度值，设定值来自业务逻辑层下发的配方。控制层执行位置式 PID，输出 0～1000 的加热功率千分比，再经驱动层写入 PWM。这里的关键参数是周期抖动：如果标称 100 ms 的任务实际抖动达到 ±20 ms，积分项就会失真。因此控制层通常运行在 RTOS 的高优先级任务或定时器中断中，而不是普通主循环里。

业务逻辑层：把“闭环行为”变成“工艺过程”

业务逻辑层负责编排工艺步骤、管理配方、处理批次和状态迁移。它不直接碰寄存器，也不直接算 PID，而是调用控制层提供的“启动升温”“保持恒温”“执行保压”等动作，并根据反馈决定下一步。典型形态是状态机或工序引擎。

例如一个注塑机温控工序可以抽象为：预热 → 升温 → 恒温 → 生产 → 冷却 → 结束。每个状态有进入条件、保持条件、退出条件和超时保护。业务层还要处理配方切换：当操作员选择“PC+ABS 配方”时，把目标温度 260 ℃、升温速率 2 ℃/s、恒温窗口 ±3 ℃ 下发给控制层。业务层的输出不是电信号，而是“工序指令”和“批次记录”。

应用交互层：把“工艺过程”变成“可操作、可追溯的界面”

应用交互层面向操作员、工程师和上位系统，负责展示、输入、报警、日志和对外通信。典型形态包括 HMI 画面、触摸屏、Web 组态、OPC UA/Modbus TCP 服务端、MES 接口。它不承担实时闭环，但必须保证“看到的就是当前状态”。

交互层的一个常见工程问题是刷新频率与数据一致性。例如 HMI 每 200 ms 刷新一次温度显示，而控制层每 100 ms 更新一次，如果直接读共享变量而不加锁或快照，就可能出现跳变。合理做法是控制层发布“只读快照”，交互层读取快照，避免跨层直接共享可变状态。

跨层协作的一个完整数据路径

把五层串起来看一次实际过程：操作员在 HMI 上选择“PC+ABS 配方”，交互层把配方号写入业务逻辑层；业务层查表得到目标温度 260 ℃、升温速率 2 ℃/s，启动“升温”状态；控制层每 100 ms 读取驱动层温度值，与斜坡设定值比较，经 PID 输出加热功率千分比；驱动层把千分比换算为 PWM 比较值，调用 HAL 的 hal_pwm_set；HAL 写定时器寄存器。反向路径上，温度值经驱动层换算、控制层快照、业务层记录、交互层显示，形成闭环。

这条路径里，任何一层“越权”都会带来问题：业务层直接写 PWM 会绕过 PID 和限幅；交互层直接读控制层内部变量会破坏快照一致性；驱动层直接操作寄存器会让换芯片成本剧增。因此分层不只是画框图，而是接口边界和依赖方向的约束。

分层落地时的三个判断依据

• 接口稳定性：下层接口是否只暴露语义、不暴露实现。若上层代码里出现寄存器名或芯片型号，说明 HAL 边界被击穿。
• 时序归属：实时性要求高的计算是否集中在控制层。若业务层里出现 delay_ms 或忙等，说明实时职责错位。
• 可替换性：更换一种温度变送器时，改动是否只落在驱动层。若业务层或交互层也要改，说明设备语义没有收敛在驱动层。

实际工程中，五层并非总是物理上分成五个进程或五个工程。小型设备可能把 HAL 和驱动层合并在一个 MCU 工程里，业务层和交互层跑在同一个 HMI 上；大型产线则可能把控制层放在 PLC 或实时控制器，业务层放在工控机，交互层放在触摸屏和上位服务器。层数可以压缩，但“职责边界”和“依赖方向”不能丢。判断一个分层设计是否合理，最终看的是：当硬件、工艺或界面任意一项发生变化时，改动是否能被限制在预期的那一层内。