国产成人精品免高潮在线观看-国产精品99无码一区二区-国产av人人夜夜澡人人爽-精品国产免费一区二区三区香蕉

　　1 通信在制造系統的水平集成

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

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

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

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

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

　　2 垂直行業的快速信息采集——垂直行業信息 模型

　　在不同行業，我們如何去快速地搭建運行系統，讓機器 之間形成協作呢?雖然，這種行業的信息模型非常難以被適 用，就像前面提到半導體SEMI的對象單一，但是在包裝機械 行業里，PackML標準已經被推廣了近30年，現在究竟又有多 少End User在使用呢?因為，包裝領域的機器對象實在太復 雜了：液體、固體、粉體的包裝形式不同;制藥包裝里還有 片劑、丸劑、膠囊制劑、液體制劑、氣霧劑等等，這種復雜 的對象變化，很難統一!

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

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

　　PackML標準在這方面堪稱典范，它 完美地制定了機器和系統如何被狀態機 協作，以及從最小的組件到整個產線的 模塊化設計，在作業管理解析下發到每 個控制任務的參數中，以實現生產的變 更。PackML是一套很好的通信行規設計 范例，它解決了以下幾個問題：

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

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

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

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

　　從自動化工程的視角來看，通信的行規其實定義了一種 快速的任務調度機制，即，當作業變化時，快速地用狀態邏 輯來配置生產成為了可能。因此，通信行規，它要解決的是 在整個變化的生產中，如何快速地進行Engineering的參數配 置，而不是復雜的編程。

　　3 云端系統與數據源的連接——從傳感器到云 端的連接

　　越來越多的工廠需要從底層到云端的數據，以及部署在 云端或邊緣側的控制與調度優化。

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

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

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

　　4 工業控制與CAE軟件的協同——OPC UA的模 型交互

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

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

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

　　開放，將突破專業領域，也將突破層次結構，即——在橫 向與縱向之間打破壁壘。

　　5 管理相關信息模型DPP/碳追蹤

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

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

　　6 統一工程規范MTP

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

　　Automation ML自動化機器學習 試圖構建這樣的方案，但似乎并未能 夠很好的實現，現實是Automation ML還沒有被大多數公司作為一個模 塊嵌入在系統中。

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

　　因此，對于自動化系統來說， 工程集成——通過這種統一的規范就 可以很快地實現自動化任務的集成。

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

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

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

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