Glossary of Terms

This glossary contains information about many terms, phrases, and abbreviations used by CygNet Software. Additionally, many sections of this Help document contain terminology and concepts that are related directly to the Help section you are viewing. See the following topics for additional specific assistance:

CygNet Business Object Concepts CygNet Measurement Concepts CygNet Measurement Terminology CygNet Native Operations Concepts CygNet Studio Terminology Data Storage Terminology Energy Load Forecast Concepts

Enterprise Objects Concepts Enterprise Operations Concepts Groups Concepts Line Pack Terminology Redundancy Concepts Security Terminology SVCMON Terminology

Browse by letter:     [A]     [B]     [C]     [D]     [E]     [F]     [G]     [H]     [I]     [K]     [L]     [M]     [N]     [O]     [P]     [R]     [S]     [T]     [U]     [V]     [W]     [X]

32-bit and 64-bit Components

The terms 32-bit and 64-bit refer to the way a computer's processor handles information. The 64-bit version of Windows handles large amounts of random access memory more effectively than a 32-bit system.

CygNet Software provides support for three 64-bit services (a 64-bit Flow Measurement Service (FMS), a 64-bit Universal Interface Service (UIS), and a 64-bit Value History Service (VHS)) and all remote device drivers, communication device drivers, and import export drivers are available in 64-bit versions, with the exception of the SonicMQ Export EIE and the SonicQ EIE, which are limited to 32-bit. Note that only the driver portion of each EIE is 64-bit; the associated editor is not 64-bit.

For more information see Services Overview and 64-bit Device Drivers.

Access Control Service (ACS)

The Access Control Service (ACS) is the CygNet Software security administration service. Its database contains the list of applications and events for which security is required, as well as the list of users and their authorization levels. In terms of security each service is an application. Security can also be applied at the record level in a service. The ACS can provide security for custom applications provided they can communicate with the ACS. It functions in concert with the operating system security (Microsoft Windows) to protect access to your system.

For more information see Security.

Address Resolution Service (ARS)

The Address Resolution Service (ARS) is the CygNet Software directory service that resolves network addresses. It is sometimes called a metadata service since it resolves information about other CygNet services. The ARS must be running in order to install CygNet Software successfully. It tracks the network address and operational status of each service within a CygNet domain.

A service must be added to the ARS before it is started for the first time. This eliminates superfluous entries and enforces administrator security. You can view and modify ARS records using CygNet Explorer.

For more information see Address Resolution.

Admin.sec

Security Supervisors File. For more information see Security Supervisors.

AGA

American Gas Association. Refer to the AGA website for more information.

Alarm Condition

Alarm condition is the same as point state, in that it is the highest precedented state for a point record as defined in the CvsMetadata file for the current Point Scheme, except that in the point state definition for each point state, the alarm condition attribute must be set to "true" for the alarm condition to be considered. When alarm condition is set to true, the defined point state is considered a valid alarm condition.

For a system running the default CygNet Standard Point Scheme (Point Scheme 0), point state and alarm condition closely follow each other. For example, when a point is in a High Alarm condition, the point state and alarm condition will both be High Alarm.

For the CygNet Standard Point Scheme, three point state definitions do not allow alarm condition configuration: the Normal, Unreliable, and Uninitialized point states. For these three point state definitions, the alarm condition attribute is always "false," meaning that these point states will never be considered an alarm condition. So when a point is in a Normal, Unreliable, or Uninitialized state, the alarm condition will be blank.

For all other point state definitions, alarm condition is the highest precedented point state when alarm condition is set to true.

CygNet Standard Point Scheme

The following table lists the point state definitions that allow an alarm condition for the Standard Point Scheme:

Analog	Digital	Enumeration	String
High Alarm	Chattering	Alarm 6	Alarm 6
High Warning	Alarm	Alarm 5	Alarm 5
Low Alarm	Warning	Alarm 4	Alarm 4
Low Warning		Alarm 3	Alarm 3
High Out of Range		Alarm 2	Alarm 2
Low Out of Range		Alarm 1	Alarm 1
High Deviation
EAC Prevented*

*If enabled for CVS calculation, the "EAC Prevented" configurable bit will be set only if Enhanced Alarm Configuration conditions have been defined for this point, and the evaluation of those conditions has prevented one or more of the other enabled configurable bits from being set that otherwise would have been set.

CygNet Enhanced Point Scheme

In the CygNet Enhanced Point Scheme or other customized Point Schemes (Point Scheme 1 - 15), the alarm condition and other desired attributes (description, display order, associated state colors, etc.) can be configured in the CvsMetadata file as needed. See Understanding the CVS Metadata File for more information about the elements and attributes that define a CygNet Point Scheme.

For more information also see Point State.

Alarm Event Logging Service (ELSALM)

The Alarm Event Logging Service (ELSALM) is an instance of an ELS. Its purpose is to store alarm and notification events. It can be used to help you occasionally clear out the ELS without losing alarm history.

For more information see Logging.

Alarm Management

For more information see CygNet Alarm Manager.

AP

Alphanumeric Page (associated with the GNS). For more information see Notification Types.

API

American Petroleum Institute. Refer to the API website for more information.

API

Application Programming Interface. See also CygNet API below. For more information see Scripting.

Application Administrator 

A person who can add, delete, and modify users and user permission levels contained in an Access Control Service (ACS). See also Access Control Service (ACS).

For more information see Configuring Application Administrators.

Application Blob Service (APPS)

The Application Blob Service (APPS) is an instance of a Blob Storage Service (BSS). CygNet uses this service to store client application files.

For more information see Blob Storage Service.

Applications

For security-related purposes, CygNet services are considered applications. The application name is user-defined in each service’s configuration file, with the exception of the Address Resolution Service, which is named "ARS."

For more information see Applications.

Archive Files

Archive files are associated with the Value History Service, which can be configured to store value entries to separate compressed archive files. All values for all points are logged to a single compressed archive file for each day. Entries are written to the compressed archive at the same time they are written to the main history file, and may be retained for a specified time interval.

For more information see History.

ASTM

American Society for Testing and Materials. Refer to the ASTM website for more information.

Attribute

See Property vs. Attribute.

Audit Service (AUD)

The Audit Service (AUD) tracks and stores all changes, such as what was changed, when it was changed, and the individual who made the change, known as the audit record. It logs operator actions and configuration changes, as defined for various services. The level of detail contained in an audit record is based on the service’s auditing configuration. The Audit Service does not audit itself.

Auditable actions include starting or stopping a service through the RSM, updating or deleting values in the VHS, setpoint changes, point configuration changes, etc.

For more information see Auditing.

Automatic Backups

Automatic full backups are user defined to a relative or absolute directory path, based on defined keyword parameters set in the applicable CygNet services’ configuration files.

For more information see Backup and Restore.

Automatic Service Recovery

The RSM is expected to restart (or fix) any failed local service. This is accomplished via the Automatic Service Recovery feature of CygNet, configured for each service in the RSM. Whenever a service shuts down abnormally the RSM will attempt to restart the service via the recovery actions configured in the RSM. Automatic service recovery can be mass configured for all services in a Redundancy environment via the Automatic Service Recovery option in the Redundancy Editor.

Blackout

A blackout is a period of time during which an action does not take place. Blackouts can be applied to scheduled tasks in the MSS and to notification recipients in the GNS.

For more information see Scheduling Blackouts.

Blob

Binary Large Object. For more information see Blob Storage Service.

Blob Storage Service (BSS)

The Blob Storage Service (BSS) is a CygNet service that stores files. Any type of file can be stored in a BSS, including .app, .bmp, .csf, .dll, .doc, .exe, .ico, .ini, .jpg, .ocx, .rpt, .rsp, .rsq, .xls, etc. The term BSS is used generically to describe any Blob Storage Service (APPS, BSS, custom).

The CygNet services installation program sets up the host with two Blob Storage Services: APPS and BSS. These services are the same type; they just have different names. The APPS is the repository for all of the CygNet client application files. The BSS is installed with no files and is intended as the repository for user files such as CygNet Studio screens, trends, etc. The reason that two BSS’s are created is to allow for differentiation of security and to separate CygNet applications from user data. CygNet Software recommends that users have read-only authorization to the APPS.

Only three items differentiate the APPS and the BSS:

• The service folder. Each service has its own folder in the CygNet\Services folder.
• The service name. The name is defined in the service .cfg file using the keyword SERVICE. Regardless of the service name, the names of the startup files are Bss.exe, Bss.cfg, and Bss.ddl.
• The contents at initial startup. APPS is preloaded with CygNet client application files.

For more information see Blob Storage Service.

Bridge

See CygNet Bridge.

BTU

British Thermal Unit. For more information about supported units see PNT Engineering Units or FMS Data Items Units.

CAL

Client Access License. For more information see License Management.

Canvas

Canvas is CygNet Software's HMI (human machine interface) application.

Canvas provides high-quality screen design functionality, utilizing a variety of specialized tools and controls, which you can use to create user screens to operate with your CygNet Software installation and data. The Canvas plugin model allows the creation of custom or third-party control types, and once added to Canvas they will be available for addition to your screens.

Canvas View is the read-only runtime companion application to Canvas providing a standard multi-document interface to your Canvas screens. You can also open any CygNet Studio file (.csf) in Canvas View.

For more information see CygNet Canvas.

CFX

Flow-Cal formatted files. For more information see FMS Commands.

CIP

Common Industrial Protocol type used by an Allen Bradley CIP EIE.

Client

A client is any network-based application that proactively accesses CygNet services. For more information see CygNet Client Installer.

CMI

Classified Message Incidence.

Common Alarm Service (CAS)

The Common Alarm Service (CAS) provides centralized alarm processing for current value services (CVSs). When a CVS receives a value for a point that meets or exceeds an alarm setpoint, the CVS reports the alarm to the CAS.

Alarm setpoints and alarm reporting are configured on a per-point basis in the point configuration record in the PNT. CygNet Explorer, CygNet Studio and CygNet Vision can be used to view alarms. The ELSALM stores alarm history.

For more information see Alarms.

Communication Device

Communication or comm devices are the communication interfaces between a host server and remote devices.

For more information see Communication Devices.

Communication State

CygNet includes a communications statistic for monitoring the communications state, or comm state. This statistic reflects the state of the most recent communications with the device.

For more information see SYCSSTTN, SYCSSTAT, and Failed Comm Transition Period.

Communication Statistics

Communication statistics are calculated by the Universal Interface Service (UIS) and can be viewed in table form using the CygNet UIS View Control in CygNet Explorer or CygNet Studio. You can also create points for the statistics so that you can define alarms and notifications, as well as to report the values to the historian or to display them on CygNet Studio screens. Communication statistics can be monitored for both communication and remote devices. They are calculated from the last UIS restart, and most of the statistic types have options for current day (CD), current hour (CH), current month (CM), last day (LD), last hour (LH), and last month (LM) statistics. It is important to note that the statistics do not persist; that is, they are reset when the UIS is restarted. There is also an option to calculate rolling 20-minute window (2M) statistics; however, this feature must be enabled for the UIS.

For more information see UIS System UDCs, Remote Devices User Interface, Comm Devices User Interface, and Setting up 20-Minute Statistics.

Configurable Status Bits

Configurable Status Bits are used to facilitate CVS alarm functions and calculations, as well as CAS and GNS reporting. There are 15 configurable Status Bits that can be associated with a point record. See Point Status Bits and Configurable Status Bits for more information. Also see System Status Bits and User Status Bits.

Configuration File, Service Configuration File

A configuration file is a text file that defines a service, such as its name, associated services, file names, file size limits, etc. The configuration file is used by the service during startup. The contents of a configuration file are keywords and keyword parameters specific to the type of service.

For more information see Service Configuration Files.

Configuration Properties

Attributes of a service that define its configuration. For more information see Services.

CSV

Comma-Separated Values. It uses the file extension .csv.

CTD

Custody transfer data. For more information see CygNet Measurement or your device type in Remote Devices.

Current Value Service (CVS)

A Current Value Service (CVS) is a generic name for a data collection service that acquires data using data collectors, EIEs, remote devices, and communication devices, and stores the data in an internal table called a current value table. The CygNet current value services include the HSS, OPCIS, SVCMON, and UIS.

For more information see Current Value Services.

CVT

Current Value Table. For more information see Current Value Services.

CygNet

The CygNet^® IoT/SCADA platform collects, manages, and distributes critical real-time and operational data across your oil and gas enterprise. Using the CygNet platform, operators can process diverse data and information — from downhole sensors to surface facilities and pipelines. Users across every business function can prioritize and analyze real-time information to support strategic decision-making and optimized operations.

CygBOB

CygNet Business Object Builder. For more information see Enterprise Objects.

CygNet Alarm Manager

The CygNet Alarm Manager is an add-on solution to a CygNet system, which provides a set of components designed to aid Alarm Management and assist in rationalizing alarms and point configurations. Through a series of alarm counting and reporting operations, as well as the sample workflow provided, Alarm Management personnel are able to determine alarm flooding conditions, identify top offenders, and systematically analyze alarm conditions to ensure that points are configured in accordance with your company’s Alarm Management philosophy.

For more information see CygNet Alarm Manager.

CygNet API

CygNet Software currently supports the following Application Programming Interfaces (API). These automation libraries facilitate data retrieval, display and manipulation of the CygNet system via script:

• COM API — The CygNet COM API objects comprise several Cx* programs called automation tools or automation libraries, which provide programmatic access to CygNet services, clients, and other related entities. Most of the customer-facing COM objects are documented in the CygNet COM API topics.

• .NET API — The CygNet.API assemblies provide programmatic access to CygNet services, clients, and other related entities. Known colloquially as the CygNet.API. These assemblies also include .NET assemblies that are COM visible. Microsoft .NET Framework must be installed on the host machine when the scripts are running, in accordance with the CygNet system requirements. See CygNet .NET API for more information.
• Bridge API — CygNet Bridge API is a separately available CygNet product that provides a web service to request your CygNet data over the internet, allowing you to create your own web applications to securely access your CygNet system data. CygNet Bridge API is a REST API delivering HTTP requests and responses. The API allows reading, modifying and deleting of CygNet Point records. Accessing the CygNet Bridge API requires the installation of CygNet Bridge software, and the Bridge API feature must be selected as an option during the CygNet Bridge installation process. CygNet Bridge maintains secure data access, allowing you to access required CygNet data without direct access to a CygNet system. You can optionally require two-factor authentication to be granted access to the CygNet Bridge API. See CygNet Bridge API for more information.

CygNet Aware

Many CygNet Studio tools are considered CygNet-aware, meaning that they can be configured to show data for a particular point or points. These tools are referred to as primary point tools and their icon is designated with a small red "C." For more information see CygNet-Aware Tools and Primary Point.

CygNet Bridge

CygNet Bridge is a set of services running outside of the CygNet production environment that is utilized by other CygNet products, namely CygNet Mobile, CygNet Dispatch, and CygNet Bridge API, to securely access CygNet SCADA and/or CygNet Measurement data and provide it to users who require data access but are external to a CygNet installation.

For more information see CygNet Bridge.

CygNet Bridge API

CygNet Bridge API is an optional CygNet companion product that enables developers to securely access CygNet system data over the web for integration into desktop, mobile, or web applications. CygNet Bridge API is available in conjunction with CygNet Bridge.

For more information see CygNet Bridge API.

CygNet Depot

CygNet Depot is an add-on tool to a CygNet system, which can be used to simplify interaction with CygNet file storage services. With the Depot, you have easy access to any file stored in your APPS or BSS, as well as your Group services.

For more information see CygNet Depot.

CygNet Designer

The CygNet Designer is an add-on utility used to build models describing CygNet databases and to test existing databases against that model. With CygNet Designer you can:

• Describe rules that define your CygNet system
• Validate one or more CygNet sites against your rules
• Find and fix deviations from the rules
• Create new facilities and points using your rules

At the heart of the CygNet Designer is a model for describing your system known as a blueprint.

For more information see CygNet Designer.

CygNet Dispatch

CygNet Dispatch is an optional CygNet companion product to CygNet Measurement, that provides additional functionality to integrate results from field information that could potentially alter calculated volumes in your measurement data. CygNet Dispatch is available in conjunction with CygNet Bridge.

For more information see CygNet Dispatch.

CygNet Email Engine

The CygNet Email Engine (CygNetEmailEngine.exe) is an internal executable used by the General Notification Service (GNS) and the CygNet Measurement (FMS) to process email notifications, messages and reports. The CygNetEmailEngine.exe and an associated .config file are automatically installed to the CygNet\Bin directory on the host server (effective with CygNet v9.7 or later).

For more information see Configuring Email Properties and Configuring Email Options.

CygNet Explorer

CygNet Explorer is CygNet Software's main configuration and administration application. It provides an overview of your entire CygNet implementation while providing an interface for viewing data and modifying the records contained in the various services.

For more information see CygNet Explorer.

CygNet GIS Control (CGC)

The CygNet GIS Control was an ActiveX control in CygNet Studio that displayed SCADA data on a customized GIS map made using a third-party tool, ESRI’s ArcMap. This control is now obsolete.

CygNet Measurement

CygNet Measurement is a CygNet Software gas measurement application. It is used to produce accurate electronic flow measurement (EFM) data, to provide the best possible information to internal or external systems such as SCADA or production accounting. See also EFM below.

For more information see CygNet Measurement.

CygNet Messaging

A highly efficient process of transmitting packets of information or data between CygNet services, clients, utilities, and other CygNet applications. Native CygNet messages are transmitted via Reliable User Datagram Protocol (RUDP).

For more information see Configuring Advanced Network Settings, CygNet Client to Server Communication, and CygNet Message Sniffer Lite Utility.

CygNet Mobile

The CygNet Mobile Application Suite is an optional CygNet companion product that provides access to CygNet system data using the CygNet Operator mobile application, over a mobile device. CygNet Mobile is available in conjunction with CygNet Bridge.

For more information see CygNet Mobile.

CygNet Report Module

The CygNet Report Module is an add-on solution to a CygNet system that integrates CygNet services and client applications to create and deliver CygNet data in various report formats. Reports can be run against multiple sites on the same domain.

For more information see CygNet Report Mobile.

CygNet Sales

CygNet Sales resources include Weatherford software sales account managers specializing in CygNet products and services.

Contact CygNet Sales via the Weatherford Production Software website or email, as follows.

• Weatherford Software Sales — website: SCADA Platform — CygNet
• Weatherford Software Sales — email: CygNetSales@weatherford.com

Refer to additional topics within this Help for more information about CygNet Software.

CygNet Support

CygNet Support resources include Weatherford technical assistance analysts trained on CygNet Software products and services.

Contact CygNet Support via the online Weatherford Software Support portal, email, or telephone, as follows.

• CygNet Support — website: Software Support Portal

  (Sign in with your credentials to create, view, or update Support tickets.)

• CygNet Support Help Desk — email: CygNetSupport@weatherford.com
• CygNet Support Help Desk — phone: +1-866-4-CygNet (+1-866-429-4638)

Refer to additional topics within this Help for more information about CygNet Software.

CygNet Thin Web Client

CygNet Thin Web Client (TWC) is CygNet's browser-based HMI client application for viewing operational screens and workflows in a Web browser using sophisticated web-based technologies. Currently the designer for building web-based screens is a web-enhanced version of the Canvas desktop application.

For more information see CygNet Thin Web Client.

CygNet Training

CygNet Training resources include Weatherford technical educators providing a variety of interactive courses and training services for CygNet products and services.

Contact CygNet Training via the Weatherford Production Software website or email, as follows.

• CygNet Training — website: SCADA Platform — CygNet
• CygNet Training — email: CygNetTraining@weatherford.com

Refer to additional topics within this Help for more information about CygNet Software.

Data Collector

Data collector is a general term used for a program that updates values in Current Value Services. The data collector may be internal to the Current Value Service or may be a separate executable.

For more information see Current Value Services.

Data Group Element

A point for which the value is acquired outside of CygNet. Each point is a monitor or sensor which can be hard or soft. A hard data point can be an actual monitor; a soft point can be seen as an application or software calculation. Data group elements from hard and soft points are normally recorded and logged to create a timestamp.

For more information see Points Overview and Device Template Files.

Data Group (DG)

A data group is a collection of data group elements. All CygNet communication to and from a device is performed using data groups. Some data groups contain only a few elements, while others may contain hundreds of elements. The number of elements in a group may change if the device configuration changes (for example, you add I/O). Native data groups are defined by the manufacturer’s protocol. Modbus data groups are user defined.

For more information see Data Groups and Ordinalized Data Group.

All electronic flow measurement (EFM) data groups are dependent upon specific support data groups, consisting of the native data groups from which measurement data groups draw their data. No EFM data group works without the required support data group(s).

For more information see Data Group Dependencies and EFM Data Groups.

Database Service or DBS-Based Service

A DBS-based service is a generic name for a service that stores information used by other services. DBS-based services include the Audit Service (AUD), Device Definition Service (DDS), Facility Service (FAC), Group Service (GRP), Master Scheduling Service (MSS), Note Service (NOTE), Point Service (PNT),and Table Reference Service (TRS).

Other services that fall into this category structurally are the Access Control Service (ACS), Blob Storage Services (APPS and BSS), Event Logging Services (ELS and ELSALM), and General Notification Service (GNS), although operationally they are considered administrative (ACS, APPS, BSS) and real-time services (ELS, ELSALM, GNS).

All DBS-based services use the same database engine, and have very similar configuration parameters and security administration. Each type of DBS has a unique database schema. This is defined in the Data Dictionary Language (.ddl) file. You can view the contents of the file but do not edit it. The .ddl file also defines the indexes for the service. The indexes are useful for searching the database.

The Value History Service (VHS) uses the same underlying data storage technology (ESE) as the other DBS-based services, but it is not considered a DBS-based service due to its unique archiving functionality.

For more information see Services Overview.

DCL

Data Communications Library (DCL). A core CygNet library that assists in the transmission of data between CygNet services, clients, utilities, and other CygNet applications. It also assists with seat registration and CygNet licensing.

For more information, see CygNet Messaging and CygNet Client to Server Communication.

Device Definition Service (DDS)

The Device Definition Service (DDS) stores remote device, communication device, and text import records. The DDS and UIS have a one-to-one relationship. As such, to add another instance of a DDS requires that you add another UIS. The services’ relationship is defined in each service’s configuration file.

For more information see Devices.

Device ID

CygNet naming standards for device IDs are as follows:

Component	Valid Character Set	Limits
Device ID	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (uppercase) 0 1 2 3 4 5 6 7 8 9 dash (-), underscore (_), and tilde (~).	20 character maximum No spaces

 

For more information see Devices.

DEID

The data group element ID (DEID). For more information see DataGroupElement.

dgElements (DGE)

Data Group Element. For more information see dgElements.

DI

Device Identifier. A property of the specific remote terminal device. For more information see Devices Overview.

Domain

A CygNet system. For more information see Domains.

DTF

Device Template File, used to configure CygNet for specific field devices. For more information see Device Template Files.

DynaCards

See Dynagraph Cards.

Dynagraph Cards

A Dynagraph Card provides information about rod-pump well performance. Each card displays one complete stroke in a load versus position graph. Dynagraph cards are also called "DynaCards". Different types of cards can be polled from a device, though not all devices support all card types.

Several EIEs have a DynaCard (or Dynagraph Card) data group for retrieving rod pump data. Several CygNet device template files contain DynaCard-related elements and attributes for defining data retrieval from a DynaCard-enabled device.

The CygNet Dynagraph Viewer can be used to view dynagraph cards. The CxDynagraph API provides an alternative method of interacting with the CygNet Dynagraph Viewer. The DynaCard Library is a collection of cards collected by a field device and stored by a VHS card storage service.

See also Pump-Off Control below.

EAC

Enhanced Alarm Configuration. For more Information see Enhanced Alarm Configuration below.

EFM

Electronic Flow Measurement. For more information see CygNet Measurement, Remote Devices, and/or EFM Data Items.

EIE

Equipment Interface Engine. For more information see Equipment Interface Engine.

EIS

Enterprise Integration Suite. For more information see Enterprise Integration Suite.

ELF

Energy Load Forecasting. For more information see Energy Load Forecasting.

ELS

The Event Logging Service (ELS) is the CygNet Software service that maintains a journal of system events by logging system-generated events and user-defined events. There are four types of events: service, operations, alarms, and external.

For more information see Logging.

ELSALM

The Alarm Event Logging Service (ELSALM) is an instance of an ELS. Its purpose is to store alarm and notification events. It can be used to help you occasionally clear out the ELS without losing alarm history.

See Alarm Event Logging Service (ELSALM) above.

Email Engine, Email Handler

See CygNet Email Engine above.

Enhanced Alarm Configuration

Enhanced Alarm Configuration (EAC) expands the CygNet alarm rules to allow a user to extend the conditions by which a configurable status bit is allowed to be set or prevented from being set. When a configurable bit is prevented from being set, any subsequent alarms or notifications that would have been generated are prevented as well. EAC conditions are defined as a series of logical expressions that reference real-time values of the same point or multiple other points. However, all points referenced must reside in the same Common Value Service (CVS) as the point being configured. EAC conditions may contain up to 50 individual expressions, each of which could reference a separate point. The enhanced alarm configuration is available from the PNT Editor's Alarm Settings (Analog, Digital, Enumeration, String) pages.

For more information see Enhanced Alarm Configuration.

EntOps

Enterprise Operations. For more information see Enterprise Operations.

Equipment Interface Engine (EIE)

An Equipment Interface Engine (EIE) is an advanced device communications programming code built to correspond to CygNet services via a specific data source, such as a remote terminal unit (RTU), programmable logic controller (PLC), etc. CygNet EIE drivers support direct serial, serial modem, serial radio, and transmission control protocol/internet protocol (TCP/IP) connections between the Universal Interface Service and the device. EIEs enable users to define, configure, and view real-time data during input/output data flow.

For more information see Devices Overview.

ESE

Microsoft’s Extensible Storage Engine (ESE) data storage technology. CygNet Software uses ESE for its DBS-based services and the Value History Service (VHS). For more information see Extensible Storage Engine.

Event

An event is a command or group of commands specific to an application. For more information see Events.

Event Logging Service (ELS)

The Event Logging Service (ELS) is the CygNet Software service that maintains a journal of system events by logging system-generated events and user-defined events. There are four types of events: service, operations, alarms, and external.

For more information see Logging.

Facility

In CygNet, the term "facility" is used to represent a logical grouping of data. A facility can represent an RTU, a flow computer, a meter, or a tank battery. It can represent a manufacturing line, a building, or a specific process. It can represent a collection of points that are not device-oriented, such as scripted points or OPCIS points.

For more information see Facilities Overview and Ordinalized Facility.

Facility ID

A facility ID resolves to a facility within the CygNet environment. The format of a facility ID is Site.Service::FacilityID.

CygNet naming standards for facility identifiers are as follows:

Component	Valid Character Set	Limits
Facility ID	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (uppercase) 0 1 2 3 4 5 6 7 8 9 _ (underscore)	20 character limit No spaces

For more information see Facility Identifier.

Facility Service (FAC)

The Facility Service stores all facility information. This service is linked to and synchronizes with other services that use facility information, including the Device Definition Service (DDS), the Point Service (PNT), and the Universal Interface Service (UIS).

For more information see Facility Service.

Facility Tag

Valid facility tag strings resolve to a facility in the system. The format of a facility tag string is Site.Service::FacilityID.

For more information see Facility ID above and Tag String Formats.

Failover

Failover is the process of switching the domain on which the active server is running to a standby (or backup/redundant) server. Failover ensures seamless operation in the event of a planned or unplanned interruption in service. The purpose of a redundant environment is to support failover.

For more information see CygNet Redundancy and Failover.

File Extensions

Common file extensions are listed in the following table. For more information see ESE File Types.

File Extension	Description
.cat	Catalog file
.cfg	Service configuration file
.cfx	Flow-Cal formatted file
.csf	CygNet Studio screen file
.csv	Comma-separated values file
.csw	Studio Workspaces file
.dat.edb	Data files. For DBS-based services, the file name is ServiceName.dat.edb (for example, MSS.dat.edb).
.ddl	Data Dictionary Language file (for DBS-based services)
.dll	Dynamic Link Library
.dtf	Device template file
edb.jtx	Transaction log files for DBS-based services
.exe	Service executable
.few	Workspace files in CygNet Measurement, used to save workspace settings and values such as Site.Service, window positions, configured command definitions, custom report definitions, and controls with their settings
.inx.edb	Index file for DBS-based service databases. The file name is ServiceName.inx.edb (for example, MSS.inx.edb).
.log	Log files. Each log file contains service information. The file name is ServiceType00#.log; the # symbol is that file's individual occurrence.
.tfx	Flow-Cal formatted file
.ts.edb	Temporary storage file for DBS-based services
.xml	Extensible Markup Language file

FIX Interface Service (FIXIS)

The Fix Interface Service was a current value service that retrieved values through the Intellution Toolkit API. This service was retired in v8.1.0.

Flow Measurement Service (FMS)

The Flow Measurement Service (FMS) is the CygNet Software service that retrieves data, including electronic flow meter (EFM) data, from various sources for CygNet Measurement. The CygNet Measurement system retrieves, stores, validates, estimates, analyzes, edits, and approves the data for reporting to external systems. The FMS service functions as the interface between the Microsoft SQL Server database and the SCADA system. Optionally, the supplied FMS internal database can be used in appropriate production environments.

CygNet Measurement is delivered with a 64-bit Flow Measurement Service (FMS), providing improved efficiency and performance over the 32-bit FMS service.

The FMS Service and the FMS Explorer (primary user interface), commands, and controls manage electronic flow meter (EFM) data for the CygNet Measurement application.

For more information see CygNet Measurement.

Force evaluation on update

Force evaluation on update is an option to force an evaluation of each new value for reporting to the VHS, regardless of whether the point’s value or status has changed.

For more information see Reporting Options.

ForeSite

The ForeSite^® web-based production optimization platform enables production maximization across your reservoir, well, and surface facilities through well optimization, well monitoring and surveillance, field service management, and predictive analytics features. ForeSite supports a variety of lift types, including ESP, Gas Injection, Gas Lift, Naturally Flowing, RRL, and Water Injection wells, supporting both surface and subsurface data. ForeSite integrates seamlessly with ReO, WellFlo, and CygNet IoT/SCADA software.

For more information refer to the ForeSite Platform page on the Weatherford website or contact your Weatherford account manager. Additional information is contained in the ForeSite online help available from within the application.

ForeSite EDGE

ForeSite EDGE^® is a separately available IoT-enabled well automation and control product that extends controller functionality to provide autonomous management at the wellsite. Both ForeSite production optimization and CygNet IoT/SCADA platforms are leveraged by ForeSite EDGE devices to drive continuous production performance. ForeSite EDGE Mobile is also available as a companion app for ForeSite EDGE.

For more information refer to the ForeSite EDGE page on the Weatherford website or contact your Weatherford account manager.

ForeSite EDGE Mobile

ForeSite EDGE ^® Mobile is a companion app for your Apple iOS mobile phone that operates with ForeSite EDGE installations in the field. The app allows you to use your mobile phone at the wellsite to connect to ForeSite EDGE devices within communication range, using available on-site Bluetooth communication technology, to view and configure critical device communication setup data between ForeSite EDGE devices and RTUs in the field.

For more information refer to the ForeSite EDGE page on the Weatherford website or contact your Weatherford account manager.

Gas Measurement Repository (GMR)

The Gas Measurement Repository (GMR) is an obsolete CygNet Software product, discontinued in December 2016 with the CygNet v8.5.0 release. GMR has been superseded by CygNet Measurement (FMS), first released in August 2011 with the CygNet v8.0.0 release. A companion utility, FMS Toolbox, is provided alongside CygNet Measurement to assist in data migration from GMR to FMS.

For more information see CygNet Measurement. See also EFM above.

General Notification Service (GNS)

The General Notification Service (GNS) stores and processes notification messages. Notifications are triggered by the setting and clearing of alarm bits, and are enabled on a per alarm basis in the Point Service (PNT). When a Current Value Service (CVS) retrieves a value for a tag, it checks the tag record for alarm and notification settings. If the Report to GNS option is enabled in the alarm settings, the CVS sends the tag’s real-time record to the GNS for processing along with the GNS identifier, and then the GNS builds and processes the notification. The notification message and its recipients are configured and stored in the GNS. Several types of notification messages are supported including email, SMS (text) messages, voice messages (via a SIP server or Dialogic board), messages sent to third-party notification services, and others.

For more information see Notifications.

GMR

See Gas Measurement Repository above.

Graph API

The CygNet Notification (GNS) and Measurement (FMS) services support use of the OAuth protocol for email authentication via the Microsoft Graph API, a RESTful web API that enables authorization access to Microsoft Cloud service resources, including Microsoft 365 and Azure Active Directory. The Graph API is a built-in library referenced by the CygNet email engine. See OAuth below.

For more information see Configuring Email Properties.

Group Service (GRP)

The Group Service (GRP) is a database service that stores group hierarchies based on facility and device attributes. Hierarchies are made up of nodes, each of which has its own set of properties and attributes. The GRP can store numerous hierarchies and their respective nodes, all of which are available to the various CygNet services they interact with, like the Point Service (PNT) and Facility Service (FAC).

Although the GRP powers group hierarchy creation and storage, the GRP is largely a behind-the-scenes service. Hierarchies stored in the GRP are typically created and edited using the Group Manager utility. Its interface is friendlier than the GRP editor and it enables both high- and low-level interaction with group hierarchies (and the GRP).

In a CygNet SCADA context, a group is a collection of facilities organized into hierarchies. Facilities are included in hierarchies according to user-selected facility attributes and device attributes. Attributes can be defined in a way that makes sense in your organization. Specific attributes can then be chosen to identify levels in user-defined hierarchies. Hierarchies enable the collection and organization of information specific to the facilities and devices to which those attributes belong.

For more information see Groups.

HMI

Human-Machine Interface. For more information see CygNet Studio.

Host

A Host is a computer that is running one or more CygNet services. For more information see System Administration.

HyperPoint

A HyperPoint is a discrete value calculated from current point values in other Universal Interface Services. It is a real-time point whose value and state are determined by the execution of an associated HyperPoint script.

For more information see HyperPoint Scripting.

HyperPoint Scripting Service (HSS)

The HyperPoint Scripting Service (HSS) is a CygNet real-time service that executes custom scripting to calculate user-defined HyperPoints based on time-specified events or a change in the point value. Although the service configuration is similar to that of the Universal Interface Service (UIS), the HSS does not collect data from external devices. You can use the CygNet Explorer client application to edit the HyperPoint scripts and view the point values.

HyperPoints are configured as any other point by using the script editor built into the Point Service (PNT). When the HyperPoint script is configured on the HyperPoint property page in the PNT editor, you can compose, edit, and run a test simulation of the script. The HyperPoint script text is stored in the PNT database.

It is recommended that you host HyperPoints using the HSS rather than a UIS. This action will eliminate performance impacts on real-time data acquisition. The maximum point count for the HSS is 500,000 points.

For more information see HyperPoint Scripting.

ID

Identifier. Used in conjunction with field names in the configuration files, editors, and property pages. One example is "Application ID."

Keyword

A word used in a configuration file to activate a function or to specify a parameter. For more information see Service Configuration Keywords.

Kill

Kill the selected service. When a service is killed, a Microsoft Windows "stop" message is sent to the service. Only use if the service is not responding to a normal CygNet stop request.

See Remote Service Manager and Service Management for more information.

LED

Light-Emitting Diode. CygNet Studio contains several LED-related tool objects for placement on screens:

• An Arrow LED Tool object is an image of an arrow shaped LED that indicates a status by color.
• A Diamond LED Tool object is an image of a diamond shaped LED that indicates a status by color.
• A LED Bar Tool object shows a value in relation to segments.
• A LED Switch Tool object can be used as a toggle for digital commands.
• A Round LED Tool object is an image of a round LED that indicates a status by illuminating the LED.

For more information see CygNet Studio.

Line Pack

A CygNet application used to calculate the volume of natural gas, the mass of supercritical carbon dioxide, or the volume of petroleum liquids in a pipeline segment at any given time. The Line Pack application can also be used to calculate mass imbalance to aid in leak detection in the pipeline segment. Other optional calculations include: line pack at MAOP, line pack volume converted to energy content (natural gas only), line pack measured or calculated density (CO2 and petroleum liquids only), line pack volume converted to mass (petroleum liquids only).

For more information see Line Pack.

Link

Link is a service that functions as an MQTT (Message Queueing Telemetry Transport) publisher to retrieve and send CygNet data to an MQTT server.

For more information see Link.

Long Point ID

The Long Point ID is one of two unique identifiers of a data point.

CygNet naming standards for point identifiers are as follows:

Component	Valid Character Set	Limits
Long Point ID	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (uppercase) 0 1 2 3 4 5 6 7 8 9 ! (exclamation point) # (pound) $ (dollar) % (percent) ^ (caret) & (ampersand) _ (underscore) = (equals) + (plus) [ (opening bracket) ] (closing bracket) { (opening brace) } (closing brace) | (vertical pipe) < (less than) > (greater than)	31 character limit No spaces

See also Point ID below.

For more information see Point Identifiers.

Master Scheduling Service (MSS)

The Master Scheduling Service (MSS) is the CygNet scheduler. It can be used to schedule UIS Command Tasks, Setpoint Tasks, or FMS Tasks. Tasks can be scheduled to be recurring, for a duration, based on a condition, or continuous. A task can be applied to a single device or multiple devices. Blackout periods can be applied to tasks.

For more information see Scheduler.

Messaging

See CygNet Messaging.

MQTT

Message Queueing Telemetry Transport (MQTT) is an extremely lightweight machine-to-machine/Internet of Things (IoT) messaging transport protocol. It uses the publish/subscribe protocol, which is designed for constrained devices (limited processor or memory resources) and low bandwidth, high-latency, or unreliable networks.

For more information see Link.

NAT

Network Address Translation. For more information see Network Address Translation.

Native Data Group

See Data Group.

Node

An individual subunit of a component or navigation hierarchy. A Leaf Node is the lowest level node in a hierarchy, usually corresponding to a facility.

For more information see Groups Concepts.

NOTE

The note feature is powered by a parent service, the Note Service (NOTE). A Note Service is accessible by means of CygNet Explorer. This service contains notes created within a single site or from multiple sites on the same domain, and is associated with one or more current value services (CVS).

You can associate as many current value services (i.e., UIS, SVCMON, HSS, and/or OPCIS) as you like with a single Note Service. However, each associated current value service can only be associated with a single Note Service. For instance, Note Service A can contain notes referencing data from both UIS A and UIS B. However, UIS A can only be associated with Note Service A and UIS B can only be associated with Note Service A.

See Notes.

OAuth

An open-standard authorization protocol that describes how unrelated servers and services can safely allow authenticated access to their assets without sharing the initial, related, single logon credential. In authentication parlance, this is known as secure, third-party, user-agent, delegated authorization. The CygNet Notification (GNS) and Measurement (FMS) services support the use of Microsoft Graph API for its OAuth authorization mode. See Graph API above.

For more information see Configuring Email Properties (for GNS) or Configuring Email Options (for FMS).

ODBC

Open Database Connectivity. For more information see ODBC.

OLE

Object Linking and Embedding. For more information see Third-Party ActiveX Controls.

OPC

OLE Process Control. Also Open Platform Communications. See OPC.

OPC (DA) Server

OPC DA (Data Access) is a group of client-server standards that provides specifications for communicating real-time data from data acquisition devices such as PLCs to display and interface devices like SCADA systems. The CygNet OPC DA Server has been implemented based on this standard to expose CygNet SCADA real-time data to standard OPC DA client applications.

See CygNet OPC Server.

OPC HDA Server

OPC HDA (Historical Data Access) is used to exchange archived process data with OPC clients such as a trending or spreadsheet applications. The CygNet OPC HDA Server has been implemented based on this standard to expose CygNet SCADA historical data to standard OPC HDA client applications.

See CygNet OPC HDA Server.

OPC Interface Service (OPCIS)

The OPC Interface Service (OPCIS) is a specialized CygNet current value service that provides connectivity of CygNet Software to a computer using the OPC Data Access (DA) or OPC Historical Data Access (HDA) specification-compliant server. The OPCIS is an OPC client associated with an external OPC server. It can have a one-to-one or one-to-many relationship with OPC servers through OPC groups. OPCIS features include:

• Retrieval of current values for up to 500,000 data points from an OPC server
• Write data to OPC servers
• Connect to local or remote OPC servers
• Configurable update rate for all OPC points
• Grouping for custom update rates and point processing

CygNet supports three OPC servers: a CygNet OPC (DA) Server, a CygNet OPC HDA Server, and a CygNet OP UA Server.

See OPCIS vs OPC EIEs for a feature-by-feature comparison of the OPCIS with the OPC EIEs (OPC EIE, OPC Comm EIE, OPC Lufkin EIE, and OPC Weatherford EIE) to help you decide which OPC option best suits the requirements of your enterprise.

For more information see OPC Interface Service.

OPC UA Server

CygNet provides an OPC Unified Architecture (UA) Server, an application which exposes real-time and archived CygNet data to an OPC UA Client application using the OPC UA (OPC Unified Architecture) specification, version 1.04. OPC UA is a secure, open, reliable mechanism for transferring information between servers and clients.

The CygNet OPC UA Server adheres to the OPC UA specification, which is a service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework.

The CygNet OPC UA Server 1.0 operates with CygNet v9.5 or later and CygNet Bridge v4.4.121 or later.

An OPC UA (Unified Architecture) Server retrieves data and makes it available to an OPC UA client. CygNet supports its own CygNet OPC UA Server which communicates with a CygNet system to request and receive data via HTTP using via our flexible intermediary REST API application, CygNet Bridge API.

Ordinal

Ordinal is a generic term for an identifier. In an analog output data group, the ordinal would represent a point number or channel number. The name of an ordinal is manufacturer, device, and data group specific.

For more information, see Data Group Ordinals and Facility Ordinals.

Ordinalized Data

If a point has more than one value at exactly the same timestamp, CygNet stores the extra value only if it is different. For example, if a value is set to 1.01 @ 12:32:15.004, 1.02 @ 12:32:15.004, and 1.03 @ 12:32:15.004, the VHS will store all three values even though the timestamps are exactly the same. CygNet assigns each entry a timestamp ordinal to allow a differentiation between the three entries. The datastore would reflect the following:

Value	Timestamp	Ordinal
1.01	12:32:15.004	0
1.02	12:32:15.004	1
1.03	12:32:15.004	2

The VHS datastore only evaluates the last (i.e. largest) ordinal to determine whether to set a new value. If another value of 1.03 @ 12:32:15.004 is set, CygNet will not store this as a new entry with an ordinal of 3, as it is detected as a duplicate. However, if a new value of 1.01 @ 12:32:15.004 is set, the VHS datastore will identify this as a new value (and not a duplicate) since it only compares the value to the largest ordinal, which is the 1.03 value at ordinal 2.

Ordinalized Data Group, Data Group Ordinal

You can ordinalize a data group if a remote device requires multiple instances of a data group. This means that you define the group only once in the template but can add multiple instances of it in the DDS. The term ordinal can also mean a facility. See Data Group Ordinals and Facility Ordinals.

Ordinalized Facility, Facility Ordinal

An ordinalized facility is associated with the original remote device facility and is displayed on the Facilities page of the device editor. Ordinalized facilities must be created in or chosen from the Facility Service (FAC). See Device Facilities and Linked Facilities and Data Group Ordinals and Facility Ordinals.

Owner

The Address Resolution Service (ARS) that can confirm deletion of the service entry. A service can be deleted only from its owner.

For more information see ARS Redundancy.

Permission Level

The security authorization level required to perform an event. CygNet supports six permission levels: None (no access), Read, Update, Add, Delete, and Administrator (unlimited access).

For more information see Permissions.

PG

Numeric Page. Associated with the GNS. For more information see Notification Types.

PID

Proportional Integral Derivative control.

PM

Periodic Metering. In CygNet Measurement, data designated as PM (Periodic Metering) or PQ (Periodic Quality) appears in multiple data files, commands, controls, reports, properties, and data-mapping usages. For more information see CygNet Measurement Terminology.

PLC

Programmable Logic Controller. For more information see Devices.

Point

A point represents a discrete value that is user-defined and configured in the Point Service (PNT). See also Point ID and Point Type below.

For more information see Points Overview.

Point ID

The Point ID is one of two identifiers of a data point. After a point has been created, its Point ID cannot be changed.

CygNet naming standards for point identifiers are as follows:

Component	Valid Character Set	Limits
Point ID	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (uppercase) 0 1 2 3 4 5 6 7 8 9 ! (exclamation point) # (pound) $ (dollar) % (percent) ^ (caret) & (ampersand) _ (underscore) = (equals) + (plus) [ (opening bracket) ] (closing bracket) { (opening brace) } (closing brace) | (vertical pipe) < (less than) > (greater than)	8 character limit No spaces

See also Long Point ID above.

For more information see Point Identifiers.

Point Scheme

The Point Scheme defines the point types, point alarms, point statuses, and default colors for a CygNet domain. The information described in this Help is primarily for the CygNet Standard Point Scheme (Point Scheme 0). The Point Scheme is applicable only to the PNT as configured on the PNT Editor for each point. For more information see Point Scheme and Startup Files.

 

Point Service (PNT)

The Point Service (PNT) is the CygNet point database service used to set operational parameters for real-time points in the CygNet system. A point record contains all configuration information about a point, including the name of its current value service (CVS), its Facility, Uniform Data Code (UDC), the Short ID and Long ID, description, engineering units, history retention period, alarm setpoints, scaling factors, notification options, enumeration conversions, etc.

The PNT manages alarm limits, conversion coefficients, description information, and other parameters necessary for real-time monitoring and control. One PNT can store point records for any number and any type of current value service (CVS). A point is required to see the data on a CygNet Studio screen, in a report, in a trend, or on a web page.

For more information see Points Overview.

Point State

Point state is the highest precedented state for a point record as defined in the CvsMetadata file for each CygNet Point Scheme. Every point state definition available for a Point Scheme has the following attributes: ID, name, description, display order, token, associated state colors (single color, foreground color, background color), and an alarm condition.

The point state for a point record is based on 48 System, Configuration, and User Status Bits, which are associated with the four point types (Analog, Digital, String, Enumeration). A point record may contain up to 48 Status Bits, which are used to provide point status information about the point record in a Current Value Service (CVS) and the Alarm Event Logging Service (ELSALM). A point can be in multiple states at the same time, for example, in High Warning and High Alarm; however, the state defined to be the most severe is the one that is used for the point state (i.e., High Alarm, in this case).

CygNet Standard Point Scheme

The following table lists the common point state definitions for the standard Point Scheme. These definitions do not allow alarm condition configuration.

Analog	Digital	Enumeration	String
Normal	Normal	Normal	Normal
Unreliable	Unreliable	Unreliable	Unreliable
Uninitialized	Uninitialized	Uninitialized	Uninitialized

CygNet Enhanced Point Scheme

In the CygNet Enhanced Point Scheme or other customized Point Schemes (Point Scheme 1 - 15), the point state and other desired attributes (description, display order, associated state colors, etc.) can be configured in the CvsMetadata file as needed. See Understanding the CVS Metadata File for more information about configuring Point Scheme properties.

For more information also see Alarm Condition.

Point Type

A point type may be defined as analog, digital, enumeration, or string. For more information see Point Types.

PQ

Periodic Quality. In CygNet Measurement, data designated as PQ (Periodic Quality) or PM (Periodic Metering) appears in multiple data files, commands, controls, reports, properties, and data-mapping usages. For more information see CygNet Measurement Terminology.

Primary Point

Most objects on a CygNet Studio screen can be configured to show point information from a specific point, such as a point’s value, timestamp, description, etc. This point is referred to as the object’s primary point. Tools that can be configured with a primary point are identified in the icon by a small red "C," such as the Text Tool. To show point information, an object must identify the point using a fully qualified CygNet tag string.

For more information see Configuring Point Identifiers.

Production 4.0

CygNet software is a vital component of Production 4.0, the Weatherford production performance solution that delivers end-to-end control, data management, and advanced data analytics to activate field-wide intelligence and maximize production across your assets. In addition to the CygNet IoT/SCADA platform, Weatherford Production 4.0 products include the ForeSite optimization platform, ForeSite EDGE IoT-enabled automation, ForeSite Sense intelligent sensors, and Flow Measurement water-cut and multiphase technologies.

For more information refer to the ForeSite Production 4.0 page on the Weatherford website or contact your Weatherford account manager.

Property vs. Attribute

While the terms "property" and "attribute" are synonyms in general use, in CygNet these terms convey a more nuanced meaning.

A property refers to the aspects of a particular thing (facility, group node, point, etc.) with a predefined and shared meaning (for example, name, description, category, color, etc.), while attribute refers to the aspects of said thing with a configurable meaning. All facilities have a name and category; those are properties of a facility. Facility Attribute 1 can be configured to mean Order in Type or Route or Tank ID; it is an attribute.

Pump-Off Control (POC)

Pump-Off Control (POC) uses dynagraph cards to view well performance. CygNet provides an application for accessing and viewing these cards.

For more information see CygNet Dynagraph Viewer.

PV

Process Variable. For more information see EFM Data Items in the Remote Devices section.  

RA

Reference Address (associated with the GNS). For more information see Notification Types.

Real-Time Record (RTR)

A Real-Time Record (RTR) is the record structure that is entered into a current value table and stored within the UIS. An RTR consists of the point ID, description, value, measurement unit, timestamp, and status.

For more information see Viewing a Real-Time Record.

Redundancy

CygNet Redundancy achieves continuous operation of all CygNet services in the wake of component failure in the system, whether failure is due to normal operational transition of data from one location to another (via replication to move data from a primary server to a DR server, or backup, or forwarding, etc.), or due to an unforeseen natural disaster.

Each site in a CygNet environment runs on a unique domain and each domain is assigned a specific role: Active, Local Standby, or Data-Center Standby. When a failover is triggered (either manually via human intervention or automatically triggered without warning), all sites will swap domains, and assume a different role. Clients will always connect to the same domain, regardless of where the domain is running, and not have to make any changes as the result of a failover. CygNet redundancy operates on top of the CygNet replication model and is supported by underlying replication functionality, although replication is disabled for all services in a redundant environment.

For more information see CygNet Redundancy.

Reference Facilities and Relative Facilities

CygNet supports the ability to resolve and/or display information about a facility that is different from the facility of the configured point for an object. For any given facility you can define a path to another facility within your CygNet environment based on an attribute and a definition.

Known as Reference Facilities and Relative Facilities, these concepts are similar, but the implementation and configuration of each differs.

• Reference Facilities — Reference Facilities can only be configured for CygNet-aware tools in CygNet Studio via the [ReferenceFacility] property. Referenced facilities only support a single level of resolution. They can be configured to resolve to a facility that matches a Source Attribute or a Facility Filter Rule.
• Relative Facilities — Relative Facilities represent a more sophisticated method of referencing related facilities because it allows for multi-level resolution of facilities. This type of facility resolution is configurable (or scripted) from different locations within CygNet.

For more information see Reference Facilities and Relative Facilities.

Remote Device

Remote devices are the field RTUs and PLCs. Remote device component-level security is administrative security, governing factors such as who can change a device's configuration. See also RTU and PLC.

For more information see Remote Devices.

Remote Service Manager (RSM)

The Remote Service Manager (RSM) is used to control other CygNet services. It is sometimes called a metadata service since it manages information about other CygNet services. Service control can be on the local machine, on other machines in the local data center, or on machines in a remote data center. CygNet Redundancy functionality is handled by the RSM.

For more information see Remote Service Manager.

Remote Terminal Unit (RTU)

A Remote Terminal Unit (RTU) is a device that collects data from data acquisition equipment and transmits real-time values to the main system over a wired or wireless network to be stored and processed by the UIS.

For more information see Facilities Overview.

Report Module

See CygNet Report Module.

ROC

Remote Operations Controller; ROC also is the product name for a class of RTUs produced by Emerson Process Management (formerly Fisher).

For more information see Emerson Roc EIE or Emerson RocPlus EIE.

Roll-Down Points

A Roll-down Point is a basically a shadow point. It takes the data from the Device Facility and rolls it down to a point for a Linked Facility.

For more information see Roll-Down Points.

Rollup

Group rollups enable the "rolling up" or aggregation of information from the leaf nodes of a hierarchy to designated summary root- and sub-group nodes in the Group Service (GRP). When a rollup request is issued, it moves down the hierarchy to all relevant leaf nodes (facilities) searching for specified uniform data codes (UDCs), then rolls back up the hierarchy with the current value collected from the leaf nodes' specified current value service. This information is used to calculate totals, averages, and facility alarms.

For more information see Group Rollups.

SCADA

CygNet Software is a Supervisory Control and Data Acquisition (SCADA) system that collects and manages critical real-time and operational data.

Seat

A seat is a computer that is running one or more client applications. For more information see Managing CALs.

Security Supervisor

A person with the authority to assign Application Administrators and to add applications and events to an Access Control Service (ACS).

For more information see Security Supervisors.

Service (SRV)

A CygNet service performs pre-defined transactions in response to client requests and is responsible for acquiring, storing, organizing, and saving data. The CygNet Software application consists of 23 services that perform interrelated functions. CygNet services are categorized into five basic operational service types:

• Administrative Services
• Current Value Services
• Database Services
• Measurement Services
• Real-Time Services

CygNet naming standards for service names are as follows:

Component	Valid Character Set	Limits
Service	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (uppercase) 0 1 2 3 4 5 6 7 8 9 $ (dollar sign), ! (exclamation point), and _ (underscore)	8 character limit No spaces

For more information see Services Overview and Installing and Deleting Services.

Service Monitoring Service (SVCMON)

The Service Monitoring Service (SVCMON) is a specialized current value service that provides a method to monitor many system, service, and site statistics. The SVCMON can be used to perform service health checks, check ping times, monitor disk utilization, software and operating system version numbers, memory usage and ping times. Attributes of specific services can also be monitored, such as VHS database utilization and percent full, pending GNS notifications, total points and maximum points for current value services, and Address Resolution Service license counts.

Additionally, the SVCMON supports a defined set of calculation types. Point tags can be added to monitor deltas and rate changes. For point tags that represent file sizes, items can be scaled. The maximum point count for the SVCMON is 500,000 points.

For more information see Service Monitoring.

SIP

Session Initiation Protocol (associated with the GNS). For more information see Configuring VoIP Properties.

Site

A site is a collection of CygNet services. (The site name is a property of the service.) Services can be grouped into sites based on geography, division, region, functionality, etc.

CygNet naming standards for site names are as follows:

Component	Valid Character Set	Limits
Site	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (uppercase) 0 1 2 3 4 5 6 7 8 9 $ (dollar sign), ! (exclamation point), and _ (underscore)	8 character limit No spaces

For more information see Services Overview.

SM

SMTP Mail Address (associated with the GNS). For more information see Notification Types.

SNPP

Simple Network Paging Protocol. For more information see SNPP Messages in the Notifications section.

SP

SNPP Message (associated with the GNS). For more information see Notification Types.

Status Bits

CygNet supports several different status flags or words, each containing Boolean bits, which are used to provide status information about a point record in a Current Value Service (CVS). Each point record has 48 Status Bits. Status Bits are defined in the Point Scheme. There are three types of Status Bits: System Status Bits (17), Configurable Status Bits (15), and User Status Bits (16). See Point Status Bits for more information.

STUN

Session Traversal Utilities for NAT (associated with the GNS). For more information see Configuring VoIP Properties.

Support Data Group

See Data Group.

System Status Bits

System Status Bits denote miscellaneous state information about a point in the CygNet system, including:

• Basic point value information – whether the point is Initialized, Updated, Unreliable, or an External Value
• Basic alarm information – if an alarm is suppressed or its Alarm Priority Category
• Point type of the record – Analog, Digital, Enumeration, or String
• Point Scheme — the Point Scheme with which the point is associated
• VHS information — whether the VHS point has been edited or deleted

There are 17 system Status Bits that can be associated with a point record. The bit IDs for Status Bits are predefined within CygNet and should not be changed. See Point Status Bits and System Status Bits for more information. Also see Configurable Status Bits and User Status Bits.

System UDCs

In CygNet a System UDC is used to create tags for:

• Communication statistics
• UIS parameters
• Queue statistics
• Performance statistics
• Facility information
• Device information
• Text Import statistics
• Device control information
• Service Monitoring Service statistics

System UDCs are intrinsic to CygNet and are not mapped to elements in the DDS.

For more information see System UDCs.

Table-Driven Field

A field for which the selections are contained in a list box. The selections in the list box are contained in a table. The name of the table that contains the selections for the box can be displayed by placing the pointer over the field.

Table Reference Service (TRS)

The Table Reference Service (TRS) stores selections for table-driven fields and Uniform Data Codes (UDC). Some table fields are system-defined. Others are user-defined.

For more information, see Tables.

Tag

Most objects on a CygNet Studio screen are used to show point information. To do so, an object must identify the point using a fully qualified CygNet tag string. The recommended tag string format is the Facility Tag String.

For more information see Tag String Formats.

TCP/IP

Transmission Control Protocol/Internet Protocol. This protocol is used to identify network addressing and is monitored by the Address Resolution Service.

For more information see Network Addressing.

Timestamp

Timestamps are used to denote the date and/or time at which a certain event occurred.

For more information see Timestamps.

Timestamp ordinal

CygNet can store multiple values at exactly the same timestamp. Each entry is assigned a timestamp ordinal to allow differentiation between values. See Ordinalized Data above.

TFX

Flow-Cal formatted files. For more information see FMS Commands.

TheFrame/TheView

The CygNet Studio screen.

• TheFrame refers to the container. Properties specific to TheFrame include the height and width, title bar, minimize/maximize buttons, overall resizing options.
• TheView refers to the form. Properties specific to TheView include the background color, default font, layers. In most instances the screen is referred to as TheView.

For more information see Using TheFrame TheView.

Thin Web Client

CygNet Thin Web Client (TWC) is CygNet's browser-based HMI client application for viewing operational screens and workflows in a Web browser using sophisticated web-based technologies. Currently the designer for building web-based screens is a web-enhanced version of the Canvas desktop application.

For more information see CygNet Thin Web Client.

TLP Data

Logical collections of data accessible in a Emerson ROC or Emerson ROCPlus database. TLP stands for point type, location/logic, and parameter. TLPs use a unique referencing scheme that associates a point type number, logical (or location) number, and parameter number in order to specify a TLP location.

For more information see Emerson ROC Generic TLP Data Group and Emerson ROCPlus Generic TLP Data Group.

Token

A token is a piece of code that may be substituted for a dynamic string of text. A token represents an attribute of a point, the point’s CVS record, or its Facility attributes. For example the token %Description% can be used to substitute for the Description of a point in many locations in CygNet Software.

For more information see Using Text Tokens or Using Tokens in Notifications.

Transaction Record

A data group can be configured to retain Transaction Records. A Transaction Record is a record of the data requested from or sent to the device. Transaction Records can be viewed only from the Transaction field in the data group’s View Data dialog box. The number of Transaction Records retained is defined by the data group’s Transaction retention settings. The records are processed on a first-in, first-out basis.

For more information see Data Groups.

Trend

A trend provides a way to create a graphical representation of data change over time. Trends provide a (usually) customizable means to chart data in a number of useful formats, including line graphs, bar graphs, and area graphs. Trending capabilities are used by number of CygNet applications.

For more information see Trend Tool.

UIS Command

A UIS command is a means to perform a specific action using a data group. A command can be used to retrieve data, send data, or both, among other things. UIS commands are configured per device, per facility.

For more information see UIS Commands.

Uniform Date Code (UDC)

Uniform Data Codes (UDCs or data codes) are CygNet’s version of uniform product codes. They represent individual pieces of data in the system and can be used as a method for standardizing data identification. UDCs are a common collection of points within a system and are stored in the Table Reference Service (TRS). For example, commonly used UDCs include PSTATIC for Static Pressure, PDIFF for Differential Pressure, TGAS for Gas Temperature, and VBATT for Battery Voltage.

CygNet naming standards for UDCs are as follows:

Component	Valid Character Set	Limits
UDC Name	A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (uppercase) 0 1 2 3 4 5 6 7 8 9 - (dash) and _ (underscore)	10 character limit No spaces
UDC Description	String	40 character limit
UDC Category Name	String	10 character limit Use ~UDC for the first four characters
UDC Category Description	String	40 character limit

See also System UDCs above. For more information see Uniform Data Codes.

Universal Interface Service (UIS)

The Universal Interface Service (UIS) is the primary interface between field devices and CygNet devices. As the primary data collection service, the UIS is often called the "workhorse" of the CygNet system. It collects data for the devices stored in the Device Definition Service (DDS) and can store real-time records for up to 500,00 points for a 32-bit UIS and 5,000,000 points for a 64-bit UIS.

Using CygNet Explorer, you can view current values for device points, as well as various device statistics for remote, communication, and import/export devices. The UIS works closely with the DDS and Master Scheduling Service (MSS), among other key services.

Both a 32-bit UIS and a 64-bit UIS are available.

• The 32-bit UIS has a maximum point limit of 500,000 points.
• The 64-bit UIS has a maximum point limit of 5,000,000 points.

For more information see Universal Interface Service.

User Account Control (UAC)

User Account Control (UAC) is a Microsoft Windows security infrastructure that limits user account privileges to enhance application safety. This is enforced by requiring administrator privileges to be assigned for the application(s), in order to perform certain administrative tasks. Refer to Microsoft online documentation for more information about UAC.

For more information see CygNet and User Account Control.

User Status Bits

User Status Bits are configured by a user to associate special status information about a point. There are 16 User Status Bits that can be associated with a point record. See Point Status Bits and User Status Bits for more information. Also see Configurable Status Bits and System Status Bits.

Utilities

CygNet provides many stand-alone and command-line utilities to help manage your CygNet installation, including tools to help with the following tasks: installing software and updating hosts; host and license management; service diagnostics, monitoring, and management; database and file management; service configuration file management; communication device, remote device, and device template management; data group management; facility and group management; point configuration and management; data export; auditing and logging management; replication and redundancy management; and much more.

For more information see Utilities.

VA

Voice Address (associated with the GNS). For more information see Notification Types.

Value History Service (VHS)

The repository for historical data in CygNet Software is the Value History Service, also known as the CygNet Historian or the Enterprise Historian, or simply as the VHS. History reporting is configured on a per point basis. Reporting options are properties of the point configuration record.

Both a 32-bit VHS and a 64-bit VHS are available.

For more information see History and PNT Editor - History Page.

VoIP

Voice over IP (VoIP) is a technology for the delivery of voice communications over Internet Protocol (IP) networks, such as the Internet. The CygNet General Notification Service (GNS) supports voice messaging for notifications via the SIP transport and media transfer protocols.

For more information see SIP and Configuring VoIP Properties.

Well Test

The CygNet Well Test Module is integrated with the CygNet SCADA system to track oil, water, and gas (OWG) values for wells in a production facility. See Well Test for more information.

XML

Extensible Markup Language.