[DCM] DcmDsp > Did / Did Info / Data / Data Info 설정 방법 (실무)

AUTOSAR 진단 설정을 처음 접하면 가장 많이 보게 되는 메뉴가 바로 DcmDsp > Did / Did Info 이다.
그리고 많은 개발자가 처음에 이런 생각을 한다.

Did는 DID 번호 넣는 곳인가?
Did Info는 왜 따로 존재하는가?
둘 차이가 무엇인가?
Data는 또 왜 연결해야 하는가?
실제 프로젝트에서는 어떻게 설정하는가?

겉으로 보면 단순한 설정 메뉴처럼 보이지만,
실제로 DID(Data Identifier)는 UDS 서비스 0x22(ReadDataByIdentifier), 0x2E(WriteDataByIdentifier), 0x2F(InputOutputControlByIdentifier) 에서 사용하는 핵심 진단 데이터이다.

즉, ECU 내부 값을 읽고 / 쓰고 / 강제제어하기 위해 반드시 필요한 설정이다.

MOBILGEN Classic 기준으로 DID 설정은 아래 경로에서 진행한다.

이번 글에서는 단순 설명이 아니라,
실무에서 어떻게 이해하고 어떻게 설정하는지까지 한 번에 정리한다.

 

1. 먼저 DID가 무엇인가?

 

DID(Data Identifier)는 ECU 내부 데이터를 진단기로 읽거나 쓰기 위한 식별 번호다.

예를 들어 진단기에서 아래 요청을 보내면,

22 F1 87

 

의미는 다음과 같다.

22 = ReadDataByIdentifier (DID 읽기 요청)
F187 = 읽고 싶은 데이터 번호

ECU는 해당 DID에 연결된 값을 응답한다.

62 F1 87 ...

 

즉, DID는 단순 숫자가 아니라 외부에서 ECU 내부 데이터를 요청할 수 있게 만드는 주소 체계이다.

 

2. DcmDsp 메뉴 구조 이해하기

각 메뉴는 이름이 비슷해 보이지만 역할은 완전히 다르다.

메뉴 역할
- Data: 실제 데이터 구조 정의

- Data Info: Data 속성 정보

- Did: DID 번호 생성 및 연결

- Did Info: 접근 정책 및 권한 정의

쉽게 표현하면 아래와 같다.

 

Data = 실제 내용물

Data Info = 데이터 속성 설명서

Did = 데이터 번호표
Did Info = 접근 규칙

 

즉, DID 하나를 만들기 위해 여러 요소가 협업하는 구조다.

 

3. Data Info 설정

 

Data Info는 Data에 대한 부가 정보를 정의하는 메뉴이다.
실무에서는 크게 복잡하게 사용하지 않고, 대부분 템플릿처럼 정해진 항목을 재사용한다.

대표적으로 아래 두 가지가 가장 많이 사용된다.

NoScalingInformation_FixedData 고정 길이 데이터
NoScalingInformation_VariableData 가변 길이 데이터

왜 필요한가?

예를 들어 ECU 버전 문자열이 항상 8바이트라면 고정 길이 데이터이다.

V1.26.03

 

반면 어떤 문자열은 프로젝트마다 길이가 달라질 수 있다.
이 경우 가변 길이 데이터로 관리할 수 있다.

Data Scaling Info Size 는 뭐냐?

이 항목은 ReadScalingDataByIdentifier(0x24) 관련 설정이다.
센서 값의 단위, 배율, 변환 계수 등을 진단기로 전달할 때 사용되는 개념이다.

예를 들어:

온도값 = Raw 값 × 0.1
전압값 = Raw 값 / 100

하지만 실제 양산 프로젝트에서는 이 서비스를 거의 사용하지 않는 경우가 많고,
MOBILGEN 에서도 일반 DID 개발에서는 자주 쓰이지 않는다.

따라서 대부분 프로젝트에서는 기본값 유지 후 진행한다.

 

4. Data 설정

 

Data는 DID가 실제로 읽거나 쓰게 될 데이터를 정의하는 영역이다.
DID가 "번호"라면 Data는 "실제 값"이다.

 

주요 설정 항목
- Short Name: Data 이름이다. 프로젝트 내에서 식별 가능한 이름으로 작성한다.
이름만 보고도 무슨 데이터인지 알 수 있게 짓는 것이 좋다.
- Byte Size: Data 크기를 Byte 단위로 입력한다.

- Condition Check Read Fnc Used: ReadData 함수를 호출하기 전에 이 DID를 지금 읽어도 되는지 먼저 검사하는 함수 사용 여부이다. 즉, 데이터 읽기 전 사전 검증 단계이다.
- Type: 데이터 타입을 정의한다.

Type 설명

- UINT8: 1바이트 정수
- UINT16: 2바이트 정수
- UINT32: 4바이트 정수
- UINT8_N: 고정 길이 바이트 배열
- UINT8_DYN: 가변 길이 바이트 배열

- Use Port: DCM이 데이터를 어떤 방식으로 Application에서 가져올지 결정한다.

 

Use Port 선택 옵션 설명

- USE_BLOCK_ID: DID 데이터를 특정 Block ID(NvM Block 등)와 연결하여 사용하는 방식이다.
- USE_DATA_ASYNCH_CLIENT_SERVER: 비동기 Client-Server 방식이다.
  RTE를 통해 서버 함수를 호출하고 응답이 늦게 와도 된다.
- USE_DATA_ASYNCH_CLIENT_SERVER_ERROR: 위 비동기 Client-Server 방식 + NRC 에러 코드까지 세밀하게 제어 가능하다. USE_DATA_ASYNCH_FNC: RTE Port를 사용하지 않고 직접 비동기 함수 호출 방식이다.
- USE_DATA_ASYNCH_FNC_ERROR: 직접 비동기 함수 + NRC 제어 기능 포함
- USE_DATA_SENDER_RECEIVER: AUTOSAR Sender-Receiver Port 데이터를 읽는 방식이다.
  다른 SWC가 주기적으로 송신한 값을 받아서 DID 응답에 사용한다.
- USE_DATA_SENDER_RECEIVER_AS_SERVICE: Sender-Receiver 데이터를 Service처럼 접근하는 방식이다.
- USE_DATA_SYNCH_CLIENT_SERVER: 가장 많이 쓰는 옵션이다.
  RTE Client-Server 함수 호출 후 즉시 결과 반환.
- USE_DATA_SYNCH_FNC: RTE 없이 직접 함수 호출 방식이다. Client-Server Port 없이 C 함수로 바로 연결한다.
- USE_ECU_SIGNAL: Com Signal / ECU Signal 값을 직접 DID에 매핑하는 방식이다.
  즉, 통신 Signal 값을 그대로 DID 응답으로 사용한다.

 

- Info Ref: 앞서 생성한 Data Info를 연결한다.

 

5. Did Info 설정

 

Did Info는 해당 DID를 어떻게 접근할지 결정하는 정책 영역이다.
실무에서는 이 설정이 매우 중요하다.

왜냐하면 DID 데이터는 존재해도 접근 권한이 없으면 읽을 수 없기 때문이다.

DID에서 허용할 기능(Did_Read, Did_Control, Did_Write)을 선택한다.

 

예시 1. ECU 정보 DID
Read = Enable
Write = Disable
Control = Disable

부품번호, 버전, VIN 등은 보통 읽기만 허용한다.

예시 2. 생산라인 설정 DID
Read = Enable
Write = Enable

공장 생산 시 값을 읽고 써야 하는 경우 사용한다.

 

6. Did 설정

 

여기서 실제 DID 번호를 생성하여 DID를 설정한다.

 

주요 설정 항목
- Short Name: DID 이름이다. 프로젝트 내에서 식별 가능한 이름으로 작성한다.

- Identifier: 실제 DID 번호이다.
- Used: 사용 여부이다. true 로 설정해야 Generate 대상이 된다.

- Use Port: Signal 값을 어떤 인터페이스로 가져올지 결정하는 설정이다.

Usd Port 선택 옵션 설명

- USE_ATOMIC_NV_DATA_INTERFACE: NvM(비휘발성 메모리) 데이터 값을 DID로 읽을 때 사용
예: 차량 옵션 값, 공장 설정값
- USE_ATOMIC_SENDER_RECEIVER_INTERFACE: Sender-Receiver Port의 단일 값(Atomic Data)을 읽을 때 사용. 다른 SWC가 보내는 현재 값을 DID 응답으로 사용.
예: 배터리 전압, 센서 상태, 모터 상태
- USE_ATOMIC_SENDER_RECEIVER_INTERFACE_AS_SERVICE: Sender-Receiver 데이터를 Service 형태로 접근하는 방식. Generator 구조에 따라 사용됨. 실무에서는 일반 SR 방식보다 사용 빈도 낮음.
- USE_DATA_ELEMENT_SPECIFIC_INTERFACES: 각 Data Element마다 개별 인터페이스를 생성해서 사용하는 방식. 신호마다 별도 Read/Write 연결 가능.
예: DID 안에 여러 데이터가 있고 각각 다른 소스에서 가져올 때

 

- Info Ref: 앞서 생성한 Did Info를 연결하는 부분이다. 이 항목이 빠지면 DID는 존재해도 응답 데이터가 없다.

 

DID 설정에서 Signal 을 추가하면,

해당 DID 응답 데이터 안에서 어느 위치에 어떤 데이터를 넣을지 정의하는 항목이 나온다.

 

즉, DID 하나에 여러 데이터를 조합해서 응답할 때 사용하는 설정이다.

 

주요 항목 설정

- Short Name: 굳이 수정할 필요 없이 그냥 설정값으로 두어도 된다.

- Byte Offset: 응답 데이터에서 몇 번째 Byte 위치부터 이 Signal 데이터를 배치할지 지정하는 값이다.
- Data Ref: 이 Signal이 참조할 실제 Data 항목을 연결한다.

 

7. 하모나이즈 수행 후 Generate

 

모든 설정이 완료되면 먼저 Harmonize를 수행하여 설정 간 연결 상태를 정리한다.

이후 Generate를 수행한다.

 

Generated 를 수행하면 Error 가 발생할 것이다.

왜 Error 가 발생했는지? 어떻게 해결하면 되는지는 이전 블로그에 설명을 했기에.. 따로 기술하진 않겠다.

(이전 블로그 글 참고: https://jjongday.tistory.com/107)

 

정리

 

DcmDsp > Did / DidInfo 설정은 단순 메뉴 입력 작업이 아니다.
ECU 내부 데이터를 외부 진단 시스템과 안전하게 연결하는 핵심 설계 작업이다.

반드시 아래 흐름으로 이해해야 한다.

 

1. Data Info 생성
2. Data 정의
3. Did Info 정책 설정
4. Did 번호 생성
5. Signal 연결
6. Generate
7. Application 구현
8. CANoe 검증

 

Did는 진단 식별 번호, Data는 실제 데이터, DidInfo는 접근 정책이다.

이 세 가지를 정확히 설계해야 실무 DID가 완성된다.