Documentation

State Information

Simulation State Information

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 for calculating the output signal value for the current simulation step.

Some examples of uses of saved state information 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.

Types of State Information

You can save these kinds of state information.

Type of State InformationDescriptionConfiguration Parameters in Data Import/Export Pane
States for each simulation stepState information of blocks (referred to as partial state data) at each time step of a simulationStates
Final stateState information of blocks at the end of the simulationFinal states
Final state with SimStateFinal state with a SimState object that captures additional internal information that Simulink® uses during simulationFinal States and Save complete SimState in final state

SimState provides more complete final simulation state information than final states information by itself does. However, if the requirements and limitations of using SimState do not meet your modeling requirements, save final state information without SimState.

Comparison of SimState and Final State Logging

CharacteristicFinal StateFinal State with SimState

Simulation mode

Supports all simulation modes

Normal or Accelerator.

Model reference

State Information for Referenced Models

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 SimState even if S-functions declare that no SimState states exist in the block. If the block output is of custom type, Simulink displays an error.

Readability

Use structure with time format for best readability

To examine a simplified view of the data, consider using looking at the loggedStates property of the Simulink.SimState.ModelSimState class.

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 two simulation modes.

Cannot save in normal mode and restore in Accelerator, 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 SimState and when you restore the simulation using the SimState. For example, you cannot add or remove a block after saving the SimState without repeating the simulation and saving the new SimState.

Input to model function

To input to model function, use Array format with non-complex data of type double.

You cannot input the SimState to model function.

Code generation

Supported

Not supported

For both SimState 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 SimState, see Limitations of SimState.

Format for State Information Saved Without SimState

If you do not use the SimState 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 Array option for the Configuration Parameters > Data Import/Export > Format option supports compatibility with models developed in earlier releases, when Simulink supported only the array format for saving state information.

The array format reflects the order of signals. The order of saved state information can change between simulations when you change any of the following:

  • The model (even without changing the signal)

  • The simulation mode

  • The code generation mode

The Structure and Structure with time formats are easier to read and consistent across simulations. Also, these two 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.

  • Dataset format:

    • Uses MATLAB® timeseries objects to store logged data. MATLAB timeseries objects allow you to work with logged data in MATLAB without a Simulink license.

    • Supports logging multiple data values for a given time step, which can be important for Iterator subsystem and Stateflow® signal logging

    • Does not support logging nonvirtual bus data for code generation or rapid accelerator mode.

State Information for Referenced Models

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 reference 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 reference model path. The top model path is the path from the model root to the Model block that references the reference model. The reference model path is the path from the reference model root to the block whose state the signals field records. The compound path uses a | character to separate the top and reference model paths. For example:

>> xout.signals(1).blockName
ans =

sldemo_mdlref_basic/CounterA|sldemo_mdlref_counter/Previous Output

See Also

Classes

Related Examples

Was this topic helpful?