SCADA Software Platforms

SCADA Software Platforms: Engineering Guide

SCADA software platforms are the supervisory layer of industrial automation that collect real-time process data, present operator graphics, manage alarms and events, store historical records, and issue supervisory commands to PLCs, RTUs, drives, analyzers, and other field assets. In modern projects, SCADA is rarely “just software”; it is a full platform composed of runtime servers, historians, alarm engines, communication drivers, client workstations, redundancy services, cybersecurity controls, and often virtualization or container infrastructure. For electrical engineers, automation engineers, panel builders, and EPC teams, the key is to design SCADA as an engineered system with clear performance, compliance, and lifecycle requirements.

What a SCADA platform does

A SCADA platform sits above the control layer. PLCs and RTUs execute deterministic control logic locally, while SCADA supervises, visualizes, logs, and coordinates. Typical functions include:

• Data acquisition from PLCs, RTUs, meters, protection relays, and analyzers via OPC UA, Modbus TCP, IEC 60870-5-104, DNP3, PROFINET gateways, or vendor-native drivers.
• HMI graphics and operator control.
• Alarm management with priorities, shelving, acknowledgments, and event journaling.
• Historian or time-series storage for trends, KPIs, and reports.
• Recipe, batch, or sequence orchestration in some platforms.
• Remote access, web clients, and integration with MES, ERP, and cloud analytics.

In practice, SCADA is the “single pane of glass” for operations, but the PLC/RTU remains the authority for safety and fast control loops. This separation is important for compliance with the EU Machinery Directive 2006/42/EC and for functional safety design under IEC 61508 / IEC 62061 / ISO 13849 where applicable.

How SCADA works

At a high level, SCADA uses a polling or subscription model. The server polls field devices or subscribes to published data, maps tags into a namespace, timestamps values, and distributes them to clients and historians. Alarm engines compare tag values against thresholds and state rules. Communication is typically client-server, though modern systems may use publish/subscribe and edge gateways.

A simple sizing relationship for network bandwidth is:

$$B \approx \frac{N \times S \times f \times 8}{1000}$$

where $B$ is bandwidth in kbit/s, $N$ is number of tags, $S$ is average payload bytes per tag update, and $f$ is update frequency in Hz.

Worked example: 5,000 tags, average 12-byte payload, 1 Hz update rate:

$$B \approx \frac{5000 \times 12 \times 1 \times 8}{1000} = 480\ \text{kbit/s}$$

That looks small, but protocol overhead, retries, encryption, alarm bursts, and historian writes can multiply real traffic by 5 to 10 times. A practical engineering factor is to size the network and server CPU at 30% to 40% of peak utilization, not 80% to 90%.

Main vendors and product families engineers should know

Vendor	Product families	Typical strengths
Siemens	WinCC, WinCC Unified, WinCC OA	Strong in industrial integration, large systems, and Siemens ecosystem; WinCC OA is common in utilities and infrastructure.
AVEVA	AVEVA System Platform, AVEVA Plant SCADA, AVEVA Edge, AVEVA Historian	Enterprise SCADA, historian, and multi-site architectures; broad integration and reporting.
Rockwell Automation	FactoryTalk View SE, FactoryTalk Optix, FactoryTalk Historian	Strong for Allen-Bradley-centric plants and modern HMI/edge architectures.
Ignition (Inductive Automation)	Ignition Platform, Perspective, Vision, Historian, MQTT modules	Highly flexible, web-native, strong OPC UA and MQTT ecosystem, popular for custom engineering.
Schneider Electric	EcoStruxure Geo SCADA Expert, AVEVA-based offerings	Utilities, water, and remote telemetry; strong alarm and telemetry features.
Emerson	Movicon.NExT, Ovation HMI/SCADA	Process and infrastructure applications; good for distributed architectures.
GE Vernova	iFIX, CIMPLICITY	Established installed base, especially in industrial and utility sectors.
COPA-DATA	zenon	Strong in packaging, energy, and multi-protocol systems with good engineering tools.

Selection criteria and concrete sizing rules

Selection should be driven by architecture, not brand preference. Key criteria include:

• Protocol support: OPC UA, Modbus TCP, IEC 60870-5-104, DNP3, BACnet/IP, MQTT Sparkplug B.
• Number of tags and update rates.
• Alarm count and event throughput.
• Historian retention and compression requirements.
• Redundancy needs for servers, networks, and storage.
• Web/mobile client requirements.
• Cybersecurity features: RBAC, audit trail, certificate management, patching model.
• Vendor support, local integrator capability, and spare parts availability.

For server sizing, a practical rule is:

• Small system: up to 5,000 tags, single server, 4 to 8 vCPU, 16 to 32 GB RAM.
• Medium system: 5,000 to 50,000 tags, 8 to 16 vCPU, 32 to 64 GB RAM, separate historian recommended.
• Large system: 50,000+ tags, distributed servers, historian cluster, redundancy, and virtualization.

Worked numeric example for historian storage: assume 10,000 tags, average 1 sample every 5 seconds, 16 bytes of effective stored data per sample after compression, 30 days retention.

Samples per day:

$$\frac{10000 \times 86400}{5} = 172{,}800{,}000$$

Raw storage per day:

$$172{,}800{,}000 \times 16 \approx 2.76 \times 10^9\ \text{bytes} \approx 2.76\ \text{GB/day}$$

For 30 days, that is about 83 GB raw, but with indexes, metadata, backups, and growth margin, specify at least 250 GB usable historian storage. In engineering practice, add 2x to 3x margin if alarms, reports, or higher sampling rates are expected.

Where SCADA fits in automation, panel, SCADA, and contracting projects

In a typical project stack, field instruments feed PLCs/RTUs, PLCs connect to SCADA, and SCADA connects to MES/ERP/cloud or remote operations centers. Panel builders provide the industrial PCs, network switches, UPS, firewalls, terminals, and marshalling. Electrical contractors install power, grounding, network cabling, and fiber. The automation engineer defines tags, communications, alarms, and graphics. The SCADA architect defines server topology, redundancy, naming, and cybersecurity zones.

For EPC delivery, SCADA usually appears in the control system specification, FAT/SAT scope, network architecture, and cybersecurity deliverables. It should be frozen early enough to avoid late changes in tag naming, alarm philosophy, and network address plans.

Applicable standards and clauses

Relevant standards include IEC 60204-1 for electrical equipment of machines, IEC 61000-6-2 and IEC 61000-6-4 for EMC immunity and emissions in industrial environments, IEC 62443 for industrial cybersecurity, and EN 50170/fieldbus or protocol-specific standards where applicable. For operators and alarm management, ISA-18.2 and IEC 62682 align on alarm lifecycle and rationalization. For HMI design, ISA-101 is the main reference. For documentation and panels, IEC 61439 and IEC 60204-1 are often used together in European projects.

Specific clauses engineers should note include IEC 60204-1:2016 Clause 4 on general requirements, Clause 13 on conductor and cable requirements, and Clause 18 on verification. IEC 61000-6-2 and IEC 61000-6-4 define immunity and emissions expectations for industrial environments. IEC 62443-3-3 is the key system security requirements standard, especially SR 1 through SR 7. ISA-18.2 covers alarm philosophy, rationalization, and performance monitoring; IEC 62682 mirrors its lifecycle approach. For machine-related SCADA/HMI integration, ensure the control system does not undermine safety functions required by ISO 13849-1 or IEC 62061.

Installation considerations: wiring, EMC, segregation, thermal

SCADA servers and industrial PCs should be installed in clean, temperature-controlled cabinets or control rooms. Keep power and data segregation strict: separate AC power, 24 VDC, Ethernet, and safety circuits, with physical separation or segregated ducting. Use shielded Ethernet where required by the EMC environment, bond shields per the system grounding strategy, and avoid pigtails that degrade high-frequency performance.

Follow good panel practice: route communication cables away from VFD output cables, contactor coils, and transformer primaries. For EMC, use 360-degree shield termination where the system design requires it, and maintain equipotential bonding. Thermal design should consider server dissipation, UPS losses, and switch heat. A simple rule is to derate enclosure cooling if internal ambient exceeds 35°C. For example, if the SCADA PC dissipates 120 W and the switch/UPS another 80 W, design for at least 200 W continuous heat load plus 20% margin, so specify cooling for 240 W minimum.

Cybersecurity installation matters too: place SCADA servers in a dedicated zone, use firewalls between levels, disable unused services, and enforce patch and backup procedures. For EU projects, document the security architecture to support NIS2-aligned risk management, access control, logging, and incident response.

Copy-ready project specification table

Item	Specification
Platform	SCADA software platform with server, client, historian, alarm, and reporting functions
Protocols	OPC UA, Modbus TCP, IEC 60870-5-104, DNP3, MQTT Sparkplug B as required
Tag capacity	Minimum [insert value] tags with 30% spare capacity
Update rate	Critical tags at 1 s or faster; noncritical tags at 5 to 10 s
Alarms	Priority, shelving, acknowledgment, audit trail, and alarm KPI reporting per ISA-18.2 / IEC 62682
Historian	Minimum [insert value] days retention with backup and restore tested
Redundancy	Server, network, and storage redundancy as required by availability class
Cybersecurity	Role-based access control, audit logs, certificate management, secure remote access, patch procedure
Compliance	IEC 60204-1, IEC 61000-6-2, IEC 61000-6-4, IEC 62443, ISA-18.2, IEC 62682, ISA-101
Installation	Dedicated cabinet/room, segregated cabling, EMC bonding, thermal margin, UPS-backed power

For most projects, the best SCADA platform is the one that matches the protocol mix, lifecycle support, cybersecurity posture, and engineering skill set of the delivery team. A technically elegant platform that cannot be maintained, secured, or supported locally is a poor engineering choice.