Equipment connectivity
Device and PLC data paths, Kepware and OPC UA configuration, and application-side capture.
Service
IT/OT integration
Engineer the connections around production.
GTMI designs and implements interfaces between equipment, industrial applications and enterprise systems. We specify how transactions behave and who supports each connection.
For IT, OT, and application owners planning equipment connectivity or a production-to-enterprise interface.
- 01
Equipment
PLCs, devices, OPC UA
- 02
Industrial application
Execution and local records
- 03
Interface layer
Contracts, delivery, monitoring
- 04
Enterprise
ERP, quality, labels, APIs
A connection is scoped as an interface with named owners. Access to either system follows the client’s approval process.
What GTMI takes on
Architecture and implementation at the interface
An integration project defines how data or transactions move between named systems. GTMI can produce the architecture and interface specification, implement the connection, and prepare its operating model. The scope covers system ownership, network zones, authentication assumptions, data contracts, and deployment dependencies. Equipment, enterprise applications, and infrastructure remain under their respective owners’ control.
Enterprise transactions
ERP write-back, quality records, label requests, and API publication with defined request and response contracts.
Delivery behaviour
Transaction state, retries, reconciliation, and escalation matched to the permitted delay and integrity requirements.
Interface operations
Monitoring needs, support ownership, deployment dependencies, and procedures for investigating failed delivery.
The delivery work
Specify the transaction before building the connection
For each flow, GTMI documents the source of truth, payload, response, permitted delay, and treatment of incomplete or duplicate transactions. Developers and testers use that interface contract to build and check the connection. Equipment capture and an ERP posting have different timing and integrity requirements; we choose a delivery pattern for each. The specification lets system owners decide whether the flow requires an immediate response, permits queued delivery or needs a change at the receiving system. Security and quality reviewers can assess the proposed boundary before implementation starts.
Implement delivery and the operating controls
Work can include Kepware and OPC UA connectivity into Ignition, API interfaces, and enterprise write-back. Where the process permits delayed delivery, local records, outbox events, and workers can support queued transactions and retries. Where it does not, the design defines the required response and escalation. Test scenarios cover normal delivery, interruptions, recovery, and reconciliation. Monitoring and support procedures accompany the implemented flow.
Interface deliverables
- System and network boundary map
- Interface contracts and transaction rules
- Implemented connections with failure and recovery tests
- Monitoring requirements and support procedures
Platforms
- OPC UA
- Kepware
- MQTT and Sparkplug B
- Unified namespace
- ERP
- LIMS and QMS
- Labelling
Illustrative example: fictional manufacturing data
When a production posting times out
A completed fictional bracket order sends its quantity to an ERP. Delayed posting is permitted in this scenario. The receiver is assumed to support atomic duplicate detection and lookup by event ID.
| Field or rule | Contract extract |
|---|---|
| eventId | EV-DEMO-102: stable across delivery attempts |
| orderId | ORDER-DEMO-102 |
| quantity / unit | 12 / pieces |
| completedAt | 2030-04-04T01:00:00Z |
| Source record | Production application owns the completed quantity |
| Enterprise acceptance | ERP owns acceptance of the posting |
| Duplicate rule | Receiver atomically accepts an event ID once; a changed payload with the same ID needs investigation |
| Reconciliation | Lookup by event ID returns accepted, absent or unavailable |
| State | Meaning | Next action |
|---|---|---|
| Pending | Local record and outbox event committed together | Worker sends the event |
| Unknown | Response timed out; acceptance is uncertain | Look up the event ID at the receiver |
| Delivered | Acknowledgement or lookup confirms acceptance | Retain the receipt and attempt history |
| Needs review | Lookup unavailable or attempt limit reached | Support owner reconciles the event; automatic retry stops |
If lookup confirms acceptance, mark the event delivered. If it confirms absence, a bounded retry can use the same ID under the duplicate rule. An unavailable lookup leaves the outcome unknown. The retry limit in this sample contract is three attempts before review.
Proposed recovery check: lose the response after the receiver accepts the event, then reconcile its ID. The expected outcome is one posting and a recorded receipt. No test has been run in this example. The contract lets owners assess whether their receiver and production process support this design.
Working together
Architecture brief or interface build
Commission an interface specification for your team to implement, or engage GTMI to build and test the connection.
Architecture and specification
A reviewed integration design for your internal team or vendor to implement, with assumptions and approval needs documented.
Interface implementation
Build and test a defined connection, including its transaction handling, deployment instructions, and handover.
Where next
Define the engagement
Specify the interface you need
Tell us which systems need to exchange information and what happens when the connection fails. We can review the architecture, build a particular flow or repair an existing interface. A sample payload or system diagram can follow through an agreed sharing channel.