A P&ID tag and a CMMS asset record describe the same physical device from two different disciplines, and the handover between them is where most maintenance data quality problems start. Building a clean Maximo or SAP PM asset register from a P&ID means translating each instrument and valve tag into a functional location, an equipment record, and a set of classification attributes the CMMS can actually use for planning, spares, and work history. Done well, this happens once, during commissioning data handover, not repeatedly through years of maintenance tickets that reference a device nobody can find in the system.
Why the P&ID tag is not a CMMS asset number
An ISA 5.1 style tag such as PT-101 tells a process engineer three things: the measured or controlled variable (pressure), the function (transmitter), and a loop number that ties it to a control loop on the drawing. It says nothing about where the device physically sits in a plant hierarchy, what its maintenance strategy is, what spare parts fit it, or who is responsible for it. A CMMS does not organize the world by loop. It organizes by functional location (a fixed position in the plant hierarchy, independent of the device installed there) and by equipment record (the physical asset, which can be removed, replaced, or repaired without changing the functional location).
This is the core translation job: PT-101 on the P&ID becomes a functional location like AREA10-COMP-A-PT101 or 10-PT-101 depending on the site's numbering convention, and the physical transmitter installed there becomes an equipment record with its own serial number, manufacturer, model, and calibration history. If the transmitter is swapped out for a replacement unit, the functional location stays the same and a new equipment record is linked to it. Sites that skip this distinction end up with asset numbers that are really just P&ID tags, which breaks the moment a device is replaced or a loop is renumbered on a later revision.
Tag to functional location: the mapping decisions that matter
Before any tags leave the P&ID, someone has to decide the functional location numbering scheme, because the CMMS structure will outlive several generations of drawings. The decisions that matter most:
- Hierarchy depth. Plant, area, unit, system, and loop, or a flatter structure. A refinery with dozens of units needs deep hierarchy; a single packaged skid usually doesn't.
- Numbering source. Some sites carry the ISA loop number straight into the functional location (cleanest, but only works if tag numbers are unique plant-wide). Others assign a separate CMMS-native number and cross-reference the P&ID tag as an attribute. Cross-referencing is more resilient to future P&ID renumbering but adds a lookup step for technicians.
- Multi-tag loops. A single control loop can include a transmitter, a controller function, and a final control element (PT-101, and the valve it operates, FCV-302, tied together on the same loop). Each physical device gets its own functional location and equipment record even though they share a loop number on the drawing.
- Non-instrument tags. Valves (XV-301), relief devices, and rotating equipment on the P&ID follow the same translation, and most CMMS asset registers actually contain more valve and mechanical equipment records than instrument records.
The mapping table below is the single most useful artifact in this phase, and it should exist as its own spreadsheet or database table before anyone starts creating records in the CMMS, not as tribal knowledge in someone's head.
What Maximo and SAP PM expect at minimum
The two dominant enterprise CMMS platforms use different vocabulary for the same underlying structure. Getting the terminology straight avoids a lot of confused handover meetings between the instrumentation team and the reliability team.
| Concept | P&ID / ISA terminology | IBM Maximo | SAP PM (S/4HANA Asset Management) |
|---|---|---|---|
| Fixed position in the plant hierarchy | Loop / tag location on the drawing | Location (hierarchical, parent-child) | Functional Location (structured code, e.g. PLANT-AREA-UNIT-DEVICE) |
| Physical device that can be swapped | Instrument or valve body | Asset (linked to a Location) | Equipment (linked to a Functional Location, has its own master record) |
| Grouping devices by type for reporting and specs | Signal type / device category on the legend | Classification + Attributes (Ka specs) | Class + Characteristics (via classification system CL20N or object type) |
| Where calibration, PM plans, and work orders attach | Not on the P&ID | Asset or Location, depending on site config | Equipment master record (preferred, per PM best practice) |
| Spare part cross-reference | Manufacturer cut sheet, separate from the drawing | Item Master linked to Asset | Material Master linked to Equipment (bill of material, BOM) |
The practical implication: every instrument and control valve on the P&ID needs, at minimum, a functional location code, an equipment record if the physical device is known at handover, and a classification that lets the CMMS group it with every other pressure transmitter or control valve in the plant for reporting and spares standardization.
Classes, attributes, and specifications
This is where most handovers lose data even when the functional location structure is sound. A CMMS classification for "pressure transmitter" or "control valve" carries a defined set of attributes, and those attributes have to come from somewhere concrete: the instrument index, the specification sheet, or the manufacturer's data sheet, never guessed at data entry time.
For a transmitter like PT-101, the attributes a maintenance planner needs typically include: measured variable, range, output signal type, process connection size and rating, wetted material, hazardous area certification, and manufacturer part number. For a control valve like FCV-302: body size and rating, actuator type, fail action (fail open, fail closed, fail last), positioner type, and seat leakage class. None of this lives on the P&ID itself. The P&ID gives you the tag, the service, and the loop context. The instrument index and the specification sheets give you everything the CMMS attribute fields actually need filled in.
A safety instrumented function tag such as SIF-101 carries an additional handover requirement: the CMMS record needs to reflect that this device sits inside a safety loop, because SIF and SIL-rated devices usually have a mandated proof-test interval and a documented test procedure that has to attach to the equipment record, not float in a separate safety file that maintenance never sees.
The instrument index as the handover document
The instrument index (sometimes an I/O list, sometimes a standalone spreadsheet) is the practical bridge between the P&ID and the CMMS, because it is already organized by tag with columns for service, range, signal type, and loop association. The columns a well-built instrument index needs to carry, specifically to support a clean CMMS load, are:
| Instrument index column | Feeds this CMMS field |
|---|---|
| Tag number | Cross-reference on the equipment record |
| Functional location (if assigned pre-handover) | Functional Location / Location code |
| Service description | Equipment description |
| Manufacturer and model | Equipment master, manufacturer/model fields |
| Range and units | Classification attribute |
| Signal type (analog, discrete) | Classification attribute |
| P&ID drawing number and revision | Linked document reference |
| SIL or safety classification, if applicable | Safety-critical flag, proof-test PM trigger |
A P&ID review that produces this index directly, rather than as a separate manual transcription pass after the drawing is issued, removes one of the most common sources of tag mismatches between engineering documents and the maintenance system.
Where handovers usually break down
Three failure patterns show up repeatedly on brownfield and greenfield projects alike. First, tag renumbering between issued-for-construction and as-built drawings that never gets reconciled against the CMMS, so the maintenance system references a tag that no longer exists on the current P&ID. Second, instrument index columns that get filled in loosely at handover ("TBD" in the manufacturer field) and never get revisited once the plant is operating, leaving classification attributes permanently blank. Third, valves and instruments that appear on the P&ID but were never assigned a functional location because they weren't considered "critical" at the time, which then surface as unplanned, undocumented assets the first time they fail.
The fix for all three is the same discipline: treat the instrument index as a controlled document that gets revised alongside the P&ID, and treat the CMMS load as a data migration project with a defined source of truth, not a one-time import that nobody owns afterward.
Further reading
- /learn/isa-5-1-tag-numbering
- /blog/instrument-index-vs-io-list
- /solutions/pid-review-and-instrument-index
- /industries/oil-and-gas-instrumentation