制造業尋求自動化設備和應用程序的集成，最好的榜樣就像即插即用的網頁瀏覽體驗那樣，完全不用通過人工來連接“物”，即插即用。為了達到這一理想狀態，包括工業自動化的許多專家和從業人員投入到這一復雜的挑戰中。然而歷經多年，到目前為止任何參與智能制造和工業4.0的人都知道，絕大部分的實踐還是碎片化的，局限于一些狹窄領域，更遑論跨領域的數據存取的互操作性。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?本文作者彭瑜，畢業于清華大學熱能工程系，教授級高級工程師，PLCopen中國組織名譽主席，中國自動化學會儀表和裝置專委會名譽常務委員，國務院特殊津貼獲得者；長期從事工業生產過程自控系統的設計、現場總線和工業通信在控制系統的應用研究工作。 ? ? ? 統而言之，目前在世界范圍內還沒有機構和組織能提供一種經過驗證的標準化方法，市場上的工業物聯網的產品也沒有辦法選擇一套公認的標的技術。換句話說，為實現這一基礎性問題的標準化還是在路上。

好在對此現狀表示不滿和憂慮的大有人在，有許多人和組織正在謀求突破。最近就有令人高興的消息傳來，微軟的Standards, Consortia & Industrial IoT總架構師向美國ISA的專業網站透露，微軟與西門子合作率先使用可被發現的數據模型（如OPC UA和W3C物聯網WoT標準），簡化并實現了工業現場設備數據標簽的自動變換。這一改工業物聯網、工業互聯網的項目中最花費時間又容易出錯的任務的現行做法，即：從手動將沒有標準化或沒有可被發現的數據模型的工業設備的數據標簽，自動變換為類似OPC UA這樣的標準數據的操作，從而開辟了即插即用，以便于在邊緣或云中進行進一步處理的前景。 ?

Vol.1

以互聯網為師

成功解決互操作性已經有了先例，大家所熟悉的網頁瀏覽，調制解調器是互聯網的網關。購買PC后，將其帶回家，標準化的好處立竿見影。首先，開箱即用的個人電腦通常都有一個以太網端口。PC連接到網絡調制解調器后，通過DHCP（Dynamic Host Configuration Protocol）獲得IP地址，并發現自己的網絡網關。然后，它會發現自己的域名系統（DNS）服務器是什么，并開始訪問來自全球各地的廣泛信息。所有這些機制都通過一個網關自動激活；對于大多數用戶來說，它是一種相當于魔法的技術。歷史的經驗證明，這種全球網絡只有在市場圍繞特定標準進行整合時才有可能實現。那么，人們渴望著在運用工業物聯網（IIoT）也可以使用類似的魔法技術的時候，是不是也應該思考選擇什么樣的標準化方案和路徑才有可能跨出成功的一步呢？我們可以預言，像IIoT這種需要在全球形成的網絡，只有在市場圍繞特定標準進行整合時才有可能實現，否則就是一個實現不了的“承諾”。 ? 如圖1所指出的在IIoT的許多服務和功能（諸如歷史數據存取、報警和通知、下達命令和控制、數據操作、數據分析和預測）中，實時數據訪問是最最基礎的，通常也稱為設備或流程遠程數據采集。這種類型的數據通常被歸類為時間序列數據，是非事務性（non-transactional）的，以真-假、數字或文本的形式存在。可視化或測量工廠層上正在發生的事態通常是數字化轉型的第一步。特別是從大規模地將各種設備從不同的地域集成接入IIoT，跨越數據互操作的鴻溝的重要性就益發顯現。如果我們運用IIoT最直接的用例即數據訪問有了標準化的解決方案，那么工業物聯網給制造商帶來了巨大的挑戰就有了成功的基礎，而不會出現由于解決不了從工廠現場存取數據這方面的問題，常常成為一些數字化轉型計劃的攔路虎，以至于胎死腹中。

圖1 ?工業物聯網的各種功能 （圖源：IEB網站）

Vol.2

MQTT和OPC?UA

沒有明確定義數據存取的互操作性

智能制造利用工業物聯網眾多目標之一是在企業中納入新的信息產生方和/或信息使用方時不需花費集成成本。簡化集成主要是通過在通信層和信息層實現一些知名標準的產品來實現，譬如OPC UA和MQTT。但是，這兩個標準是否足以實現數據存取的互操作性呢?

目前MQTT已成為實現“一次提供數據；可以到處分發”（provide data once; distribute everywhere）的架構。OPC基金會于2006年發布了第一個OPC UA規范，其中包括許多其他連接功能中的數據存取功能。其優點包括啟用非windows設備、具有標準數據類型定義的可瀏覽地址空間，以及具有死帶過濾條件的長輪詢機制。OPC UA在制造商中變得流行，因為除了現有客戶端-服務器范式，在2018年還增加發布-訂閱協議，將Pub/Sub連接添加到規范中，包括無代理（broker-less）協議的以太網和UDP和有代理（brokered）協議的AMQP和MQTT。OPC基金會繼續實現互操作性的目標，通過配套規范定義了標準對象類型，每個規范都利用核心數據定義來構造標準對象定義。

關于數據存取的互操作性，OPC UA和MQTT并未明確定義。如圖2所示，MQTT僅定義基本通信協議，其余所有堆棧都未定義，這些未定義的堆棧在圖中用紅色標注。這就造成選用MQTT時信息使用方為集成應用平添了沉重的負擔。

信息使用方面臨的集成障礙包括：熟悉信息產生方實現的主題路徑，以及確定應用程序是否可以通過最后遺囑功能監視信息產生方的健康狀況。

另外的挑戰有：選擇使用哪種QoS級別，信息產生者是在固定的時間間隔上發布還是僅在更改的數據上發布，等等。對集成商來說更可怕的是MQTT沒有傳輸數據的定義，因此信息使用方的應用程序不得不適應設備選擇的編碼方案、數據類型和對象定義。總之，MQTT僅僅定義數據存取模型中的通信協議層，在通信層以上的各層次均未定義的事實形成了如下后果，即如果選用MQTT是遠遠不能滿足數據存取的互操作性目標的。

OPC UA在數據存取模型的每個級別上都實現了標準化。雖然每一層的定義都優于其他技術，但問題出在在模型的每一層級其規范的組合都包含許多選擇（見圖2）。考慮到過多的通信協議、編碼方案、數據類型和對象定義，簡單地將OPC UA的信息使用方連接到OPC UA的信息產生者方并不能保證數據存取的互操作性，因為每個應用可能會在堆棧上選擇不同的選項。集成商必須仔細評估信息產生方的設備在每一層實現了哪些選項，并確保它與信息使用者方應用程序的功能相匹配。或者相反，集成商將了解信息使用方應用程序的功能，并不得不限制它可以使用的OPC UA產品的范圍。由此可見，如果目標是互操作性，指定OPC UA是不夠的。

圖2 ?MQTT和OPC UA的協議棧 （圖源：IEB網站）

Vol.3

OPC UA over MQTT

開辟了新路徑

或許OPC基金會已開始認識到，雖然在每一個層面有多種技術規范提供選擇可以增加靈活性，但其帶來的負面影響卻是增加了集成的成本和推廣的困難。于是，在2022年2月宣布，包括亞馬遜AWS、谷歌Cloud、IBM、微軟、SAP和西門子六家云服務提供商有些在目前的產品中支持基于OPC UA over MQTT，有些會在他們的開發路線圖中支持OPC UA over MQTT。這一聲明標志著這六家重要企業將與OPC UA over MQTT組合兼容。更令人印象深刻的是，這一聲明標志著企業內部多云架構的可能性，允許用戶無縫地將數據從一個云供應商轉移到另一個云供應商，實現云到云的互操作性。

OPC基金會在2022年4月的OPC國際日上指出，OPC UA over MQTT已有數千種實現。 對于需要識別OPC UA Pub/Sub技術的信息使用方應用的終端用戶和集成商，OPC基金會于2022年6月創建了一個市場，作為一個可供公眾訪問的網頁，允許基于功能、傳輸、應用配置文件和許多其他標準進行篩選。問題在于雖然已經保證了普遍的市場支持，但沒有宣布任何OPC UA over MQTT產品在OPC市場上市的時間表，包括來自六家云服務提供商的產品。對于需要商業產品的終端用戶和集成商來說，了解市場上可用的產品仍然是一個挑戰 與此同時，OPC基金會正在為構建語義語境的數據連通性做出努力。OPC UA FLC（現場級通信）計劃正在傳感器、執行器、控制器、企業和云之間創建開放標準語義語境的數據連接通信解決方案，滿足工業自動化、工廠自動化和過程自動化的所有要求。

OPC UA FX繼續取得快速進展，將最基本的工業通信現代化，并將主流計算數據概念推向工業邊緣。OPC UA現場級通信（FLC）計劃目標包括：在供應商、平臺以及目前尚不可知的范疇之間構建安全可靠的通信，實現從傳感器到企業及其他領域的互操作性。OPC基金會生態系統是統一的，由工業、IT、物聯網（IoT）和云組織組成，有超過65個聯合工作組參與，專注于定義和實現從工業現場設備（包括傳感器/執行器）到企業和云系統的標準語境和語義數據模型。 OPC基金會與清潔能源和智能制造創新研究所（CESMII）共同開發的全球可用UA云庫使OPC UA信息模型在全球范圍內的云端可用，為用戶提供查找和使用OPC模型的有效方法。這簡化了為語義數據模型提供可信源的應用工程。

還有一個可擴展性與互操作性相結合的問題。物聯網領域中的許多應用都利用MQTT作為一種輕量級方法向任意數量的信息使用方發布數據。然而，盡管MQTT支持可擴展性，但它本身并不能促進互操作性。另一方面，OPC基金會更理解集成的挑戰不僅僅是對通信層加以規范，因此他們規范了從通信層到信息層的完整技術棧。而且OPC基金會更重視信息層，其主要價值主張都是通過信息層來展開的，OPC ?UA專門用了4000多頁來進行信息定義，而通信定義只有不到300頁，就可見一斑。

Vol.4

MQTT/Sparkplug

也是一種解決方案

為了解決MQTT上缺乏信息互操作性的問題，Arcom/Eurotech于2015年創建了Sparkplug標準，以明確定義協議映射、編碼方案、公共數據類型，以及自定義對象結構的方法。它最初是的一個不知名的專有定義，用于幫助通過MQTT進行內部集成。很快在一年之內，Cirrus Link使用該技術為美國Inductive Automation公司的Ignition（一個流行的SCADA/MES平臺）開發了各種第三方模塊。Ignition的MQTT引擎模塊為數據存取互操作性建立了一個簡單而明顯的用例。

來自任意數量供應商的Sparkplug信息產生方將信息發布到標準MQTT代理。然后，這些信息立即可用，并在Ignition的內部標簽結構中枚舉為標簽和用戶定義類型（User Defined Types，UDT）。該功能最令人印象深刻的是，新連接的Sparkplug設備自動出現，無需終端用戶或集成商輸入。2019年，開源組織Eclipse基金會獲得了Sparkplug規范的所有權。由于Ignition允許任何人通過免費和功能齊全的試用下載來評估其平臺，包括任何業余愛好者都可以使用的免費Maker Edition，因此它的受歡迎程度持續增加。

Sparkplug從下往上構建堆棧，通過MQTT定義信息以實現互操作性，而OPC基金會則從上向下指定發布-訂閱功能以實現可擴展性。OPC UA工作組開始開發標準，通過其他用例擴展其現有的信息定義，如防火墻遍歷、控制器到控制器通信、控制器到云通信，或通過消息代理大規模連接信息產生方和信息使用方。之后，在2018年，OPC基金會發布了第14部分:Pub/Sub規范，MQTT已成為其四個通信協議中最受歡迎的，這主要是因為市場之前對樹莓派應用、家庭自動化項目或其他物聯網應用都用到MQTT，因而熟悉。此外，2021年5月發布的UA- IIoT - Starterkit僅支持MQTT，以至最近的OPC網絡研討會在提到Pub/Sub架構時主要討論OPC UA over MQTT。圖3給出Sparkplug與OPC UA over MQTT，看來OPC基金會正在工業物聯網的范疇內僅支持MQTT，不支持其它的協議。

圖3 ?Sparkplug和OPC UA over MQTT協議棧 （圖源：IEB網站）

Vol.5

W3C正在開發物聯網標準WoT

最近微軟的工業物聯網的總架構師向媒體透露，他們利用WoT的TD（Thing Description, ·物描述）作為架構模式，OPC UA作為接口，創建了一個參考實現，并以UA Edge Translator應用程序的形式演示這個概念。該應用程序運行在Docker容器中，便于部署在支持Docker或kubernetes的工業邊緣網關上。通過擴展UA Cloud Publisher的UI，僅一次單擊完成對UA Edge Translator的組態。目前，UA Edge Translator只處理Modbus設備，但添加其它設備也很方便。演示提供了SIEMENS SENTRON PAC電能表的WoT組態文件樣本，其中已經包含了將電能表映射到標準化OPC UA PROFI能源配套規范所需的信息。OPC UA PROFI能源配套規范直接從UA云庫加載。這一演示表明WoT開始步入工業物聯網數據存取互操作性的戰場。

萬維網聯盟（W3C）在交付全球公認的標準方面有著良好的記錄，包括構建Web的HTML和CSS。在其麾下2020年成立了W3C物聯網（WoT）工作組，其任務是通過構建模塊的規范來對抗物聯網的碎片化，從而實現跨物聯網平臺和應用領域的物聯網設備和服務的輕松集成。作為現有標準的補充和增強，W3C WoT提供了標準化的元數據和其他可重用的技術構建塊，目標是使跨物聯網平臺和應用領域的集成變得容易。其方法是通過遵循著名且成功的Web范式，通過提供一套標準化的技術構建模塊，幫助簡化物聯網應用開發，增加靈活性和互操作性，特別是對于跨域的應用；同時支持已建立的標準和工具的重用。 通常，在現有的物聯網項目中，開發人員必須面臨以下挑戰：必須了解來自不同供應商和制造商的不同物聯網系統和服務組成的異構技術環境（參見圖4）。這種多樣性包括通信協議、有效負載數據交換的數據模型和安全需求的變化。物聯網應用通常是針對一個狹窄而具體的用例開發，在其生命周期內，這些應用難以擴展、維護或重用。

WoT規范提供了一套標準化的技術構建模塊，引入了一個基于屬性、事件和動作的簡單交互抽象。屬性包括傳感器的測量值（只讀）、組態參數（讀/寫）、狀態（只讀或只寫）、或計算結果（只讀）、等等；動作包括機器啟動/停止、淡入/淡出、長期持續的過程（打印文件、隨時間改變屬性等）、等等；事件包括現場報警、門已開、數據已在流動、等等。任何物聯網網絡接口都可以用這種抽象來描述（參見圖5）。通過使用這種抽象，應用程序可以有一個通用的支撐（a common anchor）來檢索物聯網服務的元數據，了解可以訪問哪些數據和物聯網服務的功能，以及如何訪問這些數據和服務的功能。物聯網設備的元數據，包括實現這種通用抽象所需的所有信息，都被記錄在所謂的WoT的 TD（物描述）中。TD是W3C物聯網中的一個核心構建塊，可以被視為物聯網實例的入口端（很像網站的index.html）。它提供以下信息：相關的數據和功能，使用哪種協議，數據如何編碼和結構化，使用安全機制控制存取，以及進一步的機器可讀和人可讀的元數據。TD用JSON-LD表示，可以由物聯網設備本身提供，也可以托管在外部的存儲庫中，如TD目錄。

圖5 ?TD的概念圖（圖源：WoT網站）

總的來說，WoT是一個協議無關的方法，并提供了一個公共機制來定義如何將特定的協議（如MQTT、HTTP、CoAP或Modbus）映射到WoT的交互屬性-動作-事件抽象中（參見圖6）。這個映射和協議特定的元數據是由WoT綁定模板提供的。特定協議的綁定模板為客戶端如何通過相應的面向網絡的協議接口來激活每個WoT交互抽象提供了指導。

圖6 由WoT物描述TD可推斷出WoT腳本API （圖源：WoT網站）

可選的WoT腳本API構建塊定義了一個ECMAScript（JavaScript）API，它可由WoT物描述規范推斷出來，并支持WoT交互抽象。它定義了行為實現和基于腳本的WoT運行時之間的接口。但是請注意，WoT的實現并不局限于腳本環境。Java或C/ c++中的編程語言API也可以從WoT的腳本API中派生出來。

Vol.6

適應工業物聯網應用的

數據存取模型

其實從應用的角度看，工業系統需要實時、同步、協同的業務處理和制造過程，其重要基礎就是全局的數據共享，而不是數據交換。這就要求有一個從數據存取架構的視角建立的數據存取模型，能夠實現數據/信息的使用方與數據/信息的產生方解耦，就如在互聯網中通過TCP/IP模型實現了數據/信息的存取與具體設備的地址脫鉤那樣。有人設想了這樣的數據存取模型（見圖7）。

圖7 設想的數據存取模型 （圖源：IEB網站）

要使數據/信息的使用方與數據/信息的產生方解耦，一個重要前提是實現點對基礎架構的通信連接，而不是點對點的連接。在“點對點”體系結構中，信息使用方必須發起的連接數量與系統中信息產生方的數量直接相關。信息產生方的數量還規定了必須在信息使用方一側設計的不同協議和客戶自定義語法解析功能的數量。因此，隨著信息產生方數量的增加和實現的協議數量的增加，點到點模型變得不可持續。 當從所有工廠設備收集信息時，企業系統受到了所需通信協議數量的挑戰。對于應用程序來說，要做到跨所有設備且與任何協議通信，負擔是在太大了。人們一直在努力通過將過多的通信協議通用化來消除這種負擔，但一涉及到產品采用，那又是另外一回事了。工業自動化制造商不會只優先考慮標準化協議，而是繼續在EtherCAT、PROFINET和EtherNet/IP等原生現場總線技術上進行創新。幾乎所有的設備都繼續支持Modbus/TCP來交換數據，有些還增加了IO-Link。一些設備已經發展到包含OPC UA服務器，但即使是OPC基金會成員的工業自動化制造商仍然省略OPC UA服務器。一些集成商和終端用戶正在等待最新的設備規范OPC UA FX，期望它將導致更大的市場采用。相比之下，其他人嚴重懷疑在工業設備這一級別是否有可能采用標準協議。考慮到各種訴求和復雜情況，采用W3C的WoT解決方案是一個可行途徑。

結束語 ? ? ?

時至今日我們尚不能看到適合全球的工業互聯網和工業物聯網的數據存取互操作性的明朗格局。我們盼望能在此方向加快進程，讓企業在納入新的數據/信息產生方或數據/信息使用方時不需花費或極少集成成本。 ? ?

編輯：黃飛