2. Fab良率监控系统架构总览
Fab良率监控系统采用经典的四层分层架构,将数据从采集到最终可视化展示进行解耦。每一层职责明确,通过标准化的接口进行交互,确保系统具备高可扩展性、低耦合性和实时处理能力。本章将详细阐述各层的核心职责、技术选型以及层间交互流程。
架构设计核心原则: 分层解耦、数据单向流动、接口标准化、故障隔离。
2.1 系统分层架构总览
系统自底向上分为:数据采集层、数据处理层、分析层和展示层。数据从设备端产生,经过清洗、聚合、分析,最终以图表或告警形式呈现给工程师。
架构优势: 每一层都可以独立扩展。例如,当Fab新增机台时,只需在采集层增加采集节点,上层无需改动;当需要引入新的分析算法时,只需在分析层增加服务模块。
2.2 各层职责详解
2.2.1 数据采集层
数据采集层是系统的“触角”,负责从Fab内的各类设备、传感器和MES系统中获取原始数据。该层必须支持多种工业协议,并保证数据采集的实时性和完整性。
- 设备数据: 通过SECS/GEM协议从刻蚀机、光刻机、沉积设备等工艺机台采集工艺参数(温度、压力、RF功率等)。
- 量测数据: 从CD-SEM、膜厚仪、缺陷检测设备获取晶圆关键尺寸和缺陷信息。
- 日志数据: 收集设备日志、操作日志和系统日志,用于异常追溯。
- 环境数据: 采集洁净室的温湿度、颗粒度等环境参数。
| 数据源类型 | 典型协议/接口 | 数据频率 | 数据量级 |
|---|---|---|---|
| 工艺机台 | SECS/GEM (HSMS) | 秒级 ~ 毫秒级 | 高 (每机台每天数GB) |
| 量测设备 | OPC-UA / 文件共享 | 批次级 (每批一次) | 中 (每批次数MB) |
| MES系统 | REST API / 数据库视图 | 事件驱动 | 低 (KB级) |
| 环境传感器 | MQTT / Modbus | 分钟级 | 低 (MB级/天) |
2.2.2 数据处理层
数据处理层是系统的“消化系统”,负责对采集到的原始数据进行清洗、转换、标准化和聚合。该层需要同时支持实时流处理和批量处理两种模式。
- 数据清洗: 剔除异常值、填充缺失值、处理重复数据。
- 数据标准化: 将不同设备、不同格式的数据统一为内部标准格式(如JSON Schema或Avro)。
- 实时聚合: 使用Flink或Spark Streaming计算秒级/分钟级的统计指标(均值、标准差、CPK等)。
- 批量处理: 使用Spark或Hive进行日/周级别的批次聚合,生成良率汇总报表。
关键挑战: Fab内设备种类繁多,数据格式差异巨大。数据处理层必须设计灵活的Schema Registry和字段映射规则,避免因数据格式变更导致下游分析任务失败。
2.2.3 分析层
分析层是系统的“大脑”,承载了良率监控的核心业务逻辑。该层利用统计学和机器学习算法,对处理后的数据进行深度分析,并生成控制规则和预测模型。
- SPC统计过程控制: 实时计算控制图(X-bar、R图、P图等),检测工艺偏移和异常波动。
- 良率预测: 基于历史数据和当前工艺参数,使用回归或分类模型预测批次良率。
- 缺陷根因分析: 通过关联规则挖掘或决策树,定位导致良率下降的关键工艺步骤或设备参数。
- 批次追踪: 支持按批次号、晶圆ID、设备ID等多维度追溯,快速定位问题批次。
| 分析模块 | 输入数据 | 输出结果 | 典型算法 |
|---|---|---|---|
| SPC控制 | 实时工艺参数 | 控制图、告警事件 | Western Electric规则 |
| 良率预测 | 历史良率 + 工艺参数 | 预测良率值、置信区间 | 随机森林 / XGBoost |
| 根因分析 | 缺陷数据 + 设备日志 | 根因列表、贡献度排序 | 关联规则 / SHAP值 |
| 批次追踪 | 批次ID | 全链路工艺记录 | 图数据库查询 |
2.2.4 展示层
展示层是系统的“窗口”,负责将分析结果以直观、易理解的方式呈现给不同角色的用户(工艺工程师、设备工程师、生产主管等)。该层需要支持多终端适配和实时数据刷新。
- Web Dashboard: 提供良率总览、设备OEE、缺陷分布等核心看板。
- 实时告警: 当SPC规则被触发或良率预测低于阈值时,通过WebSocket推送告警至浏览器或移动端。
- 报表生成: 支持按日/周/月导出PDF或Excel格式的良率报告。
- 大屏展示: 在Fab现场部署大屏,实时滚动显示关键良率指标。
2.3 层间交互流程
各层之间通过标准化的API和消息队列进行通信,确保数据流动的可靠性和可追溯性。典型的交互流程如下:
- 采集层 → 处理层: 采集层将原始数据封装为标准消息,通过Kafka发送至数据处理层。每条消息包含设备ID、时间戳、参数名和参数值。
- 处理层 → 分析层: 处理层完成清洗和聚合后,将标准化数据写入时序数据库(如InfluxDB或TimescaleDB),并通过REST API或gRPC接口供分析层调用。
- 分析层 → 展示层: 分析层将计算结果(如SPC告警、预测良率)写入Redis或内存数据库,展示层通过WebSocket订阅实时数据,或通过HTTP接口查询历史数据。
2.4 架构设计关键考量
高可用设计: 每一层都采用集群部署,避免单点故障。Kafka集群保证数据不丢失,Flink/Spark集群保证计算任务的高可用,Web服务采用负载均衡。
数据一致性: 在实时流处理中,使用Kafka的Exactly-Once语义保证数据不重复不丢失;在批量处理中,通过事务和检查点机制保证数据一致性。