Beruflich Dokumente
Kultur Dokumente
Author:
Omar Elshal
Supervisor:
Submission Date:
4 June, 2013
the thesis comprises only my original work towards the Bachelor Degree
(ii)
due acknowledgement has been made in the text to all other material used
Omar Elshal
4 June, 2013
Acknowledgment
I would like to thank everyone who helped me during this project. First of all I
would like to thank my supervisor Prof. Dr. Ayman Elnaggar for giving me the
chance to make my bachelor project outside into a real business environment and
for his continuous encouragement.
I would like to thank GEEDS managers at Valeo Ayman Bazaraa and Mohamed Elmawzini for their great motivation and their wise handling to the problems I faced.
I would like also to thank my supervisors at Valeo Ahmed Alaa and Bishoy
Sawerous for their patience with the many problems I faced and giving me much of
their time to assist me.
I also would like to thank all the people who helped me and gave me trainings during
my work in Valeo Karim Nasr, Irene George, Mohamed Amer, Ahmed Abd El Atie
and finally a special thanks to Khaled Magdy for his continuous support even when
i did not ask for it and for saving me a lot of time many times by his priceless
guidance.
I dedicate this work to all my family and friends.
IV
Abstract
Cars are evolving at an unbelievable rate nowadays and the data required for
diagnostics is becoming larger more than ever, Car manufacturers also are trying to
make their products more user friendly than it used to long ago. From there rises the
need for a more faster, more user-friendly communication protocol which is
Ethernet. Although it is not that new fresh protocol for most users using internet, but
for automotive industry it is.
Now it is possible to diagnose your car at your garage using just your laptop. You
can check what failures/bugs did occur during your last trip, at what exact time and
every data related to this bug at this exact moment all displayed at the screen of your
laptop with no need for any complicated diagnostic tools.
We managed to send/receive packets of data from/to evaluation board which
simulates the vehicle through Ethernet but the sent packets was getting corrupted
due to a hardware bug, so we moved to CAN communication protocol instead as a
back-up plan to finish the diagnostics part of the project to have a meaningful
simulation. The simulated inputs differ from analog to digital inputs such as: speed,
rpm, heat, fuel and handbrakes. And by changing in these inputs through
potentiometers or buttons connected to the evaluation board, our configured system
can store diagnostics events such as: over heat, low fuel and doors open while car
moving. This event are shown later on our implemented pc application for
diagnostics.
List of Figures
Figure 2-1: AUTOSAR simple main Architecture overview ......................................................... 7
Figure 2-2: AUTOSAR Architecture general layers ..................................................................... 8
Figure 2-3 AUTOSAR BSW Layers ............................................................................................ 10
Figure 2-4 Ethernet Stack within BSW Layers............................................................................. 10
Figure 2-5 AUTOSAR Basic Software stacks .............................................................................. 11
Figure 3-1 Ethernet stack modules ............................................................................................... 13
Figure 3-2 Code snippet on server side......................................................................................... 14
Figure 3-3 EthIf SW Specification example ................................................................................. 15
Figure 3-4 Lower Ethernet stack module overview (Eth) ............................................................ 16
Figure 3-5 Lower Ethernet stack module overview (EthTrcv) ..................................................... 17
Figure 3-6 DEM module configuration snapshot ......................................................................... 19
Figure 3-7 ARP frames payload content ..................................................................................... 22
Figure 3-8 CAN message format .................................................................................................. 24
Figure 3-9 Application GUI .......................................................................................................... 25
Figure 3-10 Rx Messages parsing snippet code ............................................................................ 26
Figure 3-11 Evaluation Board Overview ...................................................................................... 27
Figure 3-12 Ethernet new Cabling Diagram ................................................................................. 28
Figure 3-13 Final hardware Design .............................................................................................. 29
VI
BSW
Basic Software
CAN
LIN
DEM
DCM
MCAL
Eth
EthIf
EthTrcv
TCP/IP
ARP
TCP
UDP
ICMP
MII
I-PDU
ECU
MAC address
SWC
Software Component
GUI
Contents
Acknowledgment ......................................................................................................................... IV
Abstract ......................................................................................................................................... V
List of Figures ............................................................................................................................... VI
List of Acronyms and Definitions................................................................................................ VII
Chapter 1 Introduction ............................................................................................................. 1
1.1 Literature Review ............................................................................................................. 1
1.2
2.1.2
2.1.3
2.2
3.2.1
3.2.2
3.3
3.3.1
3.4
3.5
3.6
3.6.1
3.6.2
VIII
Bibliography ................................................................................................................................ 32
IX
Chapter 1
Introduction
1.1 Literature Review
Every day a new technology in car manufacturing appears. New sensors, new
accessories, new electronic partsetc. In modern cars all this need to have an
interconnection between them and that is why car manufacturers choose between
three types of currently available data-buses.
(1) Controller Area Network (CAN):
CAN is the most commonly used data-bus by automotive manufacturers
as it is in the middle in both cost and speed as CAN data-bus provides speed up to
1Mbps and most of diagnostic tools connect to the vehicle CAN-bus through (On
Board Diagnostics)OBD II* .
* OBD II: is a communication protocol over CAN to provide vehicles different
parameters (speed, rpm, air intake, etc.) and events (errors, test results). Car
manufacturers are enforced by law to provide an OBD II interface since 1996.
32
CHAPTER 1.
INTRODUCTION
The problem is that even FlexRay is not providing enough speed for new
applications like camera streams as the data bus needs to transfer multiple streams
from different cameras and other sensors and electronic components and that is
where the Ethernet can be used as it provides many features such as:
(1) Very high bit rate from 10Mbps to 100Gbps.
(2) Is widely used and has huge number of resources and documentation.
(3) It can provide security by lots of available encryption algorithms as CAN does
not provide security.
(4) OBD II can be used over Wi-Fi or it can even be replaced be a new more
advanced protocol for vehicle diagnostics.*
(5) No special connections or hardware needed as the hardware is already used.
(6) Competitive price as its hardware components are massively produced all over
the world.
* now the only way to connect to the vehicles port wirelessly is by using the
ELM327 chip produced by ELM electronics as a gateway for OBD II and either
CHAPTER 1.
INTRODUCTION
Bluetooth or Wi-Fi adapter but it has some limitations such as (a) does not support
all protocols (b) software needs to be specifically developed for this chip.
There has been many great applications in the market so far which are made by
third-party developers. It includes a hardware hack extension added to the vehicle
to be able to get the data their application needs, but the problem that it lacks the
crucial part as not being manufactured from the beginning of the design process of
the vehicle to be fully integrated with its system and get the maximum benefit and
data needed for either diagnostics or analysis and to make use of such technology to
add new features that can add more luxury to our cars.
That was our role when we came to Valeo. As a first Ethernet project at Valeos
branch in Egypt (VIAS), our task was to start developing Ethernet stack and
introduce a working demo application that can communicate with an ECU through
Ethernet and make use of the diagnostics stack to get some data from the ECU for
analysis/diagnostic purposes.
CHAPTER 1.
INTRODUCTION
Chapter 2
Background
Unlike Computers which come with their drivers and application software, in
automotive industry Hardware suppliers are separated from Basic Software
suppliers and application suppliers.
AUTOSAR (AUTomotive Open System ARchitecture) is an open and standardized
automotive software architecture, jointly developed by:
Automobile manufacturers.
Suppliers.
Tool developers.
Tool developers make the tools required by the Suppliers who accomplish the
software requirements asked by the Automobile manufacturers.
It is a partnership of automotive OEMs (Original Equipment Manufacturer),
suppliers and tool vendors whose objective is to create and achieve open standards
for automotive E/E (Electrics/Electronics) architectures that provides basic and
robust infrastructure to assist with developing vehicular software, user interfaces
and management for all application domains.
32
CHAPTER 2.
BACKGROUND
- Commercial issues:
Reusability for cost efficiency.
Speeding up application development process with risk containment.
Sharing between different platforms.
Thus, there are rules and key goals AUTOSAR has to abide:
1. Standardization of fundamental systems functions.
2. Transferability all through the system network.
3. Integration from different suppliers.
4. Scalability to diverse vehicle and platform variants.
5. Maintainable all through the whole product life-cycle and software
updates and upgrades over the vehicle's lifetime.
CHAPTER 2.
BACKGROUND
CHAPTER 2.
BACKGROUND
2.1.1
CHAPTER 2.
BACKGROUND
CHAPTER 2.
BACKGROUND
4. Complex Drivers Layer: starts from the hardware through the Basic Software
layers until the RTE.
Task: provide the possibility to integrate special purpose functionality which are
not specified through AUTOSAR or very high timing constrains functionalities.
10
CHAPTER 2.
BACKGROUND
11
CHAPTER 2.
BACKGROUND
EB Tresos
Tresos is a tool developed by ElektroBit (EB) and is used to configure and generate
ECU Basic Software following AUTOSAR standards. It is based on Eclipse
Environment, so it allows ECU developers to verify the consistency of
configurations and to generate code for Basic Software that conforms to AUTOSAR
standards.
Wind River Compiler
Wind River Diab Compiler is a C code compiler developed by Wind River Systems
used for embedded systems. It is mainly used to compile the code after being
successfully generated by Tresos studio.
winIDEA - iSYSTEM
WinIDEA is an Integrated Development Environment and Debugger for Embedded
Software Development and Test developed by iSystem.
Vector CANoE
CANoe is a development and testing software tool from Vector informatik. The
software is primarily used by automotive manufacturers and electronic control unit
(ECU) suppliers for development, analysis, simulation, testing, diagnostics and
start-up of ECU networks and individual ECUs.
Wireshark
Wireshark is a free, cross-platform and open-source sniffing tool and network
protocol analyzer. It is used to analyze what is happening on your network drivers
whether Ethernet or Wireless at a microscopic level.
It uses a library named pcap for capturing packets. I used it for network
troubleshooting and communication protocol analysis.
12
Chapter 3
Design and Implementation
Ethernet Stack
Ethernet stack exists in the communication stack and consists of different modules
starting from MCAL layer (Ethernet Driver, Ethernet Transceiver) then HW
Abstraction Layer (Ethernet Interface) and finally Services Layer (TCP/IP stack,
Socket Adaptor module).
Each module consists of a number of .c, .h files which contains the functions
required for transmission/reception process along with many functions to assure the
success of such processes.
32
CHAPTER 3.
DESIGN AND IMPLEMENTATION
Figure 3-2
-3 Code snippet on server side
14
CHAPTER 3.
DESIGN AND IMPLEMENTATION
3.1 Documentation
The first stage of my task at Valeo was reading AUTOSAR documents of the
Ethernet stack modules:
After getting a training about the whole AUTOSAR architecture and its main
features to understand from where to start with the Ethernet stack and which crucial
modules should be taken care of and how to read the documentation properly.
I started reading in a bottom-up approach, so I started with Ethernet driver and
Ethernet Transceiver driver at the Microcontroller Abstraction Layer then Ethernet
Interface at the Hardware Abstraction layer then at the Services layer TCP/IP stack
and finally with Socket Adaptor module which in turn deals with PDU Router.
AUTOSAR documentations are distributed into two types:
SWS (Software Specifications): contains the specifications of each module
which are required to be implemented like the example mentioned below.
SRS (Software Requirements Specification): contains the general properties
and specifications of each main stack like Ethernet, CAN, OS or COM and
within each one the properties of the modules of each stack with respect to
the whole stack should be specified there.
15
CHAPTER 3.
DESIGN AND IMPLEMENTATION
16
CHAPTER 3.
DESIGN AND IMPLEMENTATION
17
CHAPTER 3.
DESIGN AND IMPLEMENTATION
18
CHAPTER 3.
DESIGN AND IMPLEMENTATION
Reusability: you can use the same code as much as possible according to your
needs.
Flexibility: you can specify the features requested by each car manufacturer in an
easy, user-friendly fast way.
Easy: as in Figure 3-6, the GUI (Graphical User Interface) is eclipse-based, so it
can be more user-friendly to configure the features required without having to
worry about C code, you just specify your requirements and EB Tresos will
generate the code in a fast easy way.
19
CHAPTER 3.
DESIGN AND IMPLEMENTATION
* Tasks.c file: acts as the main method that tests the functionalities implemented
CHAPTER 3.
DESIGN AND IMPLEMENTATION
21
CHAPTER 3.
DESIGN AND IMPLEMENTATION
We contacted our Valeo partner in France who sent us the Ethernet package before.
We were shocked when he told us that he faced the same bug without notifying us
when sending the package, and told us that he could not find where the frame gets
corrupted and at the end he had to move on to other projects requested from him.
Then we started on preparing for a back-up plan and at the same time continuing
with the Ethernet stack debugging to make sure that there is no problem in code or
the Basic Software modules to contact HW manufacturer.
We contacted HW manufacturer (STMicroelectronics) at the same time we
proceeded with debugging but after many e-mails we did not get a clear answer to
22
CHAPTER 3.
DESIGN AND IMPLEMENTATION
our problem and I had to try last two checks which are mentioned below based on
their suggestions.
After deep debugging and tracing for the frame transmission life-cycle from SoAd
module until Eth driver, I found that the frame payload was correctly built on
Transmission buffer right before payloads bytes get loaded to the HW registers.
So the frame gets corrupted either at transceiver level or there was a hardware bug
on the Evboard. Thus, I had to check two things:
1. The first check was to read the TX pins of the transceiver before the data goes
to the controller using a digital oscilloscope, after reading transceivers
datasheet to know which pins to connect the oscilloscope wires to but after
many trials, we failed to read the frame properly and we could not find
someone who could support us at this part, so I tried another easier approach
on the second check.
2.
The other option was to measure the clock cycle of a single task and compare
it with the OS task clock configured in our project, we did that by connecting
the oscilloscope to a pin which had a periodic single task on it then measuring
the cycle time of this task. And finally we found that the cycle time were
different from the OS configured one and we couldnt reconfigure it as we do
not have the OS license and the time remaining was too short to continue on
this way, so we had to move on to the back-up plan.
23
CHAPTER 3.
DESIGN AND IMPLEMENTATION
24
CHAPTER 3.
DESIGN AND IMPLEMENTATION
25
CHAPTER 3.
DESIGN AND IMPLEMENTATION
Behind the GUI, there are CAN drivers and dll library files used for initiating the
communication between the pc application and the SWC application on top of
AUTOSAR BSW.
The classes and dll files used along with their usage are as follows:
CanXLDriver.cs: acts as the driver layer which interacts with the hardware
layer and it has all the operations required for the transmission/reception of
CAN messages and uses a dll library file named vxlapi_NET20 along with
some sub-classes in a file named models. These files are implemented by
Valeo and Vector due to their critical importance.
Abstraction.cs: acts as an interface between the drivers layer and
application layer (main class) which allow the usage of CAN functionalities
in a uniform way.
AquaGauge and AGauge: dll library files used for the design of the gauges
in the application.
MainUI.cs: the main class which makes use of most of the functionalities
implemented within the project.
MainUI_Logic.cs: received messages are parsed and classified according to
their id in this class as figure 3-10 shows.
26
CHAPTER 3.
DESIGN AND IMPLEMENTATION
27
CHAPTER 3.
DESIGN AND IMPLEMENTATION
Ethernet Cable: the cable used for the communication between the PC and the
ECU, there was a hardware bug on the RJ-45 Ethernet connector of the daughter
board as the Rx pins 4, 6 were inverted to pins 7, 8. so we made a new cable to
handle this bug and it successfully detected a connection after applying the new
diagram to the cable on both sides as shown in figure 3-12.
28
CHAPTER 3.
DESIGN AND IMPLEMENTATION
29
Chapter 4
Conclusion and Future Work
4.1 Conclusion
The manufacturing of vehicles are evolving rapidly and the technology in every part
of it is getting much faster, easier and more comfortable. At the same time car
manufacturers still depend on the old vehicle communication data bus like CAN,
Lin and FlexRay for diagnostics. At the same time diagnostics data is getting larger
like camera streams in modern cars which require higher data bandwidth.
Ethernet is best solution for such problem as it is widely used by every person who
uses internet and does not require additional hardware for communication as you
can just use your personal computer and Ethernet cable, so it is more user-friendly
than the old communication protocols.
My task was to design a PC application for a vehicle simulation system which can
get diagnostics data through Ethernet. To accomplish such task I had to configure
Ethernet stack for AUTOSAR BSW on a hardware Evaluation board which
simulates vehicles system software. The system included analog and digital inputs
such as: Speed, Heat, RPM, Fuel, Doors and Seatbelt. An ECU software program
(SWC) was implemented on top of BSW layers so as to communicate with my PC
application. The SWC also reports diagnostics events like: Overheat, Low fuel, High
RPM, Doors opened while car is moving and Handbrakes on while car is moving.
32
CHAPTER 4.
CONCLUSION AND FUTURE WORK
Some of the diagnostics data are accompanied by freeze frames which contains
some data related to the error at the exact time it occurred. All previous data is
shown in a user-friendly GUI of the pc application.
After managing to get the Ethernet stack working finally, unfortunately there was a
hardware bug which causes the Ethernet frames sent get corrupted and we could not
handle such problem due to slow support response and the limited duration nature
of the project. Thus, as a back-up plan CAN was used instead and the project was
done as planned.
31
Bibliography
[1] AUTOSAR, AUTOSAR_EXP_LayeredSoftwareArchitecture, AUTOSAR 4.0.3, May
2012.
[2] AUTOSAR, AUTOSAR_ SRS_Ethernet, AUTSAR 4.0.1, 2010.
[3] AUTOSAR, AUTOSAR_ SWS_EthernetDriver, AUTSAR 4.0.3, May 2012.
[4] AUTOSAR, AUTOSAR_ SWS_EthernetInterface, AUTSAR 4.0.3, May 2012.
[5] AUTOSAR, AUTOSAR_ SWS_EthernetTransceiverDriver, AUTSAR 4.0.3, May 2012.
[6] AUTOSAR, AUTOSAR_ SWS_SocketAdaptor, AUTSAR 4.0.3, May 2012.
[7] AUTOSAR, AUTOSAR_ SWS_TcpIp, AUTSAR 4.1.1, March 2013.
[8] AUTOSAR website. http://www.autosar.org
[9] IETF, http://datatracker.ietf.org/doc/rfc1122/?include_text=1
[10] Microsoft msdn,
http://msdn.microsoft.com/enus/library/system.net.sockets.tcpclient(v=vs.71).aspx
32