Computing Without Boundaries

Object-Oriented SCADA in Ignition v7.4

2012-01-15T10:55:00.000-08:00

Object-oriented SCADA speeds development and increases maintainability since screen objects can be derived from templates. If changes are made to the template, those changes propagate down to each derived object so objects don't need to be dealt with individually. That could save a ton of work and rework. This is on the visual layer.

Parallel to this is the data layer. The data layer consists of user defined data types, which are referred to as UDDTs or UDTs. Tag database instances of UDDTs, when combined with screen object instances, take development speed to a whole new level. In fact, productivity could be increased 10- to 100-times when compared to systems without object-oriented capability.

Ignition 7.4 will feature object-oriented capability both for screen objects and UDDTs. We may not be the first to implement this, but we will be the best. We learn from other people's mistakes. When we first mentioned we were developing this at one of our training classes, about half the class winced and told us to be very, very careful about implementing it. They told us horror stories about other packages that were really complicated and buggy.

You'll have wait to see it at our 7.4 release (in February), but we've made it ridiculously simple to use and we've included productivity enhancements no one else has. Project development will now be faster in Ignition than in any other SCADA software.

The case for using Ignition on a competitive basis is now a "no-brainer." Look at the following facts:

1) Lower cost pricing model because its sold by the server, not by seat, tag, designer, screen, etc.

2) Installs hassle-free on any OS, including any newer version of Windows.

3) Installs in just minutes.

4) Super fast development.

5) Lightning fast, hassle-free and secure client deployment on any PC or mobile device.

All these are competitive factors. They have to do with winning projects and making them profitable. Now with object-oriented capability in 7.4, all vectors align to provide unbelievable, competitive firepower to those quoting Ignition. Who ya gonna call?

More About Cloud-Based SCADA Systems

2011-11-22T13:30:00.000-08:00

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!

2011-10-13T04:19:00.000-07:00

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

2011-09-08T13:39:00.000-07:00

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

2011-09-07T10:32:00.000-07:00

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?

2011-08-11T12:52:00.001-07:00

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

2011-08-09T16:43:00.000-07:00

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

2011-06-17T18:01:00.000-07:00

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?

2011-06-04T10:53:00.000-07:00

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?

2011-06-02T13:06:00.001-07:00

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

2011-04-20T10:06:00.000-07:00

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

2011-04-15T08:13:00.000-07:00

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 certain 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

2011-04-07T10:15:00.000-07:00

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?

2011-02-28T13:48:00.001-08:00

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

2011-02-18T12:02:00.000-08:00

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?

2011-02-03T21:10:00.000-08:00

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)

2011-01-28T13:15:00.001-08:00

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

2011-01-09T19:00:00.000-08:00

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

2011-01-05T21:09:00.000-08:00

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

2010-12-21T00:37:00.000-08:00

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

2010-12-08T22:40:00.000-08:00

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?

2010-12-07T21:19:00.000-08:00

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

2010-12-01T08:00:00.000-08:00

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?

2010-11-30T06:00:00.000-08:00

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

2010-11-22T08:00:00.000-08:00

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

2010-11-18T19:00:00.000-08:00

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!

2010-11-09T12:00:00.000-08:00

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

2010-11-05T08:00:00.001-07:00

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?

2010-11-03T08:00:00.000-07:00

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?

2010-11-02T08:00:00.000-07:00

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

2010-10-25T08:00:00.000-07:00

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

2010-10-20T08:00:00.000-07:00

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

2010-10-19T08:00:00.000-07:00

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 or 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

2010-10-18T08:00:00.000-07:00

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

2010-10-15T08:00:00.000-07:00

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

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

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

Ignition - What's the Catch?

2010-10-14T08:00:00.000-07:00

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

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

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

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

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

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

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

The Sheer Joy of Python

2010-10-13T08:00:00.000-07:00

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

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

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

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

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

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

Running Ignition on HP-Unix???

2010-10-12T08:00:00.000-07:00

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

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

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

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

Where's the price?

2010-10-07T08:00:00.000-07:00

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

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

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

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

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

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

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

How many patches did that take???

2010-10-06T11:08:00.000-07:00

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

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

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

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

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

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

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

Why Java?

2010-09-27T08:00:00.000-07:00

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

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

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

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

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

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

OPC-UA - Why change now?

2010-09-22T08:00:00.000-07:00

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

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

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

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

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

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

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

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

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

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

2010-09-21T08:00:00.000-07:00

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

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

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

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

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

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

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

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

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

Modbus TCP - Lingua Franca

2010-09-20T08:00:00.000-07:00

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

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

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

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

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

The perfect complement to PLCs

2010-09-17T08:00:00.000-07:00

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

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

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

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

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

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

Process Historians vs. SQL Databases

2010-09-16T08:00:00.000-07:00

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

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

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

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

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

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

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

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

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

"Sounds too good to be true."

2010-09-15T17:09:00.000-07:00

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

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

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

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

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

The Three-Minute Misconception

2010-09-14T22:57:00.000-07:00

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

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

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

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