Some blocks maintain state information that they use during simulation. For example, the state information for a Unit Delay block is the output signal value from the previous simulation step. The block uses the state information to calculate the output value for the current simulation step.
Some examples of how saved state information is used include:
Stopping a simulation for a model and using the saved state information as input when you restart the simulation.
Simulating one model and using the saved state information as input for the simulation of another model that builds on the results of the first model.
Examining changes in state information throughout a simulation.
You can save these kinds of state information.
| Type of State Information | Description | Configuration Parameters in Data Import/Export Pane |
|---|---|---|
| States for each simulation step | State information of blocks (referred to as partial state data) at each time step of a simulation | States |
| Final state | State information of blocks at the end of the simulation | Final states |
Final state with ModelOperatingPoint | Final state with a ModelOperatingPoint object that captures
additional internal information that Simulink® uses during simulation | Final States and Save final operating point |
ModelOperatingPoint provides more complete final simulation state
information than final states information by itself does. However, if the requirements and
limitations of using ModelOperatingPoint do not meet your modeling
requirements, save final state information without
ModelOperatingPoint.
| Characteristic | Final State | Final State with Operating Point |
|---|---|---|
Simulation mode | Supports all simulation modes | Normal or Accelerator. |
Model reference | See Model Referencing. | |
Resumed simulation | Not supported | Supported. |
Saved state data | Only logged states — the continuous and discrete states of blocks — which are a subset of the complete simulation state of the model User data, run-time parameters, or logs of the model not saved | Complete state information. Does not save user data, run-time parameters, or logs of the model. |
Block output | User data, run-time parameters, or logs of the model not saved | Simulink tries to save the output of a block as part of a
|
Readability | Use structure with time format for best readability | To examine a simplified view of the data, consider using the
|
Restoring state data | Can save and restore in different simulation modes. If logged state information is not sufficient, you can obtain different results in the normal mode and the accelerator mode. | Cannot save in normal mode and restore in accelerator mode, or conversely save in accelerator mode and restore in normal mode. |
Restoring multiple states | You can initialize only one out of multiple logged states in the model. | You restore all states in the model. You cannot load a subset of states. |
Structural changes | You can make structural changes between simulation and restoring the simulation. | You cannot make structural changes to the model between when you save
the |
Input to | To input to model function, use | You cannot input the |
Code generation | Supported | Not supported. |
For both ModelOperatingPoint and final state logging, Simulink saves state information at one of these points:
At the final time step
At the execution time at which the simulation paused or stopped
For additional information about ModelOperatingPoint, see Limitations of Saving and Restoring Operating Point.
If you do not use the ModelOperatingPoint for saving state
information, then use Configuration Parameters > Data Import/Export > Format to specify the data format for the saved state information.
You can set Format to:
Dataset (default)
Array
Structure
Structure with time
The default setting for the Format parameter is
Dataset. The Dataset format:
Stores logged data in timeseries or timetable objects. You can work with data saved in a
timeseries or timetable object in MATLAB® without a Simulink license.
Supports logging multiple data values for a given time step, which can be required for logging data in a For Iterator Subsystem, a While Iterator Subsystem, and Stateflow®.
Does not support rapid accelerator simulation, logging states information inside a function-call subsystem, or code generation.
Signal logging always uses the Dataset format. Logging states data
using the Dataset format allows you to post-process simulation data without
writing custom code for different types of logged data. When you log states using the
Dataset format, the data also automatically streams to the Simulation
Data Inspector during simulation.
The Array option for the Format
parameter exists for backward compatibility with models developed in earlier releases, when
Simulink supported only the Array format for logging state
information. The order of signals within the array depends on the block sorted order, which
can change from one simulation to another when you change any of the following:
The model (even without changing the signal)
The simulation mode
The code generation mode
The variation in signal order can present challenges when post-processing the logged data.
The Structure and Structure with
time formats are useful when using state information to initialize a model
for simulation, allowing you to:
Associate initial state values directly with the full path name to the states. This association eliminates errors that can occur if Simulink reorders the states, but the order of the initial state array does not change correspondingly.
Assign a different data type to the initial value of each state.
Initialize only a subset of the states.
When Simulink saves states in the structure or structure-with-time format, it adds an
inReferencedModel subfield to the signals field of
the structure. The value of this additional subfield is true (1) if the
signals field records the final state of a block that resides in the
referenced model. For example:
xout.signals(1)
ans =
values: [101x1 double]
dimensions: 1
label: 'DSTATE'
blockName: [1x66 char]
inReferencedModel: 1
If the signals field records a referenced model state, its blockName
subfield contains a compound path of a top model path and a referenced model path. The top
model path is the path from the model root to the Model block that references
the referenced model. The referenced model path is the path from the referenced model root
to the block whose state the signals field records. The compound path
uses a | character to separate the top and referenced model paths. For example:
>> xout.signals(1).blockName
ans = sldemo_mdlref_basic/CounterA|sldemo_mdlref_counter/Previous Output