SACI 2018 • IEEE 12th International Symposium on Applied Computational Intelligence and Informatics • May 17-19 • Timiúoara, Romania
Designing and Implementing a Solution to
Manipulate Signals in Automated Testing Using
CANoe
Dan GEORGESCU* and Loredana STANCIU*
* Politehnica University Timisoara, Timisoara, Romania
dan2988@yahoo.com, loredana.stanciu@upt.ro
Abstract— CANoe is a development and testing tool mainly
used in automotive industry. The major drawback of the
CAPL application and programming language is the
absence of a signal datatype, CAPL functions being called
with the signal’s name from the database. If two similar
software should be tested with minor changes in terms of
signals names, the same test cannot run on both units, even
if their functionality is the same. Also, if only one software is
tested, but the client wants changes to the database, all tests
must be modified to make the desired change. The solution
presented in this paper removes all these problems. Using a
file containing the generic name of the signals, functions will
be generated to replace the CANoe functions provided by
CAPL. Thus, significant benefits are gained in terms of final
product cost and development time, reducing the risk of not
testing the software altogether.
I. INTRODUCTION
When General Motors introduced the first engine
control unit (ECU) on an automobile in 1980, no one
predicted how critical in terms of cost, safety and security
software would become. In the beginning, testing was
mainly done directly on the automobile, and the
complexity of the software was not very large, just a few
ECUs being used [1]. Nowadays this is no longer possible,
more than 60 ECUs are being installed in some luxury
class cars [1]. Even if final testing is still done on site,
when the software arrives on the machine, it has been
tested beforehand by various methods. To do this, the
Hardware in-the-loop (HIL) method has been
implemented [2]. This method involves the existence of
hardware and software tools capable of reproducing the
environment of a machine. Thus, an ECU can be tested
without being introduced into the car.
In support of automotive companies, Vector Informatik
GmbH has developed the CANoe program. This is a
development and testing tool mainly for the automotive
industry to develop, analyze, simulate, test and diagnose
control units as well as the networks they form [3]. Due to
its wide use and due to the large number of
communication protocols supported, it is an ideal tool for
developing conventional control units as well as hybrid
and electric vehicles. The program supports protocols
such as CAN, LIN, FlexRay, Ethernet.
CAPL is a dedicated software which can be used both
in testing and environment simulation. As an event-based
program, it has functions such as timers, incoming /
978-1-5386-4640-3/18/$31.00 ©2018 IEEE
outgoing events (pressed key, access to serial port, access
to parallel port) and events on CAN (reception of a
message, signal or errors), which more than three decades
has been the main standard for automotive networking [4].
With the continuous development of technology, the
software has become more and more complex, the
requirements increased and the time became shorter to
bring a product as quickly as possible on the market.
Thus, the trend is to develop generic software, which,
through few modifications, can serve a wide range of
machines. That is why testing must be carried out in a
more general manner. One obstacle to this goal is the
impossibility to declare signal-type variables in the CAPL
language. Thus, to check a signal, the function call is
made with the name of the signal as defined in the
database. If two similar software versions are coming up
for testing, with minor changes of the signals names in the
database, the same test cannot run on both units, even if
their functionality is the same. Also, if only one software
is tested, but the client wants changes to the database, all
tests need to be modified to make the desired change.
Thus, the costs of the final product will increase as well as
the development time. Another risk is not testing the
software altogether.
One way to overcome some of these issues is to add if
or switch statements. Thus, within the test, depending on
the tested software version, for instance, signal1 or
signal2 will be checked. This method does not solve all
the problems. If the client decides to change the signals
from the database, into the test the replacements will be
done manually, all tests being modified. Also, to introduce
a new software version can be challenging, instead of if
the switch statement should be used, all tests being
modified. No matter if the changes are minor or not, the
tests, which can be hundreds, have to be manually updated
and each one can have thousands of lines of code, making
the process quite difficult and time consuming.
The solution presented in this paper removes all these
problems, generating functions that replace the ones
provided by CAPL. The solution aims to generate a set of
functions that can be used in automated testing using
CANoe. The user can generate, based on a configuration
file and a file containing the signals definition as well as
generic names for the signals, a generic set of functions,
which can be included in the test files to verify multiple
versions of software using the same test.
000309
D. Georgescu, L. Stanciu • Designing and Implementing a Solution to Manipulate Signals in Automated Testing Using CANoe

The network used can be both CAN and FlexRay.

Changing the database does not raise such problems
anymore, when a new database is received, the signals that
have changed are passed to the .csv file and a new version
of the functions is generated. Since the generic name of
the signals has not been changed, the tests do not need to
be changed, so it also saves time.

II. METHODS

A. The CAN Network

The CAN Network (Controller Area Network) is a
network that allows microcontrollers and devices to
communicate with each other in a car without the need for
a central computer. The CAN network is a message-based
protocol made especially for automotive applications, but
it is also used in other areas such as the aeronautical or
medical industry. Any CAN node can place a message on
the CAN bus [3]. This network transmits the data in
binary form, with dominant bits and recessive bits. The
dominant bit is the logical value 0 and the recessive bit is
the logical value 1. Thus, if a node sends a dominant bit
and another node transmits a recessive bit, the node
wishing to transmit the dominant bit receives the access to
the bus [4].
Since the network is a multi-master broadcast type,
each node is able to send and receive messages but not
simultaneously. A message consists of an ID that gives
priority and up to 8 bytes of data [3]. If no message is
transmitted on the network, represented by transmission of
the logical state 1, any node can start the transmission.
When two or more nodes start the transmission at the
same time, arbitration takes place.
B. The FlexRay Network
Due to increasingly sophisticated functions such as
driver assistance requiring high error tolerance, the CAN
network has been unable to meet current automotive
requirements, so a replacement had to be found. Because
of this, BMW and Daimler Chrysler decided in 1999 to
join forces to develop a technology that allows for time-
based and fault-tolerant communication. The result of this
cooperation is the FlexRay network.
The main areas where FlexRay is used are automotive
applications that do not allow bus delays, with speeds up
to 10Mbit/s. A FlexRay (FlexRay Cluster) communication
system is a system made up of a number of FlexRay nodes
and a physical transmission medium, called FlexRay. A
FlexRay node is an ECU connected to the FlexRay bus,
which can communicate with an FlexRay interface
consisting of a communication controller and one or two
bus drivers (FlexRay transceiver), the number of which
depends on how the two networks are used [5].
Due to the fact that the physical environment is not
restrictive to the network topology, we can find FlexRay
networks point-to-point as well as line or star. To
minimize the chances of errors, FlexRay offers increased
redundancy, both of two channels can be used separately
at 10 Mbit/s or can be used together to increase the
transfer rate to 20 Mbit/s [3].
C. CANoe and CAPL
The programming language used in CANoe is Vector
CAN Programming Language (CAPL). Based on C
Figure 1. System block diagram
programming language, CAPL is specifically developed
for use in PC versions of CANoe and CANalyzer [6].
CAPL can be used both in testing and environment
simulation. Being an event-based program, it has
functions such as input/output events (pressed key, access
to serial port, access to parallel port) and events on CAN
(reception of a message, signal or errors).
To use the language a database (CANdb) is needed.
This defines nodes, messages and signals from the CAN
or FlexRay network. The entire environment can be
simulated in CANoe. An ECU can be analyzed and tested
without being introduced into a real machine, so the
environment can be better controlled.
The major drawback of the CAPL programming
language is that there is no signal type that can replace the
signal name. If we want to use CAPL functions with
signals we will have to call the function with the name of
the signal from the database. Because of this, the
following code will not run, generating compilation
errors:
Signal signalToSet dbSignal;
Setsignal(signalToSet, valueToSet);
Instead, we should use the function with the name of
the signal from the database as a parameter:
Setsignal (dbSignal, valueToSet);
If the signal name changes, or we want to use the
functions in tests that will be used on multiple projects or
on different protocols (CAN, FlexRay), this will not be
possible.
The handiest way to work with signals is the one
presented above because doesn’t require additional
development, is easy to use and easy to understand. The
big disadvantage is that if the name of the signal in the
database changes, it will need to be replaced everywhere
is called. Also, if we develop the same project using
different protocols like CAN or FlexRay, separate tests
will have to be created, even if they do the same thing.
This inconvenience will lead to additional developer effort
and higher costs.

000310
 SACI 2018 • IEEE 12th International Symposium on Applied Computational Intelligence and Informatics • May 17-19 • Timiúoara, Romania
Figure 2. Generator control panel
Some of the shortcomings mentioned above may be
overcome using if or switch statements in the part of the
test where the signals differ:
...
if(tested_unit == 1)
{ In this manner, the list of functions will be generated.
Setsignal(db1Signal, valueToSet)
}
else
{
Setsignal(db2Signal, valueToSet)
}
In this case db1Signal and db2Signal may be
signals from two similar databases or signals from
different protocols, the first being transmitted on CAN and
the second on FlexRay. But this solution does not solve all
the shortcomings. If databases change the names of
signals, they should be changed wherever they appear,
resulting in extra effort and high costs. Also, a new variant
must be entered manually in all tests, using switch
statements.
One possible solution to solve this problem is to create
an automatic variant generator, having as input a file with
the signals’ name. If a signal changes, the change should
only be done in this file, and then the functions will be
automatically generated. Also, if a new software is used,
then a new column in this file will be inserted, a column
that will indicate the signals from the new database. Since
the generic name of the signals has not changed, the tests
do not need to be changed, so it also saves time.
III. THE DESIGN
The program is designed to create a set of functions that
can be used to test multiple versions of software with the
same tests. To run the function generator, a computer with
CANoe and CANCase XL or VN7600 connected to this
computer are required (Fig. 1). Through them, the
computer is able to simulate an environment as close to
the machine as possible. At the time the tests call for the
generated functions, depending on the version of the
Figure 3. The relationship between files
000311
tested software, the signals of that variant will be checked
or modified.
To use the variant generator, the user must integrate it
into the current project. The Test Environments for Test
Modules window has to be opened in the CANoe
configuration. If there is no folder named Support, it
should be created by right clicking on the .tse file and
selecting New Folder. Once the folder is created, the node
will be added by right-clicking on the folder and pressing
the Insert Network Node button.
When the user wants to generate the functions, he clicks
the function button on the panel. In advance, he would
have to load the configuration file, a file containing the
path to the .csv file with the signal definition, the path to
the location where the functions will be generated, the
name of the project, the number of variants for which the
tests are generated, and their names.
They are defined by the user, being the ones needed for
the projects. After creating the lists of functions, input
parameters are read. If this file, containing the parameters,
cannot be opened, an error is generated (Fig. 2). Once the
parameters are uploaded, the files are created at the
location specified in the configuration file. If the location
is not correct or there are write permissions, an error is
generated. If the files already exist, they will be deleted.
The next step is to create the file that links the generic
name of the signals to their names in the database. For
that, the content of the .csv file with the signal names is
read and saved in a variable. Then the file containing the
list of constants is created (the generic name of the
signals). Finally, the files containing the functions are
generated based on the information in the .csv file,
creating a series of switch statements that will ensure the
use of signals for the tested software version.
In addition to this three files that are automatically
generated and depend on the project where variants are
being manipulated, a set of files is created to help the test
engineers. These files must also be included in the tests.
At the top level is the Generic_VARIANT_Test
Step_Library.cin file. This file contains interfaces
that can be called directly into the tests, which add the
action and the expectations of the test step as well as the
result. The functions found in this file are those of
comparing and setting the signals. These features use
interfaces from a lower level. The difference between
these two levels is the information displayed in the test
report: the top level also displays step action and
expectations, while the second level displays only the
result.
The Generic_VARIANT_Func.cin file and the
Generic_VARIANT_TST_Func.cin file are inclu-
ded in the next level. These files contain functions that do
not need to be called directly into the tests because they do
not add all the information in the report, but they can be
called by top-level functions. The way these functions
interact with generated threads is shown in Fig. 3. Thus, to
set a signal, G_VAR_GetSignal (int aSignal) is
called with the unique parameter the ID of the message to
be read.
float G_VAR_GetSignal(int aSignal)
{
D. Georgescu, L. Stanciu • Designing and Implementing a Solution to Manipulate Signals in Automated Testing Using CANoe
Figure 4. Test examples on FlexRay (up) and CAN (down)
struct ltFunc funcSetup;
funcSetup.funcCall = GET_SIGNAL;
G_VAR_FuncSwitch(aSignal, funcSetup);
return funcSetup.retValFloat;
} introduced, the change consists only in the insertion of a
This function will in turn call the function
G_VAR_FuncSwitch by transmitting the signal ID and
the type of action that is to be performed, namely reading
the signal. This function is automatically generated by the
program and contains a series of switches that allow
identification of the message based on the ID and the
variant to be tested. Once the message is identified, the
function void G_VAR_Func (signal * generic name of the signal has not changed, the tests do
aSignal, struct ltFunc funcSetup) is called
to perform the action sent via the funcSetup
parameter. The difference between the two files is the type
of functionalities they meet. Thus, the Generic_
VARIANT_Func.cin file contains functions that run
immediately, they do not require waiting times, whereas
the Generic_VARIANT_TST_Func.cin file contains
the functions that test the signal for a certain period of
time until they give a verdict.
After generating generic files, they must be included
into the test:
#include
"..\Include\Test_VARIANT_SignalConstants.cin"
#include
"..\Include\Test_VARIANT_Signal.cin"
#include
"..\Include\Test_VARIANT_SignalTest.cin"
At this point, the user will be able to use newly created
features, referring to the signal that he wants to teste or
change by its generic name, for instance:
G_TestStep_VAR_SetSignal ("1", "", vcISw_Stat,
4);
The result of this function call will be to set the
ISw_Stat signal to 4 for the software version to be
tested. Fig. 4 presents two report models, one for a variant
of software that uses the FlexRay protocol and the other
for a software version using the CAN protocol.
IV. CONCLUSIONS
The application is designed to create a set of functions
to test multiple software variants using the same tests. The
network can be both CAN and FlexRay. The solution
chosen to solve the problems induced by the fact that there
is no signal type in CAPL is to create an automatic
000312
generator of variants, having as input a file with the
generic name of the signals. Thus, if a signal changes, it
only appears in the file, and then the functions will be
automatically generated. Also, if a new software version is
new column in the .csv file, which will indicate the signals
in the new database. Even changing the database does not
cause big problems, the signals that have changed are
passed to the .csv file and a new version of the functions is
generated. At the time the tests call the generated
functions, based on the tested software version, the signals
of that variant will be checked or modified. Since the
not need to be altered, thus saving time.
The user interface is very simple and consists in a panel
included in the CANoe configuration of the project. The
panel has a button that generates the tests, a button for
selecting the configuration file, and a panel displaying
error messages or running result (Fig. 2). This way the
user can easily see the results of the generation. It uploads
a configuration file, containing the paths to the required
files, as well as information about the variants being
tested. If the file is not loaded or the paths in it are not
valid an error message will be displayed on the panel.
When the program has finished running, a message will be
displayed to let the user know which files were created.
REFERENCES
[1] T. Riegraf S. Beeh S. Krauß "Efficient testing in automotive
electronics", From simulation to diagnostics Development
Measurement Techniques, vol. 109 no. 7 pp. 16-19, July 2007.
[2] B. Müller and S. Köhl, "Simulating and Testing In-Vehicle
Networks by Hardware-in-the-Loop Simulation," SAE Technical
Paper 2008-01-1220, 2008, https://doi.org/10.4271/2008-01-1220.
[3] Rishvanth , D. Valli , K. Ganesan , "Design of an In-Vehicle
Network (Using LIN, CAN and FlexRay), Gateway and its
Diagnostics Using Vector CANoe", American Journal of Signal
Processing, vol. 1, no. 2, 2011, pp. 40-45. doi:
10.5923/j.ajsp.20110102.07.
[4] Bosch. CAN specification 2.0. esd.cs.ucr.edu/webres/can20.pdf,
1991. Visited February 2018.
[5] FlexRay communication system, protocol specification, version
2.0, http://www.flexray.com/. Visited February 2018.
[6] Programming with CAPL, December 14, 2004
[7] C. Liu and F. Luo, “A Co-Simulation-and-Test Method for CAN
Bus System”, Journal of Communications, vol. 8, no. 10, pp. 681-
689, October 2013, doi:10.12720/jcm.8.10.681-689.