MatrikonOPC OPC Exchange


OPC and SQL

$id = 161; Posted on March 20th, 2008 by Eric Murphy

When discussing OPC, particularly OPC HDA, the question of OPC vs SQL/ODBC often comes up.  Although both standards deal with accessing data you usually see that OPC and SQL are used together in systems, rather than an either/or setup.   The primary design of OPC DA is for collecting real-time data in a standardized way from countless data sources and vendor products, spanning all industries.  Relational databases, which use SQL/ODBC are designed for storing data and provide standardized ways of accessing and retrieving the information (queries, views, table structure, etc).   Sounds like the perfect match to me!   Apparently I’m not the only one, since you will find many products that leverage the power of OPC and SQL.   Just recently Inductive Automation announced they will be bundling the OPC Tunneller with their FactorySQL product.   ‘OPC in, SQL out’ is a clear choice.

Where things can sometimes get interesting is the question of ‘OPC HDA out or SQL out?’   In order to answer that question, you really need to consider:  What data is being stored.  Who needs to access the data and why?  How is the data being used or presented?   In most cases, the answers really reflect the bigger question of ‘Relational-database or Process Historian?’  That’s a whole ball of wax I’d rather not get into.  Enter ‘historian vs database’ into the search engine of your choice and you can find papers fervently defending both positions.   Most arguments focus on speed, capacity, flexibility and suitability for a manufacturing environment.   As hardware and programming evolves these distinctions become increasingly more blurry.

The primary design of OPC HDA is accessing, updating and managing tag-based time-series data.   SQL is a standard interactive and programming language for querying and modifying data and managing databases, regardless of how the data is related.  Again the choice of which is better is a fuzzy choice to many.  Which is why there are products that give users the flexibility to decide: where to store their data and how to access it.   OPC HDA out of SQL/ODBC or SQL/ODBC out of OPC HDA, as well as ‘industrial relational databases’ that make use of OPC and SQL.

At the end of the day the choice is up to you.  As this article points out, you will probably end up with both.  

Those that want to know more details on how OPC and ODBC fit together might be interested in “OPC Gets Relational with Databases: Accessing SQL Server, Oracle and other Relational Databases Using OPC

2 Responses to “OPC and SQL”

  1. Anthony Ho Says:

    It is indeed a choice for the user to choose between OPC-HDA and SQL server. For me, SQL server based stored procedures and triggers have helped me to automate many historical tasks. I am interested in what UA has to offer or improve on the OPC-HDA.

  2. OPC Exchange Blog, Featuring Eric Murphy » Blog Archive » Mountain of SQL Power Says:

    [...] the new SQL server, code-named Kilimanjaro. One of the most popular topics on the blog is OPC vs SQL. A common argument in the whole ‘historian or relational database’ discussion is the speed of [...]

Leave a Reply

Please leave these two fields as-is:

Protected by Invisible Defender. Showed 403 to 988,919 bad guys.

For spam filtering purposes, please copy the number 7792 to the field below: