CSIKS

UCOS® Functional Overview
Version 5.0
Contents
Introduction.....................................................................3
User-Configurable Features .............................................. 3
Open System Features ....................................................... 5
System Components.........................................................7
Engineering Workstation (EWS)....................................... 8
Operator Workstation (OWS)........................................... 9
Field Control Unit (FCU) .................................................. 9
I/O Subsystem.................................................................. 10
SCADA Data Server (SDS).............................................. 10
Process Historical Archiver (PHA).................................. 10
Summary ......................................................................... 11
Project Configuration.................................................... 13
Architecture Configuration ............................................. 14
Device Diagram Configuration........................................ 18
Scripting .......................................................................... 29
Graphic Editors............................................................... 30
Alarm and Logging Configuration .................................. 33
Security Configuration .................................................... 34
Command Windows and Group Displays ....................... 35
Help System..................................................................... 36
Operator Interface......................................................... 37
Project Graphics Screens ................................................ 39
Command Windows and Group Displays ....................... 40
Monitoring and Acknowledging Alarms ......................... 41
Archiving ......................................................................... 42
Logging and Trending ..................................................... 43
Device Status and Diagnostics ......................................... 44
Network Diagnostics........................................................ 45
Connecting to Other Software......................................... 46
Communicating with Field Devices............................... 47
Field Control Unit (FCU) ................................................ 47
SCADA Data Server (SDS).............................................. 48
About Control Systems International (CSI).................. 49
2
UCOS Functional Overview
Introduction
UCOS is a complete control system solution. It includes The following sections describe in more detail the concepts
graphical development software, a graphical human- that underlie the user-configurable and open-system features
machine interface (HMI), and a logic processor — all based of UCOS.
on User-Configurable, Open System standards.
The product’s most important features include the ability to:

User-Configurable Features
• Use any traditional control system architecture,
Traditionally, control engineers choose configurable, DCS-based
such as DCS, SCADA, PLC/HMI, or any
systems primarily for the implementation of regulatory control.
combination thus achieving a high degree of
They choose PLC-based systems primarily for the
configurability along with low cost and easy
implementation of sequential control. They choose SCADA
maintenance.
systems primarily to integrate a large number of remote locations
• Provide totally configurable regulatory, discrete, and concentrate the logic processing at a central master station.
and sequential control.
UCOS combines the best of all these architectures.
• Use industry-standard hardware available from
numerous suppliers, including more than 40 I/O Like a DCS system, UCOS creates sophisticated regulatory
families from more than 20 manufacturers. control schemes that require little or no programming. Like
a PLC system, UCOS provides flexibility in customizing
• Provide connectivity to thousands of Windows every aspect of a project. Like a SCADA system UCOS
applications through the use of Windows 2000/XP. integrates remote and master stations.
• Provide development software that lets you design, However, unlike these traditional technologies, UCOS
configure, test, and document projects faster and creates regulatory, discrete, and sequential control schemes
easier using patented, award-winning techniques. using one integrated development tool. This single tool
addresses every aspect of the project:
UCOS is not an HMI stacked on a PLC. UCOS is a tightly
• Configuring all system hardware, including I/O
coupled project development and run-time software product
cards and tag assignment to points on cards
that lets you graphically configure object-oriented control
logic and simultaneously generate HMI graphics. One • Developing control logic
object-oriented database stores both the control logic and
graphics data for each project. • Building HMI graphics and other displays for
operators
The UCOS development and run-time environments turn
any PC into a scaleable workstation. In addition, the field • Documenting the entire project
control unit directly scans and controls multiple brands of …and all other aspects of a project.
industry-standard I/O, and the field data server allows the
system to exchange data with most other software and
UCOS eliminates the need to piece together a control
hardware.
system from multiple software packages that may or may
not be designed to work together.
UCOS includes built-in diagnostics and component
redundancy at all levels, if desired.
One integrated configuration tool does all the work and can
eliminate the need for extensive programming. This
As a consequence, UCOS can significantly reduce the cost integration allows UCOS to support a unified approach to
of developing, implementing, maintaining, and expanding a regulatory, discrete, and sequential control – regardless of
control system. the architecture.
3
Introduction
For example, UCOS device objects provide all the capability configuration is usually required to make each object unique
of function blocks by incorporating tag definitions, faceplates, and to place it into the control scheme.
programming symbols, run-time graphics, and run-time
dynamics. All this is immediately available when a device
object is placed into a device diagram.
UCOS employs object-oriented technology to replace

traditional function block and rung ladder logic programming.
Standard
Device Logic
Traditional
Function Blocks
Replaces
Figure 2 Drag-and-Drop Object Placement
Although UCOS includes a wide range of standard control

objects, it also supports extensive customization features via
Configurable templating. The templates allow you to create control
Device Logic Traditional objects to suit any need.
Rung Ladder Logic
()
Control schemes can be modified to fine tune or expand the
Replaces system. Process I/O and operator workstations are easily
added or deleted to meet changing control and business
requirements.
Figure 1 Relationship of Device Diagramming to Both the standard device objects and the user-definable
Traditional Control Programming Techniques device objects provide you with a library of starter control
schemes that can be reused any number of times. It is easy
User-configurable devices provide a unique structure and to add project-specific templates to the UCOS library and to
approach for building regulatory, discrete, and sequential import those templates into projects, thus cutting
control for a device. This structure is an extension of state development time.
logic concepts. These concepts call for a device’s control
logic to be organized into fundamental categories, such as More important, UCOS allows an organization to “package”
modes, faults, states, alarms, and controls. its best practice process expertise and then deploy that
expertise repeatedly resulting in control systems that are
This device structure is supported by event-based, logic- more consistent, more reliable, and easier to maintain
solving capabilities in the field control units (FCUs) — the throughout a project’s life cycle.
UCOS equivalent of the controller component in a traditional
control system. The FCU runs under just about any POSIX- UCOS also automatically generates faceplates or command
compliant operating system, such as Linux, QNX, UNIX, windows. You can, however customize command windows
Windows, etc. They are also available in a variety of form for user-defined devices.
factors, including high-performance PLCs and cost-efficient
ruggedized industrial controllers. The FCU controller can
directly scan and control multiple brands of I/O.
User-configurable devices and the reusable templates on

which they are based replace rung ladder logic
programming with a state-of-the-art, object-oriented
technology that offers significant advantages.
For example, device objects are dropped into logical and/or

physical relationships using graphical toolbars and menus
— standard point-and-click Windows techniques. Minimal
4
As a result, the UCOS object-oriented, hybrid approach to

control system development provides:
• More flexibility and control than DCS, PLC/HMI,

or SCADA systems
• Significant reductions in the engineering time

required to develop a project
• Enforced consistency within and among projects
• Ease of expansion and maintenance

Figure 3 Automatically-Generated Command
Windows within a Group Display
UCOS also provides automatically generated alarms, Open System Features

dynamic device graphic symbols, and other functions that are
The configurable features of UCOS afford many cost-saving
typically programmed or configured one-by-one in traditional
advantages. The open system features of UCOS afford even
control systems.
more advantages.
The automatically generated, dynamic device graphic
UCOS is designed around open systems standards — from
symbols can be placed into operator display screens using a
top to bottom.
CAD-like graphics editor that also provides tools for adding
other graphics elements, dynamics, and text.
• Engineering and operator workstations can be
widely-available PCs.
• Real-time field control units (FCU) directly scan

and control industry-standard I/O. They run under
just about any POSIX-compliant operating system,
such as Linux, QNX, UNIX, Windows, etc. and are
available in a variety of form factors, including
high-performance PLCs and cost-efficient
ruggedized industrial controllers.
• Field data servers (FDS) can be ruggedized

industrial processors available in a variety of form
factors. These universal gateways interface data
from intelligent devices, such as PLCs, Fieldbus
technologies, and RTUs into the UCOS control
system.
• All hardware is available from multiple vendors. In

fact, multiple-vendor hardware can be mixed in a
project — including multiple brands of I/O. Yet the
Figure 4 Screen Configuration configuration interface for all I/O is consistent
across all brands.
UCOS includes all the tools required to develop a project —
from logic configuration tools to HMI graphics tools. Even With UCOS, hardware requirements are dictated by the
the database is a single object-oriented file that holds tag requirements of your project, not by the control software.
definitions, graphical device objects, and hardware This balances flexibility and cost effectiveness without
configuration including network nodes, I/O subsystem compromising either. As a result, both initial control system
interfaces, and module/point configurations. This eliminates procurement costs and long-term maintenance costs are
the need to coordinate multiple files from multiple software significantly reduced.
packages.
5
Introduction
The UCOS open systems architecture also features: UCOS provides an operator interface that is easy to use.
High-resolution graphics and the familiar Windows GUI
• Microsoft Windows 2000/XP providing a reliable, simplify interactive monitoring and control. Supervisory
secure platform for the engineering and operator control of devices is consistent, regardless of device
workstations along with thousands of collateral manufacturer. In addition, security is configurable.
applications, such as spreadsheets and word processors
Since UCOS standard components offer a wide choice of
• Open data exchange via OPC, ActiveX application upgradeable features, the system provides scaleable
programming interface (API), Open Database price/performance to meet budgetary and phased
Connectivity (ODBC), and Microsoft Dynamic Data implementation requirements.
Exchange (DDE)
• Networking via satellite (VSAT), local area network

(LAN), wide area network (WAN), radio, or microwave
using TCP/IP Ethernet, Modbus, OPC, DDE, or
proprietary protocols
• Intelligent use of report-by-exception communication

schemes
• Hardware vendor independence at all levels
• Industry-standard, real-time operating system options

for the field control units (FCUs)
• The ability to import project configuration data into the

UCOS object-oriented database using Open Database
Connectivity-compliant (ODBC) applications
• The ability to export historical data for use with ODBC-

compliant applications
• Support for host-level control sequences in a true logic

controller rather than in a script language
• No requirements to change logic programming when

controllers are upgraded
• The ability to handle multiple I/O chains

simultaneously
• The ability to modify control logic without restarting or

rebooting the controller
• Highly flexible security elements that protect key

system services and enforce corporate standards
Control is accomplished via rugged I/O subsystems

comprised of proven, industry-standard components. The
architecture supports “no single point of failure” or selective
redundancy. Any component of the system – including
Operator Workstations, data servers, I/O point, I/O card,
communications network, or FCU — can be supplied in a
redundant configuration.
6
System
Components
UCOS supports several distinct, yet tightly coupled Process Historical Engineering & Operator
components: Archiver Workstations
• Engineering Workstation (EWS) for project
development
• Operator Workstation (OWS) for operator

interface
• Field Control Unit (FCU) for control logic Ethernet TCP/IP
execution and direct scanning of I/O
• microFCU for low-cost, low-power, or low-point- Field Control Unit SCADA Data Server
count applications microFCU
• I/O Subsystem supporting I/O from all industry

standard suppliers
AB I/O Modicon I/O
• SCADA Data Server (SDS) for interfacing data PLCs, RTUs, or PLC I/O_
Other Third-Party
from intelligent devices, such as PLCs, Fieldbus Devices
technologies, RTUs, PLC I/O, and other third-party GE I/O
devices Field Field Field Field Field

Devices Devices Devices Devices Devices
• Process Historical Archiver (PHA) for storing
and retrieving historical data collected by the FCU, Figure 5 System Components in Example
SDS or any other intelligent device in the system Centralized Architecture
These components are connected via VSAT, LAN, WAN,

radio, or microwave redundant or non-redundant networks
using TCP/IP Ethernet, Modbus, OPC, DDE, or proprietary
protocols.
NOTE Unless otherwise noted, in this document the term

“UCOS” is intended to mean one or more of the
above control system components.
This section describes the basic functionality and

specifications of each of these components.
7
System Components
Engineering Workstation
(EWS)
The EWS is the development tool where control schemes
are configured then downloaded to the OWS, FCU, and
SDS. The entire project is configured using a single
integrated tool based on graphical Windows standards.
The highest security level allows definition of all of the

system nodes along with the network structure. Graphical
techniques are also used to define the logical relationships
among the devices in a process area.
Figure 7 Sample User-Definable Device Logic
Project configuration begins by defining the system
architecture: workstations, field control units (FCUs), I/O, As devices are defined and placed in relationships on the
networking, etc. You simply select a component for device diagram, the system automatically generates dynamic
insertion into a graphical representation of the system graphical symbols, faceplate command windows, and alarm
architecture. displays. The supplied graphics editor can then be used to
arrange the graphical symbols, configure additional static
Graphical techniques are also used to define the logical and dynamic elements, or modify the standard symbols, thus
relationships among the control elements for multiple creating the dynamic displays for the project.
devices. You can drag-and-drop graphical representations of
device objects into a device diagram. The project development tools also support security,
grouping of command windows, logging, grouping of
alarms, generation of project documentation, and a scripting
language that allows you to customize processes and visual
effects.
Entire projects or configuration changes can be downloaded

to the operator workstations and FCUs. Changes can be
tested on the EWS before downloading to the OWS.
The EWS has the following features:
• Project configuration including network definition and

I/O selection
Figure 6 Drag-and-Drop Object Placement
• Object-oriented control logic programming
The device diagram acts as the project’s control logic,
which is subsequently downloaded to the FCU. The device • Windows 2000/XP operating system for secure, reliable
diagram includes standard devices, such as PID controllers interoperability
and transmitters, as well as user-definable devices such as
pumps, valves, and conveyors. • Tower or desktop PC
Each custom-configurable device includes many • High resolution color monitor

components: tag identifiers, defined logic schemes, and a
graphical symbol inserted from a template. The standard • System communication via single, dual, or wireless
logic of these configurable, “multi-state” devices can be TCP/IP Ethernet connection
modified and new devices can be created.
Also, graphical techniques are employed to modify or define

the logic that determines device operation.
8
The OWS has the following features:

Operator Workstation (OWS)
The OWS is used to monitor and control the process. It uses • Graphical monitoring and control screens
the project screens created during project development and • Command windows and group displays
animates them based on real-time data received from field
control units and field data servers. • Alarms, logging, and reports
• Trending and archiving
Authorized operators can monitor detailed activities for
many types of devices and send commands using standard • Device status and diagnostics
faceplate command windows and group displays. These • Real-time data exporting
displays are populated with the real-time control status of
device tags received from field control units and SCADA • Windows 2000/XP operating system for secure, reliable
data servers. Group displays may include the faceplate interoperability
command windows for multi-state devices, transmitters, and • Tower, desktop, or console-mounted, PC
controllers.
• High-resolution color monitor
• System communication via single, dual or wireless
TCP/IP Ethernet connection
Field Control Unit (FCU)

The FCU executes the control scheme configured on the EWS
and directly scans industry-standard I/O. The FCU real-time
controller runs under just about any POSIX-compliant
operating system.
The FCU provides I/O services by monitoring and

Figure 8 Command Window controlling I/O across standard networks and data highways.
The FCU can provide simultaneous support for multiple
The OWS also allows operators to display and acknowledge vendors’ I/O and I/O networks. The variety of platform and
current alarms or display historical alarms. Logs and trends form-factor options supported by the FCU allows
can be accessed by menu selection. Authorized operators incorporation of distributed, distinct I/O subsystems into
can change security status or monitor device logic as it is common control strategies.
running in the FCU. They can also monitor the hardware
through FCU, device, and rack tags that pass along Logic processing is performed by the FCU according to the
information about the health of these devices and the schemes developed during project configuration on the EWS.
connections between them. Device diagnostics show the
current status of each device tag. Device tags can be toggled The logic for a particular device is solved within one FCU
on-scan and off-scan, and current values can be overridden. or a redundant pair of FCUs. When a device is inserted into
a device diagram during project configuration, it is
The operator interface features high-resolution associated with one FCU. In effect, each device is “owned”
colorgraphics and familiar Windows GUI interaction. The by a particular FCU. That FCU solves the logic for that
Windows environment supports the display of multiple device. The FCU also sends updates of data to operator
project screens and windows. Data can be shared with other workstations using exception-based reporting or shares the
standard Windows applications via the SCADA data server. device’s data with other FCUs, if required by the control
scheme.
The OWS assumes the functionality provided by
supervisory control, HMI, or SCADA master/sub-master Exception-based reporting allows data to be widely
systems in traditional architectures. distributed without placing excessive demands on the
network’s bandwidth. Previously manned sites can be
The OWS can be displayed on a networked workstation or converted to fully automated sites because exception-based
in an Internet browser located anywhere in the world. reporting makes it technically and financially feasible to do
so.
9
System Components
Alarms are also part of the device definition and are solved The SDS has the following features:
in the FCU and reported to the operator workstation.
• Supports both serial and TCP/IP connections
The FCU features direct Ethernet network connections and • Supports off-the-shelf, industry-standard ActiveX,
standard interfaces to many specialized intelligent OPC, and DDE drivers
subsystems. • Communicates with any RS-232 compliant equipment
• Supports enabling/disabling of COM ports and polling lists
• Supports multiple ports
I/O Subsystem • Supports multi-drop slaves configuration on the RS-485
The unique flexibility of this technology supports standard, communication bus line
off-the-shelf I/O subsystems offered by a variety of • Allows creation of a poll list for each port
manufacturers.
• Supports unsolicited write
The same logic can be solved to manipulate different I/O UCOS data servers are available in configurations that
subsystems from different manufacturers without having to support low- or high-point count applications.
change any of the programming or operational parameters
of the configured system. This allows a UCOS system to
replace another control system without requiring
replacement of the I/O. In addition, when the I/O is Process Historical Archiver
replaced, no change in logic is required since UCOS logic is
hardware independent. (PHA)
Historical archiving involves copying the values of tags and
UCOS currently supports more than 40 families of I/O from other pertinent associated data, while a project is running, to
more than 20 manufacturers. an ODBC-compliant database. The values in the database
can then be manipulated, examined, queried, used for rule-
based decision making, and many other data analysis tasks.
SCADA Data Server (SDS) The system supports run-time archiving of project data to a
The SDS is a controller and data concentrator in one unit. disk file (database) that is compatible with the Microsoft
Open Database Connectivity (ODBC) standard. UCOS
It runs processes logic and directly scans supported I/O, as does supports any standard ODBC-compliant database, such as
the FCU. Microsoft SQL Server, Oracle, etc.
For devices that cannot be directly scanned by the controller, ODBC-compliant database managers, report writers, expert
the SDS offers a generalized, flexible, and user-configurable systems, custom software, and other applications are then
application designed to interface UCOS to other control used to read and manipulate the archived data. The Trend
systems, proprietary protocol drivers, or specialized software. Viewer module available in the UCOS control system is an
Software protocol drivers may be supplied by CSI or by other example of an application that reads such a database.
third-party suppliers. The protocols run as separate tasks on the
SDS and communicate to devices external to the control The PHA determines which data to save to the database
system, such as PLCs, RTUs, flow computers, intelligent valve using exception-based archiving. If the data does not
controllers, Fieldbus, etc. change, or does not change more than the user-configured
deadband, then there is no archive entry to the database.
The data exchanged with the external devices or other
software systems is then “served” to the control system As a result, exception-based archiving minimizes the amount
database so the data can be used by logic, graphics, and of data that is stored and solves the common problem of
other applications executing in the control system storing large amounts of static data. Pure exception-based
environment. Also, commands and setpoints initiated from archiving can be overridden for all tags or selected tags by
the OWS are routed to the SDS application that, in turn, configuring a minimum-write-rate variable to be a non-zero
routes them to the appropriate external application. value. Tags configured with a minimum write rate other than
zero will have their tag value archived at regular intervals,
whether or not the tag value has changed.
10
Engineering &
Process Historical Archivers
Operator Workstations
Summary
UCOS is a single product that delivers total control system
development, HMI, controller software, I/O scanning, RAID
archiving, and remote data gathering. Ethernet TCP/IP
UCOS includes all the tools needed to develop and execute Field
Devices Field Control Unit SCADA Data Server
a control project. No other software products, tools, or microFCU
Field
utilities are required. Devices
PLC I/O PLCs, RTUs, or Other PLC I/O_

Third-Party Devices
Yet UCOS is fully scaleable, easily expanded, and benefits Field
from the ability to work with a broad range of non- LAN / WAN Hub
Devices
Protocol: TCP/IP, Modbus, OPC, DDE, or Proprietary
proprietary hardware. Connection: VSAT, LAN, WAN, Radio, or Microwave
UCOS makes the best of familiar technologies and expands

on them. The next page compares and contrasts UCOS with
traditional systems to help clarify some of the unique LAN / WAN Hub LAN / WAN Hub LAN / WAN Hub
features and benefits offered by UCOS.

SCADA Data Server
Field
Devices
Figure 9 Operator
microFCU
Workstation
System Components in Example PLCs, RTUs, or Other PLC I/O_
Distributed Architecture Third-Party Devices Facility or
Field Control Unit
Facility or
Field Process 3
Devices
Field
Process 2
Devices
Figure 10 PLC I/O
System Components in Example Facility or

Process 1
SCADA Architecture
Engineering
Process Historical Archivers Operator Workstations
Workstation
Master Station
RAID
Redundant Ethernet TCP/IP
Redundant SCADA Servers LAN / WAN HUB

LAN / WAN LAN / WAN
Satellite
SCADA Data dish
Server SCADA Data Server
VSAT, LAN, WAN, TCP/IP, Modbus, OPC,

Radio, or Microwave DDE, or Proprietary
Satellite dish Dial-up Modem
Operator SCADA
Radio Data
tower Server
Workstation PLC Dial-up Modem
Field
Devices
microFCU
Field Control Unit Remote Field
RTU
I/O Subsystem Station 2 RTU Devices
Field RTU
RTU
Devices Remote Remote Stations Remote Remote
Station 1 3a and 3b Station 4 Station 5 11
System Components
UCOS Traditional Control Systems

Allows regulatory, discrete, and sequential control to be Regulatory, discrete, and sequential control are often
created with a single tool through graphical and object- configured using multiple, separate tools.
oriented software techniques. It produces the functional
equivalent of function block and rung ladder logic
programming.
Includes standard device objects and the ability to create Most systems do not have inherent support for templating
user-definable device objects, all of which are reusable, yet or starter libraries of control logic. Any reuse of logic
unique. typically requires significant manual customization.
Encompasses all project components — from control logic Multiple development tools require multiple files to store
to graphical symbols — in a single database. various types of configuration information, such as tags,
graphics, and logic.
Performs all addressing via structured tag names — no direct PLC-based systems require direct memory addresses and
memory addresses are used. complicated mnemonic naming conventions to maintain
connections among rung ladder logic programs and the
HMI software. Effectively, you must manage and
coordinate two databases of configuration information.
Non-proprietary, off-the-shelf components at all levels – Proprietary and/or single-source components are often
from workstations, to controllers, to I/O – are available required. Non-competitive sourcing makes for higher costs
from multiple vendors. Simultaneous support for multi- at all levels.
vendor I/O and competitive sourcing make for cost-
effective implementation and expansion.
OWS nodes, FCUs, I/O, devices, data servers, and Typically, the controller is a closed unit with no place to
instrumentation can be added or deleted to meet changing add cards. Sometimes minimal expansion is possible by
control system and business requirements. Multiple adding other cards in the rack holding the controller.
facilities can be connected to provide area-wide control.
Standard memory chips in the EWS, OWS, FCU, and data A new controller may need to be purchased to gain
server provide low-cost expandability. additional memory to hold new control programs or
functionality.
The EWS and OWS run industry-standard Windows Engineering and operator workstations in DCS systems
2000/XP, which offers security along with connectivity to often run some form of UNIX.
thousands of other software applications.
The FCU runs under just about any POSIX-compliant Controllers use some form of proprietary operating system
operating system, such as Linux, QNX, UNIX, Windows, (often no more than a low-level executive or task manager)
etc. which gives it the ability to run other software, and the that is typically embedded and not accessible. It has one
ability to exchange data with other software using OPC, purpose: to execute the proprietary control logic of that
DDE, ODBC, and other data sharing protocols. vendor’s system. Connectivity to third-party or custom
applications is limited or nonexistent.
Communications based on non-proprietary TCP/IP that can Frequently based on proprietary protocols that require
operate over affordable, off-the-shelf communications expensive proprietary hardware.
equipment.
Automatically incorporates report-by-exception No pre-configured communications. Engineers must
communications that maximizes network throughput. carefully program PLCs and the HMI to manage network
traffic.
12
Project
Configuration
Using an integrated, object-oriented configuration tool, a The Configure menu allows you to:
control engineer can implement complex regulatory, discrete,
and sequential control without extensive programming. • Configure device logic, tag definitions, run-time
Instead, graphical objects incorporating control capabilities graphical behavior, etc. for devices and store this device
and configured characteristics are dropped into place. This definition in a template. The template can be used to
technique is used to configure: insert multiple new device definitions into control logic,
which is called a device diagram. Each new device
• Hardware architecture including operator workstations, inherits all the characteristics of the template, yet each
field control units, individual I/O points, data servers, etc. new template-based device is unique and can be further
modified.
• Logical control relationships and physical • Create control logic that provides all control
interconnections among devices within a facility or instructions to the project’s field control units (FCUs).
process The control logic is organized by device. Each device
contains all the control logic, tag definitions, and HMI
• Logic behind user-definable devices, such as pumps, graphics associated with that device. You can then
valves, and motors arrange symbols representing each device in a device
diagram to represent the control logic of a project.
All configuration begins with the Project Configuration
editor. • Create project graphic screens using a CAD-like
drawing editor. The resulting screens can contain
dynamic objects that change color, position, shape, etc.
in response to run-time data.
• Organize command windows into group displays and
then display these groups of command windows by
name at run-time.
Run-time command windows, or faceplates, provide a
method of monitoring and controlling your process.
UCOS creates command windows automatically for
transmitters, controllers, and discrete devices.
• Configure destinations for alarm and logging messages.
• Configure Detectable Groups that can be used to

enable/disable screen object clicks.
• Define communication parameters for each workstation

that will be monitoring the Archiver.
• Specify or modify the project’s name, description, and

Figure 11 Project Configuration Editor network type.
• Perform global TCP/IP address changes.
Project architecture is configured from the Insert menu,
including workstations, FCUs, I/O, etc. • Configure F keys to show or hide screens in run-time.
13
Project Configuration
• Assign scripts to specific workstations. Scripts are menu item. A dialog box appears in which you can enter
programs written in a language specific to UCOS. configuration information. When you exit the dialog box,
Scripts can cause defined actions to take place through the new object is automatically inserted into a diagram of
pre-programmed instructions in the script itself or the architecture.
operator action.
• Customize user-defined device command windows.
Command windows can include data from multiple
devices. This data can be displayed in digital or analog
format or as trends.
• Use Dynamic Data Exchange (DDE) to pass
information between the project and any DDE-
compliant software package.
• Specify an FCU’s router address that can be used to
detect whether an FCU or its router is down.
The Security menu allows you to:
• Configure project-specific security.

• Login/logout users.
• Set login default preferences.
Other menus allow you to:
• Customize symbol graphics.

• Download projects to workstations, field control units, Figure 12 Project Configuration Editor
and field data servers after configuration.
An FCU object or an OWS/data server object can be moved
• Download updated device definitions and logic to horizontally and can be modified by double-clicking on the
FCUs without taking the project offline. object symbol or by selecting the object and choosing the
appropriate Edit menu item.
• Import and export hardware definitions.
• Print the project configuration, including the
architecture drawing, the complete hardware
configuration, control logic, and device configuration.
This section describes in detail the major functionality of

Project Configuration.
Architecture Configuration
This level of configuration allows you to name the project,
choose the type of network for the project, define the
project’s hardware components, and set up the
communication paths.
The project name and network type are specified when a

new project is created via the Project > New menu item.
Workstations, printers, field control units, and data servers

are inserted by clicking on the appropriate toolbar button or
14
Workstations, Archivers, Data Servers,

and Printers
Workstations, Process Historical Archivers, and Data
Servers require a node name, node address, and profile
name. The workstation description is optional. The
workstation profile associates a reusable set of security
definitions with the workstation.
Figure 14 FCU and I/O Hardware Definition
This dialog box is designed to allow you to view as much or

as little information as necessary and to add, change, and
delete FCU and I/O definitions.
The left side of the Hardware Definition dialog box displays

a telescoping list of all FCUs and I/O associated with the
project. The relationships among FCUs, I/O cards, channels,
chains, racks, and modules are illustrated via a tree hierarchy.
The hierarchy can be viewed by FCU or by user-defined

location within the facility.
Figure 13 Workstation Dialog Box
From the Workstation dialog box you can:
• Configure communications parameters between this

workstation and FCUs or PHAs, as well as optimize
communications over wide-area networks (WAN).
• View and modify the DDE sources, logging devices,

and alarm groups that are assigned to the workstation.
• Designate the run-time applications that will start

automatically when Run-Time is initiated.
Printers can be associated with a selected workstation and

require only a name and port designation.
Field Control Units and Associated I/O Figure 15 FCU and I/O List Organized by FCU View
FCUs and associated I/O are configured in one dialog box.
15
For example, in Figure 15 , three A-B 1771 remote I/O

racks are connected on a single length of remote I/O
communication cabling (“blue hose”). This is designated in
the figure as “Chain No. 1.” The A-B I/O cards allocated to
each rack can be assigned by selecting familiar part numbers
or by selecting the type and voltage first, which filters the
available part numbers. Throughout the setup process,
UCOS provides filters to minimize errors in the selection of
hardware settings.
Figure 18 Selected Item and Its Definition
To change a selected definition, simply modify the

information on the right side of the dialog box. Option lists
are context-sensitive. For example, when you select a
scanner for a rack, the list of scanners is limited to scanners
that are compatible with the selected baud rate. This
minimizes the opportunity for invalid or incompatible
definitions.
Figure 16 Hardware Filters for Selecting Hardware FCUs and I/O are added and deleted by selecting an item on
the left side of the dialog box and then clicking the right
UCOS allows you to create location names and specify mouse button. A menu appears at the cursor location.
locations for each FCU and each rack. This provides an
alternate way of viewing and documenting FCU and I/O
definitions.
The hierarchy tree can be expanded and contracted to show

as little or as much of the hierarchy as you choose. For
example, double-clicking on a rack in the tree displays a list
of modules associated with that rack. Double-clicking on the
rack again removes the list of modules from view.
Figure 19 Right Mouse Button Displays Action

Menu for Selected Item
Figure 17 Contracted (left) and Expanded (right)
Rack Hierarchy Tree The composition of this context-sensitive menu depends on
the selected item.
The right side of the dialog box displays a detailed
definition of the item selected in the hierarchy view. For
example, if a rack is selected on the left side of the dialog
box, the right side displays the definition of that rack.
16
The module definition shows, among other things, a list of

points available for later assignment to tags. In Figure 20
Module Definition, the first three points have already been
assigned.
Figure 20 Module Definition
I/O points are addressed via structured tag names Figure 21 Assigning points
throughout UCOS: in logic configuration on the EWS, for
operator use on the OWS, and in the FCU for logic Backup points can be assigned for any points that need
execution. This replaces the traditional method of direct backup support. A backup module is assigned to a primary
memory addresses found in PLC rung ladder logic. module. Once the first assignment is made to a backup
module, any points added to the associated primary module
Project Configuration allows you to import or export are automatically made to the backup module.
hardware definitions. A hardware definition includes the
configuration information for a workstation or an FCU. You can also assign I/O to multiple devices by using Export
Hardware definitions are exported in the *.csv file format, on the Tools menu in the Device Diagram Editor. UCOS
which means you can modify them in a third-party will sort the devices to user specifications and export the
application such as a text editor or a spreadsheet. This can devices to a file. You can then open the device files in a
decrease development time by allowing you to change third-party application and assign I/O to the devices.
hardware definitions for several components at a time,
rather than one component at a time. You can also use the Another feature of the Import/Export Devices function is
hardware import and export features to create a new project reporting. Once you export device data from UCOS, you
that is based on the hardware definitions of an existing can import that data into an application appropriate for your
project. reporting needs.
Tag names are actually assigned to I/O points in the Device

Definition Editor on a device-by-device basis. If the
appropriate FCU or I/O hardware has not yet been defined
when the point assignment must be made, you can click a
button to display the Hardware Definition dialog box.
FCU and I/O hardware can be configured, as needed, during
device configuration.
17
interactions, and determine the physical interconnections for

Device Diagram a process or facility.
Configuration
In UCOS, device diagrams represent the master control logic
programs that provide all control instructions to the project’s
field control units (FCUs).
The device diagram combines the capabilities of traditional

DCS function blocks with the sequential logic capabilities
of user-definable devices that act as a replacement for PLC
rung ladder logic. As such, regulatory, discrete, and
sequential control are created with a single tool.
Standard
Device Logic
Traditional
Function Blocks Figure 23 A Device Diagram
The following subsections provide additional details about

Replaces these and other capabilities.
Anatomy of a Device Diagram

All the basic components of a device diagram are
Configurable represented in Figure 24.
Device Logic Traditional
Rung Ladder Logic
Computing Device
()
Replaces Static Device
Control Devices
Figure 22 Relationship of Device Diagramming to

Traditional Control Programming Techniques
UCOS uses a drag-and-drop graphical interface to insert and

configure devices from a library of user-defined device
templates. These templates contain, among other things, all
the logic and functionality underlying the devices Static Devices
User-Defined
represented in the diagram. Device
Mechanical
Additionally, the ability to customize the diagram symbols Tag Data Flow
associated with devices allows device diagrams to Figure 24 Anatomy of a Device Diagram
graphically represent both logical control relationships and
physical interconnections. Figure 24 illustrates that a device diagram is composed of:
The symbols that appear on device diagrams represent • Named Devices (control, computing, static, and user-
equipment and logical control schemes. They can be connected defined)
together in a way that indicates how they interact with one
another — both logical control interactions and physical
interconnections. • Connection Lines (mechanical, static, analog end)
This makes it potentially possible to glance at a device

diagram, determine what role a device plays in control
18
UCOS Devices
Rather than requiring you to reprogram and reconfigure every
device for every project, UCOS allows you to leverage
industry standards when possible and create custom solutions
when necessary.
UCOS accomplishes this by:

Figure 25 Symbol Editor
• Supplying a wide range of pre-configured devices with
built-in functionality
The symbol editor allows you to create graphics in Project
Configuration or to import graphics from another drawing
• Allowing you to modify certain device configurations package.
and functionality
Device and Tag Names
• Allowing you to create custom devices with custom Uniqueness is enforced among devices via the device name,
functionality which is composed of a device type, a hyphen, and a device
ID:
Devices fall into the following general categories:
PUMP–3002A
• Standard control devices, such as transmitters and │ │
controllers. The functionality of each control device is │ └─ Device ID
built in and does not have to be programmed. │
└─ Device Type
Uniqueness is enforced among tag names by using the
• Standard computing devices, such as selecting
device name as a prefix and appending a period followed by
functions, limiting functions, and a calculation function.
a tag name extension:
The functionality of each computing device is built in
and does not have to be programmed, except for the PUMP–3002A.Running
calculation function, which allows you to specify a │ │ │
formula. │ │ └─ Tag Name Extension
│ │ (up to 32 characters)
│ │
• Static devices have no functional characteristics but │ └─ Device ID (up to 16 characters)
may be needed to fully represent the physical │
characteristics of the plant or process. The symbol used └─ Device Type (up to 16 characters)
to represent a static device in a device diagram can be
This enforced tag name convention allows UCOS to:
user-defined.
• Support the ISA standard approach to naming control
• User-defined devices such as pumps, valves, and loops by specifying the functionality in the device type,
conveyors. The logic, tag definitions, and symbols the loop number in the device ID, and the parameter in
associated with these devices are fully configurable. the tag name extension.
User-defined devices replace rung ladder logic.
• Support identical tag name extensions in similar devices
The symbols used to represent static and user-defined devices while preserving unique tag names via the device name
are fully configurable. UCOS supplies a wide range of pre- prefix. For example, UCOS can support several similar
drawn symbols as well as a symbol editor that can be used pump templates, each of which can be configured with
to modify existing symbols and create new ones. slightly different logic but each of which uses the same tag
name extensions to identify similar inputs and outputs.
• Support almost any other tag name convention you

need to use.
19
Device Connections For example, PID loop controllers perform an industry-

Connection lines indicate the physical and/or logical standard function that applies to control of many types of
relationships among devices (see Figure 24 ): facilities or processes.
• Mechanical lines (thick solid) are not associated with Rather than requiring you to program each controller’s
any control functionality. They do, however, serve to functionality, UCOS uses graphical techniques and fill-in-
indicate the physical interconnection among devices. the-blank forms to configure each controller device.
• Static lines (medium gray) indicate signal flow from the You enter a unique name for the new controller device, the
process to a device. FCU where the logic for the controller device is solved, the
point to which the controller device output is assigned, and a
• Tag data flow lines (dashed) indicate flow of data backup point.
among devices.
You can also modify default tag names and definitions for
Although many devices have multiple inputs, UCOS makes alarms, setpoints, commands, and other defaulted
it easy to ensure that only valid connections are made. For parameters.
example, connection types are readily visible when Device
Connection Mode is enabled and the cursor passes over a
connection point.
Figure 26 Static Connection on a Device
The type of connection is indicated by an appropriate

abbreviation. This lets you identify specific-use connection
points, such as outputs, setpoints, and variable inputs on
computing devices.
In addition, UCOS allows only valid connections. For

example, UCOS will not allow the output of one device to be
connected to the output of another device.
Emulating Traditional Drawings Figure 27 Controller Device Definitions Dialog Box

Using these basic components, a developer can use device
diagrams to represent a facility or process any number of
ways.
With the ability to customize devices and their appearance,

you can use device diagramming to emulate the design
drawings typically used to start a project, such as piping and
instrumentation drawings, mechanical flowsheets, and
electrical one-lines.
Control Devices
The underlying functional characteristics of control devices
are based on widely accepted industry standards and,
therefore, do not need to be defined.
20
Once the controller device is configured, you simply click in Computing Devices
the device diagram to indicate where the new device goes.
Most of the attributes of control devices also apply to
computing devices:
• Functionality is pre-programmed for all but the f(x)

function, which allows you to configure the formula.
• The procedure for inserting and configuring computing

devices is similar to that for control devices.
• As with control devices, computing devices have

several required and optional parameters that allow you
to customize each device.
UCOS supports the following computing devices (shown

here with the device diagram symbols):
Computing Device Diagram Symbol

User-Defined Function
Figure 28 Placing Controller in Device Diagram
This completes the configuration of one controller. Other

High Signal Select
control devices are configured using the same procedure.
It is not necessary to program the PID algorithm that defines Low Signal Select
the functionality of a controller device. The FCU software is
pre-programmed with the PID algorithm and executes it
when called to do so. The same is true of other UCOS High Signal Limit
control devices.
UCOS supports the following control devices (shown here Low Signal Limit
with the device diagram symbols):
Control Device Diagram Symbol The user-defined function f(x) allows you to specify a formula
Transmitter to be solved in the FCU. The formula supports up to three input
variables and five constants, as well as standard operators and
(Analog Input) functions.
Controller
The input variables come from tags that can be specified in
(Analog Output) either of two ways. You can enter the name of any tag for any
of the three input variables. Or, connect the output of a device
symbol in the device diagram to one of the f(x) inputs. UCOS
automatically inserts the connected tag name into the dialog
box.
21
particular type of user-defined device are defined in a

template and can include:
Before connection is made:
• The device logic executed by the FCU at run-time
• The names and characteristics of tags associated with

the device
• The symbol used to represent the device in a device

diagram (created/modified by the Symbol Editor)
• The dynamic, graphical behavior of a symbol used to

After connection is made:
represent the device in a project graphics screen at run-
time (created/modified by the Template Graphic Editor)
Figure 29 UCOS Automatically Inserts Tag Name

Device Template “PDPUMP-TEMP”
for Input Variables (on right)
Static Devices PD
PDPUMP-TEMP.Running
Static devices have no functional characteristics in the control
Device
scheme but are included to fully represent the physical Device Logic Device Tag
Diagram
Graphic
Screen
Definitions
characteristics of the plant or process. Symbol Symbol &
Dynamics
Each static device requires a name and a symbol to

represent it on the device diagram.
Figure 31 Members of User-Definable Device

Template PDPUMP-TEMP
Inserting a user-defined device into a device diagram

involves little more than specifying the template on which
the new device will be based, as in the following procedure:
1. Select the UD button from the toolbar or the User

Discrete Device menu item.
Figure 30 Insert Static Device Dialog Box
You can select one of the supplied symbols or use the

Symbol Editor from the Project Configuration window to
create a custom symbol.
User-Defined Devices: Overview Figure 32 Inserting a User-Defined Device

UCOS supplies functionality and configurations for a wide
range of user-defined devices such as pumps, valves, and
conveyors. The functionality and configuration for a
22
2. In the dialog box, select the template on which the new All the logic, tag definitions, and symbols of the template
device will be based. Enter a unique name for the new are inherited by the new device. They can be modified for
device (device type and ID). Select the FCU where the the new device without affecting the functionality and
device logic is to be solved. The diagram symbol and configuration of other devices based on the same template.
execution order are defaulted and may be changed.
For example, a device named PMP-3003 and a device
named PMP-1237 can be inserted into a device diagram in
addition to the device named PMP-1001. Each of these
devices can be based on template PDPUMP-TEMP. The
only major differences among them are the device names
and tag name prefixes, which are automatically changed to
reflect the unique device name.
Figure 33 Insert Discrete Device Dialog Box
3. Click in the device diagram to indicate where the new

device goes.
Figure 36 Device Naming Convention
At this point the logic, tag definitions, and symbols of each

device can be modified independently of one another. Each
change affects only the inserted device for which the change
is made. It does not affect other devices based on the same
template, nor does it affect subsequent devices inserted from
the same template.
Figure 34 Placing User-Defined Device in a Device
Diagram The Device Definition Editor is used to modify the
characteristics of inserted user-defined devices.
This brief procedure copies all the functionality and
configuration of the template to a new device as represented The Template Definition Editor is used to modify and create
in Figure 35 . templates. The templates supplied with UCOS can be used
as is or copied and modified to create similar templates. In
addition, new templates can be created with custom logic,
tag definitions, and symbols.
Graphic
PDPUMP-5212 Screen Creating templates is not required in UCOS. The templates
Device Logic Symbol & supplied with UCOS may provide all the functionality
Dynamics
required in a given project. Multiple new devices can be
inserted into a device diagram from each of these supplied
PD
templates.
PDPUMP-5212.Running
Device
Device Tag Diagram
Definitions Command Symbol
However, new templates may need to be created if, for
Window example, a project will use several unique pumps with
different permissives. A new template can be created for
Figure 35 Components of User-Defined Device each type of pump prior to device diagramming.
PMP-1001, One Instance of Template PDPUMP-TEMP
23
You can also export and import templates to and from another Much of the value derived from logic categorization is the
project. This feature also allows you to use a spreadsheet or near-universal applicability of these categories to any piece
database manager to further document your project. of equipment that needs discrete outputs for actuation and
control. By exposing these categories, UCOS encourages
The Import Templates dialog box allows you to select a the control engineer to configure consistent logic, which
source project from which to import a template or group of results in a system with greater integrity and ease of
templates. Once you have selected the source, simply select maintenance.
the templates from the source list, add them to the selected
list, and then import them into the target project. Although there is no difference in the type of logic created
for each category, there is a difference in the intended use of
logic for each category. This difference is more than a
convention. The logic solving software in the FCU provides
slightly different behavior for the logic in each category
with respect to the output tags associated with the logic.
Each logic category is detailed in the table on the following

page, including the general interactions of the various logic
categories.
Figure 37. Import Templates Dialog Box
The Template and Device Definition

Editors
The Template Definition Editor and the Device Definition
Editor share nearly identical functionality and are described
in the next sections as if they were one editor. Differences
are noted.
User-Defined Devices: Logic Categories

UCOS provides a structure for user-defined device logic. To
the extent that this structure exposes the base elements
required for control of a device, it is unique to UCOS.
This logic structure is based on the premise that control of most

equipment can be organized into five logic categories. These
categories describe various operational aspects of any piece of
equipment. In rung ladder logic programs, logic for each of
these categories is often written but not necessarily identified as
such. UCOS simply exposes these categories.
• Mode
• Fault
• State
• Control
• Alarm
24
Logic Intended Use FCU Execution Support

Category
Mode Mode logic defines how the device will transition into The FCU enforces mutual exclusivity per mode group.
different modes. These modes of operation (e.g. The user designates each tag in the Mode folder as part
Local/Remote, Auto/Manual) are examined during the of a mode group. The FCU allows only one tag per
execution of state logic. mode group to be set at any given instance.
Fault Fault logic describes severe abnormal conditions The first tag listed in the Fault folder is set by the FCU
associated with the device. These fault conditions (e.g. as the logical OR of all the remaining fault tags. This
very high bearing temperature) are examined during first fault tag will normally be named ANYFAULT
execution of state logic and are reported as severe and will not be driven by user-defined logic.
alarms to the user.
State State logic relates to the observable, controllable states The FCU enforces mutual exclusivity for all state tags.
of the device. State logic examines the conditions of The FCU allows only one state tag to be set at any
commands, modes, faults, setpoints, etc. to determine given instance.
the current state of the device. The current device state
is examined during execution of control logic.
Control Control logic examines conditions of states to determine Standard logic solving
the value of internal and real-world outputs. These control
outputs operate the device.
Alarm Alarm logic describes less severe abnormal conditions Standard logic solving
associated with the device. These alarm conditions
(e.g. bearing approaching high temperature) are not
necessarily examined by the other categories of logic
but are reported as alarms to the user.
User-Defined Devices: Logic Basics

The model for user-defined devices in UCOS requires that
each device be in only one state at a time, such as Starting
or Running, but not both simultaneously. Implementing this
requirement in traditional control systems can require many
rungs of ladder logic, the latching and unlatching of bits in
memory, testing and retesting, and other tedious
programming techniques to ensure that the device never
achieves multiple states simultaneously.
Figure 38 State Tab in Tag Definition Dialog Box
UCOS requires no programming and no testing to enforce
mutually exclusive states. Instead, the logic for enforcing
UCOS also enforces mutual exclusivity among mode
mutually exclusive states is pre-programmed into the FCU
groups. You associate each mode tag with a mode group,
logic-solving software.
and the FCU enforces mutual exclusivity among mode
groups.
You simply place one tag for each state onto the State tab.
That is all that is required to ensure mutual exclusivity among
state tags.
25
For example, Mode Group 1 may have an Auto and Manual User-Defined Devices: Logic
mode and Mode Group 2 may have a Local and Remote Configuration
mode. In this example, the FCU will ensure that Auto and
Manual are mutually exclusive with regard to each other and The functionality of a user-defined device is defined in the
that Local and Remote are mutually exclusive with regard to Template and Device Definition Editors.
each other.
In traditional control systems, sequential or discrete control
functionality is defined through rung ladder logic
programming. UCOS does not use rung ladder logic
programming.
Mode
Group 1 Instead, the Template and Device Definition Editors employ
Mode a graphical approach to creating object-oriented discrete
Group 2
device logic based on an adaptation of state logic concepts.
Although many of these concepts are new, the logic used to

define the functionality of a user-defined device is familiar.
Figure 39 Mode Groups
Figure 41 User-Defined Device Fault Logic illustrates a
Mutual exclusivity is an important feature designed into the typical page of logic for one category of logic, in this case fault
FCU’s logic solving software. The FCU software is also logic.
designed to handle certain conventions that are not required
but highly recommended.
For example, the FCU solves the categories of logic in a

particular order: mode, state, alarm, fault, and control. As a
consequence, you are expected to use mode and fault logic
to generate outputs which are used as inputs into state logic.
The tags resulting from state, mode, and fault logic should
then be used to drive the discrete outputs in control logic.
Alarm logic should be used only to generate messages for
operators.
Figure 41 User-Defined Device Fault Logic

Internal Tags
Alarm Logic
From the left, input tags feed data into elements such as
Real-World Tags
Alarm
logic gates, timers, and counters in the center. From these
Tags elements, the data is fed into output tags on the right.
Command Tags
Mode Logic
Control Logic
Setpoint Tags
Mode Digital
Tags State Logic Control
Tags
WildcardTags State
Tags
Fault Logic
Tags from
Other Devices Fault
Tags
Recommended Implementation
Against "Best Use" Implementation
Figure 40 Intended Use of Logic
26
UCOS supplies a default execution order that can be modified assignments for several devices at once, rather than one
for each logic element. This helps ensure that logic is device at a time.
executed as you intend.
Import and export are not designed to create new devices.
That is a task more quickly and easily accomplished with
templates. Import and export do, however, simplify the
process of making changes in a large group of existing
devices.
Most device and tag elements, with the exception of device

logic, can be modified through import and export.
Figure 42 Displaying Execution Order
User-Defined Devices: Logic Operators
Logic for each category can be placed on a single, scrollable
page or on multiple pages to aid readability. Each category of UCOS supports a wide range of standard logic operators
logic supports up to 16 pages with the Control category including logic gates, counters, timers, math operators, etc.
supporting up to 32 pages.
Figure 43 Categories of Logic
Logic elements and tags are inserted from a toolbar button

or menu item and dropped into the desired location within
the selected logic scheme.
Figure 45 Gates, Counters, Timers, and Math
When inserted into a logic scheme, some of the symbols

display small letters around the edges. These letters indicate
Figure 44 Dropping an OR Gate Into a Logic the types of inputs and outputs that can be connected at
Scheme those locations. These vary by type of logic element.
You can assign I/O to each device from the tabs in the
Device Definition Editor. You can also import and export
device definition data to and from the UCOS object-oriented
database via comma-separated (*.csv) files. You can modify Figure 46 Letters Around Symbol Edge Indicate
device and tag definitions in a third-party application, such as Type of Connection
a spreadsheet or database. This can decrease development
time by allowing you to change tag definitions and make I/O Logic operators require little if any configuration beyond the
fundamental parameters, such as presets or constant values.
27
User-Defined Devices: Tags window as a convenience to the operator; they are not
used in logic.)
I/O points are addressed via structured tag names
throughout UCOS: in logic configuration on the EWS, for • Setpoint tags (24)
operator use on the OWS, and in the FCU for logic
execution. This replaces the traditional method of direct • Command tags (10)
memory addresses found in PLC rung ladder logic. (Command tags appear as buttons on the run-time
command window of the current device; to send a
Each tag requires some definition that varies by tag type. command to the tag, the operator clicks the button.)
When inserting tags into a logic scheme, the following tag
types are available: • Digital Control tags (32)
• Internal Input/Output (data originates/stays in UCOS) • Analog Control tags (16)
• Real-World Input (data originates from field I/O for All tags (except display points) can be used as inputs in any
the device) logic category any number of times. Only compatible tags
can be inserted in each category of logic.
• Real-World Output (data sent to field I/O for the device)
• Command Input (operator initiated) Digital control tags can be used as outputs in any logic
category. But state, mode, alarm, and fault tags can be used
• Setpoint Input as outputs only in the respective logic categories.
• Wildcard Input/Output (placeholder tag to be
resolved after inserting a device on a device diagram)
• Other Device Input/Output Tag (data originates from or
is sent to another device; Device Definition Editor only)
Figure 48 Fault Logic and Tag Definitions

In Figure 48, note that the output tags in the fault logic
scheme correspond to the tag definitions on the Faults tab in
the dialog box. The tags defined on the Faults tab of the
dialog box represent a list of possible fault output tags that
can be used in the fault logic scheme. In fact, only certain
output tags are allowed in a fault logic scheme, depending
Figure 47 I/O Tags (“Other Device” Tags Appear in on whether the selection is an internal output or a real-world
the Device Definition Editor Only) output tag.
Tags are defined in a dialog box that further categorizes Tags can be defined and modified at any time while in the
them. (Numbers in parentheses indicate the maximum Template/Device Definition Editors — including while
number of tags of that type that can be defined for a given inserting a tag into a logic scheme.
device.)
All tag conventions are strictly enforced. But you do not
• State tags (16) have to remember the conventions because UCOS limits
• Mode tags (16) your choices based on the context.
• Alarm tags (16) For example, in Figure 49 , the alarm logic scheme is
• Fault tags (16) selected. When you click on the internal output toolbar
button, the resulting dialog box offers only compatible tags
• Display Point tags (16) for insertion.
(Device Definition Editor only; these are tags from other
devices displayed in the current device command
28
Figure 49 Only Compatible Tags are Available for

Insertion
Each tag definition is composed of several parameters. Each
tag must be defined with a tag name extension that must be Figure 51 Unresolved Wildcards Dialog Box
unique within the device. Other parameters specify the
logging and alarm group to which the run-time activity of a
tag is logged, the wording and color that identifies the tag in
Scripting
the device command window at run-time, security Scripting uses a programming language to initiate actions
information for selected tags, etc. The specific parameters through script commands or operator actions at run-time.
vary by tag type. You can assign a script to any workstation or to multiple
workstations, including data servers.
Wildcard tags are used in templates to represent tags that
reside in devices that you have not yet added to your Scripts allow you to customize processes and visual effects.
project. Wildcard tags allow templates to be used in many You can read and write tag values, manipulate data, save
device diagrams and projects where many devices will be and retrieve tag values, retrieve text from tags, and perform
based on the same template. You can also use wildcard tags other tasks. With scripts, you can perform tasks that logic
in devices. cannot, such as launching third-party applications and
manipulating text. You can also determine when and under
At some point during device diagramming, you must replace what circumstances scripts run.
wildcard tags with tags from actual devices. When you
double click a wildcard tag within the Device Definition Scripts can be used in any number of ways:
Editor, the Wildcard Resolution dialog box is displayed.
This dialog box enables you to assign a tag and its • Launching applications, such as Excel, Word, or Access
associated device to the wildcard tag. The procedure of
assigning a tag to a wildcard tag is known as resolving a • Placing data into a text file for import into another application
wildcard tag. which can then generate a formatted report based on that data
• Using calculations to animate or move screen objects in

a precise way
Writing a script is similar to writing a program in BASIC,
Pascal, C, or other high level languages.
A script can include the following elements:
• Statements that contain executable instructions composed of

local tags, global (device) tags, constants, and/or operators
• Comments that are ignored by UCOS but which

document the script
Figure 50 Wildcard Resolution Dialog Box
• Conditional blocks that determine whether or not a
The Report Unresolved Wildcards feature, which is part of block of statements is executed
the Device Diagram Editor, lists all the unresolved wildcard
tags in a project. This saves you the trouble of searching • Functions that return calculated values. This includes
through pages of device logic and locating the unresolved functions for performing math, time/date, string, and
wildcard tags yourself. file operations.
29
This data is entered into the Script Text Area. When the The Screen Editor and the Template Graphic Editor share
script is complete, it must be compiled. If errors are nearly identical functionality and are described in the next
encountered during the compile, they are listed in the sections as if they were one editor. Differences are noted but
Compiler Message Area along with the line numbers where both editors are referred to as “the Editor” in this section.
they occurred. Double-clicking an error message will
highlight the incorrect line in the script text area. Generally, the Editor is used to insert objects into the
drawing area, manipulate the appearance and position of the
objects, and apply run-time dynamics to the appropriate
objects. Objects can be primitive graphics (lines, rectangles,
circles, etc.), controls (buttons, check boxes, data-entry
boxes, etc.), and bitmaps. In addition, previously created
template graphics associated with specific devices can be
inserted into the drawing area.
Template Graphics
Templates define certain default device characteristics,
including logic, tag names, and graphics. When you insert a
user-defined device into a device diagram, UCOS copies the
default device characteristics from the appropriate template
to the new device. The new device will have the same logic,
tag name extensions, and graphics as the template and any
other inserted device based on that same template. These
characteristics can be changed for each inserted device.
Each UCOS template comes with a pre-configured

Figure 52 Script Editor component that specifies the run-time appearance and
dynamics of that graphic component, i.e. how that device will
After a successful compile, all tags referenced in the script look and act on a project graphic screen at run-time. You can
are listed in the Tag References area. You can then step modify this behavior and/or create new graphic components
through the script and watch how each tag value changes using the Template Graphic Editors.
line by line. This can help troubleshoot the script.
Next, you will assign when and how the script is to run.
Simply click the Add button below the Execution Conditions
Area and select the conditions under which the script will Figure 53 Pump Symbol Created in the Template
run. These conditions can be opening or closing a screen, Graphic Editor
specific changes in data, a specified length of time, starting
or closing the project, or a combination of these conditions. The graphic component you create or modify is associated
with the template.
The final step is to assign the script to a script group and
one or more workstations. As described in a previous section, device diagramming
automatically generates two symbols for each device
Graphic Editors inserted into a diagram.
The Screen Editor allows you to create the graphical user

interface, or project screens, for the project. For example, you A Device Diagram A Project Graphics
can create a control screen that displays certain pumps and Symbol Screen Symbol
valves, graphically represents their logical and/or physical
relationships, and allows you to monitor their status and send
commands to them via command windows or other means.
Figure 54 Pump Symbols for Device Diagrams and
The Template Graphic Editor allows you to create and modify Project Graphics Screens
the graphic component of templates.
30
When you insert a device into a device diagram, a diagram Bitmaps

symbol appropriate for that device appears in the device Bitmaps can be inserted into project screens or template
diagram. When you insert that device on a project graphics graphics. Although they cannot be configured with
screen, a dynamic graphic symbol appropriate for the device dynamics, you can place a transparent object over a bitmap
appears on the project screen. and configure dynamics for that object.
The remainder of this section describes in more detail Primitives

various ways to draw objects and make them perform in a Graphic primitives include such basic geometric shapes as
specific way at run-time. lines, rectangles, and circles. These basic shapes can be
combined to create more complex shapes.
Project Screen Graphics
Project screen graphics can be as elaborate or as simple as Controls
your needs require. The Editor allows you to produce a Controls are graphics that look and act like standard Windows
dynamic graphical representation of the process. You can user interface objects. They include buttons, static text, text
configure the project screen to display active process and boxes, check boxes, radio buttons, and group boxes.
instrumentation values, manually control tag values, and
dynamically illustrate the process.
Figure 56 Configurable Control Graphics
Manipulating Objects
The Editor provides basic graphics manipulation tools for
designing graphic objects and project screens. You can
Figure 55 Project Screen Created in Screen Editor select, move, resize, reshape, and rotate objects. In addition,
you can group multiple objects to make a single object to
In addition to dynamic objects, project screens can include static which you can assign dynamics. This object can be
objects such as text labels and screen navigation objects to allow duplicated as needed, maintaining its dynamic properties if
the operator to move among multiple screens within a project. you so choose. You can also align objects, make them the
(Navigation is also possible using run-time menu items.) same size, mirror, invert, or clone them individually or as a
group, and change the Z Order (front-to-back order) of
individual graphics or graphic components.
Graphic Objects
You can combine device graphics, bitmaps, graphic Static Properties
primitives, and/or control objects to create objects on
Static properties define the default appearance of an object
operator screens. Your operator screens can be simple or
at run-time. If the object is assigned no dynamic properties
complex, depending upon your needs.
that change its appearance at run-time, then static properties
define the way the object always looks at run-time.
Devices (Screen Editor only) Otherwise, static properties define the initial appearance of
You can select any user-defined device that appears in any the object before it is changed by dynamic properties. You
of the current project’s device diagrams as long as the can define the following static properties for an object:
device has a template graphic associated with it. After you
• Interior fill (color, percent of fill, and fill direction)
have selected the device, click where you want to put it in
the drawing area. • Text color, direction (vertical or horizontal), and font
• Edge color, width, and style
31
Data-Initiated Dynamic Properties An expression can be a specific value or a formula. The

formula will return a value that can vary, depending on the
Run-time data can dictate the appearance or behavior of
run-time values of the tags comprising the formula. An
objects at run-time. You can configure the following
expression can consist of device or local tag names used as
dynamic onscreen device characteristics to respond to run-
variables, operators (plus, minus, multiply, etc.), and
time data:
parentheses used to force a specific order of precedence.
• Interior fill color and percent of fill The Expression Editor creates expressions with minimal
typing for those fields that accept expressions.
• Visibility/invisibility (determined by the result of a
single expression)
• Edge color and style
• Text color
• Text value
• Rotation
• Movement
You can trigger these changes with an expression in the Figure 58 Expression Editor
dynamic properties of an object. An expression can be as
simple as a single digital tag. When the tag is TRUE the Local tags can be thought of as user-defined variables or
expression is TRUE, and the dynamic property associated constants. As such, they can be used like named constants in
with that tag is implemented. Expressions can also be more an expression, or they can be used to store user-entered data
complex and can include digital tags, analog tags, math at run-time. This data can then be used in expressions. Local
operators, or any combination of the three. tags also have specific uses with certain types of objects.
In the following illustration, each alarm tag is associated

with a different fill color, i.e. the interior color of the object.
The Percent expression is associated with a transmitter scale
value tag.
Figure 59 Local Tags Definition Box
Local Tags are categorized by type: Integer (signed long),

Float, String, and Mapped Text. Each type has associated
values and defaults that are defined when the tag is created.
Local tag values are not typically processed through a field
control unit as are device tags.
Figure 57 Dynamic Fill Tab for Run-Time Graphics

Operator-Initiated Dynamic Properties
At run-time, the object changes color depending on the You can specify an action to perform when the user clicks
prioritized list of expressions. For example, in the figure an object at run-time. The following actions can be
above, FIT-1007.HI_LIMIT has the highest priority. If both configured:
FIT-1007.HI_LIMIT and FIT-1007.LO_ALARM are
HIGH, the object will assume the color and fill assigned to • Display a command window or group display
FIT-1007.HI_LIMIT because its priority is higher than the • Change the value of tags
priority of FIT-1007.LO_ALARM in this expression.
• Show, hide, or close windows containing project screens
32
• Launch a UCOS run-time application or a third-party

application
• Run a script
Static, data-initiated, and operator-initiated properties can be

combined to allow behavior not specified above. For
example, a mouse click can change the value of a tag that
causes the fill color of an object to change. Most dynamics
assume the characteristic of the highest priority expression
that is TRUE in a list of expressions.
Changing the Color Palette

The Editor allows you to select colors from a palette of 126
colors. A default color palette is supplied with a wide range
of colors that will suit most needs. If you have specialized
needs, you can change the color palette.
Figure 60 Add/Edit Logging Device Dialog Box
Startup Screens (Screen Editor only) An alarm group consists of little more than a name for the
You can specify which screens are loaded into memory group. Then one or more alarm groups are associated with
when the project starts at run-time. This allows you to load one or more operator workstations.
only those screens that are necessary for routine operation.
If other screens are required, they can be loaded when they
are needed.
Zoom In / Zoom Out

You can change the cursor to a magnifying glass and zoom
in or out each time the left mouse button is clicked in the
drawing area. Zooming is centered on the area where the
mouse is clicked. You can click multiple times to zoom in or Figure 61 Alarm Group Configuration Dialog Box
out by multiple magnification levels.
Next, up to 16 alarm priorities are also defined. These specify
the color of alarm messages, whether or not an audible alarm is
Grid (Screen Editor only) sounded when the tag goes into alarm, and whether or not
You specify the appearance and visibility of the grid, which acknowledgment is required.
can be used to visually align objects.
Alarm and Logging

Configuration
Object-oriented techniques allow you to configure alarming
and logging with minimal effort.
First, create one or more alarm groups and/or logging

groups.
A logging group consists of a list of logging devices to be Figure 62 Alarm Priority Configuration Dialog Box
associated with that logging group. Each logging device
sends data to a printer or disk file.
33
Finally, select the alarm group, alarm priority and/or the The following table indicates which types of tags can be
logging group to be associated with each tag, as applicable. logged via which types of groups.
Alarm Logging
Tag Type Group Group
States ●
Modes ●
Alarms ● ●
Faults ● ●
Figure 63 Associating Tags with Alarm and Setpoints ●
Logging Groups
Commands ●
At run-time when activity occurs on a tag, that activity is Digital Controls
logged via that tag’s group to the appropriate workstation,
printer, and/or disk file. Analog Controls
Each alarm group, alarm priority, logging device, and logging

Tag1 Destination1
group will be defined only once in a project. However, once the
Group1 item is defined, you can create alarm and logging associations
Tag2 Destination2 for thousands of tags simply by selecting a name from a
supplied list. UCOS handles the task of matching the proper
Tag3 Destination3 workstation or logging device with each tag at run-time.
Group2
Tag4 Destination4
Figure 64 Alarm and Logging Concepts Security Configuration
UCOS provides a flexible set of security functions and easy-
As depicted in the previous figure, each tag can be to-use dialog boxes for security definitions.
associated with only one alarm group and/or one logging
group (depending on the type of tag). However, each group Certain functions are pre-defined as secure, i.e. they are
can be associated with multiple tags and/or destinations. protected from unauthorized use. For example, secure
functions include developing a project, starting or stopping a
Each group can log to any number of destinations: alarm run-time project, sending commands to a device at run-time,
groups to workstations and logging groups to printers and/or acknowledging alarms, and archiving data. Project and
disk files. security configuration are also secure functions. These
functions can be used only if the logged-in user has security
UCOS automatically creates a local logging group for each clearance to use them.
workstation in a project. Local logging groups allow you to
log station-specific activities instead of system-wide events. All run-time project graphics screens are also considered
Changing a setpoint and logging on to a workstation are secure. However, the level of security can vary from screen
examples of station-specific activities. When you assign a to screen and from workstation to workstation. A user may
logging device to a local logging group, the logging device have access to a given screen on one workstation and no
will receive only the data that belongs to the workstation it access to that same screen on a different workstation.
is associated with. Thus, a logging device that is associated
with a local logging group will not be bombarded with data Security is configured using object-oriented techniques that
from other workstations in the project. provide significant flexibility while minimizing the amount
of required configuration.
34
User Access Security Users

In order to start Project Configuration or Run-Time, a user Each security user is assigned to a security group, username,
must log in by providing the correct username and and password.
associated password.
Figure 65 Log In User Dialog Box

Figure 67 Add User Dialog Box
Security Groups
Security access is configured via security groups. Each user When a user logs in to a workstation, he or she can use any
belongs to one security group. The security group secure function that was enabled for his or her associated
determines who has access to the following tasks: security group.
• Starting and stopping a project in run-time

Auto Log Off
• Archiving data and accessing that data
Any EWS and OWS can be configured to automatically log
• Sending commands and setpoint changes off after a user-specified number of minutes of inactivity,
• Acknowledging alarms that is no keyboard or mouse activity. This adds another
• Toggling tags on and off level of security that is independent of the operator.
• Manually overriding tags in Device Diagnostics
• Developing a project Command Windows and
• Configuring security Group Displays
• Accessing project screens in run-time A project can be controlled at run-time by three types of
displays:
• Command windows
• Group displays
• Project graphics screens
Command windows are one method of monitoring and
controlling devices at run-time. They allow the operator to
monitor the real-time values of all tags associated with a device
and to send commands to a device (subject to security measures).
Group displays and project graphics screens provide two

different ways to display command windows at run-time
Figure 66 Security Groups Dialog Box and also provide additional features. For information on
project graphics screens, see “Project Screen Graphics” on
page 31 .
Workstation Profiles
Workstation profiles assign a set of security groups to each Command Windows are generated automatically by UCOS
workstation. As a result, you can customize security for for each transmitter, controller, and user-defined device
individual workstations.
35
inserted into a device diagram. You can, however,

customize command windows for user-defined devices.
Figure 71 A Graph Trend (left) and a Plot

Trend (right)
In addition to the tag set and trend window, you can determine
how to display commands and setpoints in run-time. You can
choose to place the commands and setpoints on the command
window as buttons, at either the right or left edge of the
command window. You can also choose to display commands
Figure 68. Group Display Containing One and setpoints in a menu or as both buttons and a menu.
Command Window Each for a Transmitter, a
User-Defined Device, and a Controller Command Windows can be displayed in two ways. One way
is to right-click an appropriate object on a project screen.
In Figure 69 , the command window contains several
elements added through customization. Customized
command windows allow you to include tag data for the
device with which the command window is associated, as
well as tag data from other devices. Two types of tag
elements are available for customization: tag sets and trends.
Figure 72 Selecting an Appropriate Device on a

Project Screen Displays a Command Window
Figure 69 Command Window in Run-Time Another way is to call up a group display that contains the
command window you want to see.
• Tag sets are collections of tags and tag values
displayed in a command window. Tag sets can show
tags and tag values for analog or digital tags. If you
select digital tags, you can choose to show the tags at
all times or only when the tags are HIGH.
Figure 73 Group Display Command Window Selection

Figure 70 Typical Tag Set
• Trends (plot or bar type) allow tags to be trended during Help System
run-time. Trends will show real-time data only. If you need The UCOS help system provides reference help for Project
to display archived data, use the Trend Viewer. Configuration and Run-Time.
36
Operator
Interface
The operator interface features high-resolution graphics and and functionality to the operator – even if the monitored
familiar Windows GUI interaction. devices are from different manufacturers.
The operator interface running on the OWS node: UCOS provides built in features for monitoring and
controlling your project. You don’t have to do any
• Allows operators to monitor detailed activity for many programming or interface with any other software packages
types of devices and send commands using command to get trend and alarm viewing, device and system point
windows and group displays status, command windows and animated schema from
which you can control your project. All this is automatically
• Displays optional project screens created during project configured when you design the project. The following
development and makes them dynamic based on real- figures display several OWS monitoring and control
time data displays.
• Logs alarms and other events, displays alarm and log

messages, and lets operators acknowledge alarms
• Trends real-time and historical data
• Lets authorized operators monitor and manually

override device logic
• Displays the status of communication between the

OWS and FCU, which helps the operator diagnose the
cause of communication interruptions
The OWS can also run on a field data server, allowing OWS Figure 74 Device Diagnostic – Device Points
functionality that does not include operator intervention,
such as scripting, logging, etc. In addition, the OWS can be
securely accessed using an Internet browser and Microsoft
Terminal Services.
UCOS provides operators with high-resolution

colorgraphics and the Windows graphical user interface.
Flexibility is ensured via selected operating characteristics

that are configurable at run-time. Standard features include
simultaneous display of multiple project graphics screens,
drop-down menus, and run-time configuration dialog boxes.
Figure 75 Alarm Viewer
Consistency is ensured because most monitoring and control
functions are automatically generated. For example,
command windows are generated automatically during
project configuration and present a consistent appearance
37
Operator Interface
Figure 79 Log Viewer
Figure 76 Animated Schema
Figure 80 Trend Viewer
Figure 77 Device Point Status

Figure 81 Network Diagnostics
Figure 78 Group Display
38
You can configure screen objects that are linked to the

Project Graphics Screens executable file of an application within UCOS or of a third-
Operators can display multiple project graphics screens at party application. UCOS starts the application when the
one time. Screens can be selected for display from a drop- operator clicks the appropriate screen object. Similarly, you
down menu or accessed via embedded paging objects. can configure screen objects that open or close run-time
screens.
You can use F keys to show or hide screens at run-time.
These keyboard shortcuts can be specific to each The user’s level of access to each screen is controlled by the
workstation and are set up during project configuration. security definitions entered during configuration. The levels
of screen access include no access (screen cannot be
Command windows for monitoring and controlling detailed displayed); view-only access; or full access (operator can
device parameters can be displayed at any time by clicking send commands via command windows, as defined by the
on appropriate devices. user’s security profile).
Depending on how the screens were configured, they may

display real-time data via color changes, movement,
numbers, text, etc.
GPM
Figure 82 Graphical and Device-Based Monitoring and Control Displays
39
Operator Interface
momentarily sets the tag associated with that button. If that

Command Windows and tag is used as an input in any logic scheme, then that logic is
Group Displays solved as a result of the tag being set. (You can require that
the operator confirm selected commands prior to execution
Right-clicking a device on a project graphics screen displays of the command. Also, commands are subject to security
a command window for that device. Up to 10 command measures.)
windows can be viewed in each group display. The operator
can access group displays by name via the Group Display
dialog box or by clicking an appropriately configured screen
object.
Figure 85 User-Defined Device Command Window

Showing Set Value Dialog Box – Full View
Command windows for controllers display the current

setpoint and process variable values of the device as side-
by-side bar graphs. An output bar graph shows the current
Figure 83 Group Display Dialog Box operating level of the device output on a user-defined scale.
The scroll arrows to the left of the Output graph increase or
As you select each group display, you can see which decrease the output by user-defined amounts when in
command windows are included in the group display. manual mode.
Figure 84 Group Display Showing Transmitter,

Controller, and Discrete Device Command Figure 86 Controller Command Window – Full View
Windows – Partial Views
The Setpoint button allows an operator to enter new setpoints
By default, command windows are displayed in partial view, for the control loop. The Auto/Man button allows an operator
as shown in Figure 84. In full view, additional tags associated to control the output value automatically (using a standard PID
with the device are accessible. Double-clicking on one of the algorithm) or manually. In manual mode, the Output button
setpoint tags (HiDisOrd) displays a dialog box (Set Value) allows the operator to enter a value for the output. The Dir/Rev
which allows the operator to enter a value to be sent to that button allows the operator to select direct or reverse acting
tag (See Figure 85). mode.
The command window for a user-defined device can display A trend displays the process variable.
tag sets, trends, and/or up to 10 command buttons that can
be specified by the developer. Clicking one of the buttons
40
The transmitter command window displays the current value The bottom panel displays alarms that are in alarm and have
of the device as a number and as a bar graph. The raw value been acknowledged or do not require acknowledgment.
for the device is displayed as a percentage; a setpoint tag set
displays all setpoint values. One or more alarms can be acknowledged with a single
button click.
The alarms that are displayed depend on both developer and

operator choices:
• You associate each alarm with an alarm group and then

choose which alarm groups can be displayed on each
workstation.
• Of the alarm groups that you allow to be displayed on a

given workstation, the operator can choose to display
all of those alarm groups or selected alarm groups.
The operator can also control the background color and the
order in which alarms are displayed.
These characteristics can be saved and recalled at any time

Figure 87 Transmitter Command Window – Full View on a window-by-window basis.
The ability to send commands and change values is subject The operator can display multiple Alarm Viewer windows
to security measures. each with different characteristics – different alarms,
different display order, etc.
Monitoring and
Acknowledging Alarms
The Alarm Viewer allows operators to monitor and
acknowledge alarms and to customize the appearance of the
window to suit the needs of a project or an operator’s
personal preference.
Figure 88 Alarm Viewer
The top panel in an Alarm Viewer window displays

unacknowledged alarms that are currently in alarm and
require acknowledgment and alarms that are out of alarm but
still require acknowledgment.
41
Operator Interface
will not be generated and the PHA will not store the tag’s
Archiving value. On the other hand, if the tag’s value changes by 10 or
The Process Historical Archiver (PHA) includes a complete more units, an exception will be generated and the PHA will
set of archive utilities that allow you to configure, implement, store the tag’s value. You can create more than one deadband
and monitor run-time archiving of project data to a disk file group for a project.
(database) that is compatible with the Microsoft Open Database
Connectivity (ODBC) standard. The PHA supports any At the user-defined buffer release interval, the PHA sends a
standard ODBC-compliant database that runs on Windows command that causes the buffered data to be archived to the
2000/XP, such as Sybase SQL Server (single user), Microsoft ODBC-compliant database.
SQL Server (multi-user), etc.
You can configure archiving for one or more OWS nodes in
You can then use ODBC-compliant database managers, report a project with each node handling the same or a different set
writers, expert systems, custom software, and other of archiving parameters. Archiving configuration is
applications to read and manipulate the archived data. performed on the OWS node that will actually perform the
archiving.
The Status Monitor displays real-time statistical information
about the data passing through the PHA.
Process
At run-time, the PHA filters the tags that are to be archived,
Historical
based on the user-defined configuration. Only archivable tag
changes that meet the user-defined parameters are stored in the Archiver
buffer. The user-defined parameters are described in the
following paragraphs.
If you do not specify otherwise, the PHA will use exception- Process Historical Archiver
based archiving to determine which data to store in the Filters Data
buffer. In exception-based archiving, the buffer contains data
only for user-selected tags with values that have actually
changed. Exception-based archiving eliminates unwanted Process Historical Archiver
transitional data and minimizes network traffic. Buffers Archivable Data
...
Exception-based archiving can be overridden for individual
tags or groups of tags. You can use frequency groups to
specify how often the PHA samples and stores tag values. Server Writes Archivable
Within a frequency group you can assign a minimum write Data to Database
rate and a sample rate. The minimum write rate forces the
PHA to store tag values at an assigned time interval, and the
sample rate determines how often the PHA samples tag
values. Any value greater than zero in effect disables
exception-based archiving for the affected tags. ODBC Database
For example, let’s say you create a frequency group with a

minimum write rate of 1800 seconds (30 minutes). If you ODBC-Compliant
Applications Use Data
assign a tag to that frequency group, the PHA will store the
tag’s value every 1800 seconds, regardless of whether or not
the tag’s value has changed. You can create more than one Trend
Viewer Crystal
frequency group for a project. Reports
Microsoft
You can use deadband groups to specify the sensitivity of the Access
Custom
PHA. Deadband groups define how much a tag’s value must Software Microsoft
change before an exception is generated. For example, let’s Query
Visual
say you create a deadband group with a deadband value of 10 Basic
units. If you assign a tag to that deadband group and the tag’s
value changes by only 5 units during run time, an exception Figure 89. PHA Data Transfer
42
Logging and Trending

UCOS provides extensive logging, archiving, and trending
capabilities for process history and analysis. These functions
are available online from the Run-Time Tools menu.
Log Viewer
The Log Viewer lets operators view one or more log files
produced by the logging subsystem. This subsystem logs
entries from such sources as the alarm subsystem and
operator actions. (Log files are created only if you choose to
send logable messages to one or more files. You can choose
to have each message logged to a file, to a printer, to both, Figure 91 Trend Viewer
or to neither.)
Trend Viewer can optionally plot trends for data archived to the
Any number of log files can be viewed simultaneously and any ODBC-compliant database. Since the database is ODBC-
part of a log file’s view can be copied to the clipboard or compliant, the user can also access archived data through other
printed. Log file contents can be sorted for viewing in ODBC-compliant products.
chronological or reverse chronological order.
For example, a user might use Microsoft Excel to combine
corporate data and PHA data in one spreadsheet – even
though the source data are in different locations and stored
in different types of databases.
Figure 90 Log Viewer
Trending
Operators can format and view trends for real-time or
archived data using Trend Viewer. Up to eight points can be
plotted in a single trend window with user-selectable plot
lines, sample markers, colors, grids, vertical axes, statistical
functions, delta values, buffer size, etc.
Multiple trend windows can be displayed at any one time

and the characteristics of each can be saved and recalled, as
needed.
43
Operator Interface
• Displays a user-defined list of tags and tag values from

Device Status and one or more devices and allows the user to manually
Diagnostics insert new values for selected tags
UCOS provides extensive custom and standard monitoring Any or all of these perspectives can be viewed individually
and control capabilities via command windows, group or simultaneously in multiple windows. Color changes
displays, and project graphics screens. representing control logic status and value changes are
updated dynamically in real-time.
UCOS also provides the following tools to help test and
debug running projects.
Animated logic schemes look just like the logic configured
in the Template and Device Definition Editors for user-
Device Point Status defined devices. The user can choose to display logic for
The Device Point Status utility shows the current value for any or all of the five logic categories.
each tag associated with a selected device. Values are
updated dynamically.
Figure 93 Animated Logic Schemes in Device

Diagnostics
Figure 92 Device Point Status Dialog Box
User-defined colors indicate current input and output values.
By default red indicates a discrete 0 or reset value, green
Device Diagnostics indicates a discrete 1 or set value, and blue indicates an
The Device Diagnostics utility is used to monitor logic as it analog value.
is executed in the FCU, monitor real-time tag values, and
manually override tag values. Numbers are also used to indicate current actual input and
output values: discrete 0, discrete 1, or an analog number.
The utility offers three perspectives on the FCU’s activity.
The utility: Setpoint, alarm, and fault values can be entered manually,
and commands can be sent by double-clicking an
• Uses colors and numbers to “animate” the logic for appropriate tag. Double-clicking timers, counters, and logic
user-defined devices gates displays the execution order, presets, etc.
• Displays all the tags and tag values associated with a

device and allows the user to manually insert new
values for selected tags
44
The Device Point Status window displays all the tags and
current tag values for one device. Network Diagnostics
The Network Diagnostics feature monitors the
communication status between a workstation and its
associated FCUs. It can even determine the route taken to a
destination, similar to the Tracert function in Windows. This
helps the operator diagnose the cause of a communication
failure.
Figure 94 Device Point Status in Device

Diagnostics
From this window, a tag can be taken off scan and new
values can be entered manually (subject to security
measures). These new values are inserted into the logic
stream, and the results can be viewed in the animated logic
schemes. Tags can then be put on scan. A separate dialog
can display all tags currently off scan.
Figure 97 Network Diagnostics Dialog Box
Figure 95 Off Scan Tags
The System Point Status window serves the same purpose

and offers the same functionality as the Device Point Status
window. The only difference is that the System Point Status
window allows the user to specify which tags to display.
The tags can come from multiple devices in the project. The
list can be saved and recalled later.
Figure 96 System Point Status in Device

Diagnostics
45
Operator Interface
UCOS can also request tag values from other software, if so

Connecting to Other defined during Project Configuration.
Software This makes it possible to:
UCOS is designed to share real-time and historical data
seamlessly with external systems and applications. • Create custom reports
Real-time data can be exchanged with systems external to • Perform calculations

UCOS using any of the following industry standards: • Insert real-time data into memos and other word
processor documents
• Microsoft Dynamic Data Exchange (DDE)
• View data in a format not directly supported by the
• OPC (server and/or client, optionally redundant) operator workstation
• Perform other functions via third-party or custom
• Application Programming Interface via ActiveX applications, such as PID loop tuning and expert
systems, that support one or more of these protocols
The exchange of data between UCOS and an external
system can be accomplished through the use of standard For example, UCOS exposes all process point values to
third-party protocol drivers that support the standards listed OPC via tag names. To read and/or write UCOS data, the
above. In this case, UCOS usually serves data to the third- project developer simply identifies those tags that will be
party protocol driver. The third-party driver then exchanges available for reading, writing, or both. This is accomplished
data with the external system via a serial or network through fill-in-the-blank dialogs and pop-up tag lists.
protocol.
Alternatively, if the external system supports one of the

standards listed above, then real-time data may be
exchanged directly between UCOS and the external system.
In this case, Ethernet is typically used as the physical data
communications layer and TCP/IP is typically used as the
protocol.
In addition to providing access to real time data, UCOS also Figure 98 Configuring UCOS as an OPC Server
provides access to historical archive data. The PHA uses
standard, Open Database Connectivity (ODBC)-compliant In addition, UCOS can interface with third-party servers that
relational databases to store historical process information. communicate with hardware devices. Of course, the types of
As such, standard Structured Query Language (SQL) calls functions that can be performed on UCOS data depend on
can be used to query the PHA’s database. the capabilities of the third-party or custom software
accessing the data.
Although UCOS supports a wide range of I/O with built-in
I/O drivers, support of the data exchange standards listed
above allows UCOS to exchange both real-time and
historical data with virtually any external system. UCOS
users have access to a large library of standard DDE, OPC,
and ActiveX protocol drivers available from hardware
manufacturers or third-parties. These proven protocol
drivers provide read-write access to UCOS process data.
In addition, the support of these standards allows UCOS

users to exchange data with a large selection of third-party
software that is DDE-, OPC-, ActiveX-, and/or ODBC-
compliant.
46
Communicating
with Field Devices
Real-time information and device control status are stored in

Field Control Unit (FCU) the FCU’s logic solver. Data updates are reported by
The FCU is a PLC or personal computer that runs under just exception. This frees the system from the scan rate
about any POSIX-compliant operating system, such as limitations that can affect real-time processing and reporting
Linux, QNX, UNIX, Windows, etc. The controller software of data at the operator workstation. It also minimizes
executes sequential and regulatory control schemes that are network traffic allowing FCUs to be located remotely.
downloaded from the engineering workstation. It also
provides real-time scanning and control of remote I/O. The following figure shows the flow of data from project
configuration to the FCU and OWS. The project is
UCOS supports selective redundancy at all levels, including downloaded to the FCU, then to the OWS. The FCU solves
redundant FCUs and redundant I/O points. the logic internally and sends the data to the I/O network.
Each FCU is directly connected to the same network as the

Field Control
engineering and operator workstations. Flash disks, non- Unit A
volatile memory, and an optional internal backup power
Project
supply help ensure continuous processing. Operator Configuration
Workstation
At run-time, the FCU software:
• Receives commands and data from one or more Field Control

Communications Unit B
operator workstations and/or one or more input/output Services
interfaces that communicate with field devices (e.g.
pumps, valves, etc.)
Logic Solver Device Object
• Processes and solves in real-time all logic generated Logic
during the project development phase
• Communicates the results to the operator workstation I/O Scanner
and/or input/output interfaces
Logic processing is performed by the FCU according to the I/O Interface

schemes developed during project configuration on the
EWS. The processing is completely event-based. Every (FCU components)
device configured in a device diagram is represented in a
I/O Network
device table residing on the appropriate FCU. All the logical Configurable Information
Device Object Data
relationships are represented in a device-specific event list Flow at Run-Time Download/Update
that logically relates source (occurrence) and destination
(triggered response) events. Figure 99 FCU Controller Subsystem
When an event occurs at run-time, the logic processing The FCU provides significant support for the unique logic
engine uses the appropriate event list to determine what categories used by UCOS. For example, mutual exclusivity
action (if any) to execute. That action may, in turn, trigger of device states is enforced by the FCU. The developer does
other events and actions. The real-time executive ensures that not need to write code to support mutual exclusivity of
critical control functions take precedence over other device states.
operations, and that logic is executed in the correct sequence.
47
Communicating with Field Devices
Standard vendor-manufactured I/O scanner cards are

plugged directly into the FCU. These cards provide access SCADA Data Server (SDS)
to I/O networks, which are scanned directly by the FCU. The SDS can communicate with devices that cannot be
directly scanned by the FCU.
UCOS supports multiple vendor I/O subsystems at all
levels. A variety of distributed I/O networks can be The SDS is a generalized, flexible, and user-configurable
accommodated in the same or different FCUs. application designed to interface UCOS to other control
systems, proprietary protocol drivers, or specialized software.
The FCU supports all required distributed control Software protocol drivers may be supplied by CSI or by
functionality, including: other third-party suppliers. The protocols run as separate
tasks on the SDS and communicate to devices external to
• Control scheme execution the control system, such as PLCs, RTUs, flow computers,
intelligent valve controllers, Fieldbus, etc.
• Data acquisition and calculation
The data exchanged with the external devices or other
• Regulatory, discrete, and sequential control software systems is then “served” to the control system
database so the data can be used by logic, graphics, and
• Interlocking other applications executing in the control system
environment. Also, commands and setpoints initiated from
• Event-initiated processing the OWS are routed to the SDS application that, in turn,
routes them to the appropriate external application.
• I/O scanning
The SDS has the following features:
• Industry-standard, POSIX-compliant operating system
• System communication via single or dual wireless • Supports both serial and TCP/IP connections
TCP/IP Ethernet connection • Supports off-the-shelf, industry-standard ActiveX,
DDE, and OPC drivers
• Direct scanning of I/O
• Communicates with any RS-232 compliant equipment
• Supports enabling/disabling of COM ports and polling

lists
• Supports multiple ports
• Supports multi-drop slaves configuration on the RS-485

communication bus line
• Allows creation of a poll list for each port
• Supports unsolicited write
• Includes an FCU and data concentrator in one unit
• Can be supplied in a redundant, low-, or high-point-

count configurations
48
About Control Systems

International (CSI)
UCOS is just one of the open systems solutions from Control component. More importantly, you are assured that your
Systems International, Inc. (CSI), a leading suppliers of solution can continue to evolve as technology advances.
industrial automation systems since 1968.
CSI – delivering the best value in integrated, open process
For more than 35 years, demanding industries have relied on automation and information management systems.
CSI for automation and instrumentation solutions. Our
primary strength and value for your project is our ability to Procure/
design and implement total, cost-effective automation Approve
Configure/Test
systems – and to plan and manage large, turnkey projects.
Founded in 1968, CSI pioneered the application of Design & Automation Install
microprocessor and networking technology to real-time Document Project & Start-up
control problems. By the end of the 70s, we were supplying Life Cycle
complete distributed control systems for plant control and Accept
information management. By the mid-80s, CSI was serving Define System Train/Support
the demanding petrochemical industry with innovative Requirements Maintain
solutions for total facility and distribution system
automation.
Today, CSI is a global presence, offering comprehensive

control and instrumentation solutions for a broad range of
industries and applications, from water/wastewater
management to the distribution of fuel and other bulk liquids.
Our technical depth and specific industry experience
complement your knowledge of your business. CSI's
solutions – such as UCOS – are designed to meet your
specified standards for performance and ease of use,
maintenance, and expansion. With hundreds of systems
installed worldwide, CSI's track record of success speaks for
itself.
But these aren't the only reasons you should consider CSI
for your next automation project. Unlike other suppliers of
"total system" or "one stop shop" solutions, CSI does not
manufacture hardware platforms or I/O subsystems. Our
solutions are always designed to conform to open systems
standards.
So, you are not tied to a single vendor for spare parts and
service. Our engineers and software specialists are
experienced with many types of open, compatible
equipment that can enhance your core solution. You don't
have to settle for a second-best or less cost-effective
49
About Control Systems International (CSI)
Notice
All procedures, data, information, drawings, specifications or other
material, whether accompanying this document or separately
supplied in furtherance of this document, contain confidential and
proprietary information which (i) is the property of Control
Systems International, Inc. (“CSI”), (ii) is disclosed by CSI only in
confidence, and (iii) except as CSI may otherwise permit in
writing, is to be used, disclosed or copied only to the extent
necessary for the evaluation and use thereof by the recipient. The
foregoing shall not apply to any such material to the extent that the
contents (i) are now or subsequently become available to the public
without payment, (ii) were previously known to the recipient, or
(iii) subsequently become otherwise known to the recipient without
restriction.
This document is based on information available at the time of its

publication. While efforts have been made to be accurate, the
information contained herein does not purport to cover all details
or variations in hardware and software, nor to provide for every
possible contingency in connection with installation, operation and
maintenance.
CSI makes no representation or warranty, either expressed or

implied, with respect to, and assumes no responsibility for, the
accuracy, completeness, or sufficiency of the information
contained herein. No warranties of merchantability or fitness for a
particular purpose shall apply.
This document takes precedence over and supersedes in their

entirety all previous versions or revisions.
VXL, FUEL-FACS, FUEL-FACS+, UCOS, and the CSI logo are

registered marks of Control Systems International, Inc. Control
Systems International and CSI are trademarks of Control Systems
International, Inc. UCOS U.S. Pat. 5,812,394.
All other product and company names/logos mentioned in this

document are trademarks and/or registered trademarks of their
respective holders.
Copyright © Control Systems International, Inc. 2005.

All Rights Reserved.
8040 Nieman Road, Lenexa, KS 66214-1523
Telephone: 1-913-599-5010 Facsimile: 1-913-599-5013
http://www.csiks.com
CSI Document No. K-9506-PTS-1-MKTG-11072005-MJK
CSI Form No. K-9906-DOT-6-MKTG-23081999-MJK-R02
50
NOTES
51
About Control Systems International (CSI)
NOTES
52

CSIKS

Uploaded by

Copyright:

Available Formats

CSIKS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSIKS

Uploaded by

Copyright:

Available Formats

UCOS® Functional Overview

The product’s most important features include the ability to:

UCOS employs object-oriented technology to replace

Although UCOS includes a wide range of standard control

User-configurable devices and the reusable templates on

For example, device objects are dropped into logical and/or

As a result, the UCOS object-oriented, hybrid approach to

• More flexibility and control than DCS, PLC/HMI,

• Significant reductions in the engineering time

• Enforced consistency within and among projects

• Ease of expansion and maintenance

UCOS also provides automatically generated alarms, Open System Features

• Real-time field control units (FCU) directly scan

• Field data servers (FDS) can be ruggedized

• All hardware is available from multiple vendors. In

• Networking via satellite (VSAT), local area network

• Intelligent use of report-by-exception communication

• Hardware vendor independence at all levels

• Industry-standard, real-time operating system options

• The ability to import project configuration data into the

• The ability to export historical data for use with ODBC-

• Support for host-level control sequences in a true logic

• No requirements to change logic programming when

• The ability to handle multiple I/O chains

• The ability to modify control logic without restarting or

• Highly flexible security elements that protect key

Control is accomplished via rugged I/O subsystems

• Operator Workstation (OWS) for operator

• Field Control Unit (FCU) for control logic Ethernet TCP/IP

execution and direct scanning of I/O

• I/O Subsystem supporting I/O from all industry

devices Field Field Field Field Field

These components are connected via VSAT, LAN, WAN,

NOTE Unless otherwise noted, in this document the term

This section describes the basic functionality and

The highest security level allows definition of all of the

Entire projects or configuration changes can be downloaded

The EWS has the following features:

• Project configuration including network definition and

Each custom-configurable device includes many • High resolution color monitor

Also, graphical techniques are employed to modify or define

The OWS has the following features:

Field Control Unit (FCU)

The FCU provides I/O services by monitoring and

archiving, and remote data gathering. Ethernet TCP/IP

PLC I/O PLCs, RTUs, or Other PLC I/O_

UCOS makes the best of familiar technologies and expands

features and benefits offered by UCOS.

Figure 10 PLC I/O

System Components in Example Facility or

Redundant SCADA Servers LAN / WAN HUB

VSAT, LAN, WAN, TCP/IP, Modbus, OPC,

Satellite dish Dial-up Modem

UCOS Traditional Control Systems

• Configure destinations for alarm and logging messages.

• Configure Detectable Groups that can be used to

• Define communication parameters for each workstation

• Specify or modify the project’s name, description, and

The Security menu allows you to: