向基於語義模型的操作集成的演變
向基於語義模型的操作集成的演變
在過去的許多年裡，已經定義了許多架構方法，用於系統集成以及其資訊和流程的表示。這些方法包括面向數據、面向消息、面向服務和面向資訊的方法。需要探討的問題是：
- 這些不同的方法有何不同和聯繫？
- 從實時運營整合架構的角度來看，語義模型究竟適合在用哪裡？
- 語義模型作為實時操作集成架構的一個關鍵組成部分，能提供什麼價值？
-
集中式應用的數據
從 1950 年到 1980 年，單體應用程式要求應用程式擁有所有數據。所有對數據的訪問都是本地的；所有定義、關係和知識都包含在應用程式中。企業中的部門化用戶擁有直接的領域知識，因此無需集成。
隨著電腦變得更加經濟實惠並在整個工業運營中激增，並且在終端設備中包含可編程邏輯控制器 (PLC) 和嵌入式計算功能，複合應用程式和系統的複雜性穩步增加。從 1990 年到現在，資料庫和客戶端-伺服器架構曾經並且仍然用於允許多個並發客戶端與集中式數據存儲進行交互。
對於集中式數據存儲，集中式應用程式擁有其部分數據，其他應用程式直接調用以獲取資訊或請求被調用應用程式執行某些操作。從歷史上看，這涉及通過應用程式介面 (API) 或遠程函數調用 (RFCs) 直接調用另一個應用程式。API 和 RFCs 包含在客戶端庫中，調用應用程式鏈接到該客戶端庫。在這種情況下，調用應用程式負責理解被調用應用程式的語義並負責所有數據轉換等。雖然從性能角度來看速度很快，但從維護角度來看，這種方法已被證明是昂貴的（而且很脆弱，因為一個應用程式中的故障會對所有直接相互連接的應用程式產生連鎖反應）。此外，在大多數情況下，數據驗證方法的記錄不充分。因此，基本數據的新消費者的新要求導致部署並行系統以捕獲附加數據，同時引入替代數據驗證規則。這種做法會產生多個「真實的版本」，因此數據的所有用戶都會花費 50-75% 的時間來對賬和驗證數據，然後才能充分信任數據以進行分析。隨著系統複雜性和點對點集成的增加，這種準備時間也在增加。語義計算的另一個好處是減少這種浪費的時間。
-
以數據為中心的架構
擁有數據的集中式應用程式的替代方案是以數據為中心的架構。這顯然比直接連接的方法向前邁進了一步，因為應用程式不會直接相互連接以交換資訊。以數據為中心的架構以相關業務和運營數據的單一定義為基礎，圍繞這些數據集成系統並開發應用程式。簡而言之，以數據為中心的架構為集中式數據存儲和使用該集中式數據存儲的規則和要求進行互操作的客戶端應用程式建立了一個通用數據模型。不幸的是，數據是從它們在各種 SORs 的端點複製的，其中應用了獨特的驗證規則。這也導致了多個「真實的版本」。
這種方法的一個早期例子是 SAP 的早期版本。這些 SAP 版本是（或至少看起來是）基本上是 40 多個應用程式套件，開發圍繞中央數據模型進行交互。儘管 SAP 支援外部應用程式的其他集成方法，但 SAP 已採用以數據為中心的方法進行應用程式內部通訊，從而導致數據重複。
XML 之前的集成方法雖然本質上很簡單，但卻是用固定的數據結構實現的，這導致了一個相當緊密耦合的系統，其中所有系統組件都受到數據和數據結構變化的影響。這種架構方法通常會導致共享數據存儲中出現單點故障。從歷史上看，它在業務系統中不是關鍵的，但在運營中的實時工作流程應用中，這種方法破壞了運營系統。並造成巨大的效率和品質損失以及額外的成本。
-
分散式應用的數據
隨著 1990 年至今網路的進步，應用程式的複雜性發展為由多個通訊（集成）應用程式構建的分散式系統。雖然早期的實現主要是試圖打破單體架構，但它們仍然基於單一應用程式模型並為特定領域設計。
最終，這導致了一類新的系統，其中集成了多個應用程式以創建新功能並使用每個應用程式中包含的數據來實現最初應用程式設計者最初不打算的功能。在這種情況下，每個應用程式都是一個 SOR—一個資訊系統，它是給定數據元素或資訊片段的權威數據源。
這些系統的分散式特性引起的問題很快導致人們意識到分散式架構是硬而脆弱的。需要一種更好的系統間通訊方式來處理通訊故障和應用程式可用性問題。這導致了鬆散耦合的面向消息架構的想法。
-
面向消息的架構 (MOA)
面向消息的架構 (MOA) 用於交換資訊（文檔），其中沒有關於應該對接收的文檔做什麼的隱含語義。
這個定義是什麼意思？這基本上意味著 MOA 用於廣泛的資訊共享。一個例子是股票報價，其中金融服務公司有一個 MOA 主幹（例如，TIBCO、MQ 或 MSMQ）來將股票價值的變化分發給任何感興趣的應用程式。MOA 不會規定某人在知道股票價值發生變化後會做什麼；MOA 只是通知他們這已經發生了。根據這個定義，MOA 主要用於數據同步和事件通知。因此，MOA 通常是基於發布/訂閱的。
就其本身而言，MOA 不涉及交換資訊的任何數據模型。它以請求的服務品質將數據從 A 點移動到 B 點。它不定義內容，也不捕獲系統的語義。
當 MOA 期望響應時，MOA 可以擴展為包括結構化數據。在這種情況下，要交換的資訊的數據模型通常基於行業標準。示例包括 EDI（Electronic Data Interchange）、BEMML（ISA-95 標準的 XML 實現）和 BatchML（ISA-88 標準的 XML 實現）。所使用的數據模型也可用於我們在上面「以數據為中心的架構」部分中討論的數據模型。
-
面向服務的架構（SOA）
雖然 MOA 有助於緩解分散式系統中應用程式之間的通訊複雜性，但典型的系統是通過點對點集成構建的，資訊語義被隱藏、隱藏在實現中並且在運行時根本不可用。
SOA 為應用程式或應用程式組件之間的互操作添加了一種標準化方法。SOA 添加了在運行時可發現的介面契約的獨立於平台的描述。這使得臨時客戶端能夠訪問公開的資訊，如果不深入了解正在交換的數據和消息傳遞主幹的結構, 這在 MOA 中有時是不可能的。不幸的是，並非所有資訊都被公開，但該概念確實提供了一定程度的改進。有了嚴格的設計和治理監督，改進的程度是非常大的。
在 SOA 中，消費者（客戶端）為了一些明確定義的目的（例如，處理訂單）與提供者進行交互。資訊是針對特定任務的，不會經常更改。當資訊確實發生變化時，會添加一項新服務以保持與現有系統的「向後兼容性」。單個服務定義捕獲服務及其數據的語義，但無法提供有關係統的任何知識。
-
面向資訊的架構（IOA）
由於基礎設施的多樣性，前面的架構方法可以說是相輔相成的，並且在實際中一起使用是有意義的。事實上，任何不斷發展的架構都必須提供一種與現有系統有效共存和/或集成的方法。系統需要進化，重構根本負擔不起，也不現實。IOA 擴展了 SOA 以包括對被集成系統中資訊的規範視圖和訪問，作為業務和運營智慧和分析的基礎，支援流程優化和增強的決策制定。IOA 為市場提供了組合業務和運營流程的基礎，這些流程和運營流程圍繞單個資訊模型共同創建複合應用程式。該模型定義了數據交換的規範形式並定義了數據中介的規範。這與上面的以數據為中心的方法不同，規範模型是交換模型，不一定是任何給定服務的模型。挑戰在於數據模型是為一組給定的問題設計的。將其重新定向以用於其他目的，需要類似於 SOA 的治理規則和流程。
另一方面，語義計算在元素級別定義數據，因此可以輕鬆創建用於特定目的的模型，而無需從適當的數據存儲中移動數據。語義計算並不適用於所有應用程式，但有許多應用程式是獨一無二的。一些關鍵示例是 (1) 強大、敏捷的治理，(2) 實時 HAZOPs，以及 (3) 整個設計、採購、施工、移交、啟動和調試階段以及運營和維護階段的數據管理。鑒於這些示例解決方案針對的是相對較小的一組人員和一組集中的長期運行的功能和任務，使用語義計算，通常的可擴展性挑戰不是問題。
IOA 通常包括 MDM（主數據管理）和 BI 和 OI 工具，作為 SOA 的補充。在他的數據集成部落格文章 (//www.dataintegrationblog.com/robin-bloor/heart-information-orientationarchitecture-middleware/) 中，Robin Bloor 指出 IOA 還可能包含語義數據映射以提供資訊的上下文在 MDM 和集成應用程式中訪問。這個想法與本文的基本前提是一致的。無論前面描述的架構方法已經證明多麼有用，它們都缺乏用於處理資訊的上下文。SOA 與基於標準的消息（例如 OAGIS、BAMML 和 BATCHML）相結合，提供了為諸如訂單管理或生產跟蹤之類的服務創建和集成複合流程和應用程式的能力。但是，對於客戶端應用程式可以請求的資訊，仍然沒有覆蓋上下文。
該上下文在 IOA 中由真實世界的覆蓋模型提供，該模型為資訊請求提供上下文。通過這種方式，請求（以及相關的服務、數據的定義等）與模型中定義其含義並提供其上下文的對象相關聯。例如，可以基於行業標準（例如 ISA-95 和 ISA-88）為工業企業創建模型，用於定義石油鑽井平台的企業層次結構。該模型位於層次結構的最低級別，包含設備資源的實例，例如與資訊請求、操作和響應相關聯的泵或電機。然後，該關聯提供上下文以支援查詢，例如「查找該泵的可用工單」、「報告該電機的當前溫度」或「計算該水箱上周的 pH 平均值」。通過向 IOA 添加上下文，IOA 的行為類似於語義計算。事實上，ISO 15926，工業自動化系統和集成–包括石油和天然氣生產設施在內的加工廠的生命周期數據的集成就是這樣一個標準定義。
所有這些資訊都可以通過任何先前描述的架構以一種或另一種方式獲得。語義計算所做的是以對工業企業有意義的方式將獨立於提供者的上下文、規則和持續治理引入討論中。語義計算簡化了訪問數據的任務以及將有意義的動作與建模對象相關的事件相關聯。
-
模型驅動架構
到目前為止，討論的重點是使用語義模型來支援運營系統集成，並且可以說，通過使用 SOA、中間件、語義計算和（在適當的情況下）通用資訊模型來創建複合/集成應用程式。在語義計算中，可以針對特定需求構建多種資訊模型，從而消除對固定通用資訊模型的需求。這聽起來可能類似於前面討論的模型驅動架構，但實際上，它是非常不同的。模型驅動架構，在 Alan Brown 的論文「模型驅動架構簡介」中有詳細解釋，是關於在應用程式設計的上下文中使用流程模型來驅動應用程式的開發，可能包括應用程式程式碼本身的生成。相比之下，本文的討論側重於模型的臨時或集中使用，結合 SOA 和適當的中間件，對上下文中提供的資訊採取行動，重點關注企業中可用且獨立於 SOR 的資訊。
資訊模型——語義模型的核心
術語資訊模型 (IM) 通常用於單個事物的模型，例如設施、建築物和過程工廠。資訊模型將問題域的描述形式化，而不限制該描述如何映射到軟體中的實際實現。簡而言之，資訊模型是一種抽象不同數據的方法。資訊模型是關於描述數據的含義（本體）以及它們適合的位置。在語義計算上下文中，可以組織這些數據來回答任何特定問題。今天，供應商通常使用語義計算概念來解決一組有限視圖中特定的、預定義的問題。資訊模型允許我們理解和抽象其設計意圖的知識。
ISA-95 是特定領域資訊模型的一個很好的例子，其設計意圖是通過解決上述四個運營活動來優化工業設施的運營（參見「製造業的複雜性問題」）。ISA-95 標準正確地指出，其模型結構並不反映公司內特定的業務組織結構，而是一種運營活動的模型。不同的公司將活動或子活動（職能和任務）的職責分配給不同的業務組織組。換言之，ISA-95 定義了製造運營管理 (MOM) 域中的數據/對象和活動的實例。ISA-95 活動並未指定哪些系統必須到位或這些系統應如何實施或集成。資訊模型幫助我們了解不同的資訊如何相互關聯，但不能幫助我們了解系統應該如何實施。
ISO 15926 工業自動化系統和集成——包括石油和天然氣生產設施在內的加工廠生命周期數據的集成是設備生命周期資訊管理的另一個例子，從概念到初步工程、詳細工程、採購、施工、移交，再到運營和維護 (O&M) 階段，ISA-95 也適用。ISA-95 是 ISO 15926 運維階段的補充，作為變更資料庫的工程管理，使所有設備和系統配置的知識保持一致。這種一致性管理是被ISA-95 假定的，但它明確地超出了 ISA-95 的範圍。
語義模型是一種特定的資訊模型。語義模型有助於識別資訊中的模式和趨勢並發現不同資訊之間的關係。語義模型使用兩個重要的結構：
- 辭彙：一組概念，給出了明確定義的含義，在上下文中保持一致。
- 本體：定義辭彙背後的上下文關係，是定義特定知識領域的基石。
語義模型由概念網路和這些概念之間的關係組成。在工業企業中，概念可能是「生產請求」、「批次」或「設備」。ISA-95 第 1 部分是語義辭彙的一個很好的例子，定義了易於理解的特定領域的概念。
一個概念的意義是由它與其他概念的關係來定義的。ISA-95 中這種關係的一個很好的例子是「設備類別」和「設備」。由於設備在語義上與設備類相關聯，因此領域中的系統和人員可以使用語義關係找到特定類的所有設備。
雖然沒有正式的關係標準，但語義模型通常使用以下定義：
- 實例：x3456 是一個批次的實例。
- IS_A：反應器是一種設備。
- HAS_PART：反應器 <有部件> 加熱器。
隨著知識的變化，語義模型必須進化。例如，當定義新的操作定義（產品）段時，可能需要通過將資訊模型鏈接到特定操作/流程段來更改資訊模型。與運營部門相關的其他定性數據可以輸入到不斷更新的模型中，從而豐富模式和影響的知識。
在語義計算的概念中，這種變化是 “可發現的”，並被自動嵌入到基礎設施中。
行動路線
資訊建模的主要目標是提供一種敏捷、適應性強、易於理解的方法和術語，用於訪問 SORs 內的數據和上下文，以豐富知識並提高每個組織的適應性和響應能力。
資訊上下文的一個重要因素是它的脈絡，即資訊變化的有序歷史。這在許多分析性應用中尤為關鍵。脈絡有助於回答諸如以下問題：
- 這批產品使用的是什麼批次的材料？
- 我們何時得知的？
- 為什麼會做出這樣的決定？
脈絡增加了重要的背景，將實例與事件和活動的時間線聯繫起來。脈絡還提供了關於流程執行的持續時間的資訊，無論是與設備、材料轉換、系統性能，還是人們的反應能力有關。例如，一個理想的系統會在以下時間段捕獲數據：
- 在任何SOR內的創建（輸入製造產品的請求）。
- 作為一項任務提交給操作員（告訴操作員去製造產品）。
- 來自設備的狀態變化，表明該過程已經開始（現在正在製造產品）。
在此示例中，脈絡為流程性能和所有參與者提供現場計量。
由於變化發生在多個分散式系統中，沒有一個單獨的SOR包含一個完整的變化歷史。每個SOR都以歷史數據的形式提供它的每一塊拼圖。正因為如此，我們往往只能看到一個不完整的、難以理解的過去的情況。沒有任何一個單獨的SOR會提供完整的脈絡覆蓋和參與制造運營執行的所有SORs的可視性。語義計算允許在不改變任何預先存在的SOR的情況下將這些項目聯繫起來。
業務數據的複雜性
不幸的是，製造企業內各種 SORs 中存在的大部分數據都不是以漂亮的、扁平的、類似於表格的形式出現的。數據通常表現為複雜結構、層次結構、集合和數組的醜陋混亂形式。雖然電腦可以輕鬆處理它，但人們無法輕鬆理解此類資訊。更糟糕的是，當今市場上的大多數報表和 BI 工具都旨在處理扁平的、類似表格的數據源。語義計算簡化了這個問題。建議在每個 SOR 周圍放置一個包裝器以公開基礎數據以進行通用訪問。這種方法使 SOR 保持「原樣」，同時提供對數據的更廣泛訪問，以提高企業績效。
例如，OPC 標準為數據訪問、警報、事件、複雜數據、歷史數據等定義了不同的規範，每個規範都有自己的資訊模型來捕獲和提供對預期用途很重要的上下文。即使是一個簡單的模擬項目，例如壓力感測器，也是一個具有屬性並引用多個其他對象的對象（圖 2-3）。這些對象提供可能很重要的資訊，例如儀器範圍或工程單位。
圖 2-3：OPC UA 模擬項表示
再以 ISA 95 定義的對象為例，我們可以看到，雖然設備能力（圖 2-4）是一個複雜的對象，它包含一組設備能力屬性，但在任何時候查詢可能只需要其中的幾個. 此外，每個設備能力屬性本身都是一個複雜的對象，具有多個數據元素。
圖 2-4：ISA-95 運營能力模型
語義建模通過為用戶提供資訊和提取所需資訊的工具來幫助定義這些結構。很容易想像用戶或系統通過選擇「設備名稱」和設備能力屬性的「值」和「值的計量單位」屬性來查詢「能力」的所有設備能力屬性。
從歷史上看，根據底層實現技術，所有數據都可以通過與 SOR 的單個或多個事務來訪問。數據的格式從 XML 文檔（B2MML、BatchML）和二進位對象（OPC、Tibco、MSMQ）到 Web URI（URL 的通用版本），以及介於兩者之間的任何格式。與這些數據源建立溝通是不夠的；必須將特定於應用程式的格式轉換為通用的、基於標準的格式，該格式易於理解並可供所有客戶使用。沒有模型和相關行業標準提供的辭彙表，這些知識被鎖定在源 SOR 中。
現在，OPC 提供對數據的語義訪問和對數據的各種操作，例如，在指定時間範圍內對平均值、最小值和最大值進行語義確定。
語義模型
本節詳細介紹了語義模型在模型伺服器（見下文 “模型伺服器”）部署方式的例子。
正如萬維網聯盟（W3C）所定義的那樣，語義計算 “提供了一個共同的框架，使數據能夠跨越應用、企業和社區的界限進行共享和重複使用”。雖然萬維網的定義通常是關於共享文檔的能力，但語義計算提供了一個框架，以便單個數據元素能夠被共享，並且更容易被機器所理解。語義計算可以支援從各種不同來源呈現的數據的通用格式的概念。它還為理解數據關係提供了結構。這支援了對基於語義的網路數據進行請求，而不是依賴明確的（或隱含的）鏈接或參考。
語義計算架構，由 Tim Berners-Lee 定義，是一種分層結構，具有用於命名空間和模式定義的 XML 基礎，以支援通用語法。XML 基礎之上的下一層支援資源定義框架和 RDF 模式。RDF 是一種資源圖形表示的框架。儘管創建它是為了表示有關 Web 資源的資訊，但它可以用於各種其他數據類型。RDF 元素的核心定義是基於主謂賓形式的三元組。RDF 的機器可讀格式是 XML (RDF/XML)。
RDF 模型本質上定義了一個通過三元組描述的圖。RDF 模式（又名 RDF 辭彙描述語言）為 RDF 提供了額外的知識，例如可以使用的術語、適用的限制以及可以存在的其他關係。可以創建 RDF 模式來描述類的分類（與 RDF 中的資源相反）和資源之間的形式化關係（類型和子類）以定義簡單的本體。可以使用 Web 本體語言創建更複雜的本體。本體辭彙表是語義計算架構的下一層。
如前所述，本體通過定義的辭彙表和模型分類法提供對領域內概念（術語和關係）的理解。在特定的行業領域內，一個本體可用於支援多個應用程式。此外，可以創建一個本體來支援可以跨越多個領域的普遍適用的術語和關係。本體定義實體和關係來表示可以在適當的行業、領域和應用程式之間共享的知識。為了促進這一點，本體支援定義良好的屬性繼承模型。OWL 產生了這種更具表現力的語義，並指定了語義可以提供「實體之間更複雜的關係的機制，包括：限制類在數量和類型方面的屬性的手段，推斷具有各種屬性的項目是特定類的成員的手段，一個定義良好的屬性繼承模型，以及對基本語義的類似語義擴展。」 因此，可以捕獲更廣義的知識（稱為上層本體），然後可以進一步細化以支援特定領域（領域本體）。
對數據的語義理解取決於定義了術語和關係的通用辭彙表。RDF Schema提供了一個支援類型化和子類型化的辭彙表框架，以及定義數據類型的能力。更詳細的本體可以用OWL來創建，它依賴於RDF Schema，但在它自己的命名空間中提供額外的語義術語。OWL是通過物種或配置文件來定義的。提供限制術語使用的配置文件可以通過包括可以使用的推理引擎使實現更簡單。OWL Lite（針對主要需要分類層次和簡單約束功能的用戶）可用於分類學和簡單的約束；OWL DL（由於與描述邏輯的對應關係而得名）可用於完全的表達能力；而OWL Full可用於無表達能力的約束。
SQL 協議和 RDF 查詢語言 (SPARQL) 是一種用於查詢 RDF（包括 RDF Schema 或 OWL）的類 SQL 語言。SPAROL 用於查詢 RDF 圖模式並從選定的子圖中返回結果。SPARQL 可用於查詢本體以及實例化模型數據。SPARQL 結果可以以傳統形式呈現，以便在 Excel、MS SQL 報表服務等中使用。SPARQOL 是訪問高度分散的數據以利用傳統分析工具的工具。
ISO 15926是OWL等在石油和天然氣行業的生命周期數據管理中具體實施的一個例子。
模型伺服器
本節解釋模型伺服器作為語義模型的運行時伺服器的作用。
模型伺服器（或模型管理器）提供部署模型的運行時框架。模型伺服器必須支援許多關鍵功能服務來持久化和管理模型（本體）以及模型實例數據。它還必須為模型和實例數據查詢和更新提供工具和應用程式介面。接下來，模型伺服器的角色為上面討論的語義模型提供了執行能力。此功能是通過 Jena、Joseki、Sesame 和 Pellet 等開源項目提供的。
模型伺服器支援許多不同的持久化層，包括資料庫和文件（通常是RDF/XML格式，儘管N3和Turtle是另外兩種流行的表示方法）。雖然關係型資料庫可以用來支援RDF數據的持久性，但是對存儲在關係型資料庫（RDB）中的RDF數據（基於圖的數據）的查詢往往是低效的，而且在不改變資料庫模式的情況下改變數據模型的能力可能會喪失。三元存儲是一個專門為存儲和查詢RDF數據而設計的特殊用途的資料庫。其數據結構針對以三元結構存儲的數據進行了優化，三元結構對應於RDF的主語-謂語-賓語形式。Jena和Sesame都提供三元存儲。
當我們在這個層面上考慮模型伺服器時，還沒有要求理解持久化數據的結構。然而，當考慮到額外的模型伺服器功能時，對數據的理解就變得相關了。Jena和Sesame都提供了很好的例子。
首先，我們應該注意到，Jena提供的是 “一個構建語義計算應用的Java框架”，而不是提供一個完整的模型伺服器。具體而言，Joseki是Jena的一個開源子項目，它提供的伺服器能力為RDF數據提供一個HTTP介面，以及一個用於SPARQL查詢和更新的介面。此外，Jena提供了一個RDF數據的編程介面以及一個推理引擎。有了這個額外的能力，Jena確實需要 “理解 “RDF本體。推理或推論意味著能夠推導出本體沒有直接表達的事實。
Jena 提供了一個推理引擎來支援 RDF、RDFS 和 OWL 中的推理，但在某些情況下是不完整的。Jena 提供了一個可插拔介面，以便可以集成額外的推理引擎。例如，Pellet 是一個完全支援 OWL DL 並且可以插入 Jena 的開源 Java 推理器。憑藉這種類型的可擴展性，Jena 支援 RDFS 和 OWL 等語言，並支援從實例數據和類描述中進行數據推斷。
與 Jena 一樣，Sesame 提供了一個支援持久性、介面 API 和推理的 Java 框架。但是，Sesame 中的推理功能支援 RDF 和 RDFS，但不支援 OWL。對於一組 RDF 或 RDFS 數據，可以查詢 Sesame 並找到隱含資訊。由於也可以斷言任何可以推斷的內容，因此支援推斷的一種方法是在最初創建數據時將隱式資訊顯式添加到存儲庫中。這就是Sesame方法。
語義模型和模型管理中間件
本節介紹通過模型管理中間件提供的語義模型服務。
模型管理中間件的目的是提供一個框架，使創建以現實世界語義模型為中心的應用程式變得更加簡單，並支援實時操作數據和相關企業應用程式的集成。模型管理中間件框架的一個關鍵組件是用於部署、運行和管理基於先前描述的模型服務類型的語義模型的基本服務集。此外，中間件框架應該支援一類模型本體及其實例化。例如，本體可以基於行業標準（如 ISA-95、ISA-88 和 ISO 15926）並支援企業模型的定義，包括資產、每個材料轉換和相關的測量。
框架架構的另一個關鍵組成部分是支援模型感知適配器，允許整合各種類型的終端（OPC、資料庫和網路服務訪問應用程式，如CAD），以及這些終端和模型元素之間流動的資訊映射。
因此，中間件框架提供了兩種視圖：
- 參考模型（即本體）定義了模型中存在的類以及它們之間的關係，但不對應於任何特定的企業或資產。
- 實例化模型定義了直接引用現實世界實體的類的實例。它們填充有一組屬性（例如，位置、溫度）以及與模型中其他實例化實體的關係。
作為如何使用行業標準（ISA-88/95、OAGIS、MIMOSA 等）為現實世界建模的示例，請考慮以下示例，該示例基於塗料製造商的項目。
ISA-95 中的類：企業、站點、區域和生產單元被實例化。這些與附加的工作設備類一起用於定義從企業級別到特定工作設備級別的物理模型。
在工作設備層面，通常情況下，測量類被附加並映射到終端數據適配器和特定數據源。
一旦模型被實例化，並通過適配器層映射到終端，現在可以通過多種方式使用該模型來實現之前描述的業務收益。
在示例塗料製造企業中，需要獲取有關資產（例如儲罐）資訊的應用程式現在轉到單個位置（託管實例化模型的模型伺服器）以訪問該資訊。這包括有關儲罐的實時資訊（例如，溫度）、歷史資訊（例如，本周的平均溫度）或更複雜類型的資訊（例如，此儲罐或此類儲罐的未結工作訂單）。
模型伺服器提供：
- 這些應用程式使用一致的介面方法進行查詢。(例如，SPARQL）來獲得關於油罐的操作資訊，無論資訊的真正來源是什麼，如SCADA系統，操作資料庫，還是SAP或Maximo等應用程式。
- 儲罐的表示和圍繞儲罐的企業層次結構是一致的，並且是基於行業標準（ISA-95等）。無論在終端系統中使用的是何種基本格式，規範的形式都是保持的。
- 儲罐資訊現在很容易擴展，以引入未來被認為有用的新資訊。例如，一個與外部資產管理系統中的設備故障有關的新要求很容易與模型中的設備聯繫起來，這樣故障資訊就可以通過相同的模型背景進行查詢。該模型還提供了一個基於現實世界背景的 “畫布”，以簡化生產控制方面的配置，如計算關鍵性能指標（KPI）、定義操作事件所需的行動，以及為檢測到的問題生成警報。現在，資訊的類型可以與模型中的一個對象相關聯，然後很容易使其對模型中的上下文敏感。
- 同樣，語義模型中的關係現在使應用程式更容易橫向查看模型中的這些資訊，以回答在模型初始創建時沒有預料到的問題。例如，一家塗料企業包含可以提供相同功能但來自不同供應商的相似類型的電機。通過模型中的關係，例如「電機類型 A <相當於> 電機類型 B」，可以輕鬆生成一份報告，顯示當前生產中使用的所有類似類型電機的性能特徵（跨地區，如果需要），因此將來會做出更好的供應商決策。這樣做時，該分析得出的結論是，需要採取維護措施來更換一種類型的電機，因為另一種類型的電機性能要好得多。請注意，在此示例中，顯示等效性的關係不必出現在最初實施和部署的模型中。這些可以稍後根據新知識添加。
綜上所述，基於語義模型的應用集成能力擴展框架包括：
- 操作實體模型：操作實體模型（例如，罐、泵）及其關係以支援數據查詢，這些數據查詢可能包含在現實世界上下文中的許多不同系統中。這是一個強大的概念，它允許我們在實體（和底層系統）之間建立智慧，以支援針對故障預測、異常行為檢測以及產品品質問題檢測和預防等方面的分析和優化。
- 建立全局命名空間：建立通用的命名定義和資訊訪問方法，以便應用程式引用實體，例如資產，這些實體可能被多個企業子系統以不同的方式命名和標識，以保護應用程式不知道這些子系統的詳細資訊（例如、SCADA/DCS 系統、OPC 伺服器、SAP 或 Maximo）。
- 定義規範形式：定義規範形式以引用與企業中的運營實體相關聯的資訊。例如，用於混合油漆的罐的溫度可以從較低級別的 OPC 伺服器獲取，或者可以從 SAP 或 Maximo 獲取工作訂單。如前所述，行業標準可用於為該規範形式提供定義，其優點是可以建立在通用實體（例如設備、位置和人員）的公認定義和辭彙之上。
- 提供企業應用程式介面：為應用程式提供查詢和更新操作實體及其關聯數據的全局介面，使應用程式不需要知道哪個子系統擁有任何給定的實體或關聯數據（例如，OPC 伺服器、SAP 或 Maximo 等）。該應用程式基於與數據對應的現實世界模型提供了完整的企業數據視圖。這使得添加新的底層系統變得更加簡單，因為其細節隱藏在模型背後。
- 通過將配置關聯到已批准的配置集，提供協調所有 SORs 的更改並驗證所有 SORs 的配置一致性的方法。
- 根據 HAZOP 定義的當前值計算設施中的當前風險級別。
示例：映射到第4層的第3層的工作流中的製造運營和商業智慧
製造企業中存在的運營流程清楚地定義了與領域相關的特定本體。
例如，正在更改資產狀態的資產管理 SOP 將資產數據、更改原因和許多其他資訊塊鏈接在一起。對於使用此 SOP 的操作人員來說，它所操作的資訊是很好理解的。流程定義的分析快速生成如上定義的實體和關係，但在本地化的、特定於領域的語義上下文中。該流程不僅與多個系統交互，而且還具有確定的時間線和事件順序以及活動調用。每個接觸點都會為我們的資訊譜系生成一個條目，而工作流本身定義了它所運行的領域的本體。
在分析語義建模和沿襲時，製造企業中已經存在的流程提供了定義特定領域語義模型所需的豐富元數據來源。通過以電腦可執行形式捕獲這些模型並根據需要連接到 SORs，可以應用自擴展語義資訊模型。每個新的流程定義都用新的定義和關係擴展了模型。
這種方法的一個重要副作用是來自單個 SOR 的數據被每個使用它們的工作流上下文化。通常，根據操作過程中的使用情況，不同的本體會被添加到來自系統的相同數據中。同樣，如果每個工作流智慧地捕獲其執行的瞬態數據，就會創建豐富的沿襲資訊。
通過結合這兩個元數據來源，並在底層系統上的分層查詢功能，一個強大的製造業BI和OI的來源被創建。來自流程定義的元數據描述了實體和關係，可以以這樣的方式呈現給用戶，以幫助他們利用來自業務和運營流程的隱含背景進行查詢構建活動。
將所有的東西放在一起
以下示例基於模型平台構建的批處理管理系統，並利用多種建模技術使具有不同專業知識和需求的人員能夠輕鬆添加和調整功能。在這個例子中，平台的模型是兩種不同建模技術的組合：
- 數據建模：定義代表抽象、特定領域概念的數據。簡而言之：定義的辭彙表構成了數據建模的基礎。數據建模允許像 ISA-95 這樣的行業標準與本地化的、特定於業務的概念甚至系統和應用程式特定的定義共存。
- 服務建模：定義使用數據模型中的數據與 SORs 和人員交互的服務或活動。服務建模提供了由與各種 SORs 集成的服務實現者使用的強類型定義。
模型中定義的所有活動直接轉化為領域專家構建的圖形工具使用的特定於領域的構件。
定義後，模型構成了系統的基礎，為實施服務的開發人員、構建工作流的流程設計人員以及創建查詢以提取有關製造運營績效的相關資訊的資訊建模人員提供了構建塊。
模型定義作為高級的、特定於領域的構件呈現給流程設計者。提供隱式上下文定義的好處，形成了用於訪問操作資訊的平台語義模型的基礎。
當新的流程被定義並部署到系統中時，資訊模型被更新以包括流程定義中隱含的背景，並與系統的核心資訊模型的概念相結合。
圖 2-5 代表了一個簡單的 SOP，每次抽取一個批次的實驗室樣本時都會運行該 SOP。該 SOP 由計劃（達到設定點 1 後的每一小時）或由達到設定點 2 時設備的事件觸發。在此過程之後，系統會從批次管理系統中找到批次使用的當前設備。然後，它從產品生命周期管理 (PLM) 系統載入規範，用作下一步的說明，該步驟由操作員執行。
圖 2-5：實驗室樣品採集 SOP
下一步向操作員發出工作指令，其中包含來自批次和 PLM 的資訊，以進行實際取樣。由於此步驟是由人執行的，因此可能需要很長時間，但最終操作員會指示樣品已準備好並已交付給實驗室。在接下來的步驟中，系統會向實驗室技術人員發出工作指令，以檢查和驗證樣品是否已收到。最後一步在實驗室資訊管理系統（LIMS）中記錄樣品，接收由LIMS分配給樣品的樣品ID。在這幾個步驟的連續過程中，這個過程與以下幾項進行交接：
- 批次管理系統
- ERP/PLM
- 管理資訊系統
- PLC
- 人
這個簡單的過程捕獲了本體的許多元素和非常重要的資訊沿襲。圖 2-6 展示了可以從這個過程中提取的一些概念和關係。無論數據來自何處，都可以立即為系統構建查詢，例如：
- 用什麼設備生產一批？
- 誰拿了樣本？
- 樣本是如何採集的？
- 該批次使用什麼規格？
圖 2-6：實驗室樣品採集 SOP 本體
現在讓我們看看產生的資訊。每次流程運行時，都會記錄每一步的執行情況以及傳入和傳出活動的所有資訊，包括 SORs 中不存在的瞬態資訊。例如，根據來自 PLM 的數據，生成並呈現給操作員的「取樣程式」指令。它不存儲在與流程相關的任何記錄系統中。隨著時間的推移，PLM 數據可能會發生變化，從而妨礙我們了解向操作員提供的確切內容的能力。有了這些數據，用戶可以向系統提出以下問題：
- 取樣時間是什麼時候？
- 操作員何時實際取樣？
- 在最後一個月的運營中使用了哪些取樣程式？
- 運營商響應樣本請求平均需要多長時間？
此示例演示了傳統 SOA 建模如何與從可執行業務流程中推斷出的語義模型相結合，以解鎖通常無法從單個記錄系統中獲得的獨特資訊並將其置於上下文中。資訊模型的使用簡化了最終用戶與系統的交互，並為 BI 工具創建了數據源。
結論
解釋了語義模型和語義計算作為集成框架的關鍵組成部分在構建解決方案方面的價值。這種架構是在以數據、資訊傳遞和服務為中心的一些廣泛使用的著名解決方案架構的背景下討論的。語義模型被籠統地描述，然後通過一個詳細的例子加以說明，以顯示基於語義模型的整合框架如何作為構建解決方案的基礎，推動業務洞察力和效率。
語義模型在解決方案架構的下一步發展中發揮著關鍵作用，這些解決方案架構支援的業務目標是獲得對運營中所發生的事情的更完整的看法，並從該看法中獲得業務洞察力。基於ISO 15926和ISA-95等行業標準及其所有相關標準的語義模型和語義計算應用，使之更進一步，特別是應用供應商採用這些標準時。
