Do You Really Need All That Raw Sensor Data? No! There’s a Better Way

If you’re building applications that feed off streams of sensor data, there’s a good chance you’re a data junkie like me. There’s a certain sense of satisfaction in seeing your sensor devices pour data into your applications, and it’s easy to add more data streams with the wealth of readily available sensors.

Sensor systems can capture macro events that are deconstructed to an extended sequence of measurements with astounding levels of detail. Even the most ardent data junkie will nevertheless admit that massive amounts of raw data by themselves don’t advance the objectives of the application. It's about the events themselves and not about finely sliced and diced measurements of each event. Fortunately, the emergence of smart sensors can help restore focus to events of importance to applications and their users.

As it becomes easier to generate more sensor data, data streams turn into floods of raw measurements that can overwhelm the embedded hardware and software intended to make something useful out of all that data. It’s not just a matter of the data exceeding the capabilities of the processing and communications plumbing. The detailed measurements can become a distraction to application developers and users as they fixate on small details rather than higher-level abstractions usually needed for decision making.

Dealing in abstractions

Abstraction means some loss of detail by definition. For data-centric applications, working with derived data abstracted from multiple raw measurements can worry engineers that are understandably concerned about missing some detail that could later prove important. That’s certainly a valid concern for applications, such as data recorders for transportation or security that need to identify some novel event or untangle some root cause.

For many consumer and industrial applications, however, the specific characteristics of an event of interest are well known. A sudden fall of a person or object generates specific motion artifacts, and industrial motor faults exhibit predictable vibration patterns. The details of those characteristics generally don’t matter to many higher-level applications. The application only needs to be alerted when the fall or fault event occurs. Of course, the mechanisms used to detect the alert condition do require detailed sensor measurements.

I faced that same issue on a project that generated a massive amount of data for an application that dealt with high-level events. The detailed data was needed to generate that high-level event information, but we’d run out of storage if we tried to archive any measurement data, beyond some brief window of activity. An abstraction method based on machine learning and other analytical methods did the trick.

After plenty of testing, we were confident that we could generate the abstraction on the fly and just write over old measurement data.

Focusing on events

State-of-the-art sensors such as STMicroelectronics’ line of iNEMO inertial measurement units (IMUs) offer this kind of capability for always-on applications. The low-power IMUs include the LSM6DSOX for battery-powered consumer applications, the LSM6DSRX for high-accuracy applications, and the ISM330DHCX for industrial applications. These IMUs integrate a programmable finite state machine (FSM) and machine learning core (MLC) that you can train using your own training data sets (see, “Use a Smart Sensor’s Built-In Machine Learning Core to Optimize “Always-On” Motion Tracking”).

When one of these devices detects the patterns associated with an event of interest, it can generate an interrupt for a host processor. The host processor can then execute appropriate application logic. In fact, if you want the raw motion data alone, or in combination with the event interrupts, you can read the raw measurement data, as with any motion sensor (Figure 1).

Figure 1: STMicroelectronics iNEMO IMUs integrate a complete digital chain that generates conditioned data for the integrated FSM and MLC, and for host access through the IMU’s first in first out (FIFO) buffer. (Image source: STMicroelectronics)

The ability of the sensor to monitor its own measurements and identify more abstract events reduces the load on the processor and communications channel—and points the way to a new generation of smart sensors. More importantly, sensors able to analyze raw data internally and produce useful information point the way to more efficient ML designs that supply more derived data than raw measurements.

Conclusion

Focusing an application solution on derived data rather than raw measurements doesn’t require an ML-capable sensor. For relatively simple data sets, the sensor system’s host processor may have sufficient cycles available to execute a decision tree to identify events. For larger deployments, however, you can use an edge computing resource between the sensor and upstream host to perform the abstraction transformation. Regardless of how you do it, the reduction of data to useful abstractions aids application areas where less can be more.

References:

Use a Smart Sensor’s Built-In Machine Learning Core to Optimize “Always-On” Motion Tracking

1 – https://www.digikey.com/en/articles/use-a-smart-sensors-built-in-machine-learning-core-to-optimize-always-on-motion-tracking