Tags provide a consistent data model throughout Ignition, and offer the easiest way to get up and running creating realtime status and control systems. The phrase "realtime status and control system" is sort of an industry buzz word.

Despite their low initial learning curve, however, Tags offer a great amount of power in system design and configuration. The ability to aggregate tags from a variety of installations in a central SQL database means that you can build widely distributed SCADA systems more easily than ever before with a high level of performance and relatively easy configuration.

Tag Configuration in the Gateway

While the goal of Tags is to create an easy yet powerful tag model, the variety of options and terminology can sometimes make configuration confusing. The goal of this section is to provide a clear overview of the Tag landscape, and provide a clear guide to the configuration of various architectures.

Note that you will use both the Gateway and the Designer for tag configuration.

In the Gateway, as described in this section, you perform the tag configuration by specifying such things as the realtime/historian providers and internal/external databases. The tag configurations in the Gateway apply globally to all your projects.

In the Designer, when working on your project design, you will create the different types of tags such as an OPC tags, memory tags, and expression tags. You will then set the tag properties and other functionalities such as alarming. You will also gain a working knowledge of what tags are and how they are executed.

Tag Providers and Drivers

At the highest level of configuration is the Tag Provider. A provider is a tag database (a collection of tags) and a name. An Ignition Gateway can have any number of tag providers, and therefore the name is used to distinguish which provider a tag comes from. Tag Providers can be set up with security or even disabled independent of each other.

Every provider holds tags, but not every provider is a Tag driver, or a tag executor. Some tag providers simply make tags available to use, and the tag execution is performed by a different driving provider elsewhere. For example, the Database Provider is a Tag provider that simply watches a tag database stored in an external database. It does not execute tags, it only monitors the values of the tags present. Somewhere else there is a tag driver such as a Driving Datasource Provider or a legacy FactorySQL that is executing the tags and storing the values to the database.

Realtime vs. Historian Providers

As discussed above, all Tags reside in a tag provider and provide realtime values. Additionally, there is the concept of tag historian providers, which can store and query historical data for tags. Each tag can optionally have a historian provider assigned to it to whom it will report value changes for historical storage.

Realtime Providers - Internal vs. External

The Tags "tag database", or how Tags tag configuration is stored, can take two forms. For internal tags, the configuration is stored in the Ignition Gateway. In the external form, tags are stored in a SQL database, outside of the Ignition Gateway. The two different storage mechanisms have different pro and cons, and so it is a good idea to acquaint yourself with each of them.

Internal Tags Provider

The internal Tags provider manages the tags inside the Ignition Gateway. This is the most common method and is optimized for the best scaling and performance.

It is possible to create multiple internal providers per Gateway. The tags can be exposed to other Gateways on the network through the Gateway's OPC-UA settings.

External Tags Providers

There are two types of external Tags providers in Ignition:

Database Provider
Database Driving Provider (provided by the SQL Bridge module)

The driving provider, as mentioned above, will execute tags as well as make available tags driven by other external drivers looking at the same database, such as other Ignition Gateways using the driving provider, or legacy FactorySQL installations.

The primary benefit of external providers is that the data is stored in a central database, and is therefore accessible to other data consuming systems that do not have the capabilities to connect to Ignition's OPC-UA server as an OPC-UA client yet still require the need to consume realtime tag information.

The negative side to external providers is that all tag values must be written to the database and then polled for change, which is a less efficient method than internal provider's method. In other words the inherent architecture of the external model does not scale as well as the internal provider model.

Configuring Realtime Tags

Realtime Tags providers are configured in the Gateway's Configure section under Tags > Realtime. After installation, the Ignition Gateway will start with an internal provider defined. You can edit its name and settings by selecting edit to the right of its entry in the table, or create new providers by selecting Create new Realtime Tag Provider below the table.

There are three types of Realtime Tag Provider that you can choose from:

Standard Tag Provider
Tag Consuming Provider
Tag Driving Provider

The settings for each of these tag providers are shown next.

Standard Tag Provider Tags are stored inside of Ignition and executed by the system.
Name	The name of the provider.
Description	The description of the provider.
Tag Editing Role (s)	Users must belong to one of these roles in order to edit this provider's tags in the Designer. Multiple roles can be specified by separating them with commas. If blank, tag editing for this provider will not be restricted in the Designer.
Default Database	The default database connection to use for expression tags that run SQL queries. All query tags with default database providers selected with run their queries against this database source.

Tag Consuming Provider Reads tags stored in an external database and driven by a different instance. Only consumes tags provided by other systems, does not write tag values back to the database.
Name	The name of the provider.
Description	The description of the provider.
Tag Editing Role (s)	Users must belong to one of these roles in order to edit this provider's tags in the Designer. Multiple roles can be specified by separating them with commas. If blank, tag editing for this provider will not be restricted in the Designer.
Database	The database connection where the tag database resides.
Poll rate	The rate in milliseconds at which value and configuration changes will be polled.
Poll overlap	The amount of time, in milliseconds, to overlap the polling time span.

Tag Driving Provider Stores and executes tags in an external database.
Name	The name of the provider.
Description	The description of the provider.
Tag Editing Role (s)	Users must belong to one of these roles in order to edit this provider's tags in the Designer. Multiple roles can be specified by separating them with commas. If blank, tag editing for this provider will not be restricted in the Designer.
Database	The default database connection where the tag database resides.
Driver name	The unique name of this driver. Since the tags are stored in a central database, there may be multiple providers and drivers operating on them. This name will be used to identify this driver instance, and the tags that it executes. While the driving provider will read all of the tags stored in the database, it will only execute those tags that are assigned to it.
Poll rate	The rate in milliseconds at which value and configuration changes will be polled.
Poll overlap	The amount of time to overlap polls by. If set to 0, the config scan will look for changes only since the last execution. However, on databases that do not support millisecond resolution or are performing less-than-optimally, this could result in missed changes. This setting will expand the window in order to avoid missing these changes.
Enable browsing	Allows remote browsing of the OPC servers available to this driver over TCP/IP. This allows other Gateways to remotely browse and add tags assigned to this driver into the central database.
Browse port	The port to listen on for remote connections. This port must not be in use by any other entity on the machine. Also, each driving provider that wishes to support browsing must have its own port.
Browse address	The IP address/network name that remote Gateways will use when browsing. Therefore, care must be taken that the address is available from the Gateways that will try to connect. Also, since it is used for access by remote systems, it should not be the loopback address (localhost or 127.0.0.1). The browse address and port will be stored in the Tags database so that other Gateways can easily look them up. After the settings are configured, you should immediately see the driver name in the OPC browse list for the external provider on other systems looking at the same database. Note: When using remote browsing, make sure that the local firewall has an exception for the port that is used to listen. Otherwise, remote machines will not be allowed to connect.

External Provider Reference

Important

The information provided here requires an understanding of Tags and how they work. It is an advanced reference to how the tables of external Tags providers are structured and an overview of the concepts of tag execution. If you are a new user, it is suggested that you read the Understanding Tags section first.

Basic Concepts and Data Flow

Tags operate through tables created in the database.

Tag Configuration Table Names and Descriptions
sqlt_core	The core tag information table, has one entry per tag. Defines fundamental properties like data type, as well as the current value of the tag. Is monitored by the provider to determine value and configuration changes.
sqlt_meta	Provides additional properties for tags. Only consulted when tag configuration has changed.
sqlt_as	Provides alert state configuration for tags which utilize alerting.
sqlt_perm	Provides custom permission settings for tags set to use them.
Operations Table Names and Descriptions
sqlt_sc	Contains the definitions of scan classes, which dictate how tags are executed.
sqlt_sci	Contains an entry for each scan class from sqlt_sc, for each driver currently driving tags. Used to verify that drivers are properly executing.
sqlt_drv	Contains an entry for each Tags driver. Only really used for browsing tags.
sqlt_err	Contains errors that have occurred executing tags.
sqlt_wq	The "write queue". All write requests are entered into this table, where the driver will detect and execute them. The result will be written back by the driver, and will be noticed by the provider.

Tag Execution Concepts

Polling – Many operations require polling of the database by either the driver or the provider. To ensure efficiency, all polling operations utilize indexed timestamp fields. This allows the database to do very little work when nothing has changed.

Tag Configuration – Tags are configured by inserting or modifying the appropriate entries in the configuration tables above. Configuration change is signaled to the provider by updating the configchange of sqlt_core to be the current time. Deleting a tag works by setting its deleted column and then touching config change. This will inform all drivers and providers to remove the tag from memory. At some point later, a daemon will delete the tag information from the database.

Tag Execution, drivers – Each tag has a drivername property that indicates which driver is responsible for executing it. Other drivers and providers with different names will treat the tag as an external tag – a tag driven by a different entity – and will only monitor its value.

Tag Execution, scan classes – Each tag is assigned to a scan class. The idea is that scan classes will define how often the tag should execute, as well as provide more advanced options like leased and driven execution. In reality, the tag driver is free to execute tags as it desires, but it is important to understand how the scan classes and the sqlt_sci table are expected to work, as that is how the provider will verify that the tags are being executed.

Tag Monitoring – Both providers and drivers generally monitor tag value and configuration changes. In general, the entities will monitor tags whose drivername isn’t equal to their own, which for providers means all tags, since providers don’t have a driver name. Monitoring occurs by selecting the tag values (or any information desired) from the appropriate table where one of the indexed timestamp columns is greater than the last checked time. The provider/driver will then store that time in memory as the last check, and will use it in the next poll.

Table Reference

The following is a reference list for the table structures of all the tables listed above. In general, all integer time values are in milliseconds.

sqlt_core
Column	Data Type	Notes
id	integer	Auto-incrementing, unique id for the tag
name	string	Name of tag
path	string	Folder path, in form of `path/to/`
drivername	string	Name of driver responsible for executing tags
tagtype	integer / TagType enum	The type of tag - that is, OPC, DB, and so on
datatype	integer / DataType enum	The type of data provided by the tag
enabled	integer (0 or 1)	Whether the tag is enabled for execution
accessrights	integer / AccessRightsenum	Access permissions for the tag
scanclass	integer	ID of the scan class for the tag
intvalue	integer	Value column used if tag has integer data
floatvalue	double	Value column for float/real data
stringvalue	string	Value column for string data
datevalue	datetime	Value column for date data
dataintegrity	integer / DataQualityenum	Current quality of the value
deleted	integer (0 or 1)	Whether the tag is deleted or not
valuechange	datetime	The last time that the value changed
configchange	datetime	The last time that the tag's config changed

sqlt_meta
Column	Data Type	Notes
tagid	Integer	ID of tag that the property belongs to
name	string	The well-known property name
intval	integer	Value, if property has integer type
floatval	double	Value if property has float type
stringval	string	Value, if property has string type

sqlt_as
Column	Data Type	Notes
id	integer	Unique id of alert state
statename	string	Name of alert state
severity	integer /Severity enum
low	double	Low setpoint
high	double	High setpoint
flags	integer / Alert Flags	Flags that dictate how the state acts
lotagpath	string	Path to tag that provides low setpoint, if low driven flag is set
hitagpath	string	Path to tag that Provides high setpoint, if high driven flag is set
timedeadband	double	Time deadband value
timedbunits	integer / TimeUnits enum	Time deadband units

sqlt_perm
Column	Data Type	Notes
tagid	integer	ID of tag that the permission belongs to
rolename	string	Name of the role that this permission is applied to
accessrights	integer / AccessRights enum	Access rights for the given role on the given tag

sqlt_drv
Column	Data Type	Notes
name	string	Name of the tag drive
ipaddr	string	Address of browser server, blank or null if browsing isn't available
port	integer	Port of browse server

sqlt_sc
Column	Data Type	Notes
id	integer	Auto-incrementing unique id
name	string	Name of the scan class
lorate	integer	The slower rate to run at, in milliseconds. Only rate used if scan class mode is direct
hirate	integer	Higher rate, in ms. Only used if scan class is driver or leased
drivingtagpath	string	Path to tag to watch if mode is driven
comparison	integer / Comparison enum	Operation to apply to driving tag in driven mode
comparevalue	double	Value to compare driving tag to for driven mode
mode	integer / Scan class mode enum	The mode of the scan class
staletimeout	integer	Time, in milliseconds, before scan class is determined to not be running
leaseexpire	datetime	The time that the lease should expire, if using leased mode
configchange	datetime	The last time that the scan class has been modified
deleted	integer (0 or 1)	Whether the scan class has been deleted

sqlt_sci
Column	Data Type	Notes
sc_id	integer	The id of the scan class represented
drivername	string	The driver executing this instance
lastexec	datetime	Last time that the scan class executed
lastexecrate	integer	The rate of the scan class at last execution
lastecexduration	integer	Time, in ms, that the scan class took to execute
lastexecopcwrite	integer	Writes to OPC performed during last execution
lastexecopcreads	integer	Value updates from OPC processed in last execution
lastexecdbwrites	integer	Writes to DB performed during last execution
lastexecdbreads	integer	Value updates from the database processed during the last execution
lastecexdelay	integer	The delay between when the scan class should have ran and when it actually ran for the last execution
avgexecduration	integer	The average duration time of the scan class, in ms
execcount	integer	The number of times the scan class has executed
nextexec	datetime	The next time that the scan class should execute

sqlt_wq
Column	Data Type	Notes
id	integer	Auto-incrementing unique id for the write operation
tagid	integer	ID of the tag to write to
intvalue	integer	Value, if tag has integer data type
floatvalue	double	Value, if tag has float or real data type
stringvalue	string	Value, if tag has string data type
datevalue	datetime	Value, if tag has date data type
responsecode	integer / Write Responseenum	The state of the write request. When created, the response code should be set to 2 - Pending
responsemsg	string	Write error if operation failed
t_stamp	datetime	The time that the write request was created
objectid	integer	ID of the object with the error
objectype	integer / Object Type enum	The type of object. Used with objectid to identify the item that caused the message
lifecycleid	integer/ Lifecycle enum	When the message was generated
msgtype	integer / Message Type enum
errormsg	string	The primary message
stack	string	Additional error information
t_stamp	datetime	When the message was generated

Enum Reference

There are known values for many of the objects in the Ignition Tags. Almost every list in Ignition has an enumeration that starts at 0 and counts down the list. Below are a few:

Basic Tag fields

Tag Type
0	OPC Tag
1	DB Tag
2	Client Tag
6	Folder Tag

Data Types
0	Byte
1	Short
2	Integer
3	Long
4	Float
5	Double
6	Boolean
7	String
8	Date
9	Integer Array
10	Long Array
11	Double Array
12	Boolean Array
13	String Array
14	DataSet

Access Rights
0	Read Only
1	Read/Write
2	Custom

Scan Class Modes
0	Direct
1	Driven
2	Leased

Write Response
0	Failure
1	Success
2	Pending

Quality

Data Quality
0	Bad Data from OPC
4	CONFIG_ERROR
8	NOT_CONNECTED
12	DEVICE_FAILURE
16	SENSOR_FAILURE
20	Bad, showing last value
24	COMM_FAIL
28	OUT_OF_SERVICE
32	WAITING
64	UNCERTAIN
68	UNCERTAIN showing last value
80	SENSOR_BAD
84	LIMIT_EXCEEDED
88	SUB_NORMAL
28	SERVER_DOWN
192	Good Data
216	Good, with local override
256	OPC_UNKNOWN
300	Config Error
301	Comm Error
310	Expr Eval Error
330	Tag exec error (fsql)
340	Type conversion error
403	Access Denied
404	Not Found
410	Disabled
500	Stale
600	Unknown (loading)
700	Write Pending

Alarms

Comparison Mode
0	Equal
1	Not Equal
2	Less Than
3	Less Than Equal
4	Greater Than
5	Greater Than Equal

Alert Flags
0x01	Low Exclusive
0x02	Low Infinite
0x04	High Exclusive
0x08	High Infinite
0x10	Any Change
0x20	Low Driven
0x40	High Driven

Tag Configuration in the Gateway

Tag Providers and Drivers

Realtime vs. Historian Providers

Realtime Providers - Internal vs. External

Internal Tags Provider

External Tags Providers

Configuring Realtime Tags

Standard Tag Provider

Tags are stored inside of Ignition and executed by the system.

Tag Consuming Provider

Reads tags stored in an external database and driven by a different instance. Only consumes tags provided by other systems, does not write tag values back to the database.

Tag Driving Provider

Stores and executes tags in an external database.

External Provider Reference

Important

Basic Concepts and Data Flow

Tag Configuration Table Names and Descriptions

Operations Table Names and Descriptions

Tag Execution Concepts

Table Reference

sqlt_core

Column

Data Type

Notes

sqlt_meta

Column

Data Type

Notes

sqlt_as

Column

Data Type

Notes

sqlt_perm

Column

Data Type

Notes

sqlt_drv

Column

Data Type

Notes

sqlt_sc

Column

Data Type

Notes

sqlt_sci

Column

Data Type

Notes

sqlt_wq

Column

Data Type

Notes

Enum Reference

Basic Tag fields

Tag Type

Data Types

Access Rights

Scan Class Modes

Write Response

Quality

Data Quality

Alarms

Comparison Mode

Alert Flags

In this section ...