张立成，刘晓鑫，郝茹茹，周 洲，尚旭明

(长安大学 信息工程学院，陕西 西安 710064)

0 引言

随着我国经济社会持续快速发展，机动车保有量呈快速增长趋势，据公安部交通管理局统计，截至2017年底，全国机动车保有量达3.10亿辆，其中汽车2.17亿辆，与2016年相比，全年增加2 304万辆，增长11.85%[1]。汽车安全性能检测是保证道路交通安全的重要措施之一，国家相关部门高度重视，陆续制定出台了面向机动车安全性能检测与综合性能检测的系列标准[2-4]。除此之外，还出台相关政策，如机动车检验业务逐步社会化、市场化来缓解车主检车排队、检验时间长等问题[5]。为了检验业务更加公平公正，2015年，公安部要求各交警支队使用全国统一版的机动车检验监督管理系统，各检验机构部署安装机动车安全技术检验业务信息系统，该业务信息系统要满足国家标准GB/T26765-2011《机动车安全技术检验业务信息系统及联网规范》[6-7]。标准实施后，每个检验项目开始检验前需要向检验监督管理系统申请，申请成功后拍摄检验过程照片并上传，检验完成时需要上传检验结果，再申请检验结束。因此设计合理、稳定、高效的车辆检测调度算法显得尤为重要。另外新标准实施后，现有的检测调度算法存在一些不足，如检验结果上传成功后，该项目则被锁定，不能继续申请检验，也不能再次上传检验结果，因此对检测异常中断的一些项目，如制动，需要断点保存功能，否则会形成本地报告单数据与监管平台数据的不同步。

本文分析了现有调度算法的基本原理和不足，提出了一种改进的基于状态机的调度算法，并详细描述了实现过程。

1 现有调度算法

1.1 文件共享

该方式的基本思路是在各个工位硬盘上建立共享文件夹，主控机将报检信息以一定格式，如request.ini文件，写入到共享文件夹下，工位机在空闲时实时扫描判定是否有新的报检文件生成，如果有新的报检文件，则读取报检信息，检测完成后将检测数据写入共享文件result.ini中，并将request.ini文件删除，主控机判定request.ini文件被删除后，读取共享文件result.ini获取检测数据，数据读完后删除result.ini文件。该方法存在诸多问题：(1)实际使用过程中，经常出现由于病毒原因或安全策略设置原因导致共享文件夹无法访问的现象，整个系统无法调度，甚至瘫痪；(2)工位机或主控机轮询报检信息或结果信息消耗大量CPU资源，尤其是主控机程序，需要处理的任务比较多，降低了系统调度的实时性，工位数量越多，实时性越差，不利于系统扩展；(3)系统可靠性差，一旦工位机的报检信息文件被破坏或误操作，系统将无法正常运行。

1.2 基于winsocket的车辆调度

文献[8]介绍了一种基于winsocket的车辆动态调度方法。每个工位机在不发生故障的情况下，有空闲、忙和等待三种状态，当任何一个工位机进入新状态后都必须向主控机及时通报，直到主控机对该状态进行确认为止。与共享文件方式不同，信息是通过winsocket消息发送给工位机，如：第i个工位空闲(i取1,2,3，…,MaxGwNum)，报检队列不为空时，主控机给第i工位发送报检数据帧，延时n秒后，主控机检测是否收到第i工位机回应，若收到则判定报检信息发送成功，否则重发，延时次数增1，若延时次数超过设定阈值，系统报网络错误。第i工位收到报检数据帧后执行检测任务，状态由空闲变为忙，检测完成后，检测数据按照一定帧格式发送给主控机并等待主控机调度，状态由忙变为等待。主控通过第i+1工位发来的winsocket消息判断i+1工位的状态，若第i+1工位状态为忙，则第i工位一直等待，若第i+1工位空闲，主控请求第i工位离开，延时n秒后，判断第i工位是否回应，若第i工位没有回应，延时次数增1，若延时次数超过设定阈值，系统报网络错误；若第i工位回应，第i工位状态由忙变为空闲，主控向第i+1工位发送报检信息，依次类推。该调度算法利用TCP握手机制保证了数据发送的可靠性，整体优于文件共享方式，但是也存在如下几点不足：(1)命令帧和数据帧都是通过winsocket实现主控机与工位机之间的交换，命令帧数据量小，数据帧数据量大，尤其是近些年来国家监管部门要求传输制动力曲线、工位检测图片、视频等大容量数据，该数据传送方式容易丢帧，实现复杂，系统可靠性、实时性降低；(2)第i工位机出现掉电、重启等故障时，软件重新运行后，检测信息丢失，需要等待主控机重新发报检信息；(3)机动车安全检验机构连入监管平台后，实现了检测节拍的过程控制，若制动某轴检测完成后，支队网络突然发生异常或检测软件异常中断，只能通过业务退办继续检测，给检验机构带来不便，降低了检验效率。

2 核心算法设计

2.1 调度表设计

算法设计的调度表包括工位状态表和工位调度状态表，工位状态表命名为GWZT，其数据字典设计如表1所示。

表1 工位状态表数据字典

gwnflg设计有3种状态，有检测任务时状态为9，无检测任务时状态为1，其他状态为无效状态，如被屏蔽状态、存在硬件故障状态等，赋值为0。屏蔽或故障状态的工位不参与调度。

工位调度状态表命名为GWiZT，i为工位的序号，工位状态表依次为GW1ZT,GW2ZT,…,GWnZT。若检测线共有3个工位，即n=3，工位调度状态表即有GW1ZT,GW2ZT,GW3ZT。数据字典设计如表2所示。

表2 工位调度状态表数据字典

jcflgi设计有4种状态，正在检测时状态为1，检测完成时状态为9，出现故障时状态为7，其他为初始化状态，值为0，如表3所示。

表3 工位检测状态表

ctrlflgi设计有5种状态，有检测任务时，控制状态赋值为8，表示检测命令；本工位所有报检项目检测完成，且下一工位正忙，控制状态赋值为1，表示等待命令；本工位所有报检项目检测完成，且下一工位空闲，控制状态赋值为9，表示前进命令；若检测任务由于某些原因被终止，控制状态赋值为7，表示中断检测命令，如表4所示。

表4 工位控制指令表

2.2 主控调度算法

利用工位状态表及工位调度状态表，将每个工位的工位状态gwnflg、工位检测状态jcflgi、工位控制指令ctrlflgi组成三个数的组合。由排列组合原理，共有3×4×5 = 60种组合。其中有很多为无效组合，将有效组合整理出来，如表5所示。

表5 工位组合状态表

假设工位i没有故障，也没有被屏蔽，则该工位为有效工位(以下所述工位指有效工位)。若工位数为n,系统初始时，各工位组合状态都为“100”(以下所述状态指组合状态)。如果是第1个工位(i=n)，从报检队列中按报检先后顺序选择一辆待检车，将第1个工位状态更新为“918”，此时其他工位的状态是“100”。如果第1个工位检测任务完成，其状态为“991”，表示第1个工位任务检测完成，需要等待。如果第2(i=n-1) 个工位有检测任务，则保持第1个工位的状态为“991”，点阵屏提示引车员“请等待”；否则将第2个工位状态更新为“918”，同时将第1个工位状态更新为“999”，点阵屏提示引车员“请前进”，在随后调度过程中，第1个工位的状态会更新为初始状态“100”，此时第1个工位的检测任务调度到了第2个工位，依次类推。当调度到第n个工位时(i=1)，需要对每个工位的数据进行合成处理。具体算法细节见算法1。

算法1：主控调度算法

设工位序号为i(i=1,…,n),n为工位数。

1:输入：第i个工位状态Si,第i+1个工位状态Si+1,当i=n时，Si+1=""

2:fori=1,2,…,n

3:if Si="991"

4: ifi=1

5: Si="999"

6: end if

7:end if

8:if Si="999"

9: Si="100"

10:end if

11:if Si="100"

12: if Si+1="100"

13: end if

14: if Si+1="918"

15: end if

16: if Si+1=""

17: Si="918"

18: end if

19: if Si+1="991"

20: Si="918"

21: Si+1="999"

22: end if

23:end if

24:end for

2.3 工位机调度算法

工位机调度算法在工位调度线程中运行，第i个工位机轮询GWiZT表，执行主控调度算法赋予的检测指令，具体算法细节见算法2。

算法2：工位调度算法

设工位序号为i(i=1,…,n),n为工位数。

1:输入：第i个工位控制状态Ci，第i个工位检测状态Ji

2:if Ci=0

3: 提示检测就绪

4:end if

5:if Ci=1

6: 提示请等待

7:end if

8:if Ci=8

9: 取报检信息逐项检测

10: Ji=9

图1 车辆检测时序图

11: Ci=1

12:end if

13:if Ci=9

14: 提示请前进

15:end if

本文设计的算法，当工位组合状态为"918"时，每完成一项检测节拍，将检验数据更新到数据库中，新的联网监管系统实现了检测车辆的过程控制和过程监管。以制动为例，制动的每个轴检验前需要申请，检验完成后需要上传检验结果及项目结束信息，一旦检验结果信息成功上传，不可重新上传覆盖。为此，在结果表中增加检验项目上传成功标志信息，如B1表示一轴制动、B2表示二轴制动等。B1=1表示一轴检测完成且成功上传，B2=0表示二轴检测未完成等，当工位检测软件因网络故障、硬件故障等原因需要重新运行时，工位状态仍为"918"，只有检测完成时状态才会被更新为"991"，基于网络数据库的状态调度算法在软件重新运行时通过读取相应的工位状态表和工位调度状态表即可重新获取报检信息，继续检测，而基于winsocket通信方式的算法必须等待主控重发报检信息。而且，本文设计的算法在软件异常重启时根据标志位即可判定哪些项目已经检验完成且成功上传，自动加载已检测完成且上传成功的车辆检测数据，继续未检测项目。这样既避免了重复检测，节省了时间，也确保了监管中心的数据与本地检测数据一致。

3 算法测试

为了验证本文提出的新型调度算法，采用实例分析对算法的可行性和合理性进行测试。假设有3个工位，选取5辆待检车辆。为5辆车辆在3个工位上分配检测任务，车辆检测耗时如表6所示。

表6 车辆检测项目耗时表 (min)

图1是本文提出的调度算法按照表6所示的检测项目耗时表的调度Gantt图。Gantt图中展示了5辆待检车辆在3个检测工位上的消耗时间。通过实例分析，证明本文提出的调度算法可以实现汽车检测控制系统的调度功能。

4 结束语

本文设计的算法目前在榆林、咸阳、商洛等多个地区的10多个机动车安全性能检验系统中进行了测试使用，算法稳定可靠，满足全程实时联网环境下的调度要求，加快了检验机构的工作效率，减少了车主的等待时间，确保检验机构数据与监管平台数据的一致性。