ProfiNet or ProfiNot

R

Ralph Mackiewicz

> > So you too wonder about why things are done the way they are in the
> > world of controls. So do I.
>
> Of course no major manufacturer actualy WANTS an open protocol that
> will allow small vendors to tap into their user base, or lay
> themselves open to competion. It is the customers responsibility to
> INSIST on openess for thier own protection.

Yes EXACTLY. There is a lot of hand-wringing about all the proprietary stuff used in IA but it is mostly misdirected. Customers buy all that proprietary stuff. That is why it exists.

> In IA communications products tend to have a very high degree of
> conformance to one of the plethoria of 'standards' out there.

In the words of Bob Metcalfe, co-inventor of Ethernet: "Standards are great. Everyone should have one of their own." He was being sarcastic.

> Unfortunately that does not assure interoperability as standards fall
> short of defing every element required in a connection, there is
> always space to make a conformant device not interoperate with another
> conformant device, often in a conformant manner!

Such interoperability issues are inevitable in ANY standard. We are all human beings and it is not possible to define a *useful* comm standard (if the standard is too rigid it becomes too narrow in its scope...flexibility brings choices) that does not provide some choices to the developer. Not being conspiratorial in nature, and
based on long experience implementing public communications standards, anytime there are choices each developer will likely make different choices. Not to purposely foil interoperability, but due to simple human frailty.

> Also, while manufacturers are quick to stick standards labels on their
> products, technical support frequently refuse to help resolve problems
> in a system where an alternative (compliant) product has been used for
> some element in place of their own product. i.e. Connect foo
> engineerings PLC to foo engineerings DP encoder with baa engineerings
> capable, when things do not work (even if there is no sign of comms
> problems) the first thing they suggest is to replace baa engineerings
> cable with thier own.

This is a shame but it is not universal. You shouldn't put all 'manufacturers' in the same bag. My company has worked with numerous customers in working through interoperability issues that resulted in identifying bugs in our competitors product as well as our own. We have even made changes in our product to interoperate in spite of other people's bugs. If you are committed to standards dealing with
interoperability is a simple fact of life. Those manufacturers that you have this problem with are not committed to standards. Probably because most of their customer base is perfectly satisfied with a proprietary approach.

> That is why many people regard the only real open systems to be open
> source ones. It is the only way that eventual problems can be
> identified and rectified.

Its not the only way, it is one way. You can also have a committed vendor. You can also buy product source code in some cases (albeit not "open source").

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
A
> The mistake that is holding back fieldbus nodes is to start with
> proprietary single sourced silicon and proprietary protocols
> where the IP licensing costs more than the device itself. When you look at
> the cost of all the leaches, it is impractical to embed a network stack in
devices. Yet no
> one so far has realized that the economics of Open Source and
> commodity Ethernet silicon are about the only way to open the
> floodgates and move things forward.
> It is hilariously ironic that the thing that is holding back massive
> fieldbus deployment is their own anal attitude that they must own or
> control everything.
> The market is so badly fragmented by these control freaks that new
> additions are doomed before they start simply because they
> won't use what
> is established, cheap, and ubiquitous. Greed is it's own
> reward when you reinvent the world.

They do have one point though. TCP/IP over Ethernet isn't always fast enough. Usually...

> If I can buy $9.00 Ethernet cards, no proprietary scheme is ever going
> to achieve the volumes to be competitive.

Oh, I agree, but I wouldn't even use Linux if I'm trying to get cheap IO. You could make a system with an ARM processor running ucLinux (or something) off of some flash. People have already got that though. I was at the embedded systems conference in SF last month, and while there was a hell of a lot of Linux folks, there were just as many folks adding TCP/IP stacks to
their already cheap hardware.

For an example: Check out www.zworld.com and look at their RabbitCore series. You could make a TCP/IP IO module with 34 IO lines, and the most
expensive unit is $89 for a quantity of 1! That's less then $3 a point for hardware costs (not counting the cost of packaging the devices or any margin). Sure, I have to use their special C as opposed to writing Linux, but if you want to use cheap hardware to make a cheap TCP/IP IO device, even Linux is too fat.

Of course, you have to spend $279 for the development kit, but that's quite reasonable, as I think even you would admit. :)
 
C
Hi Alex

Alex Pavloff wrote:

> > The mistake that is holding back fieldbus nodes is to start with
> > proprietary single sourced silicon and proprietary protocols
> > where the IP licensing costs more than the device itself. When you look at
> > the cost of all the leaches, it is impractical to embed a network stack in
> > devices. Yet no
> > one so far has realized that the economics of Open Source and
> > commodity Ethernet silicon are about the only way to open the
> > floodgates and move things forward.
> > It is hilariously ironic that the thing that is holding back massive
> > fieldbus deployment is their own anal attitude that they must own or
> > control everything.
> > The market is so badly fragmented by these control freaks that new
> > additions are doomed before they start simply because they
> > won't use what
> > is established, cheap, and ubiquitous. Greed is it's own
> > reward when you reinvent the world.
>
> They do have one point though. TCP/IP over Ethernet isn't always fast enough. Usually...
>
> > If I can buy $9.00 Ethernet cards, no proprietary scheme is ever going
> > to achieve the volumes to be competitive.
>
> Oh, I agree, but I wouldn't even use Linux if I'm trying to get cheap IO.
> You could make a system with an ARM processor running ucLinux (or something)
> off of some flash. People have already got that though. I was at the
> embedded systems conference in SF last month, and while there was a hell of
> a lot of Linux folks, there were just as many folks adding TCP/IP stacks to
> their already cheap hardware.
>
> For an example: Check out www.zworld.com and look at their RabbitCore
> series. You could make a TCP/IP IO module with 34 IO lines, and the most
> expensive unit is $89 for a quantity of 1! That's less then $3 a point for
> hardware costs (not counting the cost of packaging the devices or any
> margin). Sure, I have to use their special C as opposed to writing Linux,
> but if you want to use cheap hardware to make a cheap TCP/IP IO device, even
> Linux is too fat.

There's a couple of ways to look at it. First, I personally am not interested in the proprietary offerings as I intend to release the hardware design and software to the LPLC project and the public for free under the GPL or equivalent. I agree the rabbit looks like someone in the embedded industry finally got the volume religion and I wish them well. This in any volume would probably be cheaper as the hardware is cheaper. It's not that much cheaper though and with software development under Linux being almost trivial, I would be willing to pay the difference to have Open Source. Sure it's overkill, but it would still be cheaper than buying into any of the "open" industrial clubs and using their silicon and protocols. And it
would be a standalone Linux system. I could run the LPLC code on it and have a "micro" PLC replacement or even distribute tasks to it or let it concentrate data. My justification is that you would get a whole lot more functionality for a few more bucks. Sorta three in one to justify the extra hardware. And you would get the source with every unit.

Regards

cww
 
G
> based on long experience implementing public communications
> standards, anytime there are choices each developer will likely make
> different choices. Not to purposely foil interoperability, but due to
> simple human frailty.

i agree that, when choices are available, different developers make different choices, but i don't ascribe it to human frailty. different
developers have different understandings of the problem set, they operate under different constraints, and answer to powers that judge
them and their efforts using different criteria.

if everyone were supposed to make the same choice, then there would be no need to provide a choice in the first place.

the real trick, as a developer, is to know what choices you're making or providing, what the cost/benefit tradeoffs are, and to make all of those choices and their implications known to the people who need to know.


Greg Goodman
Chiron Consulting
 
C
Hi Roger

I've got an even better idea than that. Contribute the time you'ld spend writing a couple of one-shot definite purpose protos to help us with a truly open, free, publically owned, Ethernet based proto for the LPLC project. Then maybe next time around you could start with a solid framework and make a few trivial adjustments for the application. If enough people do that, it'll cover a lot of ground _and_ be well standardized yet easily extensible at need. We have someone, Ron Gage, that has started just that. Sharing a proto we all own that runs on commodity _or_ specialized hardware is an idea whose time has come. If people would quit bitching about the status quo and help us change it, the benefits expand at an exponential rate. All we need is comitted volunteers. Think about it, how many people does even an AB or Siemens actually have writing networking code? We can do a lot better than that if people really want things to change Waiting for change is pretty hopeless. This is such a limited market that a few committed people can actually put the industry back on track and break the Tower of Babel deadlock.

Regards

cww
 
J
>
> My experience is that I have wasted a lot of time looking at LAN and WAN based industrial protocols, only to find that customers just do not want them. I think they are less naive than us. When you talk about 'standards' and 'interoperability' they just look at you blandly as if you were born yesterday and say "of course things never are compatible in pratice are
> they, why don't you just send a few bytes of data in a UDP packet and stick the format in a .txt file so everyone knows whats in it and can use it". Quite.
>
> Once you have one simple parser written for datagrams/ASCII hex on serial/TCP streams etc, it does not take much effort to modify it to another
> format. And it works. And anyone can use. No drivers to order, no organisations to join...........Anarchy for industrial networking, thats what I say, lets picket the next OPC/fieldbus/thisnet/thatnet AGM......oops I am getting a bit carried away.
>
> Seriously though, this is really what XML is all about, albeit in a slightly more formal container. Anybody who talks about sticking OPC packets in XML, automation data objects et al, should be taken out and shot at dawn.

I entirely agree! I prefaced my first posting with the disclaimer "Let's assume the Industrial Automation industry needs WAN....."

I really don't think the IA industry needs a lot of WAN infrastructure. But, interestingly enough, you mention text based application layers like XML used to create SIMPLE layer 6 and 7 protocols for automation; check this out:

http://www.factoryxml.com
 
C
> Jake Brodsky wrote:
> > Mind you, who should help you de-bug a multi-vendor system?
>
> Nobody. Hell, I have difficulty getting vendors to admit there is a
> problem even with their equipment on all sides of the problem.
>
> I'm in favor of published standards (though it may be a licensed standard)
> because it gives me something to point to besides an idiot light which
> says "comm fail."
>
> > That is why many people regard the only real open systems to be open
> source ones. It is the only way that eventual problems can be identified
> and rectified.

This is a very, very, large benefit. Who hasn't had a project delayed because they had to search for answers or work around problems. I've even ran into dead ends and had to completely change approaches when information or solutions were not forthcoming. The project I'm doing now has flowed much faster and more steadily because I can fix problems as they come up. My stress level has been minimal and everybody's happier.


> Openness has many degrees of freedom. The old DEC VMS operating system
> wasn't "open," but the interfaces were well documented and you could
> obtain a licensed copy of the kernel code for modest cost. As a result it
> enjoyed years of user support that other operating systems couldn't seem
> to attract.
>
> Likewise, we don't need a completely open design with completely open bits
> of code. What we need is a very tight, well defined standard interface.
> The downside is that I see no motive for a large company to do this for
> the control system community. A small company could do this, but they'd
> have to take a very enlightened approach to partnering with other firms.
> I don't see that happening any time soon either.

I think possibly the best thing would be for the existing front runners to be "opened up" enough to enable other companies and even OSS projects to
use them without concern. The standard for "open enough" could easily be measured as the point where the effect is noticeable. I have asked Modicon for example, to grant the Puffin PLC project permission to use the Modbus protocols, particularly Modbus/TCP, in a manner consistant with our OSS goals. Not to abandon all rights or anything drastic like that, but simply to let LPLC use them in the same manner as I can as an individual without the threat of legal action. They have by far the most liberal license I have
seen in this business and are so very close to what we need that it's just language differences and the fact that we aren't a legal entity and so can't enter into agreements that separates us. I would be happy with a letter from an honorable company officer simply stating that they won't come after us. It's obvious that they want Modbus/TCP to become a standard the right way and are making it as easy as possible for others to adopt it. Even if we can't find a way, I still applaud them for trying to do something
that really needs to happen. We would like to reward them by adopting and popularizing the protocol if we can.

> So we're left with efforts such as the Puffin PLC project. I sincerely
> hope they succeed. It would be nice to make the code base a sort of
> standard. It would be nice to have integrators build custom systems that
> others could work on instead of large companies packaging their wares for
> ridiculous mark-ups while hiding as many bugs as possible.

Thank you!

> My point of the previous post was that while Open Source initiatives are a
> means to an end, it's not the only means to that end. Furthermore, we
> still don't know how well the open source iniatives will stand the test of
> time.

We are, however, abundantly familiar with the effects of the status quo. I don't see OSS as very risky in comparison. If people want to use it, it will always be there.and just as viable. How could it be invalidated?.

> Linux itself didn't get much trade rag visibility until three or four
> years ago. It's just now penetrating the mainstream media. While I hope
> it stays there and grows, I still have doubts about its long term mission
> stability. I fear the risk of another fractured standards market as with
> other *IX versions of the past. I hope it never goes that far, but we
> have lots of past experience suggesting that it can.

If it does, it will certainly be a loss for everyone. The GPL goes a long ways to prevent this from happening. The intense pressure for the Linux companies to make money is stressing the community ties. There have been those who thought they could have the benefits without the responsibilities. They are no longer with us. As the user base becomes more general and less idealistic there is the danger that greed and averice will undo what sharing and cooperation have done.

Regards

cww
 
J
> Cool trick.
> Where do you do your wrap/unwrap?
> On another processor?

I designed the SST Profibus line of interface cards (5136-PFB). So I had the advantage of being able to roll a lot of this functionality into the Profibus interface's firmware. The encapsulation took place on the Profibus cards (one on each end).

Jim Stewart
Celerox Digital Solutions
[email protected]
 
A

Armin Steinhoff

>Curt Wuollet wrote:
>Hi Roger
>
>I've got an even better idea than that. Contribute the time you'ld spend
>writing a couple of one-shot definite purpose protos to help us with a
>truly open, free, publically owned, Ethernet based proto for the LPLC
>project.

If you have only soft real-time requirements .... use PVM. It's based on message passing over TCP/IP and is widely used for networked computer clusters. This piece of software is really mature
und is used by many research institutes and industrial sites.

Computer clusters and distributed control systems are from the communication's point of view very similar (or nearly identical).

The PVM library offers blocking and non-blocking send and receive calls, event handling, networkwide synchronisations, message handlers (remote execution) and lots of other useful mechanismn ... and it is an 'open source' tool.

There are implementations for UNIXes, LINUX, QNX 6, Win98/NT a.s.o
( http://www.epm.ornl.gov/pvm/pvm_home.html
http://sourceforge.net/projects/pyqnx )

PVM isn't bound to a transport media ... its transport layer can also be implemented on top of e.g. CAN, LON, PROFIBUS ... that means applications can be moved from a TCP/IP environment to a fieldbus environment without
code changes.

> Then maybe next time around you could start with a solid
>framework and make a few trivial adjustments for the application.
>If enough people do that, it'll cover a lot of ground _and_ be well
>standardized yet easily extensible at need. We have someone,
>Ron Gage, that has started just that. Sharing a proto we all own
>that runs on commodity _or_ specialized hardware is an idea whose
>time has come. If people would quit bitching about the status quo and
>help us change it, the benefits expand at an exponential rate. All we
>need is comitted volunteers. Think about it, how many people does
>even an AB or Siemens actually have writing networking code?

They don't know probably how many mature networking code based on MPI or PVM are already used for distributed systems?

>We can do a lot better than that if people really want things to change
>Waiting for change is pretty hopeless. This is such a limited market
>that a few committed people can actually put the industry back on
>track and break the Tower of Babel deadlock.

Standards at the application layer like MPI, PVM, MPI/RT could be the tools to break the Tower of Babel ... at least a little bit :)

Regards

Armin Steinhoff
 
J

Joe Jansen/ENGR/HQ/KEMET/US

>I really don't think the IA industry needs a lot of WAN infrastructure.
>But, interestingly enough, you mention text based application layers like XML used to create SIMPLE layer 6 and 7 protocols for automation; >check this out:
>
>http://www.factoryxml.com


From the web site:

International patents for FactoryXML are pending.

What, exactly, are they patenting? The use of XML in a factory? Does that mean I have to stop?

--Joe Jansen
 
Top