-
-
手机阅读
[转载]如何在创建ZigBee应用时做出正确的选择
图片：
图片：
低功耗、低成本的ZigBee无线网络标准使得把无线通信功能嵌入到日用家电成为可能。它的支持者宣称，该标准将在家庭和楼宇自动化、节能甚至国土安全领域开拓丰富的新市场。
尽管ZigBee v1.0版规范已经得到最终批准，但对于打算进入这个市场的公司来说，该协议不是能以一种规格适应所有应用的“万能药”。在其最基础层，ZigBee确保了与其它符合标准的产品的互操作性。而与ZigBee的潜在应用非常之广一样，开发人员必须权衡的问题也非常之多，包括更深层的应用、架构和平台等。
ZigBee标准提供了网络、安全和应用支持服务，这些服务工作在IEEE 802.15.4媒体存取控制(MAC)和物理层(PHY)无线标准之上。它采用了一整套技术来实现可扩展、自组织、自恢复的网络，这种网络可以管理各种各样的数据传输模式(见图1)。
图1（见附件1）：ZigBee标准提供了在MAC和PHY层之上的网络、安全和应用支持服务。
尽管ZigBee常常被默认为无线网格网络，但该标准实际上支持多种网络拓扑，包括星型、簇树型(cluster tree)或星/网格混合型网络(见图2)。因此，开发人员首先要考虑的是“哪种网络结构最适合我的应用需要？”
如果数据可靠性是关键要求，那么网格网络架构针对固有的不可知缺陷提供了最佳防护，这些缺陷有可能导致任何无线环境(例如存在RF衰减、电磁干扰和多径信号的情况)中的信号质量下降。通过把ZigBee接收器和发射器放得更加靠近，所有这三种条件的负面效果将会减轻。网格网络的冗余通道会确保提供替代的数据通道，从而避免单节点故障。
其它应用也许需要ZigBee路由器来扩展网络的工作范围，其中路由器将充当因为相距太远而不能直接通信的节点之间的中继器。此外，这种部署方案可能依赖于电池供电的路由器，所以需要相当数量的“睡眠”时间以增加它们的使用寿命。例如，在一个农作物监视网络或者类似的农业应用中，簇树型结构也许是最好的选择。它可以把多个子网络汇聚成一个长距离的ZigBee广域网。在这个广域网中，低数据率的通信流沿着树进行传输，而只有当需要发送或接收适当子网之间的数据时才唤醒电池供电的路由器。反之，一些较短距离的应用更适合采用星型拓扑，因为它可以免除网格网络的路由通信负担。
互操作性
尽管ZigBee是一个开放标准，但它也赋予了OEM很大的自由度，允许他们决定自己的产品应该在多大程度上向第三方供应商开放。因为ZigBee标准只定义了网络、安全和应用接口层，所以开发商可以购买整个ZigBee协议栈，包括针对特定产品的应用类(profile)，或者只许可实现基本的网络级互操作性的联网层。
在应用层，开发商必须决定是采用公共的应用类还是开发自己专有的类。ZigBee v1.0已经为照明应用定义了基本的公共类，并正在制定针对HVAC、工业传感器和其它传感器的应用类。任何公司都可以设计与支持公共类的产品相兼容的产品。例如，一个采用公共ZigBee照明类的荧光灯镇流器供应商可以与采用相同类的第三方灯开关调光器实现互操作。开发人员可以对该公共类加入他们自己的看法和感觉。ZigBee设备采用应用对象进行建模，这些应用对象通过交换类对象和它们的属性实现与其它设备的通信。
尽管这看起来同ZigBee的开放精神相矛盾，但一些OEM也会开发不在应用层提供互操作性的产品。开发商可以设计专有的应用类，以创造只有单一供应商的设备，或者选择第三方设备。ZigBee定义了一个抽象接口，而平台供应商提供了应用编程接口(API)，该API定义了应用如何被集成到ZigBee协议栈的规则。一个专有的ZigBee系统仍然可以在网络层上受益于第三方产品制造商。ZigBee底层栈的互操作性提供了数据路由、媒体存取控制、网络形成及维护、设备和服务发现等功能。
数据如何进行传输是开发人员考虑的另一个关键因素，因为ZigBee没有定义传输层。开发人员必须决定到底是自己创建传输机制，还是使用一个带有内置传输层的ZigBee芯片来创建他们的应用。例如，Ember公司连同ZigBee协议栈一道提供了一个传输层，这有助于简化应用开发过程并确保可靠的端到端消息传递。该传输层提供了开发人员可以据此定义专有ZigBee类的框架。
安全性
大部分ZigBee解决方案将需要某种级别的安全性。ZigBee提供了一套基于128位AES算法的安全类和软件，并集成了802.15.4的安全元素。ZigBee协议栈类为MAC、网络和应用层定义了安全性。它的安全服务包括针对关键进程建立和传输、设备管理和框架保护的方法。
如果开发人员选择使用一个公共的ZigBee类，那么就已经为其应用做出了安全决策，因为在该类中已经对安全性进行了预定义。即使开发人员打算创建一个专有类的应用，他仍可以在若干个ZigBee预定义的栈类中挑选一种安全模式。
在这个层上，开发人员需要决定这样一些问题：是否需要对数据帧的载荷进行加密，以及附着在数据帧末尾的认证码长度(8、16或64位，等等)。基本的应用也许不需要认证，因而可以受益于一个较小的数据包载荷。这些数据完整性方面的选项使得开发人员可以在消息保护和额外开销之间进行权衡。
开发人员还必须决定在哪个层上施加安全机制：在MAC层、网络层还是应用层。如果应用需要尽可能强大的安全保护，那么就在应用层保护它。此处实施的安全措施采用了一个会话密钥，它只能被另一个拥有该钥匙的设备所认证和解密。这种方法既能防止内部攻击也能防止外部攻击，但需要更多的存储器来实现它。
在MAC层和网络层的安全性实质上服务于相同的目的：确保单跳传输的安全。MAC层仲裁对共享媒介的访问并控制相邻设备之间的单跳传输。ZigBee联盟添加了一个网络层安全选项以便加入在MAC层无法实现的功能，包括拒绝不能被验证的数据帧的能力。这两个安全层采用的是该网络上所有ZigBee设备都共享的全局密钥。MAC层和网络层的安全性适合需要防止对特定基础设施攻击的应用，例如防止一个非法设备恶意侵入网络。如果开发人员需要在两个设备之间建立路由，而该网络层的框架又是不安全的，那么非法设备可能会截取数据包。
图2（见附件2）：ZigBee支持多种网络拓扑，包括星型、集群树型或星/网格混合型网络。
ZigBee安全性还引入了一个“信用中心(Trust Center)”的概念，它允许设备进入网络，然后分配密钥，从而确保设备之间端到端的安全性。此处，开发人员必须根据他们的应用从两种信用中心模式之间选择一种：住宅或商用。住宅模式消耗资源少，但不建立密钥或随着网络规模而扩展。商用模式建立并维护密钥，而且具有良好的扩展性，但其代价是要消耗相当多的存储器。
平台考虑因素
ZigBee提供了一个标准化的网络和应用框架，开发人员可以在此基础上建立应用而无须担忧联网和RF问题的烦扰。然而，单靠其自身，ZigBee标准化框架不能保证产品的顺利开发。为了创建兼容ZigBee的应用，这个市场的不同供应商提供了各种各样的产品，包括RF收发器、微控制器、闪存ROM、供应商专有的协议栈和应用开发工具。因此，开发人员必须选择是用多家供应商的组件创建自己的ZigBee解决方案，还是在一个集成硬件/软件平台上建立自己的应用。由于前一种方法涉及艰难的集成工作，因此大部分开发人员将可能倾向于后一种方法。
他们必须做出的第一个决定是在芯片和联网软件层次上。最大的挑战起源于硬件和联网软件之间的复杂性和不兼容性。在开发一个新应用时发现的问题很少只局限于一个协议栈层。例如，在一个原型设计的MAC层中发现的一个故障很少能够被网络层提供商检测到并进行调试。因而，开发人员必须仔细考虑他们所选平台的集成深度。
一个ZigBee解决方案需要一个RF收发器、一个针对应用处理的微控制器或DSP和一个ZigBee网络栈。直到最近，大部分系统都是来自于多家供应商合作伙伴的多芯片、多软件解决方案。目前，新一代的全集成、单供应商平台正在进军该市场。多供应商平台有时可以提供较低的前期成本优势。但是，一个单一来源的平台虽然常常更昂贵，却可让开发人员避免由不同供应商的硬件和软件产品组成的解决方案所固有的麻烦和产品开发延迟。
开发人员还必须考虑网络栈的深度。一般来说，网络栈越深，开发工作越容易。一个提供从物理网络层、传输层直到ZigBee类的网络栈将使开发人员不必理会网络的内在工作机理，从而允许他们集中精力于应用开发上。例如，一个用混合供应商解决方案建立的ZigBee应用可能需要开发人员计算他们的应用将如何处理节点之间丢失的网络包。这类复杂的网络问题已经在单一来源、全栈平台中得到考虑。
工具的选择也可能成就或毁坏一项ZigBee开发工作。开发人员需要仔细考虑他们平台的开发环境的广度和功能。供应商提供全套的开发工具是很重要的，它应该具备多节点无线半导体、网络软件、软件工具、培训和技术支持。此外，该工具应该是一个集成环境的一部分，此集成环境具备通用接口或者是一系列独立工具的集合。最后，开发环境应该包括用于调试的充分工具。
尽管ZigBee v1.0版规范已经得到最终批准，但对于打算进入这个市场的公司来说，该协议不是能以一种规格适应所有应用的“万能药”。在其最基础层，ZigBee确保了与其它符合标准的产品的互操作性。而与ZigBee的潜在应用非常之广一样，开发人员必须权衡的问题也非常之多，包括更深层的应用、架构和平台等。
ZigBee标准提供了网络、安全和应用支持服务，这些服务工作在IEEE 802.15.4媒体存取控制(MAC)和物理层(PHY)无线标准之上。它采用了一整套技术来实现可扩展、自组织、自恢复的网络，这种网络可以管理各种各样的数据传输模式(见图1)。
图1（见附件1）：ZigBee标准提供了在MAC和PHY层之上的网络、安全和应用支持服务。
尽管ZigBee常常被默认为无线网格网络，但该标准实际上支持多种网络拓扑，包括星型、簇树型(cluster tree)或星/网格混合型网络(见图2)。因此，开发人员首先要考虑的是“哪种网络结构最适合我的应用需要？”
如果数据可靠性是关键要求，那么网格网络架构针对固有的不可知缺陷提供了最佳防护，这些缺陷有可能导致任何无线环境(例如存在RF衰减、电磁干扰和多径信号的情况)中的信号质量下降。通过把ZigBee接收器和发射器放得更加靠近，所有这三种条件的负面效果将会减轻。网格网络的冗余通道会确保提供替代的数据通道，从而避免单节点故障。
其它应用也许需要ZigBee路由器来扩展网络的工作范围，其中路由器将充当因为相距太远而不能直接通信的节点之间的中继器。此外，这种部署方案可能依赖于电池供电的路由器，所以需要相当数量的“睡眠”时间以增加它们的使用寿命。例如，在一个农作物监视网络或者类似的农业应用中，簇树型结构也许是最好的选择。它可以把多个子网络汇聚成一个长距离的ZigBee广域网。在这个广域网中，低数据率的通信流沿着树进行传输，而只有当需要发送或接收适当子网之间的数据时才唤醒电池供电的路由器。反之，一些较短距离的应用更适合采用星型拓扑，因为它可以免除网格网络的路由通信负担。
互操作性
尽管ZigBee是一个开放标准，但它也赋予了OEM很大的自由度，允许他们决定自己的产品应该在多大程度上向第三方供应商开放。因为ZigBee标准只定义了网络、安全和应用接口层，所以开发商可以购买整个ZigBee协议栈，包括针对特定产品的应用类(profile)，或者只许可实现基本的网络级互操作性的联网层。
在应用层，开发商必须决定是采用公共的应用类还是开发自己专有的类。ZigBee v1.0已经为照明应用定义了基本的公共类，并正在制定针对HVAC、工业传感器和其它传感器的应用类。任何公司都可以设计与支持公共类的产品相兼容的产品。例如，一个采用公共ZigBee照明类的荧光灯镇流器供应商可以与采用相同类的第三方灯开关调光器实现互操作。开发人员可以对该公共类加入他们自己的看法和感觉。ZigBee设备采用应用对象进行建模，这些应用对象通过交换类对象和它们的属性实现与其它设备的通信。
尽管这看起来同ZigBee的开放精神相矛盾，但一些OEM也会开发不在应用层提供互操作性的产品。开发商可以设计专有的应用类，以创造只有单一供应商的设备，或者选择第三方设备。ZigBee定义了一个抽象接口，而平台供应商提供了应用编程接口(API)，该API定义了应用如何被集成到ZigBee协议栈的规则。一个专有的ZigBee系统仍然可以在网络层上受益于第三方产品制造商。ZigBee底层栈的互操作性提供了数据路由、媒体存取控制、网络形成及维护、设备和服务发现等功能。
数据如何进行传输是开发人员考虑的另一个关键因素，因为ZigBee没有定义传输层。开发人员必须决定到底是自己创建传输机制，还是使用一个带有内置传输层的ZigBee芯片来创建他们的应用。例如，Ember公司连同ZigBee协议栈一道提供了一个传输层，这有助于简化应用开发过程并确保可靠的端到端消息传递。该传输层提供了开发人员可以据此定义专有ZigBee类的框架。
安全性
大部分ZigBee解决方案将需要某种级别的安全性。ZigBee提供了一套基于128位AES算法的安全类和软件，并集成了802.15.4的安全元素。ZigBee协议栈类为MAC、网络和应用层定义了安全性。它的安全服务包括针对关键进程建立和传输、设备管理和框架保护的方法。
如果开发人员选择使用一个公共的ZigBee类，那么就已经为其应用做出了安全决策，因为在该类中已经对安全性进行了预定义。即使开发人员打算创建一个专有类的应用，他仍可以在若干个ZigBee预定义的栈类中挑选一种安全模式。
在这个层上，开发人员需要决定这样一些问题：是否需要对数据帧的载荷进行加密，以及附着在数据帧末尾的认证码长度(8、16或64位，等等)。基本的应用也许不需要认证，因而可以受益于一个较小的数据包载荷。这些数据完整性方面的选项使得开发人员可以在消息保护和额外开销之间进行权衡。
开发人员还必须决定在哪个层上施加安全机制：在MAC层、网络层还是应用层。如果应用需要尽可能强大的安全保护，那么就在应用层保护它。此处实施的安全措施采用了一个会话密钥，它只能被另一个拥有该钥匙的设备所认证和解密。这种方法既能防止内部攻击也能防止外部攻击，但需要更多的存储器来实现它。
在MAC层和网络层的安全性实质上服务于相同的目的：确保单跳传输的安全。MAC层仲裁对共享媒介的访问并控制相邻设备之间的单跳传输。ZigBee联盟添加了一个网络层安全选项以便加入在MAC层无法实现的功能，包括拒绝不能被验证的数据帧的能力。这两个安全层采用的是该网络上所有ZigBee设备都共享的全局密钥。MAC层和网络层的安全性适合需要防止对特定基础设施攻击的应用，例如防止一个非法设备恶意侵入网络。如果开发人员需要在两个设备之间建立路由，而该网络层的框架又是不安全的，那么非法设备可能会截取数据包。
图2（见附件2）：ZigBee支持多种网络拓扑，包括星型、集群树型或星/网格混合型网络。
ZigBee安全性还引入了一个“信用中心(Trust Center)”的概念，它允许设备进入网络，然后分配密钥，从而确保设备之间端到端的安全性。此处，开发人员必须根据他们的应用从两种信用中心模式之间选择一种：住宅或商用。住宅模式消耗资源少，但不建立密钥或随着网络规模而扩展。商用模式建立并维护密钥，而且具有良好的扩展性，但其代价是要消耗相当多的存储器。
平台考虑因素
ZigBee提供了一个标准化的网络和应用框架，开发人员可以在此基础上建立应用而无须担忧联网和RF问题的烦扰。然而，单靠其自身，ZigBee标准化框架不能保证产品的顺利开发。为了创建兼容ZigBee的应用，这个市场的不同供应商提供了各种各样的产品，包括RF收发器、微控制器、闪存ROM、供应商专有的协议栈和应用开发工具。因此，开发人员必须选择是用多家供应商的组件创建自己的ZigBee解决方案，还是在一个集成硬件/软件平台上建立自己的应用。由于前一种方法涉及艰难的集成工作，因此大部分开发人员将可能倾向于后一种方法。
他们必须做出的第一个决定是在芯片和联网软件层次上。最大的挑战起源于硬件和联网软件之间的复杂性和不兼容性。在开发一个新应用时发现的问题很少只局限于一个协议栈层。例如，在一个原型设计的MAC层中发现的一个故障很少能够被网络层提供商检测到并进行调试。因而，开发人员必须仔细考虑他们所选平台的集成深度。
一个ZigBee解决方案需要一个RF收发器、一个针对应用处理的微控制器或DSP和一个ZigBee网络栈。直到最近，大部分系统都是来自于多家供应商合作伙伴的多芯片、多软件解决方案。目前，新一代的全集成、单供应商平台正在进军该市场。多供应商平台有时可以提供较低的前期成本优势。但是，一个单一来源的平台虽然常常更昂贵，却可让开发人员避免由不同供应商的硬件和软件产品组成的解决方案所固有的麻烦和产品开发延迟。
开发人员还必须考虑网络栈的深度。一般来说，网络栈越深，开发工作越容易。一个提供从物理网络层、传输层直到ZigBee类的网络栈将使开发人员不必理会网络的内在工作机理，从而允许他们集中精力于应用开发上。例如，一个用混合供应商解决方案建立的ZigBee应用可能需要开发人员计算他们的应用将如何处理节点之间丢失的网络包。这类复杂的网络问题已经在单一来源、全栈平台中得到考虑。
工具的选择也可能成就或毁坏一项ZigBee开发工作。开发人员需要仔细考虑他们平台的开发环境的广度和功能。供应商提供全套的开发工具是很重要的，它应该具备多节点无线半导体、网络软件、软件工具、培训和技术支持。此外，该工具应该是一个集成环境的一部分，此集成环境具备通用接口或者是一系列独立工具的集合。最后，开发环境应该包括用于调试的充分工具。