Most writing on edge AI functional safety treats it as a model problem. Is the network deterministic, is it in distribution, is there a monitor that can overrule it? Those questions matter, and we answer them in functional safety and machine learning. But putting inference on an edge device next to a live process adds a second failure class back into the safety case. The silicon running the network can fail randomly, the model and its monitor often share that silicon, and the accelerator in the middle is usually certified to less than the rest of the chip.
This article covers that second half: what a hardware fault does to an inference, what the inference silicon is certified to, and where the monitor has to physically run for the integrity claim to hold.
Edge AI functional safety has two halves, and page one covers one
Functional safety is the part of overall safety that depends on the correct operation of electrical, electronic and programmable electronic components. The page that currently answers this query, Hyperion's guide to edge AI under ISO 26262, IEC 61508 and IEC 62443, sets out the accepted pattern: the ML component is advisory, a deterministic monitor is authoritative, and the monitor must itself be certified to the required ASIL or SIL. It also lists what determinism costs at the edge: fixed-point arithmetic, fixed thread affinity, no dynamic memory allocation during inference, and control loops often budgeted under 10 ms.
That is the systematic half: avoiding design faults in the model and the software. IEC 61508 has always had a second half, the control of random hardware failures, and it does not go away because the workload is a neural network. The IET's guidance on AI in functional safety is explicit that the hazard analysis must cover sources internal to the system that contains AI, including hardware failures, communication errors, operating system integrity and third-party libraries. On an edge device, every one of those lives on the same board as the model.
What a bit flip does to an inference
Most faults vanish, the rest are worse than model error
A soft error is a transient bit flip, usually caused by a high-energy particle strike. The intuitive objection is that a network that is already wrong a few percent of the time should not care about a rare flipped bit. Rahman, Laskar and Li tested that objection directly with fault injection on modern DNNs:
- On CIFAR-100, 98 to 99 percent of injected faults were masked. The remaining 1 to 2 percent produced silent data corruption (SDC), a wrong output with no error raised.
- Of those SDCs, about 37 percent on average were safety-critical misclassifications, meaning the wrong answer fell in a class group that matters for safety.
- The probability of a safety-critical misclassification from a transient fault was about 2.3 times (CIFAR-100) and 4.1 times (ImageNet) higher than from the model's own algorithmic inaccuracy.
- Higher-order bits in the tensors, and the first and last layers of the network, accounted for most of the dangerous outcomes.
The same paper notes that under ISO 26262 the SoC doing the inference in a self-driving car must keep its soft-error rate below 10 FIT (failures per billion device hours), and that an unprotected DNN accelerator alone could exceed that budget for the whole chip. A review of soft errors in DNN accelerators adds the second number an assessor will ask for: at ASIL D, a single-point fault metric of at least 99 percent.
Burst errors from corrupted weights
Fault injection is a model of reality. Beam testing is closer to it. In a neutron irradiation test of NN-based object detection on GPUs, 56 percent of the burst-mode errors repeated the same SDC, most likely from an upset in the stored model parameters. That matters for edge control: a corrupted weight does not produce one bad output, it produces the same bad output on every cycle until something reloads the model. A monitor that only checks the plausibility of each output in isolation can accept a consistently wrong one.
Why the accelerator is the weak block
The most useful public number on an embedded NPU comes from an RTL-level fault injection study of Arm's Ethos-U55. Across four MAC configurations and a range of networks, the SDC rate stayed below 0.1 x 10^-15 per inference. That satisfies ASIL B and ASIL C. It fails ASIL D, and the SDC rate rises with the size of the MAC array and on-chip SRAM.
Three findings from that study shape how an edge safety architecture should be built:
- Memory is not the problem you think it is. Storage structures are usually protected by error correction codes. The damaging faults land in flip-flops and combinational logic in the datapath, which ECC does not see.
- Hardening is expensive. Duplicating each functional block (DMR) brought the Ethos-U55 to ASIL D levels at roughly 2x area. Hardening every flip-flop cost about 60 percent extra area and still fell short.
- Logic faults are growing. With smaller nodes, lower voltages and faster clocks, transient glitches in combinational logic are no longer negligible, and ignoring them overstates reliability.
Chip makers are candid that the method is not finished either. An NXP and ONERA thesis proposal on integrating neural network IP with safety assurance lists the open questions for an NN block on an automotive SoC: what its random failures are, what failure modes they produce (which depend on the network loaded), what monitors can detect them, and what evidence can demonstrate a detection ratio. Those are the inputs to an FMEDA, and for neural accelerators they are still research questions.
What the inference silicon is actually certified to
Read vendor safety claims carefully, because most of them split three ways: the development process, the safety processor, and the AI compute.
NVIDIA's IGX Thor safety brief is a clean example. The development process for the SoC and its safety software is compliant up to ISO 26262 ASIL D and compatible up to IEC 61508 SIL 3 / SC 3. For random hardware failures, the Thor SoC meets ASIL B, compatible up to SIL 2, while the Functional Safety Island reaches SIL 3. The island is an independent, redundant set of processors with its own power rail and clocks, backed by a separate safety microcontroller on the carrier board, DRAM ECC, in-system test, and support for freedom from interference.
NPU IP follows the same logic. The MIPS ARC NPX6FS is offered as ASIL B or ASIL D Ready, with diagnostic error injection, windowed watchdogs, lockstep for safety-critical modules, and safety manuals with FMEDA and DFMEA reports, and it needs optional software test libraries to reach ASIL B. On the FPGA side, AMD's Versal AI Edge series pairs its AI engines with dual Cortex-R5F real-time cores, triple-redundant platform management and ECC, and is architected to meet IEC 61508 and ISO 26262.
The pattern across all three: the highest integrity claim sits with a small, deterministic processor next to the accelerator, not with the accelerator. That is the hardware mirror of the software rule that the model is advisory and the monitor is authoritative.
Freedom from interference when monitor and model share a chip
On a single edge SoC, the model, the operating system, the network stack and the monitor compete for the same caches, memory bus and clocks. The safety case has to show that a fault or overload in the non-safety part cannot delay or corrupt the safety part. That is freedom from interference.
Intel and SYSGO's IEC 61508 whitepaper shows the conventional answer for a robotic arm controller: an Atom x6000FE SoC running the PikeOS real-time operating system and hypervisor, with safety and non-safety workloads in separate partitions. For an AI workload the same partitioning applies, with two additions:
- The inference path must be made deterministic before timing can be bounded, by the measures Hyperion lists. Our edge AI deployment pipeline treats this as a release gate: golden outputs and tail latency measured on the target, not on the workstation.
- Compression changes the fault picture. Faults in high-order bits dominate the dangerous outcomes, and quantization changes the number format those bits belong to. A fault analysis done on the FP32 model does not carry over, so repeat it after every step in edge AI model compression.
Interference is also a security question. Hyperion places AI inference servers in IEC 62443 zone 3 and requires all traffic to the control zone to pass a conduit with authentication and integrity checks. An adversarial input is a deliberate fault, and a functional safety analysis alone will not surface it.
An edge architecture that can hold a SIL
Block by block: who carries which claim
Putting the pieces together gives an architecture where each block carries a claim it can actually support:
| Block | Runs on | What it must show |
|---|---|---|
| Learned model | NPU or GPU | Advisory only; evidence of performance in its operating domain |
| Safety monitor or filter | Safety island, lockstep core or separate MCU | Full SIL claim; bounded worst-case execution time |
| Platform separation | Hypervisor or hardware partitioning | Freedom from interference for timing, memory and power |
| Accelerator health | In-system test plus online test patterns | Detection of permanent faults within the process safety time |
| Fallback | Monitor plus actuators | Safe state reachable without the accelerator |
The monitor does not have to be crude. A control barrier function safety filter is small enough to run on a real-time core and still lets the learned controller act freely inside the safe set. In the closed-loop control stack Equation Labs validated on a 500 L pilot basin, the safety layer runs in under 2 ms, end-to-end edge latency came down from 1.2 s to 285 ms, and the campaign recorded zero safety violations across 400 simulated years. The timing split is the point: the part that holds the safety claim is two orders of magnitude faster than the loop it guards, so it can run on the slowest, most trustworthy core on the board.
Detecting a sick accelerator in the field
Permanent faults from ageing and latent defects accumulate over the life of the device. Periodic self-test is the standard answer, and it can be specialised for neural accelerators. Kundu and Basu ran software-based self-test with functional test patterns in mission mode and found that GAN-generated patterns improved detection coverage of functional safety violations by up to 130.28 percent compared with patterns selected from the dataset. The practical form: a known input with a known output, run on the NPU between control cycles, with the monitor dropping to fallback on a mismatch. Because of the burst behaviour above, the test should also catch corrupted weights, not just a broken datapath.
What is still not settled
Three gaps are worth stating plainly to anyone scoping an edge AI safety project:
- Most accelerator fault tolerance is still research. A 2026 PRISMA survey of fault-tolerant DNN accelerators finds most detection and recovery schemes at TRL 3 to 4, and few that provide the certification evidence an assessor needs, such as deterministic WCET and system-level safety validation.
- SDC has no agreed definition for generative models. The Ethos-U55 authors define it as a top-1 label mismatch for classifiers and say the definition for LLMs and generative tasks is an open question. A controller that outputs continuous actions needs its own definition, written in terms of the process.
- The standards are still moving. NVIDIA's brief already points integrators at ISO/IEC TS 22440 alongside IEC 61508 and ISO 13849. How the edition 3 drafts treat AI is covered in IEC 61508 and machine learning, and where these hardware activities sit in the overall functional safety life cycle is a topic of its own.
The working rule until then: certify the monitor and the platform, treat the accelerator as a component that will fail, and design so that when it does, the process notices before the operator does.
FAQ
Can a neural processing unit be certified to SIL 3?
Not on random hardware integrity, in current vendor claims. The development process is commonly certified to ASIL D or SIL 3, but the AI compute is typically rated ASIL B or SIL 2, with SIL 3 reserved for an independent safety island next to it. Design so the SIL 3 function runs on the island.
Do soft errors matter if the model is already imperfect?
Yes. Fault injection results show safety-critical misclassifications from transient hardware faults are roughly 2 to 4 times more likely than from the model's own errors. The dangerous faults cluster in high-order bits and in the first and last layers of the network.
Does ECC on memory protect edge AI inference?
Only partly. ECC covers storage arrays, but the most damaging soft errors in an NPU land in flip-flops and combinational logic in the datapath, which ECC does not cover. Those need redundancy, hardening or runtime testing.
Is cybersecurity part of edge AI functional safety?
It is a separate discipline under IEC 62443, but an industrial AI system needs both. Functional safety asks whether the system fails safely; IEC 62443 asks whether it is protected from attack. Adversarial inputs are where the two overlap.