Dependability, Functional Safety and Fault Tolerance

Introduction and Context

Embedded systems increasingly control functions whose failure can injure people, damage equipment, interrupt essential services, or create environmental harm. Examples include vehicle braking and steering, aircraft flight controls, railway signalling, medical infusion pumps, industrial robots, nuclear instrumentation, and smart-grid protection. In such systems, correct functionality alone is insufficient. The system must also be dependable: it must deliver the required service, at the required time, with acceptable risk, and must respond safely when faults occur.

Dependability is a collective term covering attributes such as reliability, availability, maintainability, safety, integrity, security, and resilience. Functional safety is a more specific concept concerned with freedom from unacceptable risk caused by malfunctioning behaviour of electrical, electronic, and programmable electronic systems. It is achieved through a lifecycle of hazard identification, risk reduction, requirements specification, design, verification, validation, operation, maintenance, and controlled decommissioning.

This chapter develops engineering methods for dependable embedded systems. It explains hazard analysis, failure modes and effects analysis (FMEA), fault-tree analysis (FTA), diagnostic coverage, redundancy, watchdogs, fail-safe design, safety integrity, standards, and safety cases. The emphasis is not on adding isolated protective components, but on constructing a defensible chain from hazards to safety requirements and verified implementation.

Learning Objectives

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

1. Distinguish reliability, availability, safety, security, and functional safety.

2. Model faults, errors, failures, hazards, and accidents.

3. Apply FMEA and FTA to embedded-system safety analysis.

4. Select watchdog, diagnostic, redundancy, and fail-safe techniques appropriately.

5. Interpret the role of IEC 61508 and sector-specific standards such as ISO 26262.

6. Estimate simple failure probabilities and diagnostic effects while recognizing model limitations.

7. Construct the principal elements of a safety case for a regulated embedded system.

8. Critically evaluate trade-offs involving cost, complexity, independence, common-cause failures, and cybersecurity.

1. Dependability Concepts and Terminology

1.1 Fault, error, failure, and hazard

A fault is a defect or abnormal condition in hardware, software, requirements, environment, or operation. A stuck-at-0 signal, corrupted memory bit, incorrect calibration constant, and erroneous timing assumption are examples. A fault may be dormant or active.

An error is an incorrect internal system state resulting from a fault. For example, a corrupted sensor value stored in memory is an error even before it influences an actuator.

A failure occurs when the delivered service deviates from the specified service. If a controller commands excessive motor torque, the system has failed even if all internal signals appear plausible.

A hazard is a condition with the potential to cause harm. A hazard is not itself an accident: an unintended high-speed motor command is hazardous, while an injury resulting from that command is an accident or harmful event.

The causal chain is commonly represented as:

fault → error → failure → hazardous situation → accident or loss.

Safety engineering attempts to break this chain through prevention, detection, containment, control, and mitigation.

1.2 Reliability, availability, maintainability, and safety

Reliability is the probability that an item performs its required function for a specified time under stated conditions. For a constant failure rate λ, an exponential model gives

R(t) = exp(−λt),

where λ has units of inverse time and the model assumes statistically independent failures with a constant hazard rate. The model is often useful for electronic components during their useful-life period, but it is not valid without qualification during early-life or wear-out phases.

The mean time to failure under the same exponential, non-repairable model is

MTTF = 1/λ.

Availability is the probability that a repairable system is operational when required. In a simple two-state model with constant failure rate λ and repair rate μ,

A = μ/(λ + μ).

Here μ is the reciprocal of mean repair time. This steady-state expression assumes constant rates, adequate repair resources, and a system that can be represented by operational and failed states.

Maintainability concerns the ease and speed with which a failed system can be restored. Diagnostic information, modular replacement, built-in test, and safe access improve maintainability.

Safety concerns preventing unacceptable risk. A system can be highly reliable but unsafe: it may operate correctly for long periods but fail in a dangerous way when a rare fault occurs. Conversely, a system can be safe but unavailable if it frequently enters a conservative shutdown state.

Security protects against intentional or unauthorized actions. Security and safety are distinct but increasingly interdependent. A cyberattack that modifies a firmware image can create a safety hazard, and safety diagnostics may expose exploitable interfaces.

1.3 Fail-silent, fail-safe, and fail-operational behaviour

A fail-silent system ceases to produce outputs after detecting a fault. A fail-safe system transitions to a state in which the residual risk is acceptably low. The safe state depends on the application: removing motor torque may be safe for a robot but unsafe for a surgical ventilator if ventilation is interrupted without backup.

A fail-operational system continues to provide the required function after a defined fault, usually through redundancy or reconfiguration. Aircraft flight controls and autonomous vehicles may require fail-operational behaviour for a limited time followed by a controlled degradation.

Safety is therefore a system-level property, not a universal preference for shutdown. The correct response depends on the hazard, timing, process physics, human interaction, and available fallback functions.

2. Risk, Hazards, and Safety Requirements

Risk is generally evaluated as a combination of the severity of harm and the likelihood of occurrence. Qualitative matrices are widely used, but they should not be mistaken for precise probability models. A sound risk assessment identifies:

• the intended function and operating context;
• reasonably foreseeable misuse and environmental conditions;
• hazardous events and credible initiating causes;
• severity and exposure of harm;
• existing prevention and mitigation measures; and
• tolerable residual risk and assumptions.

A safety requirement should be specific, testable, and traceable. “The controller shall be safe” is not verifiable. A stronger requirement is: “If the overspeed monitor detects a speed above the defined threshold, the drive shall remove torque within 20 ms, shall record diagnostic status, and shall prevent automatic restart until an authorized reset.”

Safety requirements include both functional and non-functional aspects. Functional requirements specify protective actions; timing, independence, diagnostic coverage, fault reaction, environmental limits, and verification criteria constrain the implementation.

Safety integrity

Safety Integrity Level (SIL) in IEC 61508 and Automotive Safety Integrity Level (ASIL) in ISO 26262 express the rigor and risk-reduction expectations associated with a safety function. They are not simply component quality grades. Assignment is based on hazard and risk analysis; achievement depends on architecture, random-hardware analysis, systematic-process control, diagnostics, independence, and evidence.

IEC 61508 uses SIL 1 through SIL 4, with SIL 4 representing the most stringent level. For low-demand functions, risk reduction is commonly expressed through the probability of dangerous failure on demand (PFDavg). For high- or continuous-demand functions, the relevant measure is the probability of dangerous failure per hour (PFH). Exact target ranges and calculation rules must be taken from the applicable edition and sector standard; they should never be inferred from a simplified classroom formula.

3. Hazard-Analysis Techniques

3.1 Failure Modes and Effects Analysis

FMEA is a bottom-up method. For each item or function, the analyst identifies possible failure modes, local effects, system effects, causes, existing controls, and recommended actions. Typical columns include:

| Item/function | Failure mode | Cause | Local effect | End effect | Detection/control | Action |

|---|---|---|---|---|---|---|

For an embedded temperature controller, failure modes may include a sensor open circuit, sensor short circuit, ADC reference drift, corrupted set point, processor lock-up, output transistor stuck on, or communication timeout.

Traditional FMEA sometimes assigns ratings for severity, occurrence, and detectability and multiplies them to obtain a risk-priority number. This multiplication is ordinal rather than probabilistic: a score of 120 is not necessarily twice as risky as 60, and different rating combinations can produce the same result. Modern practice therefore uses explicit action rules, criticality analysis, and engineering judgement in addition to any ranking number.

FMEA is valuable for discovering single-point failures and specifying diagnostics. Its limitations include dependence on analyst completeness, difficulty representing complex interactions, and weak treatment of multiple simultaneous failures and common-cause failures. FMEA should be updated after design changes, field incidents, and test results.

3.2 Fault-tree analysis

FTA is a top-down deductive technique. The analyst begins with a top event, such as “uncommanded hazardous motor torque,” and decomposes it using AND and OR gates into lower-level causes.

For independent basic events A and B:

• OR probability: P(A OR B) = P(A) + P(B) − P(A)P(B).
• AND probability: P(A AND B) = P(A)P(B).

For rare independent events, the OR expression is often approximated by P(A)+P(B), but the approximation must be justified. The AND expression is valid only when the events are appropriately defined and independent over the analysis interval. Common-cause failures violate this assumption and can make a redundant design much less effective than the simple calculation suggests.

As an illustration, suppose two independent channels each have probability 0.001 of a dangerous failure during a specified mission, and the dangerous system condition requires both channels to fail. The estimated probability is

P = 0.001 × 0.001 = 10⁻⁶.

This result is not a certification claim. It excludes common power, clock, software, environmental, maintenance, and specification failures unless they have been separately modelled.

FTA reveals minimal cut sets: smallest combinations of basic events sufficient to cause the top event. A single basic event in a minimal cut set is a single-point vulnerability. FTA is particularly useful for demonstrating that safety goals are achieved by combinations of independent barriers.

3.3 STPA and complementary methods

Systems Theoretic Process Analysis (STPA) treats accidents as arising not only from component failures but also from unsafe control actions, inadequate feedback, flawed process models, and organizational constraints. It is useful for software-intensive systems, autonomy, and human-machine interaction where traditional component failure lists are incomplete.

Event-tree analysis begins with an initiating event and examines possible success or failure of protective barriers. Hazard and Operability Study (HAZOP) uses guide words such as “more,” “less,” “none,” and “reverse” to identify deviations from design intent. In practice, FMEA, FTA, STPA, HAZOP, simulation, and field-data analysis are complementary rather than competing techniques.

4. Fault Detection, Diagnostics, and Fault Tolerance

4.1 Detection and diagnostic coverage

A diagnostic detects a fault and supports a defined reaction. Examples include range checks, rate-of-change checks, temporal monitoring, memory error-correcting codes, CPU self-tests, clock monitoring, communication CRCs, plausibility checks between redundant sensors, and power-supply supervision.

Diagnostic coverage is the fraction of relevant dangerous faults detected by a specified diagnostic under defined assumptions. A qualitative statement such as “high coverage” is insufficient unless the fault population, test interval, detection latency, and response are documented.

A simple approximation for residual dangerous failure rate is

λ_res ≈ λ_D(1 − DC),

where λ_D is the dangerous failure rate before diagnostics and DC is diagnostic coverage expressed as a fraction. This approximation assumes correct classification, independent diagnostic behaviour, immediate effective response, and a failure-rate model appropriate to the application. It does not account for latent faults, common cause, proof-test intervals, or diagnostic failures. In regulated design, formal hardware metrics and probabilistic models are required.

4.2 Watchdog timers

A watchdog timer resets or interrupts a processor if it is not serviced within a permitted interval. It can detect many forms of software lock-up, deadlock, runaway execution, and timing failure. A simple watchdog is not sufficient for all faults: a faulty program may continue executing an incorrect loop and still service it.

Stronger designs use an independent watchdog clock, a windowed watchdog, a challenge-response service sequence, and supervision of task execution. A windowed watchdog accepts a service only within a time interval. Servicing too early can indicate a bypassed or runaway task; servicing too late indicates a stall.

Watchdog architecture must define reset consequences. Repeated resets may create a denial-of-service condition or conceal a persistent hazard. The system should record reset causes, limit restart attempts, and transition to a safe state when recovery is not credible.

4.3 Redundancy and diversity

Redundancy may be spatial, temporal, informational, or functional. Dual sensors, duplicated processors, repeated computations, and an independent mechanical brake illustrate different forms.

A 1oo2 architecture (one-out-of-two) declares the function available if at least one of two channels supports it. It can improve availability but may be vulnerable to a single dangerous channel producing an incorrect command unless disagreement is detected. A 2oo2 architecture requires agreement and can prevent a single erroneous channel from authorizing an action, but it may shut down on one fault. A 2oo3 architecture can tolerate one erroneous channel through voting, but increases cost and common-cause exposure.

Redundancy is effective only when channels are sufficiently independent. Shared power, clock, communication bus, cooling, requirements, compiler defects, maintenance errors, or environmental stress can defeat nominal duplication. Diversity—different hardware, software, algorithms, teams, or technologies—can reduce some common-mode risks, but it does not guarantee independence.

4.4 Error detection and containment

Embedded systems use parity, cyclic redundancy checks, checksums, sequence counters, timeouts, memory ECC, control-flow monitoring, stack guards, range checks, and end-to-end communication protection. Detection must be paired with containment. A detected invalid message should not merely set a flag; it should prevent unsafe use, preserve diagnostic evidence, and invoke an appropriate fallback.

Graceful degradation can retain non-hazardous functions while disabling hazardous ones. For example, a mobile robot may stop autonomous motion but continue to report status and permit supervised recovery.

5. Fail-Safe Hardware and Software Design

Fail-safe design begins by defining the safe state and the transition path. Common practices include de-energize-to-trip outputs, normally closed emergency-stop circuits, independent over-temperature cut-outs, current limiting, mechanical interlocks, energy discharge, and physically separated safety channels.

However, “de-energize to trip” is not universally safe. Removing power from a medical ventilator or an aircraft actuator may create greater danger. The safe state must therefore be derived from hazard analysis and validated under realistic process conditions.

Software practices include defensive programming, strong typing, bounded execution time, explicit state machines, safe defaults, input validation, partitioning, memory protection, deterministic scheduling, configuration control, and independent verification. Safety-related software should minimize unnecessary complexity. Dynamic allocation, uncontrolled recursion, hidden shared state, and unbounded blocking are generally avoided or rigorously constrained.

Safety mechanisms must themselves be specified. A sensor plausibility check needs thresholds, timing, handling of sensor startup, calibration drift, transient noise, and disagreement recovery. A reset handler needs a defined safe output state before application initialization. Diagnostic reporting must distinguish a tested fault from an untested condition.

6. Standards and the Safety Lifecycle

IEC 61508 is a generic functional-safety standard for electrical, electronic, and programmable electronic safety-related systems. It promotes a lifecycle approach, risk-based integrity levels, management of functional safety, requirements traceability, verification and validation, hardware fault analysis, software controls, competence, and configuration management.

Sector standards adapt these principles. ISO 26262 addresses road-vehicle functional safety and introduces automotive concepts such as the item, safety goals, functional and technical safety concepts, ASIL, hardware metrics, freedom from interference, and safety validation. IEC 62304 addresses medical-device software life-cycle processes; IEC 61511 applies functional safety to the process industry; EN 50126/50128/50129 address railway dependability, software, and signalling safety. DO-178C and related aviation standards use assurance objectives and evidence structures that differ in terminology and detail from IEC 61508.

Compliance is not achieved by claiming that a microcontroller is “SIL certified.” A product certificate may provide evidence for specified assumptions and usage constraints, but the integrator remains responsible for the complete safety function, interfaces, environment, diagnostics, configuration, and lifecycle process.

A typical lifecycle includes:

1. Concept and context definition.

2. Hazard and risk analysis.

3. Safety goals and functional safety requirements.

4. Technical architecture and allocation.

5. Detailed hardware and software development.

6. Verification, integration, and validation.

7. Production, operation, maintenance, and incident feedback.

8. Modification control and decommissioning.

Traceability links hazards to safety goals, requirements, architecture, implementation, tests, anomalies, and residual-risk acceptance.

7. Safety Cases and Evidence

A safety case is a structured, evidence-based argument that a system is acceptably safe in a defined context. It is not merely a test report and not identical to a certificate.

A practical safety case contains:

• claim: the top-level safety assertion;
• argument: reasoning that decomposes the claim into defensible subclaims;
• evidence: analyses, test results, reviews, tool qualifications, process records, and operational data; and
• context and assumptions: boundaries, operating conditions, independence assumptions, and limitations.

For example, a top claim may state that a robotic cell prevents hazardous motion during a person-detected intrusion. Subclaims may address detection performance, safe removal of energy, fault tolerance, response time, cybersecurity, maintenance controls, and validation under foreseeable misuse.

The argument should address residual risk and uncertainty. Evidence must be relevant, repeatable, configuration-controlled, and sufficiently independent. A large quantity of weak evidence does not compensate for an invalid safety argument. Safety cases should be maintained as living artefacts when software, hardware, threats, operating conditions, or standards change.

8. Worked Application: Illustrative Robotic Conveyor Guarding System

Background

Consider an illustrative automated conveyor cell in which a robot transfers parts between stations. A person may enter the guarded area during maintenance. The safety function is to detect entry and remove hazardous robot torque before a person can be struck.

Problem definition

The hazard is robot motion while a person is inside the danger zone. Potential causes include a failed light curtain, shorted input, processor lock-up, stuck output relay, bypassed guard switch, communication timeout, or incorrect restart logic. The safe state is zero hazardous motion, with restart requiring verified clearance and an authorized reset.

Analysis

An FMEA identifies that a single shorted safety input could falsely indicate that the light curtain is clear. A diagnostic test pulse and dual-channel input comparison are therefore required. An FTA for “hazardous motion with person present” includes an OR combination of guard detection failure, safety-controller dangerous failure, and actuator energy not removed after a valid trip. The architecture must also address common power and wiring failures.

The response-time budget is decomposed into sensing, input filtering, logic execution, output switching, drive torque removal, and mechanical stopping. The total must be less than the maximum permissible stopping time derived from the hazard analysis and measured stopping distance. Timing assumptions are validated on the actual machine, including worst-case load and wear conditions.

Approach and solution

The proposed design uses two independently monitored guard channels, a safety-rated controller, dual contactors with feedback of auxiliary contacts, a mechanically applied brake, and a reset circuit located outside the danger zone. The controller performs discrepancy monitoring, periodic test pulses, watchdog supervision, and contactor feedback checks. The standard motion controller is not permitted to override the safety path.

The system enters a latched safe state after a trip. Automatic restart is prohibited. Faults are logged with time, channel status, reset cause, and maintenance information. The safety case includes FMEA, FTA, wiring inspection, fault-injection tests, stopping-time measurements, software review, environmental tests, and validation of foreseeable bypass attempts.

Outcome

The design reduces dependence on a single sensor or processor and provides evidence for detection, reaction, and restart control. It does not eliminate all risk: a common wiring error, incorrect hazard-zone definition, defeated guard, or inadequate maintenance could remain. These residual risks require training, physical design controls, periodic inspection, and operating procedures.

Learning points

1. The safety function must be defined at system level, including the machine and human interaction.

2. Redundancy is meaningful only when faults and common causes are analysed.

3. Response time is a safety requirement, not merely a performance metric.

4. Diagnostics require a specified reaction and evidence of effectiveness.

5. A safety case combines argument, evidence, assumptions, and residual-risk management.

9. Challenges, Limitations, and Contemporary Developments

The largest challenge in modern embedded safety is complexity. Connected devices combine legacy software, third-party libraries, machine learning, wireless networks, cloud services, and updates. Traditional exhaustive testing is impossible for many state spaces. Formal methods, model checking, runtime assurance, and restricted architectures can provide stronger evidence for selected properties, but they do not replace hazard analysis or system validation.

Artificial intelligence creates additional concerns. A machine-learning model may be difficult to explain, sensitive to distribution shift, and vulnerable to adversarial inputs. Safety claims should specify the operational design domain, monitored confidence or uncertainty, fallback behaviour, training-data controls, and change-management process. An AI component should not be assumed safe merely because its average accuracy is high. A deterministic safety monitor and a conservative fallback may bound the consequences of uncertain predictions.

Cybersecurity is now part of safety engineering. Secure boot, authenticated updates, least privilege, protected diagnostics, key management, network segregation, and vulnerability response can prevent intentional faults from becoming hazardous failures. Security controls must themselves be analysed for availability and failure behaviour.

Other challenges include ageing components, electromagnetic interference, supply-chain substitutions, counterfeit parts, climate stress, insufficient independence between assessor and developer, and organizational pressure to accept residual risk. Ethical governance requires transparent reporting of unsafe conditions, protection of maintenance personnel, respect for human override, and avoidance of misleading claims of certification.

Best practice is to begin safety analysis early; define measurable safety requirements; minimize complexity; design for diagnostic observability; separate safety and non-safety functions where justified; analyse common cause and dependent failures; test fault reactions rather than only nominal operation; maintain bidirectional traceability; control tools and configurations; involve independent reviewers; and revisit the safety case throughout service life.

Chapter Summary

Dependability is a system property encompassing reliability, availability, maintainability, safety, integrity, security, and resilience. Functional safety manages unacceptable risk arising from malfunctioning behaviour through a disciplined lifecycle. Faults may propagate into errors, failures, hazardous situations, and accidents; engineering controls interrupt this chain.

FMEA provides a bottom-up examination of failure modes and controls, while FTA decomposes hazardous top events and reveals minimal cut sets. STPA and related methods complement these techniques for software-intensive and socio-technical systems. Watchdogs, diagnostics, ECC, communication protection, redundancy, diversity, containment, and fail-safe or fail-operational architectures are useful only when their assumptions and reactions are explicitly defined.

Simple reliability and probability equations are helpful for preliminary reasoning but cannot substitute for standards-based analysis of latent faults, common cause, dependencies, proof-test intervals, and uncertainty. IEC 61508 and sector standards establish lifecycle and evidence expectations, not automatic safety by component purchase. A safety case connects claims, arguments, evidence, assumptions, and residual-risk decisions. Contemporary systems additionally require cybersecurity, control of AI-related uncertainty, supply-chain governance, and ongoing operational feedback.

Key Terms

Fault: A defect or abnormal condition that may produce an error.

Error: An incorrect internal system state.

Failure: Deviation of delivered service from specified service.

Hazard: A condition with potential to cause harm.

Risk: Combination of the likelihood and severity of harm.

Dependability: Ability to deliver trusted service under stated conditions.

Reliability: Probability of performing required function for a specified time.

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

Maintainability: Ability to be restored effectively after failure.

Functional safety: Risk reduction achieved through correct functioning of safety-related systems.

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

FTA: Top-down deductive analysis of causes of a hazardous top event.

Diagnostic coverage: Fraction of relevant faults detected by a diagnostic.

Watchdog: Supervisory timer that reacts when expected processor activity is absent or abnormal.

Redundancy: Use of multiple elements to perform or support a function.

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

Fail-safe: Transition to a defined acceptably low-risk state after a fault.

Fail-operational: Continued required operation after specified faults.

Safety case: Structured claim, argument, evidence, and assumptions supporting safety.

Safety Integrity Level: IEC 61508 measure of required and achieved risk-reduction integrity.

Review Questions

Short Answer Questions

1. Distinguish a fault, error, failure, and hazard.

2. Why can a highly reliable system still be unsafe?

3. What is the purpose of a watchdog timer?

4. State one important limitation of FMEA.

5. Why is redundancy alone insufficient to establish safety?

Long Answer Questions

1. Explain the functional-safety lifecycle from hazard analysis to operation and maintenance.

2. Compare FMEA, FTA, STPA, and event-tree analysis, including appropriate applications.

3. Discuss fail-safe and fail-operational architectures with suitable embedded-system examples.

4. Explain how diagnostic coverage, latent faults, and common-cause failures influence safety claims.

5. Describe the structure and evidential role of a safety case in a regulated system.

Analytical / Application Questions

1. Develop an FMEA for an embedded infusion-pump occlusion-detection function and propose diagnostic controls and safe reactions.

2. Construct an FTA for “uncommanded actuator motion after emergency stop” and identify at least three common-cause failures that a simple independent-channel calculation would miss.

3. Design a watchdog and fault-recovery strategy for a networked robotic controller, including timing assumptions, restart limits, diagnostic logging, and cybersecurity considerations.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents the usual propagation of a malfunction toward harm?

A. Failure → fault → error → hazard

B. Fault → error → failure → hazardous situation

C. Hazard → error → fault → failure

D. Error → hazard → fault → failure

Correct Answer: B. Fault → error → failure → hazardous situation

Question 2

For a constant failure rate λ under an exponential non-repairable model, reliability at time t is:

A. λt

B. 1 − exp(−λt)

C. exp(−λt)

D. 1/λt

Correct Answer: C. exp(−λt)

Question 3

Which technique begins with a hazardous top event and decomposes its possible causes?

A. FMEA

B. FTA

C. HAZOP only

D. Reliability growth testing

Correct Answer: B. FTA

Question 4

A simple watchdog timer primarily detects:

A. All incorrect algorithmic decisions

B. Processor stalls and some timing failures

C. Every electromagnetic interference event

D. All mechanical wear mechanisms

Correct Answer: B. Processor stalls and some timing failures

Question 5

Why may two redundant channels fail together?

A. Redundancy always increases common-cause failures

B. Shared power, requirements, environment, or maintenance can affect both

C. Independent channels cannot use diagnostics

D. Voting eliminates physical dependencies

Correct Answer: B. Shared power, requirements, environment, or maintenance can affect both

Question 6

If two independent events each have probability 0.001 and both are required for a top event, the estimated top-event probability is:

A. 0.002

B. 0.001

C. 0.0001

D. 0.000001

Correct Answer: D. 0.000001

Question 7

Which statement about diagnostic coverage is most accurate?

A. It is a universal fixed property of a component

B. It is the fraction of relevant faults detected under defined assumptions

C. It guarantees that the system reaches a safe state

D. It is equivalent to availability

Correct Answer: B. It is the fraction of relevant faults detected under defined assumptions

Question 8

What is a principal purpose of a safety case?

A. To replace all system testing

B. To document only component prices

C. To connect safety claims with arguments, evidence, and assumptions

D. To prove that no residual risk exists

Correct Answer: C. To connect safety claims with arguments, evidence, and assumptions

Question 9

Which behaviour best describes a fail-operational system?

A. It always shuts down after any fault

B. It continues the required function after defined faults

C. It ignores detected faults

D. It operates only during maintenance

Correct Answer: B. It continues the required function after defined faults

Question 10

Which statement correctly characterizes functional-safety standards?

A. Buying a certified microcontroller automatically certifies the whole system

B. They apply only to hardware reliability

C. They establish lifecycle, analysis, process, and evidence expectations

D. They eliminate the need for hazard analysis

Correct Answer: C. They establish lifecycle, analysis, process, and evidence expectations