[DCM] DCM 전체 구조 이해하기 (DSL, DSD, DSP 설명 포함)

AUTOSAR 프로젝트에서 DCM(Diagnostic Communication Manager)은 반드시 설정하게 되는 핵심 BSW 모듈이다.

진단기(CANoe, CANalyzer, OEM Tester 등)에서 ECU로 요청을 보내면,
ECU는 해당 요청을 해석하고 적절한 응답을 보내야 한다.
이 전체 흐름을 담당하는 모듈이 바로 DCM이다.

하지만 ecud_Dcm.arxml 파일을 처음 열어보면 메뉴가 많고 구조가 복잡해서 어디서부터 시작해야 할지 막막하다.

이 항목들이 무엇을 의미하는지 먼저 이해해야 이후 DID, Session, Security 설정도 자연스럽게 진행할 수 있다.

이번 글에서는 ecud_Dcm.arxml 구조를 실무 관점에서 먼저 정리하고, 각 메뉴에서 무엇을 설정하는지 단계별로 설명한다.

1. DCM 전체 구조 한눈에 보기

 
DCM은 크게 3개 계층으로 나뉜다.

 
Tester 요청 수신 → DSL → DSD → DSP → 응답 생성
즉, 진단 요청이 들어오면 순서대로 흘러간다.
 

2. 각 구조 역할 설명

 
1) DcmDsl = Diagnostic Session Layer

가장 아래쪽 DCM 내부에서 통신 인터페이스를 담당하는 계층이다.
외부에서 들어오는 진단 요청(Request)을 수신하고, 처리 완료된 응답(Response)을 다시 외부로 전송한다.
 
쉽게 말하면 "진단 데이터를 받아오고 보내는 창구" 이다.

DcmDsl에서 주로 설정하는 것

 
- Buffer: 진단 요청과 응답 데이터를 저장하는 버퍼 설정이다.
- Callback DCM Request Service: 진단 요청이 들어왔을 때 Callback 함수를 통해 선행 조건을 검사하는 설정이다.
- DcmDslDiagResp: 진단 응답 관련 설정이다.
- DcmDiagComProtocol: 진단 통신 프로토콜 설정이다.

2) DcmDsd = Diagnostic Service Dispatcher

DcmDsl이 받은 진단 요청을 분석해서,
어떤 서비스인지 판별하고 해당 처리 영역(DcmDsp)으로 전달하는 계층이다.
 
쉽게 말하면 "진단 요청 접수 후 어디로 보낼지 결정하는 관리자" 이다.

- Service Table: 가장 핵심 설정이다. ECU가 어떤 진단 서비스를 지원할지 정의하는 영역이다.

예:

0x10 DiagnosticSessionControl
0x11 ECUReset
0x19 ReadDTCInformation
0x22 ReadDataByIdentifier
0x27 SecurityAccess
0x2E WriteDataByIdentifier
0x31 RoutineControl
0x3E TesterPresent
 
즉, 여기 등록되지 않은 서비스는 요청이 와도 처리되지 않는다.
 
- Service Request Manufacturer Notification: 진단 요청이 들어왔을 때 차량 제조사(OEM)용 Callback Notification 을 수행하는 영역이다. 즉, 서비스 처리 전에 OEM 전용 로직을 넣을 수 있다.
쉽게 말하면 "OEM 전용 요청 감시 Hook"
 
- Service Request Supplier Notification: 진단 요청이 들어왔을 때 부품사(Supplier)용 Callback Notification 을 수행하는 영역이다. OEM과 별도로 공급사 개발 로직을 넣을 수 있다.
쉽게 말하면 "Supplier 전용 요청 감시 Hook"
 
3) DcmDsp = Diagnostic Service Processing

DcmDsd가 요청 서비스를 판별하면,
실제 데이터 읽기, 쓰기, 초기화, Reset, Security Unlock 같은 동작은 모두 DcmDsp에서 처리된다.

쉽게 말하면 "진단 기능 본체"

 
- Common Authorization: 공통 권한 설정 영역이다.
특정 서비스 실행 전에 공통으로 검사할 조건을 정의한다.
즉 여러 서비스에서 공통으로 사용하는 접근 권한 관리다.

- Data: 진단 데이터 정의 영역이다. DID나 Memory 서비스에서 사용하는 실제 데이터 객체를 정의한다.
- Data Info: Data의 속성 정보다. (고정 길이 / 가변 길이, Read/Write 가능 여부 등)
- Did: 가장 많이 사용하는 메뉴다. DID(Data Identifier)를 생성하는 곳이다.
- Did Info: DID의 부가 설정이다. 즉, DID 권한 관리 영역이다.
- Routine: RoutineControl(0x31) 설정이다. 특정 동작을 실행하는 서비스다.
- Veh Info: Vehicle Information 관련 데이터 설정이다. OEM별 Vehicle Information DID 또는 차량 정보 서비스와 연결될 수 있다.
- DcmDspClearDTC: UDS 서비스(0x14 ClearDiagnosticInformation) DTC 삭제 기능 설정이다.
- DcmDspComControl: UDS 서비스(0x28 CommunicationControl) 통신 송수신 Enable/Disable 설정이다.
- DcmDspControlDTCSetting: UDS 서비스(0x85 ControlDTCSetting) DTC 기록 활성/비활성 설정이다.
- DcmDspEcuReset: UDS 서비스(0x11 ECUReset) ECU Reset 종류를 설정한다.
- DcmDspMemory: 메모리 접근 서비스 설정이다. Flash, EEPROM 접근과 연결될 수 있다.
- DcmDspMemoryTransfer: 프로그래밍(Flashing) 관련 설정이다. 즉 SW 업데이트 기능과 연결된다.
- DcmDspPeriodicTransmission: 주기 전송 설정이다. 특정 DID를 일정 주기로 자동 응답한다.
- DcmDspRequestFileTransfer: 파일 전송 서비스 설정이다. 일부 최신 진단 환경에서 파일 단위 전송 시 사용한다.
- DcmDspSecurity: UDS 서비스(0x27 SecurityAccess) Seed / Key 인증 설정이다.
- DcmDspSession: UDS 서비스(0x10 DiagnosticSessionControl) 세션 설정이다.
 

실무에서 가장 많이 만지는 메뉴 TOP 3

 
1. Data
2. Did
3. Did Info
 

정리

 

DCM은 복잡해 보이지만 구조만 이해하면 명확하다.
무작정 DID부터 만드는 것이 아니라, 통신 → 서비스 분배 → 기능 처리 흐름으로 접근해야 한다.

이 글을 기준으로 다음 단계인 DID 설정까지 이어가면 실제 프로젝트 적용도 훨씬 수월해진다.