What is the difference between a project information model and an asset information model?

The ISO 19650 series uses two terms for the two stages of information management, delivery and operation. A project information model (PIM) is the information produced to design and construct an asset: models, drawings, specifications, schedules, and the records of how they were developed and approved. An asset information model (AIM) is the information needed to manage and operate the asset once it is in use: what is installed and where, how it is maintained, its warranties and certificates, and how it relates to other assets and spaces.

A common misreading is that the AIM is the final PIM under a new name. It is not, and neither term describes a file format. The two serve different purposes, have different owners and change at different speeds. The question that matters is which information should pass from one to the other, who checks it on the way, and who looks after it afterwards.

How they differ

The overlap is smaller than it looks. Much project information has no long-term use, such as construction sequencing models, superseded options and temporary works. Equally, some operational information does not exist until late in the project: serial numbers, commissioning results, as-installed locations. The AIM should never become an indiscriminate archive of everything the project created.

Crossing over is a deliberate act

Guidance on the common data environment (CDE) from the IMI Framework (formerly the UK BIM Framework) describes information passing through states, namely work in progress, shared, published and archived. Its status codes mark information as suitable for PIM authorisation or for AIM authorisation, and published information is authorised by the lead appointed party and then accepted by the appointing party, the client. The move into the AIM is therefore a deliberate acceptance step; nothing crosses automatically.

Nor does an AIM have to begin with a project. ISO 19650-3 covers information management in the operational phase, and its abstract states that it can be applied to all types of assets and by organisations of all types and sizes. For existing assets, an AIM can be built up from surveys and records.

Planning the transition

The transition works best when it is designed backwards from operation. The owner first defines what the AIM must contain, in what format and for which receiving systems. Each requirement is then traced to the party who will produce it during the project, and the stage at which they will do so. Well before completion, a representative exchange is tested by importing a sample into the receiving systems and checking identifiers, classification and document links. Acceptance criteria settle what is accepted, what is outstanding and how outstanding items are tracked. Finally, someone is named as the AIM's owner, responsible for updating it during operation and for connecting changes to maintenance and replacement.

Keeping the AIM alive

An AIM is valuable only while it stays current. Connecting it to the maintenance workflow means replacements and alterations update the record as a matter of course, and a periodic sample audit against the building shows whether that is actually happening.