四、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系统）等等。

（一）组件对象模型（COM）与分布式组件对象模型（DCOM）

    多年来，软件工程师们一直在尝试编写可迅速嵌入各程序开发项目的可重用代码：软件组件（或简称为组件）。就像硬件工程师们先设计和制造出可用于各种电子设备的元件，然后利用它们组装成设备一样，控制系统软件开发者可以利用软件组件去组装自己的程序块，且很放心地知道这些组件是无故障的。这些组件不使用全局变量，并且独立于任何应用程序。组件对象模型（Component Object Model——COM）就是软件组件采用的一种常规结构。它根据面向对象编程（Object Oriented Programming——OOP）的思想，将组件对象化，给出了面向对象软件组件（或简称为对象组件）的标准。

    COM首次是在对象链接与嵌入（Object Linking and Embedding——OLE）2.0版中引入的，它是一种标准，而非一种实现。COM解释了组件之间该如何通信，但为了具体实现它，还需要用到另一个东西，即ActiveX。

在设计COM的过程中，微软解决了下列问题：

1．交互操作能力。开发者怎样才能创建出独立的组件，使其能与其它组件充分地协作，而不用考虑它们是由谁创建的？

2．版本控制。一旦某个组件正由其他组件或应用程序使用，怎样才能改变或升级这个组件，而不影响正在使用它的组件或应用程序?