机器人技术系列第 20 篇，先给结论：工作站报警不是把 PLC、机器人、视觉和安全设备的报错文字集中到 HMI，而是建立一套能回答“谁先出问题、设备现在处于什么状态、谁可以处理、满足什么条件才能恢复”的统一故障语义。 如果报警页面只有一串按时间滚动的红字，现场仍会被连锁信息淹没，维修人员只能靠经验猜第一原因。

我们在设计机器人工作站时，会把报警架构当成控制功能的一部分，而不是调试末期补几条弹窗。它至少包含六层：稳定且唯一的故障 ID；事件、状态和原因的区分；首发故障与连锁反应的关联；严重度与恢复类型；给操作员看的动作提示；可用于复盘的时间、版本和上下文记录。

GB/T 41261-2022《过程工业报警系统管理》提供了报警管理、合理化和生命周期思路，但它的对象是过程工业。本篇借用其中“报警应被设计和管理”的方法，不把过程装置的指标、术语或条款直接当作离散机器人工作站的强制验收线。机器人单元仍要根据设备状态、工艺风险、安全功能和人员职责形成自己的故障模型。

一、先分清事件、状态、报警和消息

很多报警泛滥，起点不是程序太复杂，而是所有信息都被当成同一种“报警”。

• 事件：某件事情在某个时刻发生，例如产品到位信号上升、机器人程序启动、配方切换完成。事件用于追溯，不一定要求人处理。
• 状态：某个条件在一段时间内成立，例如安全门打开、气压低于工作条件、机器人不在自动模式。状态有开始和结束。
• 报警：需要指定人员在规定时间内注意、判断或动作的异常信息。它应有后果、优先级和处理方式。
• 消息：提示性信息，例如“等待上游放行”“当前无生产订单”。它能解释设备为何未动作，但不一定代表故障。

如果把“等待产品”“机器人自动运行”“安全门打开”“伺服故障”和“视觉结果返回”全部画成红色报警，操作员会逐渐忽略颜色与蜂鸣。真正的高风险信息出现时，也只是列表里多了一行。

建议先建立信息分类表：

信息类型	是否需要确认	是否影响运行	是否需要声音/灯光	是否进入故障统计
普通事件	否	通常不影响	否	进入事件记录，不计故障
等待状态	否	暂停当前动作	通常不需要	统计等待时间可选
工艺报警	视后果决定	可能停单站或隔离产品	按优先级	是
设备故障	是	停相关设备	是	是
安全相关停机	必须按安全程序确认	阻止危险运动	与现场设计一致	单独记录，不能被普通自动重试覆盖
维护提醒	可延后确认	当前可能不停机	低优先级	进入维护计划

分类一旦确定，HMI 颜色、灯塔、声音、消息保留时间和统计口径才能保持一致。

二、故障 ID 要稳定，显示文字可以多语言

报警架构的主键不应该是中文句子。文字会修改、翻译和缩写，不适合在 PLC、机器人、MES 和维修记录之间做关联。更稳妥的做法是给每个故障定义稳定 ID，例如 CELL02-GRP01-POS-TIMEOUT，并把显示文字、设备、部件、严重度和恢复方式作为属性。

一个完整条目可以包含：

字段	示例	设计目的
FaultID	CELL02-GRP01-POS-TIMEOUT	跨系统稳定关联
Source	PLC / 机器人 / 视觉 / 安全控制器	知道原始产生位置
Object	2 号单元 1 号气爪	定位设备与部件
Condition	关闭命令后规定窗口内未见关闭确认	描述可验证触发条件
FirstOrDerived	首发 / 派生	区分根因候选与连锁结果
Severity	高 / 中 / 低，或项目自定义等级	决定呈现与响应
RecoveryClass	自动恢复 / 验证后恢复 / 现场维修	限制恢复权限
ProductAction	保持、隔离、复检、报废待判	防止设备恢复后丢失产品状态
Evidence	命令、反馈、压力、步骤号、产品号	为复盘保存上下文
TextKey	ALM_GRIPPER_CLOSE_TIMEOUT	多语言显示与版本管理

FaultID 要在项目生命周期中保持稳定。修正文案时不换 ID；故障语义真正变化时，建立新 ID 并记录替代关系，避免历史统计把两种条件混成一个故障。

编号也不要只按“第 1001 条、第 1002 条”随意增长。可以按单元、设备、功能和故障类型分层，但不要把过多业务含义压进数字位数。结构要让人能读，也要给将来扩展留空间。

三、状态码与原因码要分开

“设备未就绪”通常是状态，不是根因。它可能因为安全门打开、机器人伺服未使能、配方未加载、气压不足或下游未允许。若 HMI 只显示“机器人未就绪”，维修人员仍要逐层找原因；若每个不满足条件又同时弹一条红色报警，列表会被连锁项占满。

比较清楚的结构是：

• 状态码回答“设备现在能做什么”，例如待机、准备、自动运行、暂停、故障、维护；
• 原因码回答“为什么不能进入目标状态”，例如安全条件未满足、启动前检查未完成、驱动器故障、工艺条件缺失；
• 动作提示回答“当前角色下一步做什么”，例如补料、隔离产品、由获授权维修人员检查某个部件；
• 证据字段回答“为什么系统这样判断”，例如哪一个输入、在哪一步、持续多久。

状态机只保留有限的主状态，原因码可以更细。这样 PLC、HMI 和上位系统不用为每种组合创造一个新状态，操作员又能看见具体阻断原因。

例如，机器人处于“未准备”状态，原因列表可以同时存在“自动模式未选择”和“区域安全未验证”。当自动模式满足后，第一条消失；安全条件仍未满足时，主状态保持未准备。两条原因不应都被计为独立设备故障，更不能因为操作员消除显示文字，就把真实状态改成准备。

四、首发故障要冻结，连锁报警要能归因

工作站的连锁反应通常很快。一个气爪不到位，PLC 停止机器人；机器人停止导致下游等料；上游又因缓存满而停机。几百毫秒后，HMI 可能出现十几条信息。时间最早的一条不一定就是根因，因为不同设备打时间戳和上传速度不同，但控制逻辑知道哪些条件是因、哪些是结果。

报警设计应保存“本次故障链的首发候选”：

1. 系统在正常运行状态下监测到第一个导致状态迁移的异常条件；
2. 冻结该条件发生时的步骤号、命令和反馈；
3. 后续由它引发的停机、等待和互锁标为派生；
4. 故障链关闭前，不允许新的派生信息覆盖首发记录；
5. 若出现真正独立的新故障，创建第二条故障链，不把它塞进旧链。

可以用 CauseGroupID 把同一链条关联起来。例如：

顺序	FaultID/事件	角色	CauseGroupID
1	气爪关闭超时	首发候选	CG-20260806-0042
2	机器人取件步骤中止	派生状态	CG-20260806-0042
3	下游缺料等待	派生状态	CG-20260806-0042
4	上游缓存满	派生状态	CG-20260806-0042

这不代表软件自动宣判气爪一定是物理根因。关闭超时还可能由气压、阀岛、传感器、工件卡阻或程序时序造成。首发候选的作用是保留调查起点，防止后来的连锁信息把它淹没。

五、触发条件必须可测试，不能写“设备异常”

每个报警都应能用输入、状态和时间条件重现。坏写法是“夹具异常”“通信异常”“机器人故障”；好写法要说明观察对象、期望变化和超时条件。

以气爪关闭超时为例，触发逻辑可写成：

• 前提：当前步骤已发出关闭命令；
• 计时起点：关闭输出真正置位；
• 成功条件：关闭确认有效，且打开确认无效；
• 异常条件：在本配方规定窗口内成功条件未成立；
• 上下文：记录打开/关闭输入、压力允许、阀岛诊断、步骤号和产品号；
• 去抖：传感器短暂变化不立即作为成功，保持条件按项目试验确定；
• 取消：步骤因更高优先级停机中止时，计时器退出但保留中止原因。

“本配方规定窗口”应来自动作试验、最不利工况和余量设计，不是随手写一个整数。时间窗口过短会制造误报警，过长会让真正故障拖慢节拍。调试时应保存正常动作时间分布和慢动作样本，再决定门限。

如果成功条件需要两个互斥传感器，也要定义不可能组合。打开和关闭同时有效，可能是接线、传感器位置或输入映射问题，不应被当作“关闭成功”。两者都无效则要区分气爪在中间位置、传感器故障还是气源问题。

六、严重度不是“停机越久越高”

报警严重度应基于后果和响应紧迫性，而不是仅看停机时间。一个很快恢复的安全功能异常，严重度可能很高；一个需要较长时间补料的等待，未必是高优先级报警。

可以从四个问题决定等级：

1. 是否可能影响人员安全或安全功能；
2. 是否可能造成设备损伤、产品批量不合格或环境后果；
3. 是否必须立即处理，还是可以运行到计划维护窗口；
4. 现场角色是否有能力和权限处理。

示意分层如下：

等级	典型后果	响应	呈现策略
S1	安全功能异常、继续动作可能扩大风险	按安全程序停机并由授权人员处理	独立显示，不被普通故障消音覆盖
S2	可能损坏设备或批量影响产品	停相关单元，隔离产品，尽快维修	高优先级声音/灯光，保留首发
S3	当前循环失败但风险受控	操作员按验证过的步骤处理	明确动作提示，避免多条连锁弹窗
S4	维护提醒或性能退化	计划处理	不抢占高优先级界面
Info	等待、切换和普通事件	无需故障响应	事件区显示，不发持续蜂鸣

字母和级数没有统一答案，关键是每一级后果、响应和权限一致。若项目把所有故障都设为最高等级，结果不是更安全，而是高优先级失去区分度。

七、恢复类型必须写进报警属性

不同故障需要不同恢复方式。恢复权限不能只靠操作员“知道规矩”，应由状态机和报警属性共同限制。

恢复类型	适用条件	系统动作
自动消除	条件短时波动、无安全与产品风险，且重试已被验证	条件恢复后清除状态，保留历史事件
有限自动重试	故障机理允许，重试次数与间隔已验证	记录每次重试，超限升级为人工处理
操作员验证后恢复	需要确认物料、夹具或产品状态，但无需进入危险区域	HMI 引导检查项，验证完成后才能恢复
现场维护后恢复	需要停机隔离、进入设备或拆装	获授权维修人员按程序处理并完成恢复验证
安全程序处理	涉及安全功能、旁路或防护状态	普通控制程序不得自动绕过，按风险评估与现场安全程序执行

自动重试最容易被滥用。视觉通信偶发超时可以在受控条件下重试一次，但机械卡阻、夹持不确定、产品可能受损或安全状态不清时，重复动作可能扩大损坏。每个自动重试都应回答：为什么重试不会加重后果；最多几次；两次之间检查什么；失败后怎样升级；是否保存第一次失败证据。

操作员验证后恢复也不是把一个按钮改成“确认”。系统应展示可执行检查，例如“确认产品已隔离并扫描产品号”“确认夹具内无松动物”“完成参考件验证”。检查项太抽象，人员只会机械点击。

八、安全旁路与普通报警确认必须分开

报警确认只表示某人看见了信息，不能改变安全功能状态。确认、消音、条件消除和恢复运行是四个不同动作：

• 确认：记录人员已看见并接管；
• 消音：停止声音，但报警仍处于活动状态；
• 条件消除：触发条件已经不成立；
• 恢复运行：经过相应验证后，状态机允许重新进入目标模式。

安全门、光幕、安全停止或相关监控出现异常时，普通 HMI 确认不得自动恢复危险运动。任何未经受控授权的安全旁路、屏蔽、短接或强制，都不能被包装成普通报警的“临时忽略”。进入正常生产或自动模式前，旁路必须清除并完成安全功能验证。

受控维修确需临时旁路时，只能在五项条件同时满足时执行：完成风险评估、取得书面批准、安排专人监护、采用限速或受控运动、设置明确失效时限。到期、人员变化或作业条件变化时立即撤销。报警系统应显示旁路对象、授权人、启用时间和剩余时限，并阻止旁路状态被普通确认隐藏。

这部分逻辑不应由报警文字代替。旁路状态应来自安全架构允许的受控机制，普通 PLC 位和 HMI 密码不能冒充安全功能。

九、HMI 文案要回答动作，不要只翻译原始报码

机器人控制器可能给出详细报码，PLC 有互锁位，视觉软件有内部错误码。直接把原始信息堆到 HMI，维修工程师也许看得懂，操作员却不知道下一步做什么。反过来，如果只显示“请联系维修”，每个小问题都会升级。

一条面向现场的报警建议包含：

1. 发生在哪里：2 号单元 1 号气爪；
2. 发生了什么：关闭命令发出后未得到关闭确认；
3. 当前影响：取件步骤已停止，本件状态待确认；
4. 操作员可以做什么：在防护外检查气压允许与产品位置，按产品处置流程隔离本件；
5. 什么时候升级：确认信号仍不成立，或同班重复发生时联系维修；
6. 维修证据：原始输入、阀岛诊断、动作时间和控制器报码。

动作提示应根据角色变化。操作员界面不展示让其拆装或越权处理的步骤；维修界面可以提供电气图纸页码、I/O 地址和诊断趋势；工程师界面再展示程序步骤和版本。不同层次共享同一个 FaultID，避免形成三套互不对应的叫法。

文案还要避免否定套否定。“安全门未关闭信号未满足”很难读，应改成“安全门关闭确认无效”。“机器人未无故障”更是典型的程序变量直译。现场压力大时，短句和明确对象比技术术语堆叠更有用。

十、日志要保存上下文，不能只存发生时间和文字

故障复盘至少需要发生时刻、条件消除时刻、确认时刻、恢复运行时刻和相关状态。只保存“08:32 气爪报警”，无法判断报警持续多久、谁处理、恢复前是否完成产品处置。

上下文建议包括：

• FaultID、CauseGroupID、来源设备与原始报码；
• 主状态、步骤号、模式和当前配方；
• 关键命令/反馈、计时器实际值和门限版本；
• 产品号、载具号和本件处置状态；
• 报警发生、确认、条件消除和恢复的各自时间；
• 操作角色、处理动作和程序版本；
• 自动重试次数、每次结果与升级原因。

时间字段要写明语义。源设备发生时间与上位系统收到时间可能不同；显示到毫秒也不代表系统真的具备毫秒可比性。本篇不展开多设备对时设计，但报警架构必须至少保留事件来自哪里、时间在哪里产生以及日志分辨率，否则“最早一条”可能只是最先上传的一条。

十一、统计指标要先定义起止点

报警次数不能直接等同于故障次数。一个首发故障可能产生十条派生信息；同一状态每个扫描周期重复写入，会让次数失真。统计应以故障链、FaultID 和状态变化为基础，而不是以消息行数为基础。

常用指标可以包括：

• 首发故障次数与持续时间；
• 每个 FaultID 的重复发生间隔；
• 自动重试成功率与升级率；
• 派生报警数 ÷ 首发故障数，用于观察报警泛滥；
• 未确认、长时间活动和频繁抖动报警；
• 故障发生到条件消除、到恢复生产的分段时间。

如果使用 MTTR，必须在项目里定义起止点。示例口径可以是“从首发故障记录生成，到对应设备完成恢复验证并重新具备生产条件的平均时间”；等待备件、等待授权、人员到场和实际维修时间是否包含，应分别记录，不能把一次恢复耗时直接称为 MTTR。不同项目口径不同，跨线比较前必须先确认定义一致。

报警系统自己的质量也可以监控：每小时出现多少条需要人处理的信息；同一原因产生多少派生项；操作员确认但条件未消除的比例；长期搁置的维护提醒。目的不是追求报警越少越好，而是让每条报警都有明确价值。

十二、用故障注入验收报警架构

报警设计不能只靠代码评审。调试阶段应按风险允许的方式做故障注入或信号模拟，逐条验证触发、显示、连锁、恢复和记录。涉及安全功能的测试必须由获授权人员按风险评估和验证计划执行，不能为了验收随意屏蔽防护。

建议验收矩阵至少包含：

验收项	要验证的证据
触发准确	条件成立时报警出现，不成立时不误报
首发冻结	连锁信息出现后首发候选仍可见
状态一致	PLC、HMI、机器人和上位系统指向同一 FaultID
严重度一致	灯光、声音、界面位置与响应要求相符
权限正确	操作员不能执行维修/安全级恢复动作
产品处置	故障件不会在恢复后丢失、重复或混入合格流
重试边界	次数、间隔、证据保存和升级条件有效
历史记录	发生、确认、消除、恢复与版本字段齐全
文案可执行	目标角色能按提示完成动作，不需猜报码

故障注入后，不仅看报警有没有弹出，还要看系统是否停在可理解、可恢复的状态。若关闭气源模拟气爪不到位，恢复气源后程序自动继续取件，而产品位置和夹持状态未经验证，这不是“恢复顺畅”，而是把不确定状态带回自动流程。

十三、完整算例：气爪不到位怎样从一条报警变成一条证据链

假设机器人取件后，PLC 发出气爪关闭命令。设计可分为以下步骤：

1. PLC 记录命令置位时刻和当前步骤号；
2. 在配方规定窗口内等待“关闭有效且打开无效”；
3. 若条件成立，记录动作时间作为趋势，不产生报警；
4. 若超时，生成 CELL02-GRP01-POS-TIMEOUT，冻结命令、双位置输入、气压允许、阀岛诊断、产品号和机器人状态；
5. 机器人停止当前工艺推进，上下游进入由该 FaultID 派生的等待状态；
6. HMI 显示本件待隔离，提示操作员在防护外确认产品是否仍被可靠保持；
7. 若需要进入设备或拆装，由获授权维修人员按停机隔离程序处理；
8. 处理后先完成夹具空动作与状态验证，再按产品处置结果决定是否恢复当前循环；
9. 条件消除和恢复时间分别写入同一故障链；
10. 若同班重复出现，升级为维修分析，不允许无限点击重试。

这里没有把“气爪不到位”直接等同于气爪坏了。FaultID 描述的是可观察条件，物理根因要靠气压、阀岛、传感器、机构和产品状态进一步判断。报警架构负责保存证据和限制错误恢复，维修方法负责找到根因，两者不能混成一句“请检查气爪”。

十四、四种不该采用的做法

第一，不是报警越多越完整。等待、状态和普通事件应进入各自区域；只有需要人员响应的信息才占用报警通道。

第二，不是自动重试越多越智能。重试会改变现场并覆盖第一次失败证据；机械状态、产品状态或安全条件不确定时，应停止并按角色验证。

第三，不是最早显示的文字就一定是根因。应结合控制因果、首发冻结和源设备证据，区分发生时间与上传时间。

第四，不是确认按钮按下就可以恢复。确认只代表有人看见；触发条件消除、产品处置完成、安全状态验证和模式允许，才构成恢复生产的条件。

一套好的报警架构，现场感受通常不是“信息更多”，而是第一次打开页面就能看见第一原因、当前后果和下一步动作；工程师事后也能用同一个 ID 追到原始设备、程序步骤和产品。把这些结构在设计期写进控制标准，比设备投产后靠维修人员记住一千条报码更便宜，也更可靠。

撰文：EVST Editorial Team