Anda di halaman 1dari 41

Media Engineering and Technology Faculty

German University in Cairo

Diagnostics over IP (DOIP)


Bachelor Thesis

Author:

Omar Elshal

Supervisor:

Prof. Dr. Ayman Elnaggar

Submission Date:

4 June, 2013

This is to certify that:


(i)

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

List of Acronyms and Definitions


AUTOSAR

AUTomotive Open System ARchitecture

BSW

Basic Software

CAN

Controller Area Network

LIN

Local Interconnect Network

DEM

Diagnostics Event Manager

DCM

Diagnostics Communication Manager

MCAL

Microcontroller Abstraction Layer

Eth

Ethernet Driver (AUTOSAR BSW module)

EthIf

Ethernet Interface (AUTOSAR BSW module)

EthTrcv

Ethernet Transceiver Driver (AUTOSAR BSW module)

TCP/IP

A family of communication protocols used in computer networks

ARP

Address Resolution Protocol

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

ICMP

Internet Control Message Protocol

MII

Media Independent Interface

I-PDU

Interaction Layer Protocol Data Unit

ECU

Electronic Control Unit

MAC address

Media Access Control address

SWC

Software Component

GUI

Graphical User Interface


VII

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

Aim of the project ............................................................................................................ 4

Chapter 2 Background ............................................................................................................. 5


2.1 AUTOSAR Architecture .................................................................................................. 7
2.1.1

AUTOSAR Architecture Layers ............................................................................... 8

2.1.2

AUTOSAR Basic Software Layer ............................................................................ 9

2.1.3

AUTOSAR Basic Software Stacks ......................................................................... 11

2.2

AUTOSAR Software Development Tools ..................................................................... 12

Chapter 3 Design and Implementation ................................................................................. 13


3.1 Documentation ............................................................................................................... 15
3.1.1
3.2

Overview of Ethernet stack modules: ..................................................................... 16

Configuration and Compilation...................................................................................... 19

3.2.1

Configuration Process: ............................................................................................ 20

3.2.2

Compilation Process: .............................................................................................. 20

3.3

Testing and Debugging .................................................................................................. 21

3.3.1

Ethernet Blocking problems: .................................................................................. 22

3.4

Back-up Plan .................................................................................................................. 24

3.5

System Design ................................................................................................................ 25

3.6

Hardware Setup .............................................................................................................. 27

3.6.1

Ethernet part: ........................................................................................................... 27

3.6.2

CAN part ................................................................................................................. 28

VIII

Chapter 4 Conclusion and Future Work .............................................................................. 30


4.1 Conclusion...................................................................................................................... 30
4.2

Future Work ................................................................................................................... 31

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

(2) Local Interconnect Network (LIN):


LIN is used for seat position motors, window lift, mirror control, light sensors and
any other application when high speed is not needed and when low cost is needed
as LIN provides bitrate only up to 20Kbps so it is the cheapest data-bus.
(3) FlexRay:
FlexRay has both the highest speed and cost .it provides bitrate up to 10Mbps and it
is used in cars like Audi A6, Audi A8, BMW x5, BMW 5 series, BMW 7 series and
other High-end vehicles only because of its high cost.

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

1.2 Aim of the project


The project aims to introduce a proof of concept that Ethernet stack is working
properly as Ethernet stack had many bugs/problems at Valeo till the moment we
came to the company. That proof of concept is achieved in two sides:
PC side: a C# application that can communicate with the BSW (Basic
Software) on the ECU or Evaluation board side.
ECU side: Configuring the Ethernet stack and Diagnostics modules along
with the remaining communication stack modules which then can
communicate with the last upper layer SW-C (Software Component) which
in turn will deal with our pc application.

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

AUTOSAR was established to handle the increasing amount of software


unnecessarily which result in:
- Technical issues:

Reliability: for safety.


Scalability: suit different vehicle and platform variants.
Standard: for correctness process at any time.
Integration: using modules from multiple suppliers.
Separating the development process of application from the utilities to make
room for innovation.

- 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

2.1 AUTOSAR Architecture


AUTOSAR architecture on the highest abstraction level comprises three main
software layers: Application, Runtime Environment and Basic Software which run
on a Microcontroller.
The AUTOSAR Basic Software is further divided in four layers: Services, ECU
Abstraction, Microcontroller Abstraction and Complex Drivers, and within these
layers are functional groups which are System, Memory, Communication Services
and many more.

Figure 2-1: AUTOSAR simple main Architecture overview

CHAPTER 2.
BACKGROUND

2.1.1

AUTOSAR Architecture Layers

Application (SWCs): consists of software components instead of layers, these


components are mapped on ECU and all the interactions of SW-C is done through
the RTE.

Runtime Environment (RTE):


provides communication abstraction to
AUTOSAR software components and/or AUTOSAR Sensor/Actuator components
which will make AUTOSAR SWCs independent from the mapping to a specific
ECU.
Basic Software (BSW): the most important layer as it provides services to
AUTOSAR application and contains standardized and ECU specific components.
AUTOSAR Libraries (Libs): collection of functions that can be called by BSW,
RTE, SWCs, other Libs and integration code.
Examples: CRC calculation, fixed/floating point mathematical, E2E calculation, Bit
handling and Crypto.

Figure 2-2: AUTOSAR Architecture general layers

CHAPTER 2.
BACKGROUND

2.1.2 AUTOSAR Basic Software Layer


1. Microcontroller Abstraction Layer: It is the lowest software layer of the Basic
Software, so it contains the drivers required for the direct access to the C and
internal peripherals.
Task: separate the higher software layer from the C.
Examples: CAN, Ethernet, DIO and ADC drivers.

2. ECU Abstraction Layer: works as an interface to the drivers of the


Microcontroller Abstraction Layer and also contains drivers for external devices.
Task: make higher software layers independent of ECU hardware layout.
Examples: CAN, Ethernet interfaces.

3. Services Layer: the highest layer of the Basic Software.


Task: provide basic services for application and Basic Software modules like:
Operating System functionality.
Vehicle network communication and management services.
Memory Services.
Diagnostic services.
Examples: NVRAM manager, COMM, ECU state manager.

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.

Figure 2-3 AUTOSAR BSW Layers

Figure 2-4 Ethernet Stack within BSW Layers

10

CHAPTER 2.
BACKGROUND

2.1.3 AUTOSAR Basic Software Stacks


System stack: provides basic services and library functions for application and
basic software modules.
Services include standardized services (operating system, timers, error memory)
and ECU specific services (ECU state management, watchdog manager).
Memory stack: provides standardized access to internal/external memory (nonvolatile memory).
Communication stack: provides standardized access to vehicle network
communication (CAN, Lin, FlexRay and Ethernet).
Input/Output (I/O) stack: provides standardized access to sensor, actuators and
ECU onboard peripherals.

Figure 2-5 AUTOSAR Basic Software stacks

11

CHAPTER 2.
BACKGROUND

2.2 AUTOSAR Software Development Tools

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.

Figure 3-1 Ethernet stack modules

32

CHAPTER 3.
DESIGN AND IMPLEMENTATION

PC simple TCP/IP application


At the beginning, I was asked to develop a simple c# application. The purpose of it
was to just communicate between two PCs through TCP/IP family protocols, One
node sends a specific message to the other node in the network using their IP address
and a Port number to pass the data through it, after receiving the message at the
other node it sends an acknowledgment to the first node to assure the reception of
the message. The other node then should be replaced by ECU after finishing the
development process of Ethernet stack.
As figure 3-4 shows, the server starts running using local IP address and starts to
listen for any client at a specific port number, then client on the other node tries to
send a specific message to this IP address and port. If the IP address and port number
were right, the server accepts the requested socket connection and start receiving
clients message. After the reception process completes, the server sends an
acknowledgment to confirm the reception of the clients message and closes the
socket connection.

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.

Figure 3-3 EthIf SW Specification example

15

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.1.1 Overview of Ethernet stack modules:


3.1.1.1 Ethernet driver (Eth):
As it belongs to the Communication drivers it offers a hardware independent
interface for all Ethernet controllers, so the main task of the Ethernet driver is to
provide the upper layer (Ethernet Interface) with a hardware independent interface
for the same controllers to make such interface uniform for them. Thus, Ethernet
Interface can access the underlying bus in a uniform manner.
This interface can provide the functionality to initialize, configure and transmit data.
Figure 3-2 shows the lower part of the Ethernet stack where one Ethernet Interface can access
many controllers using one or several Ethernet drivers.

Figure 3-4 Lower Ethernet stack module overview (Eth)

Modules that use Ethernet Driver module:


Ethernet Interface (EthIf)
Ethernet Transceiver Driver (EthTrcv)
Modules used by the Ethernet Driver module:
Development Error Tracer (DET) for reporting of development errors.
Diagnostic Event Manager (DEM) for reporting of diagnostic-relevant
events and states.

16

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.1.1.2 Ethernet Transceiver driver (EthTrcv):


Since it belongs to the MCAL or the Communication drivers, its main function is to
provide the upper layer (Ethernet Interface) a hardware abstraction and independent
interface to all similar transceivers in a uniform way. The configuration of the
Ethernet Transceiver Driver however is bus specific, since it considers the particular
characteristics of the communication transceiver.
Figure 3-5 depicts the lower part of the Ethernet stack where one Ethernet Interface can access
many transceivers using one or several Ethernet Transceiver drivers.

Figure 3-5 Lower Ethernet stack module overview (EthTrcv)

Modules that use Ethernet Transceiver Driver module:


Ethernet Interface (EthIf)
Modules used by the Ethernet Transceiver Driver module:
Ethernet Controller Driver (Eth) for transceiver access via Media
Independent Interface (MII).

17

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.1.1.3 Ethernet Interface (EthIf):


As a part of the ECU Abstraction Layer or the Communication Hardware
Abstraction more precisely, it provides the upper layers a hardware independent
interface to the Ethernet Communication System which contains different Ethernet
controllers and transceivers. So it should act as a single interface of all upper
Ethernet modules (TCP/IP stack) to the Ethernet hardware drivers.
Ethernet Interfaces main function is to allow multiple software modules transmit
and receive data through multiple Ethernet connections in a uniform way.

3.1.1.4 TCP/IP stack (TcpIp):


TCP/IP stack is not an AUTOSAR module as it is a family of predefined internet
protocols in computer networking, so it is a stack which contains a number of sub
modules which their main purpose is to send and receive different Internet Protocol
data and all the operations need for its success like segmentation and flow control.
TcpIp protocol family consists of a number of protocols like ARP, IP, DHCP,
ICMP, UDP and TCP which are implemented within the TCP/IP stack.

3.1.1.5 Socket Adaptor (SoAd):


It resides in the Services Layer between the PDU Router and TCP/IP stack. The
main task of this module is to create an interface between PDU Router or any
AUTOSAR communication service module uses PDU and a socket based TCP/IP
stack, so it can map I-PDU IDs to socket connections and vice versa.
SoAd does not provide segmentation or flow control like any TP (Transport Layer),
all these functionalities are implemented by the TCP/IP stack. Instead SoAd will
detect and fix errors resulting from TCP/IP stack operations.
PDU Routers main purpose is to deploy AUTOSAR I-PDU onto different
communication protocols. Based on their I-PDU ID the routing through a network
system type (e.g. CAN, LIN or Ethernet) is determined.

18

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.2 Configuration and Compilation


The second stage was to configure the Ethernet stack modules using EB Tresos
software after reading the SWS (Software Specifications) and SRS (Software
Requirements Specification) documentation related to Ethernet stack.
EB Tresos software is the tool used for the configuration process, all modules that
you will use in you project are put in plugins folder and after creating your project
you can import the required modules for your project in an easy way then configure
it based on your project requirements.
The importance of the configuration resides in many reasons:

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.

Figure 3-6 DEM module configuration snapshot

19

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.2.1 Configuration Process:


At First, I checked an already configured project as the Ethernet stack package was
not delivered and ready yet. The main benefits of checking this configured project
was to see how the configuration process happens and how it is related to the
documents I have read and to familiarize myself with the use of Tresos software to
speed up the configuration process when the Ethernet package arrives.
When the package has arrived, we tried to migrate the old plugins/modules with
Ethernet package plugins as it does not contain all required modules for the project
but it did not work out as Tresos software would not launch after the migration.
After many trials, we managed to launch the software and import the required
plugins/modules needed for the project to configure Ethernet stack.
Then when completing the configuration with no consistency problems (missing
items detected), comes the process of generating the source code (.c, .h, SWCD) and
check for further errors and after the project is successfully generated with no errors,
I was ready to start the compilation of the code to check for any further
warnings/errors.

3.2.2 Compilation Process:


Apart from Tresos, Wind River Diab c code complier is used to compile the project
source code generated for further warnings/errors inspection and more importantly
to compile the *Tasks file.
After successful compilation with no errors, an ELF file is generated along with
some files. This ELF file contains all project source code, so it is the file to be burnt
on the ECU for testing and validation of your real requirements on hardware.

* Tasks.c file: acts as the main method that tests the functionalities implemented

within the project.


20

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.3 Testing and Debugging


The third phase was the longest and hardest phase. After burning the source code on
the Evaluation Board for testing. The Evaluation board was connected at one node
of the Ethernet cable and the other node was connected to the PC and on the PC.
For Evaluation board/ECU side, winIDEA application was used for burning the
source code on the ECU by specifying the Elf file and then tracing and debugging
the tasks file which will run after running the project by putting breakpoints at the
functions you want to trace. For PC side, Wireshark application was running to
capture sent/received packets to/from the Evaluation Board.
At the beginning Wireshark software did not detect any packets received from ECU
and we checked the Rx Indication function at the BSW on ECU to check if the
problem from the ECU but there was no frame received from PC either, so we
decided to change the Ethernet cable and then it check again. After changing the
cable to the new layout (explained in HW section) both nodes successfully managed
to send/receive frames to each other.
In the tasks file, two periodic functions were implemented to send Ethernet ARP
frames periodically for connection initiation one function through EthIf module and
the other was via SoAd.
The ARP frame sent through EthIf was not correctly built at all after debugging, so
I used the other function which uses Socket Adaptor module.

21

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.3.1 Ethernet Blocking problems:


After managing to handle Ethernet previous problems, there is a problem I faced
which blocked us for quite a while. The ARP frames (whether request or reply) sent
from ECU was somehow corrupted and so the connection initiation process fails
each time an ARP frame sent. As Figure 3-7 shows, some bytes of the ARP frame
payload gets duplicated overwriting other bytes and causing frames corruption.
Source MAC address for example should be 12:34:56:78:9a:bc as configured
before.

Figure 3-7 ARP frames payload content

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

3.4 Back-up Plan


Our back-up plan when we started planning at the beginning of the project if the
Ethernet project progress failed at any time was one of the following approaches:
CAN to Ethernet device.
CAN to Wi-Fi device.
Or to use the CAN communication data-bus.
When we were blocked during our work on the project for hardware shortage or any
reason, we investigated more on the other plans to be ready at any time.
We searched for a device which uses the same CAN type and standards used in
Valeo, but the products we found was not available here in Egypt and the time left
would not allow us to try the CAN to Ethernet or Wi-Fi approaches.
So we had to switch from Ethernet to the CAN used in Valeo, and start designing
the *SWC and the PC application and getting the hardware required for the
simulation.
The development process using CAN was quick and fast due to the available support
on this field at Valeo, all the development process steps of integrating CAN drivers
with the c# application are explained in the next section System Design.
Each CAN message is 8 bytes in length, each byte represents some identifier
hexadecimal number used for specifying the modules needed and the type of the
data requested, for example the 3rd and 4th bytes in figure 3-8 are the hexadecimal
id for speed.

Figure 3-8 CAN message format

*SWC is the term used in AUTOSAR for ECU software program.

24

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.5 System Design


My task after that was to design a simple PC application which has a GUI that
simulates some functionalities of a vehicle and some data for diagnostics purposes.
The system consists of analog and digital inputs simulating various vehicle
functionalities which are:
Speed, RPM (Revolutions per minute), Fuel, Heat, Handbrakes, Doors and Seat
Belt.
The system also reports some DEM (Diagnostics Event Manager) events used for
diagnostics which are:
Overheat, high RPM, doors opened while driving, hand Brakes on while driving and
low fuel, then the system stores some related data, these events are requested by the
PC program to be displayed on a user friendly GUI. Some of this events are
accompanied by freeze frames which contains the data related to the bug at the exact
time it occurred for diagnostics purposes.
Figure 3-9 shows the application GUI with the features mentioned above.

Figure 3-9 Application GUI

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.

Figure 3-10 Rx Messages parsing snippet code

26

CHAPTER 3.
DESIGN AND IMPLEMENTATION

3.6 Hardware Setup


Hardware Debugger (iSystem): the iSystem debugger is used to see exactly what
happens on hardware after the execution of a certain line of code, it is connected to
the evaluation board and then we can debug/trace the projects code through
winIDEA software on PC after burning and running the source code of the specified
project.
3.6.1 Ethernet part:
The Ethernet Evaluation board shown in figure 3-11 consists of two parts:
Mother Board (XPC56XX Rev.B): manufactured by STMicroelectronics, it
contains all the needed analog and digital pins used for the project.
Daughter Board (SPC56EC74A256S): Ethernet board manufactured also by
STMicroelectronics, it is a more specific ECU which contains the RJ-45
Ethernet connector required for the communication.

Figure 3-11 Evaluation Board Overview

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.

Figure 3-12 Ethernet new Cabling Diagram

3.6.2 CAN part


The Mother Board used in Ethernet had the CAN implemented on it, so we used it
and replaced the daughter board with another one to match the new target of the
CAN project.
CAN case: it is a hardware tool used to connect the ECU to the PC through CAN
communication bus, it has a convertor case that can convert from CAN to USB
(Universal Serial Bus) so you can plug it to the PC.
Potentiometers, buttons, wires and breadboard: potentiometers used to simulate
the change that happens on analog parameters like speed and RPM along with wires
and button which are connected on the bread board and the pins of the Evaluation
board.
The full hardware simulation is illustrated in the next page (figure 3-13).

28

CHAPTER 3.
DESIGN AND IMPLEMENTATION

Figure 3-13 Final hardware Design

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.

4.2 Future Work


As for the future work, Wireless data communication can replace the wired
communication protocols in the future to add more luxury to the vehicle.
User can get diagnostics information without having to connect a wire or cable to
his/her car using three options:
Wi-Fi: where user can just use his/her laptop without having to connect any
cables to neither the car nor the laptop.
Bluetooth: where user can use just his/her mobile phone which has a
mobile application installed on it to monitor diagnostics data or either
control some functionalities of your car.
3G/4G mobile communication: this can be extremely useful if user is
away from his/her car, user can see vehicles location using GPS or can
check if the car is turned on or any other data that can help the user when
he/she is away from the car.
These proposed future solutions if done on car manufacturers level could save us a
lot of time and effort and add more luxury to our life and make it easier and more
secure.

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

Anda mungkin juga menyukai