路世魁的开题报告王改.docx

路世魁的开题报告王改.docx

《路世魁的开题报告王改.docx》由会员分享，可在线阅读，更多相关《路世魁的开题报告王改.docx（11页珍藏版）》请在冰豆网上搜索。

路世魁的开题报告王改

研究生学位论文选题报告

及论文工作实施计划

学院：

计算机学院

专业：

计算机应用技术

研究生：

路世魁

学位级别：

工学硕士

指导教师：

王波

入学年月：

2004年09月

　重庆大学研究生院

2005年12月28日

说明

一、论文选题报告由研究生向教研（研究）室汇报并听取意见后，整理成文填写。

二、研究生应在入学后的第三学期内完成选题报告。

三、本表一式三份，一份交学院，指导教师和研究生各存一份。

研究生自存表应于答辩前交学院，作为答辩申报材料之一。

一、论文选题报告（申请时间：

2005年12月28日）

论文题目：

OPCDX在智能建筑系统集成中的应用研究

研究方向：

计算机网络技术与系统集成

课题来源

国家

项目

部、省级

项目

横向

联系

自拟

合同

编号

经费数

（万元）

√

题目类型

基础

研究

应用

研究

工程

应用

其它

√

自选报告内容：

（课题学术和实用意义，国内外现状综述；研究目的、内容、技术路线；可行性论证等）

一、课题学术和实用意义

1智能建筑系统集成的产生和发展背景

智能建筑发展的初期，各个子系统规模很小，控制对象少而简单，各个子系统相对独立信息共享主要依赖手工传递，维护管理工作处于半自动化状态。

随着现代通信，计算机及其网络的发展，智能建筑各个子系统向着规模大、控制对象多且分散，各个子系统间以及建筑物内、外对信息传输速率和共享程度提出了很高的要求。

由于要将智能建筑中各类设备和子系统通过一定的方式集成在一起，于是产生了智能建筑系统集成这一概念和技术。

[1]

2OPC技术概要

随着计算机技术、通信技术和控制技术的发展,控制领域正开始向网络化方向发展。

控制系统的结构从最初的CCS（计算机集中控制系统）,到第二代的DCS（分散控制系统）,发展到现在流行的FCS（现场总线控制系统）。

对诸如图像、语音信号等大数据量、高速率传输的要求,又催生了当前在商业领域风靡的以太网与控制网络的结合。

从而拓展了工业控制领域的发展空间,带来新的发展机遇。

[2]。

过去在控制系统中，控制设备之间及控制设备与控制系统软件之间的数据通信是通过驱动程序来实现的。

由于软件开发商对驱动程序的要求各不相同，硬件供货商不可能为所有的软件开发商提供驱动程序，所以这项工作主要只能由控制系统的软件开发商承担。

随着现场总线技术和PC机在过程控制系统中的应用，一方面网络中需进行数据访问的控制设备数量不断增加且产品的不断升级，另一方面，企业中越来越多来自不同部门的员工通过PC机对数据进行访问。

这就需要更多的驱动程序，给用户和软件开发商带来了巨大的工作负担,使其无法全身心地投入到其核心产品的开发中去。

这种开发方式主要存在以下弊端：

（1）重复开发:

每个软件系统开发商必须为每个特定的硬件开发一个驱动程序。

（2）不同开发商之间的驱动程序的不一致性:

软件开发商各自从自己的需要出发，采用不同的数据交换协议开发驱动程序，从而使各开发商之间的驱动程序不一致，并且驱动程序并不支持所有的硬件特性。

（3）不支持硬件产品升级:

由于驱动程序由软件开发者开发，硬件产品的升级将会使有的驱动程序失效，为适应硬件特征的新变化，软件开发者必须为硬件开发新的驱动程序。

（4）访问冲突:

一般来说，两个软件包不能同时访问同一设备，因为它们使用不同的驱动程序。

为了解决这一问题，硬件开发商试图以开发驱动程序的方法来解决这一问题,但由于不同的客户采用不同的客户协议而无法实现。

控制系统软件开发商构造一个完整的控制系统需要大量的驱动程序，如果再考虑兼容不同硬件厂商的产品，那么驱动程序的数量将更加庞大。

为解决这一控制系统软件开发中的瓶颈问题，需要一项为业界所公认的数据交换标准来规范驱动程序的开发。

在这种情况下，OPC标准应运而生。

OPC（OLEforProcessControl）是过程控制业中的新兴标准，它以OLE/COM/DCOM机制为通信标准，采用客户/服务器模式，把开发访问接口的任务放在硬件生产厂家或第三方厂家，以OPC服务器的形式提供给用户，解决了软、硬件厂商的矛盾，完成了系统的集成，提高了系统的开放性和互操作性。

OPC服务器通常支持两种访问接口：

自动化接口和自定义接口，它们分别为不同的编程语言环境提供访问机制。

自动化接口是为基于脚本编程语言而定义的标准接口，可使用VB、Delphi、PowerBuilder等语言开发OPC服务器的客户应用。

而自定义接口是专门为C++等高级语言而制定的标准接口[3]。

3OPC主要标准

（1）OPCDA数据访问规范

OPCDA（OPCDataAccessCustomInterfaceSpecification）简化了不同总线标准间的数据访问机制,为不同总线标准提供了通过标准接口访问现场数据的基本方法。

OPCDA服务器屏蔽了不同总线通信协议之间的差异,为上层应用程序提供统一的访问接口[4],可以很容易的在应用程序层实现对不同总线协议的设备进行互操作。

在现场控制网络中，OPCDA规范实现了现场数据在控制网络中的纵向传输[5]。

（2）OPCDX数据交换规范

随着以太网现场总线技术的发展,各个现场总线协议都推出了各自的以太网现场总线标准,例如等。

为了给连接在以太网上的不同现场总线设备之间提供数据访问服务,同时也为了弥补OPCDA规范在实现总线设备间数据访问时对上层应用程序有依赖性的不足,OPC基金会于2001年宣布制定OPCDX标准[6]，经过两年的努力，于2003年3月5日正式发布了数据交换规范OPCDataeXchangeSpecificationVersion1.0[7]。

OPCDX服务器的内部结构如图1所示[5]。

图1OPCDX服务器结构

从图1中可以看出,OPCDX服务器实际上扮演了3种角色[7]:

（1）它要实现OPCDA服务器的功能,通过OPCDA接口为其他OPCDA客户提供数据访问服务,这些客户可以是上层应用程序,也可以是其他OPCDX服务器。

（2）OPCDX服务器还作为OPCDA服务器的客户端,直接访问其他OPCDA服务器,所访问的可以是独立OPCDA服务器,也可以是由其他OPCDX服务器内部提供的OPCDA服务器,因此,OPCDX服务器之间可以不依赖上层应用程序完成现场数据的横向访问。

（3）OPCDX服务器还要管理DX数据库,并通过DX数据库管理其内部的OPC/DA服务器和OPCDA客户,根据用户通过通用的组态软件配置的组态信息,调度现场数据的采集和发送,完成与其他OPC设备接口的数据交换。

OPCXML规范

由于OPC技术过分依赖微软的COM/DCOM技术，这使它局限于Intranet和Windows操作平台。

为了实现与Internet的互联以及在多操作平台上的应用，OPC基金会与微软公司合作,在Microsoft.Net新技术与OPCDA的基础上于2003年7月制定OPCXML规范（OPCXML-DASpecification）Version1.0[8]。

可扩展标志语言XML和基于XML的模式语言为描述和交换应用程序间的结构化信息提供了一种途径。

OPCXML利用XML技术有效地扩展OPC技术的应用范围,使OPC应用不再局限于Windows操作平台,可实现多平台间的互操作。

与OPCDA不同，OPCXML描述了在客户端与服务器间非持久连接环境下的数据交换，这使它可以应用于更广泛的领域。

在现场控制网络中，OPCXML规范提供了现场数据到互联网中的传输。

OPCXML定义一组通过互联网访问工厂现场数据的工业标准接口,并提供即插即用的可连接性和多个厂商产品的互操作性等功能,降低了企业信息与互联网应用集成的难度，简化了工厂不同层次数据访问和数据交换。

3智能建筑系统集成为什么采用OPC技术

由于网络互联的硬件设备已经商业化，标准化。

所以在系统集成时主要面临的是软件集成的问题，如何通过标准的通信协议达到互操作的目的。

在实现智能建筑系统集成时为了解决互联和互操作问题所采取的手段大致为以下几种:

（1）采用统一通信协议实现系统集成的方式。

（2）采用协议转换实现系统集成的方式。

（3）采用OPC技术实现系统集成的方式。

3.1采用统一通信协议实现系统集成的方式

建筑智能化系统应属过程控制范畴，长期以来没有建立国际性的标准通信协议，这种局面严重障碍了智能建筑技术的发展。

1995年美国暖通空调工程师协会推出了楼宇自动控制领域的第1个开放式标准通信协议——BACnet[9]。

同年通过ANSI认证，成为美国国家标准。

很多空调、制冷、锅炉、变配电等设备制造厂商均采纳该标准协议，为智能建筑的系统集成开创了十分有利的局面。

BACnet采纳了五种协议：

EIA232——PTP、EIA485—MS/TP、LonTalk、Arcnet、Ethernet。

但是在先前的BACnet协议中，不同厂家生产的设备互联仍需通过协议转换器，尚未达成开放系统实现互操作的要求。

LonWorks是美国埃斯朗公司1990年推出的全分布式的具有开放性和互操作性、采用LonTalk协议的网络，经过LonMark互操作性协会认证的产品具有良好的互操作性。

但是这种方式不是真正意义上的开放系统，因为这种协议对厂家不是中立的，其中有埃斯朗公司的知识产权，真正的开放系统对各个厂家应该是中立的。

3.2采用协议转换实现系统集成的方式

具有不同协议的网络互连，可以采用协议转换器。

协议转换器分为专用的协议转换器和标准的协议转换器。

专用协议转换器指两种协议之间专用的转换器。

采用这种协议转换器，如果要连接多个不同类型的网络，就需要多种类型的协议转换器。

有时协议转换器难于匹配不同的网络的控制机制和服务。

另外，当协议转换器故障时，这种结构没有提供可靠的端到端的机制，所以这种专用的协议转换器不可取。

随着技术的发展，协议转换器方式的应用将越来越少。

特别是OPC技术的成功应用，为不同协议的网络互连，开辟了新的途径，协议转换方式的应用将会更少。

3.3采用OPC技术实现系统集成的方式。

OPC提供信息管理域应用软件与实时控制域进行数据传输的方法，提供应用软件访问过程控制设备数据的方法，解决应用软件与过程控制设备之间通信的标准问题。

当设备通过OPC互联时，图形化应用软件、趋势分析应用软件、报警应用软件等应用软件均基于OPC标准，现场设备的驱动程序也均基于OPC标准。

在统一的OPC环境下，各应用程序可以直接读取现场设备的数据，不需要一个一个地编制专用的接口程序，各现场设备也可直接与不同应用之间互连。

OPC的重要作用是使设备的软件标准化，从而实现不同网络平台，不同通信协议、不同厂家的产品方便地实现互联和互操作。

OPC技术的完善与推广，为智能建筑系统集成时，在实时控制域与信息管理域的全面集成创造了良好的软件环境。

所以说，OPC开创了系统集成的新途径，OPC将成为系统集成的主要方式。

3.4OPCDX在建筑智能化系统集成中的应用的必要性

作为与OPCDA相互补充的标准,OPCDX推广现有OPCDA的功能,提供了服务器之间的横向数据访问,能够在系统运行中实现“服务器-服务器”的数据交换,[10]。

因此,它不影响现有的现场总线规范，只是让集成在一个系统中的多现场总线仪表可以交换数据[11]。

OPCDA,OPCDX以及OPCXML等OPC规范不是独立的，可以将它们共同应用于智能建筑现场控制网络系统集成中。

采用OPCDA标准进行智能化建筑系统集成只能在在应用程序层实现对不同总线协议的设备进行互操作，OPCXML规范提供了现场数据到互联网中的传输。

但是OPCDA和OPCXML不能够实现控制层的设备与设备之间的互操作。

要实现在控制层的设备与设备之间的互操作和数据交换就需要采用OPCDX标准，也就是说OPCDX标准实现了现场数据在控制网络中的纵向传输。

OPCDX标准在智能建筑的系统集成中是有不可替代的作用的。

二、国内外现状综述

管理OPC标准的组织是OPC基金会。

其前身由一个Fisher-Rosemount、RockwellSoftware、Siemens、Opto22、Intellution和IntuitiveTechnology等著名大公司组成专门的工作组，仅仅用了短短的一年时间便开发出一个基本的可运行的OPC技术规范。

OPC基金1997年2月建立OPC欧洲基金会，1998年3月建立OPC日本基金会。

OPC中国基金会成立于2000年12月15日成立，大陆的OPC会员有北京华富惠通技术有限公司、北京华控技术有限公司、浙江中控科技集团有限公司和北京中瑞泰科技有限公司。

OPC的新技术标准OPCDX是OPC基金委托RockwellSoftware等公司研发的,与2003年3月发布。

尽管OPC技术对微软操作系统有很强的依赖性,使得它在嵌入式系统中的实现有一定的困难,但是在非Windows平台下的OPC技术也得到了迅速的发展。

2001年1月

SoftwareAG公司推出了基于UNIX平台的EntireXDCOM,实现了非Window平台DCOM技术；2001年6月,WindRiver公司推出的基于VxWorks平台的VxOPC,是第一个非Window平台的OPC/DA产品。

OPCDX发布以来引起了国内外企业和研究机构的广泛关注。

近年来出现了少量产品，许多还在测试之中。

SoftingAG公司开发了一个测试版的产品开发包Toolbox.NET，可用于开发OPCDXClient[12]。

IDXOnline公司发布的的iDXsuite是一个符合OPCDX标准的OPCDX服务器[13]。

IntegrationObjects公司的OPCServerSDK是一个可以开发符合OPCDX标准服务器和客户段的开发包[14]。

FieldServerTechnologies公司的FS-B3510LonWorksOPCGateway[15]和FS-B4010LonWorksOPCGateway[16]也是两种新开发的符合OPCDX标准的硬件产品，他们用于系统集成。

Kepware,Inc开发的OPCDXplug-inforKEPServerEX[17]是一种OPCDX服务器软件产品。

SoftwareToolbox,Inc的TOPServerOPCServers[18]是用于系统集成的OPCDX服务器。

国内的企业目前没有OPCDX产品发布。

OPCDX技术能兼容多种总线协议,不仅有严格的技术规范和测试标准,而且有强大的技术支持作为后盾,因此将会在系统集成中被广泛应用。

三 、研究目的

通过本课题的研究，能够深入理解OPCDX标准原理与结构，将OPCDX标准应用到建筑智能化系统集成。

四 、研究内容

（1）建筑智能化系统集成的思想、方法和技术手段及趋势。

（2）OPCDX标准的内容，原理和在建筑智能化系统集成中的必要性。

（3）采用OPCDX技术的建筑智能化系统集成模型设计。

（4）研究采用OPCDX标准进行应用软件开发的方法。

五、技术路线

基于以上的研究目的和研究内容，笔者制定了如下的技术路线：

建筑智能化系统集成模型将采取OPCDA、OPCXML、OPCDX。

实现平台

OPCDX可以有两种实现方式:

基于微机的实现和嵌入式实现。

在嵌入式实现方式中,

OPCDX服务器作为独立的以太网现场总线设备,摆脱了对主设备的依赖,可以直接与总线上的其他OPC服务器进行信息交流。

我们将采用PC平台。

操作系统

采取支持COM的微软操作系统进行开发。

六、可行性论证

从理论上讲，课题所需要的理论基础包括3部分

（1）建筑智能化系统集成的理论，这一方面的资料从网上和图书馆比较容易获得。

（2）OPC和OPCDX技术资料，我们在互联网上可以获得OPC和OPCDX标准的资料，

http:

//www.opc foundation.org是OPC基金会站点，专门发布有关OPC标准的最新信息。

（3）C++和VB编程技术，本人已有一定的这方面基础。

（4）COM基本原理。

图书馆有这方面的资料。

因此可以看出理论上本课题是可行的。

课题所需的硬件

应用软件开发测试运行可以在普通PC平台上实现，因此硬件上是可行的。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（若纸不够，请另附页）

主要参考文献目录：

[1]王波,卿晓霞.智能建筑导论[M].北京：

高等教育出版社,2003.

[2]陈维刚,费敏锐.工业控制系统的网络化发展[J].工业仪表与自动化装置,

2004

（1）.

[3]OPCTaskForce.OPCCommonDefinitionsandInterfaces.Version1.0,1998.

[4]OPCFoundation.OPCDataAccessCustomInterfaceSpecification.Version

3.0,2003.

[5]吕勇，王天然，于海斌，林　跃.OPC技术在现场总线互操作中的应用.仪表技术与传感器,2004（3）

[6]OPCFoundation.OPCtocreatdataexchangestandardforEthernet

[EB/OL].http:

∥www.opcfoundation.org,2001.

[7]OPCFoundation.OPCDataeXchangeSpecification.Version1.0,2003.

[8]OPCFoundation.OPCXML-DASpecification.Version1.0,2003.

[9]ANSI/ASHRAEStandard135-2001：

BACnet-ADataCommunicationProtocolforBuildingAutomationandControlNetworks.USA,2001.

[10]OPCFundation.OPCDataExchange（DX）Announcemount,2001.

[11]DHolley.OPCDXgluesfieldbusestogether.TheIndustrialEthernetBook,2001（8）.

[12]2005.

[13]

[14]http:

//www.integ-

[15]

[16]

[17]

[18]

[19]周明强，高悦翔，王波.智能化系统集成的开放工业标准一OPCDX技术.2003

（1）.

[20]周明强，王波.基于OPC技术的建筑智能化系统集成研究.中国优秀博硕士学位论文全文数据库.2003（4）.

选题报告论证记录（含时间、地点、参加人，提问及回答要点等）：

主持人签名：

记录签名：

2005年12月29日

二、论文工作实施计划

论文工作的具体进度与安排（含调研、完成时间等）

起止时间

内容摘要

备注

2005.09～2006.01

查阅文献资料,准备开题报告。

2006.02-2006.6

消化资料，开发OPCDX应用，并根据技术路线来完成工作

2006.07-2006.08

对系统进行完善和测试

2006.9～2007.1

撰写论文

2007.2～2007.4

论文的完善整理

2007.05～2007.6

论文答辩

教研（研究）室意见：

教研室

研究室

主任签名：

年月日

院、所意见：

院、所负责人签名：

年月日

计划变动情况：