Alarm & Trip Schedules

This week I was working on an Alarm & Trip Schedule for a client (hi Terri) and it occurred to me that this is a report that is required by almost every project, but is always a little complicated to produce.

Projects often require an Alarm & Trip Schedule to be produced from SPI, and it's often a frustrating process to extract the required data. The required fields appear in the Instrument Index module, the Process Data module, and the Wiring module, and no Browser conveniently combines everything into a single View. In fact, as a general rule, SPI doesn't provide many Browsers that mix data between modules.

Fortunately, it's actually quite simple to create an Alarm & Trip Schedule with APSR. The Query is relatively easy, making use of Virtual Fields and a nested Union, and of course the Grid or Designer make it simple to produce a deliverable report.

Typically an Alarm & Trip Schedule is a list of Instruments (usually Analog Inputs) with some basic tag data, the range of the device and/or DCS/PLC input, the Alarm & Trip Set-points (as defined by the Process Engineers usually) and the Set-points configured in the DCS/PLC. There may be other information, such as the I/O Card details, the Control System Tag & Description, etc.

The primary fields are found in the COMPONENT table, from which we select the core Instrument fields (Tag, Service, I/O Type) plus some range fields if required (Instrument Range, Calibrated Range and/or DCS Range).

Unfortunately, the Alarm & Trip Set-points are not in the Instrument Index, they're in the SPI Process Data module (a design decision that has caused a lot of frustration for many many projects). This creates two problems, one that the Alarm & Trip Set-points cannot be included in any Browsers in the Instrument Index module, and that it is necessary to create a Process Data entry for an Instrument before the Set-points can be entered. 

Often, to avoid these problems, projects will choose to use UDF's for alarms. This is a very practical solution, although it can cause confusion on projects where both the UDF's and the Process Data fields are used. 

The Process Data module has another complication, the Alarms & Trip Set-points are not stored in a single table, they're in the FLOW, LEVEL_INSTRUMENT , PRESSURE, and TEMPERATURE tables (depending on the Process Function Type of the Instrument). We need to use a UNION to combine the results from each of these tables in APSR, first by creating a Derived Table (sub-query) to hold the Union

In the Derived Table tab, we start with the FLOW table, and select the various Alarm & Trip Set-points and related fields:

Then create the Union by clicking the + next to the Q in the upper right corner of the window, this will open a new blank query pane for the next part of the Union. Add the LEVEL_INSTRUMENT table and select the corresponding fields here:

Repeat the process by adding new Union sections, adding the PRESSURE and TEMPERATURE tables, and selecting the corresponding fields. When we return to the Main tab, we now have a sub-query providing the combined Alarm & Trip Set-points from all of the Process Data tables:

(Note that the field descriptions are based on the first table in the Union)

The other place Alarm data is entered in SPI is as part of the Control System Tags associated with Instruments. By adding the CONTROL_SYSTEM_TAG table to our query we can extract the Control System Tag Name, Description, Calibration Range, Alarm Settings, plus other DCS and Wiring data as required.

In the end it's a relatively simple query. 

The results are shown below (click to enlarge).

I've used the APSR Grid to display the results. This makes it very easy to layout a simple report of rows & columns, and also is ideal if you need to export the final report to Excel. You could also use the Report Designer if you need a pixel-perfect fully formatted report.

You can download

• Alarm & Trip Schedule Report for APSR (you will need APSR installed), 
• Exported Excel report.

That's the basic report, but of course it can be modified to the requirements of any particular project. Also, the Grid Layout I've developed is designed for exporting to Excel and issuing as a document, but if a data extract is required for export to the DCS programmers (for example), that is just as easy.

Let me know your thoughts. Do you have any specific requirements for an Alarm & Trip Schedule? 

Regards,

Brian.