Optimizing Vehicle Suspension Design Through System-Level Simulation

By Brad Hieb and Vijayalayan R, MathWorks

Optimizing vehicle ride quality and handling performance involves balancing multiple competing design objectives. For example, to reduce vibrations in the frequency range that causes driver discomfort, engineers need to reduce suspension stiffness. On the other hand, to keep the suspension deflection within acceptable limits, they may need to increase suspension stiffness. Evaluating such tradeoffs can be time-consuming and costly when suspension designs are tested on prototype vehicles.

One way to reduce the costs and delays associated with physical prototypes is to develop a system-level model and run simulations to optimize the design. This approach enables chassis engineers to find initial values for key design parameters early in the development process. These initial values make it possible to evaluate early-stage program decisions. Further, they significantly reduce the number of iterations based on physical prototypes required and serve as a good starting point for more detailed simulations of higher-fidelity models.

This article describes a workflow that uses system-level simulation to optimize a vehicle suspension system design. The workflow is based on a quarter car model of the vehicle built with Simulink® and Simscape™.

Why System-Level Simulation?

In a traditional workflow (Figure 1) a test vehicle is built from the specification. Engineers test the vehicle’s performance on the road and in the lab, evaluate the test results, and modify the design to improve performance. These steps are repeated multiple times in an iterative process until the vehicle meets its design objectives.

Figure 1. Flow diagram for a traditional vehicle design process.

The primary drawbacks of a traditional approach are the cost and time required to build prototypes for each iteration. The build-and-test cycle makes it difficult to predict how long it will take to complete the entire design process. Further, lengthy iterations make it impractical to explore all design configurations, so there is a good chance that the final vehicle design may not be optimal.

In the system-level simulation approach (Figure 2), engineers use simulation to refine the specification before building a physical test vehicle.

Figure 2. Flow diagram for a design process using system-level simulation.

This model may be a modified version of a fully validated model from a previous vehicle development program. Engineers run simulations with this system-level model to verify performance against requirements and to optimize tunable parameters. Once the design meets the performance requirements, the workflow follows the iterative steps used in the traditional approach. Because the design was optimized early through simulation, fewer prototypes are required, saving time and reducing costs.

The system-level model, once validated with results from final verification of the vehicle, can be reused in future vehicle development programs. System-level models can also be used to supplement vehicle verification testing. They are particularly valuable for vehicles with many configurations, where it is impractical to test all possible configurations or where testing is difficult or dangerous to perform.

Creating a Physical Model of a Simple Mass-Spring-Damper System

Reliable results can only be obtained from a system-level simulation when the model accurately represents the actual system behavior. There are several ways to derive a model, ranging from first principles modeling to data-driven modeling (Figure 3). The approach used will depend on factors such as the availability of test data and understanding of the underlying physics.

Figure 3. Modeling approaches.

In our example we will use a physical network approach based on Simscape. Simscape makes it easy to model physical systems because you only need to define how the physical components of a system are connected to each other. It is not necessary to derive and implement equations governing the behavior of the entire system. Simscape automatically formulates the equations for the physical network. This approach facilitates rapid design iteration and exploration, leading to optimized designs and improved understanding of how physical design parameters affect system behavior.

To illustrate the physical network approach, we begin by modeling a simple mass-spring-damper system using the mass, spring and damper blocks provided by the Simscape Foundation Library (Figures 4a and 4b).

Figure 4a. A simple mass-spring-damper system.
Figure 4b. Simscape model of the system.

We run simulations to visualize how the mass will react to a force applied as a step input (Figure 4c).

Figure 4c. Simulation results showing the mass-spring-damper system’s response to a 10-Newton force applied as a step input.

For some systems, it may be necessary to model components with nonlinear properties—for example, if the damper has a damping coefficient that varies with velocity. We can use the Simscape language to create a custom Translational Damper block that reflects this nonlinearity:

component LUT_damper < foundation.mechanical.translational.branch
% Translational Damper
% The block represents an ideal mechanical translational viscous damper. 
% Connections R and C are mechanical translational conserving ports, 
% with R representing the damper rod, while C is associated with the
% damper case. The block positive direction is from port R to port C. 

% Copyright 2005-2008 The MathWorks, Inc.
      D = {100, 'N*s/m'};    % Damping coefficient:left
    f == D*v;


Building the System-Level Quarter Car Model

We extend the basic mass-spring-damper system model by adding components to represent the tire dynamics and the road surface (Figure 5).

Figure 5. Quarter Car model created using Simscape.  

We model different types of road surfaces and provide an option to select the desired road surface using a multiport switch block. After selecting the desired road surface for the testing, we simulate this model, and analyze the acceleration, velocity, and displacement of the sprung mass.

Optimizing the System-Level Model

Combining the quarter car model with road models gives us a system-level vehicle model that we can use to optimize the vehicle suspension design. Our goal is to suppress vibrations within the 4Hz–8Hz frequency range while keeping suspension travel within set limits. To do so we need to tune suspension design parameters, such as the damping coefficient and spring stiffness. Manually tuning these parameters is a very time consuming task.

This process can be automated using Simulink Design Optimization™ which provides interactive tools and functions to automatically tune design parameters until simulation results meet design objectives such as improved system performance and minimized energy consumption. In the Design Optimization tool we can set the suspension deflection limits by selecting the Simulink signal from the model that measures the deflection and graphically specifying the limits for the signal, which are the constraints for the optimization problem. After defining the constraints, we can select the design parameters to optimize from the Simscape model and tune those parameters using numerical optimization techniques available in the tool.

Because the deflection and comfort need to be optimized across different road surfaces, the road surface type is treated as an uncertain parameter. This type of parameter is varied by the optimization algorithm to expand the number and type of simulation scenarios used during the optimization, but it is not tuned by the algorithm.

Since the primary design requirement is to minimize the amplitude of the sprung mass acceleration signals lying in the frequency 4 Hz–8 Hz we create a custom cost function in MATLAB®:

function out = SuspnComfort(data)
global BPSpec BPFilt

if isempty(BPFilt)
    %Create a bandpass filter to focus on the 'comfort' frequency range
    A_stop1 = 60;    %        Attenuation in the first stopband = 60 dB
    F_stop1 = .1;    %                     Edge of the stopband = .1 Hz
    F_pass1 = 2;     %                     Edge of the passband = 2 Hz
    F_pass2 = 8;      %             Closing edge of the passband = 8 Hz
    F_stop2 = 100;   %              Edge of the second stopband = 100 Hz
    A_stop2 = 60;    %       Attenuation in the second stopband = 60 dB
    A_pass = 1;      % Amount of ripple allowed in the passband = 1 dB
    BPSpec = ...
        fdesign.bandpass('Fst1,Fp1,Fp2,Fst2,Ast1,Ap,Ast2', ...
        F_stop1, F_pass1, F_pass2, F_stop2, A_stop1, A_pass, ...
        A_stop2, 1000);
    BPFilt = design(BPSpec);

%Filter the Suspension Acceleration
Sig = data.Uncertain.MsAcc;
%Sig = data.Nominal.MsAcc;
t = Sig.Time;
y = Sig.Data;
Ts = 1/BPSpec.Fs;
tn = min(t):Ts:max(t);
yn = interp1(t,y,tn);
yf = filter(BPFilt,yn);

%Compute energy in filtered signal
yf2 = yf.^2;
out = 0.5*diff(tn)*(yf2(2:end)+yf2(1:end-1))';

%figure(1), plot(tn,yn,tn,yf), title('MsAcc, MsAcc(filtered)')

This function uses a bandpass filter from Signal Processing Toolbox™ to filter sprung mass acceleration signals within the specified frequency range and ignore signals outside it. The cost function computes the energy of the filtered signal and returns this value as its output.

Having defined the custom cost function as the value to minimize, we start the optimization process.

The model is simulated repeatedly with different values for the spring stiffness and damping coefficient. We track the optimization progress via plots of the cost function output and the deflection amplitude (Figure 6).

Figure 6. Optimization results: deflection amplitude (top center), and cost function output for each iteration (top right).

At the end of the process, Simulink Design Optimization reports the values for the spring stiffness and damping coefficient that will minimize vibration and maximize passenger comfort.

With just two parameter values to tune, this optimization problem took about eight minutes to run on a single-core processor. More complex optimization problems with additional tunable parameters can be run in parallel on multiple computing cores using Parallel Computing Toolbox™.

Published 2015 - 92282v00