DCS Process Contro PlantPax

Rockwell Automation WW Control Solution Procurement Specifications

Procurement SpecificationDocument Control System


Plant Wide DCS Process Control System

Procurement Specification

Document

WW EMEA Procurement Control System Draft 1 Page 2 of 110


Table of Contents

1. System Specification Overview............................................................................10

2. System Architecture Requirements.....................................................................10

2.1. System Scalability..................................................................................................102.1.1. Controller Capacity...............................................................................................................112.1.2. I/O Network and I/O Capacity..............................................................................................112.1.3. Controller Application Capacity............................................................................................11

2.2. System Redundancy...............................................................................................11

2.3. System Expansion..................................................................................................11

2.4. Software Revisions................................................................................................11

2.5. System Sever.........................................................................................................112.5.1. HMI Server...........................................................................................................................122.5.2. Data Server...........................................................................................................................122.5.3. Alarm Server.........................................................................................................................122.5.4. Domain Server......................................................................................................................122.5.5. Security Server.....................................................................................................................122.5.6. License Server......................................................................................................................132.5.7. Historian Server....................................................................................................................132.5.8. OPC Server...........................................................................................................................132.5.9. Batch Server.........................................................................................................................13

2.6. System Services.....................................................................................................142.6.1. Distributed Data...................................................................................................................142.6.2. Directory Service..................................................................................................................142.6.3. Alarms and Events................................................................................................................152.6.4. Security................................................................................................................................15

2.7. Networks...............................................................................................................152.7.1. Network Management.........................................................................................................152.7.2. Supervisory Network............................................................................................................152.7.3. Control Network...................................................................................................................152.7.4. Control Network Redundancy and Alarming........................................................................16

2.8. I/O.........................................................................................................................162.8.1. Analog I/O............................................................................................................................162.8.2. Discrete I/O..........................................................................................................................162.8.3. High-Speed I/O.....................................................................................................................162.8.4. Chassis Based I/O.................................................................................................................172.8.5. Distributed In-Cabinet I/O....................................................................................................172.8.6. Distributed On-Machine I/O.................................................................................................172.8.7. Intrinsically Safe I/O.............................................................................................................172.8.8. Conformally Coated I/O........................................................................................................182.8.9. Adding or replacing I/O Modules Online..............................................................................18

2.9. Field Device Interfaces and Device networks..........................................................182.9.1. DeviceNet.............................................................................................................................18

Jose Luis SanchezWW EMEA GITC Page 3 4/21/2023


2.9.2. HART I/O..............................................................................................................................182.9.3. Foundation Fieldbus I/O.......................................................................................................192.9.4. Profibus I/O..........................................................................................................................192.9.5. Intelligent Device Management...........................................................................................20

3. System Configuration, Visualization and Maintenance........................................20

3.1. Engineering Workstation.......................................................................................203.1.1. Engineering Workstation Configuration...............................................................................203.1.2. Engineering Workstation Functions.....................................................................................213.1.3. Reusable Applications..........................................................................................................21

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

3.3. Operator Interface Visualization............................................................................243.3.1. Operator Station Redundancy..............................................................................................243.3.2. Operator Station Security.....................................................................................................243.3.3. Area Security........................................................................................................................243.3.4. Alarm Window.....................................................................................................................243.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...................................................................................................................263.4.3. Alarm Acknowledgment.......................................................................................................263.4.4. Alarm Logging.......................................................................................................................273.4.5. Alarm Navigation..................................................................................................................273.4.6. Alarm Archiving....................................................................................................................27

3.5. Trending................................................................................................................283.5.1. Trend Data...........................................................................................................................28

3.6. Reports..................................................................................................................29

3.7. Report Generation.................................................................................................30

4. Process Controllers..............................................................................................30

4.1. Controller Programming Environment...................................................................304.1.1. Controller Editor...................................................................................................................30

4.2. Controller Runtime Modifications..........................................................................31

4.3. Controller Restore / Upload...................................................................................31

4.4. Controller Communications...................................................................................31

4.5. Control Strategy Development...............................................................................31

4.6. Controller Configuration Languages.......................................................................324.6.1. Function Block Diagram........................................................................................................324.6.2. Sequential Function Chart....................................................................................................334.6.3. Structured Text.....................................................................................................................334.6.4. Ladder Diagram....................................................................................................................34



4.6.5. User Defined Functions and Tags.........................................................................................34

4.7. Alarm and Event Detection....................................................................................34

4.8. Process Control......................................................................................................344.8.1. PIDE Loop Control................................................................................................................344.8.2. PIDE Integrated Auto-Tune..................................................................................................354.8.3. PIDE Optimized Auto-Tune...................................................................................................354.8.4. Standard Library for Controller............................................................................................354.8.5. Computational Functions.....................................................................................................364.8.6. Discrete Control Functions...................................................................................................364.8.7. Advanced Regulatory Control...............................................................................................364.8.8. Fuzzy Logic...........................................................................................................................36

4.9. Batch & Sequencing Control...................................................................................374.9.1. Basic Batch & Sequencing....................................................................................................374.9.2. Comprehensive Batch & Sequencing....................................................................................37

4.10. Drive Control.........................................................................................................37

4.11. Motion Control......................................................................................................38

4.12. SCADA and Third Party Connectivity......................................................................384.12.1. OPC Interface...................................................................................................................394.12.2. Serial Interface................................................................................................................394.12.3. Ethernet...........................................................................................................................394.12.4. Third Party PLC Communication......................................................................................394.12.5. Third Party DCS Communication......................................................................................39

4.13. Controller Application Code Security......................................................................40

4.14. Process and System Simulation..............................................................................40

5. Production Management....................................................................................40

5.1. Historical Data Archiving........................................................................................40

5.2. Plant Data Historian...............................................................................................41

5.3. Historical Data Reporting.......................................................................................41

5.4. Dynamic Resource Management............................................................................41

5.5. Batch Reporting.....................................................................................................42

5.6. Batch Recipe Management....................................................................................42

5.7. Material Tracking...................................................................................................43

5.8. MES Interface........................................................................................................43

5.9. Integrated Asset Management...............................................................................43

6. Service and Support............................................................................................44

6.1. Training.................................................................................................................446.1.1. Operator Training.................................................................................................................446.1.2. Maintenance and Hardware Training...................................................................................456.1.3. Engineering Training.............................................................................................................45

6.2. Technical Support..................................................................................................46



6.2.1. Onsite Support Services.......................................................................................................46

7. Hardware Specifications.....................................................................................47

7.1. Inputs and Outputs................................................................................................477.1.1. Analog Inputs.......................................................................................................................487.1.2. Digital Inputs........................................................................................................................497.1.3. Analog Outputs....................................................................................................................497.1.4. Digital Outputs.....................................................................................................................497.1.5. I/O Terminations..................................................................................................................497.1.6. Spare Capacity......................................................................................................................49

7.2. Controller Removal and Insertion under Power.....................................................50

7.3. Controller Redundancy..........................................................................................50

7.4. Controller Redundancy Switch-over Time..............................................................50

7.5. Safety Controllers - SIL...........................................................................................50

7.6. Controller Power Supplies.....................................................................................50

7.7. Controller Memory Backup....................................................................................51

7.8. Controller Memory Expandability..........................................................................51

7.9. Controller Footprints.............................................................................................51

7.10. Cabinets................................................................................................................51

7.11. Warranty Information............................................................................................51

8. Electrical Requirements......................................................................................52

8.1. Field Instrumentation............................................................................................52

9. Environmental Conditions...................................................................................52

9.1. Indoor Installations................................................................................................52

9.2. Outdoor Installations.............................................................................................52

9.3. Storage Conditions................................................................................................53

10. Appendix A......................................................................................................53

10.1. Definitions.............................................................................................................5310.1.1. Acronyms and Abbreviations...........................................................................................5310.1.2. Terms...............................................................................................................................53

1 Purpose..............................................................................................................59

2 Bidder Requirements..........................................................................................59

2.1 Technical.........................................................................................................592.1.1 Trained Personnel................................................................................................................592.1.2 Experience............................................................................................................................59

2.2 Commercial...........................................................................................................602.2.1 Quotation Submittal Requirements......................................................................................602.2.2 (TBD by End User)................................................................................................................60



3 Basis of Ethernet Services....................................................................................61

3.1 Agency Specification..............................................................................................61

3.2 Manufacturer’s Specifications and Guidelines........................................................61

4 Services to be Supplied........................................................................................61

4.1 Option 1: Ethernet Network Design.......................................................................614.1.1 Requirements Analysis.........................................................................................................614.1.2 Review and Discussion.........................................................................................................624.1.3 Network Design Development.............................................................................................63

4.2 Option 2: Ethernet Network Design Assessment...................................................63

4.2.1 Ethernet Network Design Assessment...................................................................64

4.3 Ethernet Audit.......................................................................................................644.3.1 Installation Measurements and Verifications.......................................................................644.3.2 Configuration Verifications...................................................................................................654.3.3 Operational Network Measurements...................................................................................65

5 Test Equipment Usage and Equipment Specifications..........................................665.1 Ethernet Inactive Network Test Equipment for Copper Media............................................665.2 Ethernet Inactive Network Test Equipment for Fiber Media................................................665.3 Ethernet Active Network Test Equipment............................................................................66

6 Documentation Requirements............................................................................67

6.1 Network Design Deliverables (Option 1 Deliverables)............................................67

6.2 Network Design Assessment Deliverables (Option 2 Deliverables).........................67

6.3 Audit Report Content.............................................................................................68

7 Warranty............................................................................................................69

7.1 Structured Cabling.................................................................................................69

1. General Requirements............................................................................................78

2. Architecture............................................................................................................80

3. Security..................................................................................................................80

4. Application Explorer...............................................................................................82

5. Communications.....................................................................................................82

6. Application Documentation....................................................................................83

7. Tag Database.........................................................................................................83

8. Derived Tags...........................................................................................................84

9. Embedded Variables...............................................................................................84

10. Macro Capabilities................................................................................................84

12. FactoryTalk® Alarms and Events...........................................................................86



13. Data Logging........................................................................................................88

14. Activity Logging....................................................................................................88

15. Local Messages.....................................................................................................89

16. Events...................................................................................................................89

17. Graphic Displays...................................................................................................90

18. Control of Graphic Displays...................................................................................92

19. Trends..................................................................................................................93

20. Expressions...........................................................................................................94

21. Process Faceplates................................................................................................95

22. Recipe Management.............................................................................................96

23. Language Switching..............................................................................................96

24. Global Objects......................................................................................................96

25. Interoperability.....................................................................................................97

26. Networks..............................................................................................................98

27. Client/server Operation........................................................................................98

28. Redundancy..........................................................................................................99

29. Activations..........................................................................................................100

30. Remote Monitoring with Web-based HMI Clients...............................................100

FactoryTalk Historian SE........................................................................................102

Logged Data.............................................................................................................102

Storage Media..........................................................................................................102

FactoryTalk Services Platform.................................................................................102

Data Store................................................................................................................102

Data Compression....................................................................................................102

Calculation Engine..................................................................................................102

FactoryTalk Historian Datalink...............................................................................102

FactoryTalk Historian Processbook.........................................................................102

FactoryTalk View SE Trend Object..........................................................................103

FactoryTalk Asset Centre.........................................................................................104

CENTRALIZED DATABASE..................................................................................104

SOURCE CONTROL...............................................................................................104



AUDITS...................................................................................................................104

EVENTS..................................................................................................................104

SECURITY..............................................................................................................104

NOTIFICATION.....................................................................................................105

REPORTING...........................................................................................................105

SOFTWARE DELIVERY SYSTEM.........................................................................105

SCHEDULER..........................................................................................................105

DISASTER RECOVERY..........................................................................................105

CALIBRATION MANAGEMENT...........................................................................105

FactoryTalk Services Platform.................................................................................105



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 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 ScalabilityThe 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 CapacitySystem 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 CapacitySystem 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 CapacitySystem 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 non-disruptive 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 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 ExpansionThe 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 RevisionsApplication 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 SeverThe 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 ServerThe 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 ServerThe data server links networks and devices to system wide visualization and development components such as HMI clients and engineering workstations. It shall provide 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 ServerThis alarm server alerts operators to critical alarm conditions and maintains a record of alarm status for historical access.

2.5.4. Domain ServerA 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.

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 tag-by-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 ServerThe 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 ServerThe 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 ServerA 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.

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 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, 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 ServiceThere 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. 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 EventsWhen 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. SecurityCentralized 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. NetworksThe 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 ManagementNetwork 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 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 NetworkThe 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 NetworkThe 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 AlarmingFailure 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 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/OThe 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/OThe 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/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 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 high-speed conveyors and finished goods packaging on high speed motion applications.

2.8.4. Chassis Based I/OChassis-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 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/OHighly distributed I/O shall be supported throughout the system including rail-based distributed I/O. Distributed in-cabinet 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/OThe 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 On-Machine 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/ODistributed 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/OAn 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 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 OnlineI/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 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 and temperature measurement instruments.

2.9.1. DeviceNetDeviceNet should be an open, low-cost option the system uses to connect to industrial devices and to eliminate costly and time-consuming 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 device-level 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.

2.9.2. HART I/ODesigned 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/OFoundation 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, configuration faults, operating mode, and maintenance



requests.

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/OThe 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.

3.1.1. Engineering Workstation ConfigurationThe 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 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, 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 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 ConfigurationThe 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 EditorProvided should be a full-featured graphics editor that includes a complete set of drawing objects and sophisticated drawing 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 DisplaysThe 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 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 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 graphics with 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 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 standard QWERTY keyboard of the workstation manufacturer and no other keyboard shall be required for operations.

3.3.1. Operator Station RedundancyThe 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 SecurityThe 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 SecurityEach 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.

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, multi-state 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 ManagementThe 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 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 PrioritiesThe 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.

3.4.2. Alarm DetectionConfiguring 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 AcknowledgmentIn 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 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 LoggingAll 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 NavigationThe 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 ArchivingAlarm 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. TrendingThe system shall support three levels of trending: real-time trending, short-term historical trending, and archive/retrieval of short-term trending for indefinite 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 real-time 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 DataThe 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.

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. ReportsReporting 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 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 GenerationHourly, 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 Control lers 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 EnvironmentThe system shall utilize the same programming environment for process, sequential, drive, motion and safety control programming through out the system.

4.1.1. Controller EditorThe 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:



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, user-selected 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 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/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 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 / UploadIt 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 CommunicationsThe 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 DevelopmentAs 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.

4.6. Controller Configuration LanguagesConfiguration 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 DiagramFunction 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.

4.6.2. Sequential Function ChartSequential 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 safe-state 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 TextThe system should support Structured Text (ST), a textual-based 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 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 DiagramLadder 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.

4.6.5. User Defined Functions and TagsThe 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.7. Alarm and Event DetectionAlarms 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: 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 ControlStandard software algorithms shall be available to perform regulatory control functions, and these shall have easily configurable parameters.

4.8.1. PIDE Loop ControlEnhanced 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-TuneA 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-to-use 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-TuneThe system shall provide advanced open and closed loop tuning and analysis by providing PIDE control loop optimization from an intuitive off-line software tool. The off-line 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 ControllerA 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 FunctionsThe 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

4.8.6. Discrete Control FunctionsThe 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

4.8.7. Advanced Regulatory ControlThe 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.

4.8.8. Fuzzy LogicThe 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.9. Batch & Sequencing ControlThe 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 server-based 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 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 & SequencingThe 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 & SequencingThe 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 ControlSystem 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 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 ControlSystem 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, time-and 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 ConnectivityThe 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.

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 InterfaceThe 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 InterfaceThe 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. EthernetThe 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 CommunicationThe 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 CommunicationThe system should support communication with third party DCS’s, including but not limited to:

Bailey Net/Infi90 Honeywell TDC 2000 Honeywell TDC 3000 Honeywell PlantScape Fisher Provox Rosemount RS3 Moore APACS Westinghouse WDPF Taylor MOD300

4.13. Controller Application Code SecuritySystem 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 SimulationThe 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.

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 ArchivingData 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 HistorianThe 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.

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 ReportingThe 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 ManagementSmart 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

5.5. Batch ReportingData 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 Listingo Batch Summaryo Batch Detail

Material Reports o Material Usageo Forward Track & Trace



o Backward Track & Trace Analysis Reports

o Batch Executiono Batch Duration Comparisono Batch Exceptions

5.6. Batch Recipe ManagementAdvanced 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.

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 TrackingThe 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 InterfaceThe system shall be designed to integrate with business systems and office-automation 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 real-time 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 Inventory and asset management systems

5.9. Integrated Asset ManagementThe 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. TrainingVendor 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.

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 TrainingThe 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 TrainingThe 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 Client and server architecture, including networking



and redundancy The display hierarchy, and the graphical, trending,

alarm, reporting, and batch displays

6.1.3. Engineering TrainingThe 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 SupportThe 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:

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 ServicesThe 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 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:


AnalogHigh Level Analog Input, (10V & 4-20ma)Dynamic analog input (typically vibration)Analog Output, (4-20ma)Analog Output, (10v)Thermocouple InputRTD InputAnalog Input, Voltage And CurrentAnalog Output, Current/VoltageIsolated Discrete Relay24-220 VAC (8 NO & 8 NC) Output24-220 VAC (16 NO) OutputDC Input24 VDC, (Isolated)10-30 VDC, (Diagnostic)24 VDC48 VDC125 VDC(Isolated)

AC Input120 VAC, (Isolated)220 VAC, (Isolated)120 VAC, (Diagnostic)120 VACAC Output120/220 VAC, (Isolated)120 VAC, (Diagnostic)120/220 VACDC Output24 VDC, (Isolated)10-30 VDC, (Diagnostic)24 VDC24 VDC, (Electronically Fused)48 VDC125 VDC, (Isolated)


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 non-isolated 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

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 TerminationsAll 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.

7.1.6. Spare CapacityEach 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 PowerControllers 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 RedundancyControllers 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 fiber-optic 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.

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 TimeIn 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 - SILThe 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 SuppliesRedundant 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 BackupController 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 battery-module 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 ExpandabilityThe 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.

7.9. Controller FootprintsControllers 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 cost-effective 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. CabinetsControl 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 InformationWarranty 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

8.1. Field InstrumentationAll 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 InstallationsEquipment 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 InstallationsIt 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 ConditionsIt 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. Relative humidity (outside the moisture proof container): 5% to 95%.

10.Appendix A

10.1. DefinitionsThis section contains definitions for acronyms, abbreviations, words, and terms as they are used in this document.

10.1.1. Acronyms and AbbreviationsAcronyms 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

10.1.2. TermsTerms 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.

Communications Link: The hardware and software that performs thetransmitting 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 push- button, 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 controldevices.

Function Block: A control bock as defined in IEC 1131-3. See alsoBlock.

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 programfor 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.



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.

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.



VFD Drives premiere Integration and Automatic

Configuration

Procurement SpecificationDocument



a. VFD shall be capable of communications through standard protocols, and will support EtherNet/IP as standard. RS232 or RS485 DF1 optional.

b. The VFD shall be able to communicate with at least two networks at the same time. EtherNet/IP, ControlNet, or DeviceNet are the preferred networks.

c. Disaster Recovery-All VFD parameters shall be able to be configured and viewed using RSLogix 5000 Version 16 or higher. VFD configuration settings shall be stored in the RSLogix 5000 project file and in the ControlLogix processor(s).

d. VFD communications adapter shall have individually selectable fault actions in the case of a communications loss, or if the controller is idle (in program mode or faulted). Selections include faulting the VFD, stopping the VFD, zeroing data written to the VFD, holding the VFD in its last state, and using a user selectable fault configuration.

e. The I/O packet shall consist of VFD status and feedback, command and reference, and at least 8 data words of inputs and 8 data words of outputs that can be dynamically configured to access any parameter.

f. PLC memory tags associated with a VFD I/O packet shall be automatically created within the PLC with descriptive names associated with the respective parameter or function, and also contain the proper data type so no program modification is required.

g. VFD Startup wizards shall be provided to facilitate VFD commissioning and startup.

h. VFDs must be able to be flash updated directly from RSLogix 5000

i. HMI software shall include preprogrammed, off-the-shelf VFD screens / faceplates with Add on Instructions in the PLC that can be readily used to provide VFD status & control, fault & alarm indication with detailed corrective actions/diagnostics, trending, and operator help.

j. When a VFD need to be replace for any reasons the firmware and confiruration should be loaded into the controller to allows an automatic configuration when replaced. That should possible over ethernet network



Ethernet IP Network Procurement Specification

Document



1 Purpose Define and establish Ethernet and EtherNet/IP design and installation testing criteria in accordance with ANSI/TIA or ISO/IEC and ODVA, respectfully, physical media specifications. Define and establish best practices related to optimizing performance of protocols, configuration of switches and host devices. In doing so, this document describes the bidder requirements, the basis of Ethernet services, the services to be supplied, test equipment requirements and usage, documentation requirements, and related warranties.

2 Bidder Requirements

2.1 Technical

2.1.1 Trained PersonnelService Supplier personnel should have completed the Rockwell

Automation EtherNet/IP Training Course, CCP174, or equivalent. The

training should provide in-depth Ethernet knowledge from a company that

is a member of ANSI/TIA, ISO/IEC and ODVA.

2.1.2 ExperienceIndustrial network design provides a foundation upon which performance

and reliability are built. Ethernet and EtherNet/IP network designs will be

based on ANSI/TIA or ISO/IEC and ODVA specifications, respectfully, and

IEEE standards. The service supplier must demonstrate an understanding

of environmental impact to the network and be able to apply the MICE

(Mechanical, Ingress, Climatic / Chemical, and Electromagnetic)

classification system. The service supplier providing the industrial network

design must demonstrate experience working with Ethernet and

EtherNet/IP vendors from Layer 1 through Layer 7, jointly publishing

whitepapers and/or best practices.

Due to the technology involved with Ethernet and its relatively new

implantation in industrial settings and the associated test equipment,

service supplier personnel must show prior experience with Ethernet

systems designs, installations and associated protocols with an emphasis



on EtherNet/IP. This prior experience should also include the testing of

Ethernet systems in an industrial setting. Service supplier personnel must

show prior experience with all test equipment or equivalent, the ability to

interpret the test results, and provide recommendations for any test or

verification that did not meet test specification criteria.

2.2 Commercial

2.2.1 Quotation Submittal Requirements(Specific requirements by issuing company)

2.2.2 (TBD by End User)(Specific requirements by issuing company)



3 Basis of Ethernet Services

3.1 Agency Specification

All tests, verifications, checks, and recommendations shall be in conformance with the

ANSI/TIA or ISO/IEC and ODVA specifications. ANSI/TIA or ISO/IEC and ODVA specifications

define electrical and mechanical parameters that are the basis for all tests and test

equipment usage defined in Sections 4 & 5.

3.2 Manufacturer’s Specifications and Guidelines

All tests, verifications, checks, and recommendations shall be in conformance with all

applicable vendor specifications and guidelines. Manufacturers’ specifications and

guidelines may define additional electrical and mechanical parameters beyond ANSI/TIA or

ISO/IEC and ODVA specifications, and must be included in the basis for all tests and test

equipment usage defined in Sections 4 & 5.

4 Services to be Supplied

4.1 Option 1: Ethernet Network Design

4.1.1 Requirements AnalysisThe analysis will gather and analyze the following network requirements: Expected number of servers and clients Expected number of automation devices Expected layout of the plant and future network via drawing review,

plant walk-through Expected relationship of traffic between servers and clients, servers

and automation devices, and peer-to-peer dependencies between automation devices

Requirements for interconnection into and segregation from the business systems

Corporate network specifications and any other specifications that must be followed

Ethernet network physical media design and installation specification Environment classification

Mechanical Ingress Climatic Electromagnetic

Network validation requirements Re-usable network switch hardware & media and new system impact

when applicable Redundancy requirements, fault tolerance and fault recovery

requirements Performance requirements, capacity requirements, & data mapping Identification of any business, SCADA, IT, video, or other requirements Access, authentication, diagnostic and monitoring requirements



4.1.2 Review and DiscussionThe Ethernet network consultants will conduct a workshop with key project members. These discussions will include a review of the requirements analysis to gain consensus and intended direction for the overall project prior to the initiation of the design documentation. There is no physical deliverable for this project phase but is used for team consensus to move forward with the system design or make any required changes.



4.1.3 Network Design DevelopmentThe Network Design should reference and comply, when applicable, with standards and guidelines such as the Purdue Reference Model for Computer Integrated Manufacturing, ISA 95 & ISA 99, ODVA, and Cisco/Rockwell Automation Reference Architecture for Manufacturing. The network design development consists of creating the following documents based on the requirements analysis, review and discussion: Bills of Material for the following:

Cabling infrastructure Network infrastructure based on MICE classification

Field installation and drawings/ for the following: Cabling physical topology Graphical representation of logical cabling and network topology Interconnections between network infrastructure devices

Detailed configuration of network to include, but may not be limited to the following: VLAN configuration documentation IP address schema to layout IP address standards and assigns IP

addresses to devices Global Switch configuration details for all switches to include, but may

not be limited to the following: IGMP Querier/Snooping VLAN database SNMP Spanning tree protocol Global security parameters

Switch interface configuration details for all switches to include, but may not limited to the following: General interface configuration Speed/Duplex configuration of each port and corresponding end

device Port Mirroring Per port VLAN association Port security

4.2 Option 2: Ethernet Network Design Assessment

The network design assessment offers a review of existing design documentation (physical

topology, logical topology, network layout, Bill of Material (BOM), cable schedules,

configuration plans) to ensure the specified components, network architecture and network

configuration scheme will meet the functional requirements. The deliverable is a summary

of observations, issues, and resolutions with risk ratings. This can be used to ensure all

vendor designs will interconnect without any issues, to verify the design is within your

specific requirements or to offer third-party review.



4.2.1 Ethernet Network Design AssessmentThe Network Design Assessment should reference and comply, when

applicable, with standards and guidelines such as the Purdue Reference

Model for Computer Integrated Manufacturing, ISA 95 & ISA 99, ODVA, and

Cisco/Rockwell Automation Reference Architecture for Manufacturing.

Ethernet Network Design Assessment Services include review of the

following elements:

• Business, functional and informational objectives and requirements• Network drawings• Bill of materials including all devices (servers/clients automation

deviceshub, switch, router, bridge, patch panel) and media for the application data rate

• Hardware specifications for networking devices including switches, repeaters, routers, firewalls, etc

• Logical network configuration• Software specification and configuration• IP address schema• Network application verification (control or information)

4.3 Ethernet Audit

The on-site audit includes testing of the cabling infrastructure (copper and fiber) and network infrastructure (switches) to validate the installation, configuration and operational characteristics of the network with respect to the latest TIA/EIA or ISO/IEC and ODVA Ethernet specification and the previously accepted design. All test data shall be supplied for review and approval by (customer name). Any tested design element that is not in compliance with the applicable design specification shall be noted and a recommendation for corrective action shall be supplied.

4.3.1 Installation Measurements and Verifications Network walk-through to verify all applicable installation specifications

and MICE classifications were followed Visual inspection of all terminations (fiber and copper) Tests of the twisted pair segments to determine if the cable meets the test standards

specified for the LAN installation Headroom Report: The worst-case margin for a parameter determined by the

selected standard. This may be NEXT, ACR-N, PSNEXT, or another measurement Wire Map: Tests for opens, shorts, crossed pairs, reversed wires, and split pairs Resistance: Measures the d.c. loop resistance of each cable pair Length: Displays the length of twisted pairs in feet or meters Propagation Delay: Measures the time taken for a signal to travel the length of each

cable pair Delay Skew: Calculates the difference in propagation delay between the cable pairs NEXT and ACR-F: Tests twisted pair cable for Near-End Crosstalk and Attenuation

Crosstalk Ratio Far-End Insertion Loss: Measures the insertion loss of each cable pair ACR-N: Calculates the ratio of attenuation to crosstalk for all combinations of cable

pairs at the near-end Return Loss: Measures signal loss due to signal reflections in the cable PSACR-N (Power Sum ACR Near-End): For each cable pair, PSACR-N is

calculated using the sum of the ACR-N from the other pairs



PS NEXT (Power Sum NEXT): For each cable pair, PSNEXT is calculated as the sum of the NEXT from all other pairs

PS ACR-F (Power Sum Attenuation Crosstalk Ratio Far-End): For each cable pair, PSACR-F is calculated using the sum of the ACR-F from the other pairs.

Tests of the fiber optic segments to determine if the cable meets the test standards specified for the LAN installation Optical power loss Length Propagation delay

4.3.2 Configuration Verifications

Network walk-through to verify all applicable installation specifications were followed Visual inspection of all terminations (fiber and copper) Testing of the network switches to determine if the switches were correctly configured

per the accepted design. Properties to verify include: Name (SNMP) IP Address Subnet mask Speed, actual and advertised Duplex, actual and advertised VLAN ID(s) (if applicable) Network access (802.1X) (if applicable)

4.3.3 Operational Network Measurements Testing of the operational characteristics of the network (switches and

servers) to determine if the network will performance as designed. Operational characteristics to include: Frame loss rate at maximum design rate: less than 0.1% frames

lost at multiple frame sizes from 64 to 1518 bytes, 10 second duration per frame size

Jitter at maximum design rate: less than 500 µs jitter and less than 20 ms maximum frame spacing at multiple frame sizes from 64 to 1518 bytes, 10 second duration per frame size

DHCP service available and responsive: DHCP server response less than 1 ms for 5 test iterations

DNS service available and responsive: DNS server response less than 1 ms for 5 test iterations

FTP service available and responsive: SYN/ACK response less than 1ms, connect and disconnect in less than 1 ms, read and write rates greater than 300 Kbps, delete file in less than 1 ms (for 5 iterations each test, 250 Kb file size)

Web service available and responsive: web server name lookup in less than 1 ms, SYN/ACK response less than 200 ms, first reply in less than 200 ms, receive time in less than 500 ms, receive speed greater than 20 Kbps (for 5 iterations, URL = www.time.gov).



5 Test Equipment Usage and Equipment Specifications

The following is a list of test equipment along with their specifications to be used during testing. NOTE: All test equipment that requires traceable calibration must have current proof of traceable calibration from the equipment manufacturer.

5.1 Ethernet Inactive Network Test Equipment for Copper Media

The network test tool should be a hand-held instrument that can certify, test, and troubleshoot twisted pair cabling in local area network (LAN) installations. The test tool should offer adapters for testing both RJ45 and M12 D Type connectors. The Permanent Link Adapter shall be terminated with a component compliant RJ45 plug in accordance with ANSI/TIA-568-C.2.

The test tool should include the following features and measure the following parameters:

Capable of testing shielded and unshielded twisted pair (STP, FTP, SSTP and UTP) as well as coax LAN cabling

Capable of testing to the following standards (select which apply) TIA Category 3 and 5e per ANSI/TIA-568-C TIA Category 5 (1000BASE-T) per TIA TSB-95 TIA Category 6 per ANSI/TIA-568-C.0 TIA Category 6A per ANSI/TIA-568-C.0 including Alien Crosstalk TIA TSB-155 (10GBASE-T) including Alien Crosstalk ISO/IEC 11801 Class C, D, E, EA, F including Alien Crosstalk EN 50173 Class C, D, E and F ANSI TP-PMD IEEE 802.3 10BASE-T, 100BASE-TX, 1000BASE-T

Exceeds Level III accuracy requirements for the Permanent Link and Channel per TIA-1152 and IEC 61935-1 (Level IIIe for TIA Category 6A)

High definition time domain diagnostics for Return Loss and NEXT Length Range up to 800 m (2600 ft) - Single-ended Test and 150 m

(490 ft) - Dual-ended Test (Main and Remote) Length Resolution to 0.1 m or 1 ft - Single-ended Test or 0.1 m or 1 ft -

Dual-ended Test (Main and Remote) Length Accuracy to ± (1m 4%) - Single-ended Test ± (1m 4%) - Dual-

ended Test (Main and Remote) Ability to save, upload, manage, print copper test results Test results provided electronically in native format from test

instrument manufacturer with ability to view, organize and print using freely distributed software from same test instrument manufacturer

5.2 Ethernet Inactive Network Test Equipment for Fiber Media

Tier 1 Polarity and optical loss certification per ANSI/TIA-568-C.0 Connection types must include SC, LC ST and FC type connectors/adapters

(select appropriate) Capable of testing 62.5 and 50 μm multimode fiber and 9 μm singlemode fiber Capable of tesing up to 5k multimode cable, 10km of singlemode cable Ability to save, upload, manage, print fiber test results Test results provided electronically in native format from test instrument

manufacturer with ability to view, organize and print using freely distributed software from same test instrument manufacturer

Tier 2 OTDR certification per ANSI/TIA-568-C.0 (optional)

5.3 Ethernet Active Network Test Equipment

General requirements



The network test equipment shall be a portable, battery-operated instrument with capabilities to analyze and troubleshoot network problems in IEEE 802.3 Local Area Networks (LAN). It shall assist in troubleshooting and documenting network problems. It shall enable performance testing of Ethernet links.

The network test equipment shall be capable of real-time monitoring, discovery, and analysis of shared and switched 10BASE-T, 100BASE-TX, 1000BASE-T and 1000BASE-X Ethernet networks.

The test equipment should have the following capabilities. Signal verification providing link signal information including actual and

advertised speed and duplex, signal levels, link partner signaling and auto-negotiation signals.

It shall also solicit for 802.3af Power over Ethernet (PoE) and measure DC voltage on each pin.

Local statistics pertaining to the collision domain of which the test equipment is a member.

Broadcast domain device discovery. The test equipment shall perform active SNMP discovery for all network devices.

Broadcast domain network discovery. The test equipment shall discover networks by IP subnet and NetBIOS domain.

Broadcast domain VLAN discovery. The test equipment shall identify VLAN membership configurations and interface status.

Nearest switch test to find the switch that is closest to the port to which the test equipment is connected.

Switch scan test to continuously monitor the nearest switch plus a second user-selected switch.

Key device test to check the availability of critical devices on the network.

The network test equipment shall be capable of Ethernet performance measurement. The following tests shall be available: loss rate, jitter, RFC2544 throughput, RFC2544 latency, and RFC2544 loss.

The network test equipment shall be capable of network services testing. The following service tests shall be available: DHCP, DNS, e-mail, FTP, NT file, WINS, and Web.

6 Documentation Requirements

6.1 Network Design Deliverables (Option 1 Deliverables)

The Network Design Deliverables consist of the following documents: Network Design Methodology document to define the basic method and

reasoning for the design. This document is a basic framework that the details of the design are based and lays the framework for the component selection, layout and basic configuration.

Completed Bills of Material for the following: Network cabinets Hardware and media

Field installation and cabling schedule or drawings to articulate the cabling Ethernet switch physical drawings Ethernet fiber and/or copper backbone physical topology Logical network topology Detailed connections for all devices Detailed configuration of network Global Switch configuration details for all switches Interface Switch configuration details for all switches

6.2 Network Design Assessment Deliverables (Option 2 Deliverables)

The design assessment deliverable includes the following

• Observations, issues and resolutions



• Network configuration changes• Media replacement suggestions• Network and topology design suggestions to improve overall performance• List of documentation that was not supplied as part of the network design

package

6.3 Audit Report Content

The following summarizes the final report content when applicable. This will include an

executive summary that summarizes the results and provides recommendations to ensure

proper network operation, or approves the installation with no recommendations. The final

report should also include all test results in which the end user has the ability to access,

process, analyze, share, and display the information.

Executive Summary and detailed test results Node count Headroom Report Wire Map Resistance Length Propagation Delay Delay Skew NEXT ACR-F Insertion Loss ACR-N Return Loss PS ACR-N PS NEXT PS ACR-F Optical power loss for fiber Length for fiber Propagation delay for each fiber Fiber termination inspection results Switch configuration

Name (SNMP) IP Address Subnet mask Speed, actual and advertised Duplex, actual and advertised VLAN ID(s) (if applicable)

Operational characteristics Frame loss rate at maximum design rate Jitter at maximum design rate DHCP service available and responsive DNS service available and responsive FTP service available and responsive Web service available and responsive

7 Warranty

7.1 Structured Cabling

All non-consumable products must have a minimum 20-year performance guarantee offered and maintained by the manufacturer of structured cabling and not the



contractor/installer. When installed per ANSI/TIA or ISO/IEC standards the structured cabling will support application(s) which the system was designed to support.



Panel Operator Interface


2.1 GRAPHICAL OPERATOR INTERFACE



A. Manufacturers:1. Model 2711P2. Substitutions: Not Permitted

B. Common Hardware Ratings:

1. The PanelView Plus Operator Terminal shall be of a design with interchangeability provided for all similar PanelView Plus models with different screen sizes.

2. The PanelView Plus Operator Interface system must be able to determine the correctness of the application program to run on its hardware configuration prior to executing the user program.

3. The PanelView Plus Operator Interface shall have downward compatibility whereby all new module designs can be interchanged with all similar modules in an effort to reduce obsolescence.

4. The PanelView Plus Operator Interface hardware shall function continuously in:a. Operating Temperature of range of 0 degrees to plus 55 degrees Cb. Storage Temperature range of minus 20 degrees to plus 70 degrees Cc. Humidity range of 5 to 95% non-condensing

5. The PanelView Plus Operator Interface system shall be UL listed and cUL certified, CE marked for all applicable directives, North American Hazardous Locations Class I, Division II, Groups A.B,C,D, and C-TICK marked for use in continental Australia.

6. The PanelView Plus Operator Interface system shall be designed and tested to operate in the high electrical noise environment of an industrial plant.

7. The PanelView Plus Operator Interface shall have at least one Universal Serial Bus (USB) port that supports a printer. Print operation shall be initiated with a “print” object programmable in the user application.

8. The PanelView Plus Operator Interface shall have one dedicated port which supports communications to the Logic Module via an industrial communications network or RS232 serial connection utilizing industrial secure protocols.

9. A configuration mode on the PanelView Plus terminal shall be provided to adjust display characteristics, memory card (if used), terminal preset, terminal information, data and time and printer setup on demand, and be available from run mode if required.

10. The PanelView Plus Terminal shall be designed to provide for free air flow convection cooling without a fan.

11. The PanelView Plus Terminal shall include indicators showing the following status information:

A. Status of the CPU

B. Communications status for the Logic Module channel

12. Run mode object (button) shall be available to place the PanelView Plus terminal in Run mode on demand from the configuration mode.

13. Non-volatile memory shall store the operating system information to protect against loss in the case of power loss or system shut-down. New PanelView Plus Terminal firmware can be downloaded into the terminal on demand to utilize feature upgrades via compact flash, serial communications, or Ethernet communications.

14. Touch Screen PanelView Operator Terminals shall have the entire screen available for object usage and not be limited by specific templates or function keys.



15. Keypad based PanelView Operator Terminals shall have the function keys relegendable by the user and complete freedom to program the function keys as required by the application specifications.

16. Keypad and Touch combination PanelView Plus Operator Terminal units shall be available to allow users to maximize the number of inputs available in an application.

C. Selection

1. The operator interface shall interface with the programmable logic controller as addressed in this specification or as indicated on the drawings.

2. The operator interface shall be selected from a family of operator interfaces with screen sizes ranging from four to fifteen inches.

D. Programming

A major consideration of the PanelView Plus Operator Interface terminal shall be its programming software, which shall allow development, modification and maintenance of the application program in the PanelView Plus Operator Interface Terminal. The Programming software shall be compatible with the Logic Controller programming software, RSLogix, the Communications systems driver software, RSLinx, be tested to run on Microsoft operating systems including Windows 2000/XP. The capability shall exist to allow for expansion of the system by the addition of hardware and/or user software.

1. A single programming package shall be capable of programming the family of specified graphical operator interface.

2. The software package shall include the following minimum operator devices.A. Push buttons and selectorsB. ASCII entry devices C. Diagnostic indicators D. Message displays E. Embedded numeric and ASCII variable displaysF. Analog and digital gaugesG. TrendsH. Animation of objects

3. The software package shall offer such features as cut, copy, paste, and tag import / export capabilities in and between various PanelView Plus application files.

4. The PanelView Plus Operator Interface system shall be capable of addressing the following data types:

A. Bit 0 or 1B. 4BCD 0 to 9999C. Unsigned Integer 0 to 65535D. Signed Integer -32768 to +32767E. DINT -2,147,483,648 to 2,147,483,647F. SINT -128 to +127G. IEEE Floating Point -99,999,997,952 to 999,999,995,904H. Bit Array 4,294,967,295I. Character Array protocol dependentJ. Bool True or False

E. Programming Techniques

1. The programming format shall involve the placement of input and output objects via the offline programming and configuration package, FactoryTalk View Studio.

2. Input and Output objects shall be linked to the Logic Controller via “tags” Tags will contain the addressing information to access the data in the Logic Controller.



3. The capability shall exist to change a input object from normally open to normally closed, add instructions, change addresses, offline and then download the application to the PanelView terminal.

4. A real time clock shall be included within the PanelView Plus Terminal. Access to the time and date shall be from the user program, or message or alarm generation.

5. The PanelView Plus terminal shall have a user configurable alarm system capable of popping up an alarm banner on a user screen and presenting information that is critical to the user and of immediate use.

6. The Alarm banner shall be configurable to include “Clear Alarm”, “Acknowledge Alarm”, “Print Alarm”, “Print Alarm List”, “Clear Alarm List” and “Acknowledge All Alarms” buttons.

7. The PanelView Plus Terminal shall have solid state RAM memory to store the application program, process data, and alarm status. This memory shall have both capacitor and battery backup in the event that input power to the processor is lost.

8. The PanelView Plus Operator Interface system shall have a minimum total memory capacity of 32 MB.

F. Graphical Operator Interface – Four Inch Display1. The operator interface panel shall be Series 2711P, PanelView Plus 400.2. The operator interface panel shall be a monochrome flat panel display.3. Specifications

a. The display type shall be monochrome passive matrix, film compensated super-twist nematic (FSTN).

b. The display size shall be 3.1 inches wide by 2.3 inches high (78mm wide by 59mm high).

c. The operator input shall be keypad with 8 relegendable function keys, numeric keypad, and cursor controls.

d. The PanelView Plus shall have RS-232 (DF1) communications as standard. Additional communications shall include Ethernet/IP as standard with a choice of optional communications modules, which are determined by catalog number extension or added separately.

*********************************************************Select communication modules to be DH+, Remote I/O, or DH-485. These units are field modifiable.*********************************************************

e. One Universal Serial Bus (USB) port shall be provided for a printer connection, keyboard, or mouse.

f. The standard memory shall be 32 MB Flash memory.g. Provide Compact Flash Memory. Card Selected and sized based upon memory

requirements with a 32MB minimum.h. The unit shall include a battery-backed clock and shall timestamp critical data.i. Agency approvals shall include UL, CSA approved; Class 1, Div 2; Groups A,

B, C, D certified; CE marked; and C-Tick

G. Graphical Operator Interface – Six Inch Display1. The operator interface panel shall be Series 2711P, PanelView Plus.2. The operator interface panel shall be a monochrome flat panel display.3. Specifications

a. The display type shall be monochrome passive matrix, film compensated super-twist nematic (FSTN).


c. The operator input shall be keypad, touch screen, or both.

*********************************************************



Select either touch screen; keypad with 10 relegendable function keys, numeric keypad, and cursor control keys; or both.*********************************************************







H. Graphical Operator Interface – Six Inch Display1. The operator interface panel shall be Series 2711P, PanelView Plus 600.2. The operator interface panel shall be a Color Flat Panel.3. Specifications

a. The display type shall be Active Matrix Thin Film Transistor (TFT) color.b. The display size shall be 4.4 inches wide by 3.3 inches high (111mm wide by

84mm high).c. The operator input shall be keypad, touch screen, or both.

*********************************************************Select either touch screen; keypad with 10 relegendable function keys, numeric keypad, and cursor control keys; or both.*********************************************************







I. Graphical Operator Interface – Seven Inch Display1. The operator interface panel shall be Series 2711P, PanelView Plus 700. 2. The operator interface panel shall be a Color Flat Panel.3. Specifications

a. The display type shall be Active Matrix Thin Film Transistor (TFT) color.




c. The operator input shall be touch screen, keypad, or both.


d. The PanelView Plus shall have Ethernet/IP and RS-232 (DF1) communications as standard. Additional communications shall be determined by catalog number extension or added separately.

*********************************************************Select communication to be, ControlNet or DH+ / Remote I/O / DH-485. Units are field modifiable.*********************************************************

e. Two Universal Serial Bus (USB) ports shall be provided for a printer connection, keyboard, or mouse.



B, C, D certified; CE marked; and C-Tickj. The display shall have a field replaceable backlight.

J. Graphical Operator Interface – Ten Inch Display4. The operator interface panel shall be Series 2711P, PanelView Plus 1000 5. The operator interface panel shall be a Color Flat Panel.6. Specifications


158mm high).c. The operator input shall be touch screen, keypad, or both.








K. Graphical Operator Interface – Twelve Inch Display



7. The operator interface panel shall be Series 2711P, PanelView Plus 1250 8. The operator interface panel shall be a Color Flat Panel.9. Specifications


184mm high).c. The operator input shall be touch screen, keypad, or both.








L. Graphical Operator Interface – Fifteen Inch Display10. The operator interface panel shall be Series 2711P, PanelView Plus 1500 11. The operator interface panel shall be a Color Flat Panel.12. Specifications

k. The display type shall be Active Matrix Thin Film Transistor (TFT) color.l. The display size shall be 12.0 inches wide by 9.0 inches high (304mm wide by

228mm high).m. The operator input shall be touch screen, keypad, or both.


n. The PanelView Plus shall have Ethernet/IP and RS-232 (DF1) communications as standard. Additional communications shall be determined by catalog number extension or added separately.


o. Two Universal Serial Bus (USB) ports shall be provided for a printer connection, keyboard, or mouse.

p. The standard memory shall be 32 MB Flash memory.q. Provide Compact Flash Memory. Card Selected and sized based upon memory

requirements with a 32MB minimum.r. The unit shall include a battery-backed clock and shall timestamp critical data.



s. Agency approvals shall include UL, CSA approved; Class 1, Div 2; Groups A, B, C, D certified; CE marked; and C-Tick

t. The display shall have a field replaceable backlight.

PART 3 EXECUTION

1.1 INSTALLATION

A. Install in accordance with manufacturer’s instructions.

B. Unload, unpack and transport equipment to prevent damage or loss.

C. Replace damaged components as directed by Engineer.

D. Protect from dust and other harmful materials.

1.2 INTERFACE WITH OTHER PRODUCTS

A. Provide all required cables, cords and connections for interface with other control system components.

B. Coordinate size and configuration of enclosure to meet project requirements.

1.3 CLEANING

A. Clean units as recommended by manufacturer.



HMI/SCADA


1. General Requirements

1.1 The operator interface software, herein described as the HMI (Human Machine Interface), shall be an integrated package for developing and running automation applications. The HMI shall be designed for use in Microsoft® Vista Business, Windows 7, Windows XP (including XP SP3), and Windows Server 2003 and 2008. It shall use COM, ODBC, OPC, and ActiveX technologies for optimal performance and integration with other software systems.

1.2 The HMI shall be based on Microsoft user-interface standards. The HMI shall:• store all historical data in local and/or an ODBC-compliant database,• support VBA scripting for integration with other Windows products, and• be able to act as an OPC client to allow for data exchange with a wide

range of process devices.



1.3 The HMI shall support multiple development environment clients that can have simultaneous access to the HMI application.

1.4 The HMI shall support multiple HMI servers in an application. HMI servers can also be redundant.

1.5 The HMI shall support multiple run time clients that can have simultaneous access to the HMIapplication.

1.6 In non-redundant scenarios, the HMI shall support up to two HMI servers hosted on a singlecomputer.

1.7 In redundant scenarios, the HMI shall support up to one HMI servers hosted on a single computer.

1.8 The HMI shall provide a common way to defi ne and authorize secured actions on resources for a set of users or groups and locations.

1.9 The HMI shall allow for seamless integration and interoperability with other Rockwell Automation products to allow for sharing of tag data without duplication of tag databases and other functionality.

1.10 The HMI shall provide an Application Explorer for organizing and working with projects. It shall contain all editors for creating projects and shall display project fi les as they are created. The HMI shall include a large selection of commonly used graphic objects and symbols that can be dragged and dropped into a graphic display. The HMI shall also include a tool that enables adding symbols and addresses created in an Allen-Bradley PLC-5, SLC 500, or ControlLogix program to a project. All project fi les shall be in a directory structure that does not mix application fi les (userdeveloped project fi les) with system fi les, for easy data backup.

1.11 The HMI Application Explorer shall support editing of remote projects from different computers. This enables the separation of confi guration software and run-time software which provides a more stable run-time environment.

1.12 All HMI projects should be viewable and editable from the same engineering stationin the application tree.

1.13 The HMI editor should allow for simultaneous collaboration by multiple developers.

1.14 The HMI shall provide a tool to show the status of installed product patch fi leversions currently installed on a computer.

1.15 The HMI shall provide the ability to design high-level graphics for complex applications either by using its own drawing editor or by importing graphic fi les from other drawing packages such as AutoCAD®, CorelDRAW® and PhotoshopTM. Specifi cally, the HMI shall allow importing of the following fi le formats: WMF, .CLP, .BMP, .TIF, .GIF, .PCX, and .JPEG. The HMI shall include, but not be limited to, the following graphic object animations: position, rotation, size, visibility, color, fi ll, slider, and touch.

1.16 The HMI shall integrate Microsoft Visual Basic for Applications (VBA) as a built-in scripting language to customize and extend applications. The HMI must adopt Microsoft’s Component Object Model (COM) and implement COM technology as a means of exposing open application interfaces to external applications, such as Microsoft Visual Basic (VB). VBA scripting will handle graphics similar to the way



forms and other graphics are handled in VB. This will allow for access to all the events, methods and properties of graphical objects and ActiveX controls in theHMI.

1.17 The HMI shall provide an ‘HMI Server Backup and Restore’ utility that has the ability to backup running HMI servers without shutting down and restore servers into applications.

2. Architecture

2.1 The graphic viewers, or HMI clients, shall be separate from the business logic, or HMIServers, and both are separate from the confi guration software.

2.2 The HMI shall support data servers as a means to communicate with any OPC server.

2.3 The HMI clients shall be able to view tag data from any HMI server or data server inthe application.

2.4 The HMI client shall be able to view displays from any HMI server in the application.

2.5 The HMI shall support direct access to control information. This eliminates the duplication of entering tag database information more than once. The HMI shall support remot 2.6 e editing. Any computer with suffi cient security and the confi guration software installed can add, change or delete any configuration information on any computer in the distributed application.

2.7 The HMI shall support a scalable design environment. The HMI shall support themigration of machine level HMI projects to site level HMI projects.

2.8 The HMI servers shall run as a service and will not have a user interface. This allowsfor secure headless operation and does not require a user to be logged on at the server.

2.9 The HMI shall provide support to confi gure and interact with the server by using theconfiguration software or the HMI client.

3. Security

3.1 The HMI shall use the FactoryTalk® Local Directory and/or Network Directoryprovided by the FactoryTalk® Security services:

• Local Directory: all project elements are located on a single computer and security information is shared with other participating software products located on the same computer.

• Network Directory: information about project elements and security is organized for multiple FactoryTalk-enabled products across multiple computers on a network.



•3.2 FactoryTalk® Security shall use the following policies to defi ne system-wide rulesthat govern how security is implemented:

• System Policies:• Security policies – defi ne general security rules• Audit policies – defi ne what security-related information is audited while

the system is in use• User Rights Assignment policies – defi ne which users can access

particular features• Health Monitoring parameters – defi ne application wide settings to tune

the application and accommodate network issues for a distributed FactoryTalk® system.

• Live Data Policy – defi nes a default communications protocol for a distributed FactoryTalk® system, DCOM or TCP/IP.

• Product Policies: sets of securable features for the individual products in the FactoryTalk® system

3.3 FactoryTalk® Security shall provide a common way to defi ne and authorize secured actions on resources for a set of users or user groups and locations.

3.4 FactoryTalk® Security Policy settings in the Network Directory shall be completely separate from those in the Local Directory.

3.5 The HMI shall provide a tool to confi gure FactoryTalk® Security settings. The HMI shall provide an optional, s 3.6 tand-alone tool for administering a FactoryTalk® system to do the following:

• Create and confi gure application, area, and data server elements in a FactoryTalk® Directory.

• Back up and restore an entire directory, an individual application, or systemwide settings.

• Configure options for routing, logging, and viewing diagnostic messages.

3.7 The HMI shall have the ability to allow certain users or groups of users to access only certain parts of the system. The security shall be based on a series of codes. Each code shall allow the users or groups of users with security privileges for that code, to access the HMI commands, macros, graphic displays, OLE verb controls, and tags allowed by that code. The HMI shall allow assigning individual users combinations of security codes, allowing each user to access diff erent sets of features.

3.8 The security system shall use the Windows security system. This will closely integrate the overall system security model.

3.9 The security system shall allow the use of Windows user accounts and groups. This enables users to be added and removed from the Windows user groups without changing the HMI application.

3.10 The security system shall be able to assign each person a user account with a login name, password, and any desired macros. The desired macros execute on login and logout.

3.11 The HMI shall have a minimum of 16 diff erent security codes.



3.11 The HMI shall have the ability to set up security by either inclusion or exclusion.

3.12 The HMI shall provide a means for operators to change their passwords while a project is running.

3.13 The HMI shall provide increased security through electronic signature control. The signature control will be an ActiveX that will require the user to enter their username and password, and optionally obtain verifi cation from a supervisor, before performing a set-point change, command, or recipe download.

3.14 The HMI shall not allow the update of a given set-point or the execution of a command to occur until the signature has been authorized.

3.15 The HMI shall log all signature control run-time activities to the activity log.

3.16 The HMI shall allow the Windows desktop to be locked out.

3.17 The HMI shall support auto logging out of a user after a confi gurable period of inactivity.

3.18 The HMI shall support action groups to group diff erent actions together and assign security permissions to all of the actions in the group.

3.19 The HMI, with FactoryTalk® Local Directory, shall allow all users to have full access to the directory and to FactoryTalk® View by default. The HMI, with FactoryTalk3.21 ® Network Directory, shall allow all users that are members of the Windows Administrator group on any local computer that is connected to the FactoryTalk® Network Directory, to have full access to the directory and to FactoryTalk® View by default.

3.20 The HMI shall retain the existing security settings when upgrading FactoryTalk® Services Platform.

4. Application Explorer

4.1 The HMI shall provide an Application Explorer to organize and work with HMI servers.

4.2 The Application Explorer shall be able to edit all the HMI servers in a system within the same application tree.

4.3 The Application Explorer shall support drag and drop between HMI servers in an application and between multiple copies of the Application Explorer.

4.4 The Application Explorer shall support a tree view of all the servers and their components.

4.5 The Application Explorer shall allow for editing components and testing components.

4.6 The Application Explorer shall allow for editing of all components in a running HMI system.



4.7 The Application Explorer shall support a folder hierarchy to allow the application to mimic the physical layout of the plant. Folders can be added to the second level of the application tree.

4.8 Folders can contain an HMI server, and any number of data servers.4.9 The HMI shall provide the ability to copy HMI servers between folders without the

need for renaming of components.4.10 The confi guration software shall support security that enables only valid

users to view and edit data.

5. Communications

5.1 The HMI shall provide full optimization of tag writes to contiguous data held in devices, to allow quick and effi cient communication on downloads to any OPC servers that provide write optimization.

5.2 The HMI shall provide communication drivers to Rockwell Automation devices at no additional cost.

5.3 The HMI shall have the ability to switch automatically to a pre-defi ned secondary network if the primary network fails at run time.

5.4 The HMI shall act as an OPC client. The HMI shall support both local and remote OPC connections. During confi guration, the HMI client shall produce a list of all known registered OPC servers. When functioning as an OPC client, the HMI must be able to implement the OPC ‘Browse Namespace’ method.

5.5 The HMI shall automatically scan only required values. When a display opens, the HMI shall request information on the required points. The display will receive updates when the value changes until the display closes.

5.6 The HMI shall support directly referencing the tag in the controller. This eliminates the need to create an HMI tag and greatly reduces the amount of confi guration that is required.

5.7 The HMI shall support data server redundancy. Any OPC data server can have a secondary data server associated with it. If the primary server fails, the defi ned secondary server will take over the OPC connection, providing uninterrupted access to data.

5.8 The HMI shall support a seamless transition during data server fail-over. The fail-over will not require any user interaction from the clients.

5.9 The HMI shall support switching back to the primary data server from the secondary, when the primary data server comes back online. Alternatively, the HMI can remain connected to the secondary data server even if the primary data server becomes available.

5.10 The HMI shall aggregate multiple data sources into a single namespace and a single connection. Clients will not need to manage individual connections to multiple data servers.

5.11 Once a data server is defi ned in the HMI application, it will be available to all HMI



clients.

5.12 The HMI shall provide additional offl ine access to a data server’s namespace. Access to the data server namespace will be available when the data server is offl ine. The data server must be online to obtain run-time values for the data items.

6. Application Documentation

6.1 The HMI shall provide comprehensive documentation of an application by using the Application Documenter utility.

6.2 The HMI shall provide the ability to scan through an entire HMI application to eliminate the need to manually create documentation.

6.3 The HMI shall provide the ability to see tag cross-references showing where both HMI tags and direct tag references with controllers are used throughout the application.

6.4 The HMI shall provide the ability to export the application documentation to an easy-to browse HTML format.

7. Tag Database

7.1 The tag database shall defi ne what HMI tags will be monitored. Each entry in the tag database shall be called an HMI tag.

7.2 The tag database shall be organized in a hierarchy, with each level represented by a folder that can be expanded or collapsed. The HMI shall ha 7.3 ve the ability to update the current value of a tag from the device to which it is connected, and then store that value in RAM so it is immediately accessible to all parts of the HMI.

7.4 The HMI tag database shall provide four types of tags: analog, digital, string, and system. Each tag shall have the ability to receive its data via an OPC server or from memory. A tag with OPC as its data source shall receive its data through any respective OPC server. A tag with memory as its data source shall receive its data from a value table and can be used for local storage purposes.

7.5 The tag database shall provide the ability to generate tag names consisting of up to 256 characters. The tag names shall be able to contain the following characteristics: A through Z, 0 through 9, underscore ( _ ) and dash ( - ).

7.6 The tag database shall provide the ability to enter a tag description, minimum value, maximum value, scale, off set, and units (if analog), on and off labels (if digital), initial value, security access code, and alarming description.

7.7 The tag database shall provide the ability to duplicate, edit, and delete any individual tag or folder of tags.

7.8 The tag database shall have the ability to selectively import tags from an Allen-Bradley PLC/PAC database. Tags imported in this way shall be copied into the database and shall not be shared with the source PLC database.



7.9 The HMI shall have the ability to modify the tag database while a project is running. That is, it shall be possible to add a tag in the run mode to the database (with alarming, data logging, and displays all active) without stopping the project.

8. Derived Tags

8.1 The HMI shall have the ability to create a tag whose value is the result of an expression. The expression can be made up of mathematical operations, tag values, if-then-else logic, and other special functions. The current value of the derived tag shall be stored in an analog, digital or string tag in a value table. Multiple derived tags may reside in the same derived tag fi le or in up to 20 diff erent derived tag fi les that run simultaneously.

8.2 The HMI shall have the ability to specify the evaluation period of the derived tag.

8.3 The HMI shall have the ability to edit derived tags during development or run time.

8.4 The HMI shall have the ability to start and stop derived tag processing while a project is running.

8.5 The HMI shall have the ability to directly write to an HMI tag or a data server tag via a derived tag.

9. Embedded Variables

9.1 The HMI shall support embedded variables to display values that change dynamically at run time by putting placeholders in strings.

9.2 Embedded variables shall consist of any of the following:• Numeric (analog or digital) tags• String tags• Tag placeholders• The time• The date

9.3 The HMI shall allow creating embedded variables in these editors:• Graphic Displays• Local Messages• Information Messages• Alarm Setup

10. Macro Capabilities

10.1 The HMI shall provide a macro capability that executes system commands, userdefined commands, and other macros.

10.2 The HMI macros shall be securable. The HMI shall provide a mechanism to restrict certain users from executing given macros.

10.3 The HMI macro capability shall permit parameter passing of up to seven variables.

10.4 The HMI macro capability shall permit macros to call macros.



10.5 The HMI macro capability shall permit synchronous or asynchronous operation.

10.6 The HMI macro editor shall be a simple text editor permitting other editors to create macro fi les when necessary.

11. HMI Alarming11.1 The HMI shall allow users to set up a complete alarm system.

11.2 The alarm system shall have the ability to monitor any analog or digital tag for alarms. The alarm system database must allow up to 40,000 analog or digital alarm tags per HMI server.

11.3 The alarm system shall have the ability to defi ne up to eight diff erent severity classes to visually distinguish alarms.

11.4 The alarm system shall have the ability to:use system default messages or create unique messages to describe an alarm,log messages to a fi le or ODBC database, to a printer, or to both, and tosuppress alarms for maintenance and tuning purposes.

11.5 The alarm system shall provide a means of displaying up to 2,000 tags that are in alarm per HMI server. This alarm summary display shall be fully confi gurable and shall support blinking colors.The alarm summary di 11.6 splay can contain tags from all servers in the application, and can be viewed from any client in the application.

11.7 In the alarm summary display, a user can acknowledge an alarm. The alarm will then appear as acknowledged to all clients in the application.

11.8 The alarm system shall have the ability to create alarm log fi les periodically, at specifi ed times, and on event. The alarm log system shall have the ability to automatically purge old fi les after a specifi ed time.

11.9 Custom alarm summary objects shall be able to be embedded on any display. It shall be possible to include or exclude any tag in a summary by the use of intelligent fi lters, which must be of the following types:

• wildcard (* or ?) constructs• tag types (analog, digital)• alarm states (‘Faults’, ‘Out of Alarm’ and ‘Only show current tags in

alarm’)• severity (levels 1-8).• Alarm summary objects shall be able to be sorted on the fl y by date or

by severity in• ascending or descending order or by folder.

11.10 The alarm system shall allow online export of an alarm log fi le to the following ODBC format databases:

• Microsoft Access• Oracle• Microsoft SQL Server

11.11 The alarm system shall allow user-defi ned alarms to be generated via a command.



11.12 The alarm system shall allow the operator to write a custom message to the alarm history.

11.13 The alarm system shall allow the operator to call a command or macro when an alarm in the summary is selected. This functionality must pass the following alarm information as comma-separated parameters:

• tag name• alarm type• severity• value• date• time• tag type

11.14 The alarm system shall have the ability to “Identify” alarm corrective action to the operator. The alarm identifi cation must be confi gured during alarm confi guration, and must not require a unique button per alarm on a graphic to implement.

11.15 The alarm system shall have a minimum of eight alarm thresholds capable of dynamically changing during run time via tags. The alarm system shall be able to generate alarms on an increasing threshold, decreasing threshold, or both. It must be possible to disable alarm generation when approaching normal operating range.

11.16 The alarm system shall have the ability to use variable thresholds that are changeable at run time.

11.17 The alarm system shall implement a handshake mechanism between the HMI and the PLC ladder logic that guarantees short duration alarms are recorded in the alarm history fi le. The alarm system must be fl exible in this implementation to allow the PLC ladder logic to reset the bit, or to manage the resetting of the bit, in the HMI.

11.18 The HMI will allow the user to defi ne which computer in the application contains the central log. Log information from all computers in the application will be logged to the central log.

11.19 The HMI will allow the periodic central logging interval to be defi ned by the user, in terms of seconds, minutes, hours or days.

11.20 The HMI will have the ability to create a table in the database for use as central alarm log storage.

11.21 The HMI will have the ability to defi ne a user name and password for the central log database connection.

12. FactoryTalk® Alarms and Events

12.1 FactoryTalk® Alarms and Events shall be a separate alarm monitoring system from the HMI alarming. These two alarm monitoring systems shall not share alarm information.

12.2 The HMI shall support both alarm monitoring systems.

12.3 The FactoryTalk® Alarm and Events shall provide a single, integrated set of alarm information. All participating FactoryTalk® products shall work together to



provide a consistent way to defi ne, manage, log and view alarm and event information across a FactoryTalk® application.

12.4 The FactoryTalk® Alarm and Events shall support tag-based alarming and devicebased alarming.

12.5 The HMI shall support up to two FactoryTalk® Alarms and Events Servers for tagbased alarms and up to two servers for device-based alarms.

12.6 Tag-based alarming shall provide monitoring for a system that includes controllers such as PLC-5s, SLC500s, third party controllers, which communicate through OPCDA servers or if not using the pre-built alarm instructions in Logix 5000 controllers.

12.7 Tag-based alarming shall off er equivalent alarm monitoring as HMI alarming but with an extended feature set.

12.8 Device-based alarm monitoring shall utilize pre-built alarm instructions, available in RSLogix 5000 v16 or later. The controller detects and monitors alarm conditions, keeping all alarms and event processing in the controller.

12.9 The two new alarm instructions in Logix processors are:• ALMD – Boolean alarms• ALMA – Analog alarms

12.10 The pre-built instructions shall be programmed in the controller only once, reducing programming eff ort and errors.

12.11 Device-based alarm monitoring shall eliminate the need for duplicating alarm tags in an HMI server and controller.

12.12 Device-based alarm monitor shall reduce controller communication resources and network overhead by eliminating alarm polling. The alarm status is communicated only when the state changes.

12.13 Device-based alarm monitoring shall provide accurate time stamps on alarm conditions that are generated from Logix5000 controllers.

12.14 Device-based alarm state shall be managed, processed, and preserved by controllers, even if a computer goes down.

12.15 FactoryTalk® Alarms and Events shall support language-switching with alarm messages.

12.16 FactoryTalk® Alarms and Events shall support secure access to alarm and event operations through integration with FactoryTalk® Security.

12.17 FactoryTalk® Alarms and Events shall support up to 20,000 alarms, up to 10,000 of which can be tag-based alarms.

12.18 The FactoryTalk® Alarms and Events shall support associating up to four tags with each alarm to include process data with event information and alarm messages.



12.19 The FactoryTalk® Alarms and Events shall support associating a classifi cation string or alarm class to alarms. The alarms shall support fi ltering with this alarm class string in the alarm viewer objects.

12.20 The FactoryTalk® Alarms shall support associating a FactoryTalk® View command, up to 1,000 characters long, with the alarm.

12.21 The HMI shall support a logging component that manages connections between alarm servers and databases and logs data from each alarm server to an alarm history database.

12.22 FactoryTalk® Alarm and Event logging shall be used with a Microsoft SQL Server2005 Express SP2, Microsoft SQL Server 2008 SP 1, or Microsoft SQL Server 2005 database.12.23 The FactoryTalk® Alarms and Events shall support objects to view and analyze alarms during runtime.

12.24 An Alarm and Event Log Viewer shall allow viewing, fi ltering and printing data from alarm history databases. Third-party database tools can also retrieve, view, analyze, and print alarm history information.The FactoryTalk® Alarm and E 12.25 vent Summary object shall be highly confi gurable. It shall support operator interaction to acknowledge, disable, suppress, fi lter, and sort alarms during run time.

12.26 The FactoryTalk® Alarm and Event Banner object shall be used to monitor and respond to the most serious alarms requiring immediate attention.

12.27 The Alarm and Event Banner shall display only the highest priority, most severe and most recent alarms.

12.28 The FactoryTalk® Alarm Status Explorer object shall be used to enable or disable alarms, suppress or unsuppress alarms, and view operator comments.

12.29 The FactoryTalk® Alarms and Events objects shall subscribe to alarms and events from one or more areas in the FactoryTalk® system.

13. Data Logging

13.1 The HMI shall have the ability to record specifi c tag values under certain conditions. Several models shall defi ne these conditions. The collected data shall be stored in a fi le or ODBC database for displaying in trends, for archiving for later processing or analysis.

13.2 The HMI shall have the ability to start and stop data logging while a project is running.

13.3 The HMI shall be able to run 20 diff erent datalog models simultaneously. The HMI shall have the ability to stop and start datalog models at any time.

13.4 Datalog models must support three diff erent data collection modes: periodic polling, on change, and on demand. The periodic polling rate must have configurable time units of hundredths, tenths, seconds, minutes, hours or days. The default time unit will be seconds.



13.5 The datalog system shall have the ability to create data log fi les periodically, at specifi ed times, on event, and never. The datalog system shall have the ability to automatically purge old fi les or records after a specifi ed time.

13.6 The HMI shall be able to switch to an alternate path if a problem is encountered logging to the primary path. Errors such as ‘low disk space’ and ‘dropped network connections’ must be handled automatically.

13.7 The HMI shall provide a way to automatically merge data logged to an alternate location back to the primary location when the problem is corrected.

13.8 The HMI shall provide a mechanism for renaming the historical data set. It must be possible to link the historical data with a batch or lot ID.

14. Activity Logging

14.1 The HMI shall have the ability to record information about various types of systemactivity. This information shall be stored in the Windows Event fi le or an ODBCdatabase for archiving for later processing or analysis, and/or for displaying andanalyzing with third-party software, such as Crystal Reports and Microsoft Excel. The HMI shall have 14.2 the ability to log message received from a machine level HMI tohave a central log of all HMI activity.

14.3 The activity log shall have the ability to log any of the following: command and macro usage, operator comments, system messages and errors, communication network errors, tag read and write activity, and custom messages.

14.4 The activity log shall allow designating when to clear or overwrite entries and what activities to log.

14.5 The HMI shall have the ability to edit activity logging during development or run time.

14.6 The HMI shall have the ability to conditionally log information to a hard disk and to a status bar by category.

14.7 The HMI shall present the activity information in a dockable window that can be dynamically sesized and scrolled. This activity bar can be re-docked or disabled during run time.

14.8 The HMI shall have the ability to view the activity log from any computer in the application. The HMI shall support periodic central logging of activity log fi le information to an ODBC-compliant database. Central logging will support, but not be limited to, Microsoft Access, Oracle, and Microsoft SQL Server.

14.9 The HMI will allow the user to defi ne which computer in the application contains the central log. Log information from all computers in the application will be logged to the central log.

14.10 The HMI will allow the periodic central logging interval to be defi ned by the user, in terms of seconds, minutes, hours or days.

14.11 The HMI will have the ability to create a table in the ODBC database for use as central activity log storage.



14.12 The HMI will have the ability to defi ne a user name and password for the central log database connection.

14.13 The HMI will have the ability to log the old value, new value and comment for a tag write.

14.14 The HMI will have the ability to add a comment for a command.

15. Local Messages

15.1 The HMI shall support local messages to provide ongoing information on the status of devices and processes.

15.2 The HMI shall provide a Local Messages editor to create local messages and specify their trigger values.

15.3 The HMI shall display the message with the trigger value that matches the connection value assigned.

15.4 The local message display shall show one message at a time from the message file assigned to the local message display.

15.5 The HMI shall support up to 10,000 messages in each message file.

16. Events

16.1 The HMI shall have the ability to trigger actions based on an event that has an expression applied to it. An expression is an equation that contains tag values, mathematical operations, if-then-else logic, or other functions. An action shall have the ability to produce a variety of functions including, but not limited to, initiating a snapshot of tag values, displaying an error screen, and changing a tag value.

16.2 The HMI shall have the ability to specify the evaluation period of events.

16.3 The HMI shall have the ability to edit events during development or run time.

16.4 The HMI shall have the ability to start and stop event processing while a project is running.

16.5The HMI shall have the ability to run 20 event fi les simultaneously.

17. Graphic Displays

17.1 The HMI shall provide a number of ready-made graphic displays (such as RSLogix5000 faceplates) as libraries.

17.2 The HMI shall provide a graphic display editor for creating displays using graphic objects.

17.3 The HMI shall provide, at minimum, the following toolbars:



• graphics• objects• alignment• states• pattern style• foreground color• background color

17.4 The graphic display editor shall have the ability to drag and drop objects from a pre-confi gured graphics library, paste objects that are copied to the clipboard from another Windows application such as Microsoft Word and Microsoft Paint, and insert objects created by another Windows application using OLE. True OLE support is required in that it shall be possible to call up the native application that created the object being inserted and use the native object editing tools from within the HMI.

17.5 The HMI shall provide, at minimum, the following productivity tools: easy access to the object Property Panel, Object Explorer, grid settings, ability to import other graphic formats, zooming, and drag-and-drop features.

17.6 The HMI shall allow creating a new graphic display, adding existing displays from another HMI application, generating complete graphic displays from an XML fi le, and exporting complete graphic displays to an XML fi le for modifi cations done on a third-party text editor. The HMI shall allow single-display or multiple-displays-batch import. The graphic display shall support V 17.7 BA scripting similar to forms in Visual Basic. The HMI shall allow VBA to access 3rd party ActiveX controls and their accompanying properties, methods and events.

17.8 The graphic display native objects shall support properties, methods and events that are accessible via VBA scripting.

17.9 The objects shall support tooltips that can be displayed at runtime. The tooltips shall support embedded variables and be language translatable.

17.10 Toolbars and color palettes shall be docked in optional positions in FactoryTalk® View Studio.

17.11 It shall be possible to customize the color palette. Graphics drawn with a customized color palette shall not require the customized color palette to be present on all runtime computers. Colors must be stored internal to the graphic fi les as Red, Green, Blue numbers, not as palette indexes.

17.12 The graphic display editor shall have context-sensitive “right-click” support on all objects.

17.13 The graphic display editor shall have, at minimum, the following drawing tools and objects: snap, grid, arc, ellipse, freehand line, line, polygon, polyline, rectangle, rounded rectangle, wedge, and text.

17.14 The graphic display editor shall have, at minimum, the following editing tools: undo, redo, cut, copy, paste, delete, duplicate, tag substitution, fl ip, rotate, resize, reshape, align, group, ungroup, send to back, bring to front, fi ll, and color.

17.15 The graphic display editor shall have as a minimum the following viewing tools: zoom in, zoom out, pan, and view entire graphic.



17.16 The graphic display editor shall have the ability to use tag placeholders to provide a way to use one graphic display to represent a number of similar operations.

17.17 The graphic display editor shall provide, at a minimum, the following advanced objects:

• Push buttons, macro buttons, ramp buttons• Numeric display and numeric entry objects• Control List Selector and Piloted Control List Selector objects• Numeric and string pop-up scratchpads and keypads• String display and entry enable objects• Local message display• Alarm, diagnostics log, and information message objects• Time and date objects• Image object• Display navigation objects• Print display button• Login, logout, and Shutdown buttons• List, symbol, and multi-state indicators• Gauges, bar graphs, scales and trends• Alarm banner, alarm list and alarm status list objects• Recipe objects• ActiveX control objectsThe graphic displaye

17.18 ditor shall have the ability to create a screen background byconverting objects to wallpaper. These wallpaper objects cannot be selected or edited.

17.19 The graphic display editor shall allow creating libraries of graphic objects.

17.20 The graphic display editor shall provide a library of graphical images that can be copied on to a display screen and animated.

17.21 The graphic display editor shall allow assigning animations to any object or group of objects. It shall also allow drilling down in a group to modify any object or object attribute without losing any object animations.

17.22 The graphic display editor shall allow animations to be copied from any object to another object.

17.23 The graphic display editor shall provide a text search and replace capability on an object or group of objects. This capability shall allow whole tags or parts of tags to be replaced on an individual confi rmation or replace-all basis.

17.24 The graphic display editor shall permit 1,000 editing operations to be undone and redone.

17.25 The graphic display shall permit specifying display placement anywhere on the screen.

17.26 The graphic display shall permit specifying display size.

17.27 The graphic display shall provide at least two diff erent display types:• Replace, which automatically closes all opened windows



• On Top, which allows the graphic display to display in front of any other display of On Top or Replace types. The On Top display shall also be possible to be kept opened and on top when a Replace display opens at run time.

17.28 The graphic display shall provide an onscreen keyboard for data entry on systems that do not have attached keyboards.

17.29 The graphic display shall provide input fi elds that continuously update, showing the results of downloads.

17.30 The graphic display editor shall provide the option to load a screen into memory but not display it to the operator. This feature allows embedded ActiveX controls to process logic without being seen.

17.31 The graphic display shall allow a confi gurable title and system menu bar.

17.32 The graphic display shall allow all objects within the graphic to use the last acquired value of a tag.

17.33 The graphic display shall allow selecting a color for the following items:• Background• Input background/text• Interactive objects highlight• Object with input focus

17.34 The graphic display shall provide for the inclusion of security, inherited from the HMI security system.

17.35 The HMI shall provide an editor to create multiple local message fi les each containing up to 10,000 messages and associated trigger values.

17.36 The HMI shall allow docking displays to an edge of the run time client window, during runtime. The area of the run time client window available for other displays shall be reduced by the height and width of the docked display. The display shall support docking on the top, bottom, left or right edges of the run time client.

18. Control of Graphic Displays

18.1 The graphic display editor shall have the ability to attach, as a minimum, the following animation to objects: blinking colors, visibility, rotation, horizontal and vertical movement, resizing width and height, fi ll, and touch.

18.2 The graphic display editor shall allow dragging of the object to visually set the range of motion for an object.

18.3 The graphic display editor shall have the ability to attach OLE verb control to an OLE object.

18.4 The graphic display editor shall have the ability to attach control that links an object or display to a key or mouse button, so operators can perform an action by pressing a key or mouse button.

18.5 The graphic display editor shall have the ability to simulate run time with test display capabilities without changing to run time.



18.6 The graphic display editor shall enable automatic scaling of displays to make the porting of applications easier between systems with diff erent display resolutions.

18.7 The graphic display editor shall provide functionality to execute a macro or script on display shutdown, assigned on an individual display basis.

18.8 The graphic display editor shall provide a ‘Command Wizard’ to help users construct HMI commands when attaching animation to graphic objects.

18.9 The graphic display editor shall provide the ability to print any graphic whether running or ot. If the graphic is not running, the command will wait for the graphic to collect all run-time data and when send the results to the printer. It must be possible to print a graphic in the background, ever disturbing the view of the currently running screen. A graphic display,

18.10 when hosting an ActiveX control, shall allow access the properties, methods and events of the ActiveX control through VBA scripting.18.11 The graphic display editor shall provide real-time trends that always include a minimum of 15 minutes of data.18.12 Each graphic shall have a confi gurable update rate to specify the maximum rate at which data servers will send data to the tags used in the display.18.13 The graphic display editor shall off er a quick and convenient way to view the hierarchy of objects in a display to show a tree view of all objects in the display, hierarchy of objects within groups, and highlighting objects by selecting an object type, animation type or tag name.18.14 The graphic display editor shall have the ability to display values that change dynamically at run time by inserting embedded variables into text captions on graphic objects and in message text.18.15 The HMI shall have the ability to use the same graphic display with diff erent sets of tags by assigning tag placeholders to objects instead of tag names and assigning a parameter fi le to the graphic display.18.16 The parameter fi le shall defi ne the tags that the graphic display uses at run time.18.17 The HMI shall provide the ability to generate complete graphic displays from anXML fi le, or to export complete graphic displays to an XML fi le.18.18 The XML import operation shall allow you to:

• create a new graphic display• modify the display settings of one or more graphic displays• create new graphic objects on a new or existing display• update existing graphic objects on a display• modify the following aspects of graphic objects, whether new or

updated:• properties• connections• animations• groupings• wallpaper attribute• key assignments• import multiple XML fi les as a batch in a single step.

18.19 The XML export operation shall allow you to:• create an XML fi le that completely describes a graphic display• export multiple XML fi les in a single step.

19. Trends



19.1 The HMI shall have real-time and historical trending capabilities. It shall also have the ability to display both real-time and historical data at the same time on the same trend.

19.2 The trending feature shall be able to plot data for as many as 100 tags on a single chart, with the ability to make pens visible or invisible during development and run time.

19.3 The trending feature shall have an object model that is accessible via the graphics VBA scripting to access the trend object at run time.

19.4 The trending feature shall have the ability to add or remove tags at run time, either individually or in groups.

19.5 The trending feature shall have the ability to view data points from multiple historical datalog models at the same time.

19.6 The trending feature shall have the ability to perform X-Y plots as well as time plots.

19.7 The trending feature shall have the ability to automatically best fi t the Y-axis data, as well as use the minimum and maximum values of a tag. It shall also have the ability to control the Y-axis with a tag value.

19.8 The trending feature shall have the ability to scale all pens on the same Y-axis, unique Y axis per pen, and isolated pens on the same trend.

19.9 The trending feature shall display the pen’s date, time, and value as a tool tip when the mouse is held over a pen.

19.10 The trending feature shall have the ability to load predefi ned profi les and the ability to witch profi les during run time.

19.11 The trending feature shall display time ranges with millisecond granularity and have the bility to use either standard time or military time.

19.12 The trending feature shall have the ability to pause, resume, and automatically pause when scrolling back in time.

19.13 The trending feature shall support the following refresh rates: milliseconds, seconds, minutes, hours, and on change.

19.14 The trending feature shall have the ability to display a legend. The legend shall be able to display the full tag name, short tag name, or tag description, and be changeable at run time.

19.15 The trending feature shall have the ability to display data logged to either a primary or alternate server.

19.16 The trending feature shall support panning and click-and-drag zooming through data.

19.17 The trending feature shall support printing of only the trend and legend and not the entire display.



19.18 The trending feature shall contain a confi gurable real-time data buff er. The trending feature shall support p 19.19 arameter passing to simplify trend and display management.

19.20 The HMI trend shall support FactoryTalk Historian Site Edition data.

20. Expressions

20.1 The HMI shall have the ability to compare data to other values, combine data with other data, and create cause-eff ect relationships with other data.

20.2 Expressions shall have the ability to be used, at a minimum, in any one of the following:

• Graphic displays• Alarm setup• Information setup• Macros• Global connections

20.3 Expressions shall have the ability to be built from, at a minimum:• tag values• constants• mathematical, relational, logical and bit-wise operators• built-in functions• if-then-else logic.

20.4 Expressions shall have the ability to be used, at a minimum, in any one of the following: graphic display, derived tag, event, activity log, data log, or any alarm.

20.5 The expression editor shall have the ability to use effi ciency tools like cut, copy, andpaste to produce like expressions.

20.6 The expression editor shall have the ability to use, at a minimum, the following arithmetic operators: addition, subtraction, multiplication, division, modulus, and exponent.

20.7 The expression editor shall have the ability to use, at a minimum, the following relational operators: equal, not equal, less than, greater than, less than or equal to, and greater than or equal to.

20.8 The expression editor shall have the ability to use, at a minimum, the followinglogical operators: AND, OR, and negation.

20.9 The expression editor shall have the ability to use, at a minimum, the following bit-wise operators: AND, inclusive OR, exclusive OR, right shift, left shift, and complement.

20.10 A command wizard shall facilitate creating actions that trigger when the expressionevaluates true.

21. Process Faceplates



21.1 The HMI shall provide process faceplates to help reduce development time. These displays along with corresponding images shall be easily added to the HMI application and quickly connected to Logix5000 instructions to enable setting up and running with minimal eff ort.

21.2 The HMI shall provide sets of faceplates that work with Logix5000 instructions, a consistent look and feel across all displays, and global objects that can be re-used in regular displays.

21.3 The built-in process faceplates shall be translated to English, French, Spanish, German,Chinese and Japanese.

21.4 Process faceplates shall work with the following Logix5000 instructions:• Enhanced PID (PIDE)• Discrete 2-State Device (D2SD)• Discrete 3-State Device (D3SD)• Totalizer (TOT)• Enhanced Select (ESEL)• Alarm (ALM)• Alarm Analog (ALMA)• Alarm Digital (ALMD)• Ramp/Soak (RMPS)• PhaseManager (PhaseManager)• Internal Model Control (IMC)• Coordinated Control (CC)• Modular Multivariable Control (MMC)

22. Recipe Management

22.1 The HMI shall have the ability to perform recipe management functions. The recipesystem shall allow uploading and downloading recipe fi les.

22.2 The recipe system shall allow issuing a command before a recipe is downloaded andafter downloading has completed.

22.3 The recipe system shall allow verifying communications before downloading, verifyingthe download completed successfully, and logging errors if a download fails.

22.4 The recipe system shall allow previewing a download before it occurs and adjusting thevalues before downloading.

23. Language Switching

23.1 The HMI shall provide the ability to confi gure multiple language versions of an application and switch application languages dynamically at run time, with a specifi ed language at startup, which could be changed while the application is running on the client using the Language command.



23.2 The HMI shall also allow the application to be opened in a particular language fordevelopment purposes.

23.3 The HMI shall support a project default language.

23.4 The HMI shall support up to 40 languages in each HMI application.

23.5 The HMI shall have the ability to add or remove languages when developing HMIapplications.

23.6 The HMI shall provide the option to support multiple languages in the library displays.

23.7 The HMI shall allow the selection of desired languages to be included in the run-timeapplication.

23.8 The HMI shall allow exporting user-defi ned text strings into an editable fi le in UNICODEformat and later importing it back with translated strings. The HMI shall be able to export and import user-defi ned string such as the title bar, labels and captions in graphics displays, and embedded string variables.

23.9 The HMI shall provide a string spreadsheet editing feature to export and import language switchable strings to and from Excel for editing or translation. The string spreadsheet editor shall support the Optimized Strings feature, which enables one-time editing to recurring strings.

23.10 The HMI shall provide a language function that returns the ID of the current run-timelanguage.

24. Global Objects

24.1 The HMI shall allow linking the appearance and behavior of a graphic object to multiplecopies of that object in the same application to help develop and maintain repetitiveobjects more easily. When changes are made to the base objects, the copies shall bechanged accordingly.

24.2 The HMI shall provide a global object display editor for creating global objects.

24.3 The HMI shall allow creating a new global object display, adding existing displays fromanother HMI application as global object displays, and importing XML information exported from another global object display or a standard display into an existing global object display.

24.4 The HMI shall have the ability to create base objects from all standard objects exceptfor ActiveX controls.

24.5 The HMI shall provide the ability to drag and drop global objects onto standard displays



to create reference objects.

24.6 When changes are made to the base object, its reference objects shall inherit the samechanges. Reference 24.7 objects shall display the following properties in the Property Panel:

• Common properties: name, size, position, and visibility• A state property if applicable, and• Link properties: animation, connections, and size.

24.8 The HMI shall be able to modify the link properties of a reference object to determinewhich information the reference object will receive from the base object.

24.9 The HMI shall be able to break the links between the reference objects and its baseobject. This object shall become a standard graphic object.

24.10 The HMI shall provide default values for the link properties assigned to a referenceobject when it is created. These default values shall be editable as well.

24.11 The HMI shall allow parameters to be defi ned for global objects. This allows theuse of global objects without having to break the link to the base object’s tags and expressions. Structured tag support shall be available.

24.12 The HMI shall provide faceplates that support RSLogix instructions available as globalobjects.

25. Interoperability

25.1 The HMI shall be based on standards that allow the HMI’s data to be accessed, sharedamong, and be fully interoperable with other Windows applications.

25.2 The HMI’s graphic displays shall be containers for ActiveX controls and be able to accessthe controls’ methods, properties and events via VBA scripting.

25.3 The HMI shall log all data in fi les in an ODBC database for easy retrieval in otherprograms such as Microsoft Excel.

25.4 The HMI’s database editor shall allow browsing the ladder/control scheme documentation for direct tag import. This capability shall consist of a wizard that enables on-the-fl y tag creation without recompiling.



26. Networks

26.1 The HMI shall use Windows security to support a centralized and secure user name andpassword repository.

26.2 The HMI shall support a Windows 2003 and higher domain.

26.3 The HMI shall support a Windows Workgroup.

27. Client/server Operation27.1 The HMI shall permit client/server operation whereby graphics functionality (fulloperations) shall be provided at a client station.

27.2 The HMI server shall leverage Microsoft Windows 2003 and higher technology.

27.3 An application shall support multiple HMI servers.

27.4 An application shall support multiple client connections at any one time.

27.5 An application shall support multiple Data servers.

27.6 HMI client/server operation shall use Microsoft ActiveX technology and standardInternet Information Services (IIS) functionality.

27.7 The client shall support Windows 2000 Professional, Windows 2000 Server, Windows2003 Server, Windows XP, and Windows Vista.

27.8 The HMI clients/servers shall implement security via Microsoft’s Windows securitymodel, hence a Windows Primary Domain Controller may be required to facilitate this.

27.9 Client stations are desired to be thin clients. Performance shall not degrade at the thinclient in terms of display refresh or display call-up. (For example, displays on the client refresh at a rate equal to or better than the rate possible on the server).

27.10 The client software shall use a set-up wizard for initial confi guration. The set-up wizardwill allow the user to decide whether the client has full access or view-only operation.

27.11 Two forms of client licensing schemes will be available: Dedicated Clients (require alicense fi le on the client) and Floating Clients (require a license fi le on the HMI server computer).

27.12 The client computers must cache copies of the HMI project graphics locally and be ableto automatically copy the latest graphic from the server(s) as required.



27.13 The client shall support auto downloading of an ActiveX control if the ActiveX control isnot present on the client or the version has changed.

27.14 The HMI Client shall support the use of Terminal Services to lower the total cost ofownership.

27.15 The HMI shall support many run-time edits, changes that take eff ect immediately andchanges that require a non-disruptive action, such as reopening a graphic display. Some of the run-time edits include tag edits and alarm edits.

28. Redundancy

28.1 The HMI shall support redundant HMI servers.

28.2 The HMI shall support redundant Data servers, both RSLinx Enterprise and other OPCData Servers.

28.3 The HMI shall support redundant FactoryTalk® Alarms and Events servers.

28.4 The HMI Development Environment shall be used to set up redundancy options for HMIand Data servers.

28.5 The HMI shall support seamless fail over from a primary server to a secondary server.

28.6 The HMI shall support seamless fail back from a secondary server to a primary server.

28.7 The HMI shall support switching back to the primary data server from the secondary, when the primary HMI server comes back online. Alternatively, the HMI can remain connected to the secondary data server even if the primary HMI server becomes available.

28.8 The HMI shall support notifi cation of a service disruption including computer name offailed server. The HMI shall support notifi 28.9 cation service recovery including the computer name of active server.

28.10 The HMI shall support the replication of runtime changes made in the primary HMI Server to the secondary HMI Server from the HMI development environment.

28.11 The HMI shall support a Server Status dialog box to check the current state of a server,change a server’s redundancy options, or manually switch between an Active sever and a Standby server.

28.12 The HMI shall support a controlled, manual switchover from the Active server to the Standby server



28.13 The HMI shall support the use of HMI Development Environment for manual startingand stopping of Startup components on both Primary and Secondary HMI servers.

28.14 The HMI shall ensure the server is not put into an active state until all subsystems areready to provide data.

28.15 The HMI shall provide policy system settings to accommodate for network issues, such as the time to recognize a network glitch and how frequently a check for network failure is detected.

28.16 The HMI shall provide VBA Display Client Object Model methods to determine the stateof the Primary and Secondary servers.

28.17 The HMI shall support redundancy without the need to write application logic.

28.18 The HMI shall support the ability to run an event on failover.

28.19 The HMI shall support the ability to run an event on failback. The HMI shall automatically synchronize the alarm state information on the primary and secondary so there is no disruption or loss of alarm state information on a failover

29. Activations

29.1 The HMI shall also support a secure, software-based system for activating software products and managing software activation fi les.

29.2 The HMI shall support activation via phone, email or website.

29.3 The HMI shall provide a 7-day grace period activation.

30. Remote Monitoring with Web-based HMI Clients

30.1 The HMI shall support fully scalable and animated web displays of existing FactoryTalkView SE applications from the offi ce, home, or on the road via an internet browser.

30.2 The HMI shall provide support for multiple browsers including Internet Explorer andFirefox.

30.3 The remote thin-client shall be an internet browser with a small plug-in, without theneed for an additional client software installation.

30.4 The HMI shall support multiple concurrent thick and thin-client connections.





Factorytalk Historian SE




FactoryTalk Historian SE

A separate Historian Server will be installed and configured to archive process data. The historian software will be FactoryTalk Historian SE from Rockwell Automation, no equal.

Logged Data

All field IO points will be archived at a resolution of once per second. Adequate storage will be available on the Historian server to maintain two years of historical process data online

Storage Media

Historical process data will be stored on a RAID 5 or other redundant disk media.

FactoryTalk Services Platform

The historian software will natively support the following components of the FactoryTalk Services Platform: FactoryTalk Security. Provides centralized authentication and access control by verifying the identity of each

user and granting appropriate system rights. FactoryTalk Directory. A common address book to locate and access plant-floor resources. FactoryTalk Live Data. Manages connections between controllers and servers to optimize plant data

communications along with fault tolerance. FactoryTalk Audit. Collects messages that document changes performed by users during design,

management and operation or production. Audit messages can be centrally stored and analyzed. FactoryTalk Diagnostics. Collects, stores and provides access to activity, status, warning, and error messages

generated by FactoryTalk compliant products during installation, configuration and operation.

Data Store

Time-series data will be available for retrieval through SQL calls to either an ODBC or OLEDB connection.

Data Compression

Raw data will be filtered and compressed making optimum use of disk space and to minimize retrieval time.

Calculation Engine

An embedded calculation engine allows programming of complex calculations like asset efficiency, real-time cost accounting and process summaries.

FactoryTalk Historian Datalink

A Microsoft Excel add-in that enables users to quickly access real time or historical data from the FactoryTalk Historian. Users can use the native functionality in Excel to analyze and report historical process activity.

FactoryTalk Historian Processbook



Ability to build ProcessBooks which are collections of historical data displays. These displays show static or dynamic historical process data along with information form external sources like specification, schematics or laboratory data.

FactoryTalk View SE Trend Object

The FactoryTalk View Trend Object instead FactoryTalk View SE allows the operator to browse and select process tags from the Historian. This can be done on-the-fly while the historian is running.



Factorytalk Asset Center


FactoryTalk Asset Centre

A separate Asset Centre Server will be installed and configured to gather, manage and secure the power, automation and information assets across the facility’s entire enterprise. The asset centre software will be FactoryTalk Asset Centre from Rockwell Automation, no equal.

CENTRALIZED DATABASE

The software will use a centralized SQL database that is configured to be part of the system install and is the primary repository for version control and traceability information.

SOURCE CONTROL

The software will use Source control. This source control leverages the centralized database and provides automatic version control. This ensures proper file management and single master relationships. Supported documents include configurations, programs, SOPs, CAD and more.

AUDITS

The software will have an Audit feature to gather information centrally that is generated by user interactions with Rockwell Automation FactoryTalk enabled applications, including FactoryTalk AssetCentre. The audit trail consists of user, device, computer, time and action taken.

EVENTS

The software will have an Events feature, which gathers system-generated information centrally from FactoryTalk-enabled applications, including FactoryTalk AssetCentre. Typical event information may include time, source generating or messaging.

SECURITY

FactoryTalk AssetCentre will internally leverage the powerful features already found in FactoryTalk® Security. This standardized security model minimizes efforts to administer users and passwords on operator interfaces, historians, engineering and maintenance workstations. It even enforces security rights when machines are disconnected from the LAN.

NOTIFICATION



The Notification feature proactively notifies designated users when predefined system events occur. E-mail notifications could include:

• Upload and compare event statuses • Completed, aborted or failed schedules • Scheduled reports • Rogue candidate detection • Source Control file reminder

REPORTING

The reporting capabilities of the software will allow scheduled and on-demand searches and can include traceability information from Audit, Events or Source Control.

SOFTWARE DELIVERY SYSTEM

FactoryTalk AssetCentre utilizes a Software Delivery System. This element proactively keeps client workstations up to date with the latest revision of FactoryTalk AssetCentre by periodically pulling revision information from the FactoryTalk AssetCentre server. This keeps client workstation maintenance to a minimum as new features are added or updated.

SCHEDULER

The software will have a Scheduler, which is used to run periodic tasks or reports. These are assigned to FactoryTalk AssetCentre-designated computers, or agents, to leverage unused or under-utilized computing power within your facility and are load-balanced automatically across all agents.

DISASTER RECOVERY

FactoryTalk AssetCentre provides control system backup that is integrated with source control to provide reliable and easy access to the latest control system configuration files. The backup system can be configured to provide a comparison of the configuration file retrieved from the plant floor with the master file stored in source control so users can determine any changes that have been made on the plant floor. These operations are executed on a repeating date or time basis as scheduled to fit your operational needs.

CALIBRATION MANAGEMENT

The software will manage calibration data efficiently that is associated with the process instruments. This includes scheduling, reporting and tracking. The Calibration Management feature supports e-signatures and paperless record keeping to better comply with FDA 21 CFR Part 11. It also maintains record histories such as last calibrated and “as left, as found.”

FactoryTalk Services Platform

The Asset Centre software will natively support the following components of the FactoryTalk Services Platform: FactoryTalk Security. Provides centralized authentication and access control by verifying the identity of each

user and granting appropriate system rights. FactoryTalk Directory. A common address book to locate and access plant-floor resources. FactoryTalk Live Data. Manages connections between controllers and servers to optimize plant data

communications along with fault tolerance. FactoryTalk Audit. Collects messages that document changes performed by users during design,

management and operation or production. Audit messages can be centrally stored and analyzed. FactoryTalk Diagnostics. Collects, stores and provides access to activity, status, warning, and error messages

generated by FactoryTalk compliant products during installation, configuration and operation.


