Brownfield engineering documentation. A survival guide
An MOC package built against a drawing that has not been updated since 2009 is not a management of change document. It is a record of what the drawing said. When that difference surfaces during a HAZOP or a regulator audit, the project team has to reconstruct twelve years of undocumented modifications from field markups, commissioning reports, and memory. That reconstruction is the brownfield documentation problem, and it starts with the drawings.
Read one of your own drawings.
Drop a P&ID, instrument index, or schedule. Tagsight reads it to the tag and opens a workspace you keep when you sign in.
PDF · DWG · DXF · TIFF · PNG · XLSX
What makes a project brownfield.
A brownfield project runs on an existing facility. The plant was built ten or forty years ago, has been modified through a succession of small projects and a couple of large ones, and is currently operating. Any change you make has to fit alongside what is already there, including the parts of what is already there that nobody documented properly.
The defining brownfield problem is documentation drift. The drawings are old. The drawings have been revised, but the revisions did not always make it back to the central document control. The plant has been modified in the field without drawing updates. The original engineering company is dissolved, merged, or has lost the source files. The instrument list exists, but it disagrees with the P&IDs in 8 percent of rows.
Greenfield projects start from a blank page and the engineering documents converge as the project advances. Brownfield projects start from a non-blank page, and the documents have to navigate around what is already there. The data-extraction problem is bigger and the validation problem is bigger.
What the documentation usually looks like.
Expect five categories of source material on a typical brownfield job.
Original CAD files. Rare. Most plants over fifteen years old have lost the original DWG, DGN files, or the files exist but the layer structure no longer makes sense.
Vector PDFs from CAD. Common for projects executed in the last decade. These are clean to work with.
Scanned PDFs. Common for the original 1980s-1990s drawings. Quality varies wildly. Some are clean 600 DPI scans done as part of a previous digitization initiative. Others are 200 DPI scans of photocopies of the originals.
Microfilm or scanned microfilm. Rare but real. Quality is poor. Tag readability is sometimes possible, often not.
Field markup copies. Hand-marked drawings showing as-built modifications. The annotations are gold. The annotations are also incomplete and contradictory.
A brownfield digitization pass usually has to ingest at least three of these categories on the same project. The ability to handle scanned PDFs without losing the operating company's tag convention is what separates a useful tool from a demo.
Scoping the job before you start.
The first hour of a brownfield project is spent triaging the documentation. How many drawings are there. What format. What revision. Are there overlapping revisions of the same drawing in different folders. Is the instrument index from 2014 still believed to be current.
The goal of triage is not to clean up the documentation. The goal is to know what you have so you can build a defensible scope. A 75-page set of vector PDFs at known revision E is a different job from a 75-page set where 40 are revision unknown scanned 1990s drawings, 25 are field markup copies, and 10 are vendor packages with no consistent tag convention.
Underscoping a brownfield job is the dominant project failure mode. The sales engineer scopes against the clean half of the documentation. The execution engineer discovers the messy half three weeks in. The schedule slides and the customer is unhappy. A defensible scope makes explicit which drawings are included, what their format is, and what is being delivered against each.
As-built vs document-of-record.
A subtle distinction with large consequences. The document-of-record is the latest revision of the drawing in the central document management system. The as-built is the actual physical configuration of the plant. They are sometimes the same, frequently not.
When the plant has been modified in the field without a drawing revision, the document-of-record and the as-built diverge. The instrument index built off the document-of-record will be wrong in the rows where the field has moved on. A digitization pass off the document-of-record will faithfully reproduce a wrong document.
The right convention is to mark every output document with the source. 'Instrument list, generated from drawing set rev E, document control as of 2024-03-15. Field validation not performed.' This sets expectations. The output is true to the drawings. Whether the drawings are true to the plant is a separate question, addressed by field validation if the project requires it.
Tag archaeology.
On a 30-year-old plant, the tag convention has usually evolved. The 1990s area uses one convention, the 2005 expansion uses another, and the 2018 modernization introduced a third. All three are still active.
A digitization workflow has to detect the convention per drawing or per area, then extract within that convention. Forcing every tag through one filter, usually ISA 5.1 loses the tags that do not match. The lost tags become RFIs in construction.
Duplicate tags across areas are a common archaeological finding. The 1990s area has FIT-101 on the feed line. The 2005 expansion also has FIT-101 on a totally different feed line. Both are still in service, and the operations team distinguishes them by area code or by drawing number. A digitization pass needs to surface this duplication, not silently merge or drop it.
In-house letter sets are the third archaeological finding. A 1980s petrochemical plant might use B for level, instead of L because the original engineering company's standard predated the convergence on ISA. The tags are valid, the standard is not in any published reference, and the only people who know what B means are the operating engineers. The extraction tool has to extract these tags as the operator wrote them, not silently rewrite them as L tags.
Field validation, when and how.
Field validation is walking the plant and confirming the drawings against the physical configuration. It is the most expensive activity in a brownfield project and the only activity that closes the as-built versus document-of-record gap.
Not every brownfield project needs field validation. A controls upgrade that replaces the PLC but reuses the existing field instruments needs minimal validation. A revamp that replaces field instruments needs heavy validation. A safety study, HAZOP, LOPA, SIL needs validation against any tag that contributes to a safeguard.
The digitization output is the input to field validation. A field engineer with an instrument list, an equipment list, and a marked-up P&ID can walk a unit in a day and confirm the existence and tag of each device. The findings come back as a redline against the digitized data. Closing those redlines is the as-built record.
Without digitization, field validation is a list-build exercise. The engineer walks the plant with a clipboard, writes down what they see, and types it into a spreadsheet later. With digitization, validation is a confirmation exercise. The two activities are not the same effort and not the same cost.
MOC discipline on legacy plants.
Management of change on a brownfield plant has to track three things. What was, what is, and what changed. The three are not always the same as the three drawings, rev D, rev E, rev F because of the as-built drift discussed above.
A workable MOC package contains. The previous revision of the affected drawings, the new revision, a diff table at the tag level, added, removed, modified, the redlines from any field validation, and the engineering and safety review sign-offs.
The diff at the tag level is the artifact that ages best. Three years later, an investigator asking 'why did this PSV get added' can read the diff, see that it was added between rev D and rev E, and trace to the HAZOP recommendation that drove it. Without the diff, the investigator has to compare the two drawings page by page.
For regulated facilities, pharma, life sciences, anything under PSM the diff is a regulatory artifact. For non-regulated facilities it is just good practice that pays back the second time you need to know why something is the way it is.
Documents that survive a turnover.
A brownfield project hands over to operations at the end. The package that survives is the package that operations can use without the engineering team being on call.
Minimum. Instrument index in Excel, equipment list, line list, current revision of the P&IDs, vector and printable, MOC documents per change, and the field validation redlines. Helpful but optional. Connectivity graph in DEXPI for whoever has a plant data system, the integrity report from the digitization pass, and the loop diagrams refreshed against the current revisions.
The package that does not survive is the package that depends on a vendor login, a proprietary file format that operations does not have a license for, or an engineer's personal computer. Hand over the data, hand over the format keys, and assume the operations team will not call the engineering office in the third year.
Version-stamp everything. Three years from now, the next project team will dig out the package, check the version stamps, and decide what is still trustworthy. A package without version stamps is a package that gets thrown out and redone from scratch.
Downloads.
FAQ.
What is the first thing I should do on a brownfield project.
Triage the documentation. Catalog every drawing, its format, its revision, and its provenance. The triage tells you the scope. Skipping triage is the dominant cause of brownfield project overruns.
How do I handle drawings whose revision is unknown.
Treat them as the latest available, mark them as 'revision unknown' in the output, and flag them for the customer to confirm against their document control system. If the customer has lost track, the drawing is what it is. The output inherits the same uncertainty.
What if the instrument list and the P&IDs disagree.
The P&IDs are the source. Re-extract from the drawings and ship the result. Differences from the legacy instrument list are findings worth reviewing, not errors. Sometimes the legacy list is correct and the drawing is stale. Field validation closes the gap.
How do I price a scanned-drawing digitization.
Per page, with a multiplier for scan quality. A clean vector PDF is one unit. A clean 600 DPI scan is roughly 1.5 units. A 200 DPI photocopy of a photocopy is 2 to 3 units. The multipliers cover review effort more than extraction time.
Can the operating company's in-house tag standard be used.
Yes. Detect the convention per drawing or per area and extract within it. The output comes back in the operating company's convention, not forcibly converted to ISA. Mixed conventions across a single drawing set work.
How do I handle field markup copies.
Treat the markups as redlines against the formal revision. The formal revision is the source for the digitization pass. The markups are validation findings to be incorporated when the next formal revision is issued.
Do I need to digitize every drawing in the set.
Only the drawings in scope. A 200-drawing facility has the unit P&IDs, the utilities, the off-sites, the loop diagrams, the SLDs, the cause-and-effect, and the wiring. A controls upgrade scope might be the unit P&IDs plus the loop diagrams. Scope discipline saves real money.
What is the difference between as-built and document-of-record.
Document-of-record is the latest revision in document control. As-built is the physical configuration of the plant. They diverge when modifications happen in the field without drawing updates. Field validation is what closes the gap. Without it, extracted documents are true to the drawings, not necessarily to the plant.
How do I deliver an MOC package the regulator will accept.
Include both revisions of every affected drawing, a tag-level diff, the engineering and safety review records, and the field validation redlines if applicable. Version-stamp every artifact. Sign-offs are typically PE-stamped or equivalent depending on the regulator.
What about vendor package PLCs in legacy plants.
Vendor packages often have their own internal I/O list maintained by the vendor. The plant-side I/O list usually shows only the hardwired tags that hand up to the main control system, plus a reference to the vendor PLC for the internal I/O. Mirror this convention in the output to avoid double-counting.
Can microfilm scans be digitized.
Sometimes. Microfilm scanned at 600 DPI or higher with good contrast can be extracted, but the review-flag rate is high and tag confidence is lower. For tags below the OCR threshold, manual review is the only path. Set expectations accordingly.
How do I version-stamp the output documents.
Stamp each artifact with. Source drawing set name, source revision, extraction date, software version, and reviewer initials. Embed the stamp in the file itself, a footer in Excel, metadata in PDF rather than relying on the file name. Three years on, the file name will be the only thing left and you want the provenance to come with it.