Reliability, Safety, Cybersecurity and Governance

Introduction

A mechatronic system combines mechanical structures, sensors, actuators, electronics, embedded software, communications and human interaction. Its engineering quality therefore cannot be judged only by whether it performs its intended function during a demonstration. A production robot, autonomous vehicle, medical device or industrial controller must also operate reliably, fail safely, resist malicious interference, protect information and comply with legal and professional obligations.

These concerns are interconnected. A failed sensor may create a safety hazard; an unpatched controller may allow a cyberattack; poor configuration management may make it impossible to determine which safety functions are installed; and unclear responsibility may delay corrective action. Reliability, safety, cybersecurity and governance must consequently be addressed throughout the system life cycle: concept, requirements, design, implementation, verification, commissioning, operation, maintenance, modification and retirement.

This chapter develops practical methods for identifying hazards, analysing failure, designing protective functions, estimating reliability, applying functional-safety principles, securing connected systems and governing data and professional decisions.

Learning objectives

After studying this chapter, students should be able to:

1. Distinguish reliability, availability, safety, security and resilience.
2. Perform a preliminary hazard analysis and construct a basic FMEA.
3. Explain fail-safe, fault-tolerant and defence-in-depth design.
4. Use elementary reliability and availability equations appropriately.
5. Relate functional safety to the risk-reduction process and safety integrity.
6. Apply secure-by-design principles to mechatronic architectures.
7. Explain the roles of standards, data governance, ethics and regulation.
8. Recommend assurance activities for a mechatronic system across its life cycle.

1. Core concepts and their relationships

Reliability is the probability that an item performs its required function for a specified time, under stated conditions. It is concerned primarily with unintended loss of function. Maintainability is the ability to be retained or restored to a specified condition through maintenance. Availability is the proportion of time that a system is capable of performing its required function. Safety is freedom from unacceptable risk of physical injury or damage. Cybersecurity is the protection of systems, networks and data against unauthorized access, alteration, disruption or destruction. Governance establishes who has authority, which rules apply, how decisions are recorded and how compliance is demonstrated.

These properties are not interchangeable. A system may be reliable but unsafe if it reliably performs a dangerous action. It may be safe but unavailable if it enters shutdown too frequently. It may be physically safe yet insecure if an attacker can manipulate its motion commands. A resilient system anticipates disruption, limits consequences, recovers and learns.

Risk is commonly described as a combination of the likelihood of a hazardous event and its consequence. In qualitative engineering practice, risk is often represented as a matrix. Numerical probability should not be implied when categories such as “unlikely” or “severe” have not been calibrated with evidence. Risk reduction should follow a hierarchy: eliminate the hazard where feasible; use inherently safer design; add engineering guards and protective devices; provide warnings and procedures; and use personal protective equipment only as the last layer.

2. Hazard analysis

A hazard is a potential source of harm. A hazardous situation occurs when people, property or the environment are exposed to the hazard. An accident is an undesired event that produces harm; an incident may be a near miss or other undesired event without injury.

A hazard analysis begins by defining the system boundary, intended use, reasonably foreseeable misuse, operating modes, users, environment, interfaces and life-cycle stages. Typical mechatronic hazards include:

• unexpected movement, crushing, shearing, entanglement and impact;
• stored electrical, hydraulic, pneumatic or mechanical energy;
• excessive temperature, pressure, noise, radiation or chemical exposure;
• loss of braking, steering, containment or position control;
• software or sensor faults that generate unsafe commands;
• cyber compromise of controllers, safety settings or maintenance access.

A useful preliminary hazard analysis records the hazard, initiating causes, hazardous event, consequence, existing controls, required additional controls and responsible owner. Analysis should include normal operation, setup, teaching, cleaning, maintenance, fault recovery and disposal. Human factors matter: confusing displays, poorly located emergency stops, alarm overload and ambiguous procedures can convert a technically minor fault into a serious event.

Fault-tree analysis (FTA) is a top-down method. It begins with a top event, such as “robot moves while a person is inside the cell,” and decomposes it using logical gates into contributing failures. An AND gate means all input events are required; an OR gate means any input event can produce the output. FTA supports causal reasoning and, when credible probabilities are available, quantitative estimation. Its results depend on assumptions about independence and complete identification of causes.

Event-tree analysis is complementary. It starts with an initiating event and follows alternative success or failure of protective functions. For example, after loss of position feedback, the branches may represent successful detection, successful controlled stop, or failure of either function. FTA asks “what can cause this?”; event-tree analysis asks “what can happen after this?”

3. Failure Modes and Effects Analysis

FMEA is a bottom-up, structured examination of how component or function failures affect the system. A team lists each function, failure mode, local effect, end effect, cause, existing detection or control and recommended action. Examples include an encoder producing a constant value, a valve stuck open, a brake failing to engage, corrupted firmware or a network switch losing power.

Traditional FMEA may score severity (S), occurrence (O) and detection (D), commonly on ordinal scales such as 1–10. A risk priority number is sometimes calculated as:

Here S, O and D are ordinal ratings, not measured probabilities. The product is therefore a prioritization aid rather than a scientifically valid risk estimate. A high-severity failure should not be ignored merely because its RPN is moderate, and teams should record the rationale for every rating. Contemporary practice often supplements or replaces RPN with action priority, explicit severity thresholds and quantitative reliability or safety analysis.

Worked example: simplified FMEA

Consider an automated palletizer. A guard-door switch may fail in the closed state. The effect is that the controller can incorrectly infer that access is safe. If severity is rated 9, occurrence 3 and detection 7, then RPN = 9 × 3 × 7 = 189. The number does not prove that this failure is more dangerous than every failure with a lower score. Because the consequence is potentially severe, the design response should include a monitored, positively guided switch, a second independent protective measure where justified, diagnostic testing and validation of the stop function.

FMEA quality depends on multidisciplinary participation, accurate operating information, traceable assumptions and review after design changes or field incidents. Software, human actions, common-cause failures and cybersecurity abuse cases must not be excluded simply because the method originated in hardware analysis.

4. Reliability engineering

For a non-repairable component with a constant failure rate λ, the exponential model gives the reliability function:

where R(t) is the probability of surviving to time t, λ is the constant failure rate in failures per unit time, and t is time in the same unit. The model assumes statistically independent failures, a constant hazard rate and operation within specified conditions. It is often a useful approximation during the useful-life period, but it is not universally valid; infant mortality and wear-out require other models or field evidence.

The mean time to failure under this model is:

For independent components in a series system, every component must function, so:

If two independent components provide true parallel redundancy and the system works when at least one works:

These equations assume independence and ideal switching or architecture. Real redundancy can be defeated by common-cause failures, shared power, shared software, environmental stress or a defective change process.

For repairable systems, steady-state availability is often approximated by:

MTBF is mean time between failures and MTTR is mean time to repair, both measured in the same time unit. This approximation assumes a stable long-run process, well-defined repair completion and suitable statistical conditions. It does not mean that every individual system will operate for exactly MTBF hours.

Worked reliability example

A controller has a constant failure rate of 0.0002 failures per hour. For a 1,000-hour mission, λt = 0.0002 × 1000 = 0.2, and therefore R(1000) = e^(−0.2) ≈ 0.819. The probability of at least one failure during the mission is approximately 1 − 0.819 = 0.181, or 18.1%, under the model assumptions. If the controller is one of two independent, identical parallel units, ideal redundancy gives 1 − (1 − 0.819)² ≈ 0.967. This optimistic result must be reduced in practice if both units share a power supply, software defect or environmental cause.

Reliability improvement methods include derating, thermal management, component qualification, robust mechanical design, preventive maintenance, built-in test, diagnostic coverage, spare-parts planning and root-cause analysis. Reliability demonstration testing must reflect actual duty cycles and environmental conditions rather than only nominal laboratory operation.

5. Fail-safe and functional-safety design

A fail-safe design moves to a defined safer state when a fault occurs. For a machine, this may mean removing drive energy and applying a brake; for a process, it may mean closing a valve or depressurizing a vessel. The safe state is application-dependent: removing power from a medical ventilator, for example, may itself be hazardous. Fail-safe behaviour must therefore be established through hazard analysis, not assumed.

Fault tolerance allows continued operation after some failures, usually through redundancy, reconfiguration or graceful degradation. Fail-safe and fault-tolerant strategies can coexist. A vehicle may continue steering after one sensor failure while ensuring that a second fault causes a controlled stop.

Functional safety concerns the ability of electrical, electronic and programmable electronic safety-related systems to achieve or maintain a safe state. The engineering process normally includes allocation of safety requirements, architecture selection, diagnostic design, verification, validation, proof testing, management of changes and evidence of competence. Safety integrity is not simply “software quality”; it concerns the probability that a safety function performs when demanded or over time, according to the applicable framework.

Important design principles include:

• De-energize to trip: loss of energy causes the protective action where appropriate.
• Positive guidance and monitored contacts: faults such as welded contacts are detectable.
• Two-channel architecture: independent channels reduce the effect of a single fault, but require measures against common causes.
• Diagnostic coverage: tests identify dangerous failures before a demand.
• Manual reset and restart interlock: clearing a fault does not automatically restart hazardous motion.
• Independent safety path: a standard control program should not be the sole protection for a critical hazard.
• Validation under abnormal conditions: test broken wires, short circuits, stuck inputs, communication loss, power cycling and timing faults.

Standards are selected by application and jurisdiction. ISO 12100 addresses machinery risk assessment and risk reduction; IEC 61508 provides a generic functional-safety framework; ISO 13849 and IEC 62061 are important for machinery control systems; IEC 62443 addresses industrial automation and control-system cybersecurity; ISO/SAE 21434 addresses road-vehicle cybersecurity. IEC 60204-1 concerns electrical equipment of machines, while ISO 10218 is relevant to industrial robots. Standards are not interchangeable legal advice: the designer must identify the regulations and harmonized or adopted standards applicable to the product and market.

6. Cybersecurity for mechatronic systems

Connectivity expands capability and attack surface. Threats include unauthorized remote commands, ransomware, firmware replacement, denial of service, manipulation of sensor data, theft of production data, insecure maintenance laptops and supply-chain compromise. The consequences can be physical, not merely informational.

A secure-by-design process begins with asset identification and threat modelling. Assets may include PLCs, safety controllers, robots, drives, engineering workstations, credentials, recipes, logs and intellectual property. The team identifies trust boundaries, entry points, adversaries, attack paths and consequences. Security requirements should then be derived from system risk, not bolted on after commissioning.

Practical controls include:

1. Secure architecture: segment corporate IT, supervisory systems, control networks and safety functions; restrict traffic through managed gateways.
2. Identity and access management: use unique accounts, least privilege, strong authentication and controlled vendor access.
3. Secure development: threat modelling, code review, static analysis, dependency control, signed firmware and reproducible release records.
4. Resilience: tested backups, recovery procedures, redundant communications where justified and safe local fallback modes.
5. Monitoring: synchronized logs, anomaly detection and incident escalation without overwhelming operators.
6. Lifecycle maintenance: vulnerability disclosure, patch assessment, update testing, asset inventories and end-of-support planning.

Cybersecurity controls must not undermine safety. A security mechanism that blocks an emergency stop is unacceptable; conversely, an unauthenticated maintenance port may allow a dangerous command. Safety functions should be designed to remain effective during loss of ordinary communications, and cyber incident procedures should define when to isolate equipment, stop production, preserve evidence and notify authorities.

Artificial intelligence can assist anomaly detection, predictive maintenance and inspection, but it introduces model drift, false alarms, opaque decisions and adversarial manipulation. AI should not be treated as an unquestionable safety barrier. Its performance must be bounded, monitored and supported by deterministic protective functions where consequences are severe.

7. Data governance, ethics and regulation

Mechatronic systems generate operational logs, video, location data, biometric information, maintenance records and worker-performance indicators. Governance addresses ownership, purpose, quality, retention, access, privacy, integrity, provenance and disposal. A useful data classification scheme distinguishes public, internal, confidential and highly restricted data, with controls proportionate to harm.

Good governance requires a data inventory, named stewardship, documented purpose, minimum necessary collection, access approval, retention schedule, audit trail, backup and secure deletion. Personal data should be collected lawfully and transparently, used for specified purposes and protected against unauthorized disclosure. Applicable privacy law varies by jurisdiction; engineers must consult the relevant legal and institutional requirements rather than assuming that technical access equals permission.

Professional ethics requires engineers to protect public safety, disclose limitations, maintain competence, avoid conflicts of interest, respect privacy and report credible hazards. If production pressure conflicts with a known serious safety defect, professional responsibility requires escalation and evidence-based action. Records should make clear what was known, who decided, what assumptions were made and which residual risks were accepted.

Regulatory responsibility extends beyond design. It includes conformity assessment, technical files, declarations, labeling, installation instructions, training, incident reporting, change control and post-market surveillance where applicable. A modification to software, safety parameters or network architecture can invalidate previous validation and require re-assessment.

8. Assurance across the life cycle

Assurance is the planned production of confidence supported by evidence. A practical assurance plan links each requirement to analysis, implementation, verification and validation evidence. Verification asks whether the system was built according to its specified requirements; validation asks whether it meets the intended need in its operational context.

Useful evidence includes hazard logs, FMEA and FTA records, requirements traceability, design reviews, test procedures, test results, code and configuration baselines, cybersecurity assessments, training records, maintenance data and incident reports. Independence in review is valuable: the person who wrote a safety function should not be its only validator.

A change-control board or equivalent process should evaluate modifications for effects on safety, reliability, cybersecurity, compliance and interoperability. Configuration management identifies the exact hardware, firmware, parameters and documents in service. Without it, an incident investigation may compare the wrong versions and corrective actions may be ineffective.

9. Illustrative case: connected collaborative palletizer

Background

A manufacturing company deploys a collaborative palletizer with an electric gripper, vision sensor, programmable controller, cloud-connected maintenance gateway and safety-rated protective scanner. Operators load pallets and occasionally enter the work area to clear material.

Problem

During commissioning, the scanner intermittently reports a clear field after reflective packaging is moved. At the same time, a vendor laptop uses a shared password to access the controller. The machine has no documented restart interlock test, and maintenance records do not identify firmware versions.

Analysis

The hazard is unexpected robot movement while a person is exposed. FMEA identifies scanner misdetection, incorrect configuration, communication loss, controller logic error and unauthorized parameter change as causes. FTA shows that hazardous motion can occur if the scanner fails to detect presence and the safety stop path fails to prevent motion. The shared password creates a cybersecurity route to the same consequence. A reliability-only analysis would miss this interaction.

Approach and solution

The company first stops production and performs a documented risk assessment. It validates scanner performance with representative packaging, lighting and approach paths. The safety function is redesigned so that invalid, lost or inconsistent scanner data produces a controlled stop; reset is manual and outside the hazard zone; restart requires a fresh permissive sequence. Safety parameters are protected from ordinary operator accounts, vendor access uses named accounts and time-limited approval, and the maintenance gateway is segmented from the safety network. Firmware and parameter baselines are recorded, backups are tested and incident logs are retained. Independent personnel witness tests for intrusion, communication loss, power restoration, sensor obstruction and restart.

Outcome

The machine achieves a demonstrable safe response to the tested faults, while maintenance access becomes auditable. The company also discovers that a planned software update would have changed scanner timing, so change control triggers revalidation before release.

Learning points

The case illustrates that safety and cybersecurity share consequences but require distinct controls. Redundancy is not automatically independence; a common network, password or configuration can defeat it. Evidence, competence and lifecycle control are as important as the initial design.

Challenges and limitations

No analysis method guarantees safety. FMEA can become a paperwork exercise, miss interactions and underestimate software or human failures. FTA may rely on unrealistic independence assumptions. Reliability data may be sparse, nonrepresentative or distorted by under-reporting. Risk matrices can create false precision. Standards provide structured expectations but do not replace engineering judgment or legal interpretation.

Cybersecurity is continually changing: newly discovered vulnerabilities, obsolete components and supply-chain dependencies can alter risk after deployment. Safety and security may compete for resources, availability and access, requiring explicit trade-off decisions. Finally, residual risk cannot always be eliminated. It must be reduced so far as reasonably practicable, communicated to affected people and accepted by an authorized, accountable decision-maker.

Best-practice checklist

• Define intended use, foreseeable misuse and system boundaries.
• Identify hazards and cyber assets before selecting controls.
• Prefer inherent risk reduction over warnings and procedures.
• Use FMEA, FTA or event trees according to the question being asked.
• Treat high-severity hazards explicitly rather than relying only on RPN.
• Design safe states, diagnostics, manual reset and restart prevention.
• Consider common-cause failures in every redundancy claim.
• Segment networks and apply least privilege from the beginning.
• Maintain traceability between requirements, tests, configurations and incidents.
• Reassess risk after hardware, software, parameter or network changes.
• Protect personal and operational data through purpose limitation and access control.
• Escalate unresolved risks and preserve professional independence.

Chapter Summary

Reliable mechatronic engineering requires more than preventing component failure. Reliability concerns continuity of intended function; safety concerns unacceptable physical risk; cybersecurity concerns hostile or unauthorized interference; and governance concerns accountable, lawful and traceable decision-making. Hazard analysis defines dangerous situations and supports the hierarchy of controls. FMEA examines failure modes from the component or function upward, while FTA and event trees reason from hazardous outcomes or initiating events.

Elementary reliability models can estimate survival, series and parallel behaviour, and repairable availability, but their assumptions must be stated. Fail-safe design establishes a safe response to faults, whereas fault tolerance maintains operation through redundancy or reconfiguration. Functional safety requires requirements allocation, diagnostics, validation, independence and lifecycle evidence.

Secure-by-design practice includes asset identification, threat modelling, segmentation, identity control, secure updates, monitoring and recovery. Safety and cybersecurity must be coordinated without allowing security mechanisms to obstruct essential protective functions. Data governance, ethics, standards, regulation and change control complete the professional responsibility of the mechatronics engineer.

Key Terms

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

Availability: Proportion of time a repairable system is capable of performing its required function.

Maintainability: Ability to restore or retain a specified condition through maintenance.

Safety: Freedom from unacceptable risk of harm.

Cybersecurity: Protection against unauthorized access, alteration, disruption or destruction.

Hazard: Potential source of harm.

Risk: Combination of likelihood and consequence associated with harm.

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

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

Event-tree analysis: Forward analysis of consequences following an initiating event.

Fail-safe design: Design that moves to a defined safer state after a fault.

Fault tolerance: Ability to continue specified operation after selected faults.

Functional safety: Safety achieved through safety-related control and protection functions.

Diagnostic coverage: Extent to which dangerous failures are detected by diagnostics.

Common-cause failure: Failure of supposedly independent elements from a shared cause.

Defence in depth: Multiple independent or diverse layers of protection.

Threat modelling: Structured identification of assets, adversaries, attack paths and consequences.

Data governance: Rules and responsibilities for data quality, access, use, retention and protection.

Configuration management: Control and identification of system versions, parameters and changes.

Residual risk: Risk remaining after protective measures have been applied.

Review Questions

5 Short Answer Questions

1. Distinguish reliability, availability and safety.
2. What is the purpose of a preliminary hazard analysis?
3. State one assumption of the exponential reliability model.
4. Why is a high FMEA severity rating not necessarily neutralized by a low RPN?
5. Define fail-safe design and give one mechatronic example.

5 Long Answer Questions

1. Explain how FMEA, fault-tree analysis and event-tree analysis complement one another.
2. Discuss the limitations of redundancy in a connected control system.
3. Describe a secure-by-design process for an industrial robot.
4. Explain how functional-safety evidence should be produced across the system life cycle.
5. Analyse the ethical and regulatory responsibilities of an engineer who discovers an untested safety modification.

3 Analytical / Application Questions

1. A machine has a hazardous actuator, a position sensor and a protective scanner. Construct a preliminary hazard analysis for unexpected motion and recommend layered controls.
2. A component has λ = 0.0001 failures per hour. Estimate its 2,000-hour reliability using the exponential model, state the assumptions and interpret the result.
3. Design a governance and cybersecurity improvement plan for a factory in which vendor laptops share passwords and controllers are connected directly to the corporate network.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes safety from reliability?

A. Safety concerns only software, whereas reliability concerns only hardware.

B. Safety concerns unacceptable harm risk, whereas reliability concerns continued intended function.

C. Safety is measured only by availability, whereas reliability is measured only by cost.

D. Safety and reliability are identical terms.

Correct Answer: B. Safety concerns unacceptable harm risk, whereas reliability concerns continued intended function.

Question 2

In an FMEA, what does a failure mode describe?

A. The financial cost of a product

B. The way a function or component can fail

C. The final legal approval of a design

D. The number of operators assigned to a machine

Correct Answer: B. The way a function or component can fail

Question 3

For a constant failure rate λ, which expression gives exponential reliability?

A. R(t) = λt

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

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

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

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

Question 4

A fail-safe machine design should generally do what when a relevant fault occurs?

A. Continue at maximum speed

B. Move to a defined safer state

C. Disable all diagnostic records

D. Automatically restart without verification

Correct Answer: B. Move to a defined safer state

Question 5

Why can parallel redundancy provide less benefit than its ideal equation suggests?

A. Parallel systems cannot contain sensors

B. Redundant elements may share common-cause failures

C. Redundancy always increases failure rate to 100%

D. Parallel elements never require power

Correct Answer: B. Redundant elements may share common-cause failures

Question 6

Which practice is most consistent with least privilege?

A. Giving every operator administrator rights

B. Using one permanent vendor password

C. Granting each user only the access needed for assigned duties

D. Allowing anonymous engineering access

Correct Answer: C. Granting each user only the access needed for assigned duties

Question 7

What is the primary purpose of configuration management?

A. To increase motor torque

B. To identify and control system versions, parameters and changes

C. To replace all safety testing

D. To eliminate the need for maintenance

Correct Answer: B. To identify and control system versions, parameters and changes

Question 8

Which method starts with a top event and logically decomposes its causes?

A. Fault-tree analysis

B. Event-tree analysis

C. Preventive maintenance

D. Data classification

Correct Answer: A. Fault-tree analysis

Question 9

A controller has λ = 0.0002 failures per hour. Under the exponential model, its reliability at 1,000 hours is approximately:

A. 0.181

B. 0.500

C. 0.819

D. 1.200

Correct Answer: C. 0.819

Question 10

Why should an AI anomaly detector not normally be the sole protective barrier for a severe physical hazard?

A. AI systems cannot process any data

B. AI models may drift, produce false results or be manipulated

C. AI always prevents emergency stops

D. AI removes the need for validation

Correct Answer: B. AI models may drift, produce false results or be manipulated