Procurement Specification Document PROCESSO002BENE

8/14/2019 Procurement Specification Document PROCESSO002BENE

1/62

Process Control System

Procurement SpecificationDocument

V2.0Rockwell Automation

January 2009


2/62

PROCES-SP002B-EN-E

Page 2 of 62


3/62

Table of Contents

1. System Specification Overview ......................................... 72. System Architecture Requirements .................................. 7

2.1. System Scalability ...........................................................................................................82.1.1. Controller Capacity ..................................................................................................82.1.2. I/O Network and I/O Capacity .................................................................................82.1.3. Controller Application Capacity .............................................................................. 8

2.2. System Redundancy ....................................................................................................... 82.3. System Expansion ........................................................................................................... 92.4. Software Revisions .........................................................................................................9

2.5. System Sever ...................................................................................................................92.5.1. HMI Server ..............................................................................................................92.5.2. Data Server ...............................................................................................................92.5.3. Alarm Server ..........................................................................................................102.5.4. Domain Server .......................................................................................................102.5.5. Security Server ......................................................................................................102.5.6. License Server .......................................................................................................112.5.7. Historian Server .....................................................................................................112.5.8. OPC Server ............................................................................................................ 112.5.9. Batch Server ...........................................................................................................11

2.6. System Services ............................................................................................................122.6.1. Distributed Data .....................................................................................................122.6.2. Directory Service ................................................................................................... 122.6.3. Alarms and Events .................................................................................................132.6.4. Security ..................................................................................................................13

2.7. Networks .......................................................................................................................132.7.1. Network Management ............................................................................................132.7.2. Supervisory Network .............................................................................................142.7.3. Control Network .................................................................................................... 142.7.4. Control Network Redundancy and Alarming ........................................................ 14

2.8. I/O ...............................................................................................................................152.8.1. Analog I/O ............................................................................................................. 152.8.2. Discrete I/O ............................................................................................................152.8.3. High-Speed I/O ......................................................................................................152.8.4. Chassis Based I/O ..................................................................................................152.8.5. Distributed In-Cabinet I/O .....................................................................................162.8.6. Distributed On-Machine I/O ..................................................................................162.8.7. Intrinsically Safe I/O ..............................................................................................162.8.8. Conformally Coated I/O ........................................................................................162.8.9. Adding or replacing I/O Modules Online ..............................................................17

2.9. Field Device Interfaces and Device networks .............................................................. 172.9.1. DeviceNet ..............................................................................................................17

Page 3 of 62


4/62

2.9.2. HART I/O .............................................................................................................. 182.9.3. Foundation Fieldbus I/O ........................................................................................182.9.4. Profibus I/O ............................................................................................................192.9.5. Intelligent Device Management .............................................................................19

3. System Configuration, Visualization and Maintenance19

3.1. Engineering Workstation ............................................................................................. 193.1.1. Engineering Workstation Configuration ................................................................203.1.2. Engineering Workstation Functions ......................................................................203.1.3. Reusable Applications ..........................................................................................21

3.2. Operator Interface Configuration ..................................................................................213.2.1. Graphical Display Editor ....................................................................................... 213.2.2. Graphic Displays ....................................................................................................223.2.3. Standard Faceplate Library ...................................................................................233.2.4. Integrated Batch Visualization ...............................................................................23

3.3. Operator Interface Visualization ..................................................................................233.3.1. Operator Station Redundancy ................................................................................243.3.2. Operator Station Security .......................................................................................243.3.3. Area Security .........................................................................................................243.3.4. Alarm Window ......................................................................................................253.3.5. Faceplates ..............................................................................................................253.3.6. Time Synchronization ...........................................................................................25

3.4. Alarm and Event Management .....................................................................................253.4.1. Alarm Priorities ......................................................................................................263.4.2. Alarm Detection .....................................................................................................273.4.3. Alarm Acknowledgment ........................................................................................273.4.4. Alarm Logging .......................................................................................................283.4.5. Alarm Navigation ...................................................................................................283.4.6. Alarm Archiving ....................................................................................................28

3.5. Trending ........................................................................................................................283.5.1. Trend Data .............................................................................................................29

3.6. Reports ..........................................................................................................................303.7. Report Generation .........................................................................................................31

4. Process Controllers ......................................................... 314.1. Controller Programming Environment .........................................................................31

4.1.1. Controller Editor ....................................................................................................314.2. Controller Runtime Modifications ................................................................................32

4.3. Controller Restore / Upload ..........................................................................................334.4. Controller Communications ..........................................................................................334.5. Control Strategy Development .....................................................................................334.6. Controller Configuration Languages ............................................................................ 34

4.6.1. Function Block Diagram ........................................................................................344.6.2. Sequential Function Chart ......................................................................................354.6.3. Structured Text .......................................................................................................354.6.4. Ladder Diagram ..................................................................................................... 364.6.5. User Defined Functions and Tags ..........................................................................36

Page 4 of 62


5/62

4.7. Alarm and Event Detection ...........................................................................................364.8. Process Control .............................................................................................................37

4.8.1. PIDE Loop Control ................................................................................................374.8.2. PIDE Integrated Auto-Tune ...................................................................................374.8.3. PIDE Optimized Auto-Tune ..................................................................................37

4.8.4. Standard Library for Controller .............................................................................384.8.5. Computational Functions .......................................................................................384.8.6. Discrete Control Functions ....................................................................................394.8.7. Advanced Regulatory Control ............................................................................... 394.8.8. Fuzzy Logic ...........................................................................................................39

4.9. Batch & Sequencing Control ........................................................................................ 394.9.1. Basic Batch & Sequencing .....................................................................................404.9.2. Comprehensive Batch & Sequencing ....................................................................40

4.10. Drive Control ..............................................................................................................404.11. Motion Control ............................................................................................................414.12. SCADA and Third Party Connectivity .......................................................................41

4.12.1. OPC Interface .......................................................................................................424.12.2. Serial Interface .....................................................................................................424.12.3. Ethernet ................................................................................................................424.12.4. Third Party PLC Communication ........................................................................424.12.5. Third Party DCS Communication ........................................................................42

4.13. Controller Application Code Security ........................................................................434.14. Process and System Simulation ..................................................................................43

5. Production Management ................................................. 445.1. Historical Data Archiving .............................................................................................445.2. Plant Data Historian ......................................................................................................445.3. Historical Data Reporting ............................................................................................. 455.4. Dynamic Resource Management ..................................................................................455.5. Batch Reporting ............................................................................................................465.6. Batch Recipe Management ........................................................................................... 465.7. Material Tracking ..........................................................................................................475.8. MES Interface ...............................................................................................................475.9. Integrated Asset Management .......................................................................................48

6. Service and Support ......................................................... 486.1. Training .........................................................................................................................48

6.1.1. Operator Training ...................................................................................................496.1.2. Maintenance and Hardware Training .....................................................................496.1.3. Engineering Training .............................................................................................50

6.2. Technical Support .........................................................................................................506.2.1. Onsite Support Services .........................................................................................51

7. Hardware Specifications ................................................ 517.1. Inputs and Outputs .......................................................................................................51

7.1.1. Analog Inputs ........................................................................................................537.1.2. Digital Inputs ........................................................................................................ 547.1.3. Analog Outputs .....................................................................................................547.1.4. Digital Outputs ......................................................................................................54

Page 5 of 62


6/62

7.1.5. I/O Terminations ....................................................................................................547.1.6. Spare Capacity ....................................................................................................... 55

7.2. Controller Removal and Insertion under Power ...........................................................557.3. Controller Redundancy .................................................................................................557.4. Controller Redundancy Switch-over Time ...................................................................56

7.5. Safety Controllers - SIL ................................................................................................567.6. Controller Power Supplies ............................................................................................567.7. Controller Memory Backup ..........................................................................................567.8. Controller Memory Expandability ................................................................................567.9. Controller Footprints .....................................................................................................577.10. Cabinets .......................................................................................................................577.11. Warranty Information ................................................................................................. 57

8. Electrical Requirements ................................................. 578.1. Field Instrumentation ....................................................................................................58

9. Environmental Conditions .............................................. 58

9.1. Indoor Installations ....................................................................................................... 589.2. Outdoor Installations .....................................................................................................589.3. Storage Conditions ........................................................................................................58

10. Appendix A ..................................................................... 5910.1. Definitions ...................................................................................................................59

10.1.1. Acronyms and Abbreviations ..............................................................................5910.1.2. Terms ................................................................................................................... 59

Page 6 of 62


7/62

1. System Specification OverviewThis specification defines the minimum mandatory requirements for the processautomation system and associated software and support services.

The system shall enable the users to control plant-wide applications throughout thefacility, from batch and continuous processing to high-speed packaging lines within asingle architecture. The architecture should also provide seamless information flow from plant floor instrumentation.

The process automation system should provide flexibility, scalability and expandabilitywhen solving batch and process applications unlike a traditional closed, rigid system likea DCS. The system should allow users to incrementally implement plant automationusing only the components needed. When an upgrade or addition to the system isrequired components should be easily added.

The process automation system must include the following features traditionallyassociated with both a programmable logic controller such as programming in ladder logic and remote I/O architectures and a distributed control system (such as continuousand complex control, advanced operator interfaces, and sophisticated redundancy). Thesecapabilities must seamlessly reside in the control system without the use of specialgateways 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 includingPC platforms with a Windows operating system (supporting XP, Vista, Server 2003 andServer 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 informationsystems.

2. System Architecture RequirementsThe basic architecture of the system is based upon a distributed "client-server" structureat the supervisory network with physically and functionally distributed controllers performing the real-time control and processing operations and separate workstationsand clients providing the human-machine interface (HMI) functions. All of theseelements are to be interconnected via Ethernet with TCP/IP networking software. Theclient server structure of the system shall make it possible for the system to operateeven if several components are out of service. Interface with Field devices should bethrough dedicated non-Supervisory Networks and support both classic signalconversion I/O as well as Smart Instrumentation and Industrial control devices. Thesystem 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


8/62

across multiple controllers. The system shall use a distributed architecture so that nosingle failure will disable the total system. Plus, the user shall be able to elect that allor portions of the system be made redundant, to provide the highest levels of systemavailability. The local and wide-area network potions of the system shall be compliantwith 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 supportall media forms of Ethernet including copper and fiber optic.

2 . 1 . System Scalability The system must provide the highest degree of scalability possible sousers only buy what they need open, scalable, and distributed. Itshould provide scalable controllers and I/O all with a common designenvironment in addition to a scalable HMI solution again with acommon design environment. The need is to provide a highlyintegrated control system across different control platforms and enablethe control capability to expand from a few loops to thousands.

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

2.1.2. I/O Network and I/O CapacitySystem shall include specification for maximum I/O limitationsfor controllers. This should include maximums for controlnetworks, I/O networks, and I/O module (local and remote I/O,

SCADA, and industry-standard control networks.).

2.1.3. Controller Application CapacitySystem shall include specification for controller applicationcapacity. This should reflect both single programminglanguage applications as well as cases involving a mix of control application strategies. If differences exist (in themaximum number of controllers allowed) between redundantand non-redundant configurations, vendor shall provideexplanation.

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

Page 8 of 62


9/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 andI/O redundancy is covered under the Controller and I/O section of thisdocument). 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 systemexpansion in a phased fashion, where the initial system implementationmay be quite small. As requirements grow, the system shall accommodatethe addition of HMIs, front-end computers and field devices, all without performance degradation. The system shall support field extension of itsnetwork, addition of gateways to the network, addition of controllers andremote I/O where required, and integration of PLCs and computers intothe system.

2 . 4 . Software RevisionsApplication software shall not require modifications in order to be ableto run under new releases of the system operating software. Any newrelease of system software shall be backward compatible with filescreated using the previous software releases.

2 . 5 . System Sever The system shall be capable of running a pair of similarly configuredservers/workstations in a redundant configuration where at any pointin time, one is the acting Primary and the other the acting Backup. Anon-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 itsreinstatement, re-synchronize the databases via a push-button on thescreen, again without interruption to system operation. A simplemethod of manually initiating a fail-over shall be provided to assistwith 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 wideoperator workstations thereby removing the need to createduplicate copies and maintain them for multiple operator workstations.

2.5.2. Data Server The data server links networks and devices to system widevisualization and development components such as HMIclients and engineering workstations. It shall provide

Page 9 of 62


10/62

communication services between applications and devices onthe plant floor allowing users to read, write, and configurevalues in plant floor devices, such as sensor readings and other system controller data.

Data servers shall be configurable to run on both a primarycomputer and a backup computer. The system shouldautomatically switch to a backup computer if communicationwith the primary computer fails.The servers should handle failure detection and failoversautomatically for all components (clients) of the system. In atraditional system (DCS), each client must independentlymonitor 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 conditionsand 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 tomanage highly distributed systems.

2.5.5. Security Server An available security server should protect againstunauthorized use but still allow authorized users to use thesystem efficiently. The security is to be a centralized systemwhich restricts access to system resources based on keysecurity components.

The security server shall have the capability to have either control-system local users/groups or domain-linkedusers/groups and the ability to use an existing domain.

The key components that are to be securely managed by thesecurity 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 whichactions can be performed on a secured resource.

Page 10 of 62


11/62

2.5.6. License Server Electronic software licenses for components are to be managed by a software license server. Software licenses for engineeringworkstations and for operator interface consoles shall beindependent of the type and mixture of I/O used (analog vs.discrete, input vs. output). The software licenses (both runtimeand engineering) shall be portable allowing the operator totransfer licenses from one PC to another without requiringintervention from the vendor.

To help minimize the risk associated with changesin project scope, if software is licensed on a tag-by-tag basis, the vendor shall supply in writingdetails on how the required software licensewould 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 collectionfunctions defining what data is to be collected and under whatcircumstances 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 becollected. As with process historical data, this data shall beaccessed for viewing and for reporting.

2.5.8. OPC Server The system must allow for 3rd party connectivity to the systemcontrollers and to the HMI Server via an OPC interface. Thisopen connectivity shall follow the OPC Foundation's standardsto get information to or from the system. If the system isconfigured for redundancy, OPC communications mustcontinue 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 informationinto a batch event journal for reporting and archiving.

Page 11 of 62


12/62

Functions of the batch server should include transformingconfigured 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 assignequipment to a particular batch (e.g. acquire ownership of anavailable resource and assign its use to a particular batch), preventing its allocation to another batch. If parallel stepsrequire the same dedicated resource, the system shouldautomatically determine how the resources are allocated amongsteps when the batch is run, based on criteria established by theuser.

The batch server should support redundant storage. Duringruntime, it should continuously journal all actions to one or multiple disk drives, so that data can be fully recovered in theevent of control system failure. In the event of a primary server failure, the batch server can be re-started on another secondarymachine and should return to the previous locations in allactive recipes.

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

2.6.1. Distributed DataData in the system is to remain distributed in its original, nativeenvironment (e.g. the controller). The data should bedistributed, not duplicated or copied throughout the systemallowing resources (tags, displays, alarms and events, securitysettings) to be defined once and shared throughout the system.The data should be available immediately to every piece of thesystem with each being able to locate, browse, and organize thedata and services needed. Resource changes within the systemupdate immediately across all pieces of the system.

2.6.2. Directory ServiceThere should be present a directory of factory resources such asdata tags, HMI displays, and other plant floor objects that actsas a lookup service for the data rather than a single, commondatabase. The directory should be a service that should providea searchable reference to data resources stored anywhere acrossthe system. It shall provide the benefits of a common databasewithout a possible single point of failure.

Page 12 of 62


13/62

Resource names are to be separated from the physical locationswhere the resources reside. For example, changing the locationwhere a data item is stored should not change its name, and asa result, should not change access to the data item. Usersshould be capable of building complex distributed systems

offsite and later deploying the systems at other locations bysimply changing the names of the computers where the dataservers and HMI servers reside. The individual tag and other resource names are to remain unchanged. Likewise, adeployed program can be moved to a workstation, modified,and then redeployed. In addition, separating the names of dataitems from their locations also makes implementing redundantsystems much easier.

2.6.3. Alarms and EventsWhen alarms or events occur in the system, operators are to be

quickly alerted of the conditions which require immediateaction. Alarms and events are to be detected at the controller level ensuring accurate identification of alarm sequences,reduced network bandwidth requirements, and improvedoverall system performance. Since the alarm state is to bemanaged in the controller itself the state should not be not lostif the HMI servers fail. Alarms triggered anywhere in thesystem shall be capable of being viewed and acknowledgedfrom any operator workstation in the system.

2.6.4. Security

Centralized access control should be provided by verifying alluser identities, and then by either granting or denying eachusers request to access features and resources within thesystem.

2 . 7 . NetworksThe system should utilize the Common Industrial Protocol (CIP) to move dataseamlessly throughout the system. Multiple physical networks, including the plant, supervisory, control, and device networks should appear as a singlenetwork making communications efficient.

2.7.1. Network Management Network Management is to provide the ability for the system tosupport and manage system wide communications. This shallinclude:

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


14/62

Supervisory control between controller and BatchManagement

Data collection for trends and historians Production data transfer between the system and Plant

MES software

2.7.2. Supervisory NetworkThe open technologies of Ethernet and TCP/IP shall be utilizedfor communication between the control system server and theoperator stations. The control system server and its associatedoperator stations must be capable of connecting to two fullyindependent Ethernets run in parallel. No repeater or bridgeconnection 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 thecontrollers.

2.7.3. Control NetworkThe process control network/remote I/O network is used toconnect the controller to field (Remote) I/O and shall be anopen, 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 AlarmingFailure of any supervisory system shall be announced audiblyand 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 typicaldata throughput of his communications system, in baud rateand number of analog values per second.

Loss of communications shall not cause loss of control at thelocal subsystems. Also, loss of a local subsystem (either a

Page 14 of 62


15/62

single node or both of a redundant pair) shall not cause the lossof 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 distributedin cabinets and machines around the application or integrated with the controller itself.

2.8.1. Analog I/OThe analog I/O modules perform the required A/D and D/Aconversions to directly interface analog signals to processor data values using up to 16-bit resolution. Analog I/O can beuser-configured for the desired fault-response state in the eventthat I/O communication is disrupted. This feature shall provide

a safe reaction/response in case of a fault.

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

2.8.3. High-Speed I/OSystem 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 sub-millisecond control. System controllers should also supportevent tasks which provide event driven control for applicationsthat require interrupt driven or deterministic input to output processing. These system capabilities are vital for complete plant automation requiring raw material handling with high-speed conveyors and finished goods packaging on high speedmotion applications.

2.8.4. Chassis Based I/OChassis-based I/O shall provide high functionality field deviceinterface capabilities to the system. Networks supported bychassis-based I/O include DeviceNet, EtherNet, andControlNet.

Chassis-based HART device interfaces, analog input andoutput are available with the option of each channel being set

Page 15 of 62


16/62

to voltage, current or current + HART. This shall provide aversatile communication option which is HART compliant andutilizes standard wiring / terminal blocks.

2.8.5. Distributed In-Cabinet I/O

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

2.8.6. Distributed On-Machine I/OThe system should offer distributed on-machine I/O which is

locally mounted allowing for high-speed dedicated machinecontrol. Networks supported by distributed on-machine I/O areto include EtherNet/IP. Distributed On-Machine I/O is similar to Distributed In-Cabinet I/O but should not require anadditional enclosure for environmental protection allowing for much easier maintenance and troubleshooting. It is the placement of system I/O directly on a machine rather thanhousing the I/O in a remote, central cabinet. Distributed On-Machine I/O shall provide high-speed dedicated machinecontrol 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 intrinsicsafety requirements for operation in hazardous locations. I/Omodules with intrinsically safe barriers built into the I/O are to be available. These I/O can be distributed in hazardous areaswithout the use of bulky explosion proof or purged enclosureswhich are expensive and difficult to maintain. The I/O shouldhave built-in galvanic isolators which reduce terminations andthe size of cabinets.

2.8.8. Conformally Coated I/OAn option to provide conformally coated system I/O modulesthat contain protection against corrosive elements shall beavailable. The conformal coatings are to be 1-2 mil thick polymeric films which cover or encapsulate the printed circuitassemblies. Though generally undetectable by the naked eye,the conformal coatings are to protect the assemblies fromairborne contaminants and corrosion by sealing out the

Page 16 of 62


17/62

contaminants and humidity. This should allow the conformallycoated I/O modules to function in corrosive areas where thenormal 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 systemcontrollers are online. The ability to add I/O online shouldmake it much easier to make system I/O changes to the systemwithout affecting the entire system since the controllers do nothave to be taken offline to do so.

It shall not be necessary to remove power or field wiring toreplace an input or output module.

2 . 9 . Field Device Interfaces and Device networksThe 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 andtemperature measurement instruments.

2.9.1. DeviceNetDeviceNet should be an open, low-cost option the system uses toconnect to industrial devices and to eliminate costly and time-consuming hardwiring. Direct connectivity improvescommunication and shall provide device-level diagnostics notavailable or easily accessible through hardwired I/O interfaces.

Because DeviceNet uses a trunk line/drop line topology, a singleDeviceNet cable shall provide power and communication signal toall devices on the network. This significantly reduces the amountof wiring required and greatly simplifies installation.

DeviceNet shall provide the system controllers with a directnetwork connection to low-level devices with increased device-level diagnostics allowing for troubleshooting, trending andimproved data collection from each device.

Explicit Messaging shall be supported in the DeviceNet

scanner module so configuration, diagnostics, and status can beread or written from a device on the network by the controller.

Automatic Device Replace (ADR) shall be supported in theDeviceNet scanner module, so that when a DeviceNet capabledevice is replaced on the network, its configuration will beautomatically refreshed to the replacement, by the scanner.

Page 17 of 62


18/62

2.9.2. HART I/ODesigned to complement traditional 4-20mA analog signaling,the HART Protocol supports two way digital communicationsfor process measurement and control devices.

Analog input cards shall support HART protocol. The inputsshall allow for 4 HART variables and should work with anyHART compliant field device. It shall be possible to re-rangethe HART device from the system and for the system to reflectre-ranging of the device performed via a handheld. Other HART information shall be capable of being communicatedthrough the I/O cards to maintenance packages

Addition of any HART I/O module must be accomplished without the disruption of the system. This includes the physicalinsertion of a module while the rack is powered. The system

shall be able to read all variables provided by the field devicewithout the need for any additional wiring.

The system should provide direct access to HART instrumentsvia the Control and I/O development software. Access toHART instrument variables shall be available throughcontroller tag data structures and configuration and calibrationshould be accomplished via instrument profiles.

2.9.3. Foundation Fieldbus I/OFoundation Fieldbus networks shall be available from

dedicated interfaces directly to the controller. The vendor shall provide intelligent, self-diagnosing linking devices based onFoundation Fieldbus standards. The HSE/H1 (High SpeedEthernet / Fieldbus H1) linking device shall be able to supportup to four H1 segments.

The linking device shall allow dual, concurrentcommunications 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 andasset management applications on the same network.

The system shall support all field devices certifiedby the appropriate standards body for FoundationFieldbus and shall not require additional approvalsby the vendor of the host system. The systemshall be able to read all variables provided by thefield device without the need for any additionalwiring. Diagnostic information shall be availablefrom the field devices, including device faults,

Page 18 of 62


19/62

configuration faults, operating mode, andmaintenance requests.

The system shall provide direct integration andaccess to Foundation Fieldbus devices, including

configuration and scaling, via the Control and I/Odevelopment software.

2.9.4. Profibus I/OThe system must support Profibus networking, an open, digitalcommunication 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 aProfibus PA network via Ethernet (without requiring DPmasters or couplers).

The system shall have an option to connect to Profibus DPnetworks 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 inthe plant, and support the user in managing them, is to beavailable. It should be based on the FDT/DTM standard, as thistechnology provides engineers with the freedom to integrate

field and communication components supplied by allcomplying third parties.

ControlNet, EtherNet/IP, DeviceNet, HART, Profibus andother field devices that support the Field Device Tool(FDT/DTM) standard interface specification, includingactuators and transmitters should be capable of being managed by the system.

3. System Configuration, Visualization and MaintenanceThis section specifies the configuration and visualization of the Engineering andOperator Workstations and supporting engineering software.

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

Page 19 of 62


20/62

3.1.1. Engineering Workstation ConfigurationThe system is to utilize an Engineering workstationconfiguration that complies with the following generalconfiguration requirements:

The engineering workstations shall employ standard PCtechnology with state-of-the-art hardware based on aWindows operating system (XP, Vista, Server 2003 andServer 2008) and industrial Ethernet communications.

Thin clients utilizing terminal services shall beavailable.

It shall be possible to install more than one engineeringworkstation in a system.

The engineering system shall be an open systemallowing, for example, project data from MicrosoftExcel to be imported.

Storage media shall be provided at each engineeringworkstation.

It shall be possible to save configuration data on bothremovable and non-removable media for back up purposes without taking the system off-line.

The engineering software shall employ an intuitive MSWindows explorer style interface, which will allow theengineer to manage all aspects of the controller, HMI,network, hardware, and field device configuration.

3.1.2. Engineering Workstation FunctionsOnly 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, andediting. However, it shall also be possible to use multipleengineering 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


21/62

Configuration of continuous and sequential controloperations

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 reusableapplication designs. The library management function shall beshared or common among applications used to create andmanage engineering configurations, relative to controlstrategies, 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 anorganized manner.

Documents or objects can be checked out from thelibrary, reviewed and edited.

Edited documents can be returned to the library i.e.checked in

3 . 2 . Operator Interface ConfigurationThe system is to utilize an operator station configuration that ensures the rightinformation can be viewed at the right time. Some of the operator interfacessupported by the system are to include: message displays, graphic terminals, portable HMIs and industrial computers and monitors. The configuration, whichshould offer a common look and feel from an operations viewpoint, should becompletely 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 includesa complete set of drawing objects and sophisticated drawing

Page 21 of 62


22/62

tools and customizable toolbars, object animation andcommand wizards.

The editors 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, modifyand remove components, and also allows users to browse andaccess tags stored in controllers and other data servers. Thedisplay editor should support, but must not require, a customscripting engine such as Visual Basic for Applications.

3.2.2. Graphic DisplaysThe system shall permit configuration of custom graphicdisplays. These displays shall be accessible through assignableuser accounts, and using the standard system operator displaynavigation functions. Revision of an existing display shall

result in automatic updating of any display servers in thesystem scope. The system shall provide detailed documentationof tags used on custom graphic displays. System shall supportdesignation 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


23/62

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

3.2.3. Standard Faceplate LibraryA library of standard pre-built process control HMI faceplates

and symbols shall be available. Optional Industry specificlibraries shall be available.

The standard HMI library shall consist of the following pre-engineered 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 VisualizationA library of standard pre-built process control HMI graphicswith integrated batch views shall be available.

The standard HMI library shall consist of the following pre-engineered graphics at a minimum:

Batch Overview Display Batch Unit Display eProcedure Displays Material Manager Displays

3 . 3 . Operator Interface VisualizationOperator stations shall be capable of being implemented with multiple monitorsand screens so that the operator can have many display pages active at once. Inthis configuration the cursor positioning device (mouse, track ball, etc.) andkeyboard shall be automatically shared and switched to the selected window onthe selected monitor. Transition between windows and screens shall beinstantaneous and user-transparent. Operator options shall include cursor controldevices such as mouse or touch-screen. The normal operations shall be via the

Page 23 of 62


24/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 areviewing is always up-to-date. To maximize data availabilityand integrity, the Operator Station shall provide the ability for configuration of system redundancy. This shall in no way limitor restrict the use of the client/server configuration and/or architecture.

Clients shall automatically failover to the backup or redundantserver. This operation shall not require any applicationreprogramming or reconfiguration. Client stations shall support

the designation of different primary servers allowing thenetwork loading to be distributed and to ensure that in theevent of a failure not all clients will experience a switchover.

3.3.2. Operator Station SecurityThe system shall ensure Operator Station security byauthenticating users against a set of defined user accounts andaccess privileges. Project-level security should also besupported by the system. Levels of security can be assigned tooperator interface commands, macros, database tags, andgraphic displays. Combinations of these levels can be assigned

to individuals or groups of users, giving them different accessto different features. Operator interface security can also beconfigured 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 SecurityEach operator shall be assigned one or more specific areas of the plant with the appropriate monitoring and controlresponsibility. An area shall be defined in this context as alogical 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 individualoperator access by means of area assignment. An operator shall only be able to view or control those control moduleswithin the assigned areas. Each Action taken by an operator shall be allowed if and only if the operator is assigned to thefunction and approved by security level to execute the function,at that particular time, in that context, from that location.

Page 24 of 62


25/62

3.3.4. Alarm WindowA dedicated alarm line, or Alarm banner, shall appear on alloperator displays showing either the most recentunacknowledged 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 AlarmSummary 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 adedicated line. If multiple alarm/change of state conditionsoccurs, subsequent messages shall overwrite the display if theyare higher priority. As subsequent alarms are displayed, the previous alarm information shall move to an unacknowledgedalarm list awaiting acknowledgment by the operator.

3.3.5. FaceplatesThe system should include pre-built and tested graphicfaceplates for control functions such as PID, totalizers, multi-state devices, motor starters and drives.

3.3.6. Time SynchronizationThe Operator Interface shall be capable of synchronizing itstime with the control system so that there is no more than a 20msec 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 asGPS (Global Positioning System) or DCF77 which can be usedas the time master for the system. Date and timesynchronization shall be possible anywhere in the world usinga satellite source such as GPS (Global Positioning System).

3 . 4 . Alarm and Event Management The system shall support a comprehensive alarm detection and managementfacility to allow fast and accurate notification to the operator of abnormalconditions within the process. Alarm monitoring shall be extended to calculatedvalues and SCADA input values handled by the system. Alarm monitoring shallalso be extended to diagnostic values monitored by the system. Monitoring of source values and analyzing for alarms shall take place as close to the originalsource 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 beable 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


26/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 theresponsible operator(s) shall be permitted to acknowledge or clear the respective

alarms.The interface to the appropriate user for alarm presentation and control shall bevia the operators standard navigation screen or specific windows, either dedicated, or "pop up" (or both). The operator shall have the option to retain analarm manager window on his screen at all times, or may invoke the alarmmanager screen as required. Invocation of the alarm manager screens shall beuser 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 PrioritiesThe system shall support the ability to configure all alarms based on their level of seriousness relative to impact on theoperation of the process or system. The system should supportat least four alarm priorities. These priorities are to beconfigured as part of the control function blocks as follows:

Urgent High Medium Low

Each alarm type shall be individually able to be prioritized intoone of the above categories. Urgent, High, Medium and Low priority alarms shall be displayed as such in the system AlarmSummary. Audible Alarm and Alarm Paging

An audible alarm shall be configurable for each of the abovealarm priorities. Alarms shall be routable to external alarmhardware (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 providerealistic 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


27/62

3.4.2. Alarm DetectionConfiguring a function block alarm in the controller shallautomatically cause the system to perform the followingactions when an alarm occurs:

The alarm shall be time stamped to a resolutionappropriate for the location within the system at whichthe alarm condition is monitored or detected (e.g., thenearest second in the HMI, the nearest processing cycletimestamp when in the controller or field device).

The alarm shall be logged in the Event Database withthe Point Name, Alarm type, Alarm Priority, PointDescription, 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 andUrgent 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 AcknowledgmentIn addition, the alarm zone of the operator interface shall showthis alarm provided it is the highest priority, unacknowledgedalarm in the system.

The system shall provide for efficient alarm acknowledgmentin a number of ways as follows: Selection of any parameter tag for the point in alarm from

a custom graphic and pressing the dedicatedacknowledge 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 alarmsummary display

On acknowledgment by the operator, the flashing indicator shall turn to a presentation format designated for acknowledgedalarms (e.g., acknowledge color, steady, not flashing), and the parameter shall remain in that presentation format on any

Page 27 of 62


28/62

system or custom graphic. Should the point go out of alarm before being acknowledged by the operator, the alarm shall beshown by a designated presentation format and remain in thelist until specifically acknowledged by the operator.

Alarms shall be configurable to be annunciated by: Alarm message appearing on dedicated alarm line onoperator 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 onnetwork connected operator stations as long as the computer running the operator station software remains logicallyconnected to the network.

3.4.4. Alarm LoggingAll new alarms shall be configurable to be logged on allalarm/event loggers, written to a disk file in a readable fileformat, placed into the active alarm summary display windowand audibly annunciated.

3.4.5. Alarm NavigationThe alarm manager "pop up" support window shall include theability to have the alarm manager present the operator with animmediate means of going directly to the display page which isrequired to investigate the source of the new alarms. If a seriesof new alarms are received at the operator station, and all of them happen to be associated with the user-defined alarmgroup, the pop-up window shall be pre-set to immediately callup the graphic display page for that group.

3.4.6. Alarm ArchivingAlarm management functions, including archive recording of alarms and events, the recording of operator acknowledgementof alarms, the enable and disable of point and group alarming, plus the annunciation and logging of alarms, shall be providedat all operator stations.

3 . 5 . Trending The system shall support three levels of trending: real-time trending, short-termhistorical trending, and archive/retrieval of short-term trending for indefinite

Page 28 of 62


29/62

periods. System graphics/display builder shall include the creation of "trendwindows" which can be used to pull real-time values from the system and plotthem vs. time on the screen. The trend windows shall be assigned to selectedvariables in the database, including measurements, calculated values, manuallyinputted data, and binary (discrete, state-based) values.

Operator workstations are to be capable of displaying both historical and currenttag values using trends. At runtime, when an operator opens a graphic displaycontaining 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 datacomes from a data log model.

Two types of trend charts are to be available. A standard chart plots tag valuesagainst time, whereas a XY plot chart plots the values of one or more tagsagainst another tag. For example, the temperature of a tank could be plottedagainst 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 andhistorical trend information. Data collected in any historical packageshall be available to all workstations. The system must support acentralized approach to historical data collection.

The system shall support operator defined sets of trends so that commonlyviewed historical information can be defined in trends once and easilyaccessed by selecting a pre-configured screen target incorporated inthe graphic display. There should be no practical limit to the number of trends that can be defined. Each trend screen shall support up toeight (8) separate pens. Selection of points to be trended shall be menu

driven. Historical trends shall support seamless integration of both real-time andhistorical data within a single trend window, with seamless movement between the two. In the event that the screen should be scrolled to theleft, then historical values will be recalled from historical data files.Scrolling the trend far enough to the right will result in current real-time data being displayed as it should be collected.

Zoom in/out and moving forwards and backwards in time shall be possiblewith no more than two operator actions. A mechanism for selecting alocation on the trend, such as a hairline cursor and reading the numericvalues of the trends at that point in time shall be provided.

It shall be possible to call up new historic trends and configure them onlinefrom the Operator Interface. Pre-configured real-time trends shall be available from a faceplate.

3.5.1. Trend DataThe trending shall be configurable for dynamic updates at auser-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


30/62

The control system shall provide trending capability with thefollowing 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 thesame point offset in time, or different points must be possible.

Trend De-cluttering via per-pen enable/disable onmulti-plot style trends

Independent Y-axis per point on multi-plot styletrends. It shall be possible to display the Y-axis for any point on the trend by simply selecting the pointusing the mouse or keyboard.

Copying the currently displayed trend data to theclipboard 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-configuredreports for managing devices, equipment, alarms, events and control loops, aswell as batch or production run and shift reports. The application is to includetrending and dashboard capabilities for analysis and uses Microsoft Excel for report generation.

In addition to gathering data from control system, the reporting software shouldfeature 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 allowusers to report critical data. Reports that can be configured as graphical displaysand then printed, created using VBA within the operator interface developmentsoftware, or created via third-party software such as Microsoft Word, MicrosoftExcel and Crystal Reports are to be supported.

The Operator Interface shall provide an integral reporting subsystem usedto report both current and archived data.

The reporting subsystem shall utilize standard a Windows tree/list view

Page 30 of 62


31/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 besupplied which can be modified or used as should be.

The reporting subsystem shall provide the capability todefine both the dynamic and static properties reports,including but not limited to: archived data, alarmdata, 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 reportsthat 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 GenerationHourly, daily, monthly, end-of-month, quarterly and yearlyreports shall be supported. Reports shall be capable of beingprinted and/or saved to disk when a process event occurs. It shallbe possible to activate a report in any of the following manners:u pon demand by operator request, scheduled (shift, daily and monthly), and upon predefined events.

4. Process ControllersThe controller shall be a multi-tasking, real-time microprocessor with the ability to

simultaneously manage multiple activities. The controller shall be able to performcontinuous and regulatory control on dozens of "loops" while concurrently executingsafety interlock logic, as well as executing hundreds of algebraic calculations, all of which will be defined at, and down-loaded from, the operator stations. Thecommunications 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 shallconsist of an IEC 61131-6 and ANSI/ISA-88 compliant editor.It shall represent the multi-tasking operating system of thesystem controllers with a graphical tree view showing tasks, programs, phases, and routines.

The logic editor shall support the creation of routines in anyone or more of the following four programming languages:

Page 31 of 62


32/62

Function Block Diagram Graphical representation of the algorithm used to create and manage process loops.

Ladder Diagram Graphical representation similar toelectrical relay circuits where rungs of logic performsequential operations.

Sequential Function Chart Graphical flow diagramused to organize and sequence the operation. Structured Text Textual basic like language useful for

developing custom algorithms and string textmanipulation.

The editor shall provide the ability to drag-and-drop to moveinstructions, logic, routines, programs, and tasks either within asingle project or between projects to create detailed projectlibraries.

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-partytools such as Microsoft Excel.

Full Project Import/Export this ASCII representationof a controller project shall provide access to create andmanipulate the project using other text editors.

Partial Import/Export Online or Offline The systemshall support the import or export of specific, user-selected portions of logic, into and out of both arunning 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 thesystem.

4 . 2 . C ontroller Runtime ModificationsControllers 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/Omodules, all while the system is fully operational. Additionally, application codewritten in Function Block Diagram, Ladder Diagram, Sequential Function Chartor Structured Text should be capable of being modified, tested and downloadedwhile the system continues to operate.

In addition to being able to modify a controllers contents while running, multipleusers should have simultaneously access to a running controller. Changes made

Page 32 of 62


33/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 controllers configurationdatabase. Controllers shall support the upload andreconstruction of their configuration while running.

4 . 4 . Controller CommunicationsThe controller shall be fully functional with "peer" ability to initiatecommunication transactions among other controllers, and with operator stations,gateways and other computers on the LAN(s). If a controller requires ameasurement from another controller or gateway, it shall merely request theowner of the measurement to begin sending value updates, as the measurementchanges, until such time as the requesting controller advises that it no longer needs value updates. All data transfers from the controller(s), after the initialtransmission of current value and status, shall be done on an exception basis. Inorder to make the best use of available LAN bandwidth, the system shall use areport by exception/alarm scheme.

4 . 5 . Control Strategy Development As a minimum the controller should contain continuous, discrete and sequentialcontrol functions. Associated controller logic (such as a regulatory loop) should be able to be defined within a control object or control module. This controlobject can encapsulate the control logic and provide a means to monitor andinteract 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 controlmodules/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 2000milliseconds. All control objects, regardless of function block content,shall be able to execute at any of these rates. Note that all function blockswithin a control object shall execute at the same rate.

Peer-to-peer communications that provide for the direct transfer of processdata 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 redundantcontroller system.

A controller shall be capable of being inserted under power, withoutupsetting the process being controlled by other controllers.

Page 33 of 62


34/62

4 . 6 . Controller Configuration LanguagesConfiguration languages shall be offered that are traditionally associated with both a PLC and DCS programming environment. These shall include thefollowing 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 theability 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 DiagramFunction Block Diagram (FBD) instructions are required

provide the building blocks needed to perform sophisticated process and drive control. Control strategies can be created ina familiar way utilizing flow representations of applications.Active X faceplates can be utilized for instructions commonlyused with operator interfaces (Enhanced PID, Ramp/Soak, etc.)and online visualization of FBD process data should be alsosupported by the system.

To make it easier to navigate through a FBD routine, thesystem shall give the users the capability to divide the routineinto a series of sheets which helps organize function blocks and

makes them easier to visualize and search. This shall not affectthe order in which the function blocks. In general, one sheetshould be used for each device (motor, valve, etc.)

System FBD routines shall automatically determine thefunction block execution order.

Page 34 of 62


35/62

4.6.2. Sequential Function ChartSequential Function Charts (SFC) shall be available. SFC is astructured, IEC 61131-3 compliant, high-level control programming language.

The SFC shall include the following features: It shall provide the necessary facilities for real-timecontrol of sequential processes.

It shall have access to process control and other database information.

It shall be possible to modify the program logic whileother sequences are active.

It shall support execution of the chart in Manual or Automatic Mode.

It shall be possible to configure multiple states within asingle SFC container. This allows for effectivecoordination of sequences which have more than onemode (e.g., Heating and Cooling) or that contain safe-state logic (e.g., Aborting or Holding Logic)

The ability to create master SFC elements which can becopied and used throughout the configuration just like afunction block.

A Sequential Function Chart (SFC) is similar to a flowchart of a process. It should be a highly visual language used by thesystem to organize the functional specification for controlsystems as a series of steps and transitions. A step represents amajor function of the process and contains the actions thatoccur at a particular time, phase, or station. A transition is thetrue or false condition that tells the SFC when to proceed to thenext step.

Step transitions and step actions shall support the structuredtext language for configuration of transition logic as well asindividual actions for steps.

4.6.3. Structured TextThe system should support Structured Text (ST), a textual- based control function that uses statements to define what toexecute. It is a, high level programming language similar toBasic or C which shall be used to program complexmathematical operations that would be difficult with other control functions.

Two types of expressions, Boolean and numeric, can be used inST. Boolean expressions compare values or check if

Page 35 of 62


36/62

conditions are true or false and numeric expressionscalculate 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 DiagramLadder Diagram (LD) should be supported by the system. Itshould be a rung-based control function that may be utilized todevelop sequential control applications such as conveyors,machine control, and interlocks. LD can also be utilized to

manage motion and servo control needs and easily performmessaging and serial communications.

4.6.5. User Defined Functions and TagsThe system should support the creation of libraries of commonly used instructions and templates that can be reusedthroughout 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 Diagramroutines.

Can be animated Provide instruction source protection with systems

word and view only or complete source lockingoptions.

Defined once in a project and can be shared bymultiple controller programs.

The number of add-on instructions should be limitedonly by controller memory.

Users should be able to organize multiple tags of different datatypes into a single user defined tag structure.

4 . 7 . Alarm and Event DetectionAlarms and events are to be detected quickly so that operators can be immediatelynotified of critical conditions. Alarm and event detection and processing are to beincorporated directly into the controllers.

Alarm and event detection features should include:

Page 36 of 62


37/62

Alarm triggers based on analog tags, digital tags, or control functionexpressions

Digital alarms - single state / bit detection Analog alarms LL, L, H, HH, Rate of Change detection Configurable alarm detection options such as delay time