1．集散控制系统DCS与现场总线控制系统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的一些控制思想的。
要把握新世纪工业过程控制的发展趋势，无论在学术研究或是工程应用方面都有必要使FCS综合与继承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、FCS系统就要看看究竟我们具备什么样的能力，在下面的看法中我将要详细分析我们的主要特点和究竟在技术上需求什么！
如果说今后选择控制系统，我认为应该选择代表成熟的集散式控制系统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）的商业化，Microsoft Windows受欢迎的程度与日俱增，这大大增加了工业控制领域对Windows开发的普遍要求。
当今的集散控制系统（DCS）环境下的控制系统软件（或应用程序）与一般环境下的应用程序相比：一方面其功能已经发生了质的变化。比如，DCS网络下的控制系统软件能够调用、执行DCS网络中其它计算机上的一个程序，并与之交互，这是其它环境下的应用程序无法实现的；另一方面，DCS网络系统将整个系统的任务分散进行，然后集中监视、操作、管理，这些应用程序由于工作于网络环境下，因而分布极广，已被配置在网络中10台、100台、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 Calculating 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）；要么在"进程外"工作，即代码在同一机器的另一个进程内运行，或在远程电脑的另一个进程内执行（亦即一个EXE文件－－ActiveX EXE）。利用Visual Basic 5.0，Visual C++5.0或Visual J++等OOP语言，可以很方便地创建ActiveX DLL（进程内服务器）和ActiveX EXE（本地或远程进程外服务器）。
控制系统软件开发者可以将自己的应用程序逻辑编写成进程内ActiveX DLL或本地进程外ActiveX EXE或远程进程外ActiveX EXE，以向其他ActiveX组件或外部应用程序开放它们的部分或全部对象。
建立和使用ActiveX EXE实例的客户应用程序，可开放它们的对象，并在进程外使用它们。这意味着，ActiveX EXE中的代码运行在它自己的进程中，并且是在它自己的空间中，这可把它与客户应用程序的代码空间分离开来。
ActiveX DLL不能作为一个应用程序单独运行，但可以为应用程序提供对象的动态链接库。由于DLL中的代码与调用它的应用程序运行于同一进程中，所以能使程序执行得更快、更高效。
控制系统软件开发者可以利用ActiveX组件组装自己的应用程序。使用ActiveX组件的方法与在OOP中使用其它对象类似：
（1）创建一个你欲使用的ActiveX组件对象的实例；
（2）利用该对象的方法、属性和事件编写代码；
（3）使用完毕释放该对象；
（4）必要时进行错误处理。
下面是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 Excel. Application
Dim xlBook As Excel. Workbook
Dim xlSheet As Excel. Worksheet
'用Add方法创建对象的实例
Set xlApp = New Excel. Application
Set xlBook = xlApp.
Set xlSheet = xlBook.
'将文本框中的数据赋给Excel单元
xlSheet. Cells(1,1).Value = Text1. Text
xlSheet. Cells(2,1).Value = Text2. Text
'在Excel中，用Excel公式计算其和
xlSheet. Cells(3,1). Formula = " = R1C1 + R2C1"
'在Text3文本框中显示结果
Text3. Text = xlSheet. Cells(3,1)
'保存工作表单
xlSheet. SaveAs" c:\"
'关闭Excel
xlApp. Quit
'释放对象
Set xlApp = Nothing
Set xlBook = Nothing
Set xlSheet = Nothing
End Sub
为简单起见，程序中没有进行错误检查。用户在编程时应养成检查错误、处理错误的习惯。
由以上程序可以看出，其编程方法完全是OOP的方法。这并不奇怪，因为ActiveX组件本身就意味着对象之间的共享，ActiveX组件是一种客户机/服务器关系，在这种关系中客户机请求对象，服务器提供对象。然而，具体一个ActiveX组件是客户机还是服务器并没有一个明显的界限。前面我们说可以把ActiveX组件理解成是一个服务器，因为它为用户程序（客户应用程序）提供服务；然而在其它场合，ActiveX组件本身往往还要向其它ActiveX组件请求服务，这时它又担当客户机的角色。
不管怎样，利用ActiveX组件组装成的应用程序，其结构必然是客户机/服务器结构，客户机/服务结构是网络发展的必然结果。
4.3 客户机/服务器结构
综观计算机网络系统结构的发展，大致可分为三个阶段：集中式结构、文件服务器结构以及客户机/服务器结构。这三个阶段代表了计算机网络系统结构发展的里程和趋势。
在六、七十年代，如果一家公司需要真正的计算能务（比如，天气预报、地震预报数据处理等等）便会考虑使用大型机，大型机代表一种集中式系统结构。
在集中式结构中，只有两种关键组件：服务器和客户机终端。客户机与服务器之间传输的唯一数据是用户的按键调度信息以及由服务器返回的终端字符。集中式结构伯优点包括出色的安全性以及可实现集中管理，这是因为无论应用程序逻辑还是数据都驻留于同一台机器－－服务器上；同时也意昧着服务器的费用太高，因为它要完成网络中所有的计算。由于应用程序逻辑和数据都驻留于服务器上，集中式结构没有办法真正划分应用程序逻辑。
在本世纪80年代，PC机进入了商业舞台并逐渐走入千家万户。不久，局域网问世，同时引入了文件服务器的崭新概念。
文件服务器结构以DOS局域网和Windows3.X为代表。它使得廉价的PC机联成网络，共享资源。这对于那些根本没有实力实现大型机方案的公司来说，PC机无疑是他们的救星。但是，在这种结构中，应用程序逻辑总是在客户工作站上执行，使用的是客户机的CPU，而不是像集中式结构那样在服务器上执行。这意味着，客户机要有足够的计算能力，以便执行需要的任何应用程序，或能完成任何必要的任务。这无形中增加了客户机的负担，从而抵消了PC机价格低廉的优点。
为了折中考虑费用与性能问题，引入了客户机/服务器结构。在这种结构中，允许应用程序逻辑在用户工作站、服务器(不再称为"文件服务器")或者两者上运行。SQL Server、Oracle等是客户机/服务器结构的代表。
在客户机/服务器结构中，同时至少有两个独立的应用程序在运行：一个是客户应用程序（简称为客户）；另一个是服务器应用程序（简称为服务器）。客户提出请求，服务器响应请求并为其服务。为了完成一项特定的任务，客户和服务器协同工作，以提高运行速度和效率。例如，在网络环境中，用户在客户端发出SQL命令查询服务器上某数据库中的数据，在文件服务器和客户机/服务器这两种结构中，该命令的执行情况是不一样的。如果读者不能区分它们之间的差别，就不可能充分利用客户机/服务器结构为我们提供的强大功能。
事实上，在基于文件服务器的结构中，查询是在客户端赋值并执行的。这就意味着，如果查询涉及的表中有10000条记录，那么查询逻辑会请求服务器通过网络将包含这10000条记录的表全部传送到自己这儿（客户端），在客户端进行查询处理。而在基于客户机/服务器原结构里，SQL语句本身将通过网络传送并在服务器内执行，服务器使用自己的CPU处理完SQL语句后，只把处理结果（成功或失败）通过网络反馈回客户端。显然，这大大减轻了网络的负载，同时也缩短了执行时间。这是对基于文件服务器结构性能的一个重要改进。
综上所述，大型机和基于文件服务器的系统由于应用程序逻辑必须在大型机内运行（针对集中式结构）或必须在客户机内执行（针对文件服务器结构），所以不能提供一个真正可伸缩的系统框架。而客户机/服务器系统至少由两部分组成：一台发出请求的客户机，一台为请求服务的服务器。这两个部分协同工作，应用程序逻辑则分布于客户和服务器之间。这样一来，就为开发运行更快、更高效的应用程序提供了基础。
Intranet和Internet为客户机/服务器结构提供了极好的机遇。当今的Web技术就是一个典型的客户机/服务器结构：浏览器是客户机，Web站点是服务器。
4.4 软件开发建议
在DCS网络环境下运行的应用程序，应该是遵循COM/DCOM标准、通过ActiveX实现的客户机/服务器结构的应用程序。因为这样的应用程序是由ActiveX组件组装而成的，与其它应用程序结构相比更加健壮、可伸缩性强且容易维护。
另外，应注意：由于微软的重新命名，OLE文档已成为ActiveX文档；OLE控件已成为ActiveX控件；等等。从而OLE这一术语才真正像它早期缩写的含义那样，代表"对象链接与嵌入"，而OLE中一些关键技术和组件则成为重新命名后的ActiveX技术和组件。
需要指出的是，究竟采用何种软件进行开发并不十分重要。采用Visual Basic 5.0以上版本的软件可以开发出人机界面十分友好的组态软件和监视软件，这也被大量的专业化组态软件公司优先采用，毕竟它是几乎所有软件编制人员最易上手的工具。它本身具备良好的可视化界面（所见即所得）和良好的结构化风格，允许多人协同工作。由于最大的软件开发工作量之一是编制界面，我们没有必要选择太专业化的开发工具，因为熟悉和掌握是需要较长时间。也有公司采用Visual Basic & Visual C++5.0或Visual J++等语言，可以相互弥补各自的不足。近段时间，国内外有不少公司试着采用Java甚至HTML语言编制动态的组态软件，将枯燥乏味的组态软件工作当作是动画编辑，逐步得到人们的首肯。这对今后工业以太网控制系统的大量应用无疑将占尽先机，也逐步展现出迷人的前景。
5．DCS向FCS系统的过渡及其发展方向
前面我们介绍了，今后DCS系统的发展必将是以在DCS的基础上发展起来的FCS替代现在的DCS，因为FCS顺应了自动控制系统的发展潮流。
为了今后的开发工作不迷失方向，我们有必要了解FCS的主要构成、现状和未来的发展方向，应该说，今天我们讨论的DCS应该是今后的FCS：
5．1七十年代以前，控制系统中采用模拟量对传输及控制信号进行转换、传递，其精度差、受干扰信号影响大，因而整个控制系统的控制效果及系统稳定性都很差。七十年代末，随着大规模集成电路的出现，微处理器技术得到很大发展。微处理器功能强、体积小、可靠性高、通过适当的接口电路用于控制系统，控制效果得到提高；但是尽管如此，还是属于集中式控制系统。随着过程控制技术、自动化仪表技术和计算机网络技术的成熟和发展，控制领域又发生了一次技术变革。这次变革使传统的控制系统（如集散控制系统）无论在结构上还是在性能上都发生了巨大的飞跃，这次变革的基础就是现场总线技术的产生。
5．2现场总线是连接现场智能设备和自动化控制设备的双向串行、数字式、多节点通信网络，它也被称为现场底层设备控制网络（INFRANET）。80年代以来，各种现场总线技术开始出现，人们要求对传统的模拟仪表和控制系统变革的呼声也越来越高，从而使现场总线成为一次世界性的技术变革浪潮。美国仪表协会(ISA)于1984年开始制订现场总线标准，在欧洲有德国的PROFIBUS和法国的FIP等，各种现场总线标准陆续形成。其中主要的有：基金会现场总线FF（Foundation Fieldbus）、控制局域网络CAN（Controller Area Network）、局部操作网络LonWorks（Local Operating Network）、过程现场总线PROFIBUS（Process Field Bus）和HART协议(Highway Addressable Remote Transducer)等。但是，总线标准的制定工作并非一帆风顺，由于行业与地域发展等历史原因，加上各公司和企业集团受自身利益的驱使，致使现场总线的国际化标准工作进展缓慢。但是不论如何，制定单一的开放国际现场总线标准是发展的必然。
5．3 当前流行的几类现场总线
5．3．1 基金会现场总线FF
基金会现场总线FF是在过程自动化领域得到广泛支持和具有良好发展前景的一种技术。其前身是以美国Fisher－Rosemount公司为首，联合Foxboro、横河、ABB、西门子等80家公司制定的ISP协议和以Honeywell公司为首，联合欧洲等地150家公司制定的World FIP协议。这两大集团于1994年9月合并，成立了现场总线基金会，致力于开发出国际上统一的现场总线协议。
基金会现场总线分为H1和高速H2两种通信速率。H1的传输速率为31.25Kbps，通信距离可达1.9km，可支持总线供电和本质安全防暴环境。H2的传输速率可为1Mbps和2.5Mbps两种，通信距离为750m和500m。物理传输介质可为双绞线、光缆和无线，其传输信号采用曼切斯特编码。基金会现场总线以ISO/OSI开放系统互连模型为基础，取其物理层、数据链路层、应用层为FF通信模型的相应层次，并在应用层上增加了用户层。用户层主要针对自动化测控应用的需要，定义了信息存取的统一规则，采用设备描述语言规定了通用的功能块集。FF总线包括FF通信协议、ISO模型中的2～7层通信协议的通栈、用于描述设备特性及操作接口的DDL设备描述语言、设备描述字典，用于实现测量、控制、工程量转换的应用功能块，实现系统组态管理功能的系统软件技术以及构筑集成自动化系统、网络系统的系统集成技术。
5．3．2 CAN总线
CAN总线最早是由德国Bosch公司推出，用于汽车内部测量与执行部件之间的数据通信协议。其总线规范已被ISO国际标准组织制定为国际标准，并且广泛应用于离散控制领域。它也是基于OSI模型，但进行了优化，采用了其中的物理层、数据链路层、应用层，提高了实时性。其节点有优先级设定，支持点对点、一点对多点、广播模式通信。各节点可随时发送消息。传输介质为双绞线，通信速率与总线长度有关。CAN总线采用短消息报文，每一帧有效字节数为8个；当节点出错时，可自动关闭，抗干扰能力强，可靠性高。
5．3．3 LonWorks总线
LonWorks技术是美国ECHELON公司开发，并与Motorola和东芝公司共同倡导的现场总线技术。它采用了OSI参考模型全部的七层协议结构。LonWorks技术的核心是具备通信和控制功能的Neuron芯片。Neuron芯片实现完整的
LonWorks的LonTalk通信协议。其上集成有三个8位CPU。一个CPU完成OSI模型第一和第二层的功能，称为介质访问处理器。一个CPU是应用处理器，运行操作系统与用户代码。还有一个CPU为网络处理器，作为前两者的中介，它进行网络变量寻址、更新、路径选择、网络通信管理等。由神经芯片构成的节点之间可以进行对等通信。LonWorks支持多种物理介质并支持多种拓扑结构，组网方式灵活，其IS－78本安物理通道使得它可以应用于危险区域。LonWorks应用范围主要包括楼宇自动化、工业控制等，在组建分布式监控网络方面有较优越的性能。
5．3．4 PROFIBUS总线
PROFIBUS是符合德国国家标准DIN19245和欧洲标准EN50179的现场总线，包括 PROFIBUS－DP、PROFIBUS－FMS、PROFIBUS－PA三部分。它也只采用了OSI模型的物理层、数据链路层、应用层。PROFIBUS支持主从方式、纯主方式、多主多从通信方式。主站对总线具有控制权，主站间通过传递令牌来传递对总线的控制权。取得控制权的主站，可向从站发送、获取信息。PROFIBUS－DP用于分散外设间的高速数据传输，适合于加工自动化领域。FMS型适用于纺织、楼宇自动化、可编程控制器、低压开关等。而PA型则是用于过程自动化的总线类型。
5. HART总线
HART协议是由Rosemount公司于1986年提出的通信协议。它是用于现场智能仪表和控制室设备间通信的一种协议。它包括ISO/OSI模型的物理层、数据链路层和应用层。HART通信可以有点对点或多点连接模式。这种协议是可寻址远程传感器高速通道的开放通信协议，其特点是在现有模拟信号传输线上实现数字信号通信，属于模拟系统向数字系统转变过程中的过渡产品，因而在当前的过渡时期具有较强市场竞争力，在智能仪表市场上占有很大的份额。
5．4 现场总线控制系统（FCS）的结构与特点
5．4．1 结构
随着现场总线技术的出现和成熟，促使了控制系统由集散控制系统（DCS）向现场总线控制系统（FCS）的过渡。在一般的FCS系统中，遵循一定现场总线协议的现场仪表可以组成控制回路，使控制站的部分控制功能下移分散到各个现场仪表中。从而减轻了控制站负担，使得控制站可以专职于执行复杂的高层次的控制算法。对于简单的控制应用，甚至可以把控制站取消，在控制站的位置代之以起连接现场总线作用的网桥和集线器，操作站直接与现场仪表相连，构成分布式控制系统。
5．4．2 特点
分布式的FCS系统比DCS系统更好地体现了“信息集中，控制分散"的思想。与传统的DCS 相比，FCS有其自身的特点。FCS系统具有高度的分散性，它可以由现场设备组成自治的控制回路。现场仪表或设备具有高度的智能化与功能自主性，可完成控制的基本功能，并可以随时诊断设备的运行情况。另外，FCS的结构比DCS简化。有的FCS系统省略了DCS中控制站这一层，操作站直接与现场仪表相连。这些使FCS的可靠性得到提高。
现场总线系统具有开放性。系统对相关标准具有一致性、公开性，强调对标准的共识与遵从。通信协议一致公开，各不同厂家的设备之间可实现信息交换，通过现场总线可构筑自动化领域的开放互连系统。系统的开放性决定了它具有互操作性和互用性。互操作性指互连设备间、系统间信息传送与沟通；而互用则意味着不同生产厂家的性能类似的设备可实现相互替换。作为工厂网络底层的现场总线还对现场环境有较强地适应性。它支持双绞线、同轴电缆、光缆、无线和电力线等，具有较强的抗干扰能力。
由于结构上的改变，FCS比DCS更节约硬件设备。使用FCS可以减少大量的隔离器、端子柜、I/O卡及I/O端口，这样就节省了I/O装置及装置室的空间；同时减少了大量电缆，可以极大地节省安装费用。与此同时，FCS比DCS性能有所提高。由于免去了D/A与A/D变换，使仪表精度得到极大的提高；通过将PID功能植入到相应的智能传感器中去，使控制周期大为缩短。目前FCS可以从DCS的每秒调节2～5次增加到每秒调节10～20次，改善了调节性能。FCS控制系统与DCS控制系统结构比较见图1。
5．4．3 现场总线的优点
由于现场总线的以上特点，特别是其系统结构的简化，使其从设计、安装、投运到正常生产运行及检修维护，都体现出优越性。它不仅节省了硬件数量与投资，节省了安装费用，而且系统的维护开销也大大地降低。现场总线控制系统不仅精确度与可靠性高，在方便使用和维护性方面，FCS也比DCS有优势。FCS使用统一的组态方式，安装、运行、维修简便；利用智能化现场仪表，使维修预报（Predicted maintenance）成为可能；由于系统具有互操作性和互用性，用户可以自由选择不同品牌的设备达到最佳的系统集成，在设备出现故障时，可以自由选择替换的设备，保障用户的高度系统集成主动权。
此外，它还具有设计简单，易于重构等特点。
5．4．4 发展趋向
传统的集散控制系统（DCS系统）具有集中监控、分散控制、操作方便的特点。但是，在实际应用中也发现DCS的结构存在一些不足之处，如控制不能做到彻底分散，危险仍然相对集中；由于系统的不开放性，不同厂家的产品不能互换、互联，限制了用户的选择范围。利用现场总线技术，开发FCS系统的目标是针对现存的DCS的某些不足，改进控制系统的结构，提高其性能和通用性。
FCS想要在实际中取代DCS，既要具备DCS所具有的功能，又要能克服DCS的缺点。FCS由于采用了现场总线技术，在开放性、控制分散等方面优于传统DCS。但是由于它是一种新技术，目前连标准本身都还没有制定统一，因此FCS与成熟的DCS相比，还存在下列的一些欠缺。
（1）由于现场总线标准本身尚在发展中，从而给产品的开发和测试带来难度。这在一定程度上造成产品开发商、生产商少，产品品种单一而且价格昂贵。
（2）在某些场合中，FCS还无法提供DCS已有的控制功能。由于软硬件水平的限制，其功能块的功能还不是很强，品种也不够齐全；用现场仪表还只能组成一般的控制回路如单回路、串级、比例控制等，对于复杂的、先进的控制算法还无法在仪表中实现，对于单回路内有多输入、多输出的情况缺乏好的解决方案。
（3）目前FCS成功的应用实例不多，难以评估实际应用效果。
由于以上这些原因，FCS取代DCS将是一个逐渐的过程。在这一过程中，会出现一些过渡型的系统结构，如在DCS中以FCS取代DCS中的某些子系统。用户将现场总线设备连接到独立的现场总线网络服务器，服务器配有DCS中连接操作站的上层网络接口，与操作站直接通信。在DCS的软件系统中可增添相应的通信与管理软件。这样不需要对原有控制系统作结构上的重大变动。
（4）当前，各种形式的现场总线协议并存于控制领域。在楼宇自控领域，Lonworks和CAN网络具有一定的优势；在过程自动化领域，主要有过渡型的HART协议、得到广泛支持的FF现场总线协议以及同样较有竞争力的PROFIBUS协议。HART协议将是目前几年内智能化仪表的主要通信协议；基金会现场总线是过程自动化领域中较有前途的一种现场总线，得到许多自动化仪表设备厂商的支持；由于Lonworks技术的开放性，国内出现了利用它开发控制系统的许多开发商。考虑到统一的开放式现场总线协议标准制定的长期性和艰巨性，传统DCS的退出将是一个渐进过程。在一段时期内，会出现几种现场总线共存、同一生产现场有几种异构网络互连通讯的局面。但是，发展共同遵从的统一的标准规范，真正形成开放式互连系统，是大势所趋。
6．DCS的硬件系统及其发展方向
关于硬件系统，我们还没有更深入的讨论。不过，DCS或者是今后的FCS硬件肯定会大量采用单片嵌入式软硬件系统。这是因为：
1. 无论是DCS的智能模件还是今后FCS的现场模块，必须具备自我诊
断、数据交换等功能；
2. 由于DCS和今后的FCS都会将控制、采集任务下达给远端绝大部分
的模件或模块，以让其分散系统任务，故该类模件或模块必须具备状态或数据采集、或者进行PID控制。因此，它不能缺少MCU；
3. 由于通讯功能的增强，有必要加强通讯协议的认可、总线设备地址的
辨识、误码的智能判断及相应错误的纠正等。
所谓单片嵌入式软硬件系统是指具备可安装与PCB（印制板）还仪器、仪表、专业模块设备内的计算机系统。它并不包括我们常说的PC计算机。
6．1采用单片微处理器的嵌入式软硬件系统
这种系统即是我们常说的单片计算机系统。它往往采用一片单片机加外围芯片构成。主要有AD、DA、DI、DO芯片作为与外部设备交换传统的模拟量信号和开关量信号。并增加与外部的通讯接口电路、完成所谓的RS485物理接口并配合通讯协议在控制总线或现场总线上与主计算机或其他设备交换数据。
由于传统的单片机功能有限，往往还加入了大量的逻辑处理单元和大容量存储器。例如：采用PAL 、GAL、CPLD等。也有采用FPGA以完成逻辑、译码、存储、通讯控制和特殊布尔计算。
必须指出，单片计算机计术仍然在不断发展。很多单片机采用RISC精简指令集和CPLD、FPGA或者是DSP技术，可以片内带FLASH MEMORY，并有JTAG接口，可以在线完成程序擦除、下载、调试等工作。工业控制领域以16BIT单片机为主，逐步采用32BIT甚至64BIT单片机，而应用于通讯领域中以8BIT单片机为多。据《电子工程专辑》报道：由于因特网的接入需求为8位MCU带来新的活力。这表现在8位单片机供应商纷纷采取措施推出增强因特网接入功能的新型8位MCU，这给本来由于常规8位单片机极高的市场需求又注入新的活力。市场预计从2000年的90亿美元增加到2004年的160亿美元。而16位、32位MCU加起来还不到8位MCU的一半。完全打破某些专家和公司预计的16位MCU将在短时间内替代8位MCU。他们的依据8位MCU是没有能力实现与因特网连接。然而，这些预言是错误的。基于8位MCU的低价格性和软件嵌入式操作系统的支持，加上单片机上集成硬件的TCP/IP控制协处理器。这比采用16位甚至32位MCU要可靠、经济。如果说世界各大厂商在采用8位MCU完成通讯功能、而你却想用16位MCU，这除非是你的产品成本比别人低得多，否则无法与别人竞争。
单片机系统配备TCP/IP通讯协议完成以太网接口是目前单片机的热点。国外甚至推出可以发E_mail、上Web浏览的单片机系统。因此，上网冲浪不再是PC 计算机的专利。只有充分享受网上资源的一切设备才是人们所追求的目标。这种技术的大量使用，无疑给未来的工业以太网探明道路。
6．2采用DSP数字处理器的嵌入式软硬件系统
DSP数字处理器是近来发展起来的新技术。它实际上也是单片计算机。一般的单片机内部总线采用程序区和存储器区共用的冯－诺依曼结构。程序按步进行，必须完成取指、运算、执行才能完成一个指令。而DSP采用哈佛结构，程序区和存储器区完全分开，取指、运算可以完全分开，即在运算阶段时可以进行取下一条指令操作。故可以高速、并行工作。由于集成大量的存储器和布尔处理器、复杂逻辑阵列及特殊算法功能块，可以高速处理大量数据甚至轻而易举地完成模糊控制或自适应控制等，是未来嵌入式系统的发展方向。
TMS320系列DSP是美国德州公司的产品。因其内部可以并行运行多个程序故可以处理更复杂的问题，相应程序执行速度得以大大提高。由于硬件回路功能较强，甚至AD、DA转换器也可以直接选择DSP某些接口来构成。
对于需要更快的处理速度（与纯硬件执行速度相当）某些设计完全可以由FPGA组成硬件，而采用VHDL设计语言来满足系统要求。则其执行方式完全并行工作，执行指令也完全与常规的us/步不同，因为它不是按每个功能需要多少个执行周期来完成，而是每个功能由多少个“硬件”构成，它总共延时多少ns。这个“硬件”是由软件来描述，而完成功能确实内部的硬件进行。可以说，它如同一个半导体厂定制的ASIC电路。内部功能由专用硬件构成（不过是看不见硬件），而生成的硬件却是由软件进行描述而生成的。
未来的DSP最终会向FPGA过渡。
6．3 DCS模件向FCS模块的演变
常规的DCS是由若干个机柜中安装各种模件或者是板卡所构成。它们相对集中并且通过内部的通讯、控制总线与各个模件相连接。由于DCS已经发展很久，但其总体结构变化不大。不过，这种结构已经明显显示出不足：
a．由于各板卡集中于几个机柜中，各自的通讯联络采用专用的协议，故属于封闭式，无法直接与第三方设备交换数据，必须进行相互接口、通讯协议转换。开放性较差；
b. 所有的模件接口采用传统的DI、DO、AI、AO，需要大量的电缆与现场设备相连接。直接导致安装复杂、成本居高不下，故障点增多；
c. 模件抗干扰能力、防静电能力差。
而FCS模块强调可以现场安装，高可靠性和恶劣的环境下高防护等级可以直接安装于现场。而相互连接可以通过冗余的通讯电缆连接，所有连接在通讯总线上的设备可以共享信息，最终实现控制功能下移至现场层。
7．结束语：
综上所述，DCS系统最终向FCS系统发展，我们究竟是使用别人的产品或是自己开发，是开发DCS还是FCS这要根据我们自身的实力和情况定。根据技术的发展方向和市场的需求，我认为：如果需要开发DCS产品应该顺应技术的发展方向和市场的需求进行。换句话说，应该结合目前现有品牌DCS并有所扩展－带FCS的模块以逐步向FCS系统过渡即寻找开发的捷径。
根据世界上成功合作例子，有许多厂商之间相互合作，例如美国GE公司与香港Fanuc组成GE FANUC品牌的90XX系列PLC。他们不再是简单的OEM组装，而是进入了较高层次的再开发，在亚州市场上取得了巨大成功。我们能否也借鉴此类方式合作。而不要采用成套购入别人硬件OEM简单的生产方式，共同投入技术，维护、发展产品。这样的合作方式当然取决与对方是否愿意。例如，征得ABB的同意，共同推出适合电站系统的INFI－DF DCS系统，并部分采用自己的硬件和软件系统，获得商标、硬件、软件的使用权，可以在初期按技术合作入股、提成等方式，在东汽生产模件并投入物力、人力开发与FCS相适应的现场总线模块扩展DCS应用范围。
如果此类方式遭到断然拒绝，那我们只有独立开发自己的DCS系统了。
（转载）
