In my last post, I linked to Sharon Rosner's blog where he talks about a new product from his company and rants (that's a Web term, by the way) about OPC. One reason I linked is because Rosner gave voice to objections I have occasionally heard about OPC. I feel that OPC is one of those technologies that attracts detractors, in part due to an anti-Microsoft bias or just flat out misunderstanding. Unfortunately, I am not, on my own, capable of setting the record entirely straight. I have written about OPC in Automation World, and there will be more to come. But, I figured I'd get a response, and I did.
This is from Tom Burke, executive director of the OPC Foundation.
OPC exists because the people who deploy automation systems do not want solutions that tie them to a single vendor. Single vendor solutions inevitably cost them a lot more in the long run. The original set of OPC specifications were based on COM because COM was a widely available technology that made it possible for independent vendors to develop interoperable software. For the most part, OPC has succeeded in achieving its goal of giving end users choices when they purchase or upgrade their systems.
That said, COM and DCOM are not perfect - the DCOM protocol is not robust enough for many automation applications and support for COM/DCOM on non-Windows platforms is limited. In addition, the artificial distinction between real time process data, alarms and historical data created by the separate COM specifications made OPC solutions less elegant than some proprietary systems. For these reasons, the OPC Foundation is developing the Unified Architecture (UA) specification.
UA is a service-oriented, platform independent architecture that allows application developers to expose all of their process information within a single cohesive framework. UA leverages the latest web service technologies in a way that can meet the diverse requirements of automation industry. More specifically, UA does _not_ require that all applications communicate via XML messages. Instead, UA incorporates an efficient, interoperable binary protocol that is easy to process and small in size. In addition, UA creates an abstraction layer that hides the physical protocol from the application developer. This means the same UA application can be deployed using pure XML messaging in environments where XML on the wire is a key requirement or it can be deployed using the binary format in environments where performance a key concern.
I think there are a lot of good things coming in the future for manufacturing communications. When I mention microformats like RSS, Atom, AJAX (Asynchronous JavaScript and XML) and the like, there are knowing nods from technologists. These technologies will build upon what is already a widespread communications technology. These things take time to work out. Expect to see more this summer.
4:14:15 PM 
|
|
