The Value of Fast SCADA Installation & Development

When integrators install Ignition for their customers they deliver more bang for the buck in two ways. By an order of magnitude, they save their customers money both on software itself and on the labor to develop applications and deploy them. It's a double-sided benefit for end-users.

If you're an integrator, you might say, "but that's less work for me!" From experience I can tell you that's not true. I've discovered that in the same number of hours you will deliver way more functionality and end-users will love you for it. Then they will ask you to do even more. It's a win-win proposition. Essentially, what I have found is that they finally feel like they are getting the value they always expected.

This is a valuable concept you can use to your advantage as you offer your services.

Also consider this: Who wants to pay for an integrator to spend all week just to install and deploy HMI/SCADA/MES software? That's a huge waste of time and money and it makes the end-user feel like he's getting milked. Enough with that! Why should an installation and deployment take more than a few minutes? Spend the rest of your time building what the customer really wants and deploy it to a hundred clients with just a mouse click.

End-Users Are Beginning To Expect More From Integrators
End-users are starting to take all this for granted. I've been witness to the overwhelming reception of Ignition by end-users once they truly understand it. Hundreds of other integrators have discovered this as well. But now many end-users have come to expect what Ignition delivers as the new norm. When integrators approach these end-users with the old way they're going to get laughed right out of the place. I was recently a witness to a CEO ridiculing an integrator who proposed doing it the old way. It was embarrassing for me to watch.

Virtually all other software I'm aware of is so '90s. Relational databases are a way of life now in manufacturing yet most HMI/SCADA software treats it as an afterthought if they handle it at all. Sure, you could band-aid something together but why would you want to when you could be delivering real value in a fraction of the time? You want to feel loved? Well trust me, that's how you do it.

Offer Higher Value Before Your Competitors Do
Integrators should always be on the look out for better ways to do things more efficiently. Some integrators say, "I just do what the customer tells me." Do that at your own peril because one day the end-user will discover it on his own and some other integrator will be putting it in.

In one case recently, an integrator lost about a year's worth of work when another integrator showed the customer two bids: one for what the end-user requested, and an alternative bid using Ignition. The customer decided to use Ignition because the integrator showed that for the same amount of labor he could deliver more functionality – and more value for the money. He's feelin' the love now!

Integrators Can Differentiate Their Services By Developing Specialized Modules

A week ago we held a Module SDK developers class at our new facilities in Folsom, Calif., with the purpose of increasing the number of third-party developers who would partner with us by developing specialized new modules. I was surprised to learn, however, that integrator differentiation was a key reason for developing new modules.

We recently added two new features to Ignition that make it possible for integrators to differentiate their services from the competition. The first is the new Module SDK and the second is the OEM lock.

Ignition Module SDK
The SDK can be downloaded for free from the Inductive Automation website and includes a new 80-page manual for developers.

Using these tools and knowledge of the java programming language, integrators are now extending Ignition in ways we couldn't have even imagined. Since your java code is compiled your intellectual property is protected. Some integrators have even hired java experts solely for this purpose.

OEM Lock
The OEM lock allows integrators to create Ignition applications that cannot be opened in the development environment (or be otherwise be decoded) without a developer's key. We've had a lot of requests for this functionality over the years and now you have it.

The Developer Program
Just to clarify, we have a three-tier program for module developers. On the first tier, for qualified companies that develop modules which we deem to compliment our product offering, we have a partner program whereby the module developer develops the module and we market it aggressively through our normal channels, as well as us handling sales and first-tier support.

Our second tier program is very similar to the Apple app store program, if you are familiar with that. On the third tier you can develop modules for your own in-house use and this could include developing modules which create integrator differentiation.

Module Development Is Easier Than You Think
What you should bear in mind is that when you write an Ignition module you gain all the leverage of the Ignition platform itself. This includes use of the development environment, the deployment model, database connectivity as well as store-and-forward functionality, security, connectivity with thousands of other devices, interaction with Python scripting, internationalization (yes, that's coming soon too), and literally hundreds of other functions that are baked into the Ignition platform. A proficient Java developer could develop in a week what would take years to write otherwise.

Then there's the aspect of install base. When you develop for the Ignition platform you instantly have a potentially large and ever expanding install base. Right now this is thousands of installations in more than 50 countries. So once an integrator develops a module, there are a lot of Ignition users who would probably be very interested in buying the new module.

Platform Focus vs. Specialized Module Development
Here's our philosophy about modules. We want to focus on the Ignition platform itself and make it the best platform there ever was. This includes supplying ever more universal functionality, improved documentation, constantly improving software quality, improving the ease of use, etc.

For the more specialized functions we want to partner with other qualified companies that already have extensive domain experience in some specialized area. There are potentially thousands of these areas. Perhaps yours is one of these companies.

Automating Business Processes Can Save U.S. Jobs

Recently, I was talking to corporate engineers at a major United States company that has adopted Ignition with a vengeance. They said, "You know what we're doing, don't you? We're saving U.S. jobs."

I've always felt this was the case. But you can't just plop down Ignition and expect to automatically save jobs. Ignition has to be thoughtfully integrated against existing business flows; then if you did well, you can make the same statement as the company above.

I'd love to tell you more about the company that was rejoicing over the phone about saving jobs in America, but we're under a non-disclosure agreement because they are serious about keeping their new-found business advantages.

Better Efficiency Begets Better Jobs
There is another company that generated reams of paper every day just to keep track of their operations. They are in the food industry and have stringent genealogy requirements. The amount of double, triple and quadruple data entry was astounding. Now it's all electronic using Ignition.

You might say, "well, what happens to all those people's jobs?" The answer is they still work there, but in better, more productive, more rewarding jobs. That company is now more competitive. Similar stories are rolling in every day from Ignition users.

A "Living Application" Example
Our own customer relationship management (CRM) system is an example of making everyone's job better. Way back in 2005 we were being overwhelmed administratively on just the traffic we had at the time. We had a hard time tracking everything that was going on. We were doing it all manually and it was labor intensive and not very scalable.

So we took every one of those existing business flows and automated them using Ignition. Everyone knows what's going on. The sales pipeline, all communications, tech support history, knowledge base, statistics of many types, website back-end, license activation and history, quotes, email, phone, appointments, cameras, you name it, it's probably there. And every single day there are updates rolled out to the multitude of open clients, which adds even more functionality.

It's a living application which keeps up with our business processes as we improve them. Ignition makes "continuous improvement" attainable in reality. There is just no way to communicate how our CRM has taken all the internal friction out of our operation and for that we're far more competitive than we otherwise would have been. And it didn't cost us a million dollars.

The Right Mix for Automating Business Processes
Why is Ignition so adept at automating business processes and creating paperless plant floors? Because Ignition is a rapid application development (RAD) tool, because it can easily talk with almost anything in the enterprise, because it has an amazingly simple deployment model, and because it has flat server pricing so you can scale it out without dealing with oppressive economics.

As I mentioned before, achieving these efficiencies doesn't happen auto-magically. It still requires someone who knows existing company business processes as well as a familiarity with Ignition and databases. But with these in place you can do miracles and be the hero.

What many companies are doing here in America today with Ignition is breathtaking. I've seen many of these applications and I'm just thinking, "Wow, these guys have got to be deadly to the competition – such ingenuity." Ingenuity certainly hasn't left America.

Web-based HMI: An Emerging Trend?

Realization of Web-based Control

Once considered impractical for applications requiring responsive animation and real-time control, a new breed of web-based HMI system is starting to appear on plant floors and in manufacturing enterprises.

“Java (web) based systems can now deliver sub-second response, rich animation and natural integration with other parts of the corporate information infrastructure,” says Nathan Boeger of Inductive Automation.

Unlike traditional systems, these web-based systems can economically be extended to every aspect of a business such as QC, maintenance, logistics, plant manager, and so forth. Now every participant in the manufacturing cycle can have unprecedented access to vital plant production information.

It's easy to see why web-based systems are gaining popularity. Web-based systems install and run client applications from any web-browser and when users login they always get the most recent version of an application. There are no client licenses to manage, no tedious software installations, no application files to copy over and no communication configurations to setup. IT departments are willing to embrace technology they understand. All this is in sharp contrast to traditional systems.

The economic advantages of using web-based systems are compelling. The bottom line is, web-based HMI systems fit well with the rest of the enterprise and facilitate the smooth flow of information throughout an organization without unnecessary difficulty and expense.

Security Issues
When potential users first consider using web-based technology they usually ask about security. Just how secure are web-based systems? The question is especially valid now that post 9/11 committees have deemed HMI and SCADA security “one of the most serious risks to our national security.”

Traditional vendors rely heavily on “security by obfuscation” which has never been considered a safe practice. Web-based systems, on the other hand, are already positioned to leverage standard and proven web security techniques as administered by IT departments.

It’s only a matter of time before legislation mandating minimum HMI and SCADA security requirements will surface. Traditional providers will likely have to overhaul their products to come into compliance. They will welcome this day since they will sell lots of mandated security upgrades.

Seeing What's Next
Functionally speaking, HMIs haven't changed much over the past five years.

“HMIs that just do operator interface tasks are a commodity, and you can buy them dirt cheap off the Internet … The real action is in HMIs that provide web access, interface to higher-level enterprise software, perform MES functions,” says Rich Merritt, senior technical editor of Control Global, in his article, “HMI Software is disappearing”.

The book Seeing What’s Next by Christensen, Anthony and Roth, introduces theories to predict major industry changes. These theories are supported with interesting historical examples. Applying these predictive theories to this industry suggests incumbent HMI vendors will continue to service their large existing market without much change. They will probably not compete with their own model.

On the other hand, web-based vendors will find success selling where traditional vendors have failed; to those companies that refuse to spend big bucks on systems perceived as being unnecessarily complex, cumbersome and overshooting needs. This is likely to lead to explosive growth for web-based systems in market segments which have been unfulfilled by traditional systems.

Anyone familiar with manufacturing knows the majority of factories barely implement information technology at the plant floor level. There are exceptions, but when you see clipboards being used to record schedules, downtime and production, when you envision how things should be done, you finally come to realize this is a vast untapped market.

There is an accelerating pace of web-based systems being installed in what was essentially a non-consuming market. 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.

Web Services and Ignition

Our modus operandi is to deliver what people want (sometimes sooner, and sometimes later, but always eventually if it is of general interest) . Recently there's been significant demand for Web Services so we undertook development of an Ignition Web Services module.

A definition of Web Services is in order. The following definition has been provided by the W3C Working Group:

Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

With that said, forget the acronyms SOAP and WSDL for now. We plan to make this an easy to use module requiring little or no knowledge of Web Services. The module will act as both a requester and provider of information.

So what can you use it for? You can integrate with ERP systems as large as SAP or small as Quickbooks Pro. You can also integrate with hardware devices such as the iLon SmartServer.

We have a lot of exciting things on our development timeline. This is just one of them. You will be hearing more about this one, and others, soon.

What is Inductive Automation's Market Share?

Funny question... one of our sales team got asked that question today so I had to get up and give a lecture about it. My immediate response was, "market share of what?" We're talking apples and oranges here.

Look at it this way. $20,000 might buy you a real nice SCADA client, a developer seat and a historian with support for 5,000 tags. And at the end of the day, no matter how you look at it, that's all you have.

But what about Inductive Automation? $9500 buys a SCADA server that can support 200 clients, 10 developer seats, a historian with support for 50,000 tags, plus support for fifty or more simultaneous projects (actually each are arbitrary quantities because the truth is, it's limited only by hardware).

Okay, so if you had to buy the other guys' equivalent of that, how much would it cost? I computed it using one company's recent prices and came up with about $1.3 million.

So you have to normalize for that. What is the equivalent value in terms of the other guys' prices that we deliver with even a single Ignition server? When you consider we have thousands of installations (in over fifty countries), what is our market share?

To be fair, not every Ignition Server is going to deploy 200 clients. But the point is, they could. And that is why you can't really compare market share. The value delivered by a single Ignition server is determined by the size of the deployment. The bigger the deployment, the greater the value delivered in terms of the other guys prices.

Sony Google TV + Ignition Mobile = Awesome Status Marquee (cheap & easy)

Earlier this week, someone asked me to recommend a large screen monitor that could display realtime status information for packaging lines. It suddenly struck me, "what if the new Google TV could do it?" (40" Sony for $1000)

Over the Holidays I bought the 46" version ($1400) for my personal use. All I had to do was plug it into power and connect to my wifi which which took me all of five minutes (or you can use CAT 6 Ethernet). This amazing, totally integrated TV can browse the web, watch NetFlix, YouTube, and a lot more. But as I pondered the question of a good line status monitor I blurted out "maybe Google TV could do it!"

So I gave it a try when I got home last night. First, I launched our Internet hosted demo project but that didn't fly because Google TV doesn't have the JRE installed. But because it's based on Android OS, I decided to launch via our Mobile Module demo site and viola! What a beautiful display! Plug and play line status display in minutes!

There are a few things to know though: 1. You should turn off the screen saver. 2. turn off inactivity auto-power off. 3. configure your Ignition application for auto-login. 4. enter your Mobile Module's URL with a direct address to your application bypassing the project page. 5. bookmark the URL and create a shortcut key to it.

I got so excited at the prospect of a cheap & easy line status monitor that this morning I bought a 40" Google TV (at Best Buy) on my way into the office. We decided to mount a few of them around the office using Ignition and Mobile Module to show realtime departmental stats - things like support calls handled, successful sales call made, web demos delivered, and new counties sold to (by the way, that's over 50 now), etc.

It's amazing what a line status marquee can do for production and efficiency. When used to display realtime efficiency, I've heard numerous managers comment that efficiency goes up every time without even prompting. There's something about closing the loop with operators in realtime. And for years, people have been asking me for recommendations about the best way to create such marquees. I've had a variety of answers over the years, but none have even come close to the low cost and simplicity of this solution.

Why Ignition Offers the Best Mobile HMI / SCADA Capabilities

The Ignition Mobile Module will be released January 25! It can run on any modern mobile device including iPhone, iPad, iPod, Blackberry 6 or any Andriod-based device such as the Droid, DroidX or the HTC smartphone. Ignition Mobile is based on the HTML5 canvas element. It doesn't require the JRE or any sort of plug-in at all.

The finished product makes it look so simple, yet what we've done behind the scenes is unprecedented. Just look at the criteria we used in the development of this mighty module!

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.
4. Must not require duplicate mobile app development.

5. Must support zoom and pan.

6. Must be based on open standards.

7. Must be based on technology that holds the best promise for longevity.

8. Must be secure.

9. Must be simple to install module with near-zero configuration.

We've delivered on every point. Interestingly, we can't find another mobile package anywhere that does. And as always, with Inductive Automation software, you can launch unlimited free clients (limited only by your server capacity – not by licensing).

On January 25 you will be able to download it from our site and try it for yourself. You won't even have to give us your name (unless you want to).

Integrator Anxiety

I love talking to our sales guys because it gives me a chance to download to them some controls integrator perspectives which I think (and hope) could be valuable to them. I want them to have a real appreciation for an integrator's world (and what a challenging world it is!). When I do this I usually have huge realizations myself.

This happened to me today when I realized that the limitations of new software or hardware are usually only discovered after you decide to use it for the first time. So here you are, you've discovered a cool new piece of technology but you're up against the learning curve and are racing against the customer's schedule. And it's only at this time that you discover what the software or hardware can't do, and you're jumping through hoops to make it work. Talk about stress! It's almost enough to make you not want to adopt anything new. But it's also fatal not to be on the lookout for a better way to do things – because if you don't bring it to the table, somebody else will. I've been there a thousand times myself.

So I let our sales staff know this is what integrators are up against. There is real risk and stress related to new adoptions. Sometimes it's horrible. But I also coach them to relate that Ignition addresses all these pain points. It was totally developed from an integrator's perspective. We've taken away as many limitations and surprises as possible. Occasionally an integrator will push our software to the limit and report it to us – but man! – we're all over it right then. I know what it's like to be in the field or in development and you've made the leap and tried something new, and only then discover crazy limitations. The feeling of panic starts spreading through you. I hate it and don't want anyone to have to experience it with our software.

Personally, the more I use our software the more I discover what it can do, rather than what it can't do. And that's the way it should be.

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).