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
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 Introduction 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 C. Magnus Rimvall CACSD·“ Open Systems"· Other Desirable Features 112.4 CACSD Block-Diagram Tools Christopher P Jobling Basic Block-Diagram System Representations. Architectures of Block-Diagram Syster pen-Architectures of Block-Diagram University of wales 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 laid down in the middle years of the wwer undreamed of when the classical and modern control theories were desktop machines have computing ne twentieth century t 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 makir 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 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 2000 by CRC Press LLC
© 2000 by CRC Press LLC 112 Computer-Aided Control Systems Design1 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 languages 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-ofmagnitude 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
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 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. Packages a serot ENIAC BM701 1970 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. e 2000 by CRC Press LLC
© 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 packages 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
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 inely used to imple ne control laws developed by control engineers and control 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 eadily increasing cost of application software, estimated at about 80% of the total installation cost of 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 ing"number-crunching. For the implementation of control algorithms, assembly languages are sti 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 omputing. 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 e 2000 by CRC Press LLC
© 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 engineering “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, MODULA, 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 schematic 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
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 graphi 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 f 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 ialized areas The first digital simulation systems were FORTRAN programs. Eventually, special purpose languages emerge 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] w Council and this forms the basis of most simulation languages in use tod, s proposed by the U.SSimulation 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 systen 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 mbining these tools 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 e 2000 by CRC Press LLC
© 2000 by CRC Press LLC known and more expensive vector refresh and vector storage display technology. The prime feature of rasterscan 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 possibilities 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 developed in the mid-1970s. In the U.S., control theory was concentrated in the time domain and made use of
tate-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 algorithn 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 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 In MATLAB, matrices and matrix operations are entered into the computer in the straightforward fashion 112.2 This elegant treatment of linear algebra readily appealed to control scientists who realized that it was equal applicable to the solution of" modern control"problems based on linear state-space models(Fig. 112.3) >【vec,va1]=eig(a) 0.67170.9321-0.8981 val= URE 112.2 Entering and manipulating matrices in MATLAB. In this example, a matrix is defined and its eigenvectors e 2000 by CRC Press LLC
© 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
>>A=[0,1,0:0,0,1;2,3,4]; p⊥eg les 2,414 able all(poles 0) FIGURE 112.3 Using state-space matrices. a simple stability test showing the power of the matrix functions built-in to MATLAB. The Boolean functionall'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 ructures required to do similar tasks in co langua s Returns the lability matrix [b, ab, a 2b s used as: gs ol(a, b) [ma, na] siz mb, nb]= error('Non-square A matrix) Seif ma error(' Unequal number of rows in A and B) gs =b: k =b: Igs, k] 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 However, powerful though the basic"matrix calculator"capabilities of MAT- gs=control(A, B) 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 qs ar stored in a file. When called, such a"script "of commands is 0 it had been typed by the user. MATLABs 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) By creating a set of functions in this way, it is relatively easy to build up a FIGURE 112.5 Using a toolbox"of useful functions for a particular application domain. This is exactly user-defined function as an what happened shortly after the release original MATLAB. Entrepreneurs extension to MATLAB 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 based mainly on the state-space methods in vogue in the U.S., several packages, such as MATRIXx and C, emerged and were a great success. e 2000 by CRC Press LLC
© 2000 by CRC Press LLC However, powerful though the basic “matrix calculator” capabilities of MATLAB 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 CtrlC, 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 controllability of a state-space model. FIGURE 112.5 Using a user-defined function as an extension to MATLAB
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, lATLAB 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 by the addition of data structures and more sophisticated support for package, MATRIXx, has evolved further 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 val 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 The system must be transparent. Small and large systems should be equally treated by the user interface The system must be able to co Ite 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 small-scale data management, e.g., in the form of spreadsncteg taba support of large-scale data management, e.g., in the form of a relational da 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 dapted 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 syster 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 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 e 2000 by CRC Press LLC
© 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 requirement 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
Basic Data objects ystem Types denominato State space Transter function Factored trans Simple analysis results frequency response Time response Frequency response Root-locus Complex analysis results 思思管 Bode diagram Nichos diagram IGURE 112.6 Some of the MATLAB conventions used to support control engineering data types >%P1ant:G(s)=5/s(s"2+2s+1 >>nmmG=5;denG=conv([10],[121]) Controller: Gc(s)=15(8 + 1)/(8+2) K GC 15 c=-1;PGc=·2 > [num Gc, den_Gc]= zp2tf(K_Gc, z_Gc, P Gc)i >> Feedback: H(s)=1/(s +10) > num H= 1: den H= [1 10]1 FIGURE 112.7 Defining a control system in MATLAB. >>881ze(A)=[3,3],ize(B)=[3,1],size(c)=[1,3 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 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 e 2000 by CRC Press LLC
© 2000 by CRC Press LLC the packing and unpacking routines that usually accompany the toolbox code. For example, the packed statespace 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
s(A,B, C,D)T IGURE 112.9 Packing and unpacking syster > IGo A, Go B, Go C, Go D] series(Gc A, Gc_B, Gc_ C, GC D,G A,G B,G C,G D) >>locus(Go A, Go B, Go C, Go D) b)Using non-packed data, the MaTLAB control systems toolbox FIGURE 112. 10 Use of a packed datastructure to simplify interaction. 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 problen 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 function d 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 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 e 2000 by CRC Press LLC
© 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