上一篇我们讲了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 RequestMCS要确认收到。AMHS回报Carrier已经到达MCS要更新状态。Stocker报错取货失败MCS要把异常往上抛给MES。在Fab里接口消息不能“差不多”因为一个Carrier位置错了后面可能整条链路都乱。第二层搬运请求管理层 Request Management这一层负责管理所有搬运需求。它会处理 新建搬运请求 修改搬运请求⛔ 取消搬运请求⏸️ 挂起搬运请求▶️ 恢复搬运请求 查询搬运状态比如MES发来请求“把FOUP-001从Stocker-A送到ETCH-01。”MCS不会立刻派车而是先把这个请求登记成一个可管理的对象分配Request ID记录来源、优先级、起点、终点、时间戳等信息。这样做的好处是一旦搬运失败系统可以知道是谁发起的什么时候发起的失败在哪一步要不要重试要不要取消要不要通知上游系统第三层状态模型层 State ModelMCS真正的难点之一是维护“现场状态的数字镜像”。它要持续维护这些状态 Carrier位置 Carrier状态 OHT状态 Stocker状态 路径状态 Load Port状态 Zone / Track状态⚠️ Alarm状态其中最关键的是Carrier位置。因为所有搬运动作都建立在一个前提上系统知道这个FOUP现在到底在哪里。如果MES认为FOUP在StockerMCS认为FOUP在Load Port现场实际却在人工手推车上那系统就没法正确搬运。所以MCS必须不断接收现场设备回报用事件来刷新自己的状态模型并在状态冲突时触发异常处理。第四层调度与路径规划层 Dispatch Routing这一层是MCS最像“大脑”的地方但它和RTD的“大脑”不一样。RTD调度的是生产批次MCS调度的是搬运资源。它要考虑️ 哪条路径最短 哪条路径不堵 是否需要经过Stocker中转 目标Load Port是否可用⏱️ Hot Lot是否要优先搬运 是否存在Zone限制 是否会造成死锁或拥堵举个例子同一时间有三个任务FOUP-A从Stocker送到ETCH-01FOUP-B从METRO-02送到StockerFOUP-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 HandlingMCS系统最体现水平的地方往往不是正常搬运而是异常恢复。常见异常包括⚠️ 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-AETCH-01的Load Port是否可用搬运路径是否可达是否已有相同Carrier的任务当前AMHS是否可执行如果校验通过MCS进入调度阶段。第四步MCS调度AMHSMCS根据当前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做得快不快不只取决于机台加工时间也取决于它能不能在正确的时间到达正确的位置。
MCS架构深入：它如何连接MES、RTD、AMHS、Stocker和OHT？
上一篇我们讲了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 RequestMCS要确认收到。AMHS回报Carrier已经到达MCS要更新状态。Stocker报错取货失败MCS要把异常往上抛给MES。在Fab里接口消息不能“差不多”因为一个Carrier位置错了后面可能整条链路都乱。第二层搬运请求管理层 Request Management这一层负责管理所有搬运需求。它会处理 新建搬运请求 修改搬运请求⛔ 取消搬运请求⏸️ 挂起搬运请求▶️ 恢复搬运请求 查询搬运状态比如MES发来请求“把FOUP-001从Stocker-A送到ETCH-01。”MCS不会立刻派车而是先把这个请求登记成一个可管理的对象分配Request ID记录来源、优先级、起点、终点、时间戳等信息。这样做的好处是一旦搬运失败系统可以知道是谁发起的什么时候发起的失败在哪一步要不要重试要不要取消要不要通知上游系统第三层状态模型层 State ModelMCS真正的难点之一是维护“现场状态的数字镜像”。它要持续维护这些状态 Carrier位置 Carrier状态 OHT状态 Stocker状态 路径状态 Load Port状态 Zone / Track状态⚠️ Alarm状态其中最关键的是Carrier位置。因为所有搬运动作都建立在一个前提上系统知道这个FOUP现在到底在哪里。如果MES认为FOUP在StockerMCS认为FOUP在Load Port现场实际却在人工手推车上那系统就没法正确搬运。所以MCS必须不断接收现场设备回报用事件来刷新自己的状态模型并在状态冲突时触发异常处理。第四层调度与路径规划层 Dispatch Routing这一层是MCS最像“大脑”的地方但它和RTD的“大脑”不一样。RTD调度的是生产批次MCS调度的是搬运资源。它要考虑️ 哪条路径最短 哪条路径不堵 是否需要经过Stocker中转 目标Load Port是否可用⏱️ Hot Lot是否要优先搬运 是否存在Zone限制 是否会造成死锁或拥堵举个例子同一时间有三个任务FOUP-A从Stocker送到ETCH-01FOUP-B从METRO-02送到StockerFOUP-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 HandlingMCS系统最体现水平的地方往往不是正常搬运而是异常恢复。常见异常包括⚠️ 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-AETCH-01的Load Port是否可用搬运路径是否可达是否已有相同Carrier的任务当前AMHS是否可执行如果校验通过MCS进入调度阶段。第四步MCS调度AMHSMCS根据当前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做得快不快不只取决于机台加工时间也取决于它能不能在正确的时间到达正确的位置。
