向基于語義模型的操作集成的演變

在過去的許多年里，已經定義了許多架構方法，用于系統集成以及其信息和流程的表示。這些方法包括面向數據、面向消息、面向服務和面向信息的方法。需要探討的問題是：

• 這些不同的方法有何不同和聯系？
• 從實時運營整合架構的角度來看，語義模型究竟適合在用哪里？
• 語義模型作為實時操作集成架構的一個關鍵組成部分，能提供什么價值？

1. 集中式應用的數據

從 1950 年到 1980 年，單體應用程序要求應用程序擁有所有數據。所有對數據的訪問都是本地的；所有定義、關系和知識都包含在應用程序中。企業中的部門化用戶擁有直接的領域知識，因此無需集成。

隨著計算機變得更加經濟實惠并在整個工業運營中激增，并且在終端設備中包含可編程邏輯控制器 (PLC) 和嵌入式計算功能，復合應用程序和系統的復雜性穩步增加。從 1990 年到現在，數據庫和客戶端-服務器架構曾經并且仍然用于允許多個并發客戶端與集中式數據存儲進行交互。

對于集中式數據存儲，集中式應用程序擁有其部分數據，其他應用程序直接調用以獲取信息或請求被調用應用程序執行某些操作。從歷史上看，這涉及通過應用程序接口 (API) 或遠程函數調用 (RFCs) 直接調用另一個應用程序。API 和 RFCs 包含在客戶端庫中，調用應用程序鏈接到該客戶端庫。在這種情況下，調用應用程序負責理解被調用應用程序的語義并負責所有數據轉換等。雖然從性能角度來看速度很快，但從維護角度來看，這種方法已被證明是昂貴的（而且很脆弱，因為一個應用程序中的故障會對所有直接相互連接的應用程序產生連鎖反應）。此外，在大多數情況下，數據驗證方法的記錄不充分。因此，基本數據的新消費者的新要求導致部署并行系統以捕獲附加數據，同時引入替代數據驗證規則。這種做法會產生多個“真實的版本”，因此數據的所有用戶都會花費 50-75% 的時間來對賬和驗證數據，然后才能充分信任數據以進行分析。隨著系統復雜性和點對點集成的增加，這種準備時間也在增加。語義計算的另一個好處是減少這種浪費的時間。

2. 以數據為中心的架構

擁有數據的集中式應用程序的替代方案是以數據為中心的架構。這顯然比直接連接的方法向前邁進了一步，因為應用程序不會直接相互連接以交換信息。以數據為中心的架構以相關業務和運營數據的單一定義為基礎，圍繞這些數據集成系統并開發應用程序。簡而言之，以數據為中心的架構為集中式數據存儲和使用該集中式數據存儲的規則和要求進行互操作的客戶端應用程序建立了一個通用數據模型。不幸的是，數據是從它們在各種 SORs 的端點復制的，其中應用了獨特的驗證規則。這也導致了多個“真實的版本”。

這種方法的一個早期例子是 SAP 的早期版本。這些 SAP 版本是（或至少看起來是）基本上是 40 多個應用程序套件，開發圍繞中央數據模型進行交互。盡管 SAP 支持外部應用程序的其他集成方法，但 SAP 已采用以數據為中心的方法進行應用程序內部通信，從而導致數據重復。

XML 之前的集成方法雖然本質上很簡單，但卻是用固定的數據結構實現的，這導致了一個相當緊密耦合的系統，其中所有系統組件都受到數據和數據結構變化的影響。這種架構方法通常會導致共享數據存儲中出現單點故障。從歷史上看，它在業務系統中不是關鍵的，但在運營中的實時工作流程應用中，這種方法破壞了運營系統。并造成巨大的效率和質量損失以及額外的成本。

3. 分布式應用的數據

隨著 1990 年至今網絡的進步，應用程序的復雜性發展為由多個通信（集成）應用程序構建的分布式系統。雖然早期的實現主要是試圖打破單體架構，但它們仍然基于單一應用程序模型并為特定領域設計。

最終，這導致了一類新的系統，其中集成了多個應用程序以創建新功能并使用每個應用程序中包含的數據來實現最初應用程序設計者最初不打算的功能。在這種情況下，每個應用程序都是一個 SOR—一個信息系統，它是給定數據元素或信息片段的權威數據源。

這些系統的分布式特性引起的問題很快導致人們意識到分布式架構是硬而脆弱的。需要一種更好的系統間通信方式來處理通信故障和應用程序可用性問題。這導致了松散耦合的面向消息架構的想法。

4. 面向消息的架構 (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 實現）。所使用的數據模型也可用于我們在上面“以數據為中心的架構”部分中討論的數據模型。

5. 面向服務的架構（SOA）

雖然 MOA 有助于緩解分布式系統中應用程序之間的通信復雜性，但典型的系統是通過點對點集成構建的，信息語義被隱藏、隱藏在實現中并且在運行時根本不可用。

SOA 為應用程序或應用程序組件之間的互操作添加了一種標準化方法。SOA 添加了在運行時可發現的接口契約的獨立于平臺的描述。這使得臨時客戶端能夠訪問公開的信息，如果不深入了解正在交換的數據和消息傳遞主干的結構, 這在 MOA 中有時是不可能的。不幸的是，并非所有信息都被公開，但該概念確實提供了一定程度的改進。有了嚴格的設計和治理監督，改進的程度是非常大的。

在 SOA 中，消費者（客戶端）為了一些明確定義的目的（例如，處理訂單）與提供者進行交互。信息是針對特定任務的，不會經常更改。當信息確實發生變化時，會添加一項新服務以保持與現有系統的“向后兼容性”。單個服務定義捕獲服務及其數據的語義，但無法提供有關系統的任何知識。

6. 面向信息的架構（IOA）

由于基礎設施的多樣性，前面的架構方法可以說是相輔相成的，并且在實際中一起使用是有意義的。事實上，任何不斷發展的架構都必須提供一種與現有系統有效共存和/或集成的方法。系統需要進化，重構根本負擔不起，也不現實。IOA 擴展了 SOA 以包括對被集成系統中信息的規范視圖和訪問，作為業務和運營智能和分析的基礎，支持流程優化和增強的決策制定。IOA 為市場提供了組合業務和運營流程的基礎，這些流程和運營流程圍繞單個信息模型共同創建復合應用程序。該模型定義了數據交換的規范形式并定義了數據中介的規范。這與上面的以數據為中心的方法不同，規范模型是交換模型，不一定是任何給定服務的模型。挑戰在于數據模型是為一組給定的問題設計的。將其重新定向以用于其他目的，需要類似于 SOA 的治理規則和流程。

另一方面，語義計算在元素級別定義數據，因此可以輕松創建用于特定目的的模型，而無需從適當的數據存儲中移動數據。語義計算并不適用于所有應用程序，但有許多應用程序是獨一無二的。一些關鍵示例是 (1) 強大、敏捷的治理，(2) 實時 HAZOPs，以及 (3) 整個設計、采購、施工、移交、啟動和調試階段以及運營和維護階段的數據管理。鑒于這些示例解決方案針對的是相對較小的一組人員和一組集中的長期運行的功能和任務，使用語義計算，通常的可擴展性挑戰不是問題。

IOA 通常包括 MDM（主數據管理）和 BI 和 OI 工具，作為 SOA 的補充。在他的數據集成博客文章 (http://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，工業自動化系統和集成--包括石油和天然氣生產設施在內的加工廠的生命周期數據的集成就是這樣一個標準定義。

所有這些信息都可以通過任何先前描述的架構以一種或另一種方式獲得。語義計算所做的是以對工業企業有意義的方式將獨立于提供者的上下文、規則和持續治理引入討論中。語義計算簡化了訪問數據的任務以及將有意義的動作與建模對象相關的事件相關聯。

7. 模型驅動架構

到目前為止，討論的重點是使用語義模型來支持運營系統集成，并且可以說，通過使用 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 內的數據和上下文，以豐富知識并提高每個組織的適應性和響應能力。

信息上下文的一個重要因素是它的脈絡，即信息變化的有序歷史。這在許多分析性應用中尤為關鍵。脈絡有助于回答諸如以下問題：

• 這批產品使用的是什么批次的材料？
• 我們何時得知的？
• 為什么會做出這樣的決定？

脈絡增加了重要的背景，將實例與事件和活動的時間線聯系起來。脈絡還提供了關于流程執行的持續時間的信息，無論是與設備、材料轉換、系統性能，還是人們的反應能力有關。例如，一個理想的系統會在以下時間段捕獲數據：

1. 在任何SOR內的創建（輸入制造產品的請求）。
2. 作為一項任務提交給操作員（告訴操作員去制造產品）。
3. 來自設備的狀態變化，表明該過程已經開始（現在正在制造產品）。

在此示例中，脈絡為流程性能和所有參與者提供現場計量。

由于變化發生在多個分布式系統中，沒有一個單獨的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），以及這些終端和模型元素之間流動的信息映射。

因此，中間件框架提供了兩種視圖：

1. 參考模型（即本體）定義了模型中存在的類以及它們之間的關系，但不對應于任何特定的企業或資產。
2. 實例化模型定義了直接引用現實世界實體的類的實例。它們填充有一組屬性（例如，位置、溫度）以及與模型中其他實例化實體的關系。

作為如何使用行業標準（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等行業標準及其所有相關標準的語義模型和語義計算應用，使之更進一步，特別是應用供應商采用這些標準時。