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!