设备控制最怕“流程散落在按钮事件和回调里”。正常路径或许能跑，一遇超时、暂停和恢复便出现重复动作。状态机明确系统现在是什么，调度器则决定下一步允许做什么。
1. 状态、事件、守卫与动作
状态机由当前状态、触发事件、转换条件和动作组成。例如机械手只有在已归零、无报警、目标端口可用且晶圆状态可信时，才能从 Idle 转入 Moving。守卫条件失败应留下明确原因，而不是静默无响应。
状态要表达业务语义，避免用几十个布尔值拼装现实。IsMoving=false 既可能是已到位，也可能是报警停机；二者显然不能执行相同后续动作。
2. 分层状态机避免“超级状态机”
整机、模块、任务和晶圆各有生命周期。整机可能处于 Productive，机械手处于 Idle，某片晶圆处于 Processing。把所有组合塞进一个状态机会产生状态爆炸。
更合理的方式是分层建模，并定义清晰的聚合规则：模块故障怎样提升为整机不可用，任务取消怎样传播到子动作，安全状态又怎样拥有最高优先级。
3. 调度本质是受约束的资源分配
多腔设备中，机械手、对准器、腔体和缓存位都是有限资源。调度器要满足晶圆工艺顺序、驻留时间、腔体能力、污染兼容性和互斥约束，再优化吞吐量。
锁资源时应规定全局顺序，或由集中式调度器一次分配，避免两个任务互相等待。资源占用还要带租约或恢复机制，防止进程异常后留下“幽灵锁”。
4. 暂停、取消和急停必须分开
暂停通常在安全点停止并保留继续条件；取消要终止任务并执行收尾；急停优先消除危险，可能来不及保持业务一致性。三者若共用一个布尔标志，恢复语义必然混乱。
动作要标识能否中断、能否重试以及是否幂等。晶圆加工完成后的消息重发可以幂等，物理加工本身通常不能简单重做。
5. 用事件日志重建过程
每次状态转换应记录旧状态、新状态、触发源、晶圆上下文和关联 ID。事件日志不是为了“多打日志”，而是让工程师能够回答某片晶圆为何走到这里。
总结
状态机提供确定性，调度器提供并发效率。先把状态、资源和失败语义建模清楚，再谈最优排程；否则提升的吞吐量会被死锁、恢复失败和误加工抵消。