(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202210924108.4 (22)申请日 2022.08.02 (71)申请人 上海哥瑞利软件股份有限公司 地址 201199 上海市闵行区园文路28号318 室 (72)发明人 邹滨杰　 (74)专利代理 机构 上海申浩 律师事务所 31280 专利代理师 田敏 (51)Int.Cl. G06Q 10/06(2012.01) G06Q 50/04(2012.01) G06F 16/23(2019.01) (54)发明名称 基于数据库非等待锁机制的自动派工方案 (57)摘要 本发明公开了一种基于数据库非等待锁机 制的自动派工方案， 采用数据库非等待锁机制去 解决资源争抢的问题， 同时通过自定义排序规则 实现资源优 先级的问题， 数据库非等待锁机制包 括非等待锁机制的架构模型、 资源锁表， 包括如 下步骤： (1)当设备请求派工时， 把设备的端口状 态更新为ReadyToLoad； (2)获取相关资源， 以资 源唯一标识作为锁的NAME去获取锁； (3)在获取 到锁之后， 向COM_CON_LOCKS插入记录； (4)进行 业 务 处 理 ；( 5 ) 更 新 设 备 端 口 状 态 为 ReserveToLoad， 表示设备派工完成； (6)释放锁， 事务提交。 本申请提升了派工效率的同时， 又没 有带来运维成本和硬件成本， 可以推广到整个半 导体行业。 权利要求书1页 说明书4页 附图3页 CN 115239171 A 2022.10.25 CN 115239171 A 1.一种基于数据库非等待锁机制的自动派工方案， 其特征在于， 采用数据库非等待锁 机制去解决资源争抢的问题， 同时通过自定义排序规则实现资源优先级的问题， 所述数据 库非等待锁机制包括非等待锁机制的架构模型、 资源锁 表， 具体包括如下步骤： (1)当设备请求派工时， 把设备的端口状态更新 为ReadyTo Load； (2)获取相关资源， 并且以资源唯一标识作 为锁的NAME去获取锁， 这里利用的是数据库 的For Update No Wait机制， 这种 机制表示如果获取不到行锁就直接返回， 不会对数据库 造成锁等待， SQL语句如 下： SELECT*FROM  COM_CON_LOCKS  T WHERE T.LOCK_NAME＝资源名 FOR UPDATE NO WAIT； (3)在获取到锁之后， 向COM_CON_LOCKS插 入记录； (4)进行业 务处理； (5)更新设备端口状态为ReserveTo Load， 表示设备派工 完成； (6)释放锁， 事务 提交。 2.根据权利要求1所述的一种基于数据库非等待锁机制的自动派工方案， 其特征在于， 所述资源锁 表为COM_CON_LOCKS。 3.根据权利要求1所述的一种基于数据库非等待锁机制的自动派工方案， 其特征在于， 所述如果获取锁失败， 设备派工失败， 设备不能空闲， 引入了一个定时任务， 去查询设备 的 端口状态为ReadyTo Load。 4.根据权利要求1所述的一种基于数据库非等待锁机制的自动派工方案， 其特征在于， 所述如果设备派工失败， 设备端口 的状态也会更新 为ReadyTo Load。 5.根据权利要求1所述的一种基于数据库非等待锁机制的自动派工方案， 其特征在于， 所述如果系统中有个定时任务(Watchdog)， 定时去查询设备端口状态为ReadyToLoad， 会进 行设备重新派工， 一 直到设备派工 完成。 6.根据权利要求1所述的一种基于数据库非等待锁机制的自动派工方案， 其特征在于， 所述COM_CON_LOCKS表结构如下： CREATE TABLE COM_CON_LOCKS ( "CATEGORY"VARCHAR2(32), "LOCK_NAM E"VARCHAR2(64) ) ALTER TABLE"COM_CON_LOCKS"ADD  CONSTRAINT"PK_COM_CON_LOCKS"PRIMARY  KEY(" LOCK_NAM E","CATEG ORY")USI NG INDEX"PK_COM_CON_LOCKS"ENABLE 。权　利　要　求　书 1/1 页 2 CN 115239171 A 2基于数据库非等 待锁机制的 自动派工方案 技术领域 [0001]本申请涉及半导体的资源调度技术领域， 具体涉及一种基于数据库非等待锁机制 的自动派工方案 。 背景技术 [0002]在半导体行业,自动化程度 非常高， 都是无人工厂， RTD(Real  Time Dispatch)是 自动化派工的管理系统， 主要负责为空闲设备寻找最合适的任务， 并且发送搬送指令给下 游搬送系统， 以此来实现全自动化。 由于工厂的设备和资源之间是n ‑1的关系， 会存在多个 设备的端口(设备能力相同 )同时请求派工， 从而导致把一个载具派到多个设备的情况， 为 解决此问题， 现有技 术都用FIFO(先进显出)队列中间件去解决此问题。 [0003]通常， RTD系统是基于FIFO队列中来实现的， 为了保证系统队列可用， 以及数据一 致， 需要在软件上额外引进队列中间件(如ActiveMQ)来 解决该问题。 [0004]通常情况下， 半导体生产工作设备种类及数量很多， 资源(载具)数量也会很多， 一 台设备会多种加工功能， 多个上下料口， 如图1设备上/下料口模型。 同时， 车间会有多条生 产线， 每个生产线会有多台设备， 参见图2的生产车间平 面图。 从图1和图2可以看出， 当一个 设备或者相同能力的设备同时去发出派工请求时， 会对一个资源(载具)进行争抢， 如果对 资源没有一种可靠机制， 肯会出现一个载具被派到多个设备上， 或者出现死锁的情况， 问题 模型如图3所示。 针对图3的问题模型， 通常RTD采用FIFO队列的方式进解决资源争抢的问 题， 如图4所示为基于队列的架构模 型。 通过图4不难发现： 队列消费者只能以单线程的模式 进行消费， 如果可以出现多线程消费， 一样会引发资源争抢的问题。 在一个队列只能有一个 消费者线程的情况下， 如果整个系统只有一个队列， 那么所有的请求都会堆积在队列当中， 如果想要提升效率必须去调整队列数量， 一般这种调整是需要改变程序的代码或者用一套 管理系统去配置 完成， 分以下几种情况： [0005]1、 需要根据现有资源情况调整队列配置； [0006]2、 如果系统需要更新， 需要对队列的数据进行消费完成之后才能进行更新， 很容 易出现操作风险； [0007]3、 如果是简单自研队列， 当队列中有数据， 但出现宕机的情况队列数据丢失， 恢复 之后未处 理的数据的数据丢失或者与数据库数据不 一致， 有数据一 致性风险； [0008]4、 需要单独开发一个队列的管理界面去管理规则比如， 把不同载具映射到不同的 队列算法。 [0009]从图4可以看出， 队列 中间件其实是一个很复杂的问题， 对消息的可靠性， 高度可 用性， 数据一致性都要考虑到， 无疑增加了很多的负担及系统复杂性。 经过仔细分析， 同一 个载具同时被多个设备并发请求的数量并不会很大， 请求的力度已经细化到了加工工步及 对应的Recipe(加工配方)， 同一时间并发在0 ‑100之间， 在这种量的情况下没必 要引入复杂 度更高的队列来 解决此问题。 [0010]综上所述， 基于FIFO队列的方案会 存在如下一些问题：说　明　书 1/4 页 3 CN 115239171 A 3