인지야공/강의 요약/8번째 글
자율주행이동체 ② 고장이 없어도 위험하다 — 안전과 보안 표준
①에서 아키텍처를 봤다면 이 글은 “그래서 그게 안전하다는 걸 어떻게 증명하는가”에 대한 것이다. 자율주행에서 표준이 유독 많은 이유가 여기 있다.
SOTIF — 의도된 기능의 안전성
ISO 21448. 기존 기능 안전 표준인 ISO 26262 와 무엇이 다른지가 출발점이다.
| 구분 | ISO 26262 (기능 안전) | SOTIF (ISO 21448) |
|---|---|---|
| 전체 이름 | Road vehicles — Functional safety | Safety of the Intended Functionality |
| 위험 원인 | HW/SW 고장(Fault) → 부품이 망가져서 사고 | 고장이 없어도 시스템 한계·센서 한계·AI 비결정론 → 부품은 정상인데 사고 |
| 대표 상황 | 브레이크 ECU 가 갑자기 고장난다 | 안개 속에서 카메라가 보행자를 못 알아본다 (카메라는 정상 동작 중) |
| 핵심 과제 | 결함 없는 안전한 시스템 설계 | AI·센서의 성능 한계와 알 수 없는 상황 관리 |
“부품은 정상인데 사고가 난다”는 문장이 SOTIF 의 전부다. 딥러닝이 들어오면서 생긴 새로운 종류의 위험이라, 기존 표준으로는 다룰 수 없었다.
네 개 영역
Known/Unknown × Safe/Hazardous 의 조합이다.
| 영역 | 이름 | 의미 | 대응 |
|---|---|---|---|
| Area 1 | Known-Safe | 알려진 안전한 상황. 이미 정상 처리 중 | 유지 |
| Area 2 ★ | Known-Unsafe | 알려진 위험. 한계를 이미 파악함. “비가 심하면 인식 불가”를 안다 | 설계 변경으로 능력 향상 또는 ODD 에 제한 조건 명시 |
| Area 3 ★★★ | Unknown-Unsafe = Black Swans | 예상하지 못한 상황에서 발생하는 위험. 한 번도 학습하지 않은 교통 상황 | 시나리오 탐색으로 크기를 줄여 나간다. SOTIF 의 핵심 과제 |
| Area 4 | Unknown-Safe | 몰랐지만 우연히 안전했던 상황 | 불확실성 관리. Area 4 가 크면 시스템의 강건성이 높은 것 |
목표는 Area 2 와 Area 3 를 최소화하는 것이다. 다만 Area 3 를 완전히 없애는 것은 불가능하므로 “충분히 작게” 만드는 것이 현실적인 목표다.
이 프레임이 좋은 이유는 “모르는 것”을 인정하고 시작한다는 점이다. 알려진 위험은 고치면 되지만, 모르는 위험은 더 많은 시나리오를 탐색해서 아는 쪽으로 옮기는 수밖에 없다.
사이버보안 — ISO 21434 와 UNECE R155
| 구분 | ISO 21434 | UNECE WP.29 R155 |
|---|---|---|
| 성격 | 기술 표준 — 어떻게 만들어야 하는가 | 법적 규정 — 이걸 지켜야 판매 허가 |
| 제정 | ISO | UNECE (유엔 유럽경제위원회) |
| 내용 | 차량 사이버보안 개발 프로세스 15개 조항 | CSMS 인증 의무화, VTA 취득 요건 |
| 대상 | OEM, Tier1, Tier2 전 공급망 | 차량을 판매하는 OEM |
| 관계 | 따르면 R155 충족에 유리 | 준수를 위해 ISO 21434 를 활용 |
하나는 기술 표준이고 하나는 법이다. 이 구분이 핵심이다.
CSMS → VTA
순서가 시험에 나온다.
| CSMS (CyberSecurity Management System) | 제조사가 운영하는 사이버보안 관리 체계. “우리 회사는 보안을 이렇게 관리합니다”를 인증받는 것 |
| VTA (Vehicle Type Approval) | 차량 양산 전 국가 승인. OEM 이 CSMS 인증서 + 기술 문서 + 샘플 차량을 제출 → Technical Service 기관이 테스트 → Approval Authority 가 형식 승인 → 양산 허가 |
CSMS(회사 인증) → VTA(차량 인증) 순서다. CSMS 가 없으면 VTA 를 못 받고, VTA 가 없으면 차를 팔 수 없다.
TARA
Threat Analysis and Risk Assessment — ISO 21434 의 핵심 분석 도구다. 7단계로 진행한다.
| 단계 | 활동 |
|---|---|
| 1. 자산 정의 | 보호할 것을 정의. 브레이크 제어 신호, 차량 위치 데이터, ECU 소프트웨어 |
| 2. 위협 시나리오 식별 | “누가 어떤 방법으로 공격할 수 있는가”. CAN 버스 스푸핑으로 가짜 브레이크 신호 주입 |
| 3. 영향도 측정 | 성공했을 때 피해 규모. 안전·재무·운영·개인정보 네 관점 |
| 4. 공격 경로 분석 | 물리적 접근, 원격 접근, 공급망 |
| 5. 실현 가능성 측정 | 현실적으로 가능한가. 필요한 전문성·시간·장비 |
| 6. 위험 측정 | 영향도 × 실현 가능성 = 위험 수준 (CAL 1~4) |
| 7. 위험 관리 방법 결정 | 수용/회피/전가/감소 중 선택. 설계 변경, 보안 패치, OTA |
CAL (Cybersecurity Assurance Level) — 위험 수준에 따라 1~4 등급. ISO 26262 의 ASIL 과 같은 개념이고 CAL 4 가 가장 높은 요구사항이다.
테스트 방법
| 방법 | |
|---|---|
| 정적 분석 | 코드를 실행하지 않고 분석. CQA(코드 품질 분석), 결함 분석 |
| 동적 분석 | 특정 부분을 실제 실행하며 테스트. VectorCast |
| Fuzz 테스트 | 유효하지 않은 입력을 무작위로 집어넣어 예상치 못한 동작을 유발. 인터페이스 취약점 발견에 효과적 |
| Pen 테스트 | 보안 전문가가 공격팀/방어팀으로 나뉘어 실제 해킹 시도. 블랙박스/화이트박스/그레이박스 |
ODD — 운행 설계 영역
Operational Design Domain — ADS 가 정상 작동하도록 설계된 운행 환경의 범위다. ADS 는 ODD 안에서만 안전성을 보장한다. 밖에서는 MRM 을 수행하거나 운전자에게 인계해야 한다.
ISO 34503 이 정의한 3대 구성 요소.
| 요소 | 하위 항목 |
|---|---|
| 도로 요소 | 구역(어린이보호구역, 터널, 고층건물 간섭구역), 차선 구조, 교차로 유형(평면/입체), 노면 상태, 임시 공사 구간 |
| 환경 조건 | 날씨(기온·바람·강우량·강설량), 조도(자연광·인공조명·야간), 먼지, GNSS 연결성(GPS/BeiDou/Galileo + RTK 보정) |
| 동적 요소 | 트래픽 에이전트(자동차·보행자·자전거·동물·오토바이), 특수차량(구급차·경찰차·소방차), 트래픽 밀도/양/유율, 최대 허용 속도 |
“L4 자율주행”이라는 말이 조건 없이 쓰이면 의심해야 하는 이유가 여기 있다. ODD 를 좁게 잡으면 L4 는 훨씬 쉬워진다. 어디까지가 그 차의 ODD 인지가 실제 성능을 말해 준다.
ISO 3450X 시리즈
| 표준 | 주도 | 내용 |
|---|---|---|
| ISO 34501 | 중국 | 용어 사전 — 시나리오 관련 용어와 정의 통일 |
| ISO 34502 | 일본·독일 | 안전 평가 프레임워크 — Trigger 조건 정의, 위험 식별 |
| ISO 34503 ★ | 영국·일본 | ODD 분류 체계 — 도로/환경/동적 요소의 분류. 국내 충북대 기석철 교수 주도로 KS 부합화 |
| ISO 34504 | 독일·네덜란드 | 시나리오 분류 — 정성적/정량적 레이블링 |
| ISO 34505 | 중국·독일 | 시나리오 평가 및 테스트 케이스 생성 |
PEGASUS 6-Layer Model
자율주행 시나리오를 6개 계층으로 분해하는 모델이다. ASAM OpenX 표준의 기반이 됐다.
| Layer | 내용 | 담당 OpenX |
|---|---|---|
| 1 — Road | 도로 구조와 레이아웃 (차선 수, 교차로 형태, 경사, 곡률) | OpenDRIVE |
| 2 — Traffic Infrastructure | 신호등, 표지판, 가드레일 | OpenDRIVE |
| 3 — Temporary Modifications | 도로 공사, 임시 차선 변경, 행사 통제 | OpenDRIVE |
| 4 — Moving Objects | 주변 차량, 보행자, 자전거 | OpenSCENARIO |
| 5 — Environment | 날씨, 조도, V2X 연결성 | OpenSCENARIO |
| 6 — Digital Information | HD Map, V2X 신호, 디지털 정보 | (확장 연구 중) |
13 이 정적, 45 가 동적이다. 그래서 앞쪽은 OpenDRIVE, 뒤쪽은 OpenSCENARIO 가 맡는다.
ISO 5083 — ADS 안전의 우산 표준
SAE Level 3·4 ADS 의 안전을 다루는 최상위 통합 표준이다. ISO 26262(기능 안전) + ISO 21448(SOTIF) + ISO 21434(사이버보안)을 모두 연계한다.
- 발전 경로 — ISO TR 4804 (2020) → ISO TS 5083 (2023) → ISO IS (최종 국제 표준, 추진 중)
- 적용 대상 — SAE Level 3 & Level 4 ADS
- 규제 역할 — 각국 자율주행 법규·규제의 기술적 근거
두 가지 안전 접근법
| 접근법 | 의미 | 방법 |
|---|---|---|
| Positive Risk Balance 긍정적 위험 균형 | ADS 가 평균 인간 운전자보다 더 안전함을 수치로 증명해야 한다 | 지역별(유럽/미국/중국)·도로 유형별(고속도로/도심)·날씨별·연령별 인간 사고율 데이터와 ADS 성능 비교 |
| Avoidance of Unreasonable Risk 불합리한 위험 회피 | 모든 위험을 없애는 건 불가능하므로, 불합리하게 높은 위험은 반드시 제거한다 | 정성적(전문가 검토) + 정량적(수치) 평가 조합. 사고 회피를 “실질적으로 가능한 한” 최대화 |
“완벽하게 안전한가”가 아니라 “사람보다 나은가”를 기준으로 잡은 것이 실용적이다. 전자는 증명이 불가능하고 후자는 데이터로 답할 수 있다.
MRM 과 MRC
| 전체 이름 | 설명 | 예 | |
|---|---|---|---|
| MRM | Minimal Risk Maneuver | 고장·한계 상황·ODD 이탈 시 최소 위험 상태로 이행하는 행동(동사). “무엇을 하는가” | 비상등 → 감속 → 갓길 이동 → 정차 |
| MRC | Minimal Risk Condition | MRM 수행 후 도달한 최종 안전 상태(명사). “어디에 있는가” | 갓길에 안전하게 정차된 상태 |
MRM = 동사(행동, 과정) / MRC = 명사(상태, 결과)
레벨에 따라 처리가 다르다. Level 3 은 MRM 수행 후 운전자에게 인계(Fail-Safe), Level 4 는 MRM 으로 MRC 까지 자체 처리(Fail-Operation)한다.
XIL — 실물을 하나씩 더해 간다
MiL → SiL → HiL → ViL → Proving Ground → Real Road 순으로 실제 하드웨어가 점차 추가된다.
| 단계 | 실물 포함 | 설명 |
|---|---|---|
| MiL Model-in-the-Loop | 없음 (모두 모델) | 알고리즘 아이디어를 수학 모델로만 검증. PC 에서 실행. 가장 빠르고 저렴 |
| SiL Software-in-the-Loop | SW 만 실제 코드 | 타겟 프로세서용 실제 코드를 PC 에서 컴파일·실행. 컴파일러 오류, 타이밍 문제 발견 |
| HiL Hardware-in-the-Loop | 실제 ECU | 실제 ECU 를 시뮬레이터에 연결. dSPACE AutoBox 같은 장비. 실시간 상호작용 |
| ViL Vehicle-in-the-Loop | 실제 차량 | 섀시 다이나모미터에 실차를 올리고 가상 도로 환경을 연결 |
| PG Proving Ground | 완전 실물 (통제 환경) | K-City(화성), C-Track 같은 시험 트랙에서 실차 주행 |
| Real Road | 완전 실물 (실제 도로) | 공공 도로 실증. 예측 불가 상황 발생. 최종 검증 |
뒤로 갈수록 현실에 가깝지만 비싸고 느리다. 앞 단계에서 잡을 수 있는 문제를 뒤에서 잡으면 비용이 몇 자릿수로 뛴다는 것이 이 순서의 존재 이유다.
ASAM OpenX 표준 생태계
ASAM(Association for Standardization of Automation and Measuring Systems)이 정의하는 자율주행 시뮬레이션 표준 패밀리다. 서로 다른 시뮬레이터와 도구들이 같은 파일을 읽고 쓸 수 있게 해 준다.
| 표준 | PEGASUS 계층 | 하는 일 |
|---|---|---|
| OpenDRIVE | Layer 1,2,3 (정적 도로) | 도로 구조를 XML 로 정의. 차선 수, 경사, 교차로, 신호등 위치, 표지판. Reference Line 기반 모델링 |
| OpenSCENARIO | Layer 4,5 (동적) | 주행 시나리오를 언어로 정의. “100m 앞에서 보행자가 갑자기 튀어나온다”. V1(XML, 현재 주류) / V2(DSL) |
| OpenOSI | 센서 인터페이스 | 시뮬레이터↔센서 모델 연결. GroundTruth → SensorView → 센서 모델 → SensorData → ADS 입력 |
| OpenCRG | 노면 표면 | 노면의 굴곡·요철·균열을 3D 로. 타이어 진동·승차감 시뮬레이션 |
| OpenLABEL | 데이터 어노테이션 | 카메라·LiDAR 데이터의 레이블 형식 통일 |
| OpenOntology | 공통 기반 | 도로 교통의 모든 개념을 통일된 언어로 정의 (2020년 시작) |
핵심 구별은 셋이다.
OpenDRIVE = 정적 도로(어디에 뭐가 있나) OpenSCENARIO = 동적 시나리오(무슨 일이 일어나나) OpenOSI = 센서 모델 인터페이스(데이터가 어떻게 흐르나)
디지털 트윈
실제 차량과 가상 차량을 실시간으로 동기화하여 양방향으로 데이터를 주고받는 기술이다.
| 단계 | 활용 | 예 |
|---|---|---|
| Research | 가상 환경에서 AI 알고리즘 개발. 현실에서 불가능한 위험 시나리오를 무한 생성 | CARLA 에서 1,000가지 교차로 시나리오 |
| Design | 설계 단계에서 가상으로 문제 발견. HW 제작 전에 SW 검증 | 새 센서 배치가 사각지대를 만드는지 확인 |
| Verification | XIL 기반 가상 검증 | HiL 로 AEB 를 1만 번 테스트 |
| Deployment | OTA 전 가상 차량에 먼저 적용 | 새 SW 를 디지털 트윈에서 1주일 검증 후 배포 |
| Monitoring | 실차 데이터를 가상 쌍에 실시간 반영. 이상 감지·예측 정비 | 실차 BMS 데이터로 배터리 고장 사전 예측 |
시뮬레이션과의 차이가 시험 포인트다.
| 시뮬레이션 | 일방향. 모델 설정 → 실행 → 결과. 실시간 동기화 없음 |
| 디지털 트윈 | 양방향. 실차 데이터 → 가상에 반영 → 가상 예측 → 실차에 피드백 |
실시간 동기화가 있느냐가 갈림길이다.