More About Cloud-Based SCADA Systems

Our recent Cloud-Based SCADA Systems webinar was well attended right up to the end of the presentation, which highlights the tremendous interest in this topic. I have a few more comments I'd like to make to amplify the webinar.

Other Resources
There are many informative books available on the subject of cloud computing such as The Cloud at Your Service by Rosenberg, Cloud Computing for Dummies by Hurwitz, and many others (see listing here). Furthermore, the Homeland Security News Wire website has a wealth of information on this topic.

Security
This is largely a matter of how well a system is planned and implemented. There is no such thing as 100% guaranteed security in-house or in the cloud, though obviously, in-house is more under your control and is afforded better protection under the law. IT security techniques and practices have evolved over many years and need to be applied to SCADA and MES systems just as they are applied to front office systems. This is especially true for cloud deployments. We have developed Ignition with this in mind so you can leverage proven, standardized IT security practices.

Latency
We discovered this the hard way with a system where the Ignition server was 3,000 miles from the PLCs and clients. This wasn't exactly a cloud system but rather a WAN for a large company.

The elementary math principle of zero times any number is always zero says all. When you press a button in a SCADA system to start a pump there are many transactions involved. Client to server, server to PLC, PLC to server, and server back to client. Also, each of these has handshaking involved which involves more trips. Each leg has its own latency and variability of latency.

When the latency is very low as in a local network, the effects are usually negligible. When there are hundreds of milliseconds of latency in each leg, the accumulative effects can be intolerable. And the variable effects of latency can cause a system to look unreliable.

The Patriot Act
Data located on your physical premises is treated very much differently than your data in the cloud. You should see the Patriot Act Hang-up in the Cloud post by Michael Overly on this matter. This post gives some insight to a question asked by one of our webinar attendees. You should also check out the Forrester Research Cloud Privacy Heat Map for international cloud privacy information. Remember that when you host in the cloud, the hosting server could be located anywhere in the world.

Reliability
Every company will need to answer the question, "How much downtime can I tolerate?" for themselves and then decide accordingly whether off-site hosting makes sense or not. One company decided "no worries – we have redundant ISPs" only to have both providers go down for the better part of a day.

I hope these comments are useful. Some of the questions that were asked at the end of the webinar were intriguing. I will try to answer some of the questions in subsequent posts.

Dukes Choice Award 2011 - we won!

Colby and Carl spent all of last week at Oracle's JavaOne convention in San Francisco. At the show, Oracle awarded Inductive Automation the Duke's Choice Award for Innovative Industrial Software.

According to Oracle "The Duke's Choice Awards celebrate extreme innovation in the world of Java technology and are granted to the most innovative projects using the Java platform." There are only ten Dukes Choice Awards given each year so we are very honored to win. Colby and Carl said they were treated like mini-celebrities during the entire convention.

There were about 45,000 attendees at the joint OpenWorld /JavaOne convention this year. The JavaOne attendance alone was estimated at double that of last year. Java is clearly on the rise.

Carl and Colby were interviewed at the show and you can watch it here. Great job guys!

Ignition 7.3 Beta now available

Ignition v7.3 is now available for download by request. Please register on our support forum and then contact us to give you access to the Beta Download part of our forum. If you have not already done so, please register at: http://www.inductiveautomation.com/forum/

While there are hundreds of improvements and new features in this release the following are some of the major ones:

• Drawing tools added for vector graphics.
• Zooming in the Designer.
• Better grouping support for components and shapes.
• New Symbol Factory module.
• More efficient serialization format for windows.
• Better color-choosing UI.
• Internationalization in Gateway/Designer.
• New compression algorithm for analog SQLHistorian tags.
• New ability for SQLHistorian to create preprocessed history tables for better query performance over long time spans.
• New query cache in the client to avoid unnecessary repeated querying of the same time span.
• Data density histogram on the Easy Chart for SQLHistorian pens.
• Improved memory usage for SQLTags in the Gateway.
• Automatic SQLTag creation when dragging and dropping OPC items.
  
• Improved performance and scan class settings for SQLTags (one-shot, triggered on-change, subscribed vs polled).
• Improved memory usage for ControlLogix driver.
• Improved performance and stability for all drivers.
• Improved installer allows choosing individual modules on install and upgrade.
• New graphical and command-line installer for Linux.
• Ignition installation directory structure changed.

Please realize that this is an early beta and so it should not be used in production.

I've been using this release for a while now and it is a joy to use. Working in the designer is a fluid experience. The new 2D drawing tools exceed anything I've ever used in any other package and now with the inclusion of Symbol Factory graphics development is lightning fast.

Please call us with any comments or suggestions on this new release.

Running Ignition on Panelview Plus 6 update

In my post entitled "Ignition runs of Panelview Plus 6", I stated that "One good thing is that the logic modules are separable from the screen unit and you can upgrade your logic modules using the Rockwell Step Forward program."

As it turn out there are some exceptions. According to the Rockwell KB, the following display modules have 5-wire touch screens, and therefore will not work with the newer Panelview Plus 6 logic module:

2711P-RDB7C / Series A, all revs
2711P-RDT12C / Series A, all revs
2711P-RDB12C / Series A, all revs, Series B Rev A

The newer units use a more robust 8-wire touch screen. I would recommend that you verify your own display module's compatibility with the newer logic module (through Rockwell) before deciding on a course of action.

Inductive Automation - Where Did the Name Come From?

Every so often I get asked the question of how did we come up with our name "Inductive Automation." I think Carl first suggested it and and it stuck. This is probably because it's such a fitting name - let me explain...

From Wikipedia "Inductive reasoning, also known as induction or inductive logic, is ... commonly construed as a form of reasoning that makes generalizations based on individual instances. " That's precisely what we did when we created the framework for what was to become the Ignition platform.

Before we wrote a single line of code, I developed a philosophic stance in response to my specific experiences in the controls integration business. In other words, I established generalized principles from my specific experiences and observations. Therefore the "Inductive" part of Inductive Automation is very appropriate.

The Observations
My experiences and observations were many and varied but they boiled down to the following:

1) I was frequently being asked to develop or integrate database applications into industrial systems but industrial software just didn't deal with databases and when it did it was ugly. Developing "one offs" with custom code was not economically feasible, nor was maintaining it in the longer term.

2) Unreasonable pricing for industrial software alone was killing way too many deals. I lost one customer (for a few years - he's back now) because he thought I was trying to rip him off. The whole job was $105k but $85k of it was software which we had to buy. I'd already pared down my labor to $20k due to the high overall price tag. In retrospect, it's better I didn't get that job because my labor was so low I would have lost money.

3) Installing industrial software alone was a huge time consuming process. For an integrator you would think this would be a good thing because it's usually billable. But I would rather be putting my time toward developing a better app - not installing software.

4) Most industrial software only runs on certain versions of Windows and when IT wants to upgrade, the whole process usually becomes a nightmare – if not impossible – forcing IT to maintain different flavors of Windows.

5) Realizing the full potential of industrial software wasn't possible due to lousy deployment models and lousy licensing models.

6) I observed that standard IT software and technology was inexpensive and worked better than what I saw as expensive, non-standard, convoluted, odd-ball industrial software.

7) I also saw that the simple task of logging PLC data to an SQL database server was being portrayed as rocket science or something. Why should it take hours or days to setup a process historian? Our programmers who came straight out of the university at first had a hard time understanding what the big deal was. Nor could they understand why a historian should sell for $30k or more. They finally concluded that this industry has had the wool pulled over its eyes for a long time and that it's about 10 years behind the IT industry in general.

8) When I even mentioned the possibility of a web-based solution to customers it instantly hit a chord with them.

9) Most industrial software scaled poorly, strictly from a technology standpoint. In fact, at a certain point of scaling up maintaining it effectively usually becomes impossible, whereas normal IT technology scales very well with little effort.

10) Industrial software security was non-existent or oddball at best whereas standard IT technologies pretty well have security figured out.

11) Generally speaking, canned middleware applications offered by industrial vendors are totally out of touch with anything customers actually need. In reality, every manufacturer already has its own processes developed out of its own experiences in dealing with situations. The point is not to redefine these processes, but rather to automate them in software.

The Principles Concluded
So what are the general principles I derived from all these experiences?

1) Don't reinvent the wheel. Well established, proven and inexpensive IT technologies already exist. Use them.

2) The more eyes on the data the more useful a system is. Accessibility is paramount. Therefore leverage web-based technology.

3) Be database centric. This aligns with the principle #1 above. IT departments can support database servers (which do need backups and maintenance from time to time). Be able to support any database server an IT department uses. Database servers form the ideal interconnection point between different software applications and greatly increase the usefulness of any software application. Islands of information and proprietary data repositories are a bad thing.

4) Avoid software that imposes arbitrary limitations just to make more money. From observation, this really jacks people up.

5) Be cross platform. This includes every flavor of Windows as well.

6) KISS (Keep It Simple Stupid). Software should never be more complex than is necessary. Avoid bloatware. Avoid heavyweight installations. Software should seem lean and mean and refined.

These are the general principles I started with and when I did so I wasn't even planning to start a software company (look at the first principle again). All I wanted to do was find software out there that met these criteria. I spent several months looking exhaustively and only found isolated bits and pieces out there. Therefore, I took the plunge and started a software company. Our guiding light has always been the above principles and they seem to be good ones because we now have thousands of installations in over 50 countries.

Ignition runs on PanelView Plus 6

More than one customer has asked us if Ignition clients can run on PanelView Plus 6 operator terminals. Since PanelView Plus 6 terminals run on CE we figured it should work when using the Mobile Module. It turns out this is only partially true. The newer logic module, which runs CE version 6.0 with extended features (that last part is important), can run Ignition using the Mobile Module.

Rockwell was kind enough to provide us with a unit to try this out. The exact part number they provided us was 2711P-T12C4D9, which includes the extended features. My understanding is that the term extended features means it can run third party software and is packaged with a Word viewer, Excel viewer, PDF viewer and Media viewer. In this case we copied the open-source .NET VNCviewer.exe application onto the PanelView Plus 6 using a USB stick. This application works with the Ignition Mobile Module to deliver Ignition applications on the PanelView. VNCViewer can reference a separate configuration file with parameters to make it run in full screen mode, use 16 bit color and other settings.

While the Mobile Module normally utilizes the HTML 5 canvas component to deliver mobile applications, it is also a VNC server. The configuration for this is under the advanced checkbox in the mobile configuration section of the gateway. It's important to fill in the name of your project in this section.

Launch Clients Using the ME ActiveX Program Launcher
We got fancy and launched our Ignition client right from a PanelView application using the ME ActiveX Program Launcher. This ActiveX control is provided with FactoryTalk View ME. You must set the "program source" to path\vncviewer.exe and can set the "program parameter" to your VNCViewer configuration path\file.

One of the interesting things about this is that when your Ignition client is in full screen mode and you quit out of it, the VNCViewer also terminates. It seems to take a second click to do this.

Proof of Concept – Details Available Upon Request
This test was just a proof of concept. I'll write up all the fine details I know of and I will make them available to anyone who inquires. For example, I can provide you with my VNCViewer configuration file or project settings to make your screens scale properly without scroll bars.

I would not call the performance snappy, but depending on your situation this could be a good solution for you if you're trying to minimize the number of terminals on your floor. I would say give it a try and then decide.

One good thing is that the logic modules are separable from the screen unit and you can upgrade your logic modules using the Rockwell Step Forward program. The cost is somewhere between $1,100 and $1,500 with trade-in of your old logic module (which saves you $400 - $600 depending on the model). My understanding is that not every distributor supports this program, but I know Rexel in Sacramento does because they gave me this pricing.

FactorySQL Under the Hood

FactorySQL brought magic to the plant floor. It would have been called "Yesware" except that name was already taken. This is because you could say "yes, I can do that" to practically any PLC to SQL database interaction you could imagine.

Want to log PLC values? No problem. Want to send recipes to PLCs? Go for it. Want to mirror PLC addresses in the SQL database so that web pages can display and control PLC values? Go for it. Want to copy whole sections of PLC memory to another PLC somewhere else. Yes you can. In fact, the possibilities are endless but they boil down to being able to say "yes, I can do that" while everyone else is shaking their heads "no."

I've had two integrators sit beside me on a major project where all they ever said was "I'm not sure how we'd go about that" and all I ever said was "don't worry, we'll take care of it," and then we would, usually in minimal time. The other integrators looked kind of dumbfounded because I kept doing this. But my secret was FactorySQL.

Well, now we have Ignition and under the hood we still have FactorySQL but it's no longer called that. Now we call it the SQL Bridge Module. But it does all the same things and more. For example, you can make programming changes while groups are running without interrupting anything, just like online programming changes in a PLC.

I fear one thing though. With all the excitement about the Ignition platform I'm afraid we're neglecting to tell people about the real power they have under the hood with the SQL Bridge Module. The other day when one of the sales people showed it to someone they were blown away by what they saw - they could hardly believe what they were seeing was true.

So my message to you... check it out. You'll be amazed at what you can do.

Does OEE really work?

You've heard about OEE for years now. But does it really work? I've got a story for you but first I'd like to comment that OEE is just a tool. You can either use it, abuse it or neglect it.

Some months ago one of our end-users installed the OEE module at one of their facilities that has a lot of lines. A lot of data has been collected but only recently did the production manager started analyzing it. His attention was drawn to one machine on one line by reason of the OEE. On closer inspection he determined the machine was pausing at times for no apparent reason so he called in maintenance. It's not unusual for automated machinery to slow down or pause due to low product supply or backup conditions but this just didn't seem right. By monitoring the PLC logic maintenance was able to trace the problem to an intermittent field IO block that sometimes gave false state information for some photoeyes.

After the part was replaced the OEE jumped up by 10%. They had accumulated a baseline of OEE information and just by replacing this one part the OEE increased dramatically. In this case the faulty component didn't entirely stop production so its effects weren't obvious. It just made the line not run as well as it could.

This brings me back to the main point. For OEE to work it has to be properly implemented and then the resultant data need to be acted upon. When this is done the results can be significant.

Is bloatware really necessary?

There was a thread on our forum recently that made the point of how fast and easy it is to install Ignition. I am so glad to see people notice this. It's a big thing. Just imagine your HMI/ SCADA/ MES server just crashed - like a hard drive failure. Now tell me how long it would take to reinstall, reactivate and get all of your projects functioning again. I shutter to think about how long it would take to restore some traditional systems.

With Ignition you're talking about minutes. Seriously, minutes. Even if you have fifteen projects on that one Ignition server this still holds true. (Is it even possible to have fifteen projects on a traditional HMI/ SCADA server?) You just download Ignition via Internet (a few minutes), install Ignition (a few minutes) and restore your single backup file (a few minutes). And with that single file restore all of your communication settings, database settings, project settings - everything is restored and you're good to go. And it will run for two hours at a time fully functional until you reactivate the license which only takes a few seconds. Some traditional systems make licensing reactivation a nightmare - that's crazy. Like kicking a dog when he's down.

Getting back to the main point, I'm really glad our easy install is being noticed by our users. We have so many firsts with Ignition it's easy to lose that message.

The question is, why are we the only ones? IMHO, I think most traditional software was created in the 90's and then tacked-on to, band-aided, and wrappered until it became bloatware. Possibly, as time moved forward and developers came and went (face it, no publicly held corporation is going to keep good developers for very long) later developers didn't understand what earlier developers did so they hacked. How else do you end up with GB installs now requiring DVDs for relatively simple applications?

Then again, maybe I'm wrong. Maybe it was just a lack of good vision and planning from the start. I don't know. All I do know is that it doesn't require DVDs, GBs or hours or days to install and restore a system unless you make it that way.

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.