Alarms were originally shown on Piping and Instrumentation Diagrams / Drawings (P&IDs) to document hardware requirements for installation in a (panelboard) control room. This was important because there was limited real estate in the control room for the alarms (displayed on Panalarms and light boxes) and there was a real cost to wire them up (approximately $1000 / alarm). Alarms are often treated as if they are “free” in the modern distributed control system (DCS). They are configured in software and displayed on a PC monitor (HMI). This raises the question whether it is still necessary, or even beneficial, to document DCS alarms on P&IDs.

A bit of History

The P&ID is a process design tool used to document process flows, instrumentation, control input and outputs, interlocks, and installed equipment. (Figure 1)
In the pre-DCS era of pneumatic controls, stand-alone electronic controls, and alarm lightboxes, P&IDs were used to communicate certain design information to the Control Systems Engineering group.

According to Bill Hollifield, “So if we in process design specified a “Temperature Controller” (and incidentally, would also indicate if this was to be a “control room instrument” or a “locally mounted instrument”) there would be a specific decision by us if alarm(s) were justified on that measurement. If we decided they were, we would put an “H” or “L” next to the controller bubble.”

Hollifield also said “The result of doing this was that a running count of alarms could be determined by inspection of the P&ID. This enabled sizing of the Panalarms for cost estimating purposes. Since Panalarms and all the wiring associated with them were expensive; every alarm was justified.”

More History – Along Comes the DCS

With the P&ID methodology firmly established, along comes the DCS. Instead of revising the P&ID paradigm, it was simply extended and minimally adapted to the DCS. A DCS controller, for example was shown with a box around the bubble, rather than a plain bubble.

But the DCS does have very a different paradigm. Each measured value in the modern DCS can have several different types of alarms configured in software at no extra cost.

The P&ID design practice was adapted at many companies to identify alarms for configuration in the DCS. From the point of view of the project team, justification of individual alarms was no longer important. The thought was often “the owning department can decide whatever alarms they want and turn them on.” Or “we will follow a rule of thumb and turn on by default all HH – H – L – LL alarms at 95%, 90%, 10%, and 5%. Production can change them if they like.” (A really poor practice!) None of this was put on the P&ID for a new project – it would have been a lot of work for absolutely nothing. And there is no way it could have been “complete and accurate” – some point types in a DCS have 16+ alarm types!

In some places, the P&ID indication of an “H” or “L” next to the bubble “evolved” to indicate that a lightbox-type alarm was to be installed on this specific measurement. Thus it took on a different and inconsistent meaning if the alarm was shown on the P&ID. 

Regulations and MOC

The introduction of OSHA’s regulation for Process Safety Management (PSM) (1910.119) caused most companies to take management of change (MOC) more seriously. Before the 1980s, keeping P&IDs up-to-date was often not taken very seriously. In fact, the first task in most expansion projects was to verify the current installation and update the P&IDs. OSHA PSM prescribes that Process Safety Information (including P&IDs) be available and up to date. It does not, however, state what information must be included on a P&ID.

Does it Make Sense to use the P&ID to document a DCS Alarm Configuration?

With the modern DCS, documenting alarms on P&IDs may be more trouble than it is worth. Some reasons to consider:

• Bad PV Alarms - With the advent of better instrumentation, every analog transmitter seems to be capable of generating a “Bad PV” diagnostic alarm. These certainly don’t add value to the P&ID, so why include any alarms at all?
• Alarm names are different – Alarm names on P&IDs (e.g., TAH100 and TAHH100) are often different than those used in the DCS (e.g., TIC100-High and TIC100-HighHigh).
• Alarm rationalization defines the alarms to be configured in the DCS - Alarm rationalization is the process of reviewing potential alarms to verify that they meet the criteria for being an alarm, and for documenting their cause, consequence, corrective action, priority, and limit. The output of rationalization is a master alarm database (MADB), which is the authorized list of rationalized ala
• rms and their settings. Since rationalization is an ongoing activity, much effort would be spent updating the P&IDs to keep them consistent with the MADB.

Thanks to Bill Hollifield for sharing his insights on alarms and P&IDs.