An alarm and trip setpoint list is the register that records, for every measured point on a plant, the values at which something is annunciated to an operator or actuated without one. It sits beside the I/O list rather than inside it. The I/O list says a signal exists and where it lands. The setpoint list says what that signal is watched for. Projects also call it the alarm and trip schedule, the setpoint schedule or the alarm and trip settings document, and the three names describe the same register.
In short
- The list is organised by tag, not by alarm. One transmitter usually occupies one row carrying several settings, because the settings only make sense relative to that instrument's range.
- A setpoint has no meaning without the range it sits inside. Carrying the calibrated range on the same row is what makes a setting checkable rather than a bare number.
- Alarms and trips share the document but not the consequence. An alarm asks an operator to act, a trip acts on its own, and the row has to say which it is and which system holds it.
- The document is a reconciliation surface. Three parties hold a version of the truth, and the value of the register is that it puts all three on one line.
- Every trip row should point at a cause and effect matrix row. A trip setting with nothing consuming it is either an orphan or a documentation gap.
What the register is for
An engineer arriving on a running plant can read the control system and see what is configured. What the control system cannot tell them is what was intended, who decided it, and against which instrument range the decision was made. That is the gap the document fills, and it is why the register outlives the commissioning it was built for.
It is used in four places. Configuration engineers load the control and safety systems from it. Commissioning teams prove each setting against it during loop checks. Operations reads it when an alarm is questioned. Management of change compares against it when a process condition moves. None of those uses works if the document is a list of numbers with no provenance.
The columns
Formats vary by owner, but the set below is what the published project formats agree on. The column that separates a usable register from a decorative one is the last group.
| Column | What it carries | Example |
|---|---|---|
| Tag number | The instrument the setting belongs to, matching the instrument index exactly | PT-1042 |
| Service | Plain-language description of the measured point | Separator inlet pressure |
| P&ID reference | The drawing the tag is read from, with sheet and revision | PID-0214 rev C |
| Calibrated range | Lower and upper range value as configured in the transmitter | 0 to 16 bar g |
| Engineering unit | The unit every setting on the row is expressed in | bar g |
| Low low | Setting at the lowest actioned level | 1.2 |
| Low | First low-side setting | 2.0 |
| High | First high-side setting | 12.5 |
| High high | Setting at the highest actioned level | 14.0 |
| Action type | Whether each populated setting annunciates or actuates | Alarm / Trip |
| System | Which system holds the setting | Control system / Safety system |
| Priority | Operator response class assigned during rationalization | High |
| Deadband | The margin a value must recover by before the condition clears | 0.3 bar |
| Source document | Where the design value came from | Process data sheet rev 2 |
| Matrix reference | The cause and effect row a trip feeds | CE-014 |
| Configured value | What is actually loaded, read back from the system | 13.9 |
| Status | Whether the row is issued, commissioned or under change | Commissioned |
Two columns in that list do work that nothing else on a project does. Source document converts an anonymous number into a decision someone made and can be asked about. Configured value is the only place the design intent and the live plant are written next to each other.
Alarm settings and trip settings on one page
Because both appear on the same row, the difference has to be stated explicitly rather than inferred from the column heading.
| Alarm setting | Trip setting | |
|---|---|---|
| What it does | Annunciates and waits for a human | Actuates without waiting |
| Who responds | The operator | The system |
| Normally held in | The control system | The safety system, where the function is a protective one |
| Removal | An operator can often suppress or shelve it under a defined procedure | Removal is a controlled bypass with its own register |
| Consumed by | The alarm system and the rationalization record | A cause and effect row, and the function behind it |
| Evidence it works | Alarm performance records | Proof testing, recorded elsewhere |
A row carrying a high high value against a tag whose action type says alarm, while the cause and effect matrix lists the same tag as a shutdown initiator, is the single most common inconsistency this document exists to surface.
A worked row
Take one line and read it the way a commissioning engineer does.
| Field | Value on this row |
|---|---|
| Tag | PT-1042 |
| Service | Separator inlet pressure |
| P&ID reference | PID-0214 rev C |
| Calibrated range | 0 to 16 bar g |
| Low low / Low / High / High high | (none) / 2.0 / 12.5 / 14.0 |
| Action type | Low alarm, High alarm, High high trip |
| System | High high in the safety system, the rest in the control system |
| Source document | Process data sheet rev 2 |
| Matrix reference | CE-014 |
| Configured high high | 13.9 |
Read down, the row says four separate things. The instrument measures inlet pressure on a range of 0 to 16 bar g, so every number after it is interpretable. Two settings ask an operator to act and one does not. The high high setting is held in a different system from the others, which tells a commissioning engineer they will prove it by a different route. And the design value is 14.0 while the plant is running 13.9.
That last line is the interesting one. A 0.1 bar difference is not obviously wrong. It might be a deliberate commissioning adjustment that nobody wrote back, or an instrument rescaling that moved the engineering conversion, or a transcription error. The register does not resolve it. What it does is make it impossible to miss, which is the whole function of carrying two columns instead of one.
The three registers that disagree
The reason this document drifts is that no single discipline owns the numbers on it.
| Holder | Owns | Updates when |
|---|---|---|
| Instrument index | The tag and its calibrated range | An instrument is added, replaced or re-ranged |
| Process data sheet | The design setting and the reason for it | A process condition or an operating envelope changes |
| Control and safety system | The configured value actually in service | Commissioning, a change request, or a start-up adjustment |
Each is correct within its own scope and each is updated on its own schedule. The setpoint list is where the three are forced into the same row, and a reconciliation that runs against all three is a genuinely different exercise from checking the document against itself.
The most damaging drift is the range. A setting is a fraction of a span, so when the span moves and the settings do not, the alarms either move relative to the process or leave the measurable range entirely. An instrument re-ranged from 0 to 16 bar down to 0 to 10 bar leaves a high high of 14.0 permanently unreachable, and nothing annunciates to say so.
Where it meets the rest of the document set
| Document | The join | What breaks when the join fails |
|---|---|---|
| Instrument index | Tag number and calibrated range | Settings expressed against a range the instrument no longer has |
| I/O list | Tag number and signal class | A setting against a point with no input to watch it |
| Cause and effect matrix | Matrix reference on every trip row | A trip value nothing consumes, or a matrix initiator with no setting |
| Alarm rationalization record | Priority and the rationalization decision | Priorities assigned twice and differently |
| Loop check records | Tag number, proven at commissioning | Settings never demonstrated on the real signal path |
| Control narrative | Service description and intended response | Prose describing behaviour the settings do not produce |
A project that maintains the setpoint list without maintaining those joins ends up with a register that is internally tidy and externally wrong, which is harder to detect than an obviously incomplete one.
What goes wrong
Settings without ranges. A list of bare numbers cannot be checked, only trusted. It is the most common defect and the easiest to fix.
One row per alarm. Splitting a tag across four rows, one per level, loses the relationship between the settings and makes the range column redundant four times over. Settings on one tag belong on one line.
Start-up adjustments that never come back. A trip raised to get a unit through commissioning is a temporary change with a permanent tendency. Without a status column and a configured-value column, the temporary setting becomes the plant's real setting silently.
Priority set in two places. When the rationalization record and the setpoint list both carry a priority and nobody nominates which one governs, they diverge within a revision or two. Pick one holder and reference it from the other.
Trips with no matrix reference. Either the trip is not actually a protective function and the action type is wrong, or the matrix is incomplete. Both are worth knowing.
Keeping it true after handover
The register is built during detailed design and used for the life of the asset, so the revision discipline matters more than the initial build. Three habits carry most of the weight. Issue it with a revision and a status per row rather than per document, so a single changed setting does not force a full reissue. Record the configured value at the end of commissioning rather than assuming the design value was loaded. And re-check every setting on a tag whenever that tag's range changes, treating a re-range as a change to the settings rather than to the instrument alone.
For the register that supplies the tags and ranges this document depends on, see what the instrument index carries. For the rationalization work that assigns the priorities, see alarm rationalization under ISA 18.2. For the document that consumes the trip rows, see the cause and effect matrix.