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