CygNet Well Test Components

The CygNet Well Test Module is a complex application that integrates several components. The following diagram shows the various components of the module.

Note that this model is only applicable to Host-based devices. A slightly different model is needed for Device-based configurations. Each component is described below, with a link to more information for each.

Click the following image to see the various components of the CygNet Well Test Module:

CygNet Well Test Module Components

See the following subsections for more information:

• Well Test API
• Well Test Windows Service
• CygNet Setup
• Well Test Configuration Control
• Well Test Configuration XML
• VB Script to Process Well Test Results
• Well Test Record Storage
• Well Test Canvas Screens for HMI

Well Test API

The CygNet Well Test Module requires the CygNet.API.WellTest assembly, which is used by the back-end CygNet Well Test Windows Service, the well test configuration XML, the Canvas well test screens, and external systems such as ForeSite. It is located in the CygNet\Bin directory and is automatically version managed by Canvas.

The CygNet.API.WellTest has two helper functions that can be used to retrieve well test records:

• The GetAllWellTests function is supplied with starting and ending timestamps. The well test records are returned in a jagged dictionary object.
• The GetWellTestsForWell function takes in the well facility tags along with timestamps to retrieve the well test records.

See Retrieving Well Test Records for an example of these functions.

Well Test Windows Service

The CygNet Well Test Module requires the CygNet Well Test Windows Service. This Windows service monitors the well test configuration XML stored in the HyperPoint of the Header Queue point for starts and stops, value changes, and then executes the well test commands and actions.

The service requires a Windows Service config file, which points to the configuration point containing the well test configuration XML. The CygNet Well Test Windows Service Config File (WellTestServiceConfig.xml) takes the following format:

The service is installed via CInstall on the host CygNet server and includes an Application Definition File (.app) and Response List File (.rsp) to facilitate version management. The service must be located on the CygNet server and utilizes the CygNet.API.WellTest.

Well Test Persistence

The Well Test Service uses a persistence model to ensure smooth operation of any active well tests should the service shutdown unexpectedly in the middle of a well test operation. When the service starts it reads the XML in the HyperPoint of the configured Header Queue points. The XML includes an <ActiveWell> section and an <ActionQueue> for the well in an active well test.

In the following example AMANDA_WL is the <ActiveWell> and its <ActionQueue> contains several well test actions to be completed. This data is kept updated as changes occur, but not when the service is triggered for shutdown. When the well test service is triggered for shutdown, a list of any remaining actions will be written to the <ActionQueue> element of the header point XML. A list of the remaining wells to be tested is written to the <PendingQueue> element (in this case: ESSEN_WL, PELICAN_WL, and VIRGINIA_WL). When the well test service is triggered to start or restart, the XML configuration will be loaded. The well test service will then look for the existence of an <ActiveWell>, if one exists, any remaining actions will be loaded into the Action Queue for the Well, and the Action Queue will be restarted (in this case: Test, PointValueCompare, SetPoint, and so on…).

CygNet Setup

The CygNet Well Test Module requires a typical CygNet configuration, with defined CygNet facilities, points, UDCs, UIS commands, scheduling commands, etc.

See Configuring CygNet Well Test for more information.

Well Test Configuration Control

The CygNet.API.WellTest.Controls.dll is a plugin control assembly that can be made available for use in Canvas to allow the manual configuration of the well test configuration XML file. This plugin provides a user-friendly method for defining the necessary elements required to execute a well test via a Canvas screen. Using the control assembly and a configuration screen you can easily define the following well test properties: point scheme, data retention value, relative facilities, UDCs, headers, wells in the well test, header templates, positions, commands, and associated actions for each command.

See Configuring Well Test Using Canvas for more information.

Configuration Headers

The well test configuration XML contains the following important elements:

• Header Point — The well test configuration XML contains a list of headers and their associated wells that will be included in the well test sequence.
• Header Point Queue — The queue is an XML string that is written to the Header point (as HyperPoint Script Text). There are multiple header queues, one for each header, and each can be modified in many ways (i.e. screens, MSS, external interface such as ForeSite, etc.). A SetPoint command is issued to the Header Point to tell the queue to do the work. For example, a value of "Start" will start the well test process on the specific header/test facility. The first enabled well in the queue is taken off, passed into the workflow, and processed according to the configuration. After that well is finished, the next enabled well in the queue is taken off the queue and processed. Other values can be set to control the processing of the queue (Abort, Stop, Complete, etc.) as the well test process unfolds.

Well Test Configuration XML

The Well Test Configuration XML defines the logical blocks required to perform well test actions. It includes header points, which define the associated wells to be included in the well test sequence, and the relationship of wells to the valves in various positions, and a header queue to monitor multiple headers. The well test configuration is an XML string that is manually written to a configuration point in the PNT as HyperPoint Script Text.

See Configuring Well Test Using XML for more information.

VB Script to Process Well Test Results

Once the well test action sequence completes, the well test contents must be generated. Since the values for the well test record can come from various locations due to the unique configurations at the field-level, a programmable approach in the form of a VB script is required.

A sample script is available to illustrate the concept of processing supplied arguments and providing the necessary output that the CygNet Well Test Module expects in order to process a well test record. The VB script will need to be customized for the user's environment.

See Processing and Storing Well Test Results for more information.

Well Test Record Storage

Well test records are stored as XML strings in VHS entries for each configured well. After the VB script exits processing, the well test data is complete, and the appropriate output is available, the CygNet Well Test Module will create the well test configuration XML record (an XML string) and store it as a BLOB entry in the appropriate VHS point. External systems can also consume the well test records stored in the VHS using the CygNet.API.WellTest API.

See Processing and Storing Well Test Results and Retrieving Well Test Records for more information.

Well Test Canvas Screens for HMI

CygNet Well Test Module uses Canvas screens to visualize well test status and detail information. The screens can also be used to initiate an on-demand well test campaign. The sample Canvas screens are included on the CD_Image in the Samples\Well Test folder. The screens will need to be customized for the user’s environment.

See Sample Well Test Screens and Scripts for more information.