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.

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.  

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?

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.