AUTOSAR 아키텍처와 Classic·Adaptive 플랫폼 구조

ECU 소프트웨어 복잡성을 다루는 공통 구조

고급 차량에는 100개 이상의 ECU(Electronic Control Unit)가 들어가며, 소프트웨어는 1억 줄 이상으로 늘어난다. ADAS, 인포테인먼트, 자율주행 기능이 추가되고 CAN, LIN, FlexRay, Ethernet 네트워크가 얽히면서, ECU별로 독립 개발하던 방식만으로는 호환성과 유지보수를 관리하기 어렵다.

AUTOSAR(AUTomotive Open System ARchitecture)는 이 문제를 다루기 위해 만들어진 자동차 전자 시스템용 표준 소프트웨어 아키텍처다. 글로벌 자동차 제조사, 공급업체, 소프트웨어 회사가 참여하는 파트너십을 바탕으로 하며, 주요 자동차 제조사와 공급업체는 코어 멤버로, 소프트웨어 및 반도체 회사는 프리미엄 멤버로, 도구·서비스 제공업체는 개발 멤버로 참여한다.

핵심은 애플리케이션을 하드웨어에서 분리하고, 표준 인터페이스와 XML 기반 메타모델로 컴포넌트를 연결하는 데 있다. 이를 통해 공급업체 간 호환성, 소프트웨어 재사용, 유지보수 효율화, 산업 협력을 지원한다.

AUTOSAR가 지향하는 바는 하드웨어 독립적 소프트웨어를 통한 이식성, 재사용으로 인한 개발 비용 절감, 기능 확장이 쉬운 구조, 그리고 ISO 26262를 지원하는 안전성 및 보안성이다. 자동차 소프트웨어의 표준 플랫폼과 글로벌 생태계를 기반으로 혁신을 가속하고 지속 가능한 발전을 뒷받침하는 것이 비전이다.

제어 ECU와 고성능 컴퓨팅을 나누는 플랫폼

AUTOSAR 아키텍처는 Application Layer, Runtime Environment(RTE), Basic Software(BSW)의 계층을 중심으로 구성된다. 계층 사이의 표준 인터페이스와 하드웨어 추상화는 변경의 영향을 격리하고 유지보수를 쉽게 만든다.

Classic Platform과 Adaptive Platform은 대상 시스템의 성격이 다르다.

구분	Classic Platform	Adaptive Platform
대상	실시간 제어 시스템, 안전 관련 기능, 제한된 자원, 정적 설정	고성능 컴퓨팅, 동적 시스템, 복잡한 알고리즘, 네트워크 집약적 시스템
운영 환경	OSEK/VDX 기반 RTOS	POSIX 기반 OS
메모리	정적 메모리 할당	동적 메모리 할당
구조	결정적 동작과 높은 신뢰성	서비스 지향 아키텍처(SOA)
언어		C++14/17

Classic Platform은 엔진·변속기를 포함한 파워트레인 제어, ABS·ESC 같은 섀시 제어, 도어·조명 같은 바디 제어, 에어백과 ADAS를 포함한 안전 시스템에 적용된다.

Adaptive Platform은 자율주행 제어, V2X 통신, 인포테인먼트, OTA 업데이트처럼 고성능과 동적인 구성이 필요한 영역에 맞춘다.

Classic Platform에서 기능과 하드웨어를 연결하는 방식

SWC는 재사용 가능한 애플리케이션 단위다

소프트웨어 컴포넌트(SWC)는 애플리케이션 기능을 구현하는 하드웨어 독립적 모듈이다. 표준 인터페이스를 제공하고 XML 메타모델로 정의되므로, 기능 구현과 ECU 하드웨어를 분리할 수 있다.

SWC는 애플리케이션의 비즈니스 로직을 담는 Application SWC, 센서와 액추에이터를 추상화하는 Sensor/Actuator SWC, 공통 기능을 제공하는 Service SWC, 캘리브레이션 데이터를 다루는 Parameter SWC로 나뉜다.

포트는 컴포넌트 경계를 드러낸다. Sender Port와 Receiver Port는 데이터를 주고받고, Client Port와 Server Port는 서비스를 요청하고 제공한다. SWC 내부에서는 Runnable이 실제 실행 가능한 함수를 맡으며, 이벤트에 의해 또는 주기적·비주기적으로 실행되고 RTE가 이를 호출한다.

RTE가 통신과 호출을 중개한다

RTE는 SWC와 BSW 사이에 놓여 통신을 중개하고 하드웨어를 추상화한다. 포트를 통한 데이터 전달과 서비스 호출 라우팅을 담당한다.

통신은 Sender-Receiver 방식의 데이터 교환, Client-Server 방식의 서비스 호출, Mode Management를 통한 모드 전환, Trigger에 따른 이벤트 발생으로 구성된다. RTE는 도구를 통해 자동 생성되며, XML 메타모델로 기술한 SWC 설명을 바탕으로 ECU별 하드웨어에 맞춰 생성되고 성능과 메모리를 최적화한다.

BSW는 공통 시스템 기능과 하드웨어 접근을 맡는다

BSW의 Services Layer에는 작업 스케줄링과 타이머를 제공하는 OS Services, NVM 관리와 EEPROM 에뮬레이션을 제공하는 Memory Services, PDU 라우팅과 네트워크 관리를 담당하는 Communication Services, ECU 상태 관리와 DET(Development Error Tracer)를 포함하는 System Services가 있다.

ECU Abstraction Layer는 CAN, SPI, ADC, PWM 같은 장치 기능을 추상화한다. MCAL(Microcontroller Abstraction Layer)은 마이크로컨트롤러 하드웨어에 직접 접근하는 벤더별 드라이버 계층으로, 표준 API를 제공해 포팅을 쉽게 한다.

표준 BSW만으로 구현하기 어려운 기능, 하드웨어 직접 접근, 레거시 통합, 특수 요구사항은 Complex Drivers로 처리한다.

Adaptive Platform은 서비스 중심으로 확장한다

Adaptive Platform은 런타임 서비스 검색, 동적 메모리 할당, 플러그 앤 플레이, 유연한 구성을 지원한다. 멀티코어 프로세서와 Linux 기반 OS, Ethernet 같은 고대역폭 네트워크, 병렬 처리를 활용하며 C++의 객체지향 설계, STL 라이브러리, 람다와 스마트 포인터 같은 모던 C++ 기능, 타입 안전성을 활용한다.

서비스 인터페이스는 IDL(Interface Definition Language)로 정의한다. 이 정의는 언어 중립적이며 버전 관리와 진화를 고려할 수 있다. Service Registry에 서비스를 등록하고 Service Discovery로 동적으로 찾으며, Publish-Subscribe 방식의 이벤트 통신과 Request-Response 방식의 요청·응답 통신을 사용한다.

통신 수단으로는 SOME/IP(Scalable service-Oriented MiddlewarE over IP), DDS(Data Distribution Service), HTTP/REST, MQTT가 있다.

자율주행에서는 센서 융합, 경로 계획, 의사결정, 차량 제어를 수행한다. V2X 영역은 차량 간 통신(V2V), 차량-인프라 통신(V2I), 차량-보행자 통신(V2P), 차량-네트워크 통신(V2N)을 포함한다. 인포테인먼트는 내비게이션, 멀티미디어, 스마트폰 연동, 음성 인식을 다루며, OTA 업데이트는 소프트웨어 업데이트와 보안 패치, 기능 추가, 버그 수정을 지원한다.

표준화가 재사용성과 안전성으로 이어지는 지점

AUTOSAR의 표준화는 API, 데이터 타입, 프로토콜, 메타모델의 공통 정의에서 출발한다. ARXML(AUTOSAR XML)은 SWC 설명, 시스템 구성, ECU 설정을 기술하는 형식이다. 시스템 설계, 코드 생성, 설정, 검증 도구로 이어지는 도구 체인도 이 메타모델을 중심으로 작동한다.

SWC는 플랫폼에 독립적으로 설계해 프로젝트와 공급업체 사이에서 재사용하고 라이브러리로 축적할 수 있다. BSW도 표준 스택, 교체 가능한 MCAL, 재사용 가능한 설정, 검증된 컴포넌트를 기반으로 반복 활용할 수 있다. 참조 아키텍처, 설계 패턴, 베스트 프랙티스, 템플릿은 설계 재사용을 뒷받침한다.

확장은 SWC 추가, 새로운 ECU 도입, 네트워크 확장, 서비스 확장으로 이뤄진다. 멀티코어, 분산 처리, 부하 분산, 자원 최적화는 성능 확장의 수단이다. 새로운 마이크로컨트롤러와 네트워크, 다양한 OS, 레거시 통합도 플랫폼 확장의 대상이다.

안전과 보안도 아키텍처의 범위에 들어간다. 기능 안전 측면에서는 ISO 26262와 ASIL 등급, 안전 메커니즘, 오류 감지·처리, Fail-safe와 Fail-operational을 지원한다. 보안 측면에서는 ISO/SAE 21434와 함께 암호화, 인증, 접근 제어, 침입 탐지를 다룬다. OBD(On-Board Diagnostics), UDS(Unified Diagnostic Services), 오류 메모리, 원격 진단은 진단 체계에 포함된다.

시스템 설계에서 ECU 통합까지

개발은 기능·비기능 요구사항과 성능·안전 요구사항, 인터페이스, 제약사항을 분석하는 단계에서 시작한다. 이후 ECU, 네트워크 토폴로지, 신호, 통신 매트릭스를 정의하고 SWC의 포트·인터페이스·Runnable·의존성을 설계한다.

SWC 구현에서는 C 코드 작성, 알고리즘 구현, 단위 테스트, 문서화를 수행한다. 이어 ARXML에 포트 설정, Runnable 매핑, 자원 요구사항을 작성하고 SWC를 통합해 인터페이스 검증, 통신 테스트, 성능 측정을 진행한다.

ECU 추출 단계에서는 SWC를 ECU에 매핑하고 네트워크, BSW, OS를 설정한다. RTE 자동 코드 생성으로 SWC를 연결하고 BSW 인터페이스와 최적화를 반영한다. BSW는 모듈 선택, 파라미터 설정, MCAL 설정, 검증을 거쳐 구성된다.

마지막으로 RTE, BSW 설정 코드, OS 설정 코드, 링커 스크립트를 생성한다. 컴파일·링킹·이미지 생성·플래싱을 수행한 뒤 단위 테스트, 통합 테스트, 시스템 테스트, HiL(Hardware-in-the-Loop) 테스트로 검증한다.

도입 시 함께 검토할 제약

AUTOSAR는 SWC 재사용과 검증된 컴포넌트 활용으로 개발 비용과 개발 기간을 줄이고 품질을 높일 수 있다. 기능 추가, 하드웨어 독립성, 공급업체 교체 가능성도 장점이다. 산업 표준을 기반으로 공급망 협력을 돕고 엔지니어 교육과 도구 생태계 형성에도 유리하다. ISO 26262 지원, 검증된 아키텍처, 오류 처리 메커니즘, 진단 기능은 안전성 측면의 기반이 된다.

반면 추상화 계층이 많아 학습 곡선이 가파르고 초기 도입과 디버깅이 복잡하다. 추상화 계층에 따른 메모리 오버헤드, 간접 호출에 따른 성능 오버헤드, RTE 통신 중개 오버헤드, 코드 크기 증가도 검토 대상이다.

고가 도구가 필요할 수 있고 벤더 종속성, 도구 간 호환성, 도구 학습 부담이 생길 수 있다. 소규모 시스템에는 과도할 수 있으며 레거시 통합이 어렵고 특수 요구사항을 충족하는 데 제한이 생길 수 있다.