# Failure Mode Coding: Shift-Level Diagnostic Playbook - Canonical: https://pearlgateway.net/docs/failure-mode-coding-shift-level-diagnostic-playbook/ - Updated: 2026-08-30T04:33:00+00:00 A failure mode code is not an administrative afterthought. It is a compressed record of a diagnostic decision made under shift conditions, often in the middle of a peak, with production pressure building behind you. When shift teams enter codes quickly, vaguely, or defensively, the entire reliability loop corrupts: planning cannot trust the data, spare parts stock the wrong items, repeat faults go unnoticed, and the same breakdown recurs next week. This playbook is written for the maintenance teams, controls engineers, and warehouse operators who live at the shift boundary. It explains how to observe symptoms, interpret what they actually mean, collect evidence that will survive the handover, and code failures in a way that makes the next shift — and the monthly reliability review — genuinely smarter. ## The Shift Boundary Is Where Codes Lose Their Meaning Breakdowns rarely announce themselves during the day shift when planning engineers are at their desks. They happen at 02:00, during a weekend sort, or in the middle of an automated storage and retrieval cycle. The person with the most direct access to the failed asset is the shift technician, and that technician is also the person under the most pressure to restore production. Code quality is a casualty of that pressure. The shift handover is the decisive moment. When the morning planner opens the work order from the night shift, they have exactly two sources of truth: the written code and the attached evidence. If the code says merely “conveyor fault,” the planner must guess whether that means a photoeye, a drive, a belt, or a jammed carton. Each guess sends the next technician in a different direction and costs another hour of runtime. To keep codes useful, every shift should consistently answer five questions before touching a work order: What asset stopped? What was observed at the moment of failure? What was measured before any repairs? What was changed or replaced? And what is still unknown? A code that captures those five items will remain meaningful after the shift is over. ## Agree on a Vocabulary Before the Failure Occurs The most common source of confusion is not sloppy observations; it is inconsistent vocabulary. One technician calls it a “conveyor motor fault,” another calls it an “overcurrent trip,” and a third calls it a “sheared shaft.” All three might be describing the same event from different angles, but the reliability database stores them as three different problems. Before a failure happens, the site reliability team should agree on a simple four-layer vocabulary. The **asset** is the specific machine or zone, for example conveyor 12 or sorter 3. The **component** is the physical part that failed, such as the tail pulley bearing or the photoeye lens. The **failure mode** is the physical manner of failure, such as seizure, fatigue, contamination, wear, misalignment, or open circuit. The **symptom** is what the operator or the PLC actually saw, such as an overcurrent trip, a missed divert, or a false empty-read. These four layers are distinct, but they are often collapsed into one line item in a hurry. The goal of a shift-level playbook is to make sure the code captures all four layers in separate fields, not mixed together. A useful sentence would be: conveyor 12, tail pulley bearing, seized, overcurrent trip on the VFD. That sentence is immediately actionable and historically comparable. ## Read the Operating Context Before You Touch the Machine The same symptom can point to completely different failure modes depending on the machine state at the moment of the event. A VFD overcurrent at cold startup on a Monday morning is not the same problem as a VFD overcurrent during a full-load merge at steady speed. A photoeye false signal during a changeover is not the same problem as a false signal during continuous high-speed flow. Before a technician resets the drive, clears the jam, or repositions a sensor, the operating context must be captured. What was the conveyor doing? Was it starting, accelerating, running at steady speed, decelerating, or stopped? How much load was on the line, and what kind of product was being handled — cartons, totes, pallets, or irregular items? Which upstream and downstream zones were running at the same time? Was a changeover or a new SKU introduced recently? This information evaporates the moment the machine is restarted. Once the drive resets and the belt moves, the load profile is gone, and the next shift will never know whether the fault occurred under normal conditions or under a one-time abnormal condition. The shift technician should write the context on the work order before pressing reset. It is a simple habit that converts a vague code into a diagnosis. ## Component Interaction on Typical Warehouse Assets Warehouse equipment is rarely a single machine. It is a chain of interacting components, and a failure in one component often surfaces as a symptom in another. A technician who codes only the reporting component will record the symptom, not the failure. On a conveyor system, the drive motor, gearbox, belt, pulleys, and photoeyes all interact. A seized idler bearing stalls the belt, the belt slips on the drive pulley, the VFD sees a sudden load change and trips on overcurrent. The HMI reports a drive fault. The damaged component is the bearing, not the motor or the VFD. Coding “VFD trip” is technically accurate but diagnostically empty. On a sorter, the divert mechanism depends on air pressure, solenoid response, carrier position, and upstream gap control. If a carton arrives late because the upstream photoeye is dirty, the sorter reports a missed divert, but the real failure is upstream signal integrity. Coding the sorter as the failed asset ignores the interaction. For automated storage and retrieval machines, positioning system errors can be caused by wheel wear, rail debris, loose encoder couplings, or load imbalance. The PLC will report a position deviation, but the shift team must ask which physical component could cause that deviation. The answer comes from interaction mapping — knowing that a load presented off-center to the shuttle will induce a false position error even when the encoder is healthy. When a shift team understands these interactions, they stop treating the machine’s error message as the final diagnosis. The error message is a symptom. The failure mode code is a conclusion about the physical component. ## Symptom-to-Failure-Mode Decision Table The table below is a practical shift-level guide. It helps the technician move from what the machine is telling them to which failure mode family deserves the provisional code, and what evidence confirms that decision before the code is locked in. Observed symptom on HMI / machine | Provisional failure mode family to code | Evidence to collect before coding | Avoid coding this if… Photoeye does not detect a product | Sensor contamination or misalignment | Clean the lens, check the bracket position, verify the photoeye output with a voltmeter while passing a test item | The blockage is consistent at one position — that points to a mechanical positioning fault, not the sensor VFD overcurrent trip on a conveyor | Mechanical seizure or jam at the load | Disengage the drive safely and turn the conveyor by hand; check belt tension and pulley rotation | The conveyor rotates freely by hand — the overcurrent likely has an electrical or control cause, not a jam Sorter divert misses the carton | Pneumatic or timing failure | Check line air pressure at the solenoid, confirm the solenoid actuates, verify the carrier position against the encoder count | The carton arrived late because upstream gap widened — code the upstream detection issue instead AS/RS position deviation on a cycle | Wheel/drive slip or positioning sensor drift | Run a slow manual move, compare encoder counts to a physical measurement, inspect wheels for flat spots or wear | The rail has debris or the load was off-center — these alter position without an encoder fault Merge blockage with no object present | PLC logic conflict or phantom sensor trigger | Replay the sequence from HMI logs, watch the sensor states at the exact moment of the blockage, check for a second sensor wired in the same string | The sensor physically held a product after the product departed — code mechanical jam or release, not logic The table purposefully separates symptom from provisional code. It forces the shift team to name the physical failure mode, not just repeat the machine’s error message. ## Collect Evidence Under Time Pressure Evidence collection is not theoretical. It happens while production waits, and everyone knows it. The discipline is to collect evidence that is already present and does not require extensive delay, before anything is disturbed. Three evidence buckets should be standard on every shift. The first bucket is **observations**: unusual noise, heat, smell, visible debris, product position, guard condition, and hydraulic or pneumatic fluid residue. Photos and short videos are acceptable and should be taken before repair work starts, not after. A timestamped photo of a sheared coupling is more persuasive than a description written later. The second bucket is **measurements**: current draw, voltage, temperature, air pressure, encoder counts, trip history on the drive, gap distances, and vibration readings if a meter is available. These numbers are the only objective bridge between the symptom and the failure mode. Without them, a code is a guess. The third bucket is **history**: when the last PM was performed, what the previous code on this asset was, whether the fault is intermittent, and whether a similar fault occurred on a sister conveyor or sorter. History converts an isolated event into a pattern. A shift technician may not have time to pull historical reports, but they should always write down whether this fault has happened before in their own memory or on the machine’s log screen. The guiding rule is simple: do not leave the work order with evidence only in memory. Memory is the first thing that fades in a shift handover. ## Interpretation Errors That Corrupt the Code Several recurring interpretation errors destroy the value of failure mode coding. Knowing them by name is the first defense against repeating them. The first error is **coding the sensor instead of the condition**. A photoeye blocked by a jammed carton is not a photoeye failure. The sensor worked correctly; the carton failed to move. The code should describe the jam or the jam source, not the sensor. Coding the sensor floods the spares forecast with unnecessary photoeyes and hides the real mechanical issue. The second error is **coding the safety device**. When a light curtain trips, the curtain did not fail; a person or an object entered a dangerous zone. Unless the curtain hardware itself is damaged, the correct failure code is the triggering condition, not the curtain. This is also the point where safety procedures are absolute. No shift team should ever attempt to bypass, mask, or defeat a safety device to simulate a failure or to keep a line running. Site lockout procedures, OEM documentation, and competent engineering judgment take priority over any diagnostic step in this playbook. The third error is **copying the previous code**. When the same conveyor faults twice in a week, the temptation to reuse the prior code is strong. But the second fault may have a different root. The prior code is context, not a diagnosis. Each event deserves its own evidence and its own conclusion. The fourth error is **coding the correction, not the failure**. If a technician retensions a belt and the line runs, the work order may read “belt tension adjusted.” But if the belt was loose because the idler bearing collapsed, the correct component is the bearing and the correct failure mode is seizure. A correction is not a diagnosis. The code must identify what failed, not what was done to make the machine run. The fifth error is **making the code fit the spare part in stock**. When a technician carries a spare VFD and installs it quickly, the paperwork frequently says “VFD replaced.” If the root was a seized motor ## Related Pearl Gateway Guides - [Failure Mode Coding: Data Signals and Condition Monitoring](/docs/failure-mode-coding-data-signals-and-condition-monitoring/) - [Critical Spare Parts: Data Signals and Condition Monitoring](/docs/critical-spare-parts-data-signals-and-condition-monitoring/) - [Lubrication Management: Data Signals and Condition Monitoring](/docs/lubrication-management-data-signals-and-condition-monitoring/) ## Site-Specific Review Worksheet This educational worksheet supports a structured review of failure mode coding: shift-level diagnostic playbook. 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.