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