OPC for Building Automation
Automated Buildings OPC Interview
Many guys question OPC because of it's roots. A couple things I noted: "The OPC UA specification comes complete with security built right in, OPC UA becomes a efficient technology to use to provide secure robust transfer of data. Let’s not forget scalability. Since OPC is an open standard maintained by the OPC Foundation, it remains a scalable technology evolving along with industry demands. OPC UA is also completely backward compatible with the current OPC specifications, so no one has to delay projects because they want the newest flavor of OPC. "
That sounds like a great solution, but there would need to be a lot of interfacing between protocols. That sounds expensive?
Mandrusiak: That is the beauty of OPC technology. It was created to be cost effective. It easily interfaces with Johnson Controls devices, LON devices, BACnet devices, Modbus, PROFIBUS, the list is long. Member companies of the OPC Foundation devote considerable time and resources to developing robust interfaces to all the protocols used within the Building Automation industry, and then in keeping with the core values of OPC technology, make them off-the-shelf products.
Looking at our servers I can agree with this. They are "off the shelf", "cost effective" servers and their scalability is very high.
I think this OPC has some traction.
Last edited by sysint; 03-03-2009 at 09:07 AM.
URL need a fix (remove the last letter)
What's the unique offering of OPC UA that I cannot find in BACnet or Lon?
Well, the point is it doesn't matter if it's bacnet or LON, etc... Let's call it the Free Framework.
So, you can have multiple vendors products on top, and more than one. Further, it's a friendlier format for business exchange of information for reporting, energy, etc...
However, I can tell you that our servers move data quickly and are extremely scalable so accessing traditional bacnet and LON sites with OPC is not a bad idea. Put it alongside a tunneled and supervised system and it's no contest. Much faster. So, I think they are on to something.
Also, you can have multiple vendors on the Free Framework with low cost devices.
Last edited by sysint; 03-03-2009 at 09:34 AM.
A band-aid solution by your standard. Perhaps a nice band-aid, but a band-aid will always be a band-aid. Right?
Well, I think that if you call what you use a band-aid then yes it's a band-aid.
It's just that this band-aid moves data significantly faster and is much more scalable.
Think about it.... No supervisor necessary. Directly access multiple servers, multiple sites, multiple databases.
However, in our case our box fits in everywhere. LNS, frameworks, etc... So, from that aspect we aren't tying anybody down. For instance your system could grab the OPC or the LON. Plus you could use the IP852 routing. You have to admit that is very flexible solution with free software tools.
The point I'm trying to make is that the OPC is a good answer on top and allows for more cost effective "boxes".
Has anyone implemented UA on non-Windows? I haven't kept up with OPC, but back in the DCOM days you ultimately ended up with Windows issues that neither the client nor server vendor could repair. I remember when UA came out and thinking although this is XML, but it's Microsoft XML.
Well, our server isn't a Windows OS.
However, we do have a .NET app for visualization.
OPC is a bandaid...and will aways be a poor mans...clunky way to share data in and out of applications. Its not a cure all by any means. Legacy software still to maintain, supervisors and gateways. It turns into a kluster real fast with everyone finger pointing. People dont want that. And I doubt its faster outside of lab conditions or it could be reproduced effectively in a timely fashion in the field..job in and job out.
Originally Posted by sysint
Its a band aid that has no intent on expanding its overall capability...that will always be what it is.
To add... the scalable comment is laughable!
Well, I'll admit that DCOM was. This is much cleaner.
As far as scalable, honestly our boxes are significantly faster than yours and don't require a supervisor. Of course on the LON side you guys still funnel everything through the Neuron so you are limited right in the beginning. Maybe that's the bottleneck. It's like trying to suck up a lake through a straw. What do you think?
Why do you find it clunky? What makes data moving in your tunnel better on your platform? How many independent instances of companies using your tunnel?
We don't require a supervisor.... its nice for organization of certain things but not a necessity. A supervisor is just another station among the stations same as in each jace. The Niagara network talks at the IP level..JACE to JACE... JACE to Supervisor...etc
Originally Posted by sysint
All without the BS that comes with OPC.
I tunnel as a convenience to use legacy config tools. You Tunnel to get it to work. I have no need to tunnel for everyday use with the Niagara network. I tell Point A from JACE W to goto Jace X Point Z...Tell it how fast I want it to update depending on whats shared. Thats it, no third party crap to tell more third party crap to tell the obsolete Supervisory device to update a field controller ...then back again.
OPC is gay, Johnson went down that path 10 years ago...Its a PITA..all this while better solutions are readily available. OPC is a dead horse.
Seems to me somebody thinks the old boxes he was using were PITA and likes his AX significantly better...
How many JACE's points can you directly access and serve on a single page? I think some OPC benefits are the ability to source large amounts of data from multiple locations.
Sometimes I think you go rose-colored glasses mode on your stuff.
(Anyway- I'd like to push this back to an OPC discussion and not a product discussion - the article is from Matrikon and OPC foundation.)
Cant argue with that.
Originally Posted by sysint
Well OK - OPC XML/DA is working better than the previous methods.
Tags for this Thread