My Distributed Control System ‘Wish List’

01 September 2006

Hans Eder has worked for many years in controller troubleshooting, development of advanced controls, and performance analysis on many different systems. Many of the features and functions needed to work effectively are still not available, he says, and so he’s created this DCS ‘wish list.’

The first control computer I ever used was a Honeywell 4500 / PMX system which had just 64 k memory! Yet, due to the clever, efficient design of the operating system (Microsoft do you hear me?) this did not prevent us from running dozens of advanced control applications plus several linear programming modules in real time.

Operating systems and application software have evolved significantly. But a closer look shows that the main developments were made in the operator interface and in supporting functionality such as alarming, reporting and the like. The ‘true’ process control functionality, however, has hardly seen any significant evolution at all. For auxiliary functions needed for the building and maintaining of controllers and control schemes, progress has been rather modest.

In some systems the standard PID controller was expanded in functionality and truly enriched. Unfortunately in other cases the PID controller was rather diffused with a whole flood of options and parameters that are hardly understood by the users, and seldom used. But there is more to process control then just the PID controller. In order to be able to handle all the control tasks at hand we need a whole range of different control technologies, a full ‘technology set’—the arsenal of process control.

Let us concentrate on some key functions that would make our job easier and faster.

Better monitoring, analysis
First of all, information on the process needs to be further improved. Many systems still lack adequate (the emphasis is on ‘adequate’) display and especially storing mechanisms for our most important information, the operating data. I find it truly absurd that users are forced to buy and use external real time data base systems. They also have their own specific user interfaces which violates a fundamental demand, namely,
that all important functions should be handled in a fully integrated and coherent way.

The trouble with the operating data is often augmented by shortcomings in their presentation. Admittedly, we see higher screen resolution, faster updates, and more parameters that can be updated on one particular display. But as far as one of the most important needs of both operators and control engineers
alike is concerned, namely, truly information-rich dynamic representation of the data over time, in other words the plotting and trending of the process variables, there is still a lot to be desired.

In some cases only a few variables can be trended on one screen. This does not allow us to see all key influencing variables together with the controller’s PV, setpoint and output, which is so important for troubleshooting and tuning. In a few cases it is even very difficult to have the output trended.

In some systems setting up a new trend display is quite cumbersome. In others, trends of the PV, SP and OP are shown on the controller display—really nice, but the plotting scale is always equal to the measurement range and cannot be adjusted at all. The result: Just a bunch of straight lines without any
information content whatsoever. Sometimes, when we look at a trend display but need to go to another
display just for a moment, that trend image is lost and the trending just starts again at the current time point—a real pain during testing or troubleshooting.

What we need are easy to configure and use functions that allow at least six, better nine or 12 variables to be shown. We should be able to easily change the update intervals and ranges which we can associate with a certain controller or display so that they automatically are available when that controller or display is called. This allows us to follow the variables without any data loss when we need to switch over to another display for a moment.

Furthermore, we need better facilities to see (and store) all the different pieces of process information: For the analysis of problems and upsets it is important to follow the development of continuous process variables like temperatures and pressures together with events like alarms, status changes of switches,
controller modes etc.

Finding the needed display is another difficulty in many cases: some systems show huge lists of cryptic display names and only allow accessing them by their exact name. More elaborate linking mechanisms between displays (not just toggling between the current and the previous display) like an associated display feature (best in three or more levels) would help to speed up things considerably Also, linking display names directly and automatically at build time to the unit ID would be another helpful feature as well as a fuzzy search on display (and also tag or block) names.

Control scheme creation
Some systems are based on individual building blocks: every major function like an analogue signal input or output or a ratio control function or the PID is represented as a single entity. This approach provides very high flexibility.

Other systems use a predefined structure for their controllers, so-called ‘tags’ or ‘points’ where input, control, and output processing are combined and the user only needs to specify the needed function in every block. In this case vital information from one part of the structure to another is already automatically passed on.

A typical example is windup protection: when the controller output has reached the high end of its range, then there is no point in allowing setpoint changes that would try to push it further up. In block-based systems it is typically left up to the user to take care of this, which takes extra time and effort. This information exchange is not only needed within one single controller but of course also between all the
controllers in a cascade.

Another example is the automatic stopping of the control and output processing upon detection of an invalid
(‘bad’) measurement and the automatic re-initialisation when the measurement becomes ‘good’ again. Of course, this can be done by the user in block based systems as well, but again, at the expense of extra effort.

All these features should be provided in every system, regardless of the basic design philosophy. And it is truly not too difficult to design a DCS in such a way that macro-structures consisting of blocks that naturally belong together like input–control–output processing are automatically detected and all the necessary information interchange is automatically ensured by the system.

Furthermore, connections between the tags or blocks respectively are often very difficult to trace. A sound and smart ‘cross reference’ utility that presents these connections in a clear, informative way and protects from unintended deletion of referenced tags or blocks or unintended de-activation would be very helpful as a standard feature.

Productivity and performance tools
The key motivation for buying and using an expensive DCS system is (or shall we say, should be) to deliver better control performance. Yet no system comes with a really sound, dynamic performance monitoring system built in that allows users to check if this objective has been met or not. Besides, such a system would tell us which controls do not need any attention and where we should focus our maintenance work.

In many cases we need quantitative knowledge about the process behaviour: For example, the controllability ratio, the ratio between the process deadtime and the dominant time constant, allows us a quick check if the PID is suited for the given process. Secondly, many methods exist that allow us to calculate sound PID tuning on the basis of the process parameters. And thirdly, for certain control techniques like feedforward and model based control we cannot work without having quantitative information such as the process parameters.

Consequently, we need tools for estimating the process parameters from the test results or sound operating data. Of course, there are tools around like GLIDE, MIDSA, TOPAS etc., but again, with respect to inter-connectivity and user interface issues it would be preferential to have this functionality integrated in the system. And, of course, tools for tuning the most widely used controller, the PID, should be a standard feature of any control system.

Finally, to develop functionalities that cannot be done with the standard building blocks and functions, a neatly integrated programming language should be available in any system. The key demand here is to make the communication with the DCS database as easy and as safe as possible and to allow every tag or block to execute such programs as specified by the user.

A lot to be desired
Despite the advances made there is still a lot to be desired and I just have highlighted some key areas. Surprisingly enough, most of the lacking functionality has to do with the ‘core’ DCS task—with the fundamental information and control actions. Besides, improvements in the data handling and representation we ultimately need a true engineering toolbox.

Strangely enough, the ‘old’ Honeywell 4500 / PMX system mentioned in the beginning had more of my wish-list realised than many of the DCS systems on the market. A couple dozen of these systems are still in use and many of the users have been and are still reluctant to change because of that. In any case, with this article I hope to trigger some stimulus for more user input into the vendors which would eventually give us the features needed to better cope with the ever growing demand for better control in shorter time.

The author, Hans H. Eder, may be reached at See also

Contact Details and Archive...

Related Articles...

Additional Information...

Print this page | E-mail this page