★ Hochschule Harz  Rene Simon

★ PLCopen中國 譯

摘要：本文追溯了可編程序控制器（Programmable Logic Controller， PLC）從最初以硬件為中心的設計，到軟件驅動的實現方式，再到當今虛擬PLC（Virtual PLC，vPLC）的演進歷程；分析了促成這一轉變的關鍵技術進步，評估了vPLC技術的現狀，并探討了工業自動化領域持續存在的挑戰—特別是與實時通信相關的難題。研究還重點介紹了正在涌現的新興產品、試點部署項目以及影響vPLC未來發展的標準化倡議。

Abstract: This paper traces the evolution of programmable logic controllers (PLCs) from their originally hardware-centric designs, through software-driven implementations, to today's virtual PLCs (vPLCs). It examines the key technological advances that have enabled this transition, evaluates the current state of vPLC technology, and discusses the challenges that persist in industrial automation— particularly those related to real-time communication. The study also highlights emerging products, pilot deployment projects, and ongoing standardization initiatives that are shaping the future development of virtual PLCs.

1   PLC的發展歷程

自20世紀60年代誕生以來，   PLC已從最初的繼電器替代裝置逐步發展為具備網絡化、智能化特征的工業控制核心設備 [1]。根據IEC 61131-1（2003） [2]標準定義， PLC的核心功能是信號處理，具體表現為對機械設備及工業流程的控制與指令輸出。  PLC系統通常需配套以下外圍設備：傳感器與執行機構的輸入/輸出模塊（Inputs/Outputs， I/Os）、人機交互界面（Human-Machine Interface， HMI）、編程及調試工具（Programming and Debugging Tool， PADT）。其功能實現可基于三類平臺：專用軟硬件系統、具備工業特性的個人計算機，或通用計算設備。

1.1   硬PLC

硬PLC或者經典PLC（通常也被直接稱為PLC）代表了可編程序控制器發展的基礎階段。這類PLC多為緊湊型或模塊化設備，具有專用硬件架構及傳感器/執行器接口（輸入/輸出模塊）。其信號/數據處理的運行時環境（Runtime， RT）與硬件深度集成，內部通信系統通常采用專有協議。傳統PLC須提供必要的實時性能，主要采用循環掃描工作模式，循環周期可達1毫秒。

通常PLC的PADT配有仿真器，這些仿真器無需I/O連接，可用于測試和演示目的，必要時還可與機器/流程的數字孿生連接。這些仿真器既無意圖也無能力運行真實的物理系統。經典/硬PLC的系統架構如圖1所示。

圖1 經典/硬PLC的系統架構

1.2   支持遠程I/O的PLC

PLC技術發展的下一階段是遠程I/O（Remote I/O， RIO）模塊的研發。該技術通過將傳感器/執行器接口分離， 實現了三大核心優勢：滿足流程工業對長距離信號傳輸的需求、提升制造業在有限空間內的多信號處理能力，以及顯著降低系統資源消耗。

圖2 PLC與遠程I/O系統架構

該技術發展的關鍵前提是外部實時通信系統的實現，例如現場總線或工業以太網系統。這些通信系統必須實現標準化以支持多供應商設備。這也意味著相關供應商需要對整個系統共同承擔責任，也需要額外提供設備間工程耦合的方式（例如通過設備描述文件等）。

在工業自動化系統中，除了通過遠程I / O模 塊（Remote I/O）連接的設備外，也存在直接連接的現場設備（即不經遠程I/O裝置的傳感器或執行器）。這類設備通常被歸類為分散式外圍設備（Dezentrale Peripherie），直接與控制單元通信。類似的概念還包括RTU（遠程終端單元）以及IEC 61850標準[3] ，該標準定義了電力自動化領域中的通信與互操作性框架。 PLC與遠程I/O系統架構如圖2所示。

1.3   軟PLC

軟PLC（Soft PLC）標志著可編程序控制器技術的又一重大演進。其核心特征在于將運行時環境（Runtime）與硬件解耦：從技術層面看，該運行時可在單一供應商的不同硬件產線上部署；從商業維度而言，更可實現多供應商之間的資源共享。軟PLC的系統架構如圖3所示。

圖3 軟PLC的系統架構

為實現跨平臺運行的靈活性，軟PLC系統需滿足三大核心技術要求：

• 必須支持x86、ARM、PowerPC等多架構處理器平臺；

• 需兼容從Linux、Windows到VxWorks、QNX乃至無操作系統的多樣化運行環境；

• 要具備性能、功能、內存及接口等方面的彈性擴展能力。

軟PLC通過可共享的PADT支持，實現在不同硬件上的運行。PADT可根據實際需求進行零修改、輕度適配或深度定制等不同級別的調整。值得強調的是，該技術的實現根基在于嚴格遵循IEC 61131-3[4] 國際標準所定義的通用編程語言規范。

遠程I/O與軟PLC技術自20世紀90年代起便呈并行發展態勢。隨著這兩項技術的成熟，越來越多的自動化設備開始集成PLC功能模塊，包括工業PC、操作面板、遠程I/O模塊、驅動/機器人/CNC控制器等各類工業控制設備。集成軟PLC運行時的操作面板如圖4所示。

圖4 集成軟PLC運行時的操作面板

1.4   虛擬PLC

PLC技術的下一個重大突破在于vPLC的發展。該架構實現了運行時環境的本地化分離，同時將物理輸入/輸出模塊保留在工廠現場層。這一轉型將分階段推進：從現場服務器起步，逐步過渡到私有云服務器，最終延伸至公有云平臺。

技術實現上可采用實時功能分層方案—將運動控制等關鍵硬實時功能保留在現場層，而軟實時功能則可云化部署。此變革正催生“PLC即服務”（PLCaaS）與“控制即服務”（CaaS）等創新商業模式。基于服務器架構的虛擬PLC（vPLC）系統如圖5所示。

圖5 基于服務器架構的虛擬PLC（vPLC）系統

隨著工業數字化轉型的深入，vPLC技術正成為工業自動化領域的重要發展方向。作為硬PLC的虛擬化延伸，vPLC選用了當前相對成熟的虛擬化技術方案，既保證了工業控制系統的可靠性需求，又能充分利用現代計算架構的靈活性優勢。vPLC的層級架構如圖6所示。

圖6 vPLC的層級架構

vPLC通過容器或虛擬機監控程序（Hypervisor）技術實現。容器提供了“一種利用虛擬化操作系統內核運行軟件的隔離執行環境” [5]。而虛擬機監控程序則是“能夠創建并運行一個或多個虛擬機的計算機軟件”[5]。該技術分為兩類：裸機型虛擬機監控程序直接運行在硬件上以獲得更高效率；托管型則依托操作系統運行以降低硬件依賴性。這些技術方案均可達到實時性要求[6~8]。

vPLC的引入將帶來多重優勢，包括：

• 顯著提升應用開發的靈活性；

• 通過減少硬件種類與數量降低成本；

• 降低維護、更新、安全及能耗支出；

• 增強機器/工廠全生命周期的可擴展性；

• 實現集中式且支持遠程操作的數字化管理。

vPLC將推動工業自動化（基于云）的全面虛擬化趨勢，其中也包括PADT的虛擬化。

對于所有類型的可編程序控制器（硬PLC、軟PLC和vPLC）而言，循環周期時間是最關鍵的指標。該周期時間包括服務器運行時中的程序執行時間，以及通信網絡中的雙向延遲（和抖動）。由于vPLC通常跨越物理I/O、服務器甚至多個云環境，其通信系統必須滿足更廣泛的覆蓋范圍需求，能夠在物理輸入輸出與服務器之間、單個或多個云服務器之間，以及不同（甚至公共）網絡中高效運行，而無法依賴任何時間緩沖機制。與此同時，通信系統還需具備高服務質量（QoS），包括低延遲、低抖動、低丟包率和足夠的數據吞吐量，以滿足實時控制要求。工程層面上，網絡設計、部署與維護必須符合現有工業通信系統的標準與規范，從而確保系統的確定性、可靠性與實時性，其中服務質量（QoS）， 尤其是可用性最為重要。表1概述了當前的技術發展水平。

表1 PLC 循環周期時間

2   虛擬PLC的產業應用

vPLC經過一系列技術迭代， 首批商用產品不僅已成功面世，更在小規模生產場景中實現了初步應用。 2019年， 大眾汽車集團奧迪事業部率先啟動了包含vPLC技術的云端生產系統建設項目[9]。該項目與西門子vPLC產品研發同步推進，旨在構建完整的云端生產體系（而不僅限于控制編程），所有組件與流程均通過實驗室環境預先驗證。最終，德國Neckarsulm工廠的某車橋裝配線部署了兩臺SIMATIC S7-1500V，該系統自2024年1月起已投入實際生產運行。

與此同時，圍繞vPLC的潛在應用場景也逐漸清晰。例如，在中型化工廠中，可采用模塊化結構，各單元（如接收、預處理、核心反應、分離凈化、物流與廢物管理等）由集中部署在現場服務器機房的一臺或多臺 vPLC 進行控制；對于系列化設備制造商，如每年交付百臺以上標準化設備的企業，所有控制器可在生產方自有云端運行，并在交付后實現遠程維護，無需派遣人員前往客戶現場；對于PLC服務提供商，則可通過vPLC 運營城市級基礎設施，例如統一管理一座城鎮的全部交通信號系統。

奧迪事業部當前還推進著另一重點項目[10]。該項目涵蓋了可行性研究、初步實踐演示、原型機制作，以及利用CODESYS Virtual Control SL的功能性和安全型控制器建立試生產單元。

表2 商用虛擬PLC產品及其廠商[1]

3   虛擬PLC的標準化進程

vPLC的廣泛應用離不開兩大關鍵要素： 一是適用通信協議的普及性與全球標準化程度， 二是QoS必須達到當前標準工業通信系統的同等水平。這種可靠的通信能力需要覆蓋三大場景：遠程I/O設備的數據交互（輸入/輸出）、云服務器內部通信以及跨云服務器通信—后者往往需要穿越不同的（公共）網絡。目前相關的標準化工作正在推進中，其中IEC/IEEE 60802時間敏感網絡（TSN）工業自動化規范[11] 已進入IEC委員會草案投票（IEC CDV）和IEEE標準協會投票（IEEE SA ballot）階段。

PLCopen中國在深圳組織了一次研討會，啟動了一項新的標準化工作。會上，有關專家討論了中國國家標準草案《可編程序控制器 虛擬化參考架構》和《可編程序控制器 可信計算技術要求》。這項標準化工作預計將為下一版IEC 61131-3標準的制定做出貢獻。

4   虛擬PLC未來面臨的挑戰

當前vPLC技術的發展仍面臨多重挑戰，這些挑戰存在于技術、管理和產業融合等多個維度：

首先，責任認定機制缺失構成最緊迫的挑戰。核心問題在于責任體系的高度分散化—網絡設備供應商、通信服務商、容器/虛擬化平臺開發商、云服務提供商等多方主體權責劃分不清。當vPLC出現功能失效時，由誰承擔停產責任？由誰補償經濟損失？這些問題亟待解決。

其次，產業適配性引發深層憂慮。工業自動化以外的企業能否滿足該細分市場的嚴苛要求？這些企業普遍具有更快的技術迭代節奏、更靈活的產品開發周期以及差異化的組織架構。盡管這不是新問題，但仍是關鍵制約因素。

第三，通信標準體系面臨轉型升級壓力。工業通信系統正面臨新要求：無論是PRO FINET、 EtherCAT、Modbus TCP等傳統協議，還是WiTSnet等新興技術， 都必須實現更遠距離覆蓋； 而VxLan、 MQTT等非工業技術則需達到與當前工業自動化解決方案同等級的QoS標準。

最后，人才與安全構成基礎性挑戰。理想的OT/IT融合要求工廠基層提升IT知識水平，與此同時，網絡安全挑戰預計將呈指數級增長。

5   結語

展望未來，vPLC必將深度融合先進通信、精準運動控制、功能安全、系統冗余與多維可視化能力，推動自動化系統的進一步發展。工業通信系統將以持續演進而非重新開發為方向，引入虛擬化的物理層與傳輸層，但工程方式（如設備描述、通信配置與過程建模）不會發生根本性變化。對于已經在控制器中以代理或功能塊形式實現虛擬化的功能，無需再作為獨立設備重復虛擬化；反之，若要對設備進行集中式虛擬化，則應將整個應用程序一并整合其中，以保持系統的一致性與完整性。與此同時，容器與虛擬機監控器（Hypervisor）仍需統一化標準，控制功能將逐步實現集中化，并通過PLCopen庫支持運動控制、安全與過程控制等模塊化應用。硬件PLC、軟件PLC與vPLC的發展既存在遞進關系，又在技術體系上并行演進，三者將長期共存并通過IEC 61131-3 / PLCopen標準實現兼容編程與統一的工業通信系統。未來具體的PLC類型選擇將取決于行業特性、應用場景、終端用戶需求、項目技術規范及資源條件等多重因素，從而形成靈活協同、標準統一、架構開放的工業控制生態。

作者簡介：

Rene Simon （1966-），男，德國馬格德堡人，教授， 博士，現任PLCopen主席， 就職于Hochschule Harz，研究方向為可編程序控制器。

參考文獻：

[1] SIMON R. Virtuelle Steuerungen: Evolution und Stand der Technik[J]. atp magazin, 2026, 68 (6/7) : 46 - 51.

[2] IEC 61131-1:2003 Programmable controllers — Part 1: General information[S]. 2003.

[3] IEC 61850:2021 Communication networks and systems for power utility automation[S]. 2021.

[4] IEC 61131-3:2025 Programmable controllers — Part 3: Programming languages[S]. 2025.

[5] ISO. ISO Online Browsing Platform (OBP)[EB/OL]. https://www.iso.org/obp/ui.

[6]  GIVEHCHI O, IMTIAZ J, TRSEK H, et al. Control-as-a-service from the cloud: a case study for using virtualized PLCs[EB/OL]. https://publicarest.fraunhofer.de/server/api/core/bitstreams/0db95abd-b90a-4a11-87fc-449d592e7d36/content.

[7]  LANGMANN R, STILLER M. The PLC as a smart service in Industry 4.0 production systems[J]. Applied Sciences, 2019, 9(18): 3815. DOI:10.3390/app9183815.

[8]  PEREZ D J, WALTL J, PRENZEL L, et al. How real (time) are virtual PLCs?[EB/OL]. (2022) . https://tum-esi.github.io/publications- list/PDF/2022-ETFA-How_Real_Time_Are_Virtual_PLCs.pdf.

[9] SIEMENS AG. Audi is virtualizing the shop floor with the virtual PLC from Siemens[EB/OL]. https://www.siemens.com/global/en/ company/stories/industry/factory-automation/virtual-plcaudi.html.

[10] CODESYS Group. Audi uses virtual CODESYS[EB/OL]. https://www.codesys.com/newsevents/news/article/audi-uses-virtual- codesys-control-1.html.

[11] IEC/IEEE 60802 TSN Profile for Industrial Automation[EB/OL]. https://1.ieee802.org/tsn/iec-ieee-60802/.

摘自《自動化博覽》2026年7月刊