diagnostics over ip for autosar

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

IV

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 El-

mawzini 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.

V

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.

VI

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 frame’s 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

VII

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

ARP

TCP

A family of communication protocols used in computer networks

Address Resolution Protocol

Transmission Control Protocol

UDP User Datagram Protocol

ICMP

MII

I-PDU

Internet Control Message Protocol

Media Independent Interface

Interaction Layer Protocol Data Unit

ECU

MAC address

SWC

GUI

Electronic Control Unit

Media Access Control address

Software Component

Graphical User Interface

VIII

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 Overview of Ethernet stack modules: ..................................................................... 16

3.2 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

IX

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

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

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

Bibliography ................................................................................................................................ 32

32

Chapter 1

Introduction

1.1 Literature Review

Every day a new technology in car manufacturing appears. New sensors, new

accessories, new electronic parts…etc. 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 vehicle’s 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.

‎CHAPTER 1.

INTRODUCTION

2

(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 vehicle’s port wirelessly is by using the

ELM327 chip produced by ELM electronics as a gateway for OBD II and either

‎CHAPTER 1.

INTRODUCTION

3

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 Valeo’s

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

4

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.

32

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.

‎CHAPTER 2.

BACKGROUND

6

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

7

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

8

2.1.1 AUTOSAR Architecture Layers

Application (SWC’s): 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 SWC’s 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, SWC’s, 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

9

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

10

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

‎CHAPTER 2.

BACKGROUND

11

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 (non-

volatile 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

‎CHAPTER 2.

BACKGROUND

12

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.

32

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

‎CHAPTER 3.

DESIGN AND IMPLEMENTATION

14

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

client’s message. After the reception process completes, the server sends an

acknowledgment to confirm the reception of the client’s message and closes the

socket connection.

Figure ‎3-3 Code snippet on server side Figure ‎3-2 Code snippet on server side

‎CHAPTER 3.


15

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

‎CHAPTER 3.


16

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.

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.

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

‎CHAPTER 3.


17

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.

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).

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

‎CHAPTER 3.


18

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 Interface’s 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 Router’s 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.

‎CHAPTER 3.


19

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

‎CHAPTER 3.


20

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.

‎CHAPTER 3.


21

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.

‎CHAPTER 3.


22

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 frame’s corruption.

Source MAC address for example should be 12:34:56:78:9a:bc as configured

before.

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

Figure ‎3-7 ARP frame’s payload content

‎CHAPTER 3.


23

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 payload’s 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 transceiver’s

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 couldn’t 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.

‎CHAPTER 3.


24

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.

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

Figure ‎3-8 CAN message format

‎CHAPTER 3.


25

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

‎CHAPTER 3.


26

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 driver’s 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

‎CHAPTER 3.


27

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 project’s 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

‎CHAPTER 3.


28

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.

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).

Figure ‎3-12 Ethernet new Cabling Diagram

‎CHAPTER 3.


29

Figure ‎3-13 Final hardware Design

32

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 vehicle’s 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.

‎CHAPTER 4.

CONCLUSION AND FUTURE WORK

31

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 vehicle’s 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.

32

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

http://www.autosar.org/

http://datatracker.ietf.org/doc/rfc1122/?include_text=1

http://msdn.microsoft.com/enus/library/system.net.sockets.tcpclient(v=vs.71).aspx

diagnostics over ip for autosar

Documents