Post

Guideline [2]: ISO 26262

Posted Updated
By Dyan Lee
9 min read

ISO26262?

ISO(국제표준화기구)가 제정한 자동차 기능안전에 관한 국제표준

An international standard for automotive functional safety established by ISO (International Organization for Standardization)

0

ISO26262 and MISRA C are safety-related standards for automotive software and system development.

  • To prevent accidents caused by errors in the E/E (Electrical and/or Electronic) system installed in the vehicle.
  • ISO collaborates closely with the International Electrotechnical Commission (IEC).
    • ISO 26262 specifications were officially released in 2011 as an adaptation of IEC 61508, the generic functional safety standard for E/E systems.
  • ISO 26262 defines the required activities, tangible and intangible evidence, and methods used for development and production, along with a process model.
    • Comprised of a total of 10 parts and 43 requirements and recommendations, it defines the overall flow of hardware and software development and follows the V model development process.

1

Background

  • 유럽연합(EU)은 자동차 전자제어장치(ECU) 장착 의무화를 강화하고, 첨단 운전 보조 시스템과 통합 안전 시스템 설치를 요구하고 있다.
  • 소프트웨어 문제는 국제 자동차 산업의 법적 분쟁과 사고의 주요 요인으로 부각되고 있다. 예를 들어, Toyota의 급가속 사고는 ECU의 소프트웨어 결함으로 발생했다.
  • 자동차 ECU의 확산과 차량 네트워킹의 복잡성 증가로 기능안전의 중요성이 커지고 있다.
  • 여러 공급업체의 ECU 개발과 전자 제어 시스템의 복잡성 증가로 표준화 필요성이 커지고 있다. 표준화는 개발 효율성을 높이고 비용을 절감하는 데 도움이 된다.
  • IEC 61508은 일반 전기 및 전자 장치에 대한 기능 안전 표준이지만, 자동차 산업의 특수성을 반영하지 못한다. 자동차 전용 기능 안전 표준이 필요하다.
  • The European Union is strengthening the mandatory installation of Electronic Control Units (ECUs), which are crucial components of automotive electronic control systems. This includes enforcing the mandatory installation of advanced driving assistance systems and integrated safety systems in vehicles to enhance overall road safety.
  • Software-related issues are increasingly becoming significant factors in legal disputes and accidents within the international automotive industry. For example, Toyota’s sudden acceleration incident was attributed to a software defect in the ECU, highlighting the critical impact of software reliability on vehicle safety.
  • The importance of functional safety is growing due to the rapid proliferation of automotive ECUs and the increasing complexity of vehicle networking. As cars become more electronically sophisticated, ensuring that these systems operate safely under all conditions becomes paramount.
  • As the development of ECUs by multiple suppliers becomes more common and the complexity of automotive electronic control systems continues to rise, there is a growing need for standardization. Standardizing development processes can improve efficiency, streamline collaboration among different suppliers, and significantly reduce costs.
  • While IEC 61508 is a comprehensive functional safety standard for general electrical and electronic devices, it does not adequately address the unique requirements and specific characteristics of the automotive industry. This gap underscores the need for automotive-specific functional safety standards to ensure the highest levels of safety and reliability in vehicle electronic systems.

표준화 과정

2

ISO 26262 Overall Development Stages

3Overview of ISO 26262

4

Part1. Vocabulary

  • Requirements
    • Consists of the processes that customers perform to acquire products and services

Part2. Management of Functional Safety

  • Contents
    • 2-5. Overall safety management
    • 2-6 Project dependent safety management
    • 2-7 Safety management regarding production, operation, service and decommissioning
  • Requirements
    • Define requirements to plan, coordinate and track individual activities related to functional safety
    • Define overall safety management requirements

Part3. Concept Phase

  • Contents
    • 3-5 Item definition
    • 3-6 Hazard analysis and risk assessment
    • 3-7 Functional safety concept
  • Requirements
    • ASIL determination through hazard analysis and risk screening based on development item definition
    • Define safety goals and safety mechanisms

Part4. Product Development: System Level

  • Contents
    • 4-5 General topics for the product development at the system level
    • 4-6 Technical safety concept
    • 4-7 System and item integration and testing
    • 4-8 Safety validation
  • Requirements
    • System integration from the manufacturer’s perspective
    • Check safety mechanisms implemented in technologies other than electrical and electronic systems
    • Verification of the effectiveness of safety concepts implemented by external means
    • Premise verification of human controllability and operational tasks

Part5. Product Development: Hardware Level

  • Contents
    • 5-5 General topics for the product development at the hardware level
    • 5-6 Specification of hardware safety requirements
    • 5-7 Hardware design
    • 5-8 Evaluation of the hardware architectural metrics
    • 5-9 Evaluation of safety goal violations due to random hardware failures
    • 5-10 Hardware integration and verification
  • Requirements
    • Definition of requirements for HW development, integration, verification, etc. according to the V model concept

Part6. Product Development: Software Level

  • Contents
    • 6-5 General topics for the product development at the software level
    • 6-6 Specification of software safety requirements
    • 6-7 Software archtectural design
    • 6-8 Software unit design and implementation
    • 6-9 Software unit verification
    • 6-10 Software integration and verification
    • 6-11 Testing of the embedded software
  • Requirements
    • Define requirements for development, integration, verification, etc. according to the V model concept for SW level development

Part7. Production, operation, service and decommissioning

  • Contents
    • 7-5 Planning for production, operation, service and decommissioning
    • 7-6 Production
    • 7-7 Operation, service and decommissioning
  • Requirements
    • Define requirements for planning for item production, sample production, mass production, service, etc.

Part8. Supporting processes

  • Contents
    • 8-5 Interfaces within distributed developments
    • 8-6 Specification and management of safety requirements
    • 8-7 Configuration management
    • 8-8 Change management
    • 8-9 Verification
    • 8-10 Documentation management
    • 8-11 Confidence in the use of software tools
    • 8-12 Qualification of software components
    • 8-13 Evaluation of hardware elements
    • 8-14 Proven in use argument
    • 8-15 Interfacing an application that is out of scope of ISO 26262
    • 8-16 Integration of safety-related systems not developed according to ISO 26262
  • Requirements
    • Definition of requirements for safety requirements management, specification method, configuration/change management, verification, documentation, support tool qualification verification, reusable SW qualification verification, HW qualification verification, safety proven through actual use, etc.

Part9. 9. Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses

  • Contents
    • 9-5 Requirements decomposition with respect to ASIL tailoring
    • 9-6 Criteria for coexistence of elements
    • 9-7 Analysis of dependent failures
    • 9-8 Safety analyses
  • Requirements
    • How to disassemble safety requirements ASIL
    • Degree of mutual interference, which is a condition of coexistence between safety-related components, and risk analysis method technology

Part10. Guidelines on ISO 26262

  • Requirements
    • Information technology to help you understand ISO 26262, including key concepts, safety cases, ASIL breakdown, and more

Part11. Guidelines on application of ISO 26262 to semiconductors

* Parts added in the 2nd Edition

Part12. Adaptation of ISO 26262 for motorcycles

* Parts added in the 2nd Edition

  • Contents
    • 12-5 General topics for adaptation for motorcycles
    • 12-6 Safety culture
    • 12-7 Confirmation measures
    • 12-8 Hazard analysis and risk assessment
    • 12-9 Vehicle integration and testing
    • 12-10 Safety validation

ISO 26262 SW, HW Development Stages

5The V model for software development. a V‑shaped cycle.

6The hardware design flow in ISO 26262-5

ASIL

ASIL(자동차 안전 무결성 레벨; Automotive Safety Integrity Level)은 상황 노출 가능성, 잠재적 위험 심각도, 제어 가능성을 기준으로 4가지 레벨로 구분되는 안전 측정 표준이다.

ASIL (Automotive Safety Integrity Level) is a safety measurement standard divided into four levels based on the likelihood of exposure of the situation, potential severity of risk, and controllability.

ASIL의 등급 결정은

  1. 위험원의 심각도(S:Severity) 평가
  2. 노출 가능성(E:Expisure)
  3. 제어성(C) 평가

의 평가표를 통해 분류, 결정된다.

ASIL’s rating decisions are

  1. Severity (S:Severity) assessment of risk sources
  2. Possibility of exposure (E:Expisure)
  3. Controllability (C) assessment

each grade is classified and determined through an evaluation table.

  • ASIL은 최저 등급 A부터 최고 등급 D까지 구성됨.
  • ASIL이 높다는 것은 해당 개발 아이템의 오류로 인해 사고가 날 경우 상대적으로 피해가 클 수 있음을 의미한다. 그 위험을 줄이기 위해 높은 수준의 안전 메커니즘과 안전 요구 사항이 강력해져야 한다.
  • IEC 61508의 SIL(안전 무결성 수준; Safety Integrity Level)을 차량의 특성에 맞게 조정한 것이다.
  • ASIL is composed of the lowest grade A to the highest grade D.
  • A high ASIL means that if an accident occurs due to an error in the development item, the damage may be relatively high. To reduce that risk, high-level safety mechanisms and safety requirements must be strengthened.
  • The SIL (Safety Integrity Level) of IEC 61508 is adjusted to suit the characteristics of the vehicle.

7

8

Reference

Guideline/Assessment
guideline safety-related-standards ICMS ISO 26262
This post is licensed under CC BY 4.0 by the author.