作為OPC基金會中國免費技術(shù)顧問，在10月14日的中國OPC Day在線會議為大家分享一下OPC UA FX的進程。這里FX即Field eXchage。也和基金會中國的張譽有些深刻的感受--即，OPC UA基金會在推進數(shù)字化標準與規(guī)范方面的工作值得借鑒。每一年的OPC Day都能看到歐美的自動化同仁們，以及來自大型終端用戶如歐萊雅、大眾汽車、巴斯夫等，大型IT企業(yè)Microsoft、華為、Cisco、Intel等，他們都在積極推進著這個關(guān)系著未來制造業(yè)集成進程的規(guī)范與標準。從OPC基金會的工作我們可以看到很多值得借鑒的地方。

　　大背景-產(chǎn)業(yè)數(shù)字化中的難題

　　關(guān)于數(shù)字化轉(zhuǎn)型，這里牽扯到的話題是，我們究竟需要數(shù)字化轉(zhuǎn)型，還是轉(zhuǎn)型需要數(shù)字化?

　　圖1-數(shù)字化推進中的困境

　　關(guān)于產(chǎn)業(yè)推進數(shù)字化進程中的幾個困境：

　　1.互操作標準的欠缺

　　數(shù)字化架構(gòu)的實現(xiàn)，無論提出邊緣計算、數(shù)字孿生、工業(yè)互聯(lián)網(wǎng)、工業(yè)物聯(lián)網(wǎng)、智能制造架構(gòu)。這些實現(xiàn)的顯著特征是“集成”，數(shù)據(jù)、通信、應(yīng)用的基礎(chǔ)連接需求，必須建立在體系性的標準基礎(chǔ)之上。這是共識，在多個系統(tǒng)間如數(shù)字化設(shè)計的CAD/CAE/CAM/CAPP，以及現(xiàn)場運營技術(shù)類的系統(tǒng)如PLC/DCS/SCADA和管理系統(tǒng)如ERP/CIMS/MES，以及應(yīng)用的Cloud/Edge這些多功能場景中的集成，必然遇到這個交互的難題，如果沒有統(tǒng)一的規(guī)范與標準，這是無法想象的。

　　歐美構(gòu)建這些架構(gòu)的首要問題就是標準的問題，因此，OPC UA基金會聯(lián)合了眾多的協(xié)會組織，包括中國的SAC/TC124、IEC、VDMA、I4.0組織、IIC、ECC(中國邊緣計算組織)，以及各個現(xiàn)場總線基金會、OMG(DDS)、MQTT等統(tǒng)一來構(gòu)建這些標準連接問題。

　　2.工程成本如何降低的問題

　　目前國內(nèi)推進的工業(yè)互聯(lián)網(wǎng)企業(yè)，就其現(xiàn)實數(shù)據(jù)報表來看，鮮有能夠盈利的。這個問題的關(guān)鍵就在于無法解決應(yīng)用的“可復(fù)制性”問題—除了雄心勃勃準備從事該領(lǐng)域的大量企業(yè)，在資本的推動下，熱火朝天的干了也有不少年頭了。

　　可復(fù)制性的關(guān)鍵在于標準與規(guī)范，缺乏標準與規(guī)范會大幅影響工程實施成本，因為，大量的數(shù)據(jù)需要連接、配置、開發(fā)接口并進行測試，如果沒有統(tǒng)一的規(guī)范與標準，那么這就會成為一個“勞動密集型”工作，就會帶來大量的人工成本，而尤其是IT類工程師的成本又較之市場平均工程師成本高的情況下。

　　3.模塊化編程

　　就實現(xiàn)層面來說，面向?qū)ο?、模塊化封裝的方式構(gòu)建了系統(tǒng)的各個應(yīng)用，那么，整個應(yīng)用是會快速實現(xiàn)的，也可以被復(fù)用—但是，這就是難題。

　　經(jīng)常和張譽討論起這件事情，OPC UA的角色其實非常關(guān)鍵，因為，在工程實施的時候，數(shù)據(jù)是一個獨立體，而應(yīng)用則千差萬別的接口方式，那么，OPC UA提供了一個數(shù)據(jù)的標準封裝框架，使得對于不同的應(yīng)用而言，都可以基于相同的方式來調(diào)用數(shù)據(jù)。OPC UA首先就是一個容器來對數(shù)據(jù)進行了結(jié)構(gòu)化和標準化的處理。

　　其次，OPC UA又將在不同場景中的通信連接方式予以了支持，這包括了C/S、Pub/Sub的不同機制下的通信協(xié)議支持，幾乎涵蓋了各個常用的通信規(guī)約，如OPC UA對現(xiàn)場總線的支持、對TSN、MQTT、DDS這些的支持，都是為了解決在不同的領(lǐng)域所習(xí)慣和常用的通信機制。

　　OPC UA提供了特別的命名空間(Name Space)來為數(shù)據(jù)提供了數(shù)據(jù)存儲的格式、訪問層級、角色、授權(quán)與驗證機制、類型、參考、調(diào)用等，這些使得數(shù)據(jù)具有了“高完備性”的結(jié)構(gòu)，這帶來的問題是它看上去會有點過于“重”的結(jié)構(gòu)。

　　不過，OPC UA比較好的解決了這些問題，它基于SoA，其實，這就是一種“關(guān)注點分離”的模塊化編程思想，它使得應(yīng)用和數(shù)據(jù)分離，OPC UA數(shù)據(jù)提供服務(wù)給不同的應(yīng)用來“共享方式訪問”，避免數(shù)據(jù)與應(yīng)用的耦合關(guān)系帶來的復(fù)雜性，以及不同應(yīng)用間的潛在耦合風(fēng)險。

　　另外，OPC UA提供了一種“動態(tài)”的交互模式—這使得系統(tǒng)具有“動態(tài)”運行的特征，滿足制造現(xiàn)場中的變化，例如在數(shù)字化仿真系統(tǒng)和運行系統(tǒng)間的動態(tài)模型交互，可以有助于實現(xiàn)數(shù)字孿生運行、邊緣計算的架構(gòu)運行—因為，它自身也包含了對傳統(tǒng)現(xiàn)場總線、TSN、Pub/Sub機制的高實時性任務(wù)交互的需求。

　　當(dāng)然，OPC UA的確比較重，這也在于OPC基金會的野心實在龐大，想將整個制造納入其中—并且，為何要將FLC納入其中，因為，如果要實現(xiàn)制造現(xiàn)場的動態(tài)性能，就得把現(xiàn)場層通信納入其中。

　　4.信息安全問題

　　由于集成，必然牽扯到了IT與OT系統(tǒng)的相互訪問，而IT系統(tǒng)本身采用的通用訪問機制也帶來了端口的開放，帶來對底層數(shù)據(jù)訪問中的信息安全問題。因此，OPC UA信息安全采用了證書和授權(quán)機制，這使得信息安全得到保障—這也是非常重要的一環(huán)。

　　除了信息安全(Cyber Security)，另一個在工業(yè)里需要被考慮的安全是功能安全(Functional Safety)，確保生產(chǎn)裝備的人身安全機制。

　　因此，本文，主旨討論技術(shù)標準與規(guī)范，順便展開講一些觀點與看法。

　　圖2-OPC UA FX所描繪的通信全景

　　圖2是最為經(jīng)典的-所有人都看過的，不宜多講，列為看官，看圖生義，就知道未來工業(yè)通信的目的是從管理的架構(gòu)延伸到分布式計算的架構(gòu)。

　　其實，所謂的數(shù)字化轉(zhuǎn)型，僅從數(shù)字化這個視角，它就是要將原有的架構(gòu)擴展到分布式架構(gòu)上，而意味著不僅技術(shù)，通信，也包括了企業(yè)內(nèi)的數(shù)字流動、業(yè)務(wù)的靈活性組合、服務(wù)的靈活組合問題，即，局部單元的智能，以及，其組合形成的對市場的應(yīng)對能力。

　　本文僅討論標準與規(guī)范，只是順便想提醒一下我們討論數(shù)字化轉(zhuǎn)型的時候，在商業(yè)邏輯上，技術(shù)、規(guī)范均是要服務(wù)于業(yè)務(wù)。轉(zhuǎn)型，是業(yè)務(wù)模式的轉(zhuǎn)型，企業(yè)應(yīng)對市場能力的轉(zhuǎn)型，那么，技術(shù)架構(gòu)只是滿足這種變化—我們講這種技術(shù)的演進，只是在業(yè)務(wù)轉(zhuǎn)型發(fā)生后的匹配，而不是試圖用技術(shù)去指揮企業(yè)的數(shù)字化轉(zhuǎn)型。

　　圖3-參與OPC UA FLC倡議的企業(yè)

　　圖3是主要OPC UA FLC～現(xiàn)場級通信倡議發(fā)起者，兩者的關(guān)系在于FX是FLC制定的具體規(guī)范。FLC由自動化業(yè)界的知名企業(yè)、以及Intel、Huawei、Cisco主要推進的，而國內(nèi)的廠商似乎只有來自IT業(yè)界的華為一家。前年的時候，某圈內(nèi)朋友還表達“國內(nèi)自動化廠商似乎還沒有積極參與到國際規(guī)范與標準中去”。另一方面就是國內(nèi)好像信誓旦旦要為工業(yè)通信制定規(guī)范與標準的，反倒不是自動化企業(yè)，而是來自于通信領(lǐng)域的企業(yè)。這一方面說明了或許在國內(nèi)OT端企業(yè)的專業(yè)話語權(quán)并不重，亦或企業(yè)都只是忙著賺錢，也沒空搭理所謂的未來通信規(guī)范與標準。由IT廠商建立工業(yè)通信規(guī)范與標準，我只是想說“此通信，非彼通信”。做了標準，和規(guī)范，需要有工業(yè)領(lǐng)域的企業(yè)參與并在產(chǎn)品研發(fā)中來支持。

　　后面我會總結(jié)一下，制定標準這件事情，看來也不是一個簡單的事情，我們對于標準，如老尹說的算是個“指導(dǎo)”、“管理辦法”—定性而不定量，有較大解釋空間的描述性、建議性、指南性，但缺乏在實際層面的可操作性、落地執(zhí)行方面的內(nèi)容-好處就是快速就可以制定標準。

　　OPC UA FX中的關(guān)系

　　而根據(jù)FLC所倡議的規(guī)范，即，OPC UA FX，它是OPC UA Field eXchange的簡寫，從其名字即是將OPC UA涵蓋至現(xiàn)場層，即，OPC UA不想僅停留在通信層，也想涵蓋網(wǎng)絡(luò)協(xié)議的統(tǒng)一規(guī)范，可謂志向遠大。OPC UA FX聽上去感覺是對OPC UA over TSN的新稱呼，倒也不完全是，因為，OPC基金會想法并不局限于TSN，這個FX會涵蓋5G、Wi-Fi 6這樣的無線通信，可以被稱為OPC UA over 5G、OPC UA over Wi-Fi 6，這些都被稱為Field eXchange。

　　因此，有線和無線都會成為基礎(chǔ)。目前TSN的確被賦予了更高的優(yōu)先級，畢竟5G的性能和成本尚未對于工業(yè)有好的經(jīng)濟性，只是在測試驗證階段。而Wi-Fi 6，也在測試中，作為在OPC UA基金會的未來技術(shù)選項里，做了羅列。如圖4，OPC UA FX在整個連接中的作用。

　　圖4-OPC UA FX所處的位置和作用

　　OPC UA FX進展

　　OPC UA FLC作為倡議者組織，由主要的自動化廠商發(fā)起，在初始階段，它主要聚焦在C2C，即，Controller to Controller階段的通信。而在2022年7啟動C2D和D2D領(lǐng)域的規(guī)范，使得TSN延伸至Controller to Device 及Device to Device的階段。

　　TSN目前的國際標準IEC60802似乎進展比較慢，因為2020-2022年這期間疫情的緣故，以及很多企業(yè)人員的工作不穩(wěn)定，IEC60802似乎并未完成其IA Profile的規(guī)范工作，因為目前才是CDS文件，尚未進入FDS文件狀態(tài)。

　　圖5-FX工作范圍和邊界

　　如圖5，OPC UA FX涵蓋的是底層網(wǎng)絡(luò)和其IA-Profile的定義，我們從這個結(jié)構(gòu)上可以看到，OPC UA基金會的想法就是用OPC UA的應(yīng)用信息模型來作為應(yīng)用層架構(gòu)，然后集成網(wǎng)絡(luò)層的TSN/5G，這個想法很大，也即，OPC UA+TSN，會被新的FX規(guī)范所定義。

　　OPC UA FX的規(guī)范簡要展開

圖6-OPC FX系列規(guī)范

　　如圖6，OPC UA FX第一批規(guī)范，也即在2022年發(fā)布的Part 80-84這個集合，主要還是針對C2C的，即包括80-84五個部分，其中80，82在去年進行了介紹。此次主要還是交流一下兩個重要的規(guī)范，81和83，一個針對自動化組件本身的資產(chǎn)、功能模型，和離線工程的規(guī)范。

　　Part 80：主要定義了OPC UA FX基本概念

　　Part 81：自動化組件的資產(chǎn)和功能模型的協(xié)調(diào)，統(tǒng)一的自動化組件信息訪問，獨立于控制器或設(shè)備廠商，適用于PLC或傳感器、工廠或過程自動化

　　圖7-自動化組件的信息模型參考

　　在自動化系統(tǒng)的組件中，包括了物理對象、軟件、固件、授權(quán)，信息包括廠商、產(chǎn)品、固件版本、序列號等。實際上就是給上位或水平系統(tǒng)提供了誰家的控制器、軟件版本等基本信息，如圖7所示。

　　圖8-自動化組件的邏輯連接

　　其次，如圖8，就是提供了這些自動化組件的驗證(資產(chǎn)與功能性實體)方法、擁有者、應(yīng)用配置等。再者就是這些組件，如PLC、驅(qū)動器支持的交互機制，基于OPC UA Pub/Sub機制來傳輸，信息包括功能安全、信息安全、TSN的QoS(優(yōu)先級、保護帶寬、延時、截止時間)、不同的傳輸機制(以太網(wǎng)、UDP、AMQP、MQTT)、連接的監(jiān)測。

　　Part 83-離線工程

　　圖9-離線工程信息規(guī)范與參考

　　在離線工程方面，如圖9，F(xiàn)X包括了離線描述器用以描述能力、功能，配置自動化組件的資產(chǎn)，自動化系統(tǒng)必要開發(fā)、調(diào)試、維護階段的信息。

　　這個開放的封裝文檔采用ECMA-376，也就是openXML的格式來進行建模和附件封裝，內(nèi)部與外部關(guān)系、數(shù)字簽名。信息模型描述采用了Automation ML規(guī)范，一種面向車間工程的XML-based數(shù)據(jù)交換格式，也是IEC62714的標準。工程附件包括其它信息模型的集成，如PLCopen、YANG，文檔、手冊、圖紙。

　　就是說，這些是在離線工程中，對自動化組件的相關(guān)信息、描述、圖紙、文檔等進行統(tǒng)一規(guī)范。

　　應(yīng)用場景分析

　　OPC UA FX，或者之前稱為OPC UA over TSN的，在很長一段時間里，其實，很多人都會疑惑它的應(yīng)用場景。其實，如果TSN你覺得用不到，那么大概率上來說：

　　(1).數(shù)字化還未到達較為深入的階段

　　后來發(fā)現(xiàn)，大家為什么不用OPC UA over TSN，而是因為其實很多應(yīng)用，它在OPC UA +Ethernet這個任務(wù)等級上就可以解決，比如OPC UA在標準以太網(wǎng)上，其實也可以達到10mS倍數(shù)等級的，而且，在有些時候，如前段時間發(fā)現(xiàn)我們的工程師在OPC UA的訪問上，可以達到2mS的循環(huán)，這還超出了我的原來的想像。

　　在什么場景下會需要TSN?

　　->真的是實現(xiàn)了互聯(lián)，以及高速的推理應(yīng)用這個場景;

　　->動態(tài)的數(shù)字化應(yīng)用，即時分析與應(yīng)用;

　　(2).大概你還沒有了解OPC UA FX的方案就是為了你的應(yīng)用而設(shè)計;

　　因為，你可能在尋找方案，但因為目前TSN的很多方案其實，還都在測試階段，還不是成熟到所謂的“拿來即用”，因此，對于在測試會覺得還沒完成，而對于沒有測試的一般都在拿其它的方案在測試，但是，還沒有尋找到最佳的解決方案。而當(dāng)OPC UA+TSN比較成熟的方案出來后，這個架構(gòu)才會發(fā)揮力量。

　　(3).這幾年進程的確有點慢。

　　TSN最近幾年進展比較慢，與TSN是一個基于IT思想而設(shè)計的標準，它的形成過程不同于以往，因為IEC其它的通信標準，基本上都是傳統(tǒng)OT的“先有問題，再尋求方案，最后標準化”的思路。TSN是按照先有技術(shù)，然后去推進場景應(yīng)用的IT思維來設(shè)計的。

　　另外，TSN被稱為“歷史上，首次，各家自動化廠商要來協(xié)同構(gòu)建的標準”，TSN與以往的由某個主要廠商已有的標準來推進不同。這是第一次大家居然競爭企業(yè)坐在一起來商討如何面向未來構(gòu)建一個新的工業(yè)通信架構(gòu)。因為，大家意識到，原有的玩法，在未來不會那么奏效。

　　這使得TSN較之以往的通信標準需要花費更多的溝通與協(xié)調(diào)時間，但是，好在它是有基礎(chǔ)的，即早期的IEEE802.1Q的基本規(guī)范上。因此，相對來說，它又算快的—因為，畢竟第一次Shaper起草工作組會議還是在2016年，到2019年左右各家已經(jīng)出了原型機，按說速度也夠快的。

　　但是，目前來看，各家的問題都聚焦在了“軟件”問題上，即，如何更為有效的對TSN網(wǎng)絡(luò)進行配置，因為，TSN網(wǎng)絡(luò)不同于以往的工業(yè)通信網(wǎng)絡(luò)。傳統(tǒng)工業(yè)通信網(wǎng)絡(luò)基本上為了“確定性”，采用了非常簡化的思路，就是“輪詢”、“令牌”，因為，這種在軟件上容易實現(xiàn)，配置簡單。但TSN采用了復(fù)雜的排隊和“橋接”網(wǎng)絡(luò)模式，這使得系統(tǒng)復(fù)雜性會有所提高。

　　網(wǎng)絡(luò)動態(tài)配置會是個關(guān)鍵問題，需要一個好的配置算法來實現(xiàn)高效的配置，在網(wǎng)絡(luò)出現(xiàn)變化時，能夠動態(tài)優(yōu)化網(wǎng)絡(luò)的數(shù)據(jù)流調(diào)度。因此，TSN網(wǎng)絡(luò)是一個需要高度智能的網(wǎng)絡(luò)配置系統(tǒng)，還有，這個必須要做到“User-friendly”，而這又是個難題，要把復(fù)雜的網(wǎng)絡(luò)問題，轉(zhuǎn)換為與應(yīng)用無關(guān)、與制造商無關(guān)的進行配置，這本身就需要特別的“標準”，而IEEE/IEC6082的工作進程也使得這項工作推進有點慢，最近幾年疫情也使得大家工作都不那么穩(wěn)定有序。

　　圖10-OPC UA over TSN的應(yīng)用場景

　　在圖9中，可以看到首先由TSN來采集現(xiàn)場數(shù)據(jù)，包括I/O、視覺、運動控制軸(目前C2D剛開始)，然后經(jīng)由OPC UA over TSN傳輸?shù)竭吘壙刂破鲗樱缲惣尤R可以采用Hypervisor的工業(yè)PC來作為一個處理和分析單元。在這個架構(gòu)中，處理和分析單元，主要運行AI、調(diào)度、優(yōu)化類的程序，然后解析出要去執(zhí)行的調(diào)整，通過TSN網(wǎng)絡(luò)來下發(fā)給現(xiàn)場設(shè)備。而對于長周期的模型訓(xùn)練，OPC UA也提供了到云端的連接規(guī)范(后續(xù)可以另行分享)。

　　在OPC UA over TSN的應(yīng)用架構(gòu)中，首先是有集成的架構(gòu)實現(xiàn)，然后是高速動態(tài)的質(zhì)量分析、快速動態(tài)的調(diào)節(jié)執(zhí)行行為，構(gòu)成一個控制、邊緣分析下發(fā)執(zhí)行的大閉環(huán)—這個閉環(huán)，主要聚焦在全局的質(zhì)量優(yōu)化、改善上。

　　關(guān)于標準的問題

　　我也看過了大量的IEEE/IEC關(guān)于各種標準的制定文件，能觀察到這些標準的制定，其實是個非常嚴謹?shù)墓こ踢^程。圖10作為參與一些標準工作，以及對照OPC、IEEE的標準工作有感而發(fā)。

　　圖11-對于標準制定的思考

　　首先，標準的制定，包括參考IEEE802.1Q系列的TSN標準，以及OPC 基金會的標準?？梢钥吹剑瑯藴实闹贫ㄍ耆谝粋€工程開發(fā)過程的流程來實現(xiàn)，先要去分析需求，制定一個目標，然后要拆解為各種場景，因為即使工業(yè)也分為離散、流程、批處理等多種業(yè)務(wù)場景，然后要去解析，解決這些問題的機制，針對這些問題拆分為硬件、軟件、網(wǎng)絡(luò)拓撲、配置工具與方法等。因此，制定這個標準的過程本身就是一個非常嚴謹?shù)墓こ涕_發(fā)過程。

　　因為，受制于在工程思維方面的訓(xùn)練，以及在技術(shù)研發(fā)水平上的制約，感覺很多時候，我們在制定標準的時候，會陷入到對“詞句”的解析上，因為很多都是跟標。而自行制定的標準，往往照貓畫虎，但并非基于需求的工程過程來實現(xiàn)，在形式上像是標準，但在指導(dǎo)性，實現(xiàn)可行性尚有欠缺。

　　協(xié)作問題，標準制定還是需要較好的協(xié)同工作機制，這需要本身具有強的研發(fā)項目管理水平。專家方面，還是需要一線的工程技術(shù)人員參與比較好。另外，在這些標準的制定過程中，行業(yè)的標準，應(yīng)該多方協(xié)同，包括各自的角色分工：

　　(1).終端生產(chǎn)企業(yè)：目前大部分的智能制造、工業(yè)通信標準，最終用戶是使用者，因此，他們需要從需求端來提出意見。國內(nèi)很多標準，缺乏來自終端用戶的聲音，如果僅是自身行業(yè)人制定標準，那么，難免有點“閉門造車”的問題。

　　(2).裝備企業(yè)：作為系統(tǒng)的實現(xiàn)者，或者技術(shù)的載體，裝備需要更為明確在其自身的實現(xiàn)上的需求。

　　(3).技術(shù)提供者，像自動化、系統(tǒng)、軟件類廠商，作為技術(shù)提供者，應(yīng)該去按照需求來解析模塊，并對其進行分布開發(fā)。提出規(guī)范與標準的實現(xiàn)方法。

　　(4).標準專家：基于標準的標準來對整個標準制定過程的程序、定義、邊界、行文、引用等進行規(guī)范。

　　參與的企業(yè)要具有廣泛的代表性，而專家身份也需要來自技術(shù)、工程管理，眾多利益相關(guān)者必須深入?yún)⑴c其中。