A failure mode library is a reusable, per-asset-class catalog of the ways a class of equipment can fail, each entry naming the failure mode, its mechanism, likely causes, effect, and how it is detected. You build it once for “centrifugal pump” or “gearbox,” then reuse it across every FMEA PM design, and CMMS failure code for every asset in that class.
The idea is to stop reinventing failure knowledge one machine at a time. Most plants rediscover the same pump failures in every analysis, every PM review, and every after-action meeting, because that knowledge lives in people’s heads instead of a shared catalog. A failure mode library captures it once and makes it the common source that feeds analysis, maintenance strategy, and failure coding. This guide covers what belongs in an entry, how to structure the library by asset class, how to build one without boiling the ocean, and how it feeds the work downstream.
What is a failure mode library?
It is a structured list of failure modes, organized by equipment class, that serves as the single reference for how those assets fail. A failure mode is a specific way function is lost, “impeller worn,” “seal leaking,” “bearing seized”, not the asset and not the whole event. The library holds one row per mode, with the supporting detail attached, and every pump in the plant inherits the pump-class list rather than starting from a blank page.
Think of it as the difference between tribal knowledge and an asset. When a 30-year millwright retires, the pump failures he carried in his head walk out the door unless someone wrote them down in a form the next person can use. The library is that form. It converts tribal knowledge into a durable catalog that survives turnover and gets better every time a new mode is found.
What goes in each library entry?
Each row describes one failure mode fully enough to be useful without the person who wrote it. A workable minimum is six fields: the mode (the observed loss of function), the mechanism (the physical process behind it), the likely causes the effect on production or safety, the detection method (what sign shows up first, and on which instrument), and the recommended maintenance strategy. That last column is what makes the library actionable rather than academic: it says whether this mode is best handled by scheduled replacement, a condition trigger, or run-to-failure.
Keep the mode, mechanism, and cause in separate fields, the way ISO 14224 insists. “Seal leaking” is the mode, “elastomer degradation” is the mechanism, and “chemical attack from the wrong sanitizer” is the cause. Collapsing them into one line is the classic data error, and it wrecks the library’s usefulness downstream, because FMEA and failure coding both need those layers apart.
How is a failure mode library organized?
By asset class, inheriting from the equipment hierarchy. Each class, pump, motor, gearbox, conveyor, valve, owns a list of modes, and every physical asset tagged to that class inherits the list. This is what makes the library reusable: you maintain one pump list, not one list per pump. When a new pump arrives, it starts fully populated with the class’s known failure modes on day one.
How do you build a failure mode library?
Start narrow, harvest from real sources, and grow it deliberately. The failed libraries are the ones someone tried to build complete and perfect on day one; the successful ones start on the worst-actor asset class and expand as failures teach them.
- Pick one critical asset class first. Choose the class driving the most downtime, usually pumps, motors, or conveyors. Rank candidates with an asset criticality matrix so you start where the payback is largest, not where it is easiest.
- Harvest modes from three sources. Pull from your own coded CMMS history (what has actually failed), from experienced technicians (what they have seen that never got logged), and from a published mode list for that equipment class as a checklist against blind spots.
- Write each mode with all six fields. Mode, mechanism, cause, effect, detection, strategy, and keep mode, mechanism, and cause separate. A row missing the detection or strategy field is a note, not a library entry.
- Tag each mode with a maintenance strategy. Decide, per mode, whether it warrants scheduled replacement, a condition-monitoring trigger, or run-to-failure. This is the decision the library exists to make repeatable, and it flows straight into the PM schedule.
- Wire it to the CMMS failure codes. The library’s mode list should be the same list technicians pick from at work-order close-out. One vocabulary, used in both places, so the history feeds the library and the library feeds the history.
- Review and grow it on a cadence. Every time a failure happens that is not in the library, add it. Review each class quarterly. A library that stops growing has quietly stopped matching the plant.
How does the library feed FMEA and PM design?
The library is the front end for both. An FMEA starts by listing failure modes, then scoring severity, occurrence, and detection, and the listing step is exactly what the library hands you pre-written. Instead of a team brainstorming modes from scratch in a meeting, they pull the class list and spend their time on the scoring and the actions, which is where the value is. The library also keeps FMEAs consistent: two pumps analyzed by two teams start from the same modes.
For PM design, the strategy column is the whole point. A mode marked “condition-based” becomes a monitoring route; one marked “scheduled replacement” becomes a calendar or runtime PM; one marked “run-to-failure” deliberately gets no PM and a stocked spare instead. The library turns the question “what PMs should this pump have?” from a debate into a lookup. And because the same modes feed failure-rate and MTBF tracking, you can see whether the strategy you chose is actually driving that mode’s failures down.
What makes a failure mode library go stale?
Three failure patterns kill libraries, and all three are avoidable. The first is building for completeness instead of use: a team spends six months importing an exhaustive taxonomy, the library becomes unmanageable, and nobody maintains it. Start small and let real failures drive growth. The second is orphaning it from the CMMS: if the library lives in a spreadsheet that has nothing to do with the failure codes technicians actually pick, the two vocabularies drift and the library slowly describes a plant that no longer exists.
The third is skipping the strategy column. A catalog of modes with no maintenance strategy attached is an encyclopedia, interesting but inert. The value is in the decision each entry drives, monitor, replace on schedule, or run to failure. Assign that strategy, revisit it when a mode’s failure rate refuses to fall, and the library stays a working tool. A good test: if your PM planners and your FMEA teams both open the same library when they sit down to work, it is alive. If only the person who built it ever opens it, it is already dead.
What the numbers say
- The reliability-data standard ISO 14224 defines the mode / mechanism / cause structure your library entries should follow, precisely so failure data can be shared and compared rather than stranded in one plant’s vocabulary (ISO 14224:2016, Collection and exchange of reliability and maintenance data for equipment). A library aligned to it is portable across sites and analyses.
- Matching strategy to mode, the library’s core job, is where the maintenance savings live: the U.S. Department of Energy’s FEMP O&M guidance, maintained by PNNL, reports condition-driven programs save 8–12% over preventive-only maintenance and can beat reactive operation by 30–40% (PNNL, O&M Best Practices: Maintenance Approaches). You cannot assign the right strategy to a mode you have never written down.
A failure mode library is how a plant stops relearning the same failures forever. Build it per asset class, six fields per mode, starting on your worst actor, and wire it to both your FMEAs and your CMMS codes so knowledge flows both ways. For the deepest single-component example to model your entries on, see bearing failure modes; for how the library plugs into analysis, read FMEA vs FMECA; and for the operator-ownership culture that keeps a library alive, total productive maintenance. A durable library is a reliability asset in its own right, the same theme as our equipment reliability guide and the floor-data work in the CLS case study.