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

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

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

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

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

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

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>

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>

Fig 1.6: Simulation Script

Fig 1.7: Simulation Script

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

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

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

.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

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

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