Risk, Reliability, Safety, and Cybersecurity Governance

Introduction

Mechatronic systems combine mechanical structures, sensors, actuators, embedded controllers, software, communications networks, and human operators. This integration creates capability, but also creates coupled failure modes. A sensor fault can cause unsafe control action; a software update can change mechanical behaviour; a network compromise can disable a safety function. Consequently, risk cannot be managed by treating hardware, software, safety, and cybersecurity as separate subjects.

Governance is the organised direction, control, assurance, and accountability applied throughout the system life cycle. Effective governance establishes acceptable risk, assigns decision authority, preserves evidence, and ensures that hazards and vulnerabilities are controlled from concept through decommissioning.

Learning Objectives

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

1. Construct and maintain a risk register for a mechatronic system.
2. Apply FMEA and fault-tree analysis and interpret their limitations.
3. Calculate and interpret reliability, availability, maintainability, and failure-rate measures.
4. Explain functional safety, safety integrity, resilience, and defence in depth.
5. Apply secure-by-design principles to industrial control and connected mechatronic systems.
6. Develop an incident-governance process linking safety, reliability, and cybersecurity.

1. Risk as a Systems-Governance Problem

Risk is commonly understood as the effect of uncertainty on objectives. In engineering practice, it is often represented as a combination of the likelihood of an undesired event and its consequence. This representation is useful, but risk is not always adequately described by multiplying two numbers. Rare catastrophic events, correlated failures, uncertainty in data, and deliberate attacks require judgement and structured evidence.

A risk register is a controlled record of risks. Typical fields include risk ID, system element, hazard or threat, initiating cause, event, consequence, existing controls, likelihood, severity, risk owner, treatment action, due date, verification evidence, and residual risk. The owner is accountable for treatment; the technical team supplies analysis and evidence; management accepts or rejects residual risk.

A useful risk statement has the form: Because of [cause], [event] may occur, resulting in [consequence], affecting [asset or objective]. This separates causes from consequences and avoids vague entries such as “software risk.”

Risk treatment may involve avoiding the activity, reducing likelihood, reducing consequence, transferring part of the financial exposure, or accepting residual risk with explicit authority. Controls should follow the hierarchy of controls: inherently safer design, engineered safeguards, administrative controls, and personal protective measures. Warnings and procedures are important but generally less reliable than physical or automatic controls.

Risk-ranking example

Suppose a robotic fixture has a possible unexpected clamp closure. A preliminary team rates severity as 5 on a defined five-level scale and likelihood as 2. A simple matrix score is:

Here, R is the matrix score, S is severity, and L is likelihood. The result has no physical unit and is meaningful only within the organisation’s agreed matrix. It is not a probability and must not be compared directly with a quantified annual fatality risk. The team should next identify safeguards, such as trapped-key access, dual-channel monitoring, and validated stop functions, then reassess residual risk.

2. Hazard Analysis and Risk Registers

A hazard is a potential source of harm; a hazardous situation occurs when people, assets, or the environment are exposed to that hazard; harm is the resulting injury, loss, or damage. A threat is a potential intentional or accidental action that can exploit a vulnerability. An asset is something requiring protection, such as a person, controller, recipe, production capability, or safety function.

A sound analysis proceeds through the following logic:

1. Define system boundaries, operating modes, interfaces, users, and foreseeable misuse.
2. Identify energy sources, motion, pressure, temperature, chemicals, stored energy, and information assets.
3. Identify initiating events and credible combinations of failures.
4. Estimate consequence and likelihood using documented criteria.
5. Select controls according to the hierarchy of controls.
6. Verify that controls work under normal, fault, maintenance, and recovery conditions.
7. Record assumptions, evidence, owners, and review dates.

Risk registers should be living configuration-controlled documents. A changed actuator, network connection, firmware version, supplier, or operating duty may invalidate previous assumptions. Risk acceptance should therefore be linked to change control and management of obsolescence.

3. Failure Modes and Effects Analysis

FMEA is a bottom-up method. For each component or function, the team identifies its failure mode, local effect, system effect, cause, current controls, and recommended action. Examples include an encoder giving a constant value, a valve failing open, a controller losing communication, or a power supply becoming intermittent.

Many organisations score severity, occurrence, and detection from 1 to 10 and calculate a risk priority number:

S is severity, O is occurrence, and D is detection difficulty as defined by the organisation. Higher detection scores normally mean poorer detectability. RPN is ordinal, not a probability, and multiplication can hide an unacceptable high-severity failure behind low occurrence. Therefore, high-severity items require attention even when RPN is modest. Action priority categories or criticality rules are often preferable to RPN alone.

FMEA is strongest when the team understands component functions and failure behaviour. Its limitations include dependence on expert judgement, difficulty representing simultaneous failures, and weak treatment of human, software, and malicious causes. Design FMEA examines product design; process FMEA examines manufacturing or service processes; system FMEA examines interactions and functions.

4. Fault-Tree Analysis

Fault-tree analysis (FTA) is a top-down, deductive method. The analyst begins with a top event, such as “person exposed to hazardous motion,” and decomposes it through logical gates into basic events. An AND gate requires all input events; an OR gate requires at least one input event.

For independent events, an OR gate with events A and B has probability:

For an AND gate:

These equations assume that event probabilities refer to the same time interval and that independence applies where multiplication is used. If events are dependent, common-cause analysis or conditional probabilities are required.

For small probabilities, the OR expression is approximately P(A ∪ B) ≈ P(A) + P(B), but the exact expression should be used when accuracy matters. FTA helps identify minimal cut sets: combinations of basic events sufficient to produce the top event. It complements FMEA: FMEA asks what happens when a component fails; FTA asks how a feared system event can occur.

5. Reliability, Availability, and Maintainability

Reliability is the probability that an item performs its required function for a stated time, under stated conditions. For a constant failure rate λ and statistically independent failure behaviour, the exponential model is:

Here, R(t) is reliability at time t, λ is the constant failure rate in failures per hour, and e is the base of natural logarithms. The model assumes a constant hazard rate and is most appropriate during the useful-life region, not during early infant mortality or wear-out.

The mean time to failure for this model is:

For repairable equipment, mean time between failures (MTBF) is used carefully because definitions vary. Under a simple steady-state interpretation:

A is inherent or operational availability under the stated definition, MTTR is mean time to repair, and both time quantities use the same units. This expression excludes or includes logistics, preventive maintenance, and administrative delays depending on the selected availability definition; the definition must therefore be declared.

Maintainability concerns the probability that failed equipment can be restored within a specified time. A commonly used constant repair-rate model is:

where μ is the repair rate and t is repair time. The model assumes exponentially distributed repair times and a constant repair rate.

Worked reliability example

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

Thus, under the model assumptions, the probability of surviving the interval without failure is approximately 98.02%. This is not a guarantee for every unit; it is a population-model estimate. Environmental conditions, maintenance, common-cause failures, and nonconstant ageing may make the estimate inaccurate.

For independent series components, system reliability is:

For a parallel arrangement in which the system works if at least one independent component works:

Redundancy improves reliability only if switching, independence, power, communications, maintenance, and common-cause assumptions are valid. Two identical sensors exposed to the same vibration or flawed software are not independent merely because there are two of them.

6. Functional Safety and Resilience

Functional safety is the part of overall safety that depends on a system or equipment responding correctly to inputs. Examples include emergency stopping, overspeed protection, safe torque off, pressure shutdown, and interlocked access.

A safety lifecycle normally includes hazard analysis, allocation of safety functions, specification of required integrity, design, verification, validation, operation, proof testing, modification, and retirement. Safety functions should be independent enough from the control system that a control failure does not defeat the safeguard. The required performance or integrity level is determined by risk assessment, not selected merely because a component is marketed as “safety-rated.”

Important principles include fail-safe behaviour, fault detection, diagnostic coverage, separation of channels, control of systematic faults, secure configuration, and proof-test planning. A guard that prevents access is a protective measure; a sensor detecting guard opening and commanding a safe stop is a safety function. Both must be validated in the actual application.

Resilience is the capability to withstand, adapt to, recover from, and learn from disruption. Reliability seeks failure-free operation; resilience recognises that failures and attacks will occur. Resilient design may include graceful degradation, manual fallback, spare capacity, segmented networks, safe states, backups, recovery exercises, and lessons-learned processes. Safety and resilience can conflict: a rapid restart may restore production but create danger unless the safe state and restart conditions are verified.

7. Cybersecurity Governance in Industrial Systems

Industrial cybersecurity protects the confidentiality, integrity, and availability of systems while giving priority to safe and continuous operation. In operational technology, availability and integrity may be more immediately consequential than confidentiality. A compromised set point, timestamp, calibration file, or safety configuration can cause physical harm without destroying equipment.

Secure-by-design means security requirements are established before implementation rather than added after deployment. Core practices include:

• asset inventory with ownership, software versions, data flows, and criticality;
• threat modelling for remote access, suppliers, removable media, wireless links, and exposed services;
• least privilege, unique accounts, strong authentication, and controlled privileged access;
• network zoning and conduits, with carefully governed conduits between business and control networks;
• secure configuration, application allow-listing where feasible, and removal of unnecessary services;
• signed updates, vulnerability management, tested backups, and recovery objectives;
• monitoring of anomalous commands, authentication, configuration changes, and safety-system events;
• incident response that includes safe shutdown, evidence preservation, communication, and restoration.

Security controls must respect real-time and safety constraints. A security patch that interrupts a controller during a hazardous process may create more immediate risk than the vulnerability it fixes. Patches should therefore be risk-assessed, tested in representative environments, scheduled under change control, and accompanied by rollback and recovery plans.

A useful architecture separates zones by function and consequence, restricts traffic between them, and places industrial demilitarised zones between enterprise and control environments. Segmentation is not a substitute for authentication, secure configuration, monitoring, or competent operators.

8. Incident Governance and Assurance

An incident is an event that has caused or could cause harm, loss of control, security compromise, or violation of requirements. Near misses are valuable evidence because they reveal weak controls without the full consequence.

An incident process should define:

1. detection and immediate protection of people;
2. escalation according to severity and legal obligations;
3. containment without destroying evidence;
4. technical and organisational investigation;
5. causal analysis that avoids stopping at “operator error”;
6. corrective and preventive actions with accountable owners;
7. verification of effectiveness;
8. communication, reporting, and controlled closure.

Safety and cybersecurity teams should share relevant information. For example, unexplained actuator motion may be a component failure, an incorrect control algorithm, or malicious command injection. Investigation should preserve logs, controller states, configuration versions, network evidence, and maintenance records while maintaining chain of custody.

Assurance is evidence-based confidence that requirements are fulfilled. Verification asks whether the system was built correctly against its specification; validation asks whether it fulfils its intended purpose in its operational context. Independence of review is valuable for critical functions. Metrics should include overdue risk actions, repeat incidents, patch latency, backup restoration success, proof-test completion, unsafe demands, mean time to detect, and mean time to recover. Metrics must not encourage concealment—for example, “zero reported incidents” may indicate poor reporting rather than excellent safety.

9. Integrated Case Study: Automated Packaging Cell

The following is an illustrative case, not a report of a real organisation.

Background and problem

A packaging cell contains a six-axis robot, a conveyor, pneumatic clamps, vision equipment, a programmable controller, and a remote maintenance connection. Operators load cartons through an access door. A near miss occurs when a clamp closes during maintenance. At the same time, the engineering team discovers that the maintenance laptop shares credentials with several controllers.

Analysis

The risk team maps operating, setup, cleaning, fault-recovery, and maintenance modes. FMEA identifies a failed door switch, a stuck output, loss of encoder feedback, and incorrect restoration of a saved program. FTA begins with “person exposed to unexpected motion” and identifies combinations involving access-door detection failure, inadequate stopping, and restart command acceptance. Cybersecurity analysis identifies shared accounts, an always-enabled remote service, insufficient network separation, and unverified program changes.

The team recognises common causes: a single 24 V supply powers both control and safety devices; the same technician account can alter logic and safety parameters; and maintenance instructions assume that the cell is de-energised although pneumatic energy can remain stored.

Approach and solution

The organisation establishes separate named accounts, multi-factor authentication for remote access where technically feasible, time-limited access approval, and logging. The remote connection terminates in a controlled zone rather than directly on the controller network. The cell receives a documented safety function for door opening, with monitored stopping, isolation of pneumatic energy, manual verification of zero energy, and controlled reset from outside the hazard zone. Safety-related changes require authorisation, review, testing, and version-controlled backup.

The risk register assigns owners and due dates. FMEA actions are linked to verification tests; the FTA is updated to reflect independent power and monitoring. A restoration exercise demonstrates that a known-good controller configuration can be recovered. Operators and maintainers practise a scenario involving loss of network control and a safe local shutdown.

Outcome and learning points

The principal improvement is not one device but governance integration. Physical safeguards, functional safety, account management, change control, incident response, and training now support one another. The case illustrates that cybersecurity is a safety concern when digital actions can influence physical energy, and that redundancy is ineffective if common power, software, credentials, or maintenance practices defeat independence.

10. Ethical, Regulatory, and Professional Considerations

Engineers have duties to protect people, disclose material risks, maintain competence, and avoid misleading claims about reliability or security. A risk acceptance decision should identify who is exposed, who benefits, what evidence supports the decision, and whether affected workers have been consulted. Safety cannot ethically be traded for production targets without transparent authority and lawful justification.

Relevant frameworks vary by jurisdiction and sector. Common reference families include machinery risk assessment and safety standards, functional-safety standards for electrical and programmable systems, industrial cybersecurity standards, quality-management systems, and data-protection law. Standards provide structured expectations, but compliance is not proof that a particular design is safe or secure. Applicable legislation, conformity assessment, supplier obligations, and record-retention requirements must be determined for the actual application.

Artificial intelligence introduces additional governance issues. A learning-based vision or control component may change behaviour with new data, produce uncertain outputs, or be vulnerable to data poisoning. It should have bounded authority, monitored performance, fallback behaviour, versioned models, representative validation data, and human oversight appropriate to consequence. An AI component must not be treated as an unexplained replacement for a validated safety function.

11. Practical Best Practices and Limitations

A mature programme integrates hazard analysis, reliability engineering, safety engineering, cybersecurity, quality, procurement, and operations. It defines requirements early, maintains traceability, tests realistic failure combinations, controls configuration, and learns from near misses. Suppliers should provide failure data, security advisories, update policies, component provenance, and end-of-support information.

No analysis method is complete. Risk matrices can create false precision; FMEA can miss interactions; FTA can assume unjustified independence; reliability figures can be misapplied outside their population or environment; penetration tests provide snapshots; and checklists cannot replace engineering judgement. The appropriate response is not to abandon methods, but to state assumptions, combine complementary analyses, validate controls, and revisit conclusions as evidence changes.

Chapter Summary

Risk, reliability, safety, and cybersecurity in mechatronic systems are interdependent governance responsibilities. Risk registers translate uncertainty into assigned actions and evidence. FMEA provides a bottom-up view of component and functional failures, while FTA reasons top-down from feared events and exposes minimal cut sets. Reliability models quantify survival under stated assumptions; availability and maintainability connect failure behaviour to operational performance.

Functional safety ensures that safety-related functions respond correctly, while resilience prepares the system to withstand, recover from, and learn from disruption. Secure-by-design practices protect industrial assets and physical processes through inventory, threat modelling, access control, segmentation, secure change, monitoring, and tested recovery. Incident governance links immediate protection with investigation, corrective action, and assurance. The central professional lesson is that dependable mechatronic systems require technically sound controls plus accountable lifecycle governance.

Key Terms

Risk: Effect of uncertainty on objectives.

Hazard: Potential source of harm.

Threat: Potential action or event capable of exploiting a vulnerability.

Vulnerability: Weakness that can be exploited or triggered.

Risk register: Controlled record of risks, controls, owners, and actions.

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

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

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

Reliability: Probability of performing a required function for a stated time and condition.

Failure rate: Frequency parameter describing failures under defined assumptions.

MTTF: Mean time to failure for a non-repairable item.

MTBF: Mean time between failures, with definition dependent on context.

Maintainability: Probability of restoring function within a specified time.

Availability: Proportion or probability of being operationally ready under a stated definition.

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

Safety integrity: Likelihood that a safety function performs as required.

Resilience: Ability to withstand, adapt to, recover from, and learn from disruption.

Secure by design: Incorporation of security requirements and controls from system conception.

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

Incident governance: Controlled process for response, investigation, learning, and assurance.

Review Questions

Short Answer Questions

1. What information should a risk register contain?
2. How does FMEA differ from fault-tree analysis?
3. State the assumptions of the exponential reliability model.
4. Why does redundancy not always improve reliability?
5. What is the purpose of network zoning in an industrial control environment?

Long Answer Questions

1. Explain how a risk register should be developed, reviewed, and linked to change control.
2. Compare FMEA and FTA, including their strengths, limitations, and complementary use.
3. Explain the relationship among reliability, maintainability, and availability, using the relevant equations.
4. Describe a functional-safety lifecycle for a robotic cell.
5. Discuss how secure-by-design principles can be integrated with safety engineering.

Analytical / Application Questions

1. A system has two independent components in series, with reliabilities 0.98 and 0.95 over a mission. Calculate system reliability and explain why common-cause failures would alter the result.
2. Construct a mini risk register for an autonomous mobile robot operating near pedestrians. Include three risks, controls, owners, and verification evidence.
3. Analyse the packaging-cell case and identify one FMEA entry, one fault-tree branch, one safety control, and one cybersecurity control that address the same hazardous outcome.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a risk register?

A. A record containing only component failure rates

B. A controlled record of risks, controls, owners, actions, and evidence

C. A list of cybersecurity software licenses

D. A maintenance schedule without hazard information

Correct Answer: B. A controlled record of risks, controls, owners, actions, and evidence

Question 2

FMEA is primarily which type of analysis?

A. Top-down deductive analysis

B. Bottom-up analysis of failure modes and effects

C. Financial analysis of maintenance cost

D. Statistical analysis of network traffic

Correct Answer: B. Bottom-up analysis of failure modes and effects

Question 3

For independent events A and B, which expression gives the probability of an OR gate?

A. P(A)P(B)

B. P(A) − P(B)

C. P(A) + P(B) − P(A)P(B)

D. P(A)/P(B)

Correct Answer: C. P(A) + P(B) − P(A)P(B)

Question 4

A constant failure rate is assumed in which reliability model?

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

B. R(t) = λt

C. R(t) = 1 + λt

D. R(t) = t/λ

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

Question 5

Using R(t) = e^(−λt), what is approximately the reliability for λ = 2 × 10⁻⁵ per hour and t = 1,000 hours?

A. 0.0200

B. 0.5000

C. 0.9802

D. 1.0200

Correct Answer: C. 0.9802

Question 6

Which statement about an RPN calculated as S × O × D is correct?

A. It is a physical probability with units of hours

B. It is meaningful only within the defined scoring system

C. It always identifies the most dangerous failure

D. It eliminates the need for engineering judgement

Correct Answer: B. It is meaningful only within the defined scoring system

Question 7

What is the principal purpose of fault-tree analysis?

A. To decompose a feared top event into causal combinations

B. To calculate employee training hours

C. To assign product prices

D. To replace system validation

Correct Answer: A. To decompose a feared top event into causal combinations

Question 8

Which practice best represents secure-by-design?

A. Adding passwords after commissioning without changing architecture

B. Establishing security requirements and threat models during design

C. Allowing shared administrator accounts for convenience

D. Disabling all monitoring to improve performance

Correct Answer: B. Establishing security requirements and threat models during design

Question 9

Why can two redundant sensors fail to provide independent protection?

A. Sensors never measure physical variables

B. They may share common power, environment, software, or failure causes

C. Redundancy always reduces availability

D. Parallel systems cannot be tested

Correct Answer: B. They may share common power, environment, software, or failure causes

Question 10

Which action belongs first in incident response when people may be in immediate danger?

A. Publish the incident report

B. Delete logs to prevent confusion

C. Protect people and place the process in a safe condition

D. Restore production immediately

Correct Answer: C. Protect people and place the process in a safe condition