By performing operations at the edge rather than the server, overall system performance can be greatly enhanced.

The two main topics at the IoT conferences I have attended recently are security and big data. Security is presented as one of the main barriers for adoption of IoT in a big way, and cases like the Target and Home Depot security breaches help fuel the argument.

Big data, on the other hand, is held as the key to monetizing the IoT ecosystem. The power of the IoT solution is in the data about the client/user that it can give to the IoT service provider. IoT developers are spending the majority of their resources finding ways to collect and analyze data, and the more they collect, the better it is. The twist, and pitfall, is that the amount of data moving through the system can swamp the system’s servers and hubs and overwhelm the databases.

It’s not only a problem of magnitude but also of quality and relevance of the data. With the large number of new and sophisticated sensors available today that can easily connect to controllers and communicate through the network, eager engineers and product managers are happy to embrace the technology and take all the sensors they can get. The same goes for data—the bigger the better.

This approach that any data is good data, and we will manage it on the server side, can be one of the biggest problems that product managers need to control. New sensor technologies enable new systems to monitor a large number of parameters at a low cost, and send all the data via wide bandwidth communication to a large, distributed bank of hard drives. This sounds great to every engineering and product manager, but this could also be a trap.

In the last few months, I’ve worked with lots of IoT vendors, and all of them were, in my opinion, overly obsessed with collecting data. In one case, it was a continuous monitoring of air pressure in car tires—a number of times every minute. This data was sent with a GPS location to a server. This was a retrofit system and not integrated into other monitoring systems in the car.

Do we really need to know this information with this resolution? Isn’t it more efficient to send only changes or when the pressure goes below or above a critical level and then send the GPS location? Another company was monitoring body temperature in a number of locations at a 10-Hz rate with 10-bit resolution. Does our body temperature change that fast? Do we really need 10-bit resolution for this measurement?

The implication of this issue goes beyond just data. In both of those cases, battery power consumption was a critical design aspect. Reducing the power consumption is actually a key for the adoption of these products. Reducing sample rates lets the system spend more time in sleep mode, leading to less power consumed. Reducing the size of data sent over a wireless Interface, a major power consumer in most IoT systems, can also significantly reduce the power consumption.

Another option for reducing the data size is to move from a 10-bit A/D to an 8-bit part. This can reduce the power consumption by 50%.

One concept behind this approach of more data is the ability to process all the data in the server. This approach of “let’s get all the data and figure out later what’s needed” could be useful in some cases, but finding ways to do more processing on the IoT edge device can reduce the amount of data sent. This can enable the use of smaller bandwidth, lower power communication, and overall lower power consumption for the system. One limitation to implementing this approach is the added complexity on the device side, and the need to run some background processing to analyze the data locally before sending it to the server.

1. Timing for a general embedded control system.

Figure 1 demonstrates a typical embedded control system that can be part of an IoT, M2M, or industrial control system. The system is running continuously, at a timing cycle defined by a timer input (running in an endless loop). This example shows a system that reads data from two sensors; one is an ADC that’s accessed via a system register, and the other is connected via an I2C serial bus. This information and some other digital input data are sent to the host processor every cycle. The sample system also shows a general system interrupt service routine (ISR) and activation of some external actuator. In this sample system, the data is collected and sent to the host in every cycle; you can see that a significant amount of time is spent idling and waiting for an external response.

The CPU utilization in this example is about 60%, which means that for 40% of the time, the CPS is running and consuming power without any meaningful benefit. One way to improve system performance in this case is with a hardware sleep mode. Putting the CPU and related devices in sleep mode will significantly reduce the power consumption during the idle time, by more than 90% in many cases. The problem developers are facing is managing the timely system transition into and out of sleep mode.

2. Timing of parallel data processing.

In the system shown in Figure 1, the time spent in idle mode is about 40% of the overall processing time. Figure 2 shows the same system, but with a parallel processing architecture. This system uses the time spent in idle mode to locally process the data collected. The system can also collect data for statistics and consolidate it into one transmission cycle. This can reduce the amount of data sent to the host or enable the system to work, at some level, independently from the host.

To implement this approach, many developers are using an RTOS to manage the system’s different processes. The problem those developers face is the extra resources required to run an RTOS, including a more powerful processor. This is not an efficient approach and may not even be possible when it comes to legacy devices with smaller controllers. This is where SynthOS, an application-specific operation system generation tool, can step in, as it takes as input the source code for the different tasks that needs to run on the controller and builds a complete system that manages the execution of those tasks based on a simple configuration file.

Using SynthOS, users can define the main task responsible for collecting data from the system’s sensors. It can also spawn other tasks that will monitor those sensors or use interrupt-based monitoring. The user can define tasks to process the data before sending it to the server. Those tasks can be defined to run in the background at a lower priority. The user can run filtering, averaging, or min/max detection in the background and minimize the data sent. SynthOS can also manage the sleep-mode operation—it’ll put the system in sleep-mode that can wake up on interrupt. This approach can also lower power on the device side due to less data that needs to be transferred to, saved on, and processed by the server.

Jacob Harel is the Vice President of Business Development/Product Management at Zeidman Technologies. He is the named inventor on several patents. He holds a BA in Computer Science and Economics from Tel Aviv University.