Tag History vs. Transaction Groups

Capturing useful data during your manufacturing processes will require you to make a decision between implementing Tag History or Transaction Groups. Such a decision will also revolve around understanding two manufacturing process types: Discrete and Continuous.

Recognizing essential aspects of your specific manufacturing process and how it pertains to one of the existing process types allows you full advantage of Ignition’s data logging capabilities. This is because both data logging implementations are flexible enough to apply to the same given scenario, where one of them will typically provide a more efficient approach than the other.

On this page, you will be informed on how concepts from these process types apply towards existing manufacturing industries, and which of Ignition’s data logging solutions are known to work best.

Discrete and Continuous Processes

Discrete and continuous processes are typically understood concepts by integrators and manufacturers when they define important aspects of a product’s creation. When observing your own processes on the plant floor, each of them should be able to fall into one of those categories.

Discrete

A discrete process involves a specified count of units moving from one workstation to another to experience modifications. Each unit retains a unique identifier for keeping track of its progress per station. Examples of where this is primarily used can be found in the following manufacturing industries:

• Automotive Suppliers
• Steel Production
• Food and Beverage (Batching)

The categories listed above all involve a process where a finite, countable amount of units (specialized parts for either automobiles or raw uncut solid material) will undergo work with one or more workstations on the plant floor. Each workstation will keep track of start and stop timestamps per unit, where the unique identifier will allow you to request those timestamps later.

Continuous

A continuous process describes a continuous amount of material for means of ensuring consistency in production. To accomplish this, the process may run for long durations with little to no interruptions. Examples of where this is primarily used can be found in the following manufacturing industries:

• Fiber Extrusion
• Oil and Gas
• Water and Wastewater

The categories listed above all involve material that’s difficult to quantify. Somewhere in the process, a consistent rate of some material will have to run through a given workstation. Monitoring a specified rate of material for long and uninterrupted durations will ensure said consistency.

Intertwining Discrete and Continuous

Understanding which type defines the most critical parts of your manufacturing process will help you make well informed decisions during your Ignition project development. Keep in mind that although some industries, like those listed above, primarily use either discrete or continuous processes, most industries typically involve other secondary manufacturing processes that require utilizing both concepts.

For instance, water and wastewater is an industry where people typically want to know the timestamps of specific intervals for when a pump turns on or when a tank alarm goes off. Essentially, they need ways to monitor the state of their overall system at intervals of some time. However, water and wastewater cannot be quantified as units, so there must also be a way to monitor the flow rate of material, as well as any interruption events.

Recognizing Data Logging and Monitoring Methods

Ignition provides two primary means of database logging for its users:

• Tag Historian
• SQL Bridge

The Tag Historian’s design allows timestamped values of individual tags to be stored asynchronously due to its use of Tag Groups and internal structure of associated SQL tables. The SQL Bridge’s design provides a more event-based procedure for logging a set of tags to a user-defined SQL table.

The key differences between these two methods is how data is stored and timestamped. This is because those differences result in varying complexities for how they are queried to the type of resulting visual you are looking for.

Tag Historian

If you are considering using Tag Historian, take a moment to review where your process expects to keep track of individual event-based data capturers using various Tag Group types/intervals. Event-based data will usually focus on recording workstation interruptions or changes from its expected flow rate of a given material. In order to keep track of such events, various moving parts may need separate monitoring to generate individual datasets and trends. The list below describes where key Tag History features can apply to this kind of setup:

• Deadband Discrete Style and Analog Compression: Storage for tags is based on value changes and the changes themselves exceeding a user configured deadband.
  • No matter what type of historical tag you have configured, discrete or analog, deadband configurations ensure the values of each and every historical tag stores its next incoming value to your discretion.
• Asynchronous Tag Storage: The storage of each tag happens independently (For example: Tag A might be stored every 10 seconds due to constant value changes while Tag B might be stored twice a day due to lack of change). Once data has been stored from a successful batch, the review of trends for each and every part of your various workstations can be narrowed down to a single tag’s set of data if desired without any complex SQL querying.
• Data Partitioning: Historical data is stored into monthly partitions by default. Historical data from different Gateways are also placed into its own partition table structure when sharing the same database. Pre-processed partition options are also available for even faster query times.
  • This structure allows for the abstraction of enterprise architectures to store large sets of tag data from multiple Ignition Gateways into a centralized database if desired.
• Fixed Table Structure: Multiple, tall data formatted, SQL tables are used by the Tag Historian to keep track of tags being stored, their Tag Group configuration and their Gateway origin.
  • This allows users to focus more on storage and retrieval of data without the worry of defining optimal database tables yourself.
• Querying and Built-In Aggregation: Aggregation such as Avg, Sum, Max/Min, DurationOn, and DurationOff can be enabled through various tag history query functions and user interfaces such as the Power Chart.
  • Additional to the abstractions placed during Tag History storage, that same can be said for querying the same data onto trends in your Ignition projects.
  • The Power Chart also provides a simpler way to query these trends using drag and drop functionality from tag browse lists to the components themselves.

For continuous processes, it’s recommended to use tag history

Tag Historian is more asynchronous in its data inserts and which results in a complex structure of associated SQL tables where groups of tags being recorded at the same rate will typically have timestamps that differ in milliseconds. Continuous processes will work better with Tag Historian because of this due to its ability to create independent sets of data points where each can be quickly and individually monitored for changes in its trends. Durations in a continuous process can be potentially un-ending with no start or end events. Since the most meaningful data comes from easily locating deviations in your trends, your setup may want to focus on constantly monitoring for changes, unique anomalies, and interruptions of some expected flow of material instead of logging individual sets of time-based data per event (discrete).

SQL Bridge

If you’re considering SQL Bridge for your setup, take a moment to review where your process expects to keep track of time-based data. Such time-based data may involve records of when those workstations began and finished work for each unit of product which would require multiple item values in your workstations to be recorded under the same timestamp for accuracy. In addition to inserting new data into what will be a user-defined SQL table, existing row(s) may instead need replacing based on some type of event success or failure. The list below describes where key SQL Bridge features can apply to this kind of setup.

• Transaction Group Types: Storage of various items under a single timestamp, SQL updates, and OPC writes are possible with transaction group types options. SQL Bridge’s Transaction Group will create a single custom table of data that receives inserts of a single timestamped row of data due to an event trigger by default.
• Execution Triggers: Transaction group executions will depend on the state of a single, user-defined item. Handshake mechanisms for execution success/failure are also provided to execute other events if needed.
  • All instructions between your connected devices and databases can be defined from transaction groups alone if desired.
• Synchronous storage: All items in a transaction group are stored together as a single SQL transaction when inserted.
  • Once your monitored events have successfully fired enough write executions, you can expect to review your table using standard SQL querying against simple table structures.
• Customizable Table Structure: A wide data formatted table where items defined in your transaction group will represent table columns.
  • Optimization of tabular data is in the hands of the user when using transaction groups. More importantly, a custom SQL table integrated with transaction group UI provides the most flexibility for your plant floor instructions while reducing complex SQL querying.
• Direct SQL Querying
  • Tables both defined by a transaction group will be much simpler to understand when read or written to in your database.
  • This also allows for integration of external stored procedures defined in your database if needed.

For discrete processes, it is recommended to use SQL Bridge

SQL Bridge is best used for discrete processes since the focus is placed on capturing the state of multiple tags under a shared timestamp during some given change event or instruction defined by the user. Time-based data stored in a single, user-defined table is more optimal, especially when a large dataset of logging is required for many individual tags/items per widget (countable unit), each with their own start and end time in a given assembly line. Each widget is an event in itself that would probably need to provide a litany of information within its duration on the assembly line, such as build ID, elapse build time, upstream batch IDs, length, weight, and QA pass/fail. Such a process probably doesn’t need constant, unending monitoring (continuous) but instead a process of nested sub-loggers that is triggered per given unit.