ISO 26262 - Fault Injection Test (1)

안녕하세요, VPilot입니다!

 

VPilot에서는 자동차 시스템 및 SW 개발 과정에서 실제로 참고할 수 있는 산출물 예제와 작성 기준을 정리하고 있습니다.

 

요구사항, 아키텍처, 인터페이스, 검증 문서를 만들다 보면 “어떤 항목을 어떤 수준으로 작성해야 하는지”가 가장 막막할 때가 많습니다. VPilot은 그 막막함을 줄이기 위해, 현업 산출물에 가까운 구조와 예제를 제공합니다.

 

현재는 ASPICE와 ISO 26262를 중심으로 BMS, 자율주행, 조향 제어 시스템 예제를 제공하고 있으며, SOTIF, ISO 8800, 사이버보안까지 자동차 SW 실무에 필요한 주제로 계속 확장해가고 있습니다.

 

실무 문서 작성이나 포트폴리오 구성을 위해 참고할 수 있는 시스템·SW 산출물 예제를 찾고 있다면, 아래 VPilot 카테고리에서 확인해보세요.

 

'VPilot' 카테고리의 글 목록

---

ISO 26262를 다루다 보면 필연적으로 결함 주입 테스트(Fault Injection Test, FIT)라는 개념을 마주하게 됩니다.

 

많은 분들이 이를 단순히 "고장을 내보는 것" 정도로만 이해하거나, 어떻게 체계적으로 접근해야 할지 막막해하는 경우가 많습니다.

간단하게 설명해보자면 FIT는 다음 질문에 가장 정면으로 답하는 테스트입니다.

 

“고장이 실제로 발생했을 때, 시스템이 의도한 대로 검출하고, 통제하고, 안전 상태로 이행하는가?”

 

정상 테스트가 “잘 동작함”을 보여준다면, FIT는 “망가졌을 때도 안전함”을 보여줍니다.

---

FIT의 본질

---

FIT는 시스템을 일반적인 상황이 아닌, 비정상적이고 스트레스를 주는 상황에 강제로 노출시켜 작동을 확인하는 기법입니다. 과거에는 주로 하드웨어 고장을 시뮬레이션하는 것에서 시작했지만, 현재는 소프트웨어의 강건성(Robustness) 테스트의 일부로 그 범위가 확장되었습니다.

 

ISO 26262 표준에는 이 테스트를 명시적으로 정의하고 가이드라인을 제공하고 있는데, FIT는 결국 ‘Fault가 Error로 활성화되는 순간’을 안전 메커니즘이 잡아내는지 보는 테스트이기 때문에, 아래 용어 구분이 중요합니다.

ISO 26262-10:2018(E) : 4.3.1 Figure 5

 

(단순히 용어를 설명하기 위한 그림이 아니지만, 지금은 Fault - Error - Failure로 전개된다는 사실과 용어 정의만 기억해주세요.)

 

• 결함 (Fault): 시스템 실패를 유발하는 근본 원인이나 비정상적인 조건 (예: 코드 버그, 물리적 손상)
• 오류 (Error) : Fault가 활성화되어 시스템 내부의 데이터나 상태가 틀어진 것 (안전 메커니즘의 탐지 대상)
• 고장 (Failure): Error가 통제되지 않고 외부로 전파되어, 시스템이 기능을 수행하지 못하는 최종 결과

일반적으로 회사에서는 프로세스와 설계 검토를 통해 시스템적인 결함을 예방하려고 노력하지만, 완벽할 수는 없습니다. 여기에 더해 운영 중 발생하는 우발적 결함을 막기 위해 안전 메커니즘(Safety Mechanism)을 탑재하는데, FIT의 핵심 목표는 바로 이 안전 메커니즘이 의도한 대로 결함을 탐지하고 방어하는지를 검증하는 것입니다.

---

FIT가 필요한 이유

---

한 문장으로 정리하자면 "정상 조건 테스트만으로는 ‘안전 경로’를 거의 못 탄다" 라고 할 수 있습니다. 안전 관련 로직은 대부분 “이상 상황에서만” 실행되기 떄문입니다.

• watchdog 리셋 트리거
• 통신 타임아웃 진단
• 센서 값 이상 처리
• 메모리 무결성 오류 처리
• 안전 제한 동작(토크 제한, 기능 비활성화, Fail-Safe 등)

정상  테스트를 아무리 열심히 해도, 이런 경로는 시험에서 거의 실행되지 않습니다.그래서 FIT가 필요합니다. 강제로 이상 상황을 만들지 않으면 안전 메커니즘은 영원히 “시험되지 않은 코드”로 남게 됩니다.

---

FIT의 핵심 목적

---

단순히 에러를 발생시키는 것이 아니라, 다음과 같은 명확한 목적을 가지고 수행해야 합니다.

1. 결함 탐지 능력 검증: 시스템이 주입된 결함을 얼마나 잘 탐지하는지 확인
2. 미탐지 결함 식별: 여전히 탐지되지 않고 남는 결함이 무엇인지 파악하여, 시스템을 개선할지 혹은 리스크를 수용할지 결정
3. 테스트 커버리지 확대: 정상적인 동작 시나리오에서는 실행되지 않는 방어 코드(예: 예외 처리 루틴)를 강제로 실행시켜 테스트 커버리지를 높임
4. 안전 메커니즘의 유효성 확인: 설계된 안전 장치가 실제로 효과가 있는지 증명

---

이어서

---

FIT는 “언제, 어디서, 무엇을 주입할 것인가”가 핵심입니다. 다음 글에서는 개발 단계를 소프트웨어 기준의 소프트웨어 단위 레벨, 통합 레벨 및 기능 레벨에서의 결함 주입 테스트로 나누어 각 단계에서 어떤 결함을 주입하고 무엇을 증명해야 하는지 정리하겠습니다.

---

본 포스팅에서 다룬 내용 외에 추가로 궁금하신 점이 있으면, 여러 시스템 및 소프트웨어 레벨의 예제도 있으니 아래 링크를 참조해주세요.

• 배터리 관리 시스템
• 자율주행 시스템
• 조향 제어 시스템

VPilot 카테고리 - 시스템·SW 예제 모음