Objective Vehicle Dynamics Testing

Introduction

Objective vehicle dynamics testing has a key role in the development and assessment of a new vehicle. Testing activity is performed:

• Benchmarking and target setting

• Development

• Verification and validation

Objective testing is used more and more to correlate the simulation models to physical objects, which is a key factor to improve the accuracy of virtual prototyping.

For all these tasks it is very important to have reliable and accurate test results, in order to avoid mistakes in the design, development or (even worse) target-setting process. The application of ISO standards and robust legacy test procedures are good practices for the implementation of a reliable testing process. Each car maker or system supplier has its own procedures, which are the result of technical memory and specific know-how. Nevertheless, ISO standards are a widely accepted common basis of knowledge and recommendations, which are essential to get good test results. They also provide a “minimal” set of test manoeuvres to cover the main aspects of vehicle behaviour on lateral, longitudinal and cross-coupled (combined) dynamics, as shown in the picture above.

From each test type, vehicle dynamics engineers get a number of performance metrics, which allow making an objective picture of the vehicle’s behaviour under different testing conditions. Another key factor for test efficiency and reliability is the implementation of a test automation and validation system, which is the object of this application note.

General requirements (ISO 15037):

Measurement setup

Data acquisition system typical test setup for vehicle dynamics

• SIRIUS or

• DEWE-43A or

• any data acquisition device compatible with DS-IMU2 inertial measurement unit

Sensors

• DS-IMU2 (on CAN port)

• IMU from a competitor brand (on Analog Input)

• Optical speed and sideslip angle sensor (on Analog Input)

• Measurement of steering wheel (on Analog Input)

Software

• DewesoftX

• DS-IMU2 plugin

• Math channels

• Sequencer – Test cases

• Display and math setup

Analysis

Technical requirements

Getting reliable objective metrics is a matter of the proper application of testing procedures, high-quality sensors and measurement systems, a good driver, the ability to actuate commands almost like a robot in open loop test manoeuvres, as well as correct signal processing and data analysis. The table below summarizes the main measurement issues, mainly related to sensor and measurement system accuracy, and the main items for proper signal processing, taking into account filters, sensor position effects, and sensors-vehicle-road inclination effects

Typical measurement issues

• Slip angle accuracy (noise, drift, sensor position)

• Roll and pitch accuracy (drift)

• High dynamics

• Synchronization

• Narrow range accuracy

• Wide range accuracy

• GPS + IMU resolution & accuracy

General requirements (ISO 15037)

• Sensors and recorder accuracy, data acquisition, filtering, post-processing

• Compensation of sensor position for slip angle and velocity:
  Translation from the measurement point to the reference point (COG)

• Compensation of sensor position for acceleration:
  Translation from the measurement point to the reference point (COG)

• Compensation of gravitational effect (inclination):
  G-component due to body roll and pitch
  G-component due to ground inclination (roll and pitch)

These items will be shown by taking some data files as the case study, related to a benchmark test of DS-IMU2 vs. a competitor’s IMU performed by the company in Italy International at the proving ground of one of its Italian customers.

Filtering and synchronization

The first point is to manage different data sources: AI channels pass through anti-aliasing filters, so it is not possible to compare directly the competitor’s IMU signals vs. the DSIMU2. It is possible to apply similar filters to the digital channels from DS-IMU2, in order to have the same gain and phase shift as the AI. The result is shown below for the channel “yaw rate”, which does not require any further compensation. Then the channels from the optical sensor are translated forward in time to compensate for the delay of the internal filter (64ms in this case).

• Ref_YawRate: yaw rate from the competitor (reference) IMU on Al with anti-alias filter

• Angular_velocity_Z: yaw rate from the DS-IMU2 "as it is"!

• Angular_velocity_Z/IIRFilter: yaw rate from the DS-IMU2, filtered with a Dewesoft math filter

Translation of speed and sideslip angle 

The second step is to translate the slip angle from DS-IMU2 and from the optical sensor to the same evaluation point. After being translated forward, the channels from the optical sensor are synchronous with the other AIs, in particular with the output of the IMU. Then the slip angle and the velocity are translated from the sensor location to the evaluation point, using the angular rates from the IMU. DS-IMU2 data were translated to the same evaluation point using angular rates from the DS-IMU2 itself, without the need to synchronize them with each other. The result is shown in the picture on the right.

• Beta: sideslip angle from the optical sensor

• Slip_angle: sideslip angle from the DS-IMU2

• Beta_C: sideslip angle from the optical sensor shifted in time and Compensated

• (sensor position effect), i.e. translated to the evaluation point

• Slip_Angle_C/IIRFilter: sideslip angle from DS-IMU2 Compensated and filtered

Compensation for the inclination(gravitational) effect

Finally, the compensation of gravitational effect due to overall roll and pitch inclination is considered. In general, the problem has to be managed by the rotation matrix, which defines the orientation of the IMU relative to the earth's coordinate frame or to the ground. Yet, we can keep things simple if we assume to drive on a flat horizontal surface, and with small roll and pitch angles (due only to the motion of the vehicle’s body). In the case of lateral dynamic, we consider the compensation on Ay on a horizontal plane related to the Roll angle:

Here we are assuming an ISO-based reference system, with the X axis aligned to the mid-axis of the vehicle pointing forward, the Y axis pointing to the left and the Z axis pointing upward. The IMU axis rotates with the vehicle axis. The X’ (not shown) Y’ and Z’ axis follow only the vehicle rotation on the ground (horizontal) plane, but Z’ always points upwards and X’ and Y’ keeps on the horizontal plane. The roll angle lies between the YIMU and Y’ axis, equal to the angle between \Z_{IMU}\) and Z' axis.

The DS-IMU2 provides both the raw Ay and the “true” Ay, i.e. the lateral acceleration observed on the IMU Y axis and on the horizontal plane. Otherwise, the compensation can be calculated:

In practice, given a vehicle with a 4 deg/g roll stiffness, the amount of this compensation over the steady state lateral acceleration is about 7%. Notice that for passive chassis (i.e. roll angle on the opposite side of the curve radius) it is always negative, i.e. lateral acceleration on the horizontal plane is less than the acceleration sensed on the IMU Y axis. This is due to the fact that the accelerometer senses a component of lateral acceleration plus a component of g acceleration. Notice that the units are not the same: the DS-IMU2 output acceleration in [m/s2], while the output from the other IMU is in [g].

Test automation and validation

A test automation and validation tool is expected to deliver several key benefits both in the phase of preparation of the tests and in the phase of actual execution of the test manoeuvres on the track. The final goal for a testing department is to implement a more efficient and reliable test process, which definitely may lead to better test results with less effort. Here are some basic features of a vehicle dynamics test tool:

• Provide info to the driver about what to do, e.g. nominal test parameters (speed, frequency, etc.)

• Provide info to the driver about what he is doing, e.g. actual speed vs. nominal speed.

• Implement calculations to perform the test validity check

• Provide feedback to the driver about what was right or wrong in the test execution

• Provide feedback to the driver about what to do next, e.g. to repeat a test run or to switch to a different kind of test

• Implement calculations to get a preview of performance metrics on board, e.g. stopping distance, step response, etc.

The two steps, i.e. preparation and execution of the tests, are described in the pictures below.

The preparation phase in Dewesoft relies mainly on the project environment, where some suitable global variables are defined in order to store some key parameters related to vehicle properties and the sensor setup.

A number of predefined test cases may be enabled or disabled by the test engineer, according to the required test protocol. Furthermore, it is possible to add new test cases to cover new kinds of tests. Each test case references a sequence, which manages the test parameters and counters and provides instructions to the driver about what to do, step by step.

On the car, during the execution of the tests, the driver will see the messages coming from the sequencer and the meters or other visual controls defined in a test setup. Each sequence deals with a given test setup, which holds specific math channels to calculate parameters or metrics needed for the validation of the test execution vs. nominal conditions, e.g. speed, steering frequency, steering amplitude, etc. The sequence will provide information to the driver about how many valid tests he performed and when he can switch to another type of test.

Conclusion

In the first part of this note, some basic features that may help in day-by-day vehicle dynamics testing activity were highlighted. These items provide an answer to the main technical requirements asked by ISO test standards for vehicle dynamics:

• The use of Dewesoft filters and delay channel math to compare data from different sensors and sources (AI vs. CAN/plugin)

• The use of basic math formulas to compensate for the offset effect (i.e. location effect) of speed sensors and acceleration sensors

• How to deal with issues related to the body and/or road inclination in acceleration measurements with DSIMU2 and math channels

Finally, a test automation solution was introduced, conceived to actively support the driver during the execution of a predefined test session, including a validation check of each test run. This solution is based on test cases, sequences, and specific math setups, and it is expected to improve the effectiveness of vehicle dynamics testing to a noticeable degree.