【专家观点】zigbee技术如何构建兼容性平台实现产品互操作

zigbee是目前国际开放物联网标准中唯一涵盖完整应用层的低功耗无线局域网协议。zigbee联盟自诞生以来，一直将产品的互操作性作为物联网标准的首要目标。随着物联网技术与应用的普及，zigbee标准得以持续性进化。

今天我们来听听zigbee中国成员组技术专家是如何理解zigbee产品的互操作性，不同的智能产品是怎么样在一起的。【本文作者：徐利明 （德州仪器半导体技术(上海)有限公司无线产品部、zigbee中国成员组技术专家）；张宇宁(飞利浦照明(中国)投资有限公司标准与法规部、 zigbee中国成员组技术专家）；寇宏（中国电子技术标准化研究院物联网中心、zigbee中国成员组技术专家）】

一、zigbee标准、测试与认证保障了产品的互操作性

众所周知，应用层协议是终端产品互操作的基础。Zigbee技术对应用层的标准化基于功能定义，即cluster，然后根据cluster进一步规范设备类型(devicetype)。也就是说，先有cluster再有device type，而不是相反。这也是为什么Zigbee的库称为Zigbee Cluster Library而非Zigbee Device Library。ZCL是一部工具书，罗列了所有Zigbee已定义的功能。

Zigbee认证项目保证了产品具备其预期功能，而且不同生产商的产品可以互操作。产品认证同样也是联盟标准开发过程的关键组成部分。与其他标准制定组织不同，Zigbee的标准只有当有产品通过测试认证程序后才会被发布。Zigbee认证过程使生产商能够为客户提拱各种各样便于操控的Zigbee产品。我们对于产品标准符合性和可互操作性的高度关注，保证大家能获取功能可靠的产品，从而带来愉悦的用户体验。

认证类型

认证程序在两个领域保证产品符合zigbee技术标准，且不同设备间可互操作。

zigbee兼容平台

zigbee兼容平台认证程序保证一个平台要经过严格评估才能应用到zigbee产品上。平台一般由一个2.4GHz的无线发射器和一个带zigbee固件的微处理器组成，并通过测试程序来证明其符合zigbee技术标准，保证了用于个人和商业的终端产品生产有可靠的平台供应来源。联盟成员的平台成功完成测试后，联盟会给予其zigbee兼容平台的认证资格。

zigbee认证产品

zigbee产品认证程序能对任何应用zigbee开发标准的产品进行认证测试。产品必须完全符合标准并成功执行所有的必测命令。产品通过测试后联盟会给予zigbee认证产品的资格，有权使用认证产品标志。

zigbee联盟不建议厂商自行开发所有的zigbee协议，而是要求采用zigbee兼容平台（zigbeecompliant platform）并专注于产品的应用开发。

zigbee测试是针对软件协议的互通性测试，主要采用Test Harness与Device Under Test (DUT)乒乓式交互的测试方法。zigbee测试着重于功能特性的方面，暂时不关注产品的物理特性。

协议实现一致性声明（PICS, Protocol Implementation Conformance Statement）是厂商的自述性文件，也是测试过程的唯一依据。

具体来说，PICS是一个文档，它罗列了zigbee标准或相关测试文档中要求的所有参数和特性，并将其按照强制或可选分成两个类型，被测设备必须无条件地满足所有强制性的功能要求。从文档组织形式上看，协议实现一致性声明的主体部分是一个格式固定的调查问卷表格，每一项的答案填进最右侧的一列里，答案或是简单地选择“是”或“否”，或是填入一些数值、集合等。

PICS是一份很详细的文档，下图仅是一个缩影。

下图是一个典型的测试环境。测试实验室的测试工具包括软件层面的ZTT (zigbee Test Tool)和硬件设备Test harness。DUT与test tool按照zigbee test spec逐条进行符合性测试，直至完成所有需要的测试例。

zigbee test乒乓操作模型

二、“互操作性”的含义与范围

从上面的描述可以看出，zigbee作为一个物联网通信标准，自标准定义到测试的方法与流程，其目标都是设备通信与行为层面的规范与互操作性，而不涉及产品本身的性能。换句话说，标准本身定义的是通信各层级（OSI7层模型或简化4层模型）的格式与规范，测试本身关注空中数据包（over-the-airpacket）的合规性。设备本身的性能差异交给厂商与市场，这也是平衡“标准化”与“差异化”的合理结果。

举例来说，下述各项属于Zigbee测试的内容，其互操作性由zigbee标准保证：

1) 设备网络层的行为，包括网络发现、加入/离开网络、交互网络参数等。

2) 设备安全性的行为，包括安全模式的支持、密钥的生成分发、密钥的动态更新等。

3) 设备功能性的行为，包括测试PICS文件中所列的所有Mandatary和Optional行为。

下述各项不属于Zigbee测试的内容，亦不属于zigbee所保证的产品互操作的范围：

1) 功能参数在产品表达上的一致性。比如同一亮度和颜色参数在不同产品的光学表达不一致（色差）。

2) 命令在执行上的细微差异。比如照明设备执行“OFF”命令时从亮到灭的时间不一致（有快有慢）。

3) 设备RF性能上的差异。比如不同公司的产品在网络中的性能表现不一致、不同的产品具有不同的信号强度和有效传输距离。

4) 设备自身的性能和稳定性。比如有些产品可以长时间稳定地存在于网络中，有些产品有更高的断网概率。

产品性能的一致性并非zigbee联盟的诉求，也不应当是一项物联网通信标准的责任。工业界在追求互联互通的技术标准的同时，亦需要足够的空间追求产品的差异化与附加值。

除了上述的“非互操作”例子之外，市场上还有下面两种“不能互操作”的情况：

zigbee标准给产品提供了足够的灵活性。产品可以实现”optional cluster”，如果设备双方一方实现某个可选项而另一方没有实现，这将导致针对这个功能的不能互操作。令人迷惑的是，消费者从产品上看到的设备类型是一致的。

生产厂商在zigbee的方式之外，增加了额外的组网限制，比如需要特定的合作伙伴的产品才可以组网（你有一百种方法使得可以互操作的设备不能互操作）。这并非联盟鼓励的实现方式，但在物联网市场上特别是生态系统中并不罕见。

三、一个例子——从一个灯的“On/Off”看设备双方的交互

前面我们主要介绍了在zigbee如何定义标准与测试规范，尤其在应用层互操作上的测试和认证，以保证不同厂家之间的产品在经过认证后，具有天然的互联互通性。

但是对于很多开发者来说，仍然对不同厂家之间的zigbee产品能够进行互通互联存在很大的疑问。下面我们以一个实际的产品功能为例，进一步阐述zigbee协议如何保证产品的互通互联性。

假设A厂家开发一款On/Off功能的Switch，B厂家开发一款On/Off功能的Light，A和B都在遵循zigbee协议规范的基础上进行开发。他们的产品能否实现互通互联？本文主要讨论跟互操作相关的应用层面开发。这里我们结合德州仪器(TI)的Zigbee芯片CC2530/CC2630[1]以及TI的Zigbee3.0协议栈Z-Stack3.0[2]进行开发演示(请知悉，这对所有的zigbee compliant platform均适用)，让大家在了解zigbee协议的同时也学会zigbee产品的开发。

首先我们来看zigbee协议里面是怎样定义这两个产品的。这涉及两个文档，一个是Lighting Occupancy Device Specification[3], 另外一个是zigbee Cluster Library Specification[4].

在文档[3]中这两个产品的定义如下：

他们有各自的Device ID，当我们拿到Device ID是0x0100的设备时，我们就知道它是一个On/off Light。不同的物理设备之间可以用二进制数据交流了，这本身就是实现互操作的基础，后面会更加精彩。在TI的Z-Stack3.0协议栈里面我们看到对DeviceID的定义也是如此，spec与stack一致（这是显然的！）。

直接使用定义好的变量对需要开发的设备进行描述。

不同的物理设备之间仅靠Device ID肯定是不够的，我们再来看这些设备各自的功能定义。文档[3]中对On/off Light和On/off Switch在功能定义如下：

每个设备类型定义了一些Cluster，每个cluster有client和server之分，有些cluster是强制支持，有些cluster是选择性支持。Cluster可以理解成是关于某个功能的一组属性和命令的集合，也是两个设备之间的通信接口。cluster上的server和client，可以理解成输入Cluster和输出Cluster。

比方说On/off Light需要支持On/off cluster的server端，也就是输入端，对于一个On/off Light来说是接收“开灯”命令，也就是输入命令。与之相对应的On/Off Switch需要支持On/off cluster的client端，也就是输出端，即发送“开灯”命令。严格地讲，通信双方是在同一个cluster ID的client端和server端之间进行的。

我们同样可以找到TI Z-Stack 3.0协议栈中对cluster ID的定义如下图所示，

然后按照规范中对On/off Light和On/off Light Switch设备需要支持的cluster ID要求，TIZ-Stack 3.0协议栈的软件实现如下，

那么有这样的定义以后On/off Switch 是否一定可以控制On/Off Light了呢？答案是：还差一步！原因在于On/off Switch发送的“开灯”命令，On/off Light收到以后怎么知道这个是“开灯”而不是“关灯”命令呢，这时候我们需要回去看Cluster是如何进一步定义某个功能的属性和命令。我们看下On/off cluster 下的属性和命令是怎么定义的呢?

在文档zigbee Cluster Library Specification [4], 我们找到了对On/off cluster的相关定义如下所示：

这个文档中主要是对每个Cluster下面的属性(Attribute)和命令(Command)相关操作进行了详细的定义。请记住，ZCL是一部工具书，其罗列了所有Zigbee已定义的功能。

首先我们来看属性Attribute，一个cluster下面有一个或者多个attribute值，它主要反映物理数量或状态的数据值，比如灯的状态值(On/Off)、温度值等等。在Zigbee协议里面大部分的attribute值都是维护在server端，也有很少部分attribute在client上维护。比方说On/Off Light的On/Off的状态值开或者关，是在On/Off Light上面维护，这个容易理解。我们找到0x0006On/off cluster 下面的attribute。

OnOff attribute是一个布尔型参数，0表示关，1表示开。

每一个attribute值都有特定的ID号，名字，变量类型，数值范围，操作权限，默认值以及是强制支持还是可选。TI协议栈中对Attribute ID的定义如下所示。

这样我们可以通过Cluster ID+Attribute ID知道需要操作的具体是哪个属性，具体含义是什么。以上面这个On/off Cluster下的OnOff attribute为例，显然这个attribute是在server端维护的，所以在TI Z-Stack3.0协议栈On/off Light设备中看到了这个定义如下：

其次我们再来看文档zigbee Cluster Library Specification [4]对cluster里面对命令相关操作的定义如下所示：

每一个命令都有特定的Command ID, 也就是意味着Cluster ID+Command ID的方式就可以知道具体操作的是哪个cluster下面哪个command。在TI Z-Stack 3.0协议栈中对On/off cluster相关的Command ID定义如下（一如既往与spec保持一致）

比较容易理解，对于On/off Switch来说就是发送命令，On/off Light就是接收命令。协议栈中对于发送命令和接收命令都已经实现，如下所示，详细描述了On/off Switch如何调用现成API发送命令，在On/off Light上面接收命令，利用现成的回调函数让开发者收到命令后操作实际的硬件设备，比如通过PWM控制把灯打开。

到此为止我们在理论上说明了A厂家按照zigbee规范开发的On/off功能的Switch可以控制B厂家按照zigbee规范开发的On/off功能的Light了，也就是实现了互操作。至此，所有的cluster, attribute, command及各种ID, value都完美地匹配了，不是吗？

但是也许还有人持有怀疑态度。为了证明我们之前的分析都是正确的（其实无需证明），我们使用基于TICC2530/CC2630芯片的zigbee设备进行实际测试，并通过空中交互的数据报文进行进一步验证。由于本文主要讨论Zigbee互操作性，此处省略zigbee设备的网络创建，加网操作，直接让On/off Switch发送相关命令给On/Off Light。该实例中发送了off命令和on命令，通过Ubiqua[5]抓包软件，获取空中的数据包如下：

我们挑选其中的几个数据包进行详细的解释。