Five Engineering Mistakes That Only Appear During Commissioning
Commissioning proves installation. Operational readiness proves behaviour. Most projects only do the first.
The machines arrived. The commissioning report was signed. The supplier's team flew home. And then the real problems began.
This pattern is so common it has become industry folklore: a plant that passes every commissioning test, yet fails within weeks of going live.
The problem is not the equipment. It is not the installation. It is the gap between what commissioning tests and what operations requires. Commissioning proves that everything is connected and functional. It does not prove that the system will behave predictably under operational stress, during maintenance, or when something changes.
What follows are five engineering mistakes that are almost invisible during commissioning — but become obvious the moment the operation depends on them. Each mistake is preventable. Each requires the right engineering discipline, the right diagnostics, and the right architecture.
1. The Assumption That "Green Means Right"
Green Status Confirms Communication, Not Correctness
A green status indicator confirms that a device is communicating. It does not confirm that the network is behaving correctly.
This is the most common commissioning mistake. Engineers look at a dashboard of green lights and declare the network healthy. The lights are green because the devices are responding to ping requests, because the links are up, because the control system shows no active alarms. But green means operational status, not operational correctness.
Consider what green does not reveal. It does not reveal that latency has increased by 20% since the morning. It does not reveal that jitter has become variable. It does not reveal that packet loss is accumulating. It does not reveal that a device is about to fail.
Commissioning tests are conducted under ideal conditions. The network is new. The load is low. The cables are properly terminated. The environment is controlled. Green means everything is working — right now.
Operations are not ideal. Cable degradation occurs. Load increases. Environmental conditions change. Devices age. Green today does not guarantee green tomorrow. But without a baseline, without diagnostics, without visibility into behaviour, the engineering team has no way of knowing what is changing.
The TT Perspective
Diagnostics and monitoring provide the visibility required to detect operational drift before it becomes failure.
They reveal the difference between green and right. Throughput's approach to network diagnostics ensures that engineers can establish baselines, monitor behaviour, and investigate anomalies before they become failures. Network Diagnostics & Monitoring explores this in depth.
2. The Boundary That Nobody Owns
Healthy Systems Can Still Fail at the Interface
A signalling system may be healthy. A communications network may be healthy. A control centre may be healthy. Yet the operation can still fail because the boundary between them behaves badly.
Commissioning tests individual systems. The signalling system is tested. The communications network is tested. The control centre is tested. Each passes. But the boundary between them is rarely tested as thoroughly. And the boundary is where failures often occur.
The cross-system problem is difficult to diagnose because responsibility is fragmented. The signalling engineer owns the signalling system. The network engineer owns the communications infrastructure. The control centre engineer owns the control platform. When something goes wrong at the boundary, each engineer investigates their own domain and finds no fault.
The fault exists in the relationship, but no one owns the relationship. This creates a classic accountability vacuum: suppliers point to contracts, liability ends at delivery, operators see the problems but lack authority to intervene, and founders defer to manuals that cannot answer back. The result is that troubleshooting becomes finger-pointing rather than investigation.
The problem is increasingly relevant as industrial networks become more interconnected and data-dependent. New regulations are explicitly addressing interoperability, data exchange, cybersecurity and the safe use of data in operational networks.
The TT Perspective
Cross-system failures require cross-system diagnostics.
Throughput's approach to network architecture and diagnostics ensures that the boundaries between systems are visible, maintainable, and engineered for behaviour — not just connectivity. Protocol conversion and network visibility become architectural disciplines rather than afterthoughts. Network Diagnostics & Monitoring and Industrial Ethernet Networks provide the engineering framework.
3. The Silent Failure of Media and Protocol Mismatch
A Cable That Is Mechanically Correct Can Still Be Electrically Wrong
A cable that is mechanically correct can still be electrically wrong.
Commissioning teams frequently encounter issues with mismatched communications speeds, incompatible media, and incorrect cabling. Serial links with incorrect baud rates, or 1000Base fiber ports connecting to 100Base media converters that are simply incompatible. The connection is physically possible, but it does not work.
Another example involves single-mode and multi-mode fiber mismatches that only surface during commissioning. The cables are terminated correctly. The connectors are clean. The link light is green. But the data does not flow. Similarly, RS-232 pinout issues — request-to-send and clear-to-send signals on the wrong pins — can prevent communication while the link appears physically intact.
These problems are often rooted in procurement and design decisions made years earlier. Engineering and procurement documents often do not address communications protocols, network speeds, connection types, and media conversion. The assumption is that "Ethernet is Ethernet" or "serial is serial" — but the reality is more complex.
The TT Perspective
Protocol conversion and media integration are architectural decisions, not afterthoughts.
Throughput's approach ensures that the boundary between serial and Ethernet, between copper and fibre, between different protocols and speeds, is engineered deliberately rather than discovered during commissioning. ATOP's serial-to-Ethernet and fibre conversion technologies, combined with ProSoft's protocol translation capabilities, provide the disciplined integration required to avoid these silent failures.
4. The IP Address Collision That Waits for the Spare
A Spare Device with a Default IP Address Is Not a Spare
A spare device with a default IP address is not a spare. It is a ticking time bomb.
Plants often include spare cabinets and equipped spaces for future expansion. These typically come with default IP addresses and are connected to the same network used by the active plant. The default addresses are often in the same subnet as active devices, creating network collisions that only appear when the spare is activated, or when traffic patterns change.
The collisions are often intermittent. A spare device with a conflicting IP address may not cause immediate problems because it is not actively communicating. But when it is powered on, when it is activated, or when network traffic reaches a certain threshold, the collision becomes apparent. The result can be loss of communication, incorrect data, or complete network failure.
Another common issue is identical subnets used on different sides of a router, causing confusion when traffic tries to cross the boundary. Engineering and procurement documents rarely address these scenarios because they assume that network configuration will be handled during commissioning. But by the time commissioning begins, the equipment is already installed, and the cost of reconfiguration is high.
The TT Perspective
Network architecture must anticipate the entire lifecycle of the installation, including future expansion.
Throughput's approach to network design ensures that addressing and subnetting are planned deliberately, with visibility and diagnostics that can detect collisions and configuration errors before they cause failures. Westermo's managed switches and network management capabilities provide the visibility required to identify and resolve IP conflicts before they impact operations.
5. The PLC That Only Knows Two States
The Missing Yellow Range of Diagnostics
The PLC recognises only two states: "working" or "not working" — green or red. The yellow range — information and warnings — is completely missing.
This is the fundamental limitation of most PLC-based diagnostics. The PLC monitors communication and reports when devices are functioning or not. It does not report when a device is degrading, when communication is becoming unreliable, or when a failure is imminent.
Consider a typical EtherNet/IP network. The PLC monitors each device's communication at the application level. If a device does not respond within the timeout period, the PLC declares it failed. But what happens before the timeout? The PLC may tolerate one or two missed telegrams without recording anything. The engineering team sees no issue — until the timeout is exceeded and the device is declared failed.
The PLC provides no early warning. It does not report telegram gaps, packet loss, or jitter. It does not report that a cable is degrading or that a connector is becoming intermittent. It does not report that a device is gradually becoming less reliable. By the time the PLC declares a failure, the failure has already occurred.
This is particularly problematic during commissioning. The engineering team may assume that the network is stable because the PLC reports everything is working. But the PLC is blind to the conditions that will eventually cause failure. The bathtub curve — high failure rates during early operation and end-of-life — is a normal pattern, but without visibility, the engineering team cannot distinguish normal early failures from systemic issues.
The TT Perspective
Diagnostics must go beyond the PLC's binary view.
Throughput's approach to network monitoring provides the visibility required to detect degradation before it becomes failure. By monitoring performance metrics, traffic patterns, and anomaly detection, engineers can establish baselines, identify drift, and investigate anomalies before they become failures. This is the difference between reactive troubleshooting and proactive maintenance. Network Diagnostics & Monitoring provides the engineering framework.
The Engineering Truth
Commissioning Is Valuable. But It Is Not Operational Readiness.
Commissioning is valuable. It proves that equipment is installed correctly and that systems are functional. But commissioning is not operational readiness.
It tests installation, not behaviour. It tests components, not relationships. It tests today, not tomorrow.
The five mistakes described here are all examples of the same underlying problem: a gap between what commissioning tests and what operations requires. The gap is invisible during commissioning because it exists in the assumptions that engineers make about the network, the systems, and the operation. It becomes visible only when those assumptions are tested by operational reality.
Good engineering does not stop at commissioning. It anticipates the conditions that commissioning does not test: degradation, change, failure, and the relationships between systems. It designs for behaviour, not just connectivity. It builds visibility into the architecture, not as an afterthought.
Great engineering produces a functioning network. Better engineering produces a network that continues functioning long after the original project team has left.
Connect with a Solutions Specialist
When commissioning ends and operations begin, the engineering question is whether the system will survive what commissioning could not test.
What assumptions are hiding in your commissioning process?