Real-Time Sanity has finally arrived!

Before OPC The extended nightmare!

Before OPC became a reality, getting information out of the PLC or DCS was a nightmare of horrendous proportions. Vast armies of programmers, spending countless hours of frustrating and confusing times writing low level interfaces to badly (or sometimes non-existantly) documented PLC or DCS systems. Just think of it, if there are say 100 PLC manufacturers, 50 DCS manufacturers and 50 SCADA applications. To cover all the SCADA connections to all the PLC's and DCS devices, you would need to write 7,500 drivers. Oh but it gets worse because each of the manufacturers has a number of variations and releases of the PLC and of course there are hordes of other devices like chart recorders, analyzers, single loop controllers etc.

So along came OPC and now (at last), most of the manufacturers of front-end devices have been forced to provide an OPC compatible server. Now you can just write a single OPC client device and theoretically connect to any of thousands of devices out there!

OPC had to happen:

It seems pretty obvious that a standard process interface was needed, so why did it take so long to get off the ground?

Well rumor has it that some of the larger DCS manufacturers really didn't like the idea of software companies putting whizz bang graphic interfaces on to their systems and getting all that business that they had targeted for themselves. Instead of opposing the idea, they were diabolically crafty and created confusion by agreeing with the idea and then dropped frequent tactical spanners into the works. Anyway, so much for cynicism and history....it is here now so let's see how we can use this technology!

What does OPC stand for and how is it structured?

OPC stands for OLE for Process Control. As we all know (chuckle, chuckle), OLE stands for Object Linking and Embedding and it is the law according to Uncle Bill as to how software components should be created so that they can talk to each other. So, OPC uses the accepted OLE technology and defines a set of routines that are specifically useful for the process industry. Now, if you want to link your application to thousands of different devices, all you have to do is swot up on what the OPC routines do, select the ones you are interested in, write the code that will link into the these routines and your application is connected to the real-time world!

What kind of routines in the OPC specification can you make use of?

As I mentioned above, each routine is tailored to the Process Control Industry. For example, you could make use of a routine that will return all the details of all the tags that the device has configured. Another routine allows you to specify a tag name and it will notify you if the value of that tag changes. There are now even routines that will enable you to get the historical data for a tag you specify from a starting time to an ending time.

The future?

OPC has taken far longer to evolve than it ever should have, but now we should start to see a rash of new, inexpensive applications coming out that link into any front end device. The same armies of programmers that used to spend their lives writing heartbreaking code for low level drivers will now be creating imaginative applications that revolutionize the process world. Certainly (without letting the cat out of the bag), that is exactly what we at St James Software have on the drawing board!

Click here to view our Price List.