제8부 자율주행

8.6 DRIVE OS I — 하이퍼바이저·RTOS

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

8.2~8.5에서 DRIVE SoC의 하드웨어(이기종 엔진)를 봤다. 이 장은 그 위의 기반 OS — DRIVE OS — 를 판다. 하드웨어가 아무리 강력해도, 결정성(하드 실시간)과 격리(혼합 criticality) 를 보장하는 OS가 없으면 자율주행은 안전하지 않다. 범용 리눅스만으로는 데드라인을 보장(8.1) 하거나 안전/비안전을 격리(8.3) 할 수 없다. DRIVE OS는 하이퍼바이저(격리) + RTOS(실시간) + 리눅스(풍부) + CUDA/TensorRT 런타임 + 안전 서비스를 묶어 이를 제공한다. 이것이 안전(8.8)의 토대다.

핵심 통찰: 자율주행 OS는 "성능"이 아니라 "결정성과 격리"를 판다. RTOS는 최악 지연을 보장(8.1의 데드라인)하고, 하이퍼바이저는 혼합 criticality를 격리(안전 critical AV와 비안전 IVI가 한 칩에 있어도 서로 영향 못 줌, 8.3). 그 핵심 개념이 간섭으로부터의 자유(Freedom From Interference, FFI) — 공간(메모리)·시간(스케줄) 격리로 한 곳의 결함이 안전 critical 기능에 전파되지 못하게. 안전은 안전한 OS 위에서만 가능하다.

배우는 것:

DRIVE OS가 무엇인가 — 기반 SW 스택(하이퍼바이저·OS·드라이버·CUDA/TRT·안전 서비스), 왜 특수 OS인가.
하이퍼바이저 — SoC를 격리된 파티션으로, 혼합 criticality(안전/비안전)·다중 OS.
RTOS — 하드 실시간(최악 지연 보장)·우선순위·선점, 리눅스와의 차이.
간섭으로부터의 자유(FFI) — 공간(메모리)·시간(스케줄) 격리, 안전의 핵심.
왜 안전의 토대인가 — OS/하이퍼바이저가 안전 케이스의 일부(인증, 8.8).

선수 지식: 8.1(결정성·실시간·안전)·8.3(혼합 criticality·격리)·8.2(이기종 SoC), 5.2(CUDA/TensorRT 런타임). 기능안전은 8.8~8.11, 미들웨어·통신은 8.7. 환경은 DRIVE 플랫폼.

정직: DRIVE OS의 구성요소·하이퍼바이저·OS·인증 범위는 세대·버전 의존이다 — 이 장은 결정성·격리·FFI의 원리(표준 안전 개념)를 가르치고 구체 구성은 "확인 필요". 자율주행은 safety-critical — 실제 안전 설계·인증은 자격 있는 기능안전 엔지니어·표준(ISO 26262, 8.8)의 영역이고, 이 장은 그 토대 개념을 설명한다.

8.6.2 왜 특수 OS — 범용 리눅스로 부족

데스크톱·서버는 리눅스로 충분하지만, 자율주행은 두 가지를 리눅스만으로 못 한다:

그래서 DRIVE OS는 계층화된 기반 SW를 제공한다:

— DRIVE OS 스택(개념).

핵심: DRIVE OS는 "리눅스 대체"가 아니라 결정성(RTOS)·격리(하이퍼바이저)·안전 서비스를 더한 기반 SW다. 리눅스도 그 안에서(비안전 파티션) 쓰되, 안전·실시간은 RTOS·하이퍼바이저가 보장. 안전은 이 토대 위에서만 쌓을 수 있다.

8.6.3 하이퍼바이저 — 격리·파티셔닝

하이퍼바이저는 SoC를 격리된 파티션(VM) 으로 나눈다 — 8.3의 도메인 통합(AV+IVI 한 칩)을 안전하게 가능케 하는 핵심.

하이퍼바이저가 하는 것:

혼합 criticality 격리: 안전 critical(AV, ASIL D)과 비안전(IVI, Linux)을 한 SoC에 두되 격리 — 비안전의 결함·과부하·악성이 안전 기능에 전파 못 함(FFI, 8.6.5).
다중 OS: 파티션마다 적합한 OS — 안전·실시간엔 RTOS, 풍부·비안전엔 Linux. 한 칩에 공존.
자원 파티셔닝: CPU 코어·메모리·디바이스를 파티션에 격리 할당 — 한 파티션이 다른 파티션 자원을 침범 못 함.
안전 보장: 하이퍼바이저 자체가 안전 케이스의 일부(인증, 8.8) — 격리가 보장돼야.

핵심: 하이퍼바이저가 8.3의 "AV+IVI 한 칩"을 안전하게 만든다. 격리 없이 통합하면 IVI 결함이 AV 안전을 위협하지만, 하이퍼바이저의 공간·시간 격리로 안전 파티션을 보호. 도메인 통합의 전제가 하이퍼바이저다.

8.6.4 RTOS — 하드 실시간

RTOS(Real-Time OS) 는 안전·실시간 파티션에서 데드라인을 보장한다(8.1의 결정성).

RTOS vs 리눅스 — 무엇을 어디에:

RTOS: 하드 실시간·결정성·안전 인증(ASIL). 기능은 제한적이나 보장이 핵심. 안전 critical 태스크.
Linux: 풍부한 기능·생태계·개발 편의. 비안전·비실시간. 보장은 약함.
분할: 안전·실시간은 RTOS, 나머지는 Linux — 하이퍼바이저가 격리. CUDA·TensorRT(5.2·8.4)도 적절한 파티션에서.

핵심: "안전·실시간은 RTOS, 풍부함은 Linux" 가 자율주행 OS 분할의 정석이다. 리눅스의 풍부함이 좋지만 하드 실시간 보장이 없어 안전 루프에 못 쓴다 — RTOS가 데드라인을 보장하고, 둘을 하이퍼바이저로 격리해 공존. 결정성이 성능보다 우선(8.1).

8.6.5 간섭으로부터의 자유(FFI) — 안전의 핵심

혼합 criticality의 핵심 안전 개념: 간섭으로부터의 자유(Freedom From Interference, FFI) — 낮은 무결성(비안전) 요소의 결함이 높은 무결성(안전) 요소에 영향을 주지 못함.

왜 중요한가(안전, 8.8):

혼합 criticality의 전제: AV(ASIL D)와 IVI(비안전)를 한 칩에 두려면 FFI가 보장돼야 — 안 그러면 IVI 결함이 AV를 위협해 통합이 안전하지 않음(8.3).
안전 케이스의 일부: ISO 26262는 혼합 criticality 시 FFI를 요구 — OS/하이퍼바이저가 이를 제공·인증해야(8.8).
장애 격납: 한 요소가 고장 나도(공간·시간 격리로) 다른 요소가 계속 — fail-operational(8.9)의 기반.

핵심: FFI가 "안전을 안전한 OS 위에서만 쌓을 수 있다"의 구체적 의미다 — 하드웨어(MMU·파티션)·하이퍼바이저·RTOS·자원 예산이 공간·시간 격리를 구현해야, 혼합 criticality·통합·중복화가 안전하다. 격리가 보장 안 되면 그 위의 어떤 안전 설계도 무너진다.

8.6.6 왜 안전의 토대 — OS가 안전 케이스의 일부

자율주행 안전(8.8)은 OS·하이퍼바이저 위에서만 성립한다:

인증된 기반: RTOS·하이퍼바이저가 안전 인증(ASIL)돼야 — 안전 critical 기능이 그 위에서 돌므로, OS가 안전 케이스의 일부.
결정성 보장: OS가 데드라인을 보장 못 하면 위의 어떤 안전 로직도 제때 실행되지 못해 무의미.
격리 보장: FFI가 없으면 비안전 결함이 안전을 오염 → 혼합 criticality·통합 불가.

견해: 안전은 사후에 못 붙인다 — 토대(OS·하이퍼바이저)부터 안전이어야 한다(8.1·8.8 반복). 풍부한 리눅스에 안전 로직을 덧붙인다고 안전해지지 않는다(결정성·FFI 없음). RTOS·하이퍼바이저·하드웨어 안전 기능이 결정성·격리를 보장·인증하고, 그 위에 AV 안전을 쌓는다. 이것이 DRIVE OS가 "기반 OS"인 이유.

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

[ ] 범용 리눅스만으로 부족한 두 가지(하드 실시간 결정성·혼합 criticality 격리)를 안다.
[ ] 하이퍼바이저가 SoC를 파티션으로 격리해 혼합 criticality·다중 OS·자원 파티셔닝을 줌을 안다.
[ ] RTOS가 최악 지연을 보장(하드 실시간)하고, 리눅스와의 분할(안전·실시간=RTOS, 풍부=Linux)을 안다.
[ ] FFI(공간·시간 격리) 가 혼합 criticality 안전의 핵심임과, MMU·하이퍼바이저·예산이 구현함을 안다.
[ ] OS/하이퍼바이저가 안전 케이스의 일부(결정성·FFI 보장·인증)이며 안전의 토대임을 안다.

증상→의심: 인지 루프가 가끔 데드라인 초과(jitter) → 리눅스 비결정성 → RTOS 파티션. 비안전 IVI 결함이 AV에 영향 → FFI 부족 → 하이퍼바이저 격리·자원 예산. 혼합 criticality 인증 막힘 → FFI 미보장 → 공간·시간 격리. 리눅스에 안전 로직을 덧붙여 안전 주장 → 결정성·FFI 없음 → RTOS·하이퍼바이저 토대. 자원 경합으로 안전 태스크 밀림 → 시간 격리 부족 → 예산·우선순위. 메모리 오류 전파 → 공간 격리 부족 → MMU·파티션.

8.6.8 트레이드오프·대안

결정	트레이드오프
RTOS vs Linux(파티션)	결정성·인증·제한 vs 풍부·생태계·비결정
통합(하이퍼바이저) vs 분리 칩	비용·SDV·격리 검증 vs 단순(8.3)
격리 강도	안전 보장 vs 자원 공유·오버헤드
인증 OS vs 범용	안전 케이스·비용 vs 유연·미인증

견해: 안전·실시간은 RTOS, 풍부함은 Linux, 격리는 하이퍼바이저 — 혼합 criticality를 한 칩에 안전하게(FFI). 인증된 기반이 비용·제약이 있지만 안전 critical엔 필수(사후 불가). 격리는 약간의 자원·오버헤드를 내주고 안전을 산다. 모든 안전 결정은 자격 있는 기능안전 엔지니어·표준(8.8) 의 영역 — 이 장은 토대 개념.

비엔비디아 정직: 안전 OS·하이퍼바이저는 자동차 업계 표준 접근이고 여러 공급자(QNX·다른 RTOS·하이퍼바이저)가 있다. DRIVE OS의 강점은 NVIDIA SoC·이기종 엔진(GPU/DLA/PVA)과의 통합·CUDA/TensorRT 런타임·안전 서비스·인증이다. OS 구성·인증 범위는 세대 의존 — 실제 안전 설계는 표준·인증·검증으로, 이 장은 원리.

8.6.9 흔한 함정

리눅스로 안전·실시간. 리눅스는 하드 실시간 보장이 약함(jitter) — 안전 루프는 RTOS.
격리 없이 통합. AV+IVI를 한 칩에 FFI 없이 두면 비안전 결함이 안전 위협 → 하이퍼바이저·FFI(8.3).
FFI를 공간만 또는 시간만. 둘 다 필요 — 메모리(공간) + 스케줄/예산(시간) 격리. 하나만으론 불충분.
안전을 사후에. 풍부한 OS에 안전 로직 덧붙이기 ≠ 안전 — 토대(결정성·FFI)부터(8.1·8.8).
OS를 안전 케이스에서 제외. OS/하이퍼바이저가 안전 케이스의 일부 — 인증·보장 필요.
결정성 = 빠름 오해. 결정성은 "최악 지연 보장"이지 평균 속도가 아님 — RTOS가 평균은 느려도 보장.
자원 예산 없음. 시간 격리(CPU 예산)가 없으면 한 파티션 과부하가 안전 태스크 데드라인을 깸.
구성을 버전 불문. DRIVE OS·하이퍼바이저·인증이 세대 의존 — 확인.

8.6.10 연습문제

연습 1 (왜 특수 OS). 데이터센터 엔지니어가 "리눅스에 우리 AV 소프트웨어를 탑재하면 되지"라고 한다. 범용 리눅스만으로 안 되는 두 가지를 설명하라.

정답

① 하드 실시간(결정성): 자율주행은 인지~제어 루프의 최악 지연(worst-case)이 데드라인 안에 보장돼야 안전(8.1) — 가끔 늦으면(jitter) 위험한 결정. 범용 리눅스는 처리량·기능 우선이라 스케줄링이 최악 지연을 보장 못 함(jitter·비결정적) → 안전 루프에 부적합. RTOS가 우선순위 선점·무한 블로킹 방지로 데드라인을 보장. ② 혼합 criticality 격리(FFI): 한 SoC에 안전 critical AV(ASIL D)와 비안전(IVI·일반 앱)을 두면(8.3 통합), 비안전의 결함·과부하·악성이 안전 기능에 영향을 주면 안 됨(간섭으로부터의 자유). 범용 리눅스는 이런 강한 격리·안전 보장이 부족 → 하이퍼바이저가 공간(메모리)·시간(스케줄) 격리로 파티션을 분리. 즉 리눅스는 풍부하나 결정성·격리 보장이 없어 안전 critical에 단독으론 부적합. DRIVE OS는 RTOS(실시간)+하이퍼바이저(격리)를 더하고, 리눅스도 비안전 파티션에서 쓴다. 안전은 안전한 OS 토대 위에서만.

연습 2 (RTOS vs Linux). 자율주행 시스템의 다음을 RTOS 파티션과 Linux 파티션 중 어디에: (a) 인지~제어 안전 루프, (b) 안전 모니터, (c) 인포테인먼트 UI, (d) 비실시간 데이터 로깅·일부 AI 개발 도구.

정답

(a) 인지~제어 안전 루프 → RTOS — 안전 critical·하드 실시간(매 사이클 데드라인 보장 필요, 8.1), 결정성·인증(ASIL)이 핵심. 리눅스의 jitter는 위험. (b) 안전 모니터 → RTOS — 안전 감시는 결정적·인증돼야, 안전 critical. (c) 인포테인먼트 UI → Linux — 비안전·풍부한 그래픽/UI/앱 생태계가 필요, 하드 실시간 불필요. 하이퍼바이저로 안전 파티션과 격리(FFI). (d) 비실시간 데이터 로깅·AI 개발 도구 → Linux — 비안전·비실시간·풍부한 도구/생태계, 리눅스가 편의. 분할 원리: 안전 critical·하드 실시간(인지 제어·안전 모니터) = RTOS(결정성·인증), 풍부·비안전·비실시간(IVI·로깅·개발) = Linux(기능·생태계). 하이퍼바이저가 둘을 격리해 한 SoC에 공존(FFI) — 비안전 Linux 파티션의 결함이 RTOS 안전 파티션에 영향 못 주게. CUDA/TensorRT는 적절한 파티션에서(추론이 안전 경로면 RTOS측 보장 하에). "안전은 RTOS, 편의는 Linux"가 정석.

연습 3 (FFI). 간섭으로부터의 자유(FFI)가 무엇이고, 공간·시간 격리가 각각 무엇을 막는지, 왜 혼합 criticality에 필수인지 설명하라.

정답

FFI(Freedom From Interference): 낮은 무결성(비안전) 요소의 결함이 높은 무결성(안전) 요소에 영향을 주지 못함을 보장 — 혼합 criticality의 핵심 안전 속성. 두 격리: ① 공간(spatial) 격리 — 메모리(MMU·파티션)로 한 요소가 다른 요소의 메모리를 침범 못 하게. 막는 것: 비안전 파티션의 메모리 오류·오버런·포인터 버그가 안전 파티션의 데이터·코드를 건드려 오염시키는 것. ② 시간(temporal) 격리 — 스케줄링·자원 예산(CPU 시간 budget)으로 한 요소가 다른 요소의 CPU·시간을 뺏지 못하게. 막는 것: 비안전 파티션의 과부하·무한루프·폭주가 안전 태스크의 CPU를 독점해 데드라인을 깨는 것. 둘 다 있어야 FFI(하나만으론 불충분 — 메모리는 격리됐어도 CPU를 뺏기면 데드라인 깨짐). 혼합 criticality 필수 이유: AV(ASIL D)와 IVI(비안전)를 한 칩에 두려면(8.3 통합·비용), 비안전의 결함이 안전을 위협하지 않아야 — FFI가 없으면 통합이 안전하지 않아 ISO 26262 인증 불가(8.8). 하이퍼바이저·RTOS·MMU·자원 예산이 FFI를 구현·보장하고 안전 케이스의 일부로 인증. FFI가 "안전한 OS 위에서만 안전을 쌓는다"의 구체적 의미.

연습 4 (안전 토대). "리눅스 위에 안전 로직을 잘 구현하면 안전한 자율주행이 된다"는 주장을 반박하라.

정답

반박: 안전은 토대(OS·하이퍼바이저)부터 보장돼야 하고, 사후에 못 붙인다. 리눅스 위 안전 로직이 안 되는 이유: ① 결정성 없음 — 리눅스는 하드 실시간 보장이 약해(jitter), 안전 로직이 아무리 잘 구현돼도 제때 안 돌면(데드라인 초과) 무의미(8.1). 안전 로직이 50ms 늦게 실행되면 그 순간 사고. ② FFI 없음 — 리눅스에 안전+비안전이 섞이면 비안전 결함(메모리·CPU 폭주)이 안전 로직을 오염·차단 → 공간·시간 격리가 없으면 안전 보장 붕괴. ③ 인증 — ISO 26262는 안전 critical 기능이 실행되는 OS 자체가 안전 케이스의 일부로 인증되길 요구(ASIL) — 범용 리눅스는 그 인증·보장이 없어 안전 케이스가 성립 안 됨. ④ 장애 격납 — OS가 격리·내결함을 보장 못 하면 한 결함이 전체로 전파. 즉 안전 로직의 정확성과 무관하게, 그것이 실행되는 토대가 결정성·FFI·인증을 보장 못 하면 안전하지 않다. 올바른 접근: RTOS(결정성)·하이퍼바이저(FFI·격리)·하드웨어 안전 기능(락스텝, 8.2) 의 인증된 토대 위에 안전 로직을 쌓고, 그 전체를 안전 케이스로 검증(8.8). 풍부함(리눅스)은 격리된 비안전 파티션에. 안전은 위에서 아래로가 아니라 아래에서 위로.

연습 5 (설계). L4 AV+IVI 통합 SoC의 OS 아키텍처를 FFI·결정성 관점에서 설계하라.

정답

설계: ① 하이퍼바이저로 파티션 분할 — SoC를 격리된 파티션으로. 안전 파티션(RTOS): 인지~제어 안전 루프·안전 모니터(ASIL D), 하드 실시간 결정성·인증. 비안전 파티션(Linux): IVI·UI·로깅·비실시간. (필요시 추가 안전 파티션·중복.) ② FFI 보장 — 공간 격리(MMU/하드웨어 파티션으로 파티션 간 메모리 침범 차단) + 시간 격리(CPU 코어·시간 예산을 파티션에 격리 할당해 비안전 과부하가 안전 태스크 데드라인을 못 깸). 디바이스(GPU·DLA·PVA)도 파티션에 격리 할당·중재. ③ 결정성 — 안전 파티션 RTOS가 우선순위 선점·무한블로킹 방지로 종단 지연(센서→제어) 데드라인 보장. ④ 중복화 연계(8.9) — fail-operational 위해 안전 기능을 이중 컴퓨팅·다양성(다른 경로)으로, OS가 장애 격납·전환 지원. ⑤ CUDA/TensorRT 추론 — 안전 경로 인지는 안전 파티션 보장 하에(DLA 결정성, 8.4), 비안전 AI는 Linux측. ⑥ 인증 — 하이퍼바이저·RTOS·전체를 ISO 26262 안전 케이스로(8.8). 핵심: 통합(비용·SDV)을 FFI(공간+시간 격리)로 안전하게, 안전·실시간은 RTOS, 풍부함은 Linux, 둘을 하이퍼바이저로 격리. 모든 안전 결정은 자격 있는 기능안전 엔지니어·표준의 영역(8.8) — 이것은 토대 아키텍처. L4는 중복화까지(8.9).

8.6.11 요약 · 다음 장

DRIVE OS는 SoC 위의 기반 SW — 하이퍼바이저(격리)·RTOS(실시간)·Linux(풍부)·CUDA/TensorRT 런타임·안전 서비스를 묶는다. 범용 리눅스만으로는 하드 실시간 결정성·혼합 criticality 격리를 못 줘 자율주행에 부족.
하이퍼바이저는 SoC를 격리된 파티션으로 나눠 혼합 criticality(안전 AV + 비안전 IVI)·다중 OS·자원 파티셔닝 — 8.3 통합을 안전하게.
RTOS는 최악 지연을 보장(하드 실시간)해 안전 루프의 데드라인을. 안전·실시간은 RTOS, 풍부함은 Linux 로 분할, 하이퍼바이저로 격리.
FFI(공간 메모리 + 시간 스케줄 격리) 가 혼합 criticality 안전의 핵심 — 비안전 결함이 안전에 전파 못 하게. OS/하이퍼바이저가 구현·인증.
안전은 안전한 OS 토대 위에서만 — OS/하이퍼바이저가 결정성·FFI를 보장·인증해야 그 위 안전 설계가 유효(사후 불가). 정직: 구성·인증 세대 의존, safety-critical은 자격 있는 엔지니어·표준(8.8)의 영역.

다음 장: 8.7 DRIVE OS II — 미들웨어·통신·DRIVE 스택. 기반 OS 위의 미들웨어 계층 — 센서·컴퓨트·액추에이터를 잇는 결정적 통신(DDS류·시간 동기화), 컴포넌트 프레임워크, 그리고 DriveWorks(8.13)로 이어지는 DRIVE 스택을 본다. 이로써 DRIVE OS(8.6~8.7)를 마무리한다.