SCADA Functionality and Terminology


Thread Starter

Bronson, Robert

I put together a list of SCADA Server functionality by looking at a number of 3rd party developers. My intent is to have a list of functions to send to a system integrator. Hopefully the list would be applicable independent
of whether the HMI was Wonderware, Intellution or an OPC client. The 3rd parties I looked at were: Matrikon - Modbus/OPC Server for Modicon PLCs, Standard Automation - EFM/SCADA Server, Insight Automation - Energy Management Systems/4, Automation Solutions Inc. - AUCS 4.0, and PRAXIS -
PRAXIS Protocol Engine Please let me know if I've missed any functionality. I'm also interested to
know if the terminology I'm using is standard for oil & gas e.g., some use circuit rather than port.

1. Poll Manager Functionality
a) Primary (polling) and Monitor Modes
b) Multiple Poll types (i.e., Regular, Historical, Full)
c) Polling Priorities (High, Medium, Low for Regular Polls)
d) Demand Poll
e) Report By Exception

2. Port Functionality
a) Multiple Port Support
b) Multiple Baud Rate
c) Serial and TCP/IP
e) Same Station Delay
f) Baud Rate Support
g) Direct, Modem/Radio, Dial-up

3. Multiple Protocol Support
a) ROC and Modbus
b) Multiple protocols on a single port

4. Configuration
b) Port Sharing Supports RTU Configuration
c) Communication and Device Parameters Changes On-Line
d) No Overall Loss of Communication with configuration changes
e) Initial Auto-Configuration from RTU/PLC

5. Communication Diagnostics
a) Communication Status Flag
b) Poll Count
c) No Response Count
d) Incomplete Poll
e) Fail retry count
f) All Station Time Update
g) Response Timeout

6. HMI Interface Support
a) OPC
b) HMI Access to communication Diagnostics
c) HMI control of Demand Polling/Polling Interval or Priority
d) HMI Read of Historical Data, RTU Alarm logs, RTU Event Logs
e) HMI able to have complete control of Device Polling for Trouble Shooting Purposes

Olga Rojkovskaia


I would suggest to add SCADA Server redundancy and functionality, associated with it, such as Hot Standby Server and Switchover.

As addition to "Poll Manager Functionality" I would suggest time synchronization over the network.

In "Port functionality" there could be added parameters, specific to each particular type of communication (eg. key up/down delays for
radio; dial-up modem init. string etc.).

In some systems I've also seen tools like software
Protocol Analyzer or "Sniffer", allowing in-depth troubleshooting of communications, integrated into communications server.

Oleg Rojkovski
Project Engineer, Spartan Controls Ltd.

Anthony Kerstens

> 1. Poll Manager Functionality
f) Poll rate/intervals
g) Dynamic poll table optimization (like Wonderware servers).


> 6. HMI Interface Support
g) DDE (for older drivers for older devices no one want to touch anymore.)

Anthony Kerstens P.Eng.

Michael Johnson

Would multiple port support be the same as Server/Client capablities?
What about usage on operating systems other than MS Windows?

Al Pawlowski, PE

With regards to this feature list, here are a few of my favorites. Note that they are not universally provided by the popular SCADA packages, but have proven to be pretty useful for me.

1) Remote unit simulation. Flip a (software) switch and the remote I/O points reverse types (inputs become outputs) and their comm links become "responders" vs "pollers". If you copy part, or all, of a system configuration and do the flip, you can simulate the field units. Very
helpful for system integration and troubleshooting comm (especially radio) link problems.

2) Deviation vs snapshot historical data logging. With deviation logging, the data is logged with a time stamp only when its value changes by a user adjustable amount (usually % of scaled range in
engineering units). With snapshot, a simple copy of the database, or some of it, is made at known intervals; often including data averaging to save disk space. The problem is that the most valuable logs are those that show unusual values; just the ones you lose with an averaging scheme. Although deviation logging has become more popular, there are still some packages that don't have it as a standard function.

3) Comm link control that allows individual remote unit poll by the user while the rest of the system is in operation. This allows you to check on an RTU with the system up.

4) Ability to run more than one protocol on the same comm link i.e. logical links vs physical. This is really nice when you want to gradually revise a link or do retrofits.

5) Percent "up time" for each remote to master, and vice versa, comm link. And the value, along with all other measures of comm link "goodness", should be stored so that it can be logged, alarmed, scaled and displayed just like a regular process variable.

6) Logarithmic charting axis scaling. Very nice for displaying variables such as Turbidity. Actually, a user adjustable partial scale zoom in/out function would be more flexible, but I have not seen it on any product.

7) Seamless combination of real time values with logged values on trend charts. It is really nice to see a trend of the last day, week, month
or whatever simply by scrolling from the current value back on the time axis.

8) Copy, paste, of all configured components i.e. a whole comm link worth of remotes and their points for instance. Obviously, a great time

9) Automatic computer reboot, and SCADA restart, after a power fail with all of the points at their pre-fail values, especially remote setpoints.

10) Logging of HMI screens, including dialogue boxes etc., on a triggered basis determined by the user or a control script. Nice to be able to see what the operator sees when something goes wrong. Very useful for tracking and training.

Greg Goodman

i came to this thread late, but perhaps listmembers are still interested in building or discussing a feature list for SCADA systems.

on May 9, Robert Bronson wrote:

> I put together a list of SCADA Server functionality...

> Please let me know if I've missed any functionality. I'm also interested to
> know if the terminology I'm using is standard for oil & gas e.g., some use
> circuit rather than port.

not a bad list, for a start. here are some other features i look for (and have built) in SCADA software.

- toolkit/API for writing custom protocol drivers

- toolkit/API and/or support for commodity protocols to allow live data monitoring by 3rd-party or custom software

this could include C/C++ libraries, Java classes, SQL service, DDE, ODBC, client extensions to Tcl or python, etc

it can also include HTTP support for data monitoring in web browsers

- support for industry-standard import/export file formats

comma-delimited ASCII files for configuration import/export,
COMTRADE for waveform capture,

- I/O value processing

this includes, but is not limited to: scaling, engineering units conversion, and deadbanding

it also includes the ability to code (compiled or scripted) custom conditioning routines

- support for datatypes more complex than
bit/byte/word/longword/float/string in the I/O subsystem

RTUs, PLCs and IEDs can provide timestamps, scale-and-add register pairs, EBCDIC register values, waveforms, etc

some of these, like timestamps, can be translated in the protocol driver to a standard form for presentation to the SCADA database

there should also be a mechanism for sending and receiving binary blocks of arbitrary size, not just discrete values. for instance, code or configuration blocks can be uploaded and downloaded without the SCADA system needing to know what's in them.

similarly, waveforms or fault records can be captured from an IED and stored to a historical database for later retrieval, parsing and display by custom software.

also, the SCADA system needs to be able to aggregate a collection of tags into an output block. many IEDs are configured with block
commands; each value gets modified in the HMI separately, but the entire configuration block is sent as a whole. ideally, the system should
allow configuration blocks to be written to an archive, then later selected and downloaded. (this is the basis for a SCADA-based configuration management system for IEDs.)

- data quality flags!

initial data = configured initial value
stale data = last known value, but not updated from I/O since system startup
manually entered = data entered by the operator
no data available =
overflow/underflow = indication provided by RTU/PLC
comm timeout = data unavailable due to poll timeout
comm failure = data unavailable due to other comm failure

additional user-defined data quality flags that can be presented by a custom I/O driver

- alarm generation and management

various levels of alarm (warning, urgent, critical); better if the user can specify both the list of levels and the level generated by each

alarms on the various states of multi-state values

alarms on analog ranges (lo-lo, lo, hi, hi-hi), rate of change

alarms on control timeout and uncommanded change of state

customizable strategies for acknowledging and clearing alarms. some clients want an acknowledged alarm to "clear" (disappear from the alarm list) when the alarm condition no longer obtains; other clients want the operator to explicitly acknowledge and clear each alarm.

- audit trail

which user changed what, and when. not just who sent what controls or acknowledged which alarms, but who changed which fields in which tag
configurations, who executed what maintenance utility, and who visited which screen that fired off an scripted entry action

- various historical compression strategies

- network distributability

can i run different I/O drivers on different boxes and feed a single database?

can i run multiple MMIs on the network connected to the same server?

- communications diagnostics should be available for each pollable data block, entire remote devices (aggregates of pollable data blocks from a
given address), and from an entire channel.

the point here is that comm statistics are useful as diagnostics only if they help identify the problem. comm stats should help me
distinguish between a misconfigured poll ("no such register in this PLC"), an incorrectly addressed device ("no device at address 10 on this
network"), a flaky I/O card in a PLC ("how come I have a 30% failure rate on that device, spread across all the pollable blocks?") and a badly terminated Modbus+ cable or noisy serial line ("how come i have 50% failure across the board on this channel?").

- multi-user, with security

different users have access to different features and functions of the system, based on their user profile, without the need for password
control of each control point or screen

Greg Goodman
Chiron Consulting -- -- (713) 869-6876