┌────────────────────────────────────────────────────────┐
│ │
│ ASW (Application Software Layer) │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ 개발자가 작성하는 소프트웨어 │
│ - 엔진 제어 로직 │
│ - 제동 제어 로직 │
│ - 변속 제어 로직 │
│ - 진단 로직 │
│ - 하드웨어와는 무관하게 작성 │
│ │
├────────────────────────────────────────────────────────┤
│ │
│ RTE (Runtime Environment) │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ 자동으로 생성되는 중간 계층 │
│ - ASW와 BSW 연결 │
│ - 신호 라우팅 │
│ - 데이터 변환 │
│ - 동기화 │
│ 개발자는 건드리지 않음! │
│ │
├────────────────────────────────────────────────────────┤
│ │
│ BSW (Basic Software) │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ 기본 서비스 제공 │
│ - 통신 (CAN, LIN, Ethernet) │
│ - 메모리 관리 (NvM, Fee, Ea) │
│ - 진단 (Dem, Dcm) │
│ - 드라이버 추상화 │
│ - OS (운영체제) │
│ │
│ 하드웨어와 가까운 곳 │
│ │
├────────────────────────────────────────────────────────┤
│ 하드웨어 │
│ (CPU, 메모리, CAN 칩, 센서 등) │
└────────────────────────────────────────────────────────┘
1. ASW: Application Software Layer
ASW란?
ASW = 응용 소프트웨어
개발자가 직접 작성하는 소프트웨어예요. 자동차의 기능을 구현하는 곳이에요.
대부분의 자동차 소프트웨어 개발자는 ASW를 개발하고 계십니다.
ASW의 특징
1️⃣ 하드웨어 독립적
가장 중요한 특징이 이거예요.
예시: 엔진 제어 코드
ASW 개발자가 작성:
"엔진 RPM이 3000이면, 분사량 100ml"
이 코드는:
- BMW 칩에서도 동작
- Audi 칩에서도 동작
- Mercedes 칩에서도 동작
왜? 하드웨어에 직접 접근하지 않으니까!
(RTE를 통해서만 통신)
vs
하드웨어에 직접 접근하면:
"CAN 레지스터 0x123에 값 쓰기"
→ BMW 칩에서만 동작
→ 다른 칩이면 주소가 다름!
이게 AUTOSAR의 가장 큰 장점이에요.
2️⃣ 비즈니스 로직에만 집중
ASW 개발자는 "무엇"에만 집중하고, "어떻게"는 신경 쓰지 않아도 돼요.
"뭐를 할까?" (ASW 담당)
- 엔진 회전수를 3000으로 유지
- 냉각수 온도가 90도 이상이면 팬 작동
- 센서가 고장나면 DTC 기록
"어떻게 할까?" (BSW와 RTE가 담당)
- CAN 메시지 어디서 받을 건지
- 메모리는 어느 주소에 저장할 건지
- 하드웨어는 정확히 어떻게 제어할 건지
3️⃣ SWC (Software Component) 단위로 구성
ASW는 여러 개의 SWC (소프트웨어 컴포넌트)로 이루어져 있어요.
일반적인 자동차 ECU:
EngineControlSWC (엔진 제어 SWC)
├─ EngineControl_Runnable (10ms마다 실행)
├─ FuelInjection_Runnable
└─ EmissionControl_Runnable
DiagnosticSWC (진단 SWC)
├─ DTC_Recording_Runnable (100ms마다 실행)
└─ SelfTest_Runnable
각 SWC는 독립적으로 개발되고,
RTE를 통해 통신해요.
ASW의 역할
역할
설명
예시
센서 데이터 읽기
입력값 수신
"엔진 RPM: 3000"
로직 실행
계산 & 의사결정
"분사량 = RPM × 0.5"
액추에이터 제어
출력값 전송
"연료 분사!"
오류 처리
예외 상황 대응
"센서 고장! DTC 기록"
통신
다른 ECU와 협력
"변속기에 엔진 RPM 전송"
2. RTE: Runtime Environment
RTE란?
RTE = 런타임 환경
ASW와 BSW 사이의 중간 계층이에요. AUTOSAR의 가장 특별한 부분이에요.
가장 중요한 특징? 자동 생성된다!
제네레이트 코드라고도 부르고 생성 코드라고도 부르고 여러가지고 불립니다.
ASW 개발자는:
"엔진 RPM 읽기, 분사량 쓰기"라고 하고
RTE는:
"그게 CAN 메시지 ID 0x100의
바이트 0-1을 가져와서 × 0.25하고...
데이터 타입 변환하고...
동기화하고... 전달한다"는 걸
자동으로 처리해줘.
개발자는 손도 대지 않는데
수천 줄의 코드가 자동 생성됨!
RTE의 역할
1️⃣ 신호 라우팅 (Signal Routing)
ASW의 신호를 올바른 곳으로 전달하는 거예요.
예시: 엔진 RPM
EngineControlSWC가 "엔진 RPM 읽기"를 요청
↓
RTE가 "어디서 받아야 하나?" 검색
↓
설정 파일에서: "엔진 RPM은 CAN 메시지 0x100에서"
↓
BSW의 Com 모듈에서 CAN 데이터 가져오기
↓
"Data[0:1] = 0x2710" (십진수로 10000)
↓
스케일 적용: 10000 × 0.25 = 2500 rpm
↓
EngineControlSWC에 "2500"으로 전달
이 모든 걸 RTE가 투명하게 처리!
상황: 엔진 RPM을 여러 SWC가 읽음
Time 0ms:
- EngineControlSWC가 RPM 읽음 (3000)
- BrakeControlSWC가 RPM 읽음 (3000)
- TransmissionSWC가 RPM 읽음 (3000)
모든 SWC가 같은 값을 봐요!
(RTE가 스냅샷으로 관리)
vs
동기화 안 하면:
- 엔진제어가 3000 읽는데
- 변속제어가 3001 읽음 (시간 차이)
- 불일치 → 오류!
4️⃣ 주기 관리 (Timing Management)
각 Runnable이 정확한 시간에 실행되도록 해요.
Time 0ms: EngineControl_Runnable 실행 (10ms 주기)
Time 10ms: EngineControl_Runnable 실행
Time 20ms: EngineControl_Runnable 실행
Time 0ms: DiagnosticCheck_Runnable 실행 (100ms 주기)
Time 100ms: DiagnosticCheck_Runnable 실행
RTE (OS와 협력):
- 각 Runnable의 실행 시간 관리
- CPU 시간 할당
- 우선순위 결정
RTE의 특징: "자동 생성"이 핵심!
ASW 코드:
┌─────────────────────────────────────┐
│ #include "Rte_EngineControl.h" │
│ │
│ void EngineControl_10ms(void) { │
│ uint16 rpm = Rte_Read_EngineRPM();│
│ float torque = Calc(rpm); │
│ Rte_Write_DesiredTorque(torque); │
│ } │
└─────────────────────────────────────┘
개발자 작성 (짧음!)
RTE 자동 생성 코드:
┌─────────────────────────────────────┐
│ // Rte_EngineControl.h (자동 생성) │
│ // 수천 줄! │
│ │
│ uint16 Rte_Read_EngineRPM(void) { │
│ // CAN 메시지에서 신호 추출 │
│ // 바이트 변환 │
│ // 스케일 적용 │
│ // 데이터 타입 변환 │
│ // ... (복잡한 로직) │
│ return value; │
│ } │
│ │
│ void Rte_Write_DesiredTorque(...) {│
│ // 반대 방향 변환 │
│ // CAN 메시지에 삽입 │
│ // ... (복잡한 로직) │
│ } │
└─────────────────────────────────────┘
RTE 자동 생성 (수천 줄!)
왜 자동 생성할까?
1. 오류 감소: 수작업하면 버그 많음
2. 일관성: 모든 신호가 같은 방식으로 처리
3. 유지보수: 신호 변경 → RTE 재생성 (자동)
4. 개발 속도: 개발자는 비즈니스 로직만 작성
3. BSW: Basic Software Layer
BSW란?
BSW = 기본 소프트웨어
모든 저수준 서비스를 제공하는 계층이에요. ASW의 밑바탕이에요.
BSW의 역할
1️⃣ 통신 (Communication)
주요 모듈:
- Com: 신호 인코딩/디코딩
- CanIf: CAN 인터페이스
- CanTp: CAN 전송 프로토콜 (긴 메시지 분할)
- LinIf: LIN 인터페이스
- EthIf: Ethernet 인터페이스 (Adaptive용)
역할:
- CAN 메시지 보내고 받기
- 신호 매핑 (논리 신호 ↔ 물리 메시지)
- 버스 관리
2️⃣ 메모리 관리 (Memory Management)
주요 모듈:
- NvM: Non-Volatile Memory Manager (플래시/EEPROM 관리)
- Fee: Flash EEPROM Emulation
- Ea: EEPROM Abstraction
- MemIf: Memory Interface
역할:
- 엔진 맵 저장 (영구 보존)
- 설정값 저장
- 오류 로그 저장
- 전원 꺼져도 유지!
3️⃣ 진단 (Diagnostics)
주요 모듈:
- Dem: Diagnostic Event Manager (오류 감지/기록)
- Dcm: Diagnostic Communication Manager (진단 통신)
- Uds: Unified Diagnostic Services
역할:
- 센서 고장 감지
- DTC (오류 코드) 생성/저장
- 정비소 진단기와 통신
- "P0117: 엔진 온도 센서 저전압" 같은 오류 보고
4️⃣ OS (Operating System)
주요 역할:
- Task 스케줄링
- 인터럽트 처리
- 메모리 관리 (동적 할당)
- 뮤텍스/세마포어 (멀티코어 동기화)
AUTOSAR OS:
- OSEK (전통적, 단순)
- AUTOSAR OS (최신)
5️⃣ 드라이버 추상화 (HAL, MCAL)
HAL (Hardware Abstraction Layer):
- 특정 칩의 차이 숨김
- "GPIO 읽기", "ADC 값 읽기" 같은 추상화
MCAL (Microcontroller Abstraction Layer):
- 칩 레벨 드라이버
- "Bosch MCU GPIO", "Infineon MCU GPIO" 등
덕분에:
칩이 바뀌어도, HAL/MCAL만 수정
ASW는 변경 X!
BSW의 특징: "하드웨어 가까움"
BSW 아키텍처:
┌────────────────────────────────┐
│ Com, NvM, Dem, Dcm, ... │ ← ASW와 가까움
├────────────────────────────────┤
│ CanIf, LinIf, EthIf │ ← 통신 인터페이스
├────────────────────────────────┤
│ CAN Driver, LIN Driver │ ← 프로토콜 드라이버
├────────────────────────────────┤
│ HAL (GPIO, ADC, PWM 등) │ ← 하드웨어 추상화
├────────────────────────────────┤
│ MCAL (레지스터 접근) │ ← 칩 직접 제어
├────────────────────────────────┤
│ 하드웨어 │ ← CPU, 칩, 메모리
└────────────────────────────────┘
🔄 세 계층의 상호작용: 실제 예시
예시: 자동차 시동 후 엔진 RPM 읽기
[Step 1] ASW 실행
Time 0ms, EngineControl_10ms() 호출
┌────────────────────────────┐
│ uint16 rpm = Rte_Read_EngineRPM();
│ // "엔진 RPM 읽어줘!"
└────────────────┬───────────┘
↓
[Step 2] RTE 중간 처리
설정 파일 확인:
"EngineRPM은 CAN ID 0x100의
바이트 0-1, 스케일 0.25"
↓
BSW Com 모듈에 요청
"CAN ID 0x100의 데이터 줄래?"
↓
[Step 3] BSW 처리
CanIf: "CAN 버스에서 0x100 찾아"
↓
CAN Driver: "버스에서 메시지 읽기"
↓
받은 데이터: Data[0]=0x10, Data[1]=0x27
(16비트 정수: 0x2710 = 10000)
↓
Com 신호 디코딩:
신호값 10000 × 스케일 0.25 = 2500 rpm
↓
RTE에 전달: 2500
↓
[Step 4] RTE 반환
ASW에 "2500" 반환
↓
[Step 5] ASW 사용
┌────────────────────────────┐
│ uint16 rpm = 2500; // 받은 값!
│ if (rpm > 3000) {
│ // 분사량 줄이기
│ }
└────────────────────────────┘
예시: 엔진 제어 → 결과 전송
[Step 1] ASW 계산
┌────────────────────────────┐
│ float torque = rpm * 0.1; // 토크 계산
│ Rte_Write_DesiredTorque(torque);
│ // "변속기에 원하는 토크 500 Nm 전송"
└────────────────┬───────────┘
↓
[Step 2] RTE 변환
설정 파일 확인:
"DesiredTorque는 CAN ID 0x200의
바이트 2-3, 스케일 0.1"
↓
역변환 계산:
물리값 500 Nm ÷ 스케일 0.1 = 5000
↓
[Step 3] BSW 인코딩
Com: 5000을 16비트로 변환
0x1388
↓
Data[2] = 0x13
Data[3] = 0x88
↓
[Step 4] BSW 전송
Com: CAN 메시지 0x200 생성
CanIf: 라우팅 결정
CAN Driver: 버스에 전송
↓
CAN 버스에 0x200 #13 88 ...
↓
[Step 5] 다른 ECU 수신
변속기 ECU:
"아, 엔진이 500 Nm 토크를 원하네"
최적 기어 선택!
Why? : 왜 계층을 나눴을까?
1️⃣ 하드웨어 독립성
칩 변경 시:
❌ 계층 없이:
- ASW 전체 수정
- 신호 매핑 수정
- 드라이버 수정
→ 엄청난 작업!
✅ AUTOSAR 계층 사용:
- ASW는 그대로
- RTE는 자동 재생성
- BSW의 MCAL만 수정
→ 빠르고 안전!
2️⃣ 재사용성
같은 엔진 제어 SW:
- BMW 5시리즈에도 사용
- BMW 7시리즈에도 사용
- Mercedes에도 사용 (약간의 변수만 조정)
→ 개발 시간 & 비용 대폭 절감
3️⃣ 개발 병렬화
ASW 팀과 BSW 팀이 동시에 작업 가능:
ASW 팀: "엔진 제어 로직 개발"
↓
RTE 자동 생성 (정의된 인터페이스 기반)
↓
BSW 팀: "CAN 드라이버 개발"
→ 개발 시간 단축!
4️⃣ 테스트 용이성
테스트 시뮬레이션:
- ASW만 테스트하려면?
- RTE와 모의(Mock) BSW로 대체
- 실제 하드웨어 없이 테스트 가능!
→ 개발 초기부터 테스트 가능
5️⃣ 유지보수 용이성
신호 변경 시:
"CAN 메시지에 새로운 신호 추가"
❌ 계층 없이:
- ASW 코드 수정
- 통신 드라이버 수정
- → 버그 위험 높음
✅ AUTOSAR:
- 설정 파일만 수정
- RTE 재생성
- 나머지는 자동
→ 안전하고 빠름!
다 소프트웨어를 배울때나 코딩을 배울때, 아니면 정보처리기사 공부할 때 나왔던 방법론적인 것들이죠
정리: ASW-RTE-BSW 역할 요약
계층
개발자
핵심 역할
특징
ASW
응용개발자
기능 구현
하드웨어 독립적, 비즈니스 로직
RTE
자동 생성
신호 라우팅
투명한 중간계층, 동기화
BSW
BSW개발자
기본 서비스
하드웨어 가까움, 재사용 불가
다음 편 예고
이제 AUTOSAR의 전체 계층 구조를 이해했어요!
그런데 ASW는 정확히 어떻게 구성되어 있을까요? SWC, Runnable, Port 같은 용어들이 나오는데...
여기서부터는 실무자들만 이해할 수 있을 것 같아요.
다음 편에서는 "SWC와 Runnable: AUTOSAR 소프트웨어의 기본 단위"를 포스팅 해보겠습니다.
