8.0 to 8.1 Upgrade Guide
This section details notes and advisories for users planning on upgrading from 8.0 to 8.1.
If upgrading to 8.1.33 or newer, be aware the bundled Java version for Ignition has been upgraded from Java 11 to Java 17. For most users, this upgrade will be seamless. However, users should check Java 17 combability with installed JDBC drivers and third party modules in case modifications are needed.
Changes to Be Aware Of​
Tag Historian Licensing​
In 8.1, the Tag Historian module licensing has been adjusted.
- Licensing for the full Tag History works identically to before. If you have a normal Tag Historian license, and are using the standard Tag Historian functionality, there are no changes.
- For customers with a Scale-Out architecture, the Tag Historian could be used on the front-end Gateways unlicensed. This would provide a message of "Partially licensed" on those Gateways, even though the configuration was an acceptable architecture with no need for additional licensing. In 8.1, we added the ability for the Tag Historian to be licensed for read-only operations, to eliminate that message. This is available for free for users upgrading from existing licenses 7.9 and 8.0 licenses that have Upgrade Protection by contacting your sales representative at Inductive Automation.
- A small set of customers use third-party modules that act as a storage engine for Ignition's Tag Historian. Previously, Inductive Automation did not require a Tag Historian license for a module to act as an engine for our Tag Historian (i.e. to use our API for storage and retrieval). Starting in 8.1, a Tag Historian license is needed in order for these modules to function. If you are using one of these modules in 7.9 or 8.0 and you have Upgrade Protection on your license, Inductive Automation will provide a free addition to your license, so no additional cost is required upon upgrade. If you have Upgrade Protection, Inductive Automation will attempt to auto detect if you're running one of these modules to update your license in our system automatically, so you would only need to click the refresh license button in your Ignition Gateway to pull in the change. Some third party modules cannot be auto detected, so call your sales representative if a third party historian module does not work on upgrade and you have an existing 7.9 or 8.0 license with Upgrade Protection, and we will add the necessary parameters to your license.
If your system is one of the few that uses third-party historian engine modules, it is highly advised that you review the system after upgrading to 8.1 and ensure the historian system is working as expected. If there are any issues with historian system after upgrade, and clicking refresh on your license hasn't resolved the issue, please contact your sales representative for assistance.
Gateway Scan of Project Directory​
As of 8.1, the Gateway scans the project directory every five minutes for changes. This is an important change for users that have a Version Control System with their Gateway. Previously in 8.0, the scan time was every 10 seconds, which proved to be resource intensive.
Users who want to change this scan rate back to the 10 second frequency can do so by placing the following system flag in the ignition.conf file:
-Dignition.projects.scanFrequency=10
JxBrowser Library Update​
We updated our bundled JxBrowser library from version 6 to version 7. For most users, this has no ramifications at all.
For users that have intentionally written scripts against the JxBrowser library, those scripts may have broken as a result of the update. Take a look at the JxBrowser migration guide for more details.
Gateway Authentication with Identity Providers​
In Ignition 8.1, Identity Providers are used to authenticate users on the gateway, whereas version 8.0 and prior used User Sources. To make the upgrade process seamless, your newly upgraded 8.1 gateway will create a new Ignition Identity Provider, and point it to the System User Source (under Gateway Settings prior to upgrade). For this to work, the Ignition Identity Provider needs to be able to view the list of users from the backing User Source.
In cases where Active Directory or Hybrid User Sources were set as the System User Source, you'll want to make sure that the list of users from the underlaying user source are available. Otherwise, some users may not be able to log into the gateway after upgrading. You can validate this before upgrading by viewing the Manage Users page. If one or more users are missing from the resulting list, then you'll want to refine how the user source builds that list. Based on the system's user source, you may need to check some settings:
- For Active Directory User Sources, it's a good idea to verify the User Search and User List filter settings on the User Source, making sure they're filtering on the criteria you expect.
- For Hybrid User Sources, the List Users from Active Directory will determine where the list of users is generated from. If the resulting user list is missing users, you may need to toggle this setting.
- For Database User Sources using the "Manual" Mode, make sure the List Users Query is able to return the users you'd expect. If, after upgrading, you're unable to log into the Gateway you can always perform a gateway password reset to troubleshoot any authentication issues.
Perspective Script Transforms​
Arrays in script transforms will now automatically be returned as valid JSON. This change technically modifies the value returned by the transform (i.e., potentially adding quotation marks around string elements), which may impact some existing bindings. If you're making use of Script Transforms that interact with arrays, then you may want to reexamine their configuration after upgrade.
Changes That Require User Action​
These changes will require manual action on the part of the system administrator/project author. In other words, these are features or situations that have a direct corresponding solution, but for various reasons cannot be automatically upgraded.
Redundancy Connection Configuration​
Redundancy communication is now accomplished through a Gateway Network connection between the master Gateway and the backup. This mechanism provides greater security and performance than the previous communication channel, but will require the system administrator to re-establish the connection.
The settings for the communication channel are still configured in the Gateway under Configure>Redundancy, and are still established from the Backup to the Master, but must be modified before the backup will successfully connect to the master after upgrade.
Replacement for the system.tag.browseConfiguration Function​
The Tags system in Ignition changed dramatically in Ignition 8, which makes the Ignition 7 function system.tag.browseConfiguration
obsolete. The function has been removed from the code base, so scripts using the old browseConfiguration function will break upon upgrade. The functionality has been replaced by system.tag.getConfiguration.
OPC UA Certificate Management​
Prior to Ignition 8, Ignition’s built-in OPC UA client implicitly trusted the certificate of any server it connected to, and Ignition’s built-in OPC UA server implicitly trusted the certificate of any client connecting to it. This is no longer true. New certificate management pages for the client and server have been added to the configuration section of the Gateway under “OPC UA > Security”. From this UI, trusted certificates can be imported and quarantined certificates can be marked as trusted. Ensuring the remote certificate is trusted, is required for all secured inbound and outbound connections.
On upgrade, all secured inbound and outbound connections other than the default “loopback” connection will be faulted until the remote certificate is explicitly marked as trusted.