Process Control System Procurement Specification Document

V2.0 Rockwell Automation January 2009

PROCES-SP002B-EN-E

Page 2 of 62

Table of Contents

1. System Specification Overview.........................................7 2. System Architecture Requirements..................................7
2.1. System Scalability...........................................................................................................8 2.1.1. Controller Capacity..................................................................................................8 2.1.2. I/O Network and I/O Capacity.................................................................................8 2.1.3. Controller Application Capacity..............................................................................8 2.2. System Redundancy .......................................................................................................8 2.3. System Expansion...........................................................................................................9 2.4. Software Revisions.........................................................................................................9 2.5. System Sever...................................................................................................................9 2.5.1. HMI Server..............................................................................................................9 2.5.2. Data Server...............................................................................................................9 2.5.3. Alarm Server..........................................................................................................10 2.5.4. Domain Server.......................................................................................................10 2.5.5. Security Server ......................................................................................................10 2.5.6. License Server .......................................................................................................11 2.5.7. Historian Server.....................................................................................................11 2.5.8. OPC Server............................................................................................................11 2.5.9. Batch Server...........................................................................................................11 2.6. System Services............................................................................................................12 2.6.1. Distributed Data.....................................................................................................12 2.6.2. Directory Service...................................................................................................12 2.6.3. Alarms and Events.................................................................................................13 2.6.4. Security..................................................................................................................13 2.7. Networks.......................................................................................................................13 2.7.1. Network Management............................................................................................13 2.7.2. Supervisory Network.............................................................................................14 2.7.3. Control Network....................................................................................................14 2.7.4. Control Network Redundancy and Alarming........................................................14 2.8. I/O ...............................................................................................................................15 2.8.1. Analog I/O.............................................................................................................15 2.8.2. Discrete I/O............................................................................................................15 2.8.3. High-Speed I/O......................................................................................................15 2.8.4. Chassis Based I/O..................................................................................................15 2.8.5. Distributed In-Cabinet I/O.....................................................................................16 2.8.6. Distributed On-Machine I/O..................................................................................16 2.8.7. Intrinsically Safe I/O..............................................................................................16 2.8.8. Conformally Coated I/O........................................................................................16 2.8.9. Adding or replacing I/O Modules Online..............................................................17 2.9. Field Device Interfaces and Device networks..............................................................17 2.9.1. DeviceNet..............................................................................................................17 Page 3 of 62

2.9.2. HART I/O..............................................................................................................18 2.9.3. Foundation Fieldbus I/O........................................................................................18 2.9.4. Profibus I/O............................................................................................................19 2.9.5. Intelligent Device Management.............................................................................19

3. System Configuration, Visualization and Maintenance 19
3.1. Engineering Workstation .............................................................................................19 3.1.1. Engineering Workstation Configuration................................................................20 3.1.2. Engineering Workstation Functions......................................................................20 3.1.3. Reusable Applications ..........................................................................................21 3.2. Operator Interface Configuration..................................................................................21 3.2.1. Graphical Display Editor.......................................................................................21 3.2.2. Graphic Displays....................................................................................................22 3.2.3. Standard Faceplate Library ...................................................................................23 3.2.4. Integrated Batch Visualization...............................................................................23 3.3. Operator Interface Visualization ..................................................................................23 3.3.1. Operator Station Redundancy................................................................................24 3.3.2. Operator Station Security.......................................................................................24 3.3.3. Area Security.........................................................................................................24 3.3.4. Alarm Window ......................................................................................................25 3.3.5. Faceplates ..............................................................................................................25 3.3.6. Time Synchronization ...........................................................................................25 3.4. Alarm and Event Management.....................................................................................25 3.4.1. Alarm Priorities......................................................................................................26 3.4.2. Alarm Detection.....................................................................................................27 3.4.3. Alarm Acknowledgment........................................................................................27 3.4.4. Alarm Logging.......................................................................................................28 3.4.5. Alarm Navigation...................................................................................................28 3.4.6. Alarm Archiving....................................................................................................28 3.5. Trending........................................................................................................................28 3.5.1. Trend Data.............................................................................................................29 3.6. Reports..........................................................................................................................30 3.7. Report Generation.........................................................................................................31

4. Process Controllers .........................................................31
4.1. Controller Programming Environment.........................................................................31 4.1.1. Controller Editor....................................................................................................31 4.2. Controller Runtime Modifications................................................................................32 4.3. Controller Restore / Upload..........................................................................................33 4.4. Controller Communications..........................................................................................33 4.5. Control Strategy Development.....................................................................................33 4.6. Controller Configuration Languages............................................................................34 4.6.1. Function Block Diagram........................................................................................34 4.6.2. Sequential Function Chart......................................................................................35 4.6.3. Structured Text.......................................................................................................35 4.6.4. Ladder Diagram.....................................................................................................36 4.6.5. User Defined Functions and Tags..........................................................................36

Page 4 of 62

4.7. Alarm and Event Detection...........................................................................................36 4.8. Process Control.............................................................................................................37 4.8.1. PIDE Loop Control................................................................................................37 4.8.2. PIDE Integrated Auto-Tune...................................................................................37 4.8.3. PIDE Optimized Auto-Tune..................................................................................37 4.8.4. Standard Library for Controller.............................................................................38 4.8.5. Computational Functions.......................................................................................38 4.8.6. Discrete Control Functions....................................................................................39 4.8.7. Advanced Regulatory Control...............................................................................39 4.8.8. Fuzzy Logic...........................................................................................................39 4.9. Batch & Sequencing Control........................................................................................39 4.9.1. Basic Batch & Sequencing.....................................................................................40 4.9.2. Comprehensive Batch & Sequencing....................................................................40 4.10. Drive Control..............................................................................................................40 4.11. Motion Control............................................................................................................41 4.12. SCADA and Third Party Connectivity.......................................................................41 4.12.1. OPC Interface.......................................................................................................42 4.12.2. Serial Interface.....................................................................................................42 4.12.3. Ethernet................................................................................................................42 4.12.4. Third Party PLC Communication........................................................................42 4.12.5. Third Party DCS Communication........................................................................42 4.13. Controller Application Code Security........................................................................43 4.14. Process and System Simulation..................................................................................43

5. Production Management.................................................44
5.1. Historical Data Archiving.............................................................................................44 5.2. Plant Data Historian......................................................................................................44 5.3. Historical Data Reporting.............................................................................................45 5.4. Dynamic Resource Management..................................................................................45 5.5. Batch Reporting............................................................................................................46 5.6. Batch Recipe Management...........................................................................................46 5.7. Material Tracking..........................................................................................................47 5.8. MES Interface...............................................................................................................47 5.9. Integrated Asset Management.......................................................................................48

6. Service and Support.........................................................48
6.1. Training.........................................................................................................................48 6.1.1. Operator Training...................................................................................................49 6.1.2. Maintenance and Hardware Training.....................................................................49 6.1.3. Engineering Training.............................................................................................50 6.2. Technical Support.........................................................................................................50 6.2.1. Onsite Support Services.........................................................................................51

7. Hardware Specifications................................................51
7.1. Inputs and Outputs .......................................................................................................51 7.1.1. Analog Inputs ........................................................................................................53 7.1.2. Digital Inputs ........................................................................................................54 7.1.3. Analog Outputs .....................................................................................................54 7.1.4. Digital Outputs ......................................................................................................54

Page 5 of 62

7.1.5. I/O Terminations....................................................................................................54 7.1.6. Spare Capacity.......................................................................................................55 7.2. Controller Removal and Insertion under Power...........................................................55 7.3. Controller Redundancy.................................................................................................55 7.4. Controller Redundancy Switch-over Time...................................................................56 7.5. Safety Controllers - SIL................................................................................................56 7.6. Controller Power Supplies............................................................................................56 7.7. Controller Memory Backup..........................................................................................56 7.8. Controller Memory Expandability................................................................................56 7.9. Controller Footprints.....................................................................................................57 7.10. Cabinets.......................................................................................................................57 7.11. Warranty Information.................................................................................................57

8. Electrical Requirements.................................................57
8.1. Field Instrumentation....................................................................................................58

9. Environmental Conditions..............................................58
9.1. Indoor Installations.......................................................................................................58 9.2. Outdoor Installations.....................................................................................................58 9.3. Storage Conditions........................................................................................................58

10. Appendix A.....................................................................59
10.1. Definitions...................................................................................................................59 10.1.1. Acronyms and Abbreviations..............................................................................59 10.1.2. Terms...................................................................................................................59

Page 6 of 62

1. System Specification Overview
This specification defines the minimum mandatory requirements for the process automation system and associated software and support services. The system shall enable the users to control plant-wide applications throughout the facility, from batch and continuous processing to high-speed packaging lines within a single architecture. The architecture should also provide seamless information flow from plant floor instrumentation. The process automation system should provide flexibility, scalability and expandability when solving batch and process applications unlike a traditional closed, rigid system like a DCS. The system should allow users to incrementally implement plant automation using only the components needed. When an upgrade or addition to the system is required components should be easily added. The process automation system must include the following features traditionally associated with both a programmable logic controller such as programming in ladder logic and remote I/O architectures and a distributed control system (such as continuous and complex control, advanced operator interfaces, and sophisticated redundancy). These capabilities must seamlessly reside in the control system without the use of special gateways or interfaces. In addition, the system shall provide seamless integration of continuous, batch and safety protection control, including common software tools. The system shall be an open system composed of standards-based technology including PC platforms with a Windows operating system (supporting XP, Vista, Server 2003 and Server 2008), Ethernet communications, TCP/IP, OPC for interconnectivity of multiple systems from different suppliers, field mountable control system, remote I/O subsystem, and bus-based serial communication with smart field devices over FieldBus, HART, Profibus, DeviceNet, and Modbus networks. This specification does not include field instrumentation and management information systems.

2. System Architecture Requirements
The basic architecture of the system is based upon a distributed "client-server" structure at the supervisory network with physically and functionally distributed controllers performing the real-time control and processing operations and separate workstations and clients providing the human-machine interface (HMI) functions. All of these elements are to be interconnected via Ethernet with TCP/IP networking software. The client server structure of the system shall make it possible for the system to operate even if several components are out of service. Interface with Field devices should be through dedicated non-Supervisory Networks and support both classic signal conversion I/O as well as Smart Instrumentation and Industrial control devices. The system shall not have a centralized architecture wherein a (redundant) central computer is required to support the overall system operation. The real-time data processing, calculation and alarm and display functions can be in a single controller or distributed

Page 7 of 62

across multiple controllers. The system shall use a distributed architecture so that no single failure will disable the total system. Plus, the user shall be able to elect that all or portions of the system be made redundant, to provide the highest levels of system availability. The local and wide-area network potions of the system shall be compliant with Ethernet and TCP/IP specifications. The system architecture shall allow for the use of both LAN and WAN technology in the same system. The system shall support all media forms of Ethernet including copper and fiber optic.

2.1.

System Scalability
The system must provide the highest degree of scalability possible so users only buy what they need – open, scalable, and distributed. It should provide scalable controllers and I/O all with a common design environment in addition to a scalable HMI solution again with a common design environment. The need is to provide a highly integrated control system across different control platforms and enable the control capability to expand from a few loops to thousands.

2.1.1. Controller Capacity
System shall include specification for control network capacity. If differences exist (in the maximum number of controllers allowed) between redundant and non-redundant configurations, vendor shall provide explanation.

2.1.2. I/O Network and I/O Capacity
System shall include specification for maximum I/O limitations for controllers. This should include maximums for control networks, I/O networks, and I/O module (local and remote I/O, SCADA, and industry-standard control networks.).

2.1.3. Controller Application Capacity
System shall include specification for controller application capacity. This should reflect both single programming language applications as well as cases involving a mix of control application strategies. If differences exist (in the maximum number of controllers allowed) between redundant and non-redundant configurations, vendor shall provide explanation.

2.2.

System Redundancy
The system shall be of a highly reliable design and shall have an operational availability in excess 99.5% (i.e., annual downtime of less than 44 hours per year). Operational availability shall be considered to be met when no more than three operator stations or controllers, in any combination, are inoperable. The system design shall provide for nondisruptive repairs of faulty equipment and on-line, non-disruptive field expansion of the system. Redundancy shall be system based and modular. This is to provide for selection and implementation of

Page 8 of 62

redundancy as needed both during the development and operation of the system. This is not limited to but includes redundant servers (database), controllers, and communications networks. (Controller and I/O redundancy is covered under the Controller and I/O section of this document). This redundancy should be capable of being implemented on-line and without disrupting the system operation.

2.3.

System Expansion
The system shall be constructed to permit implementation and system expansion in a phased fashion, where the initial system implementation may be quite small. As requirements grow, the system shall accommodate the addition of HMIs, front-end computers and field devices, all without performance degradation. The system shall support field extension of its network, addition of gateways to the network, addition of controllers and remote I/O where required, and integration of PLCs and computers into the system.

2.4.

Software Revisions
Application software shall not require modifications in order to be able to run under new releases of the system operating software. Any new release of system software shall be backward compatible with files created using the previous software releases.

2.5.

System Sever
The system shall be capable of running a pair of similarly configured servers/workstations in a redundant configuration where at any point in time, one is the acting Primary and the other the acting Backup. An on-line database duplication mechanism shall be available. It shall be possible to remove one of the redundant servers for maintenance without interrupting operation, and upon its reinstatement, re-synchronize the databases via a push-button on the screen, again without interruption to system operation. A simple method of manually initiating a fail-over shall be provided to assist with such maintenance operations.

2.5.1.

HMI Server
The HMI Server is to store HMI project components (for example, graphic displays) and serves them to system wide operator workstations thereby removing the need to create duplicate copies and maintain them for multiple operator workstations.

2.5.2.

Data Server
The data server links networks and devices to system wide visualization and development components such as HMI clients and engineering workstations. It shall provide Page 9 of 62

communication services between applications and devices on the plant floor allowing users to read, write, and configure values in plant floor devices, such as sensor readings and other system controller data. Data servers shall be configurable to run on both a primary computer and a backup computer. The system should automatically switch to a backup computer if communication with the primary computer fails. The servers should handle failure detection and failovers automatically for all components (clients) of the system. In a traditional system (DCS), each client must independently monitor connections, detect communication failures, and switch between backup and primary computers. This is not preferred.

2.5.3.

Alarm Server
This alarm server alerts operators to critical alarm conditions and maintains a record of alarm status for historical access.

2.5.4.

Domain Server
A domain server is to be available that the system utilizes to manage highly distributed systems.

2.5.5.

Security Server
An available security server should protect against unauthorized use but still allow authorized users to use the system efficiently. The security is to be a centralized system which restricts access to system resources based on key security components. The security server shall have the capability to have either control-system local users/groups or domain-linked users/groups and the ability to use an existing domain. The key components that are to be securely managed by the security server are: • Users and groups of users • Actions, such as read, write, update, and download which can be performed on a secured resource. • Defined objects in the system, such as areas, data servers, graphic displays, control networks and devices, and so on, for which actions are allowed or denied. Each piece of the system can define its own set of securable resources and actions. • The computers or groups of computers from which actions can be performed on a secured resource.

Page 10 of 62

2.5.6.

License Server
Electronic software licenses for components are to be managed by a software license server. Software licenses for engineering workstations and for operator interface consoles shall be independent of the type and mixture of I/O used (analog vs. discrete, input vs. output). The software licenses (both runtime and engineering) shall be portable allowing the operator to transfer licenses from one PC to another without requiring intervention from the vendor. To help minimize the risk associated with changes in project scope, if software is licensed on a tagby-tag basis, the vendor shall supply in writing details on how the required software license would change if the system I/O was increased or if the mix of system I/O was modified.

2.5.7.

Historian Server
The system shall have available if needed a historian server that performs process data collection from the control system. There should be included a user configurable data collection functions defining what data is to be collected and under what circumstances it is to be collected. Users shall be capable of accessing historical data. When the system is configured, and as it is adapted over time, it shall be possible to define classes of information that should be retained, as well as specific system-level data that should be collected. As with process historical data, this data shall be accessed for viewing and for reporting.

2.5.8.

OPC Server
The system must allow for 3rd party connectivity to the system controllers and to the HMI Server via an OPC interface. This open connectivity shall follow the OPC Foundation's standards to get information to or from the system. If the system is configured for redundancy, OPC communications must continue even in the event of a HMI or data server failure, without any extra work required from the 3rd party OPC client.

2.5.9.

Batch Server
A Batch Server must manage batch resources, support batch production and include system failure detection and recovery, and provide system and production communication functions. It should gather and record system and production information into a batch event journal for reporting and archiving.

Page 11 of 62

Functions of the batch server should include transforming configured recipes into executable recipes, allocating resources based on recipe requirements and, if applicable, operator input, Managing equipment selection for recipes that require use of the same equipment in two different parts of a recipe, preventing deadlock conditions. An arbitration mechanism should also allow operators to assign equipment to a particular batch (e.g. acquire ownership of an available resource and assign its use to a particular batch), preventing its allocation to another batch. If parallel steps require the same dedicated resource, the system should automatically determine how the resources are allocated among steps when the batch is run, based on criteria established by the user. The batch server should support redundant storage. During runtime, it should continuously journal all actions to one or multiple disk drives, so that data can be fully recovered in the event of control system failure. In the event of a primary server failure, the batch server can be re-started on another secondary machine and should return to the previous locations in all active recipes.

2.6. System Services
2.6.1.

System services are services that are utilized across all of the system components.

Distributed Data
Data in the system is to remain distributed in its original, native environment (e.g. the controller). The data should be distributed, not duplicated or copied throughout the system allowing resources (tags, displays, alarms and events, security settings) to be defined once and shared throughout the system. The data should be available immediately to every piece of the system with each being able to locate, browse, and organize the data and services needed. Resource changes within the system update immediately across all pieces of the system.

2.6.2.

Directory Service
There should be present a directory of factory resources such as data tags, HMI displays, and other plant floor objects that acts as a lookup service for the data rather than a single, common database. The directory should be a service that should provide a searchable reference to data resources stored anywhere across the system. It shall provide the benefits of a common database without a possible single point of failure.

Page 12 of 62

Resource names are to be separated from the physical locations where the resources reside. For example, changing the location where a data item is stored should not change its name, and as a result, should not change access to the data item. Users should be capable of building complex distributed systems offsite and later deploying the systems at other locations by simply changing the names of the computers where the data servers and HMI servers reside. The individual tag and other resource names are to remain unchanged. Likewise, a deployed program can be moved to a workstation, modified, and then redeployed. In addition, separating the names of data items from their locations also makes implementing redundant systems much easier.

2.6.3.

Alarms and Events
When alarms or events occur in the system, operators are to be quickly alerted of the conditions which require immediate action. Alarms and events are to be detected at the controller level ensuring accurate identification of alarm sequences, reduced network bandwidth requirements, and improved overall system performance. Since the alarm state is to be managed in the controller itself the state should not be not lost if the HMI servers fail. Alarms triggered anywhere in the system shall be capable of being viewed and acknowledged from any operator workstation in the system.

2.6.4.

Security
Centralized access control should be provided by verifying all user identities, and then by either granting or denying each user’s request to access features and resources within the system.

2.7. Networks

The system should utilize the Common Industrial Protocol (CIP) to move data seamlessly throughout the system. Multiple physical networks, including the plant, supervisory, control, and device networks should appear as a single network making communications efficient.

2.7.1.

Network Management
Network Management is to provide the ability for the system to support and manage system wide communications. This shall include: Networked field devices Scheduled and unscheduled I/O control networks Peer to peer control between controllers Supervisory control data exchange between controller

• • • •

and OI

Page 13 of 62

• • •

Supervisory control between controller and Batch Management Data collection for trends and historians Production data transfer between the system and Plant MES software

2.7.2.

Supervisory Network
The open technologies of Ethernet and TCP/IP shall be utilized for communication between the control system server and the operator stations. The control system server and its associated operator stations must be capable of connecting to two fully independent Ethernets run in parallel. No repeater or bridge connection between the Ethernet is acceptable as a means of achieving this function. This Network shall be used for connection of Servers, Workstations and Clients to the controllers.

2.7.3.

Control Network
The process control network/remote I/O network is used to connect the controller to field (Remote) I/O and shall be an open, flexible, high performance network.

• • • • • •

These networks shall have the following capabilities: Inherently designed to provide redundancy Capable of providing control loop updates within 1 sec Deterministic delivery of process data Completely open standard with no proprietary content A producer/consumer network model to optimize network bandwidth Communications processing on the network card to ensure network traffic will not affect server or controller performance

2.7.4.

Control Network Redundancy and Alarming
Failure of any supervisory system shall be announced audibly and visually via the alarming subsystem. To ensure maximum reliability, communications shall be redundant. The communications system shall be capable of sustaining loss of one media channel without loss of data or performance degradation. The Bidder shall include the typical data throughput of his communications system, in baud rate and number of analog values per second. Loss of communications shall not cause loss of control at the local subsystems. Also, loss of a local subsystem (either a

Page 14 of 62

single node or both of a redundant pair) shall not cause the loss of network communication.

2.8. I/O

The system should interface with field devices in two ways, via standard I/O, and through intelligent field devices. The system should offer I/O products for virtually every application need, from analog or digital I/O that can be distributed in cabinets and machines around the application or integrated with the controller itself.

2.8.1.

Analog I/O
The analog I/O modules perform the required A/D and D/A conversions to directly interface analog signals to processor data values using up to 16-bit resolution. Analog I/O can be user-configured for the desired fault-response state in the event that I/O communication is disrupted. This feature shall provide a safe reaction/response in case of a fault.

2.8.2.

Discrete I/O
The system must support discrete I/O modules which have digital I/O circuits that interface to on/off sensors such as pushbutton and limit switches and also to on/off actuators such as motor starters, pilot lights, and annunciators. The discrete outputs are directly controlled by the state of corresponding processor data bits and the discrete inputs directly control the state of corresponding processor data bits.

2.8.3.

High-Speed I/O
System shall provide high-speed discrete and analog control for plant automation applications such as material handling and packaging equipment which require the ability to perform submillisecond control. System controllers should also support event tasks which provide event driven control for applications that require interrupt driven or deterministic input to output processing. These system capabilities are vital for complete plant automation requiring raw material handling with highspeed conveyors and finished goods packaging on high speed motion applications.

2.8.4.

Chassis Based I/O
Chassis-based I/O shall provide high functionality field device interface capabilities to the system. Networks supported by chassis-based I/O include DeviceNet, EtherNet, and ControlNet. Chassis-based HART device interfaces, analog input and output are available with the option of each channel being set

Page 15 of 62

to voltage, current or current + HART. This shall provide a versatile communication option which is HART compliant and utilizes standard wiring / terminal blocks.

2.8.5.

Distributed In-Cabinet I/O
Highly distributed I/O shall be supported throughout the system including rail-based distributed I/O. Distributed incabinet I/O must support EtherNet/IP communication. The distributed In-Cabinet I/O is to be offered in modular and block I/O styles. Modular I/O is a system of interface cards and communications adapters that interface directly to the sensors and actuators of the machine/process and communicate their status to the controller via a communication network.

2.8.6.

Distributed On-Machine I/O
The system should offer distributed on-machine I/O which is locally mounted allowing for high-speed dedicated machine control. Networks supported by distributed on-machine I/O are to include EtherNet/IP. Distributed On-Machine I/O is similar to Distributed In-Cabinet I/O but should not require an additional enclosure for environmental protection allowing for much easier maintenance and troubleshooting. It is the placement of system I/O directly on a machine rather than housing the I/O in a remote, central cabinet. Distributed OnMachine I/O shall provide high-speed dedicated machine control which should reduced wiring and system costs, improved Mean Time to Repair, and enhanced control system reliability.

2.8.7.

Intrinsically Safe I/O
Distributed I/O should be capable of meeting the intrinsic safety requirements for operation in hazardous locations. I/O modules with intrinsically safe barriers built into the I/O are to be available. These I/O can be distributed in hazardous areas without the use of bulky explosion proof or purged enclosures which are expensive and difficult to maintain. The I/O should have built-in galvanic isolators which reduce terminations and the size of cabinets.

2.8.8.

Conformally Coated I/O
An option to provide conformally coated system I/O modules that contain protection against corrosive elements shall be available. The conformal coatings are to be 1-2 mil thick polymeric films which cover or encapsulate the printed circuit assemblies. Though generally undetectable by the naked eye, the conformal coatings are to protect the assemblies from airborne contaminants and corrosion by sealing out the

Page 16 of 62

contaminants and humidity. This should allow the conformally coated I/O modules to function in corrosive areas where the normal I/O modules can not.

2.8.9.

Adding or replacing I/O Modules Online
I/O modules should be capable of being added while system controllers are online. The ability to add I/O online should make it much easier to make system I/O changes to the system without affecting the entire system since the controllers do not have to be taken offline to do so. It shall not be necessary to remove power or field wiring to replace an input or output module.

2.9. Field Device Interfaces and Device networks

The system shall be capable of utilizing these open networks to interface controllers directly to intelligent field devices: DeviceNet, Foundation Fieldbus, HART and Profibus. The system shall support a wide assortment of digital process control instruments including liquid analysis, level, flow, pressure and temperature measurement instruments.

2.9.1.

DeviceNet
DeviceNet should be an open, low-cost option the system uses to connect to industrial devices and to eliminate costly and timeconsuming hardwiring. Direct connectivity improves communication and shall provide device-level diagnostics not available or easily accessible through hardwired I/O interfaces. Because DeviceNet uses a trunk line/drop line topology, a single DeviceNet cable shall provide power and communication signal to all devices on the network. This significantly reduces the amount of wiring required and greatly simplifies installation. DeviceNet shall provide the system controllers with a direct network connection to low-level devices with increased devicelevel diagnostics allowing for troubleshooting, trending and improved data collection from each device. Explicit Messaging shall be supported in the DeviceNet scanner module so configuration, diagnostics, and status can be read or written from a device on the network by the controller. Automatic Device Replace (ADR) shall be supported in the DeviceNet scanner module, so that when a DeviceNet capable device is replaced on the network, its configuration will be automatically refreshed to the replacement, by the scanner.

Page 17 of 62

2.9.2.

HART I/O
Designed to complement traditional 4-20mA analog signaling, the HART Protocol supports two way digital communications for process measurement and control devices. Analog input cards shall support HART protocol. The inputs shall allow for 4 HART variables and should work with any HART compliant field device. It shall be possible to re-range the HART device from the system and for the system to reflect re-ranging of the device performed via a handheld. Other HART information shall be capable of being communicated through the I/O cards to maintenance packages Addition of any HART I/O module must be accomplished with out the disruption of the system. This includes the physical insertion of a module while the rack is powered. The system shall be able to read all variables provided by the field device without the need for any additional wiring. The system should provide direct access to HART instruments via the Control and I/O development software. Access to HART instrument variables shall be available through controller tag data structures and configuration and calibration should be accomplished via instrument profiles.

2.9.3.

Foundation Fieldbus I/O
Foundation Fieldbus networks shall be available from dedicated interfaces directly to the controller. The vendor shall provide intelligent, self-diagnosing linking devices based on Foundation Fieldbus standards. The HSE/H1 (High Speed Ethernet / Fieldbus H1) linking device shall be able to support up to four H1 segments. The linking device shall allow dual, concurrent communications with HSE and EtherNet/IP (or Controlnet). This will allow the use of EtherNet/IP (or Controlnet) for discrete and process applications and/or HSE for process and asset management applications on the same network. The system shall support all field devices certified by the appropriate standards body for Foundation Fieldbus and shall not require additional approvals by the vendor of the host system. The system shall be able to read all variables provided by the field device without the need for any additional wiring. Diagnostic information shall be available from the field devices, including device faults,

Page 18 of 62

configuration faults, maintenance requests.

operating

mode,

and

The system shall provide direct integration and access to Foundation Fieldbus devices, including configuration and scaling, via the Control and I/O development software.

2.9.4.

Profibus I/O
The system must support Profibus networking, an open, digital communication system with a wide range of applications, particularly in the fields of factory and process automation. The system shall be capable of integrating directly to a Profibus PA network via Ethernet (without requiring DP masters or couplers). The system shall have an option to connect to Profibus DP networks via interface cards that fit the system form factor of the processor and I/O racks.

2.9.5.

Intelligent Device Management
Software that is able to configure all intelligent field devices in the plant, and support the user in managing them, is to be available. It should be based on the FDT/DTM standard, as this technology provides engineers with the freedom to integrate field and communication components supplied by all complying third parties. ControlNet, EtherNet/IP, DeviceNet, HART, Profibus and other field devices that support the Field Device Tool (FDT/DTM) standard interface specification, including actuators and transmitters should be capable of being managed by the system.

3. System Configuration, Visualization and Maintenance
This section specifies the configuration and visualization of the Engineering and Operator Workstations and supporting engineering software.

3.1. Engineering Workstation

The engineering workstation shall be designed to support all operational, engineering, maintenance, and configuration functions. Users shall be able to access the entire control system from a single location without custom programming.

Page 19 of 62

3.1.1.

Engineering Workstation Configuration
The system is to utilize an Engineering workstation configuration that complies with the following general configuration requirements: • The engineering workstations shall employ standard PC technology with state-of-the-art hardware based on a Windows operating system (XP, Vista, Server 2003 and Server 2008) and industrial Ethernet communications. Thin clients utilizing terminal services shall be available. It shall be possible to install more than one engineering workstation in a system. The engineering system shall be an open system allowing, for example, project data from Microsoft Excel to be imported. Storage media shall be provided at each engineering workstation. It shall be possible to save configuration data on both removable and non-removable media for back up purposes without taking the system off-line. The engineering software shall employ an intuitive MS Windows explorer style interface, which will allow the engineer to manage all aspects of the controller, HMI, network, hardware, and field device configuration.

• • • • • •

3.1.2.

Engineering Workstation Functions
Only one engineering workstation shall be necessary to perform all of the traditional configuration tasks (Control, HMI, Batch, and History), intelligent device configuration (transmitters, drives, analyzers, etc.), database generation, and editing. However, it shall also be possible to use multiple engineering workstations simultaneously for this work. The central engineering workstation shall be capable of supporting all of the following functions: • • • • • I/O configuration DCS hardware configuration (controller, operator stations) Configuration of plant and field communication networks intelligent device instrument configuration and maintenance Configuration of Drives, Weigh scales and Motor Management Equipment

Page 20 of 62

• • • • • • • • •

Configuration of continuous and sequential control operations Configuration of the plant process structure/hierarchy, for example, compliant to S88. HMI Graphics display generation and modification Configuration of historical and real-time trends Management of alarm and event configuration Report creation, generation and modification Configuration of operator security and access privileges Batch Configuration and Planning (Recipes, Procedures, Formulas, etc.) A controller simulator tool to enable logic debugging and testing without requiring any hardware.

3.1.3.

Reusable Applications
The system shall include mechanisms to manage reusable application designs. The library management function shall be shared or common among applications used to create and manage engineering configurations, relative to control strategies, displays, quality, reports, calculations, recipes and procedures. • • • • • • Library objects shall be available, on-line for reuse. Library objects can be locked, such that they cannot be modified. Library objects may be encrypted to protect proprietary application design information. Library objects shall be retrievable and editable in an organized manner. Documents or objects can be checked out from the library, reviewed and edited. Edited documents can be returned to the library i.e. checked in

3.2. Operator Interface Configuration

The system is to utilize an operator station configuration that ensures the right information can be viewed at the right time. Some of the operator interfaces supported by the system are to include: message displays, graphic terminals, portable HMI’s and industrial computers and monitors. The configuration, which should offer a common look and feel from an operations viewpoint, should be completely scalable spanning local, machine-level systems to highly distributed, supervisory-level applications.

3.2.1.

Graphical Display Editor
Provided should be a full-featured graphics editor that includes a complete set of drawing objects and sophisticated drawing

Page 21 of 62

tools and customizable toolbars, object animation and command wizards. The editor’s application tree shall provide users with a visual picture of an application. It shall let users see and explore all the components of the system and make it easy to add, modify and remove components, and also allows users to browse and access tags stored in controllers and other data servers. The display editor should support, but must not require, a custom scripting engine such as Visual Basic for Applications.

3.2.2.

Graphic Displays
The system shall permit configuration of custom graphic displays. These displays shall be accessible through assignable user accounts, and using the standard system operator display navigation functions. Revision of an existing display shall result in automatic updating of any display servers in the system scope. The system shall provide detailed documentation of tags used on custom graphic displays. System shall support designation of custom graphic displays to process areas for purposes of alarm navigation. Graphical displays should be capable of being: • Created in a supplied graphics display editor. • Dragged and dropped from a graphic library. • Created by another Windows® application, then copied and pasted into a display or inserted using Object Linking and Embedding. • ActiveX® objects embedded in the graphic display. • Graphic display information can be exported to and imported from an XML file. A library of the following graphical objects should be included: • Push buttons, macro buttons, ramp buttons • Numeric display and numeric entry objects • Control List Selector • Numeric and string pop-up scratchpads and keypads • String display and entry enable • Local message display • Alarm, diagnostics log, and information message objects • Time and date objects • Display navigation objects • Navigation keys • Login, Logout, and Shutdown buttons • Symbol and multi-state indicators

Page 22 of 62

• •

Gauges, bar graphs, scales, and trends Alarm banner, alarm list, and alarm status list objects

3.2.3.

Standard Faceplate Library
A library of standard pre-built process control HMI faceplates and symbols shall be available. Optional Industry specific libraries shall be available. The standard HMI library shall consist of the following preengineered symbols and faceplates at a minimum:

• • • • • • • • • • • • • •

Standard PID Controller CASCADE PID Controller Ratio Controller Split-Range Controller Manual Loader Totalizer for Solids and Liquids Digital Value Monitoring with Alarming Analog Value Monitoring with Alarming Motor (Start/Stop) with Interlocks Motor – Two Speed Motor – Forward/Reversing Valve (On/Off) with 1 or 2 Feedback Signals Valve (On/Off) with Interlocks Motorized Valve Control

3.2.4.

Integrated Batch Visualization
A library of standard pre-built process control HMI graphics with integrated batch views shall be available. The standard HMI library shall consist of the following preengineered graphics at a minimum: • Batch Overview Display • Batch Unit Display • eProcedure Displays • Material Manager Displays

3.3. Operator Interface Visualization

Operator stations shall be capable of being implemented with multiple monitors and screens so that the operator can have many display pages active at once. In this configuration the cursor positioning device (mouse, track ball, etc.) and keyboard shall be automatically shared and switched to the selected window on the selected monitor. Transition between windows and screens shall be instantaneous and user-transparent. Operator options shall include cursor control devices such as mouse or touch-screen. The normal operations shall be via the Page 23 of 62

standard QWERTY keyboard of the workstation manufacturer and no other keyboard shall be required for operations.

3.3.1.

Operator Station Redundancy
The system is to support redundant HMI servers, data servers, and networks. This is to ensure that the data the operators are viewing is always up-to-date. To maximize data availability and integrity, the Operator Station shall provide the ability for configuration of system redundancy. This shall in no way limit or restrict the use of the client/server configuration and/or architecture. Clients shall automatically failover to the backup or redundant server. This operation shall not require any application reprogramming or reconfiguration. Client stations shall support the designation of different primary servers allowing the network loading to be distributed and to ensure that in the event of a failure not all clients will experience a switchover.

3.3.2.

Operator Station Security
The system shall ensure Operator Station security by authenticating users against a set of defined user accounts and access privileges. Project-level security should also be supported by the system. Levels of security can be assigned to operator interface commands, macros, database tags, and graphic displays. Combinations of these levels can be assigned to individuals or groups of users, giving them different access to different features. Operator interface security can also be configured to require user authentication for critical operations, such as set point changes and recipe downloads. Operator activity and system changes are to be logged for later review.

3.3.3.

Area Security
Each operator shall be assigned one or more specific areas of the plant with the appropriate monitoring and control responsibility. An area shall be defined in this context as a logical entity comprising a set of control modules in the system. This in turn may represent a physical space in the plant or factory. It shall be possible to define individual operator access by means of area assignment. An operator shall only be able to view or control those control modules within the assigned areas. Each Action taken by an operator shall be allowed if and only if the operator is assigned to the function and approved by security level to execute the function, at that particular time, in that context, from that location.

Page 24 of 62

3.3.4.

Alarm Window
A dedicated alarm line, or Alarm banner, shall appear on all operator displays showing either the most recent unacknowledged alarm in the system. The line shall be clear when there are no unacknowledged alarms for the operator to process. Each graphic display shall also be linked to an Alarm Summary graphic that allows for a configurable sort or filter by priority, and grouping of alarms. On occurrence of an alarm, the graphic display shall output the point identification, point type and point description on a dedicated line. If multiple alarm/change of state conditions occurs, subsequent messages shall overwrite the display if they are higher priority. As subsequent alarms are displayed, the previous alarm information shall move to an unacknowledged alarm list awaiting acknowledgment by the operator.

3.3.5.

Faceplates
The system should include pre-built and tested graphic faceplates for control functions such as PID, totalizers, multistate devices, motor starters and drives.

3.3.6.

Time Synchronization
The Operator Interface shall be capable of synchronizing it’s time with the control system so that there is no more than a 20 msec deviation between input/output events in the field and being time stamped at the HMI level. The System shall support connection to a highly accurate time source such as GPS (Global Positioning System) or DCF77 which can be used as the time master for the system. Date and time synchronization shall be possible anywhere in the world using a satellite source such as GPS (Global Positioning System).

3.4. Alarm and Event Management

The system shall support a comprehensive alarm detection and management facility to allow fast and accurate notification to the operator of abnormal conditions within the process. Alarm monitoring shall be extended to calculated values and SCADA input values handled by the system. Alarm monitoring shall also be extended to diagnostic values monitored by the system. Monitoring of source values and analyzing for alarms shall take place as close to the original source of data as is practically possible. This software will be responsible for monitoring the process measurements and status inputs and advising the operator when alarm conditions are detected in these measurements and status inputs. Alarm (and event) annunciation, acknowledgement, and related functions shall be able to be associated with an individual, responsible operator, user, or group of users. In this way, operators and users may have their view of points or tags in

Page 25 of 62

alarm restricted to only those alarms associated with points for which they have been assigned responsibility. This will help to reduce potential confusion caused by exposing an operator to alarms over which the operator has no control. When points or tags are assigned to an operator, or group of operators, only the responsible operator(s) shall be permitted to acknowledge or clear the respective alarms. The interface to the appropriate user for alarm presentation and control shall be via the operator’s standard navigation screen or specific windows, either dedicated, or "pop up" (or both). The operator shall have the option to retain an alarm manager window on his screen at all times, or may invoke the alarm manager screen as required. Invocation of the alarm manager screens shall be user configurable and shall include designation of alarm groups and "filter" criteria for the display (e.g., tag, equipment reference, operator, time window, batch, process unit, and process area).

3.4.1.

Alarm Priorities
The system shall support the ability to configure all alarms based on their level of seriousness relative to impact on the operation of the process or system. The system should support at least four alarm priorities. These priorities are to be configured as part of the control function blocks as follows: • • • • Urgent High Medium Low

Each alarm type shall be individually able to be prioritized into one of the above categories. Urgent, High, Medium and Low priority alarms shall be displayed as such in the system Alarm Summary. Audible Alarm and Alarm Paging An audible alarm shall be configurable for each of the above alarm priorities. Alarms shall be routable to external alarm hardware (via system I/O) and/or directly to the operator HMI. If enabled, the annunciators on the operator station shall sound. The operator station shall be able to use multimedia technologies (such as .wav files and sound cards) to provide realistic alarm annunciation. . The system shall have the capability to send alarms directly to pagers and email addresses via third-party (Win911) software.

Page 26 of 62

3.4.2.

Alarm Detection
Configuring a function block alarm in the controller shall automatically cause the system to perform the following actions when an alarm occurs: • The alarm shall be time stamped to a resolution appropriate for the location within the system at which the alarm condition is monitored or detected (e.g., the nearest second in the HMI, the nearest processing cycle timestamp when in the controller or field device). The alarm shall be logged in the Event Database with the Point Name, Alarm type, Alarm Priority, Point Description, and new value The PV of the alarm shall turn to a presentation format (color, object display) associated with the level and priority of the alarm (e.g., red and flash) on any standard or custom display which uses the point An Unacknowledged alarm entry shall be made in the system alarm summary for Low, Medium, High and Urgent Alarms or events The audible alarm shall sound (if configured) The alarm annunciators indicator shall flash until acknowledged Once the alarm is acknowledged and has been reset the alarm will be cleared from the alarm summary

• •

• • • •

3.4.3.

Alarm Acknowledgment
In addition, the alarm zone of the operator interface shall show this alarm provided it is the highest priority, unacknowledged alarm in the system. The system shall provide for efficient alarm acknowledgment in a number of ways as follows: • Selection of any parameter tag for the point in alarm from a custom graphic and pressing the dedicated acknowledge push-button • Selection of the alarm in the system alarm zone and pressing the dedicated acknowledge button • Selection of the alarm in the alarm summary display and pressing the dedicated acknowledge button • By performing a page acknowledge from the alarm summary display On acknowledgment by the operator, the flashing indicator shall turn to a presentation format designated for acknowledged alarms (e.g., acknowledge color, steady, not flashing), and the parameter shall remain in that presentation format on any Page 27 of 62

system or custom graphic. Should the point go out of alarm before being acknowledged by the operator, the alarm shall be shown by a designated presentation format and remain in the list until specifically acknowledged by the operator. Alarms shall be configurable to be annunciated by: • Alarm message appearing on dedicated alarm line on operator interface • Alarm message appearing on alarm summary display • Audible Tone (either using the PC Speaker or a sound card) • Alarm annunciation shall take advantage of multimedia technology by providing realistic alarm sounds (via .wav files). Alarms shall be annunciated at the station even if there is no operator currently signed-on. This feature shall be available on network connected operator stations as long as the computer running the operator station software remains logically connected to the network.

3.4.4.

Alarm Logging
All new alarms shall be configurable to be logged on all alarm/event loggers, written to a disk file in a readable file format, placed into the active alarm summary display window and audibly annunciated.

3.4.5.

Alarm Navigation
The alarm manager "pop up" support window shall include the ability to have the alarm manager present the operator with an immediate means of going directly to the display page which is required to investigate the source of the new alarms. If a series of new alarms are received at the operator station, and all of them happen to be associated with the user-defined alarm group, the pop-up window shall be pre-set to immediately call up the graphic display page for that group.

3.4.6.

Alarm Archiving
Alarm management functions, including archive recording of alarms and events, the recording of operator acknowledgement of alarms, the enable and disable of point and group alarming, plus the annunciation and logging of alarms, shall be provided at all operator stations.

3.5. Trending

The system shall support three levels of trending: real-time trending, short-term historical trending, and archive/retrieval of short-term trending for indefinite

Page 28 of 62

periods. System graphics/display builder shall include the creation of "trend windows" which can be used to pull real-time values from the system and plot them vs. time on the screen. The trend windows shall be assigned to selected variables in the database, including measurements, calculated values, manually inputted data, and binary (discrete, state-based) values. Operator workstations are to be capable of displaying both historical and current tag values using trends. At runtime, when an operator opens a graphic display containing a trend object, the data displayed in the trend can be real-time or historical. A data server collects real-time data for the trend and historical data comes from a data log model. Two types of trend charts are to be available. A standard chart plots tag values against time, whereas a XY plot chart plots the values of one or more tags against another tag. For example, the temperature of a tank could be plotted against time with a standard chart or against the pressure of the tank with a XY plot chart. • Every operator workstation shall provide viewing for real-time and historical trend information. Data collected in any historical package shall be available to all workstations. The system must support a centralized approach to historical data collection. The system shall support operator defined sets of trends so that commonly viewed historical information can be defined in trends once and easily accessed by selecting a pre-configured screen target incorporated in the graphic display. There should be no practical limit to the number of trends that can be defined. Each trend screen shall support up to eight (8) separate pens. Selection of points to be trended shall be menu driven. Historical trends shall support seamless integration of both real-time and historical data within a single trend window, with seamless movement between the two. In the event that the screen should be scrolled to the left, then historical values will be recalled from historical data files. Scrolling the trend far enough to the right will result in current realtime data being displayed as it should be collected. Zoom in/out and moving forwards and backwards in time shall be possible with no more than two operator actions. A mechanism for selecting a location on the trend, such as a hairline cursor and reading the numeric values of the trends at that point in time shall be provided. It shall be possible to call up new historic trends and configure them online from the Operator Interface. Pre-configured real-time trends shall be available from a faceplate.

• •

3.5.1.

Trend Data
The trending shall be configurable for dynamic updates at a user-defined rate. Real-time trending shall have no "history" and shall operate like a chart recording that is "turned on" when the display graphic is initiated.

Page 29 of 62

The control system shall provide trending capability with the following functions: • Real time trending • Historical trending • Archived History trending • Trend Scrolling • Trend Zoom • Trend screen in Engineering Unit or Percent • Cursor readout of trend data • Trend comparisons between archived, real-time and historical data (for example, this year vs. last year, this batch vs. last batch). Comparisons between the same point offset in time, or different points must be possible. • Trend De-cluttering via per-pen enable/disable on multi-plot style trends • Independent Y-axis per point on multi-plot style trends. It shall be possible to display the Y-axis for any point on the trend by simply selecting the point using the mouse or keyboard. • Copying the currently displayed trend data to the clipboard for pasting into spreadsheet or document • Operator controllable X and Y axis scaling

3.6. Reports

Reporting software that allows end users to configure Web-based dashboards, trends, and reports is to be available. It should include standard, pre-configured reports for managing devices, equipment, alarms, events and control loops, as well as batch or production run and shift reports. The application is to include trending and dashboard capabilities for analysis and uses Microsoft Excel for report generation. In addition to gathering data from control system, the reporting software should feature third-party connectors that address native and OPC DA real-time devices, and OSI PI Historians. The system shall also support a number of simple reporting options that allow users to report critical data. Reports that can be configured as graphical displays and then printed, created using VBA within the operator interface development software, or created via third-party software such as Microsoft Word, Microsoft Excel and Crystal Reports are to be supported. • • The Operator Interface shall provide an integral reporting subsystem used to report both current and archived data. The reporting subsystem shall utilize standard a Windows tree/list view

Page 30 of 62

• •

• • •

presentation techniques for management and administration of reports. The reporting subsystem shall provide the capability to define reports for both visualization and printed format. Report templates shall be supplied which can be modified or used as should be. The reporting subsystem shall provide the capability to define both the dynamic and static properties reports, including but not limited to: archived data, alarm data, or event data. Configuration of automatic report generation, including frequency, destination of the report. The reporting subsystem shall not impose limits on the number of reports that can be configured. The system shall support the use of optional third-party applications (i.e., Microsoft Excel, Crystal Reports) for generation of reports.

3.7. Report Generation

Hourly, daily, monthly, end-of-month, quarterly and yearly reports shall be supported. Reports shall be capable of being printed and/or saved to disk when a process event occurs. It shall be possible to activate a report in any of the following manners: upon demand by operator request, scheduled (shift, daily and monthly), and upon predefined events.

4. Process Controllers
The controller shall be a multi-tasking, real-time microprocessor with the ability to simultaneously manage multiple activities. The controller shall be able to perform continuous and regulatory control on dozens of "loops" while concurrently executing safety interlock logic, as well as executing hundreds of algebraic calculations, all of which will be defined at, and down-loaded from, the operator stations. The communications network "backbone" for the controller shall be either Ethernet I/P (10 -100 Mega baud) or ControlNet.

4.1. Controller Programming Environment

The system shall utilize the same programming environment for process, sequential, drive, motion and safety control programming through out the system.

4.1.1.

Controller Editor
The system control and I/O development environment shall consist of an IEC 61131-6 and ANSI/ISA-88 compliant editor. It shall represent the multi-tasking operating system of the system controllers with a graphical tree view showing tasks, programs, phases, and routines. The logic editor shall support the creation of routines in any one or more of the following four programming languages:

Page 31 of 62

• • • •

Function Block Diagram – Graphical representation of the algorithm used to create and manage process loops. Ladder Diagram – Graphical representation similar to electrical relay circuits where rungs of logic perform sequential operations. Sequential Function Chart – Graphical flow diagram used to organize and sequence the operation. Structured Text – Textual basic like language useful for developing custom algorithms and string text manipulation.

The editor shall provide the ability to drag-and-drop to move instructions, logic, routines, programs, and tasks either within a single project or between projects to create detailed project libraries. The editor shall also have open access to various portions of projects through: • Windows® Clipboard – cut/copy/paste code and information from and to other Windows-based tools. • Import/Export Tag Definitions – the Comma Separated Value (CSV) export extracts tags for use by third-party tools such as Microsoft® Excel®. • Full Project Import/Export – this ASCII representation of a controller project shall provide access to create and manipulate the project using other text editors. • Partial Import/Export Online or Offline – The system shall support the import or export of specific, userselected portions of logic, into and out of both a running controller as well as an offline controller configuration file. Controller data tags are to be defined just once using the editor and are then are to available immediately to every piece of the system.

4.2. Controller Runtime Modifications

Controllers and their development environment must provide the ability to perform runtime modifications. This includes the creation of new data structures, tags, tasks, programs, and routines and also the addition of select system I/O modules, all while the system is fully operational. Additionally, application code written in Function Block Diagram, Ladder Diagram, Sequential Function Chart or Structured Text should be capable of being modified, tested and downloaded while the system continues to operate. In addition to being able to modify a controller’s contents while running, multiple users should have simultaneously access to a running controller. Changes made

Page 32 of 62

by one user are to be automatically propagated or uploaded to the other users project view so that each user has an up-to-date image.

4.3. Controller Restore / Upload

It shall be possible to recreate the configuration of one or more controllers after a total loss of the controller’s configuration database. Controllers shall support the upload and reconstruction of their configuration while running.

4.4. Controller Communications

The controller shall be fully functional with "peer" ability to initiate communication transactions among other controllers, and with operator stations, gateways and other computers on the LAN(s). If a controller requires a measurement from another controller or gateway, it shall merely request the owner of the measurement to begin sending value updates, as the measurement changes, until such time as the requesting controller advises that it no longer needs value updates. All data transfers from the controller(s), after the initial transmission of current value and status, shall be done on an exception basis. In order to make the best use of available LAN bandwidth, the system shall use a report by exception/alarm scheme.

4.5. Control Strategy Development

As a minimum the controller should contain continuous, discrete and sequential control functions. Associated controller logic (such as a regulatory loop) should be able to be defined within a control object or control module. This control object can encapsulate the control logic and provide a means to monitor and interact with its logic as a loop. This includes, but is not limited to, cut, copy, paste, enable/disable etc. It shall be possible to schedule the execution of control modules/functions within the controller. This execution environment shall support: • Individual “control objects” comprised of user selected functions. Must have assignable execution rates of 50, 100, 200, 500, 1000 and 2000 milliseconds. All control objects, regardless of function block content, shall be able to execute at any of these rates. Note that all function blocks within a control object shall execute at the same rate. • Peer-to-peer communications that provide for the direct transfer of process data between controllers without the use of gateways or servers. • The controller “firmware” shall be capable of being upgraded on line, without stopping or upsetting the process being controlled in a redundant controller system. • A controller shall be capable of being inserted under power, without upsetting the process being controlled by other controllers.

Page 33 of 62

4.6. Controller Configuration Languages

Configuration languages shall be offered that are traditionally associated with both a PLC and DCS programming environment. These shall include the following four programming languages: Function Block Diagram – For continuous process and drive loops Sequential Function Chart – For control sequence management and batch

• • • •

process Structured Text – For custom looping and complex mathematical algorithms Ladder Diagram – For state based sequential and motion control All function types must co-exist with each other in a single controller, have the ability to interact with each other, and support online editing.

• • • • •

The system also must support: S88 State Control for complex and simple batch control applications. User defined functions for customization (Add-on instructions, User defined tags) Application-specific instructions for process, drive, motion and safety applications. ASCII instructions to manipulate string data. Message instructions to communicate between different devices.

4.6.1.

Function Block Diagram
Function Block Diagram (FBD) instructions are required provide the building blocks needed to perform sophisticated process and drive control. Control strategies can be created in a familiar way utilizing flow representations of applications. Active X faceplates can be utilized for instructions commonly used with operator interfaces (Enhanced PID, Ramp/Soak, etc.) and online visualization of FBD process data should be also supported by the system. To make it easier to navigate through a FBD routine, the system shall give the users the capability to divide the routine into a series of sheets which helps organize function blocks and makes them easier to visualize and search. This shall not affect the order in which the function blocks. In general, one sheet should be used for each device (motor, valve, etc.) System FBD routines shall automatically determine the function block execution order.

Page 34 of 62

4.6.2.

Sequential Function Chart
Sequential Function Charts (SFC) shall be available. SFC is a structured, IEC 61131-3 compliant, high-level control programming language. The SFC shall include the following features: • It shall provide the necessary facilities for real-time control of sequential processes. • It shall have access to process control and other database information. • It shall be possible to modify the program logic while other sequences are active. • It shall support execution of the chart in Manual or Automatic Mode. • It shall be possible to configure multiple states within a single SFC container. This allows for effective coordination of sequences which have more than one mode (e.g., Heating and Cooling) or that contain safestate logic (e.g., Aborting or Holding Logic) • The ability to create master SFC elements which can be copied and used throughout the configuration just like a function block. A Sequential Function Chart (SFC) is similar to a flowchart of a process. It should be a highly visual language used by the system to organize the functional specification for control systems as a series of steps and transitions. A step represents a major function of the process and contains the actions that occur at a particular time, phase, or station. A transition is the true or false condition that tells the SFC when to proceed to the next step. Step transitions and step actions shall support the structured text language for configuration of transition logic as well as individual actions for steps.

4.6.3.

Structured Text
The system should support Structured Text (ST), a textualbased control function that uses statements to define what to execute. It is a, high level programming language similar to Basic or “C” which shall be used to program complex mathematical operations that would be difficult with other control functions. Two types of expressions, Boolean and numeric, can be used in ST. Boolean expressions compare values or check if

Page 35 of 62

conditions are true or false and numeric expressions calculate integer or floating-point values. ST shall provide these benefits to the system: • If/Then, Case, Do/While, Do/Until and For/Next constructs
• Non case sensitivity

• •

Used in actions and transitions of Sequential Function Charts A Fully functional editor

4.6.4.

Ladder Diagram Ladder Diagram (LD) should be supported by the system. It should be a rung-based control function that may be utilized to develop sequential control applications such as conveyors, machine control, and interlocks. LD can also be utilized to manage motion and servo control needs and easily perform messaging and serial communications. User Defined Functions and Tags The system should support the creation of libraries of commonly used instructions and templates that can be reused throughout the control project: : • Shall be capable of being created using Function Block Diagram, Structured Text, or Ladder Diagram • Can be used in Function Block Diagram, Sequential Function Chart, Structured Text or Ladder Diagram routines. • Can be animated • Provide instruction source protection with systems word and view only or complete source locking options. • Defined once in a project and can be shared by multiple controller programs. • The number of add-on instructions should be limited only by controller memory. Users should be able to organize multiple tags of different data types into a single user defined tag structure.

4.6.5.

4.7. Alarm and Event Detection

Alarms and events are to be detected quickly so that operators can be immediately notified of critical conditions. Alarm and event detection and processing are to be incorporated directly into the controllers. Alarm and event detection features should include: Page 36 of 62

• • • • •

Alarm triggers based on analog tags, digital tags, or control function expressions Digital alarms - single state / bit detection Analog alarms – LL, L, H, HH, Rate of Change detection Configurable alarm detection options such as delay time latched, continuous or automatic acknowledge 100us distributed sequence of events (SOE) over Ethernet for high accuracy alarming and first fault detection

4.8. Process Control

Standard software algorithms shall be available to perform regulatory control functions, and these shall have easily configurable parameters.

4.8.1.

PIDE Loop Control Enhanced Proportional, Integral, Derivative (PIDE) control loops are to be supported through the Function Block Diagram and Structured Text control functions. These control functions are to be used to create continuous and batch process PIDE control loops. It shall be possible to put any individual control loop in a manual; automatic, or cascade mode. In cascade, it shall be possible to configure remote setpoints from other regulatory controllers or from other control blocks. There shall be bumpless transfer between all control modes, and windup protection shall be provided. Control blocks shall be able to perform automatic mode switching based on external or internal logic inputs.

4.8.2.

PIDE Integrated Auto-Tune A PID auto-tuner should be integrated into the PIDE instruction used in the function block language and auto-tuning can be initiated from any operator workstation or engineering station. The PID auto-tuning facility shall employ an easy-touse graphical interface with a setup “wizard” to assist engineers and technicians who are unfamiliar with the tool. The integrated auto-tuner is to be: • applicable to processes with slow and fast dynamics • used with self-regulating and integrating processes • immune to noise and process load disturbances • accessed directly from the controller

4.8.3.

PIDE Optimized Auto-Tune The system shall provide advanced open and closed loop tuning and analysis by providing PIDE control loop

Page 37 of 62

optimization from an intuitive off-line software tool. The offline modeling tool should be available so archived process data can be used to perform loop analysis. Using real data off-line should allow experimentation with new settings without compromising production.

4.8.4.

Standard Library for Controller A library of standard pre-built control algorithms for process control shall be available. The standard controller library shall consist of the following pre-engineered control strategies at a minimum: • • • • • • • • • • • • • • Standard PID Controller Cascade PID Controller Ratio Controller Split-Range Controller Manual Loader Totalizer Digital Value Monitoring with Alarming Analog Value Monitoring with Alarming Motor (Start/Stop) with Interlocks Motor – Two Speed Motor – Forward/Reversing Valve (On/Off) with 1 or 2 Feedback Signals Valve (On/Off) with Interlocks Motorized Valve Control

4.8.5.

Computational Functions The following computational functions shall be supplied as standard configurable items or simple algebraic instructions: • • • • • • • • • • • • • Addition/Subtraction Ramp generator Lead-lag Integrator/Accumulator Dead time High/low select Multiplication/Division Time averaging Signal selection switch Exponential polynomial Logarithms Square root Absolute value

Page 38 of 62

4.8.6.

Discrete Control Functions The following discrete control functions shall be supplied as standard configurable items: • Logic functions -- and, or, not, nand, nor, xor • Change of state detect • Set/reset flip-flops • Timers and counters • Comparison elements -- greater than, less than, equal to, not equal to • Multiplexer (selects one of up to 16 signals) • Positive, negative, and bi-directional edge trigger Advanced Regulatory Control The system shall support predefined advanced regulatory control function blocks. These function blocks shall be applicable to a wide variety of difficult to control situations, such as loops significant dead time, loops with multiple possible control variables, and situations significant interaction between various controls variables and process variables. Fuzzy Logic The system shall support the ability to create custom fuzzy logic based function blocks, which can be used in significantly non-linear applications. These fuzzy logic based function blocks shall be able to incorporate the expert control knowledge of operators and engineers who are familiar with the process. Fuzzy logic blocks shall not be limited in the number of variables or rules. In addition, the fuzzy algorithm(s), once created, must execute entirely in the process controller and must support on-line tuning.

4.8.7.

4.8.8.

4.9. Batch & Sequencing Control

The system shall provide batch solutions from basic sequencing to the most complex and demanding batch applications. The system shall adhere to ISA-88 standards and present a scalable batch capability that includes a controller-based state machine for local sequencing applications to more comprehensive serverbased batch control with material tracking and electronic batch records advantages. The batch solution shall: • Be open, flexible and use industry standard communication protocols • Integrated material management and recipe design. • Create and manage recipes and execute them automatically • Reduce the hours needed for validating and commissioning • Configure physical and procedural models • Integrate with a wide variety of complementary software applications

Page 39 of 62

• • •

Collect detailed electronic batch data about your process to generate detailed reports Integrate and exchange batch and recipe information with corporate information systems Simulate your entire batch process

4.9.1.

Basic Batch & Sequencing
The system shall support the implementation of simple batch production applications. These solutions might be described as applications where the entire control functionality of the batch is essentially implemented within the system controllers. If anything, only batch-to-batch formulation changes are required, and there is minimal flexibility in the usage of equipment, except when managed by operator selections.

4.9.2.

Comprehensive Batch & Sequencing
The system must support complex batch production applications. These are applications where a server-based batch production management function is required in addition to batch control functionality located within the system controllers. The server-based functionality of the system should be an open application that can interact with batch production applications located in legacy controllers or third party controllers. The system shall support S88 State Control and the ISA S88.01 standard.

4.10. Drive Control

System controllers should have the ability to control drives. The drive configuration is to be integrated with the controller software allowing users of drives to consolidate drive system configuration, operation and maintenance into a single, integrated environment. Users are to be capable of configuring both the controller and drive side of the network I/O in the controller programming software. Copy and paste programming should make configuring multiple drives effortless. The drive controllers should be capable of being programmed with instructions including: Pulse Multiplier, S-Curve, PI, Integrator, Up/Down Accumulator, Notch and High- and Low-Systems Filter, Second- Order Lead/Lag, Derivative and others. These instructions are to be programmed utilizing Ladder Diagram, Function Block Diagram, Sequential Function Chart or Structured Text. Descriptive drive tag names, such as *.AccelTime1, are to be automatically created, eliminating the need for users to manually add descriptions. The tag names are to match the drive parameter names, effectively providing standardized tags that are the same from one program to the next. The proper data types are to

Page 40 of 62

also be automatically generated for each tag, eliminating the need for users to program data conversion logic. The drive software is to include the following: • • • Startup Wizards to provide a simple, step-by-step process to programming drives. Graphs, images and descriptive text are to assist users through the commissioning process. Reusable instructions that to allow users to encapsulate their most commonly used logic as sets of reusable instructions. Preconfigured faceplates objects that can be imported into a user’s HMI display. They are to allow for operator control, monitoring of data, parameter adjustments and fault description/corrective.

4.11. Motion Control

System controllers shall provide highly-integrated motion control. The real-time communications system should be a single fiber optic ring that serves as the sole interface between control and drive. The motion control solution shall provide these important benefits: • Advanced diagnostics and process reporting via the SERCOS interface. • Wide variety of motion module options for system controllers. • Up to 16 axes of motion can be controlled from one motion module. • System should be fully expandable, with up to 32 axes supported per controller. Multiple controllers can be used if additional axes are needed. • Routines can be written in one of multiple IEC 61131-3 languages Ladder, Structured Text or Sequential Function Chart • 40 available motion instructions to handle even the most demanding motion applications such as axis moves, high-speed registration, timeand position-based camming and even multi-axis gearing • Graphical editor simplifies creation of complex motion profiles. • Graphical data capture and display allows motion performance to be monitored. • Wizard-based axis and drive configuration for easy-to-use programming.

4.12. SCADA and Third Party Connectivity

The system shall include SCADA capability to communicate with third party PLC and DCS vendors through third party OPC vendors. By utilizing these OPC connections to communicate over various networks, including Modbus, Profibus, DF1, Serial, DH+, EtherNet/IP, DH-485, Remote I/O, and others, the system shall provide the ability to log, trend and report data from the third party PLC and DCS sources.

Page 41 of 62

If required for a particular SCADA network communication, Protocol Converter Interface cards are to be supported. These are typically provided by the third party OPC vendors. The system shall be capable of communicating with third party control systems by using the following interfaces and protocols:

4.12.1.

OPC Interface The system shall be able to communicate bi-directionally with auxiliary systems using OPC. The OPC interface shall be configured in a client-server relationship. There shall be no need to write any custom code to set up the OPC interface. Configuring the OPC shall be done using drag-and-drop functionality to link the data source and target. At a minimum, the OPC interface shall support scan rates of 500 ms and 1 second.

4.12.2.

Serial Interface
The following serial capabilities shall be available for communicating to auxiliary systems: RS-232C, RS-422, and RS-485 with full and half-duplex operation, and selectable baud rates (19200, 38400, 57600, and 115200). Modbus interfaces are to be configurable in a master-slave relationship, with the system as the master and the auxiliary system as the slave.

4.12.3.

Ethernet The system shall be able to communicate bi-directionally with auxiliary systems using IEEE 802.3 Ethernet protocol at 10 or 100 MBPS, with TCP/IP

4.12.4.

Third Party PLC Communication
The system should support communication with the following third party PLC’s, including but not limited to: • • • • • • TI Square D GE Series 6 GE Series 90 Modicon Siemens

4.12.5.

Third Party DCS Communication
The system should support communication with third party DCS’s, including but not limited to: • Bailey Net/Infi90 Page 42 of 62

• • • • • • • •

Honeywell TDC 2000 Honeywell TDC 3000 Honeywell PlantScape Fisher Provox Rosemount RS3 Moore APACS Westinghouse WDPF Taylor MOD300

4.13. Controller Application Code Security

System controllers shall utilize multiple-user, multiple-level application code protection while online and offline. Controller security settings are to include: • Full controller access • Read only access • Code read and data read/write access • Read and write access not allowed • Source protection for individual routines

4.14. Process and System Simulation

The system shall support various levels of Process Simulation: Controller Simulation. A controller simulation tool shall be available which shall allow simulation of field inputs and outputs within the control logic and to facilitate testing and troubleshooting of the controller program. It shall require no control or I/O hardware and shall be capable of being used to simulate both Batch and Continuous processes. It shall not require special modifications of the actual controller program to be able to run in simulation mode. Simulation of Remote I/O. The system shall support the use of PCI cards which are capable of simulating the actual electrical signals and responses of remote I/O and Profibus field devices to an actual controller. Process Modeling. The system shall support the use of higher order Process Simulation programs that are capable of modeling the process dynamics. These programs shall be capable of making use of the actual control program for the development of the model and maximizing reuse.

• •

System controllers should be capable of being emulated in software to make it possible to test controller application code without the need to physically connect to hardware. Field inputs and outputs that are connected to system controllers should be capable of being simulated for testing a wide variety of processes ranging from discrete to continuous. An extensive user interface also shall provide the dynamic interaction needed to thoroughly test control systems and to train operators and maintenance personnel.

Page 43 of 62

5. Production Management
The system is to provide a data Historian which collects data, and reporting software that is used to display the data.

5.1. Historical Data Archiving

Data is to be collected by the historian at high speeds, in real time, and at full resolution from any controller, HMI or related manufacturing system. The Historian should not use MS SQL or Oracle to store its data (relational databases are not efficient to store time series data), but use an optimized proprietary data storage to handle large amounts of time series data. It should store them very efficiently, but also be able to retrieve the data very efficiently into trends, reports and other applications. It should be capable of handling up to 10 billion records per day, over 40 billion records per month or up to 5 trillion records per year. It must also be able to support connections to the standard databases such as MS SQL and Oracle, so that applications based on these products can utilize the data from the Historian - either through ODBC, or rather OLE DB and OPC HDA. Production data is to be turned into actionable information through comprehensive historical data archiving. Some of the key features are to include: • Complete time-series data collection • Easy, flexible, scalable configuration • Compatibility with any PLC or HMI using OPC standards • Reliable, 24/7 data collection • Data storage in an efficient, usable form • Built-in Thin Client report writer • Access to all reports with a Web browser • Dynamic modification of data collection parameters • Detailed SPC analysis • Retrieve data directly from Microsoft® Excel • Sophisticated data collection and triggering options • Standard and custom data calculators • Support for UTC time • Reports on data from external sources

5.2. Plant Data Historian

The historian is to connect to the control system, or human-machine-interface software, and collect data at high speeds, in real-time, and at full resolution. The historian is to provide the capability to collect, store, analyze, and visualize data using a powerful engine and a set of reporting tools such as time-series trends, bar charts, pie charts, trends, and incorporate an easy method of generating reports using Microsoft Excel. It shall also use compressed storage data algorithms to contain a vast amount of data in a small format, and allow retrieval of the data quickly over a short or long time span. Page 44 of 62

It shall be possible to direct the historical data collection function to collect data from multiple sources (native process data from control applications, system diagnostic values, calculated variables, soft points, and SCADA points, points accessible through OPC or ODBC mechanisms). Timestamps shall be associated with data values. Where available, timestamps shall be used from originating source of data. Where available, data quality/status shall be used from originating source of data. Data collection shall be on a polled, demand, or exception. The historian should have features to generate archives and define how the archives are generated and when the system closes an archive and creates a new one.

5.3. Historical Data Reporting

The system shall make advanced reporting available to various users of the system including plant managers, operations and even shop floor operators. Reports are to provide users with relevant up to date information that is required to perform their jobs. These advanced reports are to be available through a standard Web browser. It should allow end users to self-configure rich Web-based dashboards, trends and reports without expensive, time-consuming support resources. The reporting package shall provide unified access to virtually all manufacturing/plant data sources, and produce web-based reports, such as dashboards, trends, X-Y plots, and Microsoft® Excel reports, that can be used by manufacturing operators, engineers, supervisors, management and executives throughout a plant.

5.4. Dynamic Resource Management

Smart Binding capabilities should include configurable requirements and preferences in unit selection for optimal procedural flow and recipe management. Optimization options shall address: • • • • • • • • • Reduce Recipe Management Effort System shall define all recipes as class based, then set specific requirements through unit attributes Improve energy efficiency System shall allow definition of algorithms to select optimal unit for reduced energy usage Improve quality and reduce rework System shall enable pre-built binding requirements algorithms to eliminate manual product transfer routing errors Improve Process efficiency System shall reduce batch cycle time through dynamic routing decisions System shall react dynamically to changing unit conditions after schedule has been initiated

Page 45 of 62

5.5. Batch Reporting

Data collection from process batch operations should be managed by batch production recording and recordkeeping functions. These functions shall allow the user to define extensions to the basic process historical data collection functions, to perform product, recipe, procedure, or process-specific data recording. These functions shall also allow the user keep an accurate account of batch yields, material consumption and production, batch cycle times, genealogy, regulated, and other industry or product-specific data. The event-based and continuous data captured for every batch executed should be automatically correlated, and easy-to-use tools shall make exploring the complex data simple. The system solution shall incorporate batch reporting functions and standardized report configurations. Reports should be capable of being executed on demand, based on a schedule, or on system or production events. Reports, when generated, shall be capable of being distributed automatically through hardcopy reports, via user interface functions to operators, and via Web services (or to external users), and via email to authorized recipients. Standard web-based batch reports should minimally include: • Batch Reports o Batch Listing o Batch Summary o Batch Detail • Material Reports o Material Usage o Forward Track & Trace o Backward Track & Trace • Analysis Reports o Batch Execution o Batch Duration Comparison o Batch Exceptions

5.6. Batch Recipe Management

Advanced recipe management tools are to be incorporated into the system and provide the ability to configure multiple recipe projects and easily transfer process data recipes through out the system. The following batch recipe management options are to be available:

Software that manages the four primary ISA-88 defined recipe components. This includes header data, formula data, recipe procedure, and equipment requirements.

Page 46 of 62

Software that automates the manual procedures using an interactive, web-based interface to sequence and document manufacturing operations. It should provide the consistency of automated controls in manual operations. Software that brings just-in-time material management to batch execution systems, allowing more effective management of materials and recipes, and provide plant-level material management and tracking, and integrates with company-wide inventory management systems.

5.7. Material Tracking

The system shall provide plant-level material management and tracking that can tie to corporate material management systems to manage and track the use of materials by material type, lot, and sub-lot. Also to manage and tracks vessels, containers and pallets, as well as permanent and transient storage. Material definitions are to be added to recipes, significantly reducing the number of recipes needed for flexible storage facilities. Material consumption, production, and association of materials to containers and vessels are to be automatically logged, providing complete information for forward and backward material tracking within and across process cells.

5.8. MES Interface

The system shall be designed to integrate with business systems and officeautomation systems, as well as with process equipment. The system shall be able to be connected to most major computer manufacturer's systems via gateways and servers, and shall provide data access and file access. The system must also be capable of being bridged to department LANs. The system supplier shall provide software, to run in existing PCs, to allow them to be placed on the system Ethernet LAN, or remotely linked via a serial circuit, and to have access to realtime and historical data. This software shall also permit a PC, under appropriate systems word access control, to operate like an operator's workstation. The system shall provide an open MES interface that helps users to better manage manufacturing processes by integrating plant floor control systems with enterprise, IT and other applications. The MES interface is to employ open database access and to act as a bi-directional “data conduit” between the control system and the business system. System users can utilize the MES interface for:

• • • •

Integrating with production scheduling systems Quality Management Systems Customer and production orders Production tracking systems

Page 47 of 62

Inventory and asset management systems

5.9. Integrated Asset Management
• • • • •

The integrated asset management capabilities of the system are to include: Audit trail for programming and parameter changes. Who made what, when, where and why? Control access to automation devices according to skills and responsibilities Automation device monitoring Disaster recovery plan for automation devices & file archiving Calibration Management

The system shall provide a constant and automatic audit trail of asset changes while also controlling access to these assets; it should be able to verify automatically what it is running against what was qualified. This IAM feature shall provide compliance with the FDA regulation that a Quality Manager has to be able to check if what is running has any impact on quality. It shall also ensure compliance with O9001-2000 (which demands that a company has to be in control of all of its assets). Device diagnostic information should be regularly collected by the system and status and trouble-shooting information should be constantly displayed to the Maintenance team. . An Asset Calibration feature shall allow for a paperless calibration solution; managing calibration requirements, specifications, schedules, calibration results and reporting. An optional capability using Field Device Type (FDT) technology, shall allow access to instrument parameters, aid in configuring and operating process devices, and help with diagnostics. The Asset management software shall: • Manage installed DTM’s with a DTM Catalog • Build the DTM Networks from client computers to the physical devices • View and edit the configuration for a device (online or offline) • Upload and download the configuration for a device • Print the configuration for a device

6. Service and Support
6.1. Training
Vendor shall make available advanced online training, self-paced training, and instructor based, classroom training. This ensures that the right type of training can be matched to the needs of operators and maintenance electricians thereby greatly increasing their ability to operate the system as efficiently as possible.

Page 48 of 62

The vendor shall offer regularly scheduled classes at training centers in all areas/regions of the country. The vendor shall publish course schedules and allow customer registration via the Internet.

6.1.1.

Operator Training
The Vendor shall provide on-site operator training of the final configured software application. This training shall include as a minimum, the following skills knowledge: • Graphic screen navigation • Manipulation of elements on graphic screens • Faceplate manipulation • Alarm annunciation • Accessing alarm history • Accessing trend displays • Accessing and interpreting system diagnostic displays Operator training sessions will provide all information required to: • Operate the system, create and maintain historical files. • Display historical file information graphs and charts. • Start up/Shut down the systems when required. • Complete any other operations that will be required by an operator. • Provide necessary training to deal with power outage and shut down procedures.

6.1.2.

Maintenance and Hardware Training
The vendor will provide Maintenance Training for all systems at site. The vendor shall offer complete and comprehensive training programs for the system, including the controller, networks, and OS. The controller hardware training course content shall include: • CPU, power supply, communication cards, backplane, local and remote I/O racks. • I/O cards • Communications and Ethernet communication • Fault tolerant architecture and failsafe architecture. The Operating System hardware training course content shall include: • System Overview

Page 49 of 62

• •

Client and server architecture, including networking and redundancy The display hierarchy, and the graphical, trending, alarm, reporting, and batch displays

6.1.3.

Engineering Training
The engineering training course content shall include: • • • • • • • • • • • Configuration of the I/O hardware devices Configuration of the communication networks Configuration of continuous and sequential control operations Design of operating and monitoring strategies Introduction to Windows Creation, administration and management of OS system database Creation, administration, and management of graphics displays Creation, administration, and management of system alarming Creation, administration, and management of the historical subsystem Creation, administration, and management of the reporting subsystem HMI Scripting

6.2. Technical Support

The vendor shall offer phone and e-mail support and Internet information. The vendor shall offer 24/7 support for all system hardware and software. This shall include spare parts, maintenance, and technical support. The vendor shall offer a published 800 number for telephone support during normal business hours. The vendor shall offer comprehensive self directed technical support via the Internet that shall include: • Contact with technical support via e-mail • Searchable knowledge base • Product catalogs and manuals • Product Frequently Asked Questions • Software updates • Application examples • Application Tips Available phone support programs should allow system users to choose a service level appropriate to their needs and the objectives of their maintenance strategy including: Page 50 of 62

• Real-time, 8am-5pm local time phone support, comprehensive electronic support tools and software and flash firmware updates for system products. 24x7x365 phone support and dial-up diagnostics optional. • Direct, 24x7x365 phone access to a designated team of support specialists with an intimate knowledge of the user’s specific application and industry. Completely customizable. Dial-up diagnostics optional. • Remote technical consulting and application development for small programming projects — including software conversions and updates. • 30 days of phone support for select system software.

6.2.1.

Onsite Support Services
The following field support engineering services should be offered to assist maintenance staff with preventive and reactive tasks. Field support engineers are to be made available on an as needed, scheduled, or full-time basis to meet the specific user needs and system maintenance strategy. Support services available should include: • Callout services for repair and troubleshooting labor as needed for system related issues. • Extended parts and labor Warranty for repair labor (including local travel) and replacement parts for system control equipment and drives for up to five additional years. • Drives startup services to commission system drives and prevent potential startup problems. To Include 1 or 2 year extended warranty. • Conversion services to convert existing programmable controllers, drives and motors to new or different system technologies. • Preventive maintenance Services to perform regular maintenance on system related equipment to prevent potential problems and extend component/system life. • Embedded engineer as full-time labor to perform reactive and preventive tasks in continuous support of the system maintenance department.

7. Hardware Specifications
7.1. Inputs and Outputs
I/O modules shall be available in a wide variety of densities, including 2, 6, 8, 16 and 32 point, and shall interface to static and dynamic analog and discrete inputs at various voltage levels (both AC and DC). These modules must be able to be

Page 51 of 62

inserted or removed while the system I/O rack is under power and operating, without any disturbance to the system. Output modules shall be available with analog, solid state AC, solid state DC, and relay contact type outputs. Modules shall have a small form factor and feature deterministic I/O update rates, diagnostics features, local (front of module) or remote terminations, and software configuration/management support. • Common mode rejection ratios of 60 dB or greater from DC to 60 Hz and normal mode rejection ratio of 30 dB or greater at 60 Hz are required. • Analog input and output modules shall provide pass-through capability to exchange non-control data, both PROFIBUS and HART, with asset management applications, utilizing the infrastructure of the system. • Dynamic analog input (typically vibration) modules shall provide intelligent local processing of signals and alarms so to minimize data transfer volume and controller processing requirements. • Digital output circuits shall be provided with protection for the switching of inductive loads. • The following configurable fail-safe options shall be available for each output module: o Drive to predetermined analog output or de-energize for a digital output o Maintain the last good output value for an analog or hold for a digital output. • Drive to predetermined analog output or de-energize for a digital output • Maintain the last good output value for an analog or hold for a digital output. • The fail-safe actions listed above shall be taken upon a processor halt, or power supply failure, or a communication failure between the controller and the I/O module, if so configured. • It shall be possible to change modules in remote I/O racks while the rack is powered up without affecting communication to the other modules in the rack. As a minimum, the following types of modules should be available:

Page 52 of 62

Analog High Level Analog Input, (10V & 4-20ma) Dynamic analog input (typically vibration) Analog Output, (4-20ma) Analog Output, (10v) Thermocouple Input RTD Input Analog Input, Voltage And Current Analog Output, Current/Voltage Isolated Discrete Relay 24-220 VAC (8 NO & 8 NC) Output 24-220 VAC (16 NO) Output DC Input 24 VDC, (Isolated) AC Input 10-30 VDC, (Diagnostic) 120 VAC, (Isolated) 24 VDC (Isolated) 220 VAC, 48 VDC (Diagnostic) 120 VAC, 125 VDC(Isolated) 120 VAC AC Output 120/220 VAC, (Isolated) 120 VAC, (Diagnostic) 120/220 VAC DC Output 24 VDC, (Isolated) 10-30 VDC, (Diagnostic) 24 VDC 24 VDC, (Electronically Fused) 48 VDC 125 VDC, (Isolated)

7.1.1.

7.1.1. Analog Inputs
The system shall be capable of supporting the following types of analog process input signals: • • • • 4-20 mA dc, 0-20 mA dc, and ±20 mA dc, isolated and non-isolated inputs 1-5 V dc, ±10 V dc, and ±1 V dc isolated and nonisolated inputs Type B, E, J, K, L, R, S, T and U thermocouples, isolated and non-isolated inputs Platinum resistance temperature detector (RTD) – Pt100, Pt500, Pt1000, Ni100, Ni1000, Cu10 per IEC 60751, isolated and non-isolated inputs

Page 53 of 62

• •

High-speed Pulse input – 100, 125, 250, 500 kHz, 1 & 2 MHz @ 24 V Vibration

Temperature linearization and thermocouple cold junction compensation shall be provided. Normal resolution shall be a minimum of 13-bits; special modules with 16-bit resolution shall be available. Standard measurement conversion time shall be faster than 25 ms. typical analog input modules shall operate at 25°C with a basic error of no more than ±0.25% of input range.

7.1.2.

Digital Inputs
The system shall be capable of supporting the following digital input types, time stamped to 10 ms second accuracy: • • • • • 24 Vdc 125 Vdc 24-48 Vac/dc 120 Vac 230 Vac

7.1.3.

Analog Outputs
The system shall support output types of 0-20 mA, 4-20 mA, ±10 Vdc, 0-10 Vdc, and 1-5 Vdc. Analog output modules shall operate with an error limit less than the following: Voltage ±0.2% of output, Current ±0.3% of output.

7.1.4.

Digital Outputs
Relay or solid-state output contacts that are free of voltage and ground shall be available. Relay outputs with 5-125 Vdc, 5A rating shall be available. Latching and non-latching momentary contact outputs shall be available. The following solid state output ratings shall be available: 24 Vdc, 120 Vac, and 230 Vac

7.1.5.

I/O Terminations
All field wiring shall be terminated to the I/O modules or on a vendor supplied termination panel. Each I/O module/panel shall be able to accept 14 AWG cable. If the field wiring is to be terminated at a panel, the vendor shall supply a prefabricated cable to connect the termination panel to the process I/O card.

Page 54 of 62

7.1.6.

Spare Capacity
Each system shall be supplied with 20% spare I/O capacity installed for each I/O type in the base system. The base system should be defined as the quantity of hardware needed to meet the project requirements.

7.2. Controller Removal and Insertion under Power

Controllers should be capable of removal and insertion under power (RIUP). Communication and I/O modules should be capable of being removed and inserted while power is applied to the controller. This allows users to keep the system up and running when it is necessary to replace modules.

7.3. Controller Redundancy

Controllers shall be redundant and provide total redundancy of all functions in the event of a Controller failure. Supplier shall document redundancy scheme and expected performance of redundancy failover. The communication for redundancy shall not be over the control network and is to be a redundant fiberoptic cable connection. Redundant controllers, power supplies, racks, and communication networks shall be available. Redundant controllers are to be physical separated to minimize the potential for common cause failures and are not permitted to share a common backplane. Backdating the standby controller shall be done in such a manner to assure that no instruction of any type executed in the primary can be “lost” upon switchover to backup. Vendor shall state how long the switchover and initialization time is in a 70% loaded controller. Exception to these requirements shall be clearly stated. Fail-over to redundant components shall be alarmed, but otherwise transparent to the user: i.e., no additional application programming shall be needed to handle the failover. Rack-based control redundancy shall: • Provide high system availability by switching control to a secondary controller chassis if anything in the primary controller chassis fails. System will switch from primary to secondary upon: o Power loss to primary chassis. o Hardware or firmware failure of any module in primary chassis. o User program major fault in primary controller. o Disconnection of communications. o Removal of any module in the primary chassis. o User command given to switchover.

Page 55 of 62

• Not require users to maintain separate programs for the primary and secondary controllers because the system utilizes automatic program cross-load and synchronization. • Be supported by standard hardware. • Support a bump-less switchover. • Support online updating of firmware.

7.4. Controller Redundancy Switch-over Time

In the redundant system, controllers shall operate with a “hot backup” where both CPUs execute the identical step of the operator program in parallel. When a CPU error is detected, a switchover shall be initiated with switchover to be completed in as little as 20 msec.

7.5. Safety Controllers - SIL
The system should support safety systems through the availability of Safety Integrity Level (SIL) certified controllers and I/O. System controllers and I/O that are certified for SIL 1 and SIL 2 applications by TÜV should be available.

7.6. Controller Power Supplies

Redundant power supplies for system rack-based controllers shall be provided for high availability of chassis power. The redundant power supplies should be capable of being utilized in remote rack-based chassis also, ensuring that remote I/O also always has the power needed. The power supply shall be separate from the chassis slots so as not to consume any I/O slots. Power supplies shall be available in 120/240 VAC and 24 VDC models. As an option, a UPS capable of providing a minimum of 20 minutes of power shall be included with the system. The controllers shall not require the use of cooling fans.

7.7. Controller Memory Backup

Controller configuration memory shall have an on-board lithium battery or CompactFlash backup option so that the controller maintains its configuration and state information in the event of a power outage. A rack mounted batterymodule option is to also be available. The module is to provide longer battery life than the on-board backup battery. In the event of an extended power failure, the controller shall not require access to the engineering station to reload any portion of its configuration.

7.8. Controller Memory Expandability

The vendor shall supply controllers which have the capacity for increasing their memory via memory expansion cards to accommodate additional programming. In a redundant system, memory additions shall be possible online without shutting down the system.

Page 56 of 62

7.9. Controller Footprints

Controllers are to be available in the following footprints: Rack mounted high performance controllers that have a high memory capacity, support intensive process applications and provide fast processing of motion instructions. Rack mounted controllers should also utilize a wide range of modular network communications which ensures that only what is needed is purchased. Panel mounted with small footprint and high performance for tackling smaller, machine-level control applications. They should provide a costeffective means to integrate a simple machine or application into the system. Rail mounted controllers that provide a small, highly adaptable distributed control option. These should include inexpensive, multi-loop controllers that offer two flexible communications slots that can be configured to support the various system communication options.

7.10. Cabinets

Control cabinets shall conform to CE standards for electromagnetic compatibility with the EMC law, and ensure protection against unauthorized access, mechanical influences, contamination, and other environmental influences. Ingress Protection (IP) enclosures are to provide protection against foreign objects and moisture. The standard cabinet shall conform to IP40, and a cabinet upgrade to IP55 shall be available

7.11. Warranty Information

Warranty programs should include all replacement parts, local repair labor and local travel for up to five additional years on select system control equipment and drives. If a problem occurs, a dispatch center should immediately send an experienced, factory-trained technician to the site to perform all system repairs and restore operation Features should include: • Reduce liability for equipment malfunction or failure • Reduce the duration of unscheduled downtime events • Reduce overall maintenance expenses • Replacement of parts quickly and easily without the need for separate purchase orders or administrative burden • Unlimited troubleshooting and repair services by factory trained technicians (8am - 5pm local time, Monday-Friday) • Procurement and installation of all replacement parts • Genuine new replacement parts

8. Electrical Requirements

Page 57 of 62

8.1. Field Instrumentation

All field instrumentation and equipment supplied to this specification and used with the process control system must meet the minimum applicable requirements set forth by the International Electrotechnical Commission (IEC) standards and comply with the latest edition of the references listed below: International Electrotechnical Commission (IEC) IEC 60751 (1983-01) Industrial platinum resistance thermometer

• • • • • • • • • • • • • • •

sensor IEC 61000-4-2 (2001-04) Electromagnetic compatibility (EMC)Part 4-2: Testing and measurement techniques – Electrostatic discharge immunity test IEC 61000-4-3 (2002-03) Electromagnetic compatibility (EMC) Part 4-3 IEC 61000-4-4 (1995-01) Electromagnetic compatibility (EMC) Part 4: Testing and measurement techniques - Electrical fast transient/burst immunity test IEC 61158 (2000-08) Fieldbus standard for use in industrial control systems Part 2: Physical Layer specification and service definition IEC 61508: Functional Safety, Safety Related Systems National Fire Protection Association NFPA 70 National Electrical Code Underwriters Laboratories UL Certificate Canadian Standards Association CSA Certificate ISO-9001 NEC (National Electrical Code) Standard 500

9. Environmental Conditions
9.1. Indoor Installations
Equipment installed in air-conditioned buildings shall be designed to operate in the following environmental conditions: • Temperature range: 0°C to 60°C. • Relative humidity: 5% to 95% RH.

9.2. Outdoor Installations

It shall be possible to install the I/O system in outdoor enclosures in Class 1 Div 2 (Groups A, B, C, and D) and CENELEC/ATEX Zone 2 hazardous environments. The minimum ratings of outdoor panels is to be NEMA 4x.

9.3. Storage Conditions

It shall be possible to store the equipment before installation for up to 6 months in an air-conditioned building under the following conditions: • The equipment shall be packed in a moisture proof container • Storage temperature: -40°C to 70°C. Page 58 of 62

Relative humidity (outside the moisture proof container): 5% to 95%.

10. Appendix A
10.1. Definitions
This section contains definitions for acronyms, abbreviations, words, and terms as they are used in this document.

10.1.1.

Acronyms and Abbreviations Acronyms and abbreviations used in this document: • CPU Central Processing Unit • HART Highway Addressable Remote Transducer • HMI Human Machine Interface • IEC International Electrotechnical Commission • I/O Input/Output • ISA The Instrumentation, Systems, and Automation Society • MTBF Mean Time Between Failures • OLE Object Linking and Embedding • OPC OLE for Process Control • OS Operator Station • PC Personal Computer • RFI Radio Frequency Interference Terms Terms used in this document: • Alarm Logging: Editor for configuring the message system in the operator station and the application for displaying, archiving, and handling messages. • Archive: Saving measured values and messages in the operator station to history so the data can be called up over a long period of time. • Audible signal device: Horn, bell, buzzer, or similar device indicating that a new alarm or message has arrived at the operator station. • Availability: The probability that a system will be able to perform its designated function when required. • Bus: A path for electrical signals allowing the exchange of data between various components of a computer or system. • Central Processing Unit (CPU): The central part of the controller in which the operator program is stored and processed, and the operating system and communication interfaces are contained. • CFC: Continuous Function Chart is a high-level graphical language using function blocks for configuring continuous control systems. • Chart: The document in which the automation functions can be created using the CFC tool or the SFC tool.

10.1.2.

Page 59 of 62

• Communications Link: The hardware and software that performs the transmitting and receiving of digital information over a communication system, for example a bus. • Configurable: The capability to select and connect standard hardware modules (blocks) to create a system; or the capability to change functionality or sizing of software functions by changing parameters without having to modify or regenerate software. • Configuration: The physical installation of hardware modules to satisfy system requirements; or the selection of software options to satisfy system requirements. • Cycle: In the controller, the scanning of inputs, execution of algorithms by the controller, and transmission of output values to devices. • Discrete Control: Control where inputs, algorithms, and outputs are based on logical (True or False) values. • Distributed I/O: Field devices or analog and digital modules located at a distance from their central controller. • Ethernet: Hardware type standard for data transmission using coax, twisted pair, fiber optic cable, or wireless, usually running at 10 Mbps (see Fast Ethernet). • Faceplate: On the Operator Station screen, a graphic element that represents, for example, an analog controller instrument, a hardwired pushbutton, or a switch, allowing operator monitoring and control of the device. • Fast Ethernet: A faster version of Ethernet running at 100 Mbps. • Fault-tolerant system: A system in which all essential components (such as CPU, Power supplies, racks etc) are duplicated, allowing the backup device to take over from the primary device without control interruption if a failure occurs. • Foundation Fieldbus: The ISA/IEC Foundation Fieldbus standard covers a communication system for field mounted measurement and control devices. • Function Block: A control bock as defined in IEC 1131-3. See also Block. • GPS: Global Positioning System, a satellite based system, which shall provide the exact position anywhere on earth, and the time of day. • Human Machine Interface (HMI): The graphical interface program for allowing an operator to interact with and control a process. • Instance: A copy of a function block, which is used again in the control configuration for a similar application. • Ladder logic (LAD): Graphical representation of the automation task using relay symbols complying with DIN 19239. • Logs: Files or printouts of information in chronological order. • Mode: Control block operational condition, such as manual, automatic, or cascade. • OPC: Object Linking and Embedding for Process Control, a software application, which allows bi-directional data flow between two separate applications.

Page 60 of 62

• Operator Station (OS): Electronic equipment including, at a minimum, a monitor, keyboard, and pointing device used by an operator to monitor and control his assigned process or manufacturing units. • PLC: Programmable Logic Controller, used for discrete and continuous control in processing and manufacturing plants. • Profibus: Process Field Bus, a field bus complying with EN 50170 Vol. 2 Profibus (DIN 19245; bus system for industrial application based on Profibus). • Plug and Play: The ability of hardware equipment to automatically identify itself to the system. When the equipment is powered up it is automatically assigned a unique identity without the need to set any dipswitches. • Point: A process variable derived from an input signal or calculated in a process calculation. • Process Object: A collection of variables and parameters that performs a control function (eg. motor, block valve, PID Controller) which may consist of more than one I/O point. • Redundant: A system/subsystem with two modules that shall provide automatic switchover to a backup in the event of a failure, without loss of a system function. • Regulatory Control: The functions of process measurement, control algorithm execution, and final control device actuator that provide closed loop control of a plant process. • Reliability: The probability that the system or component will perform its intended function for a specified period of time, usually measured as Mean Time between Failures. • Structured Control Language (SCL): A high-level language complying with IEC 1131-3 for programming complex or custom logic tasks within the controller. • Self-Diagnostic: The capability of an electronic device to monitor its own status and indicate faults that occur within itself. • Security: System access control by key lock, systems word, electronic card, or other equivalent method. • Sequential Control: A type of discrete control handling sequential processes. • Sequential Function Chart (SFC): Sequential Function Charts are a high-level graphical configuration language for sequential control applications. • System Bus: The network used for communication between controllers and HMI servers. • Tag: A collection of attributes that specify either a control loop or a process variable, or a measured input, or a calculated value, or some combination of these, and all associated control and output algorithms. Each tag is unique. • Tag Id: The unique alphanumeric code assigned to inputs, outputs, equipment items, and control blocks. The tag ID might include the plant area identifier.

Page 61 of 62

Time synchronization: Time Synch is provided by the operator station to make sure that all PLCs and operator stations on the bus operate with the same time of day. • Workstation: Computer equipment including a PC, monitor, keyboard, and associated pointing device used by engineers to configure the control system. 

Page 62 of 62