集散控制系统DCS与现场总线控制系统FCS的比较.doc

1、集散控制系统 DCS 与现场总线控制系统 FCS 的比较 11 概述 FCS、DCS FCS 是在 DCS 的基础上发展起来的，FCS 顺应了自动控制系统的发展潮流，它必将替代 DCS。这已是业内人士的基本共识。然而，任何新事物的发生，发展都是在对旧事物的扬弃中进行的，FCS 与 DCS 的关系必然也不例外。FCS 代表潮流与发展方向，而 DCS 则代表传统与成熟，也是独具优势的事物。特别是现阶段，FCS 尚没有统一的国际标准而呈群雄逐鹿之势，DCS 则以其成熟的发展，完备的功能及广泛的应用而占居着一个尚不可完全替代的地位。本人认为：现场总线控制系统 FCS 应该与集散式控制系统DCS 相互兼

2、容。 无论是 FCS 或者是 DCS，它们最终是为了满足整个生产过程而进行的系统控制（PCS）。 首先以工程成本与效益看，现场总线的根本优势是良好的互操作性；结构简单，从而布线费用低；控制功能分散，灵活可靠，以及现场信息丰富。然而这些优势是建立在 FCS 系统初装的前提下，倘诺企业建立有完善的 DCS，现在要向 FCS 过渡，则必须仔细考虑现有投资对已有投资的回报率。充分利用已有的 DCS 设施，现有 DCS 的布线以及成熟的 DCS 控制管理方式来实现 FCS 是我们应选之途。 虽然现场总线对已有的数字现场协议有优势可言，但向其过渡的代价与风险是必须分析清楚的。再者，从技术的继承及控制手段上

3、，也要求 FCS 与 DCS 应相兼容。FCS实现控制功能下移至现场层，使 DCS 的 多层网络被扁平化，各个现场设备节点的独立功能得以加强，因此，在 FCS中有必要增加和完善现场子层设备间的数据通讯功能。 由于历史的原因，DCS 通常拥有大型控制柜用以协调各个设备，同时更强调层与层的数据传输。可见，两种控制在策略上各具优势。DCS 适用于较慢的数据传输速率；FCS 则更适用于较快的数据传输速率，以及更灵活的处理数据。然而，当数据量超过一定值过于偏大时，如果同层的设备过于独立，则很容易导致数据网络的堵塞。要解决这个问题，拟设立一个适当的监控层用以协调相互通讯的设备，必然是有益的，DCS 就能轻

4、松地胜任这一工作。可见，为使 FCS 的控制方式和手段完善化，是有必要借鉴 DCS 的一些控制思想的。 要把握新世纪工业过程控制的发展趋势，无论在学术研究或是工程应用方面都有必要使 FCS 综合与继承 DCS 的成熟控制策略；与此同时，DCS 的发展也应追寻 FCS 控制策略的新思想，使其具有新的生命力。DCS 应能动地将底层控制权交付给 FCS 系统，将较高层的系统协调管理功能发扬光大，完成对新时代，新形势的工业控制系统的智能设备集成。 12 现场总线传输特点 现场总线控制系统（FCS）是顺应智能现场仪表而发展起来的。它的初衷是用数字通讯代替 420mA 模拟传输技术，但随着现场总线技术与智

5、能仪表管控一体化（仪表调校、控制组态、诊断、报警、记录）的发展，在控制领域内引起了一场前所未有的革命。控制专家们纷纷预言：FCS将成为 21 世纪控制系统的主流。 然而就在人们沸沸扬扬的对 FCS 进行概念炒作的时候，却没有注意到它的发展在某些方面的不协调，其主要表现在迄今为止现场总线的通讯标准尚未统一，这使得各厂商的仪表设备难以在不同的 FCS 中兼容。此外，FCS 的传输速率也不尽人意，以基金会现场总线（FF）正在制定的国际标准为例，它采用了 ISO 的参考模型中的 3 层（物理层、数据链路层和应用层）和极具特色的用户层，其低速总线 H1 的传输速度为 31.25kbps，高速总线 H2

6、的传输速度为1Mbps 或 2.5Mbps，就针对西门子推出的 PROFIBUS 总线而言：其市场站有率相对较大，但由于受通讯线路长度的影响，在 100M 线路长度下最高通讯速率为 12Mbps，这在有些场合下仍无法满足实时控制的要求。由于上述原因，使 FCS 在工业控制中的推广应用受到了一定的限制。当人们冷静下来对这些问题进行思考时，不禁想起了在商业网络中广泛应用的以太网。 以太网具有传输速度高、低耗、易于安装和兼容性好等方面的优势，由于它支持几乎所有流行的网络协议，所以在商业系统中被广泛采用。但是传统以太网采用总线式拓朴结构和多路存取载波侦听碰撞检测（CSMA/CD）通讯方式,在实时性要求

7、较高的场合下，重要数据的传输过程会产生传输延滞，这被称为以太网的“不确定性” 。研究表明：商业以太网在工业应用中的传输延滞在 230ms 之间，这是影响以太网长期无法进入过程控制领域的重要原因之一。因此对以太网的研究具有工程实用价值，从而产生了一种新型以太网。 13 工业以太网的研究现状 近年来控制与通讯工程师们致力于新型工业以太网的研究工作，其中有代表性的是 FF 制定的快速以太网标准，其传输速度为 100Mbps。综观工业以太网的研究现状，出现了两个值得注意的发展方向：以太网集线器和具有实时功能的以太网的协议。 a、以太网集线器 FF 将以太网技术加入到 H2 协议中，并以它作为 H2 的

8、底层协议，其网络采用星型拓朴结构。 集线器（HUB）置于网络中心并通过以太网 I/O 接口挂接现场设备，其中实时现场仪表和普通现场仪表（通过通道组）分别挂接在不同的以太网 I/O 接口上。以太网 I/O 接口高速（约 100 kHz）扫描所有实时现场仪表和通道组，然后传送数据包到上层控制器。 通常普通控制算法在现场控制器中进行（可由上层控制器下载），而高级控制算法则在上层控制器中进行，其控制输出经以太网集线器和以太网 I/O 接口传输到现场执行仪表。由于实时现场仪表挂接在专用的以太网入口地址，并用完全分离的线路传输数据，所以保证了实时数据不会产生传输延滞和线路阻塞。 集线器作为网络的仲裁器，除

9、了控制通信双方的传输时间外，还对传输的数据包进行优先级设置，使每条信息都包含传输优先级等实时参数。此外智能化的集线器还可以动态检测需要通讯的现场设备所在以太网 I/O 口，并为之提供数据缓冲区，这样可大大缩短现场设备的响应时间和减少数据的重发次数。集线器与其它集线器相连可实现不同网络之间的数据共享。 经验证这种采用以太网集线器技术的 FCS 可使实时数据的延迟时间控制在 200 纳秒的范围之内，这已足以满足多数场合的实时控制要求。 b、在以太网的协议中加入实时功能 一些 FCS 的生产商（如 ControlNet、Profibus、Modbus和 Java 等）在开发自己的工业以太网 FCS

10、时，在工业以太网协议中加入实时功能，此项技术被称为“地道” ，它其实仅仅是在设备中加入特殊的协议芯片，这里不做具体介绍。 c、工业以太网的研究课题 上述研究工作的进展为以太网进入 FCS 提供了可行性，但要使以太网能在 FCS 中发挥其强大的网络优势，以满足现代工业控制中日益增长的数据传输和信息传输种类（如语音、图象和视频等）的需要，还有待于研究工作取得更大的突破性进展。目前的研究工作应集中解决以下两个方面的问题： 14 尽快推出 FCS 国际标准 当今的 FCS 领域出现了世界各大厂商各自为战的混乱局面。其中有影响的为 Intel 公司的 Bitbus、德国的 HART 和Profibus、

11、丹麦的 P-NET、Honeyvell 及 AB 的 WorldFIP、Foxboro,ABB 和横河的 ISP、FF 的 H1 和 H2 和 Echelon 的 Lonworks、菲利普的 CAN 等。这种混乱局面是由于各大厂商为了抢占市场急于推出自己的产品，而 FCS 的国际标准又迟迟不能出台所造成的。标准的不统一使各厂家推出的 FCS 成为一个个“自动化孤岛”，不同系统和现场设备的兼容性都很差。FCS 的用户强烈呼吁尽快出台 FCS 的国际标准，以期望实现 FCS 的“世界大同”。 1994 年 6 月 WorldFIP 和 ISP 联合成立了 FF，它包括了世界上几乎所有的著名控制仪表

12、厂商在内的 100 多个成员单位，致力于 IEC 的 FCS 国际标准化工作。但由于部分成员为了自身利益，力图阻止 FCS 的国际标准出台，形成了FF 的 FCS 国际标准难以 “一统天下”的令人担忧的局面。解决这一问题的途径是：一是要求 FF 在其国际标准中推出完善的用户层和严格的互操作性的产品认证；二是提高用户抵制非国际标准的 FCS 的自觉性。 工业以太网向 FCS 现场级的延伸。必须指出，工业以太网 FCS 中，其现场级总线的传输速度并不理想，这是因为工业以太网还只是在上层控制网络中应用，而许多厂商出于安全考虑，在许多技术问题没有解决之前，现场级尚未使用工业以太网，所以 FCS 总体的

13、传输速度没有什么质的飞跃。为了实现以太网向现场级的延伸，除了改进以太网的通讯协议之外，还需要解决网络的本安、现场设备的冗余和通过以太网向现场仪表供电等技术问题。 本人认为，在保留 FCS 特色的基础上解决上述问题才能使工业以太网具有生命力。工业以太网的介入为 FCS 的发展注入了新的活力，随着 FCS 国际标准的推出以及有关技术问题的突破性进展，一个代表 21 世纪潮流的工业以太网的现场总线控制系统时代就会到来。 2 PLC 与 DCS、 FCS 比较 PLC 是由早期继电器逻辑控制系统与微机计算机技术相结合而发展起来的，它是以微处理器为主的一种工业控制仪表，它融计算机技术、控制技术和通信技术

14、于一体，集顺序控制、过程控制和数据处理于一身，可靠性高、功能强大、控制灵活、操作维护简单。近几年来，可编程序控制器及组成系统在我国冶金、电厂、轻工石化、矿业、水处理等行业更是到了广泛的应用，并取得了一定的经济效益。 由于工业生产过程是一个分散系统。用户往往关心的不只是一个控制系统（例如 DEH），因为它只是整个生产过程的一部分。他需要了解、控制整个控制系统。例如，电厂生产原料是煤、水，而制成品是电。因此生产过程控制（PCS）的方式最好是分散进行，而监视、操作和最佳化管理应以集中为好。随着工业生产规模不断扩大，控制管理的要求不断提高，过程参数日益增多，控制回路越加复杂，在 70 年代中期产生了集

15、散控制系统 DCS，他一经出现就受到工业控制界的青睐。DCS 是集计算机技术、控制技术、网络通信技术和图形显示技术于一体的系统。与常规的集中式控制系统相比有如下特点： 1 实现了分散控制。它使得系统控制危险性分散、可靠性高、投资减小、维护方便。 2 实现集中监视、操作和管理。使得管理与现场分离，管理更能综合化和系统化， 3 采用网络通信技术，这是 DCS 的关键技术，它使得控制与管理都具实时性，并解决系统的扩充与升级问题。 目前，由于 PLC 把专用的数据高速公路（HIG HWAY）改成通用的网络，并逐步将 PLC 之间的通信规约靠拢使得PLC 有条件和其它各种计算机系统和设备实现集成，以组成

16、大型的控制系统，这使得 PLC 系统具备了 DCS 的形态，这样，基于 PLC 的 DCS 系统目前在国内外都得到了广泛的应用。应该说，PLC 就其现状和发展趋势，更接近 PCS 系统所要求的 FCS 控制系统。 不过，由于受传统设计理验的影响，完全由 PLC 系统来构成传统的 DCS 系统还较难于让国内保守的设计院大量采用，虽然国外已经有大量的基于 PLC 构成的 DCS 系统正在正常的运行。 3我们采用什么样的系统？ 我们如果有志于在工业自动化控制系统中施展才能就必须发展 DCS 或 FCS 系统。因为它是未来工控领域的主流发展方向。至于采用别人的 DCS、FCS 系统还是自己开发 DCS

17、、 FCS 系统就要看看究竟我们具备什么样的能力，在下面的看法中我将要详细分析我们的主要特点和究竟在技术上需求什么！ 如果说今后选择控制系统，我认为应该选择代表成熟的集散式控制系统 DCS 并具备先进的现场总线控制系统 FCS，它们之间应该相互兼容。 31 采用现有的 DCS 系统 这就是我在摘要中所提及的“维持现状坐观工控产业的日新月异的发展”。这种方式相对来讲无需投入较大的人力、物力开发产品，只须完全选用别人的产品，被动学习新的知识，而自动控制开发处则充当工程调试队。这种方式就目前情况而言可以维持生存，但纵观实例是不可能有大的发展。 32 采用别人的硬件和软件系统（OEM）自己构成 DCS

18、 系统 这种方式我们也曾经尝试过，不过，我们仅仅是降低了部分生产成本。降低产品总成本的主动权不属于我们，而业绩则属于软硬件开发商。 33 与别人合作，共同开发新型 DCS 系统 这种方式我们也曾经尝试过，产品自主权不完全属于我们。技术水平我们先不用评说。但市场接纳程度还不理想。一但合作方短时间没有足够的回报率他是不可能再投入人力、物力以完善系统、提高技术水平。因为他不可能在一棵树上吊死，他还必须生存！这也是人之常情。 如果利用别人的成熟产品之品牌组成全方位合作模式，应该说在世界范围是有成功的例子。关键是应该认真分析、了解为什么市场接纳不够？怎样才能满足市场生存要求？ 34 完全自己开发 DCS

19、 系统 这种想法由来已久！如果 DCS 开发成功，那不言而喻是一件好事！无论在电站自动化或者是其他行业中，工程应用的种种努力都是在为自己而作。其产品成本完全掌握在自己手里。获得更大的利润不再是一句空话。不过，我们应该在动手之前，充分了解自己究竟有没有能力开发产品，又有没有能力将其推向市场。这往往是我们考虑得较多的问题，从而导致我们无法下定决心的关键所在。那就先让我们分析一下究竟需要什么技术和人才吧！ 前面讲了 DCS 系统是集计算机技术、控制技术、网络通信技术和图形显示技术于一体的系统。那就需要计算机、图形显示技术（软硬件件开发、系统维护），控制技术（系统工程师、硬件接口），网络通信技术（网络

20、通讯技术及协议标准制定）。 a. 计算机、图形显示技术（软硬件件开发、系统维护）: DCS 系统的软件技术包括如下方面： 用于控制组态的软件和图形监视软件、各 DI、DO、AI、AO 及专用功能模件的嵌入式操作系统软件及控制、管理软件。 用于完成系统要求的硬件平台，如工程师站计算机系统、操作员站计算机系统、DCS 机柜内的通用、专用模件。所有软件的运算、控制指令必须经过与此相配的硬件系统执行。 b. 控制技术（系统工程师、硬件接口） 完成整个控制系统要求的专业化技术知识。应该熟悉控制对象的工艺过程、特性及要求。 c. 网络通信技术（网络通讯技术及协议标准制定）。 DCS 具有一定的通讯手段，为

21、了兼容今后的 FCS 系统，应具备多种现场通讯手段或通讯转换卡件。需要熟悉多种通讯协议和接口（集线器、交换器、服务器及光纤通讯、光电转换接口等）。 4DCS 软件系统及其发展方向 随着计算机的普及发展，企业网（Intranet）和国际互联网（Internet）的商业化，Microsoft Windows 受欢迎的程度与日俱增，这大大增加了工业控制领域对 Windows 开发的普遍要求。 当今的集散控制系统（DCS）环境下的控制系统软件（或应用程序）与一般环境下的应用程序相比：一方面其功能已经发生了质的变化。比如，DCS 网络下的控制系统软件能够调用、执行 DCS 网络中其它计算机上的一个程序，

22、并与之交互，这是其它环境下的应用程序无法实现的；另一方面，DCS 网络系统将整个系统的任务分散进行，然后集中监视、操作、管理，这些应用程序由于工作于网络环境下，因而分布极广，已被配置在网络中 10 台、100 台、1000 台甚至更多台的机器上运行，如果这些应用程序不够健壮、没有灵活的可伸缩性，将给日后的维护、升级、重新配置带来极大的困难，至少要消耗大量人力、财力和物力。而这种维护、升级、重新配置随着市场的发展，用户需求的扩大是不可避免的。 为了解决这一问题，微软在对 Windows 系统本身进行改进、升级的同时，对 Windows 应用程序的标准、结构等也进行了重新定义，这就是：遵循组件对象

23、模型（COM）/分布式组件对象模型（DCOM）标准、通过 ActiveX 实现的客户机/服务器结构。 客户机/服务器结构的主要思想是：根据 COM/DCOM 标准，将应用程序分割成若干个相互独立的逻辑单元，每个逻辑单元为应用程序提供一定的服务（以后就会明白这些逻辑单元被称为 ActiveX 组件），通过 ActiveX 把这些逻辑单元有机地结合起来，使它们协同工作，完成特定的任务。应用程序是 ActiveX 组件对象的集合，这些 ActiveX 组件对象知道怎样相互通信、相互调用，以实现应用程序要求的功能。 针对 Intranet 下控制系统的特殊情况，微软给出了一个三层的服务系统模型：用户逻

24、辑（或用户服务）、商业逻辑（或商业服务）和数据逻辑（或数据服务）。用户服务提供用户可交互的或显示对数据进行查询、处理结果的屏幕界面等，由于 Windows 应用程序的屏幕界面已经标准化，所以用户服务相对来说变化不会太大，将它作为一个独立的逻辑单元，可被多个应用程序使用，从而实现了代码的重用；商业服务提供用户处理数据的各种规则，这些规则根据不同的用户有所不同，即使同一用户不同时期也可能不同。将它作为一个独立的逻辑单元并统一放在网络服务器中，有利于应用程序的日后维护。如果以后这些规则需要改变，只须重新配置网络服务器中的商业服务，而不需要重新编译客户机的应用程序；数据服务为用户提供各种数据，它是用户

25、的数据源。实际中，这些数据源可能是 Oracle、 SQL Server、FoxPro、Access 以及其它集散控制系统中的数据库（如：Fix 系统）等等。 4.1 组件对象模型（COM）与分布式组件对象模型（DCOM） 多年来，软件工程师们一直在尝试编写可迅速嵌入各程序开发项目的可重用代码软件组件（或简称为组件）。就像硬件工程师们先设计和制造出可用于各种电子设备的元件，然后利用它们组装成设备一样，控制系统软件开发者可以利用软件组件去组装自己的程序块，且很放心地知道这些组件是无故障的。这些组件不使用全局变量，并且独立于任何应用程序。组件对象模型（Component Object Model-

26、COM）就是软件组件采用的一种常规结构。它根据面向对象编程（Object Oriented Programming-OOP）的思想，将组件对象化，给出了面向对象软件组件（或简称为对象组件）的标准。 COM 首次是在对象链接与嵌入（Object Linking and Embedding-OLE）2.0 版中引入的，它是一种标准，而非一种实现。COM 解释了组件之间该如何通信，但为了具体实现它，还需要用到另一个东西，即 ActiveX。 在设计 COM 的过程中，微软解决了下列问题： （1）交互操作能力。开发者怎样才能创建出独立的组件，使其能与其它组件充分地协作，而不用考虑它们是由谁创建的？ （

27、2）版本控制。一旦某个组件正由其他组件或应用程序使用，怎样才能改变或升级这个组件，而不影响正在使用它的组件或应用程序? （3）与语言无关。怎样才能确保用不同语言编写的组件能协同工作？ （4）透明的跨进程交互操作。开发者怎样才能编写组件，使其能在进程内或进程外工作? 然而，OLE2 中的 COM 只解决了同一网络中对象之间的交互问题，而没有解决对象在不同网络中的其它机器上生存或执行的问题，对这一问题的解决将打开通向在 Windows 环境下的分布对象结构之路。为了适应这一需要，微软开发出了分布式组件对象模型。 分布式组件对象模型（Distributed Component Object Mode

28、l-DCOM），即通常所说的“ 网络 OLE“。DCOM 是一种特殊的协议，允许应用程序在分布式计算环境（Distributed Calculating Environment-DCE）里进行面向对象的远程过程调用（Remote Procedure Call-RPC）。DCOM 扩展了 COM 的性能，使得 COM 对象能够通过相关网络与远程机中的另一个对象交互并使用此对象，这些网络可以是局部网、企业的 Intranet 或现今的 Internet。用户可以在 Windows NT4.0 版中得到 DCOM，它特别适用于开发企业的信息管理系统、专用的 Web 等。基于网络方面的不安全性考虑，D

29、COM 自身包含有较高的安全处理功能。 所有软件组件都遵循 COM 或 DCOM 标准。 4.2 ActiveX 根据微软的定义：支持组件对象模型（COM）的对象总称为“组件对象“。而现在流行的术语 OLE即 OLE2，支持 COM，所以 OLE 对象也称为“组件对象“。一个组件对象不仅支持“对象链接与嵌入“ ，而且还可以远程调用或运行其它机器或网络中的组件对象等等，它的功能已远远超过了OLE 字面所能表达的功能。为了适合未来更加复杂的应用，微软决定重新命名它，将所有这些组件对象统称为 ActiveX。 随着 OOP 逐渐成为公认的编程主流，面向对象软件组件已成为事实上的标准。面向对象软件组件

30、统称为 ActiveX 组件。经过一番扩展以后，ActiveX 组件现在可提供对 DCOM的支持。ActiveX 是组件对象模型的一种物理实现方式，它为 ActiveX 组件的创建提供了基础。 ActiveX 组件将程序逻辑封装起来，并可以进程内、本地进程外、远程进程外三种形式之一在网络中运行，为其它应用程序（客户机应用程序）提供服务。因此可以将 ActiveX 组件理解成“服务器“。它要么在“ 进程内“ 工作，即代码在与客户机应用程序相同的进程空间内执行（亦即一个 DLLActiveX DLL）；要么在“进程外“工作，即代码在同一机器的另一个进程内运行，或在远程电脑的另一个进程内执行（亦即一

31、个 EXE 文件ActiveX EXE ）。利用 VisualBasic 5.0，Visual C+5.0 或 Visual J+等 OOP 语言，可以很方便地创建 ActiveX DLL（进程内服务器）和 ActiveX EXE（本地或远程进程外服务器）。 控制系统软件开发者可以将自己的应用程序逻辑编写成进程内 ActiveX DLL 或本地进程外 ActiveX EXE 或远程进程外 ActiveX EXE，以向其他 ActiveX 组件或外部应用程序开放它们的部分或全部对象。 建立和使用 ActiveX EXE 实例的客户应用程序，可开放它们的对象，并在进程外使用它们。这意味着，Acti

32、veX EXE 中的代码运行在它自己的进程中，并且是在它自己的空间中，这可把它与客户应用程序的代码空间分离开来。 ActiveX DLL 不能作为一个应用程序单独运行，但可以为应用程序提供对象的动态链接库。由于 DLL 中的代码与调用它的应用程序运行于同一进程中，所以能使程序执行得更快、更高效。 控制系统软件开发者可以利用 ActiveX 组件组装自己的应用程序。使用 ActiveX 组件的方法与在 OOP 中使用其它对象类似： （1）创建一个你欲使用的 ActiveX 组件对象的实例； （2）利用该对象的方法、属性和事件编写代码； （3）使用完毕释放该对象； （4）必要时进行错误处理。 下面

33、是 Visual Basic 5.0 中一个说明怎样在程序中利用 ActiveX 组件的 VB 程序片段。假设已建立了一个窗体，该窗体包含三个文本框（Text1、Text2 和 Text3）和一个命令按钮（Command1），并且在进程中增加了对微软 Excel 8.0 对象库的引用。当单击命令按钮（Command1）时，在 Command1_Click 事件过程中按照 Microsoft Excel 公式计算 Text1与 Text2 的和，并将相加的结果显示在 Text3 中。程序如下： Private Sub Command1_Click（） 说明对象变量 Dim xlApp As Ex

34、cel. Application Dim xlBook As Excel. Workbook Dim xlSheet As Excel. Worksheet 用 Add 方法创建对象的实例 Set xlApp = New Excel. Application Set xlBook = xlApp. Workbooks.Add Set xlSheet = xlBook. Worksheets.Add 将文本框中的数据赋给 Excel 单元 xlSheet. Cells（1,1）.Value = Text1. Text xlSheet. Cells（2,1）.Value = Text2. Text

35、 在 Excel 中，用 Excel 公式计算其和 xlSheet. Cells（3,1）. Formula = “ = R1C1 + R2C1“ 在 Text3 文本框中显示结果 Text3. Text = xlSheet. Cells（3,1） 保存工作表单 xlSheet. SaveAs“ c:Test.xls“ 关闭 Excel xlApp. Quit 释放对象 Set xlApp = Nothing Set xlBook = Nothing Set xlSheet = Nothing End Sub 为简单起见，程序中没有进行错误检查。用户在编程时应养成检查错误、处理错误的习惯。 由

36、以上程序可以看出，其编程方法完全是 OOP 的方法。这并不奇怪，因为 ActiveX 组件本身就意味着对象之间的共享，ActiveX 组件是一种客户机/ 服务器关系，在这种关系中客户机请求对象，服务器提供对象。然而，具体一个 ActiveX 组件是客户机还是服务器并没有一个明显的界限。前面我们说可以把 ActiveX 组件理解成是一个服务器，因为它为用户程序（客户应用程序）提供服务；然而在其它场合，ActiveX 组件本身往往还要向其它 ActiveX 组件请求服务，这时它又担当客户机的角色。 不管怎样，利用 ActiveX 组件组装成的应用程序，其结构必然是客户机/服务器结构，客户机/ 服务

37、结构是网络发展的必然结果。 4.3 客户机/服务器结构 综观计算机网络系统结构的发展，大致可分为三个阶段：集中式结构、文件服务器结构以及客户机/服务器结构。这三个阶段代表了计算机网络系统结构发展的里程和趋势。 在六、七十年代，如果一家公司需要真正的计算能务（比如，天气预报、地震预报数据处理等等）便会考虑使用大型机，大型机代表一种集中式系统结构。 在集中式结构中，只有两种关键组件：服务器和客户机终端。客户机与服务器之间传输的唯一数据是用户的按键调度信息以及由服务器返回的终端字符。集中式结构伯优点包括出色的安全性以及可实现集中管理，这是因为无论应用程序逻辑还是数据都驻留于同一台机器服务器上；同时也

38、意昧着服务器的费用太高，因为它要完成网络中所有的计算。由于应用程序逻辑和数据都驻留于服务器上，集中式结构没有办法真正划分应用程序逻辑。 在本世纪 80 年代，PC 机进入了商业舞台并逐渐走入千家万户。不久，局域网问世，同时引入了文件服务器的崭新概念。 文件服务器结构以 DOS 局域网和 Windows3.X 为代表。它使得廉价的 PC 机联成网络，共享资源。这对于那些根本没有实力实现大型机方案的公司来说，PC 机无疑是他们的救星。但是，在这种结构中，应用程序逻辑总是在客户工作站上执行，使用的是客户机的 CPU，而不是像集中式结构那样在服务器上执行。这意味着，客户机要有足够的计算能力，以便执行需

39、要的任何应用程序，或能完成任何必要的任务。这无形中增加了客户机的负担，从而抵消了 PC机价格低廉的优点。 为了折中考虑费用与性能问题，引入了客户机/服务器结构。在这种结构中，允许应用程序逻辑在用户工作站、服务器（不再称为“文件服务器“ ）或者两者上运行。SQL Server、Oracle 等是客户机/ 服务器结构的代表。 在客户机/服务器结构中，同时至少有两个独立的应用程序在运行：一个是客户应用程序（简称为客户）；另一个是服务器应用程序（简称为服务器）。客户提出请求，服务器响应请求并为其服务。为了完成一项特定的任务，客户和服务器协同工作，以提高运行速度和效率。例如，在网络环境中，用户在客户端发

40、出 SQL 命令查询服务器上某数据库中的数据，在文件服务器和客户机/服务器这两种结构中，该命令的执行情况是不一样的。如果读者不能区分它们之间的差别，就不可能充分利用客户机/服务器结构为我们提供的强大功能。 事实上，在基于文件服务器的结构中，查询是在客户端赋值并执行的。这就意味着，如果查询涉及的表中有 10000条记录，那么查询逻辑会请求服务器通过网络将包含这 10000 条记录的表全部传送到自己这儿（客户端），在客户端进行查询处理。而在基于客户机/服务器原结构里，SQL 语句本身将通过网络传送并在服务器内执行，服务器使用自己的 CPU 处理完 SQL 语句后，只把处理结果（成功或失败）通过网络

41、反馈回客户端。显然，这大大减轻了网络的负载，同时也缩短了执行时间。这是对基于文件服务器结构性能的一个重要改进。 综上所述，大型机和基于文件服务器的系统由于应用程序逻辑必须在大型机内运行（针对集中式结构）或必须在客户机内执行（针对文件服务器结构），所以不能提供一个真正可伸缩的系统框架。而客户机/服务器系统至少由两部分组成：一台发出请求的客户机，一台为请求服务的服务器。这两个部分协同工作，应用程序逻辑则分布于客户和服务器之间。这样一来，就为开发运行更快、更高效的应用程序提供了基础。 Intranet 和 Internet 为客户机/服务器结构提供了极好的机遇。当今的 Web 技术就是一个典型的客户

42、机/服务器结构：浏览器是客户机，Web 站点是服务器。 4.4 软件开发建议 在 DCS 网络环境下运行的应用程序，应该是遵循 COM/DCOM 标准、通过 ActiveX 实现的客户机/服务器结构的应用程序。因为这样的应用程序是由 ActiveX 组件组装而成的，与其它应用程序结构相比更加健壮、可伸缩性强且容易维护。 另外，应注意：由于微软的重新命名，OLE 文档已成为ActiveX 文档；OLE 控件已成为 ActiveX 控件；等等。从而OLE 这一术语才真正像它早期缩写的含义那样，代表“对象链接与嵌入“，而 OLE 中一些关键技术和组件则成为重新命名后的 ActiveX 技术和组件。

43、需要指出的是，究竟采用何种软件进行开发并不十分重要。采用 Visual Basic 5.0 以上版本的软件可以开发出人机界面十分友好的组态软件和监视软件，这也被大量的专业化组态软件公司优先采用，毕竟它是几乎所有软件编制人员最易上手的工具。它本身具备良好的可视化界面（所见即所得）和良好的结构化风格，允许多人协同工作。由于最大的软件开发工作量之一是编制界面，我们没有必要选择太专业化的开发工具，因为熟悉和掌握是需要较长时间。也有公司采用 Visual Basic & Visual C+5.0 或 Visual J+等语言，可以相互弥补各自的不足。近段时间，国内外有不少公司试着采用 Java 甚至 H

44、TML 语言编制动态的组态软件，将枯燥乏味的组态软件工作当作是动画编辑，逐步得到人们的首肯。这对今后工业以太网控制系统的大量应用无疑将占尽先机，也逐步展现出迷人的前景。 5DCS 向 FCS 系统的过渡及其发展方向 前面我们介绍了，今后 DCS 系统的发展必将是以在 DCS的基础上发展起来的 FCS 替代现在的 DCS，因为 FCS 顺应了自动控制系统的发展潮流。 为了今后的开发工作不迷失方向，我们有必要了解 FCS的主要构成、现状和未来的发展方向，应该说，今天我们讨论的 DCS 应该是今后的 FCS： 51 七十年代以前，控制系统中采用模拟量对传输及控制信号进行转换、传递，其精度差、受干扰信

45、号影响大，因而整个控制系统的控制效果及系统稳定性都很差。七十年代末，随着大规模集成电路的出现，微处理器技术得到很大发展。微处理器功能强、体积小、可靠性高、通过适当的接口电路用于控制系统，控制效果得到提高；但是尽管如此，还是属于集中式控制系统。随着过程控制技术、自动化仪表技术和计算机网络技术的成熟和发展，控制领域又发生了一次技术变革。这次变革使传统的控制系统（如集散控制系统）无论在结构上还是在性能上都发生了巨大的飞跃，这次变革的基础就是现场总线技术的产生。 52 现场总线是连接现场智能设备和自动化控制设备的双向串行、数字式、多节点通信网络，它也被称为现场底层设备控制网络（INFRANET ）。8

46、0 年代以来，各种现场总线技术开始出现，人们要求对传统的模拟仪表和控制系统变革的呼声也越来越高，从而使现场总线成为一次世界性的技术变革浪潮。美国仪表协会（ISA）于 1984 年开始制订现场总线标准，在欧洲有德国的 PROFIBUS 和法国的 FIP 等，各种现场总线标准陆续形成。其中主要的有：基金会现场总线 FF（Foundation Fieldbus）、控制局域网络 CAN（Controller Area Network）、局部操作网络 LonWorks（Local Operating Network）、过程现场总线 PROFIBUS（Process Field Bus）和 HART 协议

47、（Highway Addressable Remote Transducer）等。但是，总线标准的制定工作并非一帆风顺，由于行业与地域发展等历史原因，加上各公司和企业集团受自身利益的驱使，致使现场总线的国际化标准工作进展缓慢。但是不论如何，制定单一的开放国际现场总线标准是发展的必然。 53 当前流行的几类现场总线 531 基金会现场总线 FF 基金会现场总线 FF 是在过程自动化领域得到广泛支持和具有良好发展前景的一种技术。其前身是以美国 FisherRosemount 公司为首，联合 Foxboro、横河、 ABB、西门子等80 家公司制定的 ISP 协议和以 Honeywell 公司为首，

48、联合欧洲等地 150 家公司制定的 World FIP 协议。这两大集团于1994 年 9 月合并，成立了现场总线基金会，致力于开发出国际上统一的现场总线协议。 基金会现场总线分为 H1 和高速 H2 两种通信速率。H1 的传输速率为 31.25Kbps，通信距离可达 1.9km，可支持总线供电和本质安全防暴环境。H2 的传输速率可为 1Mbps 和 2.5Mbps 两种，通信距离为 750m 和 500m。物理传输介质可为双绞线、光缆和无线，其传输信号采用曼切斯特编码。基金会现场总线以 ISO/OSI 开放系统互连模型为基础，取其物理层、数据链路层、应用层为 FF 通信模型的相应层次，并在应

49、用层上增加了用户层。用户层主要针对自动化测控应用的需要，定义了信息存取的统一规则，采用设备描述语言规定了通用的功能块集。FF 总线包括 FF 通信协议、ISO 模型中的 27 层通信协议的通栈、用于描述设备特性及操作接口的 DDL 设备描述语言、设备描述字典，用于实现测量、控制、工程量转换的应用功能块，实现系统组态管理功能的系统软件技术以及构筑集成自动化系统、网络系统的系统集成技术。 532CAN 总线 CAN 总线最早是由德国 Bosch 公司推出，用于汽车内部测量与执行部件之间的数据通信协议。其总线规范已被 ISO国际标准组织制定为国际标准，并且广泛应用于离散控制领域。它也是基于 OSI 模型，但进行了优化，采用了其中的物理层、数据链路层、应用层，提高了实时性。其节点有优先级设定，支持点对点、一点对多点、广播模式通信。各节点可随时发送消息。传输介质为双绞线，通信速率与总线长度有关。CAN 总线采用短消息报文，每一帧有效字节数为 8 个；当节点出错时，可自动关闭，抗干扰能力强，可靠性高。 533LonWorks 总线 LonWorks 技术是美国 ECHELON 公司开发，并与 Motorola 和东芝公司共同倡导的现场总线技术。它采用了 OSI 参考模型