Much of today’s excitement and press related to the Internet of Things (IoT) revolves around the data and analytics generated from new IoT applications and how to apply them to changing business models. Though we do discuss the “things” in IoT, to me they get short shrift when it comes to the discussion. Obviously without these things there would be no IoT. But just how hard it is to actually measure and gather the data and then adjust the devices is often ignored in our excitement to discuss the value of the data. After spending a few days at National Instruments NIWeek 2016, I think I have gained a new appreciation for the complexities when it comes to actually getting to the data and making it useful. And NI is a key player in the data acquisition, monitoring and control, for at least the foreseeable future Now, NI is about as “geeky” a company as you can find. Founded in 1976, NI is known as a leading provider of test, measurement and control equipment, and if ever there were a non-glamour subject to most people, these topics would be it. However, ask an embedded engineer or developer, and NI’s LabVIEW software and accompanying hardware has a firm place in their heart for actually developing and deploying systems. (Image Courtesy of National Instruments) In easy to understand terms, what does NI provide? If you have a widget, say an engine, and you want to design a system to control and monitor that engine, NI can provide the software (LabVIEW) and the hardware (test and measurement as well as the controllers) to make it possible. Now that’s IoT, and NI has been doing it since 1976. So, what’s so hard about “getting the data from the things”? Just about everything: the environment(s) they have to work in, networking multiple systems together and actually connecting to things to get to the data.

• The Environment: Think shop floor: dirt, dust, loud noises, heat, humidity, just about every bad thing you can think of. But that’s not all. Think about really harsh environments outside, like oil rigs in the Arctic or at the equator.
• Networking: Not only do the networks have to exist in harsh environments, but they have to coexist with interference from spinning wheels, motors, generators, microwaves, etc. Now extend that single network to supporting several of these systems on a manufacturing line—all that needs to be monitored, with timing coordinated to keep that line up and running.
• Getting the Data: So how do I connect a sensor to an actual motor? First of all, do I have an existing system, or is this a greenfield (new) installation? Obviously, it’s easier in a new application where I can install sensors from the beginning, but a huge part of IoT is adding data collection, analysis and control to existing systems. Think about an existing motor or robot or factory line—what we call brownfield installations—that were never intended to be connected or measured. How do you retrofit a connection to these things?

NI has a fairly novel approach to the test, measurement and control problem. They combine a flexible software package (LabVIEW) with a Field Programmable Gate Array (FPGA)-based piece of hardware that can be connected directly to the sensors. This integrated system provides some key advantages. First, you can connect and aggregate a number of sensors to a single controller, taking advantage of a single processor / storage configuration. Second, they use FPGAs. In layman’s terms, FPGAs are re-programmable pieces of silicon that control and monitor the actual devices. FPGAs have a number of advantages over a custom, including time-to-market, cost and long-term maintenance. Because FPGAs are re-programmable, you don’t have to spend time and money to design and develop custom silicon. In addition, FPGAs provide the ability to quickly and easily update, improve and maintain systems over time, without having to produce new silicon. There are disadvantages, however. NI’s system (hardware and software) is tightly coupled to maximize its effectiveness. Many embedded designers view this as a proprietary hardware / software solution and may not want to get locked into committing to both hardware and software from a single vendor. Others may look at the NI solution and see it as less flexible as direct programming in the language of their choosing. Finally, some engineers may believe that an FPGA solution is not what they need (for whatever reason, cost, performance, flexibility), preferring instead to design a fit-for-purpose semiconductor for their final solution. Longer term, there are some real questions about how NI’s hardware solutions will evolve. I believe that computation and storage are being continually pushed closer to the actual sensors and devices. What is now an analog interface running to a controller from a sensor will go away, and sensors will integrate with processors on a single board and run a standard IP interface to the aggregation point. This can be seen in the new Industrial IoT (IIoT) gateways being delivered by companies such as Dell, Cisco Systems and Hewlett Packard Enterprise and promoted by the Open Fog Consortium. Now, I don’t believe that the entire IoT world will go this direction, but this is the wave of the future, and how NI adapts over time will be telling as to how long they will be in the heart of “getting the data from the things”.