Reliability and lifecycle management
Sustain dependable behaviour beyond the prototype: engineer for the mission profile, learn from the field and control components, software, suppliers and evidence through retirement.
After this module, you should be able to:
- Define reliability in measurable system terms
- Relate mission profile, stress and ageing to design decisions
- Control product configurations and lifecycle changes
- Use field evidence to improve continued reliability
Study guide · Updated · About 9 minutes reading + 20–30 minutes practice
Before you start: Read TEA-103, TEA-109 and TEA-110. Reliability claims need stated use and environmental conditions.
Reliability is performance over a stated time and environment.
A reliability claim is incomplete without the required function, operating duration, use profile, environment and acceptable probability of success. “Highly reliable” cannot guide design or verification.
| Concept | Useful distinction | Engineering consequence |
|---|---|---|
| Reliability | Probability of required operation for a stated time and conditions. | Needs a defined mission and measurable success criterion. |
| Availability | Readiness for use, including failure and restoration time. | Repair, restart, redundancy and service logistics matter. |
| Maintainability | Ability to restore or change the product correctly and efficiently. | Diagnostics, modularity, access, tools and instructions matter. |
| Safety | Freedom from unacceptable risk, including during failure. | A product may fail safely without remaining reliable. |
| Durability | Ability to resist wear, degradation and environmental stress. | Material, mechanical, thermal and component ageing require evidence. |
Prevent, tolerate and detect degradation.
| Design area | Reliability approach | Questions to answer |
|---|---|---|
| Components | Margins, derating, approved alternates and supplier controls. | Are ratings valid for real temperature, transients, tolerance and lifetime? |
| Thermal and mechanical | Manage heat, vibration, shock, ingress, fatigue and connector wear. | Where do stresses concentrate and how do they change with ageing? |
| Memory and storage | Budget endurance, retention, corruption detection and power-loss behaviour. | How often is data written and what happens at end of endurance? |
| Power | Handle brownout, surge, sequencing, battery ageing and reset. | Can partial power or repeated reset create latent corruption? |
| Software | Bound resources, detect stuck behaviour, preserve compatibility and recover. | What accumulates, wraps, leaks, wears or expires over long operation? |
| Diagnostics | Expose degradation before loss of required behaviour. | Are coverage, detection time, false alarms and service action defined? |
Reliability is a system property. A high-reliability component cannot compensate for thermal misuse, an uncontrolled write rate, poor connector design, ambiguous maintenance or software that exhausts a counter after years of operation.
Keep the fielded product known and supportable.
- Define the mission profile. Quantify use, loads, environments, storage, transport, maintenance and intended life.
- Allocate reliability objectives. Identify critical functions, failure criteria, margins and diagnostic needs.
- Analyse and test early. Use FMEA, stress analysis, tolerance analysis, accelerated tests and representative prototypes.
- Control production. Manage suppliers, processes, programming, calibration, screening and acceptance data.
- Track exact configurations. Connect hardware, software, bootloader, settings, calibration and service history.
- Learn from operation. Collect exposure and failure data, investigate root causes and trend precursors.
- Control change and obsolescence. Assess equivalence, risk, regression, stock strategy, support windows and migration.
- Plan retirement. Address final updates, data handling, credentials, spares, communication and safe disposal.
Worked example: non-volatile event log
A controller writes status to flash every second. The feature works during development but can exhaust the memory long before the intended ten-year life.
The revised design records state changes and faults rather than every unchanged sample, uses a journal with integrity checks and validates recovery after interrupted writes. Endurance calculations include worst-case event rates, high-temperature retention and margin for manufacturing variation.
Maintain a living reliability record.
Functions, duty cycles, environments, loads, storage, transport, maintenance and lifetime.
Objectives, allocations, analyses, tests, responsibilities, gates and acceptance criteria.
FMEA, margins, derating, tolerance, thermal, endurance and common-cause assessments.
Environmental, life, stress, robustness, recovery and accelerated-test evidence.
Released combinations, suppliers, changes, compatibility, calibration and service actions.
Exposure, incidents, returns, root cause, corrective action, trends and residual risk.
Common failure patterns
Reliability is judged from light laboratory use rather than lifetime cycles and field stresses.
A nominally equivalent replacement bypasses system-level impact and regression analysis.
Failure counts are tracked without units, hours or cycles, so rates and trends mislead.
Hardware, firmware, calibration and service history cannot be reconstructed for a field unit.
Start from a mission profile and failure definition
Describe expected operating hours, cycles, loads, temperatures, humidity, vibration, storage and maintenance. Reliability is meaningful only for defined conditions and a defined failure. A controller that remains powered but produces inaccurate measurements may have failed its intended function.
Distinguish reliability, availability and maintainability. Frequent recoverable resets can produce high apparent availability while interrupting important operations. Fast repair can improve availability without reducing the frequency of failure. Select measures that reflect the product outcome rather than choosing the most flattering number.
Analyse degradation mechanisms such as contact wear, solder fatigue, capacitor ageing, sensor drift and flash endurance. Accelerated testing needs a justified relationship between stress and the failure mechanism; excessive stress can create a failure mode that would not occur in the intended use.
Use field and test evidence with its limitations
A small test with no failures is evidence, but not proof of zero failure probability. State exposure, sample selection, operating conditions and statistical assumptions. Under an independent identical-trial model, the probability of zero failures is R raised to n, where R is per-trial reliability and n is the trial count. Real devices may violate independence through common design defects.
Classify field reports by symptom, configuration, severity and plausible mechanism. Preserve the distinction between confirmed product failures and incomplete reports. Analyse trends across board, firmware and supplier changes; mixing all versions can hide a concentrated issue.
Connect corrective action to verification and field monitoring. A new capacitor may address wear but change start-up current, and a retry fix may improve recovery while increasing energy use. Lifecycle decisions therefore require system impact analysis, not only a replacement part approval.
| Change | Revisit |
|---|---|
| Sensor replacement | Accuracy, timing, diagnostics and calibration. |
| Flash device replacement | Erase behaviour, endurance and interrupted updates. |
| Firmware recovery change | Operation continuity, timing and stored-state consistency. |
| Support retirement | Update access, key handling, data removal and user information. |
Keep the supported configuration knowable
Maintain a compatibility record for hardware, bootloader, application, configuration, calibration and service tools. Retain the ability to reproduce a released build and interpret its diagnostic records. A product that cannot be identified accurately cannot be targeted reliably for a field correction.
Plan obsolescence and support before supply or expertise disappears. Qualify alternatives, retain essential design knowledge and define how unsupported devices are handled. Decommissioning may require revoking credentials, removing sensitive data and leaving actuators or stored energy in an appropriate state.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Assess a zero-failure test claim
Thirty independently selected units each complete one defined mission with no failures. A report claims this proves 99% mission reliability with 95% confidence.
- Check the claim under an independent identical Bernoulli-trial model.
- Calculate approximately how many zero-failure trials would support that one-sided claim.
- Identify why repeated cycles on one unit may not be equivalent to independent units.
Show the worked answer
For a zero-failure demonstration, the one-sided 95% lower confidence bound under the stated model is 0.05 raised to the power 1/n. At n = 30, that is approximately 0.905, so the evidence does not support the stated 0.99 lower bound. Solving 0.99 raised to n ≤ 0.05 gives n ≥ 299 zero-failure trials.
This calculation does not establish that the trial model matches the product. Repeated cycles on one device can share manufacturing condition, wear and environment, while all units may share a systematic defect. Define representative missions and sample independence, include uncertainty and failure mechanisms, and choose the study design appropriate to the claim.
Review criteria
- The confidence statement and model are explicit.
- The arithmetic does not overstate the small test.
- Independence and representativeness are evaluated.
Check your understanding
Does quick automatic recovery prove reliability?
No. It may improve availability while the initiating failures remain frequent or interrupt essential outcomes.
Why include service tools in configuration control?
They can install software, alter calibration or interpret diagnostics. An incompatible tool can invalidate the supported product configuration.
Further learning
- NASA Systems Engineering HandbookLifecycle processes, technical risk, reliability, maintainability, configuration and product transition.
- NASA Software Engineering HandbookSoftware reliability, configuration management, measurement, maintenance and operational evidence.
- NASA Fault Management HandbookFault detection, isolation, response and recovery as contributors to dependable operation.
Reliability is engineered—and then continually maintained.
Long-lived embedded systems need a defined mission profile, controlled margins, known configurations, field learning and disciplined change from release through retirement.