Reliability engineer Fred Schenkelberg makes an observation about manufacturers’ own data that is worth sitting with. Writing for Accendo Reliability, he notes that warranty and service systems exist for a different purpose than the one engineers want to use them for: “The databases and records are to help serve the customer and track costs, not to reveal reliability performance.”
That is the quiet problem behind most product development in equipment manufacturing. The design team’s only systematic view of how the last machine performed comes from a system built by finance to settle claims.
Key Takeaways
- Field data shows how a product behaves under real use, which test data cannot reproduce because it cannot anticipate every combination of stress and component variation.
- Warranty records were built to pay claims and track cost, so they are a poor and heavily filtered source of engineering insight.
- Machines that never fail carry as much design information as the ones that do, and warranty systems never see them.
- The feedback loop usually runs slower than the product cycle, so generation two is frozen before generation one has finished reporting.
Test Data Tells You What You Designed For
Validation testing answers a specific question: does the machine survive the conditions we decided to test it against? It is a necessary question and a narrow one.
Field data answers a different question. As Schenkelberg puts it, “It is a record of how the product performs for those using the product. All the expectations, stresses, and component variation are present.”
That last clause is the important one. A test rig applies the loads an engineer thought to apply. A customer applies the loads their business requires, on the surfaces they happen to have, at the duty cycle their schedule demands, maintained to whatever standard they maintain things to. No test plan reproduces that, because a test plan is a set of assumptions and the field is the check on those assumptions.
Your Best Field Data Is an Accounting System
Ask most manufacturers what they know about how the current product performs and the answer traces back to warranty claims and service calls.
Both are records of transactions. A warranty claim exists because someone wanted to be paid. A service ticket exists because someone was dispatched. Neither was designed to describe a failure mechanism, and neither is filled in by someone whose job is to help engineering.
The consequence is that the design team inherits a dataset optimised for cost control. It is usually accurate about what was spent and vague about what actually happened, and the fields an engineer would most want are the ones most likely to be left blank or filled in with whatever closes the ticket fastest.
What Warranty Data Quietly Leaves Out
Even where the records are clean, the sample is not the population.
Schenkelberg is explicit about the noise: “We do not know exactly when the first turn-on or use occurs after purchase. Nor do we know exactly and under what circumstances failure occurs.” A machine shipped in March and commissioned in September has six months of unrecorded life, so time-based analysis starts from a date that is not the real one.
Then there is everything the system never sees. Failures outside the warranty window, which is where the most interesting wear shows up. Failures the customer fixed themselves because it was quicker. Failures on machines the customer had already written off. And the units that ran without incident, which produce no record at all despite being the strongest evidence that a design decision was sound.
This is the same filtered view that makes warranty cost so difficult to control, discussed in how manufacturers reduce the cost of warranty claims.
The Machines That Never Fail Are Also Data
Design decisions are usually judged by what broke. The more useful comparison is between the units that broke and the units that did not, under the same conditions.
Runtime hours make that comparison possible. A component that fails at 1,200 hours in one fleet and runs past 6,000 in another is not simply unreliable, it is sensitive to something, and the difference between those two populations is the actual engineering finding.
Without hours, all you have is a count of failures against a count of units sold, which cannot distinguish a weak component from a machine being worked four times harder than anyone planned for. Those two problems have completely different fixes, and one of them is not an engineering problem at all.
The Loop Runs Slower Than the Product Cycle
There is a timing problem underneath all of this. Warranty evidence accumulates over the first year or two of a product’s life, gets analysed some time after that, and arrives at the design team when the successor has already been specified.
Schenkelberg’s own framing is pragmatic: “If it’s not possible to redesign or improve the current product, you can on the next design cycle.” True, and it is also an admission that the loop is slow.
Data reported by the machine as it runs compresses that. A pattern visible at eight months is a running change to the current product. The same pattern discovered at three years is a note in a requirements document for a machine that will ship in another two.
What to Instrument, and What to Ask
Useful engineering feedback does not require capturing everything. It requires capturing a few things consistently, on enough units to compare.
Accumulated runtime hours, so failures can be expressed against exposure rather than against calendar time. Electrical behaviour such as voltage and current, because degradation frequently shows there before it becomes a fault. Whether the machine is running at all, which separates a fleet in hard use from one sitting idle. And the conditions immediately preceding a fault, which is the part a service ticket almost never captures.
The questions worth putting to that data are equally few. Which failures cluster at a particular exposure? Which customers see them and which do not? Is the duty cycle we designed to the duty cycle the product actually sees? And the one that usually changes a specification: what is the difference between the hardest-worked fleet and the average?
Where ARMOR™ Fits
ARMOR™ was built to report from the machine rather than from the paperwork around it. ARMOR 4+™ wires into the equipment’s existing electrical system and reports runtime hours, voltage and current into ARMOR Asset Central™, so exposure and electrical behaviour are recorded continuously rather than reconstructed after a claim.
That gives engineering a population rather than a sample. Units that never failed are visible alongside units that did, and both carry hours, which is what makes the comparison meaningful.
The unit installs non-destructively on standard wiring harnesses with no bill-of-materials redesign, and ARMOR™ is not a replacement for the PLM or warranty systems already in place. How it is built in at the production stage is set out on the ARMOR™ for Equipment Manufacturers page.
Frequently Asked Questions
Will this tell us why a component failed?
Rarely on its own. Telemetry tells you the conditions and the exposure leading up to a failure, which is usually the missing context. The physical cause still comes from examining the part. The two together are far more useful than either alone.
How many connected units do we need before this is worth anything?
Fewer than most people assume for spotting a pattern, more than most assume for proving one. A handful of instrumented machines will show you that your duty cycle assumption was wrong. Establishing that a component is genuinely weak, rather than being worked hard in one fleet, needs a population large enough to compare.
We already collect fault codes. Is that not the same thing?
Fault codes tell you the machine reached a threshold someone defined in advance. They are silent about everything below that threshold, which is where gradual degradation lives, and they cannot tell you anything about the machines that never triggered one.
Does this replace validation testing?
No, and it should not. Testing is how you find problems before shipping. Field data is how you find out which of your assumptions were wrong. A manufacturer that stopped testing and relied on the field would be using its customers as the test rig.
See how ARMOR™ is built into equipment like yours, at the build stage. ARMOR™ for Equipment Manufacturers
