Process control system 1 Task and objective 1.1 Plant specification 1.1.1 Operator terminals 1.1.2 Scope of information 1.1.3 Process displays 2 Requirements placed on control system 2.1 Basic system requirements and properties 2.2 Uniform, window-based GUI 2.3 Facility for uniform online parameterization 2.4 Object-oriented data model 2.5 Protection against unauthorized access 2.6 Openness and integration capability 2.6.1 Open interfaces for standard software 2.6.2 Open interfaces for user software 2.7 System response in event of faults 3 System and plant concept 3.1 Plant configuration 3.2 Central computer 3.3 Operator terminals 3.4 Printers 3.5 Local area network (LAN) 4 Software components of the control system 4.1 Operating system 4.2 Database system 4.3 Graphics system 4.4 Processing of basic data 4.4.1 Message processing 4.4.2 Processing of measured values 4.4.3 Commands/setpoints 4.5 Process operation and visualization 4.5.1 Process displays 4.5.2 Curve displays 4.5.3 Message logging/evaluation/acknowledgment 4.6 Report system 4.7 Archiving system 4.7.1 Short-term archive 4.7.2 Long-term archive 4.8 Development response specification 4.9 Display generation 4.10 Documentation 5. Sector-specific modules for expansion of control system 5.1 Archiving and reporting in conformance with ATV 5.1.1 Fundamental system requirements and properties 5.1.2 Measured values and their processing 5.1.3 Processing of counted values 5.1.4 Laboratory values 5.1.5 Derived data (calculated values) 5.1.6 Curve displays 5.1.7 Reports 5.1.8 Saving of archived data on external media 5.2 Alarm output using radio call 5.3 Maintenance management 5.4 Direct interfacing of telecontrol stations to the host computer 5.5 External operator terminal via the Internet 5.6 Optimization of plant management for drinking water networks and district water supplies 6. Quantity breakdown and performance 1. Task and objective Within the project, a host process control system is to be installed in the plant. The installation of the process control system also includes the interfacing of various automation systems (PLCs). The host control system must provide the following functions: - Central monitoring of the plant systems by recording, processing and displaying all defined process variables such as measured values, process signals and fault signals. - Saving of data in long-term archives for subsequent evaluation in the form of reports and graphics. - Generation of calculated values using arithmetic or logic operations on process data. - Display of the plant and process systems on dynamic flowcharts as color graphics with display of all required data in analog and/or digital form. - Display of measured data in the form of curves and tables. - Online parameterization of the system using convenient interactive screen forms and menus with corresponding Help function. - Logging of all data and statuses, production of ATV reports for documentation of operating process, with calculations specific to the sewage treatment plant. 1.1 Plant specification 1.1.1 Operator terminals The following configuration must be provided for use of the control system: Quantity Description/location Required functions ------- Central computer (server) System configuring Data archiving Data exporting Data importing Process visualization Process operation Report output ------- Operator terminal (client) Process visualization Process operation Input of laboratory data Output of fault signals ------- Operator terminal (Web client) Process visualization Process operation Output of fault signals ------- Display and diagnostics terminal (office PC) Process and data display Analysis 1.1.2 Scope of information The expected scope of information to be transmitted between the control system and the PLC level is summarized in the following tables. The tables list the minimum requirements placed on the control system for the scope of information to be transmitted and processed. Scope of information: Quantity Type PLCs to be coupled Binary signals Measured values Commands Setpoints Counted values Laboratory data Calculated values Data volumes 25% should be additionally planned as reserve. 1.1.3 Process displays Quantity Type of display Plant display Curve display Setpoint display Tables/statistics 2 Requirements placed on control system 2.1 Basic system requirements and properties The design and functionality of the process control system must correspond to the current state-of-the-art for process information and operating systems, and possess future-oriented hardware and software. The control system should be a modern system with attractive graphical user interface, open for the office and process worlds, possess proven and reliable functions, permit efficient configuration, and be scaleable for simple and complex tasks. It must additionally be available for worldwide use and supported worldwide. Commercially available PCs are to be used as operator and server stations. Office PCs or industrial PCs can be used which execute on Microsoft Windows 2000 or Windows XP. The control system thus profits from the innovations and cost savings in the PC sector. The control system software must be offered as a complete package or runtime package. If the project increases in size, cost-neutral upgrading of the number of variables must be possible, i.e. the price-optimized starter solution with subsequent upgrading should be only slightly more expensive than if the larger solution were implemented immediately. The communications channels for interfacing to the SIMATIC S7 controllers via various communications media must be included in the scope of delivery of the control system as well as, for example, the drivers for simple types of coupling such as point-to-point via the MPI interface. Furthermore, coupling should be possible via the standardized OPC software interface to other devices and applications from different vendors. In addition to the basic packages, it must be possible to expand the system using the option packages referred to below. These must be integrated in the GUI, i.e. switching between various applications using standard inputs such as Alt-Tab or Strg-Esc is not permissible for safety reasons. - Server Multi-user systems operate according to the client/server principle. The server stations are executed on the basis of the Windows 2000 Server and use its security- oriented operating system mechanisms. Servers handle central tasks such as process coupling and archiving for the stations in the multi-user system. Client stations executing on the basis of Windows 2000 or Windows XP utilize the server's performance. They communicate with the server via a separate terminal bus which simultaneously permits interfacing to the office level. The standard TCP/IP protocols are used for communication between the operator terminals. A corresponding PC LAN is used as the network. Since clients automatically "search" for the server defined in their project, they can also be subsequently connected without any feedback problems. With up to 4 clients, the server can be operated if required with an operator terminal, above this number it exclusively handles server functions. It must be possible to connect max. 32 clients. The Windows 2000 Server is defined as the platform for the control system server. All configuration and process data are located centrally in a project directory on one drive (typically on the server) so that access and modifications are basically possible from all stations (online configuring). However, the client can also possess local displays and process local actions, thus accelerating image selection and specifically reducing the load on the server. Modified project states can be activated in online mode without interrupting process operation. - Redundancy The redundancy option should permit operation of two control system computers in parallel. Data integrity is to be guaranteed using automatic alignment of archives. In addition, the redundancy concept is a guarantee for process control and operation since the clients are automatically switched to the active server should a server fail. In this manner, all clients permanently remain available for process monitoring and operation. Both servers should carry out the archiving in parallel. This guarantees data integrity without gaps. If a failed partner is restored, all process values and messages during the down period are automatically aligned with the partner server. Thus two equal servers are available again. Alignment of the archives for the down period is carried out in the background without influencing the current application. If faults occur in additional applications which are being executed on the redundant servers, switching over of the redundancy must be activated automatically. The control system should possess the following system features: - Basic PC and standard operating system - Executes on all standard PCs with Pentium processor - 100% 32-bit software designed for the standard Microsoft Windows operating system - Central computer (server): Windows 2000 Server - Operator terminals (client): Windows 2000 or Windows XP - Direct use possible for hardware and software offered for the PC sector (e.g. LAN cards) - Can be used as single-user or multi-user system with client/server structure - Scaleable performance through selection of corresponding hardware platforms (for example using multi-processor systems with Windows 2000) - Operation and monitoring modules - Graphics system for free design of visualization and operation using pixel graphics objects (Windows, OLE, OCX, ActiveX objects), with the facility for dynamic response for all properties and with online configuration. A block library provides support when creating the displays. - Message system for recording and archiving events with display and operation facilities based on DIN 19235; freely-selectable message classes, message display and logging, freely-selectable online sorting. - Process data archiving for recording, archiving and compression of measured values, e.g. for displaying as curves and tables and for further processing operations, central data archiving on an archive server - Report and logging system for time-driven or event-driven documentation of messages, operator inputs, archive contents and current data as user reports (process data) or project documentation (documentation updating for configuration data) in a flexible, freely-selectable layout. - Processing functions for configuration of actions for objects, and the formulation and processing of scripts with Visual-Basic or ANSI-C. - Standard interfaces from the 32-bit Windows world are an integral part of the control system; standard Microsoft SQL Server 2000 database for configuration and process data with access facilities using ODBC or OLE-DB. - Programming interfaces (API) exist for all application modules of the control system, and offer access facilities to data and functions. A function library permits programming of stand-alone applications with which the basic functionality can be expanded. - Open interfaces - Access to configuration data (lists) and archived process data via standard database interface (ODBC/SQL), C-API or OLE-DB - Linking of Windows application blocks (ActiveX controls) - Data exchange with other Windows programs via the OPC interface - Expandable configuration wizards by means of application wizards and Visual Basic for Applications - API programming interface with access to control system functions - Connection to SIMATIC S5, S7, 505, SINAUT ST7 and PLCs from other vendors (e.g. using the cross-vendor Profibus or OPC) 2.2 Uniform, window-based GUI The process can be controlled and optimized in a transparent manner using individually configurable graphical user interfaces (GUI) for the control system. Functions are available which guarantee efficient and safe process operation. The design of the GUI should provide a flexible and function-oriented display of the process dialog. To achieve better charity, it is possible, for example, to provide a division into overview, working and key areas. This ergonomic and process-oriented division of the process screen, as well as structuring of the process displays in hierarchies, is automatically generated by wizards. Displays which have already been configured can be transferred object-oriented to the envisaged position in the hierarchy tree using the mouse. All area and detail displays can also be directly selected using global key combinations. It should be possible to use other applications by configuring appropriate OLE containers. In addition to this, it must be possible to access OCX/ActiveX objects. The functionality of other programs can thus be homogeneously integrated into the GUI of the control system. Overlapping by other displays must be inhibited, i.e. displays are output or suppressed (decluttering) depending on their size or the configured display level. This guarantees that an operator immediately recognizes important feedbacks from the process, for example in output boxes or message displays, and can react immediately and appropriately. Process displays can be zoomed by the mouse during runtime, and display sections can be panned using the mouse wheel. The control system should use the following input systems known from the Windows world: Keyboard, mouse or touch screen. If the standard cursor is positioned above accessible objects, it must change its representation (I/O box: mouse pointer plus cursor symbol; object accessible by mouse: mouse pointer plus arrow). The additional object is freely-selectable. The control system should be able to record operations on variables. The date, time, user name, old and new values should also be recorded. Operations in critical process situations can then be traced back and understood. It should be possible to extend the display and operation functions by project-specific actions. The control system can then exactly guide the operator towards elimination of the cause in critical situations, thus avoiding down times (automatic operator prompting). Selection of an alarm by the operator automatically leads to the display with the fault. 2.3 Facility for uniform online parameterization It is taken for granted that a comprehensive parameterization system is integrated with which the user can adapt the scope of functions and the functionality to changing requirements without programming knowledge. The system must offer the possibility for carrying out these parameter settings online. In practice, this means that the respective editor can run in a second window during operation, and that the planning engineer can specifically carry out modifications to his application without having to leave process operation and without influencing the background activities. Furthermore, it should be possible to carry out modifications to the configuration on a client. 2.4 Object-oriented data model A significant advantage of object orientation is that the real world (the technological process) can be modelled extremely closely to the DP world. 2.5 Protection against unauthorized access Protection must be provided against unauthorized operator access to the process, archives and control system. Such operations include modifications to setpoints, selection of displays, or calling of the configuration software during process operation. There are different access levels which permit establishment of hierarchical access protection as well as exclusive input privileges for individual operators. The password and user name define the access privileges of an operator. These can also be redefined during process operation. Convenient user administration functions are available for this. The validity is cancelled after a particular period during which no operations have been made. The control system thus guarantees that only authorized operators can carry out critical interventions and that the process is executed safely. 2.6 Openness and integration capability 2.6.1 Open interfaces for standard software Incorporation of standard Windows applications such as MS Excel, MS Word, MS Access must be possible using the standard OLE/ActiveX and ODBC/SQL mechanisms. It must be possible for any user programs (e.g. individual data management, analysis, process optimization) to work together with the control system via the integral C programming interface, using both control system data and functions. To permit cross-vendor communication, the control system must have OPC capabilities to make current process data available to other computers and applications. Any computers connected to the network then have access to all control system data. A standard database (e.g. Microsoft SQL Server 2000) must be used in order to save (secure transaction) all list-oriented configuration data such as lists of variables and message texts, but also current process data such as messages, measured values and user data sets in order to be able to access the database via the open C-API or OLE-DB programming interfaces. Incorporation of the standard Visual Basic for Applications tool should permit automation of working steps during the engineering phase and individual expansion of the configuration environment (generation of mass data is simplified). 2.6.2 Open interfaces for user software It is extremely decisive that the control system offers facilities for homogeneously integrating other applications and application blocks into the GUI for process operation. Both application windows and OLE custom controls (32-bit OCX objects) or ActiveX controls can be integrated into the control system application as if they were own objects of the control system. It should be possible to use the ANSI-C script language and Visual Basic scripting for dynamic operations on graphic objects. 2.7 System response in event of faults Once a fault has been eliminated (e.g. restart of a PC), running-up must be carried out automatically such that operation of the complete system is resumed without operator interventions being necessary. The process image must be updated at the same time; gaps in data recording must be identified. 3 System and plant concept 3.1 Plant configuration The required plant configuration is shown in the "Control system configurator". Recording, processing and management of process data should be carried out on a central host computer (server). Several operator terminals, each with a monitor, must be provided in the control room for the operation and monitoring functions. It should be possible to execute the complete functionality on each operator terminal. An LAN (Ethernet, IEEE 802. 3) must be provided. 3.2 Central computer (server) The server has the following main functions: - Communication with the programmable controllers - Processing of process data - Management of the databases (these contain the complete parameter settings for the system as well as the long-term archive). - Saving/archiving and restoring of data - Editing station functions - Time synchronization for all computers connected to the network by means of a central time service (DCF77 or GPS). The server must correspond to the requirements of process operation (time response, multitasking, failure response). A state-of-the-art Pentium PC must be offered. The PC must be selected such that expansion of the main memory and hard disk is possible up to twice the required values. The computing performance must be dimensioned such that the loading is max. 60% during normal operation. 3.3 Operator terminals (clients) These computers must be primarily provided for tasks such as: Selection of process displays Process operations Operation of information functions and reports. Each operator terminal comprises a visualization computer with high-resolution graphics screen. The screen diagonal must be at least 19 inches, and the resolution at least 1280 * 1024 pixels. Selected process displays must be continuously updated, independent of the screen on which they are output. A keyboard and mouse belong to each monitor. The keyboard is primarily used for manual input of measured values and parameters. Process operations (triggering of commands, input of setpoints, display selection, message acknowledgment etc.) are mainly carried out using the mouse. 3.4 Printers The printers in the control room are usually used for plant management. One of the printers must be offered as a color printer for producing hard copies of the color graphics monitors. The second printer logs process and archive data such as actual values, alarms or measured values. 3.5 Local area network (LAN) The PLC level is coupled to the host computer via an LAN. Coupling between all computers involved in the control system should be carried out according to IEEE 802.3 (Ethernet). TCP/IP protocols should be used here. 4 Software components of the control system 4.1 Operating system The following operating systems are defined for the complete local network (control system): - Central computer (server): Windows 2000 Server - Operator terminals (client) : Windows 2000 or XP 4.2 Database system The Microsoft SQL Server 2000 database system must be provided for management of the archives and system parameters. In addition to the required database performance, the licenses offered must include the facility for modification or new generation of applications by the client. The selected database system as well as the tools required by the contractor in the context of the database application must be listed in the quotation. 4.3 Graphics system The control system's graphics system should process all inputs and outputs on the screen during process operation. The images for visualization and operation of a plant consist of both simple and complex graphics objects. These are integrated into the images during the configuration phase using the graphics editor integrated in the control system. A number of objects should be provided for design and use of an attractive GUI: Static objects such as - Lines, connections (linear elements) - Polygon, polygon-based interpolation - Circle, segment, arc - Ellipse, ellipse segment, ellipse arc - Rectangle - Rectangle with round corners - Static text Predefined objects such as - Table, curve, message, log and image windows - OLE objects - OCX (ActiveX) objects (OLE control) - Input and output boxes - 2D and 3D bars - Graphic objects (BMP, WMF, EMF, GIF, JPG or using OLE) - Status displays - Text lists - Group displays Windows objects - Button - Check box - Radio box - Round button - Slider Dynamic control should be possible for the appearance of all graphic components. Variables which determine the geometry, color, pattern etc. should be directly accessible or definable using tag values or from programs. For example, a line can be colored red, green or blue, the size of a circle changed, or a group object moved on the screen. Status displays can be controlled by alternate display or suppression of individual graphic objects positioned above one another. It is possible in this manner for the process, the processing in the control system, actions or even standard Windows applications to actively influence the screen display. Examples of properties which can be dynamically controlled: - Object color and pattern - Background color and pattern - Line color, width, type, start, end - Font - Horizontal, vertical writing direction - Foreign language for inscription texts (using operator input) - X and Y positions in pixels - Display of objects (visible/invisible) - Circle radius - Start and end angles - Corner radius - Access privilege (using operator input) - Upper and lower limits of bars - Hysteresis response of bars - Scaling and graduations for curves (using operator input) - Filling of any polygons (also with patterns) The control system should also provide the facility for using existing graphics or photographic material for designing the images. Graphics files with BMP, WMF, EMF, GIF, JPG or OLE formats can be imported. 4.4 Processing of basic data 4.4.1 Message processing The message system processes the results of functions which monitor the activities in the process, in the automation level and in the system. It outputs messages optically and audibly, and archives then electronically and on paper. Optional access of messages, sorting in ascending/descending order, and supplementary information for individual messages guarantee fast locating and elimination of faults. The message structure is freely-definable and must therefore be adapted to the special requirements of the plant. A message consists of message blocks which may also contain variable values. Each message of a product is arranged in a store comprising 16 message classes with 16 message types each. It should be possible to configure up to 50,000 different messages. The control system should generate messages from: - Bit variables These are managed by the data manager in the variables function, and can be process variables or internal variables. Thus actions can process any monitoring functions and trigger messages from the control system using the action "Write variable". - Analog variables Using the limit monitoring function, any number of limits can be defined for a variable. A message is generated if one of these limits is violated during runtime. - System monitoring - Group messages - Process and archive operations - The arrival of messages - From the process - From the automation system - From an action The message system consists of a cyclic archive. The oldest entries are overwritten. The archive can be transferred to a long-term archive according to shift, day, week or month. A selection criterion defines which individual messages are to be archived. The sizes of the archives are only limited by the vacant hard disk capacity. The system should automatically inform the operator when the hard disk capacity becomes too small. It should be possible to process up to 100 messages/second at continuous load. 4.4.2 Processing of measured values The control system archives measured values from the automation system. Recorded values can be processed using definable actions before being saved. The measured values are recorded cyclically or event-driven using the variables function. It is thus possible to record process values as well as values of internal variables, values from any applications and manual inputs. The processing can produce totals, minimum, mean or maximum values or also be freely-formulated in an action. The storage operation saves the processing results in the measured-value archive on a hard disk medium. The recording cycle can be freely-defined within limits. The archiving cycle can be as large as the recording cycle, or a multiple thereof. Totals, minimum, mean and maximum values are calculated from the values recorded between two storage times. Recorded values can be written immediately onto the hard disk, thus preventing data loss (instantaneous values). If faults occur during measured-value recording, either the last value or a configured substitute value can be saved. To achieve fast recording of values, they can also be included in a cyclic buffer in the main memory (online curves). The control system should offer various methods for archiving measured values. Measured values should be archived cyclically or event-driven, individually or in blocks. The following procedures should be possible: - Archive cyclically and continuously - Archive cyclically and selectively - Archive acyclically - Archive only following changes 4.4.3 Commands/setpoints It should be possible for the system operator to carry out switching operations or command outputs using plant displays (process displays) or other screen forms provided for this purpose. The execution of a command (bit command or setpoint) is expected and monitored by the control system in the form of a feedback if parameterized accordingly. It must be possible to specify the setpoints parameterized in the system as physical values using a screen form. The unauthorized output of commands and setpoints is blocked by the control system using password protection. Disabled (switched-off) commands and setpoints are not output. 4.5 Process operation and visualization These components permit the user to monitor the process, to intervene in the process, and to define or modify system and process parameters. Pixel graphics monitors with keyboard and mouse are available for this purpose. Operation and monitoring of the process is largely carried out using: - Process displays - Process information - Curve displays - Message evaluation system 4.5.1 Process displays To facilitate operation of the control system, the process displays are organized in the form of a hierarchical tree: - Plant overview - Area overview - Plant subpicture - Detailed object information The graphics editor of the control system must offer functions usual to powerful Windows graphics programs. Functions for exact positioning, alignment, rotation, mirroring and inheriting of graphic object properties should be present just like those for grouping, block generation and the importing or embedding of externally edited texts and graphics (BMP, WMF, EMF, GIF and JPG formats or via OLE). Its facility for opening several displays simultaneously permits fast copying between different displays. The clipboard can be used for this, or even simpler using drag & drop. Working with the block library and configuring of a status display with up to 32 different statuses are carried out in an analogous manner. The graphics designer permits direct modification of the properties of individual objects in the case of grouped objects without having to first cancel the grouping. It is also possible to simultaneously modify properties of several selected objects (e.g. the line color). It must be possible to individually adjust the GUI of the graphic designer. The size and position of the various palettes for colors, zooming, alignment functions, object types and styles must be variable; if necessary, non-required palettes can simply be hidden. Frequently used functions can be offered as icons in the toolbar. The graphics designer outputs the exact coordinate values and the zoom value, and enables pixel-exact positioning of objects using the cursor and tabulator keys. Several clear configuration dialogs exist for most objects, permitting parameterization of the most important properties of an object in a dialog box. This dialog box is displayed automatically as soon as the associated object is positioned in the display. Furthermore, the graphics designer makes it possible to manipulate practically all properties of an object and to update them during runtime. Dynamically updated properties are emphasized in bold print in the properties box so that they can be easily recognized. The graphics designer offers several graded facilities for dynamic updating of object properties. In the simplest case, such properties are linked directly to internal variables or process variables. A dynamic dialog makes it possible to carry out simple conversion of values or, for example, to define ranges for changing the color coding. Flexible dynamic updating is provided by direct incorporation of scripts. These are incorporated either using C scripts in the ANSI-C standard or using Visual Basic scripts. Using a direct connection, control system objects can influence the properties of other objects, for example the position of a slider influences the angle of rotation of a pointer instrument. A dynamic wizard makes complex dynamic functions easily accessible to the configuring engineer. The graphics designer supports configuring in 32 image levels. In the case of complex images with several superimposed objects, individuals levels can be suppressed, making the display far clearer. Standard Microsoft aids such as tooltips for the online project are naturally included in the control system and can be configured with just a few inputs. A multi-language definition must always be possible for such configuration operations. Once objects have been generated, they are stored in a library and recalled from there. Standards specific to the company, technology or sector can then be produced and support rapid generation of a project. The control system recognizes the block library – divided into global and project-specific libraries – and the function library which can be used during script configuring. The global library includes predefined objects sorted according to topics and belonging to the scope of delivery of the control system (valves, motors, cable runs, indicators etc.). The project-specific library is provided for the individual project. The objects can be configured in several languages. The names of the objects and object groups, as well as the user-defined interface parameters, are also switched over when the GUI is switched over. Each graphic object, irrespective of its complexity, is saved in the block library. This could be a pure graphic, or the objects can also include special processing routines or even process links. Thus larger projects can also be rapidly handled using standardization. The blocks can be listed in the library with their names. They can also be displayed as icons, permitting simpler and faster identification of individual objects. Integration of such an object into a process display is then simply carried out using drag & drop. New objects can be inserted into the library just as easily. The global library also includes the following object classes: - Shut-off fittings and gate valves - Displays and measuring instruments - Control panels, buttons and switches - DIN 30600, ISA and E symbols - Conveyors, motors - Cable runs, valves and tanks - Scales - etc. The user object permits configuring using modular systems. Any graphic objects can be grouped into a new object, and the interface parameters relevant to a process connection can be defined. The names used by the configuring engineer can be saved in several languages, e.g. "High limit" for English and "Obergrenze" for German. The user object can be saved in the library using drag & drop, and subsequently inserted into control system displays in the same manner. Only the parameters which have been defined by the user are linked to process variables. The global library contains a whole series of such user objects (e.g. measuring instruments) and can be expanded at any time in the configuration if required. HMI systems (Human Machine Interface) are used for central operation and monitoring of processes. Displays must be produced which permit a view of the plant. There are usually several process objects of the same type, for example motors, pumps, controllers and valves. The control system should show how the costs for configuring the graphic representation of these process objects can be minimized. It permits standard operation and display of such objects using the faceplate modules. The control system offers a very efficient type of configuring: functions which are repeatedly required are only defined once, where each function call can be executed with its own data. It is possible to integrate image windows in a standard control system display which provide a window area for further control system displays. For example, the same display is to be output several times as subsidiary images in the master image. During runtime, each subsidiary image is a referenced copy of a configured image. Each runtime copy works with its own data. Configuration is carried out centrally so that modifications become immediately effective in all calls of subsidiary images from all relevant master images. The main objective is thus central modification of image sections which are repeatedly required, making repeated modifications at many positions superfluous. Each runtime copy – referred to as an invocation of an image type – works with its own structured data set. The control system should permit use of such data sets on the basis of freely-defined data structures with derived variables. The configuration of such a type of faceplate initially corresponds to the configuration of a standard control system display which is usually smaller than the complete screen area. The graphic layout and the internal processing routines are defined during the configuration procedure. A standard script must be inserted in order to derive a faceplate type from a normal display. This is provided with the invocation name and a table containing information on the type connections. This standard script refers to an I/O box, and is triggered when its output value is changed. Creation of faceplate invocations from a predefined faceplate type means placing image windows in a master image and calling the faceplate type there. During runtime, the invocation name of the associated copy of the faceplate type is written into the I/O box. The connection to the corresponding data set structure is then carried out automatically via the type script. In order to display objects (e.g. pumps, gate valves, motors etc.) and object statuses (e.g. on/off, remote/local etc.) in the process displays, symbol sets comprising standardized symbols must be created by the contractor; the symbols must be used uniformly in all process displays. The system must additionally make it possible for the client to modify the existing symbols and to create new symbols. Modifications made in the symbol set must be automatically imported into all process displays by the system. The detailed information associated with an object output in the process display can be visualized if required. To make this possible, an additional window with the associated object data is output in the selected display when the object is clicked using the mouse. The content and design of all plant displays must be agreed upon with the client during preparation of the development response specification. 4.5.2 Curve displays Archived values (instantaneous or compressed values) can be displayed as curves and tables both on the screen and in reports. Colors and patterns can indicate limit violations, substitute values, faults and jumps in time, for example. Just like the message window, the curve window also provides a toolbar for operator access to curves. A brief help text explains the meaning of the individual icons. If required, individuals keys can also be configured and stored with the associated operating functions. It is also possible for authorized operators to modify parameter settings online, i.e. to change the colors of curves or to generate new groups. Access to the archives is supported by specific, direct section of measuring-point groups, measuring points and individual measured values. Selection can be made using names or time slots. The values of a section of the display can be focused in detail using the ruler and zoom function. The scales of the time and value axes are adapted accordingly, and the curve values interpolated for the display. It is possible to configure a common or separate axis for each curve with different value ranges per curve. Limit violations should be identified by a configurable change in color in the output in the curve window. The configurable direction of the curve means that horizontal and vertical writing directions can be set for the curves, thus making a recorder function possible. The x and y axes are interchanged by the recorder function compared to the normal curve display. The y axis is used as the time axis. It is additionally possible with the recorder function to define whether the current time is to be at the top or bottom border of the curve window. If several curves are displayed simultaneously, the control system should also offer the possibility for curve staggering. With this setting, the curves which are to be displayed in a curve window are superimposed on one another. The range of values for the y axis can be defined for each curve. 4.5.3 Message logging/evaluation/acknowledgment The message list can be displayed using line-oriented message windows. Message statuses can be differentiated at all times by different colors. Freely-selectable filters specifically assign the view of the message display to individual process or plant components. Several different message windows can be used in an application with the control system. The two following displays are possible in the message window: - Dynamic message window (process message window) This view only contains incoming and currently present messages. Messages which have already returned to normal can be automatically removed from the view when appropriately configured. - Message window with archive view (short-term or long-term archive) In this mode, all messages recorded up to this moment in the short-term or long-term archive are displayed, also those which have already returned to normal. New messages can be displayed using an additional message window if required. In addition, graphics objects can also display message events by changing their appearance. The message can be acknowledged using an operator input on the graphic object. Message logs continuously document the sequence of messages (message sequence report) or specific views in the archive (message archive report). The printout is output when a page has been completely filled. In the case of the message sequence report – which is exclusively assigned to a line printer – the printout is made each time a message occurs. Messages can be tapped using open program interfaces and, for example, audibly signalled using a sound card. Any further analysis and evaluation actions can be derived on this basis. If a message occurs, an application can specifically direct a video camera to the location of the cause, and display the situation on the screen. The operator can scroll through the messages displayed in the message window either line-by-line or page-by-page, forwards or backwards, or also jump to the start or end of the list (short-term/long-term archive). The messages displayed on the screen can be acknowledged individually (single acknowledgment) or completely (group acknowledgment). With a group acknowledgment, either all messages currently visible in the message window or all messages requiring acknowledgment are acknowledged. The message system can also pass on acknowledgments to the automation systems so that these can react accordingly. Selections can be carried out to provide a better overview and direct access to the desired information. Selection criteria can be generated dynamically online by setting completely freely-selectable filters. Ascending and descending sorting of alarms enables fast and efficient fault analysis. Various combination possibilities exist. For example, all messages which have already returned to normal can be automatically removed from the display if required and if they no longer satisfy the currently valid selection criterion. Individual messages, message classes and message types can be eliminated from the recording or incorporated again as desired (disable or enable messages). For example, if a fault in the control technology results in permanent occurrence of a message, the operator can disable its appearance, and then enable it again following elimination of the fault. The operator can enter a separate text (message comment) in the message archive for each message and for each occurrence of a message. This comment is saved with the message and can be recalled later. The person responsible for the next shift can therefore obtain information on the events of the last shift in electronic form. Messages can also be configured for saving together with message information. This information supports the operator with more detailed information each time the message occurs. The message "Motor 25 faulty" could therefore simultaneously include information on elimination of the fault. The loop-in-alarm function outputs the associated process display for the selected message, or triggers a stored action so that the operator can specifically react to the cause of the fault. 4.6 Report system The control system should offer an integral reporting system with which the data can be output on paper. Freely-selectable layouts should be available for printing the following data recorded during process operation: - Message sequence reports - Message archive reports - Archive reports - Operator input logs - System message reports - User reports - Hard copies and configuration data (documentation updating, complete or portions). Prior to direct output on the printer, the reports can also be saved as a file and displayed as a preview on the screen. The status of all jobs can be displayed online by means of a corresponding operator input. Print orders can be defined in the configuration which determine the layout, the scope (number of pages) and the printer to be used. It is also possible to define cyclic hourly, daily and monthly reports. Reports can also be started time/event-driven or by direct operator input. A specific printer can be assigned for each print order. If this fails, a specific substitute printer is used (max. three printers can be defined). The message sequence report can output incoming messages immediately on an exclusively-assigned line printer (line-by-line printing). It should be possible to adjust curve reports dynamically (e.g. the time period). Screen views set online, as well as filters for curve and message data, can be printed out directly at any time. The report layouts consist of static and dynamic objects as also available in the graphics system. This means that table objects, curves and complete images (in the form of a dynamically generated meta file) can also be integrated in a report. It should also be possible to integrate hard copies with variable image coordinates and zoom areas. In addition to the process data present in the control system, it should also be possible to integrate external data, e.g. using ODBC objects or in CSV format. 4.7 Archiving system Two types of archive are differentiated: 4.7.1 Short-term archive (recorder data) The short-term archive is used to archive data points resulting from processing of the process data as rapidly as possible. The saved data are mainly used to generate curves for the measured values (recorder data). 4.7.2 Long-term archive Long-term archiving is the cyclic archiving of selected process data in a database, and their further compression in defined time intervals together with automatic deletion of archive data when they have reached a certain age. The data saved in the long-term archive (database) are available for evaluation in the system. 4.8 Development response specification The elaboration of a development response specification for hardware and software is required for the control system. The contractor is responsible for production of the specification. The development response specification should clarify all details with respect to the task and specific requirements, and present the solution in detail. If necessary, the specification will be revised during the technical clarification phase according to the requirements, and presented again to the client. Scope and contents of the development response specification The scope of the development response specification basically includes: - Configuration (hardware and software) - Function description - Generation of information lists - Generation of plant displays 4.9 Display generation The following procedure is to be used for generation of displays: - Display draft (on paper or monitor) - Agreement with client - Incorporation of requested corrections - Renewed agreement with client - Incorporating of any further corrections - Completion of display generation An exception will be the first plant display. This display is to be used to clarify fundamental points with the client such as display division, number and position of message lines, colors, symbols etc. It can therefore be assumed that this display will be modified many times. 4.10 Documentation The documentation must be designed such that the system design and function are clear and easy to recognize, and that optimum maintenance and repair are guaranteed. Scope of documentation: - Hardware documentation - Standard software and system software documentation - Documentation of data points - User manual - Documentation updating of system parameters - Hard copies of plant displays - Program listings of user software produced specific to the plant All documents referred to above must be clearly arranged in DIN A4 folders and handed over as two copies to the client for checking at the latest following trial operation. The scope of delivery also includes a copy of the software system on CD. 5. Sector-specific modules for expansion of control system 5.1 Archiving and reporting in conformance with ATV 5.1.1 Fundamental system requirements and properties The following fundamental archiving objects must be implemented for archiving and reporting in conformance with ATV: - Measured values - Counted values - Laboratory values / manually entered values - Derived data (computed values) For all these archiving objects, the system must automatically generate further compression stages using a basic interval depending on the archived object. The compression stages are described further below together with the respective archived object. Archiving of measured values and counted values can be carried out both online and using time-delayed telegrams with time stamp depending on the system configuration of the PLC. Based on the archived data, it must be possible to make evaluations in the form of output curves (historical curve data) and reports in line with ATV-M 260. 5.1.2 Measured values and their processing The configuration of the measured values relevant to archiving and reporting in conformance with ATV specifies a basic interval for the archiving. This is the mean value. Either 1, 3, 5 or 15 minutes can be selected as the basic interval depending on the requirements (see specifications). Further compression of the values takes place automatically at intervals of 1 hour, 2 hours, day, month and year. The maximum and minimum values can also be determined for the archived values in each compression stage. The automatically recorded measured values must be checked for plausibility, limit violation, measuring-point failure and communication fault to the PLC. Corresponding identifications must be saved together with a measured value. In the case of a measuring-point failure or communication fault to the PLC, it must be possible to define a substitute value. In the case of telecontrol configurations, the measured values provided with a time stamp in the automation system must be read into the control system in the same manner and arranged in the archive in chronological order. These data are then also available for further evaluation. Recorded values can be manually connected by the user if he has a corresponding password privilege. A corrected value must be appropriately identified in the reports. 5.1.3 Processing of counted values All counted values (e.g. quantity in m³, kWh etc.) must always be recorded via pulse inputs on the local automation systems, standardized, and processed further in the control system. The counted values must be recorded cyclically, and differences between the values generated for further processing. The following intervals are available for the evaluations: - 1-hour value - 2-hour value - Day value - Month value - Year value The following processing steps must be carried out when recording the counted values: - Plausibility check - Generation of extreme values - Generation of substitute value - Overflow processing The plausibility check must recognize when the counter value has been manipulated in the PLC during runtime (e.g. resetting of PLC with setting of counter value to "0"). This must be taken into account when determining differences in counter values. In the normal case, the overflow takes place at the "natural" limits (e.g. an unsigned 16-bit value overflows at 65535). The overflow must be freely-adjustable for individual values. 5.1.4 Laboratory values / manually entered values Manually entered values are not received online from the PLC but must e.g. be entered following determination in the laboratory. Assignment of these manually entered laboratory values according to date must be carried out by the user. Input of the values must be easy. The following alternatives should be available for entering laboratory values: - Input in table - Input in self-defined input forms - Manual importing of laboratory values from file Automatic importing of laboratory values must be available for those values which are written automatically by a laboratory system into a CSV file. Depending on the manually entered value, the interval can be selected as follows: - 2 hours - 12 hours - Daily - Weekly - Monthly - Yearly On the basis of the respective input interval, the laboratory values are compressed into daily, monthly and yearly values analogous to the measured values. A differentiation is basically made between 3 types of laboratory value. The type defines how a non-existent value (e.g. no value determined on Sundays) is to be incorporated into the processing: - Type 1 – stored laboratory value: the last value is held up to the next input - Type 2 – manually entered value: 0 is used if no value is entered for a particular interval - Type 3 – analyzed value: if no value is entered for a particular interval, it is entered as non-defined The period for which a manually entered value may still be entered for the past or also imported must be adjustable. Values which are older than this period must be rejected by the system. The values can also be entered on a client. 5.1.5 Derived data (calculated values) Derived values – so-called calculated values – must be provided by the system. The results of operations are assigned cyclically to the calculated values. Mathematical calculations and logic operations on measured values, laboratory values, calculated values, constants and status messages can be generated using equations. The following functions must be implemented: - Fundamental arithmetic operations (addition, subtraction, division, multiplication) - Logic functions (AND, OR, NOT). - Mathematical functions (power, root, sine, cosine, tangent, absolute value, exponential value, Napierian and common logarithms) - Special functions (conditional calculation IF .. THEN , polleni, cos ?) - Comparison (<,>,=, <=, >=, ><), - Constants (Euler's constant, Pi, selectable constants) - Parentheses Handling of substitute values must also be available for the calculated values. It must also be possible to manually correct a calculated value. A corrected value must be identified accordingly in the reports. The basic calculation interval can be selected as follows depending on the calculated value: - 1, 3, 5 or 15 minutes - 2 hours - 12 hours - Daily - Weekly On the basis of the respective calculation interval, the calculated values are compressed into hourly, 2-hourly, daily, monthly and yearly values analogous to the measured values. 5.1.6 Curve displays The data archived in conformance with ATV such as measured values, laboratory values and calculated values are displayed on the screen in the form of historical curves (output curves). Up to 8 curves can be assigned to one curve display. The functions listed below are required to simplify work with the curve displays: - Online combination of curves - Single symbol display - Zoom function - Adjustable time range - Shifting of curves in the x and y directions (offset of value and time) - Two selectable rulers which indicate the respective values underneath the rulers as well as mean value, maximum value and total between the rulers. - Printout of current curve display by pressing key - Application of a weighting factor to a curve 5.1.7 Reports, logs, evaluations and balances The types of reports and logs must correspond to the ATV-DVWK-M 260 data sheet "Recording, display, evaluation and documentation of the operating data of sewage treatment plants using the process data". This is guaranteed by optional logging in MS-Excel with access to the archived data. The list of required reports can be obtained from the function catalog. The following applies: It must be possible to configure several different daily reports (e.g. short-term and long-term acquisition). The same applies to monthly and yearly reports. Printing out of all reports is made following selection of the desired period on the GUI by manual triggering from MS-Excel. It must be possible to output a preview of the reports on the screen. The reports can be saved in MS-Excel, CSV (Comma Separated Value) or HTML (HyperText Markup Language) formats. Subsequent processing of the reports must be possible at any time following saving in the above-mentioned formats. 5.1.8 Saving of archived data on external media The data for the archiving and recording in conformance with ATV, such as measured values, laboratory values and calculated values, are stored in their own databases in a ring buffer. The following functions must be present to prevent data from being lost when the ring buffer has been circled completely: - Function for data saving (copy) (manual and automatic, daily or monthly) - Function for restoring saved data - Ring buffer size individually adjustable for daily, monthly and yearly data 5.2 Alarm output using radio call The module automatically directs messages and alarms from the subordinate automation systems to radio call receivers. The modular design means that country- specific or application-specific radio call services, further process interfaces as well as shift management can be integrated without problem. The module can save up to 99 different radio calls. Furthermore, radio calls can be started directly on the user interface and modified at any time. The following radio call services are supported: - D1 – SMS - D2 – Message - City call - E-Plus - Quix news - mobilkom Austria (A1, Amax) - Natel Swiss The previously defined service units (e.g. mechanical engineer, electrical engineer etc.) are assigned to the individual persons in a so-called telephone book. The shift management defines the persons in the respective service unit to whom the messages are to be sent and the times. By using the escalation system it is can be guaranteed that the message is successfully passed on even if individual persons cannot be reached by sending it to further persons as necessary. 5.3 Maintenance management A module should be fully integrated in the control system and contain maintenance functions which support the plant operator during inspection, maintenance and repair of the plant. The combination of calendar intervals with operating hours and cycles counters processed online should permit optimum determination of maintenance dates/intervals. In addition, it should be possible to directly activate a job through process signals. For the maintenance reports, it must be possible to define maintenance objects (e.g. pump, gate valve) which are linked to an input/output signal. Maintenance orders are assigned to these maintenance objects, and their interval counters count depending on: - Runtime - Calendar - Operating cycles. The carrying out of maintenance is acknowledged by the user and also saved in the system. It should be possible to correct the intervals for the actual times and total times (necessary e.g. when replacing pumps). The user can call the following overviews on the screen: - Status of all maintenance orders - Recommended maintenance dates - Announced maintenance dates - Planned maintenance dates - Dates for today, tomorrow, last/next month/week - Percentage availability or exceeding of interval It must be possible to implement the following functions: - Maintenance through combination of performance measurement with calendar/event control - Automatic activation of maintenance (single/cyclic) or manual - Overview with maintenance orders in tabular form and as object structure - Manual repair orders - Order management and planning - Order feedback with configurable feedback and weakness codes - Subsequent processing of order feedbacks - Long-term archive with filter and export functions - Importing/exporting of master data management to permit generation and modification e.g. with EXCEL - Automatic or manual recording of all maintenance data - Integration of maintenance data into ATV reports - Free output of maintenance data possible in process displays 5.4 Direct interfacing of telecontrol stations to the host computer The system should be able to directly interface telecontrol substations, i.e. without a PLC as interface. This means that the host computer operates as a telecontrol master station with respect to data coupling. Current process values as well as messages from the substations are processed in the control system via a modem connection. Control commands and setpoints are entered in the control system by the operator and transmitted to the substations for further processing. Messages and measured values to be archived in the control system must be transmitted to the system with an exact time stamp and entered in the archive in chronological order (preprocessing of process data in the telecontrol substation). The status information of the substations should be displayed in the control system by means of standard displays. The operator must be informed of faulty substations directly on the graphics objects (e.g. actual-value boxes). Analog values can be converted from the raw value into the physical value and vice versa using linear adaptation of the raw values. Counted values are checked for overflow, and can be processed with respect to their interval quantities. They are also transmitted to the control system with the exact time, and processed. 5.5. External operator terminal via the Internet The external operator terminal permits plant monitoring and control via the Internet or intranet. The following functions must be provided by the terminal: - Operation and monitoring, evaluation, servicing and diagnostics via the Web - Individual assignment and access privileges for displays and start page to the various Web users - Different authorization levels unambiguously define the access privileges - High security through isolation of server-local project from Web project - High-performance, modification-driven transmission of data – Internet HMI callback - Additional security mechanisms such as routers, firewalls, proxy servers, SSL coding and VPN technology - It should also be possible to operate mobile terminals as Web clients (e.g. rugged local units or mobile panels as low-cost alternative to PCs on all standard operating systems such as Windows NT, 2000, XP, ME, support of Microsoft Terminal Services) 5.6 Optimization of plant management for drinking water networks and district water supplies The plant management system should serve towards optimization of the running of the water supply network. Since the operating costs primarily depend on the current consumption of the pumps, particular attention must be paid to the runtimes of these pumps. The plant management system should provide the operating personnel of the water supply network with help by determining cost-optimized pump utilization plans using mathematical procedures. Restrictions resulting from the structure of the supply network are taken into consideration by this procedure. These plans should be presented to the operating personnel for approval. It should be possible to process the following tasks using the plant management system: Plant management for normal operation Use is possible in particular when elaborating plant management concepts. The question concerning reduction of operating costs with absolute supply reliability is of prime importance. - Optimization of pump utilization plans Utilization of high-tariff and low-tariff periods as included in power supply contracts; observation of power limits (kWmax monitoring) and switching cycles - Optimization of reservoir plans Utilization of high-tariff and low-tariff periods as included in power supply contracts; observation of power limits (kWmax monitoring), consideration of max. duration times - Revision of power supply contracts New negotiation of existing power supply contracts according to previous determination of required quantity - Maintenance planning Consideration of maintenance and repair measures in normal operation, thus increase in operating reliability with simultaneous reduction in operating costs - Optimization of well runtimes Consideration of maximum and minimum quantities, transport costs - New division of consumer areas - Optimization of external water importing 6. Quantity breakdown and performance Upper limits - Process connection / communication - Configurable PLC process variables 64,000 - Number of different updating cycles 8 - Graphics system - Number of objects per picture 1000 - Updating cycle for process variables <= 2 sec with typical plant displays - Number of variables per display max. 500 - Number of accessible fields per display 1000 - Archiving of process data - Sequence archiving: values per second 5000 - Curves - Number of curves per curve display 15 - Number of measured values on hard disk Limited by hardware - Message system - Number of message archives (single/long-term archive) 2 - Number of messages per sequence archive Limited by hardware - Number of configurable messages 50,000 - Possible number of archived messages per 1 s 100 - Rush of alarms without loss, 2000 in 10 s not as permanent load - Number of process variables per message line 10 - Reports (not ATV reports) - Number of simultaneous message sequence reports 1 - Number of message archive reports (simultaneous) 3 - Number of user reports 20 - Number of report lines per block 66 - Number of variables per report 300 - Multi-user system - Number of clients for server with operator terminal 4 - Number of clients for server without operator terminal 32 - Number of Web clients 50 01. Process control system PCS 01.01 Design guidelines (hardware) 01.01. 0010 1 Installation in central control room as server Product: Siemens or equivalent Product: _____________ Type: _______________ Minimum technical requirements: – Pentium IV processor; 2.8 GHz – main memory configuration according to system requirements, min. 1 GB – min. 40 GB IDE hard disk drive – 3.5 inch diskette drive, internal, 1.44 MB – CD drive 50-speed – CD RW drive 40x12 speed – SBus with 2 vacant interfaces – interfaces: SCSI, Ethernet, ISDN 2*RS423, audio – Min. 1280 * 1024 pixels – 1 keyboard – 1 mouse – installed in tower housing– including all required accessories Delivery and startup Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0020 1 Color monitors Product XXX or equivalent Minimum technical requirements: LCD color monitor 20" TFT – low radiation – 80 Hz vertical frequency – resolution 1280 * 1024 pixels – connecting cable to computer 1.50 m including all required accessories Delivery and startup Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0030 1 Printer Installation in central control room Product: XXX Type: xxx or equivalent Minimum technical requirements: – color graphics printer – min. 9 pages/minute b/w, 30 s/colored page – single sheet (paper width up to DIN A3) –max. noise xx dB – serial interface (RS-232C) – data cable, length: min. 15 m including all required accessories, incl. drivers for WIN 2000/XP Delivery and startup Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0050 1 Color printer (hardcopy unit) Installation in central control room Product: HP or equivalent Type: LaserJet Minimum technical requirements: – laser printer – paper format DIN A4 – 4 MB – parallel interface (Centronics) – data cable, length: max. 10 m including all required accessories Delivery and startup Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0060 1 MO drive 650 MB Product: XXX or equivalent Type: Minimum technical requirements - Connection via SCSI bus - For archiving Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0070 1 Radio clock with time transmitter For connection to the bus system Product: Siemens Type: DCF77 time transmitter or GPS Minimum technical requirements – LCD – keyswitch for locking – LED for operating display – automatic summer/winter time switchover – interface for bus connection With all accessories, small parts, fixing and mounting material, delivery and installation; including complete parameterization and startup. Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0073 2 Installation in central control room as client (HMI station) Product: XXX or equivalent Product:_____________ Type: _____________ Minimum technical requirements: – Pentium IV processor; 2.8 GHz – main memory configuration according to system requirements, min. 1 GB – min. 40 GB IDE hard disk drive– 3.5 inch diskette drive, internal, 1.44 MB – CD-ROM drive 50-speed – SBus with 2 vacant interfaces – interfaces: SCSI, Ethernet, ISDN 2*RS423, audio – min. 1280 * 1024 pixels – 1 keyboard – 1 mouse – installed in tower housing including all required accessories Delivery and startup Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0076 2 Color monitors Product: XXX or equivalent Minimum technical requirements: LCD color monitor 20" TFT – low radiation – 80 Hz vertical frequency – resolution 1280 * 1024 pixels – connecting cable to computer 1.50 m including all required accessories Delivery and startup Product:.......................................... Type:............................................... Dimensions:.................................... Power requirements:....................... 01.01. 0080 1 Static uninterruptible power supply for the control system, comprising: compact, low-noise, single-phase UPS with design matched to office surroundings, online function principle, i.e. connected consumers must be supplied by the UPS uninterrupted and isolated from any irregularities in the power supply network, supply to inverter during short dips and power supply failures from integral, maintenance- free and closed lead battery, automatic charging of battery during power supply mode, automatic switching over to bypass mode in event of higher or longer overloads and with consumer short-circuits, simple operation and functional display of operating states and loading stages: power supply present, inverter on, bypass mode, group fault – load display 0 to 150%, audible prewarning when the remaining stored energy time of the battery (at rated load) is only 1.5 minutes, computer interface 01.01. 0090 1 Bus system System-based bus cable mainly comprising: bus coupler – bus amplifier – bus cable or connecting cable – coax plug and terminating resistor including complete overvoltage and lightning protection equipment, including all required accessories, delivery, installation and startup for connection of server and clients, including 30 m cable. Product: Siemens or equivalent Selected system: Product: ________________________ Type: _________________________ 01.01. 0100 1 Bus system System-based bus cable mainly comprising: bus coupler – bus amplifier – bus cable or connecting cable – coax plug and terminating resistor including complete overvoltage and lightning protection equipment, including all required accessories, delivery, installation and startup for connection of server and automation bus, including 10 m cable. Product: Siemens or equivalent Selected system: Product: ________________________ Type: _________________________ Subsection total: 01.01: Design guidelines Subsection heading 01.02 Software 01.03. 0010 1 Standard software Windows 2000 or XP operating system, on CD-ROM incl. installation and documentation, incl. following supplements or components for: communication to PROFIBUS, client/server communication Product::.......................................... Type/version :.......................................... 01.03. 0020 1 Control system standard package For generation and use according to preliminary remarks, delivered on CD-ROM, incl. installation and documentation To be offered: development license, runtime licenses for client, minimum technical requirements: Multi-window capability – min. 256 colors – display capability for curves, bars – color changes – flashing – management of min. 500 displays with up to 200 variables each Possible product: Siemens or equivalent Type/version: WinCC........ 01.03. 0030 1 Control system – user software – corresponding to requirements – standard system without parameterization of the data points for the requirements as described in the preliminary remarks – including all licenses required for operation of all control system components – including all standard documentation for hardware and software Product:.......................................... Type:.......................................... 01.03. 0040 1 Control system – user software – corresponding to requirements for reporting according to ATV M260 for use on the server. Supply software on CD-ROM, install on server and startup. Product: Siemens or equivalent Type/version: PM-AQUA........ Subsection total: 01.02: Standard software Subsection heading 01.03 System software / test / 01.04. 0010 1 Engineering The following services must be provided in agreement with the client: – production of development response specification for hardware and software – function description – generation of information lists – definition of master data In accordance with definition in preliminary remarks and protocol parameterization corresponding to client's guideline definitions (short and long versions): completely installed and documented 01.04. 0020 System parameterization of measured values Completely installed, documented and started up 01.04. 0030 System parameterization of setpoints Completely installed, documented and started up 01.04. 0035 System parameterization of counted values Completely installed, documented and started up 01.04. 0040 System parameterization of binary signals (messages) Completely installed, documented and started up 01.04. 0050 System parameterization of binary signals (commands) Completely installed, documented and started up 01.04. 0060 1 Development response specification and implementation of process displays The process displays must be drafted as a 1:1 concept and agreed upon with the client. The process displays can be entered into the system following the final definition. It is assumed that small adaptations will still have to be subsequently carried out. 01.04. 0060 1 Plant displays – overview displays With 5 picture variables 01.04. 0060 Process displays With linking of up to 20 variables 01.04. 0060 Process displays With linking of up to 40 variables 01.04. 0060 Process displays With linking of up to 60 variables 01.04. 0060 Process displays With linking of more than 60 variables 01.04. 0060 Curve displays For curves/output curves with parameterization of picture attributes 01.04. 0070 1 Generation of a daily report according to ATV M260, including draft, revision and implementation on the control room system. 01.04. 0071 1 Generation of a monthly report according to ATV M260, including draft, revision and implementation on the control room system. 01.04. 0072 1 Generation of a yearly report according to ATV M260, including draft, revision and implementation on the control room system. 01.04. 0073 1 Generation of a monthly report for the daily log, including draft, revision and implementation on the control room system. 01.04. 0074 1 Generation of a yearly report for the daily log, including draft, revision and implementation on the control room system. 01.04. 0075 1 Acceptance test The contractor installs all computers of the process control system as well as an automation system with simulation possibilities for the analog and binary signals in his factory. The most important plant functions are then tested. The following acceptance is recorded in a report. 01.04. 0080 1 Installation ready for operation covering the following: installation of hardware in the equipment rooms – connection of power supplies – connection of various components using the standard connecting cables – connection of control system components to the process bus – connection of I/O equipment (printers, plotters) – including all accessory materials The space requirements and dimensions must be agreed upon with the client. 01.04. 0090 1 Hardware startup All control system equipment is tested and started up on the client's plant using test programs, including interfacing of the automation level. 01.04. 0100 1 Software startup Startup of complete process control system by the contractor on the client's plant. Followed by a performance test by the client with support by the contractor. All functions and interactions of all system components are checked during this conformance test. Deviations from the development response specification or malfunctions of the control room system are recorded in a report. In the event of small defects which do not influence the plant functions, the plant is considered as accepted. If system defects are detected during the test, the contractor will receive an improvement deadline of 20 working days. 01.04. 0110 1 Training of operating personnel – Locally on the plant – training for handling the system – practical work with the system – extended training for __2___ persons, duration 5 days 01.04. 0120 1 System administrator – Locally on the plant – elimination of simple control system faults – display construction / modification of process displays – parameter input / modification in context of system updating – plant-specific training for __1___ person, duration 5 days 01.04. 0130 1 1. Service contract The following services for hardware and software components must be offered for the control system consisting of the various PCs and associated I/O devices (monitors, keyboards, printers, data backup units). 2. Repair Re-establishment of the reference status: 2.1 Debugging of faults 2.2 Elimination of defects, faults and damage on the hardware by repairing or replacing the faulty components or modules 2.3 On system software products by providing debugged software (new product release version) or new delivery (new product version) 2.4 If the fault cannot be eliminated quickly, the contractor will provide an intermediate solution for bypassing the fault – as long as this is possible with an appropriate effort and the client can no longer process urgent tasks because of the fault. 2.5 The response time is the sending of a service specialist or the commencement of Teleservice services initiated following a reported fault 01.04. 0140 1 Service contract As described above, but with a response time during normal working hours from Monday to Friday 01.04. 0150 1 Service contract As described above, but with a response time during normal working hours from Monday to Friday and within the warranty obligations of the contractor 01.04. 0160 1 Engineering – development response specification. The following services must be provided in agreement with the client: – generation of development response specification for hardware and software – function description – generation of information lists – definition of master data as well as parameterization of reports according to ATV M260 guidelines: ATV daily report, ATV monthly report, ATV yearly report, monthly report for the daily log, yearly report for the daily log, fault report, message report, supplied completely installed and documented on external data medium Subsection total: 01.03: System software / test / Section total: 01: Process control system PCS 1 ausschreibungstext_wincc_V6_01_e.doc, Page 1 of 29