Technology forecasters have been predicting that the Internet of Things—the technologies around connecting everyday things to the Internet—will be the foundation of the next major networking wave. The volumes being discussed are huge — 10x to 100X that of mobile phone shipments per year.
The important question to consider is what application will drive that huge adoption? Desktop (laser printer) publishing drove the early Ethernet market. Wi-Fi volume took off when Intel put an 802.11 chip into its laptop reference design. Mobile phone volumes increased exponentially when the handsets became affordable.
Clever smartphones and tablet applications, which connect to low cost products, will likely drive the Internet of Things from the hobbyist market to the mainstream market. Smartphones already enable consumers to connect to anyone and search for anything–anywhere, anytime.
It is only a matter of time before smartphone and tablet owners realize they have a true universal remote control in their pocket. Then, they will want to monitor and control their “things” from anywhere, at anytime. Life style change is in the wind: Informa Telecoms & Media reported that in 2008, vendors shipped more smartphones than netbooks. These trends are setting the stage for the Internet of Things to take off.
So far, Internet-connect products have only held hobbyist’s interest because product prices have been high and installations have been complex. When the Internet cost-adder breaks below $30 and installation can be simplified to a plug and play experience, the market will have greater opportunity to expand rapidly.
Today, there are three target applications that show promise: reducing a custom installer’s customer support cost; saving the consumer money; and giving the consumer more comfort and peace of mind.
For example, companies that sell expensive products for home theaters or landscape irrigation usually sell their products through a network of custom installers. A truck roll for home theater installer can cost over $100, while landscaping services typically spends $10,000 a month in fuel charges.
With Internet connectivity, a product brand owner could add remote monitoring and control features to a product, giving their channel another product to sell. The channel is happy to increase revenue, and their customers get better faster service.
The result is happier customers and a loyal sales channel. One example is Monster Cable’s HTUPS 3700 home theater power supply, which has Internet connectivity features that enable their custom installers to provide remote diagnostic and problem remediation services to their end consumers. Monster won a CES Innovations 2010 Design and Engineering Award for the HTUPS 3700.
Products that save the consumer money show promise. Some examples are occupancy-smart thermostats and weather-smart irrigation controllers that can save 10% to 30% on consumer energy and water bills. There is an opportunity to sell home smoke, CO, flood, and freeze detectors that could send a text message or email to rental property or vacation property owners. These services could collect incremental revenue in the form of pay-per-alarm instance or smartphone applications for the alerting sensors.
Consumer products will ultimately drive Internet of Things market volume. It follows then that a successful Internet connected consumer product will have to satisfy three product requirements: low cost, easy installation, and reliability. Low product cost enables high volume. A hobbyist or rental property manager might spend $200 or more for an Internet connected thermostat, but the mainstream consumer will be stretched to pay an additional $30 over the typical $60 for a home thermostat.
Second, for the product to stay in the home, it has to be simple to use and install, because if it is not, it will be returned to the retailer. Elke den Ouden, of Philips Electronics , has found that 50% of all returned electronic products worked fine, but the consumer did not know how to use them. ABI research reported in 2009 that 30% of consumers struggled to install Wi-Fi products, and these products suffered from an 11% return rate. Mainstream retailers will tolerate 5% return rates, but not 11%. Installation complexity explains why Zigbee and Z-wave products usually installed by custom installers.
A major reason for the Amazon’s Kindle commercial success over the Sony’s e-book reader was its seamless integration with the Amazon book store using 3G. There was no USB cable and PC in the middle to complicate things, although 3G is expensive, a downside for a achieving low cost adder. Lastly, the Internet connected features have to be reliable. If the product continually fails to work, consumer word of mouth will kill the product’s adoption.
Product interoperability is not a factor slowing adoption. The abundance of remote controllers and battery re-chargers in homes proves the point. Retailers know that consumers come into their stores “on a mission” to solve a single point problem: to replace a broken thermostat or a garage door opener.
They don’t come into the store with a home automation problem, ready to make a big investment, so it is the Internet-connect cost adder and ease of installation that plays the biggest role in customer adoption.
The good news is that product interoperability can happen incrementally, over time, even after product has been in the field. That is because application interoperability can easily be achieved by connecting web services through published APIs that are “mashed up” in the Internet cloud.
Consider the example of an Internet connected smoke detector (Figure 1 below ) that can send a text message or email alert to the homeowner when smoke is detected.
Figure 1. Representative Internet connected product example.
There are three design elements to create an Internet connection. First, the smoke detector has to be connected to a LAN connection. Second, that LAN has to be connected to the Internet through a gateway or router. Third, there should be a web application server to receive the smoke warning and send an email or text message to the specified person(s).
There are two design patterns that can be used. First, a web server located in the product itself, and second, a web application server located in the Internet cloud (Figure 2, below ).
Figure 2. Web application server located in the sensor creates installation headaches for the customer (requires a fixed IP address, open ports on firewall).
Placing the web server in the product is the most common approach today. The advantage is that the product company does not have put a web server infrastructure in place, but there are two important disadvantages. It adds cost and complexity to the sensor, and it greatly adds to the sophistication required in the installation process. Web server software requires a 32-bit CPU running Linux, as well as the memory to support it.
At nearly 200,000 lines of code, the Linux OS turns the sensor into a computer that will very likely need to be rebooted several times a month. Consumers tolerate rebooting their computer and home router, but rebooting a smoke detector or thermostat will not be accepted.
A smoke detector function can be implemented with very low cost 8-bit MCUs, so a 32-bit CPU plus Linux based system is overkill. The bigger issue to consider is how the smartphone browser or application knows the smoke detector’s IP address when the smoke detector is located behind a firewall.
The solution is to require the consumer to apply a fixed IP address to the sensor and open a port on the firewall. A hobbyist (or IT department) will pay a high product premium, be willing play with his router’s port settings, and reboot the flood sensing Linux box twice a month; but the mainstream consumer that brings high volume potential will not.
Hosting the web application server “in the cloud” at a dedicated server facility (Figure 3 below ) is a more accessible design pattern for the high volume, price conscious consumer market.
Figure 3. Web application server located in the Internet cloud enables simple plug and play installation because server maintains NAT firewall table entry between the server and the sensor.
There are four advantages to placing the web application server in the cloud: lower endpoint cost, plug and play installation, greater product extensibility over time, and the value of a connected customer. In this system architecture, the cost of web server CPU and memory implementation is amortized over many users, not added to the end-point bill of materials.
8-bit MCUs integrated with RF radio that cost less than two dollars can be used in the sensor, keeping the BOM cost low. The firmware code stack is a factor of ten times smaller than Linux running TCP/IP, which lowers on-board memory cost and has fewer lines of code, meaning fewer latent software bugs.
The second advantage is giving the consumer a true plug and play installation experience. The design challenge is to have the consumer initiate a conversation to the sensor using a browser outside the firewall. The design solution is to have the cloud-based server maintain the consumer’s firewall network address translation (NAT) table entry between server and the endpoint.
The problem is that there are no Internet standards for NAT firewalls. You have to catalog the NAT algorithms in the abundance of available consumer firewalls. When these challenges have been overcome, the effort to ensure plug and play installation is well worth it. When the product installs easily, it will stay in the home or office and not be returned to the retailer.
The third advantage is that the product’s function can be extended in the field by adding value to the web application hosted in the cloud. Software on the server can be rewritten to adopt new features that consumers have requested, as well as add features that were not even envisioned at the time of the original product design, and connect (interoperate) with other web services.
If the web server is located in the sensor, the in-home firmware upgrade process is too complex for most consumers. If software upgrades provide consumers real value, it can lead to revenue growth opportunities.
Fourth is the very high value in having connected customers. Bain consulting has found that the cost of selling to an existing customer is 20% of the cost of selling to a new customer. It clearly pays to keep loyal customers. For example, a perfect opportunity to offer a customer new products and services is when a she views product status from her smartphone application. With a connected application, customer behavior can be tracked and analyzed to predict consumer trends and inform better product design.
The downside to the server in the cloud approach is that implementation is ultimately complex because it has to support the huge number of endpoints the Internet of things implies. Friendster , the early social networking site, and the launch of Apple’s MobileMe (at only 20,000 accounts) are two examples of systems that were not built to scale. Both cases resulted in disastrous failures that had costly outcomes and recovery.
Two choke points are SQL transactions and managing open TCP sessions. First, at 20,000 plus endpoints, SQL transactions and managing open TCP/IP connections quickly become choke points in the system. SQL database architectures do not scale well because a modern server can only handle 100 to 1000 SQL operations per second. SQL transactions become a critical choke point because the most frequent SQL transaction is user credential checking. When the SQL operational limit is reached, system performance does not degrade gracefully.
Second, TCP/IP becomes problematic because a TCP/IP process server can handle 10,000 to 50,000 TCP/IP connections. For a server system to scale beyond that limit, the servers must be interconnected in a cluster to share data. Clustering raises costs beyond the obvious cost of the servers alone. The bottom line is that in fast-paced technology markets driven by the scale of smartphones, there is no time for redesigning a server for a product that unexpectedly takes off.
A handful of companies have started up to serve the Internet of Things business opportunity. These companies have produced systems that supply the Internet of Things networking by delivering cloud based services. Three frequently cited companies are Arrayent, Pachube and Widetag. By using their products you can focus on your core business, rather than building a server based system out of pieces and parts yourself. This saves you development time, cost, and risk.
The Internet-Connect System , for example, is a turnkey end-to-end Internet-connect system to enable brand owners to connect their low cost products sold at retail. Its core technology is a highly scalable (low cost to operate) communication server that provides a virtual web services interface for web application developers. It also provides hardware reference designs for low cost RF endpoint modules and the lowest cost ($5 BOM) Ethernet gateway to connect proprietary RF LANs to the Internet.
Pachube , London, UK, offers a “data brokerage platform for the internet of things” to manage data points from individuals, organizations, and companies. The service stores and serves data in both established web protocols and construction industry standards. It is used for collecting and pooling environmental data from around the world to utilize for analysis and sending out alerts.
WideTag , Redwood City, CA, delivers a scaleable and fault tolerant cloud infrastructure for communication and data storage. The company has built an “energymeter” that provides real-time monitoring and management of energy consumption, and it also offers a social networking-based site that pools ambient noise measurements.
Arrayent recently released two Internet-Connect Development Kits that enable embedded system designers to prototype products with Internet connected product functionality – straight out of the box. Arrayent supports both proprietary low power RF (sub-1GHz) and Wi-Fi RF LAN technologies.
Consider a smoke detector that augments its audio alarm with text messages and emails to specific recipients. A few reasons why you might want to buy an Internet connected smoke detector are to be alerted when there is a fire in a vacation home or rental property, or more practically, be notified when the battery is low before the pesky chirping sound commences at 2 AM in the morning. Fortunately, these alerting features are easy to prototype with the DevKit hardware and web application in less than a day.
The DevKit includes hardware and hosted software components that enable you to monitor and control your device. Since this is a battery powered application, we’ll select a low power RF implementation. On the hardware side, the Low Power RF Kit comes with an RF Module and a low cost Ethernet gateway. The RF Module’s digital I/O lines, analog inputs, and an RS232 serial port can be used to easily connect to most embedded systems. The RF module reference design uses a Texas Instruments CC1110; the chip integrates a programmable sub 1GHz radio and an 8051 MCU.
The default frequency is set to the 900MHz band, and at 10dBm output, using a star topology. The RF Module can comfortably communicate throughout 4,000-5,000 square foot house. The CC1110 also supports 128-bit AES encryption in hardware, which is the standard level of security for online banking.
The low cost Ethernet gateway features a BOM cost of less than $5, plugs into the consumer’s home router Ethernet port and provides the RF link that communicates with the RF Module. The combination of the RF Module and Ethernet Gateway enables our smoke detector prototype located behind a consumer’s home firewall to traverse that firewall and connect to web applications in the cloud, without any configuration required by the consumer (Figure 4 below ).
Figure 4. Arrayent Internet-Connect Development Kit for Low Power RF includes application development tools, RF module, gateway and Internet-Connect Service development account.
The DevKit also comes with hosted software tools to enable you to define, configure, and control a connected product prototype from any web browser. These components are the Internet Connect Server Account, the Configurator, and the Utility Application. The Server Account provides access to the servers and APIs. The Configurator application can be used to set up beta user or demo accounts, define device attributes, and define data to be collected.
You can specify information to be stored, tracked over time, or communicated back and forth between the device and the Internet or the Connect Server and other devices. For example, the Server can remember the location of the device, and track the fire and battery history collected from the device, along with time stamps. This history could then be displayed in a time series when the tester logs into the website and views the device attributes and how the device has performed over time.
The first step in a product design is to decide what information is important to the end customer. For our smoke detector, we want a text message alert that smoke is detected in a specific location in the house. We also want to know if the battery is low in advance of the 2AM chirping sound. On this smoke detector, the alarm is a digital signal that you connect to the general purpose I/O on the RF module. Then you connect the battery level to the RF Module’s analog inputs (Figure 5, below).
Figure 5. Arrayent RF Module is connected to the smoke detector's alarm signal and battery voltage.
After making the physical connections between the smoke detector and the RF module, you are ready to move to the web application side. First you specify a “device type” for your product and set up a database to store information about your product features. You will log into the Configurator Application, which is a web site to configure your connected application. Here, you will “Add New Type,” which is the smoke detector, and set its display name, as shown in Figure 6 below .
Figure 6. Specifying your device type using the Arrayent DevKit Configurator
Then, you will use the “Add New Attribute” window to add basic information about the device and set up the kind of data you would like to collect. Here, these attributes will include smoke, battery level, battery level time series, location, and an alarm email address (Figure 7 below ).
Figure 7. Specifying your device attributes using the Arrayent DevKit Configurator
Now that the work of getting the physical device connected and defined on the server is done, you are ready to try it out! In lieu of developing your own web application, Arrayent also provides a Utility Application, which lets you test how the product will work. This tool is pre-built by Arrayent so you do not have to develop a web application from scratch just to test your prototype. The Utility Application is the DevKit’s user interface, where you can log in to view and control the smoke detector, much like the end user of a real product would.
Log into the Utility Application (Figure 8, below ) and register your smoke detector. Since there would be more than one smoke detector in the home, you could also add a description, like Guest Bedroom, to help you track your device.
Figure 8. The Arrayent Utility application is used to implement an end user login page.
Then, using the attributes you have set up in the Configurator Application (Figure 9 below ), you can view and control your smoke detector. Here, we see for the Guest Bedroom smoke detector, there are fields to monitor the current state and to control the Smoke status, Battery Voltage, and Battery Voltage History fields.
Figure 9. Arrayent Utility application view of smoke detector status.
In the Utility Application, you can also change some of these attributes, such as renaming the device or adding an email address for alerts. You can also set up your smoke detector so that you will get an email or SMS message when the battery is low, giving you the opportunity to put in a fresh battery before the alarm starts beeping at 2 AM.
Behind the scenes, the DevKit Configurator and the Utility applications make use of Arrayent’s patent pending Virtualized Web Services technology, offering two key benefits. The first benefit is reducing product BOM cost.
As mentioned earlier, the classic Internet connect design pattern places a web application server in the end product. A web application server runs on Linux, 32-bit processors, and the memory to support it. That hardware is too expensive for most consumer applications, certainly a smoke detector. Arrayent’s virtualized web services places the product’s web application server into low cost servers Internet cloud. The end product can be powered by low cost MCUs with small memory footprint.
The second advantage is that most embedded system designers do not program at the web services abstraction level, and web application developers do not program at the embedded system abstraction level. With Arrayent’s virtualization technology, a web server application developer writes code controlling the smoke detector at the web services level (XML and HTTP). This architecture enables web applications developers to be productive and efficient without the need for additional embedded systems developers.
If you would like to take your testing to the next level, you could create your own product website with the sample PHP code included in the DevKit. This includes a basic consumer-facing interface, so you can demonstrate how a product’s website would look and function very quickly (Figure 10 below ).
Figure 10. Internet connected smoke detector status viewed on web browser user interface created by modifying DevKit sample PHP code.
Product future-proofing comes with this architecture, because product functionality is implemented as a web applications located on Internet cloud-based servers and not on the device itself. Arrayent Connect Servers are designed to scale; they are built using a communication switch-like architecture so the likelihood of downtimes or server chokepoint limitations due to SQL calls and open TCP sessions is minimized. The servers themselves are redundant within a co-location, and backed up with geographically separated co-locations to ensure reliable operation.
As smartphone and tablets become more integrated into our lifestyles, consumers will want the increased control and comfort Internet-connected devices will bring to their lives. Remote control enables customer installers to deliver faster customer service cheaper (i.e. save rolling a service truck) or give people comfort (turn on the house AC when coming home from work.)
Consumer peace of mind drives remote monitoring applications; consumers can answer “is my house is secure?” or “is Johnny home?” High product costs, along with challenging and costly product installations, have been major inhibitors in the past. With the advent of low cost wireless RF LANs and cloud computing technologies, these inhibitors are falling away. Opportunities are now emerging to reach beyond the hobbyist market and realize large-scale consumer adoption.
1) Picking the Right Technologies for Your Home Network Design. M. Mangai, N. Omar. Embedded.com, November 10, 2009.
2) Embedded Systems Meet the Cloud, M. Riley, Dr. Dobbs.com, June 28, 2010.
Harshy Wanigasekara is Application Architect at Arrayent, Inc.. He has over 15 years design and engineering management experience in human interface systems, distributed fault-tolerant systems, and embedded real-time systems. Prior to Arrayent, Harshy worked at Omneon Inc., C-Cube Microsystems (now LSI), and Philips Electronics Research. He holds a B.S. in Electrical Engineering from Columbia University, and an M.S. in Computer Science from Polytechnic University in New York