Control Software Specification and Design: An Overview

Abstract

A1though much remains to be done in control theory, it has already developed a significant body af knowledge, composed af model s and identification and optimization methods. This knowledge is often ve ry sop hi sticated ando when applied 10 relatively rapid and complex in· dustrial operations and design, it may requi re substanti al engineering support. While operations can already be performed by compUlers, design remains largely a human domain where trial and errar, experience and in· tuitian come into play.Currem cont rol system design fo r ind ustrial applica· tions correspo nds essentiall y to stating lhe process requirements, specifying lhe fu nclions to be performed, then implementing them in software. Thi s art icle surveys techniques in lhe field of control software and design, noting particularly the need fo r clear specifications and engineering methods. lt provides the basis for predicting the general direction of improvements in contrai system design allowed by the deve lopments in compute r lech nology a nd artific ial int elligence. Control system design needsA glance at co mputing systems and process con trol applications revea ls a significant reductio n of the hardware cos H o-function rat io, leading to a much broader rangeof appl ications lhan imaginable 20 years ago. This trend is expected to hold duri ng lhe eighties, due to higher scales of integration of electronic componenls. The result in g sophistication of lhe applications and the increased complexity of their control algorithms turn software, which includes system analysis, engineering, programming, and testing, into the most expensive item of a controI system and often a significant part of lhe overall investment in an industrial plant. Unfo nunatel y, one cannot consider software production witho ut thi nking about software errors, which stem from several causes. To start with, the customer who orders a software system may not know precisely what he wants. When discu ssing his ambiguous, incomplete, and sometimes contradictory specifications with the supplier, both customer and supplier may make diverging assumptions, thinking lhat they understand one another. The supplier then proceeds to introduce his own errors through internai communication problems within his staff and through the very nature of computer programrning.The fa ult does not lie entirely with the people involved. The culprits are the traditional means for specification and developrnent. Free-syntax, informal specifications are c1early inadequale to define software and lead to unforeseeable costs, de lays, and often unsatisfactory res ult s. It follows lhat praclical formalisms and software prod uctioo too ls and controls are needed. Some have already been introduced. The existing efforts and their co ntexts rnerit consideration.