专利名称：动态部件管理的制作方法
技术领域：
本发明涉及自动-id跟踪系统。
背景技术：
自动识别(自动-id)系统被用于例如识别或获取将要被制造、购买或销售、或用于商务的产品的信息。例如，关于诸如储藏室中的盒子的物理对象的信息可以与标签或其它粘贴(affixed to)在该盒子上的标识符相关地存储，并且/或者带有唯一标识符作为标签的对象可以位于零售商店的货架上。则，某种类型的设备，诸如读取器或传感器，可以被用于使用该标识符识别该物理对象，并由此确定、捕捉和使用存储在计算机系统中的关于该盒子或对象的信息，举例来说，所述信息诸如对象的品牌名称或对象的有效期。
自动-id系统的一个例子已知为射频识别(RFID)系统。RFID一般指的是这样的技术，其中，与RFID标签或转发器(transponder)中的天线相关的微芯片上存储了唯一的号码(和/或其它识别信息)。读取器用于与天线通信并从微芯片获取该唯一的号码，并且由此获得与该唯一的号码相关的信息。有利的是，RFID是快速的而且是无线的，不需要方向或可视线(line of sight)来使能在读取器和标签之间的通信，并且减少或消除了对于人的数据输入的需求。结果，RFID可以用于很多应用，例如诸如在商店或仓库中对有标签的对象的识别、具有RFID标签的汽车对通行费的自动付费、以及/或者为了进入受限区域而对授权人员的识别。
存在很多其它类型的自动-id系统设备。例子包括2D条形码扫描器、智能卡设备/读取器、语音识别系统、光学字符(optical character)识别系统以及生物测定系统(例如，视网膜和指纹扫描)。很多或所有这些系统都具有下列能力或潜力降低成本、增加效率，提高数据精度、为数据提供更多粒度(granularity)(甚至到达单个物品/对象层级(level))，以及由此改进在企业系统的操作中的顾客满意度。
发明内容
根据一个总体方面，系统包括自动-id节点，其可操作用来接收关于用于跟踪物品的自动-id跟踪系统的物品数据；数据处理模块，其在该自动-id节点中，可操作用于实施处理部件，以便在数据处理模块和自动-id节点的操作期间处理该物品数据；部件管理器，其可操作用来基于所述物品数据，从多个部件中确定处理部件；部件加载器，其可操作用于在该数据处理模块和该自动-id节点的操作期间将该处理部件加载到该数据处理模块。
实现可以包括一个或多个下面的特征。例如，数据处理模块可以包括内核服务模块，其可以被操作用于处理所述自动-id跟踪系统中的所述物品数据。部件加载器可以包括配置文件，其可操作用于基于与所述处理部件相关的配置设置向所述部件管理器输出指令，以用于确定该处理部件。所述数据处理模块可以包括集成模块，其可操作用于处理自动-id节点与自动-id跟踪系统的其它元件之间的通信。
所述处理部件可以包括适配器，其适用于与自动-id跟踪系统的指定元件进行的通信。所述适配器可以包括通信器，其可操作用于管理可以包括指定的通信协议的所述适配器与所述指定元件之间的数据传输；和数据转换器，其可操作用于管理在由所述处理部件所使用的第一数据格式与由该指定元件所使用的第二数据格式之间的数据转换。
所述处理部件可以与可以被主动实施的用于执行第一处理任务的主动实例以及可以不被主动实施的用于执行第二处理任务的被动实例相关。还可以存在用于将处理部件的被动实例与所述多个处理部件中的一个或多个的其它被动实例一起存储的池。
所述数据处理模块可以包括实例管理器，其可操作用于基于对所述第二处理任务从不被主动实施到被主动实施的改变的确定，从所述池中激活被动实例并将该被动实例实施为第二主动实例。
所述实例管理器还可以可操作用来基于对所述第一处理任务从被主动实施到不被主动实施的改变的确定，将主动实例去激活到所述池中以作为第二被动实例存储。还可以存在部件数据仓库，其可以操作用来存储所述多个处理部件，以用于所述部件管理器或所述部件加载器从中进行选择。
根据本发明的另一个总体方面，在用于跟踪物品的自动-id跟踪系统中的自动-id节点接收物品数据；分析该物品数据，以便从多个部件中确定用于处理该物品数据的处理部件；在数据处理模块和该自动-id节点的操作期间向该数据处理模块加载该处理部件；并且使用该处理部件处理该物品数据。
实现可以包括一个或多个下列特征。例如，在向所述数据处理模块加载所述处理部件中，可以将该处理部件加载到集成模块，该集成模块可以操作用于处理该自动-id节点与自动-id跟踪系统的其它元件之间的通信。在向所述数据处理模块加载所述处理部件中，可以加载可以适合用于与所述自动-id跟踪系统的指定元件通信的适配器。
可以加载所述处理部件的主动实例，以用于执行可以被主动实施的第一处理任务；并且可以存储该处理部件的被动实例，以用于执行可以不被主动实施的第二处理任务。
基于对所述第二处理任务从不被主动实施到被主动实施的改变的确定，可以从所述池中激活所述被动实例，以将该被动实例实施为第二主动实例；并且基于对所述第一处理任务从被主动实施到不被主动实施的改变的确定，可以将该主动实例去激活到所述池中以便作为第二被动实例存储。
根据本发明的再一个方面，一种装置包括具有存储在其上的指令的存储介质。所述指令包括第一代码段，用于在用于跟踪物品的自动-id跟踪系统的自动-id节点接收物品数据；第二代码段，用于分析该物品数据，以便从多个部件中确定用于处理该物品数据的处理部件；第三代码段，用于在数据处理模块和该自动-id节点的操作期间将该处理部件加载到该数据处理模块；和第四代码段，用于使用该处理部件处理该物品数据。
实现可以包括一个或多个下列特征。例如，所述第三代码段可以包括第五代码段，用于将该处理部件加载到集成模块，该集成模块可以操作用于处理所述自动-id节点与所述自动-id跟踪系统的其它元件之间的通信。所述第五代码段可以包括第六代码段，用于加载可以适合用于与自动-id跟踪系统的指定元件进行通信的适配器。
所述自动-id跟踪系统可以操作用于从多个跟踪设备自动收集所述物品数据，并且还可以操作用于处理该物品数据，以便使得物品数据对于与该自动-id跟踪系统相关的企业应用和用户接口是可用的，并且对于该自动-id跟踪系统来说是可用的。
数据处理模块可以包括实例处理器，其基于对第二处理任务从不被主动实施到被主动实施的改变的确定可操作用于激活在池中的被动实例并且将该被动实例实施为第二主动实例。
在附图和下面的描述中，一个或多个实现的细节将被说明。通过描述、附图和权利要求，更多的特征、方面和优点将变得更加明显。
图1是自动-id系统的网络图。
图2是图示图1的自动-id特征(feature)的例子的系统200的方框图，包括具有自动-id节点和设备控制器的自动-id基础结构(infrastructure)。
图3是与图2的自动-id基础结构一起使用的网络体系结构(architecture)的方框图。
图4是图2和图3的自动-id节点的方框图。
图5A图示了设备集成(integration)。
图5B图示了设备集成、后端系统集成、人力(human)集成和自动-id节点集成。
图6图示了集成层。
图7和8图示了集成层的面向对象的实现。
图9是图4的自动-id节点的实现的方框图。
图10是在图9的实现中使用的配置设置文件的方框图。
图11是在图9和图10的实现中使用的部件的实例的生命周期的流程图。
图12是图9和图10的系统的部件的实例的生命周期的流程图。
在不同的附图中相同的附图标记和名称指示相同的元件。
具体实施例方式
图1是自动-id系统100的网络图。在图1中，多个企业应用包括例如供应链管理应用102，其可以被企业用来监视企业的产品或服务的生产/购买、发货和销售的过程。资产(asset)跟踪和管理系统104可以被例如用来监控和跟踪在一个场所(site)中、在多个场所之间、在一个组织内或者在多个组织之间的资产的数量，以便确定哪个资产，例如存货资产对于企业来说是可用或不可用的，或是企业所期望的。库房管理应用106可以被用于监视库房的接收、存货、选择和发货方面。分析系统108可以被用于对诸如例如对于顾客请求的响应的速度、偷盗导致的损失、以及任何其它可能影响到企业的利润或操作的企业操作的方面进行量化。
图1图示的企业应用的例子图示了企业对于搜集、共享和使用对于企业系统来说是通用的数据的需求。例如，供应链管理应用102可能需要基于资产管理应用104中的数据了解当前有多少某种类型的资产可用。分析系统108可能从自动-id中间件和从其它应用102、104或106提取数据，以便例如发现性能方面的论题(诸如存储的使用，或者递送延迟的原因)、问题(诸如产品假冒模式)、以及物理对象的一般可视性(物品、箱子(case)、货盘)。分析系统108可以通过门户系统报告所发现的结果。
要由企业应用共享和使用的大多数数据，诸如，那些刚刚被描述的数据，都涉及由企业系统购买和/或卖出的产品或服务。在图1中，有关这些产品或服务的信息由应用通过使用中间件基础结构110来获取，中间件基础结构110实现了自动识别(自动-id)系统，用于自动获取和共享与要购买和/或销售的产品和服务相关的信息。
一般，如上所指，自动-id系统使能与企业卖出或使用的产品相关的信息的收集和使用，并且包括用于获得关于标识符的信息的标识符和读取器。在图1中，自动-id元件的例子包括条形码读取器/打印机112，其可以被用来读取或打印(将要)附加在对象上的条形码标签。示出了RFID读取器/打印机114，正如从上述关于RFID系统的讨论应该理解到的，其可以被用于从附加到对象的RFID标签读取信息或向附加到对象的RFID标签分配信息。传感器16例如可以指的是环境传感器(例如温度计)，或是语音或光学字符识别传感器。正如其名称所暗示的，移动读取器118指的是可以由用户携带的例如用于检测RFID标签或其它自动-id标识符的读取器。最后在图1中，可编程逻辑控制器(PLC)设备表示用于诸如开/关控制、定时、逻辑、计数和排序的应用的数字控制器，并且还可由下面详述的设备控制器系统进行控制。
如图1所示，随后，通过自动-id设备/系统112-120中的任何一个获取的信息都可以被传输到企业应用102-108中的任何一个、在任何企业应用102-108之间共享，并且由企业应用102-108中的任何一个使用。这样，企业可以获取和使用实质上是实时的、跨越其操作的整个层面(spectrum)的信息。而且，企业可以与其它企业共享信息。例如，供应链管理应用102可以与第一企业(例如零售商店)相关，而库房管理应用可以与第二企业(例如制造商)相关。通过从自动-id设备/系统112-120获取信息，并跨越中间件基础结构110共享该信息及其它信息，所述两个企业可以提高他们两个各自的操作效率。
图2是图示图1的自动-id特征的例子的系统200的方框图。在图2中，企业应用202可以包括上面讨论的各种应用102-108，以及各种其它企业应用。
自动-id基础结构204表示图1的中间件基础结构110的部分或全部。具体来说，自动-id基础结构204包括自动-id节点206、208和210。自动-id节点206、208和210一般表示在定义的位置的节点，其被设计成将自动-id设备112-120获取的信息与现有的商业逻辑或数据相关联。而且，自动-id节点206、208和210可以被用于存储被自动-id设备/系统112-120跟踪的产品或对象的历史信息。这种历史信息例如可以包括，在特定时间的状态信息、对象位置、与被跟踪的对象相关的环境信息、以及为了期望的目的被收集和组合的多个对象的信息。
自动-id节点206、208和210可以在整个企业中或者在多个企业之间战略地来布置。例如，自动-id节点206可以位于制造场所，而自动-id节点208可以位于产品分配(distribution)场所，而自动-id节点210可以位于零售商店。这样，可以获得特定于自动-id节点的实际设置的信息并且该信息只在该特定节点被保留。
例如，在零售商店的自动-id节点210可能对跟踪物品的零售价格或者在零售商店的货架上的物品的数量感兴趣。这种信息可能对于在制造位置的自动-id节点206不是有用的，但是可能对于在分配位置的自动-id节点208是部分有用的。例如，在分配位置208的自动-id节点可能对物品的零售价格不感兴趣，但是可能对目前在货架上的物品的数量感兴趣(为了重新上货)。
类似地，在不同场所的商业处理和商业逻辑可以从对本地化的自动-id节点206、208和210的使用中得到好处。例如，零售自动-id节点210可能包括用于防止对象被盗的工作流程(workflow)，而制造自动-id节点206可能对监控在特定时段内生产的对象的数量感兴趣。于是，通过使用本地化的自动-id节点的分散的网络，系统200可以更有效地处理信息，并且以对在各个位置的用户更有用的方式来处理信息。
在系统200中的每个自动-id节点一般包括一个或多个设备控制器，在图2中图示为设备控制器212，214和216，它们与分配自动-id节点208相关。当然，自动-id节点206、208和210中的每个可以具有更少数量或更多数量的设备控制器，或者可以根本不使用设备控制器。
参照作为例子的设备控制器214，图2图示出设备控制器214可以被用于监视和协调某些或全部自动-id设备112-120的操作。当然，设备控制器212和216可以被用于监视可以被连接到那些设备控制器的类似的自动-id设备的操作。
更特别的是，设备控制器214可以被用于处理来自自动-id设备112-120的数据，以便提高其相关的自动-id节点208的效率。例如，设备控制器可以去除无关的信息，或者可以以由自动-id节点208指定的方式组合或修改数据，所述的指定方式可能对该自动-id节点的分配功能有用，并且/或者可能对企业应用202有用。
因此，设备控制器214可能基于来自自动-id节点208的指令来协调和管理自动-id设备112-120，并且将来自自动-id设备的(处理过的)信息中继到自动-id节点208。例如，自动-id节点208可以被用于指示设备控制器214来获取与对象218(例如，要分配到零售商用于销售的玩具或其它物品)相关的特定类的数据(例如诸如数量)。然后，设备控制器214可以使用RFID读取器/打印机114从与对象218相关的标签220获取这个信息，并且可以随后在传递关于对自动-id节点208可用的被讨论的对象的特定数量的信息之前去除任何同时获得的不期望的信息。
作为另一个例子，自动-id节点208可以指示设备控制器214分配信息给对象218。例如，设备控制器214可以使用RFID读取器/打印机114来改变对象218的当前价格(例如，将新价格信息存储到附加在某类对象的RFID标签220上，或将该信息与该RFID标签220相关联地存储)。
从图2应当可以理解，正如设备控制器212、214和216中的每一个可以被用于对与其相关的所有自动-id设备和/或环境设备112-120进行过滤、集合(aggregate)、写入或者操作(manipulate)数据，自动-id节点208可被操作用来对与其相关的设备控制器212、214和216进行过滤、集合、分配或者操作数据。以这种方式，自动-id节点208可以将来自于其设备控制器212、214和216的信息与在一个或多个企业应用202上可操作的商业处理进行集成。
通过扩展(by extension)，可以看到企业应用202可操作用来从所有的自动-id节点216、218和220集合信息。而且，应当理解，在系统200的一个层级有用的信息可能在另一层级不是有用的。例如，企业应用202可能对由读取器/打印机114收集的低层级(例如物品层级)信息不感兴趣，或者不能使用该信息。而是，企业应用202可能对该信息的兴趣只达到该信息是由设备控制器214和/或自动-id节点208过滤和/或集合的程度。
作为所描述的体系结构的结果，应当理解来自企业应用202和/或来自多个企业应用的商业逻辑可以在自动-id中间件110中得到支持。而且，这种多个企业应用可以使用对于所有的企业应用来说是通用的单一的物理硬件系统和单一的自动-id中间件来支持。
图3是与图2的自动-id基础结构204一起使用网络体系结构300的方框图。更具体的说，图3图示了一种体系结构，通过该体系结构可以使得图2的自动-id基础结构204可以与被开发用于自动-id系统的电子产品代码(EPC)一起使用。
EPC指的是与统一产品代码(UPC)标识符类似的一个唯一的号码，其具有预定义的格式和方案(scheme)，多个组织和企业同意使用该格式和方案来唯一指定和识别他们的相关产品、货物或服务，及其集合(例如货盘、箱子或者卡车负载)。那么，在RFID系统的上下文中，EPC可以被分配(assign)给在图2的对象218上的标签220。例如，典型的EPC是由四个字段定义的首标字段(用于区分不同的格式)、制造字段(每个分配EPC的组织具有其自己的制造字段)，产品字段(产品代码)和序列号(伴随产品)。
在图3中，EPC信息服务(EPCIS)层302允许在网络上交换EPC数据。即，EPCIS提供标准格式或协议，通过该标准格式或协议，识别出EPC号码的读取器可以找到并使用关于该EPC号码的信息(并且因此可以找到并使用与其相关的物品)。在一些实现中，并且/或者在相关实现中，例如诸如物理标记语言(PML)和/或可扩展标记语言(XML)的语言可以被用于上述对于商业层级EPC信息的传送和使用。
EPCIS层302从应用管理器304接收信息，应用管理器304一般可操作用于监视信息事件(例如标签读取)并管理事件，以用于到EPCIS层302的通信以及借此到EPCIS数据仓库(repository)306的通信。当数据仓库306在相对长的时段内累积数据并且在该时段内数据可能对于特定的应用或设备并不是立即有用的时候，应用管理器304操作以监控和配置数据仓库306。一般来说，特别考虑到潜在的网络延迟，多个对象的信息流可能对于数据仓库306来说太大，以致无法在实际中实时使用。图2的自动-id节点208最好可以在某个固定的时段跟踪那些对于自动-id节点208来说是立即可用的信息。
应用管理器304和EPCIS层302对对象名称服务(ONS)具有访问权限，而对象名称服务与域名服务(DNS)类似，是一种允许应用管理器304和EPCIS层302基于产品的EPC代码来找到关于该产品的信息的查看服务。ONS 308可以具有不同层级的信息，例如可以基于该信息对于产品来说是否是本地存储来对该信息进行分类。
应用层级事件(ALE)接口层310提供到设备管理器312和设备控制器214的接口。更特殊的是，ALE接口层310可以被用于在从设备管理器312和/或设备控制器214接收信息事件时对其进行过滤或集合。设备管理器312可以被用于管理设备控制器214的状态和/或配置。
还是在图3中，读取器协议接口层314为设备114提供接口。即，应当理解，不同的企业可以采用不同类型的设备114，或是其它自动-id设备，并且这些设备和企业可以使用不同的读取器协议以用于与读取器通信。读取器协议接口314被设计成使能与在系统300中的全部的读取器的通信。
从图3中应当理解，无需图2的自动-id基础结构204也可以使用系统300，并且，反过来，无需图3的其它元件也可以使用图2的自动-id基础结构204。于是，图3示出了图2的自动-id基础结构204可以但不要求与EPC网络及标准一起使用。
图4是图2和/或图3的自动-id节点206、208和210的方框图。在图4中，内核服务模块402如下所详述地例如处理自动-id节点208的实现的细节，而各种集成模块404、406、408和470处理内核服务模块402相对于外部特征、用户和服务的通信、配置和管理细节。
例如，后端系统集成层404处理自动-id节点400与后端系统之间的通信，后端系统诸如例如图1的应用102-108，或者图2的应用202。
设备集成层406处理自动-id节点400与设备之间的通信。例如，设备集成层406可以使能图2的节点208与设备控制器214之间的通信。在一些实现中，设备集成层406可以使能与一个或多个跟踪设备112-118的通信。
人力集成层408处理自动-id节点400与用户接口之间的通信。例如，自动-id节点操作员可以配置自动-id节点，以便通过用户接口执行某些任务，或者监控自动-id节点接收的信息。当例如发生不期望的事件或者故障时，操作员还可以从自动-id节点获得报警消息。而且，自动-id节点400得安全性可以被监控，以使得只有被授权人员才能与自动-id节点400交互。
节点集成层470处理自动-id节点400与其它自动-id节点之间的通信。例如，多个相邻的自动-id节点一起可以通过分配或供应链跟踪对象，以便为对象提供路由信息，或者确定是否应该购买或库存附加单位的该对象。
将在“集成层”的题目下更详细地描述节点集成层470、后端系统集成层404、设备集成层406以及人力集成层408。
内核服务模块402包括行为(activity)和处理(process)管理模块410。行为和处理管理模块410分析与对象经历的事件相关的信息，所述事件诸如例如标签信息被图2中的RFID读取器114从(例如)对象218的标签220读出的读取或跟踪事件。随后，行为和处理管理模块410将该信息与已知的与该特定对象相关的信息进行匹配。
例如，如下所详述的，每个被跟踪的对象都可以与一个或多个商业处理相关，所述商业处理也被称为例如商业处理模型或工作流程。这种处理通常描述对象在其生命周期的全部或部分期间，即从制造到分配、或从分配到零售、或从制造到零售，所经历的所有已知或预期的可能性。在这个意义上讲，取决于特定自动-id节点400的责任，自动-id节点可能要求特定对象的全部生命时间的信息，或者可能只要求该生命时间信息的某个子集。
因此，实际上，当前的事件信息(例如由读取器114从标签220读取的信息)与在先检测到的事件信息以及预期的事件信息(从相关商业处理模型导出的)相结合，允许自动-id节点400对于被跟踪的对象的状态进行确定。通过这种方式，自动-id节点400能够在最少的人力干预或监视下以高效率和成本有效的方式通过供应链或某些其它商业模型(例如顾客退货)来移动对象。
行为和处理管理模块410包括事件消息分派器(dispatcher)412。事件消息分派器412从不同的源接收事件，其中，如上面所提到的，术语事件通常可以指由例如图1中的一个或多个跟踪设备112-118的行为触发而发生的事件。
在一些实现中，这种事件可以被表示为事件消息分派器412从任何数量的源接收的软件/数据分组。除了跟踪设备112-118外，还可以经由人力集成模块408从本地操作员接收事件。还可以从例如后端系统404或从另一个自动-id节点接收事件。
这些不同源的事件可以在描述各种事件时共享相同或类似的格式。例如，不同源的事件可以使用统一的事件描述符协议来描述事件。事件描述例如可以包括指定的对象标识符、事件类型(例如RFID读取事件)、事件源(例如RFID读取器114)、时间戳、事件源的位置、事件主题标识符或其它信息。
作为一个具体的例子，读取器设备114可以发送类型为“扫描”、来自于具有id“abcd1234”的RFID读取器、与时间“2004年12月21日上午10:23”相关联并具有对于被扫描的对象来说是唯一的对象专用标识符的事件。通过这种方式，可以以兼容的格式在事件消息分派器412中接收来自不同源的事件，从而事件消息分派器412可以以相同或类似的方式来处理到来的事件，而不管事件的源如何。
事件消息处理器412分析上面提到的某些或者全部信息，或者其它信息，并且从而将到来的事件分派到一个或多个行为处理器(handler)414或416。例如，可以基于事件的类型(例如，设备读取器事件，或者相邻自动-id节点事件，或者后端系统事件)、事件的时间(例如，该事件是白天事件还是夜晚事件)、或者实质上通过其可以委派行为处理器来处理事件的任何其它标准来将事件分派给其它行为处理器414/416之一。
行为处理器414/416分析其中包含的关于事件的信息以及可能与该事件相关并且可以在需要时访问的任何已知数据，并且将该信息和与事件的对象相关的确定的商业处理进行比较。通过这样做，行为处理器414/416可操作用来确定响应于该事件，如果需要的话，应该采取的一个或多个未来的动作(action)。
一旦被确定，未来的动作可以被传送(communicate)到自动-id节点400的外部，以便在那里执行。例如，未来的动作可以通过集成接口404、406、408和/或470来传送。通过这种方式，例如，可以要求人类操作员执行某种动作，或者可以提出报警，或者可以通知分离的自动-id节点204、206、208(或者后端企业应用102-108/202，或设备112-120)某些所需的行为。行为处理器414/416还可以更新其自身的状态和/或跟踪关于该对象的数据，以便反映由事件代表的改变，并更准确地反映该对象在商业处理中的位置。
和该对象相关的商业处理可以以一组规则来表示，并且/或者作为可以与该对象、可能以及其它对象相关的工作流程模型的一部分来表示。例如，规则可能与条件条款类似，阐明响应于特定条件或情况(circumstances)应采取的不同的动作。即，规则可以阐明如果对于接收到的事件一个或多个条件被满足，则作为响应应该采取一个或多个动作。在下面将详细讨论条件的类型、决策确定处理和响应的动作。
为了实现这样的规则，行为处理器414包括规则引擎418，其将规则组420和422应用到在行为处理器414处到来的事件。规则引擎418提供用于将可编程规则组应用到在自动-id节点400处接收的事件的体系结构。规则引擎418例如可以实施一种机制，以便在规则组420/422中搜索可以被应用于所接收的事件的一个或多个规则。
例如，规则引擎可以分析该事件(该事件如上所提到的可以采用统一事件描述符协议的格式)，并且可以对每个规则组和/或规则的选择性标准进行计算和匹配来找到一个或多个可用规则。规则引擎418还可以包括这样的机制，其通过激活在内核服务410的其它部分的动作，以及/或者通过经由后端系统集成404、设备集成406、人力集成408和节点集成470传送对于外部模块、用户和服务的动作请求来执行规则。
作为一个例子，事件消息分派器412可以确定到来的事件与在某个位置(例如在仓库的特定入坞湾(docking bay))接收到某类设备的送货相关，并且可以将该事件分派到行为处理器414，其可以被分配处理这种事件。行为处理器414可以确定该事件与某个对象相关并且/或者具有其它的特性(例如在晚上送货期间发生)，以便确定在规则引擎418中的规则组420是适合应用到这种类型的事件的规则组。随后，规则组420可以被应用来分析所接收的事件并从而将每个规则的条件条款与所接收的关于该事件的信息以及其它信息(可能的话)进行匹配，并且，如果存在匹配，则可以将该规则应用于确定对于该事件以及相应的对象将要采取的未来的或期望的动作。
规则引擎418是可缩放的，以便更多的规则组可以被添加到该规则引擎而无需破坏其功能。而且，规则引擎418是灵活的，因此。现有的规则组可以例如在运行时间或在不再需要时被去除或去激活(deactivate)。
规则组420例如可以由后端系统经由后端系统集成模块404或者从其它接口模块406、408或470之一分配到行为处理器414/416。还可以从其它自动-id节点或者从图3的EPCIS数据仓库306或者从一些其它源添加规则。由于规则组420/422是模块化的，因此它们可以容易地被替换或修改，而不会破坏其它规则组的操作。
如上所提到的，规则引擎418接收对象专用事件并且将该事件与商业处理相关联，以便确定，如果存在的话，用于与该事件相关的对象的未来或期望的动作。通过这样做，规则引擎418可以具有对在执行匹配操作中可能有用的附加数据的访问权限。特别是，在内核服务402中，相关数据管理模块423与行为和处理管理模块410通信，并且将存储(或访问)在规则引擎418实施规则组420和422时可能有用的数据和服务。
例如，相关数据管理模块424可以与行为处理器414、416紧密工作以跟踪每个事件对象的生命周期，或者该生命周期的一部分，并且可以响应于接收事件来实时更新事件对象的状态。例如，相关数据管理模块423可以包括有关对象在其从例如生产到零售，或者从退回对象直到该对象被重新包装作为整修过的对象来零售的生命周期的过程中的数据。
相关数据管理模块423通常跟踪有关特定对象的两类数据。具体来说，动态数据指的是随时间变化、或者可以期望会变化，或者随着相关对象随时间移动而已经变化的数据。相反，静态指的是通常不随时间变化，或者仅仅是不经常变化的数据。不同的参数取决于被跟踪的对象和商业处理可以被认为是动态的或静态的。例如，一个对象的位置可以被认为是动态的，而对象的颜色或重量一般可以被看作是静态的。然而，对象的颜色也可能变化，特别是在制造过程中，在这种情况下颜色可以被看作是动态的性质。
因此，动态数据在对象在定义的生命周期或时间线中移动时表示该对象。例如，动态数据一般在图4中被表示为包括三个部件期望动作424、当前状态426和历史428。期望动作424包括对于事件的期望的未来事件，或者可能的未来事件。于是，当前状态426可以包括事件的当前状态，而历史428可以包括事件对象所经历的过去事件的列表。
由于这些部件是动态的，因此可以响应于相对于特定对象而接收的事件来修改相关数据。例如，每次接收到事件时可以由行为处理器414、416来更新三个部件424、426和428。具体来说，如果事件触发在装车平台(loading dock)对对象的接收，则该对象的当前状态可以从当前状态426中的“运送中”变为“已接收”。随后，可以将之前的当前状态条目(entry)移动到历史428，以表示该对象的运送历史(例如在运送中经过的路线)。在期望动作424中“已接收”的期望动作被重新指定为当前状态426，并且规则引擎414可以使用规则组420来确定下面应当实施仍在期望动作424中的哪一个期望动作(例如卸载该对象以便存货到商店的货架上)。
于是动态数据至少可以和接收关于特定对象的事件频率一样经常地改变(alter)。事件的数量和频率通常与读取器的数量和可用性相关，因此，在理论极限中，由足够大的数量的读取其在其生命时间期间连续跟踪的对象可以具有连续变化的动态数据。
相反，静态数据存储在通常不被期望需要有规律或者持续更新的数据库或存储器中的相关数据管理模块423中。而是相关和数据管理模块423可以与外部源进行通信来周期性地或者半周期性地更新静态数据。因此，这种静态数据通常可以不被期望会响应于事件而改变(虽然这在某些情况下可能发生)。
例如，位置数据库430可以包括装车平台的地址，以及到达该装车平台的送货的可能的源的地址。应当理解一些位置信息可以被认为是动态的(例如运送中的对象的当前位置)，而另一些位置信息可以被认为是静态的(例如生产特定对象的制造设施)。然而，通常，静态信息将被认为是不会逐事件地改变的。
类似地，产品数据库432可以包括被跟踪的产品或对象的详细描述，包括那些改变但是又通常不会逐事件地改变的描述。产品数据库432可以存储这种信息，或者可以从外部源中例如使用统一产品id(例如从对象218的标签220读出的EPC代码)来查看该信息。
商业处理数据库434可以包括一个或多个与对象相关的商业处理。如上所提到的，商业处理可以指被设计来支配(govern)对象的生命时间的任务/事件的形式化的工作流程或进展。例如，商业处理模型可以被形式化以用于制造处理，或者用于分配处理，或者用于客户返还缺陷商品的处理。
在这种情况下，商业处理模型可以在例如后端系统202在抽象层级上来设计，以通过多个对象的各自生命周期的全部(或很大的部分)来支配该多个对象的生命时间。这样，可以在自动-id节点400实施或监控商业处理模型的特定子集或实例，以便使用于特定对象的商业处理模型表示该对象可能经历的生命周期及可能(预期)的事件。这种类型的实现的一个特定例子将在下面参照图6来讨论。
在其它的例子中，可能不存在在这个层级上定义的商业处理模型或者工作流程，并且规则、动态数据和静态数据可能隐含地定义将由对象经历的商业处理。
资源数据库436可以包括用于事件的其它资源。例如，资源数据库436可以包括对于实施响应于事件所需的任何动作来说都是可用的资源。例如，如果在仓库接收到对象，并且该仓库需要特殊的设备以用于运输该对象，则资源数据库436可以存储有关这样一种在该仓库的前提下可能有用的移动设备的信息。类似的解释适用于可能对于对象的整个生命周期中的对象管理来说是有用的其它资源，因此，通常，每当规则引擎418确定需要动作时，都可以咨询资源数据库来确定为了实施该动作什么资源是可用的。
虽然针对动态数据和静态数据的划分讨论了上述的实现，应当理解这种划分仅仅是一个例子。例如，数据库430-436可以被用于在存储静态数据之外还存储一些或全部动态数据，并且，在这种情况下，可以简单地比上述的例子中更经常地使用动态改变的数据来进行更新。例如，如上所提到的，既然位置数据可以表示动态位置信息或是静态位置信息，那么应当理解，可以认为位置数据库430包含动态和/或静态数据。
内核服务402还包括配置和经营(administration)管理模块440，用于配置和管理自动-id节点400。例如，经营管理模块440可以允许用户上载更多的规则组420、422，管理与模块404-408相关的集成逻辑，或者建立与外部服务的连接(例如更新静态数据存储430-436)。最后在图4中，存储和归档管理模块450管理内核服务模块410的数据存储和归档。例如，模块450可以被用于对不经常使用的或者在某个预定时间中不被使用的数据归档。通过这样做，模块450可以与外部存储站点进行交互，以便最小化在自动-id节点400处需要的资源。
上述对于图4的描述是针对特定对象或特定对象组的时间线的例子给出的，其中，对象的期望动作被与实际的事件相匹配。然而，应当理解，可以用其它参数来实施规则、时间线和其它标准。
例如，除了是对象专用的，自动-id节点还可以相对于特定的读取器或读取器组来操作。例如，一个读取器可以从多个对象的标识符中检测事件，从而历史428、当前状态426和期望动作424可以相对于读取器，而不是相对于该读取器读取的任何特定对象来定义。
例如，圣诞节的橱窗(display)可以销售很多与圣诞节相关的对象，并且可以使读取器位于这些对象的附近来确定何时橱窗缺货(depleted)。在这个例子中，行为处理器414可以处理关于特定处理器所发生的所有行为，并且规则组420可以指定例如用于从储藏室或者从制造商再次定购库存的参数，或者用于在一类对象售完后将该类对象替换为另一类的参数。
因此，虽然行为和处理管理模块410可以根据多种不同的参数和方针(guideline)来操作，但是从此处包含的说明和例子应当理解，行为和处理管理410可操作用于确定期望事件或未来事件，并且等待直到匹配期望事件的相应事件到来。通过这样做，行为和处理管理模块410可以处理不匹配任何期望事件的多个事件，在这种情况下可以触发报警，或者，不需要采取任何动作。
集成层如前所述，设备集成层406处理自动-id节点400与多个设备之间的通信。如图5A所示，设备能够包括不同类型的自动数据获取设备510、设备控制器520和设备管理系统525。如图5A所示，自动-id节点400能够直接与特定设备510通信，或者通过设备控制器520与特定设备510通信。
数据获取设备510能够包括周期性设备和非周期性设备。周期性设备是那些发射周期数据流的设备。非周期性设备是那些发射非周期数据流的设备。周期流是以规律的时间间隔(例如每n毫秒一个数据值)发生的连续的数据流，而非周期流与其相反，其中的数据使以非规律的间隔发射，例如，只有当检测到带标签的物品时才发射。周期性设备的例子是用于测量一个或多个物理属性(例如，温度、湿度、加速度、压力、光、位置、移动或噪声)的传感器，以及提供连续数据馈送(例如股票信息)的服务器。非周期性设备的例子是RFID(射频识别)标签读取器。特定类型的RFID标签读取器的例子是由加州Morgan Hill的Alien Technology制造的读取器以及由马里兰州Rockland的Matrics有限公司制造的读取器。
如前所述，设备控制器520是软件，可操作用于管理一个或多个自动数据获取设备510，并且基于来自自动-id节点400的指令将由自动数据获取设备510发射的数据中继到自动-id节点400。
设备管理系统525监控设备和/或设备控制器的状况并将当前的状况通知给自动-id节点400。该通知可以周期性地发生或当状况反常时发生。设备管理系统525还能够支持远程管理，诸如固件上载和系统重新配制。
如图5B所示，自动-id节点400的后端系统集成层404、人力集成层408、以及节点集成层470分别处理与不同类型的后端系统530、用户接口540、和自动-id节点550的通信。
不同类型的后端系统530可以包括逻辑系统、资产跟踪和管理系统、维护服务系统、仓库管理系统、金融系统、分析系统和报告系统。而且以仓库管理系统为例，也可以有不同的实现，例如，Oracle实现和SAP实现。
不同类型的用户接口540能够包括基于网络或基于其它服务器的用户接口、独立用户接口，和移动接口。用户接口540还能够为不同的用户而被不同地配置。
自动-id节点550可以包括位于不同地理位置的节点。以供应链为例，节点可以位于制造场所、分配中心和零售中心。自动-id节点550可以包括由不同公司开发的不同自动-id系统的节点，例如可以从加州Mountain View的Verisign得到的EPCIS服务器以及可以从德国Walldorf(Baden)的SAP AG得到的Auto-ID节点。
在本说明书中，设备510、设备控制器520、设备管理系统525、后端系统530、用户接口540、以及自动-id节点550将被称作自动-id部件。
自动-id部件可以在各个方面不同，包括但不局限于通信协议的类型、通信信道、通信模式、或者所使用的消息格式。比如，一些自动-id部件可以使用HTTP(超文本传输协议)通信，而其它的可以使用基于套接字(socket)的通信协议，例如TCP/IP(传输控制协议/因特网协议)来通信。每种一般类型的通信协议还可以具有几种不同的变化。例如，一种公知的HTTP的变化是安全HTTP(HTTPs)。
对于TCP/IP来说，通信信道可以是发布商-订户信道、点到点信道或者套接字信道。例子有可以从纽约州Armonk的IBM获得的MQSeries、可以从马萨诸塞州的Bedford的Sonic软件公司获得的SonicMQ、可以从加州San Jose的BEA系统公司获得的WebLogic服务器以及可以从德国Walldorf(Baden)的SAPAG获得的XI。上述的大多数系统都同时支持发布商-订户信道和点到点信道两者。
对于HTTP来说，通信信道可以是SOAP(简单对象访问协议)和JSP(Java服务器页面)。
通信模式可以是在线通信模式或离线通信模式。在在线通信模式中，自动-id节点和自动id部件保持连续的连接。也就是说，即使当自动-id节点和自动-id部件不互相发送消息时，连接也保持开放(open)。在离线通信模式中，自动-id节点和自动-id部件不保持相互的连续连接。而是，它们例如只在发送消息时或者只当网络访问可用时临时连接。离线模式可由例如移动设备和移动用户接口使用。
如果没有集成层404、406、408、470，自动-id节点400将只能支持特定的通信协议、通信信道、通信模式、和/或消息格式，并且将不能与不使用该自动-id节点400所支持的特定通信协议、通信信道、通信模式和/或消息格式的自动-id部件集成。
使用集成层404、406、408、470，自动-id节点400能够与使用不同通信协议、通信信道、通信模式和/或消息格式的多种不同类型的自动-id部件集成。此外，如下所述，层404、406、408、470能够容易地被扩展以容纳未来开发的新的类型的自动-id部件。
如图6所示，集成层404、406、408、470的每个都包括适配器610、通信器620、和转换器630。
适配器610处理自动-id节点400与自动-id部件之间的通信。适配器610使用通信器620和转换器630来处理通信。
通信器620处理通信的数据传输方面。通信器620支持各种不同类型的通信协议、通信模式和通信信道，包括但不局限于前面所述的通信协议、通信模式、和通信信道。
转换器630处理通信的数据转换方面。转换器630将从连接的自动-id部件接收的数据转换成自动-id节点400能理解的内部消息格式。相反地，转换器640还将来自自动-id节点400的数据转换成连接的自动-id部件能理解的外部消息格式。
如图7所示，在集成层404、406、408、470的面向对象的实现中，适配器610可以由基础适配器类710和一个或多个特定适配器类720来表示。基础适配器类710实现对所有特定适配器类720通用的功能。特定适配器类720利用支持特定通信协议、通信信道、通信模式和消息格式的附加功能来扩展通用功能。
还可以使用类似的基础类和特定类组来实施通信器620和转换器630。通过将集成层404、406、408、470的功能分离成基础类和特定类，通用集成层404、406、408、470能够容易地扩展以容纳附加的特定通信协议、通信信道、通信模式和消息格式。
如图8所示，实施适配器610、通信器620、和转换器630的类可以被存储在类数据仓库810中。类数据仓库810可以位于集成层404、406、408、470之中(如所图示的)，或者作为替代，可以位于自动-id节点400能够访问的分离的位置。
对于每个将被连接到自动-id节点400的自动-id部件，适配器610的实例被产生并且被添加到由集成层404、406、408、470所维护的适配器实例列表820中。
产生针对给定的自动-id部件的适当适配器实例能够由人类操作员来手动执行。人类操作员可以检查自动-id部件并随后产生支持给定自动-id部件的特定通信协议、通信信道、通信模式、和/或消息格式的适配器实例。
图9是图4的自动-id节点400的实现的方框图。如图4中所讨论的，自动-id节点400包括处理事件消息的内核服务模块402。内核服务模块402可以包括事件消息分派器412、行为处理器414/426，规则引擎418、规则组420/422和数据管理模块423。内核服务402还可以包括处理自动-id节点400的相同或不同处理的其它模块。自动-id节点400还包括与外部模块通信的多个集成模块404、406、408和470。针对图5A、5B和图6在上面讨论了这种通信的例子。
在图9中，自动-id节点400包括动态加载用于在自动-id节点400中使用的部件的部件管理器902。换句话说，部件管理器902具有使能自动-id节点400添加新部件，或者在运行时间切换到使用不同的部件而不破坏自动-id节点400的操作的可扩展基础结构。
例如，部件管理器902可以被操作用于添加与新的类型的设备通信的新的适配器部件(例如图6的适配器610)，而不需要停止和重启自动-id节点400。在另一个例子中，部件管理器902可以被操作用以使用新的版本的数据转换器部件(例如与新版本的后端系统兼容的版本)在运行时间替换旧版本的数据转换器。结果，自动-id节点400在生产环境中被无缝地更新，以便与新版本的后端系统通信。
部件数据仓库904存储可以由自动-id节点400使用的多个部件。通过这样做，部件数据仓库904起到自动-id节点400的部件仓库的作用。部件数据仓库904例如可以包括对应于自动-id节点400与之通信的设备的多个适配器部件、以不同通信协议通信的多个通信器、转换不同格式数据的多个数据转换器、多个行为处理器(例如图4的行为处理器414)、或者多个规则和规则组(例如图4中的规则组420，422)。部件数据仓库904可以通过例如从外部后端系统或者从其它自动-id节点下载部件来获取部件。部件数据仓库904还可以去除自动-id节点400不再使用的部件。
部件加载器906可以基于在自动-id节点400接收的物品数据从部件数据仓库904加载部件。物品数据，通常指由自动-id节点402从各种外部模块404、406、408和470接收的数据，或者由自动-id节点400处理的数据。这种物品数据例如可以包括从设备112-118、设备控制器212-216或者设备管理器312接收的物品跟踪数据。物品数据还可以包括从其它自动-id节点、后端系统或用户接口接收的数据，并且可以例如包括规则或规则组、从后端系统接收的关于物品的数据或者由用户接口从人类操作员/管理员获得的数据。
部件加载器906可以如图9所示，对于部件管理器902来说是外部的。在其它的实现中，部件加载器906对于部件管理器902来说可以是内部的。
在一种实现中，部件加载器906在部件数据仓库904中搜索特定类型的部件。在一些实现中，部件加载器906还可以在自动-id节点400外部，例如在另一个自动-id节点、或在后端系统中进行搜索，以获取特定的部件。更具体地说，部件加载器906例如可以在接收SOAP消息时加载HTTP通信器部件，或者可以在接收套接字消息时加载TCP/IP通信器部件。
部件加载器906还包括配置设置文件908。配置设置文件908可以对于在自动-id节点400中的应用来说是外部文件，并且可以在该应用运行时被加载。配置设置文件908例如可以是文本文件格式或可扩展标记语言(XML)文件格式。配置设置文件908可以在第一次运用(deploy)自动-id节点时被定义，但是也可以根据需要改变。在一个例子中，配置设置文件908是可扩展的，以便可以添加新部件和它们的属性的定义。在另一个例子中，自动-id节点400可以使用配置设置文件908来改变部件的设置，而不需要重新编译这些部件。
配置设置文件908将部件登记到自动-id节点400。换句话说，配置设置文件908可以起到部件加载器906用来定位部件的地图的作用。例如，配置设置文件908可以包括部件在部件数据仓库904中的位置，或者，在自动-id节点400的其它实现中包括自动-id节点400之外的位置。配置设置文件908还可以指定部件的特定版本，诸如例如当前版本。配置文件908可以是一个文件，或者可以是存储或组织在不同位置的多个文件的形式。
在一些实现中，配置设置文件908可以定义在自动-id节点400中可以是主动的部件的选择的列表。部件加载器906可以在启动时基于选择的列表加载部件。而且，主动自动-id节点400可以通过拷贝上述的设置，即，在自动-id节点400的配置设置文件908中的主动部件的选择列表，在另一个自动-id节点被复制。
配置设置文件908还可以包括一些部件属性。例如，配置设置文件908可以提供实例化部件所需的一些部件属性数据。配置设置文件908还可以支持动态属性，其允许自动-id节点400对属性值进行改变而无需重新编译运行时间的部件。例如，零售商店的规则组可以包括用于一年中四季的规则。通过将属性“季节”设置为当前的季节例如“冬天”，自动-id节点400可以对所接收的事件应用冬天规则。
如在图5和6中所讨论的，集成模块404、406、408和470可以利用诸如RFID读取器适配器910、扫描仪适配器912和实质上任何其它适配器(在图9中用通用适配器x 914来表示)的不同的适配器610来与多个外部模块进行通信。部件管理器902可以基于来自外部模块的连接请求动态地加载所述适配器。例如部件管理器902可以在接收来自RFID读取器114的连接请求时加载RFID读取器适配器910。
而且，部件管理器902可以在运行时间向集成模块404、406、408和470动态加载主动适配器所需的其它部件。例如，部件管理器902可以为RFID读取器适配器加载通信器部件A 920和数据转换器部件C 924。同时，扫描仪适配器912可以使用通信器B 922和数据转换器C 926。同时，适配器x 914可以使用通信器B 924和数据转换器E 929。
在图9中，通信器B 922和通信器B 924是相同部件B的两个主动实例。换句话说，不同的适配器，即扫描仪适配器912和适配器x 914共享来自部件数据仓库904的相同通信器部件。例如，在用于设备、设备控制器和设备管理模块的很多适配器中可以公用TCP/IP通信器部件。
共享的部件提供在自动-id节点400的开发和维护中的更高效率。在这个例子中，只需要开发一个TCP/IP通信器部件。并且，部件数据仓库904只需要加载和存储这个TCP/IP通信器部件的一个拷贝。当在这个TCP/IP部件上实施改变时，只需要改变部件代码的一个拷贝。
如图9所示，实例920-929是主动实例。同样地，实例920-929是在数据处理模块，即集成模块404、406、408和470中运行的处理。然而，主动模式维持相对大量的实例可能导致自动-id节点400的处理能力和存储器使用的较重负荷，以致自动-id节点400可能相对缓慢地工作。因此，一些实例可以以被动形式存储。
例如，在图9中，被动实例池930可以存储大量的这种部件的被动实例。如刚刚提到的，被动实例是主动实例的静态形式。更具体地说，被动实例可以包括主动实例的数据和状态信息。结果，最新实例化的部件可以加载被动实例来重新生成相应的主动实例。
运行的部件，即主动实例，可以输出其被动实例并且将其存储在被动实例池930中。在另一方面，被动实例可以被输入到部件以重新生成该部件的主动实例。在一些实现中，被动实例可以被复制和传送到其它的自动-id节点或系统。因此，主动实例可以在其它地方被复制。
被动实例池930为自动-id节点400提供缓冲器以用于将其部分的工作负荷保留为非主动的，并由此，节省自动-id节点400的处理能力。结果，自动-id节点400通过着眼于有限数量的同时运行的主动实例来提高其性能。而且，当自动-id节点401同时接收到大量请求时，被动实例池可以通过串行化其工作负荷来避免自动-id节点401崩溃(crash)。
实例管理器931可以被用于管理在主动实例和在被动实例池中的被动实例之间的切换。实例管理器931对于每个功能模块，例如通信器620或转换器630来说可以是内部的。在其它实现中，实例管理器931对于功能模块可以是外部的。如图9所示，实例管理器931可以是数据处理模块的一部分，可以对于该数据处理模块来说是外部的。根据需要，可以有一个或多个实例管理器931。并且，在一些实现中，实例管理器931可以是部件管理器902或部件加载器906的一部分。
实例管理器931可被配置来定义可以在自动-id跟踪系统中允许的每个部件的主动实例的限制数量。如图9所示，实例管理器931可以定义适配器610可以具有3个主动实例，通信器620可以具有3个主动实例，而数据转换器630可以具有3个主动实例。
在自动-id节点的操作期间每个部件的主动实例的数量可以被配置以适应不同的情况。实例管理器931可以被操作来通过调整不同部件各自的主动实例的限制数量来优化在所述不同部件中其处理能力的分配。例如，实例管理器931可以授予负荷重的部件较高数量的有效实例，而授予没有那么活跃的部件较低数量的主动实例。
在一个特定的例子中，新适配器可以请求与自动-id节点400通信。实例管理器可以被配置成将部件适配器610的主动实例的限制数量增加到4，以便能够响应新适配器而无需去激活当前适配器RFID读取器适配器910、扫描仪适配器912和适配器914。而且，实例管理器可以被配置成减少通信器620或数据转换器630的主动实例的限制数量，以便容纳添加新适配器Y主动实例。
在一个实现中，自动-id系统中的部件，例如610、620和630可以保留附加的主动实例来协助在被动实例和主动实例之间进行切换的处理。结果，部件610、620和630可以保持常数数量的正在运行的主动实例而不会将时间浪费在等待被动实例被换入(swap in)。而且，附加的主动实例可以被用于将新接收的请求交换成被动实例，而不会为该交换任务而破坏现有主动实例的操作。
进一步在图9中，被动实例池930包括被动实例池A 932，其存储通信器部件A 920的被动实例。被动实例池C 934包括数据转换器部件C 924、928的被动实例。池A 934包括三个被动实例实例A1 936、实例A2 938和实例A3 940。这三个实例可以例如表示来自RFID读取器的三个通信请求。被动实例池C 934包括实例C1 942和实例C3 934，它们例如可以表示从RFID读取器适配器910和/或扫描仪适配器912接收的两个数据分组。
于是，图9的自动-id节点400的实现提供了灵活的基础结构，其将功能的描述与实现分离开来。结果，自动-id节点400能够切换到使用功能模块的不同实现，并且能够在运行时间添加功能模块的新的实现。该系统还使得多个功能模块能够共享和重复使用部件。而且，如图9所示，该系统允许自动-id节点400动态地改变功能模块的运行实例的参数。作为最终的例子，被动实例允许自动-id节点400管理其工作负荷，并允许使能复制和传送运行的功能模块的实例，即，部件的主动实例。
图10是配置设置文件908的方框图。配置设置文件908可以驻留在编译的代码，即，自动-id节点400的运行的系统之外，并且可以在运行时间被加载到系统。因此，配置设置文件908使能对自动-id节点400的动态配置，而不需要停止和重启自动-id节点400。配置设置文件908的内容展示了自动-id节点400的动态可配置特征。
一般来说，部件数据仓库904中的每个部件都在配置设置文件908中登记。每个部件的登记信息可以包括部件管理器902找到该部件所需的信息、在实例化该部件时所需的信息，并且在一些实现中，可以包括部件的可配置动态属性。由于配置设置文件908中的信息是可配置的，因此使得自动-id节点400能够动态加载来自配置的位置并且具有动态属性的部件。
参照图10，配置设置908示出了图9中被加载的部件的配置部分。一般来说，这种配置部分服务用于登记如上所述的每个部件的动态位置和属性、和/或驻留在部件数据仓库904中的该部件与一些其它部件之间的从属性。
为了列出几个例子，配置部分1002配置RFID读取器适配器910，而配置部分1004配置通信器A 920。配置部分1006配置数据转换器C 928，而配置部分1008配置扫描仪适配器912。配置部分1010配置扫描仪适配器912，而配置部分1012配置适配器x 914，配置部分1014配置通信器B 922、924，而最后配置部分1014配置数据转换器E 928。
部件W的配置部分1016和部件Y的配置部分是在图9中未示出的其它部件的配置部分的例子。在配置设置908中的部件注册表中还可以有用于其它部件的许多其它配置部分，为了清楚的目的，此处未示出所述其它部件。
在一个特定例子中，配置设置908中的配置部分1002存储部件RFID读取器适配器920的配置信息。该配置1002包括部件A的位置1020，例如，在部件数据仓库904中部件A驻留的路径。
而且，配置部分1002可以包括版本号1022，以便标识部件。部件RFID读取器适配器920可以具有多个版本，例如，每个版本在不同的时间被开发，并且可以和RFID读取器设备的不同模型兼容。部件管理器902可以将源RFID读取器设备的版本号与版本号1022进行匹配来确定是否加载在配置部分1002中登记的部件，即，RFID读取器适配器920。
在一些实现中，部件被以这种方式实施，以使得该部件的功能和实现被分离，并且使得对相同功能可以存在多个实例。例如，部件的功能可以由接口来描述。许多类可以实施该接口，并且自动-id节点400可以在其编译代码中参考该接口。配置设置908可以配置自动-id节点400以便在运行时间动态选择一个特定的实现，即，特定的类，以完成在该接口中定义的功能。在这个例子中，类名称1022被用于选择RFID读取器适配器920的期望实现。
搜索路径1024可以包括关于如果部件没驻留在部件数据仓库904中则到哪里去找到部件的信息。搜索路径1024可以描述自动-id节点400外部的部件的一个或多个可能的位置。例如，搜索路径1024可以包括远程机器名称和/或文件路径、相邻自动-id节点的标识或者到数据库或数据仓库的连接信息。
从属部件1026参考当前部件使用的一个或多个部件。在一个实现中，部件管理器902将从属部件与当前部件一起加载。在这个例子中，RFID读取器适配器920使用实例920的通信器部件A和实例922的数据转换器C。部件管理器902例如可以基于配置部分1004加载部件A和部件A的从属部件，基于配置部分1006加载部件C和部件C的从属部件，并且随后加载RFID读取器适配器910。
类似地，配置部分1008指示扫描仪适配器部件使用实例922、924的通信器B和实例928的数据转换器C。而配置部分1012指示实例914的适配器x使用实例922、924的通信器B和实例928的数据转换器E。在这个基础结构中，部件可以简单地通过改变其从属部件的属性容易地改变到使用不同的从属部件。
例如，实例928的部件数据转换器C和实例928的部件数据转换器E可以共享相同的数据转换器功能(例如，两个部件可以实现相同的数据转换器接口，并且因而可以相互交换)。适配器X通过简单地将配置部分1012的从属部件属性从E改变到C来改变为使用实例928的数据转换器C而不是实例929的数据转换器E。
属性1028-1032是RFID适配器的范例动态属性的列表。例如，属性A 1028可以指定RFID标签在它们的放置中是不可预料的，而因此RFID适配器可以激活其“判定取向模块”来处理每个标签。此后，属性A 1028可以被改变成指定RFID标签总是取向相同的方向(例如在扫描方法的某些改进后)，从而RFID适配器可以随后无需运行该“判定取向”模块而工作，并且可以因此具有改进的性能。类似地，属性B 1030、属性C 1032和潜在的其它属性，可以表示实例910的RFID适配器部件的其它可配置参数。
图10图示了一个例子，在其中，7个配置部分被用于7个部件，该7个部件在图9的自动-id节点400中是主动的。每个可以包括自动-id节点400中的部件的当前设置，即位置、属性、从属部件，和/或其它相关信息。当自动-id节点400工作时，配置部分可以被修改和被加载。如上所述，配置部分的内容示出了在自动-id节点400中的部件的动态可管理特征。
图11是在图9和图10的实现中使用的部件的生命周期的流程图。一般来说，如上面所解释的，部件是被实施来完成特定任务的功能程序模块。部件可以是一段代码、软件程序、类模块、指令组和/或脚本程序。部件可以驻留在开发机器、后端系统甚或另一个自动-id节点中。
如前面的例子所述，部件可以是集成模块402、404、406、470的适配器、通信器或者数据转换器。而且，部件可以是内核服务模块402中的规则组、行为处理器或者规则引擎。部件可以在数据处理模块中被实例化，数据处理模块例如可以包括自动-id节点400中的内核服务模块402、集成模块404、406、408和470、或其它模块。这种部件可以表示数据处理模块的动态部分，并且可以例如根据配置设置文件908在运行时间被加载。图9中的自动-id系统400的基础结构允许自动-id节点容易地适应新的部件。
在另一方面，例如可以包括事件消息分派器412、相关数据管理423、配置和经营管理440、存储和归档管理450以及集成模块404、406、408和470的一些部分以及部件管理器902和部件加载器906的数据处理模块的静态部分可以被看作是自动-id节点400的“主干”。当自动-id节点400开始其操作时，自动-id节点400的“主干”部分被加载。因此，对于“主干”的改变将需要停止和重启自动-id节点以便被运用。因此，如这里所讨论的，具有在自动-id节点中加载的“主干”部件而不需要运行时间的管理，增强了自动-id节点400的性能。
在图11的例子中，新部件X，例如用于新版本RFID读取器的适配器被开发并且准备好将被运用到自动-id节点400。自动-id节点400将部件X加载到部件数据仓库904(1102)。例如，自动-id操作员可以手动将部件X加载到自动-id节点，或者企业应用202可以指示自动-id节点加载来自特定机器的部件。在另一个例子中，相邻自动-id节点可以将部件X传播到自动-id节点400。
一旦部件X被物理加载到部件数据仓库904中，部件X就向自动-id节点400登记(1104)，以便部件加载器906能够找到并实例化新添加的部件X。在一个实现中，部件X的位置以及部件X的其它相关配置属性被添加到当前配置设置908。例如，配置部分1002可以被添加到配置设置文件908。因此，自动-id节点400准备好处理应该由部件X处理的请求。
一旦自动-id节点400接收到对部件X的请求(1106)，例如RFID读取器扫描标签并请求自动-id节点400处理该事件。自动-id节点400随后激活部件管理器902以加载部件X，即，实例910的RFID读取器适配器部件(1108)。部件加载器908查看配置设置文件908并且找到用于部件X的配置部分1002。使用例如位置1020、版本/类名称1022和/或搜索路径，部件加载器906可以从部件数据仓库904中找到部件X。在另一个例子中，部件加载器906可以从外部模块下载部件X。部件加载器906可以随后加载部件X的全部从属部件，例如实例920的部件A和实例928的部件C。
部件加载器906可以随后在集成模块404、406、408、470中实例化部件X及其从属部件(部件A和C)。例如，RFID读取器适配器实例910以及其从属部件的主动实例(即，通信器A 920和数据转换器C 926)可以在集成模块404、406、408、470中运行。现在，RFID读取器适配器实例910，以及通信器A 920和数据转换器C 926的主动实例现在处理来自在之前与自动-id节点400进行通信的RFID设备的请求。而且，更多的来自RFID读取器设备的请求可以这样由加载的部件X及其从属部件处理。在图12中会进一步讨论处理接收的请求的部件的主动实例的细节。
部件管理器902例如可以周期性地检查部件X是否完成了其所有实例的处理(1110)。在另一个实现中，部件管理器902可以检查主动实例X是否空闲了某个时段，并且如果是这样的话，部件管理器902可以卸载部件X(1112)。
图12是图9和图10的系统的部件实例的生命周期流程图。如前所述，实例指的是在处理物品数据的处理中部件的运行的拷贝。一般来说，实例的生命周期从该实例从部件以及物品数据被实例化开始。实例的生命在该实例完成对物品数据的处理时结束。主动实例一般需要自动-id节点400的处理能力。因此，自动-id节点400中的每个数据处理模块可以允许限制数量的主动实例同时存在。
如图9所示，在自动-id节点400中，实例管理器931和被动实例池930使得实例能够在其生命周期期间被保存在中间状态，即，被动实例状态，以便该实例可以被保留并在以后的某个时间被处理而不需要占用自动-id节点400的处理能力。
作为一个具体的例子，行为处理器部件的实例可以处理与物品数据相关的送货。在这个例子中，该送货行为处理器部件被设计成将所接收的RFID读取器事件与在企业系统中的发货文档相匹配。在接收到新RFID读取器事件时，即，当物品被RFID读取器设备扫描时，该送货行为处理器实例开始。送货行为处理器实例随后开始在一个或多个后端系统或数据仓库中进行搜索来寻找被扫描的物品的相应送货文档。如果该送货文档被找到，则该送货行为处理器实例进一步处理该送货文档，例如在送货文档中将该物品的状态更新为“接收到”。此时，送货行为处理器实例完成了其任务，并且其生命终止。
在一个例子中，搜索送货文档处理可能需要一些时间来完成。送货行为处理器实例可能将其生命时间的大多数时间花在等待搜索结果上。同时，RFID读取器可能扫描很多其它物品，并且可能初始化自动-id节点400中的送货行为处理器部件的许多新的实例。就同时的主动实例的数量是有限的这点来说，实例管理器931可以将某些实例保存为被动实例池930中的被动实例。在一些实现中，实例管理器931例如可以在相邻自动-id节点输出一些要被处理的被动实例，以缓解在自动-id节点400的工作负荷。
参照图12的流程图，自动-id节点400可以如图11所描述的，首先将部件X，例如送货行为处理器部件加载到部件数据仓库904(1202)。自动-id节点400接收对于部件X，例如送货行为处理器部件的请求(1204)。更具体地说，RFID读取器扫描物品并请求自动-id节点400处理该被扫描的事件。数据处理模块，即内核服务模块402，可以只允许部件X的一个主动实例。内核服务模块402检查是否已经存在运行的主动实例(1206)。换句话说，内核服务模块402检查是否还有空间来创建新的主动实例。
如果不存在主动实例，内核服务模块402在内核服务模块中实例化部件X的第一主动实例(1208)，然后开始处理接收的请求，即RFID扫描事件x。在另一方面，如果内核服务模块发现已经存在正在运行的部件X的实例(换句话说系统正忙)，则内核服务模块402可以为所接收的请求创建被动实例，并且将其存储在被动实例池930中(1210)。
可以有其它的实现，例如，内核服务402可以允许限制数量的主动实例同时运行。只有在在内核服务中的主动实例达到该限制数量时才可以将新的实例放到被动实例池930中。在再一个例子中，不能立即将新的实例放到被动池中，而是，现存的主动实例可以被换出到被动实例池930中，而新的实例被作为新的主动实例添加到内核服务模块402中。可以有其它的实例交换规则的实现。
当一个主动实例完成其处理时(1212)，内核服务402可以从被动实例池930换入下一个被动实例(1214)。处理检查是否该部件的全部被动实例都被处理过了，并且，如果是这样，则该实例的生命周期结束。
如果不是这样，主动实例继续处理1212和1214。在该处理期间，内核服务模块402可以接收被动实例的物品数据(1216)。例如，内核服务模块402可以接收对于物品的送货文档的搜索结果。与该物品相关的实例可能在被动实例池中。内核服务模块402可以随后将当前主动实例换出到被动实例池930(1218)，以便新的实例可以被换入。内核服务模块402可以随后找到与该物品相关的被动实例，并且将该被动实例换入到内核服务模块402中。
处理1212-1218继续，直到部件X的全部实例都被处理。最终，如图11所图示，部件X可以被卸载(1112和1114)。
如图12所示的动态管理的实例允许自动-id节点有效地管理其资源，例如其处理能力和存储器使用，以使得该自动-id节点能够以其自己的步调处理大量的请求。而且，通过将空闲的主动实例切换成被动实例，可以增强自动-id节点的性能。主动实例的可移植性可以协助向其它自动-id节点和/或系统分配工作负荷，并且可以协助测试自动-id节点的功能和性能。说明了多个实现。然而，应当理解可以进行各种修改。相应地，其它的实现是在所附权利要求的范围之内的。
权利要求
1.一种系统，包括自动-id节点，其可操作用来接收关于用于跟踪物品的自动-id跟踪系统的物品数据；数据处理模块，其在该自动-id节点中，可操作用于实施处理部件，以便在数据处理模块和自动-id节点的操作期间处理该物品数据；部件管理器，其可操作用来基于所述物品数据，从多个部件中确定处理部件；部件加载器，其可操作用于在该数据处理模块和该自动-id节点的操作期间将该处理部件加载到该数据处理模块。
2.如权利要求1所述的系统，其中，所述数据处理模块包括内核服务模块，其可操作用于处理在所述自动-id跟踪系统中的所述物品数据。
3.如权利要求1所述的系统，其中，所述部件加载器包括配置文件，其可操作用于基于与所述处理部件相关的配置设置向所述部件管理器输出指令，以用于确定该处理部件。
4.如权利要求1所述的系统，其中，所述数据处理模块包括集成模块，其可操作用于处理自动-id节点与自动-id跟踪系统的其它元件之间的通信。
5.如权利要求4所述的系统，其中，所述处理部件包括适配器，其适用于与自动-id跟踪系统的指定元件进行的通信。
6.如权利要求5所述的系统，其中，所述适配器包括通信器，其可操作用于管理包括指定的通信协议的所述适配器与所述指定元件之间的数据传输；和数据转换器，其可操作用于管理在由所述处理部件所使用的第一数据格式与由该指定元件所使用的第二数据格式之间的数据转换。
7.如权利要求1所述的系统，其中，所述处理部件与被主动实施的用于执行第一处理任务的主动实例以及不被主动实施的用于执行第二处理任务的被动实例相关。
8.如权利要求7所述的系统，包括用于将处理部件的被动实例与所述多个处理部件中的一个或多个的其它被动实例一起存储的池。
9.如权利要求8所述的系统，其中，所述数据处理模块包括实例管理器，其可操作用于基于对所述第二处理任务从不被主动实施到被主动实施的改变的确定，从所述池中激活被动实例并将该被动实例实施为第二主动实例。
10.如权利要求9所述的系统，其中，所述实例管理器还可操作用来基于对所述第一处理任务从被主动实施到不被主动实施的改变的确定，将主动实例去激活到所述池中以作为第二被动实例存储。
11.如权利要求1所述的系统，包括部件数据仓库，其可操作用来存储所述多个处理部件，以用于所述部件管理器或所述部件加载器从中进行选择。
12.一种方法，包括在用于跟踪物品的自动-id跟踪系统中的自动-id节点接收物品数据；分析该物品数据，以便从多个部件中确定用于处理该物品数据的处理部件；在数据处理模块和该自动-id节点的操作期间向该数据处理模块加载该处理部件；和使用该处理部件处理该物品数据。
13.如权利要求12所述的方法，其中，向所述数据处理模块加载所述处理部件包括将该处理部件加载到集成模块，该集成模块可操作用于处理该自动-id节点与自动-id跟踪系统的其它元件之间的通信。
14.如权利要求12所述的方法，其中，向所述数据处理模块加载所述处理部件包括加载适合用于与所述自动-id跟踪系统的指定元件通信的适配器。
15.如权利要求11所述的方法，包括加载所述处理部件的主动实例，以用于执行被主动实施的第一处理任务；和存储该处理部件的被动实例，以用于执行不被主动实施的第二处理任务。
16.如权利要求15所述的方法，包括基于对所述第二处理任务从不被主动实施到被主动实施的改变的确定，从所述池中激活所述被动实例，以将该被动实例实施为第二主动实例；和基于对所述第一处理任务从被主动实施到不被主动实施的改变的确定，将该主动实例去激活到所述池中以便作为第二被动实例存储。
17.一种装置，包括具有存储在其上的指令的存储介质，所述指令包括第一代码段，用于在用于跟踪物品的自动-id跟踪系统的自动-id节点接收物品数据；第二代码段，用于分析该物品数据，以便从多个部件中确定用于处理该物品数据的处理部件；第三代码段，用于在数据处理模块和该自动-id节点的操作期间将该处理部件加载到该数据处理模块；和第四代码段，用于使用该处理部件处理该物品数据。
18.如权利要求17所述的装置，其中，所述第三代码段包括第五代码段，用于将该处理部件加载到集成模块，该集成模块可操作用于处理所述自动-id节点与所述自动-id跟踪系统的其它元件之间的通信。
19.如权利要求18所述的装置，其中，所述第五代码段包括第六代码段，用于加载适合用于与自动-id跟踪系统的指定元件进行通信的适配器。
20.如权利要求17所述的装置，其中，所述自动-id跟踪系统可操作用于从多个跟踪设备自动收集所述物品数据，并且还可操作用于处理该物品数据，以便使得物品数据对于与该自动-id跟踪系统相关的企业应用和用户接口是可用的，并且对于该自动-id跟踪系统来说是可用的。
全文摘要
一种自动识别系统被描述为包括多个分布式自动－id节点，所述多个分布式自动－id节点可操作用来随着物理对象例如通过诸如供应链网络或销售网络的企业操作时跟踪这些物理对象。自动－id节点被分布在网络的所有站点，并且与诸如RFID读取器或者传感器设备的企业应用系统和/或数据获取系统通信。通过关注他们的各自站点，自动－id节点最小化由它们各自的企业应用跟踪的数据量。自动－id节点可以包括部件管理器，其动态加载用于在自动－id节点中使用的部件，而不会破坏自动－id节点的操作。例如，部件管理器可以被操作用于添加与新的类型的设备通信的新适配器部件，而不需要停止和重启自动－id节点。
文档编号G06K7/00GK1828646SQ20061005147
公开日2006年9月6日 申请日期2006年2月28日 优先权日2005年2月28日
发明者林涛, 斯蒂芬·戈贝尔 申请人:Sap股份公司