A model is an abstract and simplified description of a system using mathematical equations
and diagrams. The modeling concepts in this topic provide context for understanding the
process of mathematically describing a system with Simulink^{®} software tools.

A *block diagram* is a visual representation of a
*model* in the Simulink Editor. The editor allows you to add blocks selected from block libraries
representing elementary model components. Elementary components include integrator,
gain, and sum blocks. *Blocks* are connected to each other with
signal and event *lines* to visually construct the model
equations.

A classic block diagram of a *system* is drawn graphically
with blocks and lines. The history of these block diagrams is derived from
engineering areas such as Feedback Control Theory and Signal Processing. A block
within a block diagram defines a model in itself. The relationships between
elementary models are represented by signal lines connecting the blocks.
Collectively the blocks and lines in a block diagram describe the overall model of a
system.

Simulink extends classic *block diagrams* by:

Adding a set of equations (block methods) to each block that define the time-based relationships between the input signals, output signals, and the block state variables.

Adding parameters to each block that specify the coefficients from the model equations.

Providing a Simulink engine for numerical solution of the

*block diagram*by evaluating the relationships over time, where time starts at a user specified “start time” and ends at a user specified “stop time.”

See also: Simulink Block Diagrams, Build and Edit a Model Interactively, Use block diagrams to graphically represent dynamic systems, Simulation

A *block* is a basic modeling construct of the Simulink Editor. You add instances of the *blocks* from the
built-in Simulink libraries to perform specific operations. You can also create your own
custom blocks. Some blocks have input signals, output signals, and state. Most blocks
have parameters that you use to specify block behavior. Whether a block has parameters
and the nature of those parameters is specific to each block.

Each block represents a set of equations for the Simulink engine. The equations are represented as block methods. The blocks shown above have the following block methods.

Block methods are evaluated during the simulation of a block diagram. The evaluation of the block methods is performed within a simulation loop, where each cycle through the simulation loop represents the evaluation of the block diagram at a given point in time.

Virtual blocks organize and provide graphical hierarchy in a model, but they do not affect the simulation result. During model simulation, the Simulink engine flattens all virtual blocks. That is, Simulink expands the blocks in place before execution. This expansion is similar to the way macros work in a programming language such as C or C++.

Simulink defines the following virtual blocks:

Virtual Subsystem – Use a virtual subsystem to encapsulate related and functional parts within a larger model. A Virtual Subsystem block has the check box for the parameter

**Treat as atomic unit**cleared.Inport and Outport – Use port blocks to move data (signals) and events (function-calls) from outside a System block or referenced Model block to within the block.

Bus Creator, Bus Assignment, Bus Selector – Bus blocks combine signals into a virtual bus and manage the routing of signals around a complex block diagram. Virtual buses are simply a graphical convenience and do not change the behavior of the model.

See Nonvirtual and Virtual Blocks, Signal Types, Types of Composite Signals.

Non-virtual blocks provide execution control and graphical hierarchy in a model. Simulink defines the following non-virtual Subsystem and Model blocks:

Atomic Subsystem and Model – Blocks within an Atomic Subsystem block or a Model block that references a model execute as a single unit (atomic execution) at each time step. For an Atomic Subsystem block, the check box for the parameter

**Treat as atomic unit**is selected.You can place any Simulink block in an Atomic Subsystem or referenced model, including blocks with different execution rates. This flexibility provides the advantage of grouping functional aspects of a model at the execution level.

In the following example, the vehicle model is an Atomic Subsystem block containing blocks that model the mechanics of a car. The control model is referenced from a Model block.

Enabled and Triggered – Atomic Subsystem or Model block whose execution is controlled external data from a signal. Contains an Enable or Trigger port block. For the Trigger port block, the parameter

**Trigger type**is set to`rising`

,`falling`

, or`either`

.Function-Call – Atomic Subsystem or Model block whose execution is controlled by an event from a function-call initiator (e.g., Stateflow chart, Function-Call Generator, and S-Function blocks), Contains a Trigger port block with

**Trigger type**set to`function-call`

.

Simulink defines the following non-virtual components for only Subsystem blocks.

Action Subsystem – Atomic Subsystem block whose execution is controlled by an event from an action initiator (e.g., If or Switch Case block). Contains an Action Port block within the Subsystem block.

While Iterator Subsystem– Atomic Subsystem block that runs multiple iterations during each model time step. Contains a While Iterator block that controls the number of iterations by evaluating a logical condition.

A while iterator subsystem is similar to a function-call subsystem in that it can run for any number of iterations at a given time step. The while iterator subsystem differs from a function-call subsystem in that there is no separate initiator.

For Iterator Subsystem – Atomic Subsystem block that runs a fixed number of iterations during each model time step. Contains a For Iterator block that controls the number of iterations.

A block mask is a custom block parameter interface that displays only selected block parameters. A mask for a Subsystem block allows you to provide an interface for setting parameters on blocks inside the Subsystem block without having to navigate the model hierarchy.

See Masking Fundamentals.

Custom blocks are new blocks that extend the built-in functionality of Simulink. You can create libraries of custom blocks to use in your model.

The following blocks define the algorithm of a custom block either graphically with a block diagram or programmatically.

MATLAB

^{®}Function – Code a MATLAB function using the MATLAB language that runs in a Simulink model . See Implementing MATLAB Functions Using Blocks.MATLAB System – Bring existing

`System`

objects based on matlab.System into Simulink. See MATLAB System Block.Subsystem – Draw a block diagram representing an algorithm, wrap this diagram in an instance of the Simulink Subsystem block, and then provide the block with a parameter dialog using a Simulink block mask. See Subsystem, Atomic Subsystem, CodeReuse Subsystem.

C Caller – Integrates your external C code into a Simulink model. See Integrate C Code Using C Caller Blocks.

S- function – Create a custom block programmatically by creating a MATLAB file or a MEX-file that contains the block's system functions. The resulting file is called an S-function. You then associate the S-function with instances of the Simulink S-Function block in your model. See S-Function.

See Types of Custom Blocks, Block Authoring and Simulation Integration.

A line is a basic modeling construct of the Simulink Editor. Lines connect the output ports of blocks with the input ports of other blocks.

Signal lines transfer data during a simulation from one block to another block. Signals are time varying quantities that have values at all points in time (continuous) or at specified time points (discrete). The source of a signal corresponds to the block that writes to the signal during evaluation of its block output method. The destination of a signal is the block that reads the signal during the evaluation of its block input method.

You can specify signal attributes, including signal name, data type (e.g., double, 32-bit integer), numeric type (e.g., real, complex) and dimension (e.g., one-dimensional, two-dimensional, multi-dimension array). Many blocks can accept or output a signal of any data type or dimensionality. Other blocks impose restriction on the attributes of the signal they can handle.

During a simulation, save data from a signal by logging the signals.

In response to a function-call or action initiator, event lines send an event to a Subsystem or Model block. The block that receives the event, executes the blocks within it one or more times during a time step. Function-call initiators include Function-Call Generator blocks, Stateflow charts, and S-function blocks. Action initiators include If and Switch Case blocks.

See Signals and Signal Basics.

Data is the parameter and input signal values that Simulink uses to produce the output values resulting from simulating the behavior of a model.

Types of data:

Model parameters – Variables to specify block and signal parameters in a model. Includes MATLAB variables, parameter and signal data objects, data type objects, and bus objects.

Model configuration parameters – Control a simulation.

Simulation data – Input data that you use to drive a simulation and the output data that a simulation generates.

Data Objects – Use the

`Simulink.Signal`

and`Simulink.Parameter`

classes to create data objects. See Data Objects.

Location of data:

**Block parameters**– Use block parameters to directly specify numerical values. You can also enter a variable name and define its value in the Simulink model workspace, a Simulink data dictionary, or the MATLAB base workspace.**MATLAB base workspace**– Use the MATLAB base workspace to save variables that are separate from the model in a MAT-file or MATLAB script.Simulink treats the base workspace and the data dictionary as a single global name space. If the base workspace and a referenced data dictionary have identical variable name, Simulink uses the variable value in the data dictionary.

The MATLAB base workspace contains variables that are global and visible to all Simulink models.

See Comparison of Signal Loading Techniques, Export Simulation Data.

**Simulink model workspace**– Use the model workspace to define and store local data variables. Variables defined in a model workspace are visible only within the scope of the model with a unique name space. Therefore, you can use the same variable name in multiple model workspaces and you can assign a unique variable value to the name in each model.Define variables in the data dictionary using Model Explorer. In the

**Modeling**tab, click**Model Explorer**. In the left pane, select Model Workspace.Values for the model workspace variables are initialized from values saved with the model, from a separate MAT-file or MATLAB file, or initialized using MATLAB code saved with the model.

See Model Workspaces, Specify Source for Data in Model Workspace.

**Simulink data dictionary**– Use a Data Dictionary to define and store global data, share data between models, and track changes made to the data. Data is saved in a file separate from the model.Create a data dictionary file. In the

**Modeling**tab, under**Design**, click**Data Dictionary**. Click**New**and enter a file name with an extension`.sldd`

.Define variables in the data dictionary using Model Explorer. In the

**Modeling**tab, click**Model Explorer**. In the left pane, select**Design Data**.

Imported and exported data – Import signals for a simulation from the MATLAB base workspace, a MAT-file, or a spreadsheet. Create input signals using a source block or the Signal Editor block. Use signal logging to export simulation results. Signals are saved as vectors

`[t, X, Y]`

for time, state and output at each major time step.

See also: Determine Where to Store Variables and Objects for Simulink Models, Symbol Resolution.

Parameters are Simulink model characteristics that affect the simulation and code generation result.

Model parameters specify model behavior during compilation, simulation, and code generation such as the solver to use and the types of errors and warnings to display.

To specify model parameters, in the **Modeling** tab, click
**Model Settings** . The Configuration Parameters dialog box
opens.

Block parameters define model dynamics and mathematics. Whether a block has
parameters that you can set and the nature of those parameters is specific to each
block. To specify block parameters, open the block parameter dialog box, or in the
**Modeling** tab, under **Design**, click one
of the following:

**Property Inspector**– Specify block parameters directly or enter a variable name for a parameter value.**Model Data Editor**– Specify block parameters with variables.**Model Explorer**– Specify block parameters with variables.

If you have a single parameter used in many locations across a large model, updating every instance of that parameter can be a difficult task. Instead, enter a variable name as the value of a parameter and then define the variable once using one of the following methods.

Simulink Model Workspace – Create model workspace variables and assign values to the variables. The parameters you define are specific to the model and saved with the model. Use a MATLAB variable for ease of maintenance. Use a

`Simulink.Parameter`

object to control additional properties including, data type, dimensions, and units. See Edit and Manage Workspace Variables by Using Model Explorer .Simulink Data Dictionary – Create design data variables in a data dictionary and link the dictionary to a model. During model simulation, Simulink retrieves data from the data dictionary.

MATLAB Base Workspace – In the MATLAB base workspace, define parameters using any MATLAB mechanism for defining a variable. For example, you can use a MAT-file and load the variables when you open the model. Use MATLAB expressions to specify parameter variable values. Simulink evaluates the expressions before running a simulation. See Save and Load Workspace Variables (MATLAB), Save Workspace Variables (MATLAB), Load Workspace Variables (MATLAB).

Using the MATLAB base workspace or a Simulink data dictionary to define variables is useful when you are using the same set of parameters for more than one model. This mechanism also allows you to use different sets of parameter values for the same model.

See also Share and Reuse Block Parameter Values by Creating Variables, Create, Edit, and Manage Workspace Variables.

When you reference the same model from multiple Model blocks you create instances of the model. You can set block parameters to use the same value or a different value for each instance of the model.

To use different values,

In the model workspace for the referenced model, create a MATLAB variable or

`Simulink.Parameter`

object.Enter a parameter name and a default parameter

**Value**. Select the**Argument**check box to create a*model argument*.For a block in the referenced model, enter the name of the model argument for the value of a block parameter.

For each Model block, open the block parameters dialog box, select the

**Instance parameters**tab, enter a value for the*instance parameter*with the*model argument*name.

See also Parameterize Instances of a Reusable Referenced Model.Tunable Block Parameters

You can change the value of a tunable block parameter during a simulation. This allows you to determine interactively the most suitable value for a parameter. When you change the value of a tunable parameter, the change takes effect at the start of the next time step. For example, the gain parameter of the Gain block is tunable. You can change the block gain while a simulation is running. See Tune and Experiment with Block Parameter Values.

To specify parameters, in the **Modeling** tab, under
**Design**, click **Property Inspector**.
Click a block to display the block parameters and properties.

See also Specify Block Properties.

Properties are Simulink model characteristics that generally do not affect the simulation result.
To specify properties, in the **Modeling** tab, under
**Design**, click **Property Inspector**.

With the Property Inspector opened, click a blank space within a *block
diagram*, or in the **Modeling** tab, select **Model Settings** > **Model Properties**. Model properties include:

General – Name an location of model file.

Design Data – Variables defined outside the model that parameterize the model and its blocks and signals.

Callbacks – Commands that execute when a specific model event occurs.

With the Property Inspector opened, select a block, and then select the
**Properties** tab. Block properties include:

Block Annotation – Values of selected block parameters displayed below the block.

Callbacks – Commands that execute when a specific block event occurs. For example, you can set up a MATLAB script to load and define block parameter variables using expressions.

Priority – Set the relative execution order of blocks. A lower value executes the block first before a larger priority value.

Tags – Block identifiers that are programmatically searchable.

To set properties, in the **Simulation** tab, under
**Prepare**, click **Property Inspector**.
Click an empty space to display the model properties. Click a block to display the
block properties.

See also: Specify Block Properties,Callbacks for Customized Model Behavior.

The state of a model is defined by the values of its state variables. State variables are the set of variables whose values at time zero with the values of model inputs and the model equations can determine the behavior of a model during a simulation. Examples of state variables include, motor position and velocity, inductor current, capacitor voltage, solution temperature, and gas pressure.

If the current output value of a block is a function of the previous output value, the block defines a state variable that needs to be saved between time steps. Computing a block output hence entails saving the value of the state variable at the current time step for use in computing the output at a subsequent time step.

The following facilities are provided for determining, initializing, and logging model states during simulation:

The

**Data Import/Export**pane of a model's Configuration Parameters dialog box (see State Information) allows you to specify initial values for model states, and to record the values of the states at each time step during simulation as an array or structure variable in the MATLAB workspace.Open the Configuration Parameters dialog box. Select the

**States**check block for logging to the MATLAB variable`xout`

.In the MATLAB Command Window, list the logged values for state of the Integrator block at each time step.

>> xout{1}.Values.Data ans = 0.0000 1.8127 3.2968 4.5119 . . .

The

`model`

command displays information about the states defined by a model, including the total number of states, the block that defines each state with its initial value. List blocks in the model vehicle_model with states.In the MATLAB Command Window, enter the model function, and then list blocks with state.

[sys,x0,str,ts] = vehicle_model([],[],[],'sizes') str = {'vehicle_model/Integrator'}

The Simulink debugger displays the value of a state at each time step during a simulation, and the Simulink debugger's

`states`

command displays information about the model's current states (see Simulink Debugger).In the MATLAB Command Window, start the Simulink debugger, and then enter the command

`states`

.sldebug 'vehicle_model' (sldebug @0): >> states Continuous States for 'vehicle_model': Idx Value (system:block:element Name 'BlockName') 0. 0 (0:0:0 CSTATE 'vehicle_model/Integrator')

The Block Parameters dialog box (and the

`ContinuousStateAttributes`

parameter) allows you to give names to states for those blocks (such as the Integrator) that employ continuous states. This can simplify analyzing data logged for states, especially when a block has multiple states.

A continuous state is defined for all values of time. An example of a continuous state would be the velocity of a car show on an analog speedometer with a needle position that changes continuously with the rotation of a tire.

Blocks with continuous states and the block parameter **Initial
condition** include:

In general, excluding simple models, analytical methods do not exist for integrating states represented by ordinary differential equations. Integrating the states requires the use of numerical methods.

A discrete state is defined only at specific times. It is an approximation of a continuous state where the state is updated at periodic or aperiodic time intervals. An example of a discrete state would be the velocity of a car shown on a digital speedometer that is updated every second as opposed to continuously.

Blocks with discrete states include:

Discrete Time Integrator

Discrete State-Space

Discrete Transfer Fcn

Delay

Computing the discrete state for a block requires knowing its value at the previous time step and also the current input value to the block. Simulink provides two types of discrete solvers:

Fixed-step discrete solver – determines a fixed step size that hits all the sample times for all the model's discrete states, regardless of whether the states actually change value at the sample time hits.

Variable-step discrete solver – varies the step size to ensure that sample time hits occur only at times when the states change value.

A hybrid model has both continuous and discrete states. Solving such a model entails choosing a step size that satisfies both the precision constraint on the continuous state integration and the sample time interval constraint on the discrete states. Simulink meets this requirement by passing the next sample time interval for the discrete solver as an additional constraint on the continuous solver. The continuous solver chooses a step size that advances the simulation up to but not beyond the time of the next discrete sample time . The continuous solver can take a time step short of the next sample time hit to meet its accuracy constraint but it cannot take a step beyond the next sample time hit even if its accuracy constraint allows it to.

You can simulate hybrid systems using any of the integration methods, but certain
methods are more effective than others. For most hybrid systems,
`ode23`

and `ode45`

are superior to the other
solvers in terms of efficiency. Because of discontinuities associated with the
sample and hold of the discrete blocks, do not use the `ode15s`

and
`ode113`

solvers for hybrid systems.

Sample time is the time interval that specifies the rate (1 / sample time) for executing block methods to produce outputs and update internal state of blocks. Time is an inherent component of a block diagram in that the simulation results of a block diagram change with time.

Sample time is specified as:

Continuous – Blocks run at variable times based on solver settings.

Discrete – Blocks run at specific times that are explicitly specified.

In the following example, the controller runs at a discrete rate specified with a
sample time of `0.01`

seconds while Simulink determined the vehicle model to have a continuous sample time.

Determining a system's behavior over time thus entails repeatedly solving the model at
intervals, called time steps or time intervals, from the start of the time span to the
end of the time span. The process of solving a model at successive time steps is
referred to as *simulating* the system that the model
represents.

See also What Is Sample Time?, Types of Sample Time, Specify Sample Time, and View Sample Time Information.

Every Simulink block has a sample time which defines when the block will execute.
Most blocks allow you to specify the sample time via a `SampleTime`

parameter. Common choices include discrete, continuous, and inherited sample
times.

Common Sample Time Types | Sample Time | Examples |
---|---|---|

Discrete | [`T` ] | Unit Delay, Digital Filter |

Continuous | [0, 0] | Integrator, Derivative |

Inherited | [–1, 0] | Gain, Sum |

For discrete blocks, the sample time is a vector [Ts, To] where Ts is the time interval or period between consecutive sample times and To is an initial offset to the sample time. In contrast, the sample times for nondiscrete blocks are represented by ordered pairs that use zero, a negative integer, or infinity to represent a specific type of sample time. For example, continuous blocks have a nominal sample time of [0, 0] and are used to model systems in which the states change continuously (e.g., a car accelerating). Whereas you indicate the sample time type of an inherited block symbolically as [–1, 0] and Simulink then determines the actual value based upon the context of the inherited block within the model.

Note that not all blocks accept all types of sample times. For example, a discrete block cannot accept a continuous sample time.

For a visual aid, Simulink allows the optional color-coding and annotation of any block diagram to indicate the type and speed of the block sample times. You can capture all of the colors and the annotations within a legend (see View Sample Time Information).

For a more detailed discussion of sample times, see Sample Time

Units are used to measure the total amount of a quantity.

Simulink
*units* are specified as a Inport block or
Outport block parameter at the boundaries of a Simulink
*model component*. Simulink
*model components* include Subsystem blocks,
Model blocks, Stateflow charts, and Simulink to Simscape converter blocks. To display units on a model, in the
**Debug** tab, select **Information Overlays** > **Units**.

See also: Unit Specification in Simulink Models, Converting Units.

Simulink block characteristic where the output port signal of a block is computed from the values of its input port signals. The output signal value is a function of the input signal values.

Blocks with direct feedthrough include the Gain, Product, Sum, Transfer Fcn, State-Space, and Math Function blocks.

See also: Algebraic Loop Concepts.

*Signal* loop between blocks with *direct
feedthrough*. An *algebraic loop* generally occurs
when an input port of a block with *direct feedthrough* is driven
directly by the output port of the same block or indirectly through other blocks with
*direct feedthrough*.

In the following model, the two Gain blocks with *direct
feedthrough* create an *algebraic loop*.

See also: Algebraic Loop Concepts.

An *artificial algebraic loop* occurs when an atomic subsystem or Model block causes Simulink to detect an algebraic loop, even though the contents of the subsystem do not contain a direct feedthrough from the input to the output. When you create an atomic subsystem, all Inport blocks are direct feedthrough, resulting in an algebraic loop.

Start with the included model, which represents a simple proportional control of the plant described by

which can be rewritten in state-space form as

The system has neither algebraic variables nor direct feedthrough and does not contain an algebraic loop.

Modify the model as described in the following steps:

Enclose the Controller and Plant blocks in a subsystem.

In the subsystem dialog box, select

**Treat as atomic unit**to make the subsystem atomic.In the

**Diagnostics**pane of the Model Configuration Parameters, set the**Algebraic Loop**parameter to`error`

.

When simulating this model, an algebraic loop occurs because the subsystem is direct feedthrough, even though the path within the atomic subsystem is not direct feedthrough. Simulation stops with an algebraic loop error.

The simulation uses a technique known as *zero-crossing
detection* to accurately locate a discontinuity without resorting to
excessively small time steps during a simulink. Usually this technique improves
simulation run times.