宇宙免责声明

在您继续阅读本文之前，请注意，本文涉及的RCS-CMS-WCS 4.x版本及其新系统TAS（Task Arrangement Service，任务编排服务）可能包含作者基于当前知识水平的推测和假设。

作者已尽最大努力确保信息的准确性和完整性，但鉴于宇宙的无限性和技术的不断进步，本文中的信息可能与读者的量子状态发生纠缠，导致不可预测的结果，根据量子物理学，本文中的某些信息可能处于存在与不存在的叠加状态。作者不对因量子不确定性导致的信息不准确性负责。作者无法保证所有信息的绝对正确性。

玻璃心，不点赞会紫砂！

续接上文【 一文带你入门RCS4.x【任务编排】(一）】，让我们来复习一下任务链的逻辑 ！

 任务编排测试与任务链详情分析

     1.创建基础搬运编排并理解测试报文

                一条简单的任务链，我们代入进去的逻辑应该是如下步骤这样进行的：

                       1.我们先得知道我们的起点终点在哪里（在3.x也是如此）

                       2.我们需要搬运的载具在什么地方，并且点位上是否有载具绑定（4.x新增了一个锁定条件，站点有可能被锁定）

                       3.我们的起点终点是否被锁定，是否可用 （申请起点节点 申请终点节点）

                       4.什么车型能来搬运这个载具，并且是否是指定AMR，怎么获取AMR（可近距离优先）

                       5.我们要通过怎么样的任务流程去搬运载具 （搬运任务节点）

                根据上面的逻辑，我们就可以写出一个简单的搬运任务链

                 点击保存之后，我们就有了一个搬运任务，这时，我们可以使用任务编排中的测试功能去尝试任务下发与运行

                    OK，当你点了测试按钮之后，如果你学过编程或者会看JSON格式文件，那么恭喜你，接下来你将畅通无阻

    



让我们把报文拉下来看一下，这里面有什么好东西

这是一段默认的任务测试JSON报文，简单解读一下就是targetRoute这个数组里面

    （数组 Array 是一种基本的数据结构，用于存储相同类型的元素集合，我们简单的抽象理解一下就类似于 水果 : [西瓜，苹果，香蕉]  ）

当我们理解了数组之后再来分析这个默认的JSON报文，就会一目了然，显而易见最外层的数组为targetRoute，他里面有好几个对象（Object)

    (对象 Object 是一种基本的数据结构，用于存储一种键值对{Key ： Value}, 我们简单的抽象理解一下就类似于 {西瓜：绿色}，{香蕉：黄色} ）

再次回头看，我们解构这个JSON，就能得到一段我们能理解的意义，有一个数组叫做targetRoute，他里面有两个对象

再细分一下，对象里面有五个属性

所以我们就可以自己编写测试的JSON文件来进行测试，并不需要去触发其他PLC信号或通过运营管理手动填写任务下发，更加方便的去调用任务链进行调试

比如现在我们有一台AGV在X点，他要去Y点，我们就可以通过4.X的潜伏车通用任务编排去进行下发测试（如下图）

让我们来修改一下测试用例的JSON文件吧

什么！到这里你就看不懂了？

（确实，如果没有编程基础或之前有了解过这些对象数组这些抽象的东西，直接来理解这一套确实是比较吃力的，遇到不会看不懂的，又没有人问，问技术支持吧，技术支持不搭理你，问同事吧，同事也不会，自己研究吧，客户立马客诉上来了，那怎么办？？？？？

在以前，我们真的很吃力，碰到这种事真是触发 “螳螂” 的被动了,不过现在可是2024年啊，人工智能发展的最离谱的一年，人类发展至今最大的能力就是会使用工具，我们直接把这一段JSON文件扔给AI，来看看他是怎么帮我们解读的）

                  😇还自己动手改个集贸啊！！ 都什么时代来了，有问题先抛给AI跑一遍再说

回归正题，我们把已经写好的任务测试报文复制到RCS的任务测试里面，格式化一下，现在他长这样（如下图）

如果不出意外，我们的潜伏车就可以执行从X点去Y点的搬运任务了，实际情况应该是，AGV到X点举升，移动至Y点放下，结束任务。

 2.通过任务链详细分析任务执行异常点

        在任务运营管理中，我们可以直接查到我们的每一条任务（如果没有就开历史记录），找到我们异常的任务链，点击左侧录制按钮（呸！）点击右侧详细按钮即可开始分析做题

展开之后如果不出意外，应该是下图这样

子菜单节点中有四种属性节点，他们分别为 子任务列表|交互信息|异常反馈|流程实例

子任务列表就是用来显示子任务状态的，这里面一般都是显示子任务节点在哪一步，货架是哪一个，起点是哪里，终点是哪里（由于没有很重要的信息，完全可以一笔带过）

交互信息 是用来监控本条任务对外（对第三方或对内） 发送的任何交互信息，比如TAS通知WCS，WCS通知外设这种信号都会在这里面记录

异常反馈  大部分情况下，异常报告或异常节点都是在这里面抛出的，如果这里面没有，并现场任务确实出现了异常情况，则可排查信号交互或实施问题

流程实例  东西太多了，留给下次单独介绍（只需要知道这里面包含了这个任务链的所有变量即可）

排查问题很简单，而且基本上4.x对比3.x要更简单，毕竟报错ERR都抛到前端来了，能有什么难度，一般报错根据以下流程查询，大概率能解决75%的问题

假设现场现在 任务链节点卡住，很久没动（常绿但没反应）

  1.查询是否外设交互异常导致一直在申请反馈

  2.查询实施路线或监控端是否有报错或问题，硬件是否有问题

  3.排查任务节点中是否有抛出错误，节点传参异常或任务调用异常

  4.RCS发送上报是否正常完成，WCS任务状态是否卡住

  5.任务终点是否允许小车进，地图配置是否无异常

  6.远程配置并重新下发任务尝试复现    

  7.最重要的一条（开始摇人）

根据上面的一套操作，基本上项目上一些简单的任务都可以尝试自己解决了，毕竟再好的文章也比不过自己亲手尝试一下来的快，开个模拟器，弄个单独的地图去尝试呗

文至于此，本来还是想讲一下submitParam这个Object 和 任务详情中的任务节点查异常，但是现场客诉又来啦，那就下次再见吧！