AUTOSAR DCM - Diagnostic Request 처리 흐름 완전 이해 (DSL → DSD → DSP + 전체 흐름)

DCM 설정을 어느 정도 해보고 나면, 대부분 한 번쯤 같은 문제를 겪는다.

CAN 통신도 정상이고 DID 설정도 맞는 것 같은데, 실제로는 응답이 없거나 기대한 값이 나오지 않는 상황이다.

 

이때 많은 경우 설정을 다시 확인하는 데 시간을 쓰지만, 실제로 필요한 것은 설정이 아니라

"요청이 ECU 내부에서 어떤 경로로 이동하고 처리되는지에 대한 흐름 이해"다.

 

AUTOSAR 구조에서 DCM은 단순히 데이터를 읽고 쓰는 모듈이 아니라,

진단 요청을 해석하고 시스템 전체로 전달하는 중앙 처리 역할을 수행한다.

 

이 글에서는 Diagnostic Request가 들어왔을 때 내부에서 어떤 일이 일어나는지를

전체 흐름 → 내부 구조 → 실제 처리 흐름 순서로 연결해서 설명한다.

 

1. 전체 흐름 먼저 이해해야 한다

 

진단 요청은 외부 테스터에서 시작해서 ECU 내부를 거쳐 다시 응답으로 돌아가는 구조다.

이 흐름을 단순화하면 다음과 같다.

Tester → CAN → PduR → DCM → RTE → SWC

 

여기서 중요한 포인트는 하나다.

DCM은 끝이 아니라 중간 단계이며, 실제 데이터는 SWC에서 생성된다

 

이걸 이해하지 못하면, 문제 발생 시 DCM만 계속 보게 되고 원인을 놓치게 된다.

 

2. DCM과 다른 모듈의 관계

AUTOSAR_SWS_DiagnosticCommunicationManager.pdf 에서 발췌

 

이 그림은 DCM이 AUTOSAR 내부에서 어떤 모듈들과 연결되어 있는지를 보여준다.

진단 메시지는 PduR을 통해 DCM으로 전달되며, 실제 데이터 처리를 위해 RTE를 통해 SWC와 연동된다.

 

다만 이 그림은 데이터의 “흐름”을 상세히 보여주기보다는, 각 모듈 간의 의존 관계를 중심으로 표현되어 있다.

따라서 실제 동작을 이해하기 위해서는 이 구조를 기반으로 흐름을 머릿속에서 재구성할 필요가 있다.

 

3. DCM 내부 구조 (DSL → DSD → DSP)

 

이제 DCM 내부로 들어가 보자.

 

DCM은 하나의 덩어리가 아니라, 역할에 따라 세 단계로 나뉘어 있다.

DCM = DSL → DSD → DSP

 

이 구조는 단순한 분리가 아니라, 요청 처리 과정을 단계별로 나눈 것이다.

 

4. DCM 내부 구조

AUTOSAR_SWS_DiagnosticCommunicationManager.pdf 에서 발췌

 

이 그림은 DCM 내부에서 DSL, DSD, DSP가 어떻게 상호작용하는지를 보여준다.

진단 요청은 DSL에서 시작하여 DSD를 거쳐 DSP로 전달되며, 처리 결과는 다시 반대 방향으로 전달된다.

 

각 단계는 명확한 역할을 가진다.

DSL: 요청을 받아도 되는지 판단
DSD: 어떤 서비스로 처리할지 결정
DSP: 실제 데이터 처리 수행

 

5. 실제 요청 흐름을 단계별로 이해하기

 

이제 전체 흐름과 내부 구조를 연결해서, 실제 요청이 들어왔을 때 어떤 일이 일어나는지 살펴보자.

 

5.1 CAN → PduR: 단순 전달 구간

테스터에서 전송된 진단 요청은 CAN을 통해 ECU로 들어오고,

CAN Driver와 CanIf를 거쳐 PduR까지 전달된다.

 

이 구간은 데이터 전달만 수행하며 별도의 판단 로직은 없다.

따라서 이 단계에서 문제가 발생한다면, DCM이 아니라 통신 설정을 확인해야 한다.

 

5.2 DSL: 요청을 처리할 수 있는 상태인지 판단

PduR를 통과한 메시지는 DCM의 첫 단계인 DSL로 들어온다.

 

DSL은 단순히 데이터를 수신하는 계층이 아니라,

현재 ECU의 상태를 기준으로 해당 요청을 처리할 수 있는지를 판단하는 역할을 한다.

 

예를 들어 ECU가 Default Session 상태일 경우,

일부 DID는 접근이 제한되며 이러한 요청은 DSL 단계에서 차단된다.

 

즉, 요청이 실제 서비스 로직(DSP)까지 내려가기 전에 시스템 상태 조건을 먼저 통과해야 한다.

 

예를 들어, 특정 DID는 Extended Session에서만 접근 가능하다.

이때 ECU가 Default Session 상태라면 요청은 여기서 차단된다.

 

또한 DSL은 응답 시간(P2, P2*)을 관리하고, 처리가 지연될 경우 Pending 응답을 생성하는 역할도 수행한다.

지원하지 않는 SID가 들어올 경우, 이 단계에서 Negative Response Code (예: 0x11)가 생성된다.

 

5.3 DSD: 서비스 해석 및 분기

DSL을 통과한 요청은 DSD로 전달된다.

 

DSD는 요청 메시지의 SID를 기반으로 어떤 서비스인지 해석하고, 해당 요청을 적절한 처리 로직으로 전달한다.

이 구조는 모든 진단 요청을 하나의 진입점에서 처리하되, 서비스별 로직을 분리하기 위한 설계다.

 

즉, 새로운 서비스가 추가되더라도 기존 구조를 변경하지 않고 분기만 추가하면 되도록 만들어진 구조다.

예를 들어 0x22는 ReadDataByIdentifier 서비스로, 0x2E는 WriteDataByIdentifier 서비스로 전달된다.

 

이 단계는 일종의 라우터 역할을 하며, 지원하지 않는 서비스일 경우 여기서 바로 오류 응답이 생성된다.

지원하지 않는 SID가 들어올 경우, 이 단계에서 Negative Response Code (예: 0x11)가 생성된다.

 

5.4 DSP: 실제 처리 수행

DSP는 DCM 내부에서 실제 동작이 수행되는 핵심 구간이다.

 

예를 들어 DID Read 요청이 들어오면 다음과 같은 과정을 거친다.

1. DID 존재 여부 확인
2. 접근 권한 확인 (Session / Security)
3. 연결된 함수 호출

 

여기서 중요한 점은, 이 함수가 DCM 내부가 아니라는 것이다.

DSP → RTE → SWC

 

AUTOSAR 구조에서는 Application 로직이 SWC에 있기 때문에,

DSP는 RTE를 통해 SWC의 함수를 호출한다.

지원하지 않는 SID가 들어올 경우, 이 단계에서 Negative Response Code (예: 0x11)가 생성된다.

 

5.5 SWC: 실제 데이터 생성

SWC는 실제 기능이 구현된 영역이다.

 

센서 값을 읽거나, NvM 데이터를 가져오거나, 내부 상태를 계산하는 작업은 모두 이 영역에서 수행된다.

즉, 테스터가 요청한 DID의 값은 결국 SWC에서 만들어진다.

 

이 구조를 이해하면, “DCM까지는 정상인데 값이 이상하다”는 상황에서

SWC나 RTE를 확인해야 한다는 판단이 가능해진다.

 

5.6 응답 생성 및 전송

SWC에서 생성된 데이터는 다시 RTE를 통해 DSP로 전달되고,

DSD와 DSL을 거쳐 PduR로 내려간 후 CAN을 통해 테스터로 전송된다.

SWC → RTE → DSP → DSD → DSL → PduR → CAN → Tester

 

이 과정은 요청 흐름의 정확한 역방향이다.

 

정리

 

결국 DCM을 이해한다는 것은 특정 설정을 아는 것이 아니라,

요청이 ECU 내부에서 어떤 경로로 이동하고

어느 단계에서 처리되는지를 흐름으로 이해하는 것이다.

 

이 흐름을 기준으로 보면, 문제가 발생했을 때 단순히 설정을 다시 보는 것이 아니라

어느 단계에서 요청이 끊겼는지를 기준으로 원인을 빠르게 좁힐 수 있다.

 

DSL은 요청 처리 가능 여부를 판단하고,

DSD는 요청을 해석하여 분기하며,

DSP는 실제 처리를 수행하고,

최종 데이터는 SWC에서 생성된다.

 

그리고 이 모든 과정은 PduR → DCM → RTE → SWC라는 전체 흐름 위에서 동작한다.