首页 理论教育 物联网传感器的系统结构与设计原则

物联网传感器的系统结构与设计原则

时间:2023-11-02 理论教育 版权反馈
【摘要】:整个EPCIS系统设计主要包括数据库设计、文件结构设计和程序流程设计三部分。除了标签之间的联系,聚合事件中还有各类动作表示当前EPC标签的状态。其中,EPCIS捕获模块用于对EPCIS事件的捕获以及对所捕获到的数据进行处理。

物联网传感器的系统结构与设计原则

在RFID产品信息发布中,从生产线开始在产品的适当部位贴上标签,由专用设备写标签代码,由安装在产品物流过程中各关键部分的读写器读取信息,通过网络传送给EPCIS服务器,进行处理和存储。在查询时,用户使用读写器读取标签代码,凭借此代码到EPCIS服务器上进行查询。EPCIS根据标签代码和用户权限提供相关的信息,在用户使用的客户端计算机、带显示设备的读写器或者手机等专用设备上进行显示。整个EPCIS系统设计主要包括数据库设计、文件结构设计和程序流程设计三部分。

1.数据库设计

在EPCIS系统中,数据库用来记录产品类型等信息,当单个产品RFID码对应的信息传入系统时,应用程序访问数据库表,获取相关信息加入PML文档中。下面以所设计的产品为例,介绍由generate和show两张表构成的数据库。

generate表中,每个记录对应一个产品类型,show表中每个记录对应一个具体的产品。首先读写器传送来的信息会被插入到show表中相应的字段,然后调SHOWASPURL字段所指定的ASP(Active Server Page,动态服务器页面)程序,该ASP程序再负责将刚插入的传感信息从表中提取出来,插入到PML URL字段所指定的PML文档中,最后显示该PML文档的内容。show表中的传感信息字段起到缓冲存储的作用。

2.文件结构设计

每种产品类型×××只需1个×××.show.asp文件、1个×××.asp文件和1个×××文件夹。这些程序中,除Client.exe外,其余程序均运行于EPCIS服务器端,共同构成EP-CIS的信息服务系统,进行数据的存储,并为数据的查询提供相应结果。

3.程序流程设计

EPCIS客户端服务程序的作用主要是读取串行口传送来的RFID码信息和传感信息,结合本客户端的权限,实现与EPCIS服务器端的交互。

EPCIS服务器端运行的程序由服务器端应用程序、数据库、PML文档和HTML文档等组成。在存储和发布信息的过程中,程序以产品类型为存储单位进行存储,并依据数据库所指示的文件路径进行查询。EPCIS验证管理员权限无误后,判断是否为新的产品类型。若为新的产品类型,则调用server.asp生成新产品信息处理文件×××.asp,更新show表,将×××.asp文件路径等插入;若为已有产品类型,则调用该类型产品信息处理文件×××.asp,批量生成产品的PML文档,存储至×××文件夹,同时更新show表的相应字段。

EPCIS首先验证用户权限,无权限者被返回,而生产厂商、运输商和消费者等具有不同的查询权限,将查询内容和权限共同赋予×××.show.asp,生成相应的信息页面,返回给客户端。

4.EPCIS层次分析

(1)抽象数据模型层

抽象数据模型层定义了EPCIS内部数据的通用结构,是EPCIS规范中唯一不会被其他机制或者其他版本的规范扩展的部分。抽象数据模型层主要涉及事件数据和高级数据两种类型。事件数据主要用来展现业务流程,由EPCIS捕获接口捕获,通过一定的处理之后,由EPCIS的查询接口查询;而高级数据主要包括有关事件数据的额外附加信息,是对事件数据的一种补充。就高级数据的具体定义,在EPCIS规范1.0.1版本中并未体现。抽象数据模型层将被作为定义EPCIS内部数据格式的标准,由数据定义层使用。

(2)数据定义层

数据定义层主要就事件数据定义了其格式和意义。

EPCIS事件:对EPCIS中所有事件的概括定义。

对象事件:对象事件可以理解成EPC标签被RFID读写器读到,可以被任何一种捕获接口捕获,以通知EPCIS服务器此事件的发生。一个对象事件可以包括多个EPC标签的读取,各个标签之间可以没有任何联系。

聚合事件:聚合事件描述的是物理意义上的某个物品与另外一个物品发生“聚合”操作,比如商品被放入货架、货物被放入集装箱等。在这类事件发生时,会涉及“包含”和“被包含”的概念。例如,商品被放入货架,则货架在此处的角色定义是“包含”,而商品的角色定义是“被包含”;同样,如果这个货架被装入集装箱中,那么对于这个聚合事件,货架的角色就是“被包含”,而集装箱的角色就是“包含”。在聚合事件中,也可以同时涉及多个EPC标签。此处涉及的所有标签之间必须有十分严格的联系,要有明确的“包含”、“被包含”的角色划分。聚合事件中的EPC标签关系,与数据结构中的树很类似,即必须有一个“根标签”,且每一个标签都有其“父标签”或“子标签”。除了标签之间的联系,聚合事件中还有各类动作表示当前EPC标签的状态。

统计事件:用来表示某一类EPC标签数量的事件,最典型的应用就是生成某种物品的库存报告。(www.xing528.com)

交易事件:用来表示某个EPC标签或者某一批EPC标签在业务处理中的分离或者聚集。交易事件用一种模糊的方式来说明EPC标签在一个或多个业务处理中的状态。例如,一个商品被售出,此时商品首先会被销售人员从仓库中取出,触发一个聚合事件,然后记录商品的信息,最后交给顾客。商品从仓库中取出一直到交给客户的整个过程,就是一个交易事件。从实现的角度看,各类EPCIS事件的关系可以用UML(统一建模语言)模型表示。

(3)服务层

服务层定义了EPCIS服务器端提供的服务接口,用于与客户端进行交互。当前的规范定义了两个核心的接口模块:EPCIS捕获模块和EPCIS核心查询模块。其中,EPCIS捕获模块用于对EPCIS事件的捕获以及对所捕获到的数据进行处理。EPCIS核心查询模块除了基本的查询接口之外,还有两个接口用于与客户端交互:EPCIS查询控制接口用来对客户端的查询方式和查询结果进行控制;EPCIS查询回调接口用于按照用户的查询结果进行相应的回调操作。

5.EPCIS模块与接口

(1)数据(监听)模块

在数据捕获模块中,数据的发送方是系统直接导出数据(ALE)端,接收方是EPCIS服务器端。发送数据的过程是,由ALE提供原始数据,并将原始数据封装为XML文档格式,以ALE报告的形式发送,EPCIS服务器端接收到ALE报告后,对XML文档进行解析,得到相应的数据信息,经过一系列的校验后存入数据库。ALE监听器监听ALE报告的发送,并进行实时处理。

从实现角度来看,ALE报告的发送和对ALE报告的监听采用J2EE规范中的Java消息服务(JMS)规范和EJB中的消息驱动柄(MDB)来实现。在ALE端生成的报告以JMS消息的方式封装,并发送。在EPCIS服务器端配置一个消息队列,充当ALE报告发送的目的地。此外,在EPCIS服务器端对MDB进行部署,监听相应的消息队列,充当JMS消息,即ALE报告的使用者。

采用JMS和MDB实现的好处是两者都是基于标准的J2EE规范,当前主流的J2EE中间件都能够对这两项技术实现无缝支持,而且JMS和MDB后期都能够以Web服务器的格式进行发布,为各种服务的整合提供了良好的支持。

(2)查询模块

核心查询模块包括标准查询接口、查询控制接口和查询回调接口,客户端通过这3类接口可以与EPCIS服务器端的EPC数据进行交互。其中,标准查询接口是一种通用的查询接口,而查询控制接口和查询回调接口都是在标准查询接口的基础上对客户端和服务器端交互方式进行定制。在核心查询模块中,用户可以用两种方式来获得数据。第一种方式是提交一个查询请求,由EPCIS服务器端执行相应的查询操作,返回客户端需要的数据结果集。

从数据由服务器端到客户端的交互角度来看,这种方式称为“拉动”(Pull),即数据存放在服务器端,被动地由客户端来查询。另外一种方式是客户端对需要查询的数据进行订阅,定制的内容包括关键数据(如事件类型、包含的字段内容等)、周期(多久执行查询过程一次)以及生成查询报告的格式(以何种方式来展现查询结果集)。这种方式称为“推动”(Push),即客户端只需完成订阅操作,服务器端就可以根据客户端的订阅内容,周期性地生成查询报告。

(3)查询接口

标准查询接口用于与EPCIS服务器直接交互,访问EPC数据库。该接口不供客户端直接调用,而是作为一种相对底层的接口,与查询控制接口和查询回调接口结合在一起使用,来完成客户端的查询操作。

(4)查询控制接口

查询控制接口在标准查询接口的基础上,对客户端的查询请求进行控制,控制方式包括对大量数据的查询控制、对过度复杂数据的查询控制以及对订阅查询操作的控制等。许多查询操作可能产生一个“无限”大小的结果集,比如一个查询操作的条件是“查询某一个时间段内发生的所有对象事件”。根据对应时间段的长短或者单位时间内捕获接口捕获到的EPCIS事件,该结果集的数量可能是百万甚至千万级别的。此时,为了使系统性能不受影响,定义一个“超大查询异常”(Query Too Large Exception),当查询结果集的数量超过某一数值时,此异常将会被触发,提示客户端缩小查询的范围。

有一类查询操作需要比服务本身提供更加丰富的资源,比如某个查询的目标是查找某些特定字段存在特定数值的EPCIS事件,对这个事件的查询取决于对这个特殊字段的查询,而对这个特殊字段的查询又取决于数据库内部是否对这个字段建立索引。这样一来,此查询操作将涉及到更多的访问资源。针对这一问题,可以定义“过度复杂查询异常”(Query Too Complex Exception)来控制,当客户端的查询请求过于复杂时,这类异常就会被触发,导致客户端的请求被拒绝。与超大查询异常不一样,过度复杂查询异常一旦产生,即使客户端缩小查询范围,此查询也可能不成功。通常要修改查询条件的结构,以保证查询成功。

(5)查询回调接口

查询回调接口更注重查询结果的展现和回调操作,能够按照客户端的需求展示查询结果,并且根据查询结果触发相应的回调操作。回调操作主要包括两类:一类是当查询操作正常执行,结果集被正确返回时,触发正常的回调操作;另一类是当查询操作执行异常,结果集不能正确返回时,产生了超大查询异常,触发异常的回调操作。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈