作為OPC基金會中國免費技術顧問,在10月14日的中國OPC Day在線會議為大家分享一下OPC UA FX的進程。這里FX即Field
eXchage。也和基金會中國的張譽有些深刻的感受--即,OPC UA基金會在推進數字化標準與規范方面的工作值得借鑒。每一年的OPC
Day都能看到歐美的自動化同仁們,以及來自大型終端用戶如歐萊雅、大眾汽車、巴斯夫等,大型IT企業Microsoft、華為、Cisco、Intel等,他們都在積極推進著這個關系著未來制造業集成進程的規范與標準。從OPC基金會的工作我們可以看到很多值得借鑒的地方。
大背景-產業數字化中的難題
關于數字化轉型,這里牽扯到的話題是,我們究竟需要數字化轉型,還是轉型需要數字化?
圖1-數字化推進中的困境
關于產業推進數字化進程中的幾個困境:
1.互操作標準的欠缺
數字化架構的實現,無論提出邊緣計算、數字孿生、工業互聯網、工業物聯網、智能制造架構。這些實現的顯著特征是“集成”,數據、通信、應用的基礎連接需求,必須建立在體系性的標準基礎之上。這是共識,在多個系統間如數字化設計的CAD/CAE/CAM/CAPP,以及現場運營技術類的系統如PLC/DCS/SCADA和管理系統如ERP/CIMS/MES,以及應用的Cloud/Edge這些多功能場景中的集成,必然遇到這個交互的難題,如果沒有統一的規范與標準,這是無法想象的。
歐美構建這些架構的首要問題就是標準的問題,因此,OPC UA基金會聯合了眾多的協會組織,包括中國的SAC/TC124、IEC、VDMA、I4.0組織、IIC、ECC(中國邊緣計算組織),以及各個現場總線基金會、OMG(DDS)、MQTT等統一來構建這些標準連接問題。
2.工程成本如何降低的問題
目前國內推進的工業互聯網企業,就其現實數據報表來看,鮮有能夠盈利的。這個問題的關鍵就在于無法解決應用的“可復制性”問題—除了雄心勃勃準備從事該領域的大量企業,在資本的推動下,熱火朝天的干了也有不少年頭了。
可復制性的關鍵在于標準與規范,缺乏標準與規范會大幅影響工程實施成本,因為,大量的數據需要連接、配置、開發接口并進行測試,如果沒有統一的規范與標準,那么這就會成為一個“勞動密集型”工作,就會帶來大量的人工成本,而尤其是IT類工程師的成本又較之市場平均工程師成本高的情況下。
3.模塊化編程
就實現層面來說,面向對象、模塊化封裝的方式構建了系統的各個應用,那么,整個應用是會快速實現的,也可以被復用—但是,這就是難題。
經常和張譽討論起這件事情,OPC UA的角色其實非常關鍵,因為,在工程實施的時候,數據是一個獨立體,而應用則千差萬別的接口方式,那么,OPC UA提供了一個數據的標準封裝框架,使得對于不同的應用而言,都可以基于相同的方式來調用數據。OPC UA首先就是一個容器來對數據進行了結構化和標準化的處理。
其次,OPC UA又將在不同場景中的通信連接方式予以了支持,這包括了C/S、Pub/Sub的不同機制下的通信協議支持,幾乎涵蓋了各個常用的通信規約,如OPC UA對現場總線的支持、對TSN、MQTT、DDS這些的支持,都是為了解決在不同的領域所習慣和常用的通信機制。
OPC UA提供了特別的命名空間(Name Space)來為數據提供了數據存儲的格式、訪問層級、角色、授權與驗證機制、類型、參考、調用等,這些使得數據具有了“高完備性”的結構,這帶來的問題是它看上去會有點過于“重”的結構。
不過,OPC UA比較好的解決了這些問題,它基于SoA,其實,這就是一種“關注點分離”的模塊化編程思想,它使得應用和數據分離,OPC UA數據提供服務給不同的應用來“共享方式訪問”,避免數據與應用的耦合關系帶來的復雜性,以及不同應用間的潛在耦合風險。
另外,OPC UA提供了一種“動態”的交互模式—這使得系統具有“動態”運行的特征,滿足制造現場中的變化,例如在數字化仿真系統和運行系統間的動態模型交互,可以有助于實現數字孿生運行、邊緣計算的架構運行—因為,它自身也包含了對傳統現場總線、TSN、Pub/Sub機制的高實時性任務交互的需求。
當然,OPC UA的確比較重,這也在于OPC基金會的野心實在龐大,想將整個制造納入其中—并且,為何要將FLC納入其中,因為,如果要實現制造現場的動態性能,就得把現場層通信納入其中。
4.信息安全問題
由于集成,必然牽扯到了IT與OT系統的相互訪問,而IT系統本身采用的通用訪問機制也帶來了端口的開放,帶來對底層數據訪問中的信息安全問題。因此,OPC UA信息安全采用了證書和授權機制,這使得信息安全得到保障—這也是非常重要的一環。
除了信息安全(Cyber Security),另一個在工業里需要被考慮的安全是功能安全(Functional Safety),確保生產裝備的人身安全機制。
因此,本文,主旨討論技術標準與規范,順便展開講一些觀點與看法。
圖2-OPC UA FX所描繪的通信全景
圖2是最為經典的-所有人都看過的,不宜多講,列為看官,看圖生義,就知道未來工業通信的目的是從管理的架構延伸到分布式計算的架構。
其實,所謂的數字化轉型,僅從數字化這個視角,它就是要將原有的架構擴展到分布式架構上,而意味著不僅技術,通信,也包括了企業內的數字流動、業務的靈活性組合、服務的靈活組合問題,即,局部單元的智能,以及,其組合形成的對市場的應對能力。
本文僅討論標準與規范,只是順便想提醒一下我們討論數字化轉型的時候,在商業邏輯上,技術、規范均是要服務于業務。轉型,是業務模式的轉型,企業應對市場能力的轉型,那么,技術架構只是滿足這種變化—我們講這種技術的演進,只是在業務轉型發生后的匹配,而不是試圖用技術去指揮企業的數字化轉型。
圖3-參與OPC UA FLC倡議的企業
圖3是主要OPC UA FLC~現場級通信倡議發起者,兩者的關系在于FX是FLC制定的具體規范。FLC由自動化業界的知名企業、以及Intel、Huawei、Cisco主要推進的,而國內的廠商似乎只有來自IT業界的華為一家。前年的時候,某圈內朋友還表達“國內自動化廠商似乎還沒有積極參與到國際規范與標準中去”。另一方面就是國內好像信誓旦旦要為工業通信制定規范與標準的,反倒不是自動化企業,而是來自于通信領域的企業。這一方面說明了或許在國內OT端企業的專業話語權并不重,亦或企業都只是忙著賺錢,也沒空搭理所謂的未來通信規范與標準。由IT廠商建立工業通信規范與標準,我只是想說“此通信,非彼通信”。做了標準,和規范,需要有工業領域的企業參與并在產品研發中來支持。
后面我會總結一下,制定標準這件事情,看來也不是一個簡單的事情,我們對于標準,如老尹說的算是個“指導”、“管理辦法”—定性而不定量,有較大解釋空間的描述性、建議性、指南性,但缺乏在實際層面的可操作性、落地執行方面的內容-好處就是快速就可以制定標準。
OPC UA FX中的關系
而根據FLC所倡議的規范,即,OPC UA FX,它是OPC UA Field eXchange的簡寫,從其名字即是將OPC UA涵蓋至現場層,即,OPC UA不想僅停留在通信層,也想涵蓋網絡協議的統一規范,可謂志向遠大。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。
因此,有線和無線都會成為基礎。目前TSN的確被賦予了更高的優先級,畢竟5G的性能和成本尚未對于工業有好的經濟性,只是在測試驗證階段。而Wi-Fi 6,也在測試中,作為在OPC UA基金會的未來技術選項里,做了羅列。如圖4,OPC UA FX在整個連接中的作用。
圖4-OPC UA FX所處的位置和作用
OPC UA FX進展
OPC UA FLC作為倡議者組織,由主要的自動化廠商發起,在初始階段,它主要聚焦在C2C,即,Controller to Controller階段的通信。而在2022年7啟動C2D和D2D領域的規范,使得TSN延伸至Controller to Device 及Device to Device的階段。
TSN目前的國際標準IEC60802似乎進展比較慢,因為2020-2022年這期間疫情的緣故,以及很多企業人員的工作不穩定,IEC60802似乎并未完成其IA Profile的規范工作,因為目前才是CDS文件,尚未進入FDS文件狀態。
圖5-FX工作范圍和邊界
如圖5,OPC UA FX涵蓋的是底層網絡和其IA-Profile的定義,我們從這個結構上可以看到,OPC UA基金會的想法就是用OPC UA的應用信息模型來作為應用層架構,然后集成網絡層的TSN/5G,這個想法很大,也即,OPC UA+TSN,會被新的FX規范所定義。
OPC UA FX的規范簡要展開
圖6-OPC FX系列規范
如圖6,OPC UA FX第一批規范,也即在2022年發布的Part 80-84這個集合,主要還是針對C2C的,即包括80-84五個部分,其中80,82在去年進行了介紹。此次主要還是交流一下兩個重要的規范,81和83,一個針對自動化組件本身的資產、功能模型,和離線工程的規范。
Part 80:主要定義了OPC UA FX基本概念
Part 81:自動化組件的資產和功能模型的協調,統一的自動化組件信息訪問,獨立于控制器或設備廠商,適用于PLC或傳感器、工廠或過程自動化
圖7-自動化組件的信息模型參考
在自動化系統的組件中,包括了物理對象、軟件、固件、授權,信息包括廠商、產品、固件版本、序列號等。實際上就是給上位或水平系統提供了誰家的控制器、軟件版本等基本信息,如圖7所示。
圖8-自動化組件的邏輯連接
其次,如圖8,就是提供了這些自動化組件的驗證(資產與功能性實體)方法、擁有者、應用配置等。再者就是這些組件,如PLC、驅動器支持的交互機制,基于OPC UA Pub/Sub機制來傳輸,信息包括功能安全、信息安全、TSN的QoS(優先級、保護帶寬、延時、截止時間)、不同的傳輸機制(以太網、UDP、AMQP、MQTT)、連接的監測。
Part 83-離線工程
圖9-離線工程信息規范與參考
在離線工程方面,如圖9,FX包括了離線描述器用以描述能力、功能,配置自動化組件的資產,自動化系統必要開發、調試、維護階段的信息。
這個開放的封裝文檔采用ECMA-376,也就是openXML的格式來進行建模和附件封裝,內部與外部關系、數字簽名。信息模型描述采用了Automation ML規范,一種面向車間工程的XML-based數據交換格式,也是IEC62714的標準。工程附件包括其它信息模型的集成,如PLCopen、YANG,文檔、手冊、圖紙。
就是說,這些是在離線工程中,對自動化組件的相關信息、描述、圖紙、文檔等進行統一規范。
應用場景分析
OPC UA FX,或者之前稱為OPC UA over TSN的,在很長一段時間里,其實,很多人都會疑惑它的應用場景。其實,如果TSN你覺得用不到,那么大概率上來說:
(1).數字化還未到達較為深入的階段
后來發現,大家為什么不用OPC UA over TSN,而是因為其實很多應用,它在OPC UA +Ethernet這個任務等級上就可以解決,比如OPC UA在標準以太網上,其實也可以達到10mS倍數等級的,而且,在有些時候,如前段時間發現我們的工程師在OPC UA的訪問上,可以達到2mS的循環,這還超出了我的原來的想像。
在什么場景下會需要TSN?
->真的是實現了互聯,以及高速的推理應用這個場景;
->動態的數字化應用,即時分析與應用;
(2).大概你還沒有了解OPC UA FX的方案就是為了你的應用而設計;
因為,你可能在尋找方案,但因為目前TSN的很多方案其實,還都在測試階段,還不是成熟到所謂的“拿來即用”,因此,對于在測試會覺得還沒完成,而對于沒有測試的一般都在拿其它的方案在測試,但是,還沒有尋找到最佳的解決方案。而當OPC UA+TSN比較成熟的方案出來后,這個架構才會發揮力量。
(3).這幾年進程的確有點慢。
TSN最近幾年進展比較慢,與TSN是一個基于IT思想而設計的標準,它的形成過程不同于以往,因為IEC其它的通信標準,基本上都是傳統OT的“先有問題,再尋求方案,最后標準化”的思路。TSN是按照先有技術,然后去推進場景應用的IT思維來設計的。
另外,TSN被稱為“歷史上,首次,各家自動化廠商要來協同構建的標準”,TSN與以往的由某個主要廠商已有的標準來推進不同。這是第一次大家居然競爭企業坐在一起來商討如何面向未來構建一個新的工業通信架構。因為,大家意識到,原有的玩法,在未來不會那么奏效。
這使得TSN較之以往的通信標準需要花費更多的溝通與協調時間,但是,好在它是有基礎的,即早期的IEEE802.1Q的基本規范上。因此,相對來說,它又算快的—因為,畢竟第一次Shaper起草工作組會議還是在2016年,到2019年左右各家已經出了原型機,按說速度也夠快的。
但是,目前來看,各家的問題都聚焦在了“軟件”問題上,即,如何更為有效的對TSN網絡進行配置,因為,TSN網絡不同于以往的工業通信網絡。傳統工業通信網絡基本上為了“確定性”,采用了非常簡化的思路,就是“輪詢”、“令牌”,因為,這種在軟件上容易實現,配置簡單。但TSN采用了復雜的排隊和“橋接”網絡模式,這使得系統復雜性會有所提高。
網絡動態配置會是個關鍵問題,需要一個好的配置算法來實現高效的配置,在網絡出現變化時,能夠動態優化網絡的數據流調度。因此,TSN網絡是一個需要高度智能的網絡配置系統,還有,這個必須要做到“User-friendly”,而這又是個難題,要把復雜的網絡問題,轉換為與應用無關、與制造商無關的進行配置,這本身就需要特別的“標準”,而IEEE/IEC6082的工作進程也使得這項工作推進有點慢,最近幾年疫情也使得大家工作都不那么穩定有序。
圖10-OPC UA over TSN的應用場景
在圖9中,可以看到首先由TSN來采集現場數據,包括I/O、視覺、運動控制軸(目前C2D剛開始),然后經由OPC UA over TSN傳輸到邊緣控制器層,如貝加萊可以采用Hypervisor的工業PC來作為一個處理和分析單元。在這個架構中,處理和分析單元,主要運行AI、調度、優化類的程序,然后解析出要去執行的調整,通過TSN網絡來下發給現場設備。而對于長周期的模型訓練,OPC UA也提供了到云端的連接規范(后續可以另行分享)。
在OPC UA over TSN的應用架構中,首先是有集成的架構實現,然后是高速動態的質量分析、快速動態的調節執行行為,構成一個控制、邊緣分析下發執行的大閉環—這個閉環,主要聚焦在全局的質量優化、改善上。
關于標準的問題
我也看過了大量的IEEE/IEC關于各種標準的制定文件,能觀察到這些標準的制定,其實是個非常嚴謹的工程過程。圖10作為參與一些標準工作,以及對照OPC、IEEE的標準工作有感而發。
圖11-對于標準制定的思考
首先,標準的制定,包括參考IEEE802.1Q系列的TSN標準,以及OPC 基金會的標準。可以看到,標準的制定完全基于一個工程開發過程的流程來實現,先要去分析需求,制定一個目標,然后要拆解為各種場景,因為即使工業也分為離散、流程、批處理等多種業務場景,然后要去解析,解決這些問題的機制,針對這些問題拆分為硬件、軟件、網絡拓撲、配置工具與方法等。因此,制定這個標準的過程本身就是一個非常嚴謹的工程開發過程。
因為,受制于在工程思維方面的訓練,以及在技術研發水平上的制約,感覺很多時候,我們在制定標準的時候,會陷入到對“詞句”的解析上,因為很多都是跟標。而自行制定的標準,往往照貓畫虎,但并非基于需求的工程過程來實現,在形式上像是標準,但在指導性,實現可行性尚有欠缺。
協作問題,標準制定還是需要較好的協同工作機制,這需要本身具有強的研發項目管理水平。專家方面,還是需要一線的工程技術人員參與比較好。另外,在這些標準的制定過程中,行業的標準,應該多方協同,包括各自的角色分工:
(1).終端生產企業:目前大部分的智能制造、工業通信標準,最終用戶是使用者,因此,他們需要從需求端來提出意見。國內很多標準,缺乏來自終端用戶的聲音,如果僅是自身行業人制定標準,那么,難免有點“閉門造車”的問題。
(2).裝備企業:作為系統的實現者,或者技術的載體,裝備需要更為明確在其自身的實現上的需求。
(3).技術提供者,像自動化、系統、軟件類廠商,作為技術提供者,應該去按照需求來解析模塊,并對其進行分布開發。提出規范與標準的實現方法。
(4).標準專家:基于標準的標準來對整個標準制定過程的程序、定義、邊界、行文、引用等進行規范。
參與的企業要具有廣泛的代表性,而專家身份也需要來自技術、工程管理,眾多利益相關者必須深入參與其中。