(资料图片仅供参考)
目前汽车嵌入式开发中，可以通过Bootloader升级应用程序（Application），而Bootloader多采用UDS协议（即14229）。虽然OEM都会告知供应商参考UDS，但是每家OEM的需求多少又有点不同。本文讨论Server响应时间对APP程序复位的影响，也聊一下APP跳转Boot的另一种方式。
1P2Server、P2*Server、P4Server时间参数理解在我们讨论正题之前，先明确：
APP在编程会话下（$10 02）需要25ms内响应；
在编程会话下P4Server = P2Server = 25ms；
如果P4Server = P2Server，Server不能响应NRC0x78。
：
在APP下，：
我们还可以让当前节点先回复响应，再执行复位动作。即APP程序先给Tester应答，即APP程序先回正响应$50 02或者除0x78以外的否定响应（因为P4Server = P2Server，不让回复NRC0x78），不用Boot回复响应，这样即可极大的缩短响应时间，在25ms内给Tester应答。
但是这个做法有没有不妥当的地方？有！上位机（Tester）一般来说是脚本做的，诊断指令自动发送，尤其ECU下线刷写（EOL）时，讲究时间成本和自动化，Tester收到响应就会立马执行下一条诊断指令。Tester在25ms内收到App程序的响应，Tester马上发送下一个诊断指令，比如：$31服务，检查诊断电压。可是这个时候APP还没有完成复位动作，程序还没有真正的进入Boot，Boot是没有办法升级APP程序的。所以，我们必须约定一个时间，即ECU复位时间，确保ECU确实完成一个完整的复位动作，进入Boot以后再发送下一个诊断指令，避免Tester发送过快导致的程序刷写失败。
一般来说，会在需求中硬性的约束ECU的复位时间（这个是性能要求，不能打折），比如1.5s，这样在设计上位机的时候，要求上位机收到$50 02响应，1.5s以后再发送下一个诊断请求即可避免刷写失败的问题。
