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.
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.
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.