DCS Process Contro PlantPax

Rockwell Automation WW Control Solution Procurement Specifications
Procurement Specification
Document Control System
Plant Wide DCS Process Control

System
Document
WW EMEA Procurement Control System Draft 1
Page 2 of 111
Table of Contents
1. System Specification Overview.......................................10

2. System Architecture Requirements.................................10
2.1.
System Scalability............................................................10
2.1.1. Controller Capacity..................................................................................11

2.1.2. I/O Network and I/O Capacity..................................................................11
2.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...................................................................11
2.5.1.
2.5.2.
2.5.3.
2.5.4.
2.5.5.
2.5.6.
2.5.7.
2.5.8.
2.5.9.
2.6.
System Services...............................................................14
2.6.1.
2.6.2.
2.6.3.
2.6.4.
2.7.
Network Management.............................................................................15
Supervisory Network...............................................................................15
Control Network......................................................................................15
Control Network Redundancy and Alarming............................................16
I/O...................................................................................16
2.8.1.
2.8.2.
2.8.3.
2.8.4.
2.8.5.
2.8.6.
2.8.7.
2.8.8.
2.8.9.
2.9.
Distributed Data......................................................................................14
Directory Service.....................................................................................14
Alarms and Events..................................................................................15
Security................................................................................................... 15
Networks.........................................................................15
2.7.1.
2.7.2.
2.7.3.
2.7.4.
2.8.
HMI Server..............................................................................................12
Data Server.............................................................................................12
Alarm Server...........................................................................................12
Domain Server........................................................................................12
Security Server........................................................................................12
License Server.........................................................................................13
Historian Server......................................................................................13
OPC Server..............................................................................................13
Batch Server........................................................................................... 13
Analog I/O............................................................................................... 16
Discrete I/O.............................................................................................16
High-Speed I/O........................................................................................16
Chassis Based I/O....................................................................................17
Distributed In-Cabinet I/O........................................................................17
Distributed On-Machine I/O.....................................................................17
Intrinsically Safe I/O................................................................................17
Conformally Coated I/O...........................................................................18
Adding or replacing I/O Modules Online...................................................18
Field Device Interfaces and Device networks.....................18
2.9.1. DeviceNet...............................................................................................18
2.9.2. HART I/O..................................................................................................18
2.9.3. Foundation Fieldbus I/O...........................................................................19
Jose Luis Sanchez
WW EMEA GITC
Page 3
3/26/2015
2.9.4. Profibus I/O.............................................................................................. 19

2.9.5. Intelligent Device Management...............................................................20
3. System Configuration, Visualization and Maintenance.....20

3.1.
Engineering Workstation..................................................20
3.1.1. Engineering Workstation Configuration...................................................20

3.1.2. Engineering Workstation Functions.........................................................21
3.1.3. Reusable Applications.............................................................................21
3.2.
Operator Interface Configuration.......................................22
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.3.
Operator Interface Visualization........................................24
3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.
3.3.6.
3.4.
Operator Station Redundancy.................................................................24

Operator Station Security........................................................................24
Area Security...........................................................................................24
Alarm Window......................................................................................... 24
Faceplates...............................................................................................25
Time Synchronization..............................................................................25
Alarm and Event Management...........................................25
3.4.1.
3.4.2.
3.4.3.
3.4.4.
3.4.5.
3.4.6.
3.5.
Graphical Display Editor..........................................................................22

Graphic Displays.....................................................................................22
Standard Faceplate Library......................................................................23
Integrated Batch Visualization.................................................................23
Alarm
Alarm
Alarm
Alarm
Alarm
Alarm
Priorities........................................................................................26
Detection......................................................................................26
Acknowledgment..........................................................................26
Logging.........................................................................................27
Navigation.....................................................................................27
Archiving.......................................................................................27
Trending..........................................................................28
3.5.1. Trend Data............................................................................................... 28
3.6.
Reports............................................................................29
3.7.
Report Generation............................................................30
4. Process Controllers........................................................30
4.1.
Controller Programming Environment................................30
4.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..................................32
4.6.1.
4.6.2.
4.6.3.
4.6.4.
4.6.5.
4.7.
Function Block Diagram..........................................................................32

Sequential Function Chart.......................................................................33
Structured Text........................................................................................33
Ladder Diagram......................................................................................34
User Defined Functions and Tags.............................................................34
Alarm and Event Detection...............................................34
Jose Luis Sanchez

WW EMEA GITC
Page 4
3/26/2015
4.8.
Process Control................................................................34
4.8.1.
4.8.2.
4.8.3.
4.8.4.
4.8.5.
4.8.6.
4.8.7.
4.8.8.
4.9.
PIDE Loop Control....................................................................................34

PIDE Integrated Auto-Tune.......................................................................35
PIDE Optimized Auto-Tune.......................................................................35
Standard Library for Controller................................................................35
Computational Functions.........................................................................36
Discrete Control Functions.......................................................................36
Advanced Regulatory Control..................................................................36
Fuzzy Logic..............................................................................................36
Batch & Sequencing Control..............................................37
4.9.1. Basic Batch & Sequencing.......................................................................37

4.9.2. Comprehensive Batch & Sequencing......................................................37
4.10. Drive Control....................................................................37

4.11. Motion Control.................................................................38
4.12. SCADA and Third Party Connectivity..................................38
4.12.1.
4.12.2.
4.12.3.
4.12.4.
4.12.5.
OPC Interface......................................................................................39
Serial Interface....................................................................................39
Ethernet.............................................................................................. 39
Third Party PLC Communication..........................................................39
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...........................................................................44
6.1.1. Operator Training....................................................................................44

6.1.2. Maintenance and Hardware Training.......................................................45
6.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...........................................................47
7.1.1. Analog Inputs..........................................................................................48

Jose Luis Sanchez
WW EMEA GITC
Page 5
3/26/2015
7.1.2.
7.1.3.
7.1.4.
7.1.5.
7.1.6.
Digital Inputs........................................................................................... 49
Analog Outputs.......................................................................................49
Digital Outputs........................................................................................49
I/O Terminations......................................................................................49
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.......................................................................53
10.1.1.
10.1.2.
Acronyms and Abbreviations...............................................................53

Terms................................................................................................... 53
Purpose........................................................................59
Bidder Requirements.....................................................59
Technical....................................................................59
2.1
Trained Personnel....................................................................................59
Experience..............................................................................................59
2.1.1
2.1.2
2.2
Commercial......................................................................60
Quotation Submittal Requirements.........................................................60
(TBD by End User)...................................................................................60
2.2.1
2.2.2
Basis of Ethernet Services..............................................61

3.1
Agency Specification........................................................61
3.2
Manufacturers Specifications and Guidelines....................61
Services to be Supplied..................................................61
4.1
Option 1: Ethernet Network Design...................................61
Jose Luis Sanchez

WW EMEA GITC
Page 6
3/26/2015
Requirements Analysis............................................................................61
Review and Discussion............................................................................62
Network Design Development.................................................................63
4.1.1
4.1.2
4.1.3
4.2
Option 2: Ethernet Network Design Assessment................63
4.2.1
Ethernet Network Design Assessment...............................64
4.3
Ethernet Audit.................................................................64
Installation Measurements and Verifications...........................................64
Configuration Verifications......................................................................65
Operational Network Measurements.......................................................65
4.3.1
4.3.2
4.3.3
Test Equipment Usage and Equipment Specifications.......66

Ethernet Inactive Network Test Equipment for Copper Media..................66
Ethernet Inactive Network Test Equipment for Fiber Media.....................66
Ethernet Active Network Test Equipment................................................66
5.1
5.2
5.3
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
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
Jose Luis Sanchez
WW EMEA GITC
Page 7
3/26/2015
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
Jose Luis Sanchez
WW EMEA GITC
Page 8
3/26/2015
SCHEDULER........................................................................105
DISASTER RECOVERY............................................................105
CALIBRATION MANAGEMENT...................................................105
FactoryTalk Services Platform.......................................................105
Jose Luis Sanchez

WW EMEA GITC
Page 9
3/26/2015
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 Scalability
The system must provide the highest degree of scalability possible so

users only buy what they need open, scalable, and distributed. It
should provide scalable controllers and I/O all with a common design
environment in addition to a scalable HMI solution again with a
common design environment. The need is to provide a highly
Jose Luis Sanchez
WW EMEA GITC
Page 10
3/26/2015
integrated control system across different control platforms and enable

the control capability to expand from a few loops to thousands.
2.1.1.
Controller Capacity
2.1.2.
I/O Network and I/O Capacity
2.1.3.
Controller Application Capacity
System shall include specification for control network capacity.

If differences exist (in the maximum number of controllers
allowed) between redundant and non-redundant
configurations, vendor shall provide explanation.
System shall include specification for maximum I/O limitations

for controllers. This should include maximums for control
networks, I/O networks, and I/O module (local and remote I/O,
SCADA, and industry-standard control networks.).
System shall include specification for controller application

capacity. This should reflect both single programming language
applications as well as cases involving a mix of control
application strategies. If differences exist (in the maximum
number of controllers allowed) between redundant and nonredundant 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 Expansion
The system shall be constructed to permit implementation and system

expansion in a phased fashion, where the initial system implementation
may be quite small. As requirements grow, the system shall accommodate
the addition of HMIs, front-end computers and field devices, all without
performance degradation. The system shall support field extension of its
network, addition of gateways to the network, addition of controllers and
remote I/O where required, and integration of PLCs and computers into the
system.
2.4.
Software Revisions
Application software shall not require modifications in order to be able
to run under new releases of the system operating software. Any new
release of system software shall be backward compatible with files
created using the previous software releases.
2.5.
System Sever
The system shall be capable of running a pair of similarly configured
servers/workstations in a redundant configuration where at any point in
Jose Luis Sanchez

WW EMEA GITC
Page 11
3/26/2015
time, one is the acting Primary and the other the acting Backup. An
on-line database duplication mechanism shall be available.
It shall be possible to remove one of the redundant servers for
maintenance without interrupting operation, and upon its
reinstatement, re-synchronize the databases via a push-button on the
screen, again without interruption to system operation. A simple
method of manually initiating a fail-over shall be provided to assist
with such maintenance operations.
2.5.1.
HMI Server
The HMI Server is to store HMI project components (for
example, graphic displays) and serves them to system wide
operator workstations thereby removing the need to create
duplicate copies and maintain them for multiple operator
workstations.
2.5.2.
Data Server
The data server links networks and devices to system wide
visualization and development components such as HMI clients
and engineering workstations. It shall provide communication
services between applications and devices on the plant floor
allowing users to read, write, and configure values in plant floor
devices, such as sensor readings and other system controller
data.
Data servers shall be configurable to run on both a primary
computer and a backup computer. The system should
automatically switch to a backup computer if communication
with the primary computer fails.
The servers should handle failure detection and failovers
automatically for all components (clients) of the system. In a
traditional system (DCS), each client must independently monitor
connections, detect communication failures, and switch between
backup and primary computers. This is not preferred.
2.5.3.
Alarm Server
This alarm server alerts operators to critical alarm conditions
and maintains a record of alarm status for historical access.
2.5.4.
Domain Server
A domain server is to be available that the system utilizes to
manage highly distributed systems.
2.5.5.
Security Server
An available security server should protect against

unauthorized use but still allow authorized users to use the
system efficiently. The security is to be a centralized system
which restricts access to system resources based on key
security components.
The security server shall have the capability to have either
control-system local users/groups or domain-linked
users/groups and the ability to use an existing domain.
The key components that are to be securely managed by the
security server are:
Jose Luis Sanchez
WW EMEA GITC
Page 12
3/26/2015
2.5.6.
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.
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 Server
The system shall have available if needed a historian server
that performs process data collection from the control system.
There should be included a user configurable data collection
functions defining what data is to be collected and under what
circumstances it is to be collected. Users shall be capable of
accessing historical data.
When the system is configured, and as it is adapted over time,
it shall be possible to define classes of information that should
be retained, as well as specific system-level data that should
be collected. As with process historical data, this data shall be
accessed for viewing and for reporting.
2.5.8.
OPC Server
The system must allow for 3rd party connectivity to the system
controllers and to the HMI Server via an OPC interface. This
open connectivity shall follow the OPC Foundation's standards
to get information to or from the system. If the system is
configured for redundancy, OPC communications must
continue even in the event of a HMI or data server failure,
without any extra work required from the 3rd party OPC client.
2.5.9.
Jose Luis Sanchez

WW EMEA GITC
Batch Server
A Batch Server must manage batch resources, support batch
production and include system failure detection and recovery,
Page 13
3/26/2015
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 Services
System services are services that are utilized across all of the system components.
2.6.1. Distributed Data
Data in the system is to remain distributed in its original,

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

WW EMEA GITC
Directory Service
There should be present a directory of factory resources such
as data tags, HMI displays, and other plant floor objects that
acts as a lookup service for the data rather than a single,
common database. The directory should be a service that
should provide a searchable reference to data resources stored
anywhere across the system. It shall provide the benefits of a
common database without a possible single point of failure.
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.
Page 14
3/26/2015
Likewise, a deployed program can be moved to a workstation,

modified, and then redeployed. In addition, separating the
names of data items from their locations also makes
implementing redundant systems much easier.
2.6.3. Alarms and Events
When alarms or events occur in the system, operators are to

be quickly alerted of the conditions which require immediate
action. Alarms and events are to be detected at the controller
level ensuring accurate identification of alarm sequences,
reduced network bandwidth requirements, and improved
overall system performance. Since the alarm state is to be
managed in the controller itself the state should not be not lost
if the HMI servers fail. Alarms triggered anywhere in the
system shall be capable of being viewed and acknowledged
from any operator workstation in the system.
2.6.4.
2.7.
Security
Centralized access control should be provided by verifying all
user identities, and then by either granting or denying each
users request to access features and resources within the
system.
Networks
The system should utilize the Common Industrial Protocol (CIP) to move data
seamlessly throughout the system. Multiple physical networks, including the
plant, supervisory, control, and device networks should appear as a single
network making communications efficient.
2.7.1. Network Management
Network Management is to provide the ability for the system to

support and manage system wide communications. This shall
include:
Networked field devices
Scheduled and unscheduled I/O control networks
Peer to peer control between controllers
Supervisory control data exchange between controller
and OI
Supervisory control between controller and Batch

Management
Data collection for trends and historians
Production data transfer between the system and Plant
MES software
2.7.2. Supervisory Network

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

WW EMEA GITC
Page 15
3/26/2015
2.7.3. Control Network

The process control network/remote I/O network is used to
connect the controller to field (Remote) I/O and shall be an
open, flexible, high performance network.
These networks shall have the following capabilities:
Inherently designed to provide redundancy
Capable of providing control loop updates within 1 sec
Deterministic delivery of process data
Completely open standard with no proprietary content
A producer/consumer network model to optimize network
bandwidth
Communications processing on the network card to
ensure network traffic will not affect server or controller performance
2.7.4. Control Network Redundancy and

Alarming
Failure of any supervisory system shall be announced audibly
and visually via the alarming subsystem.
To ensure maximum reliability, communications shall be
redundant. The communications system shall be capable of
sustaining loss of one media channel without loss of data or
performance degradation. The Bidder shall include the typical
data throughput of his communications system, in baud rate
and number of analog values per second.
Loss of communications shall not cause loss of control at the
local subsystems. Also, loss of a local subsystem (either a
single node or both of a redundant pair) shall not cause the
loss of network communication.
2.8.
I/O
The system should interface with field devices in two ways, via standard I/O, and
through intelligent field devices. The system should offer I/O products for
virtually every application need, from analog or digital I/O that can be
distributed in cabinets and machines around the application or
integrated with the controller itself.
2.8.1. Analog I/O
The analog I/O modules perform the required A/D and D/A
conversions to directly interface analog signals to processor
data values using up to 16-bit resolution. Analog I/O can be
user-configured for the desired fault-response state in the
event that I/O communication is disrupted. This feature shall
provide a safe reaction/response in case of a fault.
2.8.2. Discrete I/O
The system must support discrete I/O modules which have

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

WW EMEA GITC
Page 16
3/26/2015
2.8.3. High-Speed I/O
System shall provide high-speed discrete and analog control

for plant automation applications such as material handling
and packaging equipment which require the ability to perform
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/O
Chassis-based I/O shall provide high functionality field device

interface capabilities to the system. Networks supported by
chassis-based I/O include DeviceNet, EtherNet, and ControlNet.
Chassis-based HART device interfaces, analog input and output
are available with the option of each channel being set to
voltage, current or current + HART. This shall provide a
versatile communication option which is HART compliant and
utilizes standard wiring / terminal blocks.
2.8.5. Distributed In-Cabinet I/O
Highly distributed I/O shall be supported throughout the

system including rail-based distributed I/O. Distributed incabinet I/O must support EtherNet/IP communication. The
distributed In-Cabinet I/O is to be offered in modular
and block I/O styles. Modular I/O is a system of

interface cards and communications adapters that
interface directly to the sensors and actuators of the
machine/process and communicate their status to the
controller via a communication network.
2.8.6. Distributed On-Machine I/O
The system should offer distributed on-machine I/O which is

locally mounted allowing for high-speed dedicated machine
control. Networks supported by distributed on-machine I/O are
to include EtherNet/IP. Distributed On-Machine I/O is
similar to Distributed In-Cabinet I/O but should not

require an additional enclosure for environmental
protection allowing for much easier maintenance and
troubleshooting. It is the placement of system I/O
directly on a machine rather than housing the I/O in a
remote, central cabinet. Distributed 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/O
Distributed I/O should be capable of meeting the intrinsic

safety requirements for operation in hazardous locations. I/O
Jose Luis Sanchez

WW EMEA GITC
Page 17
3/26/2015
modules with intrinsically safe barriers built into the I/O are to
be available. These I/O can be distributed in hazardous areas
without the use of bulky explosion proof or purged enclosures
which are expensive and difficult to maintain. The I/O should
have built-in galvanic isolators which reduce terminations and
the size of cabinets.
2.8.8. Conformally Coated I/O
An option to provide conformally coated system I/O modules

that contain protection against corrosive elements shall be
available. The conformal coatings are to be 1-2 mil thick
polymeric films which cover or encapsulate the printed circuit
assemblies. Though generally undetectable by the naked eye,
the conformal coatings are to protect the assemblies from
airborne contaminants and corrosion by sealing out the
contaminants and humidity. This should allow the conformally
coated I/O modules to function in corrosive areas where the
normal I/O modules can not.
2.8.9. Adding or replacing I/O Modules Online
I/O modules should be capable of being added while system

controllers are online. The ability to add I/O online should
make it much easier to make system I/O changes to the system
without affecting the entire system since the controllers do not
have to be taken offline to do so.
It shall not be necessary to remove power or field wiring to
replace an input or output module.
2.9.
Field Device Interfaces and Device networks

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

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

WW EMEA GITC
Page 18
3/26/2015
2.9.2. HART I/O
Designed to complement traditional 4-20mA analog signaling,

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

interfaces directly to the controller. The vendor shall provide
intelligent, self-diagnosing linking devices based on Foundation
Fieldbus standards. The HSE/H1 (High Speed Ethernet /
Fieldbus H1) linking device shall be able to support up to four
H1 segments.
The linking device shall allow dual, concurrent

communications with HSE and EtherNet/IP (or Controlnet).
This will allow the use of EtherNet/IP (or Controlnet) for
discrete and process applications and/or HSE for process
and asset management applications on the same network.
The system shall support all field devices
certified by the appropriate standards body for
Foundation Fieldbus and shall not require
additional approvals by the vendor of the host
system. The system shall be able to read all
variables provided by the field device without
the need for any additional wiring. Diagnostic
information shall be available from the field
devices, including device faults, configuration
faults, operating mode, and maintenance
requests.
The system shall provide direct integration and
access to Foundation Fieldbus devices,
Jose Luis Sanchez
WW EMEA GITC
Page 19
3/26/2015
including configuration and scaling, via the

Control and I/O development software.
2.9.4. Profibus I/O
The system must support Profibus networking, an open, digital

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

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

Maintenance
This section specifies the configuration and visualization of the Engineering and
Operator Workstations and supporting engineering software.
3.1.
Engineering Workstation
The engineering workstation shall be designed to support all operational,
engineering, maintenance, and configuration functions. Users shall be able to
access the entire control system from a single location without custom
programming.
3.1.1. Engineering Workstation Configuration

The system is to utilize an Engineering workstation
configuration that complies with the following general
configuration requirements:
Jose Luis Sanchez

WW EMEA GITC
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.
Page 20
3/26/2015
It shall be possible to install more than one

engineering workstation in a system.
The engineering system shall be an open system
allowing, for example, project data from Microsoft
Excel to be imported.
Storage media shall be provided at each engineering
workstation.
It shall be possible to save configuration data on
both removable and non-removable media for back
up purposes without taking the system off-line.
The engineering software shall employ an intuitive
MS Windows explorer style interface, which will
allow the engineer to manage all aspects of the
controller, HMI, network, hardware, and field
device configuration.
3.1.2. Engineering Workstation Functions
Only one engineering workstation shall be necessary to

perform all of the traditional configuration tasks (Control, HMI,
Batch, and History), intelligent device configuration
(transmitters, drives, analyzers, etc.), database generation,
and editing. However, it shall also be possible to use multiple
engineering workstations simultaneously for this work.
The central engineering workstation shall be capable of
supporting all of the following functions:
Jose Luis Sanchez

WW EMEA GITC
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,
Page 21
3/26/2015
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.
3.2.
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
Operator Interface Configuration

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

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

displays. These displays shall be accessible through assignable
user accounts, and using the standard system operator display
navigation functions. Revision of an existing display shall result
in automatic updating of any display servers in the system
scope. The system shall provide detailed documentation of
tags used on custom graphic displays. System shall support
Jose Luis Sanchez

WW EMEA GITC
Page 22
3/26/2015
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:
Jose Luis Sanchez

WW EMEA GITC
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
Page 23
3/26/2015
Motorized Valve Control
3.2.4. Integrated Batch Visualization
A library of standard pre-built process control HMI graphics with

integrated batch views shall be available.
The standard HMI library shall consist of the following

pre-engineered graphics at a minimum:
3.3.
Batch Overview Display

Batch Unit Display
eProcedure Displays
Material Manager Displays
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 Redundancy

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

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

WW EMEA GITC
Page 24
3/26/2015
3.3.3. Area Security
Each operator shall be assigned one or more specific areas of

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

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

faceplates for control functions such as PID, totalizers, multistate devices, motor starters and drives.
3.3.6. Time Synchronization
The Operator Interface shall be capable of synchronizing its

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

The system shall support a comprehensive alarm detection and management
facility to allow fast and accurate notification to the operator of abnormal
conditions within the process. Alarm monitoring shall be extended to calculated
values and SCADA input values handled by the system. Alarm monitoring shall also
be extended to diagnostic values monitored by the system. Monitoring of source
values and analyzing for alarms shall take place as close to the original source of
data as is practically possible. This software will be responsible for monitoring the
process measurements and status inputs and advising the operator when alarm
conditions are detected in these measurements and status inputs.
Jose Luis Sanchez

WW EMEA GITC
Page 25
3/26/2015
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 operators standard navigation screen or specific windows, either
dedicated, or "pop up" (or both). The operator shall have the option to retain an
alarm manager window on his screen at all times, or may invoke the alarm
manager screen as required. Invocation of the alarm manager screens shall be
user configurable and shall include designation of alarm groups and "filter" criteria
for the display (e.g., tag, equipment reference, operator, time window, batch,
process unit, and process area).
3.4.1. Alarm Priorities
The system shall support the ability to configure all alarms

based on their level of seriousness relative to impact on the
operation of the process or system. The system should
support at least four alarm priorities. These priorities are to be
configured as part of the control function blocks as follows:
Urgent
High
Medium
Low
Each alarm type shall be individually able to be prioritized into

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

automatically cause the system to perform the following
actions when an alarm occurs:
Jose Luis Sanchez

WW EMEA GITC
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).
Page 26
3/26/2015
The alarm shall be logged in the Event Database with

the Point Name, Alarm type, Alarm Priority, Point
Description, and new value
The PV of the alarm shall turn to a presentation format
(color, object display) associated with the level and
priority of the alarm (e.g., red and flash) on any
standard or custom display which uses the point
An Unacknowledged alarm entry shall be made in the
system alarm summary for Low, Medium, High and
Urgent Alarms or events
The audible alarm shall sound (if configured)
The alarm annunciators indicator shall flash until
acknowledged
Once the alarm is acknowledged and has been reset
the alarm will be cleared from the alarm summary
3.4.3. Alarm Acknowledgment
In addition, the alarm zone of the operator interface shall show

this alarm provided it is the highest priority, unacknowledged
alarm in the system.
The system shall provide for efficient alarm acknowledgment in
a number of ways as follows:
Selection of any parameter tag for the point in alarm
from a custom graphic and pressing the dedicated
acknowledge push-button
Selection of the alarm in the system alarm zone and
pressing the dedicated acknowledge button
Selection of the alarm in the alarm summary display and
pressing the dedicated acknowledge button
By performing a page acknowledge from the alarm
summary display
On acknowledgment by the operator, the flashing indicator
shall turn to a presentation format designated for
acknowledged alarms (e.g., acknowledge color, steady, not
flashing), and the parameter shall remain in that presentation
format on any 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.
Jose Luis Sanchez

WW EMEA GITC
Page 27
3/26/2015
3.4.4. Alarm Logging
All new alarms shall be configurable to be logged on all

alarm/event loggers, written to a disk file in a readable file
format, placed into the active alarm summary display window
and audibly annunciated.
3.4.5. Alarm Navigation
The alarm manager "pop up" support window shall include the
ability to have the alarm manager present the operator with an
immediate means of going directly to the display page which is
required to investigate the source of the new alarms. If a
series of new alarms are received at the operator station, and
all of them happen to be associated with the user-defined
alarm group, the pop-up window shall be pre-set to
immediately call up the graphic display page for that group.
3.4.6.
3.5.
Alarm Archiving
Alarm management functions, including archive recording of
alarms and events, the recording of operator
acknowledgement of alarms, the enable and disable of point
and group alarming, plus the annunciation and logging of
alarms, shall be provided at all operator stations.
Trending
The system shall support three levels of trending: real-time trending, short-term
historical trending, and archive/retrieval of short-term trending for indefinite
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.
Jose Luis Sanchez

WW EMEA GITC
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 realPage 28
3/26/2015
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 Data
The trending shall be configurable for dynamic updates at a

user-defined rate. Real-time trending shall have no "history"
and shall operate like a chart recording that is "turned on"
when the display graphic is initiated.
The control system shall provide trending capability with the
following functions:
Real time trending
Historical trending
Archived History trending
Trend Scrolling
Trend Zoom
Trend screen in Engineering Unit or Percent
Cursor readout of trend data
Trend comparisons between archived, real-time and

historical data (for example, this year vs. last year,
this batch vs. last batch). Comparisons between the
same point offset in time, or different points must be
possible.
Trend De-cluttering via per-pen enable/disable on

multi-plot style trends
Independent Y-axis per point on multi-plot style

trends. It shall be possible to display the Y-axis for
any point on the trend by simply selecting the point
using the mouse or keyboard.
Copying the currently displayed trend data to the

clipboard for pasting into spreadsheet or document
Operator controllable X and Y axis scaling
3.6.
Reports
Reporting software that allows end users to configure Web-based dashboards,
trends, and reports is to be available. It should include standard, pre-configured
reports for managing devices, equipment, alarms, events and control loops, as well
as batch or production run and shift reports. The application is to include trending
and dashboard capabilities for analysis and uses Microsoft Excel for report
generation.
In addition to gathering data from control system, the reporting software should
Jose Luis Sanchez

WW EMEA GITC
Page 29
3/26/2015
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.
3.7.
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.
Report Generation
Hourly, daily, monthly, end-of-month, quarterly and yearly
reports shall be supported. Reports shall be capable of being
printed and/or saved to disk when a process event occurs. It
shall be possible to activate a report in any of the following
manners: upon demand by operator request, scheduled (shift, daily and
monthly), and upon predefined events.
4. Process Controllers
The controller shall be a multi-tasking, real-time microprocessor with the ability to
simultaneously manage multiple activities. The controller shall be able to perform
continuous and regulatory control on dozens of "loops" while concurrently executing
safety interlock logic, as well as executing hundreds of algebraic calculations, all of which
will be defined at, and down-loaded from, the operator stations. The communications
network "backbone" for the controller shall be either Ethernet I/P (10 -100 Mega baud) or
ControlNet.
4.1.
Controller Programming Environment

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

WW EMEA GITC
Page 30
3/26/2015
4.1.1. Controller Editor
The system control and I/O development environment shall

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

the algorithm used to create and manage process
loops.
Ladder Diagram Graphical representation similar to

electrical relay circuits where rungs of logic perform
sequential operations.
Sequential Function Chart Graphical flow diagram

used to organize and sequence the operation.
Structured Text Textual basic like language useful for

developing custom algorithms and string text
manipulation.
The editor shall provide the ability to drag-and-drop to move
instructions, logic, routines, programs, and tasks either within a
single project or between projects to create detailed project
libraries.
The editor shall also have open access to various portions of
projects through:
Windows Clipboard cut/copy/paste code and

information from and to other Windows-based tools.
Import/Export Tag Definitions the Comma Separated

Value (CSV) export extracts tags for use by third-party
tools such as Microsoft Excel.
Full Project Import/Export this ASCII representation of

a controller project shall provide access to create and
manipulate the project using other text editors.
Partial Import/Export Online or Offline The system

shall support the import or export of specific, userselected portions of logic, into and out of both a
running controller as well as an offline controller
configuration file.
Controller data tags are to be defined just once using the editor
and are then are to available immediately to every piece of the
system.
4.2.
Controller Runtime Modifications

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

WW EMEA GITC
Page 31
3/26/2015
by one user are to be automatically propagated or uploaded to the other users

project view so that each user has an up-to-date image.
4.3.
Controller Restore / Upload

It shall be possible to recreate the configuration of one or
more controllers after a total loss of the controllers
configuration database. Controllers shall support the upload
and reconstruction of their configuration while running.
4.4.
Controller Communications
The controller shall be fully functional with "peer" ability to initiate communication
transactions among other controllers, and with operator stations, gateways and
other computers on the LAN(s). If a controller requires a measurement from
another controller or gateway, it shall merely request the owner of the
measurement to begin sending value updates, as the measurement changes, until
such time as the requesting controller advises that it no longer needs value
updates. All data transfers from the controller(s), after the initial transmission of
current value and status, shall be done on an exception basis. In order to make
the best use of available LAN bandwidth, the system shall use a report by
exception/alarm scheme.
4.5.
Control Strategy Development

As a minimum the controller should contain continuous, discrete and sequential
control functions. Associated controller logic (such as a regulatory loop) should be
able to be defined within a control object or control module. This control object
can encapsulate the control logic and provide a means to monitor and interact with
its logic as a loop. This includes, but is not limited to, cut, copy, paste,
enable/disable etc. It shall be possible to schedule the execution of control
modules/functions within the controller.
This execution environment shall support:
Individual control objects comprised of user selected functions. Must

have assignable execution rates of 50, 100, 200, 500, 1000 and 2000
milliseconds. All control objects, regardless of function block content, shall
be able to execute at any of these rates. Note that all function blocks
within a control object shall execute at the same rate.
Peer-to-peer communications that provide for the direct transfer of process

data between controllers without the use of gateways or servers.
The controller firmware shall be capable of being upgraded on line,

without stopping or upsetting the process being controlled in a redundant
controller system.
4.6.
A controller shall be capable of being inserted under power, without

upsetting the process being controlled by other controllers.
Controller Configuration Languages

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

Sequential Function Chart For control sequence management and batch
process
Structured Text For custom looping and complex mathematical algorithms
Ladder Diagram For state based sequential and motion control
All function types must co-exist with each other in a single controller, have the
ability to interact with each other, and support online editing.
Jose Luis Sanchez
WW EMEA GITC
Page 32
3/26/2015
The system also must support:

S88 State Control for complex and simple batch control applications.
User defined functions for customization (Add-on instructions, User defined
tags)
Application-specific instructions for process, drive, motion and safety
applications.
ASCII instructions to manipulate string data.

Message instructions to communicate between different devices.
4.6.1. Function Block Diagram
Function Block Diagram (FBD) instructions are required provide

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

structured, IEC 61131-3 compliant, high-level control
programming language.
The SFC shall include the following features:

It shall provide the necessary facilities for real-time
control of sequential processes.
It shall have access to process control and other
database information.
It shall be possible to modify the program logic
while other sequences are active.
It shall support execution of the chart in Manual or
Automatic Mode.
It shall be possible to configure multiple states
within a single SFC container. This allows for
effective coordination of sequences which have
more than one mode (e.g., Heating and Cooling) or
that contain 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.
Jose Luis Sanchez
WW EMEA GITC
Page 33
3/26/2015
A Sequential Function Chart (SFC) is similar to a flowchart of a

process. It should be a highly visual language used by the
system to organize the functional specification for control
systems as a series of steps and transitions. A step represents
a major function of the process and contains the actions that
occur at a particular time, phase, or station. A transition is the
true or false condition that tells the SFC when to proceed to the
next step.
Step transitions and step actions shall support the structured
text language for configuration of transition logic as well as
individual actions for steps.
4.6.3. Structured Text
The system should support Structured Text (ST), a textualbased control function that uses statements to define what to
execute. It is a, high level programming language similar to
Basic or C which shall be used to program complex
mathematical operations that would be difficult with other
control functions.
Two types of expressions, Boolean and numeric, can be used in
ST. Boolean expressions compare values or check if conditions
are true or false and numeric expressions calculate integer or
floating-point values.
ST shall provide these benefits to the system:
If/Then, Case, Do/While, Do/Until and For/Next

constructs
Non case sensitivity
Used in actions and transitions of Sequential Function

Charts
A Fully functional editor
4.6.4. Ladder Diagram
Ladder Diagram (LD) should be supported by the system. It

should be a rung-based control function that may be utilized to
develop sequential control applications such as conveyors,
machine control, and interlocks. LD can also be utilized to
manage motion and servo control needs and easily perform
messaging and serial communications.
4.6.5. User Defined Functions and Tags
The system should support the creation of libraries of

commonly used instructions and templates that can be reused
throughout the control project:
:
Shall be capable of being created using Function

Block Diagram, Structured Text, or Ladder Diagram
Can be used in Function Block Diagram, Sequential

Function Chart, Structured Text or Ladder Diagram
routines.
Can be animated
Provide instruction source protection with systems

word and view only or complete source locking
options.
Defined once in a project and can be shared by

multiple controller programs.
Jose Luis Sanchez

WW EMEA GITC
Page 34
3/26/2015
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 Detection

Alarms and events are to be detected quickly so that operators can be immediately
notified of critical conditions. Alarm and event detection and processing are to be
incorporated directly into the controllers.
Alarm and event detection features should include:
Alarm triggers based on analog tags, digital tags, or control function

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

latched, continuous or automatic acknowledge
100us distributed sequence of events (SOE) over Ethernet for high

accuracy alarming and first fault detection
4.8.
Process Control
Standard software algorithms shall be available to perform regulatory control
functions, and these shall have easily configurable parameters.
4.8.1. PIDE Loop Control
Enhanced Proportional, Integral, Derivative (PIDE) control loops

are to be supported through the Function Block Diagram and
Structured Text control functions. These control functions are
to be used to create continuous and batch process PIDE control
loops. It shall be possible to put any individual control loop in a
manual; automatic, or cascade mode. In cascade, it shall be
possible to configure remote setpoints from other regulatory
controllers or from other control blocks.
There shall be bumpless transfer between all control

modes, and windup protection shall be provided. Control
blocks shall be able to perform automatic mode switching
based on external or internal logic inputs.
4.8.2. PIDE Integrated Auto-Tune
A PID auto-tuner should be integrated into the PIDE instruction

used in the function block language and auto-tuning can be
initiated from any operator workstation or engineering station.
The PID auto-tuning facility shall employ an easy-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:
Jose Luis Sanchez

WW EMEA GITC
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
Page 35
3/26/2015
4.8.3. PIDE Optimized Auto-Tune
The 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 Controller

A library of standard pre-built control
algorithms for process control shall be
available. The standard controller library shall consist of
the following pre-engineered control strategies at a
minimum:
Standard PID Controller

Cascade PID Controller
Ratio Controller
Split-Range Controller
Manual Loader
Totalizer
Digital Value Monitoring with Alarming
Analog Value Monitoring with Alarming
Motor (Start/Stop) with Interlocks
Motor Two Speed
Motor Forward/Reversing
Valve (On/Off) with 1 or 2 Feedback Signals
Valve (On/Off) with Interlocks
Motorized Valve Control
4.8.5. Computational Functions

The following computational functions shall be supplied as
standard configurable items or simple algebraic
instructions:
Jose Luis Sanchez

WW EMEA GITC
Addition/Subtraction
Ramp generator
Lead-lag
Integrator/Accumulator
Dead time
High/low select
Multiplication/Division
Time averaging
Signal selection switch
Exponential polynomial
Page 36
3/26/2015
Logarithms
Square root
Absolute value
4.8.6. Discrete Control Functions
The following discrete control functions shall be supplied as

standard configurable items:
Logic functions -- and, or, not, nand, nor, xor

Change of state detect
Set/reset flip-flops
Timers and counters
Comparison elements -- greater than, less than, equal
to, not equal to
Multiplexer (selects one of up to 16 signals)
Positive, negative, and bi-directional edge trigger
4.8.7. Advanced Regulatory Control
The system shall support predefined advanced regulatory

control function blocks. These function blocks shall be
applicable to a wide variety of difficult to control situations,
such as loops significant dead time, loops with multiple
possible control variables, and situations significant interaction
between various controls variables and process variables.
4.8.8. Fuzzy Logic
The system shall support the ability to create custom fuzzy

logic based function blocks, which can be used in significantly
non-linear applications. These fuzzy logic based function blocks
shall be able to incorporate the expert control knowledge of
operators and engineers who are familiar with the process.
Fuzzy logic blocks shall not be limited in the number of
variables or rules. In addition, the fuzzy algorithm(s), once
created, must execute entirely in the process controller and
must support on-line tuning.
4.9.
Batch & Sequencing Control

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

detailed reports
Jose Luis Sanchez

WW EMEA GITC
Page 37
3/26/2015
Integrate and exchange batch and recipe information with corporate

information systems
Simulate your entire batch process
4.9.1. Basic Batch & Sequencing
The system shall support the implementation of simple batch

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

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

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

created, eliminating the need for users to manually add descriptions. The tag
names are to match the drive parameter names, effectively providing
standardized tags that are the same from one program to the next. The proper
data types are to 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:
Jose Luis Sanchez

WW EMEA GITC
Page 38
3/26/2015
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 users HMI
display. They are to allow for operator control, monitoring of data,
parameter adjustments and fault description/corrective.
4.11. Motion Control

System controllers shall provide highly-integrated motion control. The real-time
communications system should be a single fiber optic ring that serves as the sole
interface between control and drive.
The motion
control solution shall provide these important benefits:

Advanced diagnostics and process reporting via the SERCOS interface.
Wide variety of motion module options for system controllers.
Up to 16 axes of motion can be controlled from one motion module.
System should be fully expandable, with up to 32 axes supported per
controller. Multiple controllers can be used if additional axes are
needed.
Routines can be written in one of multiple IEC 61131-3 languages
Ladder, Structured Text or Sequential Function Chart
40 available motion instructions to handle even the most demanding
motion applications such as axis moves, high-speed registration, timeand position-based camming and even multi-axis gearing
Graphical editor simplifies creation of complex motion profiles.
Graphical data capture and display allows motion performance to be
monitored.
Wizard-based axis and drive configuration for easy-to-use
programming.
4.12. SCADA and Third Party Connectivity

The system shall include SCADA capability to communicate with third party PLC
and DCS vendors through third party OPC vendors. By utilizing these OPC
connections to communicate over various networks, including Modbus, Profibus,
DF1, Serial, DH+, EtherNet/IP, DH-485, Remote I/O, and others, the system shall
provide the ability to log, trend and report data from the third party PLC and DCS
sources.
If required for a particular SCADA network communication, Protocol Converter
Interface cards are to be supported. These are typically provided by the third party
OPC vendors.
The system shall be capable of communicating with third party control

systems by using the following interfaces and protocols:
4.12.1. OPC Interface

The system shall be able to communicate bi-directionally
with auxiliary systems using OPC. The OPC interface shall
be configured in a client-server relationship. There shall be
no need to write any custom code to set up the OPC
interface. Configuring the OPC shall be done using dragand-drop functionality to link the data source and target. At
a minimum, the OPC interface shall support scan rates of
Jose Luis Sanchez
WW EMEA GITC
Page 39
3/26/2015
500 ms and 1 second.

4.12.2.
Serial Interface
The following serial capabilities shall be
available for communicating to auxiliary
systems: RS-232C, RS-422, and RS-485 with
full and half-duplex operation, and selectable
baud rates (19200, 38400, 57600, and
115200). Modbus interfaces are to be configurable in a
master-slave relationship, with the system as the master and
the auxiliary system as the slave.
4.12.3. Ethernet
The system shall be able to communicate bi-directionally
with auxiliary systems using IEEE 802.3 Ethernet protocol
at 10 or 100 MBPS, with TCP/IP
4.12.4. Third Party PLC Communication
The system should support communication with the following

third party PLCs, including but not limited to:
TI
Square D
GE Series 6
GE Series 90
Modicon
Siemens
4.12.5. Third Party DCS Communication
The system should support communication with third party

DCSs, 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 Security

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

Jose Luis Sanchez
WW EMEA GITC
Page 40
3/26/2015
4.14. Process and System Simulation

The system shall support various levels of Process Simulation:
Controller Simulation. A controller simulation tool shall be available

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

possible to test controller application code without the need to physically connect
to hardware. Field inputs and outputs that are connected to system controllers
should be capable of being simulated for testing a wide variety of processes
ranging from discrete to continuous. An extensive user interface also shall provide
the dynamic interaction needed to thoroughly test control systems and to train
operators and maintenance personnel.
5. Production Management
The system is to provide a data Historian which collects data, and reporting software that
is used to display the data.
5.1.
Historical Data Archiving

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

WW EMEA GITC
Page 41
3/26/2015
5.2.
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
Plant Data Historian

The historian is to connect to the control system, or human-machine-interface
software, and collect data at high speeds, in real-time, and at full resolution. The
historian is to provide the capability to collect, store, analyze, and visualize data
using a powerful engine and a set of reporting tools such as time-series trends, bar
charts, pie charts, trends, and incorporate an easy method of generating reports
using Microsoft Excel. It shall also use compressed storage data algorithms to
contain a vast amount of data in a small format, and allow retrieval of the data
quickly over a short or long time span.
It shall be possible to direct the historical data collection function to collect data
from multiple sources (native process data from control applications, system
diagnostic values, calculated variables, soft points, and SCADA points, points
accessible through OPC or ODBC mechanisms). Timestamps shall be associated
with data values. Where available, timestamps shall be used from originating
source of data. Where available, data quality/status shall be used from originating
source of data. Data collection shall be on a polled, demand, or exception.
The historian should have features to generate archives and define how the
archives are generated and when the system closes an archive and creates a new
one.
5.3.
Historical Data Reporting

The system shall make advanced reporting available to various users of the system
including plant managers, operations and even shop floor operators. Reports are
to provide users with relevant up to date information that is required to perform
their jobs. These advanced reports are to be available through a standard Web
browser. It should allow end users to self-configure rich Web-based dashboards,
trends and reports without expensive, time-consuming support resources.
The reporting package shall provide unified access to virtually all

manufacturing/plant data sources, and produce web-based reports, such as
dashboards, trends, X-Y plots, and Microsoft Excel reports, that can be used
by manufacturing operators, engineers, supervisors, management and
executives throughout a plant.
5.4.
Dynamic Resource Management

Smart Binding capabilities should include configurable requirements and
preferences in unit selection for optimal procedural flow and recipe management.
Optimization options shall address:
Jose Luis Sanchez

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

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

WW EMEA GITC
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.
Page 43
3/26/2015
5.7.
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.
Material Tracking
The system shall provide plant-level material management and tracking that can
tie to corporate material management systems to manage and track the use of
materials by material type, lot, and sub-lot. Also to manage and tracks vessels,
containers and pallets, as well as permanent and transient storage.
Material definitions are to be added to recipes, significantly reducing the number of
recipes needed for flexible storage facilities. Material consumption, production, and
association of materials to containers and vessels are to be automatically logged,
providing complete information for forward and backward material tracking within
and across process cells.
5.8.
MES Interface
The system shall be designed to integrate with business systems and officeautomation systems, as well as with process equipment. The system shall be able
to be connected to most major computer manufacturer's systems via gateways
and servers, and shall provide data access and file access. The system must also
be capable of being bridged to department LANs. The system supplier shall
provide software, to run in existing PCs, to allow them to be placed on the system
Ethernet LAN, or remotely linked via a serial circuit, and to have access to 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 Management

The integrated asset management capabilities of the system are to include:
Audit trail for programming and parameter changes. Who made what,
when, where and why?
Control access to automation devices according to skills and
responsibilities
Automation device monitoring
Disaster recovery plan for automation devices & file archiving
Calibration Management
The system shall provide a constant and automatic audit trail of asset changes
while also controlling access to these assets; it should be able to verify
automatically what it is running against what was qualified. This IAM feature shall
provide compliance with the FDA regulation that a Quality Manager has to be able
to check if what is running has any impact on quality. It shall also ensure
Jose Luis Sanchez
WW EMEA GITC
Page 44
3/26/2015
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 DTMs with a DTM Catalog
Build the DTM Networks from client computers to the physical

devices
View and edit the configuration for a device (online or offline)
Upload and download the configuration for a device
Print the configuration for a device
6. Service and Support

6.1.
Training
Vendor shall make available advanced online training, self-paced training, and
instructor based, classroom training. This ensures that the right type of training
can be matched to the needs of operators and maintenance electricians thereby
greatly increasing their ability to operate the system as efficiently as possible.
The vendor shall offer regularly scheduled classes at training centers in all
areas/regions of the country. The vendor shall publish course schedules and allow
customer registration via the Internet.
6.1.1. Operator Training

The Vendor shall provide on-site operator training of the
final configured software application.
This training shall include as a minimum, the following

skills knowledge:
Graphic screen navigation
Manipulation of elements on graphic screens
Faceplate manipulation
Alarm annunciation
Accessing alarm history
Accessing trend displays
Accessing and interpreting system diagnostic displays
Operator training sessions will provide all information
Jose Luis Sanchez

WW EMEA GITC
Page 45
3/26/2015
required to:
Operate the system, create and maintain historical files.
Display historical file information graphs and charts.
Start up/Shut down the systems when required.
Complete any other operations that will be required
by an operator.
Provide necessary training to deal with power
outage and shut down procedures.
6.1.2. Maintenance and Hardware Training

The vendor will provide Maintenance Training for all
systems at site. The vendor shall offer complete
and comprehensive training programs for the
system, including the controller, networks, and
OS.
The controller hardware training course content
shall include:
CPU, power supply, communication cards,
backplane, local and remote I/O racks.
I/O cards
Communications and Ethernet communication
Fault tolerant architecture and failsafe architecture.
The Operating System hardware training course content
shall include:
System Overview
Client and server architecture, including networking
and redundancy
The display hierarchy, and the graphical, trending,
alarm, reporting, and batch displays
6.1.3. Engineering Training

The engineering training course content shall include:
Jose Luis Sanchez

WW EMEA GITC
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
Page 46
3/26/2015
6.2.
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
Technical Support
The vendor shall offer phone and e-mail support and Internet
information. The vendor shall offer 24/7 support for all system
hardware and software. This shall include spare parts,
maintenance, and technical support. The vendor shall offer a
published 800 number for telephone support during normal business hours.
The vendor shall offer comprehensive self directed technical support via the
Internet that shall include:
Contact with technical support via e-mail
Searchable knowledge base
Product catalogs and manuals
Product Frequently Asked Questions
Software updates
Application examples
Application Tips
Available phone support programs should allow system users to choose a service
level appropriate to their needs and the objectives of their maintenance strategy
including:
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 users specific
application and industry. Completely customizable. Dial-up
diagnostics optional.
Remote technical consulting and application development for small

programming projects including software conversions and
updates.
30 days of phone support for select system software.
6.2.1. Onsite Support Services
The following field support engineering services should be

offered to assist maintenance staff with preventive and
reactive tasks. Field support engineers are to be made
available on an as needed, scheduled, or full-time basis to
meet the specific user needs and system maintenance
strategy.
Jose Luis Sanchez

WW EMEA GITC
Page 47
3/26/2015
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
Jose Luis Sanchez
WW EMEA GITC
Page 48
3/26/2015
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:
7.1.1.
Analog
High Level Analog Input, (10V & 420ma)
Dynamic analog input (typically
vibration)
Analog Output, (4-20ma)
Analog Output, (10v)
Thermocouple Input
RTD Input
Analog Input, Voltage And Current
Analog Output, Current/Voltage
Isolated Discrete Relay
24-220 VAC (8 NO & 8 NC) Output
24-220 VAC (16 NO) Output
DC Input
24 VDC, (Isolated)
10-30
VDC, (Diagnostic)
AC
Input
24
120VDC
VAC, (Isolated)
48 VDC
220
VAC, (Isolated)
125 VAC,
VDC(Isolated)
120
(Diagnostic)
120 VAC
AC Output
120/220 VAC, (Isolated)
120 VAC, (Diagnostic)
120/220 VAC
DC Output
24 VDC, (Isolated)
10-30 VDC, (Diagnostic)
Analog Inputs
24 VDC
24 VDC, (Electronically Fused)
48 VDC
125 VDC, (Isolated)
The system shall be capable of supporting the following types
of analog process input signals:
Jose Luis Sanchez

WW EMEA GITC
4-20 mA dc, 0-20 mA dc, and 20 mA dc, isolated and

non-isolated inputs
1-5 V dc, 10 V dc, and 1 V dc isolated and nonisolated inputs
Type B, E, J, K, L, R, S, T and U thermocouples, isolated
and non-isolated inputs
Platinum resistance temperature detector (RTD)
Pt100, Pt500, Pt1000, Ni100, Ni1000, Cu10 per IEC
60751, isolated and non-isolated inputs
High-speed Pulse input 100, 125, 250, 500 kHz, 1 & 2
MHz @ 24 V
Page 49
3/26/2015
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 25C with a basic error of no more than 0.25% of
input range.
7.1.2.
Digital Inputs
The system shall be capable of supporting the following
digital input types, time stamped to 10 ms second accuracy:
24 Vdc
125 Vdc
24-48 Vac/dc
120 Vac
230 Vac
7.1.3. Analog Outputs

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

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

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

Each system shall be supplied with 20% spare I/O capacity
installed for each I/O type in the base system. The base
system should be defined as the quantity of hardware
Jose Luis Sanchez
WW EMEA GITC
Page 50
3/26/2015
needed to meet the project requirements.

7.2.
Controller Removal and Insertion under Power

Controllers should be capable of removal and insertion under power (RIUP).
Communication and I/O modules should be capable of being removed and inserted
while power is applied to the controller. This allows users to keep the system up
and running when it is necessary to replace modules.
7.3.
Controller Redundancy
Controllers shall be redundant and provide total redundancy of all functions in the
event of a Controller failure. Supplier shall document redundancy scheme and
expected performance of redundancy failover. The communication for redundancy
shall not be over the control network and is to be a redundant 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. Failover 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 Time

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

The system should support safety systems through the availability of Safety
Integrity Level (SIL) certified controllers and I/O. System controllers and I/O that
are certified for SIL 1 and SIL 2 applications by TV should be available.
Jose Luis Sanchez

WW EMEA GITC
Page 51
3/26/2015
7.6.
Controller Power Supplies

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

Controller configuration memory shall have an on-board lithium battery or
CompactFlash backup option so that the controller maintains its configuration
and state information in the event of a power outage. A rack mounted
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 Expandability

The vendor shall supply controllers which have the capacity for increasing their
memory via memory expansion cards to accommodate additional programming. In
a redundant system, memory additions shall be possible online without shutting
down the system.
7.9.
Controller Footprints
Controllers are to be available in the following footprints:
Rack mounted high performance controllers that have a high memory

capacity, support intensive process applications and provide fast
processing of motion instructions. Rack mounted controllers should also
utilize a wide range of modular network communications which ensures
that only what is needed is purchased.
Panel mounted with small footprint and high performance for tackling
smaller, machine-level control applications. They should provide a costeffective means to integrate a simple machine or application into the
system.
Rail mounted controllers that provide a small, highly adaptable
distributed control option. These should include inexpensive, multi-loop
controllers that offer two flexible communications slots that can be
configured to support the various system communication options.
7.10. Cabinets
Control cabinets shall conform to CE standards for
electromagnetic compatibility with the EMC law, and ensure
protection
against
unauthorized
access,
mechanical
influences,
contamination,
and
other
environmental
influences. Ingress Protection (IP) enclosures are to provide protection
against foreign objects and moisture. The standard cabinet shall
conform to IP40, and a cabinet upgrade to IP55 shall be
available
Jose Luis Sanchez
WW EMEA GITC
Page 52
3/26/2015
7.11. Warranty Information

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

technicians (8am - 5pm local time, Monday-Friday)
Procurement and installation of all replacement parts
Genuine new replacement parts
8. Electrical Requirements
8.1.
Field Instrumentation
All field instrumentation and equipment supplied to this specification and used with
the process control system must meet the minimum applicable requirements set
forth by the International Electrotechnical Commission (IEC) standards and comply
with the latest edition of the references listed below:
International Electrotechnical Commission (IEC)

IEC 60751 (1983-01) Industrial platinum resistance thermometer
sensor
IEC 61000-4-2 (2001-04) Electromagnetic compatibility (EMC)- Part

4-2: Testing and measurement techniques Electrostatic discharge immunity test
IEC 61000-4-3 (2002-03) Electromagnetic compatibility (EMC) - Part
4-3
IEC 61000-4-4 (1995-01) Electromagnetic compatibility (EMC) - Part
4: Testing and measurement techniques - Electrical fast transient/burst immunity test
IEC 61158 (2000-08) Fieldbus standard for use in industrial control
systems Part 2: Physical Layer specification and service definition
IEC 61508: Functional Safety, Safety Related Systems
National Fire Protection Association
NFPA 70 National Electrical Code
Underwriters Laboratories
UL Certificate
Canadian Standards Association
CSA Certificate
ISO-9001
NEC (National Electrical Code) Standard 500
9. Environmental Conditions
9.1.
Indoor Installations
Equipment installed in air-conditioned buildings shall be designed to operate in the
following environmental conditions:
Jose Luis Sanchez

WW EMEA GITC
Temperature range: 0C to 60C.

Relative humidity: 5% to 95% RH.
Page 53
3/26/2015
9.2.
Outdoor Installations
It shall be possible to install the I/O system in outdoor enclosures in Class 1 Div 2
(Groups A, B, C, and D) and CENELEC/ATEX Zone 2 hazardous environments. The
minimum ratings of outdoor panels is to be NEMA 4x.
9.3.
Storage Conditions
It shall be possible to store the equipment before installation for up to 6 months in
an air-conditioned building under the following conditions:
The equipment shall be packed in a moisture proof container

Storage temperature: -40C to 70C.
Relative humidity (outside the moisture proof container): 5% to 95%.
10. Appendix A
10.1. Definitions
This section contains definitions for acronyms, abbreviations, words, and terms as
they are used in this document.
10.1.1. Acronyms and Abbreviations

Acronyms and abbreviations used in this document:
CPU Central Processing Unit

HART Highway Addressable Remote Transducer
HMI Human Machine Interface
IEC International Electrotechnical Commission
I/O Input/Output
ISA The Instrumentation, Systems, and Automation Society
MTBF Mean Time Between Failures
OLE Object Linking and Embedding
OPC OLE for Process Control
OS Operator Station
PC Personal Computer
RFI Radio Frequency Interference
10.1.2. Terms
Terms used in this document:
Alarm Logging: Editor for configuring the message system in the

operator station and the application for displaying, archiving, and
handling
messages.
Archive: Saving measured values and messages in the operator

station to history so the data can be called up over a long period of
time.
Audible signal device: Horn, bell, buzzer, or similar device

indicating
that a new alarm or message has arrived at the operator station.
Availability: The probability that a system will be able to perform its

designated function when required.
Bus: A path for electrical signals allowing the exchange of data

between various components of a computer or system.
Central Processing Unit (CPU): The central part of the controller in

which the operator program is stored and processed, and the operating system and
communication interfaces are contained.
Jose Luis Sanchez

WW EMEA GITC
Page 54
3/26/2015
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 the

transmitting and receiving of digital information over a communication system, for
example a bus.
Configurable: The capability to select and connect standard hardware

modules (blocks) to create a system; or the capability to change
functionality or
sizing of software functions by changing parameters
without having to modify or regenerate
software.
Configuration: The physical installation of hardware modules to

satisfy
system requirements; or the selection of software options to
satisfy
system requirements.
Cycle: In the controller, the scanning of inputs, execution of

algorithms by the controller, and transmission of output values to
devices.
Discrete Control: Control where inputs, algorithms, and outputs are

based on logical (True or False) values.
Distributed I/O: Field devices or analog and digital modules located at

a distance from their central controller.
Ethernet: Hardware type standard for data transmission using coax,

twisted pair, fiber optic cable, or wireless, usually running at 10 Mbps (see Fast
Ethernet).
Faceplate: On the Operator Station screen, a graphic element that

represents, for example, an analog controller instrument, a hardwired 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
control devices.
Function Block: A control bock as defined in IEC 1131-3. See also

Block.
GPS: Global Positioning System, a satellite based system, which shall

provide the exact position anywhere on earth, and the time of day.
Human Machine Interface (HMI): The graphical interface program

for
allowing an operator to interact with and control a process.
Instance: A copy of a function block, which is used again in

the
control configuration for a similar application.
Ladder logic (LAD): Graphical representation of the automation task

using
relay symbols complying with DIN 19239.
Logs: Files or printouts of information in chronological order.
Mode: Control block operational condition, such as manual, automatic,

or cascade.
OPC: Object Linking and Embedding for Process Control, a software

application, which allows bi-directional data flow between two separate applications.
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
Jose Luis Sanchez

WW EMEA GITC
Page 55
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 56
3/26/2015
VFD Drives premiere

Integration and Automatic
Configuration
Document
Jose Luis Sanchez

WW EMEA GITC
Page 57
3/26/2015
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
Jose Luis Sanchez

WW EMEA GITC
Page 58
3/26/2015
Ethernet IP Network
Document
Jose Luis Sanchez

WW EMEA GITC
Page 59
3/26/2015
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.
Bidder Requirements
2.1
Technical
2.1.1
Trained Personnel
Service 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
Experience
Industrial 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
Jose Luis Sanchez
WW EMEA GITC
Page 60
3/26/2015
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
Jose Luis Sanchez

WW EMEA GITC
Commercial
2.2.1
Quotation Submittal Requirements

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

(Specific requirements by issuing company)
Page 61
3/26/2015
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 Manufacturers 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.
Services to be Supplied
4.1
Option 1: Ethernet Network Design

4.1.1
Jose Luis Sanchez

WW EMEA GITC
Requirements Analysis
The 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
Page 62
3/26/2015
4.1.2
Jose Luis Sanchez

WW EMEA GITC
Review and Discussion

The 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.
Page 63
3/26/2015
4.1.3
Network Design Development

The 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.
Jose Luis Sanchez

WW EMEA GITC
Page 64
3/26/2015
4.2.1
Ethernet Network Design Assessment

The 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:
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
Jose Luis Sanchez

WW EMEA GITC
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)
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
Page 65
3/26/2015
4.3.2
Configuration Verifications
4.3.3
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)
Operational Network Measurements
Jose Luis Sanchez

WW EMEA GITC
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
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).
Page 66
3/26/2015
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
5.2
Ethernet Inactive Network Test Equipment for Fiber Media
5.3
Jose Luis Sanchez

WW EMEA GITC
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%) - Dualended 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
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)
Ethernet Active Network Test Equipment

General requirements
Page 67
3/26/2015
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, email, FTP, NT file, WINS, and Web.
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
Jose Luis Sanchez

WW EMEA GITC
Page 68
3/26/2015
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
Jose Luis Sanchez

WW EMEA GITC
Page 69
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 70
3/26/2015
Panel Operator Interface

Document
2.1
GRAPHICAL OPERATOR INTERFACE
Jose Luis Sanchez

WW EMEA GITC
Page 71
3/26/2015
A.
Manufacturers:
1.
Model 2711P
2.
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 C
b. Storage Temperature range of minus 20 degrees to plus 70 degrees C
c. 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.
Jose Luis Sanchez

WW EMEA GITC
Page 72
3/26/2015
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
D.
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.
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 selectors
B. ASCII entry devices
C. Diagnostic indicators
D. Message displays
E. Embedded numeric and ASCII variable displays
F. Analog and digital gauges
G. Trends
H. 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.
B.
C.
D.
E.
F.
G.
H.
I.
J.
E.
Jose Luis Sanchez

WW EMEA GITC
Bit
4BCD
Unsigned Integer
Signed Integer
DINT
SINT
IEEE Floating Point
Bit Array
Character Array
Bool
0 or 1
0 to 9999
0 to 65535
-32768 to +32767
-2,147,483,648 to 2,147,483,647
-128 to +127
-99,999,997,952 to 999,999,995,904
4,294,967,295
protocol dependent
True or False
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.
Page 73
3/26/2015
F.
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.
Graphical Operator Interface Four Inch Display

1.
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 supertwist 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.
f.
g.
h.
i.
G.
Jose Luis Sanchez

WW EMEA GITC
One Universal Serial Bus (USB) port shall be provided for a printer connection,
keyboard, or mouse.
The standard memory shall be 32 MB Flash memory.
Provide Compact Flash Memory. Card Selected and sized based upon memory
requirements with a 32MB minimum.
The unit shall include a battery-backed clock and shall timestamp critical data.
Agency approvals shall include UL, CSA approved; Class 1, Div 2; Groups A,
B, C, D certified; CE marked; and C-Tick
Graphical Operator Interface Six Inch Display

1.
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 supertwist nematic (FSTN).
b.
84mm high).
c.
The operator input shall be keypad, touch screen, or both.
Page 74
3/26/2015
*********************************************************
Select either touch screen; keypad with 10 relegendable function keys,
numeric keypad, and cursor control keys; or both.
*********************************************************
d.

*********************************************************
*********************************************************
e.
f.
g.
h.
i.
H.
keyboard, or mouse.
Graphical Operator Interface Six Inch Display

1. 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.
84mm high).
c.
The operator input shall be keypad, touch screen, or both.
*********************************************************
*********************************************************
d.

*********************************************************
*********************************************************
e.
f.
g.
h.
i.
I.
Jose Luis Sanchez

WW EMEA GITC
keyboard, or mouse.
Graphical Operator Interface Seven Inch Display

1.
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.
Page 75
3/26/2015
b.
c.
99mm high).
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.
f.
g.
h.
i.
j.
J.
Two Universal Serial Bus (USB) ports shall be provided for a printer
connection, keyboard, or mouse.
The display shall have a field replaceable backlight.
Graphical Operator Interface Ten Inch Display

4.
The operator interface panel shall be Series 2711P, PanelView Plus 1000
5.
6.
Specifications
a.
b.
158mm high).
c.
*********************************************************
*********************************************************
d.
*********************************************************
*********************************************************
e.
f.
g.
h.
i.
j.
K.
Jose Luis Sanchez
WW EMEA GITC
Graphical Operator Interface Twelve Inch Display

Page 76
3/26/2015
7.
8.
9.
Specifications
a.
b.
184mm high).
c.
*********************************************************
*********************************************************
d.
*********************************************************
*********************************************************
e.
f.
g.
h.
i.
j.
L.
Graphical Operator Interface Fifteen Inch Display

10.
11.
12.
Specifications
k.
l.
228mm high).
m.
*********************************************************
*********************************************************
n.
*********************************************************
*********************************************************
o.
p.
q.
r.
Jose Luis Sanchez

WW EMEA GITC
Page 77
3/26/2015
s.
t.
PART 3 EXECUTION
1.1
1.2
1.3
INSTALLATION
A.
Install in accordance with manufacturers 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.
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.
CLEANING
A.
Jose Luis Sanchez

WW EMEA GITC
Clean units as recommended by manufacturer.
Page 78
3/26/2015
HMI/SCADA
Document
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:
Jose Luis Sanchez

WW EMEA GITC
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.
Page 79
3/26/2015
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
HMI
application.
1.6 In non-redundant scenarios, the HMI shall support up to two HMI servers hosted on a single
computer.
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 AllenBradley 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 station
in 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 le
versions 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
Microsofts 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
Jose Luis Sanchez
WW EMEA GITC
Page 80
3/26/2015
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 the
HMI.
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
HMI
Servers, 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
in
the 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 the
migration 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
allows
for 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
the
configuration software or the HMI client.
3. Security
3.1 The HMI shall use the FactoryTalk Local Directory and/or Network Directory
provided 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.
Jose Luis Sanchez

WW EMEA GITC
Page 81
3/26/2015
3.2 FactoryTalk Security shall use the following policies to defi ne system-wide rules
that 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.
Jose Luis Sanchez

WW EMEA GITC
Page 82
3/26/2015
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.
Jose Luis Sanchez
WW EMEA GITC
Page 83
3/26/2015
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 failover 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.
Jose Luis Sanchez

WW EMEA GITC
Page 84
3/26/2015
5.12 The HMI shall provide additional offl ine access to a data servers 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 AllenBradley 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.
Jose Luis Sanchez

WW EMEA GITC
Page 85
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 86
3/26/2015
10.6 The HMI macro editor shall be a simple text editor permitting other editors to
create macro fi les when necessary.
11. HMI Alarming

11.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.
Jose Luis Sanchez

WW EMEA GITC
Page 87
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 88
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 89
3/26/2015
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
Server
2005 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.
Jose Luis Sanchez

WW EMEA GITC
Page 90
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 91
3/26/2015
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
Jose Luis Sanchez
WW EMEA GITC
Page 92
3/26/2015
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 thirdparty 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.
Jose Luis Sanchez

WW EMEA GITC
Page 93
3/26/2015
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
Jose Luis Sanchez

WW EMEA GITC
Page 94
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 95
3/26/2015
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 an
XML 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
Jose Luis Sanchez
WW EMEA GITC
Page 96
3/26/2015
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 pens 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.
Jose Luis Sanchez

WW EMEA GITC
Page 97
3/26/2015
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,
and
paste 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.
relational operators: equal, not equal, less than, greater than, less than or equal to,
and greater than or equal to.
logical operators: AND, OR, and negation.
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
expression
evaluates true.
21. Process Faceplates

Jose Luis Sanchez
WW EMEA GITC
Page 98
3/26/2015
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
recipe
system shall allow uploading and downloading recipe fi les.
22.2 The recipe system shall allow issuing a command before a recipe is downloaded
and
after downloading has completed.
22.3 The recipe system shall allow verifying communications before downloading,
verifying
the 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 the
values 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.
Jose Luis Sanchez

WW EMEA GITC
Page 99
3/26/2015
23.2 The HMI shall also allow the application to be opened in a particular language
for
development 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 HMI
applications.
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 runtime
application.
23.8 The HMI shall allow exporting user-defi ned text strings into an editable fi le in
UNICODE
format 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 onetime editing to recurring strings.
23.10 The HMI shall provide a language function that returns the ID of the current
run-time
language.
24. Global Objects

24.1 The HMI shall allow linking the appearance and behavior of a graphic object to
multiple
copies 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 from
another 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
except
for ActiveX controls.
24.5 The HMI shall provide the ability to drag and drop global objects onto standard
displays
Jose Luis Sanchez
WW EMEA GITC
Page 100
3/26/2015
to create reference objects.

24.6 When changes are made to the base object, its reference objects shall inherit
the same
changes. 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
determine
which 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
base
object. This object shall become a standard graphic object.
24.10 The HMI shall provide default values for the link properties assigned to a
reference
object 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
the
use of global objects without having to break the link to the base objects tags and
expressions. Structured tag support shall be available.
24.12 The HMI shall provide faceplates that support RSLogix instructions available as
global
objects.
25. Interoperability
25.1 The HMI shall be based on standards that allow the HMIs data to be accessed,
shared
among, and be fully interoperable with other Windows applications.
25.2 The HMIs graphic displays shall be containers for ActiveX controls and be able
to access
the 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 other
programs such as Microsoft Excel.
25.4 The HMIs 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.
Jose Luis Sanchez
WW EMEA GITC
Page 101
3/26/2015
26. Networks
26.1 The HMI shall use Windows security to support a centralized and secure user
name and
password 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 Operation

27.1 The HMI shall permit client/server operation whereby graphics functionality (full
operations) 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 standard
Internet Information Services (IIS) functionality.
27.7 The client shall support Windows 2000 Professional, Windows 2000 Server,
Windows
2003 Server, Windows XP, and Windows Vista.
27.8 The HMI clients/servers shall implement security via Microsofts Windows
security
model, 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 thin
client 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 setup wizard
will 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 a
license 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 able
to 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 is
Jose Luis Sanchez
WW EMEA GITC
Page 102
3/26/2015
not 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
of
ownership.
27.15 The HMI shall support many run-time edits, changes that take eff ect
immediately and
changes 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
OPC
Data 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 HMI
and 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 of
failed 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 servers 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
starting
and stopping of Startup components on both Primary and Secondary HMI servers.
Jose Luis Sanchez
WW EMEA GITC
Page 103
3/26/2015
28.14 The HMI shall ensure the server is not put into an active state until all
subsystems are
ready 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 state
of 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 FactoryTalk
View 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 and
Firefox.
30.3 The remote thin-client shall be an internet browser with a small plug-in, without the
need for an additional client software installation.
30.4 The HMI shall support multiple concurrent thick and thin-client connections.
Jose Luis Sanchez

WW EMEA GITC
Page 104
3/26/2015
Jose Luis Sanchez

WW EMEA GITC
Page 105
3/26/2015
Factorytalk Historian SE
Document
Jose Luis Sanchez

WW EMEA GITC
Page 106
3/26/2015
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

Jose Luis Sanchez
WW EMEA GITC
Page 107
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 108
3/26/2015
Factorytalk Asset Center

Document
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 facilitys 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 FactoryTalkenabled 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
Jose Luis Sanchez
WW EMEA GITC
Page 109
3/26/2015
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.
Jose Luis Sanchez

WW EMEA GITC
Page 110
3/26/2015
Jose Luis Sanchez

WW EMEA GITC
Page 111
3/26/2015

DCS Process Contro PlantPax

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DCS Process Contro PlantPax

Uploaded by

Copyright:

Available Formats

Rockwell Automation WW Control Solution Procurement Specifications

Rockwell Automation WW Control Solution Procurement Specifications

Plant Wide DCS Process Control

WW EMEA Procurement Control System Draft 1

Rockwell Automation WW Control Solution Procurement Specifications

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

2.1.1. Controller Capacity..................................................................................11

Field Device Interfaces and Device networks.....................18

Rockwell Automation WW Control Solution Procurement Specifications

2.9.4. Profibus I/O.............................................................................................. 19

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

3.1.1. Engineering Workstation Configuration...................................................20

Operator Interface Configuration.......................................22

Operator Interface Visualization........................................24

Operator Station Redundancy.................................................................24

Alarm and Event Management...........................................25

Graphical Display Editor..........................................................................22

3.5.1. Trend Data............................................................................................... 28

Controller Programming Environment................................30

4.1.1. Controller Editor......................................................................................30

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

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

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

Controller Configuration Languages..................................32

Function Block Diagram..........................................................................32

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

Jose Luis Sanchez

Rockwell Automation WW Control Solution Procurement Specifications

PIDE Loop Control....................................................................................34

Batch & Sequencing Control..............................................37

4.9.1. Basic Batch & Sequencing.......................................................................37

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

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

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

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

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

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

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

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

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

6.1.1. Operator Training....................................................................................44

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

Inputs and Outputs...........................................................47

7.1.1. Analog Inputs..........................................................................................48

Rockwell Automation WW Control Solution Procurement Specifications

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

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

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

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

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

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

Acronyms and Abbreviations...............................................................53

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

Manufacturers Specifications and Guidelines....................61

Option 1: Ethernet Network Design...................................61

Jose Luis Sanchez

Rockwell Automation WW Control Solution Procurement Specifications

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

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

Test Equipment Usage and Equipment Specifications.......66

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

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

Rockwell Automation WW Control Solution Procurement Specifications

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