자동차 ECU 프로젝트를 진행하다 보면 어느 순간부터 단순 CAN 통신이나 AUTOSAR 설정만 보는 것이 아니라, FOTA나 보안 관련 설정까지 수정해야 하는 경우가 생긴다.
특히 양산 프로젝트나 OEM 대응을 하다 보면 다음과 같은 요청을 종종 받게 된다.
- DowngradeProtection 해제
- OEUK 서비스 제거
- SecurityAccess 수정
- FOTA 기능 비활성화
처음 이런 가이드를 받으면 대부분 당황하게 된다.
- “이걸 왜 끄는 거지?”
- “이 설정은 어디서 하는 거지?”
- “잘못 수정하면 ECU가 벽돌 되는 거 아닌가?”
실제로 FOTA나 보안 관련 설정은 ECU Download, Bootloader, 진단 통신과 직접 연결되기 때문에 단순 옵션 하나 수정하는 수준으로 보면 안 되는 경우가 많다.
이번 글에서는 Mobilgene 기준으로 Downgrade Protection과 OEUK 관련 설정이 무엇인지, 왜 수정하는지, 그리고 실제로 어디서 설정하는지를 정리해본다.
다운그레이드 방지(Downgrade Protection)는 왜 존재할까?
자동차 ECU는 OTA 또는 정비 환경에서 새로운 소프트웨어를 다운로드할 수 있다.
그런데 여기서 문제가 하나 발생한다.
만약 누군가 이전 버전 소프트웨어를 다시 ECU에 다운로드하면 어떻게 될까?
예를 들어 현재 ECU 버전이 다음과 같다고 가정해보자.
현재 ECU Version : 1.0.5
그런데 누군가 이전 버전인 1.0.3을 다시 다운로드하려고 시도할 수도 있다.
이 경우 이전 버전에 존재하던 버그나 보안 취약점이 다시 살아날 수 있다.
그래서 많은 OEM들은 이전 버전 다운로드를 막는 기능을 넣는다.
이 기능이 바로 Downgrade Protection 또는 Anti Rollback 기능이다.
즉, 현재 ECU보다 낮은 버전이 들어오면 Flash 자체를 거부하도록 만드는 것이다.
Mobilgene에서는 어디서 설정할까?
실제 프로젝트에서는 이 기능이 Bootloader(FBL)와 FOTA 영역에서 함께 동작하는 경우가 많다.
Mobilgene에서는 보통 Ecud_Fota.arxml파일 내 다음과 같은 위치에서 확인할 수 있다.

실제로 설정 화면을 보면 ' Downgrade Protection ' 항목이 존재한다.
여기서 true 상태라면 이전 버전 다운로드를 차단하게 되고, false 상태라면 이전 버전 Flash도 허용하게 된다.
실무에서는 OEM 요구사항이나 개발 단계에 따라 이 옵션을 변경하는 경우가 있다.
예를 들어 개발 단계에서는 테스트 편의상 이전 버전 재다운로드가 필요할 수 있다.
하지만 양산 단계에서는 대부분 활성화하는 경우가 많다.
왜 다운그레이드 방지를 해제할까?
처음 보면 보안 기능인데 왜 끄는지 의아할 수 있다.
하지만 실제 개발 환경에서는 다음과 같은 상황이 자주 발생한다.
개발 중인 ECU에 신규 버전을 올렸는데 문제가 발생했다.
그런데 이전 정상 버전으로 다시 내려가야 테스트를 계속할 수 있는 상황이 생긴다.
이 경우 Downgrade Protection이 켜져 있으면 이전 버전 다운로드가 거부된다.
결국 테스트 불가능, 재현 불가능, Rollback 불가능한 상황이 발생할 수 있다.
그래서 개발 단계나 특정 OEM 미적용 프로젝트에서는 Downgrade Protection을 끄고 사용하는 경우가 존재한다.
OEUK 서비스는 무엇일까?
다음으로 많이 보게 되는 것이 OEUK 관련 설정이다.
프로젝트마다 정확한 의미는 조금씩 다르지만, 보통 OEM 전용 OTA/FOTA 인증 또는 보안 절차와 연결된 경우가 많다.
특히 다음과 같은 기능들과 함께 등장하는 경우가 많다.
- ECU Unlock
- Secure Download
- 인증 Key 검증
- OTA 인증
- SecurityAccess 확장 기능
Mobilgene DCM 설정을 보면 실제로 다음과 같은 항목들이 존재하는 경우가 있다.
SID27_SecurityAccess
└ GetSeed_OEUK
└ CompareKey_OEUK
이런 항목은 일반 SecurityAccess 외에 OEM 전용 Unlock 절차가 추가된 형태라고 이해하면 된다.
즉, ECU가 특정 다운로드나 보안 기능을 수행하기 전에 OEM 인증 절차를 통과하도록 만드는 것이다.
왜 OEUK 서비스를 제거할까?
실제 프로젝트에서는 OEM 사양이 바뀌거나 특정 기능이 미적용되는 경우가 존재한다.
예를 들어 현재 프로젝트에서는 OTA 인증 기능을 사용하지 않기로 결정되었거나, 특정 OEM 보안 절차가 제외될 수도 있다.
이 경우 DCM 내부에 OEUK 관련 서비스가 남아 있으면
- 사용하지 않는 인증 루틴이 유지됨
- 불필요한 SecurityAccess 경로가 남음
- Flash Sequence가 꼬일 수 있음
- OEM 검증에서 Fail 가능성 발생
같은 문제가 생길 수 있다.
그래서 OEUK 미적용 위해 Dcm 에서 OEUK 관련 서비스를 삭제하라고 가이드를 주는 경우가 많다.
실제로 어디서 제거할까?
Mobilgene 기준으로 Ecud_Dcm.arxml에서 보통 아래 경로의 'SID27_SecurityAccess' 에서 확인할 수 있다.

여기서 다음과 같은 SubService가 존재할 수 있다.
- GetSeed_OEUK
- CompareKey_OEUK
이 항목들이 OEM 전용 Unlock 절차와 연결되어 있는 경우가 많다.
프로젝트 가이드에서 OEUK 미적용이라고 했다면 보통 이런 Sub Service를 제거하거나 Used 옵션을 false 처리하는 방식으로 비활성화하게 된다.
단순 설정 수정으로 끝나지 않는 이유
여기서 중요한 점은 이런 설정이 단순 UI 옵션 변경으로 끝나지 않는 경우가 많다는 것이다.
왜냐하면 다음 영역들이 서로 연결되어 있기 때문이다.
- DCM
- FBL
- RTSW
- NvM
- SecurityAccess
- RoutineControl
- Download Manager
예를 들어 DCM에서 서비스를 삭제했는데 내부 Callback 함수는 그대로 남아 있을 수 있다.
그러면 링크 에러, Undefined Reference, Generator Error 같은 문제가 발생할 수도 있다.
그래서 실무에서는 보통
- DCM 서비스 제거
- 관련 Callback 제거
- FBL 설정 제거
- FOTA 설정 수정
- Version Check 제거
정리
AUTOSAR나 Mobilgene를 처음 공부할 때는 설정 화면 자체에만 집중하게 되는 경우가 많다. 하지만 실제 ECU 프로젝트에서는 체크박스 하나, Service 하나도 단순 옵션이 아니라 ECU 내부 동작 구조와 연결되어 있는 경우가 많다.
특히 FOTA, SecurityAccess, Bootloader, Download Sequence 같은 영역은 단순 진단 기능이 아니라 ECU 보안과 소프트웨어 업데이트 흐름 전체와 연결된다.
그래서 실무에서는 단순히 false로 변경, 서비스 삭제 수준으로 접근하는 것이 아니라,
왜 이 기능이 존재하는지, ECU 내부에서 어떤 흐름으로 동작하는지, 제거 시 어떤 영향이 발생하는지 까지 함께 이해하는 것이 중요하다.
이런 구조를 이해하기 시작하면 AUTOSAR 설정 화면도 단순 설정 메뉴가 아니라, ECU 내부 로직과 통신 흐름이 연결된 구조로 보이기 시작한다. 그리고 바로 그 시점부터 단순 설정 작업이 아니라 “왜 이런 설정이 필요한가”를 이해하는 ECU 개발 관점으로 넘어가게 된다.
'mobilgene > 미분류' 카테고리의 다른 글
| [Det] AUTOSAR Det(Development Error Tracer)란 무엇인가? (0) | 2026.05.25 |
|---|---|
| [WdgM] Watchdog Manager란? Mobilgene에서 WdgM 설정 구조 이해하기 (0) | 2026.05.15 |
| [IoHwAb] SWC에서 IoHwAb Analog Input을 읽는 과정 (Rte_Call 기반 실무 흐름) (0) | 2026.05.01 |
| [IoHwAb] AUTOSAR IoHwAb 완전 정리 2편 – IoHwAbConfig 구조와 실무 설정 (0) | 2026.04.30 |
| [IoHwAb] AUTOSAR IoHwAb 완전 정리 1편 – IoHwAbGeneral 구조와 실무 설정 (0) | 2026.04.30 |