基于数据库非等待锁机制的自动派工方案制造技术

本发明专利技术公开了一种基于数据库非等待锁机制的自动派工方案，采用数据库非等待锁机制去解决资源争抢的问题，同时通过自定义排序规则实现资源优先级的问题，数据库非等待锁机制包括非等待锁机制的架构模型、资源锁表，包括如下步骤：(1)当设备请求派工时，把设备的端口状态更新为ReadyToLoad；(2)获取相关资源，以资源唯一标识作为锁的NAME去获取锁；(3)在获取到锁之后，向COM_CON_LOCKS插入记录；(4)进行业务处理；(5)更新设备端口状态为ReserveToLoad，表示设备派工完成；(6)释放锁，事务提交。本申请提升了派工效率的同时，又没有带来运维成本和硬件成本，可以推广到整个半导体行业。导体行业。导体行业。

【技术实现步骤摘要】
基于数据库非等待锁机制的自动派工方案


[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队列的方案会存在如下一些问题：
[0011]1)因为是FIFO队列，会出现如果队列数切分不合理，会出现队列阻塞，导致效率底下；
[0012]2)由于生产资源实时在变动，系统管理员需要根据现有资源数量对队列数量进行调整，出现资源数和队列数不平衡而容易造成生产事故；
[0013]3)在硬件资源上需要增加额外的队列中间件服务器，增加了硬件成本；
[0014]4)在软件知识上，需要增加队列中间件的管理知识，甚至需要招聘关于这方面的特殊人才，增加了人力和财力成本；
[0015]5)由于引进队列中间件，增加了系统的复杂度，在开发及维护上会带来一定的困难。

技术实现思路

[0016]本申请提供了一种基于数据库非等待锁机制的自动派工方案，提出用数据库的No Wait锁的方案去解决
技术介绍
中指出的问题，旨在提升生产效率，提升系统稳定行，降低系统复杂度。
[0017]本申请是通过以下技术方案实现的：
[0018]一种基于数据库非等待锁机制的自动派工方案，采用数据库非等待锁机制去解决资源争抢的问题，同时通过自定义排序规则实现资源优先级的问题，所述数据库非等待锁机制包括非等待锁机制的架构模型、资源锁表，具体包括如下步骤：
[0019](1)当设备请求派工时，把设备的端口状态更新为ReadyToLoad；
[0020](2)获取相关资源，并且以资源唯一标识作为锁的NAME去获取锁，这里利用的是数据库的For Update No Wait机制，这种机制表示如果获取不到行锁就直接返回，不会对数据库造成锁等待，SQL语句如下：SELECT*FROM COM_CON_LOCKS T WHERE T.LOCK_NAME＝资源名FOR UPDATE NO WAIT；
[0021](3)在获取到锁之后，向COM_CON_LOCKS插入记录；
[0022](4)进行业务处理；
[0023](5)更新设备端口状态为ReserveToLoad，表示设备派工完成；
[0024](6)释放锁，事务提交。
[0025]作为优选实施例，所述资源锁表为COM_CON_LOCKS。
[0026]作为优选实施例，所述如果获取锁失败，设备派工失败，设备不能空闲，引入了一个定时任务，去查询设备的端口状态为ReadyToLoad。
[0027]作为优选实施例，所述如果设备派工失败，设备端口的状态也会更新为ReadyToLoad。
[0028]作为优选实施例，所述如果系统中有个定时任务(Watchdog)，定时去查询设备端口状态为ReadyToLoad，会进行设备重新派工，一直到设备派工完成。
[0029]作为优选实施例，所述COM_CON_LOCKS表结构如下：
[0030]有益效果：
[0031]本申请采用了最简单的架构解决了RTD派工争抢被派资源问题，同时没有提高原有系统复杂度，相对于FIFO方案来说，提升了派工效率的同时，又没有带来运维成本和硬件成本，可以推广到整个半导体行业，具体包括：
[0032](1)利用数据库的No wait锁机制，可以实现派工请求的高并发，使得系统不会出现队列阻塞的情况，极大提高了生产效率；
[0033](2)提供了一系列的排序算法，可以按照用户定义的排序规则优先生产某些订单，可以灵活的配置生产优先级，从根本上避免了某些批次晶圆的长时间堆积而造成的品质不良；
[0034](3)直接集成在了RTD主工程中，不需要任何中间件，减少了系统复杂，和硬件资源；
[0035](4)简单易用，容易维护减少了系统的维护难度。
附图说明
[0036]图1为本申请现有技术中设备上/下料口的模型示意图。
[0037]图2为本申请现有技术中生产车间的结构示意图。
[0038]图3为本申请现有技术中派工问题的模型示意图。
[0039]图4为本申请现有技术中基于队列的架构模型示意图。
[0040]图5为本申请一个实施例本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种基于数据库非等待锁机制的自动派工方案，其特征在于，采用数据库非等待锁机制去解决资源争抢的问题，同时通过自定义排序规则实现资源优先级的问题，所述数据库非等待锁机制包括非等待锁机制的架构模型、资源锁表，具体包括如下步骤：(1)当设备请求派工时，把设备的端口状态更新为ReadyToLoad；(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)更新设备端口状态为ReserveToLoad，表示设备派工完成；(6)释放锁，事务提交。2.根据权利要求1所述的一种基于数据库非等待锁机制的自动派工方案，其特征在于，所述资源锁表为COM_CON_LOCKS。3.根据权利要求1所述的一种基于数据库非等待锁机制的自动派工方案，其特征在于，所述...

【专利技术属性】
技术研发人员：邹滨杰，
申请(专利权)人：上海哥瑞利软件股份有限公司，
类型：发明
国别省市：