楊 飛 朱會兵 馬 和
(1.湖北省交通運輸廳漢十高速公路管理處 武漢 430051;2.武漢理工大學信息工程學院 武漢 430070)
隨著交通量的增長,通車時間越久,高速公路的破損情況就會越嚴重。早期修建的高速公路大多已接近使用年限,需要大修和改建;近年修建的高速公路也出現了不同程度的損壞。因此,及時準確地掌握高速公路的狀態信息并采取相應的養護措施,對于維持高速公路良好的使用狀態和保護人民群眾生命財產安全都具有重大意義。對于業務邏輯的實現,多數路面管理系統采取固化在程序代碼中的方式來實現,當業務邏輯很復雜并且發生變化時,系統的修改和擴展需要花費很大的代價。顯然,這種高度耦合的方式給系統帶來了很大風險。規則引擎可以很好地解決以上問題。本系統是以交通運輸部2012年度推廣應用項目——“瀝青路面智能化養護關鍵技術”成果為基礎,在構建了瀝青路面養護對策庫的基礎上,研發了一種采用基于規則引擎的路面智能養護系統。該系統采用Drools作為系統的規則引擎,主要解決了以下問題:公路養護規則引擎的設計和規則的實現;規則的維護和管理;規則沖突的解決;系統的兼容性;整合前臺顯示規則與后臺規則文件。
規則引擎是一種嵌入在應用程序中的組件,實現了將業務邏輯從應用程序中分離出來,并使用預定義的語義模塊編寫業務邏輯。規則引擎的主要工作是將輸入的數據對象與加載的規則進行匹配,并由符合條件的規則生成規則執行實例。目前主流的規則引擎包括Ilog JRules,Drools,Jess,等等[1]。其中Ilog JRules和Jess都是相當成熟的商業BRMS,提供了一套完整的規則建模、規則編寫、規則測試、規則部署和維護的工具,但是價格非常昂貴。Drools規則引擎是由JBoss開發的優秀的開源規則引擎[2],是開源規則引擎中使用最廣的產品之一。除具有一般規則引擎的優點外,還具有高效的算法、豐富的規則語言、強大的API和工具集成等特點[3]。故選擇Drools作為系統的規則引擎。
(1)基本信息模塊。主要包括路線編碼、區間編碼、路段編碼、公路等級、路面類型、車道類型、面層類型和基層類型等基本信息的管理。
(2)養護評價模塊。主要功能是對路面使用性能 (PQI)、路 面 破 損 (PCI)、路 面 平 整 度(RQI)、路面車轍(RDI)、路面抗滑性能(SRI)和路面結構強度(PSSI)6個路況參數做出評價。
(3)養護決策模塊。主要功能是根據路況數據得出養護方案和養護造價。
(4)規則管理模塊。主要包括規則文件的編輯、沖突解決策略。
(5)系統管理模塊。主要包括用戶管理、權限管理和系統日志。
系統邏輯結構分為表示層、業務邏輯層和數據持久層3個層次,見圖1。

圖1 系統邏輯架構圖
在表示層中,從JSP頁面發送來的請求被轉發到相應的Action控制器。Action控制器首先獲取用戶請求參數,然后調用業務邏輯層中相應的Service組件,Service組件再調用數據持久層中相應的Dao組件,執行相應的數據庫操作,返回的處理結果將通過Action輸出到JSP頁面。當用戶進行養護決策時,養護決策Action控制器調用業務邏輯層中的養護決策Service組件取得相應路況信息,調用規則管理Service組件從規則庫中取得規則文件。使用規則引擎進行模式匹配,匹配成功的規則被送入議程等待執行,執行完畢后,輸出養護方案。
依據“瀝青路面智能化養護關鍵技術”的研究成果,本系統根據養護對策生成各項的判別規則并存儲到數據庫中。例如:當PCI>70,RQI>43.8,RDI>70,SRI>80.5,PSSI>80.2,并且病害類型為裂縫、局部坑槽、擁包、沉陷、松散和翻漿其中之一時,養護方案為F11。
(1)如果用戶輸入的路況數據只包含PCI,RQI等5個參數,不含病害數據和輔助參數,則要先按使用相同判別參數的規則進行規則的合并,生成FILE類型的規則文件。
(2)如果用戶輸入的路況數據包含PCI,RQI等5個參數且包含病害數據,但不包含輔助參數,則合并后生成對應于FILEX類型的規則文件。
(3)如果用戶輸入的路況數據包含PCI,RQI等5個參數且包含輔助參數,但不包含病害數據,則合并后生成對應于FILEY類型的規則文件。
(4)如果用戶輸入的路況數據包含PCI,RQI等5個參數且包含病害數據,也包含輔助參數,則上述規則對應于FILEZ類型的規則文件。
一個標準的規則文件就是一個擴展名為.drl的文本文件。根據規則文件的結構,可以將規則分為3部分:屬性聲明部分(attribute)、條件部分(LHS)和結果部分(RHS)。規則格式如下:

為了方便用戶輸入,這里采用可視化界面進行規則的生成和管理;并且設計了一個專門用于“翻譯”的JavaBean,實現前臺顯示與后臺規則文件的統一,見圖2。

圖2 規則文件添加界面
養護決策模塊的處理流程包括數據準備、規則編譯、規則執行和養護方案生成4部分。啟動養護決策之后,首先判斷數據庫中是否存在指定的路況數據,如果存在,則讀取路況數據和規則文件。然后編譯規則文件,編譯通過之后設置全局變量,并插入路況數據,執行規則文件,如果已經生成養護方案,則計算造價并存入數據庫,見圖3。

圖3 養護決策流程圖
一個事實對象在模式匹配的過程中,規則庫中有多條規則與之匹配,從而可能產生多種結果,但不能確定具體得到哪個結果,即稱產生了規則沖突[4]。規則沖突的根源來自于規則庫的邏輯不完備或者不一致。因為規則庫本身是一個邏輯系統,當規則庫的添加或者修改導致規則庫的邏輯不一致或者不完備時,就會發生規則沖突。Drools提供的沖突解決策略包括設置優先級和LIFO(后進先出)[5]。通過給規則設置優先級,可以確保不同優先級的規則不發生沖突,但是相同優先級的規則仍然可能沖突。后進先出策略只是簡單地讓后進入議程(Agenda)的規則先被激活,但是對可能存在的沖突沒有做任何處理。
如何發現這種邏輯上的包含關系是問題的關鍵。一種方法是直接寫if判斷語句,如果用戶輸入的規則條件里有“不要求”語句,并且條件的其他部分與規則庫里的某一條規則相同,那么就判定用戶輸入的規則不合法。如此需要考慮的情況將非常復雜,因為用戶輸入的規則里可能只有一個“不要求”語句,也可能有多個,而且具體是哪一個參數“不要求”也是不確定的,還有可能用戶輸入的規則里沒有“不要求”語句,而規則庫里的規則有“不要求”語句,這樣也會形成邏輯沖突。
受集合論的啟發,再考慮到Java優秀的字符串處理能力,筆者采用如下方法來檢測邏輯沖突:為規則條件的每個部分加一個標記值,用于表示該項條件所代表的集合,約定“大于”記A,“小于”記B,則“不要求”記AB。例如,用戶輸入2條規則,記為 Rule A 和 Rule B,Rule A 的內容為:當PCI>70,RQI>43.8,RDI>70,SRI>80.5,PSSI>80.2時,養護方案為F11;Rule B的內容為:當PCI>70,RQI>43.8,RDI不要求,SRI>80.5,PSSI>80.2時,養護方案為F12。則Rule A的標記值表示為(A,A,A,A,A),Rule B的標記值可以表示為(A,A,AB,A,A)。這樣要檢測這種邏輯上的包含關系,只需用java.lang.String的contains()方法就可以實現。首先對用戶輸入規則文件的條件部分所對應的標記值進行賦值,然后將其與規則庫里的規則文件逐個進行比較,這里又分2種情況,一種是用戶輸入規則在邏輯上被包含,另一種是用戶輸入規則在邏輯上包含規則庫里的規則,這兩種情況都屬于邏輯沖突,記錄下沖突規則的ID后,就可以設置警告信息。
針對現代路面信息管理系統面臨的問題,本文介紹了基于Drools規則引擎的路面信息管理和決策系統的解決方案,討論了系統的總體架構、業務規則的生成和管理、養護決策的處理流程和沖突的解決策略。文中利用Java語言的字符串處理能力,通過比較用戶輸入的規則與規則庫原有規則,實現規則的沖突檢測功能,防止規則的重復與沖突,保證了系統的穩定性。針對用戶輸入的路況數據可能不全面,存在參數缺失的情況,合理設計規則結構,使規則庫可以處理多種類型數據,提高了系統的兼容性。設計了一個專門用于“翻譯”的JavaBean,實現前臺顯示規則與后臺規則文件的統一。
[1]張 淵,夏清國.基于Rete算法的Java規則引擎[J].科學技術與工程,2006,6(11):1548-1550.
[2]王重英.基于規則引擎的工作流系統設計[J].現代電子技術,2009(12):42-44.
[3]馬秀麗,王紅霞,張凌云.Drools在網絡故障管理系統中的應用[J].計算機工程與設計,2009,30(8):1859-1862.
[4]ROSENBERG F,DUSTDAR S.Business rules integration in BPEL-a service-oriented approach[C]//7th International IEEE Conference on E-Commerce Technology(CEC’2005).Washington DC:IEEE Computer Society Press,2005:476-479.
[5]GRAHAM I.Business rules management and service oriented architecture[M].[S.l.]:Wiley,2007.