Process for Updating Legacy Testers


One simple truth that test and automation engineers know well is that technology is always changing and advancing. Even the most state-of-the-art system today will be obsolete tomorrow. Obsolescence is caused by a number of factors, but regardless of the cause, if you don’t closely support your system, it will eventually become outdated and it will need to be updated. That being the case, it is important to have a good strategy for updating systems when they become obsolete. You may have a test stand that stood up to evolving technology very well - or maybe not so well. In either case, having a good plan for when you need to update will help you extend the life of your new system and get the most out of your investment.

Small Problems can Become Big Problems

Chances are that there is only a small handful of items that are actually driving the update. For example, the OS running the stand is no longer going to be supported. Or, perhaps a critical piece of hardware no longer functions, and the original vendor no longer carries it. Perhaps the devices under test have evolved to a point where the existing system is insufficient to handle the process.

Problems like these rarely come along by themselves - there is almost always a cascading effect somewhere. For example, consider one company who had a test system running on Windows XP. It consisted of some PC based data acquisition instrumentation, in addition to some external boxed instruments. With Windows XP support coming to a close, the company’s maintenance policies required an update to Windows 10. This didn’t cause an immediate issue, because all of the application software was able to run fine on Windows 10. However, the driver that supported the critical data acquisition card was incompatible with the Windows 10 64-bit kernel. Since the driver couldn’t run, the data acquisition card couldn’t be used. A similar replacement was found, but its application programming interface (API) was different from the old one. Therefore, the end application required some rewriting, during which some old bugs were uncovered and some build issues encountered. By the time the system was running again the company had spent several times more money than they had intended to spend on the update. After all, there was really only one item that was incompatible with the new OS. But that one issue caused a cascade of other issues, and at the end of all of this, the system still contained mostly old and continually obsolescing hardware and software.


As the above case study and most likely your own experience indicate, it is always best to have a plan for updates. Plan maintenance, plan replacements for hardware, plan software updates, plan to be ready for more advanced parts coming down the pipeline next year, etc. Sometimes, it is tempting to only worry about what is broken now, and not think about what might happen in the future. This works while it works, but as soon as something critical breaks, or loses support, or is no longer available for purchase, your problems metastasize. It doesn’t have to be that way. Planning regular maintenance can greatly reduce and limit the effect of those unforeseen problems that always have a way of appearing.

Consider the lifecycle of the various hardware components in your system. If you have components that are nearing the end of their life, consider replacing them, even if those components are not the immediate cause of the update. There is little gain in an update that overlooks a piece of hardware that will force another shutdown and update in a year or perhaps even a matter of months.

Platforms and Standardization are Your Friends

In addition to lifecycle, standardize your hardware around a common platform. By this, I mean do what you can to standardize the hardware in your stand to either use common interfaces, or to be from a common vendor, etc. In addition, many companies have standard components that they use for various functions - for example, a standard DMM, or standard Frequency Counter, or standard Power Supply. Do what you can to make your system use components that are standard to your company. It makes maintenance much easier.

Consider the communication interfaces that your hardware will be using. There are many different interfaces available out there, and the complexity of your software increases proportionally to the number of different hardware interfaces your system requires. Having many different interfaces also makes your system more vulnerable to obsolescence in the future. Instead, choose instruments that either have a common hardware interface, such as GPIB or Ethernet, or those that use a standard command set, like SCPI.

Write Modular Software

Write modular software. Generally speaking, this means that each piece or module of software has a single responsibility. Without following good design practice, software has a tendency to spread its tendrils out into other areas of code. One hardware resource may be referenced in multiple places, or two pieces of code might have references to one another, making them interdependent. Modular code minimizes this effect, since the goal is to limit the scope of each individual module to its own area of responsibility. If in a year, you need to swap out one piece of hardware, you can modify a single module of code rather than having to rewrite the entire codebase. This not only allows for quicker, more cost-efficient updates, but it also minimizes bugs that can be introduced to the existing code by the update.

Plan Now, Save Later

In general, the goal of any update should be to set yourself up for the best outcome in the future. A little bit of thought into all of the hardware and software that your system relies upon can guide you in the right direction when prioritizing the updates you want to do on your legacy system. Many times, the cheapest option now is not the option that will cost the least in the long run. An ounce of time and effort now along with investment in the right equipment is worth a pound of time spent troubleshooting complex issues in a crunch and purchasing hardware at a premium. Plan your updates, and be kind to future you.

Wes Pierce

Senior Systems Engineer

Wes has always been an eager learner with an ever-increasing array of interests. Following graduaton from Texas A&M University with a degree in Mechanical Engineering, he immediately jumped into the controls and test & measurement industry working at National Instruments. All of the exposure to so many fascinating applications at NI eventually drove Wes to found his own business to directly develop and work on systems integration projects for customers of his own. After seven years spent designing and building LabVIEW-based systems for clients in many different industries, Wes joined the brilliant and talented Endigit team in 2020, looking to continue learning, pursuing interests, and developing exciting technical solutions for customers.

Wes enjoys spending time with his wife and two children and being outdoors hiking, skiing, and exploring the countryside. He is also a licensed private pilot.

Add new comment