F3 · Mission-Critical & Auto
Functional Safety: Containers & DDS
Overview
Starting from software-defined vehicle architecture, this article analyzes how containers, DDS/ROS 2 communication and the safety-island pattern separate safety-critical from non-safety-critical workloads. Its core argument is to limit fault propagation through explicit service interfaces, execution boundaries and communication paths — rather than equating container isolation with functional safety. Its ecosystem value is connecting automotive safety engineering, cloud-native deployment and open middleware into a discussable architecture framework for mixed-criticality prototypes on Arm.
Scope of verification
- The content focuses on the software-architecture relationship among containers, DDS/ROS 2 and the safety-island concept, offering interface and fault-boundary design direction; it does not specify full physical hardware validation.
- Software isolation is not hardware-enforced separation and does not constitute an ASIL claim or ISO 26262 certification; timing interference, failure injection, the safety case and target-ECU validation must still be completed independently.
Canonical source: https://developer.arm.com/community/arm-community-blogs/b/automotive-blog/posts/safe-scalable-automotive-systems-functional-safety-containers-dds
This page is a guided summary with boundary notes, not an official reproduction.
This page is a guided summary with boundary notes, not an official reproduction.