Model Design Modeling Approaches

Transcription

1 Model Design 1 Peter Fritzson Modeling Aroaches Traditional state sace aroach Traditional signal-style block-oriented aroach Object-oriented aroach based on finished library comonent models Object-oriented flat model aroach Object-oriented aroach with design of library model comonents 2 Peter Fritzson 1

2 Modeling Aroach 1 Traditional state t sace aroach 3 Peter Fritzson Traditional State Sace Aroach Basic structuring in terms of subsystems and variables Stating s and formulas Converting the model to state sace form: x ( t) f ( x( t), u( t)) y( t) g( x( t), u( t)) 4 Peter Fritzson 2

3 Difficulties in State Sace Aroach The system decomosition does not corresond to the "natural" hysical system structure Breaking down into subsystems is difficult if the connections are not of inut/outut tye. Two connected state-sace subsystems do not usually give a state-sace system automatically. 5 Peter Fritzson Modeling Aroach 2 Traditional signal-style block-oriented aroach 6 Peter Fritzson 3

4 Physical Modeling Style (e.g Modelica) vs signal flow Block-Oriented Style (e.g. Simulink) Modelica: Physical model easy to understand Block-oriented: Signal-flow model hard to understand for hysical systems Res2 R2 sum3-1 1 Ind 1/L l2 1 s R1=10 R2=100 AC=220 n n sum n C= L=0.1 sinln sum Res1 1/R1 Ca 1/C l1 1 s n n G 7 Peter Fritzson Traditional Block Diagram Modeling Secial case of model comonents: the causality of each interface variable has been fixed to either inut or outut Tyical Block diagram model comonents: x + - y f(x,y) Integrator Adder Multilier Function Branch Point Simulink is a common block diagram tool 8 Peter Fritzson 4

5 Physical Modeling Style (e.g Modelica) vs signal flow Block-Oriented Style (e.g. Simulink) Modelica: Physical model easy to understand Block-oriented: Signal-flow model hard to understand for hysical systems Res2 R2 sum3-1 1 Ind 1/L l2 1 s R1=10 R2=100 AC=220 n n sum n C= L=0.1 sinln sum Res1 1/R1 Ca 1/C l1 1 s n n G 9 Peter Fritzson Examle Block Diagram Models Electric k 1 / k / L i R Control + - e 1/ TI + - K Rotational Mechanics 2 k J1 J 2k2 ω2 1 1/ k2 k θ k 3 τ load + - 1/ J 3 ω 3 θ 3 10 Peter Fritzson 5

6 Proerties of Block Diagram Modeling - The system decomosition toology does not corresond to the "natural" hysical system structure - Hard work of manual conversion of s into signal-flow reresentation - Physical models become hard to understand in signal reresentation - Small model changes (e.g. comute ositions from force instead of force from ositions) requires redesign of whole model + Block diagram modeling works well for control systems since they are signal-oriented rather than "hysical" 11 Peter Fritzson Object-Oriented Oriented Modeling Variants Aroach 3: Object-oriented aroach based on finished library comonent models Aroach 4: Object-oriented flat model aroach Aroach 5: Object-oriented aroach with design of library model comonents 12 Peter Fritzson 6

7 Object-Oriented Oriented Comonent-Based Aroaches in General Define the system briefly What kind of system is it? What does it do? Decomose the system into its most imortant comonents Define communication, i.e., determine interactions Define interfaces, i.e., determine the external orts/connectors Recursively decomose model comonents of high comlexity Formulate new model classes when needed Declare new model classes. Declare ossible base classes for increased reuse and maintainability 13 Peter Fritzson To-Down versus Bottom-u Modeling To Down: Start designing the overall view. Determine what comonents are needed. Bottom-U: Start designing the comonents and try to fit them together later. 14 Peter Fritzson 7

8 Aroach 3: To-Down Object-oriented aroach using library model comonents Decomose into subsystems Sketch communication Design subsystems models by connecting library comonent models Simulate! 15 Peter Fritzson Decomose into Subsystems and Sketch Communication DC-Motor Servo Examle Controller Electrical Circuit Rotational Mechanics The DC-Motor servo subsystems and their connections 16 Peter Fritzson 8

9 Modeling the Controller Subsystem Controller Electrical Circuit Rotational Mechanics feedback1 ste1 - PI PI1 Modeling the controller 17 Peter Fritzson Modeling the Electrical Subsystem Controller Electrical Circuit Rotational Mechanics resistor1 inductor1 signalvoltage1 EMF1 ground1 Modeling the electric circuit 18 Peter Fritzson 9

10 Modeling the Mechanical Subsystem Controller Electrical Circuit Rotational Mechanics inertia1 idealgear1 inertia2 sring1 inertia3 seedsensor1 Modeling the mechanical subsystem including the seed sensor. 19 Peter Fritzson Object-Oriented Oriented Modeling from Scratch Aroach 4: Object-oriented flat model aroach Aroach 5: Object-oriented aroach with design of library model comonents 20 Peter Fritzson 10

11 Examle: OO Modeling of a Tank System source maxlevel level h tank levelsensor out in valve controller The system is naturally decomosed into comonents 21 Peter Fritzson Object-Oriented Oriented Modeling Aroach 4: Object-oriented flat model design 22 Peter Fritzson 11

12 Tank System Model FlatTank No Grahical Structure No comonent structure Just flat set of s Straightforward but less flexible, no grahical structure model FlatTank // Tank related variables and arameters arameter Real flowlevel(unit="m3/s")=0.02; arameter Real area(unit="m2") =1; arameter Real flowgain(unit="m2/s") =0.05; Real h(start=0,unit= unit="m") "Tank level"; Real qinflow(unit="m3/s") "Flow through inut valve"; Real qoutflow(unit="m3/s") "Flow through outut valve"; // Controller related variables and arameters arameter Real K=2 "Gain"; arameter Real T(unit="s")= 10 "Time constant"; arameter Real minv=0, maxv=10; // Limits for flow outut Real ref = 0.25 "Reference level for control"; Real error "Deviation from reference level"; Real outctr "Control signal without limiter"; Real x; "State variable for controller"; assert(minv>=0,"minv must be greater or equal to zero");// der(h) = (qinflow-qoutflow)/area; // Mass balance qinflow = if time>150 then 3*flowLevel else flowlevel; qoutflow = LimitValue(minV,maxV,-flowGain*outCtr); error = ref-h; der(x) = error/t; outctr = K*(error+x); end FlatTank; 23 Peter Fritzson Simulation of FlatTank System Flow increase to flowlevel at time 0 Flow increase to 3*flowLevel at time 150 simulate(flattank, stotime=250) lot(h, stotime=250) time 24 Peter Fritzson 12

13 Object-Oriented Oriented Modeling Aroach 5: Object-oriented aroach with design of library model comonents 25 Peter Fritzson Object Oriented Comonent-Based Aroach Tank System with Three Comonents Liquid source Continuous PI controller Tank TankPI qin qout source tank tsensor cin tactuatort t icontinuous cout model TankPI LiquidSource source(flowlevel=0.02); PIcontinuousController icontinuous(ref=0.25); Tank tank(area=1); connect(source.qout, tank.qin); connect(tank.tactuator, icontinuous.cout); connect(tank.tsensor, icontinuous.cin); end TankPI; 26 Peter Fritzson 13

14 Tank model The central regulating the behavior of the tank is the mass balance (inut flow, outut flow), assuming constant ressure model Tank ReadSignal tsensor "Connector, sensor reading tank level (m)"; ActSignal tactuator "Connector, actuator controlling inut flow"; LiquidFlow qin "Connector, flow (m3/s) through inut valve"; LiquidFlow qout "Connector, flow (m3/s) through outut valve"; arameter Real area(unit="m2") = 0.5; arameter Real flowgain(unit="m2/s") = 0.05; arameter Real minv=0, maxv=10; // Limits for outut valve flow Real h(start=0.0, unit="m") "Tank level"; assert(minv>=0,"minv (, minimum Valve level must be >= 0 ");// der(h) = (qin.lflow-qout.lflow)/area; // Mass balance qout.lflow = LimitValue(minV,maxV,-flowGain*tActuator.act); tsensor.val = h; end Tank; 27 Peter Fritzson Connector Classes and Liquid Source Model for Tank System connector ReadSignal "Reading fluid level" Real val(unit="m"); end ReadSignal; connector ActSignal "Signal to actuator for setting valve osition" Real act; end ActSignal; qin source tsensor cin TankPI tank icontinuous qout tactuator cout connector LiquidFlow "Liquid flow at inlets or outlets" Real lflow(unit="m3/s"); end LiquidFlow; model LiquidSource LiquidFlow qout; arameter flowlevel = 0.02; qout.lflow = if time>150 then 3*flowLevel else flowlevel; end LiquidSource; 28 Peter Fritzson 14

15 Continuous PI Controller for Tank System error = (reference level actual tank level) T is a time constant x is controller state variable K is a gain factor dx error dt T outctr K * ( error x) Integrating s gives Proortional & Integrative (PI) error outctr K *( error dt) T base class for controllers to be defined model PIcontinuousController extends BaseController(K=2,T=10); Real x "State variable of continuous PI controller"; error to be defined in controller base class der(x) = error/t; outctr = K*(error+x); end PIcontinuousController; 29 Peter Fritzson The Base Controller A Partial Model artial model BaseController arameter Real Ts(unit="s")=0.1 "Ts - Time eriod between discrete samles discrete samled"; arameter Real K=2 "Gain"; arameter Real T=10(unit="s") "Time constant - continuous"; ReadSignal cin "Inut sensor level, connector"; ActSignal cout "Control to actuator, connector"; arameter Real ref "Reference level"; Real error "Deviation from reference level"; Real outctr "Outut control signal"; error = ref-cin.val; cout.act = outctr; TankPI end BaseController; qin qout source tank tsensor tactuator error = difference betwen reference level and actual tank level from cin connector cin icontinuous cout 30 Peter Fritzson 15

16 Simulate Comonent-Based Tank System As exected (same s), TankPI gives the same result as the flat model FlatTank simulate(tankpi, stotime=250) lot(h, stotime=250) time 31 Peter Fritzson Flexibility of Comonent-Based Models Exchange of comonents ossible in a comonent-based model Examle: Exchange the PI controller comonent for a PID controller comonent 32 Peter Fritzson 16

17 Tank System with Continuous PID Controller Instead of Continuous PI Controller Liquid source Continuous PID controller Tank TankPID source qin qout tank tsensor tactuator cin idcontinuous cout model TankPID LiquidSource source(flowlevel=0.02); PIDcontinuousController idcontinuous(ref=0.25); Tank tank(area=1); connect(source.qout, tank.qin); connect(tank.tactuator, idcontinuous.cout); connect(tank.tsensor, idcontinuous.cin); end TankPID; 33 Peter Fritzson Continuous PID Controller error = (reference level actual tank level) T is a time constant x, y are controller state variables K is a gain factor dx error dt T d error y T dt outctr K *( error x y ) Integrating s gives Proortional & Integrative & Derivative(PID) error d error outctr K *( error dt T ) T dt base class for controllers to be defined model PIDcontinuousController extends BaseController(K=2,T=10); Real x; // State variable of continuous PID controller Real y; // State variable of continuous PID controller der(x) = error/t; y = T*der(error); outctr = K*(error + x + y); end PIDcontinuousController; 34 Peter Fritzson 17

18 Simulate TankPID and TankPI Systems TankPID with the PID controller gives a slightly different result comared to the TankPI model with the PI controller simulate(comarecontrollers, stotime=250) lot({tankpi.h,tankpid.h}) 0.4 tankpi.h tankpid.h time 35 Peter Fritzson Two Tanks Connected Together Flexibility of comonent-based models allows connecting models together source TanksConnectedPI qin qout qin qout tank1 tank2 tsensor tactuator tsensor tactuator cin icontinuous cout cin icontinuous cout model TanksConnectedPI LiquidSource source(flowlevel=0.02); Tank tank1(area=1), tank2(area=1.3);; PIcontinuousController icontinuous1(ref=0.25), icontinuous2(ref=0.4); connect(source.qout,tank1.qin); connect(tank1.tactuator,icontinuous1.cout); connect(tank1.tsensor,icontinuous1.cin); connect(tank1.qout,tank2.qin); connect(tank2.tactuator,icontinuous2.cout); connect(tank2.tsensor,icontinuous2.cin); end TanksConnectedPI; 36 Peter Fritzson 18

19 Simulating Two Connected Tank Systems Fluid level in tank2 increases after tank1 as it should Note: tank1 has reference level 0.25, and tank2 ref level 0.4 simulate(tanksconnectedpi, stotime=400) lot({tank1.h,tank2.h}) tank1.h tank2.h time 37 Peter Fritzson Exchange: Either PI Continous or PI Discrete Controller artial model BaseController arameter Real Ts(unit = "s") = 0.1 arameter Real K = 2 arameter Real T(unit = "s") = 10 ReadSignal cin ActSignal cout arameter Real ref Real error Real outctr error = ref - cin.val; cout.act = outctr; end BaseController; "Time eriod between discrete samles"; "Gain"; "Time constant"; "Inut sensor level, connector"; "Control to actuator, connector"; "Reference level"; "Deviation from reference level"; "Outut control signal"; model PIDcontinuousController extends BaseController(K = 2, T = 10); Real x; Real y; der(x) = error/t; y = T*der(error); outctr = K*(error + x + y); end PIDcontinuousController; model PIdiscreteController extends BaseController(K = 2, T = 10); discrete Real x; when samle(0, Ts) then x = re(x) + error * Ts / T; outctr = K * (x+error); end when; end PIdiscreteController; 38 Peter Fritzson 19

20 Exercises Relace the PIcontinuous controller by the PIdiscrete controller and simulate. (see also the book, age 461) Create a tank system of 3 connected tanks and simulate. 39 Peter Fritzson Princiles for Designing Interfaces i.e., Connector Classes Should be easy and natural to connect comonents For interfaces to models of hysical comonents it must be hysically ossible to connect those comonents Comonent interfaces to facilitate reuse of existing model comonents in class libraries Identify kind of interaction If there is interaction between two hysical comonents involving energy flow, a combination of one otential and one flow variable in the aroriate domain should be used for the connector class If information or signals are exchanged between comonents, inut/outut signal variables should be used in the connector class Use comosite connector classes if several variables are needed 40 Peter Fritzson 20

21 Simlification of Models When need to simlify models? When arts of the model are too comlex Too time-consuming simulations Numerical instabilities Difficulties in interreting results due to too many low-level model details Simlification aroaches Neglect small effects that are not imortant for the henomena to be modeled Aggregate state variables into fewer variables Aroximate subsystems with very slow dynamics with constants t Aroximate subsystems with very fast dynamics with static relationshis, i.e. not involving time derivatives of those raidly changing state variables 41 Peter Fritzson 21