## Sample Times in Systems and Subsystems

### Purely Discrete Systems

A purely discrete system is composed solely of discrete blocks and can be modeled
using either a fixed-step or a variable-step solver. Simulating a discrete system
requires that the simulator take a simulation step at every sample time hit. For a
*multirate discrete system*—a system whose blocks
Simulink^{®} samples at different rates—the steps must occur at integer
multiples of each of the system sample times. Otherwise, the simulator might miss
key transitions in the states of the system. The step size that the Simulink software chooses depends on the type of solver you use to simulate the
multirate system and on the fundamental sample time.

The *fundamental sample time* of a multirate discrete system is
the largest double that is an integer divisor of the actual sample times of the
system. For example, suppose that a system has sample times of 0.25 and 0.50
seconds. The fundamental sample time in this case is 0.25 seconds. Suppose, instead,
the sample times are 0.50 and 0.75 seconds. The fundamental sample time is again
0.25 seconds.

The importance of the fundamental sample time directly relates to whether you direct the Simulink software to use a fixed-step or a variable-step discrete solver to solve your multirate discrete system. A fixed-step solver sets the simulation step size equal to the fundamental sample time of the discrete system. In contrast, a variable-step solver varies the step size to equal the distance between actual sample time hits.

The following diagram illustrates the difference between a fixed-step and a variable-step solver.

In the diagram, the arrows indicate simulation steps and circles represent sample time hits. As the diagram illustrates, a variable-step solver requires fewer simulation steps to simulate a system, if the fundamental sample time is less than any of the actual sample times of the system being simulated. On the other hand, a fixed-step solver requires less memory to implement and is faster if one of the system sample times is fundamental. This can be an advantage in applications that entail generating code from a Simulink model (using Simulink Coder™). In either case, the discrete solver provided by Simulink is optimized for discrete systems; however, you can simulate a purely discrete system with any one of the solvers and obtain equivalent results.

Consider the following example of a simple multirate system. For this example, the
DTF1 Discrete Transfer Fcn block **Sample
time** is set to `[1 0.1]`

[], which gives it an
offset of `0.1`

. The **Sample time**
of the DTF2 Discrete Transfer Fcn block is set to
`0.7`

, with no offset. The solver is set to a variable-step
discrete solver.

Running the simulation and plotting the outputs using the
`stairs`

function

set_param(bdroot,'SolverType','Variable-Step','SolverName','VariableStepDiscrete','SaveFormat','Array'); simOut = sim(bdroot,'Stoptime','3'); stairs(simOut.tout,simOut.yout,'-*','LineWidth',1.2); xlabel('Time (t)'); ylabel('Outputs (out1,out2)'); legend('t_s = [1, 0.1]','t_s = 0.7','location','best')

produces the following plot.

(For information on the `sim`

command. see Run Simulations Programmatically. )

As the figure demonstrates, because the DTF1 block has a
`0.1`

offset, the DTF1 block has no output until
`t = 0.1`

. Similarly, the initial conditions of the transfer
functions are zero; therefore, the output of DTF1, y(1), is zero before this
time.

### Hybrid Systems

*Hybrid systems* contain both discrete and continuous blocks
and thus have both discrete and continuous states. However, Simulink solvers treat any system that has both continuous and discrete sample
times as a hybrid system. For information on modeling hybrid systems, see Modeling Hybrid Systems.

In block diagrams, the term hybrid applies to both hybrid systems (mixed
continuous-discrete systems) and systems with multiple sample times (multirate
systems). Such systems turn yellow in color when you perform an **Update
Diagram** with Sample Time Display **Colors**
turned '`on`

'. As an example, consider the following model that
contains an atomic subsystem, “Discrete Cruise Controller”, and a
virtual subsystem, “Car Dynamics”.

**Car Model**

With the **Sample Time** option set to
**All**, an **Update Diagram**
turns the virtual subsystem yellow, indicating that it is a hybrid subsystem. In
this case, the subsystem is a true hybrid system since it has both continuous and
discrete sample times. As shown below, the discrete input signal, D1, combines with
the continuous velocity signal, v, to produce a continuous input to the
integrator.

**Car Model After an Update Diagram**

**Car Dynamics Subsystem After an Update Diagram**

Now consider a multirate subsystem that contains three Sine Wave source blocks, each of which has a unique sample time — 0.2, 0.3, and 0.4, respectively.

**Multirate Subsystem After an Update Diagram**

An **Update Diagram** turns the subsystem yellow because
the subsystem contains more than one sample time. As shown in the block diagram, the
Sine Wave blocks have discrete sample times D1, D2, and D3 and
the output signal is fixed in minor step.

In assessing a system for multiple sample times, Simulink does not consider either constant [inf, 0] or asynchronous [–1, –n] sample times. Thus a subsystem consisting of one block that outputs constant value and one block with a discrete sample time will not be designated as hybrid.

The hybrid annotation and coloring are very useful for evaluating whether or not the subsystems in your model have inherited the correct or expected sample times.

### Sample Time in Subsystems

Subsystems fall into two categories: triggered and non-triggered. For triggered
subsystems, in general, the subsystem gets its sample time from the triggering
signal. One exception occurs when you use a Trigger block to create a triggered
subsystem. If you set the block **Trigger type** to
**function-call** and the **Sample time
type** to **periodic**, the
`SampleTime`

parameter becomes active. In this case,
*you* specify the sample time of the Trigger
block, which in turn, establishes the sample time of the subsystem.

There are four non-triggered subsystems:

Virtual

Enabled

Atomic

Action

Simulink calculates the sample times of virtual and enabled subsystems based on the respective sample times of their contents.

The atomic subsystem is a special case in that the subsystem block has a
`SystemSampleTime`

parameter. Moreover, for a sample time other
than the default value of –1, the blocks inside the atomic subsystem can have only a
value of `Inf`

, –1, or the identical (discrete) value of the
subsystem `SampleTime`

parameter. If the atomic subsystem is left
as inherited, Simulink calculates the block sample time in the same manner as the virtual and
enabled subsystems. However, the main purpose of the subsystem
`SampleTime`

parameter is to allow for the simultaneous
specification of a large number of blocks, within an atomic subsystem, that are all
set to inherited. To obtain the sample time set on an atomic subsystem, use this
command at the command prompt:

get_param(AtomicSubsystemBlock,‘SystemSampleTime’);

Finally, the sample time of the action subsystem is set by the If block or the Switch Case block.

For non-triggered subsystems where blocks have different sample rates, Simulink returns the Compiled Sample Time for the subsystem as a cell array of
all the sample rates present in the subsystem. To see this, use the `get_param`

command at MATLAB^{®} prompt.

get_param(subsystemBlock,'CompiledSampleTime')