[AUTOSAR] Communication 구조와 BSW 통신 스택 정리

 

AUTOSAR Communication 구조는 소프트웨어 컴포넌트 간의 데이터 교환을 효율적으로 수행하고, 하드웨어와의 결합도를 낮추기 위해 계층적으로 설계되어 있다. SWC와 Runnable을 기반으로 기능을 분리하고, RTE를 통해 컴포넌트 간 통신을 추상화함으로써 시스템의 재사용성과 확장성을 확보한다.

 

이 과정에서 BSW는 하드웨어와 상위 애플리케이션 사이를 연결하는 핵심 역할을 수행하며, System Services, ECU Abstraction, MCAL로 구성된 계층 구조를 통해 하드웨어 의존성을 최소화한다. 또한 Com, Dcm, Dem과 같은 통신 및 진단 모듈과 PduR, CanIf, CAN Driver로 이어지는 통신 흐름을 통해 데이터가 실제 네트워크로 전달된다.

 

특히 NM과 CanSM은 네트워크의 상태를 관리하여 불필요한 전력 소모를 줄이고, FlexRay와 같은 통신 방식은 시스템 설계에 따라 구조적 제약을 갖는다는 점에서 AUTOSAR 통신 구조의 특징을 잘 보여준다.

 

이 글에서는 AUTOSAR의 전체 통신 흐름과 주요 BSW 모듈의 역할을 중심으로, 각 계층이 어떻게 연결되고 동작하는지에 대해 정리한다.

 

---

 

Overview

• software component(SWC) 단위로 기능을 구성한다 (객체지향 개념)
  • 기능 단위로 분리된 모듈
  • 단독으로 동작하지 못하고 다른 SWC와 상호작용하여 동작
• Runnable은 SWC 내부에서 실제로 동작하는 함수 단위
  • RTE를 통해 데이터를 주고 받는다
    • [SWC A - Runnable] ↔ RTE ↔ [SWC B - Runnable]
• RTE(Runtime Environment)
  • SWC와 SWC, 그리고 SWC와 하드웨어 사이를 연결하는 중간 계층
  • 컴포넌트들이 서로를 직접 알지 않아도 통신 가능하도록 하는 인터페이스 역할
• 전체 구조
  • ASW(Application Layer) ← RTE ← BSW(Basic Software) ← MCU
• BSW는 크게 3단계 구조로 나뉜다
  • System Services
    • OS 및 시스템 공통 기능 제공
    • 시스템 전체 동작을 관리
    • 예: OS(스케줄링), 통신 서비스, 메모리 관리, 진단 서비스
  • ECU Abstraction Layer
    • 하드웨어를 직접 다루지 않도록 추상화
    • 하드웨어 변경에 대한 영향을 최소화
    • 예: 센서 추상화, 통신 모듈 추상화, 메모리 HW 추상화
  • MCAL (Microcontroller Abstraction Layer)
    • 하드웨어 레지스터를 직접 제어하는 계층
    • 디바이스 드라이버 역할 수행
    • 예: GPIO Driver, ADC Driver, PWM Driver, CAN Driver
• AUTOSAR 통신 구조
  • server는 항상 동작하지 않음
  • client의 요청이 있을 때 해당 요청을 처리하는 방식으로 동작

 

BSW

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

• BSW는 하드웨어와 상위 소프트웨어를 연결하는 핵심 계층
• BSW 모듈 구성
  • 노란색 블록
    • 특정 기능을 수행하는 개별 모듈
    • 하나의 명확한 역할을 담당
    • 예: 메모리, 입출력, 진단 등
  • 파란색 블록
    • 여러 모듈이 계층적으로 구성된 구조
    • 주로 통신 스택에서 나타남
    • 데이터 패킹, 라우팅, 인터페이스 처리 등 여러 단계 포함
• Transceiver
  • MCU와 CAN Bus 사이에서 신호를 변환하는 장치
  • 구조: MCU ↔ CAN Controller ↔ Transceiver ↔ CAN Bus
    • MCU/Controller: 디지털 신호
    • CAN Bus: 전압 기반 신호
  • 디지털 신호를 실제 통신 가능한 전기 신호로 변환
  • 통신을 위해 반드시 필요
• NM (Network Management)
  • 네트워크 상태를 관리하는 모듈
  • 필요할 때만 네트워크를 활성화하고, 필요 없을 때는 절전 상태로 전환
  • 역할
    • Wake-up: 네트워크 활성화
    • 유지: ECU 상태 확인 및 통신 유지
    • Sleep: 네트워크 절전 상태 전환
• CanSM (CAN State Manager)
  • CAN 통신 상태를 제어하는 모듈
  • 통신 시작, 정상 동작, 오류 상태, 절전 상태 등을 관리
  • NM과의 관계
    • NM: 네트워크 사용 여부 결정
    • CanSM: 실제 CAN 상태 전환 수행
• Com / Dcm / Dem
  • Com (Communication Module)
    • SWC의 데이터를 네트워크로 송수신
  • Dcm (Diagnostic Communication Manager)
    • 외부 진단 장비와 ECU 간 통신 처리
  • Dem (Diagnostic Event Manager)
    • 에러 발생 기록 및 관리
• PduR (PDU Router)
  • 데이터를 목적지로 전달하는 라우터 역할
  • 상위 모듈(Com, Dcm)과 하위 통신 모듈(CAN, LIN 등) 연결
• FlexRay
  • 정적 스케줄 기반 통신 (Time-triggered)
  • 모든 ECU가 정해진 시간 슬롯에 따라 통신 수행
  • 특징
    • 높은 신뢰성과 실시간성
    • 구조 변경 시 전체 스케줄 영향

 

CAN Interface module (CanIf)

• CanIf
  • 상위 통신 모듈과 CAN Driver 사이를 연결하는 인터페이스
• Hardware Object (Mailbox)
  • CAN Controller 내부의 메모리 버퍼
  • 송신/수신 메시지를 저장
  • 설정에 따라 특정 메시지를 처리
• Hardware Object Handler (HoH)
  • Hardware Object를 추상화한 개념
  • CanIf가 PDU를 HoH로 변환하여 CAN Driver 호출
• CAN Driver
  • 어떤 CAN Controller의 어떤 Hardware Object를 사용할지 설정 정보 보유
  • 해당 버퍼에 메시지를 할당하여 실제 전송 수행