电子控制单元的刷写方法、装置、设备以及存储介质与流程

1.本公开涉及计算机技术领域，尤其涉及车辆控制、自动驾驶领域。


背景技术：

2.ota(over-the-air technology，空中下载技术)管理器(master)，在刷写整车电子控制单元(ecu)时，只能在程序中固定好某种刷写方式。如果ecu的刷写方式发生改变或者主机厂变更，需要重新修改代码编译发版。


技术实现要素：

3.本公开提供了一种电子控制单元的刷写方法、装置、设备以及存储介质。
4.根据本公开的一方面，提供了一种电子控制单元的刷写方法，包括：
5.解析目标电子控制单元(ecu)的配置文件得到目标ecu的配置信息；
6.根据目标ecu的配置信息，获取目标ecu的刷写流程；
7.按照目标ecu的刷写流程，对目标ecu进行刷写。
8.根据本公开的另一方面，提供了一种电子控制单元的刷写装置，包括：
9.第一解析模块，用于解析目标ecu的配置文件得到目标ecu的配置信息；
10.获取模块，用于根据目标ecu的配置信息，获取目标ecu的刷写流程；
11.刷写模块，用于按照目标ecu的刷写流程，对目标ecu进行刷写。
12.根据本公开的另一方面，提供了一种电子设备，包括：
13.至少一个处理器；以及
14.与该至少一个处理器通信连接的存储器；其中，
15.该存储器存储有可被该至少一个处理器执行的指令，该指令被该至少一个处理器执行，以使该至少一个处理器能够执行本公开中任一实施例的方法。
16.根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，该计算机指令用于使该计算机执行根据本公开中任一实施例的方法。
17.根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现根据本公开中任一实施例的方法。
18.根据本公开实施例，能够利用目标ecu的配置信息对目标ecu采用合适的刷写流程进行刷写。
19.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
20.附图用于更好地理解本方案，不构成对本公开的限定。其中：
21.图1是根据本公开一实施例的电子控制单元的刷写方法的流程示意图；
22.图2是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图；
23.图3是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图；
24.图4是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图；
25.图5是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图；
26.图6是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图；
27.图7是根据本公开一实施例的电子控制单元的刷写装置的结构示意图；
28.图8是根据本公开另一实施例的电子控制单元的刷写装置的结构示意图；
29.图9是根据本公开另一实施例的电子控制单元的刷写装置的结构示意图；
30.图10是根据本公开另一实施例的电子控制单元的刷写装置的结构示意图；
31.图11是用于刷写整车ecu的ota管理器框架的结构示意图；
32.图12是ecu升级流程的示意图；
33.图13是可以用来实施本公开的实施例的示例电子设备的示意性框图。
具体实施方式
34.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
35.图1是根据本公开一实施例的电子控制单元的刷写方法的流程示意图，包括：
36.s101、解析目标电子控制单元ecu的配置文件得到该目标ecu的配置信息；
37.s102、根据该目标ecu的配置信息，获取该目标ecu的刷写流程；
38.s103、按照该目标ecu的刷写流程，对该目标ecu进行刷写。
39.在本公开实施例中，每个ecu可以具有对应的配置文件。ecu的配置文件中可以包括该ecu实现刷写所需的基本的配置信息。需要进行刷写的ecu可以称为目标ecu。刷写也可以称为数据刷写。在对目标ecu进行刷写的过程中，可以通过通信网络例如can(controller area network,控制器局域网络)总线或以太网等，向目标ecu发送数据，实现目标ecu数据的管理和更新。例如，在ota管理器(master)中可以设置配置文件解析模块，解析目标ecu的配置文件可以得到该目标ecu的各种配置信息，例如逻辑地址、ip地址、ecu类型、通信方式等，解析完配置文件得到的结果可以供ota管理器的其他模块使用。再如，在ota管理器中可以设置刷写流程控制模块，根据目标ecu的配置信息获取该目标ecu的刷写流程后，可以按照目标ecu的刷写流程，控制目标ecu和ota管理器之间的刷写命令。
40.在本公开实施例中，能够利用目标ecu的配置信息对目标ecu采用合适的刷写流程进行刷写。例如，与需要重新编写代码的方式相比，本公开实施例的方案仅需要修改配置文件中配置信息即可实现对不同ecu的刷写。
41.图2是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图，该实施例的方法包括上述电子控制单元的刷写方法实施例的一个或多个特征。在一种可能的实施方式中，该目标ecu的配置信息包括该目标ecu的类型，其中，s102根据该目标ecu的配置信息，获取该目标ecu的刷写流程，包括：s201、获取与该目标ecu的类型对应的目标ecu的刷写流程。
42.在本公开实施例中，ecu的类型可以包括多种，例如，mcu(microcontroller unit，
微控制单元)类型的ecu、带文件系统的ecu以及支持ab分区的ecu等。不同类型的ecu的刷写流程可能不同。例如，mcu类型的ecu可以先擦再写。再如，带文件系统的ecu的处理器较大，可以采用特定命令进行刷写。再如，支持ab分区的ecu，可以将升级包的数据写入ecu的b分区。在解析目标ecu的配置文件得到目标ecu的类型后，可以确定目标ecu的类型对应的目标ecu的刷写流程。例如，mcu类型的ecu对应的刷写流程为引导加载程序(bootloader)，带文件系统的ecu对应的刷写流程为mcu上的引导加载程序(bootloaderonmpu)，支持ab分区的ecu对应的刷写流程为ab交换(abswap)。如果目标ecu的类型为带文件系统的ecu，则目标ecu的刷写流程为引导加载程序(bootloader)。
43.在本公开实施例中，可以支持对不同类型的目标ecu进行刷写，有利于快速添加不同类型的目标ecu。
44.图3是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图，该实施例的方法包括上述电子控制单元的刷写方法实施例的一个或多个特征。在一种可能的实施方式中，该目标ecu的配置信息包括该目标ecu的通信方式，其中，s103按照该目标ecu的刷写流程，对该目标ecu进行刷写，包括：
45.s301、按照该目标ecu的刷写流程，并采用该目标ecu的通信方式与该目标ecu通信；
46.s302、在每次通信过程中，解析uds(unified diagnostic services，统一诊断服务)命令，直至该目标ecu的刷写流程结束。
47.在本公开实施例中，ecu的通信方式可以包括多种，例如：can、canfd(can with flexible data-rate，带灵活数据速率的can)、doip(diagnostic communication over internet protocol，通过网络协议进行诊断通信)等。如果通信方式为can，刷写装置例如ota管理器(master)可以采用can协议与目标ecu通信，ota管理器和目标ecu之间的交互的数据为can数据。如果通信方式为canfd，刷写装置例如ota管理器(master)可以采用canfd协议与目标ecu通信，ota管理器和目标ecu之间的交互的数据为can数据。如果通信方式为doip，刷写装置例如ota管理器(master)可以采用doip与目标ecu通信，ota管理器和目标ecu之间的交互的数据为以太网数据。在物理层，基于can或canfd的can数据通过can总线收发，基于doip的以太网数据通过以太网收发。
48.在刷写过程中，ota管理器(master)与目标ecu通信，在每次通信过程中，需要解析uds命令。uds命令可以包括多种，例如uds请求(request)、uds确认(positive)、uds否定(negative)等命令。可以根据目标ecu的主机厂提供的文件例如odx.html解析uds命令。
49.如果ota管理器需要向目标ecu发送数据，可以将需要发送的数据携带在uds请求中，并利用该uds对应的通信协议对该uds进行封装得到can数据或以太网数据。然后，ota管理器再向目标ecu发送该can数据或以太网数据。ota管理器可以先将该can数据或以太网数据发送至网关，再由网关发送给目标ecu。ota管理器也可以直接将该can数据或以太网数据发送给目标ecu。
50.如果ota管理器接收到来自网关或目标ecu的can数据或以太网数据，可以从该can数据或以太网数据中解析得到uds数据。然后再解析该uds数据以确定其中的uds命令是uds肯定命令还是uds否定命令。如果是uds肯定命令，可以表示该ota管理器的uds请求命令被成功执行。如果是uds否定命令，可以表示该ota管理器的uds请求命令被拒绝执行。
51.例如，如果目标ecu是mcu类型的ecu，其刷写流程可以包括先擦再写等步骤。ota管理器可以先向目标ecu发送擦除某段存储地址的uds请求命令。目标ecu收到该uds请求命令后，如果成功删除该段存储地址内存储的数据，可以向ota管理器返回uds确认命令；如果不能成功删除该段存储地址内存储的数据，可以向ota管理器返回uds否定命令。然后，ota管理器可以先向目标ecu发送写入某段分数据的uds请求命令。目标ecu收到该uds请求命令后，如果成功写入这段数据，可以向ota管理器返回uds确认命令；如果不能成功写入这段数据，可以向ota管理器返回uds否定命令。如果需要写入多段数据，可以重复执行写入的步骤，直至将所有所需的数据写入目标ecu后，该目标ecu的刷写流程结束。
52.在本公开实施例中，可以按照该目标ecu的刷写流程和通信方式，在每次通信过程中，解析uds命令，从而自动地完成对目标ecu刷写流程，能够适用于多种通信方式和多种类型ecu。
53.在一种可能的实施方式中，该方法还包括：解析升级包中的配置文件，得到升级包中的该第一数据。
54.在本公开实施例中，升级包可以包括目标ecu升级所需要的程序文件。解析升级包得到的第一数据，需要通过刷写流程添加到目标ecu中或者替换目标ecu中的部分或全部数据。例如，在ota管理器中可以设置解析升级包模块，用于按照升级包中的配置文件来解析升级包，得到特定格式的比如hex、s19或者其他自定义格式的第一数据。
55.在本公开实施例中，通过解析升级包中的配置文件，可以得到需要向ecu中写入的数据，能够实现快速升级，减少升级所需的人力物力。
56.在一种可能的实施方式中，如图4所示，在s302中，在每次通信过程中，解析uds命令，包括：
57.s401、根据待发送的第一数据生成uds命令；
58.s402、按照该目标ecu的通信方式对应的通信协议将该uds命令打包，得到打包的数据；
59.s403、向该目标ecu发送该打包的数据。
60.例如，解析升级包得到第一数据后，需要将第一数据发送给目标ecu。ota管理器可以根据第一数据生成uds请求命令。如果第一数据的数据量较大，可以分段发送，每次生成一个uds请求命令。接着，利用通信协议将uds请求命令打包得到can数据或以太网数据。然后按照刷写流程向目标ecu发送(或通过网关向目标ecu发送)该打包的can数据或以太网数据。如果需要分段发送，可以多次发送携带uds请求命令can数据或以太网数据。
61.在本公开实施例中，在发送数据的情况下，可以按照目标ecu的通信方式对应的通信协议将包括第一数据的uds命令打包，再发送到打包的数据。这样，可以支持向目标ecu发送基于各种通信协议生成的数据，有利于适用于更加丰富的场景。
62.在一种可能的实施方式中，如图5所示，在s302中，在每次通信过程中，解析uds命令，包括：
63.s501、接收来自于目标ecu的第二数据；
64.s502、按照该目标ecu的通信方式对应的通信协议对该第二数据进行解析；
65.s503、从解析结果中提取出uds命令。
66.例如，ota管理器从目标ecu或网关收到目标ecu的第二数据后，可以按照该目标
ecu的通信方式对应的通信协议对该第二数据进行解析。收发数据使用的通信协议可以相同。例如，如果发送第一数据时采用了can协议，那么解析第二数据时也采用can协议。利用通信协议对该第二数据进行解析后，可以从解析结果中突起uds命令。然后基于uds命令的uds数据部分，可以确定该uds命令是uds肯定命令还是uds否定命令。
67.在本公开实施例中，在接收数据的情况下，可以按照目标ecu的通信方式对应的通信协议解析包括uds命令的第二数据，从而提取出uds命令。这样，可以支持从目标ecu接收基于各种通信协议生成的数据，以确定刷写结果是否成功，不仅有利于适用于更加丰富的场景，还可以获取刷写过程的动态。
68.在一种可能的实施方式中，该uds命令包括uds请求命令、uds确认命令、uds否定命令的至少之一。通过解析各种uds命令可以控制执行目标ecu的刷写流程。例如，在ota管理器中可以设置解析uds命令模块，用于解析具体的uds命令，包括请求(request)、确认(positive)、否定(negative)等命令。
69.图6是根据本公开另一实施例的电子控制单元的刷写方法的流程示意图，该实施例的方法包括上述电子控制单元的刷写方法实施例的一个或多个特征。
70.在一种可能的实施方式中，该方法还包括：
71.s601、向该目标ecu发送种子(seed)信息，该种子信息用于表示身份信息；
72.s602、接收与该种子信息对应的校验信息；
73.s603、按照第一算法对该校验信息进行计算得到第一键(key)信息；
74.s604、向该目标ecu发送该第一键信息，以在该目标ecu校验收到的该第一键信息与自身按照该第一算法计算的第二键信息是否一致。
75.在本公开实施例中，可以包括身份校验的流程。身份校验通过后再执行刷写流程。例如，在s102或s103之前，可以先执行s601。ota管理器可以通过某个uds命令例如uds命令27向目标ecu发送种子(seed)信息。该种子信息可以表示该ota管理器或操作者等的身份信息。目标ecu根据种子信息可以向ota管理器返回几个字节例如4字节的校验信息。ota管理器可以采用设定的第一算法对该校验信息进行计算，得到第一键信息(例如key1)。ota管理器可以通过某个uds命令例如uds命令28将第一键信息发送给目标ecu。目标ecu也按照第一算法对发送给ota管理器的校验信息进行计算得到第二键信息(key2)。目标ecu收到第一键信息后，可以比较收到的第一键信息和自己计算的第二键信息是否一致。如果一致，可以表示身份校验通过，可以开始进行后续的刷写流程。如果不一致，可以表示身份校验不同，不允许进行后续的刷写流程。可以重新进行身份校验，也可以认为刷写失败。在身份校验过程中，通过目标ecu的通信协议对ota管理器与目标ecu之间交互的种子信息、校验信息、第一键信息、第二键信息等进行打包或解包。通过身份校验，能够保证刷写流程的安全性。
76.在一种可能的实施方式中，该方法还包括以下至少之一：
77.在向该目标ecu发送数据之后，请求该目标ecu返回crc码，以进行crc(cyclic redundancy check，循环冗余校验)校验；
78.在向该目标ecu发送数据之后，发送crc码，以在该目标ecu中进行crc校验。
79.在本公开实施例中，可以包括数据校验的流程。具体可以包括crc校验的流程。
80.在一种方式中，可以在ota管理器中进行crc校验。例如，ota管理器向该目标ecu发送数据，并可以请求目标ecu返回crc码。在目标ecu中可以根据收到的数据计算crc码，并将
该crc码返回ota管理器。ota管理器可以根据自己计算的crc码与收到的crc码进行比较。如果二者一致，可以表示crc校验成功；如果二者不一致，可以表示crc校验失败。
81.在另一种方式中，可以在目标ecu中进行crc校验。例如，ota管理器向该目标ecu发送数据，并可以向目标ecu发送该数据对应的crc码。在目标ecu中可以根据收到的数据计算crc码，并将自己计算的crc码与收到的crc码进行比较。如果二者一致，可以表示crc校验成功；如果二者不一致，可以表示crc校验失败。
82.在本公开实施例中，通过数据校验，能够保证刷写结果的准确性。
83.图7是根据本公开一实施例的电子控制单元的刷写装置的结构示意图，该装置包括：
84.第一解析模块701，用于解析目标电子控制单元ecu的配置文件得到该目标ecu的配置信息；
85.获取模块702，用于根据该目标ecu的配置信息，获取该目标ecu的刷写流程；
86.刷写模块703，用于按照该目标ecu的刷写流程，对该目标ecu进行刷写。
87.图8是根据本公开另一实施例的电子控制单元的刷写装置的结构示意图，该实施例的装置包括上述电子控制单元的刷写装置实施例的一个或多个特征。在一种可能的实施方式中，该目标ecu的配置信息包括该目标ecu的类型，该获取模块702用于获取与该目标ecu的类型对应的目标ecu的刷写流程。
88.在一种可能的实施方式中，该目标ecu的配置信息包括该目标ecu的通信方式，该刷写模块703，包括：
89.通信子模块801，用于按照该目标ecu的刷写流程，并采用该目标ecu的通信方式与该目标ecu通信；
90.解析子模块802，用于在每次通信过程中，解析统一诊断服务uds命令，直至该目标ecu的刷写流程结束。
91.在一种可能的实施方式中，该解析子模块802，包括：
92.生成子模块8021，用于根据待发送的第一数据生成uds命令；
93.打包子模块8022，用于按照该目标ecu的通信方式对应的通信协议将该uds命令打包，得到打包的数据；
94.发送子模块8023，用于向该目标ecu发送该打包的数据。
95.在一种可能的实施方式中，该解析子模块802，包括：
96.接收子模块8024，用于接收来自于目标ecu的第二数据；
97.数据解析子模块8025，用于按照该目标ecu的通信方式对应的通信协议对该第二数据进行解析；
98.提取子模块8026，用于从解析结果中提取出uds命令。
99.在一种可能的实施方式中，该uds命令包括uds请求命令、uds确认命令、uds否定命令的至少之一。
100.图9是根据本公开另一实施例的电子控制单元的刷写装置的结构示意图，该实施例的装置包括上述电子控制单元的刷写装置实施例的一个或多个特征。在一种可能的实施方式中，该装置还包括：
101.第二解析模块901，用于解析升级包中的配置文件，得到升级包中的该第一数据。
102.图10是根据本公开另一实施例的电子控制单元的刷写装置的结构示意图，该实施例的装置包括上述电子控制单元的刷写装置实施例的一个或多个特征。在一种可能的实施方式中，该装置还包括：
103.第一发送模块1001，用于向该目标ecu发送种子信息，该种子信息用于表示身份信息；
104.接收模块1002，用于接收与该种子信息对应的校验信息；
105.计算模块1003，用于按照第一算法对该校验信息进行计算得到第一键信息；
106.第二发送模块1004，用于向该目标ecu发送该第一键信息，以在该目标ecu校验收到的该第一键信息与自身按照该第一算法计算的第二键信息是否一致。
107.在一种可能的实施方式中，该装置还包括以下至少之一：
108.请求模块1005，用于在向该目标ecu发送数据之后，请求该目标ecu返回循环冗余校验crc码，以进行crc校验；
109.第三发送模块1006，用于在向该目标ecu发送数据之后，发送crc码，以在该目标ecu中进行crc校验。
110.本公开实施例的电子控制单元的刷写装置的各模块、子模块的具体功能和示例的描述，可以参见上述电子控制单元的刷写方法实施例中对应步骤的相关描述，在此不再赘述。
111.相关技术中，ota管理器(master)在刷写整车ecu时，不能针对升级包类型、通信方式、刷写时序等做动态适配。ota master在刷写目标ecu时，如果升级包类型、通信方式或刷写时序等变更，需要重新修改代码编译并发版。对于ota管理器来说，无法在各个主机厂项目中用同一套方案。升级包类型、通信方式、刷写时序中的至少一种，每次变更都需要修改大量代码，耗时耗力，不利于ota管理器项目中ota模块的移植。此外，ota管理器的整个升级模块划分不合理、耦合度高，所需投入的人力物力更大。
112.本公开实施例提供的ecu的刷写方法中，可以提出一种刷写ecu的模型，用于帮助ota管理器(master)划分各个功能模块，能够实现各种类型的ecu的动态适配。例如，该模型可以支持适配s19、hex等多种格式的升级包解析，可适配升级对象包括mcu类型的ecu、带文件系统的ecu以及支持ab分区的ecu等。另外也可适配can、canfd、doip等多种通信方式，各个功能模块均支持扩展。
113.该模型包括用于刷写整车ecu的ota管理器(master)框架。参见图11，该框架包括配置文件解析模块1101、刷写流程控制模块1102、收发数据模块1103、解析uds命令模块1104、解析升级包模块1105、其他模块。各个模块可以相互独立且可扩展。因此，如果添加新的ecu，只要底层接口没有变化，则只需要修改配置文件即可，无需重新修改代码编译发版，降低了开发成本。该框架中各个模块功能介绍如下：
114.配置文件解析(parseconfigfile)模块1101：该模块配置了ecu的各种信息，比如逻辑地址、ip地址、ecu类型、通信方式等，解析完配置文件例如config.json的结果供后续模块使用。
115.刷写流程控制(processflashprogram)模块1102：该模块控制了整个刷写流程，主要是控制目标ecu和ota master之间的刷写命令。
116.收发数据模块1103：该模块主要负责将发送数据(senddata)和/或接收数据
(receivedata)。比如收发数据模块将can数据或以太网数据发送给外部。收发的数据包括：基于can的uds(udsoncan)、基于canfd的uds(udsoncanfd)、基于doip的uds(udsondoip)等。
117.解析uds命令模块1104：该模块主要用于解析具体的uds命令，包括request、positive、negative命令。例如，解析uds命令模块根据主机厂提供的文件例如odx.html，可以解析uds请求命令(parseudsrequestcomma nd)、解析uds确定命令(parseudspositivecommand)、解析uds否定命令(parseudsnegativecommand)等。
118.解析升级包(parseupdatepackage)模块1105：该模块负责解析升级包，按照升级包中的配置文件来解析，比如hex、s19或者其他自定义格式。
119.其他模块：比如用于27/28uds命令的种子/键(seed/key)值计算接口、计算crc(calculatecrc)、计算签名(calculatesignature)等其他小的功能模块。
120.刷写单个ecu升级流程大致如图12所示：
121.s1201、最初ota master收到升级某个ecu的指令。
122.s1202、然后ota master开始解析该ecu对应的配置文件例如config.json得到配置信息。
123.s1203、随后ota master开始解析升级包，得到s19、hex等各种格式的数据。
124.s1204、升级包解析完成后，开始初始化收发数据模块。初始化成功后按照该ecu对应的刷写流程开始通信。通信方式可以包括can、canfd或doip等。
125.s1205、每次通信都需要解析uds命令例如请求(request)、确认(positive)、否定(negative)等命令，直到整个刷写流程结束。
126.按照配置文件中配置的特定刷写流程发送数据/接收数据。例如，mcu类型的ecu的刷写流程为引导加载程序(bootloader)、带文件系统的ecu的刷写流程为mcu上的引导加载程序(bootloaderonmpu)、支持ab分区的ecu的刷写流程为ab交换(abswap)。
127.如果是发送数据，需要按相应的通信协议将uds数据打包并发出；如果是接收数据，则需要按相应的通信协议将数据解析并提取出uds数据部分。
128.按照该模型开发的ota master刷写框架，可以快速添加不同类型的目标ecu，且对于各个子模块均可适配、可扩展。为ota master刷写ecu开发节省了大量成本，且因为子模块耦合度极低，也有利于节省后期维护成本。
129.本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。
130.根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
131.图13示出了可以用来实施本公开的实施例的示例电子设备1300的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
132.如图13所示，设备1300包括计算单元1301，其可以根据存储在只读存储器(rom)1302中的计算机程序或者从存储单元1308加载到随机访问存储器(ram)1303中的计算机程
序，来执行各种适当的动作和处理。在ram1303中，还可存储设备1300操作所需的各种程序和数据。计算单元1301、rom 1302以及ram 1303通过总线1304彼此相连。输入/输出(i/o)接口1305也连接至总线1304。
133.设备1300中的多个部件连接至i/o接口1305，包括：输入单元1306，例如键盘、鼠标等；输出单元1307，例如各种类型的显示器、扬声器等；存储单元1308，例如磁盘、光盘等；以及通信单元1309，例如网卡、调制解调器、无线通信收发机等。通信单元1309允许设备1300通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
134.计算单元1301可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1301的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1301执行上文所描述的各个方法和处理，例如电子控制单元的刷写方法。例如，在一些实施例中，电子控制单元的刷写方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1308。在一些实施例中，计算机程序的部分或者全部可以经由rom1302和/或通信单元1309而被载入和/或安装到设备1300上。当计算机程序加载到ram 1303并由计算单元1301执行时，可以执行上文描述的电子控制单元的刷写方法的一个或多个步骤。备选地，在其他实施例中，计算单元1301可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行电子控制单元的刷写方法。
135.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
136.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
137.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
138.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入、或者触觉输入)来接收来自用户的输入。
139.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
140.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。
141.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
142.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。