OPC-XML (was Difference Between OPC and DDE)

L

Thread Starter

Lynn at Alist

> Briefly, however, DDE or dynamic data exchange is a crude system for sharing
> and updating data between applications (typically) under Microsoft Windows.
> <clip>
>
> OPC formerly defined Object Linking and Embedding (OLE) for Process
> Control <clip>


I'm just curious. I remember when OPC came out, one of the big new "wonders" over DDE was that "it's binary, not ASCII". When OPC starts using XML & everything reverts to ASCII again, how much of a "step backwards" is this? Or is CPU power now so cheap we shouldn't care?

I don't know the size of average OPC-XML packets, but I know with UPNP (Soap + XML) it takes about 1500 bytes to turn on a single bit in a device, whereas something like Modbus/TCP would require 12 bytes to do the same.

Thanks - Lynn
 
C

Curt Wuollet

Hi Lynn

I agree completely. Very often, the vaunted benefits of the latest buzzword are totally irrational from a technical viewpoint. The real justification for all of these is: That's how Microsoft is going to (make) let you do it. Instantly, it's a great thing.

Regards

cww
 
R

Ranjan Acharya

I guess that is why we need gigabit Ethernet.

It seems to take longer to turn a bit on somewhere with just all the configuration hassles too. I have not noticed anything simple or fast.

R
 
F

Frank Iwanitz

Hi,

On June 14, 2003, Lynn at Alist wrote:
> I'm just curious. I remember when OPC came out, one of the big
> new "wonders" over DDE was that "it's binary, not ASCII". When
> OPC starts using XML & everything reverts to ASCII again, how
> much of a "step backwards" is this? Or is CPU power now so cheap
> we shouldn't care? <

OPC based on DCOM can only be used on MS systems (ok, DCOM is available for Unix to, but does anybody know OPC products?) and is limited to the intranet.

OPC based on Web Services can be used on any device/system and can be used both in intra- and internet.

> I don't know the size of average OPC-XML packets, but I know with
> UPNP (Soap + XML) it takes about 1500 bytes to turn on a single
> bit in a device, whereas something like Modbus/TCP would require
> 12 bytes to do the same. <

Passing a 4-Byte value takes about 20 bytes with OPC DCOM.
I did not count yet how much will it take with OPC XML. But it will be much more. The overhead with OPC XML is more or less linear, i.e. reading or writing a number of values at the same time will not decrease the overhead.

I do not know any figures that compare DCOM with Web Services or even DCOM OPC with XML OPC.

I guess stack runtime could be more or less the same for both technologies, i.e. encoding/decoding SOAP and marshalling/demarshalling DCOM packages. The difference will be found in transfering the information.

Regards,

Frank
 
R

Robert Holmström

Hi Curt,

From a technical viewpoint we have decided on another route. We use Linux on an embedded industrial computer. On this we have our web based SCADA software, Greyhound, which stores all data in the database (read and write values). We use an external SQL server (MySQL) to receive (push or pull) data from the distributed Linux platform. The SCADA system communicate with MODBUS etc. through software drivers.

There are good alternatives to OPC.

Robert Holmström
Botech AB
 
C

Curt Wuollet

And I'm glad to hear it! Now if we could just get some PLC manufacturers to see it that way....... I think making my own PLC will be quicker and easier.

Regards

cww
 
O

OPC Developer

Hi Robert,

What is your better "alternatives to OPC"?

In your email you state that you do this and that and use a driver to gather the data. What is the nature of the interface between your logging software and the driver? Can you drop in a driver from another vendor without writing any code or changing the driver in some fashion?

Look if we remove the "tragedy of COM" as you might see it, OPC is a standard that still allows multiple software products to share data in a fashion that does not require the user to be a programmer.

Can you give me URLs to specifications for an API/Client/Server architecture on Linux that accomplishes the same goals? I don't mean Corba by itself, I mean a truly defined specification, perhaps Corba based or something, that covers all of the same or similar functions as the OPC specification specifically in regards to the collection of Industrial/Process data? If you can PLEASE post the links here as I really want to know.

Additionally can you give me links to the vendors using this Linux equivalent to OPC so that I can determine the available market for a product targeted to the linux space?

I look forward to your reply.

Extra points if you know who I am.

Thank you.
 
C

Curt Wuollet

I find it fascinating that you characterise the fact that we have no choice but to use OPC as being beneficial. And that every other conceivable platform being excluded is somehow the fault of the Linux community. And the fact that the vendors would refuse to even consider an Open alternative is cast as something wonderful here as well. Why do you suppose there isn't Linux OPC? (well besides bad design). Since that's what MS allows, it's an exalted and wonderful thing. I give you kudos for making lemonade when handed lemons.

I can think of any number of better ways to transfer data with context that would be more efficient and an automation specific design from the ground up would do a lot more with a lot less. But, MS would never allow it and the vendors would never support it. I guess that makes Windows better than Linux. That's a very strange conclusion.

It's kinda like casting facism as a wonderful way to standardize world government. The people won't have any choice, but they'll all be in the same boat and universally miserable.

Regards

cww
 
OPC Developer:
> Hi Robert,

I'm not Robert, but...

> What is your better "alternatives to OPC"?
>
> In your email you state that you do this and that and use a driver to
> gather the data. What is the nature of the interface between your
> logging software and the driver? Can you drop in a driver from
> another vendor without writing any code or changing the driver in some
> fashion? <

I don't know what software Robert uses, but certainly the MatPLC can do
this today. No code writing or changing of the driver required.

Similarly, for local I/O (data acq. boards), COMEDI can do this today.

Your post makes it sound as though Microsoft invented something wondrous
with OPC; it didn't. It's obvious functionality.

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

Robert Holmström

In my comment I just stated that there are good alternatives to OPC. "Better" is your word, not mine. Our solution is just one. If the customer apply a LCC (Life Cycle Cost) analysis to the investment I am not sure that OPC will turn out to be the best solution in each and every case. Are you? Some programming might be a good investment. Like connecting the application to an SQL (MySQL) database that can retrieve values from other SQL databases (like our Linux system). As I said, this is our way of doing things. I am convinced that the customer will find the best solution to his/her need.

Sorry, but I am not looking for extra points.

/Robert Holmström
Botech AB

PS. Please read articles in next month's issue of AutomatedBuildings.com
 
O

OPC Developer

Hi Jiri,

Last time I checked Microsoft didn't invent OPC. I beleive a body of manufactures within the automation market got together to address a growing issue, that of driver development. The fact that they chose a Microsoft platform was based on their mutual use of that platform for a majority of the products they each currently had in hand. To have done anything else at the time the OPC specification was first created would have been ridiculous.

Now here we are seven years later and yes the world has changed to some degree. Wintel is no longer the only game in town but niether is COM as an underlying RPC methodology. I beleive that as the OPC foundation gets specifications like OPC XML completed, the opportunity to port existing OPC technology to other platforms will grow. At that point it will be up to individuals like yourself to determine whether pride or productivity is more important when that occurs. If there is still a bias against OPC within the Linux market after it is no longer dependent on an Msoft platform then vendors like my self will never have a reason to commit real money to the effort. What say ye?

If having a well developed, well tested, and well supported product is not important to the Linux side of industrial automation market then we should stop this banter about why there aren't more vendors moving to Linux. If I were to move my product to Linux but constantly lost business to the freebe code from a guy that hacked something together then whats the point?

Those that know me, have always know that I sell steak before sizzle. If the Linux market is happier with grisel then why should I try to port my product there?
 
M

Michael Griffin

On June 25, 2003, OPC Developer wrote: <clip>
> I beleive that as the OPC foundation gets
> specifications like OPC XML completed, the opportunity to port existing OPC
> technology to other platforms will grow. At that point it will be up to
> individuals like yourself to determine whether pride or productivity is
> more important when that occurs.
<clip>

I'm certainly willing to judge some future OPC system on its own merits if and when it ever appears. I must admit though being a bit sceptical about something that touts "XML" as being the solution to "openness" after having seen several XML schemas which are simply XML front ends to proprietary formats. It is quite possible to create systems using XML that are just as closed, proprietary, and platform specific as any binary format would be.

As for whether the XML version of OPC will be any more open than the existing one, the proof of the pudding will be in the eating, not in the acronyms.

> Those that know me, have always know that I sell steak before sizzle. <

"Those that know me"? If you are under the impression that your name is "Mr. OPC Developer", then it appears that even you don't know you. Basing your argument on your reputation seems a bit foolish when you don't even have a name. We here know no such thing about what you sell.

> If the Linux market is happier with grisel then why should I try to port my
> product there?
<clip>

I assure you that I don't feel that you are under any obligation to sell me anything. I would certainly be the last to urge you to enter a market where you don't believe you can be successful. Perhaps you ought to leave this market to others. Taking risks is always, well, risky and you may not feel comfortable with this. Indeed whilst I hesitate to speak on behalf of Mr. Baum or Mr. Holmström, I imagine they will somehow manage to get along without you.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
On June 25, 2003, OPC Developer wrote:
> Last time I checked Microsoft didn't invent OPC.
...
> Now here we are seven years later and yes the world has changed to
> some degree.

OK; I guess most of it was just accident of history, rather than some sinister plot :)

> I beleive that as the OPC foundation gets specifications like OPC XML
> completed, the opportunity to port existing OPC technology to other
> platforms will grow.

That would be good.

> At that point it will be up to individuals like yourself to determine
> whether pride or productivity is more important when that occurs.
...
> What say ye?

That'd be productivity... if OPC-XML is unencumbered, we'll use it.

> If I were to move my product to Linux but constantly lost business to
> the freebe code from a guy that hacked something together then whats
> the point?

Well, that's a different question; most likely, the point'd end up being the support and so on, with the product itself being GPL. After all, everyone agrees that most of the money (and work) in software and automation is in custom stuff and support. Your expertise would then lie
not in having the code, but in knowing which version of the software is good and where all the customization hooks are.

If your product is truly innovative, it might be better for you to keep it closed initially. That'd depend on the precise details. You'd also need to keep sharp, because the optimal thing would be to make it Open Source *just* before "some guy hacks up a freebie alternative".

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

OPC Developer:
Sodium Cyanide is a mature and well tested product but, regardless of your recommendations and widespread acceptance with very few user complaints, (there was really no other choice given) I respectfully submit that I might find valid reasons not to use it.

Regards

cww
 
R

Ralph Mackiewicz

This is exactly the kind of off-the-wall fanatical statement that only serves to marginalize interest in open source solutions. Anybody with the slightest grasp on reality is going to realize that any assertion that there would be a similiarity in outcome in the use of OPC and sodium cyanide is preposterous. I think an argument against OPC could be better made with silence than with this kind of blather. Widespread use and a whole bunch of happy repeat users are, in fact, some of the many valid reasons to use OPC. Wildly inappropriate analogies do not refute this.

Ralph Mackiewicz
 
On July 1, 2003, Ralph Mackiewicz wrote:
> This is exactly the kind of off-the-wall fanatical statement that only
> serves to marginalize interest in open source solutions.

Agreed, but, to make the obvious joke...

> Anybody with the slightest grasp on reality is going to realize that
> any assertion that there would be a similiarity in outcome in the use
> of OPC and sodium cyanide is preposterous.

why do you think they call it "blue screen of death"?

In most situations[1], I suspect all you'll get from OPC is an almondy
taste, with no aftereffects, like eating an almond cake or ice-cream.

There are specific objections to be had against OPC in particular, and
MS Windows and proprietary code in general; but I think those better be
left for another time and another thread.

Jiri
[1] With the obvious exception of safety-critical systems.
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C

Curt Wuollet

Hi Ralph

My point, is that is is equally "fanatical" to imply that OPC is Open and without IP concerns or would have ever been chosen if it wasn't based on Microsoft IP as no solution that is not blessed by MS will ever find it's way into their or their "partners" products. Further, implying that there can't be a good solution without it or that we are building junk if we don't adopt it sounds a lot like partisan propaganda to me. It's the only thing MS and their "partners" will support. That makes it "popular" in a sense. But it doesn't make it good. Or even desirable _if_ you had any choice. Which you, as a "MS and friends" user simply don't. Our community has the choice of supporting it or not. And more importantly _how_ we support it. It is my opinion that it should be supported, but should never become indispensible or crucial to an OSS solution as it is clearly under MS control. Unless you believe the propaganda. If you like your only choice that's fine. I would prefer to keep our options Open.

Regards

cww
 
R

Ralph Mackiewicz

> My point, is that is is equally "fanatical" to imply that
> OPC is Open and without IP concerns or would have ever been
> chosen if it wasn't based on Microsoft IP as no solution that
> is not blessed by MS will ever find it's way into their or their
> "partners" products.

The implication might not have been correct, but I don't think it was fanatical. I think it goes without saying that companies seriously committed to Microsoft technology would not have embraced OPC if it was not based on Microsoft technology. There is a difference between being wrong and being fanatical.

> Further, implying that there can't be a good solution without it
> or that we are building junk if we don't adopt it sounds a lot like
> partisan propaganda to me. It's the only thing MS and their
> "partners" will support. That makes it "popular" in a sense. But
> it doesn't make it good. Or even desirable _if_ you had any choice.

I guess we disagree here. I think OPC is good. The fact that it is widely used (popular) is one of the things that makes it good. People that choose Windows platforms will like the value that OPC brings.

> Which you, as a "MS and
> friends" user simply don't. Our community has the choice of
> supporting it or not. And more importantly _how_ we support it. It
> is my opinion that it should be supported, but should never become
> indispensible or crucial to an OSS solution as it is clearly under
> MS control. Unless you believe the propaganda. If you like your
> only choice that's fine. I would prefer to keep our options Open.

If you would have said this initially you wouldn't have gotten the hairs raised on my back. You may not think OPC is a good solution because it uses MS technology but using OPC on Windows is not suicidial. It is a good solution for many Windows based systems.

You guys should look at the platform independent version of OPC. There is a standard being developed for Component Interface Specifications as part of IEC TC57 WG13 in the IEC61970 standard. It is based on a submission from EPRI called the Generic Interface Defintion. It is loosely based on OPC but is platform indepenent. It follows from work performed at the Object Management Group (OMG) for the Data Access for Industrial Systems (DAIS) specification. The DAIS documents are available from http://www.omg.org. DAIS can be implemented without any of the dreaded MS technology. DAIS on Windows is (essentially) OPC. Makes everybody happy.

Regards, Ralph Mackiewicz SISCO, Inc. 6605 19-1/2 Mile Road Sterling Heights, MI 48314-1408 USA
T: +586-254-0020 F: +586-254-0053
mailto:[email protected] http://www.sisconet.com
 
R

Ralph Mackiewicz

> > Anybody with the slightest grasp on reality is going to realize that
> > any assertion that there would be a similiarity in outcome in the
> > use of OPC and sodium cyanide is preposterous.
>
> why do you think they call it "blue screen of death"?

OK, I will admit THAT was funny.

> In most situations[With the obvious exception of safety-critical
> systems], I suspect all you'll get from OPC is an almondy taste,
> with no aftereffects, like eating an almond cake or ice-cream.

In many systems, the equivalent of an almondy taste with no aftereffects is a fine solution. I think that there are probably a large number of users who would consider that the optimum solution.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
C

Curt Wuollet

Hi Ralph

From: Ralph Mackiewicz
> To: [email protected] Subject: Re: ENGR: OPC-XML (was Difference
> Between OPC and DDE)
>
>
>> My point, is that is is equally "fanatical" to imply that OPC is
>> Open and without IP concerns or would have ever been chosen if it
>> wasn't based on Microsoft IP as no solution that is not blessed by
>> MS will ever find it's way into their or their "partners" products.
>>
>
> The implication might not have been correct, but I don't think it was
> fanatical. I think it goes without saying that companies seriously
> committed to Microsoft technology would not have embraced OPC if it
> was not based on Microsoft technology. There is a difference between
> being wrong and being fanatical.

The biggest problem here is that it enforces an "all MS, all the time" assumption across all of packaged automation. This effectively prevents doing anything better without massive upheaval, which is exactly what MS policy is carefully crafted towards. Using their "standards" soon means that it's all MS or nothing. You can easily see that this is pretty much the situation. By this late date, no matter what weird direction they go and what odious licensing they adopt, most of the world we work in must follow. I find it very difficult to characterize that as a good thing for anyone but MS.

>> Further, implying that there can't be a good solution without it or
>> that we are building junk if we don't adopt it sounds a lot like
>> partisan propaganda to me. It's the only thing MS and their
>> "partners" will support. That makes it "popular" in a sense. But it
>> doesn't make it good. Or even desirable _if_ you had any choice.
>
>
> I guess we disagree here. I think OPC is good. The fact that it is
> widely used (popular) is one of the things that makes it good. People
> that choose Windows platforms will like the value that OPC brings.

And just what other platforms do they have to choose from? It's not a choice, it's a mandate. Show me a PLC line that allows anything else. (until I get mine done) Some choice!

>> Which you, as a "MS and friends" user simply don't. Our community
>> has the choice of supporting it or not. And more importantly _how_
>> we support it. It is my opinion that it should be supported, but
>> should never become indispensible or crucial to an OSS solution as
>> it is clearly under MS control. Unless you believe the propaganda.
>> If you like your only choice that's fine. I would prefer to keep
>> our options Open.
>
>
> If you would have said this initially you wouldn't have gotten the
> hairs raised on my back. You may not think OPC is a good solution
> because it uses MS technology but using OPC on Windows is not
> suicidial. It is a good solution for many Windows based systems.

If you don't mind being locked in forever and dictated to. As I said, you have to preface that with "since you are going to use Windows anyway". Walk a mile in my moccasins. seriously consider how difficult it is even to provide a choice. Don't you think there should be a choice? Supporting this situation is what allows it to continue. You'll have to pardon me if I don't automatically buy whatever they're selling.

> You guys should look at the platform independent version of OPC.
> There is a standard being developed for Component Interface
> Specifications as part of IEC TC57 WG13 in the IEC61970 standard. It
> is based on a submission from EPRI called the Generic Interface
> Defintion. It is loosely based on OPC but is platform indepenent. It
> follows from work performed at the Object Management Group (OMG) for
> the Data Access for Industrial Systems (DAIS) specification. The DAIS
> documents are available from http://www.omg.org. DAIS can be
> implemented without any of the dreaded MS technology. DAIS on Windows
> is (essentially) OPC. Makes everybody happy.

OPC in any form is Windows technology and probably covered by patents. It can't really be sanitized. If they disallowed it tomorrow, the industry would have to scramble to the next stopgap. That is control. The control that can only be exercised with monopoly power. How many automation people really want .NET? :^)

Regards

cww
 
Top