For decades, the basic architecture of sensor nodes consisted of a controller, a sensor, local storage memory, network connectivity, and a battery. Every system that is trying to collect data from the analog world is based on some variation of this system. Each must solve the fundamental problem of collecting data, storing critical parts of it, and taking appropriate action based on the data analytics. In previous data acquisition systems, sensor nodes would collect data and, if there was local memory, store a few hundreds of samples locally before transferring it to a central hub for processing. The hub would process the data and take appropriate actions. Communications were typically wired, using Ethernet or a similar industrial bus.
With the advent of the Internet of Things (IoT), every device in the field has started communicating over the network. A conservative estimate predicts that over 10 billion devices will be connected by the year 2020. These include cars, industrial automation equipment, medical implants, and new-age applications like wearables, smart homes, etc. Next-generation 5G networks are already being deployed in several parts of the world to handle the traffic expected from these devices. But there are several unanswered questions which data scientists and system designers are trying to address today: Which devices need to be connected to the cloud? How much information needs to be broadcasted? How much processing can be done locally? And who pays for the cloud?
A trivial approach to IoT is to upload everything to the cloud and handle processing remotely. While this may work for small and isolated systems, once the world becomes more connected and a plethora of systems are trying to upload information, system designers will need to consider the cost of network vs. local storage and processing. They will need to evaluate scenarios that reduce connection frequency, perform local storage and processing, and then perform periodic bulk uploads. The term “Industry 4.0” simply implies a future of connected devices. To ensure that optimal, cost effective, low power implementations are deployed in the field, each component of the system must be carefully analyzed today. In this article, we will examine the often neglected but most important aspect of any sensor node – local memory.
Figure 1: Traditional Sensor Node. (Source: Cypress)
Figure 2: Sensor Node in Industry 4.0. (Source: Cypress)
Sensor nodes are increasingly connected to each other as well as to a central processing hub through one or several wireless technologies including Wi-Fi, Bluetooth, and others. These wireless protocols allow for sensor nodes to be placed in locations that are not accessible with traditional systems due to the limitations and cost of routing wired networks. A mesh of wireless sensor nodes can be distributed through an entire factory automation floor and continuously monitor all critical system parameters.
There are new challenges to address with the move to wireless. For example, a traditional system would never have to worry about running out of power but the same approach does not work for wireless sensor nodes. These nodes must be designed to run on an extremely tight energy budget. Any improvement in power consumption that significantly affects battery life in turn means less frequent maintenance. Many times, due to cost constraints, system designers deploy solutions that are initially cheaper, but over time end up being expensive due to higher maintenance costs. One of the biggest costs in these remotely deployed sensor nodes is replacing on-board batteries. A system that is optimized to save 30% power directly corresponds to 30% less maintenance cost for replacing batteries.
What factors contribute to power consumption on these sensor nodes? A detailed system power consumption analysis of a typical BLE sensor node identified key parameters that affect battery life. The biggest contributors to system power consumption are:
Antenna power during data upload
Controller power when performing data acquisition
Local memory power consumption during data logging
The antenna power of a BLE system depends directly on how often the sensor node is trying to ‘connect’ and upload data to a hub. While BLE can support the upload of ~500 bytes every 10ms, rarely does a sensor node collect data at this 50KB/s rate. Typical environmental parameter sensing systems capture 100-500 bytes/s, depending upon the sensing element. This allows the BLE system to be designed for longer connection intervals to increase battery life. Longer connection intervals force the system to store logs of more data points than a system that has the freedom to upload data at will. Typical internal memory of an IoT controller ranges from 64Kbytes to 256Kbytes and major portions of this memory is occupied by the BLE stack and user APIs required for performing ADC and other housekeeping tasks on the node. This causes the system to run out of internal memory when storing the data logs, so logs must often be stored in external memory.
Since IoT sensor nodes are battery powered, external memory must be non-volatile to ensure data reliability. While there are a wide range of non-volatile technologies in the market, system designers prefer using a memory that offers a simple interface and the best reliability. The most common candidates for external non-volatile memory are EEPROM, Flash, and ferroelectric RAM (F-RAM). However, because Flash/EEPROM technologies were originally designed to offer good read performance, there are have severe drawbacks when they are continuously written to.
A Flash cell can be “programmed” to contain new data only if the cell is erased beforehand. Programming a cell allows a change of state from logic ‘1’ to logic ‘0’. During the next update, if the cell needs to hold a logic ‘1’, the cell must first be erased. To optimize erase speed and program times, Flash manufacturers use different page, block, and sector architectures. A page is the smallest quantum of data that can be programmed into the flash at one time. Flash devices contain an internal page size buffer that allows for temporary storage of data and once transfer from the external interface is complete, the device initiates a page program operation on a page that is already erased in the main array. If this page contains old data, it must be erased prior to a program operation.
Every time an erase is performed, the Flash cell deteriorates, which is quantified as endurance in a Flash datasheet. Typically, the best Flash devices are rated for endurance cycling of one hundred thousand erase-program cycles, after which they are no longer guaranteed to reliably store data. While this number appears large, we will demonstrate that this endurance falls short even in low-end data logging systems.
Some manufacturers implement byte programming and delayed programming from buffer to Flash memory. While these features do simplify the program operation into the device, they do not address Flash’s underlying endurance limitations. To compensate for these limitations, the system designer is forced to implement a complex file system to handle wear leveling of cells that also adds overhead and slows down the system. Similar drawbacks exist for EEPROMs.
We designed three systems based on F-RAM, EEPROM, and Flash that emulate typical IoT sensor data-logging behavior by performing data-acquisition of parameters like temperature, humidity, pressure, and acceleration. These systems were optimized using the best BLE connection interval and identical local storage algorithms. For the purpose of simplicity, we selected a slow BLE connection interval of 4 seconds and a data sampling rate of 100 bytes/s. Every sample consists of a snapshot of all the sensor data as well as a few marker bytes that will allow the receiving hub to parse the information and provide feedback to the operator.
Figure 3: F-RAM-based IoT Sensor Node. (Source: Cypress)
Figure 4: Flash-based IoT Sensor Node. (Source: Cypress)
Figure 5: EEPROM-based IoT Sensor Node. (Source: Cypress)
On-board current monitoring is used to accurately log current consumption of the system during each of the following phases:
Data Acquisition (ADC capture and read sensor data)
Write/ Program data to external memory
Upload data to hub every 4 seconds
For this analysis, we used a 64-Mbit Flash, a 256-Kbit EEPROM, and a 4-Mbit Excelon F-RAM from Cypress. The Flash device was pre-erased at the start of the experiment and supports 512 bytes/ page, while the EEPROM supports 60 bytes/page. The F-RAM is a byte-accessible ultra-low power F-RAM that has no requirements of pre-erase or page write.
A typical system run for an F-RAM based system is shown in Figure 6.
Figure 6: Current consumption of F-RAM-based IoT Sensor Node. (Source: Cypress)
View larger image
Table 1: System Power Consumption of IoT Sensor Nodes
Table 1 summarizes system performance in terms of energy consumption for all three types of sensor nodes. These systems were configured to upload around 500 bytes every 4 seconds, and current was monitored for 120 seconds. All three systems have identical performance in terms of data throughput with the only difference being in the algorithm used to write into memory:
An F-RAM-based system can write the acquired sample as soon as it is available since F-RAM supports byte accesses.
An EEPROM-based system can only write page-wise (64 bytes per page) and has a 2ms soak time to allow for completion of write. This forces the system to remain ON for an additional 2ms each time a page write is performed.
A Flash-based system can only write in pages of 512 bytes. The device consumes around 13mA during a program time of 20ms and has an additional 20ms period of status register update. This forces the system to be ON for a total of 45ms.
Table 2: High-Level Summary
We can see that an EEPROM-based system consumes ~22% more power than an F-RAM based system, while a Flash-based sensor node consumes ~140% more power than an F-RAM-based system. A closer look into the power consumption pattern shown in Figure 7 reveals why Flash devices perform so poorly in such applications. Program time overhead effectively doubles the total power consumption of the system.
Figure 7: Current consumption of Flash memory in IoT sensor Node (mA) vs Time (ms). (Source: Cypress)
In addition to the large overhead of power consumption, a Flash or an EEPROM based system also suffers from the shortcomings of the technology, especially endurance and erase power in case of Flash. Flash devices have limited endurance of around 10^5 cycles, which limits the life of the product. The system also suffers from down time during erase operations since Flash devices take significant time to perform chip erase. The power consumption during the erase operation will also add to the total power budget, further reducing power efficiency. These sensor nodes are battery-powered, but in case of an inadvertent power-loss, Flash or EEPROM-based systems can also suffer from a loss of data integrity. Flash devices must be programmed one page at a time, so the system must locally store one page of data until it has successfully written into the device. Any power failure during this period can result in the loss of at least one page of data.
F-RAM, such as the Excelon F-RAM from Cypress, addresses these concerns, making it highly efficient for IoT-based data logging. F-RAM endurance is 10^14 write/read cycles and provides immediate non-volatility and byte accessibility. Its low write/read current of 2.4mA, standby current of 2.3uA and hibernate current of 0.1uA, yield extremely low power such as is required for battery-operated IoT devices.
|Nilesh Badodekar is an Applications Engineer at Cypress Semiconductor. He has a master’s degree in Visual Information Processing and Embedded Systems from Indian Institute of Technology, Kharagpur, India.|
|Girija Chougala is staff applications engineer at Cypress Semiconductor and works on various non-volatile memory products (nvSRAM and F-RAM) and system solutions. Girija’s responsibilities include defining new products, systems analysis, creating validation platforms, solution demos, development kits, performing product validation, resolving technical issues for customers, and developing technical collaterals such as datasheets, applications notes, and whitepapers.|