Ensuring the integrity of process controls involves both hardware issues, software issues, and human issues. Of these, the hardware issues are usually the easiest to assess and the software issues the most difficult.
The hardware issues are addressed by providing various degrees of redundancy, by providing multiple sources of power and/or an uninterruptible power supply, and the like. The manufacturers of process controls provide a variety of configuration options. Where the process is inherently safe and infrequent shutdowns can be tolerated, nonredundant
configurations are acceptable. For more demanding situations, an appropriate requirement might be that no single component failure can render the process-control system inoperable. For the very critical situations, triple-redundant controls with voting logic might be appropriate. The difficulty is assessing what is required for a given process.
Another difficulty is assessing the potential for human errors. If redundancy is accompanied with increased complexity, the resulting increased potential for human errors must be taken into consideration.
Redundant systems require maintenance procedures that can correct problems in one part of the system while the remainder of the system is in full operation. When conducting maintenance in such situations, the consequences of human errors can be rather unpleasant.
The use of programmable systems for process control present some possibilities for failures that do not exist in hard-wired electromechanical implementations. Probably the one of most concern is latent defects or “bugs” in the software, either the software provided by the supplier or the software developed by the user. The source of this problem is very simple. There is no methodology available that can be applied to obtain absolute assurance that a given set of software is completely free of defects. Increased confidence in a set of software is achieved via extensive testing, but no amount of testing results in absolute assurance that there are no defects. This is especially true of real-time systems, where the software can easily be exposed to a sequence of events that was not anticipated. Just because the software performs correctly for each event individually does not mean that it will perform correctly when two (or more) events occur at nearly the same time. This is further complicated by the fact that the defect may not be in the programming; it may be in how the software was designed to respond to the events.
The testing of any collection of software is made more difficult as the complexity of the software increases. Software for process control has progressively become more complex, mainly because the requirements have progressively become more demanding.
To remain competitive in the world market, processes must be operated at higher production rates, within narrower operating ranges, closer to equipment limits, and so on. Demanding applications require sophisticated control strategies, which translate into more complex software. Even with the best efforts of both supplier and user, complex software systems are unlikely to be completely free of defects.