PAC8000 Controllers

Hybrid, Process, Logic & EBIM

Instruction Manual

GE Intelligent Platforms, Inc.

2500 Austin Drive
Charlottesville, VA 22911
www.ge-ip.com
Contents INM8521 February 2010

Related documents ............................................................................................................................. iii

IMPORTANT NOTE............................................................................................................................ iii
OVERVIEW .............................................................................................................................................1
Physical Model.....................................................................................................................................1
Logical model.......................................................................................................................................2
Control .................................................................................................................................................3
Integration ............................................................................................................................................3
Peer to peer .........................................................................................................................................4
Open systems ......................................................................................................................................4
Fully scalable system...........................................................................................................................4
Redundancy.........................................................................................................................................4
Hazardous area considerations ...........................................................................................................4
REDUNDANCY .......................................................................................................................................6
Network redundancy ............................................................................................................................6
Controller redundancy..........................................................................................................................7
Power supply redundancy....................................................................................................................7
Workstation redundancy ......................................................................................................................7
CONTROLLER & EBIM HARDWARE....................................................................................................8
Configuration options ...........................................................................................................................8
Redundancy.........................................................................................................................................9
Embedded software packages...........................................................................................................11
Controller Synchronisation.................................................................................................................11
The Execution cycle...........................................................................................................................12
Peer to peer operation .......................................................................................................................12
Failsafe, Health and Recovery...........................................................................................................13
Network ports.....................................................................................................................................15
Serial interfaces .................................................................................................................................15
Installation and Configuration ............................................................................................................19
Maintenance ......................................................................................................................................25
I/O MODULES .......................................................................................................................................27
General purpose applications ............................................................................................................27
Hazardous area applications .............................................................................................................27
HART support ....................................................................................................................................29
Failsafe modes...................................................................................................................................29
NAMUR compliance...........................................................................................................................29
Module installation .............................................................................................................................30
Module configuration..........................................................................................................................30
FIELDBUS SUPPORT ..........................................................................................................................31
Foundation Fieldbus ..........................................................................................................................31
HART – Universal commands............................................................................................................31
Modbus ..............................................................................................................................................31
H1 Linking device...............................................................................................................................31
HART maintenance............................................................................................................................32
COMMUNICATIONS NETWORK .........................................................................................................33
Cabling...............................................................................................................................................33
Terminations/connectors....................................................................................................................33
WORKSTATION....................................................................................................................................34
Recommended specification..............................................................................................................34
IP addressing .....................................................................................................................................34
PAC8000 WORKBENCH ......................................................................................................................35
PAC8000 Process Control - Overview...............................................................................................35
PAC8000 Logic - Overview................................................................................................................36
POWER SUPPLIES ..............................................................................................................................38
PAC8000 Controller ...........................................................................................................................38
I/O modules........................................................................................................................................38
AC/DC and DC/DC supplies ..............................................................................................................39
APPENDIX A - ATEX INFORMATION..................................................................................................40

ii
Related documents
The following documents contain additional information relating to the specification and
installation of the PAC8000 equipment.

Component Data Sheets

Instruction Manuals
INM8100 Installing I/O modules – (General purpose and 2/2 applications)
INM8200 Installing I/O modules – (2/1 applications)
INM8900 Power Supplies – Configuration and Installation

IMPORTANT NOTE
Use of equipment in hazardous areas
In common with all other electrical apparatus installed in hazardous areas, this apparatus must
only be installed, operated and maintained by competent personnel. Such personnel shall have
undergone training, which included instruction on the various types of protection and installation
practices, the relevant rules and regulations, and on the general principles of area classification.
Appropriate refresher training shall be given on a regular basis. [See clause 4.2 of EN 60079-17].
This instruction manual supplements the requirements of nationally accepted codes of practice,
for example, IEC/EN 60079-14 in Europe and the National Electrical Code, combined with
ANSI/ISA-RP 12.6 in the USA. All installations should comply with the relevant sections of
these codes.
In addition, particular industries or end users may have specific requirements relating to the safety
of their installations, and these requirements should also be met.

For ATEX information relating to this equipment see Appendix A.

iii
Overview
PAC8000 has a comprehensive family of open system components to serve the process
automation market. Users can connect many of these open components to provide a
comprehensive control solution, or they can use a single component and connect it to the other
products already in the plant.
This offers a new approach to process control; providing a fully integrated solution for continuous
control strategy development and process visualisation with commercially available open systems
components. It is a full life cycle approach that provides a process engineer with the tools to
design, implement, document and maintain a process control system using advanced control
strategies typically associated with closed, proprietary distributed control systems (DCS).
It consists of a number of open system components:
• an Open Control Platform consisting of a rugged controller with embedded control software
• a Workbench that is the process engineer’s configuration and commissioning workstation
• a rugged I/O platform that is suitable for direct mounting in process plants.
This manual is principally concerned with the first of these elements, the Open Control Platform
(OCP) while the other control components are discussed in other publications and software help
files.

Physical Model
At a physical level, some of the individual elements can be understood better by reference to
Figure 1. This diagram highlights some of the key elements and how they relate to each other.

OPC Client OPC N on-FTE

workstation W orkbench server workstation HMI Control
Room

Engineering HMI
Office
Bridge
Switch Switch

Optical fibre IntraLAN link

links

Fibre optic
converters
Switch Switch Remote
plant
Optical fibre object
links

Process
plant
Redundant OCP
OCP controller OCP
controller controller

Figure 1 - A typical system model

The Engineering Office

The engineering office contains a number of key facilities for the engineering staff to develop
control system strategies. The primary engineering resource is the Workbench, which is used to
define the control system strategies, document those strategies and create the executable control
software code that will subsequently be embedded into the remote OCP controllers.
In this engineering office environment, one section of the LAN serves the office functions by
linking the workstations, the printer and other peripherals. The independent plant network is fully
redundant with completely separate network interface cards in the Workbench, Operator Station

1
 and any computer interfacing to the plant network through an OPC server. These operator stations
are linked to a pair of Ethernet switches that consolidate the traffic onto the main cross-site links.
In the diagram, these redundant networks are shown as fibre optic cable to imply probable
distances of over 100 meters. For greater distances, i.e. greater than 400 meters, repeaters would
be necessary somewhere along the fibre optic path.

The Control Room

HMI consoles and screens are located here to view, monitor and adjust when necessary the
essential parameters of the process. These consoles are redundant to assure that the operators can
always access the information they need.

The Process Plant

The OCP controllers mounted in field enclosures around the plant are in continuous control of the
process(es). Each controller is capable of running function block and PLC type programs
simultaneously via embedded control software. These programs are defined in the Engineering
Office and downloaded across the network to the allocated controller.
The controller is accompanied in its field enclosure by a set of I/O modules. These are available
in a comprehensive range – AI, DI, AO, DO, HART, Foundation Fieldbus and
Frequency/Quadrature – to handle typical user applications.
In addition to general purpose applications, the I/O modules have been designed to operate in
harsh environments under arduous conditions of temperature, vibration and shock. They are also
designed to operate safely in potentially explosive atmospheres, such as those found on
petrochemical refineries, pharmaceutical plants, offshore drilling platforms and the like.
Independent LANs are routed in from different switches in different locations to prevent local
damage from halting communications. Additional redundancy at a node is available by the use of
a second controller. This controller, like its partner, is also served by redundant LANs. One
controller is designated master and the other is maintained on active standby.

Logical model
To avoid complication, not all of the system is portrayed in Figure 1. A broader impression of
system components can be gained from Figure 2

Figure 2 - Logical diagram of a process control system

The network cloud represents whatever hardware and software is necessary to interconnect the
elements of the system that surround it. On the upper side of the cloud are elements that define
and manage the process. On the lower side is the field equipment used to implement the process.

2
Control
The PAC8000 Controller has the ability to accept control software applications and use them to
manage one or more processes in the field. The application is developed in the PAC8000
Workbench, then sent across the network to the controller located out in the field. The type of
control application can be chosen to suit the application.
Distributed Control Systems (DCS) are typically used to control large scale, process operations.
The DCS is a tightly integrated solution and easy to use but it is not easily scaled to address
varied system applications, nor is it open to other third party devices. The Process Controller
offers the benefits of an integrated “DCS-like” solution that is also easy to maintain since it is
created from components that conform to open standards.
Programmable controllers (PLCs) are viewed as scalable but not so easy to configure. They are
targeted normally at smaller, higher speed, discrete manufacturing applications. The PAC8000
Logic Controller provides the scalability of the PLC but its Logic Workbench provides a suite of
tools to dramatically simply configuration and make the task more graphical and intuitive.
The PAC8000 Hybrid Controller provides the benefits of both these techniques; a process
control solution that has the characteristics of DCS, and also a PLC, via an IEC 1131-1
compatible programming language for discrete control applications. This enables the user to tailor
a unique solution for their application. If you need to control a process plant and also require
sequential discrete control, the PAC8000 Hybrid Controller can be configured to address both
requirements simultaneously with a single control solution.
In addition to the Controller solutions, an Ethernet Bus Interface Module (EBIM) is also
available in the same mechanical/electrical package. This unit is a Modbus Interface, with
Ethernet connectivity, for the 8000 I/O field-located products shown in Figure 2 above. It acts as
a Modbus slave interface between a Modbus master and the individual I/O modules. The master
can be an adjacent Controller, i.e the next node on the LAN, or one located more remotely on the
plant. For details of the Modbus command library see page 16 and for its memory address
mapping see page 24. The software for configuring an EBIM is provided with all of the
Workbench packages. The EBIM also supports the same level of redundancy as the other
controllers.

Integration
HMI
The PAC8000 Workbench contains a built-in, system configuration export facility. This enables
the user to extract the system configuration database, which can be used to set up the control
system’s HMI.
The user first creates the system within the appropriate Workbench package using the tools
provided there. On completion, the configuration data is exported to a standard .CSV (comma
separated value) data file that contains a representation of the system. This file can then be used to
configure the user’s HMI to provide an on-screen model of the system.

FOUNDATION™ Fieldbus H1
The PAC8000 System can support H1 fieldbus devices through Ethernet gateways, known as
linking devices. Within a single package, these linking devices provide a hub for up to four
networks of H1 field components and a gateway to the Ethernet LAN.

Dual LAN - Ethernet

Linking
device

H1 fieldbus

Figure 3 - H1 Linking Device on Ethernet

3
 The H1 devices have publisher/subscriber rights so that data can be passed from a device on
linking device ‘x’, via the LAN, to another H1 device on linking device ‘y’, say. PAC8000 uses
the same LAN protocol, so it has access to these H1 devices for use within its control strategies.

Peer to peer
In addition to the application data being made available to the OPC server, and the clients
attached to it, individual controllers can obtain data from each other via a peer-to-peer facility.
This enables individual controllers to share data that is important to the overall control of the
process. The data sharing process is discussed in a later section.

Open systems
The benefits of using an open controller based solution, as opposed to traditional distributed
control systems, are numerous. By taking advantage of Windows NT-based object-based
technology, graphical user interfaces, and easy-to-learn software solutions, the PAC8000 System
reduces process control system life cycle expenditure by around 30-40%.

Modbus TCP
Modbus protocol can be used over Ethernet by embedding a Modbus frame in a TCP frame to
deliver point-to-point explicit messaging. This uses the same register method as the familiar
remote terminal unit (RTU) protocol.

OPC
OLE for Process Control (OPC) defines the standard interface between an I/O system and other
HMI products. This interface connects the I/O to any HMI. The OPC Server conforms with the
OPC standard, assuring a reliable interface to any HMI.

Fully scalable system

The PAC8000 System can be scaled to meet the application requirements; addressing applications
that range from ten points to thousands of points. The system software solution can also be
optimised to suit the application, enabling the user to choose only the software functionality
required today yet provide the flexibility to add more functionality as the need grows. The
PAC8000 System offers all this versatility in a single integrated database, providing a cost-
effective solution that is also easy to use.

Redundancy
Redundancy is available at many levels throughout the system. All of the key systems and
functions can be given a level of redundancy that the user thinks is necessary. While it has been
easy in the past to provide redundancy on power supplies, cabling and workstations, etc.
redundancy on networks and controllers has proved more complex.
Network redundancy has become more available with the development of Fault Tolerant
Ethernet. The PAC8000 System has adopted this technology, which enables a rapid changeover
between networks if faults are detected on the network currently in use.
Controller redundancy is even more difficult to achieve because of the changeover period during
which the standby assumes the role of master. Unless the standby is kept in step with the master it
cannot take over the role of master without a period of acclimatisation. This difficulty has been
overcome with the controller, which can maintain close synchronism with a second controller like
itself. In the event of a controller failure the standby can immediately take over the role of master.
This is because it is populated with up-to-date information and the same control strategy as the
previous master. The standby can therefore be viewed as identical to the master and suitable as an
immediate replacement.

Hazardous area considerations

Your application may require control of processes in areas where potentially explosive
atmosphere can exist. Areas such as these are classified according too the frequency of occurrence
of explosive atmospheres which obviously relates to the level of risk of an explosion.
8000 series I/O hardware is used for hazardous applications. GE are world leaders in the field of
hazardous area equipment and literature on hazardous area classification, as well as full details of
their 8000 series Process I/O™ equipment, can be found on the web site www.ge-ip.com.

4
 For those users interested in hazardous area application, two important aspects have to be taken
into consideration when dealing with them:
• where the field I/O equipment is mounted and
• where the field wiring goes.

Mounting
All 8000 I/O equipment can be mounted in a Class I, Division 2 or a Zone 2 hazardous location
with no additional protection considerations other than weather conditions and electrical safety.
This means that the equipment does not need to be housed in flameproof enclosures, inert-gas-
purged cabinets or the like.
8000 I/O equipment can be mounted in conventional field enclosures with, typically, an IP55
(NEMA 12) level of protection. Details on the installation of this equipment and the
recommended codes of practice are available on request.

Field Wiring
The field wiring is the wiring from the I/O equipment to the field devices. The field devices may
be mounted in the same type of hazardous area as the I/O equipment, or they may be mounted in a
safer one or a more hazardous one. This clearly will have an impact on the type of area that the
field wiring enters.
The 8000 I/O equipment can be chosen to suit the field wiring conditions and can accommodate
field wiring that goes into hazardous locations classified as:
• Class I, Division 1 (N. American classification)
• Zone 1 (European classification)
• Zone 0 (European classification)

5
Redundancy
Redundancy is the concept whereby one part of a system takes over from another in the event of
the failure of the first. This allows the user to provide backups for essential parts of the system
and significantly reduce its downtime. The PAC8000 System embodies a number of ways to
provide redundancy and these are discussed below.

Network redundancy
Network redundancy is about providing a secondary path for the data in the event of a failure in
the current path. A machine running the application, has to be able to recognise a network failure
and switch the data transmission to an alternative network path. Previously, this had to be
achieved at the application level or the hardware level.
Application-level redundancy is not very satisfactory because it means that the application has to
maintain two TCP stacks, and event timing proves to be something of a headache. Only those
applications that have been designed or written to support redundancy can be used.
On the other hand, hardware-level redundancy is, not suprisingly, very hardware dependent and
changing a network card type can mean changing the setup to accommodate the new hardware.
Neither of the above methods provides a satisfactory solution to the implementation of network
redundancy. The PAC8000 System solves the problem with a “middleware” implementation. This
employs the LAN Redundancy Entity (LRE) and its associated Network Status Table.

W in XP/ W in 2000 Embedded

Application Application

TCP/ IP TCP/ IP
Stack Stack

N DIS
Hooks
LRE

LRE

HAL N etwork HAL N etwork

Status Status
Table Table
MAC A MAC B MAC A MAC B

Figure 4 - LAN redundancy model

This method can be used for any general purpose application that requires network redundancy
when running under Windows® XP or Windows® 2000. In such an application, the LRE is
handled by Microsoft’s “Network Driver Interface Specification” (NDIS), which integrates the
LRE without any further intervention by the user. The driver is installed with the application and
automatically provides an interface that is application and protocol independent.
The technique can also be used as an embedded solution within proprietary equipment, such as
the PAC8000 Controller. Here the LRE is accessed using specific software “hooks” to achieve the
same result.

Non-redundant network components

Any item connected to only one of the networks, i.e. non-redundant, will still have access to the
second network as long as an intra-LAN link is made between the switches serving the two
LANs. This will require the use of a “crossover” cable, not a standard “straight wired” patch
cable.

6
 Only one link is required and it can be made between any two switches that serve the two LANs.
The link shown in the diagram is between a pair of switches at the control room end.

Work Work Work Work

station station station station
#1 #2 #1 #2
Server Server Server Server
#1 #2 #1 #2

Switch #1 Switch #2

Intra-LAN link
(using crossover cable)

LAN A LAN B

Figure 5 - Intra-LAN link between switches

Controller redundancy
An extra controller can be added to a node to provide a “standby”. This is maintained in step with
the master while it remains in “standby” mode.
If system checks fail to return a satisfactory result, control of the node is transferred to the
standby. By keeping master and standby in constant step with each other the transfer of control
from master to standby is made in a rapid and “bumpless” fashion. The process is not affected by
this transfer.

Power supply redundancy

Power supplies are clearly essential to the continuous operation of the field equipment. An N+1
scheme is available for the remotely located system and field power supplies. This scheme uses
power supplies that are paralleled and which are capable of load sharing. The incorporation of one
additional power supply per supply line, in excess of system requirements, i.e. N+1, ensures that
should one power supply fail, there is sufficient capacity still available to maintain the system in
full operation.
This technique is very effective but it does place the emphasis on the identification of a failed
supply and its early replacement to maintain a redundant status.
The PAC8000 System has been designed to monitor individual power supplies and react with a
message to the Operator Station on the identification of a power supply failure. This information
can be signalled to the Control Room so that maintenance personnel can take action to restore full
redundant operation.

Workstation redundancy
Redundancy can be applied to workstations as well as the inter-linking network hardware. Two
situations need to be recognised when discussing redundant workstations.
(a) Totally independent workstations where failure of one means that the other is used
(b) One workstation with two process network connections
Technically, the first situation is trivial and can be implemented by duplicating all the hardware
(and software) and connecting the second workstation onto the network. The second situation is
what is being considered here.
The workstation requires two Network Interface Cards (NICs) for the process LAN and possibly a
third if it will be connected to the Office LAN. The Win 2000/Win XP option illustrated in Figure
4 is implemented in the workstation so that the two LAN connections are recognised as only one
IP address by the top-level system application.

7
Controller & EBIM hardware
The PAC8000 controller is the hardware platform located out in the field. This platform carries
the control software application that manages the process(es). The EBIM looks almost identical to
these controllers and, with the exception of the process control software, behaves much like them.
In this section, unless otherwise stated, the controllers and the EBIM can be treated as the same.
The controller, or EBIM, is mounted on a carrier in a field enclosure to protect it from the weather
as well as unauthorised tampering. It requires DC power and one or more network communication
links for it to operate.
The controller carrier connects to the I/O module carrier so that I/O data and instructions can be
passed along a shared communication bus (“Railbus”) between them. The controller and its I/O
modules together form a “node”.

Controller carrier I/ O modules

To a maximum of
64 I/ O module slots

“ Railbus” signals

Figure 6 – Railbus link between controllers and I/O modules

Configuration options
Depending on the level of redundancy required, a node can be configured in the following ways:

Single controller with single LAN

This represents the simplest configuration where a single controller is connected to the rest of the
system via a single LAN connection.
Single controller I/ O modules

Single LAN

Figure 7 - Single controller with single LAN

8
 Single controller with dual LAN
The next alternative is when redundancy is added to the LAN but not to the controller. Dual LAN
connections provide the first level of redundancy.
Single controller I/ O modules

Dual LAN

Figure 8 - Single controller with dual LANs

Dual controllers with dual LAN

The highest level of redundancy is when two controllers are used, each having redundant LAN
connections.
Dual controllers I/ O modules

Dual LAN s

Figure 9 - Dual controllers with dual LANs

Redundancy
As previously mentioned, the system can support various levels of redundancy. At the controller
level, this is achieved by mounting an additional controller in the node to mirror the operation of
the master. This “standby” controller is maintained in step with the master via a connecting link
on the mounting carrier.

Adding a second controller

The carrier has space for two controllers – ‘A’ and ‘B’. The first one, ‘A’, is located on the left;
the second takes the right hand ‘B’ position.
A second controller can be plugged into the carrier even when system power is present on the
carrier. The controller receives its main d.c. power supply via a connector on its top face. The
RJ45 LAN sockets are located on the opposite lower face.

Automatic changeover
Each controller carries out diagnostic checks on itself in order to maintain an awareness of its
current status. In addition to hardware checks, the controller keeps a careful check on the
checksums of the software and firmware in its memory. It also checks that all allotted tasks have
had their chance to run.
If any of the diagnostic checks, carried out by the master on itself, fail to return a satisfactory
result, control of the node is immediately transferred to the standby. By keeping master and

9
 standby in constant step with each other the transfer of control from master to standby is made in
a rapid and “bumpless” fashion.
An alarm is sent to the Control Room that the changeover has occurred. Diagnostic information
can then be checked to identify the cause of the fault. In the event of a software failure, the
“repair” is carried out remotely; if it is a hardware problem, a replacement controller must be
fitted.

Manual changeover
Each controller is provided with a manual changeover button located on the carrier. This is used
to change the state of the controller.

POW ER FAIL IN PUTS

2/ 2 NC 2/ 1
–
+ 1 2 3 4 5 6 7 8 9

PFM

Change state A B
buttons
CHANGE CHANGE
A STATE STATE B
SERIAL SERIAL
PORT PORT
1 1

Figure 10 - Controller “change state” button locations

The effect of pressing the controller’s change state button depends upon the controller’s current
state and whether it has a second, i.e. redundant, controller beside it. Table 1 shows the result of
pressing one of the buttons when its related controller is one of the states shown in the first
column.

Table 1 - Effect of "change state" button

State before State of other Result
button press controller
Master Standby Master confirms health of Standby – if OK, Standby
takes over as Master – if not OK, button press is
ignored
Standby Master Standby controller goes to Offline mode
Offline Master Offline controller goes through a Cold Start and
synchronization with Master before adopting Standby
mode
Master Not present Master ignores button press unless it is already in
failsafe mode. If in failsafe it goes to Offline mode
Offline Not present Offline controller goes through a Cold Start before
adopting Master mode

Hot swapping
Controllers can be added and removed from their carrier positions while they are still under
power.
IMPORTANT NOTE: In a Division 2 or Zone 2 hazardous area, it is important that the
connection from the LAN is isolated before the RJ45 connectors are removed or inserted.
When the replacement is fitted, configuration of the unit commences automatically. Configuration
data is transferred from the operational master to the new controller. When the new one has been
populated with the latest information and all of its system diagnostics checked out, it is elevated
to the operational status of Standby.

On-line software changes

A controller operating remotely in the field can have its firmware or its configuration replaced via
the network. Firmware changes, typically a version update of the control software, can only be

10
 made in an offline mode. Configuration changes can be made and downloaded to the controller
when the controller is on-line.
A firmware change can be carried out on an controller only when it is in Offline mode. If the
system has a redundant controller then the Standby is taken Offline and its firmware updated.
When the download is complete, and all the checksums validated, the Standby is taken through
the Cold Start process and then synchronised with the Master before being brought up to Standby
mode. If there is no controller redundancy, the control application must be stopped before the
firmware change can take place.
A configuration can be changed while the controller is on-line and in full control of the process.
The configuration is downloaded to a separate area of memory to avoid conflict with the current
configuration. When the download is complete, and checksums validated, the new configuration
can be used to take-over control.

Embedded software packages

With the exception of the EBIM, the PAC8000 Controllers are supplied with embedded software
applications. The user can choose from the following Controllers to suit their requirements.
• PAC8000 Logic Controller
• PAC8000 Process Controller
• PAC8000 Hybrid Controller

PAC8000 Logic Controller

This Controller offers the user an effective alternative to the PLC and a range of solutions for
smaller systems. This powerful Soft PLC package enables the deployment of multiple PLC
configurations and distributed systems in a networked environment.
It provides a complete toolkit for creating IEC 61131-3 compatible programs. The Discrete
Control Workbench supports the six standard IEC 61131-3 automation languages - Sequential
Function Chart (SFC), Function Block Diagram (FBD), Ladder Diagram (LD), Structured Text
(ST), Instruction List (IL) plus Flow Chart - and is used to develop, download, simulate, debug,
monitor, and edit application programs.

PAC8000 Process Controller

The PAC8000 Process Controller employs a process control engineering and management
software solution with full, distributed control system functionality. The system is a fully
integrated advanced process control and instrument engineering system offering configuration
tools, modelling, simulation, troubleshooting utilities, project drawing management and self-
documentation.
PAC8000 Process Control is open and easy-to-use with a robust system providing the flexibility
to configure control systems ranging from a few loops to thousands of points. The user can also
scale their design allowing cost effective system expansion. In addition, the system’s extensive
use of industry standards simplifies integration with other applications.

PAC8000 Hybrid Controller

The PAC8000 Hybrid Controller combines the benefits of both the Logic and the Process
Controllers in one. The one Controller can take the place of DCS and a PLC hardware and
software platforms to run both discrete control and process control programs simultaneously.

Controller Synchronisation
A pair of PAC8000 Controllers will synchronise with each other so that the one designated as
Standby can take control as Master if necessary. This ensures a bumpless changeover should the
need arise.
The process uses “lockstep” to ensure that the Standby controller is at the same stage of the
process as the Master. Although some communications are naturally asynchronous and can cause
the two to get fractionally out of step, the “leading” controller will pause momentarily to ensure
that synchronism is restored.
Each controller constantly checks its own health and signals this to the other via a local link. If a
health check should fail this is registered as a synchronization fault and an alarm is raised. If it
occurs to the Master then, as long as the Standby is healthy, control is passed to the Standby.

11
 In any startup/restart situation, an controller will carry out its health checks, obtain the
configuration and then assume control as the Master, or it will attempt to synchronise itself with
the Master.
Synchronisation does not apply to the EBIM product.

Real Time Clock

A real time clock, containing the time and date, is maintained to an accuracy of 10 milliseconds
within each controller.
The controller with the lowest node number is used as the time reference for all other controllers
and clients on the plant network. Every 50 seconds approximately, a signal is broadcast by this
controller to resynchronise the clocks.
If that controller is removed, the next (configured) controller with the lowest node number will
take over the role automatically.
Note: Although the clock is battery backed, it is not intended to maintain itself for long periods. It
is required to record the duration of any “brownouts” and will survive as long as the working
RAM holding the process variables. After that data has decayed the clock is unnecessary because
the controller will need to carry out a restart.

The Execution cycle

In order to operate in a consistent and deterministic manner, the controller performs most of its
processing in an “execution cycle”. This is essentially of the form:
• Synchronise with the other processor (if applicable)
• Read all inputs
• Perform control package instructions
• Write all outputs
• Repeat
Each of these steps in the cycle has numerous other sub-steps, such as scanning the I/O modules,
writing data received from HMIs and remote controllers, etc. but knowledge of these details is not
necessary in order to operate the system.
The execution cycle does not apply to the EBIM product.

Peer to peer operation

As mentioned earlier, controllers have the ability to obtain information from other parts of the
network on a producer/consumer basis. One of the key features of a controller is its ability to use
information gathered by another controller from its field devices.
For example, node A, B and C may require data from node D in order to be able to execute their
strategies. For example, node C requires the data from, say, memory addresses “10” and “29” at
node D.

A B C D

A requires: B requires: C requires:

D-10 D-12 D-10

D-22 D-22 D-29
D-23 D-29
D-37

Figure 11 - Consumer requirements of controllers

This information can be made available to node A, B and C by node D broadcasting selected data
items.

12
 This does not apply to the EBIM product.

10,12,22,23,29,37

10,29

A B C D

A requires: B requires: C requires: D broadcasts a

package containing
D-10 D-12 D-10 the data values in:
D-22 D-22 D-29
D-23 D-29 D-10 D-12
D-37 D-22 D-23
D-29 D-37

Figure 12 - Obtaining data from a remote controller

Each node selects the information it requires from the broadcast and incorporates it with the data
it has gathered from its own I/O devices.
When defining the process in the control software, a node can request information from a field
device by its tag name or number. This is encoded automatically into the software and the
controller will take over the responsibility for distributing the information to the nodes that
require the information.

Modbus TCP Slaves

The previously mentioned “linking devices” can also be used as gateways between the Ethernet
LAN and existing Modbus controlled equipment. The linking devices have an EIA-232 port that
enables them to act as a Modbus master to attached Modbus slave equipment.

Failsafe, Health and Recovery

It is important to understand the way the controller deals with hard and software failures and how
it affects the rest of the node.

Controller failure and failsafe modes

Hard failures
A hard failure is one which would cause a controller to halt. Such a fault would cause the
controller to drop its “health” flag, close the LAN ports and set its state to “Failed”. If it was one
of a redundant pair, the dropping of the health flag would trigger the Standby controller to take
over.
Manual intervention is required for such a failure in order to do a restart.

Soft failures
A soft failure would not cause a controller to shutdown but it could cause a failover, unless the
Standby is experiencing the same or a greater fault. An example of such a fault is a LAN
communication failure.
Every execution cycle, redundant controllers exchange information on their health. The master
then makes a decision on which of them is healthier. If it decides that the Standby is healthier,
then it will drop its health flag and force a failover.
When the failover is complete, the new Standby will raise its health flag again in case the new
Master suffers a complete failure.

Failsafe
Failsafe is a mode that the controller can adopt if communications are lost for a user defined
length of time. If a healthy Standby is not available to take over control, the I/O modules will be
placed into a failsafe mode also. This means that they adopt predefined states and will become
Read-only, i.e. they will not accept any Write commands.

13
 If all LAN communications to a redundant Master controller fail, it is still regarded as a soft
failure but the controller will adopt a failsafe mode and failover to the Standby. If LAN
communications are re-established the controller can recover itself and adopt an effective Standby
mode. The serial ports of the controller can also force the controller into failsafe mode if
communications timeouts are exceeded.

Node Health
A controller maintains an array of 'node health' flags. There are 256 input states for serial port
COM1 and another 256 for COM2 (since these can have separate networks of remote devices).
Where both links are used to address the same nodes then COM1 contains the node health flags.
Note that another set of 256 node health flags exists for Modbus Master on Ethernet.
The controller sets the node as “healthy” when all read and write commands have been completed
successfully since the last recovery. The controller sets the node as “not healthy” when one or
more read or write commands fail after retries. Thus the health flag is a 'quality' flag, to be
applied to all data retrieved from that node.
The node health flags are maintained such that the Master and Standby contain identical
information.

Diagnostic commands
Diagnostic commands are used to confirm the presence and integrity of one or more nodes on a
link that is 'quiet'. For example, this could be the link connected to the standby, or it could be the
'reserve' link - in cases where both links are used.
All commands (read or write) act as diagnostic commands. If no command has been sent to a
node for the timeout period then a special diagnostic command is sent. The timeout period is
configured in the port parameters (this is the field used for Comms Lost Timeout on slave
protocols). Thus diagnostic commands could also be sent to a node that has a scan rate slower
than the port timeout parameter.
The controller constructs the diagnostic command. Note this is not the Modbus diagnostic
(function 8) command.
It chooses a read command based upon the first one available of the following:
• the first configured input register
• the first configured holding register
• the first input state
• the first coil.
If no read commands are configured then a read of the first register or coil configured for writing
is used.
A diagnostic command is unsuccessful if it receives no response or an exception response. The
latter is included as a failure because the command is derived from a command that is expected to
work.

Diagnostic flags
In addition to the node health flags the controller maintains a set of flags that indicate the current
'diagnostic health' of each node on each link. The node health flag is set when all read's and
writes are successful to a node. The diagnostic status is deemed healthy on its first success. On
the failure of a diagnostic check, the node health is cleared down.

Error Action
The following action is taken should any Modbus command fail, irrespective of whether it is a
write, read or a diagnostic.
If the current diagnostic state for this processor and link is “failed” then no retry is performed. If
a link is deemed “failed” then it is not used for reads or writes, only diagnostic commands are
sent. A single success is required in order to set the diagnostic health flag for that node, on that
link and processor.
If the current diagnostic state for the processor and link is healthy then two more tries are
performed (making 3 in all). The command that failed is resent until either it works or it fails 3
times. If it works then the command and the diagnostic message is rescheduled according to the

14
 respective scan rates. If all writes and reads are now successful then the node health is set on both
processors.
If the command fails 3 times in a row then this node is deemed “failed” on this link. The node
health is cleared down (such that all writes and reads must be successful to set it again) and the
diagnostic fault flag is set.

Warm and cold restarts

Apart from initial powering up, there may be occasions when a controller has to restart after a
temporary loss of power. The restart sequence will depend upon the duration of the outage.
Often, a power outage is of a temporary nature – a “brownout” – and power fail signalling from
the system supplies provides sufficient notice to enable the variable to be written to battery-
backed RAM before the voltage drops below a critical point.
The battery-backed RAM will hold the current system and process variables for a short period,
something of the order of 5 – 10 minutes. There is little point in maintaining the variables for
longer than this, as the process will have progressed beyond a point where the variables will be
any longer relevant.
If the variables are still available, the controller will perform a “warm” restart. That is, after basic
initialisation, the controller will recover the system variables from the battery-backed RAM and
confirm that nothing in the system has changed. It can then recover the process variables, restore
them and resume operation with no further intervention.
The other key parameter that is stored to battery-backed RAM is the real time clock. On recovery,
the controller checks the clock to determine the length of the outage. The user can predefine a
maximum timeout beyond which the controller should call a halt and not resume its control
program. This will be chosen to suit the type of process being controlled.
If the variables are no longer available from battery-backed RAM, the controller will restart in its
usual manner but, after system checks, it will place the I/O modules into failsafe until further user
intervention.

Network ports
Each controller is equipped with two RJ45 (8-pin) LAN connections to provide redundancy on
the Fault Tolerant Ethernet (FTE).
The LAN ports support four basic types of interface. These are largely transparent to the user.

• HMI Modbus slave The HMI can read data from the controller or write data
to it. See the Serial Port Modbus information that follows
for details of the Modbus commands supported.
• Engineering interface These interfaces handle the downloading of configuration
data for the controller and the I/O modules. The
• Technician interface Technician interface enables a single controller to be
targeted to permit firmware updates.
• Peer to peer This handles the communication that can take place
between individual controllers across the network.

In all cases, where the client initiates the connection the controller is considered to be the server.
In peer to peer applications a controller can also be a client of the controller providing the data.

Serial interfaces
The controller is provided with two serial ports that can support a range of protocols. A port can
run the same protocol as the other or a different one. The protocol used by a serial port is
specified with the Workbench software and downloaded to the controller. In addition to the
protocols provided, users can also define their own protocol and download it to the controller.
Typical applications for the serial interfaces are communication with Technician /Engineering
workstations, exchange of data with remote devices, serial interface testing, HART maintenance,
use of Modscan, Configurator and Technician Utility programs.
Serial ports can be locked and unlocked on demand.

15
Modbus
Modbus operates in a half-duplex mode. That is, the master sends a request and expects to receive
a response before the next message can be sent to the same, or a different slave. The user can also
preset the amount of time that a master will wait for a reply from a failed slave, i.e. the timeout
period.
As Slave or Master the controller will respond to, or issue, respectively, the following Modbus
commands.
Command 1: Read Coil Status
Command 2: Read Input Status
Command 3: Read Holding Registers
Command 4: Read Input Registers
Command 5: Force Single Coil
Command 6: Preset Single Register
Command 8: Read Diagnostics
Sub function 0: – Return Request Data
Sub function 2: – Return Diagnostic Register
Command 15: Force Multiple Coils
Command 16: Preset Multiple Registers
Command 17: Report Slave ID

Modbus Slave
The controller can receive Modbus commands via the serial link and operate as a Modbus slave,
providing information on the contents of its data registers and accepting write commands to
modify register values.
As slaves, both controllers of a redundant pair can be part of a multi-drop serial link and are
allocated individual node addresses. Addresses lie between 2 and 255 (since 0 is always used for
broadcast) and before configuration a controller will have the default address of 126. A
redundant pair – Master and Standby – would have consecutive node addresses and each
recognises the address of the other.

Modbus Master
The controller can also act as a Modbus master to control and obtain information from equipment
that is capable of operating as a Modbus slave. As master there are specific controller and link
configurations that may (and may not) be used.

Permitted Configurations
a) Simplex controller - Single link
COM1 or COM2 can be multi-dropped to connect to one or more remote Modbus devices.
The remaining serial link can be used for a different network of remote Modbus devices.
b) Duplex controller - dual link
This is effectively case a) for each processor. If COM1 is used then controller A is connected
to the remote devices via its COM1 and controller B is connected to the same devices using
its COM1. The remote devices must support the use of dual links.
c) Simplex controller - both links
COM1 is connected to the remote devices and COM2 is connected to the same remote
devices. The remote devices must support the use of dual links.

Non-permitted Configurations
The following two configurations are NOT permitted as they would require the use of two
Modbus masters on the same link. The Modbus protocol does not support multi-masters.
d) Duplex controller - Single link.
Where the A and B controllers are multi-dropped on the same cable used to connect the
remote Modbus devices.
e) Duplex controller - both links.
Where controllers A and B are multi-dropped on both COM1 and COM2 with the remote
devices. The remote devices are connected to both COM1 and COM2 networks.

16
 Dual link action
Where both COM1 and COM2 are used to connect to the same remote nodes, the Controller
selects which link to use for read and write commands. The links are treated independently of
each other. When a read or write is about to be sent on either link, a test is made to determine
whether this is the active link for this node. If it is not the active link then the command is not
sent. Diagnostic messages are sent regardless of active link or not.
The algorithm that determines the active link involves examination of the diagnostic flags for that
node. If the node is healthy on one link and not the other then the healthy one is active. If neither
is healthy then read and write commands are not sent, only diagnostic commands are sent. If both
links are healthy then COM1 is preferred over COM2. This is so that remote devices that have
preferred links can be wired with COM1 connected to the preferred port. For instance a BIM uses
DMA transfers on LAN A but character interrupts on LAN B. This COM1 should be connected
to LAN A. This also tallies with the controller use of serial ports. DMA is available on COM1
but not COM2.
Note that each node is treated independently of all others. There is no concept of active link just
active link per node. Thus the controller might use COM1 to access node 2 but COM2 to access
node 3.
Excluded from this design is the idea on non-automatic failback. For instance, if COM1 fails then
recovers then the controller is happy to automatically resume its usage. It does not need a manual
command to re-enable that link.
Remember that dual links cannot be used in duplex mode.

Duplex action
Case b) is the only duplex scenario supported. Here each processor polls the link independently
of each other. The master sends writes and reads and the standby diagnostic messages. Each
makes the status of each node on each link available in the Input States. However, be aware that
if the standby is unhealthy then its diagnostic status data are not available since they cannot be
communicated to the master.
The Failover criteria are similar to the rules used for Railbus modules. That is, if one controller
can see some nodes that the other cannot see, and this is not true the other way around, then the
one that sees the nodes will be master (subject to other failure conditions).
As for modules the comparison is not based on a straight inspection of the diagnostic flags. When
a node changes status from healthy to failed or vice versa then this change triggers the other
processor to access that node 'immediately' using the diagnostic message. When the other
processor has completed then the processor that first detected the change repeats the access to the
node. Only if the other processor has a different result is this node marked as failed or recovered
for failover purposes.
Because of the co-ordination required between the processors inter-controller link transfers are
required. This could delay the retries of the failed node so it could take up to a second for the
failover to occur.

SLIP
The serial ports can also support the SLIP protocol for point-to-point communications.

Multidrop HART
This is a variant of the HART protocol enabling it to support multi-drop requirements. This can
be used on a single serial link that connects multiple controllers.

User written
The controller is also able to accept any other serial protocol that a user wishes to support. The
user can write a software driver that interfaces to the controller and embed it in the controller
firmware.

HART maintenance
HART plays a significant role in modern process control and any system has to provide the
facilities for the gathering of HART data and the management and maintenance of HART field
devices.

17
Cornerstone
This popular HART maintenance software is supported by the PAC8000 System. It is
implemented via either of the serial ports using a multi-drop configuration.

AMS
Support for the AMS software is currently in development. The server being designed will
provide an Ethernet interface for the HART maintenance software.

HART OPC Server

The HART OPC Server provides the services required to communicate with HART compatible
field devices. It is not an application in itself but provides an OPC server functionality for easy
integration of HART data into any OPC client. It has a pass-through interface, specified by the
HCF, that allows HART device-specific commands to be passed from the client applications
through the server to a field device.
The HART OPC server has all that is necessary to interface to the PAC8000 System for the
exchange of HART primary and status data and the control of HART devices.

18
Installation and Configuration
Health And Safety
Before commencing installation of the equipment:
♦ Ensure that all installation work is carried out in accordance with all relevant local standards,
codes of practice and site regulations and any special requirements stated in this manual.
♦ Check that the module functions are correct for the applications.
♦ Take care to avoid damaging the pins at all connector interfaces.
♦ Ensure that all relevant power supplies have been made SAFE.

Enclosures
In many cases the PAC8000 System equipment will be located out in the process plant and will
therefore require some form of protection from the weather and the danger of physical damage.
Enclosures for this purpose are readily available, but any enclosure that is designed to provide an
adequate level of ingress protection and is capable of withstanding physical damage appropriate
to the environment will be satisfactory.

Planning
Before beginning installation consider the following points:
♦ Additional carriers may be required at a later stage. When positioning the trunking, the
PAC8000 System controller carrier and any 8000 I/O carriers, consider making provision for
such extensions or modifications.
♦ Where possible, when routing the wiring and associated trunking, make generous space
allowances for the carriers, carrier extenders and extension cables.
♦ Make adequate allowance for the working space to trim and insert cable-ends.
♦ Try to ensure that you have all the required parts to hand before starting.
♦ Ensure that you have a 3.5 mm flat-bladed screwdriver, a 2 mm flat-bladed screwdriver, and
all the necessary tools for mounting the enclosure, DIN rails (if used) and cable trunking.
Tools will also be required for preparing cable-ends.

Summary
Installing a PAC8000 System node is straightforward. Depending on circumstances and work
procedures, a node may be constructed in a wiring shop and then taken on site for installation or
fully constructed and installed in-situ.
Referring to manuals listed in "Related documents", a typical installation could proceed as
follows:
1. Install trunking, making allowance for carriers and required clearance for trimming and
fitting cable-ends.
2. Install the DIN rails (or if DIN rail mounting is not used, drill mounting holes in the
mounting surface).
3. Fit the carriers (and any carrier extenders) to the DIN rails (or fit carriers to the mounting
surface).
4. Fit the field terminals.
5. Switch off all power supplies to the node and make safe.
6. Trim field wiring cable-ends and connect into the field terminals (this could also be done
after the modules are fitted). Cable-ends should be tagged to identify the associated
instrument/actuator.
7. Trim cable ends of power supplies and connect to the relevant terminals.
8. Fit carrier extender cables.
9. Fit the Power Supply Unit(s), I/O modules and the PAC8000 Controller.
10. Connect the power supply and LAN cables to the PAC8000 Controller.

19
Carrier installation
Mounting the Controller/EBIM carrier
The PAC8000 Controller/EBIM mounts on a purpose built module carrier that connects via a
multi-pin plug to an I/O module carrier. The carrier must be mounted firmly to a suitable vertical
panel.
Important note: Any panel orientation other than vertical may affect the air circulation around
the controller and will reduce the operating temperature range. Contact the equipment supplier or
manufacturer for advice on alternative mounting orientations.
The four fixing point locations for the carrier are shown below in Figure 13.
125
55

Ø 7 - 2 places

PO W ER FAIL IN PUTS
2/ 2 NC 2/ 1
–
+ 1 2 3 4 5 6 7 8 9

PFM

L
C
178

A B
103
CHANGE CHANGE
A STATE STATE B
SERIAL SERIAL
PORT PORT
1 1

Ø 6.2 - 2 places
40
188

Figure 13 - Mounting hole positions for carrier

Figure 13 also provides a guide, via the multi-pin connector location, to the relative position of
the adjoining I/O module carrier.
The carrier should be mounted onto a panel using M6 machine head or cheese head screws with
suitable washers. As a guide to the length of mounting screws; if the panel is 3 mm thick, with a
panel mounted nut, use 25 mm length screws.

Carrier power supply connections

The carrier requires a 12 V DC power supply. This supplies the I/O modules and a Power Supply
Monitor module, when fitted.
The connections, located at the top left of the carrier (see Figure 13), should be wired as given in
the following table.

Table 2 - 12 V Railbus supply connection

Pin # Function
1
2 0V
3 + 12 V DC
4 + 12 V DC
5 0V
6 No connection

Carrier grounding
The circuit board should be grounded to the panel on which the carrier is mounted using the screw
terminal located in the upper left corner of the carrier (see Figure 13).

20
 Power “health” connections
The carrier has provision for the connection of “health” signals from local power supplies that
supply the carrier, controller and the I/O modules. The input connector for these signals is located
on the upper left side of the carrier and has connections described below.

Table 3 - Power “health” signal connections

+
123456789
Terminal pairs 1 to 6 are used to receive power health signals from power supply types 8913 and
8914, where
+ = Power health signal from power supply
– = – ve return from power supply output
Note: In the case of the 8913-PS-AC power supply, the “–“ connection must come from the – ve
return of the 12V output.
Terminal pairs 7 and 8 are not connected and should not be used.
Terminal pair 9 (i.e. + and –) should be left unconnected if a Railbus Isolator (8922-RB-IS) is
being used. Connect them with a wire link if there is no Railbus Isolator present.
The screens/shields from any of the incoming cables may be connected to the screw terminal
beside the power “health” connector.

Controller installation
Mounting the controller
A controller mounts on a purpose built carrier - see above. As mentioned above, the carrier must
be mounted in a vertical plane in order to provide the correct air circulation. The controller is
mounted on the carrier with the power connector facing upwards and the LAN connections facing
down. Locate the controller on the multi-pin circuit board connector provided and push home.
Apply sufficient hand pressure to keep the controller in place until the two securing screws are
tightened.

Controller power supply connections

The controller has a multi-pin connector on its top face to receive a nominal 12 V, 4.1 A (max.),
DC supply.
The pin connections for this interface are shown in the following table.

Table 4 - 12 v DC controller connection

Pin # Function 12 6

1&7 + 12 V DC
2&8 0V 7 1

3–6, 9–12 Unused

Note: The power connector may be removed or replaced without isolating the incoming power.

21
LAN connections
There are two Ethernet ports on the controller, one for the “LAN in use” and one for the
redundant LAN (see Figure 14).

Serial port 2

LAN A

LAN B

Figure 14 - Communication ports on controller

Both of the LAN connections accept the standard Ethernet cable with RJ45 connectors. These
connect directly to a local Ethernet hub or switch – or two separate hubs/switches if redundancy is
required.
Both ports are 100BaseT and 10BaseT compatible with integral shielding. The connecting cables
for these ports should be of the type – Category 5, shielded twisted pair (STP).

Serial ports
The two serial ports for a controller are located in different places. Port 1 is part of the carrier on
which the controllers are mounted (see Figure 15), and Port 2 is on the controller, adjacent to the
RJ45 Ethernet ports (see Figure 14).

POW ER FAIL IN PUTS

2/ 2 NC 2/ 1
–
+ 1 2 3 4 5 6 7 8 9

PFM

A B

CHANGE CHANGE
A STATE STATE B
SERIAL SERIAL
PORT PORT
1 1

Serial ports
on carrier

Figure 15 - Serial port 1 (A & B) on carrier

The serial ports on the carrier and the controller use sub miniature D-type, 9-pin connectors.
5
9

6 1

Figure 16 - D-type connector for serial port connections

22
 The pin allocations for this connector are as follows:

Table 5 - Serial port pin-outs

Pin # Function
1 0V
2 N.C.
3 Tx / Rx (+)
4 Tx / Rx (+)
5 Tx / Rx (–)
6 Tx / Rx (–)
7 N.C.
8 N.C.
9 0V

Note: The body of the connector on the carrier is connected to the ground plane of the carrier
circuit board.

Addressing
Although there are redundancy and automatic failovers to consider, addressing the various
elements of the system is very straightforward, and largely transparent to most users of the
system.

LAN addresses
Although there are two ports on a controller, there is only one IP address allocated to it. The fault
tolerant Ethernet (FTE) interface automatically links the IP address of the controller to the
hardware address of the “port in use”.
If one LAN develops a fault, the controller’s IP address gets linked to the hardware address of the
other port. This “port switching” is transparent, and “bumpless”, to higher layers of the network
model, where the controller is always regarded as a single entity.

Node addresses
As mentioned above, each controller has an IP address. However, in a system with redundant
controllers, where either one could be the master, it means that there are two potential IP
addresses for the node!
It is important that each has an independent IP address because, occasionally, instructions need to
be directed at a specific controller, as in the event of a software update.
The dual address situation is resolved by the fault tolerant Ethernet (FTE) interface, which
ensures that the IP address of the node is mapped to the appropriate controller.

Serial port addresses

The serial port addresses will depend upon the type of protocol used at the port and are allocated
during setup.

Configuration tools
Configuration of the PAC8000 Controller, and it component parts, is carried out from the
PAC8000 Workbench. This application runs under the Windows® operating system and resides
on a PC normally located in a Control Room type area.
The Workbench software is an integrated development environment that is used to launch various
tools under its control, each of which is dedicated to a specific task. The tools are described here,
in brief, but the user is advised to consult the help files and other documentation that relates to
each specific tool.

PAC8000 Process Control

PAC8000 Process Control software is an open, easy-to-use process control engineering and
management software solution that delivers comprehensive, distributed control system
functionality. PAC8000 Process Control software is a fully integrated advanced process control

23
and instrument engineering system offering configuration tools, modelling, simulation,
troubleshooting utilities, project drawing management and self-documentation. It is a robust
solution that provides the flexibility to configure control systems ranging from a few loops to
thousands of points. A flexible, scalable design allows cost effective sy stem expansion. In
addition, the system’s extensive use of industry standards simplifies integration with other
applications.

Discrete Control
Discrete Control is a powerful, robust embedded software technology that is designed to build
distributed discrete control applications. The Discrete Control Workbench is your complete tool
kit for creating IEC 61131-3 programs. The Discrete Control Workbench fully supports the six
IEC 61131-3 automation languages (Ladder Diagram (LD), Sequential Function Chart (SFC),
Function Block Diagram (FBD), Structured Text (ST), Instruction List (IL) plus Flow Chart) and
is used to develop, download, simulate, debug, monitor, and edit application programs. The
Discrete Control Workbench permits the user to mix programming languages in the same project.
Its true Windows interface guides the user through development of the project. PLCopen has
certified this software to the IEC 61131-3 standard to ensure portability of programs. The
Workbench Simulator will test programs before startup. The Workbench can then be used
dynamically to view programs as they run in real-time and to make changes on-the-fly.

I/O Configurator
The I/O Configurator software is used to provide the detailed configuration information that the
I/O hardware requires. Unlike the higher level, strategy building software, which describes what
is done with the collected data, this application might be said to define how the data is collected.
It is used to configure the hardware interfaces in the system.
For example, the I/O Configurator is used to specify the type of input sensor, whether HART
variables and status reporting is enabled, whether pulse counting is used, etc. It can also be used
to view a log of I/O events.
For full details on the use of the Configurator, see the instruction manual INM8455.

Network IP address configuration

The IP address for a PAC8000 Controller is assigned automatically when the controller is
connected to the system. When the controller is powered up and connected to the system, it
initiates a broadcast, intended for the Workbench, giving its MAC address and asking for an IP
address.
If the MAC address(s) of the controller had been recorded before it was connected into the
system, the Workbench, on receipt of the broadcast, can identify the MAC address of the
controller broadcasting and automatically assign an IP address to the controller.
If the MAC address was NOT known before the controller was connected then, as long as there is
no more than one new controller connected to the system at one time, it will be obvious that the
new controller appearing on the Workbench screen is the one that has just been fitted.
The assigned IP address is sent to the controller, which then records it permanently by writing the
address to its flash RAM.

Modbus address mapping

Users requiring the Modbus register addresses for the allocated tag names can obtain a printed
report directly from the Workbench. To obtain a printed report or save a copy of the report to file:
1) Select “Controller Reports” under the named controller/EBIM in the tree view on the left of
the screen
2) Click on the “Standard Reports” radio button at the top of the right hand panel, select the
“Master Tag Xref” report in the drop-down list-box beneath it and click the “Run Reports”
button
3) From the top menu bar choose “Panel” and then select Save or Print according to
requirements.

24
 Downloading / Uploading
The PAC8000 Controller has the ability to receive strategies and configurations via the network.
The Control Centre software can download the executable software to the Controller where it is
checked for any transmission errors then stored in non-volatile memory for use.
New strategies and configurations can also be downloaded while it is still running an existing one.
The new strategy is stored in a different section of memory to the existing one. When it has been
checked and confirmed as a “clean download” the operator can switch the Controller to the new
strategy without interruption.
I/O module configurations can also be changed via the network. In a similar manner to strategies,
a configuration can be downloaded to the Controller for transmission within the node to the I/O
modules. This enables maintenance staff to change hardware on the plant and then have a new
configuration downloaded from the Control Centre.
Uploading of configurations and strategies from the node is also possible. This enables operators
in the Control Centre to obtain and check the configuration or strategy that is currently loaded
into the Controller.

Updating firmware
If a new release of operating software is available, this may also be downloaded to the Controller
for embedding in its firmware memory. The Controller has to be in Standby mode in order to
accept the new revision of software so it cannot continue to run a process while the update takes
place. However, if a second (redundant) Controller is available at the node, the firmware can be
downloaded to it while it is in Standby mode. On completion of the download and verification, it
can become the new Master while the other obtains its update.

Maintenance
Power Supply Monitor
The Power Supply Monitor module (8410-NS-PS) monitors the health of all power supplies in a
PAC8000 System node and signals to the Controller in the event of a failure. The module receives
power supply status information for all supply rails including 12V system power, 24V field power
for general-purpose I/O modules and field power for intrinsically safe I/O modules.

Figure 17 - Power Supply Monitor (8410-NS-PS)

Where power supply redundancy is supported, the module enables failed power supplies to be
identified and replaced without interference to the process. In Zone 2/ Div 2 hazardous areas, the
Power Supply Monitor module may be removed and replaced without the need for a gas clearance
certificate.

LED indicators
A set of indicators is provided on the front face of a controller. These provide indication of both
healthy and fault conditions. The following table gives an interpretation of the status of the
Controller based on the indicator states.

25
Table 6 - LED indicator states
LED name Colour On Off Flashing
Power green Power OK No power –
Master yellow Master Standby –
Healthy yellow Healthy Not healthy Refreshing
Fault red Failed OK Starting
Failsafe red In failsafe mode OK No control
LAN A yellow OK Not in use Fault
LAN B yellow OK Not in use Fault
COM 1 yellow OK Not in use Fault
COM 2 yellow OK Not in use Fault
A-B Link yellow OK Not in use Fault
Railbus yellow OK Not in use Fault

26
I/O modules
The PAC8000 Controller is supported by a broad range of input and output (I/O) modules from
the 8000 I/O range. These are mounted on carriers, similar to the controller(s). The carriers
connect to each other through multi-pin connectors, which carry the data and power supplies on a
simple bus.

General purpose applications

Process control has applications in many industries: water treatment, steel making, brewing,
power generation, etc., all of which can have harsh plant environments. 8000 I/O series products
are specifically designed to withstand such environments and these applications are referred to
here as general purpose.

Hazardous area applications

Other industries, such as oil exploration and refining and chemical and pharmaceutical
manufacturing have environments that may contain explosive gases or dust and therefore these
type of uses are referred to as hazardous area applications. GE is a world leader in technology for
the prevention of explosive hazards and that experience is of major value to users requiring
process control equipment for such applications.
The 8000 series equipment is certified to operate in Class I, Division II (USA) and Zone 2
(CENELEC) hazardous area environments. Certain components in the 8000 range are permitted
also to connect into Division I, Zone 1 and Zone 0 hazardous areas.
An application “code” has been adopted that helps users to identify the type of 8000 I/O Series
equipment for their particular application. As well as general purpose, two equipment applications
are defined – “2/2” and “2/1”.
The two numerals, and their usage, have a particular meaning as follows:

2/1
Location of Ü Û Field wiring
node location
e.g. Zone 2 or e.g. Zone 1 or
Division 2 Division 1

♦ The first figure represents the most hazardous type of area in which the equipment can be
mounted (without additional hazard protection)
♦ The second figure represents the most hazardous type of area from which the field wiring
can originate.

27
2/2 (& general purpose) applications
This equipment represents a base level for all applications. It is used for all general purpose work
but it has been designed to be mounted in Zone 2 or Division 2 hazard areas and will accept field
wiring that originates in the same, or non-hazardous (i.e. safe), areas. All general purpose
applications should use 2/2 products.

I/O module types available

No. of
Model I/O module function channels
ANALOG INPUT
8101-HI-TX 4/20 mA with HART 8
8103-AI-TX 4/20 mA 8
8105-TI-TC Thermocouple and mV 4
8106-TI-RT RTD and Ω 4
8119-VI-05 1 to 5V 8
ANALOG OUTPUT
8102-HO-IP 4/20 mA with HART 8
8104-AO-IP 4/20 mA for I/P converters 8
DISCRETE INPUT
8109-DI-DC 24V DC, isolated, sinking 8
8122-DI-DC 24V DC, isolated, sinking 16
8110-DI-DC 24V DC, non-isolated, module powered 8
8121-DI-DC 24V DC, non-isolated, module powered 16
8111-DI-AC 115V AC, isolated, sinking 8
8112-DI-AC 115V AC, non-isolated, module powered 8
8113-DI-AC 230V AC, isolated, sinking 8
8114-DI-AC 230V AC, non-isolated, module powered 8
DISCRETE OUTPUT
8115-DO-DC 2-60V DC, non-isolated, module powered 8
8117-DO-DC 2-60V DC, isolated, volt-free switch 8
8116-DO-AC 20-265V DC, non-isolated, module powered 8
8118-DO-AC 20-265V DC, isolated, volt-free switch 8
PULSE INPUT
8123-PI-QU Pulse/frequency input 2

See the individual product data sheets for further details.

28
 2/1 applications
While still designed for mounting in Division 2 or Zone 2 hazardous areas, 2/1 equipment can
accept field wiring from Division 1 or Zone 1 hazardous areas. All Div 1/Zone 1 field wiring is
protected by built-in intrinsic safety (IS) interfaces (see Glossary on page ); as a result, the field
wiring can even originate in a Div 1 /Zone 0 area with total safety.
All IS field wiring applications must use 2/1 I/O modules.

Intrinsically safe field wiring I/O module types available

No. of
Model I/O module function channels
ANALOG INPUT
8201-HI-IS 4/20 mA with HART 8
8205-TI-IS Thermocouple and mV 8
8206-TI-IS RTD and Ω 8
ANALOG OUTPUT
8202-HO-IS 4/20 mA with HART 8
8204-AO-IS 4/20 mA for I/P converters 8
DISCRETE INPUT
8220-DI-IS Switch / proximity detector 16
DISCRETE OUTPUT
8215-DO-IS Solenoid driver / IIC gas groups 4
PULSE INPUT
8223-PI-IS Pulse/frequency input 2

See the individual product data sheets for further details.

HART support
Some modules within the 8000 range are designed to provide support for HART field devices.
Input modules are available that can read the HART variables and output modules that can
transmit them to the field devices.

Failsafe modes
Every module has a “failsafe” mode that it can adopt automatically in the event of a loss of
communication with the controller. The mode can be defined by the user to be a specific failsafe
state, e.g. “go to maximum value” or “go to minimum value”, or it can hold the last valid value
that it had before the communications breakdown.
Failsafe values are defined during configuration and downloaded to the controller. The Controller
then passes the individual configurations to the I/O modules.

NAMUR compliance
LED indication styles are compliant with the current NAMUR standards.

29
Module installation
Details for the installation of 8000 series modules are provided in the following publications:
• INM8100 – Installation Guide - 2/2 I/O modules
• INM8200 – Installation Guide - 2/1 I/O modules

Module configuration
The I/O modules are configured through the PAC8000 Workbench software. Consult the
Workbench help files for details.

30
Fieldbus support
The PAC8000 System is designed to support the bus networks in your plant, simplifying
automation tasks. The system supports FOUNDATION™ Fieldbus, HART, and serial protocols such
as Modbus and Profibus, in addition to traditional analog and discrete I/O interfaces.

Foundation Fieldbus
The PAC8000 System fully supports FOUNDATION™ Fieldbus devices. A fully integrated H1
Linking Device implements up to four Fieldbus H1 ports and connects to the PAC8000 controller
over the high speed Ethernet Plant Network. Function blocks are available in the PAC800
Workbench to integrate H1 data into the control system and the Operator Displays and can be
used to communicate between H1 devices.

HART – Universal commands

HART is supported by the I/O modules that connect directly to the HART field instruments. The
modules can pass up to 4 variables to the Controller in addition to the analog process signal.
Analog input and output modules “with HART” can obtain information from any HART
instrument. Each module channel can communicate with a single HART instrument. HART
universal command 3 is used to gather up to 4 dynamic variables, which are available in many
HART devices. A differential pressure transmitter can now transmit absolute pressure(s),
temperature and device status in addition to the 4-20mA differential pressure signal. This
provides more process information to the PAC8000 Controller from each device. Modules “with
HART” permit HART messages to be passed through to HART instruments for calibration, status
checking and advanced diagnostics and pass messages back to the asset management system for
device maintenance.

Modbus
The PAC8000 Controller can adopt a master role enabling it to communicate with existing
fieldbus subsystems. This enables it to use data from existing I/O components and share the
information throughout the network. It will also perform as a Modbus slave when requested for
data from I/O components that it is managing. It performs full validation of all requests then
supplies the data. If it is configured with a redundant Controller then only the Master is authorised
to respond to Modbus requests.

H1 Linking device
The PAC8000 system supports H1 linking devices, which are single integrated units that function
as a:
▪ linking device
▪ bridge
▪ controller
▪ gateway
▪ Fieldbus power supply
▪ distributed I/O subsystem
The use of FOUNDATION™ Fieldbus and OPC enables it to tightly integrate with the PAC8000
Controller and other intelligent devices and software from multiple manufacturers. It also has
serial ports that enable it to play the role of Modbus master to conventional fieldbus equipment or
slave in a Modbus to H1 role. It also incorporates full redundancy to compliment the PAC8000
system.

Fully integrated
The device is a complete integrated and self-contained unit including power supplies, impedance
terminator or even safety barriers, making it simpler to deploy, maintain and expand. A single
module implements four H1 ports, Ethernet and serial Modbus port directly on the controller.
This enables the user to implement a simpler and leaner control system.

H1 flexibility
The linking device creates a pathway for communication between local and remote H1 devices
enabling each H1 device to be addressed from any point on the network. It has a built-in Fieldbus

31
 power supply subsystem that includes a range of power supplies, impedance terminators and
isolating safety barriers.

HART maintenance
The PAC8000 System is designed to operate with conventional HART maintenance software.
This enables HART instruments in the field to be managed from a central point. The software
provides a supervisory program that allows remote configuration and diagnosis of the HART
devices. A serial link is established between the Controller and a control room PC running the
maintenance software and a network of stations can be formed via a LAN.
Typical examples of HART maintenance software are Cornerstone from Applied System
Technologies and Asset Management Solutions (AMS) from Fisher-Rosemount.

PAC8000 Controller connection

The PAC8000 Controller is equipped with two serial ports, each with RS485 interfaces, that can
be used to connect directly into a HART management network. For extended distances, repeaters
may be required to maintain signal quality.

32
Communications network

Cabling
Category 5 – twisted pair cable
Network cable runs of up to 100 meters (approx. 300 ft) should use standard Category 5 (Cat 5)
cable. This type of cable is recommended because of its relative immunity to moderate levels of
electrical interference. The eight conductors within the cable are arranged in four pairs. Each pair
is twisted together to reduce the effect of stray electromagnetic fields. A foil screen is then
wrapped around the eight conductors to increase the electromagnetic protection. This foil, or
shield, should be grounded at one end of the cable run to prevent it from building up a static
electrical charge and reduce the effects of electro-magnetically induced signals.
Category 5 cable is a recognised standard and cable of inferior quality will not perform as well
over the distances specified above.

Optical Fibre
When network cables are required to cover distances of greater than 100 meters, twisted pair
cable is not suitable; the signal losses become too great. To travel distances greater than 100
meters the system designer generally turns to optical fibre.
Different types of fibre are available to suit the distance travelled. Multimode is the commonest
grade and is suitable for distances up to approximately 1 kilometre, after that, it too is prone to
excessive signal loss. Single mode fibre is the best, and most expensive. This is capable of
covering distances up to 7 kilometres in a single run.
Optical fibre cabling requires electrical to optical interfaces at each end of its run. Network
components like switches and hubs can be purchased with these interfaces built in. If the
component does not have an optical interface, then additional interface components will have to
be purchased to make the conversion.
Optical fibre is not only a means to cover greater distances but is also an option when network
cabling has to travel through areas that are particularly prone to large amounts of electrical noise
caused, for example, by the switching of heavy currents. The data in optical fibre is carried by
means of light pulses and this makes it insensitive to electrical interference.
It is also an excellent medium for crossing areas that carry risks of inflammable vapours being
present. Because it carries no electrical signal, there is no danger of a broken or severed cable
causing ignition of this type of atmosphere.

Terminations/connectors
Cat 5 cable
The PAC8000 Controller is fitted with shielded connectors to reduce electrical noise and to
ground the cable. If cable terminations will be fitted by the user then shielded terminations should
be used to maintain the same level of screening. Shorter patch cables can be purchased ready
fitted with this type of connector and are usually designated with an ‘S’ in the cable type number.

Optical fibre
The fitting of the terminations at each end of optical fibre requires specialised skills. The fibre has
to be fitted with end terminations that will transmit the light signals with the minimum loss.
Incorrect fitting of these terminations will either damage the cable or render it ineffective because
of the signal loss. Always have fibre terminated by suitably trained and experienced
personnel.

33
Workstation

Recommended specification
While the PAC8000 Workbench software will probably work successfully with a wide range of
hardware, PAC8000 has tested the software on equipment supplied by Dell Computers and
found their operation to be satisfactory.

IP addressing
IP addresses for PAC8000 Controllers are assigned by a BOOTP server that resides in the
PAC8000 Workbench workstation.
There is no intrinsic incompatibility with DHCP (Dynamic Host Configuration Protocol), which
is often used to assign IP addresses, and BOOTP and DHCP will co-exist without any conflicts.
The Process Network will be set up as a different entity from, say, the Office Network and so the
user will probably assign the workstation IP address manually, as a matter of course.
The PAC8000 Workbench workstation must be the first node on the network and PAC8000
Controllers can only be attached to the network when the PAC8000 Workbench workstation has
been installed. Unless this happens, the Controllers will not be assigned addresses and will
therefore be unavailable on the network.

34
PAC8000 Workbench
The PAC8000 Hybrid Controller contains two embedded software environments that will run
executable files downloaded to it from the Workbench. These environments allow the controller
to perform the functions of either process automation or discrete automation as the user requires.
The Hybrid Controller is in fact capable of performing these functions in parallel with each other,
so that two completely separate and unrelated processes can be controlled at the same time.
The PAC8000 Process Controller and the PAC8000 Logic Controller contain a single embedded
application that provides the functionality of a DCS or a PLC, respectively. The basic properties
of each of these control environments are described here.
The PAC8000 EBIM can be used as a remote slave to a host controller or to one of the above
PAC8000 controllers. Any of the Workbenches described below can be used to configure the
EBIM.

PAC8000 Process Control - Overview

PAC8000 Process Control is a process control engineering and management software solution
with full distributed process control system functionality. The system is a fully integrated
advanced process control and instrument engineering system offering configuration tools,
modelling, simulation, troubleshooting utilities, project drawing management and self-
documentation.
PAC8000 Process Control is an open, easy-to-use, robust system providing the flexibility to
configure control systems ranging from a few loops to thousands of points. The user can also
scale their design allowing cost effective system expansion. In addition, the system's extensive
use of industry standards simplifies integration with other application.

PAC8000 Workbench
The PAC8000 Workbench consists of modular software building blocks that are integrated into a
process control solution. The system comprises two integrated components; the Instrument Index
and the Strategy Builder.

Instrument Index
The Instrument Index is used to model the process systems input/output by assigning controller,
module and point destinations. Using a predetermined template, this task is accomplished as a
simple "fill in the blanks" procedure. The Instrument Index uses this information to build the I/O
configuration data file. This data file will subsequently be used to cross-link the point attributes to
the algorithms on the process control diagrams.

Strategy Builder
Process control logic diagrams are developed using the Strategy Builder. The control strategy is
built by selecting the appropriate blocks, assigning symbolic tags, and then connecting the blocks
with analog or digital lines, using standard drawing forms and commands. SAMA style drawings
define all the functions and parameters that form a process loop. Function block choices include;
manual/auto station, function generators, pulse controllers, sequencers, bumpless transfers, PID
and other standard function blocks. To further reduce development time template diagrams can be
created and reused within the current project or another future project. For example, a cascade
loop can be created and saved for repetitive use to generate additional control loops. When the
drawing model is completed, the project diagrams are cross-linked with the I/O database to create:
• Comprehensive control system engineering documentation.
• Advanced control strategies.
• Operator interface database, alarms and faceplates.
• System maintenance tools.
There is no need to review function block codes, re-enter tags, generate spare parts listings, or
match control logic to the operator interface. This allows the user to concentrate on designing
control strategies and eliminate the repetitive tasks.

35
 Project Components
In addition to these key design features, PAC8000 Process Control has a wealth of tools and
features that simplify the management of the project and provide easy to use interfaces for the
user.

Comprehensive Self-Documentation
PAC8000 Process automatically generates as-built system documentation including I/O
configuration reports, cross reference analysis, bill of materials, instrument index, system start-up,
maintenance information, and wiring diagrams. The instrument index provides instrument details
such as manufacturer, model number, group number, shift and day log, panel wiring information
including panel in/out terminal block and panel in/out position, and field wiring information
including cable colour, size and type.

Advanced Control Strategies

The system automatically configures control solutions from straight-forward single loops to
advanced control strategies. With over sixty process control algorithms, PAC8000 Process has the
solution; whether for regulatory, discrete or sequential control. The algorithms provide the logic
and analytic functions for complex control strategies such as feed forward, cascade, and multi-
variable control. Functions are provided for easily configuring biased multi-output loops as found
in steam and water header pressure control. The system automatically accounts for different
device capacities, devices in service, and devices in automatic mode. Adaptive tuning functions
for PID control is supported. Two and three state device drivers provide the functionality for
motor and valve operations with failure alarms, local and remote operation, and interlocks.
Sequential step functions with interlocks and first out functionality are easily configured. The
system automatically assigns controller addresses, optimises controller communications and
provides I/O card and point alarm status. By supporting portability between alternative open
controller platforms, PAC8000 Process provides considerable flexibility in specifying system
hardware.

On-line Maintenance, Tuning and Troubleshooting

Savings in time and system costs are not limited to initial development and start-up. The system
provides suggestive tuning capabilities, on-line and off-line control configuration, and intelligent
control schematics from which the system can be modified and tuned.

PAC8000 Process Simulator

The PAC8000 Process Simulator allows the animation of logic diagrams with either simulated
data or live, real-time process data. The Simulator is also used for tuning and operator control
purposes. I/O diagnostic tags are provided for the operator interface for troubleshooting
assistance. Verification of control loop integrity and troubleshooting loop problems can be
accomplished quickly and efficiently.

PAC8000 Logic - Overview

PAC8000 Logic is a 32-bit software application for distributed control applications. It supports all
five IEC 61131-3 languages: Ladder Diagram (LD), Structured Text (ST), Instruction List (IL),
Sequential Function Chart (SFC) and Function Block Diagram (FBD), plus the Flow Chart (FC)
language. The Workbench provides tools for simulation, debugging, and on-line monitoring and
editing of programs. The code generated by the workbench is ported to the target, i.e. the
PAC8000 controller, without modification to the original programs.

The Workbench
Discrete Control is designed to build distributed automation applications. The workbench
contains a powerful project management tool that graphically represents and organises programs,
resources, configurations, and networks within a project.
The Workbench provides powerful and intuitive graphical and textual editors. Docking toolbars
and resizable split windows, drag-and- drop and cut-and-paste are all implemented to enhance
ease-of-use.
The Ladder Diagram (LD) is one of the most familiar methods of representing logical equations
and simple actions. Contacts represent input arguments and coils represent output results. Each
block in the selection list has a description text.
The Structured Text (ST), is a high level structured language with a syntax similar to Pascal but
more intuitive to the automation engineer. This language is mainly used to implement complex

36
procedures that cannot be easily expressed with graphical languages. Discrete Control's ST text
editor guides the user to the correct syntax and punctuation and provides the best validation and
programmer assistance facilities.
The Instruction List (IL) is a low-level language, similar to the simple textual PLC languages.
IL is a register-level programming language. Discrete Control has a set of more than 60 IEC
functions and function blocks. Users can enlarge this set by writing functions and function blocks
in the LD, FBD, ST, and IL languages.
The Sequential Function Chart (SFC) language divides the process cycle into a number of well-
defined steps, separated by transitions. Discrete Control fully supports graphical Flow Chart
programming, which is familiar to many engineers.
Function Block Diagram (FBD) is a graphical language which allows the user to build complex
procedures by taking existing function blocks from the Discrete Control library, and wiring them
together on screen. The FBD editor allows manual input of variables. The diagrams can be
zoomed to view the whole diagram or specific areas in more detail. User can mix LD and FBD
programming in the same chart.
The Flow Chart is an easy to read decision diagram where actions are organised in a graphic
flow. The Discrete Control Flow Chart Editor has full support for connectors and sub-programs.

Linking variable and I/O devices

Before building the project code, I/O variables are linked to the I/O devices. I/O devices can take
the type Boolean, Integer, Small Integer, Real, Time, String or a user-defined Structure, enabling
the management of I/O validity, status, or any required information. Once a device is selected, a
simple mouse-click 'connects' a variable to a channel. On each channel a gain and an offset can be
defined.

The Build
To validate the project, the project code must be built. This step is also very useful for syntax
checking; all detected errors can be easily located with a simple mouse-click. The generated code
is fully publicly documented and supported. The code generator produces the code for each
resource plus all tables required for data exchanges.

Simulation
Simulation enables the validation of the project without any hardware. Each resource can be
executed cycle-by-cycle, and various system variables, such as the cycle time, can be monitored.
Data exchanges are also simulated. Any variable can be monitored or forced.
For debugging with real platforms, or to perform maintenance operations on 'live' systems,
changes can be downloaded on-line with-out stopping the running resources. During the testing
phase I/O devices can be set as virtual, if the PAC8000 Controller is not completely ready or is
unavailable to the programmer. Note also that now Function block's instances can be directly
debugged from editors. The workbench is intuitive and user-friendly, but to further assist the user,
Discrete Control provides HTML-based cross-referenced on-line help system that includes a
complete language reference. The Discrete Control workbench also offers a document generator.
Project items are shown as a tree, the table of contents of the project documentation can be
customised by a simple click on each item.
To allow re-use of code, libraries of IEC functions and function blocks can now be developed.
Functions and function blocks are designed and tested as in any other projects, but other projects
can be linked to these "library project" to allow the use of their functions and function blocks.
Once a "library project" has been selected, its blocks can be selected as standard blocks. As
libraries, import/export functionality allows the sharing of POUs between projects. It is also a
comfortable way to integrate the work of several programmers to constitute the final project.
For safety purpose, the "upload" feature allows you to download the source code of your
resources onto the target system. For maintenance purpose or at any time, these sources can be
uploaded to re-constitute the project.

The Target
The word Target refers to a PAC8000 Controller.

37
Power supplies
All of the PAC8000 System hardware is designed to operate from DC power. Power supplies are
available with the system to provide the required regulated DC voltages from AC or DC sources.

PAC8000 Controller
A PAC8000 Controller requires a nominal 12 V DC supply to operate. The power requirement of
any of the 8521-xx-MT Controllers is 5W, e.g. 12V DC @ 400 mA (typ.). This can be supplied
by a local bulk power supply – see below.
The controller is supplied with cabling (Part No. 015-428 - see Figure 18) that enables it to be
connected to two independent power supplies, i.e. a main and a redundant supply.
+ Red PSU 1
(main)
– Black
+ Red
Controller PSU 2
Power (redundant)
Connector
– Black

Figure 18 - Power cable configuration

If a single power supply is used, it is recommended that the cable for PSU 2 also be connected to
PSU 1.
Note: If the controller is located in an environment that will experience temperatures below
–20°C, the PVC cable should be supported and protected from physical impact to avoid stressing
the insulating sheath.

I/O modules
The I/O modules require a 12 V DC source which is distributed between modules via a combined
data and power bus called “Railbus”. The power (i.e. current) requirements of the modules
depends upon the type of modules used. As a “rule-of-thumb”, Digital Input modules take the
least current and Analog Output modules require the most. These factors must be taken into
account when designing the power regime. Full details of the requirements of each module are
provided on their data sheets.

Bussed Field Power

The 8000 I/O modules require a basic 12 V DC for the Railbus, but the field devices connected to
the I/O modules may require AC or DC power in order to function. Sometimes the power is wired
directly into the field device, but if this power will be supplied from the I/O module end of the
field wiring then it can be distributed to the I/O modules via the Bussed Field Power facility on
the module carriers.
Bussed field power enables the required power supply (DC or AC) to be connected to the I/O
module carrier and distributed to the modules that require it. This avoids the need for extra power
connections at the field wiring terminals and considerably simplifies wiring management.
See the instruction manual for I/O module installation and configuration INM8100 (General
Purpose and 2/2 applications) for further details.

Power for Intrinsically Safe field wiring

In some installations, part, or all, of the field wiring may have to enter Division 1, Zone 1 or Zone
0 hazardous areas. This requires the use of 2/1 I/O modules. In this event, the power for the I/O
modules must be supplied from a safe power supply that limits the amount of energy that can be
supplied into such an area. The 8920 power supply is designed for this task.
See the following instruction manuals for further details on IS I/O module installation and power
supplies for IS applications.
• INM82100 – Installing I/O modules (2/1 applications)
• INM8900 – Power Supplies – Configuration and Installation

38
AC/DC and DC/DC supplies
A range of recommended DC output power supplies that incorporate "power-fail signalling" is
available to suit all the applications required by the equipment. For full details of these items
consult the data sheets and the INM8900 instruction manual (see “Related Documents”).

39
Appendix A - ATEX information
The Essential Health and Safety Requirements (Annex II) of the EU Directive 94/9/EC [the ATEX Directive - safety of apparatus]
requires that the installation manual of all equipment used in hazardous areas shall contain certain information. This annex is included to
ensure that this requirement is met. It compliments the information presented in this document and does not conflict with that information.
It is only relevant to those locations where the ATEX Directives are applicable.

1 General
a) In common with all other electrical apparatus installed in hazardous areas, this apparatus must only be installed,
operated and maintained by competent personnel. Such personnel shall have undergone training, which included
instruction on the various types of protection and installation practices, the relevant rules and regulations, and on the
general principles of area classification. Appropriate refresher training shall be given on a regular basis. [See clause
4.2 of EN 60079-17].
b) This apparatus meets the requirements of protection 'n' in accordance with EN 50021.
c) This apparatus has been designed and manufactured so as to provide protection against all the relevant additional
hazards referred to in Annex II of the directive, such as those in clause 1.2.7.

2 Installation
a) The installation should comply with the appropriate European, national and local regulations, which may include
reference to the IEC code of practice IEC 60079-14. In addition particular industries or end users may have specific
requirements relating to the safety of their installations and these requirements should also be met. For the majority of
installations the Directive 1999/92/EC [the ATEX Directive - safety of installations] is also applicable.
b) This apparatus is normally mounted in a non-hazardous [safe] area, however, it also meets the requirements of
Category 3 apparatus and may be installed in a Zone2 location providing that the relevant installation conditions are
met.
c) This apparatus must not be subjected to mechanical and thermal stresses in excess of those permitted in the
certification documentation, this manual and the product specification. If necessary the product must be protected by
an enclosure to prevent mechanical damage.
d) The apparatus must not be installed in a position where it may be attacked by aggressive substances and must be
protected from excessive dust, moisture and other contaminants by an enclosure.

3 Inspection and maintenance

a) Inspection and maintenance should be carried out in accordance with European, national and local regulations which
may refer to the IEC standard IEC 60079-17. In addition specific industries or end users may have specific
requirements which should also be met.
b) Access to the internal circuitry must not be made during operation.
c) If the outer enclosure of the apparatus needs to be cleaned, this should be done with a cloth lightly moistened by a
dilute mixture of detergent in water.

4 Repair
a) The product cannot be repaired by the user and must be replaced with an equivalent certified product. Repairs should
only be carried out by the manufacturer or his authorised agent.

5 Marking
a) The Controllers are labelled in a manner that is reproduced below. In addition the serial number and/or date of
manufacture are marked on the individual apparatus.
This manual applies to products manufactured and date marked during or after the year 2002.
The following common information is provided on each component:

Company Logo:
Company Name and Address: GE Intelligent Platforms, Inc. Charlottesville, VA
European compliance mark: 1725

40