这种想法由来已久！如果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台、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 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. Workbooks.Add
Set xlSheet = xlBook. Worksheets.Add ?将文本框中的数据赋给Excel单元 xlSheet. Cells（1,1）.Value = Text1. Text xlSheet. Cells（2,1）.Value = Text2. Text ?在Excel中，用Excel公式计算其和
xlSheet. Cells（3,1）. Formula = \?在Text3文本框中显示结果 Text3. Text = xlSheet. Cells（3,1） ?保存工作表单
xlSheet. SaveAs\?关闭Excel xlApp. Quit ?释放对象
Set xlApp = Nothing Set xlBook = Nothing Set xlSheet = Nothing End Sub
为简单起见，程序中没有进行错误检查。用户在编程时应养成检查错误、处理错误的习惯。 由以上程序可以看出，其编程方法完全是OOP的方法。这并不奇怪，因为ActiveX组件本身就意味着对象之间的共享，ActiveX组件是一种客户机/服务器关系，在这种关系中客户机请求对象，服务器提供对象。然而，具体一个ActiveX组件是客户机还是服务器并没有一个明显的界限。前面我们说可以把ActiveX组件理解成是一个服务器，因为它为用户程序（客户应用程序）提供服务；然而在其它场合，ActiveX组件本身往往还要向其它ActiveX组件请求服务，这时它又担当客户机的角色。
不管怎样，利用ActiveX组件组装成的应用程序，其结构必然是客户机/服务器结构，客户机/服务结构是网络发展的必然结果。 4.3 客户机/服务器结构
综观计算机网络系统结构的发展，大致可分为三个阶段：集中式结构、文件服务器结构以及客户机/服务器结构。这三个阶段代表了计算机网络系统结构发展的里程和趋势。 在六、七十年代，如果一家公司需要真正的计算能务（比如，天气预报、地震预报数据处理等等）便会考虑使用大型机，大型机代表一种集中式系统结构。