2. 生产异常事件模型基础

在生产线运行过程中，异常并不是一个孤立的“报警”动作，而是一段有起点、有演化、有终点的过程。要把它描述清楚，必须先把“设备此刻处于什么情况”和“发生了什么变化”区分开。这正是事件模型与状态机建模的出发点：状态描述系统在某一时刻的稳定情形，事件描述打破这种稳定的外部或内部刺激，转移描述状态之间的迁移，动作描述迁移过程中执行的处理，守卫条件则决定这次迁移是否被允许。

五个核心概念及其关系

以一条典型的灌装产线为例。灌装工位可能处于“待机”“运行”“缺料暂停”“故障停机”“清洗中”等状态。当上游供瓶信号到达时，产生一个事件（如 BOTTLE_IN）；如果此时设备处于“待机”且安全门关闭，则允许从“待机”转移到“运行”。安全门关闭这一判断就是守卫条件（guard），它不改变状态，只决定转移能否发生。转移发生时，控制器可以执行动作（action），例如启动输送带、打开灌装阀、写入开始时间戳。

这五个概念的关系可以概括为：事件触发转移，守卫条件过滤转移，动作伴随转移，状态记录转移的结果。缺少守卫条件，模型会在不该动作时误动作；缺少动作，模型只能“知道”变化却无法“响应”变化；缺少状态，模型就无法表达“同一事件在不同情形下含义不同”。例如同样是 STOP 事件，在“运行”状态下应转入“待机”，在“故障停机”状态下则应忽略，因为设备已经停止。

有限状态机与扩展状态机的区别

上面这张图已经隐含了一个问题：如果只用“状态 + 事件 + 转移”来描述，模型会很快遇到表达瓶颈。例如“缺料暂停”状态下，料位从 8% 缓慢回升到 9%、9.5%、9.8%，这些连续变化无法用离散事件逐一表达；再如“运行”状态下，不同批次产品的灌装量不同，仅靠状态名无法携带这些数据。这正是有限状态机（FSM）与扩展状态机（EFSM，Extended FSM）的分界。

有限状态机只包含有限个状态、事件和转移，状态本身不携带变量，守卫条件只能引用外部输入信号。它的优点是形式简单、易于验证，适合逻辑清晰的启停控制。扩展状态机在 FSM 基础上增加了状态变量、转移变量和条件动作：状态可以拥有内部变量（如累计产量、料位百分比、故障计数），转移可以带参数（如 FAULT_DETECT(code=0x12)），动作可以读写这些变量。EFSM 还能表达“同一状态内的事件延迟处理”和“带条件的进入/退出动作”，因此更适合生产异常这类需要记录上下文、区分严重程度、支持恢复判断的场景。

建模符号与表示法

工业现场常用的状态机表示法主要有三种。第一种是状态转移图（State Transition Diagram），即上文 SVG 所用的椭圆节点加带标注箭头，直观但状态多时容易连线交叉。第二种是状态转移表（State Transition Table），以“当前状态 × 事件”为行列表格，单元格填写“目标状态 / 动作 / 守卫”，适合查漏和代码生成。第三种是UML 状态机图，支持复合状态、进入/退出动作、历史伪状态，适合描述带层级和恢复语义的复杂异常处理。

无论采用哪种表示法，转移标注都应遵循统一格式：事件 [守卫条件] / 动作。方括号内为守卫，斜杠后为动作，二者均可省略，但省略守卫意味着“无条件转移”，省略动作意味着“仅改变状态”。这一约定在 IEC 61131-3 的 SFC（顺序功能图）和多数状态机代码生成工具中通用，建议在项目内固定下来，避免同一张图里出现两种写法。

一个可落地的状态转移表片段

把前面的灌装工位模型整理成状态转移表，可以直接作为控制器逻辑或测试用例的输入。下表为示例，参数阈值（10%、0.6MPa）属于教学假设值，实际项目应按工艺文件标定。

当前状态   事件            守卫条件                动作                    目标状态
IDLE       BOTTLE_IN       安全门关闭              启动输送带               RUNNING
RUNNING    STOP            —                       关闭灌装阀               IDLE
RUNNING    NO_MATERIAL     料位 < 10%              暂停灌装、置缺料标志     STARVED
STARVED    MATERIAL_OK     料位 >= 30%             恢复灌装、清缺料标志     RUNNING
RUNNING    FAULT_DETECT    压力 > 0.6MPa           急停、记录故障码         FAULT
FAULT      RESET           故障已清除              复位故障码               IDLE
IDLE       CLEAN_START     设备已停机              启动清洗程序             CLEANING
CLEANING   CLEAN_DONE      —                       复位计数器               IDLE

从这张表可以读出两个工程要点。其一，同一事件在不同状态下目标不同：STOP 在 RUNNING 下转入 IDLE，而在 FAULT 下没有定义转移，意味着该事件被忽略，这本身就是一种安全设计。其二，守卫条件决定了恢复路径是否成立：STARVED 回到 RUNNING 要求料位回升到 30% 而非 10%，这是为了避免在临界点反复抖动，属于典型的滞回设计。若把守卫写成 [料位 >= 10%]，系统可能在 9.9% 与 10.1% 之间频繁切换，造成设备频繁启停。

理解这五个概念以及 FSM 与 EFSM 的差异，是后续建立异常分级、恢复策略和状态机代码结构的前提。建模时先问三个问题：系统有哪些稳定状态？哪些事件会打破稳定？打破之后允许做什么、不允许做什么？把这三个问题回答清楚，状态转移图和转移表自然就能落地。