자동차 소프트웨어 구조 AUTOSAR 이해
STM32와 FreeRTOS 실습 기반으로 체득한 계층 구조
AUTOSAR의 정체.
자동차 소프트웨어는 점점 복잡한 전자 시스템으로 진화하고 있다.
기존처럼 "ECU 하나 = 하나의 기능"이 아니라, 다양한 기능들이 통합/표준화된 구조에서 동시에 작동함.
이때 필요한 게 바로 AUTOSAR (AUTomotive Open System ARchitecture)
"자동차 소프트웨어를 효율적으로 만들고 관리하자"는 국제 표준 아키텍처.
AUTOSAR를 이해하고 잘 사용하기 위해서는 설계 철학 과 실제 구현되는 계층 구조를 먼저 체득해야한다고 생각한다.
AUTOSAR의 설계 철학
AUTOSAR는 단순히 소프트웨어 구조만을 정의하는 것이 아니라,
왜 그렇게 나누고, 어떻게 시스템을 설계해야 하는가에 대한 철학을 함께 제시하는 구조적 프레임워크다.
핵심 철학 5가지
1. 표준화 (Standardization)
"모든 자동차 제조사와 부품사가 같은 언어로 이야기할 수 있도록"
AUTOSAR는 ECU 소프트웨어를 표준 인터페이스로 나눈다.
덕분에 서로 다른 공급업체의 SW 컴포넌트도 호환 가능.
예: Bosch의 센서 드라이버 + 현대차의 SWC → AUTOSAR 기반이면 결합 가능.
2. 추상화 (Abstraction)
"기능과 하드웨어를 분리하자"
APP는 MCU나 센서 종류를 몰라도 동작할 수 있어야 한다.
→ 하드웨어 변경 시에도 APP 로직은 그대로 유지 가능.
이는 MCAL과 RTE가 핵심 역할을 한다.
3. 모듈화 (Modularity)
"소프트웨어를 부품처럼 나누고 조립하자"
모든 컴포넌트(SWC, BSW)는 독립적인 모듈로 작성됨.
테스트, 유지보수, 교체가 쉬움.
예: 하나의 센서 드라이버만 고쳐도 전체 시스템 수정 필요 없음.
4. 재사용성 (Reusability)
"한 번 만든 SWC는 어디서든 다시 쓰자"
SWC는 포트와 인터페이스만 맞추면 다른 프로젝트/차종에도 재사용 가능.
설계 생산성을 극대화하고, 비용을 절감한다.
5. 분리된 책임 (Separation of Concerns)
"누가 무엇을 책임질지를 명확히 하자"
APP / RTE / BSW / MCAL은 각자의 책임 범위만 수행.
→ 계층 간 의존성이 낮고, 설계가 명확해진다.
예: APP이 HAL 함수를 직접 호출하지 않도록 구조적으로 차단.
AUTOSAR의 계층 구조
AUTOSAR를 가장 빠르고 직관적으로 이해하기 위해서는 계층 구조를 살펴보는게 좋다고 생각한다.
가장 위에는 애플리케이션, 가장 아래에는 하드웨어와 가까운 드라이버가 있다.
각 계층별 역할 정리
1. Application Layer (SWC: Software Component)
- 개발자가 직접 작성하는 기능 코드
- 예: 에어백 작동, ABS, 자동긴급제동, 차량문 잠금 제어 등
- 이 계층에서는 하드웨어나 통신 방식에 신경 쓰지 않고, 기능만 정의한다.
if (accel > 3.0 && seatOccupied) {
triggerAirbag();
}2. RTE (Runtime Environment)
- 애플리케이션과 하위 계층(BSW) 간의 데이터 전달자 / 미들웨어
- SWC와 BSW를 느슨하게 연결한다.
“RTE는 C언어 관점에서 보자면, WINAPI처럼 상위 계층에서 하위 기능을 직접 모르고도 호출할 수 있게 해주는 자동 생성형 미들웨어 API다.
다만, RTE는 컴포넌트 간 통신을 위한 라우팅과 포트 연결까지 포함하므로, WINAPI보다 더 구조적이다.”
예시
- App에서 Sensor 값을 가져와야 할 때, 직접 드라이버를 호출하지 않고
RTE_get_SensorValue()같은 중간 API를 사용
3. BSW (Basic Software)
- OS, 통신 스택, 진단 서비스, 메모리 관리 등 자동차 시스템 공통 기반
- 대표적인 모듈:
- OS (OSEK/VDX 기반 RTOS)
- CAN 통신 스택
- Watchdog
- Memory Stack (EEPROM, Flash 등)
- FreeRTOS + CubeMX로 구현할 경우, 우리가 설정하는 Task 큐, 세마포어도 BSW의 일부처럼 작동한다.
4. MCAL (Microcontroller Abstraction Layer)
- 하드웨어 추상화 계층
- GPIO, UART, SPI, I2C, ADC 등을 MCU 종류에 따라 다르게 구현한 부분
- STM32 에서 HAL_GPIO_WritePin() 처럼 하드웨어를 직접 제어하는 함수들이 이 계층에 해당
예시로 이해하기 : 에어백 시스템
| 계층 | 실제 동작 예시 |
|---|---|
| APP | triggerAirbag() 함수 실행 |
| RTE | triggerAirbag → GPIO 설정 명령 전달 |
| BSW | GPIO 제어 스택, FreeRTOS Task 실행 |
| MCAL | HAL_GPIO_WritePin(GPIOC, PIN, HIGH) |
| H/W | 할당된 핀에 전압 인가 → 릴레이 작동 |
Windows OS와 비교하며 이해하기
| AUTOSAR 계층 | OS 비유 | 설명 |
|---|---|---|
| APP (SWC) | 유저 프로세스 (e.g. 엑셀, 워드) | 실제 기능 구현, 이벤트 판단, UI/비즈니스 로직 |
| RTE | 시스템콜 인터페이스 + API 브릿지 | API 호출을 받아서 내부 서비스(BSW)에 전달 |
| BSW | 커널 서비스 (디스패처, 통신 스택 등) | RTOS Task 스케줄링, CAN 통신, Flash 관리 등 |
| MCAL | 디바이스 드라이버 | 하드웨어를 직접 제어하는 레벨 (GPIO, ADC, CAN 등) |
| H/W | 디바이스 자체 | 릴레이, 모터, GPS, 센서 등 실제 장치 |
용어 정리
| 용어 | 설명 |
|---|---|
| SWC | Software Component. 개발자가 만드는 기능 모듈 |
| RTE | Runtime Environment. 미들웨어, 계층 연결 |
| BSW | Basic Software. OS, 통신, 메모리 등 시스템 공통 소프트웨어 |
| MCAL | MCU 추상화 계층. MCU마다 다르게 구현되는 드라이버 |
| ECU | 전자 제어 장치. 자동차에 들어가는 소형 컴퓨터 |
| CAN | 차량 내 통신 프로토콜. ECU 간 데이터 송수신 |
| FreeRTOS | 임베디드용 RTOS. AUTOSAR OS 대체용으로 실습 가능 |
마치며
개념이 확 잡히지 않고 두루뭉술하게 다가왔던 AUTOSAR의 구조를 오늘 처음으로 명확히 정리해봤다.
아직은 겉핥기 수준의 지식일 수 있지만, 구조를 먼저 이해하고 하나하나 구현해가며 체득하는 과정은 나에게 꼭 필요한 단계라고 느낀다.
앞으로 각 계층마다 직접 기능을 구현하며 실전에서 AUTOSAR 철학을 꺼내 쓸 수 있는 개발자로 성장하고 싶다.
