AUTOSAR 프로젝트를 진행하다 보면 ECUC 설정 파일 중에서 Ecud_Det.arxml 파일을 보게 되는 경우가 있다.
하지만 실제 프로젝트에서는 Det 모듈을 직접 수정하거나 설정할 일이 많지 않다 보니,
많은 개발자들이 다음과 같은 생각을 하게 된다.
- “이 모듈은 대체 뭐 하는 애지?”
- “왜 있는 거지?”
- “안 건드려도 되는데 왜 AUTOSAR에 포함되어 있지?”
특히 Application SW 개발을 주로 하는 경우에는 Com, Dcm, Dem, CanIf 같은 모듈은 자주 접하지만 Det는 거의 수정하지 않는 경우도 많다.
그래서 이번 글에서는 AUTOSAR의 Det 모듈이 정확히 무엇인지, 왜 존재하는지, 실제로 어떤 역할을 하는지, 그리고 어떤 상황에서 설정을 변경하게 되는지를 초보자 관점에서 정리해보려고 한다.
Det란 무엇인가?
Det는 Development Error Tracer의 약자이다.
이름 그대로 개발 단계에서 발생하는 오류를 추적하기 위한 AUTOSAR 모듈이다.
여기서 중요한 점은 “개발 단계(Development)” 라는 부분이다.
즉, Det는 차량 양산 이후 고객이 사용하는 진단 기능이라기보다는,
ECU 소프트웨어를 개발하고 디버깅하는 과정에서 발생하는 문제를 빠르게 발견하기 위한 디버그용 모듈에 가깝다.
예를 들어 AUTOSAR의 CAN Driver를 사용한다고 가정해보자.
원래는 다음과 같은 순서로 동작해야 한다.
Can_Init();
Can_Write();
그런데 개발자가 실수로 Can_Init()을 호출하지 않은 상태에서 Can_Write()를 먼저 호출했다면 내부적으로 상태 오류가 발생하게 된다.
이때 AUTOSAR BSW 모듈 내부에서는 다음과 같은 형태로 오류를 보고할 수 있다.
(void)Det_ReportError(CAN_MODULE_ID, 0U, ApiId, ErrorId);
즉, “CAN Driver가 초기화되지 않았는데 Write API를 호출했다.”
라는 개발 오류를 Det를 통해 보고하는 것이다.
Det는 어떤 역할을 할까?
Det는 AUTOSAR 내부에서 개발자가 잘못된 방식으로 API를 사용했는지 확인하는 역할을 수행한다.
특히 AUTOSAR는 수많은 BSW 모듈들이 서로 연결되어 동작하기 때문에 초기화 순서나 상태 관리가 매우 중요하다.
예를 들어 다음과 같은 문제들은 실제 AUTOSAR 개발 과정에서 자주 발생할 수 있다.
- 초기화 전에 API 호출
- NULL 포인터 전달
- 잘못된 파라미터 값 사용
- 잘못된 상태(State)에서 함수 호출
- 설정값 오류
- 범위를 벗어난 값 전달
Det는 이런 문제를 실행 중에 감지하여 개발자가 빠르게 원인을 찾을 수 있도록 도와준다.
쉽게 말하면 다음과 같은 개념이다.
“AUTOSAR 내부 개발 실수를 감지하는 디버그용 안전장치”라고 보면 이해하기 쉽다.
Det와 Dem은 완전히 다른 모듈이다
AUTOSAR를 처음 공부할 때 Det와 Dem을 헷갈리는 경우가 매우 많다.
이름도 비슷하고 둘 다 “오류”와 관련되어 있기 때문이다.
하지만 실제 목적은 완전히 다르다.
Det는 개발 중 발생하는 소프트웨어 사용 오류를 추적하기 위한 모듈이고,
Dem은 차량에서 발생한 실제 고장 이벤트를 관리하는 진단 모듈이다.
예를 들어 다음과 같은 경우를 생각해볼 수 있다.
Det의 경우
- 초기화 안 된 API를 호출함
- NULL 포인터 전달함
- 잘못된 상태에서 함수 호출함
같은 개발자 실수를 추적한다.
반면 Dem은 다음과 같은 차량 실제 고장을 관리한다.
- CAN Bus-Off 발생
- 센서 이상
- 모터 과전류
- 통신 장애
- 배터리 이상
그리고 이런 오류는 DTC 형태로 저장되어 UDS 진단기로 읽을 수 있게 된다.
즉, 정리하면 아래와 같다.
Det = 개발 오류 추적
Dem = 차량 진단 이벤트 관리
Ecud_Det.arxml은 무엇인가?
Ecud_Det.arxml 파일은 AUTOSAR의 Det 모듈 설정 정보를 저장하는 ECUC 설정 파일이다.
보통 AUTOSAR 설정 툴(Mobilgene, DaVinci, Tresos 등)에서 생성되며,
Det 모듈의 동작 방식이나 오류 처리 방식을 설정할 수 있도록 구성되어 있다.
실제로 설정 화면을 보면 다음과 같은 구조를 확인할 수 있다.

처음 보면 상당히 복잡해 보일 수 있지만, 실제 의미는 그렇게 어렵지 않다.
우선 DetGeneral 영역에서는 Det 모듈의 전체 동작 옵션들을 설정하게 된다.

예를 들어 화면에서 볼 수 있는 Forward To Dlt, Version Info API, Ram Buffer Size 같은 항목들이 여기에 포함된다.
- Forward To Dlt 옵션은 Det 오류를 DLT(Diagnostic Log and Trace) 시스템으로 전달할지 여부를 의미한다.
만약 true로 설정하면 Det에서 발생한 오류 정보를 DLT 로그 시스템으로 넘겨서 디버깅 로그로 확인할 수 있게 된다.
반대로 false이면 DLT 전달 없이 내부 처리만 수행하게 된다.
- Version Info API 옵션은 Det 모듈의 버전 정보를 조회하는 API를 사용할지 여부를 설정하는 항목이다.
- Ram Buffer Size는 Det 오류 정보를 RAM에 얼마나 저장할 것인지에 대한 버퍼 크기 설정이다.
현재 화면에서는 255로 설정되어 있는데, 이는 오류 로그를 임시 저장하기 위한 버퍼 크기라고 볼 수 있다.
그 다음으로 DetNotification 영역은 오류 발생 시 호출할 Hook 함수 또는 Callback 함수를 설정하는 부분이다.

현재 설정에서는 Det_ErrorHook 라는 함수가 연결되어 있다.
즉, AUTOSAR 내부에서 Det 오류가 발생하면 단순히 오류 코드만 기록하는 것이 아니라,
Det_ErrorHook() 함수를 추가로 호출하여 사용자 정의 동작을 수행할 수 있다는 의미이다.
예를 들면 이런 작업들이 가능하다.
- UART 로그 출력
- 디버거 메시지 출력
- 특정 변수 저장
- 오류 카운트 증가
- 개발용 Trace 기록
즉, 개발 중 디버깅을 좀 더 쉽게 하기 위한 확장 기능이라고 볼 수 있다.
DetConfigSet 영역은 실제 Det 설정 집합(Config Set)을 관리하는 부분이다.
그리고 그 안의 Module 영역에서는 어떤 AUTOSAR 모듈의 오류를 관리할 것인지 정의하게 된다.

현재 화면에서는 DS000, ID = 4096 이라는 항목이 보이는데,
이것은 특정 모듈에 대한 식별 ID(Module ID)를 의미한다.
AUTOSAR에서는 각 BSW 모듈들이 고유한 Module ID를 가지며,
Det 오류 발생 시 어떤 모듈에서 오류가 발생했는지 구분하기 위해 사용된다.
즉, 내부적으로는 다음과 같은 형태로 활용된다.
Det_ReportError(uint16 ModuleId, uint8 InstanceId, uint8 ApiId, uint8 ErrorId)
여기서 ModuleId 값으로 사용되는 것이 바로 이런 ID 값이다.
정리하면 Ecud_Det.arxml은 단순한 옵션 파일이 아니라,
AUTOSAR 개발 오류를 어떤 방식으로 기록하고, 어디로 전달하고,
어떤 Hook 함수로 처리할 것인지 정의하는 설정 파일이라고 이해하는 것이 가장 정확하다.
그런데 왜 실무에서는 거의 안 건드릴까?
실제로 프로젝트를 진행하다 보면 Det를 거의 수정하지 않는 경우도 많다.
특히 Application SW 개발자라면 다음과 같은 생각이 들 수 있다.
“프로젝트 하면서 한 번도 수정 안 해봤는데?”
실제로 그런 경우가 많다.
그 이유는 대부분의 AUTOSAR Stack 업체들이 기본적인 Det 설정을 이미 제공하기 때문이다.
그리고 Det는 Application 기능을 구현하는 모듈이 아니라 내부 디버그 지원용 모듈이기 때문에,
프로젝트 기능 요구사항에 따라 자주 변경되는 영역이 아니다.
또한 많은 프로젝트에서는 다음과 같은 방식으로 사용된다.
- Debug Build에서는 활성화
- Release Build에서는 비활성화
- 기본 설정 유지
- 특별한 로그 기능만 추가
즉, 존재 자체는 중요하지만, 실제 수정 빈도는 높지 않은 모듈이다.
그렇다면 언제 Det 설정을 변경할까?
Det는 평소에는 기본 설정으로 사용하는 경우가 많지만,
특정 상황에서는 설정을 변경하거나 추가 기능을 연결하기도 한다.
대표적인 경우는 개발 중 디버깅 로그를 강화하고 싶을 때이다.
또 다른 경우는 Custom Error Hook을 연결하는 상황이다.
프로젝트에 따라서는 Det 오류 발생 시 사용자 정의 함수를 호출하여 별도의 로그 저장이나 디버그 동작을 수행하기도 한다.
BSW 연동 검증 단계에서도 Det는 매우 유용하게 사용된다.
예를 들어 다음과 같은 문제를 빠르게 발견할 수 있다.
- CanIf 초기화 누락
- Com 설정 오류
- NvM 상태 오류
- Dcm 초기화 순서 문제
특히 AUTOSAR 초기 포팅 단계에서는 Det 로그가 문제 원인 분석에 큰 도움이 된다.
초보자가 꼭 기억해야 하는 핵심
Det를 처음 보면 매우 복잡해 보일 수 있다.
하지만 핵심은 생각보다 단순하다.
Det는 AUTOSAR 내부에서 발생하는 개발용 오류를 추적하기 위한 디버그 모듈이다.
즉, 다음처럼 이해하면 된다.
Det는 개발자가 API를 잘못 사용했는지 감지하는 AUTOSAR 내부 디버거이다.
그리고 중요한 점은 다음과 같다.
- 차량 고장을 저장하는 모듈이 아니다.
- DTC를 관리하는 모듈이 아니다.
- UDS 진단 서비스와 직접 연결되는 모듈도 아니다.
- 개발 단계에서 오류를 빠르게 찾기 위한 용도이다.
정리
Det는 AUTOSAR에서 개발 단계 오류를 추적하기 위해 존재하는 모듈이다.
실제 프로젝트에서는 자주 수정하지 않을 수도 있지만,
AUTOSAR 구조를 이해하려면 반드시 개념 정도는 알고 있어야 하는 중요한 모듈 중 하나이다.
특히 AUTOSAR를 처음 공부할 때는 다음 3개 역할 차이를 명확히 이해하는 것이 중요하다.
Det → 개발 오류 추적
Dem → 차량 진단 이벤트 관리
Dcm → UDS 진단 통신 처리
이 차이만 정확히 이해해도 AUTOSAR 진단 구조가 훨씬 쉽게 보이기 시작한다.
'mobilgene > 미분류' 카테고리의 다른 글
| [Fota] 다운 그레이드 방지 해제와 OEUK 미적용 방법 (0) | 2026.05.30 |
|---|---|
| [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 |