|
|
|
| R2012a Documentation → SimDriveline Version 1 | |
Learn more about SimDriveline |
|
| Contents | Index |
| On this page… |
|---|
Simulating Drivelines within the Simulink Environment |
SimDriveline models use the Simulink solver suite, and many of your choices for these solvers and their settings are no different for driveline simulations than they are for general Simulink models. See the Simulink documentation for a general discussion.
This section examines issues specific to simulating driveline systems. The most important are the dynamical discontinuities caused by the locking and unlocking of clutches.
Once you have chosen a solver for your driveline system, your most important solver choices are step size and tolerance. Assume a fixed simulation time. The real time or computational cost the model needs to finish is less if you demand less accuracy of the simulation and more if you demand more accuracy. The fundamental tradeoff in numerical simulation is speed versus accuracy. The step size and tolerance control this tradeoff. A special case of this tradeoff occurs with "stiff" systems.
Mode changes associated with clutches require further consideration if you use fixed-step solvers. See Optimizing Clutch Mode Changes and Fixed-Step Solvers following.
Variable-step solvers are the typical default. A variable-step solver automatically adjusts its step size as it moves forward in time to adapt to how well the solution is converging. You control the accuracy and speed of the variable-step solution by adjusting the solver tolerance. You can also limit the minimum and maximum step size in a variable-step solver, but you should change these settings only after trying other approaches.
Fixed-step solvers are necessary if you are generating a code version of your model. A typical application in this case is a hardware-in-the-loop simulation. With a fixed-step solver, you can adjust the step size directly and control the accuracy and speed of your simulation.
Larger tolerances or step sizes result in less simulation accuracy but, in general, greater speed. If a system undergoes sudden, rapid changes, larger tolerances or step size can cause major inaccuracies. Consider reducing the tolerances or the step size if your simulation:
Is not accurate enough
Exhibits abrupt discontinuities in driveline states (velocities)
Reaches the minimum step size allowed without converging
The locking and unlocking of clutches induce sudden changes in the driveline dynamics and might require you to reduce the tolerances or the step size. You should set the variable-step solver tolerance or the fixed-step solver step size to the smallest value you can that produces an acceptable simulation speed (not too slow).
For a further discussion of how to simulate clutch mode changes accurately with fixed-step solvers, see Optimizing Clutch Mode Changes and Fixed-Step Solvers following.
This table summarizes the effect and pitfalls of changing tolerances or step size on accuracy and speed, with attention to the effect on clutch simulation.
| Adjustment | Solver Type and Setting | Effect on Accuracy | Effect on Speed | Effect on Clutch Simulation |
|---|---|---|---|---|
| Reduce | Variable-step: tolerances | Increases | Reduces | Improves resolution and simulation of abrupt locking and unlocking |
| Fixed-step: step size | ||||
| Increase | Variable-step: tolerances | Reduces | Increases | Degrades resolution and simulation of abrupt locking and unlocking |
| Fixed-step: step size |
A stiff system has several intrinsic time scales of very different magnitudes. These contrasting time scales result from widely different dynamics of coupled degrees of freedom in the system, from the contrast between initial conditions and later evolution, or both. These time scales can change during the simulation.
Generally, drivelines are not stiff systems, with one broad class of exceptions. While the internal dynamics of a driveline is typically not stiff, its coupling to its external load — the wheel-tire-road load, in the case of an automobile — is often stiff. (A tire is "stiff" in responding slowly to imposed forces and experiencing slip. It also has a broad range of frequency responses.) For example, driving and road conditions typically change over seconds or tens of seconds. However, the internal changes of an automobile's drive system can change over fractions of a second, especially if clutch mode changes and braking are at work. In addition, clutch mode changes create dynamical discontinuities. Optimizing Clutch Mode Changes and Fixed-Step Solvers following discusses these dynamical discontinuities further.
Regular solvers can have difficulty accurately simulating such systems. The Simulink solver suite contains a set of variable-step solvers designed to solve stiff systems. If you are simulating a stiff driveline with a variable-step solver and getting unsatisfactory results, consider:
Reducing the tolerances. This adjustment makes the simulation run more slowly.
Using a stiff variable-step solver.
If you are simulating a stiff driveline with a fixed-step solver and getting unacceptable performance, try:
Reducing the step size. This makes the simulation run more slowly.
Using the Simulink ode14x solver.
[1] Moler, C. B., Numerical Computing with MATLAB, Philadelphia, Society for Industrial and Applied Mathematics, 2004, Chapter 7.
The discontinuities associated with the locking and unlocking of clutches can create significant obstacles to accurate SimDriveline simulation if you are using a fixed-step solver.
Mode changes cause the number and nature of the degrees of freedom of the system to change during the simulation. See Analyzing Degrees of Freedom following.
Because clutch mode changes are idealized events, they cause the system's dynamics (torques) to change abruptly, as static and kinetic friction switch roles. The switch occurs when one or more clutch pressures rises high enough to induce locking or falls low enough to induce unlocking.
In the default mode setting, mode iteration determines when clutches lock and unlock. Mode iteration consists of suspending the simulation time steps and repeatedly testing the locking and unlocking conditions for all the clutches simultaneously. You can turn this mode iteration off.
A fixed-step solver, unlike a variable-step solver, cannot adaptively reduce its step size to better resolve the system dynamics when clutches undergo mode changes. Instead, you need to make other changes to your model to compensate.
You exert dynamic control on the locking and unlocking of clutches through their input clutch pressure signals. The simplest way to force a locking is to abruptly change a clutch pressure from zero to some predetermined value. You can then force an unlocking by abruptly changing the clutch pressure back to zero. Such abrupt clutch pressure changes are not realistic, as discussed in Shaping Realistic Clutch Pressure Signals in the Simple Models chapter. The best solution is to model a full clutch actuator. However, you can use simplified models instead of a complex clutch simulation.
The important criterion is to make sure the clutch pressure signal rises and falls smoothly and not suddenly. The Simulink Sources library provides many ways to create such signals. You can also reshape existing signals using blocks such as State-Space and Transfer Fcn.
These demo models illustrate smoothed clutch pressure signals:
Staggering Multiple Clutch Signals. In multiclutch systems (transmissions) where multiple clutches lock and unlock together, you can further optimize your simulation by slightly staggering the clutch pressure signal changes. Slightly offset the rise or fall of each clutch pressure from the others in time, so that the clutches changing their modes together do not experience the dynamical discontinuities simultaneously.
You can adjust internal parameters within each Controllable Friction Clutch block to control when and how it locks and unlocks.
Changing the Pressure Threshold. The pressure signal coming into a clutch is dimensionless and normalized to 1 for a specified physical friction torque. You can also specify a pressure threshold Pth. This threshold imposes a cutoff on the clutch pressure such that the effective controlling pressure is P – Pth rather than P. If P < Pth, no pressure at all is applied.
Raising the threshold makes it harder for the clutch to engage. If you find a clutch in your simulation is engaging too easily, consider raising its pressure threshold. If the clutch has difficulty engaging, consider lowering the pressure threshold.
Changing the Velocity Tolerance. Each clutch has a velocity tolerance ωTol that controls when the clutch locks or unlocks.
A clutch locks if the relative shaft velocity ω lies in the range –ωTol < ω < ωTol.
A clutch unlocks if the virtual velocity ω, calculated while the clutch is locked but subject to external torques, lies outside the range –ωTol < ω < ωTol.
In default operation, the solver settings determine a value for ωTol. But you can also specify an ωTol value.
If the clutch is locking too easily, consider reducing the velocity tolerance. If the clutch has difficulty locking, consider increasing the velocity tolerance.
The Simulink documentation discusses the adjustment of the Simulink solvers in general.
With locking and unlocking clutches in your driveline simulation, the most critical mistake with Simulink solvers to avoid is excessively loose solver accuracy. If the variable-step tolerances are too large, the solver finds it difficult or impossible to accurately track the dynamical change associated with the change of friction torques acting on the driveline. If the fixed step size is too large, the solver cannot accurately resolve abrupt changes such as clutch lockings and unlockings.
If you encounter convergence failures or abrupt driveline state (velocity) changes at or around the instant of clutch mode changes, consider reducing the solver tolerances for a variable-step solver and the step size for a fixed-step solver.
In the default mode, the simulation suspends time-based steps and repeatedly tests if the clutches of your model should lock or unlock. This algebraic loop constitutes mode iteration.
You can turn off mode iteration for an entire driveline through its Driveline Environment dialog. The effect of turning mode iteration off is to spread the mode change calculation over multiple time steps, instead of concentrating it all at one time step. This change typically makes the simulation run somewhat faster but with some loss of accuracy.
With fixed-step solvers and in the generated code versions of SimDriveline models, mode iteration is disabled automatically. See the Driveline Environment and Controllable Friction Clutch reference pages for more details. See Generating Code following to learn more about generating code from SimDriveline models.
[1] Higham, D. J., and Higham, N. J., MATLAB Guide, Philadelphia, Society for Industrial and Applied Mathematics, 2000, Chapter 12.
A variety of errors can cause your SimDriveline simulation to stop before completion. Some of these errors arise from unphysical motions, actuations, and configurations of the driveline itself.
For an introduction to driveline torque and motion actuation, see Actuating Drivelines with Torques and Motions in the Simple Models chapter.
Analyzing and counting the driveline degrees of freedom (DoFs) are often essential to fixing simulation errors. For more about driveline DoFs, see Analyzing Degrees of Freedom following.
To run successfully, your driveline simulation must, throughout the simulation, have a positive number of independent DoFs. Furthermore, the model's DoFs must not conflict with each other.
If you encounter a simulation error where the driveline cannot move, check to see whether the number of independent DoFs is positive. If NDoF is not positive, you should:
Remove one or more constraining blocks, such as Gears, Clutches, or Housings
Remove one or more Motion Actuator blocks
Try one or both of these steps repeatedly until you locate the origin(s) of the simulation failure and make NDoF positive.
Consider also whether two or more DoFs are in conflict. For example, check whether two Motion Actuators are trying to move a single DoF in two different ways. Such a configuration creates a motion conflict and leads to a simulation error.
Faulty clutch and transmission configurations generate many driveline motion failures and usually arise from DoF conflicts and errors. Clutches impose conditional or dynamic constraints; see Constrained Degrees of Freedom in Analyzing Degrees of Freedom following.
To avoid or cure such problems, you should pay especially close attention to the collective mode state of your clutches, including clutches occurring inside transmission subsystems. The key to avoiding errors with transmissions is to work out and implement a complete and consistent clutch schedule. See Optimizing Clutch Mode Changes and Fixed-Step Solvers preceding and Combining Clutches and Gears into Transmissions in the Simple Models chapter.
It is easy to make these mistakes:
Locking too many clutches simultaneously, leading to redundant dynamic constraints and overconstrained (not enough) DoFs.
Locking conflicts among clutches, leading to nonredundant but still conflicting constraints.
Example: Locking one clutch locks one driveline axis to another. You could also lock the first driveline axis simultaneously to a third axis with another clutch. If the second and third axes cannot turn at the same velocity, these DoFs are in conflict.
Locking too few clutches simultaneously. Strictly speaking, this error does not overconstrain DoFs or put them in conflict. However, it typically puts a transmission into a state where it cannot transmit any torque or motion.
Like Motion Actuators, Initial Condition actuators can also cause motion conflicts. Unlike Motion Actuators, they do not impose constraints or remove DoFs from the driveline, because they act only at the start of the simulation. However, if you configure them incorrectly, Initial Condition actuators can cause errors when you begin the simulation.
Initial Condition actuators can conflict with one another.
Example: Suppose you couple two driveline axes through a Gear with a gear ratio of 2. The base axis must spin twice as fast as the follower, in the same direction. If you actuate the base with an initial velocity, and the follower cannot respond with half that velocity at the start of the simulation, the simulation stops with an error.
Initial Condition actuators can conflict with Motion Actuators. When the simulation starts, the velocity signal controlling a Motion Actuator and the initial velocity value specified by the Initial Condition actuator must agree, if they act on the same DoF. Analogous requirements hold for velocities transformed by gear couplings.
Regardless of how you set the initial conditions of your driveline axes, the complete set of initial conditions must be consistent with itself. Driveline connection lines satisfying angular velocity constraints (e.g., branched lines, lines in closed loops) must have the same initial angular velocities.
 | Using the Simscape Editing Mode | Analyzing Degrees of Freedom |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
