Connecting two systems is often the most visible milestone in an integration project. A PLC value appears in Ignition, an API returns a successful response, or an MQTT subscriber receives its first message.
These are important milestones, but they establish only that communication works under the conditions tested. A successful data exchange is not the same thing as a reliable integration.
The Happy Path Is Only One Path
During initial development, integrations are frequently tested with both systems online, valid data available, and communication functioning normally. Under those conditions, even a relatively simple implementation can appear dependable.
Production environments introduce conditions that are less predictable. Network connections drop, services restart, databases become temporarily unavailable, and external systems return unexpected responses.
The important question is not whether these conditions can occur. It is how the application behaves when they do.
What Happens When Communication Fails?
Consider an application submitting a production result to a manufacturing execution system. The request reaches the server, but the connection fails before the acknowledgment returns.
From the application’s perspective, the result is uncertain. The server may have accepted the transaction, or the request may never have been processed.
Blindly retrying could create a duplicate transaction. Assuming success could allow production to continue without confirmation. Assuming failure could misrepresent a transaction that was actually completed.
A reliable implementation needs an appropriate strategy for resolving that uncertainty. Depending on the external system, this may involve transaction identifiers, idempotent requests, acknowledgment tracking, status queries, or operator-assisted recovery.
Reliability Requires More Than Reconnection
Automatically reconnecting to a service is useful, but restoring communication does not necessarily restore application consistency.
- Timeouts: Define how long an operation can wait before its result becomes uncertain or requires intervention.
- Retries: Determine which operations can safely be repeated and under what conditions.
- Data quality: Distinguish current, valid information from stale, missing, or uncertain values.
- Buffering: Decide whether information must be retained during an outage and how it will be delivered afterward.
- Observability: Provide enough status and diagnostic information to determine where an exchange failed.
- Recovery: Establish how the application returns to a consistent state after communication resumes.
Not every integration needs all of these mechanisms. A noncritical dashboard and a production traceability transaction have very different reliability requirements. The implementation should reflect the consequences of missing, delayed, or duplicated information.
Data Delivery and Data Meaning
Reliable communication also requires understanding what the receiving system is actually being told.
An MQTT message arriving successfully does not automatically establish that its contents represent the latest equipment state. Similarly, a successful database write does not guarantee that the correct production unit, workstation, or transaction was associated with the result.
Identifiers, timestamps, quality indicators, and clear message contracts help preserve meaning as information moves between systems. Delivery guarantees and application-level processing guarantees should also be treated as separate concerns.
Build for the Conditions That Matter
At No Ceilings, we approach industrial integration as more than establishing connectivity between endpoints. The behavior of the complete exchange matters, including what happens when one side is unavailable or the expected response never arrives.
Reliability does not require making every integration unnecessarily complicated. It requires identifying the realistic failure conditions, understanding their consequences, and implementing the appropriate safeguards.
A working integration moves information when everything goes right. A reliable integration has a defined way to handle the situations when it doesn’t.
Our Ship-to-Shore Data Integration and SIMATIC IT Work Instructions case studies illustrate different communication and integration challenges.