When I first heard about object-oriented programming as a software engineer developing embedded firmware for T&M systems, I was intrigued. How efficient would it be to have a single piece of firmware that could run on every type of hardware that we were creating?
Obviously there were some differences between the hardware capabilities of, say, a PCI bus communication card and a serial port. But fundamentally they needed to be configured, devices discovered, commands sent, and data read. By creating an overall framework that configured each device in a consistent way, system engineers could realize a greatly simplified and streamlined application development process.
You can make most of these devices look and behave like each other, but it’s really hard to do in an efficient way that takes advantage of each interface’s unique capabilities. How can you build an interface that supports bursting only on those buses that could take advantage of it? If the goal is to provide a portable API across these interfaces, how portable is it when I have a bunch of device-specific cases that I need to handle to make the process efficient?
Too Many Standards
I see a similar situation for wireless networking software and MACs. Developers face a bewildering number of wireless networks, communication links, and protocols based on myriad standards such as Wi-Fi, Bluetooth, ZigBee, Z-Wave, 6LoWPAN, EnOcean, Dust, ANT, io-homecontrol, M-Bus and KNX, and WirelessHART—plus proprietary solutions.
Wouldn’t it be great to replace them all with a single communication layer that could cover all the applications, simplifying the design of wireless networks? You also would achieve instant interoperability among applications and built-in bridging between networks. In the end, these unified efforts are extremely difficult to achieve because the customer applications have such varying requirements and needs.
In home security systems, range is key, as each wireless door sensor needs to reach the control panel. Battery life is critical, so low power consumption, short packets, and low duty cycle are important. System cost is critical, too, so the memory footprint of the network is another consideration. But for most sensor nodes, data rate is not a key parameter unless you have a wireless camera running on its own network.
Nearly all the sensor nodes in a security system are battery-powered, but the main panel is normally line-powered. Thus, a protocol that enables the panel to constantly listen for incoming packets from the sensors is a viable solution. In addition, home security systems tend to be closed systems. These requirements drive a data packet structure and a network communications protocol optimized for customer needs, as well as a lightweight network protocol (which is often proprietary) optimized for short packets.
The requirements for home security are very different than, say, the requirements of a high-bandwidth wireless household data network. High data rates (for applications such as streaming video), larger batteries or wall-powered end devices, vendor interoperability, and global deployment are requirements that place Wi-Fi in a strong position in the home.
But given the need for low-cost, battery-powered, low-data-rate applications for many household control networks, other wireless networks likely will coexist with Wi-Fi. So what do all these options and choices mean for wireless designers seeking to make decisions for their networking solutions?
Continue on next page
What’s Next
We’re likely to continue to live in a wireless world populated by numerous communication networks (both standard and proprietary) that have evolved to be optimized for their particular application. Many engineers will continue to work with several different solutions to address all their system needs.
For many applications that require squeezing every ounce of battery life or performance out of components, proprietary solutions will likely continue to dominate. IP networks based on 6LoWPAN are gaining traction in many areas due to the desire to get data from wireless nodes onto the Web. In the metering market, neighborhood-area networks and meter-to-meter communications are getting pressure to migrate to standards-based networks from governments and utilities.
Bridges in many networks will be required to consolidate all the data pipes between devices: a wireless access point in your house has Wi-Fi, Ethernet, and possibly powerline communications (PLC). The smart meter may have a sub-gigahertz node along with a ZigBee PHY and PLC PHY. Your home security system probably has a proprietary network along with Ethernet and possibly Wi-Fi to connect to the Web.
Suppliers, designers, and end users will continue to live in a multi-protocol wireless world, mixing and matching standard and proprietary solutions driven by our critical customer and application requirements. One size doesn’t fit all, and we will continue to see a polyglot of protocols.