Ignition 8.3 Pro Tips: Achieve Better Industrial Data Management

Data is like water: a valuable resource that’s flowing all around you and whose proper management is essential. Without smart data management, an organization can end up with a dreaded data swamp from which it’s difficult to extract value and insights. On the other hand, when data is expertly managed, you get clear streams of information that help you make better decisions, boost efficiency, improve safety, save money, and more.

This blog is part one of a four-part series designed to help you make the most of 8.3 features. To kick off this series, we’ll explore powerful tools in Ignition 8.3 that help you achieve better industrial data management. Several of Inductive Automation’s Sales Engineers have offered their expert tips, insights, and use-case ideas for these tools, so that you can build control systems that brilliantly manage plant-floor data. And while these tips are exceptionally effective, they’re also surprisingly simple to do, because 8.3 does the hard parts for you.

Let’s get right into it.

Optimize Time-Series Data Management

Core Historian Tips

The new Industrial Historian Solution Suite in 8.3 offers multiple industrial historians to optimize how you store, analyze, and manage time-series data. One of these historians is the built-in Core Historian, which has native data aggregation, requires zero database configurations, and needs no maintenance. The Core Historian has up to eight times better write performance and 600 times better read performance than Ignition’s previous internal tag history provider.

“It’s the easiest historian to deploy with Ignition!” Inductive Automation Sales Engineer Adam Koch says. “You just configure a historical provider in the gateway and Ignition does all the work. No external connection is needed.”

Maggie Rosenkrans, another Sales Engineer here at IA, explains that “It’s a great use case for when you don’t want or can’t manage a relational database for reasons such as limited resources.” For example, if the cost of managing a relational database is prohibitive or you don’t have a database administrator on staff, the Core Historian could be a great choice for you.

SQL Historian Tips

Another historian within the suite is the SQL Historian, which is phenomenal for large-scale data storage. You can use it to seamlessly integrate Ignition with external SQL databases to create a high-performance historian. And it automatically supports compression, partitioning, interpolation, and data aggregation for any SQL database.

So what kind of organization would the SQL Historian be a good option for? Rosenkrans explains that it’s a great fit for those integrating with an existing database that was already set up for long-term data storage or is being managed by another entity within the organization (e.g., IT). And, Rosenkrans mentions, it’s a good choice when you want another platform to read the historical data through the database.

Additionally, Koch explains, “It’s ideal for separation of SCADA and historical data among different servers/computers. The SCADA server only needs the resources to run its operations and the database server can have all the necessary storage resources for long-term data.”

And IA Sales Engineer Brad Fischer adds that it’s also an easy way to implement recipe data management, allowing operators to load recipes and even commit changes to the database.

Tips For Additional Historian Tools

The Industrial Historian Module Suite also comes with a library of tools that help you leverage data sources (like CSV files and database tables) as read-only historians, plus a simulator, data splitter, and more.

According to Rosenkrans, “The simulator is great for proof of concepts where you want to demo visualizing historical data or test out a theory involving tag history without storing your own data.”

Data splitters are also especially handy in a number of situations. “They are useful for ensuring you have data duplicated, in case one database is unavailable for any reason,” Rosenkrans explains. Data splitters can also be used when you want to send data to a database that another Ignition gateway can connect to, in order to see historical data without using remote tag providers or remote historical providers.

To put things into context, Rosenkrans details a use case for data splitters. “Say you have a production database and an enterprise database that your production gateway can reach,” she says, “but you also have an enterprise gateway that you don’t want connecting to the production database. How can you store history to both databases without doing SQL replication on your side and make it so that the enterprise can still see the tag history you want it to see?” The answer, she explains, is that a tag history splitter can handle that data duplication for you (without needing to handle that from the database side) and you can make that database connection from the enterprise gateway only to the enterprise database.

Sponsored content by Inductive Automation