Functional safety is the part of overall system safety that deals with what happens when electronics and software behave incorrectly. It covers the freedom from unacceptable risk caused by malfunctioning behaviour of electrical and electronic systems, including the interaction of those systems with mechanics and hydraulics [1][4]. The wording differs between industries, but the engineering idea is the same in all of them. A system is functionally safe when it produces the correct technical reaction to a defined stimulus in a defined environment, and when it still reaches a defined harmless condition after a fault occurs [1].

The discipline exists because safety used to be a property of mechanical design. Braking, steering and machine guarding were made safe by dual hydraulic circuits, generous dimensioning and mechanical interlocks. As soon as those functions moved into control units and firmware, the old design reserves no longer covered the new failure modes [1]. A modern mid-range car carries roughly 40 to 50 processors, and high-end models contain around 120 [4]. Every one of them can fail in ways that a mechanical engineer never had to consider, such as a bit flip in RAM, a stuck watchdog or a scheduler that misses a deadline.

Typical use cases are automotive electronic control units, industrial drives and machinery, medical electronics, rail signalling, avionics and increasingly drones and industrial IoT equipment [4]. The main standards are IEC 61508 as the generic base, ISO 26262 for road vehicles and DO-254 or DO-178 for airborne equipment [1][4]. Later in this article two real designs illustrate the concepts. One is a system basis chip that monitors a microcontroller and forces a fail-safe output, the other is an instrument display where a small safety microcontroller checks the picture produced by a large multimedia processor [5][6].

Technical Details

Hazard, risk and safety

Three terms are used loosely in everyday language and must be kept apart in engineering work. A hazard is a condition that can lead to injury, death, loss of equipment or environmental harm. A hazard describes only the outcome. Risk adds the likelihood of that outcome, so risk is the combination of frequency and consequence [2].

$$R \;=\; f \cdot M$$

Here R is the risk expressed as consequence per unit time, f is the frequency of the hazardous event in events per unit time, and M is the magnitude of the consequence per event [2]. Both factors can be attacked. Lowering the frequency and lowering the severity of the outcome both shrink the same product.

Safety is then defined as the absence of unacceptable risk rather than the absence of risk, because zero risk is not achievable in a real product [1][2]. A hazard does not require a broken part. An engineer can design a hazard into a perfectly working system, which is why safety analysis has to look at correct operation and emergency operation as well as at failures [2].

ISO 26262 refines the frequency term for road vehicles. The risk of a hazardous event is described as a function of three arguments [1].

$$R \;=\; F(f,\; C,\; S)$$

The arguments are the following.

• f is the frequency of occurrence of the hazardous event.
• C is the controllability, meaning the ability of the driver or of other people involved to avoid the specific harm through a timely reaction.
• S is the severity of the harm that results if the event is not avoided.

The frequency term is not a single measured number. It is itself driven by two independent contributions [1].

$$f \;=\; F_{f}(E,\; \lambda)$$

• E is the exposure, the probability that the vehicle is in the operational situation in which the hazardous event can occur at all. ISO 26262 simplifies this to the probability of the driving scenario, measured either by how often the situation occurs or by how long it lasts.
• λ is the failure rate of the item that can lead to the hazardous event, covering dangerous random hardware failures and the systematic faults that remain in the system.

A higher exposure and a higher failure rate both raise the frequency of the hazardous event. Exposure and controllability reduce the resulting risk, severity raises it. The normative form of this relation is given in ISO 26262 Part 3, Annex B [1].

Whatever gap remains between the resulting risk and the tolerable risk has to be closed by safety measures. If those measures are implemented in electronics or software, they receive a safety integrity level [1].

Fault, error and failure

Safety standards distinguish two families of failure, and the countermeasures are completely different for each [5].

Systematic failures are deterministic. The same cause produces the same wrong behaviour every time. They come from specification mistakes, design mistakes, tool defects and process gaps. They cannot be measured with a failure rate, so they are attacked with process quality, reviews, requirements traceability, tool qualification and disciplined configuration management [4][5].

Random hardware failures happen unpredictably during the operating life of a part and follow a probability distribution. They are permanent, such as a short between two tracks, intermittent, such as a marginal contact under vibration, or transient, such as a memory upset caused by natural radiation [4][5]. They are handled either by lowering the failure rate through better parts and derating, or by detecting and controlling the fault while the product runs.

ISO 26262 classifies faults further by their relation to the implemented diagnostics. Table 1 summarises the classes in the wording used by hardware safety analysis.

Fault class	Covered by a safety mechanism	Effect on the safety goal
Single-point fault	No mechanism present	Violates the safety goal on its own
Residual fault	Mechanism present but does not cover this fault portion	Violates the safety goal on its own
Latent fault	Not detected and not perceived by the driver	Violates the goal only together with a further independent fault
Dual-point fault	Partially covered	Violates the goal in combination with one other fault
Safe fault	Not relevant	Does not measurably increase the risk

Fault classes follow the ISO 26262 terminology as applied in vendor safety documentation [5].

Dependent failures deserve separate attention because they defeat redundancy. A common cause failure makes two channels of a redundant element fail from one root cause. A common mode failure is the subset where both channels fail in the same way, which also disables the comparison between them. A cascading failure starts in one element and propagates to the next element inside the same channel [5].

The safety lifecycle

Functional safety is not a test at the end of development. Both IEC 61508 and ISO 26262 organise the work as a safety lifecycle that spans the concept phase, product development at system, hardware and software level, production, operation, service and decommissioning [1]. The lifecycle exists because mistakes in any phase can create a hazard, and because evidence has to be produced continuously rather than reconstructed afterwards [1].

The management side of the lifecycle defines who is responsible for each activity, how competence is maintained and how lessons from earlier projects flow back into the process. A working quality management system and a safety culture that reaches up to top management are treated as preconditions rather than as optional extras [1][2].

Integration is where many programmes lose control of the schedule. Assigning test effort by risk, tracing every requirement to a test case and keeping build and installation automated are practical measures that keep the evidence chain intact [3]. The distinction between verification and validation matters here. Verification asks whether the product was built according to the specification, validation asks whether the specified behaviour is actually safe in the real environment [1][3].

Integrity levels

Standards grade the required rigour by the criticality of the function. IEC 61508 uses Safety Integrity Levels SIL 1 to SIL 4, with SIL 4 the highest. ISO 26262 uses Automotive Safety Integrity Levels ASIL A to ASIL D, plus the class QM for functions that need no safety-specific measures [4][6]. The level is derived from severity, exposure and controllability during the hazard analysis and risk assessment, and it then drives the required methods, the review independence and the quantitative targets [1].

The intuition behind the level is the necessity and the ability of a human to avert an unsafe situation. Unintended braking or unintended airbag deployment can be fatal and no driver reaction helps, so those functions land at the top of the scale. A parking sensor or a speedometer usually lands lower, because a driver can stop the car safely without either [4].

An integrity level is not fixed forever. ASIL decomposition allows a requirement to be split across two sufficiently independent elements, each of which then carries a lower level while the combination still satisfies the original one [6]. Independence is the condition that makes this legitimate, and it has to be argued with a dependent failure analysis rather than assumed.

Metric	What it measures	ASIL B	ASIL C	ASIL D
Single-point fault metric	Share of dangerous faults covered by diagnostics	≥ 90 %	≥ 97 %	≥ 99 %
Latent fault metric	Share of latent faults covered or perceived	≥ 60 %	≥ 80 %	≥ 90 %
PMHF	Probability of violating one safety goal per hour	< 10−7 h−1	< 10−7 h−1	< 10−8 h−1

Targets as proposed in ISO 26262 and reproduced in vendor and IP literature [1][4].

The metrics in Table 3 are ratios of failure rates, and the failure rate is the reciprocal of the mean time to failure under the usual assumption of an exponential distribution [1].

$$\lambda \;=\; \frac{1}{\mathrm{MTTF}} \qquad 1\ \mathrm{FIT} \;=\; 10^{-9}\ \mathrm{h}^{-1}$$

The starting point for every diagnostic argument is the diagnostic coverage, the share of the failure rate of an element that a safety mechanism detects and controls [1].

$$\mathrm{DC} \;=\; \frac{\lambda_{\mathrm{detected}}}{\lambda_{\mathrm{total}}}$$

The single-point fault metric expresses how much of the safety related failure rate is neither an uncovered single-point fault nor a residual fault.

$$\mathrm{SPFM} \;=\; 1 – \frac{\sum \lambda_{\mathrm{SPF}} + \sum \lambda_{\mathrm{RF}}}{\sum \lambda_{\mathrm{SR}}}$$

• λ_SPF is the failure rate of single-point faults, which have no safety mechanism at all.
• λ_RF is the failure rate of residual faults, the portion of a fault that the present mechanism does not cover.
• λ_SR is the total failure rate of the safety related hardware parts.

The latent fault metric applies the same idea to faults that stay hidden. It is evaluated over the failure rate that remains after the single-point and residual contributions have been taken out.

$$\mathrm{LFM} \;=\; 1 – \frac{\sum \lambda_{\mathrm{MPF,latent}}}{\sum \lambda_{\mathrm{SR}} – \sum \lambda_{\mathrm{SPF}} – \sum \lambda_{\mathrm{RF}}}$$

λ_MPF,latent is the failure rate of multiple-point faults that are neither detected by a mechanism nor perceived by the driver.

The top failure metric is not a ratio but a probability per hour of operation, evaluated for one safety goal.

$$\mathrm{PMHF} \;=\; \frac{P_{\text{safety goal violated}}}{t_\text{operating hour}}$$

The numerator is the probability that random hardware failures violate the safety goal under consideration, and the metric is evaluated per safety goal over the operating life of the item.

Two remarks keep these numbers honest. First, the targets apply per safety goal, not per system, which is the main difference to the PFH figure used by IEC 61508 [1]. Second, the values have no absolute meaning. They are useful to compare a new design against trusted existing designs, and a developer may justify different targets when the argument is sound [1][4].

Safe states and timing

A safety mechanism consists of a detection part and a reaction part. Detection is quantified by diagnostic coverage, the share of the relevant failure modes that the mechanism recognises. Reaction moves the system into a safe state, degrades it gracefully, or switches to a redundant channel that has been shown to be fault free at runtime [1][4].

Timing turns this into a hard engineering constraint. Not every fault becomes a hazard immediately, because mechanical and electrical inertia buy time. The fault tolerant time interval, FTTI, is the span between the occurrence of a fault that can cause a hazardous event and the moment by which the countermeasure has to be complete [4][5]. Inside the FTTI the design has to fit the fault detection time interval and the fault reaction time interval, and their sum is the fault handling time interval [6].

$$t_{\mathrm{FHTI}} \;=\; t_{\mathrm{FDTI}} + t_{\mathrm{FRTI}} \;\le\; t_{\mathrm{FTTI}}$$

• t_FDTI is the fault detection time interval, from the occurrence of the fault to the moment the diagnostic recognises it.
• t_FRTI is the fault reaction time interval, from detection to the completed transition into the safe state.
• t_FHTI is the fault handling time interval, the sum of the two.
• t_FTTI is the fault tolerant time interval, from the occurrence of the fault to the moment the hazardous event would happen.

The inequality is the design constraint. It has to hold under worst case conditions, not on average, which is why diagnostic period, task scheduling and communication latency all become safety requirements [6].

Safety functions are therefore real-time functions. Missing a deadline in a steering or braking path is a total failure, missing a deadline in an engine management path degrades quality without violating a safety goal, and missing a deadline in a lighting function is usually tolerable because the driver notices and compensates [1]. Latent faults follow a slower clock. They only need to be found within the multiple-point fault detection interval, which in vehicles is commonly one driving cycle, so a built-in self test at power-up is an accepted mechanism [5].

Analysis methods

The concept phase and the design phase use different analytical tools, and mature projects combine them.

Inductive methods start from a component failure mode and ask what it causes. FMEA and its quantitative extension FMEDA belong here, and FMEDA is the method used to compute the architectural metrics of a hardware element [2][5]. Deductive methods start from an undesired top event and ask which combinations of basic events produce it. Fault tree analysis belongs here and delivers the minimal cut sets, which are the shortest paths from basic faults to the top event [1][2]. Process industries add HAZOP and what-if checklists, and human error is covered by human factors analysis [2].

When a design change is needed, the order of preference is fixed and applies far beyond electronics. Remove the hazard by design, then add safety devices, then add warning devices, then fall back to procedures and training [2]. Electronics belongs mostly to the second and third step, which is a useful reminder that a diagnostic routine is never the first answer to a bad architecture.

Evidence and the safety case

The final deliverable of a functional safety programme is an argument, not a number. A safety case is a structured argument, supported by evidence, that justifies why the system is acceptably safe in its specific operating environment [4]. Safety cases are hierarchical. A semiconductor supplier contributes to the case of the chip vendor, the chip vendor contributes to the case of the Tier 1 supplier and so on up to the vehicle manufacturer [4].

Many components are developed without knowledge of the final application. This is the safety element out of context model. The supplier states the assumptions under which the element is safe, and the integrator has to confirm that the real system matches those assumptions [4][5]. The safety manual that carries these assumptions is as much a part of the product as the silicon.

Examples

A system basis chip supervising a microcontroller

A system basis chip combines the voltage regulators, the bus transceivers and the supervision logic that sit next to a microcontroller. The NXP MC33904 and MC33905 show what that supervision contributes to an ASIL B design, and the accompanying safety manual states the assumptions under which the contribution holds [5]. This is the safety element out of context model in practice. The component supplier defines the safety related functions and their timing, the integrator confirms that the real system matches them.

Three safety related functions are declared. The chip has to supply the microcontroller core voltage inside a specified range, it has to run a periodic handshake with the microcontroller, and it has to signal a fail-safe condition on a dedicated output within the fault tolerant time interval [5].

The watchdog implements the handshake. In its enhanced modes the microcontroller must answer with a value derived from a random code, and in window mode the answer is only accepted in the second half of the period. A trivial timer refresh from an interrupt therefore does not satisfy the watchdog, which is what makes it a control flow check rather than a liveness check [5].

The safe state of the device is defined as one of three conditions. Operating correctly, explicitly indicating an error through the active-low fail-safe pin, or being completely unpowered. Everything beyond that is the responsibility of the integrator, who must ensure that the system reaches its own safe state when the chip signals an error [5].

The timing budget is concrete. Undervoltage on the core supply is indicated after roughly 40 microseconds, a reset line shorted to ground after about 100 milliseconds, and a watchdog failure after up to 256 milliseconds by default. The default fault tolerant time interval is therefore set by the watchdog window at 256 milliseconds, and shortening that window to below 100 milliseconds moves the limiting case to the reset monitoring [5].

The quantitative side comes from an FMEDA. The failure rate model follows IEC/TR 62380 and adds three contributions for permanent faults in a semiconductor [5].

$$\lambda_{\mathrm{device}} \;=\; \lambda_{\mathrm{die}} + \lambda_{\mathrm{package}} + \lambda_{\mathrm{EOS}}$$

The die term depends on the technology, its maturity, the transistor count and the mission profile. The package term depends on pin count, pitch, board material and temperature cycles. The third term covers electrical overstress at the interfaces. For this device the numbers are 46.61 FIT, 25.38 FIT and 0 FIT, so the total is roughly 72 FIT, which corresponds to 72 × 10⁻⁹ failures per hour. Transient faults are argued away for this 0.25 micrometre process because no SRAM is present and the node size makes radiation induced upsets unlikely [5].

Declared function	Mechanism in the device	Reaction	Indicative timing
Core supply within range	Undervoltage monitor	Assert fail-safe output	≈ 40 µs
Correct microcontroller execution	Windowed challenge and response watchdog	Assert fail-safe output	≤ 256 ms (default)
Reset path integrity	Reset output monitoring	Assert fail-safe output	≈ 100 ms

Values from the device safety manual [5].

The following sketch shows the shape of the microcontroller side of the handshake. It is written for readability and follows common embedded coding rules, so it uses fixed width types, avoids side effects in conditions and gives every branch a defined outcome.

/* Windowed challenge-response watchdog service.
   Called once per control cycle from the highest priority task. */

typedef enum
{
    WDG_OK         = 0,
    WDG_TOO_EARLY  = 1,
    WDG_BAD_ANSWER = 2
} wdg_result_t;

static wdg_result_t Wdg_service(void)
{
    uint16_t     challenge;
    uint16_t     answer;
    wdg_result_t res;

    if (sbc_window_is_open() == false)
    {
        res = WDG_TOO_EARLY; /* early refresh is itself a fault */
    }
    else
    {
        challenge = sbc_read_challenge();
        answer    = wdg_derive_answer(challenge);
        res       = (sbc_write_answer(answer) == true) 
                    ? WDG_OK : WDG_BAD_ANSWER;
    }

    return res;
}

A refresh outside the open window is reported as a fault instead of being silently retried, because an early refresh indicates that the control flow is already wrong.

ASIL decomposition in an instrument display

The second example shows how a system reaches an integrity level that none of its main processors carries alone. NXP combines an i.MX RT1170 multimedia processor with an S32K118 microcontroller to build an automotive display that satisfies ASIL B [6].

The multimedia processor is a QM device. It cannot lift the system to ASIL B by itself. The S32K118 is an ASIL B device, so the requirement is decomposed into an ASIL B(B) part handled by the small microcontroller and a QM(B) part handled by the large processor. The decomposition is only allowed because the two elements are sufficiently independent, and the design supports that claim with a separate buck converter for the safety domain instead of sharing the multimedia power management chip [6].

The assumed hazard is simple to state. The image on the display may not match what the vehicle actually reports, and a driver who trusts a wrong telltale can make a wrong decision. The safety goal follows directly, which is that the displayed image must match the expected content. The safety mechanism is a cyclic redundancy check over each displayed frame [6].

At runtime the multimedia processor renders the frame and its display integrity checker computes the CRC of the frame. The safety microcontroller holds a reference list of CRC values for every icon state, receives the computed value over a serial link and compares the two. A mismatch drives a warning LED and an audible alarm and starts the transition to the safe state. The application note assumes a fault handling time interval shorter than an FTTI of 350 milliseconds [6].

Scenario	Belt state	Icon shown	CRC comparison	System reaction
Normal, belt open	not fastened	icon on	match	none
Normal, belt closed	fastened	icon off	match	none
Rendering fault	fastened	icon wrong	mismatch	LED and alarm, transition to safe state

Behaviour of the reference platform [6].

The comparison itself is short, which is typical for safety mechanisms. The value is in the reference data and in the reaction, not in the algorithm.

/* Frame integrity check on the safety microcontroller. */

static void frame_check_cycle(const frame_state_t *state)
{
    uint32_t expected;
    uint32_t reported;

    expected = crc_reference_lookup(state->icon_id, state->icon_status);
    reported = link_get_reported_crc();

    if (expected != reported)
    {
        safe_state_enter(SAFE_STATE_DISPLAY_MISMATCH);
    }
    else
    {
        fault_counter_reset(FAULT_ID_DISPLAY);
    }
}

The same logic outside the vehicle

The reasoning is not automotive property. In process plants, a pressure relief valve is the safety device that acts when the control loop fails, a gas detector is the warning device, and a permit-to-work procedure is the last line when neither is sufficient [2]. Moving nitrogen bottles out of an occupied room removes an asphyxiation hazard entirely and beats every diagnostic that could be added later [2]. Engineers who learn functional safety in one industry can usually transfer the method, and only have to relearn the vocabulary and the target metrics of the local standard [4].

Summary

Functional safety asks what a system does when its electronics and software go wrong, and it answers with defined behaviour rather than with hope.

The most important points are these. Hazard, risk and safety are distinct terms, and safety means the absence of unacceptable risk instead of the absence of risk [1][2]. Systematic failures are fought with process and review, random hardware failures with detection and control at runtime [4][5]. The integrity level is derived from severity, exposure and controllability, and it sets the methods and the quantitative targets for the rest of the project [1][4]. A safety mechanism is only useful if its detection and reaction together fit inside the fault tolerant time interval [5][6]. Decomposition can lower the level required from an individual element, but only when independence is argued and designed in, as the display example shows with its separate power domain [6]. Finally, the deliverable is a safety case, a structured argument backed by evidence, and for components used out of context the assumptions of use are part of that argument [4][5].

The metric values quoted above are the targets proposed in ISO 26262. They are design guidance rather than absolute limits, and a project may set different targets when the safety argument supports them [1][4].

References

[1] Hans-Leo Ross, Functional Safety for Road Vehicles: New Challenges and Solutions for E-mobility and Automated Driving, Springer International Publishing, 2016.

[2] Nicholas J. Bahr, System Safety Engineering and Risk Assessment: A Practical Approach, Second Edition, CRC Press, Taylor & Francis Group, 2015.

[3] Boyd L. Summers, Effective Methods for Software and Systems Integration, CRC Press, Taylor & Francis Group, 2013.

[4] Andrew Hopkins, The Functional Safety Imperative in Automotive Design, ARM Limited White Paper, September 2016.

[5] NXP Semiconductors, AN12048: Safety Application Note for MC33904 and MC33905, Rev. 1.0, 21 September 2017.

[6] NXP Semiconductors, AN13659: Enabling Automotive Safety Display Based on i.MX RT1170 with Safety MCU S32K, Rev. 0, 23 June 2022.