Man I hate OPC. It just feels like software plumbing gone overboard in the COM based architecture it uses. The term “software plumbing” is used to describe software thats forms the basis of software that people (realy people, not developers) actually see. Software plumbing is important as it needs to be establish for the rest of the structure gets built, though I’m sure the analogy is being taken too far here.
I’m currently working on an OPC application that leverages the Technosoftware C++ API that sits on top of OPC to simplify the OPC development somewhat. It does this, but because of leaky abstractions, there is need to delve into the library code where it interacts with the OPC interfaces directly. It just seems the combination of COM and C++ result in butt ugly hard to do understand code. You hear/read old Microsofties talking about the wonderful COM architecture (COM is love and all that sort of thing) and wonder what the hell were they smoking? It reminds of the STL in that some developers think its a paragon of API design, but to me its difficult to use and difficult to read. Anyway, I’m heading off into bile blog territory here. So back to why I started this blog post…
The Technosoftware OPC C++ Client API treats OPC DA 2.0 and 3.0 servers differently and runs different portions of it’s implementation depending on the OPC version. Its difficult to get access to many OPC servers which require entire systems to practically operate e.g. Yokogawa EXA. Hence there is a need for OPC simulation servers. The one simulation server I’ve found that delivers solely a OPC DA 2.0 interface and sufficiently functional to use in development/testing is the OPC simulator found at http://www.dsxp.com.
