Simulink® Modeling for Vehicle Simulator Design - Delphi

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

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 2. Simulink ® Model Distribution on to the
Targets
Opal-RT TestDrive [4] provides the most effective way to
implement a model-based approach to design vehicle
simulation. MATLAB-Simulink ® will allow us to quickly
create real-time simulations of dynamic systems and use them
throughout the design cycle - from initial concepts, to
controller design, test and validation using hardware-in-theloop
(HIL) testing.
The target system is a PC or cluster of PCs where the
simulation runs. The real-time requires a real-time operating
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.
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
2. Decoding of CAN messages from the ECU
3. Instrumentation support for reading and writing memory
through CAN calibration protocol (CCP) [2] and universal
calibration protocol (XCP) [3]
4. Support for periodic data acquisition (DAQ) and periodic
data stimulation (STIM) using CCP and XCP
5. Simulation of fault conditions to test the ECU
6. Simulation of diagnostic test tool to read diagnostic
trouble code (DTC)
7. Simulation of power waveform test tool

8. Replay CAN logs on target hardware for functional
verification
9. Test automation using python scripts
10. Message logger
1. NETWORK SIMULATION
Traffic data from the radar, yaw rate sensor, and vehicle
speed sensor are simulated by Simulink ® models.
The radar sensor transmits scan data through a set of CAN
messages periodically. Each set of messages is transmitted
sequentially and the sequence is repeated.
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
messages.
Figure 5. Scheduler on Simulation
Each message also has individual control to simulate missing
message fault diagnostics.
The ACC gets CAN messages from other ECUs such as the
engine management system (EMS), brakes control module
(BCM), transmission control module (TCM) and instrument
cluster (IC). The simulator model groups all these messages
based on the appropriate periodicity, with message triggering
accomplished through the Simulink ® pulse generator.
Messages can employee several methods to maintain data
integrity logic, through scan index, rolling count and
checksum calculations.
Figure 6. Network Simulation
Figure 7. Data Integrity using Rolling Count and
Checksum

Figure 8. Rolling Count on Simulation
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
THROUGH CAN CALIBRATION
PROTOCOL (CCP) AND UNIVERSAL
CALIBRATION PROTOCOL (XCP)
CAN calibration protocol (CCP) provide a set of commands
for instrumentation. Read- and-write memory operations are
achieved using UPLOAD and DOWNLOAD commands
respectively.
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 10. CCP Architecture
Figure 11. XCP Architecture
4. SUPPORT FOR PERIODIC DATA
ACQUISITION (DAQ) AND PERIODIC
DATA STIMULATION (STIM) USING
CCP AND XCP
Data acquisition (DAQ) is used to read non-contiguous
memory locations periodically.

Figure 12. DAQ Concept
In Simulink ® , the above concept has been implemented as
follows:
Figure 12a. Simulink ® Implementation of CCP and
DAQ
The Simulink ® model configures the ECU to send periodic
updates of memory (DAQ) through following CCP
commands.
1. SET_DAQ_PTR
2. WRITE_DAQ
3. START_STOP
Figure 12b. Timestamp Check
Figure 12c. Encoding values to DAQ buffer
Figure 12d. Decoding values front DAQ buffer
At this point ECU starts sending DAQ messages on CAN
bus. The simulator receives these messages.
The DAQ buffer update process is executed much faster
(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
CONDITIONS TO TEST THE ECU
Fault simulation can be achieved in the following ways:
1. Missing node faults - by stopping messages from
simulated nodes like ECM, BCM.
2. Missing Scan Fault - by stopping the update of the radar
scan index.
3. Rolling Count (RC) Fault - by stopping the rolling count
increment.
4. Checksum Value Fault - by calculating the wrong
checksum value for signals.
5. RC Sliding Window Fault - by sending m wrong RC
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 14. RC Sliding Window on Simulation
6. SIMULATION OF DIAGNOSTIC
TEST TOOL TO READ DIAGNOSTIC
TROUBLE CODE (DTC)
The diagnostic test tool sends a service request over the
vehicle CAN bus to diagnose the ECU.
Diagnostic requests can be of two types, namely
1. Physical diagnostic request
2. Functional diagnostic request
The simulator can be configured for global generic diagnostic
specification (GGDS) or non-GGDS type.
Figure 15. Diagnostics Test Tool
Depending on the configuration, the diagnostic request is sent
and the diagnostic response is processed.
The diagnostic response bytes are stored in a buffer based on
the frame index of the response.

Figure 16. Handling of Multi-frame
Figure 17. Decoding DTCs
The faults are simulated from the simulator by various
methods such as stopping messages, sending messages with
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 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
As the vehicle control algorithms for various features of
adaptive cruise control grows more complex, simulation of
all real-time scenarios to validate ECU functionality is not
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 20. Python Scripting Window
10. MESSAGE LOGGER
The Simulink ® model sends raw CAN frames directly to the
host PC through TCP/IP. The message logger decodes and
displays the messages along with their description. This helps
in monitoring CAN traffic for debugging.
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
power waveforms to which the ECU is being exposed and the
performance is analyzed.
REFERENCES
1. MATLAB - Simulink ® Reference & User Guide (http://
www.mathworks.com/)
2. CCP_V2.1.pdf (http://www.asam.net/)
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
Chandrakantha Ursu, M.S.
Specialist
Independent Test & Verification - Active Safety
Delphi Automotive Systems Pvt. Ltd
Technical Centre India
Kalyani Platina, Block 1, No 24
EPIP Zone Phase II, Whitefield
Bangalore - 560066, India
Phone: 91 80 30777595
chandrakantha.ursu@delphi.com
Ramachandra Bhat K, M.S.
Systems Engineer - Active Safety
Delphi Automotive Systems Pvt. Ltd
Technical Centre India
Kalyani Platina, Block 1, No 24
EPIP Zone Phase II, Whitefield
Bangalore - 560066, India
Phone: 91 80 30777801
ramachandra.bhat@delphi.com
Ramkumar Damodaran, B.E.
Technical Leader
Independent Test & Verification - Active Safety
Delphi Automotive Systems Pvt. Ltd
Technical Centre India
Kalyani Platina, Block 1, No 24
EPIP Zone Phase II, Whitefield
Bangalore - 560066, India
Phone: 91 80 30777689
ramkumar.damodaran@delphi.com
DEFINITIONS/ABBREVIATIONS
ACC
A2L
BCM
CAN
CCP
DAQ
Adaptive Cruise Control
ASAM MCD 2MC/ASAP2 standard
Brake Control Module
Controller Area Network
CAN Calibration Protocol
Data Acquisition
DLC
DTC
ECM
ECU
GUI
HIL
IC
I/O
PC
Data Length Code
Diagnostic Trouble Code
Engine Control Module
Electronic Control Unit
Graphical User Interface
Hardware In the Loop
Instrument Cluster
Input/Output
Personal Computer
PWTT
Power Waveform Test Tool
QNX
Unix-like real time operating system
RADAR
Radio Detection And Ranging
RC
Rolling Count
RTOS
Real Time Operating System
STIM
Data Simulation
TCP/IP
Transmission Control Protocol/Internet Protocol

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