Safety and reliability engineers
Connect hazards, failure mechanisms and lifecycle evidence so that risk controls remain effective in the real product and its operating environment.
After this module, you should be able to:
- Frame hazards and reliability objectives at system level
- Trace risk controls into architecture and verification
- Challenge independence, common causes and diagnostic assumptions
- Use field information to maintain the assurance case
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-106 and TEA-111. TEA-301 introduces functional-safety lifecycle concepts.
Safety and reliability are properties of operation.
The role examines how technical failures, misuse, environment, maintenance and external services can lead to harm or loss of function. It helps the team choose proportionate controls and assemble an argument that connects hazards to requirements, design features and evidence.
Keep the risk-control chain intact.
| Area | Question | Evidence |
|---|---|---|
| Hazard analysis | What conditions can cause harm, and through which sequences? | Hazard log and scenario analysis |
| Reliability model | Which failure mechanisms and mission profiles dominate? | FMEA/FMECA, fault tree or reliability model |
| Risk controls | What prevents, detects or limits each hazardous situation? | Safety requirements and allocation |
| Independence | Can one cause defeat both function and monitor? | Common-cause and independence analysis |
| Lifecycle feedback | How will complaints, incidents and drift revise assumptions? | Monitoring and escalation process |
Challenge diagnostic coverage
Ask which faults are detected, how quickly, under what operating conditions and by what independent means. A watchdog may detect lost execution but cannot prove that a plausible yet incorrect output has been identified.
Move continuously between scenarios and design.
- Define hazardous outcomes. Avoid starting with component failures alone.
- Build causal paths. Include software, users, environment and dependent services.
- Specify controls. State response time, independence and effectiveness.
- Allocate and trace. Connect controls to owners, interfaces and verification.
- Test assumptions. Inject faults and examine combinations and latent conditions.
- Monitor operation. Compare field evidence with predicted mechanisms and rates.
Worked hand-off: heater control
The safety engineer defines the hazardous over-temperature scenario and maximum safe response. Hardware provides an independent cut-off; firmware detects sensor plausibility and commands shutdown; systems engineering allocates timing; verification injects stuck sensors and failed outputs. Reliability analysis checks whether shared power or sensing defeats both layers.
Maintain a living assurance case.
Scenarios, causes, controls, status and residual risk.
Failure modes, dependencies, assumptions and mission profile.
Testable controls with ownership and traceability.
Independence, common causes and fault containment.
Analyses and tests that demonstrate control effectiveness.
Operational signals, trend thresholds and corrective action.
Common traps
Risk analysis is detached from design and change control.
Latent and common-cause failures are not examined.
A claimed diagnostic rate has no representative evidence.
Field data and product changes do not refresh the argument.
Keep hazards, failures and controls distinct
A failure analysis asks how an element can fail and what follows. A hazard analysis asks how harm can arise in the operating context, including combinations and foreseeable misuse. Use both directions to avoid missing a hazard that has no single obvious component failure.
Translate a risk control into a testable system requirement. Identify detection, response, timing, independence and recovery. Allocate the requirement through hardware, firmware and procedures, then verify that the realised control works under the conditions used in the risk argument.
Distinguish frequent recoverable faults from rare severe outcomes. Reliability data can inform analysis, but software systematic faults should not be assigned arbitrary random failure rates to make a calculation pass. Make the basis and limitations of every quantitative claim clear.
Challenge shared causes and optimistic diagnostics
A monitor that shares the faulty sensor, power rail or software assumption may not provide the claimed protection. Examine common causes, dependencies and the conditions under which diagnostics are disabled. Two channels can agree because both are wrong.
Diagnostic coverage requires a defined fault population and evidence about detection. It is not the percentage of test cases that passed. Detection time, test interval and behaviour between checks matter. A periodic test can leave a latent fault present until the next opportunity to detect it.
Work with cybersecurity engineers on faults an attacker may deliberately induce. An input flood, malicious configuration or blocked update can change the assumptions of a safety mechanism. Evaluate the physical consequence and the response together.
| Claim | Challenge |
|---|---|
| Independent protection | What common failure could defeat both paths? |
| Fault detected | Which manifestations remain plausible and invisible? |
| Safe shutdown | What stored energy or secondary hazard remains? |
| Automatic recovery | What proves the initiating condition is cleared? |
Maintain the argument through production and service
A risk control can be weakened by an unapproved substitute, calibration error, service bypass or unsupported update. Link the control to manufacturing and support requirements as well as design verification. Identify which assumptions must be communicated to installers and users.
Review field signals for changes in exposure or failure mechanism. A risk assessment remains current when new evidence is considered and decisions are recorded. Closing a corrective-action ticket should include the effect on risk, verification and installed products.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Challenge a redundant temperature monitor
The control loop and the protection monitor use separate software tasks, but both read the same ADC and voltage reference. The safety argument calls them independent.
- Identify common causes that can produce agreement on a wrong value.
- Propose evidence or design changes needed to support the protection claim.
- Define a fault-injection scenario and recovery criterion.
Show the worked answer
Reference drift, ADC malfunction, shared conversion configuration or corrupted shared data can affect both tasks. Separate scheduling does not establish measurement independence. Analyse the required protection and whether an independent sensor or analogue cut-off, diagnostic reference measurement or other justified mechanism is needed.
Inject a credible shared measurement fault and observe whether the physical temperature remains controlled. Also test faults in the protective path and document remaining limitations. Recovery should require trustworthy sensing and a known thermal state, with the appropriate reset authority. Update the architecture and risk-control trace before relying on the revised claim.
Review criteria
- Common causes are identified beyond source-code separation.
- The proposed protection addresses the actual failure mechanism.
- Verification and recovery close the control argument.
Check your understanding
Is diagnostic coverage the proportion of tests passed?
No. It concerns the relevant fault population and how effectively faults are detected under the defined model.
Why involve service in risk-control review?
Service can alter calibration, configuration, bypasses and software, changing the assumptions that make the control effective.
Further learning
- NASA Systems Engineering HandbookRisk, reliability and technical-process context.
- TEA-106 · Fault handling and safe statesDetection, containment, degradation and recovery.
Keep risk connected to engineering reality.
Strong assurance traces each important risk through concrete controls, credible independence and evidence that remains current throughout the lifecycle.