The engineer sees OPC-AE services in Ignition but receives no underlying alarm or event data. The visible service structure is not a working bridge: the described product state has no native path from legacy OPC-AE into OPC UA. Commission the interface as an external conversion architecture, and distinguish flattened UA data points from true OPC UA Alarms & Conditions before selecting the gateway.
Integration Boundary and Acceptance Criteria
Before anything else, confirm what the receiving application consumes. Legacy OPC-AE and OPC UA Alarms & Conditions are different alarm interfaces. A converter that publishes alarm attributes as ordinary UA data points may support logging but will not automatically provide native alarm subscriptions, condition state, acknowledgment behavior, or event semantics.
- Identify the source interface as legacy
OPC-AE, not OPC Data Access values or database records. - Ask each destination whether it requires OPC UA Alarms & Conditions or can consume ordinary OPC UA data points.
- List the required event properties: source, event time, message, category, priority or severity, state transitions, quality, and acknowledgment information.
- Define archival acceptance separately from live display acceptance. A screen showing current alarm values does not prove that every event transition reaches the database.
- Treat native Ignition support as unavailable until the installed release demonstrably provides the linkage. The status described was only a loose roadmap position after OPC UA
1.05, with no delivery date.
Do not equate OPC UA 1.05 with PubSub. They are orthogonal capabilities, and PubSub support had no stated schedule. The check before proceeding is a written interface requirement naming either “UA data points” or “UA Alarms & Conditions,” plus the event fields that must survive conversion.
Legacy OPC-AE Source Commissioning
Prove the source independently of Ignition and the conversion layer. OPC Classic alarming uses COM/DCOM technology, so a Windows-to-Linux design still needs a Windows-side component capable of establishing the legacy session. DCOM identity, access rights, host resolution, and firewall policy can prevent browsing or delivery even when the server name appears.
- Run a compatible test client in the source server’s supported Windows environment.
- Connect using the same service account and network path planned for the gateway.
- Browse the exposed event organization and confirm that event sources or categories are populated.
- Generate controlled alarm transitions at the source: activation, return to normal, and acknowledgment where the source supports acknowledgment.
- Record the source timestamps, messages, priorities or severities, and transition sequence for later comparison.
- Disconnect and reconnect the test client to expose account, startup, and DCOM activation problems before introducing another layer.
A successful browse is not enough. Do not move on until the client receives live events generated after subscription and their fields match the source system’s display.
Windows-to-Linux Conversion Gateway
Place the legacy-facing side of the gateway where COM/DCOM can operate, normally on Windows or in a supported Windows environment. Publish the converted result through OPC UA toward Linux and other clients. This contains the platform-specific dependency on the source side and uses the cross-platform protocol across the remaining boundary.
| Gateway output | Suitable use | Acceptance limitation |
|---|---|---|
| Ordinary OPC UA data points | Custom middleware, current-state display, or a logger designed around changing values | Does not by itself provide native UA alarm-condition semantics |
| OPC UA Alarms & Conditions | Clients requiring event subscriptions, condition state, or alarm-aware processing | Requires explicit mapping and a destination that supports the service |
| Direct database records | Long-term forensic retention and reporting | Does not provide a live OPC UA alarm interface to other clients |
Cogent DataHub was identified as a possible converter from OPC DA/A&E information to OPC UA data points. Validate that exact output against the acceptance criteria; a data-point conversion is not interchangeable with Alarms & Conditions.
- Connect the gateway to the proven
OPC-AEsource. - Subscribe to only the required event scope during the first test.
- Map one representative alarm completely before scaling the configuration.
- Expose the result through the required UA output mode.
- Restart the gateway and confirm automatic recovery without interactive login.
The commissioning check is one controlled source alarm appearing at the gateway output with the same source identity, message, timestamp, state, and priority or severity.
Alarm Semantic Mapping
Map event meaning, not merely text. A legacy event notification can represent a new condition, a change in an existing condition, a return to normal, or an acknowledgment. If every notification becomes only a Boolean or string tag, downstream software may lose the transition sequence needed for alarm analysis.
| Source information | Destination treatment | Verification |
|---|---|---|
| Alarm source | Preserve a stable asset or point identity | Two assets with the same message remain distinguishable |
| Source event time | Store separately from gateway receipt and database insertion time | Transport delay does not alter event chronology |
| Message and category | Retain the original values; add normalized fields separately | Forensic queries can recover the source representation |
| Priority or severity | Use a documented mapping table rather than an assumed one-to-one scale | Lowest and highest test priorities reach the intended destination classes |
| Active and normal transitions | Store each transition as an event | A short alarm produces both activation and return records |
| Acknowledgment | Preserve the action, time, and available actor identity | Acknowledgment is not mistaken for return to normal |
| Quality or diagnostic state | Carry it as a separate field | Bad communications cannot appear as a valid normal condition |
If the source and destination use different severity models, create a controlled mapping document and retain the unmodified source value. Do not move on until activation, normalization, and acknowledgment can be distinguished in the converted output.
Ignition OPC UA Client Ingestion
Configure Ignition only after the gateway output has passed an independent UA test. Service entries visible under a server folder do not prove that a provider is linked to alarm data. In the described configuration, those hooks did not implement an OPC-AE-to-UA bridge.
- Create the UA client connection to the conversion gateway using the endpoint and security settings approved for the project.
- Approve the client and server trust relationship on both sides where certificate trust is required.
- Confirm connection state before browsing or importing any items.
- If the gateway publishes data points, subscribe to the complete group representing one alarm, including identity, state, timestamp, message, and quality.
- If the gateway publishes Alarms & Conditions, verify that the chosen Ignition component and installed version can consume the required event service. Do not substitute a successful tag browse for that test.
- Force another controlled source event and compare its data with the independent gateway test.
The check is a live event traversing the source, converter, UA session, and Ignition without manual refresh. A connected session with static browsable nodes does not satisfy this gate.
Long-Term Alarm Archive Design
A retention requirement covering the life of an asset—approximately 70 years in this case—makes the external archive the durable system of record. SCADA replacements must not force alarm history through proprietary export and import paths. Store records in a database schema that can be migrated independently of the SCADA master station.
- Write append-only event records for activation, state change, return, acknowledgment, suppression, and communication-state changes that the source supplies.
- Store source event time, gateway receipt time, and database insertion time in separate columns.
- Retain the source system identity, alarm identity, original message, original category, original priority or severity, state, quality, and acknowledgment data.
- Add a deterministic duplicate-detection key or equivalent ingestion control so reconnects do not silently multiply records. Preserve duplicates flagged by the source when they are distinct source events.
- Document time-zone handling and clock authority. Test behavior across the site’s applicable clock changes.
- Export a sample, restore it into a clean database environment, and reconcile row counts and event ordering.
ODBC, a SQL Server linked server, or a PostgreSQL foreign-data wrapper can address database connectivity, but none converts OPC-AE semantics into OPC UA alarms. OLE DB is not directly accessible from Java, so do not make it an untested dependency in a Java-based integration path. The archive gate is a restore test that reproduces the complete controlled alarm sequence without querying the original SCADA system.
Cutover Diagnostics
Diagnose from the source outward. Changing multiple layers at once hides whether the failure belongs to DCOM, the converter, UA transport, semantic mapping, or database insertion.
| Symptom | Likely boundary | Decisive check |
|---|---|---|
| Service folders appear but contain no live event linkage | Unimplemented or unbound bridge function | Test the source with a native A&E client and use an external converter |
| Local Windows client works; remote gateway does not | DCOM identity, activation, name resolution, or firewall policy | Run the gateway account through the same remote connection test |
| UA connection works but alarm-aware client sees no conditions | Gateway publishes data points instead of Alarms & Conditions | Inspect the gateway output service type |
| Current state is correct but transitions are missing | State polling or incomplete event mapping | Generate a short activation-and-return sequence and compare event counts |
| Duplicate records appear after reconnect | Replay handling or database idempotency | Repeat a forced disconnect test and inspect event identity and timestamps |
| Database order differs from source order | Receipt time used as event time | Sort by preserved source timestamp and compare the recorded sequence |
Do not move on until each failure can be assigned to one boundary using an independent client, gateway diagnostic, UA client test, or database query.
End-to-End Verification
- Capture baseline counts in the source, gateway, UA consumer, and archive.
- Generate one alarm activation and confirm its source identity, message, source timestamp, priority or severity, active state, and quality at every layer.
- Return the alarm to normal and confirm a separate transition reaches every layer.
- Acknowledge the alarm where applicable and confirm that acknowledgment remains distinct from normalization.
- Interrupt the UA connection, generate controlled events if the source and gateway are designed to retain them, restore the connection, and document whether the events replay or require another recovery path.
- Restart the converter and receiving service. Confirm automatic reconnection and repeat the activation-to-archive test.
- Query the archive for the full sequence, compare event counts, and verify that source timestamps—not insertion order alone—reconstruct the chronology.
- Export and restore the test records, then repeat the count and field comparison against the source capture.
Accept the interface only when every required transition survives normal operation, reconnection, restart, archival query, and database restore.
FAQ
What happens if Ignition shows OPC-AE services but no alarms?
The visible services do not create the missing bridge. Prove the OPC-AE source independently, then place a conversion gateway between the legacy source and the UA client.
What happens if the converter exposes alarms as OPC UA tags?
The client can read mapped values, but it may not receive native OPC UA Alarms & Conditions behavior. Verify the destination requirement before accepting data-point conversion.
What happens if the OPC-AE server is on Windows and Ignition is on Linux?
Keep the COM/DCOM-facing connection in a supported Windows environment and publish OPC UA across the platform boundary. Test the gateway service account remotely before configuring the Linux-side client.
What happens if OPC UA 1.05 support is added?
That alone does not prove that legacy OPC-AE bridging, Alarms & Conditions consumption, or PubSub is present. Verify each required capability in the installed product release.
What happens if the archive looks correct before cutover?
Run activation, return, acknowledgment, connection interruption, service restart, export, and restore tests. Final acceptance requires matching counts, source timestamps, identities, states, and quality at every stage.