If every well needed its own hand-built report, reporting across a field of hundreds of wells would be impossible. It is not, because of a single idea: design the report once and drive it with parameters. A report template is that reusable design, and a parameterized report is what you get when you run it against a particular set of inputs. This guide explains how one template produces a per-well report for any well, covering how layout binds to SCADA tags, how run-time parameters select the site and period, and why this is the concept that makes SCADA reporting scale.
Report Template in one line: A report template is a reusable report design - its layout, calculations, and structure - that is not tied to any single asset. A parameterized report is an instance of that template run with specific inputs, such as a chosen site, date range, and tag set. By binding the template to parameters rather than fixed data, one design generates a correct report for any well, letting a single template serve an entire field.
A report template separates the shape of a report from the data that fills it. The template defines everything that is common across every instance: the headers, the sections, the tables, the calculations, the layout of the page. What it deliberately does not hard-code is the specific asset or period. Those are left as parameters - placeholders the template refers to instead of concrete values. When you want an actual report, you supply the parameters, and the template resolves into a finished document for that particular case. Design the daily well report once, and it works for well one, well fifty, and every well after.
This is the difference between authoring a report and authoring a report for one well. Without templating, a hundred wells means a hundred report definitions to build and, worse, to maintain: change the layout and you change it a hundred times. With a template, the design lives in one place. Improve the calculation or add a column once, and every report generated from the template inherits the change. The template becomes the single source of truth for what that class of report looks like, and the per-asset variation is pushed entirely into the parameters supplied at run time.
The parameters are what make a template flexible. Typical ones are the asset or site to report on, the date or date range to cover, and the tag set that supplies the values. When a report is run, these can be filled in automatically by a schedule - end of gas day, this well - or requested through a run-time prompt when a person generates the report on demand, choosing the site and period from a dialog. Either way the same template is being asked a specific question: produce this report, for this asset, over this window.
The mechanism that connects the template's placeholders to real data is tag binding. Rather than pointing a chart or a cell at a fixed, named tag, the template binds it to a tag resolved through the parameters - for example, the level tag belonging to whichever site was selected. This indirection is what lets one design read the right instrument for any asset: pass well one and it binds to well one's tags; pass well fifty and it binds to well fifty's. Getting the binding right depends on a consistent tag-naming or asset-model convention across the sites, so the template can locate the equivalent tag on each asset. When that structure exists, parameterization turns a field of similar wells into a single template applied many times.
Templating is the concept that lets SCADA reporting scale with the number of assets rather than the number of report designs. A cloud SCADA platform such as Merobix typically monitors many similar sites - wells, tank batteries, compressor stations - that share the same measurement structure. A parameterized template exploits that similarity: one daily production report design, one downtime report design, one compliance summary design, each run per site through parameters, covers an entire fleet. Adding a new well to monitoring does not mean authoring a new report; it means the existing templates now have one more asset to run against.
The payoff compounds when templating meets scheduling. A scheduled job can iterate a template across every site in an asset group, producing a per-well report for the whole field automatically at each gas-day close, from a single design that one person maintains. When the design needs to change, it changes once and the whole fleet's reports change with it, which keeps a large operation's reporting consistent rather than drifting site by site. In a multi-site cloud SCADA context this is not a convenience but a necessity: it is the only practical way to give hundreds of assets tailored, correct reports without hundreds of hand-built definitions to keep in sync.
A report template is the reusable design - the layout, calculations, and structure - that is not tied to any specific asset. A parameterized report is a concrete instance of that template run with specific inputs like a chosen site, date range, and tag set. The template is the reusable blueprint; the parameterized report is the finished document produced when you supply the parameters.
Instead of pointing a chart or cell at a fixed named tag, the template binds it to a tag resolved through the parameters - for example, the level tag of whichever site was selected. Pass one well and it binds to that well's tags; pass another and it binds to the next well's. This works when the sites follow a consistent tag-naming or asset-model convention so the template can locate the equivalent tag on each asset.
Because they let reporting scale with the number of report designs rather than the number of assets. A cloud SCADA platform monitoring many similar wells can maintain one daily report template and run it per site through parameters, covering the whole fleet. Adding a new well means the existing template simply has one more asset to run against, instead of authoring a brand-new report definition.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.