캔통신 - UDS란? 데이터 포맷 (Unified Diagnostic Services, CAN BUS Communication, Format)

 

목차

 

"관련제품 문의는 로고 클릭 또는 공지사항의 연락처를 통해 하실 수 있습니다."

 

 

 

UDS란? (Unified Diagnostic Services)

 

UDS, 즉 '통합 진단 서비스(Unified Diagnostic Services)'는 모든 1차 자동차 제조업체(Tier-1 OEMs)에서 사용해야 하는 프로토콜 시스템입니다. UDS는 자동차의 전자 제어 장치(ECU)에서 진단을 가능하게 하며, 이를 통일된 방식으로 수행합니다. 이 서비스에는 진단, 펌웨어 업데이트, 정기 테스트 등 다양한 기능이 포함되어 있습니다.

 

UDS는 자동차 시스템의 문제를 진단하고 해결하기 위한 표준화된 방법을 제공합니다. 예를 들어, 차량에 문제가 발생했을 때, UDS를 통해 해당 문제의 원인을 파악하고, 필요한 경우 소프트웨어 업데이트나 조정을 원격으로 진행할 수 있습니다. 이러한 기능은 차량의 안전성과 효율성을 높이는 데 중요한 역할을 합니다. 또한, 정기적인 자가 진단 루틴을 통해 차량의 상태를 지속적으로 모니터링하고, 잠재적인 문제를 조기에 발견할 수 있도록 도와줍니다.

 

간단히 말해서, UDS는 자동차의 '건강 검진' 시스템과 같은 역할을 하며, 차량의 여러 시스템이 제대로 작동하고 있는지를 확인하고 관리합니다. 이를 통해 차량 소유자와 제조업체 모두에게 유익한 결과를 가져다줍니다.

 

 

 

 

UDS 프로토콜 등장 배경

 

매일 새로운 회사들이 등장하고 있으며, 이들 각각은 차량과 전자 제어 장치(ECU)용 소프트웨어에 대해 서로 다른 아키텍처를 사용합니다. 또한, 단일 제조업체만을 봐도, 그들이 사용하는 모든 ECU를 직접 제조하는 것은 아닙니다. 대부분의 ECU는 다른 제조업체들로부터 조달됩니다. 이러한 상황에서 각각의 ECU에 대한 진단을 동시에 수행하는 것은 복잡하거나 사실상 불가능할 수 있습니다.

 

이러한 상황에서 모든 ECU가 다양한 제조업체에서 온 것이라 할지라도 반응할 수 있는 통합된 진단 표준의 필요성이 대두되었습니다. 그러다 ISO-14229 표준이 도입되었는데, 이 표준은 모든 제조업체와 다른 통신 프로토콜들(예: CAN, KWP 2000, Ethernet, LIN 등)에 대한 진단을 표준화했습니다. UDS는 오프보드(Off-board)와 온보드(Onboard) 진단 모두에 사용되는 일반적으로 정의된 프로토콜입니다. UDS는 OSI 모델의 응용 계층에 존재하며, 다음과 같은 부분들이 명시되어 있습니다:

 

 

 

 

 

• ISO 14229-1은 '명세 및 요구 사항'을 명시합니다.
• ISO 14229-3은 'CAN 상의 UDS'를 명시합니다.
• ISO 14229-4은 'FlexRay 상의 UDS'를 명시합니다.
• ISO 14229-5은 'IP 상의 UDS'를 명시합니다.
• ISO 14229-6은 'K-Line 상의 UDS'를 명시합니다.
• ISO 14229-7은 'LIN 상의 UDS'를 명시합니다.

 

간단히 말해, UDS와 ISO-14229 표준은 다양한 ECU 제조업체 간의 호환성을 높이고, 차량의 진단 및 유지보수를 효율적으로 만드는 데 중요한 역할을 합니다. 이를 통해 차량의 안정성과 성능을 보장하는 동시에, 제조업체와 소비자 모두에게 이점을 제공합니다.

 

 

 

 

 

UDS 동작 방식

 

 

 

UDS(통합 진단 서비스)는 기본적인 클라이언트(Client)-서버(Server) topology서 작동합니다. 여기서 '테스터'는 서비스를 요청하는 ' Client' 역할을 하며, ECU(전자 제어 장치)는 테스터의 요청에 응답하거나 서비스를 제공하는 ' Server' 역할을 합니다.

 

클라이언트/테스터:

• 클라이언트/테스터는 진단 기능 및 데이터베이스 관리, 특정 해석, 인간-기계 인터페이스와 같은 기능을 사용합니다.
• 차량의 ECU에 대한 검사, 모니터링, 테스트 또는 진단을 제어하는 시스템으로, 특정 유형의 작업자에게 전용될 수 있습니다.
  • 예: 차고 정비사를 위한 오프보드 스캔 도구, 조립 공장을 위한 On board(OBD) 테스터 도구 등.

서버:

• 서버는 ECU의 일부로서 진단 서비스를 제공합니다.
• ECU는 최소한 하나의 서버를 포함합니다.
• UDS는 서버와 ECU를 구별하여 표준이 구현으로부터 독립적이도록 합니다.
• 서버에는 ABS(안티록 브레이킹 시스템) 및 엔진 관리 시스템 등이 포함됩니다.

차량의 모든 서버 또는 ECU는 UDS 프로토콜에 따라 테스터 도구와 통신할 수 있어야 합니다. 테스터는 서비스 요청의 형태로 ECU에서 다양한 작업을 트리거할 수 있습니다. 예를 들어,

 

- Initiate diagnostics session.

- Read or clear the diagnostics trouble code.

- Troubleshooting vehicle issues.

- Extracting parameter data values.

- Test safety-critical issues.

- Requesting for data.

- Writing some data.

- Running tests on components and getting back the results.

- Flashing a program.

- Clearing memory.

- Setting a schedule, etc.

 

 

UDS는 테스터가 클라이언트로 요청하고 ECU가 서버로 수행할 수 있는 다양한 진단 서비스를 정의합니다:

• 사용 가능한 서비스.
• 요청 메시지 형식.
• 응답 메시지 형식.
• 타이밍 매개변수는 어떻게 되어야 하는가?
• 테스터와 ECU, 노드 등에 의한 서비스 처리.

 

간단히 말해, UDS는 자동차 내의 다양한 ECU들이 효율적으로 서로 소통하고 문제를 진단하며 해결할 수 있도록 하는 중요한 통신 및 진단 표준입니다. 이 시스템은 차량의 안전성과 성능을 유지하는 데 필수적인 역할을 합니다.

 

 

 

 

 

UDS Service Request: Format

 

Request

 

1. SID (서비스 식별자):
   • 이것은 1바이트 길이의 16진수 코드로, 0x00부터 0x3E까지의 값을 가질 수 있습니다.
   • 서버(ECU)가 클라이언트/테스터가 요청한 서비스를 이해하는 데 사용됩니다.
   • SID는 필수 필드입니다. 서비스 식별 번호 없이는 ECU가 서비스 요청을 이해할 수 없습니다.
2. SubFn (서브 기능):
   • 이것은 서버에게 주어진 서비스에 대해 요청된 서브 기능이 무엇인지 알려줍니다.
   • 서브 기능도 1바이트 길이이며, 단일 서버에 속합니다. 예를 들어,
     • 01: 서비스 요청
     • 02: 서비스 시작
     • 03: 서비스 중지
     • 04: 결과 요청 등
   • 서브 기능 필드는 선택적 필드입니다. 일부 선택된 서비스에만 필요하며, 식별자에 의해 데이터를 읽거나 쓰는 서비스는 서브 기능이 필요 없습니다.
3. DID (데이터 식별자):
   • 클라이언트와 서버는 기본 형식으로 숫자만을 사용하여 통신합니다.
   • 테스터가 읽는 모든 데이터 요소에는 해당 데이터 요소의 데이터 식별자로 알려진 번호가 할당되어야 합니다.
   • UDS에서 DID는 2바이트 길이이며, 서버와 클라이언트 모두 다른 데이터 식별자를 사용하여 다른 요소를 식별합니다.
   • OBD(온보드 진단)에서는 DID가 전 세계적으로 표준화되어 있습니다.
   • UDS에서는 자동차 제조업체가 자체 DID를 정의하며, OEM의 테스터 도구만 이 DID를 읽을 수 있습니다.
   • 데이터 식별자 필드는 완전히 선택적입니다. DID가 전혀 필요하지 않은 서비스가 있거나, 단일 메시지에 하나 또는 여러 데이터 식별자가 있을 수 있습니다. 이들은 데이터 지향적(DID), 루틴 지향적/제어적(RID), MID, 또는 UID일 수 있습니다.
4. Data Req (데이터 요청 필드):
   • 이 필드는 특정 메시지의 데이터 식별자와 관련된 메타데이터를 포함합니다.
   • n바이트 길이이며, 서비스 요청에 따라 선택적이거나 필수일 수 있습니다.

 

 

 

 

Positive Response Message 

 

 

 

1. PR SID (Positive Response Service Identifier):
   • PR SID는 요청 메시지에서의 서비스 식별자와 동일하며, 길이는 1바이트입니다.
   • 이 값은 16진수 0x40에서 0x7E 사이의 범위를 가집니다.
   • PR SID의 값은 항상 SID에 0x40 (16진수)를 더함으로써 결정됩니다.
   • 예: 만약 SID가 0x1E라면, PR SID는 0x1E + 0x40이므로, 0x5E가 됩니다.
2. Sub Fn (Sub Function):
   • Sub Fn은 1바이트 길이이며, 선택 사항입니다.
3. DID (Data Identifier):
   • DID는 SR(서비스 응답) 메시지에서와 같으며, 1바이트 길이이고 선택 사항입니다.
4. Data Req (Data Request):
   • Data Req는 선택 사항이며, 서비스에 매우 특화되어 있습니다.

 

 

Negative Response Message

 

 

 

1. NR-SID (Negative Response Service Identifier): 이는 1바이트 크기로 사전에 정의된 값 '0x7E'를 갖습니다. 이 코드는 서버(보통 차량의 ECU)가 요청받은 서비스를 수행할 수 없을 때 보내는 '부정적인 응답'을 나타냅니다.
2. SID RQ (Service Identifier Request): 이 또한 1바이트 길이의 식별자로, 수행할 수 없는 서비스의 ID를 나타냅니다. 예를 들어, 차량의 ECU에 어떤 특정한 진단 서비스를 요청했을 때, 해당 서비스를 수행할 수 없는 경우 이 식별자가 사용됩니다.
3. NRC (Negative Response Code): 이 역시 1바이트 길이를 가지며, 요청된 서비스를 수행하지 않는 이유를 나타냅니다. UDS 프로토콜에서는 다양한 NRC가 사전에 정의되어 있으며, 이 코드를 통해 서버가 서비스 수행을 거부하는 구체적인 이유를 클라이언트(테스터)에게 알릴 수 있습니다.

 

 

 

팜테크에서는 Influx사의 CAN BUS 통신 관련 제품(UDS 포함) 및 교육을 제공하고 있습니다. 해당 제품에 관심이 있으시다면 아래 연락처 또는 홈페이지에 문의 남기시면 됩니다. :)