In-Vehicle Automotive Network Gateway

Electronic Control Unit for Low Price Vehicle

T. S. Shamin Dudu1, S. G. Shivaprasad Yadav2, M. Arun Kumar2, Nisha C. Rani3
1 - M. Sc. [Engg.] Student, 2 - Senior Lecturer, Real Time Embedded Systems Centre,
M.S. Ramaiah School of Advanced Studies, Bangalore 560 054
3 - Senior Lecturer, Department of Electrical and Electronics Engineering, The Oxford College of Engineering.,
Bangalore 560 068

Abstract
The rising numbers of sensors, actuators and electronic controls increased the complexity of automotive networks.
Moreover, multiple network systems have evolved to meet the different requirements coming from automotive
applications. A gateway Electronic Control Unit (ECU) is a central network interconnecting system to link various field
buses in a vehicle. In this paper, a gateway ECU is proposed to interconnect Controller Area Network (CAN) and Local
Interconnect Network (LIN) field buses for Low Price Vehicles (LPVs).
A gateway ECU is necessary for addressing the communication and network challenges in todays vehicles. A study is
conducted to know about existing commercial gateway ECU, and derive the specification for a gateway ECU suitable for
LPVs. The proposed gateway ECU is designed based on this specification and implemented using PIC microcontroller
and line transceivers for interconnecting LIN and CAN buses. The designed gateway ECU has been successfully validated
using two other nodes one node with LIN and another with CAN networks.
The proposed gateway ECU has optimal functionality and is cost effective solution for LPV segments. The trends in
automotive networks and electronics show that the LPV needs to have only CAN and LIN networks in next one to two
decades. In short, the proposed gateway ECU has optimal balance between functionality and cost, and is best suitable for
LPVs.
Key Words: Electronic Control Unit, Gateway, In Vehicle Network, Control Area Network, Local Interconnect Network,
Low Price Vehicle
several ECUs and the need for information exchanges
among them have been evolved.
The
different
performance
requirements
throughout a vehicle, as well as competition among the
companies in automotive industry, have led to the
design of a large number of communication networks.
A gateway is required to manage all these in vehicle
networks and messages effectively. Network gateway is
a device or a piece of software in a computer that
forwards and routes data packets along networks. A
possible gateway concept in a LPV is depicted in Fig. 1.
This paper focuses to design, implement and validate
gateway ECU to interconnect LIN and CAN networks
of LPV.

Abbreviations
AUTOSAR
AVC-LAN
BEAN
CAN
ECU
FPGA
LIN
LPV
Mbps
MOST
OSI
PDU
PSoC
RAM
TP
TTP
kbps
uC

Automotive Open System

Architecture
Audio Visual Communication Local Area Network
Body Electronics Area Network
Controller Area Network
Electronic Control Unit
Field Programmable Gate Array
Local Interconnect Network
Low Price Vehicle
Mega bits per second
Media-Oriented System Transport
Open Systems Interconnection
Protocol Data Unit
Programmable System on- Chip
Random Access Memory
Transport Protocol
Time Triggered Protocol
kilo bits per second
Microcontroller

Smart Sensor

Door Control Unit

Dashboard Unit

1. INTRODUCTION
Since the 1970s, an exponential increase in the
number of electronic systems has been observed that
have gradually replaced those that are purely
mechanical or hydraulic as discussed in [1]. In early
days, each new function was implemented as a standalone ECU, which is a sub-system composed of a
microcontroller and a set of sensors and actuators. The
evolution of automotive electronics since 1960 was
tremendous starting from simple ignition control to Xby-wire technology by 2010 [2]. As the electronics
increased, the need for functions to be distributed over

SAS

TECH

Immobiliser

Gateway ECU

Engine ECU

Fig. 1 Possible Gateway concept in LPV

2. TRENDS IN GATEWAY ECU

Field-bus is serial bus allowing message exchange
between nodes connected to bus. Today most ECUs
exchange information with each other using field-buses.

79

Volume 8, Issue 2, September 2009

The major requirements in automotive communications

are fault tolerance, determinism, bandwidth, flexibility
and security [3] depending on the applications. For
example, determinism and bandwidth are major
requirements for powertrain application, whereas
bandwidth and flexibility are major requirements for
multimedia applications.
Today several field bus technologies are used by
different automotive system vendors. The most
common field bus technologies are LIN, CAN and
MOST. The upcoming technologies are FlexRayTM,
TTP, ZigBee etc. LIN is single wire communication
which uses master-slave concept, can transfer data up to
8 bytes in a frame at maximum data rate of 19.6 kbps.
But CAN uses multi-master concept with maximum
data rate of 1 Mbps, which has a differential bus in
physical medium. FlexRayTM has advantage of data rate
of up to 10Mbps with maximum of 255 bytes per frame
[4].
Due to higher complexity, the entire electronics in
vehicle are classified as logical domains such as
powertrain domain, chassis domain, telematics domain
etc. [5]. The range of domains in today vehicles is
between 2 and 4. In a low or mid class vehicle, typically
two domains - body and powertrain - can be found. Up
to four domains can be found in luxury cars. Besides
the body and powertrain, separate domains for
telematics and chassis are also realized. Gateways are
required to connect different vehicle domains. The
central gateway, multi-gateway or backbone topologies
are three different concepts for the organization of
domains. In small or mid sized cars, two vehicle
domains (body, powertrain) with central gateway
architecture are possible. For current luxury cars, three
domains required with multi-gateway architecture and
for future luxury cars, four or more vehicle domains
with backbone architecture could be required.
The Gateway converts a data frame from one
protocol form to another protocol form. In order to meet
the challenging demand, the gateway functionality has
been distributed between hardware and software.
Dedicated gateways must be developed with the
objective of reducing the demands on CPU. This
concept consists of a standard CPU core, an internal
RAM or Flash and several communication controllers.
One such FlexRay-CAN gateway embedded system can
be designed with MPC5554 uC, MFR4200 FlexRay
controller, CAN transceiver and FlexRay transceiver
[6].
Standardization is necessary in order to ensure the
adaptability to various platforms or systems, flexibility
to integrate the module in any existing system or
addition of new features in the module and reusability
of the module. According to AUTOSAR [7], the entire
gateway functionality can be divided into three units
PDU gateway, TP gateway and Signal gateway. PDU
gateway routes entire data packets from one network to
another and to route transport protocol data. A TP
gateway is required to transfer the extensive diagnostic
data of an ECU from one network to another via the
Transport Protocol. If only individual signals are
needed on the other network, the signal gateway
disassembles the received PDU into individual signals,
and then assembles them into one or more PDUs.
The gateway shall provide an efficient exchange of
data and on the other hand, safety-critical
communication (e.g., steer-by-wire, brake-by-wire)

SAS

TECH

must not be influenced by non-safety-critical traffic [8].

Latency and performance are important parameters of a
gateway. In contrast to the commercially available
gateways, the automotive gateway platform which is
currently developed by the UAS Technikum, Wien [8]
can be configured and expanded to a high degree
concerning both hardware and software by using a
PSoC architecture. The proposed P160 gateway
expansion board includes Xilinx Spartan-3E FPGA
(XC3S1600E) and related circuitry. One of the possible
LIN-CAN-FlexRay gateway is discussed in detail [9],
which uses MPC5516 uC and another one is discussed
in detail [10], which uses MC9S12DP256 uC.
Gateway ECU has been considered as a necessary
component in a high end vehicle since few years.
Toyota has introduced a gateway ECU in their previous
models since 2004 to interconnect communication
systems such as CAN, BEAN (Body Electronics Area
Network) and AVC - LAN [11]. Another example of
gateway is Central Electronic Module [3] in Volvo
XC90 models, which interconnects low speed CAN
(125 kpbs), high speed CAN (500 kpbs or 1 Mbps) and
LIN. In order to understand the complexity and types of
messages to be exchanged in a vehicle, CAN messages
in Mitsubishi motors GRANDIS vehicle is considered
[12]. Here, around 40 different messages are exchanged
between 8 ECUs at various intervals required by the
system.
LIN, CAN, and FlexRay protocols have different
message
transmission
speeds,
communication
paradigms and message frames. As a result, an
algorithm to minimize the differences between the
protocols is required. The differences in message
transmission speed cannot be changed because the
speeds are set by the protocols. An algorithm has been
proposed for the gateway embedded system [13] which
focuses on interpreting the message frames of each
protocol and minimizing the differences in
communication paradigms.
The trends in automotive communication are
shown in Fig. 2. From the requirements for LPVs and
focus on cost effective solutions, it can be concluded
that at least for next one to two decades, only LIN and
CAN networks needed to meet requirements of LPVs.
Hence, the proposed gateway is designed with CAN
and LIN networks only. The trends in LIN protocol
have been discussed in detail in [14], for sensor
networking application in vehicle.

Fig. 2 Trends in automotive communication [9]

80

Volume 8, Issue 2, September 2009

the behavior of a system in its operational environment.

They are as listed down below:

Environment: System shall be able to operate in

the temperature range of - 40 to 125 deg

Reliability: The system shall be consistent and

repeatable for its entire functionality

Power: Power consumption of the system shall be

optimal and support power saving modes like
sleep, idle to save power consumption

Flexibility: The system shall be flexible to add new

functionalities. The system shall have at least
16kbytes of flash memory.

Maintainability: The system shall be able to

service and upgrade very easily.

Safety: The system shall not behave in an unsafe

mode during any operations.

Cost: Cost of entire components used shall not

exceed $10.

3. DESIGN OF GATEWAY ECU FOR LPV

3.1 Specification
The specification of a typical gateway ECU for
LPV is listed down in Table 1.
Table 1 Specification of gateway ECU for LPVs
Parameters
Typical Number of ECUs
Types of Protocols
Typical Number of signals
Required maximum bus speed
Need of Operating system
Number of CAN, LIN buses
Interface to Diagnostic tester
Typical Flash memory size
Typical CPU clock speed
Message transmission time
slots

Values in LPVs
~1020
CAN, LIN
~200400
CAN : 500kbaud
LIN : 9.6kbaud
Simple scheduler
Single
Possible
32..64kB
820MHz
<=3 (10ms,100ms,
1000ms)

3.3 Design and Implementation

The high level design of proposed gateway is
shown in Fig. 3. Major components used in the
design are microcontroller, CAN and LIN
transceivers. The microcontroller chosen for
gateway implementation is PIC 18F4580 [19] from
Microchip. The CAN transceiver, MCP2551 [20] is
from Microchip and LIN transceiver, TPIC1021 [18] is
from Texas Instruments.

3.2 Major Requirements

Functional requirements: The following are the
major functional requirements of the proposed gateway
ECU. The gateway ECU shall

Use battery voltage input to derive its power

Have its own power supply unit to derive 5V

supply for uC and other digital components and 12
V supply for powering line drivers

Have a optimal scheduler to schedule CAN

transmission and LIN communication messages

Support one CAN 2.0 and one LIN 2.0 bus

interface

Have following CAN protocol requirements:

o 11 - bit identifier length
o 3 transmission time slots for transmission (10
ms, 100 ms, 1000 ms)
o Baud rate up to 500 kps

Have following LIN protocol requirements:

o 6-bit identifier
o 2 transmission time slots (100 ms, 1000 ms)
o Baud rate up to 9.6 kbps

Keep the overview of all CAN messages.

Be the master for LIN communication.

Be able to configure CAN message parametersidentifier, message length and data pointer.

Be able to configure LIN message parameters identifier, communication mode transmit/ receive
and message data.

Compute the checksum within the respective

protocol handlers.

Compute parity for identifiers of LIN within the

respective protocol handler.

Be able to configure the messages to be transferred

from CAN to LIN or LIN to CAN easily
Non-functional requirements: Non-functional
requirements are the requirements which are related to

SAS

TECH

Fig. 3 System design of gateway ECU for LPVs

3.4 Justification of the Hardware Design

81

The entire design and components used in the

proposed gateway ECU can meet the cost and
temperature requirements
The hardware components used in the design
meets automotive standards and requirements
PIC 18F4580 uC has support for both CAN (using
Enhanced CAN module) and LIN (using Enhanced
USART module) protocols
PIC 18F4580 uC conforms to CAN 2.0 and
supports LIN2.0 specifications
PIC 18F4580 uC meets the memory requirements
of the system
TPIC1021 conforms to LIN physical layer
specification revision 2.0
MCP2551 meets CAN physical layer specification
2.0

Volume 8, Issue 2, September 2009

The software design of GatMain module for the

proposed gateway ECU is shown in Fig. 5 and LINMast
module is shown in Fig. 6.

The hardware components used can be

upgradeable for incorporating more functionality
without higher cost impact.

3.5 Software Design

Start
Initialise timer for scheduler, LIN,
CAN, display and interrupts

The overall software architecture of the proposed

gateway ECU is shown in Fig 4. The entire system is
divided into small functional components in order to
have higher maintainability and scalability. The
subcomponents are:

GatMain.c: The main module of gateway to

control of the entire functionality of the system

Can.c: The CAN transmission and reception

routines defined in this module

LINMast.c: Master transmission and reception

functions for LIN are defined in this module

ProtConv.c: LIN to CAN conversion and CAN to

LIN conversion routines are handled in this
module

Disp.c : The LCD display control and routine to

refresh the display are defined in this module

OSCPU.c: The scheduler for gateway is

implemented in this module to generate 10ms time
base for the scheduler

100ms lapsed?

1000ms
lapsed?

10ms lapsed?

Yes

Yes

send CAN, LIN

messages
scheduled for
100ms

send CAN, LIN

messages
scheduled for
10ms

No

No

Yes
send CAN, LIN
messages
scheduled for
1000ms

No
Check for any
new CAN and
LIN messages received?
Yes
Check if the new message
needs to be converted?
Yes
No

Yes
if LIN to CAN
convertion?

if CAN to LIN
convertion?

Yes

No

Yes

Yes
Do protocol
convertion from
CAN to LIN

No

Do protocol
convertion from
LIN to CAN

Prepare the display buffer with

new data
Display new messages in LCD
End

Fig. 5 Software design of GatMain module

Fig. 4 Software architecture of gateway ECU

Start

Configure LIN module (Baudrate, port,

enable, data width etc.)
Configure LIN in transmit
mode

Yes

If Master node?

No

Configure LIN in receive mode

No

Extract length information

from ID, compute parity for ID

If BREAK sequence
is received?

Send BREAK sequence to

start the LIN communication

Yes
Receive SYNC and ID

Send SYNC byte 0x55 to

synchronise with Master

If Master to send
message?
Yes
Compute the checksum and
send data bytes followed by
checksum

Compute the checksum of No

data and ID

Configure LIN in receive

mode and receive all data
No
bytes and checksum from
slave

If Master is sending
the message?
Yes

Configure LIN in transmit

mode and transmit all
data bytes and checksum
from slave

Compute checksum and

verify the same against
received checksum and
validate message

Configure LIN in receive

mode

End

Receive all data bytes and

checksum from master.
Compute checksum and verify
the same against received
checksum and validate
message
End

Fig. 6 Software design of LINMast module

SAS

TECH

82

Volume 8, Issue 2, September 2009

The software design of CAN module is shown in

Fig. 7.

Start
CAN Initialisation in
Receive mode (Port,
Buadrate, mask etc)
New message
received? (Buf
status)
Yes
Identify the buffer in
which new data
received

Configure CAN
module in transmit
mode

Copy the data from

buffer to local data Yes
buffer

No

Initialise the transmit

registers with ID,
data length and data
Start the
transmission

Update the status and

increment the status
counter

No
Data transmission
is completed?
No
Yes

Scheduler
triggered? (10ms,
100ms,1000ms)
Yes
New message to be
transmitted?

}CANMsgHdr;
LIN message buffer is defined as array of the
below data structure
typedef struct {
unsigned char LIN_FrameStat;//Frame status
unsigned char LIN_ComMode;// Com mode :
(RECEIVE or TRANSMIT)
unsigned char LIN_Identifier; // Identifier
unsigned char LIN_MsgPtr[9]; // data
}LINMsgHdr;

End
No

Fig. 7 Software design of can module

The process of configuring gateway functionality
is depicted in Fig. 8. The LIN to CAN and CAN to LIN
protocol conversion algorithm (ProtConv module)
which is being performed at runtime is shown in Fig. 9.

Fig. 9 Software design of Prot-Conv module

3.7 Hardware Design

The hardware implementation of the gateway ECU
for LPV is shown in Fig. 11.

4. VALIDATION AND RESULTS

The demo concept for validating the gateway ECU
is shown in Fig. 10.

Fig. 8 Gateway functional work flow

3.6 Database Design for the Messages

CAN message buffer is defined below as an array

of the data structure.
typedef struct {
unsigned int CANID;
// Identifier
unsigned char CAN_MSGLEN;// Length
unsigned char * CAN_MsgPtr; // Data Ptr

SAS

TECH

Fig. 10 Demo concept for gateway validation

83

Volume 8, Issue 2, September 2009

D1

CP1
X1
33pF

40
39
38
37

19
20
21
22
27
28
29
30

V1
VBB

1N4001

EN
RXD
TXD

8
RC4
RC3
RC2

RB7
RB6
RB5
RB4

23
18
17

LBUS

INH

TPIC1021

LIN Bus
220pF
C2

1
4

D1
R2
1K

GN D

26
25

3
7

U2

N W ak e
V SU P

15
16
24

OSC1
OSC2

3
1

RS
E nable

D B0
D B1
D B2
D B3
D B4
D B5
D B6
D B7
7
8
9
10
11
12
13
14

RC7/RX
RC6/TX

10K

14

RC0
RC1
RC5

VO

VCC
RB0
RB1
RB2/CANTX
V SS

U3
1

36

4
5
8

V SS

RB3/CANRX

33
34
35

13

RD0
RD1
RD2
RD3
RD4
RD5
RD6
RD7

R3
3 2

VD D

12MHz XTAL

MCLR/VPP/RE3
RA0
RA1
RA2
RA3
RA4
RA5
RE0
RE1
RE2

VCC
2
15

VCC
CS1

MC1602-13 - LCD 16 x 2

TXD
RXD
Vref
Rs

CANL

V SS

33pF
C1

2
3
4
5
6
7
8
9
10

VD D

11

U1
R1
1K

32

VCC

VD D

VCC

GND
CS2
R/W

4
6

1
16
5

31

12

CANH

CAN Low
R4
120R

CAN High

MCP2551
2

PIC18F4580

Title
Gateway ECU
Size
A

Document Number
001

Date:

Sunday , February 01, 2009

Rev
000
Sheet

of

Fig. 11 Hardware design of gateway ECU

The photograph of the prototyped gateway ECU

with demo setup is shown in Fig. 12.
Gateway ECU

Power Supply

CAN Node

LIN Node

Fig. 12 Prototype of gateway ECU with one CAN

and one LIN Nodes

The gateway has been validated against the test cases

and successfully verified for its functionality. Some of
the main system test cases executed are given here:

Checking CAN reception by the gateway ECU

node. The test conditions are : 1) Connect the CAN
bus of CAN node to gateway node 2) Send one
CAN message from CAN node to gateway

SAS

TECH

84

Checking CAN transmission by the gateway ECU

node. Test conditions are : 1) Connect the CAN
bus of CAN node to gateway node 2) Send one
CAN message from gateway to CAN node
Checking the CAN transmission at various rate 10
ms, 100 ms and 1000 ms and validate the received
message. The test conditions are : 1) Connect the
CAN bus of CAN node to gateway node 2) Send
one CAN message from CAN node to gateway 3)
Repeat the message transmission in time slots 10
ms,100 ms and 1000 ms
Check the CAN communication at higher bus load.
The test conditions are : 1) Connect the CAN bus
of CAN node to gateway node 2) connect
CANalyzer to CAN bus 3) Send one CAN
message from CANalyser continuously in every
10ms
Checking LIN transmission by master gateway
node. The test conditions are:
1) Connect the
LIN bus of LIN node to gateway node 2) Send one
LIN message from gateway to LIN node
Checking LIN reception by gateway master node.
The test conditions are: 1) Connect the LIN bus of
LIN node to gateway node 2) Send one LIN
message from LIN node to gateway
Checking the LIN transmission at various rate
100ms and 1000ms and validate the received
message 1) Connect the LIN bus of LIN node to
gateway node 2) Send one LIN message from LIN
node to gateway 3) Repeat the message
transmission in time slots 100ms and 1000ms

Volume 8, Issue 2, September 2009

Cost is the major parameter considered by the LPV

manufacturers for any ECU to be considered for the
vehicle. Hence, there shall be an optimal balance of the
functionality and cost for the gateway ECU. The cost
estimation and justification of the proposed gateway
ECU is summarized in Table 2. From this, it is evident
that the proposed gateway is at least 60% cheaper than
the current commercially available gateway ECU.

Flash Memory consumption

Us ed, 22.74%

Free, 77.26%

Table 2 Cost justification of the proposed gateway

ECU for LPVs
Memory usage - Module wise

OSCPU
1%

ProtCOnv
19%

Components

Can
20%

MC9S12XDP512C PIC18F4580 :
AL : $10.27
$4.38
LIN Transceiver MCZ33689DEW : TPIC1021 :
$1.70
$0.55
CAN Transceiver MCZ33989EG : MCP2551 :
$2.33
$0.79
Total
$14.3
$5.72
(approximate)
All price for approximately 1000 samples from the
websites www.microchip.com, www.ti.com,
www.freescale.com
Tools
MC9S12XDP512 PIC18F4580
CAL
Compiler suite
CodeWarrior
MPLAB IDE :
Professional
Free
(IDE+Compiler) MPLAB C
from $1995
Compiler :
$495.00
Programmer
M68CYCLONEP PICSTART
ROE ~$498
PLUS
Programmer :
$ 223.99
Debugger
MPLAB ICD
3 : $219.99
Total
$2493.00
$938.98
(approximate)
All price for approximately for one sample from the
websites www.microchip.com, www.freescale.com
High end gateway Proposed
gateway
Development
~12-18 man
~6-12 man
effort
months
months

GatMain
18%

Library
6%

Fig. 13 Flash memory consumption in the proposed

Gateway ECU
R A M M e m o ry u sa g e

Us ed
3 4%

Fr ee
66%

RAM Usage - Module wise

can
14%

Library
7%
stack
48%

disp
11%

GatMain
1%
OSCPU
2%

LINMast
8%

ProtCOnv
9%

The following are some of the benefits of a

gateway ECU in an automotive networking system.

Easy configuration and good overview of

messages (Messages are centrally coordinated via
single database)

Higher flexibility of message transfer (Message on

one bus type can be made available to other bus
without influencing the existing setup)

Reduces cost of the complete system (By reducing

types of interface nodes between ECUs)

Highly configurable system (Addition/deletion of

nodes easily possible by just changing
configuration only in the gateway ECU)

Easily upgradeable to new technology (New bus or

protocol can be incorporated with only adapting
gateway node and not influencing any other
existing nodes)

Fig. 14 RAM memory consumption in the proposed

gateway ECU
Memory is an inevitable component in any
embedded system and is also considered as one of the
critical resource in embedded system. At the time of
micorcontroller selection, the designer always considers
the memory requirement as one of key parameters. The
Flash and RAM memory utilization in the implemented
gateway ECU using PIC 18F4580 uC is shown in Fig.
13 and Fig. 14 respectively. It is found that only 23% of
Flash memory and 34% of RAM memory is utilized in
this implementation. A good system shall have at least
30% of memory is free to implement more custom
features and hence increases flexibility of the system.

SAS

TECH

Proposed

Microcontroller

disp
14%
LINMast
22%

High end

85

Volume 8, Issue 2, September 2009

5. LIMITATIONS OF PROPOSED
GATEWAY ECU

[4]

Some of the limitations of the proposed gateway

ECU are listed down in Table 3.

[5]

Table 3 Limitation of the proposed gateway ECU

Parameter
Proposed gateway
CPU Performance Optimal performance with upto 10
MIPS and 20 MHz operation only

[6]

Message database Upto 3.2 kbytes of RAM

(256 bytes of stack and 256 bytes
for normal application, 1 Message
structure need ~14 bytes (~200
messages only can be managed)
Number of CAN Only one CAN and LIN buses
and LIN buses
possible
Coprocessor

[7]
[8]

No coprocessor available to share

CPU load

[9]
[10]

The current implementation of CAN and LIN

protocol has been validated against the OSI reference
model and inferred that the current implementation
doest not have network and session layer.

[11]

6. CONCLUSION

[12]

The conclusions at the end of this study are listed

down here:

From literature review, it was concluded that the

existing gateway ECUs does not provide cost
effective solution for LPVs.

It was also concluded that gateway ECU with

CAN and LIN networks are sufficient to meet the
requirements for LPVs.

From the cost calculation, it was concluded that

the proposed gateway ECU is very much suitable
and affordable for LPVs.

As the proposed gateway ECU have sufficient free

memory (~70%), it is still possible to enhance the
proposed gateway ECU with more features and
customize according to the customer needs,
without changing the hardware and cost.

[13]

[14]

[15]
[16]
[17]

REFERENCES

[18]

[1] Nicolas, Yeqiong, Franoise and Cdric, (Jun

2005) Trends in Automotive Communication
Systems Proceedings of the IEEE, Vol. 93, No. 6,
IEEE
[2] Jrgen Leohold, (Sep 2004) Communication
Requirements for Automotive Systems, 5th IEEE
Workshop on Factory Communication Systems
Wien WFCS
[3] Thomas Noltet, Hans Hanssont, Lucia Lo Bellot,

SAS

TECH

[19]
[20]

(2005) Automotive Communications - Past,

Current and Future vol 1, pp 985-992 IEEE
Schmid, Markus, article on Automotive Bus
Systems p29-32, www.atmel.com
Osella Massimo, (2006) Electronic Architecture
and System Engineering for Integrated Safety
Systems-Conceptual
Hardware
Architecture
Specification Deliverable D2.2, Ver 1.0 The
EASIS Consortium, pp17-24.
Suk-Hyun, Sang-won, Sung-Ho and Jae, (Oct
2006) Development of Network Gateway
Between CAN and FlexRay Protocols For ECU
Embedded Systems, SICE-ICASE International
Joint Conference ICASE
Hartmut Hrner, Vector Elecktronik, (Oct 2007)
The Universal Gateway ECU a press article in
Elektronic Automotive journal.
A. Puhm, P. Roessler, (2008) Development of a
Flexible Gateway Platform for Automotive
Networks 1-4244-1506-3/08 IEEE
Qian Hua, (Nov 2007) Body Control -from Gates
to Gateways, PA312, Freescale
Tae-Yoon, Suk-Hyun, Jin-Ho, Sung-Ho and Jae,
(Oct 2007) Gateway System with Diagnostic
Function for LIN, CAN and FlexRay,
International Conference on Control, Automation
and Systems, ICROS
Toyota, Toyota Hybrid System-Course 071Section 6 Body Electronics
Sano
Yoshiaki,
Fukatsu
Hiroki,
(2004)
Development
of
New
In-Vehicle
Communications System Mitsubishi Motors
Technical Review 2004 vol.16 pp85-91
Seung-Han Kim, Suk-Hyun Seo, (2008) A
Gateway System for an Automotive System: LIN,
CAN, and FlexRay, The IEEE International
conference on Industrial Informatics (INDIN), 13th
-16th Jul 2008
Chindris Gabriel, (May 2003) Integrating Sensor
Devices in a LIN bus network 26th International
Spring Seminar on Electronics Technology,
IEEE
OSEK/VDX Operating System Specification
Ver 2.2.3, 17th Feb 2005 http://portal.osekvdx.org1
CAN Specification, Robert Bosch GmbH Ver
2.0 Sep 1991 www.semiconductors.bosch.de1
LIN Specification Package Rev 2.0, 23rd Sep
2003 www.lin-subbus.org1
Datasheet of TPIC1021 LIN Physical Interface
Texas Instruments, Jul 2005, www.ti.com1
Data Sheet of PIC18F2480/2580/4480/4580
Microcontroller, Microchip, Revision C, Mar
2007 www.microchip.com1
Datasheet of MCP2551 High-Speed CAN
Transceiver, Microchip, Revision E, Jan 2007
www.microchip.com1
1) accessed on 21-Jan-2009

86

Volume 8, Issue 2, September 2009