FMECA는 고장 모드, 그로 인한 영향, 심각도를 분석해 시스템의 신뢰성과 안전성을 개선하는 체계적인 기법입니다.
처음 접하는 경우 다소 생소할 수 있지만, 설계 초기 단계에서 잠재적 고장을 식별하고 예방 조치를 마련하는 데 핵심 역할을 합니다.
이번 포스팅에서는 FMECA의 개념과 절차를 구체적으로 살펴보며 이를 어떻게 활용할 수 있는지 알아보겠습니다.
FMEA/FMECA 관련 포스팅
- SW FMEA의 Ground Rules - 사전활동, 준비물, 그라운드 룰
- DRBFM vs. FMEA - 소프트웨어 개발에서 차이점과 장단점
- DRBFM (Design Review Based on Failure Modes) - 수행 원칙, 사전 준비, 수행 절차
- ISO 26262: Vocabulary (Part 1), 기능안전 표준 용어 정리 (2018) - S
- ISO 26262: Confirmation Measure에 대한 총정리
소프트웨어 신뢰성 분석과 FMECA 개요
소프트웨어 신뢰성 분석은 시스템의 신뢰성을 확보하고 검증하기 위해 필요한 시험을 수행하여 효과적인 비용으로 높은 신뢰성을 갖는 시스템을 설계하는 데 도움을 줍니다. FMECA(Failure Mode, Effects, and Criticality Analysis)는 시스템 고장을 분석하는 체계적 기술로 미 국방성에서 처음 개발되었으며, 시스템의 잠재적 고장 유형과 그 영향을 조기에 식별하여 예방 조치를 취하도록 합니다.
FMECA의 역사와 발전
1. MIL-P-1629 (1949년):
미 국방성에서 제정한 “Procedures for Performing a Failure Mode, Effects, and Criticality Analysis”가 FMECA의 첫 번째 가이드라인입니다.
2. NASA 아폴로 미션 (1960년대):
FMECA는 NASA에서 우주 프로그램의 하드웨어 신뢰성 향상과 검증을 위해 처음 적용되었습니다.
3. MIL-STD-785B 및 MIL-STD-1629A:
- MIL-STD-785B (폐기됨): 시스템 및 장비의 신뢰성 프로그램을 정의.
- MIL-STD-1629A (폐기됨): FMECA 수행을 위한 요구사항과 절차를 수립.
- 비록 MIL-STD-1629A는 폐기되었지만, 해당 개념과 기법은 국방 및 민수 산업의 중요한 시스템 개발 과정에 여전히 유용하게 적용되고 있습니다.
4. FMEA와 FMECA의 차이점
- FMEA (Failure Modes and Effects Analysis): 고장 유형과 그 영향을 분석하여 정량적 순위를 제공.
- FMECA: FMEA의 확장으로 심각도 분석 (Criticality Analysis, CA)을 포함하여 고장 영향의 심각성(Criticality)과 발생 가능성을 등급화.
- FMECA 절차는 고장 모드를 분석하고 각 고장 유형에 대해 심각도, 빈도, 탐지 가능성을 평가합니다.
FMECA 개념
시스템 설계자는 시스템의 기능적 속성과 물리적 속성을 고려하여 다음과 같은 내용을 평가합니다:
- 발생 가능한 고장 유형과 고장 빈도.
- 고장 원인과 그로 인한 결과.
- 고장 예방책 및 시스템 개선 방안.
FMECA의 목표:
- 시스템의 약점 및 잠재적 위험을 조기에 발견.
- 설계 변경 시 고장 유형을 분석하여 개선 방향을 설정.
- 유지보수 계획 및 정량적 신뢰성 분석의 기초 데이터 제공.
FMECA는 초기 설계 단계에서 이러한 시스템 분석을 통해 신뢰성 및 안전성을 지닌 대체 설계를 하도록 도와줍니다. 모든 내재되어 있는 고장 유형과 영향성이 시스템의 성공적인 동작과 관련이 있다는 점을 알 수 있게 해 줍니다. 또한 가능성 있는 고장 유형 목록을 만들 수 있으며, 그 영향 정도를 알 수 있습니다. 그리고 시스템 설계 변경 시 고장 유형을 분석하는 데 도움을 주기 위해 미래에 참고하기 위한 기록 문서를 제공할 뿐만 아니라 유지보수 계획 및 정량적인 신뢰성 및 유용성 분석을 위한 기본 데이터를 제공합니다.
일반적으로 FMECA 는 다음과 같은 기본 정보를 식별하고 분석한다.
- Item(s)
- Function(s)
- Failure(s)
- Effect(s) of Failure
- Cause(s) of Failure
- Current Control(s)
- Recommended Action(s)
- Plus other relevant details
FMECA에서 RPN과 Criticality Analysis
FMECA(Failure Mode, Effects, and Criticality Analysis)는 FMEA의 확장된 개념으로 고장 영향과 함께 심각도를 정량적으로 평가하는 기법입니다. FMECA에서 RPN(Risk Priority Number)과 Criticality Analysis는 각각 고장 위험의 우선순위를 평가하고 고장의 심각도를 정량화하기 위한 핵심 도구입니다.
1. RPN(Risk Priority Numbers)
RPN은 위험 우선순위 번호로, 각 고장 모드의 위험도를 평가하고 비교하는 데 사용됩니다. 이를 통해 어떤 고장 유형을 우선적으로 개선해야 하는지를 결정할 수 있습니다.
RPN 계산 방법
RPN은 다음 세 가지 요소의 곱으로 계산됩니다: (참고: SW FMEA: 위험도 평가를 위한 심각도(Severity), 발생가능성(Occurrence), 검출가능성(Detection) 선정 기준)
- Severity (심각도): 고장이 발생했을 때 시스템, 사용자, 고객에 미치는 영향의 심각한 정도를 평가합니다.
등급 범위: 1(매우 낮음) ~ 10(매우 높음, 치명적). - Occurrence (발생 가능도): 고장이 발생할 수 있는 빈도 또는 확률을 평가합니다.
등급 범위: 1(거의 발생하지 않음) ~ 10(자주 발생). - Detection (검출 가능도): 고장이 발생하기 전에 이를 발견할 가능성을 평가합니다.
등급 범위: 1(쉽게 발견 가능) ~ 10(발견하기 어려움).
RPN 활용
- RPN 값이 높을수록 위험도가 큽니다.
- 우선순위를 설정하여 위험도가 높은 고장 모드부터 개선 활동을 수행합니다.
- 일반적으로 RPN 임계값을 설정하고, 해당 값을 초과하면 즉각적인 조치가 필요합니다.
2. Criticality Analysis (심각도 분석)
Criticality Analysis는 고장의 심각도와 발생 확률을 종합적으로 고려하여 고장 모드의 **중요도(criticality)**를 평가하는 기법입니다.
이는 정량적 및 정성적 방법으로 수행될 수 있습니다.
(1) 정량적 심각도 분석
정량적 분석은 고장의 발생 확률과 심각도를 수치화하여 각 고장 모드의 중요도를 평가합니다.
정량적 Criticality 계산식:
- Item Unreliability (항목 신뢰성 결핍): 특정 부품이 고장 날 확률.
- Mode Ratio (고장 모드 비율): 특정 고장 모드가 전체 고장에서 차지하는 비율.
- Probability of Loss (손실 확률): 고장이 시스템 성능이나 안전에 미치는 영향의 확률.
- 부품의 전체 심각도 (Item Criticality)는 개별 고장 모드의 심각도를 모두 합산하여 계산합니다:
(2) 정성적 심각도 분석
정성적 분석은 심각도(Severity)와 발생 빈도(Frequency)를 평가한 후 심각도 매트릭스(Criticality Matrix)를 이용해 위험도를 시각화합니다.
이 매트릭스를 통해 위험 수준을 등급화하고 고장 모드를 비교할 수 있습니다. 고장에 대한 영향을 수용할 수 있는 경우, ACCEPT 등급으로 표시합니다.
- 위험 수준: 낮음(LOW), 중간(MED), 높음(HIGH)
2. FMECA 절차
FMECA는 FMEA와 심각도 분석(CA: Criticality Analysis)으로 구성되어 있으며, FMEA는 CA를 수행하기 전에 반드시 완료되어야 하며, FMECA는 다음 그림과 같은 절차로 수행됩니다. 또한 시스템 개발 수명 주기를 통해 설계 변경에 영향을 주는 방법으로 반복적으로 적용할 수 있습니다.
(1) 시스템 요구사항 정의 (Definition of System Requirements)
기대하는 결과와 이와 관련된 기술 성능 측도 (TPMs: Technical Performance Measures) 측면의 시스템을 기술합니다.
(2) 기능 분석 (Accomplishment of Functional Analysis)
기능적인 측면에서 시스템을 정의합니다. 시스템은 개발 생명 주기 초반에 기능 요소로 분해되어 이 후에 물리적인 패키지 형태로 구성될 수 있습니다.
(3) 요구사항 할당 (Accomplishment of Requirements Allocation)
시스템 레벨의 요구사항을 하향식 방법으로 분해합니다.
(4) 고장 모드 식별 (Identification of Failure Modes)
고장 모드 (Failure Mode)는 시스템의 특정 기능이 고장으로 실행되는 형태를 말합니다. 일반적으로 HAZOP의 가이드워드를 이용하여 시스템 기능 오동작을 식별하고, 이에 따른 고장 모드를 식별하게 됩니다.
(5) 고장 원인 결정(Determination of the Cause of Failure)
고장이 발생하는 실제 원인을 결정하기 위해 프로세스나 제품을 분석합니다. 일반적인 원인은 시스템을 운영하는 동안 비정상적인 기기의 스트레스, 마모, 소프트웨어의 경우 코딩 오류 등이 있을 수 있습니다.
잠재적인 고장 원인을 분석하는데에는 이시가와(Ishikawa)의 원인-영향도(Cause-and-Effect Diagram)를 그려서 표현하면 효과적입니다. 원인-영향도는 생선 가시모양과 비슷하다 하여 어골도(Fish bone diagram)라고도 하며 경험 기반 고장 원인 결정보다는 효율적일 수 있습니다.
(6) 고장 영향도 결정 (Determination of the Effects of Failure)
고장은 시스템 전체 뿐 아니라 연관된 기능의 성능 및 유효성에 여러 가지 형태의 영향이 미치게 됩니다. 이것은 시스템 계층 구조에서 같은 레벨에 있거나 상위 레벨이 있는 다른 구성요소에 고장 영향도를 고려할 때 매우 중요한 원인이 됩니다.
(7) 고장 발견 방법 식별 (Identification of Failure Detection Means)
프로세스 FMECA는 고장이나 결합 발생을 발견할 수 있도록 현재의 프로세스를 통제합니다. 설계 단계에서 FMECA는 잠재적인 고장 발견이 될 수 있는 설계 형태, 설계 기준, 데이터 판독 정보 기기, 설계 평가 절차 등에 중점적으로 확인합니다.
(8) 고장 모드 심각도 결정 (Determination of Failure Mode Severity)
고장이 발생했을 때 단지 시스템 성능 감소인지 아니면 시스템의 파괴나 인명 피해가 있는지 특정 고장으로 인한 영향이나 충돌의 중요성을 참조하여 고장 결과 범위를 정할 수 있습니다. 이러한 고장 영향을 실례를 통해 표현하기 위해서 심각도를 1에서 10까지 정량적으로 표시한다. 심각도는 안전성 이슈 또는 고객의 불만족도와 연관되어 결정할 수 있습니다. (참고: SW FMEA: 위험도 평가를 위한 심각도(Severity), 발생가능성(Occurrence), 검출가능성(Detection) 선정 기준)
(9) 고장 모드 빈도 등급화 (Rating of Failure Mode Frequency)
시스템 내에 있는 기능이나 컴포넌트가 다양한 방법으로 고장 발생이 주어진다면 이번 단계에서는 각각의 고장 유형의 발생 빈도를 확인합니다. 시스템 요소의 모든 고장 빈도의 합이 시스템 고장 비율과 같아야만 하며, 정량화 목적을 위해 1에서 10까지 범위에서 등급화 합니다. (참고: SW FMEA: 위험도 평가를 위한 심각도(Severity), 발생가능성(Occurrence), 검출가능성(Detection) 선정 기준)
(10) 고장 모드 발견 확률 등급화 (Rating of Failure Mode Detection Probability)
고장 모드 발견 확률 등급화는 프로세스 통제, 설계 형태, 검증 절차 등이 주요 시스템 재해를 막기 위한 적절한 시기에 잠재적인 고장을 발견할 수 있는 것과 연관이 있습니다. 프로세스에 적용하기 위해서 고장 모드 발견 확률 등급화는 고장 영향이 후속 프로세스나 최종 소비자, 사용자에게 전달되기 전에 프로세스 통제를 하는 현재 지점에서 고장 발견 및 검증을 할 수 있는 위치가 되는 확률을 참조하는 것입니다. 고장 유형 발견 확률 순위 또한 정량화 표기를 위해 1부터 10까지의 수를 사용합니다. (참고: SW FMEA: 위험도 평가를 위한 심각도(Severity), 발생가능성(Occurrence), 검출가능성(Detection) 선정 기준)
(11) 고장 모드 심각도 분석 (Analysis of Failure Mode Criticality)
고장 모드 심각도 분석의 목적은 시스템 설계의 심각한 상황을 기술하기 위해 이전 단계의 결과를 반영하는 것입니다. 위험도는 심각도, 빈도, 발견 확률 기능으로 볼 수 있고 RPN(Risk Priority Number, 위험 우선순위번호)으로 환산하여 표기할 수 있습니다. RPN은 다음 식으로 표현됩니다.
RPN은 고장 모드의 심각도를 나타냅니다. 예를 들어 발생 빈도가 높거나 시스템 성능에 중대한 영향을 주는 고장 유형과 발견하기 어려운 고장유형은 매우 높은 RPN으로 관찰됩니다.
(12) 제품/프로세스 향상을 위한 제언 (Initiation of Recommendations for Product/Process Improvement)
마지막 단계는 RPN의 영역으로 식별되는 반복적인 프로세스나 그 원인에 대한 평가, 제품/프로세스 향상을 위한 제언으로 후속 조치를 하는 것이다. FMECA는 시스템 개발 주기를 통해 반복적으로 적용하는 설계 변경에 적절한 방법이다. 또한 문서화가 잘되어 있는 FMECA는 일단 시스템이 운영되면 유지보수나 고장수리를 지원한다. FTA와 연관되어 있는 FMECA는 위험요소 분석(Hazard Analysis)을 수행하기에 효과적인 접근방법이다. FMECA의 결과는 FTA에서 필요로 하는 모든 “바람직하지 않은(undesirable)" 시스템 레벨 이벤트를 식별하는 FTA의 적합한 입력으로 지원된다.
FMECA는 시스템과 소프트웨어의 신뢰성을 확보하고 고장을 예방하는 데 효과적인 기법입니다. 설계 초기 단계부터 적용하여 위험 요인을 조기에 식별하고 개선 방안을 마련함으로써 시스템 성능, 안전성, 유지보수 효율성을 극대화할 수 있습니다.
FMECA는 단순한 고장 분석을 넘어, 시스템의 신뢰성과 경쟁력을 강화하는 핵심 도구입니다.
FMEA/FMECA 관련 포스팅
- SW FMEA의 Ground Rules - 사전활동, 준비물, 그라운드 룰
- DRBFM vs. FMEA - 소프트웨어 개발에서 차이점과 장단점
- DRBFM (Design Review Based on Failure Modes) - 수행 원칙, 사전 준비, 수행 절차
- ISO 26262: Vocabulary (Part 1), 기능안전 표준 용어 정리 (2018) - S
- ISO 26262: Confirmation Measure에 대한 총정리
'Software Engineering' 카테고리의 다른 글
| 소프트웨어공학: 소프트웨어 생산성 측정과 개선 - 생산성 측정 프로세스 (0) | 2024.12.20 |
|---|---|
| 자동차 제어 소프트웨어 개발에서의 나쁜 소프트웨어 엔지니어 특징과 교훈 (2) | 2024.12.18 |
| 끊임없이 진화하는 소프트웨어: Lehman의 8대 법칙 (리먼 법칙) (2) | 2024.12.15 |
| 객체지향 프로그래밍의 핵심: 추상화란 무엇인가? (0) | 2024.12.15 |
| 객체지향 프로그래밍에서 클래스(Class)와 객체(Object): 핵심 개념 이해하기 (1) | 2024.12.14 |