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.