📚 课程目录第2章设备状态模型与SEMI标准速览

2. 设备状态模型与SEMI标准速览

在EAP系统中，设备状态不是“设备现在好不好”的一句描述，而是一套可被采集、可被判定、可被追溯的结构化模型。EAP要做的第一件事，是把设备控制器、PLC、SECS/GEM接口或日志中零散的信号，映射成统一的状态语义，再基于状态驱动事件采集与异常处理。理解设备状态模型，是后续所有监控逻辑的起点。

一、设备状态分类：从物理状态到逻辑状态

半导体设备常见的状态分类通常包括：运行（Running/Productive）、待机（Standby/Idle）、故障（Down/Fault）、维护（Maintenance）、工程（Engineering）、非计划停机（Unscheduled Down）等。不同标准对状态名称和层级有细微差异，但核心逻辑一致：状态描述设备“当前是否具备生产条件、是否正在产出、是否被占用”。

实际建模时，建议区分三层：物理层（如门开关、真空、温度、报警位）、逻辑层（如Idle、Run、Down）、业务层（如可派工、不可派工、需PM）。EAP通常采集物理层信号，在逻辑层做状态判定，再向MES提供业务层状态。例如，一台刻蚀机腔体真空度未达标，物理层是“真空未就绪”，逻辑层可能是“Standby”，业务层则是“不可派工”。

二、SEMI标准要点：E10、E30、E58、E116

SEMI E10定义了设备可靠性、可用性、可维护性（RAM）的通用状态模型，是设备状态分类的“母标准”。它将设备时间划分为六大类：总时间、运行时间、待机时间、工程时间、计划停机、非计划停机。E10的核心价值在于：用时间账本的方式，把设备状态与产能损失关联起来。

SEMI E30（GEM）规定了设备与主机之间的通用设备通信模型，包括状态变量、事件、报警、数据采集等。E30不直接定义“运行/待机”，但它定义了状态如何被上报、事件如何被触发。EAP开发中，E30是SECS-II消息与状态模型之间的桥梁。

SEMI E58（ARAMS）关注设备自动可靠性、可用性和可维护性数据采集，强调自动获取状态与停机原因，减少人工录入。它要求设备能自动区分“计划停机”与“非计划停机”，并记录原因代码。

SEMI E116（EPT）则聚焦设备性能跟踪，定义设备状态与性能指标（如OEE、吞吐量、利用率）之间的数据模型。E116更偏向数据分析和KPI计算，适合与E10配合使用。

记忆口诀：E10管“时间怎么分”，E30管“状态怎么传”，E58管“停机怎么记”，E116管“性能怎么算”。

三、状态与事件的关系

状态是“持续一段时间的条件”，事件是“状态发生变化的瞬间”。例如，设备从Run变为Idle，这是一个状态迁移，同时触发一个“StateChange”事件。EAP采集事件时，必须同时记录：事件时间戳、旧状态、新状态、触发源（如PLC位、SECS消息、操作员操作）、原因代码。

状态与事件的关系可以概括为：状态是事件的上下文，事件是状态迁移的触发器。没有状态模型，事件只是一堆无意义的信号；没有事件，状态模型无法感知变化。实际系统中，EAP通常维护一个“当前状态表”，每收到一个事件，就更新状态表并判断是否需要上报MES或触发告警。

四、状态机建模方法

状态机建模是EAP状态管理的核心方法。推荐采用“有限状态机（FSM）”思路：定义状态集合、迁移条件、动作和事件输出。建模步骤包括：

枚举状态：根据E10和业务需求，列出设备所有可能状态，如Idle、Run、Down、PM、Eng。
定义迁移条件：明确每个迁移的触发信号，如“Start按钮按下”“报警Alarm 101触发”“PM工单开始”。
定义动作：迁移时执行的操作，如记录事件、更新数据库、发送SECS消息、触发MES上报。
处理异常：定义非法迁移的兜底逻辑，如未知状态时保持原状态并告警。

下面用一个简化的状态机示意图，展示设备从Idle到Run、Down、PM的核心迁移路径。图中标注了典型触发条件，便于理解状态与事件的对应关系。

在代码实现层面，状态机通常用枚举加迁移表表达。例如，用Python字典定义迁移规则，每收到一个事件就查表判断是否允许迁移，并执行对应动作。关键点在于：迁移条件必须可配置，因为不同设备、不同工艺、不同客户对“什么算Run、什么算Down”的定义可能不同。EAP系统应支持从配置文件或数据库加载状态机定义，而不是硬编码在代码里。

# 示例：状态迁移表（简化）
transitions = {
    ("Idle", "Start"): "Run",
    ("Run", "ProcessEnd"): "Idle",
    ("Run", "Alarm"): "Down",
    ("Down", "Clear"): "Idle",
    ("Idle", "PMStart"): "PM",
    ("PM", "PMEnd"): "Idle",
    ("Idle", "EngMode"): "Eng",
    ("Eng", "ExitEng"): "Idle",
}

def on_event(current_state, event):
    next_state = transitions.get((current_state, event))
    if next_state:
        log_event(current_state, event, next_state)
        return next_state
    else:
        log_warning(f"非法迁移: {current_state} + {event}")
        return current_state

实际项目中，状态机还需要处理“复合状态”和“并行状态”。例如，设备可能同时处于“Run”和“Alarm”状态，这时需要定义优先级：Alarm优先于Run，或者用子状态表达。E10的RAM模型也要求区分“计划停机”和“非计划停机”，这需要在状态迁移时记录原因代码，而不是只看状态名称。

常见误区：把“报警发生”直接等同于“设备Down”。实际上，有些报警不影响生产，设备仍处于Run状态。EAP必须结合报警等级、设备信号和工艺上下文，才能正确判定状态迁移。

总结来说，设备状态模型是EAP的“骨架”，SEMI标准是“语言规范”，状态机是“行为逻辑”。三者结合，才能让EAP从被动采集走向主动感知，为后续的事件采集、异常处理和OEE分析打下基础。