Plant Engineering Document and Asset Information Software: Why the Drawing on Your Screen No Longer Matches the Plant

Why plant information decays quietly until it hurts someone

An engineer is planning a tie-in for a small debottlenecking job. He opens the process and instrumentation diagram from the network drive, the file called P-1234_RevC_FINAL_ISSUED_2.pdf, and designs off it. The drawing shows a spec break at a flange that was moved during a 2019 project and a manual valve that was removed in the same job. The isometric goes to fabrication. The spool arrives on site and does not fit. That is three days of a crew and a re-issue, which is annoying and survivable.

The version of this story that is not survivable involves an isolation planned off the same drawing. When a line list, a P and ID and reality disagree, the disagreement eventually finds a person with a spanner. Every owner operator knows this, which is why engineering information management gets funded. It is also why it is so often funded as a scanning project and then quietly abandoned, because scanning produces files and the problem is not files.

Here is the problem in one sentence: you have a document register and you do not have a tag register, and the relationship between the two is the thing everybody actually needs. Ask any operating plant to produce everything known about transmitter PT-2041. The datasheet, the loop drawing, the P and ID it appears on, the hazardous area certificate, the cause and effect matrix entry, the vendor manual, the last calibration record, the spare part number. In most facilities that is a two hour job for a person who has been there fifteen years, and an impossible job for anyone else. The knowledge is in the folder structure and in one head.

Problem 1: revision status lives in the filename

Filename conventions are a compression of state into a string, and they degrade the moment two people are working at once. A folder ends up holding Rev C, Rev C marked up, Rev D draft, and a scan of Rev B with somebody's pen on it. There is no machine readable answer to the only question that matters: which one is current and approved for construction.

What a custom build does: revision becomes a state machine on a document object rather than a substring. Draft, issued for review, issued for construction, as-built, superseded, void. A superseded revision remains accessible because you legally and practically need history, but it is unambiguously marked and it never appears as the default. Transmittals are records, so you can answer who received Rev C and when, which matters more than people expect when a contractor claims they built to what they were given.

Problem 2: handover from projects is a hard drive, not information

An EPC contractor completes a project and hands over tens of thousands of documents near practical completion, at the exact moment your engineering team is busiest and least able to check anything. The specification you wrote said document numbers shall follow the owner convention and required attributes shall be populated. Verifying that by hand across forty thousand files is not possible, so it gets accepted, and the debt is now yours forever.

Industry has answers for this. CFIHOS exists precisely to standardise what information an owner requires from a project, and ISO 15926 provides a data model for plant lifecycle information. They are useful and they are not free: adopting them properly is an organisational commitment, not a software setting.

What a custom build does: make handover a gate rather than an event. The contractor uploads into a staging area and the system validates automatically against your rules. Document number format, required attributes, tag references that must already exist in the register or be accompanied by a new tag record, file format and legibility, and completeness against the deliverables register. Failures come back with a report the contractor can act on, before the retention payment is released. Doing this well changes the economics of every future project, because the contractor knows the check is mechanical.

Problem 3: the redline never comes home

Modifications happen. A change gets approved through management of change, work is executed, and somebody marks up a drawing on site with a red pen because that is what has always worked. The marked up drawing goes back to the engineering office when someone gets around to it. In practice the loop closes on the big jobs and quietly fails on the small ones, which is why the drift is always in the details: a small bore branch, a relocated instrument, a deleted drain.

What a custom build does: bind the as-built obligation to the change record, not to goodwill. A change cannot be closed while affected documents remain in a redline pending state, and the affected documents are known because the change references the tags. Field redlines get captured as annotations on a tablet against the current revision, which removes the transport step where paper is lost. There will still be a queue at the drafting office, because updating a P and ID is real work by a real person. The difference is that the queue is visible and ageing, and the plant manager can see that eleven changes are closed on paper and open in the drawing set.

Problem 4: what the incumbents do well, and who they are built for

Be fair here, because these are serious products. Hexagon SmartPlant Foundation is probably the most complete asset information model on the market and it will do everything discussed above, provided you adopt its class library and staff a team to administer it. AVEVA Asset Information Management is strong, particularly if your engineering toolchain is already AVEVA, and it does the model to document to tag linkage well. Bentley eB is solid document control with mature transmittal and workflow handling. ProArc is lighter and pragmatic on a Microsoft stack and is a genuinely reasonable answer for straightforward document control.

The gap is not capability, it is fit and cost of ownership. The first three assume an owner who will fund an information management function, adopt a standard class library, and reshape internal processes around the tool. Large operators do exactly that and it works. A mid-size owner with two people in engineering information cannot run that, and the adoption effort exceeds the value they would get. ProArc sits comfortably at the document level but does less for tag-centric asset information, which is where the operational questions live.

The other gap, common to all of them, is your CMMS. Your functional location hierarchy in SAP PM or Maximo is where maintenance actually happens, and if the tag register does not reconcile to it you now have two hierarchies to maintain and a permanent reconciliation job.

Problem 5: forty years of drawings are pictures, not information

Your recent documents are vector PDFs with searchable text. Your 1978 drawings are scans, sometimes of microfiche, and to a computer they are pictures. Searching for a tag across that estate returns the modern half. The traditional fix is a data capture contract, where a service provider manually indexes drawings and tags, and the price is per drawing multiplied by a large number.

This is where machine learning earns its place, and it is a genuinely good fit rather than a marketing one. Optical recognition tuned to engineering drawings extracts tag numbers, drawing numbers, revision blocks and title block attributes from raster scans, and a second pass proposes tag to document relationships. It will not be perfect on a 1978 microfiche scan and it does not need to be, because the alternative is not perfection either. Route low confidence extractions to a review queue where a technician confirms in seconds rather than typing from scratch. In our experience this converts a data capture problem that was priced out of reach into one that fits inside the project.

What this costs and how long it takes

A first release with the tag register aligned to your functional locations, the document register with revision states and transmittals, tag to document relationships, and full text and OCR search runs $70,000 to $150,000 in 12 to 18 weeks. A full platform adding handover validation for contractors, the change driven redline and as-built loop, bulk legacy extraction with a review workflow, mobile field access and CMMS synchronisation runs $200,000 to $500,000 over 9 to 15 months.

Cost drivers specific to this category: the size and condition of the legacy scan estate, because a hundred thousand clean vector PDFs and a hundred thousand poor microfiche scans are different projects. Conformance obligations, if a joint venture partner or a regulator requires CFIHOS or ISO 15926 aligned deliverables. CMMS synchronisation, which is straightforward in principle and slow in practice because your functional location hierarchy has grown organically. Three dimensional model integration if you want to click a valve in a laser scan or a design model and get its documents. What keeps cost down: pick one operating unit, load its current documents and tags, and prove the tie-in scenario end to end before you touch the archive.

Build versus buy, honestly

Buy if you are one plant with an orderly file share, a stable process, and no active project pipeline handing you new documents. ProArc or a well configured document management system on the stack you already own will serve, and your money is better spent on a scanning and indexing programme. Buy SmartPlant Foundation or AVEVA if you are a large operator willing to fund an information management team and adopt the vendor's class library, because at that scale their depth is real and rebuilding it would be irrational.

Build when two or more of these are true. You carry more than roughly twenty thousand tags and there is no register that lists them. Your CMMS functional locations and your engineering tags disagree and someone reconciles them manually. You receive project handovers you cannot validate. Your redline loop closes on big jobs and fails on small ones. Or the incumbent products have been quoted to you and the licence plus the administration headcount exceeds what the information is worth to a facility your size, which is a legitimate and common finding.

How to choose a developer for engineering information software

Ask them to draw the model before you sign. You want tag and document as two registers with a many to many relationship between them, plus revision, transmittal, change record and discipline as distinct objects. A developer who draws a folder tree with metadata has built a file manager, and you already have one of those.

Ask what they will do with a raster drawing from 1978. If the answer is that users will index it manually, price that answer, because it is usually larger than the software budget.

Ask how they will reconcile with your CMMS. Which system, which hierarchy is the master, what happens when a tag exists in one and not the other, and who resolves it. A hand wave here becomes a permanent reconciliation job that you will staff forever.

Ask how the redline loop closes and what stops a change record from closing early. If the answer relies on people remembering, the drift you are trying to fix will simply resume with better software watching it.

Ask who owns the code, the repository, the hosting accounts and the exported data format, and get it in the contract before kickoff. At Digital Heroes the client owns all of it from the first commit. Plant information has a lifespan measured in decades and will outlive any development relationship, so the ability to take it somewhere else is not a negotiating point, it is the basic requirement.