Toolbox Environment for Analysis and Design of Multivariable Systems

Copyright © IFAC Advances in Control Education Oulu, Finland, 2003

ELSEVIER

IFAC PUBLICATIONS www.elsevier.comllocatelifac

TOOLBOX ENVIRONMENT FOR ANALYSIS AND DESIGN OF MULTIVARIABLE SYSTEMS Maja Atanasijevie-Kunc, Rihard Karba, Borut Zupancic

Faculty of Electrical Engineering, University of Ljubljana, TriaSka 25, 81-1000 Ljubljana, 8lovenia

Abstract: In the paper some ideas of studying multivariable control design are presented and illustrated through the usage of toolbox environment which should enable inclusion of already existing toolboxes, illustration of some interesting aspects explained by teacher and the possibility of developing, testing and presentation of solutions, prepared by students. Good experiences with graphically oriented toolbox environment usage confirm correct orientation of the discussed software. Copyright

©2003IFAC Keywords: Analysis, Design, Validation, MIMO systems, Education aids

1. INTRODUCTION

and to incorporate them into the same program environment; • motivation aspects should be covered by suitably chosen and defined design problems.

One of the lectures the students can attend in the fifth year of university study of Automatics on the Faculty of Electrical Engineering, University of Ljubljana are the lectures on Multivariable systems. They include also auditorial and laboratory exercises. In the last few years we have gradually introduced some modifications which are now included in lectures and especially exercises and exams. With this new ideas we tried to introduce or only to emphasize the follOwing important goals:

As a result of mentioned goals we have prepared printed materials (Atanasijevic-Kunc, 2001) with description of 15 projects and graphically oriented toolbox environment, realized inside program package Matlab (Matlab, 1999). Each of the mentioned project bases on the realistic model of the multivariable system originating from industry practice or laboratory pilot plants. Student's tasks connected with these projects are to analyse the model and to design controllers using different approaches to meet the prescribed close-loop properties. Finally the evaluation of the solutions should point out the best result regarding all design goals. Tasks connected with the chosen project are solved by a team of two students and are separated into four groups. By solving the first students should repeat some important aspects of system theory in general and of course a special attention is devoted also to multi variable processes which

• exercises should be realized as illustration and an extension of the lectures with the possibility of relative simple and user friendly computer aided support as numerical treatment of multi variable systems is always complex; • student's obligations regarding laboratory work should be to some degree simplified and guided, • but there must also be the possibility which enables them to realize their own solutions 267

are introduced through lectures and partly repeated during auditorial exercises. This part of the project is meant to be treated during laboratory exercises and to be solved by everyone. Solving the second and third group enable to pass the written and oral part of exam if the results are successfully described and presented to auditorium consisted of the professor, laboratory staff and colleagues. It is of course also possible to pass written and oral part of exam in the classical way. In spite of the fact that each project is quite complex and somehow rounded up we wanted to show that research and design work can be continued. This ideas are indicated in the fourth group of project tasks. Design of control systems is always related with a great number of procedures where perhaps the most often used in all design steps are different analytical operations. They are important in the modelling phase, in the phase of choosing the potentially good design algorithms, during design itself and also in the phase of result evaluation, where the solution or even a group of solutions have to be tested and compared. These were the reasons which have motivated us to build a toolbox for analytical purposes (Atanasijevic-Kunc and Karba, 2002) with which we tried to fulfill the following ideas: it should remind and guide the student through important system properties in time and frequency domain; it should support open and close - loop situations; it should be used for single-input/single-output (SISO) as well as for multi variable (MIMO) systems; where possible some degree of parallelism should be established in treatment of SISO and MIMO problems; it should also be possible to estimate the degree of matching of design results with more or less exactly described design goals and so help in choosing potentially the best design result. To enable computer aided environment of mentioned projects in combination with analytical and design operations and demonstration possibilities graphically oriented toolbox environment was designed as is described in the following section.

Fig. 1. Starting window of toolbox environment

Fig. 2. Problem definition window lem definition. Temporary information of problem definition can be displayed in Matlab workspace by pushing the buttons write mode~ write mode and write goals. By pushing for example 5. problem button the window, as shown in Fig. 3 is opened. The user can

2. GRAPHICALLY ORlENTED TOOLBOX ENVIRONMENT

Fig. 3. Definition of the fifth problem in this case generates linearized state - space description of semi batch distillation column (Matko et al., 1992) in Matlab workspace. Corresponding matrices have in this case the following values: A = [ -0.4352 0.4382 0.0172 -0.0194; -0.1229 0.1211 -0.0092 0.0104; -0.1981 0.1931 -0.3431 0.3535; 0.1017 -0.0970 -0.1698 0.1611), B = [ 0.1259 -0.0974; 0.1182 -0.0802; 0.2923 -0.1168; 0.2198 -0.0932]' C = [ 1 0 00; 0 0 1 0), D = [ 0 0; o 0). When this information of model description is defined the user can start for example with system analysis by pushing the corresponding button

Graphically oriented toolbox environment was realized inside program package Matlab and can be started by opening the window as it is shown in Fig. 1 where we can see that each design procedure is meant to be realized in three main steps: problem definition, contoller(s) design and results validation. Pushing the problem definition button opens the window as shown in Fig. 2. Here we have the access to problem definitions of all described projects, further possibilities, and the user can also create his own files with corresponding prob268

which enables the call of one group of analitical functions from mentioned toolbox. The organization of available analitical functions in connection with more or less precisely specified design goals are described in the next section. When the design problem is defined the work can proceed with design itself. Pushing the control design button in starting window (Fig. 1) opens the window as it is illustrated in Fig. 4. Here

and Multivariable Frequency Domain Toolbox (Maciejowski, 1990; Maciejowski, 1989) in the way that several functions have been added, they are organized in graphical windows and can be called also only by pushing the button. In all functions explanation and where possible graphical representation of results is added. The amount of additional explanations can be controlled by the so called communication vector. Mentioned functions can be divided in several different ways. Some of them can be used with SISO systems, some with MIMO and some are suitable for both kind of problems. Regarding different design situations both groups are organized into four levels: Open-loop analysis functions are using only the information of linear system model. They are grouped into general, time and frequency domain properties as illustrated in Fig. 5. They should

Fig. 4. Control design window the buttons are prepared to be connected with the files created by the students when solving the tasks from the chosen project. In this way systematic approach of project solving is indicated while in the same time organized results can be used for documentation and presentation purposes. When the controller and close-loop system are defined the buttons CL analysis (close - loop analysis) and absolute validation become active and again two groups of analitical functions can be used to find out how the specified controller has influenced close - loop properties. Relative validation (Fig. (1)) functions are also the group of analytical functions. They are meant to be used in the cases where several close - loop solutions (at least two) are available and they should help the designer to choose the best s0lution regarding specified design goals. In the starting window also the demonstrations button is prepared. It enables the presentation of all information needed in connection with programe environment as well as with the topics of design itself. It is also important to notice that in all windows bottom buttons enable to end the work with graphical environment, to return to the previous window or to the very beginning.

Fig. 5. Open-loop MIMO analysis give the information of the properties of the process itself and help the user to choose between different design approaches. Closed-loop analysis functions are organized identically however in this case also the information of used controller is needed. Absolute validation functions are used for evaluation of matching desired design goals. In comparison with closed-loop analysis here also design goals have to be specified. Suitable and enough general specification of design goals can of course be very difficult especially in earlier design stages where needed information is not available or in situations where the user can define contradictory design goals. To avoid somehow these problems we have introduced the possibilities with which the user can define the importance of each specified design goal. In this way design goals can be specified either very precise or in a very approximate manner where perhaps all stable results are acceptable (default goals in Fig. 3). The result of absolute validation is in the range between 0 and 1. If the result of absolute validation is 0 design solution is unacceptable as one or more design goals are violated more than allowed. If the result is 1 this means that all design goals are

3. ORGANIZATION OF ANALYTICAL FUNCTIONS The Toolbox for dynamic system analysis consists of a great number of functions which represent an extension and enlargement of the functions available in Matlab, Control System TooIbox (Control System Toolbox, User's Guide, 1998)

269

completely satisfied. IT the result is between 0 and 1 the solution is acceptable, but all design goals are not completely fulfilled. Better are of course solutions which are closer to 1. These results can also be used for some kind of relative validation. But it can occur that several solutions have the same validation result. In this case the next level can be used. Relative validation functions tend to help the user to compare the efficacy of different design solutions and to prepare him to the real situation where also different kind of non-linearities have to be expected. One which is in practice always presented is for example limitation of control signals. Relative validation functions can simultaneously compare up to five design solutions. The validation result is calculated regarding the first solution. Result greater than 1 therefore means that solution is better than the first. Higher validation values mean better or more efficient solutions.

(1 )

where in the first step the so-called rough tuning matrices G 1 and G 2 are defined. They are usually chosen to be the inverse of the system at some desired frequency (Maciejowski, 1989). In the second step the so-called fine tuning scalars 'Y and 8 are used in the same way as in SISO-cases when gains for P and I part are chosen to satisfy some close-loop properties. By choosing the function MV - root locus for P-tuning from the group of frequency domain properties (Fig. 7) it is possible to observe the influence of parameter 'Y to the closed-loop polepositions for the case, when rough tuning matrix of P-part is chosen to be the inverse of the system in steady state. This is for the discussed system

4. SOME ILLUSTRATIVE RESULTS By choosing to inspect the so called general properties (Fig. 6) it is possible for example to find out the values of poles and time constants of the discussed system and the values of transmission zeros which can not be observed directly from transfer function matrix but represent the parallelism to SISO zeros. It is also possible to establish if the process can be statically or/and dynamically decoupled. This information is not important only for further design purposes but represents the structural properties of the system. The values

Fig. 7. Frequency domain properties of MIMO system illustrated in Fig. 8. The system has four poles and two transmission zeros. By increasing parameter 'Y from zero to infinity two of close -loop poles are approaching transmission zeros while the other two are approaching the two zeros at infinity. The idea can be extended to the PI and the whole MIMO-PID structure tuning. Suppose further that two controllers of the following form have been designed:

~

ANALYSIS OF -'\,[ULTII :r1RIA.BLE SYSTEMS ,

GENERAL PROPERTTES

...... -.......--.-.....

~

--

...

- 0.0499 0.0672]

GPJI

= [ -0.0776 0.100s

+~ s

[-0.0150 0.0202] - 0.0233 0.0302 - 0.0899 0.0524]

GpJ2

= [ -0.1899 0.0778

+~ s

Fig. 6. General properties of MIMO system

+ (2)

+

[ - 0.0020 0.0028] - 0.0033 0.0042

(3)

Now the close - loop properties can be inspected using the group of corresponding functions which are, as mentioned, organized very similar to open - loop analysis functions. Parallelism to SISO problems was realized also in time domain for well known quality indicators to step responses known as delay time, rise time, settling time and maximal overshoot, only that all these parameters are now represented by matrices (Fig. 9). In the cases where the results should match some desired design goals the expectations must or should be defined. In our case this is realized in the following manner. First the so called mode is defined (Fig. 3) . This includes the definition of the

of decoupling indexes for example give the information of the degree of the zeros at infinity for each input - output signal pair of MIMO system. These structural properties can be connected also with the poles and transmission zeros which can lead to root - locus representation of MIMO systems in such way that it becomes very similar to SISO problems. The idea can be realized in connection with tuning procedures for MIMO P and PI controllers, which also represent some kind of parallelism to SISO tuning approaches. When using this type of design the controller of the following form is proposed: 270

result of absolute validation is O. When certain design goal is completely fulfilled the result is 1. And when it is inside the allowed tolerance the validation result value is correspondingly smaller. The overall result is calculated by multiplying all partial results. This kind of validation should stimulate to improve poorly satisfied goals while good results should not be pushed too far. Sometimes it is of course difficult to define all these values. In such situations design goals need not to be specified explicitly. It is supposed that stable solution is desired, while all other design goals should be as good as possible and goal matrix is defined as:

\~ Fig. 8. Root-locus of MIMO system

...

cil, lmvc

variable nacin and (if known) the maximal values of control, reference and disturbance signals. By setting nacin = 1 we have chosen the situation where output signals should track corresponding references as good as possible. In the case where nacin = 2 good disturbance rejection should be fulfilled. When nacin = 3 both aspects are of the same importance. Design goals can be specified in time and fre-

=

111111 [ 1 0 0 0 0 0]

T

(4)

where T denotes matrix transpose. Each stable system is in this situation evaluated with 1. This is the case also for both presented results. When relative validation on the set of solutions is performed also limitations on control signals range are taken into account. In such situations the close-loop behavior can be nonlinear if control signals are saturated. This is the reason why all the properties which are defined for linear systems are omitted from relative validation. As all design goals in time domain were defined to be of some interest, by default complexity, settling times and overshoots are proposed for relative validation. The values of the last two can differ regarding absolute validation if closed-loop system properties are nonlinear. With this information the user can also evaluate the difference between theoretical linear and more realistic nonlinear situation. In addition two criteria are proposed. The first should be regarded as the measure of achieved quality as design goal of good matching of outputs with corresponding reference signals is always presented. It is defined as: JI = L J Ireh(t)Yi(t)ldt. On the other hand the measure of demanded control activity can be inspected with: h = L J 1u;(t)ldt. We have to mention that reference signals needed for calculation of J 1 and J 2 are generated automatically in the following manner. First the parameter I:!.T is defined as I:!.T = 4 * t., where t. is the mean settling time of compared linear systems. Then step changes are realized in I:!.T intervals for each of input signals so that transient responses of direct paths and cross-coupling can be observed. The situation is illustrated in Fig. 10 for the first and in Fig. 11 for the second solution. The fist I:!.T can be used for start up in nonlinear situations. Taken into account all presented criteria the results of relative validation are presented in Fig. 12. The first result is regarded as a norma while the validation results of the other represent the measure of improvement regarding the calculated norma. On the basis of relative validation the following

Fig. 9. Time domain properties of close-loop MIMO system quency domain with corresponding matrices. Suppose we have chosen nacin = 1 and the situation where we want to specify design goals only in time domain. In this case the matrix ciljimvc is defined. For chosen situation it consists of six rows. Each row is connected with one of design goals: the first with stability, the second with desired minimal and maximal time constant, the third with acceptable design complexity, the fourth with desired steady-state gain, the fifth with desired settling times and the sixth with desired overshoots. The elements of the first column are 1 if corresponding goal is of some importance or 0 if it is of no importance. In that case it will not influence the validation process. With the subsequent columns the so called importance and prescribed values for each goal are defined. H for example the element ciljimvc(l, 1) = 1 and ciljimvc(l, 2) = 1 this means that the design result is not acceptable if the closed-loop system is not stable. H ciljimvc(2,1) = 1 and ciljimvc(2,2) = 0.8 and ciljimvc(2,3) = 100 desired value of minimal time constant is 100 [sec]. The importance of this goal is 0.8 and the result is still acceptable if it is not violated for more then 20%. In the cases when design goal is violated more than allowed, the 271

5. CONCLUSIONS

can be concluded. Both results are equal regarding complexity and approximately equal regarding control efforts. Due to considerably smaller oscillations and reduced cross couplings the control quality of the second solution is almost two times better. The overall price is obtained by multiplication of partial results and indicate the superiority of the second solution.

O "E1j

0.05

;;;~
On the basis of presented results and our own experiences the follOwing can be concluded: Presented graphical toolbox environment enables user friendly, simple and systematic treatment of multi variable systems in the sense of problem definition and analysis of different design stages. Students steel have all the freedom regarding controller design but some of the starting ideas can also be realized by the use of analitical possibilities. In our opinion the analysis of parallelism and differences between SISO and MIMO systems improves students understanding of control problems. The concept of design goals definition and evaluation is introduced in such a manner that it does not represent any kind of limitation but only stimulates the criticism of definition of what is good and why. It also enables some further development in several directions. Project oriented work was very good accepted by the students as it seems they have more confidence in their knowledge while approximately the same amount of time is needed for exam preparation. In the same time the possibilities which enable further research work are indicated which also can represent a motivation for better studying results. The first experiences with tool box environment usage confirmed correct orientation of the discussed software.

o

-0.05

------ - ------~

.(... _

I", tlr--

i i

~

j

~

------ - -------

-0" 0

1

2

3 .. 1 0~

Fig. 10. Time responses of the first solution used for relative validation

the second solution

0'03~

0.02

i

0.01

;

0

(

I

; -
U

-
o

1

2

3

0.06.-.- .. -. -. ..- . - ....-. .- .. - 0

'i

•

or-0.05 0

il ;d ._ '-' I I \J

'l ,~jlU~1 .----l


-005

..

\

REFERENCES

I

Atanasijevic-Kunc, M. (2001). Multivariable systems, Collection of complex problems (in Slovene language). 2nd ed. , Faculty of Electrical Engineering, University of Ljubljana. At anasijevic-Kunc, M. and R. Karba (2002). Analysis tool box stressing parallelism of SISO and MIMO problems. Preprints of the 15 th World Congress, IFAC, Barcelona, Spain. Control System Toolbox, User's Guide (1998) . The Math Works Inc. Maciejowski, J. M. (1989). Multivariable Feedback Design. Addison - Wesley Publishers Ltd .. Oxford. Maciej owski , J . M. (1990) . Multivariable Frequency Domain Toolbox, User's Guide. Cambridge Control Ltd, and GEC Engineering Research Centre. Matko, D., B. ZupanCic and R. Karba (1992). Simulation and Modelling of Continuous Systems, A Case Study Approach. Prentice Hall Inc., Englewood Cliffs. Matlab (1999) . The Language of Technical Computing, Version 5. The Math Works Inc.

\--....!

_------_._--,.-.

---- ------ ----0" 0

1

2

3

.. , 0'

Fig. 11. Time responses of t he second solution used for relative validation

Fig. 12. Relative validation of two MIMO closeloop systems 272