CN114978898A - 数据传输控制方法、装置、抬头显示器和存储介质 - Google Patents

Abstract

本申请实施例提供一种数据传输控制方法、装置、抬头显示器和存储介质，通过设置投影设备如HUD与主机端基于通信消息发送的数据控制信息进行更新软件包数据的传输控制，在不增加额外数据线的情况下，实现了通过图像消息进行更新软件包的数据传输，将图像消息的较强的数据传输能力利用了起来，不仅实现了更新软件包数据的有序传输，还提高了更新软件包数据的传输效率，提高了投影设备如HUD中软件的更新升级效率，进而节省了用户进行软件升级所需要的时间，提升了用户体验。

Description

数据传输控制方法、装置、抬头显示器和存储介质

技术领域

本申请实施例涉及车辆技术领域，尤其涉及一种数据传输控制方法、装置、抬头显示器和存储介质。

背景技术

随着汽车智能化的发展，抬头显示器(head up display，HUD)应用在汽车上成为可能。一种通过与车内电子控制单元(electronic control unit，ECU)连接，借助车内ECU进行图像数据生成的HUD——从属HUD(即Slave HUD)，由于其能够呈现丰富多彩的显示画面，成为目前HUD开发的重点。

软件的更新升级，作为对出厂后的电子产品的功能进行完善的一种重要手段，也被广泛应用在智能汽车上。对Slave HUD的软件升级来说，目前主要由智能汽车的云端将升级包发送给整车ECU，再由整车ECU将其分发给HUD的主机端(即与HUD相连的ECU)，由主机端对HUD进行软件的更新升级。

现有技术中，通过本地总线消息的形式进行更新软件包数据的传输，由于本地总线消息主要适用于进行如HUD显示屏的亮度、高度等控制指令数据的传输，数据传输比特率低，而更新软件包的数据量通常较大。因此，在使用现有技术的方案进行更新软件包传输时，存在传输效率低的问题，从而导致HUD的软件更新速度慢。

发明内容

本申请实施例提供一种数据传输控制方法、装置、抬头显示器和存储介质，以解决现有技术中更新软件包传输过程中存在传输效率低的问题，提高了HUD的软件更新速度。

第一方面，本申请实施例提供一种数据传输控制方法，所述方法包括：

投影设备接收主机端以通信消息的形式发送的更新软件包的数据控制信息；

基于所述数据控制信息向所述主机端请求所述更新软件包的数据；

接收所述主机端以图像消息的形式发送的所述更新软件包的数据。

其中，所述投影设备可以为抬头显示器HUD、AR-HUD或其他具有投影功能的设备；例如，当所述数据传输控制方法应用于HUD时，HUD与主机端通过高速串行链路连接，所述HUD包括解码器和中央处理器CPU，所述解码器用于对从所述主机端接收到的消息进行解码，所述CPU用于基于解码后的消息进行数据处理。

第二方面，本申请实施例提供一种数据传输控制装置，所述装置包括：

通信模块，用于接收主机端以通信消息的形式发送的更新软件包的数据控制信息；

决策模块，用于基于所述数据控制信息向所述主机端请求所述更新软件包的数据；

捕获模块，用于接收所述主机端以图像消息的形式发送的所述更新软件包的数据。

其中，所述装置集成于投影设备，所述投影设备可以为抬头显示器HUD、AR-HUD或其他具有投影功能的设备；例如，当所述装置集成于HUD时，所述HUD与主机端通过高速串行链路连接，所述HUD包括解码器和中央处理器CPU，所述解码器用于对从所述主机端接收到的消息进行解码，所述CPU用于基于解码后的消息进行数据处理。

第三方面，本申请实施例提供一种抬头显示器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述第一方面所述的数据传输控制方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的数据传输控制方法。

本申请实施例提供的数据传输控制方法、装置、抬头显示器和存储介质，通过设置投影设备如HUD与主机端基于通信消息发送的数据控制信息进行更新软件包数据的传输控制，在不增加额外数据线的情况下，实现了通过图像消息进行更新软件包的数据传输，将图像消息的较强的数据传输能力利用了起来，不仅实现了更新软件包数据的有序传输，还提高了更新软件包数据的传输效率，提高了投影设备如HUD中软件的更新升级效率，进而节省了用户进行软件升级所需要的时间，提升了用户体验。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例的一种应用场景示意图；

图2为本申请实施例一提供的一种抬头显示器的结构示意图；

图3为本申请实施例一提供的数据传输控制方法的流程示意图；

图4为本申请实施例一提供的数据包的格式示意图；

图5为本申请实施例二提供的数据传输控制方法的流程示意图；

图6为本申请实施例三提供的数据传输控制方法的流程示意图；

图7为本申请实施例三提供的数据控制信息的格式示意图；

图8为本申请实施例四提供的软件更新方法的进程一的流程示意图；

图9为本申请实施例四提供的软件更新方法的进程二的流程示意图；

图10为本申请实施例五提供的数据传输控制装置的结构示意图；

图11为本申请实施例六提供的一种抬头显示器的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“目标”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前的HUD根据显示画面的图像数据来源可以分为以下两种：

(1)智能HUD：即Smart HUD，通过车身CAN\LIN\Ethernet等总线获取相关信号，由HUD自己生成图像数据，完成绘制图像，并将图像投射到前档风玻璃上。

(2)从属HUD：即Slave HUD，与车内ECU相连，由车内ECU获取相关信息生成图像数据，并将图像数据推送给HUD，HUD接收图像数据，完成绘制图像，并投射到前挡风玻璃上。

对于Slave HUD来说，由于产生HUD所需图像数据的ECU一般性能强劲，并且算力冗余，有利于生成丰富多彩的显示画面，并且Slave HUD能显著降低HUD开发的工作量及难度，因此，Slave HUD已成为目前行业趋势所在。

另外，随着汽车电子电气架构的更新迭代以及整车厂造车周期的大幅缩短，ECU的数据传输控制功能已成为了整车ECU的基本及必须功能，在整车交付给用户端后，可能存在或多或少的功能有待完善，这个时候就可以通过整车云端的升级功能下发更新包到整车云端相关ECU，即整车ECU，通过整车ECU将相关更新包的数据传输给其他有待功能完善的ECU，以完善整车功能，提升用户体验。基于这种功能，在对Slave HUD进行软件更新时，由整车ECU将更新软件包分发给HUD的主机端(即与HUD相关ECU)，通过主机端对HUD进行软件的更新升级即可，改变了原来通过拆掉仪表蒙皮盖板并打开HUD机械结构暴露硬件电路，再使用专用刷写工具进行升级的软件更新方式，从而促进了Slave HUD的应用和推广。

示例性地，图1为本申请实施例的一种应用场景示意图，如图1所示，本实施例中，主机端(ECU)与HUD之间通过高速串行链路连接，通过高速串行链路，ECU与HUD之间可以有以下两种消息传输机制：(1)图像消息，用于传输与HUD中显示画面对应的图像数据，即RGB数据，是一种只能由ECU发送到HUD的单向数据传输消息，示例性地，图像消息可以为RGB888消息等；(2)通信消息，用于HUD与ECU之间通信的消息，是一种可以双向传输的消息，如ECU可以通过通信消息向HUD发送调节HUD显示屏的亮度、高度等控制指令的数据，HUD也可以通过通信消息向ECU发送响应反馈，示例性地，通信消息可以为如两线式串行总线(inter-integrated circuit，I2C)消息，也可以为通用异步收发传输器(universal asynchronousreceiver/transmitter，UART)消息等。

当需要对图1中所示的Slave HUD进行软件更新时，目前行业内使用较为普遍的一种方法是，通过ECU使用通信消息的形式将更新软件包的数据发送给HUD，而由于通信消息主要适用于控制指令等一些简单数据的传输，传输比特率较低，而更新软件包的数据量通常较大，因此，在使用现有技术的方案进行更新软件包传输时，存在传输效率低的问题，从而导致软件更新速度慢。

如何在不增加硬件成本的基础上提高更新软件包的传输效率，是本申请技术方案的出发点，也是最终想要实现的目的。虽然图像消息相较于通信消息具有更高的数据传输比特率，但现有技术中图像消息只适用于进行图像数据的传输，如何利用图像消息进行更新软件包数据的传输成为本申请发明人在实践过程中反复思考的问题。基于此，本申请提出一种适用于HUD软件升级过程更新软件包的数据传输控制方法，在开始进行更新软件包传输时，基于通信消息与图像消息自身的特点，通过将通信消息与图像消息的结合，先由ECU发起与HUD的握手过程，并以通信消息的形式将更新软件包的数据包的传输控制数据发送给HUD；握手通过后，再由ECU以图像消息的形式将更新软件包的数据发送给HUD；最后，HUD基于接收到的更新软件包的数据对自身软件进行更新。实现了通过图像消息进行更新软件包的数据传输，最大化地利用了图像消息数据传输能力，提高了更新软件包的数据传输效率，提升了HUD的软件更新速度，进而节省了用户进行软件升级所需要的时间，提升了用户体验。

实施例一

在图1所示的HUD的软件更新系统的基础上，示例性地，图2为本申请实施例一提供的一种抬头显示器的结构示意图，如图2所示，为实现上述技术方案，在高速串行链路的基础上，本实施例中，设置HUD中包括解码器和中央处理器(central processing unit，CPU)，解码器用于对从ECU收到的消息进行解码，CPU用于采用以下实施例中的方法对解码后的消息进行数据处理。可以理解的是，本实施例中，ECU中也设置了与该解码器相匹配的串码器。示例性地，若HUD中采用的解码器为DS90UB926，则ECU中使用兼容DS90UB926的串码器即可。

在图2所示的HUD及图1所示的软件更新系统的基础上，示例性地，图3为本申请实施例一提供的数据传输控制方法的流程示意图，本实施例的方法可以由本申请实施例所提供的数据传输控制装置执行，该装置可以由软件和/或硬件的方式来实现，并可集成于如图2所示的HUD中。如图3所示，本实施例的数据传输控制方法，包括：

S301、接收主机端以通信消息的形式发送的更新软件包的数据控制信息。

本实施例中，在握手过程中，由ECU通过串码器按照通信消息的格式对数据控制信息进行编码，生成携带数据控制信息的通信消息，并将该通信消息通过高速串行链路发送给HUD。HUD在接收到通信消息后，通过解码器进行解码，得到更新软件包的数据控制信息，并将数据控制信息发送给CPU，以使CPU进行后续的数据处理。

在一种可能的实施方式中，对于数据量通常较大的更新软件包，本实施例中，将更新软件包拆分成多个数据包分多次进行传输，从而保证数据的传输过程能够有序进行，避免了数据漏传、重复传输等情况的发生，保证了HUD接收到的数据的可用性，有利于提高数据的传输效率和软件的更新效率。可以理解的是，当更新软件包的数据量较小时，数据包的数据也可以只有一个。

在一种可能的实施方式中，设置数据控制信息对更新软件包的多个数据包的传输进行控制，本实施例中，可以根据数据包的格式设置数据控制信息的内容和格式等。示例性地，数据控制信息中可以包括待发送数据包的标识，该标识可以为目标数据包的标识码、序号等，其中，目标数据包为当前需要进行处理的数据包。

在一种可能的实施方式中，本实施例中，图4为本申请实施例一提供的数据包的格式示意图，如图4所示，主机端发送给HUD数据包中包括数据头和数据区两部分，数据头中包括帧号和帧长度，数据区中包括更新软件包中的至少一个数据。相应地，就可以设置数据控制信息中包括帧号和帧长度。这样在发送更新软件包的数据之前，通过先将对应的数据控制信息发送到HUD端，就可以使HUD知道待捕获数据包的信息，并且，当接收到一个数据包，就可以根据该信息对接收的数据包进行验证等，从而达到由HUD对更新软件包的数据传输进行控制的目的。

其中，帧号即数据包的序号；帧长度即数据区中数据的长度(数据区中的数据量)。帧号和帧长度的大小可以根据情况进行设置，示例性，帧号可以占2个字节，帧长度可以占4个字节。

S302、基于数据控制信息向主机端请求更新软件包的数据。

本实施例中，CPU在接收到数据控制信息之后，就可以根据数据控制信息确定是否需要向主机端请求更新软件包的数据，若需求，需要请求哪些数据等。在执行本步骤时，可以结合HUD中当前是否已收到更新软件包的数据以及收到的更新软件包的数据的实际情况进行确定。

在一种可能的实施方式中，HUD的内存中事先存储有更新软件包的相关信息，如总长度信息、数据包个数信息等，这些信息可以是，主机端在向HUD发送数据控制信息之前，事先发给HUD的。相应地，在本步骤中，CPU根据内存中存储的更新软件包的相关信息及接收的数据控制信息，确定是否需要向主机端请求数据，在确定需要请求数据时，HUD向主机端发送更新软件包的数据获取请求；若不需要请求数据，则HUD向主机端发送不需要相关数据的响应消息，以通知主机端停止数据发送或结束流程等。

可以理解的是，HUD也是以通信消息的形式向主机端发送数据获取请求及其他响应消息等的。

S303、接收主机端以图像消息的形式发送的更新软件包的数据。

本实施例中，当ECU接收到HUD发送的获取更新软件包的数据的请求的时候，主机端通过串码器按照图像消息的格式对更新软件包的数据进行编码，生成携带更新软件包的数据的图像消息，并将该图像消息通过高速串行链路发送给HUD。HUD在接收到该图像消息后，通过解码器进行解码，得到更新软件包的数据，完成一次更新软件包的数据传输。

在一种可能的实施方式中，当更新软件包中包括多个数据包时，针对每个数据包重复执行上述S301-S303，HUD就可以得到更新软件包的全部数据，再采用预先设计好的软件更新逻辑，使用接收到的更新软件包的数据进行软件更新即可。

需要说明的是，当更新软件包中包括多个数据包时，进行软件更新时，可以在更新软件包的所有数据包都接收完毕之后，再执行更新流程，也可以每接收到一个数据包后就立即执行相应的更新流程。具体采用哪种更新策略可以由具体的软件更新逻辑确定，此处不做限制。

本实施例中，通过设置HUD与主机端通过高速串行链路连接，HUD包括解码器和中央处理器CPU，由解码器对从主机端接收到的消息进行解码，CPU基于解码后的消息进行数据处理，并基于通信消息发送的数据控制信息进行更新软件包数据的传输控制，在不增加额外数据线的情况下，实现了通过图像消息进行更新软件包的数据传输，将图像消息的较强的数据传输能力利用了起来，不仅实现了更新软件包数据的有序传输，还提高了更新软件包数据的传输效率，提高了HUD中软件的更新升级效率，进而节省了用户进行软件升级所需要的时间，提升了用户体验。

实施例二

在上述实施例一的基础上，下面将以一个具体的实施例对ECU与HUD之间的握手过程的具体实施方式加以描述，图5为本申请实施例二提供的数据传输控制方法的流程示意图，如图5所示，本实施例的数据传输控制方法，包括：

S501、接收主机端以通信消息的形式发送的更新软件包的数据长度信息。

本实施例中，在开始发送数据包之前，ECU与HUD握手的第一步是将更新软件包的数据长度信息发送HUD，其中，数据长度信息中包括更新软件包中数据的总长度，即目标长度，以便于HUD掌握更新软件包的数据量情况。

本步骤中，数据长度信息也是以通信消息由ECU发送给HUD。类似地，本步骤中，由ECU通过串码器按照通信消息的格式对数据长度信息进行编码，生成携带数据长度信息的通信消息，并将该通信消息通过高速串行链路发送给HUD。HUD在接收到通信消息后，通过解码器进行解码，得到更新软件包的数据长度信息，并将数据长度信息发送给CPU。

S502、将目标长度保存到内存中，并对内存中更新软件包的需求帧号和长度信息接收标识进行设置。

为便于使用，在S501之后，本实施例中，将从数据长度信息解码出来的目标长度保存到内存中。可以理解的是，本实施例中，事先在内存中预留了存储更新软件包的目标长度的位置，同时，为实现对数据传输的有效控制，避免数据漏传、错传、重复传输等情况的发生，本实施例中，内存中也预留有更新软件包的需求帧号和长度信息接收标识的存储位置。

其中，需求帧号即待捕获数据包的帧号。本步骤中，由于当前还没有开始进行数据包的传输，因此，将内存中的需求帧号直接设置为初始值即可，如设置为阿拉伯数字1。

长度信息接收标识即是否接收到更新软件包的数据长度信息的标识，包括已接收到标识和未接收到标识，示例性地，已接收到标识用阿拉伯数字1表示，未接收到标识用阿拉伯数字0表示。本步骤中，由于S501中进行了数据长度信息的接收，因此，将内存中的长度信息接收标识设置为已收到标识即可。

S503、接收主机端以通信消息的形式发送的更新软件包的数据控制信息。

在S502之后，本步骤中，ECU以通信消息的形式向HUD发送更新软件包的数据控制信息，相应地，HUD接收ECU以通信消息的形式发送的更新软件包的数据控制信息，其具体实施方式与S301中类似，此处不再赘述。

S504、基于内存中更新软件包的目标长度和需求帧号，对数据控制信息进行校验。

本实施例中，数据控制信息中包括ECU待发送数据包的帧号和帧长度，为便于区分，本实施例中，将ECU待发送数据包的帧号，叫做目标帧号，将ECU待发送数据包的帧长度，叫做目标帧长度。

本步骤中，基于S502中存储到内存中的更新软件包的目标长度和需求帧号，对S503中接收到的数据控制信息进行校验，具体地，需要进行如下两方面的判断：(1)数据控制信息中的目标帧号与内存中需求帧号是否一致；(2)数据控制信息中的目标帧长度是否不大于预设帧长度。若数据控制信息中的目标帧号与内存中需求帧号一致，且，目标帧长度不大于预设帧长度，则校验通过，继续执行S505；否则，校验失败，以通信消息的形式向ECU发送数据控制信息校验失败的反馈信息。

其中，预设帧长度可以根据HUD显示屏的显示分辨率进行设定，示例性地，对于视频显示有效区为800×480分辨率位数为24位的显示屏，每帧图像的大小为800×480×3＝1152000个字节，则预设帧长度为每帧图像的大小与数据头的大小的差值。例如，若数据头的长度为6个字节，则数据区最大长度(即预设帧长度)为1152000-6＝1151994。

本实施例中，通过对数据控制信息中的目标帧号进行校验，可以有效避免数据漏传、错传、重复传输等情况的发生，保证数据的有序传输，从而保证HUD接收到的数据刚好就是需要的数据。通过对数据控制信息中的目标帧长度进行检验，保证每一个数据包中的数据量都小于或等于显示屏的分辨率，充分考虑了图像数据的特点，保证使数据能够顺利传输，不致于发生数据错乱或发生数据丢失等，保证了接收到的数据的可用性。

S505、若校验通过，则以通信消息的形式向主机端发送第一响应信息。

本步骤中，若S504中对数据控制信息进行校验的结果为校验通过，则生成第一响应信息，并以通信消息的形式将第一响应信息发送给ECU。其中，第一响应信息用于请求ECU以图4所示的数据包格式发送更新软件包的目标数据包。示例性地，第一响应信息中包括目标帧号(也即需求帧号)，相应地，第一响应信息用于请求目标帧号对应的更新软件包的数据包。

可以理解的是，对于更新软件包中包含多个数据包的情况，当ECU向HUD发送第一个数据包时，需要执行S501-S505中的全部步骤，当ECU向HUD发送除第一个数据包之外的其他数据包时，执行S503-S505中的步骤即可。需要说明的是，对于更新软件包中只包含一个数据包的情况，采用ECU向HUD发送多个数据包中的第一个数据包的流程进行更新软件包的数据传输，即直接执行S501-S505中的步骤即可。

本实施例中，通过在每次进行数据包传输之前都有选择性地执行上述S501-S505或S503-S505中的步骤与ECU进行握手，为后续的更新软件包的传输奠定了基础，不仅通过通信消息实现了数据控制信息的获取，还通过对数据控制信息进行校验，真正实现了通过数据控制信息的数据传输的控制，进一步保证了HUD接收到的更新软件包的数据的可用性，提高了HUD中软件的更新效率。

实施例三

在上述实施例一或二的基础上，下面将以一个具体的实施例对HUD内部的数据处理过程的具体实施方式加以描述，图6为本申请实施例三提供的数据传输控制方法的流程示意图，如图6所示，本实施例的数据传输控制方法，包括：

S601、接收主机端以图像消息的形式发送的更新软件包的目标数据包。

在完成上述实施例二所述的握手过程之后，对于有多个数据包的情况，ECU以图像消息的形式向HUD发送更新软件包的目标数据包，相应地，HUD接收ECU以图像消息的形式发送的更新软件包的目标数据包，其中，目标数据包可以为更新软件包的第一个数据包，也可以为其他数据包。本步骤中，目标数据包的发送和接收的具体实施方式与S303中类似，此处不再赘述。

S602、基于数据控制信息中的目标帧号、目标帧长度和目标校验值，对目标数据包进行校验。

示例性地，图7为本申请实施例三提供的数据控制信息的格式示意图，如图7所示，本实施例中，ECU发送给HUD的数据控制信息中除包括待发送数据包的目标帧号和目标帧长度外，还包括待发送数据包的数据区中至少一个数据的校验值，该检验值可以是ECU通过相应的算法，如循环冗余检验(cyclic redundancy check，CRC)算法，根据待发送数据包的数据区中的至少一个数据计算得到的，为便于区分，这里将数据控制信息中的校验值叫做目标校验值。

本实施例中，通过设置数据控制信息中包括目标校验值，便于在HUD接收到数据包时，对数据包中的数据进行校验(对数据区内容的校验)，避免数据在传输过程中被篡改，从而进一步提高接收到的数据的准确性，保证数据的高可用性，有利于提高软件的更新效率。

在步骤中，在S601之后，采用与ECU中相同的算法计算接收到的目标数据包的数据区中至少一个数据的校验值。为与数据控制信息中的目标帧号、目标帧长度和目标校验值进行区分，本实施例中，将目标数据包的数据头中的帧号、帧长度和计算得到的目标数据包的校验值，分别叫做实际帧号、实际帧长度和实际校验值。相应地，本步骤中，通过如下三个方面的判断对目标数据包进行校验：(1)目标数据包的实际帧号与数据控制信息中的目标帧号是否一致；(2)目标数据包的实际帧长度与数据控制信息中的目标帧长度是否一致；(3)目标数据包的实际校验值与数据控制信息中的目标校验值是否一致。若实际帧号与目标帧号一致，且实际帧长度与目标帧长度一致，且实际校验值与目标校验值一致，则校验通过，继续执行S603-S605；否则，校验失败，以通信消息的形式向ECU发送目标数据包校验失败的反馈信息，以使ECU重新发送目标数据包或结束发送更新软件包的数据包等。

S603、若校验通过，则采用目标数据包对HUD进行软件更新。

本步骤中，若通过S602对目标数据包检验通过，则基于预设软件更新流程采用目标数据包对HUD进行软件更新。

S604、确定HUD中软件的已更新长度是否小于目标长度。

本步骤中，在S603采用目标数据包对HUD中的软件更新完成之后，计算HUD中软件的已更新长度，并将已更新长度与内存中的目标长度做比较，确定已更新长度是否小于目标长度。

S605、若是，则更新内存中的需求帧号，并以通信消息的形式向主机端发送第二响应信息。

本步骤中，若根据S604中的步骤确定HUD中软件的已更新长度小于目标长度，说明HUD的软件还没有更新完成，还有待接收的数据包，则本步骤中，更新内存中的需求帧号，可选地，将需求帧号设置为目标数据包的下一个数据包的帧号，示例性地，计算目标数据包中的实际帧号加1后的数值，并将该数值设置为需求帧号。同时，以通信消息的形式向ECU发送第二响应信息，其中，第二响应信息用于请求ECU发送目标数据包的下一个数据包的数据控制信息。可选地，第二响应信息中包括需求帧号。

可以理解的是，若根据S604中的步骤确定HUD中软件的已更新长度等于目标长度的情况，则说明HUD中软件已更新完毕，则以通信消息的形式向ECU发送更新完毕的信息，以使ECU停止数据包的发送。

可以理解的是，在后续过程上，通过重复执行S503-S505及S601-S605中的步骤，就可以实现对所有数据包的接收，并完成对HUD中软件的更新。

本实施例中，通过上述S601-S605中的步骤，在对更新软件包的数据传输进行控制的基础上，对HUD中的软件进行更新，提高了HUD中软件的更新效率，减少了用户进行软件更新的等待时间，提升了用户体验。

实施例四

下面将以一个具体的实施例对基于上述各实施例的软件更新流程的具体实施方式加以描述，为进一步提高HUD中软件的更新效率，本实施例提供的软件更新方法可通过两个进程同时进行。

示例性地，以通信消息为I2C消息为例，图8为本申请实施例四提供的软件更新方法的进程一的流程示意图，如图8所示，进程一中主要包括如下步骤：

a、周期性检测I2C消息，当收到的I2C消息中的信息为更新软件包长度信息(即数据长度信息)时，保存软件包长度信息到内存中的预先设置的目标长度变量sw_package_len中，并设置待接收的捕获数据包帧号(即需求帧号)的数值为wait_cap_data_num＝1，将更新软件包长度标志(即长度信息接收标识)设置为已收到，并通过I2C消息给主机端肯定响应，让主机端通过I2C消息发送待捕获的数据包控制信息(即数据控制信息)。其中，HUD发出I2C消息由解码器通过高速串行链路给到主机端。

b、继续周期性检测I2C消息，当收到的I2C消息中的信息为待捕获数据包控制信息(即数据控制信息)时，该控制信息中包括待通过高速串行链路传输的更新软件包的数据包(这里为目标数据包)的帧号Rec_I2C_Data_num(即目标帧号)，帧长度(即目标帧长度)以及数据区的校验值Rec_I2C_Data_CS(即目标校验值)，判断Rec_I2C_Data_num是否与wait_cap_data_num一致，且，帧长度是否小于等于数据格式中要求的帧长度(即预设帧长度)，如果判断结果为否，通过I2C消息给主机端发送包括错误信息的否定响应；如果判断结果为是，设置开始捕获视频信号标志cap_start_flag为1，并通过I2C消息给主机端发送肯定响应(即第一响应信息)，以使主机端将待更新软件包中的数据打包成如图4所示的数据包格式。

示例性地，图9为本申请实施例四提供的软件更新方法的进程二的流程示意图，如图9所示，进程二中主要包括如下步骤：

c、持续周期性检测cap_start_flag，当为1时，开始捕获更新软件包的数据包，捕获到的数据包可以先放到缓存中，在缓存中对数据包的以下几项进行检查：第一，数据头中的帧号(即实际帧号)与wait_cap_data_num(需求帧号，也即目标帧号)是否一致；第二，数据头中的帧长度(即实际帧长度)与步骤b中待捕获数据包控制信息中的帧长度(即目标帧长度)是否一致；第三，对数据区中至少一个数据计算得到的校验值Buffer_Calc_CS(即实际校验值)与步骤b中待捕获数据包控制信息中的校验值Rec_I2C_Data_CS(即目标校验值)是否一致。当以上三项均一致时，那么此时的数据包为有效数据包，需要将该数据包中数据区内容拷贝到内存中并更新到HUD中的相关区域。否则，该数据包中数据没有通过检查，此时应丢弃该数据包，并设置cap_start_flag＝0，同时，通过I2C消息给主机端发送包括相关错误信息的否定响应。

(2)当已更新的软件包长度等于sw_package_len(即目标长度)时，说明此时已经更新完软件，通过I2C消息告知主机端HUD已更新完整个软件包，并退出更新。当已更新的软件包长度小于sw_package_len时，令wait_cap_data_num(即需求帧号)加1，设置cap_start_flag＝0，并通过I2C消息告知主机端HUD已更新完当前数据包，让主机端通过I2C消息发送下一帧待捕获数据包的控制信息。

本实施例中，通过设置进程一和进程二两个进程，并设置进程一和进程二同时进行，进一步加快HUD中软件的更新速度。

实施例五

图10为本申请实施例五提供的数据传输控制装置的结构示意图，该装置可以由软件和/或硬件的方式来实现，并可集成于投影设备如HUD中，如图10所示，本实施例中数据传输控制装置10包括：

通信模块11、决策模块12和捕获模块13。

通信模块11，用于接收主机端以通信消息的形式发送的更新软件包的数据控制信息；

决策模块12，用于基于数据控制信息向主机端请求更新软件包的数据；

捕获模块13，用于接收主机端以图像消息的形式发送的更新软件包的数据。

可选地，从主机端接收到的更新软件包的数据为预设数据包格式的目标数据包，预设数据包格式中包括数据头和数据区，数据头中包括目标数据包的实际帧号和实际帧长度，数据区包括更新软件包的至少一个数据，目标数据包为HUD当前接收到的数据包。

可选地，数据控制信息包括待发送数据包的目标帧号和目标帧长度，决策模块12具体用于：

基于内存中更新软件包的目标长度和需求帧号，对数据控制信息进行校验；

若校验通过，则以通信消息的形式向主机端发送第一响应信息，第一响应信息用于请求主机端以预设数据包格式发送更新软件包的目标数据包。

可选地，决策模块12具体用于：

确定目标帧号与需求帧号是否一致；

确定目标帧长度是否不大于预设帧长度，预设帧长度是预先基于HUD的显示屏分辨率设定的；

若目标帧号与需求帧号一致，且，目标帧长度不大于预设帧长度，则校验通过；

否则，校验失败。

可选地，数据控制信息还包括待发送数据包的数据区的目标校验值，决策模块12还用于：

基于数据控制信息中的目标帧号、目标帧长度和目标校验值，对目标数据包进行校验；

若校验通过，则采用目标数据包对HUD进行软件更新。

可选地，决策模块12具体用于：

计算目标数据包的数据区中包括的至少一个数据的实际校验值；

确定目标数据包的实际帧号与数据控制信息中的目标帧号是否一致；

确定目标数据包的实际帧长度与数据控制信息中的目标帧长度是否一致；

确定目标数据包的实际校验值与数据控制信息中的目标校验值是否一致；

若实际帧号与目标帧号一致，且实际帧长度与目标帧长度一致，且实际校验值与目标校验值一致，则校验通过；

否则，校验失败。

可选地，决策模块12还用于：

确定HUD中软件的已更新长度是否小于目标长度；

若是，则更新内存中的需求帧号，并以通信消息的形式向主机端发送第二响应信息，第二响应信息用于请求主机端发送目标数据包的下一个数据包的数据控制信息。

可选地，通信模块11还用于：

接收主机端以通信消息的形式发送的更新软件包的数据长度信息，数据长度信息中包括更新软件包中数据的目标长度；

决策模块12还用于：

将目标长度保存到内存中；

将内存中更新软件包的需求帧号设置为初始值；

将内存中更新软件包长度信息接收标识设置为已收到标识。

本实施例所提供的数据传输控制装置可执行上述方法实施例所提供的数据传输控制方法，具备执行方法相应的功能模块和有益效果。本实施例的实现原理和技术效果与上述方法实施例类似，此处不再一一赘述。

实施例六

图11为本申请实施例六提供的一种抬头显示器的结构示意图，如图11所示，该抬头显示器20包括存储器21、处理器22、解码器23及存储在存储器上并可在处理器上运行的计算机程序；抬头显示器20中处理器22的数量可以是一个或多个，图11中以一个处理器22为例；抬头显示器20中的处理器22、存储器21和解码器23可以通过总线或其他方式连接，图11中以通过总线连接为例。

其中，解码器23可以是解码芯片，如TI公司的DS90UB926芯片等，负责对从高速串行链路接收到的消息进行解码并转换得到相应的信息。

存储器21作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请实施例中的通信模块11、决策模块12和捕获模块13对应的程序指令/模块。处理器22通过运行存储在存储器21中的软件程序、指令以及模块，从而执行抬头显示设备的各种功能应用以及数据处理，即实现上述的数据传输控制方法。

存储器21可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器21可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器21可进一步包括相对于处理器22远程设置的存储器，这些远程存储器可以通过网格连接至抬头显示设备。上述网格的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

实施例七

本申请实施例七还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序在由计算机处理器执行时用于执行一种数据传输控制方法，该方法包括：

接收主机端以通信消息的形式发送的更新软件包的数据控制信息；

基于数据控制信息向主机端请求更新软件包的数据；

接收主机端以图像消息的形式发送的更新软件包的数据。

当然，本申请实施例所提供的一种包计算机可读存储介质，其计算机程序不限于如上的方法操作，还可以执行本申请任意实施例所提供的数据传输控制方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本申请可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网格设备等)执行本申请各个实施例中的方法。

值得注意的是，上述数据传输控制装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。

Claims (11)

1.一种数据传输控制方法，其特征在于，所述方法包括：

投影设备接收主机端以通信消息的形式发送的更新软件包的数据控制信息；

基于所述数据控制信息向所述主机端请求所述更新软件包的数据；

接收所述主机端以图像消息的形式发送的所述更新软件包的数据。

2.根据权利要求1所述的方法，其特征在于，从所述主机端接收到的所述更新软件包的数据为预设数据包格式的目标数据包，所述预设数据包格式中包括数据头和数据区，所述数据头中包括目标数据包的实际帧号和实际帧长度，所述数据区包括所述更新软件包的至少一个数据，所述目标数据包为所述投影设备当前接收到的数据包。

3.根据权利要求2所述的方法，其特征在于，所述数据控制信息包括待发送数据包的目标帧号和目标帧长度，所述基于所述数据控制信息向所述主机端请求所述更新软件包的数据，包括：

基于内存中所述更新软件包的目标长度和需求帧号，对所述数据控制信息进行校验；

若校验通过，则以通信消息的形式向所述主机端发送第一响应信息，所述第一响应信息用于请求所述主机端以所述预设数据包格式发送所述更新软件包的目标数据包。

4.根据权利要求3所述的方法，其特征在于，所述基于内存中所述更新软件包的目标长度和需求帧号，对所述数据控制信息进行校验，包括：

确定所述目标帧号与所述需求帧号是否一致；

确定所述目标帧长度是否不大于预设帧长度，所述预设帧长度是预先基于所述投影设备的显示屏分辨率设定的；

若所述目标帧号与所述需求帧号一致，且，所述目标帧长度不大于所述预设帧长度，则校验通过；

否则，校验失败。

5.根据权利要求4所述的方法，其特征在于，所述数据控制信息还包括待发送数据包的数据区的目标校验值，接收所述主机端以图像消息的形式发送的所述更新软件包的目标数据包之后，所述方法还包括：

基于所述数据控制信息中的目标帧号、目标帧长度和目标校验值，对所述目标数据包进行校验；

若校验通过，则采用所述目标数据包对所述投影设备进行软件更新。

6.根据权利要求5所述的方法，其特征在于，所述基于所述数据控制信息中的目标帧号、目标帧长度和目标校验值，对所述目标数据包进行校验，包括：

计算所述目标数据包的数据区中包括的至少一个数据的实际校验值；

确定所述目标数据包的实际帧号与所述数据控制信息中的目标帧号是否一致；

确定所述目标数据包的实际帧长度与所述数据控制信息中的目标帧长度是否一致；

确定所述目标数据包的实际校验值与所述数据控制信息中的目标校验值是否一致；

若所述实际帧号与所述目标帧号一致，且所述实际帧长度与所述目标帧长度一致，且所述实际校验值与所述目标校验值一致，则校验通过；

否则，校验失败。

7.根据权利要求5所述的方法，其特征在于，所述采用所述目标数据包对所述投影设备进行软件更新之后，所述方法还包括：

确定所述投影设备中软件的已更新长度是否小于所述目标长度；

若是，则更新内存中的需求帧号，并以通信消息的形式向所述主机端发送第二响应信息，所述第二响应信息用于请求所述主机端发送所述目标数据包的下一个数据包的数据控制信息。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述接收主机端以通信消息的形式发送的更新软件包的数据控制信息之前，所述方法还包括：

接收所述主机端以通信消息的形式发送的所述更新软件包的数据长度信息，所述数据长度信息中包括更新软件包中数据的目标长度；

将所述目标长度保存到内存中；

将所述内存中所述更新软件包的需求帧号设置为初始值；

将所述内存中所述更新软件包长度信息接收标识设置为已收到标识。

9.一种数据传输控制装置，其特征在于，所述装置包括：

通信模块，用于接收主机端以通信消息的形式发送的更新软件包的数据控制信息；

决策模块，用于基于所述数据控制信息向所述主机端请求所述更新软件包的数据；

捕获模块，用于接收所述主机端以图像消息的形式发送的所述更新软件包的数据。

10.一种抬头显示器，包括解码器、存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1-8中任一所述的数据传输控制方法。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-8中任一所述的数据传输控制方法。

Images