ZigBee技术是一种短程无线通信技术,基于ZigBee技术的应用系统具有诸多先进实惠的优点,例如:低成本、低功耗等。基于ZigBee技术的应用场景比较多,例如:停车场管理、无线抄表、矿井监控等。这些应用系统有很多相似的地方,本文试图给出一种基于ZigBee技术的应用系统的通用设计方案,具体的应用系统可以在此基础上做一些修改或者实例化就可以实现了。
FFD:全功能设备,可用作路由设备或者协调器。
RFD:受限功能设备,只能用作终端设备。
前台程序:运行在设备上的软件。
后台程序:运行在服务器上的软件。
上图是ZigBee应用系统的一个通用部署图,包括:
终端设备:为RFD,也可以是FFD,用于采集数据,通过路由设备与协调器(手持机或者基站)连接,或者直接连接到协调器。终端设备与路由设备构成星状拓扑结构,与协调器构成星状或者树形拓扑结构,作为拓扑图中的叶子节点。
路由设备:为FFD,负责传输信息,路由设备之间构成网状拓扑结构,与协调器之间构成树形拓扑结构。
协调器:为FFD,可以是手持机,也可以是固定式基站,除了能够控制终端设备、路由设备之外,还可以控制其他辅助设备。
辅助设备:为了配合ZigBee设备,完成特定应用功能所需要的其他设备,例如:道闸、LED指示灯、摄像头等,被协调器(基站)控制。
协调器(基站、手持机)可以通过多种方式与后台服务器连接:无线方式(GPRS/CDMA等)接入网络,有线方式(网口)接入网络,有线方式(串口/USB口)。
后台服务器:运行的是ZigBee系统的网络管理软件系统及业务应用系统(包括使用的数据库),这两个软件系统可以分开部署,也可以合一部署。
后台客户端通过以太网与后台服务器连接,可以有C/S结构的客户端,也可以由B/S结构的客户端。用户可以通过后台客户端实现对ZigBee系统的远程控制。
上图是ZigBee应用系统的一个通用的功能层次框架图。从下至上一次为:
终端设备:设备角色,为RFD,包括设备及前台程序,通过空中接口与路由设备或者协调器连接。
路由设备:设备角色,为FFD,包括设备及前台程序,通过空中接口与终端设备或者协调器连接。
协调器:设备角色,为FFD,包括设备及前台程序,通过空中接口与路由设备或者终端设备连接。
空中接口:这个指的就是无线接口,其内容就是ZigBee协议上定义一些数据结构、命令,也可以是自定义的协议。
前后台接口:一般就是ZigBee协议上定义的数据结构,也可以是自定义的协议,前台与后台就是通过这个接口来实现交互。
设备驱动:指的是被后台程序调用,与前台程序实现交互的一个角色,由于选在采用java来实现后台程序,因此设备驱动包含采用C2Java工具将前后台接口的C语言格式转化为java语言格式以便java程序使用。上层软件系统能够看到的最底层也就是设备驱动,并不需要了解设备层是如何工作的。设备驱动向上提供最原子的消息格式与调用接口,为了便于上层应用的使用,可以定义出一批固定接口,封装设备驱动,这里按照逻辑分为网络管理接口和业务应用接口,上层应用还可以直接调用设备驱动。
网络管理接口:用于实现网络管理功能,需要与前台交互的接口。该接口被网络管理系统实现,通过调用设备驱动来链接前台。
业务应用接口:用于实现业务应用功能,需要与前台交互的接口。该接口被业务应用系统实现,通过调用设备驱动来链接前台。
软件平台:可以将一些公共的,基础的软件部分抽取出来构建一个简单的软件平台,其他软件系统就可以基于该平台来构建,提高效率。
网络管理系统:实现网络管理功能的功能组件集合,可以通过网络管理接口,经过设备驱动来与前台链接,也可以直接通过设备驱动来与前台链接。网络管理系统基于软件平台构建,再加上一些网络管理组件,例如配置、拓扑、告警等。网络管理系统相对来说也可以做的比较通用。
业务应用系统:实现业务应用功能的功能组件集合,可以通过网络业务应用接口,经过设备驱动来与前台链接,也可以直接通过设备驱动来与前台链接。各业务应用系统差别可能比较大,但都可以基于软件平台来构建,随着业务应用组件的不断发展,还可以将一些通用的业务组件沉淀到平台中来。业务应用系统还要依赖于网络管理系统,没有网络管理系统,业务应用系统是玩不起来的。实际部署中,这两个系统可以分开部署,也可以一起部署,其实就是一些功能组件的可分可合。当然,要做到可分可合也不太容易,需要在设计的时候就考虑组件之间的依赖关系。最简单的,就是将两个系统合二为一,就是一个系统,既提供网络管理功能,也提供业务应用功能。
上图是一个简单的软件平台的框架图,解释如下。
首先是操作系统与数据库。操作系统就采用当前最广泛使用的win 2003和win xp,其中win 2003作为服务端和数据库的操作系统,win xp作为客户端的操作系统。当然,由于采用java语言来开发应用系统,也很容易切换到其他操作系统之上,例如linux、unix。数据库也采用当前用的最多的MS SQL Server 2005,可能使用oracle 10g以上或者MS SQL Server 2008。
JDK最好采用当前最稳定的版本,建议采用1.6。
应用服务器有好多,对于中小型系统,采用tomcat就足够了,而且还免费。
系统框架就采用SSH(spring+struts+hibernate)。
一些基础模块也是需要考虑的,例如:异常框架,调试打印,通信模块,这些都是必备模块,还可以加入一些选配模块,例如:定时器,队列,国际化等。基本上都能找到开源的东西,都往spring中塞就可以了。
为了实现系统分布式部署,还需要有ESB(企业服务总线)。
服务端与客户端之间可以采用多种方式通信,例如httpinvoke、rmi。还需要提供开放性的服务提供方式,例如web service、rest,当然,前期基本上都是闭环应用,可以不用提供这些。
不管是如何通信,都需要有一个请求解析派发模块,所有服务请求都要经过这个模块,这样便于实现对请求的管理,例如权限过滤等。
平台和可以提供一些基础的公共的组件,例如日志、权限,这两个组件几乎是必备。还可以提供一些框架性的组件,应用可以基于这些框架来开发特定的应用组件,例如数据管理、GIS、工作流、报表等,其中,数据管理需要自己开发,其他的都有开源组件,可以拿来用。
服务端还需要开发控制台,用于对服务端运行状态的显示监控。必须的。
C/S界面框架和B/S界面框架属于表现层的东西,做好了可以统一风格,避免重复开发。一般来说包括uiloader和控件两部分。uiloader要负责登录、主界面框架、权限控制等功能。各控件要支持国际化,个别要支持数据绑定。如果提供换肤功能的话,主界面及各控件还要注意皮肤的方便设置与切换。
网络管理系统基于软件平台开发,自然就包括了软件平台中已有的组件,例如日志、权限等。实际构建版本的时候也可以做一些选择。
为了较好的管理ZigBee网络,需要提供如下管理功能:
配置管理:特指网络管理相关的配置,与业务应用相关的建议分开放到业务应用系统中。配置管理是整个网络管理系统甚至业务应用系统中最基础的功能组件模块,其他模块都会依赖于他,没有他就玩不转。
版本管理:指的是对基站等设备上的前台程序进行管理的功能模块,完成版本下载、查询等功能。这个功能也是基础性的一个功能,相当于提供了一种方便的前台程序下载的手段,当然有其他办法也是可以替代的。
拓扑管理:必备功能模块,用以管理网络中所有节点之间的关系,可以基于GIS来做,显得更加形象,但GIS比较大,因此,如果不要求那么实时形象的话,没有必要。
告警管理:收集网络中各种告警信息,分成等级,便于网络维护人员及时进行网络维护。
性能管理:显示网络中各个设备的运行性能。
数据管理:网络管理系统产生的一些数据可能要做备份恢复等操作,提高数据安全性,也是一种提高数据库性能的方法,不一定必配。
业务验证:该模块提供一组测试手段,供管理者随时对系统业务功能进行测试,例如测试某一个终端设备是否能够正确采集发送抄表数据。不一定必配。
还可能存在其他一些功能。
好多ZigBee系统的价值就体现在业务应用系统上,前面所有模块都是为这个系统服务。基于软件平台开发。
除了特定于某一个应用场景可能存在不同的业务功能模块之外,还是可能存在一些共有的功能模块,不尽相同,但可以在同一的框架上开发,如下。
配置管理:指的是与业务应用相关的一些配置。
数据管理:基于通过用的数据管理组件来开发。
监控中心:考了来考虑去,觉得还是放到业务应用系统中,而不是放到网络管理系统中个,主要是基于监控可能更多的是与业务有关,当然可以与网络管理中的告警管理合二为一。如果对地址位置比较敏感,可以考虑基于GIS来构建,例如停车场的监控,通过监控台就能够实时了解整个停车场的状态。
综合分析:以多种形式来对整个系统的数据进行分析,以帮助管理者决策,天然的要求基于报表来做。开源的报表有很多,可以满足一些简单的需求,但中国的报表比较特色,开源的一般满足不了。国内已经有好多中国式报表的商家,可以购买,例如润乾、凡软等。其中润乾有免费版的,叫快逸,不幸的是不交钱的话,其logo标去不掉。