Java Tops the Charts of Programming Language Popularity

There are two indexes I'm aware of which measure the popularity of programming languages.  The most referenced one is the TIOBE index.  I've watched it for a number of years with Java being in the #1 position usually.  The latest rating for March 2016 shows Java has advanced far out into the #1 position by a long shot. Python comes in at position #5.

The TIOBE index is apparently calculated by an algorithm applied to data found on the web by a web crawler.

Another index is the PYPL index (PopularitY of  Programming Language) which is calculated based on Google Trends and how often language tutorials are searched by language.  According to this index Java is #1 by a massive margin and Python is #2.

There are other corroborating sources.  Inc. Magazine ranks Java as #1 with Python coming in #2.  C comes in at #3.  Another interesting approach is based on job listings for programming jobs such as is reported by CodingDojo and which lists SQL as #1 (though not really a development language as you would normally think of one), Java as #2, and Python as #5.

CodeEval claims to be more of a language predictor based on the languages that over 2000 tech industry employers are testing for.  According to this index, Python has held the #1 position for four years in a row with Java coming in at  #2 and with a huge margin over C++ which is in position #3.

It's interesting to note that Java is the clear leader no matter which approach is used.  Python's rating is more varied, but it is always at or near the top of the list.

For me, it's reassuring to know the language choices we made ten years ago are still top of the list in popularity.

Open Source Publish-Clients for IIoT

Cirrus Link will release open-source MQTT publish-client libraries through the Eclipse Foundation in the second quarter of 2016. Libraries will be available in C, C#, Java, Python and JavaScript. Java will be available as a standalone library, as well as a module for Kura. Kura is a Java/OSGi-based framework for IoT gateways.

These libraries leverage the open and popular Google Protobuffers standard, as well as the Kura definition for data which just happens to align nicely with common PLC datatypes. They will be released concurrently with the open Sparkplug standard which tracks "state" though the use of birth and death certificates.

What is little understood by the larger IoT audience is that in the IIoT setting, "state" is required. SCADA is useless without state. The Sparkplug standard wraps up the MQTT definition, Protobuffers for data representation, Kura specifications for datatype definition, birth and death certificates to provide "state" and other simple mechanisms to make MQTT useful in SCADA applications.

Any publish-client compatible with the Sparkplug specification will also be a proper Ignition citizen through the use of the MQTT Distributor module. This makes me want to build some sort of edge of network device using Raspberry Pi or BeagleBone. I've got a few ideas. Now I just need some time.

PLC Virtual Shared Memory using SQLBridge

How can you accomplish virtual shared memory between PLCs of different models or even different brands? For example, how can you share memory between Rockwell and

Siemens processors? And what problems would this solve?

The first thing I want to point out is that the solution is not complicated or expensive and very few people even know about it. Yet it's the simplest solution in the world and can be setup to work in just a few minutes. The solution, by use of SQL Bridge, simply involves mapping two transaction groups in the bidirectional update mode to the same table. That's all. Each transaction group maps to a single PLC. And did you know you can create additional transaction groups for many more PLCs configured in the same way and have all of them share the same memory? There's no limit in the number of PLCs that can partake.

All this can be configured from only the Ignition Gateway and Designer. You can even launch several Gateway clients and using the Quick Client monitor and manipulate address values in each of the PLCs simultaneously. Everything for configuration and testing in one program and at arms length. How simple is that?

Think of the problems solved. Some gnarliest problems I ever encountered as an integrator had to the with inter-processor communications and handshaking, particularly between different brands or models of PLCs. It usually got complicated. Just documenting all the communication paths and getting my head around them, especially when there were many different brands/ models of processors involved, was onerous. Usually hardware protocol converters were required and talk about a pain, ouch! Handshaking was unreliable and it seemed like communication would always stop at 2am in the morning...always. And none of this was really "shared memory" anyway. Not really.

What do I mean by shared memory? Simple... you change a value of an address in PLC "A" to 99 and a corresponding address in PLC "B" gets the same value of 99. Now if you change the same address in PLC "B" to 33, then the original address in PLC "A" now sees 33. This is the magic of the bidirectional mode. I call it bidirectional mirroring. It's the most useful thing ever for an integrator. A thousand uses. No one else would ever understand the value of this.

But it gets better than that. Transaction Groups are configured just by dragging and dropping browsed tags into them. There are just a few fields to fill out to make it all work and half of those are just dropdown or checkbox selections.

Experienced integrators know that shutting down any system during production is no good. That's why online programming was invented for PLCs. Well, it's the same with SQL Bridge. Need to make an online change? No problem - no need to shut anything down.

You only need the SQL Bridge module and the zero-cost platform all at a price which is ridiculously low. You might want some OPC drivers too but they are equally low cost. I think the pricing committee lost their minds!

Virtual Shared Memory is just one thing out of 1000 things you can do with SQL Bridge. SQL Bridge was my secret weapon when I was an integrator. Now it's yours. Enjoy!

IIoT that Just Works

This is the wildest technology wave I've ever seen. No one wants to be left behind. But as I look over the IIoT landscape it looks mostly like a solution in

search of a problem. The Cirrus Link solution for Ignition is just the opposite.

The Cirrus Link MQTTEngine and MQTTDistributor modules for Ignition provide an out of the box, end-to-end solution which can be setup and running in a matter of minutes. What does it accomplish? It can publish (with MQTTEngine) industrial edge-of-network data to an on-premise or off-premise cloud (MQTTDistributor) and then subscribe to that data (MQTTEngine again) from any number of Ignition servers (for analysis and distribution to end-users). Other enterprise software can subscribe to this cloud data as well with access being determined by role and authentication level.

What's so special about this? Imagine tens of thousands of datapoints (from thousands of edge-of-network devices) all being delivered to any number of Ignition servers with second or sub-second response times even from low bandwidth and unreliable links. Imagine that the tags representing these tens of thousands of datapoints were created automatically in just a few seconds (not a few months) just by subscribing to the cloud and imagine that each tag can be configured with advanced alarms, with history, event scripts, etc. Now imagine that every datapoint is a bidirectional and stateful connection. That's the magical 40,000 foot view.

A third Ignition module by Cirrus Link (MQTTInjector) facilitates the simulation and modeling of an entire IIoT network with thousands of edge-of-network nodes in a snap. So you can setup and test an entire end-to-end system within the Ignition ecosystem and all within arms length on a sunny afternoon.

But it gets even better than that. MQTT is an open standard (see MQTT.org) and compatible edge-of-network hardware devices which can talk practically any industrial protocol on the field side (Director Series) are available from Elecsys Corp.

Arlen Nipper of Cirrus Link is co-inventor of MQTT (in collaboration with IBM). Arlen has a long history with major Oil and Gas companies in data acquisition and control. The major problem has been how to communicate reliably to remote assets over low-bandwidth and unreliable links. The technology behind the Cirrus Link MQTT for Ignition solution has been in constant field use for many years. It is the successful response to problems well known in industry.

SQL Bridge is Magical

SQL Bridge is my favorite part of Ignition.  It was our first product back when I was the only "salesperson."  Back then it was a standalone product called FactorySQL and was the product that bootstrapped us forward.

FactorySQL resulted from a call by many of our customers (back when I was an integrator) to track, analyze and make available ever more complex data from ever more sources and to provide accessibility to the data from web pages.  Prior to that we developed a lot of one-off C, Delphi and VB applications, but these were albatrosses around the neck.  What I really wanted was a reasonably priced, simple, commercial-off-the-shelf solution and I was pretty confident I'd find it.  Yet four months later I reversed that idea, was disillusioned and was pretty sure I wouldn't find it.  Therefore we had no choice but to develop something in-house.

I drew up the original concept on paper and Colby developed it.  We gained indispensable field experience deploying it to a wide variety of industries and applications which allowed us refine, add versatility, and battle harden it.  I was giddy at the realization my integration business could now have a total monopoly.  No where else could you get FactorySQL's functionality at any price.  It was intoxicating, but that wore off when I realized you either get in the software business with both feet, or you get out (I could write a book on that subject alone).  So I chose the software business.  

Back to being the first "salesman." It was a real kick demonstrating FactorySQL to integrators.  In the first place, like myself in the beginning, few had much familiarity with SQL.  I took great pleasure in showing them how easy, inexpensive and useful SQL databases can be.  While demonstrating FactorySQL the "light bulb" would inevitably go off and uniformly I'd get the "what's the catch?" question.  I did this by demonstrating the 1-2-3 drag-drop-log ease of use.  Then I'd show triggers, bi-directional mirroring, recipes, mapping addresses between different brands of PLCs, wide column logging, automatic sequencing, all types of stuff.  I could do it in minutes.  I don't sell anymore but it was fun while I did. 

In 2010 FactorySQL was renamed SQL Bridge which is part of Ignition.  That offered a host of new benefits such as ability to run on any platform like OSX, Linux or any version of Windows, support for OPC-UA, built-in drivers for most popular protocols, online editing, and more.  But it now shares the limelight with a stable of other cool modules and that's mostly why I wrote this piece.  SQL Bridge is the integrator's swiss army knife (it was my ace-in-the-hole) but it could be forgotten as the limelight now favors the rising stars (newer modules).  And that would be a pity.

Heck, we're the first culprits.  Just go to our website and look up SQL Bridge.  If you can find it at all you'll likely come away thinking it's only a logger or historian.  So I'm telling you now it's more. It's the integrator's swiss army knife. It's the integrator's secret advantage (experience shows not every integrator "gets it").

You can get your own reality on this by downloading Ignition from our site and installing it (five minutes max).  First set up a database (MySQL is free and sets up in minutes).  Then go into the "Configuration" page and create a database connection.  Open the designer and go straight to "Transaction Groups" in the project tree (SQL Bridge manifests itself in the designer as Transaction Groups in the project tree and as a the History tab of the Tag editor).  Using the included help system you'll figure it out quick and if not look it up in our free Ignition University.

What is Inductive Automation's Market share?

Recently we were asked what Inductive Automation's market share is.  Good question.  Clearly what was being asked was, "what percent of the SCADA market does Ignition have?"  But asking that question misses the bigger picture.  The diverse applications to which Ignition is deployed defy any simple categorization as "SCADA".  Nonetheless, I will address the SCADA market share question later in this post.  But as knowledgeable users already know, there is no established category that adequately defines Ignition.

A good analogy of this is the history of the cell phone.  In the beginning the cellphone was just a telephone.  Everyone understood you could make calls with it and nearly everyone had one.  Then the smartphone came which handled emails, web browsing, scheduling, photography, video, games and a thousand other things.  It became a viable second office.  It's no longer a cell phone,  it's a handheld computer.  It's in a whole new category that happens to make phone calls also.

It's exactly the same with Ignition.  Ignition is clearly in a category of its own, and yes, it can do SCADA too.  But it is an IT friendly, all-in-one, rapid development and deployment platform that can create custom database applications, or anything else at an unbelievably low price.  So what is this category called?  I'm looking for suggestions.

Old SCADA is like using a horse buggy.  Ignition is like driving a Mercedes AMG ML63.

That gets us back to "what is our market share?"  Simple.  100% of our category.  Because no one, I really do mean no one, even comes close to our functionality.  Some companies are trying to copy us, but they clearly don't understand much about Ignition.  A bunch of programmers and marketers in an ivory tower will never understand Ignition, nor do they understand actual needs of the market.

Now as I promised, let's look narrowly at the traditional SCADA market.  What's our market share? There are different market share metrics used like new sales and install base, but how would you ever measure either now that there's Ignition?  Ignition antiquates these metrics.  Consider this... install one Ignition server, deploy 25 runtime clients, use 100k tags, create 5 simultaneous projects with 250 screens each and you spend about 13K.  Now rip it all out and replace it with your traditional SCADA software and what will you spend?  Maybe $65K? More?

Let's extend the example a bit.  Let's say you want to add 25 more runtime clients and go up to unlimited tags.  What do you pay?  Another $65K?  More?  With Ignition it costs you nothing more.

So tell me now, what is the size of the SCADA market really?  And since Ignition is sold at a fixed price by the server with unlimited runtime clients, unlimited tags, unlimited concurrent development seats, unlimited database connections, and unlimited historian points, how do you measure the cost to fulfill a given system's requirements?  I'm sorry to say folks.. we just broke all traditional market share metrics.

From our perspective though, it's not all about SCADA.  We do SCADA also.  But how about fulfilling all the needs of  Production, QA, Scheduling, Maintenance or any other department and making it all work seamlessly at the speed of light as a paperless system.  The market for that is huge.  How huge?  I doubt anyone knows because the category has never been adequately defined.  But whatever it is, we've got 100% of it because no one else is even trying.

The PLC Industry is about to be Disrupted by a Source you would Never Expect

Bedrock Automation.  Never heard of it?  That’s probably because they've come swinging out of

Silicon Valley where anything is possible.  In two short years they've built a cyber secure PLC with OPC-UA built-in.  The operating temperature rating  is -40℃ to +80℃.  

All power and communications through the backplane is completely pinless by use of  what they call Black FabricTM  technology.  Not a single pin!

Their goal is to have as few catalog numbers as possible (they stated to me no more than a dozen part numbers).  For example, there is a single module part number for a universal I/O module.  By software configuration alone you can choose any type of industrial input or output, discrete or analog, AC or DC.

I held this thing in my hand and I've never seen or felt anything like it.  It’s rugged!  It’s well built!  I was even told they tried to blow one up by putting it on top of a million volt Tesla coil but it kept working.  

I know you’re thinking by now they’re just a flash in the pan.  But I don’t think so.  They are a subsidiary of Maxim Semiconductor.  Maxim has a 7.57B market cap and 8,800 employees.  A brief description of the company follows:

“Maxim Integrated Products, Inc. designs, develops, manufactures, and markets various linear and mixed-signal integrated circuits worldwide. The company also provides a range of high-frequency process technologies and capabilities for use in custom designs. It primarily serves automotive, communications and data center, computing, consumer, and industrial markets. The company markets its products through a direct-sales and applications organization, as well as through its own and other unaffiliated distribution channels. Maxim Integrated Products, Inc. was founded in 1983 and is headquartered in San Jose, California.”

The real question is, will they be able to push this amazing product to the finish line?  If they can actually deliver the product at the price point they told me, which is about the price of a mid-range PLC, then the price won’t be an obstacle.  In terms of hardware, I think it’s already a slam-dunk. Probably what it boils down to now is software.  And for that, I think they have some very cool stuff up their sleeve.

Their choice to build-in OPC-UA is a masterstroke.  While incumbents wearily cling to “has been” protocols, Bedrock is pulling out into first place with its UA adoption.  Welcome to the 21st Century!

Disruption happens when you least expect it.  Frankly, I was shocked to see what Bedrock has accomplished in so little time.  But Silicon Valley moves at a different pace and this company has significant resources.  Commercial release is slated for mid-2015.  

What This Group Is, 500 Words or Less

I'm always trying to explain what we do more and more concisely and had to do so for a disruption award for SARTA (Sacramento Area Regional Technology ) in 500 words or less. Well, this is what I came up with...

Ignition by Inductive Automation® has completely disrupted the SCADA (Supervisory Control and Data Acquisition) market, upending virtually all such old-school players which are mostly international conglomerates.

Whereas traditional SCADA solutions were developed in the mid-1990s, they have advanced little since then and are ill-suited to the demands of today’s industry.

Inductive Automation, and its elegant Ignition, all-in-one server-based solution, address well known frustrations of the automation industry.  These frustrations include having to deal with long-obsoleted technology, software instability problems, antiquated licensing models, foolish business practices, and poor support.

By contrast, Ignition makes deploying and maintaining an unlimited number of rich visualization clients from the central server just a mouse click away.  While they are similar to webpages and rely on web standards, they are actually rich clients particularly suited to the demands of the industrial environment.  Entire installation takes just minutes as compared to hours or days per client for traditional SCADA software. 

The modern enterprise normally has dozens of highly fragmented systems and data stores which results in “islands of information.”  Seldom does the right information reach decision makers in time, if ever.  Old school SCADA only contributes to the problem.  Ignition on the other hand unifies these disparate systems, consolidating data with agility and ease.  Data collection can be from anywhere, analyzed in meaningful ways, and made accessible to decision makers at every level of the organization.  But most importantly, the development, deployment and maintenance of such Ignition systems are affordable thanks to its unique architecture. 

A key distinguishing factor of Ignition is its platform and modular architecture.  The platform could be considered an industrial operating system while its plugin modules (which can be written by anyone) provide functionality, much like iOS is a platform and its apps provide functionality.  This plays a key role in future proofing the Ignition product since newer technology modules can run right next to legacy ones.  The industrial automation industry screams for software longevity, a demand which until now has been unfulfilled.

While the incumbent players all embrace Microsoft solidly, they ignore the larger global picture as we see increasing adoption of Linux and OSX.  Ignition is built with Java (not Javascript), which is fully cross-platform, so users can run on any operating system equally well out of the box.  While old-school Microsoft diehards are hacking away for six months or more, desperately trying to make their software run on the next version of Windows, we are already running on it from day one.  And with every hack, their systems become less and less stable. 

All of our innovative firsts would take a hundred pages to describe.  These include concurrent web-launched IDEs (Integrated Development Environments), single file backup of the entire system, seamless integration between modules, and on and on.  But, the ones described here are some of the overarching ones. 

Probably the most important innovative first, which is a radical departure from the rest of the field, is Ignition’s flat pricing model by the server.  One Ignition server license can replace hundreds of individual licenses required under the other guy’s model.   The cost differential is astounding.  This means unlimited visualization clients, unlimited database connections, unlimited plant floor connections, unlimited web service connections, unlimited IDEs, and more - all for one flat cost.

Industrial software projects are no longer limited by cost considerations.  So, now affordable, effective solutions can be rolled out which increase collaboration between all parts of an enterprise.  Metcalfe’s Law is in play here.  It states that the utility of any communications system is equal to the number of users squared (utility = users²).  A single Ignition server instance can service many users.

How did I do?

ICC 2014: Talk Shop & Share Ideas

In a few weeks the Ignition Community Conference 2014 will be held in Folsom, California, and our attendance trajectory is double the number of attendees from last year.  Integrators and end users will gather, talk shop, share ideas, and learn more approaches to solving problems in the field.

I am looking forward to getting into conversations with end users and integrators from around the world, and even though our marketing team hasn't promoted it - cross-pollination still applies. A single good idea gotten at the conference could repay the cost of attendance in spades.

ICC runs September 22 through 24 with 24 Automation sessions and plenty of time to participate in productive forums while networking with other members of the Ignition community.  

Why your SCADA system should be more like your smart phone

There is a better model for how a SCADA system should be designed. A good example of this better approach is probably sitting in your pocket. It’s your smart phone. Your smart phone runs on a set of powerful, yet independent apps. Why is that a smart idea?

• You can add or delete apps without restarting your smart phone.
• Apps can be easily upgraded while the other apps continue to operate.
• If an app crashes, it doesn't take down the entire system. 
• You can select the exact apps you need to provide the exact functionality you want on your phone.
• Smart phone apps are relatively inexpensive without requiring large annual licensing fees.

Compare that to how SCADA systems have traditionally been designed:

• Adding software requires a complete restart of the entire system.
• Software upgrades not only require everything grinding to a halt, they can often break another part of the system causing a cascading need for upgrades.
• If a piece of software crashes, it freezes the entire system.
• Often you must pay for functionality you don’t use or need.
• Annual licensing fees for software can be astronomical.  

There is another advantage to having a modular approach to manufacturing software. That’s that third parties can also develop specific applications that add powerful functionality. Look on your smart phone. Many of the most popular and useful apps are not created by Apple or Google. They are created by third party developers.

That’s why Ignition was created using a modular approach. In addition to the key modules that the Inductive Automation team creates, other companies are creating some very cool modules that you can easily add.  It makes a system more versatile and powerful. I think it just makes sense.

Technology is constantly advancing. Isn't it time that SCADA moves up to the New SCADA standard?

Thousands of SCADA users on a high wire without a net.

Earlier this month, tens of thousands of HMI, SCADA and MES systems lost their safety net. The problem?

Microsoft no longer supports Window XP.

Granted that XP is pretty old, but it still runs on more than a quarter of PCs worldwide.  And there is probably a greater portion of SCADA systems still on it.

According to the Microsoft website: “After April 8, 2014, Microsoft will no longer provide security updates or technical support for Windows XP. Security updates patch vulnerabilities that may be exploited by malware and help keep users and their data safer. PCs running Windows XP after April 8, 2014, should not be considered to be protected, and it is important that you migrate to a current supported operating system – such as Windows 8.1 – so you can receive regular security updates to protect their computer from malicious attacks.”

Of course Microsoft believes that everyone should always upgrade and buy the latest version of their OS. But for most users running HMI, SCADA and MES software it's seldom a simple upgrade.

Most users would prefer two weeks of army boot camp followed by a dental visit for a root canal compared to what they now face.

I believe the problem with traditional SCADA software has to do with developers veering too far from Microsoft's mainline API, such as using newfangled features before they really gain widespread acceptance, so they get deprecated.  An example of this is Silverlight.  Silverlight is dead yet so many software vendors bet the farm on it.  The main point is this... Upgrading a SCADA system from one version of Windows to the next is usually a crap shoot.  

That’s why we decided to make Ignition cross platform from day one. That means that it runs on Linux, Unix, OSX, but most importantly, any newer version of Windows right out of the box.  So far, we've been ready day one for each new release of Windows.  And do you have to pay for an upgraded version of our software to do so?  Probably not.

So the real question is this... are you ready to get off the merry-go-round and solve the real problem once and for all?  Seriously, next time you are ready to upgrade to a new version of Windows, try Ignition - costs nothing to try  - and you'll be glad you did.  

OPC-UA goes mainstream

From PLCOpen.org presentation of February 2014

One of my most popular posts was Imagine OPC-UA Everywhere.  Since that post Triconix was reported to have integrated UA into their Trident safety PLC product.   Now two other significant events tell me OPC-UA has taken root firmly and we'll see soon OPC-UA embedded in most PLC controllers.

One event was the announcement today in Control Engineering - Europe entitled OPC-UA client function blocks for IEC 61131-3.   In that announcement was the following excerpt "...adding the OPC UA client functionality in the controller by defining a set of Function Blocks for IEC 61131-3.  This specification has just been released, making the controller an intelligent part in the IT communication."

The other announcement is even more significant in my book.   It's the release of the a new ControlLogix OPC-UA module made by OLDI.  I missed the Rockwell webinar about it yesterday and the information on OLDI's site is sparse, but it obviously sits on the CLX backplane so would seem to have access to at least a single controller's tags and maybe even more.  

The latter release will likely pressure other PLC manufacturers to do the same, and then I think the snowball really begins.

VOIP Alarm Notifications - Another Solution

When we developed the Ignition alarming module and its voice notification system, we opted to do the modern thing; we based it on VOIP.

The old hardware cards you install on a PC back-plane are so '90's, so we skipped them.  VOIP delivers unprecedented power and flexibility, is inexpensive, and exceedingly easy to setup and use.

What this means is you can connect Ignition to all types of VOIP services.  Ignition looks just like a VOIP telephone handset.  But maybe you've never dealt with VOIP before.  So here's what you should know. Skype is a big VOIP server in the sky - and you can connect to that.  If the phone sitting on your desk has an Ethernet port, it's probably VOIP.  So you would have your phone system administrator configure a new extension and provide you with the username/account/extension_number, password and server's IP address so you can configure that in Ignition.

There are other cases where you would want to connect to a POTS (Plain Old Telephone System) line.  POTS lines are highly reliable and work even when utility power is down.  And that might be the only thing you have available.  To address that we mentioned that we discovered a couple of inexpensive (~$200) VOIP servers, but several customers have mentioned delivery and support on those items are problematic (they are sourced from China).  Well, we discovered yet another option -  it works better and costs less.

Enter the Grandstream HT-503 analog phone adapter.  It's not even a VOIP server.  It just interfaces between VOIP protocol and a POTS line.  It has better voice quality and costs about $50 from Amazon. Colby ordered one from Amazon and got it in a couple of days (Grandstream is located in the US).

Colby wrote a how-to guide to configure this little box (pictured above).  He did add the caveat that you need to set the minimum time between calls  for 5 seconds or more (as shown to the right) since the POTS system requires this.

The information for setting up the HT-503 is included in this KB article  from the support section of our site.

The ways of leveraging VOIP are endless.  We aren't endorsing this Grandstream solution particularly, other than to say we tried it and it worked, the sound quality was excellent, and we were able to obtain one quickly and inexpensively.  Like the rest of of our technology choices in Ignition, the VOIP standard is open, so your possibilities are endless.

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.