3、数据采集与集成：设备数据采集（SECS/GEM）、EDA数据导入、MES数据对接
好，咱们进入第三章。这一章，说白了就是解决一个核心问题——数据从哪来。
你想想看，良率管理软件再牛，没有数据就是空壳子。我见过不少新入行的工程师，一上来就搞算法、搞模型，结果发现数据源都没打通，白忙活一场。所以这一章，咱们把数据采集和集成这件事彻底讲透。
3.1 设备数据采集：SECS/GEM 协议
先聊设备数据采集。半导体厂里，设备是数据的源头。怎么把设备的数据拿过来？业界标准就是 SECS/GEM。
SECS/GEM 不是单个协议，是一套协议族。我简单给你拆解一下：
- SECS-I：基于 RS-232 串口，老设备用得多，速度慢，但稳定。
- HSMS：基于 TCP/IP，现在的主流。速度快，适合大数据量传输。
- SECS-II：定义消息格式和内容，不管底层是串口还是网络。
- GEM：在 SECS-II 之上，定义了设备行为模型，比如状态机、报警、数据采集等。
我个人习惯，把 GEM 理解成「设备的 API 文档」。它规定了设备该报告什么、什么时候报告、怎么报告。
3.1.1 连接与通信
设备端通常有个 Equipment Interface (EI) 软件，负责把设备内部数据转成 SECS/GEM 消息。主机端（就是你那台良率管理服务器）通过 HSMS 连上去。
连接过程大致是这样：
- 主机发起 TCP 连接（端口通常是 5000 或 5001）。
- 双方交换
Select.req和Select.rsp，建立通信会话。 - 主机发
EstablishCommunicationsRequest，设备回CommunicationsStateData。 - 好了，可以开始收数据了。
嗯，这里要注意：连接超时和重连机制一定要写好。我在项目中遇到过，设备半夜重启，主机没重连，结果一晚上数据全丢了。后来我加了个心跳检测，每 10 秒发一次 LinkTest.req，断了就自动重连。
3.1.2 数据采集项
设备能采集什么数据？GEM 里有个概念叫 Data Variable (DV) 和 Equipment Constant (EC)。
- DV：动态数据，比如温度、压力、功率、气体流量。每次测量都会变。
- EC：静态配置，比如腔室编号、工艺配方名称。基本不变。
我建议你一开始就把所有 DV 和 EC 列个清单，跟设备厂商确认好。别等到上线了才发现少了个关键参数。
3.1.3 报警与事件
设备不光要传数据，还要传报警和事件。GEM 定义了 Alarm 和 Event 两种机制。
- Alarm：设备出问题了，比如温度超限、门没关好。主机收到后要立刻响应。
- Event：设备状态变化，比如晶圆开始加工、加工完成。主机用来跟踪批次进度。
我曾经踩过一个坑：设备报了 Alarm，但主机没及时处理，结果晶圆在腔室里过烧了。后来我写了个规则——Critical Alarm 必须在 5 秒内通知操作员，否则自动停线。
3.2 EDA 数据导入
EDA 数据，就是设计数据。良率管理里，EDA 数据主要用来做 设计-制造相关性分析。比如，某个缺陷是不是跟版图上的特定图形有关？
常见的 EDA 数据格式有：
- GDSII：最古老也最通用的版图格式。
- OASIS：GDSII 的压缩版，文件更小。
- LEF/DEF：抽象版图，用于物理验证。
- SPICE：电路网表，用于电学分析。
导入 EDA 数据，说白了就是把设计文件解析成良率软件能理解的格式。我一般分三步走：
- 格式转换：把 GDSII 或 OASIS 转成内部数据结构（比如四叉树）。
- 分层处理：版图有很多层（比如多晶硅层、金属层），每层单独索引。
- 坐标对齐：把设计坐标和制造坐标对齐。这一步容易出错，因为制造过程会有缩放和偏移。
我记得有一次，客户说他们的良率分析结果总是不准。我查了半天，发现是 EDA 数据导入时坐标没对齐，偏差了 0.1 微米。别小看这 0.1 微米，在先进工艺里，这可能导致几十个芯片被判废。
3.3 MES 数据对接
MES（制造执行系统）是工厂的中枢神经。它管着批次、工单、设备状态、工艺参数、测量结果……几乎所有跟生产相关的数据。
良率管理软件跟 MES 对接，主要做两件事：
- 拉数据：从 MES 拿批次信息、测量数据、设备日志。
- 写数据：把良率分析结果写回 MES，比如判定某批次是否需要返工。
3.3.1 接口方式
MES 的接口五花八门。我见过的主要有这几种：
| 接口类型 | 特点 | 适用场景 |
|---|---|---|
| REST API | 基于 HTTP，JSON 格式，简单灵活 | 现代 MES，云部署 |
| SOAP Web Service | 基于 XML，功能强大但笨重 | 老牌 MES，如 Siemens、Applied |
| 数据库直连 | 直接读 MES 的数据库表 | 紧急情况，或者 MES 没有 API |
| 消息队列 | 如 Kafka、RabbitMQ，异步解耦 | 高吞吐、实时性要求高的场景 |
我个人最推荐 消息队列。为什么？因为 MES 的数据量太大了，如果用 REST API 轮询，服务器扛不住。用消息队列，MES 主动推送，良率软件被动接收，轻松又高效。
3.3.2 数据模型映射
MES 的数据模型跟良率软件的数据模型通常不一样。比如，MES 里一个批次叫 LotID，良率软件里可能叫 BatchID。你得做个映射表。
我建议你建一个 中间层，专门负责数据转换。这样 MES 换接口了，或者良率软件升级了，只改中间层就行，不用动核心逻辑。
3.3.3 实时性要求
不同数据对实时性的要求不一样：
- 设备状态：秒级。设备一停，良率软件要立刻知道。
- 测量数据：分钟级。晶圆测完了，数据最好在 5 分钟内进良率系统。
- 批次信息：小时级。批次流转信息，晚一两个小时问题不大。
我曾经帮一个客户优化过数据对接。他们原来所有数据都用 REST API 轮询，每 30 秒查一次。结果 MES 服务器 CPU 经常 100%。后来我改成：设备状态用消息队列，测量数据用批量导入（每 5 分钟一次），批次信息用定时任务（每小时一次）。CPU 使用率直接降到 20%。
3.4 数据质量与校验
数据采进来了，不代表就能直接用。数据质量是个大问题。
我总结了几种常见的数据质量问题：
- 缺失值：某个参数没采到，或者采到的是空值。
- 异常值：温度突然跳到 1000°C，明显是传感器坏了。
- 重复值：同一条数据被采了两次。
- 时间戳错乱：数据的时间顺序不对，或者时间戳格式不统一。
我的做法是，在数据入库前加一道 校验层：
- 检查必填字段是否为空。
- 检查数值是否在合理范围内（比如温度 20-300°C）。
- 检查时间戳是否单调递增。
- 检查是否有重复记录（用唯一键去重）。
嗯，这里要特别提醒：数据校验不能太严格。太严格了，正常数据也可能被误杀。我一般设一个「警告」级别和一个「拒绝」级别。警告级别的数据先标记，人工审核；拒绝级别的数据直接丢弃并报警。
好了，这一章就到这里。数据采集与集成，听起来简单，做起来全是细节。下一章咱们聊聊数据清洗和预处理，那又是另一番天地。