CN116382744B - 多个ecu并行刷写方法、装置、系统及存储介质 - Google Patents
多个ecu并行刷写方法、装置、系统及存储介质 Download PDFInfo
- Publication number
- CN116382744B CN116382744B CN202310652803.4A CN202310652803A CN116382744B CN 116382744 B CN116382744 B CN 116382744B CN 202310652803 A CN202310652803 A CN 202310652803A CN 116382744 B CN116382744 B CN 116382744B
- Authority
- CN
- China
- Prior art keywords
- data packet
- ota
- client
- clients
- upgrade data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 230000005540 biological transmission Effects 0.000 claims abstract description 116
- 230000004913 activation Effects 0.000 claims abstract description 60
- 238000003745 diagnosis Methods 0.000 claims description 46
- 230000001680 brushing effect Effects 0.000 claims description 25
- 230000004044 response Effects 0.000 claims description 16
- 238000006243 chemical reaction Methods 0.000 claims description 15
- 230000006854 communication Effects 0.000 claims description 15
- 238000004891 communication Methods 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 15
- 230000008569 process Effects 0.000 claims description 9
- 230000006870 function Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 14
- 230000007547 defect Effects 0.000 description 12
- WXZOXVVKILCOPG-UHFFFAOYSA-N bis(2-ethylhexyl) benzene-1,3-dicarboxylate Chemical compound CCCCC(CC)COC(=O)C1=CC=CC(C(=O)OCC(CC)CCCC)=C1 WXZOXVVKILCOPG-UHFFFAOYSA-N 0.000 description 8
- 238000012545 processing Methods 0.000 description 6
- 239000003795 chemical substances by application Substances 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000000605 extraction Methods 0.000 description 3
- 230000008439 repair process Effects 0.000 description 3
- 239000000284 extract Substances 0.000 description 2
- 238000011010 flushing procedure Methods 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
- Y02T10/00—Road transport of goods or passengers
- Y02T10/10—Internal combustion engine [ICE] based vehicles
- Y02T10/40—Engine management systems
Abstract
本申请涉及智能车辆技术领域，提供了多个ECU并行刷写方法、装置、系统及存储介质。该方法包括：建立多个OTA客户端与网关服务端之间的公用传输通道；经由公用传输通道向网关服务端发送路由激活请求；向每个OTA客户端发送提示信息；接收每个OTA客户端上传的升级数据包，升级数据包含有ECU的全域唯一逻辑地址；经由公用传输通道，将每个OTA客户端发送的升级数据包均转发至网关服务端，以使网关服务端对每个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU。本申请可实现对车辆全域的多个ECU的并行刷写，极大地缩短了升级刷写的时间，并可降低升级的成本。
Description
技术领域
本申请涉及智能车辆技术领域，尤其涉及一种多个ECU并行刷写方法、装置、系统及存储介质。
背景技术
OTA（Overthe Air Technology，空间下载技术）升级是指基于空间下载技术对固件和/或软件进行升级。OTA升级不仅可快速地修复系统（如车辆系统）的缺陷，而且可快速迭代、提升产品质量，从而提升用户对产品的使用体验，还可明显降低车辆系统固件和软件的升级成本。
为了更好地满足人满人们对于智能车辆的功能的多样化需求，智联网汽车功能也越来越丰富，车辆的ECU（Electronic Control Unit，电子控制单元，又称“行车电脑”、“车载电脑”等）件也越来越多。
目前的OTA升级基本是采用串行刷写的方式，且无法实现对同一个车辆功能域内的多个ECU的并行刷写。例如，当需要对同一个车辆功能域内的多个ECU（如车辆动力功能域内包括发动机、电池等多个动力ECU）进行升级刷写时，只能按照串行的方式每次刷写一个ECU，在刷写完一个ECU之后才能继续刷写下一个ECU。因此，这种升级刷写方式不仅耗时长，无法实现快速修复车辆系统的缺陷，无法快速迭代、提升产品质量，且升级升本较高。
发明内容
有鉴于此，本申请实施例提供了一种多个ECU并行刷写方法、装置、系统及存储介质，以解决现有的OTA 升级刷写方式不仅耗时长，无法实现快速修复车辆系统的缺陷，无法快速迭代、提升产品质量，且升级升本较高，同时也无法实现对同一个车辆功能域内的多个ECU的并行刷写的问题。
本申请实施例的第一方面，提供了一种多个ECU并行刷写方法，包括：
建立多个OTA客户端与网关服务端之间的公用传输通道；
在成功建立起公用传输通道后，经由公用传输通道向网关服务端发送路由激活请求，路由激活请求携带有每一个OTA客户端的源地址；
在接收到网关服务端针对路由激活请求返回的成功激活响应信息时，向每一个OTA客户端发送路由激活成功的提示信息，以提示OTA客户端上传升级数据包；
接收每一个OTA客户端上传的升级数据包，升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址；
经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，以使网关服务端对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，以使各个目标ECU基于接收到的升级数据包对其原数据包进行刷写升级。
本申请实施例的第二方面，提供了一种多个ECU并行刷写装置，包括：
建立模块，被配置为建立多个OTA客户端与网关服务端之间的公用传输通道；
发送模块，被配置为在成功建立起公用传输通道后，经由公用传输通道向网关服务端发送路由激活请求，路由激活请求携带有每一个OTA客户端的源地址；
信息发送模块，被配置为在接收到网关服务端针对路由激活请求返回的成功激活响应信息时，向每一个OTA客户端发送路由激活成功的提示信息，以提示OTA客户端上传升级数据包；
接收模块，被配置为接收每一个OTA客户端上传的升级数据包，升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址；
转发模块，被配置为经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，以使网关服务端对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，以使各个目标ECU基于接收到的升级数据包对其原数据包进行刷写升级。
本申请实施例的第三方面，提供了一种多个ECU并行刷写系统，包括：
OTA升级主控端；
与OTA升级主控端通信连接的网关服务端；
OTA升级主控端包括第二方面的多个ECU并行刷写装置。
本申请实施例的第四方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并且可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。
本申请实施例的第五方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。
本申请实施例与现有技术相比，其有益效果至少包括：通过建立多个OTA客户端与网关服务端之间的公用传输通道；在成功建立起公用传输通道后，经由公用传输通道向网关服务端发送路由激活请求，路由激活请求携带有每一个OTA客户端的源地址；在接收到网关服务端针对路由激活请求返回的成功激活响应信息时，向每一个OTA客户端发送路由激活成功的提示信息，以提示OTA客户端上传升级数据包；接收每一个OTA客户端上传的升级数据包，升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址；经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，以使网关服务端对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，以使各个目标ECU基于接收到的升级数据包对其原数据包进行刷写升级。通过上述方式，可以实现多个OTA客户端与网关服务端之间的通信连接，并实现多个OTA客户端的升级数据包的并行传输，并且每个OTA客户端上传的升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址，即一个全域唯一逻辑地址对应一个目标ECU；经由该公共传输通道将各个OTA客户端上传的升级数据包均转发至网关服务端，再由网关服务端进行解析和诊断后转发至相应的目标ECU进行升级刷写，不仅可实现对多个不同的车辆功能域间的ECU的并行刷写，还可以实现对同一个车辆功能域内的多个ECU的并行刷写，也即，可以实现对车辆全域的多个ECU的并行刷写，极大地缩短了升级刷写的时间，可快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，从而提升用户对产品的使用体验，同时还可明显降低OTA升级的成本。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1是本申请实施例的一种应用场景的场景示意图；
图2是本申请实施例提供的一种多个ECU并行刷写方法的流程示意图；
图3是本申请实施例提供的一种公用传输通道的结构示意图；
图4是本申请实施例提供的另一种公用传输通道的结构示意图；
图5是本申请实施例提供的又一种公用传输通道的结构示意图；
图6是本申请实施例提供的一种诊断报文的数据帧结构的示意图；
图7是本申请实施例提供的一种多个ECU并行刷写方法的应用示例；
图8是本申请实施例提供的一种多个ECU并行刷写方法的时序图；
图9是本申请实施例提供的一种多个ECU并行刷写装置的结构示意图；
图10是本申请实施例提供的一种多个ECU并行刷写系统的结构示意图；
图11是本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。
下面将结合附图详细说明根据本申请实施例的一种多个ECU并行刷写方法、装置和系统。
图1是本申请实施例提供的一种应用场景的场景示意图。该应用场景可以包括OTA客户端101、OTA客户端102、OTA客户端103、远程信息处理器（TBOX）104、网关服务端105、电子控制单元（ECU）106、电子控制单元（ECU）107、电子控制单元（ECU）108。
OTA客户端101、102、103可以分别通过网络（可以是采用同轴电缆、双绞线和光纤连接的有线网络，也可以是无需布线就能实现各种通信设备互联的无线网络，例如，蓝牙（Bluetooth）、近场通信（Near Field Communication，NFC）、红外（Infrared）等）与远程信息处理器（TBOX）104连接。远程信息处理器（TBOX）104与网关服务端105之间可通过以太网（简称“ETH”）连接。网关服务端105可通过CAN（Controller Area Network，控制器局域网络）、CAN-FD或ETH（以太网）总线分别与电子控制单元（ECU）106、107、108相连接。CAN-FD，可以理解成CAN协议的升级版，只升级了协议，物理层未改变。
OTA客户端101、102、103，可以是硬件，也可以是软件，当OTA客户端101、102、103为硬件时，其可以是具有显示屏且支持与远程信息处理器（TBOX）104通信的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等；当OTA客户端101、102、103为软件时，其可以安装在如上的电子设备中。OTA客户端101、102、103可以实现为多个软件或软件模块，也可以实现为单个软件或软件模块，本申请实施例对此不作限制。进一步地，OTA客户端101、102、103上可以安装有各种应用，例如数据处理应用、即时通信工具等。
远程信息处理器（TBOX）104，即远程通信终端，可以是安装在车辆内部（如仪表盘下方）的远程通信终端。远程信息处理器中可承载设置有用于实现本申请实施例的多个ECU并行刷写方法，以将各个OTA客户端上传的升级数据包转发至网关服务端的OTA升级主控端（简称“UMC”）。
网关服务端105，可以是承载设置有OTA升级代理（简称“UA”）的网关（GateWay，简称“GW”）。
电子控制单元（ECU）106、107、108，是指安装在车辆上用于控制车辆的某部分功能的ECU部件。例如，可以是车辆上的任一车辆功能域中的任一ECU部件。比如，车辆具有多个功能域，包括动力域（主要包括与车辆的动力控制相关的功能部件）、车身域（主要包括车门等功能部件）、娱乐域（主要包括车载音乐等功能部件）等。电子控制单元（ECU）106、107、108可以是动力域中的任意三个ECU，也可以分别是动力域、车身域和娱乐域中的任一个ECU。
在本申请实施例中，远程信息处理器（TBOX）104可利用承载在其中的OTA升级主控端（UMC）建立多个OTA客户端（如OTA客户端101、102、103）与网关服务端105之间的公用传输通道；在成功建立起它们之间的公用传输通道后，UMC可经由该公用传输通道向网关服务端105发送路由激活请求；在接收到网关服务端105针对该路由激活请求返回的成功激活响应信息时，向每一个OTA客户端（即OTA客户端101、102、103）发送路由激活成功的提示信息，以提示OTA客户端101、102、103上传升级数据包；UMC在接收到OTA客户端101、102、103上传的升级数据包时，再经由该公用传输通道，将接收到的升级数据包均转发至网关服务端105；网关服务端105在接收到这些升级数据包之后，会对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU（例如，电子控制单元（ECU）106、107、108），并将每个升级数据包分发至对应的目标ECU；各个目标ECU在接收到升级数据包后，利用该升级数据包对其原数据包进行刷写升级。通过上述方式，不仅可实现对多个不同车辆功能域间的ECU的并行刷写，还可以实现对同一个车辆功能域内的多个ECU的并行刷写，极大地缩短了升级刷写的时间，可快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，从而提升用户对产品的使用体验，同时还可明显降低OTA升级的成本。
需要说明的是，OTA客户端101、OTA客户端102、OTA客户端103、远程信息处理器（TBOX）104、网关服务端105、电子控制单元（ECU）106、电子控制单元（ECU）107、电子控制单元（ECU）108的具体类型、数量和组合可以根据应用场景的实际需求进行调整，本申请实施例对此不作限制。例如，OTA客户端的数量可以是2个或2个以上，电子控制单元（ECU）的数量也可以是2个或2个以上。
由于OTA客户端的源地址（即OTA客户端的逻辑地址）一般是固定的（如固定为0x0F00），一个OTA客户端的源地址只能与一个socket进行绑定，所以只能创建一个TCPsocket客户端与GW的TCP socket服务端相连接，即只允许一个OTA客户端与GW通信连接，以接收或发送数据，故只能进行串行刷写。其中，TCP（Transmission ControlProtocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC793定义。socket，即套接字，就是两台主机之间逻辑连接的端点。比如说，网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket。
由于上述原因，现有的OTA升级方式只能实现串行刷写，无法实现对同一个车辆功能域内的多个ECU的并行刷写。这种升级刷写方式不仅耗时长，无法实现快速修复车辆系统的缺陷，且升级升本较高。
为解决上述技术问题，本申请实施例提供了一种多个ECU并行刷写方法，该方法可在只建立一个TCP socket客户端与GW的TCP socket服务端相连接的基础上，实现对车辆功能域间或域内的多个ECU的并行刷写。
图2是本申请实施例提供的一种多个ECU并行刷写方法的流程示意图。图2的多个ECU并行刷写方法可以由图1的远程信息处理器（TBOX）104中的OTA升级主控端（UMC）执行。如图2所示，该多个ECU并行刷写方法包括：
步骤S201，建立多个OTA客户端与网关服务端之间的公用传输通道。
公用传输通道，可以是设置在OTA升级主控端（UMC）内部的数据传输通道。该数据传输通道使用同一个TCP socket客户端与GW的TCP socket服务端进行绑定，从而实现对多个OTA客户端上传的升级数据包的转发。
在一实施例中，OTA升级主控端（UMC）在客户端侧，UMC可以通过车联网发现并连接车辆；之后创建车辆列表，将发现并连接上的车辆的车辆信息（包括车辆ID、车辆ECU、车辆ECU支持的诊断协议等）添加到该车辆列表中；再创建TCP socket客户端，并将该TCPsocket客户端与网关服务端创建的TCP socket服务端进行绑定。
步骤S202，在成功建立起公用传输通道后，经由公用传输通道向网关服务端发送路由激活请求，路由激活请求携带有每一个OTA客户端的源地址。
当OTA升级主控端检测到其创建的TCP socket客户端可连接到网关服务端创建的TCP socket服务端时，表示成功建立起该共用传输通道。OTA升级主控端可通过该公用传输通道向网关服务端105发送路由激活请求，路由激活请求携带有每一个OTA客户端的源地址。OTA客户端的源地址，即系OTA客户端的逻辑地址，如为“0x0F00”。
在本申请实施例中，多个OTA客户端可以是源地址相同的OTA客户端，也可以是源地址不同的OTA客户端。
步骤S203，在接收到网关服务端针对路由激活请求返回的成功激活响应信息时，向每一个OTA客户端发送路由激活成功的提示信息，以提示OTA客户端上传升级数据包。
网关服务端105在接收到OTA升级主控端发送过来的路由激活请求时，可提取出该路由激活请求中的OTA客户端的源地址，并查询这些OTA客户端的源地址是否为合法的OTA客户端逻辑地址。例如，预先设定的合法的OTA客户端逻辑地址为“0x0F00~0x0F10”，那么在接收到OTA升级主控端发送过来的OTA客户端的源地址时，查询合法的OTA客户端逻辑地址“0x0F00~0x0F10”中是否存在这些OTA客户端的源地址。若存在，则向OTA升级主控端返回成功激活响应信息。成功激活响应信息包括激活成功的OTA客户端的源地址。
OTA升级主控端在接收到网关服务端105返回的成功激活响应信息时，向激活成功的源地址所对应的OTA客户端发送路由激活成功的提示信息（例如，可以是“路由激活成功，允许上传升级数据包”的提示语）。OTA客户端在接收到OTA升级主控端发送的提示信息后，即可上传升级数据包。
步骤S204，接收每一个OTA客户端上传的升级数据包，升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址。
作为一示例，假设一车辆的车辆功能域包括动力域、车身域、娱乐域等，动力域包括i个ECU，车身域包括j个ECU，娱乐域包括k个ECU，i，j，k均为≥2的正整数，那么为了区分每个车辆功能域中的每个ECU，可为每个车辆功能域中的每个ECU分配一个全域唯一逻辑地址，以唯一标识每一个ECU。
步骤S205，经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，以使网关服务端对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，以使各个目标ECU基于接收到的升级数据包对其原数据包进行刷写升级。
原数据包，是指目标ECU在未刷写升级前所使用的数据包。
各个目标ECU基于接收到的升级数据包对其原数据包进行刷写升级，具体是各个目标ECU使用网关服务端105转发过来的升级数据包对其原数据包进行刷写、覆盖，以达到升级的目的。
本申请实施例提供的技术方案，通过上述方式，可以实现多个OTA客户端与网关服务端之间的数据同步传输，并且每个OTA客户端上传的升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址，即一个升级数据包对应一个目标ECU；经由该公共传输通道将各个OTA客户端上传的升级数据包转发至网关服务端，再由网关服务端进行解析和诊断后转发至相应的目标ECU进行升级刷写，不仅可实现对多个不同车辆功能域间的ECU的并行刷写，还可以实现对同一个车辆功能域内的多个ECU的并行刷写，极大地缩短了升级刷写的时间，可快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，从而提升用户对产品的使用体验，同时还可明显降低OTA升级的成本。
图3是本申请实施例提供的一种公用传输通道的结构示意图。如图3所示，该公用传输通道包括多个内部客户端、一个内部服务端和一个对外客户端；多个内部客户端与多个OTA客户端的数量相同，一个内部客户端对应与一个OTA客户端连接；每一个内部客户端均与内部服务端连接；内部服务端与对外客户端连接；对外客户端与网关服务端105连接。
其中，图3中的“IN SOCKET CLIENT1~INSOCKET CLIENTn”表示内部客户端1~n，“INSOCKET SERVER”表示内部服务端，“OUT SOCKET CLIENT”表示对外客户端。
在公用传输通道中，内部区分多个不同的OTA客户端，外部不感知多个不同的OTA客户端。对外客户端使用TCP socket与网关服务端的TCP socket绑定，以将多个OTA客户端上传的升级数据传输至网关服务端。
在一些实施例中，在上述步骤S205中，经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，具体包括：
每一个内部客户端在接收与其通信连接的OTA客户端上传的升级数据包时，将接收到的升级数据包转发给内部服务端；
内部服务端将接收到的升级数据包转存至公用传输通道的共享内存空间中；
对外客户端实时读取共享内存空间中的升级数据包并转发至网关服务端。
作为一示例，针对同一个OTA客户端（如OTA客户端1）有多个ECU（如ECU1、ECU2和ECU3）需要进行刷写升级的场景。若需要实现对该OTA客户端1的三个ECU（ECU1、ECU2和ECU3）的并行刷写，则可以通过创建三个内部客户端1、2、3，并将OTA客户端1拆分成三个子OTA客户端1-1、1-2和1-3，其中，子OTA客户端1-1、1-2和1-3的源地址（即OTA客户端逻辑地址）均相同，例如，为“0x0F00”；ECU1、ECU2和ECU3的全域唯一逻辑地址不同，例如，分别为“0x0701、0x0702和0x0703”。内部客户端1、2、3分别与子OTA客户端1-1、1-2和1-3连接。与ECU1、ECU2和ECU3对应的升级数据包1、2、3分别由子OTA客户端1-1、1-2和1-3上传给内部客户端1、2、3。内部客户端1、2、3将接收到的升级数据包1、2、3转发给内部服务端，再由内部服务端将接收到的升级数据包转存至公用传输通道的共享内存空间（即“SHARE MEMORY”）中。对外客户端通过实时读取共享内存空间中的升级数据包1、2、3，并转发给网关服务端105。
作为另一示例，针对多个不同OTA客户端（如OTA客户端1~10，它们的源地址分别为“0x0F00~0x0F10”）有多个ECU（如ECU1~10，其中，ECU1~10分别对应的是OTA客户端1~10，即一个OTA客户端对应有一个ECU需要刷写升级）需要进行刷写升级的场景。首先，可创建10个内部客户端1~10，内部客户端1~10分别与OTA客户端1~10一一对应连接。内部客户端1~10分别接收与之连接的OTA客户端1~10上传的升级数据包1~10，并将升级数据包1~10转发给内部服务端，再由内部服务端将接收到的升级数据包转存至公用传输通道的共享内存空间中。对外客户端通过实时读取共享内存空间中的升级数据包1~10，并转发给网关服务端105。
作为又一示例，针对多个不同OTA客户端（如OTA客户端1、2、3），每个OTA客户端有至少一个ECU（如OTA客户端1的ECU1需要进行刷写，OTA客户端2的ECU2、3需要进行刷写，OTA客户端3的ECU4、5需要进行刷写）需要进行刷写升级的场景。可创建5个内部客户端1~5，OTA客户端2可拆分成OTA客户端2-1、OTA客户端2-2，OTA客户端3可拆分成OTA客户端3-1和OTA客户端3-2。内部客户端1~5分别对应连接OTA客户端1、OTA客户端2-1、OTA客户端2-2、OTA客户端3-1和OTA客户端3-2。OTA客户端1将升级数据包1（对应ECU1）上传至内部服务端，OTA客户端2-1将升级数据包2（对应ECU2）上传至内部服务端，OTA客户端2-2将升级数据包3（对应ECU3）上传至内部服务端，OTA客户端3-1将升级数据包4（对应ECU4）上传至内部服务端，OTA客户端3-2将升级数据包5（对应ECU5）上传至内部服务端，再由内部服务端将接收到的升级数据包转存至公用传输通道的共享内存空间中。对外客户端通过实时读取共享内存空间中的升级数据包1~5，并转发给网关服务端105。
在本申请实施例中，根据需要刷写的ECU的全域唯一逻辑地址或者OTA客户端的源地址确定需要创建的OTA客户端、内部客户端数量；之后，建立各个OTA客户端与内部客户端之间的通信连接；然后，各个OTA客户端将其需要上传的升级数据包发送给对应的内部客户端，再由各个内部客户端先转发给内部服务端，之后由内部服务端再转存至该公用传输通道的共享内存空间中，以便于对外客户端实时读取并将读取到的升级数据包转发至网关服务端。整个数据转发过程的安全性较好。
在另一些实施例中，该公用传输通道包括一个对外客户端。在上述步骤S205中，经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，具体包括：
将每一个OTA客户端上传的升级数据包存储至公用传输通道的共享内存空间中；
对外客户端实时读取共享内存空间中的升级数据包并转发至网关服务端。
作为一示例，针对同一个OTA客户端（如OTA客户端1）有多个ECU（如ECU1、ECU2和ECU3）需要进行刷写升级的场景。首先，可将OTA客户端1拆分成OTA客户端1-1、1-2和1-3，OTA客户端1-1直接上传升级数据包1（对应ECU1）至公用传输通道的共享内存空间中；OTA客户端1-2直接上传升级数据包2（对应ECU2）至公用传输通道的共享内存空间中；OTA客户端1-3直接上传升级数据包3（对应ECU3）至公用传输通道的共享内存空间中。对外客户端实时读取共享内存空间中的升级数据包1、2、3并转发给网关服务端。
在本申请实施例中，通过多个OTA客户端直接将升级数据包上传至公用传输通道的共享内存空间，再经由对外客户端实时读取共享内存空间中的升级数据包并转发给网关服务端的方式，可提高升级数据包的转发效率，有利于进一步提升后续的多个ECU并行刷写效率，从而快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，进而提升用户对产品的使用体验，并降低OTA升级的成本。
图4是本申请实施例提供的另一种公用传输通道的结构示意图。如图4所示，该公用传输通道包括多个对外子客户端；每一个对外子客户端与至少一个OTA客户端连接，每一个对外子客户端所连接的OTA客户端不重复；每一个对外子客户端均与网关服务端105连接。
其中，图4中的“SOCKET CLIENT1~SOCKETCLIENTn”表示对外子客户端1~n，n为≥2的正整数。
在一实施例中，在公用传输通道内部，多个对外子客户端可分别采用不同的TCPsocket，每个外部客户端可与至少一个OTA客户端连接。多个对外子客户端可以采用统一的TCP socket与网关服务端的TCP socket绑定，以实现数据的外发。多个对外子客户端在内部所采用的TCP socket，外部不感知（如网关服务端不感知）。
在另一实施例中，多个对外子客户端可分别采用不同的TCP socket，且各个对外子客户端均使用其TCP socket与网关服务端的TCP socket绑定。
图5是本申请实施例提供的又一种公用传输通道的结构示意图。如图5所示，该公用传输通道包括多个内部客户端、多个内部服务端和多个对外子客户端。其中，一个内部服务端与多个内部客户端连接，且与一个对外子客户端连接。多个内部服务端和多个对外子客户端的数量相同。
在一些实施例中，该公用传输通道还可以设置成如下结构：包括多个内部客户端、多个内部服务端和多个对外子客户端。其中，一个内部服务端与多个内部客户端连接，且与一个对外子客户端连接。多个内部服务端和多个对外子客户端的数量不相同。例如，公用传输通道中创建有2个对外子客户端1、2，对外子客户端1与一个内部服务端1连接，内部服务端1与内部客户端1、2、3连接，内部客户端1、2、3分别与OTA客户端1、2、3连接；对外子客户端2与OTA客户端1、2、3连接。
在本申请实施例中，通过在公用传输通道创建多个对外子客户端，每一个对外子客户端可与至少至少一个OTA客户端连接，可以极大地扩充公用传输通道所能连接的OTA客户端的数量。一般情况下，一个对外子客户端可以对应连接1024个OTA客户端，采用这种结构，可以将公用传输通道所能连接的OTA客户端的数量扩充至1024*n个，n为≥1的正整数，由此可以满足更多的ECU的并行刷写需求，进一步提升OTA刷写升级的效率，从而快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，进而提升用户对产品的使用体验，并降低OTA升级的成本。
在一些实施例中，结合图4，在上述步骤S205中，经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，具体包括：
将每一个OTA客户端上传的升级数据包存储至公用传输通道的共享内存空间中；
每一个对外子客户端从共享内存空间中实时读取与之连接的OTA客户端上传的升级数据包，并转发至网关服务端。
结合图4，作为一示例，针对多个不同的OTA客户端（如OTA客户端1、2、3）有多个ECU（如OTA客户端1有ECU1、2、3共三个ECU需要刷写，OTA客户端2有ECU4、5共两个ECU需要刷写，OTA客户端3有ECU6、7共两个ECU需要刷写）需要进行刷写升级的场景。假设公用传输通道中创建有3个对外子客户端1、2、3，可将OTA客户端1拆分成OTA客户端1-1、1-2和1-3，将OTA客户端2拆分成OTA客户端2-1和2-2，将将OTA客户端3拆分成OTA客户端3-1和3-2。其中，OTA客户端1-1、1-2和1-3分别与对外子客户端1连接，OTA客户端2-1和2-2分别与对外子客户端2连接，OTA客户端3-1和3-2分别与对外子客户端3连接。OTA客户端1-1直接上传升级数据包1（对应ECU1）至公用传输通道的共享内存空间中；OTA客户端1-2直接上传升级数据包2（对应ECU2）至公用传输通道的共享内存空间中；OTA客户端1-3直接上传升级数据包3（对应ECU3）至公用传输通道的共享内存空间中，OTA客户端2-1直接上传升级数据包4（对应ECU4）至公用传输通道的共享内存空间中，OTA客户端2-2直接上传升级数据包5（对应ECU5）至公用传输通道的共享内存空间中，OTA客户端3-1直接上传升级数据包6（对应ECU6）至公用传输通道的共享内存空间中，OTA客户端3-2直接上传升级数据包7（对应ECU7）至公用传输通道的共享内存空间中。对外客户端1实时读取共享内存空间中的升级数据包1、2、3并转发给网关服务端。对外客户端2实时读取共享内存空间中的升级数据包4、5并转发给网关服务端。对外客户端3实时读取共享内存空间中的升级数据包6、7并转发给网关服务端。
在一些实施例中，在上述步骤S205中，网关服务端，对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，具体包括：
提取出每一个升级数据包中的全域唯一逻辑地址，确定与全域唯一逻辑地址对应的目标ECU；
确定每一个升级数据包对应的目标ECU所支持的诊断协议，诊断协议为第一诊断协议或第二诊断协议；
若目标ECU支持第一诊断协议，则直接将升级数据包转发至与之对应的目标ECU；
若目标ECU支持第二诊断协议，则获取第二诊断协议对应的数据帧结构，数据帧结构包括请求标识部分、诊断报文部分和其他部分；
提取出升级数据包中的诊断报文；
将升级数据包对应的全域唯一逻辑地址填充至请求标识部分的位置，将诊断报文填充至诊断报文部分，按照第二诊断协议的数据帧标准填充完整其他部分，得到转换数据包；其中，填充至诊断报文部分的诊断报文包括OTA升级主控端的源地址、全域唯一逻辑地址、OTA客户端的IP地址、OTA客户端的源端口以及刷写升级数据；
将转换数据包转发至对应的目标ECU。
第一诊断协议，为遵循ISO13400-2标准的DOIP（（Diagnostic communicationoverInternet Protocol））协议。
第二诊断协议，为CAN总线协议或CAN-FD总线协议。
第一诊断协议对应的数据帧结构如下表1所示，第二诊断协议对应的数据帧结构如下表2所示。
表1
表2
第二诊断协议对应的数据帧结构中的请求标识部分是表2中的“CANID”字段所对应的位置，即“请求ID”，诊断报文部分是表2中的“UDS数据”字段所对应的位置，其他部分是表2中除了请求标识部分和诊断报文部分之外的位置。
升级数据包中的诊断报文，即表1中的第一诊断协议对应的数据帧结构中的DOIP数据字段所对应的UDS数据。“SA”字段对应的是OTA客户端的源地址，“TA”字段对应的是全域唯一逻辑地址（即ECU目标地址）。
结合图6，填充至诊断报文部分的诊断报文包括OTA升级主控端的源地址（即“OTAUMC源地址”）、全域唯一逻辑地址（即ECU目标地址）、OTA客户端的IP地址（即OTA CLIENT源IP地址）、OTA客户端的源端口（即OTA CLIENT源端口）以及刷写升级数据。其中，OTA CLIENT源IP地址，在内部区分多个不同的OTA客户端，外部不感知。OTA CLIENT源端口，在内部区分多个不同的OTA客户端，外部不感知。
其中，图6中的“Eth Frame”为遵循IEEE802.3协议的数据帧结构。“DOIP报文”为遵循ISO13400-2标准的DOIP协议的数据帧结构。图6中的最后一个表格对应的是本申请实施例用于封装升级数据包中的刷写升级数据的数据结构帧。
在一实施例中，网关服务端在接收到OTA升级主控(UMC)的对外客户端转发的升级数据包时，先检查升级数据包的完整性，若升级数据包完整，则对该升级数据包进行解析，以获取其中的全域唯一逻辑地址；再判断该全域唯一逻辑地址所对应的目标ECU所支持的诊断协议。若该升级数据包支持第一诊断协议，则直接将该升级数据包转发给该目标ECU。若该升级数据包支持第二诊断协议，则将提取到的全域唯一逻辑地址填充至第二诊断协议对应的数据帧结构中的请求标识部分，即“请求ID”处，并将从第一诊断协议对应的数据帧结构中的DOIP数据字段所对应的UDS数据复制并填充至第二诊断协议对应的数据帧结构中的“UDS数据”字段所对应的位置，其他部分则遵循第二诊断协议的数据帧标准来填充完整，即得到转换数据包，最后，将该转换数据包转发给目标ECU。
结合表1、表2，若是需要将第二诊断协议对应的数据帧结构转换为第一诊断协议对应的数据帧结构，则将第二诊断协议对应的数据帧结构中的“应答ID”提取出来并填充至第一诊断协议对应的数据帧结构中的“SA”字段所对应的位置，并将第二诊断协议对应的数据帧结构中的“UDS数据”提取出来填充至第一诊断协议对应的数据帧结构中的“DOIP数据”字段所对应的位置，其余部分则遵循第一诊断协议的数据帧标准来填充完整，即可。
在本申请实施例中，网关服务端在接收到UMC转发过来的升级数据包后，对升级数据包进行解析，以提取出其中的全域唯一逻辑地址，再根据该全域唯一逻辑地址确定目标ECU，接着，诊断目标ECU所支持的诊断协议，并根据目标ECU所支持的诊断协议确定是否需要执行数据帧结构之间的转换操作；若不需要转换，则直接将升级数据包转发至目标ECU；若需要转换，则先执行数据帧结构的转换，得到转换数据包，再将转换数据包转发至目标ECU，可避免目标ECU因无法读取相关的升级数据而导致刷写失败的问题。与此同时，采用特殊设计的数据结构来封装诊断报文，其中，诊断报文中的OTA CLIENT源IP地址和OTACLIENT源端口，在内部区分多个不同的OTA客户端，外部不感知，可在只建立一个TCPsocket客户端与GW的TCP socket服务端相连接的基础上，实现对车辆功能域间或域内的多个ECU的并行刷写，极大地提升刷写的效率。
结合图7，在一示例中，假设在TBOX的UMC中同一个OTA客户端有n个ECU需要并行刷写，可先将OTA客户端拆分成OTA客户端1~n，记为CLIENT1、CLIENT2...CLIENTn。其中，CLIENT1、CLIENT2...CLIENTn的IP地址和端口号分别为192.168.10.101、55001，192.168.10.102、55002，192.168.10.1xx、5500x，OTA客户端1~n的逻辑地址（源地址）固定为0x0F00，ECU1、ECU2...ECUn的逻辑地址（即全域唯一逻辑地址）分别为0x0701、0x0702...0x070n，UMC的内部服务端（即内部socket server）的IP地址为192.168.10.224，与网关服务端相连的UMC的对外客户端（即TCP socket client）的IP地址为192.168.10.2，需要实现同时对ECU1、ECU2...ECUn进行并行升级刷写。
可先创建CLIENT1、CLIENT2...CLIENTn与UMC的内部客户端相连，CLIENT1、CLIENT2...CLIENTn将其升级数据包上传至内部客户端，内部客户端收到升级数据包后，将这些升级数据包转发至内部服务端，内部服务端再将这些升级数据包转发至公用传输通道的共享内存空间中，再由对外客户端实时读取这些升级数据包，并将这些升级数据包转发至网关服务端，网关服务端收到升级数据包后，通过UA解析升级数据包，提取其中的全域唯一逻辑地址，发现全域唯一逻辑地址为0x701、0x702......0x070n，将升级数据包分别发给ECU1（接收CLIENT1上传的升级数据包）、ECU2（接收CLIENT2上传的升级数据包）...ECUn（接收CLIENTn上传的升级数据包），以使ECU1、ECU2...ECUn进行升级刷写。
上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。
图8是本申请实施例提供的一种多个ECU并行刷写方法的时序图。如图8所示，该多个ECU并行刷写方法包括：
步骤S801、OTA升级主控端（UMC），通过联网和直连发现车辆，并创建车辆列表，创建套接字（即socket）。
步骤S802、OTA升级代理(UA)，创建TCP数据套接字（即TCP DATA socket），并将该TCP数据套接字与UMC创建的套接字进行绑定。
步骤S803、UMC在接收OTA客户端选定的车辆后，连接到OTA升级代理(UA)创建的TCP数据套接字。
步骤S804、UA初始化与UMC绑定的套接字链接，初始化后即成功建立起公用传输通道。
步骤S805，UMC经由公用传输通道向UA发送路由激活请求，路由激活请求携带有OTA客户端的源地址。
步骤S806，UA在执行完毕通用的DOIP报头处理程序和路由激活处理程序后，向UMC返回成功激活响应信息。
步骤S807，UMC在接收到UA返回的成功激活响应信息时，向OTA客户端发送路由激活成功的提示信息，以提示OTA客户端上传升级数据包。
步骤S808，UMC在接收到OTA客户端上传的升级数据包时，将该升级数据包发送给UA。
步骤S809，UA在接收到UMC转发的升级数据包后，对该升级数据包进行解析和诊断，以确定目标ECU（OTA升级从控，简称“US”）。
步骤S810，UA将升级数据包发送给目标ECU。
步骤S811，UMC在接收到OTA客户端发送的注销申请时，关闭TCP 套接字，并向UA发送关闭TCP套接字请求。
步骤S812，UA在接收到UMC发送的关闭TCP套接字请求时，结束DOIP会话。
下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。
图9是本申请实施例提供的一种多个ECU并行刷写装置的结构示意图。如图9所示，该多个ECU并行刷写装置包括：
建立模块901，被配置为建立多个OTA客户端与网关服务端之间的公用传输通道；
发送模块902，被配置为在成功建立起公用传输通道后，经由公用传输通道向网关服务端发送路由激活请求，路由激活请求携带有每一个OTA客户端的源地址；
信息发送模块903，被配置为在接收到网关服务端针对路由激活请求返回的成功激活响应信息时，向每一个OTA客户端发送路由激活成功的提示信息，以提示OTA客户端上传升级数据包；
接收模块904，被配置为接收每一个OTA客户端上传的升级数据包，升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址；
转发模块905，被配置为经由公用传输通道，将每一个OTA客户端发送的升级数据包均转发至网关服务端，以使网关服务端对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，以使各个目标ECU基于接收到的升级数据包对其原数据包进行刷写升级。
本申请实施例提供的技术方案，通过上述装置，可以实现多个OTA客户端与网关服务端之间的数据同步传输，并且每个OTA客户端上传的升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址，即一个升级数据包对应一个目标ECU；经由该公共传输通道将各个OTA客户端上传的升级数据包转发至网关服务端，再由网关服务端进行解析和诊断后转发至相应的目标ECU进行升级刷写，不仅可实现对多个不同车辆功能域间的ECU的并行刷写，还可以实现对同一个车辆功能域内的多个ECU的并行刷写，极大地缩短了升级刷写的时间，可快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，从而提升用户对产品的使用体验，同时还可明显降低OTA升级的成本。
在一些实施例中，公用传输通道包括多个内部客户端、一个内部服务端和一个对外客户端；多个内部客户端与多个OTA客户端的数量相同，一个内部客户端对应与一个OTA客户端连接；每一个内部客户端均与内部服务端连接；内部服务端与对外客户端连接；对外客户端与网关服务端连接。
在一些实施例中，在上述公用传输通道中：
每一个内部客户端在接收与其通信连接的OTA客户端上传的升级数据包时，将接收到的升级数据包转发给内部服务端；
内部服务端将接收到的升级数据包转存至公用传输通道的共享内存空间中；
对外客户端实时读取共享内存空间中的升级数据包并转发至网关服务端。
本申请实施例提供的公用传输通道，包括多个内部客户端、一个内部服务端和一个对外客户端；多个内部客户端分别与一个OTA客户端连接，用于接收各个OTA客户端上传的升级数据包，之后，将接收到的升级数据包转发给内部服务端，之后由内部服务端再转存至该公用传输通道的共享内存空间中，以便于对外客户端实时读取并将读取到的升级数据包转发至网关服务端。整个数据的转发过程的安全性较好。
在另一些实施例中，公用传输通道包括一个对外客户端。
在该公用传输通道中：
将每一个OTA客户端上传的升级数据包存储至公用传输通道的共享内存空间中；
对外客户端实时读取共享内存空间中的升级数据包并转发至网关服务端。
在本申请实施例中，多个OTA客户端可直接将升级数据包上传至公用传输通道的共享内存空间，再经由对外客户端实时读取共享内存空间中的升级数据包并转发给网关服务端的方式，可提高升级数据包的转发效率，有利于进一步提升后续的多个ECU并行刷写效率，从而快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，进而提升用户对产品的使用体验，并降低OTA升级的成本。
在又一些实施例中，公用传输通道包括多个对外子客户端；每一个对外子客户端与至少一个OTA客户端连接，每一个对外子客户端所连接的OTA客户端不重复；每一个对外子客户端均与网关服务端连接。
在上述公用传输通道中：
将每一个OTA客户端上传的升级数据包存储至公用传输通道的共享内存空间中；
每一个对外子客户端从共享内存空间中实时读取与之连接的OTA客户端上传的升级数据包，并转发至网关服务端。
在本申请实施例中，通过在公用传输通道创建多个对外子客户端，每一个对外子客户端可与至少至少一个OTA客户端连接，可以极大地扩充公用传输通道所能连接的OTA客户端的数量。一般情况下，一个对外子客户端可以对应连接1024个OTA客户端，采用这种结构，可以将公用传输通道所能连接的OTA客户端的数量扩充至1024*n个，n为≥1的正整数，由此可以满足更多的ECU的并行刷写需求，进一步提升OTA刷写升级的效率，从而快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，进而提升用户对产品的使用体验，并降低OTA升级的成本。
在一些实施例中，上述网关服务端包括：
第一提取模块，被配置为提取出每一个升级数据包中的全域唯一逻辑地址，确定与全域唯一逻辑地址对应的目标ECU；
确定模块，被配置为确定每一个升级数据包对应的目标ECU所支持的诊断协议，诊断协议为第一诊断协议或第二诊断协议；
第一转发模块，被配置为若目标ECU支持第一诊断协议，则直接将升级数据包转发至与之对应的目标ECU；
获取模块，被配置为若目标ECU支持第二诊断协议，则获取第二诊断协议对应的数据帧结构，数据帧结构包括请求标识部分、诊断报文部分和其他部分；
第二提取模块，被配置为提取出升级数据包中的诊断报文；
转换模块，被配置为将升级数据包对应的全域唯一逻辑地址填充至请求标识部分的位置，将诊断报文填充至诊断报文部分，按照第二诊断协议的数据帧标准填充完整其他部分，得到转换数据包；其中，填充至诊断报文部分的诊断报文包括OTA升级主控端的源地址、全域唯一逻辑地址、OTA客户端的IP地址、OTA客户端的源端口以及刷写升级数据；
第二转发模块，被配置为将转换数据包转发至对应的目标ECU。
在本申请实施例中，网关服务端在接收到UMC转发过来的升级数据包后，通过第一提取模块对升级数据包进行解析，以提取出其中的全域唯一逻辑地址，再根据该全域唯一逻辑地址确定目标ECU，接着，通过确定模块诊断目标ECU所支持的诊断协议，并根据目标ECU所支持的诊断协议确定是否需要执行数据帧结构之间的转换操作；若不需要转换，则通过第一转发模块直接将升级数据包转发至目标ECU；若需要转换，则通过转换模块先执行数据帧结构的转换，得到转换数据包，再通过第二转发模块将转换数据包转发至目标ECU，可避免目标ECU因无法读取相关的升级数据而导致刷写失败的问题。与此同时，采用特殊设计的数据结构来封装诊断报文，其中，诊断报文中的OTA CLIENT源IP地址和OTA CLIENT源端口，在内部区分多个不同的OTA客户端，外部不感知，可在只建立一个TCP socket客户端与GW的TCP socket服务端相连接的基础上，实现对车辆功能域间或域内的多个ECU的并行刷写，极大地提升刷写的效率。
图10是本申请实施例提供的一种多个ECU并行刷写系统的结构示意图。如图10所示，该多个ECU并行刷写系统包括：
承载于远程信息处理器（TBOX）104中的OTA升级主控端（UMC）；
与所述OTA升级主控端通信连接的网关服务端105；
所述OTA升级主控端包括如图9所示的多个ECU并行刷写装置。
在本申请实施例中，远程信息处理器（TBOX）104可利用承载在其中的OTA升级主控端（UMC）建立多个OTA客户端与网关服务端105之间的公用传输通道；在成功建立起它们之间的公用传输通道后，UMC可经由该公用传输通道向网关服务端105发送路由激活请求；在接收到网关服务端105针对该路由激活请求返回的成功激活响应信息时，向每一个OTA客户端发送路由激活成功的提示信息，以提示OTA客户端上传升级数据包；UMC在接收到OTA客户端上传的升级数据包时，再经由该公用传输通道，将接收到的升级数据包均转发至网关服务端105；网关服务端105在接收到这些升级数据包之后，会对每一个升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU；各个目标ECU在接收到升级数据包后，利用该升级数据包对其原数据包进行刷写升级。通过上述方式，不仅可实现对多个不同车辆功能域间的ECU的并行刷写，还可以实现对同一个车辆功能域内的多个ECU的并行刷写，极大地缩短了升级刷写的时间，可快速修复车辆系统的缺陷，实现产品（车辆固件和软件）的快速迭代、提升产品的质量，从而提升用户对产品的使用体验，同时还可明显降低OTA升级的成本。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
图11是本申请实施例提供的电子设备11的示意图。如图11所示，该实施例的电子设备11包括：处理器1101、存储器1102以及存储在该存储器1102中并且可在处理器1101上运行的计算机程序1103。处理器1101执行计算机程序1103时实现上述各个方法实施例中的步骤。或者，处理器1101执行计算机程序1103时实现上述各装置实施例中各模块/单元的功能。
电子设备11可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备11可以包括但不仅限于处理器1101和存储器1102。本领域技术人员可以理解，图11仅仅是电子设备11的示例，并不构成对电子设备11的限定，可以包括比图示更多或更少的部件，或者不同的部件。
处理器1101可以是中央处理单元（Central Processing Unit，CPU），也可以是其它通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application SpecificIntegrated Circuit，ASIC）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
存储器1102可以是电子设备11的内部存储单元，例如，电子设备11的硬盘或内存。存储器1102也可以是电子设备11的外部存储设备，例如，电子设备11上配备的插接式硬盘，智能存储卡（Smart Media Card，SMC），安全数字（Secure Digital，SD）卡，闪存卡（FlashCard）等。存储器1102还可以既包括电子设备11的内部存储单元也包括外部存储设备。存储器1102用于存储计算机程序以及电子设备所需的其它程序和数据。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。
Claims (8)
1.一种多个ECU并行刷写方法，其特征在于，包括：
建立多个OTA客户端与网关服务端之间的公用传输通道；
在成功建立起所述公用传输通道后，经由所述公用传输通道向所述网关服务端发送路由激活请求，所述路由激活请求携带有每一个所述OTA客户端的源地址；
在接收到所述网关服务端针对所述路由激活请求返回的成功激活响应信息时，向每一个所述OTA客户端发送路由激活成功的提示信息，以提示所述OTA客户端上传升级数据包；
接收每一个所述OTA客户端上传的升级数据包，所述升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址；
经由所述公用传输通道，将每一个所述OTA客户端发送的升级数据包均转发至所述网关服务端，以使所述网关服务端对每一个所述升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，以使各个所述目标ECU基于接收到的升级数据包对其原数据包进行刷写升级；
所述公用传输通道包括多个内部客户端、一个内部服务端和一个对外客户端；所述多个内部客户端与所述多个OTA客户端的数量相同，一个内部客户端对应与一个OTA客户端连接；每一个所述内部客户端均与所述内部服务端连接；所述内部服务端与所述对外客户端连接；所述对外客户端与所述网关服务端连接；
或者，
所述公用传输通道包括多个对外子客户端；每一个所述对外子客户端与至少一个OTA客户端连接，每一个所述对外子客户端所连接的OTA客户端不重复；每一个所述对外子客户端均与所述网关服务端连接；
或者，
所述公用传输通道包括多个内部客户端、多个内部服务端和多个对外子客户端；其中，一个内部服务端与多个内部客户端连接，且与一个对外子客户端连接；多个内部服务端和多个对外子客户端的数量相同。
2.根据权利要求1所述的方法，其特征在于，经由所述公用传输通道，将每一个所述OTA客户端发送的升级数据包均转发至所述网关服务端，包括：
每一个所述内部客户端在接收与其通信连接的OTA客户端上传的升级数据包时，将接收到的升级数据包转发给所述内部服务端；
所述内部服务端将接收到的升级数据包转存至所述公用传输通道的共享内存空间中；
所述对外客户端实时读取所述共享内存空间中的升级数据包并转发至所述网关服务端。
3.根据权利要求1所述的方法，其特征在于，所述公用传输通道包括一个对外客户端；
经由所述公用传输通道，将每一个所述OTA客户端发送的升级数据包均转发至所述网关服务端，包括：
将每一个所述OTA客户端上传的升级数据包存储至所述公用传输通道的共享内存空间中；
所述对外客户端实时读取所述共享内存空间中的升级数据包并转发至所述网关服务端。
4.根据权利要求1所述的方法，其特征在于，经由所述公用传输通道，将每一个所述OTA客户端发送的升级数据包均转发至所述网关服务端，包括：
将每一个所述OTA客户端上传的升级数据包存储至所述公用传输通道的共享内存空间中；
每一个所述对外子客户端从所述共享内存空间中实时读取与之连接的OTA客户端上传的升级数据包，并转发至所述网关服务端。
5.根据权利要求1所述的方法，其特征在于，对每一个所述升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，包括：
提取出每一个升级数据包中的全域唯一逻辑地址，确定与所述全域唯一逻辑地址对应的目标ECU；
确定每一个升级数据包对应的目标ECU所支持的诊断协议，所述诊断协议为第一诊断协议或第二诊断协议；
若所述目标ECU支持第一诊断协议，则直接将所述升级数据包转发至与之对应的目标ECU；
若所述目标ECU支持第二诊断协议，则获取所述第二诊断协议对应的数据帧结构，所述数据帧结构包括请求标识部分、诊断报文部分和其他部分；
提取出所述升级数据包中的诊断报文；
将所述升级数据包对应的全域唯一逻辑地址填充至所述请求标识部分的位置，将所述诊断报文填充至所述诊断报文部分，按照所述第二诊断协议的数据帧标准填充完整所述其他部分，得到转换数据包；其中，填充至所述诊断报文部分的诊断报文包括OTA升级主控端的源地址、全域唯一逻辑地址、OTA客户端的IP地址、OTA客户端的源端口以及刷写升级数据；
将所述转换数据包转发至对应的目标ECU。
6.一种多个ECU并行刷写装置，其特征在于，包括：
建立模块，被配置为建立多个OTA客户端与网关服务端之间的公用传输通道；
发送模块，被配置为在成功建立起所述公用传输通道后，经由所述公用传输通道向所述网关服务端发送路由激活请求，所述路由激活请求携带有每一个所述OTA客户端的源地址；
信息发送模块，被配置为在接收到所述网关服务端针对所述路由激活请求返回的成功激活响应信息时，向每一个所述OTA客户端发送路由激活成功的提示信息，以提示所述OTA客户端上传升级数据包；
接收模块，被配置为接收每一个所述OTA客户端上传的升级数据包，所述升级数据包中包含有用于区分任一个车辆功能域内的任一个ECU的全域唯一逻辑地址；
转发模块，被配置为经由所述公用传输通道，将每一个所述OTA客户端发送的升级数据包均转发至所述网关服务端，以使所述网关服务端对每一个所述升级数据包进行解析和诊断，以确定每个升级数据包对应的目标ECU，并将每个升级数据包分发至对应的目标ECU，以使各个所述目标ECU基于接收到的升级数据包对其原数据包进行刷写升级；
所述公用传输通道包括多个内部客户端、一个内部服务端和一个对外客户端；所述多个内部客户端与所述多个OTA客户端的数量相同，一个内部客户端对应与一个OTA客户端连接；每一个所述内部客户端均与所述内部服务端连接；所述内部服务端与所述对外客户端连接；所述对外客户端与所述网关服务端连接；
或者，
所述公用传输通道包括多个对外子客户端；每一个所述对外子客户端与至少一个OTA客户端连接，每一个所述对外子客户端所连接的OTA客户端不重复；每一个所述对外子客户端均与所述网关服务端连接；
或者，
所述公用传输通道包括多个内部客户端、多个内部服务端和多个对外子客户端；其中，一个内部服务端与多个内部客户端连接，且与一个对外子客户端连接；多个内部服务端和多个对外子客户端的数量相同。
7.一种多个ECU并行刷写系统，其特征在于，包括：
OTA升级主控端；
与所述OTA升级主控端通信连接的网关服务端；
所述OTA升级主控端包括如权利要求6所述的多个ECU并行刷写装置。
8.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310652803.4A CN116382744B (zh) | 2023-06-05 | 2023-06-05 | 多个ecu并行刷写方法、装置、系统及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310652803.4A CN116382744B (zh) | 2023-06-05 | 2023-06-05 | 多个ecu并行刷写方法、装置、系统及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116382744A CN116382744A (zh) | 2023-07-04 |
| CN116382744B true CN116382744B (zh) | 2023-08-04 |
Family
ID=86975431
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310652803.4A Active CN116382744B (zh) | 2023-06-05 | 2023-06-05 | 多个ecu并行刷写方法、装置、系统及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116382744B (zh) |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109828935A (zh) * | 2019-01-17 | 2019-05-31 | 重庆菲斯塔新能源汽车科技有限公司 | 一种基于can fd总线的并行刷写方法 |
| CN110032382A (zh) * | 2019-03-25 | 2019-07-19 | 深圳猛犸电动科技有限公司 | 一种汽车电子控制单元升级方法、系统及终端设备 |
| CN111277477A (zh) * | 2020-01-13 | 2020-06-12 | 重庆邮电大学 | 一种支持车载多网段同时升级的fota系统 |
| CN111930407A (zh) * | 2020-10-19 | 2020-11-13 | 广州汽车集团股份有限公司 | 车辆ecu软件升级方法、系统、车载tbox的微控制器和soc端 |
| CN112040443A (zh) * | 2020-08-31 | 2020-12-04 | 经纬恒润(天津)研究开发有限公司 | 多客户端ota升级处理方法及系统 |
| CN112261130A (zh) * | 2020-10-21 | 2021-01-22 | 宝能(广州)汽车研究院有限公司 | 车辆、车辆的ota升级系统及方法 |
| CN112463190A (zh) * | 2020-11-24 | 2021-03-09 | 广州橙行智动汽车科技有限公司 | 一种车辆升级方法和装置 |
| CN113672254A (zh) * | 2021-07-30 | 2021-11-19 | 北京三快在线科技有限公司 | 车辆ota升级方法、装置、存储介质和无人驾驶设备 |
| CN114880002A (zh) * | 2022-07-12 | 2022-08-09 | 江铃汽车股份有限公司 | 一种ota数据刷写方法及系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11829748B1 (en) * | 2021-09-29 | 2023-11-28 | Geotab Inc. | Systems and methods for safe over-the-air update of electronic control units in vehicles |
-
2023
- 2023-06-05 CN CN202310652803.4A patent/CN116382744B/zh active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109828935A (zh) * | 2019-01-17 | 2019-05-31 | 重庆菲斯塔新能源汽车科技有限公司 | 一种基于can fd总线的并行刷写方法 |
| CN110032382A (zh) * | 2019-03-25 | 2019-07-19 | 深圳猛犸电动科技有限公司 | 一种汽车电子控制单元升级方法、系统及终端设备 |
| CN111277477A (zh) * | 2020-01-13 | 2020-06-12 | 重庆邮电大学 | 一种支持车载多网段同时升级的fota系统 |
| CN112040443A (zh) * | 2020-08-31 | 2020-12-04 | 经纬恒润(天津)研究开发有限公司 | 多客户端ota升级处理方法及系统 |
| CN111930407A (zh) * | 2020-10-19 | 2020-11-13 | 广州汽车集团股份有限公司 | 车辆ecu软件升级方法、系统、车载tbox的微控制器和soc端 |
| CN112261130A (zh) * | 2020-10-21 | 2021-01-22 | 宝能(广州)汽车研究院有限公司 | 车辆、车辆的ota升级系统及方法 |
| CN112463190A (zh) * | 2020-11-24 | 2021-03-09 | 广州橙行智动汽车科技有限公司 | 一种车辆升级方法和装置 |
| CN113672254A (zh) * | 2021-07-30 | 2021-11-19 | 北京三快在线科技有限公司 | 车辆ota升级方法、装置、存储介质和无人驾驶设备 |
| CN114880002A (zh) * | 2022-07-12 | 2022-08-09 | 江铃汽车股份有限公司 | 一种ota数据刷写方法及系统 |
Non-Patent Citations (1)
| Title |
|---|
| 基于车辆OTA功能的整车电检系统预研;吕小磊 等;《汽车工艺与材料》(第6期);第42-46页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116382744A (zh) | 2023-07-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8417860B2 (en) | Hybrid in-vehicle infotainment network | |
| JP6611921B2 (ja) | 端末の相互接続方法、装置、不揮発性コンピュータ記憶媒体及びコンピュータプログラム | |
| CN110166432A (zh) | 对内网目标服务的访问方法、提供内网目标服务的方法 | |
| CN105282209B (zh) | 车辆用网络系统和其中异构通信控制器的数据传输方法 | |
| US10511668B2 (en) | Method of transmitting and receiving data in vehicle network and apparatus for the same | |
| CN111586145B (zh) | 一种车辆诊断方法、系统及电子设备和存储介质 | |
| CN110225071A (zh) | 车载智能网关及汽车 | |
| CN111865742B (zh) | 车辆及车内消息传输方法 | |
| US20170048158A1 (en) | Operation method of communication node in network | |
| CN113141306A (zh) | 一种诊断报文路由方法及其总线路由设备 | |
| CN110177010B (zh) | 一种链路切换方法及装置 | |
| KR20200143961A (ko) | 차량 진단 통신 장치, 그를 포함한 시스템 및 그 방법 | |
| CN114629742B (zh) | 用于新能源电动汽车的车辆数据通信仿真测试平台和方法 | |
| JP2013141283A (ja) | 進化型ワイヤレスネットワークにおけるｉｐアドレス割り当て | |
| CN117376339A (zh) | 基于ota的车辆ecu升级方法、装置、设备及介质 | |
| CN207926649U (zh) | 车载智能网关及汽车 | |
| CN116382744B (zh) | 多个ecu并行刷写方法、装置、系统及存储介质 | |
| CN110430478B (zh) | 组网通信方法、装置、终端设备及存储介质 | |
| CN113485920A (zh) | 实现DoIP实体的方法、装置、可读存储介质及电子设备 | |
| KR101507562B1 (ko) | 차량에 멀티미디어 시스템을 장착하기 위한 장치 | |
| CN113285860A (zh) | 一种通过主节点刷写从节点的方法和系统 | |
| CN111741075A (zh) | 通信连接方法、车辆远程连接系统及连接设备 | |
| WO2024026592A1 (zh) | 一种数据存储方法及相关装置 | |
| US20220242338A1 (en) | Onboard communication system, switching device, and control method | |
| CN117251184A (zh) | 电子控制单元ecu的升级控制方法及设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240117 Address after: No. 13 Xingxiang Road, Zengjia Town, High tech Zone, Shapingba District, Chongqing, 400039 Patentee after: Chongqing Selis Phoenix Intelligent Innovation Technology Co.,Ltd. Address before: 610095 No. 2901, floor 29, unit 1, building 1, No. 151, Tianfu Second Street, high tech Zone, China (Sichuan) pilot Free Trade Zone, Chengdu, Sichuan Province Patentee before: Chengdu Thalys Technology Co.,Ltd. |
|
| TR01 | Transfer of patent right |