Mobilgene 전체 구조 한방 정리 (입문 → 실무 연결)

AUTOSAR 기반 개발을 처음 접하면 가장 크게 막히는 지점은 “개념이 어려워서”가 아니라,
각 요소들이 어떻게 연결되어 동작하는지 흐름이 머릿속에 그려지지 않기 때문이다.

특히 Mobilgene 환경에서는 코드가 자동 생성되기 때문에
구조를 이해하지 못하면 생성된 코드가 전부 낯설게 느껴지고,
문제가 발생했을 때 어디를 봐야 할지 감이 잡히지 않는다.

이 글에서는 단순 개념 나열이 아니라,
전체 구조 → 각 계층 역할 → 실제 데이터 흐름 → 실무에서의 의미
이 순서로 자연스럽게 설명해 보겠다.

 

1. AUTOSAR 구조, 왜 3계층인데 4개처럼 보이지?

 

AUTOSAR는 Layered Architecture로 구성되어 있으며,
주요 계층은 Application Layer, Runtime Environment (RTE), Basic Software (BSW), 그리고 Microcontroller (MCAR)로 이렇게 4개로 나눌 수 있다.  계층은 특정한 역할과 기능을 가지고 있으며, 서로 독립적으로 동작할 수 있도록 설계되어 있다.

 

AUTOSAR는 일반적으로 “3계층 구조”라고 설명된다.
하지만 실제 위 그림을 보면 다음과 같이 4개로 나뉘어 있는 경우가 많다.

 

이 때문에 많은 개발자가 처음부터 혼란을 겪는다.
이 부분은 단순히 외우는 것이 아니라, 개념을 정확히 구분해서 이해해야 한다.

AUTOSAR에서 말하는 3계층은 다음과 같다.
    - Application Layer (ASW)
    - RTE Layer (RTE)
    - Basic Software Layer (BSW)

여기서 MCAL은 별도의 계층이 아니라 "BSW 내부를 구성하는 가장 하위 레벨 드라이버 집합"이다.

 

2. 구조를 “역할 중심”으로 다시 보기

 

1) Application Layer – “로직만 존재하는 영역”

Application Layer는 ASW(Application Software)로 구성되어 있다.
ASW는 SWC(Software Component)의 집합으로 구성되어 있다.

개발자가 실제로 코드를 작성하는 유일한 영역이다.

이 계층의 가장 중요한 특징은 하드웨어에 대한 정보가 완전히 제거되어 있다는 점이다.

 

예를 들어 차량 속도를 읽는 코드가 있다고 가정하면,

uint8 speed;
Rte_Read_VehicleSpeed(&speed);

이 코드만 보면 다음과 같은 정보는 전혀 드러나지 않는다.

- CAN에서 온 데이터인지?
- 센서에서 직접 읽은 값인지?
- 다른 ECU에서 전달된 값인지?

즉, Application은 “데이터의 출처”를 알 필요가 없다.
그저 필요한 데이터를 읽고, 판단하고, 결과를 출력하는 역할만 수행한다.

이 구조 덕분에 Application 코드는

플랫폼, 하드웨어, 통신 방식이 바뀌어도 그대로 재사용이 가능하다.

 

 

2) RTE – “연결과 추상화의 핵심”

RTE(Runtime Environment)는 AUTOSAR 구조의 중심이라고 봐도 무방하다.

많은 초급 개발자가 RTE를 단순한 “중간 레이어”로 이해하는데,

실제로는 훨씬 중요한 역할을 수행한다.

RTE는 다음과 같은 책임을 가진다.
- SWC 간 데이터 전달
- SWC ↔ BSW 연결
- 함수 호출 매핑
- 데이터 버퍼 관리
- 이벤트 기반 실행 트리거

즉, RTE는 단순히 데이터를 전달하는 것이 아니라, 전체 시스템에서 데이터 흐름을 ‘관리’하는 계층이다.

 

왜 RTE가 반드시 필요한가?

만약 RTE가 없다면 어떤 문제가 발생할까?
- SWC가 직접 CAN Driver를 호출해야 한다.
- 하드웨어가 변경되면 Application 코드 수정이 필요하다.
- 인터페이스 변경 시 영향 범위가 커진다.

RTE는 이러한 문제를 해결하기 위해 완전한 인터페이스 기반 구조를 만들어준다.

그 결과 Application은 오직 RTE API만 사용하게 되고,
내부 구현이 어떻게 바뀌든 영향을 받지 않는다.

 

Mobilgene은 바로 이 RTE를 자동 생성해주는 도구이다.
개발자가 ARXML로 구조를 정의하면, Mobilgene이 이를 기반으로 다음을 생성한다.
- Rte_Read / Rte_Write API
- Port 연결 코드
- Runnable 연결 코드
- 내부 버퍼 및 인터페이스 코드

즉, RTE는 작성하는 코드가 아니라 설정으로부터 생성되는 코드이다.

 

 

3) BSW – “실제 기능이 동작하는 영역”

BSW(Basic Software)는 이름 그대로 기본 소프트웨어 계층이지만,
실제로는 시스템의 대부분의 기능이 이곳에서 수행된다.

 

이 계층은 크게 두 가지 역할로 나뉜다.
1) 서비스 계층
    - OS (Task 스케줄링)
    - ECU State Manager
    - Communication Stack

 

2) 하드웨어 제어 계층
    - CAN Driver
    - LIN Driver
    - ADC / DIO

이 계층의 핵심 역할은 하드웨어와 직접 통신하고, 그 결과를 상위 계층에 제공하는 것이다.

Application은 이 계층을 직접 호출하지 않고, 항상 RTE를 통해 간접적으로 접근한다.

 

 

4) MCAL – “가장 아래에서 실제 레지스터를 건드리는 영역”

MCAL은 BSW 내부에서도 가장 하위 레벨이다.

이 계층은 다음과 같은 특징을 가진다.
- MCU 레지스터 직접 제어
- 하드웨어 의존성 100%
- 플랫폼 변경 시 가장 많이 수정되는 영역

3. Mobilgene 기준 전체 동작 흐름

 

이제 구조를 실제 흐름으로 연결해보면 다음과 같다.

[ ARXML 설정 ]
        ↓
[ Mobilgene 코드 생성 ]
        ↓
[ RTE 구성 완료 ]
        ↓
[ SWC 로직 작성 ]
        ↓
[ ECU 실행 ]

 

여기서 중요한 점은 개발자는 코드를 처음부터 만드는 것이 아니라
"구조를 정의하고 그 위에 로직을 얹는 것"이라는 점이다.

 

데이터 흐름을 이해해야 디버깅이 된다.
실무에서 가장 중요한 것은 구조보다 데이터가 실제로 어떻게 흐르는지 이해하는 것이다.

 

4. 실제 개발자가 하는 일 (실무 기준)

 

실제로 개발자가 하는 일은 크게 3가지다.

1. ARXML 설정
   → Port / Interface 정의
2. Runnable 작성
   → Rte_Read / Write 사용해서 로직 구현
3. 디버깅
   → 데이터 흐름 기반으로 문제 분석

 

정리

 

데이터 흐름을 이해해야 디버깅이 된다.

ARXML로 구조를 정의하면, RTE가 연결을 만들고, SWC는 로직만 담당한다.

이 요약만 정확히 이해하고 있어도
구조가 머릿속에 정리되고, 디버깅 방향이 잡히며, RTE 코드가 읽히기 시작한다.

실무에서 가장 중요한 것은 구조보다 데이터가 실제로 어떻게 흐르는지 이해하는 것이다.