'2025/02/16'에 해당되는 글 6건

목표

• 모니터 Configuration을 작성해서 전송 Configuration이 어떤 신호를 보내왔는지 확인하기.
• 진단통신을 전송할 프로그램을 이 Configuration으로 설정

• Transmit 부분을 담당하는 메인 Configuration

제작

1. 새 프로젝트 제작

2. Channel Mapping의 VCI를 VN1610 Channel을 1로 설정

3. 준비 완료

목표

• 모니터 Configuration을 작성해서 전송 Configuration이 어떤 신호를 보내왔는지 확인하기.
• 진단통신에서 ACK를 보내줄 프로그램을 이 모니터 Configuration으로 설정

• Receive부분을 담당(우선은 Monitor, 다음으로 Simulator로 진화 예정) 

제작

1. 새 Configuration 제작

2. Channel Mapping의 VCI를 VN1610 Channel을 2로 설정

3. Start로 시작 후에 신호 받아보기

UDS에서의 Extended CAN ID (29-bit) 형식

UDS(ISO 14229)는 CAN(Controller Area Network)에서 실행되며, CAN의 Extended ID (29-bit Identifier) 형식을 사용할 수 있다. Extended CAN ID는 Standard CAN ID (11-bit)보다 더 많은 주소 공간을 제공하며, 네트워크에서 더욱 정교한 메시지 라우팅을 가능하게 한다.

1. CAN 프레임 구조

CAN Extended ID를 사용하면 29비트의 식별자를 통해 메시지를 송수신할 수 있다. UDS에서 Extended CAN ID는 일반적으로 다음과 같은 형식으로 구성된다.

1.1 Extended CAN ID (29-bit) 구조

Extended ID는 4개의 주요 필드로 구성된다.

비트 범위필드 명칭설명

💡 예제: 0x18DA10F1 (진단기 → ECU 10번 요청 메시지)

• 0x18 → 우선순위 (0b000)
• 0xDA → Protocol Format (PF) (진단 통신 전용 값)
• 0x10 → Protocol Specific (PS) (ECU 10번 대상)
• 0xF1 → Source Address (SA) (진단기 주소)

2. Extended CAN ID의 실제 사용

2.1 진단 요청 (Request)

진단기가 특정 ECU로 UDS 요청을 보낼 때, 다음과 같은 Extended CAN ID를 사용한다.

목적CAN ID 예제 (29-bit)설명

2.2 진단 응답 (Response)

ECU가 진단기의 요청에 응답할 때는 다음과 같은 Extended CAN ID를 사용한다.

응답 ECUCAN ID 예제 (29-bit)설명

즉, 요청(Request) 시에는 0x18DAXXF1 형식이고, 응답(Response) 시에는 0x18DAF1XX 형식이 된다.

3. Extended ID를 활용한 UDS 통신 예제

3.1 Read Data By Identifier (0x22) 요청 및 응답

VIN (차량 식별 번호)을 읽는 UDS 요청을 예로 들어보자.

① 진단기 → ECU 10번에 요청 (VIN 요청)

CAN ID: 0x18DA10F1  (진단기 → ECU 10번)
Payload: 22 F1 90

• 0x22 → Read Data By Identifier 요청
• F1 90 → VIN을 요청

② ECU 10번 → 진단기에 응답

CAN ID: 0x18DAF110  (ECU 10번 → 진단기)
Payload: 62 F1 90 57 4D 5A 42 59 58 32 35 36 38 36

• 0x62 → Read Data By Identifier 응답
• F1 90 → 요청한 데이터 ID
• 57 4D 5A ... → VIN 데이터

3.2 Security Access (0x27) 요청 및 응답

보안 인증을 수행하는 과정을 Extended ID로 설명한다.

① Security Access Seed 요청

CAN ID: 0x18DA10F1  (진단기 → ECU 10번)
Payload: 27 01

• 0x27 01 → Seed 요청 (Level 1)

② ECU 10번 → Seed 응답

CAN ID: 0x18DAF110  (ECU 10번 → 진단기)
Payload: 67 01 AB CD EF 12

• 0x67 01 → Seed 응답
• AB CD EF 12 → Seed 값

③ Security Key 전송

CAN ID: 0x18DA10F1  (진단기 → ECU 10번)
Payload: 27 02 56 78 9A BC

• 0x27 02 → Key 전송
• 56 78 9A BC → 계산된 Key 값

④ ECU 10번 → 인증 성공 응답

CAN ID: 0x18DAF110  (ECU 10번 → 진단기)
Payload: 67 02

• 0x67 02 → 인증 성공

4. Extended ID vs. Standard ID 비교

항목Standard ID (11-bit)Extended ID (29-bit)

💡 Standard ID는 간단한 OBD-II 진단에 적합하지만, Extended ID는 다중 ECU 환경에서 강력한 라우팅 기능을 제공한다.

5. 결론

📌 Extended CAN ID의 핵심 포인트

✅ UDS에서 Extended CAN ID (29-bit 형식)는 보다 정밀한 ECU 통신을 가능하게 한다.

✅ 요청(Request): 0x18DAXXF1 (진단기 → ECU XX번)

✅ 응답(Response): 0x18DAF1XX (ECU XX번 → 진단기)

✅ Standard ID보다 많은 주소 공간을 제공하여 다중 ECU 네트워크에 적합하다.

✅ ISO-TP(ISO 15765-2)와 결합하여 대용량 데이터 전송을 지원한다.

🚗 Extended CAN ID를 활용하면 더욱 정교하고 강력한 UDS 진단 기능을 구현할 수 있다! 🔥

UDS (Unified Diagnostic Services) 상세 설명

UDS(ISO 14229)는 차량 및 산업용 ECU의 진단을 수행하는 표준 프로토콜로, CAN(ISO 15765-4)에서 실행되며 다양한 진단 서비스(SID)를 제공한다.

1. UDS 메시지 구조

UDS는 CAN ID, ISO-TP(ISO 15765-2) 데이터 프레임, 그리고 진단 서비스 데이터로 구성된다.

1.1 CAN ID 구조

UDS에서 사용하는 CAN ID는 Normal (Standard ID)과 Extended (Extended ID) 형식이 있다.

(1) Standard CAN ID (11-bit)

• 송신 ID (Request, 진단기 → ECU) : 0x7DF
  • 모든 ECU를 대상으로 브로드캐스트 요청을 보냄
• 응답 ID (Response, ECU → 진단기)
  • ECU 1: 0x7E8
  • ECU 2: 0x7E9
  • ECU 3: 0x7EA
  • 여러 ECU가 응답할 수 있음

(2) Extended CAN ID (29-bit)

• 송신 ID (Request, 진단기 → ECU) : 0x18DAF1XX
  • XX: ECU의 주소 (예: 0x18DAF110 → ECU ID 10에 요청)
• 응답 ID (Response, ECU → 진단기) : 0x18DAXXF1
  • XX: ECU의 주소 (예: 0x18DA10F1 → ECU ID 10에서 응답)

2. UDS 서비스 구조

UDS는 요청(Request)과 응답(Response) 메시지를 Service ID (SID) 기반으로 구성한다.

서비스 명칭요청 SID응답 SID설명

3. UDS 데이터 패킷 구조

UDS는 ISO-TP (ISO 15765-2)를 사용하여 8바이트 이상의 데이터를 전송한다.

3.1 ISO-TP 프레임 구조

프레임 타입PCI 값첫 번째 바이트내용

4. UDS 요청 및 응답 예제

4.1 진단 세션 변경 (0x10)

진단기가 ECU의 특정 기능을 활성화하려면 Diagnostic Session Control (0x10) 명령을 사용한다.

예제: 프로그래밍 세션으로 전환

요청: 10 03
응답: 50 03

• 10 03 → 0x03 (Programming Session)
• 50 03 → 응답 성공

4.2 ECU 리셋 (0x11)

ECU를 리셋하는 명령이다.

예제: ECU 하드 리셋

요청: 11 01
응답: 51 01

• 11 01 → Hard Reset 요청
• 51 01 → 응답 성공

4.3 보안 인증 (Seed/Key) (0x27)

일부 기능(예: ECU Flashing)은 보안 인증이 필요하다.

예제: Security Access

1. Seed 요청
2. 요청: 27 01 응답: 67 01 XX XX XX XX (Seed 값 반환)
3. Key 전송
4. 요청: 27 02 YY YY YY YY (Seed 기반 Key 전송) 응답: 67 02 (보안 해제 성공)

4.4 데이터 읽기 (0x22)

ECU의 특정 데이터(예: VIN)를 읽는 명령이다.

예제: VIN 읽기

요청: 22 F1 90
응답: 62 F1 90 57 4D 5A 42 59 58 32 35 36 38 36

• 22 F1 90 → VIN 요청
• 62 F1 90 ... → 57 4D 5A... (VIN 데이터 반환)

4.5 DTC (Diagnostic Trouble Code) 조회 (0x19)

ECU가 저장한 오류 코드를 조회한다.

예제: 현재 오류 코드 요청

요청: 19 02
응답: 59 02 02 07 E8 03 01 0F

• 19 02 → 현재 저장된 DTC 요청
• 59 02 → 응답
• 07E8, 0301, 0F → 오류 코드 목록

4.6 ECU 소프트웨어 업데이트 (Flashing)

1. Programming Session 시작
2. 요청: 10 03 응답: 50 03
3. 보안 해제
4. 요청: 27 01 응답: 67 01 XX XX XX XX 요청: 27 02 YY YY YY YY 응답: 67 02
5. Flash 다운로드 요청
6. 요청: 34 00 00 10 00 응답: 74 20
7. 데이터 전송
8. 요청: 36 00 AA BB CC ... 응답: 76 00
9. 전송 종료
10. 요청: 37 00 응답: 77 00

5. 결론

• UDS (ISO 14229)는 차량 ECU와 진단기 간의 정교한 진단 및 제어 프로토콜이다.
• CAN ID는 Standard (11-bit)와 Extended (29-bit) 형태로 사용된다.
• ISO-TP (ISO 15765-2)를 통해 멀티 프레임 데이터 송수신이 가능하다.
• 주요 기능:
  • Diagnostic Session Control (0x10)
  • Security Access (0x27)
  • DTC 조회 (0x19)
  • ECU Flashing (0x34, 0x36)

🚗✨ UDS는 차량 ECU와 깊이 상호작용하며, 정비 및 프로그래밍을 수행할 수 있는 강력한 프로토콜이다!

CAN의 진단통신 (CAN Diagnostic Communication)

CAN(Controller Area Network)은 차량 및 산업용 기계에서 널리 사용되는 통신 프로토콜로, 진단통신(Diagnostic Communication)은 차량 내부의 전자제어장치(ECU, Electronic Control Unit)와 정비 도구(진단기) 간의 데이터를 송수신하는 데 활용된다.

진단통신을 위해 주로 사용되는 프로토콜은 ISO 14229 (Unified Diagnostic Services, UDS), ISO 15765-4 (CAN을 통한 OBD-II 통신) 및 KWP2000 (ISO 14230) 등이 있다.

1. CAN 기반 진단통신 개요

1.1 진단통신의 목적

• 차량의 ECU 상태 모니터링
• 오류 코드(DTC, Diagnostic Trouble Codes) 확인 및 삭제
• ECU 설정 및 매개변수 변경 (Coding, Flashing)
• 실시간 데이터 스트리밍 (Live Data)
• ECU 소프트웨어 업데이트 (Reprogramming)

2. CAN 진단 프로토콜

2.1 OBD-II (ISO 15765-4)

• 차량의 배기가스 및 엔진 상태 모니터링을 위한 온보드 진단(On-Board Diagnostics) 표준
• OBD-II 스캐너가 CAN 네트워크에 연결되어 특정 PID(Parameter IDs)를 요청하여 엔진 및 배기가스 데이터를 수집

OBD-II 메시지 구조

• 요청(Request)
  • 예: 02 01 0C (엔진 RPM 요청)
• 응답(Response)
  • 예: 04 41 0C 0B B8 (RPM 데이터 반환, 0x0BB8 = 3000 RPM)

2.2 UDS (ISO 14229)

UDS (Unified Diagnostic Services)는 ECU의 플래싱, 설정 변경, 진단 기능을 수행하는 CAN 기반 프로토콜이다.

UDS 서비스 (Diagnostic Services)

UDS 프로토콜은 특정한 서비스 ID(SID)를 사용하며, 주요 서비스는 아래와 같다:

서비스SID (요청)응답 SID설명

UDS 통신 예제

1. ECU 소프트웨어 다운로드 세션 시작
2. 요청: 10 03 (Programming Session 시작) 응답: 50 03
3. 보안 잠금 해제
4. 요청: 27 01 (Security Access Step 1) 응답: 67 01 XX XX XX XX (Seed 값 반환) 요청: 27 02 YY YY YY YY (Seed 값으로 Key 계산 후 전송) 응답: 67 02 (보안 잠금 해제 성공)
5. ECU 소프트웨어 업데이트
6. 요청: 34 00 00 10 00 (Request Download) 응답: 74 20

2.3 KWP2000 (ISO 14230)

• OBD-II보다 확장된 진단 프로토콜로, CAN뿐만 아니라 K-Line에서도 사용 가능
• 0x22(데이터 읽기), 0x2E(데이터 쓰기), 0x31(루틴 실행) 등의 서비스 존재

3. CAN 진단 메시지 프레임

CAN 진단 메시지는 일반적으로 **ISO-TP (ISO 15765-2: Transport Protocol)**을 사용하여 데이터 길이를 확장한다.

3.1 ISO-TP (ISO 15765-2) 메시지 구조

ISO-TP는 8바이트 이상의 데이터를 CAN을 통해 송수신할 수 있도록 한다.

• Single Frame (SF) : 1~7 바이트 데이터 전송 (0x0X)
• First Frame (FF) : 8바이트 이상의 데이터 전송 시작 (0x1X)
• Consecutive Frame (CF) : 다중 프레임 전송 (0x2X)
• Flow Control Frame (FC) : 수신 상태 응답 (0x3X)

예제: 10바이트 데이터 전송

1. 송신 (ECU → 진단기)
2. 10 0A 22 F1 90 11 22 33 44 (First Frame, 전체 길이 10바이트) 21 55 66 77 88 99 AA BB CC (Consecutive Frame)
3. 수신 (진단기 → ECU)
4. 30 00 00 (Flow Control Frame, 계속 전송하라는 응답)

4. CAN 진단통신의 활용

4.1 DTC (Diagnostic Trouble Code)

DTC는 차량의 오류 코드로, UDS의 0x19 명령으로 조회 가능하다.

예제: DTC 조회

• 요청: 19 02 (현재 저장된 DTC 요청)
• 응답: 59 02 02 07 E8 03 01 0F (DTC 코드 07E8, 0301, 0F 반환)

4.2 ECU Flashing

ECU 소프트웨어를 업데이트하려면 UDS의 Request Download (0x34) 및 Transfer Data (0x36) 명령을 사용한다.

1. Programming Session 전환 (0x10 03)
2. 보안 해제 (0x27 01 → 0x27 02)
3. Request Download (0x34)
4. Transfer Data (0x36)
5. Request Transfer Exit (0x37)
6. ECU Reset (0x11 01)

5. 결론

CAN 기반 진단통신은 차량의 유지보수, 성능 모니터링, 그리고 ECU 업데이트를 위해 필수적인 기능이다. OBD-II는 주로 일반적인 차량 진단에, UDS는 정밀한 ECU 제어 및 소프트웨어 업데이트에, ISO-TP는 긴 데이터 전송을 지원하는 역할을 한다.

🚗✨ UDS 기반 CAN 진단통신을 활용하면 차량의 문제를 정확히 진단하고, 필요한 설정을 변경하거나 ECU 소프트웨어를 업데이트할 수 있다!

1. CloudFront 이동
2. Distributions 에서 해당 정적 호스팅 항목을 선택
3. Invalidations 선택
4. Create Invalidation 선택
5. Add object paths에 path입력
   • 전체 변경: /*
6. Create invalidation 후 완료를 기다린 후, 캐시가 지워진 브라우저에서 확인