Rimvall, C.M, Jobling, C.P. “Computer-Aided Control Systems Design” The Electrical Engineering Handbook Ed. Richard C. Dorf Boca Raton: CRC Press LLC, 2000 112 Computer-Aided Control Systems Design 1 112.1 Introduction 112.2 A Brief History of CACSD Technological Developments ? User Interfaces ? CACSD Packages of Note 112.3 The State of the Art in CACSD Consolidation of CACSD ? A critique of Matrix Environments for CACSD ? “Open Systems” ? Other Desirable Features 112.4 CACSD Block-Diagram Tools Basic Block-Diagram System Representations ? Architectures of Block-Diagram Systems ? Open-Architectures of Block-Diagram Editors 112.1 Introduction The use of computers in the design of control systems has a long and fairly distinguished history. It begins before the dawn of the modern information age with the analog computing devices that were used to create tables of ballistic data for artillery and anti-aircraft gunners and continues to the present day in which modern desktop machines have computing power undreamed of when the classical and modern control theories were laid down in the middle years of the twentieth century. Modern computer-aided control system design (CACSD) has been made possible by the synthesis of several key developments in computing. The development and continued dominance of high-level procedural lan- guages such as FORTRAN enabled the development and distribution of standard mathematical software. The emergence of fully interactive operating systems such as UNIX and its user “shells” influenced the development of CACSD packages which have been constructed along similar lines. The ready availability and cheapness of raster-graphic displays has provided the on-screen display of data from control systems analysis, the creation of tools for modeling control systems using familiar block diagrams and have the potential to make order-of- magnitude improvements in the ease-of-use, ease-of-manipulation, and efficiency of the interaction between the control designer, his model, analysis tools, and end-product—software for embedded controllers. The driving force of all these developments is the seemingly continual increase in computing power year-on-year and the result has been to make computers accessible to large numbers of people while at the same time making them easier to use. A control engineer often describes systems through the use of block diagrams. This is not only the traditional graphical representation of a control system, it is also an almost discipline-independent, and thus universally understandable, representation for dynamic systems. The diagrams may also constitute a complete documentation 1 Originally published as “Computer-Aided Control Systems Design”, Chapter 23, pp 429–442, in Levine, W. S. (Ed.), The Control Handbook, CRC Press, 1995. C. Magnus Rimvall F. L. Smith & Co. A/S Christopher P. Jobling University of Wales ? 2000 by CRC Press LLC of the designed system. Block diagrams are self-documenting and, when appropriately annotated, may form complete and consistent specifications of control systems. It is, therefore, not surprising that a number of tools for modeling (control) systems through block diagrams have emerged on the market over the last 5 to 10 years. In addition to serving as a documentation aid, the overall cost and cycle time for developing complex controllers is radically reduced if analysis/simulation code and/or real-time code is automatically generated from the block-diagrams. This eliminates time-consuming manual coding, and avoids the introduction of coding bugs. In this chapter, we explore the state-of-the-art in CACSD. We begin with a brief survey of the tools that have been developed over the years. We then focus on the matrix environments that provide the current standard and attempt to explain why they are important. We also examine modern block-diagram editors, simulation and code generation tools, and finally allow ourselves to speculate on the future. 112.2 A Brief History of CACSD The term computer-aided control system design may be defined as: The use of digital computers as a primary tool during the modeling, identification, analysis, and design phases of control engineering. CACSD tools and packages typically provide well-integrated support for the analysis and design of linear plant and controllers although many modern packages also provide support for the modeling, simulation, and linearization of nonlinear systems and some have the capability of implementing a control law in software. Figure 112.1 (adapted and updated from Rimvall [1987,1988]) illustrates the development of CACSD pack- ages over the last four decades. In order to put events into proper context, other key influencing factors, chiefly hardware and software developments, are also shown. In this section we describe the background to the emergence of CACSD tools in more detail, starting with technological developments and then moving on to user interface aspects. The aim is to understand the current state-of-the-art by examining the historical context in which these tools have been developed. FIGURE 112.1 The historical development of interactive CACSD tools showing the availability of related hardware and software. Some actual products are included to indicate the state-of-the-art. ? 2000 by CRC Press LLC Technological Developments Computing Hardware Since 1953, there has been a phenomenal growth in the capabilities and power of computing hardware. Observers estimate that the power of computing devices (in terms of both execution speed and memory availability) has doubled every second to third year, whereas the size and cost (per computational unit) of the hardware has halved at approximately the same rate. In terms of CACSD, the chief effect of these developments has been to widen the range of applications for computing and at the same time to make computers, and therefore the applications, widely available to practitioners in all branches of the subject. For example control engineers, control theorists, and control implementors all benefit as described below. ? Desk-top machines which are orders of magnitude more powerful than mainframe machines of two decades ago provide the means by which CACSD can be brought to the data analysis, model building, simulation, performance analysis and modification, control law synthesis, and documentation that is the day-to-day work of the control engineer. ? Without powerful computing hardware, many of the complex algorithms developed by control theorists for both analysis and implementation would otherwise be impractical. ? Embedded computer systems, which implement controllers, smart actuators, and smart sensors, are routinely used to implement the control laws developed by control engineers and control theorists. System Software The development of system software, such as operating systems, programming languages and program execution environments, has been slower than that of hardware, but is nonetheless impressive. Less impressive is the steadily increasing cost of application software, estimated at about 80% of the total installation cost of a computing system, which developments in computer science have been largely unable to reduce. We are, in fact, in the midst of a software crisis, dating from about 1968, which is the result of ever increasing improvements in hardware. Such improvements increase the possibilities for software, raise the expectations of users, and therefore raise the stakes in software production faster than improvements in software development technology has been made. High Level Languages The invention of FORTRAN was a major breakthrough in engineering computing. A high-level language, FORTRAN and the compilers that convert it into machine code, allowed engineers to write programs in a language that was sufficiently close to mathematical notation so as to be quite natural. Since its invention, numerous other high-level languages have been created, although FORTRAN continues to dominate engineer- ing “number-crunching”. For the implementation of control algorithms, assembly languages are still popular although high(er) level languages such as C, which is the predominant systems programming language, MOD- ULA, and ADA are gaining acceptance in the market place. Graphical Displays Engineers are, in general, more comfortable with pictures than with text as a means of communicating their ideas. Hence, the wide availability of graphical displays is of prime importance to many areas of engineering computing. Indeed, the development of computer graphics has been the means by which certain control systems design techniques, such as multivariable control systems analysis, have been made practicable. Computer graphics have also been instrumental in providing improvements in human-machine interfaces such as sche- matic systems input and direct manipulation interfaces with windows, icons, pull-down menus, and pop-up dialog boxes. Further improvements in user interfacing techniques such as hypermedia will continue to rely on developments in display technology. For modern CACSD, the most significant development in display technology has been the development of cheap, high-resolution raster graphics displays, although, historically, great strides were made with less well ? 2000 by CRC Press LLC known and more expensive vector refresh and vector storage display technology. The prime feature of raster- scan technology is that an area of the image may be made to appear to move on the screen by the application of simple logical operations. Raster graphics displays are, therefore, ideal for building direct manipulation graphics applications such as block diagram editors, which will be discussed later. They are not so well suited to the direct display and manipulation of vector images, which are a key part of many engineering graphics applications. For example, it is difficult to move part of a vector image such as a bode-plot without destroying the rest of the picture or to display sloping lines that look smooth at low resolutions. However, the dominance of the technology has been a factor in ensuring that the deficiencies in the technology can be overcome by clever software. Quality Numerical Software Following the invention of FORTRAN there was a gradual development of useful general purpose subroutines that could be archived into libraries, distributed, and shared. This lead eventually to the development of standard subroutine libraries such as EIS-PACK [Smith et al., 1977], LINPACK [Dongarra et al., 1979], and LAPACK [Anderson et al., 19789] (for solving eigenvalue problems and sets of linear equations) which have had a direct influence on the development of CACSD. Simulation Languages For many years before the predominance of digital computers, dynamic system behavior was simulated using analog and hybrid computers. Digital simulation began to take over from analog and hybrid simulation during the mid-1960s. Digital simulation programs can be used to model a wider range of nonlinear phenomena more reliably than analog or hybrid computers, at the cost of losing real-time and introducing quantization problems. However, the disadvantages of the technology are more than outweighed by improvements in modeling pos- sibilities and increases in productivity. Digital simulation has superseded analog computation in all but a few specialized areas. The first digital simulation systems were FORTRAN programs. Eventually, special purpose languages emerged which allowed statements written in a form close to state equation notation to be translated into FORTRAN which enabled the engineer to concentrate on the problem description. In 1967, a standard language called CSSL (Continuous Systems Simulation Language) [Augustin et al., 1967] was proposed by the U.S. Simulation Council and this forms the basis of most simulation languages in use today. User Interfaces Over the years, user interaction with computers has become progressively more direct. In the very early days, the user interface was another human being. These “operators” were gradually replaced by operating systems which provided communication first through the medium of punch-card and paper tape, then later by teletype machines, text-based visual display units, and, most recently, by windowed graphical user interfaces. Along with this change, there has been a corresponding change in style for CACSD tools. Batch mode programs were collected into “packages” and provided with question and answer or menued interfaces. These, in turn, have been largely superceded by command driven interfaces and direct-manipulation graphical user interfaces, currently used only for specialized tasks such as block-diagram input, will have a wider role in future CACSD packages. CACSD Packages of Note As the supporting technology has developed, control engineers mainly working in academia have been actively engaged in developing tools to support developments in control theory and in combining these tools into packages. Early pioneering work was carried out in Europe where the emphasis was on frequency response methods for multivariable control systems analysis and design. Some of the first CACSD packages were devel- oped in the mid-1970s. In the U.S., control theory was concentrated in the time domain and made use of ? 2000 by CRC Press LLC state-space models. Several packages of tools for state-space design were created and reached maturity in the late 1970s. These packages were usually written in FORTRAN and made use of a question-and-answer interface. Some of the better packages made use of standard numerical libraries such as EISPACK and LINPACK, but many made use of home-grown algorithms with sometimes dubious numerical properties. One of the earliest standardization efforts was concerned with algorithms and there have been several attempts to create standard CACSD libraries. One of these, SLICOT [van den Boom et al., 1991], is still ongoing. But it has to be admitted that such efforts have had little success in the marketplace. The real break-through came with the development of the “matrix environments”, which are discussed in the next section. Currently, although many research groups continue to develop specialist tools and packages in conventional languages such as FORTRAN, most CACSD tool-makers now use these matrix environments as a high-level language for creating “toolboxes” of tools. 112.3 The State of the Art in CACSD In this section we shall describe the matrix environments that have come to dominate CACSD, that is, the analysis, synthesis, and design of linear controllers for linear plants. We shall then move on to examine some of the requirements of CACSD which are less well served by the current generation of tools. Consolidation of CACSD As can be seen in Fig. 112.1, the 1980s was a decade of consolidation during which CACSD technology matured. Menu driven and Q&A dialogs were superseded by command languages. The matrix environment has become the de facto standard for CACSD. The reasons for this are due to the simplicity of the data structures and the interface model and the flexibility of the package. We illustrate these properties using MATLAB (MATrix LABoratory) [Moler, 1980], the original matrix environment. Originally designed as a teaching program for graduate students, giving interactive access to the linear algebra routines EISPACK and LINPACK, MATLAB was released into the public domain in around 1980. In MATLAB, matrices and matrix operations are entered into the computer in the straightforward fashion illustrated in Fig. 112.2. This elegant treatment of linear algebra readily appealed to control scientists who realized that it was equally applicable to the solution of “modern control” problems based on linear state-space models (Fig. 112.3). FIGURE 112.2 Entering and manipulating matrices in MATLAB. In this example, a matrix is defined and its eigenvectors and eigenvalues are determined. ? 2000 by CRC Press LLC However, powerful though the basic “matrix calculator” capabilities of MAT- LAB are, its real flexibility is due to its support of macro files. A macro file (M-file), in its simplest form, is just a collection of ordinary MATLAB commands which ar stored in a file. When called, such a “script” of commands is executed just as if it had been typed by the user. MATLAB’s real strength lies in its ability to use M- files to create new functions. Such a function is defined in Fig. 112.4. Once defined in this way, the new function can be executed as if it was a part of the language (Fig. 112.5). By creating a set of functions in this way, it is relatively easy to build up a “toolbox” of useful functions for a particular application domain. This is exactly what happened shortly after the release of the original MATLAB. Entrepreneurs quickly realized that if they cleaned up the code, added control oriented data types and functions and some graphics capability, MATLAB could be resold as a proprietary CACSD package. So, based mainly on the state-space methods in vogue in the U.S., several packages, such as MATRIXx and Ctrl- C, emerged and were a great success. FIGURE 112.3 Using state-space matrices. A simple stability test showing the power of the matrix functions built-in to MATLAB. The Boolean function ‘all’ returns the value TRUE (or 1) if all the elements of the argument are non-zero. The argument is itself a vector of Boolean values (that is, those values of the vector of the poles of the A matrix that are negative). By treating matrices as “first-class objects”, MATLAB provides many such opportunities for avoiding loops and other control structures required to do similar tasks in conventional languages. FIGURE 112.4 The extension of MATLAB by means of “macro” or M-files. Here is a routine for determining the control- lability of a state-space model. FIGURE 112.5 Using a user-defined function as an extension to MATLAB. ? 2000 by CRC Press LLC MATLAB itself underwent further development. It was rewritten in C for efficiency and enhanced portability and released as a commercial product in 1985. Like its competitors, the main market was initially the CACSD market, where, supported by two sets of toolbox extensions called the Control and Signal Processing Toolboxes, MATLAB made rapid inroads into academia and industry. A recent development has been the provision of add-on graphical input of system models, in the form of block diagrams, support for “point-and-click” nonlinear simulation, and enhanced graphical functionality. At least one package, MATRIXx, has evolved further by the addition of data structures and more sophisticated support for macro development. The result is the package X-Math described by Floyd et al. [1991]. A Critique of Matrix Environments for CACSD MATLAB and similar matrix environments are far from completely ideal. Rimvall [1987] gave the following requirements for a CACSD environment which are largely still valid today. ?Software packages must support the same entities used by human specialists in the field. ?The basic commands of an interactive environment must be fast yet flexible. ?CACSD packages should support an algorithmic interface. ?The transition from basic use to advanced use must be gradual. ?The system must be transparent. ?Small and large systems should be equally treated by the user interface. ?The system must be able to communicate with the outside world. Matrix environments do not meet all of these requirements. The following sections give a critical review of the state-of-the-art. Support of Control Entities For a control engineer, the entities of interest are ?numerical descriptions of systems (state-space models, transfer functions, etc.) ?symbolic elements for general system equations ?graphical elements for the definition of system topologies ?support of large-scale data management, e.g., in the form of a relational database ?support of small-scale data management, e.g., in the form of spreadsheets ?graphical displays of numerical computations, possibly together with graphical interaction for require- ment specifications, etc. MATLAB was developed by a numerical analyst for numerical analysts. Such people need, and MATLAB provides, only one data structure, the complex matrix. It is a credit to its flexibility that the package can be adapted to a control engineer’s needs by the careful use of convention and toolbox extensions (Fig. 112.6), but the price paid is increased complexity. Take, as a simple example, single-input single-output control systems design. For each element in the system model, i.e., plant, controller, feedback network, the user has to look after four matrices for a state-space model or two polynomials for a transfer function. He cannot simply refer to the “transfer function G”, but must refer instead to the numerator and the denominator polynomials (see Fig. 112.7) that stand for G. These polynomials can, in turn, only be distinguished from row vectors by convention and context. In MATRIXx, this problem was avoided by using packing techniques and a special data-structure so that, for example, the state-space model in Fig. 112.3, would have been stored as shown in Fig. 112.8 and additional data would be stored in the workspace of the program so that the A, B, C, D matrices could be later extracted when needed. Such packing schemes are quite widely used by toolbox writers to overcome the limitations imposed by the two-dimensional matrix. One is usually advised, but not required, to manipulate such structures only through ? 2000 by CRC Press LLC the packing and unpacking routines that usually accompany the toolbox code. For example, the packed state- space model might have a function sstosys to pack the data and systoss to unpack it into separate components as shown in Fig. 112.9. The advantage is that once packed, the state-space model G can be used in processing as if it was the single system object it represents. To see this, compare the code for simulation and analysis of a system given in Fig. 112.10(a) with the MATLAB Control System Toolbox code given in Fig. 112.10(b). However, aside from the problem that packed data structures may be accidently used as ordinary matrices, there is a more severe problem that results from a lack of standardization. There are now a number of toolboxes FIGURE 112.6 Some of the MATLAB conventions used to support control engineering data types. FIGURE 112.7 Defining a control system in MATLAB. FIGURE 112.8 A packed “system matrix”, additional values would have to be included to store the sizes of the relevant elements but these are not shown for clarity. ? 2000 by CRC Press LLC that are used in CACSD, and none of them takes a standard approach to packing data structures. Thus, the data structures used in the Multivariable Control Systems Toolbox are completely incompatible with those used in the Systems Identification Toolbox, which itself is incompatible with the standard Control Systems Toolbox. The consequence is that each toolbox must supply conversion tools and the situation is similar to the problems faced with integrating data from two different packages. There is, therefore, an identified need for matrix environments to provide a wider range of data types, preferably user definable. These would be used in the same way as record datatypes are used in conventional programming systems and would be considerably safer to use since the types expected and returned by functions could be specified in advance and the scope for misuse would be much reduced. In addition, the need to invent new types for each application would be somewhat reduced. This approach has been taken in the matrix environment X-Math and similar features are planned for a future release of MATLAB. Some of the other requirements listed above, such as graphical systems input, graphical display of results, and spreadsheet data manipulation, are covered to a greater or lesser extent by the current generation of matrix environments. The others, namely symbolic data processing and database support, are not but are considered to be outside the scope of this article. Fast Yet Flexible Command Language MATLAB clearly satisfies this criterion as is evidenced by the natural interaction shown in Fig. 112.3. For CACSD use, it is debatable whether the principle still holds, mainly because of the way that the package entities needed for control have to be constructed and managed by the user. Nonetheless, no-one could complain that matrix environments are not flexible: the growing number of new control applications for them provides ample evidence of that. Algorithmic Interface The support of an algorithmic interface is simply a recognition of the fact that no package developer can anticipate the requirements of every user. So, the package must be extensible by provision of user-defined FIGURE 112.9 Packing and unpacking system models. FIGURE 112.10 Use of a packed datastructure to simplify interaction. ? 2000 by CRC Press LLC macros and functions. MATLAB has these, and their provision is clearly important to the users of the package and developers of toolbox extensions. However, there is a limit to the software robustness of the mechanisms that MATLAB provides. MATLAB is an un-typed language, all data structures used in extensions to MATLAB are implemented in terms of collections of matrices and vectors. It is therefore up to the programmer to develop conventions for using these data items such that the algorithms work properly. A strongly typed language, in which the user must specify the nature of each data object before it is used, is a much safer basis on which to provide extensions that are to be used by many other people. Transition From Basic to Advanced Use The user of a CACSD package is faced with two different types of complexity: the complexity of the user interface and the complexity of the underlying theory and algorithms. In both cases extra guidance is needed for novice users. Typically, the designers of CACSD packages do not wish to stand in the way of the expert users, so they provide direct access to the whole package and interfere in the use of the package as little as possible. This creates problems for novice or infrequent users of the package—novices because they are coming to the package without any knowledge of it, infrequent users because they have probably forgotten most of what they learned the last time they used the package. In MATLAB, the user interface is deceptively simple. One can take a short tutorial and learn the basic concepts and underlying principles in perhaps one hour. But what happens when one is finished with the tutorial and wants to do some actual work? The sheer number of commands in the system can be overwhelming. In basic MATLAB there are some two hundred commands, add a few toolboxes and the number quickly increases. The only way to find out how to use a command is to know its name. If you don’t know the name you can list all the commands available, but since each command name is limited to eight characters, there is not necessarily going to be any relationship between command name and command function. Having found a command the next step is to learn how to use it. In a research prototype CACSD package called IMPACT, Rimvall and Bomholt [1985] provided a latent question and answer mode feature which switches from normal command entry to step by step elicitation of parameters when requested by the user. Other ways of overcoming some of these difficulties [Rimvall, 1988] include providing a means of loading toolboxes only when they are needed, thereby reducing the instantaneous “name-space”, and providing operator overloading so that the same named proce- dure in X-Math [Floyd et al., 1991] and enables, for example, the multiplication operator ‘*’ to mean matrix multiplication, series combination of systems, polynomial convolution, or time response evaluation depending on the types of the operands. Transparency This is a fundamental principle of software engineering that simply means that there should be no hidden processing or reliance on side effects on which the package depends for its correct operation. Everything the package does and the package itself should, at all times, be under the complete control of the user. Scalability This simply means that account should always be taken of the limitations of numerical algorithms. The package should warn the user when limits are reached and the algorithms should thereafter ‘degrade gracefully’. It is surprising how many applications have been programmed with artificial limits set on various arrays which is fine so long as the user never presents the package with a problem that its designer never believed would ever be tackled (an inevitable event). Most matrix environments are limited only by the available memory. “Open Systems” The need to transfer data to other systems is simply a recognition that no one package can do all things equally well. In many applications, it makes sense to pass a processing task onto an expert. The ability of a package to be able to exchange data (both import and export) is the main feature of so-called open systems. At the very least it must be possible to save data in a form that can be retrieved by an external program. MATLAB and its ? 2000 by CRC Press LLC cousins provide basic file transfer capabilities, but the ideal CACSD package would have some link to a much more convenient data sharing mechanism such as could be provided by a database. Other Desirable Features ? Form or menu drive input is often more useful than a functional command driven interface for certain type of data entry. A good example is the plotting of results where the selection of options and parameters for axis scaling, tick marks, etc. are more conveniently specified by means of a dialog box than by a series of function calls. Such a facility is provided in X-Math’s graphics. ? Graphical input is useful for defining systems to be analyzed. Today, most of the major packages provide block diagram input, usually tied to nonlinear simulation. What is rarer is graphical input of more application-specific system representations such as circuit diagrams. ? Strong data typing, as already discussed, is useful for toolbox developers since it provides a robust means of developing extra algorithms within the context of the CACSD package. On the other hand, there is a fine balance between the needs of the algorithm developer and the algorithm implementor. The former is probably best served by a type-less environment in which it is easy and quick to try out new ideas (such an environment is often called a rapid-prototyping environment). The latter, who needs to ensure that the algorithms will work properly under all conditions, needs strong typing to ensure that this can be guaran- teed. A similar dichotomy between inventors and implementors can be observed in software engineering. ? Data persistence. Unless explicitly saved, CACSD data is not maintained between sessions. Neither can data easily be shared between users. The evolution of models and results over time cannot be recorded. Hence, CACSD packages need database support. ? Matrix environments only support numerical computation. It is often useful to be able to manipulate a symbolic representation of a control system. Delaying the replacement of symbolic parameters for numerical values for as long as possible can often yield great insight into such properties as stability, sensitivity, and robustness. 112.4 CACSD Block-Diagram Tools As we have discussed in the previous sections, the 1980s was an important decade for control engineering. Apart form new theories, better design methods, and more accurate numerical algorithms, this was the decade when powerful and easy-to-use interactive CACSD tools were put on the average control engineer’s desk. Through the use of interactive and extendible programs, new methods and algorithms could be easily imple- mented and quickly brought to bear on real control engineering problems. Yet despite this tremendous improve- ment in the availability of good control design environments, the total cost and cycle time for a complex control design was still perceived by many groups and companies as being too high. One of the major remaining bottlenecks was the manual conversion of a control design into testable simulation code and, at a later stage, the conversion of the eventual design into the actual embedded real-time controller code. A control engineer often describes a system through the use of block diagrams of different kinds. To bypass the bottleneck between theoretical design and actual real-time implementation, systems which took engineering block diagrams and automatically converted them into simulation and/or real-time code started to emerge in the middle of the 1980s. As an early example, already in 1984 General Electric decided to develop a block- diagram-based tool with automatic code generation capabilities. This program allowed draftspersons to enter control block diagrams and automatically convert the functionality of these diagrams into real-time code. Although it used limited graphics, this GE-Internal “Autocode” program successfully produced code at 50% of the cost of traditionally generated code, primarily due to error reduction of not hand coding. This reduction of costs provided the evidence that automatic translation of block diagrams is both feasible and desirable. However, due to advances in both computer graphics and code-generation techniques, the first tool was obsolete by the late 1980s. In recent years, several commercial block-diagram-based tools have become available. These ? 2000 by CRC Press LLC tools include System Build from Integrated Systems Incorporated, ModelC from Systems Control Technology, the PC-Based XAnalog from Xanalog, Simulab/Simulink from the Mathworks, and BEACON from General Electric. Some of these tools primarily serve as interfaces to analysis packages such as MATRIXx (System-Build), CTRL-C (Model-C), and MATLAB (Simulink). In some cases they can also be used to directly generate a computer language such as FORTRAN, ADA, or C. A summary of an early 1989 evaluation of the suitability of using System Build, CTRL-C, and Grumman’s Protoblock for engine control is given in [Spang et al., 1993]. Basic Block-Diagram System Representations Some basic user requirements fulfilled by most modern block-diagram oriented CACSD packages are 1.A simple-to-use graphical user-interface that can be used with little or no training. The graphical interface is usually based on the Macintosh, MS-Windows, and/or the X-Window System standard. 2.A set of rules for drawing controls-oriented diagrams, sometimes adhering to a standard diagram representations such as IEC-1331 or Petri Nets. 3.An object-based representation of the diagram entities and their graphical behavior. The underlying package must retain a semantical understanding of the diagram so that, for example, pertinent infor- mation such as signal types, dimensions, and ranges are propagated through the diagram, or connecting lines are retained when objects are moved. 4.Hierarchical structure which allows individual blocks to reference either other block diagrams or external modules (e.g., pre-coded system primitives). 5.Efficient internal simulation capabilities and/or real time code generation capabilities including optimi- zation of execution speed and/or memory allocation. As a consequence of the last two points, the block-diagram tools must have an open architecture so that the created modules can be associated with external code in a modular fashion. There are two main reasons for this: ?When the block-diagrams are used to simulate a physical system, the resulting models must frequently be interfaced with already existing submodels (e.g., from various FORTRAN libraries). ?When real-time controllers are implemented, the auto-generated code must be interfaced with operating system code and other “foreign” software. All of today’s block-diagram CACSD tools use hierarchical signal-flow diagrams as their main system repre- sentation. As illustrated in Fig. 112.11, a signal-flow diagram is a directed graph with the nodes representing standard arithmetic, dynamic and logic control blocks such as adders, delays, various filters, nonlinear blocks, and Boolean logic blocks. The connections between the blocks represent “signal” information which is FIGURE 112.11 A signal-flow diagram in the BEACON system. ? 2000 by CRC Press LLC transmitted from one block to another. The connections also indicate the order of execution of the various blocks. Signal flow diagrams are ideal for describing the dynamics of a system or controller. Some CACSD packages also support some alternate system representation better suited for the logic and sequencing portion of a controller. Possible representations include ladder-logic, dynamic truth-tables, flowcharts, Petri-nets, or state-transition diagrams. Figure 112.12 shows a typical control flow diagram or flowchart. The connections in this case represent the order of execution. The triangular blocks are decision blocks while the square blocks are variable assignment blocks written in a PASCAL-like language. Also shown are a multiway branch and a truth table. BEACON requires that the control flow diagrams produce structured code which equivalently means that a diagram can be implemented as a sequence of if-then-else statements without go-to’s. Hierarchies greatly facilitate the drawing and organization of diagrams. They provide appropriate levels of abstraction so that individual diagrams can be understood without clutter from details. Hierarchies simplify individual diagrams, making the resulting code easier to test. One can build up a set of subdiagram libraries which can be linked into possibly several higher level diagrams. Some block-diagram editors also allow the mixing of various diagram types in a hierarchical fashion (e.g., to call a low-level signal-flow diagram imple- menting a control-law scheme from a decision-making flow-chart diagram). The graphical modeling environments cannot be viewed as replacements for the matrix environments described in the previous sections, as most of the block-diagram environments have very limited analytical capabilities (usually only simulation and linearization). However, many of today’s block diagram tools have been developed as companion packages by the same commercial vendors that also sell matrix environments. Through linearization, it thus becomes possible to transform a non-linear block diagram to a linear represen- tation which can then be analyzed and used for design in the matrix environment. Unfortunately, such automatic transformations are only available between tools from the same vendor, cross-translations between arbitrary tools are not possible. Architectures of Block-Diagram Systems To illustrate typical features and capabilities of a block-diagram oriented simulation or code-generation package, examples will be drawn from BEACON, a CACSD environment developed at GE between 1989 and 1995. There FIGURE 112.12 A BEACON control-flow block diagram. ? 2000 by CRC Press LLC are, of course, many other block diagram systems, but being commercial products, the essential features are difficult to describe in detail. That said, another system that is well documented and worthy of study is the BlockEdit tool which was part of ECSTASY, a CACSD package developed in the UK in the late 1980s [Munro and Jobling, 1994]. BEACON has been in production use within GE since the first quarter of 1992. Through the use of BEACON, the company has been able to substantially reduce the overall cost and cycle time for developing complex controllers. The automatic generation of code not only eliminates the time-consuming manual coding, but also avoids the manual introduction of bugs into the code. BEACON allows the user to graphically design a complete real-time controller as a series of hierarchical block diagrams. These diagrams can thereafter be automatically converted into a variety of computer languages for either control analysis, simulation, or real-time computer code, as illustrated in Fig. 112.13. As shown in this figure, the BEACON system consists of three major components: 1.A graphical block-diagram editor with which the engineer designs the system to be simulated/coded [Spang et al., 1993]. Within this editor, the user may also create new graphical icons representing various numerical or logical blocks. 2.A netlist generated from the diagram and containing a full description of that diagram. The netlist format is keyword-oriented, it has a syntax resembling that of a higher-level language such as Pascal or Ada. To allow a variety of code generators and other uses such as the generation of I/O or termination lists or the automatic generation of test cases, all of the information except graphical location contained in the block diagram is written to the ASCII nestlist file. 3.An automatic code generator which translates the block diagrams into simulation and/or real-time computer code [Rimvall et al., 1993]. The BEACON architecture is one of the most open and extendible in the industry, allowing for straightfor- ward extensions to the capability of the system and easy interfacing to other systems. Therefore, the architecture of other block diagram environments is often variants of that of BEACON. Some of the most common differences found in other systems are: ? Built-in simulation capabilities. Many of today’s commercial systems have a non-linear simulation engine directly built into the system, avoiding BEACON’s explicit translation step. Simulation results may then also be directly displayed on or accessed from the original diagram (e.g., in the form of time histories). This allows the user to see immediately the effects of any changes made to the diagram. One drawback of this approach is that these non-compiled approaches all have some kind of threaded-code or inter- pretative model execution, leading to much slower simulations than explicitly compiled simulation models such as those coming out of BEACON. Some systems allow for either of the two approaches. ? The avoidance of an explicit netlist. Many systems have a monolithic architecture with no direct access to the information in a modeled system. This prevents users from directly interfacing the block-diagram editor to other tools or filters (as often performed on a quite ad-hoc basis by the users within GE). ? No code-generation. Some older systems have built-in simulation capabilities only, with no generation of real-time or explicit simulation code. FIGURE 112.13 The BEACON architecture. ? 2000 by CRC Press LLC Open-Architectures of Block-Diagram Editors Flexible block-diagrams have the capability of allowing users to develop or modify the graphical representation of symbols to meet the needs of various applications. In addition, it must be possible to add or modify the semantical meaning of the new or changed graphical symbols for simulation- or code-generation purposes. The Editing of Block-Diagram Symbols In BEACON, all symbols were developed using a Symbol Editor as shown in Figs. 112.14 and 112.15. This graphical editor is similar to most other object-oriented graphical editors, with the additional ability to describe diagram connectivity and the display of changing parameter values on the symbol itself. Each symbol is made up of a variety of separate objects (shapes) that are grouped together. In Fig. 112.14, we see a Symbol Editor session, with the edited Switch symbol in the lower left window. The drawing primitives with its graphical shapes is the one in the middle. The large window to the right is an example of a block attributes window. In this case, it is the connectivity definition attributes for the left edge of the switch block; these attributes are used to define the sides and vertices which allow inputs or outputs, the allowed number of connections, vector dimension, and types. Associated with most BEACON block symbols is a parameter form. These forms are unique for each individual block, allowing the user to define the parameters of the block and the specific function. For example, the integrator allows specification of the type of integration to be implemented as well as rate limits and initial conditions. The forms are constructed during palette design using the Forms Editor shown in Fig. 112.15. To the left of the screen we see the actual parameter form of the Integrator block. In the middle we have the palette from which the primitive form elements may be picked. Each primitive forms object, such as text/value boxes and action buttons, have definable characteristics that will vary from element to element. To the right of Fig. 112.15 we see the characteristics of the data-input box for the parameter “lower limit”. FIGURE 112.14 The BEACON symbol editor. ? 2000 by CRC Press LLC The Functional Description of Symbols The BEACON code generator will process a netlist into FORTRAN, Ada, C, or 68000 code. It accomplishes this by merging the block ordering information, the connectivity information, and the block-specific parameter values found in the netlist with block-specific functional descriptions of each block type. These block descrip- tions are stored separately from the netlist. This process is illustrated in Fig. 112.16. Each block type supported by BEACON (e.g., adder, integrator, switch) will have a single block definition describing the functionality of the block. Whenever a new block symbol is added using the graphical Symbol Editor, a corresponding block definition file must be added to the system too. This block definition is written in “BEACON Block-Definition Language” (BDL), a special-purpose structured language that contains all the necessary elements for describing block connectivity, block parameters, and algorithms, as well as implemen- tational detail such as fixed-point scaling. Code From Signal-Flow Diagrams The code resulting from a signal-flow diagram is a well-structured and yet locally optimized implementation of the diagram. It has the following characteristics: ?Through processing the sorted netlist, each block on the diagram is individually mapped onto the target language. Named blocks, e.g., LIMAXLAG in Fig. 112.11, are preceded by a comment stating that name in the code. FIGURE 112.15 Examples of block parameter forms. FIGURE 112.16 General principle of the workstation-based code generator. ? 2000 by CRC Press LLC ?Each connection on the diagram corresponds to a memory location in the code. To ensure readable code, each labeled connection, e.g., X1PTN in Fig. 112.11, is explicitly declared as a variable in the code. Unlabeled connections are mapped into reusable temporary variables or, in the case of assembler code, temporarily used registers. This ensures a locally optimized and yet fully readable code. ?States and other variables explicitly named on the diagram retain their name in the code. Unnamed states are automatically assigned unique names. ?Each numerical value is directly inserted into the code using the appropriate format of the target language and arithmetic type/precision used. Code From Control-Flow Diagrams Control-flow diagrams are processed in a similar manner to signal-flow diagrams. The main difference is that while a signal flow diagram uses a fixed set of blocks with well-defined semantics (the block interconnections and block parameters being the only variants between two blocks of the same type), the blocks in control-flow diagrams may contain arbitrary expressions, assignment statements, and/or procedure calls (as shown in Fig. 112.12). These BEACON language constructs must be translated into the primitives of each target language. The BEACON graphical editor ensures that control-flow diagrams are well structured, i.e., that the diagram can be mapped into structured code. The automatic translation of large truth-tables into complex structured code is particularly time-saving. Conclusions In this chapter we have reviewed the tools available for the computer-aided design of control systems. The main features of the current state-of-the-art are analysis tools built around a “matrix environment” and modeling, simulation, and code generation tools constructed around the block diagram representation. For the most part, control systems analysis and design is done from a textual interface and modeling, simulation, and code generation rely on a graphical user interface. There are links between the two “environments”, usually provided by some form of linearization. Future CACSD environments will have to give equal emphasis to “control data objects” as they now do for matrices. This is becoming urgent as the number of specialist toolboxes being written for MATLAB and similar packages increases. Only by having a set of commonly approved data-types can the further development of incompatible data formats within a single package be prevented. Rimvall has defined an extended MATLAB- compatible command language to overcome such problems and the issues are discussed in [Rimvall and Wette, 1993]. As graphical user interfaces become more popular on computing devices, the possibilities for interactive manipulation of systems will have to be explored. We expect that graphical tools for control systems analysis and design will become common-place over the next few years and may eventually replace textual interfaces for most users. A final important area for development of CACSD will be driven by the need to embed control systems design into information systems for enterprise integration. To some extent this is already happening with the need for multidisciplinary teams of engineers to work on common problems. The computer-based support of such projects requires facilities for the development and exchange of models, the storage of design data, version control, configuration management, project management, and computer-supported cooperative work. It is likely that CACSD will have to develop into a much more open set of tools supported by databases, networks, and distributed computation. The implications of some of these developments are discussed in [Barker et al., 1993]. Related Topics 100.1 Models?100.2 Dynamic Response?100.3 Frequency Response Methods: Bode Diagram Approach ? 2000 by CRC Press LLC References E. Anderson, Z. Bai, C. Bischof, J. Demmel, J. Dongarra, J. DuCroz, A. Greenbaum, S. Hammarling, A. McKenney, and D. Soresen, “LAPACK: A portable liner algebra library for supercomputers,” technical report, Argonne National Laboratory, 1989. D. Augustin, J. C. Strauss, M. S. Fineberg, B. B. Johnson, R. N. Linebarger, and F. J. Samson, “The SCi continuous system simulation language (CSSL),” Simulation, 9(6), 281–304, 1967. H. A. Barker, M. Chen, P. W. Grant, C. P. Jobling, and P. Townsend, “Open architecture for computer-aided control engineering,” IEEE Control Systems Magazine, 12(3), 17–27, 1993. J. J. Dongarra, J. R. Bunch, C. B. Moler, and G. W. Stewart, “LINPACK users’ guide,” Lecture Notes in Computer Science, 1979. M. A. Floyd, P. J. Dawes, and U. Milletti, “X-Math: a new generation of object-oriented CACSD tools,” in Proceedings European Control Conference, 3, 2232–2237, 1991. C. Moler, “MATLAB—user’s guide,” technical report, Alberquerque, N.M.: University of New Mexico, 1980. N. Munro and C. P. Jobling, “ECSTASY: A control system CAD environment,” in CAD for Control Systems, D. A. Linkens, Ed., New York: Marcel Dekker, pp. 449–467. C. M. Rimvall, “CACSD software and man-machine interfaces of modern control environments,” Transactions of the Institute of Measurement and Control, 9(2), 1987. C. M. Rimvall, “Interactive environments for CACSD software,” in Preprints of 4th IFAC Symp. on Computer Aided Design in Control Systems CADCS ‘88, pp. 17–26, Beijing, PRC, 1988. C. M. Rimvall and L. Bomholt, “A flexible man-machine interface for CACSD applications,” in Proc. 3rd IFAC Symp. on Computer Aided Design in Control and Engineering, Pergamon Press, 1985. C. M. Rimvall, M. Radecki, A. Komar, A. Wadhwa, H. A. Spang III, R. Knopf, and M. Idelchik, “Automatic generation of real-time code using the BEACON CAE environment,” in Proceedings of the 12th IFAC World Congress on Automatic Control, 6, 99–104, 1993. C. M. Rimvall and M. Wette, “Towards standards for CACE command syntax and graphical interfaces,” in Proceedings of the 12th IFAC World Congress on Automatic Control, 8, 87–390, 1993. B. T. Smith, J. M. Boyle, J. J. Dongarra, B. S. Garbow, and Y. Ikebe, “Matrix eigensystem routines—EISPACK guide extension,” Lecture Notes in Computer Science, 51, 1977. H. A. Spang III, C. M. Rimvall, H. A. Sutherland, and W. Dixon, “An evaluation of block diagram CAE tools,” in Proceedings of the 11th IFAC World Congress on Automatic Control, 9, 79–84, 1990. H. A. Spang III, A. Wadhwa, C. M. Rimvall, R. Knopf, M. Radecki, and M. Idelchik, “The BEACON block- diagram environment,” in Proceedings of the 12th IFAC World Congress on Automatic Control, 6, 105–110, 1993. A. van den Boom, A. Brown, F. Dumortier, A. Geurts, S. Hammarling, R. Kool, M. Vanbegin, P. van Dooren, and S. van Huffle, “SLICOT: A subroutine library in control and systems theory,” in Proceedings 5th IFAC Symposium on Computer Aided Design in Control Systems—CADCS’91, pages 1–76, Swansea, UK, 1991. Further Information Keeping up to date with developments in CACSD is not always easy but the proceedings of the triennual IFAC symposium on Computer-Aided Design in Control Systems (CADCS) and the IEEE biennual workshop on CACSD are useful indicators of the latest trends. The proceedings of the last three of these meetings are given below. The other items give useful snapshots of the state-of-the-art at various points in the last 10 years or so. In addition to these sources, the IEEE Control Systems Magazine regularly publishes articles on CACSD and is a good place to look for other information. M. Jamshidi and C. J. Herget, Eds., Computer-Aided Control Systems Engineering, North-Holland, 1985. CADCS, Proceedings of the 5th IFAC Symposium on Computer Aided Design in Control Systems, Swansea, UK: Pergamon Press, 1991. M. Jamshidi, M. Tarokh, and B. Shafai, Computer-Aided Analysis and Design of Control Systems, Englewood Cliffs, N.J.: Prentice-Hall, 1991. CACSD, Proceedings of the IEEE Control Systems Society Symposium on CACSD, Napa, Calif.: IEEE, 1992. ? 2000 by CRC Press LLC M. Jamshidi and C. J. Herget, Eds., Recent Advances in Computer-Aided Control Systems Engineering. Studies in Automation and Control, Amsterdam: Elsevier Science Publishers, 1992. CACSD, Proceedings of the IEEE/IFAC Joint Symposium on Computer-Aided Control System Design, Tucson, Az., Pergamon Press, 1994. D. A. Linkens, Ed., CAD for Control Systems, New York: Marcel Dekker, 1994. CACSD, Proceedings of the IEEE Symposium on Computer-Aided Control System Design, Deerborn: IEEE, 1996. IFAC CACSD, Proceedings of the 1997 IFAC Symposium on Computer-Aided Control System Design, Ghent, Belgium: IFAC, 1997. ? 2000 by CRC Press LLC