SQL-Based Historian

Hi all,

I'm having a little bit of a "discussion" with a client, who we set up a SCADA system including FTHistorian for last year. They asked for an SQL-based Historian, and our Rockwell rep assured us that FTHistorian was SQL based. I now know that of course it isn't, though there are ways of linking it to an SQL server, which we've done. But there's just some rumbling about not being given what they asked for, and so my question becomes: is there any Historian package out there that natively stores data in an SQL database that we could have potentially offered them instead? I know packages like Ignition offer an SQL bridge module, or things of the same ilk, but as far as I know the actual historical database is not an SQL database.

Anyone know of anything?

Inductive: https://inductiveautomation.com/products/legacy/factorysql

Wonderware: http://software.schneider-electric....on-information-management/historian/overview/


Your Rockwell rep lied outright. Historian is and always has been based on the OSI Pi platform.

FactorySQL is a legacy product, Ignition and the SQL bridge module will store your data directly in SQL.
2 different methods -
1 using transaction groups is just straight up sql inserts/updates etc.
2 using the historian feature, Stores directly into sql but the table structure isn't what you're used too.

Hello,

ASF said:

Anyone know of anything?

Click to expand...

PeakHMI can record to SQL databases. The two most common, from my experience, are MySQL and MS SQL.

PeakHMI uses ODBC to read/write data to any database that supports ODBC. I have never run across a database that does not have an ODBC driver.

Rockwell's FT Historian is rebranded OSI PI. Which is the market leader in process historian. There are some people out there that does nothing but PI.

One thing that confused many even here is that the historian comes in two parts. The part that decided which data to keep and the part that stores the data. Rockwell didn't lie to you that PI can be access by SQL commands. Just about all historians store the data in some kind of SQL database.

The reason you need a historian portion for a process database is that you can't just poll data directly into a SQL server, otherwise you will blow up the server with tons of data. You need this front end to decide what data is worth keeping in conjunction with some kind of compression algorithm. You also need this front end to interpolate the data when you are doing the retrieving as well.

Another alternative

Another alternative that you may want to consider is to use an OPC archiver component that will read data from your existing SCADA system and transfer it to a SQL Server. I know there is a PI OPC Server. I'm not sure however if this OPC Server already exists in your FThistorian installation.

This way, you can keep the system you delivered and still meet your customer requirements. You can still take advantage of PI compression and also avoid overloading your SQL Server by selecting the data that they really need. I presume that they want to run SQL reporting services (or use other Microsoft BI related features) if they insist on having SQL server as historian.

The OPC archivers are generally low cost products. Here is an example:
http://integrationobjects.com/products/opc-data-archiving/opc-easy-archiver/

Hello,

k_w said:

The OPC archivers are generally low cost products. Here is an example:
http://integrationobjects.com/products/opc-data-archiving/opc-easy-archiver/

Click to expand...

No prices or I could not find any.

Thanks all, some useful info there. As far as "fixing" it, we've got it sorted - they have their data accessible via SQL - but there's was just a little bit of rumbling about the time their IT guys spent on it. So we don't have anything we need to rectify, it's all working, I guess I just wanted to know in hindsight, could we have offered them a different solution which would have natively stored the data in an SQL database without the need for any other works to get it there.

Thanks all!

For future information Schneider have 2 Historians that use SQL CitectSCada Historian(Links to the Citect Trend files for back fill capabilities in case loss of comms) and Wonderware Historian.