【正文】
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 frontend puter. 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 frontend 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 work. 3 Trending and Archiving Trending has bee 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 plete 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 mon 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 fet about it and use the system as a black box. Since SCADA systems by definition must be able to municate 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 fontend I/O, frontend processing, working 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 works or I/O subsystems are available for certain mercial 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 PVSSII) 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. IMPLEMENTATION STRATEGIES 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 mercial solution are required, feasible or wanted. Special I/O does not always require custom solution for the fontend 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