Dependability, Safety and Resilience

Introduction

Cyber-physical systems (CPS) combine computation, communication, sensing, actuation and physical processes. Their failures may therefore produce consequences that extend beyond software malfunction: a defective controller can damage machinery, injure people, interrupt essential services or create environmental harm. Dependability engineering provides the concepts and methods needed to prevent, tolerate, detect and recover from such failures.

This chapter examines reliability, availability, maintainability, safety, fault tolerance and resilience. It introduces hazard analysis, failure mode and effects analysis (FMEA), fault-tree analysis (FTA), redundancy and functional-safety standards. The emphasis is on mechatronic CPS such as autonomous vehicles, robotic cells, medical devices, industrial automation systems and intelligent transportation infrastructure.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Distinguish reliability, availability, maintainability, safety and resilience.
2. Calculate basic reliability, failure-rate, availability and repair measures.
3. Apply FMEA and fault-tree analysis to CPS hazards.
4. Compare hardware, software and architectural redundancy.
5. Explain fault detection, isolation, graceful degradation and fail-safe behavior.
6. Relate engineering decisions to functional-safety standards and governance obligations.
7. Evaluate dependability trade-offs in a practical mechatronic system.

1. Dependability as a System Property

Dependability is the ability of a system to deliver services that can justifiably be trusted. It is not a single attribute. It includes:

• Reliability: continuity of correct service during a specified period and operating environment.
• Availability: readiness for correct service when required.
• Maintainability: ability to be restored or modified effectively after failure.
• Safety: absence of unacceptable risk of physical injury, damage or environmental harm.
• Security: resistance to unauthorized access, manipulation and disruption.
• Integrity: protection against improper alteration of data or behavior.
• Resilience: ability to withstand, adapt to and recover from faults, disturbances and attacks.

These properties interact but are not interchangeable. A system can be highly available yet unsafe if it remains operational while producing hazardous commands. Conversely, a system can be safe because it shuts down frequently, but have poor availability. A safety controller must therefore balance continuity of service with controlled risk.

A useful CPS dependability model has four layers:

1. Physical process: motors, mechanisms, pressure, temperature, motion and energy.
2. Embedded control: sensors, processors, software, actuators and power supplies.
3. Communication and coordination: networks, time synchronization and distributed messages.
4. Human and organizational context: operators, maintenance teams, procedures, suppliers and regulators.

Failure analysis must cross these boundaries. For example, a network delay may cause a controller to use stale position data; the resulting mechanical motion may create a collision hazard.

2. Reliability and Availability Models

2.1 Reliability functions

Let T be the random time to failure. Reliability at time t is the probability that the system has not failed by t:

The cumulative failure probability is:

The failure-rate function or hazard rate is:

where f(t) is the probability density of failure time. The unit of λ is inverse time, such as failures per hour. The hazard rate is a conditional instantaneous failure tendency, not simply the probability of failure per hour in all circumstances.

For a constant failure rate λ, the exponential model applies:

This model assumes statistically independent failures, a constant rate, no aging effect and operation under a specified environment. It is often useful for electronic components during their useful-life period, but it is not generally appropriate for wear-out mechanisms such as bearing fatigue.

The mean time to failure (MTTF) for a non-repairable component is:

For the exponential model:

MTTF applies to non-repairable units. For repairable systems, mean time between failures (MTBF) is commonly used, but its interpretation depends on the exact definitions of failure, repair and operating time.

2.2 Series and parallel structures

A series system functions only when every required element functions. If component failures are statistically independent:

For n identical components with reliability R(t), this becomes R_series(t) = R(t)ⁿ. Series architecture reduces reliability because every additional necessary element introduces another possible failure point.

A parallel redundant system functions when at least one of n independent components functions:

For two identical components, R_parallel(t) = 1 − (1 − R(t))². This result assumes that redundancy is genuine: failures are independent, switching is successful, and common-cause failures are absent. These assumptions are often violated in practical CPS designs.

Worked Example 1: Exponential reliability

A sensor has a constant failure rate of 2 × 10⁻⁵ failures per hour. Its reliability over 1,000 h is:

Thus, under the model assumptions, the probability of surviving 1,000 h is approximately 98.02%. The corresponding MTTF is:

MTTF is not a guarantee that each sensor will last 50,000 h; it is a statistical mean.

2.3 Availability

Availability is the probability that a repairable system is operational at a specified time or over a specified interval. A common steady-state approximation is:

where MTTR is mean time to repair or restore service. This expression assumes alternating operating and repair periods, stable averages and a defined repair process.

For a two-state continuous-time model with constant failure rate λ and repair rate μ:

Since MTBF ≈ 1/λ and MTTR ≈ 1/μ under the simple exponential assumptions, the forms are consistent.

Availability can be improved by increasing reliability, reducing repair time, improving diagnostics, keeping spares, designing for access and automating recovery. High availability does not by itself demonstrate safety.

3. Failure, Fault, Error and Hazard

A fault is a defect or abnormal condition, such as a broken wire or software design error. An error is an incorrect internal state caused by a fault. A failure occurs when the delivered service deviates from the required service. A hazard is a condition with the potential to cause harm. Risk combines the likelihood of a hazardous event with its severity.

A typical causal chain is:

Fault → erroneous sensor value → incorrect controller decision → excessive actuator command → hazardous motion → injury.

Not every fault causes a failure, because design barriers may detect it or prevent it from propagating. Dependability engineering therefore seeks to:

• prevent faults;
• detect faults quickly;
• isolate faulty elements;
• contain errors;
• provide a safe degraded service;
• recover and learn from disturbances.

A safety function is a function intended to achieve or maintain a safe state. Examples include emergency stopping, prevention of unexpected restart, overspeed limitation and monitoring of protective doors.

4. Hazard Analysis and Risk Reduction

Hazard analysis begins with the intended function and operating context. Engineers identify foreseeable misuse, energy sources, environmental conditions, interfaces and credible failure scenarios. Risk is commonly evaluated using severity and likelihood categories, although the precise method depends on the applicable standard and industry.

A practical process is:

1. Define system boundaries and operating modes.
2. Identify hazards and hazardous events.
3. Estimate severity and likelihood.
4. Identify existing safeguards.
5. Specify risk-reduction functions.
6. Allocate requirements to hardware, software, people and procedures.
7. Verify, validate and document residual risk.

Risk matrices are useful communication tools but should not be treated as precise probability models. Categories can hide uncertainty, correlations and rare catastrophic events. Quantitative evidence is preferable when credible data are available.

FMEA

Failure Mode and Effects Analysis is a bottom-up method. For each component or function, the analyst records its failure modes, local effects, system effects, causes, existing controls and recommended actions. Typical columns include:

Some organizations assign rankings for severity, occurrence and detectability. A risk-priority number may be calculated as their product, but this ranking can be misleading: a catastrophic failure should not necessarily be considered acceptable merely because its numerical product is low. Modern FMEA practice emphasizes action priority, criticality and explicit controls rather than blind reliance on one score.

FMEA is effective for component-level and interface-level analysis, but it may miss combinations of failures and emergent system behavior. It should therefore be complemented by top-down methods.

Fault-tree analysis

FTA begins with a top event, such as “robot enters protected human area with hazardous speed,” and decomposes it using logical gates. An AND gate means all input events are required; an OR gate means any input event can produce the output.

For independent basic events A and B:

• OR probability: P(A OR B) = P(A) + P(B) − P(A)P(B)
• AND probability: P(A AND B) = P(A)P(B)

For rare, independent events, the OR approximation P(A OR B) ≈ P(A) + P(B) may be acceptable, but the exact expression should be used when probabilities are not small.

FTA reveals minimal cut sets: smallest combinations of basic events sufficient to cause the top event. It is particularly useful for redundant systems, common-cause analysis and quantitative safety arguments. Independence must never be assumed without justification; shared power, software, environment, maintenance error or design defects can defeat apparent redundancy.

5. Fault Tolerance and Resilient Architecture

Fault tolerance is the capability to continue an acceptable service despite specified faults. It is achieved through structural and behavioral mechanisms.

Redundancy types

• Hardware redundancy: duplicate sensors, processors, power supplies or actuators.
• Information redundancy: error-detecting codes, parity, checksums and message authentication.
• Software redundancy: diverse implementations, monitors and recovery blocks.
• Analytical redundancy: estimating a variable from a model and comparing it with measured data.
• Temporal redundancy: repeating an operation or measurement.
• Functional redundancy: using different physical principles, such as combining radar and camera sensing.

Simple duplication is vulnerable to common-cause failure. Triple modular redundancy (TMR) uses three channels and a voter; it can mask one incorrect channel if the voter and remaining channels function correctly. However, TMR adds cost, power consumption, synchronization requirements and possible voter failure.

A robust architecture typically contains:

1. independent sensing or cross-checks;
2. watchdogs and timeouts;
3. fault detection and isolation;
4. a defined safe state;
5. graceful degradation;
6. diagnostic records and recovery procedures.

A fail-safe system moves to a state with acceptably low hazard when faults occur. A fail-operational system continues its required function after certain faults. Autonomous driving and aircraft controls may require fail-operational behavior for a limited period, followed by a controlled transition to a minimal-risk condition.

Resilience extends beyond fault masking. It includes preparation, absorption, adaptation, recovery and learning. A resilient CPS may reconfigure communication routes, reduce production speed, switch to manual control or safely shut down while preserving essential information.

6. Maintainability, Diagnostics and Proof Testing

Maintainability is influenced by modular design, accessibility, standard interfaces, diagnostic coverage, documentation, training and spare-parts logistics. Mean time to repair includes fault localization, access, replacement, testing and return to service—not merely the time spent changing a component.

Diagnostics should detect dangerous faults before a demand occurs. A watchdog timer can identify software that has stopped executing, while a plausibility monitor can compare position, velocity and acceleration. Diagnostic coverage is not absolute: a test may detect some failure modes but miss latent or intermittent faults.

Safety-related protective functions often require periodic proof testing. A proof test intentionally exercises a function to reveal dangerous hidden failures. The interval should be justified by the required risk reduction and the probability of dangerous failure remaining undetected. Proof tests themselves must be designed carefully; a superficial test can create false confidence.

7. Functional-Safety Standards and Lifecycle Thinking

Functional safety is achieved when safety-related systems correctly perform their safety functions and behave predictably under fault conditions. Important frameworks include:

• IEC 61508: generic functional-safety framework for electrical, electronic and programmable electronic safety-related systems.
• ISO 13849: safety-related parts of control systems for machinery, using performance levels.
• IEC 62061: functional safety of machinery control systems.
• ISO 26262: functional safety of road vehicles.
• IEC 62304: medical-device software lifecycle processes.
• IEC 62443: security for industrial automation and control systems.

Standards differ in scope and terminology, but lifecycle principles are similar: define the intended function, identify hazards, allocate safety requirements, design with appropriate rigor, verify independently, validate in the real operating context, manage configuration and maintain evidence throughout operation.

Safety integrity is not created by using a particular processor or programming language. It depends on the complete system, including requirements, architecture, diagnostics, independence, competence, testing and change control. Safety and cybersecurity are increasingly interdependent: an attacker who disables a speed monitor can create a functional-safety hazard, while a safety shutdown can become a denial-of-service target.

Engineers must distinguish compliance from safety achievement. A certificate or standard-conformance claim is evidence of a process and design argument, not proof that every operational risk has vanished.

8. Worked Example: Redundant Emergency-Stop Monitoring

Consider an illustrative robot cell with two independent emergency-stop channels. Each channel has reliability 0.99 over a specified mission interval. The safety function succeeds if at least one channel remains functional, assuming an independent voter and successful actuation.

The probability that both channels fail is:

Therefore:

The idealized redundant reliability is 99.99%. This result must not be reported as the achieved safety performance without examining common power supplies, shared wiring, common software, environmental interference, maintenance mistakes and voter failure. If a shared power supply can disable both channels, the assumed independence is false and the benefit is much smaller.

The design should also specify what happens after detection. The emergency stop may remove actuator energy, apply brakes, inhibit restart and require a deliberate reset. A reset must not cause unexpected motion; the system should require verification that the hazard has been removed.

9. Illustrative Case Study: Autonomous Warehouse Vehicle

Background

An autonomous warehouse vehicle transports loads between storage aisles and packing stations. It uses wheel encoders, lidar, wireless communication, a programmable controller and motor drives. People and vehicles share portions of the facility.

Problem

During testing, the vehicle occasionally continued moving for several seconds after a lidar communication interruption. Investigation showed that the controller retained the last valid obstacle distance and the network timeout was longer than the braking distance at maximum speed.

Analysis

An FMEA identified “sensor data frozen” and “communication loss” as failure modes. An FTA for “vehicle fails to stop before obstacle” included an OR relationship between loss of primary obstacle detection and failure of the independent bumper switch. It also identified an AND path involving communication loss and an overly long timeout. The analysis revealed a common-cause issue: both obstacle-processing channels depended on the same network switch.

Approach and solution

The engineering team:

1. introduced a short, justified communication timeout;
2. calculated stopping distance for each speed and floor condition;
3. added an independent safety scanner and a hardwired emergency-stop circuit;
4. commanded a controlled stop when data became stale;
5. limited speed when operating near people;
6. prevented automatic restart after a safety trip;
7. logged diagnostic events for maintenance analysis;
8. validated the complete system using normal, degraded and foreseeable misuse scenarios.

Outcome

The vehicle entered a minimal-risk state after loss of valid obstacle data. The additional channel improved fault detection, while the speed restriction reduced the required stopping distance. The final safety argument documented assumptions, test evidence, residual risks and maintenance requirements.

Learning points

The case demonstrates that redundancy alone is insufficient. Timing, physical stopping performance, independence, human interaction, recovery behavior and validation are equally important. It also shows why safety requirements must be stated quantitatively where possible—for example, maximum reaction time and stopping distance—rather than as vague requirements such as “stop quickly.”

10. Challenges, Ethics and Professional Practice

Dependability analysis is limited by incomplete failure data, changing environments, software complexity, rare-event statistics and uncertain human behavior. Artificial intelligence introduces additional concerns: data-distribution shift, opaque decisions, difficult-to-predict edge cases and changes after deployment. An AI perception system should not be treated as inherently reliable because its average classification accuracy is high; safety depends on performance in the operational design domain and on independent protective mechanisms.

Ethically, engineers must communicate uncertainty, avoid overstating safety claims and preserve traceability from hazard to requirement, implementation and test evidence. Deliberately disabling alarms, concealing near misses or reducing maintenance below the validated schedule is professionally unacceptable. Organizations should maintain incident reporting, controlled change management, competence records and independent review for high-consequence systems.

Best practice includes:

• analyze hazards before selecting technology;
• define safe and degraded states explicitly;
• use independent protection layers where justified;
• test interfaces and timing, not only individual components;
• address common-cause and common-mode failures;
• include operators and maintainers in validation;
• monitor field performance and near misses;
• reassess risk after software, hardware, environment or mission changes.

Chapter Summary

Dependability in cyber-physical systems is a system-level property comprising reliability, availability, maintainability, safety, security, integrity and resilience. Reliability describes continuity of correct service, while availability also includes restoration after repair. Exponential reliability models are useful under constant-rate assumptions, and series and parallel equations demonstrate the effects of architecture and redundancy.

Hazard analysis links system purpose to unacceptable outcomes. FMEA provides a systematic bottom-up examination of failure modes, whereas FTA begins with a hazardous top event and identifies causal combinations. Both methods require careful treatment of assumptions and common-cause failures.

Fault tolerance uses redundancy, diagnostics, monitoring and reconfiguration to control faults. Fail-safe systems move to a low-risk state; fail-operational systems continue essential service after defined faults. Resilience adds adaptation, recovery and learning. Functional-safety standards impose lifecycle, verification, validation and evidence requirements, but compliance must not be confused with guaranteed safety. Effective engineering combines quantitative analysis, sound architecture, human factors, cybersecurity, maintenance and ethical governance.

Key Terms

Dependability: Ability of a system to deliver justifiably trusted service.

Reliability: Probability of performing required service without failure for a specified time.

Availability: Probability that a system is ready to provide correct service when required.

Maintainability: Ability to be restored or modified effectively after a fault.

Safety: Freedom from unacceptable risk of harm.

Resilience: Ability to withstand, adapt to and recover from disturbances.

Fault: Defect or abnormal condition in a system.

Error: Incorrect internal state resulting from a fault.

Failure: Deviation of delivered service from specified service.

Hazard: Condition with potential to cause harm.

Risk: Combination of the likelihood and severity of harm.

FMEA: Bottom-up analysis of failure modes, causes, effects and controls.

Fault-tree analysis: Top-down logical analysis of causes of a defined top event.

Redundancy: Provision of additional means to perform a function.

Common-cause failure: Failure of multiple elements due to one shared cause.

Fail-safe: Behavior that moves the system toward an acceptably safe state after faults.

Fail-operational: Continued performance of required service after specified faults.

Diagnostic coverage: Proportion of relevant failure modes detected by diagnostics.

Proof test: Periodic test intended to reveal dangerous hidden failures.

Functional safety: Correct performance of safety functions under specified conditions and faults.

Review Questions

Short Answer Questions

1. Distinguish reliability from availability.
2. What is the difference between a fault, an error and a failure?
3. State two assumptions behind the parallel-reliability equation.
4. What is the purpose of a watchdog timer?
5. Why can redundancy fail to provide its expected benefit?

Long Answer Questions

1. Explain how FMEA and fault-tree analysis complement one another in CPS hazard analysis.
2. Discuss the relationship among reliability, maintainability and availability, including the role of MTTR.
3. Compare fail-safe and fail-operational architectures using mechatronic examples.
4. Explain how functional-safety standards support a safety lifecycle from requirements to maintenance.
5. Discuss why cybersecurity and functional safety should be considered together in connected industrial systems.

Analytical / Application Questions

1. A repairable controller has MTBF of 8,000 h and MTTR of 20 h. Calculate its steady-state availability using A = MTBF/(MTBF + MTTR), and explain whether this value alone proves that the controller is safe.
2. Design an FMEA for an automated conveyor safety function with a guard switch, motor drive and emergency-stop relay. Identify at least four failure modes and propose detection or mitigation for each.
3. An autonomous vehicle uses two obstacle sensors, but both share one power supply and one network switch. Analyze the claimed redundancy, identify common-cause failures and propose a more defensible architecture.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes reliability from availability?

A. Reliability includes repair time, whereas availability excludes it.

B. Reliability concerns failure-free operation over time, whereas availability includes readiness and restoration.

C. Reliability applies only to software, whereas availability applies only to hardware.

D. Reliability measures safety severity, whereas availability measures failure likelihood.

Correct Answer: B. Reliability concerns failure-free operation over time, whereas availability includes readiness and restoration.

Question 2

For a component with constant failure rate λ, which expression gives exponential reliability at time t?

A. R(t) = λt

B. R(t) = 1 − e^(−λt)

C. R(t) = e^(−λt)

D. R(t) = 1/λt

Correct Answer: C. R(t) = e^(−λt)

Question 3

A series system functions only when:

A. At least one component functions.

B. Exactly two components fail.

C. Every required component functions.

D. The repair rate exceeds the failure rate.

Correct Answer: C. Every required component functions.

Question 4

What is the main purpose of FMEA?

A. To begin with a top event and construct logical gates.

B. To examine component or function failure modes, effects, causes and controls.

C. To calculate only steady-state availability.

D. To certify that a system is immune to cyberattacks.

Correct Answer: B. To examine component or function failure modes, effects, causes and controls.

Question 5

In a fault tree, an AND gate indicates that:

A. Any one input event is sufficient for the output event.

B. All specified input events are required for the output event.

C. The input events are statistically independent in every case.

D. The output event cannot occur.

Correct Answer: B. All specified input events are required for the output event.

Question 6

A system has MTBF = 9,900 h and MTTR = 100 h. Under the simple steady-state model, its availability is:

A. 0.0099

B. 0.0101

C. 0.99

D. 1.01

Correct Answer: C. 0.99

Question 7

Which is an example of analytical redundancy?

A. Installing a second identical fuse with no monitoring.

B. Estimating position from a motion model and comparing it with a sensor measurement.

C. Increasing the physical size of a motor.

D. Replacing a failed component after breakdown.

Correct Answer: B. Estimating position from a motion model and comparing it with a sensor measurement.

Question 8

Why may two redundant channels fail together?

A. Because redundancy always reduces reliability.

B. Because common power, software, environment or maintenance can create common-cause failure.

C. Because parallel systems require all channels to fail.

D. Because diagnostic coverage is always 100%.

Correct Answer: B. Because common power, software, environment or maintenance can create common-cause failure.

Question 9

Which behavior is most characteristic of a fail-safe system?

A. It continues at maximum performance after every fault.

B. It moves toward a state with acceptably low hazard after a fault.

C. It suppresses all diagnostic information.

D. It automatically restarts without checking the hazard.

Correct Answer: B. It moves toward a state with acceptably low hazard after a fault.

Question 10

What is the principal purpose of a proof test?

A. To increase the nominal processor speed.

B. To reveal dangerous hidden failures in a safety function.

C. To replace hazard analysis permanently.

D. To guarantee that common-cause failures cannot occur.

Correct Answer: B. To reveal dangerous hidden failures in a safety function.