Email: MagnusRimvall@Hotmail.Com
Unfortunately, few practical problems present themselves as pure simulation problems. For example, it happens often that the set of starting values is not specified at one point in time. Such problems are commonly referred to as boundary value problems as opposed to the initial value problems discussed previously. Boundary value problems are not naturally simulation problems in a puristic sense (although they can be converted to initial value problems by a technique called invariant embedding). A more commonly used technique for this type of problems, however, is the so-called shooting technique. It works as follows:
To elaborate on yet another example, assume that an electrical network is to be simulated. The electrical components of the network have tolerance values associated with them. It is to be determined how the behavior of the network changes as a function of these component tolerances. An algorithm for this problem could be the following:
These examples show that simulation does not live in an isolated world. A scientific or engineering experiment may involve many different simulation runs, and a plenty of other things in between. Unfortunately, the need for enhanced experimentation capabilities is not properly reflected by today's simulation software. Although model representation techniques have become constantly more powerful over the past years, very little was done with respect to enhancing the capabilities of simulation experiment descriptions. Some simulation languages, such as ACSL, offer facilities for model linearization and steady-state finding. Other simulation languages, such as DSL/VS, offer limited facilities for frequency domain analysis, e.g. a means to compute the Fourier spectrum of a simulation trajectory. To our knowledge, there is not a single simulation system currently available that would offer a general-purpose nonlinear programming package for curve fitting, steady-state finding, the solution of boundary value problems, etc. as an integral part of the software, and this is only one among many tools that would be useful to have. Moreover, those few experiment enhancement tools that are currently available are often difficult to use, and are very specialized, that is: limited in applicability.
Whenever such a situation is faced, we, as software engineers, realize that something must be wrong with the data structures offered in the language. Indeed, all refinements in model representation capabilities, such as techniques for proper discontinuity handling, facilities for submodel declarations, etc. led to enhanced programming structures, whereas the available data structures are still much the same as they were in 1967 when the CSSL specifications were first formalized. When we talk about Computer-Aided Design Software as opposed to Simulation Software, it is exactly this enhanced experiment description capability that we have in mind. Simulation is no longer the central part of the investigation, but simply one software module (tool) among many others that can be called at will from within the experiment description software which from now on will be called computer-aided design software. Algorithms for particular purposes will be called computer-aided design techniques, and the programs implementing these algorithms will be called computer-aided design tools. As many of the design tools are application dependent, our discussion will be restricted to one particular application, namely the design of control systems.
Until very recently, the data structure available in Computer-Aided Control System Design (CACSD) software were as poor as those offered in simulation software. However, even the available programming structures in these software tools were pitiable. Users were led through an inflexible question and answer protocol. Once an incorrect specification was entered by mistake, there was no chance to recover from this error. The protocol deviated from the designed path and probably led sooner or later to a complete software crash after which the user had lost all his previously entered data, and was forced to start from scratch.
A true break-through was achieved with the development of Matlab, a matrix manipulation tool. Its one and only data structure is a double precision complex matrix. Matlab offers a consistent and natural set of operators to manipulate these matrices. In Matlab, a matrix is coded as follows:
A = [1,2,3;4,5,6;7,8,9]
or alternatively:
A = [ 1 2 3
4 5 6
7 8 9 ]
Elements in different columns are separated by either comma or space, whereas elements in different rows are separated by either semicolon or carriage return. With matrices being the only available data structure, scalars are obviously included as a special case. Each element of a matrix can by itself again be a matrix. It is, therefore, perfectly legitimate to write:
a = [0*ONES(3,1),EYE(3);[-2 -3 -4 -5]]
where ONES(3,1) stands for a matrix with three rows and one column full of "1"-elements, 0*ONES(3,1) is thus a matrix of same size consisting of "0"-elements only. EYE(3) represents a 3x3 unity matrix which is concatenated to the "0"-matrix from the right, thus making the total structure now a matrix with three rows and four columns. Concatenated from below is the matrix [-2 -3 -4 -5] which has one row and four columns. Thus, the above expression will create the matrix:
A = [ 0 1 0 0
0 0 1 0
0 0 0 1
-2 -3 -4 -5 ]
Suppose it is desired to solve the linear system:
A*x = b
For a non-singular matrix A, it is known that the solution can be obtained as:
x = INV(a)*b
or, somewhat more efficiently:
x = a\b
(b from left divided by a), in which case a Gaussian elimination is performed in place of the computation of the complete inverse. With Matlab, we finally got ourselves a tool that allows us to learn what we always wanted to know about Linear Algebra (such as: what are the EIG(a+2*EYE(a)) where EYE(a) stands for a unity matrix with the same dimensions as a, and EIG(É) computes the eigenvalues of the enclosed expression). In fact, such a tool existed already for some time. It was called APL, and offered much the same features that are advertized in Matlab. However, APL was characterized by a very cryptic syntax. The APL user was forced to learn to think in a fashion similar to the computer that executed the APL program, which is probably why APL never really made it into the world of applications. Cleve Moler, on the other hand, taught the computer to "think" like the human operator.
It is to be noted that Matlab was not designed to solve CACSD problems. Matlab is simply an interactive language for matrix algebra. Nevertheless, this is exactly the type of tool that the control engineer needs for solving his problems. As an example, let us solve a simple LQG (Linear Quadratic Gaussian) regulator design problem. For the linear system:
dx/dt = A*x + B*u
it is desired to compute a linear state feedback such that the performance index (PI) is:
PI = integ( x'*Q*x + u'*R*u ) = min!
where u' denotes the transpose of the vector u. This LQG problem can be solved by means of the following algorithm:
H = [ A -B*INV(R)*B'
-Q -A' ]
V = [ V1
V2 ]
K = -INV(R)*B'*P
where:
P = Re{V2*INV(V1)}
The following Matlab program (file: RICCATI.MTL) may be used to implement this algorithm:
EXEC('contr.mtl')
IF ans <> n, SHOW('System not Controllable'), RETURN, END
[v,d] = EIG([a,-b*(r\b');-q,-a']);
d = DIAG(d); k=0;
FOR j=1:2*n, IF d(j)<0, k = k+1; v(:,k) = v(:,j); END
p = REAL(v(n+1:2*n,1:k)/v(1:n,1:k));
k = -r\b'*p
RETURN
which is a reasonably compound way of specifying this fairly complex algorithm. Yet, contrary to an equivalent APL code, we find this code acceptably readable.
After Matlab had become available, it took amazingly little time until several CACSD experts realized that this was an excellent way to express control problems. Clearly, Matlab was not designed for CACSD problems, and still a lot had to be done to make it truly convenient, but at least a basis had been created. In the sequel, several CACSD programs have evolved: CTRL-C, MATRIXx Impact, PC-Matlab, and Matlab-SC. All of these programs are spiritual children of Matlab.
We want to demonstrate in this Appendix how simulation software designers can learn from the experiences made recently in CACSD program development, and how the CACSD program developers can learn from the experiences gained in simulation software design.
It should be very convenient if a Matlab-like matrix notation could be used within simulation languages for the description of linear systems or linear subsystems. It would indeed be useful if the simulation software could apply to linear (sub-)systems an integration algorithm that is more efficient than the regularly used explicit Runge Kutta, Adams-Bashforth or Gear algorithms, e.g. an implicit Adams-Moulton technique. Linear (sub-)systems could automatically be identified by the compiler through the use of a matrix notation.
On the other hand, it is true that most recent CACSD programs offer only limited simulation capabilities (e.g. applicable to linear systems only), and the simulation technology involved is mostly stone aged. It would be useful indeed if all our knowledge about the simulation of dynamic systems/processes could be integrated into the CACSD software. Since a design usually involves more than just simulation, but certainly simulation among other techniques, it would definitely be beneficial if a flexible interface between a CACSD program and a simulation language could be created such that powerful simulation runs could be made efficiently at arbitrary points in a more complex design study. These are some of the topics that this Appendix tries to address.
It is to be noted that this Appendix discusses purely digital solutions only. Other simulation techniques (such as analog and/or hybrid simulation techniques) were discussed in Chapter 4 of this book. Although we shall not refer to these techniques explicitly any further, computer-aided control system design algorithms can be implemented on hybrid computers very easily. The dynamic process (that is: the model description) will then be programmed on the analog part of the computer, while the experiment description that triggers individual simulation runs will be programmed on the digital part of the computer. The digital CACSD program will look just the same as in the purely digital solution, while the simulation program will look just the same as any other analog simulation program. For these reasons, a further elaboration on these concepts can be spared.
In the next Section, a systematic classification of CACSD techniques will be attempted. We shall discuss what different techniques (algorithms) for computer-aided control system design exist.
In Section A.3, CACSD tools will be classified. This discussion highlights the major differences between several classes of CACSD tools. Both Sections A.2 and A.3 will help to prepare Section A.4, in which a number of currently available CACSD tools will be compared with respect to features (algorithms) offered by these software systems.
After this discussion, the reader may question whether a diversification of tools as can be currently observed is truly justified and desirable, or whether this is merely a sales argument for the various software vendors. For this reason, we will discuss the problem of software standardization vs software diversification in Section A.5.
In Section A.6, we shall show how simulations can intelligently be used within CACSD software. This section will help to throw a bridge across to other Chapters in this book.
Section A.7 finally will give an outlook to our perspective of forthcoming developments in the area of CACSD software design.
Interested in reading the full paper? (49 pages, 3,017,091 bytes, pdf)