January 2008

Developing a control logic specification
By Michael Whitt
Writing the software that controls the plant equipment is an interactive task. 

The programmer writes the software, of course, but he does not do so in a vacuum. The process described here is not
platform specific. Whether DCS, PLC, or PC the objective is the same: The software must do the job, but further, it must
satisfy both the maintenance and the operations departments to the fullest extent possible.

This can be quite difficult. Many production personnel are unable to read logic diagrams, electrical drawings, or software
listings, yet invariably they have the final say in the "look/feel" aspect of the project. 

Production personnel generally operate best in a text­based environment (procedures, lists), while the technical person
usually is more comfortable in a graphics­based environment (drawings, charts). It is important to get buy­in from both
organizations. 

The real trick is to reconcile the two in a cost­effective manner.

The "Law of Unintended Consequences" is especially active in the systems integration arena. Many times, mistakes
made cannot be spontaneously and surreptitiously corrected "by the field," as is so often the case with the design­drawing
package. 

The work of the systems integrator is "out there" for all to see. Therefore, it is important for integrators to begin by spelling
out their understanding of what they are about to do at their customer's behest. 

To reduce potential rework due to unintended consequences, customers should require some feedback from integrators
before they begin the task, and integrators owe it to themselves to develop a good vision of what they need to do to satisfy
the scope of work. Thus, a well­written control specification serves both masters and increases the likelihood of a
successful project.

One approaches the process in stages that gradually increase the level of detail until the control scheme is mature and
defined. At a minimum, a control specification should address the topics listed in the table to the right.

Over the next year, in this InTech space, we will explore the process of developing a control specification. 

In this month's analysis, let us focus on Section 1 ­ Process overview.

Only the major functions

The integrator typically gets a set of instructions, which, depending on the technical sophistication of the customer, can be
quite vague. Sometimes the instructions can be a simple statement such as, "I want this to do that!" 

Even in clearly spelled out cases, there is usually ample room for misunderstanding. 

The process overview is where we begin to understand the scope of the task. There should be at least a paragraph about
every major process area or task. If the project is a retrofit, then each sub­section should have a paragraph about what is
in place today, and what will be in place at the end of the project. Here is good process overview:

This is a plant that sorts and refurbishes widgets. The raw materials are unloaded, transported, cleaned, sorted,
packaged, and shipped. This project will automate selected portions of this operation. Following is a brief description of
the work that will transpire: 

1.  Unloading: A truck dumps the product in the receiving hopper, and the driver notes the weight of materials
 delivered. This project will add weigh cells to the hopper to validate the driver's log.
2.  Transport: Operators open a manual gate to empty product from the receiving hopper into a rolling bin, which they
push to Building B for processing. There, they dump the rolling bin contents into a cleaning hopper. This project will
install an automatic receiving bin discharge gate valve and a transport conveyor with speed controls.
3.  Cleaning: A rotating cleaning drum takes the product from the cleaning hopper and processes the material through
a series of wash and dry cycles. The materials are manually loaded into the drum (which is manually controlled) and
manually retrieved after drying. This project will automate the drum cleaning sequence, excluding the load and
unload operations.
4.  Sorting: Operators open a manual gate to empty product form the receiving hopper onto a sorting table, where the
items are sorted into one of four classification bins. There will be no change to this operation.
5.  Packaging: Operators place a pallet­mounted box under the classification bin and open a manual gate valve to fill it
to a specified level in the box. This project will add a small man­machine interface (MMI) at the classification bins,
will automate the gate valve, and add a weigh scale beneath the bin. The operator will press a button on the MMI,
and the box will fill up to a specified weight.
6.  Shipping: Boxes are manually loaded on the truck. There will be no change in this operation.

It takes a small number of words to communicate the overall intent of a project, but the value of the overview is immense. It
should be in simple language that is comprehensible to non­technical upper management, thus giving everyone
associated with the project an opportunity for buy­in, the ultimate goal of a well­written control specification. 

ABOUT THE AUTHOR
Michael Whitt (mwhitt@mesainc.com) 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.

Key sections for a control spec
Section 1 ­ Process overview

Section 2 ­ Operability & visualization

Section 3 ­ Device control

Section 4 ­ Contiunous control

Section 5 ­ Sequence control

Section 6 ­ Alarms & reports

Section 7 ­ Data flow & historization

Section 8 ­ Fault tolerance & recovery
February 2008
Developing a control logic specification
By Michael Whitt
Editor's note: January's Channel Talk focused on Section 1 ­ the Process Overview. In this month's analysis, let us focus
on Section 2 ­ Operability & visualization. 
Operators must not only be able to run the plant, but be able to do it with the confidence that they are getting the right
information at the right time. 

They must be able to enable and disable automatic operation and enter set points, but they also need to be able to run
reports, monitor alarms, and perform a myriad of other tasks particular to their situation. 

However, simply defining the tasks the HMI must support is only a part of developing an HMI specification. Beyond
providing functionality, the HMI design should put operators in their comfort zone. This includes color considerations,
screen hierarchy, alarm management issues, and other purely esoteric considerations that otherwise would not be
necessary to simply get the job done. 

Therefore, the operator interface specification is a "corporate" task, requiring the active participation of all concerned.

Human­machine interface is a broad term that encompasses the following subsystems:

The Graphic User Interface (GUI) is a utility that allows the user to create graphic screens that let the operator view
the process and quickly gain an understanding of its condition. Most of the time, these screens appear as "cartoons"
depicting the process equipment using animated graphics. Some of these screens also give the operator the ability
to modify the process by linking the graphics to action tags that force the PLC to react.
The action/animation database dovetails with the GUI package. It provides a means for linking the graphics to the
control system and, ultimately, to the process equipment. This database lets the user give the active graphic
elements names, or "tags," useful for troubleshooting, define their action/animation characteristics, and define their
links to the outside world.
The device driver is a software utility that mates the HMI to a control device like a PLC. The driver manages
(translates) HMI data requests and transfers them onto the communication network.
The alarm manager is a software utility that monitors alarm tags. These tags link up to process sensors and switches
and to embedded PLC logic. They log alarm events, date and time stamp them, alert the operator by either audio or
visual means, and allow the operator to acknowledge or clear alarms.
The data historian is a software utility that stores data collected by historian tags. These tags sample specific
process sensors at timed intervals and store the information in data archive files on the workstation.
The report generator is a software utility that generates process reports.

A well­written control logic specification will include requirements for each of the subsystems listed above. Some of the
tools that may be used are:

A Graphics Design plan to provide information on the color palette, shapes, and texture
An Animation Plan to provide guidance on situational animation (two­step operator action), active illumination (flash
& blink), and active sounds (beep & click)
A Navigation Plan to provide guidance on how the operator will move from screen­to­screen
An Alarm Management Plan to describe alarm philosophy and expected operator interaction
A Security Plan to describe layers of accessibility
An Information Management Plan, describing the number of reports needed and the content
A Data Communications Plan, describing data flow, devices, and device drivers
An Environmental and Ergonomics Plan, describing considerations needed for operator comfort and ease of access
The HMI Control Specification is a key chapter in any Control System Specification, as the HMI becomes, in the end, the
most visible part of the control system as a whole. 

Time spent on the front end developing the specification is time well spent.

ABOUT THE AUTHOR
Michael Whitt (mwhitt@mesainc.com) is an ISA Senior Member and the Manager of Integrated Systems at Mesa
Associates, Inc. Section 1 of this series is atwww.isa.org/link/channel_talk. His book is Successful Instrumentation and
Control Systems Design, ISA Press, 2004.
April 2008
Developing a control logic specification:
Device control
The control logic specification should define the configuration requirements for all of the major device­related elements.

In this context, a "device" is a control element, not a field device, though most control devices tie to a field device.

While it may appear to be daunting, there really are only a finite number of device types in any control package,
regardless of the size of the project. Each field device will have at least one, but perhaps several, associated control
devices.

Here is an overview of most of the major ones.

Analog input device­sensors

Sensors detect process elements such as pressure, flow, temperature, and the like. Each sensor will have several
parameters that should have definition in the control specification:

Scaling blocks­Convert the input signal to Engineering Units (EU). EU conversions sometimes take place in the I/O
module itself, depending on system capabilities; else, the calculation transpires inside the PLC program.
Regardless, the input scaling feature of the system should provide a means of detecting open circuit conditions and
of individually setting failure behavior on open circuit detection. For example, it is frequently advantageous for a
critical temperature signal to exhibit "upscale burnout" when faulting, forcing the value to its maximum level. This will
cause a severe system reaction when a temperature probe fails, forcing the system to automatically drive to its most
safe condition.
Analog alarm blocks­Each sensor should be able to have alarm set points entered and have alarms generated from
the input signal. Most pre­configured AA blocks have four alarms­two that activate on rising values and two that
activate on falling values. Generally, the lesser settings generate "warnings," and the extreme settings generate
"alarms." The specification should describe the difference between the two in terms of the alarm manager and HMI
animation. Typically, a warning does not list in the alarm manager, whereas the alarm does. A warning might
appear as a value turning yellow at the HMI, while the alarm might turn that item red.
Simulation­If the choice is for simulation of the analog values for testing purposes, that fact should be in the
specification.
Animation­Define the colors and flash behavior for each alarm condition.

Discrete input device­switches

Debounce timers­All switches should have individually configurable debounce timers to reduce nuisance alarms
and inadvertent action.
Simulation­If simulation of input switches for testing purposes is a desire, then include that in the specification.
Animation­Define the colors and flash behavior for each alarm condition.

Discrete output­motors and valves

Click action­Typically, two actions are required before any direct action can be taken. This is a safety requirement
that we meet by forcing the user to click once to open a control overlay, and then click again to take the action. In
some critical cases, a click action may need to respond after a login or entry of a security code.
Motor run timers­Track the number of hours a motor runs. This feeds into the plant's predictive maintenance
program.
Motor inhibit timers­Prevent rapid restarts. Restarting too quickly will cause overheating of the windings, reducing
 service life. Restart times vary according to the size of the motor.
Mismatch timers­Alert the operator if commanded state differs from actual state for longer than reasonable
expectations permit.
Interlock status indication­Display the interlock list, and indicate the status of each item.
Interlock action definition­Define what happens when an interlock is lost. Typically, loss of an interlock places its
related device in a "safe" state, from the standpoint of the process, and takes the device out of automatic mode. This
forces the operator to take action before the device will again react to automatic commands.
Permissive status indication­Describe any requirement to display the permissive list and status indication if desired.
Permissive action definition­Define what happens when a permissive is lost. Typically, loss of a permissive places
its related device in a "safe" state, but leaves the device in automatic mode. When the permissive is back, assuming
the other conditions (such as inhibit mode, etc.) still warrant, the device will start, open, or otherwise revert to its
normal operating mode.
Animation­Define the colors and flash behavior for each state of the device. Most devices have at least three states:
On, off, and travel (or mismatch). Depending on the industry, green may indicate running or open, while in other
industries those conditions may be red. Travel might be solid yellow, with the mismatch alarm causing the yellow
symbol to flash. Regardless of animation plan, define that plan for each end device.

Analog output device

Analog output devices include throttling valves, variable frequency drives, and others. Some of the points of discussion
could include:

Auto/manual switching­Define user security level for switching between modes. In auto mode, the output derives
from some function internal to the control system. In manual mode, the output is operator driven, via manual trim or
manual loading.
Manual trim­Discuss the manual increment/decrement feature, whether it is required and what percent of scale per
bump.
Manual loading­Is it necessary for the operator to be able to force the output to a specific setting? Via keypad?
Deviation alarm­If feedback exists to allow comparison between command and actual position, it is possible to
deploy a deviation alarm.

Analog control device

One of the more common analog control devices is the Proportional­Integral­Derivative, or PID, block. Some points of
discussion for this function could include:

Auto/manual switching­Define user security level for switching between modes. In auto mode, the output goes up or
down depending of the difference between the process variable (PV) and the set point (SP).
Remote/local set point­Define user security level for switching between modes. In local mode, the operator enters
the set point using a keypad. In remote mode, the set point links to another control function in the control system.
Deviation alarm­Define the alarm action if PV deviates from SP beyond a definable percentage.

A properly defined set of Device Control Requirements 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 (mwhitt@mesainc.com) 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.
November 2008
Continuous control logic specification
For almost any project, there will be three types of control: Discrete Devices (www.isa.org/link/CT_0408), Continuous, and
Sequential.

The control logic specification should define the configuration requirements for all of the major continuous­control
elements. A continuous control element is one in which the process variable (PV) is allowed to modulate within a
specified range. Sampling the PV takes place at a given frequency and comparison to a desired state­the set point (SP)
transpires.

A control variable is then developed and fed to an end device that affects the PV such that the error between SP and PV
moves toward zero. The desire is to reduce the error to zero and maintain it there.

However, due to physical limitations of the equipment, and other real­world impacts, it takes a continual cycle of
corrections to maintain a minimum of error.

One of the key purposes of the control specification is to provide control tolerances that describe the magnitude of
acceptable errors (must the error always be zero, or is "dead band" that is acceptable?).

Documentation: A control specification will need to define the method of documentation for the control scheme. One
acceptable method is the Scientific Apparatus Maker's Association (SAMA) diagram. Another method that is gaining
popularity is the Function Block approach. Either way, the control specification will need to define how the project's
documentation will proceed.

Human ­ Machine Interface (HMI) aspects: The purpose of the continuous control function is to free the operator from
having to make continual adjustments to the process. Thus, it is not necessary the controls be visible on the main graphic
screen unless the operator wants to make a change.
Some of the more common considerations for display on the main graphic are:

Analog value of the PV displayed in engineering units
Alarm animation for high, high­high, low, low­low, bad signal quality, and deviation from set point
Status indication for local/remote and auto/manual

Types of continuous control

PID (proportional/integral/derivative): In this type of control, three parameters (gain/reset/rate) define how the control
element will react to a deviation between PV and SP over time. GAIN defines the instantaneous magnitude of the
response, RESET corrects any resulting offsets over time, and RATE makes the controller more reactive based on
the rate of change of the input. A particular control element may employ any one or all of these parameters in order
to achieve stability.
Cascade is loop in which one PID function serves as the set point of a second function.
Ratio is often in conjunction with a one or two PID control functions, the ratio function is primarily for blending
applications.
Reduce misunderstandings
It is important to pre­define the behavior of each control scheme. Some of the considerations for a continuous control loop
are:

Auto/manual (A/M) switching: This action is typically done at the HMI. When switching from auto to manual, there are
two behaviors that need to be defined for the set point: 1) SP Tracking On, where SP follows PV while the controller
is in manual, thus providing for a bumpless transfer when the operator transfers back to Auto; or 2) SP Tracking Off,
where the SP retains its last good value while in auto. The first case guarantees a bumpless transfer from manual to
auto, while the second case guarantees that the process variable will "bump" back to its last good automatic SP.
There are good arguments for each method, depending on the process.
Local/remote set point mode: Local SP is generally the data entered at the HMI's keyboard by the operator. A remote
SP is generally for Cascade loops where an external algorithm calculates SP.
Direct/reverse acting: If an output is supposed to increase if the error between PV and SP is increasing in a positive
direction, then a controller is direct acting. Conversely, if the output is supposed to increase if the error is
decreasing, it is reverse acting. An example of a direct acting loop would be a cooling water loop. As temperature
increases, the amount of cooling water would need to increase. Tank level would be an example of a reverse acting
loop. As level increases, the amount of water fed to it would need to decrease.
PV deviation alarm: Alert the operator if the error between PV and SP exceeds a specified amount for longer than a
specified period of time.
PV magnitude alarms: An alarm management scheme should describe the high, high­high, low, low­low alarm SP
and debounce times. One should define all and any actions that are necessary as the alarms activate.
Interlock action definition: Define what happens when an interlock is lost. Typically, loss of an interlock places its
related device in a "safe" state, from the standpoint of the process, and takes the device out of automatic mode. This
forces the operator to take action before the device will again react to automatic commands.
Permissive status indication: Describe any requirement to display the permissive list and status indication if desired.
Permissive action definition: Define what happens when a permissive is lost. Typically, loss of a permissive places
its related device in a "safe" state, but leaves the device in automatic mode. Upon restoring the permissive, and
assuming the other conditions (such as inhibit mode, etc.) still warrant, the device will start, open, or otherwise revert
to its normal operating mode.
Animation: Define the colors and flash behavior for each state of the device. Most devices have at least three states:
on, off, and travel (or mismatch). Depending on the industry, green may indicate running or open, while in other
industries red color may indicate those same conditions. Solid yellow color might indicate travel, with the mismatch
alarm causing the yellow symbol to flash. Regardless of animation plan, define it for each end device.

A properly defined set of Continuous Control Requirements will greatly reduce misunderstandings and related rework,
and will go far towards guaranteeing the systems integrator delivers a system that will behave as desired.

ABOUT THE AUTHOR
Michael Whitt (mwhitt@mesainc.com) 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.
December 2008
Sequential control can be the most difficult
By Michael Whitt
For almost any project, there will be three types of control: Discrete devices, www.isa.org/link/200804CT;
Continuous, www.isa.org/link/CT_1108; and Sequential.

The control logic specification should define each of the major sequential­control subsystems and give a general outline
of how the system needs to behave.

A sequential control element is one in which a series of activities need to occur in a specific order.

Every process control facility, even if it is primarily a "continuous" process, has sequential aspects. Startup and shutdown
are two examples that are hard to escape.

Sometimes, the sequences are operator­intensive, where the operator gets the system to a stable operating condition and
then puts it into automatic mode. However, other systems are not. Batch applications, for example, are sequence (recipe)­
heavy.

One of the best ways to describe a sequence is to use a Sequential Function Chart (SFC). An SFC consists of States and
Transitions. Each box, in the SFC diagram, represents a miniature "step" program that executes until the "transition"
condition shown beneath it becomes true. When that occurs, the program transits to the next Step, and executes those
tasks.

In this chart, the long, horizontal, double­line represents an "Or" function.

A Step can contain a single command, or it can even contain another SFC.

In either case, part of the transition logic should contain confirmation that the action(s) commanded in the Step logic has
actually occurred, thus making the logic deterministic.
Sequence structure
However documented, the "specifier" should insist the programmer be able to answer the following questions for each
Sequence:

1. What are the Start Conditions for this Sequence?

 a.  Start the Sequence Timer

 b.  Raise the Sequence Active Flag…

2.  Are all sequence­related devices in Automatic? It may be desirable to have a Zone­Auto/Manual feature to allow the
Operator to put all the devices in automatic, or to automatically put them in Automatic when the sequence is activates.

3. What are the Exit Conditions for this Sequence? 

4.  What are the Exit Actions for this Sequence?

 a. Stop the Sequence Timer

 b. Lower the Sequence Active Flag…

Sequence step structure
The programmer should be able to answer the following questions for each Sequence Step:

1.  What are the Start Conditions for this Step?

2.  What actions should take place in this Step?
 a. Start the Step Timer and Raise the Step Active flag

 b. Open Valve X, etc.

3.  How long should this Step be active before setting
 an alarm?

4.  Should this Step have a "Jump" function? If so,

 a. What are the Jump Conditions?

 b. What are the Jump Actions?

5. Should this Step have a "Pause" function? If so,

 a. What are the Pause Conditions?

 b. What are the Pause Actions?

 c. What are the Resume Conditions?

 d. What are the Resume Actions?

6. Should this Step have a Safe­State program? If so,

 a. What are the Safe­State Conditions?

 b. What are the Safe­State Actions?

 c. What are the Resume Conditions?

 d. What are the Resume Actions?

7.  What are the Exit Conditions for this Step? This is  the Transition Logic.

8.  What are the Exit Actions for this Step?

 a. Stop the Step Timer

 b. Lower the Step Active Flag…

Human­machine interface aspects
Sequences can be the most difficult of the control schemes from an operator's standpoint. Being able to know whether the
sequence is operating correctly can be the difference between a good batch and a bad one.

At a minimum, the HMI needs to provide key information
to the operator as to the Active Step and Step Time. Alarm status should feed in as well, and it should tie into the HMI
Alarm Manager.

It is important to pre­define the behavior of each sequence. Some of the considerations are:

Auto/Manual (A/M) Mode Switching­In some cases, it may be desirable to give the Operator the ability to single­step
through a sequence (Manual Mode). In Manual Mode, even if the transition conditions are met, the transition logic
will not be satisfied until the Operator presses the Next Step button. At that time, the next step will activate.
 Start/Stop/Pause/Resume Mode Switching­Define the mechanism that will give the operator the control needed.
Animation­Define the colors and flash behavior for each state of the sequence.

A properly defined set of Sequential Control Requirements will greatly reduce misunderstandings and related rework.

This properly defined set will go far towards guaranteeing the systems integrator delivers a system that will behave as
desired.

ABOUT THE AUTHOR
Michael Whitt (mwhitt@mesainc.com) is an ISA Senior Member and the Manager of Integrated Systems at Mesa
Associates, Inc.
January 2009
Developing a control logic specification:
Alarms and reports
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.

There are three primary ways to be sure this takes place: 1) Color animation and value displays at the HMI (human­
machine interface); 2) Alarm management; and 3) Report generation.

Color animation and value displays: HMI graphic screens can provide a wealth of information at a glance by proper use of
color animation. A well­written control specification will provide color animation and value display guidelines. These
guidelines can take the form of a chart or list and need to cover all conceivable eventualities.

Each end device should be in the chart, with every animation possibility described.

Alarm management: HMI software packages all have some capacity for managing alarms. The control specification needs
to define how to display and acknowledge the alarms. It should define their behavior under different conditions. Like the
Animation Plan, the Alarm Management Plan can manifest in a chart.

The chart should include alarm priorities. Three levels of alarms are in this chart, but more or less can also work. Care
should be taken to minimize confusion by the operators, so the simpler, the better.

Report generation: The single most under­specified item is generally the reports that will need to result upon completion
of the project. Reports can serve to validate or refute assumptions, provide the basis of a cost/benefit analysis, or merely
provide a list of alarms that came out over a 24­hour period. Report formats and content, perhaps even samples should
be included in a well­written control specification. There are several fundamental reports:

Daily/weekly production reports
Daily/weekly raw materials usage reports
Daily alarm summary report

In addition, one must decide who and how to generate the report. 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 project people should vet this portion of the control specification very carefully and, if possible, give it to Operations
for review and approval. This will greatly reduce misunderstandings and related rework, and will go far towards
guaranteeing that the systems integrator delivers a system that will behave as desired.

ABOUT THE AUTHOR
Michael Whitt (mwhitt@mesainc.com) 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.
February 2009
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.

Data flow
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:

1.  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.
2.  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. 

Data historian
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.

Report generation
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 (mwhitt@mesainc.com) 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.
March 2009
Fault tolerance and disaster recovery
By Michael Whitt
In a perfect world, our control systems would install and operate indefinitely with no faults. Experience teaches us
otherwise.

Control system specifications should deal with fault tolerance and failure recovery issues.

A Hazard and Operability (HazOp) study is a good vehicle for determining the level of risk acceptable for a particular
production process. If a formal HazOp is not practical, then it is up to the specification writer to do his own analysis.

According to the National Institute of Standards and Technology (NIST), there are four approaches to achieving
dependability:

1.  Fault avoidance ­ Design phase: Use care to eliminate potential causes of faults in the design phase. This is where
a HazOp or some other detailed method of analysis is most useful. The HazOp process, when coupled with the
proper application of industry standards and accepted practices, followed by a thorough design check, should help
filter out most­but never all­of the conditions in which an avoidable fault could exist. For software applications, one
should execute a thorough Functional Acceptance Test (FAT) in which process simulation or loop­back logic
validates the software prior to shipping it to the site. The control specification should describe the level of detail that
will be required during the FAT.
2.  Fault removal ­ Pre­commissioning phase: Regardless of the thoroughness of the FAT, mating the control system up
to the actual field devices always uncovers problems. Vendor­provided equipment rarely operates per their
preliminary literature; control schemes may need modification. This is where a well­defined Site Acceptance Test
(SAT) is most useful. The SAT builds on the FAT by removing the simulation and having the software operate the
actual field devices. Removing faults during or after commissioning is extremely expensive.
3.  Fault tolerance ­ Post­commissioning phase: Allow the system to operate without an intolerable interruption in
production even in the presence of ongoing hardware or software faults. A Hot­Standby set of processors that switch
primaries upon fault detection would be an example of a fault tolerant system, as would an Ethernet ring topology
that allows a device to fail without interrupting the operation of the remaining devices on the network.
4.  Fault evasion ­ Post­commissioning phase: Sense the trend toward a problem situation, and initiate corrective action
before the problem occurs. Setting an alarm if network data throughput deviates beyond a set percentage from the
norm, giving the operator time to make corrective action would be an example of fault evasion.

Weighing failure recovery
Regardless of how bulletproof the design is, how fault­tolerant the system, or how well trained the operators and
technicians, system failures are still possible. Though we can mitigate the severity and duration of these undesired events
by and technique, the fact remains that a disastrous event could occur at any time. A properly written control system
specification should deal with this from the beginning.
How quickly could your facility recover from a major event such as a hurricane or fire? There are two major categories to
consider, the physical plant and software.

Physical plant configuration control: When a processing plant is constructed, a mass of drawings and other documents
emerge as a matter of course. The control system specification should describe the documents that are critical for failure
recovery. A complete record of these drawings should be maintained offsite. Most of those documents are static and
change very little after project installation. Some, however, provide information that could change after installation.
Instrumentation and electrical drawings fall into this category, as do Piping and Instrumentation Diagrams, instrument
specifications, electrical single lines, and other documents. It is important to maintain these documents in order to quickly
reconstruct sections of the facility if needed.

Data security: This depends on a mix of automatic and manual processes. There are two primary considerations for data
security in this context, backup and restore. Several of the more common options for managing data follow.
 1.  No offsite data, daily backups to hard drive: This is the least secure. If the computer fails, the backups are likely to be
lost. The likelihood of being able to restore is remote.
2.  Daily backup to hard drive with a weekly backup to tape or other media. Onsite and offsite storage of tapes: This is
better. In this case, the most data that will be lost is a week. Restoration is manual and can happen as soon as
retrieval of tapes. Until recently, this was probably the most common method of archival.
3.  Daily backup to hard drive with a weekly backup to tape or other media. Onsite and offsite storage of tapes.
Redundant, hot­swappable, mirrored hard drives: This is becoming a more common configuration as the cost of this
configuration falls. In this case, data constantly backs up to the mirrored drive. If one drive fails, the server switches
immediately to the backup, with little or no effect on the system. Pulling and replacing the bad drive without shutting
down the server is possible and the drive will automatically re­mirror. The risk in this configuration is less related to
the failure of the drive than to a fire or some other disaster in the equipment room taking out the entire server and
both drives, in which case, a week's worth of data will be lost.

Fault tolerance and disaster recovery are topics frequently omitted or under­described in control system specifications.

ABOUT THE AUTHOR
Michael Whitt (mwhitt@mesainc.com) is an ISA Senior Member and the Manager of Integrated Systems at Mesa
Associates.