[Autosar] 차량용 통신 구조, 계층(Layer)별로 완벽히 이해하기

차량 내부에는 CAN, LIN, Ethernet, FlexRay, SPI 등 다양한 통신 방식이 혼재되어 있습니다. 겉보기엔 그저 데이터를 주고받는 '통신' 같지만, 하드웨어 레벨로 내려가면 이들의 내부 동작 방식은 완전히 다릅니다.

 

AUTOSAR(오토사)의 핵심 철학은 이러한 통신 방식의 물리적 차이를 없애는 것이 아닙니다. 철저한 계층(Layer) 구조를 통해 아래의 복잡한 하드웨어 차이를 흡수하고, "상위 애플리케이션에서는 하드웨어를 몰라도 되게" 만드는 것입니다.

 

전체적인 구조를 파악하기 위해, 가장 아래에 있는 하드웨어 계층부터 위로 올라가며(Bottom-up) 각 계층의 역할과 흐름을 정리해 보겠습니다.

1. MCAL (Microcontroller Abstraction Layer)

한 줄 요약: "하드웨어를 실제로 움직이는 최하단 디바이스 드라이버 계층"

MCAL은 AUTOSAR 구조에서 가장 아래에 위치하며, 마이크로컨트롤러(MCU)와 직접 맞닿아 있는 계층입니다. 이 곳에서는 다음과 같은 물리적인 제어 작업이 수행됩니다.

• 몇 번 포트(Pin)로 데이터가 들어왔는지 확인
• 어떤 하드웨어 레지스터를 조작해야 하는지 결정
• CAN, LIN, SPI 등 어떤 내부 컨트롤러를 사용할지 제어

핵심 구성 요소

• CAN Controller Driver
• LIN Controller Driver
• SPI Driver
• Ethernet Driver

즉, 하드웨어 스펙에 종속적인 디바이스 드라이버들이 바로 이 MCAL에 올라가게 됩니다.

2. ECU Abstraction Layer

한 줄 요약: "MCU 밖의 보드(Board) 종속적인 차이를 숨기는 계층"

MCAL 바로 위에 위치하는 이 계층은, 특정 MCU나 보드 설계에 따라 달라지는 하드웨어의 차이를 한 번 더 감춰주는 역할을 합니다.

어떤 ECU는 A라는 외부 칩(Transceiver 등)을 쓰고, 다른 ECU는 B라는 센서를 사용할 수 있습니다. 상위 계층이 이러한 보드 레벨의 차이까지 알 필요가 없도록 일관된 인터페이스를 제공하는 것이 목적입니다.

여기서 SPI를 짚고 넘어가야 하는 이유
SPI는 CAN이나 LIN처럼 여러 ECU가 물려있는 '차량 네트워크 통신'이라기보다는, 센서나 보드 내부의 외부 칩(External IC)과 연결할 때 주로 사용하는 'ECU 내부 통신'에 가깝습니다. 따라서 SPI의 활용은 통신 스택보다는 이 ECU Abstraction Layer의 관점에서 이해하는 것이 자연스럽습니다.

3. Communication Stack (ComStack)

한 줄 요약: "통신 방식의 '종류'를 통신 '서비스'로 추상화하는 핵심 계층"

AUTOSAR 통신 구조의 핵심이 되는 곳입니다. CAN, LIN, Ethernet 등은 동작 방식이 완전히 다르지만, 이 계층을 거치면서 그 차이가 깔끔하게 정리됩니다.

• 하위 계층의 시각: "이 데이터는 CAN 버스에서 왔고, 저 데이터는 LIN 버스에서 왔다."
• 상위 계층의 시각: "그냥 데이터를 '보낸다' / '받는다'."

즉, 물리적인 통신 방식의 차이를 완벽히 흡수하여, 상위 애플리케이션이 동일한 메커니즘으로 네트워크를 사용할 수 있게 만들어 줍니다.

+) Controller와 Transceiver의 위치 이해

통신 구조를 명확히 하려면 하드웨어 레벨의 두 가지 요소를 구분해야 합니다.

• Controller (디지털): 데이터 송수신 로직 제어 (MCAL 영역)
• Transceiver (물리/아날로그): 전기 신호 ↔ 디지털 신호 변환 (예: CAN 두 선의 전압 차이를 1과 0으로 변환)

이 둘의 조합(Controller + Transceiver)이 실제 통신을 수행하는 하드웨어적 뼈대이며, AUTOSAR의 하위 계층(MCAL 및 ECU Abstraction)에서 이를 제어하게 됩니다.

4. Service Layer와 Network Management (NM)

한 줄 요약: "단순한 통신을 넘어, ECU의 동작과 전력 효율을 관리하는 서비스 계층"

Communication Stack 위로 올라오면 이제부터는 '하드웨어'가 아니라 완벽한 '운영 서비스'의 영역입니다. 진단(Diagnostics), 메모리 관리, 시스템 모드 관리(Sleep/Wake) 등 ECU의 전반적인 동작을 관리합니다.

Network Management (NM)의 진짜 역할

차량 내부에 있는 수십 개의 ECU가 계속해서 통신을 주고받는다면 엄청난 전력 낭비가 발생합니다. NM은 단순히 네트워크를 연결하는 독립적인 기능이 아니라, Service Layer 내부에 포함되어 "네트워크 + 전력 관리"를 동시에 수행하는 핵심 서비스입니다.

• ECU 상태 제어: 네트워크 참여, Wake-up(깨우기), Sleep(재우기)
• 전력 최적화: 같은 네트워크(버추얼 네트워크)에 속한 ECU들이 통신이 필요 없을 때 동시에 Sleep 상태로 진입하도록 유도하여 차량 전체의 전력 소모를 최소화합니다.

---

정리하자면...

데이터와 제어의 흐름을 위에서 아래로(Top-down) 다시 정리하면 다음과 같습니다.

1. Application Layer (소프트웨어 로직)
2. Service Layer (NM을 포함한 시스템 및 전력 관리)
3. Communication Stack (통신 프로토콜 추상화 및 라우팅)
4. ECU Abstraction Layer (보드 레벨 하드웨어 인터페이스)
5. MCAL (MCU 내부 레지스터 제어)
6. Hardware (Controller & Transceiver)

한 줄 결론:
AUTOSAR 통신 아키텍처는 "개발자가 밑단의 복잡한 물리적 통신 방식을 몰라도 되도록, 층층이 감싸 올린 정교한 추상화 구조"입니다.

 

출처 및 참고문헌

https://yoginsavani.com/understanding-autosar-architecture-a-guide-to-automotive-software-integration/