ISO 26262 적용에 있어 필수적인 활동인 안전 분석에서 알아보기로 한다.
안전 분석은 개발 단계에 따라 완성된 function, behavior, design의 잠재적인 고장과 결함의 원인, 결과를 분석하는 활동이다. 안전 목표(Safety Goal) 또는 안전 요구사항의 위배를 야기할 수 있는 조건과 이에 대한 원인 분석을 수행함에 목적을 둔다. 이에 더불어 위험 요소들에 대한 회피, 제거, 완화 등의 해결책을 찾기 위한 방법도 제시한다.
ISO 26262에서 안전 분석은 기능 안전 요구사항 및 안전 메커니즘의 수립과 시스템 안전을 유지하는 근거를 제공하기 때문에 필수적인 활동이다.
1. 안전 분석 기법의 종류
귀납적 분석 방법과 연역적 분석 방법으로 나눈다.
- 귀납적 분석 방법: 경험적 요인을 포함시킨 확률적 분석방법이며, 전제가 참이면 결론은 확률적 참이고 필연적인 참이 아닌 것으로 결론을 내는 방법 (예: FMEA, ETA)
- 연역적 분석 방법: 논리적인 분석 방법이며, 전제가 참이면 결론도 반드시 참으로 정의되는 방법 (예: FTA, reliability block diagram)
귀납적 분석 방법은 경험, 지식에 의존하며 이것이 풍부할 경우 빠짐없는 분석이 되지만, 양날의 검처럼 경험과 지식의 범주에만 머물 수 있는 단점이 있다.
연역적 분석 방법은 경험, 지식이 부족한 경우 수행하는데, 분석 내용이 목표한 바에서 벗어날 가능성이 크다.
본 포스팅에서는 안전 분석 기법 중, 귀납적 분석 방법의 대표적인 예시인 FMEA를 다룬다.
2. FMEA 종류
Process FMEA와 Product FMEA가 분류의 첫번째 구분으로 나눌 수 있다. ISO 26262는 Product FMEA를 주된 수행 방법으로 채택하며, 분석 대상과 failure mode에 따라 System/HW/SW로 나눈다. System/HW/SW FMEA는 분석 대상과 failure mode만 다를 뿐 수행 절차, 방식은 동일하다.
3. FMEA 수행 절차
과거 발생한 문제나 엔지니어의 경험에 의존하여 잠재적인 고장 모드를 식별한다. 식별된 고장 모드에 의한 영향 분석을 수행하고 고장 모드의 원인을 분석 후, 고장 모드의 위험을 평가한다. 평가된 위험의 우선 순위에 따라 회피 방안을 수립한다. 다음의 절차로 수행한다.
3-1) 분석 대상 정의 -> 3-2) 계획 수립 -> 3-3) 고장 모드 식별 -> 3-4) 고장 원인 및 영향 분석 -> 3-5) 위험 평가 -> 3-6) 위험 모니터링 -> 3-7) FMEA 결과서 작성
3-1. 분석 대상 정의
분석 대상의 범위, 경계, 동작하는 환경 등을 정의한다.
논리적, 물리적 구조로 정의하고 외부 인터페이스 및 환경 요소를 파악한다. 예비 아키텍처를 정의하여 대상을 정의한다.
각 단계별 필수자료 및 관련 자료는 다음과 같다. (필수자료 / 관련자료)
- 시스템: 시스템 설계서 / 시스템 사양서, 법규 및 규약, 과거 차 문제점, 차량 아키텍처
- HW: HW 설계서 / HW 사양서, HSI, HW 데이터 시트, HW 임의 고장 데이터, HW 필드 문제점
- SW: SW 설계서, 소스 코드 / SW설명서, HSI, SW 설계 규약, 모델링 규약, SW 과거 문제점
3-2. 계획 수립
FMEA 목적, 역할, 일정 및 프로세스를 규정한다. 분석을 수행할 단위 구성 요소로 분해한다. 분석 대상이 되는 구성 요소와 기능의 계층화를 한다. FMEA를 수행할 인원을 구성한다. 수행할 인원은 시스템 개발자를 비롯하여 다양한 전문가가 참여할 수 있다.
3-3. 고장 모드 식별
고장 모드는 시스템에 정의된 기능 별로 발생 가능한 고장 모드를 식별한다.
System FMEA: 구체적인 설계가 이루어지지 않은 상태이기 때문에 기능/구조 상에서 발생할 수 있는 잠재적인 고장 모드를 식별한다.
HW, SW FMEA: 구체적인 설계가 이루어진 상태이므로 구성 요소들 간의 관계가 상호작용을 통해 발생할 수 있는 고장 모드를 식별한다.
3-4. 고장 원인 및 영향 분석
시스템, HW, SW의 고장 모드가 식별되었으면, 그 고장을 일으키는 원인과 그 고장이 차량 기능이나 성능에 미치는 영향을 분석한다.
고장 영향 분석: 시스템의 잠재적 고장 모드에 따라 상위 시스템에서 발생할 수 있는 고장 영향 분석, 상위 시스템이 차량일 경우 고장 영향은 위험원(hazard)을 의미한다.
고장 원인 분석: 추후 위험 회피 방안을 수립할 때, 근본적인 원인에 대한 조치를 취하기 위해 필요하다. 시스템을 구성하는 구성 요소들 간의 상호 작용이나 물리적/전기적/화학적 특성에 근거한다. 기술적 근거만을 기록하며 과거 유사 시스템 개발 시 밝혀진 고장 원인의 경우도 포함한다.
3-5. 위험 평가
식별된 시스템의 고장이 차량의 기능이나 성능에 미치는 영향의 심각도와 고장의 발생 빈도, 고장을 검출할 수 있는 가능성 등을 평가하여 고장으로 인한 위험도륵 계산한다.
심각도, 검출도, 발생빈도의 곱으로 고장 위험도를 계산한다. RPN값이라 한다.
가장 높은 RPN 값을 갖는 위험 원인에 대해 우선적으로 위험 조치사항을 적용한다.
3-6. 위험 모니터링
시스템 고장별 위험도에 따라 위험의 원인을 제거하거나 위험을 회피 ,또는 완화시키는 방안을 수립하여 시스템, HW, SW 개발에 반영한다. 시스템 안전 요구사항을 확증하기 위해 조치 사항에 대한 시험 결과를 검토한다.
3-7. FMEA 결과서 작성
전체 FMEA 활동에 대한 결과를 문서 형식에 맞게 명세한다.
'IT 각종 공부' 카테고리의 다른 글
소프트웨어 테스트 (Software test) - 2편 (0) | 2021.09.03 |
---|---|
소프트웨어 테스트 (Software test) (0) | 2021.09.02 |
요구 공학 (Requirements Engineering) -3 (0) | 2021.08.30 |
요구공학 (Requirements Engineering) - 2 (0) | 2021.08.29 |
요구공학 (Requirements Engineering) - 1 (0) | 2021.08.28 |
댓글