简介:面向半导体制造与工厂自动化领域的专业研究文档,聚焦300mm半导体工厂中自动物料搬运系统(AMHS)的架构设计与性能优化。内容系统梳理了从200mm工厂SEMI Auto方式向300mm工厂Full Auto方式的演进,详解Tool To Tool直接搬送模式、Interbay与Intrabay整合、Stocker及搬运车辆选型等关键技术,并涵盖UTS等洁净室空间利用方案及MTBF、MTTR、三西格玛搬送时间等性能指标分析。资源共1个文件,为docx格式精编文档,压缩包约436KB,适合半导体设备工程师、工厂自动化规划人员及微电子专业学生参考。同时针对生产空间最大化利用、稳定性与高效性平衡等核心痛点给出系统解答。目前已有145人学习下载,逻辑清晰、要点精炼,可直接用于技术方案评审、报告撰写或AMHS系统认知入门。
1. 300mm工厂的AMHS:为什么它是决定产能的尖兵利器
300mm半导体工厂里,AMHS系统虽然不是直接加工晶圆的设备,却是决定整条产线能不能满负荷跑起来的“隐形瓶颈”。单盒300mm晶圆加上FOUP的重量,已经超过人工搬运的合理上限,每天数千次的搬送频次更让人工介入既不安全也不经济。这台“晶圆配送系统”一旦抖动,设备利用率、WIP Cycle Time、洁净室空间占用全部联动受影响。这篇文章不写泛泛的半导体科普,直接拆AMHS在300mm产线的角色定位、搬运方式演进、性能指标、空间优化和现场调试的坑,给正在做产线规划或AMHS项目评估的工程师一份能对照的实战参考。
2. 搬运方式的进化:从Semi Auto到Full Auto,再到Tool to Tool直送
2.1 Semi Auto到Full Auto:为什么300mm非改不可的结构性原因
在200mm工厂时代,AMHS的主导模式是SEMI Auto(半自动)。Wafer在中央区域Interbay这一段由轨道系统负责,但从Interbay轨道末端取货,再把FOUP送到生产设备的Port上,这一步需要生产现场的操作员人工介入。说白了就是“轨道负责干线,人负责支线”。200mm的Wafer加上FOUP整体重量并不夸张,操作员沿洁净室通道搬上一段,在人力可接受的范围内,所以Semi Auto能支撑当时的生产节奏。
到了300mm,这个思路就撑不住了。首先是重量:300mm FOUP满载一盒晶圆后大约在8~10kg量级,单纯“拎一段”还不算致命,但300mm工厂内设备密度高、产线节奏快,搬运频次比200mm工厂高出一个数量级——每天有效搬送次数动辄上万次。也就是说,如果还保留人工介入,每个班次需要操作员完成上千次取放动作,这已经不是体力问题,而是品质和效率的双重灾难。人工搬送单元在300mm产线里还会带来隐性损失:FOUP在人工搬运时发生磕碰、站别取错、Port放不到位,每一件都会直接变成设备的空闲时间或wafer异常。
所以300mm工厂必须上Full Auto。在Full Auto模式下,AMHS系统的搬送请求由MES或RTD(实时调度系统)自动触发,OHT自动从出发点到目的地完成整段搬送,中间不需要任何人工搬运动作。生产人员只需要在设备侧做上下料确认,而FOUP从Stocker取货、上轨道、经由OHT运送、下降到设备Port的全过程全部自动化。这不仅消除了人为事故,还让产线上所有设备的物料流都变成可预测、可调度的“数字信号”——调度系统知道每一盒FOUP在哪辆车、在哪个路口、什么时候到位,这对后续优化Cycle Time至关重要。
2.2 Tool to Tool直送:路径从四次中转变成一次直达,省的不只是路程
Full Auto解决的是“全程无人”,而Tool to Tool要解决的是“要不要绕路”。先看传统模式的路径:Tool A → Stocker01 → Stocker02 → Tool B。也就是说,一盒FOUP从加工设备A出来,要先进Stocker存一下,再从Stocker取出来,经过轨道系统运到另一个Stocker,最后从Stocker送到设备B。
这个过程看似只是“多存了两次”,但累加的时间非常客观。Stocker的升降机是串行设备,同一时刻只能处理有限数量的FOUP存取,一旦搬送量上来,升降机门口就是天然的排队点。取放FOUP再加上升降机排队,一次Stocker中转的附加时间通常在几十秒到几分钟不等。我把两条搬送路径放在一起对比一下:
| 搬送模式 | 路径 | 中转环节 | 时间影响因素 |
|---|---|---|---|
| 传统中转 | Tool A → Stocker01 → Stocker02 → Tool B | 2次Stocker存取 | 升降机吞吐、排队、调度延迟 |
| Tool to Tool直送 | Tool A → Tool B | 0次Stocker中转 | 轨道拥堵、OHT调度策略、路口等待 |
举例来看:假设两个站点之间轨道里程300米,OHT平均移动速度约1.5m/s,纯移动耗时大约3~4分钟。传统中转路径上,每次进Stocker需要经历“OHT放料→升降机入库→升降机出库→OHT取料”这串动作,加上排队等待,单次存取常常要花掉2~3分钟。两次中转就意味着额外多出5分钟左右的纯等待。折算下来,Tool to Tool直送能将单次搬送时间压缩掉一半以上。
正因为有这种时间价值,Tool to Tool在300mm工厂里已经不只是“可选项”,而是大规模搬送量下的刚需。尤其是设备集中、工序连续性要求高的区域,FOUP不经过Stocker中转直接送到下一站加工设备,能显著减少设备Port的空置时间。
2.3 Tool to Tool落地前提:Interbay与Intrabay整合、布局与车辆选型
Tool to Tool直送不是说改个控制软件就能跑起来,它需要AMHS系统在架构层面做出四个调整。
第一是Interbay与Intrabay的整合。Interbay是连接各生产区域的骨架轨道,Intrabay是各区域内贴近设备的支线轨道。传统200mm工厂里,两条轨道网络相对独立,搬送任务在中转点要交接给不同的车辆或轨道段。而要支撑Tool to Tool,必须把Interbay和Intrabay在逻辑上合并成一张统一的轨道网络,让一辆OHT能从设备A的Port直接开到设备B的Port,中途不掉头、不交接。
第二是工厂布局的配合。Tool to Tool直送的价值建立在“上下游设备距离足够近”的前提下。如果两个工序在物理上相隔极远,OHT在长距离轨道上慢悠悠移动,反而不如先送进就近Stocker等批量转运。实际操作时,工厂规划通常在相邻Bay内布置前后工序的相关设备,让高频率搬送的两个Tool之间轨道距离控制在可接受的范围内。
第三是搬送车辆和Stocker的选型。OHT的负载能力、加速度、轨道转弯半径,决定了它能否胜任长距离直送;而Stocker的容量和分布密度,则是直送模式的兜底方案。即便直送覆盖大部分搬送任务,工厂仍需要保留一定量的Stocker,用于跨bay转运、批次合并、异常暂存和出货缓冲。
第四是控制系统的调度逻辑。Tool to Tool直送路径变短,但OHT的路线规划、优先级判断、路口冲突消解都必须实时完成。控制系统需要快速评估“直送”和“先进Stocker”两种方案在当前交通状态下的预期耗时,动态选择更优的选项——这已经是动态调度器的核心能力,后面第4章展开说明。
3. 把性能“数”出来:MTBF、MTTR与三西格玛搬送时间
3.1 MTBF和MTTR:衡量系统稳定性的两个仪表盘
AMHS在300mm工厂里是全天候运行的基础设施,任何异常停机都可能导致生产设备缺料停摆。衡量系统稳定性的最常用两个参数是MTBF和MTTR。
MTBF(Mean Time Between Failure,平均故障间隔时间)反映系统硬件的故障频率,MTBF越高,表示硬件越稳定、故障率越低。MTTR(Mean Time To Repair,平均修复时间)反映故障发生后的恢复能力,MTTR越低,表示系统可在线使用的能力越高。这两个指标在300mm工厂的AMHS项目中通常会被直接写进采购验收条款,也是日常运维报表里最重要的两个数据。
| 参数 | 衡量维度 | 数值方向 | 对生产的影响 |
|---|---|---|---|
| MTBF | 硬件稳定性 | 越高越好 | MTBF低→频繁故障→设备间歇性缺料 |
| MTTR | 故障修复能力 | 越低越好 | MTTR高→单次故障拖得长→整片区域产量损失 |
在实际项目里,MTBF和MTTR统计口径要注意两点。其一是MTTR必须把“故障上报→备件到位→维修完成→系统恢复”整个链路都算进去,很多工厂只统计维修动作本身,导致报表数据远好于真实停线时间。其二是现场环境对MTBF的影响很大,轨道振动、洁净室温度波动、OHT高频启停都会使现场实测MTBF低于厂商标称值。评估供应商方案时,条件是要让乙方在工厂实际工况下给出参考数据,只拿实验室标称值来论证可不行。
3.2 平均搬送时间与三西格玛搬送时间:平均值达标不代表真的稳定
衡量AMHS搬送效率时,最常用的两个指标是平均搬送时间和三西格玛搬送时间。平均搬送时间就是某时间段内所有搬送任务耗时的算术平均值;三西格玛搬送时间借用了统计学上的三西格玛概念,表示在对应时间内完成的搬送任务量占到总任务量的三西格玛百分比,用来刻画任务耗时的尾部分布。
经常有工厂只看平均搬送时间,结果发现问题都在尾巴里。举一个典型的例子:A线和B线的平均搬送时间都是12分钟。A线的任务耗时集中在11~13分钟,B线则是8分钟左右完成大部分任务、少部分远距离或高拥堵任务耗时超过20分钟。只看平均值,两条线看起来完全一样;一旦考察三西格玛搬送时间,B线的长尾拉到明显高于A线的水平。而设备Port恰恰只关心头尾:它等一盒关键FOUP如果多等5分钟,等待时间就实打实退化成了设备闲置时间。
| 指标 | 定义 | 典型用途 |
|---|---|---|
| 平均搬送时间 | 所有搬送任务耗时的算术均值 | 评估系统整体搬送能力 |
| 三西格玛搬送时间 | 覆盖三西格玛统计区间任务的完成时间 | 识别长尾、评估关键任务按时性 |
| P95/P99搬送时间 | 95%/99%任务完成时间 | 长尾监控、KPI辅助指标 |
在Full Auto模式下,这两个指标直接关系到生产设备能否保持高利用率,也会影响Wafer的Cycle Time。因此多数300mm工厂会同时监控平均搬送时间和三西格玛搬送时间,后者的考核标准往往定得比平均值严格得多。
3.3 AMHS是多元非线性系统:传统控制理论不够用,离散事件仿真成为主流手段
AMHS系统由数十台OHT、上百个轨道节点、多个Stocker和一套控制软件组成。各台OHT之间既共享轨道资源,又在交汇路口竞争通行权,还要受制于Stocker升降机吞吐能力的影响。这种系统的行为呈现明显的非线性特征:某个路口拥堵的波动,可能通过OHT路径选择传播到相邻区域,最终形成全厂级连锁反应。传统控制理论依赖线性化假设和传递函数建模,在面对这种规模的非线性系统时会变得难以驾驭,无法直接进行精确分析。
实际操作中,业内主流做法是采用离散事件仿真(DES)来对AMHS建模。把轨道段、路口、Stocker升降机、OHT车辆都作为仿真模型中的资源节点,把搬送任务列表作为事件流输入,跑出来的输出结果包含平均搬送时间、三西格玛、路口利用率、OHT空闲率等关键数据。模型输入参数包括:
| 输入参数 | 取值来源 | 说明 |
|---|---|---|
| 轨道网络拓扑 | CAD布局图 | 轨道段长度、连接关系、单双向 |
| OHT数量与参数 | AMHS设备清单 | 数量、速度、加速度、升降时间 |
| Stocker参数 | 设备规格书 | 容量、升降机数量、单循环时间 |
| 搬送任务矩阵 | MES历史数据 | 起止站点、频率、时段分布 |
模型建好后,先用来排查瓶颈,再做参数优化验证,最后输出改版方案供现场实施。这也是第6章要重点展开的优化路径。
4. 影响搬送效率的关键参数:OHT、轨道布局与调度逻辑的实践边界
4.1 硬件侧:OHT速度、加速度与升降马达的取舍
硬件参数里,影响AMHS整体效率最直接的是OHT的行走速度和加速度。更高的速度和加速度可以在理论上减少单次搬送时间,但事情往往没有这么简单。
OHT在轨道上并不是全程匀速运行的。接近交汇路口时要减速,接近设备Port时要蠕行对位,前方有慢车时要跟随。当搬送任务十分密集时,高速运行反而会导致OHT频繁处于“加速—急停—再加速”的状态,车体本身的磨损更快,轨道上的振荡也更容易影响FOUP的稳定性。制造商通常会根据实际搬送量分布,设置一个折中的最大行走速度,而不是直接放开到机械极限。
| 参数 | 设置过高带来的问题 | 工程上常见的处理 |
|---|---|---|
| 最大行走速度 | 频繁启停、车体磨损、路口通过不稳定 | 按轨道区段区分限速,高流量区降速 |
| 加速度 | FOUP晃动加剧、轨道载荷突变 | 平衡启动与停车平滑性 |
| 升降马达速度 | 设备侧安全风险上升 | 用安全联锁限制最大速度 |
升降马达的运行速度是另一个容易被忽视的参数。OHT完成一个搬送动作,FOUP需要从轨道高度下降到设备Port,再从Port抬升回OHT。升降马达的动作时间虽短,但每次搬送都要执行,算上高频次后对整体效率仍有影响。由于设备Port附近时常有操作员活动,升降马达的速度一般以安全为前提来设定,不太会追求极限速度。
4.2 轨道布局:最短路径、冗余能力与交汇路口
轨道拓扑是AMHS性能的上限。软件调度再智能,也顶不上一张物理上就不合理的轨道网络。经验上,设计轨道布局时一般要过三关:
第一关是行走路线优化。每个搬送起点和终点之间,轨道系统上要存在一条合理的最短路径,但最短路径不等于最优路径。如果所有OHT都涌向同一条路径,这条路就会成为拥堵瓶颈,整体搬送时间反而上不去。设计时需要分散流量、适当制造“次优绕行路径”。
第二关是冗余能力。关键轨道段和路口最好有备用绕行通道,否则单点故障发生时,故障路段的周边区域会瞬间形成交通死锁。一个值得做的测试是“单点失效测试”,也就是人为将某段轨道设为不可用,跑仿真看全厂平均搬送时间的恶化程度。如果恶化超过30%,这个区域的冗余设计就不合格。
第三关是交汇路口设计。路口是轨道上的天然串行节点,多个高流量轨道的交叉要尽量避免。如果无法避免,就需要在控制逻辑中设计合理的优先级规则,让交汇路口的通行效率和公平性找到平衡点。
4.3 软件侧:路径选择、OHT搜索与交通控制的三重逻辑
硬件给了AMHS“能跑多快”的上限,软件则决定了“跑得好不好”。在AMHS控制系统中,有三个核心逻辑直接影响搬送效率。
路径选择逻辑解决的是“走哪条路”的问题。OHT出发前,控制系统要根据实际距离、途中障碍物数量、交汇路口数等信息确定一条最优路径。如果出发后遇到路径上的突发故障,系统还需要支持动态重新规划,让OHT绕行而不至于死等。
OHT搜索逻辑解决的是“派哪辆车”的问题。当设备发出搬送请求后,控制系统需要选择一个空闲OHT去执行任务。这里容易误解的是:谁最近就派谁,这种规则看似合理,但未必最优。当多个站点同时发出搬送请求,且各站点的任务紧急程度不同时,“全选最近”会让部分急单被后续任务憋住。更实用的做法是按“任务紧急程度+车辆距离”做加权评分,让高优先级任务优先被最近的空车接走。
交通控制逻辑解决的是“路口谁先走”的问题。在交汇路口,多辆OHT可能同时到达,控制系统需要确定通行顺序。理想情况下可以设计动态优先级,越紧要的任务越优先通过。但在实际工厂中,设计人员往往会选择更简单的固定优先级逻辑,这主要是出于稳定性考量——复杂的交通控制逻辑在多车并发时的状态管理非常容易出问题,一旦卡死,影响的是整片区域的搬送服务。先用简单逻辑保证系统稳,再做局部优化,这种取舍在AMHS领域很常见。
4.4 AMHS现场调试常见问题与排查
这些年做AMHS项目,下面四类问题几乎每个项目都会撞上。按“现象→原因→解决”的顺序记录,给做现场调试的同行一个排查索引。
坑1:OHT最高速度调高后,平均搬送时间不降反升
- 现象:调高OHT行走速度和加速度参数后,单次搬送理论时间变短,但整体平均搬送时间反而增加,交叉路口拥堵报警明显增多。
- 原因:搬送任务密集时,高速行驶的OHT在路口和Port频繁减速急停,每次重新加速都消耗时间,加上车流在路口的交织更紧密,整体效率被拖累。
- 解决:分段限速,在路口前预设减速区段,恢复低速可控的通行节奏;同时根据搬送量分布重新计算最佳最大速度,不必做全段统一高速。
坑2:MTTR数据持续偏高,但每次维修动作本身并不慢
- 现象:系统报表中MTTR长期超考核线,但维修工单显示每单的实际修复时间并不长。
- 原因:MTTR统计口径出了问题。从故障发生到维修人员从更衣室走到设备现场、再到备件从远端库房领出,这段时间全都被排除在维修工单之外。
- 解决:把“故障发生→系统恢复”的完整链路纳入MTTR统计,关键备件做区域就近存放,并规定维修响应时限,才能让MTTR反映真实的停机损失。
坑3:平均搬送时间达标,但某几台关键设备的Port频繁缺料
- 现象:全厂平均搬送时间在KPI范围内,但关键设备的Port前经常出现“设备等人”的情况,设备利用率低于预期。
- 原因:平均搬送时间掩盖了尾部延迟。某些搬送任务因为绕行或路口拥堵,实际耗时显著高于平均值,恰好这些任务对应的是关键设备的用料需求。
- 解决:在KPI中加入三西格玛或P95搬送时间考核;对关键设备单独跟踪“请求发出→FOUP到位”的时间分布,一旦尾部超限,优先优化对应区域的路径选择逻辑和路口优先级。
坑4:复杂调度算法上线后,控制系统进程异常重启
- 现象:在控制系统里部署了“多站点多车辆全局最优分配”的复杂算法后,控制服务运行不到半天就出现异常崩溃,全厂搬送一度停摆。
- 原因:算法对CPU资源消耗过高,叠加多辆车并发请求时的状态竞争条件,触发了控制软件的死锁或内存异常。
- 解决:复杂算法先跑离线仿真压力验证,再分区域逐步放开;实际运行时对全局最优算法的触发频率做节流,甚至降级为“区域内最优+区域间顺序分配”,换来系统稳定。
5. 洁净室空间优化:Stocker“长高”20%-30%与UTS零占地方案
5.1 洁净室空间贵在哪:地面面积和空气环境双双代价高昂
洁净室空间昂贵的原因有两个层面:一是地面面积要尽可能放生产设备,每平米都在直接贡献产能;二是洁净室要维持恒定洁净度,大空间的空气处理、温湿度维持每小时都要持续支出能量成本。AMHS要在车间内解决所有WIP的存储保管,势必要占用相当大的面积和空间。如何在存储和搬送要求不变的前提下,把AMHS占据的洁净室空间压到最小,这是每一个300mm工厂AMHS方案都要回答的问题。
5.2 方案一:把Stocker“长高”:用天花板高度换20%-30%存储增量
200mm工厂里最常采用的思路是提升Stocker中央区域的天花板高度,选用更高规格的Stocker型号,把存储层数加多。在保持占地空间不变的前提下,这种方案一般能增加20%-30%的Wafer存储量。
这个方案的落地逻辑很清楚:Stocker的容量由存储列数乘层数决定,而层数受限于厂房天花板高度。将天花板抬高几米,或者选用更高阶的Stocker机型,单位面积的存储量自然就上去了。20%-30%这个数字在很多升级项目中都能看到,相当于用一个相对可控的厂房改造成本,让同一块面积的存储效率提升三成。
提升天花板高度不是没有代价,洁净室的体积也变大,建设和运维空气处理的能耗都会上涨。如果楼房的土建条件不具备大幅提高层高,这个方案就不太容易复制。
5.3 方案二:UTS:把存储挪到天花板下,地面面积零占用
300mm工厂里更受青睐的替代方案是UTS(Under Track Storage)。UTS安装在OHT轨道下方的空中空间,FOUP可以像暂时“挂”在天花板下方一样被存放,完全不需要占用洁净室的地面面积。对比一下两种方案的特点:
| 对比维度 | 高架Stocker | UTS(Under Track Storage) |
|---|---|---|
| 地面面积占用 | 塔体加操作通道占用较多 | 几乎零占用 |
| 空间利用方向 | 向上扩展,依赖厂房层高 | 利用轨道下方的水平空间 |
| 存储容量 | 集中式大容量 | 分布式小容量、沿轨道布点 |
| 典型场景 | 大批量中央存储、跨bay缓存 | 局部缓冲、Port前暂存、高峰缓解 |
实际应用里,UTS的价值并不只是“换个地方放东西”。由于它直接挂在轨道下方,OHT经过时只需要一次短距离垂直动作就能完成存取,这意味着UTS除了存储容量之外,还能当作用在途缓冲器来用。比如某台高利用率设备的上游物料经常瞬时到达,Port却暂时放不下,旁边的UTS就能先把FOUP暂存起来,等Port空闲再送过去。这种“轨道沿线分布式缓冲”的能力,让UTS在很多300mm工厂里成为Full Auto场景下的标配。
引入UTS需要额外关注结构设计。虽然地面面积被释放了,但天花板下方多了重物,轨道的悬挂点、厂房梁架的承重、消防喷淋系统的净空都需要重新核算。安装前至少要请结构工程师做一轮荷载校核,否则后期整改的代价会相当大。
5.4 柔性设计:故障自侦测与动态改道是一项刚需能力
300mm工厂的轨道网络遍布整个车间,拓扑结构复杂。单个OHT或单一合分流节点故障时,大部分情况下不会影响全局;但故障如果发生在交通繁忙路段,或长时间得不到修复,拥堵会沿着路径选择逻辑向周边区域扩散,最终拉低全厂搬送效率。
AMHS的“柔性”设计就是要应对这种单点故障。核心能力包括四个方面:
- 自我侦测:控制系统持续采集轨道节点、OHT状态和Stocker状态,快速判定故障区域。
- 动态调整运行参数:发现拥堵后,自动调节路口优先级、路径选择权重、各区域OHT分配比例。
- 动态改道:对所有在途OHT重新计算路径,避开故障路段,防止拥堵雪球式扩大。
- 维修协同通知:同步向运维系统推送故障定位信息,让维修人员第一时间处理。
柔性设计不是只靠软件就能完成的。轨道拓扑上如果没有备用路径,软件再聪明也没有绕行的物理基础。因此,布局设计阶段就要考虑轨道冗余,控制软件再负责把冗余变成动态路线。两者缺一不可。
6. AMHS性能优化:我习惯先跑指标分解、模拟、现场校准
做AMHS性能优化的这些年来,我固定用的方法就四步:先定指标,再建模型,然后离线仿真,最后小范围现场验证。这套流程在多个项目里都验证过可行,即使不引入复杂的全局优化算法,单靠它也能稳定地改善系统表现。
第一步先定指标。明确本次优化到底要改善什么——平均搬送时间、三西格玛搬送时间,还是某个区域的Port缺料率。目标要可以量化。第二步再建仿真模型,用MES里导出的历史搬送任务数据,和当前轨道拓扑、OHT数量、Stocker参数一起建成模型,并用历史数据对模型做校验,确保仿真输出的平均搬送时间与现场偏差在5%以内。第三步在离线模型里尝试几种改动方案,比如调整OHT数量、修改路口优先级、增加某类UTS缓冲,对比它们的搬送时间分布和长尾表现。最后一步再把仿真中最优的方案拿到现场一小片区域试运行,跟踪一周的实时数据,确认三西格玛指标达标后才全量放开。
这套方法的好处在于,所有试错成本都发生在仿真模型里,现场改动风险大为收敛。做性能优化时,“翻车”往往发生在直接改参数、现场观察结果的路径上。很多参数之间是相互耦合的,单独调一项可能看起来有效,换个搬送量又失效。仿真模型恰恰能把这些耦合关系提前暴露出来。
如果视角放到450mm时代,AMHS还会面临三件明确的事:Wafer尺寸增大导致单盒重量显著上升,OHT负载能力、轨道强度和厂房基础都要重新评估;UTS这类零地面占用的存储方式会从可选优化项变成必须项;AMHS系统在线升级能力将从“最好有”变成“必须有”。系统依赖到那个程度时,任何停机都是不可接受的。
这份精编文档把全流程的关键参数和设计原则浓缩成了一份可以对照检查的参考,做AMHS项目的选型评估、方案对比或现场调优时,按章节翻对应模块即可。
某次做性能优化,我在仿真里把OHT数量减了两台,结果显示平均搬送时间反而下降——原因是交通拥堵缓解带来的收益大于车辆减少带来的运力损失。这个结果让我更确认了一点:AMHS的黑匣子不能靠直觉开关,必须用数据一层层剥开。从那以后,每次性能优化,我都强迫自己按“指标→建模→仿真→小范围现场校准”走完整个流程,时间终会证明确有其用。希望帮到你。
本文还有配套的精品资源,点击获取