Model Order

The model order is a property of a dynamic system model. It is the number of model states that is minimal and sufficient to represent the system dynamics of the actual system. Often, but not always, the model states are associated with storage of energy or information.

(There is another property called relative order that is sometimes relevant and might be discussed in a future installment — the number of updating cycles required for an input to have any effect on the output.)

It would be easy to propose a model that is much too complicated for the actual system, and presume that if one part of the model isn't sufficient, other parts will take up the slack. The net result will be a well-working model — right? Unfortunately, things don't usually work out that way. Models having an order that is inconsistent with the actual system are likely to show a number of pathological properties. Let's list some of the things that can go bad.

 

Pathological state models

It is possible to obtain state equation systems that show various undesirable properties. ^[1]

• The model can be over-specified. In this case, the representation is redundant. Some of the state variables are almost represented as a linear combination of other state variables, with only insignificant differences. The extraneous state variables tend to serve as noise accumulators, and to propagate meaningless rattling without contributing any useful information.

• The model can be under-specified. In this case, the model will be missing some important information necessary to follow the system state accurately. Models sometimes allow a deliberately reduced state representation for simplicity, at the price of an acceptable reduction in accuracy. In the right situations, these reduced order models can be very useful, despite minor deficiencies.

• The model can be unstable. The slightest disturbances can grow as they propagate through the system states, eventually feeding back as enlarged disturbances to other states, and resulting in state variable values that grow toward infinity. These models are rarely useful except in special cases where the real system is unstable. If the model is actually correct, and the system really is unstable, that is typically your first problem, not the model. Feedback might be able to stabilize the system.

• The model can be marginally stable. Though the system does not by itself go off to infinity, the effects of past inputs do not wear off. Sometimes this reflects a real behavior; for example, water in a tank remains at the same level "virtually forever" if valves allowing fluid to be pumped in or out are closed. In the presence of noisy inputs, the result can be a kind of aimless wandering, not consistently heading in any particular direction. A linear state model can certainly represent this, but without the desirable property of strict linearity (the outputs can be nonzero even if all inputs are zero). This almost always leads to some sort of difficulty.

• The model can be non-observable. A group of elements "spin off" like their own self-contained little sub-systems to produce no outside effects. This is a big deal to theorists, but in practice, it probably means only that your model is more complicated than it needs to be. As long as the unobservable states don't "cause things to break" internally, you don't need to care too much, but no point in retaining this kind of clutter in your model.

• The model can be non-controllable, that is, there may be no way to determine an input sequence that can lead to the desired output conditions. This is probably a concern when your system is being designed — uncontrollable systems tend to be unproductive.

A stable and economical system model should have a state transition matrix that is full rank; that is, all matrix rows are linearly independent, and all matrix columns are linearly independent. The model should be of a sufficiently high order to represent all of the important behaviors of the system, without insignificant or extraneous internal behaviors.

Determining how many states a model should have goes a long way toward setting up a model that avoids pathologies. But this can be harder than it first sounds, because state variables are internal and hidden. They would be much easier to account for if you could see them.

 

Example: estimating model order from first principles

If you can determine from physical principles what the order of the state model needs to be, that is a huge advantage. This is mostly a matter of accounting.

Here is an example. A pneumatic lifter is supposed to adjust the vertical position of a platform. As objects with different weight are placed on the platform, this causes some compression in the air cylinder and the platform position sags. The goal will be to input commands to an air pressure valve or air exhaust valve to appropriately raise or lower the platform to maintain its target position.

What are the physically meaningful internal states of this system?

1. We want to observe the platform height, so this is a very good candidate as an easily observable state variable. Various sensing devices area available that can measure the small platform displacements inexpensively and with good accuracy.

2. As air is added or removed from the pressure cylinder, the pressure changes. We can't easily measure the mass of the pumped air, even though that is in theory a very good idea. Pressure can be directly observed using a variety of sensor devices, though to save costs this instrumentation might be omitted.

3. If the pressure causes vertical force that is out of balance with the weight of the object placed on the platform, the imbalance will cause acceleration in the vertical direction. While the pressure difference and the resulting acceleration are physically different, they have a proportional relationship, contributing equivalent information. Pressure differences are typically a little easier to measure than acceleration.

4. The acceleration will lead to velocity in the vertical direction. This velocity is a separate state variable, the cumulative effects of the acceleration over time. But this is probably too difficult or expensive to measure directly.

5. Velocity will cumulatively show its effect as a change in vertical position. That is already covered by the position state variable, so our accounting is done.

The tally is that three states are required to model the system dynamics:

1. pressure difference
2. velocity
3. position

But of these, it is likely that only the position state is easy to observe.

Though we now have a pretty good idea of how many state variables there are, finishing the model involves some details about how input variables, model parameters, and states interact.

At the end of this exercise, we still don't have a model. But we do have a rather good idea of what state variables the model will need, and that is some important progress.

 

Determining system order from measured observations

On the other hand, suppose you don't really have any clear grasp of what all the relevant internal state variables are. (In other words, you have a typical manufacturer's spec sheet for your equipment.) Is it possible to get a reasonable idea of how many state variables the model needs, based on observing the actual system?

To do this, you must of course observe the actual system as it dynamically responds, by driving the system with known inputs, recording the values of both the applied input signals and the observed output signals. Which brings us to the topic for next time.

 

---