A user-defined data type, or UDT, is a custom data structure you create by bundling several related tags into a single named type. Instead of declaring tubing pressure, casing pressure, flow rate, valve state, and a status word as five loose tags, you define a Well type that contains all of them, and then declare each well as one tag of that type. UDTs, also called structures, are one of the most quietly powerful features in modern PLC programming, and standardizing on them is arguably the single biggest maintainability win available to a growing oilfield SCADA program.
User-Defined Data Type in one line: A user-defined data type (UDT) is a custom structure that groups related tags into one reusable named type, such as a Well type holding tubing pressure, casing pressure, flow, valve state, and status. You then declare instances of that type, so every well is described by the same consistent bundle of members instead of scattered individual tags.
A UDT is defined once as a template: you list the members it contains, each with its own name and data type, and give the whole thing a meaningful name. A Well UDT might hold a real for tubing pressure, a real for casing pressure, a real for flow, a boolean or enumeration for valve state, and an integer status word carrying packed condition bits. Having defined it, you can now create a tag of type Well, and that single tag carries every one of those members as named sub-elements you access by a clear path.
The gain over loose tags is immediate. Where you once had dozens of independent tags with names that only convention kept related, you now have one tag per well whose structure is explicit and self-documenting. Referring to a well's casing pressure means addressing that member of that well's tag, and it is obvious at a glance which well and which value you mean. The relationships between the values - that these five things all describe one well - are encoded in the type itself rather than living only in a naming convention that a later engineer has to infer.
Because the members and their types are defined in one place, the type becomes a contract. Every tag of that type has exactly the same members, in the same layout, with the same names. Add a member to the UDT - say a downhole temperature - and every instance gains it consistently. This single source of truth for what data describes a well, or a separator, or any repeated asset is what turns a sprawling tag database into an organized, predictable data model.
Once a UDT exists, both logic and HMI stop being one-off work and become copy-paste consistent. A routine written to control a well operates on a tag of the Well type, referring to its members by name, so the same routine applies unchanged to every well - you point it at a different well tag and it just works. The logic no longer has to be rewritten or carefully re-addressed for each well, because the shape of the data it acts on is guaranteed identical everywhere the type is used.
HMI faceplates gain the same consistency. Build a faceplate that displays and controls a well by binding its fields to the members of a Well tag, and that one faceplate serves every well by simply pointing it at a different instance. There is no per-well screen to hand-build and no risk of one well's display drifting from another's, because they all render the same structure. Dozens of wells present a uniform interface to operators, which reduces training, reduces mistakes, and makes the whole system feel coherent rather than assembled piecemeal.
This consistency compounds as the program grows, which is why UDTs are such a strong maintainability play. Standardizing a well UDT means a fix or an enhancement is made once - to the type, the reusable routine, or the shared faceplate - and it applies everywhere automatically. Adding the twentieth well is instantiating a known type and reusing proven logic and screens, not another round of custom work. The larger the field gets, the more this leverage matters, and the more a program built without it accumulates inconsistency and effort with every addition.
Defining a standard site UDT - a Well type, a Separator type, a Compressor type - and using it across an oilfield gives the whole operation a common data language, and the benefit reaches all the way up to cloud SCADA. When every well in the controller is an instance of the same type, every well exposes an identical, predictable set of points, so bringing them into a platform like Merobix is uniform rather than a bespoke mapping exercise for each site. The structure that organizes the data at the controller carries through to how it is monitored remotely.
That uniformity is what makes fleet-scale dashboards and templated faceplates practical in the monitoring layer. A single well template built once in the SCADA platform applies to every well because every well presents the same UDT-shaped data, so an operator sees the same tubing pressure, casing pressure, flow, valve state, and status in the same place on every well's screen. Comparing wells, spotting the outlier, and rolling out a new site all become routine, because the data model was standardized at the source rather than reconciled after the fact.
The broader lesson is that a well-chosen UDT standard is an investment that pays back continuously as the SCADA program grows. It costs a little upfront thought to decide what a Well should contain and to hold the line on using that type everywhere, but it saves that cost many times over in every subsequent well added, every screen reused, every change made in one place instead of many. For a growing oilfield operation, standardizing on site UDTs is the structural decision that keeps the control and monitoring program maintainable at scale rather than collapsing under its own repetition.
A UDT, or user-defined data type, is a custom structure you create by bundling several related tags into one named type, such as a Well type containing tubing pressure, casing pressure, flow, valve state, and a status word. You then declare instances of that type, so each well is one tag carrying all those members. It replaces many loose, individually named tags with a single organized, reusable structure.
Because every instance of a UDT has exactly the same members in the same layout, you can build one faceplate that binds to those members and then point it at any instance. A single well faceplate serves every well by pointing it at a different well tag, with no per-well screen to hand-build. Dozens of wells then present a consistent interface, reducing both development effort and operator error.
Standardizing a site UDT means every well, separator, or compressor exposes an identical, predictable set of data, so bringing sites into a cloud SCADA platform and building templated dashboards becomes uniform rather than bespoke for each one. Fixes and enhancements are made once to the type and apply everywhere, and adding a new site is instantiating a known type rather than custom work. That consistency is what keeps a growing SCADA program maintainable at scale.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.