ReliabilityEngineeringFramework

A prototype proves that a design can work. Field-readiness is a different claim: that it will keep working, in the hands of someone who did not build it, for as long as it was sold to last.

Most field failures are not design errors in the ordinary sense. The circuit is correct. The firmware passes its tests. What was never established is the margin — how much heat, noise, supply disturbance, wear and time the design can absorb before behaviour changes. Margin is invisible on a bench at 25 °C with a short USB cable and a fresh battery.

This framework is a checklist for finding that margin before a customer does. It covers five groups of checks: thermal behaviour, electromagnetic compatibility, over-the-air update integrity, lifecycle stability, and power integrity as a cross-cutting concern. Each check is a question with a defined answer and a defined piece of evidence.

What this covers

Embedded electronic products with a microcontroller or SoC, firmware, a power supply and an enclosure, intended for continuous or unattended service — industrial controllers, telematics units, medical devices, metering, defence subsystems, connected consumer hardware.

What this does not cover

Functional specification and verification, which precede this. Formal safety certification, which follows it — this framework will make a certification audit less painful but is not a substitute for one. Software application-level testing. Production test and end-of-line fixtures, which are a separate discipline.

Work through the checks against one product, at one hardware revision, with one firmware build. Mark each item Pass, Fail or N/A. An item may only be marked Pass when the named evidence exists and someone can produce it — not when the team believes it would pass.

N/A is legitimate and should be used freely: a mains-powered fixed installation does not need battery calendar ageing; a device with no radio does not need WPC approval. Record why. Items marked N/A are removed from the denominator when the score is calculated, so an honest N/A costs nothing and an inaccurate one hides a gap.

Every item carries the gate at which it becomes mandatory. A gate is met only when every item assigned to it, and to all earlier gates, is Pass or N/A. This is deliberately strict: a gate that can be passed with open items is not a gate, it is a milestone.

Re-run the affected group after any change that alters the physical or electrical design — a new enclosure material, a component substitution, a different cable harness, a switching frequency change, a bootloader update. Reliability evidence is tied to a configuration, not to a product name.

The three gates correspond to decisions that cost money to reverse. Each one asks a different question, and the checks are distributed accordingly.

Heat is a rate multiplier for every other failure mechanism. It shortens electrolytic capacitor life, accelerates electromigration, shifts oscillator frequency, reduces flash retention and lowers the margin of every timing-critical circuit. The failures it causes rarely look thermal — they look like intermittent resets and unexplained drift in July.

• THM-01Prototype

  The operating envelope is written down

  Minimum and maximum ambient, humidity range, altitude, solar load, mounting orientation, enclosure material and whether the unit is in still air or forced convection. If this is not on paper and agreed with the customer, every thermal number that follows is an assumption.

  Evidence Environmental specification, signed off.

  PassFailN/A
• THM-02Prototype

  Components are derated at maximum ambient, not at 25 °C

  Every semiconductor, electrolytic, inductor and current-carrying passive checked against its derating curve at the top of the envelope. Regulators and MOSFETs lose current capability exactly when the enclosure is hottest, which is the same moment the load is highest.

  Evidence Derating table with part number, rating, applied stress and margin.

  PassFailN/A
• THM-03Pilot

  Internal temperature rise is measured, not estimated

  Thermocouples on the hottest parts and thermal imaging of the assembled unit, in its real enclosure, at maximum sustained load. Simulation is useful for comparing options and unreliable for absolute numbers once cables, potting and mounting are involved.

  Evidence Thermal images with a scale, plus logged thermocouple data.

  PassFailN/A
• THM-04Pilot

  Junction temperature budget is closed for the hottest three parts

  Measured case temperature plus θ_JC and dissipated power, compared against the absolute maximum with stated margin. Where a part has a die temperature sensor, cross-check the calculation against it.

  Evidence Junction temperature calculation sheet.

  PassFailN/A
• THM-05Pilot

  Cold start is verified at minimum temperature

  Crystal and oscillator startup, LCD response, battery internal resistance, electrolytic ESR and any mechanical actuator, all after a full soak at T_min — not after moving a warm unit into a cold chamber.

  Evidence Cold-start test log with soak duration recorded.

  PassFailN/A
• THM-06Pilot

  Over-temperature behaviour is defined and tested

  The device degrades predictably — reduces duty cycle, drops non-essential loads, raises an alarm — rather than entering a reset loop or silently producing wrong data. Define the thresholds, the hysteresis and what the user is told.

  Evidence Thermal derating state machine plus a chamber test that drives it.

  PassFailN/A
• THM-07Pilot

  Sensor accuracy is characterised across the temperature range

  Measurement drift over temperature is either within specification or compensated. Reference voltages, current shunts, load cells and analogue front ends all move; a device that reads correctly at 25 °C and 3 % high at 55 °C is a field problem that no one will diagnose as thermal.

  Evidence Accuracy-versus-temperature plot for each measurement channel.

  PassFailN/A
• THM-08Production

  Condensation and dew point are addressed

  Sealed enclosures that breathe through temperature cycles will accumulate water. Conformal coating, a membrane vent, or a design where no cold surface sits above the board. Coating alone does not solve it if connectors and test points are exposed.

  Evidence Damp heat cyclic test result, or a documented rationale for exclusion.

  PassFailN/A
• THM-09Production

  Soak test on the production configuration

  Continuous operation at maximum ambient and maximum duty for at least 72 hours, with functional output logged throughout. Run it on a unit built the way units will actually be built, including potting, coating and final gasket.

  Evidence Soak test log with the failure criteria stated in advance.

  PassFailN/A
• THM-10Production

  Thermal cycling exposes joint and connector weakness

  Cycling between the envelope extremes for a defined number of cycles, then electrical and functional retest. This is where solder joint cracking under heavy components, connector fretting and coefficient-of-expansion mismatches surface.

  Evidence Cycling profile, cycle count and post-test inspection report.

  PassFailN/A

EMC is decided at layout and mechanical design, then discovered in a chamber weeks before shipping. The checks below are weighted early for that reason. Immunity matters more than emissions for field reliability: emissions failures delay a launch, immunity failures cause returns.

• EMC-01Prototype

  Target standards and markets are fixed before layout

  Which emissions class, which immunity levels, which markets. An industrial Class A product and a residential Class B product are different designs, and a device destined for both is designed to the harder one from the start.

  Evidence Compliance plan listing standards, classes and target markets.

  PassFailN/A
• EMC-02Prototype

  Return paths are continuous under every fast signal

  Walk each high-speed net, clock and switching node and confirm an unbroken reference plane directly beneath it. Slots, splits and routing over plane gaps convert a working circuit into an antenna, and are almost impossible to fix after fabrication.

  Evidence Layout review checklist, signed by a reviewer who did not do the layout.

  PassFailN/A
• EMC-03Prototype

  Every cable entry has filtering and ESD protection at the boundary

  Protection placed where the cable meets the board, before the signal runs across the PCB. A TVS diode three centimetres inside the board has already let the transient couple into everything it passed.

  Evidence Interface schedule listing each connector pin and its protection.

  PassFailN/A
• EMC-04Prototype

  Performance criteria are agreed before test day

  Write down what counts as acceptable during an immunity test: no effect, temporary degradation with self-recovery, or degradation requiring intervention. Deciding this in the chamber, with the lab clock running, produces the answer the schedule wants.

  Evidence Performance criteria document with the monitored functions named.

  PassFailN/A
• EMC-05Pilot

  Shields and enclosures are bonded properly

  Cable shields terminated 360° at the connector shell, not through a pigtail wire. Enclosure sections bonded with short, wide, low-impedance connections. A pigtail is an inductor, and at 200 MHz it removes most of the benefit the shield was bought for.

  Evidence Mechanical drawing showing bonding points and shield termination.

  PassFailN/A
• EMC-06Pilot

  Pre-compliance emissions scan before design freeze

  Near-field probing plus a low-cost radiated scan to find the dominant emitters while the layout can still change. The aim is not a certificate, it is knowing whether the margin is 10 dB or 2 dB before committing to tooling.

  Evidence Pre-compliance scan plots with the peaks identified by source.

  PassFailN/A
• EMC-07Pilot

  ESD immunity to IEC 61000-4-2, contact and air

  Applied to every surface a human can touch, including connector shells, mounting screws, keypads and the seam between enclosure halves. Test with the device operating and monitored, and check that it recovers to a defined state rather than merely surviving.

  Evidence ESD test report with discharge points mapped on a photograph.

  PassFailN/A
• EMC-08Pilot

  EFT and surge on power and long signal lines

  Burst per IEC 61000-4-4 and surge per IEC 61000-4-5 at the levels the installation actually sees. Inductive loads switching on a shared supply — contactors, motors, solenoids — are the most common cause of resets that no one can reproduce.

  Evidence Test report with levels, coupling method and observed behaviour.

  PassFailN/A
• EMC-09Production

  Radiated immunity with the device functionally monitored

  IEC 61000-4-3 across the frequency range, with the product doing its real job and its output observed continuously. A device that is powered but idle will pass tests that a device doing ADC conversions will fail.

  Evidence Accredited lab report plus the monitoring log.

  PassFailN/A
• EMC-10Production

  Conducted and radiated emissions with the real supply and real cables

  CISPR 32 / EN 55032 or the applicable equivalent, tested with the power adapter, harness and accessories that will actually ship. A different adapter is a different product as far as emissions are concerned.

  Evidence Accredited test report naming the exact accessories used.

  PassFailN/A
• EMC-11Production

  The cable harness specification is frozen and controlled

  Length, shielding, twisting, ferrite position and connector type all recorded in a drawing, because the compliance result is only valid for the harness that was tested. Purchasing substituting an unshielded cable to save cost invalidates the certificate.

  Evidence Controlled harness drawing referenced from the test report.

  PassFailN/A
• EMC-12Production

  Radio and market approvals are complete

  For India, BIS registration where the product category requires it and WPC ETA for any radio. For export, FCC, CE-RED or the relevant regional equivalent. Confirm whether the module's existing approval carries over to your product or needs a host declaration.

  Evidence Certificates and, for modular approvals, the host integration statement.

  PassFailN/A

An update mechanism is the only part of a product that can turn a software mistake into a hardware recall. It is also the only thing standing between a fleet and a permanent defect. Both facts argue for treating it as a reliability subsystem in its own right, designed before the first release rather than added at the first bug.

• OTA-01Prototype

  What is updatable and what is not, stated explicitly

  Application firmware, bootloader, radio stack, FPGA image, configuration, certificates. Anything that cannot be updated in the field is a permanent design decision and should be recognised as one now, not discovered later.

  Evidence Update scope table listing every updatable component and its mechanism.

  PassFailN/A
• OTA-02Prototype

  Dual-bank layout with automatic rollback

  The new image is written to an inactive bank, verified, then activated; if it fails to confirm health within a defined window, the bootloader reverts. Memory for two images plus scratch must be budgeted at the part-selection stage, not found later.

  Evidence Flash memory map and bootloader state diagram.

  PassFailN/A
• OTA-03Pilot

  Power loss at any point leaves a bootable device

  Interrupt power during download, during write, during verification, during the bank switch and during first boot of the new image. Repeat several hundred times with randomised timing. This is the single highest-value test in the whole framework.

  Evidence Automated power-cut test report with iteration count and failures.

  PassFailN/A
• OTA-04Pilot

  Image authenticity is verified before activation

  Cryptographic signature checked by the bootloader against a key in immutable storage. A checksum detects corruption; it does not establish that the image came from you. Where the threat model requires it, extend to a full secure boot chain.

  Evidence Signing and verification design note, plus a negative test with a tampered image.

  PassFailN/A
• OTA-05Pilot

  Signing keys have custody, backup and rotation defined

  Who holds the private key, where the backup is, what happens when that person leaves, and how a key is rotated across a deployed fleet. A lost signing key with no rotation path means the fleet can never be updated again.

  Evidence Key management procedure with named custodians.

  PassFailN/A
• OTA-06Pilot

  Transfers resume over poor links and respect a data budget

  Tested at the worst signal quality the deployment will see, with drops mid-transfer. Delta updates where bandwidth is metered. A 4 MB image over a cellular link on a data plan costs money and time that the pilot will make visible.

  Evidence Degraded-link test results and the per-update data figure.

  PassFailN/A
• OTA-07Pilot

  A manual recovery path exists and is documented

  When OTA fails badly, someone needs to restore a unit without a return. A recovery mode, a serial or USB path, or a documented procedure a field technician can follow. Confirm it is physically reachable once the enclosure is sealed.

  Evidence Field recovery procedure, validated by someone outside the firmware team.

  PassFailN/A
• OTA-08Pilot

  The fleet inventory is accurate

  You can answer, for any moment, which firmware version and configuration each deployed unit is running. Without this, an update campaign is being aimed at a guess, and post-incident analysis has nothing to work from.

  Evidence Device inventory view showing version distribution.

  PassFailN/A
• OTA-09Production

  Rollouts are staged, with hold criteria and a kill switch

  A canary cohort first, defined success criteria and dwell time before widening, and the ability to stop a campaign immediately. Sizing matters: the canary must be large enough to reveal a problem and small enough that the problem is survivable.

  Evidence Rollout procedure with cohort sizes and stop conditions.

  PassFailN/A
• OTA-10Production

  Telemetry can detect a bad release within one cohort

  Boot success rate, crash and watchdog counts, connectivity retention and a small number of functional health indicators, reported per firmware version. If the only signal that a release is bad is a customer phone call, the staged rollout achieves nothing.

  Evidence Health metric list and the dashboard used during a campaign.

  PassFailN/A
• OTA-11Production

  Updates are tested from the oldest version still in the field

  Not only from the previous release. Units come back online after months offline, and the migration path from an old configuration schema or an old bootloader is exactly where update code breaks.

  Evidence Update matrix showing tested source versions against the target.

  PassFailN/A
• OTA-12Production

  Downgrade policy and anti-rollback are decided

  Whether a device may be moved to an older version, and whether a version counter blocks reverting past a security fix. These two requirements conflict, and the resolution should be a deliberate decision rather than an accident of implementation.

  Evidence Written downgrade policy with the security rationale.

  PassFailN/A

Everything in the product wears out on a schedule. The question is whether that schedule is longer than the service life you sold, and whether you will still be able to build, support and re-certify the product across it. These failures arrive years after the design team has moved on, which is precisely why they need to be written down now.

• LFC-01Prototype

  The BOM is scored for lifecycle risk

  Every line marked with lifecycle status, sourcing count, lead time and whether the manufacturer publishes a longevity commitment. Parts already flagged NRND at design time will be unbuyable before the product's second production run.

  Evidence Risk-scored BOM with a dated source for each status.

  PassFailN/A
• LFC-02Prototype

  Flash endurance is budgeted against service life

  Writes per day multiplied by the intended life, compared to the endurance rating with wear levelling accounted for. Logging every reading to internal flash is the usual way a five-year product becomes an eighteen-month product.

  Evidence Write-endurance calculation with the assumed write pattern stated.

  PassFailN/A
• LFC-03Prototype

  Builds are reproducible from source control

  Toolchain version, dependencies and build environment pinned and archived, so that building from a release tag five years from now produces the shipped binary. Without this, a small field fix requires re-qualifying an entire rebuilt image.

  Evidence A rebuild from tag whose output matches the archived release binary.

  PassFailN/A
• LFC-04Prototype

  Hardware revisions are traceable

  Each board revision tied to a BOM, a fabrication package, a change record and the units built from it. When a failure pattern appears in the field, the first question is which revision, and it must be answerable from records rather than memory.

  Evidence Revision register linking board rev to BOM rev, change reason and build lot.

  PassFailN/A
• LFC-05Pilot

  Critical single-source parts have an approved alternate

  Identified, footprint-compatible where possible, and ideally validated on at least one build. The parts worth this effort are the ones whose absence stops the line: the SoC, the regulator, the connector, the display.

  Evidence Approved alternates list, with test results where an alternate was built.

  PassFailN/A
• LFC-06Pilot

  Electrolytic capacitor life is calculated at operating temperature

  Rated hours adjusted for the actual temperature the part sees — roughly halving for every 10 °C above the rating point, and also affected by ripple current. A 2000-hour capacitor near a hot regulator is a scheduled failure, not a random one.

  Evidence Capacitor life calculation using measured local temperature.

  PassFailN/A
• LFC-07Pilot

  Battery cycle life, calendar ageing and end-of-life behaviour

  Capacity at end of life rather than at delivery, behaviour when the pack degrades, and the transport and storage constraints that come with the chemistry. State what the product does when the battery can no longer hold the design margin.

  Evidence Battery life budget plus the end-of-life functional definition.

  PassFailN/A
• LFC-08Pilot

  Mechanical wear items are counted against expected use

  Connector mating cycles, relay and switch operations, membrane keypad presses, hinge cycles, fan hours. Each has a rated life; compare it to how often the product will actually be opened, switched or serviced.

  Evidence Wear item table listing rated cycles against expected cycles.

  PassFailN/A
• LFC-09Production

  Vibration and shock to the real profile

  Tested to the profile the product will actually experience — vehicle mount, machine mount, handheld drop, transport packaging. Heavy components, tall electrolytics, unsupported connectors and unpotted modules are where it will show.

  Evidence Vibration and shock report with the profile justified against the use case.

  PassFailN/A
• LFC-10Production

  Ingress protection is verified on the production enclosure

  With the production gasket, the production cable glands, the production fasteners at the specified torque, and after the enclosure has been opened and reclosed the number of times a service visit requires. IP ratings degrade with reassembly.

  Evidence IP test report naming the sample build standard and reassembly count.

  PassFailN/A
• LFC-11Production

  Spares, repair and failure analysis are planned

  What is stocked, what is repairable, what is replaced whole, and how a returned unit gets analysed rather than swapped. Field failures are the highest-quality reliability data available; a process that discards them discards the data.

  Evidence Service plan including the failure analysis route back into engineering.

  PassFailN/A
• LFC-12Production

  Certification maintenance has an owner

  Which changes invalidate which certificate, who decides, who re-tests, and when certificates expire. A component substitution made by a purchasing team on a Friday can silently void a compliance claim that the sales team is still making on Monday.

  Evidence Change-impact procedure naming the certification owner.

  PassFailN/A

Power sits underneath all four groups above, which is why it is separated here rather than buried in one of them. A large share of field failures that get reported as firmware bugs are actually a supply that sagged, a rail that came up in the wrong order, or a write that was interrupted.

• PWR-01Prototype

  Reset supervision and a watchdog that cannot be starved

  A brown-out detector or external supervisor set above the minimum operating voltage, and a watchdog that is kicked only when the system is genuinely healthy — not from a timer interrupt that keeps running while the main loop is deadlocked.

  Evidence Watchdog design note plus a fault-injection test that proves it fires.

  PassFailN/A
• PWR-02Pilot

  Slow brown-out never leaves the device in an undefined state

  Ramp the supply down over seconds rather than switching it off, which is what a discharging battery or a failing adapter actually does. This is where partially powered logic drives outputs, corrupts memory or latches up.

  Evidence Brown-out sweep results with the observed behaviour at each threshold.

  PassFailN/A
• PWR-03Pilot

  Rail sequencing is correct on both power-up and power-down

  Multi-rail devices usually specify an order. Power-down sequencing is checked far less often than power-up and causes latch-up and back-powering through I/O pins when it is wrong.

  Evidence Oscilloscope captures of all rails at both transitions.

  PassFailN/A
• PWR-04Pilot

  Non-volatile writes survive power loss

  Configuration, calibration and logs written with journaling, dual-copy or an atomic commit, so an interruption mid-write leaves the previous good record intact. Test by cutting power during writes, repeatedly and at random offsets.

  Evidence Power-cut-during-write test log with iteration count.

  PassFailN/A
• PWR-05Pilot

  Inrush and hot-plug are within limits

  Measured inrush current at cold start and at the worst-case supply, checked against fuses, upstream supplies and connector ratings. Hot-plugging a load onto a live bus is a different and usually harsher event than a normal power-up.

  Evidence Inrush waveform capture with the peak value recorded.

  PassFailN/A

This checklist and a design FMEA answer different questions and work best together. The FMEA asks what could fail and what it would cause. The checklist asks whether the general mechanisms that cause most field failures have been examined at all.

Run the checklist first. It is faster, requires no facilitation, and its Fail items are excellent FMEA inputs — a failed check is a known weakness with an unquantified consequence, which is exactly what an FMEA session should be spending its time on. Then use the FMEA to establish severity, occurrence and detection for the ones that matter, and to find the failure modes specific to your design that no generic list could anticipate.

Where a formal safety standard applies, the relationship inverts: the standard's hazard analysis leads, and this checklist becomes supporting evidence that generic engineering diligence was applied. For IEC 61508, ISO 26262 or IEC 62304 work, treat the appendix mapping as an index into your existing safety case rather than a replacement for it.

A completed checklist is a claim. The evidence pack is what makes it auditable — by a customer's engineering team, by a certification body, or by your own team eighteen months later when a failure pattern appears and no one remembers what was tested.

Assemble it as a single indexed set, tied to a specific hardware revision and firmware version:

The checks are not a compliance route on their own. This table shows where each group intersects the standards most often encountered on critical-application products, as an index into the work rather than a substitute for the standard itself.

Scores below update as you mark items above. Each group score is the proportion of applicable items marked Pass; items marked N/A are excluded from the denominator. A gate is met only when every item at that gate and all earlier gates is Pass or N/A.

Marks are held in the page only and are cleared on reload — nothing is stored or transmitted. Use your browser's print or save-as-PDF to keep a record; the printed version renders as a blank tick-sheet suitable for a review meeting.