CN117873046A - 车辆碰撞场景下的诊断方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请涉及车辆技术领域，公开了一种车辆碰撞场景下的诊断方法、装置、电子设备及存储介质，方法运用于车端，包括：若检测到目标标识的值变换为目标值，则记录目标值的维持时长；在维持时长达到预设时长时确定出现碰撞场景，并采集碰撞场景下的整车数据；将整车数据发送至云端，以接收云端为响应整车数据而返回的诊断请求；若检测接收到诊断请求，则将目标数据发送至云端，以使云端生成诊断报告。本申请通过检测目标标识的数值变换，以及变换为目标值之后的维持时长，以准确确定出车辆是否出现碰撞场景。车端将碰撞场景下的整车数据发送至云端备份，云端同时根据车端的目标数据对车端进行及时诊断，以为后续车辆维修提供有效帮助。

Description

车辆碰撞场景下的诊断方法、装置、电子设备及存储介质

技术领域

本申请涉及车辆技术领域，具体涉及一种车辆碰撞场景下的诊断方法、装置、电子设备及存储介质。

背景技术

随着车辆保有量和驾驶人数的激增，车祸概率也随之大幅上升，各厂商将车辆安全问题作为研究和解决的重中之重。

现有某些车辆发生碰撞事件之时，车辆无法准确识别出碰撞场景，在某些情况下容易误判出现碰撞场景。另外，车辆判定出碰撞场景后会主动向车主发出短信提醒或手机APP(Application，应用程序)消息，其中包括碰撞事件发生的时间、地点等消息，但是这些数据非常有限，无法反映车辆内在情况，对事后车辆维修也提供不了有效帮助。

发明内容

鉴于上述问题，本申请提供了一种车辆碰撞场景下的诊断方法、装置、电子设备及存储介质，用于精准判定出车辆的碰撞场景，并使车端将碰撞场景下的整车数据发送至云端，以使云端对车端及时诊断，以为后续车辆维修提供有效帮助。

根据本申请一个方面，提供了一种车辆碰撞场景下的诊断方法，运用于车端，所述诊断方法包括：若检测到目标标识的值变换为目标值，则记录所述目标值的维持时长；在所述维持时长达到预设时长时确定出现碰撞场景，并采集所述碰撞场景下的整车数据；将所述整车数据发送至云端，以接收所述云端为响应所述整车数据而返回的诊断请求；若检测接收到所述诊断请求，则将目标数据发送至所述云端，以使所述云端生成诊断报告。

在一种可选的方式中，所述目标标识包括第一目标标识和第二目标标识；所述诊断方法还包括：检测所述第一目标标识的值是否变换为第一目标值，以及所述第二目标标识的值是否变换为第二目标值；若皆为是，则确定所述目标标识的值变换为所述目标值。

在一种可选的方式中，所述在所述维持时长达到预设时长时确定出现碰撞场景，进一步包括：检测所述第一目标值对应的维持时长是否达到第一预设时长，以及所述第二目标值对应的维持时长是否达到第二预设时长；若皆为是，则确定出现碰撞场景。

在一种可选的方式中，所述采集所述碰撞场景下的整车数据，进一步包括：将所述目标标识的值变化为所述目标值的时刻作为碰撞场景的发生时刻，并将所述维持时长到达所述预设时长时对应的时刻作为采集结束时刻；采集所述发生时刻至所述采集结束时刻之间的目标车端数据流，并将所述目标车端数据流作为所述碰撞场景下的整车数据。

根据本申请一个方面，提供了另一种车辆碰撞场景下的诊断方法，运用于云端，所述诊断方法包括：接收目标车端发送的碰撞场景下的整车数据；其中，所述整车数据是所述目标车端检测到目标标识的值变换为目标值，且在预设时长内维持所述目标值不变，而采集得到的目标车端数据流；响应所述整车数据而向所述目标车端发送诊断请求，以获取所述目标车端的目标数据，并根据所述目标数据生成诊断报告；将所述诊断报告发送至指定端；其中，所述指定端包括所述目标车端，用户端和维保端中的至少一端。

在一种可选的方式中，所述诊断方法还包括：接收用户发送的授权信息；其中，所述授权信息中包括所述目标车端的身份信息和数据交互权限，所述数据交互权限包括所述云端接收所述碰撞场景下的整车数据的权限；根据所述身份信息确定出进行授权同步操作的目标车端，并将所述数据交互权限同步至所述目标车端，以使所述目标车端发送所述碰撞场景下的整车数据。

在一种可选的方式中，所述整车数据携带有所述目标车端的车端标识；所述诊断方法还包括：将所述车端标识与预设车端标识进行匹配操作；若匹配成功，则将所述整车数据进行存储操作，并执行响应所述整车数据而向所述目标车端发送诊断请求的步骤。

根据本申请另一方面，提供了一种车辆碰撞场景下的诊断装置，运用于车端，所述诊断装置包括：记录模块，用于若检测的目标标识的值变换为目标值，则记录所述目标值的维持时长；采集模块，用于在所述维持时长达到预设时长时确定出现碰撞场景，并采集所述碰撞场景下的整车数据；接收模块，用于将所述整车数据发送至云端，以接收所述云端为响应所述整车数据而返回的诊断请求；发送诊断模块，用于若检测接收到所述诊断请求，则将目标数据发送至所述云端，以使所述云端生成诊断报告。

根据本申请另一方面，提供了另一种车辆碰撞场景下的诊断装置，运用于车端，所述诊断装置包括：整车数据接收模块，用于接收目标车端发送的碰撞场景下的整车数据；其中，整车数据是目标车端检测到目标标识的值变换为目标值，且在预设时长内维持目标值不变，而采集得到的目标车端数据流；响应模块，用于响应整车数据而向目标车端发送诊断请求，以获取目标车端的目标数据，并根据目标数据生成诊断报告；发送模块，用于将诊断报告发送至指定端；其中，指定端包括目标车端，用户端和维保端中的至少一端。

根据本申请一个方面，提供了一种电子设备，包括：控制器；存储器，用于存储一个或多个程序，当一个或多个程序被所述控制器执行时，以执行上述的诊断方法。

根据本申请一个方面，还提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述的诊断方法。

根据本申请一个方面，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的诊断方法。

本申请通过检测目标标识的数值变换，以及变换为目标值之后的维持时长，以准确确定出车辆是否出现碰撞场景。车端将碰撞场景下的整车数据发送至云端备份，云端同时根据车端的目标数据对车端进行及时诊断，以为后续车辆维修提供有效帮助。

上述说明仅是本申请实施例技术方案的概述，为了能够更清楚了解本申请技术手段，而可依照说明书的内容予以实施，并且为了让本申请上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一示例性实施例示出的一种车辆碰撞场景下的诊断方法的流程示意图。

图2是本申请一示例性实施例示出的另一种车辆碰撞场景下的诊断方法的流程示意图。

图3是基于图2所示示例性实施例示出的另一种车辆碰撞场景下的诊断方法的流程示意图。

图4是本申请一示例性实施例示出的用户授权示意图。

图5是本申请车辆碰撞场景下的诊断方法的应用场景的示意图。

图6是本申请一示例性实施例示出的车辆碰撞场景下的诊断装置的结构示意图。

图7是本申请一示例性实施例示出的另一车辆碰撞场景下的诊断装置的结构示意图。

图8是本申请的一示例性实施例示出的电子设备的计算机系统的结构示意图。

具体实施方式

这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

在本申请中提及的“多个”是指两个或者两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

现有车辆无法准确识别出碰撞场景，在某些情况下容易误判出现碰撞场景。另外，车辆判定出碰撞场景后会主动向车主发出短信提醒或手机APP消息，其中包括碰撞事件发生的时间、地点等消息，但是这些数据非常有限，无法反映车辆内在情况，对事后车辆维修也提供不了有效帮助。

为此，本申请的一方面提供了一种车辆碰撞场景下的诊断方法。具体请参阅图1，图1是本申请一示例性实施例示出的一种车辆碰撞场景下的诊断方法的流程示意图。该诊断方法运用于车端，至少包括S110至S140，详细介绍如下：

S110：若检测到目标标识的值变换为目标值，则记录目标值的维持时长。

本实施例车端可实时监测目标标识的值，若检测到其数据变换为目标值，则持续记录该目标值的维持时长。例如，监测acu_crashStatusValid信号作为目标标识，其默认起始状态为acu_crashStatusValid＝0x0(16进制数，代表INVALID-无效)，若检测到其变换为acu_crashStatusValid＝0x1(16进制数，代表VALID-有效)，其值由0x0变为了0x1(目标值)，则持续记录“acu_crashStatusValid＝0x1”的维持时长。

S120：在维持时长达到预设时长时确定出现碰撞场景，并采集碰撞场景下的整车数据。

预设时长是预设参数，本申请并不对其具体数值大小和单位进行限定，可以根据实际情况进行相应调整，例如其可以是1000毫秒，1秒等。

车端可采集并存储碰撞场景下的整车数据，主动对整车CAN(Controller AreaNetwork，控制器局域网信号)数据进行存储，主动对各个关键域及关键ECU(EngineControl Unit，电子控制单元)感应器进行数据存储，保证最大程度的收集碰撞事件发生现场的相关数据，示例性数据如下：

(1)碰撞传感器数据：碰撞传感器包括加速度计和碰撞传感器，它们会记录碰撞发生时的加速度、冲击力等数据。

(2)刹车系统数据：刹车系统会记录碰撞发生前后的制动状态、刹车压力和刹车力度等数据。

(3)安全气囊系统数据：安全气囊系统会记录气囊的部署时间、气囊压力、乘客位置等数据。

(4)安全带系统数据：安全带系统会记录安全带的使用情况，包括是否系好、松弛状态等。

(5)车辆状态数据：各个关键ECU会记录车辆状态数据，如车速、转速、油门位置、制动状态等。

(6)GPS位置数据：智能汽车通常配备了GPS系统，会记录碰撞发生时的车辆位置信息。

(7)摄像头和雷达数据：智能汽车通常配备了摄像头和雷达等感应器，会记录碰撞发生前后的图像和距离数据。

(8)EDR数据：EDR是一个专门的数据记录设备，记录和存储车辆发生事故时的相关数据，包括车速、刹车状态、加速度、转向角度、安全气囊部署情况等。

S130：将整车数据发送至云端，以接收云端为响应整车数据而返回的诊断请求。

车端可将整车数据存储于本地，并将其压缩打包发送至云端进行备份，以避免数据丢失，示例性数据发送过程如下：

1)数据准备：车端首先要将采集到的原始数据进行整理，把原始数据、处理后的数据或者日志文件等各自归类保存，最终汇总在一个总文件夹下。

2)数据压缩打包：车端使用ZIP算法对整理好的总文件夹进行压缩打包，以减小数据的大小，便于传输。

3)车端建立与云端服务器连接：车端使用HTTP的POST请求将压缩文件发送到云端服务器的指定URL，在请求过程中，车端需要提供认证信息、文件名、文件大小和数据内容等。

4)云端数据验证和处理：云端服务器接收到请求后，进行上传验证。

首先，云端服务器会检查请求中的认证信息，确认车端的身份。然后，通过校验数据的MD5值或者其他标识来确认确保数据完整性和正确性。

5)存储和备份：云端服务器将验证和处理后的数据存储在相应的存储系统中，如数据库、文件系统等。为了保证数据的安全性和可靠性，云端服务器可能会对数据进行备份和冗余存储。

6)响应和反馈：云端服务器向车端发送响应和反馈，以确认数据上传成功，并提供相应的状态信息或处理结果，车端可以根据响应和反馈进行相应的处理和记录。

S140：若检测接收到诊断请求，则将目标数据发送至云端，以使云端生成诊断报告。

云端同时会下发诊断请求至车端，以获取目标数据对车端进行诊断。其中，目标数据是云端诊断所需的数据，其类型和范围小于或等于整车数据。

诊断报告包括但不限于：

车辆基本信息：包括车辆制造商、型号、车辆识别号码(车架号)、车辆注册信息等。

碰撞事件信息：包括碰撞发生的时间、地点、碰撞类型(前、后、侧面碰撞等)以及碰撞的严重程度。

车辆传感器数据：通过车辆的传感器和数据采集系统，获取车辆在碰撞过程中的相关数据，如车速、加速度、转向角度等。

车辆状态分析：根据传感器数据和车辆系统状态，分析车辆在碰撞过程中的状态变化，如车辆是否失控、是否触发安全气囊等。

车辆损伤分析：通过远程诊断结果，对车辆损伤进行分析和评估，包括车身、车轮、玻璃、灯具等部件的受损情况。

车辆结构分析：通过远程诊断结果对车辆结构进行分析，评估碰撞对车辆整体结构的影响程度。

车辆系统诊断：通过远程诊断车辆的关键ECU，对车辆的机械系统和电子系统进行诊断，评估碰撞对这些系统的影响程度。

事故原因推测：根据对车辆传感器数据和损伤情况的分析，推测事故的原因，可能包括驾驶失误、机械故障、道路状况等。

修复建议：根据诊断结果，给出对车辆修复的建议，包括需要修复的部件、修复方法、替换零件的建议等。

预估修复费用：根据对车辆损伤的评估，预估修复所需的费用，包括人工费用和零件费用。

远程支持：如有需要，诊断报告可能会提供远程支持的联系方式，以便车主或修理厂能够进一步咨询或寻求帮助。

本实施例通过检测目标标识的数值变换，以及变换为目标值之后的维持时长，以准确确定出车辆是否出现碰撞场景。车端将碰撞场景下的整车数据发送至云端备份，云端同时根据车端的目标数据对车端进行及时诊断，以为后续车辆维修提供有效帮助。

目前车辆一般根据单一的参数变换确定车辆场景，存在较大的误差，为此，在本申请另一示例性实施例中，目标标识包括第一目标标识和第二目标标识，详细介绍了如何根据多个目标标识确定车辆场景。

基于图1所示的S110至S140，本实施例的诊断方法还包括S150至S160，详细介绍如下：

S150：检测第一目标标识的值是否变换为第一目标值，以及第二目标标识的值是否变换为第二目标值。

其中，第一目标值和第二目标值可以相同，亦可不同，本申请并不对其进行限定。

S160：若皆为是，则确定目标标识的值变换为目标值。

若存在多个目标标识，则需要所有的目标标识的值变换为相应的目标值，才能确定目标标识的值变换为目标值。

示例性地，第一目标标识为acu_crashStatusValid，其初始默认值为0x0；第一目标标识为acu_crashStatus，其初始默认值为0x0；第一目标值和第二目标值皆为0x1。若acu_crashStatusValid＝0x0(16进制数，此处代表INVALID-无效)变为acu_crashStatusValid＝0x1(16进制数，此处代表VALID-有效)；acu_crashStatus＝0x0(16进制数，此处代表NO_CRASH-无碰撞)变为acu_crashStatus＝0x1(16进制数，此处代表CRASH-有碰撞)，则确定目标标识的值变换为目标值。

进一步地，在本申请另一示例性实施例中，对“在维持时长达到预设时长时确定出现碰撞场景”步骤进行了说明，即上述S120中进一步包括S121至S122，详细介绍如下：

S121：检测第一目标值对应的维持时长是否达到第一预设时长，以及第二目标值对应的维持时长是否达到第二预设时长。

其中，第一预设时长和第二预设时长可以相同，亦可不同，本申请并不对其进行限定。

S122：若皆为是，则确定出现碰撞场景。

示例性地，第一预设时长和第二预设时长皆为1000毫秒，若第一目标值和第二目标值的维持时长皆达到1000毫秒，则可确定出现碰撞场景。

本实施例进一步说明如何根据多个目标标识确定车辆场景，若检测到所有目标标识的值变换为相应的目标值，以及各个目标值的维持时长达到相应的预设维持时长，则确定出现了碰撞场景。本实施例通过多个目标标识的以降低检测过程中出现的偶然误差，在一定程度上提高了碰撞场景的检测精准度。

在本申请另一示例性实施例中，详细介绍了如何采集碰撞场景下的整车数据。即上述S120中进一步包括S123至S124，详细介绍如下：

S123：将目标标识的值变化为目标值的时刻作为碰撞场景的发生时刻，并将维持时长到达预设时长时对应的时刻作为采集结束时刻。

目标车端发生碰撞事件，其目标标识的值会在碰撞场景的发生时刻变换为目标值，当时目标车端并未在此时刻完成碰撞场景的判定，需要目标值的维持时长达到预设时长时才能判定成功，此过程存在一定的时间差，为了确保目标车端碰撞场景下的数据的完整性，本申请的整车数据涵盖了此过程的所有数据。

S124：采集发生时刻至采集结束时刻之间的目标车端数据流，并将目标车端数据流作为碰撞场景下的整车数据。

本实施例中的整车数据并非某系时刻对应的数据，而是由多个时刻的目标车端数据流构成的数据。其中，涵盖了碰撞发生时刻至碰撞场景判定成功时刻过程中的所有数据，最大程度保证了目标车端在碰撞场景下的数据完整性。

示例性地，10：00时刻，目标标识的值变化为目标值，即为碰撞场景的发生时刻；10：01时刻，目标值的维持时长到达预设时长，即为采集结束时刻，即整车数据包括10：00至10：01间各个时刻对应的数据流。

本实施例进一步说明了整车数据涵盖的数据范围，其涵盖了碰撞场景发生时刻至成功判定碰撞场景的时刻间的数据流，最大程度保证了目标车端在碰撞场景下的数据完整性。

本申请的另一方面提供了另一种车辆碰撞场景下的诊断方法。具体请参阅图2，图2是本申请一示例性实施例示出的另一种车辆碰撞场景下的诊断方法的流程示意图。该诊断方法运用于云端，至少包括S210至S230，详细介绍如下：

S210：接收目标车端发送的碰撞场景下的整车数据；其中，整车数据是目标车端检测到目标标识的值变换为目标值，且在预设时长内维持目标值不变，而采集得到的目标车端数据流。

示例性地，目标车端检测到其acu_crashStatus(目标标识)的值由0x0变为0x1(目标值)，且维持1000毫秒(预设时长)不变，则确定出现碰撞场景，采集碰撞场景下的整车数据发送至云端。

S220：响应整车数据而向目标车端发送诊断请求，以获取目标车端的目标数据，并根据目标数据生成诊断报告。

在某些实施例中，设置有端口身份认证步骤，以确保数据交互的安全。整车数据携带有目标车端的车端标识，云端将车端标识与预设车端标识进行匹配操作；若匹配成功，则将整车数据进行存储操作，并执行S220。

云端向目标车端发起诊断请求，目标车端为响应该诊断请求，则会将目标数据返回云端，以使云端完成对目标车端的诊断，示例性诊断过程如下：

(1)云端通过前置建立的远程连接，向车辆发送UDS(Unified DiagnosticServices，统一诊断服务)诊断请求。其中，UDS是一种诊断通信协议，它定义了标准的诊断服务和消息格式。诊断请求可以包括读取实时数据、读取故障码、执行特定的诊断功能等。

(2)车辆响应：车辆接收到云端发送的诊断请求后，根据请求的内容执行相应的操作。例如，如果云端请求读取实时数据，车辆会将实时数据通过远程连接传输到云端；如果云端请求读取整车故障码，车辆会将故障码传输到云端。

4)数据分析和诊断：云端接收到目标车辆的目标数据后，进行数据分析和诊断。云端使用专业的算法和模型来解析目标数据，识别存在或潜在的问题并进行诊断。例如，根据实时数据的变化趋势，判断是否存在异常情况；根据故障码的解析结果，确定具体的故障类型。

5)生成诊断报告：根据数据分析和诊断结果，云端生成专业的诊断报告。报告可以包括目标车辆的健康状况、存在的问题和建议的修复措施等。

S230：将诊断报告发送至指定端；其中，指定端包括目标车端，用户端和维保端中的至少一端。

云端将诊断报告可通过手机APP、电子邮件、短息等方式主动向用户端或指定联系人推送，也可向维修公司、保险公司等事先通过车主授权的机构发出。

值得注意的是，云端还可将诊断报告发送至目标车端，以使非授权维修机构从目标车端下载诊断报告，以方便车辆后续维修。

本实施例通过检测目标标识的数值变换，以及变换为目标值之后的维持时长，以准确确定出车辆是否出现碰撞场景。车端将碰撞场景下的整车数据发送至云端备份，云端同时根据车端的目标数据对车端进行及时诊断，并将诊断报告发送至指定端，以为后续车辆维修提供有效帮助。

为保护用户个人信息和车辆信息安全，满足相关法律法规的要求，所有的数据交互权限都是基于车主授权。在本申请另一示例性实施例中，进一步介绍了目标车端和云端之间授权同步方式，具体请参阅图3，图3是基于图2所示示例性实施例示出的另一种车辆碰撞场景下的诊断方法的流程示意图。本实施例诊断方法还包括S310至S320，详细介绍如下：

S310：接收用户发送的授权信息；其中，授权信息中包括目标车端的身份信息和数据交互权限，数据交互权限包括云端接收碰撞场景下的整车数据的权限。

身份信息包括但不限于目标车端的车架号、车辆牌照、车系车型、车架号、颜色、动力类型等。

授权信息还可包括目标车辆的位置信息、状态信息。其中，位置信息包括但不限于GPS定位信息，例如经纬度、行驶方向、附近主要交通标识点等；状态信息包括但不限于整车CAN信号数据，关键域及关键ECU日志数据，摄像头和雷达数据等。

S320：根据身份信息确定出进行授权同步操作的目标车端，并将数据交互权限同步至目标车端，以使目标车端发送碰撞场景下的整车数据。

用户必须事先知晓并同意在车辆发生碰撞事件后，汽车运营商或服务提供方会对车辆进行远程诊断并生成相关报告；用户可以授权报告的接收人和发送方式；用户可通过线下销售服务门店签署相关文件，或手机APP应用进行授权；用户进行授权后也可根据实际需求终止授权，整个授权过程必须严格按照相关法律法规执行。

请参阅图4，图4是本申请一示例性实施例示出的用户授权示意图。其中，用户发起授权任务，将授权信息发送至云端，云端保存相应的授权信息，并根据授权信息中的身份信息确定出需进行权限同步的目标车端，并将数据交互权限同步至目标车端，以使目标车端发送碰撞场景下的整车数据。

在本申请另一示例性实施例中对上述多个诊断方法的应用场景进行了示例性说明，具体请参阅图5，图5是本申请车辆碰撞场景下的诊断方法的应用场景的示意图。其中，包括用户端100，目标车端200，云端300和维保端400，三端之间可通过无线通信的方式连接，本申请并不限制它们之间的连接方式。

目标车端200若检测到目标标识的值变换为目标值，则记录目标值的维持时长；在维持时长达到预设时长时确定出现碰撞场景，目标车端200采集碰撞场景下的整车数据，并将整车数据发送至云端300。

云端300接收目标车端200发送的碰撞场景下的整车数据，向目标车端200发送诊断请求，目标车端200将诊断所需的目标数据返回至云端300，云端300根据目标数据对目标车端200进行诊断，将生成的诊断报告保存在本地，并将诊断报告发送至用户端100、目标车端200和维保端400，以便于多端快速知晓目标车端200的情况，以便于后续车辆维修。

本申请的另一方面还提供了一种车辆碰撞场景下的诊断装置，如图6所示，图6是本申请一示例性实施例示出的车辆碰撞场景下的诊断装置的结构示意图。诊断装置600运用于车端，包括：记录模块610，用于若检测的目标标识的值变换为目标值，则记录目标值的维持时长；采集模块630，用于在维持时长达到预设时长时确定出现碰撞场景，并采集碰撞场景下的整车数据；接收模块650，用于将整车数据发送至云端，以接收云端为响应整车数据而返回的诊断请求；发送诊断模块670，用于若检测接收到诊断请求，则将目标数据发送至云端，以使云端生成诊断报告。

在一种可选的方式中，目标标识包括第一目标标识和第二目标标识；诊断装置600还包括：检测模块，用于检测第一目标标识的值是否变换为第一目标值，以及第二目标标识的值是否变换为第二目标值；确定模块，用于若皆为是，则确定目标标识的值变换为目标值。

在一种可选的方式中，采集模块630进一步包括：检测单元，用于检测第一目标值对应的维持时长是否达到第一预设时长，以及第二目标值对应的维持时长是否达到第二预设时长；确定单元，用于若皆为是，则确定出现碰撞场景。

在一种可选的方式中，采集模块630进一步包括：时刻单元，用于将目标标识的值变化为目标值的时刻作为碰撞场景的发生时刻，并将维持时长到达预设时长时对应的时刻作为采集结束时刻；数据流单元，用于采集发生时刻至采集结束时刻之间的目标车端数据流，并将目标车端数据流作为碰撞场景下的整车数据。

本申请的另一方面还提供了另一种车辆碰撞场景下的诊断装置，如图7所示，图7是本申请一示例性实施例示出的另一车辆碰撞场景下的诊断装置的结构示意图。诊断装置700运用于云端，包括：整车数据接收模块710，用于接收目标车端发送的碰撞场景下的整车数据；其中，整车数据是目标车端检测到目标标识的值变换为目标值，且在预设时长内维持目标值不变，而采集得到的目标车端数据流；响应模块730，用于响应整车数据而向目标车端发送诊断请求，以获取目标车端的目标数据，并根据目标数据生成诊断报告；发送模块750，用于将诊断报告发送至指定端；其中，指定端包括目标车端，用户端和维保端中的至少一端。

在一种可选的方式中，诊断装置700还包括：授权信息接收模块，用于接收用户发送的授权信息；其中，授权信息中包括目标车端的身份信息和数据交互权限，数据交互权限包括云端接收碰撞场景下的整车数据的权限；交互授权模块，用于根据身份信息确定出进行授权同步操作的目标车端，并将数据交互权限同步至目标车端，以使目标车端发送碰撞场景下的整车数据。

在一种可选的方式中，整车数据携带有目标车端的车端标识；诊断装置700还包括：匹配模块，用于将车端标识与预设车端标识进行匹配操作；匹配成功模块，用于若匹配成功，则将整车数据进行存储操作，并执行响应整车数据而向目标车端发送诊断请求的步骤。

本申请通过检测目标标识的数值变换，以及变换为目标值之后的维持时长，以准确确定出车辆是否出现碰撞场景。车端将碰撞场景下的整车数据发送至云端备份，云端同时根据车端的目标数据对车端进行及时诊断，以为后续车辆维修提供有效帮助。

需要说明的是，上述实施例所提供的诊断装置与前述实施例所提供的诊断方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，这里不再赘述。

本申请的另一方面还提供了一种电子设备，包括：控制器；存储器，用于存储一个或多个程序，当一个或多个程序被控制器执行时，以执行上述的诊断方法。

请参阅图8，图8是本申请的一示例性实施例示出的电子设备的计算机系统的结构示意图，其示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图8示出的电子设备的计算机系统800仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括中央处理单元(Central Processing Unit，CPU)801，其可以根据存储在只读存储器(Read-Only Memory，ROM)802中的程序或者从存储部分808加载到随机访问存储器(Random Access Memory，RAM)803中的程序而执行各种适当的动作和处理，例如执行上述实施例中的方法。在RAM 803中，还存储有系统操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(Input/Output，I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不相同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如前的诊断方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的诊断方法。

根据本申请实施例的一个方面，还提供了一种计算机系统，包括中央处理单元(Central Processing Unit，CPU)，其可以根据存储在只读存储器(Read-Only Memory，ROM)中的程序或者从存储部分加载到随机访问存储器(Random Access Memory，RAM)中的程序而执行各种适当的动作和处理，例如执行上述实施例中的方法。在RAM中，还存储有系统操作所需的各种程序和数据。CPU、ROM以及RAM通过总线彼此相连。输入/输出(Input/Output，I/O)接口也连接至总线。

以下部件连接至I/O接口：包括键盘、鼠标等的输入部分；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分；包括硬盘等的存储部分；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分。通信部分经由诸如因特网的网络执行通信处理。驱动器也根据需要连接至I/O接口。可拆卸介质，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器上，以便于从其上读出的计算机程序根据需要被安装入存储部分。

上述内容，仅为本申请的较佳示例性实施例，并非用于限制本申请的实施方案，本领域普通技术人员根据本申请的主要构思和精神，可以十分方便地进行相应的变通或修改，故本申请的保护范围应以权利要求书所要求的保护范围为准。

Claims (10)

1.一种车辆碰撞场景下的诊断方法，其特征在于，运用于车端，所述诊断方法包括：

若检测到目标标识的值变换为目标值，则记录所述目标值的维持时长；

在所述维持时长达到预设时长时确定出现碰撞场景，并采集所述碰撞场景下的整车数据；

将所述整车数据发送至云端，以接收所述云端为响应所述整车数据而返回的诊断请求；

若检测接收到所述诊断请求，则将目标数据发送至所述云端，以使所述云端生成诊断报告。

2.根据权利要求1所述的诊断方法，其特征在于，所述目标标识包括第一目标标识和第二目标标识；所述诊断方法还包括：

检测所述第一目标标识的值是否变换为第一目标值，以及所述第二目标标识的值是否变换为第二目标值；

若皆为是，则确定所述目标标识的值变换为所述目标值。

3.根据权利要求2所述的诊断方法，其特征在于，所述在所述维持时长达到预设时长时确定出现碰撞场景，进一步包括：

检测所述第一目标值对应的维持时长是否达到第一预设时长，以及所述第二目标值对应的维持时长是否达到第二预设时长；

若皆为是，则确定出现碰撞场景。

4.根据权利要求1所述的诊断方法，其特征在于，所述采集所述碰撞场景下的整车数据，进一步包括：

将所述目标标识的值变化为所述目标值的时刻作为碰撞场景的发生时刻，并将所述维持时长到达所述预设时长时对应的时刻作为采集结束时刻；

采集所述发生时刻至所述采集结束时刻之间的目标车端数据流，并将所述目标车端数据流作为所述碰撞场景下的整车数据。

5.一种车辆碰撞场景下的诊断方法，其特征在于，运用于云端，所述诊断方法包括：

接收目标车端发送的碰撞场景下的整车数据；其中，所述整车数据是所述目标车端检测到目标标识的值变换为目标值，且在预设时长内维持所述目标值不变，而采集得到的目标车端数据流；

响应所述整车数据而向所述目标车端发送诊断请求，以获取所述目标车端的目标数据，并根据所述目标数据生成诊断报告；

将所述诊断报告发送至指定端；其中，所述指定端包括所述目标车端，用户端和维保端中的至少一端。

6.根据权利要求5所述的诊断方法，其特征在于，所述诊断方法还包括：

接收用户发送的授权信息；其中，所述授权信息中包括所述目标车端的身份信息和数据交互权限，所述数据交互权限包括所述云端接收所述碰撞场景下的整车数据的权限；

根据所述身份信息确定出进行授权同步操作的目标车端，并将所述数据交互权限同步至所述目标车端，以使所述目标车端发送所述碰撞场景下的整车数据。

7.根据权利要求5至6中任一项所述的诊断方法，其特征在于，所述整车数据携带有所述目标车端的车端标识；所述诊断方法还包括：

将所述车端标识与预设车端标识进行匹配操作；

若匹配成功，则将所述整车数据进行存储操作，并执行响应所述整车数据而向所述目标车端发送诊断请求的步骤。

8.一种车辆碰撞场景下的诊断装置，其特征在于，运用于车端，所述诊断装置包括：

记录模块，用于若检测的目标标识的值变换为目标值，则记录所述目标值的维持时长；

采集模块，用于在所述维持时长达到预设时长时确定出现碰撞场景，并采集所述碰撞场景下的整车数据；

接收模块，用于将所述整车数据发送至云端，以接收所述云端为响应所述整车数据而返回的诊断请求；

发送诊断模块，用于若检测接收到所述诊断请求，则将目标数据发送至所述云端，以使所述云端生成诊断报告。

9.一种电子设备，其特征在于，包括：

控制器；

存储器，用于存储一个或多个程序，当一个或多个程序被控制器执行时，使得控制器实现权利要求1至7中任一项所述的诊断方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机可读指令，当计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1至7中任一项所述的诊断方法。