[DEM] 설정 구조 정리 (1) DemConfigSet

AUTOSAR 프로젝트를 처음 진행하면 많은 개발자가 가장 어렵게 느끼는 설정 중 하나가

바로 Dem(Diagnostic Event Manager) 이다.

Dem은 ECU 내부에서 발생하는 각종 고장을 감지하고, 저장하고, 진단기로 읽을 수 있도록 관리하는 모듈이다.

쉽게 말하면 차량 ECU의 고장 이력 관리자 역할을 한다고 보면 된다.

하지만 실제 툴에서 Dem 메뉴를 열어보면 Event, DTC, Freeze Frame, Debounce, Operation Cycle 등 수많은 항목이 트리 형태로 나열되어 있다. 처음 보는 사람 입장에서는 “어디부터 봐야 하지?”, “무슨 설정을 해야 하지?”라는 생각이 들 수밖에 없다.

이번 글에서는 실제 Dem 설정 화면의 구조를 기준으로, 각 항목이 어떤 역할을 하는지 하나씩 자세히 설명한다.

단순히 용어만 나열하는 것이 아니라, 실무에서는 왜 필요한지, 어떤 경우에 수정하는지까지 함께 정리한다.

 

1. Dem 전체 구조 이해하기

 

Dem 메뉴는 크게 DemConfigSet 과 DemGeneral 두 영역으로 나뉜다.

 

이 두 영역은 이름은 비슷하지만 역할이 다르다.

DemConfigSet

: 고장(Event), DTC, Debounce와 같이 실제 Fault 동작 방식을 정의하는 영역이다.
즉, ECU에서 어떤 고장을 감지할 것인지, 몇 번 실패해야 Fault로 인정할 것인지, 어떤 DTC 번호를 사용할 것인지 등을 설정한다.

DemGeneral

: Fault를 저장하는 메모리 구조, Freeze Frame, Operation Cycle, Enable Condition처럼 Dem 전체 동작 환경을 설정하는 영역이다. 즉, Fault를 어디에 저장할지, 언제 저장할지, 어떤 조건에서만 동작할지를 관리한다.

처음 공부할 때는 DemConfigSet부터 이해하고, 그 다음 DemGeneral로 넘어가는 것이 가장 효율적이다.

 

2. DemConfigSet 상세 설명

 

DemConfigSet은 실무에서 가장 자주 수정하는 영역이다.

실제 프로젝트에서 신규 Fault를 추가하거나 DTC를 생성할 때 대부분 여기서 작업한다.

Component

Component는 ECU 내부 기능 단위 또는 소프트웨어 모듈 단위로 Fault를 분류하기 위한 항목이다.

예를 들어 하나의 ECU 안에는 모터 제어, CAN 통신, LIN 통신, 센서 처리 등 여러 기능이 함께 존재할 수 있다.

Fault가 많아질수록 관리가 어려워지기 때문에 기능별로 그룹을 나누는 것이 중요하다.

 

Debounce Counter Based Class

Dem의 Debounce Counter Based Class는 고장을 즉시 판단하지 않고,

내부 Counter 값을 이용해 일정 조건을 만족했을 때 Fault를 발생시키는 기능이다.

차량 환경에서는 노이즈, 통신 지연, 순간 센서 튐 현상이 자주 발생한다.

이런 일시적인 오류를 바로 고장으로 처리하면 불필요한 DTC가 많이 발생하게 된다.

이를 방지하기 위해 Counter 방식 Debounce를 사용한다.

쉽게 말하면 아래와 같은 개념이다.

- 오류 발생 시 Counter 증가
- 정상 복귀 시 Counter 감소
- Counter가 기준값 이상이면 FAIL
- Counter가 복구 기준값 이하이면 PASS

즉, 단순 1회 오류가 아니라 누적 결과로 Fault를 판단한다.

 

Debounce Time Base Class

Debounce Time Base Class는 횟수(Count) 가 아니라 시간(Time) 을 기준으로 Fault를 판정하는 방식이다.
즉, 오류가 발생했다고 바로 Fault를 띄우는 것이 아니라, 일정 시간 이상 오류 상태가 유지될 때만 고장으로 인정한다.

반대로 정상 상태도 일정 시간 이상 유지되어야 Fault를 해제한다.

순간적인 센서 튐, 짧은 전압 강하, 일시적인 통신 지연처럼 잠깐 발생하는 이상 신호를 무시하고 싶을 때 자주 사용한다.

현재 설정값 해석
Failed Threshold = 20
Passed Threshold = 40
Behavior = DEM_DEBOUNCE_RESET
Debounce Time Failed Threshold = 20

오류 상태가 설정된 기준 시간(주기 단위) 동안 20번 누적되면 Fault가 발생한다.
예를 들어 Dem MainFunction 주기가 10ms라면: 20 × 10ms = 200ms
즉, 200ms 이상 오류가 지속되어야 Fault가 발생한다.

Debounce Time Passed Threshold = 40
정상 상태가 40번 누적되면 Fault가 해제된다.
동일하게 주기가 10ms라면: 40 × 10ms = 400ms
즉, Fault 발생 후 400ms 동안 정상 상태가 유지되어야 복구된다.

Debounce Behavior = DEM_DEBOUNCE_RESET
이벤트 초기화, Clear DTC, IGN Cycle 변경 등의 특정 조건이 발생하면 내부 시간 카운터를 초기화하는 방식이다.
누적 시간을 계속 유지하지 않고 새로 다시 판정하게 만든다.

DTC

DTC는 Diagnostic Trouble Code의 약자이며, 진단기에서 읽히는 실제 고장 코드이다.

ECU 내부에서 Event가 발생하더라도 DTC가 연결되어 있지 않으면 서비스 툴에서 해당 Fault를 확인할 수 없다.

즉, 고객 서비스 관점에서는 DTC가 매우 중요하다.

예:
0x123456 CAN Timeout
0x234567 Motor Stall
0x345678 Over Voltage

정비소에서 스캔 툴을 연결했을 때 보이는 코드가 바로 이 DTC다.

DTC Attributes

DTC Attributes는 DTC의 세부 동작 속성을 정의한다.

예를 들어 Fault가 몇 번 정상 주기를 지나면 자동 삭제될지(Aging), 메모리에 영구 저장할지, Confirmed 상태가 되려면 어떤 조건이 필요한지 등을 여기서 설정한다.

이 항목은 단순 설정처럼 보이지만 OEM 요구사항과 직결되기 때문에 매우 중요하다.

Event Parameter

 

 

 

Event Parameter는 Dem에서 실제 고장(Fault)을 정의하는 가장 핵심 메뉴다.
DTC, Debounce, Operation Cycle, Enable Condition 등 여러 설정이 최종적으로 이 Event를 중심으로 연결된다.

 

쉽게 말하면 하나의 Fault 객체를 만드는 영역이라고 보면 된다.

 

요약하면,

Event Parameter는 하나의 Fault를 만들고, 그 Fault에 필요한 모든 진단 설정을 연결하는 중심 메뉴이다.

- Short Name 은 이벤트 이름이다.
프로젝트에서 Fault를 식별하는 논리 이름이며, 코드와 설정에서 함께 사용된다.

- Event Available 는 해당 Event를 현재 프로젝트에서 활성화할지 여부를 결정한다.

- Event Confirmation Threshold 는 Fault 발생 후 몇 번 Confirm 되었을 때 Confirmed DTC로 인정할지 설정한다.
만약 1로 설정한다면, 한 번 조건 만족 시 바로 Confirm 처리된다는 의미다.

- Event Id 는 Dem 내부에서 사용하는 고유 Event 번호다.
각 Event는 중복되지 않는 ID를 가져야 한다.

- Event Kind 는 이 Event가 어디(BSW, ASW)에서 보고되는 Fault임을 나타내는지 표시한다.
즉, 애플리케이션 로직에서 Dem_SetEventStatus() 같은 API로 제어하는 Event이다.

- Enable Condition Group Ref 는 특정 조건에서만 Fault를 감지하도록 Reference를 연결하는 설정이다.

- Operation Cycle Ref 는 이 Fault가 어떤 주기(IGN ON/OFF 등)를 기준으로 관리될지 설정한다.

- Debounce Algorithm Class 는 이 Event에 사용할 Fault 판정 방식(Counter Based / Time Based)을 연결하는 항목이다.

 

DemDtrs

DTR(Data Trouble Record) 관련 설정 영역이다.

일반적인 Body ECU 프로젝트에서는 사용 빈도가 낮을 수 있지만, 측정값 기반 진단이나 특정 규격 대응 프로젝트에서는 사용되기도 한다. 예를 들어 배출가스나 센서 성능 진단처럼 수치 기반 Trouble 정보를 관리할 때 활용된다.

우선순위가 낮으므로 나중에 학습해도 충분하다.