Developing a control logic specification
By Michael Whitt
The primary purpose of a Supervisory Control and Data Acquisition (SCADA) system is to provide useful information to an operator in a timely, pertinent fashion.
Sometimes, this means the data needs to display over time in a trend display or chart. Sometimes, the instantaneous (real-time) value of the data needs to be on display too.
A well-written control specification will describe how the systems integrator should manipulate the data values as it permeates the control system.
In a typical scenario, data flows from the sensor, generally as a 4-20mA signal, on copper wires. Most analog-to-digital (A/D) converters convert the current on the wires to a voltage, usually a value from 1-5VDC.
The programmable logic controller (PLC) input module converts this voltage to an integer value. The integer value could range from 0-4095 (for 12-bit resolution). This numeric value is representative of the measured process parameter, but it is not very useful in its raw integer form.
The PLC programmer converts that value to something that represents the engineering unit calibration range of the transmitter. For a pressure transmitter scaled to produce a 4-20mA output on an input ranging from 0-10PSI, an integer value of 2048 would represent a pressure of 5PSI.
This data has value to the operator and is the data that goes to the human-machine interface (HMI) for display. The data that reads out to the operator on the graphic screen is "real-time" or "instantaneous" data, even though the refresh rate on the HMI screen is much slower than the scan rate of the PLC.
That same data sample also transmits to a data repository where it stores away for future use. This is "historical" data, and the repository is a "Historian."
In preparing the control specification, it is a good idea to lay out the guidelines for how the PLC manages the data and how it transfers to the HMI. If left to his own devices, a programmer may elect to work entirely with the raw integer value while in the PLC.
This, in fact, used to be the norm; since memory space was precious in the PLC, it took a lot of memory to do floating-point math in the PLC, and it slowed the network down to pass it to the HMI.
Another tactic used was to convert the raw integer to an integer that represents a real number, but with an implied decimal point. The benefit of this is it improved readability inside the PLC program while staying away from the expensive floating-point manipulations.
The value can then convert to a floating-point number at the HMI for display. Most of the newer PLC systems are 32-bit, and as such, there is no benefit in doing anything other than converting to a real number in the PLC as 32-bits are allocated for each tag regardless of whether it is used or not.
Sequence of events
The sequence of events (SOE) is critical in applications where an alarm condition could set off a flood of discrete (on/off) alarm signals that could all occur within the span of one or two PLC cycles.
Such floods make root-cause analysis difficult or impossible using just the PLC. There are a couple of ways to deal with this:
- If the signals are few and the risk of a flood minimal, then the signals could be hardwired to an inexpensive electronic (as opposed to digitally scanned) annunciator that has SOE capabilities. Know that the major PLC brands all have an SOE module that sits in their I/O rack that does the high-speed scanning, time stamping, and recording itself, independent of the PLC scan rate. Again, this is usually for small numbers of SOE data points.
- If there are many possibilities, many signals, or if the risk of an alarm flood is high, then a dedicated SOE recorder may be appropriate. SOE recorders continually sample many points, thousands in some cases, and log events at very high resolution. The scan rate in an SOE recorder is certain to be within one millisecond, regardless of the number of points, whereas the PLC scan rate can vary between 10 and 100 milliseconds or worse. In cases where dedicated SOE systems are used, the field signals probably need to be parallel-wired to the PLC also. Make sure the first termination point is the SOE connection, with, perhaps an interposing relay or data highway serving to forward the signal to the PLC.
Most HMI packages have at least some inherent storage capabilities for displaying real-time trends of analog signals. The efficacy of these data historians is spotty at best, and varies a lot, depending on the HMI software. A real-time trend displays the most recently scanned data value, plus some number of previous scans. These trends usually show between five and 30 minutes worth of historical data.
In enterprise control systems where there are a large number of data points, a dedicated data historian server usually gathers data samples for storage, analysis, and display. The control specification should describe the approximate number of points to be sampled, the sample frequency for each signal type (temperature, flow, etc.), and the length of time between archives.
The single most under-specified item is generally the reports that will need to come about upon completion of the project. Reports can help to validate or refute assumptions, provide the basis of a cost/benefit analysis, or merely provide a list of alarms that occurred over a 24-hour period. Report formats and content and perhaps even samples should be included in a well-written control specification. There are several basic reports that come to mind:
- Daily/weekly production reports
- Daily/weekly raw materials usage reports
- Daily alarm summary report
In addition, decisions regarding how reports generate must transpire. Will the operator initiate the report from the HMI, or at a stand-alone PC? Which operator will generate the report, and at what time during the day? Will it come as a hardcopy, or as a file, or both?
A properly specified set of reports and alarms is critical to the eventual turnover and takeover of the system by Operations. The vetting of this portion of the control specification is critical and, if possible, the Operations people should review and approve it. This will greatly reduce misunderstandings and related rework and will go far toward guaranteeing the systems integrator delivers a system that will behave as desired.
ABOUT THE AUTHOR
Michael Whitt (firstname.lastname@example.org) is an ISA Senior Member and the Manager of Integrated Systems at Mesa Associates, Inc. His book is Successful Instrumentation and Control Systems Design, ISA Press, 2004.