ISO 26262 (자동차 기능안전)
1. 개요
가. 정의
ISO 26262는 자동차 전기·전자(E/E) 시스템의 오동작(malfunctioning behavior)으로 인한 위험을 허용 가능한 수준까지 낮추는 것을 목표로 하는 기능안전(Functional Safety) 국제표준이다. 범용 안전표준 IEC 61508을 자동차 도메인에 특화해 만든 것으로, "안전은 설계·개발·생산·운용의 전 생애주기에서 증거(evidence)로 입증되어야 한다"는 원칙 위에 서 있다.
ISO 26262가 등장한 배경은 자동차의 '컴퓨터화'에 있다. 과거 기계·유압으로 구현되던 제동·조향·구동이 전자제어장치(ECU)와 소프트웨어로 옮겨 가면서, 센서 오류 하나, 비트 플립 하나, 소프트웨어 결함 하나가 곧바로 가속·제동 실패 같은 인명 사고로 번질 수 있게 되었다. 전통적 품질관리가 '고장률을 낮추는 것'에 집중했다면, 기능안전은 한 걸음 더 나아가 "고장이 나더라도 시스템이 위험한 상태로 가지 않도록(fail-safe / fail-operational) 설계되었는가"를 묻는다. 2011년 1판이 승용차(총중량 3.5t 이하) 중심으로 제정된 뒤, 전동화·자율주행으로 E/E 비중이 폭증하자 2018년 2판에서 트럭·버스·이륜차까지 적용 범위를 넓히고 반도체(11부)·이륜차(12부) 지침을 신설했다.
따라서 ISO 26262를 이해하는 출발점은 '위험(risk) = 심각도 × 노출빈도 × 제어가능성'이라는 관점이다. 모든 고장을 0으로 만들 수는 없으므로, 위험이 큰 기능에는 더 엄격한 개발·검증을, 위험이 작은 기능에는 통상적 품질관리(QM)를 적용하는 위험 비례(risk-proportionate) 접근이 표준 전체를 관통한다. 이 비례의 척도가 바로 뒤에서 설명할 ASIL이다.
ISO 26262는 총 12개 부(part)로 구성된다. 1부(용어)·2부(안전관리)를 뼈대로, 3부(개념 단계)·4부(시스템)·5부(하드웨어)·6부(소프트웨어)가 개발 생애주기를 다루고, 7부(생산·운용)·8부(지원 프로세스)·9부(ASIL 지향 분석)·10부(지침)가 이를 뒷받침한다. 2018년 2판에서 추가된 11부는 반도체에 대한 적용 지침을, 12부는 이륜차에 대한 적응을 다룬다. 이처럼 표준이 '관리-개념-개발-운용-지원'을 아우르는 전방위 체계라는 점은, 기능안전이 특정 기술이 아니라 조직 전체의 프로세스·문화·거버넌스를 요구하는 경영 과제임을 시사한다.
나. 기능안전과 다른 안전 개념의 구분
기능안전을 정확히 쓰려면 인접 개념과의 경계를 분명히 해야 한다. ISO 26262가 다루는 것은 어디까지나 E/E 시스템의 오동작(systematic failure + random hardware failure)으로 생기는 위해다. 예컨대 브레이크 ECU가 소프트웨어 버그로 제동 명령을 무시하거나, 메모리 비트가 방사선으로 뒤집혀 엉뚱한 토크를 내는 상황이 대상이다. '기능안전(functional safety)'이라는 명칭 자체가 이 범위를 함축한다 — 어떤 기능이 '기능적으로 올바르게 동작하지 못할 때' 생기는 위험을, 그 기능을 감시·보완하는 또 다른 기능(안전메커니즘)으로 통제한다는 의미다.
반면 시스템이 '설계된 대로 정상 동작'하는데도 의도한 기능 자체의 성능 한계·오인식 때문에 위험이 생기는 경우는 ISO 26262의 범위 밖이며, 이를 다루는 것이 2022년 정식 발행된 ISO 21448(SOTIF, Safety Of The Intended Functionality) 이다. 카메라가 역광에서 보행자를 인식하지 못하는 자율주행 상황은 '고장'이 아니라 '성능 부족'이므로 SOTIF의 영역이다. 또 전기충격·발화 같은 비기능적 위해는 전기안전 규격이, 완성차 전체의 거동 안전은 UL 4600(자율주행차 안전사례) 등이 보완한다. 시험 답안에서는 "ISO 26262=고장 대비, SOTIF=성능 한계 대비, 둘은 상호 보완"이라는 분담 구도를 명확히 서술하는 것이 핵심이다.
이 구분이 실무에서 중요한 이유는 안전활동의 '증명 방식'이 근본적으로 다르기 때문이다. ISO 26262의 고장은 원인이 특정 가능하고 확률로 정량화되므로, FTA·FMEA로 고장 경로를 추적하고 하드웨어 지표로 잔여 위험을 수치화할 수 있다. 반면 SOTIF가 다루는 성능 한계는 '언제 어떤 상황에서 오인식할지'를 완전히 열거할 수 없어, 주행 시나리오 커버리지와 통계적 논증에 의존한다. 즉 전자가 '결정론적 증거'라면 후자는 '확률·시나리오적 논증'에 가깝다. 정보관리기술사 관점에서는 두 접근의 검증 철학 차이를 꿰뚫는 것이 고득점의 분기점이 된다.
또한 기능안전은 체계적 고장(systematic failure) 과 무작위 고장(random failure) 을 구분해 각기 다른 수단으로 다룬다. 체계적 고장은 요구·설계·구현의 결함처럼 조건만 맞으면 반드시 재현되는 고장으로, 프로세스 엄격화(리뷰·정적분석·테스트 커버리지)로 '예방'한다. 무작위 고장은 반도체 노화·방사선처럼 확률적으로 발생하는 하드웨어 고장으로, 안전메커니즘에 의한 '검출·대응'과 지표 관리로 다스린다. 이 이분법이 표준 전체의 활동을 어떻게 배분할지를 결정하는 뼈대다.
2. ASIL — 위험 등급 결정과 전체 구조
ISO 26262의 모든 활동은 위험원 분석 및 위험 평가(HARA, Hazard Analysis and Risk Assessment) 에서 출발한다. 차량의 각 기능이 오동작했을 때 벌어질 수 있는 위험 상황(hazardous event)을 식별하고, 이를 세 가지 축으로 정량화한다. 첫째 심각도(Severity, S0S3) — 사고가 났을 때 탑승자·보행자가 입을 상해의 정도. 둘째 노출빈도(Exposure, E0E4) — 그 위험 상황에 차량이 처할 확률·빈도. 셋째 제어가능성(Controllability, C0~C3) — 운전자가 그 상황을 회피·제어할 수 있는 정도다. 이 세 값의 조합으로 ASIL(Automotive Safety Integrity Level) 이 결정된다.
graph TD
START["차량 기능 정의"] --> HARA["HARA: 위험상황 식별"]
HARA --> S["심각도 S0~S3"]
HARA --> E["노출빈도 E0~E4"]
HARA --> C["제어가능성 C0~C3"]
S --> COMB["위험 조합 평가"]
E --> COMB
C --> COMB
COMB --> ASIL["ASIL 등급 QM/A/B/C/D"]
ASIL --> SG["안전목표 Safety Goal 도출"]
SG --> FSR["기능안전요구 FSR"]
FSR --> TSR["기술안전요구 TSR"]
위 구조도가 보여 주듯 ASIL은 그 자체가 목적이 아니라 '얼마나 엄격하게 개발·검증할지'를 결정하는 입력이다. ASIL은 QM(Quality Management, 일반 품질관리로 충분)과 A·B·C·D의 다섯 단계로 나뉘며, D가 가장 엄격하다. 제동·조향처럼 오동작 시 치명적인 기능은 대개 ASIL C/D, 전동 미러·실내등처럼 위험이 작은 기능은 QM/A로 분류된다. 등급이 올라갈수록 요구되는 분석·테스트·문서화·여유 설계의 강도가 비선형적으로 커지므로, HARA 단계에서 ASIL을 과대·과소 산정하면 각각 과잉비용과 안전부족으로 직결된다. 바로 이 때문에 HARA는 소수 전문가의 주관이 아니라 다분야 합의와 근거 기록으로 수행되어야 한다.
| 항목 | 내용 | ASIL과의 관계 |
|---|---|---|
| 심각도(S) | S0(상해 없음)~S3(생명 위협·치명상) | 높을수록 ASIL ↑ |
| 노출빈도(E) | E0(거의 없음)~E4(상시 발생) | 높을수록 ASIL ↑ |
| 제어가능성(C) | C0(제어 쉬움)~C3(제어 불가) | 높을수록 ASIL ↑ |
| ASIL | QM < A < B < C < D | 개발·검증 엄격도 결정 |
표는 세 요소의 방향성을 정리한 것이지만, 실제 산정은 단순 덧셈이 아니라 표준이 제공하는 위험 매트릭스(risk matrix) 에 따른다. 예를 들어 고속주행 중 의도치 않은 완전제동은 심각도·노출·제어불가가 모두 높아 ASIL D로, 저속 주차 중 후방카메라 꺼짐은 상대적으로 낮게 평가되는 식이다.
세 요소를 곱의 형태로 다루는 데에는 깊은 이유가 있다. 아무리 심각한 결과라도 거의 발생하지 않거나(E 낮음) 운전자가 쉽게 회피할 수 있다면(C 낮음) 실제 위험은 낮아지기 때문이다. 예컨대 '시속 200km에서만 발생하는 결함'은 노출빈도가 낮아 등급이 내려가고, '운전자가 즉시 감속으로 대응 가능한 경고등 오류'는 제어가능성이 높아 등급이 내려간다. 이처럼 ASIL은 결과의 크기만이 아니라 그 결과가 현실화될 조건까지 종합한 '실질 위험'의 척도이며, 바로 이 점이 단순 고장심각도 분류와 기능안전 등급을 가르는 핵심이다. 답안에서 S·E·C를 나열만 하고 '왜 곱으로 묶는가'를 빠뜨리면 원리 이해가 부족한 것으로 평가된다.
또 하나 중요한 기법이 ASIL 분해(ASIL decomposition) 다. 하나의 ASIL D 요구를, 서로 독립적으로 동작하는 두 경로(예: ASIL B + ASIL B(D))로 나누어 각 구성요소의 개발 부담을 낮추는 기법으로, 다만 두 경로가 공통원인고장(CCF)으로 함께 무너지지 않도록 독립성(freedom from interference) 을 입증해야만 성립한다. 독립성이 깨지면(예: 두 경로가 같은 전원·클록·메모리를 공유) 분해는 무효가 되고 원래의 ASIL D 부담이 그대로 돌아오므로, 분해는 비용 절감 수단이기 이전에 '독립성 증명'이라는 또 다른 분석 과제를 동반한다는 점을 유의해야 한다.
3. 안전생애주기와 V모델 — 구성요소와 절차
ISO 26262의 두 번째 축은 안전생애주기(safety lifecycle) 다. 이는 개념 단계 → 제품개발(시스템·하드웨어·소프트웨어) → 생산·운용 → 폐기까지 안전활동을 시간순으로 엮은 것으로, 개발 단계는 전형적인 V모델로 전개된다. 왼쪽 하강부에서 요구사항을 상위에서 하위로 분해(안전목표 → FSR → TSR → HW/SW 설계)하고, 오른쪽 상승부에서 단위·통합·시스템 수준으로 검증하며 각 단계의 산출물이 상위 요구를 충족함을 추적성(traceability)으로 입증한다.
flowchart LR
subgraph LEFT["설계(요구 분해)"]
direction TB
L1["안전목표(Safety Goal)"] --> L2["기능안전요구(FSR)"]
L2 --> L3["기술안전요구(TSR)"]
L3 --> L4["HW/SW 안전요구"]
L4 --> IMPL["구현(설계·코딩)"]
end
subgraph RIGHT["검증(통합·확인)"]
direction TB
R4["단위 검증"] --> R3["HW/SW 통합"]
R3 --> R2["시스템 통합"]
R2 --> R1["안전확인(Safety Validation)"]
end
IMPL --> R4
L4 -. 추적성 .-> R4
L3 -. 추적성 .-> R3
L2 -. 추적성 .-> R2
L1 -. 추적성 .-> R1
V모델이 ISO 26262의 사실상 표준 개발모형이 된 이유는 '요구와 검증의 대칭성'에 있다. 왼쪽에서 상위 안전요구를 한 단계씩 분해할 때마다, 오른쪽의 대응 단계에서 그 요구가 충족되었음을 검증하도록 좌우가 거울처럼 맞물린다. 이 대칭 구조는 "모든 안전요구는 반드시 하나 이상의 검증 활동으로 닫혀야 한다"는 폐루프(closed-loop) 원칙을 자연스럽게 강제하며, 추적성 매트릭스로 그 폐루프를 가시화한다. 요구가 검증 없이 남거나 검증이 요구 없이 떠 있으면 추적성 점검에서 즉시 드러나므로, 누락된 안전활동을 조기에 포착할 수 있다.
세부 구성요소를 단계별로 보면 다음과 같다. 개념 단계에서는 아이템 정의(item definition)로 대상 시스템의 경계를 긋고, HARA로 ASIL과 안전목표를 정한 뒤 이를 구현 독립적인 기능안전요구(FSR) 로 구체화한다. 시스템 단계에서는 FSR을 하드웨어·소프트웨어에 할당 가능한 기술안전요구(TSR) 로 세분하고, 안전 아키텍처(감시·이중화·안전상태 전이)를 설계한다. 여기서 중요한 개념이 안전상태(safe state) 와 고장허용시간간격(FTTI, Fault Tolerant Time Interval) 이다. 고장이 발생한 순간부터 위험이 현실화되기까지의 시간 안에 시스템이 안전상태(예: 토크 차단, 경고 후 감속)로 전이해야 한다는 시간 제약으로, [[rtos]]의 결정성·마감시간 개념과 직결된다. FTTI는 다시 '고장을 검출하는 시간(fault detection time)'과 '안전상태로 반응하는 시간(fault reaction time)'의 합으로 쪼개지며, 이 두 시간의 상한을 보장하려면 진단 주기와 반응 경로가 실시간성 요구를 만족해야 한다. 그래서 안전 아키텍처 설계는 곧 실시간 스케줄링 설계와 분리될 수 없고, 워치독·감시 코어의 주기를 FTTI로부터 역산해 정하는 작업이 핵심이 된다.
생산·운용 단계도 안전생애주기의 일부다. 개발이 끝났다고 안전이 보장되는 것이 아니라, 생산 공정에서 안전 특성이 재현되는지(공정관리), 운용 중 고장을 진단·보고하고 리콜·필드 대응으로 되먹임하는지까지가 표준의 관심사다. 즉 ISO 26262는 '설계의 안전'을 넘어 '생애 전체에 걸친 안전의 유지'를 요구하며, 이것이 일회성 시험합격으로 끝나는 전통적 인증과 구별되는 지점이다.
하드웨어 단계에서는 무작위 하드웨어 고장(random hardware failure)을 정량적으로 평가한다. 핵심 지표는 세 가지다. SPFM(단일점 고장 지표) 은 안전메커니즘이 단일점 고장을 얼마나 잡아내는지를, LFM(잠재 고장 지표) 은 드러나지 않고 숨어 있는 잠재 고장을 얼마나 진단하는지를, PMHF(무작위 하드웨어 고장 확률 지표) 는 시간당 위험 고장 확률(FIT, 10억 시간당 고장 수)을 나타낸다. 표준이 제시하는 목표치는 ASIL이 올라갈수록 가팔라진다.
| 지표 | ASIL B | ASIL C | ASIL D |
|---|---|---|---|
| SPFM | ≥ 90% | ≥ 97% | ≥ 99% |
| LFM | ≥ 60% | ≥ 80% | ≥ 90% |
| PMHF | < 100 FIT | < 100 FIT | < 10 FIT |
이 수치가 의미하는 바를 산문으로 풀면 이렇다. ASIL D의 SPFM 99%는 "단일점 고장의 99%를 안전메커니즘이 검출·대응해야 한다"는 뜻이고, PMHF 10 FIT는 "위험한 무작위 고장이 10억 시간(약 11.4만 년 연속주행)당 10회 미만이어야 한다"는 극히 낮은 확률을 요구한다. 이를 달성하려면 ECC 메모리, 락스텝(lockstep) 듀얼코어, 워치독, 주기적 자가진단(BIST) 같은 안전메커니즘을 아키텍처에 녹여야 한다.
여기서 핵심은 '진단 커버리지(diagnostic coverage)'라는 개념이다. 아무리 고장률이 낮은 부품이라도 고장을 검출하지 못하면 안전지표에 그대로 위험으로 잡히고, 반대로 고장률이 다소 높아도 안전메커니즘이 고장을 높은 비율로 검출해 안전상태로 전이시키면 잔여 위험은 낮아진다. 즉 하드웨어 안전설계의 본질은 '고장을 없애는 것'이 아니라 '고장을 제때 검출·격리하는 것'이다. 이 때문에 ASIL D 시스템은 연산 결과를 두 경로로 비교하는 락스텝, 메모리 오류를 정정하는 ECC, 주기적으로 논리를 검사하는 BIST를 중첩해, 단일 고장이 검출 없이 출력으로 전파되는 경로를 구조적으로 차단한다.
소프트웨어 단계에서는 MISRA C 같은 코딩 규칙, 정적분석, 요구 기반 테스트, 구조적 커버리지(ASIL D는 MC/DC 요구)를 적용하며, 이는 [[embedded-software-test]]·[[software-safety-analysis]]의 FMEA·FTA 기법과 맞물려 체계적 고장을 제거한다. 소프트웨어는 무작위로 '마모'되지 않으므로 고장률 수치가 아니라 개발 프로세스의 엄격성 자체가 안전 증거가 된다는 점이 하드웨어와 결정적으로 다르다. 그래서 표준은 ASIL이 높을수록 더 강한 설계 원칙(모듈화·강결합 금지·결정적 실행), 더 엄격한 검증 기법(경계값·동등분할·오류주입), 더 높은 커버리지 목표를 '권고(highly recommended)' 수준으로 차등 요구한다. 또한 요구·설계·코드·테스트 사이의 양방향 추적성을 유지해, 어떤 안전요구가 어느 코드로 구현되고 어떤 테스트로 검증되었는지를 빠짐없이 증거로 남겨야 한다.
4. 비교 — 기능안전 표준 간 관계와 적용 사례
ISO 26262는 홀로 존재하지 않고 안전표준의 계층 속에 놓인다. 모태인 IEC 61508은 전 산업용 범용 기능안전 표준으로 안전무결성수준을 SIL 1~4로 나누는데, ISO 26262의 ASIL은 이를 자동차 도메인에 맞춰 재해석한 것이다. 차이가 생기는 이유는 적용 맥락에 있다. 공장 설비(IEC 61508)는 고장 시 '정지(fail-safe)'가 대개 안전하지만, 고속주행 차량은 갑작스런 전체 정지가 오히려 위험할 수 있어 fail-operational(일부 기능 유지) 설계가 요구된다. 이 실무적 함의 차이가 두 표준의 아키텍처 선택을 가른다.
| 표준 | 대상 | 등급 체계 | 핵심 관심사 |
|---|---|---|---|
| IEC 61508 | 전 산업(범용) | SIL 1~4 | 범용 기능안전 모태 |
| ISO 26262 | 도로 차량 E/E | ASIL A~D(+QM) | E/E 고장 대비 |
| ISO 21448(SOTIF) | 의도기능 성능한계 | 등급 없음 | 오인식·성능부족 |
| DO-178C | 항공 SW | DAL A~E | 항공 소프트웨어 |
또한 항공 소프트웨어 표준 DO-178C(DAL A~E)와 비교하면 등급화·V모델·추적성이라는 공통 뼈대가 드러난다. 두 표준 모두 '안전무결성이 높을수록 더 엄격한 검증'을 요구하지만, 항공은 인증기관(FAA/EASA) 심사가 전제인 반면 자동차는 상대적으로 제조사 자기선언·감사 비중이 커 프로세스 증거의 자기입증 책임이 크다. 이처럼 같은 기능안전이라도 산업별 인증 생태계가 다르면 실무 운영 방식이 달라진다는 점을 답안에서 짚어 주면 비교의 깊이가 산다.
구체 적용 사례를 보면 이해가 깊어진다. 전동식 파워스티어링(EPS)은 조향 보조력 상실이 치명적이므로 통상 ASIL D로 개발되며, 모터 제어기에 락스텝 코어와 다중 센서를 두고 FTTI 내 안전상태 전이를 보장한다. 배터리관리시스템(BMS)은 과충전·열폭주를 막아야 하므로 셀 전압·온도 감시와 접촉기 차단을 ASIL C/D로 설계한다. 반대로 인포테인먼트 디스플레이는 대개 QM이다. 또 하나 실무에서 중요한 개념이 SEooC(Safety Element out of Context) 로, 특정 차량을 전제하지 않고 범용 가정 아래 개발한 반도체·소프트웨어 부품(예: 차량용 MCU)을 완성차 통합 시 그 가정의 성립 여부만 확인해 재사용하는 방식이다. 반도체 업체가 ASIL 등급을 '사전 확보'해 공급하는 생태계가 이렇게 만들어진다.
이 생태계의 실제 작동을 보면, 차량용 MCU 공급업체는 칩에 락스텝 코어·ECC·BIST 같은 안전메커니즘을 내장하고 안전매뉴얼(safety manual) 에 '완성차가 지켜야 할 가정과 사용 조건'을 명시해 함께 제공한다. 완성차·부품(Tier-1) 업체는 그 가정이 자사 시스템에서 성립하는지만 확인하면 되므로, 반도체 수준의 방대한 안전분석을 반복하지 않고도 ASIL 요구를 충족할 수 있다. 이처럼 ISO 26262는 단일 조직의 개발 규범을 넘어, 공급망 전반이 안전 증거를 분업·전달하는 DIA(Development Interface Agreement) 기반 협업 모델을 제도화했다는 점에서 의의가 크다.
5. 심화 — 자율주행 시대의 기능안전 확장과 최신 동향
최근 기능안전의 지형은 자율주행과 소프트웨어 중심 차량(SDV, Software-Defined Vehicle)으로 급격히 이동하고 있다. 가장 큰 변화는 ISO 26262(고장 안전)만으로는 자율주행을 다룰 수 없다는 인식이다. 자율주행 사고의 상당수는 부품이 '고장'나서가 아니라 인지·판단 알고리즘이 '설계된 한계 안에서 정상 동작'했는데도 예외 상황을 오판해 발생한다. 이를 메우기 위해 ISO 21448(SOTIF) 이 2022년 정식 표준으로 발행되어, 알려진/알려지지 않은 위험·안전 영역을 네 사분면으로 나누고 미지의 위험 영역을 검증·주행데이터로 축소하는 접근을 제시한다. 나아가 AI 기반 자율주행의 전체 안전사례(safety case)를 다루는 UL 4600, 그리고 2024년 발행된 ISO/PAS 8800(자동차 AI 안전)까지 등장하며 표준 체계가 다층화되고 있다.
SOTIF의 네 사분면 접근은 특히 음미할 가치가 있다. 안전/위험과 알려짐/알려지지-않음의 두 축으로 영역을 나누면, 개발의 목표는 '알려진 위험(Area 2)'을 설계로 제거하고 '알려지지 않은 위험(Area 3)'을 시나리오 발굴·주행 누적으로 '알려진' 영역으로 끌어와 다시 제거하는 것이 된다. 문제는 Area 3를 완전히 비울 수 없다는 데 있어, '얼마나 검증했을 때 충분히 안전하다고 선언할 것인가(validation target)'라는 통계적 판단이 개입한다. 이 때문에 자율주행 안전은 수억 km의 실주행·시뮬레이션 데이터를 요구하며, 고장 중심의 ISO 26262와는 근본적으로 다른 증명 부담을 낳는다.
두 번째 동향은 보안과 안전의 융합이다. 커넥티드카에서는 사이버 공격이 곧 안전 위협이 되므로, 사이버보안 표준 ISO/SAE 21434와 기능안전이 함께 설계되어야 한다. 예컨대 OTA(무선 업데이트)로 제어 소프트웨어를 갱신할 때, 변조된 펌웨어가 ASIL D 기능을 손상시키지 않도록 보안과 안전 요구가 교차 검증된다. 전통적으로 안전은 '우연한 고장(random/systematic)'을, 보안은 '악의적 공격(malicious)'을 가정해 서로 다른 위협모델을 썼지만, 커넥티드·자율주행 환경에서는 공격이 안전목표를 직접 겨냥하므로 두 위협모델을 하나의 분석으로 통합해야 한다. 유엔 규정 UNECE WP.29 R155/R156가 사이버보안관리체계(CSMS)와 소프트웨어 업데이트관리체계(SUMS)를 형식승인 요건으로 의무화하면서, 이 융합은 선택이 아니라 규제 준수 사항이 되었다. 세 번째는 중앙집중형 E/E 아키텍처로의 전환이다. 수십 개 ECU로 분산되던 기능이 소수의 고성능 도메인·존(zonal) 컨트롤러로 통합되면서, 하나의 하드웨어에서 ASIL D 기능과 QM 기능이 공존하게 되었다. 이때 하이퍼바이저·파티셔닝으로 혼합중요도(mixed-criticality) 간 간섭 없음을 보장하는 설계가 핵심 과제로 부상했는데, 이는 [[rtos]]의 공간·시간 분할 개념과 직결된다.
통합이 가져오는 이점은 분명하다. 배선·커넥터가 줄어 중량·원가가 낮아지고, 소프트웨어 중심 차량으로서 OTA로 기능을 지속 개선할 수 있다. 그러나 안전 관점에서는 '격리의 증명'이라는 새로운 난제를 던진다. 저중요도 애플리케이션의 폭주가 고중요도 제어의 CPU·메모리·네트워크 대역을 잠식하지 않도록 자원을 시간·공간적으로 분할하고, 그 격리가 결함 상황에서도 무너지지 않음을 입증해야 한다. 이 때문에 AUTOSAR Adaptive 플랫폼, 안전인증 하이퍼바이저, 결정적 이더넷(TSN) 같은 기반 기술이 기능안전 아키텍처의 필수 요소로 부상하고 있다. 예상 출제 방향으로는 "ISO 26262와 SOTIF·21434의 통합 안전 프로세스를 자율주행 사례로 설명하라"는 융합형 논제, 또는 "중앙집중 E/E 아키텍처에서 혼합중요도 격리를 보장하는 설계 방안을 논하라"는 아키텍처형 논제가 유력하다.
6. 고려사항 및 시사점
적용 전략 — ASIL 지향 설계(ASIL-oriented design): 프로젝트 초기에 HARA로 기능별 ASIL을 확정하고, 그 등급에 비례해 아키텍처·프로세스·검증 강도를 배분해야 한다. 특히 ASIL 분해로 고등급 요구를 저등급 다중 경로로 분산할 때는 독립성(freedom from interference)과 공통원인고장 배제를 반드시 증거로 남겨야 분해가 유효하다. 등급을 뒤늦게 조정하면 재설계 비용이 폭증하므로 개념 단계의 정확한 ASIL 산정이 전체 비용을 좌우한다.
트레이드오프 — 안전 vs 비용·성능·일정: ASIL D 요구는 락스텝·이중화·광범위한 커버리지 테스트를 수반해 BOM 원가와 개발기간을 크게 늘린다. 반대로 SEooC·부품 재사용·ASIL 분해는 비용을 줄이지만 가정의 타당성 입증 부담을 남긴다. 기술사 관점에서는 '안전은 타협 불가'라는 원칙 아래, 과잉설계와 과소설계 사이에서 위험 비례적 최적점을 찾는 균형 감각이 요구된다.
전망 — 데이터 기반·연속적 안전보증: 자율주행과 SDV 시대에는 출고 시점의 1회성 인증이 아니라, 주행 데이터·OTA·현장 모니터링을 통한 운용 중 연속 안전보증(continuous safety assurance) 으로 패러다임이 이동한다. SOTIF의 미지 위험 축소, 디지털 트윈·시뮬레이션 기반 검증, 안전사례(safety case)의 지속 갱신이 표준 실무의 중심이 될 것이다.
연계 기술 — 보안·AI·실시간성의 통합: 기능안전은 더 이상 독립 활동이 아니라 ISO/SAE 21434(사이버보안), ISO/PAS 8800(AI 안전), [[rtos]]의 실시간성, [[software-safety-analysis]]의 FMEA·FTA와 유기적으로 결합되어야 한다. 특히 중앙집중 아키텍처에서는 혼합중요도 격리와 보안-안전 공동설계가 핵심 역량이 되며, 조직 차원의 안전문화(safety culture)와 거버넌스가 이를 뒷받침해야 한다.
조직·거버넌스 — 안전문화의 제도화: ISO 26262는 기술 요건에 앞서 '안전을 최우선으로 삼는 조직 역량'을 요구한다. 독립적 안전평가(confirmation measure), 역할·책임의 명확화, 공급망 간 DIA 체결, 산출물의 형상·변경 관리가 뒷받침되지 않으면 아무리 뛰어난 설계도 '증거로 입증되지 않은 안전'에 그친다. 따라서 기술사는 기능안전을 단일 프로젝트의 품질활동이 아니라, 전사 프로세스·인력·문화에 걸친 지속 투자로 설계·운영하는 거버넌스 관점을 갖추어야 한다.
참고자료
- ISO, "ISO 26262:2018 Road vehicles — Functional safety": https://www.iso.org/standard/68383.html
- ISO, "ISO 21448:2022 Road vehicles — Safety of the intended functionality (SOTIF)": https://www.iso.org/standard/77490.html
- Semiconductor Engineering, "ISO 26262 Knowledge Center": https://semiengineering.com/knowledge_centers/automotive/automotive-standards/iso-26262/
- ISO26262 Academy, "Hardware Metrics: PMHF, SPFM and LFM Explained": https://iso26262.academy/blog/hardware-metrics-explained-pmhf-spfm-lfm
- ISO/SAE, "ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering": https://www.iso.org/standard/70918.html
한 줄 요약: ISO 26262는 자동차 E/E 시스템의 오동작 위험을 HARA→ASIL(A~D)로 등급화하고, 안전생애주기·V모델과 SPFM·LFM·PMHF 하드웨어 지표로 전 생애주기에 걸쳐 안전을 증거로 입증하는 기능안전 표준이며, SOTIF·21434·AI 안전표준과 결합해 자율주행 시대로 확장되고 있다.