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.