在IT技術飛躍發展的年代，流程工業自動化的傳統控制系統DCS正在步入“老態龍鐘”。它的封閉性和專用性，極大地阻礙了OT與IT的深入高效的融合。
一個幽靈正在接近工業自動化的傳統地盤。它巨大的潛力，將致使工業自動化廠商長期保有的業務模型變得日趨陳舊，不得不升級和轉型。它還會要求廠商采用正在如潮水涌來的軟件技術和來自云計算領域的實踐?？梢钥隙ǖ氖?，這一顛覆將被幾乎整個新的軟件技術，而非硬件技術所驅動。當這一顛覆第一次沖擊連續過程自動化的時候，這些新穎的軟件技術的力量和價值，將推動流程工業以及其新興的業務模型進入許多其它的領域，包括工廠自動化FA和工業物聯網IIoT。驅動這一顛覆的一個重要因素就是軟件應用的容器化（containerization）。
流程工業自動化的百年新芽
自上個世紀二十年代，流程工業開始了氣動儀表和氣動控制器的生產現場應用，最早是在1959年出現了單回路電子控制器。上世紀70年代8回路數字式控制器出現，流程工業已經運用生產數據的歷史記錄、現場總線網絡、靈活的系統組態和規模不大的人機界面。
80年代之后，100回路規模的數字式控制系統DCS開始出現，在L1層開始運用功能塊、順序控制和自診斷技術；在L2層已經有了按生產的需要配置不同規模的系統，大大提高了系統的可用性；在L3層相關的計算機系統已經接近當時的最新水平。
到了2000年，1000回路規模的數字式控制系統DCS成為主流。流程工業在L1層普遍運用高性能、多功能的DCS系統，配有HART或FF現場總線；而在L3層大量使用低成本的服務器。

之后的發展，特別是近些年來，DCS面臨著一些亟待解決的三個重要問題。一個是老齡化。許多正在運行的DCS系統已經服役二三十年，備品備件所需的元器件已經停產或改型，如何低成本且不停產或少停產的進行升級改造，這是最終用戶十分關心的問題。第二是繼承性。經過幾十年運行，控制系統積累了大量的生產運行數據和智能運營的知識庫，在控制系統的升級改造的過程中如何繼承和保護這些軟資產，不容回避。第三是融合性。在IT技術以高度密集和高速度的方式進入流程工業的今天，OT技術不得不緊跟IT的步伐，不失時機的與之融合。
等不及供應商的動作了。
這一次，是一些有遠見的最終用戶開始打破僵局，采取大刀闊斧的舉措。在他們的積極推動下，流程自動化行業出現了開發下一代開放的分布式自動化技術的全新局面。未來的控制系統追求的目標很具體：能夠低成本替代原有控制系統，且可按現場需要配置系統；運用先進的邊緣設備，但仍可沿用原有的I/O及其電纜布線；具備良好的APP工業軟件的可移植性；方便與一流的部件和第三方軟件集成。還要求用高可用性的實時數據中心構成虛擬化的系統，既要向下有效連接邊緣端與I/O端口，向上又要方便OT與IT的融合。
而這些顛覆性的技術，強烈地受到近些年來IT行業并發的若干個重要技術的影響和推動。其中最重要是大量應用的系統虛擬化，以及云計算、運用廣泛的開源軟件（OSS）、新軟件技術集成和軟件開發和部署（DevOps），以及超高可用性的部署平臺。 
一百年的老樹，正迸發出全新的枝椏。
重現當年小型機現象
自1970年PLC和DCS進入自動化領域之后，處于ISA 95的L1和L2的控制層的自動化硬件和軟件結構一直沒有變動，迄今為止自動化市場的結構也一直圍繞著捆綁式的自動化硬件和軟件在演進。
每一個自動化的供應商都開發自己的軟件環境，并將這種軟件環境轉交給最終用戶，而通常他們并不能深入這一軟件環境，只能通過供應商提供的控制器組態軟件工具與控制器交互。這一種結構方式與1970年的小型計算機市場非常類似，幾乎每一個小型機的供應商都是以硬件軟件捆綁的應用方式和軟件工具，以及自己的渠道伙伴和軟件供應商進入和占領市場。
企業控制的系統集成國際標準IEC/ISO 62264脫胎于ISA 95。雖然這一標準是在普度CIMS模型的基礎上發展起來的，適用于流程工業、離散制造業和批量過程工業，但畢竟最先獲得流程工業的普遍支持和實踐應用。工業4.0的RAMI4.0參考架構模型中的“Hierarchy Levels”的維度，主要是借鑒了ISA 95的概念。由于最終用戶對此ISA 95參考模型的認可和青睞，在美國和歐洲工業軟件的開發廠商一般都以此模型為依據。為了更好地服務于智能制造和IIoT的需要，如圖1所示，ISA 95在原來的L0至L4的層級之上增加了L5級（企業接入云系統的集成）。

關心現有系統運用新技術的升級遷移是現有的工廠和成套設備又一個關鍵的問題。制造廠不允許按整個規模替代已安裝和運行多年的ICS工業控制系統，這可能會對運行造成很大的破壞。而現有系統的數據庫積累和容納了大量具有智能特性的數據，由于這些都是在專有系統中實現的，很難用文件描述，或者難以升級遷移到新的平臺。制造廠需要非破壞性的路徑使他們能夠對現有系統進行更新和升級改造。
以?？松梨跒槔錈捇S每天從500萬個變量（tags）中產生13億個數據記錄！每天13億，這還不包括機械數據。存取這么多數據的能力，以及將數據進行分析利用并轉換為活躍的可起作用的信息，是業務的關鍵需要。
企業迫切需要從系統到邊緣再到云端實現分析的APPs，可是目前卻不那么容易完成。供應商應對難題的解決方案，似乎落后了一大截。舉一個現實的例子。美國?？松梨诠驹罅渴褂肏oneywell的DCS系統TDC 3000，這些服役二、三十年的系統其備品備件最多可用到2025年。也就是說大約還有五六年的時間，不得不面臨升級改造的嚴重問題。而且為了讓這些老系統能夠利用Honeywell的云基開放虛擬工程平臺，使TDC的環境虛擬化，還能夠支持與WirelessHART等無線變送器、儀表的聯接，利用低成本、小資源的仿真系統等，他們用了七年時間開發了Experion LCN R501.1，可以仿真TDC老系統的系統軟件，實現100%的二進制兼容和互操作?；四敲撮L的時間在技術上得以實現，其成本可想而知。
開放的架構
多年前?？松梨诘难芯亢凸こ滩块T公開倡議開發一個全新的、基于標準的過程控制架構。2014年他們編創了一個基本特性文件，在2015年的ARC論壇上分發，受到相當的關注，引發了熱烈討論，也得到具有相同要求的其它最終用戶的支持。由于美國開放集團（The Open Group）在為其它工業部門創建標準方面的專業性和成功表現，?？松梨跊Q定委托這個非盈利的第三方，組織一個新的標準化活動，面向流程控制工業中業務和技術的挑戰，開發一個新的系列標準。
The Open Group創建了開放流程自動化論壇OPAF（the Open Process Automation™ Forum），吸收一批最初的成員，并于2016年11月在舊金山召開了第一次會議。截止到2018年底，該組織已經有超過133個團體成員，包括最終用戶、硬件和軟件供應商、系統集成商、學術單位和標準化組織。顯然這是一個以大型的最終用戶為主及其支持者流程自動化供應商組成的共同體。
這個組織的使命就是維新。已經20多年沒有變動的DCS的架構，在迅速發展的IT技術面前，將如何重生？它覆蓋了最新的分布式云計算技術和虛擬化技術重新定義DCS和PLC，以及與優化運營密切相關的先進控制和MES（參見圖3）。

圖4給出OPAF的架構圖。OPAF所定義的DCN表示分布式控制節點，它是由DCF（分布式控制框架）和DCP（分布式物理基礎設施）所組成。圖中黃色所標的均為OPAF所定義的部件和模塊；海藍色所標的則是非OPAF定義的其它系統，如傳統的DCS、PLC、分析儀表系統、電氣系統、機監控系統、……，但它們都可以經由DCN接入OPAF所定義的聯接性框架OCF。

即使是處理企業業務的事務性平臺（企業的IT數據中心）和其它非OPAF環境的系統，都能經由DCN接入OCF。至于執行ISA 95的L2和L3功能（如先進控制算法、MES等）的OT數據中心直接與OCF相聯，這一先進計算平臺采用容器化的軟件技術，將不同功能的APP組織容納在不同的容器中，形成高效執行軟件子系統。
關鍵使命
作為老牌的實時操作系統的開發商風河（Wind River），已經定義并完成了一個新一代的平臺產品Titanium Control Platform，其中工業控制系統的“虛擬化”和“軟件定義”已經運用嫻熟。針對那些日趨老化的傳統工業控制系統不能支持與工業物聯網連接的問題，這一平臺承擔了預置云規模的基礎架構，將幾個關鍵基礎架構公司的平臺軟件（工業級云管理中間件open stack，工業級Linux，工業級存貯集群ceph）協調組合，分別構成控制節點、計算節點和存貯節點的協調管理，從而以高性價比的方式為傳統控制系統提供升級改造的可能（詳見圖5）。

風河在實時操作系統的長期經驗與寬泛的低延遲虛擬化和預置的云計算技術組合起來，在OPAF主導的以任務為關鍵的（mission critical）驗證性項目應用中獲得成功。所謂以任務為關鍵就是需要每天24小時不間斷運行，譬如電信系統、航空管理系統、醫療系統、金融分析系統等。同樣，用于流程工業的DCS，也是屬于必須不間斷運行的控制系統。
趨之若鶩
在The Open Group的管理下，該創新項目謀求定義一個可以運用于多個流程工業（化工、煉化、發電、制藥、冶金、紙漿和造紙等）的流程控制架構，滿足標準化、充分安全性和互操作性的要求。當今工廠中所用的任意DCS和PLC的功能，都可以被這些由服務器和許許多多計算資源和存儲資源要求足夠小的自動化邊緣設備組成的新系統所替代。圖6給出了從現有已在役的DCS/PLC系統逐步地升級遷移到這些小的邊緣設備，以及預置的高可用性的服務器的發展趨勢。

OPAF的目標是對ISA 95的L1和L2的功能標準化  這些功能是：現場設備和儀表的基本的輸入和輸出，以及執行調節控制的功能塊。目前這些功能都是由專用的DCS和PLC來完成的，規模約為100至1000個PID功能塊。?？松梨诤推渌恍┳罱K用戶深信不疑可以用更多但更小的邊緣設備作為過程控制器。這些小的硬件設備每臺可以控制少到一兩個回路，實際上執行過程自動化的微服務。
經過驗證的系統使這一創新項目由可能實現進展為現實。OPAF與洛克希德馬丁公司和其它公司的一個團隊緊密合作，在OPAF架構和由OPAF所選擇使用的工業標準的基礎上開發了一個原型系統，進行驗證。
參與這一概念驗證系統工作的OPAF成員包括：R.STAHL（提供常規I/O），施耐德電氣（提供智能I/O），Intel（提供分布式控制節點DCNs），NXT control（已被施耐德收購，提供DCNs和軟件控制器，ABB（提供軟件控制器），AspenTech（提供先進控制軟件APC），Inductive Automation（提供人機界面HMI），ANSYS（提供另一個HMI），Wind River（提供實時先進計算平臺RTAC）。
驗證的結果令人欣喜，這表明OPAF架構已經由概念轉化為正在運行的概念驗證的系統。在工業自動化界已經討論了十多年的開放自動化系統的可能性，正在一步一步的變為現實。對于流程自動化的行業這不啻為一件激動人心的事件。在2019年二月該組織正式推出了新標準的第一版O-PAS Version1.0，給出了一個與供應商無關的參考架構；而且還計劃2020年在埃克森美孚和其它至少兩個現場進行試驗。
容器化軟件技術
發源于UNIX的軟件容器化技術，經過LINUX開源軟件的大力推動，業已大大降低了門檻，成為可以較普遍掌握和運用的技術。對于軟件開發商和最終用戶，軟件容器提供兩個巨大價值：1）軟件容器技術可為任意數量的機器、物理或虛擬對象，提供自動的配置、部署和管理分布式應用的方法和手段。（2）容器軟件開發的過程創建了一個“容器圖像”的存貯庫，在軟件交付時，這一容器圖像形式可在不同于原來開發的軟硬件環境的另一種環境中協調地創建，同時還自動建立了包括運行應用軟件所要求的所有的軟工作環境。
開發容器圖像的過程已經完成了一種高度的抽象，使它獨立于異構的多CPU、操作系統、軟件版本，以及在開發期間運行的環境。由于容器圖像劃定的范圍僅容納在一個應用軟件內，所以容器會將開發者的注意力從管理計算機轉移到去管理應用。這極大地改善了應用的部署能力和可見性。容器的開發、部署和業務流程的軟件工具在前五到十年中已經臻于成熟。顯而易見，傳統的嵌入式系統軟件技術在交付和管理分布式和高可用性的應用軟件的能力方面，根本無法與容器軟件技術相抗衡。
目前在工業自動化行業和汽車、電信這些大行業中，正在為分布式自動化或功能性創建參考架構，甚至在創建特定的解決方案。
全球的汽車工業目前正在努力開發一種參考架構，謀求使一輛汽車兼具安全、自動駕駛、遠程服務、信息娛樂和舒適的性能。這包括定義一個專門的被稱為汽車級的Linux（Automotive Grade Linux ）的Linux軟件集。在電信行業，許多公司正在開發包括信號收發基站的基礎NFV（網絡功能虛擬化），以及和電信中央交換器的虛擬化處理功能CORD（Central Office Re-architected as a Datacenter）。
為迎接數字化轉型的挑戰，這些新創項目具有許多共同的特點：要求大規模而且長生命周期的遠程部署軟件的管理，在工業軟件的開發、部署和維護，以及所有類型的硬件（包括嵌入式設備）都有所突破，而不是漸近的改進。
這些突破正在順利進行或已經完成。一些領先的軟件容器管理和協調配置的開源工具已經具有實時進行分布式應用軟件的部署和管理的能力，而且在商業上達到可以提供的水平。可以預期，同樣的軟件工具將也能融合到開放過程自動化的創新項目中。
圖7釋出容器化軟件的原理框圖，圖中表示Docker將應用軟件分隔為若干個可管理的APP功能模塊，并將它們打包在一個容器中。Docker集成Linux的容器化技術的目的，一方面是為了解決應用軟件的開發能適應每一種開發環境，另一方面是為了解決代碼依賴性的跟蹤、應用軟件的可擴可縮，以及僅僅修改升級個別APP而不會影響整個的應用軟件等問題。 


圖8則表示將容器技術如何運用于OPAF的架構，構成一個分布式控制節點DCN。根據實際的需要，可在在一個DCN容器中容納所需要的各種APP，如監控和管理DCN的APP、現場總線和工業以太網的APP、現有的過程控制算法APP、新開發的過程控制算法APP等等。

從技術成熟度來講，基于容器的軟件部署已經高度標準化了，以開源的形式提供使用。它運用廣泛，并為許多不同類型的平臺所成功運用，從非常的大的系統（Google）到最小的計算機系統（樹莓派，Raspberry Pi），都已經得到現場運用的驗證。
軟件開發的三大類別
從發展過程看，軟件開發已經分成了三個主要的類別：企業軟件（業務運行）；嵌入式軟件（運行于設備、模塊等“物”中）；最近一些年形成的云軟件（運行于第三方的云資源上）。盡管這三類軟件存在著一些重疊，但它們各自有自身獨特的開發及其工具環境。

軟件開發的三個類別
在下一個五年或更多一些時間內，云軟件開發技術相比其它形式的軟件開發，顯然會成為主要的形式，而且這三種軟件開發將會極大地融合匯聚。更值得關注的是，這一融合匯聚將會被迅速發展的開源軟件的步伐所推動，而不是由目前工業自動化工業所采用的軟件開發方法邁著緩慢的步伐在前行。
這一融合匯聚的第一階段將是所謂原生云軟件（cloud-native software）的開發，開發常規企業軟件與云軟件的融合。當云原生軟件以向下擴展的形式聚焦嵌入式軟件在物聯網，特別是工業物聯網的要求時，這將推動第二階段的融合。工業自動化已邁開了這樣的步伐，在過去的兩年中已經在許多工業產品導入了Docker和Linux容器的技術。除此而外，一種正在云執行平臺上出現、并被稱為單核與嵌入式軟件開發低資源的專業組合的云技術，也不容忽視。單核技術目前還活躍在許多研究領域中，但很快會轉入應用。事實上風險投資已經在向為企業和工業IoT市場開發單核產品的方向投資。
云計算是一個有2500億美元的研發投資的大業務。它正在迅速增長，并主要被諸如亞馬遜、阿里巴巴、微軟、Google、IBM及相關巨頭所掌控和關注，競爭非常激烈。有理由期望用于云計算業務的開源軟件技術將會快速發展和推廣。不出5年時間所有軟件的開發將會使用云軟件開發的方法。在軟件的“食物鏈”內，如果“軟件正在吞噬世界”，那么吞噬軟件開發的軟件則是云軟件開發及其工具。甚至在嵌入式軟件的特殊的領域內開發幾乎會被當前和未來的云軟件技術所左右，或者說被當前和未來的云軟件技術所吞沒。
統一與分歧
下一代的DCS和PLC正在向開放、分布式、具有充分的互操作性和內在的信息安全的架構發展。而要有效地實現這樣的架構，需要大量地采用開源的云計算軟件技術。在今后的分布式控制系統DCS和PLC的自動化應用，容器軟件技術一定會大放異彩。可以毫不夸張地說，有效的運用容器部署和業務流程編排軟件很可能成為未來過程自動化系統成功的關鍵因素。
技術上可以說是大勢所趨。但在業務模式上卻出現兩種對立的觀點。OPAF發布的業務指南中指出，關鍵的利益攸關者是多元化的，包括最終用戶、系統集成商、硬件供應商、分系統供應商、軟件供應商和服務提供商。在下一代的流程自動化系統中，系統集成商/分系統集成商的角色將越來越關鍵。從現在的單一的DCS供應商轉換為系統集成商，將是一次流程自動化格局的重塑。
然而以DCS系統主要廠商之一的艾默生則并不想要如此復雜的局面。它堅持認為，用戶寧愿依賴一兩個戰略性的的供應商，而不是依靠少數幾個協議和系統集成商的能力，去將幾千個智能設備集成起來。艾默生這一派期望繼續沿襲流程工業迄今為止慣用的方法，即一個巨大的工程項目只能由一兩個有完全能力的戰略承包商負責。由于意見不合，艾默生于2018年還退出了OPAF這一組織。
另辟蹊徑的德國人
在美國人牽頭的OPAF重新定義現有DCS、PLC之后，德國流程工業用戶組織NAMUR提出了另一類的開放架構NOA，并計劃在2021年至2022年以IEC的標準發布。
德國NAMUR倡議的NOA（見圖9），堅持在原有的工業信息化、自動化金字塔結構的前提下，引入確有實效的IT技術，與OT技術深度融合，提升運行維護的優化能力。

由圖9可以清晰地發現：（1）NOA開放架構其頂層設計的出發點和目標都是圍繞不改動現有的流程工業自動化、信息化的金字塔結構考慮的。因此其開放架構的構想是在原有的基礎上引入云計算技術和其它新的IT技術，以加強和充實原有架構開放性不足的缺陷，又不至于由于開放而喪失信息安全的內在保證。（2）NOA所設計的范圍涵蓋由現場級、基礎自動化級、MES級到ERP級，而不像OPAF僅涉及L1和L2。（3）充分考慮用戶已有資產的可用性和安全性，在進行IT與OT融合升級時不會傷筋動骨。（4）作為德國提出的流程工業的開放架構，NOA還需要充分考慮與德國工業4.0的對接，因此增加了按工業4.0資產管理殼的理念和方法對現場設備進行管理。（5）但NOA沒有對現有的DCS如何升級遷移作出任何考慮，面對現有在役DCS日益老化，備品備件難以長期供應的困境，沒有給出解決方案。
筆者認為，作為從不吸收自動化制造廠商參加的純用戶組織，NAMUR更多地是從用戶目前的利益出發，其合理性表現在盡量挖掘現有系統的潛力，能少花錢就不多花錢。

圖10進一步詮釋了NOA架構的構想。在這個體系中，核心的過程控制是具有確定性的控制系統DCS，這是現存的專用系統，不具備開放性。為實現運維監控和優化，NOA的解決方案是在流程工業的裝置這一級引入具有開放性和可靠性的IT基礎架構，這是一個相關工業軟件APP平臺，執行作業調度、先進過程控制、報警管理，同時也實現對工業4.0設備的管理（即按工業4.0要求完成資產管理殼的管理）；為配合優化和預測性維護所加裝的低成本多參數的傳感器和對生產裝置監控的振動檢測系統，全都納入這一系統?，F存的的DCS系統通過開放的OPC UA與裝置級M+O系統連接。在此基礎上再在多個已建成的裝置級M+O系統之上，建立集中的全局的M+O系統，執行排產、先進的分析、歷史記錄、可靠性管理、集中的HMI，以及生產網絡的仿真等功能。這同樣應該是一個開放可靠的相關工業軟件的APP平臺。雖然現有的DCS系統只有專用的接口，但為了與集中的M+O系統連接，需要將其轉換為開放性的接口。這樣的設計達到了NAMUR不對現有DCS系統加以改動的初衷。
小記：兩行白鷺上青天
盡管在如何實現開放性上，特別是DCS如何升級遷移上，OPAF與NOA大相庭徑，不過他們還是找到了基礎要求的共同點，即他們都需要完善的描述現場設備的信息模型。在這一點上，他們都支持由現場通信集團（FieldComm GROUP） 、OPC基金會和ProfiBUS/ProfiNET國際組織正在合作開發的流程自動化現場設備的信息模型PA-DIM。
另外，這些年不事聲張在開發的先進物理層協議APL也大有進展，利用單根雙絞線傳輸10MHz以太網信號同時為現場設備供電的技術，已經日趨成熟。
自此，在世界范圍內圍繞流程工業開放自動化的未來發展，已經出現了兩條明顯不同但大有潛力的技術路線。流程工業自動化完整的未來藍圖，基本成型。