|
|
|
|
A Tale of Two Standards – OPC and ODBC
Many data consumers have different reasons for needing process and equipment data in a relational database. Relational Databases are the bedrock of ERPs, CMMS, Data Warehouses, LIMS and many other analytics and information systems. The tools that are built on those systems assume they are connecting to relational databases. Just as OPC delivers open connectivity to process and equipment data, databases benefit from open standards, in this case ODBC (Open Database Connectivity). Despite the fact that these two standards have very different histories, and solve different problems, they play very well together. Here are three different scenarios:
What if, as in the case of a recent phone call I had with a maintenance manager, you’d like to automate putting runtime data on your pumps into your maintenance management system? The great news is that the OPC standard makes it easy. By standardizing how we connect to controllers and equipment, OPC makes it easy for vendors to fill in the gap of getting OPC into ODBC databases. With, for example the OPC Client for ODBC.
Click below to learn more!
What if I have the opposite problem? I have data inside a database, control settings for a batch of new dies for example, and I’d like to push it to my controller or access it with my HMI? OPC and ODBC to the rescue again, this time in the form of an OPC Server for Relational Databases, transforming any database into a genuine, honest-to-goodness OPC Server.
Click below to learn more!
Okay. Third scenario. Third?! Yes. What if, I have a tool that I really love, which only understand ODBC, but my data is already being stored in a process historian? Well OPC and ODBC do another dance in the form of an ODBC Server for OPC, letting you write SQL-style queries to get data from any OPC-compatible process historian.
So keep your tools, and your historian. Whichever way you’d like to work OPC and ODBC, there’s something there for you.
Click below to learn more!
|
|
|
|