The fieldbus of the future

A

Armin Steinhoff

(Originally posted Mon 10/26/1998) A PROFIBUS working group is already active for the design and standardization of PROFIBUS on ETHERNET. I’m not sure ... but I expect that they will introduce a token passing protocol instead of using TCP/IP.
Regards
Armin Steinhoff
http://www.steinhoff.de
 
A

Armin Steinhoff

(Originally posted Mon 10/26/1998)
>I just returned from the ISA Houston show, the big hit of the show was
the “Super Bus” or IEEE 1451,<

IEEE1451 is a family of draft standards since several years and does not define a “Super Bus”.
It is a “distributed model for field devices” which can be used for different types of networks.

>HP was showing a system running on off the shelf Ethernet that had the
ability to Syncronise the
NCAP’s (Network Capable Application Processors) to within 200 nano
seconds, not a miss print 200ns<

Impressive .... what was the network extension ?
Regards
Armin Steinhoff
 
P
(Originally posted Mon 10/26/1998) I find the 200ns time synchronisation on by HP on Ethernet very interesting as this time represents two bits on the original Ethernet and about 200 feet of cable on any network. Thus, to synchronise to this accuracy means adding in time at the moment of sending (to avoid the collision delays) and clocking this time at the moment of receipt as well as cable propagation delay correction. Or did I miss something?
If one wants to synchronise to this level or better one can also use GPS receivers.
 
R

Randy Sweeney

(Originally posted Mon 10/26/1998) if ProfiBus (read Siemens) chooses Token Ring (read dead technology) then
they will die
When will we learn that commercial technology has zoomed past us like we were standing still.
A superior commercial technology doubling every 14 months will eclipse anything optimized that we can generate in 14 years... this is unstopable... pure non-linear math.
I can not believe that Siemens will be so stupid as to oppose the inevitable...
Ethernet is and will remain the future until it is replaced by something else which will NOT come from factory automation.
Randy Sweeney
Philip Morris R&D
 
(Originally posted Tue 10/27/1998) The big remaining percentage 46% for North America and 61% for Outside North America represent what kinds of control networks? Digital I/O or each company has its own protocol ?
 
A

Armin Steinhoff

(Originally posted Tue 10/27/1998) At 22:16 26.10.98 -0500, you wrote:
>if ProfiBus (read Siemens) chooses Token Ring<

Sorry ... PROFIBUS is not a property of Siemens ! I don’t know why the PROFIBUS should use Token Ring ?? PROFIBUS is based on a hybrid Token BUS protocol .....
[clip ... ]
>I can not believe that Siemens will be so stupid as to oppose the
inevitable... Ethernet is and will remain the future until it is replaced
by something
else which will NOT come from factory automation.<

I can’t speak for Siemens ... but the PROFIBUS will run in a short time frame on ETHERNET !
Regards
Armin Steinhoff
http://www.steinhoff.de
 
(Originally posted Tue 10/27/1998) I suspect what is really represented there is 54% of the respondents were inside North America and 39% were outside North America. The other 7% would then be none of the above and rounding error.
But I probably should wait and see what Doug Smith’s (no relation) response is.
Rufus
 
A

Andy Piereder

(Originally posted Tue 10/27/1998) It is a mistake to say that a technology is dead. I think what you really mean is that token ring is obselete in terms of office LAN. In terms of industrial networks, token ring has advantages for determinism that are not easily overshadowed by other approaches.
New technologies rarely supplant older technologies completely, but rather provide a better solution in some cases, increasing the number of potential solutions for any given problem. The impression that an older technology is dead is usually the result of older technology being used problematically because no other alternative exists. The problems created at the limits of a technology’s application is the impetus for the development of alternate solutions. Realistically, the new solution also has its limitations, and rarely if ever do those limits every coincide perfectly with the old technology.
Andy Piereder
Pinnacle Automation
 
R

Ralph Mackiewicz

(Originally posted Thu 10/29/1998)
>I have wondered about the merits of Ethernet used for an industrial network. It’s fast, and studies have shown that it is deterministic at low load conditions.<

Ethernet is not “deterministic” at any load condition. It is by design probabilistic. The real issue is performance. For many many applications Ethernet provides suitable performance even at higher load levels. The probabilistic nature is drowned out by the performance.

> I think that using ethernet TCP/IP for industrial controls has several problems. First, the media and connectors are not industrial grade. <

This is true in some respect as far as the connectors go, although this is also one of the reasons that Ethernet does not cost so much. The media itself is twisted pair wiring and you can get this cable with a variety of jackets on it for many different application requirements. I think that there are also companies that sell ruggedized Ethernet (Siemens for one). But then there is that nasty cost issue again.

> Second, more is required to carry out control than just ethernet TCP/IP. A communication standard needs to be developed to allow standard plug play components<

Yes. Very true. If everyone understood this, there would be fewer incompatible proprietary protocols and more open standards based protocols.

> With the vast expansion of internet use, I could forsee bandwidth problems for future expansion of internet audio and video. All internet communications are point to point transmissions. This is grossly inefficient on a large scale when there are users that want the same data all over the world. Take for instance downloading of Netscape; a 17MB file that took me over 3 hours to download. Netscape has lots of servers that are occasionally overloaded in part because they are repeating 17 MB downloads to individual IP addresses (Millions of downloads). Imagine if a producer consumer network was created such that every 30 minutes on a regular basis, a new download of Netscape was sent over the Internet (if there were) any outstanding requests. Faster downloads, lots of money saved on servers for Netscape (and any significant download participant). Cost of internet services would decrease, services would increase. Imagine setting up a “Movie” server in your basement that services the world. Don’t need massive high powered servers, just a high end box from Best Buy, video spigot, and a VCR. Not a bazillion point to point downloads, just one at a time. Subscribers would have a key to tap into the transimission. <

This is an interesting scenario but it won’t work for this particular application because your particular situation of waiting 3 hours for a download is not an inherent flaw in the system. It is with your Internet connection. I wouldn’t want to wait 30 minutes to get Netscape. Using my connection at home it took me less than 5 minutes to get Netscape Communicator as I recall (I have a cable modem hookup to the network). The answer to this particular problem is bandwidth. However, there are Internet technologies being developed that will support an architecture very similar to what you are describing. Its called “push” technology. Some of the variants involve multi-casting data to multiple sources simultaneously.
Also, the approach you describe will push the cost of supporting millions of downloads from Netscape to the network providers. Given that I pay for part of the network, I would rather see Netscape take the hit than me.

> My personal opinion is that these benefits that are in industrial networks will migrate (in the long run) to lare scale systems and not the other way around. Using eithernet for industrial control in my mind is like finding a way to make dump trucks cheap, nimble and fuel efficient. You still might not buy one for normal personal use even if it had better “Specs” than an economy car. Its just not designed for that. <

I don’t see many of the technologies specific to the industrial world making it to the big time of computer networking. Lets face it: what we do in the real-time/control area is a niche. The requirements that drove the development of DeviceNet, Foundation Fieldbus, Profibus, MMS, etc. don’t exist in the world of banking, insurance, home entertainment, etc. However, there are some technologies of these other systems that can be applied effectively into our niche. This has been proven countless times (e.g. Ethernet, PCs, Windows, etc.) It doesn’t matter how cheap dump trucks become. Hardly anyone has a need to own one. The requirements for a dump truck are radically different than the requirements for a passenger car. The cost of a dump truck is an effect of that difference, not the cause of the difference. Or, in other words, the cost of a dump truck is not the primary reason to buy a passenger car. Using Ethernet for industrial control is different. There are numerous applications where the particular characteristics of Ethernet can be used to build cost-effective real-time control systems.
Best Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R

Ralph Mackiewicz

(Originally posted Thu 10/29/1998)
>I have a question for you. I think that USB (Universal Serial Bus)
or something like that, will be the fieldbus for the future. It is
based on an open platform (the PC) that any one can provide products
for it. This, joined to softwars standards like OPC and CORBA, will
answer all our questions about industrial automation, due to the
highest degree of openness that could be reached (for now on).
Does any one agree with me?<

Not me. USB is no more likely to be adopted as a fieldbus than RS-232 or RS-485. It lacks application protocol standardization. RS-485 was not a suitable fieldbus until Profibus added the FDL, DP and FMS standards to run on top of it. CAN wasn’t suitable until ODVA added DeviceNet protocols and so on. From what I can tell, the only protocols standardized by USB are for media applications and some low-level stuff to allow automatic matching of peripherals to the required drivers in the host system.
There are also numerous physical limitations of USB that make it unsuitable for fieldbus applications several of which have been previously posted to this list.
USB is an excellent system for integrated peripherals on desktop computers. It looks pretty poor for a fieldbus.

>I agree with you. I work for a large integrator,
...snip...snip... open object standards and web-based technologies
allow us to reduce programming by more than 60% and eliminate the
SCADA middleware like Wonderware, Intellution, Factory Link, etc.
Using a regular web-browser and JavaBeans the SCADA level is
practically free (and way more connective).

AND:
What are the requirements for a fieldbus:
...snip...snip...
3) Interface cost less than US$1.00?<

A dollar? Why should anyone have to pay a buck for an interface? The ideal fieldbus should require no installation, no prior knowledge, no configuration, no intelligence to operate and should be included free of charge with all instruments, computers and software applications. Come to think of it, let’s make the instruments, computers and software applications free too! ;-)

Regards,
Ralph Mackiewicz
SISCO

Quote of the Day: “Connectivity alone is not enough for
interoperability. Application protocols are needed too.”—Me
 
(Originally posted Fri 10/30/1998)
>>I have wondered about the merits of Ethernet used for an
industrial network. It’s fast, and studies have shown that it is
deterministic at low load conditions.<<

>Ethernet is not “deterministic” at any load condition. It is by
design probabilistic. The real issue is performance. For many many
applications Ethernet provides suitable performance even at higher
load levels. The probabilistic nature is drowned out by the
performance. ...<clip><

I believe there are many ethernet based networks in the so-called “Rugged industrial LAN” arena; some have been working for several years.
FDDI is the TCP/IP backbone technology that I understand will give you determinism. But when you get off FDDI to Ethernet it becomes nondeterministic. Dual redundant networks can now be offered with off-the-shelf hard and software, and I think you will find many network solutions companies which have cut their teeth in the IT area willing to apply their expertise to the so-called industrial process control areas.
 
M
(Originally posted Fri 10/30/1998) The other new PC-based bus with potential for control is Firewire or IEEE1394. One company, ORMEC, is taking a stab at using Firewire for motion control—see the story at http://www.ormec.com/mktdocs/servwire.htm.
This thread raises an opportunity to discuss development issues and impediments toward use of any PC-based technology for network control. What do list members consider to be the major developmental stumbling blocks?
For example, does a new connector need to be invented before 100base Ethernet can survive as a control network?
Does a software house (like Softing) need to develop and offer protocol stacks for each candidate interconnect?
It would be fun to compile a list of impediments. Please contribute, and
thanks
Murry
 
C

C. Thomas Wiesen

(Originally posted Fri 10/30/1998) Robustness of operating systems for Intel platforms
Control software for intel platforms (Robust, modular, convertible, standard(?)
Guarantee of non obsolescence of operating systems and control software for 10-20 years (Like PLCs).
I don’t want to have to upgrade my machine controls (Hardware, software, operating system) just because there was a different reason to upgrade my desktop. Scenario: 10 years down the road the hard drive crashes on my PC based machine. Original control software is long since lost. Control software vendor no longer has old version of Control software to E-Mail me but would be happy to E-mail me the newest version for a big fee. I get the new software but it requires the newest operating system (for a small fee). A replacement hard drive cannot be found for this 10 year old PC and since the motherboard cannot support the newest operating system, I have to get an entirely new PC (for a moderate fee). Now with the new PC, operating system, and control software, will the 10 year old program be able to be run on the new control software? Even if it does, how long is my machine down? PCs are to PLCs like dog years compared to human’s. I have already found this glitch. 6 year old PCs running test stands had to have monitor replaced because the once $100 CGA board, now dead, could not be replaced; had to replace the monitor and add VGA board. I don’t remember but I think that programming had to be done to get the screen looking the same.
I believe that PCs are good when a great deal of functionality is required. Extensive HMI, on line help, massive diagnostics, very high I/O count, number crunching of data, data transfer, etc. For simple systems, PLCs fit the KISS principal and probably have a lower overall ownership cost.

>For example, does a new connector need to be invented before 100base
Ethernet can survive as a control network?<

Uhhhhh... YES. Having lots of different connectors adds cost. So connectors chosen need to cover the spectrum of all uses (in panel to wash down, to high temp)

>Does a software house (like Softing) need to develop and offer protocol
stacks for each candidate interconnect?<

A protocol standard and device profiles need to be developed. Sounds like other field busses are trying to migrate existing standards to ethernet. That will be interesting to se how that evolves.

Good questions.
 
(Originally posted Mon 11/02/1998) I think the fieldbus of the future will be based on human factors as much as technical ones. The busy engineer has not time to research all the myriad fieldbuses out there, and will latch on to those that have highest profile. This profile will be a combination of perceived openness and acceptance by others. After that, technical issues will be examined.
 
R

Ralph Mackiewicz

(Originally posted Mon 11/02/1998)
>I believe there are many ethernet based networks in the so-called
“Rugged industrial LAN” arena; some have been working for several years.

FDDI is the TCP/IP backbone technology that I understand will give you
determinism. But when you get off FDDI to Ethernet it becomes
deterministic.<

FDDI is a 100mb/s fiber technology that uses a token passing scheme to acheive determinism. Bridging FDDI to Ethernet will not make Ethernet deterministic. Ethernet is still probabilistic. The issue that pertains to industrial applications is that Ethernet’s performance is so high that its probabilistic nature is completely irrelevant for most applications.

>Dual redundant networks can now be offered with
off-the-shelf hard and software, and I think you will find many network
solutions companies which have cut their teeth in the IT area willing to
apply their expertise to the so-called industrial process control areas.<

This may be true, but some caution is needed. Putting together a network in a mainstream IT environment is considerably different from doing this on the plant floor due to so many factors that I could not possibly list them all in a single post. The technologies used may be the same but the applications are very different. You need to have an understanding of both to be effective.
Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R

Ralph Mackiewicz

(Originally posted Mon 11/02/1998)
>This thread raises an opportunity to discuss development issues and
impediments toward use of any PC-based technology for network control. What
do list members consider to be the major developmental stumbling blocks?
...snip...
It would be fun to compile a list of impediments. Please contribute, and
thanks<

It would be interesting and useful to know this certainly. Knowing these tradeoffs is critical to being able to use this technology.
Connectors come to my mind as it pertains to Ethernet. Standard Ethernet connectors must be well protected.
But, if we answer these questions from the perspective of control and automation, we’ll probably end up with a description for something like FF, Profibus, DeviceNet, ASI, etc., not Ethernet and the Internet. By letting a mass market (driven by the demand of many millions of nodes per year) answer these questions instead we get a very low cost high performance network. There will be tradeoffs in the use of a technology developed for this mass market for industrial applications. But aren’t the tradeoffs necessary?
Regards,
Ralph Mackiewicz
SISCO, Inc.
 
T

Thomas Wuensche

(Originally posted Mon 11/02/1998) If you look at CAN (the base for DeviceNet and CANopen), you have the best of both worlds. Developed for automotive applications, CAN is rugged and reliable enough for industrial applications and still has the benefits of a system used in many million nodes a year. The price of a CAN controller integrated within a microcontroller is below US-$ 1,00, and CAN controllers are available as on-chip peripheral from 8-bit controllers up to 32-bit RISC machines.
Furthermore CAN can be used either with a range of connectors or as pure wire fixed in screw terminals - choose what your application needs. Would you want to do that with Ethernet?
Best regards,

Thomas Wuensche
 
(Originally posted Tue 11/03/1998) Yes, I agree that the received wisdom appears to be that you don’t mix an IT LAN with an industrial LAN, which I think is what you mean. Gurus and consultants all carry the same message - keep them separate. (see article in the US magazine “Control of the Process” Feb 1998 by Caro and Mullen entitled “Ethernet as a control network”). This means that a new niche is opening up in the industry. Some LAN system designers/suppliers are now offering their services for the so-called “Robust Process LAN”. This is a LAN separate from the IT LAN, but bridged into it to allow certain authorised traffic.
 
A

Andy Piereder

(Originally posted Thu 11/05/1998) I had to chuckle when I read the subject line. Shouldn’t we concentrate on a fieldbus of the present? While fieldbuses have made good inroads into automation, I find that most of the system integrators and end-users I talk to are oblivious, some dimly aware and all leary of this ‘new-fangled’ technology.
Before we start worrying about the technical what’s next, we should insure that we have a market for ‘what’s next’....
Andy P.
 
Top