|
| 1 | +# Clocks and Sampled-Data Systems |
| 2 | +A sampled-data system contains both continuous-time and discrete-time components, such as a continuous-time plant model and a discrete-time control system. ModelingToolkit supports the modeling and simulation of sampled-data systems by means of *clocks*. |
| 3 | + |
| 4 | +A clock can be seen as an *even source*, i.e., when the clock ticks, an even is generated. In response to the event the discrete-time logic is executed, for example, a control signal is computed. For basic modeling of sampled-data systems, the user does not have to interact with clocks explicitly, instead, the modeling is performed using the operators |
| 5 | +- [`Sample`](@ref) |
| 6 | +- [`Hold`](@ref) |
| 7 | +- [`ShiftIndex`](@ref) |
| 8 | + |
| 9 | +When a continuous-time variable `x` is sampled using `xd = Sample(x, dt)`, the result is a discrete-time variable `xd` that is defined and updated whenever the clock ticks. `xd` is *only defined when the clock ticks*, which it does with an interval of `dt`. If `dt` is unspecified, the tick rate of the clock associated with `xd` is inferred from the context in which `xd` appears. Any variable taking part in the same equation as `xd` is inferred to belong to the same *discrete partition* as `xd`, i.e., belonging to the same clock. A system may contain multiple different discrete-time partitions, each with a unique clock. This allows for modeling of multi-rate systems and discrete-time processes located on different computers etc. |
| 10 | + |
| 11 | +To make a discrete-time variable available to the continuous partition, the [`Hold`](@ref) operator is used. `xc = Hold(xd)` creates a continuous-time variable `xc` that is updated whenever the clock associated with `xd` ticks, and holds its value constant between ticks. |
| 12 | + |
| 13 | +The operators [`Sample`](@ref) and [`Hold`](@ref) are thus providing the interface between continuous and discrete partitions. |
| 14 | + |
| 15 | +The [`ShiftIndex`](@ref) operator is used to refer to past and future values of discrete-time variables. The example below illustrates its use, implementing the discrete-time system |
| 16 | +```math |
| 17 | +x(k+1) = 0.5x(k) + u(k) |
| 18 | +y(k) = x(k) |
| 19 | +``` |
| 20 | +```@example clocks |
| 21 | +@variables t x(t) y(t) u(t) |
| 22 | +dt = 0.1 # Sample interval |
| 23 | +clock = Clock(t, dt) # A periodic clock with tick rate dt |
| 24 | +k = ShiftIndex(clock) |
| 25 | +
|
| 26 | +eqs = [ |
| 27 | + x(k+1) ~ 0.5x(k) + u(k), |
| 28 | + y ~ x |
| 29 | +] |
| 30 | +``` |
| 31 | +A few things to note in this basic example: |
| 32 | +- `x` and `u` are automatically inferred to be discrete-time variables, since they appear in an equation with a discrete-time [`ShiftIndex`](@ref) `k`. |
| 33 | +- `y` is also automatically inferred to be a discrete-time-time variable, since it appears in an equation with another discrete-time variable `x`. `x,u,y` all belong to the same discrete-time partition, i.e., they are all updated at the same *instantaneous point in time* at which the clock ticks. |
| 34 | +- The equation `y ~ x` does not use any shift index, this is equivalent to `y(k) ~ x(k)`, i.e., discrete-time variables without shift index are assumed to refer to the variable at the current time step. |
| 35 | +- The equation `x(k+1) ~ 0.5x(k) + u(k)` indicates how `x` is updated, i.e., what the value of `x` will be at the *next* time step. The output `y`, however, is given by the value of `x` at the *current* time step, i.e., `y(k) ~ x(k)`. If this logic was implemented in an imperative programming style, the logic would thus be |
| 36 | + |
| 37 | +```julia |
| 38 | +function discrete_step(x, u) |
| 39 | + y = x # y is assigned the old value of x |
| 40 | + x = 0.5x + u # x is updated to a new value |
| 41 | + return x, y # The state x now refers to x at the next time step, while y refers to x at the current time step |
| 42 | +end |
| 43 | +``` |
| 44 | + |
| 45 | +An alternative and *equivalent* way of writing the same system is |
| 46 | +```@example clocks |
| 47 | +eqs = [ |
| 48 | + x(k) ~ 0.5x(k-1) + u(k-1), |
| 49 | + y(k-1) ~ x(k-1) |
| 50 | +] |
| 51 | +``` |
| 52 | +Here, we have *shifted all indices* by `-1`, resulting in exactly the same difference equations. However, the next system is *not equivalent* to the previous one: |
| 53 | +```@example clocks |
| 54 | +eqs = [ |
| 55 | + x(k) ~ 0.5x(k-1) + u(k-1), |
| 56 | + y ~ x |
| 57 | +] |
| 58 | +``` |
| 59 | +In this last example, `y` refers to the updated `x(k)`, i.e., this system is equivalent to |
| 60 | +``` |
| 61 | +eqs = [ |
| 62 | + x(k+1) ~ 0.5x(k) + u(k), |
| 63 | + y(k+1) ~ x(k+1) |
| 64 | +] |
| 65 | +``` |
| 66 | + |
| 67 | +## Higher-order shifts |
| 68 | +The expression `x(k-1)` refers to the value of `x` at the *previous* clock tick. Similarly, `x(k-2)` refers to the value of `x` at the clock tick before that. In general, `x(k-n)` refers to the value of `x` at the `n`th clock tick before the current one. As an example, the Z-domain transfer function |
| 69 | +```math |
| 70 | +H(z) = \dfrac{b_2 z^2 + b_1 z + b_0}{a_2 z^2 + a_1 z + a_0} |
| 71 | +``` |
| 72 | +may thus be modeled as |
| 73 | +```julia |
| 74 | +@variables t y(t) [description="Output"] u(t) [description="Input"] |
| 75 | +k = ShiftIndex(Clock(t, dt)) |
| 76 | +eqs = [ |
| 77 | + a2*y(k+2) + a1*y(k+1) + a0*y(k) ~ b2*u(k+2) + b1*u(k+1) + b0*u(k) |
| 78 | +] |
| 79 | +``` |
| 80 | +(see also [ModelingToolkitStandardLibrary](https://docs.sciml.ai/ModelingToolkitStandardLibrary/stable/) for a discrete-time transfer-function component.) |
| 81 | + |
| 82 | + |
| 83 | +## Initial conditions |
| 84 | +The initial condition of discrete-time variables is defined using the [`ShiftIndex`](@ref) operator, for example |
| 85 | +```julia |
| 86 | +ODEProblem(model, [x(k) => 1.0], (0.0, 10.0)) |
| 87 | +``` |
| 88 | +If higher-order shifts are present, the corresponding initial conditions must be specified, e.g., the presence of the equation |
| 89 | +```julia |
| 90 | +x(k+1) = x(k) + x(k-1) |
| 91 | +``` |
| 92 | +requires specification of the initial condition for both `x(k)` and `x(k-1)`. |
| 93 | + |
| 94 | +## Multiple clocks |
| 95 | +Multi-rate systems are easy to model using multiple different clocks. The following set of equations is valid, and defines *two different discrete-time partitions*, each with its own clock: |
| 96 | +```julia |
| 97 | +yd1 ~ Sample(t, dt1)(y) |
| 98 | +ud1 ~ kp * (Sample(t, dt1)(r) - yd1) |
| 99 | +yd2 ~ Sample(t, dt2)(y) |
| 100 | +ud2 ~ kp * (Sample(t, dt2)(r) - yd2) |
| 101 | +``` |
| 102 | +`yd1` and `ud1` belong to the same clock which ticks with an interval of `dt1`, while `yd2` and `ud2` belong to a different clock which ticks with an interval of `dt2`. The two clocks are *not synchronized*, i.e., they are not *guaranteed* to tick at the same point in time, even if one tick interval is a rational multiple of the other. Mechanisms for synchronization of clocks are not yet implemented. |
| 103 | + |
| 104 | +## Accessing discrete-time variables in the solution |
| 105 | + |
| 106 | + |
| 107 | +## A complete example |
| 108 | +Below, we model a simple continuous first-order system called `plant` that is controlled using a discrete-time controller `controller`. The reference signal is filtered using a discrete-time filter `filt` before being fed to the controller. |
| 109 | + |
| 110 | +```@example clocks |
| 111 | +using ModelingToolkit, Plots, OrdinaryDiffEq |
| 112 | +dt = 0.5 # Sample interval |
| 113 | +@variables t r(t) |
| 114 | +clock = Clock(t, dt) |
| 115 | +k = ShiftIndex(clock) |
| 116 | +
|
| 117 | +function plant(; name) |
| 118 | + @variables x(t)=1 u(t)=0 y(t)=0 |
| 119 | + D = Differential(t) |
| 120 | + eqs = [D(x) ~ -x + u |
| 121 | + y ~ x] |
| 122 | + ODESystem(eqs, t; name = name) |
| 123 | +end |
| 124 | +
|
| 125 | +function filt(; name) # Reference filter |
| 126 | + @variables x(t)=0 u(t)=0 y(t)=0 |
| 127 | + a = 1 / exp(dt) |
| 128 | + eqs = [x(k + 1) ~ a * x + (1 - a) * u(k) |
| 129 | + y ~ x] |
| 130 | + ODESystem(eqs, t, name = name) |
| 131 | +end |
| 132 | +
|
| 133 | +function controller(kp; name) |
| 134 | + @variables y(t)=0 r(t)=0 ud(t)=0 yd(t)=0 |
| 135 | + @parameters kp = kp |
| 136 | + eqs = [yd ~ Sample(y) |
| 137 | + ud ~ kp * (r - yd)] |
| 138 | + ODESystem(eqs, t; name = name) |
| 139 | +end |
| 140 | +
|
| 141 | +@named f = filt() |
| 142 | +@named c = controller(1) |
| 143 | +@named p = plant() |
| 144 | +
|
| 145 | +connections = [ |
| 146 | + r ~ sin(t) # reference signal |
| 147 | + f.u ~ r # reference to filter input |
| 148 | + f.y ~ c.r # filtered reference to controller reference |
| 149 | + Hold(c.ud) ~ p.u # controller output to plant input (zero-order-hold) |
| 150 | + p.y ~ c.y] # plant output to controller feedback |
| 151 | +
|
| 152 | +@named cl = ODESystem(connections, t, systems = [f, c, p]) |
| 153 | +``` |
0 commit comments