제8부 자율주행

8.8 기능안전 I — ISO 26262·ASIL 기초

8.8.1 이 장에서 배우는 것 / 선수 지식

8.1~8.7에서 "이것이 안전의 토대다"를 반복했다 — 결정성(8.6)·격리(FFI)·하드웨어 안전 기능(락스텝, 8.2)·중복화. 이제 그 기능안전 자체를 판다. 자동차 전자/전기(E/E) 시스템의 기능안전 표준은 ISO 26262 이고, 그 핵심은 ASIL(자동차 안전 무결성 수준) 이다. 기능안전(95~98) 4부작의 시작 — 이 장은 안전 생명주기·위험 분석(HARA)·ASIL·안전 목표·요구사항 캐스케이드의 기초를 세운다.

핵심 통찰: 기능안전은 "테스트 하나"가 아니라 "위험을 체계적으로 줄이는 공학 규율(프로세스)" 이다. 위험을 식별하고(HARA), 그 심각도로 엄격도(ASIL)를 정하고, 안전 목표를 세우고, 요구사항으로 캐스케이드하고, 안전 메커니즘(8.9)으로 충족하고, 전 과정을 검증·인증한다. 그리고 정직하게: 기능안전은 "오작동(malfunction)"을 다루지, "의도된 기능의 한계"는 SOTIF(8.10)·AI 안전(8.11)이 다룬다 — 둘 다 필요하다.

배우는 것:

ISO 26262·기능안전이 무엇인가 — E/E 오작동으로 인한 위험의 부재, 안전 생명주기(V 모델).
HARA — 위험 분석·위험 평가, S(심각도)·E(노출)·C(제어성) 로 위험 평가.
ASIL — QM·A·B·C·D, S·E·C로 결정, 높을수록 엄격.
안전 목표·요구사항 캐스케이드 — 안전 목표 → 기능/기술/HW·SW 안전 요구.
칩·OS의 역할 — DRIVE SoC·OS의 안전 기능이 ASIL 안전 케이스를 받치는 "안전 요소"(SEooC).
정직성 — 기능안전은 필요하나 충분하지 않다(SOTIF·AI 안전 보완), 자격 있는 엔지니어·인증의 영역.

선수 지식: 8.1(safety-critical·레벨)·8.2(락스텝·안전 섬)·8.6(결정성·FFI 안전 토대). 안전 메커니즘은 8.9, SOTIF는 8.10, AI 인지 안전은 8.11. 환경은 자동차 안전 공학.

정직(중요): 자율주행은 safety-critical이고 기능안전은 엄격한 표준·인증·자격 있는 엔지니어의 영역이다. 이 장은 개념·용어·사고 틀을 가르치되, 실제 안전 케이스·ASIL 결정·인증은 자격 있는 기능안전 엔지니어가 표준(ISO 26262)·검증으로 수행한다 — 이 책으로 안전 시스템을 설계·인증할 수 없다. 또 제품이 "ASIL D 인증"이라는 주장은 구성·시점 의존이라 "확인 필요"로 다룬다(BK-04).

8.8.2 기능안전이란 — 오작동으로 인한 위험

ISO 26262(자동차 기능안전 표준)의 정의 핵심:

핵심 구분(정직성):

기능안전(ISO 26262): 오작동·고장으로 인한 위험 — 하드웨어 랜덤 고장, SW 체계적 오류. "시스템이 고장나면 안전한가?"
SOTIF(ISO 21448, 8.10): 고장이 없어도 의도된 기능의 한계로 인한 위험 — 인지가 엣지케이스를 못 다룸. "시스템이 정상 동작해도 충분한가?"
AI 안전(8.11): 학습 기반 인지의 보증.

이 셋은 다른 위험을 다루며 모두 필요하다 — 기능안전만으로 자율주행이 안전하지 않다(SOTIF·AI 안전 보완). 이 장은 기능안전(오작동).

핵심: 기능안전은 "고장났을 때 안전한가" 를 체계적으로 보장한다. 자율주행은 사람 목숨이 걸려, E/E 오작동(센서·컴퓨트·SW)이 사고로 이어지지 않도록 — 그것이 ISO 26262의 영역. 단 이것이 안전의 전부가 아님(SOTIF·AI)을 처음부터 분명히.

8.8.3 안전 생명주기 — 프로세스 규율

ISO 26262는 안전 생명주기(V 모델)를 정의한다 — 안전은 단일 시험이 아니라 개발 전 과정의 규율이다:

각 단계가 안전 요구·검증·근거(work product)를 남긴다.

프로세스가 핵심: 안전은 "잘 만들어서 테스트 통과"가 아니라 요구·설계·구현·검증의 추적 가능한 규율 — 각 단계의 산출물(work product)이 안전 케이스를 구성.
V 모델: 왼쪽(요구·설계 분해) ↔ 오른쪽(검증·통합)이 대응 — 각 요구가 검증으로 닫힘.
추적성: 안전 목표 → 요구 → 설계 → 구현 → 검증이 추적 가능해야(7.7 lineage의 안전판).

핵심: 기능안전은 "무엇을·어떻게·왜 안전한가를 추적 가능하게 입증하는 프로세스" 다 — 좋은 코드·테스트만이 아니라 체계적 위험 분석·요구·검증·근거. 사후에 못 붙인다(8.1·8.6 반복) — 개념 단계부터.

8.8.4 HARA — 위험 분석·평가

안전 생명주기의 출발은 HARA(Hazard Analysis and Risk Assessment) — 위험한 사건을 식별하고 평가한다.

세 축의 의미:

S(심각도): 그 사건이 일어나면 얼마나 다치나(경상~사망). 높을수록 위험.
E(노출): 그 위험 상황이 얼마나 자주·확률적으로 발생하나(드문 상황 vs 흔한 주행). 높을수록 위험.
C(제어성): 사람이 그 상황을 회피·통제할 수 있나(쉽게 회피 vs 통제 불가). 통제 어려울수록 위험.

핵심: HARA는 "무엇이 위험하고 얼마나 위험한가" 를 체계적으로 따진다 — 막연한 "위험하다"가 아니라 S·E·C로 정량화해 ASIL(엄격도) 을 정한다. 이것이 안전 노력을 어디에 얼마나 투입할지를 결정하는 출발점. (실제 HARA는 자격 있는 엔지니어가 표준·전문성으로 수행.)

8.8.5 ASIL — 안전 무결성 수준

ASIL(Automotive Safety Integrity Level) 은 HARA의 S·E·C로 결정되는 안전 엄격도다:

QM~D: QM은 안전 요구 없음(일반 품질), A~D는 점점 엄격. D가 최고(가장 치명적 위험).
ASIL이 엄격도를 정함: 높은 ASIL은 더 엄격한 안전 메커니즘(8.9)·검증·문서·독립성·하드웨어 메트릭을 요구. 안전 노력이 위험에 비례.
ASIL 분해(decomposition): 높은 ASIL 요구를 독립적인 낮은 ASIL 요구들로 분해 가능(예: ASIL D = ASIL B(D) + ASIL B(D), 충분한 독립성 하에 — 분해된 양쪽 모두 원본 D 출처를 (D)로 표기) — 중복화·다양성(8.9)의 근거.

핵심: ASIL은 "이 위험에 얼마나 엄격하게 대응할까" 를 정한다 — 치명적·흔한·통제 불가 위험(제동·조향)은 ASIL D로 최대 엄격, 사소한 것은 QM. 자율주행의 핵심 인지·제어 기능은 보통 높은 ASIL → 그것이 결정성(8.6)·중복화(8.9)·하드웨어 안전(8.2)의 엄격도를 정한다. ASIL이 모든 안전 노력의 척도.

8.8.6 안전 목표·요구사항 캐스케이드

HARA·ASIL에서 안전 목표가 나오고, 그것이 요구사항으로 캐스케이드된다:

안전 목표: 위험을 막는 최상위 목표(ASIL 동반). HARA의 각 위험 사건마다.
캐스케이드: 안전 목표 → 기능 → 기술 → HW·SW 요구로 점점 구체화, 추적 가능하게.
충족 수단 = 안전 메커니즘(8.9): 락스텝·워치독·ECC·중복화·플로지빌리티 체크 등이 요구를 충족.

핵심: 안전은 "위험(HARA) → ASIL → 안전 목표 → 요구 캐스케이드 → 안전 메커니즘 → 검증" 의 사슬이다. 각 고리가 추적 가능하고 ASIL 엄격도에 맞아야 — 그래야 안전 케이스가 성립. 8.2(락스텝)·8.6(FFI·결정성)·8.9(메커니즘)이 이 사슬의 하부에서 요구를 충족.

8.8.7 칩·OS의 역할 — 안전 요소

DRIVE SoC·DRIVE OS는 OEM의 안전 케이스를 받치는 "안전 요소" 다:

SEooC: 칩·OS는 차량을 모른 채 개발되므로, 안전 가정·요구를 명시한 문서(안전 매뉴얼) 와 함께 제공 — OEM이 자기 맥락에서 안전 케이스에 통합.
ASIL 지원: DRIVE 하드웨어·OS는 높은 ASIL을 지원하도록 설계(락스텝·안전 섬·FFI). 단 "ASIL D 인증"의 정확한 범위는 구성·시점 의존(확인 필요).
OEM 책임: 전체 차량의 안전 케이스·인증은 OEM이 — 칩·OS는 그 요소.

정직: "DRIVE가 ASIL D 인증"이라는 단정은 조심해야 한다 — 무엇이·어느 구성에서·어느 범위로 인증되는지는 시점·구성 의존이고, 전체 시스템 안전은 OEM의 안전 케이스다. 칩·OS는 안전 요소(SEooC)로서 안전 가정·메트릭을 제공해 OEM이 통합·검증하게 한다. 실제 인증·안전 케이스는 자격 있는 엔지니어·표준의 영역.

8.8.8 중간 점검 (체크포인트)

[ ] 기능안전(ISO 26262)이 E/E 오작동으로 인한 위험을 다루며, SOTIF(8.10)·AI 안전(8.11)과 다른 영역(보완)임을 안다.
[ ] 안전이 프로세스 규율(안전 생명주기·V 모델·추적성)이지 단일 테스트가 아님을 안다.
[ ] HARA의 S·E·C로 위험을 평가하고, 그것이 ASIL(QM·A~D) 을 결정함을 안다.
[ ] 안전 목표 → 요구 캐스케이드 → 안전 메커니즘(8.9) 의 추적 가능한 사슬을 안다.
[ ] 칩·OS가 안전 요소(SEooC) 로 OEM 안전 케이스를 받침과, 인증 주장의 신중함을 안다.
[ ] 기능안전이 필요하나 충분하지 않음(SOTIF·AI), 자격 있는 엔지니어·표준의 영역임을 안다.

증상→의심: "테스트 통과니 안전" → 프로세스·추적성·HARA 없음 → 안전 생명주기. 위험을 막연히 평가 → S·E·C·ASIL 없음 → HARA. 안전 메커니즘이 위험에 안 맞음 → ASIL·요구 캐스케이드 누락. 오작동만 막고 인지 한계 무시 → SOTIF(8.10)·AI 안전(8.11) 필요. "칩이 ASIL D니 끝" → SEooC·OEM 안전 케이스·구성 의존 확인. 안전을 사후에 → 개념 단계부터(8.1·8.6).

8.8.9 트레이드오프·대안

결정	트레이드오프
높은 ASIL vs 낮은	안전 엄격·비용·복잡 vs 단순(위험에 비례)
ASIL 분해(중복) vs 단일 고ASIL	독립성·중복화 vs 단일 고무결성(8.9)
기능안전만 vs +SOTIF/AI	오작동만 vs 한계·인지까지(필요·둘 다)
SEooC(칩) vs 자체 개발	검증된 요소·통합 vs 완전 제어·부담

견해: ASIL은 위험에 비례한다 — 막연히 다 ASIL D로 하면 비용·복잡이 폭발, HARA로 위험을 평가해 적정 ASIL을 정한다. 높은 ASIL은 중복화·독립성(8.9)·하드웨어 안전(8.2)으로 충족. 그리고 기능안전만으로 부족 — SOTIF(8.10)·AI 안전(8.11)을 함께. 칩·OS는 안전 요소로 받치되 전체 안전 케이스는 OEM·자격 있는 엔지니어. 안전은 비용이 아니라 전제.

비엔비디아 정직: 기능안전은 업계 표준(ISO 26262) 이고 모든 자동차 E/E 공급자가 따른다 — NVIDIA만의 것이 아니다. DRIVE의 기여는 AI 컴퓨팅 SoC·OS가 안전 기능(락스텝·FFI)을 갖춰 ASIL을 지원하고 안전 요소(SEooC)로 제공하는 것. 실제 안전·인증은 표준·자격·검증의 영역이고, 인증 주장은 구성·시점 의존이라 신중히 확인. 이 책은 개념을 가르칠 뿐 안전 공학을 대체하지 않는다.

8.8.10 흔한 함정

안전을 단일 테스트로. 안전은 프로세스 규율(생명주기·HARA·요구·검증·추적성)이지 "테스트 통과"가 아님.
기능안전 = 안전 전부 오해. ISO 26262는 오작동만 — 의도된 기능 한계(SOTIF 8.10)·AI 인지(8.11)는 별개·필요.
위험을 막연히. S·E·C·ASIL 없이 "위험"을 다루면 노력 배분이 틀림 → HARA로 정량화.
모든 것을 ASIL D. 위험에 비례 안 하면 비용·복잡 폭발 → HARA로 적정 ASIL.
요구 추적성 누락. 안전 목표→요구→구현→검증이 추적 안 되면 안전 케이스 불성립.
"칩이 ASIL D니 시스템도 안전". 칩은 안전 요소(SEooC) — 전체 안전 케이스는 OEM, 구성 의존.
안전을 사후에. 개념 단계부터 — 사후 추가 불가(8.1·8.6).
이 책으로 안전 설계. 개념·용어를 배우되, 실제 안전은 자격 있는 엔지니어·표준·인증.

8.8.11 연습문제

연습 1 (기능안전 범위). ISO 26262 기능안전이 다루는 것과 다루지 않는 것을 구분하고, 자율주행 안전에 왜 SOTIF·AI 안전이 더 필요한지 설명하라.

정답

ISO 26262 기능안전이 다루는 것: E/E 시스템의 오작동(malfunction)으로 인한 위험 — 하드웨어 랜덤 고장(센서 고장·비트 오류·컴퓨트 결함)·소프트웨어 체계적 오류(버그)로 시스템이 잘못 동작해 발생하는 위험. "시스템이 고장나면 안전한가?" 다루지 않는 것: 고장이 없어도 의도된 기능의 한계로 인한 위험. 예: 인지 시스템이 정상 동작해도 안개·역광·처음 보는 객체를 못 인식하는 것 — 이것은 오작동이 아니라 기능의 한계(SOTIF, ISO 21448, 8.10). 또 학습 기반 AI 인지의 불확실성·검증(8.11). 왜 더 필요한가: 자율주행 사고의 상당수는 부품 고장(기능안전)이 아니라 인지가 상황을 충분히 다루지 못함(엣지케이스·롱테일)에서 온다 — 모든 부품이 정상 동작해도 인지가 보행자를 못 보면 사고. 기능안전(고장 안전)은 필요하지만 충분하지 않다 — SOTIF(의도 기능 한계)·AI 안전(학습 인지 보증)이 그 빈틈을 메운다. 셋은 다른 위험을 다루며 모두 필요. 자율주행 안전 = 기능안전 + SOTIF + AI 안전(+ 사이버보안 8.12).

연습 2 (HARA·ASIL). HARA의 S·E·C가 각각 무엇이고, 어떻게 ASIL을 결정하는지 설명하라. "고속 주행 중 의도치 않은 급제동" 위험은 대략 어느 정도 ASIL일지 추론하라.

정답

HARA의 세 축: S(Severity, 심각도) = 위험 사건이 일어나면 피해 정도(S0 없음~S3 치명적/사망). E(Exposure, 노출) = 그 위험 상황의 빈도·확률(E0~E4, 드문 상황 vs 흔한 주행). C(Controllability, 제어성) = 사람(운전자 등)이 그 상황을 회피·통제할 수 있나(C0 쉽게~C3 통제 불가). ASIL 결정: 세 축의 조합을 표준 표에 매핑 → 높은 S·E·C(치명적·흔함·통제 불가)일수록 높은 ASIL(QM<A<B<C<D). "고속 의도치 않은 급제동" 추론: S — 고속에서 급제동은 후방 추돌·통제 상실로 치명적 가능(S3 가능). E — 고속 주행은 흔한 상황(높은 E). C — 갑작스러운 급제동은 운전자·후방 차량이 회피 어려움(높은 C, 통제 곤란). 셋 다 높음 → 높은 ASIL, ASIL D 가능성. (정확한 ASIL은 자격 있는 엔지니어가 표준 표·구체 시나리오로 결정 — 이것은 개념적 추론.) ASIL D면 가장 엄격한 안전 요구·중복화·검증이 따라옴. 핵심: 위험을 막연히가 아니라 S·E·C로 정량화해 엄격도(ASIL)를 정하고, 그것이 안전 노력의 척도. 실제 HARA·ASIL은 전문 엔지니어의 영역.

연습 3 (캐스케이드). "고속 의도치 않은 급제동 방지"(ASIL D) 안전 목표가 어떻게 HW·SW 안전 요구로 캐스케이드되는지, 그리고 어느 하드웨어/OS 기능(8.2·8.6)이 충족하는지 예로 설명하라.

정답

캐스케이드: 안전 목표(ASIL D) "고속에서 의도치 않은 완전 제동을 방지" → 기능 안전 요구(FSR) "제동 명령의 타당성을 독립적으로 검증, 오류 시 안전 상태로" → 기술 안전 요구(TSR) "제동 컴퓨트를 이중화/락스텝으로 감시, 불일치 시 안전 상태 전환" → HW·SW 안전 요구 구체 메커니즘으로. 충족하는 기능(8.2·8.6): ① 락스텝 코어(8.2) — 안전 critical 컴퓨트를 두 코어가 동일 실행·비교, 불일치(결함) 탐지 → 제동 명령 오류 감지. ② 안전 섬(8.2) — 독립 안전 감시. ③ FFI 격리(하이퍼바이저, 8.6) — 비안전 결함이 제동 안전 기능에 전파 못 하게(공간·시간 격리). ④ ECC·워치독 — 메모리 오류 정정·행 탐지. ⑤ 결정성(RTOS, 8.6) — 안전 로직이 데드라인 안에 실행 보장. ⑥ 플로지빌리티 체크(8.9) — 제동 명령의 타당성 독립 검증. 각 요구가 안전 목표로 추적되고 검증으로 닫힘(V 모델). ASIL D라 중복화·독립성·엄격한 검증이 요구됨(8.9). 핵심: 위험(HARA)→ASIL→안전목표→요구 캐스케이드→안전 메커니즘(하드웨어·OS 기능)→검증의 추적 가능한 사슬. 8.2(하드웨어 안전)·8.6(결정성·FFI)이 하부에서 요구를 충족 — "안전의 토대"의 구체적 의미.

연습 4 (SEooC). "DRIVE SoC가 ASIL D 인증이니 우리 차도 ASIL D로 안전하다"는 주장을 비판적으로 검토하라.

정답

비판: ① 칩은 안전 요소(SEooC)이지 전체 시스템이 아니다 — DRIVE SoC·OS는 차량 맥락 없이 개발된 Safety Element out of Context로, 안전 가정·요구·메트릭을 명시한 안전 매뉴얼과 함께 제공된다. 차량 전체의 안전은 OEM이 자기 안전 케이스에 통합·검증해야 성립 — 칩이 안전 요소라고 차가 자동으로 안전한 것이 아님. ② 인증 범위·구성 의존 — "ASIL D 인증"이 정확히 무엇이·어느 구성에서·어느 범위로 인증됐는지 확인해야(특정 기능·구성에 한정될 수 있음, 시점 의존, 확인 필요). 막연한 "ASIL D"는 오해. ③ 칩 외 전부도 안전해야 — 센서·액추에이터·다른 ECU·통신·전체 아키텍처·소프트웨어·중복화(8.9)가 모두 안전 요구를 충족하고 통합 검증돼야. 약한 고리 하나가 안전을 무너뜨림. ④ 기능안전만으론 부족 — SOTIF(8.10)·AI 인지 안전(8.11)도 필요. 올바른 이해: 칩의 안전 기능(락스텝·FFI)은 OEM 안전 케이스를 받치는 요소이고, OEM이 안전 가정을 자기 맥락에 매핑·요구 충족·전체 통합·검증·인증해야 차가 안전. 안전은 칩이 아니라 전체 시스템의 안전 케이스(자격 있는 엔지니어·표준·인증). "칩이 ASIL D = 차가 안전"은 위험한 단순화.

연습 5 (프로세스). 한 팀이 "AV 소프트웨어를 잘 개발하고 충분히 테스트했으니 안전하다"고 한다. 기능안전 관점에서 무엇이 빠졌나?

정답

빠진 것 — 기능안전은 "잘 작성하고 테스트"가 아니라 체계적 프로세스 규율: ① HARA(위험 분석) — 무엇이 위험하고(위험한 사건 식별) 얼마나 위험한가(S·E·C)를 체계적으로 분석했나? 없으면 어떤 위험에 얼마나 대응할지(ASIL) 모름. ② 안전 목표·요구 캐스케이드 — 위험에서 안전 목표를 도출하고 기능→기술→HW·SW 요구로 추적 가능하게 캐스케이드했나? "테스트 통과"는 요구를 검증한 것이 아닐 수 있음. ③ 추적성 — 각 안전 요구가 설계·구현·검증으로 추적되고 닫혔나(V 모델)? ④ 안전 메커니즘(8.9) — 고장을 탐지·처리하는 메커니즘(락스텝·워치독·중복화)이 ASIL에 맞게 있나? "정상 동작 테스트"만으론 고장 시 안전을 입증 못 함. ⑤ 안전 케이스·근거 — 안전을 입증하는 추적 가능한 근거(work product)·검증·독립 평가가 있나? ⑥ 랜덤 하드웨어 고장 메트릭(SPFM·LFM·PMHF 등). ⑦ SOTIF·AI 안전(8.10~8.11)도. "잘 작성하고 테스트"는 필요하지만, 기능안전은 위험 분석→ASIL→요구→메커니즘→검증→근거의 추적 가능한 프로세스로 "고장났을 때도 안전함"을 입증하는 것. 사후 테스트가 아니라 개념 단계부터의 규율. 자격 있는 기능안전 엔지니어·표준(ISO 26262)·독립 검증이 수행. 좋은 코드 ≠ 안전 케이스.

8.8.12 요약 · 다음 장

기능안전(ISO 26262) 은 E/E 오작동(고장)으로 인한 위험의 부재를 체계적으로 보장한다 — SOTIF(의도 기능 한계, 8.10)·AI 안전(8.11)과 다른 영역이고 모두 필요(기능안전만으론 불충분).
안전은 프로세스 규율(안전 생명주기·V 모델·추적성)이지 단일 테스트가 아니다 — 개념 단계부터.
HARA가 위험을 S(심각도)·E(노출)·C(제어성) 로 평가해 ASIL(QM·A~D) 을 결정 — ASIL이 안전 엄격도의 척도(D=최고).
안전 목표 → 요구 캐스케이드(기능·기술·HW·SW) → 안전 메커니즘(8.9) → 검증 의 추적 가능한 사슬. 8.2(락스텝)·8.6(결정성·FFI)이 하부에서 충족.
칩·OS는 안전 요소(SEooC) 로 OEM 안전 케이스를 받친다 — "ASIL D 인증" 주장은 구성·시점 의존(확인 필요), 전체 안전은 OEM·자격 있는 엔지니어.
정직: 이 장은 개념·용어를 가르치되 실제 안전 설계·인증은 자격 있는 기능안전 엔지니어·표준·검증의 영역 — 이 책으로 안전 시스템을 설계할 수 없다.

다음 장: 8.9 기능안전 II — 안전 메커니즘·아키텍처 패턴. 안전 목표·ASIL을 어떻게 충족하나 — 결함 탐지·처리(락스텝·워치독·ECC·플로지빌리티), 중복화·다양성, fail-operational/fail-safe, ASIL 분해의 아키텍처 패턴을 본다.