The New SCADA

When we describe Inductive Automation and Ignition, there's just so darn much to say.  But I've found a way to boil it down to three words ----- The New SCADA.  You'd be missing the point if you thought I was just talking about new features. What I'm really talking about is the New User Experience.  What I'm really talking about are the Four Pillars we're built on, which are the reason why we're the fastest growing SCADA company in the world.

What are the four pillars?  1) New Technology Model,  2) New Licensing Model,  3) New Business Model,  4) New Ethical Model.

Let's start with the last one, New Ethical Model.  How many SCADA companies have sold out? And what happens to their end-users, integrators and employees after they do?  What happens to the vision and innovation after the founder is gone?  What are the ethics when a few people become enriched at the expense of an entire user base and thousands of supporters?  We've been approached several times and we aren't selling out. We're all about reinventing the industry and delivering the New User Experience and that's what motivates us.

How about the New Business Model?  Most SCADA companies are just Marketing Companies.  Is there any real innovation?  Well I don't see anything meaningful.  Our New Business Model balances Development (new innovation), Quality Assurance, Marketing, Sales, Support, Accounting, Training, and about 20 other functions into a well functioning pipeline all focused solely on delivering the New Customer Experience.

Now let's talk about the New Technology Model.  We're not talking about new or more features - that's just background noise; what we're talking about is a whole New Paradigm.  ARC Advisory Group says we're disrupting the whole SCADA industry.  They're right.  Who else can do a fully featured install in about a minute?  Who else can run on practically any OS (including any version of Windows)?  Who else developed an elegant system from the ground up with a holistic approach, rather than a short-sighted, bolted-on, hacked up and unmanageable mess?  If I were to list all our innovative firsts it would take a hundred pages but all these are just different aspects of the same thing - a totally new and sensible Paradigm.

Finally, there's the New Licensing Model.  It's the zero hassle licensing model.  An unlimited licensing model, sold by the server, with a single affordable price no matter how many clients or tags are used.  And we're not talking about flimsy web browser clients.  We're talking about real client applications that launch as easily a web page (it's pure magic).  The conventional licensing models out there are antiquated and only deliver marginal value.  We have a sales tactic - you might as well know it - get people talking about their experiences with conventional licensing.  We get a bird's eye view of thousands of really pissed-off people.

The three words - The New SCADA - aptly define Inductive Automation and Ignition.  I didn't just wake up one morning and say "Hey! I have a great idea, let's start a SCADA company!"  No!  If even one SCADA company had even a semblance of the four pillars, I would have used it and Inductive Automation would never have been born.

I love the software and company we've created.  But more, I love the Community that's formed up around it.  If you missed our ICC in 2013 then you missed something HUGE - the Community.  In twenty-five years I've never seen anything like it, and frankly, I'm completely taken aback, and humbled, by your faith in us. Thank you.  That's why we're here and that's why I get out of bed in the morning. If sometimes I seem a bit gruff, it's not motivated out of greed - rather, it's motivated by my sense of responsibility to keep the show on the road.  It's more about managing risks so that we can keep this phenomenon going and growing, and so you'll still find us here, an even better company, in twenty years.

I think the madness of grow fast or fail fast, and then sell if successful, is just that - Madness.  What about the people who made it successful? Well, we're not going down that road.  We love what we do, we love this Community and we really do want to make the world a better place!

So there you have it - The New SCADA!

Ignition Playback Templates

The other day I was wondering if I could create SCADA "playback" using standard Ignition components. I decided to try by using Ignition templates to create a "playback controller" and "playback container"  so that a controller could be dropped into a project and containers be bound to it.  Each container would contain a single SCADA object such as a gauge, tank, readout or whatever.

This turned out to be a really easy project (with a little help from tech support).  First, history needs to be turned on for each tag to be played back.  It just takes a check mark on the tag.  This can be done en mass with the multi-selection of tags.  Dropping the controller into a project gives a bindable property called Date_Time".  This property provides the date and time to display and increments forward from the selected start time at the playback speed selected.  That's all the controller does - specify time (selecting "RT" means realtime, gives the improbable year of 1900 which tells the containers to display realtime directly from the tag value.  I only wanted a single property to bind to).  The "playback container" uses the date and time from this property to query the tag historian for a value.


The "playback container" has some display objects on it which exist only for demo purposes.  Make a copy of this template, delete all the display objects, and add your own display object. Bind your display object's value to the container's "Value" property.  Now drop your new container object into the project as many times as you want.  For each container fill in the "Tag" property with the tagname. If the default database for your project is different from your History Tag Provider, add the name of your history provider in front of the tagname.  For example, [MyHist]N7:0.  Otherwise, just the tagname will work.  Then bind the container's "Controller" property to the "Date_Time" property of the controller.  That's it.


Selecting a date/ time out in the future will give the current values as they are logged because the query is configured to select the "Closest Value" (and the current value is the closest to any future value).

I exported these templates to a .proj and you can download them from here.  I built them in Ignition version 7.6.3.

DISCLAIMER:  These templates should not be considered "production ready" nor should they be considered a product of Inductive Automation.  They were just a "proof of concept" and I was just "an integrator having fun messing around."  It didn't take long.  Just dissect them and see how I did it. There are probably many other ways to accomplish the same thing.

When XP support ends next year, Who ya gonna call?

It was just brought to my attention by one of our customers that XP support will end next year.  That really pricked up my ears because tens of thousands of HMI, SCADA and MES systems (if not more) will require upgrading.

Now the shameless self-promotion part (sorry, I can't help it)...  When we say Ignition is cross-platform we mean it also runs on most versions of Windows right out of the box.  Usually people think we're just talking talking about Linux, Unix and OSX, but we also mean Windows.  Just saying.

Guerrilla Troubleshooting Tactics

I created a training video over ten years ago called Guerrilla Troubleshooting Tactics which simplified and codified successful troubleshooting patterns.  I recently realized it has broad applicability in other areas of our business here at Inductive Automation so I thought I would share the key points of it with you.

Troubleshooting procedure is very distinct from the technical knowledge of something.  Anyone can follow this procedure up until the last step, even if the're not technical, and troubleshoot successfully.  Sometimes it's just asking the right questions of someone who does have the technical knowledge.

The following simple questions are arranged in the order given so as to pick the low hanging fruit first.  A frequent mistake is to dive into too much detail with too little information too early. Here are the steps:

Diagnostic Sequence

1)  What is the problem?
2)  How is it supposed to work?
3)  Did it ever work?
4)  What changed?
5)  What else is affected?
6)  Has it ever happened before?
7)  Why do the affected outputs act this way?

A little explanation about these steps is in order.  Remember, the order of these steps is one of  trying the easy things first.  The problem could be, and many times is, resolved on step one.   The procedure shouldn't take very long - sometimes only minutes.

First Step
The first step is to get a clear description of the problem - obvious, right?  Yet, I have personally made the mistake of getting only a partial description to a problem and then taking off on a tangent (half cocked as they say), only to later have to back up and restart.  Take your time and get the whole description.  Another point is this... if they say there is a problem, there is a problem.  Sometimes troubleshooters "blow off" the user as "using it wrong" or being "nuts" or something.  But the troubleshooter should always assume full responsibility for the system and the person using it.  It's an end to end approach.  If the problem is how the user is using it, then this should become the target of the successful troubleshooter - education of the user.  Sometimes when doing this you discover something really is wrong with the system and not the user, which is a bit embarrassing, though productive.

Second Step
You'd better know how something is supposed to work before you attempt to "fix it."  It's really hard to fix something that's operating normally!  Sometimes the design is so poor you assume it would never work that way, but that would be a bad assumption on your part.  How would you get this information?  Ask the user and verify it with a manual.  You can Google a manual or other information on practically anything these days. You don't sit there and read the whole manual.  But get good at scanning quickly and picking out the relevant info.  Sometimes asking the user is sufficient because they most familiar with the thing (they are the user aren't they?)  If that leads you astray or into confusion then resort to the manual or use your own common sense.  This step is vital since troubleshooting is done by comparing how something is... to how it should be.

Third Step
When working with "one-off" systems the step, "did it ever work?", is vital or you'll waste massive amounts of time. Your approach will be totally different if it's never worked versus the case where it did work and then something changed and it stopped working.  The first case means the development-debugging process was never completed.  That's an engineering concern and the reason it doesn't work could be one or many reasons or even owe to a fundamentally flawed design.  In most cases that's where the troubleshooting ends and it goes back to the designers, or if not, at least you know what you're up against.  But if you can ascertain that it did work at some point then you've got something you can work with.  Now you've got certainty and a starting point.

Fourth Step
When you ask "what changed?" the response is often "Nothing."  But here is your stable datum - something changed - or else it would still be working.  So you might have to ask "when it was working fine?", and then ask "when did it stop working?"  Getting them to place it in time will often get them to realize what it was.  It will be something like "oh yeah, we changed such and such."  This is usually the point where the light bulb goes off and it will lead you right to the solution.  There is one caveat though.  Before you arrived on the scene someone else might have been troubleshooting it, and if they used a shotgun approach they could have caused new problems in addition to the original one.  They might have replaced parts with whatever was on hand which are the wrong ones.  They might tweaked and adjusted things out of desperation and thrown things out of alignment.  So you have to ask about what steps were taken exactly before you arrived, and in many cases you will need put every back to the original state before starting your troubleshooting.

Fifth Step
Usually the problem will resolve on step four.  But with particularly stubborn problems it's time to step back and look at the big picture.  Look for other things that depart from what they should be.  In step two you determined how it's supposed to work, so now try to find anything else that's affected adversely.  Things like, "oh yeah, memory use is also high", or "this component is also unusually hot."  Once you determine the other things that are affected, try to determine what the common denominator is.  That might lead you to the problem.  But be aware if there are multiple problems you could get really confused doing this step.  If that happens, factor into your thinking the multiple problem possibility and see if that helps.  If not, then go to the next step.

Sixth Step
Has it ever happened before?  Some people think this should be the first step and sometimes that works. But I have found that more often than not it can lead you astray if you haven't done the other steps first.  These steps are designed to lead toward greater understanding, whereas if you do step six first it's just rote procedure.  The point of the diagnostic sequence is to proceed methodically and with certainty toward problem resolution.  Doing step six first not only misses the root cause but also can lead to shotgun troubleshooting (a bad thing).  But if you've done the preceding steps already, you can now safely ask for previous similar problems and their resolution or look into the maintenance logs.  You can also call the manufacturer for help.  If they are any good they are going to ask you  steps one to five anyway.  Steps one to five put step six into the proper context.

Seventh Step
Why do the affected outputs act this way?  Malfunctions will usually show up as misbehaving outputs. Reports will have bad numbers.  Motors won't start.  Screens won't display.  Up until now any lay person with little or no technical knowledge could perform the diagnostic sequence and win in troubleshooting.  But on this step you need the technical background.  Fortunately, most problems resolve before this step.  But even without a technical background the lay person can direct the technician on this step to success.
The technician on this step traces logic, wiring, hydraulics, pneumatics, or  whatever the system consists of, back from a defective output to the exact thing that is causing the malfunction.  When there are multiple problem causes this step is usually the only one that works.  In this case it is an iterative process (trace one problem, trace the next, etc.).  As mentioned before, multiple problems can exist due to prior shotgun troubleshooting being done, but they always exist during the development-debug phase of any product or project. During this development cycle there are often hundreds or thousands of problems to rectify.  That's why you ask if it ever worked as in step three.  Sometimes projects are left unfinished or a few bugs slip by.

There are a few other factors to keep in mind.  If the system ever worked then odds are there is only single problem to find.  This procedure will help you find it quickly.  When things start getting complicated you should suspect multiple problem causes are present.  Start asking about prior troubleshooting attempts.  Another approach is to back up a step or two.  Maybe you missed something.

Another thing to know is that users will tell you all the things they have tried.  I recommend you verify everything for yourself and not trust their narratives.  I've been led astray by before I.e. "I tested all the fuses and they're all good" only to discover half an hour later that one of them is blown (they didn't know how to properly test fuses).  Only by moving forward methodically and gaining your own certainty of things can you conquer the problems.  Sometimes you need to be tactful and say "Please don't be offended if I recheck a few things. It's part of the procedure I use."  People are never offended, they're just glad you're there to help.

Realize that when you come onto the scene, people are really confused, or else they would have solved it already. Don't let their confusions become yours - rely on your procedure.  They will tell you all types of things. They will even tell you they have tried everything and try to tell you why it can't be fixed.  They are just trying to justify why they couldn't solve it  - they are usually embarrassed - so be kind.   Take their data (you need it) but don't take their recommendations - trust only your procedure and win!

Sequential Function Charts in Ignition

You say, "sequential function charts, who uses those?"  Turns out lots of people do.  Sequential Function Charts (SFCs) are part of the IEC61131-3 programming languages.  One usually thinks of SFCs as a PLC programming language, which is true, but SFCs are also used in industrial software applications quite extensively.

Personally, I seldom used SFCs in PLC programs.  I felt much more comfortable using ladder logic.  But customer feedback from a variety of industries shows the extensive use of SFCs in specialized application programs.  In fact, one customer calls them "everything a PLC isn't", referring to the fact that they excel in highly supervisory roles with long running processes requiring advanced logic handling capability.  

There is another aspect of SFCs which doesn't exist in the PLC version (at least not to my knowledge) and that is instantiation.  What this means is when you develop SFC diagrams you are actually developing templates, but when you run them you actually run a copy, or instance, of the template. Think of the uses.  SFCs could act like paper tracking and routing forms on the plant floor except with SFCs everything is kept in a database.  

Here's an example in the manufacture of widgets.  For every widget you plan to build you instantiate a new SFC and pass it parameters such as work order number, part number, etc.  The SFC instructions could handle every aspect of the widget's subsequent routing through the manufacturing process and would write all the information off to a database.  

Instantiated SFCs could track batches in a chemical process, discrete parts, parts assemblies, practically anything.  They could even handle the routing and tracking of front office paperwork.  Paper forms could be replaced with electronic versions which are automatically routed using instantiated SFCs. The instantiation is the form, so using actual paper forms is unnecessary.  Save a tree!

Think of SFCs as script supervisors.  Higher level SFCs determine which scripts run when. They also provide a bird's eye view of your program.  Everything you do with SFCs could be done with scripts alone, but you would quickly get lost in the details.  Additionally, SFCs can provide real-time status of scripts which are running and what conditions are required to run non-running scripts.

I'm excited about adding SFCs to Ignition because they add a whole new dimension to what you can do.  I won't give you a time frame for when they'll be done, but I can tell you the development team is well under way now.  

Why keep Reinventing the Wheel?

New software products hit the market every single week.  Most fulfill specialized purposes and it seems like most are targeted at the Oil & Gas industry.  But it makes me wonder, how many of these packages are developed from the ground up?

We talk about "the platform" all the time.  A platform is sort of like an operating system but higher up the software stack.  Why would you recreate deployment , development, security, licensing, connectivity , authentication, management and monitoring logic repeatedly when all of this could be part of a platform?  For example, with our product, all the non-specialized stuff is handled by the platform while "modules" handle the specialized part.  This allows module developers to concentrate on solving the problem and not the mundane stuff that's already been done before.

Let's look at what the Ignition platform actually does...  It is an OPU-UA Client.  It's really smart about databases in that it knows how to talk to a wide variety of them even with their subtle (or not so subtle) differences.  It optimizes database requests, handles database failover logic, handles store and forward logic, and far more.  It is also a web server and handles all the complicated details of client deployment, client communication, application synchronization and more.  It handles all the details of the unified development environment (yes, one environment for developing/ configuring any module installed in the platform).  It handles redundancy, system logging, auditing, alarming, security, authentication, licensing, the scripting engine, and if I listed everything else this post would be pages long.  The point is, 98% of your job is done when you leverage the platform.  And the point is, you know 98% will work as advertised so you can concentrate on the real problem you are trying to solve.

Most of the systems that are developed from the ground up are doomed to fail.  This is because they reinvent the wheel and with that comes a very long runway and an overwhelming amount of shaking out and fixing.  Most users aren't that patient so the undertaking fails.

SECS/GEM Driver now supports SECS-I

The newly released SECS/GEM driver for the semiconductor industry has been improved!  It now supports SECS-I (serial).  The first release only supported HSMS (Ethernet) messaging, but as it turns out, there is still a lot of legacy equipment out there and most of it only supports SECS-I communications.  You would think this to be a simple thing to implement but it wasn't that easy.  

TCP/IP has a lot of stuff built into it that gets leveraged for HSMS but when you get to SECS-I serial you lose that and you've got to build a lot of stuff from the ground up.  But that's been done now and the new SECS/GEM module can now be downloaded from our module marketplace.

We are in the process of adding simulator functionality to the SECS/GEM module as well, so that testing and development can be done in the absence of actual equipment and so that equipment definition files can be tested.  

The SECS/GEM module plugs right into the Ignition Gateway to provide seamless connectivity between tools, databases, GUI front-ends, ERP systems and more.

News Flash re OPC-UA

My recent post "Imagine OPC-UA Everywhere" has been one of the most active posts ever which indicates the high degree of interest in UA.  In that post I said once hardware providers start integrating OPC-UA into their products it will be a beautiful world, but I also said there is little motivation for them to do so.  Well the floodgates might be opening up sooner than I thought.  Invensys just made the following announcement...

"Invensys has also embedded OPC UA communications with its Triconex Trident and Triconex General Purpose safety instrumented systems. OPC UA maximizes interoperability between systems and streamlines connectivity through open platform architecture and future-proof design. The new communications interface module contains an embedded OPC UA server that supports up to 10 concurrent clients, delivering high performance and secure, reliable communication of real-time data, alarms and historical events."

The announcement just came out today.  The way I see it this is a major development in the forward progress of OPC-UA.  Who's next?

New SECS GEM Driver Availability

I've been working on a special project to develop a SECS driver for some time and it's almost here.  We'll be entering the beta test period soon.  If you aren't familiar with SECS it refers to Semiconductor Equipment Communications Standard.  Or from Wikipedia:

"The SECS/GEM is the semiconductor's equipment interface protocol for equipment-to-host data communications. In an automated fab, the interface can start and stop equipment processing, collect measurement data, change variables and select recipes for products. The SECS (SEMI Equipment Communications Standard)/GEM (Generic Equipment Model) standards do all this in a defined way."

SECS/ GEM Ignition Module

The GEM/SECS Module can stand alone in the Ignition Server for use with third-party applications or work seamlessly with other Ignition modules and projects to create rich applications. Third-party applications interface with equipment nicely by use of SQL database tables as the interface mechanism. By use of a simple definition file any SECS message (including custom ones) can be supported.  Messages can be sent to equipment simply by  inserting a row into the NewMessage table.  Responses are stored in the Message table.   Handling Complex Data SECS messages can contain complex data structures in that they can have any number of items within lists and any number of lists within lists. For this reason SECS messages are serialized into JSON (JavaScript Object Notation, in this case it has nothing to do with Javascript) strings before they are inserted into the database. JSON is a human readable data-interchange format. JSON is well supported in most languages which is why it was selected to represent complex data.  Within Ignition JSON structures can be encoded/decoded to/from native structures like lists by using built-in scripting commands. Handling Real-Time Data Some SECS messages provide for streaming real-time data.  By configuring the message definition file, data can be marked for real-time usage so that equipment responses not only enter the message table but also the real-time table.  Rows only get inserted once and get updated when new data arrives.  So there is only one row for each monitored value (or complex data structure) and it always has the most recent data .  This way the real-time table never grows beyond the number of monitored values and keeps the table size manageable and query times low.  Eventually the real-time table will be reflected out into Ignition SQLTags for drag and drop ease of use. This driver should be generally available the second quarter of 2013.

Controller with integrated OPC-UA

I said I hoped I was wrong about PLC vendors not supporting integrated OPC-UA. That was in my last post and as it turns out, to some extent I was wrong, which is good.  Matthias Damm pointed out that at least three PLC vendors are shipping with integrated OPC-UA interfaces, including Beckoff, Bosch Rexroth and B&R.

I did a little searching on Beckhoff, Bosch Rexroth and B&R to find out more about these controllers and found the Beckoff CX8091 controller right away but came away empty handed for the latter two.  I'm hoping someone can help point me in the right direction on those two.

According to their website the Beckhoff controller is estimated for market release in the 2nd quarter of 2013.  It is programmed using IEC 61131-3 languages and most importantly supports online programming changes.  As you can see, they have the OPC-UA logo in the lower middle of their product.

Another poster pointed out that SAP and iTAC (who is iTAC anyway?) have already implemented OPC-UA.  As I pointed out in my last post, it's not the software companies that are the problem.   Most pure software companies have already adopted.  It's the hardware companies that are lagging.

Kudos to the software companies who are now on-board, and kudos to Beckhoff for their new controller, but as I search the web for other hardware, particularly PLCs, with integrated OPC-UA, it is kind of spooky how empty the space is.  So if Bosch Rexroth and B&R have it then why can't I find it with a web search?  Are they just not promoting it?  Someone please shed some light on this.

In my last post I pointed out three firms that provide SDKs for embedded OPC-UA.  Matthias points out another provider is Unified Automation which provides a full range of OPC-UA SDKs and development tools for ANSI C, C++, Java and .NET.

All the tools are there, all that's missing is the motivation.

Imagine OPC-UA Everywhere

I did a little fact checking to find out if there are any PLC controllers available with OPC-UA embedded.  As far as I can tell, none are available yet.  I found a page for the OPC Technology Summit 2012 which has downloadable presentations from major automation vendors like Rockwell, Siemens, and ABB.  Each laid out their OPC-UA adoption roadmap.

How is it these presentations glow about the wonderful virtues of OPC-UA, yet you can't find a PLC with OPC-UA embedded?  (Please tell me if I'm wrong, I hope I am.) There's certainly no technological barrier preventing it. There are many OPC-UA development tools available from companies like Prosys OPC and OPC Labs. Embedded Labs even provides OPC-UA on a chip that costs less than five dollars.

Adoption Roadmap
But, there is a glimmer of hope. Each of these manufacturers has put embedded OPC-UA on their adoption roadmap. They say they are going to do it, but not one has said when. This is especially interesting when you consider Inductive Automation and most other pure software companies have had OPC-UA for years now. Works great.

So what's so special about OPC-UA? Secure, simple, cross platform, flexible, standardized.  Enough said?

Imagine OPC-UA Everywhere
Imagine a world of 100% OPC-UA.  Gets me all excited because it would take the pain out the subject of intercommunication, between devices, between enterprise applications, and between devices and enterprise applications. For example, from the Ignition server running right here on my desktop I can connect to any number of other Ignition servers running on other people's machines in just minutes. And I can connect to Kepware servers running on other machines with similar ease. Now if I only had a few OPC-UA-enabled PLCs to connect to, the world would be beautiful. I won't hold my breath.

Sadly, when I mention this beautiful vision people usually roll their eyes and sigh a wistful sigh. (Try it sometime, it's true.) They know it should be but there's a tacit reality that even though it would be right for end-users and integrators, there's little incentive for PLC vendors to be more open.

Security as an Incentive
However, there's a good reason for hardware vendors to adopt OPC-UA that has nothing to do with openness. It is the one thing they are being beaten up about and that's security. OPC-UA is very, very secure and that solves a lot of their problems. It has built-in encryption and can use certificates to ensure end-points are who they say they are. We wrote our OPC-UA client and server from the ground up (from the specification) which was no easy feat mainly because of all the security involved. And speaking of that, anyone who attempts to create proprietary security schemes based on secrecy is going to be the least secure of all. Encryption and security schemes that are exposed to general public scrutiny (like the OPC-UA specification) will be tested and vulnerabilities exposed so they can be fixed.

I wrote this post because I thought it would be fun to imagine what it would be like if the anarchy of endless communication protocols was gone and we could experience the simple, secure, and standardized beauty of OPC-UA to communicate between all devices and software applications.

Java and Manufacturing: A Perfect Match

The expectation in the controls business is that most systems should last 15–20 years. Walk through any (older) facility and it's normal to find controllers at least that old. But unlike hardware most industrial software never makes it that far. The reason can be found here in my earlier post.  Operating systems change and software technologies come and go. This wreaks havoc on most industrial software applications since they're built on top of these.

Look at Silverlight. Silverlight delivers stunning graphics with minimal programming. When Silverlight was released quite a few software companies adopted it. But it now appears that Microsoft has abandoned Silverlight in favor of HTML5.  In this business, the longevity of technology is far more important than sparkle and glamour.

I know an industrial software specialist who worked for a competitor. He told me whenever Microsoft released a new update his phone would ring off the hook. He dreaded it so much he would stop answering his phone for the rest of the day.

We've been using Java since 2003. The Java Runtime Engine (JRE) creates an insulating layer between Java applications and the underlying OS. This insulates Java applications from disruption when the underlying OS changes, i.e. patches, security updates, upgrades, etc. What Java gives up in glamour it gains in stability and longevity.   Java changes for all the right reasons and none of the wrong ones (greed).  We chose to build on Java with this in mind.  But I've had to wonder about it because for many years no one else was following suit.

Then a couple of years ago I discovered a motion control system that was configured and programmed via a Java WebStart client and I felt vindicated. Not only does this provide longevity but it guarantees you'll always have access to the correct version of the designer tool (what a novel idea!).

But that's not all. Last week I heard a rumor that a major automation vendor is migrating all their software to Java. Since they haven't formally announced it I won't spill the beans and steal their thunder. But you'll be hearing about this soon enough. It's satisfying to know now that we set the trend and that others are finally catching on.

Java delivers on the software end what matters most – longevity and stability.

What we Believe

People who know us know we are passionate about Ignition. This derives from the fact that we come from system integrator roots and originally built it for ourselves based on our trials and tribulations while trying to give our customers what they wanted at a price they could afford. Originally, I didn't want to be in the software business but was forced into it because no matter where I looked the model was the same and unworkable for most of my needs. These beliefs form our DNA and are the reason we exist:

We believe existing licensing models are outdated, unfair and punitive.

We believe most of the technology in use today is clumsy and outdated.
We believe in leveraging modern web and database technologies.
We believe runtime clients should be free.  
We believe that tag limits should be abolished.
We believe that development tools should be free.
We believe in licensing by the server and that it should include everything.
We believe in open connectivity and that closed, proprietary systems are dumb.
We believe it shouldn't matter what operating system you run on.
We believe you should be able to connect to any brand or number of databases.
We believe you should be able to make data-rich applications quick and easy.
We believe in central management and single click deployment.
We believe that software should install in minutes.
We believe in free and fully functional trial downloads.
We believe you shouldn’t have identify yourself to try software.
We believe prices should be published openly and on the web.
We believe that ridiculously high support fees are ridiculous.
We believe email and forum support should be free.
We believe it is paramount to always deliver more than is expected.

Finally, we believe the foregoing principles improve business results by making actionable information (and control) available to those who need it without imposing unreasonable barriers.

VOIP Systems

VOIP relates to telephony and stands for "Voice Over IP".  Many companies now use VOIP for their telephone systems.  While the cost and complexity of VOIP systems has been a barrier to entry in the past, now the open-source Asterisk software makes implementing and managing VOIP phone systems of any size affordable.

At Inductive Automation we run Asterisk on a modest Dell server machine and use affordable Polycom VOIP handsets.  There was a bit of a learning curve in the beginning, but we got over it and now it's a piece of cake for us to manage all of our calling features from a web page. And unlike other systems we had in the past we can keep adding extensions without limit.

There are now several inexpensive "all-in-one" VOIP systems on the market.  These have from 1 to 8 FXO ports (standard outside line) to connect to telco and don't require a PC at all.  It's just an appliance running the Asterisk software.  We've been experimenting with a couple of these.  One of these is made in Australia by Rowetel.  The one FXO line version is pictured above.  I believe it can support a good number of extensions.  A box like this would be perfect for home use.  The four or eight line version might perfect for a small business.  And nothing could be more affordable - the box above only costs $175 USD.

If you're wondering why we're experimenting with these cool little boxes, stay tuned.  You'll find out what it's all about in the first quarter of 2013.

NoSQL with Ignition? Is that possible?

One of our guys, Kevin McClusky,  came up with a way to integrate the NoSQL database MongoDB with Ignition.  Please realize that MongoDB does not respond to SQL queries, rather, it has it's own unique set of commands. But using these commands and Kevin's "how-to" in his blog post here you will be able to use MongoDB in Ignition.  

You can also read more about NoSQL databases from my earlier post here.

Big Software Company Mentality

There are big software companies with a small company mentality, and that's a good thing.  And then there are small software companies with a big company mentality, and that's a bad thing.  And then there are big software companies with a big company mentality and that is a very bad thing.  

How do I define the big company mentality?  Arrogant.  Ignorant.  Happy to go on being that way.  

Have you ever visited a site and come away wondering "what the heck do they make?"  It uses nothing but stock photography.  It communicates in vast generalities, promises the sun, but answers nothing.  You're wondering "but what does it do," "what does it look like," "how much does it cost," and  "where can I download it so I can try it?"  Instead you're greeted with a form to fill out.  I don't think so... next site.

Contrast that with the small company mentality (whether the company is large or small) where the site says what it is, shows what it looks like, tells how much it costs and let's you download a free trial today without even identifying yourself.  Nothing to hide.  If you like it, give us a call.  Or just buy it on our site.  

How does the big company mentality survive?  They survive by having a big name (earned from a former time when they had a small company mentality), by customer lock-in (since the cost of labor to change is higher than the cost of the software itself) and by inertia (which should never be underestimated).  

SQL vs. NoSQL in Automation

Most people know what SQL is. Commercial implementations of the SQL language have been around since about 1983. Today SQL database servers are available from Oracle, Microsoft, IBM and various open-source organizations.  

As an analogy, I like to think of SQL databases as multi-user spreadsheet servers which use SQL commands to manipulate the spreadsheets. But rather than being spreadsheets these become tables in a SQL database.

SQL commands are known as queries.  In response to a query, the database returns a result set, which is just a list of rows containing the answers. The simplest query would return all the rows from a table, but more often, the rows are filtered in certain ways to return just the answer wanted.  Data from multiple tables are often combined into one result by using a "join" query.

This gives us the relational aspect of SQL databases in that different data from different tables can be related to each other.  For example, "Return the names of all level 3 operators who work in Riverside on Line 5 and have an average line efficiency of greater than 80% for the past 12 months."  

NoSQL refers to an emerging class of databases which are loosely known as "Big Data" type databases.  Examples are CouchDB and MongoDB. 

What's the Difference?
I downloaded and installed both just to experiment with.  The first thing I discovered is that these aren't just "plug and play" or "fill in the blanks" configuration like most SQL databases are.  Each has a different API to program against and both require the use of C++, Java, C# or various other programming languages to make them do anything at all.  In other words, each is intended to be integrated into other products, not by standardized connectors such as ODBC or JDBC, but by hard core programming.

Missing are the usual SQL database front-end tools by which you can view the contents of tables, run test queries, etc.  Rather than using tables as in SQL, NoSQL databases use the concept of "documents."  Documents contain name:value pairs where the value can contain anything at all.  API methods are available to insert and manipulate documents and name:value pairs.  There is no concept of an SQL database "join."  

SQL database administrators are continually challenged by the questions, "How do I scale out the size of my database?", "How can I do this without service interruptions?" and  "How can I reliably back up my database without interruptions?"

NoSQL databases address these problems because they can be scaled horizontally over dozens of machines (or more) without interrupting service.  Multiple copies of databases can be scaled across numerous machines to provide redundancy.  The amazing thing about this is how easily it's done.  What I saw is that  nothing more than simple configuration is required.  Doing the same with SQL databases is beyond challenging.

NoSQL databases arose out of the challenges faced by Google, Amazon and Facebook as their empires grew.  They had significantly different challenges in dealing with huge quantities of data that the traditional SQL database solutions could not cope with. 

Solutions to Two Different Problems

SQL and NoSQL are two different paradigms, each of which address different problems.  Each has their pros and cons.  Like everything in our industry, every tool has a purpose and using the wrong tool for the wrong job wreaks havoc.

So which suits the MES/controls industry best?  It's important to remember that in our industry maintainability is everything.  So are the standards that make inter-connectivity possible.  You will have to connect with existing databases to make viable MES systems.  Outside of the online services such as Twitter, Facebook, and Google you won't find NoSQL databases in use.  So why worry about them?  Are you going to write a custom programs that integrate NoSQL for customer applications?  I hope not because you'll be the only person in the world who can ever support them. 

Here's a big exception.  Are you going to develop a new product to sell that integrates NoSQL?  Perhaps a data historian?  In that case, if the performance proves out, you'd be on firm ground.  But you'll still have to develop an industry standard interface for it such as OPC-HA before anyone would buy.  

Web Services and SCADA

Web services can be another method for connectivity to SCADA and MES systems. They can retrieve tomorrow's weather, the price of stocks or commodities, the time of sunrise and sunset, and a slew of other publicly-available resources. They can also interact with many different ERP and middleware systems.

We have been looking for the best way to implement web services in Ignition for a long time, but the problem has been complicated by three factors:

1. There are many web service standards; in fact, too many.
2. Data formats are wildly variable and can include many nested structures.
3. Responses can dynamically return a varied number of data elements every time.

As regards Ignition, the question has always been how to deal with these factors in an elegant way. How should we map nested and dynamically-changing data into Ignition's resources such as SQLTags, HistoricalSQLTags or other database resources? The problem gets hairy pretty fast.

We recently solved this problem by including the Python SUDS web service client library in version 7.4.2 of Ignition (currently available in beta). In just two lines of Python code you can be up and talking to practically any SOAP server that serves WSDL files. Okay, maybe that's a bit too much information – let's clarify a few things about web services. 

Web Services Demystified
Web services are nothing more than web pages for machines. There are web servers (like the one serving this blog) and web clients (analogous with your web browser) but in the place of you (the one who is controlling your web browser) there is a program which is controlling the web client.

The content of web pages is HTML (which is text) whereas in web services this is replaced with XML (eXtensible Markup Language) which is also text. HTML is intended primarily to manage how content is displayed in your web browser, whereas XML is geared for labeling and structuring the data to be exchanged.

SOAP (Simple Object Access Protocol) sounds scary but is nothing more than some text and XML which essentially makes a contract between the web client and web server concerning how they're going to talk to each other.

WSDL (Web Services Description Language) is nothing more than an initial web page (again in XML) that the server sends (when requested) which answers the questions "How should I talk to you?" and "What should I expect back in response?"

The SUDS Library
The SUDS library can query the server for a WSDL file and parse it to tell you in plan English how to talk to it in order to execute its methods (the name SUDS is clearly a play on the acronym SOAP). Once you know what methods are available you can use SUDS to invoke those methods which can (generally) be used to retrieve and send information to the server. For example, you could retrieve a work order from an ERP system, mark the work order with current production status, and then send it back to the ERP system.

The really good thing about the SUDS library is that it works. Other libraries we tried were complicated or were picky when they tried to parse information from the server (so they "blew-up", so to speak).

The thing to realize is that XML can be (and has been) structured into many arbitrary forms. Therefore, many different standards have been created to try and reign in the chaos I.e. WSI-BP (Web Services Interoperability – Basic Profile). Another variable is that even when standards are followed, there sometimes are unintentional deviations. I think both of these reasons are why we saw so many web service client libraries fall short – except for SUDS. SUDS appears to be highly forgiving.

Looking at the example at the top right of this post you can see SUDS in action. Using Ignition's "Interactive Script Tester" we first import the SUDS client. Next, we instantiate a client against a URL and request the "calculator" WSDL file. Then we print the client instance and it tells us that it is a calculator web service and says it has four methods add, divide, multiply, and subtract each of which take two arguments which should be of type float. So now we use this information for our next print command "print client.service.divide(33.33, 11.11)" and the output results are "3.0000002".

There you have it. Four lines of code. The beauty of the library is that it's Python which solves the above issues two and three. Obviously, data on the server end can take any shape, but with the use of Ignition's system scripting functions you can now map the data into any shape and into any resource with only a few lines of Python code. Easy as pie.

It's an extensive library that can do a lot of things but you really don't need to know much more than I've shown you to do magic. Documentation and more examples for the SUDS library are here and the PyDocs are here.

OPC-UA Renders Traditional OPC Tunnelers Obsolete

This post could have been called "Isn't DCOM Dead Yet?" Distributed Component Object Model (DCOM) has been deprecated for years now but it still rears its ugly head, particularly when dealing with OPC servers on remote machines.

This led to the rise of OPC tunnelers as a solution, whereby the travails of dealing with DCOM and its associated security vulnerabilities were addressed. But now, two Ignition gateways can do the the same thing, but better, by leveraging OPC-UA. The cost is next to nothing.

The Ignition platform is, for all intents and purposes, an OPC-UA client that includes a free OPC-UA server module. The module comes with many of the more common drivers, including A-B drivers.

For moment disregard the fact that we could use Ignition's free A-B driver and assume instead we want to talk to an RSLinx OPC server, as the diagram shows. RSLinx uses the older OPC-DA technology relying on Windows COM technology. Since Ignition is written in Java and can run on any OS, the Ignition OPC COM Module is required – which costs $350 but is the only cost to this OPC-UA "tunneler" solution.

In the past, this solution wouldn't work because one piece was missing, but now it can be downloaded here and it is free. This is the "tunneler module" which would be installed in the remote Ignition gateway and will allow you to browse and access your remote PLC address space locally. Setting up and configuring the two Ignition gateways takes just minutes (less than ten) and is a piece of cake.

Of course, with OPC-UA coming of age, most of this is just for picking up those already-configured legacy OPC servers or those supporting oddball protocols. In the example above you would most likely use the free Ignition drivers or for unsupported protocols use the latest KEPServerEX which now supports OPC-UA (installed at the remote location).

I thought you might like the data on this little problem-solver.

Object-Oriented SCADA in Ignition v7.4

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

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

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

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

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

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

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

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

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

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

Dukes Choice Award 2011 - we won!

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

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

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

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

Ignition 7.3 Beta now available

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

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

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

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

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

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

Running Ignition on Panelview Plus 6 update

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

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

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

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

Inductive Automation - Where Did the Name Come From?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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