Simulink® Modeling for Vehicle Simulator Design 2011-01-0746

Published
04/12/2011

Chandrakantha Ursu , Ramachandra Bhat and Ramkumar Damodaran

Delphi Automotive Systems Ltd

Copyright © 2011 SAE International

doi:10.4271/2011-01-0746

simulation of fault conditions to test the ECU, simulation of

ABSTRACT diagnostic test tool to read diagnostic trouble codes (DTC),
As demand grows for new in-vehicle features, a large number simulation of power waveform test tool, replay vehicle logs
of electronic control modules are being introduced in the on the hardware.
automobile to increase passenger's comfort, safety,
entertainment and overall performance. The performance The simulator is used to test the ECU in a laboratory,
parameters of features such as electronic power steering, simulating the conditions that would occur if the ECU was in
engine management systems, anti-lock braking systems, the vehicle and exposed to real driving scenarios. Real time
airbag systems, transmission systems, navigation and Vehicle logs can be replayed back on the ECU. When
entertainment systems are monitored and controlled by performing in-vehicle testing, testers must provide diagnostic
electronic control units (ECUs). Vehicle level ECU testing services to read the fault and instrumentation tools to re-flash
for small hardware or software changes is not practical and it the software. In-vehicle tests also must account for battery
is expensive. Therefore, bench level testing is an effective supply variations, necessary diagnostics and have
way to ensure ECU functionality, as long as the tester is able comprehensive vehicle logs to ensure test repeatability.
to effectively simulate vehicle conditions during the bench MATLAB -Simulink® modeling can be used to simulate all
test. such scenarios. This article explains simulation of
functionalities mentioned above, using MATLAB -Simulink®
Bench level testing involves use of either static or model.
programmable simulators to simulate the required
functionalities. The programmable simulator is generally a INTRODUCTION
better tool than the static simulator because it is configurable.
This paper gives an overview of how MATLAB -Simulink® Simulink® [1] provides an environment for simulation and
model can be used to configure a programmable vehicle model-based design for dynamic and embedded systems.
simulator. Simulink® is a powerful modeling tool that Simulink® is integrated with MATLAB®, providing
provides an efficient way of simulating the system under immediate access to an extensive range of tools that helps to
design. The modeled system can be converted into an develop algorithms, analyze and visualize simulations. The
executable which can be deployed on to the target hardware modeled system can be tested using simulation, reducing the
(simulator) and can be run in real time. number of hardware versions required to design the system.

This paper explains about how to configure the vehicle

simulator for various functionalities using MATLAB -
Simulink® model. This paper focuses on the following
functionalities: vehicle interface, instrumentation support,
supporting of periodic data acquisition (DAQ) using CCP
(CAN calibration protocol) and XCP (universal calibration
protocol), periodic data stimulation (STIM) using XCP,
 Figure 1. Autocoding of Simulink® Model

A similar principle is also applicable for designing the

vehicle simulator used to test automotive electronic controller
units (ECU). The vehicle simulators used to simulate an
automotive environment that can be designed using
Simulink®. The simulated model can be autocoded using real
time workshop and then built into an executable using C
compiler to run on real time operating system. Figure 3. Test Bench Setup

This paper illustrates the vehicle simulator for an adaptive

cruise control (ACC) system. A radar scans the road traffic
conditions and sends this information on the CAN bus. These
CAN messages are used by the ACC to perform vehicle
control actions (such as braking and accelerating) depending
on the road traffic conditions.

MATLAB-SIMULINK® BASED
VEHICLE SIMULATION
Using a MATLAB - Simulink® model, various simulations
can be performed to verify any ECU functionality at bench
level. This paper explains the following simulations:

1. Network simulation
Figure 2. Simulink® Model Distribution on to the 2. Decoding of CAN messages from the ECU
Targets
3. Instrumentation support for reading and writing memory
through CAN calibration protocol (CCP) [2] and universal
Opal-RT TestDrive™ [4] provides the most effective way to calibration protocol (XCP) [3]
implement a model-based approach to design vehicle
simulation. MATLAB-Simulink® will allow us to quickly 4. Support for periodic data acquisition (DAQ) and periodic
create real-time simulations of dynamic systems and use them data stimulation (STIM) using CCP and XCP
throughout the design cycle - from initial concepts, to 5. Simulation of fault conditions to test the ECU
controller design, test and validation using hardware-in-the-
loop (HIL) testing. 6. Simulation of diagnostic test tool to read diagnostic
trouble code (DTC)
The target system is a PC or cluster of PCs where the
simulation runs. The real-time requires a real-time operating 7. Simulation of power waveform test tool
system (RTOS) such as QNX. The target system allows us to
perform model compilation and real-time execution, as well
as scheduling any signal I/O hardware for HIL applications.
8. Replay CAN logs on target hardware for functional Each message also has individual control to simulate missing
verification message fault diagnostics.
9. Test automation using python scripts
The ACC gets CAN messages from other ECUs such as the
10. Message logger engine management system (EMS), brakes control module
(BCM), transmission control module (TCM) and instrument
1. NETWORK SIMULATION cluster (IC). The simulator model groups all these messages
Traffic data from the radar, yaw rate sensor, and vehicle based on the appropriate periodicity, with message triggering
speed sensor are simulated by Simulink® models. accomplished through the Simulink® pulse generator.

The radar sensor transmits scan data through a set of CAN Messages can employee several methods to maintain data
messages periodically. Each set of messages is transmitted integrity logic, through scan index, rolling count and
sequentially and the sequence is repeated. checksum calculations.

Figure 4. Message Scheduler

Figure 4 shows the simulation of sequences used for

scheduling radar messages. Each pulse is separated from
other by 2msec. Each of these pulses will trigger set of CAN Figure 6. Network Simulation
messages.

Figure 7. Data Integrity using Rolling Count and

Checksum

Figure 5. Scheduler on Simulation

 Figure 8. Rolling Count on Simulation

Figure 10. CCP Architecture

Figure 9. Radar Scan Index on Simulation

2. DECODING OF CAN MESSAGES

FROM THE ECU
Decoding of CAN messages is automated in the model with
the help of CAN database.

3. INSTRUMENTATION SUPPORT FOR

READING AND WRITING MEMORY Figure 11. XCP Architecture
THROUGH CAN CALIBRATION
PROTOCOL (CCP) AND UNIVERSAL 4. SUPPORT FOR PERIODIC DATA
CALIBRATION PROTOCOL (XCP) ACQUISITION (DAQ) AND PERIODIC
CAN calibration protocol (CCP) provide a set of commands DATA STIMULATION (STIM) USING
for instrumentation. Read- and-write memory operations are
achieved using UPLOAD and DOWNLOAD commands CCP AND XCP
respectively. Data acquisition (DAQ) is used to read non-contiguous
memory locations periodically.
Universal measurement and calibration protocol (XCP) offers
synchronous data transfer in both directions, from master
(simulator) to slave (ECU) and from slave to master. XCP
protocol uses transportation layers like CAN, TCP/IP, UDP/
IP and USB.

This Simulink® model uses TCP/IP as a transport layer for

XCP to verify ACC algorithms which involves processing of
huge amount of data.
 Figure 12. DAQ Concept

Figure 12b. Timestamp Check

In Simulink®, the above concept has been implemented as
follows:

Figure 12c. Encoding values to DAQ buffer

Figure 12a. Simulink® Implementation of CCP and

DAQ

The Simulink® model configures the ECU to send periodic

updates of memory (DAQ) through following CCP Figure 12d. Decoding values front DAQ buffer
commands.

1. SET_DAQ_PTR At this point ECU starts sending DAQ messages on CAN

bus. The simulator receives these messages.
2. WRITE_DAQ
The DAQ buffer update process is executed much faster
3. START_STOP
(4ms) than the minimum DAQ period (20ms) and hence
needs to check for the new timestamp to avoid duplication of
data in DAQ buffer.

This is achieved by comparing the current timestamp with the

last stored timestamp.
5. SIMULATION OF FAULT 6. SIMULATION OF DIAGNOSTIC
CONDITIONS TO TEST THE ECU TEST TOOL TO READ DIAGNOSTIC
Fault simulation can be achieved in the following ways: TROUBLE CODE (DTC)
1. Missing node faults - by stopping messages from The diagnostic test tool sends a service request over the
simulated nodes like ECM, BCM. vehicle CAN bus to diagnose the ECU.
2. Missing Scan Fault - by stopping the update of the radar
scan index. Diagnostic requests can be of two types, namely
3. Rolling Count (RC) Fault - by stopping the rolling count 1. Physical diagnostic request
increment.
2. Functional diagnostic request
4. Checksum Value Fault - by calculating the wrong
checksum value for signals. The simulator can be configured for global generic diagnostic
5. RC Sliding Window Fault - by sending m wrong RC specification (GGDS) or non-GGDS type.
frames out of n.

Sliding window logic is achieved using the Simulink® pulse

generator with varying duty cycles.

Figure 13. Sliding Window for Rolling Count

Figure 15. Diagnostics Test Tool

Depending on the configuration, the diagnostic request is sent

and the diagnostic response is processed.

Figure 14. RC Sliding Window on Simulation The diagnostic response bytes are stored in a buffer based on
the frame index of the response.
 error signals set, etc. The ECU sets the diagnostic trouble
codes (DTC) for each fault. These fault conditions can be
read from the diagnostic services. Since the ECUs support
30-50 different DTCs, this information has to be transmitted
in multiple CAN frames. Since each frame of the DTC
response is transmitted from the ECU, the Simulink® model
samples these messages and then stores it in buffers.

7. SIMULATION OF POWER
WAVEFORM TEST TOOL
In the vehicle environment, the ECU is subjected to power
variations and it is very important to know how the ECU's
functionality will be affected by such conditions. The
Simulink® model helps in generating different types of power
waveforms.

Figure 16. Handling of Multi-frame

Figure 18. Power Waveform Test Setup

Here the requirement is to generate different types of

waveforms. Using the block as follows, different kinds of
waveforms can be generated that will drive the programmable
power supply.

8. REPLAY CAN LOGS ON TARGET

HARDWARE FOR FUNCTIONAL
VERIFICATION
Figure 17. Decoding DTCs As the vehicle control algorithms for various features of
adaptive cruise control grows more complex, simulation of
The faults are simulated from the simulator by various all real-time scenarios to validate ECU functionality is not
methods such as stopping messages, sending messages with always possible.
 Figure 18a. PWTT Simulation

Figure 18b. Portion of PWTT Block

Figure 18c. Various PWTT Waveforms

 Figure 19a. Data Playback Setup

Figure 19b. Data logged during playback using DAQ feature of CCP

Figure 19c. Vehicle braking and Vehicle Speed in

response to Brake
CAN message logs collected from the vehicle are transmitted
back to the ECU by Simulink® model in real time to verify
the functionally of vehicle control algorithms. During this
activity, the Simulink® model monitors software variables in
the ECU via the DAQ feature of CCP. Symbol information
parameters are read from an A2L file by a python script and
passed to the model.

9. TEST AUTOMATION USING

PYTHON SCRIPTS
Verification of functional test procedures can be automated
with the help of python scripts which establish required
values for Simulink® signals. A set of library modules is
developed with various functions that can be called from
python scripts and can be reused across multiple programs.

Figure 21. Message Logger GUI

SUMMARY/CONCLUSIONS
Using Simulink®, the time required for vehicle simulator
modeling can be reduced drastically. Simulation logic can be
verified before running on target and can be separated from
low level device drivers, making the model less dependent on
the simulator. In this paper, Simulink® is used to build a
Vehicle Simulator Model containing basic functionalities for
effectively testing the ECU, which can be configured based
on the tests required to be performed. With this
programmable simulator, ECU is exposed to real world
driving scenarios in a laboratory environment with the test
cases being written through Python automated scripts. Real
world data in terms of vehicle logs can also be replayed back
into ECU and performance of various software algorithms
can be easily verified. The model simulates different kinds of
Figure 20. Python Scripting Window power waveforms to which the ECU is being exposed and the
performance is analyzed.

10. MESSAGE LOGGER REFERENCES

The Simulink® model sends raw CAN frames directly to the
1. MATLAB - Simulink® Reference & User Guide (http://
host PC through TCP/IP. The message logger decodes and
www.mathworks.com/)
displays the messages along with their description. This helps
2. CCP_V2.1.pdf (http://www.asam.net/)
in monitoring CAN traffic for debugging.
3. ASAM_XCP_Part1-Overview_V1.0.0.pdf (http://
www.asam.net/)
4. Opal-RT TestDrive™ Manual (http://www.opal-rt.com/
product/testdrive) MATLAB - Simulink® is a Registered
Trademark of Math Works, Inc. TestDrive™ is a Registered
Trademark of Opal-RT Technologies.
CONTACT INFORMATION DLC
Data Length Code
Chandrakantha Ursu, M.S.
Specialist DTC
Independent Test & Verification - Active Safety Diagnostic Trouble Code
Delphi Automotive Systems Pvt. Ltd
Technical Centre India
Kalyani Platina, Block 1, No 24 ECM
EPIP Zone Phase II, Whitefield Engine Control Module
Bangalore - 560066, India
Phone: 91 80 30777595 ECU
[email protected] Electronic Control Unit

Ramachandra Bhat K, M.S.

Systems Engineer - Active Safety GUI
Delphi Automotive Systems Pvt. Ltd Graphical User Interface
Technical Centre India
Kalyani Platina, Block 1, No 24 HIL
EPIP Zone Phase II, Whitefield Hardware In the Loop
Bangalore - 560066, India
Phone: 91 80 30777801
[email protected] IC
Instrument Cluster
Ramkumar Damodaran, B.E.
Technical Leader I/O
Independent Test & Verification - Active Safety Input/Output
Delphi Automotive Systems Pvt. Ltd
Technical Centre India
Kalyani Platina, Block 1, No 24 PC
EPIP Zone Phase II, Whitefield Personal Computer
Bangalore - 560066, India
Phone: 91 80 30777689 PWTT
[email protected] Power Waveform Test Tool

DEFINITIONS/ABBREVIATIONS QNX
Unix-like real time operating system
ACC
Adaptive Cruise Control
RADAR
Radio Detection And Ranging
A2L
ASAM MCD 2MC/ASAP2 standard
RC
Rolling Count
BCM
Brake Control Module
RTOS
Real Time Operating System
CAN
Controller Area Network
STIM
Data Simulation
CCP
CAN Calibration Protocol
TCP/IP
Transmission Control Protocol/Internet Protocol
DAQ
Data Acquisition
 XCP
Universal Measurement and Calibration Protocol

UDP/IP
User Datagram Protocol/Internet Protocol

USB
Universal Serial Bus

The Engineering Meetings Board has approved this paper for publication. It has Positions and opinions advanced in this paper are those of the author(s) and not
successfully completed SAE's peer review process under the supervision of the session necessarily those of SAE. The author is solely responsible for the content of the paper.
organizer. This process requires a minimum of three (3) reviews by industry experts. SAE Customer Service:
Tel: 877-606-7323 (inside USA and Canada)
All rights reserved. No part of this publication may be reproduced, stored in a
Tel: 724-776-4970 (outside USA)
retrieval system, or transmitted, in any form or by any means, electronic, mechanical, Fax: 724-776-0790
photocopying, recording, or otherwise, without the prior written permission of SAE. Email: [email protected]
ISSN 0148-7191 SAE Web Address: http://www.sae.org
Printed in USA