14. Reliability, Safety, Cybersecurity and Responsible Governance

Introduction and Context

Mechatronic systems combine mechanical structures, sensors, actuators, embedded computation, communication networks and software. Their value arises from this integration, but integration also creates coupled risks. A failure in a sensor may cause an incorrect control action; a software defect may produce a mechanically hazardous motion; a compromised network may disable a safety function; and an apparently minor human-interface design error may defeat an otherwise sound technical safeguard.

Reliability, safety and cybersecurity must therefore be treated as system properties rather than as isolated attributes of individual components. Reliability concerns the ability of a system to perform its required function for a specified time and under specified conditions. Safety concerns freedom from unacceptable risk of physical injury or damage. Cybersecurity concerns protection against unauthorized access, manipulation, disruption and disclosure. Responsible governance extends these concerns to privacy, accountability, fairness, sustainability, regulatory compliance and the effects of technology on people and society.

For postgraduate engineers, the central challenge is not merely to calculate a failure probability. It is to make defensible design and management decisions when evidence is incomplete, systems are adaptive, and technical, organizational and ethical considerations interact.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish reliability, availability, maintainability, safety, security and resilience.

2. Apply failure modes and effects analysis (FMEA), fault-tree analysis (FTA) and basic reliability models.

3. Explain fault diagnosis, redundancy, fail-safe design and functional-safety principles.

4. Assess cyber risks in connected mechatronic systems and propose layered controls.

5. Integrate human factors, privacy, AI ethics, sustainability and governance into engineering decisions.

6. Interpret the role of standards, assurance cases, lifecycle management and incident learning.

7. Evaluate trade-offs among performance, cost, maintainability, safety and social responsibility.

Reliability as a System and Lifecycle Property

Reliability is commonly expressed as the probability that an item performs its intended function without failure during a stated interval, under stated operating conditions. If a component has a constant failure rate λ, its reliability can be approximated by

R(t) = e^(-λt),

and its mean time to failure is approximately 1/λ. The constant-rate assumption is useful for electronics during their useful life, but it is not universally valid. Mechanical components often exhibit early failures, a useful-life region and wear-out failures. This pattern is represented by the bathtub curve. Environmental conditions, vibration, temperature, contamination, overload and maintenance practice can substantially alter the failure distribution.

Reliability should be separated from availability. Availability is the proportion of time that a system is operational and may be approximated, for a repairable system, by

A ≈ MTBF/(MTBF + MTTR),

where MTBF is mean time between failures and MTTR is mean time to repair or restore. A highly reliable system can have poor availability if repair is slow, while a frequently failing system may have acceptable availability if it can be restored rapidly. Maintainability concerns the ease and speed with which maintenance can be performed. Resilience is broader: it is the capacity to withstand, adapt to and recover from disturbances, including disturbances that were not anticipated during design.

Reliability allocation begins with system requirements and distributes reliability targets among subsystems. Allocation should consider architecture, duty cycle, environmental stress and consequences of failure rather than simply dividing a target equally among components. Reliability prediction based on component databases can support comparison, but it cannot replace testing, field evidence and engineering judgment.

FMEA: Learning from Failure Modes

Failure modes and effects analysis is a bottom-up method. The analyst examines each function or component, identifies how it can fail, determines local and system effects, records causes and existing controls, and proposes actions. A typical worksheet contains:

• item or function;
• intended performance;
• failure mode;
• local, subsystem and end effect;
• cause and mechanism;
• current prevention and detection controls;
• severity, occurrence and detectability assessments;
• recommended action, owner and completion evidence.

Traditional risk priority numbers multiply severity, occurrence and detectability ratings. This can be useful for ranking work, but the product can conceal important distinctions: a catastrophic failure with low occurrence should not necessarily rank below a frequent nuisance failure. Modern practice therefore uses explicit severity thresholds, action rules and expert review in addition to numerical rankings.

Design FMEA examines how a design may fail; process FMEA examines manufacturing, assembly or service processes; and system FMEA traces interactions across functions. FMEA is most valuable when conducted early and revisited after design changes, field incidents, software updates or changes in operating context. It becomes weak when it is treated as a form-filling exercise, when failure effects are described only at the component level, or when common-cause failures are ignored.

Fault-Tree Analysis and System Logic

Fault-tree analysis is a top-down, deductive method. It begins with a defined undesired top event, such as “unexpected hazardous actuator motion,” and decomposes that event into contributing events using logical gates. An OR gate indicates that any input can produce the output; an AND gate indicates that several events must occur together. Basic events may include sensor failure, software logic error, loss of communication or an unsafe maintenance action.

If independent events A and B feed an OR gate, the probability of the top event is

P(A OR B) = P(A) + P(B) − P(A)P(B).

For an AND gate under independence, P(A AND B) = P(A)P(B). Independence must never be assumed casually: shared power, common software, environmental stress or a common supplier can create common-cause failure. FTA identifies minimal cut sets, which are the smallest combinations of basic events sufficient to produce the top event. It is particularly useful for demonstrating that safety goals are met and for identifying where a single point of failure remains.

FMEA and FTA are complementary. FMEA asks, “How can each element fail, and what will result?” FTA asks, “What combinations can produce this hazardous outcome?” A mature safety analysis uses both, supported by hazard analysis, testing and operational evidence.

Fault Diagnosis, Redundancy and Safe Control

Fault diagnosis generally involves detection, isolation and identification. Detection determines that behavior differs from an expected condition; isolation determines which subsystem is implicated; identification estimates the fault type, magnitude or location. Techniques include limit checking, analytical redundancy, residual generation, model-based observers, voting logic, trend analysis and machine-learning classifiers.

A diagnostic algorithm must account for false positives and false negatives. Excessive sensitivity can create nuisance shutdowns, while poor sensitivity can allow dangerous degradation. Diagnostic coverage is the ability of a mechanism to detect relevant failures, but high coverage does not guarantee safety if the detected fault is not followed by a suitable response.

Redundancy may be physical, analytical, functional or informational. In a parallel configuration, independent components can improve reliability; if two identical components each have reliability R and failures are independent, the reliability of a two-unit parallel arrangement is 1 − (1 − R)^2. In practice, redundancy introduces cost, weight, voting complexity and common-cause risk. Identical redundant channels may share the same design defect or be affected by the same electromagnetic disturbance. Diverse redundancy, such as combining different sensing principles or independently developed software, can reduce some common-mode risks.

Fail-safe design places the system in a state whose hazards are minimized when a fault occurs. A fail-operational system continues its essential function after specified failures, often with degraded performance. These goals must be distinguished: stopping a robot may be safe in one context but unsafe if it releases a suspended load. The safe state is determined by the application, energy, environment and human interaction.

Functional Safety and Assurance

Functional safety addresses hazardous behavior caused by malfunctioning electrical, electronic or programmable systems. Its lifecycle begins with hazard identification and risk assessment, followed by safety requirements, architecture, implementation, verification, validation, operation and decommissioning. Safety integrity is not achieved by a single component; it depends on systematic development, diagnostic coverage, independence, proof testing and controlled changes.

Standards provide structured expectations rather than automatic compliance. IEC 61508 supplies a generic functional-safety framework; ISO 13849 and IEC 62061 are important in machinery safety; ISO 10218 is relevant to industrial robots; ISO 26262 addresses road-vehicle functional safety; and IEC 62443 addresses industrial automation and control-system cybersecurity. The applicable standard depends on the domain, jurisdiction and intended use. Engineers must verify current editions and sector-specific legal requirements.

A safety case is a structured argument supported by evidence that a system is acceptably safe for its intended context. Claims should be linked to requirements, analyses, test results, competence records and configuration data. Traceability is essential: a changed sensor, firmware library or operating procedure may invalidate earlier evidence.

Cybersecurity in Connected Mechatronics

Connectivity expands functionality and attack surface. Threats include unauthorized command injection, credential theft, ransomware, denial of service, manipulation of sensor data, malicious firmware, supply-chain compromise and exposure of production or personal data. Cybersecurity risk is commonly analyzed through assets, threats, vulnerabilities, consequences and existing controls.

A practical defense-in-depth architecture separates business networks, supervisory systems, controllers and safety systems where appropriate; uses least privilege and strong authentication; protects communications; applies secure boot and signed updates; maintains accurate inventories; logs relevant events; and prepares incident-response and recovery procedures. Segmentation reduces the ability of an attacker to move laterally, but it is not a substitute for secure devices and disciplined operations.

Security and safety interact in both directions. A cyberattack may create a physical hazard, while a safety shutdown may create an availability or production problem that encourages unsafe bypassing. Security controls must therefore be evaluated for their effects on real-time performance, emergency access, maintenance and safe recovery. Safety functions should not depend exclusively on a network that can be remotely disabled.

Secure lifecycle practice includes threat modelling during design, vulnerability management, coordinated disclosure, patch assessment, backup validation and end-of-life planning. A patch that fixes a vulnerability can introduce a timing or compatibility fault; consequently, updates require testing, authorization and rollback capability.

Human Factors, Privacy and Responsible AI

Operators and maintainers are part of the system. Poor displays, ambiguous alarms, difficult access, excessive workload, inadequate training and normalization of deviance can transform a recoverable fault into an accident. Human-centered design uses clear status information, prioritized alarms, physical affordances, error-tolerant interfaces, realistic procedures and participatory evaluation. Safety procedures should support informed action rather than rely on perfect attention under stress.

Connected equipment may collect video, biometric information, location, operator identifiers, production data or behavioral records. Privacy governance requires purpose limitation, data minimization, access control, retention limits, transparency and lawful processing. Data collected for predictive maintenance should not automatically be repurposed for employee surveillance.

AI-based diagnosis and control introduce additional concerns: biased or incomplete training data, distribution shift, opaque recommendations, adversarial inputs, automation bias and unclear accountability. An AI system should have a defined operational envelope, performance monitoring, human oversight appropriate to the consequence of error, and a safe fallback. Explainability is not merely a user-interface feature; engineers must be able to investigate why a safety-relevant recommendation was produced.

Responsible governance assigns decision rights and accountability across designers, suppliers, operators, managers and owners. It includes independent review for high-consequence decisions, change control, incident reporting without blame-oriented suppression, and mechanisms for affected people to raise concerns.

Sustainability and Lifecycle Governance

Reliability and sustainability are connected but not identical. A durable product may reduce replacement waste, yet excessive redundancy may increase material and energy use. Predictive maintenance can extend service life, but sensors, communications and cloud computation also have environmental costs. Lifecycle assessment should consider extraction, manufacturing, transport, operation, maintenance and end-of-life recovery.

Design choices should support repairability, modular replacement, safe disassembly, software longevity and responsible material selection. Governance should address obsolete software, unsupported components, supplier dependencies and disposal of batteries or electronic assemblies. Sustainability metrics should be balanced with safety: reducing material or energy consumption must not weaken protective functions.

An Integrated Risk-Management Workflow

A defensible workflow can be organized as follows:

1. Define intended use, operating environment, stakeholders and unacceptable outcomes.

2. Identify hazards, assets, failure modes, threat scenarios and human interactions.

3. Estimate risk using severity, likelihood, exposure and uncertainty; distinguish safety risk from security and privacy risk while examining their interactions.

4. Establish requirements and allocate them to hardware, software, people and procedures.

5. Design inherently safer functions, independent protection layers, diagnostics and secure architecture.

6. Verify each requirement and validate the integrated system in realistic conditions, including foreseeable misuse and degraded modes.

7. Establish monitoring, maintenance, incident response, training and change-control processes.

8. Review field evidence, near misses, vulnerabilities and emerging risks throughout the lifecycle.

Risk matrices are communication tools, not precise substitutes for evidence. Where consequences are catastrophic, conservative assumptions, independent assessment and demonstrable barriers are appropriate. ALARP-type reasoning—reducing risk as far as reasonably practicable—requires documented consideration of alternatives, not merely a claim that further reduction is expensive.

Illustrative Case Study: Secure and Safe Retrofit of a Collaborative Robot Cell

Background

A manufacturing firm operates a collaborative robot that transfers components between a machining station and an inspection fixture. The cell contains force sensing, vision, a programmable controller and a remote maintenance connection. Production management proposes increasing speed and adding cloud-based predictive maintenance.

Situation and Analysis

A preliminary FMEA identifies vision occlusion, force-sensor drift, gripper loss, controller failure and incorrect fixture recognition. The possible effects range from rejected parts to collision or dropped components. An FTA for “person struck by robot” reveals several paths: incorrect human detection, a software timing error, a bypassed protective stop and unauthorized remote commands. The analysis also identifies common dependencies: the vision and inspection cameras share power, and the safety controller and production controller share a communication switch.

Cyber threat modelling finds weak maintenance credentials, an exposed remote-access pathway and an incomplete inventory of firmware versions. Privacy review shows that camera images could identify workers, although identification is not required for the maintenance purpose.

Strategy and Solution

The company separates safety-related communication from the ordinary production network, replaces shared credentials with individual authenticated accounts, restricts remote access through a controlled gateway and records administrative actions. Firmware is signed and updates are tested on a representative cell before deployment. The safety function uses independent protective devices and a monitored emergency-stop circuit rather than relying solely on the vision system.

The robot’s speed and separation limits are validated for the actual tooling and work envelope. Diagnostic tests are scheduled for force and vision sensors, and a degraded mode prevents automatic operation when diagnostic confidence is inadequate. Camera processing is configured to minimize retention and avoid unnecessary identity data. Operators receive training on alarms, recovery and the prohibition of informal bypasses.

Outcome

The retrofit does not eliminate every failure or attack path, but it reduces single points of failure, improves detection and makes recovery controlled and auditable. Production gains are accepted only after safety validation and cybersecurity review. A governance board approves future changes and requires reassessment when tooling, software or remote-access arrangements change.

Learning Points

The case demonstrates that FMEA alone would not reveal all combinations leading to harm, while FTA alone would not provide a complete inventory of component failure modes. Safety and cybersecurity controls must be coordinated, privacy should be designed into data collection, and operational procedures are part of the engineering system. Most importantly, assurance is ongoing: a safe installation can become unsafe through uncontrolled updates or workarounds.

Challenges, Limitations and Common Mistakes

Risk analyses depend on assumptions and data quality. Rare events are difficult to estimate statistically; laboratory tests may not represent field conditions; and failure-rate databases may not reflect new technologies. Independence assumptions can overstate the benefit of redundancy. AI performance measured on historical data may collapse under changed loads or environments.

Common mistakes include treating compliance as equivalent to safety, choosing a safe state without considering the physical context, ignoring maintenance and commissioning, relying on one security boundary, accepting unexplained AI outputs, assigning responsibility only after an incident, and ranking risks mechanically through a numerical matrix. Another error is separating safety, security, quality and sustainability into incompatible organizational silos. Integrated reviews are needed because controls in one domain can create risks in another.

Current Developments and Best Practice

Digital twins, edge analytics and condition monitoring are improving early fault detection, but their outputs require validation and cybersecurity protection. Software bills of materials are increasingly used to identify vulnerable dependencies. Secure-by-design procurement, zero-trust principles, formal methods for selected safety-critical software, continuous vulnerability monitoring and independent assurance are becoming more prominent.

Good practice includes:

• define safety, security, privacy and sustainability requirements before selecting technology;
• maintain traceability from hazard and threat to requirement, test and operational control;
• use diverse teams involving controls engineers, software specialists, maintainers, operators, cybersecurity professionals and ethicists where appropriate;
• test abnormal, degraded, adversarial and foreseeable misuse conditions;
• make changes reversible and preserve configuration history;
• treat near misses and security events as learning opportunities;
• provide clear ownership, escalation routes and resources for corrective action.

Chapter Summary

Reliable and responsible mechatronic systems require more than dependable components. Reliability, maintainability, availability and resilience describe different system properties, while safety and cybersecurity address distinct but interacting forms of risk. FMEA provides a bottom-up examination of failure modes; FTA reasons backward from hazardous events; diagnostic methods, redundancy and fail-safe architecture reduce the likelihood or consequences of failure. Functional safety requires lifecycle management, traceability and evidence rather than informal confidence.

Connected systems must be protected through defense in depth, secure updates, access control, segmentation and prepared response. Human factors, privacy, AI limitations, sustainability and accountability must be included in engineering governance. Standards guide practice, but responsible decisions still require context-specific analysis, validation, independent review and continuous learning.

Key Terms

Reliability: Probability that a system performs its required function for a specified time and conditions.

Availability: Probability or proportion of time that a system is operational and accessible.

Maintainability: Ease and speed with which a system can be restored after failure.

Resilience: Capacity to withstand, adapt to and recover from disruption.

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

FTA: Top-down logical analysis of combinations causing an undesired top event.

Common-cause failure: Failure of multiple channels due to a shared cause.

Redundancy: Provision of additional elements or methods to preserve function after failure.

Diagnostic coverage: Ability of a diagnostic mechanism to detect relevant failures.

Fail-safe: Design that moves toward a condition with reduced hazard after failure.

Fail-operational: Design that maintains an essential function after specified failures.

Functional safety: Reduction of hazardous behavior caused by malfunctioning safety-related systems.

Safety case: Structured argument, supported by evidence, that a system is acceptably safe.

Threat modelling: Systematic identification of assets, threats, vulnerabilities and consequences.

Defense in depth: Use of multiple independent or layered protective measures.

Least privilege: Limiting access rights to those necessary for an authorized task.

Privacy by design: Incorporating privacy protection into system architecture and operation.

Automation bias: Tendency to over-trust automated recommendations or decisions.

Traceability: Ability to link requirements, implementation, verification and change records.

ALARP: Reduction of risk as far as reasonably practicable, supported by documented judgment.

Review Questions

Short Answer Questions

1. Distinguish reliability from availability and maintainability.

2. What is the purpose of a minimal cut set in fault-tree analysis?

3. Why can identical redundancy fail to protect against common-cause failure?

4. Define diagnostic coverage and explain why it does not by itself guarantee safety.

5. State two privacy principles relevant to predictive maintenance data.

Long Answer Questions

1. Explain how FMEA and FTA complement one another in the safety analysis of a robotic system.

2. Discuss the lifecycle activities required to establish functional safety in a programmable mechatronic system.

3. Explain defense-in-depth cybersecurity for an industrial control system and its relationship to safety.

4. Compare fail-safe and fail-operational design, using suitable mechatronic examples.

5. Discuss how human factors, AI ethics and responsible governance influence engineering assurance.

Analytical / Application Questions

1. A two-channel sensor arrangement uses identical sensors supplied from a common power unit. Analyze the reliability benefit and identify the additional failure mechanisms that must be investigated.

2. A remote maintenance update causes intermittent timing faults in a robot controller. Propose an integrated safety, cybersecurity and change-control response.

3. Design an FMEA and outline an FTA for a conveyor system whose actuator may start unexpectedly while an operator is clearing a jam. Identify at least three prevention or mitigation measures.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes reliability from availability?

A. Reliability concerns repair speed, while availability concerns failure probability

B. Reliability concerns failure-free operation for a stated period, while availability includes restoration after failures

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

D. Reliability and availability are identical measures

Correct Answer: B. Reliability concerns failure-free operation for a stated period, while availability includes restoration after failures

Question 2

In an FTA, an AND gate indicates that the output event occurs when:

A. Any one input event occurs

B. No input event occurs

C. All required input events occur together

D. The most severe input event occurs

Correct Answer: C. All required input events occur together

Question 3

What is a major limitation of relying only on a numerical risk-priority number in FMEA?

A. It cannot record failure causes

B. It may hide the importance of a catastrophic but infrequent failure

C. It prevents identification of detection controls

D. It applies only to mechanical components

Correct Answer: B. It may hide the importance of a catastrophic but infrequent failure

Question 4

Which condition most threatens the benefit of redundant safety channels?

A. Independent sensing principles

B. Separate power supplies

C. A shared environmental disturbance affecting both channels

D. Independent verification of channel software

Correct Answer: C. A shared environmental disturbance affecting both channels

Question 5

A fail-safe response is best described as:

A. Maintaining maximum production after any fault

B. Moving toward a state in which hazards are minimized after a fault

C. Preventing all component failures

D. Allowing remote access during emergencies

Correct Answer: B. Moving toward a state in which hazards are minimized after a fault

Question 6

Which cybersecurity measure most directly limits lateral movement after a controller is compromised?

A. Network segmentation

B. Increasing actuator speed

C. Removing event logs

D. Using identical passwords across devices

Correct Answer: A. Network segmentation

Question 7

Why should an AI diagnostic system have a defined operational envelope?

A. To ensure it is never updated

B. To identify conditions in which its performance and recommendations can be trusted

C. To eliminate the need for human oversight

D. To guarantee that all failures are detected

Correct Answer: B. To identify conditions in which its performance and recommendations can be trusted

Question 8

In the illustrative robot-cell case, why was the vision system not treated as the sole protective measure?

A. Vision systems cannot inspect components

B. A single sensing method may fail, be occluded or be manipulated

C. Vision systems always consume excessive energy

D. Safety standards prohibit all cameras

Correct Answer: B. A single sensing method may fail, be occluded or be manipulated

Question 9

Which practice best supports lifecycle assurance?

A. Allowing undocumented firmware changes

B. Separating requirements from test evidence

C. Maintaining traceability between hazards, requirements, tests and changes

D. Treating commissioning as the end of safety management

Correct Answer: C. Maintaining traceability between hazards, requirements, tests and changes

Question 10

What is privacy by design in a connected mechatronic system?

A. Collecting all available data for possible future use

B. Embedding minimization, access control and retention limits into the system architecture

C. Storing personal data indefinitely

D. Replacing safety analysis with encryption

Correct Answer: B. Embedding minimization, access control and retention limits into the system architecture