AdvaBuild®

Engineering Methods User Guide

Version 3.7

Power and productivity

TM
for a better world
 AdvaBuild®
Engineering Methods User Guide

Version 3.7
NOTICE
This document contains information about one or more ABB products and may include a
description of or a reference to one or more standards that may be generally relevant to
the ABB products. The presence of any such description of a standard or reference to a
standard is not a representation that all of the ABB products referenced in this document
support all of the features of the described or referenced standard. In order to determine
the specific features supported by a particular ABB product, the reader should consult the
product specifications for the particular ABB product.

ABB may have one or more patents or pending patent applications protecting the intel-
lectual property in the ABB products described in this document.

The information in this document is subject to change without notice and should not be
construed as a commitment by ABB. ABB assumes no responsibility for any errors that
may appear in this document.

In no event shall ABB be liable for direct, indirect, special, incidental or consequential
damages of any nature or kind arising from the use of this document, nor shall ABB be
liable for incidental or consequential damages arising from use of any software or hard-
ware described in this document.

This document and parts thereof must not be reproduced or copied without written per-
mission from ABB, and the contents thereof must not be imparted to a third party nor used
for any unauthorized purpose.

The software or hardware described in this document is furnished under a license and
may be used, copied, or disclosed only in accordance with the terms of such license. This
product meets the requirements specified in EMC Directive 2004/108/EEC and in Low
Voltage Directive 2006/95/EEC.

TRADEMARKS
All rights to copyrights, registered trademarks, and trademarks reside with their respec-
tive owners.

Copyright © 2001-2013 by ABB.

All rights reserved.

Release: June 2013

Document number: 3BUR002120R3701
 TABLE OF CONTENTS

About This Book

General ............................................................................................................................13
Use of Warning, Caution, Information, and Tip ..............................................................14
Document Conventions ...................................................................................................15
Terminology.....................................................................................................................16
Related Documentation ...................................................................................................17

Section 1 - Introduction
Product Overview ............................................................................................................19
The Project Structure............................................................................................20
Control Structure..................................................................................................20
Object-types in the Control Structure .................................................22
Designation Of Objects in the Control Structure ................................23
Prerequisites and Requirements ......................................................................................24

Section 2 - Basic Engineering and Design

Overview..........................................................................................................................25
Inserting/Opening a Project .............................................................................................25
Basic Configuration of the Control Database..................................................................26
Rules for Multi-user Engineering ....................................................................................26
Multi-user Engineering in Administration Component .......................................27
Concurrence Of Conflicting Administration Functions ......................27
Multi-user Engineering in Template Builder .......................................................30
Guidelines for Using Multiple Configurators..................................................................30
Implementing Multiple CDPs for First Time .......................................................31
Plan Each Database .............................................................................31

3BUR002120R3701 5
Table of Contents

Configure each Database .................................................................... 32

Integrate all CDPs for First Time........................................................ 32
Adding new CDP to Existing Multiple CDP System .......................................... 33
Changing Export List for CDP ............................................................................ 34
Making CDPs Compatible ................................................................................... 34
Guidelines for Establishing Domains in Database .............................................. 35
Database Attributes Related to Multiple Configurator ........................................ 35
Configuration Area and Message Routing.......................................... 35
Console Library Configurator............................................................. 35
Exporting Database References ........................................................................... 36
Creating an Export File....................................................................... 37
Exporting the Files.............................................................................. 37
Compiler Considerations for Using Multiple Configurators ............................... 37
Installer Considerations for Using Multiple Configurators ................................. 38
Considerations for Program Downloads .............................................................. 38
Considerations for Database Reports................................................................... 38
Considerations for Using TCL............................................................................. 38
Considerations for Using Console Configurator.................................................. 38
Alarm and Event Processing ........................................................................................... 39
Alarm/Event Detection and Notification ............................................................. 40
Alarm/Event Logging ......................................................................................... 40
How to Configure Alarm/Event Loggers............................................................. 41
How to Configure Alarms for Continuous Loops................................................ 42
Alarm Deadband ................................................................................. 42
General Loop-level Alarm Parameters ............................................... 42
Alarm Priority ..................................................................................... 43
How to Configure Alarms for Device Loops....................................................... 43
General Alarm Parameters.................................................................. 44
Alarm Priority ..................................................................................... 44
How to Configure Historical Recording .............................................................. 45
Ringback ............................................................................................................ 45
Fetch Alarm Target .............................................................................................. 45

6 3BUR002120R3701
 Table of Contents

Alarm/Event Handling by other Applications......................................................46

Alarm/Event Handling for Report Services .........................................................49
Alarm/Event Handling for TCL ...........................................................................49
Unit Message Display .........................................................................49
Database Access of Alarm Parameters................................................49
SETEVENT Statement........................................................................49
UPDATEON and UPDATEOFF Statements .......................................49
Alarm/Event Handling for Display Builder .........................................................50
Alarm/Event Handling for Instrument Interface ..................................................50
Alarm/Event Handling for Computer Interface ...................................................50
Alarm Contacts on SIM Module .....................................................................................50
System Users ........................................................................................................51
Establishing System Users ...................................................................................51
Assigning Operator, Supervisor, and Engineer Tasks ..........................................52
Assigning Configurator User Tasks .....................................................................56
Generating Database Cross Reference Reports ...............................................................57

Section 3 - Database Reference for Objects

Scope ..............................................................................................................................59
Control Structure Database Hierarchy.............................................................................59
Database Objects .............................................................................................................71
Top Level Objects............................................................................................................71
MOD_DB Object .................................................................................................72
DATA BASE OWNERS Field.............................................................72
AREA Object .......................................................................................................74
AREA EDITORS Field.......................................................................75
MESSAGE CTR, MESSAGE TYPE, and REMOTE TYPE Fields ...75
Message Center Entries for Alarm/Event Loggers .............................77
Message Center Entries for Historical Services..................................77
DEV_DIR and DEV_DESC Objects ...................................................................78
GENERICD and Related Objects....................................................................................80
GENERICD Object ..............................................................................................84
PHYSICAL DEVICE Field ................................................................84

3BUR002120R3701 7
Table of Contents

AUTO START Field ........................................................................... 85

SOFTWARE NAME Field.................................................................. 86
DO RATE Field .................................................................................. 87
SECONDARY DP, BACKUP ENABLE, and BACKUP OVERRIDE
Fields ............................................................................ 87
DEFAULT ENVIRONMENT Field.................................................... 88
NODE TYPE Field ............................................................................. 88
MODUSERS Object ............................................................................................ 89
USER ID Field.................................................................................... 90
PASSWORD Field.............................................................................. 90
ACCESS CLASS Field....................................................................... 90
SEC DEV Field................................................................................... 90
AUTO LOG Field ............................................................................... 91
EXPORT or EXPORT TO DEVICES ................................................ 91
CONSLIB Object................................................................................................. 92
PACKAGE NAME Field .................................................................... 93
DISPLAY ID Field.............................................................................. 93
DEVICE NAME Field ........................................................................ 93
NUMBER OF ARGUMENTS Field .................................................. 93
MSG_ROUT Object ............................................................................................ 93
MESSAGE CTR and MESSAGE TYPE Fields ................................. 95
REMOTE TYPE Field ........................................................................ 95
PORTS Object...................................................................................................... 95
NUM Field ...................................................................................... 96
PORT NAME Field............................................................................. 96
TYPE Field ...................................................................................... 97
CRT Field ...................................................................................... 97
SPEED Field ...................................................................................... 98
WD Field ...................................................................................... 98
PARITY Field ..................................................................................... 98
STOP Field ...................................................................................... 98
ITO Field ...................................................................................... 99

8 3BUR002120R3701
 Table of Contents

OTO Field ......................................................................................99

TERM CHR Field ...............................................................................99
BUF SZ Field ......................................................................................99
Entries to Fields of PORTS Object for Interfaces ...............................99
Entries to Fields of PORTS Object for Keyboards, Operator Control
Panels, and Page Selector Alarm Panels (PSAPs)......100
Entries to Fields of PORTS Oject for Touchscreens .........................100
Entries to Fields of PORTS Object for Printers ................................100
Entries to Fields of PORTS Object for Security Key........................101
Entries to Fields of PORTS Object for Programmable Logic Controllers
(PLCs).........................................................................103
Entries to Fields of PORTS Object for Smart Devices .....................103
LOG_DETL Object............................................................................................104
TEMPLET NAME ............................................................................105
LOGGER DESCRIPTION................................................................105
BACKUP LOGGER NAME .............................................................105
PRINTER NAME .............................................................................105
BACKUP PRINTER NAME.............................................................106
MAX # MSGS ON DISK .................................................................106
MAX # MSGS IN MEMORY...........................................................106
STD ALARM COLOR .....................................................................106
STD ALARMS PRINTED................................................................107
STD PRINT TYPE............................................................................107
TRIP LIMIT HIGH ...........................................................................107
TRIP LIMIT HIGH HIGH ................................................................108
EVENT COLOR ...............................................................................108
EVENTS PRINTED..........................................................................108
EVENT PRINT TYPE ......................................................................109
HP ALARM COLOR........................................................................109
HP ALARMS PRINTED ..................................................................109
HP PRINT TYPE ..............................................................................110
MED ALARM COLOR ....................................................................110
MED ALARMS PRINTED ..............................................................110

3BUR002120R3701 9
Table of Contents

MED PRINT TYPE .......................................................................... 111

CONSOLE-Related Objects.......................................................................................... 112
CONSOLE Object ............................................................................................. 113
PHYSICAL DEVICE ....................................................................... 113
SOFTWARE NAME......................................................................... 114
AUTO START................................................................................... 114
DEFAULT ENVIRONMENT ........................................................... 114
Controller and Related Objects ..................................................................................... 115
CONT_SS Object .............................................................................................. 117
PHYSICAL DEVICE ....................................................................... 117
REDUNDANCY OPTION ............................................................... 118
CNTRLLER Object ........................................................................................... 119
PHYSICAL DEVICE ....................................................................... 119
SOFTWARE NAME Field................................................................ 120
AUTO START................................................................................... 121
BACKUP ON STARTUP.................................................................. 122
MAX DATA BASE SIZE ................................................................. 122
DO RATE .................................................................................... 123
Serial Ports for Controllers ............................................................... 123
Manual/Auto Operator Station.......................................................... 124
Local Control Panel Plus (LCP+) ..................................................... 124
Programmable Logic Controllers (PLCs) ......................................... 124
Smart Devices ................................................................................... 125
CCF-Related Objects .................................................................................................... 125
TLL-Related Objects..................................................................................................... 126
Remote I/O-Related Objects ......................................................................................... 127
AC410 Object................................................................................................................ 128
AC460 Objects .............................................................................................................. 129
S100 I/O Objects ........................................................................................................... 129
S800 I/O Objects ........................................................................................................... 130
MVI-Related Objects .................................................................................................... 131
PLC-Related Objects..................................................................................................... 132

10 3BUR002120R3701
 Table of Contents

Profibus I/O-Related Objects.........................................................................................132

Appendix A - Group Routing For Alarms

The Bugs Utility ............................................................................................................134
Starting the Bugs Utility in Advant HPUX platform .........................................134
Starting the Bugs Utility in AdvaBuild Windows platform ...............................136
Create the Group Routing File ......................................................................................137
Insert Records in the Group Routing File......................................................................137
Reviewing the Group Routing File................................................................................140
Removing a Record .......................................................................................................141
Install Report Messages.................................................................................................142
Bugs File Editor Commands .........................................................................................143

INDEX

3BUR002120R3701 11
Table of Contents

12 3BUR002120R3701
 About This Book

General
This book describes methods for plant engineering for these AdvaBuild® software
packages:
• AdvaBuild Control Builder
– Template Builder
– On-line Builder
• AdvaBuild Optional Software
– TCL Builder
– TLL Builder
AdvaBuild software is an extension of the Computer Aided Plant Engineering
(CAPE) concept with tools for DCS database configuration. These software
packages support the following project engineering functions:
• Configuration of the Advant® OCS control database
• Plant documentation
• Development and revision control for TCL sequences and recipes
The AdvaBuild software packages support an object-oriented method of system
engineering. This book describes the principles of object-oriented engineering, and
provides guidelines for object-oriented engineering with AdvaBuild.
Use this book as a guide and reference source for project engineering. Instructions
for using the various builders are provided in their respective user’s guides as
described in Related Documentation on page 17. This book is not intended to be the
sole source of instruction for project engineering. It is recommended that those

3BUR002120R3701 13
Use of Warning, Caution, Information, and Tip

people involved in project engineering attend the applicable system engineering

courses offered by ABB.
Use this section as a guide to the conventions and terminology used throughout this
book. For a list of documentation related to the product described in this book, see
Related Documentation on page 17.

Use of Warning, Caution, Information, and Tip

This publication includes Warning, Caution, and Information where appropriate
to point out safety related or other important information. It also includes Tip to
point out useful hints to the reader. The corresponding symbols should be
interpreted as follows:
Warning indicates the presence of a hazard which could result in
personal injury.

Caution indicates important information or warning related to the

concept discussed in the text. It might indicate the presence of a
hazard which could result in corruption of software or damage to
equipment/property.
Information alerts the reader to pertinent facts and conditions.

Tip indicates advice on, for example, how to design your project or
how to use a certain function.

Although Warning hazards are related to personal injury, and Caution hazards are
associated with equipment or property damage, it should be understood that
operation of damaged equipment could, under certain operational conditions, result
in degraded process performance leading to personal injury or death. Therefore,
comply fully with all Warning and Caution notices.

14 3BUR002120R3701
 Document Conventions

Document Conventions
The following conventions are used for the presentation of material:
• The words in names of screen elements (for example, the title in the title bar of
a window, the label for a field of a dialog box) are initially capitalized.
• Capital letters are used for the name of a keyboard key if it is labeled on the
keyboard. For example, press the ENTER key.
• Lowercase letters are used for the name of a keyboard key that is not labeled on
the keyboard. For example, the space bar, comma key, and so on.
• Press CTRL+C indicates that you must hold down the CTRL key while
pressing the C key (to copy a selected object in this case).
• The names of push and toggle buttons are boldfaced. For example, click OK.
• The names of menus and menu items are boldfaced. For example, the File
menu.
– The following convention is used for menu operations: MenuName >
MenuItem > CascadedMenuItem. For example: choose File > New >
Type.
– The Start menu name always refers to the Start menu on the Windows
Task Bar.
• System prompts/messages are shown in the Courier font, and user
responses/input are in the boldfaced Courier font. For example, if you enter a
value out of range, the following message is displayed:
Entered value is not valid. The value must be 0 to30.
You may be told to enter the string TIC132 in a field. The string is shown as
follows in the procedure:
TIC132
Variables are shown using lowercase letters.
sequence name

3BUR002120R3701 15
Terminology

Terminology
The following is a list of terms associated with object-oriented database
configuration that you should be familiar with. The list contains terms and
abbreviations that are unique to ABB or have a usage or definition that is different
from standard industry usage.

Term Description
Configurator Data HP-UX Advant, Multibus, or Windows-based subsystem
Processor (CDP) that contains a configurator.
Object An object is a logical representation of functions, plant
equipment, a location, documentation, or software
function in the project database. For instance:
• a PROJECT object represents a complete project
• a GENERICD object represents a subsystem in the
Advant OCS
• a PID object represents a PID algorithm
Parent/Child A child and its siblings are hierarchically under a parent
object from a subtree.
Root The object of type PROJECT is the top level object in the
project database. This object stores information for
project administration such as user names, project size,
and so on. Initially this object is the root. Most objects
can be set as a temporary root to facilitate navigation in
the project hierarchy.
Subtree Part of a tree, for example a subplant underneath a
PROJECT.
TLB TLL Builder
TLL Taylor Ladder Logic
Tree The project database is organized as a hierarchy of
objects related by parent-child relationships.

16 3BUR002120R3701
 Related Documentation

Related Documentation
This book is one in a series of books for the AdvaBuild software. The other books
are listed in Table 1.

Table 1. Related Documentation

Category Title Description

System Microsoft Windows Administrator’s Install, uninstall, administration, and
Administration Guide registry of Windows operating system.
AdvaBuild Administrator’s Guide Installation and project administration for
AdvaBuild suite of software products.
AdvaBuild Release Notes Information regarding upgrades and
changes that are not described in this
book.
PU410/PU412 RTA Unit User Guide Installation and technical instructions for
the external RTA unit.
Software AdvaBuild Control Builder User’s Guide Consult this book for instructions on how
to:
• operate the various builders
(Control and Template Builders) to
configure the MOD 300 database
• compile, install, download, and
decompile the database
• transfer data between the various
database configuration platforms
Options AdvaBuild TCL Builder User’s Guide This book describes how to generate
and manage TCL programs via the TCL
Builder.
AdvaBuild TLL Builder User’s Guide This book describes how to generate
and manage TLL segment files via the
TLL Builder.

3BUR002120R3701 17
Related Documentation

After you install the AdvaBuild documentation, you can access it from the Windows
task bar by choosing Start > ABB Industrial IT > Control IT > AdvaBuild >
Documentation > Document.

18 3BUR002120R3701
 Section 1 Introduction

Product Overview
The principle of engineering with AdvaBuild software is to build a data model for a
project that represents the control database. Using AdvaBuild software, you build a
tree-like hierarchy of objects, Figure 1, and configure object attributes to meet the
requirements of the project.

Figure 1. Project Structure Represented as Hierarchy Tree of Objects

3BUR002120R3701 19
The Project Structure Section 1 Introduction

The Project Structure

The PROJECT object is the top (root) of the project structure. This object contains
the administrative parameters for the project such as user IDs and user access levels.
These are established when the project is created via the AdvaBuild Administration
component.
The control structure is represented as a MOD_DB (Advant OCS Database) object
under the PROJECT object. Control structure objects represent the physical and
functional characteristics of the control system. For instance, there are objects that
represent Advant Stations, Controller Subsystems, control modules, control loops,
and so on.
Objects in the control structure are related by parent-child relationships. For
instance, a control loop is a child of a Configurable Control Function (CCF) object,
which in turn is a child of a control module object. These parent-child relationships
are established automatically as you insert objects in the project. The AdvaBuild
Control Builder software has built-in checks so that you cannot inadvertently
establish an invalid relationship between objects.

Control Structure
The control structure is where you define the control database for the Advant OCS,
Figure 2.

20 3BUR002120R3701
Section 1 Introduction Control Structure

MOD_DB object is
top of hierarchical
tree structure

AREA object
represents an
area in the
Advant OCS

GENERICD objects
represent subsystems
in an area

These objects define

functionality of the
subsystem

CONSOLE objects
represent subsystems
in an area

Figure 2. Example of Control Structure

3BUR002120R3701 21
Control Structure Section 1 Introduction

Object-types in the Control Structure

Control structure objects are organized into six basic levels as described in Table 2.
The MOD_DB object is the top of the control structure for a specific database. This
object is a child of the PROJECT object.
The Advant OCS database can be partitioned into configuration areas. A
configuration area is a group of related subsystems. Configuration areas are
represented as subtrees below the MOD_DB object. Each subsystem under a
configuration area forms another level of subtrees. The objects under each
subsystem establish the functionality and operating characteristics of that
subsystem.
For example, Figure 2 shows a database with one configuration area consisting of
one CONSOLE and one GENERICD subsystems. The GENERICD object type
establishes a Multibus-based Subsystem in the Advant OCS database. The objects
below the GENERICD object indicate what functions are supported by it. For
instance, the CI object (COMP_INTRFC) is for a computer interface, CCF is for the
Configurable Control Functions application software package, PORTS is for serial
ports, and so on. The CI object has a number of control loops represented as
LOOP_DEF objects under the CCF object.

Table 2. Control Structure Objects

Object Type Description

MOD_DB MOD_DB is the top of the control structure and represents a specific
Advant OCS database.
AREA, DEV_DIR, AREA objects allow you to partition the Advant OCS database into one
DEV_DESC or more areas. Its children are objects that represent subsystems
(nodes) in a given area.
DEV_DIR represents a device descriptor directory. Its children
(DEV_DESC) represent device descriptor sets.
AC410, AC460, These objects are children of an AREA object and represent
ADVANT_D2D, subsystems (nodes) in a given area.
CONSOLE, CONT_SS,
DCN_DCN, GENERICD

22 3BUR002120R3701
Section 1 Introduction Control Structure

Table 2. Control Structure Objects (Continued)

Object Type Description

CCF, CI, CONSLIB, These objects are children of the subsystem-level objects. They
PORTS and so on establish the physical and functional characteristics of the subsystems.
There may be more than one level of this type of object under a
subsystem-level object. For instance, CI (which is a child of GENERICD)
has CI_DEF as a child.
CTRL_BLOCK This object is a child of the CCF object and may be used as a parent for
LOOP_DEF or DEV_LOOP objects to group related loops. This object is
optional in the control structure
LOOP_DEF and The LOOP_DEF object represents a control loop. It is a child of the CCF
DEV_LOOP object. The control algorithm is defined by inserting Function Class
Module (FCM) objects as children of the LOOP_DEF object.
The DEV_LOOP object represents a discrete device. It is also a child of
the CCF object.
AINPUT, AOUTPUT, These objects are children of a LOOP_DEF object. They define the
MSQR, PID, other FCM control algorithm for the loop.
objects

Designation Of Objects in the Control Structure

The designation has to be unique in the project and the maximum amount of
characters may not exceed 21. A transition between levels should be indicated in the
designation by the transition from a numeric character to an alpha character.
It is recommended that when you define an object ID, you use the parent object
identifier as the base (prefix), and then append unique characters for a child object
identifier. Thus, if a parent object named “P” has two children, one named “C1” and
the other named “C2”, the object identification of the children are “PC1” and
“PC2”. This method facilitates masking object IDs when copying and/or importing
objects. Of course, when using this method for naming objects you eventually
exceed the maximum length for an object ID. Therefore, at some level, you will
need to start with a new prefix object ID. For example, in the Advant OCS database,
db1 may be the prefix object ID for all objects up to the level (for example,
db1_area1). At the subsystem level, each subsystem may be assigned a unique

3BUR002120R3701 23
Prerequisites and Requirements Section 1 Introduction

prefix (for example, for a controller subsystem object IDs may be cs1, cs1_cm1,
cs1_cm1_ccf, and so on). Another branch can be made at the loop level (for
example, fic_125, fic_125.ain, fic_125.sqr, fic_125.pid, and fic_125.aot).

Prerequisites and Requirements

The AdvaBuild software runs on an Windows-based Engineering Station. The
Windows-based Engineering Station comes equipped with the hardware and
software required to support the application packages that you order. The memory
provided to support the AdvaBuild software, and the memory requirements for
various options are described in the AdvaBuild Administrator’s Guide.

24 3BUR002120R3701
 Section 2 Basic Engineering and Design

Overview
Project engineering is carried out in two phases using Advabuild software:
• Basic Engineering which involves:
– Creating a new project
– Collecting general project information
– Building the hierarchy for the Control structures
• Detail Engineering, which involves:
– Detailed definition of the Control System
– Detailed definition of equipment arrangement and interconnections
– Configuration of control and device loops
– Editing and managing TCL sequences and recipes
These phases are described in the remainder of this chapter along with some basic
guidelines that are applicable for both phases of the project.
When the basic and detail phases are complete you can compile, install, and
download the database to the appropriate MOD 300 subsystems as described in the
AdvaBuild Control Builder User’s Guide.

Inserting/Opening a Project
The ability to create new projects and assign project users is supported by the
AdvaBuild Administration component. These functions are for use by the database
administrator (known as the Admin user) who should understand the Windows-
based Engineering Station file and operating system. See the AdvaBuild

3BUR002120R3701 25
Basic Configuration of the Control Database Section 2 Basic Engineering and Design

Administrator’s Guide detailed information about creating projects and inserting

users. See the AdvaBuild Control Builder User’s Guide for detailed information
about opening a project, inserting objects, editing objects, and so on.

Basic Configuration of the Control Database

The basic procedure for building the control database is as follows:
1. Insert a MOD_DB object as a child of the PROJECT object. This object
represents the top of the database.
2. Insert a DEV_DIR object as a child of the MOD_DB object. This object is a
directory of device descriptor sets. DEV_DESC objects which represent the
actual descriptor sets can be inserted under the DEV_DIR object when the
descriptor sets are defined.
3. Partition the database into areas by inserting AREA objects under the
MOD_DB object.
4. Insert subsystem-level objects (GENERICD, CONTSS, and so on) under
AREA objects.
5. Establish the functionality and operating characteristics of the subsystems by
inserting subsystem function-level objects under the subsystem-level objects.

The control structure can be modified at any time. When an object

is deleted, the children objects are also deleted.

The following sections provide guidelines for multi-user engineering, using

multiple Configurators, configuring alarms and alarm processing, and configuring
user access authority. For information on configuring object attributes for database
objects, see Section 3, Database Reference for Objects.

Rules for Multi-user Engineering

A user can work on several projects, and several users can work on a single project.
The following are some rules regarding multiple users.

26 3BUR002120R3701
Section 2 Basic Engineering and Design Multi-user Engineering in Administration Component

Multi-user Engineering in Administration Component

When you create a project, a default configuration user is assigned automatically.
The default configuration user (<project_name>_CFG) has full write access to all
project data and read-only access to journal data. In addition to the default
configuration user, you can define other users for a project. These other users are of
the three types with the privileges shown in Table 3.

Table 3. Project User Types and Their Privileges

User Type Privilege

CONFIG The CONFIG user has full write access to all project data and
read-only access to journal data, as well as the ability to do On-line
Builder functions such as compile, install, and download.
WRITER The WRITER user has full write access to all project data and
read-only access to journal data. This allows the user to select, insert,
delete, and update project data. The WRITER user usually does most
of the actual database configuration work.
READER The READER user has read only access to all project and journal
data.

Concurrence Of Conflicting Administration Functions

It is necessary to prevent certain project and user administration functions that
contradict each other from executing simultaneously. For example, it does not make
sense to save a project that another user is currently working on. Also you should
not be allowed to delete a project which is being copied to create a new project.
To prevent conflicting functions from executing at the same time, each project has a
status showing if an administration function is being performed on that project. All
Administration functions first check the status of the project they are working on
and abort if the project status conflicts with the operation to be performed.
Project status is indicated in the Status column in the upper portion of the Main
AdvaBuild Administration window. Status values are listed in Table 4.

3BUR002120R3701 27
Multi-user Engineering in Administration Component Section 2 Basic Engineering and Design

Table 4. Project Status

Value Description
I project is being Inserted via Projects > Insert Project…
R project is being Removed via Project > Delete Project…
E project is being Enlarged via Project > Enlarge Project…
S project is being Saved via Project > Save Project…
L project is being Loaded via Project > Load Project…
A project is Accessible, no manipulations via Administration
C project is being Compiled
D project is being Decompiled

When you choose project and user administration menu items (for example,
Projects > Insert Project…, Projects> Delete Project…, Users > Insert User…,
and so on), the respective function will:
• Check the current project status (see Table 4) and act accordingly. The action
depends on the selected function and status of the project.
• Check for any other users working on the project in question. The number of
users currently working on the project is displayed in the # Users column for
that project in the project list of the Main AdvaBuild Administration window.
If there are users currently working on the project or the project status is not A for
accessible, the menu item function is denied.
Table 5 identifies the Control Builder, Templet Builder, and On-line Builder
functions each user type can perform.

28 3BUR002120R3701
Section 2 Basic Engineering and Design Multi-user Engineering in Administration Component

Table 5. Functions Available for Each Project User Type

Function CONFIG WRITER READER

Insert Yes Yes No
Move Yes Yes No
Rename Single Object Yes Yes No
Rename Object and Descendants Yes Yes No
Delete Yes Yes No
Copy Single Object Yes Yes No
Copy Object and Descendants Yes Yes No
Load ASCII Transition File (ATF) Yes Yes No
Save ATF Yes Yes Yes
Export References Yes No No
Edit Comments of Single Object Yes Yes No
Edit Comments of Descendants Yes Yes No
Change User Password Yes Yes Yes
Annotation Yes Yes No
Compile Yes No No
Install Yes No No
Download Yes No No
Decompile Yes No No
Load Yes No No
Loop Load Yes No No
Multi Edit Yes Yes Yes(1)
Cross Reference Yes Yes Yes
(1) READER cannot save changes made in the Multiple Templet Editor.

3BUR002120R3701 29
Multi-user Engineering in Template Builder Section 2 Basic Engineering and Design

Multi-user Engineering in Template Builder

The Templet Builder provides automatic locking of objects to prevent two or more
users from updating the same object at the same time. When you attempt to update
an object, the Templet Builder determines whether the object has been updated or
deleted by another user since the last time the object was retrieved. If an object has
been updated or deleted by another user since it was retrieved, a Save Error dialog
identifying any conflicting records is displayed.

Guidelines for Using Multiple Configurators

You can run Configurator software (for Multibus-based CDPs) and AdvaBuild
software (for HP-UX Advant Station-based and Windows-based Engineering
Station CDPs) on multiple subsystems in the Advant OCS. Each CDP produces a
database for a specific part (domain) in the system. During runtime, the domains are
integrated to act as one unified database. Advantages for using multiple
configurators in large systems include:
• faster database compiling time
• faster downloading time since each CDP downloads to the subsystems in its
own domain.
There can be as many as 16 CDPs. Each CDP must be located at a DCN address
with a lower order hex digit of 1 (for example, 01, 11, 21, up to address F1).
Generally, data configured in a domain is known within that domain only. Certain
database attributes that reside in one domain may be referenced in other domains.
Such database attributes must be exported to those other domains by creating export
files and then exporting those files to the required configurators whose domains
reference the attributes. A certain amount of database information called the
common database portion is automatically shared among all domains. This includes
device descriptors, system nodes, and system state relations.
Guidelines are provided for the following scenarios:
• Implementing Multiple CDPs for First Time on page 31.
• Adding new CDP to Existing Multiple CDP System on page 33.
• Changing Export List for CDP on page 34. The export list refers to the data that
is exported to a CDP from other domains.

30 3BUR002120R3701
Section 2 Basic Engineering and Design Implementing Multiple CDPs for First Time

• Making CDPs Compatible on page 34. A CDP may be incompatible when its
database is compiled without saving database references, or when a CDP with a
new database replaces a CDP that was previously on-line (using the same
address).

Implementing Multiple CDPs for First Time

When you implement a multiple CDP system, follow the general procedure
described below. This will help you avoid problems and save time later on when
additional compiles, exports, and installs must be done in order to get all the CDPs
compatible. During initial development of each configuration domain, keep all of
the CDPs and associated DCN rings isolated from each other.

Plan Each Database

The following aspects of database configuration can affect the performance of a
multiple CDP system and should be considered:
• Grouping of nodes into domains
Group consoles, data processors and other nodes into configurator domains
such that the amount of data that needs to be exported is minimized. See
Guidelines for Establishing Domains in Database on page 35.
• Naming templets, loops, ladder logic entities, and so on
Having duplicate names in different configurator domains will cause problems
after the databases are put on-line. The compiler does not check for duplicate
names between configurator domains; therefore, you must take care that
duplicate names are not used.
• Learning the templet fields that are directly related to multiple CDPs
There are certain fields on some configuration templets that are directly related
to configuring multiple CDPs. It is recommended that you learn the function of
these fields before you begin database configuration. These fields are described
in Database Attributes Related to Multiple Configurator on page 35.

3BUR002120R3701 31
Implementing Multiple CDPs for First Time Section 2 Basic Engineering and Design

• Exporting data
Determine in advance which loops, units, unit relative names, ladder logic, and
console users are to be exported, and to which CDP they will be exported.
Guidelines for this are provided in Exporting Database References on page 36.

Configure each Database

Build the databases as you normally would. For templets that have data which must
be exported, specify which CDP the data will be exported to. You can either use the
EXPORT (on Windows-based Engineering Station) or EXPORT TO DEVICES (on
Multibus Console or HP-UX Engineering Station) fields on the individual templets,
or you can specify items be put in Export Source files via the Export References
Display. See Exporting Database References on page 36.
For each configurator domain proceed as you normally would in a single CDP
system. Resolve all compiler and installer errors and warnings. Keep in mind that
not everything will be resolved locally until all the imports are received.

Integrate all CDPs for First Time

To integrate all CDPs for the first time:
1. Put the CDPs on-line, one CDP at a time.
When a CDP is placed on-line for the first time, a transfer of common database
files occurs between that CDP and all other CDPs currently on-line. Since this
is the first time the CDP is on line, the databases are automatically made
compatible.

Wait until all file transfers for one CDP have been completed before
placing the next CDP on-line.

2. Once the CDPs are all on-line, start exporting to each CDP via the Export
References Display as described in the AdvaBuild Control Builder User’s
Guide.

32 3BUR002120R3701
Section 2 Basic Engineering and Design Adding new CDP to Existing Multiple CDP System

Make sure all exports are completed before proceeding to the next
step.

3. Install each database via the database templet of each respective database.
Doing a database install will cause all the imported files to be copied to the
operational database directory. These files will be available for resolving any
references. At this point, additional database compiles are not necessary since
they were done during the database configuration procedure.
The Install report may contain warnings of missing references. If so, access the
individual databases, and make the required corrections.

Adding new CDP to Existing Multiple CDP System

This procedure is similar to implementing a multiple CDP system for the first time
as described in Implementing Multiple CDPs for First Time on page 31. All
guidelines described in that section are also applicable here. It is very important that
each step is performed in the correct sequence. Use the following as a guide:
1. Configure the new database. This may be an existing database which is
operational.
2. For all configuration domains, determine what information is going to be
exported and to which CDP.
Enter the export information via templet fields or via the Export References
Display. Do not export any data at this point.
3. Connect the CDP. At this time, common data files are transferred. Since it is the
first time this CDP has been on-line, it is automatically made compatible.
4. Start exporting to each CDP. Make sure all exports are completed before
proceeding to the next step.
5. After the exports are completed, in order to make the newly imported
references available, a node-level install or higher must be done. You must
decide on one of the following options, based on the affected controllers, data
processors, and loops.
– Install the entire database

3BUR002120R3701 33
Changing Export List for CDP Section 2 Basic Engineering and Design

– Install an area
– Install one affected controller subsystem
– Install an affected node (control module, data processor, or console)
6. Install all other nodes as required.
7. Compile, install, and download loops that reference the new imported data.
8. Compile any environments that reference the new imported data.
9. Compile and link any TCL sequences that reference the new imported data.

Changing Export List for CDP

You can change the export list for a CDP. To do this, all configurator domains must
be compatible, and all loops must be properly compiled and installed and
operational. To change the export list:
1. Make the desired changes to the export list either by changing entries to the
EXPORT (on Windows-based Engineering Station) or EXPORT TO DEVICES
(on Multibus Console or HP-UX Engineering Station) field located on the
templets or via the Export References Display.
2. Export to the target CDPs.
3. A node-level install must be performed before the CDP can use the imported
data. Usually installing a Console node is most convenient. If a Console node is
installed, reboot it.
4. Then install and download any loops which reference the new imported data.
5. Compile any environments which reference the new imported data.
6. Compile and link any TCL sequences/procedures which reference the new
imported data.

Making CDPs Compatible

CDPs in a multiple CDP system may be incompatible when a database is compiled
without saving database references, or when a CDP with a new database replaces a
CDP that was previously on-line (using the same address).

34 3BUR002120R3701
Section 2 Basic Engineering and Design Guidelines for Establishing Domains in Database

To make all CDPs compatible:

1. Do exports to all CDPs.
2. Do a database install at each CDP.
3. Reboot each node and controller, starting with the CDP. For controllers, be sure
to terminate redundancy.

Guidelines for Establishing Domains in Database

Tags, printer names, unit names, and ladder logic names must be unique
systemwide. These database attributes cannot be duplicated within or between
domains.
The device descriptors are configured as children of the Device Descriptor
Directory. Device descriptors are part of the common database. That is, they are
configured once and shared by all domains. The Device Descriptor objects as a
group can be compiled and installed when new descriptors are added.

Database Attributes Related to Multiple Configurator

The following are database attributes that apply only to Multibus-based nodes and
are directly related to configuring with multiple configurators.

Configuration Area and Message Routing

The MESSAGE CTR and MESSAGE TYPE fields on the AREA and MSG_ROUT
objects have a corresponding REMOTE TYPE field which requires an entry when
the message destination is in another configuration domain. The entry specifies the
object type and must be one of the following: CONSOLE, LOGGER,
GENERIC_DPSS, LCP, HISTORY

Console Library Configurator

When you make an entry to the DEVICE NAME field of the CONSLIB object, you
use the name CONFIGURATOR to specify the subsystem that contains the
configurator for the local configurator domain (domain that contains the console
being configured). The system automatically determines the address of that
configurator and uses it.

3BUR002120R3701 35
Exporting Database References Section 2 Basic Engineering and Design

A Library Display automatically has an entry for the configurator of its domain.
There is no way to add an entry for a different configurator to a Library. However,
you can put lines on the Library for calling up the Console Configurator and Display
Builders of other configurator data processors by using the templet name of the data
processor in the DEVICE NAME field and changing at least one of the display IDs.

Exporting Database References

Certain database attributes that reside in one domain may be referenced in other
domains. Such database attributes must be exported to those other domains. This is
accomplished by creating export files and then exporting those files to the
configurators whose domains reference the attributes.
Attributes that require exporting are: tag names, unit names, unit relative tag names,
ladder logic names, and user names.
For example, if loop TC100 configured by the configurator at address 21 references
a value from loop TC222 of another domain, TC222 must be exported to the
configurator at address 21. Exported data is used by the database installer, TCL
linker, and console environment linker when they check for availability of database
attributes.
Table 6 provides a list of attributes that can be referenced in other configurator
domains.

Table 6. Database Attributes that can be Referenced by other Domains

Database Attribute Related Object Can be Referenced By

Tag Name LOOP_DEF, DEV_LOOP Other Loops, TCL Sequences,
Console Groups, Graphic Displays
Ladder Logic Attributes LL_I_O, LL_I_O_2, LL_CNTR, Other Loops, TCL Sequences,
LL_REG, LL_TIMER Console Groups, Graphic Displays
User Names MODUSERS Console Environments
Unit Names UNITMAST TCL Sequences, Console
Environments
Unit Relative Names URELNAME TCL Sequences, Graphic Displays
Unit Variable Names UNITMAST TCL Sequences

36 3BUR002120R3701
Section 2 Basic Engineering and Design Exporting Database References

To ensure that other configurator data processors receive the proper references, you
must:
• Create an Export File
• Export the Files

Creating an Export File

You can create an export file either while you edit objects in the Template Builder,
or via the Export References Display.
• Creating an Export File via Object Editing
When you configure the database objects via the Template Builder, specify the
objects whose database attributes need to be exported as follows. Mark the
object to be exported by making an entry in the EXPORT (on Windows-based
Engineering Station) or EXPORT TO DEVICES (on Multibus Console or HP-
UX Engineering Station) field. This entry is a string of numbers that represent
the most significant hex digit in the DCN address of each configurator data
processor to receive the export data. For example, the entry 125B in the
EXPORT (on Windows-based Engineering Station) or EXPORT TO DEVICES
(on Multibus Console or HP-UX Engineering Station) field specifies the
configurators at addresses 11, 21, 51, and B1 are to receive export data.
• Creating an Export File via the Export References Display
The Export References Display allows you to view and edit all exported data in one
place without having to access individual objects. To access this display from the
Control Builder Navigator window, choose Tools > Export Display from the menu
bar.

Exporting the Files

You can send the Export Data Files to all CDPs, or just to ones that you specify. This
functionality is supported by the Export References Command dialog which is
accessed by choosing Tools > Export References from the menu bar of the Control
Builder Navigator window. Prior to exporting, the database must have been
compiled at the database level and any object to be exported which was added after
the database level compile must be compiled on some level.

3BUR002120R3701 37
Compiler Considerations for Using Multiple Configurators Section 2 Basic Engineering and Design

See the AdvaBuild Control BuilderUser’s Guide for detailed information about the
Export References Display and the Export References Command dialog.

Compiler Considerations for Using Multiple Configurators

Data references which occur in the same node as the object are resolved by the
compiler. References which can possibly occur in a different node are resolved by
the installer. Compiling without saving logical references causes a new database ID
to be created.

Installer Considerations for Using Multiple Configurators

The installer resolves references in its own domain first and then resolves the
imported data.
After the install is complete, the installer shares files that make up the common
database portion which includes device descriptors, node data, system nodes, and
system state relations.
Installs from a level lower than the database level are disallowed if export data has
been received with a different database ID than the one installed. This means you
must be careful when doing an export, because it forces the receiving configurators
to do an install on the database level before doing any loop or node level installs.

Considerations for Program Downloads

Program and database downloads are always performed from the configurator data
processor that configured the node.

Considerations for Database Reports

The Multiple Templet Editor and Cross Reference Reports work within the local
domain only. If you want to be sure of finding all items in the system that reference
a given loop, you have to execute a Cross Reference Report in each domain.

Considerations for Using TCL

The TCL linker attempts to resolve references within its configurator domain first
and then uses the imported data if the references cannot be found. TCL programs

38 3BUR002120R3701
Section 2 Basic Engineering and Design Considerations for Using Console Configurator

also have the ability to resolve references at load time using both local and imported
data.

Considerations for Using Console Configurator

Any item referenced by an environment must either be local to the configurator
domain or it must be in the data import list. This includes loops referenced by
displays that are part of the environment. The console environment linker attempts
to resolve database references within its configurator domain first and then uses the
import list if the references cannot be found.
Environments can be configured in any data processor that contains a configurator.
A console can sign on to any environment in the system, whether or not the
environment was produced in the console's domain.

Alarm and Event Processing

The Advant OCS supports detection, notification, and logging of alarms and events.
An event is a predefined, significant occurrence in the system. It usually involves a
change to a process parameter. When an event takes place, the appropriate
applications and/or devices in the system such as TCL programs and the History
Services software are notified so they can take appropriate action.
Some events are standard for every system. Some examples are:
• The change of state of a digital input
• An operator or supervisor change to a setpoint via the Runtime Displays
• An engineer change to a variable via the Loop/FCM Display
Other events can be defined specifically for an individual system. Some examples
are:
• Events defined via the SETEVENT Statement in TCL
• Events defined via the Ethernet High Level Functions for systems equipped
with a VAX Interface Subsystem
• Alarms on process variables

3BUR002120R3701 39
Alarm/Event Detection and Notification Section 2 Basic Engineering and Design

Alarms are a special class of events that require acknowledgment by the operator.
When an alarm occurs, the system notifies the Multibus Consoles and/or Advant
Stations and requires the operator to acknowledge. This insures the operator knows
about situations that can affect the quality and safety of the process. For example,
you can configure alarms to warn the operator when a process temperature becomes
too high or when a process device fails to respond to a command.

Alarm/Event Detection and Notification

The system detects the occurrence of an event through the interaction of several
software packages. The process starts with the Data Base Manager Service (DBMS)
which resides in the memory of every node (subsystem and control module) in the
system. When the DBMS detects a parameter change, it determines if an event has
taken place by checking the parameter change against two event tables. One table is
static and contains a list of the standard events. The other table contains a list of the
events defined specifically for an individual system.
When the DBMS determines an event has taken place, it relays the information to
the Alarm/Event Handler. The Alarm/Event Handler in turn notifies the appropriate
applications and devices in the system. Some applications/devices are automatically
notified such as TCL runtime modules. Other devices such as Loggers and
Historical Recorders must be targeted for notification by configuring the
MESSAGE CTR attribute for the AREA object. In addition, programs running on
computer systems that communicate with the MOD System via a computer interface
are notified if they request notification through a High Level Interface Function.
During runtime, Configurable Control Functions (CCF) checks the status of the
alarms. When an alarm becomes active, CCF passes that information to the
Alarm/Event Handler.
Refer to AdvaCommand Basic Functions User’s Guide for a detailed discussion of
the following Alarm/Event Handling features:
• Alarm and event display and acknowledgment
• Suppression of alarm and event messages
• Alarm display setup

40 3BUR002120R3701
Section 2 Basic Engineering and Design Alarm/Event Logging

Alarm/Event Logging
The Alarm and Event Logger software generates a printed log of alarm, event, TCL
Billboard, and system error messages on printers. To implement alarm/event
logging functionality in your system, you must configure loggers in the database. A
logger is a software device that reports and records messages addressed to it from
elsewhere in the system. Loggers can be configured for Multibus-based consoles
and data processors, HP-UX Advant Station-based Operator Stations, Engineering
Stations, and Information Management Stations, and Windows-based Engineering
Stations. Any subsystem is limited to just one logger.
Refer to AdvaCommand Basic Functions User’s Guide for a detailed discussion of
the following Alarm/Event logging features:
• Logger control
• How to read the Alarm/Event log
• Alarm/Event message formats

How to Configure Alarm/Event Loggers

To configure an Alarm/Event logger for a Multibus-based subsystem, configure the
following objects in the subtree for the subsystem where the logger resides:
• On the AREA object (parent of the subsystem object), make entries for the
Logger in the MESSAGE CTR field.
• Assign and configure a LOG_DETL object as a child of the GENERICD object
for the subsystem. This object defines the operating parameters of the logger.
• Assign and configure a serial port for the printer via the PORTS object. This
object is a child of the GENERICD object for the subsystem.
To configure an Alarm/Event logger for an HP-UX Advant Station-based
subsystem:
• Configure the following objects in the subtree for the subsystem where the
logger resides:
– On the AREA object (parent of the subsystem object), make entries for the
Logger in the MESSAGE CTR field.
– Assign and configure a LOG_DETL object as a child of the GENERICD

3BUR002120R3701 41
How to Configure Alarms for Continuous Loops Section 2 Basic Engineering and Design

object for the subsystem. This object defines the operating parameters of
the logger.
• Set up either a serial port or a parallel port in HP-UX.
A parallel port is recommended since a limited number of serial ports are
available and the serial ports are generally required for other devices.

If you use a parallel port, this printer can only be used for the logger
printing. No other applications can share the printer.

• Configure a printer in HP-UX.

Refer to the applicable sections in Section 3, Database Reference for Objects for
details regarding how to configure the AREA and LOG_DETL objects.
Refer to the Advant Station 500 Series with AdvaCommand 1.8/AdvaBuild 2.9
User’s Guide for information on how to set up a port on the HP-UX Engineering
Station and configure a printer in HP-UX.

In addition to configuring these objects, if you expect heavy alarm

message traffic on your DCN, you can use the Group Routing
function to optimize alarm message traffic on the DCN. This
involves defining message sending and message receiving groups in
a configuration file. This is an off-line activity and is described in
Appendix A.

How to Configure Alarms for Continuous Loops

You can define one or more alarms for continuous loops via the CCF software. To
define such alarms, you have to configure attributes on various objects as described
below. For further information, refer to the Configurable Control Functions (CCF)
User’s Guide.

Alarm Deadband
Alarm deadband prevents variables that oscillate around their alarm limits from
generating spurious alarms. This parameter is configured on a subsystem level. That
is, all continuous loops for a subsystem are assigned the same deadband. Alarm

42 3BUR002120R3701
Section 2 Basic Engineering and Design How to Configure Alarms for Continuous Loops

Deadband is configured by making the appropriate entry in the ALARM

DEADBAND field of the CCF object (child of any subsystem where CCF runs).

General Loop-level Alarm Parameters

The LOOP_DEF object for each continuous loop has fields that determine the
general alarm handling parameters for that loop. These parameters determine
whether or not the loop checks for certain alarms, whether or not alarm messages
are logged, and whether or not logging is under the control of another FCM.
You can define several alarms for the measured variable of a loop via the
LOOP_DEF object. If a loop contains the PID Controller FCM, the following
alarms are configured via the PID FCM object:
• High, low, rate, and bad data quality alarms on the output of the PID Controller
FCM
• High, low, and bad data quality alarms on the setpoint
• High and low alarms on the deviation
If a loop contains the Auto/Manual FCM, the following alarms are configured via
the Auto/Manual FCM object:
• High, low, rate, and bad data quality alarms on the output of the Auto/Manual
Controller FCM.

Alarm Priority
The LOOP_DEF and FCM objects have alarm priority fields for assigning priority
levels to the alarms described above. The priority can be defined as HIGH, MED
(medium), and STD (standard). You can make entries to the Setup Display that
determine the colors used to indicate alarms of different priorities on the runtime
displays. The colors actually used at runtime depend on whether the UNACK
ALARM TEXT SHOWN IN ACK COLOR runtime option is enabled or disabled
for the current environment. See the Console Configurator User's Guide, for
information about the special runtime options.
For further information on how to configure alarms for continuous loops, refer to
the Configurable Control Functions (CCF) User’s Guide.

3BUR002120R3701 43
How to Configure Alarms for Device Loops Section 2 Basic Engineering and Design

How to Configure Alarms for Device Loops

Some device alarms are automatically present for each device loop. The conditions
these alarms indicate are:
• Unknown State - the system cannot read the feedback from the device
• Bad Input Data Quality - quality of the input is bad
• Abnormal State Change - the device changed state but no command to do so
was issued
• Illegal State - no device state is defined for the feedback coming from the
device
One device alarm is configured via the DEV_LOOP Templet.
• Time-out - becomes active when the system sends a command to the device and
the device does not respond within a configurable length of time.
Some device alarms are configured via the DEV_DESC Templet. They are in affect
for any device assigned to the descriptor set defined by the templet. They include:
• State Alarm - becomes active when the device enters a state defined as an alarm
state
• Illegal Command - becomes active when the operator or a TCL program enters
a command defined as an illegal command
The Device TCL Alarm is a special alarm you can define when using a user-defined
device algorithm. It indicates whether the TCL program is no longer capable of
performing the device algorithm.

General Alarm Parameters

The DEV_LOOP object for each device loop has fields that determine the general
alarm parameters for the loop. These parameters determine whether or not the loop
checks for alarms, whether or not alarm messages are logged, and whether or not
logging is under the control of another FCM.

44 3BUR002120R3701
Section 2 Basic Engineering and Design How to Configure Historical Recording

Alarm Priority
Alarm priority for device loops is configured in the same manner as continuous
loops.
For further information on how to configure alarms for device loops, refer to the
Configurable Control Functions (CCF) User’s Guide.

How to Configure Historical Recording

During the database configuration, you can configure how (or if) the system
archives the values of variables and the occurrences of alarm and event messages.
When alarm and event messages are archived:
• You can view archived messages via the Historical Message Display during
runtime
• You can put archived messages into process reports set up through the Report
Services
• A host/supervisory computer can access archived messages
To specify how alarm and event messages are archived:
• Assign and configure RECORDER and CHNL_DEF objects as children of the
appropriate subsystem-level object
• Place the name of the first Recorder in the MESSAGE CTR field of the AREA
objects that represent the configuration areas whose messages you want to
archive
For further information on how to configure archive parameters for alarm/event
messages, refer to the History Services with Statistical Process Control (SPC)
User’s Guide.

Ringback
When ringback is enabled for a loop, each alarm requires two acknowledgments,
one when it becomes active and one when it clears (returns to normal). When it is
disabled, acknowledgment is only required when the alarm becomes active.
Ringback can be enabled or disabled on an individual basis for each loop. This
parameter is configured as part of console environment configuration as described
in the Console Configurator User's Guide (for Multibus-based consoles) or

3BUR002120R3701 45
Fetch Alarm Target Section 2 Basic Engineering and Design

AdvaBuild Environment Builder User’s Guide (for HP-UX Advant Station-based

Operator Stations).

Fetch Alarm Target

The main display in runtime contains a FETCH ALARM target. When a loop goes
into alarm, its tag label on the display indicates an alarm exists by changing to the
appropriate color. The operator then selects the FETCH ALARM target to call the
appropriate Group Display to the screen. When you configure the console (operator
station) environment via the Environment Builder, you select the display to be
called up when FETCH ALARM is selected. The choices are: Group Alarm, Group
Graphic, Group Status, and Group Trend Displays for the tag in alarm.
This parameter is configured as part of group definition during console environment
configuration as described in the Console Configurator User's Guide (for Multibus-
based consoles) or the AdvaBuild Environment Builder User’s Guide (for Advant
Station-based operator stations).

Alarm/Event Handling by other Applications

Advant OCS application packages including Report Services, History Services,
Display Builder, Taylor Control Language, MOD 30 Instrument Interface, and
Computer Interface can access the alarm parameters listed in Table 7 and Table 8.

46 3BUR002120R3701
Section 2 Basic Engineering and Design Alarm/Event Handling by other Applications

Table 7. Alarm Parameters for Device Loops

Data State State

Description Mnemonic State/Range Relation
Type Value Desc.

Alarm CHK_ENB BIN1 DISABLED 0 Alarm Checking Disabled LCM_DEFIN_N

Checking ENABLED 1
Enable

Cutout Enable CO_ENAB BIN1 DISABLED 0 Alarm cutout disabled LCM_DEFIN_N

(Alarm Posting) ENABLED 1 Alarm cutout enabled

Cutout State CO_STATE BIN1 FALSE 0 Cutout when false LCM_DEFIN_N

(Alarm Posting) TRUE 1 Cutout when true

Device Action ACT_ALM BIN2 NO_ALARM 0 No alarm DEV_LOOP_DAT

Alarm ABNORMAL_C 1 Abnormal change
H 2 Device timed out
TIMEOUT

Device Alarm DEV_ALRM UI Per DEV_DESC DEV_LOOP_DAT

State object

Device Alarm INP_ALM BIN4 NO_ALARM 0 No alarm DEV_LOOP_DAT

Input DQ_BAD 1 Data quality bad
ALARMED_STA 2 In alarm state
ILLEGAL_STA 4 In illegal state

Device TCL TCL_ALM BIN2 NO_ALARM 0 No alarm DEV_LOOP_DAT

Alarm TCL_FAILED 1 TCL failed
TCL_TIMEOUT 2 TCL timed out

Posting Enable POSTENAB BIN1 DISABLED 0 Posting disabled LCM_DEFIN_N

ENABLED 1 Posting enabled

State Alarm STAT_ALM BIN1 0 No alarm DEV_LOOP_DAT

1 Alarm State

3BUR002120R3701 47
Alarm/Event Handling by other Applications Section 2 Basic Engineering and Design

Table 8. Alarm Parameters for Continuous Loops

Data State State

Description Mnemonic State/Range Relation
Type Value Desc.

Cutout Enable CO_ENAB BIN1 DISABLED 0 Alarm cutout disabled LCM_DEFIN_N

(Alarm Posting) ENABLED 1 Alarm cutout enabled

Cutout State CO_STATE BIN1 FALSE 0 Cutout when false LCM_DEFIN_N

(Alarm Posting) TRUE 1 Cutout when true

Deviation DEV_ALM BIN4 NO_ALARM 0 No alarm CTRLOOP_DAT

Alarm DQ_BAD 1 Data quality bad
HI 2 High alarm
LO 4 Low alarm

Measured MEAS_ALM BIN6 NO_ALARM 0 No alarm CTRLOOP_DAT

Value Alarm DQ_BAD 1 Data quality bad
HIHI 2 High high alarm
HI 4 High alarm
LO 8 Low alarm
LOLO 16 Low low alarm

Measured MROC_ALM BIN1 NO_ALARM 0 No Alarm CTRLOOP_DAT

Value Rate of IROC 1 Rate of Change Alarm
Change Alarm

Output Alarm OUTP_ALM BIN4 NO_ALARM 0 No alarm CTRLOOP_DAT

DQ_BAD 1 Data quality bad
HI 2 High alarm
LO 4 Low alarm

Output Rate of OROC_ALM BIN1 NO_ALARM 0 No Alarm CTRLOOP_DAT

Change Alarm OROC 1 Rate of Change Alarm

Posting Enable POSTENAB BIN1 DISABLED 0 Posting disabled LCM_DEFIN_N

ENABLED 1 Posting enabled

Setpoint Alarm SPT_ALM BIN4 NO_ALARM 0 No alarm CTRLOOP_DAT

DQ_BAD 1 Data quality bad
HI 2 High alarm
LO 4 Low alarm

48 3BUR002120R3701
Section 2 Basic Engineering and Design Alarm/Event Handling for Report Services

Alarm/Event Handling for Report Services

Alarm and event messages stored by History Services can be used in process reports
built with the Report Services. For further information regarding Report Services,
refer to the Report Services User's Guide.

Alarm/Event Handling for TCL

Unit Message Display

The MESG statement allows a program to send a message that must be
acknowledged by the operator to the Unit Message Display of the Console. The
REPLY statement is similar to the MESG statement except it waits for the operator
to respond with a reply to the message.
These messages are referred to as TCL Billboard Messages. Entries must be made
to the AREA object to send TCL Billboard Messages to Consoles.

Database Access of Alarm Parameters

TCL can access the loop alarm parameters listed in Table 7 and Table 8 using tag
access methods.
Example:
IF ($'TC105'.MEAS_ALM = #HIHI) THEN...

SETEVENT Statement
The SETEVENT statement provides the means to define events. When the event
occurs, TCL is notified and can change the state, status, or mode of a program.

UPDATEON and UPDATEOFF Statements

When TCL programs are run in their normal condition, no logging is performed
when database parameters are changed by the program. However, after an
UPDATEON statement is executed the system logs changes made to database
parameters of the node in which the program is running. The program is returned to
its normal, non-logging condition by executing an UPDATEOFF statement.

3BUR002120R3701 49
Alarm/Event Handling for Display Builder Section 2 Basic Engineering and Design

Alarm/Event Handling for Display Builder

The Display Builder can access the loop alarm parameters listed in Table 7 and
Table 8 using tag access methods.
When you build a display, you select the colors for presentation of database values.
If a database value goes into an alarm condition, it is automatically displayed in the
appropriate color for the priority of the alarm as specified through the Environment
Builder.
Further information regarding the Display Builder is provided in the Display
Builder User's Guide.

Alarm/Event Handling for Instrument Interface

Instrument Interfaces have a dual approach to alarms. Some alarms are configured
in the instruments and some are configured in CCF. The Taylor MOD 30 Interface
User's Guide describes how an Instrument Subsystem handles alarms.

Alarm/Event Handling for Computer Interface

Computers connected to the Advant OCS via a computer interface can access alarm
and event data (listed in Table 7 and Table 8) via high level programming functions.
Limit and alarm checks are defined via the Alarm Event Notification Services of the
High Level Programming Functions of the Ethernet Interface.
The History Services High Level Functions can read alarm and event messages
archived by the History Services software.
The user ID established via the SET_USRID High Level Function determines
whether logging is performed when an application program on the VAX changes a
value in the MOD System database.

Alarm Contacts on SIM Module

The SIM (System Integrity Module) of the Multibus console node has contacts
which can drive a relay to provide remote alarm annunciation via a light or horn.
The contacts have a rating of 30 V RMS, 42.2 volts peak at.250 A maximum.

50 3BUR002120R3701
Section 2 Basic Engineering and Design System Users

To use this feature, the Console Setup Page must contain the following entries:

Field Entry
Audible Alarm & TCL ENABLED
Audible Alarm & Clear DISABLED
Auto Acknowledgment DISABLED
Acknowledgment Mode LOCAL
Acknowledgment Level PAGE
Ring Back DISABLED

System Users
There are four main categories of system users of the Advant OCS: Operators,
Supervisors, Engineers, and Configurator users. Operators and Supervisors are
responsible for runtime operations. They monitor and control the operational
parameters of process loops via standard and custom displays designed for that
purpose. Engineers have access to system building and tuning functions in addition
to the operator tasks. Configurator Users are a special class of engineers who have
access to the install function of the Database Configurator (Multibus-based version,
not AdvaBuild).

Establishing System Users

Users are established via the USERS object which is a child of a GENERICD object
that represents a configurator/data processor. Each user is assigned one of the
following access class:
OPERATOR Low Authority
SUPERVISOR Medium Authority
ENGINEER High Authority

The AdvaBuild Administration component of the AdvaBuild

software provides an independent method for establishing
Configurator-class users for system engineering with the AdvaBuild
software.

3BUR002120R3701 51
Assigning Operator, Supervisor, and Engineer Tasks Section 2 Basic Engineering and Design

Assigning Operator, Supervisor, and Engineer Tasks

Displays and software packages that are accessible via a Console (Multibus-based)
or Operator Station (Advant Station) must be assigned a user category. This
determines the class of user that can access each display or software package. If a
display or software package is specified as OPERATOR, all users can use it. If it is
specified as SUPERVISOR, engineers and supervisors can use it. If it is specified as
ENGINEER, only engineers can use it.
You specify the user category of each display and software package via the
Environment Builder. The default categories are given in Table 9. Initially, all
displays and software packages are assigned the ENGINEER user category (except
the Library and Environment Download displays which are available to all classes
of users). You can change the default categories via the Environment Builder. A
display can have one access level in one Environment and a different one in another
Environment.

Table 9. Default User Categories for Displays and Software Packages

DEFAULT
NAME DESCRIPTION USER COMMENTS
CATEGORY
TCLRECITEMS TCL Recipe Items Engineer
TCLSEQCNTRL TCL Sequence Control Engineer
TCLREPMESG Engineer
CONSSETUP Console Setup Engineer Does not apply to
AdvaBuild Environment
Builder.
KEYSETUP Console Key Setup Engineer
LIBRARY Library Display NOCHECK No check for user
access.
TOUCHALIGN Touchscreen Alignment Engineer
LOGGERCONTROL Alarm/Event Logger Control Engineer
OPBILLBOARD Operator Billboard Engineer

52 3BUR002120R3701
Section 2 Basic Engineering and Design Assigning Operator, Supervisor, and Engineer Tasks

Table 9. Default User Categories for Displays and Software Packages (Continued)

DEFAULT
NAME DESCRIPTION USER COMMENTS
CATEGORY
CONFIGURATOR Database Configurator Engineer Does not apply to
AdvaBuild.
DBUTILITIES Database Utilities Engineer Backup, Restore
PAGEBUILD Display Builder Engineer Does not apply to the
AdvaBuild Display
Builder.
CONSCONFIG Console Configurator Engineer Does not apply to the
Environment Builder.
TCLCATALOG TCL Catalog Engineer
HISTORICAL History RDP Displays Engineer
TCLRECIPE TCL Recipe Catalog Engineer
DISKFORMAT Disk Format Utility Engineer
REPORTBUILD Report Builder Engineer Does not apply to
AdvaInform
ReportBuilder.
REPORTSCHED Report Scheduling Engineer Does not apply to
AdvaInform
ReportScheduler.
PCONFIG Programmable Controller Engineer Does not apply to
Configurator PLCBuilder
OVERVIEW Overview Displays Engineer
AREAPAGES Area Displays Engineer Alarm, Status, Trend,
Graphic
GROUPPAGES Group Displays Engineer Alarm, Status, Trend,
Graphic
DETAILPAGES Group Detail Displays Engineer

3BUR002120R3701 53
Assigning Operator, Supervisor, and Engineer Tasks Section 2 Basic Engineering and Design

Table 9. Default User Categories for Displays and Software Packages (Continued)

DEFAULT
NAME DESCRIPTION USER COMMENTS
CATEGORY
UNITOVRVIEW Unit Overview Engineer
TCLUNITDET Unit Detail Displays Engineer
RECIPEDIT TCL Recipe Detail Displays Engineer
UNITMSG TCL Unit Message Displays Engineer
TESTUNITREL Unit Graphic Displays Engineer
SEQDETAIL Sequence Detail Display Engineer
SEQDEBUG Sequence Debug Display Engineer
HISTORYUNIT History Unit Display Engineer
ENVIRALARM Environment Alarm Display Engineer
LOOPFCM Loop FCM Displays Engineer
HISTORYTREND Historical Trend Display Engineer
HISTORYMESG Historical Message Display Engineer
SYSTEMSTATUS System Status Display Engineer
CRTLREDUND Controller Redundancy Display Engineer
ENVDOWNLOAD Environment Download NOCHECK No check for user
access.
SEGMENTDISP TLL Segment Display Engineer
TIMERDISP TLL Timer Display Engineer
COUNTERDISP TLL Counter Display Engineer
REGISTERDISP TLL Register Display Engineer
IODISP TLL I/O Display Engineer
SEQUENCEDISP TLL Sequence Display Engineer

54 3BUR002120R3701
Section 2 Basic Engineering and Design Assigning Operator, Supervisor, and Engineer Tasks

Table 9. Default User Categories for Displays and Software Packages (Continued)

DEFAULT
NAME DESCRIPTION USER COMMENTS
CATEGORY
FILEDISP TLL File Display Engineer
LADDERLOGIC TLL Device Directory Engineer
SPCALARM SPC Alarm Display Engineer
SPCCHART SPC Chart Display Engineer
ACCURAY AccuRay Interface Display Engineer
WRKRCPDETAIL Working Recipe Detail Display Engineer
CONTROLLER Controller Subsystem Status Engineer
BATCH_RECIPE Master Recipe & Phase Library Engineer
BATCH_SCHED Production Schedule Engineer
BATCH_EQUIP Plant Equipment Catalog & Class Engineer
Library
BATCH_MATL Material Catalog Engineer
EDITB_RECIPE Master Recipe & Phase Library Engineer
Editors
EDITB_SCHED Production Schedule, Control Engineer
Recipe Editor, & header part of
Batch Management Display
EDITB_BATCH Body of Batch Management Engineer
Display & Working Recipe Editor
EDITB_EQUIP Plant Equipment Catalog & Editor, Engineer
& Equipment Class Editor
EDITB_MATL Material Catalog Editor Engineer
BATCH_CUSTOM Batch Customization Display Engineer

3BUR002120R3701 55
Assigning Configurator User Tasks Section 2 Basic Engineering and Design

Assigning Configurator User Tasks

This procedure is only required when you plan to use the Configurator software
package which runs on a Multibus-based CDP to do some portion of the database
configuration. If you are using the AdvaBuild software on the HP-UX or Windows-
based Engineering Station exclusively, you can ignore this section.
The Configurator has special user requirements. Any user with engineer status can
access the configurator and access any object except the following:
• MOD 300 Configurator Templet (Display)
This object is not represented in the AdvaBuild database structure. Its
functionality is provided by the Administration function in the AdvaBuild
Structure Builder on the HP-UX Advant Station and the Administration
component of the AdvaBuild Control Builder on the Windows-based
Engineering Station.
– MOD_DB object
– AREA objects
– USERS objects
To enter information into the Configurator, the engineer must be assigned as either a
Master (ADMIN) User, Database Owner, or Area Editor. They have the following
privileges:
• Master (ADMIN) Users are the only users who can:
– Create a database.
– Install a complete database.
– Perform all functions assigned to any user category defined on lower
templets.
In the Configurator, Master Users are defined on the MOD 300 Configurator
templet (object). This object is not represented in the AdvaBuild database. This
functionality is provided by the Administration function in the AdvaBuild
Structure Builder on the HP-UX Advant Station and the Administration
component of the AdvaBuild Control Builder on the Windows-based
Engineering Station.
• Database Owners can:

56 3BUR002120R3701
Section 2 Basic Engineering and Design Generating Database Cross Reference Reports

– View, edit, and delete the MOD_DB object for their database.
– View, edit, and delete the AREA objects that are part of their database.
– Compile and decompile objects of their database.
– Do all functions of user categories specified on lower level objects in their
database.
• Area Editors are users who are assigned special functions within a
Configuration area. These users can:
– Modify templets below the AREA objects in their Configuration area.
– Compile at or below the configuration area level in their Configuration
area.

Generating Database Cross Reference Reports

During database configuration you may want to run a cross reference report to
determine the status of references in the database. For instance, you can check for
unresolved references in a selected subtree. This functionality is provided via the
Cross Reference dialog, Figure 3, which is accessible by choosing either Object >
Special Commands > Cross_ref from the menu bar or Special Commands >
Cross_ref from the Right Mouse Buttons Pop-up menu. See the AdvaBuild
Control Builder User’s Guide for information on how to use the cross reference
utility.

3BUR002120R3701 57
Generating Database Cross Reference Reports Section 2 Basic Engineering and Design

Figure 3. Cross Reference Dialog

58 3BUR002120R3701
 Section 3 Database Reference for Objects

Scope
This chapter provides detailed reference information for configuring the hierarchy
of database objects in the Advant OCS control structure, and for configuring object
attributes. The information in this chapter includes:
• A description of the database hierarchy that shows the required parent-child
relationships.
• A listing of database objects with an explanation of the purpose of each object.
• A description of object attributes on an object-by-object basis for database
objects that are not covered in other documentation (for example, high level
objects and other miscellaneous objects).
Most database objects are not described in this book, but rather in the user’s guide
for the application package to which they are related. For instance, the CCF-related
objects are described in the Configurable Control Functions (CCF) User’s Guide.
For such objects, this chapter refers you to the appropriate book where more
detailed information is provided.

Control Structure Database Hierarchy

This section describes the hierarchical (parent-child) relationship between database
objects. This hierarchical structure is broken down into the following views:
• Top-Level and Subsystem-Level Objects - Figure 4
• CONSOLE Subtree - Figure 5
• GENERICD Subtree - Figure 6
• CI Subtree - Figure 7

3BUR002120R3701 59
Control Structure Database Hierarchy Section 3 Database Reference for Objects

• TCL_DEV Subtree - Figure 8

• TCL_RUN Subtree - Figure 9
• AR_DATA Subtree - Figure 10
• HISTORY Subtree - Figure 11
• CONT_SS Subtree - Figure 12
• CCF Subtree - Figure 13
• LL_DEV Subtree - Figure 14
• REMOTEIO Subtree - Figure 15
• AC410 Subtree - Figure 16
• AC460 Subtree - Figure 17
• PLC Subtree - Figure 18
• S100_IO Subtree - Figure 19
• S800_IO Subtree - Figure 20
• PROFIBUS_IO Subtree - Figure 21

60 3BUR002120R3701
Section 3 Database Reference for Objects Control Structure Database Hierarchy

MOD_DB represents a control database

AREA1 represents one configuration

area

These objects represent subsystems in

configuration area number 1

AREA2 represents a second configuration

area

Figure 4. Hierarchy for Top-Level & Subsystem-Level Objects

Figure 5. Hierarchy for CONSOLE Subtree

3BUR002120R3701 61
Control Structure Database Hierarchy Section 3 Database Reference for Objects

Figure 6. Hierarchy for GENERICD Subtree

Figure 7. Hierarchy for CI Subtree

62 3BUR002120R3701
Section 3 Database Reference for Objects Control Structure Database Hierarchy

Figure 8. Hierarchy for TCL_DEV Subtree

Figure 9. Hierarchy for TCL_RUN Subtree

Figure 10. Hierarchy for AR_DATA Subtree

Figure 11. Hierarchy for HISTORY Subtree

3BUR002120R3701 63
Control Structure Database Hierarchy Section 3 Database Reference for Objects

Figure 12. Hierarchy for CONT_SS Subtree

64 3BUR002120R3701
Section 3 Database Reference for Objects Control Structure Database Hierarchy

Figure 13. Hierarchy for CCF Subtree

Figure 14. Hierarchy for LL_DEV Subtree

3BUR002120R3701 65
Control Structure Database Hierarchy Section 3 Database Reference for Objects

Figure 15. Hierarchy for REMOTEIO Subtree

66 3BUR002120R3701
Section 3 Database Reference for Objects Control Structure Database Hierarchy

Figure 16. Hierarchy for AC410 Subtree

3BUR002120R3701 67
Control Structure Database Hierarchy Section 3 Database Reference for Objects

Figure 17. Hierarchy for AC460 Subtree

Figure 18. Hierarchy for PLC Subtrees

68 3BUR002120R3701
Section 3 Database Reference for Objects Control Structure Database Hierarchy

Figure 19. Hierarchy for S100_IO Subtree

3BUR002120R3701 69
Control Structure Database Hierarchy Section 3 Database Reference for Objects

Figure 20. Hierarchy for S800_IO Subtree

Figure 21. Hierarchy for PROFIBUS I/O Subtree

70 3BUR002120R3701
Section 3 Database Reference for Objects Database Objects

Database Objects
This section lists database objects by the following categories: Top level objects,
GENERICD and related objects, CONSOLE and related objects, CONT_SS and
related objects, CCF-related objects, TLL-related objects, REMOTEIO-related
objects, AC410 objects, AC460 objects, S100 I/O objects, S800 I/O objects,
MVIBOARD objects, and PLC objects.
The tables where the database objects are listed describe the purpose of the object
and provide a reference for more detailed information.
This section provides reference information for configuring object attributes for
top-level objects and other miscellaneous objects that are not associated with a
specific application package. Reference information for objects that are related to a
specific application package (such as CCF) is provided in the User’s Guide for that
application package as indicated in the following tables.

Top Level Objects

Top level objects are listed in Table 10.

Table 10. Top Level Objects

OBJECT TYPE PURPOSE REFERENCE

MOD_DB One per database. Establishes database name. MOD_DB Object on
page 72
AREA Child of MOD_DB object. Minimum of one per AREA Object on page
database. Used to partition database into one or 74
more configuration areas. A configuration area
is a group of related subsystems.
DEV_DIR Child of MOD_DB object. One directory required Configurable Control
per database. Contains a listing of device Functions (CCF) User’s
descriptor sets for device loops in database. Guide
DEV_DESC Child of DEV_DIR object. One required for each Configurable Control
unique device descriptor set (for example, Functions (CCF) User’s
ON/OFF, OPEN/CLOSE, and so on). Guide

3BUR002120R3701 71
MOD_DB Object Section 3 Database Reference for Objects

MOD_DB Object
Every project requires one database (MOD_DB) object, Figure 22. This object
represents the top of the control structure, and is the starting point for defining a
specific database.
The fields on the MOD_DB templet and their expected input are described below.

DATA BASE OWNERS Field

Entries to the DATABASE OWNERS fields are only applicable for the
Multibus-based configurator platform. In the Multibus-based configurator platform,
database owners have the authority to:
• View, edit and delete the MOD_DB object
• View, edit and delete the AREA and MODUSERS objects which are part of
this database.
• Compile and decompile objects of this database.
• Perform all functions of the user categories specified on lower objects in this
database.
There is no arbitrary limit for the number of owners. The names can be up to 21
characters.

72 3BUR002120R3701
Section 3 Database Reference for Objects MOD_DB Object

Figure 22. Single-Templet Form for a MOD_DB Object

3BUR002120R3701 73
AREA Object Section 3 Database Reference for Objects

AREA Object
The database can be partitioned into configuration areas for user-security and
message routing purposes. An area consists of a group of related subsystems. Every
database must have at least one area. The maximum number of areas in a database is
limited by memory.
Each AREA object, Figure 23 and Figure 24, and its descendants comprise a subtree
under the MOD_DB object. The AREA object has fields for specifying configurator
editors for the configuration area, and for routing alarm/event messages from the
configuration area to message destinations.

Figure 23. Single-Templet Form for an AREA Object, Upper Portion

74 3BUR002120R3701
Section 3 Database Reference for Objects AREA Object

Figure 24. Single-Templet Form for an AREA Object, Lower Portion

AREA EDITORS Field

Entries to the AREA EDITORS fields are only applicable for the Multibus-based
configurator platform. In the Multibus-based configurator platform, they have
authority to modify objects below the AREA objects in their configuration area, and
compile at or below the configuration area level in their configuration area.

MESSAGE CTR, MESSAGE TYPE, and REMOTE TYPE Fields

Use the scroll bar to display the MESSAGE CTR, MESSAGE TYPE, and
REMOTE TYPE fields, Figure 24. These fields are used to specify the destinations
of messages originating in this configuration area. During runtime, the following
types of messages can be generated by the system: CCF event, CCF alarm, TCL
event, TCL billboard and system error.

3BUR002120R3701 75
AREA Object Section 3 Database Reference for Objects

Only the alarms that are absolutely necessary and that provide
useful information to the operator should be configured. The list of
message destinations set up in the system database has a direct
bearing on the communications load resulting from an alarm burst.
Each destination for a message adds to the load. Unnecessary
directing of these messages should be avoided. Reducing the
number of Operator Stations or Loggers that receive these messages
can make a significant difference.
The destination and type of messages are defined by entries to the following fields:

MESSAGE CTR This is the object ID for the device (Console, History, Logger,
Generic DPSS or LCP) to receive messages. The ID must
be the one assigned when the object was inserted in the
database.
MESSAGE TYPE Is the type of message. Valid entries for type are:
CCF_ALARM
CCF_EVENT
CCF_BOTH - This option designates both CCF alarm
messages and event messages.
TCL_EVENT
TCL_BILLBOARD - This option is used to designate TCL
unit messages that are generated by TCL MESG and REPLY
statements and programmable unit alarms generated by
TCL UNIT_ALARM statements.
TCL_BOTH - This option designates both TCL event
messages and billboard messages.
SYSTEM
BOTH - This option designates all message types
designated by CCF_BOTH and TCL_BOTH.
ALL - This option designates all message types.

76 3BUR002120R3701
Section 3 Database Reference for Objects AREA Object

REMOTE TYPE This field is only applicable for systems using multiple
configurators, and when the message destination is in
another configurator domain. The entry specifies the object
type and must be one of the following: CONSOLE,
LOGGER, GENERIC_DPSS, LCP, HISTORY

Message Center Entries for Alarm/Event Loggers

Alarm/Event Loggers are software devices that log messages to printers and/or
disks. You must make an entry in the MESSAGE CTR and MESSAGE TYPE fields
for each type of message that you want to log on a specific logger. Any combination
of message types is valid. If a system has more than one configuration area, entries
must be made to the MESSAGE CTR and MESSAGE TYPE fields of each AREA
object.
In the following examples, LOGGER1 is the object ID assigned to the object
representing this Logger.
Example 1 - These entries send all CCF and SYSTEM messages to LOGGER1:
LOGGER1 CCF_BOTH
LOGGER1 SYSTEM
Example 2 - This entry sends all CCF and TCL messages to LOGGER1.
LOGGER1 BOTH
Example 3 - This entry sends all messages to LOGGER1.
LOGGER1 ALL

Message Center Entries for Historical Services

You can route entries to the History Services software for the recording of alarm and
event messages from this configuration area. The types of messages you can record
are: CCF alarm, CCF event, TCL event, and TCL billboard. The example below
shows how two entries in the MESSAGE CTR and MESSAGE TYPE fields are
used to specify all of these messages are sent to HISTORY1.
HISTORY1 CCF_BOTH
HISTORY1 TCL_BOTH

3BUR002120R3701 77
DEV_DIR and DEV_DESC Objects Section 3 Database Reference for Objects

In the example, HISTORY1 is the object ID for the History object under the
subsystem containing the History Services software. Information about the History
Services is provided in the History Services with Statistical Process Control (SPC)
User’s Guide.

DEV_DIR and DEV_DESC Objects

These objects are required if you are going to configure discrete device loops in
your control scheme. Device descriptors provide a means to display device states in
meaningful terms to system operators (for example, ON/OFF, OPEN/CLOSED).
Each device descriptor set (group of descriptors that describe all the possible states
for a device) requires a dedicated Device Descriptor (DEV_DESC) object. All
Device Descriptor objects are configured as children of the Device Descriptor
Directory (DEV_DIR) object.
The DEV_DIR object, Figure 25, is a child of the MOD_DB object. The directory
provides a means to group all Device Descriptor objects in one place in the
database. You can access the directory to view a list of names of all Device
Descriptor objects.
The only entry required for the DEV_DIR is an object ID. DEV_DESC objects,
Figure 26, are automatically added to the directory as the objects are configured and
the database is compiled.

Figure 25. Single-Templet Form for a DEV_DIR Object

Instructions for configuring the DEV_DESC objects are provided in the

Configurable Control Functions (CCF) User’s Guide.

78 3BUR002120R3701
Section 3 Database Reference for Objects DEV_DIR and DEV_DESC Objects

When you use the multiple configurator feature, device descriptors are part of the
common database and are automatically communicated to the other configurator
domains.

Figure 26. Single-Templet Form for a DEV_DESC Object

3BUR002120R3701 79
GENERICD and Related Objects Section 3 Database Reference for Objects

GENERICD and Related Objects

The GENERICD object is used to represent either a Multibus-based Turbo Node,
HP-UX Advant Station, or Windows-based Engineering Station. Either of these
subsystems can be configured to support a variety of functions (for instance,
console, data processor, control, gateway, and so on). You establish the required
functionality by configuring the appropriate children objects below the GENERICD
object. The GENERICD object and its children objects are listed in Table 11. Note
that some of the children objects required to support certain functionality on a
Multibus-based subsystem are not required when the same functionality is
supported in an HP-UX Advant Station or Windows-based Engineering Station.

Table 11. GENERICD and Related Objects

OBJECT TYPE PURPOSE REFERENCE

GENERICD Child of AREA object. Establishes a Multibus GENERICD Object
subsystem, HP-UX Advant Station, or Windows- on page 84
based Engineering Station under the
configuration area. Children of the GENERICD
object determine the functional characteristics of
the subsystem (for example, Console/Data
Processor, Console/History, Ethernet Gateway,
and so on).
MODUSERS Child of GENERICD object. One required for any MODUSERS Object
configurator/data processor (CDP) subsystem, if on page 89
that CDP is used to configure Multibus-based
consoles. This object defines names, passwords,
access privileges for console users.
CONSLIB Child of GENERICD object. One required for any CONSLIB Object on
Multibus subsystem supporting console page 92
functionality.
MSG_ROUT Child of CONSLIB object. One required for each MSG_ROUT Object
CONS_LIB object. Defines destinations for log-on on page 93
and alarm-acknowledge messages.

80 3BUR002120R3701
Section 3 Database Reference for Objects GENERICD and Related Objects

Table 11. GENERICD and Related Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

PORTS Child of GENERICD object. Required for any PORTS Object on
Multibus subsystem supporting serial devices page 95
including keyboards, printers, PLC gateways, IBM
PC gateways, and so on. One object required per
serial I/O module installed in Multibus cardfile (up
to two serial I/O modules per cardfile and up to
eight ports per module).
LOG_DETL Child of GENERICD object. One required for any LOG_DETL Object
subsystem that supports an alarm/event logger. on page 104
REP_BLDR Child of GENERICD object. One required for any Report Services
subsystem that supports Report Services User’s Guide
software.
HISTORY Child of GENERICD object. One required for any History Services with
subsystem that supports History Services SPC User’s Guide
software. There can be up to ten history nodes
maximum per system.
RECORDER Child of HISTORY object. One required per History Services with
logical recorder configured in History node. There SPC User’s Guide
can be up to 16 recorders per History node.
CHNL_DEF Child of RECORDER object. Establishes History Services with
operating parameters for individual recording SPC User’s Guide
channels. Each CHNL_DEF object supports up
to 15 channels.
SPC_DIR Child of RECORDER object. One required for History Services with
each recorder supporting SPC points. SPC User’s Guide
SPC Child of SPC_DIR object. Establishes operating History Services with
parameters for SPC. One required for each SPC User’s Guide
variable having SPC applied.
A_PANEL Child of GENERICD object. Required for Multibus Local Control Panel
subsystems that support one or more Local User’s Guide
Control Panels (LCPs).

3BUR002120R3701 81
GENERICD and Related Objects Section 3 Database Reference for Objects

Table 11. GENERICD and Related Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

TCL_DEV Child of GENERICD object. Required for any Taylor Control
subsystem that supports Taylor Control Language (TCL)
Language (TCL) development. User’s Guide
URELNAME Child of TCL_DEV object. Required to support Taylor Control
unit relativity concept for TCL development. Language (TCL)
User’s Guide
CI Child of GENERICD object. One required for Ethernet Interface
Multibus subsystems that support a gateway to User’s Guide or
an external computer (that is, an Ethernet Serial Interface
gateway for DEC/VAX or serial gateway for an User’s Guide
IBM PC).
CI_DEF Child of CI object. One required for each type of Ethernet Interface
computer interface being supported by the User’s Guide or
Multibus subsystem (that is, one for DEC VAX Serial Interface
and one for HP if both devices are being User’s Guide
supported by the same Multibus subsystem).
AR_DATA(1) Child of GENERICD object. Required for Multibus Taylor AccuRay 1180
subsystems that support a serial gateway for an MICRO Interface
AccuRay 1180 MICRO. Quantity depends upon User’s Guide.
operating characteristics of the gateway.
AR_INDEX(1) Child of AR_DATA object. Quantity depends upon Taylor AccuRay 1180
operating characteristics of the gateway. MICRO Interface
User’s Guide
AR_INST(1) Child of AR_DATA object. Quantity depends upon Taylor AccuRay 1180
operating characteristics of the gateway. MICRO Interface
User’s Guide
CCF Child of GENERICD object. One required for Configurable Control
subsystems that run Configurable Control Functions (CCF)
Functions (CCF). Establishes basic CCF User’s Guide
operating parameters for the subsystem,
particularly the base processing rate upon which
individual loop processing rates are based.

82 3BUR002120R3701
Section 3 Database Reference for Objects GENERICD and Related Objects

Table 11. GENERICD and Related Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

MULTIBIO Child of GENERICD object. One required for Configurable Control
Multibus subsystems with High Density I/O. Functions (CCF)
Establishes general parameters such as number User’s Guide
and type of I/O modules to be installed in this
subsystem.
REMOTEIO Child of GENERICD object. Required to support Taylor Remote I/O
Taylor Remote I/O in a Multibus subsystem. One User’s Guide
required per field bus controller in Multibus
cardfile (up to six maximum).
LL_DEV Child of GENERICD object. Required for Taylor Ladder Logic
subsystems that run Taylor Ladder Logic User’s Guide
software.
SMART_IO One required for each smart device serial port. Smart Device
Interface User’s
Guide
SMARTNET One required for each SHIM connected to the Smart Device
port Interface User’s
Guide
(1) Although the AR_DATA, AR_INDEX, and AR_INST objects are available for configuration, the functionality to
support AccuRay DIU Interfaces has not yet been implemented. Therefore, do not include these objects in
databases you configure with the AdvaBuild Version 3.3 software.

3BUR002120R3701 83
GENERICD Object Section 3 Database Reference for Objects

GENERICD Object
This object represents either a Windows-based Engineering Station, HP-UX Advant
Station, or Multibus-based subsystem, Figure 27.

Figure 27. Single-Templet Form for a GENERICD Object

The GENERICD object has the following configurable attributes:

PHYSICAL DEVICE Field

This is the DCN node address. This must be the decimal equivalent of the hex
address set on the DCN switch in the subsystem. If this node contains the database
configurator software, it must be at a physical address with a lower order hex digit
of 1 as given in Table 12. Be sure to enter the decimal equivalent value in the

84 3BUR002120R3701
Section 3 Database Reference for Objects GENERICD Object

PHYSICAL DEVICE field. If the node does not contain the Configurator it can be
at any physical address from 1 to 255 decimal.

Table 12. DCN Addresses for Nodes with Configurator Software

Decimal
Address (Hex)
Equivalent
01 1
11 17
21 33
31 49
41 65
51 81
61 97
71 113
81 129
91 145
A1 161
B1 177
C1 193
D1 209
E1 225
F1 241

AUTO START Field

This field determines whether or not the node starts automatically when the
software is downloaded. The only valid choice for a GENERICD node is YES.

3BUR002120R3701 85
GENERICD Object Section 3 Database Reference for Objects

SOFTWARE NAME Field

This field determines the functionality of the generic Multibus node. The choices
are:

TURBO This option sets the node up for all turbo node functions.
TURBODP This option sets the node up for data processing functions
only (no history, console, or interfaces).
TURBOGW This option sets the node up for data processing, history
and interface functions (no console).
GATEWAY This option sets the node up as a dedicated VAX
gateway. If the system contains a VAX or Smart Device
Interface in combination with other turbo node functions,
use either TURBO or TURBOGW as described above.

86 3BUR002120R3701
Section 3 Database Reference for Objects GENERICD Object

In large systems that are in danger of exceeding the maximum

number of ROUTE_LIST records (255), the following
configuration changes can be made to reduce the number of
ROUTE_LIST records in the system.

Certain Advant Station node types do not need any ROUTE_LIST

records or only need one. ES nodes only need one and IMS nodes
do not need any ROUTE_LIST records. For such nodes, prepend an
ES or IMS to your entry in the SOFTWARE NAME field of the
GENERICD object. If the node type is Multibus-based and you
prepend ES or IMS to the entry in the SOFTWARE NAME field, an
invalid software name error will be reported.

If an HP-UX Advant Station node (with a prepended entry in the

SOFTWARE NAME field of its GENERICD object) has not been
compiled or a database compile without saving database references
is occurring, then for an IMS node no ROUTE_LIST records are
produced. For an ES node, only the ROUTE_LIST record for
diagnostics is produced.

If the HP-UX Advant Station node was compiled before you

prepended ES or IMS to the entry in the SOFTWARE NAME field
of its GENERICD object, then you must recompile the node and
install the database to remove extra ROUTE_LIST records and
compress the final database table.

DO RATE Field
This is the minimum digital output rate for the Multibus subsystem when I/O
functionality is implemented in the subsystem. Enter the DO Rate in milliseconds.
Valid rates are: 20, 40, 100, 200, or 1000. DO Rate is described in greater detail in
the Configurable Control Functions (CCF) User’s Guide.

SECONDARY DP, BACKUP ENABLE, and BACKUP OVERRIDE Fields

These fields have not been implemented. Leave them at their default values.

3BUR002120R3701 87
GENERICD Object Section 3 Database Reference for Objects

DEFAULT ENVIRONMENT Field

This field is only applicable if the node is configured for Multibus console
functionality. If you want a console environment automatically downloaded to the
subsystem when it is booted, you enter the name of the environment into this field.

NODE TYPE Field

This field specifies the hardware platform for the GENERICD node. The choices
are:

MOD300_NODE This option is for a Multibus-based node.

ADVANT_STATN This option is for a Windows-based or HP-UX Advant
Station Engineering Station.

88 3BUR002120R3701
Section 3 Database Reference for Objects MODUSERS Object

MODUSERS Object
The MODUSERS object, Figure 28, is required for configurator/data processor
subsystems that are being used to configure Multibus-based Console subsystems (or
Turbo Nodes that support console functionality in addition to other functions). This
object establishes the access class for users on this console. Fields are provided for
entering user IDs, associated passwords, access class, security device, and log in
method. Each line in this templet represents one user.

Figure 28. Single-Templet Form for a MODUSERS

The columns of fields in this templet are:

3BUR002120R3701 89
MODUSERS Object Section 3 Database Reference for Objects

USER ID Field
21 characters maximum.

PASSWORD Field
12 characters maximum.

ACCESS CLASS Field

This field determines the access class for the user. The choices are:

OP Operator (view and control process through console

displays)
SU Supervisor (operator functions plus tuning)
EN Engineer (supervisor functions plus configuration and
application building)

SEC DEV Field

This field is only applicable when the Security Key function is implemented for this
node. The valid choices are:

DATA KEY This option enables the data key function. This means the
system checks for the data key device when you log in. If
the key is found, the log in is allowed. If the key is not
found, an error message is generated.
NONE This option disables the data key function.

90 3BUR002120R3701
Section 3 Database Reference for Objects MODUSERS Object

AUTO LOG Field

This field determines how the user logs in and out when the Security Key function is
implemented. The choices are:

ON When you insert the key you are logged in, and you
remain logged in when the key is removed. Log out is via
the ENVIRONLOGON display.
OFF To log in you must insert the key and log in via the
ENVIRONLOGON display. You log out by simply
removing the key.
NONE To log in you must insert the key and log in via the
ENVIRONLOGON display. You remain logged in when
the key is removed. Log out is via the ENVIRONLOGON
display.
BOTH Log in is automatic when you insert the key. Log out is
automatic when you remove the key.

EXPORT or EXPORT TO DEVICES

This field is only applicable when the system has multiple configurators.

3BUR002120R3701 91
CONSLIB Object Section 3 Database Reference for Objects

CONSLIB Object
A CONSLIB object, Figure 29, is required for Multibus subsystems that support
console functionality. This object is NOT required for HP-UX Advant Station
Operator Stations.

Use of this object is restricted. Entries should be made only for

purchased software packages. Use of software packages other than
those expressly purchased is in violation of the licensing agreement.
This object has columns of fields for specifying the software packages that will be
accessible from the Library Display on this console. Each line in the templet
represents one software package.

Figure 29. Single-Temple Form for a CONSLIB Object

This templet is limited to 37 lines. The columns of fields in this templet are:

92 3BUR002120R3701
Section 3 Database Reference for Objects MSG_ROUT Object

PACKAGE NAME Field

This field contains pre-defined names the system uses to identify the software.

DISPLAY ID Field
The name you enter in this field appears on the Library Display for this console. The
DISPLAY ID is the name you use to access the corresponding software package
during runtime via the Display Request key and bottom line entry function.

DEVICE NAME Field

This field specifies the node where software resides. If it is the node that contains
the Configurator, use the word CONFIGURATOR. If it is a different node, enter the
Object ID of that node.
If you are using the multiple configurator feature, the entry CONFIGURATOR
specifies the node that contains the configurator for the local domain.

NUMBER OF ARGUMENTS Field

Enter 0 (zero).

MSG_ROUT Object
Every CONSLIB object requires a MSG_ROUT object, Figure 30. This object
provides the means to configure how console log on and/or alarm acknowledgment
messages are routed to History subsystems and loggers.

3BUR002120R3701 93
MSG_ROUT Object Section 3 Database Reference for Objects

Figure 30. Single-Templet Form for a MSG_ROUT Object

The MSG_ROUT object has the following configurable attributes:

94 3BUR002120R3701
Section 3 Database Reference for Objects PORTS Object

MESSAGE CTR and MESSAGE TYPE Fields

To route messages, enter the message destinations and the types of messages to be
routed to these destinations in the MESSAGE CTR and MESSAGE TYPE fields.
Indicate the message destination by entering the object ID. For message type, enter
any one of the following:

CONS_LOG_ONS Console log on

CONS_ACKS Console alarm acknowledgment
CONS_BOTH Both console log on and console alarm acknowledgment

There is a limit of 256 destinations for messages. Messages of a specific type from a
configuration area can be sent to no more than 40 destinations.

Only the alarms that are absolutely necessary and that provide
useful information to the operator should be configured. The list of
message destinations set up in the system database has a direct
bearing on the communications load resulting from an alarm burst.
Each destination for a message adds to the load. Unnecessary
directing of these messages should be avoided. Reducing the
number of Operator Stations or Loggers that receive these messages
can make a significant difference.

REMOTE TYPE Field

This field is only applicable for systems using multiple configurators, and when the
message destination is in another configurator domain. The entry specifies the
object type and must be one of the following: CONSOLE, LOGGER,
GENERIC_DPSS, LCP, HISTORY.

PORTS Object
The PORTS object is required for any Multibus or Controller subsystem that
supports a serial interface, Figure 31. The physical ports of a Multibus subsystem
are provided by the 6007B Serial I/O Module. A serial I/O module provides 8 serial
ports. A Multibus subsystem can contain either one or two of these modules. Jumper

3BUR002120R3701 95
PORTS Object Section 3 Database Reference for Objects

positions on a module determine if it is module 1 (ports 1 to 8) or module 2 (ports 9

to 16). The jumper positions are described in the Multibus Principal Modules
instruction book.

Figure 31. Single-Templet Form for a PORTS Object

A general description of the fields of the PORTS object (independent of the type of
device being connected) is provided below. A more specific description for each
kind of device that can be connected is provided following the general descriptions.

NUM Field
Number of the serial port to which the device is connected. Only those ports actually
used need be configured. Valid entries are any integer from 1 to 16.

PORT NAME Field

User-assigned name for the port, up to 12 characters in length and unique system
wide.

96 3BUR002120R3701
Section 3 Database Reference for Objects PORTS Object

TYPE Field
The available port types include the following:

KEYBOARD Operator Control Panel or Alphanumeric Keyboard

TOUCHSCR 19-inch Touch Screen
PRINTER Black and White Printer, Multicolor Printer, Epson Printer
(port 8 only - version 3 firmware or later)
GENERIC Standard port for devices without special requirements
MODBUSB For use with Gould Modicon 584 and 984 PLCs, Merlin
Gerin PB80 and PB400 PLCs, and smart devices
TERMCHAR Texas Instrument Highway, or any device using up to
three ASCII termination characters
MODBUSA Defaults to the TERMCHAR port type
AB_POLL For use with the Allen-Bradley Highway (version 2
firmware or later)
MICROMAC Defaults to the TERMCHAR port type
MOD30 MOD 30 Instrument Link
DDCMP Defaults to the TERMCHAR port type
PMM For use with the AccuRay 1180M (MICRO system) port
type (version 4 firmware or later)
SECURKEY For use with the Security Key device read-only channels
REMOTCRT For use with the remote console
PSAP Page Selector Alarm Panel
DATA KEY Data Key

CRT Field
The CRT field is used to specify which color monitor a KEYBOARD or
TOUCHSCR port is associated with. It is also used to specify the PLC redundancy
option.

3BUR002120R3701 97
PORTS Object Section 3 Database Reference for Objects

Valid entries for the CRT field when a KEYBOARD or TOUCHSCR is connected
are: 1, 2, 3, 4, or ALL. Do not enter spaces or commas. For example, enter 12 to use
CRTs one and two.
Valid entries to specify PLC redundancy are:

ALL If all PLCs on a Data Highway lose communications, a port swap will
be attempted. If this swap is unsuccessful in re-establishing
communications a failover of the SC Controller will be attempted.
1NO If one PLC on a Data Highway loses communications, a port swap
will be attempted. A communications loss will NOT cause a failover of
the SC Controller.
ANO If all PLCs on a Data Highway lose communications, a port swap will
be attempted. A communications loss will NOT cause a failover of the
SC Controller.
ONE or If one PLC on a Data Highway loses communications, a port swap
blank will be attempted. If this swap is unsuccessful in re-establishing
communications a failover of the SC Controller will be attempted.

SPEED Field
This field specifies the baud rate for the port. Valid entries are: 50, 75, 110, 135,
150, 200, 300, 600, 1050, 1200, 1800, 2000, 2400, 3600, 4800, 7200, 9600, 19200

WD Field
This field specifies the size of the word length in bits. Valid entries are: 5, 6, 7, 8

PARITY Field
This field specifies the type of parity checking for confirming data integrity. Valid
entries are: NONE, ODD, EVEN, MARK, SPACE

STOP Field
This field specifies the number of stop bits. Valid entries are: 1, 1.5, 2

98 3BUR002120R3701
Section 3 Database Reference for Objects PORTS Object

ITO Field
Input Time Out defines the maximum time for the completion of an input operation.
If this time is exceeded, an error code is returned to the application program. Enter a
time from 0.1 to 9999 seconds. Six seconds is the default and is typically used for
KEYBOARD, TOUCHSCR, GENERIC, and most MODBUSB ports. Four seconds
is a typical value for TERMCHAR and PMM ports. Three seconds is a typical value
for MODBUSB ports that support smart device communication. One second is a
typical value for redundant MODBUSB ports that support programmable logic
controllers (PLCs).

OTO Field
Output Time Out defines the maximum time for the completion of an output
operation. If this time is exceeded, an error code is returned to the application
program. Enter a time from 0.1 to 9999 seconds. Six seconds is the default. One
second is a typical value for AB_POLL and PMM ports, and six seconds is a typical
value for all other port types.

TERM CHR Field

The termination character entry is used only with the TERMCHAR and PMM port
types. It is used to specify, in standard ASCII code, up to three termination
characters. For example, a carriage return, line feed, and delete termination
character sequence is entered as 0D 0A 7F. A space is required between each ASCII
code for each termination character.

BUF SZ Field
Buffer size in bytes, that is, the size of the input and output buffers used by a TCL
program referencing a port. Enter a value from 1 to 512.

Entries to Fields of PORTS Object for Interfaces

The entries required to support a serial interface for a specific device are described
in the applicable instruction books as indicated below.
IBM PC Taylor IBM PC Interface User’s Guide
MOD 30 Instruments Taylor MOD 30 Interface User’s Guide

3BUR002120R3701 99
PORTS Object Section 3 Database Reference for Objects

PLCs (various models) Taylor Programmable Controller Interface User’s

Guide
AccuRay 1180M Taylor AccuRay 1180 MICRO and AccuRay 1190 DIU
Interface User’s Guide
Smart Devices Smart Device Interface User’s Guide

Entries to Fields of PORTS Object for Keyboards, Operator Control Panels,

and Page Selector Alarm Panels (PSAPs)
These devices require specific entries for speed, word length, parity, stop bits, and
ITO.
SPEED 4800
WORD 7
PARITY ODD
STOP 2
ITO 6

Entries to Fields of PORTS Oject for Touchscreens

Touchscreens require specific entries for speed, word length, parity, stop bits, and
ITO.
SPEED 1200
WORD 8
PARITY EVEN
STOP 1
ITO 6

Entries to Fields of PORTS Object for Printers

The printer protocol is used to talk to the 6006J Printer, the EP530/531 Printer, and
the Epson Printer.
NUM The number of the port the PRINTER is connected to.

100 3BUR002120R3701
Section 3 Database Reference for Objects PORTS Object

TYPE PRINTER
The following values are defaults for 6006J Printers. In all cases, check your printer
and enter values that coincide with the printer's configuration.
SPEED 9600
WORD 7
PARITY ODD
STOP 1
ITO 6
The following values are defaults for EP530/531 Printers. In all cases, check your
printer and enter values that coincide with the printer's configuration.
SPEED 9600
WORD 7
PARITY ODD
STOP 1
Refer to the appropriate Advant Station Hardware User’s Guide for the proper
printer hardware configuration settings.

Entries to Fields of PORTS Object for Security Key

Security keys can be used to provide additional security for Multibus-based
consoles and Turbo Nodes. To implement a Security Key, the following is required:
• Each console or Turbo Node having a Security Key for log on and log off
requires a read-only serial channel for a Security Key device.
• Each console or Turbo Node used to configure Security Keys needs a
read/write channel for a Security Key device. You must have at least one of
these.
• The USERS object for the Turbo Node containing the Configurator must have
Security Key related entries for each user.

3BUR002120R3701 101
PORTS Object Section 3 Database Reference for Objects

A read-only channel port for the device requires the following entries:

NUM number of port

PORT NAME unique name (up to 12 characters)
TYPE SECURKEY
CRT Specifies which monitors the Security Key log ons and log
offs are associated with. Enter the CRT number(s) (1
through 4 or ALL). Do not enter spaces or commas. For
example, enter 12 to use CRTs one and two.
SPEED 300 to 4800 Baud. Must match the DIP switch setting for
the device. 4800 is the recommended setting.
WD 8
PARITY odd
STOP 1
TERM FF

The port for a read/write channel for the device requires the following entries:

NUM number of port

PORT NAME unique name (up to 12 characters)
TYPE TERMCHAR
SPEED 300 to 4800 Baud. Must coincide with the DIP switch
setting for the device. 1200 is the normal setting, it is
recommended that the read/write channel be set different
than the read-only channel.
WD 8
PARITY odd
STOP 1
ITO optional (default is 6)

102 3BUR002120R3701
Section 3 Database Reference for Objects PORTS Object

OTO optional (default is 6)

TERM FF

Entries to Fields of PORTS Object for Programmable Logic Controllers (PLCs)

You can connect Programmable Logic Controllers (PLCs) to a Multibus node via a
6007B Serial I/O Module. Refer to the Taylor Programmable Controller Interface
User's Guide.

Entries to Fields of PORTS Object for Smart Devices

You can connect smart devices to a Multibus node via a Small HART Interface
Module (SHIM) connected to a 6007BG Serial I/O Module. Refer to the Smart
Device Interface User's Guide.

3BUR002120R3701 103
LOG_DETL Object Section 3 Database Reference for Objects

LOG_DETL Object
A LOG_DETL object is required for subsystems that support an alarm/event logger.
This object in combination with the AREA object determine which messages are
logged, Figure 32.

Figure 32. Single-Templet Form for a LOG_DETL Object

Color is supported by color Genicom printers only. Disregard object

attributes related to color for other printers.

You define the logger’s attributes via the following fields of the LOG_DETL object:

104 3BUR002120R3701
Section 3 Database Reference for Objects LOG_DETL Object

TEMPLET NAME
This field specifies the logger name. This name appears on each page the logger
prints. It must also be entered into the MESSAGE CTR fields of the AREA objects
for the configuration areas where the logger resides. Valid entry is a character string
of up to 8 characters.

LOGGER DESCRIPTION
This field allows you to specify a descriptor for the logger. The descriptor appears
on each page the logger prints. Valid entry is a character string of up to 24
characters.

BACKUP LOGGER NAME

This field allows you to designate another logger as the backup for the logger being
configured. If the primary logger cannot print the message, it sends it to the backup
logger. The backup logger must be on another subsystem. Valid entry is the name
assigned to the backup logger via its TEMPLET NAME field.

PRINTER NAME
This field is used to specify the printer where the logger prints its messages. The
printer must be part of the subsystem containing the logger. Note that the printer
name specified here must match the printer name configured in the UNIX
environment (including upper-/lower-case).
If the logger resides on a Multibus-based node, it must have a serial channel
configured for it via the PORTS object. Valid entry is the printer name which was
assigned to the printer via the PORT NAME field of the PORTS object.
If the logger resides on an Advant Station-based node, a default printer device may
already be configured (use the LL command in HP-UX to list the contents of the
/dev file). If you need to configure a printer device, refer to the Advant Station 500
Series with AdvaCommand 1.8/AdvaBuild 2.9 User’s Guide.

3BUR002120R3701 105
LOG_DETL Object Section 3 Database Reference for Objects

BACKUP PRINTER NAME

This field is used to specify the printer the logger sends messages to if the primary
printer is not functioning. It is recommended that the backup printer not be in the
same subsystem as the primary printer. Valid entry is the printer name which was
assigned to the printer via the PORT NAME field of the PORTS object.

This field is not applicable for loggers that reside on an Advant

Station-based node.

MAX # MSGS ON DISK

This field is applicable only for loggers defined for Data Processor subsystems. This
field sets up a buffer on disk used to store messages until the printer is free to print
them. Valid entry is an integer n where n is the number of messages. The default is:
0.

MAX # MSGS IN MEMORY

This field sets up a buffer in memory used to store messages until the printer is free
to print them. Valid entry is an integer n where n is the number of messages. The
default is: 50.

STD ALARM COLOR

The field is applicable only when a color printer is assigned to the logger. This field
specifies the color used to print messages for the standard priority (priority 3) CCF
alarms. Valid entries are: RED, BLUE, GREEN, BLACK, MAGENTA, CYAN,
YELLOW. The default is: BLUE.

106 3BUR002120R3701
Section 3 Database Reference for Objects LOG_DETL Object

STD ALARMS PRINTED

This field enables the logging of standard priority CCF alarm messages. These
messages are not logged unless entries are also made to the MESSAGE CTR field of
the AREA templet where the messages originate. Valid entries are:

YES Log standard priority CCF alarm messages

NO Do not log standard priority CCF messages

Default is: NO

STD PRINT TYPE

This field specifies the type face used to print the standard priority CCF alarm
messages. Valid entries are:

BOLD print messages in a bold type face

UNDERLN print messages in the normal type face, underlined
NORMAL print messages in the normal type face

Default is: UNDERLN

TRIP LIMIT HIGH

This field specifies the trip point that, when exceeded, causes a message to be
printed warning that the logger buffer is almost full. The trip point is expressed as a
percentage of the message buffering capacity, which is the sum of the messages that
can be stored in the memory buffer (MAS # MSGS IN MEMORY field) and the
disk buffer (MAX # MSGS ON DISK field). Valid entry is an integer nn which
represents a percentage of the capacity of the memory buffer. Default is: 70.
For example, if TRIP LIMIT HIGH is 70, and the logger can buffer 50 messages in
memory and 40 messages on disk, the warning message is printed when the buffers
contain 63 messages (70% of 90).

3BUR002120R3701 107
LOG_DETL Object Section 3 Database Reference for Objects

TRIP LIMIT HIGH HIGH

This field specifies a more critical trip point that, when exceeded, causes a second
(and more urgent) message to be printed warning the logger buffer is on the verge of
being full. Like TRIP LIMIIT HIGH, this value is expressed as a percentage of the
message buffering capacity. This value must be higher than the entry for the TRIP
LIMIT HIGH field. Valid entry is an integer nn which represents a percentage of the
capacity of the memory buffer. Default is: 90.

EVENT COLOR
This field is applicable only when a color printer is assigned to the logger. This field
specifies the color used to print event messages. These messages consist of CCF
parameter change messages, all TCL messages and the subset of the system
diagnostic messages the logger prints. Valid entries are: RED, BLUE, GREEN,
BLACK, MAGENTA, CYAN, YELLOW. Default is: GREEN.

EVENTS PRINTED
This field enables the logging of event messages. These messages consist of CCF
parameter change messages, all TCL messages and the subset of the system
diagnostic messages the logger prints. These messages are not logged unless entries
are also made to the MESSAGE CTR fields of the AREA templets where the
messages originate.
Valid entries are:

YES Log event messages.

NO Do not log event messages.

Default is: NO

108 3BUR002120R3701
Section 3 Database Reference for Objects LOG_DETL Object

EVENT PRINT TYPE

This field specifies the type face used to print the event messages. Valid entries are:

BOLD print the messages in a bold type face

UNDERLN print the messages in the normal type face, underlined
NORMAL print the messages in the normal type face

Default is: NORMAL

HP ALARM COLOR
This field is applicable only when a color printer is assigned to the logger. This field
specifies the color used to print messages for the high priority (priority 1) CCF
alarms.
Valid entries are: RED, BLUE, GREEN, BLACK, MAGENTA, CYAN,
YELLOW
Default is: RED

HP ALARMS PRINTED
This field enables the logging of high priority CCF alarm messages. These messages
are not logged unless entries are also made to the MESSAGE CTR fields of the
AREA templets where the messages originate. Valid entries are:

YES Log high priority CCF alarm messages.

NO Do not log high priority CCF alarm messages.

Default is: YES

3BUR002120R3701 109
LOG_DETL Object Section 3 Database Reference for Objects

HP PRINT TYPE
This field specifies the type face used to print the high priority CCF alarm messages.
Valid entries are:

BOLD print the message in a bold type face

UNDERLN print the message in the normal type face, underlined
NORMAL print the message in the normal type face

Default is: BOLD

MED ALARM COLOR

This field is applicable only when a color printer is assigned to the logger. This field
specifies the color used to print messages for the medium priority (priority 2) CCF
alarms. Valid entries are: RED, BLUE, GREEN, BLACK, MAGENTA, CYAN,
YELLOW.
Default is: BLACK

MED ALARMS PRINTED

This field enables the logging of medium priority CCF alarm messages. These
messages are not logged unless entries are also made to the MESSAGE CTR fields
of the AREA templets where the messages originate. Valid entries are:

YES Log medium priority CCF alarms.

NO Do not log medium priority CCF alarms.

Default is: YES

110 3BUR002120R3701
Section 3 Database Reference for Objects LOG_DETL Object

MED PRINT TYPE

This field specifies the type face used to print the medium priority CCF alarm
messages. Valid entries are:

BOLD print the message in a bold type face

UNDERLN print the message in the normal type face, underlined
NORMAL print the message in the normal type face

Default is: NORMAL

3BUR002120R3701 111
CONSOLE-Related Objects Section 3 Database Reference for Objects

CONSOLE-Related Objects
The CONSOLE object represents a Multibus-based console subsystem. The
children of the CONSOLE object are a subset of the children for the GENERICD
object (only those children required to support console functionality), Table 13. The
CONSOLE object is described below. Refer to GENERICD and Related Objects on
page 80 for details regarding the other console-related objects.

Table 13. Console and Related Objects

OBJECT TYPE PURPOSE REFERENCE

CONSOLE Child of AREA object. Establishes one Multibus CONSOLE Object on
subsystem as a dedicated Console node under page 113
the configuration area.
CONSLIB Child of CONSOLE object. One required for any CONSLIB Object on
Multibus subsystem supporting console page 92
functionality.
MSG_ROUT Child of CONSLIB object. One required for each MSG_ROUT Object on
CONSLIB object. Defines destinations for log-on page 93
and alarm-acknowledge messages.
PORTS Child of GENERICD object. Required for Multibus PORTS Object on page
subsystems that support serial devices including 95
keyboards, printers, PLC gateways, IBM PC
gateways, and so on. One object required per
Serial I/O Module installed in Multibus cardfile (up
to two Serial I/O Modules per cardfile and up to
eight ports per module).
LOG_DETL Child of GENERICD object. One required for LOG_DETL Object on
subsystems that support an alarm/event logger. page 104

112 3BUR002120R3701
Section 3 Database Reference for Objects CONSOLE Object

CONSOLE Object
The CONSOLE object is used to represent a Multibus subsystem that supports just
console functionality, Figure 33.

Figure 33. Single-Templet Form for a CONSOLE Object

You define the attributes for the console via the following fields of the CONSOLE
object:

PHYSICAL DEVICE
This is the DCN node address. This must be the decimal equivalent of the hex
address set on the DCN switch in the subsystem. Be sure to enter the decimal

3BUR002120R3701 113
CONSOLE Object Section 3 Database Reference for Objects

equivalent value in the PHYSICAL DEVICE field. It can be at any physical address
from 2 to 255 decimal.

SOFTWARE NAME
This field determines the functionality of the Multibus node. The only valid choice
is:

CONSOLE This option sets the node up for console functionality.

AUTO START
This field determines whether or not the node starts automatically when the
software is downloaded. The only valid choice is YES.

DEFAULT ENVIRONMENT
If you want a console environment automatically downloaded to the subsystem
when it is booted, enter the name of the environment into this field. The
environment must be configured and made loadable according to the Console
Configurator User’s Guide.

114 3BUR002120R3701
Section 3 Database Reference for Objects Controller and Related Objects

Controller and Related Objects

The Controller subsystem (CONT_SS) and related objects are listed in Table 14.

Table 14. CONT_SS and Related Objects

OBJECT TYPE PURPOSE REFERENCE

CONT_SS Child of AREA object. Establishes one CONT_SS Object on
Controller subsystem (SC or 6000-series) under page 117
a configuration area.
CNTRLLER Child of CONT_SS object. One required per CNTRLLER Object on
Primary Control Module (up to eleven per page 119
redundant Controller subsystem). Establishes
basic operating parameters for Primary Control
Module.
BUC Child of CONT_SS object. One required per CNTRLLER Object on
backup controller (one, two, or three per page 119
redundant Controller subsystem, depending
upon redundancy ratio).
PORTS Child of CNTRLLER object. Required for Control PORTS Object on page
Modules that support serial devices such as 95
PLC gateways.
A_PANEL Child of CNTRLLER object. One required for Local Control Panel
Control Modules that support Local Control (LCP+) User’s Guide
Panels (LCPs).
CCF Child of CNTRLLER object. Required for Control Configurable Control
Modules that support Configurable Control Functions (CCF) User’s
Functions (CCF). Establishes basic CCF Guide
operating parameters for the module,
particularly the base processing rate upon
which individual loop processing rates are
based.
REMOTEIO Child of CNTRLLER object. Required for Control Taylor Remote I/O
Modules that support Taylor Remote I/O (TRIO) User’s Guide

3BUR002120R3701 115
Controller and Related Objects Section 3 Database Reference for Objects

Table 14. CONT_SS and Related Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

CONT_IO Child of CNTRLLER object. Required for Control Configurable Control
Modules that support direct I/O. Functions (CCF) User’s
Guide
LL_DEV Child of CNTRLLER object. Required for Control Taylor Ladder Logic
Modules that run Taylor Ladder Logic software. (TLL) User’s Guide
TCL_RUN Child of CNTRLLER object. Required for Control Taylor Control
Modules that run Taylor Control Language Language (TCL) User’s
(TCL). Guide
TCL_MBOX Child of TCL_RUN object. One required for each Taylor Control
mailbox being established for a Control Module. Language (TCL) User’s
Guide
DIG_MA_S Child of CNTRLLER object. Required for Control Operator Station
Modules that support digital M/A stations. instruction book for
Multibus-based
Subsystems

116 3BUR002120R3701
Section 3 Database Reference for Objects CONT_SS Object

CONT_SS Object
This object represents a Controller subsystem in the database, Figure 34.

Figure 34. Single-Templet Form for a CONT_SS Object

You configure the attributes of the CONT_SS object via the following fields:

PHYSICAL DEVICE
This is the DCN node address. This must be the decimal equivalent of the hex
address set on the D/F (DCN-to-F Bus) switch in the subsystem. Be sure to enter the
decimal equivalent value in the PHYSICAL DEVICE field. It can be at any physical
address from 2 to 255 decimal.

3BUR002120R3701 117
CONT_SS Object Section 3 Database Reference for Objects

REDUNDANCY OPTION
This field specifies the number of Backup Control Modules that can be supported in
the subsystem. The choices are:

NO BACKUPS No backup controllers

1 BACKUP One backup controller in cardfile no. 1. This backup can
support up to 11 Primary Control Modules.
3 BACKUPS Three backup controllers. One in each of the three
cardfiles. Each backup controller can support up to three
Primary Control Modules in its respective cardfile.

118 3BUR002120R3701
Section 3 Database Reference for Objects CNTRLLER Object

CNTRLLER Object
Each Control Module in a Controller subsystem must be represented by a
CNTRLLER object, Figure 35.

Figure 35. Single-Templet Form for a CNTRLLER Object

You define the attributes of the CNTRLLER object via the following fields:

PHYSICAL DEVICE
This field specifies the location of the Control Module in the Controller subsystem.
Valid entries are an integer from 1 to 12, where 1, 2, 3, and 4 represent the slots in
cardfile 1, 5, 6, 7, and 8 represent the slots in cardfile 2, and 9, 10, 11, and 12

3BUR002120R3701 119
CNTRLLER Object Section 3 Database Reference for Objects

represent the slots in cardfile 3. If the redundancy option is NO BACKUP, then a

Primary Control Module can occupy any position in the controller cardfile. If the
redundancy option is 1 BACKUP, SLOT NO. 4 in the first cardfile is reserved for
the backup controller. If the redundancy option is 3 BACKUPS, slots 4 (cardfile 1),
8 (cardfile 2), and 12 (cardfile 3) are reserved for backup controllers.

SOFTWARE NAME Field

This field specifies the software downloaded to the controller at start-up. A backup
controller and all the primary controllers that it supports must have the same
software name.
Valid entries are:

CONTROLLER This software is for a 6004B Control Module in a

subsystem using either no redundancy or 11 to 1
redundancy. The subsystem does not use Manual/Auto
Operator Stations (M/A Station) or LCPs.
CTLR3TO1 This software is for a 6004B Control Module in a
subsystem using 3 to 1 redundancy (that is, there can be
backup controllers in slots 4, 8 and 12). The subsystem
does not use Manual/Auto Operator Stations (M/A
Station) or LCPs.
DIGITAL This software is for Control Modules that use the M/A
Station option and 11 to 1 redundancy. This option is
described in the Operator Station instruction book for the
Multibus subsystem.
DIG3TO1 This software is for Control Modules that use the M/A
Station option and 3 to 1 redundancy. This option is
described in the Operator Station instruction book for the
Multibus subsystem.

120 3BUR002120R3701
Section 3 Database Reference for Objects CNTRLLER Object

CONTLCP This software is for Control Modules that use the LCP+
option and 11 to 1 controller redundancy. One A_PANEL
object must be assigned as a child of the CNTRLLER
object. The A_PANEL object must have one line in the
edit window to specify the serial port the LCP+ is
connected to (PORT NUMBER) and define the name for
the port (PORT NAME). For further information, refer to
the Local Control Panel Plus (LCP+) instruction book.
LCP3TO1 This software is for Control Modules that use the LCP+
option and 3 to 1 controller redundancy. This option is
described in the Local Control Panel Plus (LCP+)
instruction book.
SC_CTLR This software is for a 6204B SC Control Module in a
subsystem using 11 to 1 redundancy. The backup
controller must be in slot 4.
SC_CTLR3TO1 This software is for a 6204B SC Control Module in a
subsystem using 3 to 1 redundancy. The backup
controller can be in slots 4, 8, and 12.

Default is: CONTROLLER

The SC Controller Backup Memory Module (SC-BMC) must

always be placed in the first card file when 11 to 1 redundancy is
used. Also the SC-BMC requires an Extender Module in every card
file on the pbus. These SC-BMC Extender Modules must be
jumpered for the card file where they reside.
The Smart Device Interface is supported only on SC Controllers.
Therefore, if a subsystem contains a Smart Device Interface, the
only valid entries for the SOFTWARE NAME field are SC_CTLR
and SC_CTLR3TO1.

AUTO START
This field determines whether the controller starts processing automatically after the
software and database are downloaded to it.

3BUR002120R3701 121
CNTRLLER Object Section 3 Database Reference for Objects

Valid entries are:

YES start processing immediately upon download

NO do not start processing until a command to do so is
issued from the console through the Controller
Subsystem Status Display

Default is: YES

BACKUP ON STARTUP
This field determines whether redundancy is enabled for this controller.
Redundancy is only possible if the Controller subsystem has a Backup Controller
and Backup Memory Module. Valid entries are:

NO do not enable backup for the controller. This is used when

the Controller subsystem does not have a backup
controller or when a Backup Controller and Backup
Memory Module present but do not provide backup for
this controller.
YES enable backup for the controller

Default is: YES

MAX DATA BASE SIZE

The largest amount of memory in the controller used for the database, TCL
sequences, and remote lists is defined in this field. Although this field must be
specified for all controllers, it has a special meaning for controllers with backup
capabilities enabled for them. The sum of the MAX DATA BASE SIZE fields of the
Controllers for which backup capabilities are enabled (BACKUP ON START UP
field contains YES) must be less than the memory capacity of the Backup Memory
Module. The capacity for the 6004B Control Module is 2 MB or 4 MB with an
extender and for the 6204 SC Control Module it is 4 MB. The default value for this
field is sufficient to support 11 controllers with 1 backup. You can modify the

122 3BUR002120R3701
Section 3 Database Reference for Objects CNTRLLER Object

maximum database sizes of the controllers if fewer than 11 require backup

capabilities.
If the entry made to this field is too small, an error message is generated upon
download. When this occurs, the value must be changed and the database must be
recompiled and downloaded. After the database is downloaded, both the entry to
this field and the actual size of the database are displayed on the Controller
Subsystem Status Display. If the entry to this field is changed for a controller, the
Backup Memory Module and the Backup Controller must be reset before
redundancy is re-instated for the controller.
Valid entry is:
An integer number of bytes. Maximum entry for the 6004B Control Module is
256,000. The maximum size for the 6204B SC Control Module is 1 MB (1,024,000
bytes). (With LCP+ configured on the controller, the maximum database size is
reduced from 256,000 bytes to 215,040 bytes.)
Default is: 81920

DO RATE
The DO RATE field specifies the minimum resolution of any pulse output for the
controller. For pulse train outputs, the pulse width and pulse interval as specified
through the PO CHANNEL NUMBER fields of the Controller I/O Templet must be
multiples of the DO RATE. For pulse duration outputs, the duration value calculated
by the Pulse Duration FCM is rounded to the next lower multiple of the DO RATE.
Valid entry is:
A number of milliseconds as either 20, 40, 100, 200, or 1000
Default is: 200

Serial Ports for Controllers

A Controller requires a PORTS object if any device is connected to its serial I/O
connectors. The Model B Controller has two connectors. The SC Controller has 4
connectors for two redundant serial connections.

3BUR002120R3701 123
CNTRLLER Object Section 3 Database Reference for Objects

Manual/Auto Operator Station

Both the SC Controller and the Model B Controller can be equipped with one
1740N M/A Operator Station. This station is described in the Operator Station
instruction book for the Multibus subsystem. It requires a port be configured for it
via the PORTS object. The entries required to support the Manual/Auto Operator
Station are listed below. Other fields can be left blank.

NUM The number of the port the station is connected to.

For a Model B Controller, connector SER J4 is port 1 and
SER J5 is port 2.
For an SC Controller, SER 1A is port 1, SER 1B is port 2,
SER 2A is port 3 and SER 2B is port 4.
PORT NAME A name with a maximum of 12 characters with the first
three characters being SA_. The name must be unique
system wide.
TYPE GENERIC
SPEED 9600
WORD 8
PARITY NONE
STOP 1

Local Control Panel Plus (LCP+)

When an LCP+ is connected to a controller the connection can be made to any serial
connector. The serial port for this type of connection is defined through the
A_PANEL object as described in the Local Control Panel Plus (LCP+) instruction
book. A PORTS object is not required for an LCP+.

Programmable Logic Controllers (PLCs)

You can connect Programmable Logic Controllers (PLCs) to the SC Controller.
Refer to the Taylor Programmable Controller Interface User's Guide.

124 3BUR002120R3701
Section 3 Database Reference for Objects CCF-Related Objects

Smart Devices
You can connect smart devices to the SC Controller via Small HART Interface
Modules (SHIMs) connected to the SC Controller serial ports. Refer to the Smart
Device Interface User's Guide.

CCF-Related Objects
Every Control Module or Multibus subsystem that runs Configurable Control
Functions (CCF) software must have a CCF object as a child. CCF-related objects
are listed in Table 15. These objects are described in detail in the Configurable
Control Functions (CCF) User’s Guide.

Table 15. CCF and Related Objects

OBJECT TYPE PURPOSE REFERENCE

CCF Child of either a CNTRLLER object or a Configurable Control
GENERICD object. Required for control Functions (CCF) User’s
modules and subsystems that run Guide
Configurable Control Functions (CCF).
Establishes basic CCF operating parameters
for the control module (or subsystem),
particularly the base processing rate upon
which individual loop processing rates are
based.
BRKPTS Child of CCF object. One per breakpoint set Configurable Control
being defined for the system. Functions (CCF) User’s
Guide
DEV_LOOP Child of CCF object. One per device loop Configurable Control
supported by the controller. Functions (CCF) User’s
Guide
LOOP_DEF Child of CCF object. One per analog loop Configurable Control
supported by the controller. Functions (CCF) User’s
Guide

3BUR002120R3701 125
TLL-Related Objects Section 3 Database Reference for Objects

Table 15. CCF and Related Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

MOD30_300 Child of CCF object. One per analog or MOD 30 Interface Users
discrete loop that supports a MOD 30 Guide
Controller XL, Recorder, or SLU.
DEV_SPEC Child of CCF object. One per special device Configurable Control
algorithm. Functions (CCF) User’s
Guide
FCMS Children of CCF object. As required to define Configurable Control
CCF control functions. Functions (CCF) User’s
Guide
PRIM_LOG Child of LOOP_DEF object. Maximum of 3 per Configurable Control
LOOP_DEF object. Functions (CCF) User’s
Guide

TLL-Related Objects
Module that runs Taylor Ladder Logic (TLL) must have an LL_DEV object as a
child. TLL-related objects (children of the LL_DEV object) are listed in Table 16.
These objects are described in detail in the Taylor Ladder Logic (TLL) User’s
Guide.

Table 16. Taylor Ladder Logic and Related Objects

OBJECT TYPE PURPOSE REFERENCE

LL_I_O One required per LL_DEV object. Taylor Ladder Logic (TLL)
User’s Guide
LL_TIMER One required per every 25 timers. Taylor Ladder Logic (TLL)
User’s Guide
LL_CNTR One required per every 25 counters. Taylor Ladder Logic (TLL)
User’s Guide
LL_REG One required for every 25 registers. Taylor Ladder Logic (TLL)
User’s Guide

126 3BUR002120R3701
Section 3 Database Reference for Objects Remote I/O-Related Objects

Table 16. Taylor Ladder Logic and Related Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

LL_MSG One required for every 25 messages. Taylor Ladder Logic (TLL)
User’s Guide
LL_FILE One required for each program in the Taylor Ladder Logic (TLL)
node or controller. User’s Guide
LLIO_GRP One required for every 32 S800 I/O Taylor Ladder Logic (TLL)
channels. User’s Guide
LL_I_O_2 Child of LLIO_GRP object. One required Taylor Ladder Logic (TLL)
for every S800 I/O channel. User’s Guide
LL_SEQ One required for every sequence. Taylor Ladder Logic (TLL)
User’s Guide
LL_SEQIO Child of the LL_SEQ object. One Taylor Ladder Logic (TLL)
required for each of up to 128 steps in a User’s Guide
sequence.

Remote I/O-Related Objects

Remote I/O-related objects are listed in Table 17. These objects are children of the
REMOTEIO object. They are described in detail in the Taylor Remote I/O (TRIO)
User’s Guide.

Table 17. Taylor Remote I/O Objects

OBJECT
PURPOSE REFERENCE
TYPE
IO_16CKT One required per 6240B DC sink or source Taylor Remote I/O (TRIO) User’s
16-circuit block. Guide
IN_16CKT One required per 6247B 115VAC 16-circuit Taylor Remote I/O (TRIO) User’s
block. Guide
OP_16CKT One required per 6248B relay output block. Taylor Remote I/O (TRIO) User’s
Guide

3BUR002120R3701 127
AC410 Object Section 3 Database Reference for Objects

Table 17. Taylor Remote I/O Objects (Continued)

OBJECT
PURPOSE REFERENCE
TYPE
IO_32CKT One required per 6241B 32-circuit DC sink or Taylor Remote I/O (TRIO) User’s
source I/O block. Guide
IN4_2OUT One required per 6230B analog I/O block Taylor Remote I/O (TRIO) User’s
(non-two-wire XMTR applications). Guide
GRP_8CKT One required per 6244B 115VAC 8-circuit Taylor Remote I/O (TRIO) User’s
grouped or 6245B115VAC 8-circuit low Guide
leakage I/O block.
ISO_8CKT One required per 6246B AC/DC isolated Taylor Remote I/O (TRIO) User’s
8-circuit block. Guide
CSANALOG One required per 6231B current sourcing Taylor Remote I/O (TRIO) User’s
analog I/O block for two-wire XMTR Guide
applications.
HSC_A One required per high-speed counter block. Taylor Remote I/O (TRIO) User’s
Guide
HSC_B One required per high-speed counter block. Taylor Remote I/O (TRIO) User’s
Guide
RTD One required per 6233B RTD input block. Taylor Remote I/O (TRIO) User’s
Guide
TC One required per 6232B thermocouple input Taylor Remote I/O (TRIO) User’s
block. Guide

AC410 Object
The AC410 object is a child of an AREA object. One AC410 object is required per
AC410 node. Refer to the Advant Controller 410 User’s Guide for details.

128 3BUR002120R3701
Section 3 Database Reference for Objects AC460 Objects

AC460 Objects
The AC460 object is a child of an AREA object. It can have up to three
AC460MOD (module) objects as children, Table 18. Refer to the Advant Controller
460 User’s Guide for details.

Table 18. AC460 Objects

OBJECT TYPE PURPOSE REFERENCE

AC460 Child of AREA object. Establishes one Advant Advant Controller 460
Controller subsystem under a configuration User’s Guide
area.
AC460MOD Child of AC460 object. One required per CPU Advant Controller 460
(non-redundant module or redundant pair), up User’s Guide
to 3 per subsystem. Establishes basic operating
parameters for each CPU group.

S100 I/O Objects

The S100 I/O objects are listed in Table 19. They are described in detail in the S100
I/O User’s Guide.

Table 19. S100 I/O Objects

OBJECT TYPE PURPOSE REFERENCE

S100_IO Child of AC410 or AC460MOD object. Required S100 I/O User’s Guide
for control modules that support S100 I/O.
DSAI130 High level analog input, 16 differential channels S100 I/O User’s Guide
(or 8 differential & 8 single-ended)
DSAI133 High level analog input, 32 single-ended S100 I/O User’s Guide
channels, redundant or non-redundant
DSAI145 3-wire RTD (Pt100), 31 channels S100 I/O User’s Guide
DSAI151 4-wire RTD (Pt100), 14 channels S100 I/O User’s Guide

3BUR002120R3701 129
S800 I/O Objects Section 3 Database Reference for Objects

Table 19. S100 I/O Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

DSAI155 Thermocouple, 14 channels S100 I/O User’s Guide
DSAO110 Analog output, 4 isolated channels S100 I/O User’s Guide
DSAO120 Analog output, 8 non-isolated channels S100 I/O User’s Guide
DSAX110 Analog I/O, 8 input & 8 output, redundant or S100 I/O User’s Guide
non-redundant
DSDI110 Digital input, 32 channels (4 groups of 8) with S100 I/O User’s Guide
input time filter
DSDI115 Digital input, 32 channels (4 groups of 8) S100 I/O User’s Guide
DSDO110 Digital output, 32 channels (4 groups of 8) S100 I/O User’s Guide
DSDX180 Universal digital I/O, 32 channels, redundant or S100 I/O User’s Guide
non-redundant
DSDP150 Pulse input, 12 channels S100 I/O User’s Guide

S800 I/O Objects

The S800 I/O objects are listed in Table 20. They are described in detail in the S800
I/O User’s Guide.

Table 20. S800 I/O Objects

OBJECT TYPE PURPOSE REFERENCE

S800_IO Child of AC410 or AC460MOD object. One S800 I/O User’s Guide
required for each Advant Controller CPU that
supports S800 I/O.
S800_LAN Child of the S800_IO object. Associates a S800 S800 I/O User’s Guide
LAN number with a CI520 LAN Submodule of
an Advant Controller CPU.

130 3BUR002120R3701
Section 3 Database Reference for Objects MVI-Related Objects

Table 20. S800 I/O Objects (Continued)

OBJECT TYPE PURPOSE REFERENCE

S800_STN Child of the S800_LAN object. Represents an S800 I/O User’s Guide
I/O Station on the LAN.
AI810 Analog Input with 8 channels S800 I/O User’s Guide
AI820 Differential Analog Input with 4 channels S800 I/O User’s Guide
AI830 Analog Input with 8 RTD channels S800 I/O User’s Guide
AI835 Analog Input with 8 Thermocouple channels S800 I/O User’s Guide
AO810 Analog Output with 8 channels S800 I/O User’s Guide
AO820 Bipolar Analog Output with 4 channels S800 I/O User’s Guide
DI810 Digital Input with 16 channels S800 I/O User’s Guide
DI814 Digital Input with 16 channels (current source) S800 I/O User’s Guide
DI820 Digital Input with 8 channels S800 I/O User’s Guide
DI821 230VAC Digital Input with 8 channels S800 I/O User’s Guide
DO810 Digital Output with 16 channels S800 I/O User’s Guide
DO814 Digital Output with 16 channels (current sink) S800 I/O User’s Guide
DO820 Digital Output with 8 channels S800 I/O User’s Guide

MVI-Related Objects
The MVIBOARD object is a child of an AC410 or AC460MOD object. It is
required for control modules that support serial I/O devices such as PLCs, Smart
Platform, and smart devices. Refer to the appropriate Advant Programmable
Controller User’s Guide, Advant Smart Platform Interface User’s Guide, and
Advant Smart Device (HART) Interface User’s Guide for details.

3BUR002120R3701 131
PLC-Related Objects Section 3 Database Reference for Objects

PLC-Related Objects
The PLC object is a child of an AC410 or AC460MOD object. It is required for
control modules that support PLC and smart devices. Refer to the appropriate
Advant Programmable Controller User’s Guide and Advant Smart Device (HART)
Interface User’s Guide for details.

Profibus I/O-Related Objects

The PROFIBUS_IO object is a child of an AC460MOD object. It is required for
control modules that support Profibus I/O. Refer to the PROFIBUS Interface for
Advant Controller 460 manual for details.

132 3BUR002120R3701
Appendix A Group Routing For Alarms

Group Routing is an optional feature for systems that expect heavy alarm message
traffic on the DCN. This feature lets you optimize alarm message traffic on the DCN
by assigning all nodes involved with message generation/logging to sending and
receiving groups. Nodes that generate alarms are assigned to one or more (up to
four) send groups, and nodes that receive alarms are assigned to one or more (up to
16) receive groups. Alarm messages are only routed between nodes belonging to the
same group. Group routing supersedes the CCF Alarm routing specified in the
senders AREA templet.
If a node under an area templet is specified to send CCF Alarm messages to one or
more groups, then the destination message centers specified in its AREA templet
must be specified in the Group Routing file as receiving from the groups specified
by the sender node.
Groups are defined in a Group Routing file using an off-line (hpterm window-
based) utility called bugs. This file contains a list of nodes and which groups they
are sending to and receiving from. The data in this file is used to populate Advant
OCS relations when the database is compiled and installed. Once the nodes are
rebooted, the group routing will be enabled.
You must configure all Advant CDP's that will use the Alarm Group Routing
functionality with a Group Routing file. Model A/B controllers can not function as
senders. The following error occurs if there is no group routing file or a node name
is not in the file:
ALARM GROUP ROUTE ERROR: TOO MANY RECEIVE GROUPS
################################
ALARM GROUP ROUTING NOT ACTIVE FOR node_name
When the system is started, nodes that receive alarm messages check the database
and sign up for the specified groups. During runtime, when an alarm is generated,

3BUR002120R3701 133
The Bugs Utility Appendix A Group Routing For Alarms

the alarm/event task checks the database, and determines if alarm groups are
configured. If so, the alarm messages are routed to the specified groups. If not, the
standard alarm routing method is used.
Follow these procedures to configure the Group Routing file and install the file in
the database:
– Starting the bugs Utility
– Create the Group Routing File
– Insert Records in the Group Routing File
– Reviewing the Group Routing File
Related procedures are described in:
– Removing a Record
– Install Report Messages
– Bugs File Editor Commands

The Bugs Utility

The Bugs utility is used to create the Group Routing files. The Bugs utility can be
accessed from the Advant Station HPUX platform or the AdvaBuild Windows
platform.

Starting the Bugs Utility in Advant HPUX platform

If using AdvaBuild on Windows, skip this section and proceed to

Starting the Bugs Utility in AdvaBuild Windows platform on page
136
The Group Routing file is configured via the bugs file editor. To start bugs:
1. From the Display menu, click EXTERNAL APPLICATIONS.
2. Click the hpterm option. This opens an hpterm window.
3. In the terminal window, enter: bugs. This displays a ModConsole icon on the
HP-UX toolbar, Figure 36

134 3BUR002120R3701
Appendix A Group Routing For Alarms Starting the Bugs Utility in Advant HPUX platform

ModConsole Icon

Figure 36. ModConsole icon on HP-UX Toolbar

4. Double-click the icon to restore the ModConsole window, Figure 37.

Figure 37. ModConsole Window Restored

3BUR002120R3701 135
Starting the Bugs Utility in AdvaBuild Windows platform Appendix A Group Routing For Alarms

5. Press the ESC key. This launches the bugs utility, Figure 38.

Figure 38. Initial bugs Window

Turn the Caps Lock on for all interaction with the bugs utility.

Starting the Bugs Utility in AdvaBuild Windows platform

To launch Bugs on the Windows platform:
1. Select Start > Control Panel > Administrative Tools > PAS > Bugs to open
up a bugs window.
2. Press <ESC> to get the bugs prompt: What’s up Doc?>
3. Turn the Caps Lock on for all interaction with the bugs utility.

136 3BUR002120R3701
Appendix A Group Routing For Alarms Create the Group Routing File

Create the Group Routing File

To create the file, enter the following commands in bugs:
1. At the bugs prompt, enter: FMS [50.INDEX]
2. When the prompt returns, enter: ALLO GRPROUTE.DT

This creates the configuration file named GRPROUTE.DT.

The file name is critical. The Group Routing function will not work
unless the file is named exactly as shown above.

Insert Records in the Group Routing File

Use the bugs file editor to insert records in the file. Each record specifies the alarm
group assignment for one node that needs to use the group alarm routing method. To
do this:
1. Enter: EDIT GRPROUTE.DT

This opens the file in LIST mode.

2. Change to INSERT mode. To do this, enter: I

This changes the prompt to: 000000+R0 00 ?

3. Insert a record according to the following instructions. The basic syntax for a
record is:

‘nodeName,sendGrpNumbers,receiveGrpNumbers’. (GrpNumbers range is 1-

16)

A sample dialog is shown in Figure 39. For sample record specifications see

3BUR002120R3701 137
Insert Records in the Group Routing File Appendix A Group Routing For Alarms

Table 21.

For historical message recording the history template name must be

defined in the Area Template Message Center and the history node
name must be defined in the Group Routing File
a. Start the record with a quotation mark. You can use either a single (‘), or
double (“) quote; however, you must be sure to be consistent throughout
the file.
b. Enter the node name as defined on the database template, then enter a
comma (,). For example: ‘CTR3_1,
c. Specify the send group numbers according to these guidelines:
– If the node only generates messages, enter up to four send group numbers,
separating each number with a comma. For example: ‘CTR3_1,1,2,3
– If the node does not generate messages, enter 0, followed by a comma. For
example: ‘OSES1_1,0,
– If the node generates and receives messages, enter up to four send group
numbers separating each number with a comma. If you enter less than four
send groups, enter a 0 (zero) and comma after the last send group number.
For example, ‘OSES1_1,1,2,0,
d. Specify the receive group numbers according to these guidelines:
– If the node only generates messages, ignore this step and proceed to step
3e.
– If the node receives messages, enter the receive group numbers. You can
specify up to 16 receive groups. For nodes that can send and receive
messages, send group numbers may also be used in the receive group part.
Again, separate each number with a comma and end with a quotation
mark, for example: ‘OSES1_1,1,2,0,1,2,4,5’
e. To end the record, enter . (a period). This displays a prompt to insert this
record.
f. To insert the record, enter: Y

This displays a prompt to enter a new length.

138 3BUR002120R3701
Appendix A Group Routing For Alarms Insert Records in the Group Routing File

g. Press ENTER to accept the current length. This displays the INSERT ?>
prompt.
h. Press ENTER to enter the next record. This displays a message indicating
the next record number, and the 000000+R0 00 ? prompt returns.
4. Repeat step 3 for as many records as required.
5. To end the file, when the INSERT?> prompt is displayed, enter . (a period).

Record Definition (steps 3a-3e)

Prompt to
Insert (step 3f)

Prompt for new

length (step 3g)

Return to INSERT
Prompt,
New record #,
Insert Prompt
(steps 3g, 3h)

Figure 39. Example Record Definition for Send-Only Node

3BUR002120R3701 139
Reviewing the Group Routing File Appendix A Group Routing For Alarms

Table 21. Example Record Specifications

Node Send Receive

Type Record Specification
Name Groups Groups
CTR3_1 Controller 1 None ‘CTR3_1,1’.
CTR3_2 Controller 1,2,3 None ‘CTR3_2,1,2,3’.
OSES_0 Operator/Engineering 1 1 ‘OSES_0,1,0,1’.
Station
OSES_1 Operator/Engineering None 2,3 ‘OSES_1,0,2,3’.
Station

Reviewing the Group Routing File

When you are finished entering records, you should review your work before you
install the database. To do this:
1. Open the file with the bugs file editor: EDIT GRPROUTE.DT
2. At the LIST prompt, press ENTER. This displays the first record. An example
is shown in Figure 40.

You can also navigate directly to a specific record by entering the

record number, or list a range of records. For example:

• LIST ?> 3 lists record #3 (the fourth record)

• LIST ?> S 5 lists the first 5 records from the start of the file.

140 3BUR002120R3701
Appendix A Group Routing For Alarms Removing a Record

Figure 40. Example, Record Listing in Hexadecimal Format

In this example, the record listing is shown in hexadecimal format. You can also
show the listings in ascii or other formats. To do this, at the LIST prompt, enter a
semicolon, and the applicable character as described in Table 22. For example, to
list the records in ascii, use a double quotation mark: LIST ?> ;”
You can page through the file by simply entering a carriage return, or you can
navigate directly to a specific record by entering the record number.

Removing a Record
To delete a record:
1. Open the text file with the bugs editor: EDIT GRPROUTE.DT
2. At the LIST prompt, enter the number of the record that you want to delete. For
example, to delete the second record, enter: 1. This displays the second record
(Record number = $1).
3. When the LIST prompt returns, enter R. This is the Remove command.

3BUR002120R3701 141
Install Report Messages Appendix A Group Routing For Alarms

Figure 41. Removing a Record

Install Report Messages

When the database installer processes CONTROLLER, AC460MOD, and AC410
templates, if a record is found for the template, and there are no syntax errors in the
corresponding record, Alarm Group Routing will be activated for the node, and a
message such as the one shown below will be entered in the install report:
ALARM GROUP ROUTING ACTIVATED FOR CTR3_1
SENDING TO GROUP(S): 1
When the database installer processes GENERICD templates, if a record is found
for the template, and there are no syntax errors in the corresponding record, Alarm
Group Routing will be activated for the node, and a message such as the one shown
below will be entered in the install report:
ALARM GROUP ROUTING ACTIVATED FOR OS_1
RECEIVING GROUP(S): 1
If a record is not found for a template, Alarm Group Routing will not be activated
for the node, and no message will be entered in the install report.

142 3BUR002120R3701
Appendix A Group Routing For Alarms Bugs File Editor Commands

If a record is found, but no send or receive groups have been specified, the record
will be ignored. Alarm Group Routing will not be activated for the node, and no
message will be entered in the install report.
If any of the following error conditions are encountered by the installer, Alarm
Group Routing will not be activated for the corresponding node:
• If a record has too many send or receive groups. Example messages are shown
below:

ALARM GROUP ROUTE ERROR: TOO MANY SEND GROUPS FOR

CONTROLLER: 1,2,3,4,5, ALARM GROUP ROUTING NOT ACTIVE FOR
CTR3_1

ALARM GROUP ROUTE ERROR: TOO MANY RECEIVE GROUPS:

1,2,3,4,5, ALARM GROUP ROUTING NOT ACTIVE FOR OS_1
• If a record has a send or receive group number that is outside the allowed
range. Example install report messages are shown below:

ALARM GROUP ROUTE ERROR: GROUP NUMBER 17 OUT OF RANGE

MUST BE >=1 AND <=16
• If a send or receive group number is duplicated in a record. Example install
report messages are shown below:

ALARM GROUP ROUTE ERROR: DUPLICATE RECEIVE GROUPS:4

ALARM GROUP ROUTING NOT ACTIVE FOR OS_1

GENERICD and CONSOLE nodes may both send and receive

messages. These nodes may send and receive from the same group.

Bugs File Editor Commands

Table 22 describes frequently used bugs commands.

3BUR002120R3701 143
Bugs File Editor Commands Appendix A Group Routing For Alarms

Table 22. bugs file editor commands

Function Command
Change to INSERT Mode I
Change to LIST Mode L
Change to MODIFY Mode M
Quit editor . (period)
Remove (delete) current record R
Go to start of file S
Go to end of file Z
Go to previous record P
Go to next record N
Change Listing format ;” = ascii
;$ = hexadecimal
;% = binary
;@ = octal
;U = unsigned decimal
;& = signed decimal

144 3BUR002120R3701
 INDEX

A AO810 object 131

A_PANEL object 81, 115 AO820 object 131
AC410 object 22, 128 AOUTPUT object 23
AC410 subtree hierarchy 67 AR_DATA object 82
AC460 object 22, 129 AR_DATA subtree hierarchy 63
AC460 objects 129 AR_INDEX object 82
AC460 129 AR_INSTANCE object 82
AC460MOD 129 AREA object 22, 71, 74
AC460 subtree hierarchy 68 assigning
AC460MOD object 129 Configurator user tasks 56
ADVANT_D2D object 22 Operator, Supervisor, and Engineer tasks 52
AI810 object 131
AI820 object 131 B
AI830 object 131 BRKPTS object 125
AI835 object 131 BUC object 115
AINPUT object 23
alarm C
contacts on SIM modules 50 CCF object 22 to 23, 82, 115, 125
deadband 42 CCF subtree hierarchy 65
parameters for continuous loops 48 CCF-related objects 125
parameters for device loops 47 BRKPTS 125
priority 43 to 44 CCF 125
alarm/event DEV_LOOP 125
detection and notification 40 DEV_SPEC 126
handling by Advant OCS applications 46 FCM 126
handling for computer interfaces 50 LOOP_DEF 125
handling for Display Builder 50 MOD30_MOD300_MAP 126
handling for MOD 30 instruments 50 PRIM_LOG 126
handling for Report Services 49 CDP 30
handling for TCL 49 CHNL_DEF object 81
logging 40 CI object 22 to 23, 82
processing 39 CI subtree hierarchy 62
Alarm/Event Logger 40 CI_DEF object 82

3BUR002120R3701 145
Index

CNTRLLER object 115, 119 export file via Export References Display 37
common database portion 30 export file via object editing 37
CONFIG user 27 CRT field 97
configuration area 35 Serial Ports Templet 97
configuring CSANALOG object 128
Alarm/Event Logger 41 CTRL_BLOCK object 23
alarms for continuous loops 42
alarms for device loop 43 D
historical recording of alarm/event database attributes referenced by other domains 36
messages 45 database attributes related to multiple
CONSLIB object 23, 80, 92, 112 configurator 35
Console Library Configurator 35 database hierarchy 59
CONSOLE object 22, 112 to 113 database objects 71
CONSOLE subtree hierarchy 61 DCN_DCN object 22
console-related objects 112 default user categories for displays and software 52
CONSLIB 112 designation of objects in control structure 23
CONSOLE 112 DEV_DESC object 22, 71, 78
LOG_DETL 112 DEV_DIR object 22, 71, 78
MSG_ROUT 112 DEV_LOOP object 23, 125
PORTS 112 DEV_SPEC object 126
CONT_IO object 116 device descriptor sets 78
CONT_SS object 22, 115, 117 device descriptors 78
CONT_SS subtree hierarchy 64 DI810 object 131
control structure objects 22 DI814 object 131
control system structure 20 DI820 object 131
controller subsystem-related objects 115 DI821 object 131
A_PANEL 115 DIG_MA_S object 116
BUC 115 DO810 object 131
CCF 115 DO814 object 131
CNTRLLER 115 DO820 object 131
CONT_IO 116 domain 30
CONT_SS 115 DSAI130 object 129
DIG_MA_S 116 DSAI133 object 129
LL_DEV 116 DSAI145 object 129
PORTS 115 DSAI151 object 129
REMOTEIO 115 DSAI155 object 130
TCL_MBOX 116 DSAO110 object 130
TCL_RUN 116 DSAO120 object 130
creating DSAX110 object 130
export file 37 DSDI110 object 130

146 3BUR002120R3701
 Index

DSDI115 object 130 TCL_DEV subtree 63

DSDO110 object 130 TCL_RUN subtree 63
DSDP150 object 130 top-level & subsystem-level objects 61
DSDX180 object 130 hierarchy of objects 19
HISTORY object 81
E HISTORY subtree hierarchy 63
establishing domains in database 35 HSC_A object 128
establishing system users 51 HSC_B object 128
export file 37
exporting database references 36 I
implementing multiple CDPs 31
F IN_16CKT object 127
Failover, SC Controller 98 IN4_2OUT object 128
FCM object 23, 126 integrating all CDPs for first time 32
Fetch Alarm target 45 IO_16CKT object 127
IO_32CKT object 128
G ISO_8CKT object 128
general alarm parameters 44
general loop-level alarm handling parameters 42 L
generating Cross Reference Reports 57 LL_CNTR object 126
GENERICD object 22, 80, 84 LL_DEV object 83, 116
GENERICD subtree hierarchy 62 LL_DEV subtree hierarchy 65
GRP_8CKT object 128 LL_FILE object 127
LL_I_O object 126
H LL_I_O_2 object 127
hierarchy LL_MSG object 127
AC410 subtree 67 LL_REG object 126
AC460 subtree 68 LL_SEQ object 127
AR_DATA subtree 63 LL_SEQIO object 127
CCF subtree 65 LL_TIMER object 126
CI subtree 62 LLIO_GRP object 127
CONSOLE subtree 61 locking objects 30
CONT_SS subtree 64 LOG_DETL object 81, 104, 112
GENERICD subtree 62 LOOP_DEF object 22 to 23, 125
HISTORY subtree 63
LL_DEV subtree 65 M
PLC subtree 68 making multiple CDPs compatible 34
REMOTEIO subtree 66 message center 75
S100 I/O subtree 69 entries for Alarm/Event Loggers 77
S800 I/O subtree 70 entries for Historical Services 77

3BUR002120R3701 147
Index

message routing 35 CSANALOG 128

message type 75 GRP_8CKT 128
MOD_DB object 20, 22, 71 to 72 HSC_A 128
MOD30_MOD300_MAP object 126 HSC_B 128
MODUSERS object 80, 89 IN_16CKT 127
MSG_ROUT object 80, 93, 112 IN4_2OUT 128
MSQR object 23 IO_16CKT 127
MULTIBIO object 83 IO_32CKT 128
multiple configurator 30 ISO_8CKT 128
compiler considerations 37 OP_16CKT 127
database reports 38 RTD 128
installer considerations 38 TC 128
program downloads 38 remote type 75
multi-user engineering 26 REMOTEIO object 83, 115
Administration component 27 REMOTEIO subtree hierarchy 66
Templet Builder 30 REP_BLDR object 81
MVIBOARD object 131 ringback 45
root 20
O RTD object 128
OP_16CKT object 127
S
P S100 I/O objects 129
PID object 23 DASO120 130
PLC object 132 DSAI130 129
PLC redundancy 98 DSAI133 129
PLC subtree hierarchy 68 DSAI145 129
port types 97 DSAI151 129
PORTS object 22 to 23, 81, 95, 112, 115 DSAI155 130
PRIM_LOG object 126 DSAO110 130
PROFIBUS_IO object 132 DSAX110 130
project DSDI110 130
status 27 DSDI115 130
user types and privileges 27 DSDO110 130
PROJECT object 20, 22 DSDP150 130
project structure 20 DSDX180 130
S100_IO 129
R S100 I/O subtree hierarchy 69
READER user 27 S100_IO object 129
RECORDER object 81 S800 I/O objects 130
remote I/O-related objects 127 AI810 131

148 3BUR002120R3701
 Index

AI820 131 MODUSERS 80

AI830 131 MSG_ROUT 80
AI835 131 MULTIBIO 83
AO810 131 PORTS 81
AO820 131 RECORDER 81
DI810 131 REMOTEIO 83
DI814 131 REP_BLDR 81
DI820 131 SMART_IO 83
DI821 131 SMART_IO_NETWORK 83
DO810 131 SPC 81
DO814 131 SPC_DIR 81
DO820 131 TCL_DEV 82
S800_IO 130 URELNAME 82
S800_LAN 130 system users 51
S800_STN 131
S800 I/O subtree hierarchy 70 T
S800_IO object 130 TC object 128
S800_LAN object 130 TCL_DEV object 82
S800_STN object 131 TCL_DEV subtree hierarchy 63
SC Controller Failover 98 TCL_MBOX object 116
security key 101 TCL_RUN object 116
Serial Ports Templet 97 TCL_RUN subtree hierarchy 63
SMART_IO object 83 TLL-related objects 126
SMART_IO_NETWORK object 83 LL_CNTR 126
SPC object 81 LL_FILE 127
SPC_DIR object 81 LL_I_O 126
subsystem level objects 80 LL_I_O_2 127
A_PANEL 81 LL_MSG 127
AR_DATA 82 LL_REG 126
AR_INDEX 82 LL_SEQ 127
AR_INSTANCE 82 LL_SEQIO 127
CCF 82 LL_TIMER 126
CHNL_DEF 81 LLIO_GRP 127
CI 82 top level objects 71
CI_DEF 82 AREA 71
CONSLIB 80 DEV_DESC 71
GENERICD 80 DEV_DIR 71
HISTORY 81 MOD_DB 71
LL_DEV 83 top-level & subsystem-level object hierarchy 61
LOG_DETL 81

3BUR002120R3701 149
Index

U
URELNAME object 82

W
WRITER user 27

150 3BUR002120R3701
Contact us

ABB AB ABB Automation LLC

Control Technologies Control Technologies
Västerås, Sweden Abu Dhabi, United Arab Emirates
Phone: +46 (0) 21 32 50 00 Phone: +971 (0) 2 4938 000
e-mail: processautomation@se.abb.com e-mail: processautomation@ae.abb.com

3BUR002120R3701
www.abb.com/controlsystems www.abb.com/controlsystems

ABB Automation GmbH ABB China Ltd

Control Technologies Control Technologies
Mannheim, Germany Beijing, China
Phone: +49 1805 26 67 76 Phone: +86 (0) 10 84566688-2193
e-mail: marketing.control-proucts@de.abb.com www.abb.com/controlsystems
www.abb.de/controlsystems

ABB S.P.A. Copyright © 2001-2013 by ABB.

Control Technologies All rights reserved.
Sesto San Giovanni (MI), Italy
Phone: +39 02 24147 555
e-mail: controlsystems@it.abb.com
www.abb.it/controlsystems

ABB Inc.
Control Technologies
Wickliffe, Ohio, USA
Phone: +1 440 585 8500
e-mail: industrialitsolutions@us.abb.com
www.abb.com/controlsystems

ABB Pte Ltd

Control Technologies
Singapore
Phone: +65 6776 5711
e-mail: processautomation@sg.abb.com
www.abb.com/controlsystems

Power and productivity

for a better worldTM