How can a Simulink State Space block state be periodically reset?

In Simulink, can a State Space block's states be periodically reset, ie not just set on startup?

If not, what alternative is there to accomplish the same thing?

I'm looking to periodically (every T sec) reset the states of a State Space block (say, called "R" for reset), and reset them to a set of passed parameters (states); ie not static constants from the workspace that only act on sim initialization.

These passed reset-value states might come from another continuously-run State Space block (say, the block is "C" for continuous, and its states are the "Good" states), as one example...

At each n*T tick i'd look to update the states of R to the Good states, so that R somewhat matches C as time goes on. Yes, these updates could lead to discontinuous behavior from R, but that's okay.

The question is, how can I periodically update R's states?

[Sam Chak]

Hi @John

I want to make sure I understand the 'reset' problem correctly. Are you looking to update the matrices in the state-space periodically, as shown? If that's the case, the Varying State Space block might be a suitable option for you. It provides the flexibility to update the matrices based on your desired schedule.

State equations

Output equations

[John]

Thanks @Sam Chak. And you're right, i wasn't clearn about on what i meant by "update states". I was referring to the states only, not changing the system.

1) The LTI system is the same, and is not touched. But, i'm looking to change what states it's at internally, and manually (and in a manner deliberately not consistent with the state evolution).

Ie it's the "initial conditions" line in the State Space block, but that's not possible to change during runtime. I'm looking for a way to effectively periodically "reset" State Space block to certain states.

For example, assume the system R with const ABCD matrices, per above (but hopefully more clarity here)

If i input a command u(t) to R, with t = [to ..tf], then R will output states from [to..tf], with time tf having the set of states [x1(tf), x2(tf), ...xn(tf)]; these x1..xn also define y(tf) of course, explicitely.

Call this the set of general R states Old(tf). (tf) means at time tf.

Let's say at time tf i'd like to suddenly set R so that Old(tf) are now instead a different set of states, as found by another system, say the set of Good(tf) states and the correspondigly defined y(tf) (Note: this is of course not-physically-possible to instantly change the states, in the case that R represents a real system; but that's not a problem for this).

Untouched, R would continue to evolve with u(t) until the end of time, consistent with the state evolution x.=Ax+Bu. But instead, when R(tf) gives states Old(tf), I'd like R to suddenly no longer evolve from Old(tf), but instead from the new set of states Good(tf) (and corresponding new y(tf) ). So, every T seconds, R is updated to evolve from a new starting point, even though u(t) stays the same.

So this is not a normal state evolution, but is periodically set to some other reference.

2) Example with one state, x. xR is state of R, xC is state of C

Assume a basic integrator R (resetting system), and C (continuous, untouched system), resetting every 3 seconds. So reset period T = 3.

R = 1/s, and C = 2/s (ie C integrates twice as fast as R).

--- RESET R TO C's states---

t = 0: xR = 0, xC = 0

t = 1: xR = 1, xC = 2

t = 2: xR = 2, xC = 4

--- RESET R TO C's states---

[if R not reset, xR would continue to evolve from 3, but instead will now evolve from xC(t=2) = 6]

t = 3: xR = xC(2) = 4, xC = 6

t = 4: xR = 5, xC = 8

t = 5: xR = 6, xC = 10

--- RESET R TO C's states---

[if R not reset, xR would continue to evolve from 3, but instead will now evolve from xC(t=5) = 10]

t = 6: xR = xC(5) = 10, xC = 12

So, in this way R's dynamics are not matching C's dynamics, but xR is continually updated n*T so that xR roughly tracks xC

In the general case, this would look like manually setting more than one state (eg x1 position, x2 velocity in the case of a 2nd order system) and allowing the x. = Ax + Bu to continue from there, using the new x as a starting point (and u(t) staying the same ie not being affected)

[Sam Chak]

Hi @John

Thank you for describing your problem clearly. Mathematically, I believe you can manipulate the state vector to track at some time t, using the input signal , which is a function of the state vectors and . However, you will need to creatively find the mathematical equation for . It is important to note that the dynamics in the original System R remain unchanged. However, the closed-loop feedback System R may behave similarly to System C.

System C

System R

where

[John]

Thanks @Sam Chak. I'm not sure I understand how to do this in Simulink. Could you show an example?

Since it's easy to set Initial Conditions in State Space, and I'd like to do that with period T with different initial conditions each time, I'm hoping there's a method that uses the standard blocks.

[Sam Chak]

Don't mention it, @John. I perceive the issue akin to a Mathematical Tracking Problem. The task lies in ingeniously deriving an equation to guide the state of System R to closely follow the state of System C.

However, the approach you desire involves manually updating the state to synchronize with every 3 seconds, ensuring the reset mechanism doesn't disrupt System R's natural state evolution.

In this context, @Paul's programmatic approach seems most fitting. However, I'm skeptical about the practicality of correcting the state without addressing its underlying system dynamics. See demo below.

[Sam Chak]

Hey @John, I can only see the programmatic state-resettable approach being useful when both systems R and C are asymptotically stable. Plus, the designer doesn't necessarily need to be mathematically skilled with this approach.

[John]

Thanks @Sam Chak for your ideas :)

The two systems will be close, so it wouldn't be like your example that doesn't address the underlying examples. But, the update period will be short enough that even if the dynamics aren't addressed, the divergence won't be large.

So this could be a way to go. I'll check out Paul's thoughts as well now, and then see what might work best for this specific situation. Thanks for your examples!

Answer 1

[Paul]

i think you'll have to use an Integrator and other native blocks to implement

xdot = A*x + B*u

y = C*x + D*u

Use the external initial condition option and the external reset option to reset the integrator states to the signal on the initial condition line based on whatever your reset logic is. The signal on the IC line should be the IC of the integrator at t = 0 and then the values to reset to at the resets as t moves forward.

Make sure to have appropriate solver settings (solver type, zero crossing detection).

Here's an example that resets the state of the integrator to 1 every time the sine wave crosses zero in either direction, i.e., every pi seconds.

[Paul]

Though it doesn't solve this problem, which requires that the states be reset to values provided from an external source, it may be of interest that the states of State Space block and can be reset to the Initial Conditions block parameter if the state space block is inside a Resettable Subsystem.

[John]

Interesting on both -- thanks @Paul.

Regarding "it may be of interest that the states of State Space block and can be reset to the Initial Conditions block parameter if the state space block is inside a Resettable Subsystem", is there a way to make state space block intitial conditions a variable, vs constants?

"i think you'll have to use an Integrator and other native blocks to implement"

Good point -- this may be a good solution. I'll look into it and see which approach makes the most sense for this application.

[Paul]

Just like any other block parameter, the Initial Conditions parameter of the State Space block can be any expression that evaluates to a valid value for the parameter, in this can a vector (of initial conditions). So you can use, for example, X0 as the parameter value, and then Simulink will evaluate X0 using the normal workspace hierarchy. I assume that works the same way at the resets if the State Space block resides inside a Resettable Subsystem, but I didn't test it.

Based on the context of this thread I assume you're considering putting the State Space block inside a Resettable Subsystem, using a variable, e.g., X0, for the Initial Condition, and then changing the value of X0 in the workspace in which it resides while the simuluation is running (or paused) before the next reset. I don't know if that's feasible, particularly if the new value of X0 isn't known until the time of the reset. It might be feasible, but I just don't know.