Across every industrial sector — rail, energy, manufacturing, medical, aerospace, automotive — critical systems are facing rapid change: growing functional complexity, the need for agility, cybersecurity imperatives, regulatory pressure and ever-shorter innovation cycles. In response, one approach is steadily gaining ground: software-defined safety (SDS). This architecture makes it possible to reconcile functional safety, software flexibility, cybersecurity and lower maintenance costs.
This article explores the paradigm in three parts, followed by a look at ISIT-Neperis’s safety and non-safety communication stacks.
Software-defined safety: moving beyond all-hardware
Historically, functional safety relied on dedicated, certified, fixed hardware. This approach delivers robustness and predictability — but it has one major drawback: hardware doesn’t adapt. In a world where requirements change faster than industrial cycles, that rigidity becomes a bottleneck.
The problem: systems that are too rigid
- Any functional change often requires a hardware modification, making improvements costly, slow and hard to deploy.
- Certified safety devices are rarely upgradable, because every significant change forces a heavy re-certification, holding back innovation and updates.
- The rise of cyber threats calls for more frequent updates, but traditional, rigid and barely modular architectures cope poorly with this need for regular updating.
The answer: making safety programmable
Software-defined safety means transferring to software — rather than hardware — the responsibility for executing, isolating and orchestrating safety functions. This makes it possible to build a system that is flexible, adaptable and certifiable over time.
This is not about downplaying hardware — on the contrary, it remains the robust, deterministic foundation on which everything rests. Software, meanwhile, becomes the engine of dynamic compliance, reconfigurability and the continuous updating of safety and security mechanisms.
A hybrid architecture: a hypervisor + a Safety OS + a non-Safety OS
At the heart of software-defined safety is a modern architecture model built on three pillars: shared hardware, a certifiable hypervisor, and two separate execution environments that can still cooperate.
One piece of hardware, shared across criticality levels
A single SoC/CPU runs simultaneously:
- Safety functions (hard real-time, functional safety);
- Non-safety functions (GUI, connectivity, analytics, maintenance, embedded AI, and so on).
This pooling reduces cost, power consumption and hardware complexity, while simplifying platform maintenance and evolution.
A certifiable hypervisor: the cornerstone
The hypervisor plays a central role in the SDS architecture. It provides:
- Strict isolation between safety and non-safety partitions;
- Parallel execution of several operating systems;
- Deterministic resource allocation (CPU, memory, timers, and so on);
- A reduced certification scope;
- Better resilience against attacks and faults.
Thanks to a minimal, stable, certifiable microkernel, it guarantees that critical and non-critical environments coexist without interference.
Two separate operating systems — designed to cooperate
| Environment | Role | Benefits |
|---|---|---|
| Safety OS | Runs critical functions (IEC 61508, ISO 26262, EN 50128, DO-178, etc.) | Determinism, certification, stability |
| Non-safety OS | Hosts evolving application functions (UI, connectivity, embedded AI, etc.) | Agility, frequent updates, innovation |
This functional separation makes it possible to innovate quickly on non-critical services while preserving the integrity, compliance and stability of the safety functions.
Flexibility and cybersecurity: the winning duo of SDS architectures
Manufacturers now operate in an environment where they must:
- apply regular security updates (patching);
- comply with modern regulatory requirements (NIS2, automotive R155/R156, IACS directives, and more);
- protect critical infrastructure that is increasingly exposed to attack.
A system designed for continuous updates
Separating safety from non-safety paves the way for smoother software maintenance:
- the non-safety OS can be updated frequently without affecting the certified scope;
- the safety OS stays stable, with controlled, less frequent validation cycles;
- the hypervisor guarantees the integrity of the whole by isolating updates from the rest of the system.
The result: shorter maintenance cycles, improved time-to-market and far greater capacity to evolve than traditional architectures.
Cybersecurity reinforced by the architecture
Software-defined safety directly improves the level of cybersecurity:
- clear isolation of application domains;
- reduced attack surface;
- faster patch deployment;
- stronger software segmentation;
- compatibility with embedded Zero Trust approaches.
The SDS architecture therefore answers a major imperative: securing industrial systems that are now connected and heavily regulated, while maintaining a high level of functional safety.
Safety communication built into an SDS approach
In a software-defined safety architecture, critical communication must also be delivered as certifiable software building blocks. ISIT-Neperis’s Safety stacks — CANopen Safety, SIL3-certifiable CANopen Safety, FSoE (Safety over EtherCAT) and certifiable J1939 Safety — fit directly into this model, offering modular, portable solutions built without third-party code, suitable for any processor, OS or even bare-metal environment.
Some of these stacks are available in pre-certified or certifiable versions up to SIL3, such as the certifiable CANopen Safety stack — unique on the market — or the FSoE stack, compliant with IEC 61784-3-12 and usable in Master or Slave (MainInstance/SubInstance) mode.
In the SDS model, these stacks naturally sit in the Safety OS partition, where they handle critical exchanges, while the hypervisor guarantees their isolation and integrity. They contribute to a coherent, robust architecture:
- certifiable Safety communication;
- a better-controlled safety perimeter;
- simplified integration with existing Safety functions.
ISIT-Neperis’s stacks therefore complement the software-defined safety approach effectively, providing reliable, certifiable Safety communication components perfectly aligned with the requirements of modern industrial systems. Explore the ISIT-Neperis communication stacks →
Conclusion
Software-defined safety is a major step forward in the design of critical industrial systems. By combining a hypervisor, a Safety OS and a non-Safety OS on a single hardware platform, this approach brings together:
- controlled functional safety;
- software flexibility that lets you adapt the system without redesigning the hardware;
- continuous innovation through an upgradable non-safety OS;
- simplified updates, including security patches;
- native reinforcement of cybersecurity through isolation and segmentation.
With its modular, certifiable Safety and non-Safety communication stacks designed for modern architectures, ISIT-Neperis helps manufacturers take full advantage of SDS by providing reliable, integrable software building blocks ready to support their transition toward safer, more open and more sustainable systems.
Talk to our team about integrating certifiable Safety communication into your SDS platform.
Adapted and translated into English from the ISIT article “Software-Defined Safety : la révolution logicielle de la sûreté dans l’industrie” (isit.fr).