Giao thức UDS

    Với tốc độ phát triển của hệ thống nhúng trong lĩnh vực automative thì việc tracking và điều khiển các parameters là cần thiết. Do do, hệ thống chuẩn đoán được phát triển, clients có thể phát hiện lỗi trong phương tiện bằng cách kết nối công cụ chuẩn đoán (Diagnostic tester tool) đến ECUs (Electronic Control Units). Tuy nhiên, có rất nhiều nhà sản xuất trên thế giới như BMW, Ford, Suzuki, Toyota, Vinfast,.. có  architecture và software của riêng, nên không thể nào tạo một ngôn ngữ giao tiếp cho mỗi hãng xe cả. Vậy nên để các chiếc xe đó có thể giao tiếp với một testing tool chung, Unified Diagnostic Services (UDS) được sinh ra để giải quyết các vấn đề đó.

1. UDS là gì?

    UDS được sử dụng là một giao thức giao tiếp chuẩn đoán giữa các ECUs, cho phép tester có thể trigger đa dạng hoạt động cho ECU ví dụ như: Yêu cầu data, viết đọc data, hay chạy một test trên một bộ phận, clear memory,... Các trigger này được thực hiện trên form của dịch vụ request. Phía ECU cung cấp dịch vụ được coi như server, phía tester yêu cầu được coi như client. UDS là tập hợp các dịch vụ chuẩn đoán, chúng có thể được request bời client và thực hiện bởi ECU.

Vậy format của request và response như thế nào, các timing parameter là gì?.. Chúng được tuân theo chuẩn ISO-14229, hãy đọc chúng để nắm rõ chi tiết về UDS nhé :v

2. Request message

• Service Identifier (SID): Như đã đề cập, UDS là tạp hợp các dịch vụ chuẩn đoán. Và mỗi chuẩn đoán đó được gán cho một Service Identifier (ID) có độ dài 1 byte để xác định request đó yêu cầu service gì. Đây là trường bắt buộc của tất cả bản tin request trong UDS.
• SubFn: Có độ dài 1 byte, là trường optional có thể có hoặc không trong request message tùy thuộc vào service, cung cấp thông tin bổ sung cho service
• Data Identifier (DID): Đại diện cho một data nào đó ví dụ như (0x05B5: Total distance travelled; 0xF802: Vehicle Identifier Number). Đối với On Board Device (OBD), DID được chuẩn hóa đối toàn cầu, trong UDS nhà sản xuất xe định nghĩa DID của riêng họ và chỉ có test tool từ OEMs có thể đọc được. 

                      Note:

• Khi service là data oriented thì Identifier gọi là DID.
• Khi service là Routine Control thì Identifier gọi là RID, tương tự với UID, MID,.. Nhưng mục đích của Identifier là như nhau.
• Data Record: Được sử dụng trong một vài trường hợp ví dụ như service cần ghi data "Vehicle speed limit", Data record sẽ chứa giá trị tốc độ tối đa.

3. Response message

• Positive response

• Sau khi Ecu nhận được request, ECU check nếu tất cả mọi thứ đều đúng (Không có lỗi gì) sẽ gửi lại positive response cho client. 
• Có form như sau 
• SIDPR = SIDRQ + 0x40 (SIDRQ từ 0x00 đến 0x3E => SIDPR từ 0x40 đến 0x7E) 
• SubFn, DID giống như SubFn và DID của request message 
• Cuối cùng là Data Rec 

• Negative response 

• Sau khi Ecu nhận được request, ECU check nếu có bất cứ lý do gì dẫn đến không thể thực hiện service request sẽ gửi negative response cho client 
• Có form như sau: 
• NR_SID = 0x7F 
• Tiếp theo là SIDRQ 
• NRC: chỉ ra lý do không thực hiện được service request. UDS đã predefine sẵn các NRC có thể có 

0x10 - General Reject                      

0x11 - Service not supported           

0x12 - Sub Function not supported 

0x21 - Busy-repeat request             

More 

• Một vài lý do gây ra Negative response:
• Format của request message sai 
• Điều kiện làm việc không hợp lệ 
• Do điều kiện bảo mật ... 

4. Các service cơ bản.

    Tham khảo thêm tại Unified Diagnostic Services - Wikipedia