"Protocol X" to "Protocol Y" converter

  • Thread starter Rob Hulsebos Philips CFT
  • Start date
R

Thread Starter

Rob Hulsebos Philips CFT

Hi,

In this list often a question is asked like "Does anyone know of a protocol converter from X to Y", and the subsequent answers are a list of products that promise to do just that.

Having made a 'simple' Modbus-to-ProfibusFMS converter once, I know such converters stir up more issues than one can believe, such as the translation of commands, replies and errors, different message lengths, different speeds, etc.

I wonder how many people assume that an X-to-Y converter converts everything anytime anyplace anywhere anyhow, but I think that it many cases it is not so simple, and a lot of work is left
to the user's application programs. Or, even worse, many features of the protocols X and Y are not available. The simplest converter I can think of is just a shared memory interface between two
protocol drivers, but I wouldn't call this a protocol-converter.

Anyone's experience with these things is appreciated...

Rob Hulsebos
 
K

Karlheinz Schwarz

Dear Rob and dear reader,

Your statements are great! Many experts and managers make people believe that EVERYBODY can "convert everything anytime anyplace anywhere anyhow". Yes - many can and do develop many gateways. That is a huge market for programmers and system integrators. Why to change this situation? It is good for these companies!

But what's about the users?

Imagine if you didn't have common electric outlets and plugs in your house, and every time you bought a new appliance, choose a new power provider, or installed a new micro-power system like a fuel-cell, you had to wire up the appliance to the wires in your wall. And every-body's wires in everybody's walls were different. And everybody's appliance wiring was different. That's really the way it works today trying to integrate device data into applications and these devices into automation systems.

Utilities spend an ever-increasing amount for real-time information exchange; costs for data integration and maintenance are exploding. Industry experts say: US $82 billion was spent on application integration in 1998 (= 40% of corporate IT budgets; still growing) – Forres-ter, 1999.

The time has come that people realize that Converters, Gateways, and Proxy Server become too expensive ...

What to do?

Only standards (a few - not 20!) can help the industry to overcome this situation. Why should everybodies protocol converted to everybodies (minus one!) protocol! Why not convert to just a few standardized protocols?

The utility industry has understood the benefit of having ONE standard (not a standard protocol only): IEC 61850 and UCA (tm).

By the way, the protocols are one (minor crucial) issue in making systems talking together. The crucial challenge is the understanding of the SEMANTIC carried by the messages of a protocol.

Usually the well known protocols like PROFIBUS FMS and many others do not care about the semantic of the data values they communicate at all. Converters convert the values or control commands coded in one syntax onto the same values or commands in another syntax. How do you know what the values of a network variable mean? Potatos or apples, pressure or temperature - in Fahrenheit or Celsius? Is the value from tank 1 or 27?

There are many aspects to be taken into account when we want to let systems/devices communicate. Coverting protocols is just a minor (but complex and expensive) task. Even converting may not be possible, because both protocols may not have nearly equvialent models/services/parameters: A simple write cannot be mapped to a read!

More protocols to come.

A standard that EVERYBODY should know about: IEC 61850 (Communication networks and systems in substations).

See: http://www.nettedautomation.com/standardization/IEC_TC57/WG10-12/iec61850/61850_on_a_page.html

I look forward seeing more comments on these issues.

Best Regards,
Karlheinz Schwarz
 
L
Fortunately, most devices consist of arrays of integers and bits. Therefore it's only possible to map X to Y for steady-state data access which is 95% of the desire (maybe 99% even).

But with the old serial paradigm, once you make an RS-232 port "Modbus/RTU" instead of Protocol X, you lose the ability to send any Modbus or "X" commands which don't map - kind of the limited intersection of the 2 worlds.

One interesting new feature of TCP/IP is the ability to support multiple protocols at once and allow 100.00% accurate distinction between them.

I have done several custom projects where we offer 2 protocol channels:
1) Modbus/TCP to Protocol X.
2) Raw protocol tunnel of Protocol X.
This allows a standard "Modbus" access to the steady-state data collection, yet fall-back to Protocol X for all the non-mapping functions. In some projects they work together at the same time for a multi-master design (ie: Modbus -> X is interleaved with X -> X). In other projects the only multi-master support is for Modbus/TCP, and the Protocol X is treated as a high-level over-ride. The instant a raw tunneled protocol X socket opens, the Modbus/TCP is shutdown/locked and out until disconnect.

At present I'm gearing up to do some Ethernet/IP in the same manner.

So I'd say we're starting a new era of effective and useful X to Y converters - as long as one side of that equation includes TCP/IP.

Best Regards
Lynn August Linse, [email protected] http://www.linse.org/lynn
3 Rue Monet, Foothill Ranch CA 92610
Ph: 949-300-6337 Fx: 612-677-3253
 
A

Andrew Piereder

My comments interspersed with Lynn's below...

Lynn Linse wrote:
>Rob Hulsebos wrote:
>I wonder how many people assume that an X-to-Y converter converts everything anytime anyplace anywhere anyhow, but I think that it many cases it is not so simple, and a lot of work is left to the user's application programs. Or, even worse, many features of the protocols X and Y are not available. The simplest converter I can think of is just a shared memory interface between two protocol drivers, but I wouldn't call this a protocol-converter.

>Anyone's experience with these things is appreciated...

Fortunately, most devices consist of arrays of integers and bits. Therefore it's only possible to map X to Y for steady-state data access which is 95% of the desire (maybe 99% even).

--AP--
I agree that moving bits and integers is the primary "desire" but where most protocol conversion get out of hand is thinking that this is the end all and be all. I've never used a protocol converter that couldn't do this basic function, but I've seen a lot of units go on the trash heap because of the more subtle gotchas that prove to be fatal to the process.
--

But with the old serial paradigm, once you make an RS-232 port "Modbus/RTU" instead of Protocol X, you lose the ability to send any Modbus or "X" commands which don't map - kind of the limited intersection of the 2 worlds.

One interesting new feature of TCP/IP is the ability to support multiple protocols at once and allow 100.00% accurate distinction between them.

I have done several custom projects where we offer 2 protocol channels:
1) Modbus/TCP to Protocol X.
2) Raw protocol tunnel of Protocol X.
This allows a standard "Modbus" access to the steady-state data collection, yet fall-back to Protocol X for all the non-mapping functions.
In some projects they work together at the same time for a multi-master design (ie: Modbus -> X is interleaved with X -> X). In other projects the
only multi-master support is for Modbus/TCP, and the Protocol X is treated as a high-level over-ride. The instant a raw tunneled protocol X socket opens, the Modbus/TCP is shutdown/locked and out until disconnect.

At present I'm gearing up to do some Ethernet/IP in the same manner.

So I'd say we're starting a new era of effective and useful X to Y converters - as long as one side of that equation includes TCP/IP.

--AP--
It is an interesting and effective approach within its limits--limits usually imposed by the application which is seldom "greenfield". For those "other" situations it seems clear that the protocol converter needs to be more intelligent in its resolution of error-handling, scaling and unbalanced command sets.
 
C

Curt Wuollet

I've been bringing this up for years and even though it's becoming quite a problem, no one in the industry seems much interested in common open standard protocols. That's a shame as only demand from the people who build solutions is likely to change anything. If there was only one protocol that everyone supported, it would be an enormous leap forward. If that proto was suited to data exchange it would be even better. Call it a bridge protocol. I would be interested in which protos would be good candidates. To have an Open one would probably require writing another proto.

Regards

cww
 
C

Chrisstoffer, Herman

You could think of the OPC standard. Which seems to become fairly popular to connect all kind of devices, software tools, etc... to an client (HMI, SCADA, DCS, ...) system. There is also a new standard comming up OPC DX which extends
the OPC Data Access server with an Data eXchange function. This will enable you to exchange data between two OPC servers. Thus exchaning data between two modbus systems, or exchange data between a fieldbus environment and an profibus
environment, etc.. But take in mind that OPC is still more or less tied to the windows operating system. Although there are currently tool kits available to implement OPC clients and servers on other platforms like Linux.

Regards
Herman Chrisstoffer
 
R

Rob Hulsebos Philips CFT

>You could think of the OPC standard. Which seems to become fairly
>popular to connect all kind of devices, software tools, etc... to an
>client (HMI, SCADA, DCS, ...) system.
Although I haven't used OPC myself, I wonder whether it is really so
connectable as you suggest. I guess it runs into the same difficulties as
gateways and other protocol converters.

Let's throw an example. Modbus has several different commands to read data from a slave. I assume that in OPC there is something similar to a Read command as well. How does one translate the OPC_Read into one of all the possible
Modbus_Read commands? (of course, the application may not "hint" the OPC server in order to remain fully independent).

I once built a Modbus / Profibus gateway and ran into many other problems. For example Modbus uses 16 bit addresses for the registers, but Profibus (FMS) uses 16 bit object indexes and 8 bit subindexes. From Modbus -> Profibus I must make
up for the missing 8 bit, and when going Profibus -> Modbus I must limit my addressing range. I did this in an application-specific way which worked fine, but the decisions taken might upset another user for my gateway, and make it completely unusable for his application.

>There is also a new standard comming up OPC DX which
>extends the OPC Data Access server with an Data eXchange function. This
>will enables you to exchange data between two OPC servers. Thus
>exchaning data between two modbus systems, or exchange data between a
>fieldbus environment and an profibus environment, etc..

Other initiatives that promised to have unified API for all sorts of different fieldus systems failed in the past - such as IEC 61131/5 and the NOAH project. What is special about DX that it can do better? Is it only the fact that all have Ethernet as a common denominator? If so, this is a very weak assumption to build DX on...

>But take in mind that OPC is still more or less tied to
>the windows operating system. Although there are currently tool kits
>available to implement OPC clients and servers on other platforms like
>Linux.

Funny, an 'open' interface limited to a proprietary platform...

Rob

 
J
From the OPC interface standard perspective a read is a read (if you don't differentiate between synchronous and asynchronous reads) - which Modbus read function code commands to use gets handled by the implementation inside the OPC
interfaces done by a particular server manufacturer in how they have you setup the items in the server.

For example, some take an address 40001 and know from the first digit "4" that you are talking about Holding Registers and the 0001 is an offset into holding register memory. Others have you explicitly say that the memory type is holding registers, inputs, outputs, input registers. This configuration though is typically done in the server by mapping a tag name to the actual PLC address thus allowing the client to not have to "hint" the OPC server as to how to get to the actual PLC location.

The point remains that loooking into an OPC read interface from a client software application, the client is unaware of the underlying protocol specific implementation of the interface except for the OPC Item name which is where you get your protocol specifics involved - i.e. PLC memory address - N7:0 for an AB, 40001 for a Modicon, DM100 for an Omron, etc. Clients can further be isolated from even these specifics if the user takes advantage of the ability to specify tagnames in the OPC server such that all the OPC client knows is a tagname - i.e. PIC_4013 -- the client then has no clue as to whether that is coming from an AB, a Modicon, an Omron. Taken to it's fullest extent, this is as it should be in good object oriented design of interfaces where the rule is to make the interface as
independent of the underlying implementation as possible. That way the underlying implementation can change without the client application needing to be made aware in any way.

With regards to OPC to OPC gateways that can be used for things like this aplication -they do exist for this purpose -- an example of one can be found at
"http://www.softwaretoolbox.com/quicklink.asp?partnumber=41233400":http://www.so
ftwaretoolbox.com/quicklink.asp?partnumber=41233400

John Weber
 
> I've been bringing this up for years and even though it's becoming
> quite a problem, no one in the industry seems much interested in
> common open standard protocols. That's a shame as only demand from the
> people who build solutions is likely to change anything. If there was
> only one protocol that everyone supported, it would be an enormous
> leap forward. If that proto was suited to data exchange it would be
> even better. Call it a bridge protocol. I would be interested in which
> protos would be good candidates. To have an Open one would probably
> require writing another proto.

Actually, people in this industry have been trying unsuccessfully to create common open protocols for at least 15 years. The old folks on this list will remember Manufacturing Automation Protocol (MAP) sponsored by General Motors in the mid 1980's. GM demanded that any new PLC's and cell computers use MAP. MAP interfaces were made available for a variety of PLC's. MAP was based on the OSI (Open System Interconnection, not Open Source Initiative) seven-layer model. The Saturn car plant originally used all MAP interfaces, although I don't know what they use now. You can still purchase MAP interfaces to PLC's today, although hardly anybody does because they are very expensive.

In the 90's, the ISA SP-50 fieldbus standard set out to create a standard for field I/O. The committee worked on it for years and came up with a standard that the IEC lumped together with seven other "standards".

One protocol to do everything required in industry would be quite a feat, but I doubt that people would be willing to pay the extra price for all the functions they don't need. The protocol would require the high-speed, coordinated timing of SERCOS, while at the same time supporting large file transfers like FTP. If
you start restricting your requirements to reduce costs, I think you'll find that there are existing open and closed protocols that already serve the market. Rob Hulsebos has a great big list of them.

Sincerely,

Mark Wells
President
Runfactory Systems Inc.
http://www.runfactory.com1235 Bay Street, Suite 400
Toronto, Ontario, Canada M5R 3K4
Ph. 416-934-5038
Fax 416-352-5206
 
John Weber:
> the client then has no clue as to whether that is coming from an AB, a
> Modicon, an Omron. Taken to it's fullest extent, this is as it should
> be in good object oriented design

Careful with that, though, I have a feeling it's patented (using object oriented stuff with PLCs, that is). No idea what if anything the patent covers, but you might want to check into it.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C
Hi Mark

The idea was good, the wrong people were driving it. For MAP, it perhaps suited GM well, but it was all new and a cost plus affair. The companies all did their own implementations and hardware and that costs way too much money unless there
is vast uptake and usage. And it isn't really Open.

The SP50 debacle is an example of why we can't expect positive change from those who have vested interests in keeping things closed. If you have a
consortium of people who are keenly interested in their puppy becoming the standard deciding on standards, the results are very predictable. And it worked out exactly that way. I don't think anyone was very surprised.

Now, users might have their differences and perhaps even, an axe to grind. But they have more interest in simply having a standard than which one it is. And users understand that there is an enormous advantage in doing transport on
something that is ubiquitous and commoditized already. And no particular advantage to inventing new anything. What I am saying is that, instead of
throwing up our hands and simply accepting preservation of the status quo, that we get together some good heads and select those things that would be most likely to insure success rather than being IP and profit motivated.

The previous failure have not been because it's a bad idea, they have been process failures. Having the large vendors involved has been demonstrated to be a cause for failure. Trying to be all things to all people has been demonstrated to be a cause for failure. And consortia are definitely death to standards processes, especially when the members own the candidates.

To avoid another Deming demonstration, I suggest we try something different. Something least cost, least risk, using commodity hardware and reasonable scope. Something with reference code published and demonstrated to work _before_ it is presented to the vendors for implementation. With an Open Spec that is immutable and under public control. For example, a Uniform Register Block exchange protocol would solve the great majority of problems, is almost trivial to do and could be transparent. Many things in automation work this way already but only within a product line. Nothing radical here.

I think this is the type of effort that is required to effect change. And it would definitely be worthwhile. It's very doable with some support from the readers on this list. Getting the vendors on board would be much easier than asking them to support a competitor's proto.

Call me names if you will, but this is what I'm really about, solving problems by whatever means is necessary. I don't see that as unreasonable. This is the world I have to work in. If you drive the truck, you oughta be able to pick the station on the radio.

Regards

cww
 
C
Hi Herman

When I think of Open Common Standards, OPC doesn't meet the criteria. Besides being extreme overkill between PLCs, it isn't particularly suited to automation. A lightweight, automation specific protocol could accomplish more with less resource usage. Including a Windows box in the mix is a large unnecessary expense and support for OLE could very well disappear whenever it
suits their purpose. Like, .NET For Process Control? ;^)
Even between PCs, something more automation specific would be much more efficient and a lot easier to code for. And I think a user driven specification would be more likely to be universally accepted. A simple register block
exchange would be pretty cheap and easy to implement and wouldn't require much in the way of language support. Serial and TCP/IP should be supported for transport. This way older equipment could get into the act with a "ascii" or
"BASIC" module.

Regards

cww
 
Curt,

"Protocol wars" are too exhausting for me. If you really must invent a new protocol, I suggest you start by looking at the MMS definitions.
A good description is at:

"http://www.control.auc.dk/~henrik/undervisning/netpro/litt/mms_intr.txt":http://www.control.auc.dk/~henrik/undervisning/netpro/litt/mms_intr.txt

If the hyperlink gets scrambled on the A-list, go to google.com and do a search on: Ralph Mackiewicz "MAP Version 2 specifications"

Good luck.

Sincerely,

Mark Wells
President
Runfactory Systems Inc.
http://www.runfactory.com1235 Bay Street, Suite 400
Toronto, Ontario, Canada M5R 3K4
Ph. 416-934-5038
Fax 416-352-5206
 
C
I'm interested in peace not war. Competing, incompatible, protos don't interest me because there are already too many. MMS is good work. It doesn't seem to be taking the world by storm although it does show up in certain circles. I think it was available on the ancient robots I program. While it does seem to be very
comprehensive, I think it too seeks to accomplish too much. Very often in the X-Y conversion, what ends up being exchanged at great expense and hassle, is simply register values or what could be represented as such. Suppose you could just plug in a cable and say 64 registers from each machine appear in the map of the other. This would require no programming support as they could just be treated as registers. Most of these exotic conversions could be handled without
the infelicities and cartesian products that result from the various encodings, decodings, and mutilation that converting from proto to proto can bring. All that is needed to do something like this is a standard byte ordering and packet
format for transport and a fairly simple, no adjustments, service on each end. One could even use a subset of say Modbus and modbus/TCP to do this to avoid inventing anything new. My preference would be even simpler than that. I could probably write something like this in a couple days between cooperating machines. With time for coffee.

Yet the utility of even this humble, modest, facility would be enormous if it could be made universal. Consider just how much grief and expense and work and time has been spent by so many people over and over to simply get a few values from one machine to another. It should be trivial. It's something that is needed often enough that it should have been a no brainer to provide it. With languages that deal in register values directly, transparent register access
between machines is the obvious, blindingly simple solution to the problem of synchronization and communications. I submit that the only reason it hasn't been a feature from the very beginning is that it would allow users to mix products. The problem is not technical, it's obviously a useful idea, but because it needs to be agreed upon by the vendors, it'll never happen unless we
adopt a different process. A user driven process. A community process to simply get things we need and end the pettiness and obstruction that plagues our working world. The status quo makes things way too complicated, deliberately.

Regards

cww

 
R

Ralph Mackiewicz

> http://www.control.auc.dk/~henrik/undervisning/netpro/litt/mms_intr
> .txt
>
> If the hyperlink gets scrambled on the A-list, go to google.com and do
> a search on: Ralph Mackiewicz "MAP Version 2 specifications"

FYI: You can get a good deal of information on MMS, including a PDF version of the above document with figures, from:

http://www.sisconet.com/techninfo.htm
including a tutorial overview, how to encode/decode MMS packets, a description
of the ASN.1 protocol for MMS, and some articles. There is also information on UCA/IEC61850 and ICCP IEC60870-6 TASE.2 on this page.

> The idea was good, the wrong people were driving it. For MAP, it
> perhaps suited GM well, but it was all new and a cost plus affair. The > companies all did their own implementations and hardware and that
> costs way too much money unless there is vast uptake and usage. And it
> isn't really Open.

You can't get more open than MAP which was based on a profile of international standards. Openness is not the sole criteria for success in the marketplace, obviously.

> The previous failure have not been because it's a bad idea, they have
> been process failures. Having the large vendors involved has been
> demonstrated to be a cause for failure. Trying to be all things to all
> people has been demonstrated to be a cause for failure. And consortia
> are definitely death to standards processes, especially when the
> members own the candidates.

...snip...snip...

> I think this is the type of effort that is required to effect change.
> And it would definitely be worthwhile. It's very doable with some > support from the readers on this list. Getting the vendors on board
> would be much easier than asking them to support a competitor's proto.
>
> Call me names if you will, but this is what I'm really about, solving
> problems by whatever means is necessary. I don't see that as
> unreasonable.

As long as there aren't any 'large' vendors involved. Can't have anybody who actually sells stuff to users participating in these activities or somebody might actually use it!

Regards,

Ralph Mackiewicz
SISCO, Inc.

 
C
Hi Ralph

Ralph Mackiewicz wrote:
> > http://www.control.auc.dk/~henrik/undervisning/netpro/litt/mms_intr
> > .txt
> >
> > If the hyperlink gets scrambled on the A-list, go to google.com and
> > do a search on: Ralph Mackiewicz "MAP Version 2 specifications"
>
> FYI: You can get a good deal of information on MMS, including a PDF
> version of the above document with figures, from:
>
> http://www.sisconet.com/techninfo.htm
>
> including a tutorial overview, how to encode/decode MMS packets, a
> description of the ASN.1 protocol for MMS, and some articles. There is
> also information on UCA/IEC61850 and ICCP IEC60870-6 TASE.2 on this
> page.
>
> > The idea was good, the wrong people were driving it. For MAP, it
> > perhaps suited GM well, but it was all new and a cost plus affair.
> > The companies all did their own implementations and hardware and
> > that costs way too much money unless there is vast uptake and usage.
> > And it isn't really Open.
>
> You can't get more open than MAP which was based on a profile of
> international standards. Openness is not the sole criteria for success
> in the marketplace, obviously.

Obviously not, but my point was that even the best, most useful idea can be killed by how it's done. It costs a lot to do MAP the way it hit the market. Openness is simply the most direct and fastest way to popularize a protocol or standard, it can't create a market or commoditize hardware. Open standards on commodity hardware that meet a universal and well established need simply are
more likely to be utilized.

> > The previous failure have not been because it's a bad idea, they
> > have been process failures. Having the large vendors involved has
> > been demonstrated to be a cause for failure. Trying to be all things
> > to all people has been demonstrated to be a cause for failure. And
> > consortia are definitely death to standards processes, especially
> > when the members own the candidates.
>

I'd still be interested in your opinion of the example of the simple yet infinitely useful standard of transparent register access for X-Y translations and other trivial synchronization and communication tasks. How it comes about
is peripheral. Would it or would it not be a good thing? Why hasn't it happened? Isn't it obvious?

> ...snip...snip...
>
> > I think this is the type of effort that is required to effect
> > change. And it would definitely be worthwhile. It's very doable with > > some support from the readers on this list. Getting the vendors on
> > board would be much easier than asking them to support a
> > competitor's proto.
> >
> > Call me names if you will, but this is what I'm really about,
> > solving problems by whatever means is necessary. I don't see that as
> > unreasonable.
>
> As long as there aren't any 'large' vendors involved. Can't have
> anybody who actually sells stuff to users participating in these
> activities or somebody might actually use it!

The problem is that if someone is already actually using it, the major vendors feel they absolutely _must_ use something else.

You misinterpreted that rather badly. The vendors can and would certainly have to be involved, they simply can't be in control. At least not individually. They can even create them if need be Sun Inc. has made many things standard by creating them and then relinquishing control. The reason that the rest of the computing world works so smoothly is that 3Com Ethernet is the same as Intel Ethernet. And they can't pervert TCP/IP. They compete on hardware and features but not on standards. If it were up to them or MS for example, we wouldn't be able to have this discussion on the public network, at least not without paying someone. And evidence of this is that MS is trying very hard to revert us all
to that model. They just can't tell when they've got it good. Not so very long ago networking was in the same hopeless state. The proprietary competitors to Ethernet/TCP/IP are mostly memories now and networks and the market have
increased by several orders of magnitude as a result. What we take for granted, ubiquitous standardized networking would never have occured without a single vendor neutral standard. It was a bizarre and ugly process, but once a standard
was in place, the benefits are obvious.

It's worthwhile to mention that almost all the things that are well standardized in automation are not controlled by the major vendors and all the things that are balkanized are.

It's ultimately the market that decides what becomes a standard anyway. I'm simply saying it would save a decade or two and many millions of dollars if we started there.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net. Day Job:
Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

 
Curt,

It sounds like you want to create an "Open" version of VMIC's reflective
memory: http://www.vmic.com/products/reflectivememory/index.html

If you restrict yourself to only Linux, and only one transport media type, it should be technically easy to create a protocol.

If you hope to convince all automation vendors to support your protocol for every device, then that's a marketing problem, not a technical problem. I'm not sure how to solve this particular marketing problem. Methods that have failed in the past include: 1. Huge companies demand it (GM and Boeing demand MAP/TOP) 2. Huge companies supply it (Siemens and most of the German instrumentation industry with various flavours of Profibus) 3. U.S. federally funded organization promotes it (NCMS and MMS) 4. Large end-user volunteer organization designs it and promotes it (ISA with 40,000 members and SP50)

With the exception of MAP/TOP, the methods mentioned above had huge marketing budgets. I think your process for creating the new protocol doesn't involve a marketing budget, just the expectation that common sense will prevail and everybody will eventually use the new, "Open" protocol. Or maybe somebody else will see an opportunity to provide support services for the new protocol and provide marketing, although this seems unlikely.

I think it is a very challenging project.

Sincerely,

Mark Wells
President
Runfactory Systems Inc.
http://www.runfactory.com1235 Bay Street, Suite 400
Toronto, Ontario, Canada M5R 3K4
Ph. 416-934-5038
Fax 416-352-5206
 
C
Hi Mark

Mark Wells wrote:
> Curt,
>
> It sounds like you want to create an "Open" version of VMIC's
> reflective
> memory:
> http://www.vmic.com/products/reflectivememory/index.html

You don't even have to dig that hard, shared memory as an IPC mechanism has been around for decades and I'll bet one of the first things done with sockets was to share across the network. The concept has been standard practice in *NIX forever and programmers use it to solve this same class of problems without even thinking. An awful lot of I/O is simply mapped as registers as well. The model is ubiquitous, that's what makes it such a good example. Even in automation, they do it with IO, they do it within product lines e.g. cmm in GE 90/30, but no one has thought that it would be handy in the general case? Instead there's a huge assortment of kludges and bridges and adapters and junk to solve a problem that should never be. I'll wager that each and every product line uses the concept somewhere but miraculously, no two use the same implementation. I'm not really ridiculing them here, because it's not possible for them to create such a nifty little feature. Not because they don't have the resources or the talent, but because they can't cooperate. This hyper competition provides no common ground or vehicle for this sort of effort. That's where we as users can help out. By working out a neutral format and letting them know we would like to end the madness this way, they can give in to customer demand which is somewhat different than cooperating with competitors.


>
> If you restrict yourself to only Linux, and only one transport media
> type, it should be technically easy to create a protocol.
It would be only slightly more challenging to come up with something that could work for all platforms that can do the transport. Any of the recent FB proposals I've seen is of truly byzantine complexity in comparison and they invent those every day.

>
> If you hope to convince all automation vendors to support your
> protocol for every device, then that's a marketing problem, not a
> technical problem. I'm not sure how to solve this particular
> marketing problem. Methods that have failed in the past include: 1.
> Huge companies demand it (GM and Boeing demand MAP/TOP)

They got it! Trouble is, no one else could afford the physical plant.

> 2. Huge companies supply it (Siemens and most of the German
> instrumentation industry with various flavours of Profibus)

Never works, It's "Not Invented Here".

> 3. U.S. federally funded organization promotes it (NCMS and MMS)

Worked for DARPA, but they were dealing with idealists, not cutthroat competitors.

> 4. Large end-user volunteer organization designs it and promotes it
> (ISA with 40,000 members and SP50)

As they have been lamenting lately, no one pays much attention to their stuff. I suspect the committee and consortia problem comes into play here. I'm not sure why it's broken but I suspect it is not enough openness and too little participation. Just a guess. I'm not an ISA member. If it's this ineffective, I don't see becoming one either. Still this is the best bet, perhaps they should consider offending someone sometime.

>
> With the exception of MAP/TOP, the methods mentioned above had huge
> marketing budgets. I think your process for creating the new protocol
> doesn't involve a marketing budget, just the expectation that common
> sense will prevail and everybody will eventually use the new, "Open"
> protocol. Or maybe somebody else will see an opportunity to provide
> support services for the new protocol and provide marketing, although
> this seems unlikely.
>
> I think it is a very challenging project.

What you are seeing is a complete and total dissipation of the awesome power customers have. With the smallest amount of cooperation and effort towards the common interest, these problems can be solved. If every shop reading this list made such a feature mandatory for 2Q2002 purchases, it would be there by 2Q2002. That's what a real user community might do. As long as we maintain our rugged individualism, nothing interesting happens. Whose interests does that serve?

Regarde
cww
 
Top