【正文】 s – which is about the manpower necessary to support new hardware and to upgrade EPICS. CONCLUSIONS Depending on the size and the requirements for a controls project the bination of mercial 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 mercial. The necessity to interface special hardware, special timing requirements, the ?having the code in my hands? argument or the initial costs for mercial solutions will turn the scale collaborative. As long as collaborative approaches like EPICS stay up to date and run as stable and robust as mercial solutions, both will keep their position in the controls world in a plementary symbiosis. 外文翻譯譯文 工業(yè)控制系統(tǒng)和協(xié)同控制系統(tǒng) 當今的控制系統(tǒng)被廣泛運用于許多領域。 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 inbetween. Decisions on the type of implementation should be driven by technical arguments Reality shows that financial and sociological reasons form the plete 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 80th with the installation of the cryogenic control system for the accelerator HERA (HadronElektronRingAnlage). 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 seconds. In addition sequence programs were necessary to implement startup and shutdown procedures for the plex cryogenic processes like cold boxes and pete pressor streets. Soon it was necessary to add interfaces to field buses and to add puting 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 puting 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 munication work. 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 alarmfiles, (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 pany Orsi with their product Cube came into play [2]. The project included a plete 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 anizational 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 6th grade polynomial temperature conversion running at 1 Hz. The second one was the additional CPU load caused by the plex 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 work for polling all the alarm limits – typical