안녕하세요, 신입사원 여러분! 오늘은 자동차 진단 프로토콜 중 하나인 UDS(Unified Diagnostic Services)에 대해 알아보도록 하겠습니다.

UDS는 ECU 진단을 수행하기 위한 애플리케이션 계층 프로토콜입니다. ISO/OSI 모델에서 UDS와 OBD의 위치를 보면, UDS는 애플리케이션 계층에 속하고, 전송에는 여러 가지 물리 계층 표준(예: High-Speed-CAN, Fault-Tolerant-CAN 등)을 사용할 수 있습니다.

진단 메시지는 공통적인 구조를 가지고 있어요. 각 서비스는 요청 메시지, 긍정 응답 메시지, 부정 응답 메시지를 정의합니다. 긍정 응답 메시지는 보통 요청 서비스 ID에 6번 비트를 설정한 값을 첫 바이트로 가지며, 그 다음에 서비스에서 정의한 응답 매개변수가 옵니다. 부정 응답 메시지는 보통 3바이트로, 부정 응답 서비스 ID(0x7F), 원래 서비스 ID, 응답 코드로 구성됩니다.

UDS에는 하위 기능 바이트(Sub-Function Byte)라는 개념이 있습니다. 이 바이트의 7번 비트는 SuppressPosRspMsgIndicationBit로, ECU의 긍정 응답 필요 여부를 정의합니다. 0~6번 비트는 진단 서비스의 하위 기능 매개변수 값을 포함합니다.

UDS에서는 주기적 메시지 유형으로 USDT(Unacknowledged Segmented Data Transfer)와 UUDT(Unacknowledged Un-segmented Data Transfer)가 있습니다. 응답은 서비스 식별자가 있는 Type 1과 없는 Type 2, 두 가지 형식이 있어요.

UDS에는 다양한 진단 서비스가 정의되어 있습니다. 예를 들어, 진단 및 통신 관리, 데이터 전송, 저장된 데이터 전송, 입출력 제어, 루틴의 원격 활성화, 업로드/다운로드 등이 있죠.

세션 처리도 중요한 부분입니다. 진단 세션은 ECU와 진단 도구 간의 통신을 보장하는데, 기본 진단 세션, 프로그래밍 세션, 확장 진단 세션, 안전 시스템 진단 세션 등 여러 유형이 있습니다. 전원 인가 후에는 ECU가 기본 진단 세션으로 전환되고, 진단 도구로부터 다른 요청을 받으면 다른 진단 세션으로 전환됩니다.

UDS 응답 처리에서는 하위 기능이 있는 모든 서비스가 “응답 억제 처리”를 지원하고, 데이터 읽기 서비스는 이 기능을 지원하지 않습니다. 또한 기능적 요청에 대해서는 SuppressPosRspMsgIndicationBit 값과 관계없이 특정 부정 응답이 항상 억제됩니다.

이벤트에 대한 응답(Response on Event)은 하나 또는 두 개의 설정 및 시작 요청에 대해 초기 응답이 주어지고, 그 후 추적된 이벤트 발생 횟수에 따라 0에서 n개의 이벤트 기반 응답이 뒤따릅니다.

단순/폴링 진단 서비스는 물리적 주소 지정의 경우 하나의 요청과 하나의 응답(최대)으로 구성되고, 기능적 주소 지정의 경우 응답 그룹으로 구성됩니다.

주기적 서비스 실행에서는 하나의 요청에 대해 초기 응답이 하나 따르고, 그 후 주기적으로 더 많은 응답이 따릅니다. 단순 진단 서비스의 “전송 모드” 매개변수를 사용하여 전송을 중지할 수 있어요.

오류 메모리 기능으로는 오류 메모리 지우기($14 Clear Diagnostic Information)와 하위 기능($19 Read DTC Information)이 있습니다.

마지막으로 UDS 플래시 프로그래밍 예시를 보면, 진단 테스터가 ReadDataByIdentifier를 사용하여 하드웨어 ID와 소프트웨어 ID를 읽고, DiagnosticSessionControl로 특수 진단 세션으로 전환합니다. 그 후 CommunicationControl로 오류 메모리와 다른 컨트롤러의 버스 통신을 끄고, 프로그래밍 세션으로 전환합니다. 이후 지문 정보를 전송하고, RoutineControl로 플래시 메모리를 삭제한 후, RequestDownload로 실제 프로그래밍을 시작합니다. TransferData로 데이터를 전송하고, TransferExit로 전송 완료를 알립니다. 그 후 RoutineControl로 프로그래밍 성공 여부를 확인하고, ECUReset으로 컨트롤러를 재부팅하여 정상 작동으로 돌아갑니다.

어떤가요? UDS가 조금은 이해가 되셨나요? 처음에는 낯설고 어려울 수 있지만, 차근차근 공부하다 보면 점점 익숙해질 거예요. 모두 파이팅!

UDS 플래시 프로그래밍 예시:

UDS 플래시 프로그래밍 예시

UDS 플래시 프로그래밍의 과정을 단계별로 살펴보면 다음과 같습니다.

1. 진단 테스터는 ReadDataByIdentifier를 사용하여 컨트롤러의 하드웨어 ID와 소프트웨어 ID를 읽습니다. 이를 통해 정확히 어떤 장치인지 확인할 수 있죠.
2. 그 다음, 진단 테스터는 컨트롤 유닛을 특수 진단 세션으로 전환시킵니다. 이는 실제 프로그램용 진단 세션이 아니라, 여러 고급 서비스를 사용할 수 있는 세션입니다. 이 작업은 DiagnosticSessionControl 서비스를 통해 이루어집니다. 이 고급 진단 세션에서는 진단 테스터가 컨트롤 유닛에 플래시 프로그래밍을 위한 전제 조건이 충족되었는지 묻습니다.
3. 그 후, 진단 테스터는 보통 CommunicationControl 서비스를 사용하여 다른 컨트롤러의 오류 메모리와 버스 통신을 끕니다. 이로써 고급 진단 세션의 목적은 달성되었습니다.
4. 이제 진단 테스터는 DiagnosticSessionControl 서비스를 사용하여 프로그래밍 세션으로 전환합니다. 이 시점에서는 최소한 SecurityAccess가 필요합니다.
5. 그 다음, 진단 테스터는 보통 컨트롤 유닛의 이른바 ‘지문’을 전송합니다. 이는 프로그래밍이 수행되었음을 나타내기 위해 ECU 메모리에 영구적으로 저장되는 정보입니다. 일반적으로 컨트롤러 메모리에 작업장 식별자가 기록되어, 추후에 누가 ECU를 재프로그래밍했는지 확인할 수 있습니다.
6. 플래시 메모리를 재프로그래밍하기 전에, 먼저 삭제해야 합니다. 이는 RoutineControl 서비스를 사용하여 ECU 메모리의 루틴을 호출함으로써 이루어집니다. 그 후, RequestDownload 서비스를 통해 실제 프로그래밍 작업이 시작됩니다. 이 서비스를 통해 컨트롤러는 메모리에 로드될 데이터와 예상되는 데이터 크기를 알 수 있습니다.
7. 이제 TransferData 서비스를 사용하여 실제 데이터 다운로드가 루프 형태로 시작됩니다. 저장 영역은 블록 단위로 전송됩니다. 끝으로 진단 테스터는 TransferExit를 통해 모든 데이터가 전송되었음을 컨트롤 장치에 알립니다. 전송된 데이터를 검사한 후, 실제 플래시 프로세스가 컨트롤 유닛에서 이루어집니다. 일반적으로 프로그래밍 작업에는 어느 정도 시간이 소요됩니다. 이 동안 컨트롤러는 테스터의 요청을 처리할 수 없습니다. 따라서 컨트롤 유닛은 보통 TransferExit 서비스에 대해 ResponsePending 오류 코드와 함께 부정 응답을 보냅니다. 프로그래밍이 완료되면 컨트롤러는 TransferExit에 대한 긍정 확인을 보냅니다.
8. 그 다음, 진단 테스터는 RoutineControl을 사용하여 프로그래밍이 성공했는지 확인합니다. 이를 위해 컨트롤 유닛의 메모리를 검사하는 루틴을 활성화합니다. 이후 RoutineControl을 추가로 호출하여 플래시 프로그래밍에 따라 소프트웨어나 해당 레코드를 프로그래밍해야 하는지 등을 검사합니다. 컨트롤러에서 다운로드 프로세스가 완료되면, 일반적으로 ECUReset을 통해 컨트롤러가 리셋됩니다. 컨트롤러는 재부팅하여 정상 작동 상태, 즉 기본 진단 세션으로 돌아갑니다.