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)如果對于復(fù)雜機器來說，也許計 算可用性是夠了，但如果計算OEE設(shè)備綜合效率的話，就得看 其他的參數(shù)是否足夠。

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

　　對于這個“偉大”的想法，之所以覺得困難，是因為現(xiàn)實 中，似乎只有國際半導(dǎo)體產(chǎn)業(yè)協(xié)會SEMI的行規(guī)用得最好，但 它并未基于OPC UA來實現(xiàn)。SEMI的規(guī)約整體就像G代碼，它 給每個命令行定義了對應(yīng)的操作，以及攜帶的參數(shù)，機器的 任務(wù)在一個簡單的G代碼下就可以運行。SEMI其實是有個得天 獨厚的優(yōu)勢，即是在半導(dǎo)體的生產(chǎn)鏈上，所有設(shè)備操作的對 象都是單一的，即那個被稱為“Wafer晶圓”的東西，不管是 退火爐，還是光刻機、沉積、刻蝕、離子注入、拋光設(shè)備， 加工對象都是一致的，每臺設(shè)備所進行的操作如上下料、工 藝過程、檢測等，所有動作對應(yīng)的參數(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è)的信息模型非常難以被適 用，就像前面提到半導(dǎo)體SEMI的對象單一，但是在包裝機械 行業(yè)里，PackML標準已經(jīng)被推廣了近30年，現(xiàn)在究竟又有多 少End User在使用呢?因為，包裝領(lǐng)域的機器對象實在太復(fù) 雜了：液體、固體、粉體的包裝形式不同;制藥包裝里還有 片劑、丸劑、膠囊制劑、液體制劑、氣霧劑等等，這種復(fù)雜 的對象變化，很難統(tǒng)一!

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

　　問題不在這里，而在于“軟件化”，即，標準的軟件化設(shè) 計。這很關(guān)鍵——即，如何看待標準的問題，是否我們制定的 標準能夠以軟件化形式在自動化系統(tǒng)中被快速“配置”，標準 不是一個簡單的文檔，而是基于工程需求設(shè)計的一個產(chǎn)品、 一個可復(fù)用的知識和“規(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)它定義了很好的單一操作界

　　面，機器無論如何復(fù)雜，其都能在多個狀態(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ù)配 置，而不是復(fù)雜的編程。

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

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

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

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

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

　　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)品方面的 應(yīng)用資料，但現(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)。

　　所以，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)。

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

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

　　越來越復(fù)雜的集成，以及IIoT和AI應(yīng)用，使得工程集成變 得更加復(fù)雜，那么快速搭建這種信息模型、數(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ā)展制定標準，這是件挺厲害的事，這種組織 運行機制也挺有意思的。