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?