AUTOSAR Adaptive vs Classic — 뭐가 다르고, 어떻게 공존하는가

AUTOSAR, 한 번은 정리하고 넘어가자

자동차 소프트웨어 개발을 하다 보면 AUTOSAR라는 단어를 피할 수가 없습니다. 그런데 막상 "AUTOSAR가 정확히 뭐냐"고 물으면 깔끔하게 설명하기가 쉽지 않습니다. Classic이 있고 Adaptive가 있고, 둘이 다른 건 알겠는데 구체적으로 뭐가 다른지, 왜 두 개가 따로 있는지를 제대로 아는 사람은 의외로 많지 않습니다.

이번 글에서 한 번 정리해 보겠습니다.

AUTOSAR가 뭔가요?

AUTOSAR(AUTomotive Open System ARchitecture)는 자동차 소프트웨어의 표준 아키텍처입니다. 2003년, 유럽 주요 OEM과 Tier1 부품사들이 공동으로 설립했습니다. 현재는 전 세계 350개 이상의 파트너 조직이 참여하고 있는 글로벌 컨소시엄입니다.

핵심 목적은 간단합니다. 자동차 ECU(전자제어장치)에 들어가는 소프트웨어를 표준화해서, 하드웨어가 바뀌어도 소프트웨어를 재사용할 수 있게 만드는 것입니다. 쉽게 말하면, "하드웨어와 소프트웨어를 분리하자"는 것이 AUTOSAR의 근본 철학입니다.

그런데 자동차가 진화하면서 문제가 생겼습니다. 초기에 만든 표준으로는 자율주행이나 커넥티드카 같은 새로운 요구사항을 감당할 수 없게 된 것입니다. 그래서 등장한 것이 Adaptive Platform입니다.

Classic Platform — 검증된 기본기

Classic Platform(CP)은 AUTOSAR의 원조입니다. 2003년 설립 이후 꾸준히 발전해 온 플랫폼이고, 현재 양산차에 탑재된 대부분의 AUTOSAR 기반 소프트웨어는 CP로 개발되어 있습니다.

어디에 쓰이나?

CP는 Deeply Embedded ECU에 최적화되어 있습니다. 엔진 제어, 변속기 제어, 브레이크(ABS/ESC), 에어백, 바디 컨트롤 같은 영역입니다. 이런 ECU들의 공통점은 실시간성이 극도로 중요하다는 것입니다. 브레이크 제어가 몇 밀리초만 늦어도 사고가 나니까요.

핵심 특성

CP의 가장 큰 특징은 정적 구성(Static Configuration)입니다. 빌드 타임에 모든 것이 결정됩니다. 어떤 소프트웨어 컴포넌트가 어떤 순서로 실행되는지, 메모리를 얼마나 쓰는지, 통신 경로가 어떻게 되는지가 전부 컴파일 시점에 확정됩니다.

이게 왜 중요하냐면, 실시간 보장이 되기 때문입니다. 마이크로초 단위의 Hard Real-Time 응답이 가능하고, ASIL-D(ISO 26262 최고 안전 등급)까지 대응할 수 있습니다. 런타임에 동적으로 뭔가 바뀌면 타이밍 보장이 어려워지는데, CP는 그런 불확실성을 원천적으로 차단합니다.

통신 방식

CP는 CAN, LIN, FlexRay 같은 전통적인 차량 네트워크를 사용합니다. 이 네트워크들은 대역폭은 낮지만 실시간 전송이 보장되고, 자동차 업계에서 수십 년간 검증된 기술입니다.

Adaptive Platform — 새로운 시대의 요구

Adaptive Platform(AP)은 2017년에 첫 릴리스(R17-03)가 나왔습니다. CP와는 완전히 다른 설계 철학을 가지고 있습니다.

왜 만들었나?

자율주행(ADAS/AD), 커넥티드카, OTA(Over-The-Air) 업데이트 같은 기능을 구현하려면 고성능 컴퓨팅이 필요합니다. 카메라, 라이다, 레이더에서 들어오는 대량의 센서 데이터를 실시간으로 처리하고, 복잡한 AI 알고리즘을 돌려야 합니다. CP의 정적 아키텍처로는 이걸 감당할 수 없습니다.

AP는 이런 고성능 컴퓨팅 ECU를 위해 설계되었습니다. POSIX 호환 운영체제(보통 Linux 기반) 위에서 동작하고, C++14 이상의 현대적인 언어를 사용합니다.

핵심 특성: SOA

AP의 가장 핵심적인 특성은 SOA(Service-Oriented Architecture), 서비스 지향 아키텍처입니다. CP에서는 소프트웨어 컴포넌트 간 통신이 정적으로 연결되어 있는 반면, AP에서는 서비스를 동적으로 발견하고 연결합니다.

실무에서는 이런 식입니다. 카메라 서비스가 "나 객체 인식 데이터 제공할 수 있어"라고 네트워크에 알리면(Service Discovery), 자율주행 판단 모듈이 그 서비스를 찾아서 동적으로 연결합니다. 새로운 센서가 추가되거나 알고리즘이 업데이트되어도, 전체 시스템을 다시 빌드하지 않고 해당 서비스만 교체할 수 있습니다.

ARA — 표준 API

AP는 ARA(AUTOSAR Runtime for Adaptive Applications)라는 표준 API 레이어를 정의합니다. 애플리케이션은 ARA를 통해 플랫폼 서비스에 접근합니다. 통신 관리(Communication Management), 실행 관리(Execution Management), 상태 관리(State Management), 진단(Diagnostics) 같은 기능이 ARA를 통해 제공됩니다.

핵심은 이것입니다. ARA 위에서 개발한 애플리케이션은 ARA를 구현한 어떤 플랫폼에서든 동작할 수 있습니다. 하드웨어와 OS가 달라져도 애플리케이션 코드를 바꿀 필요가 없습니다.

통신 방식

AP는 주로 Automotive Ethernet을 사용하며, SOME/IP(Scalable service-Oriented MiddlewarE over IP) 프로토콜로 통신합니다. SOME/IP는 서비스 디스커버리, 이벤트 구독, 원격 프로시저 호출 같은 SOA 통신 패턴을 지원합니다. 이더넷 기반이라 CAN 대비 수십~수백 배의 대역폭을 제공합니다.

CP vs AP — 핵심 차이 정리

설계 철학

• CP: 정적 구성, 빌드 타임에 모든 것이 결정
• AP: 동적 구성, 런타임에 서비스 발견 및 연결

대상 ECU

• CP: Deeply Embedded ECU (엔진, 변속기, 브레이크, 에어백)
• AP: High-Performance Computing ECU (ADAS/AD, 인포테인먼트, 중앙 게이트웨이)

실시간성

• CP: Hard Real-Time (마이크로초 단위), ASIL-D 대응
• AP: Soft Real-Time, 고성능 데이터 처리에 최적화

운영체제

• CP: AUTOSAR OS (OSEK 기반, 전용 RTOS)
• AP: POSIX 호환 OS (Linux 기반)

개발 언어

• CP: C
• AP: C++14 이상

통신

• CP: CAN, LIN, FlexRay
• AP: Automotive Ethernet, SOME/IP

업데이트

• CP: 전체 리플래시 필요
• AP: 개별 서비스 단위 업데이트 가능 (OTA 지원)

둘은 경쟁이 아니라 공존

여기서 꼭 짚고 넘어가야 할 것이 있습니다. AP는 CP를 대체하는 것이 아닙니다. 둘은 공존하고, 서로 협력합니다.

현실적으로 생각해 보면 당연합니다. 브레이크 제어를 Linux 기반 AP로 옮길 이유가 없습니다. 마이크로초 단위의 Hard Real-Time이 필요한 안전 크리티컬 기능은 CP가 이미 완벽하게 처리하고 있습니다. 반면에, 자율주행 인지/판단 알고리즘을 CP의 제한된 리소스에서 돌릴 수도 없습니다.

실제 차량에서는 CP ECU와 AP ECU가 게이트웨이 ECU를 통해 연결됩니다. 예를 들어, AP 기반 ADAS ECU가 "긴급 제동 필요"라고 판단하면, 게이트웨이를 통해 CP 기반 브레이크 ECU에 제동 명령이 전달됩니다. AP는 Ethernet으로, CP는 CAN으로 통신하고, 게이트웨이가 프로토콜을 변환합니다.

2019년 R19-11 릴리스부터 CP와 AP는 매년 함께 릴리스됩니다. 가장 최근 릴리스는 2024년 12월의 R24-11입니다. 이 릴리스에서는 VISS(Vehicle Information Service Specification) 프로토콜 기반의 Automotive API Gateway가 새롭게 도입되어, 차량 내부와 외부 서비스 간 연결이 한층 확장되었습니다.

SDV 시대, Adaptive의 역할은 더 커진다

SDV(Software-Defined Vehicle) 시대로 넘어가면서 차량 아키텍처가 변하고 있습니다. 기존에는 기능별로 ECU가 분산되어 있었지만, 이제는 중앙 컴퓨팅 유닛(Central Computing Unit)이 여러 기능을 통합 관리하는 방향으로 가고 있습니다.

이 중앙 컴퓨팅 유닛에서 Adaptive Platform이 핵심 역할을 합니다. SOA 아키텍처 덕분에 기능을 서비스 단위로 관리하고, OTA로 업데이트하고, 새로운 서비스를 추가할 수 있습니다. 스마트폰에서 앱을 설치하고 업데이트하는 것과 비슷한 개념이 차량에도 적용되는 것입니다.

그렇다고 CP가 사라지는 것은 아닙니다. 안전 크리티컬 기능, 실시간 제어, 저전력 ECU에서는 여전히 CP가 핵심입니다. 앞으로도 한동안은 CP + AP 공존 구조가 유지될 것입니다.

PopcornSAR의 Adaptive AUTOSAR 솔루션

PopcornSAR는 Adaptive AUTOSAR 전문 기업으로, AP 기반 개발에 필요한 솔루션을 제공하고 있습니다.

PARA는 PopcornSAR가 개발한 Adaptive AUTOSAR 미들웨어 플랫폼입니다. ARA 스펙을 구현하여, PARA 위에서 개발한 애플리케이션은 표준 Adaptive AUTOSAR 환경에서 동작합니다. 통신 관리, 실행 관리, 진단 등 AP의 핵심 서비스를 제공합니다.

PACON IDE는 Adaptive AUTOSAR 개발을 위한 통합개발환경입니다. Docker 기반 Virtual ECU를 내장하고 있어서, 실제 하드웨어 없이도 AP 애플리케이션을 개발하고 테스트할 수 있습니다. 실무에서는 하드웨어가 준비되기 전에 소프트웨어 개발을 시작할 수 있다는 것이 큰 장점입니다.

AutoSAR.io는 ARXML 설계 도구로, CP와 AP 모두를 지원합니다. 시스템 아키텍처를 설계하고 ARXML을 관리하는 데 사용됩니다.

이 세 가지를 묶은 것이 Adaptive AUTOSAR Tool Kit입니다. 설계(AutoSAR.io) → 미들웨어(PARA) → 개발환경(PACON IDE)을 하나의 솔루션으로 제공하여, Adaptive AUTOSAR 개발의 전 과정을 커버합니다.

각 제품에 대한 자세한 내용은 PARA 제품 페이지와 PACON IDE 제품 페이지에서 확인할 수 있습니다. 도입 검토나 기술 문의는 문의하기를 통해 편하게 연락해 주세요.