🚗⚠️자동차 기능 안전 표준, ISO 26262 한 번에 정리하기

자동차 전자제어 장치(ECU) 개발을 하다 보면
“이거 ISO 26262 맞춰야 합니다”라는 말을 자주 듣게 됩니다.

하지만 막상 표준 문서를 펼쳐 보면 용어도 복잡하고,
어디서부터 어떻게 적용해야 할지 감이 잘 안 오죠.

이 글에서는 개발자 입장에서 ISO 26262를 어떻게 이해하고 적용하면 되는지를
가능한 쉬운 언어로 정리해 보겠습니다.
(예시는 카메라 ECU / TDA4VM 같은 SoC 기반 시스템을 기준으로 설명합니다.)

---

1. ISO 26262는 뭘 하자는 규격인가?

한 줄로 요약하면:

“자동차에서 사용하는 전기전자(E/E) 시스템이 고장 나더라도
사람을 다치게 하지 않도록 개발해라.”

특징을 몇 가지로 정리하면:

• 대상: 양산 차량에 들어가는 전기/전자 시스템(ECU, 센서, 액추에이터 등)
• 관점: “기능 안전(Functional Safety)” – 기능이 잘못 동작해서 위험을 만들지 않게
• 방법: 기획부터 폐차 시점까지 전체 라이프사이클에 걸쳐
  위험 분석 → 요구사항 → 설계 → 구현 → 검증을 체계적으로 수행

즉, “버그 줄입시다” 정도가 아니라,
“사고(인명 피해)를 줄이기 위한 체계적인 개발 프로세스”에 대한 표준입니다.

---

2. 세 가지 핵심 키워드: HARA, ASIL, Safety Goal

2.1 HARA (Hazard Analysis and Risk Assessment)

먼저 “어떤 상황에서 어떤 위험이 생길 수 있는지”를 분석합니다.

예: 전방 카메라 ECU라면

• 고속 주행 중 카메라 영상이 멈춘다
• 차선 인식이 틀어져서 차량이 잘못 조향된다
• 야간/우천 시 영상이 너무 어둡게 출력되어 장애물을 인지 못한다

각 위험에 대해 세 가지를 평가합니다.

• S (Severity): 사고가 나면 얼마나 심각한가 (사망, 중상, 경상…)
• E (Exposure): 그런 상황이 얼마나 자주 발생하는가
  (고속도로 주행 vs 특수 상황 등)
• C (Controllability): 운전자가 그 상황을 스스로 회피할 수 있는가

이 조합으로 위험도를 계산하고, 그 결과로 ASIL 등급을 정합니다.

---

2.2 ASIL (Automotive Safety Integrity Level)

ASIL은 A ~ D 네 단계 + QM 이 있습니다.

• ASIL D: 가장 엄격, 생명에 직결될 수 있는 시스템
• ASIL C/B: ADAS, 제동 보조 등 꽤 중요한 기능
• ASIL A: 비교적 낮은 위험이지만 여전히 안전 요구가 있는 기능
• QM (Quality Management): 일반 품질 관리 수준이면 충분

쉽게 말해:

ASIL이 높을수록
“더 많은 분석·문서·테스트·이중화”가 필요합니다.

예를 들어,

• 주차용 서라운드뷰 시스템 → 보통 QM ~ ASIL B
• 주행 중 차선 유지 보조용 카메라 → ASIL B ~ C 정도를 목표로 잡는 경우가 많습니다.

---

2.3 Safety Goal (최상위 안전 목표)

HARA와 ASIL 분석을 통해,
“이 시스템이 반드시 지켜야 하는 최상위 안전 목표”를 정리합니다.

예를 들어:

• “카메라 영상이 신뢰할 수 없는 상태가 되었을 때,
  운전자에게 명확한 경고를 제공해 오판을 막는다.”
• “ADAS 기능에 잘못된 카메라 데이터를 전달하지 않는다.”

이 Safety Goal이 이후 단계에서
시스템 요구사항 → HW 요구사항 → SW 요구사항으로 쪼개져 내려갑니다.

---

3. ISO 26262 개발 V-모델: 시스템 → HW → SW

ISO 26262는 전형적인 V-모델 구조를 사용합니다.

3.1 시스템 레벨

• 아이템 정의(ECU가 하는 일, 인터페이스, 운전 시나리오 정리)
• HARA/ASIL 분석, Safety Goal 정의
• 시스템 아키텍처 설계
  • 예: TDA4VM SoC + PMIC + 카메라 센서 + 통신(CAN/Ethernet) + 디스플레이
• 시스템 안전 요구사항 정의
  • 예:
    • “카메라 고장 발생 시 500ms 이내에 운전자에게 경고 표시”
    • “센서 또는 링크 고장 시 ADAS ECU에 DTC 전송”

3.2 하드웨어 레벨

하드웨어 입장에서 “고장이 나도 안전하게” 만들기 위한 활동입니다.

• 고장 모드 분석(FMEA, FMEDA)
  • 어떤 부품이 어떻게 고장 날 수 있는지, 그때 무슨 일이 생기는지 정리
  • 진단 메커니즘(모니터 회로, 이중화, self-test 등) 설계
• 안전 관련 HW 메커니즘
  • 이중 전원, safety PMIC, watchdog, lockstep CPU, ECC 메모리 등
• 결과적으로 ASIL 목표에 맞는 고장률·진단 커버리지를 맞춰야 합니다.

TDA4VM 같은 SoC는 이미 기능 안전을 고려한 하드웨어 블록(ECC, lockstep, safety MCU 등)을 제공하므로,
이걸 어떻게 활성화해서 ECU 설계에 녹였는지를 설명할 수 있어야 합니다.

3.3 소프트웨어 레벨

개발자에게 가장 현실적으로 다가오는 부분입니다.

1. SW 안전 요구사항 정의
   • 시스템/하드웨어에서 내려온 안전 요구사항을
     소프트웨어 관점에서 구현 가능한 요구사항으로 변환합니다.
   예:
   • “I2C 통신 오류가 연속 N회 발생하면 카메라 스트리밍을 중단하고 경고 표시”
   • “프레임 시퀀스가 끊기면 오류 카운트를 증가시키고 DTC를 기록”
   • “주기적으로 watchdog을 kick하고, 정해진 시간 안에 동작하지 않으면 시스템 리셋”
2. 안전 메커니즘 구현
   • 입력값 검증, boundary check
   • 타임아웃, 재시도, 예외 처리
   • self-test, sanity check (예: 프레임 타임스탬프/해상도/포맷 확인)
   • fail-safe 모드 정의
     • 카메라 영상이 이상하면 → 화면 블랭크 + 경고 문구
     • ADAS 입력으로는 더 이상 사용하지 않게 플래그 설정
3. 코딩 규칙 / 정적 분석
   • C/C++: MISRA-C, CERT-C 등 코딩 규칙 적용
   • 정적 분석 도구 사용(누수, 오버플로우, NULL 포인터, 위험 패턴 탐지)
   • 코드 리뷰에서 안전 요구사항 만족 여부 확인
4. 테스트
   • 단위(Unit) 테스트: 함수/모듈 단위
   • 통합(Integration) 테스트: 카메라 드라이버 + ISP + 어플리케이션 레벨 결합
   • 시스템(System) 테스트: 실제 보드, 실제 센서, 실제 전원/온도/진동 환경에서 검증
   • 필요 시 HIL/SIL(시뮬레이터) 활용

ISO 26262는 단순히 “테스트 해라”가 아니라,
어떤 수준의 커버리지를 목표로 할지, 어떤 방법으로 안전 요구사항을 검증할지까지 계획하고 기록하라고 요구합니다.

---

4. ISO 26262에서 자주 나오는 산출물(문서)들

현실적으로 가장 부담스러운 부분이 바로 “문서 작업”입니다.
대표적으로 이런 것들이 있습니다.

• Item Definition 문서
• HARA 보고서 (위험 분석 결과)
• Safety Goal / Safety Requirement 리스트
• 시스템/소프트웨어 아키텍처 문서
• FMEA/FMEDA/FTA 결과
• 테스트 계획 / 테스트 케이스 / 테스트 리포트
• 코드 리뷰 기록, 정적 분석 리포트
• 변경 관리/이슈 관리 내역
• 최종 Safety Case (우리가 ASIL X를 만족한다는 근거 모음집)

모두를 완벽하게 갖추는 게 이상적이지만,
프리랜서나 초기 프로젝트 단계에서는 가볍게라도 최소 세 가지는 꼭 남기는 게 좋습니다.

1. HARA + Safety Goal 요약
2. 안전 요구사항 목록(시스템 + SW)
3. 테스트 케이스 및 결과 리포트

이 세 가지가 있으면, 나중에 OEM/1차 협력사와 협업할 때도
“안전 관점에서 어느 정도 생각하고 설계했다”는 걸 보여 줄 수 있습니다.

---

5. 카메라 ECU 예제로 보는 ISO 26262 적용 포인트

TDA4VM + 카메라 센서 기반 ECU를 예로 들면,
ISO 26262 관점에서 신경 쓸 만한 체크 포인트를 정리해 보면:

1. 기능 정의 & 위험 분석
   • 어떤 주행 상황에서 카메라가 어떤 역할을 하는지
   • 고장 시 어떤 위험으로 이어지는지 (주차 vs 고속 주행 등)
2. 고장 탐지 & Fail-safe 전략
   • I2C/CSI 오류, 센서 리셋 실패, 프레임 드롭 등을 어떻게 감지할지
   • 감지 후:
     • 운전자 경고 표시
     • ADAS 기능 일시 중단
     • 로그/DTC 저장
3. 하드웨어 안전 기능 활용
   • TDA4VM의 ECC, lockstep, watchdog, PMIC 모니터 등을 어떤 경로로 연결할지
   • 전원/온도 이상 시 어떤 방식으로 시스템을 보호할지
4. 소프트웨어 품질 활동
   • 코딩 규칙 적용, 코드 리뷰, 정적 분석
   • 단위/통합/시스템 테스트, 장시간 런닝 테스트
   • Git 기반 변경 이력 관리, 이슈 트래킹
5. 문서화
   • 최소한 HARA 요약 + 안전 요구사항 + 테스트 리포트는 프로젝트 내 docs/에 정리
   • 후속 프로젝트(다른 센서, 다른 ECU)에서 그대로 재사용 가능하게 구조화

---

6. 프리랜서/개발자 입장에서 현실적으로 어떻게 접근할까?

ISO 26262를 100% 충족하려면
조직 차원의 프로세스(ASPICE, 품질 시스템 등)가 필요해서
개인 단위로는 사실상 어렵습니다.

그래도 다음 네 가지만 지켜도 “안전 관점에서 생각하고 있다”는 걸 충분히 보여 줄 수 있습니다.

1. 위험 시나리오 + Safety Goal 간단 정리
2. SW/HW 안전 요구사항 목록 작성
3. 안전 메커니즘 구현 (진단 + fail-safe)
4. 테스트/리뷰 기록을 남기는 습관

나중에 OEM나 1차 협력사와 협업할 때,
이 자료들을 기반으로 “더 공식적인 ISO 26262 프로세스”로 확장해 나갈 수 있습니다.

---

마치며

ISO 26262는 단순한 “규제”가 아니라,
“자동차 전자 시스템을 안전하게 만들기 위한 체크리스트 + 개발 방법론”에 가깝습니다.

처음에는 용어도 많고 문서도 많아서 부담스럽지만,

• HARA로 위험을 정리하고,
• ASIL에 맞는 수준의 안전 메커니즘과 테스트를 설계하고,
• 그 과정을 문서로 남긴다.

이 세 줄만 머릿속에 두고 프로젝트를 진행해 보면
생각보다 자연스럽게 ISO 26262 방식에 익숙해질 수 있습니다.

궁금한 부분이나 더 보고 싶은 내용이 있다면 댓글로 남겨 주세요.