Friday, December 6, 2013

When I learned that Intuitive Design was going to be the 8:30am session

at OSIsoft's 2013 vCampus Live, I made sure to be on time. I've done a bit of reading on usability and plowed through Steve Krug's book, "Don't Make Me Think." (Why is the obvious so out of reach?)

Any corporate citizen who's had to operate enterprise software has had to deal with non-intuitive interfaces. From manufacturing execution systems (MES) to enterprise resource planning (ERP) systems, there are armies of confused employees relying on power-users to execute critical business workflows.

Why is it easier to purchase something from Amazon than it is to buy stuff using SAP? Why can I find information on Google faster than I can find trends in my data historian?

As with Steve Krug's book, I was not disappointed by Jared Spool's talk. I was quite stunned by his definition of "Intuitive design."

Mr. Spool says that there is such a thing as an acquired knowledge continuum (that he represented as an escalator).

Click on image to go to Jared Spool's site.

At the bottom of this continuum are people with no knowledge of how to use your system; at the top are people who know everything there is to know about the system (developers).

Somewhere on this continuum is what he calls, "Target Knowledge." Target knowledge is the amount of knowledge that the user needs to perform their duties. Also on this continuum is "Current Knowledge." Current knowledge is what the user knows right now.

The knowledge gap is the distance between target knowledge and current knowledge.

A design is intuitive when knowledge gap = 0.

Closing this knowledge gap is done in many ways. You can raise current knowledge with training. You can lower target knowledge with simplification. But to ultimately build an intuitive system, you at least have to know these terms and figure out at which point your system features impede usability.

The (lack of) usability with Enterprise Software is that enterprise software is feature-driven. As customers demand features that are required by their business, vendors clamor to pack their systems with features, in so doing raising the target knowledge higher and higher on the escalator.

And as MES and ERP systems evolve, they become unusable because only the few power users can master the richness of the features. Jared Spool's proposal is to understand your "killer features" and drop everything else.

Sunday, December 1, 2013

Unless you've been living under a rock, you would know that STUXNET refers virus that impacts automation control systems. It was first discovered at the Iranian facility that was enriching uranium. And since then, we learned that this virus wasn't created by hackers; the sophistication of it points to a government with vast resources. Check out this fascinating article on STUXNET.

Here are some main points:

There isn't one Stuxnet, there are a set of twins.

The first Stuxnet attack happened in 2007 and was designed to stealthily disable the uranium enriching centrifuges by overpressurization. Its impact is uncertain.

The second Stuxnet attack was less stealthy and was designed to disable the centrifuges by over-spinning the centrifuge rotors.

The second Stuxnet virus spreads and infected the laptop of system integrators that connected to the SCADA system and the intent appears to be to disable the Iranian nuclear program over the long-term.

The forensics on the Stuxnet virus points to government involvement as the Stuxnet attack uses "zero day" Windows weaknesses and stolen digital certificates that would cost hundreds of thousands of dollars to create.

Here's something amazing:

One of the first things this Stuxnet variant does is take steps to hide its tracks, using a trick straight out of Hollywood. Stuxnet records the cascade protection system's sensor values for a period of 21 seconds. Then it replays those 21 seconds in a constant loop during the execution of the attack. In the control room, all appears to be normal, both to human operators and any software-implemented alarm routines.

Stuxnet can intercept sensor measurement and send false values to operators at the HMI. Operators at the HMI are none-the-wiser. OPC Servers have no idea that these values are counterfeit. OPC Interfaces, repeating what they were sent by OPC Servers, would simply re-transmit these false values. Data Historians, archiving what they are told by OPC Interfaces, would insert these false values in the archive as told.

The long-term effects are truly pernicious because long-term process understanding is impacted. The power of data historian software is the ability to let users look in the archives and understand real phenomenon from sensor readings. And since Stuxnet decoupled sensor transmissions from reality, there will be armies of engineers scratching their heads.

I'm headed to OSIsoft's vCampus next week and going to take part in the security hack-a-thon as SCADA security comes to the fore. Most data historian run as read-only systems: data flow unidirectionally from the control system to the data historian, so for most systems, security impact ought not be that large for process data historians.

In the meantime, if you're a system integrator, do not connect to customer SCADA. And if you're a customer, don't be letting system integrators connect to your SCADA.

Also, questions for automation purchasers to think about:

Have you assessed the risk of a stealth virus/worm infection like Stuxnet?