What Are PROFINET I&M Records?

Back to Blog

What Each I&M Block Holds

I&M0 is the mandatory read-only identity block. It carries the vendor ID, order or article number, serial number, hardware revision, and firmware revision - the fixed facts a device knows about itself from the factory. Because it is standardized, an asset tool can read I&M0 from any conforming device and get a consistent identity without a vendor-specific driver. This is the block that answers exactly what is installed at this point in the topology.

I&M1 through I&M4 are writable plant-engineering blocks. I&M1 typically holds the tag function and tag location - the plant identifier and where the device sits - so a device can carry its own asset tag. I&M2 holds the installation or commissioning date, I&M3 a free descriptor or comment, and I&M4 a signature used in some safety and change-tracking workflows. Not every device implements all of I&M1 to I&M4, but I&M0 is expected everywhere.

Why I&M Records Matter for Asset Management

The reason I&M matters is that it puts authoritative identity in the device itself rather than in a spreadsheet that drifts out of date. When a documentation or OT asset inventory tool scans a network, reading I&M0 gives it the real order and serial numbers of what is physically installed, and reading I&M1 gives it the plant tag the commissioning engineer wrote. That makes the inventory match reality without manual transcription.

I&M records are read and written through the record-data channel, the same acyclic path used for parameters and on-demand diagnosis, not through cyclic IO. In practice engineers write I&M1 during commissioning so each device announces its own tag, and asset tools re-read it later to verify nothing was swapped without updating documentation. A monitoring platform such as Merobix trends the process tags a controller exposes; it does not itself poll I&M, but the same identity data underpins keeping an accurate device register.

Writing I&M Records During Commissioning

The time to write I&M records is while the commissioning information is still fresh - as each device passes its checks, not as a documentation sweep months later. A workable routine per device:

1. Read I&M0 and confirm the order number and serial against the delivery paperwork and the as-built design.
2. Write the plant tag and location into I&M1 exactly as they appear in the instrument index - same spelling, same delimiters.
3. Write the commissioning date into I&M2 and any loop or panel reference into I&M3.
4. Read the records back to confirm the writes persisted.
5. Export the values into the asset register so the device and the database start life in agreement.

The re-read matters: a write that silently failed to persist is worse than no write, because everyone now trusts a blank.

Agree the tagging convention before the first device is touched. I&M fields are fixed-length, so long free-text tag schemes get truncated; decide up front what goes in tag function versus tag location, and keep it consistent across vendors and subsystems. A convention that matches the instrument index letter for letter makes later automated comparisons trivial, while creative per-technician formats guarantee that any audit script drowns in false mismatches.

I&M Records and Device Replacement

Replacement is where I&M quietly earns its keep. A swapped device usually carries the same order number but always a new serial number, so re-reading I&M0 after maintenance windows catches replacements that never made it into the documentation. The device name itself is assigned over DCP during replacement, and if that step goes wrong the symptom is a device name mismatch rather than an I&M problem - the two failure modes are worth keeping distinct in your head.

What does not happen automatically is the transfer of the writable blocks: a factory-fresh replacement arrives with empty I&M1 through I&M4, and nothing repopulates them unless your procedure says so. Add re-writing the tag, location, and installation date to the standard swap procedure, alongside the name assignment and any parameter download. Periodic audits then become a simple diff: read the installed base, compare against the register, and investigate every serial number and every blank tag field that disagrees.

Modular Devices and Practical Gotchas

On modular remote I/O, identity does not stop at the head station: I&M can be implemented per module and submodule, addressed through the same slot and subslot scheme described in modules, submodules, and slots. That is what lets you distinguish a replaced I/O card from a replaced station - the head's serial number is unchanged while one module's I&M0 shows new hardware. Coverage varies by product, so check the manual for which slots actually expose records.

Two more gotchas from the field. Write access to I&M can be restricted - some devices accept writes only in certain states or from an engineering connection, and hardened configurations may block writes entirely, so test the write path on the bench before promising a fully self-documenting installation. And treat I&M as identity, not as a configuration store: it documents what and where the device is, while parameters, names, and addresses live in their own mechanisms with their own backup and restore paths.

Frequently Asked Questions