Design Methodologies for Process Control


Thread Starter

Steve A

I have been designing small to medium sized Process Control systems for several years without using any formal design methodology. However, as my projects are starting to get larger and more complex I am finding that I am needing a more formal strategy.

I'd like to hear your feedback and experiences with design methodologies out there that are most suitable for Process Control applications. I'm interested in ideas on everything from generating specifications to program design to testing and documentation.


I am with an SI that does a lot of pharmaceutical work so our methods are fairly rigorous. However, we use more or less the same methods on other projects because we have found that getting it right the first time prevents delays and saves money. Plus, once one has developed the tools and templates...

If the scope is instrumentation, valves and control panels, the required inputs are P&IDs, process data (generally in the form of a process flow diagram) and a user requirements specification. This latter document is generally provided by process engineering (with some handholding by I&C) and describes the sequence of operations, process limits, critical process parameters and any special batch or regulatory loop requirements.

The first phase outputs are:
1. An instrument list in a relational database with associated info such as wire lists, selected brand and model no etc. This eventually becomes a tool during implementation (produces tag databases for controllers and HMIs, wire labels etc).
2. A datasheet package with sizing calcs for flow meters, level xmtrs, control valves, rupture disks and relief valves.
3. A hardware functional spec describing in detail the controllers, the PCs, the I/O, control panel components, any network hardware, power, grounding, a hardware tagging convention, an I/O list with addresses or tag names, project conductor conventions and wire color conventions.
4. A software functional spec describing all software licensing for both development and runtime, general rules for input and output handling (debouncing, buffering, scaling, alarming, resolution, units of measure), general rules for sequencing (including primary/standby, lead/lag, position feedback handling, logic interlocks between valve position and motor status), general rules for regulatory loops, a program file structure with file names, integration methods to foreign platforms or existing systems including a shared data list with addresses or tag names, a project tagging and labeling convention, a general discussion of HMI screens, HMI screen color conventions, security provisions and a method for handling any special requirements of the user requirements spec.
5. Control panel design drawings including loop drawings that correspond exactly to the I/O and tag lists in the other docs.

Phase 2:
1. Detailed design spec for the control logic and HMI including a list of all adjustable setpoints and alarm limits (with tag names), a precise discussion of how each system output operates with tag name references (we prefer to organize this by process area, control loop and/or batch phase but the possibilities are endless). Each HMI screen is described with regard to content and functionality. Security is described in detail including default passwords and a methodology for change. As a side comment, we always include a password protected screen for commanding outputs in manual mode because this significantly reduces the amount of engineering participation required during later commissioning and testing phases.
2. Commissioning procedure for the system including project specific forms for task verification. The tasks may include fieldbus segment checks, loop checks, valve travel setting, instrument calibration, P&ID walkdowns, control panel drawing redlines, alarm system checks. Note that we define a loop as from field device to control room so that checks discover addressing troubles as well as field problems. This document, except for importing project specific tag lists and the like, changes little from project to project.
3. Acceptance test procedure uses the hardware and software functional specs as the sole source docs. We inspect/test to insure that all specified hardware, software licensing, control logic and HMI screens are as described in those specs. This procedure is a cut and paste exercise.

We have the project manager and the process engineers comment and sign off on each revision of each document.

Commissioning and test procedures typically take a couple of days apiece. Datasheets take quite a bit of time, particularly if the valve or flow meter count is high. The rest of the stuff takes about a week apiece with perhaps a few days total to incorporate comments. Time estimates assume that the formats, templates and database tables are existing.

Hope this helps.


Jeremy Pollard

Try Process Automation - A methodology
A paper for automation engineers Overview

This paper describes an approach to the development of highly automated process systems. The methodology covers all aspects of the life cycle from requirements definition through implementation to validation, and can be applied concurrently with the project design engineering on a fast-track project.

I have reviewed this product as well and will appear in the Sept issue of Manufacturing Automation (

Worth the research

Cheers from: Jeremy Pollard, CET The Caring Canuckian!

Control Design
Manufacturing Automation
PLCopen North America - p[email protected]

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579