BY DANIEL MONETA, Marketing Work Group Chair, zigbee alliance and EVP Corporate Development
MMB Networks
www.mmbnetworks.com ,
and CAM WILLIAMS, Strategy Committee Chair, zigbee alliance and Lead Architect of IoT Connectivity
Schneider Electric
www.schneider-electric.com
Designers looking to create a successful IoT device need to be sure that their system will be interoperable with other devices and systems, both old and new. Standards such as zigbee have helped to ensure this with interoperability implemented at each level of the solution.
This article will discuss the importance of interoperability, using zigbee as an example of what to look for in an interoperable device ecosystem. It will then discuss how zigbee has evolved before introducing dotdot and demonstrate how it will help developers who are looking for an interface-agnostic means of communicating between devices and systems.
The why and how of device interoperability
The IoT requires device interoperability so that consumers don’t have to worry if one device will talk with another, so manufacturers have future-proof technology investments, and application developers can imagine and design apps for the largest possible ecosystem of compatible devices.
Product designers and manufacturers can achieve interoperability in several ways:
• Interoperability through unification
• Interoperability through backward and forward compatibility
• Interoperability through full-stack specifications
• Interoperability through over-the-air updates
• Interoperability through testing and certification
• Interoperability through commissioning
Interoperability through unification
The zigbee alliance achieves interoperability through unification: Its legacy application profiles — ZigBee Light Link (ZLL), ZigBee Home Automation (ZHA), ZigBee Building Automation (ZBA), and ZigBee Retail Services (ZRS) — address distinct use cases within a specific market vertical. In 2016, it unified these profiles under ZigBee 3.0, now commonly simply called “zigbee.” There are no special flavors of the zigbee standard applicable in a specific market segment; there is one single specification applicable across market segments.
Interoperability through backward and forward compatibility
Leveraging backward and forward compatibility, end users can upgrade and migrate their smart systems in an evolutionary and modular way to ensure that existing devices and systems are viable for future use, even as technology evolves.
For example, the forward and backward compatibility between zigbee-certified products and products certified under the legacy profiles ZigBee Light Link (ZLL) and ZigBee Home Automation (ZHA) are dependent on the type of network construction (either distributed or centralized) and the type of commissioning (classical EZ-Mode, TouchLink, or install codes) (Fig. 1 ). In particular:
• A ZigBee Light Link device can join a distributed zigbee network using either classical EZ-Mode or TouchLink commissioning (if supported by the network).
• A ZigBee Light Link device can join a centralized zigbee network that does not require install codes.
• A ZigBee Home Automation device can join a zigbee centralized network that does not require install codes.
• A zigbee device can join either a ZigBee Light Link or a ZigBee Home Automation network using classical EZ-Mode commissioning.
• A zigbee device can join a ZigBee Light Link network using TouchLink commissioning.
• A zigbee device can join a zigbee network with any deployed security policy.
• A zigbee device cannot join a ZigBee Home Automation network using TouchLink commissioning.
• A ZigBee Home Automation device cannot join a zigbee distributed network.
Fig. 1: Forward and backward compatibility between zigbee-certified products and products certified under the legacy profiles ZigBee Light Link (ZLL) and ZigBee Home Automation (ZHA) are dependent on the type of network construction.
Interoperability through full-stack specifications
zigbee defines what a fully interoperable product looks like, from the physical layer to the network layer to the application layer. It requires use of the IEEE 802.15.4 physical (PHY) and MAC layer standard, for which devices are widely available (Fig. 2 ).
Fig. 2: zigbee requires use of the 802.15.4 PHY and MAC, uses ZigBee PRO for mesh networking, and has introduced a Base Device Behavior to let products recognize networks and their requirements and join them.
New in zigbee (ZigBee 3.0) is the definition of a Base Device Behavior. It is this Base Device Behavior that lets zigbee products identify available networks, recognize network requirements, adapt to these requirements, and join them. Above the Base Device Behavior, zigbee leverages the same set of functional objects that were developed in support of the legacy profiles and used in millions of deployed products worldwide: the ZigBee Cluster Library (ZCL).
To be certified, a device must pass a series of interoperability test events using multiple independent implementations.
Interoperability through over-the-air updates
It is important that developers have a means to provide a remote firmware upgrade, especially as the IoT implies the deployment of thousands of devices. Manual updates are not an option. Look for a robust means for remote over-the air (OTA) system software upgrades using secure wireless transfer of encrypted code images. Often times, techniques can be used to enhance product functionality and operational features and provide fixes for particular interoperability issues.
Interoperability through testing and certification
Interoperability is greatly helped by a program that is clearly defined, repeatable, and independent. zigbee-certified products have had their underlying platforms, Base Device Behavior, and application-level objects (from the ZCL) tested and validated to conform to the requirements of the various standard documents.
Interoperability through commissioning
Commissioning is the process of configuring devices onto the network so that they can communicate with each other. A new device needs to be able to securely join the network and establish control relationships with other devices on the same network. In order for a device to be commissioned, it must pass the necessary security credentials to the network where they are checked for validity, thus permitting the device to be authorized to operate on the network.
zigbee defines how a device can join a network and exchange its initial security credentials with unique and secure Trust Center link keys. The initial security credentials of a device can be incorporated into the network through out-of-band mechanisms such as QR codes or an NFC tag (not defined in the standard). In addition, other commissioning mechanisms — such as the use of a commissioning tool with a rich user interface — can also be used.
Interoperability through future roadmap — dotdot
All of the above makes zigbee devices interoperable amongst themselves, and this interoperability has driven many multi-vendor ecosystems. However, most IoT devices on other networks don’t do this, even amongst devices that use the same wireless technology. The result is an IoT that is often a patchwork of translations done in the cloud, adding complexity and reducing reliability for users. This undermines technology investment, as mentioned, and puts the onus upon platform and app developers to maintain a growing set of unique interfaces to each vendor’s products. This limits the scale and innovation potential of the IoT.
Solving this interoperability problem is the purpose and role of dotdot. With dotdot, the zigbee alliance has taken the language that is the interoperability layer at the heart of zigbee and developed a program around it to extend dotdot to other networks to let IoT devices communicate, regardless of their underlying interface (Fig. 3 ).
Fig. 3: dotdot encapsulates zigbee’s interoperability layer such that it can sit on top of any network and allow any IoT device to connect and communicate.
The core of the dotdot language is the zigbee interoperability layer, but without the protocol. A layer comprises a protocol, interface, and service (the action that the layer performs). The dotdot language is agnostic to underlying networks and protocol message structure, so it defines only the interface and the action. Hence, it is an interaction model, defining the behavior and interaction between devices.
For each qualified network, a dotdot specification will also standardize or recommend protocols to complete the application layer. For example, a dotdot device on a zigbee network uses standard ZCL APS messages (and defines the format). A dotdot device on an IP network uses standard ZCLIP URI messages.
The elements that make up dotdot are node, device, cluster, attribute, and command. A node is basically a radio, or addressable physical location. A device is an addressable endpoint. It is something that performs some well-defined function for an application. Some functions are very visible to the user: light, switch, door lock, shutter, fan, thermostat, etc. Other devices perform functions that are not so obvious or are a combination of many logical devices — like a temperature, CO2 , and humidity sensor, which shares a single node address on a network but is addressable as separate device endpoints. A cluster is an object. A device or cluster may also be a virtual.
It is the device specification that defines conformance. A Device ID defines the mandatory object components that make up the device. Some are application objects that perform the actual application function; others are utility objects that support functions like over-the-air upgrade, discovery, scenes, commissioning, binding, security, group addressing, and other common utility functions. Domain and market experts decide what the minimum mandatory feature (object) set for a device with a particular Device ID is.
The zigbee alliance is collaborating with other standards groups, such as the Thread Group, to bring dotdot to multiple IP networks and connectivity technologies. Thread was a natural fit as both zigbee and Thread use the same underlying IEEE 802.15.4 radio technology and share a large number of members. Over a dozen companies already showcased early demonstrations of dotdot products in both the zigbee alliance and the Thread Group booths at CES 2017, and the first dotdot-certified products are expected in late 2017. As dotdot-certified devices start rolling out, it will also be a user-facing interoperability mark for an open ecosystem not controlled by any single ecosystem vendor.
For designers, the best way to get started on dotdot is to start building zigbee products because dotdot is built on zigbee’s application layer and zigbee is a part of the dotdot family.
Advertisement
