Reliability, Functional Safety and Cybersecurity

Introduction

Mechatronic systems combine mechanical structures, sensors, actuators, embedded computation, communications, and human interaction. Their usefulness depends not only on nominal performance but also on what happens when components age, measurements become incorrect, software fails, or an attacker manipulates a network. A safe and dependable design must therefore answer three related questions:

1. How likely is the system to perform its intended function?
2. What happens when faults occur, and can hazardous consequences be prevented?
3. Can unauthorized or malicious actions compromise safety, availability, integrity, or confidentiality?

Reliability, functional safety, and cybersecurity are distinct but interdependent disciplines. Reliability concerns failure-free operation over time. Functional safety concerns risk reduction through automatic protective functions. Cybersecurity concerns protection against intentional or accidental misuse of digital assets. In a modern robot, autonomous vehicle, medical device, or industrial machine, a cyberattack may create the same physical hazard as a hardware failure. Conversely, a safety mechanism may create a cybersecurity weakness if it is poorly authenticated or remotely accessible.

This chapter develops practical methods for analysis and design: failure mode and effects analysis (FMEA), fault-tree analysis (FTA), reliability models, redundancy, diagnosis, fault tolerance, safety cases, and industrial cybersecurity principles. The discussion is aligned conceptually with established practices in IEC 61508, ISO 13849, ISO 26262, IEC 62061, IEC 62443, and related risk-management standards. Exact compliance requires consulting the current edition of the applicable standard and its sector-specific requirements.

Learning objectives

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

• distinguish reliability, availability, safety, security, and maintainability;
• construct and interpret an FMEA and a fault tree;
• calculate basic reliability, failure-rate, availability, and redundancy measures;
• select suitable diagnostic and fault-tolerant architectures;
• explain the relationship between safety integrity and risk reduction;
• develop the structure of a safety case and a cybersecurity case;
• apply defense-in-depth, secure lifecycle, and industrial network-security principles;
• evaluate limitations, trade-offs, and ethical responsibilities in dependable-system design.

1. Core concepts and terminology

Reliability and failure

Reliability is the probability that an item performs its required function under stated conditions for a stated time. If T is operating time and T_f is time to failure, the reliability function is

where R(t) is dimensionless. The corresponding unreliability is F(t) = 1 - R(t). This definition requires a clearly specified function, environment, load, mission time, and acceptable performance boundary.

For a constant failure rate λ measured in failures per hour, the exponential model is

and the mean time to failure is

This model assumes statistically independent failures, a constant hazard rate, and no repair. It is often reasonable during a useful-life period, but it is not generally appropriate during early infant mortality or wear-out.

The hazard rate is the instantaneous conditional failure rate:

where f(t) is the probability-density function of time to failure. A decreasing hazard commonly indicates early defects, an approximately constant hazard indicates random failures, and an increasing hazard indicates wear-out. The familiar “bathtub curve” is a useful engineering model, not a universal law.

Availability and maintainability

Availability is the probability that a repairable system is operational when required. In a simple steady-state model,

where MTBF is mean time between failures and MTTR is mean time to repair or restore service. Both must use the same time unit. Availability can be improved by increasing reliability, reducing repair time, improving logistics, or adding online redundancy. High availability does not necessarily mean high safety: a system can remain available while performing a dangerous function incorrectly.

Maintainability describes the probability that a failed item can be restored within a specified time under stated conditions. Design choices such as modular replacement, built-in test, diagnostic access, and safe maintenance isolation directly influence maintainability.

Safety and security

Safety is freedom from unacceptable risk of physical injury or damage. Functional safety is the part of overall safety that depends on systems or devices responding correctly to inputs, including protection functions. Examples include emergency stopping, overspeed shutdown, torque limitation, and door interlocking.

Cybersecurity protects the confidentiality, integrity, and availability of information and control functions against unauthorized actions. Industrial control additionally requires authenticity, accountability, and sometimes safety-related timing. Security controls must not prevent a legitimate safety function from operating; safety controls must not become an unauthenticated pathway into the control system.

Risk is commonly represented qualitatively as a combination of severity and probability, although standards may prescribe particular methods. A useful engineering expression is:

This is a conceptual model, not a universal numerical law. Severity categories and likelihood scales must be defined consistently, and uncertainty must not be hidden by assigning unjustified numerical precision.

2. Failure analysis methods

Failure Mode and Effects Analysis

FMEA is a bottom-up method. The analyst begins with component or function failures and traces their local, system, and end effects. A typical worksheet contains:

Some organizations multiply ordinal ratings to obtain a risk-priority number. Such a product is only a prioritization aid: ordinal scores do not necessarily have equal intervals, and a low product can conceal a catastrophic failure with poor detectability. Engineering judgment, single-point-failure analysis, and explicit safety requirements remain necessary.

A good FMEA states failure modes precisely. “Sensor failure” is weak; “encoder output frozen at the last valid position during commanded motion” is actionable. The analysis should include open circuits, short circuits, drift, stuck-at values, intermittent behavior, incorrect calibration, timing faults, communication corruption, software defects, power disturbances, common-cause failures, and maintenance errors.

Fault-tree analysis

FTA is a top-down deductive method. It starts with a hazardous top event and decomposes it using logic gates. For independent events A and B:

• an AND gate occurs when both A and B are required;
• an OR gate occurs when either A or B is sufficient.

For probabilities in a specified mission interval,

under independence, while

for independent events. For rare independent events, the OR probability is approximately P(A)+P(B), but the exact expression should be used when accuracy matters. Independence must never be assumed for redundant channels sharing power, software, environmental stress, or a common sensor.

Minimal cut sets are the smallest combinations of basic events sufficient to cause the top event. They reveal single points of failure and common-cause vulnerabilities. FTA is particularly useful for safety requirements because it shows how lower-level failure probabilities contribute to a hazardous outcome. FMEA and FTA are complementary: FMEA asks what happens when each item fails; FTA asks how a specified undesired event can occur.

3. Reliability modeling and redundancy

Series and parallel structures

A series system operates only if every required element operates. For statistically independent elements,

If all n elements have the same reliability R, then R_series = Rⁿ. Series structures are vulnerable because each additional required element reduces total reliability.

A parallel structure operates if at least one of n redundant elements operates. For identical independent elements,

For a 1-out-of-2 architecture, this improves reliability only if failures are independent and a voter, switch, or controller can use the surviving channel. Real redundancy introduces added components, common-cause failures, imperfect switching, maintenance complexity, and possible systematic faults. Therefore redundancy must be accompanied by independence, monitoring, and a defined response to disagreement.

Worked example: independent redundant shutdown channels

Two identical shutdown channels each have reliability 0.98 over a one-hour mission. The function succeeds if at least one channel operates and the channels are independent:

R_parallel = 1 − (1 − 0.98)² = 1 − 0.0004 = 0.9996.

Thus the calculated reliability is 99.96% for the mission interval. This result excludes common power loss, common software defects, common environmental stress, and voter failure. If a common voter has reliability 0.995, the overall reliability becomes 0.9996 × 0.995 = 0.994602, or approximately 99.46%. The example demonstrates that redundancy shifts attention toward common elements and dependencies.

Reliability block diagrams and Markov models

A reliability block diagram represents success paths, not necessarily physical wiring. It is appropriate when component states and relationships can be described by static series and parallel logic. Repairable systems, standby switching, imperfect coverage, and dependent transitions may require a Markov model or state-transition model. A continuous-time Markov model assumes transition rates between states are sufficiently represented by exponential distributions. It is powerful but can become difficult to validate as the state space grows.

Reliability predictions should use credible data: field returns, accelerated testing with justified stress models, supplier evidence, environmental qualification, and expert assessment. A calculated decimal is not evidence by itself. Uncertainty bounds and model limitations should be documented.

4. Diagnostics and fault-tolerant design

A fault-tolerant system continues to provide an acceptable service after specified faults, or it moves to a defined safe state. Fault tolerance is not the same as hiding faults indefinitely. Undetected latent faults can accumulate and defeat redundancy.

Diagnostic techniques

Common techniques include:

• range, rate-of-change, and plausibility checks;
• comparison of redundant sensors;
• loopback and signal-injection tests;
• watchdog timers and heartbeat monitoring;
• memory and communication error detection;
• actuator feedback and command-response comparison;
• startup self-tests and periodic proof tests;
• model-based residual generation;
• logging, time synchronization, and event correlation.

A diagnostic must have a specified fault model, detection time, coverage claim, false-alarm policy, and reaction. Detection coverage is not simply the percentage of software tests. It concerns the proportion of relevant dangerous failures detected within the required time under defined assumptions.

A residual can be formed by comparing measured output with a model prediction:

A fault alarm may be generated when |r(t)| > γ, where γ is a threshold selected from sensor noise, model uncertainty, dynamics, and acceptable detection delay. Thresholds that are too small cause nuisance trips; thresholds that are too large delay detection. Model-based diagnosis is effective only when the model remains valid over operating conditions.

Safe states and degraded modes

The correct response depends on the hazard. Removing power may be safe for a conveyor but dangerous for a suspended load. A robot may need controlled stopping rather than uncontrolled braking. A medical pump may require continued flow at a restricted rate. Designers should specify:

1. the fault and its confidence level;
2. the maximum tolerable fault-reaction time;
3. the safe or sufficiently safe state;
4. energy isolation and residual energy controls;
5. recovery, reset, and restart conditions;
6. evidence that reset cannot cause unexpected motion.

Manual reset should not be treated as a substitute for risk reduction. It is a control against automatic restart, not proof that the hazard has disappeared.

Common-cause and systematic failures

Redundancy is weakened when channels share a power supply, clock, enclosure, communication bus, cooling system, requirement defect, software library, or environmental exposure. Diversity can reduce some common systematic faults, but diverse implementations can still share incorrect requirements. Separation, independence, diagnostic testing, environmental analysis, and conservative assumptions are essential.

5. Functional safety engineering

A functional-safety lifecycle begins with a risk assessment and continues through specification, design, implementation, verification, validation, operation, modification, and retirement. The central principle is that safety requirements must be traceable from hazards to implemented and tested safety functions.

A safety function normally specifies:

• initiating conditions or safety-related input;
• logic and processing;
• final elements and energy-control action;
• reaction time;
• required safe state;
• diagnostic and proof-test assumptions;
• environmental and operating limits;
• reset and restart behavior.

Standards use different terminology. IEC 61508 expresses safety integrity levels (SILs), while ISO 13849 commonly uses performance levels (PLs), and ISO 26262 uses automotive safety integrity levels (ASILs). These classifications are not interchangeable by name. The applicable standard, architecture, probability targets, diagnostic effectiveness, systematic capability, and lifecycle evidence must be used together.

A safety integrity claim can be misleading if it considers only random hardware failures. Functional safety also requires control of systematic failures: incorrect requirements, design mistakes, software defects, inadequate verification, configuration errors, and unsafe maintenance. Formal reviews, coding rules, independent verification, validated tools, change control, and competence management are therefore safety measures.

6. Safety cases and cybersecurity cases

A safety case is a structured, evidence-supported argument that a system is acceptably safe in a defined context. A practical structure is:

• Claim: the top-level safety assertion;
• Context: system boundaries, operating environment, assumptions, and definitions;
• Argument: logical decomposition showing why the claim follows;
• Evidence: analyses, tests, inspections, certificates, records, and field data;
• Defeaters and limitations: conditions that could invalidate the argument.

For example, the claim “the press prevents hazardous closing when the guard is open” must be decomposed into sensing, logic, actuation, reaction time, fault detection, validation, and maintenance assumptions. A test report is evidence, but it is not an argument unless its scope and relevance are clear.

A cybersecurity case uses a similar claim–argument–evidence structure. It should address identified assets, adversaries, attack paths, trust boundaries, security requirements, residual risk, monitoring, incident response, recovery, and secure decommissioning. Security is dynamic: a case must define how vulnerabilities, patches, credentials, suppliers, and configuration changes are managed throughout the lifecycle.

Safety and security cases should be linked. A security claim such as “only authorized engineering workstations can modify the safety controller” supports a safety claim if unauthorized modification could defeat a protective function. Conversely, a safety shutdown must remain available during loss of a nonessential network service.

7. Industrial cybersecurity principles

Industrial cybersecurity begins with a system inventory and architecture. Important practices include:

• segmenting zones and conduits according to function and trust;
• restricting traffic by default and allowing only required services;
• separating safety networks where justified, without assuming separation alone is sufficient;
• using strong identity, least privilege, and protected credentials;
• authenticating commands and verifying firmware and configuration integrity;
• applying secure remote access with approval, logging, time limits, and revocation;
• maintaining tested backups and recovery procedures;
• monitoring for abnormal behavior without overwhelming operators;
• managing vulnerabilities according to exploitability, exposure, consequence, and compensating controls;
• controlling removable media and supplier access;
• training personnel against phishing, unsafe workarounds, and insecure maintenance.

IEC 62443 provides a widely used industrial-security framework involving asset owners, product suppliers, service providers, security levels, and lifecycle processes. It does not eliminate the need for threat modeling. A threat model should identify what an attacker can influence, including sensors, set points, firmware, time synchronization, safety parameters, diagnostic channels, and maintenance interfaces.

Encryption can protect confidentiality and integrity, but cryptography does not replace authorization, secure key management, physical protection, patch governance, or safe fallback behavior. Availability and deterministic timing are particularly important in control systems. A security control that introduces unacceptable latency or blocks an emergency function is poorly engineered.

8. Case study: illustrative packaging-cell retrofit

Background

A fictional packaging cell contains a servo-driven indexing table, a pneumatic gripper, a programmable controller, a safety controller, light curtains, a guard switch, and an Ethernet maintenance connection. The owner wants remote diagnostics and higher throughput.

Problem

The preliminary design placed the safety controller and ordinary controller on the same flat network. The guard switch was single-channel, the servo drive accepted a networked enable command, and maintenance personnel could connect using a shared password. The cell had good nominal availability but weak evidence for safe behavior under faults or unauthorized access.

Analysis

An FMEA identified these important failure modes:

The fault tree for “hazardous motion while access is possible” included an undetected guard failure, failure of the safety logic, failure of the final switching element, and unsafe reset behavior. The analysis showed that simply adding a second guard contact would not solve common power loss or unsafe software configuration.

Approach and solution

The redesigned architecture used two monitored guard channels, a safety controller with diagnosed inputs and outputs, a drive safety function that removed torque independently of ordinary motion commands, and a mechanically controlled pneumatic exhaust where appropriate. The normal controller could request motion but could not bypass the safety chain. A manual reset was located outside the hazard zone and required the guard to be closed, the light curtain clear, and the restart area observable.

The network was divided into control, safety-related, and maintenance zones. Remote access required an approved connection, individual accounts, multifactor authentication, time-limited authorization, logging, and a documented rollback procedure. Configuration changes were version-controlled and verified. Backups were tested by restoration rather than merely stored.

Verification included fault insertion, response-time measurement, loss-of-network tests, power interruption, welded-contact simulation, invalid-command tests, password and access-control tests, and recovery exercises. The safety case linked each hazard to requirements and test evidence; the cybersecurity case linked assets and threats to controls and residual-risk decisions.

Outcome and learning points

The retrofit reduced single-point vulnerabilities and made the safety response independent of the ordinary network. It also revealed a practical trade-off: additional diagnostics generated nuisance alarms until thresholds and maintenance procedures were refined. The project demonstrated that reliability, safety, and cybersecurity should be engineered together from the hazard and asset models, not appended after commissioning.

9. Challenges, ethics, and contemporary developments

Limitations of models

Failure-rate data may be sparse, nonrepresentative, or confidential. Independence assumptions are often optimistic. Software systematic failures do not behave like random component failures. Tests cannot demonstrate that every possible input is safe, and a certification assessment is not a guarantee of safe operation in every context. Engineers should report assumptions, uncertainty, excluded failure modes, and residual risks explicitly.

Governance and professional responsibility

A design team has a duty to protect operators, maintainers, bystanders, customers, and the public. Safety shortcuts should not be justified solely by production targets. Cybersecurity decisions must consider privacy, lawful access, supply-chain responsibility, and the consequences of disabling monitoring. Incident disclosure, coordinated vulnerability handling, and accurate safety documentation are professional obligations. Operators must be given understandable procedures and authority to stop unsafe work.

AI and advanced diagnosis

Machine learning can support anomaly detection, predictive maintenance, and sensor-fault classification. However, a model may fail under distribution shift, adversarial input, sensor drift, or rare operating conditions. For safety-related decisions, the model’s training data, performance bounds, explainability, update process, and fallback behavior must be controlled. AI should not be credited with a safety integrity claim merely because it performs well on a test set. A deterministic, independently verified protective layer may still be required.

Best-practice design sequence

A disciplined project generally follows this sequence:

1. define the system, mission, users, environment, and assets;
2. identify hazards, threats, foreseeable misuse, and unacceptable outcomes;
3. specify safety and security functions with measurable timing and performance;
4. perform FMEA, FTA, threat modeling, and common-cause analysis;
5. select architecture, independence, diagnostics, and safe states;
6. implement traceable requirements with configuration control;
7. verify components and validate the integrated system under realistic faults;
8. document safety and cybersecurity cases with assumptions and evidence;
9. operate, monitor, maintain, patch, train, and audit the system;
10. manage changes, incidents, lessons learned, and retirement securely.

Chapter Summary

Reliable and dependable mechatronic systems require coordinated treatment of failure, hazard, and attack. Reliability is the probability of performing a required function for a stated time; availability additionally includes repair and restoration. FMEA provides a structured bottom-up analysis, while FTA deductively identifies combinations of events leading to a hazardous top event. Series and parallel reliability models are useful but depend strongly on independence assumptions and correct treatment of common-cause failures.

Fault-tolerant design requires more than duplication. It requires diagnostics, independence, validated switching or voting, defined safe states, controlled reset, and management of latent faults. Functional safety engineering links hazard analysis to safety functions, lifecycle evidence, and applicable standards. Safety integrity terminology must not be transferred uncritically between standards.

Cybersecurity protects control assets against unauthorized or malicious action and must be integrated with safety architecture. Segmentation, least privilege, authenticated access, secure updates, monitoring, recovery, and lifecycle governance are essential. Safety cases and cybersecurity cases organize claims, context, arguments, evidence, assumptions, and residual risk. The professional goal is not merely a high calculated reliability but a defensible, maintainable, secure, and safe system in its real operating context.

Key Terms

Reliability: Probability that an item performs its required function for a stated time and conditions.

Failure rate: Rate at which failures occur under specified assumptions, commonly denoted λ.

Availability: Probability that a repairable system is operational when required.

Maintainability: Probability that a failed item can be restored within a specified time.

Functional safety: Safety dependent on correct operation of safety-related systems and devices.

Cybersecurity: Protection of digital systems and control functions from unauthorized or malicious action.

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

Fault-tree analysis: Top-down analysis of combinations causing an undesired top event.

Minimal cut set: Smallest combination of basic events sufficient to cause a fault-tree top event.

Redundancy: Use of additional elements so a function can survive specified failures.

Common-cause failure: Failure affecting multiple redundant elements through a shared cause.

Fault diagnosis: Detection, isolation, and identification of abnormal system behavior.

Fault tolerance: Ability to continue acceptable operation or reach a safe state after faults.

Safe state: Condition in which identified hazards are controlled to an acceptable level.

Safety integrity: Likelihood that a safety function performs correctly when required.

Safety case: Structured argument and evidence that a system is acceptably safe.

Threat model: Structured description of assets, adversaries, attack paths, and controls.

Defense in depth: Multiple independent or complementary protective layers.

Proof test: Planned test intended to reveal dangerous undetected failures.

Residual risk: Risk remaining after safeguards and controls are applied.

Review Questions

Short Answer Questions

1. Define reliability and distinguish it from availability.
2. What is the difference between FMEA and fault-tree analysis?
3. Why can redundancy fail to improve safety when common-cause failures exist?
4. What information should be specified for a safety function?
5. Name four industrial cybersecurity controls relevant to a mechatronic cell.

Long Answer Questions

1. Explain the assumptions and limitations of the exponential reliability model.
2. Compare series, parallel, and 1-out-of-2 architectures, including practical disadvantages of redundancy.
3. Describe how diagnostic coverage, proof testing, and safe-state design contribute to functional safety.
4. Explain how a safety case differs from a test report and how evidence supports its argument.
5. Discuss why cybersecurity must be treated as part of, rather than separate from, modern functional-safety engineering.

Analytical / Application Questions

1. Construct an FMEA for an automated door-interlock system and recommend controls for its three most critical failure modes.
2. A robot cell has two redundant position sensors but a single shared power supply and a single software voter. Analyze which failures remain common points of vulnerability and propose a revised architecture.
3. Develop a high-level safety and cybersecurity case for a remotely monitored autonomous mobile robot, including claims, assumptions, evidence, residual risks, and recovery measures.

Multiple Choice Questions with Answers

Question 1

Which statement best defines reliability?

A. The probability that a system is operational at any random instant, including repairs

B. The probability that an item performs its required function for a stated time under stated conditions

C. The time required to repair a failed component

D. The degree of protection against unauthorized access

Correct Answer: B. The probability that an item performs its required function for a stated time under stated conditions

Question 2

For two independent identical components with reliability R over a mission, which expression represents a parallel success structure?

A. R²

B. 1 − R²

C. 1 − (1 − R)²

D. 2R

Correct Answer: C. 1 − (1 − R)²

Question 3

What is the principal analytical direction of FMEA?

A. Top-down from a hazard to causes

B. Bottom-up from failure modes to effects

C. From network threats to encryption keys only

D. From maintenance cost to product price

Correct Answer: B. Bottom-up from failure modes to effects

Question 4

A fault-tree AND gate generally means that:

A. Either input event alone causes the top event

B. Both input events are required for the output event

C. Neither input event can occur

D. The events are automatically independent

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

Question 5

Which factor most directly undermines the benefit of redundant channels?

A. Independent power supplies

B. Diverse implementation

C. A shared common-cause failure

D. Periodic proof testing

Correct Answer: C. A shared common-cause failure

Question 6

For a constant failure rate λ, the exponential reliability model is:

A. R(t) = λt

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

C. R(t) = 1 + λt

D. R(t) = λ/t

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

Question 7

Which statement about a safety case is correct?

A. It is only a list of component prices

B. It is a structured claim, argument, context, and evidence demonstrating acceptability of safety

C. It replaces all validation testing

D. It applies only to cybersecurity incidents

Correct Answer: B. It is a structured claim, argument, context, and evidence demonstrating acceptability of safety

Question 8

Which cybersecurity principle limits users and processes to the permissions necessary for their tasks?

A. Least privilege

B. Maximum availability

C. Open trust

D. Unrestricted forwarding

Correct Answer: A. Least privilege

Question 9

Two shutdown channels each have reliability 0.98 over one hour and are independent. What is their parallel reliability, before common components are included?

A. 0.9604

B. 0.9800

C. 0.9996

D. 1.9600

Correct Answer: C. 0.9996

Question 10

Why should an AI anomaly detector not automatically be treated as a complete safety function?

A. AI systems cannot process sensor data

B. Test performance does not establish performance under all operating and adversarial conditions

C. AI always reduces availability to zero

D. AI cannot be monitored

Correct Answer: B. Test performance does not establish performance under all operating and adversarial conditions