Rethinking SCADA Software

One of the hardest things I'll ever do is try to explain what Ignition is because it can do so darn many things. This is frustrating for me because I want to tell people all about everything Ignition can do -- and I could overwhelm a person fast. It's sort of like trying to explain what a car is to a pioneer who has never seen one before, and you say, "not only can you drive across the Sierra Nevada mountains in an hour but you have windshield wipers in case it rains, you have this moving map to keep you from getting lost and you can listen to all your favorite music in stereo while you cruise 70mph over the hill." Man, he hasn't even comprehended what a car is yet.

Hopefully this video solves all of that and gets right to the point. If you want to share this video with someone else, paste this URL into your email: http://www.youtube.com/watch?v=7RWmfIVDkN8

"Softwar" - the future of MES and SCADA

Hate to keep beating a dead horse. This is really funny unless you happen to be the one getting hit with punitive upgrade fees.

Actually, all these per tag, per client, per designer seat, per database connection licensing models are history. One big SCADA company "graciously" got rid of their per tag licensing model only to replace it with a per screen licensing model. Thanks for the "help" – probably the most liberal licensing model to come along in SCADA in the last ten years (except for Ignition, of course!).

Truth be told, the whole client-server model of MES and SCADA is on an evolutionary dead end. Not my words – those belong to Larry Ellison, except he was referring to IT practices of ten years ago. Softwar is a book about Oracle and Larry Ellison (its CEO and main founder) . It's one of my favorite books because it's a blueprint of things to come in our industry. There's an uncanny parallel between Ellison's predictions of ten years ago for the IT industry (which have come true) and what's happening in our controls industry today. You should read the book.

So what was Ellison saying? He was saying database centricity was the only viable model. He said the client-server model only distributed complexity and was an unsustainable model. He said it was on an evolutionary dead end. As I read those words I was saying "Yea! That's what I've been saying all along!" Only he said it first and history has proven him right.

Ellison was also talking about his rationale for the Oracle eBusiness Suite. He reasoned that all applications at the ERP level should have a common data store, common data schema, common user interface and should deliver common business processes "out-of-the-box." This would prevent data fragmentation, unsustainable support requirements and eliminate the cost prohibitive modifications required to make heterogeneous applications work together (though poorly).

This is exactly what we're doing with the Ignition MES Suite. You haven't seen the whole suite yet – just scheduling, production, downtime and OEE so far. But in the coming year and just beyond, expect to see the most impressive suite of MES functionality available anywhere and completely in alignment with these principles.

We go one step further though with our licensing model because you just pay for the server. Then you can develop with the included web-launched designer, web-launch as many clients as you want, create as many projects as you want, use as many tags as you want and never be constrained again. Everything that applies to our unlimited SCADA suite applies to our MES suite too. Go for it!

What's wrong with MES?

What is MES in the first place? Otherwise known as manufacturing execution system, it's a collection of applications sitting just above PLCs on the plant floor and just below ERP systems like SAP, JD Edwards, or Oracle eBusiness Suite. And therein lies the problem; as a "collection of applications," each one has its own data silo, data format, user interface and support requirements. These are apps like scheduling, production tracking, downtime tracking & OEE, quality assurance, recipe management, genealogy, maintenance maintenance management and a host of others. If you could just get them to play together it would be great.

Most of these applications have been developed by different companies, so getting any sort of consistency and interoperability is nearly impossible. That is especially true of the big "we have it all" vendors because nearly every one of them got their applications by buying smaller companies. So in actuality, each of the parts are incompatible.

Consider for a moment what it would be like if these did play well together. Maintenance management would know what production scheduling was up to and vice versa. If QA was putting product on hold then scheduling would know right away so that they could schedule something else until the problem is fixed. Line operators would know what is planned for the day. There are endless ways to gain efficiencies when every app is seamlessly interconnected by a common data store, common data format, common user interface and uniform support requirements.

A kludge of heterogeneous MES apps is also expensive to install and maintain. Attempting to make apps talk to other apps could cost months of labor for integration, testing and debugging. The IT support required afterward would be beyond burdensome because no app is like any other from a technical standpoint.

When selecting MES software it would be wise then to look at the big picture. First, consider all the apps that your organization could ultimately benefit from and then ensure they form a suite of products designed from the ground up with a common data store, uniform data format, uniform user interface and with uniform support requirements. The payback to your company could be handsome if this simple guideline is followed.

Ignition Mobile - The Backstory

You will soon see announcements about the Ignition Mobile Module. But in this post I want to tell you about the behind-the-scenes action leading up to its development.

For over five years, mobile access has been the most requested item for Ignition – overwhelmingly so. It's not that we took so long to develop it, but rather, we weren't settled on the best way to go about it. We didn't want to jump off rashly into using a poor model or short-lived technology that we would later regret using.

We hadn't settled on our approach until recently. The final product (which is still in beta testing) makes it look so simple, but what we've done behind the scenes is unprecedented. Ignition Mobile is based on the HTML5 canvas element. It can run on iPhone, iPad, iPod, Blackberry 6 or any Andriod-based device such as the Droid, DroidX or HTC smartphone. It doesn't require the JRE or any sort of plug-in at all.

The best part of all is that you don't need to develop separate special screens (unless you want to) because the screens you develop for standard deployment can be used for mobile as well. You can zoom and pan your existing applications such that even the most densely populated screens can be viewed and interacted with in amazing detail.

Technology Decisions

So how did we get there? We considered quite a few technologies because settling on the right technology was vital. Consider if we had selected Flash as our technology in light of Apple's recent decision not to support it on mobile devices. Silverlight Mobile technically holds promise but since it's likely to remain proprietary, and given Microsoft' proneness to abandon technologies in favor of newer ones every four years or so, we didn't think that was a good choice either. We considered many, many ways to make mobile and vacillated all over the place for years.

Finally I laid down some criteria: 1. Must be able to run on any modern mobile device. 2. Must not require a plug-in. 3. Must be able to reuse existing applications and not require duplicate mobile app development. 4. Must support zoom and pan. 5. Must be based on open standards. 6. Must be based technology that holds the best promise of longevity. 7. Must be secure. 8. Must be a simple to install module with near zero configuration.

Once those criteria were laid down things really started to move fast. Like I said before, we make it look easy, but there's a lot of technology behind it. In essence, when you launch from a mobile device it actually launches it on the server in the headless mode (resides in memory instead of going to your monitor). You can launch any number of these but you do use server resources, unlike the normal deployment model. What you see on the mobile device then is a picture of the application running on the server updated in real-time. Your clicks and other interactions are then fed back to the client application running on the server.

This is sort of like VNC but it doesn't project the desktop, only the application. And it does it into a webpage via the HTML5 canvas component. The canvas component is very fast and it allows you to zoom and pan for those devices that support that.

Surprised by the Results

Now we've got people running all over the office with cell phone in hand showing off the coolest new things in Ignition Mobile. Frankly, we did have our doubts this technological approach would really work. We didn't think it would be responsive enough. But in our early proof-of-concept testing we were left ecstatic because it worked so well. But as always, the devil is in the details. There have been many technological challenges while perfecting this technology but we've overcome them.

We really hope Ignition Mobile will generate as much excitement outside our office as it has inside. It is targeted to be available January 25.

Where is the 'c' in MES?

Back in 2002, I saw the acronym cMES a lot, but now it's just called MES. So I got to wondering, what happened to the 'c'? In case you don't remember, the 'c' stands for collaborative. When I searched for the term recently I came up with only a few references, which is surprising. But then I got to thinking, MES is a more appropriate term anyway because most MES software is anything but collaborative.

MES, of course, would include applications like scheduling, downtime tracking, OEE, quality assurance, maintenance management and numerous other applications which facilitate better coordination and management of the plant floor. But to do this effectively each separate function needs to collaborate with the other, as well as with each of the stakeholders such as maintenance people, the production scheduler, quality assurance, plant floor operators, the plant manager and so forth. MES should be all about collaboration.

This would imply having a shared data scheme between applications, having a single source user authentication, being able to switch quickly between applications, and having the ability to easily interconnect with various data sources and databases as well as ERP systems. It also implies having the ability to give any stakeholder access to the system from anywhere (without technical or licensing restrictions).

MES systems that fail on any of these points will be short lived and be of limited usefulness. Those that embody these points can be credited with putting the 'c' back into MES and the winners will be the manufacturers that use them.

Stuxnet and Common Sense

The Stuxnet PLC/SCADA virus saga keeps getting deeper. If you haven't been following the story, you can read this Wikipedia article about it. The Wikipedia article skirts around what the ultimate objective of the Stuxnet virus is but this AOL News article minces no words.

It's all very interesting, but essentially the virus exploits various software vulnerabilities and thereby modifies the PLC program that controls high frequency VFDs found only in uranium enrichment centrifuges. Its purpose, according to the AOL article, seems to be to over-speed the centrifuges momentarily so as to destruct the rotational parts.

I have just one question, why wasn't the PLC program password or keyswitch protected against program changes? In a sensitive application like this, why not? Control system security is mostly a procedural and implementation issue. Yes, network traffic should be encrypted. Yes, user authentication should be centrally managed along with other IT applications. But no matter what, any system can be compromised when common sense goes out the window.

Common sense is important and there is no one-size-fits-all solution. I see it just like a personnel safety system implementation. A risk assessment for the situation is done and vulnerabilities are evaluated, then an appropriate solution applied. And it is a continuous improvement process that adapts the system to new conditions as discovered.

In a safety system risk assessment the first step would be to determine, in a worst case scenario, what the loss would be. Death? Personal injury? Machine damage? Product damage? And in the latter two, how much cost? Similarly, you would first do a risk assessment for SCADA or PLC security. In fact, the parallels between a safety risk assessment and security risk assessment are uncanny.

The recent TSA enhanced pat-down for pilots is an example of the one-size-fits-all mentality when it comes to security. I sure hope it doesn't come to that for SCADA systems. The right answer is to approach SCADA security the same way safety has been approached in our industry for many years.

Today, even a kid could install Ignition

We have been, since the beginning, fanatical about delivering greater and greater user friendliness. I wanted, and demanded, an installation that took minutes and which worked the first time, every time, when downloaded and installed.

FactorySQL and FactoryPMI were revolutionary products. But they were separate products that had to work with third party products before they could do anything. More than one person got lost in the installation process. But Ignition is another story. The installation process is so simple it's gotten ridiculous.

I thought, "I'll bet even a kid could install Ignition." So I decided to have my ten-year-old god-daughter give it a try. I sat her down at my desk, pointed her to our website and asked her to download Ignition and install it. I had to show her where to find it on our website, but with a little direction she downloaded Ignition and installed it. The time? Four and a half minutes! When I told her she just installed enough software to run a huge manufacturing plant, her eyes got real big and she started grinning from ear to ear.

If you think I'm exaggerating, you should try it for yourself by downloading it here. If you think it sounds too good to be true, because you've installed other SCADA/MES software that took all day or several days, then give Ignition a try and convince yourself. If you think the learning curve would be too much, just remember my god-daughter – if even a ten year old could do it ...

So what can you do with software that installs in under five minutes? It's got to be pretty limited, right? Wrong. If you really want to know what it can do, read my earlier blog entitled "The Three Minute Misconception". Not only can you start developing right away, but you can have a simple application up and running in half an hour (not to mention launching a dozen clients). But the best part is, you don't even have to contact us to try it out.

Just so you know, we don't do those funky 30-day trials. Our trial is unlimited just like everything else about Ignition. Splurge on it!

Outsourcing Development... Not!

I was caught off-guard yesterday when a couple of our sales staff told me that some people thought we were outsourcing (overseas development) because Ignition is relatively inexpensive. The short story is we don't outsource.

The longer story is this... In the beginning I researched outsourcing and it was a 50/ 50 proposition, but I decided to hire locally. As you can see, it turned out to be a smart move. Two or three years ago we reconsidered outsourcing some software development and it looked pretty good on paper, but when we got down to the brass tacks and started interviewing we realized it wasn't going to work. You have to look at a broader picture when making a decision like that.

Here's the rest of the picture. Our programming requirements are intense and our feedback loop is fast. Our developers are all field savvy, even though they all come from the IT arena. Our interoffice communication is fast, accurate and bright ideas germinate spontaneously every single day. This is a priceless chemistry.

Also, we have a saying around here, "minimize the internal fiction." Our software architecture embodies this by deliberate design. So do our business processes. As soon as we start getting in the way of ourselves we clean it up right away. The bottom line is, I don't think outsourcing plays well with this idea, or our amazing chemistry.

Linux SCADA

We're seeing a pretty good up-tick in Linux installations this year. It's also interesting to note that if you search for "Linux SCADA" or "Web based Linux SCADA" you'll get a load of stuff. There are quite a few open-source projects and one of them (not web based) is pretty comprehensive.

So when my old Windows desktop bit the dust I decided to get adventurous. I download and installed Ubuntu Linux 10.10 on the bum machine and then installed Ignition on top of that. I'm no Linux guy, but the installation was no big deal. By the way, if you haven't used Ubuntu before you should grab an old machine and try – it's pretty darn nice.

To install ignition I just downloaded the Linux zip file from the Inductive Automation website and followed the instructions in the README file. Obviously, it took longer than the three minutes it normally takes on Windows, but I doubt the install took over ten or fifteen minutes total. Once I got it installed I connected over the network to a PLC, created a simple screen and launched several clients across our network. That was fun and satisfying because I resolved in the beginning not to not ask for any help if I ran into problems.

The Future For Linux SCADA

Developing professional quality SCADA software on any platform is challenging because it involves a mixture of disciplines that are hard to gather in one place. It requires the grizzled old control system expert as well as several highly skilled software developers with diverse skills in UI development, database development, hardcore coding, driver development, cryptography (if you want a modern SCADA anyway), and a lot more. Now throw in the variable of supporting different operating systems and it can get so burdensome that multi-platform support is plainly not cost effective.

Since Windows is the dominant OS, developing on Windows is the only viable choice for most companies. It doesn't make economic sense to develop SCADA on several emerging platforms while gambling they might get popular. Viewing the field of established SCADA software providers bears this out. I think every major player supports Windows only, except Inductive Automation, which is written in Java so it runs on nearly any OS.

I can tell you this was a fortunate choice on our part because if we chose anything else, that would be it. We wouldn't be supporting any other platforms for economic reasons, just like the rest.

What about the open-source projects? Any potential there? I wouldn't hold my breath for the reasons given above in the fourth paragraph. Pulling together a team like that for free seems highly unlikely to me.

OPC Xi: Is it Dead Yet?

I just have just one word for OPC-Xi ... Why? Okay, I get it, it has taken forever to get the OPC-UA show on the road. And yes, Xi is a quick and dirty solution to get around classic OPC which is based on DCOM. But it's a short-term solution in a field that demands longer-term solutions.

Forget the fact that Xi, like classic OPC, is vendor specific (depends on Microsoft technology). The bigger point is how many standards do we need? It's already to the point of madness. Isn't that the point of OPC standardization?

OPC-UA is now an accomplished fact. We recently attended the OPC-Interop conference in Nuremberg, Germany and were pleased with the heavy attendance. In fact, we successfully tested Ignition OPC-UA against nine other UA servers and ten other UA clients. Commercial products are now available from a large and ever growing number of vendors.

The more telling point is that OPC-Xi has no validation testing available (to my knowledge). And there are no interop conferences to ensure compatibility (also to my knowledge - correct me if I'm wrong). So is there really interoperability? I don't know. Take your chances.

NEWS FLASH – OPC-Xi is DEAD! Actually, it has been renamed to OPC .NET 3.0 (WCF Edition). Man, that is a mouthful to pronounce. As I was writing this one of our developers pointed out this recent change to me. By the way, WCF is the new Microsoft replacement for DCOM.

Whither Silverlight?

A number of HMI / SCADA companies have now built their products upon Silverlight, and while this creates some awesome graphics, I have to standby what I've always said about building (at least in our industry) on the tumultuous Microsoft base. Last week Microsoft announced a shift of emphasis from Silverlight to HTML5. I shouldn't have been shocked because I've been predicting this, but I WAS shocked because Silverlight just hasn't been around that long.

I think it's fine that Microsoft shifts with the times and I think it is a particularly smart move for them to shift toward HTML5, but in the HMI, SCADA and MES industry such rapid shifts spell disaster. This is because in our industry things have to last a while. I think building HMI, SCADA and MES software on top technologies that change every two or three years is like building skyscrapers on top of the San Andreas fault line.

Web-based HMI: from 2002 to present day

In 2002 Rockwell Automation wrote an article called Web-Based HMI: Beware of the Fiction and said, "If all you need to do is to look at a snapshot of historic information, then yes, the Web can do that. But if you need real-time plant floor monitoring and control, if you need to know immediately when some aspect of your system changes, if you need an alarm system that will notify you the instant something goes wrong, the Web is not yet able to provide that solution".

That was totally thinking "inside of the box", even in 2002, so in 2003 I wrote a counterpoint article called Web-Based HMI: An Emerging Trend? I concluded that article by saying, "Users are finally getting what they want – the functionality of an HMI with the economics of a web browser. The real question is not whether web based control systems are an emerging trend – they cannot be stopped, but rather which vendors are poised to jump on the bandwagon and deliver the technology."

Seven years have passed since then and where are we now? Today everyone has a web-based human machine interface available, even Rockwell. But there is one big huge difference between the players – the licensing model. The real question is, is it being sold by the server or by the seat? I almost choke every time I see a decent web-based system sold by the "named user" (which is actually a eupherism for "sold by the seat").

My 2003 article referenced a book called Seeing What's Next by Christensen, Anthony and Roth. The book introduces theories to predict major industry changes which I think you'll find interesting and which I think shed light on this industry. You should check it out on some rainy day.

OPC-UA development from the spec

It's amazing what you can accomplish when you abandon preconceived notions. This weekend I toured the SS Red Oak Victory in the old Richmond naval yards (in Richmond, Calif.). The shipyards there were built in WWII. Kaiser built Shipyard #1 in 55 days! But what was even more amazing is that they built ships like the SS Red Oak Victory in something like five days. Can you imagine how long either of these feats would take today?

Well, I think our developers are equally amazing as the builders of these ships and shipyards. They went along blissfully developing the worlds first Java OPC-UA server (and client) directly from the spec and didn't think anything about it. You know, normal day. They didn't know that they were the first. And they also didn't know that it was such a big deal to have written it from the spec. They went to an InterOP conference and found out that no one else had and some folks there were sort of drop-jawed.

Well, that's what really gets me excited around here. We get an idea of what we want to do, and then we do it. No one ever says "that's impossible" or whines "that's hard." If it makes sense we just do it. And believe me there is nothing helter-skelter going on around here either. We look WAY into the future and everything we do aligns. We very carefully study the technology trends and we always plan accordingly. Very soon we'll have another often-requested module that I would classify as nothing short of amazing – of course! And as always, it will be based on open standards. Stay tuned and I'll release details as soon as I can.

Building Applications in Earthquake Territory

Nothing is worse than building your applications on a platform that's constantly in flux. When that platform is your very foundation, your apps are sure to crumble. Take for example COM and DCOM (superseded by .NET stuff), Mobile Windows (abandoned in favor of Windows Mobile 7), VBA (as of July 2007 Microsoft no longer offers VBA distribution licenses to new customers) which has been replaced by a whole string of stuff including Script for the .NET Framework, then VSA (Visual Studio for Applications), but that was deprecated in favor of Active Scripting, but then that was replaced, as far as I know, by VSTA (Visual Studio Tools for Applications) which programs against the .NET Framework. This last one requires purchasing the Visual Studio development environment and compiling your applications.

I couldn't stomach building on a shaky foundation like that, so we didn't. You also won't find me building a home on the San Andreas fault (San Francisco / San Jose area).

From a developer perspective, my vision was and is to develop on a platform that doesn't change for the sake of change. If it's going to change then I want it to change for a good reason. I think that the Java platform accomplishes just that. That is what we wrote Ignition in.

But what about the people who use Ignition? Well, they get Python. A beautiful, forgiving scripting language. No compiling, and it's just the same as it was seven years ago. If we do anything to it at all it will be to embed a newer version which will add features but not take any away.

Hey! Spectrum Controls, Moxa, Online Development, et al

Hey guys, I've got a great idea for you. Why not make an OPC-UA-to-protocolX converter box. Maybe it could be an in-chassis card for PLCs or maybe something like the WebPort 500 (an external DIN rail mount box with serial to various PLCs using various protocols).

I mean, ideally, PLC manufacturers would build OPC-UA right into their PLCs. I say this because it's extremely secure, platform neutral and it accommodates any shape data structure. But you and I both know why that might take a very long time. So that presents quite an opportunity for you.

Right now, Modbus TCP is the lingua franca (universally spoken language) and most PLC manufacturers build it right into their PLCs in addition to their own primary protocols. I love Modbus TCP because it's open, fast, simple and ubiquitous. But it's not so secure and as far as I know it only supports elementary data types. OPC-UA is destined to be its successor since it answers these and a host of other problems.

The recent OPC interop conference in Germany (which we recently sent a couple of developers to) was a good indication of what to expect of OPC-UA. The number of OPC-UA servers and clients tested at the conference nearly tripled from just a year before – showing that the use of OPC-UA in the industry is growing fast.

So I bring it up now. I think the OPC-UA converter box (or in-rack card) is a great idea. If I was in the hardware business I wouldn't be telling you this – I'd be doing it myself.

Python - The Cartoon

For those of you who missed Carl's comment of October 13th here is a comic strip that he referred to. Apparently, my reaction to Python is pretty universal (you can read about my reaction in my post of October 13th).

Here's the thing, in any language the most tedious part is likely to be the GUI programming. But when you program Python in Ignition all the heavy lifting is done for you because Ignition makes GUI development a snap. It also handles deployment, security, authentication, database connections and data caching, single file backup, PLC connectivity and I could go on for paragraphs. So with your scripts all you have to concentrate on is the immediate specialized task at hand. That makes development fast. Really fast.

But more than that, it makes development fun. Nothing like the grueling days of VBA (which by the way is obsolete, is filled with security holes, and is an ugly language).

Ignition - What's the Catch?

This happens so often that I thought I better comment on it. Yesterday I was talking with one of our users who happens to be so jazzed on Ignition that he shows his plant, which uses it, to other people all the time. At the end of a recent showing he told me "they were just standing there drop-jawed but kept asking 'what's the catch?'"

This "what's the catch" question is asked so frequently I'd be totally remiss if I didn't answer it. The answer is "there is no catch."

This is hilarious, but I was once sitting in a conference room with executives of a company with the head of IT grilling me "how can you stay in business if you charge so little?" He was so used to paying insane dollars for marginal functionality that this was his yardstick. It took me about twenty minutes to handle this but I finally asked "why do you think we are charging too little? Have you ever stopped to think maybe the other guys are price gouging you?" Somehow this rang true with him and they bought Ignition.

Consider this, mobile phones used to cost $5.00 per minute and you had to wait for a channel to free up before you could talk. And the mobile units used to cost upwards of $6,000 each. Does that mean that Verizon, ATT and the rest of the cellular companies aren't making money or have a bad business model? Of course not.

Personally, I think this field has been brainwashed into thinking that HMI, SCADA and particularly MES are very hard and complicated and thus have be very expensive. Bull! This simply isn't true.

We have a different model. We sell by the server. That's all. Remember, I myself have been a system integrator for over twenty-two years. That is the perspective we come from. We have always looked for ways to increase the value of our services. Taking three days just to install software is delivering poor value. That's why we deliberately made our installation take only three minutes or so. Then you can take the remaining three days and deliver some real value.

There are certain things that irked me about software as an integrator. Some things just didn't seem right. And these things I've found to be universal. These are the exact points that we've addressed with Ignition. And one of those things is a fair and sensible pricing model. From what we hear, most integrators and end-users agree that we've accomplished just that.

The Sheer Joy of Python

I decided to take on a little project just for fun and used Python (naturally since that is Ignition's embedded "scripting" language) to do it. I decided to download the Python IDLE IDE (Integrated Development Environment) to see if I could speed development a bit. The whole download from the www.python.org website and its subsequent installation only took maybe three minutes (it's free too). It took me a minute or two to figure out how to make it come up in the editor mode rather than the console mode but once I got beyond that I was amazed at how fast I could write a lot of functionality.

I'll tell you a little secret, I googled things I wanted to do and then cut and paste example code into the editor. Then I made a few obvious changes and bingo, it just worked! Then I cut and paste that code into Ignition and it worked.

It became immediately obvious to me that I could even write drivers this way in a pinch. This wouldn't be the recommended way because we have a Java API for third-party developers that would be better integrated. But in a pinch where you need something quick and particularly for simple one-off protocols this would be a good (and fun) choice.

Python is forgiving and intuitive. It has dynamic type casting so you just code away and don't worry about that. The language is easy to read so when you look at another person's code you usually can tell exactly what's being done. But don't be fooled by this ease of use because Python is fully object oriented and in the case of the flavor we use in Ignition (Jython), can drill right down into the Java code. There is no compiling either, just run the code.

I mentioned all this to some of our developers yesterday and they lit up. They reminisced at programming when they were just kids and the sheer joy it brought to them. They said that is what Python does for them now. You can do so much, so fast, totally hassle free. In fact, one of them uses Python for all types of quick tasks that would otherwise be tedious.

I realized that this is what I experienced as well, the sheer joy of programming in Python.

Running Ignition on HP-Unix???

One of the reasons we chose Java for Ignition is its cross-platform capability. Of course, you would expect that most deployments would be on Windows, which is the case, but there is an interesting trend going on. We are seeing a creep away from Windows and one such case really took me off-guard. One of our customers has deployed on HP-Unix. I didn't even know that was possible.

Then there is the case of one customer who knew us from the days of FactoryPMI and FactorySQL who waited until Ignition was ready because they insisted on running on Macs.

The Linux crowd is really starting to grow and I expect it to dominate on the plant floor eventually. In fact, I have this little blue box from Eurotech on my desk running Ignition on Linux. That little box is good for -40 to +85 degC so you can put it on the plant floor or in the field without any air conditioning whatsoever. And it only consumes 3 watts of power so it's perfect for solar applications. Pretty cool!

As I've mentioned before, I consider each and every Windows version (or even different service packs) a different platform as well, despite apparent similarities. I see a lot of industrial software that isn't supported on Vista or Windows 7 or even XP SP3. But by using Java, we don't care what the platform is being used, for the server or for the clients, and that removes one huge headache for most people.

Where's the price?

Ever quote a job for a customer that included HMI and SCADA software? You know how it goes, you're preparing quotes late at night or on a weekend but all the sales reps are enjoying their weekend while you work hard trying to sell their software. This wouldn't be a problem if industrial software companies openly published their prices.

Why is it they are so secretive with pricing? According to an old-hand sales person I know, there are only two reasons for hiding prices. Either they want to be able to cut custom pricing for different customers (whatever they can get away with) or they are trying to suck people into a conversation so they can close a sale.

In my experience both reasons may be applicable to industrial software sales, but on the latter I might add that by conversing with you they often gather intelligence.

For the first, I've seen pricing for industrial software for a fortune 500 company (though I'm sure I wasn't supposed to see it) and it was only 39% of the very best prices I ever heard of for that software, which was shocking to me.

For the second reason, when you get pricing for industrial software the sales rep wants to know who the customer is, what the job is, who the contact is and so forth. This is problematic because sometimes when you're doing comparative pricing the rep runs out afterwards and calls on your customer directly.

Like I have said in the past, most of the policies we adopt at Inductive Automation are based on my prior experiences as an integrator. If you want to know the price of Inductive Automation software just go to our website —it's all right there. There's too much work to get done to mess around with all these goofy pricing games.

Of course, I might be missing the real reason. Are they possibly ashamed of their prices and pricing model? What do you think?

How many patches did that take???

Wow! Our integration sister company was upgrading a major HMI vendor's software this last week and it took tons of patches and tech support to get it running. I won't mention this company by name but I will tell you that it has huge market share. Probably the largest.

So how long does it take a trained expert (in their software) to upgrade from one major version to a couple above that? Bear in mind that this end-user paid for and got all the software disks for this upgrade. Out of the box it didn't work. It took five support calls, two service pack upgrades, two patches and one hot-fix to get it mostly going. There are still problems with tag database importing from the older version and work is being done on getting graphics to come across the versions still.

Maybe from an integrator's point of view this is a good thing ... you know, lots of billable hours. But as far as I'm concerned those hours could be spent on something more constructive for the end-user of this software.

Later on in this chain of events this company learned that our sister company was the one doing the work and immediately made the mental connection with Inductive Automation (even though they are two separate entities). Then they refused to provide any further support even though the end-user paid dearly for annual support.

This I take as the ultimate compliment. The market leader petrified of us? Now that is real progress.

Actually, I don't blame them. When you consider that our install only takes three minutes, that it works first time every time and that we can even do hot upgrades it's got to be scary for them.

The biggest risk I run with my saying that is best reflected in my earlier post "The Three Minute Misconception" wherein an analyst told me he thought Ignition software would be good for only lightweight applications only because it only takes three minutes to install. Of course that drives me crazy because I know, as do our customers, that Ignition actually does far more for far less cost. About a 3–10x cost advantage and as far as functionality goes it leaves the rest in the dust!

Why Java?

By now, most know that the Ignition by Inductive Automation platform is programmed in Java. But why?

Few people know that Java is the most popular programming language in the world (See the TIOBE Programming Community Index for September 2010). Java runs on more types of consumer and embedded devices, smart cards, ATMs, thin clients, PCs, servers, and mainframes than any other language.

Additionally, Java is the "write once, run anywhere" language. This is a major reason we selected Java. By writing Ignition in Java it runs equally well on Linux as it does on OSX, Windows or Solaris. Come to think of it, isn't every version of Windows a different platform? Well, Java spans them all. We don't care who wins the operating system wars or even if no one does.

Java is also highly resistant to viruses. Java appears to have been developed with security as a first concern rather than as an afterthought patch-up. That makes it ideally suited to the industrial environment.

With over five million Java programmers (which makes Java the largest developer community) it is far easier to hire software developers than for other languages, especially right out of school.

Rather than following the flock (look at it, every other major HMI company requires Windows) we took a step back and evaluated what language provided the most portability, security, stability and support—and Java was the clear winner.

OPC-UA - Why change now?

While talking to people about OPC-UA they usually say "Why change now? - everything I have is working great." In this, they make a good point and I'm always the first to say "If it ain't broken - don't try to fix it." But there are some important aspects you should be aware of so you can make informed choices moving forward.

Legacy OPC is based on Microsoft's COM technology which has been deprecated for years now (The software definition of deprecation is "software features that are superseded and should be avoided") . Due to the large install base of programs that use the technology Microsoft still supports it. But moving forward Microsoft has signaled neither continued support nor intention not to do so.

The COM technology that legacy OPC depends on has also proven to be a huge security issue. This is so much the case that it has undergone a massive evolution to try to mitigate the factor and in doing so programs that once worked sometimes cease to work after an OS upgrade or patch. This is such a headache that one company delivered seminars around the country teaching people how to deal with COM/DCOM. In fact, the OPC tunnelers offered by a number of companies are a solution to this COM quagmire.

OPC-UA was designed to address these issues and a number of others. It leverages modern security and performance techniques. It can be scaled down to embedded devices or up to the enterprise level. Soon you could expect to connect to PLCs, barcode scanners, flowmeters and practically any other plant floor device directly using native OPC-UA protocol. That would get rid of the headache of a gazillion device drivers. Embedded device manufactures can buy the OPC-UA stack for embedded devices if writing their own stack seems formidable. I believe it's only a matter of time before we see this happen. That's how legacy OPC came to be.

OPC-UA offers IT industry standard authentication and encryption. This is a particularly important consideration when you consider the fact that plant floors increasingly are no longer islands. Consider the recent Stuxnet virus that specifically targets Siemens HMIs.

Unlike legacy OPC, OPC-UA can run on any OS, which might not seem important now, but in the future could be an important factor. We've run into an increasing number of US companies that refuse to run industrial applications on Windows and some of these are large companies. I'm not advocating one way or the other - I'm just commenting on what I see.

COM and DCOM go back to 1994 and there are roots even earlier. OPC-UA is a "now" technology which will probably have longevity since it is based on proven IT standards.

So what should you do moving forward? Clearly, new installations should be OPC-UA or you risk doing it twice. But what about those legacy installations? Sure, if it's working then leave it alone. But be very cautious of any OS upgrades or patches. One customer had automatic updates turned on and in the morning not one single HMI terminal worked, effectively shutting down a large company for the better part of a day.

That next project probably presents the most opportune time to made the move to OPC-UA.

Get IT On Your Side and They'll Seal the Deal For You

As you expand past plant floor controls you begin to enter into the domain of IT. But when you do so you will begin to work with IT folks. Believe me, you want IT on your side or your project will end up on a data island which is useless in an enterprise system.

So how do you do that? Well, first of all you better find out what hardware and software the IT department is willing to support. When I make initial contact with IT folks, I always ask what technology they use. Then I assure them we’ll work with that. This generally makes them very happy. You have to learn to work with them within their envelope. You're not in a position to try and cram something else down their throat. It is only by standardization that they can support huge corporate networks without the job becoming onerous.

The next thing I do is use their terms and refer to the technology they are currently using. If the system you are proposing isn't something they are familiar with or if it uses 1990's technology like DCOM, then you better ditch it and find something else. In short, if they can't relate to it without a bunch of specialized training (which isn't likely to happen) then your project is probably going to die.

But the reverse is true if you can talk their terms and they can wrap their arms around the technology.

IT Could Be Your Best Friend For Sales
In this case, IT is likely to be your biggest proponent and can help you get your project pushed through. I've personally been involved in these situations many times. In one case I had the buy-in of the plant manager, maintenance manager and production manager but I said "now let's get together with you IT department."

The plant manager said "are you SURE you want to do that?" and I said "Yes."

At the start of the meeting the two IT guys had their arms crossed and looked resentful. First I asked them what relational database they used and they said MSSQL Server indignantly. I said great, that's what we use and they perked up a bit.

Then I went to the white board and laid out the system in terms I knew would be acceptable to them. They asked a lot of questions but I answered each in alignment with technology I knew they already were using. Somewhere in the middle of this I saw them flip from being adversarial to helpful. They started asking things like "When do you need this by?", "How much memory do you need?", "Can we run it on a virtual machine?" and in fact they became allies which sealed the deal.

It is an amazing thing to watch how fast EVERYONE else buys-in when IT does. Like I say. You better have them on your side.

Modbus TCP - Lingua Franca

Lingua franca = a common language used by speakers of different languages.

Modbus TCP is just that for the controls industry. A look at interface options for a wide array of devices shows that everything from flowmeters to lighting controllers, VFDs to PLCs, generators to weigh scales and even things like solar cell controllers generally provide an option for Modbus TCP connectivity. On the PLC front, it is interesting to note that many newer PLC controllers support Modbus TCP no matter what their native protocol is.

For this reason, we decided that Modbus TCP would be one of the first drivers we should develop for our free OPC-UA server. But to achieve address space browsing, something I earlier dictated any driver we develop would have, is easier said than done. Obviously, dealing with such a wide variety of devices with widely divergent address spaces is a problem. So we solved that with templates. You map your address ranges and data types and then can browse anything in those ranges. Then that template can be saved and reused. For example, you can download a couple of templates for Automation Direct controllers from our website. More templates will be added over time, but in the meantime you can create your own. Creating them is simple and intuitive.

One thing we were amazed about is how fast Modbus TCP can be. During development of the driver we were working with one customer that had really fast requirements, so we just kept refining the driver until they were happy and the result was nothing short of amazing. I imagine this was possible because the Modbus TCP protocol is so simple.

I believe that we probably have the fastest, most user-friendly Modbus TCP driver on this planet. You, of course, can use it for free because we don't charge for it at all. Not for the OPC-UA server and not for the Modbus TCP driver that comes with it. Why would we do this? I don't know, maybe we're crazy, but I'm betting that once you use it you'll want to see what else we're up to.

The perfect complement to PLCs

PLCs? Okay, you’ve tackled PLCs and now you can program 'em with one hand behind your back. So what’s next? What’s the next logical challenge? Think SQL and relational databases. Why? You’d be amazed the similarity. It’s the next logical progression.

You might ask how it is they’re even related. For one thing, relational databases can sort of be an extension of PLC memory. Live values can be mirrored there bi-directionally. Historical values and events can be recorded there as well. But operators and managers can interact with them too. It’s been over 20 years of working, living, breathing and thinking PLCs, but over the last six years I’ve delved heavily into SQL and learned a lot about relational databases. I’ve discovered that working with SQL is remarkably similar to working with PLCs and ladder logic.

SQL has four basic commands and about a hundred different modifiers that can be applied to each. These can be applied in various ways to achieve all types of results. Here’s an example. Imagine effluent from a wastewater plant with its flow, PH and other things being monitored and logged. That’s what you typically see. But now let’s associate other things with these, such as, discrete lab results, the name of the persons who did the lab work, the lab equipment IDs and calibration expiration dates, who was on shift at the time and the shift just prior, what their certification levels were, what chemicals where added and when, who the chemical suppliers were, how long the chemicals sat before use, and so forth ad infinitum. All of this becomes relational data, meaning that if it’s arranged properly in tables you can run SQL queries to obtain all types of interesting results. You might get insight into the most likely conditions which could result in an improper discharge so it can be prevented in the future.

In my explorations of SQL, I found myself looking at the layout of my tables and evaluating the pros and cons of each layout. I massaged them, turned them on their side, upside-down, and finally ended up with the most appropriate arrangement for my application. And similar to PLC programming, I explored innumerable what-if scenarios. I was struck by the amazing similarity in my approach to developing solutions for PLCs. This has been a lot of fun — in fact exhilarating — just like PLCs used to be. It’s the next logical progression you know.

SQL is a high level language that isn’t very hard to learn and you can be very clever with it. I prefer to think of it as a natural extension to my PLC programming skills. Now that you have the machinery running, what did it do? Furthermore, relational databases and SQL pull people and processes together. Machines don’t run alone. They’re merely part of a containing process and that process was devised by people. SQL and relational databases form the bridge to integrate processes, machinery and people together. I don’t believe a COTS (commercial-off-the-shelf) package can do it any more than you could offer a COTS palletizer program and have it be of any use. It just doesn’t work that way. Every machine is different. And every business process is different. That’s where the SQL comes in. It has to duplicate or augment existing process flows and these are intimately connected to the machinery. And that’s why the PLC programmer is best suited to implement solutions involving PLCs and relational databases.

So where do you start? I would suggest picking up a book at the bookstore like one of those dummies books. Then download and install the open-source MySQL database server along with the MySQL Administrator and Query Browser. It only takes a few minutes to install and then start playing. You can read about a LEFT JOIN or INNER JOIN but typing one in and observing the results is worth about 1,000 words. At the end of an evening you’ll probably be very excited with all of your new found knowledge and be thinking of endless ways to employ it in your own field of practice. Happy SQLing!

Process Historians vs. SQL Databases

I wish to register a complaint. There is a rumor that has been circulating for years that relational databases are too slow for fast process data and that only process historians are up to the job. Vendors of process historians will cite sluggish performance and the lack of data compression as the reasons standard off-the-shelf relational databases won’t work. Apparently the last time they used an SQL relational database was a few decades ago.

While there may be some specialized domains where process historians have a niche, they are not a practical choice for most industrial applications. In effect, historian vendors are saying your Toyota Camry is inappropriate transportation because it is incapable of going 180 mph or finishing the quarter mile in under 10 seconds.

An Ill-Founded Rumor
The rumor denigrating relational databases for poor throughput is baseless. A standard, off-the-shelf Microsoft SQL Server coupled with Ignition's SQL Bridge Module can log in excess of 100,000 tags per second using a desktop machine. In all likelihood, other factors such as the industrial network would become bottlenecks before the database does. Furthermore, today’s generation of SQL relational databases are designed to scale gracefully to power high-volume website traffic, whose load peaks dwarf those of industrial controls applications.

Data compression is an area where process historians do score a point. However, even this consideration can be handled with standard off-the-shelf SQL relational databases. Take a look at the MySQL 5.0 Archive Storage Engine which achieves on average a four to one compression ratio. Proprietary process historians may beat that, but let’s get back to the point of practicality. Hard disk space is so cheap these days that even considering this point is becoming an anachronism. For the rare application that demands it, table compression coupled with intelligent data logging allow databases to compete even in this regard.

One crucial question that process historian vendors omit is: what are IT departments willing to support? When I make initial contact with IT folks, I always ask which relational database they use. Then I assure them we’ll work with that. This generally makes them very happy. Believe me, you want IT on your side or your project will end up on a data island which is useless in an enterprise system. Think of it from their point view; they have the training and tools, generally, to support just one type of database. With these tools and training they can support the database with scheduled backups, tuning and other maintenance.

Support, Relational Data, and Cost Factors
Okay, we’ve heard process historian rants about relational databases; let’s talk about the downside of process historians. Let’s start with support. Just check the Amazon bookstore for any one of the proprietary process historians and you’re likely to come up empty handed. On the other hand, check for “SQL configuration” and you’ll come up with hundreds of books. How about finding people to support these proprietary systems? Good luck.

Then there is the concern about supporting relational data with a process historian. Frankly, the middleware layer is all about relational data. Time-series data, which is what process historians deal with, is just a fraction of what is needed in the middleware layer. Correlating batches, shifts, inventory, orders, downtime, quality, etc., is purely relational in nature, and these are the features that today’s enterprise integration projects demand.

What about a cost comparison? The process historian is going to be 10 to 30 times the cost of a relational database using a driver like the Ignition SQL Bridge Module depending on the number of tags required. The controls industry is still backwards on this point and prefers to price its software per tag as though the extra tags cost money to manufacture.

In summary, we’re talking about practical choices. The Ferrari may be great fun, but do you need a $500,000 vehicle to drive the kids to school or would the Camry suffice? Likewise, do you need a $60,000 process historian to log data? A relational database makes a great historian, but the reverse isn’t true. A process historian cannot process relational data. For the vast majority of systems, a relational database has more than enough power to service the historical and relational data requirements, making it not just the practical, but the wise choice.

"Sounds too good to be true."

I keep hearing over and over that our software "sounds too good to be true" (followed by the refrain "but I can't find anything wrong with it"). But why would someone say it sounds too good to be true?

Sure, with Ignition you can launch hundreds of client applications (seats) for free, sure there are unlimited free data points, sure you can launch one (or a dozen) developer seats for free, sure there is an unlimited data point historian included for free as well and and I could go on and on. But still, why does it sound too good to be true?

Could it be that some people are highly suspicious of the big automation software vendors? Could it be that there is a fear that we would suddenly switch gears and start charging for these things later? I suppose that both of these things could be the case but both are unfounded fears because that's not our gig.

The thing is, we have an entirely different philosophy. We learned long ago that price gouging suppresses progress. It's been said that business runs mainly on Excel spreadsheets. My experience bears this out. But why spreadsheets? Because they are cheap, simple and easy to understand. They get the job done.

That is why we have hassle-free licensing. That is why we sell by the server only. That is why we are penetrating into the areas where there were only spreadsheets before and this is the way we want to play the game. We are happiest when we KNOW we are giving our customers value in abundance.

The Three-Minute Misconception

I almost bust a gut the other day. I was talking with an industry analyst and asked him if he'd seen our website. He said “yes” so I asked him what he took away from it. He said it looked like a great solution for lightweight applications. Incredulously, I asked him what on our site led him to the belief the software was best suited for “lightweight” applications. His response? “It only takes three minutes to install!”

Wow! If I knew that our three-minute install would be interpreted that way, I would have directed our developers install delay loops into our installation process so that it would take four hours or four days like everyone else's does!

All joking aside, I set the record straight by citing some of the massive deployments people are doing with Ignition. He soon saw, that in fact, a single Ignition server can deploy hundreds of clients, connect to dozens of SQL databases of practically any flavor, can launch one (or a dozen) concurrent developer stations, perform as a full historian and reporting engine, run on any OS platform – and a whole lot more for a single, affordable price. But he also saw it could perform as a lightweight system too.

The truth is, when you are used to dealing with 1990’s technology, DLL hell, and systems that have been over-patched by an endless string of programmers who have come and gone, you are bound to be shocked when you see what modern technology can do.