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 example shows the modeling of the Simulink® clutch example using Simulink based states inside a Stateflow® chart. For a detailed explanation of the physical system, see Building a Clutch Lock-Up Model (Simulink).

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.

Related Topics