Every HMI is built from the same handful of things drawn over and over: pumps, valves, tanks, motors, and instruments appear on screen after screen. A graphic symbol library is the curated collection of those reusable drawings, defined once and placed many times, so a builder assembles screens from a shared kit rather than redrawing each element. This guide explains what a symbol library is, how the master-and-instance model lets a single change ripple out to every copy, why a standard library enforces consistency and speeds engineering, and how it fits into an HMI style guide.
Symbol library in one line: A graphic symbol library on an HMI is a curated set of reusable equipment symbols, such as pumps, valves, and tanks, that builders instance onto many screens instead of drawing each one from scratch. Most libraries use a master-and-instance model, so editing the master symbol propagates the change to every instance across the project, which enforces consistency, cuts engineering time, and is central to how an HMI style guide is applied.
A symbol library is essentially a toolbox of pre-drawn graphic objects representing the equipment a facility contains. Rather than each engineer drawing a pump their own way, the library provides one agreed pump symbol that everyone places, so every pump on every screen looks the same and means the same thing. The library typically covers the common process equipment, valves, pumps, motors, tanks, vessels, heat exchangers, and instruments, along with the interface elements such as indicators, faceplates, and navigation controls that make up a working screen.
The word curated matters because a good library is designed, not just accumulated. The symbols are drawn to a consistent style, sized and proportioned to sit together on a screen, and made to reflect the HMI design philosophy the site has chosen, whether that is a traditional coloured schematic look or a flat high-performance style. A library assembled thoughtfully becomes the visual vocabulary of the whole HMI, so screens built from it are coherent by default rather than by the discipline of each individual builder.
When a builder assembles a screen, they drag symbols from the library onto the display and connect each one to the tags for the real equipment it represents. The symbol carries its appearance and its behaviour with it, so placing a valve symbol brings along the way that valve shows open, closed, or faulted. This is why a library is more than a set of pictures: it is a set of ready-made, behaviour-bearing building blocks that turn screen construction into assembly rather than drawing.
The feature that makes a symbol library powerful is the relationship between the master symbol and its instances. The master is the single authoritative definition of a symbol, held once in the library. Every place the symbol appears on a screen is an instance, a linked copy that inherits its look and behaviour from the master rather than owning them independently. The instances differ only in the details that must vary, such as which tags they connect to and where they sit on the screen, while everything about how the symbol looks and behaves comes from the shared master.
The payoff arrives when a change is needed. If the standard way of showing a running pump should change, or a valve symbol needs a new fault indication, the builder edits the master once, and every instance across the entire project updates to match. Without this model, the same change would mean finding and editing every copy of that pump on every screen by hand, which is slow and almost guarantees that some copies get missed and drift out of step. The master-and-instance model turns a project-wide change from a large, error-prone chore into a single edit.
This model also allows controlled variation. Many symbol systems let an instance override selected properties, or offer parameterised symbols where the same master serves several similar cases through configuration rather than duplication, and some support inheritance so a specialised symbol builds on a general one. The discipline is to keep genuine shared behaviour in the master and only let instances vary in the ways that truly need to, so the benefit of one-place editing is preserved while still handling the real differences between individual pieces of equipment.
A standard symbol library delivers two benefits that matter most in a SCADA context. The first is consistency, which is a safety property, not just an aesthetic one. When every valve looks and behaves the same across every screen and every site, an operator learns the vocabulary once and reads any screen fluently, so a symbol never means one thing here and something else there. That uniformity reduces the chance of a misread in a moment of stress, which is exactly when consistency pays off. The second benefit is engineering speed, because building screens from a shared kit is far faster than drawing each element, and a large rollout across many sites reuses the same library everywhere.
This is why a symbol library sits at the centre of an HMI style guide. Standards work on human-machine interfaces, such as ISA-101, encourages organisations to define a style guide that captures how the HMI should look and behave, and the symbol library is how that style guide is made concrete and enforced. Rather than asking each builder to follow a written description of how a pump should look, the organisation gives them the approved pump symbol, so conformance to the standard is built into the tools they use. The library becomes the executable form of the style guide.
For a distributed operation running many similar sites, a shared library is what keeps a large HMI coherent as it grows. A cloud SCADA platform such as Merobix benefits from the same principle: standardised, reusable symbols connected to the tags of each remote site mean that a wellpad screen, a tank battery screen, and a compressor screen all speak the same visual language, and an operator moving between sites reads them all the same way. Because the symbols are defined once and instanced across the fleet, extending the system to a new site is largely a matter of placing familiar symbols and binding them to that site's tags, which keeps both the engineering effort and the operator learning curve low as the operation scales.
A master symbol is the single authoritative definition of a symbol held in the library, while an instance is a linked copy placed on a screen that inherits its look and behaviour from the master. Instances differ only in what must vary, such as their position and the tags they connect to. Editing the master updates every instance across the project, which is the main advantage of the model.
A standard library enforces consistency, so every valve or pump looks and behaves the same across all screens and sites, which helps operators read any screen fluently and reduces misreads. It also greatly speeds engineering, because screens are assembled from ready-made building blocks rather than drawn from scratch. And it makes a style guide enforceable by giving builders the approved symbols to use directly.
The style guide defines how the HMI should look and behave, and the symbol library is how that definition is made concrete and enforced. Instead of relying on builders to follow a written description, the organisation provides the approved symbols, so conformance is built into the tools. Standards work such as ISA-101 encourages defining a style guide, and the library is effectively its executable form.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.