systems engineering//functional safety

Functional safety is the part of a system's safety that depends on its control functions working correctly, and the body of standards that says how much evidence a safety-related function must carry before anyone may rely on it; it is used to design, verify and certify the electronics and software that stand between a machine and an accident, from a press's light curtain to a car's braking controller to an aircraft's flight software. The framework is the same in every sector. Analyse the hazards, estimate each one's risk as probability times severity, assign the function that reduces it an integrity level, and demand techniques and evidence that grow with that level.

Functional safety is the part of a system's safety that depends on its control functions working correctly, and the body of standards that says how much evidence a safety-related function must carry before anyone may rely on it; it is used to design, verify and certify the electronics and software that stand between a machine and an accident, from a press's light curtain to a car's braking controller to an aircraft's flight software. The framework is the same in every sector. Analyse the hazards, estimate each one's risk as probability times severity, assign the function that reduces it an integrity level, and demand techniques and evidence that grow with that level.

The integrity levels go by different names. The generic IEC 61508 uses safety integrity levels, SIL 1 to 4; road vehicles under ISO 26262 use ASIL A to D; airborne software under DO-178C uses DAL A to E (A the strictest); machinery under ISO 13849 uses performance levels a to e. At the top of each scale the standard requires independent verification, formal traceability, structural coverage and documented failure analysis; at the bottom, good engineering practice. Note the clash of names: SIL here means safety integrity level, while in testing it means software-in-the-loop.

Safety and security are two different protections, and they meet in a cyber-physical system. Functional safety protects the world from the machine (IEC 61508); cybersecurity protects the machine from people (IEC 62443 in industrial automation, with its own security levels SL 1 to 4). An attack can end as a physical accident, which is why safety cases for connected plants now have to consider deliberate as well as random faults (cyber-physical security).

The process starts before the requirements, with hazard analysis, and ends with a safety case: an argument, with evidence, that the residual risk is acceptable. The lifecycle is the V-model with safety activities attached at each level.

Architecture carries much of the burden. Separating the safety function from the control function (a safety instrumented system wired apart, an independent watchdog timer) lets the complex part stay at a low integrity level while a small, simple part carries the high one, a cheaper path than certifying everything to the top.

The standards assume behaviour can be specified, traced to code and verified piece by piece, which certifying learned components breaks: no requirement says what a neuron implements, and 99 % accuracy is not a safety argument, since the question is what happens in the other 1 % and how it is contained. A network as sole owner of a critical function remains exceptional; the usual route is a verified monitor and fallback around it (Simplex architecture). Regulators publish guidance for learned components (EASA in aviation, the EU AI Act for high-risk systems), and the ground moves every year.

SOTIF covers the gap the classic standards leave: hazards with no fault at all, such as a perception system that misreads a situation nobody foresaw.

Functional safety is a member of systems engineering; fail-safe design is its everyday tool.