夜雨聆风前面一篇文章发表后，很多人在后台或者发微信问同一个问题：
WES仓库执行系统--一个不应该存在的系统
"WMS、WCS、RCS三个系统，到底该怎么分工？谁该管什么？"
问的人太多，而且这个问题确实没法用一两句话讲清楚。今天专门写一篇，把WMS、WCS、RCS三种主流的协同架构拆开说透。
先看下这个图纸：
右边区域是堆垛机+输送线构成的立体库，左边区域是机械手拆码垛。两者之间用AGV进行衔接。
入库：机械手码垛-AGV搬托盘--输送线-堆垛机入库
出库：堆垛机出库-输送线--AGV搬托盘--机械手拆垛
这里就会用到WMS、WCS、RCS三套软件
第一种：星型架构（理想型）
WMS分别直连WCS和RCS。WCS管输送线/堆垛机，RCS管AGV。两个系统各自独立运行，WMS居中调度。
具体怎么工作？
WMS先告诉WCS：把托盘送到输送线末端。WCS调度输送线完成。然后WMS告诉RCS：到输送线末端取货，送到某某工位。RCS调度AGV过去。
AGV到达输送线口之后，需要确认"输送线就绪、可以取货"。这时候RCS直接和输送线PLC交互——一般是OPC协议，RCS读PLC的状态点，确认安全后再取货。
这种架构的优点很明显：
WMS只管发任务，不管设备细节，层次最清晰 WCS和RCS各自对自己的设备负责，边界清楚 交互链路最短，效率最高
缺点只有一个：对RCS团队要求高。
RCS工程师得懂OPC，或者Modbus，S7等各种协议，不同项目的输送线PLC可能用不同协议，RCS得能适配。很多RCS厂商不愿意干这个——"我是做AGV调度的，为什么要去懂PLC？"
但我的看法是：这本来就是RCS该做的事。 RCS调度AGV去取货，取货的安全确认是取货动作的一部分，RCS不确认谁确认？让WCS替RCS确认，等于让输送线厂商替AGV厂商做安全校验，边界上是说不通的。
所以这种架构虽然现实中用得最少，但从责任和效率上，它是三种里最合理的。
只看WMS、WCS、RCS，其架构模型为：
第二种：网形架构（妥协型）
WMS还是分别连WCS和RCS，但WCS和RCS之间也需要通讯。
AGV到了输送线口，不直接问PLC了，而是问WCS："我可以取货吗？"WCS去问PLC，PLC回答后，WCS再回给RCS。
这种架构为什么出现？
因为RCS厂商说："我不想和不同的PLC打交道，OPC、Modbus、三菱……太麻烦了。我要做标准化产品，只和WCS对接。"，然后开始摆烂
最后WCS厂商说："行吧，我来接。"
结果：RCS舒服了，WCS累死了。WCS不仅要管自己的输送线/堆垛机，还要当RCS和PLC之间的"翻译官"。
好处：RCS可以标准化，一套接口走天下。 代价：多了一层转发，效率降低了一点；更重要的是，WCS的责任边界变模糊了——本来只负责输送线，现在还要替RCS管AGV的取货安全。
这种架构在工程实践中有。但如果项目团队能力够，我还是建议用第一种。
网形架构的缺点之前专门讲过，详细可以参考前文：
只看WMS、WCS、RCS，其架构模型为：
第三种：瀑布型架构（我最不推荐的）
这是第二种的进一步"退化"。
RCS嫌麻烦之后，WMS也来模仿。
WMS厂商说："我只对接一家系统，不想同时管WCS和RCS两家。"
RCS厂商说："我只做标准产品，不和别人对接。"
好了，所有事情都丢给WCS——WMS只连WCS，WCS再连RCS。
从软件层看，就是WMS→WCS→RCS三层单向瀑布结构，WMS只管WCS，WCS管一切。信息从上往下流，像瀑布一样——但瀑布冲下来的不是活水，是责任。
换个更直观的展现方式：
这种架构下：
WMS最舒服，只面对一个系统 RCS最舒服，只接收WCS的指令 - WCS最惨，什么都要管
WMS下发的搬运任务，起点和终点都是WCS来解析，然后再转发给RCS。RCS只管执行，不管任务从哪儿来、为什么要去那儿。
只看WMS、WCS、RCS，其架构模型为：
最不合理的是：WCS的核心功能是管理输送线、堆垛机这些自动化设备，现在还要替WMS管RCS。WCS既要管PLC，又要管RCS，成了整个现场的总调度中心——这不是WCS该有的样子。
查问题时更痛苦。AGV出了问题，要查WMS有没有发、WCS有没有转、RCS有没有收到、网络有没有断——一圈查下来，时间都耗在"定位问题"上了。
为什么瀑布型架构查问题最麻烦？
这是我想重点说的。
用瀑布型架构，AGV取不了货，排查链是这样的：
WMS有没有下发任务？ WMS下发的起点/终点对不对？ WCS有没有把任务转发给RCS？ WCS转发时数据有没有丢？ RCS有没有收到指令？ RCS调度AGV有没有成功？ AGV到了之后，WCS有没有正确读取PLC状态？ PLC本身有没有问题？
8个环节，任何一个都可能出问题。 而WCS在中间，前面挡着WMS，后面接着RCS，问题到底出在哪个环节，要查一圈才能定位。
如果用的是星型架构，排查链是这样的：
WMS任务对不对？ WCS输送线调度对不对？---如果看到托盘已经到位了，这一步都可以省略 RCS AGV调度对不对？ RCS和PLC交互对不对？
4个环节，每个系统的责任边界清清楚楚。 出了问题，5分钟就能定位到是哪家的锅。
基本设计原则可以参见之前的一篇文章：
三种架构怎么选？
| 效率 | |||
| 责任清晰度 | |||
| 查问题难度 | |||
| 对RCS要求 | |||
| 对WCS要求 | |||
说句得罪人的话
行业里有一种很不好的风气：谁能力强，谁承担的就多；谁能力不强，就撒泼摆烂，直接说"我干不了"。
这话不好听，但做过几个项目的人都见过。RCS厂商说"我不对接PLC"，WMS厂商说"我只连一家系统"，最后所有脏活累活都堆到WCS头上。WCS成了万能挡箭牌，谁都可以往WCS身上甩责任。
在工程领域，不应该是"能者多劳"，而应该是"合理性优先"。 谁的设备谁负责，谁的边界谁守住。强势的一方，不应该因为自己有选择权，就获得技术上的"豁免权"。
如果一个行业里，能力强的团队反而要为能力弱的团队兜底，能躺平的厂商反而更舒服——这个行业的甲方就该警醒了：你花的是冤枉钱，买的是一个随时扯皮的系统。
一句话总结
三种架构里，**我的排序很明确：
第一种（星型）> 第二种（网形）> 第三种（瀑布型）**
第一种责任和效率都是最好的，唯一的要求是RCS团队有能力直接和PLC交互。如果团队能力够，不要犹豫，直接用第一种。
第二种是现实的妥协，RCS标准化、WCS当翻译官，工程中能接受，但不是最优解。
第三种是我最反对的——WMS和RCS都舒服了，WCS成了万能背锅侠。查问题时8个环节连环排查，甲方最痛苦。如果有厂商建议你这么做，要警惕他可能在"推责任"。
选型时记住一点：不要只看各家厂商的功能清单，要看"出了问题，谁来查、谁来改"。 合同里没写清楚的，后面都是扯皮。
做WCS的同事建议收藏，下次甲方问你"为什么AGV取不了货"，或者RCS想偷懒，把这篇转给他看。
对了，各位看官，看完点个赞！另外，本文开了赞赏。
原创不易，如果我持续输出的干货对你有帮助，请打赏1元。
过往精华文章：