[Design View / Design Solution]
Deeply Embedded Devices: The Internet Of Things
Implementing smart IP connectivity schemes will improve efficiency and deliver better performance, which becomes more critical as the Internet of connected things approaches a billion by 2011.
T he “Internet of things” is about connecting products that create, store, and consume data via the Internet. This allows processing to provide results that people can more easily use. The basic technical requirements to enable it are vastly different from the current treadmill of mainstream Internet-connectivity technology.
Mainstream connectivity strives to constantly increase bandwidth, range, and features to counter dwindling margins and prepare for the next “killer” application. Whether this is HD-media serving, on-demand TV, 4-play (voice, data, Internet, and multimedia), Network Attached Storage (NAS), or the next thing you absolutely must have, mainstream connectivity requires a wider, faster-pipe mentality.
Mainstream provisioning, however, is fundamentally disjointed from the requirements of the Internet of things. While an Internet gamer will pay $150 to replace his 802.11b/g access point with the latest 802.11a/b/g/n access point to reduce game “latency” or increase virtual “survivability,” this isn’t a price option for adding connectivity to a thermostat, temperature sensor, garage-door opener, coffee maker, or lawn sprinkler. In short, the Internet of things dictates a significantly different adoption model than mainstream broadband support.
APPLICATION TYPES Applications can be categorized as open, embedded, and deeply embedded (Fig. 1). Open systems are compute-based products with purpose-loaded functions. They may change their nature from one use to another, such as a laptop that’s configured to be a word processor in one setting and an Internet-connected media player in another. Due to the varying uses of open systems, the capabilities must be flexible yet high-performance in nature, with the limitations usually driven by cost.
Embedded systems are fixed-function. They may offer very high or low performance, with a limited energy footprint. Deeply embedded systems are single-purpose devices that detect something in the environment, perform a basic level of processing, and then do something with the results.
The Internet of things is primarily driven by deeply embedded devices. These devices are low-bandwidth, low-repetition datacapture and low-bandwidth data-usage “appliances” that communicate with each other and provide data via user interfaces. Embedded appliances, such as high-resolution video security cameras, video VoIP phones, and a handful of others, require high-bandwidth streaming capabilities. Yet countless products simply require packets of data to be intermittently delivered.
Data-rate requirements and the corresponding power consumption vary significantly between the different device categories (see the table). Open-type devices utilize Pentium class or similar processing and run complex OS-based (operating system) protocols for communication. Such devices require mains power or use large batteries and have battery life measured in hours.
It is critical to reduce power consumption, design complexity, and cost in battery-operated embedded devices through the optimization of computation occurring in the device. This is done via specialized hardware or less flexible purpose-driven software.
Deeply embedded devices build on this optimization and often require battery operation, which creates a critical need for low power consumption. These products utilize low-power microcontrollers such as Microchip’s 16-bit PIC24F family, which features low-power sleep currents down to 20 nA and allows for the use of AA or coin-cell batteries for up to 20 years of operational life.
Examples of deeply embedded, Internet-connected devices are: • Information displays for the home that can integrate heating and cooling control with lighting, music, and information displays (e.g., a Web browser) • Security still cameras that provide an extra level of coverage for monitored services • Appliances that allow time-of-start control from utilities for smart-energy control to reduce consumers’ electricity bills • Heavy equipment with sensors that can provide remote indication when in need of pending service • Toys or multimedia handsets that could be configured for subscription services, allowing updates during off periods.
The 802.11 protocol provides two basic methods of connectivity (Fig. 2). The primary method, called infrastructure or basic service set, is implemented as a structured network with at least one central point that routes traffic among the devices and onto other networks. In this method, the central point is commonly called an access point. All communications occur through the access point.
The second method allows “unrelated” devices to connect temporarily. This mode is called ad hoc, or independent basic service set. Ad hoc communication occurs from device to device, but allows many devices to share the common network.
INFRASTRUCTURE CONNECTIVITY A primary advantage of 802.11 over other wireless protocols is its intrinsic ability to connect devices to the Internet. This functionality is provided only through the infrastructure mode of operation, though. The Microchip TCP/IP stack and ZeroG 802.11 radio combination supports both infrastructure and ad hoc modes.
For instance, vehicle diagnostics can take advantage of deeply embedded Wi-Fi solutions. Developers spend considerable effort designing the hardware and software for user interfaces in these applications. However, PDAs such as the iPod touch or cellular phones such as the iPhone are perfect for user interfaces with a rich and intuitive feature set. Most include Wi-Fi, which allows the use of infrastructure or ad hoc modes in the ZeroG module.
The PDA or phone can connect to the ZeroG module, and the PIC24F16-bit microcontroller runs the Microchip TCP/IP stack for ad hoc mode (Fig. 3). The PIC24F microcontroller connects to the vehicle using any of the standard on-board diagnostic (OBD) interfaces like J1850, J1939, and ISO 15765-4.
Vehicle status, such as RPM, MPH, and battery voltage, can be displayed in a variety of forms (raw values, graphs, or gauges). Once disconnected, the PIC24F can connect to a central server using infrastructure mode to upload data or download new firmware or parameters.
Reprints
