This past January SCADAware president Rick Caldwell pulled the development team, the sales team, and the marketing team all into a conference room to discuss the next major version of StatusWatch. We talked about jazzy new features, we talked about making the product still more resistant to network failures, and we talked about ways to move onto mobile devices, but one topic bubbled to the top more times than any other – Usability.

Designing and building a software product is a careful balancing act. Too few features and the product won’t be worth buying. Too many features and the product may be too unwieldy for the user. Too much focus on a glamorous interface can make for an application that feels disingenuous and tacky, while too little focus on usability can make for an application that is, well, unusable. As a member of the StatusWatch development team for the last three years, I’ve been keenly aware of these challenges. Customer requests flood in almost every day, and it’s not uncommon for us to find ourselves furiously coding new feature after new feature without allowing ourselves time to really stop and consider the long-term direction of the application.

StatusWatch is a complicated product. It collects data from hundreds and thousands of data points. It churns out custom reports. It fires off notifications by the hundreds (FG Wilson in Northern Ireland has over four thousand notifications in their system so far).  It chews through custom formulas left and right (CAT’s North Little Rock installation recently breached two thousand global function instances). Because of the application’s power, it can take time to learn, time to set up, and time to make small adjustments until everything is just right. What we’ve heard from our customers is that these things are increasingly too much of a time sink. Lee McGarry told me on my recent visit to Northern Ireland that his monolithic list of notifications is nearly unmanageable at this point, but he has plans to add still more in the near future. Mark Lynch in North Little Rock wants to implement still more of our powerful functions to be used in custom reports, but worries about the time required to implement those functions across his sizable install base.

As we sat in that conference room and began planning out what our key features would be for StatusWatch version two, we kept circling back to the user experience. One of the developers suggested a batch creation interface that would severely reduce asset setup times. Another suggested that notifications be restructured to allow for machine-agnostic alerts (this would reduce Lee McGarry’s four thousand notifications to roughly eighteen notifications). Management brought up the oft-discussed “report cell copy/paste/move” feature that could greatly speed up the creation of reports. Great ideas came from all directions, and very few of them involved adding any actual reporting functionality, just usability.

These things are coming, some in version two of the software, some sooner. The important thing is that we’re listening, we’re learning, and we’re working hard to make this product both powerful and usable. Powerful has been our strong suit up to this point, but I expect to see usability improvements start to muscle their way in very soon.

In ‘Andon Systems, How Do They Work? (part 1)’ we looked at the four main components of Andon systems.  In this part, we will talk about how the individual pieces function together as a system.  Just to recap, the four pieces we talked about are: Andon lights, Andon boards, a reporting tool, and a notification system.  If any of these are unfamiliar to you, have a quick look back at part one.

So let’s set the stage with a realistic example of a situation where an Andon system was being utilized…

You’re managing a ten station assembly line that produces a widget that is in high demand–if the line isn’t at peak performance at all times, you are leaving profits on the table.  Production is going like clockwork, but the operator at station three is noticing that his pneumatic wrench is loosing power and is starting to slow him down.  He doesn’t want to go looking for help because that would be time lost and likely mean the line would have to stop, so he makes the best of it and continues working.  Twenty minutes later the situation is deteriorating.  The tool is nearly useless and the operator goes looking for help.  Soon the line is at a stand still.  Seven minutes later, arriving at the maintenance office, he finds that there’s no one there.  After a couple of minutes of asking around, he learns that the maintenance team is in a meeting.  The operator heads over to where the meeting is being held and in five minutes he is headed back to his station with help.  Minutes later the tool is replaced and the line is once again moving.

So how could an Andon system have prevented the loss of a quarter hour’s profits?  Here are three specific ways in which an Andon system would have drastically improved or even prevented the situation.

1) The operator knew he had a problem well in advance of the line actually stopping.  If he had had an Andon light at his station, he could have activated it at the first indication of a problem.  This would have visually shown, on the light and on the Andon board, that the line was in danger of going down.

2) If the visual indication had been missed by the maintenance personnel, a notification system utilizing paging would have alerted them to the problem even when they were in their meeting.  Furthermore, if maintenance had missed or ignored the call for help, the event would have been escalated causing the next person up the chain to be notified.

3) The situation could have been avoided entirely if you had been able to run a historical report over the past year detailing the frequency of the problem.  Such a report would have shown that this problem had been happening on a regular basis and a better tool could have been selected.

These are a few of the benefits offered by even a basic Andon system.  You may be well served by a very simple system with just a few Andon lights and an Andon board or may want a smart Andon system that ties in with your other production systems.  Regardless, Andon systems have a lot to offer in terms of improving your lean production process.

The idea behind the Andon system is simple, eliminate wasted time when resolving issues that arise on your shop floor and keep your lean production process moving as smoothly and efficiently as possible.  Andon systems are generally made up of the following components: Andon lights, Andon boards, and a reporting tool.  Additionally, a notification system that allows for escalation can be an effective way to make sure that issues are responded to and resolved as quickly as possible.  In part 1 of this post, we’ll define each of these, and in part 2 we’ll look at how the pieces work together to continuously improve your process.

Andon Lights
This one’s fairly obvious, what’s an Andon system without Andon lights!  Andon lights usually consist of three or four differently colored lights stacked on top of each other and mounted on a pole.  These Andon light stacks are mounted at each station you wish to monitor.  Also located at each station, are several buttons that are used to control the Andon lights in that station.  Ideally the light stack should be mounted in  a way that maximizes its visibility to the rest of the shop floor, and the buttons should be mounted so that they are easily accessible to the station operator.

Andon Boards
Andon boards are large, high visibility displays (often LED or LCD) that show the current state of all the individual stations in a logical group (such as an assembly line).  Other information relevant to the process may also be displayed (such as parts completed)  so that the overall status of the area can be determined at a glance.

Reporting Tool
While an Andon system with just Andon lights and boards can be useful, you really need the ability to run historical reports if you want to get the most out of your Andon system.  Such reports can be used to identify problem patterns and track problem response and resolution times over days, weeks, or months.

Notification System
A notification system that utilizes pagers or cellphones and has built-in escalation can further improve problem response and resolution times by specifically alerting individuals responsible for responding to calls for help on the shop floor.  When an issue arises the responder can immediately be alerted to the problem without even being on the shop floor.  Furthermore, if the issue is not resolved in a certain amount of time, the issue will be escalated, alerting the responder’s boss for example.

Those are the basic pieces any Andon system must have to be an effective lean production tool.  In ‘Andon Systems, How Do They Work? (part 2)’ we will look at how these pieces work together to make your process more efficient.

Roger is, by any definition, a high-maintenance customer.  A phone call from him usually means that the better portion of two hours is about to be sucked up with questions and feature requests.  He pays his annual support fees on time every year, and there is never any question as to if he’s going to get his money’s worth.  He accounts for a disproportionate number of the phone calls into the help desk here at SCADAware.

That said, Roger is also one of the people doing the most to make our StatusWatch production monitoring software better, and he’s not even on our payroll.  He is a wealth of ideas and regularly surprises me with his vision as to how performance and lean manufacturing can be improved at his facility.  He is a rare gem of a customer, one who makes you work plenty of extra hours but also makes it worth it.

A few weeks ago, I returned to my desk after a meeting and saw a note telling me that Roger had tried to reach me.  My plate was already pretty full for the day, so I winced slightly as I reached for the phone to return his call.  After the standard exchange of business-appropriate salutations, Roger got down to business.

“I think I screwed something up in StatusWatch…” he said, in a very matter-of-fact fashion.  “…but actually I think it’s better now.”

Confused, I asked if “better” meant “no longer screwed up”.

“No, no, no.  I mean I think that by screwing it up, I may have kinda improved it a bit.”

Roger went on to explain that he had implemented a certain math function incorrectly, and in doing so had found an anomaly in the way we handled that math.  He had then exploited said anomaly to do some fancy math that was previously impossible within StatusWatch’s custom reporting tools.  He had stumbled across a bug and turned it into a feature.  Our original time estimates to intentionally add this feature had been quite sizable as well, so Roger’s discovery was going to save us several days of design and coding.  We still needed to correct the bug, but by using what was learned, we would be able to add that missing math feature with a fraction of the work.

Impressed, I thanked Roger for pointing out the anomaly, hung up the phone, and smiled.  By failing to follow the directions found in the product manual, Roger had just saved us over a hundred man-hours of development work.  By screwing up, he had helped us win big.

I look at mistakes in a different way since that day.  A mistake is no longer something to be avoided like the plague.  Rather, it’s simply a lesson that I haven’t yet learned.

Historically, connecting shop floor data collection software to CNC machine tool assets that contain the data has been, at best, a challenge. When designing and building machines, each machine vendor chooses for themselves what communication protocol to implement and what data they will make available. Proprietary protocols are an obvious problem, but even if a published protocol like MODBUS or Profibus is used, a manufacturing facility may still end up with a handful of different protocols accross machines, all of which must be connected to the same shop floor data collection software.

A common solution to this problem has been to use an OPC server as a data concentration point. This solution has been effective for PLCs and most other controllers since 1996. Popular OPC servers such as Kepware’s Kepserver, can use any number of add-on modules that allow the OPC server to communicate to the various shop floor protocols. The OPC server can then be connected to data collection software with relative ease. While the OPC server method works, it is not a perfect solution. Common concerns include the cost and maintainability of the various pieces of software linking the machines to the data collection software as well as satisfying IT security restrictions.

Enter MTConnect. The goal of MTConnect is to be “…a set of open, royalty-free standards intended to foster greater interoperability between controls, devices and software applications by publishing data over networks using the Internet Protocol.” In short, MTConnect is an effort to get the machine vendors and the shop floor data collection software developers on the same page and eliminate the expensive chain of products in the middle.

The way it works is simple. The machine provides a text file containing whatever data the machine builder chooses to make available. This text file is parsed by the MTConnect Agent, a piece of software that can be connected to multiple machines. The MTConnect Agent compiles the data gathered from the machine(s) and makes it available via HTTP to any applications that may want to consume it. This provides a simple, free solution for linking machines to shop floor data collection software. Though MTConnect is still relatively new, machine builders are adopting the technology and lean manufacturing software tools are beginning to offer support as well.