Electronics Guide

Articles in This Category

Safety, Reliability, and Security

Engineers often conflate three properties that safety standards keep distinct. Reliability is the probability that a system performs its intended function for a given interval. Safety is freedom from unacceptable risk of harm. Security is resistance to deliberate attack. A system can be highly reliable and still unsafe, because it reliably does the wrong thing; conversely, a system that shuts itself down every hour is unsafe to fly but perfectly safe as a railway signal, which defaults to red.

Safety standards therefore reason about risk rather than uptime. Risk combines the severity of a possible harm with the probability of the hazardous event that leads to it, and often with the ability of an operator or another system to control the situation once it begins. Because zero risk is unattainable, standards define a threshold of tolerable risk and require evidence that the design reaches it. Several regimes, notably in the United Kingdom and in IEC 61508 practice, express this through the ALARP principle: risk must be reduced as low as reasonably practicable, where further reduction would be grossly disproportionate to the benefit gained.

A further distinction separates functional safety from the safety of intended functionality. Functional safety concerns hazards that arise when something fails, whether a random hardware fault or a systematic design error. The safety of intended functionality concerns hazards that arise when nothing fails at all, because a correctly operating function is insufficient for the situation it encounters. A camera-based perception system that misclassifies an obstacle in low sun is the canonical example, and ISO 21448 was written to address that class of hazard alongside ISO 26262.

Fundamental Principles

Fail-Safe and Fail-Operational Design

Systems must transition to a defined safe state when a failure occurs, which requires identifying that state for every credible failure mode and proving the system can reach it under degraded conditions. The appropriate safe state is domain-specific. A railway signaling system defaults its signals to red and its points to a protective position, because stopping trains is inherently safe. A press brake removes power and applies a mechanical restraint. An aircraft flight control system, by contrast, cannot simply shut down; it must be fail-operational, reverting to a degraded but still controllable mode such as direct law, in which the computers map pilot inputs to control surface deflections without the flight envelope protections available in normal operation. Automotive steer-by-wire and automated driving functions have moved in the same direction, since an unpowered steering column at highway speed is not a safe state.

Fault Tolerance and Diversity

Critical functions employ redundancy through hardware replication, diverse software implementations, or both. Redundant channels must detect disagreement and continue operating with reduced capability rather than failing silently. Simple replication defends only against random hardware faults: identical channels running identical software share every software defect, so a single systematic error defeats all of them simultaneously. Diverse redundancy answers that threat by varying the implementation, whether through independent development teams, different processor families, different compilers, or dissimilar algorithms. The Boeing 777 flight control system is a well-documented example, using three dissimilar processor types within each of its triple-redundant channels. Diversity is expensive, and empirical studies have shown that independently developed versions still fail on correlated inputs, so it reduces rather than eliminates common-cause failure.

Deterministic Behavior

Safety functions carry timing requirements as binding as their functional requirements, because a correct response delivered late is a failure. Designers must bound worst-case execution time and interrupt latency under all operating conditions rather than measure typical behavior. This favors static memory allocation over heap use, bounded loops over open-ended iteration, fixed task sets over dynamic thread creation, and cache and pipeline configurations whose effects can be analyzed. Multicore processors complicate the picture considerably, since cores contend for shared caches, memory controllers, and interconnects; aviation authorities addressed that interference explicitly in EASA AMC 20-193, issued in 2022, and the technically aligned FAA AC 20-193, issued in 2024, which together superseded the earlier CAST-32A position paper.

Traceability and Independence

Every safety requirement must be traceable forward into design, code, and test cases, and backward from each artifact to the requirement that justifies it. Bidirectional traceability demonstrates two things at once: that each requirement is implemented and verified, and that no code exists without a requirement behind it. Unjustified code is treated as a hazard in its own right, which is why standards distinguish dead code, which must be removed, from deactivated code, which is intentionally present but disabled and must be shown to be unreachable in the target configuration. Higher integrity levels add organizational independence, requiring that verification be performed by people other than the developers, and at the highest levels that assessment be performed by a separate organization.

Integrity Levels and Quantitative Targets

Safety standards allocate rigor through integrity levels. A hazard analysis establishes how severe each hazardous event would be and how likely it is, and the resulting level then determines which development, verification, and documentation objectives apply. The vocabulary differs by sector but the mechanism is shared: IEC 61508 assigns Safety Integrity Levels SIL 1 through SIL 4, ISO 26262 assigns ASIL A through ASIL D plus Quality Management for hazards with no applicable risk, DO-178C assigns Design Assurance Levels A through E, and IEC 62304 assigns software safety classes A, B, and C.

Where the failure of hardware can be modeled statistically, the levels carry numerical targets. IEC 61508 expresses them two ways. For low-demand systems, which act rarely and are tested periodically, the target is the average probability of failure on demand: SIL 1 corresponds to the band from 10⁻² to 10⁻¹, and each successive level tightens by a factor of ten to the band from 10⁻⁵ to 10⁻⁴ at SIL 4. For high-demand or continuous systems, the target is the average frequency of dangerous failure per hour, from 10⁻⁶ to 10⁻⁵ at SIL 1 down to 10⁻⁹ to 10⁻⁸ at SIL 4.

ISO 26262 applies a comparable scheme to vehicle electronics through three metrics. The single-point fault metric measures how much of the hardware failure rate is either safe by construction or covered by a diagnostic, with targets of at least 90 percent for ASIL B, 97 percent for ASIL C, and 99 percent for ASIL D. The latent-fault metric measures coverage of dormant faults in the safety mechanisms themselves, with targets of at least 60, 80, and 90 percent for the same levels. The probabilistic metric for random hardware failures caps the residual rate below 10⁻⁷ per hour for ASIL B and ASIL C and below 10⁻⁸ per hour for ASIL D. ASIL A carries qualitative requirements without quantitative targets for these metrics.

Software receives no such probability figures, because software failures are systematic rather than random: a defective program fails every time its triggering conditions recur, so a failure rate has no physical meaning. Standards therefore control software risk through process rigor. In DO-178C, the assurance level determines how many objectives apply, how many require independence, and which structural coverage criterion must be satisfied. Level C requires statement coverage, Level B adds decision coverage, and Level A additionally requires modified condition/decision coverage, which demands that each condition within a compound decision be shown to affect the outcome independently. Levels D and E require no structural coverage analysis, and Level E software, having no safety effect, falls outside the scope of the document.

Sector Standards

IEC 61508 is the generic parent standard for functional safety of electrical, electronic, and programmable electronic safety-related systems. It covers the full safety lifecycle, defines the SIL framework, and supplies the techniques tables that sector standards adapt. The current second edition dates from 2010; a third edition is in preparation, with the committee work addressing object-oriented programming, semiconductor integrity, and the integration of cybersecurity considerations. Most industries work instead from a derivative tailored to their hazards and regulators.

Aerospace

DO-178C, issued in 2011 with the EUROCAE equivalent ED-12C, governs software considerations in airborne systems and equipment certification, and DO-254 provides the analogous guidance for complex airborne electronic hardware. Three supplements extend DO-178C for model-based development (DO-331), object-oriented technology (DO-332), and formal methods (DO-333), while the companion document DO-330 covers tool qualification and defines five tool qualification levels according to whether a tool can insert an error into the product or merely fail to detect one. Design assurance levels derive from the severity of the failure condition, which in transport-category aircraft certification is paired with target probabilities: a catastrophic failure condition must be shown to be extremely improbable, conventionally interpreted as a probability below 10⁻⁹ per flight hour.

Automotive

ISO 26262, whose second edition appeared in 2018 and extended coverage from passenger cars to motorcycles, trucks, and buses, defines the automotive safety lifecycle. ASIL determination combines three factors assessed for each hazardous event: severity of possible harm, probability of exposure to the operational situation, and controllability by the driver or other road users. The standard also formalizes the safety element out of context, which allows a supplier to develop a component against assumed requirements that the integrator later confirms. ISO 21448 addresses the safety of the intended functionality for perception and driver assistance, and UL 4600 offers a safety-case framework for products that operate without human supervision.

Medical Devices

IEC 62304 specifies lifecycle processes for medical device software and assigns each software item to class A, B, or C according to the severity of harm that a failure could cause, from no injury through non-serious injury to death or serious injury. The class determines how much architectural detail, unit verification, and documentation the manufacturer must produce. IEC 62304 does not stand alone: ISO 14971 supplies the risk management process it depends on, and IEC 60601-1 governs the basic safety and essential performance of medical electrical equipment, with its programmable electrical medical systems clause covering embedded control.

Industrial and Process

IEC 61511 applies IEC 61508 to safety instrumented systems in the process industries, addressing the design and operation of protective functions such as emergency shutdown and overpressure protection. In machinery, ISO 13849 and IEC 62061 provide two routes to the same end, the former through performance levels a through e and the latter through SIL, both covering the control systems of guards, interlocks, and emergency stops. Nuclear instrumentation and control follows IEC 61513 at the system level and IEC 60880 for category A software.

Railway

The CENELEC family covers railway applications: EN 50126 for the overall reliability, availability, maintainability, and safety process, EN 50129 for safety-related electronic systems in signaling, and EN 50159 for safety-related communication in transmission systems. Software development moved to EN 50716, published in 2023, which unified and superseded the trackside standard EN 50128 and the on-board standard EN 50657, with a transition period allowing the older standards to remain in use into late 2026.

Architectural Techniques

Safety architecture is the practice of arranging components so that no single fault, and often no credible combination of faults, produces a hazard. Several patterns recur across sectors.

Redundancy and Voting

Dual-channel architectures detect disagreement but cannot identify which channel is wrong, so they typically respond by commanding the safe state; this suits fail-safe applications such as shutdown systems. Triple modular redundancy adds a voter that masks a single faulty channel and allows continued operation, which suits fail-operational applications. Quadruplex arrangements tolerate a second failure once the first channel has been isolated, at the cost of a fourth set of hardware. Lockstep processors apply the same idea inside a single package: two cores execute identical instruction streams a few cycles apart, and comparison logic raises a fault on any divergence, a configuration common in automotive and industrial microcontrollers rated for ASIL D and SIL 3 use.

Monitoring and Diagnostics

Where full redundancy is uneconomical, an asymmetric monitor-actuator arrangement pairs a complex primary channel with a simpler, independently developed monitor that checks the primary's output against safety constraints and can force the safe state. The monitor is small enough to verify thoroughly, so the pair achieves a higher integrity level than the primary alone. Supporting mechanisms include windowed watchdog timers, which detect both a stalled and a runaway task; error-correcting code on memory and buses; cyclic redundancy checks on stored configuration and transmitted messages; periodic built-in self-test of processor cores, memories, and analog front ends; and plausibility checks that compare a sensor against an independent estimate. Diagnostic coverage, the fraction of dangerous failures a mechanism detects, is a direct input to the quantitative metrics described above.

Partitioning and Mixed Criticality

Modern platforms consolidate functions of different criticality onto shared hardware, which is economical only if a lower-criticality function cannot interfere with a higher one. Robust partitioning provides that guarantee in space, through memory protection units or memory management units that confine each partition to its own address space, and in time, through a scheduler that grants each partition a fixed window regardless of its behavior. ARINC 653 codifies this model for avionics and defines the interface between the operating system and application partitions. Separation kernels and certified hypervisors extend the same principle to virtualized guests, and the ARINC 664 Part 7 avionics full-duplex switched Ethernet standard applies analogous reasoning to the network by giving each virtual link a guaranteed bandwidth allocation and bounded latency.

Development Lifecycle

Safety standards prescribe a lifecycle, usually a V-model, in which every development phase has a matching verification phase and every phase produces reviewable evidence. Planning comes first: the team defines the safety lifecycle, the verification strategy, the configuration management and problem-reporting procedures, and the required independence, and an assessor reviews those plans before significant work begins.

Hazard analysis and risk assessment. The process starts by defining the item and its operational context, then identifying hazards and the operational situations in which they matter. Preliminary hazard analysis frames the problem; FMEA and its extension FMEDA work bottom-up from component failure modes to effects and diagnostic coverage; fault tree analysis works top-down from an undesired event to combinations of causes; HAZOP applies guide words systematically to process deviations; and STPA treats safety as a control problem, identifying unsafe control actions rather than component failures, which makes it useful for software-intensive systems whose hazards arise from interactions rather than breakage.

Requirements engineering. Hazard analysis yields safety goals, which decompose into functional safety requirements and then technical requirements allocated to hardware and software. Each must be unambiguous, verifiable, and free of implementation bias, and each must carry an integrity level and a trace link. Requirements management tooling supports the impact analysis that every subsequent change demands.

Architecture and design. The architecture must show how it satisfies the safety requirements through partitioning, redundancy, monitoring, and isolation. Analysts examine it for single points of failure, for common-cause and cascading failures, and for dependent failure initiators such as shared power supplies, shared clocks, and shared memory. Independence claims between channels must be justified rather than assumed.

Implementation. Coding standards, static analysis, and review govern the code. Safety-critical software normally uses a restricted language subset such as MISRA C or MISRA C++ to eliminate undefined and implementation-defined behavior, and some domains use languages designed for analysis, such as SPARK Ada. Compilers and analysis tools must themselves be qualified when their failure could allow an error to escape, following DO-330 tool qualification levels in aviation or the tool confidence level scheme of ISO 26262, under which tools classified TCL2 or TCL3 require qualification.

Verification and validation. Requirements-based testing at unit, integration, and system levels demonstrates that each requirement is met, including robustness testing with invalid and out-of-range inputs. Structural coverage analysis then reveals code exercised by no requirement-based test, which indicates either missing tests, missing requirements, or unjustified code. Fault injection exercises the safety mechanisms themselves by forcing the failures they are meant to catch. Timing analysis establishes worst-case execution time, and formal methods increasingly prove properties that testing can only sample, an approach DO-333 recognizes as a substitute for certain verification objectives.

Safety case and release. The accumulated evidence is assembled into a safety case: a structured argument, supported by that evidence, that the system is acceptably safe for a defined application in a defined environment. Independent assessment reviews the argument, and the resulting approval is specific to a configuration, so any subsequent change triggers impact analysis and, potentially, re-verification.

Current Challenges

Three pressures are reshaping the field. The first is security. A safety function that an attacker can disable is not safe, and connectivity has made remote attack a credible hazard cause. Standards have responded by pairing safety with security processes: IEC 62443 in industrial automation, ISO/SAE 21434 for road vehicles, and DO-326A with its companions for airworthiness security. The revision work on IEC 61508 makes the coupling explicit. Because a security patch can invalidate a safety argument, the two disciplines must share a change-management process rather than run in parallel.

The second is machine learning. Neural networks resist the traceability that certification depends on, since their behavior derives from training data rather than from requirements a reviewer can inspect, and their failure modes are distributional rather than discrete. Work on this problem is active but immature, drawing on ISO 21448, UL 4600, and emerging aviation guidance, with practical deployments so far relying on architectural containment: a conventional monitor of verifiable complexity bounds what the learned component is permitted to command.

The third is complexity. Consolidating dozens of functions onto multicore systems on chip delivers cost and weight savings that are hard to refuse, but it makes interference analysis, worst-case timing, and independence arguments substantially harder. Much of the certification effort in current programs goes into demonstrating that the sharing introduced for economic reasons does not undermine the separation required for safety.

About This Category

The articles in this category address the specialized knowledge that safety-critical embedded development demands: the standards that define the rules, the analyses that identify what can go wrong, the architectures and coding disciplines that keep it from going wrong, the monitoring that catches it when it does, and the certification processes that make the result acceptable to a regulator. Engineers whose work touches systems where human safety depends on correct hardware and software operation will find these practices to be requirements rather than recommendations.

Related Topics

Several of the standards summarized above receive fuller treatment elsewhere on this site.