Ignition Integration Architecture

availability

Feature availability by platform, plan type, and user type

Platform:	AvailableWebNot availableMobile
Plan Type:	Not availableBasicNot availableEssentialAvailablePremiumAvailableEnterprise
User Type:	Not availableRequesterNot availableFull UserAvailableAdministrator

The MaintainX® Ignition Module (referred to as the Ignition module) is built on a set of design principles and core services, with a security model designed for reliable tag data streaming.

Design Principles

Non-Intrusive Design

The Ignition module is designed to minimize its impact on your Ignition Gateway:

• Lightweight operation: The module uses minimal CPU and memory resources.
• Asynchronous processing: To avoid blocking your Gateway operations, the module processes tag value changes asynchronously.
• Independent thread pool: The module runs in its own thread pool, isolated from critical Gateway functions.
• Graceful error handling: If the module encounters an error, it doesn't crash your Gateway. Instead, it logs the error and attempts to recover.

Efficient Resource Usage

The Ignition module implements several mechanisms to ensure it doesn't overwhelm your Gateway or network:

• Tag limit: To prevent excessive resource consumption, the module limits tags to a maximum of 6,000 per connector and a total of 20,000 tags across all connectors. For more information, see Tag Limits.
• Smart filtering: The module reduces unnecessary data transmissions by applying time-based hysteresis and rate limiting. For a detailed explanation of how this filtering works, see Rate Limiting.
• Batch processing: To reduce network overhead, the module groups multiple tag updates together. For more information, see Batch Service.

Core Services

The Ignition module's architecture consists of three core services that work together to reliably and efficiently stream data from your Ignition Gateway to MaintainX.

Tag Subscription Service

The tag subscription service architecture ensures that each monitored tag has its own dedicated listener, which provides isolation and reliability. If one tag encounters an issue, it doesn't affect the monitoring of other tags.

The tag subscription service architecture, with a dedicated listener created for each new tag

Filtering Service

The filtering service reduces the volume of data transmitted while ensuring important changes are captured.

Smart filtering of new tag values before batching or discarding

For more information, see Tag Filtering.

Batch Service

The batch service approach balances timeliness with efficiency. It reduces the number of API calls while ensuring data reaches MaintainX in a timely manner.

Batch queueing of readings before they're sent to the MaintainX REST API

Security

Read-Only Access

The Ignition module operates in read-only mode. It subscribes to tag value changes but can't write back to any tags in your Ignition Gateway.

Secure Outbound Communication

The Ignition module communicates exclusively through secure, outbound HTTPS connections. No inbound connections or open ports are required on your network.

All communication to MaintainX's cloud infrastructure is initiated from within your network, which makes it easier to configure with your existing firewall rules.

Network requirements:

Parameter	Value
Protocol	HTTPS (TLS)
Direction	Outbound only
Destination URL	https://agent.maintainx.com/
Port	443

Token Authentication

Every request from the Ignition module to MaintainX is authenticated using the access token, which the module sends as a bearer token. The token is generated in MaintainX when you create a connector instance and is unique to that connector instance. MaintainX validates the token on every incoming request.

The token is displayed only once at creation time. If a token is lost or compromised, it can be revoked and replaced without affecting other connector instances. For instructions, see Revoke an Access Token.

Secure Token Storage

The authentication token used to connect to MaintainX is encrypted and stored securely in the internal Ignition database.

Minimal Access Required

The Ignition module only accesses the following:

• Your selected tag paths (read-only)
• Tag value updates (by subscribing to changes)
• Outbound network endpoints to securely transmit data to MaintainX

Rate Limiting

The Ignition module limits how much data it sends to MaintainX in two ways: caps on the number of connectors and tags it monitors, and filters that control how often it sends each tag's updates.

Tag Limits

To prevent excessive resource consumption, the module enforces the following limits:

• The module can connect to a maximum of 100 connectors.
• Each connector can subscribe to a maximum of 300 tag paths.
• Each connector can handle up to 6,000 tags.
• The module supports a maximum of 20,000 tags total across all connectors, subject to the per-connector limit.

For more information about adding tag paths, see Add Tags to the Ignition Module.

Tag Filtering

To manage tag updates efficiently, the Ignition module applies a combination of Time-Based Hysteresis and Token Bucket filters. These filters help reduce noise so the system isn't overwhelmed with too many updates. When a tag update is filtered, it isn't sent to MaintainX.

Time-Based Hysteresis

Time-Based Hysteresis filters out minor changes if the new value is within 1% of the last accepted value. It still allows an update if it's been at least 1 second since the last accepted value. This prevents jitter while ensuring periodic updates.

Example:

Time (ms)	New Value	Data Sent to MaintainX?
t = 0	100	✅ Yes
t = 100	100.5	❌ No, because this is a minor change (≤ 1%) that occurred within less than one second of the last accepted value.
t = 1000	100.5	✅ Yes, because one second or more has elapsed since the last accepted value.

Token Bucket Filtering

Token Bucket Filtering allows short bursts of five updates, then enforces a steady rate of one update per second. This ensures that the system can handle spikes in data and then smooths out the flow of updates.

Example:

Time (ms)	Tokens Left	Bucket refill Triggered	Data Sent to MaintainX?
t = init	5	N/A	N/A
t = 0	4	No	✅ Yes
t = 100	3	No	✅ Yes
t = 200	2	No	✅ Yes
t = 300	1	No	✅ Yes
t = 400	0	No	✅ Yes
t = 500	0	No	❌ No (rate limited)
t = 1000	0 → 1 → 0 (refill to 1, then consume 1)	Yes (1 token)	✅ Yes
t = 1100	0	No	❌ No (rate limited)
t = 5000	0 → 5 → 4 (refill to 5, then consume 1)	Yes (5 tokens)	✅ Yes