'Programming'에 해당되는 글 110건

목표

함수 정리 및 개인적인 시간이 있을 때 설명 읽어두기.

각 함수 설명

on preStart

• 측정 시작 전에 실행됨
• 변수 초기화, 메시지 출력, 파일 읽기 가능
• 하지만 시스템이 완전히 활성화되지 않았으므로 버스 메시지 전송 불가능

on start

• 측정이 실제로 시작될 때 실행됨
• 타이머 시작, 로깅 초기화, 버스로 메시지 전송 가능
• 이 시점에서는 모든 시스템 기능을 사용할 수 있음

on preStop

• 측정 중지 요청이 들어온 후 실행되며, 측정이 실제로 중지되기 전에 처리됨
• 마지막으로 정리해야 할 작업 수행 가능 (예: ECU 종료 메시지 전송, 로그 저장 등)
• DeferStop을 호출하면 측정 중지를 지연할 수 있음
  • 예: deferStop (5000);

on stopMeasurement

• 측정이 완전히 중지된 후 실행됨
• 환경 변수 등의 변경이 반영되지 않을 수도 있음
• 로그 정리 등 종료 후 수행할 작업을 처리해야 함

목표

• 전송 Configuration에 기본이 되는 실행 스크립트를 제작

제작

1. Simulation Setup에서 아래 선을 선택해서 오른쪽 클릭
※왜인지 저 선을 뭐라고 부르는 지 찾을 수가 없음.

2. Insert Network Node 선택

※원하면 아래와 같이 Node Configuration에서 이름 등을 수정

3. 아래의 연필 혹은 오른쪽 클릭해서 Edit을 누르고 새로운 스크립트를 해당 노드와 연결

4. 아래와 같이 VectorCAPL Browser가 나오면 준비 완료

목표

어떤 Window가 사라졌을 때 해당 Window를 띄우기.

방법

1. Home → Write 선택

1. Tester Present 서비스 개요

UDS(ISO 14229) 프로토콜에서 Tester Present(0x3E) 서비스는 ECU가 진단 세션을 유지하도록 하는 역할을 합니다. 진단 장치(테스터)가 특정 시간 동안 ECU에 진단 메시지를 보내지 않으면 ECU는 진단 세션을 자동으로 종료하고 기본 모드(default session)로 돌아가게 됩니다. 이를 방지하기 위해 주기적으로 Tester Present 메시지를 보내야 합니다.

2. Tester Present 서비스의 목적

• ECU가 특정 진단 세션을 유지하도록 함
• ECU가 세션 타임아웃을 하지 않도록 주기적으로 신호 전송
• ECU가 특정 모드(예: extended session 또는 programming session)에서 계속 동작할 수 있도록 보장

3. 메시지 구조

Tester Present 서비스는 단순한 메시지 구조를 가지고 있습니다.

Byte설명

서브 기능 (Subfunction)

• 0x00 (Zero Subfunction): 기본 Tester Present 메시지 (응답 필수)
• 0x80 (Suppress Positive Response Bit 설정됨): ECU에서 응답을 보내지 않도록 설정 (Silent mode)

예제 요청/응답

1. 기본 Tester Present 요청
   • 요청: 3E 00
   • 응답: 7E (Positive Response)
2. Suppress Positive Response 요청
   • 요청: 3E 80
   • 응답 없음 (ECU가 응답하지 않음)
3. Negative Response 예제
   • 요청: 3E 00
   • 응답: 7F 3E 12 (Subfunction Not Supported)
   • 응답: 7F 3E 78 (Response Pending, ECU가 처리 중)

4. Tester Present의 동작 방식

1. 진단 장치(Tester)는 특정 진단 세션(예: ExtendedDiagnosticSession, ProgrammingSession)을 시작함.
2. ECU는 특정 타임아웃(보통 5초~10초) 내에 새로운 진단 요청을 받지 않으면 기본 세션(default session)으로 돌아감.
3. 이를 방지하기 위해 진단 장치는 주기적으로(예: 2~3초마다) Tester Present 메시지를 전송.
4. ECU가 메시지를 받으면 타이머를 리셋하고 현재 세션을 유지.
5. 특정 상황에서는 ECU가 바쁜 경우 0x7F 3E 78 (Response Pending)으로 응답할 수도 있음.

5. 주요 고려 사항

• 진단 세션 유지: Extended 또는 Programming 세션에서는 주기적으로 3E 00을 보내야 세션이 종료되지 않음.
• Suppress Positive Response: 3E 80을 사용하면 ECU가 응답하지 않으므로 통신 트래픽을 줄일 수 있음.
• Response Pending: ECU가 바쁜 경우(예: Flashing 중) 0x7F 3E 78을 반환할 수 있음.
• 세션별 필요 여부: Default Diagnostic Session에서는 Tester Present가 필요하지 않음.

6. 실무 적용 예시

차량 ECU Flashing 시나리오

• ECU의 Flash Programming Mode(10 02 Programming Session)로 진입 후
• 3E 00 메시지를 일정 간격으로 보내면서 세션 유지
• Flashing 완료 후, 11 01 (ECU Reset)으로 리부팅

이처럼 Tester Present는 ECU와의 장기적인 진단 세션을 유지하는 핵심적인 역할을 합니다.

목표

• 모니터 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 소프트웨어를 업데이트할 수 있다!

프로젝트 목표: Sequence를 정의해서 그대로 보낼 수 있는 진단통신 전송 CANoe Configuration

개인적인 목표

• 그 때, 그 때마다 필요에 의해서 조잡하게 활용하고 있는 것을 제대로 정리해서 활용.
• 자동차에 대해서도 정리하며 지식 확립.
• 최대한 인간의 쓸데없는 업무를 줄이는 방법 고려.

PC 소프트웨어 구성

• CANoe Pro
• CAN통신을 수신 받은 후 ACK를 보내주는 프로그램
  • 메모: 이게 없으면 CANoe에서 에러가 표시됨
    • 무시하고 싶다면 CANoe에서 ACK를 끄거나 하는 처리가 필요.

PC 연결 주변장치 구성

• 메모: 이게 현재 사용중인 진단 툴 개발시의 ECU 시뮬레이션 주변장치 구성
  • 때때로 VN1610대신 다른 VN을 사용할 때도 있음
• VN1610
  • CANcable 2Y
  • CANcable 1
    • 메모: CANcable 0는 FD송수신에서 에러 발생함.