Embed Size (px)
Citation preview
Generation of AUTOSAR Diagnostic
Communication Manager
Master Thesis
for
the fulfillment of the academic degree
M.S. in Automotive Software Engineering
Faculty of Computer Science
Chair of Computer Engineering
Submitted by:
Divya Ravi (Matr.Nr 362632)
Supervising tutors:
Prof.Dr.Wolfram Hardt
Dr.Ariane Heller
Dipl.Ing.Etienne Dusserre (Bosch Engineering GmbH)
Acknowledgement
I would like to thank everyone who guided, supported and helped me in making
my Master thesis successful. The co-operation and supportiveness that I received from
the whole team at the power train department at Bosch Engineering GmbH, Abstatt
is appreciable.
I would like to specially thank Mr.Etienne Dusserre, my supervisor at Bosch
Engineering GmbH who gave me an opportunity to work on an interesting topic. I
have taken efforts in the research however it wouldn’t have been possible without
his support. He provided me with the technical and professional guidance and also
increased my motivation to work confidently on the topic. He allowed me to work
independently and come up with new solutions and he also organized discussions with
other teams at Bosch so that I can present my new ideas and get their feedback.
I would also like to express my special gratitude and thanks to my professor at
the university, Dr.Prof. Hardt for his guidance and also providing me an opportunity
to accomplish my research work under his professorship.
i
CONFIDENTIALITY NOTICE
The following paper contains copyright information from Bosch Engineering GmbH.
The access to the contents of this work is possible only for Bosch Engineering GmbH,
the author, academic and work supervisors and reviewers of this work. The reproduc-
tion of this work or copying of the content is prohibited.
ii
Abstract
AUTOSAR was created as a standard software infrastructure to be able to fulfill
a very large amount of requirements. These days, more and more OEMs are trying to
introduce AUTOSAR in their products. Since there are a large amount of diagnostic
IDs needed in the Engine control unit and also a huge effort is necessary to configure
the ECU, it is very much important to have a tool to generate some parts of the
Engine Control Unit software, most importantly the diagnostics software. Diagnostic
Communication manager is one such AUTOSAR module which deals with a huge
amount of diagnostic data identifiers. Also at BEG, In the actual Non-AUTOSAR
Bosch Automotive software, there are a number of different features that are needed
and expected in the future AUTOSAR software.
The aim of this thesis is to develop a tool that successfully introduces AUTOSAR in
the BEG projects with all the necessary features and that is best in terms of Usability,
Maintainability, and Improvability. This tool has to generate the complete AUTOSAR
Diagnostic communication manager software with all the necessary features.
The work can be divided into two parts. The first part includes a complete analysis
of the existing tools that are used to generate configuration files and code. Then,
List out all the possibilities of each tool, find their advantages and disadvantages and
compare each of the tools, either individually or as a combination of tools. This is
followed by documenting the choice of best way to generate AUTOSAR DCM with all
the necessary features. In the second part, the implementation is carried out. After
the best tool is chosen, the implementation of the features for that particular tool is
planned accordingly so that it generates the DCM software. Implementation is made
and then it is tested with the existing test bench.
iii
Contents
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objective of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Technical Background 6
2.1 Automotive Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 On-Board Diagnostics . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Off-Board Diagnostics . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Diagnostics Protocol . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Diagnostic Communication Manager . . . . . . . . . . . . . . . . . . 10
3 Overview of existing solution and problems 14
3.1 Need for generation of DCM software . . . . . . . . . . . . . . . . . . 14
3.2 Existing solution for generation of DCM software at BEG . . . . . . 15
3.3 Problems in existing solution . . . . . . . . . . . . . . . . . . . . . . . 17
4 Possible approaches and the best solution 18
iv
4.1 Tkgen only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 EcuWorX only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 tkgen + EcuWorX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Tkgen + Signalconfigtool + EcuWorX . . . . . . . . . . . . . . . . . 22
4.5 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6 Best solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Implementation of parameter definition and configuration 26
5.1 Implementation of parameter definition . . . . . . . . . . . . . . . . . 26
5.2 ECU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.1 Work environment for generation using TKgen . . . . . . . . 37
5.2.2 Steps to generate ECU configuration file . . . . . . . . . . . . 38
6 Code generation using EcuWorX 46
6.1 Perspectives required for configuration and code generation . . . . . . 46
6.2 Config framework to enable code generation . . . . . . . . . . . . . . 48
6.3 Generation of code using oAW scripting . . . . . . . . . . . . . . . . 49
6.3.1 Creation of Xtend scripts . . . . . . . . . . . . . . . . . . . . . 50
6.3.2 Creation of Xpand templates . . . . . . . . . . . . . . . . . . 54
6.3.3 Creation of Check scripts . . . . . . . . . . . . . . . . . . . . . 60
6.3.4 Creation of a Workflow . . . . . . . . . . . . . . . . . . . . . . 62
7 Testing 68
7.1 MASIC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2 Generation of test configuration . . . . . . . . . . . . . . . . . . . . . 71
8 Results 72
9 Conclusion 77
10 Appendix 79
10.1 Parameter definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
v
10.1.1 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10.1.2 EEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.2 Signal conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
vi
List of Figures
1.1 DCM in the AUTOSAR architecture[2] . . . . . . . . . . . . . . . . . 2
2.1 Diagnostic tester[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Basic On-Board diagnostics system[11] . . . . . . . . . . . . . . . . . 8
2.3 Off-Board diagnostics[2] . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Overview of the communication between the external diagnostic tools
and the onboard AUTOSAR Application[14] . . . . . . . . . . . . . . 11
2.5 Position of the DCM module in AUTOSAR architecture[14] . . . . . 13
3.1 TKgen with requirements as input and generates output . . . . . . . 16
4.1 Solution 1: Tkgen only . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Solution 2: EcuWorx only . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Solution 3: Tkgen and EcuWorx . . . . . . . . . . . . . . . . . . . . . 21
4.4 Solution 4: Tkgen, Signalconfigtool and EcuWorx . . . . . . . . . . . 22
5.1 ECU parameter definition[15] . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Parameters organized hierarchically in containers . . . . . . . . . . . 29
5.3 Structure of a DID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Outline of ECU configuration editor . . . . . . . . . . . . . . . . . . . 34
5.5 ECU configuration editor for configuration . . . . . . . . . . . . . . . 35
5.6 ECU configuration description . . . . . . . . . . . . . . . . . . . . . . 36
5.7 Work Environment of Tkgen . . . . . . . . . . . . . . . . . . . . . . . 38
5.8 Excel containing input data(requirements) . . . . . . . . . . . . . . . 39
vii
5.9 Configuration of a parameter done using ECU configuration editor . . 45
6.1 Various perspectives available in EcuWorX . . . . . . . . . . . . . . . 47
6.2 ECU conf perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Code generation perspective . . . . . . . . . . . . . . . . . . . . . . . 49
6.4 Configuration Framework . . . . . . . . . . . . . . . . . . . . . . . . 50
6.5 Flowchart explaining the internal to physical signal conversion . . . . 53
6.6 Xtend editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.7 Example of 2 DIDs with parameters under them . . . . . . . . . . . . 58
6.8 Xpand editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.9 Workflow to generate the required files . . . . . . . . . . . . . . . . . 64
6.10 Predecessor and followup actions in a bamf file . . . . . . . . . . . . . 65
6.11 Input and output actions for a proper build . . . . . . . . . . . . . . 66
6.12 Build control view of code generation . . . . . . . . . . . . . . . . . . 67
7.1 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 MASIC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.1 Result of parameter definition . . . . . . . . . . . . . . . . . . . . . . 73
8.2 Test result - Read and write data by identifier . . . . . . . . . . . . . 75
8.3 Test result - Read data by identifier, length mismatch . . . . . . . . 76
viii
Chapter 1
Introduction
1.1 Motivation
More and more ECUs are introduced in cars with the development of the electronic
control systems. These control the airbags, windows, engine and other parts of a car.
Not only the control, but it also improves the automotive safety as well as comfort.
But by doing these, a lot of new problems arise such as ECU software architecture
becomes more complex, diagnostics becomes difficult and so on. Another important
thing is that there is not a single package of diagnostic criteria during the early stages
of development of automotive diagnostics technology.
The OEMs develop the diagnostic protocols of their own according to their needs
and also define the diagnostic pins that are different to the others. The ECU software
has already been implemented by many OEMs in luxury cars but this software is
not standardized. Many systems use their own protocols and the garages need to
have a number of tools just to diagnose one single vehicle. Because of this, multiple
diagnosis equipments are necessary for the diagnosis of cars since the cars have different
diagnostic protocols.
In order to come up with a solution to solve the above problems, automotive
manufacturers and suppliers created a global and common alliance for automotive
software development which is AUTOSAR (Automotive Open Systems Architecture).
1
This consortium was founded in order to manage the complexity of growing electronics
and also to improve the efficiency in cost without compromising regarding the quality
and re usability[3]. AUTOSAR defines a standard set of methods software development
for automotive electronics and also standardization of the ECU software architecture.
With this method, the competition between the Tier1 companies are simplified and it
also helps in software sharing as well as cost reduction. This standard prepares itself
for the diversity and complexity of the automotive software.
Figure 1.1: DCM in the AUTOSAR architecture[2]
The AUTOSAR standard defines the diagnostic system architecture which is based
on ISO 15765 for automotive diagnostics on the CAN bus. The standard ISO 15765 is
a standard for communication in the area diagnostic systems and is based on CAN.
Most of the OEMs currently adopt the ISO 15765 standard and this standard has
become a common criteria for diagnostics in the automotive industry. Standardization
of the ECU software which was initiated by AUTOSAR has become a major trend
2
in the automotive industry and is being used by most of the OEMs. Hence the
Diagnostic Communication Manager module(DCM) which is one of the core and
important components of the AUTOSAR basic software also has to be standardized.
From the figure 1.1, Diagnostic communication manager module is placed in the
communication services layer of the AUTOSAR software architecture.
Since the customers expect the costs to be low and for diagnostics software, the
manual effort for coding is huge since there are a huge number of IDs handled by the
diagnostics module. In order to overcome this, BEG developed a tool that generates
the diagnostic communication software but it is only for non-AUTOSAR applications.
Now since AUTOSAR is very much in trend, more and more customers want to
move to AUTOSAR in order to standardize the diagnostics software and hence the
development has to be made according to AUTOSAR standards. Also AUTOSAR is
very complex. So it is necessary that a solution has to be developed which eases the
effort of coding as well as reduce the cost for the customer.
1.2 Objective of work
� Analysis of the current non-AUTOSAR DCM generation.
� Complete analysis of the existing tools that can be used for the generation of
complete AUTOSAR DCM software
� Generate a sample code using the tools and compare the effort required, advan-
tages, disadvantages, features covered and so on.
� Document the choice of best way to generate AUTOSAR DCM with all the
necessary features.
� Implement all the necessary features to generate the DCM software using the
chosen tool by using the scripts that are supported by the tool.
3
� Test the generated software with a test bench and check if the generated code
is functioning as expected.
1.3 Thesis structure
This thesis describes the generation of the complete DCM software according to
AUTOSAR standards. It describes the various tool used at BEG and what each tool
is capable of doing based on diagnostics. The thesis is divided into the following
chapters,
Chapter 1 gives a basic introduction which includes the motivation and the
objective of work.
Chapter 2 introduces us to the basic diagnostics and the diagnostic communication
manager module in AUTOSAR in order to understand the thesis work better.
Chapter 3 describes why is it really necessary to generate the DCM software and
it also describes how the generation of DCM software is done at BEG and also the
problems associated with it.
Chapter 4 describes the possible solutions that can be derived from the tools that
are analyzed. A single tool can perform all the necessary actions or a combination of
tools have to be considered to arrive at a required solution. This evaluation is done in
this chapter and finally the best tool is chosen which can generate the complete DCM
software according to AUTOSAR standards.
Chapter 5 describes the implementation of parameter definition file according to
AUTOSAR standards and also the generation of the ECU configuration file.
Chapter 6 describes the main implementation using a tool that was finalized in
the chapter 4. The complete implementation of the scripts that are necessary to
generate the required software is described in this chapter. It also deals with the
various languages necessary to generate the code, documentation and so on.
Chapter 7 is an important step which is testing. Testing was made during the
course of the work and this chapter provides information about the test setup, tools
4
and the method. It also gives information regarding the creation of test scripts required
for testing.
Chapter 8 which is the most important part of the master thesis describes the
obtained results and also evaluation of these results.
Chapter 9, finally is the conclusion of my thesis work. It also contains information
about the goal achieved as well as the future work.
5
Chapter 2
Technical Background
2.1 Automotive Diagnostics
Automotive diagnostics is the entire field of investigation and testing in order to
determine the presence or absence of various problems in an automobile. If there are
any problems, then the causes to these problems and also the possible solutions have
to be determined. Figure 2.1 shows a diagnostic tester device.
Figure 2.1: Diagnostic tester[2]
An automobile, as we know is more than an engine and a body. It is a complex
6
machine with dozens of ECUs and millions of lines of software. Designing such a
complex system is great job but all the great innovations shall have some failures
because of hardware, sensors or software. Detecting a failure in this complex machine
would be a tedious task. Diagnostics helps us in identifying and troubleshooting
the failures relatively easier.Earlier the diagnostic capabilities were not considered
seriously but now, the basic diagnostic functions usually exist as early as in the
B-Sample and the Handling of diagnostics has improved significantly[6]. When any
one of the ECUs in the car detects a fault, two things happen. Firstly, a warning light
is set on the dashboard , in order to inform the person driving the car, that a problem
exists. Secondly, the code is recorded in the ECU’s EEPROM(Electrically Erasable
Programmable Read-Only Memory) and it can be later retrieved by the technician
for further diagnosis and repair.
Normally, the main communication, information is exchanged between the on-
board ECU and an off-board diagnostic tester. Currently, OEM and auto suppliers
are adopting the method combining online and offline diagnosis[9]
2.1.1 On-Board Diagnostics
On-Board Diagnostics is a computer based system which was basically designed in
order to reduce the emissions. This was done by monitoring various parts and the
performance of major components of the engine. Figure 2.2 shows a basic On-Board
diagnostics system. An On-Board diagnostics system basically consists of an ECU,
various sensors used as an input to control the actuators in order to get the desired
performance.There is also an indication light which warns the driver if there is any
problem in the vehicle.Various parameters can be accessed with the help of Diagnostic
Link Connector (DLC) using a scan tool.
On-Board Diagnostics systems gives the owner of the vehicle or the technician who
repairs the vehicle, access to the state of health information of various subsystems
of the vehicle. In the earlier days, the On-Board Diagnostics would only simply
illuminate a malfunction indicator light if any problem was detected in the vehicle
7
Figure 2.2: Basic On-Board diagnostics system[11]
but it doesn’t provide any information regarding the type or nature of the problem.
Whereas the modern On-Board Diagnostics along with illumination an indicator light,
it also provides information about the nature of the problem detected. Modern On-
Board Diagnostics implementations use a standardized series of Diagnostic Trouble
Codes (DTC) which allows the tester to identify the kind of problem that is detected
which helps in finding a remedy to the malfunctions occurring within the vehicle.
2.1.2 Off-Board Diagnostics
Whenever a fault occurs in the vehicle, this fault is stored by the control units so that
they can be investigated at a later point at the garage. The faults are stored in the
8
form of DTCs. To access these trouble codes a tester is needed and this is an example
for off-board diagnosis. The off-board diagnosis analyses the trouble codes stored in
the fault memory. Figure 2.3 shows Off board diagnosis. With the transport protocol
established, there is a need to define a diagnostic protocol in order to define which
messages correspond to particular functions.
Figure 2.3: Off-Board diagnostics[2]
Diagnostic Protocols[13]:
� KWP2000 (ISO 14230)
� UDS (ISO 14229)
9
Diagnostics, as the word suggests, is to identify the cause of a problem or a situation.
Whenever the ECU finds a problem, it stores that problem as a Diagnostics Trouble
Code in the Electrically Erasable Programmable Read-Only Memory (EEPROM) for
later retrieval. Diagnostic Tools are used to read data (DTCs) from the EEPROM to
analyze the cause of failure.
2.1.3 Diagnostics Protocol
Protocol refers to a set of rules for communication. In diagnostics, the communication
happens between two ECUs or between the tester tool and the ECU which follow
the same rules and should be able to exchange the information. The protocols that
are particularly used for diagnostics purposes are known as Diagnostics protocols.
The automotive industry has come up with a few diagnostic protocols that are used
for diagnostic purposes and they are Unified Diagnostics Services (UDS), Keyword
Protocol (KWP) and so on.
2.2 Diagnostic Communication Manager
The DCM module ensures diagnostic data flow and manages the diagnostic states,
especially diagnostic sessions and security states[14]. The DCM module also checks if
the requested diagnostic service is supported and in this case, it checks if the service
can be executed in current session according to diagnostic states. The DCM handles
the communication with external diagnosis tools[12]. The Diagnostic Communication
Manager module also provides a few mechanisms to support the On-board diagnostic
services $01 - $0A. With the help of these services, AUTOSAR on-board diagnostic
functionality becomes capable of meeting the complete light duty On-Board Diagnostics
regulations.
The Diagnostic Communication Manager module provides a common API for
Diagnostic service. The functionality of the DCM module is used by external diagnostic
tool during development, manufacturing or services[10] and figure 2.4 shows the
10
communication external tools and onboard application. This module is an important
part of the AUTOSAR basic software.
Figure 2.4: Overview of the communication between the external diagnostic tools andthe onboard AUTOSAR Application[14]
DCM has some functions as below,
- DCM module ensures diagnostic data flow and manages the diagnostic states,
especially diagnostic session and security state.
- DCM check if the service requested is supported The various terminologies
that are used in diagnostics are
Protocol - Protocol is a set of rules which will define the process of how reception
and transmission should work, restriction on the timings, set of the services supported
etc.
Session - A diagnostic session enables a specific set of diagnostic services and/or
functionality in the ECU[14]. It furthermore enables a protocol depending data set of
timing parameters applicable for the started session.
Security - The purpose of this is to provide a means to access data and/or diagnostic
services, which have restricted access for security, emissions, or safety reasons.
11
Service table - Service table is a set of services (functions) supported / configured
for a protocol. Only one service table will be assigned for any protocol. Ex: service
table for UDS protocol will contain the services defined according to ISO14229.
Service - Diagnostic Service is an instruction, which is requested by a tester and
carried out by the ECU.
Service identifier - A unique service Identifier will be assigned to a service defined
by the protocol. Service Id is fixed by the protocol Ex: 0x3E is the Service ID for
Tester Present service[7].
Positive response - If the request from the tester is performed successfully by the
diagnostics application in server positive response will be sent.
Negative response - If the request from the tester is not fulfilled by the service,
negative response will be returned with a suitable negative response code.
Negative response code - If the ECU is not able to carry out a tester request, it
sends a response telegram with a NRC. The NRC gives the tester information about
the reason for rejection
Let us look at an example how a tester communication works. Let us send a
request message for Tester present. The request ID is 0x3E.
When the tester requests with the message 3E 00 and if the received message is 7E 00
then it is a positive response. Positive responses always have the request ID + 40.
If the received message is 7F 3E 12, then it is a negative response. Negative responses
always start with a 7F, followed by the request SID and the negative response code.
In AUTOSAR Architecture, the Diagnostic Communication Manager (DCM) is
located in the Communication Service Layer.
Figure 2.5 shows the position of DCM in AUTOSAR architecture. The Diagnostic
Communication Manager module is network-independent. All the network-specific
functionalities (such as the specification of networks like CAN, FlexRay, MOST or
LIN) are handled outside the DCM module. PDU Router module provides a interface
which is network-independent to the DCM. The DCM module receives a diagnostic
message from PduR module, the DCM process and check the message internally. As
12
Figure 2.5: Position of the DCM module in AUTOSAR architecture[14]
part of processing the diagnostic service, the DCM will interact with other BSW
module or SWC to obtain request data or execute the request command. Typically,
the DCM will assemble gathered information and send a message back through the
PduR module.
13
Chapter 3
Overview of existing solution and
problems
The main aim of this thesis is to generate the complete AUTOSAR Diagnostic
Communication Manager software. In this chapter, we will see why is it necessary
to generate the Diagnostic Communication Manager software and also have a small
overview on an existing solution which enables to generate the DCM software and the
problems associated with it.
3.1 Need for generation of DCM software
Why is it really necessary to generate the Diagnostic Communication Manager soft-
ware? The reason is, there are a large number of messages that are handled by
the Engine control unit, especially in diagnostics. The module that handles these
diagnostic messages is the Diagnostic Communication Manager which provides APIs
for the diagnostics services. Diagnostic Communication Manager module consists
of huge number of lines of codes since there are a lot of CAN messages handled by
diagnostics and these are mostly coded manually. It also takes huge effort to configure
the ECU with respect to these diagnostic messages. Every message with its respective
data identifier has to be configured individually which are then used in the code. This
14
process is very much time consuming and most of the parts of the code are repeated
with some basic changes according to configuration of various DIDs (Data identifiers).
Hence it would be really helpful if there is some methodology for example, a tool
which can generate the Diagnostic Communication Manager software. This not only
helps in reducing the time to code but also the cost. Also, this auto generated code
can be advantageous in achieving the ubiquitous free software[5].
3.2 Existing solution for generation of DCM soft-
ware at BEG
BEG Bosch Engineering GmbH is a subsidiary of Robert Bosch GmbH which provides
services in the areas of Powertrain, Safety and Comfort, E/E systems, Testing services,
Components and small services, consulting, project and quality management. The
powertrain department at BEG develops efficient and powerful solutions for any
application in the powertrain sector. There are expertise available in the powertrain
systems for many conventional internal combustion engines such as diesel, gasoline
and also hybrid and electric powertrain concepts.
One of the areas that is handled by the powertrain department at BEG is Diag-
nostics. Since there is huge effort needed in coding the Diagnostic Communication
Manager software manually, a team at BEG developed a solution where the entire
DCM software is generated using a tool called TKgen. This tool initially was being
developed with an idea of using it for a particular project.
TKgen
TKgen is a tool developed at BEG. The main idea behind developing this tool is,
with this tool it is possible to describe, generate, document code, all in one go.
There are quite a lot of piece of codes, which are created by Copy and Paste. In the
Diagnostic Software or in Software Sharing interfaces, structures of data have to be
created and maintained during the whole software lifecycle. Of course this also needs
15
to be documented and has to work together and also declaration, implementation and
so on has to fit together.
So, TKgen is used in order to simplify such kind of work. Most of the BEG
customers often need changes and in the best case, the requirements are available
in the form of an Excel overview. This tool helps to generate configurations and
documentations with input defined in an Excel file and it is structured through
templates. Most of the work that is complex and time consuming can be done much
more efficiently with the help of TKgen.
It does not matter how many files are to be generated or how many times a same
kind of code has to be duplicated. It takes only a few minutes and the new files are
created and can be used. And if there is a change that needs to be done anywhere in
the generated files, only a change in the excel sheet is necessary and the outputs are
changed accordingly.
Figure 3.1: TKgen with requirements as input and generates output
Figure 3.1 shows the input required by Tkgen and the outputs generated. TKgen
generates files for service code, configuration, documentation and tests. This is
16
described through Excel sheets, A2L information and templates. Once it is set up,
there is an easy way to provide fast and complete output from changing one element
and generating a new fully documented and tested environment.
3.3 Problems in existing solution
So far, the tool looks impressive but it has several disadvantages. The main problem
here is, this tool generates the necessary software but it was implemented for non-
AUTOSAR projects and is currently used by a few projects of a specific customer to
generate DCM software for non-AUTOSAR requirements. Now, since more and more
customers want to move to AUTOSAR and since the AUTOSAR configuration is
very complicated and works with a lot of references which needs to fit together, it
will be much more complicated to create such configuration and this tool does not
support the generation of DCM according to AUTOSAR standards.
If any of the inputs have to be changed, then in this tool, the changes are made
through the requirement excel and the output is generated accordingly. But if the
parameters are to be configured according to AUTOSAR standards, this tool does not
have any option for configuration. There is a standard that needs to be followed to
configure with respect to the parameter definition file provided by AUTOSAR which
has to be referenced properly with the configuration and TKgen does not provide this
functionality.
Since the existing tool does not support the configuration of the DCM module
according to AUTOSAR standards and it can generate the DCM software only for non-
AUTOSAR projects and also since there is a strong requirement from the customer to
move to AUTOSAR, it is necessary to come up with an efficient and a quick solution to
migrate the existing requirements and generate a complete AUTOSAR DCM software.
This solution must also be suitable to use in all the existing AUTOSAR projects as
well.
17
Chapter 4
Possible approaches and the best
solution
There are several tools which are capable of generating the Diagnostic Communication
Manager software. It is necessary to think of all possible solutions in order to generate
the complete DCM software with the necessary features. Hence all the possible options
have to be analyzed carefully and the advantages and disadvantages of each solution
has to be considered and a decision has to be made regarding the best tool to generate
the DCM software.
4.1 Tkgen only
For a non-AUTOSAR software, it is possible to generate the complete DCM software
using TKgen only. TKgen is a tool developed to simplify the manual coding. This
tool helps to generate configurations and documentations defined in an Excel file
and is structured through templates. With the help of this tool, it is possible to
generate and also document the code, all in one go. It splits the requirements into the
required outputs. This eases and improves the developers work by generating all the
documentation, c, h, xml and a lot more files. Figure 4.1 shows the necessary inputs
and the generated outputs.
18
Figure 4.1: Solution 1: Tkgen only
With the help of an input requirement excel and the templates, Tkgen can be used
to generate the software. But it has its own pros and cons which are listed below:
Pros:
- Minimal resources
- Less development time
- No change in the build time
- Generation of test configuration easy.
Cons:
- Non-AUTOSAR
- No scope for configuration
- Not user friendly
- Not so good validation
4.2 EcuWorX only
Currrently, EcuWorX is used for the configuration of basic software modules but the
tool can also be enhanced so that it can also generate the necessary software.
ECU.WorX is an Integrated Development Environment (IDE) to manage and
develop ECU software which has the purpose to combine various development tools in
one product. With this tool, it is possible to Perform basic software configuration, Edit
AUTOSAR based basic software configuration, Processing of code generation scripts,
Import of network data (Ex: DBC files). This tool is currently used to configure
the AUTOSAR basic software. It has no built-in knowledge about the different
19
AUTOSAR modules and components. The user (or the development environment)
must provide inputs that tell the tool what can be done based on the set of rules
defined in the parameter definition file.
Not only the configuration of basic software modules, EcuWorX also supports
generation of code. The code can be generated not just for configuration files but also
for the complete software but the proper and suitable code generation mechanism has
to be implemented. Figure 4.2 shows the necessary inputs and the generated outputs.
Figure 4.2: Solution 2: EcuWorx only
Both configuration as well as code generation is a tedious task to be performed by
the tool. When it comes to configuration, if there are a lot of IDs to be configured,
configuring every ID by hand is a time consuming process. Since the requirements are
already available in the form of an excel for the existing projects, it is necessary to
have an importer in the tool which imports the excel requirements as configuration.
This method has the following pros and cons:
Pros
- Very easy to use since there is a GUI and has descriptions about the parameters
- very good validation
- Tool used by most of the projects so no training required
Cons
- need more resources
- lot of time needed to configure every diagnostic identifier by hand
- increases the build time
- requires more development time
- Need for an excel importer to import the existing excel requirements
20
4.3 tkgen + EcuWorX
Tkgen and EcuWorx can be used in combination for configuration and code generation.
Tkgen can be used for migration of the existing excel requirements into configuration
and EcuWorX can be used for code generation. Figure 4.3 shows the necessary inputs
and the generated outputs.
Figure 4.3: Solution 3: Tkgen and EcuWorx
Since there is a requirement excel already available in the existing projects, it is
necessary to migrate them to generate the configuration. This is done by Tkgen which
takes the requirements excel as input and with the help of templates, it generates
the configuration file (ecucvalues.arxml) which can be directly loaded into EcuWorX.
With this migration, the tool now has all the configurations directly loaded and hence
there is no need to configure everything by hand.
Since all the configurations are available, the code generation can be implemented
in EcuWorX tool. This generates the necessary code, documentations and so on.
Pros
- Very easy to use since there is a GUI and has descriptions about the parameters
- very good validation
- Tool used by most of the projects so no training required.
- No exporter needed to generate configuration from existing requirement excel.
Cons
- need more resources
- increases the build time
- requires more development time
21
4.4 Tkgen + Signalconfigtool + EcuWorX
Here a combination of 3 tools is used to configure and generate the DCM software.
Tkgen can be used for migration of the existing excel requirements. Signalconfigtool to
generate the configuration and documentation. EcuWorx for code generation. Figure
4.4 shows the necessary inputs and the generated outputs.
SignalConfigtool helps in generating the configuration (*.arxml) file from an excel
file having a list of all the DIDs with the respective fields to be entered into the
configuration file. It is designed based on the ECU parameter definition of AUTOSAR.
The main reason for generating this configuration file is that, in the configuration tool,
each and every parameter has to be configured manually. Although there is a GUI,
it is a time consuming process if there are a lot of parameters to configure. Hence
a configuration file is generated using the SignalConfigtool with all the input in the
form of an excel and this configuration file can be directly fed into the configuration
tool.
Figure 4.4: Solution 4: Tkgen, Signalconfigtool and EcuWorx
Signalconfigtool can be used because it shares some of the work of EcuWorX by
generating the configuration files and documentation. But the problem with this
tool is, it generates the configuration file for messages having the type ”signal” only.
Whereas for types other than signals, manual configuration has to be done in EcuWorx.
To avoid manual configuration, Tkgen can be used so that it generates the required
configuration file and then EcuWorX can be used to generate the code.
22
Pros
- Easy to use
- Very good validation
Cons
- need more resources
- increases build time
- too many tools
4.5 Comparison
By considering the solutions listed above, we have to evolve at a final decision which
tool is the best.
With solution 1 - Tkgen only, can be used only for non-AUTOSAR projects.
Implementation of AUTOSAR configuration concept is very complex. Also, the tool
does not have good validation features and when discussed with the other teams, the
teams were not comfortable using the tool since most of the things were handled
by the excel and most of the teams felt it was not very easy to use. Many training
sessions have to be held for teams to understand the tool usage. Another problem is
the tool is not very user friendly and self explanatory.
With solution 2 - EcuWorx only, both configuration and code generation has to
be performed by a single tool. But the migration of the existing excel requirements
into the tool is a major issue. There is no importer to import the excel requirements
into the tool and generate the configuration file and hence the complete configuration
has to be made by hand.
With solution 3 - Tkgen and EcuWorX, since EcuWorX doesn’t have an importer
to import the excel(required in solution 2), Tkgen can be used for this purpose. Instead
of creating an importer, it is better to use the already existing Tkgen only for migration
of the excel into a configuration file that can be used by EcuWorx for further code
generation.
23
With solution 4 - Tkgen, signalconfigtool and ecuWorX - Though signalconfigtool
shares some of the work from EcuWorX and it generates few files, it does not cover
the configuration of all the types in a message. Hence another tool Tkgen is required
to generate the configuration for messages having types other than signal. Hence
there are too many tools that have to be used which is not recommendable.
4.6 Best solution
Comparing all the four possible solutions, the better solution would be solution 3 -
Tkgen with EcuWorX as in fig 4.3. The reason for choosing this solution is that, if
we consider the already existing solution - TKgen, it generates DCM software for
non-AUTOSAR projects. If we have to introduce AUTOSAR into TKgen, then there
are a lot of complexities that the tool cannot handle. The configuration of the module
gets more complicated due to the references and the tool is not user friendly and it
also does not have good validation features.
Next option would be EcuWorX which is mainly used for the configuration of basic
software modules according to AUTOSAR standards. This tool also supports code
generation if suitable templates are implemented. But with diagnostics, huge number
of messages as per the requirements have to be configured and since the requirements
are already available in the form of an excel, it would be a good option to import the
excel into EcuWorX and convert it into configuration file. But the tool does not have
an excel importer.
EcuWorX can be used for code generation with the help of configuration file but
the problem is with importing the existing excel requirements and converting it to
configuration file. There is no excel importer but TKgen can be used just for the
creation of configuration file from the requirement excel and this configuration file
can be loaded into EcuWorX which reduces the effort of manual configuration.
So the best solution is to use TKgen for creation of configuration file from the
existing excel requirements and EcuWorX can be used to build and generate the
24
complete AUTOSAR DCM software. Also, since most of the teams are already familiar
with the tool, it would be easy for everyone to use it. Here the initial development
effort is more since all the functionalities have to be implemented in EcuWorX in
order to generate the required software. But after it is developed, it is very convenient
to use either to configure or to generate code. The tool also has very good validation
features and it has a GUI which makes it very user friendly. Hence the best solution
is to use the combination of the tools - TKgen and EcuWorX for better configuration
and code generation.
25
Chapter 5
Implementation of parameter
definition and configuration
This chapter explains about the implementation of parameter definition file to migrate
the existing non AUTOSAR projects to AUTOSAR. The parameter definition files
have to be defined according to AUTOSAR standards. This chapter also describes the
generation of the ECU configuration file using TKgen which converts the requirement
excel into a configuration file required by EcuWorX for code generation.
5.1 Implementation of parameter definition
The major part in developing the AUTOSAR ECU is basically the configuration
of AUTOSAR Basic Software (BSW). Every parameter which can be configured is
defined in a Parameter definition file. This enables for the configuration of hundreds
of parameters of the AUTOSAR basic software modules.
The parameters can be configured using a number of editors, for example, an
ECU configurator which typically has a GUI that helps in configuration of the basic
software module parameters. The editor first reads the parameter definition file and
provides a user interface which happens dynamically. Using this interface, the user
can configure the parameters accordingly. These configured parameters are called
26
ECU Configuration values.
But, configuration editors have to know how exactly the contents of the ECU
configuration values have to be structured (for example, which particular parameters
are available in which particular container) and also the kind of restrictions that
are applicable (for example, the configuration parameter must be an integer value
had must be in the range 0 to 255). All these information are specified in the ECU
configuration parameter definition. The parameter definition is usually written in an
XML format. With respect to diagnostics, there are hundreds of identifiers that need
to be configured. In order to configure these identifiers, there is a need to create a
parameter definition based on the project requirements and it has to be according
to AUTOSAR standards so that the parameters can be configured using any of the
AUTOSAR configuration editors.
Figure 5.1: ECU parameter definition[15]
27
Figure 5.1 shows that the ECU parameter definition file that conforms to the schema
of ECU configuration Parameter definition template is fed to the AUTOSAR ECU
Configuration editor. This editor then creates an ECU configuration description(.xml)
which also conforms to the schema of the ECU configuration description template.
A model based approach has to be followed to create a parameter definition. The
input and the output format is standardized by AUTOSAR and hence the parameters
can be configured using any configuration editor that is AUTOSAR compatible.
Creation of parameter definition file:
Here it is necessary to create a parameter definition file which has information about
all the parameters that have to be configured in order to generate the DCM software.
But the main important thing is that, this parameter definitin file has to be according
to the AUTOSAR standards.The parameter definition file always starts with the XML
version as well as the AUTOSAR version and it also contains the location of the
respective AUTOSAR XML schema. The AUTOSAR XML schema was developed
by the AUTOSAR consortium. Most of the software developers use model based
development tools as well as code generators in order to generate embedded software
for automotive industry. The XML schema developed by the AUTOSAR consortium
ensures the quality of being able to perform all the various aspects of development
workflow of the automotive embedded software.
The above lines represent the xml version as well as the AUTOSAR version and
the location of the respective schema. This is followed by the AUTOSAR package
description.
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>RB</SHORT-NAME>
28
AR Package (AUTOSAR Package) allows to create top level packages in order
to structure the AUTOSAR elements contained in it. It allows to put all the model
elements together, for example, in the form of an OEM or project specific package
that contains other AUTOSAR packages or elements.
Parameters are organized hierarchically in Containers. A container mainly consists
of parameters and subcontainers under it just as in figure 5.2.
Figure 5.2: Parameters organized hierarchically in containers
The package information is followed by module definition and the containers under
it. Each container can have sub-containers and parameters and these sub-containers
in turn have sub-containers under them. The parameter definition file is created as
a structure with respect to the project specifications and according to AUTOSAR
standards.
29
One of my main tasks in this thesis is also to create a parameter definition file
using which the required parameters for code generation can be configured. A suitable
design needs to be created so that the corresponding type under all the parameters
under each message can be configured correctly. The design of the structure looks as
in figure 5.3. Every message has parameters under it and each parameter has its own
information and also the corresponding type associated with it. The code in Appendix
10.1.1 shows a part of the parameter definition file where the information regarding
the parameter is defined and the containers are written as per AUTOSAR standards.
Figure 5.3: Structure of a DID
The following characteristics are defined in the parameter definition file.
<SHORT-NAME>did </SHORT-NAME>
30
SHORT-NAME is the name given to the subcontainer in a short manner and whenever
the elements under this container have to be accessed, it has to be done using this
shortname (can be used for reference purposes.)
<LONG-NAME>
<L-4 L=”EN”>Data identifier </L-4>
</LONG-NAME>
LONG-NAME is the name of the subcontainer in a more user understandable per-
spective and it can also be described in different languages.
<DESC>
<L-2 L=”EN”>The data Identifier represented in Hex</L-2>
</DESC>
DESC tells the detailed description about the purpose of this container. It helps the
user to understand about the object before configuration. It is just a short description
about what exactly has to be configured since it will be hard for the developer or the
tester to configure an element by just looking at the name of the container.
<LOWER-MULTIPLICITY>0</LOWER-MULTIPLICITY>
LOWER-MULTIPLICITY defines the minimum occurrence of configuration element.
The default value of this field is 1. If the lower multiplicity and upper multiplicity are
set to 1, then the element has to be configured mandatorily and it can occur only once.
In order to make the configuration of an element optional, the lower multiplicity can
be set to 0. In the case where the lower multiplicity is set to 1, the configuration of
the element depends on the parameter. It can be either set or cleared based on the
existence of the element in the particular parameter. Whereas if the lower multiplicity
is set to 1, then the element has to be configured mandatorily.
<UPPER-MULTIPLICITY-INFINITE>true</UPPER-MULTIPLICITY-INFINITE>
UPPER-MULTIPLICITY defines the maximum occurrences of the configuration ele-
ment. It shows how many instances of the values are allowed. The default value of
this field is 1. If the upper multiplicity is set to 1 and lower multiplicity is also set to
1, then the element has to be configured mandatorily and this can occur only once. In
addition to UPPER-MULTIPLICITY , in order to express countable infinite number
31
of the occurrences, UPPER-MULTIPLICITY-INFINITE is used and is set to ”true”.
<MULTIPLE-CONFIGURATION-CONTAINER>false</MULTIPLE-CONFIGURATION-
CONTAINER>
MULTIPLE-CONFIGURATION-CONTAINER is defined for every container. It is
set to true if the container supports multiple configuration sets.
<POST-BUILD-CHANGEABLE>false</POST-BUILD-CHANGEABLE>
POST-BUILD-CHANGEABLE specifies if it is possible to change the number of
containers during the post build time. It is set to true if the container is a descendant
of another container whose multipleconfigurationcontainer is set to true.
Under the subcontainers, the parameters that need to be configured can be specified.
Every type under the parameter container can be defined accordingly. For example,
if the number of bytes of an EEP has to be configured, then the parameter definition
file will have a format through which the configuration can be made. See Appendix
10.1.2 for reference.
<ECUC-INTEGER-PARAM-DEF>
<SHORT-NAME>numbytes</SHORT-NAME>
<LONG-NAME>
<L-4 L=”EN”>Number of Bytes of an EEP</L-4>
</LONG-NAME>
<DESC>
<L-2 L=”EN”></L-2>
</DESC>
<LOWER-MULTIPLICITY>1</LOWER-MULTIPLICITY>
<UPPER-MULTIPLICITY>1</UPPER-MULTIPLICITY>
</ECUC-INTEGER-PARAM-DEF>
In the above example, in order to configure the number of bytes of an EEP, the
parameter definition has to contain the shortname which can be accessed whenever
a reference for this parameter is necessary. It should also contain a longname and
a small description about the parameter for understandability purpose and since it
32
can be written in any language, the language of description has to be specified. For
example,”EN” for English or ”DE” for German languages. Another important field
would be the multiplicity. The upper multiplicity and lower multiplicity has to be
defined to say if the configuration of the element is mandatory or optional.
So keeping the design in mind, the XML representation of the parameter definition
file should contain a main container named ”DID” which has the rule ”MULTIPLE-
CONFIGURATION-CONTAINER” set to true which means that the container can
be configured multiple times since there are a number of diagnostic data identifiers
that needs to be configured. This container can have parameters under it which means
that it should have a subcontainer named ”param” which can also be configured
multiple times since a DID can have multiple parameters and it also has to contain
the information about the parameter such as data length, datatype, unit, resolution
and so on. This subcontainer ”param” inturn has many subcontainers under it that
defines the type of the parameter, for example, signal, eep and so on.
All these can be represented in a modular structure which eases the developer to
understand and configure accordingly. Figure 5.4 shows the modular structure after
the parameter definition file is read by the ECU configuration editor for configuration.
The parameter definition file which is in an XML format is converted into a structured
view as show in the outline window. The respective fields can be opened and configured
as per the ECU parameter definition.
The individual containers or subcontainers can be opened which gives a list of
parameters to be configured. As an example, from the figure 5.4 , the subcontainer
AVS can be expanded which results in figure 5.5 which shows the configuration
of individual container (AVS). The container can be opened and the parameters
particular to this container can be configured.
With this parameter definition file, it is possible to configure any parameter that
is required by the project and the developer or tester is not restricted to use only
the parameter definition file provided by AUTOSAR. The important things that
have to be considered here is that the parameter definition file that is created to
33
hold additional data required by the project for various development processes has
to be AUTOSAR compliant. The module can be configured using any AUTOSAR
configuration editor since the ECU parameter definition is compliant to AUTOSAR.
Figure 5.4: Outline of ECU configuration editor
34
Figure 5.5: ECU configuration editor for configuration
5.2 ECU Configuration
During the development of an ECU, the software components are designed and
implemented. The basic software and the RTE have to be configured. The basic
software is really a huge area and the whole of the basic software is not needed by
every project. Each and every project has its own requirements and the developer
chooses the necessary amount of basic software that is needed for the project through
configuration. The result of this configuration is an ECU configuration description
which is stored as an AUTOSAR XML file.
The actual software component does not know about the actual target below it.
For example, a simple information like datatype is implementation independent and
35
has to be configured. Also, basic software that is specifically needed for the project
is to be configured. If there is only CAN connectivity required, then there is no use
in having LIN and Flexray on the ECU. So it is necessary to get only the modules
that is required for the project. This saves a lot of memory and it makes it a specific
tailored configuration.
Figure 5.6: ECU configuration description
The parameter definition file has to be loaded to the AUTOSAR ECU configuration
editor in order to configure the modules. The configuration information of the entire
ECU is described in ECU Configuration description. This description file is created
based on the ECU parameter definition file.
When the ECU parameter definition file is loaded into the configuration editor, a
GUI as in figure 5.5 appears and all the parameters that are defined are configured
accordingly. If the number of parameters to be configured are a few in number
then this method is completely reasonable but in case of diagnostics, this is not
36
the case. Diagnostics handles a large number of DIDs. Each data identifier has
several parameters under it. Each parameter in turn has several sub parameters and
parameter types.
The above example shown in figure 5.3 is for a single DID and diagnostics handles
a huge number of such identifiers. Configuration of every single DID using the
configuration editor is really a huge time consuming process. Hence there needs to be
a solution to configure the information about all the identifiers in an effective way.
For this purpose, the already existing Bosch tool TKgen can be used. Since the main
intention is to port the existing non-AUTOSAR software to AUTOSAR software, the
requirements are already available in the form of an excel and this excel can be fed to
TKgen to generate the ECU configuration file.
5.2.1 Work environment for generation using TKgen
The tool used here to generate AUTOSAR ECU configuration file is TKgen. There is
no separate tool that needs to be installed and the only tools required for generation
are Microsoft Excel and a text editor like Notepad++.
The ECU configuration description file has a standard format and is compliant to
AUTOSAR standards. When several identifiers are configured, the resulting ECU
configuration description file will have the same format whereas only the data with
respect to several DIDs changes. This standard format can be used as a template in
TKgen and with the data as input, the entire file can be generated.
Work environment of TKgen:
The figure 5.7 shows the work environment and it consists of the following folders:
Common - This folder contains all the templates that are necessary for code generation
and a CONF file. The conf file holds the configuration for the program.
Conditions - This folder contains files that define the conditions that needs to be
satisfied in order to generate files.
In - This folder contains the input files with meta templates to generate respective
outputs.
37
Figure 5.7: Work Environment of Tkgen
5.2.2 Steps to generate ECU configuration file
Step1 - Input
Consider the requirement excel as in figure 5.8 which contains the information about
various parameters about the DIDs.
This excel file along with the is stored in the input folder. Also the file to be
generated having the meta template is also stored in the input folder.
38
Figure 5.8: Excel containing input data(requirements)
Step 2 Templates
TKGen makes a clear distinction between files and templates. This means that there
are two layers in the template system. At the first layer, each type of parameter with
all its respective information is parsed through the templates that is mapped to it.
The summary of these informations are then arranged within the files in the second
layer.
Naming convention:
Each of the templates are stored in the common folder of the work directory. The
templates are saved with an extension .tmpl (example: fs xml.tmpl). For templates
having multiple versions for different types, an index can be mentioned in the file
name (example: fs xml.tmpl 1) . These different versions can be summarized in one
file during generation. If a file is too complex, then the file can be split into various
parts and templates can be written accordingly. The individual outputs can later be
39
linked in the meta template of the input file for a complete generation of the required
file.
My task here is to create the templates in perl using TKgen in order to generate
the configuration file. The template consists of the standard AUTOSAR configuration
file format which is also similar to the configuration file that is generated using any
AUTOSAR compliant ECU configuration editor. The templates are created for every
type of the parameter and then linked in the meta template so that the output file
consists of the complete information combined from all the individual templates. These
individual templates are places in the ’common’ folder of the TKgen folder structure
and the information generic to all the templates are placed in the meta template that
is placed in the ’In’ folder. Also, if there are several different templates, then the
order in which the output file has to be structured can also be mentioned in the input
meta template.
For Example : Consider that ecucvalues arxml.tmpl adresse, ecucvalues arxml.tmpl cal
and so on are the individual templates. They have the same filename but different
version (adresse and cal). These versions will be automatically stored in one file during
generation and the necessary output file can be obtained.
The common folder contains the templates as well as the configuration file which
describes where the templates are used. The templates always have a naming con-
vention with extension.tmpl. If a file ecucvalues.arxml has to be generated, then
the template has to be named as ecucvalues arxml.tmpl. Tkgen will rename each
template after parsing by removing the .tmpl and sets it with the new extension. So
ecucvalues arxml.tmpl will be renamed to ecucvalues.arxml.
Template parsing
The parsing system is based on the perl module Text:Template and the templates
are written in Perl language. The Text:Template module will scan the source of the
template. The start of the program is determined by open braces ”{” and it continues
until it finds a matching closed brace ”}”. When the template is filled, the program
40
is evaluated and each variable is replaced with a resulting value to obtain an output.
To parse every template, Tkgen provides a list of variables that are generated
from the excel and A2L file and prepares them whenever they are necessary. In order
to know which variables are provided by Tkgen, the log file (tkgen.log) can be seen.
A particular variable can be searched from the log file.
Example: For a type Rweep which has subtypes id, variable and so on, the log file
looks as below:
Tmpl.conf
Conf files are configuration files which describes where exactly are the templates used.
This file is placed in the input folder of the work directory.
We have an excel which contains the configuration information and we also have
templates to generate the required code. But the parsing between the excel and
template is missing. The excel is to be parsed line by line, that is each line has to be
parsed with a corresponding template. This information, which template has to be
parsed for which line of the excel has to be described in the tmpl.conf file as in the
example.
Example:
in/RWDBI/adresse/conf ecucvalues arxml.tmpl adresse
41
in/RWDBI/cal/conf ecucvalues arxml.tmpl cal
in/RWDBI/ats/conf ecucvalues arxml.tmpl ats
in/RWDBI/signal/conf ecucvalues arxml.tmpl signal
From the above example, each line in the excel from the sheet named RWDBI with
type ”adresse” is parsed through the template ”ecucvalues arxml.tmpl adresse” , type
”cal” is parsed through the template ”ecucvalues arxml.tmpl cal” and similarly every
type line by line in the excel is parsed through the respective templates mentioned in
the tmpl.conf. If the output to be generated is complex, it can be split into multiple
templates and can be combined later into one file. Here in the example, the templates
have a suffix based on their types while they all result in generation of a single file
ecucvalues arxml.tmpl. Individual files are generated and then they are combined to
get the required output file. Also, multiple types can be mapped to the same template
as in example shown below.
Example:
in/RWDBI/adresse/conf ecucvalues arxml.tmpl
in/RWDBI/cal/conf ecucvalues arxml.tmpl
in/RWDBI/ats/conf ecucvalues arxml.tmpl
The types adresse, cal and ats parse through the same template ecucvalues arxml.tmpl.
NOTE: Every type in the excel must have a corresponding template mapped in the
tmpl.conf in order to generate the required code.
Step 3 Conditions
Tkgen maps all the variables from the excel to the templates. The excel sheet is
separated into default and mandatory columns . Which column has to be mandatory
has to be decided by the conditions that are defined for the project and also the
variables used in the template. It is possible to generate extra variables on the basis
of the Excel sheet.
In the ECU parameter definition, there might be some parameters whose UPPER
MULTIPLICITY and LOWER MULTIPLICITY are set to 1. In this case, it is
42
mandatory to have a value for that parameter. Hence while generating the ECU
configuration description using TKgen, it is necessary to take care that the parameter
is configured mandatorily. In order to configure this parameter, it has to be available
in the excel. To check if this is available, conditions can be written and as a first step,
TKgen checks if these conditions are satisfied and it throws an error if a condition is
not satisfied and stops the execution.
Example:
The conditions tmpl conditions.pm are stored in the conditions folder of the work
directory. Tkgen checks for these conditions before going to the templates. From the
example, the parameter of type ”ats” in the excel sheet must have the mandatory
fields such as ”did” whose length must be 4 and can have numbers from 0 to 9 and
characters from A to F since it is represented as hex, length and type. Similarly for a
parameter of type ”signal”, the mandatory fields are did, length, type , bit position
and so on. Based on the configuration required, the conditions can be set so that even
if some mandatory information is missing in the excel, Tkgen reports an error. The
error can be corrected in Tkgen itself rather than generating the complete file and
then an error pops out in the configuration tool.
Example of a template written in perl to configure the parameters of a DID :
{if($syskon= /.+/)
$out=”
<SW-SYSCOND>$syskon xml</SW-SYSCOND>”;
}else {$out=””;
}
43
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>$param</SHORT-NAME>
$str
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<VALUE>$Length<VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
....
....
<ECUC-TEXTUAL-PARAM-VALUE>
<VALUE>$datatype<VALUE>
</ECUC-TEXTUAL-PARAM-VALUE>
</PARAMETER-VALUES>
</ECUC-CONTAINER-VALUE>
Here the green part is the perl syntax. Everything in the template other than the perl
syntax is printed as it is where as the perl syntax is evaluated and then printed.
From the above example, consider the perl syntax(the first few lines with syskon).
Here in perl syntax related to system conditions, $out will be set to a string if the
system condition syskon is not empty. Otherwise it sets the $out to be empty which
means nothing is printed from the perl syntax.
<ECUC-NUMERICAL-PARAM-VALUE>
<VALUE>$Length<VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
In case of the above syntax which uses a variable called $Length and the value of
$Length according to the requirements mentioned in the input excel being ”2” , during
template parsing, the perl syntax is evaluated and the variable $Length is replaced by
its respective value in the exact same position where it is defined. Hence the example
written above in perl is replaced with the actual values and the code looks as below:
<ECUC-NUMERICAL-PARAM-VALUE>
44
<VALUE>2<VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
When both the parameter definition and the generated ECU configuration descrip-
tion files are loaded into the ECU configuration editor, the respective configurations
are already done and it looks as in figure 5.9
Figure 5.9: Configuration of a parameter done using ECU configuration editor
The main idea of this section, generation of ECU configuration description is
that since there are a large number of IDs handled by diagnostic communication
manager, it is really a huge time consuming process to configure each and every
DID and its respective parameters. The solution to this problem is to generate the
ECU configuration description file with the help of already existing configuration
information available in the form of a requirement excel.
Hence with the help of TKgen it is possible to generate the ECU configuration
description file with the help of an requirement excel and templates.
45
Chapter 6
Code generation using EcuWorX
The main aim of my work is to generate the AUTOSAR Diagnostic Communication
software. After analyzing the features and capabilities of various tools from chapter
4 , it is decided to use EcuWorX for generation of the Diagnostic Communication
Manager software.
6.1 Perspectives required for configuration and code
generation
ECU.WorX is an eclipse based tool available in the Bosch toolbase. This tool is
not only used just for the configuration of the basic software modules, but it can
also be used for processing of the code generation scripts. This tool supports both
configuration as well as code generation as shown in fig 6.1 .
EcuWorX offers two eclipse perspectives:
� ECU conf
� Code generation
ECU conf is for the configuration of basic software modules. The configurations
mentioned in the section ECU configuration are done in the ECU conf perspective.
46
Figure 6.1: Various perspectives available in EcuWorX
Figure 6.2 shows the ECU conf perspective.
Code generation perspective helps in generation of code. It also has a list of all
the parameters that are configured. At the bottom left corner, there is a build control
view which is available only in the code generation perspective. Using this build
control view, it is possible to build the complete modules or even partial build can be
made. In partial build, individual modules can be built separately instead of building
all the modules every time. Figure 6.3 shows the Code generation perspective.
In order to generate the necessary code, the code generation perspective is used
as in figure 6.3. EcuWorX allows creation of code generation templates based on
openArchitectureWare (oAW) and Perl and supports generation of artifacts based on
47
Figure 6.2: ECU conf perspective
configuration data. A Configuration framework is necessary for code generation using
EcuWorX tool.
6.2 Config framework to enable code generation
Configuration framework is a subset of the EcuWorX tool which helps in processing
of configuration data in AUTOSAR format . This framework as shown in figure6.4
enables code generation and processing of configuration data. It also enables forwarding
which means creation of new configuration data while processing.
The generated configuration files, code generation templates are input to the
configuration framework and based on the build actions, the necessary files are
generated by the tool. For file generation, there are generators which are used to
create new files. During the build process, the generators are not allowed to delete
any of the files. Also, the generators are executed in a specific order considering
48
Figure 6.3: Code generation perspective
the dependencies between the modules and also based on the files that need to be
generated.
The configuration data is given to the configuration framework which follows the
commands from the build framework. Based on the build actions the configuration
framework executes the oAW scripts in order to generate the required output.
6.3 Generation of code using oAW scripting
For code generation using EcuWorX, oAW (openArchitectureWare) is used. OpenAr-
chitectureware is an open source tool set for defining and processing models which
provides building blocks for the entire tool chain[1]. The OpenArchitectureWare is a
script language which performs an integration of the MDSD blocks with the actual
generator. oAW provides certain languages which are helpful in various contexts of
the MDSD process such as extensions, checks, model transformation, code generation
49
Figure 6.4: Configuration Framework
and so on. These languages are Xtend, Check and Xpand and they are built upon
a common type system and expression language. These languages can be used for
various purposes such as to transform the model, validation, generate code and so on.
6.3.1 Creation of Xtend scripts
In most of the cases, there are many additional features that needs to be added apart
from the existing available meta model. But these additional features cannot be added
directly into the meta model as these features are specific to a particular project and
they vary from one project to the other. Hence there needs to be a separate extension
of these additional features defined externally so that it is not added directly to the
meta model thereby polluting it.
For defining these additional features, OpenArchitectureWare provides a language
called Xtend. The main use of Xtend language is for model transformation. Before
generating any code, it is important to transform the model first and then generate
code. In model transformation, a new model is generated from an input model based
on several meta models. This transformation does not have any sort of additional side
50
effects with respect to the input model.
Xtend language is also used for model modifications. In model modification, an
existing model is modified or extended or completed. Here there is no creation of a
new model but only the existing model is modified.
The Xtend language provides the feasibility to describe the meta model extensions
and rich libraries of several independent operations based on the OpenArchitecture-
Ware expressions. These libraries can then be referred from any of the textual
languages which are based on expression framework[4]. Xtend files must be stored
with the file extension .ext.
Creation of a Xtend script is necessary in this work since many functions for
various calculations have to be defined. The created Xtend template consists of an
import statement and also a number of extension statements.
Import- This statement is used to import the namespaces.
import metamodel;
The namespaces of several different types can be imported using the import
statement. It defines an implicit namespace for the entire file. When a certain type
has to be analyzed, the namespace is searched for the required type and this namespace
contains the source as well as the destination elements of the meta model.
Example:
import bsw::DcmModule;
Here in the above example from the created script, the basic software module, in
particular, the DCM module is imported which contains all the source and destination
elements of the respective meta model.
Extension- This statement imports an extension file which contains additional
information specific to the project.
extension my::extensionfile;
The extension filename is specified in order to import the file into any file wherever
necessary but the filename has to be specified in the extension statement without the
file extension .ext. An extension statement can be used inside another extension file.
51
For example, an extension file that defines the standard libraries can be imported into
another extension file where standard libraries are used.
Example:
extension org::eclipse::xtend::util::stdlib::io;
In this example, an extension file that includes standard libraries are imported.
Function- Regarding the functions inside a Xtend file, functions can have an optional
return type which is followed by the function name and a parameter list. The function
has to be written in such a way that after the function is evaluated based on the
parameter list, a single value or expression has to be returned.
Also with respect to comments, Single line comments have the syntax //
//single line comment
And multiline comments have the syntax /* */
/* multiline comment*/
Considering a small example, in the present work, a function for internal to physical
signal conversion with resolution, offset, unit and datatype as input parameters has to
be created. Figure 6.5 shows the concept for internal to physical signal conversion and
Please refer Appendix ?? for the code. This function has to be defined in the Xtend
file. Whenever a signal conversion is required, this particular function is called by the
main template and this function has to return the corresponding converted value.
Also, the syntax for if else statement is
If(condition)then (
//statement
) Else (
//statement
)
Here ”(” braces have to be used instead of ”{” to avoid unnecessary line spacings
which does not make the generated code look good.
Also, Consider a statement from the code to convert internal value to physical value,
”phys=”+res+”*int”+”(”+unit+”)”
52
Figure 6.5: Flowchart explaining the internal to physical signal conversion
The characters within the ” ” are returned as it is while the characters outside, that is,
the parameters res and unit are returned with the values passed during the function
call. ”+” is used to concatenate the parameters and the string. Also, the evaluation
of the entire function returns a single expression.
For example, If the value of the parameters res,off and unit are 0.25, 0 and Volts
respectively, then the above line of code is evaluated to the following line below and
the whole function returns a single expression:
Phys=0.25*int(Volts)
EcuWorX provides an editor to write these files which looks as in figure 6.6 .
53
Figure 6.6: Xtend editor
6.3.2 Creation of Xpand templates
The modules are transformed using the Xtend language but for code generation, oAW
provides a language called Xpand. Xpand is one of the dedicated template language
which is mostly optimized in order to produce textual output. The Xpand language is
used to write templates that control the generation of output. These templates are
stored with a file extension .xpt.
The template file consists of IMPORT statements that can be multiple in number,
followed by a number of multiple EXTENSION statements, followed by either one or
more number of DEFINE blocks.
Another important symbol that we observe in the Xpand templates is the french
quotation marks.
54
These quotation marks serve to mainly distinguish between the output and the inter-
preted escaped control code. The main reason behind choosing these quotation marks
in the template is that, these quotations are unique and they rarely appear in any
generated output file and this makes the resulting templates more readable.
Import- This statement is used to import a meta model. Instead of typing the full
names of defines and types in the whole program which is a tiring process, a namespace
can be imported using this IMPORT statement.
This statement above imports the meta model named modelname. If this statement
is used in the template, then the unqualified names of the whole of the template files
and the types that are contained in the namespace can be used.
Example:
This import statement imports the basic software module named rba DcmDspUDS DIDModule
which contains all the source and destination elements of that particular metamodel.
Extension- Metamodels are represented in a very structural way which can be hier-
archical or graphical etc. But the problem with this kind of description is that, it is
very difficult to specify any additional behaviors such as derived properties. But, It is
also a nice idea not to add any target or project specific information and disturb the
meta model[16].
By using Extensions it is possible to add any extra features without disturbing the
main meta model in a very convenient and flexible manner.
The ExtensionFile contains all the necessary additional features and EXTENSION
import points to this file.
55
Example:
This extension statement imports the extension file that contains the standard li-
braries. The extension files that are defined by the user with respect to the additional
requirements can also be imported into the template file.
Example:
From the above example, dcmdspuds did.ext is an extension file that contains the
functions to compute the physical values of a signal, to create value range and so on.
In order to use these functions inside the template, the respective extension file con-
taining these functions have to be imported into the template using the EXTENSION
statement.
Define- Xpand templates consists of one or more DEFINE statements which are the
building blocks of the template. Every DEFINE statement in the template has a
primary parameter whose type is bound to the ”this” pointer and there can also be
many additional normal parameters . The main concept of the Xpand template is the
DEFINE block which is the most identifiable unit in the template file.
The statement must consist of the name, parameters and also the name of the meta-
model for which template is being defined. These templates are special methods of
a metaclass. There is always a ”this” pointer that can be used in order to address
the below model element. From the structure above, in the define statement , the
model element is of the type Entity. The rest of the body of the template contains
any number of statements .
Example:
56
This statement defines the function named startFunction for a model element of
type AUTOSAR.
File- The FILE statement is the outermost statement in the definition of the template.
It defines the scope of the of a file into which the output is generally written. This
statement directs the output that is generated with the help of the statements that
are present inside the body of the file in the template into the respective target files.
The name of the file contains the references to the model properties. The target file
is a file whose name is generally specified using the expression. The output that is
generated with the help of the functions inside the template are stored in the file that
is specified with a specific filename. Not only the filename but the directory under
which the file has to be stored can also be specified. This can be done by using the
”/” and hence the file is stored under the specified sub directory under the specified
filename.
Example:
57
The functions or the statements that are defined within the FILE of the template
are evaluated and the output is generated according to the template. This output
is then stored under the filename specified in the template. In case of the above
example, The function within the scope of the file is evaluated. The values within
the french quotes are evaluated and these values are taken from the configuration
that was created using EcuWorX during ECU configuration and then these values are
replaced in the template above. It is important to write the correct name within the
french quotes so that the equivalent values are then taken from the configuration.
Since there can be many identifiers and if the function is to be generated for every
identifier, it makes sense to use a for loop. In oAW scripting, FOREACH is used
for iteration in the template structure. Since this function has to be generated for
every identifier with their respective parameters, the function structure remains the
same but only the arguments passed to it are different. It is important to pass the
respective parameters of the respective identifiers when the function is called.
Consider that there are two identifiers with three and 2 parameters under them
respectively as shown in figure 6.7 .
Figure 6.7: Example of 2 DIDs with parameters under them
The function in the example has to be generated for both the identifiers with
respect to all the parameters under them. The first iteration would be with respect to
the identifiers.
58
This statement expands the body of iteration block for each element mentioned as an
expression. The identifier lies in the module rba DcmDspUDS DID which is imported
in the template. Every time an identifier has to be accessed, it has to be done via a
proper structure as defined in the parameter definition. If a parameter is being accessed
frequently, a short access can be created instead of using the whole structure every time.
With the above statement whenever the did needs to be accessed, it is sufficient to use
only ”did” instead of ”this.rba DcmDspUDS DID.rba DcmDspUDS DID DataSet.did”.
This makes the parameter access easy. Now, the function has to be called not only for
every DID but for every parameter inside the DID. Hence we need another iteration
(nested).
With this nested FOREACH statement, the function within the foreach statement is
called for every parameter under every DID. Hence for every parameter under the
respective DIDs, the corresponding parameter information is replaced in the template
and evaluated.
This generated output is then stored under the specified filename, which from the
above example is DcmDspUDS DID gen addr.c.
To summarize with the Xpand scripting from the examples above, Firstly, the model
has to be imported. Next, The extension file has to be imported. This can be the
extension file with the standard libraries or also the extension file that is defined by
the user that has additional features implemented in it. Then it is necessary to have
a define statement which is the building block of the template. This has the name, a
set of parameters and the model name. The filename in which the output is to be
stored is to be specified. The statements under this section are then stored under the
specified filename after evaluation of the template.
EcuWorX provides an editor to write these files which looks as in figure 6.8 .
59
Figure 6.8: Xpand editor
6.3.3 Creation of Check scripts
Even though the models are syntactically correct, they might be invalid semantically.
Instead of the component that is operating on the model makes implicit assumptions
or ignores the whole issue, oAW provides an option to specify all the constraints in
one place and it allows to check these constraints explicitly as a separate step in the
toolchain.
This file contains all the constraints that the model needs to satisfy in order to be
right. It is not a complicated language and is very easy to use. The constraints that
are to be defined using the Check language has to be stored in a file with an extension
.chk.
The check script consists of an import statement to import the model. This is
60
followed by the type of the check. Check constraints can be written for two types of
actions based on what action needs to be taken after the constraints are evaluated.
ERROR - The constraints are evaluated and if the condition in the constraint fails, the
message that is specified is printed but the execution of the workflow is not stopped.
WARNING - The constraints are evaluated and if the condition in the constraint fails,
the message that is specified is printed and the further execution of the workflow and
the following process is stopped[16].
The check script also specifies the context where the constraint has to be evaluated
and also mentions the type of the action to be taken, that is if the constraint has to
be evaluated is an error or just a warning. A message has to be specified which has to
be printed after evaluation of the condition that is specifed in the following line.
Example of the message to be printed and the condition:
context param ERROR ”Datatype is not set
This line tells us that the type of action here is an error. After evaluating the constraint,
the message that is specified is printed and the execution of workflow is stopped. The
next line specifies the condition that has to be evaluated.
this.datatype !=null
This condition checks that the datatype field is not empty. If the dataype field is not
configured during ECU configuration, then the check scripts throw an error message
that the datatype is not set and stop the further execution. The developer has to go
back and make sure that the datatype field is set and then repeat the execution.
Why is this check performed? In order to generate code, the parameters from the
configuration are used. But if these parameters are not configured, then the generated
code does not contain all the necessary information. Hence before the execution of
the Xpand templates, it is important to check if all the parameters that are necessary
to generate the code are configured and this is done using check scripts.
To summarize the steps, consider the Example:
import bsw;
import bsw::rba DcmDspUDS DIDModule;
61
context param ERROR ”Length is not set:”+this.shortName:
this.length !=null && this.length >0
At the first step, the model has to be imported. Next, the context where the
constraint has to be evaluated needs to be specified. In the example, the constraint is
evaluated for the class ”param”. This is followed by the type of the action ERROR
or WARNING. These keywords specifies what kind of action needs to be taken if the
constraint fails.
The message that needs to be printed in case the constraint fails is specified as
String. It is also possible to add the return value of the functions or the value of
the attributes into the error message so that it makes the message more clear and
understandable. From the example, the error message says that the length is not set
and it also specifies the shortname of the parameter. This makes it clear that the
length is not set for a particular parameter specified in the error message and it is not
necessary for the developer to go-through the whole configuration again.
Last and the most important step is the condition which is specified using an
expression. In the above example, the condition to check the length is specified. This
condition checks if the length field is configured and the value of length is greater
than 0. If this condition evaluates to true, then nothing is printed. Whereas, if the
condition evaluates to false, then the corresponding error message is printed.
6.3.4 Creation of a Workflow
Until now, from the previous sections, we had seen the individual files that are
necessary to generate the required code. The building blocks for the generator are -
The Xpand template for code generation, Xtend files for model transformation and
check scripts for model validation. In order to generate an efficient output, all these
building blocks accept the models as input, process these models and they provide the
models as output.
We have separate modular tools with their own unique functionality and in order
to combine all these tools into one complete generator, some kind of executive engine
62
is necessary.This functionality is provided by the oAW workflow.
The workflow file is an XML definition which contains a sequence of the components.
The components are mainly executed in exactly the same sequence as they are defined
in the workflow. The communication between the components happens through slots.
Slots are the entries into a global map which is controlled by workflow engine. Each
and every component has both read as well as write access to these slots though which
they can communicate with each other.
The workflow is saved with an extension .oaw. In order to run the individual
modular tools, it is necessary to define a worflow. This workflow controls which of the
modular scripts are executed and in which order. The workflow loads the necessary
input from the classpath of the metamodel. It also has a file encoding value and the
metamodel id that has to be specified. Most importantly, the template that needs to
be evaluated must also be specified.
Example of a work flow:
<workflow>
<component class=”com.bosch.oawtypesystem.actions.BCTCodeGenerator”>
<fileEncoding value=”ISO-8859-1”/>
<metaModelid=”mm”
class=”com.bosch.oawtypesystem.metamodel.cubec.CubecConfMetaModel”/>
<expand value=”templates::DcmDspUds DID::startFunction FOR model” />
</component>
<component class=”com.bosch.oawtypesystem.actions.BCTCodeGenerator”>
<fileEncoding value=”ISO-8859-1”/>
<metaModelid=”mm”
class=”com.bosch.oawtypesystem.metamodel.cubec.CubecConfMetaModel”/>
<expand value=”templates::DcmDspUds gen::configFileAts FOR model” />
</component>
</workflow>
In the example, there are two components and the respective classpaths are
63
specified and the template that needs to be executed are mentioned in the line expand
value. For the first component, the template that needs to be executed is the template
that has the name DcmDspUds DID.xpt. But with this statement the whole of the
template is not executed and this is where the DEFINE statement plays an important
role. Only the statements that are defined within the scope of the DEFINE statement
are executed and they are stored under a specific filename mentioned in FILE section
of the template. Under a single DEFINE, there can be many files and the statements
evaluated under each file are stored under their respective filenames.
Since there are 2 components mentioned in the above example, the components
are executed in the same order as they are defined in the workflow. Firstly, the
DEFINE startFunction in the template DcmDspUds DID.xpt is executed followed by
the configFileAts section of the template DcmDspUds arxml gen.xpt.
Figure 6.9: Workflow to generate the required files
The generated files are stored under the specified filename that was mentioned in
the FILE section of the template. While storing the output into these files, it is also
possible to mention the root directory where the file has to be placed. Example:
<directories value =${srcgenpath}/>It also possible to specify if the files need to be overwritten after they are generated
or to generate the file only once if the file already exists in the output folder.This is
helpful while generating the default implementations which is used for just illustrations.
By default, the generated files are overwritten in order to make sure that we have an
64
updated file and provide a useful production code. Fig 6.9 shows the workflow.
This chapter explained about the different oAW languages. In order to generate
the required code, the tool should have a template (Xpand) which describes the code
that needs to be generated. If there are any additional features that need to be
added apart from the existing meta model, then there has to be a Xtend file. There
should also be a Check file for validation purposes. When a build is triggered, the
corresponding workflow (.oaw) file is executed the files are generated in the output
folder with the filenames as specified in the scripts. In order to execute the workflow
during the build, the worflow has to be included in a BAMF file.
BAMF files are build actions which are scripts, processors, batches, compilers etc.
Figure 6.10: Predecessor and followup actions in a bamf file
that are executed by or during the ”build”. The sequence of executing the Build
Actions is (in most cases) determined by its Input and Output declarations. For the
purpose of declaring all relevant input and output information of an action, the bamf
file was introduced. If an action has to run before or after another action, then it can
be mentioned under Follow-up or predecessor actions. Figure 6.10 shows the window
to configure these actions.
All the necessary input actions have to be specified properly in the BAMF file.
65
The output files that has to be generated also has to be specified as an output artifact.
Correct input and output data relations of the affected components are absolutely
necessary to determine the correct order of data processing. Correct input and output
data relations of the affected components are absolutely necessary to determine the
correct order of data processing. If this is not done properly, code generators might
run before all the data was forwarded to the component, and this would lead to
compile or linking abort, or to different code after another run of the code generation.
And this also helps to increase the speed of code generation, since only the absolutely
necessary data is copied by EcuWorX. Fig 6.11 show the input and output actions.
Figure 6.11: Input and output actions for a proper build
Before running the generator action, it is necessary to run the validation action to
make sure that there are no errors. To check if the input, output actions are added
properly or to check if the execution order is mentioned correctly, the execution order
can be viewed in the Build control view in the code generation perspective. It is
possible to build all the actions or it is also possible to partially build the selected
actions. Fig 6.12 shows the build control view for code generation.
Hence during build, the necessary build actions are executed and the corresponding
66
Figure 6.12: Build control view of code generation
files are generated.
67
Chapter 7
Testing
This chapter focuses on testing of the generated diagnostic communication manager
software. The main aim of this master thesis is to generate a AUTOSAR diagnostic
communication manager software. Not only just the generation, but the generated
software has to be tested in order to find out if the software was generated correctly
and the respective functionalities are performed correctly. In order to do this test, a
Bosch tool named ”MASIC” is used.
MASIC is a Test Program developed at Bosch for Diagnostic Communication.
It is an interface for different Tester Devices. Using this tool, it is possible to do
automated tests with different devices, which are usually not able to communicate
with each other.
In order to test the generated Diagnostic communication manager software, we
need to have a set of test scripts which help in testing the proper functionality of
the generated software. Also, before the test scripts are loaded into MASIC, it is
necessary to make sure that the tool is configured properly. Once the tool is configured
and a proper connection is established, the test scripts can be run and the generated
software can be evaluated.
The figure 7.1 shows the setup that is needed to test the generated software for a
project based on Flexray communication. MASIC tool has to be installed in a system.
The system is connected to the ECU via CANCASEXL for communication using
68
Figure 7.1: Test setup
CCP-CAN or via a Samtec device for Flexray diagnostics.
From the above figure 7.1, CANCASEXL interface is used for CCP-CAN com-
munication using MASIC. SAMTEC-HSX interface is used for FlexRay diagnostics
communication using MASIC. The Flexray interface is FlexRay configured in CANa-
lyzer to analyze the FlexRay communication.
69
7.1 MASIC configuration
The important step is to configure MASIC correctly prior to the start of the test
scripts. In order to configure the MASIC settings, the configuration tool has to be
opened and all the MASIC parameters have to be configured. This is shown in the
figure 7.2.
Figure 7.2: MASIC configuration
It is also necessary to configure the CAN, CCP and UDS settings accordingly and
then the configuration is generated using the ”Create config” option. After all the
parameters are set correctly, the diagnostic communication can be started.
70
7.2 Generation of test configuration
After configuring MASIC, it is necessary to load the test scripts and a test configuration
in order for the tool to test the diagnostics software. These test scripts are already
available in the project whereas the test configuration has to be created. There is
already a test bench available for the particular project which consists of the test
scripts and batch files. When these batch files are executed, they invoke the iron
python interpreter and call the respective diagnostic service script. This script inturn
imports a configuration file.
A test configuration file has to be created and it consists of different number of
DIDs for different services. This configuration file can be generated using Tkgen.
Using Tkgen, a template can be created according to the required configuration file.
With the help of the input requirement excel, a2l and the template, the required
configuration file can be generated. By using Tkgen, we can avoid the effort of manual
coding to create the test configuration file.
For example: If a message with an identifier 0x0301 is to be read, the configuration
file looks as below:
0x0301: (’Voltage pressure sensor manifold pressure’, RONLY, [
(0.0009765, 1, 0, ’udsndk w’, 2, -32, 31.990234, (”V”, 1, 319.9951, 0.00))
]),
where,
0x0301 is the data identifier
’Voltage pressure sensor manifold pressure’ is the description
RONLY says the message is of type readonly.
The next line defines the resolution numerator, resolution denominator, offset, variable,
length and so on respectively.
The above data is obtained from the requirement excel and the a2l file. The test
configuration file along with the test scripts are loaded into the testing tool and the
results are obtained.
71
Chapter 8
Results
This chapter contains the results that are obtained from implementation, code genera-
tion and testing.
With respect to implementation, the parameter definition file is created successfully
according to the AUTOSAR compliance and the resulting structure looks as in figure
8.1. This structure was decided after several discussions with various teams according
to the ease of the developers. This structure is also designed in such a way that there
are no complications with respect to references to the other modules. The created
parameter definition file was loaded successfully into the configuration tool without
any schema errors. This structure also got accepted by the team as an understandable
and easy to configure structure.
The next part of the thesis is to generate the ECU configuration file from the
existing requirement excel using TKgen. Templates are written as per the configura-
tion file format and the existing requirement excel was completely converted into a
configuration file. With this implementation, now there is no need to configure all the
messages by hand in the configuration tool but the messages are already configured
by using the information in the requirement excel. The generated configuration file is
loaded successfully into the configuration tool without any format or schema errors
and the GUI looks as in figure 5.9. All the parameters that are available in the
requirement excel are already configured. This saves a lot of time in configuration
72
Figure 8.1: Result of parameter definition
because in diagnostics, a huge number of diagnostic messages have to be configured.
After generating the configuration file, the next major part in the thesis is to
create templates and other scripts that play an important role in code generation. At
first, the Xpand files is created successfully which is the main file that contains the
template of the code to be generated. All the functions that have to be generated are
contained in this file. The created Xpand file looks as in figure 6.8. Next, Xtend file
is created which has additional value added functions that are not contained in the
meta model. It is also possible to successfully import these functions into the Xpand
template wherever necessary. The created Xtend file with a function for internal to
73
physical conversion looks as in figure 6.6. Before generating code, it is necessary to
check if all the necessary data is configured correctly and for this purpose, a check
script was created successfully which checks for the specific conditions based on the
code to be generated.
The next part is to create a workflow which uses all the created scripts and generate
the required software. This was achieved by creating a BAMF file as shown in figure
6.11. It contains a generator which has the input templates, output filenames and the
value added functions and the BAMF also contains a validator which contains the
check scripts. When the build is triggered, the generators and the validators added in
the BAMF file are executed and the output files are generated successfully.
One of the problems that I encountered here was the generator was executed before
executing the validator. This means that the code generation was triggered before
checking if all the relevant data are configured or no. This resulted in generation of
incorrect code. The solution to this is, in the generator, a predecessor action has to be
set to execute the validator before executing this action. This is shown in figure 6.10.
In this way the check scripts are executed first before moving on to code generation
and if the check scripts fail, the build fails and there is no code generation. In this
way, the missed parameter can be configured and the build can be triggered again.
Another problem is, the output file that needs to be generated has to be specified in
the generator of the BAMF file as an output artifact. If this is not done, then the
corresponding output is not generated.
Hence the Diagnostic communication manager software was generated successfully.
This software has to be tested against the existing test bench. For this, a test
configuration has to be defined and this file is generated successfully with the help of
TKgen. This generated test configuration file is loaded into the testing tool which
is installed in the system. The test setup was made and the generated software was
tested if it works as expected.
With the generated software integrated into the project and with the help of test
configuration and the existing test bench, tests were run and the results were obtained.
74
With the newly generated software, it is possible to read the signals successfully.
It is possible to receive a message from the ECU and perform a signal conversion
successfully which was one of the main features that had to be implemented in this
thesis. It is also possible to read and write the EEPROM data as well as the adaption
parameters. The test result where a data has to be read and written is shown in the
figure 8.2 Here we are checking if it is possible to read and write data by identifier.
Figure 8.2: Test result - Read and write data by identifier
Firstly, a positive response is received. The received value is checked and compared
with the expected value. Here the expected data was supposed to have a length 4 and
the received data also had a length 4. The received data is also same as the expected
data and hence a proper communication is established and the generated software is
functioning correctly for this case.
Similarly several tests were run for every type of message to check if the generated
software handles the messages correctly. But while reading a message with type ATS
(Advanced tester service), there is a problem with the length of the received data.
75
Figure 8.3 shows the result with this failure.
Figure 8.3: Test result - Read data by identifier, length mismatch
Here the length of the expected data is 1 byte whereas the length of the received
data is 2 bytes. The reason for this behavior has to be analyzed at a future point
of time. Also these tests were conducted for one platform and the tests have to be
conducted for other platform as well which was not available during my work.
Not all the features of DCM were implemented and tested. Only the important
features such as read and write data by identifier and also signal conversion were
implemented. Future scope involves the implementation of the inputoutput features
and also test the generated software on another platform as well.
76
Chapter 9
Conclusion
BEG needed a tool to generate the complete Diagnostic Communication Manager
software to avoid the huge manual effort needed for coding and also to reduce
cost. Since AUTOSAR is so much in trend currently, more and more customers
wanted to move to AUTOSAR and hence the main aim of this thesis work is to
develop an efficient and user friendly tool that generates the complete AUTOSAR
Diagnostic Communication Manager software according to AUTOSAR standards and
it should also include some features that are available in the current non-AUTOSAR
software. For this purpose, various tools available at BEG were analysed. The
features, advantages and disadvantages of these tools were compared and a decision
was made based on the comparison and also discussions with several teams at BEG
to use EcuWorX to generate the required software.
This tool is now implemented with the necessary features in order to generate the
Diagnostic Communication Manager software. With this implementation, source and
header files, documentation etc. are generated successfully. The generated software is
tested with the help of existing test bench and test results were obtained. Most of
the teams at Bosch already use this tool - EcuWorX for configuration of the basic
software modules. The code generation part is just the extension of the tool and hence
it is very easy for everyone to use and it is not required to learn a complete new tool.
This tool plays an important role in the current projects and also the future projects
77
at BEG.
With this implementation, the AUTOSAR Diagnostic communication manager
software consisting a lot of diagnostic data is generated with the help of a tool and
this saves a lot of effort needed for manual coding and it also saves a lot of money.
Also with this tool, AUTOSAR can be successfully introduced into the BEG projects
with the necessary features.
From the thesis point of view, it was necessary to find out a solution to generate
the complete DCM software. The solution is achieved and some of the important
features are implemented and tested. The future work involves implementation of all
the remaining necessary functions in order to make the tool a complete success. The
generated software is currently tested for one generation of the project and it has to
be tested for the other generation as well.
78
Chapter 10
Appendix
10.1 Parameter definition
10.1.1 Parameter
<SUB-CONTAINERS>
<!DIDs -->
<ECUC-PARAM-CONF-CONTAINER-DEF>
<SHORT-NAME>did </SHORT-NAME>
<LONG-NAME>
<L-4 L=”EN”>Identifier </L-4>
</LONG-NAME>
<DESC>
<L-2 L=”EN”>The data Identifier represented in Hex</L-2>
</DESC>
<LOWER-MULTIPLICITY>0</LOWER-MULTIPLICITY>
<UPPER-MULTIPLICITY-INFINITE>true</UPPER-MULTIPLICITY-INFINITE>
<POST-BUILD-CHANGEABLE>false</POST-BUILD-CHANGEABLE>
<MULTIPLE-CONFIGURATION-CONTAINER>false</MULTIPLE-CONFIGURATION-
CONTAINER>
79
10.1.2 EEP
<ECUC-INTEGER-PARAM-DEF>
<SHORT-NAME>numbytes</SHORT-NAME>
<LONG-NAME>
<L-4 L=”EN”>Number of Bytes of an EEP</L-4>
</LONG-NAME>
<DESC>
<L-2 L=”EN”></L-2>
</DESC>
<LOWER-MULTIPLICITY>1</LOWER-MULTIPLICITY>
<UPPER-MULTIPLICITY>1</UPPER-MULTIPLICITY>
<IMPLEMENTATION-CONFIG-CLASSES>
<ECUC-IMPLEMENTATION-CONFIGURATION-CLASS>
<CONFIG-CLASS>PRE-COMPILE</CONFIG-CLASS>
<CONFIG-VARIANT>VARIANT-PRE-COMPILE</CONFIG-VARIANT>
</ECUC-IMPLEMENTATION-CONFIGURATION-CLASS>
<ECUC-IMPLEMENTATION-CONFIGURATION-CLASS>
<CONFIG-CLASS>PRE-COMPILE</CONFIG-CLASS>
<CONFIG-VARIANT>VARIANT-POST-BUILD</CONFIG-VARIANT>
</ECUC-IMPLEMENTATION-CONFIGURATION-CLASS>
</IMPLEMENTATION-CONFIG-CLASSES>
<ORIGIN>RB:0.1.0:2015-08-03</ORIGIN>
<SYMBOLIC-NAME-VALUE>false</SYMBOLIC-NAME-VALUE>
</ECUC-INTEGER-PARAM-DEF>
80
10.2 Signal conversion
import bsw;
import bsw::DcmModule;
import bsw::rba DcmDspUDS DIDModule;
extension org::eclipse::xtend::util::stdlib::io;
extension org::eclipse::xtend::util::stdlib::elementprops;
extension templates::mathlib;
Void createConversion(Real res, Integer off, String datatype, String unit):
if(res != null)then
(
if(res==0)then
”phys=int”+”(”+unit+”)”
else(
if(off==0)then
(
if(res==1)then
”phys=int”+”(”+unit+”)”
else
”phys=”+res+”*int”+”(”+unit+”)”
)else(
if(res==1)then
”phys=int+”+off+”(”+unit+”)”
else
”phys=”+res+”*int+”+off+”(”+unit+”)”
)))
else
”phys=int ()”
;
81
Abbreviations
ATS Advanced Test Service
AUTOSAR Automotive Open System Architecture
AVS Adjustment Value Service
BEG Bosch Engineering GmbH
BSW Basic Software
CAN Control Area Network
CCP CAN Calibration Protocol
DBC Database CAN
DCM Diagnostic Communication Manager
DID Data Identifier
DLC Data Length Code
DTC Diagnostic Trouble Code
ECU Electronic Control Unit
EEPROM Electrically Erasable Programmable Read-Only Memory
GmbH Gesellschaft mit beschrnkter Haftung
82
GUI Graphical User Interface
IDE Integrated Development Environment
ISO International Standards Organization
oAW openArchitectureWare
OEM Original Equipment Manufacturer
OSI Open Systems Interconnection
KWP Keyword Protocol
LIN Local Interconnect Network
MDSD Model Driven Software Development
MIL Malfunction Indicator light
SVN Subversion
SWC Software Component
UDS Unified Diagnostics Service
XML Extensible Markup Language
83
Bibliography
[1] Arno Haase, Markus Voelter, Sven Efftinge and Bernd Kolb. Introduc-
tion to openArchitectureWare 4.1.2. http://voelter.de/data/workshops/
oawSubmissionToolsWorkshop.pdf.
[2] Bosch Engineering GmbH - Internal.
[3] Deepika C.K, Byju G, Vishnu V.S. Implementation of DCM module for
AUTOSAR Version 4.0. http://www.erpublications.com/uploaded_files/
download/download_22_08_2013_08_56_11.pdf.
[4] Dr. Neil Loughran, Apr 2009. Introduction to openArchitecture-
Ware. http://www.uio.no/studier/emner/matnat/ifi/INF5120/v09/
undervisningsmateriale/OAW_Tutorial_MSc.pdf.
[5] Geoff Frost, Tarragon Embedded Technology. Automatic Code Genera-
tion for Safety Critical Systems. https://www.ricardo.com/Documents/IA/
ControlsandElectronics/Downloads/Autocodegen_paper.pdf.
[6] Helmut Frank and Uwe Schmidts, Vector. Vehicle diagnostics - The whole
story. https://vector.com/portal/medien/cmc/press/PDG/Diagnostics_
Congress_ElektronikAutomotive_200703_PressArticle_EN.pdf.
[7] ISO 14229-1 Road vehicles Unified diagnostic services (UDS). 2015. http:
//www.iso.org/iso/catalogue_detail.htm?csnumber=55283.
[8] Jenkins. https://jenkins-ci.org/.
84
[9] Liu Xiaoyan Auto Electronics Department,Beijing. Carrying out Autosar CAN di-
agnoses. http://m.eetasia.com/STATIC/PDF/201003/EEOL_2010MAR24_INTD_
EMS_TA_01.pdf?SOURCES=DOWNLOAD.
[10] Nagarjuna Rao Kandimala, Michal Sojka. Czech Technical University in Prague
2012. Safety and Security Features in AUTOSAR. https://rtime.felk.cvut.
cz/publications/public/autosar-safety-security.pdf.
[11] On-Board Diagnostics. http://www.obdsol.com/knowledgebase/
on-board-diagnostics.
[12] Paul Hoser, BMW Car IT GmbH, Munich. Usage of AU-
TOSAR Diagnostic Modules in a MOST Electronic Control
Unit. http://www.bmw-carit.com/downloads/publications/
UsageofAUTOSARDiagnosticModulesinaMOSTElectronicControlUnit.pdf.
[13] Protocols for programming interfaces. http://automotive.softing.com/en/
standards/protocols.html.
[14] Specification of Diagnostic Communication Manager 4.0.
http://www.autosar.org/fileadmin/files/releases/4-0/
software-architecture/diagnostic-services/standard/AUTOSAR_SWS_
DiagnosticCommunicationManager.pdf.
[15] Specification of ECU Configuration 4.0. http://www.autosar.org/fileadmin/
files/releases/4-0/methodology-templates/templates/standard/
AUTOSAR_TPS_ECUConfiguration.pdf.
[16] Xpand documentation. copyright 2004-2014. http://git.eclipse.org/c/
m2t/org.eclipse.xpand.git/plain/doc/org.eclipse.xpand.doc/manual/
xpand_reference.pdf.
[17] L. Bettini. Implementing Domain-Specific Languages with Xtext and Xtend. **.
Packt Publishing, Limited, 2013.
85
[18] M. Essaaidi, M. Maugeri, and C. Badica. Intelligent Distributed Computing IV:
Proceedings of the 4th International Symposium on Intelligent Distributed Com-
puting - IDC 2010, Tangier, Morocco, September 2010. Studies in Computational
Intelligence. Springer Berlin Heidelberg, 2010.
[19] K. McCord. Automotive Diagnostic Systems. S-A Design Workbench Series.
CarTech, 2011.
[20] K. Roebuck. AUTOSAR - AUTomotive Open System ARchitecture: High-impact
Strategies - What You Need to Know: Definitions, Adoptions, Impact, Benefits,
Maturity, Vendors. Emereo Pty Limited, 2011.
[21] J. Russell and R. Cohn. Autosar. Book on Demand, 2012.
86
![AUTOSAR Diagnostic Extract...8 u Diagnostic Services [76 pages] u How to describe the configuration of the diagnostic services of AUTOSAR u How to map diagnostic services to SWC or](https://img.dokumen.tips/doc/110x75/5e920c6a8508244c292b72a2/autosar-diagnostic-extract-8-u-diagnostic-services-76-pages-u-how-to-describe.jpg)
![Security modeling and automatic code generation in AUTOSAR · AUTOSAR standard [8] is an open industry standard for automotive softwarearchitecture,foundedin2003anddevelopedbyapartnershipofdif-](https://img.dokumen.tips/doc/110x75/5b580f747f8b9ad0048b67d0/security-modeling-and-automatic-code-generation-in-autosar-autosar-standard.jpg)
