新型汽車檢測控制系統(tǒng)調度算法*

張立成，劉曉鑫，郝茹茹，周 洲，尚旭明

(長安大學 信息工程學院，陜西 西安 710064)

0 引言

隨著我國經(jīng)濟社會持續(xù)快速發(fā)展，機動車保有量呈快速增長趨勢，據(jù)公安部交通管理局統(tǒng)計，截至2017年底，全國機動車保有量達3.10億輛，其中汽車2.17億輛，與2016年相比，全年增加2 304萬輛，增長11.85%[1]。汽車安全性能檢測是保證道路交通安全的重要措施之一，國家相關部門高度重視，陸續(xù)制定出臺了面向機動車安全性能檢測與綜合性能檢測的系列標準[2-4]。除此之外，還出臺相關政策，如機動車檢驗業(yè)務逐步社會化、市場化來緩解車主檢車排隊、檢驗時間長等問題[5]。為了檢驗業(yè)務更加公平公正，2015年，公安部要求各交警支隊使用全國統(tǒng)一版的機動車檢驗監(jiān)督管理系統(tǒng)，各檢驗機構部署安裝機動車安全技術檢驗業(yè)務信息系統(tǒng)，該業(yè)務信息系統(tǒng)要滿足國家標準GB/T26765-2011《機動車安全技術檢驗業(yè)務信息系統(tǒng)及聯(lián)網(wǎng)規(guī)范》[6-7]。標準實施后，每個檢驗項目開始檢驗前需要向檢驗監(jiān)督管理系統(tǒng)申請，申請成功后拍攝檢驗過程照片并上傳，檢驗完成時需要上傳檢驗結果，再申請檢驗結束。因此設計合理、穩(wěn)定、高效的車輛檢測調度算法顯得尤為重要。另外新標準實施后，現(xiàn)有的檢測調度算法存在一些不足，如檢驗結果上傳成功后，該項目則被鎖定，不能繼續(xù)申請檢驗，也不能再次上傳檢驗結果，因此對檢測異常中斷的一些項目，如制動，需要斷點保存功能，否則會形成本地報告單數(shù)據(jù)與監(jiān)管平臺數(shù)據(jù)的不同步。

本文分析了現(xiàn)有調度算法的基本原理和不足，提出了一種改進的基于狀態(tài)機的調度算法，并詳細描述了實現(xiàn)過程。

1 現(xiàn)有調度算法

1.1 文件共享

該方式的基本思路是在各個工位硬盤上建立共享文件夾，主控機將報檢信息以一定格式，如request.ini文件，寫入到共享文件夾下，工位機在空閑時實時掃描判定是否有新的報檢文件生成，如果有新的報檢文件，則讀取報檢信息，檢測完成后將檢測數(shù)據(jù)寫入共享文件result.ini中，并將request.ini文件刪除，主控機判定request.ini文件被刪除后，讀取共享文件result.ini獲取檢測數(shù)據(jù)，數(shù)據(jù)讀完后刪除result.ini文件。該方法存在諸多問題：(1)實際使用過程中，經(jīng)常出現(xiàn)由于病毒原因或安全策略設置原因導致共享文件夾無法訪問的現(xiàn)象，整個系統(tǒng)無法調度，甚至癱瘓；(2)工位機或主控機輪詢報檢信息或結果信息消耗大量CPU資源，尤其是主控機程序，需要處理的任務比較多，降低了系統(tǒng)調度的實時性，工位數(shù)量越多，實時性越差，不利于系統(tǒng)擴展；(3)系統(tǒng)可靠性差，一旦工位機的報檢信息文件被破壞或誤操作，系統(tǒng)將無法正常運行。

1.2 基于winsocket的車輛調度

文獻[8]介紹了一種基于winsocket的車輛動態(tài)調度方法。每個工位機在不發(fā)生故障的情況下，有空閑、忙和等待三種狀態(tài)，當任何一個工位機進入新狀態(tài)后都必須向主控機及時通報，直到主控機對該狀態(tài)進行確認為止。與共享文件方式不同，信息是通過winsocket消息發(fā)送給工位機，如：第i個工位空閑(i取1,2,3，…,MaxGwNum)，報檢隊列不為空時，主控機給第i工位發(fā)送報檢數(shù)據(jù)幀，延時n秒后，主控機檢測是否收到第i工位機回應，若收到則判定報檢信息發(fā)送成功，否則重發(fā)，延時次數(shù)增1，若延時次數(shù)超過設定閾值，系統(tǒng)報網(wǎng)絡錯誤。第i工位收到報檢數(shù)據(jù)幀后執(zhí)行檢測任務，狀態(tài)由空閑變?yōu)槊Γ瑱z測完成后，檢測數(shù)據(jù)按照一定幀格式發(fā)送給主控機并等待主控機調度，狀態(tài)由忙變?yōu)榈却?。主控通過第i+1工位發(fā)來的winsocket消息判斷i+1工位的狀態(tài)，若第i+1工位狀態(tài)為忙，則第i工位一直等待，若第i+1工位空閑，主控請求第i工位離開，延時n秒后，判斷第i工位是否回應，若第i工位沒有回應，延時次數(shù)增1，若延時次數(shù)超過設定閾值，系統(tǒng)報網(wǎng)絡錯誤；若第i工位回應，第i工位狀態(tài)由忙變?yōu)榭臻e，主控向第i+1工位發(fā)送報檢信息，依次類推。該調度算法利用TCP握手機制保證了數(shù)據(jù)發(fā)送的可靠性，整體優(yōu)于文件共享方式，但是也存在如下幾點不足：(1)命令幀和數(shù)據(jù)幀都是通過winsocket實現(xiàn)主控機與工位機之間的交換，命令幀數(shù)據(jù)量小，數(shù)據(jù)幀數(shù)據(jù)量大，尤其是近些年來國家監(jiān)管部門要求傳輸制動力曲線、工位檢測圖片、視頻等大容量數(shù)據(jù)，該數(shù)據(jù)傳送方式容易丟幀，實現(xiàn)復雜，系統(tǒng)可靠性、實時性降低；(2)第i工位機出現(xiàn)掉電、重啟等故障時，軟件重新運行后，檢測信息丟失，需要等待主控機重新發(fā)報檢信息；(3)機動車安全檢驗機構連入監(jiān)管平臺后，實現(xiàn)了檢測節(jié)拍的過程控制，若制動某軸檢測完成后，支隊網(wǎng)絡突然發(fā)生異?；驒z測軟件異常中斷，只能通過業(yè)務退辦繼續(xù)檢測，給檢驗機構帶來不便，降低了檢驗效率。

2 核心算法設計

2.1 調度表設計

算法設計的調度表包括工位狀態(tài)表和工位調度狀態(tài)表，工位狀態(tài)表命名為GWZT，其數(shù)據(jù)字典設計如表1所示。

表1 工位狀態(tài)表數(shù)據(jù)字典

gwnflg設計有3種狀態(tài)，有檢測任務時狀態(tài)為9，無檢測任務時狀態(tài)為1，其他狀態(tài)為無效狀態(tài)，如被屏蔽狀態(tài)、存在硬件故障狀態(tài)等，賦值為0。屏蔽或故障狀態(tài)的工位不參與調度。

工位調度狀態(tài)表命名為GWiZT，i為工位的序號，工位狀態(tài)表依次為GW1ZT,GW2ZT,…,GWnZT。若檢測線共有3個工位，即n=3，工位調度狀態(tài)表即有GW1ZT,GW2ZT,GW3ZT。數(shù)據(jù)字典設計如表2所示。

表2 工位調度狀態(tài)表數(shù)據(jù)字典

jcflgi設計有4種狀態(tài)，正在檢測時狀態(tài)為1，檢測完成時狀態(tài)為9，出現(xiàn)故障時狀態(tài)為7，其他為初始化狀態(tài)，值為0，如表3所示。

表3 工位檢測狀態(tài)表

ctrlflgi設計有5種狀態(tài)，有檢測任務時，控制狀態(tài)賦值為8，表示檢測命令；本工位所有報檢項目檢測完成，且下一工位正忙，控制狀態(tài)賦值為1，表示等待命令；本工位所有報檢項目檢測完成，且下一工位空閑，控制狀態(tài)賦值為9，表示前進命令；若檢測任務由于某些原因被終止，控制狀態(tài)賦值為7，表示中斷檢測命令，如表4所示。

表4 工位控制指令表

2.2 主控調度算法

利用工位狀態(tài)表及工位調度狀態(tài)表，將每個工位的工位狀態(tài)gwnflg、工位檢測狀態(tài)jcflgi、工位控制指令ctrlflgi組成三個數(shù)的組合。由排列組合原理，共有3×4×5 = 60種組合。其中有很多為無效組合，將有效組合整理出來，如表5所示。

表5 工位組合狀態(tài)表

假設工位i沒有故障，也沒有被屏蔽，則該工位為有效工位(以下所述工位指有效工位)。若工位數(shù)為n,系統(tǒng)初始時，各工位組合狀態(tài)都為“100”(以下所述狀態(tài)指組合狀態(tài))。如果是第1個工位(i=n)，從報檢隊列中按報檢先后順序選擇一輛待檢車，將第1個工位狀態(tài)更新為“918”，此時其他工位的狀態(tài)是“100”。如果第1個工位檢測任務完成，其狀態(tài)為“991”，表示第1個工位任務檢測完成，需要等待。如果第2(i=n-1) 個工位有檢測任務，則保持第1個工位的狀態(tài)為“991”，點陣屏提示引車員“請等待”；否則將第2個工位狀態(tài)更新為“918”，同時將第1個工位狀態(tài)更新為“999”，點陣屏提示引車員“請前進”，在隨后調度過程中，第1個工位的狀態(tài)會更新為初始狀態(tài)“100”，此時第1個工位的檢測任務調度到了第2個工位，依次類推。當調度到第n個工位時(i=1)，需要對每個工位的數(shù)據(jù)進行合成處理。具體算法細節(jié)見算法1。

算法1：主控調度算法

設工位序號為i(i=1,…,n),n為工位數(shù)。

1:輸入：第i個工位狀態(tài)Si,第i+1個工位狀態(tài)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表，執(zhí)行主控調度算法賦予的檢測指令，具體算法細節(jié)見算法2。

算法2：工位調度算法

設工位序號為i(i=1,…,n),n為工位數(shù)。

1:輸入：第i個工位控制狀態(tài)Ci，第i個工位檢測狀態(tà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

本文設計的算法，當工位組合狀態(tài)為"918"時，每完成一項檢測節(jié)拍，將檢驗數(shù)據(jù)更新到數(shù)據(jù)庫中，新的聯(lián)網(wǎng)監(jiān)管系統(tǒng)實現(xiàn)了檢測車輛的過程控制和過程監(jiān)管。以制動為例，制動的每個軸檢驗前需要申請，檢驗完成后需要上傳檢驗結果及項目結束信息，一旦檢驗結果信息成功上傳，不可重新上傳覆蓋。為此，在結果表中增加檢驗項目上傳成功標志信息，如B1表示一軸制動、B2表示二軸制動等。B1=1表示一軸檢測完成且成功上傳，B2=0表示二軸檢測未完成等，當工位檢測軟件因網(wǎng)絡故障、硬件故障等原因需要重新運行時，工位狀態(tài)仍為"918"，只有檢測完成時狀態(tài)才會被更新為"991"，基于網(wǎng)絡數(shù)據(jù)庫的狀態(tài)調度算法在軟件重新運行時通過讀取相應的工位狀態(tài)表和工位調度狀態(tài)表即可重新獲取報檢信息，繼續(xù)檢測，而基于winsocket通信方式的算法必須等待主控重發(fā)報檢信息。而且，本文設計的算法在軟件異常重啟時根據(jù)標志位即可判定哪些項目已經(jīng)檢驗完成且成功上傳，自動加載已檢測完成且上傳成功的車輛檢測數(shù)據(jù)，繼續(xù)未檢測項目。這樣既避免了重復檢測，節(jié)省了時間，也確保了監(jiān)管中心的數(shù)據(jù)與本地檢測數(shù)據(jù)一致。

3 算法測試

為了驗證本文提出的新型調度算法，采用實例分析對算法的可行性和合理性進行測試。假設有3個工位，選取5輛待檢車輛。為5輛車輛在3個工位上分配檢測任務，車輛檢測耗時如表6所示。

表6 車輛檢測項目耗時表 (min)

圖1是本文提出的調度算法按照表6所示的檢測項目耗時表的調度Gantt圖。Gantt圖中展示了5輛待檢車輛在3個檢測工位上的消耗時間。通過實例分析，證明本文提出的調度算法可以實現(xiàn)汽車檢測控制系統(tǒng)的調度功能。

4 結束語

本文設計的算法目前在榆林、咸陽、商洛等多個地區(qū)的10多個機動車安全性能檢驗系統(tǒng)中進行了測試使用，算法穩(wěn)定可靠，滿足全程實時聯(lián)網(wǎng)環(huán)境下的調度要求，加快了檢驗機構的工作效率，減少了車主的等待時間，確保檢驗機構數(shù)據(jù)與監(jiān)管平臺數(shù)據(jù)的一致性。