Add 2nd automotive SOAFEE learning path

Author: odincodeshen

content/learning-paths/automotive/openadkit2_virtualplatform/patches/1_functional_safety.md

@@ -0,0 +1,126 @@
+---
+title: Functional Safety for automotive software development
+weight: 2
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## What is Functional Safety?
+
+[Functional Safety](https://en.wikipedia.org/wiki/Functional_safety) refers to a system's ability to detect potential faults and respond appropriately to ensure that the system remains in a safe state, preventing harm to individuals or damage to equipment. 
+
+This is particularly important in **automotive, autonomous driving, medical devices, industrial control, robotics and aerospace** applications, where system failures can lead to severe consequences.
+
+In software development, Functional Safety focuses on minimizing risks through **software design, testing, and validation** to ensure that critical systems operate in a predictable, reliable, and verifiable manner. This means developers must consider:
+- **Error detection mechanisms**
+- **Exception handling**
+- **Redundancy design**
+- **Development processes compliant with safety standards**
+
+### Definition and Importance of Functional Safety
+
+The core of Functional Safety lies in **risk management**, which aims to reduce the impact of system failures.
+
+In autonomous vehicles, Functional Safety ensures that if sensor data is incorrect, the system can enter a **safe state**, preventing incorrect driving decisions.
+
+Three of core objectives of Functional Safety are:
+1. **Prevention**  
+   - Reducing the likelihood of errors through rigorous software development processes and testing. In the electric vehicle, the battery systems monitor temperature to prevent overheating.
+2. **Detection**  
+   - Quickly identifying errors using built-in diagnostic mechanisms (e.g., Built-in Self-Test, BIST). 
+3. **Mitigation**  
+   - Controlling the impact of failures to ensure the overall safety of the system.
+
+This approach is critical in applications such as **autonomous driving, flight control, and medical implants**, where failures can result in **severe consequences**.
+
+### ISO 26262 Standard and Applications
+
+[ISO 26262](https://www.iso.org/standard/68383.html) is a functional safety standard specifically for **automotive electronics and software systems**. It defines a comprehensive safety lifecycle, covering all phases from **requirement analysis, design, development, testing, to maintenance**.
+
+Key Concepts of ISO 26262:
+- **ASIL (Automotive Safety Integrity Level)**  
+  - Evaluates the risk level of different system components (A, B, C, D, where **D represents the highest safety requirement**). 
+  - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk).
+  https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level
+- **HARA (Hazard Analysis and Risk Assessment)**  
+  - Analyzes hazards and assesses risks to determine necessary safety measures.
+- **Safety Mechanisms**  
+  - Includes error detection, fault tolerance, and fail-safe modes to ensure safe operation.
+
+List some of typical application scenarios:
+- **Autonomous Driving Systems**: 
+  - Ensures that even if sensors (e.g., LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions.
+- **Powertrain Control**: 
+  - Prevents braking system failures that could lead to loss of control.
+- **Battery Management System (BMS)**: 
+  - Prevents battery overheating or excessive discharge in electric vehicles.
+
+For more details, you can check this video: [What is Functional Safety?](https://www.youtube.com/watch?v=R0CPzfYHdpQ)
+
+
+### Safety Island
+
+In automotive systems, a **General ECU (Electronic Control Unit)** typically runs non-critical tasks such as infotainment or navigation, whereas a **Safety Island** is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism.
+
+| Feature               | General ECU                | Safety Island                        |
+|------------------------|----------------------------|--------------------------------------|
+| Purpose               | Comfort / non-safety logic | Safety-critical decision making      |
+| OS/Runtime            | Linux, Android             | RTOS, Hypervisor, or bare-metal      |
+| Isolation             | Soft partitioning          | Hard isolation (hardware-enforced)   |
+| Functional Safety Req | None to moderate           | ISO 26262 ASIL-B to ASIL-D compliant |
+| Fault Handling        | Best-effort recovery       | Deterministic safe-state response    |
+
+This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior.
+
+**Safety Island** is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as **deceleration, stopping, and fault handling** to prevent catastrophic system failures.
+
+Key Functions of Safety Island
+- **Monitoring System Health**  
+   - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies.
+- **Fault Detection and Isolation**  
+   - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness.
+- **Providing Essential Safety Functions**  
+   - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as:
+   - Autonomous Vehicles → Safe stopping (Fail-Safe Mode)
+   - Industrial Equipment → Emergency power cutoff or speed reduction
+
+
+
+
+### Integration of Safety Island and Functional Safety
+
+Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures.
+
+How Safety Island Enhances Functional Safety
+1. **Acts as an Independent Redundant Safety Layer**  
+   - Even if the main system fails, it can still operate independently.
+2. **Supports ASIL-D Safety Level**  
+   - Monitors ECU health status and executes emergency safety strategies (e.g., emergency braking).
+3. **Provides Independent Fault Detection and Recovery Mechanisms**  
+   - **Fail-Safe**: Activates a **safe mode**, such as limiting vehicle speed or switching to manual control.
+   - **Fail-Operational**: Ensures that high-safety applications (e.g., aerospace systems) can continue operating under certain conditions.
+
+For more insights on **Arm's Functional Safety solutions**, you can refer to: [Arm Functional Safety Compute Blog](https://community.arm.com/arm-community-blogs/b/automotive-blog/posts/functional-safety-compute)
+
+
+### Impact of Functional Safety on Software Development Processes
+
+Functional Safety impacts **both hardware and software development**, particularly in areas such as requirement changes, version management, and testing validation.  
+For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks.
+
+List the Functional Safety Requirements in Software Development:
+- **Requirement Specification**  
+   - Clearly defining **safety-critical requirements** and conducting risk assessments.
+- **Safety-Oriented Programming**  
+   - Following **MISRA C, CERT C/C++ standards** and using static analysis tools to detect errors.
+- **Fault Handling Mechanisms**  
+   - Implementing **redundancy design and health monitoring** to handle anomalies.
+- **Testing and Verification**  
+   - Using **Hardware-in-the-Loop (HIL)** testing to ensure software safety in real hardware environments.
+- **Version Management and Change Control**  
+   - Using **Git, JIRA, Polarion** to track changes for safety audits.
+
+This learning path builds on the previous [learning path](https://learn.arm.com/learning-paths/automotive/openadkit1_container) and introduces how to incorporate Functional Safety design processes in the early stages of automotive software development.
+By establishing an ASIL Partitioning software development environment and leveraging [**SOAFEE**](https://www.soafee.io/) technologies, developers can enhance software consistency and maintainability in Functional Safety applications.
+

content/learning-paths/automotive/openadkit2_virtualplatform/patches/2_DataDistributionService.md

@@ -0,0 +1,65 @@
+---
+title: How to use Data Distribution Service (DDS)
+weight: 3
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+### Introduction to DDS
+Data Distribution Service (DDS) is a real-time, high-performance middleware designed for distributed systems, particularly in automotive software development for autonomous driving and advanced driver assistance systems (ADAS). Its decentralized architecture provides scalable, low-latency, and reliable data exchange, making it an essential component in managing high-frequency sensor data.
+
+In modern vehicles, multiple sensors, such as LiDAR, radar, and cameras, must communicate efficiently with computing modules and decision-making units. DDS enables seamless data transmission within the vehicle, ensuring that perception, localization, and control systems receive the necessary data with minimal delay. Additionally, it plays a crucial role in vehicle-to-infrastructure (V2X) communication, allowing vehicles to exchange information with traffic signals, road sensors, and other connected systems to enhance situational awareness and safety.
+
+
+### Why Automotive Software Needs DDS
+Modern automotive software architectures, such as SOAFEE, require deterministic data communication to ensure real-time coordination between sensors, ECUs, and computing modules. Traditional client-server communication models often introduce latency and bottlenecks, whereas DDS provides a direct, decentralized solution that enhances reliability and scalability.
+
+A key advantage of DDS is its ability to enable direct data exchange between system components without relying on a central server. This reduces the risk of a single point of failure and minimizes delays, which is crucial for autonomous driving applications where milliseconds can make a difference. For example, a LiDAR sensor publishing obstacle detection data can simultaneously send information to multiple subscribers, including perception, SLAM (Simultaneous Localization and Mapping), and motion planning modules. This parallel data distribution ensures all relevant subsystems have the latest environmental data without requiring multiple separate transmissions.
+
+Additionally, DDS provides a flexible Quality of Service (QoS) configuration, allowing engineers to fine-tune communication parameters based on system requirements. Low-latency modes are ideal for real-time decision-making in vehicle control, while high-reliability configurations ensure data integrity in safety-critical applications like V2X communication.
+
+
+### Architecture and Operation
+DDS is based on a data-centric publish-subscribe (DCPS) model, allowing producers and consumers of data to communicate without direct dependencies. This modular approach enhances system flexibility and maintainability, making it well-suited for complex automotive environments.
+
+In DDS, all participants operate within a **domain**, which provides logical isolation between different applications. Each domain contains multiple **topics**, representing specific data types such as vehicle speed, obstacle detection, or sensor fusion results. **Publishers** use **DataWriters** to send data to these topics, while **subscribers** use **DataReaders** to receive the data. This architecture supports concurrent data processing, ensuring that multiple modules can work with the same data stream simultaneously.
+
+For example, in an autonomous vehicle, LiDAR, radar, and cameras continuously generate large amounts of sensor data. The perception module subscribes to these sensor topics, processes the data, and then publishes detected objects and road conditions to other components like path planning and motion control. Since DDS automatically handles participant discovery and message distribution, engineers do not need to manually configure communication paths, reducing development complexity.
+
+
+### Applications in Autonomous Driving
+DDS is widely used in autonomous driving systems, where real-time data exchange is crucial. A typical use case involves high-frequency sensor data transmission and decision-making coordination between vehicle subsystems.
+
+For instance, a LiDAR sensor generates millions of data points per second, which need to be shared with multiple modules. DDS allows this data to be published once and received by multiple subscribers, including perception, localization, and mapping components. After processing, the detected objects and road features are forwarded to the path planning module, which calculates the vehicle's next movement. Finally, control commands are sent to the vehicle actuators, ensuring precise execution.
+
+This real-time data flow must occur within milliseconds to enable safe autonomous driving. DDS ensures minimal transmission delay, enabling rapid response to dynamic road conditions. In emergency scenarios, such as detecting a pedestrian or sudden braking by a nearby vehicle, DDS facilitates instant data propagation, allowing the system to take immediate corrective action.
+
+For example: [Autoware](https://www.autoware.org/)—an open-source autonomous driving software stack—uses DDS to handle high-throughput communication across its modules. For example, the **Perception** stack publishes detected objects from LiDAR and camera sensors to a shared topic, which is then consumed by the **Planning** module in real-time. Using DDS allows each subsystem to scale independently while preserving low-latency and deterministic communication.
+
+### Publish-Subscribe Model and Data Transmission
+Traditional client-server communication requires a centralized server to manage data exchange. This architecture introduces several drawbacks, including increased latency and network congestion, which can be problematic in real-time automotive applications.
+
+DDS adopts a publish-subscribe model, enabling direct communication between system components. Instead of relying on a central entity to relay messages, DDS allows each participant to subscribe to relevant topics and receive updates as soon as new data becomes available. This approach reduces dependency on centralized infrastructure and improves overall system performance.
+
+For example, in an automotive perception system, LiDAR, radar, and cameras continuously publish sensor data. Multiple subscribers, including object detection, lane recognition, and obstacle avoidance modules, can access this data simultaneously without additional network overhead. DDS automatically manages message distribution, ensuring efficient resource utilization.
+
+DDS supports multiple transport mechanisms to optimize communication efficiency:
+- **Shared memory transport**: Ideal for ultra-low-latency communication within an ECU, minimizing processing overhead.
+- **UDP or TCP/IP**: Used for inter-device communication, such as V2X applications where vehicles exchange safety-critical messages.
+- **Automatic participant discovery**: Eliminates the need for manual configuration, allowing DDS nodes to detect and establish connections dynamically.
+
+#### Comparison of DDS and Traditional Communication Methods
+
+| **Feature**          | **Traditional Client-Server Architecture** | **DDS Publish-Subscribe Model** |
+|----------------------|--------------------------------|---------------------------|
+| **Data Transmission** | Relies on a central server    | Direct peer-to-peer communication |
+| **Latency**          | Higher latency                 | Low latency               |
+| **Scalability**      | Limited by server capacity     | Suitable for large-scale systems |
+| **Reliability**      | Server failure affects the whole system | No single point of failure |
+| **Use Cases**       | Small-scale applications       | V2X, autonomous driving   |
+
+These features make DDS a highly adaptable solution for automotive software engineers seeking to develop scalable, real-time communication frameworks.
+
+Here is an [installation guide](https://learn.arm.com/install-guides/cyclonedds) on how to install open-source DDS on an Arm platform.
+