Simulation Scenarios of Automotive Control Units
Simulation Scenarios of Automotive Control Units
Simulation Scenarios of Automotive Control Units
Czech
Technical
University
in Prague
Faculty of Electrical Engineering
Department of Control Engineering
May 2015
Thesis supervisor: Ing. Michal Sojka, Ph.D.
ii
Acknowledgment
Let me thank my supervisor Ing. Michal Sojka, Ph.D. for his professional
guidance and helpful recommendations during the course of this work.
Furthermore, I would like to thank Ing. Milan Mráz for his willingness
and useful advice, primarily from the technical point of view.
Besides, I would like to send my last thanks to all other around me who
contributed with even a little piece of advice and supported me through
all the time.
iii
iv
Abstract
The main goal of this diploma thesis was the development of a converter
for simulation scenarios of electronic control units. The thesis mainly deals
with the simulation of a type rest-bus. The overview of available software
tools for testing and development of automotive control units is provided.
The rest-bus simulation representing the control of a head unit has been de-
veloped for two specific tools – Vector CANoe by the Vector company and
PROVEtech:TA by the MBtech Group company. Consequently, the con-
verter ensuring mainly the conversion of testing scripts and basic graphical
user interface from CANoe to PROVEtech:TA has been developed. Test-
ing scripts can be converted from CAPL language to WinWrap Basic and
C language. The whole conversion process as well as general usage of the
developed tool are described in this document. The thesis was developed in
a cooperation with company MBtech Group. The conversion of simulation
scenarios has been successfully tested on developed rest-bus simulations
for the head unit, which was provided by MBtech. The testing process
showed functional behavior of translating various simulation scripts from
the CAPL language to WinWrap Basic and C. The modularity of the tool
enables adding conversions to different tools.
Keywords
rest-bus simulation; electronic control units; converter; open-source
v
vi
Abstrakt
Hlavnı́m cı́lem této diplomové práce byl vývoj převodnı́ku simulačnı́ch
scénářů automobilových řı́dicı́ch jednotek. Během této práce je převážně
pracováno se simulacı́ typu rest-bus. V práci je uveden přehled soft-
warových nástrojů pro testovánı́ a vývoj řı́dicı́ch jednotek. Rest-bus sim-
ulace představujı́cı́ ovládánı́ palubnı́ho počı́tače byla vytvořena pro dva
specifické nástroje – Vector CANoe od společnosti Vector a PROVEtech:TA
od společnosti MBtech Group. Následně byl vyvinut nástroj zajišt’u-
jı́cı́ převážně převod testovacı́ch skriptů a základnı́ho grafického uživatel-
ského prostředı́ z CANoe do PROVEtech:TA. Testovacı́ skripty mohou
být převáděny z jazyku CAPL do jazyku WinWrap Basic a C. Tato práce
byla vyvı́jena ve spolupráci se společnostı́ MBtech Group. Převod simu-
lačnı́ch scénářů z CANoe do PROVEtech:TA byl úspěšně otestován na vyv-
inutých rest-bus simulacı́ch pro řı́dicı́ jednotku palubnı́ho počı́tače, která
byla poskytnuta firmou MBtech. Testovánı́ prokázalo funkčnost převodu
různých simulačnı́ch skriptů z jazyka CAPL do WinWrap Basic a C. Mod-
ularita nástroje umožňuje přidánı́ převodu do dalšı́ch nástrojů.
Klı́čová slova
rest-bus simulace; řı́dicı́ jednotky; převodnı́k; open-source
vii
viii
Contents
1 Introduction 1
2 Software Tools 3
2.1 Commercial Software . . . . . . . . . . . . . . . . . . . . . 3
2.2 Open-source Software . . . . . . . . . . . . . . . . . . . . . 4
2.3 PROVEtech:TA . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Workspace . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 Test Manager . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Diagnostics . . . . . . . . . . . . . . . . . . . . . . 6
2.3.4 Fault Simulation . . . . . . . . . . . . . . . . . . . 7
2.3.5 PROVEtech:RE . . . . . . . . . . . . . . . . . . . . 8
2.4 Vector CANoe . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Panels . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2 Analysis Windows . . . . . . . . . . . . . . . . . . 9
3 Rest-bus Simulation 13
3.1 Definition of Rest-bus Simulation . . . . . . . . . . . . . . 14
3.2 Description Files Formats . . . . . . . . . . . . . . . . . . 14
3.2.1 DBC File . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 ARXML File . . . . . . . . . . . . . . . . . . . . . 18
3.3 Project Setup Procedure in PROVEtech:TA . . . . . . . . 19
3.3.1 XML – RBS Descriptor . . . . . . . . . . . . . . . 20
3.3.2 XML – PROVEtech Configuration File . . . . . . . 21
3.3.3 Setup of Workspace . . . . . . . . . . . . . . . . . . 21
3.4 Project Setup Procedure in CANoe . . . . . . . . . . . . . 22
3.4.1 Simulation Setup . . . . . . . . . . . . . . . . . . . 22
3.4.2 Panel Designer . . . . . . . . . . . . . . . . . . . . 23
3.5 Test Languages . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.1 WinWrap Basic . . . . . . . . . . . . . . . . . . . . 23
3.5.2 CAPL . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.3 Main Differences . . . . . . . . . . . . . . . . . . . 27
4 Converter 33
4.1 Lexer and Parser . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Lexical Analysis . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Parsing . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Translation to WinWrap Basic . . . . . . . . . . . . 46
4.2.2 Translation to C . . . . . . . . . . . . . . . . . . . 52
4.3 Graphics Conversion . . . . . . . . . . . . . . . . . . . . . 54
4.3.1 Implementation . . . . . . . . . . . . . . . . . . . . 54
4.4 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ix
4.4.1 Installation . . . . . . . . . . . . . . . . . . . . . . 56
4.4.2 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4.3 Test Language Restrictions . . . . . . . . . . . . . . 57
4.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . 63
4.5.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.4 Example 4 . . . . . . . . . . . . . . . . . . . . . . . 66
4.5.5 Example 5 . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.6 Example 6 . . . . . . . . . . . . . . . . . . . . . . . 68
5 Conclusion 71
Appendix A 73
Bibliography 74
x
List of Figures
2.1 An example of test manager [1] . . . . . . . . . . . . . . . 6
2.2 An example of diagnostics dialog [1] . . . . . . . . . . . . . 7
2.3 An example of page for wiring faults [1] . . . . . . . . . . . 8
2.4 An example of trace window with active filter and marker [2] 10
2.5 An example of graphics window with marker [2] . . . . . . 10
2.6 An example of scope window [2] . . . . . . . . . . . . . . . 11
2.7 An example of state tracker [2] . . . . . . . . . . . . . . . 12
xi
xii
List of Tables
2.1 Summary of available open-source tools . . . . . . . . . . . 5
xiii
xiv
Abbreviations
xv
Chapter 1
Introduction
Electronic in today’s vehicles is becoming more and more complex as their overall
technological capacity grows. With this increased vehicle capacity comes a significant
growth in the number of electronic control units (ECUs) inside a vehicle. Due to this
increased complexity, each of individual ECUs interacts with each other and depends on
encompassing information, which is transferred through in-vehicle buses. Since safety is
an important factor, testing and validation of the right functionality of an ECU plays a
critical role. However, often not all ECUs of a network are available during testing. The
remaining bus simulation (rest-bus simulation) is an ideal solution when the missing
ECUs (i.e. the ”rest”) of the bus need to be simulated. This allows to simulate missing
functionality of any control unit of an in-vehicle bus, mostly CAN, LIN or FlexRay.
Moreover, it can greatly reduce testing time and costs.
A wide range of companies offers software tools that support rest-bus simulation.
Some of these tools are provided as a part of a complete software for the develop-
ment and testing of control units. During this thesis, CANoe by Vector company and
PROVEtech:TA by MBtech company were used. Many costumers of MBtech company
use PROVEtech:TA software but very frequently are supplied with rest-bus simulation
created by an original equipment manufacturer (OEM) in CANoe software. This leads
to the need of a tool that would be able to convert created rest-bus simulation from
CANoe to PROVEtech:TA.
The main focus of this thesis is the creation of the converter from CANoe to
PROVEtech:TA. In order to achieve that, a developer needs to get familiar with the
steps needed for creating a rest-bus simulation for ECUs in both above mentioned
tools. For this purpose, the rest-bus simulation for the ECU of the head unit was
created manually for both tools as the first step of this work. These simulations
represent the communication of the head unit with control buttons. The next step
was to create the converter from CANoe to PROVEtech:TA. This tool was devel-
oped in Python. Furthermore, the emphasis was put on the modular development
of the tool. This means, additional features might be easily added. The tool runs
on Windows and Linux platforms. The relevant code is placed on GitHub (https:
//github.com/mikulleo/RestbusSim-Converter) and is released under the GPL li-
cense.
Furthermore, it is important to mention that an automatically generated simula-
1/75
CHAPTER 1. INTRODUCTION
tion of signals and messages on a bus based on input description files1 is generally the
main part of any rest-bus simulation. During this thesis, the simulation ensuring the
transmission of signals, leading to the functional behavior of the head unit was de-
veloped. The rest-bus simulation was developed only for the CAN bus according to
requirements by the MBtech company. Nevertheless, despite many differences between
bus types, working with their rest-bus simulations is similar in both tools, CANoe and
PROVEtech:TA.
Automated test scripts can be developed to simulate behavior of the ECU by various
operations with signals and messages. The scripts in Vector CANoe are written in
the CAPL language, and in PROVEtech:TA they are written in the WinWrap Basic
language.
The thesis is structured as follows: Chapter 2 provides an overview of available
software tools on the market, as well as some open-source software tools that might
be helpful during the development of rest-bus simulations. An introduction to CANoe
and PROVEtech:TA is provided as well. The term rest-bus simulation as well as the
configuration and overall setup of rest-bus simulation for PROVEtech:TA and CANoe,
together with formats of their description files and test scripting languages, are described
in Chapter 3. Chapter 4 describes the development of the converter from CANoe to
PROVEtech:TA, which is the main result of this work. The examples of built abstract
syntax tree as well as converted code are given in Section 4.5. A conclusion is given in
Chapter 5.
1
description file: CAN – DBC, ARXML (described in Sections 3.2.1 and 3.2.2)
2/75
Chapter 2
Software Tools
This chapter describes several tools for the development of control units that could
be relevant to this work. Most software tools for control and test automation of ECUs
are under a commercial license. Regarding commercial software, only PROVEtech:TA
and Vector CANoe were available during this work. These two tools are described in
more detail in Sections 2.3 and 2.4. On the other hand, open-source software contains
in most cases tools for analysis and modification of description files that include signals
and messages belonging to a particular ECU. This might be helpful during the develop-
ment of an ECU. Commercial and open-source software tools are presented in Section
2.1 and Section 2.2.
3/75
CHAPTER 2. SOFTWARE TOOLS
Available open-source software tools can be in most cases used for analysis or setup of
configuration files used for the rest-bus simulation. Rarely, they allow the conversion
between different formats of configuration files. More about specific configuration files’
formats can be found in Section 3.1. The configuration files contain defined signals
and their parameters. Most of the open-source tools are collectively called ”viewers”.
Example of some the tools is shown in Table 2.1.
LDF and Fibex Viewer are simple tools offered by Intrepid Control Systems for
personal use 89 . Next, FIBEXplorer is the well-arranged tool for Fibex files analysis10 .
There are many more tools for DBC files analysis. The first of these, Canmatrix Convert
is able to export DBC files to Excel 11 . This function has been verified. Above that,
the feature of converting ARMXL files to DBC files or XLS files is mentioned. This
functionality has not been working reliably though. This is mainly because there are
several AUTOSAR standard versions of ARXML files which differ from each other.
Other tool is cantools which allows extracting information from DBC files under Linux
platform 12 . The software Busmaster can be used as the demonstration of the conversion
from CAPL script language into C++. However, the generated C++ code is specifically
designated only for usage in Busmaster tool 13 .
7
Extensible Stylesheet Language Transformation
8
http://www.intrepidcs.com/support/ldftool.htm
9
http://www.intrepidcs.com/support/fibexviewer.htm
10
http://sourceforge.net/projects/fibexplorer/
11
https://github.com/ebroecker/canmatrix
12
http://sourceforge.net/projects/cantools/
13
http://rbei-etas.github.io/busmaster/
4/75
CHAPTER 2. SOFTWARE TOOLS
2.3 PROVEtech:TA
PROVEtech:TA is a software tool developed by MBtech Group for control and au-
tomation of test systems. It allows a user to interactively set and measure all relevant
state variables of a test system. Thus, the user can set signals and transmit messages
for different test scenarios. For the optimal testing, it offers a user-friendly test man-
ager for administration of test scripts and test results. The test manager is further
described in Section 2.3.2. During a measurement, the values of one or multiple signals
can be acquired and stored for further evaluation. PROVEtech:TA can also be used
for implementation of real-time test scripts which run directly on a connected real-time
hardware. PROVEtech:TA supports systems description based on formats DBC, LDF
(LIN bus), Fibex (FlexRay bus) and ARXML. Other important part of PROVEtech:TA
is the workspace. A user can add different controls such as switch controls, sliders, etc.
The workspace exchanges signals with the simulation model which usually runs on a
real real-time computer and provides the ECU environment. The configuration of the
workspace is described in Section 3.3.3. Moreover, the diagnostic module with the user
interface is included in the software. It allows access to all diagnostic services, that are
provided by the ECU under test. PROVEtech:TA also includes the fault simulation
model that enables injecting of electrical faults in order to test ECU reaction in hard-
ware and software. The test language for writing scripts in PROVEtech:TA is WinWrap
Basic. It is described in Section 3.5.1.
The PROVEtech tool suite is equipped with PROVEtech:RE as well. PROVEtech:RE
is a test platform designed for PCs running under Microsoft Windows or INtime oper-
ating system. PROVEtech:RE is described in Section 2.3.5.
Moreover, PROVEtech:TA includes the Automation Library which provides fun-
damental methods for accessing a model computer which is running the Real-Time
Automation Engine (RTAE), such as PROVEtech:RE or a real-time computer. [6]
2.3.1 Workspace
The workspace of PROVEtech:TA is divided into two parts, the workpage and the cock-
pit. They offer the same features, though the cockpit always stays visible. The workpage
offers a wide range of display elements for the simulation and signal visualization such as
sliding displays or switch controls. A user can place several workpages to the workspace.
The workpage exchanges signals with a simulation model, which usually runs on a real-
5/75
CHAPTER 2. SOFTWARE TOOLS
2.3.3 Diagnostics
The diagnostics module allows the access to all diagnostics services which are provided
by an ECU under test. Furthermore, the error storage can be accessed and internal
6/75
CHAPTER 2. SOFTWARE TOOLS
ECU data can be displayed. The other diagnostic functions like coding and flashing of
ECUs are also supported. All diagnostic functions can be accessed via the graphical
user interface as well as test scripts. The communication with the ECU is handled by
using a dedicated diagnostic hardware. An example of the diagnostics window is shown
in Fig. 2.2.
7/75
CHAPTER 2. SOFTWARE TOOLS
and pin-to-pin failures. Afterwards, it can be checked whether the fault was recorded
in the diagnostic memory. Additionally, PROVEtech:TA also contains visual panels to
control the failure simulation for both, ECU pin failures and CAN line failures. An
example of the fault simulation is shown in Fig. 2.3.
2.3.5 PROVEtech:RE
PROVEtech:RE is runtime environment which enables PROVEtech:TA to access many
types of hardware devices, for example Vector CANcase used during this project. It also
contains a simulation engine which can be used for rest-bus simulation. It is a Windows-
based program. It is basically an ”invisible” program running in the background without
its own user interface14 . Furthermore, it upports standard automotive interfaces and bus
systems such as CAN, LIN, FlexRay, etc. The most important feature for this project
includes the rest-bus simulation creation. The configuration of rest-bus simulation is
described in Section 3.3. However, additional features comprise generation of signal
waveforms or behavioral models, or Simulink model integration. [6]
8/75
CHAPTER 2. SOFTWARE TOOLS
process, CANoe can be used to create simulation models which simulate the behavior
of an ECU. Further these models serve as the basis for analysis and testing of whole
systems. Similarly as in PROVEtech:TA, a user can interactively adjust signals and
messages for different test scenarios. CANoe contains several windows for the analysis.
These windows are described in Section 2.4.2. The workspace of CANoe can consist of
the windows mentioned. Furthermore, the workspace usually consists of panels. The
panels are graphical control elements. They are described in Section 2.4.1. CANoe
also contains a diagnostic feature set for diagnostic communications with the ECU.
Various bus systems are supported. Among them are CAN, LIN, FlexRay, or Ether-
net. Above that, CAN-based protocols are e.g. J1939, CANopen, or CANaerospace.
Among supported system descriptions are DBC, LDF, Fibex or ARXML formats. The
test language for writing scripts in Vector CANoe is CAPL. It is described in Section
4.4.3.
2.4.1 Panels
The workspace of Vector CANoe may consist of panels. The panels are graphical control
elements such as standard buttons, check boxes, radio buttons, up to LCD controls,
meters or even media players. These elements can be used to modify signal or variable
values. The configuration of the panels is carried out in the panel designer, and is
described in Section 3.4.2. The panels can then be opened in the workspace as separate
windows.
• Insert filters – used to reduce the amount of data displayed, or even delete some
data from the data stream
• Set markers – markers are assigned to an event and its time stamp; used to quickly
find events
9/75
CHAPTER 2. SOFTWARE TOOLS
• Log data
An example of the trace window is shown in Fig. 2.4.
Figure 2.4: An example of trace window with active filter and marker [2]
10/75
CHAPTER 2. SOFTWARE TOOLS
via CAPL or via pre-configured events. Individual trigger conditions can be combined
using the logical OR function. Another function is the ability to compare signals in
different approaches. The scope windows can be completely controlled from a CAPL
test module. An example of the scope window is shown in Fig. 2.6.
• Search for error – errors can be searched and functions can be monitored based
on analysis of the time response of states, signals and state transitions
11/75
CHAPTER 2. SOFTWARE TOOLS
12/75
Chapter 3
Rest-bus Simulation
This chapter explains the term rest-bus simulation, as well as steps needed for creat-
ing of such a simulation. The whole procedure of creating a specific rest-bus simulation
includes several steps. The procedure obviously varies for different software tools. For
PROVEtech:TA these steps are:
13/75
CHAPTER 3. REST-BUS SIMULATION
14/75
CHAPTER 3. REST-BUS SIMULATION
15/75
CHAPTER 3. REST-BUS SIMULATION
message_id
message_name
start_bit: the position of the first bit; for little endian byte order the position
of least-significant bit is given, for big endian byte order the position of most-
significant bit is given
16/75
CHAPTER 3. REST-BUS SIMULATION
(factor, offset): defines values for the linear conversion rule to convert the
signal’s raw value into the signal’s physical value – physical_value = raw_value
* factor + offset
receiver: name of the node receiving the signal; if the signal has no receiver or
is unknown, the name is Vector__XXX
The message structure with defined signals and an example of the implementation are
as follows:
BO_ message_id message_name : message_size transmitter
SG_ signal_name m ul t ip le x er _i n di c at or : start_bit | signal_size
@ byte_order value_type ( factor , offset ) [ min , max ] unit
receiver
17/75
CHAPTER 3. REST-BUS SIMULATION
attribute_name
UNIT: the physical measurement unit; all units defined should be SI units
SW-BASE-TYPE: the meta class; represents a base type used within ECU software
COMPU-METHOD: the meta class; expresses the relationship between a physical value
and a mathematical representation
18/75
CHAPTER 3. REST-BUS SIMULATION
ECU-INSTANCE: used to define the ECUs used in the topology; includes these
important sub-tags
ASSOCIATED-COM-I-PDU-GROUP-REFS: helps to identify which ISignalIPduGroup
are applicable for which ECU
COMM-CONTROLLERS: communication controllers of the ECU,
e.g. CAN-COMMUNICATION-CONTROLLER
CONNECTORS: all channels controlled by a single controller
SLEEP-MODE-SUPPORTED: specifies whether the ECU instance can be put to
the low power mode
WAKE-UP-OVER-BUS-SUPPORTED: specifies whether wake-up over bus is sup-
ported
CAN-CLUSTER: CAN bus specific cluster attributes
I-SIGNAL: Signal of the interaction layer (IL). The run-time environment (RTE)
supports so called ”signal fan-out” where the same system signal is sent in different
SignalIPdus to multiple receivers. The System Signal is unique per System. To
support the RTE ”signal fan-out” each SignalIPdu contains ISignals. If the same
System Signal is to be mapped into several SignalIPdus there is one ISignal needed
for each ISignalToIPduMapping.
FRAME: describes the attributes of each frame; important sub-tag is PDU-TO-
FRAME-MAPPING which defines the composition of Pdus in each frame
I-PDU-GROUP: refers to the I-PDUs that should be always kept together
END-TO-END-PROTECTION: the meta class; represents the ability to describe a par-
ticular end to end protection
19/75
CHAPTER 3. REST-BUS SIMULATION
After that, other configuration file in the XML format must be created in order for
PROVEtech:RE to be able to communicate on the CAN bus. This configuration file
is PROVEtech specific. At this time, no tool is available for the generation. Thus, it
must be created manually. To generated this XML specific file, DBC file or ARXML
file, and RBS descriptor XML are needed. The structure of this XML is described in
Section 3.3.2.
Now, the rest-bus simulation configuration can be loaded in PROVEtech:TA. PROVEtech:RE
is connected by selecting Settings → Configurations → Add Configuration. In the
new configuration, a new model must be created. In the new model, hardware type
PROVEtech:RE must be selected, and the path to the XML configuration file is added.
Finally, the workspace can be adjusted in PROVEtech:TA. This means, for example
adding signals needed during the rest-bus simulation or adding a message window where
all sent and received messages are displayed. The setup of the workspace specific for
this project is described in Section 3.3.3.
It is important to mention that the most of the rest-bus simulation in PROVEtech:TA
is carried out by PROVEtech:RE. It enables connecting the real hardware into PROVEtech:TA,
as well as creating the rest-bus simulation. More about PROVEtech:RE can be found
in Section 2.3.5.
20/75
CHAPTER 3. REST-BUS SIMULATION
The RBSConfig tool enables changing other attributes, e.g. Cycle time, Delay time,
etc. To make the rest-bus simulation enabled, the attribute IsRbsEnable must be set
to True. After that, the RBS descriptor can be generated by selecting Configuration →
Save all as XML. The generated XML file also includes a new signal TX enable which
enables sending messages in PROVEtech:TA.
21/75
CHAPTER 3. REST-BUS SIMULATION
22/75
CHAPTER 3. REST-BUS SIMULATION
scripts can be edited. After the node configuration has been established and test scripts
compiled, whole project must be compiled by selecting Configuration → Compile All
Nodes.
23/75
CHAPTER 3. REST-BUS SIMULATION
• Diag – contains the necessary methods for the diagnosis of control units via the
diagnostic tool CAESAR from Daimler and I+ME ACTIA (built into the test
system) available
• Dgn – allows access to the MCD-3 D diagnostic classes, i.e. to every diagnostic
service and diagnostic job
• GUI – commands for controlling the workpage and the cockpit of PROVEtech:TA
• Measure – provides methods for managing data acquisitions, i.e. start/stop data
acquisition, save signal curves, etc.
• System – manages signals, a test protocol with sub-protocols and provides general
system functionality
Further, Evaluation class provides commands for evaluating data acquisition. In order
to use this class, it is necessary to create its instance first.
• instruction Return
Visual Basic in general does not use semicolons to terminate fragments of code. All
functions or procedures, as well as control statements must be ended by the relevant
24/75
CHAPTER 3. REST-BUS SIMULATION
End, e.g. End Sub, EndIf, Wend2 , etc. WWB-COM offers many data types (only the
type char is missing3 ). A full documentation of syntax can be found at [10].
As mentioned in Section 3.5.1.1, PROVEtech:TA contains extensions that enable the
development of the rest-bus simulation by using WWB. Most importantly, it includes
the data type CanMsg that is used for the manipulation with messages on a bus. Other
message types for LIN or FlexRay messages are introduced as well. Moreover, it contains
objects for message filters or message queues. The name of an object must always
precede a particular function. Example is shown below:
1 Sub Main
2 System . SetSignal ( " testSignal " ,10.5)
3 Measure . Start
4 Wait 10
5 Measure . Stop
6 End Sub
3.5.2 CAPL
CAN Access Programming Language (CAPL) is a programming language inspired by
the syntax of the C programming language. CAPL is primarily used with PC-based
environments Vector CANalyzer and mostly CANoe. This language has been developed
in order to meet requirements for the development of distributed embedded systems
based on CAN bus. During these days however, other buses such as LIN or FlexRay
are supported. With CAPL programs it is possible to simulate a network and node
behavior, and to perform bus testing and analysis. Therefore, comprehensive tests can
be carried out because the user does not rely only on CANoe tool itself. CANoe however,
includes CAPL browser that is the primary editor for CAPL language, including the
compiler for a created code.
char, byte, int, word, long, dword, float, double, message, timer, msTimer
2
ending of while statement
3
data type Byte or String can be used instead
25/75
CHAPTER 3. REST-BUS SIMULATION
For creating expressions, several operators are introduced, including arithmetic opera-
tors, assignment operators, bitwise operators, etc. Then there are statements that are
equivalent to those in the C programming language. Among them
• Declaration and initialization of variables
• Arrays
• Expressions
• Control statements.
After that, there are features that are CAPL specific. First, the declaration of global
variables is done inside the section variables. The example is given below:
1 /* @@var */
2 variables { ... }
3 /* @@end */
Next, CAPL is organized in so called event procedures. Each event is associated with a
single event. When the event occurs, the corresponding procedure will execute. These
events include e.g. reception of a message (on message), expiration of a timer (on
timer), change in an environment variable (on envVar), etc. These event are classified
as follows:
• Message events
• Timer events
• Keyboard events
• Controller events
• Variable events
Furthermore, a user can define its own functions like in C language. However, CAPL
has additional functions that provide a variety of special purpose operations that are
useful during the rest-bus simulation. These functions may be e.g. setting a value of a
signal, reading a name of database name, sending a message, resetting a controller, etc.
26/75
CHAPTER 3. REST-BUS SIMULATION
and delivered to a customer with a created rest-bus simulation. These OEM specific
DLLs can introduce new functions that can be later used during the rest-bus simulation
for various purposes.
Data Types
Some of the data types exist in WWB under different name. First of all, char is not
present in WWB-COM. The type String is used instead. The numerical data types
are in Table 3.1.
Furthermore, CAPL contains enumeration data types message, timer and msTimer.
These data types do not have exact equivalents in WWB. The data type message is
provided to WWB by PROVEtech:TA library. However, messages need to be declared
little differently. CAPL declaration includes both, an identifier and variable name,
at once. In WWB, the name must be declared first and the ID can be subsequently
assigned by accessing an object. The example of both is given below:
1 message 0 x101 msg ; /* CAPL */
The type timer, or similar, does not exist in WWB. Due to this fact, the straightforward
usage of timers is possible only in CAPL. One possible option is to use the function
Wait. However, this command is not exact by means of real-time. For exact timing,
the Automation Library should be used [1]. By the time of writing this thesis, latest
information has been that timers should be available for PROVEtech:TA in the future.
Array Indexing
When declaring an array, a number specified in the array brackets in CAPL corresponds,
as in C language, to the size of an array. However, when declaring an array in WWB, a
number corresponds to the highest index as the lowest index is zero. Thus, the amount
of array elements is not specified. The following example shows the difference:
1 int arr [10] /* CAPL */
27/75
CHAPTER 3. REST-BUS SIMULATION
The array declared in WWB contains elements 0 to 9. Thus, it does contain same
amount of elements as the array declared in CAPL.
Moreover, CAPL supports expressions inside the array brackets, e.g. [index++].
This is not possible in WWB and has to be solved in another way.
For Loop
CAPL includes the C-style For loop. WWB allows two syntaxes of the For loop, both
different from CAPL though. First type is the iteration from one value to some final
value with an iteration step. For example:
1 For i = 1 to 1000 Step 100
2 Debug . Print i
3 Next i
Next possible implementation is Python-like For loop for iteration over set of items.
This kind of For loop has no equivalent in CAPL. For example:
1 For Each Document In App . Documents
2 Debug . Print Document . Title
3 Next Document
Jump Statements
WWB does not include these jump statements – break, continue. The statement
return is included in WWB-COM, therefore, it can be used in the same manner as in
CAPL.
Global Variables
The global variables in CAPL are defined inside the section variables { ... }. Be-
cause no such a section exists in WWB, it is recommended to place the global variables
28/75
CHAPTER 3. REST-BUS SIMULATION
Events
4
i.e. right after Sub Main
29/75
CHAPTER 3. REST-BUS SIMULATION
30/75
CHAPTER 3. REST-BUS SIMULATION
31/75
CHAPTER 3. REST-BUS SIMULATION
32/75
Chapter 4
Converter
33/75
CHAPTER 4. CONVERTER
Figure 4.1: An UML sequence diagram of the code translation from CAPL to WWB
34/75
CHAPTER 4. CONVERTER
the results and saves them to a file. If no changes are detected in the input source, the
tables are read from the cache. Otherwise, they are regenerated. [11]
• miscellaneous operators – ., ?, :
• others
The sub-category others, from the categories listed above, contains all other token
names that specify, for example a white space, parentheses, an identifier, a comment,
etc. The following code is an example of defined tokens:
1 tokens = [
2 # arithmetic operators
3 ’ PLUS ’ ,
4 ’ MINUS ’ ,
5 ’ TIMES ’ ,
6 ...
7 # others
8 ’ WS ’ ,
9 ’ LCBR ’ ,
10 ’ RCBR ’ ,
35/75
CHAPTER 4. CONVERTER
11 ’ ID ’ ,
12 ’ COMMENT ’ ,
13 ...
14 ]
This token list is then appended by a list that specifies reserved words and a list that
specifies different number formats, i.e. int, float and hex. The reserved words handle
all data types from CAPL, as well as keywords of control statements such as if, else,
etc.
1 reserved_words = {
2 ’ char ’ : ’ CHAR ’ ,
3 ’ byte ’ : ’ BYTE ’ ,
4 ’ int ’ : ’ INT ’ ,
5 ...
6 ’ void ’ : ’ VOID ’ ,
7 ’ if ’ : ’ IF ’ ,
8 ’ else ’ : ’ ELSE ’ ,
9 ...
10 ’ return ’ : ’ RETURN ’ ,
11 ’ default ’ : ’ DEFAULT ’ ,
12 ’ this ’ : ’ THIS ’ ,
13 }
14
15 ved_numbers = {
16 ’ dec_num ’ : ’ DEC_NUM ’ ,
17 ’ float_num ’ : ’ FLOAT_NUM ’ ,
18 ’ hex_num ’ : ’ HEX_NUM ’ ,
19 }
20
Each token is specified by writing a regular expression rule. Each of these rules are
defined by declarations with special prefix t_ to indicate that they define a token. The
regular expressions are defined by a string with prefix r. The simple regular expressions
are specified first for the tokens. The simple regular expressions include operator signs,
char, and so on. More about the regular expressions rules can be found in [13].
1 t_PLUS = r ’ \+ ’
2 t_MINUS = r ’\ - ’
3 ...
4 t_LSHIFT_EQ = r ’ \ <\ <\= ’
5 ...
Tokens with slightly more complicated expressions are listed, together with examples of
them, in Table 4.1. Moreover, the token CAPLEVENT_word must be mentioned separately.
It handles the keywords of CAPL events declarations. More can be found in Section
4.1.1.1. As the last, tokens that are defined as series of more complex regular expressions
are explained in Section 4.1.1.2.
When using the lexer, data are first fed into input method. After that, token is
called repeatedly to produce tokens. The following code shows the implementation of
36/75
CHAPTER 4. CONVERTER
The rest of events is not currently supported because they are outside the scope of
this thesis assignment. It can however be easily implemented by either modifying
t_CAPLEVENT_word token rule or by creating a new token with a specific token rule.
37/75
CHAPTER 4. CONVERTER
1 @TOKEN ( t_ID )
2 t_RESERVED ( self , t ) :
3 t . type = self . reserved_words . get ( t . value , ’ ID ’)
4 return t
This function identifies the token rule t_ID and assigns a value of an entry from the
reserved words set.
Complex regular expressions (i.e. built from series of regular expressions) are han-
dled by a function in the form t_FunctionName(self,t). These regular expressions
include – different formats of digits (float and hex), array brackets (e.g. [10][10]),
the declaration of CAPL events (on keyword, e.g. on message) and specific CAPL
header and footer comments that circumscribe either CAPL events or functions (e.g.
/*@@message:msg:*/, /*@@end */). The following example shows the function for de-
tecting token CAPLEVENT. This token is built from series of complex regular expressions
that are defined in the decorator on_event_declar.
1 on_event_declar = r ’( on ’ + t_WS + r ’) +( ’ + t_CAPLEVENT_word + r ’) + ’
2
3 @TOKEN ( on_event_declar )
4 t_CAPLEVENT ( self , t ) :
5 return t
Another functions for handling another complex regular expressions are written in the
same manner.
4.1.2 Parsing
The Yacc module (yacc.py) is used to parse language syntax. The name ”yacc” stands
originally for ”Yet Another Compiler Compiler”. The syntax is specified in terms of
Backus-Naur Form (BNF) grammar. An example of such a unambiguous grammar
might look as follows:
expression : expression + term
| expression - term
| term
factor : NUMBER
| ( expression )
In the grammar, symbols such as NUMBER, +, −, are known as terminals. They cor-
respond to raw input tokens. Identifiers such as term or expression are known as
non-terminals. They refer to grammar rules consisting of terminals and other rules.
This grammar is defined in docstrings which are then inserted into a Python code. As
an example, the simple arithmetic expression from the previously described grammar
is shown:
38/75
CHAPTER 4. CONVERTER
1 def p_expression_plus ( p ) :
2 ’ expression : expression PLUS term ’
3 p [0] = p [1] + p [3]
The expression grammar given in the previous example has been written in order to
eliminate ambiguity. However, generally it is very difficult to write grammar with all
ambiguity eliminated. The dealing with ambiguous grammar is described in Section
4.1.2.1.
Yacc uses the LR parsing. LR parsing can be called shift-reduce parsing as well. It
is the bottom up technique that tries to recognize the right hand side of grammar rules
first. During LR parsing, symbols are shift onto a stack. After that, it is looked up on
this stack and the next input token, and it is searched for patterns that match one of
the grammar rules. When a valid right hand side is found on the top of the stack, it
is usually reduced and the grammar symbols are replaced by the grammar symbol on
the left hand side. To understand this principle, the parsing of 1 + 2 expression is given
according to unambiguous grammar mentioned at the beginning of this section.
Step Symbol stack Input tokens Action
---- ------------ ------------ ------
1 1 + 2 Shift 1
2 1 + 2 Reduce factor : NUMBER
3 factor + 2 Reduce term : factor
4 term + 2 Reduce expression : term
5 expression + 2 Shift +
6 expression + 2 Shift 2
7 expression + 2 Reduce factor : NUMBER
8 expression + factor Reduce term : factor
9 expression + term Reduce expression :
expression + term
10 expression Reduce expression
11 Done .
In the project specific implementation, the Parser class is implemented in the file
parserPy.py. Each grammar rule is then defined by a separate function. The function
accepts an argument p. Under the index p[i], it contains the corresponding value
of a symbol in the given rule1 . The function p_error catches the syntax errors, i.e.
any undefined rules in the grammar context. If any syntax error is caught, the output
containing the corresponding value of a symbol and the corresponding line number will
be printed to the console. [11]
39/75
CHAPTER 4. CONVERTER
on a stack or reduce. By default, all shift/reduce conflicts are resolved in favor of shift-
ing. This may, for example, introduce problems during parsing arithmetic expressions.
To resolve ambiguity, the Yacc module allows assigning a precedence level to individual
tokens. This is done by adding the following type of code:
1 precedence = (
2 ( ’ left ’ , ’ PLUS ’ , ’ MINUS ’) ,
3 ( ’ left ’ , ’ TIMES ’ , ’ DIVIDE ’) ,
4 ...
5 )
The description of the AST for this project will be accompanied by displaying some
parts of the AST. The appropriate description will follow in such a manner, that a
reader can get acquainted how the AST is built and what syntax to use in order to ease
a translation to WinWrap Basic or C when creating an input file. The terminals in the
AST can be recognized by upper-case letters. Even though, it is assumed that a user
will built the AST for a CAPL code that has already been compiled in some CAPL
editor, by understanding the AST a user can easily identify errors in CAPL syntax that
would lead to a malfunction of the parser.
By understanding the AST, a user can easily identify a syntax for which the parser
does function properly.
First of all, the whole program is divided into code_fragments. Each code_fragment
represents a node, that can be of four different types.
40/75
CHAPTER 4. CONVERTER
The terminal CAPLEND is a CAPL specific comment that appears at the end of every
section, specifically /*@@end */.
The Fig. 4.2 shows the structure of a fragment for declaring a user-specific function.
The terminal CAPLFUNCBEGIN is a CAPL specific comment which must also include the
name of a user-defined function. It is followed by a user-function declaration and a
compound statement. Example is shown in Listing 4.1.
The Fig. 4.3 shows the structure of a fragment for declaring CAPL events.
Capl_event_declaration includes both, the CAPL specific comment and declaration
of an event. There are only two differences from user-defined functions. First, the
CAPL specific comments are different in content. Second, the CAPL events do not
take any parameters. The table 4.2 shows the supported CAPL events.
Fig. 4.4 shows the structure of a fragment for declaring global variables. This
is exactly the same as declaring CAPL events with the difference in comment and the
declaration itself. The comment with declaration goes as /*@@var:*/ variables{...}.
41/75
CHAPTER 4. CONVERTER
The last code fragment are comments. The node COMMENT is either an one-line or
multi-line comment like in C language.
As can be seen, compound_statement is the key part of every fragment. The com-
pound_statement is bordered with curly braces. Inside curly braces are block_items.
The block_item can be of five different types:
declaration, assignment, statement, case_statement, comment.
42/75
CHAPTER 4. CONVERTER
• node ID – e.g. x
The next structure of declaration, which is also not displayed, represents node Array,
and contains only array_brackets above the entry, e.g. x[ ], y[5][5]. Subsequently,
another structures of declarations (node Assign, node Assign_OP, node Assign_array)
already contain leaves expression. These structures represent assignments. The struc-
tures are shown in Fig. 4.6. It is apparent that the structures always contains entry
43/75
CHAPTER 4. CONVERTER
As will be further explained, the parser gradually proceeds through as follows – log-
ical_expression/conditional_expression → binary_epression → unary_expression.
The logical_expression is described beforehand. It may bind recursively two
expressions by either a logical AND (&&) or a logical OR (||). If they are bound
by a logical operator, they represent the node Logic_EXPR. The structure of logi-
cal_expression is following:
• binary_expression
Next, the binary_expressions may either stand for unary_expression, or may bind
recursively two expressions by either a relational operator or a bitwise operator. Sim-
ilarly as in the previous case, if they are bound together they represent the node Ex-
pression. The unary_expression can have the following forms:
• single_expression
• value_expression
• capl_function_body
The single_expression stands for a unary operation, i.e. the increment or decrement
of a variable (postfix or prefix), a variable’s complement or logical NOT. Behind the
term value_expressions may be either a variable, a variable with array brackets3 , a
constant (character or number), or a so called message_signal. It is important to say
that a number can be either in decimal or hexadecimal format. The message_signal
represents the message name paired together with the signal name by a double colon,
e.g. message control::signal button. The capl_function_body represents the node
CAPL_fcn. It is simply any function’s name with or without parameters inside paren-
theses (as shown in Fig. 4.7).
To make it clear, listing 4.2 shows examples of possible expressions.
Listing 4.2: Examples of expressions
1 x + y && z << 1 // logical_expression
2 x + y , z << 1 // binary_expression
3 x ++ , y ++ , ++ x , --x , ~x , ! x // single_expression
4 x , arr [] , 999 , 0 x1FF // value_expression
5 function1 () , function2 (x , y ) // capl_function_body
3
e.g. var[ ]
44/75
CHAPTER 4. CONVERTER
All of these statements are equivalent to the statements in C language, except the
capl_function. Therefore, they do not have to be extensively described. However, a
short overview is presented. The capl_function has already been previously described.
It corresponds to the expression capl_function_body. It is a name of a function either
with or without parameters ended by a semicolon, e.g. function(x,y);.
The compound_statement has already been completely described as well. It may
contain declarations, assignments or other statements.
At all other control statements, control statements must be placed inside curly
braces. Otherwise, the parser will produce an error and the parsing process will crash.
Below is an example of a working and a non-working case:
1 if ( speed < 100) { cruise_speed = 100; } // working
2 if ( speed < 100) cruise_speed = 100; // non - working
The if_statement has two possible forms. First option is the statement without
else, the other contains an else statement. To make it clear, the structure of the
if_statement with else is shown in Fig. 4.9. That picture presents the idea how
all control statements are parsed. Similarly, while_statement and switch_statement
consist of the control keyword followed by a control statement inside parentheses and
the compound_statement. The case_statement is parsed apart from the control state-
ments since it has a different structure. As in C language, do_while_statement places
the control statement at the end terminated by the semicolon. The for_statement
must include all three parts of the statement. It is not possible to implement For loop
45/75
CHAPTER 4. CONVERTER
in a manner such as for(; number != 0 ;) { ... }. The first part, i.e. the initial-
ization of a variable both may and may not include the type of variable. However, it is
recommended to use the variable type due to easier translation to other languages.
4.2 Translator
After the CAPL code is parsed, it can be translated to other languages. How the
translator works for translation to WinWrap Basic is described in Section 4.2.1. The
translation to the C language would be carried out similarly. The complete translation
to the C language has not been developed, because for the creation of a full-fledged
rest-bus simulation not only translation of test scripts from one language to another
is sufficient. A simulation engine, which procures the rest-bus simulation based on an
input DBC/ARXML file, is needed. Even though, the complete translation to C has
not been developed, adding this feature to the translator part should be straightforward
because CAPL is very similar to C. Nevertheless, the concept of translating events that
react on received messages is proposed in Section 4.2.2.
46/75
CHAPTER 4. CONVERTER
1 ’ WWB ’
2 Dim x as Int
3 Dim y as Int
4 Dim z as Int
On the other hand, a subtree of the following node types may be found (as explained
in Section 4.1.2.2.1):
An array must be declared with some dimensions. Therefore the function gener-
ate_array is used in order to separate array brackets and obtain the numbers of relevant
dimensions. The function generate_array has the following input parameters:
1 ’ WWB ’
2 Dim x (10 ,10) as Int
4
i.e. right after Sub Main
5
WWB is not case-sensitive though, thus the types do not have to start with an uppercase letter
47/75
CHAPTER 4. CONVERTER
When the node has the type Assign, the assignment is generated after a line of the
declaration (i.e. as if no assignment would follow) has been put on the previous line.
The function generate_code is called recursively with the relevant subtree as the input
parameter. The generation of an assignment is described in Section 4.2.1.1.3.
The node Assign_Array works on the same principle. It first generates code for
the declaration of an array, then the assignment of values into array’s positions. The
assignment into the array’s positions is described in Section 4.2.1.1.4. Declarations with
an assignment can be seen in the examples 4.5.1 and 4.5.2. The example 4.5.3 contains
a simple declaration. The example 4.5.4 shows the declaration of arrays.
1 ’ WWB ’
2 x = arr (i , j )
If the node Expression is assigned to a variable, the translator continues again recur-
sively to the function generate_code with the relevant subtree as the input parameter.
It should be clear from Section 4.1.2.2 that a call of a function is one of the subtrees in
the node Expression. The generation of expressions is described in Section 4.2.1.1.5.
The function generation is then described in Section 4.2.1.1.6. Assignments of simple
variables is shown in examples 4.5.1 and 4.5.2. The example 4.5.3 shows the assignment
of an expression, whereas the example 4.5.5 shows the assignment of a CAPL function.
1 ’ WWB ’
2 Dim x (2 ,2) as Int
3 x (0 ,0) = 1
4 x (0 ,1) = 10
5 x (1 ,0) = 99
6 x (1 ,1) = 2
48/75
CHAPTER 4. CONVERTER
1 ’ WWB ’
2 Function Function1 ( x as Double ) as Int
3 ...
4 End Function
49/75
CHAPTER 4. CONVERTER
is carried out based on the function’s name. For illustration, few frequently used func-
tions in rest-bus simulations were chosen. Other functions can be easily implemented.
However, many functions supported by Vector CANoe (i.e. CAPL language) are not
supported by PROVEtech:TA and their translation is outside the scope of this project.
The selected functions and their description can be found below:
• CAPL syntax: getSignal(signalName)
WWB syntax: System.GetSignal signalName
description: gets the value of a signal
parameters: signalName – the name of a signal to be polled
50/75
CHAPTER 4. CONVERTER
of the relevant subtree contains a control expression which is then recursively gener-
ated by calling the function generate_code. The children of the subtree represent the
code inside a compound statement. This code is again generated by the function gen-
erate_code. The control statement ends with a keyword belonging to the particular
control statement, e.g. If ... End If.
The Switch is translated in a similar way as statements described above. However,
the children of the subtree contain several cases that may be selected during switching.
Due to this fact, the converter walks iteratively through the children. For every child,
the code belonging to the particular case is then generated.
Since the For statement is far different in CAPL and WWB, only the translation of
simple For loops has been implemented. The word simple means that For loop written
in CAPL should include the number till which the loop should be iterated and the size
of iteration step. The code inside the statement cannot be generated if this condition
is not satisfied. Example of the For statement may look as follows:
1 // CAPL
2 for ( i = 1; i < 10; i ++) { ... }
1 ’ WWB ’
2 For i = 1 to 10 Step 1
3 ...
4 Next i
Considering the jump statements, only Return is translated because WWB does not
include any other jump functionality. Other jump statements will not be translated.
The examples of control statements are shown in the examples 4.5.2 and 4.5.3.
1 ’ WWB ’
2 Sub On_Start
3 ...
4 End Sub
5 Sub On_message_msg
6 ...
7 End Sub
51/75
CHAPTER 4. CONVERTER
4.2.2 Translation to C
Translation to the C language is carried out in the same manner as the translation to
WWB (described in Section 4.2.1). Due to the fact that CAPL has almost the same
syntax and semantics as C, whole translation process is not described. However, CAPL
includes a feature of reacting on a received message. This event is called on message.
When the particular message is received, the relevant procedure is started. The main
focus of this section lays in introducing a feature of translating the reaction on received
messages to the C language. The SocketCAN framework, together with the libev library
are used for this purpose. SocketCAN is the framework for CAN bus under Linux. Is
has been designed to allow socket communication similarly as possible to the TCP/IP
protocols [14]. The methods used for communication on the bus are described in Section
4.2.2.1. The libev is a high-performance event loop with many features [15]. The most
important feature for this project are I/O watchers. The concept of implementing this
library which reacts to a received message and triggers a relevant event is described in
Section 4.2.2.2.
From the programming point of view, the CAPL and SocketCAN/libev reaction
on messages has showed not to be the one-to-one equivalent. CAPL has an assigned
database with IDs and names of all messages. The on message simply waits for a par-
ticular name of message and triggers the relevant procedure. By using the SocketCAN
however, it is, first of all, checked whether the IDs match the IDs from the database.
In case an exact equivalent is needed, the database with message names would proba-
bly need to be linked to the C program. From the rest-bus simulation point of view,
PROVEtech:TA and Vector CANoe use the actual drivers by vendors’ of CAN to USB
converters to connect to the Windows operating system. The usage of SocketCAN how-
ever, seems as an interesting alternative for devices with the Embedded Linux platform.
The drawback is that the usage of SocketCAN and libev represents solution only for the
CAN bus. Commercial software tools most frequently contain possibility of creating a
rest-bus simulation even for other buses such as LIN or FlexRay.
52/75
CHAPTER 4. CONVERTER
socket consists of reading the structure can_frame. To read a received frame, the func-
tion read is called. On success, the number of read bytes is returned. The function
read_port returns the ID of a received frame. The idea here is to process this ID9 , and
based on a recognized message further call a right handler by a libev library callback.
To write CAN frames on a socket bound to the CAN interface, the function send_frame
is used. This function takes a file descriptor and structure of a CAN frame as the in-
put parameters. The write call is located inside this function to send frames over the
network. The number of sent bytes is returned in case of success.
53/75
CHAPTER 4. CONVERTER
send_frame. The function delay is called. It ensures that an I/O watcher is started
after one second. This watcher calls a callback recvmsg_cb. This callback ensures that
the data are read every specified period of time by calling read_port. Furthermore,
the message is printed depending whether bits has been set correctly.
4.3.1 Implementation
Since several XVP files should be converted into one AOF, the GUI of created converter
enables selecting multiple input XVP files which will be converted into one AOF file.
Thus, XVP files need to be iteratively processed and converted into one single file.
XSLT contains the wrapper type ElementTree. The ElementTree enables loading of
an XML file as set of Element objects. These objects are designed to store hierarchical
data structures such as XML. After a file has been selected, the transformation is run
on XML code in order to get the ElementTree by calling the function etree.parse,
where the file path is the only input parameter.
After that, the function tree.xpath is used several times during the conversion
process. This function performs a XPath query for nodes of the ElementTree. First of
all number of objects is found by counting number of Object tags. The ID is assigned
to every object when iteratively exploring every object’s properties.
Inside the Object tag, only its type is important. The type must be found for every
object. For example:
1 < Object Type = " Vector . CANalyzer . Panels . Design . CheckBoxControl , ... "
>
Obviously, the whole type property must be split in order to separate the actual type,
such as CheckBoxControl. In this project objects CheckBoxControl and ButttonCon-
trol are used. Nonetheless, the enum type in the code is prepared for the conversion of
54/75
CHAPTER 4. CONVERTER
other CAPL default controls. Afterwards, Property tags are processed. Some proper-
ties’ meaning is obvious. Those are Name, Size, and Location. The tag Text includes
the text that is displayed on the control. The very important property is SymbolCon-
figuration. This property includes several values separated by the semicolon. First
two numbers are not important for the conversion at all. After them, the values go in
following order – a database name10 ; a node name11 ; a message name; a signal name;
default value of the signal; name of a DBC file. There are two lists created:
• controls_list – stores the ID of an object, a belonging node, message, signal
and DBC file
• design_list – stores the objects’ position, size and label
These two lists are sufficient for the generation of an AOF file.
Objects of controls are prefixed by the text BOOLCONTROL=Signalschlüssel:. After
this prefix, all properties of an object are written in one line separated by the semicolon.
First, the whole signal ”path” is listed, i.e. the direction together with the name of node,
message and signal. During this project, the controls on the workspace deal only with
sent signals during the rest-bus simulation. Therefore the direction TX is set implicitly.
The example below shows a possible implementation:
1 BOOLCONTROL = Signalschl ü ssel:TX . Control . Control_Actuator . OnKey ; ...
As next, the name, position and size are listed. The position and size need to be
recalculated. CANoe considers the position and size values in pixels. On the other
hand, PROVEtech:TA uses its own scale. One horizontal step in the position, as well
as one piece of the button width equals 49 pixels. One vertical step and one piece of
the button height equals 25 pixels. Due to this reason, the position and size must be
recalculated before placing it in the AOF file.
For the position, the following calculation is performed:
. xXV P
xAOF = −L
h
. yXV P
yAOF = ,
v
where xAOF and yAOF are positions in the AOF file, xXV P and yXV P are positions in the
XVP file, dividers h and v determine how large will be the horizontal and vertical space
between individual controls, and L moves all controls to the left side. The constants h,
v and L may be largely modified for other projects.
For the size, the width of a control is determined based on the width of its label.
The height is then only converted from pixels to PROVEtech:TA scale. This project
uses the following equations:
. len(name)
wAOF =
5.5
. hXV P ∗ 1.5
hAOF = ,
25
10
CANdb, i.e. includes all messages and signal used during the rest-bus simulation
11
one node equals one ECU
55/75
CHAPTER 4. CONVERTER
where wAOF and hAOF are sizes in the AOF file, hXV P is the height in the XVP file,
and len(name) is the length of a label.
All the attributes after YSize in the AOF file for an object can be pre-set. These
include, for example the color of a button, a text alignment, etc. As mentioned at the
beginning of this section, the conversion of GUI is a very complex problem. The GUI
conversion for this project has been successful, however it is not very neat. Nevertheless,
it provides a user with the generated workspace for PROVEtech:TA which can be very
easily modified. It is completely up to the user which changes will take place, but the
modification will most probably include changing the button sizes or positions.
4.4 Usage
This section describes how the converter should be used. The Section 4.4.2 describes
the general usage of the program. That is, what steps should be made after the program
is started. The Section 4.4.3 describes how the CAPL code should be written in order
to eliminate errors during parsing and translation to WWB.
4.4.1 Installation
The program is written in Python 3.4. It is necessary to have several Python modules
available during a compilation. The modules can be added by using the pip installer.
These modules are:
io, string, mmap, os, tkinter, lex, yacc
The lex and yacc modules are included in Ply package12 . For running the tool, tk-
interApp.py needs to be executed. After this file is executed, the GUI shows up.
Subsequently, a user navigates himself through the user interface as described in the
following section.
4.4.2 GUI
After the program is started, the window showed in Fig. 4.10a opens up. This window
is used for writing all necessary values into tags inside the rest-bus XML configuration
file for PROVEtech:RE. Without setting this XML file, the rest-bus simulation will not
be functional. The windows includes the following lines:
• P:RE config file – XML: the absolute path of the PROVEtech:RE specific XML
configuration file
• DBC/ARXML file: the absolute path of the DBC or ARXML file
• RBS file – XML: the absolute path of the so called RBS file where all messages
and signals for the rest-bus simulation are defined13
12
available at: http://www.dabeaz.com/ply/ply-3.6.tar.gz
13
generated by RBSConfig tool
56/75
CHAPTER 4. CONVERTER
• Port Name – CAN channel : the name of a specific CAN channel used during the
rest-bus simulation, e.g. CAN1
• Bit Rate: the bit rate for the CAN channel specified in Port Name – CAN channel
The bit rate used during this project is 250 000 kb/s because the bus is a high speed
CAN. The example of all set values is in Fig. 4.10b. When the button WRITE TO
P:RE XML is pressed, all values set in the fields mentioned above will be written to
the file cited in P:RE config file – XML.
When the button GUI & Code Conversion is pressed, the window showed in Fig.
4.11a opens up. In this window, the conversion of either GUI or the CAPL code is
triggered. There are two fields that need to be filled in (Select button may be used),
specifically:
• XVP file – GUI : the absolute path of the XVP file(s), i.e. of the CANoe GUI
• CAN file – CAPL: the absolute path of the CAPL file, i.e. the code
Three buttons at the bottom serve as the initalizators of either the GUI or the CAPL
code conversion. Whenever a particular button is pressed, the belonging action will
follow. The example of a filled in window is in Fig. 4.11b. An output generated file is
called generatedWorkspace.aof.
9 /* @@msg : message1 : */
10 on message message1 { ... }
11 /* @@end */
Next, even though the parsing of expressions consisting of several binary expressions
works fine, the translation to WWB has been successfully created only for single binary
expressions. Due to this reason, more complicated expressions should be split apart
into the binary expression on separate lines. Following example shows both, the right
and the wrong usages:
1 // WRONG :
2 x = y + z - 10;
57/75
CHAPTER 4. CONVERTER
1 // RIGHT :
2 x = y + z;
3 x -= 10;
The binary expressions may be bound together to a logical expression. If one of the
expressions on the side is inside parentheses, then the second one must be placed inside
the parentheses as well. Below there are two possible implementations:
1 if ( x != 0 && y > 0) { ... }
2 if (( x != 0) && ( y > 0) ) { ... }
Since the implementation of for loops is different in CAPL from those in WWB, only
the translation of simple for loops works. Under the word simple for loop is meant, that
the initialization variable must be included, the value till which the loop will iterate,
and the iteration step are included. The for loop can be implemented as follows:
1 for ( int i ; i < 10; i ++) { ... }
Moreover, when using a control statement, i.e. for, while, etc., the code must be
placed inside the curly braces. The implementation of control statements with no curly
braces is not supported.
Another unsupported feature include the possibility of an expression inside array
brackets, such as arr[++].
To avoid a crash during any translation process, unsupported translations do not
raise an error. However, a user should be aware of these test language restrictions, and
consequently make manual changes in a translated output file.
58/75
CHAPTER 4. CONVERTER
(a) blank
(b) filled in
59/75
CHAPTER 4. CONVERTER
(a) blank
(b) filled in
60/75
4.5 Examples
The example 4.5.1 shows the declaration of global variables. The message declaration
can be seen there. The example 4.5.2 shows the declaration of the user-defined function.
The processing of If statements is displayed here. The example 4.5.3 shows the same
user-defined function, however with usage of For statement. Also the processing of an
expression inside the For statement is shown. The example 4.5.4 shows the processing
or an array declaration and the assignment to arrays. The example 4.5.5 shows the
processing of the CAPL event on envVar with CAPL specific functions, and their
translation to WWB equivalent. The example 4.5.6 shows the processing of the CAPL
event on start followed by If statement containing expressions and function in the
input parameter.
61/75
62/75
CHAPTER 4. CONVERTER
4.5.1 Example 1
generate_code ( tree )
-> g ene ra te_ de cla ra tio n ( tree . child ) --- char letter_a = " a ";
ge ne rat e_d ec lar at ion ( tree . child )
-> generate_code ( tree . child . child )
-> gene rate_as signmen t ( tree . child . child ) --- int j , k = 2;
g e n e r a t e _ m e s s a g e _ d e c l a r a t i o n ( tree . child ) --- message 0 x101 msg ;
CHAPTER 4. CONVERTER
generate_code ( tree )
-> generate_function ( tree . child ) --- float speedTest ( float speed )
-> generate_code ( tree . child . child )
-> g ene ra te_ de cla rat io n ( tree . child . child )
-> generate_code ( tree . child . child . child )
-> gene rate_ass ignment ( tree . child . child . child ) --- float cruising_speed = 70;
generate_code ( tree . child . child )
-> generate_code ( tree . child . child . leaf ) --- speed >= cruising_speed
63/75
CHAPTER 4. CONVERTER
Figure 4.13: AST – the function, If statement
4.5.3 Example 3
generate_code ( tree )
-> generate_function ( tree . child ) --- float speedTest ( float speed )
-> generate_code ( tree . child . child ) --- for ( int i ; i < 10; i ++)
-> generate_code ( tree . child . child . child )
-> gene rate_ass ignment ( tree . child . child . child ) --- speed =
-> generate_code ( tree . child . child . child . leaf ) --- speed = speed ++;
generate_code ( tree . child . child ) return speed
CHAPTER 4. CONVERTER
Figure 4.14: AST – function, For statement
65/75
66/75
CHAPTER 4. CONVERTER
4.5.4 Example 4
1 /* @@caplFunc : myFunc () : */
2 void myFunc ()
3 {
4 int sample_data [4] = {100 ,300 ,500 ,600};
5 double M [2][2];
6 M [ x ][ x ] = -3.14;
7 }
8 /* @@end */
1 Sub MyFunc ()
2 Dim sample_data (3) As Integer
3 sample_data (0) = 100
4 sample_data (1) = 300
5 sample_data (2) = 500
6 sample_data (3) = 600
7 Dim M (1 ,1) As Double
8 M (x , x ) = -3.14
9 End Sub
generate_code ( tree )
-> generate_function ( tree . child ) --- void myFunc ()
-> generate_code ( tree . child . child )
-> g ene ra te_ de cla rat io n ( tree . child . child ) --- int sample_data [4] = {100 ,300 ,500 ,600};
-> generate_array
ge ne rat e_d ec lar at ion ( tree . child . child ) --- double M [2][2];
-> generate_array
gene rate_as signment ( tree . child . child ) --- M [ x ][ x ] = -3.14;
-> generate_array
Figure 4.15: AST – function, arrays
4.5.5 Example 5
1 /* @@envVar : initialize : */
2 on envVar initialize
3 {
4 ILSetSignal ( Ctrl_C_Stat1_AR :: ReturnKey_Psd_UB , 1) ;
5 x = getSignal ( Ctrl_C_Stat1_AR :: ReturnKey_Psd_UB ) ;
6 }
7 /* @@end */
CHAPTER 4. CONVERTER
1 Sub On_EnvVar
2 System . SetSignal ( " TX . CTRL_C . Ctrl_C_Stat1_AR . ReturnKey_Psd_UB " , 1)
3 x = System . GetSignal ( " TX . CTRL_C . Ctrl_C_Stat1_AR . ReturnKey_Psd_UB " )
4 End Sub
CHAPTER 4. CONVERTER
Figure 4.16: AST – CAPL event, specific functions
4.5.6 Example 6
1 /* @@startStart : start : */
2 on start
3 {
4 if ( readHandle != 0 && fileGetString ( timeBuffer , elcount ( timeBuffer ) , readHandle ) != 0)
5 {
6 setTimer ( cyclicTimer ,100) ;
7 }
8 else
9 {
10 write ( " Data file cannot be opened for read access . " ) ;
11 }
12 }
13 /* @@end */
1 Sub On_start ()
2 If readHandle <> 0 AndAlso fileGetString ( timeBuffer , elcount ( timeBuffer ) , readHandle ) <>
0 Then
3 setTimer ( cyclicTimer ,100)
4 Else
5 Debug . Print " Data file cannot be opened for read access . "
6
7 End If
8 End Sub
CHAPTER 4. CONVERTER
69/75
70/75
CHAPTER 4. CONVERTER
Figure 4.17: AST – CAPL event, logical expression
Chapter 5
Conclusion
At the early stages, basic testing of Vector CANoe and PROVEtech:TA by MBtech
was carried out on already created rest-bus simulations in order to get familiar with
these tools. During the next step, the rest-bus simulation for the head unit has been
successfully made functional for both, CANoe and PROVEtech:TA. The rest-bus sim-
ulation has been created for both formats of configuration files, i.e. DBC and ARXML.
After having created both rest-bus simulations successfully, a tool for converting the
rest-bus simulation from CANoe to PROVEtech:TA was developed. The automated
test scripts to the C language has been created as well.
The tool for converting the rest-bus simulation from CANoe to PROVEtech:TA
has been developed successfully – it has been proved directly at the MBtech company.
It allows the conversion of testing scripts from CAPL to WinWrap Basic as well the
conversion of basic GUI. Additionally, it supports automatic configuration of several
relevant settings in PROVEtech:TA specific configuration files. Because of the fact that
WinWrap Basic together with PROVEtech:TA libraries is quite different from CAPL,
the conversion of testing scripts is not one-to-one equivalent and so the translation of
some pieces of code is not possible (e.g. complicated For loops, or timers). Nevertheless,
the conversion works sufficiently for many test cases which are described in this thesis.
When translating automated test scripts from CAPL to WWB, it is assumed that a
user works with a CAPL code that has already been compiled in a CAPL editor. The
developed tool does not serve as a compiler. If a syntax error is detected during a trans-
lation process, the parser will raise an error and the program will crash. Furthermore,
if a user uses a CAPL input file that includes unsupported syntax by the translator, the
program will finish the translation. An output file must be manually modified because
it will contain translation errors as the consequence. The enhanced functionality of
translating unsupported syntax is planned to be added in future versions.
The feature of translating a CAPL code to the C language has been proposed as
a concept. This functionality could not be verified for the head unit used during this
thesis for several reasons as already mentioned in the previous text. The main reason
was that the ECU was not available for usage outside the department at the MBtech
company, and the impossibility to use own laptop (i.e. laptop with Linux platform)
inside the department. Nonetheless, the proposed concept may be used as a basis for
further development. Nevertheless, translation of automated test scripts to C works for
71/75
CHAPTER 5. CONCLUSION
many cases.
To summarize, the head unit can be controlled from CANoe and PROVEtech:TA
by using the simulation in the same manner as there were control buttons physically
available. Furthermore, the conversion process from CANoe to PROVEtech:TA works
for all test cases required by MBtech.
The usage of open-source software tools has not shown to speed up the process of
creating particular rest-bus simulations. Due to this reason, the open-source tools were
not used even though the overview is given in the document. The open-source tools
may serve mostly for additional analyses of the configuration files.
72/75
Appendix A
73/75
Bibliography
74/75
BIBLIOGRAPHY
[16] CAPL Functions, 1st ed., Vector Informatik, Stuttgart, Germany, 2012.
[17] CANoe – Manual, 7th ed., Vector Informatik, Stuttgart, Germany, 2010.
[18] O. Kulatý, “Message authentication for can bus and autosar software architecture,”
Master’s Thesis, Czech Technical University in Prague, Feb. 2015.
75/75