안녕하세요,여러분! 오늘은 UDS(Unified Diagnostic Services)에서 사용되는 주요 진단 서비스에 대해 알아보겠습니다.

진단 서비스는 자동차 진단 과정에서 매우 중요한 역할을 합니다. 이를 통해 차량의 상태를 점검하고, 문제를 진단하며, ECU(Electronic Control Unit)와 통신할 수 있습니다.

가장 기본적인 서비스로는 Diagnostic Session Control (0x10)이 있습니다. 이 서비스는 진단 세션을 제어하고 변경하는 데 사용됩니다. ECU Reset (0x11)은 ECU를 리셋하는 데 사용되며, Security Access (0x27)는 보안 액세스 레벨을 제어하고 승인합니다.

차량과의 통신을 제어하는 서비스도 있습니다. Communication Control (0x28)은 통신 채널을 제어하고, Tester Present (0x3E)는 진단 장비가 여전히 연결되어 있음을 나타냅니다.

데이터를 읽고 쓰는 데 사용되는 서비스도 다양합니다. Read Data By Identifier (0x22)는 식별자로 데이터를 읽고, Write Data By Identifier (0x2E)는 식별자로 데이터를 씁니다. 메모리 액세스를 위해서는 Read Memory By Address (0x23)와 Write Memory By Address (0x3D)를 사용합니다.

진단 정보를 관리하는 서비스로는 Clear Diagnostic Information (0x14)과 Read DTC Information (0x19)이 있습니다. 이를 통해 DTC(Diagnostic Trouble Code)를 읽고 지울 수 있습니다.

그 외에도 입출력 제어, 루틴 제어, 데이터 전송 및 다운로드/업로드 등을 위한 다양한 서비스가 있습니다.

이러한 진단 서비스를 이해하고 활용하는 것은 자동차 진단 및 수리에 있어 필수적입니다. 각 서비스의 기능과 사용 방법을 숙지하고, 실제 업무에 적용할 수 있도록 노력해 주시기 바랍니다.

여러분의 업무에 도움이 되길 바라며, 궁금한 점이 있다면 언제든 물어보세요. 함께 성장해 나가는 우리가 되길 기대합니다. 감사합니다!

UDS(Unified Diagnostic Services)에서 사용되는 주요 진단 서비스는 다음과 같습니다:

1. Diagnostic Session Control (0x10): 진단 세션을 제어하고 변경합니다.
2. ECU Reset (0x11): ECU를 리셋하는 데 사용됩니다.
3. Security Access (0x27): 보안 액세스 레벨을 제어하고 승인합니다.
4. Communication Control (0x28): 통신 채널을 제어합니다.
5. Tester Present (0x3E): 진단 장비가 여전히 연결되어 있음을 나타냅니다.
6. Access Timing Parameters (0x83): 타이밍 매개변수에 액세스합니다.
7. Secured Data Transmission (0x84): 안전한 데이터 전송을 처리합니다.
8. Control DTC Setting (0x85): DTC(Diagnostic Trouble Code) 설정을 제어합니다.
9. Response On Event (0x86): 이벤트 발생 시 응답을 처리합니다.
10. Link Control (0x87): 통신 링크를 제어합니다.
11. Read Data By Identifier (0x22): 식별자로 데이터를 읽습니다.
12. Read Memory By Address (0x23): 주소로 메모리를 읽습니다.
13. Read Scaling Data By Identifier (0x24): 식별자로 스케일링 데이터를 읽습니다.
14. Read Data By Periodic Identifier (0x2A): 주기적 식별자로 데이터를 읽습니다.
15. Dynamically Define Data Identifier (0x2C): 동적으로 데이터 식별자를 정의합니다.
16. Write Data By Identifier (0x2E): 식별자로 데이터를 씁니다.
17. Write Memory By Address (0x3D): 주소로 메모리에 씁니다.
18. Clear Diagnostic Information (0x14): 진단 정보를 지웁니다.
19. Read DTC Information (0x19): DTC 정보를 읽습니다.
20. Input Output Control By Identifier (0x2F): 식별자로 입출력을 제어합니다.
21. Routine Control (0x31): 루틴을 제어합니다.
22. Request Download (0x34), Transfer Data (0x36), Request Transfer Exit (0x37): 데이터 전송 및 다운로드 프로세스를 처리합니다.
23. Request Upload (0x35): 데이터 업로드를 요청합니다.

이 외에도 다양한 진단 서비스가 있으며, 각 서비스는 특정 기능을 수행하는 데 사용됩니다. 서비스의 가용성과 구현은 제조사와 차량 모델에 따라 다를 수 있습니다.

Diagnostic Session Control

Diagnostic Session Control 서비스는 제어기, 즉 서버의 진단 세션을 다양하게 변경하고 활성화하는 데 사용됩니다. 제어기는 항상 하나의 진단 세션만 활성화되어야 해요. 전원이 인가되면 제어기는 항상 Default Session에서 시작하고, 다른 진단 세션이 시작되지 않는 한 전원이 인가되어 있는 동안 Default Session이 유지됩니다.

만약 진단기, 즉 클라이언트가 이미 활성화된 진단 세션을 다시 요청하면, 제어기는 Positive Response로 응답하고, 그림 4-1의 세션 변경에 따른 제어기 내부 동작 특성에 맞게 동작해야 합니다.

진단 세션 변경에 대해 좀 더 자세히 살펴보면,

1) 제어기가 defaultSession에 있고 진단기가 defaultSession을 요청하면, 제어기는 defaultSession을 다시 초기화해야 합니다. 이때 활성화된 진단 모드에서의 설정이나 제어는 리셋되지만, 비휘발성 메모리에 저장된 정보는 포함되지 않아요.

2) defaultSession에서 다른 session으로 변경될 때, 제어기는 defaultSession에서 ResponseOnEvent 서비스를 통해 설정된 이벤트만 Reset해야 합니다.

3) default session 이외의 session 간 진단 모드 변경 시, 제어기는 진단 세션을 (재)초기화하고, ResponseOnEvent 서비스로 설정된 이벤트를 Reset하며, Security 설정을 초기화해야 합니다. 하지만 Periodic Scheduler 설정은 세션 변경과 관계없이 계속 활성화 상태를 유지해야 해요. CommunicationControl과 ControlDTCSetting 서비스는 영향을 받지 않습니다.

4) default session 이외의 session에서 default session으로 변경할 때는, ResponseOnEvent 서비스로 설정된 이벤트와 Security 설정이 초기화되고, Periodic Scheduler 설정은 중지됩니다. CommunicationControl과 ControlDTCSetting 서비스는 리셋되어야 해요. 예를 들어, normal communication이 disable 상태였더라도 session 변경 후에는 re-enable 되어야 합니다. 활성화된 진단 모드에서의 설정이나 제어는 리셋되지만, 비휘발성 메모리에 저장된 정보는 포함되지 않습니다.

이렇게 Diagnostic Session Control 서비스를 통해 제어기의 진단 세션을 관리하고 변경할 수 있습니다. 세션 변경에 따른 제어기의 동작 특성을 잘 이해하고 있어야 효과적인 차량 진단이 가능하겠죠? 모두 힘내서 공부해 주세요!

진단 세션에 대해 좀 더 자세히 알아보겠습니다.

먼저 defaultSession에 대해 살펴볼게요. 이 진단 세션은 서버에서 기본 진단 세션을 활성화하며, 진단 애플리케이션 타임아웃 처리를 지원하지 않습니다. 예를 들어, 세션을 유지하기 위해 Tester Present 서비스가 필요하지 않아요. 만약 서버에서 defaultSession 이외의 다른 세션이 활성화되어 있다가 다시 defaultSession이 시작되면, 다음과 같은 규칙을 따라야 합니다.

• 서버는 DiagnosticSessionControl 긍정 응답 메시지를 보낸 후 현재 진단 세션을 중지하고, 새로 요청된 진단 세션을 시작해야 해요.
• 서버가 DiagnosticSessionControl 긍정 응답 메시지를 보냈다면, 진단 세션 동안 클라이언트가 서버의 잠금을 해제했을 경우 다시 잠가야 합니다.
• 서버가 DiagnosticSessionControl 요청 서비스 식별자와 함께 부정 응답 메시지를 보내면, 활성 세션이 계속 진행되어야 해요.

다음은 programmingSession입니다. 이 진단 세션은 서버의 메모리 프로그래밍을 지원하는 데 필요한 모든 진단 서비스를 활성화합니다. 만약 서버가 부트 소프트웨어에서 programmingSession을 실행하는 경우, 클라이언트가 시작한 ECUReset(11 hex) 서비스, sessionType이 defaultSession인 DiagnosticSessionControl(10 hex) 서비스, 또는 서버의 세션 레이어 타임아웃을 통해서만 programmingSession을 종료할 수 있어요.

서버가 부트 소프트웨어에서 실행 중일 때 sessionType이 defaultSession인 DiagnosticSessionControl(10 hex) 서비스를 받거나 세션 레이어 타임아웃이 발생하고, 두 경우 모두 유효한 애플리케이션 소프트웨어가 있다면 서버는 애플리케이션 소프트웨어를 다시 시작해야 합니다. 이 문서에서는 유효한 애플리케이션 소프트웨어를 다시 시작하는 방법에 대한 다양한 구현 방식을 지정하지 않아요. 예를 들어, 유효한 애플리케이션 소프트웨어는 부트 소프트웨어에서 직접 결정되거나, ECU 리셋을 수행할 때 ECU 시작 단계에서 결정될 수 있습니다.

extendedDiagnosticSession은 서버 메모리에서 “Idle Speed, CO Value” 등의 기능 조정을 지원하는 데 필요한 모든 진단 서비스를 활성화하는 데 사용될 수 있습니다. 또한 기능 조정과 특별히 연관되지 않은 진단 서비스를 활성화하는 데도 사용할 수 있어요.

마지막으로 safetySystemDiagnosticSession은 에어백 전개와 같은 안전 시스템 관련 기능을 지원하는 데 필요한 모든 진단 서비스를 활성화합니다.

이렇게 각 진단 세션은 특정 목적에 맞는 진단 서비스를 활성화하는 역할을 합니다. 차량 진단 시 필요에 따라 적절한 세션을 선택하고 활용하는 것이 중요해요. 여러분도 이 내용을 잘 이해하고 활용한다면 진단 업무를 훌륭하게 수행할 수 있을 거예요. 화이팅!