Asset criticality ranking is routinely treated as an engineering deliverable completed once during project design and then filed away. In a warehouse environment, where throughput demands, control logic, and physical layouts change rapidly, that static ranking quickly becomes fiction. Commissioning and acceptance are the first and best opportunities to test a criticality ranking against real conditions: real motors, real sensors, real safety circuits, real operators, real product flow. The checklist in this article is intended as a structured prompt for warehouse operators, maintenance engineers, and controls teams to validate, challenge, and correct the criticality rankings assigned to their material handling systems before the facility is accepted as fully operational. It is not a substitute for site-specific acceptance procedures, lockout requirements, OEM documentation, or the judgment of competent engineers on site.
Purpose and Scope of This Checklist #
Commissioning verifies that equipment operates as designed; acceptance verifies that the site can operate and maintain it as designed. Asset criticality ranking falls into the second category. The purpose of this checklist is to confirm that each asset in the warehouse has a ranking that reflects the actual consequence of its failure, not the ranking inherited from a design review table. It also verifies that the supporting systems around each asset, such as control network infrastructure, power distribution, and condition monitoring tools, are considered part of the same functional asset when determining criticality.
The scope includes mechanical assets such as conveyors, sorters, palletizers, ASRS cranes, and dock doors, as well as electrical and control equipment such as variable frequency drives, programmable logic controllers, network switches, safety relays, and sensor systems. Support infrastructure that directly affects material flow, including air compressors, hydraulic power units, and battery charging stations, should also be included. Assets that are physically small but logically critical, like a single barcode scanner that gates an entire induction area, must be assessed with the same rigor as a large mechanical drive.
- Checklist prompt: Confirm that every asset included in the original criticality register is still physically present and has an assigned owner.
- Checklist prompt: Confirm that assets added during late-stage project changes have been ranked, not left as unclassified by default.
- Checklist prompt: Confirm that the criticality register distinguishes between operational consequence, safety consequence, and environmental or compliance consequence.
Operating Context and Asset Boundaries #
Criticality cannot be judged in isolation. A conveyor that is non-critical in a low-throughput manual warehouse can be the highest-impact asset in a fully automated high-density picking operation. The first step in the commissioning assessment is to define the operating context: shift patterns, throughput targets, product mix, seasonal peaks, buffer locations, and contractual service level agreements. That context determines how long a failure can be tolerated and which failure modes are most damaging.
Asset boundaries must be defined before ranking. A sorter, for example, is not just the mechanical track with cross-belts. It includes the induction conveyors, merge lanes, package detection sensors, barcode readers, programmable logic controller code, servo drives, pneumatic supply, safety light curtains, and operator control panels. A failure in any of these can stop the sorter as effectively as a seized bearing. The ranking should apply to the functional unit, and the components within that unit should share a documented dependency list.
Practical steps during commissioning include walking the physical asset boundary, reviewing the electrical and control drawings, and agreeing across the maintenance and operations teams which vendor interfaces belong to which asset. Disputes about whether a fault belongs to a conveyor or a control system become nearly impossible to resolve later if the boundary was never agreed during acceptance.
Inspection Design and Evidence Collection #
Criticality ranking is often based on assumptions about failure likelihood and repair time. Commissioning is the point at which those assumptions can be replaced with observed evidence. The inspection design should include mechanical condition checks, electrical and control response tests, and operational load tests. Evidence collected during commissioning becomes the baseline against which all future condition monitoring is compared, so it must be recorded carefully rather than noted informally.
Observable symptoms matter. A conveyor motor that operates normally at empty but runs hot under load is an important finding that should influence both the initial condition baseline and the criticality discussion. A sensor that occasionally fails to read a reflective label under certain lighting conditions is likewise significant. Record the environment, the load profile, the ambient temperature, and the exact operating mode when each reading was taken. A thermal image or a vibration reading taken without context is hard to act on later.
Evidence to collect during commissioning #
- Current draw and speed readings under steady-state and peak load for all major drives.
- Vibration signatures for rotating equipment such as motors, gearboxes, fans, and sorter spindles.
- Thermal readings of electrical panels, motor housings, and hydraulic power units.
- Control logic response times, including how quickly a stop command propagates and how quickly faults are reported.
- Cycle counts for moving mechanisms, including divert gates, lifts, and clamp devices.
- Operator and maintenance observations during the early break-in period.
The acceptance team should look for evidence that reveals hidden criticality. A failure that occurs only under peak load, or only when the warehouse is cold in the early morning, is easy to miss in a short acceptance window. If the commissioning schedule cannot cover all operating conditions, the relevant risk should be documented as a known limitation and the criticality register should reflect the uncertainty.
Failure Coding and Data Alignment #
A criticality ranking is only as good as the failure data behind it. Failure coding is the shared vocabulary used to describe what failed, how it failed, why it failed, and what the consequence was. Without a disciplined coding structure, the maintenance history becomes a collection of vague entries such as “conveyor stopped” or “fault found in panel.” Such entries cannot support repeat-fault reduction or informed revision of criticality rankings.
During commissioning, the maintenance and controls teams should agree on a failure coding taxonomy and verify that the computerized maintenance management system actually enforces it in the work order workflow. The taxonomy should include the asset identification, the failed component within the asset boundary, the failure mode, the physical cause, the detection method, and the operational consequence including downtime duration and whether product was damaged or service levels missed.
Example of useful coding: “Sorter unit: left merge photoelectric sensor: intermittent no-detect output: dust/lint on optics: detected by operator report: blocked induction lane for 24 minutes, throughput loss of 2,300 cartons.” This tells the maintenance planner which asset is involved, which specific part failed, how it failed, why it failed, how the failure was discovered, and what it actually cost the operation. That information feeds directly back into criticality analysis; a failure that is slow to detect may justify a higher criticality rating even if the physical damage is minor.
Commissioning is also the right time to verify that all parties use the same codes. Operators may describe a fault by its physical location, engineers by the affected component, and controls technicians by the alarm message. The acceptance process should include a small trial scenario where the same real or simulated failure is coded by all three groups to see how closely the results match.
Component Interactions and Consequence Propagation #
Criticality ranking is sometimes performed at the asset level without considering control system interdependencies. In a warehouse, this leads to systematic underestimation of low-cost components that sit at choke points in the control logic. A single prox sensor that verifies the presence of a carton before an induction gate opens may have a purchase price under one hundred dollars, but its failure can stop a sorter inlet, which starves the sorter, which stops downstream packing stations, which sends idle operators to other tasks and out-of-sequence pallet loads. The consequence of that sensor failure is functionally the same as a major mechanical breakdown in the sorter.
During commissioning, the controls team should produce a dependency map that shows which assets feed which, which control interlocks exist, and where single points of failure are buried. The map should include power and data paths, not only physical product paths. An uninterruptible power supply that feeds one critical controller is itself a criticality asset, despite being invisible in a conventional mechanical asset register.
Related practice is to simulate failure propagation during acceptance trials, within the scope authorized by the OEM and site safety rules. This can be done by observing what happens when an upstream sensor is blocked, when a downstream conveyor is
Practical Review Table #
| Review area | Evidence | Interpretation caution |
|---|---|---|
| Operating state | Mode, sequence step, mission and interlock status | Expected holds can resemble equipment faults. |
| Physical condition | Alignment, wear, contamination, obstruction and load condition | One visible defect may be a consequence rather than the cause. |
| Event history | Time-aligned alarms, input changes and recent interventions | Unaligned clocks can reverse the apparent event order. |
| Validation | Controlled test result under representative conditions | A single successful cycle does not establish long-term reliability. |
Apply this table to asset criticality ranking: commissioning and acceptance checklist using approved site procedures and documented evidence.
Related Pearl Gateway Guides #
Site-Specific Review Worksheet #
This educational worksheet supports a structured review of asset criticality ranking: commissioning and acceptance checklist. Begin by identifying the equipment boundary, control ownership, operating modes, material characteristics, upstream dependencies and downstream consequences. Record what the system is expected to do, what was actually observed and which evidence is time-aligned. Avoid changing several variables at once, because simultaneous changes make cause and effect difficult to establish.
Evidence to collect #
- Operating mode, active mission or route, and the exact sequence state.
- Alarm history, device state changes and controller timestamps.
- Physical observations such as alignment, contamination, wear, obstruction and load condition.
- Recent maintenance, software changes, parameter changes and recurring work orders.
- Upstream and downstream readiness, including blocked, starved and unavailable conditions.
Decision boundaries #
Use approved site procedures and competent engineering judgment before intervention. General information in the Maintenance & Reliability library cannot determine whether a specific machine is safe to enter, restart or modify. Preserve original settings, document authorized adjustments and establish a rollback point before controlled testing. When evidence conflicts, stop and resolve the timestamp, naming or measurement discrepancy before drawing a conclusion.
Closeout record #
A useful closeout record states the symptom, confirmed cause, evidence, corrective action, validation method, residual risk and follow-up owner. It should also identify whether the event exposed a design weakness, maintenance gap, training issue, spare-parts issue or monitoring blind spot. This turns a single recovery into reusable reliability knowledge without treating one observation as universal.
Evidence Matrix for Operational Review #
| Evidence group | Questions to answer | Why it matters |
|---|---|---|
| Sequence state | What mode, step, mission and interlock state were active? | Separates a physical problem from an expected control hold. |
| Material condition | Were load dimensions, orientation, stability and spacing within the intended envelope? | Explains faults that appear random when only controller data is reviewed. |
| Device evidence | Which inputs changed, in what order, and against which timestamp? | Supports repeatable diagnosis instead of component substitution by guesswork. |
| Change history | What maintenance, configuration, software or process change preceded the symptom? | Helps define a useful comparison window and rollback boundary. |
For asset criticality ranking: commissioning and acceptance checklist, the matrix should be completed with evidence from the same event window. Mixing observations from unrelated shifts can create a convincing but false causal story. If timestamps are inconsistent, establish which controller, server or operator record is authoritative before comparing event order.
Trend evidence is more useful when the measurement definition remains stable. Record units, sampling interval, filtering, equipment mode and product family. A rising fault count may reflect increased throughput rather than deteriorating equipment, while a stable count can hide deterioration if production volume has fallen.