Application note shows how Dewesoft products may provide effective solutions for vehicle dynamics testing, offering an answer to technical requirements as well as to the increasing demand of effectiveness of the testing process. These goals can be achieved by Dewesoft hardware and software features. Furthermore, by the combination of global variables, test cases, and sequences, display and math setups, it is possible to build a customized test environment to manage tests, support the driver during the execution, and to validate each test run.
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
- Verification and validation
Objective testing is used more and more to correlate simulation model to the 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 maneuvers to cover the main aspects of vehicle behavior 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 behavior under different testing conditions. Another key factor for test efficiency and reliability is the implementation of a test automation and validation system, which is in the object of this application note.
General requirements (ISO 15037):
Typical standard and custom testsPerformance evaluation items
|Constant radius (ISO 4138)||Under/Oversteering|
|Slow increasing steer (ECE 13H)||Body motion, tail, pitch|
|Steep steer (ISO 7401)||Transient response|
|Frequency sweep sine (ISO 7401)||Steering effort|
|On center sine (ISO 13674-1)||On center feeling|
|Power on / power off reaction in a turn||Agility vs. stability|
|Lane change (ISO 3888, VDA, ADAC, ...)||Trajectory|
|ABD or emergency braking (ISO 21994)||Path deviation|
|Low-speed handling (parking)||Stopping distance|
DATA ACQUISITION SYSTEM Typical test setup for vehicle dynamics
- DS-IMU2 (on CAN port)
- IMU from a competitor brand (on Analog Input)
- Optical speed and sideslip angle sensor (on Analog Input)
- Measurement steering wheel (on Analog Input)
- Dewesoft X
- DS-IMU2 plugin
- Math channels
- Sequencer – Test cases
- Display and math setup
Getting reliable objective metrics is a matter of the proper application of testing procedures, high quality sensors and measurement system, a good driver, able to actuate commands almost like a robot in open loop test maneuvers, 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 a 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
- 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 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 AI’s, 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 of 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 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:
Ay_IMU = Ay_HOR*cos(Roll) + g*sin(Roll)
Az_IMU = -Ay_HOR*sin(Roll) + g*cos(Roll)
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. Roll angle lies between the Y_IMU 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:
ΔAy_g_roll = g * sin(Roll) ≈ g * Roll (1st order approximation for small roll angle), with Roll in [rad]
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 maneuvers on the track. The final goal for a testing department is to implement a more efficient and more 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 by 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 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 kind of tests. Each test case references a sequence, which manages the test parameters and counters and provides instruction 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.
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 the offset effect (i.e. location effect) of speed sensors and acceleration sensors
- How to deal with issues related to 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 at a noticeable degree.