" />" />
關(guān)注我們:新浪微博騰訊微博QQ空間
首頁 > 行業(yè)內(nèi)外 > 聚焦

隱藏在通信背后 ——如何應對復雜制造系統(tǒng)的軟件協(xié)作

文:文/宋華振 | 2025年第五期 (0) | (0)

  1 通信在制造系統(tǒng)的水平集成

  在一個End User工廠,它會出現(xiàn)不僅是某個設(shè)備的集 成,例如一個電子工廠,它可能還會牽扯到注塑機、CNC、貼 片、包裝等各種設(shè)備,那么,它們是如何被統(tǒng)一協(xié)作的呢?

  德國機械設(shè)備制造業(yè)聯(lián)合會VDMA試圖構(gòu)建一個適用于 各種機器的狀態(tài)模型,以及基礎(chǔ)的信息模型來進行“一統(tǒng)江 湖”,雖然感覺有點難,但這種精神值得贊揚。在最新的OPC 基金會的在線會議里,看到VDMA試圖去構(gòu)造如圖1場景中的 連接問題,即,在一個包含了切割、涂裝、包裝及檢測的流水 線里,這些機器間如何通過狀態(tài)來實現(xiàn)協(xié)作。它定義了不多的 狀態(tài)機——執(zhí)行(Executing)、不執(zhí)行(Not Executing)、停 止服務(wù)(Out of Service)、不可用(Not Avaliable)四個狀 態(tài)。不過,我覺得這四個狀態(tài)如果對于復雜機器來說,也許計 算可用性是夠了,但如果計算OEE設(shè)備綜合效率的話,就得看 其他的參數(shù)是否足夠。

51.png

  但是,如果其伴隨信息模型——就目前的信息模型來 看,僅包括機器ID、監(jiān)控(狀態(tài)、運行模式、健康狀態(tài)、消 耗)、機器設(shè)備、通知、作業(yè)單信息,感覺還差點意思,想 要達到如圖2的計算,如OEE、DPP(數(shù)字產(chǎn)品護照)的計算 和訪問,實現(xiàn)數(shù)字孿生的交互信息、AI應用的數(shù)據(jù)交互,現(xiàn)在 這個CS(所謂的伴隨行規(guī))還是不夠的。

52.png

  對于這個“偉大”的想法,之所以覺得困難,是因為現(xiàn)實 中,似乎只有國際半導體產(chǎn)業(yè)協(xié)會SEMI的行規(guī)用得最好,但 它并未基于OPC UA來實現(xiàn)。SEMI的規(guī)約整體就像G代碼,它 給每個命令行定義了對應的操作,以及攜帶的參數(shù),機器的 任務(wù)在一個簡單的G代碼下就可以運行。SEMI其實是有個得天 獨厚的優(yōu)勢,即是在半導體的生產(chǎn)鏈上,所有設(shè)備操作的對 象都是單一的,即那個被稱為“Wafer晶圓”的東西,不管是 退火爐,還是光刻機、沉積、刻蝕、離子注入、拋光設(shè)備, 加工對象都是一致的,每臺設(shè)備所進行的操作如上下料、工 藝過程、檢測等,所有動作對應的參數(shù)(起始位置、路徑、時間、溫度、壓力等等)都圍繞晶圓本身。同樣,就像TSN在 汽車行業(yè)容易被統(tǒng)一那樣,因為汽車大致上都是由四個輪子+ 懸掛+發(fā)動機(電機+逆變器)所組成——從物理對象建模的視 角來看,這個對象也是單一的模型。

  通信的行規(guī),其實定義了在執(zhí)行自動化編寫任務(wù)時, 以更為結(jié)構(gòu)和邏輯的形式去操作這些機器之間的協(xié)作。因為 所有的機器都是“動作”+“參數(shù)”按照邏輯來運行的,就相 當于每個子程序的調(diào)用,在新狀態(tài)下調(diào)用新的子程序(攜帶 參數(shù)),而這些行規(guī)定義了這些動作及所帶的參數(shù)格式。因 此,通信行規(guī)簡化了整個自動化程序的編寫工作。

  2 垂直行業(yè)的快速信息采集——垂直行業(yè)信息 模型

  在不同行業(yè),我們?nèi)绾稳タ焖俚卮罱ㄟ\行系統(tǒng),讓機器 之間形成協(xié)作呢?雖然,這種行業(yè)的信息模型非常難以被適 用,就像前面提到半導體SEMI的對象單一,但是在包裝機械 行業(yè)里,PackML標準已經(jīng)被推廣了近30年,現(xiàn)在究竟又有多 少End User在使用呢?因為,包裝領(lǐng)域的機器對象實在太復 雜了:液體、固體、粉體的包裝形式不同;制藥包裝里還有 片劑、丸劑、膠囊制劑、液體制劑、氣霧劑等等,這種復雜 的對象變化,很難統(tǒng)一!

  當然,這里想說的不是困難,而是大家還沒有達到高度 的“工程集成”階段,各個行業(yè)在現(xiàn)實中,也未能實現(xiàn)真正的 所謂“智能制造”,因為,連線才能顯示制造的智能!只有連 線的生產(chǎn)才需要更為“實時”的協(xié)作——單機關(guān)注的是動作間的 工藝切換,產(chǎn)線則是全局的協(xié)作。

  問題不在這里,而在于“軟件化”,即,標準的軟件化設(shè) 計。這很關(guān)鍵——即,如何看待標準的問題,是否我們制定的 標準能夠以軟件化形式在自動化系統(tǒng)中被快速“配置”,標準 不是一個簡單的文檔,而是基于工程需求設(shè)計的一個產(chǎn)品、 一個可復用的知識和“規(guī)則”。

  PackML標準在這方面堪稱典范,它 完美地制定了機器和系統(tǒng)如何被狀態(tài)機 協(xié)作,以及從最小的組件到整個產(chǎn)線的 模塊化設(shè)計,在作業(yè)管理解析下發(fā)到每 個控制任務(wù)的參數(shù)中,以實現(xiàn)生產(chǎn)的變 更。PackML是一套很好的通信行規(guī)設(shè)計 范例,它解決了以下幾個問題:

  (1 ) 進 行 資 產(chǎn) 管 理 , 計 算 O EE時,根據(jù)每個狀態(tài)的計時來計 算可用性(Ava lib ility)、良品率 (Quality)統(tǒng)計、機器的實際運行效率 (Performance),這三個指標就可以計 算OEE。

  (2)它定義了很好的單一操作界

  面,機器無論如何復雜,其都能在多個狀態(tài)間切換,實現(xiàn)邏輯 的任務(wù)編程與組織,這也是一個對用戶友好的方式,用簡單的 邏輯來編排任務(wù)。

  (3)機器的信息模型提高了整個數(shù)據(jù)采集的效率,通過 打包數(shù)據(jù)來實現(xiàn)快速的工程數(shù)據(jù)采集。

  從自動化工程的視角來看,通信的行規(guī)其實定義了一種 快速的任務(wù)調(diào)度機制,即,當作業(yè)變化時,快速地用狀態(tài)邏 輯來配置生產(chǎn)成為了可能。因此,通信行規(guī),它要解決的是 在整個變化的生產(chǎn)中,如何快速地進行Engineering的參數(shù)配 置,而不是復雜的編程。

  3 云端系統(tǒng)與數(shù)據(jù)源的連接——從傳感器到云 端的連接

  越來越多的工廠需要從底層到云端的數(shù)據(jù),以及部署在 云端或邊緣側(cè)的控制與調(diào)度優(yōu)化。

  在圖3中,在OPC基金會提出的云應用倡議架構(gòu)中,其 實,提供了機器與產(chǎn)線端的數(shù)據(jù),通過OPC UA Pub/Sub、C/ S機制、OpenAPI Rest、REST Queries的方式來形成各種數(shù)據(jù) 交互的支持。這個架構(gòu)包括了微軟、華為、亞馬遜作為主要 的推動者。

  在圖3的復雜架構(gòu)中,采用了非常多的數(shù)據(jù)分發(fā)機制,來 為顯示、產(chǎn)品管理(消費者相關(guān))、MES(云端MES)、ERP (云端ERP)、AI分析助手等提供各自的數(shù)據(jù)分發(fā)機制和協(xié) 議。在這些純軟件領(lǐng)域中,還定義了很多內(nèi)容,只要快速簡 單配置即可。

53.png

  圖4是我在OPC基金會的報告里看到的 來自國內(nèi)的自動化企業(yè),該報告的主題是關(guān) 于WebAPI的連接方式,即直接在瀏覽器端 采用Web Client/Web Service的方式來提供 對OT端數(shù)據(jù)的直接訪問。這是個好辦法, 其實,現(xiàn)在的PLC中配置一個Web Server也 很正常,通過瀏覽器來訪問,自適應性、易 于開發(fā)的特性還是挺好的,也算是對OPC基 金會做出了一份來自中國的貢獻。這很關(guān) 鍵,支持WebAPI的OpenAtom組織的確是 由中國本地的華為、阿里、騰訊發(fā)起的,我 覺得這是一件很好事情,顯示出本土企業(yè)在 全球標準化組織中起到了積極的推動作用。

54.png

  4 工業(yè)控制與CAE軟件的協(xié)同——OPC UA的模 型交互

  為了構(gòu)建數(shù)字孿生,需要在動態(tài)的方式中連接這些軟件 之間的關(guān)系。最早時候,這個仿真類軟件與自動化類軟件的 接口都是“私有”的,就像Mathworks針對不同的自動化公司 都開發(fā)不同的Connector接口一樣。后來,Modelica組織就開 發(fā)出了FMU/FMI在各個CAD/CAE軟件間實現(xiàn)交互,包括自動 化公司也支持這些方式,像SIEMENS、Rockwell AB、B&R、 Beckhoff等等都有這個接口。這就相當于私有到專業(yè),即, 在這個專業(yè)組織內(nèi)部,大家可以交互。不過,可能未來還是 OPC UA能夠跨領(lǐng)域, 因為CAD/CAE/EDA是各自專業(yè)的系 統(tǒng),OPC UA要打破這些專業(yè)之間的協(xié)作,還要和MES/ERP、 云端、AI系統(tǒng)進行交互,就需要更為通用的接口。

  這個接口對于自動化的好處其實在于“自動代碼生成”, 像Mathworks的自動代碼生成可以為核心算法封裝和下載到 本地PLC,進而實現(xiàn)硬件在環(huán)測試,加速開發(fā)效率和降低自動 化系統(tǒng)的開發(fā)成本。

  這些接口與規(guī)范,正代表了協(xié)作范圍的不斷延伸,產(chǎn)業(yè) 的不同領(lǐng)域必須打破那些橫亙在所謂專業(yè)領(lǐng)域的“藩籬”,打 破影響協(xié)作與全局優(yōu)化的阻礙。這也是整個數(shù)字化要進行的 工作前提,任何所謂的數(shù)字孿生、人工智能的分析與優(yōu)化, 都必須建立在這些“藩籬”被打破的、全面開放的世界里。

  開放,將突破專業(yè)領(lǐng)域,也將突破層次結(jié)構(gòu),即——在橫 向與縱向之間打破壁壘。

  5 管理相關(guān)信息模型DPP/碳追蹤

  之前看過關(guān)于數(shù)字產(chǎn)品護照DPP在綠色包裝產(chǎn)品方面的 應用資料,但現(xiàn)在看來,DPP可能更像是針對動力電池、消 費電池等領(lǐng)域的一個壁壘。不過,歐盟DPP的參與方,還是 國內(nèi)的電池廠商比較多,例如CATL、BYD、億緯鋰能、陽 光電源等,畢竟,歐洲好像也沒有特別拿得出手的電池制造 商。該標準主要面向全球的電池制造廠商,其中90%都在亞 洲,尤其是在中國。除此之外,包括像DPP——數(shù)字產(chǎn)品護 照、碳足跡這些貿(mào)易相關(guān)的內(nèi)容,也需要從機器中采集數(shù)據(jù) (Embedded DPP),以及為了實現(xiàn)碳追蹤,在機器系統(tǒng)里 對能源相關(guān)數(shù)據(jù)進行采集(圖5)。

55.png

  所以,OPC基金會和ZVEI、CATENA-X這些組織一起來實 現(xiàn)DPP的嵌入式數(shù)據(jù)采集方案,包括:在BMS里的數(shù)據(jù)點,以 及對銷售流通環(huán)節(jié)、處理后環(huán)節(jié)的各個數(shù)據(jù)監(jiān)測等。其實, 也包括了碳足跡的追蹤問題——在去年的報告里,OPC UA還定 義了碳足跡和碳捕捉的數(shù)據(jù)采集,這可能會和綠色電力的貿(mào) 易壁壘有關(guān)系,就是要知道制造產(chǎn)品的電力來自哪里。

  6 統(tǒng)一工程規(guī)范MTP

  對于自動化系統(tǒng)而言,如何在分布式的系統(tǒng)里實現(xiàn)數(shù)據(jù) 間的連接工程,就像系統(tǒng)里由5個不同的PLC廠商來實現(xiàn)各個 單元控制那樣——現(xiàn)在系統(tǒng)的任務(wù)變了,如何讓每個單元都能 升級其系統(tǒng)、怎樣才能把變更通過一個接口寫入到每個控制 器的邏輯或算法單元中?

  Automation ML自動化機器學習 試圖構(gòu)建這樣的方案,但似乎并未能 夠很好的實現(xiàn),現(xiàn)實是Automation ML還沒有被大多數(shù)公司作為一個模 塊嵌入在系統(tǒng)中。

  不過,MTP則似乎正在成為一個 熱點,它試圖去為分布式系統(tǒng)定義一 個工程的統(tǒng)一接口,以便能夠為這種 分布在多個地點的、由不同組件構(gòu)成 的整體系統(tǒng)的升級帶來工程效率方面 的提升。

  因此,對于自動化系統(tǒng)來說, 工程集成——通過這種統(tǒng)一的規(guī)范就 可以很快地實現(xiàn)自動化任務(wù)的集成。

  圖6是Power to X(消納清潔能源,轉(zhuǎn)為綠氫,再轉(zhuǎn)為X- 甲烷、綠氨、汽油、甲醇等,統(tǒng)稱為Power to X,即,電轉(zhuǎn)各 種能源X)其中核心的電解槽結(jié)構(gòu),以及通過MTP為這個制氫 系統(tǒng)搭建的工程服務(wù)架構(gòu)(圖7)。

56.png

57.png

  不過,最近聽說歐美很多大型的氫能項目都停止了。實 際上清華大學的一位專家大約在8年前就做過分析,電價如果 均量化度電成本(LCOE)不能低于0.25人民幣,按此計算, 制氫路線就不具有經(jīng)濟性。因為只有中國的光伏和風能的電 價可能才能達到這一數(shù)值。另外,從清潔能源消納的角度出 發(fā),可能也只有中國才具有實現(xiàn)Power to X的必要性。

  當然,這部分就算閑扯了——其實這篇文章想說的是,通 信規(guī)約在自動化工程中的角色,以及其核心作用。

  越來越復雜的集成,以及IIoT和AI應用,使得工程集成變 得更加復雜,那么快速搭建這種信息模型、數(shù)據(jù)交互接口規(guī) 范與標準,還是很有必要的,OPC UA提供了一個好的方向, 不過,戴老師總是說OPC UA太重了,的確——他們雄心勃勃 要干出“一統(tǒng)江湖”的通信,什么都往里面加。從今年的OPC 基金會報告中看到,包括信息安全、針對垂直行業(yè)(激光系 統(tǒng)、鐵路系統(tǒng)、航空系統(tǒng))、能源問題、機器的統(tǒng)一通信行 規(guī),以及各種通信技術(shù)如TSN/WiFi/5G等等都被納入其中。我 曾私下里和戴老師等討論過這個問題,為什么像IEEE/IEC這些 組織能夠把很多來自不同領(lǐng)域、有競爭關(guān)系的企業(yè)都聚集在 一起為未來的發(fā)展制定標準,這是件挺厲害的事,這種組織 運行機制也挺有意思的。

發(fā)表評論

網(wǎng)友評論僅供其表達個人看法,并不表明控制與傳動周刊同意其觀點或證實其描述

雜志訂閱

填寫郵件地址,訂閱精彩資訊:

雜志目錄

更多往期雜志

關(guān)注我們:

新浪微博騰訊微博QQ空間

友情鏈接:

紙質(zhì)雜志

給我們寫信