【正文】 s 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 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 mercial control systems. Once this level of integration is not possible custom frontend controllers like VME crates e 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 frontend system require a mercial 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 ponents can be subcontracted to several panies 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/ Ether) 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 missioned [6]. PLC Based Systems PLC based systems are a consequence of the turn key ansatz. The next obvious approach might be to look besides mercial PLC?s also for mercial 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 mercial solutions is fading away as soon as industry starts to deliver and support collaborative control systems. At KEK a pany was contracted to supply programmers for the KEKB upgrade. These programmers were trained in writing drivers and application code for EPICS. As a result the KEKB 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. COST 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 mercial 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 pany 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 mercial 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?