Dedicated to improving your control systems with Process Control System models
About Control
What's new
Our Clients
About Diagrams
Automation Models
Online manual
Free Software
Other Downloads

 Defining the Functional Requirements

Background - A Sorry Tale

What goes wrong with batch process control system projects? Over and over again I have seen the same situation - It goes like this:-

The Plant is nearing completion, the IO Cabinets are being cabled in and back at the software supplier's works someone suddenly realises that the project is late. For the last few months they have said that they will deliver on time, but as the testing begins, or a short time before, it becomes clear that there is no way they are going to finish on time. The project goes into panic mode.

People at the suppliers start working endless hours to try to complete the software. They are battling against time, trying to obtain detailed information, testing software and finding faults, working their way through a huge list of comments and deviations. Eventually the software gets delivered, typically with some functionality removed, in order to accelerate completion. Often, the whole project is late as a result, although to be fair, it is often not only the software that is late, and sometimes the software supplier gets unfairly blamed. This happens over and over again.

As a result user companies wind back their requirements on the next project, and fail to get all the benefit that they should be getting.

It was not supposed to be like this. What went wrong?

Modern Control Systems are wonderful , whether they be DCS or PLC/SCADA, they can all do everything that a Control engineer could hope, provided they are programmed right. Provided you  know what it is you want to program it need not take long to enter. So in general the problem is not the systems themselves.

Could some activities in the front end of the project have prevented this situation from arising? Not usually - these situations arise can even when the front end does a good job of establishing basic requirements. The problem is not usually one caused by a failing in the basic concepts (although it can happen) rather it is caused by lack of detail in the Specifications, and change during the development of the plant. And it is exacerbated by people starting to code too early.

Ask the Programmers

Ask them why there are so many errors in their software -

They will mostly say that they only programmed what the spec said - it was the spec that was wrong. They may produce statistics that show that most of the 'faults' were 'improvements' or 'changes', and that actual errors were only a small part of the problem.

Ask them why it is taking so long -

They will tell you that they spend most of their time looking for information, or filling in 'unnecessary' paperwork, or going to stupid meetings.

Or that so and so who wrote the spec had a clever idea which did not work.

Or that the people who sold the project had unreal expectations

Ask them why they put in code that was not required by the spec -

It was essential or it was obviously needed or it would make the software 'better'.

The Programmers may sometimes get it wrong, often as a result of enthusiasm, inexperience or management issues. But they are far from the main culprits.

Lack of detail in the Specifications

A typical project following the classical life cycle has the following specifications produced along the way.

A User Requirement Specification - Often this is a 'container' for a large collection of pieces of information, typically including:-

Basic process descriptions
A collection of contractual obligations
The Piping and Instrument Diagrams
An Input Output list
Loop Diagrams
An Instrument list

The URS is mostly produced early in the detailed engineering phase of the project, often before the Process design and Operational requirements are finalised, and consequently it is often only approximate - for example the Instrument List does not quite match the IO List

ControlDraw requirements models can be built that provide a single coherent data and diagram repository.

A Functional Specification

This is often where the real detail appears - if it is not in the URS then is gets put into the FDS - with luck.

ControlDraw requirements models can be extended to cover all of the detail, and comparison between the URS and FDS models provides an auditable way to show how the requirements have developed and to highlight change.

On S88

S88.01 has provided users with a methodology which has produced a step change improvement in the definition of Batch plants. Not only does the standard provide a common language for developers of batch processes, it also provides users a guide to follow while defining their batch requirements.

Most process control vendors now have products based around the standard so that the functionality that S88 assumes can easily be implemented in a modern system

However, S88 is generic, it provides a basis for defining a batch process but it must be applied - for example a Unit must be described in detail so that the phases, equipment modules, control modules are all given names and specified.

ControlDraw provides an excellent tool to help in the process.

On Piping and Instrument Diagrams

In a process plant the P&ID's are the foundations, they are essential and most valuable, to all the technologies involved in building the plant, but

They do not show procedural functions.
Often they do not even show all the system IO, in particular IO that arrives from, say, a PLC in a Package
They are not Operational - see below

The P&ID's do not show the functional requirement. Yes, with a continuous plant they may have good detail on the control loops (with luck), and this is one reason why it may be possible to get a good system just by giving the supplier the P&ID's BUT this is rare especially with Batch plants. Furthermore the revision process is slow, so they hold back the development of functional requirements.

ControlDraw models can be built that provide the missing information.

Why P&IDs are not a good basis for graphics.

P&ID's are not designed for operational purposes:
They are full of irrelevant clutter - an operator knows the size of the pipes, and does not worry about reducers etc. These issues do not matter for day to day operation.
They show no dynamics at all.

ControlDraw models can be built so that the Diagrams also form a proper basis for the graphics


ControlDraw Main Features