Prototype safety-critical isolation for autonomous driving systems on Neoverse
Introduction
Why functional safety matters in software systems
Understand functional safety risks
Apply ISO 26262 and ASIL levels
Implement safety-critical isolation using safety island architecture
Functional safety for automotive software development
How to use Data Distribution Service (DDS)
Deploy OpenAD Kit across multiple cloud instances
Run OpenAD Kit across distributed ROS 2 instances
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  1 hr
Last updated:  26 Jun 2026
Skill level:
  Advanced
Reading time:
  1 hr
Last updated:
  26 Jun 2026
Authors:Odin Shen, Arm
Julien Jayat, Arm
Arm IP:Neoverse
Tags: Containers and Virtualization Linux Python Docker ROS 2 DDS
Authors:
  • Odin Shen, Arm
  • Julien Jayat, Arm
Arm IP:
Neoverse
Tags:
Containers and Virtualization Linux Python Docker ROS 2 DDS

Who is this for?

This Learning Path is for automotive engineers developing safety-critical systems. You'll learn how to accelerate ISO 26262-compliant development workflows using Arm-based cloud compute, containerized simulation, and DDS-based communication.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Apply functional safety principles, including risk prevention, fault detection, and ASIL compliance, to build robust, certifiable automotive systems
  • Use DDS and a publish-subscribe architecture for low-latency, scalable, and fault-tolerant communication in autonomous driving systems
  • Implement distributed development by separating the simulation platform into independent, safety-isolated components

Prerequisites

Before starting, you will need the following:

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll learn about prototyping safety‑critical isolation for autonomous driving workloads on Arm Neoverse by applying functional safety concepts, ISO 26262 and ASIL guidance, and a safety‑island architecture. First, you’ll understand how to separate safety‑critical control logic from non‑safety functions. Then, you’ll connect components using a publish‑subscribe model (DDS/ROS 2) within containerized deployments or across Arm‑based instances. You’ll explore lifecycle practices aligned with the V‑model, including clear requirements, version control, impact analysis, and regression testing. By the end, you’ll organize simulation components into isolated units with defined interfaces and documentation suitable for advancing ISO 26262‑oriented development on Arm Neoverse.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
How do I decide which components belong on the safety island versus the general ECU?
Place time‑critical, safety‑relevant control logic (for example, braking or steering) on the safety island, and keep non‑critical features (such as infotainment) on the general ECU. The goal is strong isolation, determinism, and minimized coupling for safety‑critical paths.
What should I verify to confirm the isolation boundaries are defined correctly?
Check that safety‑critical components run independently from non‑critical services and communicate only through defined publish‑subscribe interfaces. Ensure data exchanged is minimal and purpose‑specific so that safety logic is not impacted by unrelated functions.
How do ISO 26262 ASIL levels influence my development workflow in this prototype?
Higher ASIL targets require more rigorous processes and evidence across the V‑model. For example, ASIL‑D changes go through full impact analysis and regression testing to prevent introducing new risks.
Should I separate components using containers on one host or across multiple Arm Neoverse instances?
Both approaches support prototyping: containers model software isolation on one system, while multiple instances model stronger physical separation. Choose the option that best matches the isolation assumptions you want to evaluate.
What artifacts should I capture to support ISO 26262 traceability in this prototype?
Maintain clear safety requirements, rationale for the safety‑island split, defined DDS/ROS 2 interfaces, and mapped tests to requirements. Record versioned changes, impact analyses, and verification results aligned to the V‑model stages.
Next