What Is a Tag Provider?
A tag provider is a component within a SCADA or industrial automation platform that serves as a source of tags -- named data points that represent values from the physical or logical world. In systems like Ignition by Inductive Automation, tag providers are the primary mechanism for organizing, accessing, and managing all real-time and historical data within a project.
Understanding Tags in SCADA Systems
A tag (also called a data point, variable, or process variable) is the fundamental unit of data in any SCADA system. Each tag represents a specific piece of information, such as:
- A sensor reading -- Temperature of a tank, pressure in a pipeline, flow rate through a valve
- A device state -- Motor running/stopped, valve open/closed, alarm active/inactive
- A calculated value -- Efficiency percentage, running total, deviation from setpoint
- A configuration parameter -- Setpoint value, alarm threshold, recipe parameter
Every tag has key properties:
- Name -- A human-readable identifier (e.g., "Tank1/Level")
- Path -- The hierarchical location within the tag tree (e.g., "Plant/Area1/Tank1/Level")
- Data type -- Integer, float, boolean, string, date, or dataset
- Value -- The current data point
- Quality -- Indicates whether the value is reliable (Good, Bad, Uncertain)
- Timestamp -- When the value was last updated
Types of Tag Providers in Ignition
Ignition supports several types of tag providers, each serving a different purpose:
Default (Internal) Tag Provider
The standard tag provider where most tags reside. Supports all tag types and is stored in the Ignition gateway's internal database. This is the primary workspace for building tag structures.
OPC Tag Provider
Connects directly to OPC UA or OPC DA servers to read and write data from PLCs, RTUs, and other industrial devices. Tags mirror the address space of the connected OPC server. This is the bridge between Ignition and the physical process.
Expression Tags
Tags whose values are computed from expressions -- mathematical formulas, conditional logic, or references to other tags. Examples:
- `{Tank1/Level} * {Tank1/Area}` to calculate volume
- `if({Motor/Running}, "ON", "OFF")` to convert a boolean to a string
Derived Tags
Tags that apply transformations to a source tag's value, such as:
- Moving average -- Smooths noisy sensor data
- Rate of change -- Calculates how fast a value is changing
- Expression -- Applies custom logic to a source value
Query Tags
Tags whose values come from SQL database queries. Useful for integrating business data (production orders, batch recipes, quality results) into the SCADA environment.
Reference Tags
Tags that point to another tag, allowing the same data point to appear in multiple locations within the tag hierarchy without duplication.
Memory Tags
Tags that exist only in memory and do not connect to any external data source. Used for internal calculations, temporary storage, and user interface state management.
Tag Hierarchies and Folder Structure
Effective tag organization is critical for maintainable SCADA systems. Tags are organized in hierarchical folder structures that typically mirror the physical plant layout:
```
[default]
Site_Paris/
Building_A/
Production_Line_1/
Conveyor/
Speed
Running
Fault
Robot_1/
Position_X
Position_Y
Cycle_Count
Utilities/
Compressor_1/
Pressure
Temperature
Running_Hours
```
This hierarchical approach provides:
- Intuitive navigation for operators and developers
- Logical grouping that matches the physical plant
- Simplified security by applying permissions at the folder level
- Easier maintenance when equipment is added or relocated
User Defined Types (UDTs)
UDTs are one of the most powerful tag organization features in Ignition. A UDT is a template that defines a reusable tag structure:
- UDT Definition -- Defines the structure (e.g., a "Motor" type with tags for Speed, Running, Fault, Running_Hours, Alarm_High)
- UDT Instance -- A concrete copy of the definition applied to a specific piece of equipment (e.g., "Pump_1" of type "Motor")
Benefits of UDTs:
- Consistency -- Every motor, valve, or tank uses the same tag structure
- Efficiency -- Create hundreds of instances from a single definition
- Maintainability -- Change the definition once, and all instances update automatically
- Standardization -- Enforce naming conventions and data structures across the entire project
Best Practices for Tag Organization
- Follow ISA-88/ISA-95 naming conventions -- Use standardized hierarchies (Enterprise > Site > Area > Unit > Equipment)
- Use UDTs for repeated equipment -- Never manually duplicate tag structures
- Separate concerns -- Keep OPC connections, internal calculations, and display tags in distinct providers or folders
- Limit tag provider count -- Use as few providers as necessary to avoid complexity
- Document tag naming standards -- Publish a tag naming convention document for the project team
- Use tag groups for scan rates -- Group tags by required update frequency (100ms for critical, 1s for standard, 10s for slow-changing)
- Enable history selectively -- Only historize tags that provide analytical value to avoid database bloat
- Plan for growth -- Design tag structures that can accommodate future equipment additions without restructuring