2019 5th International Conference for Convergence in Technology (I2CT)
Pune, India. Mar 29-31, 2019
Automated Testing of Faults of an Automotive
System
Akanksha Varshney
M.Tech, Department of Electrical Engineering
National Institute of Technology
Jamshedpur, India
akankshavarshney20@gmail.com
Dr. K. Namrata
Associate Professor, Department of Electrical Engineering
National Institute of Technology
Jamshedpur, India
namrata.ee@nitjsr.ac.in
Abstract— This paper describes an automated method to
test the Diagnostic Trouble Code (DTC) life-cycle of an
Automotive Electronic Control Unit (ECU) using the VT
System as hardware in loop and accessing it using the CAN
Access Programming Language (CAPL). Faults will be
inserted as per the output load specifications using the inputs
and outputs of the VT System to create various test scenarios.
Interfaces that connect hardware parts in the testing
configuration, also enable the data exchange and
communication between the isolated software of VT System
and ECU. This configuration has been simulated in CANoe
software implementing most of the real time constraints and
adding functionalities to make the testing framework more
efficient. The self-generated test report provides an overview
of the passing or failure status of the testing performed with
the triggered DTCs.
Keywords—ECU; CAPL; DTC; CAN; VT System
I. INTRODUCTION
The quest to satisfy the ever-increasing demand for
automotive safety, reliability, comfort and efficiency has
increased the complexity of an automotive network. This
further led to the requirement of extensive testing and
validation of Electronic Control Units (ECUs). Hence,
significant amount of time and efforts are needed to develop
these embedded devices as functionally reliable modules [1-
2]. While testing in the integrated test environment, the test
system should be able to generate various test conditions to
record the functional behavior of an ECU during the normal
and failure mode. Extensive tests under these conditions are
especially important, because their detection is difficult and
testing them in the later phases of development may
increase the cost [3]. Testing the functionality under normal
condition requires analyzing the response of the ECU’s
actuator output while varying the sensor input. During the
failure mode, test system requires additional components to
simulate fault cases along with switching load and sensors
[4].
To ensure all the interfaces of ECU work exactly as
expected requires immense amount of validation and
verification. This emphasizes the need for automated testing
which involves the verification of test requirements,
development of test scripts and their execution by
automated testing tools [5]. It reduces the duration of testing
cycles, manual errors. Also helps in quick analysis of
978-1-5386-8075-9/19/$31.00 ©2019 IEEE
Authorized licensed use limited to: Tsinghua University. Downloaded on July 06,2022 at 07:58:29 UTC from IEEE Xplore. Restrictions apply.
Mr. Sanjay Joshi
Deputy General Manager, Advance Product Creation
Tata Motors Limited
Pune, India
joshi.sanjay@tatamotors.com
parameter changes and reduces cost by increasing error
detection efficiency [6-7]. VT System is one such modular
Hardware in Loop (HIL) system which integrates all the
required components needed for simulation and creates a
suitable test environment by interfacing system hardware
with the ECU [8]. The sensors and actuators are simulated
electronically using different VT modules to produce as
many fault patterns as possible within a short period of time.
This environment can replicate the dynamic behavior of
vehicle, reduce the time span of analysis and development,
and eradicate the requirement of using expensive real
developmental/Proto vehicles for testing purposes [9].
Fig.1: Hardware simulation through VT System [10]
II. SIMULATION OF FAULT SITUATIONS
The correct functioning of vehicle components and
systems is defined in the appropriate design specifications.
Typically, these specify that for a given set of inputs or
actions, there will be certain outputs or reactions. There may
be tolerances applied to the input and output sets. Any
output parameter within this band is considered as correct
operation. A fault is any deviation from the specified
operation of the component or system for specified set of
inputs. The effects of the fault may be directly visible to the
vehicle user (e.g. engine does not start) or indirectly visible
(e.g. high fuel consumption). These may be trivial (e.g.
temporary loss of communications) or important (e.g.
malfunction of a crash detection sensor) [11]. Whenever the
ECU detects any fault in the system, ECU either provides
visual indications in terms of tell-tale and/or stores specific
fault code called the Diagnostic Trouble Codes (DTCs) in
its memory. These specific faults shall be monitored in all
1
the applicable ECUs. These DTCs can be later extracted Faults created can be verified by reading DTCs
from the memory of the ECU using implemented protocol stored in the ECU fault memory.
like ISO-14229-1, ISO-14230 etc. which help in
determining the cause of a fault [12-13].
To achieve reliability of systems, it is equally important
that the ECUs should react properly in response to the fault
conditions [14]. It is therefore important to simulate all
possible fault scenarios such as:
1. Failure of electrical wiring (e.g. short circuit to
battery, short circuit to ground, open circuit)
2. Failure in sensors or actuators
3. Incorrect input values
4. Switch Stuck
To automate testing of above fault scenario we need to
link the different diagnostic parameters, fault memory,
input/output configurations of the ECU pins and the
parameter specifications. Based on this information, a
suitable HIL module can be configured for respective Fig. 2: System Design of the Testing Environment
failure scenario of ECU pin. Inputs / Outputs of HIL
systems need to be calibrated in a way to generate different
fault states like fault not present, fault present, fault
removed. Fault memory tests can be verified with above
fault scenarios. The input/output of the ECU are simulated
through the HIL System. HIL system I/O are controlled by
the configurable parameter values which in response trigger
an error situation for respective I/O of ECU.

III. CREATING A TEST ENVIRONMENT

Testing the functional behaviour of an ECU through
simulation has the following requirements:
1. Using simulated components for simulation of
sensors or actuators.
2. Using relays or switches for establishing
connections and for creating faults.
3. Measurement of voltage and current at an output pin
of ECU.
Further, in order to validate the DTC status, following
specific setting conditions must be known:
1. ECU pin type (input or output; network; sensor or
actuator).
2. Parameter Specification (e.g. voltage and current
range).
3. Error Pattern (e.g. short circuit to ground/battery,
voltage above/below threshold, implausible
values).
Depending on the error pattern, additional information may
be required (e.g. timing requirements, monitoring
conditions, different power modes).
Following steps must be followed for establishing the
hardware connections:
1. All the pins of the ECU are connected to the
particular modules of the VT System as per the
requirements.
2. VT System is then connected to the computer
system having CANoe software through Ethernet
cable. All the modules connected in the VT System
are added to CANoe configuration.
3. CAN pins from the ECU are connected to Vehicle
Communication Interface (VCI) which is further
connected to the computer using its USB cable.
Fig. 3: Flowchart describing the process for DTC generation

Authorized licensed use limited to: Tsinghua University. Downloaded on July 06,2022 at 07:58:29 UTC from IEEE Xplore. Restrictions apply.
 The simulation nodes are created using the CAPL code
with required functionality. This is required for integration
of the system variables of individual modules and pre-
processed data (e.g. PWM measurement, average, RMS
value) assisted by the VT System. The Open Diagnostics
Data Exchange (ODX) file which is having diagnostics
database of the ECU, is attached to the testing environment.
The simulated partner ECU CAN signals will be sent to
device under test for simulating actual vehicle scenario.
Figure 4 shows an actual setup for one ECU being tested for
functional behaviour.

Fig.6: Trace window receiving CAN signals

Fig. 4: Actual test setup for functional testing of an ECU

IV. RESULT AND DISCUSSIONS

Figure 5 shows the interactive schematic view of a VT
System module which enables the generation of system
variable in the code generator window, whenever the
corresponding switch or relay is activated. The wake up of
ECU is made evident by the display of CAN signal
messages in the Trace window. This implies that ECU can
now acknowledge further instructions and the response
received for a particular Unified Diagnostic Service (UDS)
can be visualised in the Trace window. Figure 6 shows the
Trace window from CANoe software. The execution of a
CAPL test module is displayed each time in the write
window. Figure 7 displays the parameters measured by the
VT System (e.g. voltage, current) for the conditions before
fault, during fault and post fault, which were defined in the
CAPL script. Overvoltage (or Voltage above threshold)
fault is reported when the supply voltage to the battery and
ignition pins, is more than 16V, with 9V to 16 V being the
voltage range for its normal functioning. The fault is
removed when the voltage supplied to the ECU is restored
within its operational range.
Fig.7: Screenshot of the write window
The test overview is available in the reports which can
be analysed to determine the pass or fail status of the test
performed. The report is generated in the form of an HTML
document from where general test information can be
retrieved. Figure 8 displays the HTML report generated
after the completion of a test module creating an
overvoltage fault. The number of executed test cases and
their status is also indicated in the statistics. The variation of
measured value of voltage with the varying fault conditions,
with respect to time, can be seen in the graphics window as
shown in figure 9.
The Fault Memory Window of the ECU displays the
DTCs generated due to fault creation as well as provides its
code and status. On resetting the fault condition, the DTC is
restored to false. In Table 1, the write window and fault
memory window have been juxtaposed to analyse the
measured values and DTCs registered for the pre-fault/post-
fault condition and during the test execution. DTCs are
cleared each time after recording their current status for
each of these conditions. The table clearly infers that no
fault memory existed during pre-fault condition (i.e. 9V
<supply voltage <16V). The DTC is reported only when the
fault condition is created (Voltage > 16V) and gets removed
when voltage is set within the operational range of the ECU.

Fig. 5: Interactive Schematic View of VT System module

Authorized licensed use limited to: Tsinghua University. Downloaded on July 06,2022 at 07:58:29 UTC from IEEE Xplore. Restrictions apply.
 Fig. 9: The voltage variation display in the Graphics window

Fig.8: The self-generated HTML Report

TABLE 1: FAULT MEMORY WINDOW AND WRITE WINDOW ENTRIES REGISTERED DURING VARIOUS FAULT CONDITIONS
Test Step Write Window Fault Memory Window Result

Pre Fault No DTC

condition before
fault

During DTC
Test registered
Execution

Post DTC
Fault removed
condition

Authorized licensed use limited to: Tsinghua University. Downloaded on July 06,2022 at 07:58:29 UTC from IEEE Xplore. Restrictions apply.
 V. CONCLUSION
The automated testing procedure for fault detection of
an ECU aims at improving its life-cycle development
method. It ensures the reliability of the product on
consumer side along with quality standards. Though the
complexity is increased but it enables greater depth and
breadth of testing. Test requirements can be managed, test
environment can be simulated, and the test reports can be
obtained automatically in less time. Also same
configuration can be utilized for multiple ECU with
proper mapping. The reusability of the CAPL scripts
increases accuracy and provides quicker analysis for a
larger domain of variable change. The probability that the
ECU under test shall behave appropriately under all the
circumstances intensifies.
VI. ACKNOWLEDGEMENT
The authors would like to express their sincere
gratitude to the TATA Motors Limited, Pune for its
guidance and painstaking efforts for availing the
prerequisites for getting this project done.
REFERENCES
[1] J. Biteus, "Fault Isolation in Distributed Embedded System," Ph.D.
dissertation, Linköpings universitet, Linköping, Sweden,
Department of Electrical Engineering, 2007.
[2] F. Gustafsson, “Automotive safety systems, replacing costly
sensors with software algorithms,” IEEE Signal Processing
Mag., vol. 26, pp. 32-47, 2009.
[3] C. L. Heitmeyer, R. D. Jeffords and B.G. Labaw, "Automated
Consistency Checking of Requirements Specifications," ACM
Transactions on Software Engineering and Methodology, vol. 5,
no. 3, pp. 231-261, July 1996.
[4] S. Krauss, “Comprehensive ECU Tests with Fault Simulation,”
Vector Press Book, [Online]. Accessed on: Nov. 22, 2018,
Available:https://vdocuments.mx/vector-press-book.html.
Authorized licensed use limited to: Tsinghua University. Downloaded on July 06,2022 at 07:58:29 UTC from IEEE Xplore. Restrictions apply.
[5] D. Zheng, S. Zhang, "Test Automation for Automotive Embedded
Systems," Master’s thesis in Embedded Electronic System Design,
Chalmers University of Technology and University of Gothenburg,
Gothenburg, Department of Computer Science and Engineering
Sweden, 2017.
[6] M. Haug, E. W. Olsen and L. Consolini, “Software Quallity
Approaches: Testing, Verification and Validation,” Springer-
Verlag Berlin Heidelberg, 2001.
[7] D. Kum, J. Son, S. Lee, & I. Wilson, “Model-Based Automated
Validation Techniques for Automotive Embedded Systems,” SAE
International, 2007.
[8] S. T. Shruthi and K. H. N. Mufeeda, “Using VT System for
Automated Testing of ECU,” IOSR Journal of Computer
Engineering (IOSR-JCE), vol. 18, no. 3, pp. 28-31, May-Jun
2016.
[9] K. Enisz, D. Fodor, I. Szalay, & L. Kovacs, “Reconfigurable Real-
Time Hardware-in-the-Loop Environment for Automotive
Electronic Control Unit Testing and Verification,” IEEE
Instrumentation & Measurement Magazine, pp. 31-36, August
2014.
[10] S. Krauss, “A Modular Test System for Efficient Functional Tests
with Fault Simulation,” [Online]. Accessed on: Nov. 22, 2018.
Available:https://assets.vector.com/cms/content/know-
how/_technical-
articles/VT_System_Steuergeraetetest_AutomobilElektronik_2009
04_PressArticle_EN.pdf.
[11] R. Pupala and J. Shukla, "Review Paper on Vehicle Diagnosis with
Electronic Control Unit," International Journal of Innovative
Science and Research Technology, vol. 3, no. 2, pp. 117-123,
February 2018.
[12] “RobertBoschGmbH: CAN-Specification, 2.0,” [Online]. Accessed
on:Aug. 27, 2018. Available:
http://esd.cs.ucr.edu/webres/can20.pdf.
[13] A. Hentschel, E. Nordlander, “Design of an information system for
vehicle diagnostic trouble codes,” Master’s Thesis in Computer
Systems and Networks, Chalmers University of Technology and
University of Gothenburg, Gothenburg, Department of Computer
Science and Engineering Sweden, 2013.
[14] N. Niedermark, F. Low and S. Muller, "Automated Data Driven
Validation of the Diagnostic Implementation," ATZ elektronik, vol.
10, pp. 22-25, July 2015.