同一盏指示灯要说出"灭 / 闪烁 / 呼吸"三种话：工业设备状态交互怎么设计
一、一盏灯能承载的信息比想象中多
单色 LED 的可区分表达维度其实有五个：
| 维度 | 可选值 | 感知可靠度 |
|---|---|---|
| 亮 / 灭 | 2 种 | 高 |
| 闪烁频率 | 慢（0.5Hz）/ 中（1–2Hz）/ 快（4Hz+） | 中 |
| 占空比 | 长亮短灭 vs 等宽闪烁 | 低，容易误判 |
| 渐变（呼吸） | 周期 1–4 秒 | 中 |
| 短码组合 | 两短一长之类 | 低，需要人来数 |
工程实现上，灭/闪用定时器翻转 GPIO 就行；呼吸要靠 PWM 调占空比，配合一段缓动曲线（常见做法是查表或用 sin² 近似），并且必须放在不影响主控周期的低优先级任务里。这类”看起来三行代码”的功能，实际最容易出的问题是在主循环里做延时，导致采集周期抖动。
二、真正难的是”语义分配”，不是”怎么闪”
我们在工业现场见过太多这样的定义：
灭 = 关机 |
三个月后没人记得”快闪”和”慢闪”哪个是”刚上电自检”，因为它违反了人类远距离识别的基本规律：距离三米、有油污、有环境光的情况下，**人眼可靠区分的是”有没有在闪”和”颜色”，而不是”闪多快”**。频率的分辨能力会随照度、年龄、观察距离迅速衰减。
我们给客户的分配原则是四条：
- 用”是否闪”区分正常与异常，而不是用频率。常亮 = 稳定态；闪烁 = 过渡或异常。这一条最容易远距离判断，所以留给最重要的信息。
- 颜色承担第一层语义，灯态承担第二层。 绿/黄/红三色组合下，”红色慢闪”远比”某种频率的绿色”更容易被正确解读。
- 一个状态只对应一种表达，禁止复用。 同一种闪烁在不同上下文表示不同含义，等于没有定义。
- 过渡态必须能自解释为”再等一会儿”。 呼吸、缓慢渐变这类”活着但不稳定”的表达，只用于配网、启动、OTA 升级等有明确终点的过程；异常必须用锐利的、不优雅的方波闪烁——温和的动效不该用来表达危险。
三、把它写进可交付文档
工业项目的验收里，状态灯最容易出问题不是因为设计不出来，而是没写进文档。设备到客户现场后，操作工凭经验理解，一线班组的解读和三个月前调试人员的解读会分叉。
我们现在的交付模板里，这一块固定三页内容：
- 状态定义表：灯色 + 灯态 + 含义 + 操作工应做的动作（不是”报警”，而是”停机并按 X 上报”）；
- 优先级规则：多个状态同时成立时显示哪一个（我们一律按”安全事件 > 故障 > 未联网 > 运行 > 待机”）；
- 不可用状态的处理：传感器失联时灯该怎么闪。这一条最常被遗漏，也最危险——它等于告诉操作工”数据是好的”。
四、洹拓视角：小硬件里的商业逻辑
有客户问过：加个呼吸灯要不要单独报价？我们的答案是要，而且要按状态设计的工时报价，不是按硬件成本。
原因在两个层面：
第一，它是产品的”可支持性”设计。 一台设备出故障时，操作工能不能一眼描述”红灯快闪了三下”，直接决定了售后电话的排障效率。我们做设备数据采集与故障诊断智能体时，一个体会很深：现场能提供的有效描述越少，算法要补的推断就越多，成本越高。 状态语言本质上是把人这一环的噪声降下来。
第二，这是典型的”本地软件公司做嵌入式”的能力边界测试。 新乡及豫北的装备制造企业，很多自研控制器都卡在灯语、按键消抖、看门狗这类”小事”上——不是做不出来，是没有把它当规范做。我们的经验是：越是低成本的表达通道，越需要严格设计，因为它往往是人机之间唯一的界面。
对准备上设备联网的制造企业，我们的建议是从这一步开始：先把状态定义表建起来，再谈采集与看板。 状态定义一旦混乱，后端收到的时间序列数据同样混乱，而且事后无法区分”设备真出了这个状态”和”操作工手动重启过”。
灯态实现要点（PWM 呼吸、避免主循环延时）与通用嵌入式实践一致；状态语义分配与交付模板为洹拓科技工业项目现场约定。
新乡洹拓科技有限公司，软件开发 · AI模型研发 · 云服务与部署运维。
咨询热线：400-829-9957
地址：河南省新乡市辉县市金城百货四楼