Data Acquisition and Continuous Control

The heart of the CMX Process Control System lies in processing data acquisition and continuous control points.  The basic unit in this process is called a “Tag.”

Put simply, a Tag is the collection of all information necessary to acquire a process measurement, convert it to engineering units, perform a control calculation, send an output back to the field, and alarm any unexpected conditions.  A single CMX System can support up to 4096 Tags with a processing rate of approximately 1000 Tags per second on a Pentium II-based computer.

Unlike other commercial process control systems, CMXä does not require the concept of a Tag “type.”  Instead, CMXä lets the user configure any Tag with any of the available processing algorithms, while the System is on-line, and change these algorithm assignments as necessary.

Each Tag is made up of the following Tag components:

• Tag Name Information
• PV Processing
• PV Filtering
• Control Processing
• Output Processing
• Alarm Processing

Tag Name Information

The Tag name information part of the Tag contains the name, a 20-character description, an engineering units description (i.e., DegF, PSI, etc.), and the Tag’s scan frequency.

PV Processing

Process Variable (PV) processing specifies how the PV is to be calculated.  Each Tag acquires one process value per scan.  The user selects a processing algorithm by choosing from a library of standard algorithms.  All processing algorithms handle both analog and digital signals.  Some typical functions include:

• Scale a Linear Input
• Linearize a Thermocouple
• Calculate Flow from a DP Cell
• Get a Digital Contact Status
• Sum of Values
• Boolean Operations

The user can also create custom PV processing algorithms using the CMXä Algorithm Control Language (ACL).

PV Filtering

Once a raw PV is calculated by the process algorithm, the user can optionally pass the result through the Tag’s filter algorithm component.  For example, a raw PV value can be passed to a filter algorithm to derive a first order exponential.  As with the processing algorithms, CMXä has a library of standard filter algorithms to choose from. The user can also create custom filter algorithms using ACL.

Control Processing

After it is calculated, the PV can be used to supply control feedback to the process via the Tag’s control processing component.  CMXä provides a complete library of standard control algorithms such as PI, PID, Ratio Control, etc.  The user can also create custom control algorithms using ACL.

All standard algorithms support both initialization and normal control processing.  Algorithms are initialized before normal processing begins, whenever the controller mode is switched from manual to automatic, facilitating bumpless control transfer from local to the computer.  In addition, the PID-type control algorithms automatically provide logic for anti-windup protection and the initialization of cascades.

Output Processing

Once a control output has been calculated, the Tag’s output component indicates whether outputs are to be sent to the field directly or to another Tag in the System as part of a more complex control strategy.

Alarm Processing

The alarm processing component triggers alarm messages when the PV violates user-specified limits.  Each Tag is automatically assigned a bad PV alarm.  This alarm is generated whenever the PV algorithm detects an invalid value, such as an open thermocouple.  Once a PV has been set “bad,” any other calculations using the value will also have a “bad” result.  The user can specify up to 7 additional alarm checks in addition to the bad PV alarm.  Each alarm is defined by an alarm algorithm, low and high limits, a dead band, and an alarm priority.  The user can create new alarm algorithms using ACL.

When an alarm is first triggered, a message flashes in red at the top of the screen and remains there until it and all other alarm messages have been acknowledged. Once acknowledged from the alarm Display, the System clears and deletes the messages from the message queue, then returns the alarm condition to normal status.  The Alarm Display shows;

• The Tag name and a description
• Unacknowledged alarm messages displayed in red
• Acknowledged messages displayed in yellow
• The real time PV displayed in green, and
• The alarm name with the alarm limit that was violated.

For specific alarm details, the Operator can display the Tag that triggered the alarm and consult the Alarm Algorithms Sub-display.  Here, up to seven alarms, their alarm priorities, status, and the date and time of the most recent alarm can be reviewed.

The following alarm priorities are listed starting with the lowest priority:

• None - The alarm is indicated but not logged in the Alarm and Function Change (AFC) log.
• Log only - The alarm is indicated and entered in the AFC log.
• Seqintr - The alarm can interrupt SCL programs.  They are indicated and entered in the AFC log.
• Console - The alarm can interrupt SCL programs and can be displayed on the console.  They are also indicated and entered in the AFC log.
• Audible - The alarm has the highest priority and includes all the functions of a console priority alarm.  The alarm message is also put into the audible alarm queue.

The Operator also can enable, disable, or override a Tag’s alarms, change an alarm priority, and modify its alarm algorithm parameters from the Alarm Algorithms Sub-display.

History Sub-display

The History Sub-display presents the historical PV data in a tabular format.  Several optional history command parameters limit the range of the report to before, after, or around a  specific date and time.  The report can be furthered by specifying a particular history class.

Graph Sub-Display

The Graph Sub-display plots up to four PVs on the same display, or displays dual graphs each featuring one PV plot.  A set of formatting parameters controls the time range and general appearance of graph(s)

Tune Sub-display

The Tune sub-display graphically shows real-time trends for the PV, setpoint, and output parameter of a Tag and the PV of a second Tag.  All limits can be changed when selected or by command.

Creating New Algorithms

Besides supporting pre-defined algorithms, CMXä also furnishes the user with a means of writing custom algorithms.

ACL, the Algorithm Control Language, is an easy to learn language that makes the manipulation of process data very straightforward and simple.  ACL defines the algorithm and describes the resources it needs within the Tag such as the form of data storage, references to data sources, and presenting information to the Operator.

Reversed Polish Notation

Users who have worked with Hewlett-Packard calculators will have no difficulty with ACL’s use of Reverse Polish Notation (RPN).  Reverse Polish is simply a means of defining a calculation by stating the operands prior to the operator.  For example, 2 * 3 would be expressed as 2 3 * in RPN.

Program Structure

An ACL source file is organized into three sections:

• Declaration states the kind of algorithm being defined and lists the required data storage resources.
• Algorithm-Specific Parameters supply the details needed to meet the individual requirements of the various kinds of algorithms.
• Executable Code which falls into two categories; Algorithm Initialization Code and Algorithm Control Code.

Continuous History

The CMXä Continuous History System automatically records the PV of every Tag in the System at regular user-specified intervals.  Always operating in the background, the Continuous History System updates a cyclical history file with the most recently collected data.  Once a history file is full, the System begins overwriting records, starting at the first entry, until the file is full once again repeating the process.  Hence the name “Continuous History.”

The Operator can choose to view continuous history selectively from a Tag display, as tabular reports or as graphs through the associated Graph and History Sub-display.

Configuring Continuous History

When CMXä is initially configured, the user defines up to 16 continuos history classes for the application based on the following criteria:

• The class names and descriptions are assigned by the user.  Class names are used to retrieve historical data for presentation in displays and in reports.
• The period specifies how often PVs will be collected.  The period must be expressed in multiples of one minute.
• The history algorithm determines how a continuos history class PV gets processed.  Processing options include:
• PV spot values
• PV averages
• Minimum PV values
• Maximum PV values, or
• Standard deviation
• The class size specifies how much data will be stored for a class.  The user can select the number of days, hours, and minutes of history to be maintained before the file wraps to the beginning and starts overwriting.

When viewing continuous history, the Operator can select a tabular presentation by simply typing “history” or a graphic time-based plot by typing “graph” from any Tag Display. The graph sub-display plots up to four PVs on the same display, or displays dual graphs each featuring one PV plot.  A set of formatting parameters controls the time range and general appearance of graph(s).

(home)