This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Modeling a Clutch

This model shows the modeling of the Simulink® clutch example using Simulink based states inside a Stateflow® chart. You can find a detailed explanation of the physical system, including figures and equations, in the example for the Simulink clutch model with enabled subsystems.

Recommended Workflow

This model shows the recommended way of modeling hybrid systems by using Simulink and Stateflow. This model also covers when to use Simulink or physical modeling tools if the continuous dynamics are complex coupled with mode changes.

Modeling a hybrid system involves addressing the following concerns:

  • Modeling the continuous dynamics

  • Modeling the mode logic

  • Initializing states when switching between modes

Continuous Dynamics

Hybrid systems have multiple modes of operation where each mode is defined by continuous dynamics. When the continuous dynamics are complex, model them by using Simulink based states. In this model, the "Locked" and "Slipping" states represent the two modes of operation of a clutch. Simulink blocks within a Simulink based state represent the logic of the state. These blocks include continuous time blocks, such as integrators. Within each Simulink based state, you can access chart inputs and outputs by creating inports and outports with the same name. Each Simulink based state reads from a subset of chart inputs and writes to all the chart outputs.

Mode Logic

Mode logic refers to the conditions under which the model switches from one mode of operation to another. In this example, the mode logic is described by the transition logic between the two Simulink based states. The conditions needed to switch from one Simulink based state to another depend on the internal state of the integrators within in the current active mode. For example, when switching from "Slipping" to "Locked" Stateflow must read the internal state of the integrator in the "Slipping" mode.

This is possible using two different mechanisms:

1. Using State Reader and State Writer blocks inside Simulink functions: Stateflow can call Simulink functions on the transition logic between the two modes. Inside the Simulink function, use State Reader blocks to refer to the internal state of the integrator. For example, the Simulink function "detectLockup" uses the State Reader block "EngineSpeed" to read the state of the integrator block 'sf_clutch/Clutch/Slipping/xe'

2. Using qualified dot notation on the transition conditions: If the transition logic is simple and can be expressed textually, it is possible to use a syntax like Slipping.we == ... to refer to the state of the integrator 'sf_clutch/Clutch/Slipping/xe'. For this syntax to work, the "State Name" parameter of the integrator has to be set to "we".

State Handoff

When switching from one mode of operation to another, the integrators in the newly activated subsystem need to be initialized properly in order to get smooth output. This can be done using either Simulink State Reader and State Writer blocks in Simulink functions or textually using the qualified dot notation. For example, on the transition from "Slipping" to "Locked", initialize the state of the single integrator in "Locked" by using the state of one of the integrators in "Slipping". Initialize the state by using the syntax:

Locked.w = Slipping.we;

Simulation Results

When the system is simulated, the engine and vehicle velocities are as shown in the following graph. The plates lock at about 4 seconds and begin slipping again at about 6.25 seconds.

Was this topic helpful?