Web-based HMI: from 2002 to present day

In 2002 Rockwell Automation wrote an article called Web-Based HMI: Beware of the Fiction and said, "If all you need to do is to look at a snapshot of historic information, then yes, the Web can do that. But if you need real-time plant floor monitoring and control, if you need to know immediately when some aspect of your system changes, if you need an alarm system that will notify you the instant something goes wrong, the Web is not yet able to provide that solution".

That was totally thinking "inside of the box", even in 2002, so in 2003 I wrote a counterpoint article called Web-Based HMI: An Emerging Trend? I concluded that article by saying, "Users are finally getting what they want – the functionality of an HMI with the economics of a web browser. The real question is not whether web based control systems are an emerging trend – they cannot be stopped, but rather which vendors are poised to jump on the bandwagon and deliver the technology."

Seven years have passed since then and where are we now? Today everyone has a web-based human machine interface available, even Rockwell. But there is one big huge difference between the players – the licensing model. The real question is, is it being sold by the server or by the seat? I almost choke every time I see a decent web-based system sold by the "named user" (which is actually a eupherism for "sold by the seat").

My 2003 article referenced a book called Seeing What's Next by Christensen, Anthony and Roth. The book introduces theories to predict major industry changes which I think you'll find interesting and which I think shed light on this industry. You should check it out on some rainy day.

OPC-UA development from the spec

It's amazing what you can accomplish when you abandon preconceived notions. This weekend I toured the SS Red Oak Victory in the old Richmond naval yards (in Richmond, Calif.). The shipyards there were built in WWII. Kaiser built Shipyard #1 in 55 days! But what was even more amazing is that they built ships like the SS Red Oak Victory in something like five days. Can you imagine how long either of these feats would take today?

Well, I think our developers are equally amazing as the builders of these ships and shipyards. They went along blissfully developing the worlds first Java OPC-UA server (and client) directly from the spec and didn't think anything about it. You know, normal day. They didn't know that they were the first. And they also didn't know that it was such a big deal to have written it from the spec. They went to an InterOP conference and found out that no one else had and some folks there were sort of drop-jawed.

Well, that's what really gets me excited around here. We get an idea of what we want to do, and then we do it. No one ever says "that's impossible" or whines "that's hard." If it makes sense we just do it. And believe me there is nothing helter-skelter going on around here either. We look WAY into the future and everything we do aligns. We very carefully study the technology trends and we always plan accordingly. Very soon we'll have another often-requested module that I would classify as nothing short of amazing – of course! And as always, it will be based on open standards. Stay tuned and I'll release details as soon as I can.

Building Applications in Earthquake Territory

Nothing is worse than building your applications on a platform that's constantly in flux. When that platform is your very foundation, your apps are sure to crumble. Take for example COM and DCOM (superseded by .NET stuff), Mobile Windows (abandoned in favor of Windows Mobile 7), VBA (as of July 2007 Microsoft no longer offers VBA distribution licenses to new customers) which has been replaced by a whole string of stuff including Script for the .NET Framework, then VSA (Visual Studio for Applications), but that was deprecated in favor of Active Scripting, but then that was replaced, as far as I know, by VSTA (Visual Studio Tools for Applications) which programs against the .NET Framework. This last one requires purchasing the Visual Studio development environment and compiling your applications.

I couldn't stomach building on a shaky foundation like that, so we didn't. You also won't find me building a home on the San Andreas fault (San Francisco / San Jose area).

From a developer perspective, my vision was and is to develop on a platform that doesn't change for the sake of change. If it's going to change then I want it to change for a good reason. I think that the Java platform accomplishes just that. That is what we wrote Ignition in.

But what about the people who use Ignition? Well, they get Python. A beautiful, forgiving scripting language. No compiling, and it's just the same as it was seven years ago. If we do anything to it at all it will be to embed a newer version which will add features but not take any away.

Hey! Spectrum Controls, Moxa, Online Development, et al

Hey guys, I've got a great idea for you. Why not make an OPC-UA-to-protocolX converter box. Maybe it could be an in-chassis card for PLCs or maybe something like the WebPort 500 (an external DIN rail mount box with serial to various PLCs using various protocols).

I mean, ideally, PLC manufacturers would build OPC-UA right into their PLCs. I say this because it's extremely secure, platform neutral and it accommodates any shape data structure. But you and I both know why that might take a very long time. So that presents quite an opportunity for you.

Right now, Modbus TCP is the lingua franca (universally spoken language) and most PLC manufacturers build it right into their PLCs in addition to their own primary protocols. I love Modbus TCP because it's open, fast, simple and ubiquitous. But it's not so secure and as far as I know it only supports elementary data types. OPC-UA is destined to be its successor since it answers these and a host of other problems.

The recent OPC interop conference in Germany (which we recently sent a couple of developers to) was a good indication of what to expect of OPC-UA. The number of OPC-UA servers and clients tested at the conference nearly tripled from just a year before – showing that the use of OPC-UA in the industry is growing fast.

So I bring it up now. I think the OPC-UA converter box (or in-rack card) is a great idea. If I was in the hardware business I wouldn't be telling you this – I'd be doing it myself.

Python - The Cartoon

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

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

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

Ignition - What's the Catch?

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

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

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

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

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

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

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

The Sheer Joy of Python

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

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

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

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

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

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

Running Ignition on HP-Unix???

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

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

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

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

Where's the price?

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

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

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

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

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

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

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

How many patches did that take???

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

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

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

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

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

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

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

Why Java?

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?

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

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

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

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

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

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

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.