工業自動化領域正在出現重大技術變革。這種變革有可能使長期供應商的商業模式過時。它還要求所有類型的供應商采用云計算領域的新興軟件技術和實踐。這種變革幾乎完全由新的軟件技術而不是硬件驅動。雖然變革將首先影響連續過程自動化，但這些新軟件技術的功能和價值將推動它們及其新業務模式進入許多其他領域，包括工廠自動化和工業物聯網（工業互聯網）。
推動這種變革的技術是軟件應用程序的“容器化”。軟件容器技術幾十年前在UNIX操作系統中誕生，并且在龐大的Linux開源生態系統和主要云計算服務供應商的推動下迅速發展。
軟件容器為軟件開發人員和最終用戶提供兩個主要價值。首先，它們提供了自動化方法，可以跨任意數量的物理或虛擬機部署和管理多個分布式應用程序。其次，容器軟件開發過程創建了一個“容器鏡像”存儲庫——可以協同創建的軟件交付成果，并包含在特定計算機環境中運行應用程序所需的所有工件。
容器鏡像的開發創建了一個強大的新抽象，將應用程序與異構CPU、操作系統、軟件版本以及它們在生產期間運行的環境隔離開來。此外，由于容器鏡像的范圍包含單個應用程序，因此容器將開發人員的注意力從管理機器轉移到管理應用程序。這大大提高了應用程序部署和可見性。在過去的五到十年中，容器開發、部署和編排軟件工具已經成熟。它們現在遠遠超過傳統的嵌入式系統軟件技術，能夠提供并管理分布式和高可用性應用程序——例如未來分布式控制系統（DCS）的自動化應用程序。
垂直整合的商業模式的終結
自從20世紀70年代引入PLC和DCS以來，控制級別（ISA 95級別1和2，企業系統與控制系統集成的國際標準）的自動化硬件和軟件架構從根本上沒有改變。一直到今天，工業自動化市場結構圍繞著捆綁的自動化硬件和軟件。這種結構非常類似于20世紀70年代的小型機市場，每個主要的計算機供應商（Da-ta General，Prime，HP等）都推出了自己獨特的捆綁應用程序和軟件工具集，以及他們自己的渠道合作伙伴和獨立軟件供應商（ISV）。
但是，最終以用戶為中心的開放式過程自動化論壇（開放式集團論壇，華為、IBM、富士通、甲骨文等是白金會員）（Open Process Automation Forum （a Forum of The Open Group））的形成以及大部分過程自動化供應商社區的支持表明，這種高度垂直整合的業務模式已經受到威脅，可能正在達到其終點。
傳統嵌入式系統模型的終結
對于嵌入式系統和傳統嵌入式系統軟件開發的傳統市場而言，最終也是如此。網絡（分布式）嵌入式系統——特別是工業嵌入式系統——在其生命周期中的開發、部署和管理方式需要進行轉型。
目前，許多嵌入式軟件（即使它起源于開源）包含許多專有元素。出于安全原因，今天更新嵌入式軟件越來越重要，但遺憾的是，這通常很難或不可能。因此，網絡安全已經成為嵌入式系統的一個長期問題，特別是在消費電子領域。這也會產生其他問題。應用程序不靈活、操作系統和軟件工具鏈是分散的、開發速度很慢、硬件/軟件集成仍然存在問題。更糟糕的是，經驗豐富的嵌入式系統軟件開發人員比較缺乏。
雖然嵌入式系統軟件市場確實感受到了Linux的影響，但傳統嵌入式市場的其他方面仍然存在多年。市場需要改變技術，進入工業物聯網、工業4.0、智能制造等時代。未來的工業嵌入式系統將要求整個軟件堆棧可以自動升級——從頂層應用程序到底層操作系統和虛擬機管理程序。
那么，如果當前用于工業自動化的技術堆棧不再能夠很好地發揮作用，那將被什么取代呢？
容器軟件擾亂了許多行業
最近，ARC Advisory Group（ARC咨詢集團）與過程自動化業務的C-Level高管進行了討論，他對開放式過程自動化系統的前景持悲觀態度。根據這位高管的說法，“我們的客戶不希望必須在許多不同供應商的數千臺設備上管理其應用軟件。”
他認為，通過少數供應商制造的控制器管理工廠的自動化軟件是很困難的。對于管理不同供應商的應用軟件，和不同供應商的數百個硬件模塊單元或工廠，這需要技術的重大進步。與現在工廠中運行的最新過程自動化系統相比，此類系統在部署和編排（Orchestration）軟件方面必須要大大提高。
然而，工業自動化行業和其他幾個主要行業，現在正在為高度分散的自動化和功能創建參考架構甚至特定解決方案。這些舉措有許多共同點。
例如，全球汽車行業正在開發一種參考架構，該架構將包含安全性、車輛自主性、遠程服務、信息娛樂和便利性的車載功能。這包括定義一組稱為汽車級Linux的特定Linux軟件。在電信這個另一個龐大的行業中，公司正在開發在蜂窩基站和電信中心局交換機中虛擬化處理功能的架構。這兩項計劃稱為NFV（網絡功能虛擬化）和CORD（中央辦公室重新設計為數據中心）。
汽車、電信和工業自動化等行業的數字化挑戰將需要大規模和長期生命周期地管理遠程部署的軟件。這將需要在工業軟件開發、部署和維護以及包括嵌入式設備在內的所有類型硬件方面取得突破（而不是逐步改進）。
好消息是這些突破已經存在?，F在，用于軟件容器管理和編排的領先開源工具現在可以實時部署和管理分布式應用程序。理想情況下，這些相同的工具將被納入新興的開放式過程自動化計劃中。
軟件開發的融合
從歷史上看，軟件開發分為三大類軟件：企業軟件（運行業務），嵌入式軟件（運行于內部），以及云軟件（運行在第三方云資源上）。雖然他們之間存在一些重疊，但它們各自也有一些獨特的開發工具。
在未來五年左右的時間里，云軟件開發技術似乎將主導其他形式的開發，而這三者將在很大程度上融合。此外，這種融合將以開源軟件的速度發展，而不是以當今工業自動化行業典型的軟件開發速度，后者慢得多。
這種融合的第一階段將是所謂的云原生軟件的開發，標志著傳統企業軟件和云軟件的融合。用于這些任務的部署和編排軟件工具將變得司空見慣并且眾所周知。當按照縮小形式的云原生軟件滿足嵌入式系統軟件的要求時，這將推動第二階段的融合——嵌入式系統軟件是物聯網（IoT）的“面包和黃油”，尤其是工業物聯網（工業互聯網）。
在過去兩年推出的許多工業產品中，工業自動化領域現在可以看到使用Docker和Linux容器部署應用程序的方式。除此之外，一種名為Unikernels的新興云技術將嵌入式軟件開發的小規模原則與云執行平臺相結合。雖然Unikernel技術目前主要是研究領域，但這可能會改變。事實上，風險資本已經投入到為企業和工業物聯網市場開發單核產品的公司。
此外，云計算是一項價值2500億美元的業務，擁有大量的研發資金。它正在迅速發展，并由亞馬遜、阿里巴巴、微軟、谷歌、IBM等大型科技公司主導。這些大公司正在為一個龐大且不斷發展的業務展開激烈競爭。期望云計算業務中使用的開源軟件技術將迅速而廣泛地發展，這是合理的。
用于工業自動化的小規模云
ARC認為，五年內所有軟件開發都可能使用云軟件開發方法。在軟件“食物鏈”中，如果“軟件正在吞噬世界”，那么正在吞噬軟件開發世界的軟件就是云軟件開發和工具。即使在嵌入式軟件的封閉和專業化的世界中，也可能會被當前和未來的云軟件技術超越。
這并不是說所有應用程序都將在云中運行。相反，云軟件使用的軟件開發和部署技術將超越并主導其他形式的軟件開發。這有兩個可能的原因。
第一個原因是，云雖然巨大，但卻是一個相對較新且仍在不斷發展的行業。也就是說，今天的熱門云計算軟件技術與云計算本身一樣新近。OpenStack、Cloud Foundry、Docker和Kubernetes（K8s）等軟件在過去五到十年中都已作為開源軟件發布。云計算專家一致認為，當前的云計算模型包含大量冗余，可以大大改進。因此，人們應該期待這一領域的快速和持續的技術發展。
很好，但這就是云。工業自動化市場為何要關注這個問題？
這導致了期望云軟件開發占據主導地位的第二個原因。這是因為云軟件技術可以縮小到更小的系統，這也是開放過程自動化論壇關注的工業自動化系統類型。讓我們來看一個關鍵的例子：容器軟件。
容器和工業自動化
容器有什么意義？人們可以看到為什么這些對云和企業來說很重要，但為什么它們對工業自動化等應用很重要？
讓我們退后一步，回顧一下容器的歷史。容器技術始于20世紀90年代末，當時Sun Microsystems等公司正在構建非常強大的UNIX服務器。從操作和管理的角度來看，更容易在這些巨大的機器中對應用程序進行分區，而不是將所有進程一起運行。容器背后的原始概念是在應用程序之間創建分區，以便更輕松地管理大型服務器。
容器技術的缺點是實現它需要技術嫻熟的UNIX系統管理員。對于當時的大公司（Sun Microsystems，Oracle，SAP和其他公司）而言，這并沒有什么問題。但是，對深度UNIX管理專業知識和大型服務器的需求限制了容器在相對較少的公司中的使用。
什么改變了？為什么容器現在如此受歡迎？隨著容器技術在Linux中的應用，一家風險投資公司開發了軟件工具，大大簡化了Linux容器的創建、部署和操作。這個名為Docker的軟件五年前發布給開源社區。
因此，在過去的五年中，對容器的興趣在云計算和企業計算領域呈爆炸式增長。此外，在過去幾年中，許多工業自動化產品也隨Docker一起交付，使系統集成商和最終用戶能夠輕松地將自己的應用程序與這些產品集成。
早些時候，我們提到了針對電信的NFV和CORD計劃（一種邊緣計算開源平臺）。在電信行業，全數字化將把所有模擬信號處理轉移到網絡的邊緣。從蜂窩塔到中心局的所有其他服務將通過軟件執行并以數字方式完成。結果將是一個高度靈活的基礎架構，可以在不更改硬件的情況下添加新服務。而在以前，電信網絡運營商如何設想能夠在多年的生命周期內管理如此龐大的軟件定義基礎設施？
最后，這也許是最重要的一點，容器軟件可以縮小到非常小的系統。Docker運行時軟件已移植到小型ARM核心單板計算機，現在用于支持工業物聯網應用和服務。
Docker和Kubernetes
作為一個額外的好處，開源軟件世界已經在很大程度上融合在一個容器編排工具上（在此上下文中的編排是指管理容器部署的軟件）。這個開源容器編排軟件工具Kubernetes起源于谷歌，該公司通過使用容器實現的SaaS產品證明了其可靠性。今天，Kubernetes可能是企業軟件領域最熱門的開源項目。ARC認為，對于那些擁有工廠運營或工程經驗的人來說，與他們自己組織中的IT專家討論其對未來自動化架構的潛在適用性是值得的。畢竟，Docker和Kubernetes不僅僅是管理和構建容器的技術。
不僅僅包含用于存儲或傳輸應用程序的文件，術語“容器”還指使用內核中內置的功能。這些功能創建了一個“包含”的環境，用于在內核上運行代碼。代碼認為它是唯一的應用程序。嚴格來說，容器是執行時體驗，而不是分發時體驗。
安裝到文件中并作為創建容器的基礎分發的軟件工件稱為“容器鏡像”，這可能是一個令人困惑的術語。容器鏡像是使用Docker或其他容器開發工具創建的軟件工件。
當使用容器鏡像（而不是軟件包管理器）時，軟件分發和生產中的部署是用戶驅動的和應用程序驅動的而不是供應商驅動的。容器可以極大地減少軟件最終用戶的集成負擔，使他們能夠更多地關注他們的應用程序，同時讓容器鏡像的構建者專注于目標系統依賴性和配置。
當供應商而非用戶需要驅動軟件分發時（如軟件包管理器的情況），最終用戶或系統集成商負責組裝正確版本并正確設置所有運行時配置參數。通過包管理器提供的軟件是要集成的模塊化軟件單元。另一方面，容器鏡像是從最終用戶角度來看的單個但完全集成的應用程序。
如前所述，對于作為嵌入式系統的聯網設備，“終點就在附近?！闭雇磥?，高價值設備和服務將得到遠程監控、管理、更新和服務，其軟件堆棧需要提供服務。這需要極高的自動化水平。因此，在未來的嵌入式系統中需要Docker和容器，包括工業自動化中的嵌入式系統。
工業自動化的容器和編排
與當今工業自動化中使用的嵌入式系統技術相比，容器具有幾個重要的優點，可以使工業自動化系統對于最終用戶和供應商而言更簡單，更有價值。這些包括：
- 容器專注于應用程序而不是機器。這有效地將應用程序開發與運行應用程序的計算、存儲和網絡系統的管理分離。通過使應用程序開發人員和系統支持專家能夠有效地解耦并且干擾更少，這可以在系統的整個生命周期內提供價值。
- 創建和管理容器鏡像的存儲庫代表了由硬件、處理器體系結構、操作系統和支持軟件依賴性的變化引入的復雜性的解決方案。
- 容器鏡像文件的“分層”屬性使供應商和最終用戶能夠有效地創建和迭代地增強存儲庫。這認識到容器鏡像的一些（“低層”）方面將在許多應用中長時間使用，而其他方面（“高層”）或特定應用可能經常發展或改變。
- 開發人員可以創建容器開發和部署環境，以便在將應用程序部署到生產環境之前實施特定的工作和測試流程。
容器編排（Container orchestration）同樣重要，原因有很多。這些包括：
- Orchestration提供了大大簡化系統擴展和管理的功能。
- Orchestration提供聲明性分布式系統配置。此配置描述了分布式系統的所需狀態。協調器用于實現和維護這種期望的狀態。協調器的操作使分布式系統能夠實現高應用程序可用性和諸如“自我修復”的屬性，因為協調器在分布式系統的一部分受到干擾或中斷時用于恢復期望的系統狀態。
- 聲明式系統配置比命令式配置工具更不容易出錯，必須執行以糾正操作，需要對可執行文件進行故障排除。
- 聲明式系統配置與版本控制系統相結合，使得最近系統的回滾變得微不足道。軟件包管理器、嵌入式系統技術和現有的DCS產品根本無法做到這一點。
- 圍繞容器構建協調器會將主要操作重點轉移到應用程序性能上，這是最終用戶關心的。因為每個容器都是一個應用程序，所以不需要從許多不同的應用程序中過濾掉信號或日志，以便將診斷集中在特定的應用程序上。
- 專注于應用而非機器可以在許多其他領域帶來連鎖效應。例如，它使得正確構建、部署和維護應用程序變得更加容易，并將應用程序運行時問題與機器問題分開。
容器和開放過程自動化
為什么所有這些都與開放過程自動化論壇有關？因為在工業自動化領域，尤其是過程自動化領域，應用程序經常每天更換。大型過程自動化安裝幾乎每天都需要對其控制應用程序配置進行微小的更改。控制配置是過程自動化操作技術（OT）領域的日常工作。添加了新的測量，測試了新的控制方案，調整了參數或警報限制，等等。
這種不斷變化的情況，是為什么過程工業最終用戶在其DCS中運行的控制應用（配置）中投入了如此多的知識產權。這些應用程序代表了工程和調整控制系統以服務于實際工廠及其運營目標的人工年數。不幸的是，今天的知識產權被控制語言和慣用語捕獲，這些語言和機構不具備機器可讀性并且總是高度專有。標準化的容器和編排工具提供了從這個死胡同的退出通道。
應用程序部署的容器
然而，今天的DCS確實使最終用戶能夠輕松地進行頻繁的控制應用程序更改。至少，成功的開放式過程自動化系統需要在次要工程變更方面支持相同的性能水平（可能還要高得多）。將應用程序部署到目標系統（特別是OPAF分布式控制節點所設想的小型目標系統）將是一項非常重要的任務，并且它將是每天執行的任務，用于開放式自動化系統的整個安裝生命周期。
總而言之，這種成熟的，基于容器的軟件部署技術高度標準化，廣泛使用，可在開源中使用，可在各種平臺上運行，并且已經在從最大（谷歌）到最小的安裝中進行了現場驗證。
選擇不在未來的開放式自動化架構中采用容器技術，意味著符合OPAF的系統必須與將使用這些功能強大的軟件工具的未來產品競爭。自動化供應商應該意識到這些能力，他們必須了解未來的競爭格局，以及當前或敏捷的新競爭者可能帶給市場的創新。
