인지야공/강의 요약/7번째 글
자율주행이동체 ① AUTOSAR 와 소프트웨어 정의 차량
자율주행이동체 과목의 기말 범위를 세 편으로 나눠 정리한다. 이 글은 차량 소프트웨어 아키텍처를 다룬다. ②는 안전과 보안 표준, ③은 커넥티드·전동화·인지 쪽에 있다.
AUTOSAR 란
AUTomotive Open Systems ARchitecture — 자동차 제조사(OEM), 부품사(Tier1), 도구 공급사들이 공동으로 만든 차량 소프트웨어 미들웨어 및 시스템 표준이다. 2003년에 시작해 현재 350개 이상 기관이 참여한다.
모토가 이 표준의 성격을 그대로 말해 준다.
표준으로 협력하고, 구현으로 경쟁한다 (Cooperate on standards, compete on implementations)
인터페이스와 구조는 같이 만들되, 그 안에서 얼마나 잘 구현하느냐로 경쟁한다는 뜻이다.
목표는 SW 컴포넌트의 이식성·조합성·통합성을 차량 수명 주기 내내 보장하는 것이다.
왜 필요한가 — 자동차 한 대에 ECU 가 100개 이상 들어간다. 각 부품사가 제각각 SW 를 만들면 통합이 불가능해진다. AUTOSAR 가 인터페이스 규격을 정해 주면 A사 ECU 에서 만든 SW 가 B사 ECU 에서도 동작한다.
Classic 과 Adaptive
차량 안에는 두 종류의 컴퓨팅 환경이 공존한다. 엔진을 1ms 단위로 제어하는 초실시간 ECU 와, 카메라 영상을 딥러닝으로 처리하는 고성능 AI 컴퓨터다. 이 둘에 각각 Classic 과 Adaptive 가 대응한다.
| 항목 | Classic AUTOSAR | Adaptive AUTOSAR |
|---|---|---|
| 대상 HW | 마이크로컨트롤러(MCU) — 작고 저전력 | 고성능 애플리케이션 프로세서(AP) — 자율주행 컴퓨터 수준 |
| 운영체제 | 자체 RTOS — 정해진 시간 안에 반드시 동작 | POSIX 기반(리눅스 등) — 범용 OS |
| SW 구성 | 정적 — 컴파일 타임에 모든 구조 확정. 런타임 변경 불가 | 동적 — 실행 중에도 서비스 연결·해제 가능 |
| 통신 | RTE 를 통한 고정 연결 | SOA 기반. 런타임에 서비스를 동적 발견 |
| OTA | 제한적 | 완전 지원 |
| 용도 | 엔진 제어, 변속기, ABS, 에어백 — 안전 필수 | 자율주행 AI 추론, OTA, 인포테인먼트 — 고성능 연산 |
| Release | 여러 버전 병행 | R25-11 (2025년 기준 최신) |
외우는 방법을 이렇게 잡았다.
Classic = 과거의 확정된 세계 (정적, RTOS, MCU) Adaptive = 클라우드처럼 유연한 세계 (동적, POSIX OS, AP)
SDV/AIDV 시대의 핵심은 Adaptive AUTOSAR 다.
Classic 의 계층 구조
5개 계층에 Complex Driver 가 붙는다. 위에서 아래로 내려간다.
| 계층 | 역할 |
|---|---|
| Application Layer 응용 | SWC 들이 모여 있는 곳. 에어백 제어, 크루즈 컨트롤 등 실제 차량 기능 |
| RTE 런타임 환경 | VFB 를 실제 ECU 위에서 구현한 중간 다리. SWC 가 같은 ECU 든 다른 ECU 든 동일한 방식으로 통신하게 해 준다 |
| Service Layer 서비스 | OS, 통신 서비스(CAN/LIN/FlexRay), 비휘발성 메모리 관리, 진단 등 공통 기반 기능 |
| ECU Abstraction Layer | 어떤 ECU 하드웨어를 쓰든 위 계층에서 동일한 인터페이스로 접근하게 숨긴다 |
| MCAL 마이크로컨트롤러 추상화 | 가장 아래. MCU 레지스터에 직접 접근. DIO, ADC, PWM, SPI, CAN 드라이버 |
| Complex Driver 복합 드라이버 | 표준 구조로 담기 어려운 특수 센서·액추에이터 제어. 인젝터, 전자 밸브, 위치 검출기. 표준 포트 인터페이스는 반드시 지켜야 한다 |
Complex Driver 가 존재하는 이유가 현실적이다. 표준으로 다 덮을 수 없는 것이 반드시 남는데, 그걸 표준 밖에 두되 포트만은 표준을 지키게 해서 나머지 구조를 오염시키지 않는다.
VFB — 가상 기능 버스
SWC 들이 서로 어떤 ECU 에 있든 관계없이 통신할 수 있게 해 주는 가상의 통신 채널이다.
- 설계 단계 — VFB 로 추상적으로 컴포넌트 간 연결을 그린다
- 구현 단계 — 실제 ECU 배치 후 RTE 가 물리적 통신(CAN, FlexRay)으로 자동 변환한다
- SWC 입장 — “상대가 같은 ECU 인지 다른 ECU 인지 몰라도 된다”
VFB 와 RTE 의 구별이 시험 빈출이다. VFB 는 논리적 개념(설계 단계)이고, RTE 는 실제 코드로 생성된 것(구현 단계)이다.
SWC — 소프트웨어 컴포넌트
AUTOSAR 의 기본 기능 단위다. 차량 기능 하나하나를 캡슐화한 모듈.
| 특성 | |
|---|---|
| 하드웨어 독립성 | 어떤 ECU·MCU 에 올라가도 동작한다. MCAL 이 하드웨어 차이를 숨겨 준다 |
| 포트 기반 통신 | 반드시 Port 를 통해서만 외부와 데이터를 교환한다. PPort(제공) / RPort(요구) |
| SWC Description | 인터페이스·자원 요구량·구현 정보를 담은 형식 문서. 이게 있어야 다른 시스템에 통합할 수 있다 |
통신 패턴은 둘이다.
| 패턴 | 동작 | 특징 | 예 |
|---|---|---|---|
| Client-Server | 클라이언트가 요청 → 서버가 처리 후 응답 | 동기/비동기 선택 가능. 서버는 요청을 기다린다 | “현재 엔진 오류 코드 알려줘” → 응답 |
| Sender-Receiver | 송신자가 뿌리면 수신자들이 알아서 읽어 간다 | 완전 비동기. 송신자는 누가 몇 명이 받는지 모른다 | 차속 데이터를 에어컨·크루즈컨트롤·내비게이션이 동시에 읽는다 |
차속처럼 여러 곳이 동시에 필요로 하는 값은 Sender-Receiver, 진단처럼 응답이 필요한 요청은 Client-Server 다.
Adaptive 의 핵심
자율주행·인포테인먼트 등 고성능 연산 영역을 위한 플랫폼이다. Classic 과 가장 결정적으로 다른 점은 동적 서비스 연결이다.
| ARA (Adaptive Runtime for Applications) | Adaptive 의 실행 환경. Services 와 APIs 두 종류의 인터페이스를 제공 |
| Functional Cluster | 플랫폼 기능을 묶은 단위. 통신 관리, 실행 관리, 진단, 보안, 시간 동기화. 각 클러스터는 (가상) 머신당 최소 1개 인스턴스 필요 |
| 동적 서비스 발견 | Classic 은 컴파일 타임에 RTE 가 모든 연결을 확정. Adaptive 는 런타임에 서비스를 찾아 연결 |
| SOA 적용 | 차량 기능을 마이크로서비스로 분리 → OTA 로 특정 서비스만 업데이트 |
정리하면 Classic RTE = 정적(컴파일 타임 결정), Adaptive ARA = 동적(런타임 결정) 이고, 이 차이가 SOA 와 OTA 를 가능하게 한다.
자율주행의 AI
ANI / AGI / ASI
| 유형 | 특성 | 자율주행 |
|---|---|---|
| ANI 협소 AI | 특정 목적 하나만 잘한다. 체스 AI 는 체스만 | SAE L1~L4. 현재 자율주행 AI 전부가 ANI 다 |
| AGI 범용 AI | 인간처럼 여러 분야를 스스로 학습·추론. 아직 없다 | SAE L4~L5 의 이론적 기반 |
| ASI 초지능 | 인간을 모든 면에서 초월. 현재는 SF | Perfect Driver — 먼 미래 |
ANI 의 4대 한계 — ① 블랙박스(설명 불가) ② 사이버보안 취약 ③ 대량 데이터 필요 ④ 편향 위험.
신뢰 가능한 AI 4요소
자율주행 AI 가 상용화되려면 성능 외에 넷을 모두 충족해야 한다.
| 요소 | 의미 | 자율주행에서 왜 중요한가 |
|---|---|---|
| Valid AI | 검증된 방법론으로 통계적 타당성 확보. “진짜로 성능이 있는가”를 수치로 증명 | 무작위 테스트가 아닌 표준화된 시나리오로 검증해야 한다 |
| Explainable AI (XAI) | 왜 그 판단을 했는지 인간이 이해할 수 있어야 한다 | 사고가 났을 때 설명하지 못하면 법적 책임 규명이 불가능하고 시스템 개선도 못 한다 |
| Responsible AI | 편향 없고 책임 소재가 명확. 거버넌스 체계 | 훈련 데이터 편향 → 특정 인종·성별 보행자를 잘 인식하지 못하는 문제 |
| Privacy-Preserving AI | 학습·추론 과정에서 개인정보 보호. 연합 학습 등 | 차량 이동 데이터 = 개인의 생활 패턴이 드러나는 민감 정보 |
XAI 가 자율주행에서 특히 중요한 이유가 명확하다. 성능 지표가 아니라 사고 후 책임 규명 때문이다.
AVOps
DevOps 를 자율주행에 적용한 반복 순환 구조다. 데이터 수집부터 실차 배포까지 끊임없이 돈다.
| 단계 | 활동 | 핵심 |
|---|---|---|
| DataOps | 카메라·LiDAR 로그 수집 → 어노테이션 → 품질 관리 | 데이터 다양성과 품질이 AI 성능을 결정 |
| MLOps | 모델 선택·학습·평가·패키징 | 비결정론적 거동을 어떻게 평가할지가 핵심 과제 |
| ValidationOps | 시뮬레이션 + 실차 V&V | HiL, 시나리오 기반 테스트, Ground Truth 비교 |
| DevOps | 빌드·배포·OTA·모니터링 | CI/CD, 커넥티드 플릿, 텔레메트리 |
가장 어려운 지점은 AI 모델이 비결정론적이라는 것이다. 같은 입력에도 확률적으로 다른 출력이 나올 수 있어서, 전통적인 소프트웨어 검증 방법을 그대로 적용할 수 없다.
SDV — 소프트웨어 정의 차량
차량의 기능이 하드웨어가 아닌 소프트웨어로 정의되고, OTA 로 기능을 추가·개선할 수 있는 차량 아키텍처다.
- 전통 차량 — 하드웨어 중심. 기능 변경 시 부품 교체 필요(공장 방문 필수)
- SDV — OTA 패치만으로 새 기능 추가(집에서 자는 동안 업데이트)
| 핵심 요소 | |
|---|---|
| Zonal Architecture | 도메인별 분산 구조(엔진 ECU, 샤시 ECU…)에서 차량을 구역으로 나눠 Zone ECU 하나가 통합 관리. 배선 감소, 중앙 집중화 |
| OTA Update | 무선으로 SW·펌웨어 업데이트. Tesla 가 대중화 |
| SOA | 차량 기능을 마이크로서비스로 분리해 유연하게 조합. Adaptive AUTOSAR 기반 |
| HPC | 자율주행·AI 추론용 고성능 차량 내 컴퓨팅. Nvidia Drive, Qualcomm Snapdragon Ride |
배선 감소가 생각보다 큰 이야기다. 고급차의 와이어링 하네스는 수 킬로미터에 무게도 수십 킬로그램이다. 구역별로 묶으면 그게 줄어든다.
AIDV — AI 정의 차량
SDV 를 넘어, AI 모델이 차량의 핵심 로직을 결정하고 스스로 진화하는 단계다.
| 구분 | SDV | AIDV |
|---|---|---|
| 핵심 동력 | 소프트웨어 (고정된 알고리즘) | 생성형 AI + Physical AI (자율 판단) |
| 업데이트 | 기능 중심 SW 패치 (OTA) | 지속적인 AI 모델 학습 및 배포 |
| 운전자 경험 | 표준화된 기능 (기성복) | 초개인화된 맞춤형 지능 (수동→능동) |
| 시스템 구조 | 중앙 집중식 컴퓨팅 (Zonal) | 온디바이스 AI 기반 자율 판단 |
NVIDIA 가 제시한 AIDV 의 세 가지 핵심 가치.
| Self-Learning | 주행 데이터와 운전자 습관을 실시간 학습해 차량이 사용자에게 최적화된다 |
| End-to-End AI | 센서 입력에서 차량 제어 출력까지 AI 가 통합 관리. 중간 모듈의 복잡도가 줄어든다 |
| Digital Twin | Omniverse 가상 시뮬레이션으로 물리적 한계를 극복하고 안전성을 극대화 |
연합 학습
각 차량이 로컬에서 학습한 결과, 즉 가중치만 클라우드로 전송해 집계하는 분산 학습 방식이다.
| 기존 방식 | 모든 차량의 원본 주행 데이터를 클라우드에 업로드 → 개인정보 침해 위험 |
| 연합 학습 | 각 차량이 자기 데이터로 로컬 학습 → 학습된 가중치만 전송 → 클라우드에서 집계(평균) → 개선된 모델을 다시 배포 |
결과는 둘이다 — 원본 데이터는 차 밖으로 나가지 않고, 동시에 수백만 대의 주행 경험이 하나의 AI 모델에 통합된다.
데이터는 공유하지 않고 지식(가중치)만 공유한다. 개인정보 보호와 집단 지성을 동시에 달성한다.
SOAFEE
Scalable Open Architecture for Embedded Edge — Arm 이 2021년 발표한 자동차 SW 아키텍처이자 오픈소스 레퍼런스 구현체다. 창립 파트너는 Arm, AWS, Bosch, CARIAD(VW), Continental, RedHat, SUSE 등 108개사.
핵심 아이디어는 한 줄이다 — 클라우드에서 쓰는 컨테이너 기술을 차량 임베디드 환경에 가져오자. 목표는 “클라우드에서 개발 → 차량에 그대로 배포”로 개발 비용을 줄이고 검증 속도를 높이는 것이다. 기능 안전(ASIL), 사이버보안, 실시간 요구사항, 시간·공간 파티셔닝을 모두 포함한다.
| 구성 요소 | 역할 |
|---|---|
| EWAOL (Edge Workload Abstraction & Orchestration Layer) | 레퍼런스 SW 스택의 핵심 레이어. 컨테이너 런타임, 네트워크, 오프플랫폼 연결. Arm 이 오픈소스로 제공 |
| Mixed Criticality Orchestrator | 안전 등급이 다른 SW 를 같은 플랫폼에서 격리 실행. ASIL-D 서비스와 QM 서비스를 한 컴퓨터에서 안전하게 분리 |
| Container Runtime | 앱을 컨테이너로 패키징. Docker/Kubernetes 개념을 차량에 적용 |
| HAL | 다양한 HW 위에 일관된 SW 인터페이스 제공 |
| Hypervisor | 하나의 CPU 에서 RTOS 와 일반 OS 를 동시에 격리 실행. 안전 기능과 일반 앱이 서로 방해하지 않도록 |
“SOAFEE 의 레퍼런스 SW 스택”을 묻는다면 답은 EWAOL 이다. Autoware OpenAD Kit 가 SOAFEE 위에서 실행되는 대표 사례다.
SOAFEE 와 Adaptive AUTOSAR 는 경쟁 관계가 아니다 — SOAFEE 는 컨테이너·클라우드 기술을 차량에 적용하는 아키텍처 프레임워크이고, Adaptive AUTOSAR 는 고성능 AP 기반 동적 SW 플랫폼 표준이다. 둘은 함께 쓰인다.