AUTOSAR 기반 프로그램Folder Tree 분석

AUTOSAR란 어떻게 보면 프로토콜, 즉 규약과 비슷하게 생각하면 된다.

물론!!! 프로토콜이란 말은 아니다. 이해하기 쉽기 위해 비유를 한 것이니 오해하지 말 것.

 

이 글을 정리하는 이유는 다름이 아니라, 이 AUTOSAR의 진입 장벽이 너무 높다는 것.

 

특히, 기계 or 전자공학과 학생들이 취직을 준비하다 보면 이 AUTOSAR 구조를 아는 사람 등 우대조건이 들어가있는 경우가 많다.

 

그래서 조금이라도 아는 척 하기 위해, 이런 글을 작성한다. (그러니 틀릴 수 있다는 것에 주의!!)

 

우선 이러한 구조를 가진다고 한다.

 

오.. 뭔지 알겠는가? 라고 하면, 솔직히 알기 어렵다고 생각된다.

 

그치만 여기에서 일부 기능을 제외하고, 간단히 만든 폴더 구조를 GPT에게 부탁해서 보면 다음과 같다. 

ECU_Project/
│── 0_Rte/               # RTE (Runtime Environment)
│   ├── Rte.c
│   ├── Rte_Type.h
│
│── 1_Common/            # 공통 유틸리티 및 정의 파일
│   ├── Definition.h
│   ├── UdsNrcList.h
│   ├── Utility.c
│   ├── Utility.h
│
│── 2_App/               # Application 계층 (비즈니스 로직)
│   ├── AppMain.c
│   ├── BswCom/          # BSW와 연결되는 Application 기능
│   ├── BswDcm/
│
│── 3_EcuAbs/            # ECU Abstraction Layer (MCAL과 APP 중간 계층)
│   ├── Adc/
│   ├── Can/
│   ├── Dio/
│   ├── Gpt/
│   ├── Nvm/
│   ├── Spi/
│   ├── Wdg/
│   ├── Rte_EcuAbs.c
│   ├── Rte_EcuAbs.h
│
│── 4_Cdd/               # Complex Driver (HW에 직접 접근하는 모듈)
│   ├── CcpCustom/
│   │   ├── Rte_CcpCustom.c
│   │   ├── Rte_CcpCustom.h
│
│── 5_Bsw/               # Basic Software 계층 (MCAL 포함)
│   ├── Mcal/            # MCAL (Microcontroller Abstraction Layer)
│   │   ├── Adc.c
│   │   ├── Can.c
│   │   ├── Dio.c
│   │   ├── Spi.c
│   │   ├── Gpt.c
│   │   ├── Nvm.c
│   │   ├── Wdg.c
│   │   ├── Mcal_Config.c
│   │
│   ├── Service/         # OS, 메모리 관리, 진단 서비스 등
│   │   ├── Os/
│   │   ├── Eep/
│   │   ├── WdgM/
│   │   ├── Dem/
│   │   ├── Dcm/
│   │
│── 6_Config/            # Configuration 파일 (ARXML, ECUC 등)
│   ├── Autosar_Config.arxml
│   ├── Can_Config.c
│   ├── NvM_Config.c
│
│── 7_Doc/               # 문서 및 개발 자료
│   ├── Specification.pdf
│   ├── SW_Architecture.pdf
│
│── .git/                # 형상 관리(Git, SVN 등)
│── .cproject            # 프로젝트 설정 파일 (Eclipse, Keil 등)
│── .project
│── Readme.md

 

이렇게 보니, 좀 이해가 될 것 같다!

 

물론 실제로 IVS를 하며 받았던 폴더 트리는 저기서 좀 더 다른 구조였고, 다른 방식이었다. 

 

그치만 얼추 비슷하니, 이를 바탕으로 간략히 설명해보면 다음과 같이 이해해볼 수 있다.

 

참고로, 아래에서부터 역순으로 설명하겠다.

---

7. Doc & .git, .project 등

이 아키텍쳐와 세부 정보, 그리고 형상 관리를 위한 자료들이 있을만한 장소이다.

 

음.. 사실 그 이상 설명할 것이 없을 것 같다.

 

6. Config

ECU 설정 파일(ARXML, ECUC, Cfg.c) 및 문서화된 아키텍처 설계 관련 부분이다.. 사실 이 부분은 잘 모르겠다. ㅠ

 

5. BSW

Basic SW와 관련되어 설정하는 부분으로

여기서 MCAL이 실제 하드웨어와 가장 가까운 계층으로 MCU, Peripherals (CAN, SPI, ADC, GPIO, Timer 등)과 직접 연결된다.

아래 서비스엔 OS, 메모리 관리, Watchdog 관리, 진단(DEM, DCM) 등이 포함되어 있다.

OS, 메모리 관리, 진단 서비스, 통신 스택, MCAL 등을 포함한다.

 

4. Cdd

Cdd(Complex Device Driver)는 AUTOSAR 표준으로 정의된 모듈이 아니라, AUTOSAR 표준을 따르지 않는 기능을 구현할 때 사용하는 계층이다.
즉, MCAL이나 BSW(Basic Software)로 처리할 수 없는 특수한 하드웨어 기능을 구현해야 할 때 사용한다.

3. EcuAbs

상위 계층(Application)에서 하드웨어를 직접 제어하지 않고, 하드웨어 독립적인 API를 사용할 수 있도록 추상화 한 것이다.

MCAL과 APP 사이의 중간 계층 역할을 하며, 이를 이해하기 쉽게하기 위해 CAN 통신에 사용되는 EcuAbsCan.c 중 예시로 한 Function만 보자면 다음과 같다.

void EA_setPduInfo(uint8 handle, uint8 length, uint32 id, P_uint8 buffer)
{
	PduInfo[handle].swPduHandle = handle;
	PduInfo[handle].length = length;
	PduInfo[handle].id = id;
	PduInfo[handle].sdu = buffer;
}

 

2. App

 

ECU의 주요 기능(예: ADAS, 파워트레인, 차체제어 등)을 구현하는 계층

BSW와 연결되는 BswCom, BswDcm 모듈 포함된다.

우리 프로젝트의 경우 BswCom, BswDcm 이 두개를 통해 CAN 통신을 구현하였다. (Com -> Rx / Dcm -> Tx)

 

1. Common

일반적으로 사용되는 Definition이나 Utility와 같은 것들을 넣어두고 사용한다.

참고로 우리 교육에선 NRC 리스트의 정의를 여기에 저장 후 수정 및 사용하였다.

0. Rte

AUTOSAR 구조에 따르면 APP과 BSW 간 인터페이스 역할을 수행하고, AUTOSAR 기반의 SWC(Software Component) 간 통신을 중재하는 역할이다.

굳이 이렇게 나눈 이유는 안정성과 신뢰성을 위함으로, 이를 좀 더 직관적으로 표현하면 다음과 같다.

 

 

 

이와 같이, Application Layer에서 Rte를 통해 정보 등을 요청하며 이를 Rte를 통해 Answer로 답을 하게 된다.

 

물론 저 화살표를 따라 정확히 주고 받는 것은 아니고, 저렇게 App에서 Rte를 통해 MCU까지 내려가서 요청한다는 그런 정도로 이해하면 될 것 같다.

---

물론 틀린 부분도 많고, 일부러 생략한 부분도 많다. 실제로 IVS 프로젝트를 진행하며 받은 프로젝트 폴더를 정말 세세히 분석하였기에, 이를 올리고 싶지만.. 이것을 올릴 순 없다. 그러나 이와 관련된 내용을 따로 IVS 교육 내용 정리에 일부 공개로 올릴 예정이니, 관심 부탁한다!!!