Perspectives Decotignie

7/31/2019 Perspectives Decotignie

1/12

A Perspective on Ethernet TCP/IP

as a Fieldbus

Prof. J.-D. Decotignie

CSEM Centre Suisse dElectronique et de Microtechnique SA

Jaquet-Droz 1, 2007 [email protected]

Ethernet as a Fieldbus 2CERN J.-D. Decotignie, 2001

Outline

introduction

early attempts what is new ?

7 reasons to adopt Ethernet

requirements and how Ethernet can fulfil them ?

standardisation effort

conclusion


2/12


Some Years Ago ...


Why Fieldbusses ?

we mean here a link with sensors and actuators

process9 ease configuration (auto configuration ?)

9 ease redundancy

manufacturing

9 reduce cabling costs (planning, installation, maintenance,

etc.)

9 allow to test sub-assemblies separately


3/12


Today ...


Early Attempts with Ethernet

in the early 80s

9 FACTOR, Sinec H1, LAC, ARLIC

late 80s

9 a number of proposals to improve predictability

CSMA/DCR, DOD-CSMA

some were available in silicon

MAP

randomness was a problem for the users


4/12


Why Ethernet and TCP/IP ?

attachment costs have dropped

switches and full duplex

cheap cable and connector

higher signalling rates

priorities

TCP/IP is the "lingua franca"


7 reasons to adopt Ethernet

lot of cheap and integrated silicon

integration with the Internet is straightforward with TCP/IP all conventional protocols can be used

there is a clear path to future increase of bandwidth

a single solution is now possible

existing fieldbusses have reached their limits

the market is asking for it


5/12


Tomorrow ... or was it 20 years

ago ?


Requirements

traffic (mostly small packets with low latency

9 type

sporadic (on request)

periodic or cyclic (more than a single period)

9 relationships

client-server , producer consumer

data consistency

9 simultaneous sampling and indication of consistency

9

timestamps (or precedence relationship) on data rugged and low cost solution


6/12


Bounded Latency

CSMA/CD with random backoff

9 many nodes, long packets 100% use

9 small packet 37% worst case use

9 no guarantee

9 capture effect

TCP

CPU + OS performance


Efficiency

to transmit 16 bits

9 PROFIBUS FMS ~451 bits + 2 switch times (max. large)

9 FIP ~ 122 bits + 1 switch time (max 90 bits)

9 CAN ~200 bits (request and response)

9 ethernet ~1000 bits (request and response)


7/12


How to Improve ?

switched full duplex Ethernet

admission control / traffic smoothing [Kwe00]

priorities (IEEE 802.12)

9 too few levels to be used efficiently

use master slave

use tokens [Ven94] CSMA/DCR


Some Words about Switches

add latency in absence of collisions

predictable in absence of overloads9 need to know the working principle of the switch (not

standard)

can in principle limit the impact of externally

generated traffic

may be used to add redundancy


8/12


Data Consistency

sampling

9 periodicity cannot be achieved

except with synchronised clocks

temporal consistency

event relationship

9 no guaranty

except with synchronised clocks

there exists adequate clock synchronisation

algorithms but it is difficult to get good

resolutions


Relationships

client server

9 TCP is OK

producer consumer

9 no for TCP

9 there exists IP address ranges for multicast and broadcast

9 requires the use of UDP

but no acknowledgement


9/12


Rugged and Low Cost

resistance to industrial use

9 cables

9 connectors

low cost

9 tree topology

9 additional devices

9 more CPU power

9 remote powering absent


Standardisation Efforts

Fieldbus Foundation HSE (High Speed Ethernet)

Profibus ProfiNet EtherNet/IP supported by ODVA (Open DeviceNet

Vendor Assoc.), CI (ControlNet Intl) and IEA

(Industrial Ethernet Association)

IAONA (Industrial Automation Open Networking

Alliance)

MODBUS TCP IDA (Interface for Distributed Automation)


10/12


Some Advises [bog88]

cables should be too long and of good quality

not too many nodes in a single collision domain

check the interface performance

9 generates a lot of losses

chech the correct implementation of the protocols

9

ex. random backoff


Other Advises

study the architecture carefully in order to avoid

overloads

isolate externally generated traffic

9 gateways

switches are not always necessary [Lan98]

clients hubs 10M switch 10/100 switch 1001 230 247 134

4 582 257 147

16 2035 402 331


11/12


7 reasons to avoid Ethernet

cabling is more complicated and more expensive

security in not guaranteed

the protocols do not make the job

there exist better and cheaper performing solutions

it is unlikely that a universal solution will exist

remote powering is absent Ethernet does not guarantee the temporal constraints

(even with switches)


Conclusion

Ethernet and TCP/IP can be used as a fieldbus

9 need additional protocols

9 protection against externally generated traffic

9 careful use

it is also possible to use a gateway between Ethernet

and an existing fieldbus

9 gateway role

9 other transmission media can be used (wireless, mains, etc.)


12/12

Documents

Perspectives Decotignie