A Supervisory Control and Data Acquisition (SCADA) system connects operators with industrial processes by collecting field data, displaying equipment status, managing alarms, storing historical information, and allowing permitted supervisory control.
SCADA is widely used in manufacturing, utilities, water and wastewater systems, energy infrastructure, pipelines, transportation, process plants, and large distributed industrial operations.
A successful SCADA systems installation requires much more than installing visualization software on a server. Engineers must define the system architecture, identify field devices, design industrial networks, establish tag structures, configure alarms, plan historical data storage, secure the system, test communications, and document the complete installation.
Poor design at the beginning can create slow screens, unreliable communications, alarm floods, weak cybersecurity, difficult expansion, and high maintenance costs later.
This guide explains a practical step-by-step approach to designing and setting up a SCADA system correctly.
SCADA System Design Steps
1. Define the SCADA System Requirements
Before selecting hardware or software, document what the SCADA system must achieve.
Start with questions such as:
- Which machines or processes will be monitored?
- Which PLCs, RTUs, meters, drives, or other devices will connect?
- How many tags are required?
- How many operator stations are needed?
- Will historical data be stored?
- Which alarms are required?
- Is redundancy necessary?
- Is remote access required?
- Will the SCADA connect with MES, ERP, cloud, or analytics platforms?
- What cybersecurity requirements apply?
- How much future expansion is expected?
The recently published ANSI/ISA-112.00.01-2025 provides a vendor-neutral framework for the SCADA lifecycle and standardized workflows for designing, building, operating, maintaining, expanding, and auditing SCADA systems.
A clear User Requirements Specification can prevent expensive changes after implementation has already started.
2. Create the SCADA Architecture
The next step is to define the overall architecture.
A simple system may include:
- PLC
- SCADA Server
- Operator HMI
A larger plant may use:
- Field Devices
- PLC/RTU
- Industrial Network
- SCADA Servers
- Historian
- Operator Clients
- Business Systems
Typical SCADA architecture components include:
- PLCs and RTUs
- Communication gateways
- SCADA servers
- Historian servers
- Operator workstations
- Engineering workstations
- Industrial Ethernet switches
- Firewalls
- Backup servers
- Remote access infrastructure
Architecture should be based on application size, availability requirements, geographic distribution, network performance, cybersecurity, and expected expansion.
Do not add unnecessary servers simply because a large architecture looks advanced. Every additional component creates more configuration and maintenance.
3. Prepare a Complete Device and Tag List
A SCADA system needs a clear definition of the data it will collect.
Prepare a device list containing:
- PLC name
- PLC IP address
- Communication protocol
- Machine or area
- Device owner
- Network location
Then prepare the tag list.
Typical SCADA tags include:
- Motor running
- Motor fault
- Valve open/closed
- Temperature
- Pressure
- Flow
- Tank level
- Production quantity
- Energy consumption
- Alarm states
- Equipment mode
A structured naming convention is extremely useful.
For example:
Line01_Conveyor02_RunStatus
is easier to understand than:
MTR_27
A consistent tag structure helps with screen development, historian configuration, alarm management, integration, and troubleshooting.
4. Select the Correct Communication Method
SCADA systems may communicate with PLCs and field devices using different industrial protocols.
Common options include:
- OPC UA
- Modbus TCP
- Modbus RTU
- EtherNet/IP
- Vendor-specific Ethernet drivers
- Serial communication
- Telemetry protocols
OPC UA is widely used because it provides platform-independent and secure information exchange across industrial systems.
The OPC Foundation defines OPC UA as an architecture supporting secure communication, authentication, encryption, auditing, structured information models, read/write operations, subscriptions, and events.
When selecting a communication method, check:
- PLC compatibility
- Security
- Required update speed
- Data volume
- Reliability
- Vendor support
- Future interoperability
Where practical, avoid unnecessary protocol conversions because each additional gateway adds complexity.
5. Design the Industrial Network Carefully
Network design is one of the most important parts of SCADA implementation.
Poor network architecture can cause:
- Communication delays
- Device disconnects
- Lost data
- Slow screen updates
- Difficult troubleshooting
- Cybersecurity exposure
Document the network topology before implementation.
Important elements may include:
- IP address plan
- VLAN structure
- Industrial switches
- Fiber links
- Firewalls
- Routing
- Remote sites
- Redundant paths
Operational technology networks should be designed differently from ordinary office networks because industrial systems have unique reliability, availability, and safety requirements.
NIST SP 800-82 Rev. 3 provides guidance for securing operational technology while considering these requirements.
6. Segment the SCADA Network
Avoid connecting every industrial and enterprise device to one flat network.
Network segmentation can help limit unnecessary communication and reduce the impact of faults or cyber incidents.
A typical architecture may separate:
- Control devices
- SCADA servers
- Engineering stations
- Plant operations
- Enterprise IT
- Remote access
Firewalls or other controlled network boundaries may be used between appropriate zones.
ISA/IEC 62443 provides a risk-based cybersecurity framework for industrial automation and control systems and includes concepts such as zones and conduits for system design.
The exact architecture should be based on a formal cybersecurity risk assessment.
7. Configure PLC and RTU Communications
After the network is ready, configure SCADA communication with controllers.
For each PLC or RTU:
- Confirm network connectivity.
- Verify device address.
- Configure the correct driver or OPC UA connection.
- Test read access.
- Test permitted write access.
- Verify communication-loss behavior.
- Record communication parameters.
Do not immediately import thousands of tags before confirming basic connectivity.
Start with a small test group such as:
- One digital status
- One analog value
- One command
- One alarm
Once communication is stable, expand the configuration.
8. Build a Logical Tag Database
Tag organization has a major impact on long-term SCADA maintainability.
Group tags by:
- Plant
- Production line
- Machine
- Equipment
- Function
For example:
Plant01.Line02.Pump03.Run
Plant01.Line02.Pump03.Fault
Plant01.Line02.Pump03.Speed
This hierarchical approach makes large systems easier to browse and maintain.
Where the SCADA platform supports reusable equipment templates, use them for repeated assets such as:
- Motors
- Pumps
- Valves
- Tanks
- Conveyors
Templates reduce duplicated engineering and help maintain consistent behavior.
9. Design Operator Screens for Fast Understanding
A SCADA screen is an operational tool, not a marketing graphic.
The objective is to help operators understand plant conditions quickly.
A practical screen hierarchy may include:
- Plant overview
- Area overview
- Machine or process detail
- Equipment faceplate
- Alarm and trend screens
Use consistent:
- Symbols
- Navigation
- Equipment names
- Alarm indication
- Units
- Status conventions
Avoid excessive animations, bright colors, and decorative graphics that do not improve operational understanding.
Important abnormal conditions should be easy to identify.
10. Configure Alarms Carefully
Alarm design is a critical part of SCADA systems installation.
Every digital change does not need to become an alarm.
Useful alarms should represent conditions requiring operator attention.
Examples include:
- High temperature
- Low pressure
- Motor overload
- Communication failure
- Tank high-high level
- Pump failure
- Safety system fault
Each alarm should define:
- Alarm name
- Trigger condition
- Priority
- Operator response
- Acknowledgement behavior
- Delay where appropriate
Poor alarm design can create alarm floods where hundreds of messages appear during one equipment failure.
This makes it harder for operators to identify the root problem.
11. Configure Historical Data Correctly
Not every tag needs to be stored at the same frequency.
Historical data requirements should depend on how the information will be used.
Examples:
Fast-changing data
- Critical process variables
- High-speed production measurements
Moderate data
- Temperature
- Pressure
- Flow
- Production counts
Slow data
- Maintenance hours
- Daily production totals
- Energy summaries
Review:
- Sampling interval
- Deadband
- Data compression
- Retention period
- Database size
- Backup policy
Unnecessary high-frequency logging can rapidly increase storage requirements without providing useful information.
12. Design User Roles and Permissions
Not every SCADA user should have the same level of access.
Typical roles may include:
- Operator
- Supervisor
- Maintenance
- Engineer
- Administrator
An operator may need permission to start or stop equipment but should not necessarily be able to modify system configuration.
An engineer may require additional access for diagnostics.
Use role-based access wherever supported.
Avoid shared administrator accounts.
User activities such as configuration changes and important control actions should be logged where appropriate.
13. Include Cybersecurity During Design
Cybersecurity should be designed into the SCADA architecture from the beginning.
ISA/IEC 62443 defines requirements and lifecycle processes for improving the security of industrial automation and control systems.
Important SCADA security measures can include:
- Network segmentation
- Firewalls
- Role-based access
- Strong authentication
- Secure remote access
- Patch management
- Application allowlisting where appropriate
- Logging
- Backups
- Recovery procedures
- Controlled removable media
NIST also emphasizes that OT cybersecurity controls should consider operational performance, reliability, and safety requirements.
Avoid applying normal IT security practices blindly if they could interfere with critical control functions.
14. Plan Backup and Recovery
A SCADA system should be recoverable after server failure, software corruption, or a cybersecurity incident.
Back up:
- SCADA project
- Tag database
- Screen configuration
- Alarm database
- Historian configuration
- Communication settings
- User configuration
- Server settings
- License information
- Network configuration
Where possible, maintain both configuration backups and system-level recovery procedures.
Test backups periodically.
A backup is only valuable if the organization can successfully restore it.
15. Test the SCADA System Before Commissioning
Testing should begin before the system is connected to live production.
Important tests include:
- PLC communications
- Tag values
- Engineering units
- HMI graphics
- Alarm activation
- Alarm acknowledgement
- Historian data
- Trend displays
- User permissions
- Communication-loss handling
- Server restart
- Network interruption
- Backup restore
A Factory Acceptance Test can verify much of the application before site deployment.
Create a test checklist and record the result of every important function.
16. Perform Site Acceptance Testing
After installation at the plant, perform Site Acceptance Testing.
Verify actual field behavior.
For example:
- Field sensor changes
- PLC detects it
- SCADA displays the correct status
Also verify supervisory commands:
- Operator command
- SCADA
- PLC
- permitted equipment response
Check each control carefully because incorrect mapping can operate the wrong device.
Other site tests may include:
- Network failover
- Server failover
- Power recovery
- PLC communication loss
- Historian continuity
- Alarm timestamps
17. Document the Final SCADA System
After commissioning, prepare accurate final documentation.
Include:
- Architecture diagram
- Network diagram
- IP address list
- PLC/RTU list
- Tag database
- Alarm list
- User roles
- Historian configuration
- Server specifications
- Software versions
- License details
- Backup location
- Recovery procedure
- Change history
ISA-112 emphasizes SCADA as a lifecycle system covering design, implementation, operation, maintenance, expansion, and audit.
Good documentation is therefore essential long after initial startup.
Example SCADA Implementation Checklist
| Project Area | Key Check |
|---|---|
| Requirements | Operational scope documented |
| Architecture | Servers and clients defined |
| Devices | PLC/RTU list completed |
| Tags | Naming structure approved |
| Network | IP and topology documented |
| Protocols | Communication tested |
| HMI | Screens standardized |
| Alarms | Priorities and messages verified |
| Historian | Storage strategy defined |
| Security | Roles and segmentation configured |
| Backup | Recovery procedure tested |
| FAT | System functions verified |
| SAT | Field operation verified |
| Documentation | Final configuration recorded |
Common SCADA Installation Mistakes
Avoid these common mistakes:
- Starting graphics before defining the architecture
- Using inconsistent tag names
- Creating a flat industrial network
- Logging every tag at high frequency
- Turning every status into an alarm
- Sharing administrator accounts
- Adding cybersecurity only after commissioning
- Ignoring backup restoration testing
- Importing thousands of tags before communication testing
- Failing to document the final installed system
A successful SCADA implementation should be designed for operation and maintenance, not only for project handover.
Conclusion
A correct SCADA systems installation begins with requirements and architecture, not screen design.
Engineers should define devices, tags, communications, network topology, alarms, historian requirements, user permissions, cybersecurity, backups, and testing before the system enters production.
Standards and guidance such as ANSI/ISA-112, ISA/IEC 62443, NIST SP 800-82, and OPC UA specifications provide useful frameworks for building reliable and maintainable industrial supervisory systems.
The best SCADA system is not necessarily the one with the largest number of features. It is the system that gives operators accurate information, communicates reliably with field equipment, protects critical assets, stores the right data, and can be maintained and expanded throughout its lifecycle.