# Tower of Babel - Ethernet protocols, was HMI, SOFT: Where do we go from here?

J

#### Jeff Dean

While this is not strictly an HMI/Software question, it seems to relate to the "tower of babel" problem that has been touched on in previous few messages. Everyone seems to agree that communicating information from industrial hardware to PC's, other hardware, or Information Systems is important, often critical. However, this communication is not always simple or seamless using existing protocols and hardware provided by Simemens, Rockwell/AB, GE, Schneider etc etc etc. What about the emerging standards for "scheduled" or "real-time" Ethernet protocols? I wish I had a list of them all, but EtherNet/IP from Rockwell and Modbus over IP are examples that come to mind. While these do standardize life at many levels of the OSI model, they still don't eliminate the need for complex bridging between different vendors protocols or to different systems. In many cases the protocols may not even play well on the same wire. Is this truly not just an extension of proprietary models? Is there a belief that a special protocol designed for "real-time" or "scheduled" traffic is required - or is the inherent speed of 100MB Ethernet enough to allow for a few collision/recovery cycles? Jeff [email protected]

H

#### Hullsiek, William

Ralph from sisco Systems, will probably flame-me, but again, mms was designed to take care of this. Maybe some of the PuffinPLC guys will implement mms (manufacturing message service) as one of the add-ons. But then again, this was done and NO BODY bought it!! Perhaps, we should discuss how much "extra" someone is willing to pay for an "open" standard?? Is this worth $200,$500 , $1500,$2500 extra ? How many units can we sell when it is available ?? 100 - 200 per year ?? Tell me what the market is, and I am sure that some smart entrepreneur will pursue it, if it is economical. - Bill Hullsiek

C

#### Curt Wuollet

As close as I can tell the large automation vendors are scared to death of simple universal standards and have no desire to use ethernet as a go between. Instead of adopting TCP/IP and "tunneling" their protocols as Modbus/TCP does, they have instead used only the ethernet wire spec. and plopped their own "standards" on top of it. This is with the stated purpose of providing determinism, a chicken in every pot, peace on earth, and all other good things. The actual purpose is simply to subvert everything about Ethernet that is good for the user, require special hardware and above all, remain proprietary and non-interoperable with anything they don't make. As a result "Industrial Ethernet" has no more meaning than "open" in this industry. This obviously is the problem not the solution. They take the good name of Ethernet which means cheap, universal, standardized networking that works due to the standardization on TCP/IP, and turn it into something else entirely. This new Ethernet will not be cheap, universal, standardized or open and will not interoperate with the standard TCP/IP stacks that are ubiquitous. They have cleverly and deviously turned the public demand for ubiquitous, universal, interoperable ethernet as a solution into merely another brick in the "Tower of Babel" with ethernet as a marketing term to fool people in the same manner as they use "open". Am I the only one who sees this as a mere repetition of the "embrace, extend, destroy" tactic from the PC world and therefore despicable? Here's my standard: Linux does every facet of Ethernet. If I can write code for it with the standard libraries without buying, signing, or belonging to anything, then it's ethernet. If I can buy all the hardware I need on my network from Global or any etailer that does ethernet. It's ethernet. Anything else is a misappropration of what most people believe ethernet will do for them. Modbus/TCP is the only honorable attempt I've seen so far, I would love to hear of any others. regards cww

L

C

S

B

#### BKR

Is there a belief that a special protocol designed for "real-time" or "scheduled" traffic is required - or is the inherent speed of 100MB Ethernet enough to allow for a few collision/recovery cycles? Might benefit from looking at token ring ethernet. It's much more deterministic. In fact, I believe it was designed with control hardware in mind. It offers gaurantees about minimum datarate and maximum latency, and there is no possibility of collisions. So you can be sure that, eg, every device gets to transmit every 100ms. It does costs more (100-200 USD for a standard card), but it still uses CAT-5 wiring.

R

#### Rob Hulsebos

>> What about the emerging standards for "scheduled" or "real-time" >> Ethernet protocols? I wish I had a list of them all, but EtherNet/IP >> from Rockwell and Modbus over IP are examples that come to mind. >> While these do standardize life at many levels of the OSI model, >> they still don't eliminate the need for complex bridging between >> different vendors protocols or to different systems. >> In many cases the protocols may not even play well on the same wire >I have never seen a case where one protocol interferes with another. Well, I can imagine that the network messages don't mess each other up, but the performance characteristics might change if something happens on the network that you didn't expect. So I can imagine that a 'real time Ethernet protocol' runs just fine as long as it is the only one run on an Ethernet, but as soon as you start doing something else (like a huuuuuge filecopy or so) the real-time properties get lost. Rob

R

H

#### Hullsiek, William

When we evaluated Ethernet (IEEE 802.3) vs. Token-Bus (IEEE 802.4) or Token-Ring (IEEE 802.5), we discovered that Ethernet Was faster, and more reliable largely because there were better hardware drivers, more mature technology, and better multi-vendor support. IP ran considerable faster than ISO over Ethernet, again because the operating systems supported Ethernet better. In todays environment, you will find it cheaper to implement Ethernet switching, which essentially places the 'determinism' into a centrally located Hub or (hubs) if you wire it in a star configuration with redundancy. Ethernet by the lower layer definition, will re-transmit if it detects a collision (in firmware). - Billiam -

L

#### Lynn Linse

File copy was the big MAP/TOP bug-a-boo! Now it's the flashy web page with 500K of Java applets and 1.5MB of graphics that the remote web browser will try to load as fast as possible thru multiple parallel TCP channels. Even good old FTP doesn't (to my knowledge) transfer the file in multiple parallel streams! regards Lynn August Linse, Senior Product Application Engineer 15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618 [email protected] www.lantronix.com Tel: (949)300-6337 Fax: (949)453-7132

J

#### Jeff Dean

That is almost exactly my point Rob. Let me show my ignorance of at least one of the emerging protocols... I am specifically concerned if EtherNet/IP includes the scheduled/unscheduled characteristic of ControlNet. In that case, no other protocol is going to be able to exist on the same wire without effecting performance. (because other protocols will not conform to a schedule) I have not read enough specifics about EtherNet/IP to know one way or the other, but I do know it is brethren to ControlNet. Jeff [email protected]

C

#### Curt Wuollet

That's my whole point. If we can avoid proprietary protocols in the lower layers, we can use all the great stuff that works with TCP/IP on "standard" Ethernet. A token passing protocol could be run under a protocol that lives above UDP and TCP/IP normally. The 100MB Ethernet done with switches prevents collision problems and is fast enough to appear deterministic for almost any application. We lose an awful lot of versatility and flexibility with "non standard" offerings. IMHO this loss outweighs anything gained by destroying compatibility. If the automation protos use the existing internet protocol suite we can use all of the agility and versatility available to the general computing market. I would rather see them stick with proprietary transport for special apps and produce IETF compatible versions for the great majority of apps where such a product should serve admirably and give people what they expect from Ethernet. Regards cww

L