Maybe I read in to far, but I see snakeskin oil vendors grasping for air! The piece is an obvious response to Steve Hechtman's very different article on the same topic (hosted on Control Engineering) - he should be flattered. You see, the big vendors, GE Faunc in this case, but the exact same applies to Wonderware and Rockwell have been long committed to the concept of Historians, a glorified and expensive datalogger that includes, and is only meant to work with, a custom version of Microsoft SQL Server (of all product choices...). The problem is that now much cheaper products from companies like Inductive Automation and Software Toolbox can do a better job using any RDBMS (database) system. Being vendor-neutral, inexpensive add-on packages also do much better for things like trending, reporting, and data analysis. The biggest mistake of the current generation of Historian is that they tried to implement and include everything themselves - like making a giant Swiss Army knife with a spork, usb memory stick, and a wine glass. Now they're caught with their pants down, desperately scrambling to recovery their enourmous sunk costs (my favorite business term).
- You're data is special and requires "plantwide historian" treatment...their example query “What was today’s hourly unit production average compared to where it was a year ago or two years ago?”. I won't even comment...
- Your database needs to speak specialized industrial protocols (OPC) - There's separation of function by design and for a reason. Besides - this doesn't even make sense.
- Faster speeds and higher data compression - no way! The historian is wasting CPU cycles in both directions, which obfuscates your data (can no longer use external applications), to do something better achieved by a RDBMS system that supports it.
- Robust redundancy for high availability - is this a joke? Maybe Amazon.com should migrate their server farms over to GE-flavor SQL Server.
- Enhanced data security - another losing battle for the historian. The white paper mentions SQL injection attacks - all platforms in question can use stored procedures, and are all subject to this sort of attack. When it comes to up to date patching, arguably the most common vulnerability, SCADA vendors have the absolute worst track record! IT keeps their servers patched as a matter of practice - they're typically afraid to touch the SCADA machines. Ultimately, the "do everything" approach provides many attack vectors.
6 comments:
A couple of years ago I did a project using a Rockwell product. The number of hours spent working my way around the product imposed straitjacket added a whole lot more to the project cost.
It was stupid things.. like having to dive down into the deepest levels of advanced configuration to tweak the SQL query to something a little more useful. Or discovering that their "web interface" was little more than an activeX object (only works with Internet Explorer) that downloaded a multi megabyte record set before doing internal filtering and producing a few lines of data.
In my experience most of these products work fine if you stay on the goat track. If you need to do anything that is a little different you get lost in the brambles.
I recognise that, for these companies, a complete software and hardware solution is a good entry point for many applications. When that product grows to be an expensive, "jack of all trades - master of none" type of product then it is time to call shenanigans.
Any software that can pass data though my choice of OPC/XML/whatever pipe to my preference of database/HMI/whatever gets my vote.
Hi Mr Surferb, Hi everybody
First of all congratulation for your blog. There is some topics and concern which are very relevant.
I am currently working on a Linux specification project which define a common way to exchange industrial data. This project may be interesting to you.
This project has been started recently. That mean we are in early stage of development.
We realize this project trough the freedesktop organization, because it principally concern industrial desktop software interoperability.
In few words, we will are writing a specification about how to use D-Bus for data exchange between Plc and Industrial Linux software. The final goal is allowing a set of heterogeneous software communicating together and access plant floor data, using D-Bus.
As a result of, D-Bus will also allow communication between industrial and desktop software.
I invite you visiting :
http://freedesktop.org/wiki/Specifications/DBPC
As I consider you as well informed about Linux and industrial topics, I am very interesting in having a feed back from you and will seriously pay attention to you opinion and comment.
Sincerely
Rey Cyril
Thanks for this good stuff. I like your blog very much. Your blog i full of informational content of digital download software. Actually i was searching for logo software download. In urgently i type download sofware. LOL .yeah i know thats funny and i find your blog.
Where is the White paper you refer to? I could not find a link to it.
Very informative blog, i enjoyed reading this one, thanks for sharing this to us, i'm looking forward to read more from your blogs.
tank level monitorings
Very informative blog, i enjoyed reading this one, thanks for sharing this to us, i'm looking forward to read more from your blogs.
tank level monitorings
Post a Comment