Process Control System

Procurement Specification
Document

V2.0
Rockwell Automation
January 2009
PROCES-SP002B-EN-E

Page 2 of 61
Table of Contents

1. System Specification Overview........................................6

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

Page 3 of 61
 2.9.2. HART I/O........................................................................................................17
2.9.3. Foundation Fieldbus I/O..................................................................................17
2.9.4. Profibus I/O.....................................................................................................18
2.9.5. Intelligent Device Management.......................................................................18
3. System Configuration, Visualization and Maintenance
18
3.1. Engineering Workstation..........................................................................................18
3.1.1. Engineering Workstation Configuration..........................................................18
3.1.2. Engineering Workstation Functions................................................................19
3.1.3. Reusable Applications.....................................................................................20
3.2. Operator Interface Configuration..............................................................................20
3.2.1. Graphical Display Editor.................................................................................20
3.2.2. Graphic Displays.............................................................................................21
3.2.3. Standard Faceplate Library..............................................................................21
3.2.4. Integrated Batch Visualization........................................................................22
3.3. Operator Interface Visualization...............................................................................22
3.3.1. Operator Station Redundancy..........................................................................23
3.3.2. Operator Station Security................................................................................23
3.3.3. Area Security...................................................................................................23
3.3.4. Alarm Window................................................................................................23
3.3.5. Faceplates........................................................................................................24
3.3.6. Time Synchronization......................................................................................24
3.4. Alarm and Event Management.................................................................................24
3.4.1. Alarm Priorities...............................................................................................25
3.4.2. Alarm Detection...............................................................................................25
3.4.3. Alarm Acknowledgment..................................................................................26
3.4.4. Alarm Logging.................................................................................................27
3.4.5. Alarm Navigation............................................................................................27
3.4.6. Alarm Archiving..............................................................................................27
3.5. Trending....................................................................................................................27
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......................................................................................32
4.5. Control Strategy Development.................................................................................32
4.6. Controller Configuration Languages........................................................................32
4.6.1. Function Block Diagram..................................................................................33
4.6.2. Sequential Function Chart...............................................................................33
4.6.3. Structured Text................................................................................................34
4.6.4. Ladder Diagram...............................................................................................34
4.6.5. User Defined Functions and Tags....................................................................35

Page 4 of 61
 4.7. Alarm and Event Detection.......................................................................................35
4.8. Process Control.........................................................................................................35
4.8.1. PIDE Loop Control..........................................................................................36
4.8.2. PIDE Integrated Auto-Tune.............................................................................36
4.8.3. PIDE Optimized Auto-Tune............................................................................36
4.8.4. Standard Library for Controller.......................................................................36
4.8.5. Computational Functions.................................................................................37
4.8.6. Discrete Control Functions..............................................................................37
4.8.7. Advanced Regulatory Control.........................................................................37
4.8.8. Fuzzy Logic.....................................................................................................38
4.9. Batch & Sequencing Control....................................................................................38
4.9.1. Basic Batch & Sequencing..............................................................................38
4.9.2. Comprehensive Batch & Sequencing..............................................................39
4.10. Drive Control............................................................................................................39
4.11. Motion Control..........................................................................................................40
4.12. SCADA and Third Party Connectivity.....................................................................40
4.12.1. OPC Interface..................................................................................................40
4.12.2. Serial Interface.................................................................................................41
4.12.3. Ethernet............................................................................................................41
4.12.4. Third Party PLC Communication....................................................................41
4.12.5. Third Party DCS Communication...................................................................41
4.13. Controller Application Code Security......................................................................41
4.14. Process and System Simulation................................................................................42
5. Production Management................................................42
5.1. Historical Data Archiving.........................................................................................42
5.2. Plant Data Historian..................................................................................................43
5.3. Historical Data Reporting.........................................................................................43
5.4. Dynamic Resource Management..............................................................................44
5.5. Batch Reporting........................................................................................................44
5.6. Batch Recipe Management.......................................................................................45
5.7. Material Tracking......................................................................................................45
5.8. MES Interface...........................................................................................................46
5.9. Integrated Asset Management...................................................................................46
6. Service and Support.......................................................47
6.1. Training.....................................................................................................................47
6.1.1. Operator Training............................................................................................47
6.1.2. Maintenance and Hardware Training..............................................................48
6.1.3. Engineering Training.......................................................................................48
6.2. Technical Support.....................................................................................................49
6.2.1. Onsite Support Services...................................................................................49
7. Hardware Specifications................................................50
7.1. Inputs and Outputs....................................................................................................50
7.1.1. Analog Inputs...................................................................................................52
7.1.2. Digital Inputs...................................................................................................52
7.1.3. Analog Outputs................................................................................................52
7.1.4. Digital Outputs.................................................................................................52

Page 5 of 61
 7.1.5. I/O Terminations..............................................................................................53
7.1.6. Spare Capacity.................................................................................................53
7.2. Controller Removal and Insertion under Power.......................................................53
7.3. Controller Redundancy.............................................................................................53
7.4. Controller Redundancy Switch-over Time...............................................................54
7.5. Safety Controllers - SIL............................................................................................54
7.6. Controller Power Supplies........................................................................................54
7.7. Controller Memory Backup......................................................................................54
7.8. Controller Memory Expandability............................................................................55
7.9. Controller Footprints.................................................................................................55
7.10. Cabinets.....................................................................................................................55
7.11. Warranty Information...............................................................................................55
8. Electrical Requirements.................................................56
8.1. Field Instrumentation................................................................................................56
9. Environmental Conditions.............................................56
9.1. Indoor Installations...................................................................................................56
9.2. Outdoor Installations.................................................................................................57
9.3. Storage Conditions....................................................................................................57
10.Appendix A......................................................................57
10.1. Definitions.................................................................................................................57
10.1.1. Acronyms and Abbreviations..........................................................................57
10.1.2. Terms...............................................................................................................57

Page 6 of 61
1. System Specification Overview
This specification defines the minimum mandatory requirements for the process
automation system and associated software and support services.

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

The process automation system should provide flexibility, scalability and expandability
when solving batch and process applications unlike a traditional closed, rigid system like
a DCS. The system should allow users to incrementally implement plant automation
using only the components needed. When an upgrade or addition to the system is
required components should be easily added.

The process automation system must include the following features traditionally
associated with both a programmable logic controller such as programming in ladder
logic and remote I/O architectures and a distributed control system (such as continuous
and complex control, advanced operator interfaces, and sophisticated redundancy). These
capabilities must seamlessly reside in the control system without the use of special
gateways or interfaces. In addition, the system shall provide seamless integration of
continuous, batch and safety protection control, including common software tools.

The system shall be an open system composed of standards-based technology including

PC platforms with a Windows operating system (supporting XP, Vista, Server 2003 and
Server 2008), Ethernet communications, TCP/IP, OPC for interconnectivity of multiple
systems from different suppliers, field mountable control system, remote I/O subsystem,
and bus-based serial communication with smart field devices over FieldBus, HART,
Profibus, DeviceNet, and Modbus networks.

This specification does not include field instrumentation and management information
systems.

2. System Architecture Requirements

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

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

2.1. System Scalability

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

2.1.1. Controller Capacity

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

2.1.2. I/O Network and I/O Capacity

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

2.1.3. Controller Application Capacity

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

2.2. System Redundancy

The system shall be of a highly reliable design and shall have an
operational availability in excess 99.5% (i.e., annual downtime of less
than 44 hours per year). Operational availability shall be considered to
be met when no more than three operator stations or controllers, in any
combination, are inoperable. The system design shall provide for 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

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

2.3. System Expansion

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

2.4. Software Revisions

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

2.5. System Sever

The system shall be capable of running a pair of similarly configured
servers/workstations in a redundant configuration where at any point
in time, one is the acting Primary and the other the acting Backup. An
on-line database duplication mechanism shall be available.

It shall be possible to remove one of the redundant servers for

maintenance without interrupting operation, and upon its
reinstatement, re-synchronize the databases via a push-button on the
screen, again without interruption to system operation. A simple
method of manually initiating a fail-over shall be provided to assist
with such maintenance operations.

2.5.1. HMI Server

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

2.5.2. Data Server

The data server links networks and devices to system wide
visualization and development components such as HMI
clients and engineering workstations. It shall provide

Page 9 of 61
 communication services between applications and devices on
the plant floor allowing users to read, write, and configure
values in plant floor devices, such as sensor readings and other
system controller data.

Data servers shall be configurable to run on both a primary

computer and a backup computer. The system should
automatically switch to a backup computer if communication
with the primary computer fails.
The servers should handle failure detection and failovers
automatically for all components (clients) of the system. In a
traditional system (DCS), each client must independently
monitor connections, detect communication failures, and switch
between backup and primary computers. This is not preferred.

2.5.3. Alarm Server

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

2.5.4. Domain Server

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

2.5.5. Security Server

An available security server should protect against
unauthorized use but still allow authorized users to use the
system efficiently. The security is to be a centralized system
which restricts access to system resources based on key
security components.

The security server shall have the capability to have either

control-system local users/groups or domain-linked
users/groups and the ability to use an existing domain.

The key components that are to be securely managed by the

security server are:
 Users and groups of users
 Actions, such as read, write, update, and download
which can be performed on a secured resource.
 Defined objects in the system, such as areas, data
servers, graphic displays, control networks and devices,
and so on, for which actions are allowed or denied.
Each piece of the system can define its own set of
securable resources and actions.
 The computers or groups of computers from which
actions can be performed on a secured resource.

Page 10 of 61
2.5.6. License Server
Electronic software licenses for components are to be managed
by a software license server. Software licenses for engineering
workstations and for operator interface consoles shall be
independent of the type and mixture of I/O used (analog vs.
discrete, input vs. output). The software licenses (both runtime
and engineering) shall be portable allowing the operator to
transfer licenses from one PC to another without requiring
intervention from the vendor.

To help minimize the risk associated with changes in project

scope, if software is licensed on a tag-by-tag basis, the vendor
shall supply in writing details on how the required software
license would change if the system I/O was increased or if the
mix of system I/O was modified.

2.5.7. Historian Server

The system shall have available if needed a historian server
that performs process data collection from the control system.
There should be included a user configurable data collection
functions defining what data is to be collected and under what
circumstances it is to be collected. Users shall be capable of
accessing historical data.

When the system is configured, and as it is adapted over time,

it shall be possible to define classes of information that should
be retained, as well as specific system-level data that should be
collected. As with process historical data, this data shall be
accessed for viewing and for reporting.

2.5.8. OPC Server

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

2.5.9. Batch Server

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

Page 11 of 61
 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. Directory Service

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

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

2.6.3. Alarms and Events

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

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

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

2.7.1. Network Management

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

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

2.7.2. Supervisory Network

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

2.7.3. Control Network

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

These networks shall have the following capabilities:

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

2.7.4. Control Network Redundancy and Alarming

Failure of any supervisory system shall be announced audibly
and visually via the alarming subsystem.

To ensure maximum reliability, communications shall be

redundant. The communications system shall be capable of
sustaining loss of one media channel without loss of data or
performance degradation. The Bidder shall include the typical
data throughput of his communications system, in baud rate
and number of analog values per second.

Loss of communications shall not cause loss of control at the

local subsystems. Also, loss of a local subsystem (either a

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

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

2.8.1. Analog I/O

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

2.8.2. Discrete I/O

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

2.8.3. High-Speed I/O

System shall provide high-speed discrete and analog control for
plant automation applications such as material handling and
packaging equipment which require the ability to perform 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

Page 15 of 61
 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 in-
cabinet I/O must support EtherNet/IP communication. The
distributed In-Cabinet I/O is to be offered in modular and block
I/O styles. Modular I/O is a system of interface cards and
communications adapters that interface directly to the sensors
and actuators of the machine/process and communicate their
status to the controller via a communication network.

2.8.6. Distributed On-Machine I/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
modules with intrinsically safe barriers built into the I/O are to
be available. These I/O can be distributed in hazardous areas
without the use of bulky explosion proof or purged enclosures
which are expensive and difficult to maintain. The I/O should
have built-in galvanic isolators which reduce terminations and
the size of cabinets.

2.8.8. Conformally Coated I/O

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

Page 16 of 61
 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 time-
consuming hardwiring. Direct connectivity improves
communication and shall provide device-level diagnostics not
available or easily accessible through hardwired I/O interfaces.
Because DeviceNet uses a trunk line/drop line topology, a single
DeviceNet cable shall provide power and communication signal to
all devices on the network. This significantly reduces the amount
of wiring required and greatly simplifies installation.

DeviceNet shall provide the system controllers with a direct

network connection to low-level devices with increased device-
level diagnostics allowing for troubleshooting, trending and
improved data collection from each device.

Explicit Messaging shall be supported in the DeviceNet

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

Automatic Device Replace (ADR) shall be supported in the

DeviceNet scanner module, so that when a DeviceNet capable
device is replaced on the network, its configuration will be
automatically refreshed to the replacement, by the scanner.

Page 17 of 61
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.

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

2.9.4. Profibus I/O

The system must support Profibus networking, an open, digital
communication system with a wide range of applications,
particularly in the fields of factory and process automation.

The system shall be capable of integrating directly to a

Profibus PA network via Ethernet (without requiring DP
masters or couplers).

The system shall have an option to connect to Profibus DP

networks via interface cards that fit the system form factor of
the processor and I/O racks.

2.9.5. Intelligent Device Management

Software that is able to configure all intelligent field devices in

the plant, and support the user in managing them, is to be
available. It should be based on the FDT/DTM standard, as this
technology provides engineers with the freedom to integrate
field and communication components supplied by all
complying third parties.

ControlNet, EtherNet/IP, DeviceNet, HART, Profibus and

other field devices that support the Field Device Tool
(FDT/DTM) standard interface specification, including
actuators and transmitters should be capable of being managed
by the system.

3. System Configuration, Visualization and Maintenance

This section specifies the configuration and visualization of the Engineering and
Operator Workstations and supporting engineering software.

3.1. Engineering Workstation

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

3.1.1. Engineering Workstation Configuration

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

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

3.1.2. Engineering Workstation Functions

Only one engineering workstation shall be necessary to
perform all of the traditional configuration tasks (Control,
HMI, Batch, and History), intelligent device configuration
(transmitters, drives, analyzers, etc.), database generation, and
editing. However, it shall also be possible to use multiple
engineering workstations simultaneously for this work.

The central engineering workstation shall be capable of

supporting all of the following functions:

 I/O configuration
 DCS hardware configuration (controller, operator
stations)
 Configuration of plant and field communication
networks
 intelligent device instrument configuration and
maintenance
 Configuration of Drives, Weigh scales and Motor
Management Equipment
 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

Page 20 of 61
  Configuration of historical and real-time trends
 Management of alarm and event configuration
 Report creation, generation and modification
 Configuration of operator security and access privileges
 Batch Configuration and Planning (Recipes,
Procedures, Formulas, etc.)
 A controller simulator tool to enable logic debugging
and testing without requiring any hardware.

3.1.3. Reusable Applications

The system shall include mechanisms to manage reusable
application designs. The library management function shall be
shared or common among applications used to create and
manage engineering configurations, relative to control
strategies, displays, quality, reports, calculations, recipes and
procedures.

 Library objects shall be available, on-line for reuse.

 Library objects can be locked, such that they cannot be
modified.
 Library objects may be encrypted to protect proprietary
application design information.
 Library objects shall be retrievable and editable in an
organized manner.
 Documents or objects can be checked out from the
library, reviewed and edited.
 Edited documents can be returned to the library i.e.
checked in

3.2. Operator Interface Configuration

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

3.2.1. Graphical Display Editor

Provided should be a full-featured graphics editor that includes
a complete set of drawing objects and sophisticated drawing
tools and customizable toolbars, object animation and
command wizards.

The editor’s application tree shall provide users with a visual

picture of an application. It shall let users see and explore all

Page 21 of 61
 the components of the system and make it easy to add, modify
and remove components, and also allows users to browse and
access tags stored in controllers and other data servers. The
display editor should support, but must not require, a custom
scripting engine such as Visual Basic for Applications.

3.2.2. Graphic Displays

The system shall permit configuration of custom graphic
displays. These displays shall be accessible through assignable
user accounts, and using the standard system operator display
navigation functions. Revision of an existing display shall
result in automatic updating of any display servers in the
system scope. The system shall provide detailed documentation
of tags used on custom graphic displays. System shall support
designation of custom graphic displays to process areas for
purposes of alarm navigation.

Graphical displays should be capable of being:

 Created in a supplied graphics display editor.
 Dragged and dropped from a graphic library.
 Created by another Windows® application, then copied
and pasted into a display or inserted using Object
Linking and Embedding.
 ActiveX® objects embedded in the graphic display.
 Graphic display information can be exported to and
imported from an XML file.

A library of the following graphical objects should be included:

 Push buttons, macro buttons, ramp buttons
 Numeric display and numeric entry objects
 Control List Selector
 Numeric and string pop-up scratchpads and keypads
 String display and entry enable
 Local message display
 Alarm, diagnostics log, and information message
objects
 Time and date objects
 Display navigation objects
 Navigation keys
 Login, Logout, and Shutdown buttons
 Symbol and multi-state indicators
 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

Page 22 of 61
 and symbols shall be available. Optional Industry specific
libraries shall be available.

The standard HMI library shall consist of the following pre-

engineered symbols and faceplates at a minimum:

 Standard PID Controller

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

3.2.4. Integrated Batch 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:
 Batch Overview Display
 Batch Unit Display
 eProcedure Displays
 Material Manager Displays

3.3. Operator Interface Visualization

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

Page 23 of 61
3.3.1. Operator Station Redundancy
The system is to support redundant HMI servers, data servers,
and networks. This is to ensure that the data the operators are
viewing is always up-to-date. To maximize data availability
and integrity, the Operator Station shall provide the ability for
configuration of system redundancy. This shall in no way limit
or restrict the use of the client/server configuration and/or
architecture.

Clients shall automatically failover to the backup or redundant

server. This operation shall not require any application
reprogramming or reconfiguration. Client stations shall support
the designation of different primary servers allowing the
network loading to be distributed and to ensure that in the
event of a failure not all clients will experience a switchover.

3.3.2. Operator Station Security

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

3.3.3. Area Security

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

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

Page 24 of 61
 when there are no unacknowledged alarms for the operator to
process. Each graphic display shall also be linked to an Alarm
Summary graphic that allows for a configurable sort or filter by
priority, and grouping of alarms.

On occurrence of an alarm, the graphic display shall output the

point identification, point type and point description on a
dedicated line. If multiple alarm/change of state conditions
occurs, subsequent messages shall overwrite the display if they
are higher priority. As subsequent alarms are displayed, the
previous alarm information shall move to an unacknowledged
alarm list awaiting acknowledgment by the operator.

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

3.3.6. Time Synchronization

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

3.4. Alarm and Event Management

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

Alarm (and event) annunciation, acknowledgement, and related functions shall be

able to be associated with an individual, responsible operator, user, or group of
users. In this way, operators and users may have their view of points or tags in
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

Page 25 of 61
responsible operator(s) shall be permitted to acknowledge or clear the respective
alarms.

The interface to the appropriate user for alarm presentation and control shall be
via the operator’s standard navigation screen or specific windows, either
dedicated, or "pop up" (or both). The operator shall have the option to retain an
alarm manager window on his screen at all times, or may invoke the alarm
manager screen as required. Invocation of the alarm manager screens shall be
user configurable and shall include designation of alarm groups and "filter"
criteria for the display (e.g., tag, equipment reference, operator, time window,
batch, process unit, and process area).

3.4.1. Alarm Priorities

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

 Urgent
 High
 Medium
 Low

Each alarm type shall be individually able to be prioritized into

one of the above categories. Urgent, High, Medium and Low
priority alarms shall be displayed as such in the system Alarm
Summary. Audible Alarm and Alarm Paging

An audible alarm shall be configurable for each of the above

alarm priorities. Alarms shall be routable to external alarm
hardware (via system I/O) and/or directly to the operator HMI.
If enabled, the annunciators on the operator station shall sound.
The operator station shall be able to use multimedia
technologies (such as .wav files and sound cards) to provide
realistic alarm annunciation. .

The system shall have the capability to send alarms directly to

pagers and email addresses via third-party (Win911) software.

3.4.2. Alarm Detection

Configuring a function block alarm in the controller shall
automatically cause the system to perform the following
actions when an alarm occurs:

 The alarm shall be time stamped to a resolution

appropriate for the location within the system at which

Page 26 of 61
 the alarm condition is monitored or detected (e.g., the
nearest second in the HMI, the nearest processing cycle
timestamp when in the controller or field device).
 The alarm shall be logged in the Event Database with
the Point Name, Alarm type, Alarm Priority, Point
Description, and new value
 The PV of the alarm shall turn to a presentation format
(color, object display) associated with the level and
priority of the alarm (e.g., red and flash) on any
standard or custom display which uses the point
 An Unacknowledged alarm entry shall be made in the
system alarm summary for Low, Medium, High and
Urgent Alarms or events
 The audible alarm shall sound (if configured)
 The alarm annunciators indicator shall flash until
acknowledged
 Once the alarm is acknowledged and has been reset the
alarm will be cleared from the alarm summary

3.4.3. Alarm Acknowledgment

In addition, the alarm zone of the operator interface shall show
this alarm provided it is the highest priority, unacknowledged
alarm in the system.

The system shall provide for efficient alarm acknowledgment

in a number of ways as follows:
 Selection of any parameter tag for the point in alarm from
a custom graphic and pressing the dedicated
acknowledge push-button
 Selection of the alarm in the system alarm zone and
pressing the dedicated acknowledge button
 Selection of the alarm in the alarm summary display and
pressing the dedicated acknowledge button
 By performing a page acknowledge from the alarm
summary display

On acknowledgment by the operator, the flashing indicator

shall turn to a presentation format designated for acknowledged
alarms (e.g., acknowledge color, steady, not flashing), and the
parameter shall remain in that presentation format on any
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:

Page 27 of 61
  Alarm message appearing on dedicated alarm line on
operator interface
 Alarm message appearing on alarm summary display
 Audible Tone (either using the PC Speaker or a sound
card)
 Alarm annunciation shall take advantage of multimedia
technology by providing realistic alarm sounds (via
.wav files).

Alarms shall be annunciated at the station even if there is no

operator currently signed-on. This feature shall be available on
network connected operator stations as long as the computer
running the operator station software remains logically
connected to the network.

3.4.4. Alarm Logging

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

3.4.5. Alarm Navigation

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

3.4.6. Alarm Archiving

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

3.5. Trending
The system shall support three levels of trending: real-time trending, short-term
historical trending, and archive/retrieval of short-term trending for indefinite
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.

Page 28 of 61
Operator workstations are to be capable of displaying both historical and current
tag values using trends. At runtime, when an operator opens a graphic display
containing a trend object, the data displayed in the trend can be real-time or
historical. A data server collects real-time data for the trend and historical data
comes from a data log model.

Two types of trend charts are to be available. A standard chart plots tag values
against time, whereas a XY plot chart plots the values of one or more tags
against another tag. For example, the temperature of a tank could be plotted
against time with a standard chart or against the pressure of the tank with a XY
plot chart.

 Every operator workstation shall provide viewing for real-time and

historical trend information. Data collected in any historical package
shall be available to all workstations. The system must support a
centralized approach to historical data collection.
 The system shall support operator defined sets of trends so that commonly
viewed historical information can be defined in trends once and easily
accessed by selecting a pre-configured screen target incorporated in
the graphic display. There should be no practical limit to the number
of trends that can be defined. Each trend screen shall support up to
eight (8) separate pens. Selection of points to be trended shall be menu
driven.
 Historical trends shall support seamless integration of both real-time and
historical data within a single trend window, with seamless movement
between the two. In the event that the screen should be scrolled to the
left, then historical values will be recalled from historical data files.
Scrolling the trend far enough to the right will result in current real-
time data being displayed as it should be collected.
 Zoom in/out and moving forwards and backwards in time shall be possible
with no more than two operator actions. A mechanism for selecting a
location on the trend, such as a hairline cursor and reading the numeric
values of the trends at that point in time shall be provided.
 It shall be possible to call up new historic trends and configure them online
from the Operator Interface.
 Pre-configured real-time trends shall be available from a faceplate.

3.5.1. Trend 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

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

3.6. Reports
Reporting software that allows end users to configure Web-based dashboards,
trends, and reports is to be available. It should include standard, pre-configured
reports for managing devices, equipment, alarms, events and control loops, as
well as batch or production run and shift reports. The application is to include
trending and dashboard capabilities for analysis and uses Microsoft Excel for
report generation.

In addition to gathering data from control system, the reporting software should
feature third-party connectors that address native and OPC DA real-time devices,
and OSI PI Historians.

The system shall also support a number of simple reporting options that allow
users to report critical data. Reports that can be configured as graphical displays
and then printed, created using VBA within the operator interface development
software, or created via third-party software such as Microsoft Word, Microsoft
Excel and Crystal Reports are to be supported.

 The Operator Interface shall provide an integral reporting subsystem used

to report both current and archived data.
 The reporting subsystem shall utilize standard a Windows tree/list view
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

Page 30 of 61
 dynamic and static properties reports, including but not limited to:
archived data, alarm data, or event data.
 Configuration of automatic report generation, including frequency,
destination of the report.
 The reporting subsystem shall not impose limits on the number of reports
that can be configured.
 The system shall support the use of optional third-party applications (i.e.,
Microsoft Excel, Crystal Reports) for generation of reports.

3.7. Report Generation

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

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

4.1. Controller Programming Environment

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

4.1.1. Controller Editor

The system control and I/O development environment shall
consist of an IEC 61131-6 and ANSI/ISA-88 compliant editor.
It shall represent the multi-tasking operating system of the
system controllers with a graphical tree view showing tasks,
programs, phases, and routines.

The logic editor shall support the creation of routines in any

one or more of the following four programming languages:
 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.

Page 31 of 61
  Structured Text – Textual basic like language useful for
developing custom algorithms and string text
manipulation.

The editor shall provide the ability to drag-and-drop to move

instructions, logic, routines, programs, and tasks either within a
single project or between projects to create detailed project
libraries.

The editor shall also have open access to various portions of

projects through:
 Windows® Clipboard – cut/copy/paste code and
information from and to other Windows-based tools.
 Import/Export Tag Definitions – the Comma Separated
Value (CSV) export extracts tags for use by third-party
tools such as Microsoft® Excel®.
 Full Project Import/Export – this ASCII representation
of a controller project shall provide access to create and
manipulate the project using other text editors.
 Partial Import/Export Online or Offline – The system
shall support the import or export of specific, user-
selected portions of logic, into and out of both a
running controller as well as an offline controller
configuration file.

Controller data tags are to be defined just once using the editor
and are then are to available immediately to every piece of the
system.

4.2. Controller Runtime Modifications

Controllers and their development environment must provide the ability to
perform runtime modifications. This includes the creation of new data structures,
tags, tasks, programs, and routines and also the addition of select system I/O
modules, all while the system is fully operational. Additionally, application code
written in Function Block Diagram, Ladder Diagram, Sequential Function Chart
or Structured Text should be capable of being modified, tested and downloaded
while the system continues to operate.

In addition to being able to modify a controller’s contents while running, multiple

users should have simultaneously access to a running controller. Changes made
by one user are to be automatically propagated or uploaded to the other users
project view so that each user has an up-to-date image.

4.3. Controller Restore / Upload

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

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

4.5. Control Strategy Development

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

This execution environment shall support:

 Individual “control objects” comprised of user selected functions. Must
have assignable execution rates of 50, 100, 200, 500, 1000 and 2000
milliseconds. All control objects, regardless of function block content,
shall be able to execute at any of these rates. Note that all function blocks
within a control object shall execute at the same rate.
 Peer-to-peer communications that provide for the direct transfer of process
data between controllers without the use of gateways or servers.
 The controller “firmware” shall be capable of being upgraded on line,
without stopping or upsetting the process being controlled in a redundant
controller system.
 A controller shall be capable of being inserted under power, without
upsetting the process being controlled by other controllers.

4.6. Controller Configuration Languages

Configuration languages shall be offered that are traditionally associated with
both a PLC and DCS programming environment. These shall include the
following four programming languages:

 Function Block Diagram – For continuous process and drive loops

 Sequential Function Chart – For control sequence management and batch
process
 Structured Text – For custom looping and complex mathematical
algorithms
 Ladder Diagram – For state based sequential and motion control

Page 33 of 61
All function types must co-exist with each other in a single controller, have the
ability to interact with each other, and support online editing.

The system also must support:

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

4.6.1. Function Block Diagram

Function Block Diagram (FBD) instructions are required
provide the building blocks needed to perform sophisticated
process and drive control. Control strategies can be created in
a familiar way utilizing flow representations of applications.
Active X faceplates can be utilized for instructions commonly
used with operator interfaces (Enhanced PID, Ramp/Soak, etc.)
and online visualization of FBD process data should be also
supported by the system.

To make it easier to navigate through a FBD routine, the

system shall give the users the capability to divide the routine
into a series of sheets which helps organize function blocks and
makes them easier to visualize and search. This shall not affect
the order in which the function blocks. In general, one sheet
should be used for each device (motor, valve, etc.)

System FBD routines shall automatically determine the

function block execution order.

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.

Page 34 of 61
  It shall be possible to configure multiple states within a
single SFC container. This allows for effective
coordination of sequences which have more than one
mode (e.g., Heating and Cooling) or that contain safe-
state logic (e.g., Aborting or Holding Logic)
 The ability to create master SFC elements which can be
copied and used throughout the configuration just like a
function block.

A Sequential Function Chart (SFC) is similar to a flowchart of

a process. It should be a highly visual language used by the
system to organize the functional specification for control
systems as a series of steps and transitions. A step represents a
major function of the process and contains the actions that
occur at a particular time, phase, or station. A transition is the
true or false condition that tells the SFC when to proceed to the
next step.

Step transitions and step actions shall support the structured

text language for configuration of transition logic as well as
individual actions for steps.

4.6.3. Structured Text

The system should support Structured Text (ST), a textual-
based control function that uses statements to define what to
execute. It is a, high level programming language similar to
Basic or “C” which shall be used to program complex
mathematical operations that would be difficult with other
control functions.

Two types of expressions, Boolean and numeric, can be used in

ST. Boolean expressions compare values or check if
conditions are true or false and numeric expressions calculate
integer or floating-point values.

ST shall provide these benefits to the system:

 If/Then, Case, Do/While, Do/Until and For/Next
constructs
 Non case sensitivity
 Used in actions and transitions of Sequential Function
Charts
 A Fully functional editor

4.6.4. Ladder 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,

Page 35 of 61
 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.
 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.

Page 36 of 61
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:

 applicable to processes with slow and fast dynamics
 used with self-regulating and integrating processes
 immune to noise and process load disturbances
 accessed directly from the controller

4.8.3. PIDE Optimized Auto-Tune

The system shall provide advanced open and closed loop
tuning and analysis by providing PIDE control loop
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

Page 37 of 61
  Split-Range Controller
 Manual Loader
 Totalizer
 Digital Value Monitoring with Alarming
 Analog Value Monitoring with Alarming
 Motor (Start/Stop) with Interlocks
 Motor – Two Speed
 Motor – Forward/Reversing
 Valve (On/Off) with 1 or 2 Feedback Signals
 Valve (On/Off) with Interlocks
 Motorized Valve Control

4.8.5. Computational Functions

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

 Addition/Subtraction
 Ramp generator
 Lead-lag
 Integrator/Accumulator
 Dead time
 High/low select
 Multiplication/Division
 Time averaging
 Signal selection switch
 Exponential polynomial
 Logarithms
 Square root
 Absolute value

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

Page 38 of 61
 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 server-
based batch control with material tracking and electronic batch records
advantages.

The batch solution shall:

 Be open, flexible and use industry standard communication protocols
 Integrated material management and recipe design.
 Create and manage recipes and execute them automatically
 Reduce the hours needed for validating and commissioning
 Configure physical and procedural models
 Integrate with a wide variety of complementary software applications
 Collect detailed electronic batch data about your process to generate
detailed reports
 Integrate and exchange batch and recipe information with corporate
information systems
 Simulate your entire batch process

4.9.1. Basic Batch & 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.

Page 39 of 61
 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:

 Startup Wizards to provide a simple, step-by-step process to programming

drives. Graphs, images and descriptive text are to assist users through
the commissioning process.
 Reusable instructions that to allow users to encapsulate their most
commonly used logic as sets of reusable instructions.
 Preconfigured faceplates objects that can be imported into a user’s HMI
display. They are to allow for operator control, monitoring of data,
parameter adjustments and fault description/corrective.

Page 40 of 61
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, time-
and position-based camming and even multi-axis gearing
 Graphical editor simplifies creation of complex motion profiles.
 Graphical data capture and display allows motion performance to be
monitored.
 Wizard-based axis and drive configuration for easy-to-use programming.

4.12. SCADA and Third Party 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 drag-and-drop
functionality to link the data source and target. At a minimum,
the OPC interface shall support scan rates of 500 ms and 1
second.

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

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

4.12.4. Third Party PLC Communication

The system should support communication with the following
third party PLC’s, including but not limited to:

 TI
 Square D
 GE Series 6
 GE Series 90
 Modicon
 Siemens

4.12.5. Third Party DCS Communication

The system should support communication with third party
DCS’s, including but not limited to:

 Bailey Net/Infi90
 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

Page 42 of 61
  Code read and data read/write access
 Read and write access not allowed
 Source protection for individual routines

4.14. Process and System Simulation

The system shall support various levels of Process Simulation:

 Controller Simulation. A controller simulation tool shall be available

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

System controllers should be capable of being emulated in software to make it

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

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

Page 43 of 61
 products can utilize the data from the Historian - either through ODBC, or rather
OLE DB and OPC HDA.

Production data is to be turned into actionable information through

comprehensive historical data archiving.
Some of the key features are to include:
 Complete time-series data collection
 Easy, flexible, scalable configuration
 Compatibility with any PLC or HMI using OPC standards
 Reliable, 24/7 data collection
 Data storage in an efficient, usable form
 Built-in Thin Client report writer
 Access to all reports with a Web browser
 Dynamic modification of data collection parameters
 Detailed SPC analysis
 Retrieve data directly from Microsoft® Excel
 Sophisticated data collection and triggering options
 Standard and custom data calculators
 Support for UTC time
 Reports on data from external sources

5.2. Plant Data Historian

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

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

Page 44 of 61
 to perform their jobs. These advanced reports are to be available through a
standard Web browser. It should allow end users to self-configure rich Web-based
dashboards, trends and reports without expensive, time-consuming support
resources.

The reporting package shall provide unified access to virtually all

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

5.4. Dynamic Resource Management

Smart Binding capabilities should include configurable requirements and
preferences in unit selection for optimal procedural flow and recipe management.

Optimization options shall address:

• Reduce Recipe Management Effort

• System shall define all recipes as class based, then set specific
requirements through unit attributes
• Improve energy efficiency
• System shall allow definition of algorithms to select optimal unit for
reduced energy usage
• Improve quality and reduce rework
• System shall enable pre-built binding requirements algorithms to
eliminate manual product transfer routing errors
• Improve Process efficiency
• System shall reduce batch cycle time through dynamic routing
decisions
• System shall react dynamically to changing unit conditions after
schedule has been initiated

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,

Page 45 of 61
 based on a schedule, or on system or production events. Reports, when generated,
shall be capable of being distributed automatically through hardcopy reports, via
user interface functions to operators, and via Web services (or to external users),
and via email to authorized recipients.

Standard web-based batch reports should minimally include:

 Batch Reports
o Batch Listing
o Batch Summary
o Batch Detail
 Material Reports
o Material Usage
o Forward Track & Trace
o Backward Track & Trace
 Analysis Reports
o Batch Execution
o Batch Duration Comparison
o Batch Exceptions

5.6. Batch Recipe Management

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

The following batch recipe management options are to be available:

 Software that manages the four primary ISA-88 defined recipe

components. This includes header data, formula data, recipe
procedure, and equipment requirements.

 Software that automates the manual procedures using an interactive,

web-based interface to sequence and document manufacturing
operations. It should provide the consistency of automated controls in
manual operations.

 Software that brings just-in-time material management to batch

execution systems, allowing more effective management of materials
and recipes, and provide plant-level material management and
tracking, and integrates with company-wide inventory management
systems.

5.7. Material Tracking

The system shall provide plant-level material management and tracking that can
tie to corporate material management systems to manage and track the use of

Page 46 of 61
 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 office-
automation systems, as well as with process equipment. The system shall be able
to be connected to most major computer manufacturer's systems via gateways and
servers, and shall provide data access and file access. The system must also be
capable of being bridged to department LANs. The system supplier shall provide
software, to run in existing PCs, to allow them to be placed on the system
Ethernet LAN, or remotely linked via a serial circuit, and to have access to real-
time and historical data. This software shall also permit a PC, under appropriate
systems word access control, to operate like an operator's workstation.

The system shall provide an open MES interface that helps users to better manage
manufacturing processes by integrating plant floor control systems with
enterprise, IT and other applications. The MES interface is to employ open
database access and to act as a bi-directional “data conduit” between the control
system and the business system.

System users can utilize the MES interface for:

 Integrating with production scheduling systems

 Quality Management Systems
 Customer and production orders
 Production tracking systems
 Inventory and asset management systems

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

Page 47 of 61
 automatically what it is running against what was qualified. This IAM feature
shall provide compliance with the FDA regulation that a Quality Manager has to
be able to check if what is running has any impact on quality. It shall also ensure
compliance with O9001-2000 (which demands that a company has to be in
control of all of its assets).

Device diagnostic information should be regularly collected by the system and

status and trouble-shooting information should be constantly displayed to the
Maintenance team.
.
An Asset Calibration feature shall allow for a paperless calibration solution;
managing calibration requirements, specifications, schedules, calibration results
and reporting. An optional capability using Field Device Type (FDT) technology,
shall allow access to instrument parameters, aid in configuring and operating
process devices, and help with diagnostics.

The Asset management software shall:

 Manage installed DTM’s with a DTM Catalog
 Build the DTM Networks from client computers to the physical
devices
 View and edit the configuration for a device (online or offline)
 Upload and download the configuration for a device
 Print the configuration for a device

6. Service and Support

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

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

Page 48 of 61
  Accessing alarm history
 Accessing trend displays
 Accessing and interpreting system diagnostic displays

Operator training sessions will provide all information required

to:
 Operate the system, create and maintain historical files.
 Display historical file information graphs and charts.
 Start up/Shut down the systems when required.
 Complete any other operations that will be required by
an operator.
 Provide necessary training to deal with power outage
and shut down procedures.

6.1.2. Maintenance and Hardware Training

The vendor will provide Maintenance Training for all systems
at site. The vendor shall offer complete and comprehensive
training programs for the system, including the controller,
networks, and OS.

The controller hardware training course content shall include:

 CPU, power supply, communication cards, backplane,
local and remote I/O racks.
 I/O cards
 Communications and Ethernet communication
 Fault tolerant architecture and failsafe architecture.

The Operating System hardware training course content shall

include:
 System Overview
 Client and server architecture, including networking
and redundancy
 The display hierarchy, and the graphical, trending,
alarm, reporting, and batch displays

6.1.3. Engineering Training

The engineering training course content shall include:

 Configuration of the I/O hardware devices

 Configuration of the communication networks
 Configuration of continuous and sequential control
operations
 Design of operating and monitoring strategies
 Introduction to Windows
 Creation, administration and management of OS system
database

Page 49 of 61
  Creation, administration, and management of graphics
displays
 Creation, administration, and management of system
alarming
 Creation, administration, and management of the
historical subsystem
 Creation, administration, and management of the
reporting subsystem
 HMI Scripting

6.2. Technical Support

The vendor shall offer phone and e-mail support and Internet information. The
vendor shall offer 24/7 support for all system hardware and software. This shall
include spare parts, maintenance, and technical support. The vendor shall offer a
published 800 number for telephone support during normal business hours.

The vendor shall offer comprehensive self directed technical support via the
Internet that shall include:
 Contact with technical support via e-mail
 Searchable knowledge base
 Product catalogs and manuals
 Product Frequently Asked Questions
 Software updates
 Application examples
 Application Tips

Available phone support programs should allow system users to choose a service
level appropriate to their needs and the objectives of their maintenance strategy
including:
 Real-time, 8am-5pm local time phone support, comprehensive
electronic support tools and software and flash firmware updates
for system products. 24x7x365 phone support and dial-up
diagnostics optional.
 Direct, 24x7x365 phone access to a designated team of support
specialists with an intimate knowledge of the user’s specific
application and industry. Completely customizable. Dial-up
diagnostics optional.
 Remote technical consulting and application development for
small programming projects — including software conversions and
updates.
 30 days of phone support for select system software.

6.2.1. Onsite Support Services

The following field support engineering services should be
offered to assist maintenance staff with preventive and reactive
tasks. Field support engineers are to be made available on an as

Page 50 of 61
 needed, scheduled, or full-time basis to meet the specific user
needs and system maintenance strategy.

Support services available should include:

 Callout services for repair and troubleshooting labor as
needed for system related issues.
 Extended parts and labor Warranty for repair labor
(including local travel) and replacement parts for
system control equipment and drives for up to five
additional years.
 Drives startup services to commission system drives
and prevent potential startup problems. To Include 1 or
2 year extended warranty.
 Conversion services to convert existing programmable
controllers, drives and motors to new or different
system technologies.
 Preventive maintenance Services to perform regular
maintenance on system related equipment to prevent
potential problems and extend component/system life.
 Embedded engineer as full-time labor to perform
reactive and preventive tasks in continuous support of
the system maintenance department.

7. Hardware Specifications
7.1. Inputs and Outputs
I/O modules shall be available in a wide variety of densities, including 2, 6, 8, 16
and 32 point, and shall interface to static and dynamic analog and discrete inputs
at various voltage levels (both AC and DC). These modules must be able to be
inserted or removed while the system I/O rack is under power and operating,
without any disturbance to the system. Output modules shall be available with
analog, solid state AC, solid state DC, and relay contact type outputs. Modules
shall have a small form factor and feature deterministic I/O update rates,
diagnostics features, local (front of module) or remote terminations, and software
configuration/management support.

 Common mode rejection ratios of 60 dB or greater from DC to 60 Hz and

normal mode rejection ratio of 30 dB or greater at 60 Hz are required.
 Analog input and output modules shall provide pass-through capability to
exchange non-control data, both PROFIBUS and HART, with asset
management applications, utilizing the infrastructure of the system.
 Dynamic analog input (typically vibration) modules shall provide intelligent
local processing of signals and alarms so to minimize data transfer volume
and controller processing requirements.
 Digital output circuits shall be provided with protection for the switching of
inductive loads.

Page 51 of 61
 The following configurable fail-safe options shall be available for each output
module:
o Drive to predetermined analog output or de-energize for a digital output
o Maintain the last good output value for an analog or hold for a digital
output.
 Drive to predetermined analog output or de-energize for a digital output
 Maintain the last good output value for an analog or hold for a digital output.
 The fail-safe actions listed above shall be taken upon a processor halt, or
power supply failure, or a communication failure between the controller and
the I/O module, if so configured.
 It shall be possible to change modules in remote I/O racks while the rack is
powered up without affecting communication to the other modules in the rack.

As a minimum, the following types of modules should be available:

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

Page 52 of 61
7.1.1. Analog Inputs
The system shall be capable of supporting the following types
of analog process input signals:

 4-20 mA dc, 0-20 mA dc, and ±20 mA dc, isolated and

non-isolated inputs
 1-5 V dc, ±10 V dc, and ±1 V dc isolated and non-
isolated inputs
 Type B, E, J, K, L, R, S, T and U thermocouples,
isolated and non-isolated inputs
 Platinum resistance temperature detector (RTD) –
Pt100, Pt500, Pt1000, Ni100, Ni1000, Cu10 per IEC
60751, isolated and non-isolated inputs
 High-speed Pulse input – 100, 125, 250, 500 kHz, 1 &
2 MHz @ 24 V
 Vibration

Temperature linearization and thermocouple cold junction

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

7.1.2. Digital Inputs

The system shall be capable of supporting the following digital
input types, time stamped to 10 ms second accuracy:

 24 Vdc
 125 Vdc
 24-48 Vac/dc
 120 Vac
 230 Vac

7.1.3. Analog Outputs

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

7.1.4. Digital Outputs

Relay or solid-state output contacts that are free of voltage and
ground shall be available. Relay outputs with 5-125 Vdc, 5A
rating shall be available. Latching and non-latching momentary
contact outputs shall be available.

Page 53 of 61
 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 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.
Fail-over to redundant components shall be alarmed, but otherwise transparent to
the user: i.e., no additional application programming shall be needed to handle the
failover.

Rack-based control redundancy shall:

Page 54 of 61
  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 TÜV should be available.

7.6. Controller Power Supplies

Redundant power supplies for system rack-based controllers shall be provided for
high availability of chassis power. The redundant power supplies should be
capable of being utilized in remote rack-based chassis also, ensuring that remote
I/O also always has the power needed.

The power supply shall be separate from the chassis slots so as not to consume
any I/O slots. Power supplies shall be available in 120/240 VAC and 24 VDC
models. As an option, a UPS capable of providing a minimum of 20 minutes of
power shall be included with the system.

The controllers shall not require the use of cooling fans.

7.7. Controller Memory Backup

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

Page 55 of 61
 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 cost-
effective means to integrate a simple machine or application into the
system.
 Rail mounted controllers that provide a small, highly adaptable
distributed control option. These should include inexpensive, multi-loop
controllers that offer two flexible communications slots that can be
configured to support the various system communication options.

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

7.11. Warranty Information

Warranty programs should include all replacement parts, local repair labor and
local travel for up to five additional years on select system control equipment and
drives. If a problem occurs, a dispatch center should immediately send an
experienced, factory-trained technician to the site to perform all system repairs
and restore operation

Features should include:

 Reduce liability for equipment malfunction or failure
 Reduce the duration of unscheduled downtime events
 Reduce overall maintenance expenses

Page 56 of 61
  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:
 Temperature range: 0°C to 60°C.

Page 57 of 61
  Relative humidity: 5% to 95% RH.

9.2. Outdoor Installations

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

9.3. Storage Conditions

It shall be possible to store the equipment before installation for up to 6 months in
an air-conditioned building under the following conditions:
 The equipment shall be packed in a moisture proof container
 Storage temperature: -40°C to 70°C.
 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.

Page 58 of 61
 Availability: The probability that a system will be able to perform its
designated function when required.
 Bus: A path for electrical signals allowing the exchange of data
between various components of a computer or system.
 Central Processing Unit (CPU): The central part of the controller in
which the operator program is stored and processed, and the
operating system and communication interfaces are contained.
 CFC: Continuous Function Chart is a high-level graphical language
using function blocks for configuring continuous control
systems.
 Chart: The document in which the automation functions can be
created using the CFC tool or the SFC tool.
 Communications Link: The hardware and software that performs 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.

Page 59 of 61
  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
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.

Page 60 of 61
 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.

Page 61 of 61