plc外文文獻(xiàn)翻譯---工業(yè)控制系統(tǒng)和協(xié)同控制系統(tǒng)

1、<p>　　INDUSTRIAL AND COLLABORATIVE CONTROL SYSTEMS </p><p>　　A COMPLEMENTARY SYMBIOSIS –</p><p>　　Looking at today’s control system one can find a wide variety of implementations. From pure

2、 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

3、 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. </p><p>　　INTRODUC

4、TION</p><p>　　Process controls in general started at DESY in the early 80th with the installation of the cryogenic control system for the accelerator HERA (Hadron-Elektron-Ring-Anlage). A new technology was

5、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 repetitio

6、n rate of 0.1 seconds. In addition sequence programs were necessary to implement startu</p><p>　　Soon it was necessary to add interfaces to field buses and to add computing power to cryogenic controls. Since

7、 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

8、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 </p><p>　　Since this implementation w

9、as successful it was also implemented for the utility controls which were looking for a generic solution to supervise their distributed PLC’s.</p><p>　　A SELECTION OF PROCESS CONTROL SYSTEMS AT DESY</p>

10、;<p>　　DCS (D/3) </p><p>　　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 pos

11、sibility 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

12、the communication network. This traffic is determined by the total amount of archived data not by the data </p><p>　　SCADA Systems with DCS Features (Cube) </p><p>　　The fact that the D/3 system

13、 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

14、 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

15、 VME. The project started promis</p><p>　　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.</p>&l

16、t;p>　　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’ S

17、CADA systems.</p><p>　　SCADA (PVSS-II)</p><p>　　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 develo

18、ped 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

19、[4]. PVSS is a ‘pure’ Supervisory And Data Acquisition System (SCADA). It provides a set of drivers for several field buses and generi</p><p>　　One major disadvantage of SCADA systems is the fact that two da

20、tabases, the one for the PLC and the one for the SCADA system must be maintained. Integrated environments try to overcome this restriction. </p><p><b>　　EPICS </b></p><p>　　EPICS has

21、 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 t

22、he 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

23、with it’s complete functionality. In total about 50</p><p>　　1 EPICS as a SCADA System </p><p>　　The utility group ( water, electrical power, compressed air, heating and air conditioning) is usi

24、ng 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 bus

25、es 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 </p><p>　　client and ser

26、ver applications over TCP. All of these are basically SCADA functions. </p><p>　　The textual representation of all configuration files ( for the IOC, the graphic tool, the alarm handler and the archiver) pro

27、vides 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 maintai

28、n the EPICS tools and the IOC’s while the users can concentrate on the equipment being controlled. </p><p>　　2 EPICS as a DCS System </p><p>　　Besides the basic components of a SCADA system EPIC

29、S 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 proces

30、sed 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 conn

31、ection be</p><p><b>　　PLC’s </b></p><p>　　PLC’s provide nowadays the same rich functionality as it was known from stand alone control systems in the past. Besides the basic features

32、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 proc

33、essors, display processors can be linked to PLC’s to provide local displays which can be comprised as touch panels for operator intervention</p><p>　　These kind of PLC’s are attractive for turn key systems w

34、hich are commissioned at the vendors site and later integrated into the customers control system. </p><p>　　Intelligent I/O </p><p>　　New developments in I/O devices allow to ‘cluster’ I/O in ev

35、en 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 Etherne

36、t 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. </p><p>　　FUNCT

37、IONALITY </p><p>　　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 c

38、ommercial shall not be answered here. We try to summarize here basic functionalities of different controls approaches.</p><p>　　Front-end Controller </p><p>　　One of the core elements of a contr

39、ol 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 propert

40、ies 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

41、the display-, alarm- and </p><p>　　1 I/O and Control Loops </p><p>　　Complex control algorithms and control loops are the domain of DCS alike control systems. The support for sets of predefined

42、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). </p><

43、p>　　2 Sequence/ State programs </p><p>　　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 fulfi

44、lling 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 machin

45、e can be even implemented in IEC 61131. Code generators can produce ‘C’ code which can be compiled for the runtime en</p><p>　　3 Supported Hardware </p><p>　　The support for field buses and Ethe

46、rnet 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

47、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 cus

48、tom hardware. </p><p>　　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 i

49、s 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 ca

50、n play a major role in a heterogeneous environments. </p><p>　　As a result the limited support for custom- or specialized hardware may give reason for the development of a new control system.</p><

51、p>　　Display and Operation </p><p>　　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 through

52、out their set of tools. Toolkits implemented in a collaboration might vary because the individual tools were developed by different teams. </p><p>　　1 Graphic </p><p>　　Synoptic displays are the

53、 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 propert

54、ies 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 range

55、s and alarm values. Defining all of</p><p>　　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 stand

56、ard 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.</p><p>　

57、　2 Alarming </p><p>　　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 co

58、mputer. 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-

59、end system, I/O point oriented systems typically have to implement this functionality in their </p><p>　　Besides this impact on the configuration side the processing and forwarding of alarms makes the differ

60、ence 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

61、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 the</p><p>　　3 Trending and Arch

62、iving </p><p>　　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.

63、 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 mak

64、e up the difference between individual implementations. </p><p>　　4 Programming Interfaces </p><p>　　With respect to open programming interfaces PLC’s and DCS systems have a common strategy. The

65、y 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

66、 about it and use the system as a black box. </p><p>　　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 inte

67、grate custom functionality. </p><p>　　Specially collaborative systems need a certain openness to fulfill all the requirements from various development groups. Programming interfaces on all levels like font-e

68、nd I/O, front-end processing, networking etc. are mandatory. A clear advantage for this type of system. </p><p>　　5 Redundancy </p><p>　　If redundancy means the seamless switch which takes over

69、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 becau

70、se of the immense effort and the fact that it is only required in rare cases. </p><p>　　Besides processor redundancy, redundant networks or I/O subsystems are available for certain commercial DCS systems. Ag

71、ain – a domain which is not covered by SCADA or CCS implementations. </p><p>　　Advanced safety requirements may be covered by redundant PLC subsystems. These are for instance installed in (nuclear) power pla

72、nts. 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. </p><p>　　6 Namespace </p>

73、<p>　　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 othe

74、r 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 approach

75、es is the UniNified Industrial COntrol System (UNICOS) at CERN [5]. </p><p>　　DCS systems and most of the custom/ collaborative systems are record – or device oriented. The difference being that typically on

76、e 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 s

77、everal I/O points. The major difference being the fact that an object oriented device implementation provides methods and states for a device while (EP</p><p>　　Naming hierarchies are not specific to a type

78、of implementation. They are available for some systems of any kind. For sure hierarchical naming schemes are desirable. </p><p>　　IMPLEMENTATION STRATEGIES </p><p>　　After having shown all the p

79、ossible controls approaches it is time to have a look at the implementation of control systems. </p><p>　　Starting from the I/O level one has to decide whether commercial solution are required, feasible or w

80、anted. 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 si

81、gnal 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 i</p><p>　　Besides the decisi

82、on 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 industr

83、y? Or does a PLC based front-end system require a commercial SCADA system for high level controls? </p><p>　　Turn Key Systems </p><p>　　It is a clear trend in industry to deliver turn key system

84、s. 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 bee

85、n passed and the second phase, to integrate the subsystem into the global control system begins. </p><p>　　While the detailed specification of control loops etc. is now part of the subsystems contract, the c

86、ustomer 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. </p><p>　　Most tu

87、rn 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]. </p>

88、<p>　　PLC Based Systems </p><p>　　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 a

89、dvantage 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 pr

90、ovides a CCS service based on EPICS and the utility group which uses the EPICS configuration tools to set up the</p><p>　　Industrial Solutions </p><p>　　The difference between CCS solutions and

91、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 tra

92、ined 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 involvemen

93、t for a CCS impleme</p><p><b>　　COST </b></p><p>　　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 ex

94、tremes. The question what is the TCO of a control system might give similar results. </p><p>　　If you go commercial you have to pay for the initial licenses the implementation which is typically carried out

95、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. </p><p>　　If you go for a collaborative approach, you might contr

96、act 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 t

97、he collaboration to provide new features and versions or you can contribute yourself. A major difference calculating the long term costs for a control system. </p><p>　　At DESY one can roughly estimate that

98、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