MOC and P&ID Documentation: Why I/O Lists Drift

MOC procedures assume the P&IDs are right. At most brownfield facilities, they aren't.

Instrument documentation drifts from as-built conditions at every plant, and it usually drifts silently. The gap between what the P&IDs show and what's actually installed in the field is the single most common source of MOC failures that nobody talks about until an audit or an incident forces the conversation.

Why MOC depends on accurate instrument data

MOC procedures exist because changes to process equipment create risk. OSHA 1910.119 and IEC 61511 both require that documentation reflects the current state of the plant before any modification begins. The logic is straightforward: you can't evaluate the safety impact of adding a new transmitter if you don't know what transmitters are already there.

In practice, MOC reviews need an accurate I/O list to answer basic questions:

• Does the new instrument fit within existing PLC/DCS spare capacity, or do we need additional I/O modules?
• Does removing this flow element affect a SIS interlock downstream?
• Are we duplicating a measurement that already exists on a different loop?
• Will the signal class (AI, AO, DI, DO) of the new device match the available channel type?

When the I/O list is stale, these questions get answered with guesswork. Sometimes the guesswork is fine. Sometimes it results in a turnaround crew showing up to install a 4-20mA transmitter on a channel that was already reallocated to a discrete switch two shutdowns ago.

How I/O lists drift from reality

Documentation doesn't go stale all at once. It happens gradually, through a series of small, individually reasonable decisions.

Turnaround projects. A shutdown happens. Thirty instruments get replaced, five get added, two get decommissioned. The contractor updates the P&IDs in their deliverable package, but the as-built revisions don't make it back into the plant's master document set for six months. Sometimes they never do.

Emergency repairs. A transmitter fails at 2 AM. Operations replaces it with whatever's in the storeroom. The replacement has a different range, maybe a different signal type. Nobody opens a drawing to update it during an emergency callout.

Scope changes during construction. The design says PT-1205 goes on the discharge header. In the field, the fitter puts it on the suction side because the discharge nozzle is already crowded with pipe supports. The drawing never changes.

Incremental control system migrations. Half the plant moves from an old Honeywell TDC to a new DCS. The migrated loops get new tag numbers in the control system but the P&IDs still show the original tags. Now the same instrument has two names depending on which document you're looking at.

Multiple revision streams. Engineering uses one drawing set. Operations has a different copy they've been red-lining for five years. The document control system has a third version. None of them agree.

The redline P&ID problem

Redlining is supposed to be the bridge between as-designed and as-built. A field engineer walks down the unit, marks up the P&IDs with corrections, and those redlines get incorporated into the next formal revision.

In reality, redlines are where instrument data goes to die.

The markup sits in a drawer, a shared drive folder, or taped to a control room wall. It represents real, verified field information, but it's trapped in a format that's invisible to every downstream process. The MOC reviewer checking spare I/O capacity can't search a hand-marked PDF. The SIS verification engineer can't cross-reference redlined tag numbers against the safety requirements specification.

Even when redlines do get incorporated into a formal revision, there's usually a gap. The field walkdown happened in March, the markup sat in a queue until August, the draftsman updated the CAD file in October, and the new revision was issued in December. For nine months, the "official" P&ID was wrong and everyone knew it was wrong but there was no clean version that reflected reality.

The core issue is that redlines are analog patches on what should be a structured data problem. An instrument tag has a tag number, a signal class, a service description, and a location. That's structured information. Scribbling "REPLACED - NOW FT-2401" in red pen next to a bubble doesn't update any of those fields in any system.

Common MOC documentation failures

Failure mode	What happens	Downstream impact
I/O list doesn't reflect field replacements	MOC review uses obsolete signal classes	Wrong I/O module type specified, discovered during commissioning
Decommissioned instruments still on P&ID	New design routes signals through "available" channels that are actually abandoned cable	Wiring crew finds no termination at the marshalling cabinet
Tag numbers changed in DCS but not on P&IDs	SIS verification references tags that don't exist in the logic solver	Audit finding, potential enforcement action
Redline markups not digitized	MOC reviewer works from clean but outdated drawing	Safety impact assessment misses existing instrumentation
Multiple drawing revisions in circulation	Different teams base MOC on different baselines	Conflicting conclusions about spare capacity and interlock impacts
Range or calibration changes not captured	New instrument installed with field-adjusted range	Control loop tuning based on wrong transmitter span
Equipment renumbering after retrofit	Instrument-to-equipment mapping broken	Maintenance PM routes to wrong physical location

Re-baselining instrument data

At some point, the gap between documentation and reality gets wide enough that patching individual drawings isn't practical. You need a re-baseline: a fresh extraction of what's actually on the current revision P&IDs, compared against what the master I/O list says.

The traditional approach is manual. An engineer opens each P&ID page, reads every instrument bubble, types the tag number and signal class into a spreadsheet, and cross-references against the existing I/O list. For a facility with 500 instruments across 40 drawings, this takes one to two weeks of full-time work. For a large refinery unit with 3,000+ instruments, it's a multi-month project.

The reason this doesn't get done more often isn't that people don't see the value. It's that the labor cost is hard to justify until something goes wrong. So documentation drifts further, MOC reviews get less reliable, and the re-baseline eventually happens as a reaction to an incident or audit finding rather than as planned maintenance.

Automated extraction from P&ID drawings cuts the labor side of this equation significantly. Upload the current revision drawings, get back a structured I/O list with tag numbers, signal classes, and service descriptions, and compare it against what's in the document control system. The comparison is where the real value is. Knowing that 47 out of 500 instruments have discrepancies between the drawing and the master list turns a vague "our documentation might be stale" into a specific punch list.

Revision comparison catches what changed

When a new P&ID revision comes in, the question is always the same: what actually changed? The revision block might say "updated per MOC-2024-0847" but that doesn't tell you which instruments were added, removed, or modified.

Comparing two drawing revisions programmatically produces a concrete diff: instrument X was added, instrument Y was removed, instrument Z had its signal class changed from AI to AO. This replaces the manual process of holding two printouts side by side and squinting at tiny ISA bubbles looking for differences. On a complex P&ID with 80+ instruments, that manual comparison takes 30 to 60 minutes per page. Across a 40-page drawing set, you're looking at a week of tedious, error-prone work.

A structured diff also creates an audit trail. Instead of "engineer reviewed revision and found it acceptable," you have a record showing exactly which tags changed between Rev C and Rev D, tied to the MOC number. That's the kind of documentation that holds up during a PSM audit.

Practical steps for keeping documentation current

None of this requires a perfect system. It requires consistent habits around a few key practices:

1. Extract before every MOC. Before starting any Management of Change review, pull a fresh I/O list from the current P&ID revision. Don't work from the list that was built during the last turnaround. Drawings change; your baseline should too.

2. Compare after every revision. When engineering issues a new P&ID revision, run a comparison against the previous version. Don't rely on the revision block summary. Get the actual instrument-level diff and attach it to the MOC file.

3. Close the redline loop. Establish a maximum time between field redline and formal revision incorporation. 90 days is reasonable for most facilities. If redlines older than 90 days exist, they should be escalated, not ignored.

4. Treat the I/O list as a controlled document. The I/O list should have its own revision history, approval workflow, and distribution. It's not a working spreadsheet on someone's desktop. Every change should be traceable to either a P&ID revision or a MOC number.

5. Re-baseline on a schedule. Don't wait for an incident or audit finding. Pick a frequency that matches your modification rate. High-activity units might need annual re-baselining. Stable utilities might be fine every three to five years.

6. Digitize field data immediately. When a field walkdown produces instrument data, it should go into structured form the same week, not three months later when someone finds the marked-up drawings in a filing cabinet.

The goal isn't perfect documentation. Perfect documentation doesn't exist in a plant that's actively running and being modified. The goal is documentation that's close enough to reality that your MOC decisions are based on what's actually installed, not what was installed when the drawings were last formally updated. That's the difference between a MOC process that manages risk and one that just generates paperwork.