The Internet of Things (IoT) will by its very nature be composed of a fantastic variety of elements each optimized for a different function. Wearable devices will be optimized for low power and local connectivity, while wireless bridges will be optimized for transfer efficiency and flexible protocol support, and your connected kitchen appliances will focus on ease of use. These diverse requirements mean that the underlying hardware, most likely based on an MCU, will also need to have diverse feature sets for optimal implementation. If you think we already have too many MCU choices, the next generation of IoT-targeted devices will make your head spin.
Diverse requirements drive feature diversity
One of the most obvious requirements for the Internet of Things (IoT) is connectivity. Without the ability to communicate we just have a “Thing” not an Internet of Things. Connectivity covers a very wide range of capabilities, however. Just look at the Hotenda Wireless Solutions TechZone home page and you will see a dizzying array of wireless solutions for Bluetooth, cellular, GPS, ISM, RFID, 802.11/Wi-Fi/WiMax and 802.15.4/ZigBee, and that is just the starting point. Will every MCU need to support all of these wireless protocols? MCUs would bust the power, cost, and complexity budgets of just about every IoT design if they did. So what can we do?
One approach will be to specialize the functions of key IoT devices so they can simplify their connectivity requirements. For example, not every sensor will need to connect to Wi-Fi. A sensor can use just a low-power and efficient short-range connectivity standard. Sensors could use this standard to connect to a sensor “bridge” that then supports connectivity to devices further away, eventually reaching the Internet proper. Other specialized elements would provide storage capability so that locally-generated data can be saved until a connection to the destination is available. For example, heart-rate data and travel-path information taken during a bike ride might be stored on the local activity monitor until it gets within range of the health aggregator back home. Computational elements could also be allocated within the network to provide distributed computing so that large data sets can be processed and condensed prior to transmission. Since wireless communications can be power hungry, a small amount of power used to consolidate data prior to transmission can significantly boost overall power efficiency. Additionally, because data may need to flow between several intermediate points to get to the final destination, savings on the front-end can also pay off all the way down the line.
An example of a diverse set of Internet “things” is illustrated in Figure 1, and we will use this example to further explore how differentiated functions will be critical to creating a successful IoT deployment. Several of the diverse types of elements previously described are present, along with some new ones. On the edges of the IoT are distributed sensors and actuators – the IoT interface to the “real world”. Familiar elements here are personal activity monitors, location trackers, and environmental sensors, along with the associated actuators for things like heating, cooling, lighting, and building access. Behind these “edge” elements are sensor fusion devices that collect sensor data and combine (or fuse) diverse measurements to create additional knowledge for use by higher-level applications. A common example of sensor fusion is the combining of GPS and atmospheric pressure data to determine altitude as well as position. Sensor-fusion devices are typically connected to bridges that translate between one protocol and another; often between wired connectivity and wireless. In some cases local storage is required to cache sensor data for later download – for example, when an activity monitor information manager stores heart-rate information for later download to a cell phone application.
Figure 1: Internet of Things simplification through specialization.
Beacons will be sources of information feeding the IoT and can represent advertising, environmental, or location. For example, beacons might transmit distance, environmental, and altitude information for use on bike trails. Do not be surprised, however, if they provide an advertisement for a new bike accessory as the price of the service. Sensor-fusion bridge devices will combine data from multiple beacons and sensors to filter out data not needed (or wanted) depending on the receivers operating mode. This filtering can go in both directions, so that personal information (like your heart rate) is not available to an eavesdropper (perhaps during a job interview).
Storage and computation elements may be included in sensor-fusion bridge devices or as part of a communications bridge that efficiently translates wireless data between various formats and provides for data security and integrity. Once a sensor connects via Bluetooth to a bridge the data can then be stored or forwarded using a longer-reach-wireless standard, such as Wi-Fi. The bridge will need to have at least storage and communications functions, while higher-end devices will include additional processing capability. The additional processing can be used to combine various sensor readings so that the “upstream” devices need only be alerted when a complete data set is ready for retrieval or if readings are “out of bounds” and an alert needs to be issued.
MCU diversity and the evolution of the IoT
A current trend, one that will certainly expand for the IoT, is to combine key wireless hardware components with important software drives and protocol stacks to further simplify the design and creation of the diverse devices required for the fully-realized IoT. As an example, Nordic Semiconductor has created a family of highly integrated wireless MCUs that provides an integrated hardware and software solution, as illustrated in Figure 2. Starting with a standard ARM Cortex-M0 processor, CPU peripherals, abundant Flash memory and SRAM, Nordic also integrated a multi-protocol radio operating at 2.4 GHz. Devices in the family are pin compatible and support both Bluetooth low energy and 2.4 GHz operation. Precompiled (binary) protocol stacks are available from Nordic to make it easy to create high-level applications code.
Figure 2: Nordic nRF51822 wireless MCU hardware blocks.
At the IoT edge, devices will become more specialized as power-efficiency requirements will leave little room for excess Hardware “baggage.” Highly integrated and optimized devices like the Nordic nRF51822
fit most naturally at the periphery of the IoT and may start out as simple beacons and sensors. Specialization and diversity will most likely move into these types of devices as well, with some including additional storage, processing, or communications “hub-like” functions, pushing sensor management into the periphery to optimize data flow at the very source.
Bridge devices that will connect sensors, beacons, sensor-fusion devices, and other bridges to the wider IoT network will need to support a variety of wireless protocols. Initially, bridges may be implemented with multiple MCUs, each targeted at specific standards, and perhaps an FPGA to provide overall control, buffer, and security capabilities. As an example, the Freescale MKW2x family (such as the MKW21D256VHA5
) illustrated in Figure 3, provides connectivity for IEEE 802.15.4, the low-level networking standard many current Wireless Personal Area Network (WPAN) devices currently support. The on-chip RF transceiver meets or exceeds all IEEE 802.15.4 specifications applicable to 2.4 GHz ISM and MB
AN (Medical Band Area Network) bands. Thus, the transceiver enables connectivity for a wide variety of communications standards including ZigBee Pro network stack and application profiles for Smart Energy 1.x, Home Automation, Healthcare, and RF4CE, as well as the ZigBee IP network stack and the Smart Energy 2.0 application profile. The ARM Cortex-M4 processor has DSP capability to provide significant processing power, and the hardware cryptographic authentication unit supports key encryption algorithms including 3DES, AES, SHA-1 and SHA-256. A unique 128-bit ID is available on-chip to assist with device authentication and security key management.
Figure 3: Freescale MKW2x MCU family in IEEE 802.15.4 WPAN bridging.
The other connection to the bridge device requires a wider reach, perhaps using the Wi-Fi standard. An integrated transceiver module, like the Microchip MRF22WB0MA
, as shown in Figure 4, uses a simple SPI interface to connect to an MCU or an FPGA to add Wi-Fi connectivity. Since the MRF22WB0MA
is implemented as a complete module, the designer is free from regulatory compliance testing, for a much quicker time-to-market. If the module is used in conjunction with a Microchip PIC MCU, TCP/IP software stack and code libraries are available to further simplify implementation. A complete reference design, that supports GSM, GPRS and GPS communications formats, is available when the module is used in conjunction with the M2M PICTail Plus
Daughter Board. A Microchip Product Training Module describes the capabilities of the kit in detail.
Figure 4: Microchip MRF24WB0MA offers IEEE 802.11b connectivity.
Needed: A broader and deeper support ecosystem
This trend toward including more and more support for higher-level communications functions to speed development will be a key enabler for the rapid deployment of the IoT. The audio area provides a good illustration of how the support ecosystem needs to grow both wider and deeper for the IoT to develop rapidly. As an example, Atmel with its AT32UC3A0512 MCU provides a complete Digital Audio Gateway Reference Design (EVK1105
) that combines key hardware features with the needed software infrastructure required to create a complete system (Atmel provides an excellent Product Training Module for this kit). The Reference Design includes the board, a library of C source code, including floating point and DSP arithmetic, USB and TCP/IP stacks and application software for optimized audio, picture and video codecs, display drivers, web server, file system, and a complete RTOS.
Perhaps the most interesting element of the kit is the software audio decoders that are included in the decoder library, as shown in Table 1 below. The designer can simply select which driver modules to include in a project. Atmel even provides help in identifying the key licenses required for each driver. For the IoT to evolve, suppliers will need to provide not only a development ecosystem, but also provide help in any licensing or third-party agreement needed for product roll-out and launch. The IoT will have a wide range of licensing requirements and the elimination of related speed bumps could make the difference between a successful product and a failure.
|MP3 Decoder Libmad
|WMA Decoder (V10)
|AAC+ (Helix) (estimate)
Table 1: Software audio decoders: illustrating the growing trend for licensing in the IoT roll-out.
The heterogeneous nature of IoT devices will require a wide range of specialized MCUs to implement the dizzying variety of edge devices that communicate most closely to the “real world”. Devices further up the IoT network will diversify along familiar lines with various communications, storage, and computational capabilities that help optimize traffic efficiency. Suppliers will need to augment these specialized MCUs with reference designs that include sample code, drivers, stacks, and even assistance with licensing requirements for the IoT to roll-out as quickly as MCU manufacturers’ desire.
For more information about the parts discussed in this article, use the links provided to access product information pages on the Hotenda website.