How do you train one AI pipeline to recognize instruments and equipment across four completely different kinds of engineering drawings?
A refining and petrochemical operator was extracting equipment tags and attributes from engineering drawings by hand, across four structurally different document types: P&ID, fire and gas loop diagrams, HVAC schematics, and electrical one-line diagrams. Azati built a computer vision and OCR pipeline that detects objects, matches tags, classifies equipment, and extracts attributes automatically, packaging the result for direct upload into the client's engineering data platform.
structurally different drawing types recognized by one pipeline: P&ID, fire and gas, HVAC, electrical
months from first annotation task to a working production pipeline
team spanning development and data annotation
Four kinds of drawings, one document archive, zero shared logic between them. P&ID sheets show piping, valves, sensors, and pumps. Fire and gas diagrams trace how detectors, buttons, and sirens wire back to junction boxes. HVAC schematics map ductwork, dampers, and control panels. Electrical one-line diagrams lay out unit-level power distribution. An operator running a refining and petrochemical facility had all four types accumulating for years, and every equipment tag, every attribute, every connection inside them existed only on paper or scanned PDF, read one drawing at a time by an engineer.
Azati built the system that reads them instead: detects the objects, matches the tags that label them, classifies what they are, pulls their attributes, and packages the result for upload into the client's engineering data platform, across all four drawing types, in one pipeline.
A model trained on P&ID valves and instrumentation has nothing useful to say about a fire and gas loop diagram or an electrical one-line schematic. Each document type has its own conventions, its own tagging logic, its own layout rules:
A single equipment symbol can occupy a tiny fraction of a full-page engineering drawing, and standard object detection models lose accuracy fast at that scale. Detecting a valve, an instrument, or a junction box reliably meant treating small-object detection as a first-class problem, not an edge case:
Engineering tags show up handwritten, rotated, curved along a pipe run, or stamped in inconsistent fonts. Conventional OCR, built for clean printed pages, misreads or drops them outright:
Some equipment symbols look nearly identical but represent completely different components. Other object classes appear so rarely across the archive that the model barely sees enough examples to learn them. And a meaningful share of the source PDFs were simply low quality:
Most engineering document AI projects handle one drawing type well and stop there. This system had to work across four incompatible symbol libraries and tagging conventions inside a single production pipeline, not as four separate tools stitched together after the fact.
The models behind this pipeline, YOLO, SAHI, TextBPN++, TrOCR, PARSeq, aren't exotic choices picked for one engagement. They reflect a team that treats computer vision and OCR as a discipline, matching the right architecture to the actual failure mode rather than reaching for a generic off-the-shelf model and hoping it holds.
Classifying against ISA reference standards and internal catalogs, rather than trusting the model's visual best guess alone, is what let the pipeline correctly separate symbols that look nearly identical but represent different equipment. Visual confidence and engineering correctness aren't the same thing, and the pipeline was built to check both.
Tight multi-day turnarounds, rare object classes at real risk of being missed, PDFs of inconsistent quality. The team built and tuned the pipeline against the actual conditions annotation specialists worked under, not an idealized dataset.
P&ID, fire and gas, HVAC, electrical, or something else entirely, Azati has built the object detection and classification pipeline to make all of it machine-readable. Let's talk about your archive.
Digitize my drawing archiveNine stages, one continuous flow: a PDF goes in, a structured, upload-ready export comes out, and an engineer never has to manually transcribe a tag again.
Uploaded PDFs are converted page by page into high-resolution images, the format every downstream detection and recognition model in the pipeline actually works against.
This is where the drawing gets read for the first time: text pulled off the page, symbols located regardless of size, and every tag identified as a distinct object rather than noise on a busy sheet.
Text and symbols found in the previous stage now get connected and resolved: which tag belongs to which object, and what that object actually is once checked against engineering reference data rather than appearance alone.
Once an object is classified, the pipeline extracts its engineering attributes, runs final validation and preprocessing, and packages the complete result into a structured export formatted for direct upload into the client's engineering data platform.
| Area | What was delivered |
|---|---|
| Object detection | YOLO and SAHI-based detection tuned for small symbols on dense drawings |
| Text recognition | TextBPN++, TrOCR, and PARSeq for handwritten and irregular engineering tags |
| Classification | ML models cross-referenced against ISA standards and reference catalogs |
| Attribute extraction | Automated attribute assignment per classified object |
| Multi-document support | One pipeline covering P&ID, fire and gas, HVAC, and electrical drawings |
| Data annotation | CVAT-based annotation across roughly seven task batches |
| Output packaging | Structured export ready for direct platform upload |
The engagement runs entirely on dedicated servers within isolated infrastructure, with access restricted to the project team. Source drawings, annotation data, and trained models never leave that controlled environment.
A dedicated team combining engineering, model development, and hands-on annotation, small enough to move fast, structured enough to handle four drawing types in parallel.
Instead of separate manual processes for P&ID, fire and gas, HVAC, and electrical drawings, one pipeline now handles all four under a shared architecture, without four separate teams or four separate tools to maintain.
Equipment that used to require an engineer reading a drawing and typing values into a system now gets detected, classified, and attributed automatically, with an engineer reviewing structured output instead of producing it from scratch.
Long-tail equipment classes and tiny symbols that a generic detector would routinely miss are now caught reliably, closing exactly the gap that made this project hard in the first place.
The final export packages directly for upload into the client's engineering data platform, so the pipeline's result becomes working engineering data immediately, not a file that still needs manual reformatting before anyone can use it.
What this engagement demonstrates:
There is no such thing as a model that "understands engineering drawings" in the abstract. There are models trained for P&ID conventions, models trained for electrical notation, and so on. Real multi-document coverage comes from building for each convention deliberately, not from hoping one architecture generalizes across all of them.
Reading clean, large, well-printed text on a well-scanned drawing was never the problem. The problem, and the value, was in the small symbols, the handwritten tags, and the rare equipment classes that generic tools skip past. That's the 20% worth building custom architecture for.
A pipeline is only as good as the data it learns from, and that data came out of real annotation work under real time pressure. Designing the pipeline with that constraint in mind, rather than assuming a clean, idealized dataset, is what kept accuracy holding up in production.
Piping isometric digitization: 250,000+ engineering drawings reconciled into a unified flange register, 70% faster project schedules, 50% less manual effort, delivered over 12 months.
Engineering drawing tag extraction: multi-level visual context classification, equipment connection detection, and AVEVA table generation at 300 documents per hour, delivered in 3 months.
PEFS digitization for oil and gas: 35,000 engineering drawings converted to searchable, DEXPI-compliant data with an estimated 60-80% reduction in manual processing work.
AI document processing for oil and gas: ~100,000 technical documents processed, with an estimated 50-70% cut in manual review effort for standard document packages.
Enterprise data platform modernization: analytical pipelines, data marts, and orchestration workflows across hundreds of flows and thousands of structures, delivered over a 24+ month embedded engagement.
Petrochemical inventory platform: 7-year dedicated team covering development, AI-assisted nomenclature matching, on-premise DevOps, and test automation, addressing high costs from unclaimed stock.
Last updated
