具体实施方式
本发明的至少一些实施例意图用于楼宇自动化系统、例如监控、控制和管理楼宇或其它设施内的HVAC操作的系统。其它合适的楼宇自动化系统包括楼宇安全系统、楼宇(消防)安全系统、和楼宇照明系统。
图1示出合并本发明的至少一个实施例的示范性楼宇自动化系统(BAS)100的一部分。BAS包括通信网络102、多个BAS设备104、106和108、多个控制器110、112、工作站114和便携式工具116。
通信网络102可适当地为采用LONWORKS
网络服务(LNS)的网络。LONWORKS
为埃施朗(Echelon)公司的注册商标。如在本领域中已知的,LNS为BAS的元件提供开放协议网络和变量定义。然而,应当理解的是本发明的实施例可在使用其它网络环境的BAS系统中被实施。
BAS设备104、106、108是表示楼宇设施的接口的物理设备。在该例子中,BAS设备包括第一传感器104、第二传感器106、和可变空气量(VAV)执行器108。第一传感器104可适当地为产生环境空气的温度测量的温度传感器。例如,第一传感器104可以是产生代表第一传感器104所处房间内的温度的数据的房间温度传感器。第二传感器106也可以是温度传感器,但位于另一地方,例如在另一房间中,或在通风管道中。VAV执行器108为耦合到未示出的通风风闸的受控执行设备。VAV执行器108响应于控制信号可操作地被耦合以打开或关闭通风风闸。典型地,未示出的通风风闸位于房间的输入管道处或附近,以及在其它地方。VAV执行器108通过打开和关闭风闸来控制进入房间的气流。
商业、工业或多家庭住宅楼宇中的典型的BAS将包括大量传感器、执行器和控制器。因此,图1中所示的少量的设备只作为此处所描述的本发明实施例的说明的说明性上下文背景被提供。
再次特别参照图1,BAS 100的功能之一可以是采用一个或多个传感器、例如传感器104、106所产生的温度信息来控制VAV执行器108的操作。例如,如上所论述的,VAV执行器108可适当地被用来控制通风风闸以便控制进入房间的气流。特别地,VAV执行器108可控制位于冷气管和房间之间的通风风闸。在这样的例子中,如果传感器(例如传感器104)指示房间内的温度过高,则BAS 100可促使VAV执行器108打开通风风闸以增加进入房间的冷气流。反之,如果传感器(例如传感器104)指示温度过低,则BAS 100将促使VAV执行器108关闭通风风闸以减少进入房间的冷气流。这种操作在本领域中是众所周知的。
控制器110和112是典型地执行多种功能的处理设备。控制器110、112的功能典型地在软件或固件应用中被定义,该软件或固件应用在下文中被称为控制器应用,其在控制器110、112中的每一个中被保存和执行。控制器110、112分布在整个楼宇中,并通过网络102相互连接。在大多数BAS系统中,控制器110、112部分地用作各种BAS设备的接口。换句话说,控制器110、112(和特殊地,控制器应用)保存或可以访问与传感器104、106和执行器108相关的或由它们产生的数值。控制器110、112的控制器应用也典型地至少在本地层面上执行控制操作。在图1中所示的例子中,控制器110可操作地连接到传感器104和VAV执行器108,而控制器112可操作地连接到传感器106。控制器110的控制器应用基于从传感器104接收到的温度值确定VAV执行器108是否应当进一步打开或关闭通风风闸,以增加或减少进入房间的冷气流。
控制器在本领域中是众所周知的,并且包括例如可从Buffalo Grove,III的西门子楼宇技术公司得到的Staefa Predator控制器。商业或工业楼宇的典型的控制系统将包括许多例如控制器110、112的控制器。
控制站114是可操作地连接到通信网络102以接收来自所有控制器110、112的信息的计算机工作站。控制站114提供对BAS 100中的许多信息的单点访问,包括监控、管理、控制和复查楼宇和BAS 100中的状况的能力。为提供用户交互性,控制站114也执行多个应用。应用运行以从控制器110、112获得关于系统100的信息并将信息呈现在用户接口、例如图形用户接口中。为提供对控制器110、112上的数据的访问,控制站114上的应用必须与控制器110、112上的控制器应用交互。
作为控制站应用的例子,应用可提供传感器104所处房间内的温度的趋势或历史信息。这种应用将周期性地向控制器110上的控制器应用请求关于来自传感器104的温度的信息。为此,控制站114上的应用将必须访问驱动器或服务器,该驱动器或服务器能够从传感器104获得信息并以已知协议揭露包含温度值的输出。作为例子,如果控制器110为LonWorks设备,控制站114中的应用将通过未示出的LonWorks驱动器或LNS服务器与控制器110的控制器应用通信,该LonWorks驱动器或LNS服务器也将典型地驻留在控制站114中。LNS服务器提供控制站应用能理解的标准接口,并被配置成与LNS控制器应用通信。控制站应用接收来自LNS服务器的数据并处理以执行希望的处理或显示操作。控制站114上的应用通过应用的图形用户接口将信息呈现给用户。
便携式工具116可以适当地为便携式计算机,该便携式计算机能在任何点上连接到通信网络102,或直接连接到网络节点、例如控制器110和112。便携式工具116也执行访问设备、例如控制器110、112中的数据的软件。当来自控制站114的操作不够或不合适时,便携式工具116也可被用于对设备进行故障查找、测试、试运行或重置。如同控制站114一样,便携式工具116的操作必须从BAS 100中的一个或多个设备访问数据。为提供对各种设备中的数据的访问,便携式工具116也必须包括服务器、驱动器或接口、例如与控制站114的LNS服务器类似的LNS服务器。例如,为与控制器110通信,控制站114必须执行与控制器110所执行的一个或多个控制器应用通信的软件。
在对设备进行试运行、测试设备和故障查找时所涉及的步骤根据设备而不同。因此,执行这种操作必需的各种控制器应用的接口也根据设备而大大不同。因而,在现有技术中,单独的代码是有必要的以便针对每个设备类型和制造为每个操作提供用户接口(即在便携式工具116上)。这导致相当大的开发成本。然而,根据本发明的实施例,通过以插件形式创建软件对象来提供对控制器应用(或其它设备应用)的信息的访问。插件由文本定义文件形成。特别地,文本定义文件被主机应用用于形成包括一组利用从目标设备应用接收的或提供给目标设备应用的数据执行所定义的操作的对象的节点,并且还用于形成用于这种数据的图形用户接口。插件的开发或修改可以容易地通过编辑文本定义文件来完成,而不需要大量的软件修改。
相应地,插件在被创建后运行以从驻留在控制器110、112上的控制器应用访问数据,以便提供允许与操作员交换信息的视图或显示。例如,插件允许用户查看由驻留在控制器110、112上的控制器应用所保存的数值,并且也允许用户输入被传递给控制器应用的命令或数据。应当注意的是插件可被配置成访问除了控制器之外的设备、例如传感器或执行器的数据,只要那些设备执行暴露可访问接口的应用。
图2示出图解说明根据本发明的系统和方法的元件的框图。图2中的元件示出形成访问控制器215中的信息的插件的元件的装置,其中该控制器215可适当地表示图1中的控制器110或112。图2中的软件元件和数据文件可适当地驻留在图1中的控制站114和/或便携式工具116上。关于控制站114和便携式工具116的物理配置的细节对于BAS领域中的普通技术人员来说将是已知的。作为例子,控制站114可具有可从西门子楼宇技术公司得到的INSIGHTTM工作站的物理配置。便携式工具116可适当地配备成便携式“膝上型”计算机。
该装置包括XDF文件205、主机应用210、控制器215、第一节点220和接口对象225。XDF文件205、主机应用210、第一节点220和接口对象225可以均适当地驻留在同一物理设备、例如图1中的便携式工具116、或图1中的控制站114中。
XDF文件205是包括到与控制器215相关的特定应用(即控制器应用)的用户接口和数据映射的定义的外部定义文件。为此,XDF文件205包括第一部分230,其定义接口对象225中的一组执行关于第一节点220的输入/输出接口操作的用户接口显示。XDF文件205也包括第二部分235,其定义根据协议特定的数据的第一节点220的实施。特别地,协议特定的数据定义数据如何从(控制器215上的)控制器应用被接收或被提供给该控制器应用,以及数据如何被提供给接口对象225或从接口对象225被接收,包括在接口对象225和控制器应用之间所要求的任何格式转换(数据映射)。XDF文件205优选地为单文件,但可适当地包括两个单独的文件,每个文件包含这些部分230、235中的一个。XDF文件205优选地被实施为XML文件格式。
主机应用210为软件装置,该软件装置被配置成接收XDF文件205并基于该XDF文件205产生第一节点220和接口对象225。具体地,主机应用210基于XDF文件205的第二部分235形成第一节点220。随后主机应用210基于第一节点220和XDF文件205的第一部分230形成接口对象225。为此,主机应用210优选地被配置为插件能够运行的环境。在一个实施例中,所产生的第一节点220和接口对象225以LONWORK
网络服务(LNS)插件的形式形成插件。在该实施例中,第一节点220为形成LNS网络服务上的“节点”的一个或多个对象的集合,而且接口对象225定义用户接口程序或对象。
第一节点220执行从控制器215接收的数据的数据转换和处理。第一节点220也揭示用于要显示在接口对象225上的数据的接口。为创建第一节点220,主机应用215基于定义与LNS环境中的控制器应用的交互作用的现有动态链接库文件例示对象。主机应用215使用XDF205中的文本文件的信息例示对象,该信息特别定义什么数据被访问以及它如何被处理。
接口对象225以图形格式呈现从第一节点220接收的数据。此外,接口对象被配置成接收用户输入并且将这样输入的数据呈现给第一节点220以便提交给控制器215。为此,第一节点220也提供用于接收引起控制器应用动作的指令形式的用户输入的接口。在这种情况下,第一节点220将用户输入映射为对控制器215上的控制器应用所采用的格式的数据和/或动作的请求。
如所提到的,在一个实施例中接口对象225和第一节点220形成LNS插件并且满足LNS插件的技术要求。主机210是被配置成基于XDF文件205产生插件的软件装置。为此,主机210被编程为执行如图3中所示的下列步骤。
如步骤305中所示,首先调用主机210以形成控制器应用的插件。应当理解的是当术语“控制器”或“控制器215”被引用时,意图包括控制器215自身和特别是在控制器215上运行的感兴趣的控制器应用。
如下面将结合图4讨论的,插件创建过程的启动可通过在本领域中已知的LNS引导器发生。在这样启动时,给主机210提供包括标识要被采用的XDF文件的引用(自变量)的命令。应当理解的是本实施例中的主机应用210被设计为在可用编程环境下运行,因而采用API、DLL和其它可用于用作插件的特征。在框架内,主机应用210能够被用于通过采用不同的XDF文件例示插件来产生用于各种控制器应用的各种插件。因此,在该示范性操作中的步骤305中,给主机210提供包括XDF文件205的标识的命令或操作,该XDF文件205将典型地是存储在便携式工具116或工作站114的存储器中的多个可用XDF文件中的一个。
在步骤310中,主机210解析XDF文件的第二部分235以便创建第一节点220。第二部分235包括被用于形成对象的协议特定的数据,该对象接收来自控制器215的数据并将数据处理成对接口对象225有用的格式。第二部分235进一步包括被用于形成对象的协议特定的数据,该对象将从接口对象225接收的命令和数据处理成对控制器215有用的格式。第一节点220的对象可对从控制器215接收的数据执行例如求平均值、组合逻辑和其它数学运算的处理。主机210包括解析文本XDF文件中的这些功能的定义并且阐明或例示节点220内的相应对象的引擎。为此,主机210访问提供被例示的对象的框架的各种动态链接库(DLL)。在LNS环境中,提供DLL,该DLL使能访问LNS控制器应用的插件。使用这样的DLL,对象提供与控制器应用进行物理通信所必需的通信接口。
在步骤315中,主机210通过解析第一部分230阐明接口对象225。第一部分230以文本格式提供用户接口的定义。典型地,同一计算机(即便携式工具114或工作站116)内的一个或多个动态链接库包括基本图形引擎元件。在这样的环境中图形元件的布置可通过XML文本文件容易地实现。作为例子,像由Microsoft.NET框架API提供的TextBox、ComboBox那样的.NET“控制”可通过文本文件、例如XDF 205来引用(reference)。主机210进一步连接或绑定应用对象225与已经被例示的第一节点220中的对象的数据接口。换句话说,如果XDF文件205的第一部分230中的文本行定义应显示平均温度,随后主机210识别第一节点220中的提供平均温度的阐明对象并将显示操作与该对象绑定。
在步骤315后,由第一节点220和接口对象225组成的插件是可运作的。插件包括允许用户使用便携式工具116(或工作站114)在控制器215上执行(如XDF 205中定义的)所选择的操作的对象集合。图2的配置的一个优点是不同的插件功能可容易地使用文本文件来定义。执行显示的通信、绑定和阐明的操作通过主机210来配置,该主机210可重复用于多个应用。这降低必须为访问和处理控制器应用(或其它设备应用)的数据的每个新接口产生的代码的数量。此外,XDF 205的第一部分230可在使用不同协议、例如不同于LonWorks的协议的控制器应用中被重复使用。换句话说,使用不同协议的控制器的XDF文件可采用与第一部分230中相同的文本文件,即使在XDF 205的第二部分235中采用了不同的协议特定的文本文件。
虽然上述方法和系统要求软件开发以创建主机应用210,但主机应用210可被重复用于相对于控制器215可被实施的多个应用中的任何一个。
再次参照图3,步骤320-335示出由第一节点220和接口对象225形成的插件的示范性操作。总的来说,接口对象225导致图形用户接口的显示,该图形用户接口尤其包括代表楼宇控制系统的特性的动态文本或图形元素。步骤320-335的示范性操作说明如何通过应用检索并显示来自控制器215(例如图1中的控制器110)的数值。
考虑控制器215是图1中的控制器110的例子。在这种情况下,控制器110/215控制VAV执行器(例如执行器108)以基于房间的温度保持进入房间的冷气流。房间的温度由位于房间中并可操作地连接到控制器110/215的温度传感器(例如传感器104)提供。该例子中的插件应用可以是提供以华氏度为单位的温度值的显示、附接到执行器上的通风风闸的百分比打开值(即风闸位置)的显示、和可以被用于促使风闸进一步打开或进一步关闭的控制的应用。这样的应用尤其可以被用于允许技术员检查控制器以保证风闸的正确操作。
为了显示风闸位置和温度的当前状态,必须从控制器215获得数值,该控制器保存或至少能获得这样的数值。步骤320-335的示范性操作说明将如何检索和显示这样的数据。下面讨论的步骤320-335的操作示出从附接的控制器或现场面板检索数值的一般操作,以及从图1中的控制器110检索风闸位置和温度的特定例子。
关于一般操作,在步骤320中,第一节点220中的对象从与插件相关的控制器215获得原始数值。根据特定控制器设计访问这样的信息的方法在被用来定义第一节点220的外部定义文件XDF 205中被定义。数据通过通信网络(例如图1中的网络102)来物理接收,或可能通过控制器215自身中的通信端口来物理接收。物理和传输通信协议的详细说明一般在主机应用210中被定义,而不是在XDF 205中被定义。相反,XDF 205提供协议特定的数据格式和数据处理信息。
再次考虑显示在控制器110中保存的风闸位置和温度的例子,在步骤320中,第一节点220中的对象向控制器215请求并接收代表温度和风闸位置的信息。这样的信息可以例如作为在0-255之间的抽象标度上的数值被保存在控制器215中。第一节点220中的对象被配置成识别和寻址由控制器215揭示的适当输出以得到原始温度和位置信息。
再次参照应用插件的一般操作,在步骤325中,第一节点220中的对象随后将从控制器215接收的原始数据处理成对接口对象225有用的信息。处理可包括数据格式转换、例如求平均值、滤波等的数学运算、组合操作等。这些操作在被用于创建第一节点220的XDF 205中被定义。
在上述的特定例子中,在步骤325中,第一节点220将把针对温度所接收的协议特定的数值(0-255)转换为代表接口对象225所采用的标准中的温度(即华氏度)的数值。类似地,第一节点220中的对象将风闸位置的协议特定的数值(0-255)转换为代表接口对象225所采用的标准中的百分比(例如0%-100%)的数值。
在步骤330中,第一节点220提供处理后的数值给接口对象225。处理后的数值为接口对象225所期待的格式。由于接口对象225和第一节点220之间的格式/接口独立于控制器215的格式,因此显而易见的是,同一接口对象225可以被用于使用各种协议的各种类型的控制器。然而,具有不同数据格式的各种类型的控制器中的每一个将可能要求不同的第一节点220,该第一节点220将负责将对于控制器来说特定的数据转换成接口对象225的标准数据。
在上面讨论的特定例子中的步骤330的操作中,第一节点220提供转换后的温度(华氏度)和风闸位置(百分比)数值给接口对象225。
在步骤335中,接口对象225以在XDF 205中定义的格式显示数值。在上述例子中,接口对象225将以华氏度显示温度并将风闸的位置显示为在0%和100%之间的数值。举例来说,如果支持动画或动态图形对象的DLL可用,则显示可适当地为图形,例如“温度计”式条形图或“流速计”式辐射图。在这种情况下XDF 205将提供数据应如何被呈现的定义,并且主机应用210将调用使用可用DLL的合适对象。然而,一般可用的.NET图形支持提供足以在按钮、下拉菜单等环境中至少以文本形式在GUI上呈现信息的DLL。
如上所述,应当理解的是第一节点220中的对象可对从控制器215接收的原始数据执行更复杂的操作。例如,与瞬间测量相反,应用插件可进一步向用户显示温度(或其它值)的5分钟移动平均。在这种情况下,第一节点220将对从控制器215接收的温度值求平均值并不时地将转换后的平均值提供给接口对象225。
虽然步骤320-335的操作说明如何通过第一节点220和接口对象225显示从控制器215/110接收的数据,但第一节点220和接口对象225也协作以将从用户接口(鼠标点击、数据输入等)接收的数值传输到控制器215/110。例如,可以通过接口对象225从用户获得“命令”。接口对象225将“命令”传递给第一节点220。第一节点220内的对象处理命令数据并产生适当的输入给控制器215以执行命令操作。第一节点220和接口对象225的上述操作再次由XDF 205定义。随后控制器215的控制器应用执行命令操作。
虽然上述实施例可在各种网络环境中应用,但图1和2的实施例特别适合用于LNS环境中。图4更详细地示出图2中的方法和系统的第一实施例在LNS插件中被实施。图4的方法和系统包括外部定义文件(XDF)405、RDF 410、包括主要组件418和Visual Basic插件主机组件420的主机应用415、LNS引导器应用425、第一节点430、接口对象435、LNS服务器440、和控制器445。
与图2中的XDF文件类似,XDF文件405是包括与控制器445相关的特定应用的用户接口和数据映射的定义的外部定义文件。为此,XDF文件405包括第一部分450,其定义执行关于控制器445并且特别是又连接到控制器445的第一节点430的输入/输出数据操作的一组用户接口显示。XDF文件405包括第二部分455,其根据协议特定的数据定义第一节点430的实施。如同图2中的XDF文件205一样,若有需要,图4中的XDF文件405由两个单独的文件组成,每个包含这些部分450、455中的一个。然而,在本实施例中预期为单个XDF文件。
RDF文件410为包含控制器415的LONmark变量类型定义的源定义文件。总的来说,LNS网络上的楼宇控制设备采用在基于LNS的系统中使用的标准变量。RDF文件410提供变量定义以允许插件与LonMark兼容控制器445交互。例如,RDF 410提供用于将物理数据(字节)转换成结构工程数据的资源(数据类型和工程单元/转换定义)。
主机应用415是图1中的主机应用210的示范性实施例。相应地,主机应用415是被配置成接收XDF文件405并基于XDF文件405产生第一节点430和接口对象435的应用。主机应用415进一步解析RDF文件410以便允许第一节点编码和解码在协议消息中传输的原始数据。在该实施例中,主机应用415被配置为LNS插件可被执行的环境,并由LNS引导器425起动。
为此,主组件415具有Visual Basic组件420和主要组件418。采用VisualBasic组件420是由于LNS插件必须作为ActiveX进程外自动服务器被实施,并且该Visual Basic组件420可在Visual Basic环境中被执行。主要组件418执行创建第一节点430和接口对象435的一般操作。在一些实施例中,主要组件418可作为使用COM技术的插件运行。如在本领域中已知的,LNS环境基于ActiveX和COM技术并且与ActiveX和COM技术兼容。
然而,假定能与COM技术共同使用的.NET的出现,可能需要将主要组件418阐明为.NET组件。.NET组件提供.NET环境的灵活性和其它优点,包括能够访问更大范围的代码库(即DLL)。然而,.NET插件将不直接在LNS环境中工作。相应地,如图4中所示,Visual Basic组件420与.NET主要组件418通过外壳插件419交互。外壳插件419为使用在.NET环境中可用的COM可操作性框架与.NET插件实现(即.NET主机组件418)交互的ActiveX/COM环境插件。在图4的实施例中,COM外壳插件在Visual Basic组件420与.NET组件418之间执行外壳功能。COM外壳插件充当允许.NET插件组件418在正常LNS环境中运行的通道(passthrough)组件。另外,COM外壳插件420不执行主机组件415的功能。相反,.NET组件418执行主机组件415的主要功能。随后.NET组件418可访问在.NET环境中可用的库以创建第一节点430和接口对象435。
LNS引导器425是可从埃施朗(Echelon)公司得到的标准LNS组件。LNS引导器425是提供对其它LNS组件的访问的软件对象,并具有调用LNS插件的能力。在该实施例中,LNS引导器425能够产生促使主机组件415执行以创建第一节点430和接口对象435的LNS插件API命令。
第一节点430类似于图2中的第一节点220。第一节点430是在通过接口对象435显示信息所要求的格式和由LNS环境中的控制器445所提供的格式之间处理数据的对象的集合或图形。第一节点430基于XDF 405来产生,该XDF405定义数据将如何在LNS服务器440(为控制器445的LNS表示)和接口对象435之间被映射/处理。
接口对象435提供插件的图形用户接口(GUI)功能。接口对象435也基于XDF405来产生,该XDF405在文字上定义用户接口的格式以及应显示的信息的类型。接口对象435使用包含图形引擎组件的可用动态链接库来实施GUI。接口对象435也包括与第一节点430交换信息的操作。
LNS服务器440是提供处理控制器445和第一节点430之间的通信的接口的对象。LNS服务器440也通过主机组件415来初始化。
图4中的所有元件除了控制器445本身都可以容易地在单个机器、例如图1中的便携式工具(即便携式计算机)116上被实施。总的来说,图4中的元件一般协作以执行图3中的操作以允许应用提供对与控制器445的操作有关的一个或多个变量或数值的用户访问。
应当理解的是上述实施例仅仅是示范性的,本领域技术人员可以容易地设计出合并本发明的原理并且在本发明的精神和范围内的实施方案和修改方案。