The server layer of a DCS consists of application, connectivity (OPC), history, reporting and engineering services. Each used to run on its own physical machine. Virtualization consolidates them onto a few powerful hosts. Done well it brings less hardware, faster recovery and an easier test environment. Done badly, the whole plant can depend on a single storage unit or a single host.
Virtualization is not a server-reduction exercise but a redundancy and support design. Stay inside the platform and configuration the vendor supports, and design hosts, storage and network in pairs.
Why virtualize?
- Less hardware: power, cooling, cabinet space and the variety of spare parts all shrink.
- Fast recovery: a virtual machine image can be brought up on a new host in minutes, far faster than rebuilding a physical server.
- Test and training environment: a copy of the production system can be used safely to try patches and changes.
- Lifecycle: applications that need an older operating system can be kept alive on modern hardware.
Vendor support comes first
DCS vendors publish which virtualization platform, version and configuration is supported. Outside that scope you may not get vendor help when something goes wrong. So the first step is the vendor’s current compatibility document; then resource allocation (CPU, memory, network), VM placement rules and licensing requirements (dongle/USB pass-through, licence server) are verified.
Four layers of redundant design
| Layer | Single-point-of-failure risk | Design approach |
|---|---|---|
| Host | When one host fails, all its virtual machines stop | At least two hosts; critical VM pairs (primary/standby) placed on different hosts |
| Storage | A single disk array decides the fate of the whole system | Redundant controllers, RAID, independent storage where possible; capacity and I/O performance measured |
| Network | A single switch or NIC | Dual NICs, dual switches, separate control and management networks |
| Power | A single UPS or feed | Dual feeds; periodic UPS and battery tests |
Application-level redundancy (for example a primary and standby application server) does not replace virtualization-level redundancy; the two complement each other. Putting both servers of a pair on the same host leaves redundancy on paper only.
Common mistakes
- Time synchronization: clock drift in virtual machines breaks event ordering and report consistency. Define the time source clearly and set host-guest time sync behaviour per the vendor’s recommendation.
- Overcommit: if CPU and memory commitments exceed real capacity, display updates and history logging lag at busy moments.
- Snapshot habits: snapshots held for a long time in production degrade performance and complicate restores.
- Backups limited to images: an image backup does not replace an application-level backup; a restore test is also needed.
- Management access: the virtualization management interface is a privileged gateway to every server; reach it only from the management network and with multi-factor authentication. See secure remote access.
Clients and operator stations
Operator stations can also be virtualized (VDI/thin clients), but operator experience requirements such as video walls, multi-monitor work, alarm sound and hotkeys must be verified separately. Many plants virtualize servers and keep operator stations physical.
Decision list
- Has the vendor-supported platform and version been verified?
- Are primary/standby pairs placed on different hosts?
- Are storage, network and power redundant; has a single-point-of-failure list been produced?
- Are the time synchronization, backup and restore procedures written down and tested?
- Is there a migration plan and a rollback plan?
In DCS system installation and system upgrade projects, ASP Otomasyon designs the server architecture around vendor recommendations and the plant’s redundancy goals. For the lifecycle and spares side, see DCS spare-parts planning.
Frequently asked questions
Can every DCS be virtualized?
No; support depends on the platform and version. The vendor’s published compatibility document and project-level approval are decisive.
Does virtualization reduce performance?
When sized correctly the difference is not noticeable in practice. Problems appear with overcommit or slow storage, so resource allocation and I/O performance should be measured as part of the design.
Are controllers virtualized too?
This article covers the server layer. Virtualizing real-time controllers is a separate topic, evaluated per product family.
