As the connectivity, smartification, and proliferation of ADAS and autonomous driving-related functions in automobiles increase rapidly, the use of external open-source solutions is also on the rise.
In such cases, the following considerations should be taken into account to address responsibility-related issues and resolve any arising issues in automobiles:
Responsibility:
- The origin and basis of open-source software must be clear.
- If integrating the requirements of open-source software into its own ECU software, it must be communicated to customers or higher-tier entities.
- Although open-source software does not require ACQ4 (Automotive SPICE Acquisition Process), OEMs and higher-tier entities must manage it through ACQ4.
Development and Testing Plans:
- Open-source usage constraints must be stated in the development and testing plans, along with justifications.
- The testing plan should outline the test scope and verification criteria.
- Development and testing must be conducted based on the aforementioned justifications.
Design Perspective:
- It is recommended to document open-source usage in the Software Requirements Specification (SRS). (However, if open-source represents a component rather than one or multiple functional/non-functional requirements, it may not be listed in the SRS. Nevertheless, it must be included in the Software Architecture Design (SAD), and it's recommended to denote it as open-source in the architecture.)
Testing Perspective:
- If there's no Software Design Description (SDD), consider writing a separate SDD for testing purposes. Alternatively, use ISO 26262's SWC certification methods to substitute unit testing.
- Develop a test strategy based on evidence and criteria. (Especially for components related to safety functions, SWC qualification must be conducted, and ASIL coexistence must be assessed through DFA.)
Footnotes
Advanced Driver Assistance System (ADAS) : is an essential technology that aims to provide enhanced driving assistance, contributing to the safety and full realization of autonomous driving. It's important to note that while ADAS supports and assists drivers, autonomous driving aims to fully replace drivers. Therefore, while ADAS requires the presence of a driver, autonomous vehicles do not.
(Major Technologies)
- Lane Departure Warning System
- Forward Collision Warning System
- Emergency Automatic Braking
- Parking Steering Assist System
- Traffic Sign/Signal Recognition Technology
- Adaptive Cruise Control System
*ACQ4: Acquisition Process Group monitors and supervises the progress of supplier activities based on agreed-upon requirements.
In addition to ACQ 3, 4, 11, 12, 13, 14, and 15 stages.
Reference: https://grapevine9700.tistory.com/43
*SRS: Software Requirements Specification (SRS) documents software requirements and specifications, playing a crucial role in the early stages of software development.
*SAD: Software Architecture Design (SAD) documents and explains software architecture, providing detailed information about the architecture of software or information systems to help project-related stakeholders understand and consult on the system's structure and design.
(Generally includes introduction, architecture overview, diagrams, technology stack and components, security, and performance considerations.)
*SDD: Software Design Description (SDD) documents software design, providing a detailed description of the software system's structure, components, functionality, and operation to help developers, testers, and other stakeholders understand and work effectively on the software's design.
*[ISO26262's SWC Certification Method]: ISO 26262 is an international standard for functional safety of automotive electronic systems, and the certification method for software components is established according to the standard below.
- Requirements Analysis
- Software Design
- Software Implementation
- Verification and Review
- Certification and Evaluation
- Maintenance and Updates
*SWC Qualification: SWC Qualification verifies software components for safe use according to regulations such as ISO 26262. Generally established according to the following steps:
- Requirement Definition
- SWC Analysis
- Verification and Review
- Certification by Certification Body
- Maintenance and Updates
*DFA: Dependent Failure Analysis (DFA) analyzes and understands dependent errors that may occur within a system or device.
Additionally, dependent failures are cases where the failure of one component is related to the failure of another, which distinguishes them from independent cases. These may occur when one component shares causation with another or shares the same component.
Types of dependent failures include:
- Common Cause Failure (CCF)
- Common Mode Failure (CMF)
- Coupled Failure (CF)
*ASIL: Automotive Safety Integrity Level (ASIL) indicates the level of automotive safety integrity. It's a risk classification system defined in the ISO 26262 standard for the functional safety of road vehicles.
The four ASILs are as follows:
- ISO26262 - A: Represents the lowest grade (rear lamps)
- ISO26262 - B: (Headlights and brake lights, etc.)
- ISO26262 - C: (Cruise control)
- ISO26262 - D: Represents the highest grade (airbags, anti-lock brakes, and power steering)
