Purpose of the Checklist #
An industrial Ethernet topology in a warehouse carries more than routine information. It carries control traffic between programmable controllers and motor drives, status messages from barcode scanners and weigh scales, position updates from automated guided vehicles, and time-stamped event records that support root-cause analysis after an incident. Commissioning is the process of installing, configuring, and verifying that all of these services behave correctly under realistic conditions. Acceptance is the formal step in which the operator confirms that the installed network meets the criteria agreed before work began. This is not the same as documenting what was installed. Acceptance requires evidence that the network performs as intended, that the evidence can be reproduced, and that any deviation from the agreed baseline is visible to the people responsible for the system.
This article is written for warehouse operators, maintenance engineers, and controls teams. It is not a substitute for the manufacturer’s installation manual, the site’s own commissioning procedure, or the judgement of the competent engineer who holds responsibility for the installation. Safety-related network functions, such as the connection between a safety controller and its remote I/O, must be validated by the responsible party and subject to site lockout and permit requirements before any test work begins. The checklist below is a structured starting point, not a complete authority.
Pre-Commissioning Baseline and Documentation #
Commissioning should start with a clear description of the intended topology. That description is sometimes called an as-intended diagram, a network architecture drawing, or a point-to-point schedule. Without it, the commissioning team cannot distinguish a deliberate design choice from a wiring mistake.
The baseline documentation should include, at a minimum:
- A logical topology diagram showing switches, routers, wireless access points, controllers, and end devices.
- A physical cable schedule listing every wired link, its termination locations, and its intended use.
- A list of configured services such as virtual local area networks, quality-of-service markings, and redundancy protocols.
- Device names, IP addresses, and firmware or software revision numbers.
- The agreed acceptance criteria, including allowable packet loss, maximum failover time, and permitted clock offset between devices.
During commissioning, the team should mark every change to this baseline. It is common for an installer to add a temporary switch during commissioning and leave it in place after the commissioning engineer leaves. That temporary switch may not support the redundancy protocol used elsewhere and can silently break the resilient interface. The baseline document is the tool that helps the team notice that the installed topology no longer matches the intended topology.
Physical Layer Verification #
The physical layer is where warehouse networks fail most often during the first months of operation. Conveyors vibrate, fork trucks strike enclosures, patch leads are pulled tight, and dust accumulates on optical connectors. Commissioning is the time to verify that every cable was installed with sufficient margin, not merely that the link indicator lights up.
A link light only proves that two transceivers can negotiate a link speed. It does not prove that the cable is within specification. A marginal twisted-pair termination can pass link negotiation yet produce CRC errors and packet loss only when the cable warms up or when traffic crosses a specific part of the spectrum. A fiber connector that appears to work at low light levels can fail when the optical budget is reduced by a second dirty connection in the same path.
For each copper link, the commissioning engineer should record the cable test results, the measured length, and the actual link speed and duplex setting. For each fiber link, the optical light level should be recorded on both ends. These values become the reference for future troubleshooting. If a link is replaced six months later, the maintenance team can compare the new light level with the commissioning value rather than guessing whether the loss is acceptable.
Where cables pass through moving equipment, such as cable tracks on a shuttle or a lift carriage, the connector should be strain-relieved and the cable must have a service loop. A cable that is stretched during commissioning may not break immediately; it may fail weeks later after repeated flexing. The commissioning checklist should include a physical inspection of every enclosure, not just a scan of the switch port status page.
Switching, Redundancy, and Resilient Interfaces #
Once the physical layer is verified, the commissioning team should verify the logical configuration of each switch. This includes port VLAN assignment, port speed and duplex settings, spanning tree parameters, and the credentials and enable passwords stored for the device. It is not sufficient to configure a switch and then restart it once to confirm that the configuration persists. The device should be power-cycled intentionally during commissioning so that any missing start-up configuration or unauthorized default route becomes visible while the commissioning team is still on site.
Resilient interfaces in a warehouse typically take one of three forms: a ring of switches, a pair of switches connected by multiple links with a spanning tree protocol, or a wireless link that provides redundant connectivity to a moving vehicle. Each of these must be tested by simulating a failure and measuring the time to recovery. The test must be performed on the actual installed hardware, not assumed from the protocol specification.
It is important to measure failover time under realistic traffic. If the failover test is run while the network is idle, the failover may appear faster than it will be when the ring carries hundreds of time-synchronized messages per second. A useful test procedure is to generate sustained traffic across the redundant path while breaking the primary path, then observe whether any packets are lost and how long the loss window lasts. The acceptable loss window is defined by the application. A conveyor control system may tolerate a short interruption, while a vision system reading barcodes under motion may not.
The commissioning team should also verify that a redundancy event does not generate a broadcast storm when the network re-converges. The switch diagnostic log should be reviewed after the test for forwarding-loop messages or repeated topology change notifications.
Wireless Link Validation #
Wireless links in a warehouse are used for automated guided vehicles, hand-held scanners, and sometimes for temporary connections to mobile maintenance carts. Wireless is not a cable that happens to be invisible. It is a shared medium where coverage, interference, and client roaming all affect performance.
Commissioning a wireless link begins with a site survey, but the survey is not the acceptance test. The survey predicts performance; the acceptance test measures it. The commissioning team should verify that roaming between access points happens within the allowed time, that the client does not lose its association when moving through the transition area, and that throughput remains adequate when multiple devices are active on the same frequency band.
Observable symptoms of a weak wireless design include intermittent packet loss during material handling equipment movement, delayed scan events, and clients that remain associated to a distant access point instead of roaming to a closer one. Each of these symptoms can be caused by the client’s driver settings, by the access point configuration, or by the physical environment. A racking row filled with pallets of stored goods can change the RF environment enough that the access point placement that worked during an empty building fails in production.
The commissioning record should include a live throughput test, a roaming test along the actual vehicle path, and the measured signal strength at the edge of the coverage area. It should also record the wireless configuration baseline so that a later change, such as a new channel plan or a new access point firmware version, can be compared against the accepted condition.
Event Data and Time Alignment #
Warehouse automation depends on event data: when a barcode was read, when a pallet entered a zone, when a motor drive reported a fault, and when a safety device changed state. These events are generated by different devices and stored in different systems. If the clocks on those devices are not aligned, the sequence of events may appear incorrect even though each device recorded its own data accurately.
Time alignment is therefore not a detail; it is a functional requirement. The commissioning team should verify that every device on the network that generates a timestamped event uses a common time source or is sufficiently close to it. The acceptable offset depends on the application. For high-speed sortation systems, event interleaving may require millisecond-level alignment. For general warehouse monitoring, a few hundred milliseconds may be acceptable.
Observable symptoms of poor time alignment include:
- Events that appear out of chronological order when viewed from a central historian.
- A device that records the cause of an alarm occurring after the effect.
- Two devices that received the same input but recorded it at different times.
Evidence collection for time alignment is straightforward. The commissioning team can issue a common test event, such as a digital input triggered by a manual push-button, and compare the timestamps recorded by all devices that monitor that input. The differences between the timestamps are the observed time offsets. This test should be repeated after the time source has been restarted to confirm that devices re-synchronize automatically. A device that holds its last known time and never re-synchronizes is a maintenance risk even if it was correct when the time source was present.
Diagnostic Reference Table #
The following table is a practical reference for the commissioning team. It maps observable symptoms to likely causes, identifies the evidence to collect, and suggests an initial decision boundary. The decision boundary is not a final diagnosis; it is the point at which the team should continue within its scope or escalate to the responsible engineer.
| Observable Symptom | Likely Cause | Evidence to Collect | Initial Decision Boundary |
|---|---|---|---|
| One device drops off the network intermittently; other devices on the same switch are stable | Marginal patch lead, worn connector, or incorrect port configuration | Switch port counters, cable certifier result, port flapping log | Replace the patch lead and re-terminate the connector; if symptoms persist, escalate to installation engineer |
| Packet loss on wireless link only while an automated vehicle is moving | Coverage gap, antenna orientation, or roaming trigger misconfiguration | RF survey heat map, RSSI and retry counters, client roaming log | Reposition the antenna or access point; if no improvement, escalate to RF specialist |
| Events from two scanners interleave out of chronological order in the historian | Missing time source or misconfigured time zone offset | Device time sync status, NTP server reachability, manual test event timestamps | Correct time source configuration on the affected device; repeat alignment test |
| Ring failover exceeds the permitted window during a link break test | Non-redundant device added to ring, protocol parameter mismatch, or switch CPU overload | Protocol state table, failover log, CPU and memory utilization at the moment of break | Review ring configuration and remove non-participating devices; escalate if protocol states are inconsistent |
| Broadcast traffic spike immediately after a device reboot | Configuration mismatch causing a temporary forwarding loop | Spanning tree state, MAC address table, port discards, reboot time correlation | Isolate the affected downlink and verify port roles before restoring traffic |
The decision boundary column is important because it prevents a commissioning engineer from spending excessive time on a single unresolved fault. If the evidence is incomplete, the correct action is to collect more evidence or escalate, not to assume that the problem will clear itself during production.
Common Interpretation Errors #
Commissioning records are often misread later because the interpretation of the evidence was wrong at the time. Several interpretation errors appear consistently in warehouse networks.
The first is treating a single packet loss event as a failure of the link. Packet loss can be caused by a momentary broadcast storm, a switch reboot, or even a brief buffer overflow during a failover test. The acceptance
