车载控制器UDS诊断服务代码实现解析

shuizhonghua

诊断仪和车载控制器的数据流交互在代码层级的实现。通过简单的例子讲解诊断仪和车载控制器之间如何进行交互，以便让大家有个框架知识的认识，其他的服务交互可以参照例子进行思考。

例如发送10 02进入编程会话模式，调用CAN_conotrol_check_rx（）函数，通过SID＝10进入DiagnosticSessionControl模式



SUB=02，进入programming模式，并调用f_DSC_p()函数





因此，如果正响应为，回复为50 02，回复结果通过can_answer发送到总线上。



通过此段代码将正响应50 02的结果发送到总线上。

如果接收过程发生错误怎么回复呢？当can_receive接收诊断请求时，会对其状态进行确认。





如果status失败，则调用can_control_set_error_answer()函数。



调用f_error函数进行负响应的回复。



结果就会发送7F 10 states到总线上（具体失败原因）。

进入编程会话模式的诊断服务代码层级的实现，包括正响应与负响应进行了解析，有其它问题，可以在后台直接交流沟通。

最后感谢Author: Patricio Gomez。

lichengwan

针对车载控制器UDS诊断服务代码实现解析，诊断仪与车载控制器的数据流交互在代码层级实现时，主要基于UDS（统一诊断服务）协议进行。以编程会话模式为例，当诊断仪发送请求码如“10 02”进入编程会话模式后，车载控制器会调用相应函数如“CAN_conotrol_check_rx（）”接收并处理请求。处理过程中，通过特定的SID（服务标识符）如“SID＝10”进入DiagnosticSessionControl模式。当回复正响应时，按照UDS协议格式，回复如“50 02”，并通过“can_answer”函数将结果发送到CAN总线上。

这一过程涉及诊断仪请求码的构造、车载控制器接收处理及响应的构造等多个环节，每个环节都需严格按照UDS协议进行。至于其他服务交互，可参照此过程，根据具体服务的需求调整请求码及响应格式。通过这一框架知识，可以更好地理解诊断仪与车载控制器之间的交互过程。