更具鲁棒性的ZigBee的研究开发

要求。在定制板上使用芯片组要求支持硬件生产工艺，包括板级测试、调试和返工。如果选用此方案，必须从 IEEE获得一个24位的OUI，以便为每个设备分配一个唯一的64位地址。

　　当定制板采用芯片组时，设计师还必须选用一个 ZigBee网络层协议栈。设计师必须将协议栈连接到他们的硬件上，细心地测试ZigBee应用，并评估网络性能。上述未解决的许多问题甚至所有的 ZigBee问题都必须在应用中解决，这将大大地增加研发时间方面的开销。

　　4. 设备开发

　　如果必须在芯片组或模块平台上开发定制固件，下面的步骤将会有用。

　　5. 选择框架类型

　　在着手开发ZigBee设备前，设计师必须确定是公共框架还是专用框架更能满足需求。设备是需要与与其它普通的ZigBee产品兼容，还是只适合特定的应用？协议栈参数是否需要调整到最佳性能？如果专用框架更合适，就需要向ZigBee联盟申请一个专用框架。

　　6. 确定路由策略

　　开发商应该清楚是否允许使用树状路由。对于简单的静态网络，树状路由将足够。如果某些节点有可能去掉，或者需要可靠的数据传输，树状路由就显得不足了。此时，就需要花些时间对协议栈何时调用路由发现进行评估。

　　如果所选的ZigBee协议栈符合增强型ZigBee规范，应用层就可以利用路由发现请求原语和nwkUseTreeRouting属性来控制路由发现和去除树状路由。如果采用的是网状路由，开发商应该考虑当所有的路由表入口都被占用的情况下系统将如何执行。因为ZigBee规范并不对老化路由和过期路由表条目进行监管，因此一些ZigBee协议栈实现不会去除旧的路由表条目。一旦所有的路由表条目被占用，设备将不能再参与路由发现。如果协议栈无法老化或取代过期条目，应用层就应该加入自己的监管措施来实现。

　　 7. 考虑固定信道操作

　　对于许多应用，即便是存在突发干扰，ZigBee网络也可以可靠地工作在固定信道上。但是，对于那些必须与其它系统共同工作在同一频段的系统，或者无法允许数据包偶然丢失的系统，则有必要支持信道的迁移。因为目前的ZigBee规范还没有定义信道迁移机制，应用开发商可以自行决定将网络迁移到一个新信道的条件，并开发相应的实现方案。

　　8. 克服寻址限制

　　在许多应用中，目前的网络地址分配机制是足够的。但是，为了防止地址重复的可能，更具鲁棒性的ZigBee解决方案应具有复位网络地址的能力(如协调器被替换时)。

　　由于设备的网络地址不可靠而且会变化(例如，一个加电周期或复位后设备无法找到其父设备)，应用层可能也需要一个能够唯一识别每个节点的解决方案。

　　为了确保将数据发送到正确的设备上，包括MaxStream XBee在内的一些ZigBee解决方案依赖于唯一的64位地址。如果采用这样的方案，应用层中就必须有相应的配置功能，以便在传送数据之前将64位地址转换成16位的网络地址。

　　9. 测试

　　测试应该包括验证系统如何对本文所述的应用场景反应。当路由器关掉时系统有什么反应？在工作信道上出现干扰时系统将如何执行？如果设备接收到一个新的网络地址，该新地址如何被发现？需要重申的是，一些模块和协议栈开发商已经开发出了解决这些问题的配置方案，从而大大减轻了应用开发商的开发负担。

　　本文小结

　　虽然ZigBee在前进道路上面临一些重要的问题，但ZigBee 联盟具有坚强的毅力、伟大的领导力，还有大批为标准升级积极贡献的优秀设计师。即使是初级阶段，能够为设计师提供强大的网络层功能和应用层灵活性的 ZigBee规范的重要基础工作也已经完成。

　　由于在嵌入式设备领域中有着强大的领导联盟，ZigBee正成为嵌入式设备市场上的重要角色。目前ZigBee联盟正在讨论配置问题以便增加ZigBee价值，并试图解决ZigBee规范中尚未解决的许多遗留问题。经过ZigBee认证的模块和网络协议栈正在开始面市，他们提供强大的网状解决方案，并有效地解决了目前ZigBee规范中存在的许多(即便不是全部)限制。现在正是开始开发可靠的、低功率和更高性价比的ZigBee解决方案的时候了。