熱門論文
最新論文
基于語義的工業設備信息管理系統 設計與實現
發布時間：2023-07-18 09:44
目錄
圖錄 VIII
表錄 X
注釋表 XI
第1 章 緒論 1
1.1研究背景和意義 1
1.1.1 研究背景 1
1.1.2 研究意義 2
1.2國內外研究現狀 3
1.2.1語義網技術研究現狀 3
1.2.2設備管理研究現狀 3
1.3基于語義的設備信息管理系統概述 4
1.3.1語義網技術體系 4
1.3.2語義網技術與設備信息管理系統 5
1.4論文研究工作概述 6
1.4.1目前存在主要問題 6
1.4.2研究工作及創新點 7
1.5論文組織結構 8
1.6本章小結 9
第2章 基于語義的工業設備信息管理系統分析 10
2.1系統可行性分析 10
2.2系統需求分析 11
2.2.1系統功能需求分析 11
2.2.2開發環境及工具需求分析 12
2.3OPC UA技術應用需求分析 13
2.4數據庫需求分析 13
2.5本章小結 14
第3 章 工業設備信息管理中知識本體的構建研究與實現 15
3.1本體建模 15
3.1.1本體建模準則 15
3.1.2本體建模方法 16
3.1.3本體建模實現 17
3.2本體實例映射 22
3.2.1設備靜態信息實例映射 22
3.2.2設備動態信息實例映射 25
3.3本體一致性檢測 28
3.3.1一致性檢測依據 28
3.3.2一致性檢測方法 29
3.3.3一致性檢測實現 30
3.4本章小結 32
第4 章 基于語義的工業設備信息管理系統模塊設計與實現 33
4.1系統整體結構設計 33
4.1.1系統體系結構設計 33
4.1.2系統軟件結構設計 34
4.1.3系統功能模塊設計 36
4.2系統功能模塊實現 38
4.2.1系統管理模塊實現 38
4.2.2設備狀態實時監測模塊實現 40
4.2.3設備語義信息管理模塊實現 42
4.2.4設備語義信息查詢模塊實現 46
4.2.5設備異常報警及維修策略知識提供模塊實現 49
4.3本章小結 54
第5 章 測試驗證及分析 55
5.1 測試系統搭建 55
5.1.1 系統結構 55
5.1.2 軟硬件環境 55
5.2基于語義的工業設備信息管理系統測試 56
5.2.1系統管理模塊測試 56
5.2.2 設備狀態實時監測測試 57
5.2.3設備語義信息管理測試 58
5.2.4設備語義信息查詢測試 64
5.2.5 設備異常報警及維修策略知識提供測試 67
5.3 本章小結 69
第6章 總結與展望 70
6.1 課題總結 70
6.2 未來展望 71
參考文獻 72
致謝 75
攻讀碩士學位期間從事的科研工作及取得的成果 76
圖錄
圖 1.1 語義網層次模型 4
圖 1.2 系統軟件層次 6
圖 1.3 論文組織結構 8
圖 2.1 AllegroGraph 軟件架構 14
圖3.1領域本體構建流程 16
圖 3.2 AirConditioner 設備信息 E-R 模型 18
圖3.3設備本體模型類層次結構 19
圖3.4設備本體模型屬性層次結構 19
圖3.5設備信息本體模型 21
圖3.6策略知識本體 21
圖3.7設備靜態信息實例映射過程 24
圖3.8設備相關的部分靜態數據RDF模型表示 24
圖3.9設備動態信息實例映射過程 25
圖3.10 OPC UA服務器設備節點信息RDF描述 26
圖3.11基于本體的語義擴展流程 27
圖3.12基于本體的語義擴展后RDF描述 27
圖3.13本體一致性檢測過程 30
圖3.14本體導入Protege軟件 30
圖3.15 Protege軟件中本體一致性檢測選項選擇 31
圖3.16設備信息本體一致性檢測結果 31
圖4.1系統部署結構圖 34
圖4.2系統軟件結構圖 35
圖4.3基于語義的工業設備信息管理系統功能結構圖 36
圖4.4用戶屬性注冊語義信息 38
圖4.5 登錄驗證流程圖 39
圖4.6 OPC UA客戶端/服務器結構 40
圖4.7工業設備狀態實時監測模塊開發軟件架構 41
圖4.8 OPC UA演示服務器 41
圖4.9工業設備狀態信息實時采集開發流程圖 42
圖4.10設備臺賬數據模型定義 43
圖4.11語義信息查詢模塊框架 47
圖4.12 TripleINF的類型結構 48
圖4.13 AGJena推理模塊框架 53
圖4.14規則推理流程圖 53
圖5.1系統結構圖 55
圖5.2系統登錄訪問界面 57
圖5.3登錄成功后主界面 57
圖5.4設備狀態實時采集顯示界面 58
圖5.5設備入庫本體實例映射界面 59
圖5.6設備操作人員本體實例映射界面 59
圖5.7設備維修記錄本體實例映射 60
圖5.8設備本體實例生成測試結果 60
圖5.9設備操作人員本體實例生成測試結果 61
圖5.10設備維修記錄本體實例生成測試結果 61
圖5.11添加屬性測試界面 62
圖5.12刪除實例測試界面 63
圖5.13修改實例測試界面 63
圖5.14設備操作人員語義信息查詢界面 64
圖5.15設備操作人員語義信息查詢界面 65
圖5.16查全率比較圖 66
圖5.17查準率比較圖 66
圖5.18設備監測及異常報警界面 67
圖5.19 AirConditioner_1設備異常報警及策略提供結果圖 68
圖5.20設備維修提醒界面圖 68
圖5.21 AirConditioner_1設備維修提醒及策略提供結果圖 69
表錄
表3.1 設備靜態信息關聯表 22
表3.2 設備臺賬信息表 22
表3.3 設備基本信息表 22
表 3.4 設備生產產商信息表 23
表3.5 操作人員信息表 23
表 3.6 設備維修信息表 23
表 3.7 設備維修記錄表 23
表3.8 設備維修人員信息表 23
表3.9 OWL類公理 28
表3.10 常用的部分屬性公理 29
表4.1 設備異常限值選定及判決 50
表4.2 設備維修判決及維修類型 50
表5.1 測試系統的軟硬件資源表 56
注釋表
MES Manufacturing Execution System，制造企業生產過程執行系統
OPC OLE For Process Control，用于過程控制的對象鏈接嵌入技術
OLE Object Linking and Embedding，對象鏈接嵌入技術
UA Unified Architecture，統一架構
XML extensible Markup Language，可擴展標記語言
SW Semantic Web，語義網
W3C World Wide Web Consortium，萬維網聯盟
RDF Resource Description Framework，資源描述框架
RDFS RDF Schema， RDF 模式
OWL Web Ontology Language， Web 本體語言
OIL Ontology Interchange Language 本體交換語言
SPARQL Simple Protocol and RDF Query Language，簡單協議和 RDF 查詢語言
ISWC International Semantic Web Conference， 國際語義網大會
ESWC Europe Semantic Web Conference，歐洲語義網大會
ASWC Asia Semantic Web Conference，亞洲語義網大會
CMMS Computer Maintenance Management System， 計算機維護系統
EAM Enterprise Asset Management， 企業資產管理
B/S Browser/Server，瀏覽器/服務器模式
SDK Software Development Kit，軟件開發工具包
REST Representational State Transfer，表述性狀態傳遞
J2EE Java 2 Enterprise Edition， Java 企業版
JSP Java Server Pages， Java 服務器頁面
MVC Model-View-Controller，模型-視圖-控制器
Ajax Asynchronous JavaScript And XML，異步 JavaScript 和 XML
WWW World Wide Web，萬維網
API Application Program Interface， 應用程序接口
E-R Entity-Realtion Model，實體-關系模型
URI Uniform Resource Identifier，統一資源標識符
URL Uniform Resource Locator，統一資源定位符
TBox Terminology Box，術語集
ABox Assertion Box， 斷言集
第 1 章 緒論
本章首先針對基于語義的工業設備信息管理系統所做的研究工作，闡述與之相 關的研究背景、研究意義和相關技術領域的國內外研究現狀；然后，概述語義網技 術體系及其與設備信息管理系統的內在聯系；最后，總結當前工業設備信息管理系 統存在的主要問題并提出相應的解決辦法。
1.1研究背景和意義
1.1.1研究背景
在現代工業企業中，設備是勞動力和物質材料的總稱，可用于生產過程中的長 期、重復使用，基本上保持其原有的物理形態和功能［1］。設備體現了企業的現代化 和科技水平，直接影響著企業的生產經營活動，在企業生產經營過程中占有越來越 重要的地位。設備管理是企業管理的重要組成部分，為了建設好設備管理機制，不 僅需要政府部門加大監督、調控和管理力度，還需要企業加強管理，積極轉機建制， 改制、改革［2］。此外，設備廠商和最終用戶開始越來越重視工業設備的運行狀態監 控、故障診斷、設備點檢、備件管理等應用。相應的，越來越多的廠商開始采用遠 程設備監控和管理系統［3］。隨著工業 4.0 的發展和 MES(Manufacturing Execution System)在工業企業中的應用，企業將對設備裝備水平和服務要求不斷提高，傳統的 設備管理方案逐漸暴露出弊端，表現在：(1) 基于典型監控的方案，靈活性和擴展 能力不足；(2) 基于典型信息化的方案，容量、磁盤空間和智能性欠缺；(3) 沒有解 決好基于 Internet 的實時數據采集。
萬維網在人類生活的各個方面產生了深遠影響，人們通過互聯網來獲取信息［4］。 然而，隨著萬維網信息的爆炸性增長，人們越來越難以準確、迅速和全面地獲得信 息。鑒于此，萬維網之父Tim Berners-Lee于1998年將語義概念引入互聯網，提出 了語義網(Semantic Web, SW)概念，希望互聯網能夠在未來智能地處理和提供信息［5］。 與此同時，萬維網聯盟W3C(World Wide Web Consortium)制定了一系列的語義網技 術規范，這些規范推動著語義網不斷發展，其中包括資源描述框架 RDF(Resource Description Framework)、SPARQL(Simple Protocol and RDF Query Language)、Web 本體語言OWL(Web Ontology Language)等。語義網是一種智能網絡，可以根據語義 進行判斷，實現人與計算機之間的無障礙通信。語義網最大的好處是允許計算機智 能地評估存儲在網絡空間中的數據。這樣，計算機就可以理解人腦等信息的含義， 完成智能Agent的功能［5, 6］。語義網所產生的語義網技術為解決計算機對信息難以理 解、缺乏集成應用等問題提供了技術支撐。語義網技術是一種用于描述現實世界中 數據和實體的技術，以便機器可以基于語義描述來理解、處理數據和實體。近年來， 工業物聯網研究者將語義網技術引入到物聯網中，用于解決工業物聯網存在的資源 異構、互操作性困難等問題。語義網中的一些關鍵技術，如：本體構建、語義化標 注、語義推理、語義查詢和語義組合等可以加快實現工業物聯網的智能化發展。
1.1.2研究意義
設備管理作為企業管理的重要組成部分，其所占的比例越來越大，設備管理產 生的費用也逐年增加。因此，設備管理自動化、智能化成為了研究熱點，也取得了 一些成果，但在實施過程中仍然面臨著設備信息存在孤島，缺乏統一定義；設備狀 態監測實時性不強，不能為遠程的故障診斷用戶提供設備實時數據；保留歷史數據 的時間短，難以和其它管理系統集成；設備管理效率低和管理成本過高等問題。因 此本文結合實驗室語義網技術開發資源和OPC UA(OPC Unified Architecture)研究成 果，對基于語義的工業設備信息管理系統進行研究，其意義在于：
1.將本體技術引入設備管理領域，基于本體對設備信息進行組織和管理，不但 消除了因設備種類多，數據量大、數據分布異構存在的孤島，而且使設備信息具備 了計算機可理解的語義，實現信息共享。
2.基于OPC UA技術實現工業設備狀態的實時監測，可以為遠程故障診斷用戶 提供設備狀態實時數據，及時對設備進行診斷，避免因設備故障造成企業生產停滯。
3.基于 RDF 圖模型實現工業設備信息的語義化描述，不僅可以為設備保養、 設備維修、設備異常報警等的智能化應用提供數據支撐，還可以減少數據信息結構 修改和維護上的困難。
4.基于規則推理實現工業設備管理策略提供，避免因人為原因造成的錯誤管理， 為設備維護、生產過程狀態優化、故障診斷等提供決策知識，同時實現對策略知識 的重用，提高設備管理效率和智能化程度，降低管理成本，減少人工參與度。
1.2國內外研究現狀
1.2.1語義網技術研究現狀
在2001年，W3C創始人Tim Berners-Lee正式提出了語義網［7］。此后，W3C組 織針對語義網發布了一系列推薦規范，在 2004年 2月， W3C 發布了 RDF 和 OWL 推薦規范；在 2007 年 11 月， W3C 發布了 SPARQL 推薦規范；在 2009 年 4 月， W3C發布了 OWL2推薦規范，增加了可以在OWL的基礎上進行有效推理和使用的 功能。國內外針對語義網也舉辦了諸多會議，如：國際語義網大會ISWC(International Semantic Web Conference) > 歐洲語義網大會 ESWC(Europe Semantic Web Conference) 和亞洲語義網大會 ASWC(Asia Semantic Web Conference)等。
在國外，語義網早已受到廣大研究人員的關注和研究。通過以 W3C 組織、微 軟、富士通、斯坦福大學為代表的各界研究者們的努力和研究，語義網在理論和應 用上取得了很大的進步，例如：提出了 Stack、 Two Towers 等語義網體系結構模型； 提出了 RDF 語言規范用以描述資源及資源間關系；提出了 OWL、 OIL(Ontology Interchange Language)等諸多本體語言；提出了骨架法、七步法、IDEF-5法等本體構 建方法；開發了 Protege> Jena等本體建模工具；制定了 RDF、OWL、SPARQL等 一系列技術標準；出現了 Scholonto、Swoogle等典型應用等等。
在國內，我國語義網技術的研究相對較晚，比較落后，然而進步很快。早在2002 年，語義網技術就被國家863 計劃列為了重點支持項目；在2005 和 2006年的 ISWC 會議上，以中國研究機構為第一作者的文章就有四篇，充分說明我國研究者已經開 始在重視語義網技術研究，研究內容也越來越廣泛和深入，并取得了一定的成就。
1.2.2設備管理研究現狀
設備管理的理論和實踐非常豐富。自20世紀以來，已經形成了兩個主要的維護 和管理系統：由前蘇聯為代表的“計劃預修系統”和以美國為代表的“預防維護系 統”［8］。美國提出了相關的設備工程理論，并將工程技術和管理技術結合實現對設 備臺賬、設備維護、倉儲等信息的管理。從上世紀60年代開始，國內外就對企業的 設備管理進行了大量研究，提出了諸多管理系統，如： CMMS(Computer Maintenance Management System)、EAM(Enterprise Asset Management)等［9］。
在國外，日本的工業借鑒了美國和英國的管理理念，遵循嚴格和安全的生產理 念，提出了針對安全生產的設備管理理念［10, 11］。瑞典開發的設備庫存管理系統受到 歐洲國家的歡迎，美國等國家也開始研究基于計算機技術的設備管理。一些大型外 國公司涉及許多領域，對于設備信息管理的自動化、智能化需求更為迫切［12, 13］。
在中國，中國引入了前蘇聯統一的“計劃預修系統”，為在中國建立科學的設 備管理系統奠定了基礎。 20世紀 80 年代以后，國內一些大型企業開始引進美國等 西方國家的管理信息系統，但管理方法和管理工作遠遠不夠科學化、系統化［14］。國 內一些中小型企業依舊采用傳統的設備信息管理方法，人工登記臺賬、備件、維修 信息等，費時費力，并且效率低下［15, 16］。因此，采用更加先進、自動化、智能化的 管理方法是大大提高企業生產和管理效率的唯一有效途徑。
1.3基于語義的設備信息管理系統概述
1.3.1語義網技術體系
最初的語義網層次模型是由Tim Berners-Lee在2000年提出的。近年來，由于 語義網技術的快速發展，該模型不斷地獲得改進和擴展。在2006年， Tim Berners-Lee 提出了一個新的語義網層次模型［17］，如圖 1.1 所示。
用戶接口和應用
信任
證明
統一的邏輯
查詢 SPARQL 本體 規則
OWL RIF
RDFS
數據交換RDF
XML 命名空間
URI UNICODE
圖 1.1 語義網層次模型
下面將對本文研究過程中使用的五個層次進行介紹：
1.UNICODE 和 URI 層
該層是語義網的基礎層，包括UNICODE和URI(Uniform Resource Identifier)， 其中UNICODE作為一種國際字符集編碼標準，允許所有人類語言以標準化形式在 網絡上使用；URI是統一資源定位符URL(Uniform Resource Locator)的超集，可以 對語義網上的對象和資源進行識別。
2.XML+命名空間
該層包括 XML Schema 和命名空間，它通過 XML(eXtensible Markup Language) 標記語言分離了網絡資源的結構、內容和數據表示，從而可以和其它基于 XML 標 準實現無縫集成。
3.RDF+RDFS 層
RDF 是語義網用于描述 Web 資源的基本數據模型。 RDF 數據模型遵循 XML 語法但不依賴于XMLoRDFS(RDF Schema)使用建模原語將Web對象組織成層次結 構，包括類、屬性、 domain 和 rang 約束等。
4.本體層
該層采用 OWL 表示并用于描述各資源之間的關系。本體表明了資源之間復雜 而豐富的語義信息，分離了信息的結構和內容，使信息完全形式化，從而使其具備 計算機可理解的語義。
5.邏輯層
該層是為智能推理提供公理和領域推理規則，從而允許在特定領域和應用中創 建描述性知識，使本體語言的表達能力進一步增強。
1.3.2語義網技術與設備信息管理系統
隨著知識經濟的發展，人們對于信息的需求發生了根本性的變化，開始從信息 需求向知識需求轉變，使信息處理朝著資源系統化組織和提煉知識的方向發展。由 于工業 4.0 的發展以及更多智能設備的引入，企業對設備信息管理系統提出了更高 的要求，開發基于語義的設備信息管理系統成為了大勢所趨。
基于語義的設備信息管理系統是一種特定的設備知識管理系統，它以描述、提 取、存儲、查詢和分析設備管理領域大量語義實體及實體間關系為目的。該系統分
為語義描述、語義提取、語義存儲、語義查詢及分析和語義輸出五大子系統。該系 統軟件層次如圖 1.2 所示，最下層是與硬件緊密聯系的操作系統和標準軟件；中間 層為系統基礎軟件層，主要實現語義信息提取、描述、存儲、查詢、組合和顯示等 基本功能；最上層為系統高級應用軟件層，包括基于語義的信息檢索系統、基于語 義的信息管理系統等。
1.4論文研究工作概述
1.4.1目前存在主要問題
設備管理自動化的推廣實施和物聯網技術的發展為工業物聯網設備信息管理體 系的建設奠定了基礎，但在工業物聯網設備信息管理中仍然面臨以下問題：
1.設備信息存在孤島，缺乏統一定義。工業設備種類多，數據量大、數據存儲 與分布存在異構。現階段基于異構數據庫的解決方案雖能夠對異構數據源進行有效 集成，但卻造成了數據冗余，且缺乏標準化統一的數據描述，信息組織與管理復雜 度高，信息共享程度低。
2.設備狀態監測實時性不強。中國大多數企業，特別是一些中小企業，仍然手 工處理數據，使用紙張傳遞管理、維護等相關指令，實時性欠缺，設備狀態不能及 時反饋，上級管理人員無法立即獲得相應的提示和告警信息，進而影響企業決策的 及時性。
3.設備異常及維護智能化程度不高。目前，設備管理系統缺乏完善的預防性和 預測性維護，采用事后維護方式，大大增加了故障停機時間，而且大部分設備維護 依賴于維護人員的經驗，不可避免地造成人為原因的錯誤維護。此外，設備異常維 護的策略知識是動態更新的，但是計算機并不理解設備異常的數據含義，導致了知 識重用性不高，智能化程度低。
1.4.2研究工作及創新點
前文分析了目前工業設備信息管理領域存在的問題，根據實驗室課題要求，本 文主要研究語義網技術與OPC UA技術在工業設備信息管理中的應用。在調研國內 外研究現狀和對相關技術研究的基礎上，將語義網技術引入到工業設備信息管理領 域，并結合 OPC UA 技術，實現工業設備狀態的實時監測、設備信息語義化描述、 設備信息有效組織及管理、設備異常及維修策略提供等功能。課題所做的具體研究 工作內容如下：
1.OPC UA應用研究。使用OPC UA集成系統，為工業設備信息管理系統提供 設備狀態的實時監測，并為設備故障診斷、維護、語義化描述等提供數據支撐。
2.領域知識本體建模研究。將本體技術引入設備管理領域，對工業設備信息提 供標準化統一描述，實現設備數據的有效組織和信息共享，降低設備數據的管理難 度。
3.設備數據實例映射研究。使用 RDF 圖模型來描述設備數據，并利用本體對 設備信息進行語義擴展。同時使用AllegroGraph圖形數據庫存儲RDF數據，存儲量 可達數十億，同時還保持卓越的性能。
4.語義信息查詢研究。提出一種基于AllegroGraph的語義查詢機制，通過語義 匹配可使查準率和查全率相比基于關鍵詞的語法信息查詢有顯著提高。
5.策略知識提供研究。應用規則推理與策略知識本體，對設備運行過程中產生 的異常及維修提供相應的策略，實現知識重用。
6.驗證系統搭建與測試。結合B/S(Browser/Server)模式設計了基于語義的工業 設備信息管理系統架構，基于該系統對工業設備信息管理模塊進行功能性測試，同 時驗證相關技術應用的有效性。
基于以上工作內容，本文的主要創新點如下：
1.將語義網技術引入到工業設備信息管理領域，并結合OPC UA技術，實現基 于OPC UA集成的設備狀態信息實時監測及實時數據提供和基于本體的設備信息管 理，改變傳統基于關系型數據庫的信息組織和管理方式。
2.提出基于Prolog+Lisp的規則推理應用方法，利用RDF Prolog和Lisp語言描 述設備異常及維護過程的規則，利用設備狀態實時語義數據，并結合策略知識本體 中已有的知識，推理出設備可能存在的異常及故障原因，提高設備管理的智能性。
1.5論文組織結構
本文根據工業設備管理領域的需求，結合語義網技術、OPC UA技術和B/S模 式，對基于語義的工業設備信息管理系統進行設計與實現。論文一共分為六章，其 組織結構如圖 1.3所示。
圖 1.3 論文組織結構
論文中每章的主要內容如下：
第 1 章，緒論。本章主要介紹課題研究的背景和意義，分析國內外語義網技術 和設備管理的研究現狀，闡述論文所做的主要研究工作和創新點。
第2章，基于語義的工業設備信息管理系統分析。本章主要對課題研究的系統 進行可行性分析，同時對系統的功能、開發工具、OPC UA技術應用、數據庫等進 行需求分析。
第 3 章，工業設備信息管理中知識本體的構建研究與實現。本章介紹工業設備 管理領域知識本體的構建過程，主要包括本體模型構建、設備數據實例映射以及本 體一致性檢測。
第 4 章，基于語義的工業設備信息管理系統模塊設計與實現。本章介紹基于語 義的工業設備信息管理模塊的開發方法及設計過程，主要包括系統管理、設備狀態 實時監測、設備信息管理、設備信息語義查詢和策略知識提供等。
第 5 章，測試驗證及分析。本章結合 B/S 模式搭建基于語義的工業設備信息管 理系統，基于該系統對工業設備信息管理模塊進行功能性測試，同時驗證相關技術 應用的有效性。
第 6 章，總結與展望。本章主要對論文研究工作進行總結，并對未來的研究方 向和工作內容進行展望。
1.6本章小結
本章首先介紹了語義網技術和設備管理兩者存在的研究背景以及語義網技術與 OPC UA技術在工業設備管理領域的研究意義；其次分析總結了兩者在國內外的研 究現狀，并概述了兩者之間的聯系；然后針對工業設備信息管理過程中存在的問題 引出課題的研究內容；最后闡述了論文各章的主要研究內容和組織結構。
第 2 章 基于語義的工業設備信息管理系統分析
本章對基于語義網技術和OPC UA技術實現的工業設備信息管理系統進行可行 性分析，并在實驗室已有的軟硬件條件支持下，結合工業物聯網應用場景，對系統 的模塊功能、開發環境、開發工具、OPC UA技術應用和數據庫等進行需求分析。
2.1系統可行性分析
隨著計算機技術的迅速發展，設備管理方法也日新月異，傳統的設備管理方法 人工記錄檔案、維修信息等，不僅費時費力，而且效率低，設備信息無法及時有效 更新，并且查詢和審查不方便；設備信息存在孤島，缺乏統一定義，信息組織與管 理復雜度高，信息共享程度低；設備狀態監測實時性不強，上級管理人員無法立即 獲得相應的提示和告警信息，進而影響決策的及時性；設備異常及維護智能化程度 不高；在數據存儲時，針對關系型數據庫構建大量的關系表來管理多對象關系，構 建繁瑣且降低數據庫的實際利用率。本文結合實驗室OPC UA技術研究成果和語義 網技術開發資源，對工業設備信息管理系統開發進行可行性分析：
技術可行性：針對現階段設備信息管理存在的問題，本文以OPC UA集成的底 層異構網絡設備為基礎，利用基于Java的OPC UA SDK(Software Development Kit) 開發工業設備狀態實時監測，并將實時數據進行語義化描述，為后續設備異常報警 及維修提醒提供數據支撐；以RDF圖模型的AllegroGraph圖形數據庫為基礎，構建 設備及其周邊對象關系的 RDF 數據并存儲；以 TopBraid Composer 企業級大師版為 本體編輯工具，構建設備信息管理領域相關的知識本體；以AllegroGraph數據庫支 持的RDF Prolog和Lisp語言描述領域規則，進行規則推理及查詢；結合B/S模式， 基于Java語言和前端技術開發遠程設備信息管理系統。
經濟可行性：基于 B/S 模式的工業設備信息管理系統能夠提高設備管理效率， 只要有瀏覽器就可以對設備進行遠程監測、故障診斷和信息管理等，減少人為參與 度，降低設備管理成本和因設備長時間故障引起的生產停滯損失。
操作可行性：使用該系統可以減少管理人員的工作內容，節省大量的人力和物 力，大大提高工作效率、準確性和精確性，使設備信息管理更加規范化和系統化。
易用性：該管理平臺將一些專業的術語和操作封裝成服務進行屏蔽，并開發了 相應的后端REST(Representational State Transfer)訪問接口，通過Web方式發布到應 用服務器上。因此，即使是非專業的管理人員不管是在辦公室還是在家，只需通過 瀏覽器就可以訪問該管理系統進行相應的管理工作。
綜合上述分析，將語義網技術和OPC UA技術引入設備信息管理領域是可行的, 在實驗室研究基礎上，可以對其進行實現。
2.2系統需求分析
2.2.1系統功能需求分析
通過上文對工業設備信息管理系統的可行性分析，結合實驗室相關課題研究， 需完成以下基本任務和實現目標，即利用實驗室現有的軟硬件資源，搭建基于語義 的工業設備信息管理系統。在此系統上，利用OPC UA技術開發底層異構網絡的設 備狀態信息獲取端，實現工業設備狀態信息實時監測；利用RDF圖模型對設備的靜 態信息和生產過程中的動態信息進行語義化描述，并通過本體模型進行語義擴展， 實現設備信息的機器可理解；利用 TopBraid Composer 本體編輯工具建立工業設備 信息管理領域的知識本體，實現設備信息的有效組織和管理；利用 AllegroGraph 圖 形數據庫的優越存儲性能，存儲設備相關的RDF數據；利用AllegroGraph數據庫支 持的語義查詢機制，開發設備信息管理的語義查詢，實現設備異構數據的有效查詢， 提高設備信息的查全率和查準率；利用支持AllegroGraph數據庫的RDF Prolog和 Lisp語言描述領域規則，進行規則推理和查詢，實現工業設備異常及維修策略提供。
工業設備信息管理模塊功能分為系統管理、設備實時監測、設備信息管理和設 備異常及維修策略提供四大部分，具體的模塊功能如下：
1.系統管理：對用戶登錄驗證、用戶信息修改、登錄注銷及操作權限進行管理。
2.設備狀態實時監測：對現場工業設備生產過程中的設備狀態信息進行實時監 測，為遠程故障診斷用戶提供設備狀態實時數據，也為上層管理人員的決策提供數 據支撐。
3.設備信息管理：包括設備臺賬管理、操作人員管理和設備維修管理三大模塊， 實現對設備、人員相關信息的添加、修改、刪除和查詢等操作。
4. 設備異常及維修策略提供：包括設備異常報警、異常策略提供、設備維修提 醒和維修策略提供四大模塊，實現設備在生產過程中狀態自動判定及預警，并提供 不同情況的相應策略知識，供設備管理人員參考借鑒，避免人為的錯誤管理。
此外，根據設備管理需求，設計和實現設備異常、維修、管理等操作時的日志 記錄，完成對相關重要操作的備份記錄，減少系統管理者的工作內容，提高工作效 率，為后續系統的更新和維護提供歷史數據保障。
2.2.2開發環境及工具需求分析
根據基于語義的工業設備信息管理系統設計要求和實現環境，結合實驗室軟硬 件資源，本文使用Java語言作為系統開發語言，對系統開發的環境及工具進行分析：
J2EE： J2EE(Java 2 Enterprise Edition)是一套企業應用程序架構，使用可靠、穩 定和安全的中間層來滿足用戶開發需求［18］。該體系結構［19］具有如下特點：(1) 平臺 設計的軟件具有良好的兼容性； (2) 平臺易于開發，集成了豐富的庫文件，大大減 少了系統設計的工作量，提高了程序開發效率。
JSP： JSP(Java Server Pages)主要用于動態頁面開發，將界面設計和功能設計分 離開來，有利于系統的開發和后期維護〔"I。該技術具有如下特點：(1) JSP可以和其 它動態網頁技術相結合； (2) 使軟件開發工作和后期測試工作更容易。
Spring MVC： Spring MVC(Model-View-Controller)框架是一種 Web 開發框架， 通過模型-視圖-控制器較好地將數據、業務和顯示進行分離，使編寫的代碼更有規 范性，增強可讀性［21］。該框架具有如下特點：(1) 合理化網站程序的物理結構； (2) 較 好地維護、復用代碼。
Ajax： Ajax(Asynchronous JavaScript And XML)是一種網頁開發技術，用于創建 交互式 Web 應用［22］。它結合了 JavaScript、 XML、 DOM 等多種技術，通過前端提 交Ajax請求，將請求傳遞給后臺，進而與服務器交互，調用數據庫數據實現前端界 面更新。 Ajax 使網頁實現異步更新，在不刷新整個界面的前提下，對網頁局部界面 進行更新。
B/S模式：B/S模式是基于WWW(World Wide Web)瀏覽器技術，并結合瀏覽器 的多種腳本語言開發的一種基于Web技術的系統平臺模式［23］。該模式具有如下特點:
(1)保證數據的安全、一致、實時以及服務器響應的及時性等； (2) 對用戶技術和前 端機配置要求低，用戶界面豐富，客戶端系統易于維護。
2.3OPC UA 技術應用需求分析
隨著信息技術的高速發展，工業設備信息管理系統朝著自動化和智能化的方向 發展［24］。在傳統的工業生產過程中，現場設備的實時信息跟生產環境的實時信息是 至關重要的，它關系著生產過程中產品的狀態、設備的狀態、環境的狀態。這些都 需要人為地進行監控，不僅加大了生產投入成本，對實時的能耗也沒有過多的評估， 沒能作出及時的調整，而且也不利于企業以后的發展。
為了較好地適應市場的快速變化，工業廠商對底層現場設備的數據越來越重視。 但是，在數據交換過程中缺乏互操作性，工廠級別的各種設備之間缺乏統一的標準 接口。同時也由于軟件和硬件之間的異構性，從而形成系統信息和用戶之間的“信 息孤島”，工業企業急需先進技術來集成一個個的信息孤島［25, 26］。因此，在 2006 年OPC基金會發布了 OPC UA規范。OPC UA是一個巨大的進步，和傳統的OPC DA 相比， OPC UA 為所有現有的基于 COM 的規范建立了一個沒有損失任何功能和性 能的替代品，同時，還能夠描述復雜系統的豐富和可擴展的建模能力，以及滿足平 臺獨立的系統接口的所有需求。
本文將語義網技術引入到工業設備信息管理領域，并結合OPC UA技術在底層 現場設備集成方面的優勢，設計開發工業設備信息的動態管理系統。文章是在OPC UA 服務器的基礎上進行設計開發工業設備信息管理系統，在該系統中，設備狀態 信息實時采集是核心業務模塊，通過實時采集各種工業設備的狀態信息可為設備故 障診斷、設備維護提醒、設備報警和維修策略提供等應用提供數據支撐。該模塊通 過OPC UA技術實現設備狀態信息的實時采集和更新，進而實現動態管理設備臺賬 信息、操作人員信息、維修和維護等業務環節。
2.4數據庫需求分析
關系數據庫是應用最廣泛的數據庫技術。但是，隨著數據規模的擴大和數據復 雜性的增加，關系數據庫開始暴露出其局限性，不能很好地支持多層復雜查詢，也 不能滿足領域需求。鑒于數據之間內部關系的復雜和動態變化，人們開始關注圖形 數據庫，它可以有效地存儲、管理、更新數據及其內部關系，并有效地執行多層復 雜操作［27, 28］。
在工業設備信息管理系統中，由于設備生產過程數據間關系錯綜復雜，需要更 加快速有效的存儲方法去更好地訪問和處理工業設備的數據屬性。本體的語義存儲 是基于圖模型的 RDF 存儲和管理，目前主要存在兩種 RDF 存儲方式：基于關系模 型的RDF存儲和基于圖模型的RDF存儲，本文采用AllegroGraph圖形數據庫存儲 語義數據，其數據屬性存儲方式是基于圖模型的RDF存儲。AllegroGraph不僅是一 款語義圖形數據庫，還是一個用于構建語義 Web 應用的應用框架［29］，其軟件架構如 圖 2.1 所示。該數據庫具有如下特點：(1) 將數據和元數據存儲為 RDF 三元組，通 過各種查詢 API(Application Program Interface)查詢，女口 SPARQL 和 Prolog； (2)擁 有高效的數據存儲方式，并且其存儲容量可達數十億；(3) AllegroGraph基于REST 通訊協議支持多種客戶端，包括RDF4J、Java Sesame/Jena、Python和Lisp等；(4) AllegroGraph符合W3C/ISO標準，可直接從眾多客戶端應用程序中支持SPARQL 1.1、 RDFS++、SPIN 和 Prolog 規則/推理。
Java:Sesame/Jena Python C# Ruby CloJure/Scala Lisp Perl
Backup/Restore Replication Warm Failover Security Management REST
Rules:SPIN, Stored Procs
SPARQL Prolog, CLIF++ Geo SNA Time RDFS++ (Javascript,Lisp)
Session Management, Query Engine, Federation
Storage Layei(Compression,Indexing,Freetext,Transactions)
圖 2.1 AllegroGraph 軟件架構
2.5本章小結
本章首先對即將實現的工業設備信息管理系統在技術應用、經濟性、易用性等 方面進行了可行性分析；然后在實驗室已有的語義開發資源和OPC UA研究成果的 基礎上，分析了基于語義的工業設備信息管理系統的功能模塊需求、開發環境需求、 開發工具需求、OPC UA技術應用需求和數據庫需求。
第 3 章 工業設備信息管理中知識本體的構建研究與實現
本章針對工業設備信息管理應用構建有效的設備管理領域知識本體，分別從本 體建模(包括本體建模準則、本體建模方法、本體建模實現)、本體實例映射(包 括設備靜態信息實例映射、設備動態信息實例映射)、本體一致性檢測(包括檢測 依據、檢測方法、檢測實現)三方面介紹本體構建過程。
3.1本體建模
本體在語義網層次結構中位于核心位置，能夠描述類、實例以及它們的屬性是 如何定義、描述和關聯的。本體不僅是語義網中數據的語義信息載體，還是語義網 中領域知識規范化和形式化的重要途徑。數據通過一種通用本體語言上升為知識， 可以更好地被共享和重用，充分發揮以數據為中心的智能化潛力。
設備管理領域中信息本體的建模、形式化表示和語義描述是基于語義知識模型 的設備信息資源管理的基石。在工業設備信息管理中，設備相關信息存在分布異構、 邏輯表現形式異構、語義異構三方面的異構性，因此，需構建設備管理領域知識本 體模型，利用該模型對設備相關信息進行標準化統一描述，消除設備信息間存在的 異構性，同時使設備數據具備計算機可以理解的語義，提高設備管理系統的智能性， 從而有利于上層用戶對設備數據的有效組織和管理。
3.1.1本體建模準則
本體建模領域的研究人員提出了一系列構建本體的標準，其中最有影響力的是
Gruber在1995年提出的五條本體構建準則［30］：
(1)明確性和客觀性。本體通過自然語言為定義的術語提供清晰客觀的語義定 義，并在用邏輯公理表示定義時將其形式化。
(2)完全性。所給出的定義是完整的，充分表達了該術語的含義。
(3)一致性。從該術語派生出的推論與該術語本身的含義一致，不產生矛盾，
并且定義的公理與自然語言中描述的文檔一致。
(4)最大單調可擴展性。在向本體添加通用或專用術語時，請勿修改其現有的 概念定義和內容。
(5) 最小承諾和最小編碼偏好。本體約定應該最小化，要建模的對象應該提供 盡可能少的約束，并且因為實際系統可以使用不同的知識表示，所以概念的描述不 應該依賴于特定符號層的表示。
3.1.2本體建模方法
現階段領域本體的建模方法分為三類［31］：手工建模法、半自動建模法和自動建 模法。目前，國內外研究者為提高本體構建效率，降低本體構建開銷，在自動建模 和半自動建模方向上研究比較活躍，并將該研究稱為本體學習，其目標是利用機器 學習、自然語言規則、統計學等相關技術自動或半自動地從已有的數據源中獲取期 望的本體模型。但是，自動建模和半自動建模方法的研究還處于早期階段，目前還 沒有成熟的方法論指導，并且技術需求較大。因此，目前領域本體的構建仍以比較 成熟的手工建模法為主。
已有本體
圖 3.1 領域本體構建流程
目前為止，本體工程中手工構建領域本體的方法按成熟度由高到低依次為：七
步法、Methontology方法、IDEF-5法、TOVE法、骨架法。七步法是一種理論成熟
度較高的通用方法，對領域本體的構建具有重要的參考意義。斯坦福大學醫學院開 發的“七步法”定義了領域本體構建的一般流程，主要包含確定范圍、考慮重用、 列舉術語、定義類、定義屬性、定義約束和創建實例七個步驟。本文擬采用李恒杰 等人［32］提出的領域本體構建方法進行本體建模，該方法是參考“七步法”，并結合 骨架法的評價部分提出的一種領域本體構建方法，如圖 3.1 所示。該方法在“七步 法”的基礎上加入了本體評價，利用本體評價標準準確檢驗本體，使本體盡可能滿 足完善性、清晰性、可擴展性和一致性。
3.1.3本體建模實現
本文基于課題實際應用需求，采用上文給出的領域本體構建方法作為設備信息 管理領域知識本體的建模方法，并遵循Gruber于1995年提出的五條建模準則，同 時選擇實驗室現有的美國TopQuadrant公司開發的TopBraid Composer企業級大師版 作為本體編輯工具。
上文的領域本體構建方法給出了領域本體構建的基本流程，使用該方法構建設 備信息管理領域知識本體的具體實現流程如下所示：
1. 確定范圍
確定本體構建的專業領域、應用目的以及系統開發、維護和應用對象。本文構 建的本體應用于設備信息管理領域，要求能夠通過設備信息管理領域的知識本體對 設備相關信息進行標準化統一描述，從而對信息資源進行有效組織和管理，并通過 語義推理與查詢提高設備管理的智能化程度。
2.考慮重用
隨著語義網的廣泛部署，在社交網絡、地理、醫學等公共領域，許多本體已經 可用。現階段已經存在各式各樣的本體，如本體庫、專家知識的編纂、上層本體、 百科知識、集成詞匯表等。但是，在工業設備管理領域，并沒有可以借鑒的領域本 體進行重用，因此本文將略過這一步直接進行下面步驟的開發。
3.列舉術語
盡可能列出該領域想要陳述或向用戶解釋的所有相關術語。通常，名詞構成類 名的基礎，而動詞或動詞短語構成屬性名的基礎。本體是 RDF 圖模型的關系集合， E-R(Entity-Realtion Model)模型又是RDF模型的基礎之一，許多E-R建模概念都可 以直接移植到RDF模型中I6】，因此本文采用E-R模型來表示設備管理領域的實體、 實體間聯系和屬性，為后續領域本體的類、屬性等的定義奠定基礎。以OPC UA服 務器中的 AirConditioner 設備為例構建 E-R 模型，如圖 3.2 所示，圖中列舉出 AirConditioner設備相關的實體、聯系和屬性，分別對應本體中的類概念、概念間關 系和屬性。
4.定義領域本體中的類、屬性、約束和實例
(1)定義類
在列舉相關領域術語后，術語必須被組織成一個分類層次。目前，有三種方法 可以定義術語的分類層次結構：1) 自頂而下法：首先定義該領域的綜合概念，然后 逐步完善和解釋； 2) 自底向上法：首先定義領域中具體和特定概念，然后將這些概 念歸納為綜合概念； 3) 綜合法：結合上述兩種方法，首先建立中端概念，然后分別 對其進行上下推廣和劃分。本文采用綜合法將上一步驟建立的E-R模型的實體定義 為類，并建立類的層次結構。以設備本體為例建立設備相關的類層次結構，使用 TopBraid Composer 本體編輯軟件對該本體的相關類層次結構進行可視化展示，如圖 3.3 所示。圖中定義 “People"、“Device"和 “MaintenanceRecords"等實體為設備 本體中公共父類(owl:Thing)的子類；定義“設備操作人員”、“設備維修人員”和 “生產產商”等實體為類“People”的子類；定義“AirConditioner”和“Furnace” 實體為類“Device"的子類；定義“維修信息記錄”實體為類“MaintenanceRecords” 的子類。
圖 3.3 設備本體模型類層次結構
(2)定義屬性 通過類不足以清晰地描述一個領域，需要進一步定義屬性來描述這個類的內部 結構。在將屬性和類進行關聯時，需要定義這些屬性的定義域和值域，以設備本體 為例定義類的相關屬性，如圖3.4所示。圖中定義屬性“hasType”、“使用設備溫 度"、"使用設備濕度”、"設備維修記錄”等為對象屬性(owl:ObjectProperty)；定 義屬性“設備ID”、“設備型號”、“維修人工號”、“產商名稱”等為數據屬性 (owl:DatatypeProperty)。
圖 3.4 設備本體模型屬性層次結構
(3)定義約束
在以上步驟結束之后，該本體模型只有RDF模式所提供的表達能力，沒有用到 OWL 中的任何原語，因此，本階段將定義約束來豐富之前定義的屬性。其中定義 屬性約束包括： 1) 基數：屬性應盡量指出它們是否允許或需要擁有特定數目的不同 值，如“至少 1 個值”、“最多 1 個值”等； 2) 需要的取值：借助某個屬性含有特 定的值來定義類，在OWL中可以利用owl:hasValue進行指定；3)關系特征：可以 定義屬性的關系特征，如等價性、不相交性和對稱性等。
(4)定義實例
為本體模型定義實例是一個獨立的步驟。本節的定義實例步驟屬于本體實例映 射，將在 3.2 節中進行具體介紹。
5.領域本體編碼、形式化
選擇適當的本體編輯工具和本體描述語言對領域本體進行編碼和形式化。此步 驟可以使領域本體模型自動執行邏輯推理和驗證，增強機器的可讀性。本文采用美 國TopQuadrant公司開發的TopBraid Composer企業級大師版作為本體編輯工具，同 時選擇 OWL2 作為本體描述語言，對設備信息管理領域的知識本體進行編碼、形式 化。
6.本體評價
通過本體評價標準來驗證本體是否符合要求，如果不符合要求，轉向步驟 4， 如此反復循環，直到所有結果檢驗均到達要求。此步驟允許本體盡可能清晰、一致、 完善和可擴展。本文選擇 Mariano 提出的參考模型標準［6］作為評價標準，具體包含： 1) 對知識工程的繼承，主要考慮傳統知識工程對相應方法的影響； 2) 詳細程度， 主要考慮方法所提出的行為或技術說明的程序； 3) 知識形式化工具，主要考慮用于 表示知識的形式化工具； 4) 構造本體的策略，考慮用于構建本體的策略； 5) 提取 概念的策略，包括從具體到抽象、從抽象到具體和從中端到具體和抽象三種方式； 6)生命周期，主要考慮生命周期是隱式的還是清晰的；7)與IEEE 1074-1995的區 別，主要分析該方法沒有涉及到哪些被提出的過程和行為； 8) 所使用的技術，主要 針對方法中的不同行為是否使用特定技術實現進行表示； 9) 使用該方法構建本體和 應用系統； 10) 協作和分布性能，表示不同地方的開發團隊協作構建本體的能力。
通過以上步驟，可以建立設備信息本體模型。同理，采用該方法可構建策略知 識本體，具體介紹如下所示：
1.設備信息本體模型
設備信息本體模型描述了設備臺賬信息、設備生產產商信息、設備操作人員信 息、設備維修人員信息、設備維修記錄信息和傳感器信息。其中設備臺賬信息包括 設備ID、設備名稱、設備大小和設備隨機資料ID等基本信息；設備生產產商信息 包括產商名稱、產商地址、產商電話和開戶銀行等基本信息；設備操作人員信息包
括人員工號、姓名、性別、家庭住址、所屬部門和操作權限等基本信息；設備維修 人員信息包括維修人ID、維修人姓名、性別和家庭住址等基本信息；設備維修記錄 信息包括維修序號、維修內容、維修日期、維修類型等基本信息；傳感器信息包括 傳感器ID、傳感器名稱、靈敏度、測量范圍等基本信息。設備信息本體模型如圖 3.5 所示。
圖 3.5 設備信息本體模型
2.策略知識本體
圖 3.6 策略知識本體
策略知識本體描述了設備異常和設備維修的策略知識，其中設備異常策略知識 包括溫度過高、溫度過低、濕度過大、濕度過小等策略知識；設備維修策略知識包 括制熱器維修、加濕器維修、其它部件維修等策略知識。策略知識本體是為上層管 理人員提供管理策略的基礎，因此，該策略知識本體必須不斷更新。策略知識本體 如圖 3.6 所示。
3.2本體實例映射
本體實例映射是通過本體模型分解的元數據與原始數據進行映射［33］，進而將原 始數據映射為本體實例，使其具備形式化語義。在工業設備信息管理中，設備信息 不僅存在描述設備的靜態信息，如：設備名稱、生產產家、設備尺寸等，還存在設 備生產過程中產生的動態信息，如：設備的溫濕度值、采集時間、采集狀態等。本 節主要介紹將工業設備的這兩種信息映射為設備本體模型的實例數據。
3.2.1設備靜態信息實例映射
在工業設備信息管理中，設備相關的靜態信息包括設備臺賬信息、設備操作人 員信息、設備生產產商信息、設備維修人員信息、設備維修信息等，按照邏輯表現 形式的不同將這些信息分為非結構化信息、半結構化信息和結構化信息，這些信息 以二維結構形式存在關系數據庫的關聯關系表中。表3.1~表3.8列出了設備相關的 靜態信息在關系型數據庫中的部分數據記錄。
表 3.1 設備靜態信息關聯表
ID 設備臺賬 操作人員 設備維修
1 表3.2 表3.5 表3.6
表 3.2 設備臺賬信息表
ID 設備基本信息 設備生產產商
1 表3.3 表3.4
表 3.3 設備基本信息表
ID 設備ID 設備名稱 設備型號 購買日期 •…
1 A 001 Airconditioner CLS-J 2016/8/19
2 F 001 Furnace RXF-R-100 2015/10/12
表 3.4 設備生產產商信息表
ID 產商名稱 產商地址 電話 開戶銀行 •…
1 迅億達機械公司 深圳市龍崗區 0755-84550022 中國建設銀行
2 日興發機械廠 深圳市寶安區 0755-27417789 中國工商銀行
表 3.5 操作人員信息表
ID 姓名 電話 所屬部門 操作權限 ???
1 張三 17783454592 生產部 設備操作2級
2 王五 15546231759 生產部 設備操作1級
表 3.6 設備維修信息表
ID 設備維修記錄 設備維修人員
1 表3.7 表3.8
表 3.7 設備維修記錄表
ID 維修設備ID 維修內容 維修類型 維修日期 •…
1 A 001 軸承打油 潤滑 2018/1/5
2 A 008 更換風葉 修理 2018 ⑶16
表 3.8 設備維修人員信息表
ID 維修人工號 姓名 電話 家庭住址 ???
1 P 001 趙信 13277865539 重慶市青年路
2 P 002 王航 14899367741 重慶市南坪路
在實例映射過程中，關系數據庫中的一個表可以稱為一個關系，表由一系列包 含表頭的列組成，這些列稱為屬性，表的每行稱為一個元組。基于這些映射術語， 將關系數據庫模式映射到RDFS或OWL，數據庫中的每個表被認為是一個類，每 個屬性認為是一個屬性，而每個元組被認為是一個實例。在進行映射時，通過在屬 性或表名前面添加一個命名空間為每個實體創建URI，然后將數據庫中的存儲記錄 轉換為 RDF。
設備靜態信息實例映射過程如圖 3.7 所示，首先通過設備信息庫獲取設備靜態 信息相關的概念數據、屬性數據和實例數據，同時利用設備本體模型分解類概念元 數據、屬性元數據和關系元數據；然后將這兩種形式的數據進行映射匹配，進而基 于RDF圖模型對設備信息庫中的原始數據進行語義描述;最后利用本體模型分解的 關系元數據對設備的靜態信息基于本體模型進行語義描述。
圖 3.7 設備靜態信息實例映射過程
使用關系型數據庫進行建模時會存在兩方面的缺點：一是由于各個事物彼此關 聯的關系非常復雜，需要建立一系列的關聯表來記錄彼此間關系，使關系型數據庫 的解決方案繁瑣易錯；其次，數據庫需要通過關聯表間接維護實體之間的關系，導 致數據庫執行效率低，并且無法更好地管理數據庫中的信息。本文將關系數據庫中 的設備信息轉換為 RDF 數據并存儲于 AllegroGraph 圖形數據庫，可以較好地解決以 上兩方面的問題，將表 3.1~表 3.8 中的第一條數據記錄映射到設備本體模型中，其 RDF 模型表示如圖 3.8 所示。
圖 3.8 設備相關的部分靜態數據 RDF 模型表示
3.2.2設備動態信息實例映射
在工業設備信息管理中，設備生產過程中產生的動態信息包括現場的監測數據、 設備自身運行狀態信息和環境信息等。本文結合實驗室OPC UA服務器的相關研究 成果，開發OPC UA客戶端應用程序來獲取設備生產過程的狀態信息，通過設備動 態信息實例映射將設備實時采集的狀態信息基于RDF模型進行語義描述，為設備信 息管理系統中的自動異常報警、維修提醒、策略知識提供等功能提供數據支撐。
設備動態信息實例映射過程如圖 3.9所示，該過程主要分為以下3個步驟：
1.設備動態信息獲取
OPC UA服務器將不同系統集成于地址空間中，地址空間的信息模型為其提供 相關設備節點的數據信息，在OPC UA客戶端應用程序開發中可根據具體應用需求 有針對性地獲取相關節點的實時數據及節點信息，為下一階段基于 RDF 模型描述提 供數據支撐。該步驟的OPC UA客戶端應用程序開發將在下一章進行介紹。
2.基于RDF圖模型的語義描述
RDF是以建模方式描述數據語義，并在語義層面上表達資源的屬性和關系信息。 OPC UA采用了基于語義的信息模型規則建模，因此OPC UA信息模型中的數據已 經有了語義范疇，這樣就可以減少數據不必要的預處理過程，只需要對語義數據格 式進行轉換。該步驟對獲取節點的實時數據及相關信息基于RDF模型進行語義描述。
語義描述是基于RDF模型對OPC UA服務器獲取的實時數據及相關信息進行 描述，來表達資源間屬性和關系信息。數據屬性越豐富，則數據的表達能力越強， 數據的使用價值也越大。本文定義了面向OPC UA的設備節點數據信息語義表示模 型(Data Information Semantic Representation, DISR)=(Server, Nodeld, DisplayName, DataType, Value, Time, StatusCode)，該模型描述了 OPC UA服務器中設備節點的動 態數據及其節點信息的語義，如圖 3.10所示，模型中的元素可根據具體應用需求有 針對性地表示。DISR模型中的元素分別表示為：
Server：表示該節點所在服務器，在連接多服務器情況下，它是系統服務器分 配的唯一標志，根據Server，可以確認系統中的唯 個服務器。
Nodeld：表示服務器地址空間中的節點ID號，它是系統節點分配的唯一標志， 根據NodeId，可以確認服務器地址空間中的唯一一個節點。
DisplayName：表示服務器地址空間中的節點名稱。
DataType：表示服務器地址空間中節點生成的數據類型。
Value：表示服務器地址空間中節點產生的數據值。
Time：表示服務器地址空間中節點產生數據的時間。
StatusCode：表示服務器地址空間中節點產生數據的狀態信息。
圖3.10 OPC UA服務器設備節點信息RDF描述
3.基于本體的語義擴展
語義擴展是基于領域本體的資源關系，在數據現有屬性的基礎之上，通過推理 推導出新的或者隱含的數據屬性，實現數據屬性的延伸。資源關系是基于某種特征 或某個因素的關聯關系［34］，主要包括:
簡單關系：表示資源間緊密程度的關聯關系； 邏輯關系：表示資源間因果推導順序的關聯關系； 關聯關系：表示資源值之間存在某種規律性的關聯關系； 時序關系：表示資源間在某段時間內是否一起發生的關聯關系； 依賴關系：表示資源間依附存在的關聯關系。
領域本體中包含了特定領域的概念詞匯和對數據屬性及屬性關系的集合，基于 本體的語義擴展流程如圖 3.11 所示，首先通過將領域本體模型的資源及關系信息與 語義化描述后的RDF語義數據資源進行關聯性分析比較，推理得到兩者之間存在的 某種資源關系；然后利用該資源關系通過推理引擎進行推理；最后推導出 DISR 模 型中缺乏的屬性信息，賦予 OPC UA 實時數據更豐富的概念屬性含義，實現 RDF 數據屬性的延伸。基于本體語義擴展后的 RDF 描述如圖 3.12 所示，圖中虛線框表 示本體資源存在的關系。
3.3本體一致性檢測
本體一致性是指本體是否遵循所有約束，一致性是指在本體描述的形式化定義 中不存在自相矛盾的現象［35］。一般來講，本體一致性主要分為語法一致性、語義一 致性和自定義規則一致性三個方面。本體是由TBox(Terminology Box)和 ABox(Assertion Box)兩部分組成，實現本體一致性檢測的核心是實現ABox 一致性 檢測［36］,其它檢測都可以轉換為ABox 一致性檢測。
3.3.1一致性檢測依據
本體中的公理是概念間關系約束的集合，包括領域知識的一些永真斷言，例如 概念間的等價、繼承和不相交等。 OWL 語言提供兩種公理集，分別是類公理集和 屬性公理集。
1. 類公理集
類公理集是本體中類公理的集合，類公理是描述類概念的必要或充分條件。類 通過owl:Class來斷言某個資源的類型，表3.9列出了常用OWL的部分類公理及其 語法、語義和公理說明。
表 3.9 OWL 類公理
語法 語義 公理說明
rdfs:subClassOf 子類 一個類描述的外延是另一個類描述外延的子集
owl:equivalentClass 等價類 一個類描述的外延和另一個類描述的外延相同
owl:disjointWith 不相交類 一個類描述的外延和另外一個類描述的外延沒有交集
注：類描述外延是指類關聯的實例集合。
2. 屬性公理集
屬性公理集是本體中屬性公理的集合，屬性公理定義了屬性的附加特征，本體 構建者能夠根據屬性與類及其它屬性如何關聯來指定屬性的額外特征。與類公理不 同，屬性公理僅僅聲明了一個屬性的存在。 OWL 有兩種常規類型的屬性分別為對 象屬性和數據屬性，表3.10列出了這兩種屬性類型的部分屬性公理及其語法、語義 和公理說明。
表 3.10 常用的部分屬性公理
屬性類型 語法 語義 公理說明
對象屬性 rdfs:Domain rdfs:Range owl:inverseOf owl: EquivalentObjectProperties owl:disjointProperties owl:propertyChainAxiom 定義域 值域
逆屬性 等價對象屬性 不相交屬性
屬性鏈 屬性聲明的主詞必須屬于類 描述的外延 屬性的值必須屬于類描述的 外延 聲明屬性間的 逆關系 聲明兩個對象屬性具有相同 的外延 聲明兩個屬性的外延 不相交
聲明兩個屬性的外延存在鏈 式關系
rdfs:Domain
rdfs:Range owl: EquivalentDataProperties 定義域 值域 等價數據屬性 屬性聲明的主詞必須屬于類 描述的外延
屬性的值必須屬于特定數據
數據屬性 范圍內的值 聲明兩個數據屬性具有相同 的外延
不相交屬性 聲明兩個屬性的外延
owl:disjointProperties 不相交
注：屬性外延是指屬性關聯的實例集合。
3.3.2一致性檢測方法
目前的本體一致性檢測是基于Tableau算法對本體中的TBox和ABox進行沖突 檢測，該算法可以實現概念的一致性檢測推理且復雜度較低。 OWL 本體的一致性 檢測已經得到了各種推理機的支持，如Racer、FaCT++、Pellet等。本文擬采用Pellet 和Jena推理機對上文所構建本體進行一致性檢測，其中Pellet推理機是基于Java開 發的開源產品，它是一個基于 Tableau 算法實現的描述邏輯推理機，可以檢驗本體 在語法和語義方面的一致性；Jena推理機是基于規則的推理，通過構建自定義規則 檢驗本體中的邏輯矛盾，同時還可以檢驗自定義規則的正確性。
本體一致性檢測主要包括語法一致性檢測、語義一致性檢測和自定義規則一致 性檢測三個方面。本文首先采用集成Pellet推理機Protege本體編輯軟件對本體的語 法一致性和語義一致性進行檢測，然后使用Jena推理機對自定義規則進行一致性檢 測。本體一致性檢測過程如圖3.13所示，將構建好的初始本體導入Protege中，經 本體解析后讀入Pellet推理機，Pellet推理機中的TBox推理模塊對本體中的概念集
合進行一致性檢測和分類完善， ABox 推理模塊對本體中的實例集合進行一致性檢 測和個體獲取，經過兩者推理后，Pellet推理機將一致性檢測信息返回給Protege； 語法和語義一致性檢測完后，通過編寫應用程序調用 Jena 推理機，通過 Jena 推理 模塊并結合本體模型數據對自定義規則進行一致性檢測，并返回檢測結果。
語法一致性與語義一致性檢測 自定義規則一致性檢測
圖 3.13 本體一致性檢測過程
3.3.3一致性檢測實現
考慮到Pellet推理機的集成、OWL2 DL的兼容、開源等優點，本節將采用斯坦 福大學開發的 Protege 3.4 版本的本體編輯軟件對上文構建的本體進行一致性檢測。 以工業設備信息管理中的知識本體——設備信息本體為例，本體語法一致性和語義 一致性檢測實現的具體過程為：
1.將構建及實例映射完成的設備信息本體導入Protege本體編輯軟件，導入后 如圖 3.14 所示。
• Metadata(device) OWLCIasses ■ Prope
ONTOLOGY BROWSER
For Project: • device
Ontologies 我乜弋園
:◎::Ontologyfhttp:畑時 yi.paper .ontology/device)
圖 3.14 本體導入 Protege 軟件
2.在Protege軟件的主菜單中選擇"Reasoning"選項，在下拉選擇中選擇"Pellet
1.5.2(direct)"作為一致性檢測的推理機，然后點擊“Check consistency..."開始進行 檢測，如圖 3.15 所示。
device Protege 3.4 (file:\C:\Users\Root\Desktop\device.ppg, OWL / RDF Files)
Reasoni ng Code Tools Wndow Collaboration Help
Eva
DIG Reasoner
由圖 3.16 可知，檢測結果沒有提示錯誤信息，證明設備信息本體的 TBox 和 ABox 具備一致性。本節只對本體語法和語義一致性進行檢測，對于自定義規則一 致性檢測將在下一章設備異常報警及維修提醒的規則推理中進行間接檢驗。
3.4 本章小結
本章介紹了工業設備信息管理中知識本體的構建過程。首先闡述了一種將七步 法和骨架法結合的領域本體構建方法，并以設備信息本體為例對該方法的整個構建 流程進行了詳細說明；然后介紹了設備靜態信息與動態信息映射為本體實例的方法； 最后對本體一致性檢測的相關內容進行介紹，并利用集成Pellet推理機的Protege軟 件對本體的語法一致性和語義一致性進行檢測。
第 4 章 基于語義的工業設備信息管理系統模塊設計與實現
本章將語義網技術應用于設備信息管理領域，有效解決了傳統工業設備管理 信息化方案存在的缺陷，充分滿足了企業對設備信息管理的需求，進而結合 OPC UA 技術應用，詳細闡述系統體系結構設計、軟件架構設計、功能模塊設計以及各 模塊功能的實現。
4.1系統整體結構設計
基于語義的工業設備信息管理系統使用了語義網技術和OPC UA技術，將語 義網技術應用于工業設備信息管理領域，不僅有效地解決了設備信息存在孤島， 缺乏統一定義、信息組織與管理復雜度高、信息共享程度低等問題，還可以使工 業設備信息具備計算機可理解的語義，提高工業設備知識的重用性和互操作性， 進而提高設備異常及維護的智能化程度；將OPC UA技術應用于工業設備信息管 理領域，有效地解決了傳統工業設備管理系統不能基于Internet進行實時數據采集 和更新的缺陷，充分滿足了企業對工業設備信息動態管理的需求。下面主要從系 統體系結構、軟件結構和功能模塊三方面對系統進行設計。
4.1.1系統體系結構設計
基于語義的工業設備信息管理系統部署結構如圖 4.1 所示，系統服務器包括工 業設備信息管理的各功能模塊,OPC UA服務器用來集成工業現場設備并獲取設備 運行的實時數據，企業內部人員可以通過局域網訪問系統服務器以及獲取工業設 備的實時數據。另外，故障診斷用戶和系統管理用戶還可以通過互聯網進行遠程 系統訪問，當設備發生故障、發出報警和維修提醒時，可以通過短信或電子郵件 通知設備管理人員，以便工業設備管理人員可以及時地掌握工業設備的運行狀態。 由于系統采用 B/S 架構，只要有瀏覽器的地方，不管是家里還是辦公室都可以訪 問該系統，無需安裝任何客戶端軟件，同時也使工業設備信息管理系統的部署和 維護成本大大降低。
圖 4.1 系統部署結構圖
4.1.2系統軟件結構設計
基于語義的工業設備信息管理系統軟件結構如圖 4.2所示，該結構的設計參考 了語義網技術體系和工業物聯網的分層模型，由底層到高層共分為五層，依次為 感知層、網絡層、語義層、服務層和應用層，下面分別對這五個層次進行介紹。
1.感知層：感知層包括底層不同地點、不同網絡、不同生產廠商的現場設備 與 OPC UA 服務器，可通過 OPC UA 服務器對底層現場設備進行集成并對設備運 行狀態信息進行實時采集、傳輸。其中，不同網絡包括現場總線網絡、 6LoWPAN 網絡、 802.15.4 網絡等。
2.網絡層：網絡層包括 OPC UA 訪問的各種網絡系統，包括：以太網、 LAN、 工業以太網等，將采集到的設備狀態信息經網絡層的各種網絡系統傳輸到上層。
3.語義層：語義層包括OPC UA設備狀態信息獲取端、設備信息管理領域知 識本體、設備信息語義化描述、語義推理和查詢、本體數據庫和推理規則文件。
其中，OPC UA設備狀態信息獲取端是對工業現場設備的運行狀態信息進行實時獲 取，為下一步設備信息本體實例映射提供實時數據；設備信息管理領域知識本體 包括設備本體和策略知識本體，是設備信息管理領域共享概念模型的形式化規范 說明；設備信息語義化描述是將OPC UA設備狀態信息獲取端獲取的實時狀態信 息轉換為RDF語義數據，再通過設備本體將語義數據屬性進行擴展；語義推理和 查詢用于處理應用層的查詢和推理請求；本體數據庫用于存放工業設備相關的本 體模型和語義數據；推理規則文件用于存放與設備管理應用所需推理的相關規則。
設備實時監測及異常報警 設備異常報警及維修策略提供
工業設備信息管理服務組合應用
（設備實時監測） （設備臺賬管理） （設備維修管理）
（設備異常報警） （操作人員管理） （知識策略提供）
設備信息語義化描述
取數據信息
設備狀態信息獲取端
OPC UA通信棧
圖 4.2 系統軟件結構圖
4.服務層：服務層將基于語義的工業設備信息管理功能模塊應用封裝成服務， 以降低軟件架構的耦合度，主要包括設備狀態實時監測服務、設備異常報警服務、 設備臺賬管理服務、操作人員管理服務、設備維修管理服務和知識策略提供服務。
5.應用層：應用層是人機交互的橋梁，主要為工業設備信息管理用戶提供各 應用模塊，在該系統中應用層就是系統的瀏覽器操作界面。
4.1.3系統功能模塊設計
根據基于語義的工業設備信息管理系統的分析，將系統從功能上劃分為系統 管理、設備監測及異常報警、設備臺賬管理、操作人員管理和設備維修管理五大 功能模塊，如圖 4.3 所示。系統中的各個功能模塊相對獨立，不僅能夠完成其指定 的功能，還能通過圖形數據庫中的語義數據信息將各功能模塊緊密聯系在一起， 構成完整的工業設備信息管理系統。
用戶登錄
系統管理 用戶修改
注銷登錄
設備運行狀態監測
設備監測及異常報警 設備異常報警
設備報警策略提供
臺賬信息實例映射
基于語義的工業設備 信息管理系統 設備臺賬管理 設備屬性管理
臺賬信息語義查詢
人員信息實例映射
操作人員管理 人員屬性管理
人員信息語義查詢 維修信息實例映射
設備維修管理 維修提醒及策略提供
歷史信息語義查詢
圖 4.3 基于語義的工業設備信息管理系統功能結構圖
下面對基于語義的工業設備信息管理系統功能結構圖中的五大功能模塊進行 介紹：
1.系統管理模塊
系統管理模塊主要包括用戶登錄、用戶信息修改和登錄注銷三個子模塊，用 戶登錄子模塊的主要功能是完成對用戶登錄信息的驗證，驗證成功后進入系統操 作界面，驗證失敗后提示用戶登錄信息錯誤；用戶信息修改子模塊的主要功能是 修改用戶的登錄信息，包括登錄用戶名、密碼等；登錄注銷子模塊的主要功能是 安全退出系統操作界面，注銷后返回登錄界面。
2.設備監測及異常報警模塊
設備監測及異常報警模塊主要包括設備狀態實時監測、設備異常報警、設備 報警策略提供。設備狀態實時監測主要是對工業現場設備在線運行狀態數據進行 實時采集并在界面進行顯示；設備異常報警主要是通過設備狀態信息判斷當前設 備運行是否正常，如有不正常情況出現，發出報警或者用短信通知用戶；設備報 警策略提供主要是將采集的設備狀態信息進行語義化描述，并通過結合設備管理 領域知識本體制定相關推理規則，在設備異常報警的同時提供設備故障可能存在 的原因。
3.設備臺賬管理模塊
設備臺賬管理模塊主要包括設備基本信息實例映射、設備屬性及語義數據管 理、設備臺賬信息語義查詢等。設備基本信息實例映射主要利用設備基本信息對 設備本體模型進行實例化，以滿足設備基本信息的有效管理和使用需求；設備屬 性及語義數據管理主要是對設備本體中的屬性和實例數據進行增加、刪除和修改； 設備臺賬信息語義查詢主要是對設備語義化信息進行查詢。
4.操作人員管理模塊
操作人員管理模塊主要包括設備操作人員信息實例映射、人員屬性及語義數 據管理、操作人員信息語義查詢等。設備操作人員信息實例映射主要利用人員基 本信息對操作人員本體模型進行實例化，以滿足操作人員基本信息的有效管理和 使用需求；人員屬性及語義數據管理主要是對操作人員本體中的屬性和實例數據 進行增加、刪除和修改；操作人員信息語義查詢主要是對操作人員語義化信息進 行查詢。
5.設備維修管理模塊
設備維修管理模塊主要包括設備維修信息實例映射、設備維修提醒及維修策 略提供、設備維修歷史數據語義查詢等。設備維修信息實例映射主要利用設備維 修記錄信息對設備維修記錄本體模型進行實例化，以滿足操作人員基本信息的有 效管理和使用需求；設備維修提醒及維修策略提供主要是利用設備動態語義化數 據，結合設備維修判定規則，進行規則推理，如果推理出設備需要維修，發出維 修提醒并提供設備維修策略；設備維修歷史數據語義查詢主要是對設備維修歷史 語義信息記錄進行查詢。
4.2系統功能模塊實現
依據前述基于語義的工業設備信息管理系統的功能模塊劃分，本節將對系統 管理模塊、設備狀態實時監測模塊、設備語義信息管理模塊、設備語義信息查詢 模塊和設備異常報警及維修策略知識提供模塊進行實現。
4.2.1系統管理模塊實現
本模塊在語義建模的基礎之上實現工業設備信息管理系統的用戶注冊登記、 登錄驗證、信息更新等功能，下面主要對這三個功能的實現進行介紹。
1. 用戶注冊登記
該系統的用戶分為普通用戶和管理者用戶，用戶注冊登記的信息屬性包括： 用戶名、密碼、性別、家庭住址、電話、郵箱等。使用 TopBraid Composer 構建的 用戶信息圖形化展示如圖 4.4 所示。
2. 登錄驗證
該部分通過Web訪問，提供用戶名和密碼兩個輸入框以及登錄執行按鈕。當 系統用戶輸入個人信息后，系統進行登錄信息預處理，然后與 AllegroGraph 圖形 數據庫中預存的用戶信息進行匹配，執行驗證。當驗證成功后，跳轉至工業設備 信息管理系統操作界面；當驗證失敗后，彈出密碼或用戶名匹配失敗的錯誤提示 框。登錄驗證流程如圖 4.5 所示。
圖 4.5 登錄驗證流程圖
3. 信息更新
該部分可根據 SPARQL 查詢語言規范，用戶的每個屬性信息對應一條三元組 聲明，當需要更新用戶的某個屬性時，首先需要在圖形數據庫中定位包含該屬性 的三元組，其次刪除該屬性聲明，最后對該三元組中的屬性-屬性值進行修改。例 如更新“device:普通用戶」”這一用戶的電話屬性值，使用SPARQL語句如下所 示：
PREFIX device:<http://wenyi.paper.ontology/device#>
PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
DELETE
{
device :普通用戶」device:電話？a.
INSERT
{
device :普通用戶」device:電話 “18630415568”"^40伍隔.
}
WHERE
{
device:普通用戶」device:電話？a.
}
其中，PREFIX定義了 SPARQL查詢語言中所用到的URI前綴縮寫，WHERE 定位需要更新屬性的三元組，DELETE用于刪除WHERE中三元組的屬性及其屬 性值，INSERT為定位的三元組添加新的屬性及其屬性值。刪除操作和上述方法類 似，只需執行 DELETE 操作即可。
4.2.2設備狀態實時監測模塊實現
本模塊主要是基于 OPC UA 技術實現工業設備狀態信息的實時采集，并為其
它模塊提供設備的實時數據。OPC UA是OPC基金會創造的一個新標準，它是基 于客戶端和服務器體系結構，如圖 4.6 所示，其中服務器用于存儲以面向對象方式 建模的數據，并定義了一個具有兩個基本元素的元模型，即：節點和參考。參考 互聯節點和跨越網絡在OPC UA架構中稱為地址空間。
本論文對工業設備狀態實時監測模塊開發的軟件架構如圖4.7所示，其中 OPC
UA服務器采用德國Unified Automation公司提供的基于C/C++的OPC UA演示服 務器，如圖4.8所示。該服務器適用于 Windows 操作系統，提供了信息模型和模 擬數據;設備狀態信息獲取端的開發采用該公司提供的基于Java的OPC UA SDK, 利用該軟件開發工具包不僅實現了客戶端應用程序與 UA 通信棧之間的通信，還 有效地減少了 UA應用程序的開發工作。
設備狀態信息獲取端 ' J a
OPC UA通信棧 V a
V 丿
網絡系統
OPC UA通信棧 X. 丿
Z 、
OPC UA服務器
< 丿
圖 4.7 工業設備狀態實時監測模塊開發軟件架構
圖 4.8 OPC UA 演示服務器
工業設備狀態信息實時采集的應用程序開發流程如圖 4.9 所示,首先進行初始 化,連接OPC UA服務器，連接成功后設置NodeID，獲取節點引用并瀏覽地址空 間；其次創建不同設備型號所需的監控項目，并綁定OPC UA地址空間中的具體 數據項節點;然后選擇相關節點的屬性進行訂閱，設置數據采集的時間、死區值
等；最后當訂閱的屬性值發生變化后進行設備狀態信息打印輸出和語義化描述。
圖 4.9 工業設備狀態信息實時采集開發流程圖
4.2.3設備語義信息管理模塊實現
本模塊是基于 RDF 圖模型實現工業設備信息的語義描述和管理，主要包括設 備臺賬信息管理、操作人員信息管理和設備維修信息管理。RDF是關于元數據的 框架，它為在應用程序之間利用機器可理解的Web數據提供了互操作性［37］。RDF 強調讓計算機能夠靈活方便地自動處理Web資源。RDF可以應用在許多領域，例 如在資源發現中，RDF可以增強搜索引擎的語義處理能力；在分類領域中，RDF 可以用于描述內容以及內容之間的關系；采用RDF的Agent能夠提高社區之間知 識共享和知識交換的能力等等。
在上述三個設備相關的語義信息管理模塊中，包括添加實例、添加屬性、刪 除實例和修改實例四大功能。由于各信息管理模塊在技術實現上類似，下面將以 設備臺賬信息管理為例對各模塊功能進行詳細介紹。
1. 添加實例
該部分通過Web訪問，提供設備臺賬信息的一系列屬性和對應的輸入框，以 及添加實例的執行操作。通過定義設備臺賬信息的數據模型，如圖 4.10 所示，在 設備臺賬相關本體建模的基礎上，添加三元組信息，使設備臺賬信息具備了計算 機可理解的語義。
設備臺賬信息
設備生產
產商 -設備名稱
-設備型號
-設備ID
-隨機資料ID 溫度傳 感器 -設備長 -設備高
-設備寬
-所屬部門
-購買日期 濕度傳 感器
設備生產產商 溫度傳感器 濕度傳感器
-產商名稱 -開戶銀行
-開戶賬號 -產商地址
-產商電話 -產商郵箱 -設備名稱-設備ID -生產日期
-生產廠家 -靈敏度 -所在位置
-設備型號 -最大值 -最小值 -設備名稱-設備ID -生產日期
-生產廠家 -靈敏度 -所在位置
-設備型號 -最大值 -最小值
圖 4.10 設備臺賬數據模型定義
添加實例的執行操作方法實現如下：
/* 該函數功能是實現設備臺賬信息的本體實例映射 */
public static void deviceInstanceMapping(String Repository,String className,EquipmentINF list,TemSensorINF ts,HumSensorINF hs){
AGGraphMaker maker = null;
try {
maker = Agraph.openRepository(Repository); //打開指定的知識庫
} catch (Exception e) { e.printStackTrace();
} if(maker!=null) { AGGraph graph=maker.getGraph(); AGModel model=new AGModel(graph); String exns = "http://wenyi.paper.ontology/device#"; model.setNsPrefix("device", exns); 〃設置模型命名空間
Resource deviceINF = model.getResource("http://wenyi.paper.ontology/devi- ce#"+ className); //獲取本體模型中的類資源 /* 獲取本體模型中的屬性 */
Property device_name = model.getProperty(exns,"設備名稱”)； Property department = model.getProperty(exns,"所屬部門”)； Property device_length = model.getProperty(exns,"設備長”)； Property device_ID = model.getProperty(exns,"設備 ID"); Property purchase_date = model.getProperty(exns,"購買日期”)； Property devcie_width = model.getProperty(exns,"設備寬”)； Property device_model = model.getProperty(exns,"設備型號”)； Property data_ID = model.getProperty(exns,"隨機技術資料 ID")； Property device_height = model.getProperty(exns,"設備高”)； /* 本體模型添加實例三元組 */ model.add(deviceINF, device_name, list.getdevice_name())； model.add(deviceINF, department, list.getdepartment())； model.add(deviceINF, device_length, list.getdevice_length())； model.add(deviceINF, device_ID, list.getdevice_ID())； model.add(deviceINF, purchase_date, list.getpurchase_date())； model.add(deviceINF, devcie_width, list.getdevice_width())； model.add(deviceINF, device_model, list.getdevice_model())； model.add(deviceINF, data_ID, list.getdata_ID())； model.add(deviceINF, device_height, list.getdevice_height())； ……//此處的代碼和上面添加三元組的代碼類似
}
}
其中， Agraph 類對語義圖形數據庫的相關操作方法進行了封裝， deviceInstanceMapping方法中的參數Repository表示對數據庫中的某個知識庫進行 操作，className表示設備節點名稱,EquipmentINF list表示設備臺賬的基本信息， TemSensorINF ts表示設備上溫度傳感器的基本信息，HumSensorINF hs表示設備 上濕度傳感器的基本信息，值得注意的是這些信息存在一個List中。
2. 添加屬性
該部分通過執行添加屬性按鈕進行設備相關屬性及其屬性值的添加，執行操 作的方法實現如下：
/* 該函數功能是實現本體屬性的添加 */
public static void addPropertyService(String Repository,String ClassName,String property, String inst) {
AGGraphMaker maker = null；
try {
maker = Agraph.openRepository(Repository)； //打開指定的知識庫
} catch (Exception e) { e.printStackTrace()；
if(maker!=null) {
AGGraph graph=maker.getGraph();
AGModel model=new AGModel(graph);
String exns = "http://wenyi.paper.ontology/device#"; model.setNsPrefix("device", exns); //設置模型命名空間 Resource deviceINF = model.getResource("http://wenyi.paper.ontology/device #"+ClassName);
Property pro = model.createProperty(exns, property); //創建添加的本體屬性 Literal literal = model.createLiteral(inst); //創建屬性值 model.add(deviceINF,pro,literal); //添加三元組
}
丨 } I
上述方法利用 Agraph 類中的 openRepository 方法打開語義圖形數據庫中指定 的知識庫，然后在該知識庫中創建AGGraph圖，利用該圖創建AGModel，最后利 用 AGModel 中的 add 方法添加屬性。 addPropertyService 方法中的參數 Repository 表示上述指定的知識庫，ClassName表示對某個設備節點進行操作，property表示 所添加的屬性，inst表示所添加屬性的屬性值。
3. 刪除實例
該部分通過執行刪除實例按鈕進行設備實例信息的刪除，執行操作的方法實 現如下：
/* 該函數功能是實現本體實例的刪除 */
public static void deleteService(String Repository,String subject,String property) {
AGGraphMaker maker = null;
try {
maker = Agraph.openRepository(Repository); //打開指定的知識庫
} catch (Exception e) {
e.printStackTrace();
}
if(maker!=null) {
AGGraph graph=maker.getGraph();
AGModel model=new AGModel(graph);
String exns = "http://wenyi.paper.ontology/device#";
Resource Subject = model.getResource("http://wenyi.paper.ontology/device#"+
subject); //獲取本體模型中的類資源
Property Predicate= model.getProperty(exns,property); //獲取本體屬性
Statement st = model.getProperty(Subject,Predicate); //獲取該屬性實例三元組 model.remove(st); //刪除實例三元組
}
}
上述方法利用 Agraph 類中的 openRepository 方法打開語義圖形數據庫中指定 的知識庫，然后在該知識庫中創建AGGraph圖，利用該圖創建AGModel，最后利 用AGModel中的remove方法刪除三元組。deleteService方法中的參數Repository 表示上述指定的知識庫，ClassName表示對某個設備節點進行操作，property表示 所刪除的屬性。
4. 修改實例 該部分通過執行修改實例按鈕進行設備相關屬性值的修改，執行操作的方法 實現如下：
/* 該函數功能是實現本體實例的修改 */
public static void modifyService(String Repository,String subject,String property,String Object)
{
AGGraphMaker maker = null；
try {
maker = Agraph.openRepository(Repository)； //打開指定的知識庫
} catch (Exception e) {
e.printStackTrace()；
}
if(maker!=null) {
AGGraph graph=maker.getGraph()；
AGModel model=new AGModel(graph)；
String exns = "http://wenyi.paper.ontology/device#"；
Resource Subject = model.getResource(http://wenyi.paper.ontology/devic- e#+subject)； //獲取本體模型中的類資源
Property Predicate= model.getProperty(exns,property)； //獲取本體屬性
Statement st = model.getProperty(Subject,Predicate)； //獲取該屬性三元組 st.changeObject(Object)； //修改本體實例三元組
}
丨 } I
上述方法利用 Agraph 類中的 openRepository 方法打開語義圖形數據庫中指定
的知識庫，然后在該知識庫中修改相關設備的實例信息。modifyService方法中的 參數Repository表示上述指定的知識庫，subject表示對某個設備節點進行操作， property表示設備節點的某個屬性，inst表示該屬性所修改的屬性值。
4.2.4設備語義信息查詢模塊實現
本模塊利用 AllegroGraph 語義圖形數據提供的 AG 查詢機制實現。語義查詢
模塊框架如圖4.11所示，該查詢框架包含三元組查詢、SPARQL查詢和Prolog查 詢三種查詢機制，不僅可以實現RDF圖模式的簡單查詢，還可以運行前所未有的
復雜查詢，以支持預測分析，幫助企業做出更好、更實時的決策。
AG查詢
機制 Prolog查詢 SPARQL查詢 三元組查詢
i i
*
AGJena
SPIN規則
下面將對上述的三種查詢機制的實現進行介紹：
1. 三元組查詢
三元組查詢是基于model對象的listStatement()方法實現的，它是檢索三元組 的一種簡單方法，該方法可以允許用戶輸入所需值和通配符組合，檢索所有匹配 的三元組。例如想查找“生產產商”作為主語的所有三元組，那么就可以使用三 元組查詢方式進行檢索，將“生產產商”作為主語，“null”作為謂語和賓語的通 配符，三元組查詢實現方法如下所示：
StmtIterator statements = model.listStatements(生產產商,null,(RDFNode)null);
2.SPARQL 查詢
SPARQL是W3C定義的標準RDF查詢語言，可用于查詢不同的數據源。通 常情況下， SPARQL 使用 SELECT 關鍵詞構造查詢表單，并通過圖模式匹配方式 從存儲三元組的數據庫中獲取期望數據集合。在基本圖模式中通過將各三元組模 式的主語、謂語或賓語定義為變量去匹配RDF三元組集合可實現簡單查詢，還可 以通過組圖模式、可選圖模式、多圖模式和命名圖模式等實現復雜查詢。 SPARQL 查詢返回的結果支持多種格式，如JSON、RDF/XML、N-Triple等。利用SPARQL 進行語義查詢的方法如下所示：
/* 該函數功能是實現 SPARQL 查詢 */
public static String query(String Repository,String query){ AGGraphMaker maker = null;
try {
maker = Agraph.openRepository(Repository)； //打開指定的知識庫
} catch (Exception e) { e.printStackTrace()；
}
ArrayList<TripleINF> list=new ArrayList<TripleINF>()； //用于存儲結果的 List if(maker!=null) {
AGGraph graph=maker.getGraph()； AGModel model=new AGModel(graph)；
String exns = "http://wenyi.paper.ontology/device#"； model.setNsPrefix("device", exns)； try{
String queryString=query；
AGQuery sparql=AGQueryFactory.create(queryString)； //執行查詢 QueryExecution qe=AGQueryExecutionFactory.create(sparql, model)； try{
ResultSet results=qe.execSelect()； while(results.hasNext()){
QuerySolution result=results.next()； RDFNode subject=result.get("subject")； RDFNode property=result.get("property")； RDFNode object=result.get("object")； list.add(new TripleINF(subject.toString(), property.toString(), object.toString()))； //對結果進行封裝
} }finally{ qe.close()；
}
}finally{
model.close()；
}
} return JSON.toJSONString(list,true)； //返回 JSON 數據集
}
上述方法返回的每一個獨立結果對應一個三元組，并將其封裝成TripleINF對 象，存儲在一個List中，然后利用JSON工具將List中的數據轉換成JSON格式的 數據返回，TripleINF的類型結構如圖4.12所示。
圖 4.12 TripleINF 的類型結構
例如，SPARQL查詢“Temperature”溫度節點所在的包含“opc ua”字符(忽 略大小寫)的服務器、溫度值和該值產生的時間，可將如下SPARQL查詢語句作 為上述方法中的參數query，進行數據庫查詢操作。SPARQL查詢示例如下所示:
PREFIX device:<http://wenyi.paper.ontology/device#>
SELECT ?server ?value ?time
WHERE
{
device:Temperature device:sever ?sever.
device:Temperature device:value ?value.
device:Temperature device:time ?time.
FILTER regex(?sever, "opc ua", "i" ).
J
3.Prolog 查詢
Prolog 是 AllegroGraph 提供的另一種查詢機制，主要是作為一種聲明式編程 語言:程序邏輯是用關系的形式表示，通過對這些關系運行查詢來執行計算。基 于形式邏輯的Prolog編程語言與RDF三元組描述事實的方式具有異曲同工之妙, 而且 Prolog 支持自定義的規則匹配和查詢，能夠更加方便的擴展出已知信息之外 的知識。本文使用 Prolog 查詢機制主要應用于規則推理模塊，此部分將在下一節 進行詳細介紹。
4.2.5設備異常報警及維修策略知識提供模塊實現
本模塊主要基于規則推理實現設備異常報警及維修策略知識提供等功能，其 中包括設備狀態異常報警、報警策略知識提供、設備維修任務提醒、維修策略知 識提供四大功能單元。規則推理是基于一些規則和關系，從現有陳述中動態生成 新的陳述，不斷豐富本體庫中的知識，以保證本體庫的完備性和訪問查詢效率， 擴展本體不支持的表達能力［33］。此外，規則推理技術還用于分析和判斷異常現象， 通過預先設定的規則條件觸發相應的事件或行為，并生成對用戶的通知反饋。
規則推理主要包含推理規則和推理機兩部分，下面將從這兩部分介紹設備異 常報警及維修策略知識提供模塊的實現。
1. 推理規則
本部分使用 AllegroGraph 支持的 RDF Prolog 作為規則描述語言，并允許在 RDF Prolog規則中嵌入Lisp語句以實現數值比較和加減乘除等運算。推理規則表 示為goal:-facts形式，其中goal為目標，facts為事實。
系統假設傳感器檢測值表示設備狀態和設備異常/維修與設備溫濕度值存在一 定的關系，并結合OPC UA演示服務器地址空間中不同型號的設備溫濕度節點采 集值，以地址空間中的四種不同類型的設備為例，設定設備異常報警及維修限值 選定分別如表 4.1 和表 4.2 所示。其中，表 4.1 描述了設備異常限值選定及判決， 表4.2描述了設備維修判決及維修類型。
表 4.1 設備異常限值選定及判決
溫度異常限值
濕度異常限值
表 4.2 設備維修判決及維修類型
維修條件選定
維修類型
溫度條件
濕度條件
設備名稱
確定了規則的判決條件后，需要依據知識本體編寫對應的推理規則。下面將 以設備異常報警和設備維修提醒為例，介紹如何將上表中的限值選定及判決轉化 為使用 RDF Prolog 和 Lisp 語言描述的推理規則。
(1)設備異常報警規則描述
對于AirConditioner_1設備，依據表4.1可知該設備溫度大于等于80°C時表示
設備溫度過高，設備發生異常，則其判定規則描述如下所示:
(<--(A_溫度過高?c)
(q ?c !rdfs:subClassOf !device:溫度過高)
(q !device:溫度過高!rdfs:subClassOf !device:設備異常)
(q ?x !rdf:type !device:A_ 溫度傳感器)
(q ?x !device:位置 ! "AirConditioner_1 "AAxsd:string)
(q ?x !device:value ?y)
(lisp ?v80 (value->upi 80 :double-float)) (upi<= ?v80 ?y))
其中，(A_溫度過高？c)為規則的結論，其余為規則的前提條件。前提條件中 的(q ?c !rdfs:subClassOf !device:溫度過高)(q !device:溫度過高！rdfs:subClassOf ! device:設備異常)是對設備異常類型的判斷；(q ?x !rdf:type !device:A_溫度傳感器) (q ?x !device:位置！"AirConditioner_l"AAxsd:string)(q ?x !device:value ?y)是對本 體知識庫中知識的尋址，首先確定資源類型是溫度傳感器，然后再確定傳感器的 位置，最后確定傳感器此時的采集值； (lisp ?v80 (value->upi 80 :double-float))(up i<= ?v80 ?y)是對知識的判定，此處嵌入了 Lisp語句對溫度傳感器的采集值進行判 定。
對于設備異常報警后，報警策略知識的提供可借助策略知識本體，通過Prolog 查詢并結合推理出的隱含知識，提供設備異常可能導致的故障原因策略知識，并 及時通知管理者對設備進行檢修，幫助設備管理者做出正確決策。Prolog查詢示例 如下所示:
(select (?x)
(A_溫度過高？c)
(q ?y !rdf:type ?c)
(q ?y !rdfs:label !"A 溫度過高 l")
(q ?y !device:A 溫度過高策略？x))
(2)設備維修規則描述
對于AirConditioner_1設備，依據表4.2可知該設備溫度大于等于100°C或者 小于等于55C表示設備制熱器發生故障，需及時維修，則其判定規則描述如下所 示:
(<-- (制熱器維修 ?c)
(q ?c !rdfs:subClassOf !device:設備維修)
(q ?x !rdf:type !device:A_ 溫度傳感器)
(q ?x !device:位置 ! "AirConditioner_1 "AA xsd:string)
(q ?x !device:value ?y)
(lisp ?v55 (value->upi 55 :double-float))
(lisp ?v100 (value->upi 100 :double-float))
(or (upi<= ?y ?v55)
(upi<= ?v100 ?y)))
其中，(制熱器維修？c)為規則的結論，其余為規則的前提條件。前提條件中 的 (q ?c !rdfs:subClassOf !device: 設備維修)是對設備維修類型的判斷； (q ?x !rdf:type !device:A_溫度傳感器)(q ?x !device:位置!"AirConditioner_1"AA xsd:string)(q ?x !device:value ?y)是對本體知識庫中知識的尋址，首先確定資源類型 是溫度傳感器，然后再確定傳感器的位置，最后確定傳感器此時的采集值； (lisp ?v55 (value->upi 55 :double-float))(lisp ?v100 (value->upi 100 :double-float))(or (upi<= ?y ?v55)(upi<= ?v100 ?y))是對知識的判定，此處嵌入了 Lisp語句對溫度傳 感器的采集值進行判定。
對于設備維修提醒后，維修策略知識的提供可借助策略知識本體，通過 Prolog 查詢并結合推理出的隱含知識，提供設備異常時的維修策略知識，可幫助維修人 員提高工作效率，減少人為失誤。Prolog查詢示例如下所示：
(select (?x)
(制熱器維修 ?c)
(q ?y !rdf:type ?c)
(q ?y !device:制熱器維修策略 ？x))
2.推理機
該部分利用AllegroGraph提供的AGJena推理機實現。AGJena是AllegroGraph 提供的一套Java語言開發包，基于開源項目Apache Jena進行了性能優化以滿足實 際應用需求。AGJena推理模塊框架如圖4.13所示，該推理框架分成RDFS++推理 和自定義規則推理兩部分，RDFS++推理是利用RDFS/OWL公理進行推理，自定 義規則推理則是利用AGProlog自定義規則進行推理。因此，該推理框架不僅可以 利用RDFS++推理機進行邏輯推理，還可以添加規則庫中的自定義規則進行超出邏 輯演繹能力的推理。
/ 1 AGJena推理機
1 r
推理 推理 RDFS++
推理 RDFS/OWL 公理 本體 1
1
1
過程 調用 1 11 數據 1
自定義規 則推理 •
1 AGProlog 規則 模型 1
1
1
1
圖4.13 AGJena推理模塊框架
設備異常報警及維修策略知識提供模塊的規則推理流程如圖4.14所示，首先 將設備異常或維修策略提供規則讀入到RuleSet中，從RuleSet中讀取規則；然后 將規則與不同類型設備進行匹配，如果匹配成功，則執行下一步，如果匹配不成 功，則繼續讀取規則；最后獲取設備狀態RDF數據進行判定，如果判定成功，則 執行規則發出報警及維修提醒，如果不成功，則繼續讀取設備狀態的RDF數據。
圖 4.14 規則推理流程圖
4.3本章小結
本章對基于語義的工業設備信息管理系統的整體結構進行設計，包括系統體 系結構設計、系統軟件結構設計、系統功能模塊設計，并結合語義網技術和 OPC UA 技術應用對系統的功能模塊進行實現。
第 5 章 測試驗證及分析
本章對基于語義的工業設備信息管理系統進行測試搭建，并對系統的各模塊功 能完成測試。首先介紹測試系統的系統結構及其所需的軟硬件基礎，然后對該系統 的模塊功能進行有效性測試及分析。
5.1測試系統搭建
本節基于實驗室現有的軟硬件資源，設計并搭建了基于語義的工業設備信息管 理測試系統。
5.1.1系統結構
基于語義的工業設備信息管理系統結構如圖5.1所示，該結構在B/S模式的基 礎上，采用了現有Web應用程序數據層、邏輯層和表現層三層架構模式。其中，客 戶端使用支持HTTP協議的Web瀏覽器，服務器端采用Web應用服務器和數據庫 服務器，且兩者應部署于同一物理機上。
圖 5.1 系統結構圖
5.1.2軟硬件環境
基于語義的工業設備信息管理系統的測試需要許多軟硬件的支持，包括本體存 儲數據庫、本體構建工具、Web開發軟件等，測試系統所需要的軟硬件資源如表5.1 所示。
表 5.1 測試系統的軟硬件資源表
編號 名稱 用途 版本/型號 分類
1 TopBraidComposer 本體建模 ME
2 AllegroGraph 本體/RDF數據存儲 6.1.2
3 Eclipse Jee Java Web 應用開發 Release Notes 4.8
4 Tomcat Web 應用服務器 9.0 軟件
5 OPC UA服務器 提供工業設備狀態數據 1.5.6
6 UaExpert OPC UA客戶端軟件 1.4.4
7 Gruff 圖示化數據查看器 6.3.3
8 PC 機 運行客戶端軟件 Intel(R) Core(TM) i5-4590 硬件
9 服務器 運行 AllegroGraph 曙光 A840-G10
以上的軟硬件資源除AllegroGraph部署于遠程服務器之外，其余全部部署于本 地(考慮到OPC UA演示服務器只能安裝于Windows操作系統，因此本文的Tomcat Web應用服務器部署于本地PC機)，本地的客戶端與遠程服務器通過局域網互通， 服務器的 IP 地址及端口號為：202.202.43.241:10035。
5.2基于語義的工業設備信息管理系統測試
基于語義的工業設備信息管理系統的測試是驗證系統各模塊功能及操作接口的 有效性和可用性。
5.2.1系統管理模塊測試
(1)測試目的：
驗證所搭建的基于語義的工業設備信息管理系統是否可以進行有效地登錄驗證 和注銷登錄。
(2)測試步驟：
運行 TomcatWeb 服務器，發布 paper_test Web 應用程序，順利啟動后，在 Google Chrome 瀏覽器中使用 “http://localhost:8080/paper_test/login.jsp"進行系統登錄界面 訪問，然后輸入用戶名和密碼進行登錄驗證，如果驗證成功，則會跳轉至系統主界 面，否則彈出用戶名或密碼錯誤提示框。注銷登錄驗證則是在進入主界面后點擊“注 銷登錄”字樣，返回登錄界面。
(3) 測試結果：
依照上述測試步驟，系統登錄訪問界面如圖 5.2 所示，登錄成功后主界面如圖
5.3所示。可以看出，該系統提供了較為友好的系統管理界面，能夠對系統進行登錄 驗證及注銷登錄。
圖 5.2 系統登錄訪問界面
圖 5.3 登錄成功后主界面
(4) 測試結論： 通過瀏覽器能夠對基于語義的工業設備信息管理系統進行登錄驗證和注銷登錄。
5.2.2設備狀態實時監測測試
(1) 測試目的： 驗證所搭建的基于語義的工業設備信息管理系統是否可以對設備狀態數據進行
實時采集和顯示。
(2) 測試步驟：
運行系統主界面中設備狀態監測及異常報警界面，以OPC UA服務器地址空間 中的四種類型設備為例，實時采集設備的溫濕度信息并在瀏覽器界面進行顯示。
(3) 測試結果：
依照上述測試步驟，設備狀態實時采集界面如圖 5.4 所示，可以看出，該系統 提供了較為友好的設備溫濕度實時展示界面，能夠對設備的狀態信息進行實時采集 和更新。
圖 5.4 設備狀態實時采集顯示界面
(4) 測試結論 基于語義的工業設備信息管理系統可以對設備狀態數據進行實時采集和顯示。
5.2.3設備語義信息管理測試
1.設備相關本體實例映射測試
(1)測試目的： 驗證所搭建的基于語義的工業設備信息管理系統是否可以對設備臺賬信息、操
作人員信息和維修記錄信息進行有效的本體實例映射。
(2)測試步驟：
①設備入庫本體實例映射
運行系統主界面中設備入庫管理界面，錄入設備相關的臺賬信息，如圖 5.5 所
示，錄入完成后，點擊“添加實例”按鈕。
圖 5.5 設備入庫本體實例映射界面
②設備操作人員本體實例映射 運行系統主界面中人員信息管理界面，錄入設備操作人員相關信息，如圖 5.6 所示，錄入完成后，點擊“添加實例”按鈕。
圖 5.6 設備操作人員本體實例映射界面
③設備維修記錄本體實例映射 運行系統主界面中維修記錄管理界面，錄入設備維修記錄相關信息，如圖 5.7
所示，錄入完成后，點擊“添加實例”按鈕。
圖 5.7 設備維修記錄本體實例映射
(3) 測試結果：
①設備入庫本體實例映射
依照上述測試步驟，本體實例成功生成，使用Gruff本體可視化軟件查看結果, 如圖5.8 所示，由圖可知，生成的本體實例和測試添加的設備臺賬信息是一致的。
②設備操作人員本體實例映射
依照上述測試步驟，本體實例成功生成，使用Gruff本體可視化軟件查看結果, 如圖5.9 所示，由圖可知，生成的本體實例和測試添加的操作人員信息是一致的。
③設備維修記錄本體實例映射
依照上述測試步驟，本體實例成功生成，使用Gruff本體可視化軟件查看結果，
如圖 5.10 所示，由圖可知，生成的本體實例和測試添加的維修記錄信息是一致的。
圖 5.10 設備維修記錄本體實例生成測試結果
(4) 測試結論 基于語義的工業設備信息管理系統可以對設備臺賬信息、操作人員信息和維修 記錄信息進行有效地本體實例映射。
2. 設備相關本體實例管理測試
(1)測試目的 本部分主要包括設備入庫本體實例管理測試、設備操作人員本體實例管理測試 和設備維修記錄本體實例管理測試三部分，由于各模塊管理的功能類似，本部分以 設備操作人員本體實例管理測試為例，對本體的屬性添加、實例刪除和實例修改進 行測試。
(2)測試步驟
①添加屬性 運行系統主界面中人員信息管理界面，點擊“添加屬性”按鈕，進入添加屬性 界面，錄入添加內容，如圖 5.11 所示，錄入完成后，點擊“確定”。
圖 5.11 添加屬性測試界面
添加完成后，可利用 SPARQL 查詢語言對添加的信息進行查詢，查詢示例如下 所示：
PREFIX device:<http://wenyi.paper.ontology/device#>
PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?o
WHERE
{
?a rdf:type device :設備操作人員.
?a device :地址？o.
J
②刪除實例 運行系統主界面中人員信息管理界面，點擊“刪除實例”按鈕，進入刪除實例 界面，錄入刪除內容，如圖 5.12 所示，錄入完成后，點擊“確定”。
刪除完成后，可利用 SPARQL 查詢語言對刪除的信息進行查詢，查詢示例與添 加屬性查詢示例相同。
圖 5.12 刪除實例測試界面
③修改實例 運行系統主界面中人員信息管理界面，點擊“修改實例”按鈕，進入修改實例 界面，錄入修改內容，如圖 5.13 所示，錄入完成后，點擊“確定”。
圖 5.13 修改實例測試界面
修改完成后，可利用 SPARQL 查詢語言對修改的信息進行查詢，查詢示例與添 加屬性查詢示例相同。
(3)測試結果
①、②和③都可以通過SPARQL查詢語句，成功查詢出所需要的信息，也進一 步表明可通過Web瀏覽器界面對圖形數據庫中的RDF數據進行添加、修改和刪除。
(4)測試結論 基于語義的工業設備信息管理系統可以對設備臺賬信息、操作人員信息和維修 記錄信息進行屬性添加、實例修改和實例刪除。
5.2.4設備語義信息查詢測試
本小節的語義信息查詢測試分為語義信息查詢功能測試和語義信息查詢性能測 試兩部分，下面將對這兩部分測試進行介紹：
1.語義查詢功能測試
(1)測試目的 本部分主要包括設備臺賬語義信息查詢測試、設備操作人員語義信息查詢測試
和設備維修歷史記錄語義信息查詢測試三部分，由于各查詢模塊的功能類似，本部 分以設備操作人員語義信息查詢測試為例，對語義信息的查詢進行功能測試。
(2)測試步驟 運行系統主界面中人員信息管理下的語義信息查詢界面，如圖5.14 所示，并以
“設備操作人員”為例，查詢 AllegroGraph 圖形數據庫的設備操作人員語義信息。
圖 5.14 設備操作人員語義信息查詢界面
(3)測試結果
成功獲取查詢結果，如圖5.15 所示。由查詢結果可知設備操作人員的一些基本 信息，包括姓名、性別、所屬部門、操作權限等。
重慶郵電大學工業設備語義信息管理系統
人員語義信息查詢
»設備臺賬艇
圖 5.15 設備操作人員語義信息查詢界面
(4)測試結論
基于語義的工業設備信息管理系統可以對設備臺賬信息、設備操作人員信息和 設備維修歷史記錄信息進行語義查詢。
2.語義信息查詢性能測試
(1)測試目的
測試語義信息查詢相較于傳統的基于關鍵詞的語法信息查詢在查全率和查準率 方面有何影響。
(2)測試步驟
由于本文采用的OPC UA服務器地址空間中的設備類型較少，數據信息量有限, 設備相關信息之間的隱含關聯關系匱乏，使各工業設備、操作人員、維修記錄之間 所構建的領域推理規則較少，不能很好地反映語義信息查詢的性能優勢。
因此，為了更好地體現語義信息查詢在查全率和查準率兩方面的優勢，本文構 建了文獻本體模型，并選擇知網全文數據庫作為本體實例數據源，抽取語義網、語 義Web、機器人技術、人工智能四類相關的文獻共500篇映射為本體實例數據，作 為測試數據集，分析不同查詢條件個數對查詢結果的影響，采用多次相似查詢并對 每次查詢隨機測試30次，取查詢結果的平均值。
(3)測試結果
依照上述測試步驟，將語義信息查詢和基于關鍵詞的語法信息查詢在查全率和 查準率方面進行了比較，分別如圖5.16、圖 5.17 所示。
■語義信息查詢■關鍵詞查詢
100%
圖 5.16 查全率比較圖
從圖 5.16可以看出：在查全率方面，語義信息查詢比基于關鍵詞的語法信息查 詢查全率更高，并且最大差值達到了 40%以上。這是由于基于關鍵詞的語法信息查 詢是基于字符串匹配，而語義信息查詢是基于語義匹配，但兩者隨著查詢條件的增 加，查全率都會提高。
■語義信息查詢■關鍵詞查詢
圖 5.17 查準率比較圖
從圖 5.17可以看出：在查準率方面，語義信息查詢比基于關鍵詞的語法信息查 詢查準率更高，并且最大差值達到了 70%以上。這是由于基于關鍵詞的語法信息查 詢得到很多與檢索內容并不直接相關的信息使查準率變低，而語義信息查詢得到的 信息與檢索內容基本相匹配使查準率有了明顯提高。隨著查詢條件的增加，語義信 息查詢的查準率提高，而基于關鍵詞的語法信息查詢的查準率降低。
(4)測試結論
語義信息查詢相較于傳統的基于關鍵詞的語法信息查詢在查全率和查準率方面 有了顯著提高。
5.2.5設備異常報警及維修策略知識提供測試 本小節的設備異常報警及維修策略知識提供測試分為設備異常報警策略知識提 供測試和設備維修策略知識提供測試兩部分，下面將對這兩部分測試進行介紹：
1.設備異常報警策略知識提供測試
(1)測試目的 驗證基于語義的工業設備信息管理系統的設備異常報警策略知識提供的有效性。
(2)測試步驟
運行系統主界面中設備監測及異常報警界面，如圖 5.18 所示，以 AirConditioner_l設備為例，在OPC UA客戶端軟件UaExpert中修改OPC UA地址 空間中該設備溫度節點采集的數據，查看該設備是否會發生異常報警及報警策略知 識提供。
圖 5.l8 設備監測及異常報警界面
(3)測試結果
AirConditioner_l 設備成功發生報警，并提供了設備異常報警可能產生的設備故 障原因策略知識，如圖 5.l9 所示。由圖 5.l9 可知，該設備前方的指示圈由綠變紅， 發出報警，并彈出報警策略知識提示框。
(4)測試結論 基于語義的工業設備信息管理系統可以有效地進行設備異常報警并及時提供設 備異常報警策略知識，提高了設備故障診斷效率和設備異常報警的智能性。
2.設備維修策略知識提供測試
(1)測試目的 驗證基于語義的工業設備信息管理系統的設備維修策略知識提供的有效性。
(2)測試步驟 運行系統主界面中設備維修管理下的設備維修提醒界面，如圖5.20所示，同樣
以 AirConditioner_1 設備為例，在 OPC UA 客戶端軟件 UaExpert 中修改該設備采集 的溫度數據，查看該設備是否會發生維修提醒及維修策略知識提供。
圖 5.20 設備維修提醒界面圖
(3)測試結果
AirConditioner_l 設備成功發出維修提醒，并提供了設備維修過程中維修類型的 策略知識，如圖 5.2l 所示。由圖 5.2l 可知，該設備前方的指示圈由綠變紅，發出維 修提醒，并在設備維修內容及策略提供框中彈出相應的維修策略知識。
圖5.21 AirConditioner_1設備維修提醒及策略提供結果圖
(4)測試結論 基于語義的工業設備信息管理系統可以有效地進行設備維修提醒并及時提供設 備維修策略知識，提高設備維修效率和設備維修提醒的智能性。
5.3本章小結
本章首先介紹了基于語義的工業設備信息管理系統結構以及所需的軟硬件資源， 然后對基于語義網技術和OPC UA技術實現的系統各模塊功能進行了有效性測試及 分析。
第 6 章 總結與展望
6.1課題總結
本論文針對工業設備信息管理中設備信息存在孤島，缺乏統一定義，信息組織 與管理復雜度高，信息共享程度低；設備狀態監測實時性不強，不能為遠程故障診 斷用戶提供設備狀態的實時數據；設備異常及維護智能化程度不高等問題，在充分 調研國內外研究現狀和對相關技術進行深入學習的基礎之上，結合實驗室課題需求， 將語義網技術引入到工業設備信息管理領域，并結合OPC UA技術，實現了工業設 備狀態的實時監測、設備信息語義化描述、設備信息有效組織及管理和設備異常報 警及維修策略提供。主要工作如下：
1.針對設備狀態監測實時性不強的問題，使用OPC UA集成系統，利用OPC UA 在工控領域的優勢，為工業設備信息管理系統提供設備狀態的實時監測功能，并為 設備故障診斷、維護、語義化描述和數據挖掘提供數據支撐。
2.針對設備信息存在孤島，缺乏統一定義，信息組織與管理復雜度高，信息共 享程度低的問題，將本體技術引入設備管理領域，使用 TopBraid Composer 企業級 大師版構建了設備管理領域知識本體模型，并實現了設備靜態信息和生產過程中的 動態信息的本體實例映射，使用集成Pellet推理機的Protege軟件通過基于描述邏輯 的本體推理對本體進行一致性檢測，實現了設備數據的有效組織和信息共享，降低 設備數據的管理難度。
3.針對設備異常及維護智能化程度不高的問題，將設備故障異常及維修的判定 策略轉化為使用RDF Prolog和Lisp語言描述的推理規則，借助AllegroGraph語義 圖形數據庫提供的 AGJena 推理引擎，進行規則推理，實現了設備運行過程中產生 的異常報警和維修提醒，并在此基礎上自動提供相應的設備異常及維修策略，實現 了策略知識重用，提高了設備異常及維護的智能化程度。
4.針對傳統信息管理系統中基于關鍵詞的語法信息查詢存在缺陷的問題，提出 了一種基于 AllegroGraph 的語義信息查詢機制，通過語義匹配可使查準率和查全率 相比基于關鍵詞的語法信息查詢有顯著提高。
5.驗證系統搭建與測試。結合B/S模式設計了基于語義的工業設備信息管理系
統結構，基于該系統對各模塊功能進行測試，同時也驗證了相關技術應用的有效性。
6.2未來展望
本文結合實驗室課題需求，在現有語義網技術資源和OPC UA技術研究成果的 基礎上，實現了工業設備狀態的實時監測、工業設備信息的有效組織與管理和設備 異常報警及維修策略提供等智能化應用。但是，語義網技術在工業設備信息管理中 還存在廣闊的應用空間，并且需要不斷的優化和改進，論文未來研究工作可從以下 四個方面展開：
1.設備狀態實時監測是基于OPC UA技術實現的，本文采用的OPC UA演示 服務器只提供了設備運行過程中的溫濕度數據，并且地址空間中的設備種類也較少， 連接的服務器個數單一。在下一步研究中，可接入工廠中已投入使用的多個OPC UA 服務器，添加更多類型的工業設備，提供類型更豐富的數據，從而實現更多更有用 的應用。
2.構建更大規模的知識本體。本體對于企業設備信息的組織和管理有明顯優勢， 現在的企業各部分、系統之間實現數據交互的方式比較復雜。在下一步研究中，可 以將本體構建擴展到整個企業，為企業數據建立統一描述模型，使企業各部門、系 統間實現知識共享和交換。
3.本文提出的基于 AllegroGraph 的語義查詢機制，雖然在查全率和查準率方面 有顯著提高，但是由于語義信息查詢存在規則推理任務，因此在查詢時間方面比傳 統的語法信息查詢耗時更長。在下一步研究中，將把規則推理效率作為重點進行研 究，以減少語義查詢所用的時間。
4.本文設計的基于語義的工業設備信息管理系統達到了預期目標，但是由于時 間有限，還有一些內容有待完善。在下一步研究中，可對系統各個功能模塊進行標 準化，并將自然語言處理、人工智能等技術應用其中，增強并豐富系統功能。
參考文獻
[1]Xi-Guang C. Equipment management and system implementation in modern enterprises[J]. Value Engineering, 2016, 35(20): 61-62.
[2]李盛杰.論設備管理及維修維護[J].民營科技,2018, 218(5): 176-176.
[3]Chang C, Esposito C, Wang H, et al. Intelligent power equipment management based on distributed context-aware inference in smart cities[J]. IEEE Communications Magazine, 2018, 56(7): 212-217.
[4]Pankesh Patel, Muhammad Intizar Ali, Amit Sheth. From raw data to smart manufacturing: AI and semantic Web of things for industry 4.0[J]. IEEE Intelligent Systems, 2018, 33(4): 79-86.
[5]Hendler J, Berners-Lee T. From the semantic Web to social machines: a research challenge for AI on the World Wide Web[J]. Artificial Intelligence, 2010, 174(2): 156-161.
[6]高志強，潘越，馬力，等.語義Web原理及應用[M].北京：機械工業出版社, 2009: 6-10, 164-167.
[7]Berners-Lee T, Hendler J, Lassila O. The semantic Web: a new form of Web content that is meaningful to computers will unleash a revolution of new possibilities[J]. Scientific American, 2001, 284(5): 34-43.
[8]張鵬.化工機械設備管理及維修保養技術[J].化工管理,2018(2): 167-168.
[9]吳盛萍.淺談企業資產管理(EAM)系統在設備管理中的應用[J].會計師，2015, 222(15): 73-74.
[10]楊俊艷.基于Web技術的消防設施管理系統的設計與實現[D].北京：中國科學 院大學(中國科學院工程管理與信息技術學院), 2017.
[11]宋勐翔, 童壯根, 王慧鋒, 等. 基于物聯網的承壓特種設備管理系統設計與實現 [J]. 山東工業技術, 2016(23): 115-117.
[12]Samee K, Pongpeng J. Structural equation model for construction equipment management affecting project and corporate performance[J]. Ksce Journal of Civil Engineering, 2016, 20(5): 1642-1656.
[13]Ivanna Droniuk, Olha Fedevych, Iryna Maslanych. Optimization of the computer network work based on adaptive management of node equipment[C].// International Scientific and Technical Conference on Computer Sciences and Information Technologies. Lviv, Ukraine: IEEE Press, 2017: 272-275.
[14]Bai X. Design of metrology equipment running management system based on the internet of things technology[C]//IEEE International Conference on Electronic Measurement & Instruments. Yangzhou: IEEE Press, 2018: 1436-1442.
[15]翟紅曉.光伏電廠設備信息管理系統的設計與實現[D].大連：大連理工大學 2016.
[16]戴斌，劉湘媛，秦家偉.礦冶企業設備信息管理系統的設計與實現[J].電腦知識 與技術: 經驗技巧, 2017, 13(35): 114-115.
[17]Berners-Lee T, Hall W, Hendler J A, et al. A framework for web science[J]. Foundations & Trends in Web Science, 2006, 1(1): 1-130.
[18]Mei Wu. Design and implementation of J2EE and MVC model based enterprise information management system[C]//International Conference on Intelligent Transportation, Big Data & Smart City. Changsha: IEEE Press, 2016: 424-427.
[19]Chen M. Design and implementation of ERP system based on J2EE trading company[C]//International Conference on Measuring Technology & Mechatronics Automation. Changsha: IEEE Press, 2017: 53-56.
[20]Zhou Y, Kai C, Deng L, et al. Design of management system of hainan li brocade pattern gene database based on JSP[C]//International Symposium on Computational Intelligence & Design. Hangzhou: IEEE Press, 2017: 291-294.
[21]韓路彪.看透Spring MVC:源代碼分析與實踐[M].北京：機械工業出版社, 2016: 11-15.
[22]Salamo D D, Yap L D R, Olalo R J C, et al. An Ajax-based hotel management system implementing three-tier architecture approach[J]. Cloud, 2018, 1(1): 145-145.
[23]Hao Y. Platform design of sports meeting management system for regular colleges and universities based on B/S structure[J]. Wireless Personal Communications, 2018, 102(2): 1223-1232.
[24]Jiqing Cao. Research on operation and maintenance management of equipment under intelligent manufacturing[C]//Chinese Automation Congress. Jinan: IEEE Press, 2017: 5188-5191.
[25]Sten Gruner, Julius Pfrommer, Florian Palm. RESTful industrial communication with OPC UA[J]. IEEE Transactions on Industrial Informatics, 2016, 12(5): 1832-1841.
[26]Woonggy Kim, Minyoung Sung. Standalone OPC UA wrapper for industrial monitoring and control systems[J]. IEEE Access, 2018, 6: 36557-36570.
[27]Suganya Chandrababu, Dhundy R Bastola. Comparative analysis of graph and relational databases using HerbMicrobeDB[C]//IEEE International Conference on Healthcare Informatics Workshop. New York: IEEE Press, 2018: 19-28.
[28]Zuopeng Justin Zhang. Graph databases for knowledge management[J]. IT Professional, 2017, 19(6): 26-32.
[29]AllegroGraph: Semantic Graph Database[OL]. URL: [2018-03-16]. https://allegrograph.com/products/allegrograph/.
[30]Gruber T R. Toward principles for the design of ontologies used for knowledge sharing[J]. International Journal of Human-Computer Studies, 1995, 43(5-6): 907-928.
[31]Mervin R, Murugesh S, Jaya A. Ontology construction for explicit description of domain knowledge[C]//International Confernce on Innovation Information in Computing Technologies. Chennai: IEEE Press, 2016: 73-78.
[32]李恒杰，李軍權，李明.領域本體建模方法研究[J].計算機工程與設計，2008, 29(2): 381-384.
[33]Rocha O R, Vagliano I, Figueroa C, et al. Semantic annotation and classification in practice[J]. It Professional, 2015, 17(2): 33-39.
[34]施昭，劉陽，曾鵬，等.面向物聯網的傳感數據屬性語義化標注方法J].中國科 學: 信息科學, 2015, 45(6): 739-751.
[35]Alexander A. Kropotin, Alexander G. Ivashko, Yuliya V. The ontology based method for checking semantic inconsistency of relational databases and official documents[C]//International Scientific-Technical Conference on Actual Problems of Electronics Instrument Engineering. Novosibirsk: IEEE Press, 2018: 461-464.
[36]Mustapha Bourahla. Description and reasoning for vague ontologies using logic programming[J]. IET Software, 2018, 12(5): 397-409.
[37]RDF: Resource Description Framework[OL]. URL: [2018-04-10]. https://www.w3.org/RDF/.
相關標簽:
