This document summarizes the internship work of programming a virtual test box to automate testing of Body Control Modules (BCMs) in vehicles. The test box uses National Instruments hardware, the Canoe software, and custom scripts to test BCM signals, messages, and configurations over the CAN network and K-Line interface. The intern programmed test cases in XML, CAPL, and .NET to check over 100 signal and message values across 17 test cases for vehicle exterior lights and door controls. A challenge was fully integrating the K-Line server tool to read diagnostic trouble codes, which is a work in progress. The intern gained experience programming automated tests and interfacing with vehicle networks.

1. Name of Company: Continental Singapore Pte Ltd
Division: Interior
Business Unit: Body and Security
Period: 07/25/2014- 08/22/2014
Supervisor: Raigon Ignatius
Table of Contents
Introduction ..............................................................................................................................................2
Objectives and Deliverables......................................................................................................................2
Implementation and Work Experience.....................................................................................................4
XML Script .............................................................................................................................................5
CAPL Script ............................................................................................................................................8
CanoeIL................................................................................................................................................10
Test Environment................................................................................................................................11
NI IO PINS and Environment variable mapping ..................................................................................12
K-Line Sever Tool.................................................................................................................................12
.Net Kline Server test script ................................................................................................................13
MC PARAMETERS IN XML ...................................................................................................................13
Technical Interest....................................................................................................................................14
On-board diagnostics (OBD) ...............................................................................................................14
Named Pipes .......................................................................................................................................15
Challenges Faced and Resolution ...........................................................................................................15
Conclusion...............................................................................................................................................15
Attendance..............................................................................................................................................15

2. Introduction
The following report covers material on Body Control Modules (BCM), CAN messages and signals
developed by Bosch, K-line which is an industry standard for on board diagnostics of ECUs in the
automotive industry, Canoe software and visual basic Named Pipes, Network operation.
BCM testing is a challenging and rigorous process that’s complicated on many levels. The BCM controls
all interior modules in a car, interior headlights, exterior headlights, door locks and other systems. These
signals are sent across a network to other ECU’s though the CAN messaging system.
Testing the interactions of signals and messages in this environment is challenging, where testing
functionality of a sub-module (exterior lights) with over 100 test-cases. It’s time consuming testing it
manually with a different BCM configuration each time.
BCM configuration is done with a K-line tool that programs functionality and features of the ECU e.g.
specifications for North America or EU headlight setting. This is programmed by a Hex code.
Objectives and Deliverables
The purpose of this project is to develop a virtual test box that automates testing. This is done by using
switch boards, a National Instruments relay module for switch flipping, A CAN case for sending and
reading CAN messages on the network, software (Canoe), a K-line server tool that sends parameters and
reads diagnostic trouble codes (DTCs).
The Canoe test Environment is where the test script is written and executed. Test-scripts can be written
in XML, CAPL or .Net. The named pipe client allows the test nodes in Canoe to communicate with the
sever tool and transmit data on the K-line.
The test script is programmed using XML and is used to check the values of Environment Variables in the
Canoe database. The CAPL code test script is the base which allows XML to call these test functions and
check the variables.
Fig 1.0: Abstract

3. As of by the end on this internship I have programmed a working test environment with a combination
of CAPL, XML and .net test-cases. I have Programmed test-cases for mainly exterior headlights and door
controls and am proceeding to include interior headlight test-cases. A total of 17 test-cases have been
programmed.
There has been a successful implementation of the server tool to set parameters on the BCM, with the
help of my supervisor we hope to have a fully functioning K-line sever tool which is able to read
messages on the K-line.
Fig 1.1: Switch Box

4. Implementation and Work Experience
Below is a User guide on the system set up, tool and test case implementation.
Fig 1.2: Hardware
Fig 1.3: Simulation Setup
BCM and SMART
ECUs

5. The XML Module consists of three components, the XML script, CAPL script and the optional On Start
variables. The XML modules can execute test-cases by calling CAPL test functions and CAPL test-cases
written in the CAPL test scripts.
The XML module can perform checks by setting environment variables and using the State check call to
check for signals, environment variables and system variable values.
Only one XML test-script can be added to the test node however you can add multiple CAPL test-scripts
to the node, thereby allowing you to call functions from both scripts. It is advisable the set-up separate
modules for different modules. E.g. Head-light test module; auto head-light tests with 4-bulb HID. This
can be done using the test environment.
XML Script
The XML script has three categories’ of tests the Main test module, there can only be one module in one
script. The test groups and test cases as show below.
Fig 1.4: Module Configuration

6.  State-check and State-change
There are differences between the State-check and State-change function in XML in which State-
Change requires the <in>Signal</in> sequence.
 Setting signals, environment variable and system variables.
There are various ways to set values of signal, environment and system variables the above is
one way. The others are as follows highlighted in red.
Test Group
Test Module
Test Case
<statecheck wait="100" title="check
signal">
<expected>
<cansignal name="$t2-
signame$">
<eq>$t2-sigvalue$</eq>
</cansignal>
</expected>
</statecheck>
<statechange title="Header for the pattern,
appears in report" wait="Wait time between
setting and evaluating in ms"
resettime="Wait time after resetting of the
values before the test pattern terminates">
<in>
List of CAN/LIN/FlexRay signals and
environment/system variables
</in>
<expected>
List of CAN/LIN/FlexRay signals and
environment/system variables
</expected>
</statechange>
<vardef name="Variable name" type="Type" default="Default value (optional)">
Value of the variable (a literal entry or cansignal, linsignal, flexraysignal, envvar,
sysvar)
</vardef>
<set title="C_ABSMALL_R_0"><cansignal
name="C_ABSMALL_R">0</cansignal></set>
Fig 1.5: Test Setup

7.  Waiting.
There are various ways to wait for the CAN messages and signal in the Test Module.
In CAPL there is the testwaitfor functions and in XML it is the [wait=”1s”] in (s) or [wait =”300”]
in (ms). Some functions when setting wait times like the <set> function in XML will set the signal
immediately then wait for a specified amount of time. In the state-check function it will wait
first then check the signal values. To check the wait order of the functions called look at the
report generated.
 Capl test function and Capl test case
When calling these functions please note there are different ways to call them. They each have
their own identifiers and rules for calling in XML.
<testcase title=" Name of test case" ident="ID of test case">
...
<capltestfunction
name="CAPL name of test function"
title="Display name for CAPL test function">
<caplparam name="Parameter name"
type="float|int|string|signal|envvar|sysvar">Parameterwert</caplparam>
</capltestfunction>
...
</testcase>
<capltestcase name="CAPL name of CAPL test case" title="Displayed name of the CAPL
test case" ident="ID of the test case, e.g. number">
<caplparam name="Parameter name"
type="float|int|string|signal|envvar|sysvar">Parameter value</caplparam>
...
</capltestcase>
<testcase ident="Wiping Level 2" title="Wiping level 2, fall back to off">
<initialize title="Select wiping level 2" wait="1500">
<cansignal name="WipingLevel">2</cansignal>
<cansignal name="WasherRequest">0</cansignal>
</initialize>
<statechange wait="4000" title="After switching off the wipers, they shall have
reached the position 0">
<in>
<cansignal name="WipingLevel">0</cansignal>
<cansignal name="WasherRequest">0</cansignal>
</in>
<expected>
<envvar name="EnvWiperPosition">0</envvar>
</expected>
</statechange>
</testcase>

8. You may call multiple CAPL test-functions in a test case but to call the CAPL test-case you
have to first close the test case and then call the CAPL test-case. You may also add a wait
function in the test-case header, capl-test-function or capl-test-case headers. The CAPL test-
case and test functions are defined in the CAPL test-script with their respective definitions’.
 .Net test-cases and Kline
The .Net test function has to be written in .Net2.0, the function is called in XML in the following
format. A .Net test case can also be called. The .Net testfunction is used to set the K-line MC
configuration parameters.
 Variants
Variants allow the user to set up combinations of test cases to be executed. If no variant is
declared for a test-case, that test-case will appear in other variants. Variants must be declared
at the start of the test module from there you can follow the above example.
CAPL Script
I have included several features in the Capl script. I have learned to include additional scripts to
call functions and test-cases thus reducing the line of code per Capl script and allowing for
grouping of test-function and test-cases. These functions can be called in XML scripts. I have
added functions that parse’s a signal/environment variable for testing.
<nettestfunction name="SimpleTestFunction"
title=" Displayed name of the NET test function"
class=" NETTestLibrary"
assembly="TestLibrary"
variants="A" >
<netparam name="ParameterName"
type="float|int|string|signal|envvar|sysvar"> Parameter Value </netparam>
</nettestfunction>
<variants>
<variant name="A">ALL Tests</variant>
<variant name="QS">Quick Set</variant>
</variants>

9. Fig 1.6: Simulation Script
Fig 1.7: Simulation Script

10. CanoeIL
CanoeIL is set using the database and manipulating the attributes. The CanoeIL send messages cyclically
you can also set messages and signal behavior on the BUS by changing it attributes and values.
Based on the IL settings and defined nodes in the database. You need to add the nodes and activate
the node to send its respective messages. By running the simulation you should be able to see
cyclical messages in the trace window. Be sure to deactivate the IL attribute for the signal or
message, if you are using the setSignal or output message function in CAPL or .Net.
 setSignal
To use the setSignal in CAPL you must first register a signal driver by doing the following
Then call the register signal driver and set the signal value.
void Tx_C_KLDOORLOCK(double value)
{ msg_R_KLDOORLOCK.C_KLDOORLOCK = value;
output(msg_R_KLDOORLOCK);
write("Tx_C_KLDOORLOCK : %f",value );
}
testfunction SWITS_MICU_IT_1529()
{ putValue(IG1_SW,0);
registerSignalDriver(C_KLTXNUM,"Tx_C_KLTXNUM");
registerSignalDriver(C_KLDOORLOCK,"Tx_C_KLDOORLOCK");
testWaitForTimeout(300);
setSignal(C_KLTXNUM,32);
setSignal(C_KLDOORLOCK,2);}}
Fig 1.8: Database Attributes

11. Note: setSignal can be used when CanoeIL is active for the message or signal but requires the
removal of the signal driver (void function).The signal value can be set in XML, .NET or in CAPL.
Test Environment
The Test Environment will allow you to add
test nodes, scripts and other Test
Environments’. Nodes added may not
appear in the Simulation setup. The test
node is denoted with a ‘T’. One can select
and execute these test nodes in any order,
or by double clicking on the node to select
tests to execute.
Note : this nodes will not appear in the
setup window. You’ll see CANoeILNLVector
Fig 1.9: Test Environment

12. NI IO PINS and Environment variable mapping
I have mapped the NI DIO port pins I/Os to environment variables defined in the Envar database. So
values set by the Environment variables in XML set the output pins on the NI card and Input pins set the
Input environment variables. To change the pins opens the XML_ENV_NODE.can file and specify the I/O
port and pin to the environment variable, Sw means switches and Lt is LEDs. Be sure to add new
environment variables in the database before adding them in the mapping node.
Also remember to specify the I/O port type in the Panel to update the NI dll, not doing so will result in the
5V LED on the relay module to be off.
K-Line Sever Tool
Got the K-line sever tool working, problems found were with the use of the system timer in the K-line
sever tool solution to send the wake up signal. BCM requires a wake up signal within a specific time
range of approximately 24-26 (ms). The DLLs generated by canoe have to be deleted for each and every
update; otherwise changes to code will not take effect. I have written a batch file that deletes the .dll
extension in the test config folder of the simulation.
Run the K-Line Server Tool to set MC Parameters on the BCM.
Fig 2.0: NI variable map

13. .Net Kline Server test script
To set MC parameters program it in the following format.
To Call in XML
MC PARAMETERS IN XML
Create a new MC parameter using the blank MC parameter template. The structure follows the order
wake, the MC request and ECU reset command.
Note: do not include the checksum byte in the MC parameter request.
[TestCase("Identifier", "Title", "Description")]
public void KLINESever()
{
Output.WriteLine("sever connection ");
Program.SendCommand(0);
Output.WriteLine("sever disconnected");
}
<nettestcase
name="KLINESever" title="KLINESever">
</nettestcase>
Fig 2.1: XML K-line request

14. Add the new MC file to Commands.xml
Specify and ID and the file name of the MC parameter. Naming of MC Parameter file is as follows: Name
of Configuration e.g. internal test configuration. Sub-changes w/o Auto light, 2Bulb etc or test-case
name. I have extended the library to 13 MC parameters.
The .Net send command ( Program.SendCommand(0);) calls this file and it’s ID INTTEST.xml.
Technical Interest
On-board diagnostics (OBD) is an automotive term referring to a vehicle's self-diagnostic and
reporting capability. OBD systems give the vehicle owner or repair technician access to the status of the
various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely
since its introduction in the early 1980s' versions of on-board vehicle computers. Early versions of OBD
would simply illuminate a malfunction indicator light or "idiot light" if a problem was detected but
would not provide any information as to the nature of the problem. Modern OBD implementations use a
standardized digital communications port to provide real-time data in addition to a standardized series
of diagnostic trouble codes, or DTCs, which allow one to rapidly identify and remedy malfunctions within
the vehicle. The K-line protocol allows us to activate and deactivate parameters in the body control unit
for testing. (Reference: Wikipedia)
Fig 2.2: XML K-line library

15. Named Pipes
A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one
or more pipe clients. All instances of a named pipe share the same pipe name, but each instance has its
own buffers and handles, and provides a separate conduit for client/server communication. The use of
instances enables multiple pipe clients to use the same named pipe simultaneously.
Any process can access named pipes, subject to security checks, making named pipes an easy form of
communication between related or unrelated processes.
Any process can act as both a server and a client, making peer-to-peer communication possible. As used
here, the term pipe server refers to a process that creates a named pipe, and the term pipe client refers
to a process that connects to an instance of a named pipe. The server-side function for instantiating a
named pipe is CreateNamedPipe. The server-side function for accepting a connection
is ConnectNamedPipe. A client process connects to a named pipe by using
theCreateFile or CallNamedPipe function. (Reference: http://msdn.microsoft.com/)
Challenges Faced and Resolution
I am still learning a lot about the signals and messages being sent in the CAN net work, my continued
work on the project has made me face more challenges with learning new programs and writing scripts
namely XML, C# and CAPL. It has also allowed me to explore different test module functions and types.
At the moment I am having difficulty incorporating the Kline sever tool module to send MC
configurations and read DTCs, and am also making an attempt to reduce the lines of XML code for a test-
case finding a balance in coding a test-case in XML, Capl and .Net . I have however decided to use .Net
test-case for setting MC parameters on the K-line and execute the test-cases using a combination of
XML and Capl script based upon the length of execution of a test-case. This is to reduce code and
facilitate in report generation and debugging.
This is still a work in progress and I hope to finish as much as possible by the end of my internship.
Overall we have a working prototype of the virtual test box. On the other-hand the knowledge gained
during my internship on the BCM and ECUs in general has been an eye opener. I have also learned a lot
about the automotive industry practice and safety requirements for ECU operation and security. There is
a lot of work put into an ECU and its operations and I feel I have contributed significantly by developing
this tool for automated testing.
Conclusion
I have felt my continued participation in the project has enabled me to learn more about how the BCM
module works and what happens in the CAN network in Cars. This experience has also allowed me to
build on my programming skills as I have now learnt to use visual basic and write C# code.
Attendance
MC on 08/06/14