Auto safety_JA to review

content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md

@@ -0,0 +1,25 @@
+---
+title: Why functional safety matters in software systems 
+weight: 2
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## What functional safety means for developers
+
+Functional safety helps systems detect faults and respond in ways that keep people and equipment safe. It ensures that even when errors occur, the system transitions into a known, safe state to prevent harm.
+
+This concept is foundational in domains like automotive, autonomous driving, medical devices, industrial control, robotics, and aerospace. In these systems, failures can have severe real-world consequences.
+
+In software development, functional safety focuses on minimizing risks through careful design, rigorous testing, and thorough validation. The goal is to make sure that critical systems behave predictably, reliably, and verifiably, even under fault conditions.
+
+To design for functional safety, developers must consider:
+
+- Error detection mechanisms  
+- Exception handling strategies  
+- Redundant system design  
+- Development processes that align with safety standards
+
+
+In the following sections, you'll learn how to apply these principles throughout the software lifecycle, from early risk assessment and architectural design to runtime isolation and ISO 26262 compliance.

content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md

@@ -0,0 +1,39 @@
+---
+title: Understand functional safety risks
+weight: 3
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Manage risk with functional safety principles
+
+At its core, functional safety is about managing risk and reducing the impact of system failures.
+
+In autonomous vehicles, for example, functional safety ensures that if sensors produce unreliable or conflicting input, the vehicle can fall back to a known-safe state and maintain control.
+
+The three core objectives of functional safety are:
+
+- **Prevention** reduces the likelihood of errors through rigorous software development processes and testing. For example, electric vehicles monitor battery temperature to prevent overheating.
+- **Detection** quickly identifies errors using built-in diagnostic mechanisms, such as self-test routines.
+- **Mitigation** controls the impact of failures to ensure the system stays safe, even when something goes wrong.
+
+In practice, these principles might be implemented through:
+
+- Redundant sensor fusion code paths
+- Timeout mechanisms for control loops
+- Watchdog timers that reset components on fault detection
+- Safe-state logic embedded in actuator control routines
+
+Together, prevention, detection, and mitigation form the foundation for building safer, more reliable software systems.
+
+In the next step, you’ll explore how functional safety principles are formalized through safety standards like ISO 26262 and applied to real-world systems.
+
+
+
+
+
+
+
+
+

content/learning-paths/automotive/openadkit2_safetyisolation/1c_iso26262.md

@@ -0,0 +1,39 @@
+---
+title: Apply ISO 26262 and ASIL levels
+weight: 4
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+## What ISO 26262 and ASIL levels mean for developers
+
+ISO 26262 is a functional safety standard for automotive electronics and software systems. It defines a structured safety lifecycle aligned with the V-model, spanning everything from initial requirements to final validation and maintenance.
+
+The V-model is a development framework where each design phase is paired with a corresponding test phase. This structure makes it easier to trace safety requirements from early specifications through to system verification.
+
+## Key concepts in ISO 26262
+
+- **Automotive Safety Integrity Level (ASIL)** ranks the safety criticality of components on a scale from A (lowest) to D (highest). For example, ASIL A might apply to a dashboard indicator failure, while ASIL D applies to a brake system malfunction.
+
+- **Hazard Analysis and Risk Assessment (HARA)** identifies potential hazards and evaluates their risks to define the required safety goals and ASIL levels.
+
+- **Safety mechanisms** include techniques such as real-time fault detection, redundancy, and fallback modes like fail-safe and fail-operational behavior.
+
+{{% notice Note %}}In practice, many OEMs default to ASIL D for systems with any potential for passenger harm, even if the statistical likelihood of failure is low.{{% /notice %}}
+
+## Apply ISO 26262 to real-world systems
+
+ISO 26262 applies to many safety-critical vehicle systems:
+
+- **Autonomous driving systems** must respond safely to sensor errors (such as LiDAR, radar, or camera faults). Functional safety ensures the vehicle can enter a safe state and avoid unsafe decisions.
+
+- **Powertrain control** systems monitor throttle and braking inputs. Safety mechanisms such as redundancy, plausibility checks, and overrides prevent unintended acceleration or loss of braking function. 
+
+- **Battery management systems (BMS)** protect electric vehicle batteries from overheating, overcharging, or deep discharge. Built-in safety functions monitor temperature, balance voltage, and isolate faulty circuits to prevent thermal runaway.
+
+These systems require dedicated hardware and software architectures that enforce functional safety guarantees. One common solution is the *safety island*, which is an isolated compute domain used to run safety-critical control logic independently from the main system.
+
+
+
+
+

content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md

@@ -0,0 +1,51 @@
+---
+title: Implement safety-critical isolation using safety island architecture
+weight: 5
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+## How safety islands support functional safety
+
+In automotive systems, a non-safety ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation. A safety island, by contrast, is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism.
+
+The table below compares the characteristics of an ECU and a safety island in terms of their role in supporting functional safety.
+
+| Feature               | ECU                | Safety island                        |
+|------------------------|----------------------------|--------------------------------------|
+| Purpose               | Comfort/non-safety logic | Safety-critical decision making      |
+| OS/runtime            | Linux, Android             | RTOS, hypervisor, or bare-metal      |
+| Isolation             | Soft partitioning          | Hardware-enforced isolation   |
+| Functional safety requirement | None to moderate           | ISO 26262 ASIL-B to ASIL-D compliant |
+| Fault handling        | Best-effort recovery       | Deterministic safe-state response    |
+
+This comparison shows why safety-critical software depends on dedicated hardware domains to meet functional safety goals.
+
+If the main processor fails or becomes inoperable, a safety island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures.
+
+{{% notice Tip %}}
+Safety islands are often implemented as lockstep cores or separate MCUs that run on real-time operating systems (RTOS), offering guaranteed performance under fault conditions.
+{{% /notice %}}
+
+## Key capabilities of a safety island
+- **System health monitoring** continuously monitors the operational status of the main processor (for example, the ADAS control unit) and detects potential errors or anomalies
+- **Fault detection and isolation** independently detects failures and initiates emergency handling for overheating, execution faults, or unresponsiveness
+- **Essential safety functions conitnue to operate**, even if the main system crashes. A safety island can execute fallback operations, such as:
+   - Autonomous Vehicles → safe stopping (fail-safe mode)
+   - Industrial Equipment → emergency power cutoff or speed reduction
+
+## Why a safety island matters for functional safety
+
+A safety island provides a dedicated environment for executing critical safety functions. Its key characteristics include:
+
+- **Acting as an independent redundant safety layer**  
+   - Operates safety logic independently of the main processor
+
+- **Supporting the ASIL-D safety level**  
+   - Enables the system to meet the highest ISO 26262 requirements for critical operations
+
+- **Providing independent fault detection and recovery mechanisms:**  
+  - *Fail-safe*: activating a minimal-risk mode, such as limiting vehicle speed or switching to manual control 
+  - *Fail-operational*: allowing high-integrity systems, such as those in aerospace or autonomous driving, to continue functioning under fault conditions
+
+Safety islands play a key role in enabling ISO 26262 compliance by isolating safety-critical logic from general-purpose processing. They're a proven solution for improving system determinism, fault tolerance, and fallback behavior.

content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement_functional_safety.md

@@ -0,0 +1,35 @@
+---
+title: Functional safety for automotive software development
+weight: 6
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## The software development lifecycle
+
+Functional safety affects both hardware and software development, particularly in areas such as requirement changes, version control, and test validation. For example, in ASIL-D level applications, every code change must go through a full impact analysis and regression testing to ensure it doesn't introduce new risks.
+
+## Software development practices for functional safety
+
+These practices ensure that software meets industry standards and can withstand system-level failures:
+- **Defining requirements clearly**  
+  - Specifying safety-critical requirements and conduct formal risk assessments.
+
+- **Following safety-oriented programming standards**  
+  - Using MISRA C or CERT C/C++ and static analysis tools to detect unsafe behavior.
+
+- **Implementing fault-handling mechanisms**  
+  - Using redundancy, health monitoring, and fail-safe logic to manage faults gracefully.
+
+- **Testing and verifying rigorously**  
+  - Using Hardware-in-the-Loop (HIL) testing to validate behavior under realistic conditions.
+
+- **Tracking changes with version control and audits**  
+  - Using tools like Git, JIRA, or Polarion to manage revisions and maintain traceability for audits.
+
+- **Building an ASIL-partitioned development environment and adopting SOAFEE technologies** to help improve software maintainability and ensure consistent compliance with functional safety standards.
+
+{{% notice Note %}}
+This Learning Path builds on [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/). It introduces functional safety practices from the earliest stages of software development.
+{{% /notice %}}