Skip to main content

FlowSync · Model Builder · Hydraulic Model Building

Build the model from the documents you already have.

Model Builder reads your P&IDs, datasheets, as-builts and GIS the way an engineer reads them, traces the flowpaths, populates the equipment specs, and produces one verified model of the asset. On a deployment account, hydraulic model builds went from weeks of manual effort to minutes of verification, across 2,000+ miles of pipeline modeled.

For Engineering Managers · Pipeline and Facilities Engineers · GIS and Asset Data Teams

Marked-up P&ID sheets on a desk, the engineering documents a hydraulic model is built from
The documents the model is built from.
Weeks → minutes
Hydraulic model build to verification, deployment account
2,000+
Miles of pipeline modeled, deployment account
1
Model, read by every FlowSync module and the simulator you run
4 wk
Pilot on one system, standard rollout cadence

Part of FlowSyncYou buy FlowSync from WorkSync. Model Builder is the model building capability of FlowSync, and it ships with the platform.

What Model Builder is

The model build, done from the documents you already keep.

A hydraulic or process model is mostly transcription: someone reads a stack of drawings and retypes equipment, lengths, diameters and specs into a simulator. Model Builder does that reading, and leaves the engineer the judgement.

Today the model of your asset is spread across redlined P&IDs, alignment sheets, vendor folders, a GIS layer and a few databases that disagree with each other. Every study starts by assembling that picture again, and the version the last study used is gone. That is why a model is usually either expensive or stale, and often both.

Model Builder inverts the order. The documents are the source of truth, the model is derived from them, and the derivation is repeatable. On the deployment account behind the automated model-build white paper, hydraulic model builds went from weeks of manual effort to minutes of verification, across 2,000+ miles of pipeline modeled.

  • Drawings
    P&IDs and isometrics

    Equipment, tags, line numbers, valves and the connectivity between them.

  • Specifications
    Datasheets and cutsheets

    Curves, ratings, sizes and materials, read off the vendor document rather than retyped.

  • Geometry
    GIS and alignment sheets

    Centerlines, diameters, wall thickness, lengths and elevation profile, read live.

  • Change history
    As-builts and MOCs

    What was actually installed, and every approved change since the drawing was issued.

  • Operating data
    Historian and SCADA

    Pressures, flows and temperatures through DataHub, so the model can be checked against the asset it represents.

One verified model
The asset as it is today, every value traceable to its source document

What it does

6 capabilities that turn your existing stack into action.

  1. 01

    Reads the drawings the way an engineer reads them

    P&IDs, isometrics, alignment sheets, datasheets, vendor cutsheets and as-builts go in as the PDFs they already are. Equipment is identified, tags are lifted, flowpaths are traced and line specs are populated, with the source page recorded against every value.
  2. 02

    Pulls topology straight from GIS

    Centerlines, diameters, wall thickness, lengths, elevations and connectivity read live from your GIS. No shapefile export, no manual takeoff, and no exported copy that went stale between the export and the study.
  3. 03

    Reconciles the sources against each other

    The drawing, the GIS layer, the as-built and the historian disagree more often than anyone admits. Every disagreement is flagged with both values and both sources, so an engineer rules on it up front instead of discovering it mid-study.
  4. 04

    Verification instead of transcription

    Confidence is carried per item. Anything the extraction is unsure of is routed to a person rather than guessed, and the build ends in an engineer approving a model rather than rebuilding one.
  5. 05

    Stays current as the asset changes

    New as-builts, approved MOCs and field redlines are re-read as they land. The model tracks the asset instead of drifting from it between projects, which is what keeps the next study from starting with a rebuild.
  6. 06

    Corrections flow back to the system of record

    When the model corrects a tag, a spec or a connection, the fix is pushed back to GIS and the systems of record that own it. The loop closes, and the next engineer to open the drawing sees the corrected value.

How it works

Four steps, and the last one is a review.

The engineer stays in the loop at the point where judgement matters, which is deciding what is right, not retyping what a drawing already says.
  1. 1 · Ingest

    Point it at the folder

    Drawings, datasheets, as-builts and the GIS connection go in as they are. No templates to fill, no naming convention to adopt first, and nothing has to be redrawn to be readable.
  2. 2 · Extract

    Equipment, specs and flowpath

    Each document is classified, the symbols and tags are recognized, the flowpath is traced, and every value is recorded against the page it came from. Extraction that is unsure of an item routes it to a person rather than guessing it.
  3. 3 · Reconcile

    Where the sources disagree

    The drawing, the GIS layer and the as-built are compared against each other. Every disagreement is flagged with both values and both sources, so an engineer rules on it before a study runs on it.
  4. 4 · Verify

    The engineer approves, then it stays current

    The build ends in a review, not a rebuild. Once approved, new drawings, MOCs and redlines are re-read as they land, so the model tracks the asset instead of drifting between projects.

And then it does not go stale

A model is a living record, not a deliverable.

The reason models go six months stale is that nothing re-reads the source documents after the project closes. Model Builder keeps reading: a new as-built, an approved MOC or a corrected GIS attribute re-enters the model, and where the correction belongs upstream it is pushed back to the system of record so the next person to open the drawing sees the truth. Corrections are tracked, so you can always see what changed, when, and on whose authority.

  1. Verified model
    One model of the asset
  2. FlowSync
    Flow Simulator

    Steady-state and transient hydraulics.

  3. FlowSync
    Process Simulator

    Facility questions, answered weekly.

  4. Your stack
    The simulator your team already runs

    Fed the same clean, current inputs. Taylor reads the same model.

The model is built once and read by everything downstream, including the tools your engineers already own. Nothing here requires replacing a simulator.

What it replaces

Retires the workarounds your team has been stacking for years.

The workaround
4 retired
What it retires
The manual model buildAn engineer re-keying equipment, lengths and specs out of PDFs into a simulator. On a deployment account that build went from weeks of manual effort to minutes of verification.
The GIS export and the takeoff sheetAn export is a snapshot. It is stale the moment the next MOC lands, and nobody can say afterwards which copy a given study was run on.
The model only one engineer can rebuildWhen the build lives in one person’s method and folder structure, the model leaves with them. A repeatable build keeps the knowledge in the system.
The six-month-stale digital twinA model that is only updated at project boundaries is wrong for most of its life. Re-reading the source documents as they change is what keeps it usable between projects.

Works with your existing stack

Reads the systems you already run.

Drawings and documents
  • P&ID and isometric PDFs
  • Datasheets and vendor cutsheets
  • As-builts and alignment sheets
  • MOC packages
GIS and survey
  • Esri ArcGIS
  • Geodatabase and shapefile
  • Centerline and elevation profile
  • Class location data
Operating data
  • WorkSync DataHub
  • AVEVA PI System
  • Proficy Historian
  • SCADA tag history
Engineering tools
  • The simulator your team already runs
  • Model export for steady-state work
  • Model export for transient work
  • Calculation and study files

Pricing · FlowSync

Scoped to your operation.

Impact Guarantee · license fees only when the metrics move

You buy FlowSync from WorkSync; the tracks beside this are rollout scopes of that one purchase.

Scoped to your well count and systems with our implementation team when you plan your pilot. The pilot runs four weeks on one field, and DataHub is included.

GOOD
Model Builder + DataHub on one system
BETTER
adds Flow Simulator and Process Simulator on the same model
BEST
adds Taylor across your engineering library and MOC workflow

Proof

Hydraulic model builds went from weeks of manual effort to minutes of verification, across 2,000+ miles of pipeline modeled.

Deployment account, anonymized. WorkSync Research, Volume V

Before you ask

Common questions

What is FlowSync Model Builder?
Model Builder is the FlowSync module that builds a hydraulic or process model of your asset from the documents you already maintain: P&IDs, isometrics, datasheets, vendor cutsheets, as-builts and your GIS. It identifies the equipment, traces the flowpaths, populates the specs and produces one verified model, then keeps that model current as new drawings and MOCs land. Flow Simulator, Process Simulator and Taylor all read the same model, and it feeds the simulator your team already runs.
How does Model Builder actually read our PDFs?
Document AI trained on engineering libraries. Each document is classified, symbols and tags are recognized, the flowpath is traced, and the equipment specs are populated from the datasheet that states them. Every extracted value keeps a pointer to the page it came from, so a reviewer can check any number against its source in one click rather than taking it on faith.
What happens when the drawing and the GIS disagree?
It is flagged rather than silently resolved. Model Builder compares the drawing, the GIS layer, the as-built and, where it matters, the historian, and presents each disagreement with both values and both sources. An engineer rules on it, the ruling is recorded, and the study runs on a model whose conflicts are known rather than buried.
Do we have to replace the simulator we already run?
No. The common deployment keeps your existing simulator and uses Model Builder in front of it: FlowSync builds and maintains the model, and the simulator your team already runs gets clean, current inputs instead of a hand-built file. Nothing here requires a licence change or a migration to get value from the build step.
How do we know the extracted model is right?
Three things carry it. Confidence is tracked per item and low-confidence items are routed to a person rather than guessed. Every value is traceable to the document and page it came from. And the model is reconciled against your as-builts and controlled drawings, with discrepancies surfaced for a ruling. The engineer verifies a model rather than rebuilding one, which is the whole change in the job.
How long does the first model take?
The pilot runs four weeks on one system you pick: connections and document access in week one, the first build and reconciliation in week two, engineer verification and corrections in weeks three and four. On a deployment account, once the documents were connected, hydraulic model builds went from weeks of manual effort to minutes of verification.
What does it cost?
License fees only when the metrics move. You pick the operating metric that matters, most often model build time or model freshness, we agree the baseline in week zero and measure at week four. Scope is set with our implementation team when you plan your pilot, and DataHub is included.

See your own model built.

Bring one system and the folder of drawings that describes it. We build the model from your own documents and walk the reconciliation with your engineer, so you see what was extracted, what disagreed, and what it took to verify.