Designing for highly-compatible Internet Of Things

Article

Smart Home and Internet Of Things devices need to be designed for compatibility and security before they become popular

How to bring true interoperability to the Internet of Things | Network World

My Comments

Increasingly, the concept of the “smart home” or Internet Of Things is becoming very real. Here, we are seeing a lot more consumer-electronics devices, home appliances and similar devices become connected to the home network and the Internet.

The “app-cessory” approach to network-controlled devices, where the only way to control these devices via your home network is through a manufacturer-supplied mobile-platform app, has now had its day. This typically asked that the device to be connected to your iOS or Android smartphone or tablet using one of three paths: a Bluetooth connection to the mobile device in the same vein as a Bluetooth headset; a Wi-Fi network created by the device that is controlled by the mobile-platform device; or the home network’s Wi-Fi segment.

The trend that is affecting these devices is to interlink them with a platform-based voice-driven “home assistant” of the Amazon Alexa or Google Home ilk. Here, the requirement is for the manufacturer to provide a “skill” or something similar to the “home-assistant” platform so that Alexa, for example, can interact with the device.

But the article is now highlighting the requirement for increased compatibility with the Internet Of Things. This is where the same device can operate across a range of different network setups and operating platforms.

Use of highly-capable hardware interfaces at the media-connection level

A direction that has assured “out-of-the-box” interoperability for regular-class and mobile-class computer devices along with an increasing number of consumer-electronics devices is to implement one or more multi-mode front-ends when handling the different interface types.

In the case of radio, it can mean being able to handle Wi-Fi, Bluetooth, Zigbee or similar technologies concurrently.With the wired networks, it would be about working with different media protocols over the same kind of wire, being Cat5 unshielded twisted pair, TV-antenna coaxial cable, AC wires used to power your appliances or traditional telephone wires.

Devolo Home Control Central unit connected to router

In the case of a wireless connection, this is represented by the use of Bluetooth for peripheral-class device connection and Wi-Fi wireless networking to the latest standard for connecting to the home network and the Internet. Smartphones and some tablets will also implement a mobile-broadband modem that works across recent cellular mobile-telephony standards as well. As well, some consumer-electronics devices may implement a multifunction radio front-end that supports Zigbee or Z-Wave, typically to provide support for an RF-based remote control.

There are a significant number of “smart-home” or “Internet Of Things” devices that are designed to work solely with Bluetooth, Zigbee or Z-Wave. Examples of these range from temperature sensors, smart locks and movement sensors. These devices, typically battery-operated devices, use one of these technologies because of the fact that they are very thrifty on battery power thus allowing them to work on up to 3 AA Duracells or a 3V “pill-size” battery for months at an end or to work only on “harvested” power like kinetic energy.

But, if they want to liaise with your home network and the Internet, they have to deal with a gateway device that links between them and the home network. It is because, at the time of writing, no-one has effectively brought a Wi-Fi-capable single-mode or multimode radio front-end chipset that permits a battery-operated device to work in a power-efficient manner.

But another approach being called for is to have an Internet gateway device i.e. a home or small-business router being equipped with support for Bluetooth, Zigbee and / or Z-Wave along with Wi-Fi and Cat5 Ethernet for the home network. To the same extent, a Wi-Fi infrastructure device like an access point or range extender could simply be a bridge between other radio-network types like Zigbee or Bluetooth and the home network facilitated by the Wi-Fi or wired home-network connection.

Some manufacturers even have an “IoT hub” or gateway that links their Bluetooth, Zigbee or Z-Wave devices to your home network via an Ethernet connection. Here, this is offered as part of enabling their devices for online control via a Web dashboard or mobile-platform app. The current situation with most of these hubs is that they have the online-service hub that works with the manufacturer’s device.

There needs to be the ability to facilitate setups involving multiple gateways that link the home network with Zigbee or similar “IoT” radio segments. This is a reality with most of these devices being limited in their radio coverage in order to conserve battery power because they are expected to run on a commodity battery supply like two or three AA Duracells for months at a time or, in some cases, work on harvested electrical energy. You may find that having one of the gateways located near an IoT endpoint device like a smart lock may assure reliable connected operation from that device.

In these setups, there needs to be the ability to see a collection of these “IoT-specific” radio segments as one logical segment, along with the ability to discover and enumerate each device no matter which gateway or bridge device it is connected to and what kind of networks is used as the backbone.

Flexible software to the application level

To provide extended monitoring and control to the Kwikset Kevo deadbolt, you have to use a Bluetooth bridge supplied by Kwikset

Another issue raised regarding the Internet Of Things is compatibility across multiple software platforms and protocols.

A design practice that has been known to be successful was for recent network-connected home-AV equipment like Wi-Fi wireless speakers to support Apple AirPlay, Google Chromecast and DLNA “out of the box”. Here, you could stream content to these devices using most computer devices, whether it be your iPhone, Android tablet or Windows computer, or whether it is hosted on your NAS device.

Here, the goal is for a device to support many different software platforms, frameworks and protocols that are needed to do its job. To the same extent, it could be feasible for a device to work with different cloud services like Google Home, Amazon Alexa or IFTTT. What this can mean is that a device can work with different control and display surfaces from different manufacturers. It also means that the data that a piece of equipment shares is set in a known standard so that any software developer working on an IoT project can make use of this data in their code.

For example, the Open Connectivity Foundation’s standards which include the UPnP standards and are supported by the “open-frame” computing community, along with the Apple HomeKit framework will be required to be supported by network-connected devices.

Here, it will be about identifying every one of the standards supported by the physical medium that the IoT device uses to link with other devices and the network. Then implementing all of the current standards supported by that medium in a vendor-agnostic manner.

Secure by design

An issue that has been raised recently is the issue of data security practices implemented by the software that runs Internet-Of-Things and dedicated-purpose devices. Situations that have come to the fore include the Mirai botnet that scoped in network videosurveillance cameras and home-network routers to perform distributed denial-of-service attacks against online resources like the Krebs On Security Website and the DNS records held by Dyn, a dynamic-DNS provider, affecting a large number of Internet household names.

Here, the issue being called out is designing the software in this class of device for security along with a continual software-maintenance cycle. But it also includes the implementation of secure-software-execution practices not uncommon with the latest desktop and mobile operating systems. This includes secure-boot, trusted-execution and sandboxing to prevent unwanted code from running along with data-in-transit protection and authentication at the network level.

The concept of a continual software-maintenance approach where the firmware and other software associated with the Internet Of Things is always updated with these updates installed “in the field” as they are available, allows for the removal of software bugs and security exploits as they become known. It also allows the software to be “tuned” for best performance and manufacturers can even roll out newer functionality for their devices.

In some cases, it could even lead to a device being compatible with newer and revised standards and protocols rather than seeing one that ends up being limited because it doesn’t support the newer better protocol. But there can be the question about this kind of software update being used as a way to enforce unpopular device-design requirements upon an existing installed base of devices and changes how they operate. This could be brought about by a government mandate or an industry expectation, such as an eco-requirement for HVAC equipment required by a state energy-conservation department or a digital-rights-management expectation required at the behest of Hollywood.

To make the IoT hardware and software ecosystem work properly, there needs to be an underscored requirement for compatibility with prior and newer devices along with the ability to work securely and with properly-maintained software.