23.2 Simulink for system modeling and simulation

Simulink Basics

Introduction to Simulink

Simulink is a graphical programming environment built on top of MATLAB for modeling, simulating, and analyzing dynamic systems. Instead of writing lines of code to describe how a system behaves, you build a visual block diagram that represents the math behind the system. This makes it much easier to see how signals flow through a design and to spot problems early.

One of Simulink's biggest strengths is its tight integration with MATLAB. You can pull MATLAB algorithms directly into your Simulink model, and you can export simulation results back to MATLAB for plotting or further number-crunching. That two-way connection means you're not locked into one tool.

Block Diagrams and Model-Based Design

Simulink represents systems as block diagrams: blocks connected by lines that show how signals and data move between components. Each block performs a specific function:

• A Gain block multiplies a signal by a constant
• An Integrator block computes the integral of its input over time
• A Scope block displays the signal so you can visualize system behavior

These blocks can represent simple math operations or entire complex subsystems. You wire them together to build up a complete system model.

Model-Based Design is the development approach that makes this useful beyond just simulation. The idea is that your Simulink model becomes the single reference point for the whole project. You simulate it to check behavior, verify it against requirements, and even generate code from it for embedded hardware. This lets you iterate on designs quickly without building physical prototypes at every stage.

Simulink Library Blocks

Simulink ships with an extensive library of predefined blocks organized by category:

• Sources provide input signals (step functions, sine waves, constants)
• Sinks capture or display outputs (Scope, To Workspace)
• Math Operations perform arithmetic (Sum, Gain, Product)
• Continuous handle continuous-time dynamics (Integrator, Transfer Function)
• Discrete handle discrete-time dynamics (Unit Delay, Discrete Transfer Function)

To build a model, you drag blocks from the library into the editor and connect them with signal lines. Each block has configurable parameters (sample time, initial conditions, gain values, etc.) that you set to match your specific system.

If the built-in blocks don't cover what you need, you can create custom blocks using MATLAB functions or S-functions.

System Modeling

Continuous-Time and Discrete-Time Systems

Continuous-time systems have variables that change smoothly and constantly over time. Think of a charging capacitor or a swinging pendulum. In Simulink, these are modeled using blocks that represent differential equations, such as the Integrator block and the Transfer Function block.

Discrete-time systems have variables that update only at specific time steps, not continuously. A digital controller that samples a sensor every 1 ms is a discrete-time system. Simulink models these using blocks that represent difference equations, like the Unit Delay block and the Discrete Transfer Function block.

Simulink handles both types in the same model, which is important because real-world systems often mix continuous physical processes with discrete digital controllers.

State-Space Models and Transfer Functions

These are two standard ways to mathematically describe linear time-invariant (LTI) systems.

State-space models use a set of first-order differential equations organized around four matrices:

• A (state matrix): describes how the current state affects the next state
• B (input matrix): describes how inputs affect the state
• C (output matrix): maps the state to the output
• D (feedthrough matrix): maps the input directly to the output

The general form is:

$\dot{x} = Ax + Bu$ $y = Cx + Du$

Simulink's State-Space block lets you enter these matrices directly.

Transfer functions describe the input-output relationship in the frequency domain as a ratio of polynomials. For continuous-time systems, they use the Laplace variable $s$; for discrete-time systems, they use the Z-transform variable $z$. For example, a simple first-order low-pass filter might have the transfer function:

$H(s) = \frac{1}{s + 1}$

Simulink's Transfer Function block accepts the numerator and denominator polynomial coefficients.

Simulation Setup

Simulation Parameters

Before running a simulation, you need to configure a few key settings in the Simulation Parameters dialog:

• Start and stop times define how long the simulation runs (e.g., 0 to 10 seconds)
• Step size controls the time interval between computation points
  • Fixed-step: the solver uses the same time increment throughout
  • Variable-step: the solver adjusts the increment automatically, taking smaller steps when the system changes rapidly and larger steps when it's stable

Choosing the right step size matters. Too large and you miss important dynamics; too small and the simulation takes unnecessarily long.

Solvers and Simulation Modes

Solvers are the numerical algorithms that compute how the system evolves over time. Simulink offers several, and the right choice depends on your system:

• ode45: a general-purpose variable-step solver, good for most non-stiff problems
• ode23: less accurate per step than ode45 but can be faster for models with moderate accuracy needs
• ode15s: designed for stiff systems where some dynamics change much faster than others (common in circuits with very different time constants)

A quick way to pick: start with ode45. If the simulation is very slow or the solver takes extremely small steps, your system is likely stiff, and you should switch to ode15s.

Simulink also offers different simulation modes:

• Normal mode: the default, runs the model interpretively. Best for debugging and interactive work.
• Accelerator mode: compiles the model into compiled code before running, which speeds up execution.
• Rapid Accelerator mode: creates a standalone executable, offering the fastest simulation for large models or parameter sweeps.

Subsystems and Model Organization

As models grow, they get hard to read and maintain. Subsystems solve this by letting you group a set of blocks into a single higher-level block, creating a hierarchy.

For example, if your model has a plant, a controller, and a sensor, you could put each into its own subsystem. The top-level diagram then shows three clean blocks instead of dozens of individual ones.

A few details worth knowing:

• Virtual subsystems are purely organizational. They don't change how the simulation executes; they just clean up the visual layout.
• Non-virtual subsystems (like Atomic Subsystems) do have their own execution context, which matters for controlling when blocks inside them are evaluated.
• Masked subsystems let you create a custom interface with labeled parameters, so other users can configure the subsystem without opening it up and editing individual blocks.
• Model referencing takes this further by letting you reference an entirely separate Simulink model file, which is useful for team projects where different people work on different parts of the system.