The short answer
VTScada
VTScada is a SCADA platform built as one product rather than a set of modules: the historian, the alarm system with voice and text notification, the reporting, the thin clients, and the server redundancy are part of the base software, which is a large part of why small and medium water utilities choose it. Applications are built from tags and pages in a development environment that records every change as a version that can be compared and reverted, and a server list gives a site any number of redundant servers that synchronize their history and fail over on their own. Its drivers cover the controllers and protocols common in water telemetry, including polling by exception over radio and cellular, and it is licensed by tag count and server role rather than by client. On a site visit, the version history, the server list status, and the tag browser tell most of the story.
Key points
- Historian, alarms and notification, reporting, thin clients, and redundancy are built in, not separate products.
- Every application change is recorded as a version; changes can be compared and reverted.
- Redundancy is a list of servers that fail over automatically and synchronize history.
- Drivers suit water telemetry: Modbus, DNP3, controller-native drivers, OPC, MQTT, and slow radio and cellular paths.
- Licensed by tag count and server role; clients are not the cost driver.
Architecture
| Element | Notes |
|---|---|
| Application | Tags, pages, and configuration in one application directory; versioned automatically |
| Server | A computer running the application with server roles: I/O, historian, alarm notification, and others |
| Server list | Ordered lists of servers per role; the first available serves, the others stand by and stay synchronized |
| Clients | Full clients on the network, thin clients in a browser, and mobile clients; licensed as part of the application |
| Historian | Built in, stores tag history on each server; can also write to an external database |
| Alarm notification | Built in; voice calls, text messages, and email by roster and schedule |
| Drivers | Configured as tags; polling, exception reporting, and time stamping depend on the driver |
Why utilities pick it
A utility with a treatment plant, thirty lift stations on radio, and two operators on call needs redundancy, notification, history, and remote viewing, and needs them without a systems integrator on retainer. Having those functions in one product with one configuration reduces the parts that can be misconfigured and the licenses that can lapse. The version history answers the question every utility eventually asks, which is what changed and when, and the redundancy model means a second server is a computer and a license rather than a project.
Versioning and change control
Every change saved in the development environment becomes a version with a comment, and the application can be compared between versions or reverted. That does not remove the need for a change procedure; it makes one enforceable. The habit is a comment on every version that names the work order, a review of the version list at handover, and a periodic export of the application to the engineering library as an archive that lives outside the servers.
Telemetry
- Polling schedules per driver or per site, with slow paths polled slowly and critical sites polled first.
- Exception reporting and time-stamped events with drivers that support it, which matters on radio and cellular where bandwidth is scarce.
- Communication statistics per site, which show a failing radio path before the site goes silent.
- Alarm notification that follows a roster and escalates, driven from the same alarm tags the screens use.
On a site visit
- 1
Server list
Which server is primary for each role and whether the standbys are synchronized; a standby that has been out of sync for a month is not redundancy.
- 2
Version history
The latest versions, their comments, and whether anything changed recently that nobody mentioned.
- 3
Communication statistics
Per-site success rates and response times.
- 4
Alarm configuration
The roster, the schedules, and a test call; notification that has not been tested since the phone numbers changed has not worked since then.
- 5
Backup
An application export to the engineering library and a copy offline, with the license details recorded.
Frequently asked questions
- Does it need a separate database server?
- No. The historian is built in and stores on the application servers. An external database can be used for reporting or integration, but the platform runs without one.
- How does redundancy work across two buildings?
- Servers at both locations are in the server lists, with the network between them; the primary serves and the standby synchronizes. A site with a slow link between buildings sets the roles so that the I/O server is near the field connections and the history synchronizes at the rate the link allows.
- Can operators view it on a phone?
- Yes, through the thin and mobile clients, subject to the licensing and, more importantly, the remote access design: a virtual private network and multi-factor authentication in front of the client, not a client exposed to the internet.
- Is the free version usable for a small site?
- A limited free edition exists with a tag limit that suits a very small system or a training setup. A production utility system is licensed by its tag count and server roles.
Related topics
- SCADA RedundancyWhat redundant SCADA servers protect against and what they do not, how failover works for tags, alarms, history, and clients, the network and controller layers beneath it, and why an untested failover is not redundancy.
- Alarm Notification and CalloutGetting the alarm to the person on call when no one is watching the screen: notification paths, escalation, acknowledgment from the field, which alarms qualify, and the failure modes that leave a station in high level with nobody paged.
- SCADA CommunicationsHow SCADA servers talk to controllers and the field: polling and report by exception, the protocols and what each is for, media from plant Ethernet to radio and cellular, poll rate arithmetic, timeouts and quality, time sync, store and forward, and security.
- SCADA BackupsWhat a SCADA backup must contain to bring a system back: the project export, an image of each server, the databases, historian archives, licenses, certificates, scripts, and network device configurations, with frequency, retention, and the restore procedure.
- VPN DesignHow a VPN fits remote access for a control system: it terminates in the DMZ and lands on a jump host, never the control network; site-to-site tunnels carry telemetry; user tunnels require multi-factor and individual accounts; the concentrator is patched fast.
- Other PlatformsThe SCADA and HMI products a water utility may meet beyond the common ones: Siemens WinCC, distributed control systems, independent SCADA products, hosted lift station monitoring, and open-source tools, and the questions that decide whether one belongs.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.