Connecting Ignition SCADA to Operational Intelligence: A Technical Walkthrough

Inductive Automation's Ignition platform has become the dominant SCADA choice for new North American manufacturing installations since roughly 2012. Its tag-based architecture, web-based Designer interface, and module ecosystem make it significantly more flexible than the Wonderware and Rockwell platforms it has displaced in many greenfield projects. For operational intelligence deployments, Ignition's built-in historian and OPC-UA server make it one of the easiest SCADA platforms to connect to an external analytics layer.

This article walks through the specific configuration steps for establishing a read-only connection from an Ignition installation to Relynk, and the OT security considerations at each step. The target audience is the engineer or systems integrator responsible for the SCADA-to-analytics connection, not the end-user.

Ignition's Relevant Data Access Points

Ignition exposes process data through several mechanisms. For operational intelligence use cases, three are relevant:

Creating a Read-Only Integration User in Ignition

The first security principle for any Ignition-to-analytics integration is principle of least privilege: the integration credential should have the minimum permissions required to read tag data. In Ignition, this is configured in the Gateway's Security Zones and Identity Providers section.

Step-by-step configuration:

1. Navigate to Gateway > Security > Users/Roles in the Ignition Gateway configuration interface.
2. Create a new user (e.g., "relynk-reader") with a strong password or certificate authentication. Do not reuse existing user credentials.
3. Create a new Role (e.g., "ExternalDataReader") with the following permissions: Tag Read access to the specific tag paths needed, Historical Data Read access if the historian is being queried, no Tag Write permissions, no Gateway configuration access.
4. Assign the new user to the ExternalDataReader role only.
5. In the OPC-UA server settings, configure client certificate authentication and require the Relynk OPC-UA client certificate to be trusted before the connection is accepted. This prevents unauthorized OPC-UA clients from connecting even with valid user credentials.

Network Topology for the Connection

The Ignition Gateway typically sits in the OT-DMZ or on a SCADA server in the Level 3 control network. The Relynk cloud connector is a lightweight process running in the IT network or cloud-adjacent zone. The connection traverses the OT-DMZ firewall.

The firewall rule required:

• Direction: Outbound from Ignition server to Relynk cloud endpoint (or inbound from Relynk connector to Ignition if the connector is in the IT network).
• Protocol: TCP
• Port: 4840 (OPC-UA) or 443 (HTTPS/REST API)
• Source IP: Ignition server IP
• Destination IP: Relynk cloud connector endpoint IP or range
• Authentication: Certificate-based (not username/password at the network level)

For OT security teams that require the connection to originate from inside the OT network rather than allowing inbound connections from the IT/cloud side, the Ignition OPC-UA server push model (where Ignition initiates the connection to the cloud collector endpoint) is the appropriate architecture. Relynk's cloud connector supports this pattern.

Tag Selection and Namespace Configuration

A critical step in the integration that is often skipped is explicit tag selection. When connecting an external analytics platform to Ignition's OPC-UA server, the default behavior is to expose the entire tag namespace. For a well-organized Ignition installation, this may be 500-5,000 tags. For a complex installation with many PLC drivers and legacy tag imports, it may be 50,000+ tags.

The operational and security recommendation is to create a dedicated tag folder in Ignition - for example, [RELYNK] at the root of the tag hierarchy - containing only the tags relevant to operational intelligence monitoring. Use tag references or tag bindings to populate this folder from the primary tag paths. The external integration accesses only the [RELYNK] folder.

This approach has two benefits: it prevents the analytics platform from browsing tags that contain control setpoints or safety system states (OT security requirement), and it makes the tag list auditable - a clear record of exactly which process values are being shared with the external system.

Historical Data Backfill for Baseline Building

Relynk requires 14-90 days of historical data to build statistical baselines for anomaly detection. For Ignition installations with an active historian, this is retrieved via the Ignition Historian REST API during the initial onboarding period.

The API call structure for historical tag data in Ignition uses the system.tag.queryTagHistory function, which accepts tag path, start time, end time, and aggregation mode. For operational intelligence use cases, raw or maximum aggregation at 1-minute intervals is appropriate for the backfill. The returned time-series data includes timestamp, value, and quality code.

One practical note on Ignition historian quality codes: Ignition uses the OPC quality code standard (0 = Bad, 64 = Uncertain, 192 = Good). Values with quality code lower than 192 should be excluded from baseline calculations. Sensor values recorded during a PLC communication failure or sensor fault will carry a Bad quality code and should not contribute to the statistical baseline.

Validating the Connection

After configuring the connection, validate it before presenting it to the OT security team for approval. The validation checklist:

• OPC-UA client certificate accepted by Ignition without manual administrator action required on each connection
• Tag browse returns only the [RELYNK] namespace, not the full gateway tag hierarchy
• Tag writes attempted from the analytics platform fail with permission error (not silently)
• Gateway configuration access attempted from the integration user account fails with permission error
• Historical backfill retrieves values with quality filtering applied (only Good quality codes)
• Connection termination (removing the firewall rule) does not cause any SCADA alarm or process disruption

The last validation point is important for the OT security review: demonstrating that terminating the external connection has no impact on SCADA operation is a required step in most OT security approval processes. As discussed in our article on getting OT security sign-off on SCADA integrations, the ability to terminate the connection immediately is a standard security team requirement.