Electronics Guide

Articles in This Category

Why Software Safety Is a Different Problem

Hardware safety arguments rest on quantities. A designer estimates a dangerous failure rate, applies redundancy and diagnostics, and demonstrates that the residual probability meets a numerical target. None of that transfers to software. A program has no wear-out mechanism and no failure distribution; it either contains a defect on a given execution path or it does not. Testing samples the input space, but the reachable state space of even a modest embedded controller is far too large to enumerate, so testing can reveal defects and can never demonstrate their absence.

Redundancy also behaves differently. Running two copies of the same program on two processors protects against random hardware faults and does nothing about a coding error, because both copies compute the same wrong answer. Diverse implementations, in which separate teams build to the same specification, reduce but do not eliminate correlated failure, since the teams still share the specification and tend to make similar mistakes on the hard cases. The most reliable defenses are therefore preventive: a specification precise enough to be verifiable, an architecture that limits what any one defect can reach, and verification evidence that an independent party can inspect.

This is why every software safety standard is written as a process standard. The deliverable is not a measured failure rate but an argument: a plan that states what will be done, records that show it was done, and traceability that connects each requirement to its design, its code, and the tests that exercised it. Regulators and assessors accept or reject that argument. The engineering work of building it is what the articles in this category describe.

The Common Framework

Despite different vocabularies, the sector standards share a recognizable shape. Hazard analysis at the system level allocates safety requirements to software. Those requirements are refined through architecture and detailed design into code, then verified back up the same chain, which is why the model is usually drawn as a V. Each stage produces reviewable artifacts, each artifact is traced to the stage above it, and the depth of verification required at every stage is set by an integrity level derived from the consequences of failure.

Integrity Levels Across Sectors

IEC 61508 defines safety integrity levels SIL 1 through SIL 4, with SIL 4 the most demanding, and expresses the software dimension as a systematic capability of the same range. DO-178C uses design assurance levels A through E, tied to the severity of the failure condition the software can contribute to: Level A for catastrophic conditions, Level B for hazardous, Level C for major, Level D for minor, and Level E for software with no safety effect. ISO 26262 uses automotive safety integrity levels A through D, derived from the severity, exposure, and controllability of each hazardous event, with quality-managed development for items below ASIL A. The railway standards keep a graded software safety integrity level from a basic level up to the most rigorous. IEC 60880 applies to software implementing category A functions, those required to reach and maintain a safe state in a nuclear plant, and sits under the system-level framework of IEC 61513.

These scales are not interchangeable. ASIL D, SIL 3, and DO-178C Level A are the top of the ladder in their own domains, but they were derived from different hazard models and impose different objectives, so mapping one onto another is an engineering judgment that must be justified rather than a lookup. Certification credit likewise does not transfer automatically between sectors.

What a Higher Level Actually Requires

Raising the integrity level does not change the programming language or the algorithm. It changes three things. First, the required techniques: IEC 61508-3 rates each technique as highly recommended, recommended, or not recommended per SIL, and formal methods, static analysis, and structured design move from optional to expected as the level rises. Second, the required independence: at higher levels, the person who verifies an artifact may not be the person who produced it, and at the highest levels verification is performed by a separate organizational unit or an accredited assessor. Third, the required evidence: DO-178C Level A carries the full set of objectives, many of them with independence, while Level D carries a small fraction of them. The cost curve is steep, which is why architectural decisions that keep safety-critical code small are worth far more than efficiency gains inside it.

Building the Verification Evidence

Coding Standards and Static Analysis

Safety-critical projects restrict the language before they write any code. The MISRA C guidelines, first issued for the automotive industry and now used well beyond it, forbid constructs whose behavior is undefined, unspecified, or implementation-defined, along with idioms that are legal but easy to misread. Companion guidance exists for C++, and the CERT secure coding rules overlap where safety and security concerns meet. Compliance is enforced by static analysis tools, and deviations are permitted only with a documented, reviewed justification.

Beyond rule checking, sound static analyzers use abstract interpretation to prove the absence of whole classes of runtime error: division by zero, out-of-bounds array access, integer overflow, and use of uninitialized data. Related static analyses bound worst-case execution time and maximum stack depth, both of which must be known rather than measured for a system that must meet hard deadlines. These analyses are the reason safety-critical code typically avoids dynamic memory allocation after initialization, unbounded recursion, and unbounded loops: the restrictions exist so that the analysis can terminate with a proof.

Requirements-Based Testing and Structural Coverage

Testing in this discipline is driven by requirements, not by code. Each requirement generates test cases, including normal cases, boundary values, and robustness cases with invalid inputs. Structural coverage is then measured to answer a different question: which code did the requirements-based tests fail to exercise? Uncovered code signals either a missing requirement, a missing test, dead code, or deactivated code that must be shown to be unreachable in the target configuration.

DO-178C makes the graduation explicit. Level C requires statement coverage, Level B adds decision coverage, and Level A adds modified condition/decision coverage, which requires showing that each condition within a compound decision independently affects the outcome. Level A also requires verification of data and control coupling between components. ISO 26262-6 recommends a comparable progression across ASILs, adding function and call coverage at the integration level. Coverage achieved by tests written to chase the metric rather than to verify a requirement is worthless as evidence, and assessors look for exactly that.

Formal Methods and Tool Qualification

Formal methods replace sampling with proof for the properties they cover. Model checking exhaustively explores a finite state model, theorem proving establishes properties over unbounded domains, and contract-based verification proves that each function satisfies its pre- and postconditions. DO-333, published alongside DO-178C in 2011, defines how formal analysis may substitute for testing in satisfying specific objectives, and companion supplements cover model-based development (DO-331) and object-oriented technology (DO-332). Formal proof does not remove the need for testing on the target hardware, because the proof holds only for the model and the assumptions stated.

Any tool whose output is trusted without independent review becomes part of the safety argument itself. If a code generator produces code that is not reviewed, or an analyzer allows a verification step to be skipped, the tool must be qualified. DO-330 defines five tool qualification levels according to the tool's role and the software level it supports, and ISO 26262-8 uses tool confidence levels derived from the tool's impact and the likelihood that its errors would be detected. Qualification is a substantial project in its own right, which is one reason teams prefer tools that arrive with a certification evidence package.

Architecture That Contains Faults

The most effective safety measure is an architecture in which most of the code cannot cause harm. Partitioning enforces that separation in space and in time. Memory protection units confine each partition to its own address range, and a static schedule guarantees each partition its processor time regardless of what the others do. ARINC 653 formalizes this model for integrated modular avionics, allowing applications of different assurance levels to share one processor, and ISO 26262 requires equivalent freedom from interference before software elements of different ASILs may coexist. Without such mechanisms, every element inherits the highest ASIL present.

Monitoring architectures apply the same logic at the system level. A small, highly assured monitor checks the output of a large, less assured function and forces a safe state when the output leaves the acceptable envelope. Because the monitor is far smaller than the function it supervises, it can be verified to a higher standard at an affordable cost. Automotive designs formalize this as a layered monitoring concept, and windowed watchdogs, plausibility checks against independent sensors, and cross-checks between redundant channels serve the same purpose. Defensive programming completes the picture inside each component: validate inputs at every interface, check preconditions and postconditions, protect critical data with checksums or redundant storage, and define the behavior for every unexpected case rather than allowing execution to fall through.

The choice of execution platform matters as much as the application code. A real-time operating system used in a certified product must come with evidence for its own development, and vendors of safety-certified kernels supply exactly that. The same applies to compilers, libraries, and hardware abstraction layers, whose behavior becomes part of the argument the moment the application depends on it.

Firmware Security as a Safety Concern

Safety arguments assume that the software running on the device is the software that was verified. Firmware security exists to make that assumption defensible. A chain of trust starts in immutable boot code, held in mask ROM or in one-time-programmable memory, which verifies a cryptographic signature before transferring control to the next stage; each stage repeats the check for the stage that follows. Signing keys live in hardware security modules with controlled access, because a leaked key invalidates every device in the field. Anti-rollback protection, usually implemented with monotonic counters or programmable fuses, prevents an attacker from reinstalling an older signed image whose vulnerability is already public.

Field updates need the same care applied to availability. A device that bricks itself on a failed update has created a new hazard, so robust designs verify the signature before committing, write to an inactive partition, and keep a known-good image to fall back on if the new one does not confirm a successful boot. Debug interfaces deserve equal attention: JTAG and serial wire debug ports left open in production give an attacker direct access to memory and keys, so production parts lock them, and manufacturers who need field diagnostics use authenticated debug unlock rather than an open port. NIST SP 800-193, published in 2018, organizes these measures into three properties that a resilient platform must provide: protection of firmware against unauthorized change, detection of change when it occurs, and recovery to an authentic image.

Regulation has moved quickly in this area. UN Regulations 155 and 156 require vehicle manufacturers to operate certified cybersecurity and software update management systems, supported by the engineering process in ISO/SAE 21434. IEC 62443-4-1 specifies a secure development lifecycle for industrial products, with IEC 62443-4-2 defining the technical requirements their components must meet. ETSI EN 303 645 sets a baseline for consumer connected devices. In the European Union, the cybersecurity requirements of the Radio Equipment Directive delegated regulation have applied to in-scope radio equipment since 1 August 2025, and the Cyber Resilience Act, Regulation (EU) 2024/2847, phases in next: its vulnerability and incident reporting obligations apply from 11 September 2026, with the remaining requirements from 11 December 2027. Related coverage appears under cybersecurity regulations, industrial cybersecurity, and cybersecurity in medical devices.

Safety and security processes increasingly reference one another. Aviation pairs DO-178C with DO-326A for the airworthiness security process, automotive pairs ISO 26262 with ISO/SAE 21434, and the industrial sector pairs IEC 61508 with IEC 62443. The reason is practical: a security patch is a change to safety-related software, so it must pass through impact analysis and regression verification before it ships, and a program that cannot deliver patches quickly enough will find its safety case eroded by known vulnerabilities.

Pre-Existing, Third-Party, and Open-Source Code

Almost no product is written entirely from scratch. Protocol stacks, file systems, cryptographic libraries, and operating systems arrive from outside, usually without the development evidence a safety standard expects. DO-178C addresses this as previously developed software, allowing credit for prior certification, for service history where the operating environment and problem-reporting record justify it, or for reverse-engineering the missing artifacts. IEC 62304 names the general case software of unknown provenance and requires the manufacturer to identify it, analyze how its failure could contribute to a hazard, and manage its known anomalies. The common thread is that the burden of evidence does not disappear when code is acquired rather than written; it simply changes form.

Open-source components deserve particular discipline, because their vulnerabilities become public the moment they are disclosed. A software bill of materials that lists every component and version, mapped continuously against vulnerability databases, is now the practical minimum, and the Cyber Resilience Act makes such component tracking an obligation for products placed on the European market. Supplier obligations flow the same way through the rest of the chain, as described under supply chain compliance.

Machine-learned components sit at the frontier of this problem. A trained model has no requirements specification in the traditional sense, no readable design, and no meaningful notion of structural coverage, so the existing standards cannot be applied to it directly. Sector-specific guidance is emerging, and the current state of that work is discussed under artificial intelligence and machine learning.

Sustaining Safety After Release

Certification is a snapshot; the safety argument has to survive every subsequent change. Each modification, whether a functional enhancement, a defect fix, or a security patch, begins with a change impact analysis that identifies which requirements, design elements, code units, and test cases the change touches. That analysis determines the scope of reverification. A change confined to one partition with a verified interface may require limited regression testing; a change to shared data structures or timing behavior may require the full verification suite to be rerun.

Configuration management makes that analysis possible. Every artifact carries a controlled identity, and the standards distinguish control categories so that the most safety-relevant items receive the strictest change control, traceability, and archival. The build must be reproducible from archived sources and tools years later, which is why certified programs archive their toolchains alongside their code. These practices connect directly to the wider quality management system.

Finally, the feedback loop from the field closes the lifecycle. In-service problem reporting, defect trending, and post-market surveillance reveal the failure modes that hazard analysis missed, and each one should feed back into requirements and verification. When a defect turns out to be safety-relevant, the response ranges from a service bulletin to a field update to a full product recall. The standards expect this loop to be a defined process, not an improvisation.

About This Category

Software and firmware safety addresses one of the most demanding areas of modern electronics engineering. Hardware safety can often be demonstrated by testing representative samples and applying statistical analysis; software safety requires building justified confidence that systematic defects have been avoided across an effectively infinite input space. Because that confidence cannot be measured directly, the standards construct it from process rigor, independent verification, and traceable evidence scaled to the integrity required. The practices collected here distill decades of experience from industries where software failures have cost lives and where disciplined processes were developed in response. They connect closely to risk management, which supplies the hazard analysis that defines what the software must do, and to testing and certification, which supplies the independent assessment that closes the argument.