🚗 AUTOSAR 구조, 실무자 관점에서 깊이 이해하기

오토사란 ?

---

안녕하세요, 버그없는토마토입니다 🍅
오늘은~ AUTOSAR 구조를 한 단계 더 깊게, 실무 개발 시 어떤 의미를 갖는지 중심으로 정리해보겠습니다.

AUTOSAR는 단순 표준이 아니라 현대 ECU 개발의 기반 철학에 가까운 구조이며,
전동화·SDV·ADAS 시대에 필수적인 확장성을 제공합니다.

 

AUTOSAR(Automotive Open System Architecture)는

2003년 주요 OEM과 Tier1이 주도하며 출범한 글로벌 표준 아키텍처입니다.

ECU 개수 증가, 기능 복잡도 확대, 소프트웨어 재사용성 한계라는 문제를 해결하기 위해 만들어졌으며,

현재 자동차 소프트웨어 개발의 사실상 기반 플랫폼 역할을 하고 있습니다

 

그래서 해당 설계를 담당하는 파트를 플랫폼 파트라고 부르는 곳도 있고 BSW파트라고 부르는 등 다양하게 부르기도 합니다.

 

AUTOSAR의 핵심은 “계층화된 추상화 구조를 통해 ECU 소프트웨어를 모듈화하고 독립적으로 관리한다”는 점입니다.

사실 위 말이 오늘 내용을 관통하는 한 문장이라고 할 수 있습니다.

 

이 구조는 기능안전(ISO 26262)·전동화·SDV(Software Defined Vehicle)의 시대에 필수적인 확장성과 유지보수성을 보장합니다.

---

🧩 1. Application Software Layer – 기능 구현의 중심이 되는 계층

ASW(Application Software Layer)는 AUTOSAR 구조의 최상위 계층으로, 엔드 투 엔드 기능을 담당하는 SWC(Software Component)들로 구성됩니다.
이 계층의 가장 큰 특징은 플랫폼 독립성입니다. 즉, SWC 내부 로직은 특정 하드웨어나 MCU에 종속되지 않으며, 인터페이스만 동일하다면 다양한 ECU로 이식이 가능합니다.

독립적이라는 말이 핵심이라고 생각합니다.
하드웨어에 국한되지 않고 어떤 환경에서도 조립할 수 있는 레고에서 사람역할입니다.

 

이 구조가 실무적으로 중요한 이유는 다음과 같습니다.

• ECU 통합(Zonal Architecture) 환경에서도 기능 모듈 재사용이 용이합니다.
• OEM–Tier1 간 개발 분업이 쉬워집니다.
• 기능안전 요구사항을 SWC 단위로 분리하여 관리할 수 있습니다.
• 동일 기능을 여러 차종에 반복 적용할 때 비용 절감 효과가 큽니다.

결국 ASW는 차량 기능 설계의 단위를 컴포넌트 수준으로 세분화하는 구조적 변화를 촉진했다고 볼 수 있습니다.

---

🔗 2. RTE(Runtime Environment) – AUTOSAR의 연결 허브

RTE는 AUTOSAR 구조에서 매우 중요한 요소이며, Application Layer와 BSW를 완전히 분리하는 미들웨어 역할을 수행합니다.
RTE가 ECU별로 자동 생성되는 이유는 각 ECU가 사용하는 BSW 모듈 구성, 하드웨어 사양, 통신 매트릭스가 서로 다르기 때문입니다.

RTE는 이해하기가 처음엔 좀 쉽지않습니다.
초급자라면 RTE는 그냥 시냅스라고 생각하고 ASW <-> BSW의 개념까지 이해하셔도 무방합니다.

 

RTE는 다음과 같은 기능을 수행합니다.

• SWC 간 통신(Port-Prototype 기반)
• SWC와 BSW 간 인터페이스 연결
• 모드 관리(Mode Management)
• Runnable 단위의 실행 모델 관리(스케줄링 구조 결정)

실무 개발자가 가장 크게 영향을 받는 부분은 바로 Runnable 기반 실행 모델입니다.
RTE는 이 구조를 통해 ECU 소프트웨어의 실시간성, 주기성, 이벤트 기반 처리 등 실행 규칙을 정확하게 정의합니다.

따라서 RTE는 단순한 연결 계층이 아니라,
➡️ ECU 소프트웨어 아키텍처 전체의 ‘운영 규칙’을 결정하는 핵심 엔진이라고 할 수 있습니다.

---

🧱 3. Basic Software Layer – ECU 기반 시스템을 구성하는 핵심 계층

BSW는 AUTOSAR 아키텍처의 최하위 계층이며, ECU가 동작하기 위해 필요한 모든 저수준 기능을 제공합니다.
이 계층은 수백 개의 표준화된 모듈로 구성되며, 크게 세 가지 하위 계층으로 나뉩니다.

---

(1) Service Layer

• OS(스케줄러, 태스크, ISR)
• 통신 스택(CAN, LIN, Ethernet, FlexRay)
• 진단 서비스(UDS)
• 메모리 서비스(NvM, Fee, Ea)
• Watchdog Manager

ECU 운영에 필수적인 기능을 제공하는 서비스 계층이라고 할 수 있습니다.

---

(2) ECU Abstraction Layer

• ADC, PWM, SPI, TPU 등 주변장치 인터페이스 추상화
• 서로 다른 ECU 하드웨어의 차이를 통일

코드를 다루는 곳에서 빈번하게 볼수 있는 단어가 'Abstraction'입니다.
그만큼 중요하기도 하고, 그만큼 기본이기도 하죠.
저도 항상 코드를 짜기전, 함수와 함수를 연결하기 전, 변수를 넘기고 받을 때 'Abstraction'에 관해 고민하고 설계를 하는데요
얼마나 생각하고 구조화하는 데에 유지보수, 재사용 등등의 부가 개념이 따라 온다고 생각합니다.

즉, “하드웨어는 다르지만, 동일한 방식으로 접근할 수 있도록 하는 계층”입니다.

---

(3) MCAL (Microcontroller Abstraction Layer)

• MCU 제조사가 제공하는 레지스터 기반 드라이버
• CAN Driver, Port Driver, GPT Driver 등

AUTOSAR 구조 중 유일하게 하드웨어에 직접 접근하는 계층이며,
MCAL의 품질은 ECU 전체 품질에 직접적인 영향을 미칩니다.
실무에서는 MCU 선택과 MCAL 안정성 검증을 프로젝트 초기의 핵심 의사결정으로 다루고 있습니다.

---

🧠 AUTOSAR 구조가 제공하는 실질적 가치 (실무 관점)

AUTOSAR의 도입은 단순히 소프트웨어 개발을 표준화하는 것 이상으로 의미가 있습니다.
현대 ECU 개발 환경에서 AUTOSAR 계층 구조는 다음과 같은 가치를 제공합니다.

✔ 하드웨어 변경 시 소프트웨어 영향 최소화

MCU가 변경되더라도 MCAL 또는 BSW 일부만 수정하면 ASW는 그대로 유지할 수 있습니다.

✔ 기능안전 설계의 용이성

ASIL 분해가 쉬워지고, 안전 메커니즘을 SWC 단위로 적용할 수 있습니다.

✔ ECU 통합·Zonal Architecture 시대에 필수

ECU는 줄어들지만 소프트웨어 복잡도는 오히려 증가하므로, 모듈화된 구조가 필수입니다.

✔ OTA·Adaptive AUTOSAR 확장 대응

Classic–Adaptive 간 기능 분리를 통해 SDV 구조에 자연스럽게 대응할 수 있습니다.

결국 AUTOSAR는
➡️ “자동차가 소프트웨어 중심 플랫폼으로 진화하기 위한 최소 조건”
이라고 정리할 수 있습니다.

---

🏁 마무리

AUTOSAR의 구조는 단순해 보이지만,
ASW–RTE–BSW가 이루는 계층화 모델은 현대 자동차 소프트웨어 개발의 근간을 형성합니다.

전동화·ADAS·SDV로 빠르게 변화하는 환경에서 AUTOSAR는 선택이 아니라 필수 구조입니다.
사실 초급자의 시선에서는 이해하기에 어려운 개념이기도 합니다.

하지만 개념과 방향에 대해 공부하고 이해한다면 올바른 방향으로 갈 수 있다고 생각합니다.

결국에 이 설계는 무엇을 위해 하는가? 에 대해 생각하며 고심한다면 좀 더 나은 방향으로 가고 있다고 생각합니다.

오늘도 버그없는토마토였습니다 🍅