Making Industrial Software Work like Apps

April 28, 2014
Over the past five years, design requirements for industrial software have changed dramatically. In this article, three of RedViking’s software development managers discuss how they’ve seen usability expectations rise for manufacturing and testing software.

[Editor's note: To make this article quicker to read, it is presented in Q&A format.]

How has industrial software design changed over the past five years?

Greg: It used to be acceptable to have a grid view with simple status updates. Today our clients require actual views of the parts being assembled with highlights where the parts are to be placed. And historically where touch screen devices wouldn’t have ever been considered, we’re looking ahead to multipoint touch with zoom and scroll, like you have on a smartphone app.

Doug: Five years ago, an operator would’ve had to look at a manual to know the sequence to torque bolts onto a part. Now we’re building inherent work instructions right into the UI (user interface). Today they need to be able to see the torqueing pattern, know when they’re successful, and then show which bolt to torque next.

Jason: We also like simple call outs and a clean interface to make the system more intuitive. It makes training a lot simpler because people can be easily trained across multiple machines, and it makes operations a lot more straightforward for the user.

Doug: For the operator’s sake, it’s a lot better. If you have to do 12 click-throughs for the job you do every day, you’re going to hate it. A lot of our changes are driven by a better understanding of what the operator does frequently and infrequently.

Is this new software harder to maintain than the old “boxes and text” UI?

Greg: No, but it really pushes the need to have a good configuration interface. Our clients are the experts on their processes. We provide them the ability to upload images and highlight areas of the images for an individual process. And they want to have a technician do updates, not an engineer.

Jason: That’s been a big change the past few years. I’ve seen it go from “Hey, I need an engineer to change the test configuration,” to where an operator can do it right on the screen. It involves more work in the initial development of the software, but it’s easier for our clients to use and manage long term.

Doug: We like the secure browser-based approach because it gives us a dynamic platform. You’re not developing something for a specific HMI (human-machine interface); you’re developing for a browser that someone can use from a laptop, a phone or an HMI. It makes the entire system easier to maintain because you’re not maintaining multiple device-specific applications.

How much does your design vary based on the user?

Doug: Our clients want software that is straightforward so that nobody has questions, no matter who the user is. Again, there’s a lot more work on the design side, but it costs our clients less in the long run.

Greg: Our users go to lunch and they go on Facebook and Instagram and Twitter and all of our stuff has to be just as intuitive as that. We don’t write code and compare it to other industrial software as much as we compare it to all the other applications that people interact with.

Jason: We have users who are in their 20s and users who are in their 60s and we need to make sure it works well for both ends of the spectrum.

How do you evaluate software usability before you release it?

Greg: We build in an approval phase where the UI look and feel are approved before development begins in earnest. That way everyone can understand what it’s going to look like and how it’s going to act before the back end is created.

Doug: If you go through development before anyone has seen the UI, you don’t know what you’ll end up with.

Jason: I also like to have someone use an application before they know what it is or what it is supposed to do. Can they figure it out just by playing around with it? The less we have to put into a “how-to” document, the better.

Doug Brown is senior software engineer; Greg Giles is director of MES error proofing systems; and Jason Stefanski is manager of test system software and controls at RedViking. They each oversee teams of engineers who design software for manufacturing and test systems. Based in Plymouth, Mich., RedViking is a member of the Control System Integrators Association. You can reach Doug at [email protected], Greg at [email protected] or Jason at [email protected].

Sponsored Recommendations

Wireless Data Acquisition System Case Studies

Wireless data acquisition systems are vital elements of connected factories, collecting data that allows operators to remotely access and visualize equipment and process information...

Strategizing for sustainable success in material handling and packaging

Download our visual factory brochure to explore how, together, we can fully optimize your industrial operations for ongoing success in material handling and packaging. As your...

A closer look at modern design considerations for food and beverage

With new and changing safety and hygiene regulations at top of mind, its easy to understand how other crucial aspects of machine design can get pushed aside. Our whitepaper explores...

Fueling the Future of Commercial EV Charging Infrastructure

Miguel Gudino, an Associate Application Engineer at RS, addresses various EV charging challenges and opportunities, ranging from charging station design strategies to the advanced...