語義模型在智能工業營運中的作用

介紹

本文着眼于語義模型設計和技術在工業營運內建中的應用，以及語義計算的不斷發展的作用。比較語義（資料）模組化。作為應用程式架構的核心元件，以更熟悉的架構內建模式。功能能力描述了語義模型的操作基礎。語義模型的價值通過一系列讀者應該熟悉的例子來說明。

隻比對比賽;是以，為了通過區分其績效來競争，每家公司都必須明智地應用領先實踐。語義計算現在具有足夠的工業應用，可以被認為是一種領先的實踐。是以，建議以各種方式補充傳統技術和可能的長期增強功能，以促進安全性和完整性。

在圍繞更智能工廠解決方案的讨論中,通常會描述三個關鍵要素，其中語義概念是關鍵要素。這三個關鍵要素，分别是“儀表化（Instrumented）”、“智能（Intelligent）”和“互連（Interconnected）”。這些元素支援這樣一種觀點，即從我們周圍的世界收集了大量資料，如果我們使用三個“I”來聯合資料，就會産生營運智能，進而推動圍繞關鍵業務任務的及時溝通、響應和優化。在這種方法中，重要的是能夠解釋資料以進行及時分析并從各種格式和上下文的各種來源中獲得了解。使用語義計算，計算和分析被推廣到将它們應用到的相似對象的所有執行個體。

現實世界中的資料會不斷變化。是以，結構需要是自适應的，而不是嚴格預定義的。這種差異被稱為“開放世界”與“封閉世界”。語義模組化及其技術可識别基礎資料的變化以及這些變化的潛在互相作用。然而，在大多數情況下，語義的作用是在适當的上下文中及時提醒認類，以便可以識别對這些變化的響應并采取适當的行動。

實施的語義模型可以将來自任何連接配接資料存儲的資料聯合到一個靈活、自适應、适合用途的模型中，該模型利用和擴充行業标準和本體。當語義模型與執行分析、邏輯、報告、視圖等的應用程式相結合時，這些應用程式可以輕松且一緻地應用和調整，全球制造商正在真正發展到一個環境，在這個環境中，業務和營運人員可以直接控制其資料、業務和營運規則，以及業務和營運流程。一些人将這種演變稱為“不斷演變的無處不在的計算模型”，因為計算能力已經變得高度分散和普遍。

工業架構的設計必須能夠處理不斷變化的、不同的資料以及資料之間隐含的實際關系。資料源包括結構化和非結構化資料、傳感器資料（目前值和曆史值）、圖像、音頻和視訊。此外，必須識别建議的資料更改的互動作用，以便将協調更改做為規則，并且将變更降至最低。目前的資料處理不僅不能很好地适應标準的關系持久性結構，而且還面臨着在上下文中了解這些資料并适應經過經驗的添加、删除和更改，同時又不會帶來不必要的複雜性的挑戰。

語義計算的另一個主要用途是監控工業設施中部署的無數不同系統和服務的整體機械完整性。開發通用本體是一回事，這是開發語義模型的先決條件，但定期驗證适用于營運中的工業設施的法規，标準，政策，程式等的合規性計劃的完整性是完全不同的事情。核查要求确認遵守了計劃，系統配置已獲準許，所需關鍵裝置正在運作，或者在無法獲得這種确認的情況下，正在作出特别努力，以适當的方式監測增加的風險。如果事件繼續，系統應以這樣一種方式上報警報，即人類無法抑制發送到更進階别的消息。

在我們的世界中，互相依賴和互動變得過于互相關聯，以至于不得不使用技術來幫助我們驗證對既定意圖的遵守情況。也許是時候使用語義技術來監控和驗證安全性和一般合規性，包括強大的、靈活的治理。

考慮一個更智能的城市交通管理應用程式。實時交通資料通過交通燈傳感器、交通部 (DOT) 速度傳感器和錄影機提供。對準确交通流量預測至關重要的其他資料可以來自各種來源，包括天氣報告；事故報告；推文；交通中斷；月曆活動，如假期；季節性趨勢，如海灘交通；遊行、節日或重大體育賽事、緊急排程事件等特殊活動；和重大新聞事件。大量資料源用它們自己的術語描述事件，這可能與其他來源的術語有所不同。所有這些資料都必須以可用的形式被同化并在上下文中了解，并且必須解釋事件之間的關系以推斷情報。

道路、信号、傳感器等代表了交通網絡的基本模型。目前讀數、傳感器狀況、事件聲明、車輛等都代表了道路系統的狀況和每條道路的活動水準。這是要解釋的更瞬态的資料,模型更改的頻率較低。在背景獨立驗證，進而受制于适當的治理模型和開發的使用模式。事實上，甚至可以通過監控預算、施工進度等來預測模型的變化。目前的讀數和新聞源（無論其來源如何）更加動态，并且在短時間内驗證更具挑戰性。通過分離這兩類資訊（模型和更多瞬态資料），可以推導出額外的邏輯來增強對更多瞬态資料的驗證，進而減少響應時間。

為了有效地溝通，必須從這些不同的來源中引用對操作工作流程中的事件及其上下文的共同了解。例如，諸如“車輛”之類的基本術語在資料源和提供者之間可能會變得不明确，而諸如汽車、輕型卡車、半汽車、公共汽車或機車之類的差別可能會明顯減少。一些特征，例如車軸數量或乘員數量，可能會成為重要的差別。本體可以根據情況關聯“車輛”。當然，正在收集的相關資料在不斷變化。幸運的是，模型資料的更改頻率遠低于實時資料饋送。語義計算推理引擎有助于了解模型和瞬态資料變化。

語義模組化定義了資料以及這些資料實體之間的關系。工業或營運資訊模型提供了抽象不同類型資料的能力，并提供了對資料元素如何關聯的了解。語義模型是一種支援資料實體及其關系的固定和即席模組化的資訊模型。我們語義模型中的實體總集包括類的分類法，這些類可以在我們的模型中用于表示現實世界。這些想法一起由本體表示，本體是語義模型的詞彙表，為形成使用者定義的模型查詢提供了基礎。該模型支援實體及其關系的表示，支援對這些關系和實體的限制，并根據查詢聚合術語，例如“車輛”的定義。這提供了資訊模型的語義構成。

在網際網路聯盟（W3C）版本的語義計算中，通過個别元素對資料的通路，被應用于資料的驗證、計算等的本體對齊規則，以及衍生的推論，與資料存儲相分離。這不僅僅是一個關于系統或整體架構的生産力和機械完整性的基本概念。

目前的語義計算技術使：

• 将來自多個資料存儲的資料聯合為規範化形式，而無需從其主資料存儲或記錄系統(SOR)中移出。
• 建立一個由工程師動态建構的不可知資料模型，以關注目前的需求。
• 以任何形式或架構以及任何所需的工具想消費者提供資料。
• 在獨立于任何單個應用程式的資訊模型中內建業務和營運規則。
• 開發算法等，無需使用者特别努力即可在所需對象的所有現有和新執行個體上運作。

這些是對資訊管理和業務流程的典型方法的重大轉變。是以，他們确實需要重新定位和重組 IT 團隊，以不同于業務和營運團隊的傳統方式生成資訊。

語義計算的長期目标是實作靈活、自适應的環境，其中：

• 資料 + 模型 = 資訊
• 資訊 + 規則 = 知識
• 知識 + 行動 = 結果

在我們的交通管理示例中，語義模型允許使用者了解諸如 (1) 交通燈傳感器和被監控的十字路口之間的關系，(2) 任何給定交通燈傳感器與同一道路上其他傳感器的關聯， 或（3）道路與其他相交道路和主要公路的關系。語義模型還可以産生關于公交線路或地鐵線路的類似資訊，以進一步描述服務位置内可用的服務類型。車站與街道位址、服務線路和地面道路路線之間的推斷關系還為了解公共交通服務的特定中斷對道路交通的影響提供了基礎。

作為一個額外的複雜功能，一個單一的應用程式必須與多個領域模型或領域本體互動。實作這種互動的一種方法是将現有的本體合并為一個新的本體。沒有必要合并來自每個原始本體的所有資訊，因為這種內建可能無法在邏輯上得到滿足。此外，新的本體可能會引入新的術語和關系，用于連結源本體中的相關項：在後面部分的示例中，本文将密切研究如何進行語義模型的建構最适合。

制造業的複雜性問題

在今天的商業環境中，有效決策的挑戰由于大量資料的湧入和對可操作資訊的日益迫切而加劇了。業務線經理正在尋找資訊基礎設施，以提醒他們及早發現不斷變化的不良情況，以便他們能夠通過商業智能（BI）和營運智能（OI）解決方案中的背景可見性和決策支援來緩解不良情況。在一個制造企業中，資訊存在于各種島嶼中，它們必須互相銜接和溝通，以協調營運工作流程的執行。每個島嶼都是一個營運部門或地區的記錄系統（SOR），其中的資訊系統是某個資料元素或資訊的權威資料源。SORs包括ERP、MES、LIMS、QMS、WMS、SCADA和IO裝置。每個SOR中的資訊結構會随着産品庫存機關（SKU）數量、生産組合、吞吐率的生産線比例以及持續改進措施和工藝技術改進而發生變化。SORs使用一個非常具體的資料模型，它是為支援實時工作流程的特定應用功能要求而設計的。在當今快速變化的世界中，MOM和流程控制應用的非靜态性質和較長的采用時間架構是持續改進和企業競争力的主要抑制因素。這些都是實施和維護綜合MOM和流程控制解決方案的主要成本因素。

通常情況下，SORs的能力有限，無法以合理的成本和在短時間内适應流程和資料的變化。這就是60-90%的IT預算是用于維護而不是用于增強的主要原因。通過将SORs的資料暴露給語義計算應用，額外的功能更容易被整合，但更重要的是，對所有法規、标準、政策、程式等的正式遵守，能夠在每個SORs内部和SORs之間得到驗證，并且獨立于每個SORs。

制造業企業内的營運是由不斷變化的結構、業務驅動的。操作過程（活動）利用了多個SORs的資訊和能力。每個SORs都參與到工作流程中，用裝置、材料和人員來執行，這就形成了動态的、特别的操作流程和資訊本體。由于知識工作者使用的80-90%的資訊已經存在，語義模組化技術可以有效地集中來自多個SORs的可操作資料，允許知識工作者有效地使用每個SORs來執行準确和及時的行動。事實上，語義技術可以更新基礎資料存儲，但是在不久的将來，知識工作者可能最好是使用适當的SORs來更新資料。

ISA-95第3部分标準《制造營運管理（MOM）的活動模型》确定了四種活動模型，涉及MOM的各種SORs，必須交換的資料和事件：

• 生産經營管理。
• 品質營運管理。
• 維護操作管理。
• 庫存營運管理。

ISA-95第3部分指出，MOM活動是指制造工廠在将原材料或零部件轉化為産品過程中協調人員、裝置、材料和能源的活動。每個MOM活動模型是由功能中的任務和任務與功能之間的資料交換組成的。根據普渡企業參考架構（PERA）（www.pera.net）的概念（ISA-95的原始參考模型），功能和任務可以由實體裝置、人力或資訊系統執行。對于工單的操作路線中的每一項操作，四個MOM活動、功能、任務和交換的一些子集被調用，以執行該操作的工作流程，使用各種裝置、SORs和人員完成工單。按照這種模式，作業資源（材料[原材料、中間産品、消耗品和成品]、裝置和工具、MOM和過程控制系統，以及人）被視為相當于作業流程執行中的SORs的參與者。

業務資源是資料的來源，也是改變狀态的功能調用的目标，類似于一個資料庫。換句話說，一個給定的任務或資料交換隻能由人、裝置或記錄系統--一個資訊系統來執行，該系統是給定資料元素或資訊的權威資料源。作業資源在路線的每項作業中的應用是作為作業定義和規則中規定的每項活動的一組任務來執行的。對于一個給定的産品和生産線，安排和執行操作計劃的操作定義和規則通常是：各種SORs的一部分。生産路線的所有操作的協調方法必須驗證訂單執行過程中操作定義的變化，并且必須對變化做出反應，同時保持SORs之間資訊的一緻性，以産生每個活動的任務和資料交換的預期結果。

随着制造業第4層業務和第3層操作流程的執行，各種SORs的資料被使用或改變。來自不同來源的事件被觸發，以推進流程的執行或啟動新的業務和營運流程。傳統上（即 "語義 "計算之前），其中一些流程是在SORs之外定義和執行的，在這些系統之外留下一些流程執行的短暫曆史。換句話說，大量的這些系統并不存儲了解因果關系所需的資訊變化曆史，而這又是了解“what, when, and why”所需要的。這種資訊對于分析推動制造企業内部的持續流程改進至關重要。有了語義計算，這種資訊就很容易被捕獲，并成為正式記錄的一部分。

諸如流程曆史記錄這樣的應用，如果用來捕捉資訊，通常隻包括時間上下文，而不是用來處理來自SORs的複雜和交易性資料，如ERP和MOM應用。同樣，ERP系統通常缺乏詳細的執行資訊或高速交易功能，例如，在對某一特定裝置進行裝置維護後，識别哪一個生産請求被首次處理。為了從傳統系統中獲得這些資訊，有人必須知道如何從營運執行管理系統（生産、品質、庫存和維護）中查詢與裝置、操作單、工單和操作環節有關的記錄。被查詢的記錄必須從記錄、生産單和工單的時間戳中進行搭配和協調，以找到在裝置最後一次返修前後處理的生産請求的完整譜系。時間，作為跨SORs的一緻資料元素，是可用于連接配接SORs之間資訊的相關上下文。當然，這假定時間在各系統之間是适當同步的。有了語義計算，這些查詢可以以一種易于維護的方式進行結構化和重複使用，并且有審計跟蹤。

制造業企業擁有豐富的标準操作程式（SOPs），這些程式定義了應該如何執行操作流程。以上面的例子為基礎，制造企業可能有詳細的SOPs，用于裝置維護程式、裝置投入生産的資格認證，以及産品在制造過程中的路由和排程。

目前和曆史上，SOPs是以紙質形式存在的，根據需要參考。由于SOPs是手動執行工作流程的（在SOR之外），對發生了什麼、何時發生以及為什麼發生的詳細說明的譜系和了解，在最好的情況下，需要收集和關聯紙質記錄，在最壞的情況下，需要開會，讓人們通過讨論他們記得的發生過的事情來彙集記錄。有了語義計算和自動化的商業和營運流程，這些都會發生變化，但對這種有價值的變化卻有很多阻力。今天的制造企業對變革有強烈的、固有的抵觸情緒，對人們必須了解其中的風險和實作回報的好處這一現實有抵觸情緒。

使問題更加複雜的是，SORs中的資訊通常是以特定的任務或工作流程的形式存在，而不是以領域專家看待更廣泛挑戰的形式存在。在大多數情況下，為滿足新的需求而修改、替換或擴充SORs，即使是一種選擇，也是成本過高的。務實的解決方案是一種幹擾性較小的方法，它能滿足動态制造環境的要求，并為企業和工廠的各部門提供多種形式的相關、及時的資訊通路。事實上，整個企業和行業的領域專家都需要一個結構化的資訊環境，以提醒他們的教條事件，供他們分析的背景意見，進而得出他們的決策。通過語義計算，語義模型（具有将資料與資料存儲分離以及對該資料采取行動的能力）在這種務實的MOM架構形式中發揮了關鍵作用。

無論是城市交通管理還是煉油廠管理，通過語義計算應用語義模型所提供的推論和了解，對于從被監測的SORs和過程儀器中正确地得出見解至關重要。這種近乎實時的分析最終導緻了通過及時的、反應迅速的決策來優化、靈活的業務和營運流程。語義計算通過使用其推理能力來提醒正确業務流程中的正确人員及時采取正确的行動，并在沒有及時解決的情況下進行更新，進而大大增強了來自各種SORs的資料聯合。

為什麼是語義模型？

究竟什麼是語義模型。它們對這種類型的營運系統整合有什麼幫助？首先，為了清楚起見，解釋一下統一模組化語言（UML）中的模型與網絡本體語言（OWL）之間的差別：

UML 是一種模組化語言，用于軟體工程中，主要圍繞面向對象的系統設計工件。在此 UML 上下文中解釋基于面向資訊的體系結構 (IOA) 的作業系統內建時，語義模型被用作應用程式的功能核心，以提供可導航的資料模型和關聯關系，這些模型共同表示我們目标領域的知識。

Web Ontology Language 是用于編寫本體的知識表示語言系列。這些語言的特點是形式語義和資源定義架構 (RDF)/RDF 模式 (RDFS)/語義 Web 的基于 XML 的序列化。OWL 得到了網際網路聯盟 (W3C) 的認可，并引起了學術、醫學和商業的興趣。OWL家族中的本體描述的資料被解釋為一組“個體”和一組“屬性斷言”，它們将這些個體互相關聯。本體由一組公理組成，這些公理對個體的集合（稱為“類”）以及他們之間允許的關系類型進行限制。這些公理提供語義，允許系統根據明确提供的資料推斷出額外的資訊來。W3C 的 OWL 指南中提供了對 OWL 表達能力的完整介紹。

本體定義了用于描述和表示一個知識領域的術語。本體被需要分享領域資訊的人、資料庫和應用程式所使用（領域隻是一個特定的學科領域或知識領域，如醫學、工具制造、房地産、汽車維修或金融管理）。本體包括領域中基本概念的計算機可使用的定義以及它們之間的關系（注意，在這裡和整個本文中，定義不是在邏輯學家了解的技術意義上使用的）。它們對一個領域的知識進行編碼，也對跨領域的知識進行編碼。通過這種方式，它們使這些知識可以重複使用。

本體一詞已被用于描述具有不同結構程度的人工制品（工件）。這些範圍從簡單的分類法（例如樹型層次結構）到中繼資料方案，再到邏輯理論。語義網需要具有相當程度的結構的本體。這些需要為以下類型的概念指定描述：

• 許多感興趣的領域中的類（一般事物）。
• 事物之間可能存在的關系。
• 這些事物可能具有的特性（或屬性）。

本體通常用一種基于邏輯的語言來表達，這樣就可以在類、屬性和關系之間做出詳細、準确、一緻、合理和有意義的區分。一些本體工具可以使用本體進行自動推理，進而為智能應用提供進階服務，如：概念/語義搜尋和檢索、軟體代理、決策支援、語音和自然語言了解、知識管理、智能資料庫和電子商務。

本體在新興的語義網中占有重要地位，它是代表檔案語義的一種方式，并使語義能夠被網絡應用和智能代理使用。本體對于一個社群來說是非常有用的，它可以作為一種結構化和定義目前正在收集和标準化的中繼資料術語的方式。使用本體，未來的應用程式可以是 "智能的"，在這個意義上，它們可以更準确地在人類可了解的概念層面上工作。

語義模型允許使用者以更自然的方式，以結構化查詢、交易、接口和報表的形式，對模組化系統中正在發生的事情提出問題。舉例來說，一個石油生産企業可能由五個地理區域組成，每個區域包含三到五個鑽井平台，每個鑽井平台由幾個控制系統監控，每個系統都有不同的目的。其中一個控制系統可能監測采油的溫度，而另一個可能監測泵的振動。語義模型允許使用者問一個問題，如 "3号平台上正在開采的油的溫度是多少？"而不必了解細節，如哪個具體的控制系統監測該資訊，或哪個實體傳感器（通常由OPC标簽代表）報告該平台上的油溫。

是以，語義模型被用來将控制系統工程師所知道的實體世界（在這個例子中）與業務線上司和決策者所知道的現實世界聯系起來。在實體世界中，一個控制點，如閥門或溫度傳感器，是通過其在特定控制系統中的辨別符，可能是通過一個标簽名稱來了解。這可能是任何給定控制系統中幾千個辨別符中的一個，而且整個企業可能有許多類似的控制系統。為了使資訊參考和彙總的問題進一步複雜化，其他感興趣的資料點可以通過資料庫、檔案、應用程式或元件服務來管理，每一個都有自己的接口方法和資料通路的命名慣例。

是以，語義模型的一個關鍵價值是以一緻的方式提供對現實世界上下文中的資訊的通路。在語義模型實作中，這種資訊是使用“主語-謂語-賓語”形式的“三元組”來識别的。例如：

• 儲罐 1 <有溫度> 傳感器 7。
• 儲罐 1 <是>平台 4 的一部分。
• 平台 4 <是>區域 1 的一部分。

這些三元組一起構成了可以存儲在模型伺服器中的區域的本體。使用模型查詢語言可以輕松周遊此資訊，以回答諸如“平台 4 上的儲罐 1 的溫度是多少？”等問題。這比沒有将工程資訊與現實世界相關聯的語義模型的情況要容易得多。

此類應用程式的語義模型的另一個優點是維護。參考圖 2-1。

圖 2-1：資訊模型結構

這裡描述的現實世界模型可以用圖2-1所示的任何一種類型的模型來實作。關系模型的實體之間的關系是通過明确的鍵（主鍵、外鍵）實體和為關聯實體的多對多關系建立的。在這種情況下，改變關系是很麻煩的，因為它需要改變基礎模型結構本身，這對一個已填充的資料庫來說是很困難的。對基于關系模型的那種資料的查詢也會很麻煩，因為它會導緻非常複雜的where條件或重要的表連接配接。

樹型模型（圖 2-1的中間部分）在涉及現實世界的更新時也有類似的限制，并且在嘗試“橫向”周遊模型時不是很靈活。

圖型模型（圖 2-1 的右側）是語義模型的實作方式，以便在部署後更輕松地查詢和維護模型。例如，一個新的關系必須被表示出來，而這是在設計時沒有預料到的。有了三元組存儲表示法，額外的表示法就很容易被維護。一個新的三元組被 簡單地添加到資料存儲中。這是一個關鍵點。關系是資料的一部分，不是資料庫結構的一部分，也不是特定SOR的一部分。同樣，該模型允許從許多不同的角度進行周遊，以回答在設計時沒有考慮過的問題。相比之下，其他類型的資料庫設計可能需要更改結構來回答初始實施後出現的新問題。

語義模型（基于圖）允許以非線性方式輕松進行推斷。例如：考慮購買書籍或音樂的線上服務。這樣的應用程式應該非常擅長根據您的購買模式提出額外的購買建議。這對于提供諸如“因為您喜歡這部電影，您可能也喜歡這些電影”或“因為您喜歡這首音樂，您可能還會喜歡以下内容”等推薦的電商網站非常常見。

實作此目的的一種方法是使用語義模型，并添加如下關系：

A <類似于> B

此外，還建立了一個本體，其中A和B都屬于名為“新時代”的音樂流派。這些關系一旦在模型中建立，就可以在需要時輕松提供這些類型的建議。

“老天爺給你的任何機會，你也不會珍惜，更不會深入下去，你認為自己就是窮命，最喜歡通過脈脈閱讀免費的職場技巧。如果你還是杠精思維，任何事情，跑上來先論證困難，給自己一個不幹不參與的充分理由，那你完了。人生不過是短短十五年的機會，到了四十歲，你還在屌絲堆裡，啥也不幹，那你沒希望了。”