UDS 官方推荐刷写Firmware流程

背景:

FOTA(Firmware-Over-The-Air),指固件更新,如给一个车辆设备、ECU闪存下载一个完整的固件,或者修补现有的固件,更新闪存,是一次完整的镜像文件下载的过程。
FOTA过程,我大致分为两个阶段,刷写的设备如T-box或者主机通过移动网络获得固件包阶段,T-box或者主机把固件包传给被刷写的ECU阶段。
这里要叙述的是T-box或者主机或Tester把固件包传给被刷写的ECU阶段。
这篇文章来源于ISO 14229-1协议第15章节,原滋原味,我感觉只能大致参考,了解原味,全篇围绕着 “图31描述了非易失性服务器内存编程过程的概述” 这张图叙述,理解了图31,本地刷写框架结构就基本了解了。后面我再写篇实际使用的流程。

15 Non-volatile server memory programming process

非易失性服务器内存编程过程

15.1 General information

This clause defines a framework for the physically oriented download of one or multiple application software/data modules into non-volatile server memory. The defined non-volatile server memory programming sequence addresses:
这个子句定义了一个框架,用于将一个或多个应用软件/数据模块 通过物理地址下载到非易失性服务器内存中。定义的非易失性服务器内存编程序列地址:

a) vehicle manufacturer specific needs in performing certain steps during the programming process, while being compliant with the general service execution requirements as specified in this part of ISO 14229 and Part 2 (such as the sequential order of services and the session management),
车辆制造商具体需要在编程过程中执行某些步骤,同时符合ISO 14229和第2部分中规定的一般服务执行要求(如服务的顺序和会话管理),
b) to support networks with multiple nodes connected, which interact with each other, using normal communication messages,
为了支持连接多个节点的网络,这些节点使用正常的通信消息相互交互,
c) use of either a physically oriented vehicle approach (point-to-point communication — servers do not support functional diagnostic communication) or a functionally oriented vehicle approach (point-to-point and point-to-multiple communication — servers support functional diagnostic communication). A single vehicle shall only support one of the above mentioned vehicle approaches.
使用面向物理的车辆方法(点对点通信——服务器不支持功能性诊断通信)或面向功能的车辆方法(点对点和点对多通信——服务器支持功能性诊断通信)。一辆车辆只能支持上述车辆通道中的一种。

The programming sequence is divided into two programming phases. All steps are categorized based on the following types:
编程顺序分为两个编程阶段。所有步骤按以下类型进行分类:
⎯ Standardized steps: this type of step is mandatory. The client and the server shall behave as specified.
标准化的步骤:这种类型的步骤是强制性的。客户端和服务器应按照规定的行为进行操作。
⎯ Optional/recommended steps: this type of step is optional. These optional steps require the usage of a specific diagnostic service identifier (as described in the step) and contain recommendations on how an operation shall be performed. Where the specified functionality is used, then the client and the server shall behave as specified.
可选的/建议的步骤:此类型的步骤是可选的。这些可选的步骤需要使用特定的诊断服务标识符(如步骤中所述),并包含关于如何执行操作的建议。如果使用了指定的功能,则客户端和服务器应按照指定的行为进行操作。
⎯ Vehicle manufacturer specific steps: this type of step is optional. The usage and content (e.g., diagnostic service identifiers used) of these optional steps is left to the discretion of the vehicle manufacturer and shall be in accordance with ISO 14229-1 and ISO 14229-2.
车辆制造商的特定步骤:此类型的步骤是可选的。这些可选步骤的使用和内容(例如,所使用的诊断服务标识符)将由车辆制造商自行决定,并应符合ISO 14229-1和ISO 14229-2的要求。

The defined steps can either be:
所定义的步骤可以是:
⎯ functionally addressed to all nodes on the network (functionally oriented vehicle approach, servers support functional diagnostic communication), or
功能寻址是对网络上的所有节点进行寻址(面向功能的车辆方法,服务器支持功能诊断通信),或
⎯ physically addressed to each node on the network (physically oriented vehicle approach).
物理寻址是定向到网络上的每个节点(物理面向车辆方法)。

Each step of the two programming phases of the programming procedure will specify the allowed addressing method for that step. The vehicle manufacturer specific steps can either by functionally or physically addressed (depends on the OEM requirements).
编程过程的两个编程阶段的每一步都将指定该步骤所允许的寻址方法。汽车制造商的具体步骤可以通过功能或物理方式解决(取决于OEM要求)。
Figure 31 depicts the non-volatile server memory programming process overview.
图31描述了非易失性服务器内存编程过程的概述。
在这里插入图片描述

Figure 31 — Non-volatile server memory programming process overview
图31 -非易失性服务器内存编程过程概述

The programming process the client is required to follow consists of two distinct types of diagnostic service executions:
客户端需要遵循的编程过程由两种不同类型的诊断服务执行组成:
⎯ Master execute:
All steps that are required to be synchronized between multiple programming steps which run in parallel have to be coordinated as they are intended for vehicle wide functions (e.g., typically using functional addressing). This is achieved via the “master execute” of the client. The steps defined for the “Pre Programming Step” and the “Post-programming Step” of the individual programming phases are executed by the “master execute” of the client. The programming process requires synchronization between the individual “Programming steps” (e.g., the transition of the vehicle network into a mode of operation that allows for programming of individual ECUs, or at the point in time when the individual parallel “Programming steps” reach the point where a conclusion of a programming phase is required). The master execute has to maintain the vehicle in the mode of operation it has transitioned to.
必须在多个编程步骤之间同步所有步骤,这些步骤必须在多个编程步骤中进行协调,因为它们是针对车辆功能的(例如,通常使用功能地址)。 这是通过客户端的“主执行”来实现的。 为“预编程步骤”和单个编程阶段的“后编程步骤”定义的步骤由客户端的“主执行”执行。 编程过程需要在单个“编程步骤”之间进行同步(例如,车辆网络过渡到允许单个ECU编程的操作模式,或者在单个平行“编程步骤”到达的时间点上 需要一个编程阶段的结论)。 主执行必须以其过渡到的操作方式维护车辆。
⎯ Programming execute:
All steps that are not required to be synchronized between multiple “Programming steps” don’t need to be coordinated by the client and can run in parallel, therefore no “master execute” is required in the client during the execution of these steps. The “Programming steps” of the individual ECUs can be executed individually in parallel by the client until they are concluded and require the execution of the “Post programming phase”. All steps controlled by the “programming execute” are ECU oriented steps (e.g., physically addressed to the ECU to be programmed).
所有不需要在多个“编程步骤”之间同步的步骤都不需要由客户端协调,可以并行运行,因此在执行这些步骤期间客户端不需要“主执行”。单个ecu的“编程步骤”可以由客户单独并行执行,直到它们结束并需要执行“后编程阶段”。由“编程执行”控制的所有步骤都是面向ECU的步骤(例如,物理地址指向要编程的ECU)

a) Programming phase #1 — download of application software and/or application data
编程阶段1-下载应用程序软件和/或应用程序数据
1) Within programming phase #1, the application software/data is transferred to the server.
在编程阶段#1中,应用程序软件/数据被传输到服务器上。
i) Optional Pre-Programming step — Setup of vehicle network for programming
可选的预编程步骤-针对编程的车辆网络的设置
The pre-programming step of phase #1 is optional and used to prepare the vehicle network for a programming event of one or multiple servers. This step provides certain hooks where a vehicle manufacturer can insert specific operations that are required for the OEM vehicle’s network (perform wake-up, determine communication parameters, read server identification data, etc.).
阶段#1的预编程步骤是可选的,用于为一个或多个服务器的编程事件准备车辆网络。此步骤提供了某些钩子,车辆制造商可以插入OEM车辆网络所需的特定操作(执行唤醒、确定通信参数、读取服务器标识数据等)。

This step also contains provisions to increase the baud rate to improve download performance.
此步骤还包含了增加波特率以提高下载性能的规定。
The usage of this functionality is optional and can only be performed in case of a functionally oriented vehicle approach (functional diagnostic communication supported by the servers).
此功能的使用是可选的,并且只能在面向功能的车辆方法(由服务器支持的功能诊断通信)的情况下执行。
The request messages of this step can either be physically or functionally addressed.
此步骤的请求消息可以在物理上或功能上进行处理。

2) Server Programming step — Download of application software and application data
服务器编程步骤-下载应用软件和应用数据
The server programming step of phase #1 is used to program one or multiple servers (download of application software and/or application data and/or boot software).
阶段#1的服务器编程步骤用于编程一个或多个服务器(下载应用程序软件和/或应用程序数据和/或引导软件)。
Within this step, only physical addressing is used by the client, which allows for parallel or sequential programming of multiple nodes. In the case where the pre-programming step is not used, then the DiagnosticSessionControl (0x10) with subfunction programmingSession can also be performed using functional addressing.
在这个步骤中,客户端只使用物理寻址,这允许多个节点并行或顺序编程。在不使用预编程步骤的情况下,还可以使用功能寻址执行带有子函数programmingSession的DiagnosticSessionControl (0x10)。
At the end of this step, a physical reset of the re-programmed server(s) is optional. The use of the reset leads to the requirement to implement programming phase #2 in order to finally conclude the programming event by physically clearing DTCs in the re-programmed server(s), because after the physical reset during this step the re-programmed server(s) enable(s) the default session and perform(s) their normal mode of operation while the remaining server(s) have still disabled normal communication. The re-programmed server(s) will potentially set DTCs.
在此步骤结束时,对重新编程的服务器进行物理重置是可选的。复位的使用导致需要实现编程阶段#2,以便通过物理清除重新编程服务器中的dtc来最终结束编程事件,因为在此步骤中进行物理复位后,重新编程的服务器启用默认会话并执行其正常操作模式,而其余服务器仍然禁用正常通信。重新编程的服务器可能会设置dtc。

Furthermore, it shall be considered that the re-programmed server could activate a new set of diagnostic address, which differs from the ones used when performing a programming event (see 15.3).
此外,应该考虑重新编程的服务器可以激活一组新的诊断地址,这与执行编程事件时使用的诊断地址不同(见15.3)。
If either the server that was re-programmed does not change its communication parameters or the client knows the changed communication parameters, then following the reset certain configuration data can be written to the re-programmed server.
如果被重新编程的服务器没有更改其通信参数,或者客户端知道更改的通信参数,那么在重置之后,可以将某些配置数据写入重新编程的服务器。

3) Post-Programming step — Re-synchronization of vehicle network after programming
3)编程后步骤——编程后车辆网络的重新同步
The post-programming step of phase #1 concludes the programming phase #1. This step is performed when the programming step of each reprogrammed server is finished.
第一阶段的后编程步骤结束了第一阶段的编程。此步骤在每个重编程服务器的编程步骤完成时执行。
The request messages of this step can either be physically or functionally addressed.
此步骤的请求消息可以是物理寻址的,也可以是功能寻址的。
The vehicle network is transitioned to its normal mode of operation. This can either be done via a reset using the ECUReset (0x11) service or an explicit transition to the default session via the DiagnosticSessionControl (0x10) service.
车辆网络过渡到正常运行模式。这可以通过使用ECUReset (0x11)服务进行重置或通过DiagnosticSessionControl (0x10)服务显式转换到默认会话来完成。

b) Programming phase #2 — Server configuration (optional)
编程阶段#2 -服务器配置(可选)
1) Programming phase #2 is an optional phase in which the client can perform further actions that are needed to finally conclude a programming event (write the VIN, trigger Immobilizer learn-routine, etc.). For example, if the server(s) that has (have) been re-programmed is (are) physically reset during the server programming step of programming phase #1, then DTCs shall be cleared in this server(s).
编程阶段#2是一个可选阶段,客户端可以执行最终结束编程事件所需的进一步操作(写入VIN,触发Immobilizer学习例程等)。例如,如果在编程阶段#1的服务器编程步骤中,对已经重新编程的服务器进行了物理复位,则该服务器中的dtc应被清除。
2) When executing this phase, the downloaded application software/application data is running / activated in the server and the server provides its full diagnostic functionality.
在执行此阶段时,下载的应用程序软件/应用程序数据在服务器中运行/激活,服务器提供其完整的诊断功能。
⎯ Pre-Programming step — Setup of vehicle network for server configuration
预编程步骤-设置服务器配置的车辆网络
The pre-programming step of phase #2 is used to prepare the vehicle network for the programming step of phase #2. This step is an optional step and provides certain hooks where a vehicle manufacturer can insert specific operations that are required for OEM vehicle’s network (e.g. wake-up, determine communication parameters).
阶段2的预编程步骤用于为阶段2的编程步骤准备车辆网络。此步骤是可选步骤,并提供某些钩子,车辆制造商可以在其中插入OEM车辆网络所需的特定操作(例如唤醒,确定通信参数)。
The request messages of these steps can either be physically or functionally addressed.
这些步骤的请求消息可以是物理寻址的,也可以是功能寻址的。
⎯ Programming step — Final server configuration
编程步骤-最后的服务器配置
The programming step is used to, for example, write data (e.g. VIN), after the server reset.
例如,编程步骤用于在服务器复位后写入数据(例如VIN)。
The content of this step is vehicle manufacturer specific.
此步骤的内容是特定于汽车制造商的
If the server(s) that has (have) been re-programmed are physically reset at the end of the server programming step of programming phase #1, then DTCs shall be cleared in this server(s) during the programming step of phase #2.
如果在编程阶段#1的服务器编程步骤结束时,已经重新编程的服务器被物理重置,则在阶段#2的编程步骤中,该服务器中的dtc应被清除。
The request messages of these steps are physically addressed.
这些步骤的请求消息是物理寻址的。
⎯ Post-Programming step — Re-synchronization of vehicle network after final server configuration
编程后步骤-在最终服务器配置后重新同步车辆网络
The post-programming step concludes programming phase #2. This step is performed when the programming step of each reprogrammed server is finished. The vehicle network is transitioned to its normal mode of operation.
编程后步骤结束了编程阶段#2。此步骤在每个重编程服务器的编程步骤完成时执行。车辆网络过渡到正常运行模式。
This step can either be functionally oriented (servers support functional diagnostic communication) or physically oriented.
这个步骤可以是面向功能的(服务器支持功能性诊断通信),也可以是面向物理的。
The request messages of these steps can either be physically or functionally addressed.
这些步骤的请求消息可以是物理寻址的,也可以是功能寻址的。

15.2 Detailed programming sequence

详细的编程顺序

15.2.1 Programming phase #1

— Download of application software and/or application data
编程阶段#1 -下载应用软件和/或应用数据

15.2.1.1 Pre-Programming step of phase #1

— Setup of vehicle network for programming
阶段1的预编程步骤-设置车辆网络进行编程
Figure 32 graphically depicts the functionality embedded in the pre-programming step.
图32以图形方式描述了预编程步骤中嵌入的功能
在这里插入图片描述

Key
1
Prior to any communication on the data link the network shall be initialized (e.g. perform an initial wake-up on the network). The wake-up method and strategy is vehicle manufacturer specific and optional to be used.
在数据链路上的任何通信之前,网络应初始化(例如,在网络上执行初始唤醒)。唤醒方法和策略是汽车制造商特定的,可选择使用。
Furthermore, this step allows for a determination of the server communication parameters such as the network configuration parameter and server diagnostic address used by the server(s).
此外,该步骤允许确定服务器通信参数,例如服务器使用的网络配置参数和服务器诊断地址。
2
In order to be able to disable the normal communication between the servers and the setting of DTCs, it is required to start a non-defaultSession in each server where normal communication and DTCs shall be disabled.
为了能够禁用服务器之间的正常通信和dtc设置,需要在每个服务器上启动一个non-defaultSession,禁用正常通信和dtc。
This is achieved via a DiagnosticSessionControl (0x10) service with sessionType equal to extendedDiagnosticSession. The request is either transmitted functionally addressed to all servers with a single request message, or physically addressed to each server in a separate request message (requires a physically addressed TesterPresent (0x3E) request message to be transmitted to each server that is transitioned into a non defaultSession). It is vehicle manufacturer specific whether response messages are required or not.
这是通过sessionType等于extendedDiagnosticSession的DiagnosticSessionControl (0x10)服务实现的。请求要么通过单个请求消息向所有服务器发送功能寻址,要么通过单独的请求消息向每个服务器发送物理寻址(需要向每个服务器发送物理寻址的testpresent (0x3E)请求消息,并将其转换为非defaultSession)。是否需要响应消息取决于车辆制造商。
3
Following the transition into the extendedDiagnosticSession, further vehicle manufacturer specific data link initialization steps can optionally be performed.
在过渡到extendedDiagnosticSession之后,可以选择性地执行其他特定于汽车制造商的数据链路初始化步骤。
EXAMPLE A vehicle manufacturer specific additional initialization step can be to issue a request that causes gateway devices to perform a wake-up on all data links which are not accessible by the client directly through the diagnostic connector. The gateway will keep the data link(s) awake as long as the non defaultSession is kept active in the gateway.
汽车制造商特定的附加初始化步骤可以是发出一个请求,使网关设备对客户端不能直接通过诊断连接器访问的所有数据链路执行唤醒。只要网关中的非defaultSession保持活动状态,网关就会使数据链路保持清醒状态。
4
This optional routineIdentifier (number chosen by the vehicle manufacturer) allows a client to check whether all pre-conditions to transition to the programmingSession are fulfilled prior to attempting the transition.
这个可选的routineIdentifier(由车辆制造商选择的编号)允许客户端在尝试转换之前检查是否满足了转换到programmingSession的所有先决条件。
5
The client disables the setting of DTCs in each server using the ControlDTCSetting (0x85) service with DTCSettingType equal to “off”. The request is either transmitted functionally addressed to all servers with a single request message, or transmitted physically addressed to each server in a separate request message. It is vehicle manufacturer specific whether response messages are required or not.
客户端使用ControlDTCSetting (0x85)服务禁用每个服务器中的dtc设置,DTCSettingType等于“off”。请求要么通过单个请求消息向所有服务器发送功能地址,要么通过单独的请求消息向每个服务器发送物理地址。是否需要响应消息取决于车辆制造商。
6
This optional routineIdentifier (number chosen by the vehicle manufacturer) allows a client to enable or disable the failsafe reaction of an ECU if needed for safety reasons.
这个可选的routineIdentifier(由车辆制造商选择的编号)允许客户端在出于安全原因需要时启用或禁用ECU的故障安全反应。
7
The client disables the transmission and reception of non-diagnostic messages using the CommunicationControl (0x28) service. The controlType parameter and communicationType parameter values are vehicle manufacturer specific (one OEM might disable the transmission only while another OEM might disable the transmission and the reception based on vehicle manufacturer specific needs). The request is either transmitted functionally addressed to all servers with a single request message, or transmitted physically addressed to each server in a separate request message. It is vehicle manufacturer specific whether response messages are required or not.
客户端使用CommunicationControl(0x28)服务禁用非诊断消息的发送和接收。controlType参数和communicationType参数值是特定于车辆制造商的(一个OEM可能仅禁用变速器,而另一个OEM则可能根据车辆制造商的特定需求禁用变速器和接收)。该请求要么通过单个请求消息在功能上寻址到所有服务器,要么通过单独的请求消息在物理上寻址到每个服务器。是否需要响应消息取决于车辆制造商。
8
After disabling normal communication an optional vehicle manufacturer specific step follows, which allows the following.
在禁用正常通信后,可选的车辆制造商特定步骤如下。
⎯ Reading the status of the server(s) to be programmed (e.g. application software/data programmed).
读取要编程的服务器(例如应用软件/数据编程)的状态。
⎯ Reading server identification data from the server(s) to be programmed:
从要编程的服务器读取服务器识别数据;
⎯ identification (see dataIdentifier definitions): applicationSoftwareIdentification, applicationDataIdentification,
标识(见数据标识符定义):applicationSoftwareIdentification、applicationDataIdentification、
⎯ fingerprint (see dataIdentifier definitions): applicationSoftwareFingerprint, applicationDataFingerprint,
指纹(见数据标识符定义):applicationSoftwareFingerprint, applicationDataFingerprint,
⎯ Communication configuration such as dynamic assignment of address identifiers for a “Service ECU”.
-通信配置,如动态分配“服务ECU”的地址标识符。
⎯ Preparation of non-programmable servers for the upcoming programming event in order to allow them to optimize their data link hardware acceptance filtering in a way that they can handle a 100 % bus utilization without dropping data link frames (only accept the function request address identifier and its own physical request address identifier).
为即将到来的编程事件准备非可编程服务器,以便允许它们优化其数据链路硬件接受过滤,使它们能够在不丢弃数据链路帧的情况下处理100%的总线利用率(只接受功能请求地址标识符和它自己的物理请求地址标识符)。
9
It is optional to increase the bandwidth for the programming event in order to decrease the overall programming time and to gain additional bandwidth to be able to program multiple servers in parallel. A LinkControl (0x87) service with linkControl equal to either verifyBaudrateTransitionWithFixedMode or verifyBaudrateTransitionWithSpecificMode is transmitted functionally or physically addressed to all servers with a single request message with responseRequired equal to “yes”. This service is used to verify if a mode transition at the associated data link can be performed. At this point the transition is not performed. A second LinkControl (0x87) service with subfunction transitionMode is transmitted functionally addressed to all servers with a single request message with responseRequired equal to “no”.
增加编程事件的带宽以减少总体编程时间并获得额外带宽以能够并行编程多个服务器是可选的。链路控制等于verifyBaudrateTransitionWithFixedMode或verifyBaugrateTransitionwithSpecificMode的链路控制(0x87)服务在功能上或物理上发送到所有服务器,并带有一条responseRequired等于“yes”的请求消息。此服务用于验证是否可以在相关联的数据链路上执行模式转换。此时不执行转换。具有子功能转换模式的第二个LinkControl(0x87)服务在功能上发送给所有服务器,并带有一条responseRequired等于“no”的请求消息。
Once the request message is successfully transmitted, the client and all servers transition to the previously verified mode for the programming event. The servers have to transition the individual data link specific mode within a vehicle manufacturer specific timing window. For this duration plus a safety margin, the client is not allowed to transmit any request message onto the vehicle network (including the TesterPresent request message). When the transition is successfully performed, then the requested mode shall stay active for the duration the server switches between non-defaultSessions. Once the server transitions to the defaultSession, it shall re-enable the normal mode of the vehicle link it is connected to.
一旦请求消息被成功传输,客户端和所有服务器就转换到编程事件的先前验证的模式。服务器必须在车辆制造商特定的时间窗口内转换单个数据链路特定的模式。在此期间加上安全裕度,客户端不允许将任何请求消息传输到车辆网络上(包括TesterPresent请求消息)。成功执行转换后,请求的模式将在服务器在非默认会话之间切换的持续时间内保持活动状态。一旦服务器转换到defaultSession,它将重新启用与其连接的车辆链路的正常模式。
The usage of mode switches requires the support of functional diagnostic communication in each server on a single data link that shall be transitioned to the associated data link dependent mode.
模式开关的使用需要在单个数据链路上的每个服务器中支持功能诊断通信,该数据链路应转换为相关的数据链路相关模式。
Figure 32 — Pre-programming step of phase 1 (STP1)

15.2.1.2 Programming step of phase #1

— Download of application software and data
第一阶段的编程步骤-下载应用软件和数据
Following the pre-programming step, the programming of one or multiple servers is performed. The programming sequence applies for a programming event of a single server and is therefore physically oriented. When multiple servers are programmed, then multiple programming events either run in parallel or will be performed sequentially.
在预编程步骤之后,执行一个或多个服务器的编程。编程顺序适用于单个服务器的编程事件,因此是面向物理的。当对多个服务器进行编程时,多个编程事件要么并行运行,要么依次执行。
Figure 33 graphically depicts the functionality embedded in the programming step of phase #1.
图33以图形方式描述了阶段#1的编程步骤中嵌入的功能。
在这里插入图片描述

Key
1
The programming event is started in the server(s) via a physically/functionally addressed request of the DiagnosticSessionControl (0x10) service with sessionType equal to programmingSession. When the server(s) receive(s) the request, it/they shall allocate all necessary resources required for programming. It is implementation specific whether the server(s) start(s) executing out of boot software.
编程事件通过物理/功能寻址的DiagnosticSessionControl (0x10)服务请求在服务器中启动,sessionType等于programmingSession。当服务器接收到请求时,它/它们应分配编程所需的所有必要资源。服务器是否从启动软件开始执行是与实现相关的。
2
A programming event should be secured. The SecurityAccess (0x27) service shall be mandatory for emissions related and safety systems. Other systems are not required to implement this service. The method on how a security access is performed is specified in this part of ISO 14229.
编程事件应该是安全的。安全访问(0x27)服务对于排放相关和安全系统是强制性的。其他系统不需要实现此服务。关于如何执行安全访问的方法在ISO 14229的这一部分中指定。
3
It is vehicle manufacturer specific to write a “fingerprint” into the server memory prior to the download of any data (e.g., application software) into the ECU. The “fingerprint” identifies the one who modifies the server memory.
在将任何数据(例如,应用软件)下载到ECU之前,必须先将“指纹”写入服务器内存,这是汽车制造商特有的。“指纹”可以识别修改服务器内存的人。
When using this option then the dataIdentifiers bootSoftwareFingerprint, applicationSoftwareFingerprint and applicationDataFingerprint shall be used to write the fingerprint information (see dataIdentifier definitions).
当使用此选项时,应使用数据标识符bootSoftwareFingerprint、applicationSoftwareFingerprint和applicationDataFingerprint来写入指纹信息(参见数据标识符定义)。
4
Where the server does not have the memory erase routine stored in permanent memory, then a download of the memory erase routine shall be performed. The download shall follow the specified sequence with RequestDownload (…), TransferData, and RequestTransferExit.
如果服务器没有存储 在永久存储器中的存储器擦除程序,则应下载存储器擦除程序。下载应遵循RequestDownload(…)、TransferData和RequestTransferExit指定的顺序。
5
It is vehicle manufacturer specific if a RoutineControl (0x31) is used to check whether the download of the memory erase routine was successful. Alternative methods are to provide the result in the RequestTransferExit positive response message or via a negative response message including the appropriate negative response code to the RequestTransferExit request message.
如果使用RoutineControl (0x31)检查是否成功下载内存擦除例程,则与车辆制造商有关。另一种方法是在RequestTransferExit正面响应消息中提供结果,或者通过包含RequestTransferExit请求消息的适当负面响应代码的负面响应消息提供结果。
6
The memory of the server shall be erased when required by the memory technology (e.g., flash memory) in order to allow an application software/data download. This is achieved via a routineIdentifier, using the RoutineControl (0x31) service to execute the erase routine.
当存储技术(如闪存)要求时,服务器的内存应被擦除,以便允许应用软件/数据下载。这是通过routineIdentifier实现的,使用RoutineControl (0x31)服务来执行擦除例程。
7
Where the server does not have the memory programming routine stored in permanent memory, then a download of the memory programming routine shall be performed. The download shall follow the specified sequence with RequestDownload (0x34), TransferData (0x36), and RequestTransferExit (0x37). Note that the memory programming algorithm may be downloaded along with the memory erase algorithm (see footnote d).
如果服务器没有 存储在永久存储器中的存储器编程例程,则应下载存储器编程例程。下载应遵循RequestDownload(0x34)、TransferData(0x36)和RequestTransferExit(0x37)的指定顺序。注意,存储器编程算法可以与存储器擦除算法一起下载(参见脚注d)。
8
It is vehicle manufacturer specific if a RoutineControl (0x31) is used to check whether the download of the memory program routine was successful. Alternative methods are to provide the result in the RequestTransferExit positive response message or via a negative response message including the appropriate negative response code to the RequestTransferExit request message.
如果使用RoutineControl (0x31)检查内存程序例程下载是否成功,则与车辆制造商有关。另一种方法是在RequestTransferExit正面响应消息中提供结果,或者通过包含RequestTransferExit请求消息的适当负面响应代码的负面响应消息提供结果。
9
Each download of a contiguous block of application software/data to a non-volatile server memory location (either a complete application software/data module or part of a software/data module) shall always follow the general data transfer method using the following service sequence:
每次将连续的应用软件/数据块下载到非易失性服务器存储器位置(完整的应用软件/数据模块或软件/数据模块的一部分)时,应始终遵循使用以下服务顺序的一般数据传输方法:
⎯ RequestDownload (0x34);
⎯ TransferData (0x36);
⎯ RequestTransferExit (0x37).
A single application software/data block might require multiple TransferData (0x36) request messages to be completely transmitted (this is the case if the length of the block exceeds the maximum network layer buffer size).
单个应用程序软件/数据块可能需要多个TransferData (0x36)请求消息才能完全传输(如果块的长度超过最大网络层缓冲区大小,就会出现这种情况)。
10
It is vehicle manufacturer specific if a RoutineControl (0x31) is used to check whether the download of the memory was successful. Alternative methods are to provide the result in the RequestTransferExit positive response message or via a negative response message including the appropriate negative response code to the RequestTransferExit request message.
如果使用RoutineControl (0x31)检查内存下载是否成功,则与车辆制造商有关。另一种方法是在RequestTransferExit正面响应消息中提供结果,或者通过包含RequestTransferExit请求消息的适当负面响应代码的负面响应消息提供结果。
11
This optional routineIdentifier (number chosen by the vehicle manufacturer) allows a client to verify if the download has been performed successfully once all application software/data blocks/modules are completely downloaded. This routine typically triggers the server to check any and all reprogramming dependencies and to perform all necessary action to prove that the download and programming into non-volatile memory was successful and valid (e.g., checksum, signature, DTCs, hardware/software compatibility, etc.). The details are left to the discretion of the vehicle manufacturer.
这个可选的routineIdentifier(由车辆制造商选择的编号)允许客户端在所有应用软件/数据块/模块完全下载后验证下载是否成功执行。这个例程通常会触发服务器检查任何和所有重编程依赖项,并执行所有必要的操作来证明下载和编程到非易失性存储器是成功和有效的(例如,校验和、签名、dtc、硬件/软件兼容性等)。具体细节由汽车制造商自行决定。
Following the download of the application software/data, it is optional to reset the re-programmed server in order to enable the downloaded application software/data. It shall be considered that the re-programmed server could activate a new set of diagnostic identifiers, which differs to the ones used when performing the programming event. If either the server that was re-programmed does not change its communication parameters or the programming environment know the changed communication parameters, then following the reset certain configuration data can be written to the re- programmed server.
下载应用程序软件/数据后,可以选择重置重新编程的服务器,以启用下载的应用程序软件或数据。应考虑重新编程的服务器可以激活一组新的诊断标识符,该标识符与执行编程事件时使用的标识符不同。如果重新编程的服务器没有更改其通信参数,或者编程环境知道更改的通信参数,那么在重置之后,可以将某些配置数据写入重新编程的服务器。
12
Following the download of the application software/data, it is vehicle manufacturer specific to perform further operations such as writing configuration data (e.g. VIN, etc.) back to the server. This also depends on the functionally that is supported by the re-programmed server when running out of boot software.
在下载应用软件/数据之后,由汽车制造商执行进一步的操作,例如将配置数据(例如VIN等)写回服务器。这还取决于重新编程的服务器在启动软件用完时所支持的功能。
Figure 33 — Programming step of phase 1 (STP2)

15.2.1.3 Post-Programming step of phase #1

— Re-synchronization of vehicle network
阶段1的后编程步骤-车辆网络的重新同步
Figure 34 graphically depicts the functionality embedded in the post-programming step of phase #1.
图34以图形方式描述了嵌入在阶段#1的后编程步骤中的功能。
在这里插入图片描述

Key
1
The client transmits either an ECUReset (0x11) service request message onto the vehicle network with resetType equal to hardReset or DiagnosticSessionControl (0x10) with sessionType equal to defaultSession. This can either be done functionally addressed or physically addressed (depends on the supported vehicle approach). Further it is vehicle manufacturer specific whether a response message is required or not.
客户端发送ECUReset (0x11)服务请求消息到车辆网络,resetType等于hardReset或DiagnosticSessionControl (0x10), sessionType等于defaultSession。这既可以通过功能解决,也可以通过物理解决(取决于所支持的车辆方法)。此外,是否需要响应消息取决于车辆制造商。
When a baud rate switch has been performed, then this step shall be performed functionally, not requiring a response message, because the servers perform a baud rate transition to their normal speed of operation.
当执行了波特率转换时,则该步骤应在功能上执行,而不需要响应消息,因为服务器执行波特率转换到其正常操作速度。
The reception of the ECUReset (0x11) request message causes the server(s) to perform a reset and to start the defaultSession.
收到ECUReset (0x11)请求消息导致服务器执行重置并启动defaultSession
Figure 34 — Post-programming step of phase 1 (STP3)

15.2.1.4 Pre-programming step of phase #2

— Server configuration
阶段#2的预编程步骤-服务器配置
The pre-programming step of phase #2 is optional and should be used when there is the need to perform certain action after the software reset of the reprogrammed server. This will be the case when the server does not provide the required functionality to finally conclude the programming event when running out of boot software during the programming step of phase #1.
阶段#2的预编程步骤是可选的,应在重新编程服务器的软件重置后需要执行某些操作时使用。当在阶段#1的编程步骤期间引导软件用完时,服务器没有提供最终结束编程事件所需的功能时,就会出现这种情况。
Figure 35 graphically depicts the functionality embedded in the pre-programming step of phase #2.
图35以图形方式描述了嵌入在阶段#2的预编程步骤中的功能。
在这里插入图片描述

Key
1
Prior to any communication on the data link the network shall be initialized, which means that an initial wake-up of the vehicle network shall be performed. Thewake-up method and strategy is vehicle manufacturer specific and optional to be used. Furthermore, this step allows for a determination of the server communication parameters such as the network configuration parameter server diagnostic address and the data link identifiers used by the server(s).
在数据链路上进行任何通信之前,网络应初始化,这意味着应执行车辆网络的初始唤醒。唤醒方法和策略是汽车制造商特定的,可选择使用。此外,该步骤允许确定服务器通信参数,例如网络配置参数服务器诊断地址和服务器使用的数据链路标识符。
2
In order to be able to perform certain services in the programming step of phase #2, a non-defaultSession shall be started in each server on the data link that is involved in the conclusion of the programming event. This is performed via a DiagnosticSessionControl (0x10) service with sessionType equal to extendedDiagnosticSession.
为了能够在阶段#2的编程步骤中执行某些服务,必须在与编程事件结束有关的数据链路上的每个服务器上启动一个非defaultsession。这是通过一个sessionType等于extendedDiagnosticSession的DiagnosticSessionControl (0x10)服务来执行的。
3
Following the transition into the extendedDiagnosticSession, further vehicle manufacturer specific data link initialization steps can optionally be performed.
在过渡到extendedDiagnosticSession之后,可以选择性地执行其他特定于汽车制造商的数据链路初始化步骤。
EXAMPLE A vehicle manufacturer-specific additional initialization step can be to issue a request that causes gateway devices to perform a wake-up on all data links which are not accessible by the client directly through the diagnostic connector. The gateway will keep the data link(s) awake as long as the non defaultSession is kept active in the gateway.
特定于汽车制造商的附加初始化步骤可以是发出一个请求,使网关设备对客户端无法通过诊断连接器直接访问的所有数据链路执行唤醒。只要网关中的非defaultSession保持活动状态,网关就会使数据链路保持清醒状态。
Figure 35 — Pre-programming step of phase 2 (STP4)

15.2.1.5 Programming step of phase #2

— Final server configuration
阶段#2的编程步骤-最终服务器配置
The programming step of phase #2 is optional and contains any action that needs to take place with the reprogrammed server after the reset (when the application software is running) such as writing specific identification information. This step might be required in case the server does not provide the required functionality to perform an action when running out of boot software during the programming step of phase #1.
阶段#2的编程步骤是可选的,它包含复位后(当应用程序软件运行时)需要在重新编程的服务器上执行的任何操作,例如编写特定的标识信息。如果在阶段#1的编程步骤中启动软件用完时,服务器没有提供执行操作所需的功能,则可能需要此步骤。
When multiple servers require performing additional functions, then multiple programming steps can run in parallel or will be performed sequentially.
当多个服务器需要执行附加功能时,多个编程步骤可以并行运行或按顺序执行。
Figure 36 depicts the programming step of phase 2 (STP5).
图36描述了阶段2 (STP5)的编程步骤。
在这里插入图片描述

Key
1
In case the re-programmed server(s) has (have) been reset during the programming step of programming phase #1, then any diagnostic information that might have been stored in the re-programmed server(s) may be cleared via a physically addressed ClearDiagnosticInformation (0x14) service.
如果重新编程的服务器在编程阶段#1的编程步骤中被重置,那么可能存储在重新编程的服务器中的任何诊断信息都可以通过物理寻址的ClearDiagnosticInformation (0x14)服务清除。
2
The client performs any operation that is required in order to conclude the programming event with the server, such as writing configuration data (e.g. VIN).
客户端执行为了结束与服务器的编程事件所需的任何操作,例如写入配置数据(例如VIN)。
Figure 36 — Programming step of phase 2 (STP5)

15.2.1.6 Post-programming step of phase #2

— Re-synchronization of vehicle network
阶段2的后规划步骤-车辆网络的重新同步
Figure 37 depicts the Post-programming step of phase 2 (STP6).
图37描述了阶段2 (STP6)的后编程步骤。
在这里插入图片描述

Key
1
The client transmits either an ECUReset (0x11) service request message onto the vehicle network with resetType equal to hardReset or DiagnosticSessionControl (0x10) with sessionType equal to defaultSession. This can either be done functionally addressed or physically addressed (depends on the supported vehicle approach). Further it is vehicle manufacturer-specific whether a response message is required or not.
客户端发送ECUReset (0x11)服务请求消息到车辆网络,resetType等于hardReset或DiagnosticSessionControl (0x10), sessionType等于defaultSession。这既可以通过功能解决,也可以通过物理解决(取决于所支持的车辆方法)。此外,是否需要响应消息取决于汽车制造商。
When a baud rate switch has been performed, then this step shall be performed functionally, not requiring a response message, because the servers perform a baud rate transition to their normal speed of operation.
当执行了波特率转换时,则该步骤应在功能上执行,而不需要响应消息,因为服务器执行波特率转换到其正常操作速度。
The reception of the ECUReset (0x11) request message causes the server(s) to perform a reset and to start the defaultSession.
收到ECUReset (0x11)请求消息导致服务器执行重置并启动defaultSession。
Figure 37 — Post-programming step of phase 2 (STP6)

15.3 Server reprogramming requirements

服务器重编程要求

15.3.1 Requirements for servers to support programming

支持编程的服务器要求
During a programming session, servers shall default their physical I/O pins (wherever possible and without risk of damage to the server/vehicle and without risk of safety hazards) to a predefined state which minimizes current draw.
在编程会话期间,服务器应将其物理I/O引脚(在可能且没有损坏服务器/车辆的风险和没有安全隐患的情况下)默认为预定义的状态,从而使电流消耗最小化。

15.3.1.1 Boot software description and requirements

启动软件描述和要求

15.3.1.1.1 Boot software general requirements

启动软件一般要求
All programmable servers that support programming of the application software shall contain boot software in a boot memory partition. Servers that support boot software typically continue to execute out of the boot software until a complete set of application software and application data is programmed (e.g., it is possible for some servers to begin executing application software despite not having 100% of application data programmed).
所有支持应用软件编程的可编程服务器应在引导内存分区中包含引导软件。支持引导软件的服务器通常在引导软件之外继续执行,直到一套完整的应用软件和应用程序数据被编程完成(例如,有些服务器可能在没有100%的应用程序数据编程的情况下开始执行应用程序软件)。
The boot memory partition shall be protected against inadvertent erasure such that a failed attempt to modify application data or application software does not prohibit the server’s ability to recover and be programmed after the failed attempt. The server shall be able to recover and be reprogrammed if any of the following error conditions occur during the programming process:
启动内存分区应防止无意的擦除,这样修改应用程序数据或应用程序软件的失败尝试不会禁止服务器在失败尝试后恢复和编程的能力。如果在编程过程中出现以下任何错误情况,服务器应能够恢复并重新编程:
a) loss of supplied power connection.
b) loss of the ground connection.
c) disruption of data link communication.
d) over- or under-voltage conditions.
A)电源连接丢失。
B)失去地面连接。
C)数据链通信中断。
D)过压或欠压情况。
The boot software can be protected via hardware (e.g., via settings in a control register which prevents certain sectors of the memory from being erased or written to) or software (e.g., address range restrictions in the programming routines). It is recommended that the boot software not be capable of being modified by the same programming erase/write routines that are used to modify the application software and application data.
引导软件可以通过硬件(例如,通过控制寄存器中的设置来防止存储器的某些扇区被擦除或写入)或软件(例如,编程例程中的地址范围限制)来保护。建议引导软件不能被用于修改应用软件和应用数据的相同的编程擦除/写例程修改。
Programming the boot software as part of the programming process may be allowed, provided that a mechanism is in place to ensure that there is no possibility that the server could fail at a point of the programming process where it cannot recover and be programmed with a subsequent programming event.
可以允许将引导软件作为编程过程的一部分进行编程,前提是存在一种机制,以确保服务器在编程过程的某个点上不可能出现故障,从而无法恢复并使用随后的编程事件进行编程。
Boot software resides in the boot memory partition and is the software that a server begins executing upon power-up. Transfer of program control to the boot software also occurs once the server is informed that it is about to be programmed (e.g., reference the DiagnosticSessionControl service and the programming process defined in 15.2.1.2). A typical implementation showing the interactions and transitions between the boot software and the application software is shown in Figure 38.
引导软件位于引导内存分区中,是服务器上电后开始执行的软件。一旦服务器被告知它即将被编程(例如,引用DiagnosticSessionControl服务和15.2.1.2中定义的编程过程),将程序控制转移到引导软件也会发生。一个典型的实现显示了引导软件和应用软件之间的交互和转换,如图38所示。
在这里插入图片描述

Key
1
Some implementations may have the capability to transition to the Reprogramming Software programmingSession without going through a full power on reset.
一些实现可能有能力转换到重新编程软件的编程会话,而不需要经过完全的开机重置。
2
This check can serve two purposes. One is to check whether the application requested a transition into the reprogramming software’s programmingSession. The other is an alternative entry into the reprogramming software by other conditions (e.g., by scanning for a SessionControl programmingSession request over a small time window).
这种检查可以达到两个目的。一个是检查应用程序是否请求过渡到重新编程软件的programmingSession。另一种是通过其他条件进入重编程软件的替代入口(例如,在一个小时间窗口内扫描SessionControl programmingSession请求)。
Figure 38 — Example of typical interaction and transitions between application and boot software
应用程序和引导软件之间的典型交互和转换示例

15.3.1.1.2 Boot software diagnostic service requirements

启动软件诊断服务要求
Table 441 to Table 443 define the minimum diagnostic service requirements for the boot software of a programmable server. The listed services have to be supported in order to fulfil the requirements for performing non-volatile server memory programming during programming phase #1. The tables make use of the steps defined for programming phase #1 (see 15.2.1). The service(s) to be supported for steps (1), (3) and (8) shall be defined by the vehicle manufacturer.
可编程服务器启动软件的最低诊断服务要求如表441 ~表443所示。必须支持列出的服务,以便在编程阶段#1中满足执行非易失性服务器内存编程的要求。这些表使用了为编程阶段#1定义的步骤(参见15.2.1)。步骤(1)、(3)和(8)所支持的服务应由车辆制造商定义。
在这里插入图片描述

NOTE Table 441 only applies if the vehicle manufacturer supports the pre-programming step of phase #1.
表441仅适用于车辆制造商支持阶段1的预编程步骤的情况。
在这里插入图片描述

15.3.1.2 Security requirements

安全需求
All programmable servers that have emission, safety or theft related features shall employ a seed and key security feature, accessible via the SecurityAccess (0x27) service, to protect the programmed server from inadvertent erasure and unauthorized programming. All such field service replacement servers shall be shipped to the field with the security feature activated (i.e., a programming tool cannot gain access to the server without first gaining access through the SecurityAccess service).
所有具有排放、安全或盗窃相关功能的可编程服务器应采用种子和密钥安全功能,可通过SecurityAccess(0x27)服务访问,以保护编程服务器免受无意擦除和未经授权的编程。所有此类现场服务替换服务器应在激活安全功能的情况下运送到现场(即,编程工具在未首先通过SecurityAccess服务获得访问权限的情况下无法访问服务器)。

15.3.2 Software, data identification and fingerprints

软件、数据识别和指纹

15.3.2.1 Software and data identification

软件和数据识别
The boot software, application software and application data may be identified via the dataIdentifiers according to C.1. The structure of the dataRecord for bootSoftwareIdentification, applicationSoftwareIdentification and applicationDataIdentification is vehicle manufacturer specific.
启动软件、应用软件和应用数据可以根据C.1通过数据标识符进行识别。用于bootSoftwareIdentification、applicationSoftwareIdentification和applicationDataIdentification的数据记录的结构是特定于汽车制造商的。
The bootSoftwareIdentification, applicationSoftwareIdentification and applicationDataIdentification shall be part of each module that is downloaded into the server; therefore any write operation to the defined dataIdentifiers shall be rejected by the server.
启动软件识别、应用软件识别和应用数据识别应是下载到服务器的每个模块的一部分;因此,对定义的数据标识符的任何写操作都将被服务器拒绝。

15.3.2.2 Software and data fingerprints

A fingerprint uniquely identifies the programming tool that erased and/or reprogrammed the server software/data. If the server software/data is separated in several modules, the fingerprint could also identify which software/data module is manipulated (e.g., boot software, application software, and application data). If supported a fingerprint shall be written into non-volatile memory of the server before any software/data manipulation occurs (e.g. before erasing the flash memory).
指纹唯一地标识擦除和/或重新编程服务器软件/数据的编程工具。如果服务器软件/数据被分成几个模块,指纹还可以识别哪个软件/数据模块被操纵(例如,引导软件、应用软件和应用数据)。如果支持,指纹应在任何软件/数据操作发生之前(例如,在擦除闪存之前)写入服务器的非易失性存储器。
The boot software, application software and application data fingerprints may be identified via the dataIdentifiers according to C.1.
启动软件、应用软件和应用数据指纹可以根据C.1通过数据标识符进行识别。
The structure of the dataRecord for bootSoftwareFingerprint, applicationSoftwareFingerprint, and applicationDataFingerprint is vehicle manufacturer specific.
bootSoftwareFingerprint、applicationSoftwareFingerprint和applicationDataFingerprint的数据记录结构是特定于汽车制造商的。

15.3.3 Server routine access

服务器例程访问
Routines are used to perform non-volatile memory access such as erasing non-volatile memory and checking the successful download of a module.
例程用于执行非易失性存储器访问,例如擦除非易失性存储器和检查模块的成功下载。
Table 444 defines the standardized routineIdentifiers for non-volatile memory access. Other routineIdentifier numbers used in the programming sequence are specified by the vehicle manufacturer.
表444定义了非易失性内存访问的标准化routineIdentifiers。在编程序列中使用的其他例程标识符号码由车辆制造商指定。
在这里插入图片描述

15.4 Non-volatile server memory programming message flow examples

非易失性服务器内存编程消息流示例

15.4.1 General information

The following example presents CAN message traffic for a non-volatile server memory-programming event of a single server. The given message flows are based on a single server and the transfer of two modules, where each module has a length of 511 bytes. The network layer buffer size of the server that is reprogrammed is 255 bytes (reported in the RequestDownload positive response message). The programming example uses the 11 bit OBD CAN Identifiers as specified in ISO 15765-4. Therefore, all frames must be padded with filler bytes (DLC = 8). All CAN frames of a request message are padded with a filler byte of 0x55.
以下示例显示了单个服务器的非易失性服务器内存编程事件的CAN消息流量。给定的消息流基于单个服务器和两个模块的传输,其中每个模块的长度为511字节。重新编程的服务器的网络层缓冲区大小为255字节(在RequestDownload肯定响应消息中报告)。编程示例使用ISO 15765-4中规定的11位OBD CAN标识符。因此,所有帧都必须填充填充字节(DLC=8)。请求消息的所有CAN帧都填充有0x55的填充字节
All CAN frames of a response message are padded with a filler byte of 0xAA.
响应消息的所有CAN帧都用0xAA填充填充字节。
NOTE Filler bytes can have any value.
说明填充字节可以是任意值。

15.4.2 Programming phase #1 — Pre-Programming step

编程阶段#1 -预编程步骤
See Table 445 through Table 447.
参见表445至表447。
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

15.4.3 Programming phase #1 — Programming step

编程阶段#1 -编程步骤
See Table 448 through Table 463

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

15.4.4 Programming phase #1 — Post-Programming step

编程阶段#1——编程后步骤
See Table 464.
在这里插入图片描述

  • 13
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
fluent_uds_uds是一款用于刷写和下载的程序。UDS(Unified Diagnostic Services)是一种用于在汽车电子系统中进行诊断和编程的协议,而fluent是一种操作系统级代码的风格,因此,fluent_uds_uds的程序可以在车辆中用于刷写和下载各种功能。 这个程序的主要功能是通过与车辆电子控制单元(ECU)进行通信,实现对车辆电子系统的刷写和下载。它可以与各种汽车品牌和型号的ECU进行兼容,提供稳定可靠的刷写和下载功能。用户可以使用该程序来更新ECU固件、配置参数、修复故障、改善性能以及安装新功能等。 使用fluent_uds_uds程序的过程通常包括以下几个步骤: 首先,用户需要将fluent_uds_uds程序安装到适用的设备上,这可以是计算机、编程器或其他兼容设备。接下来,用户需要连接设备与车辆的ECU之间的通信接口,如OBD-II接口或CAN总线。 然后,用户可以通过fluent_uds_uds程序与ECU进行通信。程序通常提供一个用户界面,用户可以通过该界面选择所需的操作,例如刷写固件、下载参数等。程序会将命令发送给ECU,并在操作完成后返回相应的结果。 在刷写和下载过程中,fluent_uds_uds程序会提供实时的进度和反馈,以帮助用户了解操作的进行情况。它还可能提供一些特定的功能,如备份和恢复操作、记录和查看日志等。 总之,fluent_uds_uds是一款方便使用的程序,可以帮助用户进行汽车ECU的刷写和下载操作。它支持多种车辆品牌和型号,提供稳定可靠的功能,并具有用户友好的界面和实时反馈。无论是修复故障、改善性能还是安装新功能,该程序都可以胜任。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值