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

J

Thread Starter

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

Lynn August Linse

> <CLIP> > > 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. Well, I'm not too worried about it. The big BIG difference between the "Old" Bus-wars and anything which happens on Ethernet is that there is a huge cost associated with - for example - ripping out a proprietary media to put in Profibus or DeviceNet or ???. What's the cost of "change" once the Ethernet is CORRECTLY in place - best case a reflash, worst case a change of devices/vendors. Plus since Ethernet allows more than one protocol at once, there is nothing stopping me from making a "linking-device" which has Siemens AS-511 on the serial side and Modbus/TCP, Ethernet/IP, and ProfiNet on the Ethernet side (plus I can still tunnel raw AS-511 for remote Step5 access). But also remember that a $24 Commercial Ethernet device will not pass the Industrial version of the CE mark (or FM or UL or ...). Sure, it's a nice pipe-dream that cheap Ethernet will come to industry, but just ask any product designer trying to get 2000v isolation parts or Ethernet NIC or PHY chips which support -40 DegC how "cheap" Ethernet really is. You'll find that if your control device can live out its life in the IT "clean room", Ethernet is dirt cheap. If it needs to vibrate or see the sun or weather or be hosed down, it won't be so cheap. Likely cheaper than proprietary media, but not that much. 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
 
C

Curt Wuollet

Well then, the obvious solution is a truly Open, No BS, publicly owned protocol. We have talked about this on the LPLC mailing list but, so far, have concluded that adding another spec would be adding to the problem and not a solution unless we could get a lot of vendors and users on board. Next best thing is Modbus/TCP which doesn't cost anything to use and is compatible with Real Ethernet. I commend Modicon for their superior foresight in _not_ trying to ream folks for using their protocol. This has made it the most popular single Ethernet based automation protocol in existance. This supports my conclusion that opening things up grows them much faster than simply adding yet another incompatible proprietary offering. It's not Open Source zealotry it's simply Business101, give away the razor to sell the blades. And, just exactly what did Modicon lose by allowing free use of their protocol? Nothing! in fact I'll bet they sold a lot of IO and stuff as a direct result. They've got an inkling, the other big players don't have a clue. They just can't see how much this silly NIH, lock em in, charge for the air you breathe hyperproprietary mess they've created is holding the industry back. You don't make money with protocols or software. You make money selling hardware and services. You can sell more hardware and services if you can sell it to more customers. You can sell it to many many more customers if it doesn't only work with your stuff. This is painfully obvious, yet they continue to work hard to see that their stuff is usable by the smallest possible customer base by making it incompatible with everything else. That isn't Business101, that isn't very smart. and it's obviously not the way to grow an industry. I have no idea where that model came from but when the market is badly fragmented already it doesn't make any sense except for locking in the customers you already have. Regards cww
 
P

Peter Nachtwey

> 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. Rockwell/AB and Schneider/Modicon Ethernet is easy. So is Automation Direct and Omron. > > 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. > 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? I haven't seen or heard of any PLC that use 100 MB Ethernet but this is not the problem. Lack of processing power, the PLC back plane bottle neck and complicated application layers and the TCP stack are. Peter Nachtwey Delta Computer Systems, Inc.
 
R

Ralph Mackiewicz

> 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. You have it backwards Bill: Ralph won't flame you for essentially making the same point that I would. Truly open and public standards, like MMS, ALREADY exist. But MMS can't be implemented in a half a day and it will cost someone an outrageous amount of money (like a few hundred dollars) to obtain a copy of the standards. > But then again, this was done and NO BODY bought it!! This isn't true or I would be selling pencils on a street corner. Not enough people in the manufacturing segment bought it which is why the primary usage of MMS is elsewhere (under the ICCP-TASE.2 (IEC60870-6) and UCA (IEC61850) umbrellas). MMS was developed and introduced long before the manufacturing industry was ready to adapt standard networking gear like Ethernet. And, it was unfortunate enough to get caught in the insane vendor bashing experiment that was MAP. The current trend is to take every existing low-end register access protocol that uses specialized links and run them on Ethernet TCP/IP instead. This does solve some of the problems but does not address the need for a common application protocol. > 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 ?? I've seen arguments here that paying US$100 for a copy of the standard is too much to pay. The only conclusion to be drawn from this is that there is NO value in such a standard in the manufacturing automation industry. Some people may claim that they want such a thing but if they are unwilling to open the pocketbook and buy it then there isn't much of a need after all. > Tell me what the market is, and I am sure that some smart > entrepenuer will pursue it, if it is economical. Exactly. Regards, Ralph Mackiewicz SISCO, Inc.
 
C

Curt Wuollet

Lynn Linse wrote: > > -----Original Message----- > > From: Curt Wuollet [mailto:[email protected]] > > > > <CLIP> > > 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. > > Well, I'm not too worried about it. I know you're not too worried about it, you stand to profit from it. > The big BIG difference between the "Old" Bus-wars and anything which happens > on Ethernet is that there is a huge cost associated with - for example - > ripping out a proprietary media to put in Profibus or DeviceNet or ???. > > What's the cost of "change" once the Ethernet is CORRECTLY in place - best > case a reflash, worst case a change of devices/vendors. > > Plus since Ethernet allows more than one protocol at once, there is nothing > stopping me from making a "linking-device" which has Siemens AS-511 on the > serial side and Modbus/TCP, Ethernet/IP, and ProfiNet on the Ethernet side > (plus I can still tunnel raw AS-511 for remote Step5 access). No, and as long as it's stuff that generic bridges, switches, routers, and stacks understand, I think it's a good idea. Once it requires specialty items, it will be expensive, proprietary, and not remarkably better than all the other proprietary stuff. To the rest of the world, Ethernet doesn't mean cat5 wire or RG58 Coax. It means commodity switches, routers and cards and network management with tools that are used to manage the rest of your Ethernet lans. What have you gained if it's just the same proprietary protocols running on the same wire as Ethernet uses. Ethernet, in common usage includes TCP/IP and the economies of scale that adoption on a huge scale has enabled. This is different from simply moving the Tower of Babel onto a different color wire. You know this, you have championed Modbus/TCP for most of the same reasons. Where did we diverge? > But also remember that a $24 Commercial Ethernet device will not pass the > Industrial version of the CE mark (or FM or UL or ...). Sure, it's a nice > pipe-dream that cheap Ethernet will come to industry, but just ask any > product designer trying to get 2000v isolation parts or Ethernet NIC or PHY > chips which support -40 DegC how "cheap" Ethernet really is. Good point as far as it goes. Applying those specifications would also remove anything that runs on a PC from any industrial application. Yet somehow we manage with commercial 0-70C rating equipment for most applications. 10BaseT ethernet is magnetically coupled, as I recall. I'll bet you a whole pot of coffee that I can find better transformers a whole lot cheaper than you can provide low volume, proprietary, single-sourced industrial silicon. The solutions are out there, IF someone is serious about keeping Industrial Ethernet a commodity. It's not a pipe dream, I'm pretty sure even I could do it. I see the financial reasons for decommoditizing it. I'm not buying the technical reasons as an excuse. They should be a bit more careful who they try to float this stuff by, that only works with management. I do this stuff for a living. That's not saying that there aren't more plausible reasons than these. > You'll find that if your control device can live out it's life in the IT > "clean room", Ethernet is dirt cheap. Mine runs well all over auto parts rebuilding facilities. I wouldn't bring my white bunny suit if I were you. Hot, dirty, occasionally mangled, it does fully as well as the DeviceNet I have installed. > If it needs to vibrate or see the sun or weather or be hosed down, it won't > be so cheap. Likely cheaper than proprietary media, but not that much. You can run regular Ethernet over teflon or MI hardline. The cable industry would be out of business if cheap, rugged, outdoor coax weren't available. Fiber is even tougher and with commodity terminations is still cheaper than what we're gonna be stuck with. That's exactly the case for using what is already a commodity. No offense, Lynn, but I follow the IE list and I see where it's going. Regards cww Just an old electronics guy and Linux hacker.
 
S

Sergey Sorokin

> > -----Original Message----- > > From: Curt Wuollet [mailto:[email protected]] > > > > <CLIP> > > 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. I believe, that different people keep different things in mind talking about Ethernet. But, as I remember, originally (as Xerox's specs and then as scope of IEEE 802 committee) Ethernet standards describe only Physical and Data link layers (in terms of OSI model) and have nothing about higher level protocols like IPX, TCP/IP, etc. Such higher level protocols can work not only above Ethernet but also above RS-232/RS-485 based standards and others. Even for these two Ethernet layers there are many variations in media (coax, twisted pair, fiber, radio), speed (10, 100, 1000 mb/s, etc) and even in Ethernet frame structure. All these variations differ in cost and are not always compatible. Anyway, if somebody use Ethernet specs I think he can use Ethernet good name as well. Obviously Ethernet+TCP/IP is the most widely used combination for networking and many people understand Ethernet as synonym for the whole networking infrastructure including all related software, protocols and hardware. In consideration of using Ethernet for industrial control and factory automation some questions arise both to Ethernet itself and to protocols used above it. Main reason for such questions is that Ethernet and TCP/IP have been developed primarily for general purpose computing without taking into account special real-time or environment constrains. Below are only few of questions: 1) How reliable standard Ethernet works under harsh environment? (how reliable ordinary RJ-45 connector works under high vibration and does it work in wide temperature range? How reliable are communications through standard Cat5 cable under high electromagnetic noise, wide temperature range, etc?) 2) If I like to use Ethernet for smart sensors, is there any standard way to supply power to this sensor using the same Ethernet cable? How much cost to get IP66 protection level for my Ethernet connections? Is there any standardized connector to do that? etc. 3) How deterministic is media access algorithm of Ethernet? Because of collision nature of media access protocol there is nonzero probability that particular frame will not reach destination in reasonable time. Is it OK if your system controls nuclear reactor? 4) Does protocol supports prioritization to separate real-time data and nonreal-time data? Does protocol support "useful lifetime" parameter for real-time data? For example for standard file transfer oriented TCP protocol it is important to deliver any single packet of data. But it is not necessary for real-time data. For example If I failed to deliver temperature measure to the host controller it could be more important for me to try to send freshest measure instead of attempting to push through network old one. 5) Is there any standard way to get redundant Ethernet network with reconfiguration time suitable for hard real-time systems? I do not believe that clear answers exist for all such questions and for all applications. There is working group in IEEE do define standard for supplying power through signal cable (thanks to IP-telephony). QoS (Quality of Service) standards emerged providing possibility to define message priorities (thanks to multimedia industry). There are some proposals for special connectors (for example DB-9 from Siemens or IP67 RJ-45 from Woodhead) and special cable shielding and armoring. Star topology and new switching technologies allow to built up networks without collisions on physical media at all. Some protocols appeared which use standard TCP for guarantied data delivery, and additional level above UDP for real-time data. There are some approaches to provide network redundancy (from Hirschmann for example). Etc. In other words it is not so simple just to transfer networking solutions from office to the factory floor and get them perfectly working. As for high level protocols, I think that it is quite naturally for big vendors just to encapsulate their proprietary or open fieldbus protocols to TCP/IP stack as a first step in adoption of new technology. It allows them to keep bridging devices as simple as possible and allow them (and end users) move along smooth path to the future without immediate canceling all past R&D efforts and without ignoring already installed base of hardware and software. I do not think that there is any global conspiracy of big vendors to keep everything proprietary and to get by such unfair way some extra money from poor customers' pockets. Many of such vendors realize necessity to have really open interoperable standard(s) for what they call Industrial Ethernet and I agree that only publicly available standards can succeed on this way. One of the existing solution can become "de facto" standard or it can be someone's brilliant idea. In the last case such idea should be supported at least by one of major industry leader to be successful. For example, European Industrial Ethernet end user community (IAONA) supports group of European vendors (including Schneider and Phoenix Contact) in developing open protocol for Industrial Ethernet. Specs of this protocol should be publicly available this spring. So, things are not so bad and at least some big vendors invest in developing open solutions planned to be available freely in Internet. Best regards, Sergey
 
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
>> 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

Ralph Mackiewicz

> I believe, that different people keep different things in mind talking > about Ethernet. But, as I remember, originally (as Xerox's specs and > then as scope of IEEE 802 committee) Ethernet standards describe only > Physical and Data link layers (in terms of OSI model) and have nothing > about higher level protocols like IPX, TCP/IP, etc. Such higher level > protocols can work not only above Ethernet but also above > RS-232/RS-485 based standards and others. Your memory is perfect. However: higher level protocols may or may not be able to run interchangeably over RS232 or Ethernet without a mapping layer. RS232 is only a physical layer standard. Ethernet is physical and data link. > 3) How deterministic is media access algorithm of Ethernet? Because of > collision nature of media access protocol there is nonzero probability > that particular frame will not reach destination in reasonable time. A nonzero probability is not the problem. The probability of Ethernet failing to resolve access in 4 consecutive collisions is in the range of the bit error rate for copper wiring. Yes this is non-zero but it is such a small number and the amount of time that it takes to resolve a collision is so small that this is not a significant problem for industrial automation. In fact, Ethernet will outperform deterministic systems in most situations with more than a few nodes because they avoid the time consuming process of rotating tokens like deterministic systems. Performance combined with all the numerous other advantages of Ethernet in cost, availability, connectivity, etc. makes the probabilistic aspect mostly irrelevant. > Is it OK if your system controls nuclear reactor? No, because Ethernet products probably have not been certified for use in this narrow application niche by regulatory agencies. More importantly though: I don't think that this is the criteria that you want to set for use of Ethernet in industrial automation. Most of the technology that is approved for use in nuclear reactor controls is terribly out of date, expensive, bulky, difficult to use, etc. It would not be wise to depend on suitability for nuclear power reactor controls as a criteria for what is useful for industrial automation. > 4) Does protocol supports prioritization to separate real-time data > and nonreal-time data? Does protocol support "useful lifetime" > parameter for real-time data? For example for standard file transfer > oriented TCP protocol it is important to deliver any single packet of > data. But it is not necessary for real-time data. For example If I > failed to deliver temperature measure to the host controller it could > be more important for me to try to send freshest measure instead of > attempting to push through network old one. These quality of service (QOS) issues are primarily addressed in the network layer in routers. If you use routers to interconnect real- time segments with non-real-time segments you can acheive many of these kind of QOS functions without impacting application protocols (not sure about the lifetime issue though). There are big technical problems with building an application protocol that can effectively address QOS issues in an multiprotocol environment like industrial automation. > 5) Is there any standard way to get redundant Ethernet network with > reconfiguration time suitable for hard real-time systems? There are numerous ways to get redundancy using Ethernet. There may not be any "standards" for it, but there are products available to facilitate this and several approaches that work depending on exactly what you mean by "redundant". > I do not believe that clear answers exist for all such questions and > for all applications. Yes, but enough answers exist to make Ethernet the best choice for the vast majority of IA applications. > In other words it is not so simple just to transfer networking > solutions from office to the factory floor and get them perfectly > working. Neither is it simple to use solutions designed specifically for IA and get them running perfectly. Perfection may be a goal but can't be realistically achieved. All engineering is balance of tradeoffs. If you aren't making tradeoffs you are paying too much for whatever you are buying. Regards, Ralph Mackiewicz SISCO, Inc.
 
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 -
 
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
 
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
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
 
> ---------- Forwarded message ---------- > From: BKR <[email protected]> > > 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. ... My prediction is a year from now (errr ... or maybe 2) every serious "Industrial Ethernet" product will come with 2 ports - after you've paid to engineer the first one (SW & HW), the second is little more than silicon. And with the new VLAN function between routers allowing band-width guarantees for VIP sub-nets, this does NOT mean one needs to fully duplicate the infrastructure from top to bottom. Most often it may mean just two UTP cables to a fault-tolerant "infra-structure device" which uses fault-tolerant fiber rings. I won't call it a switch or router as it's really a new breed of device. For deeper nesting, you would just use 2 switches in parallel to get to this "new device". This would allow treating one port as "real-time" to a limited network with only well-behaved programs putting out well-defined traffic. The OS should actually help enforce this limited traffic. On such a net the 100M is more than enough for small control packets & the efficient new producer/consumer paradigms. On this network you could define on paper the load and performance you WILL see. The second port is your free-for-all Ethernet with the web servers, UPnP (plug-n-play resource "polling"/discovery), ARP storms, OPC access, engineering/programming access and other unpredictable traffic. I am always amazed how people WORRY about the load 100 x 70 bytes control messages per second will place on the network, then ask to put megabytes of JAVA and web pages into every node to boot! That's like paying top dollar for professional guards for one of your airport gates, then staffing the rest of the gates with party-boys & free beer & pizza. Totally defeats the purpose! Viewing one web page may equal the control traffic seen in 5 minutes (or even hours!). This duality *MUST* be enforced by the OS - not like now where NT tends to broadcast & chatter out all attached networks. The OS must understand & treat the 2 as 'different'. So if the RT network goes down, the free-for-all apps lose out (OS yanks their net access) and the 2nd now-acting-as-backup net is absconded for RT usage. Of course it will NOT be as good as before, but likely some low-level cooperation between VLAN and OS will evolve to readjust the traffic. The OS could possible even swap IP (MACs?) of the 2 cards - or the VLAN could do something much the same at "the device". (Hopefully Microsoft is listening!) Of course this also means some form of gateway, bridge, or router must link the 2 nets - however this has to be a better-breed of routers than we have now. ARP storms and other "bad but legal" loads must be kept out of the RT network. Both Lexmark and HP are known to have Windows printer drivers which (in a plug-n-play fashion) will ARP the full sub-net (even if Class B or larger) every N minutes or so trying to find a lost printer. by itself this is not bad - but users are NOT EVEN aware of this behavior so do not take it into account when the plant floor networks keep going down. Things like new hardware or "token-bus" Ethernet (as used by some DCS) just create problems as they only work if ALL devices agree to the added-rules (read that as proprietary). I've also seen site problems where users were (in their opinion) fooled into think the new, expensive Ethernet used by the DCS would be a common utility with many functions - only to learn the hard way that "No, only our products are PERMITTED on those 2 Ethernet or you void your warrantee & we pull support ...". So the expensive satellite and fiber links to remote sites does NOT mean the field techs on-site can use browser technology to search documentation archives back at HQ etc. Just my hopes and predictions: Best 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
 
Top