朱欽鴻 鮑敏



關鍵詞:模式匹配;通訊協議;XML;異構數據;微服務
中圖分類號:TP311.5 文獻標識碼:A 文章編號:1006-8228(2023)11-100-04
0 引言
工業企業的智能化改造通常跟隨著設備聯網,通過設備產量、質量數據的自動化上傳及分析,給優化決策算法提供數據依據。我們的目標企業擁有60 條不同時期建設的自動產線,其機床設備的供應商、PLC系統、數控程序版本均有差異,通訊協議、數據地址、數據格式三項設備聯網的關鍵內容無法統一。因此設計一個支持插拔式的協議數據解析系統是解決各采集設備與控制中心之間數據傳輸,降低采集模塊更新成本的重要部分[1]。
本文提出一種利用軟件層協議來避免直接操作底層協議的設計方案[2]。系統采用基于C 語言開發的數據結構,通過數據映射,實現動態轉換模式的自適應,從而降低了開發解析系統的時間和人力成本,提高了系統的可維護性。開發者設計數據模型解析方式及其對應的模型結構,用戶僅需要修改數據模型即可完成對解析系統的規則更新。
1 設計方案
本文的研究內容是異構數據動態解析系統設計。通訊協議是完成不同服務之間的數據交互的一種規則,由語法、語義、同步這三大要素構成[3]。而數據解析就是通過事先規定好的協議將可利用的數據信息從數據幀中提取出來。該解析系統依靠軟件層面的通訊協議實現解析范圍的動態自適應,以及對數據轉換器服務進行統一的配置;最終實現異構數據動態解析系統的標準化、規模化。本章節將對解析系統的整體架構進行詳細分析。
1.1 模型架構
本文提出的異構數據動態解析系統的架構如圖1所示,該系統由五個部分組成:配置中心模塊、模式匹配模塊、數據轉換模塊、服務注冊模塊、鏈路追蹤模塊,各模塊之間相互配合,完成異構數據的實時轉換[4]。
⑴ 配置中心模塊:集中管理系統中的配置信息,實現系統配置的集中管理、分發。
⑵ 模式匹配模塊:基于自定義的哈希數據結構,建立異構數據與轉換器之間的映射關系。
⑶ 數據轉換模塊:服務啟動時完成初始化操作,通過讀取XML 文件內的數據模型來創建對應的數據轉換器。相應的數據轉換器根據制定的轉換規則對異構數據進行標準化處理。
⑷ 服務注冊模塊:服務注冊模塊會將所有的服務實例添加到注冊中心,使某個微服務可以發現和調用注冊中心的服務。
⑸ 鏈路追蹤模塊:對服務調用和網絡連接情況進行追蹤記錄,當系統出現異常時能幫助維護人員很好地定位到問題所在點。
1.2 系統處理機制
步驟一:系統進行初始化操作,模式匹配器模塊和數據轉換器模塊分別通過讀取配置中心內的配置信息,生成對應的服務并注冊到服務注冊中心。
步驟二:系統接收到異構數據,鏈路追蹤模塊開始運行,記錄數據后續的操作流程(見圖2 中過程①)。系統通過服務注冊中心調用模式匹配器,由模式匹配器導出異構數據和數據轉換器之間的映射關系(見圖2 中過程②)。
步驟三:系統根據映射關系調用數據轉換器,并通過數據轉換器進行數據的獲取和整理,最后將標準化的數據寫入到持久化數據庫中(見圖2 中過程③④⑤⑥)。
2 異構數據動態解析系統的實現
2.1 模式匹配器的設計
模式匹配器包含特征提取模塊、映射模塊和原始異構數據發送模塊,其中映射模塊是其核心部分。為了提高數據匹配效率,映射模塊采用了哈希表數據結構,并根據目標場景中查詢操作占絕大多數的特點,設計了一種高效的自定義哈希表數據結構。
哈希表的設計
哈希表是通過應用哈希函數將鍵值轉換為哈希值,并使用索引轉換計算出對應的一維數組索引來實現高效數據訪問的數據結構。由于哈希函數存在哈希碰撞的可能性,并且索引轉換可能會縮小哈希值的范圍,因此可能會發生索引沖突的情況。為了生成分布均勻的哈希值,本文采用了MurmurHash3 算法作為哈希函數,該算法具有快速計算和哈希值均勻分布的特點。在出現索引沖突情況下,通常可以采用以下兩種常見的解決方案[5-7]。
⑴ 開放地址法:當哈希沖突發生時,通過尋找數組中下一個空閑位置將該鍵值對數據插入空槽中。線性探測法、雙重哈希法是常見的開放地址法的實現方法。
⑵ 鏈地址法:數組每一個槽內都存放一個哈希桶的內存地址哈希桶由鏈表、數組等數據結構構成。當哈希沖突發生時,將多個鍵值對放入同一個哈希桶中。
本文采用鏈地址法作為一種解決哈希沖突的方法。相比于開放地址法,鏈地址法在代碼設計上更加簡單明了,而開放地址法則需要考慮更多的沖突處理細節。鑒于特殊的目標場景,查詢操作在其中占據了非常高的比例。因此,為了保證系統具有良好的性能表現,自定義哈希表采用了數組作為哈希桶的數據結構,以保證查詢操作的時間復雜度較低。哈希表的自定義結構如圖3 所示。
2.2 數據轉換器的設計
2.2.1 數據轉換器轉換流程設計
數據轉換器利用預加載模式,將通信協議信息提前加載到內存中,該協議描述了數據的校驗規則和解析流程。數據轉換器會先獲取協議中的標識符,并與原始異構數據中的標識符進行比較。若兩者匹配,則進行校驗碼驗證[8]。如果校驗失敗,則轉換器會要求模式匹配器進行重發(見圖4 中過程①②)。通過校驗后,數據轉換器會讀取數據區中的數據,并按照協議規定的解析流程,將其轉換成標準數據(參見圖4 中過程③)。
2.2.2 XML 協議文檔的制定
按照通訊協議規范,本文中提出的XML 協議文檔由多個標簽構成,表1 詳細列出了各個標簽的名稱與功能描述。
XML 協議文檔的標簽層級圖如圖5 所示。
3 實例測試
本實驗采用數據采集軟件,對原始異構數據進行封裝處理,并傳輸到異構數據動態解析系統,模擬現實工廠場景的運行情況。為使測試數據清晰呈現,實驗采用看板對相關實驗結果進行展示。
實驗設備:三臺64 位計算機、一臺無線路由器。
實驗設計:主服務器啟動解析系統,通過配置中心讀取XML 文件完成各個微服務的初始化。數據模擬軟件將異構數據傳遞給解析系統,從而完成數據標準化。在實驗過程中,需要對主服務器解析系統中的部分微服務進行啟停操作。通過數據看板觀察解析系統是否符合設計要求。
3.1 實驗環境搭建
針對工廠現場數據采集,本實驗開發了模擬數據采集軟件,如圖6 所示。異構數據來源于數據庫中的真實工廠數據,并且可以靈活地調節異構數據的采集比例和發送速率。
遵循本文提出的XML 協議文檔標簽定義和層級關系,編寫了如下XML 協議文檔,其中節選內容如圖7 所示。
3.2 實驗
根據實驗流程,用模擬軟件向異構數據動態解析系統發送異構數據,在實驗過程中進行了部分服務的啟停操作,并最終通過看板系統展示相關實驗數據。異構數據標準化實驗結果如圖8 所示,驗證了異構數據動態解析系統的數據轉換能力和可靠性。
4 結論
本文提出了一種目標工廠異構數據轉換問題的解決方案,即工業設備聯網場景下的異構數據動態解析系統。該系統采用微服務架構,包括模式匹配器、數據轉換器、服務注冊中心等組件,并通過添加或修改XML 文件數據來實現轉換對象的增加與修改,從而體現了系統的通用性和標準化特點。實驗結果表明,該解析系統能夠正確、高效地標準化異構數據,這項技術方案在制造業領域具有推廣和參考價值。