How do you make 35,000 engineering drawings speak the same language as your engineering systems?
A large Middle Eastern oil and gas operator held 35,000 PEFS files across AutoCAD, PDF, TIFF, and JPEG formats, with no way to search them by equipment or process element. Azati built an AI-powered pipeline that extracts and classifies data from these drawings, converts them to the DEXPI industry standard via Proteus XML, validates the output, and generates SVG visualizations, turning a static archive into an intelligent, queryable engineering data layer.
PEFS files in the archive, previously unsearchable
estimated reduction in manual work based on pilot results
industry standard adopted for all converted output, enabling downstream system integration
Process Engineering Flow Schemes define how an oil and gas facility works: equipment connections, process flows, safety systems. When 35,000 of these diagrams exist only as AutoCAD drawings, PDFs, TIFF scans, and JPEG images, that knowledge is locked. You cannot search a TIFF. Every question about plant topology becomes a manual review across a 35,000-file archive, and decisions on operations, safety, and facility upgrades get made without the engineering data that should inform them.
Azati built the pipeline to unlock it: extract and classify data from PEFS drawings regardless of format, reconstruct process topology as a graph model, convert to DEXPI, the industry standard for machine-readable P&ID and PEFS data, validate, and generate SVG visualizations. The engagement started as a pilot and moved to full scale after the approach proved out.
PEFS are the logical backbone of the facility, but stored as static files they are invisible to any software system. No tag search, no equipment lookup, no connection tracing, just 35,000 files that had to be opened and reviewed one by one:
PEFS drawings carry meaning in symbols, topology, and geometric relationships, not just text. Symbol detection, geometric relationship analysis, and topology reconstruction are required before any data can be meaningfully extracted:
Producing valid DEXPI output is not a mapping exercise. DEXPI, built on the Proteus XML schema, is an information model that describes how process elements relate to each other within a defined hierarchy. Getting the conversion right required building expertise in the standard from scratch alongside the extraction work:
A 35,000-file archive accumulated over decades contains drawing conventions, symbol variants, and edge cases that no specification document captures in advance. The real requirements emerged from the drawings themselves:
Most AI document tools extract data into proprietary formats that require custom integration work for every downstream system. Azati built DEXPI conversion directly into the pipeline from the start, using pyDEXPI and NetworkX with Pydantic validation, so the output is not just structured data, it is data that engineering platforms, CMMS, and ERP systems can consume immediately without additional transformation.
Extracting symbols from a PEFS drawing is the easy part. Understanding how those symbols connect, what the process relationships are between them, and representing that topology correctly in the DEXPI information model is the hard part. Azati built the geometric relationship analysis and graph modeling layer using Shapely and NetworkX to do exactly that, because a list of symbols without topology is not useful engineering data.
PEFS archives contain decades of drawing conventions. No initial model covers all of them. Azati's approach uses Gradio-based review interfaces to close the loop between extraction output and domain expert feedback quickly, with systematic retraining cycles that improve coverage with every processed batch rather than plateauing early.
This client worked with Azati on other projects before this engagement and chose Azati again specifically for the combination of AI and ML depth, experience handling large unstructured datasets, and an iterative approach that fit the genuinely exploratory nature of the problem.
AutoCAD, PDF, TIFF, or JPEG, Azati can show you what an AI-powered PEFS digitization and DEXPI conversion pipeline looks like for your archive and your downstream systems.
Digitize my engineering drawingsAzati built a multi-stage pipeline that ingests PEFS files in any format, extracts and classifies the engineering data inside them, reconstructs the process topology as a graph model, converts the result to DEXPI, validates it against the schema, and renders a visual output, all in a loop that improves as the volume of processed and annotated drawings grows.
The pipeline handles PEFS files regardless of format. AutoCAD DXF and DWG files are parsed as vector geometry using ezdxf, which preserves the structural precision of the original drawing. PDF, TIFF, and JPEG files are rasterized or processed directly through the computer vision pipeline. A single entry point handles all formats.
Object detection models trained on PEFS symbol libraries identify and classify equipment, instruments, valves, and process elements across each drawing. Datumaro manages the annotation and training data pipeline, PyTorch Lightning powers model training, and models are retrained iteratively as annotated examples from new drawing batches accumulate.
Alongside visual symbol detection, the pipeline extracts text from drawings: equipment tags, instrument codes, line designations, and annotations. Each extracted text element is bound to the graphical symbol it labels, creating the searchable identifiers engineers need to find specific equipment by tag rather than by visual scan.
After extracting individual elements, the pipeline reconstructs the network of connections between them. Shapely handles the geometric relationship analysis, identifying which elements are connected by which lines and in what configuration. NetworkX models the result as a directed graph, producing a machine-readable representation of the process topology that is the core of the DEXPI output.
The process topology graph and extracted element data are converted to DEXPI using pyDEXPI and the Proteus XML schema. Pydantic validation enforces schema compliance at every conversion step, ensuring the output meets the standard's requirements rather than just resembling its structure. The result is a DEXPI file that downstream engineering systems can ingest directly.
For each processed drawing, the pipeline generates an SVG visualization that preserves the original geometry in a web-viewable, scalable format. Engineers review extraction results against the original drawing, with extracted elements overlaid or linked for verification. This review layer feeds back into model retraining, closing the loop between human expertise and automated extraction.
| Area | Azati contribution |
|---|---|
| Multi-format ingestion | Built parsing pipelines for AutoCAD DXF, PDF, TIFF, and JPEG drawings |
| Symbol detection | Trained and deployed object detection models for PEFS symbol classification |
| OCR and tagging | Extracted equipment tags, instrument codes, and bound them to graphical symbols |
| Topology reconstruction | Built graph models of process element connections using Shapely and NetworkX |
| DEXPI conversion | Implemented pyDEXPI-based conversion with Proteus XML schema and Pydantic validation |
| SVG generation | Generated scalable vector visualizations with extraction overlays for human review |
| Iterative delivery | Retrained models and refined extraction as new drawing types emerged |
| Requirements engineering | Translated evolving client needs into technical specifications through close collaboration |
The engagement operates under the client's internal data security policies. Data transfer uses TLS encryption, access is role-based with full activity logging, and all team members work under NDA with authorized access to client systems. The pipeline runs on Oracle Cloud Infrastructure (OCI) in alignment with the client's infrastructure and data residency requirements.
The engagement began as a focused pilot from October 2025 to April 2026, processing a representative subset of the archive and establishing the extraction, topology reconstruction, DEXPI conversion, and validation pipeline. Pilot results showed an estimated 60-80% reduction in manual work and led directly to a full-scale engagement now underway.
The team works in Agile Scrum, with each sprint balancing new drawing type coverage, model retraining, and requirements refinement as the client's downstream integration needs become clearer:
This client had worked with Azati on prior engagements before this project. After a successful pilot, the contract was extended for at least another year, reflecting sustained confidence in both the technical approach and the team.
Engineers and operators who previously had to manually review files to find specific equipment or trace a process connection can now search the archive by tag, element, or process relationship. The documentation that was locked in static files becomes part of how the facility is actually understood and managed.
Pilot results demonstrated that automated extraction, classification, topology reconstruction, and DEXPI conversion can shift the majority of manual processing out of human hands. A specialist reviews and confirms AI output rather than performing the extraction from scratch on every drawing.
Converted files follow the DEXPI standard built on Proteus XML. That means the output is not structured data waiting for an integration project, it is data that engineering platforms, CMMS, ERP systems, and digital twin initiatives can consume directly, compounding the value of every processed drawing.
Every digital twin initiative and predictive maintenance program eventually runs into the same problem: plant topology lives in engineering drawings that no system can read. Making the PEFS archive machine-readable in DEXPI format is the data layer that makes those downstream initiatives actually possible, not a nice-to-have preparation, but the prerequisite.
What this engagement demonstrates beyond the feature list:
Most digital twin programs stall not because the AI is not ready, but because the plant topology data is not ready. PEFS drawings contain the logical DNA of a facility: how every equipment item, valve, instrument, and process line relates to everything else. Converting that to machine-readable DEXPI is the prerequisite step that makes predictive maintenance, safety analysis, and operational AI actually work against real plant structure rather than incomplete manual records.
Many digitization projects produce structured output that sits in a proprietary database and requires custom work to connect to anything downstream. By converting directly to DEXPI via Proteus XML, Azati ensures the extracted data speaks the same language as the engineering systems the client already runs, removing the integration burden from every connection and compounding the value of every processed drawing.
A 35,000-file archive built across decades contains drawing conventions, symbol variants, and edge cases that no specification document captures in advance, and no initial model covers completely. Building systematic retraining into the engagement from the start, tied to human review feedback, is what lets the pipeline keep improving its coverage rather than plateauing at a rate that still leaves too much residual manual work.
Explore our successful projects and see how Azati delivers measurable results for our clients.
A large Middle Eastern oil and gas operator was manually extracting data from technical documents and engineering drawings submitted by contractors, cross-checking it against internal systems, and compiling reports by hand. At scale, this process was slow, resource-intensive, and increasingly error-prone, with no systematic way to prioritize which discrepancies mattered most.
Azati built an AI-powered pipeline combining computer vision and OCR to extract and validate data from engineering documents and AutoCAD drawings, flagging discrepancies against internal system records and delivering verified results directly into the client's existing Knowledge Hub platform, extending it rather than replacing it.
A large chemical enterprise required scalable mechanisms to collect, transform, and deliver trusted analytical data across dozens of interconnected business systems. Growing analytical requirements, a complex data ecosystem with hundreds of flows and thousands of tables, and the need for reliable reporting data created ongoing engineering challenges.
Azati embedded specialists into the client's delivery organization, developing analytical pipelines, data marts, and orchestration workflows using SQL, Python, dbt, Apache Airflow, Apache NiFi, Greenplum, PostgreSQL, and ClickHouse. The engagement focused on continuous platform evolution over 24+ months rather than a one-time implementation.
A large petrochemical operator faced high carrying, maintenance, and disposal costs from unclaimed and duplicate inventory across multiple ERP systems using different coding conventions. The same material was often tracked under different codes, making it impossible to see true inventory levels without manual reconciliation.
Azati ran a seven-year dedicated team engagement building and operating an on-premise inventory management platform with AI-assisted nomenclature normalization across disconnected ERP systems, covering backend development, DevOps, and test automation alongside the core product functionality.
Fragmented calculation workflows for production forecasting and reservoir engineering led to compounding numerical precision errors and slow, unreliable analytical outputs. The existing computational core could not support the accuracy requirements of petroleum engineering analysis at production scale.
Azati rebuilt the modular Python analytics platform replacing fragmented calculation workflows with a precision-engineered computational core, delivering four analytical modules within a four-month window and completing a full computational core redesign that passed UAT on first attempt after ten days.
An oil and gas enterprise needed a construction cost estimation platform capable of handling complex cross-module calculation dependencies across large-scale capital projects. Existing tools could not reliably manage the interdependencies between estimation modules required for accurate project cost modeling.
Azati built an enterprise-grade construction cost estimation platform designed specifically for oil and gas project complexity, with architecture accounting for cross-module calculation dependencies and ensuring that changes in one estimation module propagate correctly across dependent calculations.
Last updated
