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.
A general purpose nonlinear programming package for curve fitting, steady-state finding, and the solution of boundary value problems, for example, is meanwhile being offered in SimuSolve, and has recently been added to the ACSL simulation environment. However, this is only one among many experiment enhancement tools that would be useful to have. One should note tht the current experiment enhancement tools are often difficult to use, and are very specialized and therefore 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 not too long ago, 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.
The original version of 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, the original Matlab was not designed for CACSD problems, and much 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, Matlab-SC, Control.Lab, Pro-Matlab, XMath, and MaTX. All these programs are considered spiritual children of Matlab.
We want to demonstrate in this chapter 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 would be convenient if a Matlab-like matrix notation could be used within simulation languages for the description of linear systems or linear subsystems. The modeling environment Dymola offers such a feature. In Dymola, the user can specify matrices in a convenient Matlab-like syntax. However, due to the horizontal sorting capability of Dymola, matrices are expanded by the Dymola preprocessor before the sorting begins. If, for example, a 2x2 matrix A is used in a model:
y = A*x
with A being:
A = [ 1 2
3 4 ]
meaning that:
y1 = 1*x1 + 2*x2
y2 = 3*x1 + 4*x2
(expanded form), it may turn out that the equations are horizontally sorted by the Dymola preprocessor into the form: <>
x1 = 1*y1 - 2*x2
y2 = 3*y1 - 2*x2
It would be useful if the simulation software could apply to linear (sub)systems an integration algorithm that is more efficient than the regularly used Runge Kutta, Adams-Bashforth or Gear algorithms; for example, a Z transform technique currently employed for linear system simulation in Pro-Matlab. Linear (sub)systems could automatically be identified by the modeling language compiler.
On the other hand, it is useful if all knowledge about the simulation of dynamic systems or processes is integrated into the CACSD software. Because a design usually involves more than merely simulation, it is definitely beneficial if a flexible interface between a CACSD program and a simulation language is created such that powerful simulation runs can be made efficiently at arbitrary points in a more complex design study. Such interfaces have been created for all the major contenders in CACSD software. ACSL programs can be invoked from within CTRL-C and Pro-Matlab. Special simulation systems with graphical front ends have also been developed. System-Build is a nonlinear simulation environment for MATRIXx, Model-C is a similar system for CTRL-C, and SimuLink is the corresponding system for Pro-Matlab. These three simulation environments are based on block diagrams as modeling tools.
These are some of the topics this chapter addresses. Note that this chapter discusses purely digital solutions only. Other simulation techniques (such as analog and/or hybrid simulation techniques) are discussed in Chap. 4. 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) is then programmed on the analog part of the computer, and the experiment description that triggers individual simulation runs is programmed on the digital part of the computer. The digital CACSD program looks similar to the purely digital solution, and the simulation program looks exactly 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 is presented. Different techniques (algorithms) for computer-aided control system design are discussed.
In Sec. 10.3, CACSD tools are classified. This discussion highlights the major differences between several classes of CACSD tools.
Both Secs. 10.2 and 10.3 help to prepare for Sec. 10.4, in which a number of currently available CACSD are compared with respect to features (algorithms) offered by these software systems.
The problem of software standardization vs. software diversification is discussed in Sec. 10.5.
In Sec. 10.6, we show how simulations can intelligently be used within CACSD software. This section helps to create a bridge to other chapters in this book.
Finally, Sec. 10.7 presents our perspective of current and forthcoming developments in the area of CACSD software design.
Interested in reading the full paper? (41 pages, 2,761,528 bytes, pdf)