Validating an I/O list against P&IDs.
Why I/O lists drift from drawings, what discipline keeps validation tractable, and what the MOC change report needs to contain.
The I/O list is a controlled document. The P&ID set is a controlled document. They are supposed to agree. They never quite do.
Validation is the exercise of bringing them back into agreement, finding the deltas, and producing a record of what changed that the operating company can attach to its MOC paperwork.
Why the drift happens
Three sources, in roughly this order of frequency.
Field changes that redlined the P&ID but not the I/O list. Construction discovers an interference, the field engineer marks up the drawing, the redlines get formalized into the next P&ID revision, and nobody updates the I/O list because the I/O list is the controls engineer's document and the controls engineer was on a different job that month. By turnover the two documents disagree on a meaningful fraction of tags.
Tag renames. The owner-operator standard changes, or someone realizes the area-loop-suffix convention has been violated, and a batch of tags gets renamed. The rename propagates to the P&ID via a drawing revision. The I/O list owner gets the email but produces an updated I/O list later. During that gap the documents disagree.
Multiple I/O list copies. The integrator has a copy. The engineering company has a copy. The operating company has a copy. Every copy was the master at some point. Someone designates a controlled copy halfway through the project and the other two stop being updated. By turnover the controlled copy is missing the field changes that landed on the engineering company copy.
Validation is the catch-up exercise. You cannot prevent drift entirely. You can keep the catch-up cycle short.
10-step validation checklist
The following steps apply to any validation cycle, whether the list has 50 tags or 5000.
Step 1. Lock the controlled baselines
Get the latest controlled P&ID set with revision numbers confirmed by document control. Get the latest controlled I/O list with its revision number. If you cannot identify which copy is controlled, stop and resolve that first. Validating against an uncontrolled baseline produces a report that itself cannot be controlled.
Record the P&ID revision and I/O list revision at the top of the validation log before starting any comparison.
Step 2. Extract the drawing-side tag list
Compile every instrument tag visible on the controlled P&ID set. Include every bubble, every off-page connector reference, and every inline instrument. This is the drawing-side baseline.
If the P&ID set is large, a structured extraction from the P&ID PDF produces the drawing-side tag list faster than manual reading and with a lower risk of transcription error. The output is a flat list of tags and their P&ID page references.
Step 3. Count-match before deep comparison
Before tag-by-tag comparison, do a count check. Count the unique tags on the drawing side. Count the unique tags in the I/O list. If the counts match exactly, proceed. If they differ by more than 5%, investigate the cause before running the full comparison. A large count discrepancy usually means one side is not the controlled baseline, or one side includes instruments the other intentionally excludes, such as the I/O list excluding local gauges.
Step 4. Normalize tag formats before comparing
Normalize both lists to the same format before comparing strings. Normalize means. Uppercase, same separator, hyphen, remove leading zeros from suffix numbers, FT-00101 becomes FT-101, strip trailing spaces. A tag-by-tag comparison on un-normalized lists produces false mismatches that cost time to resolve.
Step 5. Run the structured comparison
Build a comparison table with one row per unique tag across both sides. For each row, capture.
| Field | Description |
|---|---|
| Tag number | Normalized |
| In P&ID. | Yes, No |
| In I/O list. | Yes, No |
| Signal class, P&ID | From ISA second-letter inference |
| Signal class, I/O list | From I/O list Signal Class column |
| Description match | Match, Mismatch, N, A |
| Range match | Match, Mismatch, Blank on one side |
| Discrepancy type | See categories below |
Step 6. Categorize every discrepancy
Before investigating any individual case, assign a discrepancy type to each mismatched row. Consistent categorization lets you batch similar cases and prioritize the work.
| Discrepancy type | Description | Common cause |
|---|---|---|
| Drawing-only | Tag on P&ID, absent from I/O list | Local gauge included in I/O list by mistake on P&ID side, or instrument never added to I/O list |
| List-only | Tag in I/O list, absent from P&ID | Instrument removed from scope but not deleted from I/O list. Drawing revision not yet propagated |
| Signal class mismatch | Tag in both, signal class disagrees | Classification error in I/O list. Or P&ID revised instrument type and I/O list not updated |
| Range mismatch | Tag in both, range or units disagrees | Datasheet revision not propagated to I/O list. Units inconsistency, kPa vs PSI |
| Description mismatch | Tag in both, description string differs | Different conventions used in two documents. Not always a real discrepancy |
| Format mismatch | Same instrument, different tag format | Normalization missed a case. FT-00101 vs FT-101 |
| Duplicate | Tag appears more than once in one document | Two instruments assigned the same loop number during parallel design |
Step 7. Investigate signal class mismatches first
Signal class mismatches are the highest-risk discrepancy type because they affect PLC hardware and wiring. A transmitter classified as AO in the I/O list when the P&ID clearly shows it as a measuring element, AI is either a data-entry error or a field configuration that differs from the design intent.
**Worked example. **
The P&ID shows FT-101 as a flow indicating transmitter on line 4"-CS-101-A1A. The I/O list has FT-101 classified as DI.
Investigation. Check the loop folder. The field instrument is a vortex flowmeter with a pulse output, not 4-20mA. The P&ID bubble shows FIT, Flow Indicating Transmitter which conventionally implies a continuous signal, but the actual device produces a digital pulse. The I/O list classification of DI is correct for the installed device. The P&ID should be revised to show FQ, Flow indicating with totalizer or pulse rather than FIT.
Resolution. I/O list is correct. P&ID requires a mark-up to reflect the actual installation. Engineering change notice raised against PID-001 Rev C to change FT-101 to FQ-101.
This is the typical resolution path. One of the two documents is right, the other needs to follow.
Step 8. Check for BPCS, SIS separation
Verify that every tag flagged as SIS in the I/O list does not appear in the BPCS section, and vice versa. A tag that appears in both sections without a deliberate reason, such as a voting transmitter used in both systems is a separation violation that will be flagged by a functional safety audit.
Also verify that SIS-flagged instruments have signal classes consistent with their SIS function. LSH-405, high-high level switch, SIS should be DI. If it is listed as AI, the instrument design must be confirmed. Is it a switch, discrete contact output or a transmitter used in a voting configuration.
Step 9. Check for orphaned control loops
An orphaned loop is one that has a final element, AO or DO but no corresponding measurement, AI or DI, or vice versa. Filter the I/O list for AO rows and cross-check each against the same loop number for an AI row.
| AO tag | Loop | Expected AI tag | AI present. |
|---|---|---|---|
| LCV-405 | 405 | LT-405 | Yes |
| FCV-101 | 101 | FT-101 | Yes |
| TCV-203 | 203 | TT-203 | No, missing |
TT-203 is absent from the I/O list. Check the P&ID. If TT-203 appears on the drawing, it was omitted from the I/O list. If it does not appear, TCV-203 may be a manually operated valve without an automatic controller, and the signal class should be DO, not AO.
Step 10. Produce the change report
Once all discrepancies have been investigated and resolved, compile the change report. The I/O list creation guide describes the column structure and controlled-document conventions that make this step faster when the I/O list was built properly from the start. Every changed row carries.
- Tag number
- Discrepancy type
- Before value, from the document that was wrong
- After value, the correct value
- Source authority, which document or field evidence confirmed the correct value
- Engineer name and date
- Action required, P&ID revision, I/O list update, or both
This report is the engineering input for the MOC package. The MOC owner adds ownership, hazard review, and sign-off. The validation team's job is to produce a complete, sourced, and dated discrepancy list.
Common gotchas
Tag-numbering format inconsistencies. FT-101 on the P&ID, FT-00101 on the I/O list. Same instrument, different format. Comparison tooling should normalize before comparing. Manual comparison has to do it in your head.
Service descriptions that do not match equipment labels. "Reactor 1 jacket inlet temperature" on the I/O list, "R-101 jacket coolant inlet" on the P&ID. Same loop. Disagreement if you compare strings literally. Fine if you compare normalized concepts.
Signal class disagreements between I/O list and second-letter convention. The P&ID has FT-101, transmitter, AI per ISA 5.1 and the I/O list has it as DI. Either the I/O list is wrong or the field instrument is actually a switch, FS-101 that got mislabeled on the drawing. Check the calibration record to settle it.
Future tags that were never built. The I/O list shows them as scope. The P&ID never carried them. Nobody ever installed them. The I/O list owner intended to delete them after construction and forgot. Common to find batches of these on plants past commissioning.
Duplicate tags in the I/O list that do not appear as duplicates on the P&ID. Two engineers working on adjacent process sections each added the same tag independently. The P&ID has one bubble. The I/O list has two rows. The comparison shows the tag as present on both sides, but the duplicate row in the I/O list means one channel will be unconnected in the PLC.
If you run this exercise regularly, automation pays the rent. Upload an existing I/O list and the current P&ID set and the comparison output drops directly into Excel. Triage still needs engineering judgment.
The output at the end is the MOC change report. That is the document the operating company files. The validation procedure exists to produce it cleanly. On projects that require handover of structured P&ID data alongside the I/O list, DEXPI schema explained covers the vendor-neutral exchange format that carries the instrument data for digital twin and asset-information handovers.
FAQ
How often should an I/O list be validated against the P&IDs during a project.
At every controlled P&ID revision during detailed engineering, typically every 4 to 6 weeks on an active project. At the IFC, issued for construction milestone. After construction is complete before commissioning begins. After any scope change or MOC during operations. The cost of validation increases as the project progresses. Catching discrepancies in detailed design is far cheaper than catching them during loop checks.
What happens if the I/O list and the P&ID both have errors.
Both documents get corrected, and both correction events are recorded in the change report. The validation is not a judgment about which document is the "right" master. It is a process of finding what is true about the plant and making both documents reflect that truth. When the installed field instrument disagrees with both documents, the field instrument and the calibration record are the ground truth, and both documents require revision.
Can the validation be done by someone other than the I&C engineer.
Someone other than the originating engineer can run the comparison mechanics, building the comparison table, categorizing discrepancies. The resolution of each discrepancy requires engineering judgment. Knowing what a PSL should be classified as, knowing whether a range of 0-1600 kPa makes sense for a separator operating at 5500 kPa design. The resolution step should involve a qualified I&C engineer. The comparison mechanics can be delegated.
What is the minimum acceptable documentation for each resolved discrepancy.
The tag number, the discrepancy type, the before and after values, the name of the engineer who resolved it, the date, and the source authority, loop folder, calibration record, field walk, vendor datasheet. One-line descriptions such as "checked and OK" are not acceptable for MOC purposes. The source authority must be traceable. If the resolution came from a field walk, note the date of the walk and the name of the person who performed it.
How do I handle tags that appear on the P&ID but are explicitly out of scope for the I/O list.
Create a separate column in the validation table for "exclusion reason" and record the reason each drawing-only tag is legitimately absent from the I/O list. Acceptable reasons include. Local-only instrument, no wired signal, instrument in a different contract scope, instrument on vendor package that maintains its own I/O list. Undocumented exclusions are indistinguishable from omissions during an audit.