SCADA Tutorial for Beginners: Build a Test System

SCADA is the supervisory layer that acquires process data, presents it to operators, records history, manages alarms, and sends authorized commands to control systems. The safest way to learn it is to build an isolated lab, then prove normal operation, bad data, communication loss, rejected writes, restart, and recovery.

This tutorial builds a small tank-monitoring system. It is intentionally vendor-neutral: product menus differ, but requirements, tag ownership, alarm design, access control, and acceptance tests transfer between platforms.

Safety boundary: Do not connect this lab to production equipment or expose it to the public internet. Simulation cannot validate electrical wiring, process hazards, machinery safety, functional safety, or site operating procedures.

What you will build

The lab contains:

• a simulated tank level;
• an inlet valve and discharge pump;
• automatic and manual modes;
• permissives and interlocks in the PLC layer;
• a SCADA overview screen;
• high, low, and instrument-fault alarms;
• a historical level trend;
• read-only and operator user roles;
• communication-quality and restart handling;
• a test record with pass/fail evidence.

Practise the PLC sequence first with PLC Simulation Software. Then expose equivalent tags from an approved OPC UA, Modbus TCP, or vendor test server to your SCADA package. The browser simulator is the logic-practice stage; it is not presented here as a SCADA server.

SCADA, PLC, HMI, historian, and DCS

Component	Primary job	Typical ownership
PLC or controller	Deterministic machine/process control	Logic, permissives, interlocks, trips
HMI	Local operator interface	Machine or cell visualization and commands
SCADA	Supervisory acquisition and control	Multiple assets, alarms, history, clients
Historian	Time-series storage and retrieval	Long-term process records and analysis
DCS	Integrated process-control platform	Controller, engineering, operations, and process functions
MES/business system	Production workflows and enterprise context	Orders, genealogy, performance, reporting

The boundaries vary by product. A SCADA package may include a historian and scripting. A DCS may expose SCADA-like clients. Define responsibilities from the actual system architecture, not the product label.

Read the SCADA architecture guide for larger deployments and PLC vs DCS vs SCADA for selection context.

A basic SCADA data path

Field signals
    ↓
PLC / RTU control logic
    ↓
Industrial protocol or OPC server
    ↓
SCADA gateway / data server
    ├── operator clients
    ├── alarm service
    ├── historian / database
    └── approved reporting integration

Commands travel in the opposite direction, but the PLC retains responsibility for validating mode, bounds, permissives, interlocks, and safe behavior. A SCADA button should request an action; it should not bypass the control layer.

Choose a learning platform

The tutorial can be completed with any SCADA environment that supports:

• a test protocol connection;
• Boolean and numeric tags;
• quality and timestamps;
• screens and basic components;
• alarms;
• history or a trend;
• user roles;
• audit logging or event history.

Inductive University provides free official Ignition training. Ignition Maker Edition is a free licence for non-commercial personal educational use, with documented limits. Educational institutions and commercial users must follow the publisher’s applicable terms.

Do not choose a production platform from a tutorial alone. Verify redundancy, scale, drivers, licences, operating-system lifecycle, cybersecurity support, backup/restore, audit requirements, vendor support, and site standards.

Step 1: Write the control narrative

Use a short requirement before creating tags or graphics:

In automatic mode, the inlet valve opens when level falls below the configured low control point and closes when level reaches the high control point. The discharge pump may run only when level is above its dry-run permissive and no fault is active. Manual commands are requests that remain subject to PLC permissives. Invalid level quality or contradictory discrete instruments place automatic operation in a defined safe state. Power restoration does not cause an uncontrolled restart.

This is a learning example, not a process-safety design. Real thresholds and responses require process, control, safety, and operations review.

Step 2: Define tag ownership

Tag	Type	Owner	SCADA access	Purpose
Tank01_LevelPV	Float	PLC	Read	Process level
Tank01_LevelQualityOK	Boolean	PLC/comms	Read	Instrument and communication validity
Tank01_ModeAuto	Boolean	PLC	Read	Actual mode
Tank01_AutoRequest	Boolean	SCADA request	Write by operator	Request automatic mode
Tank01_InletValveCmd	Boolean	PLC	Read	Actual control command
Tank01_PumpCmd	Boolean	PLC	Read	Actual control command
Tank01_PumpRunFb	Boolean	Field/PLC	Read	Running feedback
Tank01_PumpStartRequest	Boolean	SCADA request	Write by operator	Manual start request
Tank01_HighAlarm	Boolean	PLC or alarm service	Read	High-level condition
Tank01_LowAlarm	Boolean	PLC or alarm service	Read	Low-level condition
Tank01_InstrumentFault	Boolean	PLC	Read	Invalid instrument condition
Tank01_CommHealthy	Boolean	SCADA/comms	Read	Connection state

Separate request, command, and feedback. If one tag named Pump is used for all three, the display cannot explain whether the operator requested a start, the PLC issued a command, or the motor actually ran.

Step 3: Program the PLC behavior

Implement the control logic before the screen:

1. Validate the level signal and communication state.
2. Determine current mode from approved ownership logic.
3. Apply automatic fill control with hysteresis or explicit state.
4. Apply pump dry-run permissive.
5. Latch relevant faults according to the requirement.
6. Reject reset while the initiating condition remains active.
7. Define power-up and communication-restoration states.
8. Expose diagnostic reason codes, not only one generic fault bit.

Minimal state model

State	Inlet valve	Pump	Exit condition
SAFE_STOPPED	Off	Off	Valid data and approved start/mode
FILLING	On	Off	High control point, stop, or fault
READY	Off	Off	Discharge request or refill condition
DISCHARGING	Off	On	Low permissive, stop, or fault
FAULTED	Off	Off	Fault cleared and reset accepted

Include an ELSE or default branch that returns an invalid state to a defined safe condition. State recovery should be observable in diagnostics.

Step 4: Configure the test connection

Use the protocol supported by both the PLC test environment and SCADA platform.

OPC UA

Follow the secure OPC UA tutorial: discover endpoints, verify application certificates, use an approved signed-and-encrypted endpoint, authenticate the user, and test read-only access before writes.

Modbus TCP

Record device address, register map, data type, byte/word order, scaling, read/write function, polling interval, timeout, and bad-quality behavior. Modbus TCP does not provide OPC UA’s application certificate and information-model features; place it within the approved OT security architecture.

Vendor-native driver

Match controller family, firmware, slot/path or route, project tag settings, driver version, and connection limits. Use the driver manual as the source of truth.

Connection acceptance

• correct device and project identity;
• expected tags resolve;
• correct types and scaling;
• source quality and timestamps handled;
• read-only account cannot write;
• disconnect creates bad quality;
• reconnect is controlled and logged.

Step 5: Create the SCADA tags

For each tag, configure:

• provider or connection;
• address/NodeId;
• data type;
• read/write mode;
• engineering units;
• scaling, if not owned by the PLC;
• quality behavior;
• history policy;
• alarm association;
• security role;
• description and owner.

Do not duplicate scaling in the PLC and SCADA without a documented reason. One source should own the engineering value.

Derived tags

Derived expressions are useful for display-only values such as:

PumpMismatch = PumpCmd AND NOT PumpRunFb
LevelDisplayValid = LevelQualityOK AND CommHealthy

Do not hide important logic in screen scripts. If behavior affects equipment control, implement and validate it in the appropriate control layer.

Step 6: Build an answer-first overview screen

An operator screen should answer four questions quickly:

1. What is the process doing?
2. Is it healthy?
3. What needs attention?
4. What action is allowed?

Suggested layout

• Header: area, screen title, current time source, logged-in user, communication state.
• Process area: tank, valve, pump, flow direction, measured level.
• Status panel: mode, state, permissive summary, active fault.
• Alarm strip: highest-priority active condition with navigation.
• Control panel: permitted requests with confirmation and reason when disabled.
• Trend link: current level and relevant command/feedback.

Use color sparingly for abnormal or selected state. Do not make normal operation depend entirely on red/green discrimination. Pair color with text, symbol, shape, or pattern, and verify contrast and focus order.

Read the HMI design best-practices guide for display hierarchy and alarm use.

Step 7: Configure alarms deliberately

Each alarm needs more than a threshold:

Field	Question
Condition	What exact state creates the alarm?
Priority	What consequence and response urgency justify it?
Delay	Must the condition persist before annunciation?
Hysteresis/deadband	What prevents chatter?
Message	Does it identify asset, condition, and useful response?
Acknowledgement	What does acknowledging mean?
Clear/reset	Does the alarm clear automatically or require reset?
Shelving	Who may shelve it, why, and for how long?
Audit	Are acknowledge, shelve, and setpoint changes recorded?
Response	What should the operator check or do?

Example messages:

• Weak: High Alarm
• Better: Tank 01 level high — verify inlet valve closed
• Better with state: Tank 01 level high; inlet command ON — stop fill and inspect valve path

Setpoints in a tutorial are lab variables, not operating recommendations. Document why each test value was chosen.

Alarm tests

• condition activates after the configured delay;
• alarm time and source state are correct;
• acknowledgement does not clear the process condition;
• return-to-normal behavior matches the requirement;
• chatter is controlled without masking real events;
• bad quality does not create misleading process alarms;
• user permissions for acknowledge, shelve, and setpoint changes work;
• alarm actions appear in the audit record.

Step 8: Add history and a trend

Historize only what supports operations, diagnostics, quality, compliance, or analysis. More points and faster logging are not automatically better.

For the lab, log:

• level process value and quality;
• inlet command;
• pump command and feedback;
• mode and state;
• alarm state;
• communication state.

Configure either periodic sampling, change-based storage, or both according to the platform and requirement. Record:

• sample/change policy;
• deadband;
• timestamp source;
• retention;
• compression;
• time zone;
• bad-quality storage;
• database backup.

Trend acceptance

Run a fill/discharge cycle and confirm that command transitions, process response, alarms, and communication quality align in time. A trend that silently joins points across a data gap can mislead; make missing or bad data visible.

Step 9: Configure users and audit

Create at least:

• Viewer: browse screens and trends; no control.
• Operator: approved requests and alarm acknowledgement.
• Engineer: configuration functions required for the lab.
• Administrator: restricted platform administration.

Test permissions, do not merely configure them. A hidden button is not access control; the server must reject unauthorized operations.

Audit:

• login success/failure;
• command request and result;
• setpoint changes;
• alarm acknowledgement and shelving;
• role/configuration changes;
• project deployment;
• connection/certificate changes;
• backup and restore operations where available.

Step 10: Run failure tests

ID	Failure	Expected behavior
S01	Stop protocol server	Tags show bad quality; communication alarm appears
S02	Restore server	Controlled reconnect; no unintended command replay
S03	Freeze level value	Stale-data diagnostic according to requirement
S04	Force contradictory level switches	Instrument fault; automatic control enters defined state
S05	Remove pump feedback after command	Mismatch alarm after approved delay
S06	Operator writes outside approved range	Rejected and audited
S07	Viewer attempts a command	Server denies it
S08	Restart SCADA gateway	Project and history recover as documented
S09	Restart PLC simulator	Safe startup state; no uncontrolled restart
S10	Fill historian storage in test	Alarm and retention behavior observed
S11	Change client/server clock in lab	Timestamp defect becomes visible
S12	Restore backup to clean test instance	Documented recovery succeeds

Capture a screenshot, event export, or log for each test. Record product versions, configuration revision, initial conditions, action, expected result, actual result, evidence file, and reviewer.

SCADA security for beginners

The NIST Guide to Operational Technology Security, SP 800-82 Rev. 3, covers OT topologies, threats, vulnerabilities, and controls while recognizing safety, reliability, and performance constraints. Use it as a starting point for architecture and risk review.

CISA’s Internet Exposure Reduction Guidance specifically includes SCADA and ICS assets. It advises organizations to identify exposed assets, remove unnecessary exposure, change defaults, patch supported systems, use monitored secure access, apply MFA where possible, monitor traffic, and reassess routinely.

Minimum lab-to-production questions

• Is any SCADA, PLC, gateway, database, or remote-access interface publicly reachable?
• Which zone owns each component?
• Which conduits and ports are required?
• Is remote access approved, monitored, time-limited, and MFA-protected?
• Are default accounts removed or secured?
• Are backups offline or otherwise protected and restore-tested?
• Are platform, operating system, database, and driver versions supported?
• Are security logs collected without disrupting operations?
• Is there a tested manual or degraded operating mode?

Never turn a tutorial’s “make it connect” firewall rule into a production rule.

Common beginner mistakes

Building the screen before the requirement

This creates attractive graphics with unclear ownership and no acceptance criteria. Start with the narrative, state model, and tag contract.

Writing directly to outputs

SCADA should normally write requests or setpoints. The PLC applies permissions, modes, bounds, permissives, interlocks, and trips.

Treating bad quality as zero

Zero may be a valid process value. Preserve and display quality separately.

Using one account for everyone

Shared accounts destroy attribution and usually grant excessive privilege. Use named users or managed service identities where supported.

Testing only normal operation

Communication, restart, stale data, wrong permissions, full storage, and failed devices reveal most integration weaknesses.

Exposing the gateway for convenience

Public exposure creates material risk. Use an approved remote-access architecture and follow current OT security guidance.

A competency-based learning path

Avoid rigid “become a SCADA engineer in 30 days” promises. Advance when you can demonstrate each gate.

1. Architecture: draw the data and command paths and explain ownership.
2. Tags: create typed tags with quality, units, and documented addressing.
3. Screens: build an overview that shows state, abnormal conditions, and permitted actions.
4. Alarms: define and test priority, delay, hysteresis, acknowledgement, and response.
5. History: trend process, state, and quality with visible gaps.
6. Security: implement roles, audit, certificate or credential handling, and network boundaries.
7. Reliability: test reconnect, restart, backup, restore, and degraded modes.
8. Handoff: provide architecture, tag list, alarm list, test cases, backups, and known limitations.

For compensation research, use the SCADA engineer salary guide. It explains why U.S. BLS data must be mapped through adjacent occupations rather than presented as a direct SCADA-engineer median.

For dispersed or unmanned field sites, the RTU guide and downloadable site-design checklist covers telemetry modes, communications-loss behavior, time synchronization, power autonomy, store-and-forward evidence, and end-to-end commissioning.

Project handoff package

scada-tank-lab/
  README.md
  architecture.pdf
  control-narrative.md
  tag-list.csv
  alarm-list.csv
  user-role-matrix.csv
  test-cases.csv
  test-results/
  screenshots/
  backup/
  versions.md
  known-limitations.md

Do not publish passwords, private keys, production addresses, customer data, proprietary project files, or security-sensitive diagrams.

Frequently asked questions

Is SCADA the same as a PLC?

No. A PLC executes control logic close to the process. SCADA supervises one or more control systems through data acquisition, visualization, alarms, history, and authorized commands.

Which SCADA software is best for beginners?

Choose a platform with accessible official training, a legal learning licence, a supported test driver, alarms, history, roles, and backup/restore. Ignition has free official training and a documented non-commercial Maker licence, but the right production platform depends on project requirements.

Can I learn SCADA without hardware?

Yes, for architecture, tags, screens, alarms, history, scripting, roles, and many failure tests. Hardware and site testing are still required for instruments, networks, electrical behavior, process dynamics, safety, and commissioning.

Does SCADA control equipment directly?

It can send authorized requests and setpoints. The controller should enforce process and equipment rules. Safety functions require the appropriate safety-rated design and lifecycle.

Primary sources

• NIST SP 800-82 Rev. 3: Guide to OT Security
• CISA Internet Exposure Reduction Guidance
• Inductive University
• Ignition Maker Edition documentation

Vendor documentation controls product-specific implementation. Recheck licences, supported versions, and security notices before starting a real project.