Tasarım Ve Can / Can Can 1 Ethernet Ve Can / Atm Köprü Uygulanması

6

SAU ren

oııımıerı ı:.nstıtusu Dergisi

1

(1998)

7-14

DESIGN AND IMPLEMENTATION OF CAN 1 CAN, CAN 1 ETHERNET

AND CAN 1 ATM BRIDGES

Hüseyin Ekiz, Osman Çerezci,

Sakarya University, Adapazarı, Turkey Email. ekiz@esentepe.sau. edu. tr

ABSTRACT

The Controller Area Network (CAN) is a high performance

and highly reliable advanced serial cornmunication protocol which effıciently supports distributed real-time control systems at high speed, low cost, and a very high level data security. The CAN was originally developed as an automotive standard for a serial interface between electronic control units, but in a short time, it has become a desirable, cheap solution for networks in industrial environments. The fast growth of the CAN in industrial applications results some potential problems such as the size of the area that the devices, controlled by the CAN, are distributed and the communication between the CAN and

the

existing network systems (such as Ethernet or

ATM).

One of the solutions to these problems is to use bridges. However, the characteristics of the CAN creates problems, when CAN segments are connected by a bridge, since

CAN

frames do not contain any information related to destination address, source address, or LAN number that are used by traditional address-hased bridges for routing decisions. Thus, new bridges (suitable for the CAN protocol features) must be designed to overcome the problems.

The

objective of this paper is not only to investigate the

characteristics

of bridged CAN systems and to give a bridge proposal to connect CAN segments, but also to design and implement bridges that connect the CAN and existing LAN s and provide communication between them. I. INTRODUCTION

lt has

been shown that the CAN technology is very useful for any product/system with multiple microcontrollers and general purpose sensor/actuator bus systems for distributed real time control which could be used in industrial automation [I]. However, problems arise when the CAN is

used in an industrial environment, since the CAN bus has a limited length. In this case, one of the appropriate solutions is to segment the CAN system and, then, to connect them using an internetworking devices such as bridge. In addition, in an industrial environment, while the CAN is used by manufacturing sections to control the systems, the management department can use a LAN (Ethernet, ATM LAN, ete.). Furthermore, the CAN­ hased industrial application may need a backbone system, such as Ethernet or ATM, to extend the size of the distributed area.

In the following, after a brief explanation about the CAN protocol, the investigation of the characteristics of the interconnected CAN systems and the presentation of the models of the CAN

1

CAN, CAN

1

Ethernet and CAN

1

ATM bridges are go ing to be discussed.

1.1. Controller Area Network Protocol

The Controller Area Network communication protocol is a contention-based serial cornmunication. As an access method, the CAN uses CSMA/CR, Carrier Sense Multiple Access with Collision Resolution. The CAN although serial in nature is unlike many serial communication protocols; it contains no information relating to the destination or source addresses. Instead, the message contains an identifier which indicates the type of information contained

in

the message. The identifier is not only used to identify the message but also used in the arbitration mechanism. The CAN associates a priority with each message to be sent and uses a special arbitration mechanism to ensure that the highest priority message is the one transmitted.

In CAN, data is transmitted as a message consisting of between

1

and 8 bytes. A message may be transmitted periodically, sporadically, or on-demand and is sent as a frame (Figure

1

). More detail about the CAN protocol

and CAN frames can be found in [2].

Cootrol

Data Field CRCField 1 ACK Eııdof F

ı

;rame

ı

ır:

ı

Bw !die

Figure 1. Standard CAN data frarne fonnat

protocol. The proposed solution in the designed system II. DESIGN AND IMPLEMENT A TION OF A CAN 1

is to set the related registers of CAN chips to

CAN BRIDGE

appropriate values. A pass-through bridge

design

A bridge is a device that interconnects LANs and allows

stations connected to similar or dissimilar LANs to communicate as if both stations were on the same LAN [3,4]. This means that a bridge can be used to exten

�

the size of a CAN in industrial environments and to provıde a communication between the CAN and existing LANs (i.e., Ethernet or ATM). However, the characteristic of the CAN creates problems, when they are connected by . a internetworking device, since its' messages do not contaın any information related to destination address, source address, or LAN number that are used by traditional address-hased bridges for routing decisions. Thus, a new bridge (suitable for the CAN protocol features) must _be designed to extend the size of CAN systems or to pr

�

v

�

de communication between the CAN and other exıstıng systems [5].

One of the irnportant issues in the design of a CAN

₁

CAN br!dge is to choose the information that is used for routing decisions. The bridge to be designed should use appropriate information which is valid

in

the CAN protocol. It is proposed that the arbitration field of the CAN frame is used by the bridge for routing decisions. One other irnportant issue to be considered in the bridge design is to solve the potential problems which arise when the bridge is used to interconnect systems. One example in our case is the acknowledge process of the CAN

AFPU. Arbiıruion Field:

Processıng Uniı :ı---ı

which provides a service to extend the size of CAN­ hased systems and a hardware proposal are presented in following.

The CAN

1

CAN bridge architecture can be modelled as shown in Figure

2.

Assuroing a two port bridge, the bridge consists of two network interfaces for CAN networks, two dedicated Arbitration Field Processing Unit (AFPU), a shared memory unit for the database (look-up table), and a central processing unit to

provide

necessary control functions.

The Central Processing Unit (CPU) should exhibit

high

performance to interpret frame relaying decisions

from

the AFPU and reschedule the received frames. The CAN Interface (CI) unit provides an interface between the bridge and the CAN systems. This unit perfonns noı only CAN frame reception and transmission but also al other CAN protocol functions such as CRC processing The CI units comprise two integrated circuits;

the fus

is a microcontroller which performs the

function

involved and the second is a CAN chip that implemen1 all of the CAN protocols. The AFPU is the heart

of th

bridge and it is responsible for generating

franı

relaying decisions. Detail of the bridge processes elements and the solution of the acknowledgeme:

process can be found in [6].

Core Buffer2 Central Processing U nit CAN System 1

-t

1

.t s :s ı e ı e nt

H.Ekiz, O.Çerezci

2.1. The modeliing environments and simulation

results

A comnıercial simulation package that has been

developed to model network systems and network

devices was used to model the bridge shown in Figure

2.

ln the simulation, the simulation program models

three processes, namely; bridge operation, bridge-CAN

interconnection, and the transmission and reception of

frames. It was assumed that a microprocessor, M68000,

perfonns the bridge core processes. For simplicity the

simulation model is based upon the following

assumptions.

a) The features of the CAN evaluation board

from I&Me

products

were

chosen

in

the

implementation to d efıne the CAN interfaces [7].

b) The process times were measured as delays:

receive frame and write butfer time, bridge core

process time, and frame transmit or discard time.

c) The CAN system bus speed was chosen as

!Mbit/sec.

d) Tn the networking system (Figure 2), the

message traffic was defined with various local

message/remote message ratio as

%

70/30, 60/40,

50/50, 30170.

To obtain the performance of the designed CAN

1 CAN

bridge, the system (Figure 2) was loaded with various

locaVremote message ratios. This model indicates that a

CAN to CAN bridge overcomes the limitation (size of

the CAN). The performance of the design ed bridge was

evaluated from the utilisation of the bridge and the b us

systems (Figure 3) and the total processing time of the

bridge (Figure 4) with ditferent loads. The utilisation of

the bridge elements and the CAN buses are less than

50

%

utilisation when the load is about 5000

frame/second. This indicates that the designed bridge

performance is adequate to interconnect the CAN

segments. It can be concluded that the total process

time of the bridge (two frame receive

1 transmit time) is

acceptable for the CAN systems and the throughput of

the designed bridge is satisfactory in the system.

ln

addition,

in the bridge design, one of the most

important parameters is the. required buffer size.

Although the required buffer size changes depending

upon the message traffic, the designed system gives a

general idea about the required buffer size. The size of

bu ffer, in the worst case, must be minimum 5* 108 bi ts

in the designed system (Figure 4). This means that there

are 5 frames in the queue in the worst case.

In surnmary, the designed bridge has fulfilled the

objectives and it overcomes the limitations mentioned

in the previous sections. Both parameters, delay and

throughput which are related to the perfonnance of the

bridge, are satisfactory. However, the designed bridge

can

connect

only

CAN

systems. But,

the

commonication between CAN and Ethernet or ATM

systems is going to be a reality in the near future.

�t

1 _ı

ı

% Uillzation of CAN lnterfaces In the Brldge

-. •. -%700Clloc::allrm1:ie oi---· �----�----45 � 40

1

35

!

c 30

1

i

25

tt

5 20 � 15 10 5

ı

o,_ 100 _{2000 3000 5000 6000} '--1 T...ı Mossage ,....,_,Second

"'ol.tilization cl CAN aıses

----�--�·�

ı.o.ı 1 Traısferred Message 1 Second

% Utıllzatlon of the Brldge Core

E

%70130

----

_locaVrerrote

�

%60/•o _{locallrerrot e} %50/50 _ıocaVrermte %30fi0 locaVrerrote --+---�� ---2000 4000 6000 8000 ₁₀₀₀₀ 12000

Lo ad 1 Transferred Message Number 1 S. co nd

Figure 3. U tilisation of the designed bridge elements and CAN b us es

Tota 1 Process Time of the Bridge 4{)0 350

I

�

300

ı!

�

250 eıoo

: :

�

---=====--

-

'<1

_...,._

_--i

,---____{-.. --}_

===-�

_{- �}

�

150

t

; 100 _T � 50T

1

§

%

1or.i-o �avreırote

j

_._ %6CV40 ıocavrerrote

1

_.__ %50150 locaVrerrote --x- %30/10 ıocaVrermte --- -o�---4----­ 5-, o soo 1000 1500 2000 2500 3000

Load- Message f.llmber from each s lde of the brldge

!'QO

Required aıtrer Size in Ports of aidge

1000 1!'QQ 2000

-+-

%?CY.i:l�l

_._ o/o6!Y40 ıocan-errtte i _._ o/.'iQI!'IJ ıocan-errtte

ı

--.-- o/.:n'?O ıocan-errtte .

R>celved Message lll.ımber

3500

Figure 4. Total processing times of the bridge and required buffers size

lll- DESIGN AND IMPLEMENTATION OF A CAN

1

ETHERNET BRIDGE

When a new network protocol becomes popular in the

short term, one of the subjects to study is the

coınmunication between the new system and existing

systems. While the CAN is used in the manufacturing unit

of an industrial plant, the Ethernet may be employed by

another department. In this case, it is necessity to use a

bridge which is capable of connecting the CAN and

Ethernet networks. The bridge should provide services to

transiate dissimilar frame formats and to coınmunicate

different data link layer protocols.

The proposed solution for the connection of CAN and

.

Ethernet systems is to use a translation bridge. A

translation bridge connects LANs which use dissimilar

frame formats and different data link layer protocols. A

CAN

_{1 Ethernet translating bridge design and a hardware}

proposal for the designed system are presented below.

Both the CAN and the Ethernet systems have different

frame formats (Figure

1

and 5) and practise different

Medium Access Control (MAC) mechanisms and routing

algorithms. For routing, the CAN uses the selection

mechanism (algorithm) and the Ethernet practises the

address routing mechanism. As the MAC mechanism, the

CAN protocol uses the Collision Sense Multiple Access

₁

Collision Resolution (CSMA/CR), v,rhilst Collision Sense

Multiple Access

1 Collision Dedection

(CSMA/CD)

is

used by the Ethernet protocol.

The bridge contains the worst case translation that

requires creation or loss of fıelds representing

unmatched services. For example, the

CAN

supports

priority but the Ethernet does not. In this case,

the

translation process Ioses the priority.

When forwarding

in the opposite direction, the bridge must insert

the

priority. Another incompatibility is in frame sizes. The

Ethernet supports a larger frame size than the

CAN.

Therefore, translation requires the adding or

removing

of padding.

The structure of the bridge may be different from

the

implementation point of view. However, in general,

the

processes which should be performed on the frames

and the desired services in a CAN

1 Ethernet bridge will

be the same. The number of bridge elements, their

domain of operations, and their relations to each other

should be such that they are able to perform

the

processes required and provide the necessary services.

The detail of the required services and design principle

of the bridge can be found in (8].

4.1. The modeliing environment and simulation results

In the implementation of the system, the bridge

elements, the CAN network, and the Ethernet LAN

were modelled. For simplicity, the simulation model for

each system and each bridge entity is based on

the

following assumptions.

i-The CAN and the Ethernet systems: In the

implementation of the CAN system and the CAN

Interface Entity, the CAN board features from the

I&Me product were used [7]. The IEEE 802.3 standard

( 1 OBASE-5) is used to model all the Ethernet features.

ii-The CAN

1 Ethernet Learning and Filtering Entities

: The leaming and fıltering processes of each port of

the bridge is done in paralle

I

by each 'Learning and

Filtering Entity'. A M68000 microprocessor with i ts

peripherals is used to implement each of the Learning

and Filtering Entities.

iii-The CEFE and ECFE modules: Each of the these

entities comprises two parts; a M68000 microprocessor

based forwarding part and a memory. It is assumed that

in order to manage the database tables of the CEFE a nd

ECFE, Contents Addressable Data Managers

(CADM)

were used.

iv-The

BME

and

Memory:

A

M68000

microprocessor with its peripherals was used to model

the BME. The Sony product memory features were

chosen for memory to bui id up the database tables.

H.Ekiz, O.Çerezci

<15 18 _; Optional

--P_{r -ea_m_p -le}-�

�

D esıination 1-S-our-_ c_e- -L-.-n -gı-h -.1--- D- a-ta---l --;::- l Fram e check

Address Address lndicator Sequ ence

Ethernet Mes sage Format

M an a gement E ntity Fillerin g & Lea rning E n tity CAN Network Eth ernet Filtering & Lea rning E n tity E th er n et N et w or k

Figure S. Ethernet message and the functionality diagram of the CAN 1 Ethernet bridge

v- In the internetworking system, the message traftic was defıned with various local message/remote message ratio as % 80/20, 70/30,

60/40, 50/50.

To obtain the performance of the designed bridge, the bridged system was loaded with various local/remote message ratios. The performance of the designed bridge was evaluated from the utilisation of the bus systems, mean message arrival time to the destination node, and the total processing time of the bridge with different loads.

time, about

500

microseconds, are acceptable for an intercorınected CAN system.

60 50

1

�

40

+

.�

30

·1

;;

:;) ₂₀

f

� 10

% Utilization of the CAN B us

Lo cal/ Rem o te M es Ratio

1

• 80120%1

�

---70130%

L;=

7

o !---·--·-�-· -- �- ----�---.

From Figure

6,

it is concluded that both the systems,

CAN

and Ethernet, can support message traffic up to 3000 message 1 second. This means that the message number on both sides should be less than

3000

messages

1

second to work under an appropriate bus utilisation (less than

50%).

It can be deduced from the graph shown in Figure 7 that the message arrival time (from CAN to Ethernet) depends on the message priority. In the designed system, CN8 to EN8 messages have the highest priority, while CNl to ENI messages have the lowest priority.

o 1000 2000 3000 4000

The rate at which frames are processed and forwarded for transmission from one port to another is called the

bridge forwarding rate. As can be seen in Figure

8,

the

bridge forwarding rate affects the process time of the

messages only under heavy loads (more than 50 % bus

utilisation) and at high remote message ratios. Both the total process time of the bridge and message arrival

60

f

50 c ₄₀ o :;:ı

�

30

�

₂₀ � 10 o o

Lo ad (Transferred M e s s age 1 Second)

% Utilization of the Ethernet Bus Lo cal/ Remote M es Ratio

�80/20%

]

----+---�---

---+---.,-500 1000 1500 2000 Load (Transferred M e s s age/Se c o nd)

Figure 6. Utilisation of the buses with different message ratios in the proposed system

11

-·; 2500

Gı E i= � _> ·;::

<

c: "' Cl) ::E .. > ·e " B "' " 'ii c ı: .. .. ::;; 'O c: o u Cl) .,

e

u

:i

Message Arrival Time (CNB

to

EN8)

500 T 400 300 200 100 o T

1

-T

Lo cal/ Remote M es Ratio

11

---+--B0/20%

11

---70/30% 1--..-so/40%

1

1

---)(---50/50

;J

�---�---���----�� �--o 50 100 150 Se nt MessageNumber 1 Second

Me ssage Arrival _{T ime (CN1} to _EN1)

Locai/Remote M es

Ratlo

10 0 0

--/

80 0

t

:

=:=��:��: /

/

:::

(

-

-

::

:

:�

I

:

_ __ _ o o 5 0 10 0 150

So nt m e s s age Nu m bor 1 Se cond Figure 7. Mean message arrival time to destination node

IV. DESIGN AND IMPLEMENTATION OF A CAN

1

ATMBRIDGE

The Controller Area Network (CAN) and Asynchronous

Transfer Mode (ATM) are two very new communication

protocols. Because of the diversity of their applications, the

need to interconnect them is going to be a fact in the very

near future. This part of the study is concemed with the

design and implementation of a 'CAN 1 ATM Bridge'.

4.1. The CAN

1

ATM Bridge Implementation and Simulation Results

The CAN and the ATM LAN have different frame formats

(Figure

1

and Figure 9) and practise different routing

algorithms. For routing, the CAN uses the connectionless

method while the ATM practises connection oriented

routing mechanism. In addition, the CAN uses a shared bus

with medium access control (MAC), while a star solution is

preferred in ATM LANs. So, the internetworking device to

be designed to connect two networks can be a two port

'CAN

1 ATM Bridge' which is capable of connecting a

CAN and an ATM LAN. This bridge contains the worst

case translation that requires creation or loss of fields

representing unmatched services.

Figure 9 illustrates the proposed system architecture that

connects the CAN and the ATM systems. In this system, the

reformatİ on from the CAN frame into the ATM cell format

or vice versa is performed in three phases by the related

entities:

i-Discard unnecessary parts,

ii-Modify invalid parts offrame,

Total Process Tim e of the Bridge

_{(Ethernet to CAN)}

-g _o

:��

t�

____...,___.- ---"

�

-

-

)ll-. . ...><-'" .... :ıı 300 ...

.

,.;:

.

-

"·

·�-

---

-

-

-><·-

·

" � ..

--

·

""

::;; 200

�

2 50

ı

.

Lo

caL!

Remote

M

es Ratlo

� 150

'ii

�

100

i

-+-80120%• ----70130% 60140% ---50/50%.

::ı

50

�

� o

L---

--+---r---�----�----�-o 100 200 300 400 soo 60t 'O _ı: o � " E

Load (Transfe rred Message /Second)

Total Process Time of the Brldge (CAN to

Ethernet)

1000 -900 T soo

i

700

1

600-' / / / / ! ' / u i 500

1

ı

dcai/Remote

M es Ratıı:

;.

.. 400

T

.... ..--" ...• , .... ,.·"',.;''"' -+-80/20% a; 300 -o 200

1

-4-70/30% ı: 100

l

60/40% .. .. ::;; ₁ 1 ._,. c__50/50% _ o +---!-- ---,�-o 200 400 600 800 Lo ad (Message Nu m bar/Second)

Figure 8. Total processing time in the both ports of the bridge

iii-Add new parts.

It is proposed to use the AAL3/4 connection oriented

transmission protocol for the communication in the

ATM network. The MID field of the ATM ce ll is used

as the arbitration field of the CAN frame. When a node

wants to send a message to the CAN side, it puts the

arbitration field value of the CAN frame into the MID

field of the ATM eel!. This results in that the proposed

method will not need to use a database table for the

incorporation of the arbitration field during the

mapping process. It is alsa proposed that if destination

of the ATM message is in the CAN s ide, that message

can contain only one ce ll because of the CAN protocol

features.

The general b lock diagram of the CAN

1 ATM Bridge

is shown in Figure 10. Detail of the entities which are

related to the CAN side and the solutions of the

problems which arise during the interconnection of

CAN systems can be found in [9]. In the

implementation, the simulation program models three

systems: the bridge elements, CAN network, and the

ATM LAN.

As seen in Figure 9, the CAN

1 ATM bridge not only

provides a service to interconnect a CAN system and an

ATM LAN but alsa performs all the required functions

for the communication between end systems. The

performance of the design ed bridge was evaluated from

the utilisation of the CAN and the ATM sides of bridge

elements and total processing time of the bridge (Figure

1 I) with different loads.

H.Ekiz, O.Çerezci

From the figures, it is concluded that both sides of the bridge and both systems supports message traffıc up to 50% utilisation of the CAN bus. The utilisation of the ATM side bridge elemen ts are lower than that of the CAN s ide and the

system can support message traffic up to 6000 messages

1

see on the CAN side and up to 10000 messages/sec on the ATM s ide. Beyond this number of messages, the

GFC VPIIVCI PT! CLP CRC ST

(4 bits) (24 bits)

(3

bits) (I bit) (8 bits) (2 bits)

performance of the CAN side bridge elements can be influenced by an increase in the Ioad.

As can be seen in Figure ı ı, the bridge forwarding rate affects the process time of the messages only with a load of more than ı 500 messages per second in the ATM to CAN process. This amount of message traffic is satisfactory in the CAN

1

ATM connection.

SN MID DATA LI CRC

(4 bits) (10 bits)

(352

bits) (6 bits) (lO bits) Header

ATM Cell Format Payload

ATM END HOSTS

APPLICA T ION APPLICATION

AALJ/4 AAL3i4 _ATMSWITCH LA YER LA YER

ATM LAYER ATM LAYER _{ATM LA YER}

PHYS LAYER PHYS LAYER _PHYS

J

_PHYS

l

_PHYS

1

J

ı

ATM LAN STAR TOPOLOGY

A TMlCAN BRlDGE CAN END NO DES

BRIDGING APPLICATION APPLICA TION

LAN EMULA.

AALJ/4 DATA LINK DATA LINK

LA YER LAYEJl LA YER

MAC

ATM

LA YER

PHYS PHYS PHYS LAYER PHYS LAYER

ı

_ı

I

ı

CAN BUS TOPOLOGY

Figure 9. ATM cell structure and the layered architecture of the CAN 1 ATM bridge

CAN Filtering &

Learning Entity Forwarding Entity

ATM to CAN

Forwarding Entity

CA N Net w o rk A T MLAN

Figure 10. The functionality block diagram ofthe CAN 1 ATM bridge

Conclusion

A bridge must provide a selective frame retransmission function and interface operation which allows communication between dissimilar systems. The objective

of

this research has been the design and implementation of bridges which provide services that achieve the interconnection of CAN segments or interconnection of Ethernet

1

ATM systems.

First, bridged CAN topologies were investigated to find

the appropriate solution to extend the size of the CAN based systems in industrial environments. The results were implied that bridged topologies can be applied to CAN based controlling systems in distributed environments. Second, a bridge that provides a selective frame retransmıssıon function in the interconnected CAN system was designed and

implemented. The designed bridge has fulfılled the objectives and it overcomes the Iimitation of the

distributed area size. It is concluded that the parameters, delay and throughput which are related to the performance of the bridge, are satisfactory. Third, design and implementation of a bridge which provides a service that achieves the interconnection of CAN and Ethernet was presented. The bridge provides an adequate service between the CAN and the E thernet system. lt has been shown that the parameters, processing time, retransmission delay, and required buffer size which are related to the performance of

60

ı

SOT ı: 40

1

i

30

ı

5

i

"if'.

20

.!.

10

% Utilization of _CAN S ide Elemenis

Utilization of the CAN bu s Utilization of Cl& CAFE bus Utiliz ation of C lE o

L

---+----1--- -;--- --1----ı ı: o �

�

5 ;!.

..

o 12'

i

10 � ' 8 ..

61

J

2

1

o 1 o

300

1

250

.

ın o 2000 4000 6000 8000 10000

Number of processed message 1 Second

% Utilization of the ATM side Elemenis

1

,r

/

r-l_.._...,.--;;%;-;-;;Ut"'=�iz:-:ca-;c: tio:-=n-::o..-:f t;;:-he::-AArnPE"'-A"LC.FEo;b:;;u;�s --

-/

--% UUization of ATM Sw �ch - Host4 connection -i>- Utilization of A PIE

5000 10000 15000

Processed message number 1 Second

CAN 1 ATM Bridge Process Time

·---­ ·----· _ ... /

/

20000

� -g200

j

� �150

o

e

, _{••.. • •}

�

_s

_..

-�100

_e

�

₁

ı·

�

Ti

•• _--+-CAN

to A

_1M

Process . ı me

l

:ı; 50 .ı. ı

o

L'

-

-

-

-

-rı-

--

�L

�

�

�

�

-

=

=

A

TM

==

=

t

o

=

CA

==

N

=

Pr

oc

=

=

==

es

s

=

Ti

=

me

�

J

o

500

1000

1500

2000

Transferred Message !Wmber 1 Second

the bridge, are satisfactory in meeting the overall requirements.

Finally, a CAN

1

ATM bridge proposal was presented and general characteristic of the proposed bridge were investigated. lt is concluded that the parameters, process time, utilisation of the bridge elements, and required buffer size which are related to the performance of the bridge are satisfactory in meeting the o verall requirements.

[2]. 'Controller Area Network (CAN), LAN

in

vehicle comrnunication protocol', SAE n s 83 March 1990, SEA Information Report, pp. 20.

226-248

[3]. Hawe, B., Kirby, A., 'Transparent

Interconnection of Local Area Network with

bridges', Telecomrnunication Network vol.

3,

no

2, 1984, pp ı ı6-ı30.

[4]. Halsali

F,

'Data communication,

computer

networks, open systerns', Addison-Wesley

Pub.

1996, USA,

[5]. Ekiz H., Kutlu A., Powner ET., 'Performance

Analysis of CAN in Bridged System s',

Procceding of II Communication Symp

o

si

u

m,

Manchester, June 1995.

[6] Ekiz H., Kutlu A., Powner ET., 'Performance

Analysis of a CAN

1

CAN Bridge', Proceedings

of IEEE ICNP'96 Conference, 29

October-

1

November 1996, Ohio, USA, pp. 18 1-ı 88

[7] BCAN Network Evaluation System with 80C552/80Cı96 CPU User Manual, l&Me, Germany, ı 990.

[8]. H. Ekiz, A. Kutlu, M.D. Baba, E.T. Powner, 'Design and lmplernentation of a CAN

1

Ethemet Bridge', Proceedings of 3'd International CAN Conference, ı-2 October 1996, Paris, France, pp.

Illi 7-1 1/26

[9]. Ekiz H., E. Stipidis, Kutlu A., Powner ET_,

"Design and lmplementation of a CAN

1

ATM

LAN Bridge", Proceedings of Twelfth

International Synposium on Computer and

Information Sciences - ISCIS, pp., 27-29

October

1997, Antalya, Turkey

Fıgure ı 1. Utilisatıon of CAN/ATM sıde elements and processıng tımes in the

CAN 1 ATM Bridge

References

[1] M clauglin R., 'CAN Controlling from cars to X­ rays', IEE Networking May 95, UK.