Open Sesame! Why Functional Safety is the Master Key to Open the Door for Linux into Automotive

### Overview Niko People from Bosch Engineering presents a vision and methodology for integrating Linux into core automotive systems, such as braking, steering, and powertrain, rather than leaving the domain exclusively to closed-source, microkernel-based commercial operating systems. The primary barrier to Linux adoption in these core environments is automotive functional safety compliance under ISO 26262. By adopting a system engineering and functional monitoring architecture, automotive developers can leverage Linux's computing power while meeting target Automotive Safety Integrity Levels (specifically targeting ASIL B as an entry point).

### Key Topics Automotive software has unique constraints, including a historically closed-source culture, strict licensing concerns (such as customer prohibitions against GPLv3), long product lifecycles (around 15 years), high cost sensitivity, recall liabilities, and rigid development processes mandated by ISO 26262. ISO 26262 evaluates hazards based on severity, exposure probability, and controllability, defining safety integrity levels from ASIL A through ASIL D. Emerging applications in vehicle-to-everything (V2X) communication and autonomous driving demand significant compute power and utilize POSIX-based communication stacks, making Linux a practical operating system choice.

### Technical Details Using an intelligent traffic light communicating with a vehicle via V2X (enabling adaptive cruise deceleration or 'Green Wave' coordination) as an example, the speaker details how embedded Linux on modern hardware (e.g., NXP i.MX 7) can achieve functional safety through a three-layer monitoring architecture:

1. **Level 1 (Functional Layer):** Executes core functionality, calculating traffic light phases, timing, and outbound V2X messages on the primary processor running Linux. Data flow integrity is supported using checksums, CRCs, or HMAC-style validation. 2. **Level 2 (Functional Monitoring):** Implements redundant and alternate data processing methods to catch calculation errors (bit flips, rounding errors, or overflows). For example, it recalculates CRCs using look-up tables rather than bit-shifting algorithms. Level 2 also monitors the system state machine against predefined forbidden states (such as green and red displayed simultaneously) and transitions the system to a safe state (e.g., yellow blinking light) upon detecting a violation. 3. **Level 3 (Deadline Monitoring & System Feedback):** Employs an independent, safety-relevant secondary microcontroller running a deterministic real-time operating system (RTOS) with a 10 ms scheduling pace. This entity acts as an external referee that verifies timing deadlines of the main processor and monitors direct hardware sensor feedback (such as physical power relay feedback from the traffic light) to ensure the physical signal matches the transmitted state. If deadlines or states diverge, it disengages the system and enforces the safe state.

### Takeaways & Open Challenges A three-layered monitoring concept abstracts the operating system's internal certification gaps by handling safety at the architectural system level. However, broader adoption requires addressing remaining industry challenges: standardizing certified Linux distributions (such as initiatives in the SIL2Linux/OSADL or AGL communities), designing complex closed-loop feedback behaviors across participants, managing junction-wide system states when vehicles fail to obey commands, and fostering automotive upstream collaboration with the open-source community.