of a new package of computer-aided control system ... set of tools and services which allow long-term ..... able through Boeing Computer Services),. CSMP, and- ...
Published in Control and Dynamic Systems: Advances in TheoryandApplications, Volume 12. Academic Press,
New York, NY, 1976, pp. 387-489. W. M. Wonham, ”A Design Procedure for Multivariable Regulators”, Automatic, Volume 12. 1976, pp. 467-478. H . G . Kwatnyand K. C. Kalnitsky, “On Alternative Methodologies for the Design of Robust Multivariable Linear Regulators”, IEEE Transactions on Automatic Controls, VolumeAC-23, 1978. pp. 930-933. R. P. BroadwaterandH. G . Kwatny. ”Application of Nonlinear,Disturbance-Accommodating Controllers in Power Plant Control System Design”. Proceedings-19th IEEE Conference on DecisionandControl.December 1980. Albuquerque. h ” , pp. 107-1 12. R. P.Broadwater, Application of a 0. A.Schakhyand
Mathematical Model-Based Control Structureto theNSS Feedwater Sys-
tem, Internal B&W Report, Department and United the States Army MaLR:80:3168:05:0 l , March 3 l , 1980.terial Command, and Babcock and Wilcox. [ I I] R. P. Broadwater, Nuclear Power While with Babcock and Wilcox, Dr. BroadPlant Feedwater Controller Design, water performed applied research nuclear in Patent Application Case No. 4444 and fossil plant controls. He was involved in the development of the Babcock and Wilcox (B&W/LRC). December 3. 198I . Advanced Control Research Facility in which control studies areperformed using real time, digital simulations of powerplants. In nuclear Robert P. Broadplants. hehasbeeninvolved in developing water received S E E , improvedreactorcoolantpressureandfeedMSEE, PhDEE dewater system control strategies. In fossil grees from Virginia plants, he has worked on the application of Polytechnic Institute identification to improve steam temperature and State University control. Dr. Broadwater currently is with in 1971, 1974, and Tennessee Technological University where he 1976, respectively. isIn teaching power systems the and inis graduate school, he process of developing courses dealing with specializedinelechical powerplantdynamicsandcontrol. Heis also power systems, modem currentlyperformingwork for theTennessee control theory, and Valley Public Power Authority, Tennessee He Valley Authority, and Oak Ridge National nuclear power. has work experience Laboratory. with the General Electric Industrial Controls
Future Directions in Computer-Aided Control System Design Software Development J. Douglas Birdwell Department of Electrical Engineering,The University of Tennessee, Knoxville,TN ABSTRACT: Issues in the development of a new package of computer-aided control system design software are presented. The scope of the project is limited to the organization of existing results into a unified body of software, and the development of a standardized set of tools and services which allow long-term maintenance and growth of the package and support the user community. Issues which influence language selection, graphics requirements, core algorithm selection, model description requirements and software tools, and future hardware expectations are addressed.
Introduction Computer-aided control system design (CACSD)software is designedtoincrease the productivity of engineers and theoreticians and should be implemented in an interactiveenvironmentformaximum effectiveness. User-friendliness is necessary for the new or occasional user, and flexibilitymust be maintained for the sophisticates. Two environments are nec-
essary to provide assistance toboththe enduserand the implementer.Ahighlevel command language environment is needed for engineers who use the package as a design tool i n their applications. Thisenvironmentshouldminimize the programmingoverheadrequiredto use the package. A second, parallel environment is needed in theimplementation language which can provide many of the high-levelservicestotheoreticians involved in the design and testing of new algorithms and methodologies. A design objective of this environment would be the reduction of the programming overhead involved in accessing existing algorithms, data structures, and services. Both environments need advanced graphics and data handling capabilities, and need to maintain hardware independence. Software system description tools aid both the end user andtheimplementer. Input/output support data base management are included here. Common defini’ionsfordatastructures,algebraic manipulationsonsystems,andacore of
basicoperations are necessaryforefficientimplementationofalgorithms.A “macro” capabilityallowsextensionof these tools in particular applications. Fortran,thoughwidelyaccepted,does not provide the flexibility needed in CACSD. The tools need to be available intheimplementationlanguageandthe user interface. Thepackagedesignshouldallow algorithm independence; the algorithms are expectedtochangeoverthepackage lifetimeandshouldnotaffect theremainder of the implementation. A11 implemented algorithms should be reliable; awell-definederror/exceptioninterface should be used to alert the user or other software of problems. The remainder of this paper is a survey of some oftheissueswhichshouldbe considered in order to meet the CACSD software design goals stated above. It is intended that this paper provide a basis for discussionof the proper goals which a CACSD package should address and the issueswhich wouldinfluenceitsdevelopment.
Language Selection The principal languages which can be consideredforaCACSDpackageare Fortran 66 and 77, Ada, Algol 68, and P L / I . In order tomakeanintelligent choice,theimpact oftheselectedlanguage on several issues mustbe assessed. Thefinalselection ofissuesandtheir relativeimportanceareopenquestions; for this discussion, the following list is considered:
I . Packagemaintenance 2. Availability 3. Verifiability 4. Portability in an interactive environment 5 . Documentationstandards 6 . User-friendliness 7. Efficiency 8. Availabledevelopmentandmaintenance tools 9. Error/exceptioninterface IO. Feasibility of an"algorithm-independent" package 11. Upwardmobility 12. Compatibility with other languages A table could be developed which ranks eachlanguage in everyissue,assignsa weightrepresentingtherelativeimportance of each issue, and delivers a figure of merit for each language.I will mention only those aspects which are either very good or quite bad in discussing a given language. I will first consider Fortran. It is very difficult to verify code writtenin Fortran; this is because it is not a strongly typed language; i.e., the user is not forced to define variable types. Structured programming techniques are quite artificial in Fortran 66; this has improved in Fortran77.Unfortunately,aseparateverifier must be used toenforcegoodprogramming practices. Fortran 66 is not a portable language in an interactive environment,mainlybecauseeachmachine usesdifferent a representationand/or storage method for character data. Both Fortranshavetwootherstrikesagainst them. No way of defining a user error/ exception interface exists; by this, I mean the execution environment does nothing morethancheckfor theusualmachine arithmetic violations. Secondly, it is difficult to write a package which is independent of the algorithms; if one wishes to change an algorithm, it is quite likely that many other routines which use that algorithm's implementation must also be changed.Thisisbecausenoprovisions exist for dynamic storage allocation. and
all workspace usedby a subroutine which has variable dimensions must be passed in the parameter list. Fortran 66 has one feature initsfavor;veryefficientcompilersandexecutionenvironmentsexist on most machines. Adawasdesignedas animplementation languageforlargesoftwarepackages. The Ada compiler. along with the Adalanguagesystem [ 1.21. weredesigned to satisfythe problems of software maintenance, verifiability, portability, and documentation. Unfortunately, an Adacompileris notcurrentlyavailable onanymachine.althoughthissituation shouldchangewithin theyearwiththe introduction of the VAX ALS. Questions on Ada's efficiency and the availability ofdevelopmentandmaintenancetools must await an implementation. Two areas in whichAdashould do wellare error/exception handling. where user-definedexceptionscan be processed,and algorithmindependence,sincedynamic storage is available. Algol 68 hasmanyofthefeaturesof Ada and PL/ 1. but will probably be overshadowed by the capabilities of Ada. Algol 68 hastwomajorproblems. Many inconsistencies in the various implementations exist, especially in the input/output routines, making portable interactive implementation of apackagedifficult. Secondly, very few development or maintenancetoolsexistfor Algolprograms. PL/I, likeFortran,has veryefficient executionenvironments.althoughcompilationcan becostly.Unfortunately, completeimplementations of PL/I are and available on onlyafewmachines, PL/I programs are usually not portable. In conclusion, the choice of language appears to be either Fortran or Ada. The disadvantages of Fortran,even in the 1977 standard, are many, but it is widely available. Ada solves many of the problems of large package development and maintenance; it remains to be seen how universal Ada will become.
Graphics Twoquestions must be addressed in the design of the graphics subsystem for a CACSDpackage.First, what arethe low-level graphics requirements for CACSD? Second, are currently available packages and standards adequate? Given a set of low-level graphics routineswhichhaveawell-defined.standardizedinterface,portablesoftwarecan be written to perform the advanced operationsrequired by CACSD. It is critical
that a graphics interface standard which hardware is independent yet flexible enough to accommodate the capabilities of a wide variety ofhardwjare be established.Argumentsexist in thecontrol community that standards cannot be developed;however,suchstandardshave been developed in operating systems for device-independentinput/output.There is no reason to expect graphics hardware to present intractable problems. TheACMGraphicsSpecialInterest Group(SIGGRAPH) hasbeenworking on the standardization problem. and has proposed the ACM/SIGGRAPH Core [3]. Several impleGraphics System mentations of this proposed standard exist. including DIGRAF from the University of Colorado [4] VGM developed by Bell-Northern Research and DI-3000 from Precision Visuals, Inc. Similar deviceindependentgraphicspackagesare DISSPLA and DATAPLOT [ 5 ] . In addition, theAmericanNationalStandards Institute (ANSI) has formed a Technical Committee on Graphics which will eventually result in an ANSI graphics standard. The International Standards Organization (ISO) alsohasaGraphicsSubcommittee [ 6 ] . In viewofthe efforts at standardization. thecontrolscommunity shouldassess theadequacy of theproposed standards in terms of CACSD requirementsandprovide inputintothe appropriate standardization committees. I
Core Algorithms A core set of algorithms must be implemented inanypackagewhichstandardizes basic operations that are common to many higher-level problem solutions. The boundary betweenthe core andthe high-levelroutines is left fuzzy; basic matrix operations should be in the core, whilelinearsystemsimulationroutines wouldprobably notbe included.The largegreyarea is deliberate,since the boundary location depends on how structured an implementation is desired. The concepts described are applicable at any level of specialization. Four software design goals should be addressed during core package development. I) Theerror/exceptionhandling characteristics of all the procedures should be consistent. 11) The visible portion of the implementation should not depend on the algorithm used to solve a specificproblem. 111) Unreliablesoftware, where an error occurs without notification oftheuser or othersoftware, mustbeavoided.andIV) thevisible
control systems magazine
~
interface for a given problem should not depend on the data type. To meettheabovegoals,thecore packageshouldbespecified by first identifying the setof problems which it is tosolve.Examples ofproblemswhich would probably be contained in the core are algebraic Riccati equation and linear equation solutions, numerical integration, eigenvalue/eigenvector analysis, andbasicmatrixoperations.Foreach problem input and output parameters and error/exception information can be identified. Algorithmscanthen be selectedto solve the core problems. For some problems, several appropriate algorithms may exist;thereis no reasonthepackage cannot take advantage of these alternatives.Anexcellentsurvey ofavailable algorithms has beenpublished by Laub [7]. One question is in order concerning well-conditionedproblemsandnumerically stable algorithms. Shouldwe limit a package to thesolutionofonlywellconditioned problems, and can we insist on numerically stable algorithms? I suspectnot,becauseengineersneedtobe able to solve problems which can be illconditioned or forwhichnoalgorithm existswhichisguaranteednumerically stable; however, users can expect a warning to “proceed at their own risk” and notification of errors,condition bounds and other exceptions. At that point, an error/exception interface can be standardized.Sufficient information must be made available to the user or his software through this interface to guarantee the core software’s reliability. Examples ofthe types of information are matrix condition estimates, failure to compute an eigenvalue, and invalid data. Fromthedesignoftheerror/exception interface,theusercanexpectreliable software; furthermore, if the interface is well-designed, when improved algorithms are developed, they can be incorporated in the package without requiring changes in the applications programs. Allowable data types canthen be identified for each problem, standardizing the data formats for the package. The visible portionsofalltheproceduresusedto solve the core problems can be specified at this point, independently ofthe choice of algorithm. In the future,corealgorithms can be changed without modifying the visible attributes of the core package; thus, no modifications will be necessary to software using the core package. In conclusion, the two most important issues in the core package design are the
Februav 1983
standardization of the error/exception interface,andthechoice of problems rather than algorithms for inclusion in the package. The design of the visible portion ofthepackageindependentofthe algorithms,and theinsistenceonsoftware reliability are necessary goals. Lastly, it should be noted that these goals are in conflict with a Fortran implementation; it is difficult to ensure algorithm independence inportableFortran,and theimplementationofastandardized, complete error/exception interface in Fortran is almost unattainable.
Tools A quality package needsnot only stateof-the-art algorithms, but also a variety of softwaretools.Thesetoolsare the differencebetweenasubroutinelibrary and an easily used package. The tools can begrouped in fourareas: I) Software support in the implementation language, 11) data base management, 111) end user support, and IV) package development, maintenance, and verification aids. Softwaresupport in theimplementation language includes model description aids, common definitions for data structures,algebraicmanipulationson systems, and basic matrix operations. Model generation requires 1) the formulation of differential and difference equations, 2) the manipulation and reduction of block diagrams to obtain DE’S,3) the ability to define new subsystems, using a combination of the implementation language and previouslydefinedcomponents, 4) the interconnection of subsystems, which are either user-defined or are from a library, 5) themixingofcontinuous-anddiscrete-timesubsystems, 6) theabilityto use both explicit and implicit models, 7) automaticmodificationofanexisting model,and 8) inputsignaldefinition. Examples of packages with model generation capability include EASY5 (available through Boeing Computer Services), CSMP, and- SPICE. In addition,extensiveresearchhasbeendoneunderthe direction of K. Astrom at the Lund Institute of Technology on structured modeling languages [8]. EASY5containsadvanced modeling aids, but lacks the ability to define new subsystems using predefined subsystems. CSMP is limited to SISO components. SPICE, a circuit analysis program, allows user-defined components. Modeldescriptionaids relyonthe standardizationofdatarepresentation,
algebraic manipulations on systems, such as cascading two systems, and basic matrixoperations.Examples ofimportant datastructures in linearsystemsdesign are matrices, linear systems, linear feedback, and filters. If these structures are standardized,inter-procedurecommunicationsbecomemucheasier. Inalanguage such as Ada,new data types can be defined which users can refer to in their programs.Thisreducestheuser‘sprogrammingoverheadsubstantiallyover what is required in Fortran or PL/1 . Once thedatastructuresaredefined,operations can be defined on those structures, making the work involved in system interconnection more natural and less prone to errors. Databasemanagementincludesthe standardization ofinput/outputsupport routines and the storage format of data on on-line devices. These functions are useful in any application, but are necessary when a high-level command language is defined. Data base management then allows the storage of intermediate results, whose structure may be quite complex, and their subsequent retrieval by a new command process. The command language should parallel the capabilities given a user writing in the implementationlanguage.Thepurpose of the command language is to allow the one-timesolutionofproblemswithout requiring the detail of the implementation language. Both menu-driven and formal languages have been used. A good command language with macro capabilities is needed to allow the user to define repetitive functions as a new command. Menudrivenlanguagesareusuallycumbersome in a macro environment, especially if language constructs such as IF-THENELSE,LOOP,CASE,nesting,andrecursionaredefined.Formallanguages, while less restrictive, are more difficult for the inexperienced user to learn; however, in many operating system environments, they can be made to parallel the operating system command language. In this context, a formal language can appear as an extension to the system-supplied commands, with which the user is already familiar. Good examplesof command languages which are extendibleto a CACSD environment are contained in the TOPS- 10/20, VM/CMS, VAX/VMS, and MULTICS operating systems. The last class of tools contains those used to develop, maintain, and verifythe package and application programs. Two tools are desirable during program development: advanced editors and standards
73
verifiers such as PFORT [ 9 ] . Advanced editors are tailored to a specific language and perform chores such as program formatting, structuring, and variable declaration. Although certainly not necessary, they can increase the probability of producing reliable and readable code. Standards verifiers are necessary to ensurethat code generated by severalprogrammers conforms to thepackagespecifications. ThePFORTverifierforFortran is an excellent example, and ensuresthat portable Fortran is generated. During package verification, dynamic andstaticprogramanalyzersareinvaluable. Dynamic analyzers tracethe execution ofaprogramandcanpinpoint execution bottlenecks. Dramatic increases in package efficiency can result. In addition, a dynamic analyzer can be usedtodesignvalidationtests for the package by ensuring that all portions of the package are tested. Static analyzers giveinformationoninterdependencies between the program segmentsin a package, and can ensure that all segments use the same data definitions. From the output of a static analyzer, when a change must be made, all points within the package whichareaffectedcan be determined. In anylargepackage,maintenance aids for the source, object, and link file databases and updates are required. Inmostlanguages,theseaids must be written by thedeveloper.TheAda languagesystem is supposed to include these aids to support large software development projects. In conclusion, this section has reviewedtherequirementsforsoftware tools in CACSDpackagedevelopment. Fourgroupsoftoolswereestablished, coveringsupport in theimplementation language,databasemanagement,end usersupport,andpackagedevelopment and maintenance support.
and provides no answers. The capabilities of computer hardware are advancing exponentially. Since the design of a new CACSD package will require four to five years, the advances in hardware technologyoverthetimeperiodmust be considered. As one scenario, imagine that a computer equivalent to a VAX can sit on your desk for $10,000 in 1985. Special purpose hardware, particularly array and vectorprocessors,andadvancedgraphics, may also be available. What changes can be made in CACSD packages to take advantage of this capability?
Conclusions Thispaperwaswritten tostimulate discussion and to provide a starting basis for the development of a standard for a newCACSDpackage.Rather thanattempting to specify the content and form of a CACSD package, it presents a collectionofissuesanddecisions which must be addressed in the design of any CACSD package.
This short section only asks questions,
14
lag, New York, 1981. ComputerGraphics, vol. 13,no.
Conversations with the following peopleprovidedavaluableinput tothis paper: M. Athans (MIT), D.Castanon (ALPHATECH),B. Dowdy (TVA), R. Ellis (BCS), A. Erisman (BCS), R. Hammond (BCS), C. Heget (LLNL), A. Laub(USC), T. Reddoch(ORNL),A. Spang (GE), T. Trygar (DOE), Lt. Col. V. Mall (Ada Joint Program Office), and D.Ward(Stanford).Theresponsibility for the contents of this paper rests solely with the author. This work was supported by the Oak RidgeNationalLaboratory under subcontract 7685 projectautharization X40 with the University of Tennessee.
[ 11
Computer, specialissue on Ada, June,
1981. [2] H.Ledgard, Ada. anIntroductionand
3,
Aug.1979. DIGRAF User‘s Guide, TheDIGRAF Group, Univ. of Colorado, Boulder. J . J. Filliben, “DATAPLOT-aninteractive high-level language for graphics, non-linear fitting. dataanalysis, ComputerGraphandmathematics.” ics. vol. 15, no. 3, pp. 199-213.Aug. 1981. H . Z. Kriloff,“Graphicsstandardization,” from MathlStat Sojnvare Newsletter, Boeing Computer Services, vol. 4, no. 3. July-Sept.1979. A . J. Laub. “Survey of computational methods in control theory,” from Electric Power Problems: The MathematicalChallenge. pp. 231-260;A. M. Erisman, K. W. Neves, M. H.
Dwarakanath (eds.), SIAM,Philadelphia.1980. H. Elmqvist. A Structured Model Language for LargeContinuous tems, LundInstituteofTechnology
Sys-
Report LUTFDZ/(TFRT-1015), no. May,1978. B. G . Ryder, ThePFORTVerifier: User’s Guide,CS Tech. Rept. 12, Bell Labs, 1975.
Acknowledgement
References Future Hardware
Ada Reference Manual, Springer-Ver-
J. Douglas Birdrell
was born in Knoxville. TN on December4.1954. He receivedthe B . S . and M . S . degrees in Electrical Engineering i n 1974fromthe University of Tennessee. Knoxville. withhighesthonors. He wasresearch a assistant at the M.I.T. Laboratory for InformationandDecisionSystemsfrom1974to 1975. and a Fannie and John Hertz Foundato 1978. He retionFellowtherefrom1975 ceivedthe Ph.D. degree in ElectricalEngineeringfrom M.I.T. inMay.1978.During theSummer of 1978.heworkedundera traineeship at the Ecole National Superieurde Telecommunications in Paris.France. I n the Fall of 1978 he joined the faculty of the Department of Electrical Engineering at the University of Tennessee. Knoxville. where heis currently an Associate Professor of Electrical Engineering. Dr. Birdlkell is a member ofTau Beta Pi. Eta Kappa Nu. and Sizma X. ~
~
control systems magazine
