The risk priority number (RPN) is Severity × Occurrence × Detection, each rated 1 to 10, and there is no universal score that should trigger a maintenance action. Under an “act above 100” cut-off, 23 of the 100 Severity 10 combinations are never flagged, and the AIAG-VDA 2019 handbook replaced RPN with Action Priority (AP). Use RPN, if at all, as a reporting number calculated alongside AP. Then turn the priority, or a remaining-useful-life (RUL) output, into action through criticality-tiered rules that create work orders in your CMMS, with thresholds set from a baseline on the specific machine.
How the risk priority number is calculated, and where it misleads
Each failure mode gets three ordinal ratings: Severity (1 means no effect, 10 means hazardous without warning), Occurrence, and Detection, where a high Detection score means the failure is hard to catch. Multiplying them gives a value between 1 and 1,000.
Donald Wheeler (Quality Digest, 2011) showed that the 1,000 possible rating combinations collapse into only 120 distinct RPN values, unevenly spread, with some values grouping up to 24 different problem descriptions and others just one. An RPN of 360 sounds moderate on a 1,000 scale, yet it outranks 862 of the 1,000 possible combinations.
Severity, Occurrence and Detection are ordinal: they say one rating is worse than another, not by how much, and multiplication is not defined for ordinal numbers. The result can be rank reversal, where a less serious failure mode gets a higher RPN than a more serious one. The maximum RPN a Severity 2 failure can reach is 200, while the minimum at Severity 10 is 10, so a frequent, undetected cosmetic defect can outrank a rare, detectable fatal one by a factor of twenty.
Worked example: a severity 9 failure under an RPN 100 cut-off
Take a failure with Severity 9 (safety or regulatory consequence), Occurrence 2 and Detection 2. The RPN is 9 × 2 × 2 = 36, well under a 100 threshold, so the rule says to ignore it. One AP guide rates the same combination Medium to High because Severity is 9.
Under the “act above RPN 100” rule, 23 of the 100 possible Severity 10 combinations fall below the threshold and are never flagged, and that proportion is a property of the arithmetic rather than of any particular process. The quick screen is to sort an existing FMEA worksheet by Severity instead of RPN: the rows at Severity 9 or 10 that sit below your action threshold are the exposed set.
What RPN score should trigger a maintenance action?
There is no universal RPN threshold; organisations set their own limits by risk tolerance and industry, and typical bands (mandatory action above 100, documented rationale between 80 and 100, review between 50 and 80) are common practice, not universal rules. Some companies add a Severity cutoff so that any 9 or 10 requires action regardless of RPN.
NIST (2014) notes that SAE J1739 warns the RPN should not be the sole metric for risk evaluation via thresholding. Accendo Reliability advises against RPN thresholds altogether, because management pressure on a cut-off turns scoring into a numbers game in which teams bias S, O and D to slip below the line; if a threshold is used at all, it should trigger a heightened level of review, not mandated action. Mid-range clustering makes this worse: many scores sit between 80 and 150, so a one-point shift in any factor moves an item across the threshold.
So “is there an acceptable RPN in FMEA?” has an honest answer. An acceptable decision exists, documented and defensible; an acceptable number does not.
Should we rank maintenance work by RPN or by Action Priority?
Rank by Action Priority, and report RPN alongside it only where a customer or quality agreement requires it. AP is a lookup, not a calculation: you rate S, O and D against the AIAG-VDA tables and read High, Medium or Low from the AP table, which looks at the actual combination rather than its product. Because the table is indexed rather than computed, it can encode rules a product cannot, and the one that matters most is that Severity 9 or 10 with Occurrence 4 or above is classified High irrespective of Detection. Other guides also put Severity first, and SAE J1739 (2021) uses the same High, Medium, Low structure.
AP also attaches a required action and a documentation level to each priority:
| AP level | Required action | Documentation |
|---|---|---|
| High | Identify and implement actions | Written justification, signed by the FMEA owner, if no action is taken |
| Medium | Action should be taken | Rationale recorded if not |
| Low | Action optional, monitor | Decision recorded |
Two cautions keep AP honest. A Low AP does not mean action should not be considered; it orders the work, it does not excuse it. And AP only changes how the three ratings are combined, so the rating work remains the substance of the FMEA. Rating inflation (scoring O and D low to avoid a High) is the fastest route to an FMEA that passes audit and fails in the field, and the countermeasures are calibration workshops, cross-functional reviews and a leadership posture that treats High items as information.
If you must still report RPN, calculate it alongside AP from the same ratings, never instead of it; where the two disagree, the disagreement comes from RPN’s threshold behaviour, not from a different assessment. Asset criticality, rated on factors such as downtime cost, redundancy, and safety and environmental impact, produces a prioritised list of machines to include in the condition monitoring programme.
How do we build a trustworthy baseline with little or no failure history?
Start from the machine you have, not the failure history you wish you had: take baseline readings during a period of known stable operation with the operating conditions recorded, use vibration standards as interim guard-rails rather than acceptance limits, and, where the question is RUL with too few fleet failures, start the degradation model from a known prior distribution that fleet data then updates.
TechnoLynx can help a reliability team define what a trustworthy baseline means in measurable terms (coverage of operating states, label quality from failure logs), choose between standards-based thresholds and an OEM or physics-informed prior for each asset class, build the data collection and labelling pipeline, and check the result against known failure events before it drives any work order. Our page on AI engineering for manufacturing and automotive sets out how we deliver this kind of reliability work on production lines.
Can ISO vibration standards stand in for our own baseline?
For a while, and only as guard-rails. ISO 20816-3:2022 defines evaluation zones A to D for industrial machinery, from newly commissioned machines (Zone A) to vibration severe enough to cause damage (Zone D). The standard itself says these zone boundaries are not acceptance specifications; they are guidelines for avoiding gross deficiencies, and particular machines can justify different boundaries.
ISO 20816-3 recommends setting the ALARM limit relative to a baseline for that machine and measurement position, higher than the baseline by 25% of the upper limit of Zone B, and not normally above 1.25 times that upper limit. Where no baseline exists yet, as with a new machine, the initial alarm comes from experience with similar machines or agreed acceptance values, and is adjusted once the steady-state baseline is established. A guide to ISO 17359 makes the same point more sharply: a drive at 80% of its own historical baseline is a very different risk from the same drive at 80% of a generic ISO 10816 limit.
For in-service machines with no records, ISO 17359 practice accepts a retroactive baseline: readings taken during known stable operation, ideally just after scheduled maintenance confirms good condition, with speed, load and temperature recorded alongside. The baseline stays valid as long as those operating conditions and the machine’s health at the time are documented. ISO 17359:2018 frames baselines the same way, as measurements taken at a predetermined set of operating conditions against which later readings are trended.
How long should collection run? We would judge a baseline trustworthy when it covers the machine’s normal operating envelope (its load and speed cycles, any seasonal duty change), not when a calendar period has elapsed. We would also use after-the-fact failure logs to label the readings preceding each logged failure as precursors, testing a threshold before it ever creates a work order.
Can an OEM degradation curve stand in for our failure history?
Yes, as a starting prior, provided the update rule is written down before the first prediction is acted on. Degradation models estimate RUL by predicting when a monitored signal will cross a predefined threshold, and MATLAB’s Predictive Maintenance Toolbox, for example, lets you configure an exponential degradation model with a known prior distribution on its parameters. That is where an OEM curve or a physics-informed model enters: as the prior the fleet data starts from.
The same toolbox documentation shows the other end of the spectrum. With no historical data, you set priors with very large variances so the model relies mostly on observed data, update it as measurements arrive, and, after a period at a steady operating point, save the current posterior as the new prior. That restart step is a ready-made, documentable update rule.
A review of Bayesian reliability methods notes that in most reliability applications engineers hold strong prior information on only one parameter, such as the Weibull shape, and shows how to combine it with a weakly informative prior on the rest; it also illustrates sensitivity analysis of the prior. We would present the OEM curve that way: one well-founded assumption, its variance stated, and a sensitivity check showing how much the maintenance plan moves if the assumption is wrong.
Three caveats belong in that conversation. Standards-based thresholds are generic and may not reflect this machine’s installation or load profile. OEM curves describe population-average behaviour, so a fleet outlier can be mismodelled until enough local data accumulates. And replacing the prior abruptly can swing every RUL estimate at once and destabilise the maintenance schedule; blending fleet data in gradually, with each threshold change recorded alongside its baseline, calculation method, approving engineer and effective date as that guide to ISO 17359 sets out, keeps each change auditable.
How do RPN scores or RUL predictions become work orders in our CMMS?
A risk score or RUL prediction only changes what technicians do once it is converted into a concrete trigger (a tier, a threshold, a ticket) that creates or queues a work order in the CMMS the crew already uses. In production AI reliability work, a dashboard is not the deliverable. Flat thresholds, applied equally to a critical chiller and a non-critical exhaust fan, are what produce alert fatigue.
Thresholds and escalation should follow the asset’s criticality tier rather than raw readings, with tighter rules on Tier 1 assets. Two to four thresholds per parameter is enough; more adds complexity without improving signal quality.
Tier-to-work-order rules at a glance
| Tier | Trigger example | What the CMMS does |
|---|---|---|
| Tier 1 (critical) | Critical threshold, or danger level at 250–300% of baseline | Work order created automatically with asset history, triggering readings and diagnostic steps |
| Tier 2 (advisory) | Advisory threshold, or alert level at 150–175% of baseline | Scheduled inspection task created; alert raises monitoring frequency, not shutdown |
| Tier 3 (monitoring) | Warning threshold | Reading logged for trend analysis, no work order |
High-confidence events auto-create a work order with priority, failure code and parts populated; medium-confidence events go to a planner’s review queue; low-confidence events log quietly. Those percentage bands come from one CMMS vendor’s guide to ISO 17359, and they are multiples of the machine’s own baseline, so they depend on the baseline work above being done first.
For an FMEA-driven programme, the bridge is simpler: link every High AP item into the Control Plan and reaction plan, so the detection control is something the plant executes rather than a row in a spreadsheet.
At what probability should a work order actually be generated?
We would set the threshold against cost and crew capacity, not against the probability alone. In the prognostics literature, a simple heuristic replaces a component when the predicted probability of failure before the next decision point exceeds a threshold, which earlier work set at the ratio of preventive to corrective replacement cost (cp/cc). Kamariotis et al. (2023) found the optimal threshold was smaller than cp/cc for all cost ratios studied, and that optimising it improved decisions. Tian and colleagues (PHM Society) likewise derive two-level failure-probability thresholds by minimising long-run replacement cost.
Two limits matter. With limited training data, the cost estimate is uncertain enough that a threshold optimised on past units may not be optimal for future ones. And relaxing the threshold too far risks corrective replacements, which hurts most when a single failure is expensive relative to a planned swap. A two-person crew adds a constraint the formulas ignore: if the threshold generates more Tier 1 tickets than the crew can close in a week, the threshold is wrong for that plant, however good the model.
The same authors argue that experienced engineers can usually make a rough estimate of preventive, corrective and unavailability costs, and that such estimates suffice for setting the policy.
What if the model gives a wide uncertainty range instead of a clean number?
Decide on probabilities, not point estimates, and write a fallback rule for the wide case before go-live. Where the band is too wide to trust at all, we would default to the conservative branch (schedule into the next planned shutdown, or escalate to an engineer) rather than let the asset fall back to doing nothing. Lower prediction uncertainty does translate into better maintenance decisions, so tightening the band is worth modelling effort.
Who signs off on acting early, and how are overrides logged?
We would name the approver in the threshold record itself. One vendor’s guide to ISO 17359 says each alarm threshold should carry the approving engineer’s identity, and AIAG-VDA requires a written justification for not acting on a High AP. We would mirror that for model-driven tickets: the planner confirms medium-confidence work, the reliability engineer owns the thresholds, and either can stop a ticket only with a reason recorded.
Record who overrode, the model output at the time, a reason code and the eventual finding, then review the log for systematic disagreement. When a “high-confidence” alert proves false three times in a row, the threshold needs recalibrating, not the technician’s trust. A separate question, how to tell when a calibrated threshold has stopped being valid because the model or operating conditions drifted, deserves its own protocol and its own trigger rules.
How do we stop technicians ignoring the model in favour of the calendar?
We would fold the prediction into the schedule rather than set it up as a rival to it. A 2026 study on synthetic multi-asset data found that integrated scheduling, combining calendar, usage and uncertain RUL information, outperformed single-trigger rules in that example, with the RUL-threshold and usage-only rules the least favourable. The result is illustrative rather than field-proven, so we would use the prediction to move calendar tasks earlier rather than ask technicians to abandon the calendar. We cover the operational side of this, getting vibration alerts into the scheduling and ticket process a crew actually uses, in wiring vibration alerts into work-order reality.
Should we pilot threshold-driven work orders on one line before rolling them out everywhere?
Yes. Pilot on a small, well-understood group of five to ten assets, track false-positive rate and average triage time, and expand only once the thresholds hold and planners trust the alerts. Test the threshold-to-work-order rules against synthetic alerts before real sensor data reaches them, and expect to adjust thresholds after the first month.
Decide the exit criteria before the pilot starts: what false-positive rate and triage time count as success, and who signs off on scaling. A successful pilot at one depot or line does not automatically transfer; if the next site runs a different asset mix or sees different failure modes, treat it as a new, shorter pilot rather than a copy.
The questions we would put to your team next are local: what a missed failure costs on your Tier 1 assets, how many tickets your crew can close, and how much fleet data it takes before your prior stops mattering.
FAQ
What are the steps of the FMEA process?
The AIAG-VDA FMEA Handbook (2019) introduced a seven-step methodology alongside its AP tables and harmonised rating criteria.
