SIMULINK c -based tools for creating and simulating interconnected LFR objects J-M. Biannic, C. D¨oll and J-F. Magni Abstract— This paper is a short tutorial on new tools for the LFR Toolbox which have been designed in order to simplify the computation of highly interconnected LFR objects and their simulation. A specific approach, based on a fixed-point algorithm has been implemented to handle high order LFR objects. Simple examples illustrate the efficiency of these new tools.

Keywords : interconnected LFT, LFT modelling under c , LFT simulation. SIMULINK I. INTRODUCTION It is now well established that Linear Fractional Transformations (LFTs) play a key role in both linear and nonlinear control theory. From the linear side, they can be viewed as a powerful generalization of the state-space representation. From the nonlinear side, they provide an elegant unifying framework. For example, quasi Linear-Parameter-Varying (LPV) systems [8], [7] which represent a large class of nonlinear systems are easily rewritten as LFTs. In such cases the ∆-block of the LFT will depend (partly at least) on the states of the nonlinear system. Consequently, over the past decade, there has been a real interest for LFT modelling, which is not always a very simple task. Fortunately, significant progress were achieved in this domain, so that efficient computer-aided LFT modelling techniques are now available. Here, the latest version (v2.0) of Linear Fractional Representation Toolbox (LFRT) from S. Hecker, J-F. Magni and A. Varga [5], [3], [4] (available on-line from [5]) will be used. This toolbox , for use with c is based on the definition of a new class of MATLAB objects named lfr. As a result, LFR objects may now be manipulated as easily as standard transfer functions or statespace representations from the lti class (class of linear time invariant systems). For example, given two LFR objects of compatible sizes, the sum or product of these objects can be obtained very easily by using ’+’ or ’*’ overloaded operators. Moreover, the Toolbox also contains a collection of functions which enable to construct LFR objects from a symbolic description, and then to minimize the size of their ∆-block (which is a difficult problem). Yet, despite all these powerful tools, computing interconnections of LFR objects remains in some cases, a non-trivial and time-consuming task. This is the first reason which c interface [1], motivated the development of this SIMULINK thanks to which such problems are now easily solved by a visual (then faster and safer) approach. Another point is that those LFR objects can now be included in already existing c files. SIMULINK

As a second point, it was observed that the simulation of time-varying parameter dependent LFR objects using c could also be very time-consuming at two SIMULINK distinct levels : c diagram • Firstly, the construction of the SIMULINK itself may take a lot of time, since it involves many feedback loops of possibly different sizes (according to the ∆-block). As a result, the risk of making errors is high. Moreover, in case of minor changes in the definition of the LFR, the diagram is no longer valid. If a reduction algorithm is applied for example, then sizes of ∆ may change and the diagram should be updated accordingly. More embarrassing, if a parameter which was first neglected has now to be added in the LFR object, then the diagram will have to be almost entirely rewritten, • Secondly, once the diagram is completed, the simulation may need a lot of CPU-time because of on-line matrices inversions which are due to algebraic loops. This problem becomes severe when simulating highorder LFR objects which involve for example highly repeated parameters. c interAs is clarified in this paper, the proposed SIMULINK face [1] will provide a solution to the above two problems. II. INTERCONNECTIONS OF LFR OBJECTS Let us consider first the problem of interconnecting LFR objects together in order to obtain a new LFR object with an augmented ∆ block. A. Principle The principle of LFR interconnections which can be viewed as a generalization of the Redheffer product is illustrated by figure 1. Let be given a set of n systems in the LFT format, which then can be defined by the classical input/output relations : yi = Fu (Mi (s), ∆i )ui

(1)

where Mi (s) stands for the linear part of each plant and ∆i gathers (generally in a diagonal or block-diagonal format) all parametric variations or uncertainties or nonlinear elements. Let further introduce a consistent set of interconnection rules on the input/output vector signals: {w, z, {ui , yi }i=1...n } where w and z denote respectively the input and output vectors of the global system. Then, the problem is to compute the global LFT, i.e M (s) and ∆, such that : z = Fu (M (s), ∆)w

(2)

When the interconnection rules are all linear, the above problem (let alone well-posedness issues – see [6] for further details regarding this particular point which should be checked to make sure that the simulation is safe) is easily solved. It boils down indeed to a standard computation of interconnected linear systems, and the global ∆-block is easily obtained as : ∆ = diag (∆1 , ∆2 , . . . , ∆n ) ∆1

w1

As shown on figure 2, this library contains several LFR objects on its left part and standard linear Simulink objects on the right part which should make very easy the construction of diagrams involving both linear and LFR objects.

(3)

∆2

w2

z= y 21 u 11

+ −

u 21

M 1 (s)

u 12

y1

M 2 (s)

u 22

y 22

y 23 y3

u3

M 3 (s)

∆3 ∆1

∆2

∆3

Global LFT

w1

M(s) = F I (M 1 ,M 2,M 3)

w2

Fig. 1.

y

Interconnection of LFR objects

However, as illustrated by figure 1, the set of rules which reads here :  u11 = w1 − y3 , u12 = y23    u21 = w2 , u22 = y1 (4)  u3 = y22   z = y21

Fig. 2.

Construction-oriented LFR Library

Our proposed graphical approach can then be viewed as a simple extension of linmod in order to handle the class of LFR objects. The objective of this function, named slk2lfr, c diagram of interconnected is then to convert a SIMULINK LFR objects – let us call it slk diag.mdl for example – into a global LFR. The routine is then simply invoked as follows :

Interestingly, the ∆ blocks do not explicitly appear in the LFR objects which then can be connected together exactly as standard linear systems. The principle of the function slk2lfr is rather simple and is essentially based on linmod. Consequently, when invoked, c diagram to make our routine starts by editing the SIMULINK it compatible with a linear approach. Briefly speaking, the LFR blocks are simply replaced by static gains, and the linmod function is called to compute the interconnection of static matrices Mi . A static object with numerous inputs and outputs is then returned. Finally, specialized routines of the LFR Toolbox are invoked to convert the static object into a (possibly) dynamic LFR. Elements of the ∆ blocks are re-ordered, and size-reduction is performed. It may happen indeed that two distinct LFR objects in the interconnection have a common component in their respective ∆-block. Here, the new functionality (which enables to recognize the components of ∆ by their symbolic names) of the enhanced LFR object (version v2.0) are very useful.

>> global_LFR = slk2lfr(’slk_diag’);

C. Example

may be rather complex which makes the computation of M (s) a non trivial task. Consequently, it seems here much easier and natural to work with graphical tools such as c environment. A those which are available in the SIMULINK c

basic use of the MATLAB/SIMULINK linmod function for example, enables to compute any interconnection of standard linear systems very easily. The main task consists of drawing the interconnection. B. A graphical approach: description of the main tools

c diagram involves LFR As mentioned above, the SIMULINK c objects which are not available in standard SIMULINK libraries. A new one was then created which can be displayed by the command :

>> LFRbuild;

Let us now consider a simple illustrative example (which is extracted from the help) of the main routine slk2lfr. Two LFR objects sys1 and sys2 are first defined by the following sequence : >> lfrs x1 >> x3=lfr(’x3’,’ltifc’,[3 2],pck(-1,1,1,0),’freq’);

>> sys1=x1*x3; >> sys2=rlfr(2,4,3,2,2);

The first object is a static LFR, with 3 outputs, 2 inputs and the structure of ∆1 is (In denotes the n × n identity matrix) : ∆1 = diag(x1 I3 , x3 ) , x1 ∈ IR , x3 ∈

CI 3×2

The second object is a dynamic LFR, with 2 states, 4 outputs, 3 inputs and the structure of ∆2 is: ∆2 = diag(x1 I2 , x2 I2 ) , x2 ∈ IR

LFR objLFR1

1/s

LFR

A. A standard approach Let be given for example a parameter-dependent dynamic LFR object as follows :    I y = Fu K, diag , ∆(t) u (5) s with :

Consequently, ∆1 and ∆2 have a common variable x1 . Let us now draw the interconnection of figure 3, which in addition to the LFR objects also involves a standard linear system (namely a 3 × 3 integrator here). Such mixed interconnections are perfectly handled by the conversion routine as long as any non-LFR object is linear.

1 w

presentation will focus on the main aspect : the simulation of time-varying parameter-dependent LFRs. Note that some parameters may coincide with states of the system, in which case the simulated system becomes nonlinear.

∆(t) = diag (δ1 (t)In1 , δ2 (t)In2 , δ3 (t)In3 , δ4 (t)In4 )

(6)

and where K is a static matrix. The simulation of such a c environment – can be realized system – in the SIMULINK with the help of the diagram shown on figure 4.

1 z

1/s

objLFR2

2 delta1(t)

3 delta2(t)

K*u

Demux

4

Fig. 3.

delta3(t)

Example of interconnected LFR objects

5 delta4(t) 1

The diagram is simply built by “drag-and-drop” from the library. Then a “double-click” on each object will open a dialog box in which the name of the LFR has to be entered. Finally, slk2lfr is invoked. As expected, a dynamic LFR with 5 states, 4 outputs and 2 inputs is obtained. The global ∆ block has the following structure : ∆ = diag(x1 I5 , x2 I2 , x3 ) Since the proposed example remains rather simple and does not involve many objects, the computation may also be performed directly – using the overloaded feedback function – without too many lines of code : >> >> >> >> >>

lfrs Int; % define an integrator sysInt=append(Int,Int,Int); % 3x3 Int sys2aug=[sys2;sys2(1:2,:)+eye(2,3)]; sysbo=sys2aug*sysInt*sys1; % cascade sysc=feedback(sysbo,eye(2),+1,[1 2]’,[5 6]’);

However, unlike the graphical approach, the above sequence is neither trivial nor intuitive. A more complex and realistic application of the interface can be found in [2]. III. SIMULATION WITH TIME-VARYING PARAMETERS In this section, the second objective – related to simulation c interface is addressed. As is issues – of the SIMULINK further clarified below, the proposed tools were designed to handle various kinds of LFR objects (i.e with mixed ∆ blocks which involve not only time-varying parameters but some nonlinearities as well). But, for more clarity, this

LFR object (implemented as a static gain)

y 1

u

Fig. 4. ment

c environExample of a standard implementation in SIMULINK

Obviously, the construction of the above diagram is not immediate. Moreover, it highly depends on the dimensions of the LFR object at two levels: • number and order of the time-varying parameters δi (t), • repetition of each parameter (sizes of signals) Then, even a minor change in the LFR object will induce time-consuming adaptations of the simulation file. Last, but not least, it is clear from figure 4 that the simulation of LFR objects involve many algebraic loops (implying on-line matrices inversions) which yields computationally demanding simulations. In the following subsections, the above two problems are further discussed and solutions are proposed. B. A library of simulation-oriented blocks c To make easier and faster the construction of SIMULINK diagrams dedicated to the simulation of LFR objects, a specialized library has been designed. As illustrated by figure 5, it contains three objects according to the nature of the ∆block of the LFR: • simLFR-a: ∆ is a square diagonal operator which elements are either LTI or LTV scalar blocks. The c object is Del(t). It related input of the SIMULINK

simply corresponds to a (possibly) time-varying vector as follows : T

Del(t) = [ δ1 (t), ..., δn (t) ] ∈ IR n

•

•

edited via the dialog box of figure 6.

(7)

Note that each parameter in this vector will only appear once, whatever the repetitions of the δi′ s in ∆. Moreover, as detailed below, the order in which the parameters appear in Del(t) is not important, provided that the names affected to the signals are the same as those used in the definition of the LFR object. This fundamental issue, which makes the interface really easy to use, will be further detailed in a tutorial example in subsection III-D. simLFR-b ∆ does not have any specified structure, and may be non square. As is clear on the figure, both the inputs (wN L ) and outputs (zN L ) of the block are left open in that case. They have to be connected by the user c diagram. As suggested by directly in the SIMULINK the names, these signals typically correspond to inputs and outputs of a nonlinear block. But a linear system, representing for example neglected dynamics can be connected as well. simLFR-c This is the mixed-case, where ∆ contains both scalar parameters and nonlinear blocks.

Fig. 6.

In this dialog-box, three parameters have to be fixed. The first one is simply the name of the LFR object (it must belong to the class “lfr” [5]). The third parameter (optional) is the initial state. It will thus be used only for dynamic objects. A very important parameter is the second one, since it will directly affect the way the LFR is implemented. To be more precise, when the dialog-box is closed (by clicking “OK”), a sub-library is called and a sub-block (under mask) is dynamically built. This sub-block is different according to the option which is set by the second parameter : •

•

Fig. 5.

Simulation-oriented LFR Library

Remark: For technical reasons, the above library was not c library file which makes saved in fact as a true SIMULINK more difficult the dynamic edition (via the initialization of the mask) of the blocks even after they have been transferred in a standard mdl-file. Yet, LFRsim can be used exactly in the same way as LFRbuild. Let us now focus on the first object simLFR-a more closely. After this block has been transferred (by drag-andc file, it has to be drop) from LFRsim into a new SIMULINK

More details on simLFR-a: view of the dialog box

•

par = 0 : Standard implementation. In this case, the subblock looks like the one illustrated on figure 7, without the memory block in the feedback loop. This sub-block is clearly equivalent to a compact version of figure 4 (thanks to a particular “vectorization” of the input signal Del(t) – see equation (7)) . But the main point here (in comparison with the diagram of figure 4), is that the implementation is made automatically. par = -1 : Standard implementation with a loop-delay. This implementation is similar as above, but this time (see figure 7) a memory block (one integration-step delay) is used in the feedback-loop. This avoids online matrices inversions (see subsection III-C) which then considerably fasten the simulation. Note that the precision level in this case may not be sufficient in case of very fast varying parameters (which yet rarely happens on realistic applications). par = 1-10 : Implementation of a fixed-point type algorithm. In this case, the parameter (from 1 to 10) indicates the number of iterations of the algorithm. This technique is further detailed in subsection IIIC. With an improved precision level (almost as good as the exact simulation), the simulation performance (regarding CPU time) of this algorithm is similar to the above implementation (based on a memory block).

Memory block used to avoid algebraic loops (when second parameter in dialog box is set to : −1)

∆n zn

wn

memory block

M11

M12

M21

M22

1/s 1

yn

del_vec(t)

Fig. 8. K*u

2 LFR (implemented as a static gain}

(inversion-based) simulation and this approximation. However, if zn+1 = zn in the second equation of 13, then :

y

Fig. 7. More details on simLFR-a: view of a sub-block for standard simulation

C. Fast simulation For the ease of presentation, consider a static1 LFR object with a time-varying ∆-block given by : y(t) = Fu (M, ∆(t))u(t)

Upper LFT with time-varying block

Demux

1

u

un

(8)

and introduce a partition of M (of compatible dimensions with ∆) :   M11 M12 (9) M= M21 M22 By definition, the relation (8) is equivalent to :   −1 y(t) = M22 + M21 ∆(t) (I − M11 ∆(t)) M12 u(t) (10) where it clearly appears that the simulation of the above LFR object (with M11 6= 0) involves the inversion (online) of a time-varying matrix. Then, it is easily understood why the simulation of LFR objects with large ∆ blocks is a quite demanding task. But, consider now an alternative (yet equivalent!) formulation of (10) for which a discrete-time version is here considered (see also figure 8) :   yn = M22 un + M21 wn zn = M12 un + M11 wn (11)  wn = ∆n zn and finally apply – as illustrated on figure 7 – a one-step delay on the signal zn . The equations now read :   yn = M22 un + M21 wn zn = M12 un + M11 wn (12)  wn = ∆n zn−1

so that the simulation – using a fixed-step algorithm – of system (8) with a memory-block in the feedback-loop is equivalent to simulating the following system :  y(t) = M21 .∆(t).zn + M22 .u(t) (13) zn+1 = M11 .∆(t).zn + M12 .u(t) Clearly, abrupt changes in ∆(t) or in the input signal u(t) may result in significant differences between the exact 1 note that the generalization to dynamic LFRs is straightforward by integrating the dynamic operator Is in ∆

zn+1 = zn = (I − M11 ∆(t))−1 M12 .u(t)

(14)

and equation (10) is clearly recovered. A simple solution to enforce (14) is then to iterate on the second equation of (13) for frozen values of ∆(t) and u(t). This yields an efficient fixed-step algorithm which convergence is studied in [6]. In our proposed interface, the number of iterations (per integration step) of the algorithm is directly fixed by the second parameter of the dialog-box of figure 6. From the above discussion, it is clear that setting this parameter to −1 (use of a memory-block) or +1 (iterative procedure, with one integration per step) will yield the same results. Figure 9 shows how the implementation of the algorithm is realized by a cascade of elementary blocks. Each block corresponds to one iteration. The case of two iterations is illustrated here. 1/s

1 del_vec(t)

Del

Del

M21* u zn

2 input

zn1

zn

Demux 1 output

zn1

u

u

zn−>zn1

zn−>zn2 M22* u

3 Del M11* u 4 zn 5 u

2 zn1

M12* u

Fig. 9. More details on simLFR-a: view of a sub-block used for fast simulation

D. Example Let us now consider a short illustrative example which shows that a nonlinear system (given in a quasi-LPV form) can be simulated very easily with the help of the proposed interface. Let be given the following system : (1 + V )2 V˙ = −(1 + δ)V 3 + u (15) 1 + δ8 where the time-dependence has been omitted to alleviate notations. This nonlinear system can be easily rewritten in a quasi-LPV form by introducing a new parameter θ = V : (1 + θ)2 u V˙ = −(1 + δ)θ2 V + 1 + δ8

(16)

The simulation of system (15) can be achieved under c via the following diagram (figure 10) which SIMULINK construction (despite the simplicity of the example) is not immediate :

Del(t)

Sim LFR LTI/LTV

delta

Sine Wave Step V

y

theta

u

y=theta=V simLFR−a

Bus creator block

V^2 V^3

bus dim : 2 signals in bus 1/s

1+delta

delta

theta delta

V

sysLFR with 2 uncertainty blocks : delta 9x9 theta 4x4

1

Sine Wave

(1+V)^2

Fig. 11.

1 1

LFRsim-based implementation

1+delta^8

uv 8

u Step

Fig. 10.

Standard implementation of the proposed example

In this simulation, the control input u(t) and the time-varying parametric uncertainty δ(t) were respectively defined as a step and sinusoidal-type functions. Let us now use the proposed interface. The first step is to define the LFR object corresponding to (16). This is easily achieved by the following sequence : >> >> >> >> >> >> >>

lfrs theta delta ns=1; % number of states a=-(1+delta)*thetaˆ2; b=(1+theta)ˆ2/(1+deltaˆ8); c=1; d=0; M=[a b;c d]; sysLFR=minlfr(abcd2lfr(M,ns));

c diagram on figure 11 is built using Then the SIMULINK the block simLFR-a. Note that the first input Del(t) which here contains two signals (δ(t) and θ(t)) of the simulationoriented LFR object must be generated by a bus-creator block. Moreover, it should be emphasized that the signals in the bus must have similar names as those being used in the definition of the LFR object. In this example the names are delta and theta. These requirements might look a bit constraining at first. But, it does not take much time and then avoids to take care about the order of the parameters. Moreover, the repetition of each parameter is transparent as well. c modelling In this example, to conclude on SIMULINK aspects, let us note that the time spent to define the LFT and then to build the diagram of figure 11 was really smaller than the requested time to build the first one (figure 10). Moreover, using the proposed approach, if changes have to be made in the LFR object, then the simulation still runs without requiring any modification of the diagram, provided that the names of the blocks have not been changed. Time-domain simulations (not shown here for space reason) were finally performed for different values of the

second parameter (see subsection III-C). It appeared that the standard implementation (involving algebraic loops) led to 10 times longer computational time than the fast approach (even with 10 iterations of the fixed-step algorithm). Moreover, the plots are extremely close. IV. CONCLUSION In this paper, a short overview on new tools that provide c and the a simple and efficient interface between SIMULINK LFRT Toolbox was given. These tools have been designed in order to make easier the computation of interconnected LFR objects and their simulation with the help of efficient algorithms. These tools are available on line from [1]. R EFERENCES [1] J-M. Biannic and C. D¨oll. Simulink handling of LFR objects. Free Web publication http://www.cert.fr/dcsd/idco/perso/Biannic/, 2006. [2] J-M. Biannic, A. Marcos, and M. Jeanneau. Nonlinear simplified LFT modelling of an aircraft-on-ground. submitted to IEEE-CCA-CACSD Conference, 2006. [3] S. Hecker and A. Varga. Generalized LFT-based representation of parametric uncertain models. European Journal of Control, 10(4):326– 337, 2004. [4] S. Hecker, A. Varga, and J-F. Magni. Enhanced LFR Toolbox for MATLAB. In IEEE International symposium on computer aided control system design, Taipei, Taiwan, September 2004. [5] J-F. Magni. Linear Fractional Representation Toolbox (version 2.0) for use with Matlab. Free Web publication http://www.cert.fr/dcsd/ idco/perso/Magni/, 2006. [6] J-F. Magni, A. Knauf, and C. D¨oll. Practical implementation of LFTscheduled feedback gains. In In Proc. 6th Asian Control Conference, Bali, Indonesia, July 2006. [7] A. Marcos and G.J. Balas. Development of linear-parameter-varying models for aircraft. Journal of Guidance Control, and Dynamics, 27(2):218–228, March-April 2004. [8] W.J. Rugh and J.S. Shamma. Research on gain scheduling. Automatica, 36(10):1401–1425, 2000.