GRAP 框架基础
RCS输送线逻辑梳理
  1
    任务下发
      Task
        从输送线取货（Load Container）
          修改Station
            输送线预约取货量 + 1
前提：（当前输送线载货量 - 预约取货量） >= 1
          添加Reserve
            类型：OUT
状态：已预约
AGV编号
任务ID
Station
过期时间：30分钟
        从输送线放货（Place Container）
          修改Station
            输送线预约放货量 + 1
前提：（输送线总容量 - 当前输送线载货量 - 预约放货量） >= 1
          添加Reserve
            类型：IN
状态：已预约
AGV编号
任务ID
Station
过期时间：30分钟
      Task
      Task
  2
    AGV行走至输送线前，发送取放货请求
      请求取放货数据包（AGV_06_UP）
        查询当前作业（Segment）
          入库（从输送线取货）
            修改Reserve
              状态：预约 ==> 执行
过期时间：+5分钟
            查询输送线PLC
              光电：有货物
电机：停止
...
（满足可取货条件）
                成功
                  允许取货，下发（AGV_06_DOWN）
                失败
                  回滚Reserve
                    状态：执行 ==> 预约
过期时间：+5分钟
          出库（往输送线放货）
            修改Reserve
              状态：预约 ==> 执行
过期时间：+5分钟
            查询输送线PLC
              光电：无货物
电机：停止
...
（满足可放货条件）
                成功
                  允许放货，下发（AGV_06_DOWN）
                失败
                  回滚Reserve
                    状态：执行 ==> 预约
过期时间：+5分钟
          货架取放货
            默认允许
  3
    AGV取放货完成上报
      查询当前任务TASK
        入库（从输送线取货）
          修改Station
            输送线预约取货量 - 1
当前输送线载货量 - 1
前提：预约取货量 >= 1
当前输送线载货量 >= 1
          修改Reserve
            状态：执行 ==> 完成
完成时间：NOW
        出库（往输送线放货）
          修改Station
            输送线预约放货量 - 1
当前输送线载货量 + 1
前提：预约放货量 >= 1
          修改Reserve
            状态：执行 ==> 完成
完成时间：NOW
  4
    分配
      货架是空间资源算法
      滚筒输送线是 时间序列资源 + 空间
      逻辑
        滚筒入库
          当前入库站为滚筒输送线且对应的地码上存在AGV，且此AGV上一个任务为此station的入库任务，且此AGV的背篓任务数有空余，则直接派发给当前AGV。
            分配完毕后，直接将任务的个取货入库动作排序到下个节点，将入库放货动作针对之前的动作列表进行排列组合，防止到合适的位置，目标是为了让AGV少走弯路
          如果当前滚筒输送线条码上AGV，且此AGV正在作业入库作业，此时是否分配给AGV
            分配
              分配后，会不会导致状态抓不到，连续分配太多任务给当前AGV
            不分配
              分配给其他AGV，但是会导致站前AG作业完了不取面前料箱，其实它有空余背篓
        滚筒出库
          查询相同出库站的任务且状态为等待执行且已经分配AGV，对这些任务以相同AGV分组进行数量降序排序，遍历排序后的集合，如果单组数量大于等于AGV车型背篓数量，则当前任务分配给这组的AGV
  5
    AGV行走至滚筒输送线前面是否需要等待
      如果AGV定位在滚筒输送线前，且在此条码上没有发生过取放货动作，则不需要等待
      如果上一个作业为站点取货作业
        背篓数量已被预约完，则不需要等待
        背篓还有空余数量，则等待
      如果上一个作业为站点放货作业
        且下一个作业也为此站点放货作业，则进行等待
  从状态改成了预约队列
    以前
      货架逻辑：谁先改状态谁用
        缺点
          多车只能一车使用输送线
          只有一个状态和任务数据，数据量太少，事故定位很难
    现在
      输送线像月台，可以同时放多个箱子，有节拍、有暂停、有人工/PLC控制
        预约
          叫号
            完成
        优势
          多车作用同一个输送线，即使车坏了，也不影响
          把“排队”和“执行”分开了，系统更稳，也更适合复杂设备
          可追溯
            reserve记录了Task，AGV，数量，IN/OUT等数据，出问题你能查到具体原因
  为什么要回滚
    AGV在输送线前面，不一定能连接输送线
      原因
        异常暂停
        网络错误
        人工误操作
      如果不回滚
        系统会以为“已经在操作了”
        其他任务进不来
        输送线被占住
      作用
        不把输送线“卡死”
        延长过期时间，防止因输送线问题，导致任务过期而作废
        防止后期用WAITING做控制时，发生系统阻塞
        防止AGV频繁发生取放货请求包
  隐患
    先到的 AGV 拿走了不属于它的货，导致料帐错误
      方案一：同一个输送线口同时只允许 1 台车执行 OUT
        (当前输送线载货量 - 预约取货量) >= 1 并且 预约取货量 = 0
        代价：吞吐降低
        目前逻辑一个输送线到了才会发送任务，完全可以适用
        好处：如果输送线提前发放任务，如果运行中端口中发生错误，将导致AGV阻塞
      方案二：Reserve绑定料想码
        前提
          输送线 PLC提供料想码
          AGV能够识别扫描料想码并上报
        通过比对两边的料想码，如果不一致，则拒绝取放货请求