As I approach the end of my 40-year career as CEO of National Instruments, I am reminded of the great progress and innovations the test and measurement industry has witnessed since 1976. We have gone from an industry driven by vacuum tube technology in the era of General Radio to a time when the transistor ruled with Hewlett-Packard to today, when software truly is the instrument—a transition that NI helped shepherd. Moore’s law has taken us for a wild, fast ride to say the least, and just when you think it’s run its course, process innovations extend into new dimensions (literally) and push performance even further.
Just like the transistor, NI started from humble beginnings, but it has relentlessly focused on engineering great products and empowering world- changing innovation through our customers and platform technology. Allow me to reminisce on what the past 40 years have taught me and where I see this market heading as I shift into the next phase of my career.
“Do for Test and Measurement What the Spreadsheet Did for Financial Analysis”
When Jeff Kodosky, Bill Nowlin, and I started NI in 1976, we saw tremendous room for innovation in how engineers and scientists interacted with and built test and measurement equipment. We founded the company on the premise that there had to be a better way to serve the test and measurement needs that we, engineers and scientists, faced. We couldn’t buy it off the shelf but at least we wouldn’t have to build it from scratch.
The general purpose interface bus (GPIB, IEEE 488) was our gateway. Our vision, as stated in 1983, was to “do for test and measurement what the spreadsheet did for financial analysis.” Stated today, the sentence loses some of its power, but think about the early ’80s. At the time, the tools for financial analysis were “locked up” and too expensive for anyone without a big budget to access them. The early incarnations of spreadsheets turned this situation on its head, and that is exactly what we wanted to do. We wanted to make it so that any engineer or scientist could access the same tools or platform used by the R&D teams of the leading technology companies. It was a radically empowering view at the time and, in many ways, it still is.
“The Software is the Instrument”
While others might have seen GPIB as a hardware play, we recognized it for what it enabled in terms of software. As the PC industry evolved (as well as Apple’s Mac, which we had a special affinity for, given its graphical user interface), that GPIB cable made it easy to analyze and present data in a customized way for our customers’ needs. They were no longer confined to the front panel of an instrument and their pencils and notepads for data acquisition. The opportunity to innovate then shifted to the software world, where programming languages needed instrument drivers for the connected boxes. Our strategy of writing and supporting those drivers offered a critical service that continues today as NI supports more than 10,000 drivers on the company’s Instrument Driver Network.
But that world still left engineers and scientists with the burden of using tools designed for computer science to perform engineering, test, and measurement tasks. Our answer was twofold: LabWindows/CVI, to offer engineering-specific tools in ANSI C programming, and LabVIEW, a graphical programming paradigm that took the way we think about solving a problem (in flowcharts and pictures) and turned it into compiled code. The story was simple: acquire, analyze, and present. Do it in software tools designed for a customer’s use case that was easy to learn yet extremely powerful. We coined the phrase ”The software is the instrument” to describe this approach, and seeing engineers and scientists save valuable time and get to results faster was all the market validation we ever needed.
Evolving With Moore’s Law
People talk about Moore’s law like it’s about hardware, but computational hardware exists only to run software (and maybe firmware). Once we made test and measurement all about software, we had effectively enlisted Intel, Xilinx, and many other billion dollar companies in our R&D staff. With customers and partners building proficiency with our software tools, we just had to follow the chips to deliver increasing value to test and embedded systems. This has happened, so far, along two key dimensions: multicore processors and FPGAs.
Because LabVIEW is graphical and, therefore, not obviously sequential, it is tailor-made for parallel processing. LabVIEW users were among the first programmers to easily migrate from single-core processors to multiple threads and multiple cores and see almost instant speed improvements. Obviously, it’s possible to take advantage of these trends with other languages, just like it’s still possible to write highly efficient code in machine or assembly language, but why would you? The pace of change in modern electronics means you can’t waste time doing by hand what a tool can easily do for you, and we hear that over and over from LabVIEW users.
That goes to an entirely different level with FPGAs. Some problems are just better solved in the highly parallel, deterministic world of silicon. But the toolchains and programming constructs were inaccessible to most mechanical engineers or medical researchers who were experts in their measurements and problems to solve (not digital design). We recognized this in the late
1990s with LabVIEW’s graphical paradigm. We were on a quest to deliver the power of FPGAs to LabVIEW programmers, and we’ve done that. A quick look at our Engineering Impact Awards winners demonstrates the power of this technology: applications ranging from regenerating and restoring organ function damaged by disease or trauma to setting a world record in 5G wireless spectrum efficiency with massive MIMO.
