고장 영향 및 심각도 분석 (FMECA)는 고장 분석을 위해 수행하는 체계적인 기술 중에 하나로 미 국방성에서 개발하였다. FMECA는 시스템 개발 초기 단계에서 가장 많이 신뢰성 분석 기술에 사용되고 있으며 일반적으로 개념 또는 초기 설계 단계에 수행되는데 가능성 있는 모든 고장 유형을 확인하고 적절한 조치를 취하여 고장을 줄이도록 한다.
이에 대한 첫 번째 가이드라인은 미 국방 표준인 1949년 9월에 제정된 MIL-P-1629 “Procedures for Performing a Failure Mode, Effects and Criticality Analysis”이며 1960년대 NASA (National Aeronautics and Space Administration)에서 아폴로 미션 기간 중 우주 프로그램 하드웨어의 신뢰성을 향상시키고 검증하기 위해 처음 개발, 적용되었다.
1980년 폐기된 MIL-STD-785B, "Reliability Program for System and Equipment Development and Production", 에서 장비나 시스템에서 FMECA를 수행하기 위한 절차를 정의하였고 역시 이미 폐기된 MIL-STD-1629A는 FMECA를 수행하기 위한 요구사항과 절차를 수립하기 위한 국방 표준이다. MIL-STD-1629A에는 고장 유형 분석을 함으로써 임무성공이나 개인과 시스템 안정성, 유지보수와 시스템 성능상의 기능이나 하드웨어 고장이 발생할 수 있는 잠재적인 영향을 분석하고 문서화하는 것이 포함되어 있다.
각 잠재 고장은 이를 교정하기 위한 활동이 설계 위험을 제거하거나 통제할 있도록 그 영향의 심각도를 등급화 한다. 비록 MIL-STD-1629A는 폐기되었으나 이 표준에서 기술한 개념은 모든 중요 시스템(Critical System)과 국방 및 민수 산업 시스템 뿐 아니라 MIL-STD-1629A에서 사용한 기술은 어떠한 전자, 기계 장비나 시스템에도 이들을 개발하는 단계 동안 적용가능하다.
초기 FMECA는 FMEA(Failure Modes and Effect Analysis)라 불렸으며 지금은 FMEA의 확장된 개념으로 FMEA와 심각도 분석(CA: Criticality Analysis)으로 구성된다. FMECA에서 “C”가 CA를 의미하며 이는 다양한 고장으로 인한 영향의 심각성(Criticality 또는 Severity) 또는 치명도를 고려하고 그 정도를 레벨로 표현한다. FMEA는 CA를 수행하기 전에 완료되어야하며 FMEA는 시스템과 하부시스템의 고장유형의 정량적 순위를 분석하여 보여주고 CA는 컴포넌트와 시스템과 연관된 신뢰성과 심각성을 분석한다.
1. FMECA 개념
시스템 설계자는 두 개의 시스템 속성, 즉 기능적 속성 (Functional Attributes) 와 물리적 속성 (Physical Attributes)가 주어지며 다음과 같은 내용을 인식하고 분석하여 시스템을 평가해야 한다.
- 발생될 수 있는 고장, 조치해야 하는 고장 유형과 예상되는 고장 빈도수
- 고장 원인과 결과, 고장이 시스템 전체에 미치는 영향
- 고장 예방 측도와 고장을 피할 수 있는 방법
이렇게 시스템을 분석 평가해야 하는 목적은 시스템이 임무를 수행하기 위해 발생할 수 있는 고장의 위험한 상태와 영향, 잠재하고 있는 안정성 문제, 고위험, 또는 시스템에서의 약한 고리를 인식하기 위함이다.
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
이러한 기본 정보의 분석 활동을 하는 과정에서 식별되는 위험을 인식하고 이를 교정하는 활동들을 순위화하는 방법들이 포함되는데 이러한 방법에 RPN (Risk PriorityNumbers)과 Criticality Analysis (FMEA with Criticality Analysis = FMECA)가 있는 것이다.
* RPN(Risk Priority Numbers)
위험을 평가하기 위해 RPN(Risk Priority Number, 위험순위번호)을 위해서 다음과 같은 값이 먼저 평가되어야 한다.
- 각 고장 영향도의 심각도를 평가한다.
- 각 고장 발생할 수 있는 가능성을 평가한다.
- 각 고장 원인을 사전에 발견할 수 가능성에 대해 평가한다.(즉 최종사용자나 고객이 문제를 발견하기 전에 문제를 발견할 수 있는 가능성)
상기 값을 이용하여 RPN을 계산한다.
RPN = Severity x Occurrence x Detection
이렇게 계산된 RPN은 문제 분석과 교정 활동에 대한 우선순위를 통해 이슈를 비교하는데 활용할 수 있다.
* Criticality Analysis (CA: 심각도 분석)
국방 표준 MIL-STD-1629A에는 정량적, 정성적 두 가지 형태의 심각도 분석을 기술하고 있다.
정량적 심각도 분석을 하기 위해서는,
- 주어진 운영시간에 각 부품에 대해 신뢰성 유무를 정의한다.
- 잠재적인 고장 유형으로 인한 신뢰성 없는 부품을 식별한다.
- 각 고장 유형의 결과로 발생할 수 있는 손실(또는 심각성) 확률을 평가한다.
- 제품의 세 가지 요소를 사용하여 잠재적인 고장 유형에 대한 심각도를 계산한다.
Mode Criticality = Item Unreliability * Mode Ratio of Unreliability * Probability of Loss
- 각 고장 유형에 대한 심각도를 합하여 각 부품에 대한 심각도를 계산한다.
Item Criticality = SUM of Mode Criticalities
정성적 심각도 분석은 위험을 평가하고 교정 활동을 순위화한다. 이를 위해서는,
- 잠재적인 고장에 대한 영향의 심각성을 평가한다.
- 잠재적인 고장 유형에 대한 발생 가능성을 평가한다.
- 심각도 매트릭스(Criticality Matrix)를 이용하여 고장 유형을 비교한다. 심각도 매트릭스는 x축에 심각도를, y축에는 발생 확률을 표시한다.
2. FMECA 절차
FMECA는 FMEA와 심각도 분석(CA: Criticality Analysis)으로 구성되어 있으며, FMEA는 CA를 수행하기 전에 완료되어야한다. FMEA는 시스템과 하부시스템의 고장유형의 정량적 순위를 분석하여 보여주고 CA는 컴포넌트와 시스템과 연관된 신뢰성과 심각도를 분석하여 보여준다. FMECA는 기능적 속성과 물리적 속성 모두에 적용할 수 있다.
 |
| 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)은 시스템의 특정 기능이 고장으로 실행되는 형태를 말한다.
(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까지 정량적으로 표시한다. 심각도는 안전성 이슈 또는 고객의 불만족도와 연관되어 결정할 수 있다.
 |
| 고장 심각도 |
시스템 내에 있는 기능이나 컴포넌트가 다양한 방법으로 고장 발생이 주어진다면 이번 단계에서는 각각의 고장 유형의 발생 빈도를 확인한다. 시스템 요소의 모든 고장 빈도의 합이 시스템 고장 비율과 같아야만 한다. 정량화 목적을 위해 1에서 10까지 범위에서 등급화한다.
 |
| 고장 발생 빈도 |
(10) 고장 모드 발견 확률 등급화 (Rating of Failure Mode Detection Probability)
고장 모드 발견 확률 등급화는 프로세스 통제, 설계 형태, 검증 절차 등이 주요 시스템 재해를 막기 위한 적절한 시기에 잠재적인 고장을 발견할 수 있는 것과 연관이 있다. 프로세스에 적용하기 위해서 고장 모드 발견 확률 등급화는 고장 영향이 후속 프로세스나 최종 소비자, 사용자에게 전달되기 전에 프로세스 통제를 하는 현재 지점에서 고장 발견 및 검증을 할 수 있는 위치가 되는 확률을 참조하는 것이다. 고장 유형 발견 확률 순위 또한 정량화 표기를 위해 1부터 10까지의 수를 사용한다.
 |
| 고장 발견 확률 |
(11) 고장 모드 심각도 분석 (Analysis of Failure Mode Criticality)
고장 모드 심각도 분석의 목적은 시스템 설계의 심각한 상황을 기술하기 위해 이전 단계의 결과를 반영하는 것이다. 위험도는 심각도, 빈도, 발견 확률 기능으로 볼 수 있고 RPN(Risk Priority Number, 위험 우선순위번호)으로 환산하여 표기할 수 있다. RPN은 다음과 같은 식으로 결정한다.
RPN = (severity rating)(frequency rating)(probability of detection rating)
(12) 제품/프로세스 향상을 위한 제언 (Initiation of Recommendations for Product/Process Improvement)
마지막 단계는 RPN의 영역으로 식별되는 반복적인 프로세스나 그 원인에 대한 평가, 제품/프로세스 향상을 위한 제언으로 후속 조치를 하는 것이다. FMECA는 시스템 개발 주기를 통해 반복적으로 적용하는 설계 변경에 적절한 방법이다. 또한 문서화가 잘되어 있는 FMECA는 일단 시스템이 운영되면 유지보수나 고장수리를 지원한다. FTA와 연관되어 있는 FMECA는 위험요소 분석(Hazard Analysis)을 수행하기에 효과적인 접근방법이다. FMECA의 결과는 FTA에서 필요로 하는 모든 “바람직하지 않은(undesirable)" 시스템 레벨 이벤트를 식별하는 FTA의 적합한 입력으로 지원된다.
3. 소프트웨어 FMECA
소프트웨어 FMECA는 하드웨어나 시스템 FMECA와 같은 절차를 따르고 있으며 소프트웨어 FMECA의 장점중의 하나는 시스템 레벨의 FMECA와 통합 할 수 있다는 것이다. 하드웨어 FMECA와 같이 소프트웨어 FMECA도 설계 결함을 식별하는 것으로 개발 수명 주기 전 과정에 걸쳐 반복적으로 사용할 수 있다. 소프트웨어 FMECA의 결과는 소프트웨어 FTA의 입력이 될 수 있다.
소프트웨어 FMECA의 일반적인 절차는,
- 소프트웨어를 기능(Function)이나 타스크(Task)와 같은 논리적인 컴포넌트로 분리한다.
- 각 컴포넌트에 대한 고장 유형을 정한다.(예를 들어 “software fails to respond” or “software responds with wrong value”)
- 고장 유형 테이블을 사용하여, 워크시트에 고장유형을 채운다.
- 각 고장 유형에 대한 모든 원인과 상위 레벨에 대한 영향을 결정한다.
- 고장 비율을 지정한다; 발생율, 심각도, 탐색 값, RPN
- 구현되어야 되고 이미 구현된 모든 교정 활동(CA: Corrective Actions)과 오픈된 모든 부품을 정의한다.
4. FMEA 유형
* CFMEA (Concept FMEA)
- CFMEA는 시스템 개발 초기 개념 단계에서 사용한다.
- 제안된 기능과 연관된 잠재적인 고장 모드에 중점을 둔다.
- 개념 단계에서 시스템 구성 요소나 시스템 사이의 상호 작용 등을 분석한다.
* DFMEA (Design FMEA)
- 제품 출시 전에 제품을 분석하는데 사용한다.
- 설계 결함으로 인해 발생할 수 있는 제품의 잠재적인 고장 모드에 중점을 둔다.
- 시스템, 하위 시스템, 컴포넌트 등 세개의 레벨에 적용한다.
- 하드웨어, 소프트웨어, 기능 또는 결함 시스템을 분석하는데 사용한다.
* PFMEA (Process FMEA)
- 시스템, 하위 시스템, 컴포넌트 레벨에서 개발 프로세스를 분석하는데 사용한다.
- 개발 프로세스 결함에 의해 발생하는 프로세스의 잠재적인 고장 모드에 중덤을 둔 방법으로, 시스템이 개발 운영 되기 전에 프로세스 문제를 식별하고 수정하고자 하는 것이다. PFMEA는 초기 프로세스 설계 단계에서 가장 큰 영향력을 갖는다. 각 프로세스의 변화에 대해 잠재적인 고장 모드를 식별/분석해야만 한다.
 |
| FMEA 유형 |
5. FMECA/FMEA 장점
* FMEA/FMECA 공통 장점
- 예방 계획
- 요구사항 변경 식별
- 제품 개발 기간 및 비용 절감
- 보장 비용 및 낭비 비용 감소
- 불필요한 운영 작업 감 소
* Concept FMEA
- 최적의 개념 선택이나 설계 명세서 변경 결정을 지원한다.
- 잠재적인 고장 모드가 개념 단계에서의 상호작용에 기인한 것인지 식별한다.
- 시스템 레벨의 시험 요구사항을 식별한다.
* Design FMEA
- 설계 요구사항과 대체 설계의 객관적인 평가를 지원한다.
- 개발 초기 잠재적 고장 모드의 확인이 용이하다.
- 잠재적인 고장 모드와 설계/개발 프로세스에 미치는 영향의 예측 가능성을 배가시킨다.
- 철저하고 효과적인 시험 프로그램을 계획할 수 있도록 부가적인 정보를 제공한다.
- 고객의 영향에 따라 등급화된 잠재적 고장 모드 목록을 개발한다. 설계 향상을 위해 상위 시스템을 먼저 설계한다.
- 위험 활동을 감소시키기 위한 추천이나 위험을 추적하기 위한 이슈 양식 등 문서화
- 중요 관리 특성을 확인하는데 용이하다.
* Process FMEA
- 프로세스 고장 모드와 연관된 잠재적인 제품을 식별한다.
- 고객의 잠재 고장 영향도를 평가한다.
- 잠재적인 개발 프로세스 원인을 식별하고 통제나 모니터링에 초점을 두는 프로세스를 식별한다.
- 교정 활동을 위한 우선 순위의 시스템을 설치하고 잠재적인 고장 모드 목록을 개발한다.
- 불완전한 프로세스를 식별한다.
- 확인된 중대하고 심각한 특징을 식별한다.
- 설계 변경에 대한 정보나 설계자에게 타당한 피드백을 제공한다.