Databases – The Perfect Complement to PLCs, by Steve Hechtman

Interesting insight on the role of SQL and databases with PLCs and industrial automation.

Hosted at Automation.com,  Reliable Plant, FoodEngineering

Getting the most out of your SCADA system

I literally visited Inductive Automation the day before Gary Mintchell did. I didn't get the opportunity to meet him, but I did get a glimpse of his insight. He quoted the company as a "database company" - as a foundation, which is an insightful perspective.

Here's what occurred to me - I've been involved in big projects and small projects, private sector, government, and military running a variety of platforms. Does anybody have issues creating a tinker toy HMI with a few setpoints and graphics that change color? I really doubt it. Which vendor would I recommend for that? Who cares - they all do it. That's what Walt refers to about the commodization of HMIs.

So what's valuable and where are we failing? My top choice, and they are together, are "customizability and interoperability", something we tend to suck at. Suppose I asked, "how much power have we used so far this month". I'd likely get, "I donno - but you can figure it out if you keep a log of readings from that meter". Or - "what's the status on that shipment we sent out last week"? It's available on the Fedex/USPS web site. But why not on our information/SCADA system? Isn't that what web services is all about? Who are we kidding - we have enough issues migrating/tying in our legacy systems. I bundled "customizability and interoperability" together because the point is to be able to tie your system to others easily. Managers shouldn't have to buy hardware and large amounts of integration services to make their systems work for them.

Great! So how does this work? The key is being able to pass data - through standardization. This is where technologies like OPC (UA) and web services come in. But another huge, often overlooked method is using SQL databases. Most applications, and nearly all business systems use them natively. You want to know anything about your process - inventory, QA, for example - past or present. That should be available in your SCADA system. It's a great connection point, provided that it's flexible, which is Inductive Automation's strength. Get that SCADA vendors - hint, hint - step away from the custom Microsoft SQL Server implementations! The royalties are great, but nobody belives that you need them for performance. Besides databases are useful for other reasons than being a historian! It's not hard to support Oracle, MySQL, DB2 and others - just swallow your pride and old company lines.

How do you get your existing or legacy system to interoperate with others? Simple, OPC <-> SQL database bridges exist for that purpose.

SQL Standards. And standards.

Who comes up with this shit? Seriously? Is it human nature to try to make everything your own, or a flawed side effect of our culture? (In that case it's royalties). I'm talking standards, of course! Why can't we all just get along? Consider SQL. We like SQL! It's simple, powerful, and has proven to be conducive to interoperability. Don't believe me? Check out all the database frontends that work with so many "flavors" of SQL. There are innumerable database driven applications that could run on any. Why is it so hard to get along? We've got ANSI and ISO SQL (think 7 layer OSI reference model - let's implement that...right...?). Microsoft's gotta be different from Oracle, and MySQL, and IBM DB2, and PostgreSQL - and they're all subtle-ly (is that a word?) different from each other! Cumon M$, why do you have to use the TOP keyword instead of LIMIT to limit returned record sets? You know your programmers could efficiently implement both? Can't just pick on Microsoft, though - they all do it! Going to a unified, or standardized language set, while maintaining backward compatibility, really shouldn't be that big an issue. Everyone's products will be the better for it.

Let me tell you about designating quality codes for object overlays when designing SQLTags in FactoryPMI. We could have chosen whatever quality codes we wanted. My birthday could have been a tragic error! But we chose to follow OPC convention. Why? Standardization. I have no idea why 192 is the quality code for good data. But someone smarter than me said it would be. And so it went...

I was prepping myself for a long rant about standards - I was going to tear Sony a new one. But I'm tired. I'd rather go to sleep.