第1章 自动门逻辑

1.1 自动门逻辑简介

1.1.1 数据流向

处理这类问题之前，需要理解自动门门控逻辑，申请数据流向为算法-->RCS-->CMS-->WCS-->门控制器。

1. 如若上层已知当前门的状态为开，则申请开门会马上通过，而申请关门上层一般会将算法的门状态设置为关，但实际门何时关闭一般根据具体设备有一定延迟（现场一般不建议使用延时，存在安全风险）。

2. 如若上层已知当前门的状态为关，则申请开门时会等待上层已确认门开到位且无其他外部关门信息时，才可反馈申请开门通过，否则会有撞门的风险。

1.1.2 业务配置

3. 若需要提前申请开门；

可通过设置长距离开门参数进行控制，默认情况算法申请开门的距离一般约在4~6米之间。

4. 若希望机器人通过门后延迟一会儿再关门；

可通过设置交通控制释放周期来进行控制（在RCS获取能力集里面进行修改）。

                                  第2章 常见问题排查

2.1 机器人到门前，不开门

2.1.1 排查思路

步骤1 首先确认该门编号；

可在web端：搭建模型→地图配置→外设编辑（点击进去选择自动门）可查看自动门编号或者增删或者修改门编号。

步骤2 查看该车规划库是否申请开门；

搜索算法Ou +车号：rq -1 0 （-1代表不请求，0代表申请关门，1代表申请开门），后面数字代表申请门编号，如下图所示。

l 如果规划库有申请信号：则可以确认算法内部已经申请，在等待外部反馈开门，没有开门属于外部原因，需要排查rcs日志，若规划库无申请信号需检查是否存在近距离开门设置，以及近距离开门申请的距离，检查无误可联系规划库排查；

l 查询对应时间点的RCS日志信息，搜索“ask for traffic”，找到对应的申请信息，若未查询到相应的申请信号，则需要联系RCS排查；

l 若RCS发送相应的申请信号，则继续通过排查RCMS是否发送消息，可通过“运营管理”->“异常处理”->“发送消息处理（其他）”查看消息，如果没有发送对应消息那么联系RCMS处理；

l 若RCMS发送相应的消息，则继续排查WCS日志信息，查看WCS日志中是否有申请消息，如果没有则需要排查WCS配置文件是否正确配置；

2.2 机器人到门前，开门不走

2.2.1 排查思路

机器人到车门前，门已打开但机器人不走，该种问题一般为申请开门但门未到位，条件不满足导致；

步骤1 首先检查门硬件问题；

排查门是否已开到最高位，由于出于安全现已要求门在开门时需自检测到是否门开到最高位，如门控检测不到门开到高位，门控不会给WCS反馈成功信号，从而让机器人无法通过

步骤2 排查门控是否给WCS开门成功信号；

运营管理->异常处理->发送消息处理（其他）->（开门请求类型：applyLock，请求内容：有对应门编号及：uuid）根据uuid编号去WCS日志中排查；

步骤3 根据异常的uuid号，在对应时间点的WCS日志中查询是否给了开门成功信号；

字段含义：

action_type = 'applyLock'   申请动作：申请开门

task_step = 'openDoor'    任务动作：请求开门
request = '020800000000000100'  请求内容:申请开门

response = '050609000102000000010011' 请求回复（门返回开门到位成功信号）

result =YES                        应答结果：成功

response ：wcs对response 内容解析，满足wcs_protocol_message下的条件后通知rcs让AGV通过；

如图2-5，020800000000000100 表示开门请求

当response第18位为起始位起，值含义为01，认为条件满足AGV可以通过（注意，报文中从左边算起第一位0为0位，从0开始计算）。

050609000102000000010011 满足条件

结论：

若response值不满足条件，AGV静止不动，（检查门是否开门到位） 。

若response无回复，为门控程序异常，无法交互（需排查门控）

2.3 门没开，机器人往前走

2.3.1 排查思路

步骤1 打开规划库主日志，找到对应所在时间；

步骤2 查找停在门前要通过门的车，查看规划库该车的指令坐标；

步骤3 指令坐标通过门；

l 在规划库交通门应答日志answer_traffic_XX.txt中确认当前门的开闭状态。门开启状态的话，则说明是上层答复的门状态与实际不一致。如果门应答是关闭状态，则联系规划库排查

l 可在算法库日志中找到answer_traffic_XX.txt，搜索异常小车编号；

l 日志中：dn：编号（对应规划库dn号），rq：三组数字代表：门编号、开门申请信号（3申请、2申请成功）以及 车编号；

2.4 机器人未过门，门关闭

2.4.1 排查思路

小车申请开门成功后，在通过门过程中门自动下放导致门车相撞，具体排查流程如下：

步骤1 排查小车在通过门时间段内，规划库有没有给门发请求关门信号rq 0 171 （-1代表不请求，0代表申请关门，1代表申请开门），后一数字代表申请门编号。

如果通行过程中对该门发了关门信号，需要算法排查；

步骤2 如果规划库没有给关门信号，需要排查自动门的问题；

步骤3 还有一个极端可能，CMS处理关门信号较慢，导致给第三方WCS或者我们自己的WCS信号迟导致；

2.5 机器人过门后，门未关

2.5.1 排查思路

小车申请开门通过后，门没有关，排查流程如下：

步骤1 运营管理→异常处理→发送消息处理（其他）→（查看是否有releaseDevice对自动门的释放请求类型，请求内容：有对应门编号及：uuid）；

步骤2 查看是否有异常没关的门的请求关门信号内容；

l 如果有关门信号，发送状态为：已完成，则需要排查门控自身是否出现异常，导致门没关；

l 如果没有关门信号，则需要排查在问题时间节点内该车规划库算法输出是否申请关门信号（如下图为正常的算法申请关门信号）如没有申请关门信号需要算法排查；

步骤3 算法发送关门信号

运营管理→异常处理→发送异常处理（其他）中没有该车的请求关门信号，则此时需要查看:接收消息处理（RCS）是否有未处理的信息，如果有并有大量未处理的接收信息，则为rcs一个任务上报很多次消息处理，导致CMS消息处理不过来，需要排查异常消息上报的原因（需要找RCS排查）；

步骤4 若存在对自动门的释放

wcs 数据库中查看对应的任务号， task_step 大于4。此时 WCS 不在向设备发送开门指令， 自动门应该自动关闭，联系自动门维护人员；

若小车已经通过自动门，而 cms 发送消息处理中没有 releaseDevice 需要联系 cms 相关人员排查原因；