Dependability, Functional Safety and Cybersecurity

Introduction and Context

Modern mechatronic systems combine sensors, embedded processors, actuators, communication networks, software, mechanical structures and human interaction. A failure in any one of these elements can produce loss of production, damage to equipment, environmental harm or injury. Consequently, embedded-system design must address not only whether a system performs its intended function, but also how reliably, safely and securely it behaves when components fail or when an attacker interferes with operation.

Dependability is the ability of a system to deliver service that can justifiably be trusted. It includes reliability, availability, maintainability, safety, integrity and confidentiality. Functional safety is the part of overall safety that depends on the correct operation of systems and other risk-reduction measures. Cybersecurity protects the confidentiality, integrity and availability of assets against intentional or accidental threats. These disciplines overlap but are not interchangeable: a security control can affect safety, and a safety mechanism can create a cybersecurity vulnerability.

This chapter develops methods for analysing hazards, failures and threats, and for designing embedded systems that fail safely and recover appropriately. It also introduces secure boot, cryptographic protection, authentication, secure updating and the principal standards used in industrial and automotive practice.

Learning Objectives

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

1. Distinguish reliability, availability, maintainability, safety, security and fault tolerance.
2. Calculate basic reliability and availability measures under stated assumptions.
3. Perform preliminary hazard analysis, FMEA and threat analysis.
4. Select fail-safe, fault-tolerant and fail-operational architectures.
5. Explain the role of diagnostic coverage, redundancy and watchdogs.
6. Design the principles of secure boot, authentication, encryption and secure updates.
7. Relate design activities to IEC 61508, ISO 13849, ISO 26262, IEC 62443 and related standards.
8. Evaluate trade-offs among safety, cybersecurity, cost, performance and maintainability.

1. Dependability as a System Property

1.1 Core terminology

Reliability is the probability that an item performs its required function for a specified time under stated conditions. Availability is the probability that it is operational when required. Maintainability is the probability that a failed item can be restored within a specified time. Safety is freedom from unacceptable risk. Security is resistance to unauthorized access, alteration, disruption or disclosure. Integrity means that data and behaviour remain correct and unaltered; confidentiality prevents unauthorized disclosure.

A system may be reliable but unsafe. For example, a motor controller that consistently commands excessive torque is reliable in executing an unsafe specification. Conversely, a safe system may deliberately stop whenever uncertainty exists, even though this reduces availability.

1.2 Reliability models

For a constant failure rate λ, an exponential time-to-failure model gives:

where R(t) is reliability at time t, λ is the failure rate in failures per unit time, and t is operating time. The model assumes statistically independent failures, a constant hazard rate and operation in the useful-life period. It is not appropriate for early-life failures or wear-out unless the rate is approximately constant.

The probability of failure by time t is:

The mean time to failure for the exponential model is:

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

For independent components connected in series, every component must operate:

For two independent components in parallel, the system works if at least one works:

These equations assume independence and identical mission conditions. Common-cause failures, shared power supplies, shared software defects and environmental stress can make the calculated value overly optimistic.

1.3 Availability and maintainability

For a repairable component with constant failure rate λ and repair rate μ:

Equivalently, under simple steady-state assumptions:

where A is steady-state availability and MTTR is mean time to repair. The approximation assumes well-defined alternating operating and repair periods, statistical stability and no major logistics delays. Availability can be increased either by reducing failures or by reducing restoration time through diagnostics, modular replacement and spare-parts planning.

Worked example. A controller has MTBF = 10,000 h and MTTR = 5 h. Its availability is:

Thus, the estimated steady-state availability is 99.9500%, excluding scheduled maintenance and common-cause failures.

2. Fault Tolerance and Safe Failure

2.1 Failure behaviour

A fail-safe system moves to a state in which hazards are minimized when a fault is detected. A conveyor emergency-stop circuit that removes motor torque is a typical example. A fault-tolerant system continues to provide its function despite one or more faults, often through redundancy. An aircraft control computer may use multiple lanes and voting. A fail-operational system continues its essential function after a fault, at least for a defined interval, while alerting maintenance personnel.

The correct choice depends on the hazard. Removing power from a robotic arm may be safe in one application but dangerous if the arm is supporting a heavy load. Safe state must therefore be defined through hazard analysis rather than assumed to mean “off.”

2.2 Redundancy and diagnostics

Redundancy may be:

• Active, where all channels operate and their outputs are compared or voted.
• Standby, where a reserve channel is activated after failure.
• Diverse, where channels use different technologies, algorithms or suppliers to reduce common-mode failures.
• Information redundancy, such as error-detecting codes and plausibility checks.

A redundant architecture is useful only when failures are detected and isolated. Two identical sensors powered from the same unstable supply do not provide strong independence. Common-cause analysis must examine shared power, clocks, software, environmental conditions, requirements and maintenance errors.

A watchdog timer detects loss of software progress, but it does not prove that the software is correct. Good practice combines independent timing supervision, control-flow monitoring, memory protection, range checks, communication timeouts, sensor plausibility checks and safe-state actuation.

2.3 Diagnostic coverage

Diagnostic coverage describes the proportion of dangerous failures detected by specified diagnostics. A simplified conceptual measure is:

where λ_DD is the rate of dangerous detected failures and λ_DU is the rate of dangerous undetected failures. This expression assumes the relevant failure population has been classified consistently. It is not, by itself, a complete probability-of-failure-on-demand calculation.

A diagnostic must be sufficiently independent and timely. A software check that uses the same defective data, processor and algorithm as the primary function may not detect the relevant fault. Detection should lead to a controlled response, such as torque removal, isolation of a valve, transition to manual control or limitation of operating speed.

Figure: Dependability and security functions surrounding an embedded mechatronic controller.

3. Hazard Analysis and Functional Safety

3.1 From hazard to safety requirement

A hazard is a potential source of harm. A hazardous event combines a hazard with an operating situation and a possible path to harm. Risk is commonly considered as a combination of severity and likelihood, although standards define detailed assessment methods differently.

A practical hazard-analysis sequence is:

1. Define the system, boundaries, operating modes and interfaces.
2. Identify hazardous energy and unintended movements.
3. Identify initiating faults, foreseeable misuse and environmental conditions.
4. Estimate severity, exposure and possibility of avoidance where required by the selected standard.
5. Specify safety goals and derive functional safety requirements.
6. Allocate requirements to sensors, logic, actuators, mechanical protection and procedures.
7. Verify, validate and document the complete safety lifecycle.

Safety requirements should be testable. “The robot must be safe” is inadequate. “When protective-door opening is detected, hazardous motion shall be prevented within the specified stopping time, including sensor, logic and actuator response” is measurable and allocatable.

3.2 FMEA

Failure Modes and Effects Analysis examines how each component or function can fail and what consequences follow. A typical worksheet contains the item, function, failure mode, local effect, system effect, cause, existing controls, detection method, severity and recommended action.

Some organizations use a Risk Priority Number:

where S is severity, O is occurrence and D is detectability on locally defined ordinal scales. RPN is a prioritization aid, not a probability and not a substitute for engineering judgement. A very severe failure can deserve action even when its RPN is lower than that of several moderate failures.

Example FMEA entry: A rotary encoder may fail by producing a frozen value. The local effect is loss of position updates; the system effect may be uncontrolled motion if the controller assumes the value is valid. Causes include broken wiring, processor-interface failure or sensor damage. Controls include timeout detection, comparison with motor current and a second position channel. The safety response may be controlled braking and torque inhibition.

FMEA is strongest when performed by a multidisciplinary team and updated after testing, field incidents and design changes. It is weaker when it considers components only in isolation and ignores software interactions, common causes and operator response.

3.3 Safety integrity and standards

IEC 61508 provides a generic lifecycle for electrical, electronic and programmable electronic safety-related systems. It uses Safety Integrity Levels (SIL 1–4), with increasing risk-reduction expectations. ISO 13849 addresses safety-related parts of control systems using Performance Levels (PL a–e). ISO 26262 applies to road-vehicle functional safety and uses Automotive Safety Integrity Levels (ASIL A–D). These classifications are not numerically interchangeable; the applicable standard and its prescribed method must be used.

A safety lifecycle normally includes concept, hazard and risk analysis, requirements, architecture, implementation, verification, validation, operation, maintenance, modification and decommissioning. Independence between development and assessment activities may be required according to the integrity target.

4. Threat Analysis and Embedded Cybersecurity

4.1 Security objectives and threat sources

A threat is a potential cause of an unwanted security incident. Threat sources include remote attackers, malicious insiders, compromised maintenance laptops, counterfeit components, supply-chain manipulation and accidental misconfiguration.

The central security objectives are:

• Confidentiality: unauthorized parties cannot read protected information.
• Integrity: unauthorized parties cannot alter code, commands or data undetected.
• Availability: authorized functions remain available when required.
• Authenticity: an entity or message is genuinely associated with its claimed source.
• Accountability: actions can be attributed through appropriate records.

Threat analysis identifies assets, entry points, trust boundaries, attacker capabilities, impacts and mitigations. STRIDE is a useful software-oriented classification: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Automotive and industrial sectors may use specialized variants such as TARA (Threat Analysis and Risk Assessment).

4.2 Security controls

A defensible embedded security architecture uses layered controls:

1. Asset inventory and trust boundaries: identify firmware, keys, calibration data, safety parameters, interfaces and maintenance functions.
2. Least privilege: each task, user and communication endpoint receives only required authority.
3. Isolation: use memory protection, separate privilege levels, process separation and, where appropriate, hardware security modules.
4. Input validation: reject malformed lengths, invalid states, replayed counters and out-of-range values.
5. Secure logging: record security-relevant events without allowing logs to become an attack channel.
6. Monitoring and response: detect anomalies, isolate affected functions and recover safely.

Security controls must not undermine safety. For example, encryption that delays an emergency command is unacceptable unless the safety architecture provides an independent and timely path.

5. Secure Boot, Cryptography and Authentication

5.1 Secure boot and chain of trust

Secure boot establishes that only authorized software executes. A hardware root of trust stores an immutable public key, hash or manufacturer credential. At startup, boot ROM verifies the first mutable boot stage; that stage verifies the operating system or application; the application verifies critical configuration where required. Each stage must verify the next before transferring control.

Digital signatures provide authenticity and integrity. A manufacturer signs a firmware image with a private key; the device verifies the signature using the corresponding public key. The private key must remain protected, preferably in a controlled signing service or hardware security module. Hashes alone detect accidental or deliberate alteration only when the trusted reference hash cannot itself be replaced.

Secure boot should include anti-rollback protection. A version counter or monotonic security counter prevents installation of an old but legitimately signed image containing a known vulnerability. Recovery images and key-revocation mechanisms are essential for long-lived equipment.

5.2 Encryption and key management

Symmetric encryption uses the same secret key for encryption and decryption and is efficient for large data volumes. Authenticated encryption, such as AES-GCM or ChaCha20-Poly1305, provides confidentiality and integrity when keys and nonces are managed correctly. A nonce must not be reused with the same key in modes where uniqueness is required.

Asymmetric cryptography uses a key pair. It supports signatures, certificate-based authentication and key establishment, but generally requires more computation. TLS is commonly used to protect network sessions; it does not automatically secure a device if certificates, endpoint authorization or update policy are incorrectly implemented.

Key management is often more difficult than algorithm selection. Systems require secure generation, provisioning, storage, rotation, revocation, backup policy and end-of-life destruction. Hard-coded shared passwords and identical device keys create severe fleet-wide exposure.

5.3 Authentication and authorization

Authentication answers “who or what is communicating?” Authorization answers “what is it permitted to do?” A robust maintenance interface may require a device certificate, an operator identity, multifactor authentication and role-based permissions. Commands should also be authorized by operating state: a calibration command accepted during maintenance may be forbidden while the machine is moving.

Message authentication codes, sequence numbers and freshness counters help prevent spoofing and replay. Safety-critical commands should be validated for plausibility and context even after cryptographic authentication, because a legitimate but compromised sender may issue dangerous commands.

6. Secure Updates and Lifecycle Governance

Connected mechatronic products require vulnerability remediation throughout their service life. A secure update process should:

• authenticate the source and verify image integrity;
• check target device, hardware revision and dependencies;
• prevent rollback to vulnerable versions;
• use an atomic or dual-bank installation strategy;
• preserve a recoverable image after power loss;
• log the update result;
• support key compromise and certificate revocation;
• define who may approve, deploy and reverse an update.

An A/B partition scheme writes the new image to an inactive bank, verifies it, boots it provisionally and marks it confirmed only after health checks. If startup fails, the bootloader returns to the previous bank. This improves availability but requires careful handling of data migration and rollback security.

Manufacturers should maintain a software bill of materials, vulnerability disclosure process, patch policy and end-of-support policy. Operators must control credentials, segment networks, back up configurations and test patches before deployment. Security is therefore a governance and lifecycle responsibility, not merely a firmware feature.

7. Interaction Between Safety and Cybersecurity

Safety engineering traditionally considers random hardware failures, systematic design faults and foreseeable misuse. Cybersecurity considers intelligent, adaptive adversaries. A cyberattack can disable a safety sensor, alter a limit, delay a command or cause nuisance trips that encourage operators to bypass protection.

The disciplines should share hazard and asset models, but their acceptance criteria differ. Safety often seeks predictable deterministic failure behaviour; security must assume an adversary may deliberately target assumptions. Independent emergency circuits, physical separation, network segmentation, rate limiting and manual recovery can reduce combined risk.

A useful design principle is secure by default and safe under uncertainty. If authentication fails, the system should reject the privileged command. If sensor validity is uncertain, the system should enter a defined safe or degraded state. Nevertheless, degraded operation must be analysed: stopping a cooling pump may create a more serious hazard than continuing at reduced capacity.

8. Standards, Verification and Validation

Relevant standards depend on sector and jurisdiction. Common references include:

Verification asks whether the product was built according to specified requirements. Validation asks whether the right product was built for its intended use. Testing should include normal operation, boundary conditions, injected faults, power interruption, communication loss, timing overload, invalid updates, authentication failure and recovery from corrupted state.

Evidence may include requirements traceability, code reviews, static analysis, unit and integration tests, hardware-in-the-loop tests, penetration testing, fault-injection records, environmental tests and independent assessment. No single test proves safety or security; confidence comes from complementary evidence and controlled processes.

9. Illustrative Case: Autonomous Pallet-Transfer Cell

Background

Consider an illustrative industrial cell in which a mobile pallet carrier transfers loads between a conveyor and a storage rack. The carrier contains a battery, drive motors, steering actuators, laser scanners, wheel encoders, an embedded controller and wireless maintenance access.

Problem

A preliminary design stops the motors when a scanner detects an obstacle. However, the scanner communicates over a shared network, firmware updates use an unauthenticated USB interface and both wheel encoders share one power regulator. A single corrupted position value could cause a collision, while a malicious update could disable obstacle detection.

Analysis

The hazard analysis identifies collision, unexpected start, loss of braking and uncontrolled load movement. The FMEA identifies frozen encoder output, incorrect scanner data, stuck motor command, low battery during braking and corrupted configuration. Threat analysis identifies unauthorized wireless access, malicious USB media, replayed control packets and compromise of the maintenance laptop.

The highest-priority safety goals are to prevent hazardous motion when protective sensing is invalid and to ensure that braking remains available during controller faults. Security goals include authenticated maintenance, signed firmware, protected configuration and network isolation between safety-related traffic and general diagnostics.

Approach and solution

The redesigned system uses two diverse obstacle-detection paths, independent power monitoring, encoder plausibility checks and a hardware emergency-stop chain. A safety monitor can remove drive enable independently of the application processor. The controller uses a watchdog and a bounded-time command protocol; stale or out-of-sequence commands are rejected.

The boot ROM verifies a signed bootloader, which verifies a signed application image and checks a monotonic version number. Maintenance requires operator authentication and a device certificate. Firmware is installed using an A/B partition scheme. Wireless access is disabled during autonomous movement, and the safety channel is physically or logically separated from noncritical telemetry.

Outcome

The design does not eliminate all failures, but it reduces the probability and consequence of hazardous failures, improves detection, prevents unauthorized firmware execution and supports controlled recovery. Validation includes sensor disconnection, common-power faults, forged packets, replay attempts, interrupted updates and emergency stopping under maximum load.

Learning points

1. A safety function must include sensors, logic, actuators, power and timing—not only application software.
2. Redundancy without independence provides limited protection.
3. Signed firmware is ineffective if attackers can replace the trusted verification key.
4. Security authentication does not replace physical safety mechanisms.
5. Fault response must be tested in realistic operating states, including low battery and communication loss.

10. Challenges, Limitations and Contemporary Developments

Dependability predictions are limited by uncertain field data, changing environments and hidden common causes. Security risk changes as new vulnerabilities and attack techniques emerge. Artificial intelligence can assist anomaly detection, log analysis and predictive maintenance, but an AI model may produce false alarms, be manipulated by crafted inputs or be difficult to validate for safety. It should not silently replace a required deterministic safety function without appropriate evidence.

Digital twins and hardware-in-the-loop simulation improve coverage of rare combinations of faults. Remote attestation can allow a fleet manager to check software state before authorizing sensitive operations. Post-quantum cryptography may become relevant for equipment with long confidentiality requirements, although migration must consider processor capacity, memory, update mechanisms and standardization status.

Best practice is to establish security and safety requirements early, maintain traceability, minimize complexity, use independent protection paths, conduct multidisciplinary reviews, design for secure maintenance, test degraded modes and plan the complete operational lifetime. Compliance certificates are valuable evidence, but they do not guarantee safety in an incorrectly integrated or poorly maintained system.

Chapter Summary

Dependability is a system-level property encompassing reliability, availability, maintainability, safety and security. Reliability models such as the exponential model are useful only under stated assumptions. Availability depends on both failure frequency and restoration time. Fail-safe, fault-tolerant and fail-operational designs serve different hazard contexts, and redundancy is effective only when failures can be detected and common causes are controlled.

Hazard analysis converts hazardous situations into testable safety goals and requirements. FMEA provides a structured method for analysing failure modes, effects, causes and controls, while threat analysis examines assets, trust boundaries, attacker capabilities and consequences. Functional safety standards organize the lifecycle and integrity evidence; cybersecurity standards organize secure development, component protection and industrial network governance.

Secure boot establishes a chain of trust, authenticated encryption protects communications and data, authentication and authorization restrict access, and secure updates preserve integrity throughout the product lifecycle. Safety and cybersecurity must be engineered together because attacks can create safety hazards and security controls can affect timing or availability. Effective practice combines architecture, process, testing, governance and disciplined maintenance.

Key Terms

Dependability: The ability of a system to provide service that can justifiably be trusted.

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

Availability: Probability that a system is operational when required.

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

Fail-safe: Behaviour that reduces hazard when a fault occurs.

Fault tolerance: Ability to continue specified operation despite faults.

Fail-operational: Ability to continue essential operation after a defined fault.

Functional safety: Safety dependent on correct functioning of systems and controls.

Hazard: Potential source of harm.

FMEA: Structured analysis of failure modes, causes and effects.

Diagnostic coverage: Proportion of relevant dangerous failures detected by diagnostics.

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

Threat: Potential cause of an unwanted security incident.

Authenticity: Assurance that an entity, message or image is genuine.

Secure boot: Startup process that executes only authenticated software.

Digital signature: Cryptographic evidence of origin and integrity.

Authenticated encryption: Encryption that also detects unauthorized modification.

Anti-rollback: Protection against installation of an older vulnerable software version.

Safety integrity level: Integrity classification used by specified safety standards.

Trust boundary: Interface across which authority, data or assumptions change.

Review Questions

Short Answer Questions

1. Distinguish reliability from availability.
2. Why does redundancy not automatically provide fault tolerance?
3. What is the purpose of a watchdog timer?
4. What are the three principal security objectives represented by the CIA triad?
5. Why is secure boot described as a chain of trust?

Long Answer Questions

1. Explain how hazard analysis leads to functional safety requirements in an embedded mechatronic system.
2. Compare fail-safe, fault-tolerant and fail-operational architectures, giving an appropriate application for each.
3. Describe the stages and governance controls of a secure firmware-update process.
4. Explain how FMEA and threat analysis complement one another.
5. Discuss the interactions and potential conflicts between functional safety and cybersecurity.

Analytical / Application Questions

1. A motor controller has MTBF = 8,000 h and MTTR = 4 h. Calculate its approximate steady-state availability and state the assumptions behind the calculation.
2. Design an FMEA entry for a robot position sensor that produces a frozen output. Identify the effect, possible causes, detection mechanisms and safe response.
3. Propose a secure architecture for a networked actuator that must continue safe braking during loss of network communication and must support authenticated remote updates.

Multiple Choice Questions with Answers

Question 1

Under the constant-failure-rate model, which expression represents reliability at time t?

A. R(t) = 1 − λt

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

C. R(t) = λ/t

D. R(t) = t/λ

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

Question 2

A repairable system has MTBF = 10,000 h and MTTR = 5 h. What is its approximate steady-state availability?

A. 0.9500

B. 0.9950

C. 0.9995

D. 1.0500

Correct Answer: C. 0.9995

Question 3

Which characteristic most directly distinguishes a fail-safe design?

A. It always continues full operation after any fault

B. It moves to a state that reduces hazard when a fault is detected

C. It uses no sensors or diagnostics

D. It prevents all component failures

Correct Answer: B. It moves to a state that reduces hazard when a fault is detected

Question 4

What is the principal purpose of diagnostic coverage?

A. To measure the fraction of dangerous failures detected by diagnostics

B. To calculate encryption-key length

C. To determine motor efficiency

D. To eliminate all common-cause failures

Correct Answer: A. To measure the fraction of dangerous failures detected by diagnostics

Question 5

In secure boot, what normally verifies the authenticity of a firmware image?

A. A digital signature and trusted public key

B. A system clock alone

C. An unprotected text filename

D. A motor-current measurement

Correct Answer: A. A digital signature and trusted public key

Question 6

Which control primarily prevents installation of an older vulnerable but validly signed firmware image?

A. Input filtering

B. Anti-rollback protection

C. A watchdog timer

D. Network compression

Correct Answer: B. Anti-rollback protection

Question 7

What does authentication establish?

A. What actions a user is permitted to perform

B. That an entity or message is associated with its claimed source

C. That a system can never be unavailable

D. That all data is publicly readable

Correct Answer: B. That an entity or message is associated with its claimed source

Question 8

Which is a common limitation of an RPN calculated from severity, occurrence and detectability scores?

A. It is a physical unit of failure rate

B. It is always a true probability of harm

C. Ordinal scores can hide important differences in risk

D. It applies only to cybersecurity threats

Correct Answer: C. Ordinal scores can hide important differences in risk

Question 9

Why must common-cause failures be considered in redundant safety channels?

A. They can cause multiple channels to fail despite apparent redundancy

B. They increase cryptographic key length

C. They make repair unnecessary

D. They guarantee independence

Correct Answer: A. They can cause multiple channels to fail despite apparent redundancy

Question 10

Which statement best describes validation?

A. Checking whether the product satisfies coding style only

B. Checking whether the intended product addresses its real operational use

C. Measuring only component failure rates

D. Signing firmware with a private key

Correct Answer: B. Checking whether the intended product addresses its real operational use