企业官网建设流程全解析

上一篇我们讲了MCS是什么：它不是决定生产优先级的系统，而是晶圆厂里的物料搬运控制系统。

如果说MES管“这批料是什么状态”，RTD管“下一步该去哪台机台”，那么MCS管的就是：

📦这批FOUP现在在哪里

🚝怎么把它送到目标位置

✅送完以后，现场状态是否一致

这一篇，我们就深入看看MCS背后的系统架构，以及它是怎么和MES、RTD、AMHS、Stocker、OHT协同工作的。

🧩 先看一张MCS协同关系图

你可以把MCS放在整个自动化物流链路的中间位置：

MCS既不是最高层的生产决策者，也不是最底层的机械控制器。

它更像一个“物流中控层”：
上接生产系统，下接自动化搬运设备，把“生产意图”翻译成“现场动作”。

🏗️ MCS的核心架构通常分几层？

一个成熟的MCS，通常不会只是一个简单的搬运队列，而是由多个模块组成。

核心可以分成六层：

第一层：接口层 Interface Layer

接口层负责和外部系统通信。

它连接的对象主要包括：

🔗 MES
🔗 RTD
🔗 AMHS-SERVICE
🔗 Alarm / SPC / Reporting系统

接口层最重要的任务不是“传消息”，而是保证消息准确、可追踪、可恢复。

比如：

MES发来一个Move Request，MCS要确认收到。
AMHS回报Carrier已经到达，MCS要更新状态。
Stocker报错取货失败，MCS要把异常往上抛给MES。

在Fab里，接口消息不能“差不多”，因为一个Carrier位置错了，后面可能整条链路都乱。

第二层：搬运请求管理层 Request Management

这一层负责管理所有搬运需求。

它会处理：

📦 新建搬运请求
🔄 修改搬运请求
⛔ 取消搬运请求
⏸️ 挂起搬运请求
▶️ 恢复搬运请求
📊 查询搬运状态

比如MES发来请求：“把FOUP-001从Stocker-A送到ETCH-01。”

MCS不会立刻派车，而是先把这个请求登记成一个可管理的对象，分配Request ID，记录来源、优先级、起点、终点、时间戳等信息。

这样做的好处是，一旦搬运失败，系统可以知道：

是谁发起的？
什么时候发起的？
失败在哪一步？
要不要重试？
要不要取消？
要不要通知上游系统？

第三层：状态模型层 State Model

MCS真正的难点之一，是维护“现场状态的数字镜像”。

它要持续维护这些状态：

📍 Carrier位置
📦 Carrier状态
🚝 OHT状态
🏬 Stocker状态
🧭 路径状态
🔌 Load Port状态
🛑 Zone / Track状态
⚠️ Alarm状态

其中最关键的是Carrier位置。

因为所有搬运动作都建立在一个前提上：

系统知道这个FOUP现在到底在哪里。

如果MES认为FOUP在Stocker，MCS认为FOUP在Load Port，现场实际却在人工手推车上，那系统就没法正确搬运。

所以MCS必须不断接收现场设备回报，用事件来刷新自己的状态模型，并在状态冲突时触发异常处理。

第四层：调度与路径规划层 Dispatch & Routing

这一层是MCS最像“大脑”的地方，但它和RTD的“大脑”不一样。

RTD调度的是生产批次，MCS调度的是搬运资源。

它要考虑：
🛤️ 哪条路径最短
🚦 哪条路径不堵
🏬 是否需要经过Stocker中转
📍 目标Load Port是否可用
⏱️ Hot Lot是否要优先搬运
🧱 是否存在Zone限制
🔁 是否会造成死锁或拥堵

举个例子：

同一时间有三个任务：

1. FOUP-A：从Stocker送到ETCH-01
2. FOUP-B：从METRO-02送到Stocker
3. FOUP-C：从PHOTO区送到CVD区

MCS需要决定哪些任务先执行，哪些OHT去执行，路径怎么走，是否需要避开拥堵区域。

它不改变RTD给出的生产目标，但会根据现场物流条件选择最可执行的搬运方式。

第五层：任务执行层 Transfer Execution

当请求通过校验、资源也准备好之后，MCS会生成具体的搬运任务。

比如：

📌 从Stocker-A取FOUP-001
📌 搬运到ETCH-01 Load Port 2
📌 放下并确认Carrier ID
📌 回报搬运完成

任务执行过程中，MCS要持续追踪每个阶段：

✅ Command Sent
✅ Vehicle Assigned
✅ Carrier Picked
✅ Carrier Moving
✅ Carrier Placed
✅ Transfer Completed

如果任何一步失败，都不能简单地“重试一下”就完事。

因为Fab里的每一次搬运都涉及真实设备和真实晶圆，系统必须知道Carrier现在到底在哪里、设备有没有占用、目标端口是否安全。

第六层：异常处理与恢复层 Exception Handling

MCS系统最体现水平的地方，往往不是正常搬运，而是异常恢复。

常见异常包括：

⚠️ Carrier ID不匹配
⚠️ 取货失败
⚠️ 放货失败
⚠️ 目标端口被占用
⚠️ OHT中途异常
⚠️ Stocker不可用
⚠️ 路径堵塞
⚠️ 搬运超时
⚠️ MES/MCS/AMHS状态不一致

成熟的MCS不会只显示一个Alarm，而是要支持：

🔍 自动定位异常点
🔄 自动重试
⏸️ 任务挂起
🧭 重新规划路径
📍 位置校正
📣 通知MES或操作员介入
📝 保留完整日志和追溯记录

对Fab来说，异常恢复速度非常重要。因为一个搬运任务卡住，可能会导致一台机台Idle；一台关键机台Idle，可能会影响一批Hot Lot；一批Hot Lot延误，可能就会影响客户交期。

🔄 一次完整搬运是怎么发生的？

我们用一个典型场景串起来：

场景：RTD决定让Lot A去ETCH-01加工。

第一步：RTD做生产决策

RTD根据Lot优先级、Q-Time、机台能力、当前WIP状态等因素，决定：

Lot A下一步应该去ETCH-01。

但RTD通常不会直接控制OHT。它只是输出生产派工结果。

第二步：MES确认Lot状态

MES检查Lot A是否真的可以执行下一步工艺：

✅ 当前工序正确
✅ Recipe存在
✅ Lot没有Hold
✅ 前置条件完成
✅ 目标机台可加工

确认没问题后，MES生成搬运请求，告诉MCS：

“请把Lot A对应的FOUP从Stocker-A送到ETCH-01。”

第三步：MCS接收请求并校验

MCS收到请求后，会检查：

FOUP是不是真的在Stocker-A？
ETCH-01的Load Port是否可用？
搬运路径是否可达？
是否已有相同Carrier的任务？
当前AMHS是否可执行？

如果校验通过，MCS进入调度阶段。

第四步：MCS调度AMHS

MCS根据当前OHT位置、轨道状态、拥堵情况、任务优先级，选择合适的搬运资源。

它可能会决定：

“派最近的一台OHT，从Stocker-A取FOUP，走东侧主轨，送到ETCH-01 Load Port 2。”

随后MCS向AMHS下发Transfer Command。

第五步：AMHS执行搬运

AMHS控制OHT和Stocker完成具体动作：

🚝 OHT移动到Stocker-A
📦 Stocker出库FOUP
📦 OHT取货
🚝 OHT沿轨道移动
📍 到达ETCH-01
📦 放到Load Port 2

这些底层动作由AMHS、OHT Controller、Stocker Controller等现场控制系统完成。

第六步：MCS追踪并回报

搬运过程中，AMHS不断把状态回报给MCS。

MCS更新Carrier位置和任务状态。

当FOUP成功放到ETCH-01后，MCS向MES回报：

“Transfer Completed。”

MES再更新Lot位置与设备状态，后续EAP可以开始与机台交互，准备执行工艺。

🧠 MCS不是万能的，它有明确边界

MCS虽然重要，但边界必须清楚。

它不负责：

❌ 决定Lot生产顺序
❌ 判断工艺Recipe是否正确
❌ 控制机台Process Chamber
❌ 计算产品交期
❌ 维护完整工艺流程
❌ 做良率分析

这些分别属于RTD、MES、EAP、APC、SPC等系统。

MCS负责的是：

✅ 搬运请求管理
✅ Carrier位置管理
✅ AMHS任务调度
✅ Stocker出入库协调
✅ OHT路径与任务协调
✅ 搬运状态追踪
✅ 异常处理与恢复

边界清楚，系统才不会互相抢活，也不会出现状态混乱。

⚡ MCS架构设计最重要的几个原则

1. 状态必须可信

MCS最核心的资产不是算法，而是状态。

Carrier在哪里、OHT在哪里、Load Port是否空闲、Stocker是否可用，这些信息必须尽可能准确。

状态不可信，调度就没有意义。

2. 接口必须可追溯

每一条请求、每一个响应、每一次状态变化，都要能追溯。

在Fab现场，排查问题时经常要回答：

“这个FOUP为什么没有送到？”
“是谁取消了任务？”
“AMHS什么时候回报失败？”
“MES和MCS状态什么时候开始不一致？”

没有日志和追踪，异常就会变成黑盒。

3. 异常恢复比正常流程更重要

正常搬运谁都能做，难的是异常之后还能不能恢复。

比如OHT取货失败后，系统是否知道Carrier还在原位？
放货失败后，FOUP是在OHT上，还是目标端口上？
任务取消后，Carrier状态如何回滚？

这才是MCS真正的工程难点。

4. 调度要服务于产线节拍

MCS不是单纯追求最短路径。

有时候最短路径会堵，最近的OHT不一定最优，优先级最高的搬运也可能需要等待目标端口释放。

好的MCS调度，要在搬运效率、设备利用率、Hot Lot响应、拥堵控制之间做平衡。

💡 总结

MCS的复杂性，不在于它“能不能搬”，而在于它要在一个持续变化的Fab现场里，让成千上万个Carrier稳定、准确、可追踪地流动。

它连接MES和RTD的生产意图，也连接AMHS、Stocker、OHT的现场执行。

上层系统告诉它“要送什么、送到哪里”，底层设备告诉它“现在能不能送、送到哪一步了”。

MCS就在中间，把一次次生产决策变成真实的物料移动。

所以，一个成熟的自动化Fab，拼的不只是先进机台和复杂算法，也拼物流系统的稳定性。

因为在晶圆厂里，Lot做得快不快，不只取决于机台加工时间，也取决于它能不能在正确的时间，到达正确的位置。