Fast Ethernet to Sensor Level?

A

Thread Starter

Alvin Goh

Hi, All,
Some companies in the market are pushing the Industrial Fast Ethernet with TCP/IP into sensor level fieldbus, with the concept of unifying the ordinary 3 level network (management, controller and sensor) into one Ethernet network. Does anybody know any successful projects implementing this technology? I have some questions here:
1) Is Fast Ethernet really deterministic? What is the reliability?
Hamming Distance?
2) Is the TCP/IP efficient enough for sensor level communication?
3) TCP/IP is said to be OPEN by the vendors, is it really true?
4) As far as I know, Fast Ethernet is using the star topology with switching hub, is such structure suitable for sensor level communication?
5) Is it really necessory to unify the 3 level network into one? Is it safe?

Thanks and Regards,
Alvin Goh
 
S
By common usage, calling a network an “Ethernet” networks implies the use of TCP/IP protocols. This certainly is not a requirement, and may not be desirable. TCP/IP and Ethernet are two distinct and separable technologies. TCP/IP can successfully be and often is transported over a very wide range of physical networks—a key feature of the Internet. Ethernet can transport a wide range of non-TCP/IP protocols. There are several “Industrial” networks on the market that claim determinism and other features by layering protocols (usually Master/Slave or Token passing) over Ethernet.
Thus, in discussion like this, distinctions need to be made between
1) TCP/IP (the routable protocols over any low level communications method)
2) TCP/IP/Ethernet (TCP/IP when carried by Ethernet)
3) Ethernet (the low level local area network available with variety to physical media - twisted pair, coax, fiber optics, 10mbs, 100mbs, 1Gbs, etc)
4) The application protocols that can be carried in TCP/IP, Ethernet, or other mechanisms.

More comments within the message below:

> Some companies in the market are pushing the Industrial Fast Ethernet with TCP/IP into sensor level fieldbus, with the concept of unifying the ordinary 3 level network (management, controller and sensor) into one Ethernet network. Does anybody know any successful projects implementing this technology? I have some questions here:

> 1) Is Fast Ethernet really deterministic? What is the reliability?

> Hamming Distance?

> 2) Is the TCP/IP efficient enough for sensor level communication?<

The overhead of TCP/IP is not trivial. Especially if the protocol stack properly supports the myriad of options for both TCP and IP. Especially since most sensors have small, inexpensive CPU’s. I believe the key to TCP/IP/Ethernet at the sensor level is specialized, reduced cost silicon. Anyone got about $750,000 to do a custom TCP/IP/Ethernet chip? The technology is available, just waiting for someone to ante up.
Alternately, use Ethernet as the sensor/ control network, and TCP/IP/Ethernet for the configuration, maintenance, and higher level functions. The control stuff does not need routing (a key feature of TCP/IP) as it used locally, while the other stuff doesn’t need the speed of Ethernet with out TCP/IP and can use the routing of TCP/IP.

> 3) TCP/IP is said to be OPEN by the vendors, is it really true?<

YES YES YES TCP/IP is completely wide open and anyone who want the full specifications can get them.
There are two ways in which use of TCP/IP is limited:
1) TCP/IP is complex, making the barrier to entry very large. Writing, testing, and maintaining a fully compliant TCP/IP protocol stack is HUGE job. As a result, users and manufactures of products using TCP/IP must, as a practical matter, buy the protocol stack from folks who specialize in that business.
2) There is no universal application level protocol for TCP/IP. Most every vendor has layered their own application protocol over TCP/IP and the “openness” of this application layer is highly variable. The Modicon folks have made their implementations of Modbus over TCP/IP completely open and clearly documented—it is rapidly becoming VERY widely used.

Controlnet can be transported by TCP/IP and the protocols appear to be open to all members of ControlNet International. There is similar work underway by ODVA for DeviceNet over TCP/IP.
The application layers used over TCP/IP must match in order for two systems to inter-operate. This is an area that desperately needs standardization.

> 4) As far as I know, Fast Ethernet is using the star topology with switching hub, is such structure suitable for sensor level communication?

> 5) Is it really necessory to unify the 3 level network into one? Is it safe?<

An interesting alternative is to separate the business LAN from the Level 3 operations LAN by a router and separate the Level 3 operations LAN from the several low level sensor LANs by routers. Properly set up, this would isolate each area of control level (sensor level) networks from unneeded traffic else where in the plant, while allowing such cross traffic if needed as in the case of configuration and maintenance of sensors from any work station on any o of the LANs.
steve

Steven B. Cliff
VP, Research & Development
Control Technology, Inc.
Knoxville, TN 37950
http://www.controltechnology.com
 
R

Rob Hulsebos

> 1) Is Fast Ethernet really deterministic?<
Depends on the sw! For example, you could take Profibus and remove
the RS485 support and send the layer 2 frames via Ethernet.
Profibus itself is deterministic (token-bus). The wiring (= Ethernet)
is of no importance. However, you should not have non-Profibus
equipment on the Ethernet as this destroys the deterministic
character of Profibus.

Too bad the Profibus User's Group doesn't pursue this type of
implementation (they run it on top of TCP/IP...)

(list: the question about 'determinism' has been asked so
often, what if I make a FAQ out of it ?).

> Hamming Distance?<
You can rely on the Ethernet CRC, as on any extra measures done in sw.
There are experts that can convert CRC bitfault detecting
probabilities in a Hamming Distance.

By the way, what are your requirements here?


> 2) Is the TCP/IP efficient enough for sensor level communication?<
Well, some time ago someone in this list mailed the performance
figures for Modbus/TCP, on a 10 Mbit/s network, with 6 devices,
each with 16 bit inputs and 16 bit outputs, which resulted
in a cycle-time of 1.9 msec. That's pretty fast. The network-load
is then ca. 35%. The 10 Mbit/s bitrate counters the relative inefficiency
of Ethernet; you can do the same with a 35% loaded 1 Mbit/s CANbus in
ca. 2.2 msec (of course you don't do this but you take a 100% loaded
CANbus with 0.75 msec cycletime).


> 3) TCP/IP is said to be OPEN by the vendors, is it really true?<
What is 'OPEN' ? It doesn't mean that there are no bugs in the sw.

There is a separate Industrial Ethernet mailing list on www.onelist.com.
Or look at www.industrialethernet.com.

Greetings,
Rob
ASM Lithography/Atlas SW Tel. 040-2304034 / Fax 2304999
De Run 1110
5503 LA Veldhoven, The Netherlands
 
L
Well, I won't get into the academics of "performance", but from my
viewpoint your #4 is the biggest block to this at the moment. Sure, a
test lab with a dozen sensors will not mind patch-cables and hubs, but
what about a plant with 1300 sensors? Imagine installing & supporting
1300 patch cables (2600 RJ45 connectors) and 41 or more 32-port
switches. This is just not a viable solution. At least we'll need to
take a step backwards and return to bus-based Ethernet for sensor buses.

Contrast this to having 41 fast Ethernet nodes acting as a
gateway/bridge to 32 sensors by LONworks or F-Fieldbus or DeviceNet or
Profibus. Now you only have 41 patch cables 1 or 2 switches, plus the
sensor buses have hardware designed to be easy to maintain. It may not
be as fast, but the logistics of installation & maintenance are better.

Bottom line - Ethernet to Sensors MUST offer better value over the
sensor-bus alternatives.

Best Regards;

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132
 
> TCP/IP and Ethernet are two distinct and separable technologies.
> TCP/IP can successfully be and often is transported over a very
> wide range of physical networks -- a key feature of the Internet.

How true. This seems to be a recurring misunderstanding in the
networking discussions here. Although it is commonly derided as an
unneccessary technical detail, a working understanding of the OSI 7-
layer model is necessary to understand how modern networking
technology works and its limitations.

> The application layers used over TCP/IP must match in order for
> two systems to inter-operate. This is an area that desperately
> needs standardization.

This is an area that suffers from too much standardization. I once
saw Bob Metcalfe (co-inventor of Ethernet) speak and he made a very
relevant sound bite:

"Standards are great. Everyone should have one."

This was at a technical conference in 1989. Most of the major control
vendors (who have since developed their own application protocols -
some have done several of them) were in attendance. They took his
words to heart. Apparently they missed the sarcasm.

IMHO there are at least two factors (probably more) that work against
standardization of application protocols in the industrial control
field:

1. There are large dominant vendors that will not seriously embrace a
standard that did not originate in their own organization. They may
develop an interface module but they either overprice to discourage
its use or simply don't give their customers a reason or opportunity
to buy it. Other industries that do not have large dominant players
seem to have been able to agree on at least a smaller set of
standards. Jim Pinto had suggested rules as to why this happens.

2. The area of industrial control is inherently complex with many
many different requirements for communications. A single
communications architecture and a single set of protocols cannot
possibly address all of these niches in an optimized manner.
Tradeoffs have to be made. My impression, based upon the many
discussions on this list, is that most people do not want to make any
tradeoffs in their own application niche.

The result is an open standard for each vendor and each application
niche. This is what we have now: too many standards. Or, perhaps
given that this seems to be the result of "normal" market forces v.s.
the "abnormal" market force of the despised user specified standards,
we have the right number of standards!

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
Top