用于分布式数据系统的语义搜索及规则的方法与流程

发明领域本公开的实施例大体上涉及数据处理的方法，且更具体地用于查询和关联与分布式数据处理系统相关联的数据的操作规则的系统和方法。优先权请求本申请要求以下临时专利申请的优先权并从中受益：2017年3月30日提交的标题为“分布式数据系统的语义搜索和规则方法”的美国专利第62/479,120号。在此通过引用明确地并入了上述专利申请的全部内容。背景相关技术的描述物联网(iot)承诺大规模地将元素互连在一起。这种融合允许在这些元素之间的交互作用和协作，以完成一项或更多项特定任务。这些任务根据应用的上下文和环境而不同。例如，任务可以从环境特征(诸如单个房间的温度或湿度)的感测和监控到整个建筑或设施的控制和优化，以便实现更大的目标，诸如能量管理战略。根据应用，连接元素、设备及/或组件可以是异质及/或同质硬件，这可以有助于感测、致动、数据捕获、数据储存或数据处理。每种类型的连接元素硬件可以具有唯一的数据结构，所述数据结构详细描述硬件本身的物理能力及/或测量参数的数字表示。例如，温度传感器可以包括温度度量、mac地址、ip地址和cpu类型数据。每个连接的硬件元件可以具有唯一的数据结构。因此，在通过各种各样的可用元件而可用的这些各种数据结构的异构性的情况下，有效地分析及控制所述数据成为了严峻的挑战。概述提供了用于混合连接设备致动系统(在本文中称为hcdas)的系统和方法。一种系统，用于混合连接设备致动系统，可以包括：至少一个处理器，配置为：处理可包括语义查询和操作规则数据的一混合致动查询；基于已处理的混合致动查询数据及相关联于一控制系统的本体数据，确定与所述控制系统相关联的至少一可致动连接设备；基于与所述混合致动查询相关联的操作规则数据，确定与至少一已确定的连接设备相关联的可致动变量，以及执行与控制系统中的至少一个确定的已连接设备关联的可调节变量的一运行状态中的一更改。本公开的原理考虑到，至少一个处理器可以进一步被配置为通过将一本体查询组件应用于一可致动规则引擎控制模块来确定与所述至少一已确定的连接设备相关联的多个可致动操作状态。在另外的实施例中，至少一处理器可以被配置为确定与至少一连接设备相关联的多个可用规则可致动变量，所述至少一连接设备通过将本体库中的适当的多个分层控制结构与有关于所述控制系统的多个规则可致动连接设备相关联来识别。在进一步的实施例中，所述处理器可以被配置为通过将本体库中的多个适当分层控制结构与有关于一控制系统的多个规则可致动连接设备进行相关联，来确定与所述控制系统相关联的至少一连接设备。本公开的原理还预期所述规则数据具有一关联的生命周期。进一步的原理考虑了所述规则数据具有一关联的冲突机制，并且所述规则数据具有一关联的条件机制。提供了用于基于本体的查询和规则执行系统的系统和方法。一种系统，用于基于本体的查询和规则执行系统，可以包括：至少一处理器，被配置为接收具有多个查询元素和一规则数据集的一结构化搜索查询；根据所述多个查询元素识别一连接元素集；注释每个已识别的连接元素集的一数据结构，以形成一查询数据集；将所述查询数据集提供给一规则引擎；评估与所述连接元素集和所述规则数据集有关的多个条件；根据所述连接元素集的多个评估条件确定一命令集；及在所述连接元素集上执行所述命令集。在一个方面，提供了一种混合连接设备致动执行方法。所述方法包括：处理包括语义查询和规则数据的一混合致动查询；基于已处理的混合致动查询数据及相关联于一控制系统的本体数据，确定与所述控制系统相关联的至少一可致动连接设备；基于与所述混合致动查询相关联的规则数据，确定与至少一已确定的连接设备相关联的可致动变量；以及执行与控制系统中的所述至少一已确定的连接设备相关联的可致动变量的一运行状态中的一更改。附图简述这些附图并非意图按比例绘制。在附图中，在各个图中示出的每个相同或几乎相同的部件由划线数字表示。出于清楚的目的，并非每个部件都可以在每个图中被标记。在附图中：图1示出了根据本公开的各种实施例的用于促进hcdas的系统的多个方面；图2示出了根据本公开的各种实施例的不同类型的设备可以如何连接到hcdas的各种实施例；图3a示出了根据本公开的各种实施例的hcdas的各种连接元素的示例性部署；图3b示出了跨越图3a的hcdas的各种物理位置的连接元素的示例性部署；图3c示出了跨越hcdas的连接元素的用户接口内的示例性分层数据组织构造；图3d示出了跨越hcdas的连接元素的示例性本体数据组织构造；图3e示出了利用本体数据构造和跨越hcdas的连接元素的示例性控制系统；图4a是hcdas的组件和互连的框图；图4b是hcdas控制器的组件和互连的各种实施例的框图；图4c是用于hcdas的系统的组件的实施例的框图；图4d是用于hcdas的系统的组件的实施例的框图，hcdas包括语义引擎的细节；图4e是用于hcdas的系统的组件的实施例的框图，其包括规则引擎的细节；图5是用于hcdas的系统的组件的实施例的框图，其包括语义引擎和规则引擎的细节；图6a是用于执行hcdas的流程图；图6b是用于hcdas的示例性命令功能的流程图；图6c是来自图6b的hcdas的示例性命令功能的流程图；图6d示出了来自图6c的用于hcdas的操作规则生命周期操作的实施例的流程图；图7示出了用于hcdas的操作规则条件操作的实施例的流程图；图8示出了hcdas的可扩展的替代实施例；图9a至图9n示出了hcdas的lua实现细节的各种示例性实施方式；图10是根据本公开的实施例的通用计算机系统的功能框图；及图11是根据图10的通用计算机系统的通用存储系统的功能框图。详细概述本公开并不将其应用限于下面描述中阐述的或者由附图示出的部件的结构以及布置的细节。本公开能够是其他实施例，并且能够以各种方式来实践或执行。此外，在本文使用的措辞和术语是为了描述的目的，且不应被视为限制性的。“包括(including)”、“包括(comprising)”、“具有”、“包含”、“涉及”及变型在本文中的使用意在是开放式的，即“包括但不限于”。在物联网(iot)或更普遍地信息物理系统(cps)的新兴世界中，多种技术的融合正在进行中以允许由大批连接元素、设备及/或组件或是由它们的物理，虚拟及/或两者的混合组合的感测、致动、数据捕获、储存或处理。这些连接元素可使用现有的网络基础设施远程访问，以允许有效的机器到机器(m2m)和人到机器(h2m)通信。在此通信过程中，由于连接元素的网络随着时间的推移而变化，来自这些连接元素的越来越多的数据将被生成并允许以前不可能的关联。关联数据结构的完全不同的性质加剧了组织连接元素的动态集合的问题。由于硬件和相关联的数据结构的这种过剩，组织和分析数据的问题出现了，因为各种各样的数据结构可能在单个处理点处从连接元素的庞大网络接收。存在对于处理、请求和分析来自连接元素的异构源的数据的能力的需求。每个独立的连接元素可以包含来自数据结构的多个数据特征，这些数据特征类似于其他独立元素或元素组。然而，即使具有这些相似的数据特征，在众多不同连接元素上高效地查询和影响这些相似的数据特征和相关设备的变化也是一个巨大的挑战。解决数据异质性问题的一种方法涉及实现和执行混合系统，以利用语义构造来查询，定义操作规则和操作连接的元素。数据挑战的一种解决方案是使用混合结构化语义和操作规则查询解决了两个不同的问题。首先，解决从包含各种数据结构的连接系统传递的数据异构性问题。第二，过滤和聚合来自连接元素的这些异构数据，并向用户、云平台或其他存储库只提供所需且相关的数据。第三，控制环境、设备、装备或/和系统并与之交互作用。耗能设备已从仅具有打开或关闭的选项发展到允许更多的控制和功能，以更好地实现期望的目标。例如，大多数现代建筑中都使用了动态致动的电灯开关和气候控制空调系统。然而，这些设备主要仅在考虑到设备本身的测量的情况下独立地工作。今天使用的“智能设备”比其前任产品更加智能。这些设备具有使用tcp/ip，gprs，3g，zigbee等协议进行交互作用和通信的能力。这些设备中的许多设备都具有连接到intranet网络的能力。这进一步改善了与这些设备的可能的交互作用，并允许例如在标准数据库中存储从设备接收的测量结果。能够从多个设备收集数据的关键优势在于，可以分析所述数据并将其用于改善系统的整体性能。为了实现这些改进，有必要指定操作规则并将这些操作规则重新部署到不同的设备。这些操作规则的范围可以简单到在房间温度达到一定阈值时向监视平台发送警报，到控制地下矿井中空气流速的复杂的操作规则。所述挑战在于及时控制设备并发送相关信息以进行监视。所有这些都必须在非常动态的环境中发生，所述环境与控制不同环境变量并使用不同协议进行通讯的大量设备进行交互作用。实现和执行的示例应用可以包括但不限于：(1)管理hvac系统以确保设施居住者的舒适性，(2)维护用于栈房或居住者的特定环境空气质量(其可能包括温度、湿度和二氧化碳含量)，并根据普遍的天气条件动态调整工作建筑环境，(3)通过主动控制照明、加热和冷却来控制和优化能耗来管理设施管理，以及(4)监控日常运营、维护和设施运营的监督。这种应用的商业实施例可以是建筑物管理或自动化系统的一部分。应当理解，本文描述的系统利于在配置及/或终端用户应用方面的显着灵活性，并且尽管描述了几个示例，但是许多替代实施例配置和应用也是可能的。一般来说，此类任务由本质上非技术人员且需要丰富的交互体验的个人来执行，这掩盖了数据异质性问题的复杂性。本文包含的各种实施例的优点包括：允许搜索特定的连接元素或相关联的数据结构；在不熟悉设施特定架构的情况下，配置符合所述设施特定架构的警报和通知消息；允许设施特定查询的执行以确定实时指标，诸如按区域划分的能耗；以及配置任何类型的数据结构以不需要单位转换或其他特定结构的方式进行收集。应当理解，混合方法是必要的，其至少由在紧密绑定的系统中的语义查询和执行语义操作规则组成，以获得本文所述的许多益处。这样，讨论了用于混合连接设备致动系统(在本文中称为hcdas)的系统和方法。图1示出了可以实现根据本公开的各种实施例的用于促进hcdas的系统的多个样态。利用hcdas125的系统可以包括一个或以上的通用计算机110，一个或以上的数据存储阵列130，一云计算环境120，包含一个或以上的连接元素(未示出)的一建筑物或其他结构140，以及网络连接150，以允许在系统的这些部分之间交换数据。在图1所示的系统的一个实施例中，所述建筑物140包含一个或以上的连接元素、组件、设备及/或驱动组件，它们是物理的，虚拟的或两者的混合，以执行感测、致动、数据捕获、存储或处理，用于建筑物140的监视、控制或管理。任何种类的连接元素可以用于在到云计算环境120、到系统的其他部分的网络连接150上捕获、存储或处理数据，或致动相关联的设备。这些连接元素可以例如检测温度、湿度、环境光、声音、烟雾、一氧化碳、二氧化碳、运动、非导电流体、导电流体、振动、能量、功率、电压、电流或任何其他期望的特性，以及它们的组合。连接元素也可以操作或铰接元件、部件及/或其他系统，诸如打开灯、打开门或窗户、遮光帘或触发门锁。连接元素还可以处理来自其他连接元素的数据结构，或者将来自一个或以上的连接元素的数据结构传播到一个或以上的其他连接元素。可以以任何组合来部署任何数量的连接元素以监控或管理物理空间。这种空间的示例可以包括壁橱、房间、建筑物、校园、办公室、长廊或任何其他期望的地点。包含连接元素的每个建筑物140可以最终通过网络连接150连接到云计算环境120。这种连接允许能够以有线或无线的连接方式连接到云计算环境120的各种设备访问这种云计算环境120。从图1a中，这样的设备可以包括能够从用户接收输入或者提供自主操作的一个或更多个通用计算机110。一个或更多个数据储存阵列130可用于提供额外的数据储存能力。应当认识到，云计算环境120提供到附加元件或系统的附加通信路径，但并不需要作为语义搜索方法的一部分。其它实施例考虑独立或单独的系统。网络连接150可以是有线或无线连接类型。这种连接可包括但不限于任何物理布线方法，诸如5类电缆、同轴电缆、光纤、铜、双绞线或传播电信号的任何其它物理介质。无线连接可包括但不限于个人区域网(pan)、局域网(lan)、wi-fi、蓝牙、蜂窝、全球或基于空间的通信网络。在云环境120和任何其它云环境之间的访问在其他实现中是可能的，这些其它云环境被配置成与类似于云环境的设备(诸如现有的云环境120)连接。应当理解，图1中显示的计算设备仅仅旨在是例证性的，并且计算节点和云计算环境可通过具有可寻址或直接连接的任何类型的网络与任何类型的计算机化设备通信。本公开的原理包括hcdas125，hcdas125可以包含图1中的元件细节。如图1所示，这些组件可以包括更多或更少的这些组件，或者可以位于建筑物140，一系列建筑物中。hcdas125可以是物理的，可以是虚拟的或两者的混合组合。对于hcdas125的组成，位置或组织没有任何限制。图2示出了根据本公开的各种实施例的不同类型的设备可以如何连接到hcdas的各种实施例。在图2的一个实施例中，建筑物140包含一种或以上的类型的用于结构的监控或管理的连接元素210、220、230、240。这些连接元素210、220、230、240通过有线网络250或无线网络260通信，并通过网络连接150使每个连接元素的数据结构可用于hcdas125及/或云环境120。任何种类的连接元素可以用于在到hcdas125、云计算环境120、到系统的其他部分的网络连接150上感测、致动、数据捕获、储存或处理。例如，连接元素可以是连接传感器以测量二氧化碳210，用于监测建筑物140的空气质量，并通过有线网络连接250进行通信。连接元素220既可以是检测环境光的连接传感器，也可以是改变居住者照明设备的状态并通过有线网络连接250通信的致动器220。连接元素可以是用于温度和湿度230的连接传感器，以监测建筑物140的环境，并通过无线网络连接260进行通信。最后，连接元素240用作连接网关，以通过它们各自的网络连接250、260与相关联的连接元素210、220、230通信，处理每个元素的数据结构，并将它们发送到网络连接150以用于发送到云计算环境120。应当认识到，云计算环境120提供到附加设备或系统的附加通信路径，但并不需要作为语义搜索方法的一部分。其它实施例考虑独立或单独的系统。这些连接元素不需要在地理上是局部的或以任何方式在逻辑上分组以利用本公开的实施例。在地理上或在逻辑上分组连接元素可允许更经济的使用。诸如在公寓、家庭或办公室建筑物中的地理分组以及在逻辑上按功能来定位连接元素可被实现。许多逻辑分组示例中的一个可以是定位被设计成感测温度的连接端点，其靠近被占用的位置以检测环境的变化。应当认识到，连接端点的分组也可以位于非常大的地理范围内，甚至全球范围内。这种全球运营可以通过位于全球任何数量的设施中的网络来监测。图3a示出了其中可以实现本公开的各种实施例的hcdas的各种连接元素的示例性部署。示出了“北”建筑物310和“西”建筑物320。每栋建筑物都有(3)个楼层。北楼层(1)312、北楼层(2)314、北楼层(3)316被包含在北建筑物310内。西楼层(1)322、西楼层(2)324和西楼层(3)326被包含在西建筑物320内。每个楼层都有(3)个不同类型的连接元素。例如，连接元素可以是测量二氧化碳的连接传感器330、332、334、360、362、364以用于分别监测建筑物310、320的空气质量，并通过有线网络连接进行通信。连接元素可以是检测环境光的连接传感器且可以是改变居住者照明设备的状态并通过有线网络连接通信的致动器340、342、344、370、372、374。连接元素可以是用于温度和湿度的连接传感器350、352、354、380、382、384以分别监测建筑物310、320的环境并通过无线网络连接进行通信。如图所示，hcdas125连接到系统以向所述连接元素提供语义查询和操作规则，以实现系统上的改变。图3b示出了跨越在图3a的hcdas的各种物理位置上的元件的示例性部署，其中可以实现本公开的各种实施例。在每栋建筑物的每个楼层内存在多个连接元素。作为示例，温度和湿度350、352、354、380、382、384、二氧化碳330、332、334、360、362、364以及环境光340、342、344、370、372、374的连接元素存在于每栋建筑物的每一楼层上。此外，每个连接元素可以存在于每栋建筑物的每个楼层上的不同区域中。作为许多示例之一，总平面图390可以指示被定义为“区域1”392、“区域2”394和“区域3”396的区域。应当认识到，这种指定是用户或其他系统高度可配置的，并且在此仅出于说明目的而示出。给定图3a和3b中所示的连接元素配置，每个连接元素具有数据结构，所述数据结构包括但不限于传感器特定信息(温度/湿度、二氧化碳和环境光)、地理信息(区域、楼层、建筑物)和网络信息(mac地址、ip地址、有线、无线)。其他连接元素信息以及与连接元素本身的操作相关的信息也是可用的。作为一个示例，在线或离线状态可用于进一步添加到对于每个连接元素的数据结构。一旦与连接元素的物理连接就位或建立，就可以创建数字表示。将系统的物理表示转化为同质化分类的过程称为语义标注。语义标注将特定系统的连接元素中可用的数据结构链接到实际上或可能存在于物理表示的系统或本体(ontology)中的正式名字和定义。例如，本体可以包括诸如位置、关系、用途、物理量、网络协议或单位的定义。语义标注可以以两种方式之一出现，自动语义标注或手动语义标注。自动语义标注由系统在没有用户输入的情况下完成。在这种方法中，系统检查对于每个连接元素的每个数据结构，并将其解构为相应的数据结构元素。在识别过程期间，确定对于每个连接元素存在哪些数据结构元素。一旦定义了每个数据结构元素，它之后会被映射到相应的分类，并使用所述分类进行标注，所述分类又会成为所述连接元素数据结构的一部分。至少一个数据结构元素在此过程期间可以被标注，以允许所有连接元素被定义为系统的一部分。手动语义标注由系统利用用户输入来完成。作为示例，这种形式的标注可以在整个系统、连接元素组或单独的连接元素的安装期间执行。类似于自动语义标注，对于每个连接元素的每个数据结构都被检查或为用户所知。一旦用户识别出定义了什么数据结构元素，用户就可以选择到相应分类的映射。一旦用这种分类进行了标注，它又成为所述连接元素数据结构的一部分。至少一个数据结构元素在此过程期间可以被标注，以允许所有连接元素被定义为系统的一部分。其他工具可用于帮助用户识别对于特定连接元素的特定数据结构元素。这种工具可以在整个系统或系统的部分的调试期间使用。应当理解，hcdas125与所述系统紧密耦合，以允许所描述的语义操作得以实现。图3c示出了跨越hcdas的连接元素的用户接口内的示例性分层数据组织构造。应当认识到，任何组合中的任何连接元素类型可以存在于任何地理位置中，并且包括相应数据结构内的附加信息。此外，这样的分层结构数据组织示出了来自用户接口的示例性输出，所述示例性输出可以用于促进手动语义标注。图3d示出了跨越hcdas的连接元素的示例性本体数据组织构造。这些示例性数据组织示出了诸如协议或用法之类的本体的示例以及诸如数据中心或建筑物之类的针对应用的特定本体。以这种方式，设施操作员不需要具有以机器为中心的构造的深入知识，仅需要以人为中心的构造，例如用法，地理，物理量及/或单元类型等知识。图3e示出了跨越hcdas的实施例的利用本体数据构造和连接元素的示例性控制系统。现在形成了控制系统，其利用hcdas系统的元件来将人能够解释的上下文提供给物理及/或虚拟系统。一个示例是说明性的，其中要求照明技术员在每个星期一更换照明。利用本体论上下文的原理，技术人员可以通过hcdas查询“检查北建筑物楼层2的照明灯”314是什么。技术人员不需要了解以机器为中心的概念(例如序列号)，而是需要以人为中心的概念(例如物理位置)。应当理解，这些构造是动态的，hcdcs与之交互作用的系统也是动态的。这样用户或系统可以从语义查询开始，并利用所述语义查询的结果来实现在hcdas权限下对系统的更改。此外，这些查询结果可用于形成操作规则的基础，以进一步实现系统中的改变，并由hcdas执行操作规则并得出要反馈给hcdas系统的语义查询部分的结果来继续进行。一旦语义标注的过程完成，物理系统的数字表示被存储在系统内的一个或更多个存储器中。每个连接元素将由相应的数据结构表示。每个数据结构将包含描述连接元素特性的数据结构元素。作为许多示例之一，具有二氧化碳传感器330的连接元素将具有描述传感器特性的相关联的数据结构。每个数据结构将由许多数据结构元素组成。每个连接元素将拥有数据结构(contracture)和一个或更多个数据结构元素。对于所述二氧化碳传感器330的数据结构元素可以包括物理量(二氧化碳)、测量单位(百万分之几)、位置(北建筑物，楼层1，区域3)、协议(modbus)、网络(有线、ip地址)和用途(建筑物)。应当认识到，虽然每个连接元素将具有相关联的数据结构，但是数据结构元素的数量可以基于特定的配置或应用而变化。一旦以这种方式组织了连接元素数据结构，就可以在没有物理系统和相关联的连接元素的离散或深入知识的情况下执行多维分析。图4a是hcdas的组件和互连的框图。在一个实施例中，hcdas包含语义引擎402和规则引擎404，在本文中将在上下文中对其进行详细描述。应当理解，语义引擎402和规则引擎404通过网络连接405彼此通信并且与hcdas通信。通过这种紧密绑定的通信，语义引擎402获得规则引擎404执行的结果。来自规则引擎404的进一步结果被用于实现在语义引擎402处使用的语义查询。应当理解的是，这不仅仅是将结果从hdcas的一个部分传递到另一部分，而是它们之间的相互关系，这有助于本文所述许多情况的好处。语义规则引擎控制器可以由规则引擎和语义引擎两部分组成。尽管两者可以彼此结合使用，但是应当理解，这不是对系统的限制，并且一或二者可以独立于另一个使用。语义规则引擎控制器408(取决于实现方式，也可以称为hcdas控制器408)可以包括以下功能：(1)利用操作规则以不含糊和上下文的方式明确表达用户及/或系统要求和条件；(2)利用设备(例如网关)的能力在本地及/或远程部署操作规则；(3)专用的操作规则执行引擎，用于分析、创建及/或执行操作规则；(4)利用semanticweb和主体(ontology)概念提供有关数据的一致的、可重用的和共享的视图；(5)具有类自然语言语法的上下文查询语言；(6)一种有效的机制来分析用户及/或系统查询；(7)以模块化的方式开发解决方案，以便在未来集成和扩展新功能。利用语义规则引擎控制器408，关于用户控制或信息的任何用户及/或系统要求都以操作规则的形式表示。这些规则的设计使其能够：(1)评估与资源及/或其功能有关的条件；(2)在满足这些条件时执行对资源及/或功能的控制；(3)满足特定条件时通知用户及/或系统；(4)为每个规则提供生命周期，以允许安装、激活、停用及/或卸载所述规则；(5)规则之间的合作，在一个示例中，允许多个规则重复使用相同的清晰度(articulation)定义。图4b是用于hcdas的系统的组件的实施例的框图。在本示例中，hcdas414包括人机接口(hmi)416、规则库418、云连接代理420、设备数据模型库422、网关428和语义规则引擎控制器408，语义规则引擎控制器408本身包括语义引擎424和规则引擎426。还可以存在云平台120以实现远程数据传输。用户及/或系统可以使用hmi416来与hdcas414交互作用。本公开的原理考虑了部分地通过hmi416来接受hdcas414的手动、半自动及/或自动操作，并传输信息。规则库418是由语义规则引擎408创建、生成、编辑及/或以其他方式处理的操作规则库。这些规则可以在本地、远程或两者的组合中进行管理。云连接代理420是hcdas414的支持功能，并通过诸如订阅、计时器及/或与hdcas414其他组件的交互作用等功能协助规则管理。另外，设备数据模型库422是通过网关428可用于hdcas414的设备和能力的存储库。应当理解，设备数据模型库422不需要仅包含hdcas414当前正在使用的设备，而是通常可以包含所有可用设备的功能的完整库。图4c是用于hcdas的系统的组件的实施例的框图，其包括语义引擎424的细节。用户及/或来自机器的另一过程可以开始语义搜索。用户启动的搜索可以从通用计算机110开始，在其他实现中，机器启动的过程可以从系统中的任何其他过程所衍生。应当理解，语义搜索的发起方法并不相互排斥。在两种情况下，由语义引擎424处理的查询都是具有特定语法的结构化搜索查询。所述语法结构可以包括各种数据结构元素的使用、过滤、基本聚合、发布和订阅以及推论功能。在一个实施例中，结构化搜索查询可以包括一个或更多个过滤表达式。searchdeviceprotocol:zigbeeandquantity:temperatureandlocation:lab101with(name＝＝tempsensorandvalue>22andwithunit＝＝_f)的lab101将在lab101中搜索名为“tempsensor”的、具有大于22f的值的zigbee无线传感器。在替代实施例中，支持基本聚合函数，诸如min、max、sum、avg。例如，sumvariablemeasures:activeenergyandusage:lightingandlocation:building2计算了在建筑物2中所有有源光源的总和。在另一个实施例中，发布及/或订阅功能可以应用于对于给定测量类型在特定位置中的连接元素。subscribedeviceprotocol:zigbeeandquantity:temperatureandlocation:floor1withvalue>22andwithunit＝＝_fevery00:10:00from2016-03-21to2016-04-21，分析何时有特定的连接元素可用。在另一个实施例中，推断功能(诸如@type：sensor)可以用于推断所连接的元素之间的关系。结构化搜索查询被接收到由查询解码器(qd)436和查询评估器(qe)438组成的语义查询处理器434中。查询解码器(qd)436分析结构化搜索查询并将其解构为查询元素。查询元素被传递给查询评估器(qe)438，以分析查询元素并基于分析在系统上执行操作。结构化搜索查询可以包括关于特定连接元素的推断功能。在这种情况下，离散的连接元素是未知的，但是需要关于它的信息。这里，本体处理器440执行进一步的分析，所述本体处理器440进一步处理包含在结构化搜索查询中的推断引用的数据结构元素，并访问本体库442以获得对适当连接元素的可用推断引用。例如，连接元素是由用户查询环境值的二氧化碳传感器330。用户将结构化查询输入到通用计算机110中。查询解码器(qd)436对结构化搜索查询进行反编译，并将查询元素传递给执行收集数据的操作的查询评估器(qe)438。在所述示例中，仅请求传感器330处的二氧化碳的当前值。查询评估器(qe)438请求对于连接元素的完整数据结构。所述数据结构从用作对于二氧化碳传感器330的网关设备240的连接元素的传输。二氧化碳传感器330的整个数据结构从充当网关设备240的连接元素收集，并将数据传输到语义查询处理器434和通用计算机110。应当认识到，用于分析的数据结构可以接近实时的来自连接元素，诸如充当网关设备240或包含数据结构的数据库441的连接元素。这种决策基于系统的状态和结构化搜索查询。如上文所述，语义引擎432是hcdas414的一个组件，并且与图4d中描述的规则引擎紧密耦合。图4d是根据本公开的各种实施例的用于语义搜索方法的系统的组件的实现的规则引擎示例。如上文所述，规则引擎426是语义规则引擎控制器408的另一组件。它部分地利用分散的智能及/或管理，监视及/或控制任何连接设备(无论是物理设备，虚拟设备还是两者的组合)提供通往连接元素的网关。规则管理器模块448可以与远程应用程序交互作用以接收规则文件及/或命令来管理它们。规则管理器加载所述执行环境以运行和管理所有规则。所述执行环境通常是提供需要的功能所需的一组支持功能。这些支持功能444处理订阅、定时器以及与语义规则引擎控制器408的其他组件(例如，语义引擎424和云连接代理420)的交互作用。这些功能中的每一个可以驻留在执行环境442中以允许操作。所述操作环境的特定示例在图9a至图9n中示出。一旦创建了执行环境，规则管理器就可以创建规则446并对其进行管理(例如，安装、启动、停止及/或删除)。每个操作规则都可以独立执行，这样一个规则的任何异常都不会影响其他规则。操作规则可以与诸如网页服务器或云450之类的应用层交互作用以增强远程能力。这样的交互作用可以通过网页以hmi的形式来向hcdas414发布指令及/或命令。为了在上下文的基础上管理规则，可以使用上文详述的语义搜索引擎424。利用语义搜索引擎424的概念来允许规则引擎426进行基于语义的查询并使用返回的结果来执行规则。应当理解的是，语义搜索引擎424和规则引擎426之间的链接被用来带来本公开的许多益处。提供的简单查询语言极大地促进了两个引擎之间的交互作用。这是与其他解决方案(如“如果这样那么就会那样”(ifthisthenthat；ifttt))的区别因素。作为许多示例之一，规则可以使用位置标签作为获取传感器列表的方式，以将传感器的当前值与规则中指定的阈值进行比较。语义搜索引擎可以使用位置标签对所有传感器进行过滤，并仅将相关传感器提供给规则引擎。然后，操作规则可以根据规则中指定的逻辑对任何结果进行比较，并执行操作，例如通知、警报及/或致动。在替代实施例中，相同的规则可以被周期性地执行，并且在其下一次执行之前，一些新的传感器被安装在相同的位置。在下一次执行中执行相同的语义查询时，使用语义引擎将同时返回新传感器和旧传感器。因此，无需更改规则逻辑。在此示例中，规则引擎变得独立于任何拓扑更改(topologychange)。总体而言，具有此功能允许语义规则引擎控制器成为一种灵活的解决方案，在所述解决方案中，只要概念(例如上述实施例中的位置)相似，就可以在不同的产品和解决方案中重复使用相同的规则。这提供了多个好处，包括但不限于节省时间和成本，以及不论设备、安装或客户如何，都具有类似的功能。图5是用于hcdas的系统的组件的实施例的框图，其包括语义引擎424和规则引擎426的细节。另外，来自建筑物140的连接设备和相关元件被连接。此外，预期了上文描述的规则管理模块510，其可以包括但不限于订阅、计时器及/或其他管理。操作规则可以与诸如网页服务器或云450之类的应用层交互作用以增强远程能力。这样的交互作用可以通过网页以hmi的形式来向hcdas414发布指令及/或命令。作为利用所述实施例的一个示例，维护人员的任务是在每个星期一早晨更换不工作的灯泡。用户可以使用与应用程序450相关联的hmi来查询地理位置以寻找不起作用的灯泡。规则引擎426的各个组件中可能已经存在操作规则。如果是这样，则将以人类可理解的格式提供操作规则的结果(例如，北建筑物的办公室5的楼层2的灯泡熄灭了)。如果没有可用的规则，则用户可以从语义引擎424进行这样的查询。一旦获得结果，则hcdas可以制定或建议针对其制定操作规则。技术人员现在能以人为中心的方式执行维护工作，并且在随后的几周内，hcdas本身可以根据将执行的语义搜索来更新操作规则以包括或排除灯。这样，语义424和规则引擎426彼此紧密地绑定在一起，以提供、反馈和更新结果、控件及/或操作规则。关于操作及/或信息的用户及/或系统要求以操作规则的形式表示。因此，可以设计具有以下特征的规则：(1)评估与资源及/或其功能有关的条件；(2)在满足这些条件时执行对资源及/或功能的控制；(3)满足特定条件时通知用户；(4)为每个规则提供生命周期，以允许安装，激活，停用及/或卸载所述规则；(5)作为许多示例之一，规则之间的合作允许多个规则重复使用相同的清晰度定义。图6a是用于执行hcdas的流程图。如本文中所详细描述的，hcdas处理包括语义查询和规则数据602的混合致动查询。应当理解，所述查询可以来自语义引擎、规则引擎、或者来自另一个的动作以在系统内连接元素的致动下形成旨在针对性的混合查询。基于已处理的混合致动查询数据和与控制系统相关联的本体数据，确定与控制系统相关联的至少一个可致动连接设备(604)。这用作与一个查询相关联的一个或以上的连接元素的标识，所述查询可以来自语义引擎、规则引擎，或者被另一个操作以形成混合查询，所述混合查询旨在致动系统内的连接元素。一旦确定了一个或多个连接元素，就需要了解它们的功能，因此任何即将发生的动作都适用于请求采取行动的连接元素的类型。基于与混合致动查询606相关联的规则数据，确定与至少一个所确定的连接设备相关联的可致动变量，以允许进行连接元素能力的这种表征。随着这些完成，hcdas执行与控制系统608中的至少一个确定的连接装置相关联的可致动变量的操作状态的改变，以实现对一个或以上的连接元素的改变。图6b是用于hcdas的示例性命令功能的流程图。如以上所讨论的，针对一个或以上的连接元素610接收结构化搜索查询。应当理解的是，一个或多个连接元素可以是语义搜索的目标。直接从用户或另一台计算机接收此查询。接收到的结构化搜索查询被解构为其复合查询元素620。语义搜索引擎对查询元素进行处理，以识别哪些连接元素需要检查其各自的数据结构630。提取每个已识别的连接元素的数据结构并进行处理以确定哪些数据结构化元素与结构化搜索查询的查询元素匹配，并确定命令数据元素640。此命令数据元素用于确定完成结构化搜索查询所需的其他处理。本公开的实施例允许分析多个数据结构的多个数据结构元素，其对应于多个连接元素。做出确定是否需要其他处理的决定(650)。如果不需要，则对每个识别出的连接元素上的数据结构进行处理，以确定每个识别出的连接元素的命令数据元素(660)。然后，用类型670分隔命令。图6c是来自图6b的hcdas的示例性命令功能的流程图。图6b中的命令由类型670分隔。命令数据首先被处理，以确定进一步的处理。这些类型包括搜索命令674、聚合命令676、发布和订阅命令678以及本地化推断命令。一旦确定，命令就被执行以用于搜索684、聚合686、发布和订阅688以及局部推断680。一旦对所有标识的连接元素完成了命令的处理结果，就对所述数据进行注释以形成查询数据集690。所述查询数据集是初始查询的结果以及作为所处理命令的一部分采取的任何动作的结果。所述查询数据集被提供692到通用计算机，以由进行初始查询的用户及/或系统使用。一旦语义引擎完成其相关联的操作，所述处理就继续图6d中的规则引擎流程694。图6d示出了用于hcdas的操作规则生命周期操作的实施例的流程图。操作规则的好处之一是在其生命周期方面是尽可能地灵活。作为许多示例之一，降低热水供应温度的规则可能仅在周末致动，然后停止。规则生命周期的实施例通过使用诸如图形用户接口的人机接口(hmi)来管理生命周期状态，从而允许用户及/或系统满足要求。应当理解，规则可以彼此交互作用。操作规则合作是规则的动作部分将会被包含在功能中的地方。所述动作可以例如将具有特定字符串的警报发送到监视程序或管理平台。为每个执行相同功能的规则指定单独的操作将是多余的。允许规则之间的合作具有共享功能重复使用的好处。一个结果可能是较少的规则定义，并允许用户及/或系统使用现有功能，而不必为每个实例创建新功能。关于操作规则的动作部分，可以选择一种设计，以在执行的动作类型方面给予用户尽可能多的自由。这些动作可能包括控制设备、发送警报及/或定义新规则。为了实现这一点，设想了允许用户将动作部分描述为定制功能或预定义功能的想法。操作规则的一项功能是在激活或禁用方面尽可能地灵活。作为一个示例，降低热水间歇泉温度的规则可能仅在周末激活，然后停止。规则生命周期允许用户通过使用例如hmi来执行此操作，在其不同生命周期状态之间切换规则来轻松满足此要求。应当理解，这些系统也可以自主地起作用或与用户和系统输入的组合一起起作用。规则和用于规则的生命周期有几种可能的状态。这些包括但不限于设置为自动运行695，如果规则完成则处于已解决状态696。在活动状态697中，如果尚未评估规则的组件，则规则已过期698或以其他方式完成操作，及/或规则已被弃用并应将其卸载699。应该意识到，鉴于可以以编程方式更改其操作的能力，因此规则生命周期的排列是巨大的。规则生命周期的性质对于特定环境是高度可定制的。如前所述，规则的动作部分将被包含在函数中。动作可能与带有特定字符串的警报发送到监视中心或管理设备一样通用。为每个执行相同功能的规则指定单独的操作将是多余的。允许规则之间的合作可确保共享功能被重复用。结果是减少了规则定义，这使用户或系统可以使用现有功能，而不必从头开始创建新功能。从前述内容应该理解；结构化语义查询的使用解决了两个不同的问题。首先，要解决从包含各种数据结构的连接系统传递的数据异构性问题。第二个是从连接元素中过滤和聚合异构数据，并仅向用户、云平台或其他存储库提供所需和相关的数据。还应当理解，语义搜索可以作为独立系统存在，所述独立系统从任意数量的连接源接收数据。在一个实现中，集成解决方案–hcdas可以利用执行的操作规则来分析，创建，开发，执行和控制各种连接的设备，这是可能的。例如，由语义搜索引擎生成的数据可以依次提供给规则引擎，并通过开发与特定系统相关联的语义规则引擎控制器动态执行的操作规则来加以利用，以分析，创建，控制和执行所述系统上的任务，或存储在库或其他存储库中并在其他系统上使用。在另一实施方式中，规则引擎可以作为独立系统及/或系统模块存在，所述系统及/或系统模块从任意数量的连接源接收数据。再次，可以开发和执行语义规则以促进对连接源的控制以及对选定系统的控制策略。可以在运行时配置所述控制策略而不会中断设备的操作，并且规则生命周期可以与任何或所有操作规则相关联，以允许对选定的(多个)系统进行可靠的管理。有效的能源管理，尤其是适当控制和监视的问题，都在考虑之列。当前的解决方案不能解决一些、许多及/或所有这些问题。识别出的可能不存在的功能的示例包括：表达可以自主控制设备的操作规则的方法，表达当检测到特定条件时通过警报通知监视系统的操作规则的方法，将这些操作规则部署到以下位置的方法：在本地或远程使用不同的单元，一个规则引擎能够评估操作规则，根据设备和测量的地理位置和元数据(metadata)进行识别，以及检测和解决冲突的操作规则。一些示例包括智能建筑环境中的多个传感器，这些传感器可用于收集有关环境状态的尽可能多的信息。基于这些测量，可以通过控制某些致动器来操纵环境以达到新的期望状态。此外，可以使用这些测量值激活警报并进行监视。可以通过指定以下格式的操作规则，称为eca(事件条件操作)操作规则，来实现此控制和监视：当事件e发生时，如果条件c＝＝真(true)，则触发动作a，其中：事件提示评估规则。一个示例是计时器用尽或某个设备变得可用。条件指定事件发生时评估的规则部分。例如，当测量温度的设备记录到30℃以上的温度时。条件评估为真时要执行的操作。分别执行控制和监视的操作示例如下：将空调设备的温度设置为22摄氏度。向监控中心发送警报，指定已检测到可能的luaj灾。创建及/或编辑的操作规则可以部署在现场的各个单元上。最佳地，这必须是一个简单而快速的过程，以便可以尽快观察到这些操作规则的好处。此外，有可能在本地(例如，由现场专员)或远程(在以后部署新的操作规则时降低成本)部署操作规则。一旦在单元上部署了操作规则，每个单元的规则引擎可能会负责管理这些操作规则。规则引擎可以驻留在现场的每个单元上，也可以基于虚拟单元而成为云。规则引擎可能能够动态接受和删除操作规则。规则引擎可能能够满足一系列管理需求，以管理部署在其上的所有操作规则或某些子集的操作规则，同时跟踪哪些操作规则被激活或停用。规则引擎可以侦听事件，并且一旦接收到事件，规则引擎就可以检测到与所述事件有关的所有、一些或没有操作规则。然后，它可以评估每个操作规则的条件部分。最后，可以针对评估被认为是正确的操作规则执行动作。关于操作规则的条件和操作部分，可能存在以下功能：规则引擎可能能够使用来自多个设备的值来评估由逻辑和算术比较器组成的复杂条件；规则的操作部分应为用户提供最大的灵活性，允许其从简单的操作(如发送警报)到更高级的操作(如控制及甚至进一步定义新的操作规则)。现场中的每个单元可以连接到许多设备。这些设备不一定在用户调试设备的同一时间连接，并且可能只能在更晚的阶段添加。简而言之，配置本质上是动态的。此外，并不总是很明显每个设备都具有什么功能。为了解决这个问题，可以定义一种抽象语言，所述抽象语言能够识别设备及其功能，并指示何时设备可用或不可用。这将允许用户通过抽象语言定义可能不严格绑定到特定设备的操作规则，而是绑定到描述设备的属性的操作规则。抽象语言如何增强规则的一个可能示例可以基于建筑物内测得的平均温度。如果基于在创建规则时可用的当前设备来定义规则，则当将新的测量温度的设备添加到建筑物中时，规则可能不知道新设备。本公开考虑以这样的方式创建操作规则，使得它们在创建时独立于设备并且在评估时可以依赖于设备。操作规则还可以基于设备的属性而不是特定设备本身。解决方案可以允许多个利益相关者根据他们的需求添加特定的操作规则。这增加了达到某些状态的可能性，其中多个用户的操作规则可能会相互冲突。本公开内容预期检测到这些冲突。此外，所述冲突检测之后可以是解决策略，所述解决策略例如不允许其操作规则，修改一组冲突的操作规则及/或基于其显着性及/或优先级来执行操作规则。图7示出了用于hcdas的操作规则条件操作的实施例的流程图。操作规则可以设计为包含条件。操作规则的条件部分设计得非常灵活。条件可以包括对多个资源及/或功能的评估。基本条件可以定义为仅考虑一种资源或能力的条件。因此，规则的条件部分可以由逻辑运算符组合的多个基本条件的评估组成。作为一个示例，用于使用资源及/或能力的定义来获得设备的度量的语法可以是：[resource]capability以及一范例：[multisensora]temperature基于以上定义，如何由多个基本条件组成条件的示例如下，并在图7中进行了说明。condition:[multisensora]temp>25_cand[doorsensorb]isopen＝＝truebasiccondition1:[multisensora]temp>25_cbasiccondition2:[doorsensorb]isopen＝＝true可以使用的逻辑运算符的示例是and及/或or。可以使用的比较器示例包括：＝；<；_；_；<>；>。定义了各种类型的基本条件，可以对资源及/或功能进行广泛的评估。这些包括但不限于：resourcecapability:()当目前对特定资源和功能的度量很重要时，可以使用此条件。示例语法为：[multisensora]temp>25_c。这允许评估能力何时达到某个阈值(<；_；_；>)或等于/不等于特定值(＝；<>)。resource:此条件允许将“资源已连接”事件指定为条件。示例语法为：@exist[multisensora]＝true。resourcecapabilitychange:需求可能超出仅评估测量的当前值的范围。能力的状态及/或值的改变可能是令人感兴趣的。所述条件允许定义能力值的变化。示例语法为：@change[doorsensor]doorstate＝true。这种类型的评估可能有益于指示状态的功能，例如与窗口是打开还是关闭相对应的度量。resourcecapabilityincr:条件resourcecapabilitychange：的评估可以进一步区分增加和减少的条件更改。每当能力值增加时，此条件的评估结果为真(true)。示例语法为：@incr[multisensora]temperature＝true。resourcecapabilitydecr:与条件resourcecapabilityincr：相似，当能力值减小时可以使用此条件。示例语法为：@decr[multisensora]temperature＝true。通过逻辑运算符and及/或or组合大量条件的能力使用户及/或系统可以指定与特定要求有关的有益条件。由于语义搜索引擎是基于上下文的，并且不需要知道资源和功能的名称，因此可以通过位置、设备类型、协议及/或物理测量功能来表达任何兴趣。语义搜索引擎将以上下文方式返回匹配这些兴趣的相应资源。操作规则可能具有关联的操作。关于操作规则的动作部分，可以选择一种设计，以在可以执行的动作类型方面给予用户及/或系统尽可能多的自由。示例动作可以包括但不限于控制设备、发送警报及/或定义新的操作规则。设想了一种允许用户及/或系统将动作部分描述为定制功能或预定义功能的方法。在一个示例中，hcdas与语义搜索一起工作，以使设施管理员能够确定和利用设施中任意数量的设备生成的数据。除了确定设备数据之外，hcdas还可用于根据已接收和已处理数据为无设备、一些设备及/或所有设备配置参数。在一示例中，所连接的设备可以在一定间隔之后发送其数据，并在发生某些事件时发送警报。一段时间后，所示设施可能会安装新的空调单元，以通过调节相关压缩机的使用来管理温度。现在，设施管理员可能还希望使用语义搜索来查询有关这些新空调单元的信息，并当它们消耗的能量超过用于节省能量的特定预定阈值时，利用从hcdas派生的操作规则将其关闭。可以以满足以下目的的方式设计操作规则，(1)评估与资源和功能有关的条件，(2)在满足这些条件时执行对资源和功能的控制，(3)在满足特定条件时通知用户；(4)为每个规则提供生命周期，以允许安装、激活、停用及/或卸载规则，及/或(5)在操作规则之间进行合作，例如允许多个操作规则重复使用相同的动作定义。规则的条件部分可以设计为非常灵活。条件可以包括对多种资源和能力的评估。基本条件可以定义为仅考虑一种资源或能力的条件。因此，规则的条件部分可以由逻辑运算符组合的多个基本条件的评估组成。从所述实施例中，通常存在两条路径来促进语义搜索的实施，语义规则引擎控制器或hcdas，以分析、制定及/或执行操作规则。首先，是利用量身定制的解决方案，其中针对特定实施例构建搜索或操作规则，并且随着新要求的出现，重新配置新解决方案。所述选项可能无法很好地扩展，并且可能成为快速适应新实施例或更有效地实施新操作规则的障碍。第二种选择是拥有一种可以实施的更灵活的解决方案，所述解决方案不需要重新配置完整的解决方案，并且可以实现语义搜索，语义规则引擎控制器或hcdas的优势。在所述实施例中，潜在的解决方案可以具有以下特征：(1)以明确的方式表达需求和条件，以控制设备及/或发送警报；(2)这些需求的部署策略可能会在设备中本地化；(3)有效地以编程方式执行这些要求的机制；(4)上下文查询功能，以获取有关设备当前状态及/或能耗或系统的任何其他所需特性的见解。除了这些要求之外，所提出的解决方案可能适用于嵌入式环境，易于集成到任何现有设备中，采用模块化设计以允许解决方案的发展，而与设备类型无关，及/或与协议或应用程序域限制无关。图8示出了hcdas的可扩展的替代实施例。应当理解的是，hcdas和相关联的组件可以被植入任何数量的技术。示例包括但不限于jess，jbossdrools，lua及/或openrules。在一个实施例中，由于以下因素而选择了lua：(1)已经为嵌入式系统开发了lua；(2)lua是开源的，拥有强大的用户群；(3)系统的非技术用户可以理解lua语法；(4)lua允许多种表达方式；(5)lua拥有多种语言的轻量级开源解释器，包括java和c，从而促进了不同产品之间的集成。在所述实施例中，规则可以被编写为lua脚本，然后由lua解释器执行。java和c版本的规则引擎都是针对提供相似功能的不同硬件平台开发的。支持功能可以包括java或c函数的列表，以提供对订阅的支持以及用于规则执行的计时器。lua解释器可以创建一个执行环境，并确保多个规则在执行期间不会相互干扰。lua还允许规则调用普通的java或c函数，其实际实现已通过java方法或c函数来完成。通过这些实现可以支持其他功能，规则可以相应地简单调用这些功能。此外，引擎api模块可以提供功能。应当理解的是，可以使用其他适当的编程语言来达到期望的效果。在另一个实施例中，将java版本的hcdas部署在商用现成的工业网关设备上，所述设备可以使用modbus1，以太网(ethernet)，wi-fi及/或gprs接口连接到各种设备和远程云平台等。网关可以使用带有ibmj9的linuxos作为java虚拟机(javavirtualmachine；jvm)。j9专用于嵌入式系统，并已通过工业用途认证。开放服务网关计划(openservicegatewayinitiative；osgi)的prosyst2实现是在j9上使用的框架，以促进在prosyst2上运行的软件组件的模块化设计。hcdas可以实现为一个这样的组件。在又一个实施例中，针对不同的硬件平台实现了hcdas的c版本，所述硬件平台基于双核cortexa9芯片，时钟频率为900mhz，具有1gbram。应当理解，可以使用其他硬件平台。hcdas也可以为嵌入式系统运行linux4。连接选项包括但不限于zigbee、以太网、蓝牙(bluetooth)及/或wi-fi。hcdas可以作为posix兼容库开发，可以导入其他客户端应用程序项目。使用语义引擎的设备和测量标识可以允许基于设备和测量的元数据来对设备和测量进行引用和检测。可以创建本体以给出能量管理领域的知识表示(knowledgerepresentation)。这可以允许规则引擎然后针对所述本体运行查询，以基于它们的元数据来识别某些设备和测量。这非常有用，因为当前系统可能不允许轻松访问至设备唯一标识符。此外，由于拓扑可能会由于添加或删除设备而发生变化，因此语义引擎可以跟踪这种动态性质，从而确保查询结果是最新的。语义引擎的另一个好处是，本体模型可以定义实体之间的关系。作为示例，用户可能对位于城市中的所有设备感兴趣。本体模型可以允许语义引擎检测不到、一些及/或所有设备，即使用户从未明确指定所述设备在城市中也是如此。由于在本体模型内定义的传递关系指出了特定资源的特定位置，因此这是可能的。规则引擎可以通过luajavaapi函数/方法rule.query与语义引擎进行交互作用。这样的功能包括但不限于：(1)根据其元数据(例如位置)查询资源和功能的名称，(2)基于资源的元数据订阅规则，以确保即使添加或删除了资源，规则也保持相关性。这允许规则是动态的，并且可以消除每次拓扑变化发生时更新规则的需要。(3)允许其他功能，例如计算测量结果的汇总(例如，平均值(avg)，最小值(min)，最大值(max)，总和(sum))，并根据其元数据组合某些资源。语义引擎提供的各种推断有助于利用这些汇总。下面给出了上述每种情况的语义引擎语法示例。searchresourceusage:powerandloc:conferenceroom返回位于斯托曼(stallman)的所有测量功率的资源的列表。subscribecapabilityusage:temperatureandloc:conferenceroomwithvalue>25订阅一个规则，当会议室中的能力测量温度值大于25时，满足条件的规则(为清楚起见，省略了操作部分)。avgvariableusage:temperatureand@loc:floor_1计算位于楼层1的所有设备测得的平均温度。@符号表示应使用推论。图9a至图9n示出了hcdas的lua实现细节的各种示例性实施例。应当理解的是，存在多个用于表达操作规则的软件包，其中还包括集成的规则引擎。这些示例包括但不限于jess，jbossdrools和openrules。应当理解的是，可以使用许多具有类似效果的工具。lua可能是一种制定规则的工具，它具有以下优点：嵌入式系统的内存限制需要非常小的代码库；规则引擎和java版本的交互作用；非技术用户可以使用非技术语法来表达规则；从非常基本的规则到高级规则的规则表达的复杂性；一般用户熟悉lua语法；及存在一个轻量级的lua至java的开源解释器，luaj，它便于与当前的oneesp软件轻松集成。要将lua集成到现有框架中，优选的是从lua到java的解释。考虑了两种不同的开源lua解释器：luajava和luaj。其他解释器是可用且也可以使用的。luaj库允许在java平台上执行lua脚本，以及将lua函数绑定到java方法。这是有益的，因为它允许lua脚本调用常规lua函数，而其实际实现位于java方法中。规则引擎利用此功能在java中实现规则的订阅，即使所述订阅被用户视为正常的lua函数调用也是如此。为了允许使用lua订阅和管理规则，脚本必须符合指定的语法。特殊格式允许lua脚本包含操作规则描述，以及向脚本和关联规则添加生命周期。此外，可以将某些lua功能定义为在满足规则条件部分时要执行的动作部分。实现此目标的示例包括：lua脚本可以通过定义一个与脚本文件同名的空lua表开始。由于将存在多个脚本，因此这些表可用于存储脚本的所有将来功能，从而可以区分不同lua脚本的功能。脚本中的所有函数声明都可以包含在开头创建的lua表中。这可以通过将脚本名称附加到每个函数的开头来实现。lua脚本可以声明一个初始化函数，所述脚本在系统上激活时将被调用。函数名称称为init，可以包含要添加到系统中的所需规则。lua脚本可以声明一个终结函数，当所述脚本从系统中删除时，所述函数将被调用。函数名称可以称为定案(finalize)，通常包含在脚本删除过程中要执行的任何功能，例如通知监视中心所述删除操作或释放资源。lua脚本可以声明一个info函数，所述函数提供有关脚本目的的人类可读信息。各种代码表示对与规则定义相关的函数的调用。操作规则的一个目标是评估一设备和多个控制设备的测量结果。从示例中，现在可以根据资源和功能的定义来描述以下代码，例如：rule.subscribe：将规则添加到规则引擎以进行评估。rule.unsubscribe：从规则引擎中删除特定规则。rule.getcapabilityvalue：返回给定资源的特定测量能力值。rule.setcapabilityvalue：为给定资源设置特定的可控制能力值。rule.alarm：向rsp发送警报以进行监视。这些功能允许对规则库进行生命周期管理以及与任何设备及/或资源的交互作用。上述功能和与规则引擎相关的其他功能的集合被包含在以后称为luajavaapi中。本文描述了规则引擎的实现，所述规则引擎处理通过改编的lua脚本订阅的操作规则。在图9b中示出了规则引擎组件。所述规则引擎组件是一个定制组件，可以添加到硬件及/或软件平台。通过添加此软件组件，除了典型的数据记录功能之外，硬件及/或软件平台还提供了指定规则的功能。图9a说明了规则引擎组件的不同捆绑包如何装配在一起。包含规则的lua脚本需要部署到硬件及/或软件平台。lua脚本管理接口捆绑包以三种不同的方式向用户公开，以允许进行此部署。lua命令行捆绑包使用硬件及/或软件平台的标准命令行/终端公开接口。本地hmi包公开了用于通过网页浏览器(webbrowser)远程访问单个硬件及/或软件平台的接口。lua-rsp代理程序包通过rsp代理程序的消息处理程序服务向rsp公开接口。所述消息服务与lua远端hmi(luaremotehmi)交互作用。它允许通过网页浏览器对多个硬件及/或软件平台进行远程lua脚本管理。lua脚本管理接口捆绑包中定义的接口可以在lua引擎捆绑包(luaenginebundle)中实现，其目的是声明一个接口，所述接口指定可以应用于lua脚本的不同动作。这些动作允许在lua脚本的不同生命周期状态之间进行转换。一个lua脚本可以处于两种状态(已解析(resolved)，活跃(active))，可以通过四个不同的动作来访问。每个动作的含义如下：安装(install)–加载lua脚本，并且所述脚本中的所有功能都可以使用。开始(start)–调用lua脚本init函数，并且现在由规则引擎评估init函数中声明的所有规则订阅。停止(stop)–调用lua脚本的finalize函数，并从规则引擎中删除所述脚本进行的所有规则预订。卸载(uninstall)–脚本已卸载，并且脚本声明的所有功能均已从系统中删除。所述捆绑包含有一个接口，名为luascriptmanagement接口的以及一个名为luarulestructure的帮助程序类。上面提到的四个动作构成了luascriptmanagement接口方法的基础。添加了两种其他方法来辅助脚本管理，一种方法提供有关特定脚本的信息，另一种方法指示所有脚本的状态。luarulestructure专门用作由getlistofexistingscripts方法返回的列表中的对象。此类的实例包含可用于通过不同的人机接口(hmi)向用户显示的信息。有趣的是，与lua脚本生命周期相对应的接口方法返回一个布尔值(boolean)，指示操作是否成功。还要注意，还要注意，所述方法installluascript过载并且可以采取一个字符串或一个文件作为参数。前者由luacommandline捆绑包使用，而后者由本地luahmi(localluahmi)和lua-rspagent使用。最后要注意，方法getlistofexistingscripts的列表<luarulestructure>(list<luarulestructure>)的返回类型只是为了清楚起见而指定，实际实现是在jre1.4(java运行时环境1.4)中，它不支持通用型(generic)。lua命令行捆绑包通过命令行公开luascriptmanagement接口。可以通过键入以下示例命令来访问接口的不同方法：lua.install<lua文件位置>；lua.start<lua文件名>；lua.stop<lua文件名>；lua.uninstall<lua文件名>；lua.info<lua文件名>；lua.ls。所述捆绑包含有一个名为luacommand的类，所述类实现prosystosgi框架的接口pluggablecommands。所述类的代码简单明了以及根据通过命令行给出的命令调用luaengine接口的正确方法所组成。捆绑包不会验证通过命令行发送的参数是否有效，而是由luascriptmanagement接口的特定实现来完成。这样做的动机是将验证集中在luascriptmanagement实现中。否则，将必须在公开luascriptmanagement接口的每个服务上独立完成验证。lua本地hmi通过现有网页接口(webinterface)上名为控制(control)的选项公开单个硬件及/或软件平台框的luascriptmanagement接口。上载按钮与安装相对应，在安装后，脚本将显示在包含可用规则的表中。然后可以分别单击“活跃(active)”或“已解析(resolved)”按钮来启动和停止它。通过单击脚本旁边的垃圾桶图标可以卸载所述脚本。hmi的设计使其适合现有的网页接口，并确保用户易于使用。捆绑包可能包含以下类别：luaadapterservlet：负责处理来自客户端的http获取和发布请求，并调用luaengine接口的相关方法。luaadapter：osgi组件，所述组件在激活时将luaadapterservlet类的实例注册到uri名称空间中。这使得小服务程序(servlet)可以使用。luasettings：为luaadapterservlet的不同http方法设置特定的权限级别。servletconstant：捆绑包中经常使用的常数。此外，可以使用网页接口的标准样式表(.css)。为了允许动态显示lua脚本，使用了杰出java(knockoutjava)脚本库。lua本地hmi捆绑包(lualocalhmibundle)允许通过hmi访问单个硬件及/或软件平台上的luascriptmanagement接口。但是，需要能够使用单个hmi远程访问多个单元的luascriptmanagement接口。为此，创建了一个网页hmi(webhmi)，所述网页hmi将消息发送到rsp平台，然后rsp平台将这些消息转发到相应的硬件及/或软件平台。lua-rsp代理程序捆绑包驻留在硬件及/或软件平台上，并负责解释这些消息并调用luascriptmanagement接口的相应方法。hmi捆绑包可能由以下类别组成：luarspmessagehandler：处理从rsp发送到与lua相关的设备的消息，并调用相关的luaengine接口方法。扩展rsp代理捆绑包的messagehandler类，并实现了抽象的handlemessage方法。luarspreceiver：负责将luarspmessagehandler实例注册为osgi框架上的服务。发送和接收的示例消息包括以下内容：预期设备的地址；包含三个content对象的列表，带有以下字段：类型(type)–(总是应用程序/文本)；字段(field)–(指示要遵循的数据类型)；档案名称(filename)–数据包含lua脚本的名称；动作(action)–数据包含如何处理脚本(安装/启动/停止/卸载)；base64–如果已安装所述操作，则指示要跟随的数据是lua脚本的文本，并以base64编码；数据(data)–(实际信息)。luarspmessagehandler从消息中提取必要的信息，并调用相应的luascriptmanagement方法。目前，luarspmessagehandler可能未回复rsp以指示消息已成功传递(它是异步的(asynchronous))。lua引擎捆绑包包括项目期间完成的大多数开发。它首先实现luascriptmanagement接口，从而可以有效地管理lua脚本。其次，它负责评估所有规则的条件并执行相应的操作。给出了捆绑包中包含的所有软件包的概述，然后深入介绍了每个软件包中的类和功能。lua引擎实施捆绑包分为不同的java包，不同的java包将彼此不同的逻辑功能分开。如软件包名称所示，此软件包包含捆绑包的主要功能，并且是希望使用此捆绑包的其他捆绑包的入口。不同类的描述阐明了lua引擎是如何进行操作：与数据模型捆绑包交互作用；与rsp代理程序捆绑包交互作用；解释lua脚本；及将lua函数绑定到java方法。lua.engine.main软件包包含四个类：1.luaengineimpl：此类的目的是实现luascriptmanagement接口。此类已在osgi平台上注册为服务。这允许服务注册表将需要luascriptmanagement服务的捆绑包(lua命令行，本地luahmi，lua-rsp代理)匹配到所述类。在捆绑包启动时发生以下事件，分别允许lua引擎组件与rsp代理、数据模型和语义引擎组件之间进行交互作用。osgi平台确保提供对以下类的实例引用：resourceregistry–注册表，其中包含连接到硬件及/或软件平台的所有设备(使用数据模型组件)。eventhelper–将事件发送到rsp(使用rsp代理组件)。isemanticengine–引用语义引擎进行设备和测量的标识(使用语义引擎组件)。为lua解释器(luaj)创建一个称为全局变量(globals)的默认lua表。所述表包含与lua相关的所有标准库和功能。将luajavaapi的实例添加到全局变量表(globalstable)。这允许将java方法作为lua函数进行访问。这将在下面的b节中讨论。2luajavaapi：此类的目的是在java中定义可以从lua调用为函数的方法。这包括允许lua脚本从规则引擎添加或删除规则的方法，这些规则称为“订阅(subscribe)”和“取消订阅(unsubscribe)”。3.const：包含用作常量的静态最终对象。使用它们而不是枚举类型(enumtype)的原因是java版本1.4不支持枚举类型。它包含某些经常使用的字符串以及用于存储lua脚本的目录路径。4.luascriptstatuschecker：一个帮助程序类，负责跟踪lua脚本所在的状态(已解析(resolved)，活跃(active))。安装lua脚本时，必须遵循指定的某种格式。所述软件包旨在验证是否满足这些规范。所述软件包本身包含一个接口luascriptvalidator及其实现luascriptvalidatorimpl。实现的两种方法及其执行的测试是：booleanvalidatemandatoryfunctions(stringscriptname)：检查lua脚本名称不是luaj解释器中使用的保留字，例如要求(require)或数学(math)。由于脚本具有覆盖例如包含lua数学库的全局变量中包含的现有lua表的功能，因此已进行检查。booleanvalidateluascriptformat(stringscriptname)：检查在lua脚本中是否声明了强制函数init，定案(finalize)，订阅(subscribe)和取消订阅(unsubscribe)。这个概念包括范围检查和操作规则的语法。脚本通过验证后即可安装。下一步是在脚本启动时订阅在lua脚本init函数中声明的所有规则。luajavaapi可用于将规则订阅到规则引擎。添加规则后，lua.engine.subscription软件包将负责处理这些规则。规则是eca(事件条件操作)类型。所述软件包的目的是侦听事件，评估相关规则的条件，并在满足条件时执行操作。所述软件包的整体功能在图9c中示出。对于每个lua脚本，将使用对应于规则条件部分的键创建一个映射。每个键都映射到与特定条件有关的动作。luajavaapi用于在映射中添加或删除规则。然后，软件包侦听事件并确定相关规则。之后，规则条件部分的评估将委托给lua.engine.parser软件包。如果满足条件，则软件包通过使用luaj解释器或luajavaapi中指定的方法调用lua函数来执行操作。subscriptionlistener类实现了osgieventhandler接口，允许其接收事件。规则的条件部分设计为非常灵活的，可补偿osgieventhandler事件施加的限制。不同类型的基本条件可以存储在单独的软件包中。操作规则的条件部分构成了以下类定义的基础。规则的条件部分的实现在图7a中示出。对于规则的每个条件，都会启动条件类(conditionclass)的实例。所述实例包含所有基本条件的列表，这些基本条件根据不同的基本条件可以是五种不同的类型。这允许表达进阶条件，这些条件也集成了规则的事件部分。对应于基本条件的不同类别的示例在下面列出并在图9d中示出。resourcecapability；resource；resourcecapabilitychange；resourcecapabilityincr；resourcecapabilitydecr。所述程序包中提到的类允许评估各种条件。每个类的getlefthandsideofcondition方法不同，并且在条件评估期间使用。通过逻辑运算符and和or可以组合无限数量的基本条件的能力使用户可以指定与其要求相关的有意义而强大的条件。如本文所述，完整条件包括多个基本条件。完整的条件将使用luajavaapi作为字符串传递给规则引擎。所述软件包的目的是双重的：解析包含完整条件的字符串，以构造不同的基本条件对象。评估完整条件以查看是否应执行规则的操作部分。解析允许构造不同的基本条件类型。在评估时，与这些对象相对应的值将替换它们在条件字符串中的相应部分(getlefthandsideofcondition方法)。现在如图9e所示评估完成条件。请注意，根据基本条件的类型，将返回不同的值。resourcecapability对象返回所述功能的当前值，而与其他类相对应的对象则根据是否满足基本条件而返回真(true)或假(false)。然后可以如图9f所示评估算术表达式。虽然选择了exprjava库来执行条件的分析和评估，但可以根据以下条件来选择其他库：小代码量(22千字节(kbytes)jar)非常适合嵌入式系统；源代码的开源性质；及清晰的api和文档齐全的代码允许进行修改。必须对expr库进行一些修改。由于它主要是作为表达式评估器而开发的，因此对代码进行了少许修改，增加了解析功能。这允许提取必要的数据以构建我们的基本条件对象。可以预见，将来解析和表达/条件评估可能会有所不同。例如，如果条件语句在某种程度上超出了expr库的解析器的功能，则可以将antlr用作解析器。出于这个原因，接口和实现是完全分开的(松耦合(loosecoupling))。这样，将来可以使用完全不同的技术来更改确切的实现。上述灵活性是使用中指定的工厂设计模式(factorydesignpattern)实现的。使用以下两种方法创建了称为conditionparserevaluator的接口：booleanevaluatecondition(字符串条件(stringcondition))–评估完整条件，如果满足条件，则返回真(true)。setconstructbasicconditionsfromcondition(字符串完成条件(stringcompletecondition))–返回一个集合，其中包含与条件语句有关的所有第4.2.4.5节中指定的基本条件对象。图9g示出了使用工厂设计模式的软件包的简化uml图，所述工厂设计模式确保了用于条件解析和评估的松耦合。各种软件包可以构成规则引擎捆绑包。它解释了用于添加lua脚本以及评估lua脚本中包含的规则的不同逻辑组件。仍然需要解释的是lua脚本中的规则定义如何精确地订阅到以java代码实现的实际规则引擎。luajavaapi包含设计的lua函数的库，这些lua函数绑定到java方法并在图9h中进行了说明。所述api允许用户通过lua脚本与硬件及/或软件平台单元上的osgi组件进行交互作用。这些java方法都可以通过称为rule的lua表访问，所述表在捆绑包激活时间时添加到lua表全局变量中。为了允许将规则添加到规则引擎，将调用lua表(rule)中包含的订阅函数，所述订阅函数又调用luajavaapi类中的相应java方法并将规则添加到规则引擎。在lua中调用订阅函数的语法如下：rule.subscribe(scriptname，rulecondition，functiontable，function，arguments...)字符串scriptname向规则引擎指示哪个lua脚本加载了规则。字符串rulecondition包含规则的完整条件部分。从参数3开始的所有参数都与规则的操作部分相关，如下所述。规则的操作部分被设计为lua函数，以便为用户提供更大的灵活性。所述函数可以包含在lua脚本中，也可以作为映射到luajavaapi的java方法的lua函数的一部分。回想一下，每个lua脚本都以与脚本相同的名称存储在其自己的lua表中。因此，只需指定以下内容即可从任何lua脚本调用任何函数：字符串函数表(stringfunctiontable)，可以是脚本名称或与luajavaapi对应的“rule”。字符串函数(stringfunction)，要调用的实际函数。参数(arguments)，要传递给函数的参数列表。luajavaapi包含其他一些函数/方法，如下表4所示。其中最重要的是：setcapabilityvalue–允许使用数据模型组件服务控制智能设备。sendalarm–允许使用rsp代理组件将警报或其他事件发送到rsp。通过分别调用订阅和取消订阅功能，可以在规则引擎中添加和删除lua脚本中定义的规则。此外，它还引入了允许与数据模型和rsp代理组件进行交互作用的功能。这增加了控制和事件功能。lua引擎捆绑包的入口点是通过调用luascriptmanagement接口的方法或事件的发生来实现的。图9i示出了当安装了lua脚本时的程序流程。回想一下，全局变量是一个lua表，luaj解释器从所述表访问所有与lua相关的功能。图9j示出了当启动lua脚本时的程序流程。最后一步是调用脚本的init函数。这将执行此功能内的所有命令。通常，规则的订阅将在此功能内进行。由于这个原因，在调用图9k所示的订阅功能之后的程序流程就流向所述程序。图9l示出了当lua脚本停止时的程序流程。它调用脚本的定案(finalize)函数。通常，取消订阅(unsubscribe)规则将在此功能内进行。取消订阅(unsubscribe)函数从lua.engine.subscription软件包创建的映射中删除指定的规则。这样设计的目的是，如果用户未指定规则的明确取消订阅，则在脚本停止时，软件将暗中删除所述规则。这是最佳做法，因为它不假定用户将进行必要的清理。图9m示出了当卸载lua脚本时的程序流程。通过删除具有与lua脚本名称相同名称的表，可以从全局变量表中删除所有脚本功能。一旦检测到事件，lua.engine.subscription软件包将开始规则评估。它遍历所有规则，将条件评估委托给lua.engine.parser软件包。如果满足条件，则它通过使用luaj解释器调用相关的lua函数来执行相应的动作部分，如图9n所示。lua远程hmi完成与lua本地hmi相似的任务，不同之处在于与远程hmi可以与多个单元进行通信。为了允许lua脚本管理，它将格式的消息发送到rsp，然后rsp将其转发到相应的框。灰色规则表示尚未激活的已解析规则。此外，hmi还显示通过rsp代理发送到rsphmi的事件，其中包含用于规则管理和事件监视的网页前端(webfront)。远程hmi是基于rest体系结构来建构。查询功能可以直接在lua脚本中使用，以利用语义引擎。但是，使hmi也允许临时查询也很有用。一个示例显示了hmi，其中显示了基本查询的语法和结果。尽管hmi部分构成了项目的一部分，但本文档中并未详细讨论其实现。在本公开的各种实施例中使用的任何通用计算机系统可以是例如通用计算机，诸如基于intelpentium型处理器、motorolapowerpc、sunultrasparc、hewlett-packardpa-risc处理器或任何其它类型的处理器的那些计算机。例如，本公开的各种实施例可被实现为在通用计算机系统1000(诸如图10所示的计算机系统)中执行的专用软件。计算机系统1000可包括处理器1020，其连接到一个或更多个存储器设备1030，诸如磁盘、存储器或用于存储数据的其它设备。存储器1030一般用于在计算机系统600的操作期间存储程序和数据。计算机系统1000也可包括提供额外的存储容量的储存系统1050。计算机系统1000的部件可由互连机构1040耦合，互连机构1040可包括一个或多个总线(例如，在集成在同一机器内的部件之间)及/或网络(例如，在存在于单独的分立机器上的部件之间)。互连机构1040使通信(例如，数据、指令)能够在系统1000的系统部件之间交换。计算机系统1000还包括一个或多个输入设备1010(例如，键盘、鼠标、轨迹球、麦克风、触摸屏)和一个或多个输出设备1060(例如，打印设备、显示屏、扬声器)。此外，计算机系统1000可包含将计算机系统1000连接到通信网络的一个或多个接口(未示出)(除了互连机构1040以外或作为互连机构1040的可选方案)。在图11中更详细示出的储存系统1050一般包括计算机可读和可写的非易失性介质1110，其中可存储信号，所述信号规定由处理器执行的程序或存储在介质1110上或中以由程序处理的信息以执行与本文所述的实施方式相关联的一个或多个功能。介质可以是例如磁盘或闪存。通常，在操作中，处理器使数据从非易失性记录介质1110中读取到另一存储器1120内，存储器1120比介质1110允许由处理器更快地访问信息。这个存储器1120一般是易失性随机存取存储器，诸如动态随机存取存储器(dram)或静态存储器(sram)。它可位于如所示的储存系统1100中或存储器系统1030中。处理器1020通常操纵在集成电路存储器1030、1120内的数据并接着在处理完成之后将数据复制到介质1110。各种机制已知用于管理在介质1110和集成电路存储器元件1030、1120之间的数据移动，且本发明不限于此。本公开不限于特定的存储器系统1030或储存系统1050。计算机系统可包括特别编程的专用硬件，例如专用集成电路(asic)。本公开的各方面可在软件、硬件或固件或其任何组合中实现。此外，这样的方法、动作、系统、系统元件及其部件可被实现为上面所述的计算机系统的部分或实现为独立部件。虽然计算机系统1000作为例子被示为一种类型的计算机系统，本公开的各种方面可在所述计算机系统上被实施，但应认识到，本公开的方面不限于在如图11所示的计算机系统上实现。可在具有图11所示的不同的架构或部件的一个或多个计算机上实施本公开的各种方面。此外，在本公开的实施方式的功能或过程在本文(或在权利要求中)被描述为在处理器或控制器上执行的情况下，这样的描述旨在包括使用多于一个处理器或控制器来执行功能的系统。计算机系统1000可以是使用高级计算机编程语言可编程的通用计算机系统。计算机系统1000也可以使用专门编程的专用硬件来实现。在计算机系统1000中，处理器1020一般是市场上可买到的处理器，诸如从英特尔公司可买到的公知的pentium类处理器。许多其他处理器也是可用的。这样的处理器通常执行操作系统，其可以是例如从微软公司可得到的windows95、windows98、windowsnt、windows2000、windowsme、windowsxp、vista、windows7、windows10或后代操作系统、从苹果计算机可得到的macossystemx或后代操作系统、从sunmicrosystems可得到的solaris操作系统、unix、linux(任何发行版)或从各种其它源可得到的后代操作系统。可使用许多其他操作系统。处理器与操作系统一起定义了计算机平台，以高级编程语言编写的应用程序应用于计算机平台。应理解，本公开的实施例不限于特定的计算机系统平台、处理器、操作系统或网络。此外，对本领域的技术人员应当明显的是，本公开不限于特定的编程语言或计算机系统。此外，应该认识到，还可使用其他适合的编程语言和其他适合的计算机系统。计算机系统的一个或多个部分可被分布在耦合到通信网络的一个或多个计算机系统当中。例如，如上面讨论的，确定可用的功率容量的计算机系统可位于远离计算机管理器处。这些计算机系统也可以是通用计算机系统。例如，本公开内容的各个方面可被分配于一个或多个计算机系统之间，所述计算机系统被构造成为一个或多个客户计算机提供服务(比如服务器)，或者作为分配系统的一部分执行总的任务。例如，可在包括分布在执行根据本公开的各种实施例的各种功能的一个或多个服务器系统当中的部件的客户端-服务器或多层系统上执行本发明的各种方面。这些部件可以是使用通信协议(例如，tcp/ip)通过通信网络(例如，互联网)通信的可执行中间(例如，il)或解释(例如，java)代码。例如，一个或多个数据库服务器可用于存储在设计与本公开的实施例相关联的布局时使用的设备数据，诸如预期功率抽取。应认识到，本公开不限于在任何特定的系统或系统组上执行。此外应认识到，本公开不限于任何特定的分布式架构、网络或通信协议。本公开内容的不同实施方式可使用面向对象的编程语言编程，比如smalltalk、java、c++、ada或c#(c-sharp)。也可以使用其它的面向对象的编程语言。可选地，可以使用函数、脚本及/或逻辑编程语言，诸如basic、fortran、cobol、tcl或lua。本公开内容的各个方面可在非编程的环境下(比如以html、xml或其他格式创建的文档，当在浏览器程序的窗口中察看时，其提供图形用户接口(gui)的外观或执行其他的功能)实行。本公开内容的各个方面可被实现为编程的或非编程的元素，或其任意组合。在这样描述了本公开的至少一个实施例的几个方面后，应认识到，本领域的技术人员将容易想到各种变更、修改和提高。这种变更、修改和提高旨在成为本公开的一部分，并且旨在本公开的精神和范围内。因此，前文的描述和附图仅仅是示例性的。当前第1页1 2 3 当前第1页1 2 3