ISO 26262(자동차 기능 안전성)
ISO 26262
INDEX
1.ISO 26262 서론
1-1.ISO 26262의 정의
1-2.ISO 26262의 목표
2.ISO 26262의 구성
3.자동차 안전 무결성 레벨 ASIL(Automotive Safety Integrity Level)
3-1.ASIL
3-2.안전 분석
4. 하드웨어 컴포넌트의 조건
5. 소프트웨어 컴포넌트의 조건
6. 테스트 툴 조건
6-1.Tool Confidence Level(TCL)
6-2.툴 조건 프로세스
6-2.1)소프트웨어 툴 검증계획(STQP, Software Tool Qualification Plan)
6-2.2)소프트웨어 툴 문서
6-2.3)소프트웨어 툴 등급 분석(STCA, Software Tool Classification Analysis)
6-2.4)소프트웨어 툴 검증 보고서
1.ISO 26262 서론
1-1.ISO 26262의 정의
ISO 26262는 총 중량이 3.5 톤 이하인 승용차에 설치된 소프트웨어와 하드웨어를 포함하며, 모든 전기/전자(E/E, Electric & Electronic) 안전관련 시스템에 적용되는 IEC 61508를 자동차 전기/전자 시스템에 적응시킨 것으로써 전기·전자 시스템의 오류로 인한 사고방지를 위해 (ISO)에서 제정한 자동차 기능안전성 국제 표준이다.
1-2.ISO 26262의 목표
⓵자동차 안전 수명주기 (관리, 개발, 생산, 운영, 서비스, 폐기 )를 제공하고 수명주기 단계에서 필요한 활동을 지원
⓶요구 사항 명세, 설계, 구현, 통합, 검증, 검증 및 구성과 같은 활동을 포함하여 전체 개발 프로세스의 기능적 안전 측면을 고려
⓷위험 등급 ( 자동차 안전 무결성 레벨 , ASIL)을 결정하기 위한 자동차 별 위험 기반 접근 방식을 제공
⓸잔여 위험을 수용하기 위해 필요한 안전 요구 사항을 지정하기 위해 ASIL을 사용
⓹충분하고 허용 가능한 수준의 안전성을 확보하기 위한 유효성 확인 및 확인 조치에 대한 요구 사항을 제공
2.ISO 26262의 구성
ISO 26262는 9 개의 규범적인 부분과 10 번째 부분 인 ISO 26262의 지침으로 구성된다.
ISO 26262의 구성요소 | 규정 |
1.어휘 | ISO 26262의 모든 부분에 적용되는 용어, 정의 및 약어를 기술
⓵요소: 구성 요소, 하드웨어, 소프트웨어, 하드웨어 부품 및 소프트웨어 장치를 포함하는 시스템 또는 시스템의 일부 등 효과적으로 시스템에서 식별되고 조작 될 수 있는 모든 것을 지칭
⓶결점: 요소 나 항목 이 실패 할 수 있는 비정상적인 조건
⓷오류: 계산 된 값, 관측 된 값 또는 측정 된 값 또는 상태와 실제 값, 명시된 값 또는 이론적으로 올바른 값 또는 조건 간의 불일치를 의미
⓸실패: 필요에 따라 기능을 수행하는 요소 의 기능 종료.
⓹작동 불량: 설계 의도와 관련하여 항목 의 실패 또는 의도하지 않은 동작.
⓺위험: 품목의 오동작으로 인한 잠재적 피해 |
2.기능 안전 관리 | 개별 자동차 제품의 개발 및 생산을 위한 안전 수명주기 표준뿐만 아니라 전반적인 조직 안전 관리 표준을 정의
⓵위험한 사건 적시의 운전자 행동에 의해 통제되지 않으면 사고로 이어질 가능성이 있는 차량의 위험 상태 와 운전 상태의 적절한 조합을 의미
⓶안전 목표 하나 이상의 위험한 사건 의 위험을 허용 수준까지 줄이기 위한 목적으로 시스템에 할당 된 최상위 수준의 안전 요구 사항
⓷자동차 안전 무결성 레벨 ASIL 안전 목표의 자동차 별 위험 기반 분류는 물론 표준 달성에 필요한 검증 및 확인 조치를 나타냄
⓸안전 요구 사항 모든 안전 목표와 안전 목표에서 하드웨어 및 소프트웨어 구성 요소에 할당 된 최저 수준의 기능 및 기술 안전 요구 사항을 포함한 모든 수준의 요구 사항이 포함
⓹안전 수명주기 ISO 26262 안전 수명주기 내의 프로세스는 위험 (안전 위험)을 식별 및 평가하고, 그러한 위험을 허용 가능한 수준으로 줄이기 위한 특정 안전 요구 사항을 수립 |
3.개념 단계 | 항목 정의, 안전 수명주기의 시작, 위험 분석 및 위험 평가, 기능적 안전 개념을 규정 |
4.시스템 수준에서의 제품 개발 | 시스템 수준에서 제품 개발을 시작하기 위한 요구 사항으로써 기술적 안전 요구 사항의 명세, 기술 안전 개념, 시스템 디자인, 항목 통합 및 테스트, 안전성 검증, 기능적 안전성 평가, 제품 출시를 규정 |
5.H/W 수준의 제품 개발 | 하드웨어 수준에서 제품 개발을 시작하기 위한 요구 사항으로써 하드웨어 안전 요구 사항의 명세, 하드웨어 설계, 하드웨어 아키텍처 측정 항목 및 무작위 하드웨어 고장 및 하드웨어 통합 및 테스트로 인한 안전 목표 위반 평가를 규정 |
6.S/W 수준의 제품 개발 | 소프트웨어 수준에서 제품 개발을 시작하기 위한 요구 사항으로써 소프트웨어 안전 요구 사항의 명세, 소프트웨어 아키텍처 설계, 소프트웨어 유닛 설계 및 구현, 소프트웨어 유닛 테스트, 소프트웨어 통합 및 테스트, 소프트웨어 안전 요구 사항 검증을 규정 |
7.생산 및 운영 | 생산, 운영, 서비스 및 폐기에 대한 요구 사항을 규정 |
8.지원 프로세스 | 분산 개발 환경 내의 인터페이스, 안전 요구 사항의 전반적인 관리, 구성 관리, 변경 관리, 확인, 선적 서류 비치, 소프트웨어 도구 사용에 대한 자신감, 소프트웨어 구성 요소의 자격, 하드웨어 구성 요소의 자격 ,입증 된 사용 인수를 규정 |
9.자동차 안전 무결성 레벨 (ASIL) | ASIL 테일러링과 관련된 요구 사항 분해, 요소의 공존 기준, 종속적 인 실패에 대한 분석, 안전 분석을 규정 |
10.ISO 26262 가이드 라인 | ISO 26262의 개요를 제공하고 추가 설명을 제공하며 ISO 26262의 다른 부분에 대한 이해를 높이기 위해 규정 |
3.자동차 안전 무결성 레벨 ASIL(Automotive Safety Integrity Level)
3-1.ASIL
ASIL이란 자동차 시스템 요소에서 고유한 안전 위험을 추상 분류하는 것을 의미하며 특정 위험을 예방하는 데 필요한 위험 감소 수준을 표현하기 위해 사용된다. ASIL의 평가에서 위험은 시스템과 관련된 위험 영향의 상대적인 영향에 근거하여 평가되고, 이러한 영향을 나타내는 위험의 상대 가능성을 고려하여 조정된다. 구체적으로는 위험의 노출,제어 가능성,심각도에 따른 함수라고 볼 수 있다.(즉, ASIL => = f(E, C, S) )
⓵노출 등급 분류: 노출은 분석 대상 고장 모드와 동시에 발생할 경우 위험할 수 있는 작동 상황이 되는 상태로 분류된다. 즉, 상해가 발생할 수 있는 작동 조건의 상대 예상 빈도를 뜻한다.
⓶심각도 등급 분류: 심각도는 위험할 수 있는 상황에서 한 명 이상의 사람에게 발생할 수 있는 위해 범위의 예상치를 뜻한다.
⓷제어 가능성 등급 분류: 제어 가능성이란 관련 당사자가 시기적절한 대응을 통해 지정된 위해 또는 피해를 방지할 수 있는 역량을 뜻한다. 이는 곧,운전자가 부상을 방지하기 위해 행동 할 수있는 상대적인 가능성을 뜻한다.
ASIL는 ASIL A ,ASIL B ,ASIL C ,ASIL D의 범주로 나누어지고 ASIL D가 가장 높은 단계이며 ASIL A가 가장 낮은 단계이다. ASIL A 아래의 ASIL 수준은 최저 수준 인 QM 이라고 하며 QM은 안전 관련성이 없고 표준 품질 관리 프로세스 만 필요하다는 표준의 고려 사항을 나타낸다.
ASIL 범주의 예시1
ASIL 범주의 예시2
이러한 평가(ASIL A ,ASIL B ,ASIL C ,ASIL D)는 다음과 같은 의미를 가진다.
⓵ASIL 수준에 따른 고장 상황에서도 설계자 및 시스템 엔지니어가 실현해야 할 안전 요구 사항을 정의
⓶ASIL 수준은 특정 모듈에 결부되는 것이 아니라 특정 기능에 결부
⓷ASIL 수준은 감지 가능성 향상 및 대응 조치 실행과 같이 동일한 기능을 수행하는 두 가지 개별적인 요소의 분리를 통해 낮출 수 있음
⓸구현된 방식 그대로 안전 핵심 기능의 추적 가능성을 입증할 수 있으려면 설계 사이클의 각 단계에서 적절한 증거를 유지해야함
3-2.안전 분석
안전 분석의 목표는 다음과 같다,
⓵품목의 기능, 작동 상태, 설계를 고려하여 고장 및 장애의 결과를 검사
⓶안전 목표 또는 요구사항 위반으로 이어질 수 있는 상황과 원인에 대한 정보도 제공
⓷위해성 분석 및 위험 평가 도중 발견되지 않은 새로운 위험에 대해 알림
4. 하드웨어 컴포넌트의 조건
하드웨어 컴포넌트의 검증는 부품이 전체 시스템과 잘 맞는지 확인하는 것과 실패 모드를 평가하기 위해서 필요하다. 하드웨어 컴포넌트는 다양한 환경 및 운영 조건에서 부품들을 테스트하여 등급을 부여 받으며 그 결과를 그 다양한 수치적 방식으로 분석되고 테스트 절차, 가정 및 입력 기준과 함께 조건 보고서로 표현된다.
5. 소프트웨어 컴포넌트의 조건
소프트웨어 컴포넌트의 검증에는 기능 요구사항 정의, 리소스 사용률, 실패 및 오버로드 상황에 따른 소프트웨어 작동 예측 활동 등이 있다. 검증된 소프트웨어는 재사용될 수 있으며 이러한 소프트웨어에는 라이브러리, 운영체제, 데이터베이스 및 드라이브 소프트웨어가 이에 해당된다.
6. 테스트 툴 조건
여러 가지 환경상황에 따른 오류를 발견하기 위해 테스트가 필요하며 이는 비용절감 및 문제 발생률를 낮추고 품질과 안정성을 높인다. 이러한 테스트를 위한 테스트 툴 검증에는 Tool Confidence Level을 정의하는 것이 중요하다.
6-1.Tool Confidence Level(TCL)
소프트웨어 툴에 필요한 조건의 등급 수준을 결정되며 다음과 같은 분야가 평가된다.
⓵소프트웨어 툴의 오작동 및 잘못된 출력 가능성은 안전 관련 구성요소에 할당된 안전 요구사항 위반으로 이어짐
⓶출력에서 이 같은 에러를 예방하거나 감지할 가능성
Tool Confidence Level은 TCL1, TCL2, TCL3 또는 TCL4로 구성되며, 전자가 가장 낮은 단계고 후자가 가장 높은 단계이다.
6-2.툴 조건 프로세스
ISO 26262는 툴 검증 작업이 필요하며 다음과 같이 구성된다.
6-2.1)소프트웨어 툴 검증계획(STQP, Software Tool Qualification Plan)
안전 관련 항목의 개발 생명주기의 초기에 생성되며 소프트웨어 툴 조건에 대한 계획 수립과 요구되는 레벨로 툴이 분류되는 것을 도식화한 사용 사례 리스트이다.
6-2.2)소프트웨어 툴 문서
소프트웨어 툴의 적절한 사용을 보장하기 위해서는 여러 부분의 정보가 반드시 제공되며 그 구성은 기능,설치과정,사용자 매뉴얼,동작 환경,비정상적인 상태에서의 예상 동작이다.
6-2.3)소프트웨어 툴 등급 분석(STCA, Software Tool Classification Analysis)
툴의 신뢰성 등급을 결정,TCL는 Tool Impact (TI)과 Tool Error Detection (TD)으로 결정을 되며 요구되는 신뢰 레벨에 따라 TCL1부터 TCL4까지의 값이 주어진다.(다양한 사용 사례가 있을시 가장 높은 TCL가 적용)
6-2.4)소프트웨어 툴 검증 보고서
툴 검증이 완료되었고, 모든 요구조건이 충족되었다는 결과와 관련 증거가 포함되며 검증 동안의 발생하는 모든 오작동이나 잘못된 출력들은 이곳에 분석되고 문서화되어야 한다.