网关装置及数据处理方法
【专利摘要】本发明涉及一种网关装置及数据处理方法，尤其涉及智能建筑控制系统中的网关装置及数据处理方法。该网关装置具有：与用户进行通信的用户通信接口；用于进行与终端节点的通信的终端侧通信接口；存储关于设备的数据的存储器；和对数据和用户的命令进行分析处理，对数据交互进行控制的处理器，其中该处理器，当通过用户通信接口接收到来自用户的数据获取命令时，对命令进行分析，并检查存储器中存储的数据是否满足规定的要求，如满足规定的要求则将该数据直接向用户发回，如不满足规定的要求则通过终端侧通信接口向终端节点要求新的数据，并将从设备取得的新的数据向用户发回。
【专利说明】网关装置及数据处理方法
【技术领域】
[0001 ] 本发明涉及一种网关装置及数据处理方法，尤其涉及智能建筑控制系统中的网关装置及数据处理方法。
【背景技术】
[0002]随着科技发展和能源紧缺，智能化和节能化成为了现代楼宇建筑控制系统发展的趋势。在实现终端设备的可通信性能后，通过监控建筑管理所需的传感器及控制器的信息，建筑物内的所有系统(例如空调系统、安防系统、照明系统等等)都能够通过总控制台进行整合管理。由此，整个系统可以根据适当的控制方法提升舒适的室内环境和使用者的安全，并且能够确保建筑物节能效果和人力的节约。
[0003]进一步，在物联网推进的背景下，远程控制为使用者和管理者带来极大的便利，也成为该领域的重要应用场景之一。本地数据由物联网网关发送至互联网，从而实现用户的远程控制。
[0004]在此类系统中，大量监控数据给现有控制网络和运营商网络带来挑战。如何提高网络效率，减少网络拥堵，确保重要数据的传送成为亟待解决的问题。
[0005]针对这一问题，现有技术中提出了一些解决方案。例如，在专利文献I中，提出了一种机制，使用一个网关控制多个IP控制器，再经由IP控制器控制更多的终端设备，从而实现本地网络的控制命令分流，减轻网关的负载。
[0006]具体而言，在专利文献I中，该网关具有一个传输器和多个汇集器，可连接至一个或多个IP控制器，该IP控制器连接一个或多个网络设备。该传输器包括一个采集单元(用于采集每个IP控制器的负载信息)，一个控制指令收集单元(用于收集用户的控制指令)，一个决策单元(用于决策是否将指令发送至汇集器)，一个第一传输单元(用于指令至相应的汇集器)，和一个第二传输单元(从汇集器收集已汇集的控制指令)。该汇集器包括一个第三传输单元(从传输器收集指令)，一个汇集单元(汇集多条指令至一条控制指令)，以及一个第四传输单元(用于传输汇集控制指令)。当用户指令发送至网关后，传输器中的控制指令收集单元收到此指令，决策单元根据采集单元中的负载信息确定目的IP控制器，该控制指令从第一传输单元传输至汇集器。汇集器根据目的IP控制器的IP将指令从第四传输单元发送至设备。该网关可通过调控目的IP控制器，使下行网络中的过载情况减少。
现有技术
[0007]专利文献1:US7984135
【发明内容】
[0008]但是，在专利文献I中，仍然存在以下技术问题:
[0009](I)专利文献I虽然在网关内部设计了多个汇集器等指令处理单元，使指令能够发送至多个IP控制器，但并没有实际减少发送至网关的指令和网关发出的指令，无法减轻网关本身的通信负载。因此，专利文献I无法在减轻控制网关的负载和提高网关处理指令的效率上实现最优化。
[0010](2)专利文献I虽然通过使用多个IP控制器对网关至设备之间的通信数据进行了分流，但并没有实际减少设备侧网络中的指令数量，也没有减少设备所需发出的回复指令。即该数据分流未能减轻终端侧网络中的上行、下行数据流量。在具有大量终端设备的智能建筑控制网络中，终端侧网络更需要进一步优化。在此，专利文献I很难适用。
[0011](3)专利文献I并没有涉及终端设备侧回复数据的处理方法。在智能建筑中会涉及不同类型的传感器，尤其是具有警报信息类的传感器(例:火警烟感传感器)，对其所返回的数据也赋予不同优先级，使该数据能够快速返回至用户。对此类要求，专利文献I并不能够很好的实现。
[0012]如上所述，对于现有的智能建筑控制网络，如何提高网关的数据处理效率，减少网络拥堵，确保重要数据的传送将成为重要技术课题，以专利文献I为代表的现有技术并不能够很好的解决这些技术课题。
[0013]本发明用于解决上述课题，其目的在于，提供一种网关装置及数据处理方法，能够对该网关装置下发的指令数量进行优化，从而进一步减轻网关负载，提高网络效率。
[0014]另外，本发明的目的还在于，提供一种网关装置及数据处理方法，能够优化终端设备侧网络数据量，减轻终端设备侧网络的拥堵情况，最终实现整个控制网络的性能提升。
[0015]另外，本发明的目的还在于，提供一种网关装置及数据处理方法，能够保证警报类重要数据的快速返回。
[0016]为了实现上述目的，本发明提供一种网关装置，其能够与一个或多个用户进行数据交互，并直接或通过多个子网关与多个终端节点连接，多个终端节点的每一个管理一个或多个设备，该网关装置具有:与用户进行通信的用户通信接口 ；用于进行与终端节点的通信的终端侧通信接口 ；存储关于终端设备的数据的存储器；和对数据和用户的命令进行分析处理，对数据交互进行控制的处理器，该处理器，当通过用户通信接口接收到来自用户的数据获取命令时，对命令进行分析，并检查存储器中存储的数据是否满足规定的要求，如满足规定的要求则将该数据直接向用户发回，如不满足规定的要求则通过终端侧通信接口向终端节点要求新的数据，并将从终端设备取得的新的数据向用户发回。
[0017]另外，本发明还提供一种数据处理方法，利用网关装置进行数据处理，其中该网关装置能够与一个或多个用户进行数据交互，并直接或通过多个子网关与多个终端节点连接，多个终端节点的每一个管理一个或多个设备，该网关具有存储关于设备的数据的存储器，该数据处理方法包括以下步骤:接收用户发送至网关装置的数据获取命令，对命令进行分析，并检查存储在存储器中的数据是否满足规定的要求，如满足规定的要求则将该数据直接向用户发回，如不满足规定的要求则向终端节点要求新的数据，并将从设备取得的新的数据向用户发回。
[0018]根据本发明提供的上述网关装置及数据处理方法，能够使该网关下发的指令数量优化，减少终端设备侧网络数据量，减轻终端设备侧网络的拥堵情况，最终实现整个控制网络的性能提升。
[0019]进而，在本发明的数据处理方法中，分析设备数据的类型，并根据不同的类型，以不同的规则对数据进行处理后发送给用户。当设备数据为表示触发报警的报警类数据时，将发出设备数据的设备的数量发送给用户，当设备数据为日常维护类数据时，将对来自多个设备的日常维护类数据进行平均化处理后的综合信息发送给用户，从而进一步减少通过网关发送回用户的数据量。
[0020]由此，能够进一步使该网关上发的数据数量优化，减少整个智能建筑控制网络数据量，减轻网络的拥堵情况，最终实现整个控制网络的性能提升。
[0021]进而，在本发明的上述网关装置和数据处理方法中，还可以具有处理通信节点主动所发送数据的功能。在接收到设备数据时，在更新了存储在存储器中的关于设备的数据后对设备数据的类型进行判断，在判断为是表示触发报警的警报类数据时，主动向用户发送警报信息，并提取发出设备数据的设备的ID，向具备相同ID的终端节点发送数据获取命令，在接收到从终端节点发回的最新数据后更新存储在存储器中的关于设备的数据。
[0022]由此，在网关装置接收到重要数据和紧急数据(例如智能建筑控制中的火灾警报数据等)时，能够快速使用户接收到数据，确保了重要数据和紧急数据的及时传输，并且能够主动更新相关数据，使用户能够及时对此警情的事态进行确认。
【专利附图】
【附图说明】
[0023]图1是本发明实施方式I涉及的智能建筑控制网络系统的架构图。
[0024]图2是本发明实施方式I涉及的网关的结构框图。
[0025]图3是本发明实施方式I涉及的数据状态表的格式示意图。
[0026]图4是本发明实施方式I涉及的用户所发命令的格式示意图。
[0027]图5是本发明实施方式I涉及的网关数据处理方法的流程图。
[0028]图6是本发明实施方式I涉及的数据处理方法中数据判断步骤的流程图。
[0029]图7是本发明实施方式I涉及的网关返回用户数据的格式示意图。
[0030]图8是本发明实施方式2涉及的数据处理方法中数据返回步骤的流程图。
[0031]图9是本发明实施方式3涉及的节点主动发送时网关数据处理方法的流程图。
[0032]图10表示本发明实施例1涉及的命令格式。
[0033]图11表示本发明实施例1涉及的数据状态表具体格式。
[0034]图12表示本发明实施例1涉及的网关转发命令格式。
[0035]图13表示本发明实施例1涉及的更新后的数据状态表具体格式。
[0036]图14表示本发明实施例1涉及的网关返回用户数据的具体格式。
[0037]图15表示本发明实施例2涉及的网关返回用户数据的具体格式。
[0038]图16表示本发明实施例3涉及的数据状态表具体格式。
[0039]图17表示本发明实施例3涉及的网关发送用户数据的具体格式。
[0040]图18表示本发明实施例3涉及的更新警报数据后数据状态表的具体格式。
【具体实施方式】
[0041]1、实施方式I
[0042]以下结合图1?图7说明本发明的实施方式I。本实施方式I是在智能建筑控制网络中减少网关转发命令从而减轻网络拥堵的实施方式。
[0043]首先，简单说明本实施方式I的整体构思。即，在分析现有技术中对智能建筑控制网络的改进方法后可以发现，在网关和设备之间加入IP控制器可以分流网关的数据，增加网络可控设备数量。但此架构并不能够减少网关实际发出的命令，也并不能减少终端设备网络之间的数据流量。另一方面，仅仅在网关内部增加多个汇集器转发指令也并没有优化网关的处理功能。本实施方式I通过在网关内部加入一个存有数据状态表的存储器和具有相应处理功能的中央处理器，从而实现减少网关发出的命令，减轻整体网络的拥堵情况。表示数据状态的数据不限于数据状态表的形式，只要是能够存储在存储器中并起到相同作用的数据即可。以下，具体说明本实施方式I涉及的智能建筑控制网络。
[0044]1.1、智能建筑控制网络
[0045]图1是本发明实施方式I涉及的智能建筑控制网络的架构图。如图1所示，实施方式I涉及的智能建筑控制网络由至少I个网关101，若干个子网关102，以及子网关所连接的若干个通信节点103，和节点所管理的一个或多个传感器104构成。这里的网关101可与本地用户105或公共网络所连接的用户106进行数据交互，此处的用户105和用户106可为单个或多个，根据网络管理或用户的需要进行部署。在设备数量较大的网络中，子网关102可以分流网关101的数据，起到减少网络拥堵，支持更多设备的作用；在设备数量较少的网络中，也可以不采用子网关102，使用网关101直接与节点103连接的架构。通信节点103具有IP地址，其连接一个或多个含有ID的传感器104。每个通信节点103所管理的传感器104可以为不同类型也可以为相同类型。传感器104的分布取决于建筑网络部署中的便捷和易于管理等因素。
[0046]在实施方式I的智能建筑控制网络中，当用户a或用户b需要获取网络中某种数据时，先发送数据获取命令至网关101。网关101在接收此命令后对命令进行相应的处理，并决策是否下发命令。其决策取决于网关接收的命令信息、网关所存储的数据等多个因素。如下发命令则等待节点发回数据后对数据进行处理，如不需下发命令则直接对数据进行处理，最终返回数据至相关用户。在实施方法I中，网关的结构框图和数据处理流程将在下文详细介绍。
[0047]以下首先说明智能建筑控制网络的各组成部分。
[0048]1.1.1、网关 101
[0049]网关101为此智能建筑控制网络中的核心部件，即本发明所涉及的重要设备。网关101负责收集本地用户105及通过公网连接的用户106所发送的命令，并处理该用户命令，按照其中相关信息提取网关所存储的数据状态表中的相关数据。该数据状态表保存在网关101的存储器中，其详细格式将在下文介绍。网关按照此数据状态表中的数据，进行数据判断步骤，按照已存的固定策略，判断是否向其管理的终端设备网络中的通信节点发送命令。依照此命令所返回的数据或本地所存数据根据用户IP，将相关数据返回至用户。
[0050]1.1.2、子网关 102
[0051]子网关102为此智能建筑控制网络中的非必要设备。在网关需要控制大量通信节点时，或考虑到网关部署时的距离、楼层等问题，该子网关的加入可以使本智能建筑控制网络实现控制和部署更便捷。子网关102具备基本的数据转发功能，可管理一定数量的通信节点，本身具备网络中唯一的IP地址。在子网关102接收到网关101所发送的单播或组播命令时，可根据通信节点IP将此命令转发至相应的节点。另一方面，子网关102也可以接收其管理的通信节点所发送的数据，并将其转发至网关101。子网关102可具备和网关101相同的功能，也可仅支持部分功能。子网关102与其管理的通信节点的通信方式可以为无线通信方式。在某一子网关102故障或关闭时，其管理的通信节点可以自主连接至周围的其他子网关进行接入。
[0052]1.1.3、节点 103
[0053]节点103在此智能建筑控制网络中可视为重要组成部分。该节点具有通信接口，可与网关或子网关进行通信。该节点具有网络中唯一的IP，并依次进行区分。每个节点103可以管理一个或多个不具备IP的传感器，将传感器获取的数据通过网关101发送至用户。该数据发送模式可以为用户请求时的被动发送方式和无用户请求时的主动发送方式。该节点与网关101或子网关102的通信方式可以为无线通信方式，在节点部署允许的情况下可以支持多跳通信模式。在网关初始配置后，节点103接入某一子网关102或网关101，在其接入的网关102发生故障或关闭时，节点103可以通过自主寻找，接入周围其它子网关102，以保证网络的正常运行。
[0054]1.1.4、传感器 104
[0055]传感器104为网络中设备终端，具备数据获取或命令执行功能。例如在智能建筑控制网络中的温度传感器、湿度传感器、气体检测传感器、火警烟感传感器、控制开关、门禁警报传感器，等等。传感器104因其数量巨大，在此智能建筑控制网络中不具有单独的IP，而是由通信节点103进行管理，通过其ID进行区分，从而保证一个通信节点103下不会有重复的传感器ID。传感器104可以不具有通信接口，与节点103置于一个物理设备中，也可以通过串口等方式与节点103进行数据交互。
[0056]1.1.5、用户 105 与用户 106
[0057]本智能建筑控制网络中支持本地用户105及远程用户106两种用户访问模式。用户105可与网关101、子网关102、节点103和传感器104处于一个局域网内，从内部进行数据获取或命令发送。该模式适用于大厦物业等管理用户使用。用户106可通过公共网络对网关101进行数据交互，从而使用远程的方式对楼内数据进行获取或控制。该模式适用于楼内具体用户，可以方便快捷的获取或管理传感器数据。
[0058]1.2、网关101的结构
[0059]图2为上述网关101的结构框图。网关101至少具备中央处理器201、存储器202、用户侧通信接口 203及终端侧用户接口 204。
[0060]中央处理器201具有一定的运算功能，并具有预编程的数据处理模块，能够对网关101接收到的用户命令进行处理和分析，并且能够对此命令进行决策以决定是否下发此命令。另一方面，此中央处理器能够对接收到的用户数据进行处理和分析，以决策是否上发此数据。其涉及的具体分析决策流程将在下文详细介绍。
[0061]存储器202具有相应的数据存储功能，并存有一定格式的数据状态表。该状态表中的各项数据将根据接口 204获得的终端数据进行实时更新。此数据状态表将成为中央处理器201决策时的重要依据。
[0062]用户侧通信接口 203用于和用户105或用户106进行数据交互，获取用户命令，并发送数据至用户。
[0063]相应的，终端侧通信接口 204用户和子网关102、通信节点103进行通信，获取节点数据，并发送命令至子网关或节点。[0064]1.3、数据状态表格式
[0065]图3表示上述存储器202中所存数据状态表的格式。其数据项目包含:节点IP、传感器ID、应用类型号、更新时间、有效期、数据内容。
[0066]其中节点IP为网络中通信节点103的IP，每个节点的IP在网络中具有唯一性，网关根据此IP进行命令分析和决策管理。此IP可以为本地IP或公网IP，具体取决于本智能建筑控制网络的部署情况。
[0067]传感器ID为每个传感器在其节点下的唯一性区分标示，网关保存此信息，可以根据不同传感器进行命令的单播或组播发送，从而便捷获取一组传感器数据或单独的传感器数据。
[0068]应用类型号为本发明所定义的变量。本发明对智能建筑控制网络内的数据进行了分类处理:凡有害气体检测传感器、火警烟感传感器、门禁警报传感器等获取的数据定义为警报类数据，在此数据状态表中以I类数据划分，标示为01 ;凡温度传感器、湿度传感器、CO2检测传感器、控制开关等获取的数据定义为日常维护类数据，在此数据状态表中以2类数据划分，标示为02。在以后如技术不断进展，有其他类数据，此分类可进行相应的修订。定义了应用类型可以更便捷的控制智能建筑控制网络内部的传感器设备，并可以由不同的类别划分不同的优先级及处理方法。在本发明涉及的数据处理流程中将详细介绍。
[0069]更新时间标示此条数据所发出的时间信息。在智能建筑控制网络中，存有此信息可以方便的使网关或用户获知其获取的数据是否满足要求。
[0070]有效期标示此条数据的有效期限。例如警报类数据，由于其实时性的重要特性，有效期小于一定阈值；又如日常维护类数据，其实时性并没有警报类数据重要，频繁的更新将造成网络拥堵。因此有效期将帮助终端设备网络的数据更合理更有效的进行更新，此类别也是网关决策时考虑的重要参数之一。
[0071]数据栏存有本条数据的实际数据值。例如温度传感器的数据为温度值，又如警报类传感器可以用0、1来标示警报讯息的无、有，依此类推。
[0072]1.4、用户发送命令格式
[0073]图4举例说明了本实施方法中用户发出命令的格式。典型的用户命令具备:
[0074]用户IP，用于网关发回命令时的目的地址；
[0075]网关IP，用于网关确认此条命令是否为本网关所接收信息，或确定此命令是否仅对应网络中某子网关；
[0076]节点IP，如消息中具备节点IP，则为单播命令，网关将按照数据状态表中对应IP的节点数据进行决策并发回至用户，如消息中未注明节点IP，网关将按照下一位命令类型进行决策并发回；
[0077]命令类型，与数据状态表中的类型号相匹配，类型I为警报类数据的获取，类型2为日常维护类数据的获取；
[0078]命令内容，为用户发送命令的实际内容；
[0079]发送时间，此信息标示用户发出命令时的时间，用于网关决策数据有效期时使用。
[0080]在此举例，如一条用户命令为:
[0081][201.0.0.1] [203.0.0.1] [01] [GET] [12:36]
[0082]即可视为IP地址为201.0.0.1用户需要获取IP地址为203.0.0.1的网关下所有警报类传感器的数量，其发送时间为12:36。
[0083]1.5、网关中央处理器的数据处理流程
[0084]图5为网关101的中央处理器201中具有的数据处理模块中预存的典型数据处理流程。
[0085]如图5所示，首先步骤501中网关从用户处获取到命令。该命令格式可以是1.4中所示的格式。在获取命令后，网关对命令进行解析，将用户IP存储至存储器，将网关IP与本机IP和本地路由表中子网关的IP进行对比，如目的地址为本机IP则进行下一步解析，如目的地址为子网关IP则转发命令至对应子网关。此后，进行对命令类型和命令时间的解析，并按此命令类型进行下一步骤。
[0086]步骤502为数据状态表查询步骤，在步骤501中，网关已提取出命令类型。在此步骤中，网关根据此类型号，在数据状态表中抽取所有同类型数据，此命令类型对应表中的应用类型。如表中不具备此类型数据，则直接向用户返回无数据信息。如表中具备此类数据，则进入数据判断步骤503。
[0087]步骤503为数据判断步骤，其判断过程如图6所示，根据步骤601-604来实施。此判断步骤的目的是检查数据状态表中的数据是否满足要求，如满足要求可直接向用户发回，如不满足要求则向节点管理的传感器要求新的数据来返回。此步骤的目的是减少网关下发命令数量，减轻终端侧网络的拥堵情况，并且进一步减少了用户端等待时间。对每一条在步骤502中提取的数据，将进入步骤601的计算数据存活期Te步骤。数据存活期Te的计算公式如下所示:
[0088]Te=(命令时间)-(数据时间)
[0089]此处命令时间为用户所发命令的时间，而数据时间则为数据状态表中该条数据的更新时间。存活期Te表示了这条数据自发出到用户要求时的时间段。
[0090]此后进行判断步骤602，网关将判断数据存活期是否小于有效期。此逻辑关系的意义在于，如果存活期小于有效期则表明此条数据的存活时间是小于有效期限阈值的，即为有效；如果存活期大于有效期则表明此条数据存活期较长，大于有效期阈值，即为无效。对有效数据可直接进入数据返回步骤504 ;对无效数据还进行下一步数据更新步骤。
[0091]步骤603则为网关据此数据的节点IP发送数据获取命令，并在接收后更新数据状态表，使用更新后的数据进入下一步数据返回步骤504。
[0092]在数据返回步骤504中，网关根据预存的用户IP和数据状态表中的数据构造返回数据包，并将此数据包发回至用户。
[0093]1.6、网关返回用户的格式
[0094]在上述命令和数据处理流程后，网关返回数据至用户。图7表示返回用户的数据格式的一个范例。
[0095]如图7所示，此数据包具备:
[0096]所发数据的网关IP，表明源地址；
[0097]用户IP，表明目的地址；
[0098]数据内容，负载为用户所需的数据；
[0099]发送时间，此时间可注明此条数据的时间信息。
[0100]在此举例，如一条用户命令为1.4中所示格式的命令，其获取数据可能为:[0101][203.0.0.1] [201.0.0.1] [O] [12:38]
[0102]即可视为IP地址为203.0.0.1的网关向IP地址为201.0.0.1的用户所返回的数据标示网关203.0.0.1下所有警报类传感器均无警报信息，其发送时间为12:38。
[0103]1.7、效果
[0104]根据本发明的实施方式I，能够减少网关下发命令数量，进一步减轻终端侧网络的拥堵情况，并且进一步减少了用户端等待时间。
[0105]2、实施方式2
[0106]以下结合图8说明本发明的实施方式2。本实施方式2是在实施方式I的基础上追加了对返回数据进一步综合处理的实施方式。
[0107]首先，简单说明本实施方式2的整体构思。即，考虑到智能建筑控制网络中，用户的组播命令需求，网关需要对单播和组播命令分别予以回复。对于单播数据，网关可直接将数据回复至用户；而对于组播命令，回复多条数据至用户并不是最优方式。进一步优化此通信过程，减少网络拥堵。对于此需求，本发明提供实施方式2。
[0108]在本实施方式2中，网关的结构图和所需的数据状态表及图5所示的主要处理流程与实施方式I 一致，在此不做赘述。以下，详细说明本实施方式2中的数据返回步骤504的流程及数据处理方法。
[0109]2.1、组播与数据综合值
[0110]在智能建筑控制网络中，用户经常会需要用到组播命令。例如用户需获取本层楼的实时温度，又如一层楼所具有的温度传感器约为数十个左右。如果网关仅支持单播命令，用户每次仅能获取每一个传感器的温度，最终观察平均温度，此过程十分繁琐。如支持组播命令，用户可根据本层楼的网关IP，发送一条组播命令，楼层中所有具备温度传感器的节点均可获取此命令，并返回每一个传感器的实时温度。此时由用户发出的命令数量大量减少，从用户到网关的通信过程将会大大优化。进一步，所有温度传感器的节点温度均值计算过程可由网关来完成，从网关到用户也仅发送一条回复数据。此时由网关返回用户的数据量也会大量减少，此时用户至网关之间的数据交互已达最优。
[0111]用户所发命令的格式如图4所示，如其具备节点IP则表明需获取特定的某一节点中传感器的数据。如其不具备节点IP，仅具备网关IP则表明需获取该网关下所有某应用类型的数据综合值。此数据综合值的优化目的为多条数据优化至一条，此数据综合值的计算过程由网关来完成。
[0112]2.2、数据返回步骤的流程
[0113]如图8所示，在网关执行数据处理流程中数据判断步骤503结束后，进入数据返回步骤504。此时网关可根据不同的应用类型对不同的数据进行综合处理。
[0114]步骤801为解析数据的应用类型步骤，此步骤中判断该条数据类型为警报类数据或是日常维护类数据。
[0115]步骤802为不同应用类型的跳转判断，如为警报类数据则进入步骤803-804过程，对警报类传感器进行遍历，计算其中触发警报的数量，最终将总数发送至用户；如为日常维护类数据则进入步骤805-807过程，对不同传感器ID即不同传感器类别的数据进行平均值计算，最终将综合信息发送回用户。
[0116]2.3、效果[0117]根据本发明的实施方式2，能够减少网关下发命令数量的基础上减少网关与用户之间的信息数量，进一步减轻网关的负载及整个网络的拥堵情况，并且进一步提高了用户使用的便捷性。
[0118]3、实施方式3
[0119]以下结合图9说明本发明的实施方式3。本实施方式3追加了节点主动发送数据时网关数据处理流程的实施方式。
[0120]首先，简单说明本实施方式3的整体构思。即，考虑到智能建筑控制网络中，警报数据的实时性需求。对于日常维护类数据，其时间要求范围较宽，可以由网关定期发起更新，存入数据状态表，经由用户的获取命令返回至用户；而对于警报类这种重要数据所需求的时效性要求十分高，如等待用户获取将会造成不及时处理的不良后果。
[0121]对此需求，本实施方式针对不同数据的应用类型进行相应的处理，特别的是对警报类数据进行实时上发，并进一步更新网内相关数据，为用户的监控和管理带来便利。
[0122]3.1、警报类数据处理方法
[0123]在智能建筑控制网络中，有害气体检测传感器、火警烟感传感器、门禁警报传感器等获取的数据定义为警报类数据。该类传感器的特点为实时监控，遇到超过阈值时，将被触发，产生数据。此类传感器的数据多采用主动发送式，触发后发送警报至网关。对于警报类重要数据所需求的时效性要求十分高，如果未能及时交由用户则会造成不良后果。
[0124]因此网关对此类数据具有合适的处理方法，以保证警报类数据能够实时告知用户，便于用户知晓警情。在此基础上，用户至少保存I个管理端IP至网关，便于网关获取到此类数据能够将数据发送至此IP。
[0125]另外，考虑到单个传感器可能会发生故障的情况，用户对警报类传感器的数据可能会进行再次确认或排查。另一方面，对火警烟感传感器等预警信息，用户再次获取此类警情的覆盖范围情况，便于更好的处理和排查。因此由网关对这类紧急数据快速更新，便于用户二次获取数据。本实施方式中，网关接收到警报类数据后，将在发送本数据至用户后，解析传感器ID，对网络中此类传感器的数据进行更新，以获取最新数据情况。
[0126]3.2、日常维护类数据处理方法
[0127]对温度传感器、湿度传感器、CO2检测传感器、控制开关等获取的数据定义为日常维护类数据。此类传感器的特点为非触发式，且定期更新数据，上发至网关。此类传感器采集的数据对实时性要求不高，可由用户主动问询式获取或定期主动发送。
[0128]用户主动问询式的处理方法可见实施方式I及实施方式2。本实施方式对定期主动发送数据的处理方法进行了描述。
[0129]如网关接收到节点主动发送的日常维护类数据，则接收后更新相对应的数据状态表中的数据，随后结束。
[0130]3.3、节点主动式数据处理流程
[0131]根据上述节点主动发送的警报类数据和日常维护类数据的处理方法，可归纳出如图9所示的节点主动式数据处理流程。如图9所示:
[0132]步骤901为接收数据步骤，在此时本流程被触发开始；
[0133]步骤902为更新数据状态表步骤，网关接收数据后根据数据的节点IP、传感器ID等信息更新相应的数据状态表中的数据；[0134]步骤903为应用类型判断步骤，网关在更新数据后对其应用类型进行提取，并进行判断:如为日常维护类数据，则直接结束，如为警报类数据则进入下一步骤904 ；
[0135]步骤904为发送数据步骤，此步骤中网关将此条警报类数据发送至预存警报管理IP，其发送格式可参考实施方式I中的发送消息格式；
[0136]步骤905为提取传感器ID步骤，在发送警报信息后，考虑到用户的二次获取可能性以及警报类数据的实时性要求，提取此条数据的传感器ID ；
[0137]步骤906则根据步骤905中提取的传感器ID，向终端侧网络中具备此传感器ID的节点发送数据获取命令，等待接收最新相关警报类数据；
[0138]步骤907为接收更新数据步骤，在接收到节点发回的最新数据后，依次更新数据状态表，等待用户的下一步命令。
[0139]3.4、效果
[0140]根据本实施方式3，在网关接收到重要、紧急的警报类数据(例如智能建筑控制中的火灾警报数据等)时，能够快速地将此数据上报至用户，确保了重要数据和紧急数据的及时传输。
[0141]在上述实施方式1-3中，以智能建筑控制网络中的网关装置及数据处理方法为例说明了本发明的网关装置及数据处理方法，但是本发明不限于应用在智能建筑控制网络中。在存在多个终端节点的网络中均能够采用本发明的网关装置及数据处理方法来减少网关装置下发命令的数量，优化终端设备侧网络数据量，减轻终端设备侧网络的拥堵。
[0142]4、实施例
[0143]以下，结合图f图13说明本发明的三个实施例。
[0144]4.1、实施例1
[0145]本实施例基于上述实施方式I。
[0146]首先，在网络的初始化过程中，网关101、子网关102、节点103包括其管理的传感器104被开启。随后节点103自主寻找子网关102或网关101，请求接入网络。子网关102也自主寻找或已被连接至网关101。从而形成终端侧网络。该网络可以通过网关经由本地用户105或远程用户106管理。
[0147]该网络中，此处的用户105和用户106可为单个或多个，取决于网络管理或用户的需要进行部署。在设备数量较大的网络中，子网关102可以分流网关101的数据，起到减少网络拥堵，支持更多设备的作用，数量可根据具体情况部署，支持多个子网关102 ;在设备数量较少的网络中，也可以不采用子网关102，使用网关101直接与节点103连接的架构。子网关102与网关101之间的网络支持现有技术中的典型星型或树形等拓扑结构，在本发明中不进行详细讨论。通信节点103为具有IP的通信设备终端，其连接一个或多个含有ID的传感器104，连接方式可为串口或总线连接。每个通信节点103所管理的传感器104可以为不同类型也可以为相同类型，在本实施例中考虑较为复杂的不同类型的传感器。传感器104的分布取决于建筑网络部署中的便捷和易于管理等因素。
[0148]在初始化后，网络内所有节点103对其管理的传感器设备的数据进行首次获取，并发送至网关101，网关101根据这些数据来构造数据状态表，如图3所示。对应每条数据，具备节点IP、传感器ID、类型号、数据的更新时间、数据的有效期以及数据本身。对于类型号，根据传感器ID，由网关101来定义其应用类型。在此本发明对智能建筑控制网络内的数据进行了分类处理:凡有害气体检测传感器、火警烟感传感器、门禁警报传感器等获取的数据定义为警报类数据，在此数据状态表中以I类数据划分，标示为01;凡温度传感器、湿度传感器、CO2检测传感器、控制开关等获取的数据定义为日常维护类数据，在此数据状态表中以2类数据划分，标示为02。在以后如技术不断进展，有其他类数据，此分类可进行相应的修订。更新时间标示此条数据所发出的时间信息。在智能建筑控制网络中，存有此信息可以方便的使网关或用户获知其获取的数据是否满足要求。有效期标示此条数据的有效期限。例如警报类数据，由于其实时性的重要特性，有效期小于一定阈值；又如日常维护类数据，其实时性并没有警报类数据重要，频繁的更新将造成网络拥堵。因此有效期将帮助终端设备网络的数据更合理更有效的进行更新，此类别也是网关决策时考虑的重要参数之一。数据栏存有本条数据的实际数据值。例如温度传感器的数据为温度值，又如警报类传感器可以用0、1来标示警报讯息的无、有，依此类推。
[0149]数据状态表首次建立以后，根据节点的定时发送或用户命令主动获取数据等方式进行更新，从而保证数据的实时性。
[0150]随后，以用户b为例，假设此时用户b需要了解该建筑内的安防情况，即需要获取该网络中的警报类传感器的综合情况，例如多少个警报器已处于警报状态这样的信息。
[0151]此时用户先发送该数据获取命令至网关101。由于网关内部存储器已对相应的应用类型的设置进行保存，因此可以支持图4中所示的命令类型。如用户的IP为201.0.0.1,目的网关的IP为203.0.0.1，发送时间为12时36分。此时用户可根据相应的浏览器或web管理工具进行数据获取命令发送，其发送方式可由现有技术中的相应技术实现，在此不做详细讨论。该命令中所具备的必要因素可构成该条命令的典型格式，如图10所示。
[0152]网关101在接收图10所示的命令后由中央处理器201对命令进行相应的处理，其处理步骤由图5所示。首先步骤501表示中央处理器201从用户侧接口 203获取到命令。在此步骤中，中央处理器201还对命令进行解析，将用户IP201.0.0.1存储至存储器202，将网关IP203.0.0.1与本机IP和子网关IP列表进行对比。如网关IP为本机IP则进一步提取命令类型存入存储器，进行步骤502 ;如网关IP为某个子网关的IP，则通过接口 204转发命令；如网关IP与这些均不匹配，则丢弃命令，并返回错误信息。在此实施例中，网关IP与本机IP —致，中央处理器201提取命令类型01存入存储器，并进入下一步骤502。
[0153]随后进行的步骤502为数据状态表查询步骤。首先中央处理器201根据上一步骤中存储的命令类型01，在存储器202所存储的数据状态表中抽取所有同类型数据，按照命令类型对于表中的类型号。在如图3所示的数据状态表中，被抽取的数据如图11所示。在此实施例中，满足相同类型的数据有3条，将进入下一步数据判断步骤503。如果本步骤中没有满足要求的数据，即表中不具备此类型数据，则向用户发回错误信息，并终止程序。
[0154]数据判断步骤503为本发明关键步骤之一，其判断过程如图6所示。此判断步骤的目的是检查图11的被抽取的数据状态表中数据是否满足要求，如满足要求可直接向用户发回，如不满足要求则向节点管理的传感器要求新的数据来返回。此步骤的目的是减少网关下发命令数量，减轻终端侧网络的拥堵情况，并且进一步减少了用户端等待时间。对每一条在步骤502中提取的数据，将进入步骤601的计算数据存活期Te步骤。数据存活期Te的计算公式如下所示:
[0155]Te=(命令时间)-(数据时间)[0156]此处命令时间为用户所发命令的时间，而数据时间则为数据状态表中该条数据的更新时间。存活期Te表示了这条数据自发出到用户要求时的时间段。
[0157]对图11所包括的三条数据，对应命令时间12:36其Te的计算结果如下所示:
[0158]10.0.0.1 01 Te=4
[0159]10.0.0.2 01 Te=I
[0160]10.0.0.18 01 Te=I
[0161]此后进行判断步骤602，中央处理器201判断数据存活期是否小于有效期。此逻辑关系的意义在于，如果存活期小于等于有效期则表明此条数据的存活时间是小于有效期限阈值的，即为有效；如果存活期大于有效期则表明此条数据存活期较长，大于有效期阈值，即为无效。对有效数据可直接进入数据返回步骤504 ;对无效数据还进行下一步数据更新步骤。因此对图11中3条数据的进一步判断如下所示:
[0162]10.0.0.1 01 Te=4 中有效期为 3，Te>3，进入步骤 603 ；
[0163]10.0.0.2 01 Te=I 中有效期为 3，Te〈3，进入步骤 504 ;
[0164]10.0.0.18 01 Te=I 中有效期为 3，Te〈3，进入步骤 504。
[0165]步骤603中，中央处理器构造命令，发送至IP为10.0.0.1的节点，其命令格式可以图12中格式为范例。随后步骤604中，中央处理器根据节点10.0.0.1所返回的数据更新数据状态表中相应的位置，在此实施例中，图3和图11的相应数据均要更新。令该条数据进入下一步骤504。
[0166]此时所提取的数据表如图13所示。
[0167]在数据返回步骤504中，中央处理器将根据已存的用户IP =201.0.0.1和图13中数据状态表中的数据构造返回数据包，并将此数据包发回至用户。其发回数据格式的范例参照图7。如图14所示，包含网关IP:203.0.0.1，用户IP =201.0.0.1，数据:10.0.0.1/1;
10.0.0.2/0; 10.0.0.18/1，发送时间 12:37。
[0168]用户获得此数据后，可以获知此网络即此建筑内，每个警报传感器是否被触发。在传感器数量较大时，用户仅发送一次命令即可获得全面信息，并交由网关判断获取或发送已存储的数据，大大提高用户使用的便利性和效率。如所有数据均在有效期内，用户可即刻获得网络内传感器的数据，而不用等待网关进一步转发、获取传感器数据。
[0169]以此实施例为例可以看出，采用本发明的数据状态表及相应的数据查询和判断步骤，可以减少网关101转发命令的次数，减轻了终端侧网络的拥堵情况。
[0170]4.2、实施例 2
[0171]本实施例基于上述实施方式2。
[0172]首先，简单说明本实施方式2的整体构思。即，考虑到智能建筑控制网络中，用户的组播命令需求，网关需要对单播和组播命令分别予以回复。对于单播数据，网关可直接将数据回复至用户；而对于组播命令，回复多条数据至用户并不是最优方式。以实施例1为例，可以看出最后网关所返回用户的信息中，所包括信息量很大，在某些通信协议或环境受限时，往往需要进行分包发送。因此，进一步优化此通信过程，将返回数据的数据进行优化，减少网络拥堵。对于此需求，本发明提供实施方式2，并以此提出实施例2。
[0173]在本实施例2中，网关101所需的硬件结构和所需的数据状态表及图5所示的主要流程与实施方式I 一致，在此不作重复描述。以下部分说明本实施例2中主要涉及的数据返回步骤504的流程和数据处理方法。
[0174]在图5所示的数据判断步骤503完成后，网关获得用户所需且满足有效期的数据表，如图13所示。本实施例根据图8所示的流程图对这些数据进行处理。此时中央处理器201可以根据不同应用类型对不同的数据进行综合处理，在本实施例中举例提出对警报类数据的处理步骤。
[0175]首条由节点10.0.0.1产生的数据进入数据返回步骤504。如图8所示，步骤801对数据的应用类型进行解析。在此步骤中，数据类型号01被提取。
[0176]随后进行的警报类型判断步骤，此数据类型号01与预存的警报类数据类型号进行对比，在此也为01。因此符合警报类数据，进入步骤803。
[0177]在步骤803初始化之前定义变量X，并将其值置为O。在每一个符合警报类数据通过此步骤时，进一步检测该数据的具体数据，如此条数据为1，代表该传感器的警报已被触发，此时变量X加I。
[0178]对第二条数据进行相同的处理过程。步骤801中对数据的应用类型进行解析。在此步骤中，数据类型号01被提取。
[0179]随后进行的警报类型判断步骤，此数据类型号01与预存的警报类数据类型号进行对比，在此也为01。因此符合警报类数据，进入步骤803。
[0180]在步骤803中进行判断，数据为0，代表该传感器的警报未被触发，此时变量X的值不做任何改变。
[0181]对第三条数据进行相同的处理过程。步骤801对数据的应用类型进行解析。在此步骤中，数据类型号01被提取。
[0182]随后进行的警报类型判断步骤，此数据类型号01与预存的警报类数据类型号进行对比，在此也为01。因此符合警报类数据，进入步骤803。
[0183]在步骤803判断时，数据为1，代表该传感器的警报已被触发，此时变量X的值加
1
[0184]同样的重复步骤801至803，在图13中的3条数据均完成判断后，变量x数值为
2。在步骤804中，该数值被发送回用户。
[0185]同样，中央处理器根据已存的用户IP:201.0.0.1和变量X所存储的数据构造返回数据包，并将此数据包发回至用户。其发回数据格式的范例参照图7。如图15所示，包含网关 IP:203.0.0.1，用户 IP:201.0.0.1，数据:2，发送时间 12:37。
[0186]用户获得此数据后，可以清楚获得此网络即此建筑内部，有2个警报传感器已被触发，可以快速获得楼内警情，并能够在此基础上做出正确判断和处理。
[0187]以此实施例2为例可以看出，采用本发明的数据状态表及相应的数据查询和判断步骤，以及处理方法，实现了进一步优化通信过程，返回数据的数据量有了明显减少，由此网络拥堵大幅减轻。
[0188]4.3、实施例 3
[0189]本实施例基于上述实施方式3。
[0190]由于实施方式3追加了节点主动发送数据时网关数据处理流程的实施方式。本实施例将对此实施方式进行详细说明。
[0191]首先，简单说明实施方式3的整体构思。即，考虑到智能建筑控制网络中，警报数据的实时性需求。对于日常维护类数据，其时间要求范围较宽，可以由网关定期发起更新，存入数据状态表，经由用户的获取命令返回至用户；而对于警报类这种重要数据所需求的时效性要求十分高，如等待用户获取将会造成不及时处理的不良后果。
[0192]在智能建筑控制网络中，有害气体检测传感器、火警烟感传感器、门禁警报传感器等获取的数据定义为警报类数据。该类传感器的特点为实时监控，遇到超过阈值时，将被触发，产生数据。此类传感器的数据多采用主动发送式，触发后发送警报至网关。对于警报类重要数据所需求的时效性要求十分高，如果未能及时交由用户处理则会造成不良后果。
[0193]因此网关对此类数据具有合适的处理方法，以保证警报类数据能够实时告知用户，便于用户知晓警情。在此基础上，用户至少保存I个管理端IP至网关，便于网关获取到此类数据能够将数据发送至此IP。在本实施例中，该管理端IP设为100.0.0.1.[0194]另外，考虑到单个传感器可能会发生故障的情况，用户对警报类传感器的数据可能会进行再次确认或排查。另一方面，对火警烟感传感器等预警信息，用户再次获取此类警情的覆盖范围情况，便于更好的处理和排查。因此由网关对这类紧急数据快速更新，便于用户二次获取数据。本实施方式中，网关接收到警报类数据后，在发送本数据至用户后，解析传感器ID，对网络中此类传感器的数据进行更新，以获取最新数据情况。
[0195]网关101及其他网络设备的初始化过程可与实施例1中采用相同的步骤。在初始化后，如IP为10.1.1.23的节点其下火警传感器02被触发，产生一条数据，如下所示:
[0196]IP:10.1.1.23ID:02 时间:13:48 数据:1
[0197]节点将此数据发送至网关，此时网关101根据图9所示的节点主动式数据处理流程进行处理。如图9所示:
[0198]该数据步骤901为接收数据步骤，在此时由于接收到节点的数据，本流程被触发开始；
[0199]步骤902为更新数据状态表步骤，网关101现在接收数据后根据数据的节点IP、传感器ID等信息更新相应的数据状态表中的数据，即将新的数据位I写入到相应的数据位，将更新时间维护成此数据发送时间13:48 ;此后进入下一步骤，更新后的数据状态表如图16所示；
[0200]在步骤903中，网关101在更新数据后对应用类型进行提取，并进行判断:如为日常维护类数据，则直接结束，如为警报类数据则进入下一步骤904。在此实施例中，应用类型为01，即为警报类数据，直接进入下一步骤904 ；
[0201]步骤904为发送数据步骤，此步骤中网关将此条警报类数据发送至预存警报管理IP 100.0.0.1，其发送格式可参考实施方式1、2中的发送消息格式，例如图17所示。检测端的用户收到实时警报，并由此进行下一步处理；
[0202]步骤905为提取传感器ID步骤，在发送警报信息后，考虑到用户的二次获取可能性以及警报类数据的实时性要求，提取此条数据的传感器ID 02 ；
[0203]接下来步骤906则根据步骤905中提取的传感器ID 02，向终端侧网络中具备传感器ID 02的节点发送数据获取命令，等待接收最新相关警报类数据；
[0204]步骤907为接收更新数据步骤，在接收到节点发回的最新数据后，依次更新数据状态表，并等待用户的下一步命令。其例子如图18所示。
[0205]比较图16和图18可以看出，IP为10.1.1.2的节点具有同样ID为02的传感器。在传感器10.1.1.23的数据发送前，该传感器可能因为故障或因为数据传输时的丢包等问题使得其传感器数据未能实时更新，在步骤906和步骤907之后，节点10.1.1.2更新数据后获取到新的警报消息，有助于用户获取警情的实时全面情况，便于下一步处理。
[0206] 在本实施例3的情况下，在网关接收到重要、紧急的警报类数据(例如智能建筑控制中的火灾警报数据等)时，能够快速的将此数据上报至用户，确保了重要数据和紧急数据的及时传输，并且进一步获取全面的警报数据，为用户的实时处理提供了良好的基础。
【权利要求】
1.一种网关装置，能够与一个或多个用户进行数据交互，并直接或通过多个子网关与多个终端节点连接，所述多个终端节点的每一个管理一个或多个设备，该网关装置的特征在于，具有: 与所述用户进行通信的用户通信接口； 用于进行与所述终端节点的通信的终端侧通信接口； 存储关于所述设备的数据的存储器；和 对数据和所述用户的命令进行分析处理，对数据交互进行控制的处理器， 所述处理器，当通过所述用户通信接口接收到来自用户的数据获取命令时，对所述命令进行分析，并检查所述存储器中存储的数据是否满足规定的要求，如满足规定的要求则将该数据直接向所述用户发回，如不满足规定的要求则通过所述终端侧通信接口向所述终端节点要求新的数据，并将从设备取得的新的数据向所述用户发回。
2.如权利要求1所述的网关装置，其特征在于: 关于所述设备的数据包括所述设备的设备数据、所述设备数据的更新时间和所述设备数据的有效期， 所述处理器根据所述用户的命令的发送时间、所述设备数据的更新时间和所述设备数据的有效期判断所述设备数据是否有效，当判断为所述设备数据有效时将该数据直接向所述用户发回，当判断为所 述设备数据无效时向所述终端节点要求新的数据。
3.如权利要求2所述的网关装置，其特征在于: 在经由所述终端侧通信接口取得了设备数据时，更新存储在所述存储器中的关于所述设备的数据。
4.如权利要求2所述的网关装置，其特征在于: 所述设备数据包括报警类数据和日常维护类数据两种类型的数据， 所述处理器分析所述设备数据的类型，并根据不同的类型，以不同的规则对数据进行处理后发送给用户。
5.如权利要求4所述的网关装置，其特征在于: 所述处理器分析所述设备数据的类型，当所述设备数据为表示触发报警的报警类数据时，所述处理器将发出所述设备数据的设备的数量发送给用户，当所述设备数据为日常维护类数据时，所述处理器将对来自多个设备的日常维护类数据进行平均化处理后的综合信息发送给用户。
6.如权利要求4所述的网关装置，其特征在于: 在经由所述终端侧通信接口接收到设备数据时，在更新了存储在所述存储器中的关于所述设备的数据后对所述设备数据的类型进行判断，在判断为是表示触发报警的警报类数据时，主动向用户发送警报信息，并提取发出所述设备数据的设备的ID，向具备相同ID的终端节点发送数据获取命令，在接收到从所述终端节点发回的最新数据后更新存储在所述存储器中的关于所述设备的数据。
7.一种数据处理方法，利用网关装置进行数据处理，其中该网关装置能够与一个或多个用户进行数据交互，并直接或通过多个子网关与多个终端节点连接，所述多个终端节点的每一个管理一个或多个设备，该数据处理方法的特征在于: 所述网关具有存储关于所述设备的数据的存储器，该数据处理方法包括以下步骤:接收用户发送至所述网关装置的数据获取命令， 对所述命令进行分析，并检查存储在所述存储器中的数据是否满足规定的要求，如满足规定的要求则将该数据直接向所述用户发回，如不满足规定的要求则向所述终端节点要求新的数据，并将从设备取得的新的数据向所述用户发回。
8.如权利要求7所述的数据处理方法，其特征在于: 关于所述设备的数据包括所述设备的设备数据、所述设备数据的更新时间和所述设备数据的有效期， 根据所述用户的命令的发送时间、所述设备数据的更新时间和所述设备数据的有效期判断所述设备数据是否有效，当判断为所述设备数据有效时将该数据直接向所述用户发回，当判断为所述设备数据无效时向所述终端节点要求新的数据。
9.如权利要求8所述的数据处理方法，其特征在于: 在取得了设备数据时，更新存储在所述存储器中的关于所述设备的数据。
10.如权利要求8所述的数据处理方法，其特征在于: 所述设备数据包 括报警类数据和日常维护类数据两种类型的数据， 分析所述设备数据的类型，并根据不同的类型，以不同的规则对数据进行处理后发送给用户。
11.如权利要求10所述的数据处理方法，其特征在于: 分析所述设备数据的类型，当所述设备数据为表示触发报警的报警类数据时将发出所述设备数据的设备的数量发送给用户，当所述设备数据为日常维护类数据时将对来自多个设备的日常维护类数据进行平均化处理后的综合信息发送给用户。
12.如权利要求10所述的数据处理方法，其特征在于: 在接收到设备数据时，在更新了存储在所述存储器中的关于所述设备的数据后对所述设备数据的类型进行判断，在判断为是表示触发报警的警报类数据时，主动向用户发送警报信息，并提取发出所述设备数据的设备的ID，向具备相同ID的设备的节点发送数据获取命令，在接收到从所述节点发回的最新数据后更新存储在所述存储器中的关于所述设备的数据。
【文档编号】H04L12/66GK103701694SQ201210370836
【公开日】2014年4月2日 申请日期:2012年9月27日 优先权日:2012年9月27日
【发明者】何璇, 马元琛 申请人:株式会社日立制作所