Where is the 'c' in MES?

Back in 2002, I saw the acronym cMES a lot, but now it's just called MES. So I got to wondering, what happened to the 'c'? In case you don't remember, the 'c' stands for collaborative. When I searched for the term recently I came up with only a few references, which is surprising. But then I got to thinking, MES is a more appropriate term anyway because most MES software is anything but collaborative.

MES, of course, would include applications like scheduling, downtime tracking, OEE, quality assurance, maintenance management and numerous other applications which facilitate better coordination and management of the plant floor. But to do this effectively each separate function needs to collaborate with the other, as well as with each of the stakeholders such as maintenance people, the production scheduler, quality assurance, plant floor operators, the plant manager and so forth. MES should be all about collaboration.

This would imply having a shared data scheme between applications, having a single source user authentication, being able to switch quickly between applications, and having the ability to easily interconnect with various data sources and databases as well as ERP systems. It also implies having the ability to give any stakeholder access to the system from anywhere (without technical or licensing restrictions).

MES systems that fail on any of these points will be short lived and be of limited usefulness. Those that embody these points can be credited with putting the 'c' back into MES and the winners will be the manufacturers that use them.

Stuxnet and Common Sense

The Stuxnet PLC/SCADA virus saga keeps getting deeper. If you haven't been following the story, you can read this Wikipedia article about it. The Wikipedia article skirts around what the ultimate objective of the Stuxnet virus is but this AOL News article minces no words.

It's all very interesting, but essentially the virus exploits various software vulnerabilities and thereby modifies the PLC program that controls high frequency VFDs found only in uranium enrichment centrifuges. Its purpose, according to the AOL article, seems to be to over-speed the centrifuges momentarily so as to destruct the rotational parts.

I have just one question, why wasn't the PLC program password or keyswitch protected against program changes? In a sensitive application like this, why not? Control system security is mostly a procedural and implementation issue. Yes, network traffic should be encrypted. Yes, user authentication should be centrally managed along with other IT applications. But no matter what, any system can be compromised when common sense goes out the window.

Common sense is important and there is no one-size-fits-all solution. I see it just like a personnel safety system implementation. A risk assessment for the situation is done and vulnerabilities are evaluated, then an appropriate solution applied. And it is a continuous improvement process that adapts the system to new conditions as discovered.

In a safety system risk assessment the first step would be to determine, in a worst case scenario, what the loss would be. Death? Personal injury? Machine damage? Product damage? And in the latter two, how much cost? Similarly, you would first do a risk assessment for SCADA or PLC security. In fact, the parallels between a safety risk assessment and security risk assessment are uncanny.

The recent TSA enhanced pat-down for pilots is an example of the one-size-fits-all mentality when it comes to security. I sure hope it doesn't come to that for SCADA systems. The right answer is to approach SCADA security the same way safety has been approached in our industry for many years.

Today, even a kid could install Ignition

We have been, since the beginning, fanatical about delivering greater and greater user friendliness. I wanted, and demanded, an installation that took minutes and which worked the first time, every time, when downloaded and installed.

FactorySQL and FactoryPMI were revolutionary products. But they were separate products that had to work with third party products before they could do anything. More than one person got lost in the installation process. But Ignition is another story. The installation process is so simple it's gotten ridiculous.

I thought, "I'll bet even a kid could install Ignition." So I decided to have my ten-year-old god-daughter give it a try. I sat her down at my desk, pointed her to our website and asked her to download Ignition and install it. I had to show her where to find it on our website, but with a little direction she downloaded Ignition and installed it. The time? Four and a half minutes! When I told her she just installed enough software to run a huge manufacturing plant, her eyes got real big and she started grinning from ear to ear.

If you think I'm exaggerating, you should try it for yourself by downloading it here. If you think it sounds too good to be true, because you've installed other SCADA/MES software that took all day or several days, then give Ignition a try and convince yourself. If you think the learning curve would be too much, just remember my god-daughter – if even a ten year old could do it ...

So what can you do with software that installs in under five minutes? It's got to be pretty limited, right? Wrong. If you really want to know what it can do, read my earlier blog entitled "The Three Minute Misconception". Not only can you start developing right away, but you can have a simple application up and running in half an hour (not to mention launching a dozen clients). But the best part is, you don't even have to contact us to try it out.

Just so you know, we don't do those funky 30-day trials. Our trial is unlimited just like everything else about Ignition. Splurge on it!

Outsourcing Development... Not!

I was caught off-guard yesterday when a couple of our sales staff told me that some people thought we were outsourcing (overseas development) because Ignition is relatively inexpensive. The short story is we don't outsource.

The longer story is this... In the beginning I researched outsourcing and it was a 50/ 50 proposition, but I decided to hire locally. As you can see, it turned out to be a smart move. Two or three years ago we reconsidered outsourcing some software development and it looked pretty good on paper, but when we got down to the brass tacks and started interviewing we realized it wasn't going to work. You have to look at a broader picture when making a decision like that.

Here's the rest of the picture. Our programming requirements are intense and our feedback loop is fast. Our developers are all field savvy, even though they all come from the IT arena. Our interoffice communication is fast, accurate and bright ideas germinate spontaneously every single day. This is a priceless chemistry.

Also, we have a saying around here, "minimize the internal fiction." Our software architecture embodies this by deliberate design. So do our business processes. As soon as we start getting in the way of ourselves we clean it up right away. The bottom line is, I don't think outsourcing plays well with this idea, or our amazing chemistry.

Linux SCADA

We're seeing a pretty good up-tick in Linux installations this year. It's also interesting to note that if you search for "Linux SCADA" or "Web based Linux SCADA" you'll get a load of stuff. There are quite a few open-source projects and one of them (not web based) is pretty comprehensive.

So when my old Windows desktop bit the dust I decided to get adventurous. I download and installed Ubuntu Linux 10.10 on the bum machine and then installed Ignition on top of that. I'm no Linux guy, but the installation was no big deal. By the way, if you haven't used Ubuntu before you should grab an old machine and try – it's pretty darn nice.

To install ignition I just downloaded the Linux zip file from the Inductive Automation website and followed the instructions in the README file. Obviously, it took longer than the three minutes it normally takes on Windows, but I doubt the install took over ten or fifteen minutes total. Once I got it installed I connected over the network to a PLC, created a simple screen and launched several clients across our network. That was fun and satisfying because I resolved in the beginning not to not ask for any help if I ran into problems.

The Future For Linux SCADA

Developing professional quality SCADA software on any platform is challenging because it involves a mixture of disciplines that are hard to gather in one place. It requires the grizzled old control system expert as well as several highly skilled software developers with diverse skills in UI development, database development, hardcore coding, driver development, cryptography (if you want a modern SCADA anyway), and a lot more. Now throw in the variable of supporting different operating systems and it can get so burdensome that multi-platform support is plainly not cost effective.

Since Windows is the dominant OS, developing on Windows is the only viable choice for most companies. It doesn't make economic sense to develop SCADA on several emerging platforms while gambling they might get popular. Viewing the field of established SCADA software providers bears this out. I think every major player supports Windows only, except Inductive Automation, which is written in Java so it runs on nearly any OS.

I can tell you this was a fortunate choice on our part because if we chose anything else, that would be it. We wouldn't be supporting any other platforms for economic reasons, just like the rest.

What about the open-source projects? Any potential there? I wouldn't hold my breath for the reasons given above in the fourth paragraph. Pulling together a team like that for free seems highly unlikely to me.

OPC Xi: Is it Dead Yet?

I just have just one word for OPC-Xi ... Why? Okay, I get it, it has taken forever to get the OPC-UA show on the road. And yes, Xi is a quick and dirty solution to get around classic OPC which is based on DCOM. But it's a short-term solution in a field that demands longer-term solutions.

Forget the fact that Xi, like classic OPC, is vendor specific (depends on Microsoft technology). The bigger point is how many standards do we need? It's already to the point of madness. Isn't that the point of OPC standardization?

OPC-UA is now an accomplished fact. We recently attended the OPC-Interop conference in Nuremberg, Germany and were pleased with the heavy attendance. In fact, we successfully tested Ignition OPC-UA against nine other UA servers and ten other UA clients. Commercial products are now available from a large and ever growing number of vendors.

The more telling point is that OPC-Xi has no validation testing available (to my knowledge). And there are no interop conferences to ensure compatibility (also to my knowledge - correct me if I'm wrong). So is there really interoperability? I don't know. Take your chances.

NEWS FLASH – OPC-Xi is DEAD! Actually, it has been renamed to OPC .NET 3.0 (WCF Edition). Man, that is a mouthful to pronounce. As I was writing this one of our developers pointed out this recent change to me. By the way, WCF is the new Microsoft replacement for DCOM.

Whither Silverlight?

A number of HMI / SCADA companies have now built their products upon Silverlight, and while this creates some awesome graphics, I have to standby what I've always said about building (at least in our industry) on the tumultuous Microsoft base. Last week Microsoft announced a shift of emphasis from Silverlight to HTML5. I shouldn't have been shocked because I've been predicting this, but I WAS shocked because Silverlight just hasn't been around that long.

I think it's fine that Microsoft shifts with the times and I think it is a particularly smart move for them to shift toward HTML5, but in the HMI, SCADA and MES industry such rapid shifts spell disaster. This is because in our industry things have to last a while. I think building HMI, SCADA and MES software on top technologies that change every two or three years is like building skyscrapers on top of the San Andreas fault line.