在我國，標準分為13類：基礎標準、術語標準、符號標準、分類標準、試驗標準、規范標準、規程標準、指南標準、產品標準、過程標準、服務標準、接口標準，和數據標準。比如接口標準就是規定產品或系統在其互連部位與兼容性有關的要求的標準。
不過這些年來在工業發達國家，尤其在美國，開展著一類非常活躍的標準活動，似乎不能歸類于上述的任意一類標準。這就是在多種適用的工業標準的基礎上，建立為特定細分行業服務的綜合性應用標準，有時在文獻中還被稱為"標準的標準"（Standardofstandards）。這類標準往往不是由某個正式或官方的標準化組織所發起和操作的，而是由最終用戶根據他們的需要、思考和判斷來發起，并為此建立或委托一個非官方組織去開展相關的標準化活動。這類目標極為明確的標準化活動吸引了一批志同道合的伙伴（包括最終用戶、自動化供應商、自動化咨詢機構和一些標準化組織等），共同開展跨組織的、資源投入巨大的努力，有效推動了行業技術進步，并將繼續顯示出前所未有的經濟潛力和組織活力。
下面我們分析兩個案例：開放流程自動化標準OPAS和被譽為機械裝備集成的樣板的PackML。
開放流程自動化標準OPAS
OPAF論壇正在為下一代流程自動化系統的體系架構制定系列標準。所謂下一代流程自動化系統區別于現有的DCS的主要特征是：開放、可互操作、具有內生的信息安全。因此這些標準將使得獨立供應商提供的基本功能部件能夠按照模塊化架構的方式以及開放的接口標準方便地集成到流程工業適用的各類大、中、小系統之中。
1.開放流程自動化的目標和技術架構
1.1開放流程自動化的目標
處于ISA95模型L1和L2層的自動化硬件和軟件結構許多年沒有變動，自動化市場也一直圍繞著硬件和軟件捆綁的模式在演進。每一個自動化供應商都有自己的軟件開發和應用環境，并將這種軟件環境交付給最終用戶，而用戶只能通過供應商提供的組態工具與控制器交互。由此可以斷定，現今流程工業自動化控制系統DCS和PLC最大的問題在于其封閉和專用的特性。在IT技術飛躍發展的年代，這極大地阻礙了DCS和PLC的升級遷移，以及OT與IT深入高效的融合。此外，目前的DCS和PLC所有有關信息安全的措施都不是原生的，而是后加的，有如打補丁，因而一般不能提供內在的保護運營、資產設備和其它投資所需要的信息安全特性。
許多在役的控制系統其構成的硬件和軟件由于專用、封閉，維護和升級的成本昂貴，一旦需要與一流的第三方部件集成，耗資不菲。尤其在目前IT技術快速深入地滲透和融合到企業運營管理方方面面的趨勢下，這些控制系統通常不具備本征的信息安全特質，造成了巨大的風險和隱患。還有一個問題是，從長遠發展來看，現有的控制器不能有效而恰當地保護設備資產和其它資本投資，以及多年來積累的過程數據和操作知識。
鑒于上述存在的問題，2016年埃克森美孚的研究和工程部門公開倡議開發一個全新的、基于標準的流程控制架構，得到ARC咨詢集團大力支持，并由非盈利的第三方機構--美國開放集團（TheOpenGroup）組織了一個新的面向流程工業控制技術的標準化活動，即開放流程自動化論壇（OPAF）。論壇聚焦于如何運用最新的分布式云計算技術和虛擬化技術，重新定義已經日趨陳舊、20多年沒有變動的架構，重新定義DCS和PLC，以及與優化運營密切相關的先進控制和MES，但不涉及專門針對流程工業安全保護的安全儀表系統SIS（見圖1）。
圖1開放流程自動化論壇OPAF定義的范圍
值得高興的是，循著這一方向的進展相當迅速。繼2019年初發布OPASV1.0后，經過不到一年的時間已經在2020年1月定版正式發布；在今年2月發布了OPASV2.0，包括OPAS標準的Part6.1，6.2，6.4和Part7，已經可從OPAF的網站下載評估版；而OPASV2.1預計會在今年年中推出。與此同時，建立測試床和進行工業中試的計劃，也在順利推進并付諸建設落實。2019年5月的OPAF可互操作性工作會議，敦促成員把他們支持OPASV1.0的硬件和軟件拿到已經建立的測試床來試驗，以驗證標準初始版本的正確性和清晰性，從而將初始版升級為正式版。
原型/中試裝置包括4個反應器訓練裝置，由泵、反應器、分離器、分析裝置等組成，系統有25個典型的流程控制回路，130個I/O單元，總計500點。碳氫流程包括原油和加氫以及H2S，主要是評估催化性能。在2020年1月完成現場接收測試。原型/中試裝置用開放流程自動化OPA系統執行了常規的單元操作，諸如啟動、停車、控制單元的操作運行參數，以及滿足操作人員的期望等。原型/中試裝置的數據由OSIsoft的PI歷史數據軟件和InductiveAutomation'的HMI/SCADA采集，其架構的硬件和軟件來自Dell,nxtControls,PhoenixContact,Intel,Yokogawa,Moxa,Lantronix和Matrikon。其DCN有PhoenixContact的控制器、基于虛擬機的軟控制器、由Intel提供的可由客戶定義的DCN（具有4個通道），一個可切換的盒式微處理器組合（用來切換計算功能性）。通信采用OPCUA構成實時總線，在一臺DellVxRailACP服務器中劃分為6個信息段區處理軟控制器和其它功能。圖2是原型/中試裝置的開放流程自動化系統。
圖2為開放流程自動化系統的測試建立的原型/中試裝置系統
1.2OPA的技術架構
OPAS標準支持通信的相互作用，通過列出硬件和軟件部件的特定接口使自動化系統成為一個面向服務的架構SOA，而這些部件將被用來為最終用戶設計、構建和啟用自動化系統。
OPAS標準的版本并不限定一個架構中所用接口的數量，也就是說每一個自動化系統都可為滿足其特定的要求構成最合適的設計。標準只給出參考系統架構（見圖3），而不專門定義詳細的系統架構，通過給出用例來描述如何使用部件級的接口。
圖3開放型流程自動化OPA的參考系統架構
在參考系統架構中包含下列基本要素：
1.分布式控制節點（DCN）
DCN可以是一個基于微處理器的控制器、I/O、或可處理輸入輸出和具有計算功能的網關設備。O-PAS標準的一個關鍵特性是硬件與控制軟件是解耦的，所以任意一個DCN的準確功能取決于系統的構造者。一個DCN包括硬件和某個系統軟件，也允許在其中運行控制軟件，同時DCN具有能夠與O-PAS網絡（稱為OCF）連接的接口。
在OPAS標準中DCN表示一種基本的計算模塊，它可以是硬件實現或者是虛擬實現。DCN可大可小，可以沒有I/O或者有各種各樣的I/O。目前每個DCN容許的I/O密度并沒有規定，因此這方面的標準化可能要由市場來推動最終的配置。DCN也可以作為與其它網絡或系統連接的網關，例如與傳統系統、數字現場網絡、I/O、和DCS、PLC控制器等連接。工業互聯網IIoT的設備也可經由這些系統進行存取。
圖4DCN由DCP、DFC等構成
2.分布式控制平臺（DCP）
DCP是在所有DCN中要求的硬件和標準軟件接口。標準軟件接口是一個公共平臺，在平臺之上運行控制軟件程序。DCP提供物理的基礎結構和可互換的特性，這樣最終用戶便可以根據需要從多家供應商選用軟件和硬件。
3.分布式控制框架（DCF）
DCF是軟件接口的標準集合，提供一個執行應用軟件（譬如控制軟件）的環境。DCF是DCP上面的層級，提供一個與OPAS有關功能一致性集合的應用程序，而不管是哪個DCN在運行。這對于建立OPAS應用程序的市場地位很重要。
4.OPAS聯接性框架（OCF）
OCF是一個免版稅的、具有信息安全且可互操作的通信框架規范。在OPASV1.0中OCF運用OPCUA。
5.高級計算平臺（ACP）
ACP是實現DCN功能性的計算平臺，但具有可擴展可收縮的計算資源（存儲、硬盤、多核CPU），用于處理那些需要更多的資源的應用程序或服務，通常這些應用程序或服務不能由小配置的DCP來完成。ACP可以用來運行不容易分布或無法分布的應用程序，也可安裝在一個預置的服務器或云端服務器上。
2.制定標準的路線和方法
為開放、可互操作和安全的流程自動化建立一個"標準的標準"，即"OPAS"，是一項復雜的事業。其制定策略是首先參考現有的各種適用的工業標準，識別這些標準與OPAS所要求的目標之間存在的差距，再與制定這些標準的相關組織一起對這些標準進行修訂，或增加適合OPAF要求的條款，以實現合適的定義。只有在現有標準都不適用的時候，才考慮開發全新的標準。為此OPAF論壇已經與下列組織達成許可協議：AutomationML、ControlSystemIntegratorAssociation（CSIA）、DistributedManagementTaskForce（DMTF）、FieldCommGroup、IndustrialInternetConsortium（IIC）、InternationalSocietyAutomation（ISA）、NAMUR、OPCFoundation、PLCopen以及ZVEI等。
OPAF制定標準的路線圖分三步走。第一步是2019年1月公布了OPASV1.0，著重于規范流程控制系統所用部件的互操作性。第二步是在2020年發表V2.0，主要規范組態（配置）和可移植性、可互換性。第三步是在2021年發表V3.0，主要是面向如何應用的規范或指南。通過每年發布一個新版本這樣的方式，OPAF旨在促使開放流程自動化能在工業界取得認可和推進，促使自動化供應商啟動開發新產品，并反饋技術意見，同時也反映最終用戶的意見。
已經發布的OPASV1.0共有5個部分：Part1-技術架構概述（資料性）;Part2-信息安全（資料性）;Part3-配置;Part4-聯接性框架（OCF）;Part5-系統管理。OPASV1.0已經有效采用了三個現有的標準：ANAI/ISA62443（被IEC采納為信息安全標準IEC62443）、OPCUA（被IEC采納為連接性標準IEC62541）、以及RedFISH（來自DMTF的系統管理標準）。這里Redfish是一種將IT軟件和軟件定義數據中心（SDDC）聚集混合的管理標準，它增強了公用的Internet和web服務的標準，讓信息直接面對現代工具鏈，不管是由人讀取，還是由機器讀取，既簡單又安全。
OPASV2.0和V2.1（關于組態的可移植性）著重于對不同的自動化部件和系統進行控制策略的移植。所謂的可移植性是指從軟件供應商購買的應用軟件，能按照應用的許可協議在一個公司內部在各種控制系統之間移植。如果經過最終用戶的識別、判斷和采納，就可以將他們的知識產權IP以控制策略的形式進行移植。V2.0和V2.1中用到的已有標準包括：IEC61131-3（用于控制概念）、IEC61499（用于執行協調）和IEC61804（用于功能塊）。未來的OPASV3.0將著重于應用程序的可移植性。
PackML--細分行業管控一體化標準的成功范例
近年來的實踐和發展表明，PackML（PackingMachineLanguage）已經獲得巨大的成功，不僅在包裝行業取得廣泛的認可和應用，而且還被作為集成架構的典型策略解決方案，為機械裝備的集成系統提供了建模的參照標準。因為PackML涵蓋了機械設備的橫向集成和運行管理的縱向集成所需要的各種功能性，其概念、策略、架構和方法完全可以適用于幾乎所有的機械設備集成系統，特別是所有運用順序控制工藝的產線。
PackML是一個經過充分驗證的獨立的系列標準。它綜合運用了許多適合于包裝過程的控制和管理的成熟工業標準，并按實際需要加以擴充和修改（見圖5）。這些工業標準有：
工控編程語言標準IEC61131-3
運動控制規范PLCopen運動控制規范
機械功能安全規范PLCopen機械功能安全規范
功能安全標準IEC61508
管控一體化標準批量控制標準IEC61512（ISAS88）
通信標準IEC62541（OPCUA）
在此基礎上PackML開發工作組已經完成大量工作，制定主要用于包裝工業控制的國際標準以解決編程、聯網和最佳實踐三大技術關鍵。比如在管控架構上運用了IEC61512（ISAS88）批量控制標準，按企業、工廠、車間的傳統結構將包裝生產線設置為車間中的流程處理單元。產線由不同功能的設備單元集成，而設備單元又是由設備模塊構成，設備模塊包含了許多控制模塊。按照這樣的系統架構貫通從上層的調度管理到底層機械設備的邏輯控制、順序控制和運動控制以及安全控制，還開創性地定義了PackTag包裝用通信標簽，用OPCUA實現了機器對機器（M2M）和機器對其上層的HMI、MES等的通信。
圖5PackML綜合運用工業標準促成OT-IT融合
總之，PackML成功地用軟件工程的方法對包裝生產過程重新定義，支持了多品種、變批量的柔性自動化高效生產；對機械設備供應商、控制和通信供應商、管理系統供應商和系統集成商提供了可操作的標準化的關系界定；而對最終用戶則是以一攬子的方式滿足了它們提質增效、降低成本的訴求。
歐洲工業界如此評價PackML："它是一個經過充分驗證的獨立的標準；它有一個完善定義的模式/狀態模型；它提供一個一致性的人機接口；它提供的公用定義通信標簽和專業術語是互操作性的堅實基礎；其架構具有高度的模塊化。"而從事工業互聯網服務的公司則高興地看到PackML為包裝生產過程提供關鍵業績指標KPI的潛力：機械設備的PLC/工業PC運用PackTag，通過OPCUA將生產信息和參數安全地傳輸到遠程監控的云端；在云端進行分析計算和判斷后，生成KPI發布到移動終端的APP，為相關的管理人員和工程技術人員提供即時的服務。
更值得關注的是它運用于其它細分行業的前景和潛力。當前制造企業面臨數字化轉型，提出任何資產都要集成、任何資產都要在線的目標；在云賦能、大數據、人工智能等領域都面臨前所未有的挑戰。
而在許多制造行業中最大也是最直接的挑戰是怎么集成制造生產線，使得不論是老系統改造更新還是新系統設計調試和投運，都能快速地攤銷其成本并獲得盈利。工業自動化業界早已認識到最大的集成成本來自軟件集成（機械裝備控制系統的協調集成、與企業業務系統的數據交換集成、與云應用的集成等）。另外，許多制造廠希望提高他們的機械設備的效率，但苦于沒有數據；有的制造廠有一些數據，但還不足以運用這些數據實施差異化；還有些已經有了很多數據，但不知如何處理數據。一言以蔽之，絕大多數制造廠處于沒有標準機制的狀態，無法支撐他們將所采集的數據按需進行分析。
其實，PackML標準所關注和側重的都是許多其它行業中最終用戶的心聲。因為OMAC開發PackML的動力正是來自用戶和系統集成商在設法將各種機械設備集成為一個協調的系統的過程中，耗費了過多的時間和勞力而效果卻不佳這樣一個事實。其原因在于不同的設備廠家有不同的編程理念和方法、不同的控制邏輯、不同的通信協議、不同的控制器平臺和操作狀態，這意味著每臺機械設備有不同的操作過程、培訓、標準和診斷方法。隨著來自不同廠商設備數量的增加，由此形成的復雜性不是按比例增加，而是呈幾何級數增加。因此，PackML在開發之初就充分考慮到：將機械部件集成為系統時一定要做到所見即所得的一致性；這樣才能為機械部件縱向和橫向的集成提供基礎，而不用考慮這些部件是哪個廠家制造的，以及用了什么樣的控制系統硬件。PackML最終實現了在不同種類和不同廠家的機械設備之間提供高度一致性，并在此基礎上建立了機械狀態的標準集合和控制功能塊的公共集合，為簡化控制系統的開發、削減系統集成的工作量、減少培訓和操作運行成本提供了可行的條件，從而極大地降低了用戶總的消耗和投入。
PackML從不規定在所定義的任意一個機械狀態下的機械操作細節，不規定每一個狀態下的功能性。這保證了OEM廠家保護自己的知識產權。PackML只規定機械設備一共有多少個狀態以及由一個狀態轉移到另一個狀態的條件。但是，只要有公共狀態的集合和定義好的標準的PackTag標簽，就完全可以實現對每一個符合PackML的機械設備的監視和控制。同理，PackML也通過狀態機和PackTag標簽使數據交換標準化，而不規定具體從哪個機械獲得數據又需要送到哪一臺機械去，或者將數據送到HMI還是上位的生產管理系統和業務管理系統去。PackML不規定具體的傳輸方法、信息安全、編碼/解碼規則，也不規定通信接口和物理介質，這就導致OPCUA、TCP/IP和以太網得以進入并發揮其所長。OPCUA提供安全的通信，承擔通信的授權（例如使用PackTag的授權）和數據的封裝。OPCUA還提供公共的編碼，PackTag可以由OPCUA進行適當的編碼和解碼。總的說來，OPCUA為在很大程度上簡化符合PackML的機械與其它機械的控制器、HMI、企業業務系統和云服務的集成提供了基礎。OPCUA可以通過實現PackML的架構和方法，控制和監視任何一類機械裝備，從而解決機械裝備集成所常見的若干戰略性問題。
著名仿真軟件公司MathWorks的Matlab/Simulink為PackML開發了一套設計、仿真和測試的集成開發環境：用Stateflow建立符合PackML標準的狀態機的模型樣板，然后通過靜態檢查和一個附加的用戶接口確保模型的狀態和轉移條件符合標準的定義。仿真則使開發人員具備執行早期和遞增驗證的能力。DesignVerifier用來生成對模型的基于覆蓋延伸的測試實例，Test用來執行和管理測試實例。在此基礎上運用自動代碼生成可針對不同廠家的PLC生成符合IEC61131-3標準的結構化文本語言ST和符合ANSI/ISO的C/C++控制程序。用Coder（C/C++）或PLCCoder（IEC61131-3的ST）所生成的代碼符合PackTag的規則，這樣便可以與其它符合PackML的軟件無縫集成。而且PLCCoder能夠從測試實例中生成一個基準測試程序，對模型進行驗證，以保證模型的行為特性和代碼的行為特性相等效。下列PLC和工業PC平臺支持由Simulink自動生成控制代碼：3S的CoDeSys、貝加萊的AutomationStudio、倍福的TwinCAT、博世力士樂的IndraLogic、羅克韋爾的RSLogic、西門子的STEP7/TIAPortal/WinAC，以及三菱電機、OMRON、菲尼克斯的平臺軟件。
綜上所述，我們可以得出以下結論：（1）作為建立在適用工業標準綜合基礎上的PackML系列標準已經發展成熟，在包裝行業有了大量的推廣和應用，而且已經形成的一整套的技術性和經濟性的良性循環的生態系統。（2）PackML標準和規范所蘊含的價值遠遠超越了它為包裝生產線解決系統集成問題的初衷。它所開創的理念、策略和方法可以直接推廣到所有的目前因集成不同廠家制造的設備而舉步維艱的應用場景。不僅可以用于食品和飲料生產、以及其他日用消費品如衛生紙品的生產，甚至對于汽車生產這樣高度復雜的場景都可以發揮巨大作用。（3）PackML可以推廣到任意制造行業解決設備集成問題，而PackML和OPCUA的進一步組合有助于解決所有制造廠在云賦能、大數據、人工智能等領域所面臨的戰略挑戰。充分認識這些經過時間和實踐充分驗證的技術，將對眾多行業降低集成成本、提高生產率、向數據驅動的智能服務商業模式轉型帶來無盡的應用潛力，產生難以估量的巨大價值。
討論
已經獲得成功應用的PackML細分行業綜合標準，貫通了從上層的管理到中間的通信，再到底層的機械控制及其運動控制，支持了多品種、變批量的柔性自動化高效生產，對機械設備供應商、自動化供應商、系統集成商，都是可操作的標準化的關系界定。看起來一條已在役的專用自動化生產線要改造成柔性自動化生產線，可以從中汲取的將不僅僅是思路，而是從策略到方法、從整體框架乃至許多技術細節。
從包裝行業的領域知識和領域模型的視角來看，這里顯然有著深刻的技術背景：PackML遵循的是基于模型的系統工程（MBSE）的思路，通過建立和利用領域模型（即PackML的狀態圖）而不是通過建立和利用文檔作為信息交換的主要手段。PackML從概念設計階段開始，貫穿整個開發階段，直到后續的生命周期階段，都通過形式化的建模應用來支持系統的要求、設計、分析、驗證和確認。特別是PackML選擇OPCUA作為互操作的標準，這與OPCUA近年來被德國工業4.0的資產管理殼AAS選中作為其標準和技術體系的支撐部分，有非常好的契合。其中的原因在于OPCUA的信息模型及其建模工具和運行環境能夠同時兼容并融合PLCopen/MTconnect/AutomationML/機器視覺/通信等MBSE模型，當然也包括PackML的MBSE模型。
從正在開展且取得部分中間成果的開放流程自動化標準OPAS來看，其涉及的面更廣，對未來工業自動化的發展影響更深。其最深刻的顛覆在于一改現有的工業控制系統硬件軟件捆綁的封閉面貌，開創了按照最終用戶要求集成不同供應商的硬件和軟件部件，就能夠構筑具有互操作性特性的控制系統的全新局面。也就是說，在未來的DCS和PLC系統中硬件與軟件是徹底解耦的，用哪些硬件部件和軟件部件構筑控制系統的主動權完全在最終用戶手中，只要遵循OPAS規范，系統一定能實現互操作性運行。進一步的發展將朝著即插即用方向實現同類型硬件部件和軟件部件的可互換，為此就要求在進行系統組態和配置方面遵循相應的規范，即在不同組態工具鏈之間建立符合一致性數據交換國際標準AutomationML（等效于IEC62714）的接口，這樣就可以保證所定義的組態信息和Layer-F（即開放聯接框架層OCF，見圖3）的應用軟件可以被不同供應商的組態工具所輸入，也可以被不同供應商的組態工具所輸出，從而實現了組態的可移植。
這兩個"標準的標準"展現了充分的系統性。所謂的系統性是一種復雜系統的狀態、質量或條件。這種復雜系統雖然是由許多相互連接的部件所構成，但系統作為一個整體所展現出來的行為特性遠遠區別于其組成部件的單個行為特性。因此系統性就是一種屬性，將最大而且直接地影響創新技術被采用的廣泛性。開放流程自動化標準OPAS和PackML標準都是以它們鮮明和完整的系統性，已經和正在顯露出無窮的生命力。
整體上說，國外在這個方面的工作做得非常扎實，不但是可操作、可實現的，而且還是統一的。不管是制定新的面向行業應用的標準規范的能力，還是對當前現有的各種標準規范的組合應用能力，國內外的差距簡直可以說是天壤之別。在國內，大家一窩蜂地跟隨某一潮流，大都為了當前短暫的利益單兵作戰，彼此間沒有協同和統一；更沒有組織和單位去發起和創建服務于公共領域和細分行業的綜合性標準，形不成合力，更遑論形成一種生態。我們都說，得標準者得天下！在開發"標準的標準"這一戰略能力方面的長期缺失，很可能成為我國工業在自動化、信息化和智能化發展道路上將來被進一步拉大差距的根源。
共0條 [查看全部] 網友評論