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. 


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