当今的控制系统被广泛运用于许多领域。从单纯的工业控制系统到协同控制系统（CCS），控制系统不停变化，不断升级，现在则趋向于家庭控制系统，而它则是这两者的变种。被应用的控制系统的种类取决于技术要求。而且，实践表明，经济和社会因素也对此很重要。任何决定都有它的优缺点。工业控制要求可靠性，完整的文献记载和技术支持。经济因素使决定趋向于协同工具。能够亲自接触源码并可以更快速地解决问题是家庭控制系统的要求。多年的操作经验表明哪个解决方法是最主要的不重要，重要的是哪个可行。由于异类系统的存在，针对不同协议的支持也是至关重要的。本文介绍工业控制系统，PlC controlled turn key系统，和CCS工具，以及它们之间的操作。

80年代早期，随着为HERA(Hadron-Elektron-Ring-Anlage)加速器安装低温控制系统，德国电子同步加速器研究所普遍开始研究过程控制。这项新技术是必需的，因为但是现有的硬件没有能力来处理标准过程控制信号，如4至20毫安的电流输入和输出信号。而且软件无法在0.1秒的稳定重复率下运行PID控制回路。此外，在实现对复杂的低温冷藏系统的开闭过程中，频率项目显得尤为重要。

有必要增加接口解决总线问题并增加运算能力，以便于低温控制。因为已安装的D / 3系统[1] 只提供了与多总线板串行连接，以实现DMA与VME的连接并用其模拟多总线板的功能。温度转换器的计算功能来自一个摩托罗拉MVME 167 CPU和总线适配器，以及一个MVME 162 CPU。其操作系统是VxWorks，而应用程序是EPICS。

由于对它的应用相当成功，其还被运用于正在寻找一个通用的解决方案以监督他们的分布式PLC的公共事业管理。

集散控制系统（D/ 3）：

市场调查表明：来自GSE的D / 3系统被HERA低温冷藏工厂选中。因为集散控制系统（D/ 3）的特性，所以这决定很不错。在展示端和I / O端扩展此系统的可能将有助于解决日益增加的 
HERA试验控制的要求。制约系统的大小的因素不是I / O的总数，通信网络的畅通与否。而通信网络的畅通与否取决于不存档的数据总量，不取决于报警系统中配置的数据。

拥有DCS特点（Cube）的SCADA系统：

相对于Y2K问题促使我们寻找一个升级版或者代替版来代替现有的系统而言，以上提到的D / 3系统有一些硬编码的限制。由于急需给Orsi公司提供他们的产品，Cube开始起作用了[2]。该项目包括安装功能的完全更换。这包括D / 3，以及德国电子同步加速器研究所的集成总线SEDAC和VME的温度转换器。该项目很有前景。但是因为HERA试验原定时间是有限制的，所以技术问题和组织问题也迫使计划提前。在供应商网站上的最后验收测试又出现了戏剧性的性能问题。有两个因素引起了这些问题。第一个跟低估在1赫兹运行的6级温度转换器的CPU负荷有关。第二个由现有D / 3系统复杂的功能造成的额外负荷引起的。每个数字和模拟输入和输出通道在D / 3系统里的自身报警限值也被低估了。所有的附加功能都必须添加进去。最后，所有网络负载的报警限值，尤其是SCADA系统，也促使网络生成了限制。

最后，与Orsi公司的合同被取消了。升级的D / 3系统是唯一可能的解决办法。在2003年3月，此系统最后被付诸实践。

现在，相比“纯粹”SCADA系统的异质环境，Cube有同质配置环境的优势。

SCADA（PVSS -Ⅱ）：

在HERA加速器上的H1实验中，实验人员为升级他们的低速控制系统，决定使用PVSS -Ⅱ。现有的系统是由H1合作组的几名成员开发的，而现在却难以维持了。在CERN由联合控制项目[4]进行的广泛调查促使他们做出使用PVSS作为代替品的决定。PVSS是一个“纯粹”的监控和数据采集系统（SCADA系统）。其核心元素叫做事件管理器。它收集的数据主要是由I/ O设备提供。它还提供附加的管理服务，如：控制经理，数据库管理，用户界面，API经理以及在建的HTTP服务器。该PVSS脚本库允许执行复杂的序列以及复杂的图形。相比其他SCADA系统PVSS带有一个基本特点：它提供了API给设备的数据。

SCADA系统的一个主要缺点是其中的两个数据库，一个为PLC’s服务，另一个为SCADA系统服务，这两个数据库必须维持。集成环境将努力克服这个限制。

EPICS：

在德国电子同步加速器研究所，EPICS从问题解决系统演化成了全集成控制系统。从成为低温控制系统的数据收集器和数量控制器，EPICS成为了德国电子同步加速器研究所公用事业集团使用的核心系统。此外，通过 Industry Pack（IP）模块的手段，它还能运用于通过VME板卡的任何数据。EPICS通过其完整的功能，运用于没有由D / 3系统控制的低温冷藏系统。所有大约50个输入输出控制器运作大约25000业务处理记录。

作为一个SCADA系统的EPICS：

该公共事业组（水，电，压缩空气，加热和调温）使用各种散布在整个德国电子同步加速器研究所网站上的PLC。IOC向客户提供接口并采集数据。此外，如通道归档和图形显示（dm2k） 会被使用。默认名决议和目录服务器（域名服务器）用于连接 在TCP客户端和服务器应用程序。所有这些都是基本的SCADA功能。所有的配置文件（图形工具，报警处理程序和归档）提供了一种灵活的配置方案。德国电子同步加速器研究所公用事业集团已制定了一套工具来创建IOC数据库和配置文件。这样，控制组提供的服务保持EPICS工具，而用户可以精力集中在被控制的设备上了。

作为一个DCS系统的EPICS：

作为SCADA系统的基本组成部分，EPICS还提供完整的输入输出控制器（IOC）。IOC提供所有功能DCS系统要求，如：实施每个记录的标准的属性；执行每个记录时的报警检查过程；控制记录，如PID。灵活的命名方案，默认的显示和每个记录的报警属性缓和了运作工具和IOC之间的连接。灵活的数据采集模式，支持调查模式以及发布订阅模式。后者大大降低了信息拥堵的情况。

PLC’s：

PLC’s同样提供丰富的功能，因为以前它是独一无二的控制系统。此外，定期执行一个确定功能的基本特征也让他们通过以太网通信，包括内置的HTTP服务器和不同集合的通讯方案。除了通信处理器，显示器能和PLC’s连接。

智能I / O：

I / O设备上的新发展允许在更小的群体中集群I / O并把这些集群I / O渠道链接到控制系统。PLC’s对于分布式I / O已不再重要。PLC’s和智能I / O子系统的差别正在消失。

前端控制器： 

对控制系统的核心要素之一，是前端控制器。PLC’s可用于实施控制功能的设备。它的缺点就是复杂，难以达到控制属性。例如确定通信协议和最后在显示、报警和归档方案，一个控件的所有属性像P，I和D参数，还有报警限制及其他附加的属性必须得到解决。另外，这些嵌入式属性修改是很难寻觅，因为其中涉及两个或两个以上轨道系统这可能是一个有力的论据是，为什么控制回路主要实施在IOC层面，而不是PLC’s层面。

I / O和控制回路

复杂的控制算法和控制回路和域名DCS控制系统一样。对显示和控件的属性的支持是必不可少的。

频率/国家计划

在控制系统中，频率程序可以运行任何处理器。运行时环境取决于相关代码。控制系统程序直接履行运行前端处理器的监控。为复杂的启动和关闭处理程序设立的频率程序也可以运行工作站。国家机器的基本功能在IEC 61131中得到了落实。编码发电机可以产生C代码。

对现场总线和起源于I / O的Ethernet的支持是为SCADA系统服务的一个基本功能。所有SCADA系统在市场商业运作中是可行的。配置特定驱动器和数据转换器的集成硬件在商业环境中是一个难点。开放API或脚本支持有时有助于整合用户的硬件。如果不向控制系统提供这些工具，就很难整合客户硬件。

新的工业标准，如OPC，和OPC设施联系，还和控制系统之间互相联系。这种功能的基本条件是强调操作系统。在这种情况下，OPC更趋向于微软的DCOM标准。基于控制系统的UNIX很难互相连接。只有支持多平台的控制系统可以在异构环境中发挥主要作用。

1图形

DCS或自定义天气显示程序使用常见的I / O点属性集。这个预定义的命名方案填写标准的属性值，因此只需要进入记录，或设备名称进入配置工具。

2 报警系统

警报可以很好的区分不同的控制系统架构。实现I / O对象的这些系统在前后端电脑提供警报检查。只能读懂I / O点的系统在I / O处理过程中添加了警报检查。I / O对象途径在前后端系统的本土项目语言安插了警报检测。，I / O点导向系统通常要在他们的脚文本语言中实现这种功能。这是通常效率较低且容易出错，因为所有属性必须被单独配置，这导致了一系列特性。不仅为每个I / O点的错误状态结束是个人的I / O点，但报警限值和每个报警的轻重，应当限制定义为I / O点，如果它希望能够改变运行值。

这种影响在SCADA和DCS系统之间也形成了影响。SCADA系统本就读不懂报警系统。DCS系统的优势在于管理人员既可以登记警报状态，从而提前得到信息，控制蔓延到在控制系统周围的变化。后一种情况是唯一可能的系统。

3 趋势和归档

4编程接口

关于开放编程接口，PLC’s和DCS系统有相同策略。他们运行可靠，因为他们没有办法整合 可定制的合作去干涉内部处理。因此，客户定制精品，这个极其昂贵的。

由于SCADA系统必须能够 与多种I / O子系统连接已经在API上建立了I / O子系统以整合 自定义功能。

协作系统尤其需要一定的开放性以实现各种发展组织的要求。所有级别的编程接口，例如前后端I / O，前后端处理过程和网络等，是强制性的。

5冗余

如果冗余是指管理所有国家，I / O所有值无缝道岔当前正在运行，它是一个域，只有少数集散系统。自定义或CCS实施不提供这种功能。也许是因为巨大努力和事实，它是只需要在罕见的事例。此外，处理器冗余，或多余的网络，或I / O子系统是为一定的商业集散控制系统指定的。

先进的安全要求是由多余的PLC子系统覆盖。这些安装在（核）电厂。个人保护系统（PPS）的要求有时候会由冗余的PLC’s来满足。在过程控制中，冗余的PLC’s只在少数情况下使用。

6命名空间

在供应链系统中，SCADA系统的单位名称空间形容成警报部分。有些SCADA系统（如PVSS – II）提供在少数情况下的控制对象或结构化数据。这些对象由一系列特性（包括I / O点）和一套方法（宏或函数）组成。这些途径的其一是UniNified工业控制系统（UNICOS）在欧洲核子研究中心[5]。

DCS系统和大多数习惯性/协作系统是有记录的，或是设备为主。不同之处是，通常一个记录被连接到一个单一I / O点，提供这样的执行记录，如个人工程单元，显示和警报限值。设备为本的方法允许连接几个I / O点。而（EPICS的）记录只服务于一组特定的内置功能。

从I / O级开始，他们必须决定是否需要商业解决。特殊的I / O不总是需要定制解决方案。信号可以被转换成标准的信号，但是这并不适用于所有的信号。信号水平可能需要定制的发展，这必须纳入整体控制架构。信号不能被连接到标准I / O接口，也许有可能发展的I / O控制器的 
允许实施现场总线接口，这能够整合商业控制系统。整合水平是不可能定制前端控制器，如VME，开始发挥作用了。

Turn Key 系统：

在工业中，有个明显的趋势就是产生了Turn Key 系统。它允许对整个系统进行模块化设计。个别元件分包给几个公司进行本地测试。一旦交付施工现场，验收测试就已经过去了，第二个阶段，整合融入全球控制系统的子系统开始。虽然控制回路的详细规格等，是现在子系统合同的一部分。客户必须明确多少信息子系统可以被使用。

大多数Turn Key系统与PLC一起交付使用。瑞士光源（SLS）的建立过程已显示，这也是基于I/ O系统运行的VME运行 CCS的，这样才可以成功启用[6]。

基于系统的PLC：

基于系统的PLC是Turn Key系统成果。下一个明显的方法看起来可能是除了商业PLC，就是商业SCADA系统。优势就是明显和PLC一样：没有稳定的软编程器，仅有配置，支持和良好的文件系统。在德国电子同步加速器研究所，我们成功地建立了控制组和公共事业组之间的关系。尽管是EPICS编码，但其最大的优势就是能调整双方的特殊要求。

一旦工业开始支持协作控制系统，CCS的解决方案和商业之间的差异将渐渐变小。在KEK，公司签订合同为KEK-B升级提供程序员。这些程序员进行了书面驱动程序和应用程序代码的EPICS培训。因此，KEK-B控制系统是工业用和民用升级软件的混合体。这是CCS实施中工业参与的另一个例子。

自从个人电脑出现后，“一台个人电脑的总成本是多少？”这样的问题一直使人忙碌。所有的答案不尽相同的极端。现在的问题什么是一个控制系统的TCO可能作出类似的结果。如果你进入商业领域，你要支付的初始证照费用，而通常这是由供应商或分包商支付的，你付钱进行的软件支持，可能或可能不会包括你更新证照的费用。

如果你去寻求合作方式，你可能与公司签合同或完成一切。而“时间与金钱说”在工业中同样成立。你亲自完成可能更自由灵活，但是有点难度。你 可以依靠合作，以提供新的功能和版本，或者你可以为自己作出贡献。主要的区别就是要为控制系统计入长期成本。

德国电子同步加速器研究所粗略估计，控制应用程序，如支持商业模式的D / 3，和支持协作模式的EPICS几乎是相同的。在该软件支持和升级证照的费用，相当于1.5倍的FTE’s 。FTE’s是关于人力资源的内容，对于支持新的硬件和升级EPICS是必要的。

根据控制项目不同的规模和要求，整合的商业解决方案和基于协作应用程序的解决方案在百分之零到一百都有可能。。这适用于长远的技术支持。在安全问题上的特殊需要或人力资源的缺乏可能会扩大商机。接口专业硬件，掌控在手的谈判或商业解决方案的初始成本有可能促使大规模的合作。只要如EPICS的协作途径，保持最新并运行如商业方案一样稳定和强劲，它们就能在互补共生的控制世界中占有一席之地。

 

 

 

 INDUSTRIAL AND COLLABORATIVE CONTROL SYSTEMS

- A COMPLEMENTARY SYMBIOSIS –

 

-     Looking at today’s control system one can find a wide variety of implementations. From pure industrial to collaborative control system (CCS) tool kits to home grown systems and any variation in-between. Decisions on the type of implementation should be driven by technical arguments Reality shows that financial and sociological reasons form the complete picture. Any decision has it’s advantages and it’s drawbacks. Reliability, good documentation and support are arguments for industrial controls. Financial arguments drive decisions towards collaborative tools. Keeping the hands on the source code and being able to solve problems on your own and faster than industry are the argument for home grown solutions or open source solutions. The experience of many years of operations shows that which solution is the primary one does not matter, there are always areas where at least part of the other implementations exist. As a result heterogeneous systems have to be maintained. The support for different protocols is essential. This paper describes our experience with industrial control systems, PLC controlled turn key systems, the CCS tool kit EPICS and the operability between all of them.

 

-  INTRODUCTION

 

 Process controls in general started at DESY in the early 80^th with the installation of the cryogenic control system for the accelerator HERA (Hadron-Elektron-Ring-Anlage). A new technology was necessary because the existing hardware was not capable to handle standard process controls signals like 4 to 20mA input and output signals and the software was not designed to run PID control loops at a stable repetition rate of 0.1 seconds. In addition sequence programs were necessary to implement startup and shutdown procedures for the complex cryogenic processes like cold boxes and compete compressor streets.

Soon it was necessary to add interfaces to field buses and to add computing power to cryogenic controls. Since the installed D/3 system[1] only provided an documented serial connection on a multibus board, the decision was made to implement a DMA connection to VME and to emulate the multibus board’s functionality. The necessary computing power for temperature conversions came from a Motorola MVME 167 CPU and the field bus adapter to the in house SEDAC field bus was running on an additional MVME 162. The operating system was VxWorks and the application was the EPICS toolkit.

Since this implementation was successful it was also implemented for the utility controls which were looking for a generic solution to supervise their distributed PLC’s.

 

 A SELECTION OF PROCESS CONTROL SYSTEMS AT DESY

 

 DCS (D/3)

As a result of a market survey the D/3 system from GSE was selected for the HERA cryogenic plant. The decision was fortunate because of the DCS character of the D/3. The possibility to expand the system on the display- and on the I/O side helped to solve the increasing control demands for HERA. The limiting factor for the size of the system is not the total number of I/O but the traffic on the communication network. This traffic is determined by the total amount of archived data not by the data configured in the alarm system. The technical background of this limitation is the fact that archived data are polled from the display servers whereas the alarms are pushed to configured destinations like alarm-files, (printer) queues or displays.

SCADA Systems with DCS Features (Cube)

The fact that the D/3 system mentioned above had some hard coded limitations with respect to the Y2K problem was forcing us to look for an upgrade or a replacement of the existing system. As a result of a call for tender the company Orsi with their product Cube came into play [2]. The project included a complete replacement of the installed functionality. This included the D/3 as well as the integration of the DESY field bus SEDAC and the temperature conversion in VME. The project started promising. But soon technical and organizational problems were pushing the schedule to it’s limits which were determined by the HERA shutdown scheduled at that time. The final acceptance test at the vendors site showed dramatic performance problems. Two factors could be identified as the cause of these problems. The first one was related to the under estimated CPU load of the 6^th grade polynomial temperature conversion running at 1 Hz. The second one was the additional CPU load caused by the complex functionality of the existing D/3 system. Here it was underestimated that each digital and analog input and output channel had it’s own alarm limits in the D/3 system. In a SCADA like system as Cube the base functionality of a channel is to read the value and make it available to the system. Any additional functionality must be added. Last not least the load on the network for polling all the alarm limits – typically for a SCADA system – was also driving the network to it’s limits.

Finally the contract with Orsi was cancelled and an upgrade of the D/3 system was the only possible solution. It was finally carried out in march 2003.

In any case it should be mentioned that the Cube approach had the advantage of a homogeneous configuration environment (for the Cube front end controllers) – compared with heterogeneous environments for ‘pure’ SCADA systems.

SCADA (PVSS-II)

The H1 experiment at the HERA accelerator decided to use PVSS-II for an upgrade of their slow control systems[3]. The existing systems were developed by several members of the H1 collaboration and were difficult to maintain. The decision to use PVSS as a replacement was driven by the results of an extensive survey carried out at CERN by the Joint Controls Project [4]. PVSS is a ‘pure’ Supervisory And Data Acquisition System (SCADA). It provides a set of drivers for several field buses and generic socket libraries to implement communication over TCP/IP. The core element is the so called event manager. It collects the data (mostly by polling) from the I/O devices and provides an event service to the attached management services like: control manager, database manager, user interface, API manager and the built in HTTP server. The PVSS scripting library allows to implement complex sequences as well as complex graphics. Compared with other SCADA systems PVSS comes with one basic feature: it provides a true object oriented API to the device’s data.

One major disadvantage of SCADA systems is the fact that two databases, the one for the PLC and the one for the SCADA system must be maintained. Integrated environments try to overcome this restriction.

EPICS

EPICS has emerged at DESY from a problem solver to a fully integrated control system. Starting from the data collector and number cruncher for the cryogenic control system, EPICS made it’s way to become the core application for the DESY utility group. In addition it is used wherever data is available through VME boards or by means of Industry Pack (IP) modules. For those cryogenic systems which are not controlled by the D/3 system EPICS is used with it’s complete functionality. In total about 50 Input Output Controller (IOC) are operational processing about 25 thousand records.

1 EPICS as a SCADA System

The utility group ( water, electrical power, compressed air, heating and air conditioning) is using a variety of PLC’s spread out over the whole DESY site. EPICS is used to collect the data from these PLC’s over Profibus (FMS and DP) and over Ethernet (Siemens H1 and TCP). The IOC’s provide the interfaces to the buses and collect the data. The built in alarm checking of the EPICS records is used to store and forward alarm states to the alarm handler (alh) of the EPICS toolkit. In addition tools like the channel archiver and the graphic display (dm2k) are used. The default name resolution (by UDP broadcast) and the directory server (name server) are used to connect

client and server applications over TCP. All of these are basically SCADA functions.

The textual representation of all configuration files ( for the IOC, the graphic tool, the alarm handler and the archiver) provides a flexible configuration scheme. At DESY the utility group has developed a set of tools to create IOC databases and alarm configuration files from Oracle. This way the controls group provides the service to maintain the EPICS tools and the IOC’s while the users can concentrate on the equipment being controlled.

2 EPICS as a DCS System

Besides the basic components of a SCADA system EPICS also provides a full flavoured Input Output Controller (IOC). The IOC provides all of the function a DCS system requires, such as: a standard set of properties implemented in each record, built in alarm checking processed during the execution of each record; control records like PID etc.; configuration tools for the processing engine. The flexible naming scheme and the default display and alarm properties for each record ease the connection between the operator tools and the IOC’s. The flexible data acquisition supports the poll mode as well as the publish subscribe mode. The latter reduces the traffic drastically.

PLC’s

PLC’s provide nowadays the same rich functionality as it was known from stand alone control systems in the past. Besides the basic features like the periodic execution of a defined set of functions they also allow extensive communication over Ethernet including embedded http servers and different sets of communication programs. Besides the communication processors, display processors can be linked to PLC’s to provide local displays which can be comprised as touch panels for operator intervention and value settings.

These kind of PLC’s are attractive for turn key systems which are commissioned at the vendors site and later integrated into the customers control system.

Intelligent I/O

New developments in I/O devices allow to ‘cluster’ I/O in even smaller groups and connect theses clustered I/O channels directly to the control system. PLC’s are not any more necessary for distributed I/O. Simple communication processors for any kind of field buses or for Ethernet allow an easy integration into the existing controls infrastructure. Little local engines can run IEC 61131 programs. The differences between PLC’s and intelligent I/O subsystems fade away.

The ever lasting question why control systems for accelerators and other highly specialized equipment are often home grown or at least developed in a collaboration but only in rare cases commercial shall not be answered here. We try to summarize here basic functionalities of different controls approaches.

Front-end Controller

One of the core elements of a control system is the front-end controller. PLC’s can be used to implement most of the functions to control the equipment. The disadvantage is the complicated access to the controls properties. For instance all of the properties of a control loop like the P, I and D parameter, but also the alarm limits and other additional properties must be addressed individually in order to identify them in the communication protocol and last not least in the display-, alarm- and archive programs. In addition any kind of modifications of these embedded properties is difficult to track because two or more systems are involved. This might be one strong argument why control loops are mainly implemented on the IOC level rather than PLC’s.

1 I/O and Control Loops

Complex control algorithms and control loops are the domain of DCS alike control systems. The support for sets of predefined display and controls properties is essential. If not already available (like in DCS systems) such sets of generic properties are typically specified throughout a complete control system (see namespaces).

2 Sequence/ State programs

Sequence programs can run on any processor in a control system. The runtime environment depends on the relevance of the code for the control system. Programs fulfilling watchdog functions have to run on the front-end processor directly. Sequence programs for complicated startup and shutdown procedures could be run on a workstation as well. The basic functionality of a state machine can be even implemented in IEC 61131. Code generators can produce ‘C’ code which can be compiled for the runtime environment.

3 Supported Hardware

The support for field buses and Ethernet based I/O is a basic functionality for SCADA type systems it is commercially available from any SCADA system on the market. The integration of specific hardware with specific drivers and data conversion is the hard part in a commercial environment. Open API’s or scripting support sometimes help to integrate custom hardware. If these tools are not provided for the control system it is difficult – if not impossible - to integrate custom hardware.

New industrial standards like OPC allow the communication with OPC aware devices and the communication between control systems. One boundary condition for this kind of functionality is the underlying operating system. In the case of OPC it is bound to DCOM which is a Microsoft standard. UNIX based control systems have a hard time to get connected. Only control systems supporting multiple platforms can play a major role in a heterogeneous environments.

As a result the limited support for custom- or specialized hardware may give reason for the development of a new control system.

Display and Operation

Besides the front-end system the operator interfaces play a major role for the acceptance of a control system. SCADA tools come with a homogeneous look and feel throughout their set of tools. Toolkits implemented in a collaboration might vary because the individual tools were developed by different teams.

1 Graphic

Synoptic displays are the advertising sign for any control system. Commercial synoptic displays come with a rich functionality and lots of special features. Starting to make use of all these features one will find out that all individual properties of the graphic objects must be specified individually. Since SCADA systems must be generic they cannot foresee that an input channel does not only consist of a value but also consists of properties like display ranges and alarm values. Defining all of these properties again and again can be a pretty boring job. Some systems allow to generate prototypes of graphic objects. These prototype or template graphics are complex and need a specialist to generate them.

DCS or custom synoptic display programs can make use of the common set of properties each I/O point provides. This predefined naming scheme will fill in all standard property values and thus only require to enter the record – or device name into the configuration tool. A clear advantage for control systems with a notion of I/O objects rather than I/O points.

2 Alarming

Alarms are good candidates to distinguish between different control system architectures. Those systems which have I/O object implemented also provide alarm checking on the front-end computer. Those systems which only know about I/O points have to add alarm checking into the I/O processing. While the I/O object approach allows to implement alarm checking in the native programming language of the front-end system, I/O point oriented systems typically have to implement this functionality in their native scripting language. This is typically less efficient and error prone because all properties must be individually configured. This leads to a flood of properties. Not only the error states for each I/O point wind up to be individual I/O points but also the alarm limits and the alarm severity of each limit must be defined as I/O points if it is desired to be able to change their values during runtime.

Besides this impact on the configuration side the processing and forwarding of alarms makes the difference between SCADA and DCS systems. Since SCADA systems inherently do not ‘know’ about alarms, each alarm state must be polled either directly from the client application or in advanced cases from an event manager which will forward alarm states to the clients. In any case a lot of overhead for ‘just’ checking alarm limits. DCS system again have the advantage that clients can either register themselves for alarm states und thus get the information forwarded or are configured to send alarmchanges to certain destinations spread around the control system. The latter case is only possible for systems which in total are configured with all the nodes taking part in the controls network.

3 Trending and Archiving

Trending has become an important business in control systems architectures. Trends are necessary to trace error conditions or for post mortem and performance analysis of the controlled plant. Besides some custom implementations which are capable to store the data of complete control objects, most of the trending tools archive scalar data. Additional features like conditional trending or correlation plots make up the difference between individual implementations.

4 Programming Interfaces

With respect to open programming interfaces PLC’s and DCS systems have a common strategy. They are running reliably because there’s no way to integrate custom code which could interfere with the internal processing. As a consequence the customer has to order ‘specials’ - which are extremely expensive – or forget about it and use the system as a black box.

Since SCADA systems by definition must be able to communicate with a variety of I/O subsystems they already have some built in API’s which allow to integrate custom functionality.

Specially collaborative systems need a certain openness to fulfill all the requirements from various development groups. Programming interfaces on all levels like font-end I/O, front-end processing, networking etc. are mandatory. A clear advantage for this type of system.

5 Redundancy

If redundancy means the seamless switch which takes over all the states and all the values of the I/O and all states of all programs currently running, it is a domain of only a few DCS systems. Custom or CCS implementation do not provide this kind of functionality. Maybe because of the immense effort and the fact that it is only required in rare cases.

Besides processor redundancy, redundant networks or I/O subsystems are available for certain commercial DCS systems. Again – a domain which is not covered by SCADA or CCS implementations.

Advanced safety requirements may be covered by redundant PLC subsystems. These are for instance installed in (nuclear) power plants. Requirements for Personal Protection Systems (PPS) can sometimes only be fulfilled by redundant PLC’s. In process controls redundant PLC’s are only used in rare cases.

6 Namespace

The flat namespace of SCADA systems has already been described in the alarm section. Some SCADA systems (like PVSS-II) provide the notion of control objects or structured data which is a rare case. In all other cases so called field objects must be specified. These are objects which consist of a list of properties (implemented as I/O points) and a set of methods ( implemented asmacros or function calls). One of these approaches is the UniNified Industrial COntrol System (UNICOS) at CERN [5].

DCS systems and most of the custom/ collaborative systems are record – or device oriented. The difference being that typically one record is connected to a single I/O point and provides this way all sub features of a record implementation like individual engineering units, display- and alarm limits. The device oriented approach allows to connect several I/O points. The major difference being the fact that an object oriented device implementation provides methods and states for a device while (EPICS) records only serve a certain set of built in functions.

Naming hierarchies are not specific to a type of implementation. They are available for some systems of any kind. For sure hierarchical naming schemes are desirable.

After having shown all the possible controls approaches it is time to have a look at the implementation of control systems.

Starting from the I/O level one has to decide whether commercial solution are required, feasible or wanted. Special I/O does not always require custom solution for the font-end controller. Signals can be converted into standard signals but this does not apply for all kinds of signals. Resolution, repetition rates and signal levels might require custom developments which must be integrated into the overall control architecture. Even if the signals can not be connected to standard I/O interfaces it might be possible to develop I/O controllers which implement a field bus interface which allow the integration with commercial control systems. Once this level of integration is not possible custom front-end controllers like VME crates come into play.

Besides the decision whether special I/O requires dedicated custom solutions one has to decide who will do which part of the work? Does for instance the necessity of VME crates prohibit the delivery of a ‘turn key’ system built by industry? Or does a PLC based front-end system require a commercial SCADA system for high level controls?

Turn Key Systems

It is a clear trend in industry to deliver turn key systems. It allows a modular design of the whole system. Individual components can be subcontracted to several companies and tested locally. Once delivered to the construction site the primary acceptance tests have already been passed and the second phase, to integrate the subsystem into the global control system begins.

While the detailed specification of control loops etc. is now part of the subsystems contract, the customer has to specify clearly how much information of the subsystem must be made available, what the data structures will look like and which connection (field bus/ Ethernet) will be used.

Most turn key systems are delivered with PLC’s. The construction of the Swiss Light Source (SLS) has shown that also a VME based I/O system running a CCS – in this case EPICS – can be successfully commissioned [6].

PLC Based Systems

PLC based systems are a consequence of the turn key ansatz. The next obvious approach might be to look besides commercial PLC’s also for commercial SCADA systems. The advantage is clearly the same like for the PLC: stable software, no programming – only configuration, support and good documentation. At DESY we have successfully established a relation between the controls group which provides a CCS service based on EPICS and the utility group which uses the EPICS configuration tools to set up their control environment. The big advantage though being that the EPICS code can be adjusted to the special requirements from both sides.

Industrial Solutions

The difference between CCS solutions and commercial solutions is fading away as soon as industry starts to deliver and support collaborative control systems. At KEK a company was contracted to supply programmers for the KEK-B upgrade. These programmers were trained in writing drivers and application code for EPICS. As a result the KEK-B control system is a mixture of software developed partly by industry and partly in house. This is another example for an industrial involvement for a CCS implementation.

The question: “Was is the total cost of ownership (TCO) of a PC?” has kept people busy since PC’s exist. The answers vary to all extremes. The question what is the TCO of a control system might give similar results.

If you go commercial you have to pay for the initial licenses the implementation which is typically carried out by the supplier or by a subcontractor, and you pay for the on going software support which might or might not include the update license fee.

If you go for a collaborative approach, you might contract a company or implement everything on your own. A question of ‘time and money’ as industry says. You will have more freedom and flexibility for your implementations but also a steeper learning curve. You can rely on the collaboration to provide new features and versions or you can contribute yourself. A major difference calculating the long term costs for a control system.

At DESY one can roughly estimate that the (controls application)-support for a commercial approach – here D/3 - and the -support for a collaborative approach – here EPICS - is nearly the same. The software support and upgrade license fee is equivalent to one and a half FTE’s – which is about the manpower necessary to support new hardware and to upgrade EPICS.

Depending on the size and the requirements for a controls project the combination of commercial solutions and solutions based on a collaborative approach is possible in any rate between 0 and 100 percent. This applies for all levels from implementation to long term support. Special requirements on safety issues or a lack of manpower might turn the scale commercial. The necessity to interface special hardware, special timing requirements, the ‘having the code in my hands’ argument or the initial costs for commercial solutions will turn the scale collaborative. As long as collaborative approaches like EPICS stay up to date and run as stable and robust as commercial solutions, both will keep their position in the controls world in a complementary symbiosis.