What is functional safety?
Safety is not determined by the RTOS alone. This guide sets out how to design for safety across the whole software stack — RTOS, drivers and middleware — together with SIL/ASIL, the standards, and how to think about failures.
What is functional safety?
Functional safety is a safety measure that reduces risk to a tolerable level through additional functions such as monitoring and protective devices. IEC 61508 defines it as safety that depends on the correct functioning of electrical, electronic, and programmable electronic (E/E/PE) safety-related systems.
It is contrasted with inherent safety (removing the hazard itself). At a railroad crossing, for example, replacing the crossing with an overpass is inherent safety, while installing warning signals and crossing gates is functional safety. Even if the possibility of an accident cannot be reduced to zero, the idea is to lower the danger to a tolerable level through the action of functions and devices.
Because monitoring and protective functions can themselves fail, the whole life cycle requires controlling failures so that risk stays low when they occur (fail-safe), preventing faults and bugs from entering hardware and software, and being able to demonstrate this to third parties through documentation, assessment, and audit (functional safety management).
Three steps of risk reduction
After hazard identification → risk estimation → risk evaluation, intolerable risk is reduced using the following steps.
Safety integrity level
Safety integrity is the probability that a safety-related system performs the specified safety function under stated conditions within a stated period. Each standard defines its own levels.
| Standard | Safety integrity measure | Highest |
|---|---|---|
| IEC 61508 | SIL 1–4 (Safety Integrity Level) | SIL 4 |
| ISO 26262 (automotive) | ASIL A–D (Automotive SIL) | ASIL D |
| EN 50128 (railway) | SIL 0〜4 | SIL 4 |
| IEC 62304 (medical) | Class A / B / C | Class C |
A safety function is a function that achieves or maintains a safe state with respect to a specific hazardous event — for example, a pre-crash system or an airbag. ISO 26262 uses the term “safety mechanism.”
Failure types and fault assumptions
| Category | Description | Example countermeasures |
|---|---|---|
| Random hardware failure | Random failures due to aging and wear of components | High-reliability parts, diagnostics, redundancy |
| Systematic failure | Systematic failures caused by design, specification or implementation (e.g., bugs) | Process control, verification, certification |
| Soft error | Memory corruption caused by neutron radiation, electromagnetic waves, etc. | ECC, redundancy, re-execution |
Fault multiplicity: IEC 61508 addresses single faults. The machinery safety standard ISO 13849 and the automotive standard ISO 26262 consider up to double faults, and in railways some cases consider up to triple faults. Design also takes into account electromagnetic compatibility (EMC), reasonably foreseeable misuse, and unexpected start/stop.
Characteristics of safety-critical systems
Domains where a fault or failure can cause catastrophic harm such as loss of life, serious injury or environmental damage. Absolute reliability is required.
Main fields: transportation (flight control, railway signaling, automotive braking and autonomous driving), medical devices (ventilators, pacemakers, radiotherapy), energy (nuclear control, chemical-plant emergency shutdown), and defense.
Functional safety across the software stack (RTOS, drivers, middleware)
Functional safety is not achieved simply by using a safety RTOS. A safety function is realized across the whole software stack: application → middleware → drivers → hardware. Every path that safety-related processing passes through must have development, verification and evidence matching the target integrity level (SIL/ASIL).
① RTOS (kernel)
Provides task scheduling and freedom from interference through the MPU/MMU, isolating non-safety tasks so they cannot encroach on the memory and timing resources of safety tasks. But even with a safe kernel, the safety function does not hold if the drivers and middleware running on it are not safe.
② Drivers (device drivers / BSP)
The layer closest to the hardware. It handles validity checks on sensor and ADC inputs (range/plausibility), communication CRCs, start-up and run-time self-tests (CPU, RAM, ROM/flash), and interrupt-latency management. Because a driver defect can corrupt safety data directly even on a safe kernel, drivers must be developed and verified to the same integrity level as the kernel.
③ Middleware (communication stacks, protocols etc.)
Automotive and industrial networks (CAN / CAN FD / LIN / FlexRay / Automotive Ethernet / CANopen / J1939) carry safety-related signals. Using end-to-end (E2E) protection (AUTOSAR E2E) and the black-channel principle (IEC 61784-3 / PROFIsafe etc.), CRCs, sequence counters and timeouts guarantee data integrity along the whole path. The standard approach is that even if the channel itself is not safe (a black channel), safety layers at both ends protect it. File systems, USB, TCP/IP and GUIs also need appropriate development rigor if they lie on the path of a safety function.
④ Security (integral with safety)
Tampering and spoofing affect safety, so security and functional safety are designed together — secure boot, signature verification, TLS and so on (security-informed safety).
Summary: safety RTOS (isolation, scheduling) + safe drivers (hardware diagnostics, self-tests) + safe communication middleware (E2E / black channel). Only when all three layers match the integrity level can functional safety be claimed for the system. We support the entire system with products for each layer and with contract development for integration and verification.
Main functional safety standards
| Standard | Domain |
|---|---|
| IEC 61508 | Functional safety of E/E/PE systems (basic standard, parent of all domains) |
| ISO 26262 | Automotive (vehicle E/E systems) |
| IEC 62061 / ISO 13849 | Functional safety of machinery |
| IEC 62278 / EN 50128 | Railway (RAMS / software) |
| IEC 61513 | Nuclear |
| IEC 62304 | Medical device software |
| DO-178C | Aviation (airborne software) |
| ISO 15998 / IEC 60335 | Earth-moving machinery / household appliances |
Compliance generally uses a gap assessment: identify the differences between the standard's requirements and your own procedures and development evidence, and close them.
Products we carry for functional safety
We offer pre-certified safety RTOSes, certified compilers, timing analysis, multicore safety debugging, and more.