1．前言
智能建筑（Intelligent Building）在我国有近十年的发展历史，近年来在市场和技术方面逐步成熟，而且建筑智能化系统集成已形成一个行业，有巨大的发展空间。智能建筑集成管理系统IBMS（Intelligent Building Management System）是面向智能建筑领域自动化控制系统的一个应用集成平台系统。它是针对现代化的建筑中采用的智能化系统越来越多，系统越来越复杂，智能化系统运行管理和维护变的越来越困难；各智能化系统独立运行，系统之间不能有效配合使用，对发生的事件，不能站在建筑整体的角度，联动配合响应，用户投资效益难以最大化；智能化系统“孤岛”运行，与管理信息系统相互隔离等问题设计的。
应用于智能建筑行业的集成产品IBMS，多运行于Windows操作平台，开发工具以C++语言为主。受智能建筑迅猛发展的影响，广泛采用先进的计算机技术、通讯技术、控制技术、现场总线技术，软件方面目前多采用多层架构、B/S模式，采用组件技术、OPC技术、Web技术、实时数据库技术等。
但目前符合最新工业标准、基于XML/SOAP的实时数据集成技术应用（提供Web服务，实时性能优良，跨平台，易于部署和维护）的产品在市场上基本空白，有极大地应用前景，并可扩展应用到自动化领域。
2基于实时数据集成技术的Web服务技术
2.1实时数据集成技术
实时数据通常是指随时间而动态改变的数据,如气象水文信息.生产信息.股票实时信息等。课题关注的实时数据，主要是智能建筑行业通用的数据，如楼控系统、消防系统、安防系统的数据。数据类型可分为IO数据、报警事件数据等。其中IO数据又可分为浮点量、整形量、开关量、消息量等。报警事件数据通常包括事件种类、事件类型、事件源、事件描述、优先级、发生时间等数据项。
应用于智能建筑行业的实时数据集成技术，通常可完成智能化各子系统级系统集成、整个系统的系统集成（IBMS系统）、以及建筑群的系统集成（分布式IBMS系统）。在这些系统集成当中，各子系统级纵向集成的问题相对简单，对各子系统级纵向集成的技术也相对比较成熟，广泛应用的有开放标准的传统的OPC技术，也有专有的厂商技术，如Lonworks技术、Honeywell的Network API方式等。
而各子系统之间的实时数据集成技术，作为一个有关互联性和互操作性问题，这是一个多厂商、多协议、面向各种应用的体系结构，需要解决各类设备、子系统之间的接口、协议、系统平台、应用软件、建筑环境、运行管理等各类面向集成的问题。能否方便、灵活地接入各种差异极大的子系统，是IBMS系统软件设计和实现时的一个重要问题，这个问题解决得好，会给系统带来极大的适应性。目前在行业内广泛应用的解决方案是采用传统的OPC技术。
传统的OPC技术是基于微软的OLE/DCOM技术，在建筑物面积相对不大（一般不超过5万平米）、集成子系统数量较少（不超过10个）、控制对象数量不大（系统点数不超过5000~6000点），网络比较简单，比较合适。但在建筑物面积超大、多建筑物以及建筑群的集成方面，网络环境相对复杂，经常需要通过异构平台、防火墙进行通讯，这时已不适合采用，需要采用新的集成技术来解决这类难题。OPC基金会2003年7月发布新近正式推出的OPC XML-DA标准，就是以Web服务的方式解决这类问题的最新开放标准。
2.2 Web服务技术概述
从技术的角度来看，Web Service可以被认为是一种部署在Web上的对象（Web Object），因此，具有对象技术所承诺的所有优点；同时，Web Services的基石是以XML为主的、开放的Web规范技术，因此，具有比任何现有对象技术更好的开放性。
Web Services是描述了一些操作的接口，通过标准化的XML消息传递机制，可以通过网络访问这些操作。Web Services是用标准的、规范的基于XML的WSDL语言描述的，这称为Web Services的服务描述。这一描述囊括了与服务交互所需要的全部细节，包括消息格式（详细描述操作的输入输出消息格式）、传输协议和位置。该接口隐藏了服务实现的细节，允许通过独立于服务实现、独立于硬件或软件平台、独立于编写服务所用的编程语言的方式使用该服务。这使得基于Web Services的应用程序具备松散耦合、面向组件和跨技术实现的特点。Web Services都履行一项特定的任务或一组任务。Web Services可以单独或同其他Web Services一起用于实现复杂的商业交易。
2.3 基于实时数据集成技术Web服务的技术描述
OPC组织，已认可XML技术在工业应用软件中的价值，已定义16个schemas集用于.NET-M面向过程控制应用中。
l Status: Request, Response
l Read: Request, Response
l Write: Request, Response
l Subscription: Request, Response
l SubscriptionPolledRefresh: Request, Response
l Subscription Cancel: Request, Response
l Browse: Request, Response
l Get Properties: Request, Response
例如，使用OPC-XML schemas编码的消息可用于控制数千里的石油管道。操作人员可以跟踪流速、值状态等等。操作人员如果需要通过Internet连接到石油管道某一子站，他可能必须通过1个或多个的防火墙，这是典型的二进制接口连接难以做到的。
这些schema中每一个都可被Visual Studio .NET包装为一个SOAP方法调用。
2.3.1 OPC最新的XML-DA标准
OPC组织于2003年7月发布的XML-DA 1.0标准，是采用XML技术集处理实时数据的交换并可通过Internet、向上集成到企业领域。该标准的实现模型也正是基于Web 服务。
XML-DA规范有如下目标：支持HTTP、SOAP，支持基于服务的订阅，支持OPC DA 2.0x/3.0 数据，支持安全的方法。
XML-DA Server可以单独运行或是对DA 2.0x/3.0 规范COM组件的封装。
2.3.2 Web服务的订阅架构（Subscription architecture）
OPC XML-DA标准订阅架构采用设计实现一种推式拉（polled-pull）订阅。客户端与Server实现松散的合约。客户端发起订阅并同意发出周期性的更新请求。本机制是对最初基于COM组件的OPC DA 标准的回调方式——“受控制的响应”机制的一种比较好的模拟。本机制用于减少返回值的等待时间和最小化客户端、服务端之间的往返行程（round trip）。
XML-DA支持基于服务的如下订阅：Subscribe, SubscriptionPolledRefresh,和 SubscriptionCancel。其中Subscribe方法用于与服务端发起一个订阅合约，SubscriptionPolledRefresh方法用于周期性的调用来取得最新的数据项，SubscriptionCancel方法用于终止与服务端的订阅合约。
有两种订阅方法：基本轮询更新方法和高级轮询更新方法。
3．基于实时数据集成技术Web服务的设计与实现
总体方案按Web 服务的服务端、客户端分别考虑设计与实现的原理与功能，具体见下节。系统架构如图3.1所示。
图3.1 系统架构图
3.1 Web 服务端设计与实现
对Web服务的结构按逻辑可分成Web Server封装层、实时数据访问层两层实现，对应2个组件实现。
1．通用Web Server封装层
Web服务的上层为通用Web Server封装层，采用OPC XML-DA标准定义属性和方法，并对报警事件类型的数据访问作适当扩展。由Web服务接口调用处理、层次地址空间管理、IO实时数据访问、报警事件数据访问四部分组成。
Web服务接口调用处理部分，包含2个包：包“Web服务接口定义与类型定义”和包“Web服务接口实现/方法调度”。这一部分实现了Web服务接口WSI模式（Web Service Interface pattern）。通过将Web服务接口代码与服务实现代码分隔开来，实现服务接口机制与应用逻辑分离。
Web Server层的层次地址空间管理主要包括层次地址空间组织和层次地址空间浏览两部分。Web Server以层次地址空间组织的方式维护数据项。它可以是静态或动态的。客户端可以浏览服务器来得到可用的数据项。在动态组织的服务器内部实际上存在2种地址空间：实地址空间与虚地址空间。在课题实现当中，为隔离与设备关系，预定义为实地址空间模式。
IO实时数据访问部分，主要通过数据服务类OpcDaServer和实时数据订阅调度处理器类SubscriptonHandler与下层实时数据访问层的数据访问包完成IO实时数据交互访问，并根据上层Web服务方法IO实时数据访问请求，返回相应的处理结果。其中关键之处在于IO实时数据项（DeviceItem）的数据自动更新、更新数据项（UpdataItem）的数据自动更新、 IO数据订阅机制的设计实现。
报警事件数据访问部分，与IO实时数据部分原理相同，与后者区别在于处理的数据类型不同，为事件数据。
2．实时数据访问层
下层为实时数据访问层，主要实现与实际应用中的数据源（包括硬件系统或软件系统）进行数据交换，并隔离上层对象对数据项的直接访问。
实时数据访问层主要由数据访问包、设备通讯包两部分组成。其中数据访问包主要实现对实时数据的访问，并对上层提供一致性的调用接口。
设备通讯包主要实现外部硬件系统或软件系统如IBMS服务平台这些通讯对象的通讯交互。考虑到Web服务应用对象的通讯接入差异性及课题的重点在于Web服务的实现，本部分功能通过有规律的数据变化来模拟设备通讯包的实现。
3.2 Web Service客户端设计与实现
Web Service客户端的访问，通常通过WSDL或添加Web应用的方式产生客户端理类，并通过代理访问Web Service。
为提高通讯效率，在Web Service客户端实现异步方式访问。在.NET环境，通过代理类支持的IAsyncResult接口来监视和管理异步操作。通常异步方法有轮询（Polling）、回调（Callback）、等待句柄（Wait Handles）这几种。
结合OPC XML-DA的订阅架构（Subscription architecture），考虑实时数据集成的实时特性,拟采用等待句柄（WaitHandles）方法实现，并对客户端实现以组件形式进行封装。
Web服务的客户端逻辑层次从下往上可划分为三层：Web服务代理层、实时数据通讯层、UI层。其中Web服务代理层由Web服务WSDL工具自动生成，不需额外编程。UI层根据应用不同可有多种实现，只实现简单的GUI界面，形象地表示与实时数据通讯层的命令交互和实时数据显示。实时数据通讯层与具体的Web服务通讯相关，是关注的重点。
4．性能结果
客户端程序分别对不同数据项个数进行Read方法（直接读）和Poll方法（订阅轮询）的连续每秒调用的性能结果如下。对Web服务，选择4种常用的IO数据项（整形量、浮点量、开关量、字符串量）通过服务端每秒递增变化仿真处理，以方便客户端程序的测试观察。作为比较，列出本地客户端和局域网客户端的性能结果。
| 数据项个数（个）
| 本地客户端 | 局域网客户端 |
Read方法 | Poll方法 | Read方法 | Poll方法 |
1 | 1 | 20ms | 22ms | 35ms | 40ms |
2 | 4 | 25ms | 31ms | 43ms | 50ms |
3 | 100 | 75ms | 60ms | 90ms | 85ms |
4 | 1000 | 600ms | 350ms | 845ms | 590ms |
表5-1 Read、Poll方法性能对比
可以看到，对于上面的测试，当客户端数据项较少时（少于100个），Read方法比Poll方法效率更高；当客户端数据项较多时（多于100个），Poll方法比Read方法效率更高。当客户端数据项较多时, 远程Poll方法与本地Read方法效率近似。
总的来说，性能结果满足实时数据集成的要求，且性能较理想。
需要说明的是，测试计算机配置均为PIII 866，256M内存，10M网卡。测试的绝对时间与特定计算机各方面情况有关，如使用目前配置最好的计算机，测试指标还会提高。
5．结束语
通过对基于实时数据集成技术的Web服务的总体方案、服务端和客户端的设计和实现，达到如下结果：
（1） 采用OPC XML-DA标准定义和实现了Web服务，对报警事件类型的数据访问作适当扩展。实现Web服务的订阅架构，同时为避免跨防火墙时和Internet时性能损失，Web服务端共实现11个复杂Web方法来提高性能，包括状态查询、数据项浏览、属性查询、读／写、订阅／订阅轮询／订阅取消等。
（2） 客户端为隔离上层对Web服务通讯的细节的了解，提高重用性，实现了基于Windows Form Control的实时通讯组件。可以方便地与浏览器或Windows Form程序组合完成与Web服务通讯。
（3） 在服务端设计中，充分利用接口（Interface）带来的便利。各层全部用接口来描述功能，彻底的隐藏了具体实现细节。
（4） 整个设计利用Web服务接口模式、观察者模式等多种设计模式解决特定问题。
（5） Web服务性能结果满足实时数据集成的要求，且性能较理想。
