Ignition by Inductive Automation Dataset Tags for Performant Dashboards
How ECS Solutions uses dataset tags in Ignition by Inductive Automation, updated periodically by gateway timer scripts, to drive graphics on dashboard displays.
This allows the dashboard to simply display the datasets rather than execute queries. This results in better overall performance of the gateway (queries are only running one time), faster load times for displays (data is already available and just has to be rendered), and transparent updates over time (no application hang for periodic data refresh).
Creating informative dashboards, especially dashboards that provide data analytics, can be challenging. Oftentimes the requirements for the dashboard will evolve as it is developed. Over time, the queries and scripting functions and analyses that drive the data behind the dashboard start to pile up. This drains resources and drags down performance. This can also leave end-users with a (technically) functional but inefficient, slow, or even “clunky” result. If the analyses are being performed on the clients (a common pitfall for an inexperienced Ignition developer), this problem is compounded as more and more users start to access or view the application, each client running its own separate queries and analyses.
To combat this, ECS has developed an implementation strategy where dashboard visualizations (such as charts, graphs, and miscellaneous process-specific widgets) are instead driven by Ignition dataset tags. The dashboard tags are simply memory tags that receive periodic updates from the Ignition Gateway. This is typically done via gateway timer scripts set for an appropriate interval. A dashboard showing data for an entire production shift might only update every few minutes, while a dashboard showing data for just the last hour might update every 30 seconds.
By doing this, we create an architecture where the data is always available in the dataset tag for immediate use. That means no “clunkiness” or frustrating load times when screens are loaded. The data is already available in the dataset memory tag and can be rendered as fast as Ignition’s Vision or Perspective modules can draw the pixels. Any component in Ignition with a dataset property can simply be bound to the dataset tag with no fear of adding “analysis strain” to the Gateway.
Taking this a step further, displays and components can be developed using Ignition’s indirect tag path binding, meaning dashboards can be developed to allow seamless toggling between view modes. For example, a production line dashboard could be toggled between a “Day” view showing data for a full 24 hours, a “Shift” mode showing data for only an 8-hour shift, or a “Run” view that shows data for the most recent production run. As the view mode changes, the tag path directing the components to their corresponding datasets also change, updating instantly on the displays.
For example, consider a pie chart that shows how much time a machine spent in various states (Running, Unplanned Downtime, Blocked, Starved, Idle, etc.) across a particular timeframe. The dataset property for the pie chart could be bound as shown below, where a portion of the tag path is dictated by the currently selected view (Day, Shift, Run, etc.).
The dataset tag folders, if organized smartly, allow the above tag path to resolve to the appropriate data regardless of which view is selected. Further, switching between views is nearly instantaneous to the application user because, again, the data is already available for all views. The numbers have been crunched, all that’s left is rendering them on the dashboard.
It is important to consider that this “high availability” of data does come at some cost. In order to make sure the dataset tags are always up-to-date, the Ignition Gateway has to periodically perform the required analyses for each selectable timeframe. Integrators must consider the trade-offs between “high availability dashboard data” and “Gateway resource usage.” In some cases, it may make sense to run certain analyses less frequently or identify expensive analyses and run those only on demand.