How Simscape Models Represent Physical Systems

Representations of Physical Systems

This section describes important characteristics of the mathematical representations of physical systems, and how Simscape™ software implements such representations. You might find this overview helpful if you:

  • Require details of such representations to improve your model fidelity or simulation performance.

  • Are constructing your own, custom Simscape components using the Simscape language.

  • Need to troubleshoot Simscape modeling or simulation failures.

Mathematical representations are the foundation for physical simulation. For more information about simulation, see How Simscape Simulation Works.

Differential, Differential-Algebraic, and Algebraic Systems

The mathematical representation of a physical system contains ordinary differential equations (ODEs), algebraic equations, or both.

  • ODEs govern the rates of change of system variables and contain some or all of the time derivatives of the system variables.

  • Algebraic equations specify functional constraints among system variables, but contain no time derivatives of system variables.

  • Without algebraic constraints, the system is differential (ODEs).

  • Without ODEs, the system is algebraic.

  • With ODEs and algebraic constraints, the system is mixed differential-algebraic (DAEs).

A system variable is differential or algebraic, depending on whether or not its time derivative appears in the system equations.


A mathematical problem is stiff if the solution you are seeking varies slowly, but there are other solutions within the error tolerances that vary rapidly. A stiff system has several intrinsic time scales of very different magnitude [1].

A stiff physical system has one or more components that behave “stiffly” in the ordinary sense, such as a spring with a large spring constant. Mathematical equivalents include quasi-incompressible fluids and low electrical inductance. Such systems often exhibit high frequency oscillations in some of their components or modes.

Events and Zero Crossings

Events are discontinuous changes in system state or dynamics as the system evolves in time; for example, a valve opening, or a hard stop. For more information on how events are represented in the Simscape language, see Discrete Event Modeling.

A zero crossing is a specific event type, represented by the value of a mathematical function changing sign. Variable-step solvers take smaller steps when they detect a zero-crossing event. Smaller steps help to capture the dynamics that cause the zero crossing, but they also significantly slow down the simulation. Various methods of zero crossing detection and analysis help you strike the right balance between the simulation speed and accuracy. For more information, see Managing Zero Crossings in Simscape Models.

Working with Simscape Representation

A Simscape model is equivalent to a set of equations representing one or more physical systems as physical networks.

Managing Zero Crossings in Simscape Models

Your model can contain zero-crossing conditions arising from several sources:

  • Simscape and Simulink® blocks copied from their respective block libraries

  • Custom blocks programmed in the Simscape language

Simulink software has global methods for managing zero-crossing events. For more information, see Zero-Crossing Detection (Simulink).

You can disable zero-crossing detection on individual blocks, or globally across the entire model. Zero-crossing detection often improves simulation accuracy, but can slow simulation speed.


If the exact times of zero crossings are important in your model, then keep zero-crossing detection enabled. Disabling it can lead to major simulation inaccuracies.

Detecting and Minimizing Zero Crossings in Simscape Models

In addition to generic Simulink methods, Simscape software has specific tools that let you detect and manage zero-crossings in your models:

  • Prior to simulation, you can use the Statistics Viewer to identify the potential zero-crossing signals in the model. These signals are typically generated from operators and functions that contain discontinuities, such as comparison operators, abs, sqrt functions, and so on. During simulation it is possible for none of these signals to produce a zero-crossing event or for one or more of these signals to have multiple zero-crossing events. For more information, see View Model Statistics.

  • When logging simulation data for a model, you can select the Log simulation statistics option. The data log then includes the actual zero-crossing data during simulation. For more information, see Log Simulation Statistics.

    You can access and analyze zero-crossing data logged during simulation by using the Simscape Results Explorer. For more information, see About the Simscape Results Explorer.

  • The sscprintzcs function prints information about zero crossings detected during simulation, based on logged simulation data. Before you call this function, you must have the simulation log variable, which includes simulation statistics data, in your current workspace. For more information and examples, see sscprintzcs.

Managing zero crossing is especially important when you prepare your models for real-time simulation. See Reduce Zero Crossings for a detailed example of this workflow.

Enabling and Disabling Zero-Crossing Conditions in Simscape Language

When writing code for your own custom blocks using the Simscape language, you can create or avoid zero-crossing conditions in your model by switching between different implementations of discontinuous conditional expressions. You can:

  • Use relational operators, which create zero-crossing conditions. For example, programming the operator relation: a < b creates a zero-crossing condition.

  • Use relational functions, which do not create zero-crossing conditions. For example, programming the functional relation: lt(a,b) does not create a zero-crossing condition. For more information on whether a particular function creates discontinuities when used in Simscape language, see equations.


Using relational functions, like lt(a,b), in event predicates always creates a zero-crossing condition. For more information about event predicates, see Discrete Event Modeling.

Was this topic helpful?