Today is...
Saturday, June 15, 2019
The OPC Community Forum.
Open communications in the doldrums
It is two years now that OPC/MIMOSA have kept us in the dark on thier imminent solve all XML standard. Out of the blue arrives a new kid on the block...........
By Roger Irwin on 14 April, 2003 - 10:56 am

The OPC foundation has, in the past, done a reasonable job of 'upping the level' of industrial control interfaces, providing a standard API that is suitable for use by people who are 'above' the device level (production management, quality control etc.). But the OPC standards have many shortcomings. It was originally designed as an API between application and low level device interface, not as a site wide intercommunication protocol. The use of DCOM has allowed it to take on the latter role, albeit with many shortcomings. OPC promised to produce new specifications based on XML that would be more suitable for site/enterprise wide system integration as far back as 1999.

Other organisations have also worked on open protocols for industrial system integration. Some of these of never got out of thier niche markets whilst others seemed to give up in the face of the widespread diffusion of OPC, which is very well supported by both automation manufacturers and third party automation software developers. One competing standard that looked promising was MIMOSA. This had started out by defining database standards and hence SQL interfaces, and like OPC migrated to XML as a concept for improving the interface.

OPC had orginally touted a lot of features, and initially seemed very keen on making some sort of biztalk compliant interface (which worried a lot of us as it did not seemed to be the right sort of interface!). Latterly they have only talked about SOAP. They also talked with MIMOSA and decided to work together on a compatible XML standard. Things were looking positive.

But all that was 2 years ago. Deadlines have come and gone. Announcements have floated by, and in the meantime the actual information available appears to be getting less. In fact the previously published MIMOSA standards have now been made secrect, clearly thier collaboration with OPC has had some effect!

In the meantime we the users are still holding our breath. COM and DCOM are officially passe, but we do not know how or where to invest our time and money in order to go forward! From the information I have managed to extract here and there it would seem that OPC and MIMOSA decided that they had such a mess between them that the needed to start from scratch and produce something sweet and simple, as it should be. Hence also the secrecy, they did not want snippets of the original work to get out as they were allready working on something completely different. Unfortunatly it would seem that 'XML2' has also suffered from comittee bloat and run off the rails as well.

The, out of the blue, arrives IDA (www.ida-group.org). They have come apparently from nowhere with a first rate common sense standard proposal. The basic concept appears to be that of taking the IETF proposed Modbus TCP/IP standard and 'describing' the interfaces with XML, i.e. levering existing technology and standards and making it available in an easy and palatable form to people at an EDP level. That is probably too much a simplification. IDA standards, like OPC, can conceive any underlying transport such as CAN and Profibus, but the higher level interface is defined in a clear simple and concise manner. And it is freely available for download.

So, I thought this might make a good topic of discussion for this group (which has a notorious reputation for heated discussion on comms protocols). Does the IDA group have a chance of filling the void left by the OPC/MIMOSA failure to deliver, or is the OPC on the verge of releasing a world shattering super flexible protocol?

By Ralph Mackiewicz on 14 April, 2003 - 4:52 pm

> The, out of the blue, arrives IDA (www.ida-group.org). They have come
> apparently from nowhere with a first rate common sense standard
> proposal. The basic concept appears to be that of taking the IETF
> proposed Modbus TCP/IP standard and 'describing' the interfaces with
> XML, ....snip....snip....
> So, I thought this might make a good topic of discussion for this
> group (which has a notorious reputation for heated discussion on comms
> protocols). Does the IDA group have a chance of filling the void left
> by the OPC/MIMOSA failure to deliver, or is the OPC on the verge of
> releasing a world shattering super flexible protocol?
I don't think the OPC's objective was to deliver a world shattering super flexible protocol so I don't see how there was a failure (not sure about MIMOSA though).

The public documents available are architectural right now, so its a bit early to tell if IDA is going to be able to deliver a world shattering super flexible protocol. From what I can see, using Modbus TCP for this will not be signficant to current users. If all that modelling stuff is added (Potentially good stuff, by the way. It is what has always been missing from any of the numerous IA protocols du jour commonly used. The model driven approach solves numerous application integration problems) the result will not likely be interoperable with the average Modbus-TCP implementation available today that supports a 16-bit register with a numerical address model unless intervening mapping functions are added that move the integration out of the protocol. That approach can be taken for any protocol. It's called a gateway.

FYI: there is already an international standard IA protocol that
supports robust data models that runs over TCP/IP. But, it is more complex than Modbus-TCP. It's called MMS (ISO9506).

For reasons that you can see in the recent posting that disputed that there was a failure of OPC (PROC: Tag Databases - OnLine (Open source) Specifications ?), I don't think there is demand for a world shattering super flexible protocol. I'm not smart enough to predict the future, but I don't think that there is any significant outcry today for a single protocol that does everything for the IA industry. I'm not even sure that is possible technically, let alone commercially. However, a single approach, particularly a model driven approach, is possible. Go to the Object Management Group ( http://www.omg.org ) and look at their white paper on Model Driven Architecture (MDA) for a description of this concept. IMHO, this is the future.

Regards,
Ralph Mackiewicz
SISCO, Inc.

By Roger Irwin on 15 April, 2003 - 1:34 pm

I have re-visted the MMS stuff and, yes, this is complete and in use and suitable for use by the IA industry. But not adopted.

This is the level of interface I have been waiting for OPC/MIMOSA to come up with for the last two years. But if they never get there (and two years over schedule is a long time by anybodys standard) then will something like MMS or IDA come into mainstream IA like OPC DA has?

By Jonas Berge on 16 April, 2003 - 11:50 am

FOUNDATION(tm) Fieldbus is using a subset of MMS (e.g. ISO9506-6 a.k.a.
ANSI/ISA-72.02). I have seen other specifications referencing these
documents.

Jonas Berge
==================
jberge@smar.com.sg
www.smar.com

By Roger Irwin on 16 April, 2003 - 10:05 am

> I don't think the OPC's objective was to deliver a world shattering super flexible protocol so I don't see how there was a failure (not sure about MIMOSA though).

The world shattering were my words, but look back at thier press releases and perhaps I was not far off;-) However, the intention was to make a standard that could work accross enterprise networks in an open and flexible manner, something their present standards fall far short of and for no fundamental reason.

> The public documents available are architectural right now, so its a bit early to tell if IDA is going to be able to deliver a world shattering super flexible protocol.

I think the IDA communications section when read in conjuction with modbus tcp/ip is a pretty complete document, including XML schema and examples as to how we can define data to be transferred over modbus TCP/IP (I was reffering to the comms section and not the whole IDA model, but as is probably clear, I am also playing the devils advocate;-))

> FYI: there is already an international standard IA protocol that
> supports robust data models that runs over TCP/IP. But, it is more complex than Modbus-TCP. It's called MMS (ISO9506).

I keep running into this, I would appreciate further comments as I can never understand wether it is still in experimental phase or has been ratified. Opening up the argument what do other people think of this approach as an enterprise or intersystem protocol.

>I'm not smart enough to predict the future, but I don't think that there is any significant outcry today for a single protocol that does everything for the IA industry. I'm not even sure that is possible technically, let alone commercially.

I don't think a single protocol is either viable or desirable for all IA. In particular at a local level protocols such as CAN and Profibus DP serve requirements that are far removed from e.g. XML. OPC is still better than XML for the type of applications it was originally intended for such as interfacing a PC based SCADA to PLC's.

BUT, we do need a common protocol for exchanging between subsytems and from governing/monitoring systems to underlying subsystems. There are allready protocolls capable fo doing the data transfers, but we need a standard way to define the connections and have a common API. OPC has demonstrated the advantages of this.

By Anonymous on 16 April, 2003 - 2:17 pm

I have been spending a little time at the IDA web site and while it looks interesting I see no language regarding the licensing of the technology. I also then spent some time last night at the patent office (web site that is) searching for patents from the member companies. There are a number of patents that cover many of the technological virtues that IDA seems to extol.

Given that the board is made up of four or five vendors each with numerous patents that cover many of technologies that IDA seems to utilize it makes me wonder.

Now if this were an environment where patents were used solely as defense then I would say no problem. But we know better now that some see fit to use them like weapons. So I ask should initiatives like IDA make a clear statement upfront regarding the goals and requirements of their membership that precludes any member from surfacing a submarine patent once a body of products have been developed?

Thoughts any one.

Moderator, Surprise me by not censoring a response that clearly hits on such a touchy area.

(One person's touchy subject is all in a day's work for others. Surprise us all and sign your name next time... :-) --The moderator )

By Dick Caro on 16 April, 2003 - 5:08 pm

This is an excellent and timely issue, especially since Schneider is part of the iDA management group. If you remember, Schneider is the company that invented Modbus/TCP and placed the specification in the public domain by publishing it on their www.Modcon.com web site. Then in 2000 they filed suit against OPTO 22 for infringement of some of their patents. OPTO 22
used Modbus/TCP.

I have been assured by Schneider and Jetter AG, two of the vendor companies in iDA that they wish iDA to become accepted and do not want the patent
issue to become a problem. RTI is the company that has helped write the iDA specification in English and has bound in the real-time publish/subscribe RTPS protocol into iDA. I have seen the RTI submission to the IETF in 2001 that placed the RTPS algorithms into the public domain as required by the IETF for a standard.

This makes me feel good about iDA, but in this patent game, you never know. The technology of iDA belongs to the iDA Group, which is chartered in Germany as a "club". The only way to assure your own protection is by contract protecting you even in case the ownership passes to another party.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Joe Jansen on 16 April, 2003 - 5:14 pm

I have started and abandoned a few replies on this topic, And maybe this one will join the others, but we'll see! ;->

I went through the website, drug myself through about as much of the pdf file as I could stand, and although I think it is a noble effort, I just
don't see it going anywhere.

It appears that they intend to freely license everything, as they make some claim to following the open source model, etc. Now, we have all
heard the "Open Platform" mantra from just about every vendor, and they all turned out to be bogus.

My reaction, though, is "So what?". It appears to be a middleware sitting on top of Modbus/TCP. This makes sense, since Schneider is one of the
"founding members". The problem is that in the global market, Schneider is a distant fourth. Siemens will never let go of ProfiBus, and Omron and Rockwell are both backing Ethernet/IP through the ODVA group. I don't expect to see any of the top 3 divert any energy into supporting something
that is basically designed to bring Schneider back into the "upper group", so to speak. And without a clear statement of licensing intentions, it would be foolish of any of those three to start building technology around it.

I am sure it is a noble effort, but unless you are already dedicated to using Schneider's (Modicon) controllers, I wouldn't expect to see Siemens, Omron, or Allen Bradley rushing to offer their own implementation of IDA.

Just my thoughts....

--Joe Jansen

By Curt Wuollet on 17 April, 2003 - 1:56 pm

That is a grave concern, and I am not anonymous :^)
What's more, on all these industry consortia and
the OPC foundation specifically, the member list
gives me pause to reflect that depending on these
folks for _Open anything_, is closely akin to
depending on OPEC for alternative energy.
It's simply not what they do, in thought, word, or
deed.

What then, makes them qualified or even credible?

PS The submarine patents issues pervades OPC, XML and SOAP.

Regards

cww

By Alex Pavloff on 17 April, 2003 - 4:49 pm

"These folks"?

There are 300 members in the OPC foundation. There are major automation vendors, small automation vendors, single person consultancies, and universities that are members, and they're spread out over the entire world. Heck, if you want to sign up a group of open source people, I'm sure they wouldn't mind if you wanted to fork over the $500 non-profit association fee. You're always saying that there are plenty of folks that want to have more open control, right? Get 50 friends together, $10 a pop, and contribute your input.

The 50-odd corporate members (those the OPC foundation says can "create and shape the technology") that have their products listed on the OPCFoundation.org website are listed at
http://www.opcfoundation.org/05_products/05_self_cert.asp.

Once again, they range from vendors large to small covering the entire globe.

Painting everyone in the OPC Foundation (which doesn't include my company, by the way) with a big proprietary-monopolistic brush is unfair. Implying that they're all out to screw the customer by making them pay more for proprietary things is unwarranted and hurtful.

Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com

By Mark Hensley (Kepware) on 18 April, 2003 - 2:08 pm

Hi Alex,

Kepware is one of those small companies listed in the link you provided and I would like to think we aren't out to "screw" anyone. Pardon my French.

Constantly I hear how if only everything was open source everyone one would get everything they ever wanted instantly. Specifically when it comes to product enhancements or fixes. So here sits little Kepware (evil provider of windows software), along comes a customer with a problem. This happen today by the way. Customer "I'm seeing an issue in your GE Ethernet driver when reding PLC status data, can you check it out?" Our response contrary to our the so called "Screw'em" goal of windows based vendors, was immediately grab our GE PLCs hook up a couple of them, verify the problem, make a fix, test it, send it to the customer. All in the span of about 4 hours (testing takes a little time).

Now at what point in this story did I screw the customer. The new driver will be part of the next release of our server which is FREELY available from our web site at no cost for the upgrade. If the answer from some of our fellow list members is that I charged them for the driver in the first place then I'm sorry. Last time I checked I didn't hear any bells ringing that indicated it was time to go eat the state sponsored free lunch.

Sorry for the soap boxing but its rare that anyone gives us little guys any credit like you have done Alex and I want to thank you for that.

Mark Hensley
Kepware Technologies
( We make software, and we sell it, EVIL :-) )
(If you run our software backwards you hear devil music).

Sorry its been a long week.

By Landau@attbi.com on 19 April, 2003 - 10:54 am

Mark -

The folks at KEPWARE have gotten me out of more than 1 comm nightmare by providing with OPC drivers to less common plc's. The small software vendors, can provide good products when the needs of the customer aren't met by a Emerson/GE/Invensys/AB/Schneider solution.

Canary Labs trend software Sytech reporting software.

Note: They are all small independent software companies in Northeast of the USA.

Steven Landau SPEC Process Engineering & Construction. Burlington, MA www.spec-eng.com

Hi Steven,

I am very happy that we have been there to help you out. Thank you very much for the kind words and as always never hesitate to call us if you ever do have a problem. We always take the stance of "Hmm, maybe there is an issue lets take a look at it". We try not to let pride get in the way of answers. When we hire new engineers thats one of the first things I try to teach them. Pride, placed incorrectly, is the enemy.

Thanks again.

By Curt Wuollet on 20 April, 2003 - 12:20 pm

Hi Mark

Actually screwing the customers were Alex's words, not mine. I was merely chafing at the solidarity to keep automation all Microsoft, forever. I am truly and respectfully interested in your opinion on the more basic questions: Should it be possible to persue automation as we know it without having Microsoft involved? And why is this seen as destructive rather than constructive, threatening, or whatever gets poeple so hot and bothered.

Regards

cww

Hi Curt,
Trust me in the grand scheme of things I don't believe that Microsoft has all the answers and specifically all the right ones. However, and this is a big however. Due to the strong market position and technologies like COM upon which OPC is based, companies like Kepware can exist.

So in simplest terms it will always be a chicken and egg issue reagarding market size and breadth.

I mention breadth from the standpoint that even if a single vendor produced and became a substantial provider of automation software within the Linux space that still would suit the market needs of a small company like Kepware. Kepware is a small company by many standards, only 14 strong, but it is 14 people that eat, sleep, and live communications drivers. I have been very fortunate to keep all of my employees even through the heady days of the Dots Coms. These people and their accumulated talents cost most of what Kepware earns. As such I can not afford to move into questionable markets where the return on that investment may be minimal. To be honest I invest in a lot of development efforts under the windows environment but at least there I can see the potential because I know the players.

I don't profess to know much about the Linux market but I haven't seen anything like OPC for the Linux world. What I mean by that is that I don't see a standard API that a large range of existing mainstream vendors support. An API that the average Joe using some BASIC like language can access(we have a lot of VB users). In short I don't see MASS.

In the windows world we already have to work very hard to pitch our products to the various vendors whom in many cases already have their own legacy drivers. Given the roughly one billion dollar size of the automation software market we can get our little piece of that pie. I don't see a market any where near that size in the Linux platform(for automation).

Everything said, in the final analysis, even if we had a Linux product I wouldn't want to make my source code available since I'm the one paying my engineers, testers, and support group, why should I make it easier for someone to copy all of our work? As any one that has written drivers knows, having the protocol doc is only half the story when it comes to writing a good driver.

I know this is a little long winded but you asked.

By George \(Jim\) Hebbard on 23 April, 2003 - 3:20 pm

In the grand scheme of things it may not make much difference (at least to IA) whether Microsoft "wins" or Linux or QNX or whatever. However, as a 60+ year old Registered Professional Chemical (Process) Engineer, I have
been burned deeply by this whole proprietary/open argument in the past.

My "Open" friends tell me that COM (common object model) was an early and weak attempt that Microsoft picked up to try to improve inter-process communication. It was somewhat strengthened my modification to DCOM when Bill Gates's people realized that networking (and the Internet) was where the money is. They assure me that COM/DCOM isn't really an ORB (object
request broker) protocol interface like CORBA (common object request broker architecture) which they prefer. So even DCOM (distributed common object model) is, they say, inadequate for cross-platform work. I don't know.

The argument has ascended to a higher plain with Micro$oft types pushing XML-RPC and the Open types pushing SOAP, which they tell me is even strong enough to clean up the defects in COM/DCOM. A good reference on the discussion starts here:

http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-corba.html

When I was (severely) burned by the ONSPEC Concurrent DOS/PC-DOS arguments over operating system GUI (pixel graphics versus raster graphics) I learned quickly how negative a big fish is a small pond can be for the denizens of
the small pond. IBM reportedly threatened to drop ONSPEC as a VAR if they upgraded the successful Concurrent DOS version before they launched the IBM compatible version.

Pixel graphics are arguably more satisfactory for IA because the excellent graphics available at (relatively) high speed at the end of an RS-232c signal provided for very inexpensive color graphic remote displays located well away from the CPU. In any case, I had recommended ONSPEC and IBM effectively made me wrong. Microsoft has more clout, but has also learned that defects in design can be overcome by excellent marketing.

I am more concerned with Microsoft's tendency to consider the results of their marketing prowess as THE STANDARD and totally proprietary, making
competition a farce.

=>Jim<=

By Joe Jansen on 23 April, 2003 - 3:11 pm

The largest amount of inertia comes from the fact that in general, people expect to pay for software that runs on Windows. On the other hand, people expect "free-as-in-beer" distribution for anything on Linux.

As long as this is the case, developers are afraid to move to the Linux platform. Either they give up any hope of being a profitable company, or they get crucified when they actually try to enforce a paid-for licensing program. As a case in point, one of the complaints about Linux desktop is a lack of games. Loki Software entered the market to fill that very vocal gap. Loki is now bankrupt because very few people wanted to pay for the Linux version of the games, even though they spent $40 or more for the same game on windows.

Obviously I am generalizing, and this does not include everyone, however, you have to admit that the majority of Linux users typically don't pay for their software either through piracy, or simply refusing to use software that isn't GPL'ed. The GPL is a kiss of death for profitable software businesses. How many of the 'give away the software and sell the services' companies are still alive? Red Hat is changing business models, IBM and HP claim profits, but then again, they are using Linux on their own hardware, which I think is not a factor that can be ignored.

The service oriented business model is a failure. Nobody wants to pay for tech support. I have always thought that selling services (read support) for free software just encourages developers to release software that is difficult to use. Show me how I am wrong, please. I really would prefer to see how selling services encourages easy to use software.

Until Linux is pervasive enough that the people willing to pay for software are using it, there will be a large vacuum for commercial apps. And without commercial apps, it will be extremely difficult to achieve critical mass around a free-as-in-beer protocol. Without a commercial interest, there is no way to buy your way into an existing protocol and implement it on Linux (unless you find an angel investor, but that is a whole different story).

Bottom line: AB, Omron, Siemens, etc. all exist to make a profit. If they give away their R&D for free, then they have a much more difficult time doing that. Until the majority of Linux users are willing to pay real money (not $5 distribution fees) for real software developed by professional, commercial programmers, this gap will continue.

In direct answer to your question, I absolutely think it should be possible to persue automation without MS. Unfortunatly, windows holds a vast majority of the desktop, which is where you develop your IA applications, and until there are enough paying, Linux desktops to cost justify writing a port for RSLogix, CxProgrammer, etc. the automation vendors who make the development software and tools have no motivation to try to make a non-MS automation market.

Just my rambling thoughts....

--Joe Jansen

By Linnell, Tim on 24 April, 2003 - 11:22 am

>As long as this is the case, developers are afraid to move to the Linux
>platform. Either they give up any hope of being a profitable company,
>or they get crucified when they actually try to enforce a paid-for
>licensing

I think it's actually simpler than this, and has nothing to do with fear - no one is prevented from making money selling into Linux systems, and many people do. Vendors (and I work for one) know that targetting Windows for support tools will cover the entire automation market (with the exception maybe of Curt) in a single hit. The existence of technologies like OPC help a good deal, and development tools and underlying features are good and stable; fundamentally it's an easier deal in terms of the development and
ongoing support. On the other hand Linux developments for shrink wrapped software are much more difficult because there are many different
distributions, desktop environments, and even hardware platforms. Some poor sod in customer support has to keep up with all of these!

Regards

Tim Linnell

By Michael Griffin on 24 April, 2003 - 11:25 am

On April 23, 2003 11:10, Joe Jansen wrote: <clip>
> The largest amount of inertia comes from the fact that in general, people
> expect to pay for software that runs on Windows. On the other hand,
> people expect "free-as-in-beer" distribution for anything on Linux.
<clip>

I would suggest this is only true for a certain segment of the market. I would also point out that a very large percentage of people don't expect to pay for Windows software either (and don't). In many parts of the world, most Windows software (including WIndows itself) is "free" for all practical purposes.

> As a case in point, one of the complaints about Linux desktop is
> a lack of games. Loki Software entered the market to fill that very vocal
> gap. Loki is now bankrupt because very few people wanted to pay for the
> Linux version of the games, even though they spent $40 or more for the
> same game on windows.
<clip>

Games are a very difficult consumer market. Plenty of companies are going broke selling games for Windows and proprietary game consoles as well. In addition, Linux is currently mainly used for professional applications, not for consumer entertainment. I seriously doubt there is much of a games market for Linux at this time. In other words, your games example isn't very relevant.

> The service oriented business model is a failure. Nobody wants to pay for
> tech support. I have always thought that selling services (read support)
> for free software just encourages developers to release software that is
> difficult to use. Show me how I am wrong, please. I really would prefer
> to see how selling services encourages easy to use software.

The problem with the above is that you are looking at the computer on your desk, and assuming the entire "computer market" is the same thing writ large. The traditional business desktop is a backwater in the industry. There are only two computing areas where significant new development is taking place. One is consumer entertainment (e.g. games, music, etc.), and the other is servers. In both areas "services" are considered to be the future of the industry, and software as simply a channel for delivering these services.

If you want a good analogy, just consider the cell phone market. Few people buy cell phones, rather they buy a cell phone service and the cell phone is "free" (or at least below cost). That doesn't mean that companies like Nokia can't make money. It just means that you are looking at the market from the wrong end if you think of it only in terms of Nokia selling cell phones directly to consumers.

> Until Linux is pervasive enough that the people willing to pay for
> software are using it, there will be a large vacuum for commercial apps.
> And without commercial apps, it will be extremely difficult to achieve
> critical mass around a free-as-in-beer protocol. Without a commercial
> interest, there is no way to buy your way into an existing protocol and
> implement it on Linux (unless you find an angel investor, but that is a
> whole different story).

I don't see "open protocol" and Linux as being synonymous. Any advantages of a truly open protocol for Linux would be equally great for Windows. The advantages of a truly open protocol (or set of protocols) would be that everyone can use it without restriction, and no one avoids it because they are afraid the licensing rules could be manipulated against them later. The open Internet has been good for Windows as well as good for Linux.

> Bottom line: AB, Omron, Siemens, etc. all exist to make a profit. If
> they give away their R&D for free, then they have a much more difficult
> time doing that. Until the majority of Linux users are willing to pay
> real money (not $5 distribution fees) for real software developed by
> professional, commercial programmers, this gap will continue.

IBM exists to make a profit, and I hear they are doing quite well indeed. They give away a good deal of R&D for free. They are giving away R&D that helps to grow the market for their services.

The results of R&D may be more profitable for you if they enable something you want done than they would be just collecting dust on a proprietary shelf. Not all ideas on the "proper" way to success should be jammed into the same pigeon hole just because this makes classification neater.

I don't know about AB or Omron, but Siemens has set up a division to do "IT Integration" - that is to integrate automation systems with a company's larger IT systems. Siemens sees a large market for this, and quite frankly so do I, provided the communications barriers can be overcome.

Siemens has Profibus and Ethernet drivers for Linux, and they even have their own Linux distribution (Siemens Industrial Linux Distribution). This shouldn't be surprising, since as someone else pointed out that if you are going to interface with IT systems, you have to talk their language.

> In direct answer to your question, I absolutely think it should be
> possible to persue automation without MS. Unfortunatly, windows holds a
> vast majority of the desktop, which is where you develop your IA
> applications, and until there are enough paying, Linux desktops to cost
> justify writing a port for RSLogix, CxProgrammer, etc. the automation
> vendors who make the development software and tools have no motivation to
> try to make a non-MS automation market.
<clip>

You are confusing the "automation market" with PLC programming software. The latter is merely a subset of the former. There are sound business reasons at the moment why PLC programming software would target only the largest desktop operating system. However, the engineering or maintenance office desktop isn't the entire automation market or even a very large percentage of it.

************************
Michael Griffin
London, Ont. Canada
************************

By Joe Jansen on 24 April, 2003 - 4:47 pm

>>>>>
<snip>
> people
> expect to pay for software that runs on Windows. On the other hand,
> people expect "free-as-in-beer" distribution for anything on Linux.
<clip>

I would suggest this is only true for a certain segment of the market. I would also point out that a very large percentage of people don't expect to pay for Windows software either (and don't). In many parts of the world, most
Windows software (including WIndows itself) is "free" for all practical purposes.

<<<<<

True indeed. However, (making numbers up as I go here, but it should illustrate the point nonetheless) if platform A has 100 million users, and platform B has 100,000 users, and each one has a 50% pay to steal/get-for-free ratio, platform A is still the big choice. Also, many
Linux users simply won't use non-GPL software. This is not an issue for Windows users.

>>>>>

<snip>

Games are a very difficult consumer market. Plenty of companies are going broke selling games for Windows and proprietary game consoles as well. In addition, Linux is currently mainly used for professional applications, not for consumer entertainment. I seriously doubt there is much of a games market for Linux at this time. In other words, your games example isn't very relevant.

<<<<<

Yeah, you are probably right. I heard once that there are no good analogies. Probably true. My main point again was that, as a generalization, people are less willing to pay for Linux software than they are for Windows software.

>>>>>

> The service oriented business model is a failure. Nobody wants to pay
for
> tech support. I have always thought that selling services (read
support)
> for free software just encourages developers to release software that is
> difficult to use. Show me how I am wrong, please. I really would
prefer
> to see how selling services encourages easy to use software.

The problem with the above is that you are looking at the computer on your desk, and assuming the entire "computer market" is the same thing writ large. The traditional business desktop is a backwater in the industry. There are
only two computing areas where significant new development is taking place. One is consumer entertainment (e.g. games, music, etc.), and the other is servers. In both areas "services" are considered to be the future of the industry, and software as simply a channel for delivering these services.

If you want a good analogy, just consider the cell phone market. Few people buy cell phones, rather they buy a cell phone service and the cell phone is "free" (or at least below cost). That doesn't mean that companies like Nokia can't make money. It just means that you are looking at the market from the wrong end if you think of it only in terms of Nokia selling cell phones directly to consumers.

<<<<<

Nokia sells their phones to Cingulair, Verizon, and other service providers who then give them away to the consumer, binding the consumer
into a contract in the process that insures that they will more than recoup their losses. The problem is that there is no "middleman" as it
were in the Linux software deal. The software developers sell directly to the user.

In reply to your other points, my poor analogy was pointed at the game industry. You state here that the entertainment industry (games) is a
growth market. Still, the Linux gaming market is very weak. Most games out there are GPL'ed efforts that originate from Sourceforge. This
supports my earlier statement that a commercially successful Linux software company, including one targeting what you state is a growth area, games, cannot exist because of the free-as-in-beer demands of the GPL only market. True, you can try to release a commercial project with GPL, and I have heard argued that GPL does not prevent you from selling your product (MySQL, Sendmail, etc. all try this) but how do you control piracy and
re-distribution within the controls of GPL? I actually paid real money for my copy of Railroad Tycoon II from Loki, although they were already
bankrupt when I did, but some of their other releases not only had rampant piracy, but people would hack their code to make themselves invincible during tournament play.

I agree that the server market is a good growth segment. It is interesting to see how this is developing though. IBM and HP both use Linux to sell their hardware. No secret here. Linux is the loss leader (like the phone) that IBM gives away so that you buy their hardware which only they can support. This is no different than the 'old' IBM. Since IBM needs to have an OS for their hardware, why not use the one that they
can give away without paying licensing (free-as-in-beer), and anything that needs to be added, they can redirect their internal AIX people to
develop. No problem releasing this under GPL, since not many people have a use for an AS/400 operating system without the AS/400.

Red Hat, on the other hand, has no hardware to recoup their 'loss' for giving away the OS. How are they making money? Red Hat's subscription
based Enterprise Network seems very similar to Licensing 6.0, where you pay an annual fee in order to get up to date fixes. Furthermore, they
advertise that what you pay for are the enhancements Red Hat makes to the system, including Kernel Enhancements, clustering, etc. These are only available through their subscription service. (see
www.redhat.com/software/whichlinux.html and
www.redhat.com/software/subscriptions.html)

I am not saying that they are wrong for doing this. I am simply pointing out that the free-as-in-beer model wasn't working out so well for them, and they migrated to something better. The server room is a very different environment than that of IA, though. Server admins expect to pay for everything. IA people, like most end users, want it for free.

>>>>>

> Until Linux is pervasive enough that the people willing to pay for
> software are using it, there will be a large vacuum for commercial apps.
> And without commercial apps, it will be extremely difficult to achieve
> critical mass around a free-as-in-beer protocol. Without a commercial
> interest, there is no way to buy your way into an existing protocol and
> implement it on Linux (unless you find an angel investor, but that is a
> whole different story).

I don't see "open protocol" and Linux as being synonymous. Any advantages of a truly open protocol for Linux would be equally great for Windows. The advantages of a truly open protocol (or set of protocols) would be that everyone can use it without restriction, and no one avoids it because they are afraid the licensing rules could be manipulated against them later. The open Internet has been good for Windows as well as good for Linux.

<<<<<

As I tried to point out however, an open protocol is the only one that Linux can get. Are _you_ going to pony up the licensing fee for DH+? What
about when you have to pay a per-distribution royalty to AB, but all your end users are demanding GPL code that they can extend and enhance, and _freely redistribute_? Buying into a closed protocol is simply not an option, leaving open as the only choice.

As you point out though, if a good, open protocol comes along, it may just as well be implemented on Windows, and capitalized on by whoever does it.

>>>>>
IBM exists to make a profit, and I hear they are doing quite well indeed.
<<<<<

By getting paid to support the hardware that they sell by giving away a popular OS. Not because of any income derived Linux itself. IBM is not a
bunch of idiots. They know what to give away in order to maximize their profit in their core competencies. If making Linux better than Windows means people buy an AS/400 instead of an HP machine, or a roomful of little NT boxes, you can bet that they will improve Linux just enough to maximize this benefit.

>>>>>

<snip>

You are confusing the "automation market" with PLC programming software. The latter is merely a subset of the former. There are sound business reasons at the moment why PLC programming software would target only the largest desktop
operating system. However, the engineering or maintenance office desktop isn't the entire automation market or even a very large percentage of it.
<<<<<

True, but the same can be said for SCADA software, HMI systems, etc. The majority of development is done on Windows workstations. That is a simple fact of life. Databasing is done using whatever the IT dept. has installed already (Oracle, SQL Server, etc.)

What systems are you refering to, that have less of a windows dominant market? I cannot think of any.

Please don't misunderstnd my motives. I would really prefer to be using a Linux system as well. In fact, I have a QNX box that is going into my next project which is there to eliminate a Windows 2000 system running WonderWare. I only need access from my PLC to a database, and the QNX box handles this nicely. Nonetheless, the critical mass is not there to justify commercial ventures into Linux, and frankly, the cost of staying with Windows is lower than the cost/risk of moving to Linux. At the end of it all, we need to convince the vendors that Windows hurts more than Linux. Once we can make that argument, the floodgates should open.

>>>>>

************************
Michael Griffin
London, Ont. Canada
************************
<<<<<

--Joe Jansen

By Jiri Baum on 25 April, 2003 - 2:12 pm

Joe Jansen:
> Nokia sells their phones to Cingulair, Verizon, and other service
> providers who then give them away to the consumer, binding the
> consumer into a contract in the process that insures that they will
> more than recoup their losses. The problem is that there is no
> "middleman" as it were in the Linux software deal. The software
> developers sell directly to the user.

Sure there are middlemen - they're called integrators. The only difference will be that instead of buying software from the Nokia-equivalent, they'll d/l it off the net.

Every non-trivial project needs an integrator; they are where the bulk of the programming and other work is being done, anyway. Whether the
integration is done in-house or outsourced, the work needs to be done, will be paid for, and the people who do it will have bread on the table.

The only people worse off for it will be the Nokia-equivalent, if they don't manage to ride it somehow, but relatively few people work for them
anyway (perhaps 5%).

|------------------------------------------------(begin sidetrack)-----|
... [Railroad Tycoon II from Loki] ...
> some of their other releases not only had rampant piracy, but people
> would hack their code to make themselves invincible during tournament
> play.

That's poor protocol design, of course: security shouldn't depend on the good behaviour of the client software. It's also poor sportsmanship :-)
|------------------------------------------------(end sidetrack)-------|

> IBM and HP both use Linux to sell their hardware. No secret here.
...
> No problem releasing this under GPL, since not many people have a use
> for an AS/400 operating system without the AS/400.

Much the same can be said for PLC programming (and other accessory) s/w: not many people have a use for it without the PLC.

> IA people, like most end users, want it for free.

So, then, what's the problem with it being free?

> As I tried to point out however, an open protocol is the only one that
> Linux can get. Are _you_ going to pony up the licensing fee for DH+?

One way to avoid this is to put the licensed stuff into the specialist interface card that most of the protocols need anyway. I'm not sure
about DH+ in particular, but certainly ASi, CANopen, ControlNet, DeviceNet, Interbus, ModBus+, PROFIBUS and Sercos can be handled this
way quite satisfactorily, and probably most others.

The firmware in the card then translates between the proprietary external protocol on the one hand, and the freely extendable, anhanceable and redistributable software on the other.

[about IBM]
> If making Linux better than Windows means people buy an AS/400 instead
> of an HP machine, or a roomful of little NT boxes, you can bet that
> they will improve Linux just enough to maximize this benefit.

And that's all anyone asks in the open-source world: improve the public pool of software just enough to maximise the benefit to you.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Higginbotham Ricky on 25 April, 2003 - 5:56 pm

A Couple of comments on the Linux thread, in response to Joe Jansen (Re: COMM: OPENC: Open communications in the doldrums [LONG!])

Regarding games, i think its considered common knowledge in the gaming community that the best online servers are dedicated linux boxes. Actually, many companies will release a dedicated server linux version before any other, so the servers are there waiting for people. Some companies like Id Software, release entire games (not just server side) for both platforms out of sheer generosity (they also tend to be some of the best in their jenre, id, Bioware, etc.). The games that don't require much horsepower are a
different story entirely, but there are many such games on Linux that were created for it (ie. not ports) as well. Linux gaming has further to go, but its not being ignored in the gaming community by any stretch.

Reguarding Thriftiness. Theres a lot of open source software for windows. There are many ports of high quality Linux programs to windows. Programs like The Gimp, which has about 90% of Photoshops functionality is available to windows users now for free because enough programers felt like it. I don't pay for most of my Windows software because I don't need to, try
www.download.com sometime. On the other hand I do pay for quality linux software, and donate money to the projects whos work I use, reguardless of platform if i feel they merit it. Another noteworthy organization is the EFF. Not $200 for every app, but no one really pays for windows apps either. In return, I produce GPL software which some people use, and guess what, they probably don't appreciate it very much either ;-). Such is Life.

You might have noticed that Control.com is powered by Zope. Zope is OSS, written in Python, which is OSS and uses many other OSS libraries and code I'm sure (medusa for one i believe). Outside of IA there is a very big world, close your eyes if you want, its still there. Theres a lot of OSS you don't see, that just works, for business and individuals.

I've pretty much given up on Open Source as a movement in IA. Not because of the Venders (who are mostly irrelevant in the face of , but because I think they users are too apathetic about thier problems and don't look into the future when thinking of solutions. They want to save money now, by shoddy designs, cheap materials, etc. etc. by and large.

Having said that, I use a lot of OSS in my daily work for which the companies I work for benefit greatly. Yet they don't feel the need to
contribute to the OSS projects who make it all happen. Now who's the tightwads?

Richard Higginbotham
speaking for me

By Michael Griffin on 26 April, 2003 - 11:34 am

On April 24, 2003 12:43, Joe Jansen wrote: <clip>
> As I tried to point out however, an open protocol is the only one that
> Linux can get. Are _you_ going to pony up the licensing fee for DH+?

As far as I am aware, if you buy a Siemens Profibus card, you can get drivers for Suse, Redhat, and Siemens Industrial Linux. I suppose that answers how to talk between machine devices - use Profibus. Plenty of people here will tell you it's a good choice anyway. As for how to talk between automation and IT systems, that field seems to be open. The debate seems to centre around whether it should be based on an industrial protocol like Modbus/TCP, or an IT protocol like XML.

> Are _you_ going to pony up the licensing fee for DH+? What
> about when you have to pay a per-distribution royalty to AB, but all your
> end users are demanding GPL code that they can extend and enhance, and
> _freely redistribute_? Buying into a closed protocol is simply not an
> option, leaving open as the only choice.
<clip>

I don't want open protocols because I want to extend and enhance communications drivers. I want open protocols because I want to eliminate market barriers for specialist companies to write drivers that I can buy. I want a small handful of protocols to emerge as the dominant ones without having them owned by someone who uses them as a club to beat their customers with.

> As you point out though, if a good, open protocol comes along, it may just
> as well be implemented on Windows, and capitalized on by whoever does it.
<clip>

The point of open protocols isn't Linux, or open source software or getting free stuff. All of these are of course nice things, but they are not the main reason. The reason why open communications are good is because it improves the probability that you will be able to get two things to talk to each other without a bunch of computers and magic boxes in between (if you can do it at all).

If all the companies that want to sell me stuff can swallow their pride and all support a common set of protocols my life becomes easier and my projects become practical.

>> You are confusing the "automation market" with PLC programming software.
> True, but the same can be said for SCADA software, HMI systems, etc. The
> majority of development is done on Windows workstations. That is a simple
> fact of life. Databasing is done using whatever the IT dept. has
> installed already (Oracle, SQL Server, etc.)
>
> What systems are you refering to, that have less of a windows dominant
> market? I cannot think of any.

Now for a slight digression. You are thinking about "automation software" as being PLC programming software or SCADA development software. However, this ignores the software running the machinery. Consider a typical custom computerised test system. The value of the software in a single such system will exceed the combined value of all the PLC (and similar) programming software in a typical factory.

When viewed in this context, it can be seen that PLC (or SCADA, etc.) programming software is marginal. If you want to promote Linux, open source, etc., etc., then don't worry about coming up with a substitute for Step-7 or RSlogix. Come up with the development tools and software components that specialist integrators would use to create custom applications. This (integrators) is the same type of market which Linux and open source was sucessful with in the IT world. Take a lesson from that.

--

************************
Michael Griffin
London, Ont. Canada
************************

By Joe Jansen on 28 April, 2003 - 3:56 pm

Having gone through the message from the weekend, I am going to attempt to consolidate several replies into one:

I wrote earlier:

>>>>>
Nonetheless, the critical mass is not there to
justify commercial ventures into Linux, and frankly, the cost of staying with Windows is lower than the cost/risk of moving to Linux. At the end of it all, we need to convince the vendors that Windows hurts more than Linux. Once we can make that argument, the floodgates should open.

<<<<<

Ricky H replied:

>>>>>
You might have noticed that Control.com is powered by Zope. Zope is OSS, written in Python, which is OSS and uses many other OSS libraries and code I'm sure (medusa for one i believe). Outside of IA there is a very big world, close your eyes if you want, its still there. Theres a lot of OSS you don't see, that just works, for business and individuals.
<<<<<

I think this hits right at the heart of the matter. In these instances, it has been proven that Windows hurts more than Linux, and things like webservers, game servers, etc all benefit more from the increased security, stability, and scalability than the pain that was inflicted in
initially porting them from windows, or the expense of writing it natively for Linux in the first place. These markets had to have a pain factor high enough to initially move from Windows to Linux, and once they broke that threshold, it was much easier to continue writing for Linux, since that initial barrier had been overcome.

Michael G wrote:

>>>>>
As far as I am aware, if you buy a Siemens Profibus card, you can get drivers for Suse, Redhat, and Siemens Industrial Linux. I suppose that answers how to talk between machine devices - use Profibus. Plenty of people here will tell you it's a good choice anyway. As for how to talk
between automation and IT systems, that field seems to be open. The debate seems to centre around whether it should be based on an industrial protocol like Modbus/TCP, or an IT protocol like XML.
<<<<<

I agree somewhat with this. Buying hardware cards that have the protocol embedded certainly solves this problem, including MAT supporting
DeviceNet, etc. What about protocols that run on ethernet, within a TCP/IP packet? (Ethernet/IP, for example). There is very little chance that someone will build a card that embeds the protocol and license, since it is plain old TCP/IP.

Now, we could just say that we let Ethernet/IP die on the vine, so to speak. However, Modbus/TCP is not going to solve all of our problems, and unless someone comes up with a truly open protocol, that is supported by others, we are back in the same situation. The protocol support isn't going to be free. It is a matter of where you pay the license. If you pay it when you buy a communication card, then OSS drivers are no problem.
If it uses a standard RS-232 or Ethernet port, where there is no comm card purchase, then OSS drivers become very difficult. And OSS is a big
motivator to the Linux side of the argument for IA.

Remember, there needs to be more pain in staying with Windows than moving to Linux. If the pain is the same, then no transition will occur. I am
becoming more convinced that any push to move to Linux apps has to start with this basis. AutomationX offers Windows and *nix versions of there software (IIRC). Perhaps Paul J. can offer us some insight as to what makes customers choose one flavor over the other. Paul?

Jiri wrote:
>>>>>
Sure there are middlemen - they're called integrators. The only difference will be that instead of buying software from the Nokia-equivalent, they'll d/l it off the net.

<snip>

The only people worse off for it will be the Nokia-equivalent, if they don't manage to ride it somehow, but relatively few people work for them
anyway (perhaps 5%).
<<<<<

The problem with this argument, of course, is that the Nokia-equivalent are the exact group of people that need to produce the software and
hardware to make Linux successful in IA. The fact that they are the ones with the biggest chance of 'losing' is exactly why they don't enter this market space; the point I have been trying to make all along.

This is getting long again, so I will wrap it up. Again, let me mention that I don't want to be painted into a "windows groupie" image, but I am trying to offer my opinions and ideas as to why the major vendors aren't pushing into the Linux market space. Hopefully by identifying some reasons and problems, we can work on overcoming them and get a better Linux/Windows comfort ratio....

--Joe Jansen

By Chiron Consulting on 14 May, 2003 - 2:29 pm

Joe Jansen wrote:
> Please don't misunderstnd my motives. I would really prefer to be
> using a Linux system as well. In fact, I have a QNX box that is going
> into my next project which is there to eliminate a Windows 2000 system
> running WonderWare. I only need access from my PLC to a database, and
> the QNX box handles this nicely. Nonetheless, the critical mass is
> not there ...
> ... frankly, the cost of staying with Windows is lower than the
> cost/risk of moving to Linux. At the end of it all, we need to
> convince the vendors that Windows hurts more than Linux.

I don't think we need to convince anyone of anything. The American/capitalist economic worldview assumes that consumers are rational actors making decisions that they perceive to be in their own best interest. At whatever point they perceive that Windows really is more painful than Linux is risky, they will start opting for Linux. We don't have any control over Windows' painfulness (although I have a certain amount of faith in Microsoft to keep moving in that direction).
All we in the Linux community need to do is keep lowering the riskiness of the choice to use Linux.

In the IA marketplace, that means having a capable, robust application toolkit that they can opt for.

Note, by the way, that I'm not insisting that the automation applications be Open Source. I'd prefer it, but that's not a precondition for the success of Linux in automation. If Wonderware ran on Linux, and people could pay for the Wonderware licenses without having to pay for the O/S, do you think people would run it on Linux? I think so. Not all of them, but some of them. And if their experience were successful, then more and more of them.

The biggest problem is getting the software built for Linux before there's a paying mass market for it. Which is what the Open Source movement does. It builds software for free, without expectation of monetary ROI. That helps feed the limited market for Linux software, the success of which grows the market demand for more and better Linux software. At whatever point the market is large enough, and wants - and is willing to pay for - software and/or support that the volunteer
community can't/won't provide, capitalist market forces will push the vendors to fill that void. Not because we convinced them, but because they can make money doing it.

"Build it and they will come."

--
Greg Goodman
Chiron Consulting

By Curt Wuollet on 24 April, 2003 - 2:45 pm

Hi Joe

Between your remarks and Mark's, both of which are uncharacteristically civil, which I much appreciate, we have a clear picture of why it can't happen. So are we doomed to fly blindly through endless upgrades and increasingly zany and irrelevent gyrations, with often conflicting
consequences, to accomplish factory automation? Do I take my football and go home? Are we confined to the set of solutions that most favor
the profitability of the vendors at the expense of progress and even sound engineering? I have committed my energies to change things for the better. Towards the elimination of problems and barriers that even the greatest of my
antagonists clearly recognize and acknowledge. I would consider any change in the things that we all mostly agree are bad for business a major accomplishment. The only cure I can see as having a track record of success in such circumstances is indeed a much larger role for Linux and software not controlled by any one entity. This puts me at odds with the (happy?) Microsoft users and I am flamed as thoroughly as I flame.

What I would like to discuss, is _any_ ideas on how to effect change. This could be a less contentious and more productive discussion. If my
ideas stink and offend, what are the competing ideas towards this goal? We all, perhaps grudgingly, agree that competitive deadlock is holding back progress and growth. And I think it's safe to say that no one's overtly proprietary, for profit, solution will solve the problem and gain universal acceptance among the aware.

Where do we go from here? How do we actually solve the problem?

Regards

cww

By Curt Wuollet on 18 April, 2003 - 2:12 pm

Hi Alex

I don't think you read what I wrote. You're putting words in my mouth again.

It would be impossible to recruit even 5 people who would join this MS fan club from among my friends. To recruit 5 people to write an Open
replacement would be far more constructive, since you simply can't build something Open that's based on closed, proprietary, perhaps patented, MS intellectual property. And, it wouldn't stand a snowball's chance of MS or large vendor adoption anyway.

The best that a membership could get me would be the opportunity to build compromised solutions
that further encourage the monopoly and friends.

And although I don't recall implying that anyone
was screwing anyone, (I haven't been to a meeting
so I don't know what they do there) it's a safe
bet they are all MS users and thus supporters of
the monopoly, willing or not. Is that unfair?
I leave it to the reader as to whether the best
interests of customers are served by more lock-in.
It's sorta like Henry Ford said: "They can have any color they want, as long as it's black" But I do apologize to the non-corporate members since they can't, apparently "create and shape the technology".

Regards

cww

By Alex Pavloff on 18 April, 2003 - 4:46 pm

Curt Wuollet wrote:
> It would be impossible to recruit
> even 5 people who would join this MS
> fan club from among my friends.
>
> To recruit 5 people to write an Open
> replacement would be far more constructive,
> since you simply can't build something Open
> that's based on closed, proprietary, perhaps
> patented, MS intellectual property.

Step back. OPC provides a way for any program, via a common API, to access anyone elses data. So companies like Kepware, Software Toolbox, and various automation vendors, large and small, write OPC servers which handle all the nitty gritty details of talking to devices. OPC _could_ be used as a protocol (via DCOM), but its not recommended. The OPC server normally talks
to the device in their preferred format, whether it be serial, ethernet, or something else. End result -- the accessing of data is decoupled from the use of the data. Vendors writing HMI and SCADA systems don't have to write drivers anymore, they can buy them from other vendors. Heck, if you decide that you don't like your OPC server, they're absolutely nothing to stop you
from getting one from a completely different vendor and using it with nothing more than a few lines of code changes.

These OPC servers are built on COM. COM objects can be accessed from any language from tools written by any vendor. The Borland and Metroworks, MinGW, and most all windows-based compilers in a variety of languages all support writing and accessing COM objects. The underpinnings of COM objects themselves are based completely on C++ vtables. For an extremely
good guide to COM, I recommend picking up "Essential COM", by Don Box.

I tell you this because you don't appear to have any idea what technology OPC is actually based on.

If you want to create an open replacement to it though, go right ahead. Until its done though, I think most people will just use the technology that already exists and is supported

> The best that a membership could get me would
> be the opportunity to build compromised solutions
> that further encourage the monopoly and friends...

<snip>

And we're back to anti-Microsoft. I'm not going to respond to that, because I think I've done it around 30 times before.

Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com

By Jiri Baum on 24 April, 2003 - 2:47 pm

Alex Pavloff:
> OPC provides a way for any program, via a common API, to access anyone
> elses data.
...
> If you want to create an open replacement to it though, go right
> ahead. Until its done though, I think most people will just use the
> technology that already exists and is supported

There are such projects underway, of course; in a couple of weeks, we should all meet in Belgium and discuss how best to join forces.

For now, all I can speak of is MAT, which provides a common API to access various protocols (for now we have only Modbus ASCII/RTU/TCP and
one vendor's cards supporting ASi, CANopen, ControlNet, DeviceNet, Interbus, ModBus Plus, PROFIBUS and Sercos), a BASIC-like scripting
language (python), HMI builder, the beginnings of a stepladder editor, PID module, and so on.

If you ask again in about a month, we should all have a much better idea of where Linux IA is going...

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Alex Pavloff on 25 April, 2003 - 11:38 am

> From: Jiri Baum
>
> Alex Pavloff:
> > OPC provides a way for any program, via a common API, to
> access anyone
> > elses data.
> ...
> > If you want to create an open replacement to it though, go right
> > ahead. Until its done though, I think most people will just use the
> > technology that already exists and is supported
>
> There are such projects underway, of course; in a couple of weeks, we
> should all meet in Belgium and discuss how best to join forces.

For some reason, I don't think I can get the approval and cash to fly off to Belgium in a couple weeks. :-) I'm curious though. Who is "all"?

> For now, all I can speak of is MAT, which provides a common API to
> access various protocols (for now we have only Modbus ASCII/RTU/TCP and
> one vendor's cards supporting ASi, CANopen, ControlNet, DeviceNet,
> Interbus, ModBus Plus, PROFIBUS and Sercos), a BASIC-like scripting
> language (python), HMI builder, the beginnings of a stepladder editor,
> PID module, and so on.

Well, you've provided one project. Good luck transforming that into a vendor-neutral API. I strongly believe that if you want to actually make
some headway in getting industrial automation in Linux, you're going to have do more than write some code and put it on a website. How much outreach have you done to companies creating industrial hardware that runs Linux?

> If you ask again in about a month, we should all have a much better idea
> of where Linux IA is going...

Tell me who is at this meeting and why I should pay attention.

Alex Pavloff -- apavloff@eason.com
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-- www.eason.com/5Koverview.htm --

> > Alex Pavloff:
> > > OPC provides a way for any program, via a common API, to access
> > > anyone elses data.
> > ...
> > > If you want to create an open replacement to it though, go right
> > > ahead. Until its done though, I think most people will just use
> > > the technology that already exists and is supported
Jiri Baum:
> > There are such projects underway, of course; in a couple of weeks,
> > we should all meet in Belgium and discuss how best to join forces.


Alex Pavloff:
> For some reason, I don't think I can get the approval and cash to fly
> off to Belgium in a couple weeks. :-)


It's a bit late to be organizing international flights, anyway, all the good prices are gone. (Not to say it can't be done, but it'd cost more.)

> I'm curious though. Who is "all"?
Well, all the open-source projects the organizers could find were invited; who'll turn up, we'll see.

> > For now, all I can speak of is MAT, which provides
...

> Well, you've provided one project. Good luck transforming that into a
> vendor-neutral API.
Thank you.

> I strongly believe that if you want to actually make some headway in
> getting industrial automation in Linux, you're going to have do more
> than write some code and put it on a website. How much outreach have
> you done to companies creating industrial hardware that runs Linux?
Some, but not nearly enough; we've been concentrating on getting the code working first... And, of course, our target audience is the integrators and end users as well as hardware vendors.

> > If you ask again in about a month, we should all have a much better
> > idea of where Linux IA is going...
> Tell me who is at this meeting and why I should pay attention.

Well, if we manage to merge half a dozen small projects into one big project, it'll have a much better chance of success, and therefore a much better chance of becoming a significant force in industrial automation.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri

By Anonymous on 28 April, 2003 - 5:22 pm

Dear Jiri,

You failed to answer very simple questions here.

> Alex Pavloff:
> > I'm curious though. Who is "all"?
> Well, all the open-source projects the organizers could find were invited; who'll turn up, we'll see.
>

Who was invited? If this is open source why are those you invited a secret. If the intent is to build confidence in this initiative then I would suggest you don't start by keeping the players in the closet. If there are real players to be had here then they should be showcased.

> Alex Pavloff:
> > Well, you've provided one project. Good luck transforming that into a
> > vendor-neutral API.
> Thank you.

Alex is right here again. This is not about providing ONE project. This is about providing a framework of tools and products that can be used to build automation applications. If your intent is that going forward every automation application will require that everyone involved be a C/C++ programmer then I think you might want to call it a day and get a job doing the "one offs" you are targeting.

And another important thing to note here and perhaps you continue to miss it. If you want this to be successful you must insure that the resulting products and direction CREATE momentum. Now what do I mean by that?

Part of the reason the automation market is what it is is that each product allows another to build upon itself. PLC markers create PLC. PLCs need I/O. PLCs and I/O need user interfaces. User interface need displays. And everything is glue together with a billion bits and pieces, wires, cables, connectors, relays, switches, etc...

All I'm saying is that a successful product is never a market onto itself. You must insure that there is a direction, a plan that makes all the segments of automation a player in the game. Yes some call it spread the wealth. If you intend to make a product that is all things to all people then you better be prepared to make connectors. Otherwise why should the multitudes of vendors really care? Yup it all comes down to one thing and I think Eddie Murphy put it best, "We all want to buy our kids GI Joe with the Kung Fu grip", and we can't do that unless we make real money.

Guess who?

Anonymous:
> You failed to answer very simple questions here.

> > Alex Pavloff:
> > > I'm curious though. Who is "all"?

Jiri:
> > Well, all the open-source projects the organizers could find were
> > invited; who'll turn up, we'll see.

> Who was invited?

Yes, I did fail to answer this one, because I didn't have the list handy
at the time. Here it is:

Open Robot Control Software
http://www.orocos.org/

Real-time Experiment Software for Linux
http://www.rtlab.org/

A Framework for Distributed Automation and Control
http://seg.clab.ee.upatras.gr/corfu/

Open Robot Controller Computer Aided Design
http://www.inrialpes.fr/iramr/Orccad/

Enhanced Machine Controller
http://sourceforge.net/projects/emc/

Real Time Controls Laboratory
http://sourceforge.net/projects/rtic-lab/

Dynamic Systems Library
http://sourceforge.net/projects/dslib/

Modular Architecutre Controller
http://sourceforge.net/projects/mca2/

Open Controller
http://sourceforge.net/projects/opencontrollerr

ClassicLadder
http://sourceforge.net/projects/classicladder

matPLC
https://sourceforge.net/projects/mat/

CANfestival
http://sourceforge.net/projects/canfestival/

> > Alex Pavloff:
> > > Well, you've provided one project. Good luck transforming that
> > > into a vendor-neutral API.
> > Thank you.

> Alex is right here again. This is not about providing ONE project.
> This is about providing a framework of tools and products that can be
> used to build automation applications.

Yes. We'll be in a better position to answer that in a couple of weeks, after the workshop, but that's exactly what we're aiming to provide.

> If your intent is that going forward every automation application will
> require that everyone involved be a C/C++ programmer then I think you
> might want to call it a day and get a job doing the "one offs" you are
> targeting.

Even just MAT itself can already be programmed in steplader mnemonics or python scripts. Indeed, stepladder mnemonics have been part of MAT for
years now (since mid-2000). No C or C++ required.

http://mat.sourceforge.net/manual/logic/il.html
http://mat.sourceforge.net/manual/lang/python.html

> If you intend to make a product that is all things to all people then
> you better be prepared to make connectors.

Yes, we're prepared to make connectors. So far, it's only ASi, CANopen, ControlNet, DeviceNet, Interbus, Modbus, ModBus Plus, PROFIBUS and
Sercos on the industrial side, but we're hoping to widen that.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Dick Caro on 16 April, 2003 - 4:02 pm

History from one who lived it, to those who might be doomed to repeat it.

MMS is an ISO standard that was created as a "companion standard" during the MAP craze of the early 1980's. The model for MMS was the Modbus set of commands. The MMS standard is actually constructed in an early object notation to isolate the commands from the actual underlying hardware of the controller. In this aspect, MMS was targeted to the same level as OPC/DA about 10 years previous to OPC.

FMS is the Application Layer of Profibus, and is an adaptation of MMS missing only the commands related to computer-to-computer transfers not
needed in computer-to-PLC transfers. FMS served as the model for the Foundation Fieldbus Application Layer during its development.

Since both Profibus and Foundation Fieldbus are widely deployed today, and both include FMS, it's not too difficult to find how MMS fits into
industrial automation.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

-----Original Message-----
From: Roger Irwin

...snip

> FYI: there is already an international standard IA protocol that
> supports robust data models that runs over TCP/IP. But, it is more complex
than Modbus-TCP. It's called MMS (ISO9506).

I keep running into this, I would appreciate further comments as I can never
understand wether it is still in experimental phase or has been ratified.
Opening up the argument what do other people think of this approach as an
enterprise or intersystem protocol.

..snip

By Ralph Mackiewicz on 16 April, 2003 - 5:02 pm

> I have re-visted the MMS stuff and, yes, this is complete and in use
> and suitable for use by the IA industry. But not adopted.

Actually, it is not widely adopted but it is adopted in some niche applications. There are installations using MMS and there are
occassional new installations in IA as well, usually involving CNC equipment. It is much more widely adopted in the utility industry.

> This is the level of interface I have been waiting for OPC/MIMOSA
> to come up with for the last two years. But if they never get
> there (and two years over schedule is a long time by anybodys
> standard) then will something like MMS or IDA come into
> mainstream IA like OPC DA has?

Good Question. I have no idea. It seems to me that the success of a new technology in this industry (as with the vast majority of
industries) is very dependent on marketing. I think one of the reasons for the success of things like OPC, Profibus, DeviceNet, etc. is the companies that back these technologies with competitive products. MMS was originally saddled with the baggage of the IEEE 802.4 broadband token bus of MAP that GM was pushing. Once support for this broadband stuff went away, there weren't enough vendors supporting MMS on Ethernet-TCP/IP for it to become widely adopted. And, after sinking literally millions of dollars into broadband modem developments, most of these vendors simply dropped the products completely (with a few exceptions) throwing the good out with the bad. There was also the issue of complexity. At the time, computing power and memory were very expensive. Today, the complexity of MMS is not that much of a technical issue anymore. However, most of the IA vendors are into pushing their proprietary developments into
standards, not pushing standards into their developments and most users don't seem to mind that approach. IDA does have some vendor support behind it so maybe it will work out for them. But I don't think you will see Schneider competitors jumping on that band wagon too quickly.

It's about time that model driven approaches are being brought to IA.

> The world shattering were my words, but look back at thier press
> releases and perhaps I was not far off;-) However, the intention
> was to make a standard that could work accross enterprise networks
> in an open and flexible manner, something their present standards
> fall far short of and for no fundamental reason.

The difference is that OPC was never intended to be a protocol. It started as an API. Their XML protocol based work is a recent development.

> I don't think a single protocol is either viable or desirable for
> all IA. In particular at a local level protocols such as CAN and
> Profibus DP serve requirements that are far removed from e.g. XML.
> OPC is still better than XML for the type of applications it was
> originally intended for such as interfacing a PC based SCADA to
> PLC's.

Actually, it was originally intended as an API that would isolate the applications (e.g. PC based SCADA) from the protocol drivers. I don't
think it was ever intended as a protocol except by some early advocates who claimed you could use the DCOM protocol for this purpose (which didn't work too well I might add).

> BUT, we do need a common protocol for exchanging between subsytems
> and from governing/monitoring systems to underlying subsystems.
> There are allready protocolls capable fo doing the data transfers,
> but we need a standard way to define the connections and have a
> common API. OPC has demonstrated the advantages of this.

OPC has certainly demonstrated the advantages of a standardized API. No question. It has made many of the protocol integration issues simply go away for Windows based systems. IMHO, OPC is one reason for the success of the Wintel platform in IA. By using an API to isolate an application from the hassle of dealing with a specific protocol from within that application, OPC has reduced some of the impetus for a common data exchange protocol. Ironic, isn't it?

Regards,
Ralph Mackiewicz
SISCO, Inc.

By Dick Caro on 15 April, 2003 - 3:37 pm

A little more on iDA. The complete first draft iDA specification is now published on their web site: www.ida-group.org This effort took place because none of the existing fieldbus protocols were sufficiently fast enough AND synchronous in their bus timing to accomplish a distributed synchro motion control network. iDA provides the speed via 100 Mbps Ethernet (as do others) and its synchronization via real-time publish/subscribe protocol.

The exciting news is that the iDA effort is now being lead by Schneider Electric as their successor to Modbus/TCP for real-time automation networks. Rather than develop their own "yet another protocol", Schneider has elected to back the previous user-led iDA effort. One of the most significant benefits of iDA is their object model for communications. This object model is based on IEC 61499, the same basic specification for function blocks on which IEC 61804 is basing their work. iDA does not specify their object
model, only the time-critical communications with automation objects. Good work with the right objective -- in my own opinion.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Peter Whalley on 16 April, 2003 - 11:52 am

Hi Roger,

A few (rather cynical) observations:

1. the IDA Group seems to be completely dominated by Europeans. This probably means that the US will totally ignore the standard however useful
it is.

2. whilst the standard is available for download, use of the standard requires permission in writing from the publisher (ie IDA Group e. V.) No information is given as to the circumstances under which such permission would be given or if any fees would apply or if permission could
subsequently be revoke of if use of the standard might infringe other peoples intellectual property rights.

3. when I try to download the membership application form my browser gives me an Error 404 (page not found) in German. Makes it hard to join or even to find out what the joining fees are.

4. The specification runs to some 435 pages which on the surface looks very complex and hard to understand. Hardly likely to encourage it's use.

Regards

Peter Whalley

Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

By Dick Caro on 16 April, 2003 - 4:54 pm

Peter,
The development of the iDA specification took about the same time as development of the Foundation Fieldbus specification -- about 1-1/2 years. During most of the development time, the entire team was German. All of the team members I met also spoke English quite well. One of the turning points in the iDA project was the influx of Schneider Electric in late 2001. This
had the effect of making the project take longer, but subjected iDA to a more thorough review. Schneider has announced that iDA is the logical
evolution for their own real-time networks to augment and supercede Modbus/TCP.

One of the key elements of iDA is their use of NDDS middleware for device synchronisation using real-time publish/subscribe. This is needed for
distributed motion controllers to perform coordinated multi-axis machine control. It is the same mechanism as used by Foundation Fieldbus in a less time-demanding application (process control). NDDS comes from RTI www.rti.com that makes it available on almost all computing platforms. RTI has submitted the mechanism of NDDS to the IETF as a pre-standards document.
As far as I know, it is the first time any real-time documents have been proposed to the IETF, the governing body of the Internet.

Siemens has been using Simatic Ethernet for a long time, but it is not compatible with Profibus. PROFInet uses Ethernet, but it is not for real-time applications. Recently, Siemens has expressed interest in iDA to have standard a real-time protocol that works with the Ethernet interfaces they have had in their PLCs for a long time.

I see a bright future for iDA if Schneider and Siemens build product for it.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Roger Irwin on 17 April, 2003 - 1:57 pm

I hadn't noticed the patent and copyright issues. Well spotted. Also, while the full spec does run to 500 pages, it is quite a comprehensive set of guidelines that do not need (indeed they do not suggest) be applied in paralell as an all or nothing solution.

The communications section is around 100 or so pages, and like I pointed out appears primarily interested in formalising data types and message packets and defineing a way to describe communications implemented in modbus TCP/IP, basically making it a more palatable and comprehensive solution.

Now to change tack, I would like to explain WHY I (and probably many others) need to break out of the OPC DA 2 stranglehold.

Like many people in this group a large amount of my work involves interfacing production systems to EDP systems. Following a peiod of uncertaintity in the wake of the .net hype, there has been a significant shift towards Java on the part of corporate EDP users (for backend servers, not desktops), and with it often a desire to use Linux/Unix solutions for back end apps. Yes there are alternatives to OPC, but nothing like it in terms of product support, whilst using OPC means putting in Windows boxes to house OPC servers and Java gateways/adapters. It is a silly situation and we need a way out.

Whilst windows remains the preodominant platform in the automation industry, IA needs a protocol that can bridge between the IA world and the EDP world, and clearly this must a protocol supported by BOTH sides.

By Ralph Mackiewicz on 18 April, 2003 - 2:33 pm

> Whilst windows remains the preodominant platform in the automation
> industry, IA needs a protocol that can bridge between the IA world and
> the EDP world, and clearly this must a protocol supported by BOTH
> sides.

If that is true, then you can give up on any solution based on Modbus. I don't see the EDP/IT world moving to Modbus. An attempt to put it into this environment would likely be met with stiff
resistance from the IT world. The IA market does not have much leverage on the bigger (much bigger) IT market. A more practical approach is the is to leverage the technologies that the IT world has already embraced.

Regards,
Ralph Mackiewicz
SISCO, Inc.

By Roger Irwin on 19 April, 2003 - 9:44 am

> If that is true, then you can give up on any solution based on Modbus. I don't see the EDP/IT world moving to Modbus.

Well I can access a Modbus/TCP/IP server from an AS400, or an oracle based system on solaris, or just about anything with sockets, with little effort. More to the point it would be quite easy to implement e.g. a modbus/TCP server in POSIX code that would easily adapt to any platform.

As has been pointed out, OPC was intended as an API and the use of DCOM to make it an enterprise wide access medium, is as everbody here points out, not satisfactory. That is why OPC proposed XML DA, but as this has been 'real soon now' for 2 years we cannot just sit back forever and say someday it will be arrive and it will work.


> A more practical approach is the is to leverage the technologies that the IT world has already embraced.

So instead of inventing a new protocol we leverage an existing one (modbus) which is capable of being used at an enterprise level and was designed as a master/slave protocol to allow computers to interogate field devices.

....switch......

open source and 'free' seem to have crept into this argument, not from me. If one actually read the title of the thread it implies nothing of the sort. I regard OPC to be an open protocol, and I do not mind paying for OPC products (heck, I have spent several thousand Euro over the last few months on various installations). I said they are in the doldrums because they are not coming up with goods they promised (despite the money).

On a final note I do not like the fact that many people claim that it is not OPC's fault that users attempt to use their 'API' for enterprise wide networking. We are festooned with OPC literature **especially** from certain major players in the OPC field, which tout it as such, and have been doing so for years. They used to say DCOM, for the last 2 years they have been saying that DCOM is not suitable but their XML DA standard, allready in beta and about to be released is their enterprise protocol. Deadlines come, deadlines go.......

( Complete thread: http://www.control.com/1026171355/index_html )

Ralph,

Now you know why Schneider created Modbus/TCP intended to be used with a web browser (port 80). It passes through the entire corporate IT world as "just another TCP/IP message". More elegant protocols such as Foundation Fieldbus HSE and EtherNet/IP will also travel on an IT network, but can cause problems if IT chooses to close their port numbers on their firewalls.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Chiron Consulting on 22 April, 2003 - 4:37 pm

> Now you know why Schneider created Modbus/TCP intended to be used with a web
> browser (port 80). It passes through the entire corporate IT world as "just
> another TCP/IP message".

Nothing I know about Modbus/TCP indicates that it's designed for use with a web browser. A Modbus/TCP message is "just another TCP/IP
message", but has nothing to do with the HTTP, the protocol supported by web servers and browsers.

> More elegant protocols such as Foundation Fieldbus
> HSE and EtherNet/IP will also travel on an IT network, but can cause
> problems if IT chooses to close their port numbers on their firewalls.

Ditto Modbus/TCP, which uses (by default) port 502, not port 80 (the default port for HTTP service).

Regards,

Greg Goodman
Chiron Consulting

By Alex Pavloff on 22 April, 2003 - 4:38 pm

Dick Caro wrote:
> Ralph,
>
> Now you know why Schneider created Modbus/TCP intended to be used with a
web
> browser (port 80). It passes through the entire corporate IT world as
"just
> another TCP/IP message".

I'm confused. Modbus/TCP is port 502, and doesn't use the "wrap in HTTP to punch through firewalls" trick.

Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com

By Ralph Mackiewicz on 22 April, 2003 - 4:45 pm

I understand that using port 80 enables passage of protocols through firewalls without requiring IT to specifically allow it. This does eliminate a barrier. However, I don't think that this will
necessarily make Modbus/TCP acceptable to the broader IT community. IMHO, if the IA community desires to bridge the gap between the IT and IA world, then the IA community should adapt IT technology because the IT world will not likely adapt IA technology. If the IDA people abstract the modelling information so that it can be mapped to an IT oriented protocol like http-XML, SOAP-XML, TIBCO, MQ, or whatever, then the probability of acceptance by the IT staff is
increased because the cost for them to deploy it will decrease. Requiring the adaption of an IA protocol like Modbus/TCP by IT staff may unneccessarily create a barrier to acceptance of the useful IDA modelling work.

Regards,
Ralph Mackiewicz
SISCO, Inc.

By Roger Irwin on 23 April, 2003 - 11:45 am

> I understand that using port 80 enables passage of protocols through firewalls without requiring IT to specifically allow it. This does eliminate a barrier.

Not much of one for me, my major problem is working with IT systems within an Intranet.

>IMHO, if the IA community desires to bridge the gap between the IT and IA world, then the IA community should adapt IT technology because the IT world will not likely adapt IA technology.

Exactly!

>If the IDA people abstract the modelling information so that it can be mapped to an IT oriented protocol like http-XML, SOAP-XML, TIBCO, MQ, or whatever, then the probability of acceptance by the IT staff is increased because the cost for them to deploy it will decrease.

OK.

>Requiring the adaption of an IA protocol like Modbus/TCP by IT staff may unneccessarily create a barrier to acceptance of the useful IDA modelling work.

Hmmm... This is where it breaks down. Modbus/TCP is
much less of a problem than OPC/DCOM, basiclly because it is very easy to wrap into any environment. Certinaly the XML-DA looks promising and **could** be a great step forward. But it is still vaporware and we have no idea what real world performance will be like, or how good the implementation is.

But let's look at the issue another way round, suppose the IT world were to be offered a cross-platform application level interface such as IDA or something analogous to OPC DA (I am talking about the very top level here). What would be the simplest and most acceptable technology to use to actually implement the interfaces? What is actually here and now and deployable? We have cited Modbus/TCP as an easy to implement and well proven technology (also the limitations are well known!), and we have cited MMS as a valid but more complex solution that is well proven in utility industry WAN's but not in IA LAN's.

We have also toched on Foundation fieldbus/FMS, as solutions we never gained popularity in IA LAN's despite heavyweight backing.

Any other contenders?

By Curt Wuollet on 24 April, 2003 - 11:27 am

We need a middleweight contender, focused on the job. Not warmed over office automation technology tightly enmeshed in one vendors schema having been designed for the purpose of replacing interoperability, or the grandiose "do everything" specifications that are too complex
to be well understood by mere mortals. But more complete than Modbus/TCP yet sharing it's attributes of piggybacking on the most successful protocol suite ever built. It needs to look like the other 99% of the enterprises network traffic so it's not "special" and can be managed with the same tools. And it has to be absolutely, positively, vendor neutral and free of submarine patents and any other discouraging commercialisms. It's easy to see how these goals can be met and equally easy to see why they won't. One need only look as far as the Medusa to
see this vital neccessity turned to stone. Obviously, it needs to come from the user community, not the vendor community. And it needs to be built from scratch. And the only possible way for it to meet these goals and avoid balkanization or subversion is for it to be GPL OSS and thus accessable to all equally and poison to those who would enhance, extend, and destroy it for competitive purposes. This is the only way that I can see to build something attractive enough to become truly universal. The reasons for the problems are painfully obvious. Everyone + dog, wants to own or control the next big thing, by any means neccesary. That's why the only moderately successful examples are owned by a
non-competitive entity. We've abdicated that role to a dictator as that at least brings order. If we replace the dictator with a publically and
politically supportable democracy, we have the basis to finally go forward. I'm very interested in other ideas of how this could be accomplished in the automation environment that prevails.

Regards

cww

By Roger Irwin on 25 April, 2003 - 11:46 am

Curt Wuollet wrote:
....
> to be well understood by mere mortals. But more complete than Modbus/TCP yet sharing it's attributes of piggybacking on the most successful protocol suite ever built.

So far common sense.

>It needs to look like the other 99% of the enterprises network traffic so it's not "special" and can be managed with the same tools. And it has to be absolutely, positively, vendor neutral and free of submarine patents and any other discouraging commercialisms.

Well I would agree with submarine patents but vendor neutral no. There is no reason why a vendor or consortium of vendors cannot propose a protocol, as long as it is published and achieves the goal of extending usage in general rather than trying to promote a particular vendors approach. I could cite many examples, one of which would be the extended POP3 protocol which many of you will have used to retrieve this message.


>Obviously, it needs to come from the user community, not the vendor community.

>And it needs to be built from scratch. And the only possible way for it to meet these goals and avoid balkanization or subversion is for it to be GPL OSS and thus accessable to all equally and poison to those who would enhance, extend, and destroy it for competitive purposes.

Now we are right of the rails here Curt! To start with you are clearly referring to a software implementation of a protocol. The protocol itself gets RFC'd or ISO ratified or just plain PUBLISHED without any non-disclosures etc. As the single vendor modicon did with thier modbus.

There is no reason why vendors cannot propose protocols, it is up to the buyers to decide to spend money on proposals that offer the most openness and interoperability. Of course we COULD then implement the protocol ourselves but we all know that if a good and proven implementation is available at a decent price then it is not worth doing.

I think the IETF is the perfect example of this. Both users and vendors have contributed to the common cause, and most people actually use commercially implemented software to wrap the basic goods. Vendors implement and enhance RFC's in order to enlarge the market. True, they open the market to thier competitors, but being involved at the standards level means they can get a (well earned) competitive edge.

IMHO, as a user I should be bullying vendors (by means of threads like this) into developing standards the way **we** want them.

By Curt Wuollet on 27 April, 2003 - 8:48 am

Hi Roger

> From: Roger Irwin
> To: AUTOMATION@CONTROL.COM
> Subject: Re: COMM: OPENC: Open communications in the doldrums
>
> Curt Wuollet wrote:
> ....
>
>>to be well understood by mere mortals. But more complete than Modbus/TCP yet sharing it's attributes of piggybacking on the most successful protocol suite ever built.
>
>
> So far common sense.
>
>
>>It needs to look like the other 99% of the enterprises network traffic so it's not "special" and can be managed with the same tools. And it has to be absolutely, positively, vendor neutral and free of submarine patents and any other discouraging commercialisms.
>
>
> Well I would agree with submarine patents but vendor neutral no. There is no reason why a vendor or consortium of vendors cannot propose a protocol, as long as it is published and achieves the goal of extending usage in general rather than trying to promote a particular vendors approach. I could cite many examples, one of which would be the extended POP3 protocol which many of you will have used to retrieve this message.

In a more rational world, I might yield the point. In other markets ,perhaps. But in this world where vendors have a track record of developing extensive, redundent, offerings rather than cooperate even within standards bodies, we have to remove their incentive for doing this. Since the rationale for so much redundency seems to be competitive positioning, I fear the adoption of a competitors scheme would be far less likely than something that is vendor neutral and beyond manipulation. If this wasn't the case, we wouldn't have seen the medusa rear her ugly heads. It took large amounts of time and effort for these folks committed to coming up with a standard, to determine that they simply couldn't set aside competition and let someone else win. To agree on a neutral standard would be a face saving way to save one hell of a lot of money and actually make progress rather than beating a team of dead horses that stand little chance of reaching the winner's circle.

>>Obviously, it needs to come from the user community, not the vendor community.
>
>
>>And it needs to be built from scratch. And the only possible way for it to meet these goals and avoid balkanization or subversion is for it to be GPL OSS and thus accessable to all equally and poison to those who would enhance, extend, and destroy it for competitive purposes.
>
>
> Now we are right of the rails here Curt! To start with you are clearly referring to a software implementation of a protocol. The protocol itself gets RFC'd or ISO ratified or just plain PUBLISHED without any non-disclosures etc. As the single vendor modicon did with thier modbus.
>
> There is no reason why vendors cannot propose protocols,

No, there isn't any reason that vendors can't propose whatever their heart desires. There seem to be very strong, in fact, insurmountable reasons why they won't be acceptable to other vendors. Or at least historically, haven't been. And I, as a party with no particular axe to grind, can't generate much enthusiasm either, because I know there's always a hook in there someplace. I applaud Modicon's effort with Modbus, but I still couldn't get clear, unambiguous permission to use it the way I need to. I got in touch with their lawyers instead. That's exactly what's wrong with commercial IP.

it is up to the buyers to decide to spend money on proposals that offer the most openness and interoperability. Of course we COULD then implement the protocol ourselves but we all know that if a good and proven implementation is available at a decent price then it is not worth doing.

> I think the IETF is the perfect example of this. Both users and vendors have contributed to the common cause, and most people actually use commercially implemented software to wrap the basic goods. Vendors implement and enhance RFC's in order to enlarge the market. True, they open the market to thier competitors, but being involved at the standards level means they can get a (well earned) competitive edge.
>
> IMHO, as a user I should be bullying vendors (by means of threads like this) into developing standards the way **we** want them.


We quite agree on that point, indeed that may be the only way it shall come to pass. I just wish more folks would join in. A free and truly Open alternative would accelerate this change of heart.

Regards

cww

Also, from one who has direct experience in communications protocol development --

I can think of NO communications protocol actually in use that was developed by an end user or even by a university research lab. Vendor participation has been necessary. Let's look:

Ethernet - Developed by Bob Metcalf and contributed to IEEE 802.3 by his company, 3Com and its partners DEC and Intel.

IEEE 802.5 Token Ring. Developed by IBM and contributed royalty-free to 802

IEEE 802.4 Token Bus. Developed by the 802.4 committee, most of whom were representatives from suppliers. The protocol was substantially the work of Tom Phinney, now of Honeywell, then a principle of Concord Communications.

IEEE 802 during these years was chaired by Maris Graube, then from Tektronix now at Relcom.

Modbus (all forms) - Developed by Modicon.

Foundation Fieldbus - based on ISA S50.01 and Type 1 of IEC 61158. The physical layer was led by Martin Zielinski of Emerson. The data link protocol produced by committee with the major portion by Tom Phinney, then and still at Honeywell. The Application Layer protocol was developed by Udo Dobrech, Siemens; Lee Neitzel, Emerson; Yasuo Kumeda, Yamatake; and many others.

Foundation Fieldbus HSE and Type 5 of IEC 61158 - Developed by an international vendor supplied team meeting at and managed by Foxboro and led by Lee Neitzel of Emerson.

DeviceNet, ControlNet, and EtherNet/IP - Developed by teams at Allen-Bradley.

ProfiBus - Developed by a German National Standards committee with major contributions from Siemens and Klockner-Muller. Profibus-PA had major contributions by Endress+Hauser.

WorldFIP - Developed by an industry/university consortium, but commercialized and sponsored by Telemechanique, now part of Schneider, and GEC ALSTHOM, now ALSTOM.

CAN - Developed by Robert Bosch GmbH and contributed to the ISO 11898 standard.

Interbus - Developed by Phoenix Contact.

Where would we be without suppliers creating network protocols for their own vested needs? Nowhere! Even the OPEN support groups created by suppliers has been for their own vested interest: it is necessary to open these protocols via a non-profit foundation or via standards to get them to be used by others. Is it difficult to get suppliers to cooperate - YES, but they eventually yield to the best interests of their customers.

As you can see from my list, eventually network protocols too fall victim to the process of natural selection. Some win and some lose. This is evolution at its finest.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Jiri Baum on 28 April, 2003 - 2:57 pm

HTTP (web) - CERN

NCP, TCP/IP (Internet) - ARPA

SMTP (email), FTP (file transfer), UUCP (early email, usenet news), gopher (predecessor of the web), DNS (Internet domain names), all sorts
of other Internet protocols - ARPA and/or various universities taking part in the Arpanet and/or others similar

Your list is strongly biased toward automation protocols; but then the complaint was that automation protocols are proprietary, so that fits. There's no technical reason why an automation protocol couldn't be as open as DNS or TCP/IP - but then vendors would actually have to compete. The cynic suspects they don't want that.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Dick Caro on 29 April, 2003 - 1:17 pm

Well, Duh! Of course my list was biased to automation protocols. Look at this list server - Automation List!

On the negative side, let's look at the user-led protocol efforts. General Motors heavy-handed their suppliers to support MAP (Manufacturing Automation Protocol). Schneider (then Gould/Modicon) spent millions, likewise Allen-Bradley and GE-Fanuc never to see any real return on their investment. The only good thing to come of MAP was MMS, and in turn FMS (Profibus) and
the Application Layer of Foundation Fieldbus. MAP was responsible for IEEE 802.4 Token Bus, on which Profibus was originally based. Thankfully,
Profibus-DP no longer uses the token passing built into its protocol except for redundancy.

However, I do agree that US Government mega$$$ can have major effects. All of the Internet protocols were developed as part of US DoD investment into DARPA (Defense Advanced Research Projects Agency) to develop the ARPAnet which became the Internet.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: RCaro@CMC.us
Web: http://www.CMC.us
============================================

By Tim Linnell on 30 April, 2003 - 5:21 pm

One of the defining characteristics of Automation protocol design (as opposed to the protocols Jiri listed) is the need to pass data very efficiently between devices at high speed with low system resources (e.g. microcontrollers with very limited RAM and ROM (say 1K and 32K respectively)). This requires focus and pragmatism during the design of the protocol, which committee based activity doesn't favour - it seems to me that the wider the potential application net is spread (which is an inevitable result of canvassing user support), the less effective (and successful) the protocols become, and the cost of implementation per device
increases.

It's interesting to note for example that although Profibus FMS was a full industry wide committee led development, it was not until a pragmatic decision was made to remove most of the layering and protocol niceties and allow direct access to the Data Link Layer, that Profibus DP was born and took off - FMS has effectively disappeared. Similarly, the bulk of DeviceNet
was designed at AB before being passed over to the ODVA for further development, and so retains a focused and coherent core.

It's an open question whether now we have cheap higher end hardware (e.g. PC) with more resources, devices will migrate to using higher level protocols. I suspect some will (just as many cheap printers have a direct Ethernet or USB connection) - it's also possible that PC type hardware will host clusters of what are today discrete devices to save on comms infrastructure costs. The potential problem with this is that it will tend to favour large one-stop shop vendors at the expense of niche experts, and so rather limit choice and excellence.

Interesting times.

Tim Linnell (Eurotherm)

By Curt Wuollet on 29 April, 2003 - 6:24 pm

Hi Dick.

I agree in principle that vendors can contribute to an Open process. And this has worked in general computing. The magic in "Ethernet" is it's use with the Internet or TCP/IP family of protocols. It loses almost all of it's luster when used with proprietary protos. My problem is that the altruism that made for this, most successful example seems totally lacking amongst the most likely vendors to contribute in our arena. And it has been demonstrated repeatedly. So it's not really whether they _could_ play by the rules for a widely accepted standard, but if they ever _will_. Any entity should be able to contribute as long as they work for the greater good. But commercial concerns with any hint of a competitive agenda are the kiss of death to a
universal standard. And I, for one, gratefully recognize your efforts and experience and courage in trying to do the right thing. You are certainly most familiar with the problem.

Regards

cww

By Roger Irwin on 29 April, 2003 - 5:51 pm

> So, I thought this might make a good topic of discussion for this group (which has a notorious reputation for heated discussion on comms protocols). <

Hee He...At least I got that bit right:-)

By Paul Jager on 3 May, 2003 - 2:44 pm

>automationX offers Windows and *nix versions of there
>software (IIRC). Perhaps Paul J. can offer us some insight as to what
>makes customers choose one flavor over the other. Paul?

Sure - Our Substation automation system for XJ in China is Linux. This is more for technical reasons. The code we need for input of Chinese characters exists in Linux for X Windows, but not for NT. I was recently in China for a week, our developers about 3-4. The story is here:

www.mnrcan.com/newsdetail.phtml?idno=37

The Chinese have quite a task to develop China's power system and they need the most advanced products but at very aggressive prices. I believe Linux can certainly help that cause.

The other installs we have with Linux are more for let's try it, or prevention of employees hacking & gaming. There are more Windows installs than Linux.

Regards,

Paul Jager automationX
-----
Paul Jager automationX

( Complete thread: http://www.control.com/1026170993/index_html )