logo资料库

DCS与FCS比较.pdf

发布时间：2022-06-01 发布人：admin 分类：说明书 资料大小：0.27M 资料格式：pdf 举报 版权申诉
第1页 / 共20页
第2页 / 共20页
第3页 / 共20页
第4页 / 共20页
第5页 / 共20页
第6页 / 共20页
第7页 / 共20页
第8页 / 共20页
资料共20页，剩余部分请下载后查看
    集散控制系统 DCS 与现场总线控制系统 1．．．．集散控制系统 与现场总线控制系统 FCS 的比较的比较的比较的比较 与现场总线控制系统 集散控制系统 集散控制系统 与现场总线控制系统 1．1 概述 FCS、DCS FCS 是在 DCS 的基础上发展起来的，FCS 顺应了自动控制系统的发展潮流，它必将替代 DCS。这已是业内人士的基本共识。然而，任何新事物的发生，发展都是在对旧事物的扬弃 中进行的，FCS 与 DCS 的关系必然也不例外。FCS 代表潮流与发展方向，而 DCS 则代表传 统与成熟，也是独具优势的事物。特别是现阶段，FCS 尚没有统一的国际标准而呈群雄逐鹿 之势，DCS 则以其成熟的发展，完备的功能及广泛的应用而占居着一个尚不可完全替代的 地位。本人认为：现场总线控制系统 FCS 应该与集散式控制系统 DCS 相互兼容。 无论是 FCS 或者是 DCS，它们最终是为了满足整个生产过程而进行的系统控制（PCS）。 首先以工程成本与效益看，现场总线的根本优势是良好的互操作性；结构简单，从而布线 费用低；控制功能分散，灵活可靠，以及现场信息丰富。然而这些优势是建立在 FCS 系统 初装的前提下，倘诺企业建立有完善的 DCS，现在要向 FCS 过渡，则必须仔细考虑现有投 资对已有投资的回报率。充分利用已有的 DCS 设施，现有 DCS 的布线以及成熟的 DCS 控 制管理方式来实现 FCS 是我们应选之途。 虽然现场总线对已有的数字现场协议有优势可言，但向其过渡的代价与风险是必须分析清 楚的。再者，从技术的继承及控制手段上，也要求 FCS 与 DCS 应相兼容。FCS 实现控制功 能下移至现场层，使 DCS 的 多层网络被扁平化，各个现场设备节点的独立功能得以加强， 因此，在 FCS 中有必要增加和完善现场子层设备间的数据通讯功能。 由于历史的原因，DCS 通常拥有大型控制柜用以协调各个设备，同时更强调层与层的数 据传输。可见，两种控制在策略上各具优势。DCS 适用于较慢的数据传输速率；FCS 则更 适用于较快的数据传输速率，以及更灵活的处理数据。然而，当数据量超过一定值过于偏大 时，如果同层的设备过于独立，则很容易导致数据网络的堵塞。要解决这个问题，拟设立一 个适当的监控层用以协调相互通讯的设备，必然是有益的，DCS 就能轻松地胜任这一工作。 可见，为使 FCS 的控制方式和手段完善化，是有必要借鉴 DCS 的一些控制思想的。 要把握新世纪工业过程控制的发展趋势，无论在学术研究或是工程应用方面都有必要使 F CS 综合与继承 DCS 的成熟控制策略；与此同时，DCS 的发展也应追寻 FCS 控制策略的新 思想，使其具有新的生命力。DCS 应能动地将底层控制权交付给 FCS 系统，将较高层的系 统协调管理功能发扬光大，完成对新时代，新形势的工业控制系统的智能设备集成。 1．2 现场总线传输特点
    现场总线控制系统（FCS）是顺应智能现场仪表而发展起来的。它的初衷是用数字通讯代 替 4－20mA 模拟传输技术，但随着现场总线技术与智能仪表管控一体化（仪表调校、控制 组态、诊断、报警、记录）的发展，在控制领域内引起了一场前所未有的革命。控制专家们 纷纷预言：FCS 将成为 21 世纪控制系统的主流。 然而就在人们沸沸扬扬的对 FCS 进行概念炒作的时候，却没有注意到它的发展在某些方 面的不协调，其主要表现在迄今为止现场总线的通讯标准尚未统一，这使得各厂商的仪表设 备难以在不同的 FCS 中兼容。此外，FCS 的传输速率也不尽人意，以基金会现场总线（FF） 正在制定的国际标准为例，它采用了 ISO 的参考模型中的 3 层（物理层、数据链路层和应 用层）和极具特色的用户层，其低速总线 H1 的传输速度为 31.25kbps，高速总线 H2 的传输 速度为 1Mbps 或 2.5Mbps，就针对西门子推出的 PROFIBUS 总线而言：其市场站有率相对 较大，但由于受通讯线路长度的影响，在 100M 线路长度下最高通讯速率为 12Mbps，这在 有些场合下仍无法满足实时控制的要求。由于上述原因，使 FCS 在工业控制中的推广应用 受到了一定的限制。当人们冷静下来对这些问题进行思考时，不禁想起了在商业网络中广泛 应用的以太网。 以太网具有传输速度高、低耗、易于安装和兼容性好等方面的优势，由于它支持几乎所有 流行的网络协议，所以在商业系统中被广泛采用。但是传统以太网采用总线式拓朴结构和多 路存取载波侦听碰撞检测（CSMA/CD）通讯方式,在实时性要求较高的场合下，重要数据的 传输过程会产生传输延滞，这被称为以太网的“不确定性”。研究表明：商业以太网在工业应 用中的传输延滞在 2～30ms 之间，这是影响以太网长期无法进入过程控制领域的重要原因 之一。因此对以太网的研究具有工程实用价值，从而产生了一种新型以太网。 1．3 工业以太网的研究现状 近年来控制与通讯工程师们致力于新型工业以太网的研究工作，其中有代表性的是 FF 制 定的快速以太网标准，其传输速度为 100Mbps。综观工业以太网的研究现状，出现了两个值 得注意的发展方向：以太网集线器和具有实时功能的以太网的协议。 a、以太网集线器 FF 将以太网技术加入到 H2 协议中，并以它作为 H2 的底层协议，其网络采用星型拓朴结 构。 集线器（HUB）置于网络中心并通过以太网 I/O 接口挂接现场设备，其中实时现场仪表和 普通现场仪表（通过通道组）分别挂接在不同的以太网 I/O 接口上。以太网 I/O 接口高速（约 100 kHz）扫描所有实时现场仪表和通道组，然后传送数据包到上层控制器。
    通常普通控制算法在现场控制器中进行（可由上层控制器下载），而高级控制算法则在上 层控制器中进行，其控制输出经以太网集线器和以太网 I/O 接口传输到现场执行仪表。由于 实时现场仪表挂接在专用的以太网入口地址，并用完全分离的线路传输数据，所以保证了实 时数据不会产生传输延滞和线路阻塞。 集线器作为网络的仲裁器，除了控制通信双方的传输时间外，还对传输的数据包进行优先 级设置，使每条信息都包含传输优先级等实时参数。此外智能化的集线器还可以动态检测需 要通讯的现场设备所在以太网 I/O 口，并为之提供数据缓冲区，这样可大大缩短现场设备的 响应时间和减少数据的重发次数。集线器与其它集线器相连可实现不同网络之间的数据共 享。 经验证这种采用以太网集线器技术的 FCS 可使实时数据的延迟时间控制在 200 纳秒的范 围之内，这已足以满足多数场合的实时控制要求。 b、在以太网的协议中加入实时功能 一些 FCS 的生产商（如 ControlNet、Profibus、Modbus 和 Java 等）在开发自己的工业以 太网 FCS 时，在工业以太网协议中加入实时功能，此项技术被称为“地道”，它其实仅仅是 在设备中加入特殊的协议芯片，这里不做具体介绍。 c、工业以太网的研究课题 上述研究工作的进展为以太网进入 FCS 提供了可行性，但要使以太网能在 FCS 中发挥其 强大的网络优势，以满足现代工业控制中日益增长的数据传输和信息传输种类（如语音、图 象和视频等）的需要，还有待于研究工作取得更大的突破性进展。目前的研究工作应集中解 决以下两个方面的问题： 1．4 尽快推出 FCS 国际标准 当今的 FCS 领域出现了世界各大厂商各自为战的混乱局面。其中有影响的为 Intel 公司的 Bitbus、德国的 HART 和 Profibus、丹麦的 P-NET、Honeyvell 及 AB 的 WorldFIP、Foxboro, ABB 和横河的 ISP、FF 的 H1 和 H2 和 Echelon 的 Lonworks、菲利普的 CAN 等。这种混乱 局面是由于各大厂商为了抢占市场急于推出自己的产品，而 FCS 的国际标准又迟迟不能出 台所造成的。标准的不统一使各厂家推出的 FCS 成为一个个“自动化孤岛”，不同系统和现 场设备的兼容性都很差。FCS 的用户强烈呼吁尽快出台 FCS 的国际标准，以期望实现 FCS 的“世界大同”。 1994 年 6 月 WorldFIP 和 ISP 联合成立了 FF，它包括了世界上几乎所有的著名控制仪表 厂商在内的 100 多个成员单位，致力于 IEC 的 FCS 国际标准化工作。但由于部分成员为了
    自身利益，力图阻止 FCS 的国际标准出台，形成了 FF 的 FCS 国际标准难以“一统天下”的 令人担忧的局面。解决这一问题的途径是：一是要求 FF 在其国际标准中推出完善的用户层 和严格的互操作性的产品认证；二是提高用户抵制非国际标准的 FCS 的自觉性。 工业以太网向 FCS 现场级的延伸。必须指出，工业以太网 FCS 中，其现场级总线的传输 速度并不理想，这是因为工业以太网还只是在上层控制网络中应用，而许多厂商出于安全考 虑，在许多技术问题没有解决之前，现场级尚未使用工业以太网，所以 FCS 总体的传输速 度没有什么质的飞跃。为了实现以太网向现场级的延伸，除了改进以太网的通讯协议之外， 还需要解决网络的本安、现场设备的冗余和通过以太网向现场仪表供电等技术问题。 本人认为，在保留 FCS 特色的基础上解决上述问题才能使工业以太网具有生命力。工业 以太网的介入为 FCS 的发展注入了新的活力，随着 FCS 国际标准的推出以及有关技术问题 的突破性进展，一个代表 21 世纪潮流的工业以太网的现场总线控制系统时代就会到来。 2．．．． PLC 与与与与 DCS、、、、 FCS 比较比较比较比较 PLC 是由早期继电器逻辑控制系统与微机计算机技术相结合而发展起来的，它是以微处 理器为主的一种工业控制仪表，它融计算机技术、控制技术和通信技术于一体，集顺序控制、 过程控制和数据处理于一身，可靠性高、功能强大、控制灵活、操作维护简单。近几年来， 可编程序控制器及组成系统在我国冶金、电厂、轻工石化、矿业、水处理等行业更是到了广 泛的应用，并取得了一定的经济效益。 由于工业生产过程是一个分散系统。用户往往关心的不只是一个控制系统（例如 DEH）， 因为它只是整个生产过程的一部分。他需要了解、控制整个控制系统。例如，电厂生产原料 是煤、水，而制成品是电。因此生产过程控制（PCS）的方式最好是分散进行，而监视、操 作和最佳化管理应以集中为好。随着工业生产规模不断扩大，控制管理的要求不断提高，过 程参数日益增多，控制回路越加复杂，在 70 年代中期产生了集散控制系统 DCS，他一经出 现就受到工业控制界的青睐。DCS 是集计算机技术、控制技术、网络通信技术和图形显示 技术于一体的系统。与常规的集中式控制系统相比有如下特点： 1． 实现了分散控制。它使得系统控制危险性分散、可靠性高、投资减小、维护方便。 2． 实现集中监视、操作和管理。使得管理与现场分离，管理更能综合化和系统化， 3． 采用网络通信技术，这是 DCS 的关键技术，它使得控制与管理都具实时性，并解决系 统的扩充与升级问题。 目前，由于 PLC 把专用的数据高速公路（HIG HWAY）改成通用的网络，并逐步将 PLC 之间的通信规约靠拢使得 PLC 有条件和其它各种计算机系统和设备实现集成，以组成大型 的控制系统，这使得 PLC 系统具备了 DCS 的形态，这样，基于 PLC 的 DCS 系统目前在国
    内外都得到了广泛的应用。应该说，PLC 就其现状和发展趋势，更接近 PCS 系统所要求的 FCS 控制系统。 不过，由于受传统设计理验的影响，完全由 PLC 系统来构成传统的 DCS 系统还较难于让 国内保守的设计院大量采用，虽然国外已经有大量的基于 PLC 构成的 DCS 系统正在正常的 运行。 3．．．．我们采用什么样的系统 我们采用什么样的系统？？？？ 我们采用什么样的系统 我们采用什么样的系统 我们如果有志于在工业自动化控制系统中施展才能就必须发展 DCS 或 FCS 系统。因为它 是未来工控领域的主流发展方向。至于采用别人的 DCS、FCS 系统还是自己开发 DCS、FC S 系统就要看看究竟我们具备什么样的能力，在下面的看法中我将要详细分析我们的主要特 点和究竟在技术上需求什么！ 如果说今后选择控制系统，我认为应该选择代表成熟的集散式控制系统 DCS 并具备先进 的现场总线控制系统 FCS，它们之间应该相互兼容。 3．1 采用现有的 DCS 系统 这就是我在摘要中所提及的“维持现状坐观工控产业的日新月异的发展”。这种方式相对来 讲无需投入较大的人力、物力开发产品，只须完全选用别人的产品，被动学习新的知识，而 自动控制开发处则充当工程调试队。这种方式就目前情况而言可以维持生存，但纵观实例是 不可能有大的发展。 3．2 采用别人的硬件和软件系统（OEM）自己构成 DCS 系统 这种方式我们也曾经尝试过，不过，我们仅仅是降低了部分生产成本。降低产品总成本的 主动权不属于我们，而业绩则属于软硬件开发商。 3．3 与别人合作，共同开发新型 DCS 系统 这种方式我们也曾经尝试过，产品自主权不完全属于我们。技术水平我们先不用评说。但 市场接纳程度还不理想。一但合作方短时间没有足够的回报率他是不可能再投入人力、物力 以完善系统、提高技术水平。因为他不可能在一棵树上吊死，他还必须生存！这也是人之常 情。 如果利用别人的成熟产品之品牌组成全方位合作模式，应该说在世界范围是有成功的例 子。关键是应该认真分析、了解为什么市场接纳不够？怎样才能满足市场生存要求？ 3．4 完全自己开发 DCS 系统
    这种想法由来已久！如果 DCS 开发成功，那不言而喻是一件好事！无论在电站自动化或 者是其他行业中，工程应用的种种努力都是在为自己而作。其产品成本完全掌握在自己手里。 获得更大的利润不再是一句空话。不过，我们应该在动手之前，充分了解自己究竟有没有能 力开发产品，又有没有能力将其推向市场。这往往是我们考虑得较多的问题，从而导致我们 无法下定决心的关键所在。那就先让我们分析一下究竟需要什么技术和人才吧！ 前面讲了 DCS 系统是集计算机技术、控制技术、网络通信技术和图形显示技术于一体的 系统。那就需要计算机、图形显示技术（软硬件件开发、系统维护），控制技术（系统工程 师、硬件接口），网络通信技术（网络通讯技术及协议标准制定）。 a. 计算机、图形显示技术（软硬件件开发、系统维护）: DCS 系统的软件技术包括如下方面： 用于控制组态的软件和图形监视软件、各 DI、DO、AI、AO 及专用功能模件的嵌入式操 作系统软件及控制、管理软件。 用于完成系统要求的硬件平台，如工程师站计算机系统、操作员站计算机系统、DCS 机柜 内的通用、专用模件。所有软件的运算、控制指令必须经过与此相配的硬件系统执行。 b. 控制技术（系统工程师、硬件接口） 完成整个控制系统要求的专业化技术知识。应该熟悉控制对象的工艺过程、特性及要求。 c. 网络通信技术（网络通讯技术及协议标准制定）。 DCS 具有一定的通讯手段，为了兼容今后的 FCS 系统，应具备多种现场通讯手段或通讯 转换卡件。需要熟悉多种通讯协议和接口（集线器、交换器、服务器及光纤通讯、光电转换 接口等）。 4．．．．DCS 软件系统及其发展方向 软件系统及其发展方向 软件系统及其发展方向 软件系统及其发展方向 随着计算机的普及发展，企业网（Intranet）和国际互联网（Internet）的商业化，Microso ft Windows 受欢迎的程度与日俱增，这大大增加了工业控制领域对 Windows 开发的普遍要 求。 当今的集散控制系统（DCS）环境下的控制系统软件（或应用程序）与一般环境下的应用 程序相比：一方面其功能已经发生了质的变化。比如，DCS 网络下的控制系统软件能够调 用、执行 DCS 网络中其它计算机上的一个程序，并与之交互，这是其它环境下的应用程序 无法实现的；另一方面，DCS 网络系统将整个系统的任务分散进行，然后集中监视、操作、 管理，这些应用程序由于工作于网络环境下，因而分布极广，已被配置在网络中 10 台、10
    0 台、1000 台甚至更多台的机器上运行，如果这些应用程序不够健壮、没有灵活的可伸缩性， 将给日后的维护、升级、重新配置带来极大的困难，至少要消耗大量人力、财力和物力。而 这种维护、升级、重新配置随着市场的发展，用户需求的扩大是不可避免的。 为了解决这一问题，微软在对 Windows 系统本身进行改进、升级的同时，对 Windows 应 用程序的标准、结构等也进行了重新定义，这就是：遵循组件对象模型（COM）/分布式组 件对象模型（DCOM）标准、通过 ActiveX 实现的客户机/服务器结构。 客户机/服务器结构的主要思想是：根据 COM/DCOM 标准，将应用程序分割成若干个相 互独立的逻辑单元，每个逻辑单元为应用程序提供一定的服务（以后就会明白这些逻辑单元 被称为 ActiveX 组件），通过 ActiveX 把这些逻辑单元有机地结合起来，使它们协同工作， 完成特定的任务。应用程序是 ActiveX 组件对象的集合，这些 ActiveX 组件对象知道怎样相 互通信、相互调用，以实现应用程序要求的功能。 针对 Intranet 下控制系统的特殊情况，微软给出了一个三层的服务系统模型：用户逻辑（或 用户服务）、商业逻辑（或商业服务）和数据逻辑（或数据服务）。用户服务提供用户可交 互的或显示对数据进行查询、处理结果的屏幕界面等，由于 Windows 应用程序的屏幕界面 已经标准化，所以用户服务相对来说变化不会太大，将它作为一个独立的逻辑单元，可被多 个应用程序使用，从而实现了代码的重用；商业服务提供用户处理数据的各种规则，这些规 则根据不同的用户有所不同，即使同一用户不同时期也可能不同。将它作为一个独立的逻辑 单元并统一放在网络服务器中，有利于应用程序的日后维护。如果以后这些规则需要改变， 只须重新配置网络服务器中的商业服务，而不需要重新编译客户机的应用程序；数据服务为 用户提供各种数据，它是用户的数据源。实际中，这些数据源可能是 Oracle、SQL Server、 FoxPro、Access 以及其它集散控制系统中的数据库（如：Fix 系统）等等。 4.1 组件对象模型（COM）与分布式组件对象模型（DCOM） 多年来，软件工程师们一直在尝试编写可迅速嵌入各程序开发项目的可重用代码－－软件 组件（或简称为组件）。就像硬件工程师们先设计和制造出可用于各种电子设备的元件，然 后利用它们组装成设备一样，控制系统软件开发者可以利用软件组件去组装自己的程序块， 且很放心地知道这些组件是无故障的。这些组件不使用全局变量，并且独立于任何应用程序。 组件对象模型（Component Object Model——-COM）就是软件组件采用的一种常规结构。 它根据面向对象编程（Object Oriented Programming——-OOP）的思想，将组件对象化，给 出了面向对象软件组件（或简称为对象组件）的标准。 COM 首次是在对象链接与嵌入（Object Linking and Embedding——-OLE）2.0 版中引入的， 它是一种标准，而非一种实现。COM 解释了组件之间该如何通信，但为了具体实现它，还 需要用到另一个东西，即 ActiveX。
    在设计 COM 的过程中，微软解决了下列问题： （1）交互操作能力。开发者怎样才能创建出独立的组件，使其能与其它组件充分地协作， 而不用考虑它们是由谁创建的？ （2）版本控制。一旦某个组件正由其他组件或应用程序使用，怎样才能改变或升级这个 组件，而不影响正在使用它的组件或应用程序? （3）与语言无关。怎样才能确保用不同语言编写的组件能协同工作？ （4）透明的跨进程交互操作。开发者怎样才能编写组件，使其能在进程内或进程外工作? 然而，OLE2 中的 COM 只解决了同一网络中对象之间的交互问题，而没有解决对象在不 同网络中的其它机器上生存或执行的问题，对这一问题的解决将打开通向在 Windows 环境 下的分布对象结构之路。为了适应这一需要，微软开发出了分布式组件对象模型。 分布式组件对象模型（Distributed Component Object Model——-DCOM），即通常所说的" 网络 OLE"。DCOM 是一种特殊的协议，允许应用程序在分布式计算环境（Distributed Calc ulating Environment——-DCE）里进行面向对象的远程过程调用（Remote Procedure Call—— -RPC）。DCOM 扩展了 COM 的性能，使得 COM 对象能够通过相关网络与远程机中的另一 个对象交互并使用此对象，这些网络可以是局部网、企业的 Intranet 或现今的 Internet。用户 可以在 Windows NT4.0 版中得到 DCOM，它特别适用于开发企业的信息管理系统、专用的 Web 等。基于网络方面的不安全性考虑，DCOM 自身包含有较高的安全处理功能。 所有软件组件都遵循 COM 或 DCOM 标准。 4.2 ActiveX 根据微软的定义：支持组件对象模型（COM）的对象总称为"组件对象"。而现在流行的 术语 OLE－－即 OLE2，支持 COM，所以 OLE 对象也称为"组件对象"。一个组件对象不仅 支持"对象链接与嵌入"，而且还可以远程调用或运行其它机器或网络中的组件对象等等，它 的功能已远远超过了 OLE 字面所能表达的功能。为了适合未来更加复杂的应用，微软决定 重新命名它，将所有这些组件对象统称为 ActiveX。 随着 OOP 逐渐成为公认的编程主流，面向对象软件组件已成为事实上的标准。面向对象 软件组件统称为 ActiveX 组件。经过一番扩展以后，ActiveX 组件现在可提供对 DCOM 的支 持。ActiveX 是组件对象模型的一种物理实现方式，它为 ActiveX 组件的创建提供了基础。 ActiveX 组件将程序逻辑封装起来，并可以进程内、本地进程外、远程进程外三种形式之 一在网络中运行，为其它应用程序（客户机应用程序）提供服务。因此可以将 ActiveX 组件 理解成"服务器"。它要么在"进程内"工作，即代码在与客户机应用程序相同的进程空间内执 行（亦即一个 DLL－－ActiveX DLL）；要么在"进程外"工作，即代码在同一机器的另一个
    分享到：
    赞 收藏

    相关推荐

    资料库

    行业

    共收录7266份资料，累计15个分类，关注成员有19位，主要包括：物流,旅游,餐饮零售,网络游戏,咨询,金融,电子政务,外包,教育,制造,医疗,嵌入式,互联网,交通,电信

    热门标签

    物流 旅游 餐饮零售 网络游戏 咨询 金融 电子政务 外包 教育 制造 医疗 嵌入式 互联网 交通 电信

    最新资料