具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

实施例一：

为了解决现有技术中，车辆异常需要由车主主动发现，对车主专业素养要求过高，且容易导致车辆问题扩大，造成不可控的风险的问题，本申请实施例提供了一种车辆监控方法。下面结合图1所示的一种车辆监控方法的流程示意图，对本申请实施例中所提供的一种车辆监控方法进行描述说明。

参见图1所示，本申请实施例中所提供的一种车辆监控方法，包括：

S101、接收车辆的上报信息。

可选的，车辆的上报信息可以为在通信总线上各电子控制单元(ElectronicControl Unit，ECU)传输的信息。在与车辆建立有通信连接后，车辆上的各ECU即会不断上报车辆的各种信息。

S102、若接收到的上报信息中包括触发信息，则根据上报信息中与触发信息对应的关联信息，判断车辆是否异常。

在本申请实施例中，可以预先设定不同的触发条件，不同的触发条件可以被不同的信息(本文称触发信息)所触发，在触发条件被触发后，即表明需要进行车辆是否异常的判断。

在本申请实施例中，不同的触发条件可以对应需要判断车辆不同的异常。而不同的触发条件可以对应有不同的关联信息，从而用于判断车辆是否具有触发条件所对应的车辆异常。

示例性的，触发信息可以为表征AEB已开启的第一信息，此时对应的触发条件可以为接收到表征AEB已开启的第一信息，对应判断是否存在AEB异常。此时，上报信息中与触发信息对应的关联信息包括：车辆速度，车辆制动参数。

此时，参见图2所示，步骤S102可以包括：S21、根据车辆速度和车辆制动参数，确定车辆在AEB启动后的制动距离；S22、获得车辆与前方障碍物的实际距离；S23、判断实际距离和制动距离的偏差是否在预设偏差范围内；若是，转至步骤S24；否则，转至步骤S25；S24、确定车辆未异常；S25、确定车辆异常。

可选的，车辆制动参数可以包括：AEB触发条件成立到触发实际执行的时间差t₀、最大减速度a、车辆的急动度j，车辆的急动度为车辆加速度的变化率。由此，步骤S11确定车辆在AEB启动后的制动距离，具体过程可以为：计算加速度变化时间计算加速度稳定时车辆的速度根据AEB触发条件成立时车辆的速度v₀是否大于40km/h，得到以最大减速度使速度减到0或特定速度γ的时间t₂＝从而计算得到车辆在AEB启动后的制动距离

需要注意的是，γ的值是中国新车评价规程(China-New Car AssessmentProgram，C-NCAP)标准中的设定值。C-NCAP旨在评价中国市场车辆的安全性能，为消费者提供系统、客观的车辆安全参考信息，促进汽车企业按照更高的安全标准开发和生产，从而有效减少道路交通事故的伤害及损失。

可选的，步骤S14中预设偏差范围可以为制动距离s的90％至110％，即车辆与前方障碍物的实际距离位于制动距离s的90％至110％的范围内。若实际距离小于制动距离的预设偏差范围，此时表明车辆距离前方障碍物的实际距离过近，车辆制动后可能与前方障碍物发生碰撞。而若实际距离和制动距离大于制动距离的预设偏差范围，此时车辆可能在距离前方障碍物很远的地方开始制动，使车主的体验感差。因此，若实际距离和制动距离的偏差不在预设偏差范围内，即可以确定车辆异常，发出异常报警信息。此外，还可以针对上述两种不同的情况，发出不同的异常报警信息，以便于用户或者后端工程师区分异常情况。

需要说明的是，本申请实施例中所述的前方障碍物可以是前方车辆、车辆前方的人、车辆前方的建筑物等会对车辆行驶造成障碍的物体。

示例性的，触发信息也可以为表征ILC或HF请求人工接管的第二信息，上报信息中与触发信息对应的关联信息包括：驾驶员操作信息。

此时，可以参见图3所示，步骤S102可以包括：S31、根据驾驶员操作信息，判断驾驶员是否在接收到第二信息后的预设时长内接管车辆；若是，转至步骤S32；否则，转至步骤S33；S32、确定车辆未异常；S33、确定车辆异常。

需要注意的是，上述预设时长可以由工程师根据实际的车辆情况，或者根据大量的实验数据进行设置。

在上述示例中，当触发信息为ILC请求人工接管的第二信息时，驾驶员操作信息可以包括制动踏板参数、加速踏板参数、方向盘扭矩参数。

此时，步骤S31可以为根据制动踏板参数、加速踏板参数、方向盘扭矩参数与预设阈值的偏差，判断驾驶员是否接管车辆。例如，将获取到的制动踏板参数、加速踏板参数、方向盘扭矩参数分别与各自的预设阈值进行偏差计算，并判断各参数对应的偏差是否位于各参数对应的允许偏差范围内，若任一或者多个参数对应的偏差未位于对应的允许偏差范围内，则确定驾驶员未接管车辆。

还需要注意的是，触发信息为ILC请求人工接管的第二信息时，上报信息中与触发信息对应的关联信息还可以包括：车辆速度、横向加速度，纵向加速度。

在上述示例中，可以根据预设时间内车辆速度、横向加速度和纵向加速度的变化是否与制动踏板参数、加速踏板参数的变化相匹配，判断制动踏板参数和加速踏板参数是否正确，进而可以准确判断驾驶员是否接管车辆。例如，若预设时间内车辆速度、横向加速度和纵向加速度中的一个或多个变化与制动踏板参数不匹配，则确定制动踏板参数不可信，等待下次车辆上报信息。若预设时间内车辆速度、横向加速度和纵向加速度中的一个或多个变化与加速踏板参数不匹配，则确定加速踏板参数不可信，等待下次车辆上报信息。

此时，ILC请求人工接管的场景为车辆变道场景，根据制动踏板参数、加速踏板参数、方向盘扭矩参数可以较为快速、准确的判断驾驶员是否接管车辆，进行变道。

在上述示例中，触发信息可以为HF请求人工接管的第二信息时，驾驶员操作信息包括DMS状态变化参数、HOD状态变化参数。步骤S31可以为根据DMS状态变化参数和HOD状态变化参数，判断驾驶员是否接管车辆。例如，根据DMS状态变化参数表明驾驶员的注意力在车辆行驶上，HOD状态变化参数表明驾驶员握住方向盘，则确定驾驶员接管车辆。

此时，HF请求人工接管的场景为高速脱手状态，此时根据DMS状态变化参数和HOD状态变化参数可以较为快速、准确的判断驾驶员是否接管车辆。

还需要说明的是，在上述示例中，DMS状态变化参数包括表征驾驶员疲劳驾驶或分心的信息，第二信息对应的关联信息还可以包括表征车辆在非静止状态下打开车门或安全带的信息、表征整车控制器(Vehicle Control Unit，VCU)未就位的信息。此时，在上报信息中包括以上任一信息时，则可以确定HF请求人工接管的原因为对应的信息的产生原因，即HF请求人工接管的原因可以为驾驶员疲劳驾驶或分心，或者车辆在非静止状态下打开车门或安全带，或者VCU未就位等。这样可以快速确定HF请求人工接管的原因，有利于排除车辆异常。

还需要说明的是，触发信息在为第二信息时，第二信息对应的关联信息还可以包括：表征ACC异常的信息、表征TJA异常的信息。

此时，车辆监控方法还可以包括：若上报信息中具有表征ACC异常的信息，则确定第二信息的产生原因为ACC异常；若上报信息中具有表征TJA异常的信息，则确定第二信息的产生原因为TJA异常。

需要注意的是，在上报信息中同时存在多种可能导致第二信息产生的关联信息时，可以将这多种关联信息均作为第二信息的产生原因。

在本申请实施例中，在确定出第二信息的产生原因后，可以将第二信息、第二信息的关联信息和第二信息的产生原因发送给预设的工程师，这样可以便于预设的工程师快速确定异常原因，从而可以快速处理异常。

示例性的，上报信息中还可以包括表征加速度超过预设加速度阈值或安全气囊点爆的第三信息，上报信息中与第三信息对应的关联信息可以包括：AEB开启状态信息、AEB触发状态信息。需要注意的是，AEB处于开启状态，但是AEB没有接收到触发信号，则AEB处于没有工作状态，只有AEB处于开启状态，且AEB触发，则AEB处于工作状态。

在上报信息中包括第三信息时，参见图4，车辆监控方法还包括：S41、根据AEB开启状态信息，判断车辆的AEB是否处于开启状态；S42、若AEB处于关闭状态，则发送异常报警信号；S43、若AEB处于开启状态，则根据AEB触发状态信息，判断车辆的AEB是否触发；S44、若AEB已触发，则判断AEB是否异常触发；若AEB异常触发，则将上报信息和关联信息发送给预设的误触发场景库；S45、若AEB未触发，则判断AEB是否异常未触发；若AEB异常未触发，则将上报信息和关联信息发送给预设的漏触发场景库。其中，误触发场景库中存储的是确定为误触发AEB时的上报信息和关联信息，漏触发场景库中存储的是确定为漏触发AEB时的上报信息和关联信息，以便技术人员后续分析管控。其中，误触发场景库和漏触发场景库可以通过数据库实现。

需要说明的是，上报信息中包括第三信息时，说明车辆处于较为危险的状态。此时：若AEB处于关闭状态，则发送异常报警信号，提醒车主打开AEB功能，提升车辆的安全性；若AEB处于开启状态且已触发，则车辆初步判定结果为AEB请求紧急制动，若结合上述AEB异常判定方法，确定AEB为异常触发，则将上报信息和关联信息发送给预设的误触发场景库，也可以通知预设技术人员主动联系驾驶员，了解情况并提供技术支持；若AEB处于开启状态且未触发，则初步判定为驾驶员主动请求紧急制动，若根据上述AEB异常判定方法，确定AEB异常未触发，则将上报信息和关联信息发送给预设的漏触发场景库，以便技术人员进行分析管控。这样，可以对车辆运行阶段的安全进行进一步预警，可以进一步降低事故发生的概率。

示例性的，上报信息中也可以包括表征雷达失明或摄像头被遮挡的第四信息，上报信息中与第四信息对应的关联信息可以包括：表征预设关联功能是否异常的预警信息和表征是否存在遮挡事件的遮挡信息。上报信息中包括第四信息时，参见图5所示，车辆监控方法还包括：S51、根据预警信息，判断预设关联功能是否触发异常预警；S52、若未触发异常预警，则根据遮挡信息确定是否存在遮挡事件；S53、若存在遮挡事件，确定预设关联功能异常。

还需要说明的是，在本申请实施例中，上报信息中包括表征雷达失明的信息时，预设关联功能可以包括：ACC功能、TJA功能、AEB功能等功能中的至少一种。上报信息中包括摄像头被遮挡的信息时，预设关联功能可以包括：AEB功能、TJA功能、车道偏移预警(LaneDeparture Warning，LDW)、车道保持辅助系统(Lane Keeping Assist，LKA)等功能中的至少一种。需要理解的是，以上示例的预设关联功能仅为本申请中提供的几种可供采用的关联功能，在实际应用过程中，也可以采用完全不同的其他功能作为雷达失明的信息或摄像头被遮挡的信息的预设关联功能，具体应以车辆的实际功能配置为准，在本申请实施例中不做限制。

还需要说明的是，上报信息中包括第四信息时，若未触发异常预警，且不存在遮挡信息时，可以将第四信息和与第四信息对应的关联信息发送给预设工程师，以便预设工程师排查车辆出现的问题。若触发异常报警，则将车辆所处的地理位置和所述地理位置的天气信息，发送给预设知识库，当车辆下次遇到相同或相似的情况时，主动提醒驾驶员。

S103、若车辆异常，则发送异常报警信号。

若车辆出现异常，则可以向车辆发送异常报警信号，以提醒车主打开对应的功能，或排查车辆问题，以消除车辆故障。

还需要说明的是，在本申请实施例中，可以将车辆的异常情况划分等级，车辆的不同异常等级对应不同的处理方法。例如，可以将车辆的异常情况划分为高风险等级、中风险等级和低风险等级。

示例性的，高风险等级的处理方法可以为将上报信息中的触发信息、关联信息、和/或异常原因发送给预设的工程师，并向车辆发送异常报警信号。中风险等级的处理方法可以为将上报信息中的触发信息、关联信息、和/或异常原因发送给预设的工程师。低风险等级的处理方法可以为在后端中进行预警并记录，对异常情况进行持续跟踪。

在本申请实施例中，异常等级还可以存在等级升级机制。可选的，可以设置中风险等级的异常事件单日内出现3次或单月内出现10次，将升级为高风险等级的异常事件。低风险等级的异常事件单日内出现5次或单月内出现15次将升级为中风险等级的异常事件。应理解，以上仅为本申请实施例提供的一种示例性的等级升级机制，不代表本申请实施例中仅可采用上述等级升级机制，事实上，本申请对异常等级的等级升级机制不作限制。

在本申请实施例中，高风险等级的异常事件可以包括：1、AEB触发；2、包括以下任一情况导致的ACC退出：车辆动态控制系统(Vehicle Dynamics Control，VDC)激活、防抱死系统(Antilock Brake System，ABS)激活、牵引力控制系统(Traction Control System，TCS)激活、制动盘过热、制动力不足、驾驶员侧车门打开、安全带打开；3、包括以下任一情况导致的TJA退出：ACC高风险等级异常、车辆横向功能请求接管；4、包括以下任一情况导致的ILC请求接管：ACC高风险等级异常、TJA高风险等级异常；5、包括以下任一情况导致的HF请求接管：ACC高风险等级异常、TJA高风险等级异常、DMS显示驾驶员重度疲劳或分心、车辆非静止状态下打开车门或安全带、VCU未就位。

中风险等级的异常事件可以包括：1、包括以下任一情况导致的ACC退出：制动踏板踩下、车身电子稳定控制系统(Electronic Stability Program，ESP)关闭、TCS关闭、溜坡；2、包括以下任一情况导致的TJA退出：ACC中风险等级异常、危险报警灯开启、横摆角速率过高、油门开度斜率大于预设油门开度阈值；3、包括以下任一情况导致的ILC请求接管：ACC中风险等级异常、TJA中风险等级异常、车道线识别丢失、车辆状态超过可控阈值；4、包括以下任一情况导致的HF请求接管：AEB故障、AEB行人探测故障、胎压检测报警、摄像头失明、DMS显示驾驶员中度疲劳或分心。

低风险等级的异常事件可以为其他异常情况。

但是，以上对于高风险等级、中风险等级和低风险等级的异常情况的设定仅为本申请实施例所提供的一种可选示例，不作为对本申请实施例的限制。

通过为车辆的异常情况划分等级，车辆的不同异常等级对应不同的处理方式，可以更加有效的处理车辆的异常情况，避免车辆问题的扩大。异常等级升级机制可以进一步的避免车辆问题的扩大，造成不可控的风险。

需要注意的是，本申请实施例中所述的车辆可以为具有自动驾驶功能的车辆，此外也可以为其他车辆，在本申请实施例中不做限制。

综上，本申请实施例提供一种车辆监控方法，若接收到的上报消息中包括触发信息，则根据上报信息中与触发信息对应的关联信息，判断车辆是否异常，若车辆异常，则发送异常报警信号。这样，可以实现对车辆状态的实时监控，对车辆出现的问题进行主动预警，避免车辆问题的扩大。

实施例二：

基于同一发明构思，本申请实施例中还提供一种车辆监控装置600，请参阅图6所示。应理解，装置600具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置600包括至少一个能以软件或固件的形式存储于存储器中或固化在装置600的操作系统中的软件功能模块。具体地：

参见图6所示，装置600包括：接收模块601、判断模块602和报警模块603。其中：

接收模块601，用于接收车辆的上报信息；

判断模块602，用于若接收到的所述上报信息中包括触发信息，则根据所述上报信息中与所述触发信息对应的关联信息，判断所述车辆是否异常；

报警模块603，用于若所述车辆异常，则发送异常报警信号。

在本申请实施例的一种可行实施方式中，触发信息为表征AEB已开启的第一信息，上报信息中与触发信息对应的关联信息包括：车辆速度，车辆制动参数；所述判断模块602还用于，根据车辆速度和车辆制动参数，确定车辆在AEB启动后的制动距离；获得车辆与前方障碍物的实际距离；判断实际距离和制动距离的偏差是否在预设偏差范围内；若是，确定车辆未异常；否则，确定车辆异常。

在本申请实施例的一种可行实施方式中，触发信息为表征ILC或HF请求人工接管的第二信息，上报信息中与触发信息对应的关联信息包括：驾驶员操作信息；所述判断模块602还用于，根据驾驶员操作信息，判断驾驶员是否接管车辆；若驾驶员在接收到第二信息后的预设时长内接管车辆，则确定车辆未异常，否则，确定车辆异常。

在上述可行实施方式中，触发信息为表征ILC请求人工接管的第二信息，驾驶员操作信息包括制动踏板参数、加速踏板参数、方向盘扭矩参数；所述判断模块602还用于，根据制动踏板参数、加速踏板参数、方向盘扭矩参数与预设阈值的偏差，判断驾驶员是否接管所述车辆。

在上述可行实施方式中，触发信息为表征HF请求人工接管的第二信息，驾驶员操作信息包括DMS状态变化参数、HOD状态变化参数；所述判断模块602还用于，根据DMS状态变化参数和HOD状态变化参数，判断驾驶员是否接管所述车辆。

在上述可行实施方式中，第二信息对应的关联信息包括表征ACC异常的信息、表征TJA异常的信息；装置600还包括处理模块604，用于若上报信息中具有表征ACC异常的信息，则确定第二信息的产生原因为ACC异常；若上报信息中具有表征TJA异常的信息，则确定第二信息的产生原因为TJA异常。

在本申请实施例的一种可行实施方式中，上报信息中包括表征加速度超过预设加速度阈值或安全气囊点爆的第三信息，上报信息中与第三信息对应的关联信息包括：AEB开启状态信息、AEB触发状态信息；处理模块604，还用于根据AEB开启状态信息，判断车辆的AEB是否处于开启状态；若AEB处于关闭状态，则发送异常报警信号；若AEB处于开启状态，则根据AEB触发状态信息，判断车辆的AEB是否触发；若AEB已触发，则判断AEB是否异常触发；若AEB异常触发，则将上报信息和关联信息发送给预设的误触发场景库；若AEB未触发，则判断AEB是否异常未触发；若AEB异常未触发，则将上报信息和关联信息发送给预设的漏触发场景库。

在本申请实施例的一种可行实施方式中，上报信息中包括表征雷达失明或摄像头被遮挡的第四信息，上报信息中与第四信息对应的关联信息包括：表征预设关联功能是否异常的预警信息和表征是否存在遮挡事件的遮挡信息；处理模块604，还用于根据预警信息，判断预设关联功能是否触发异常预警；若未触发异常预警，则根据遮挡信息确定是否存在遮挡事件；若存在遮挡事件，确定预设关联功能异常。

需要理解的是，出于描述简洁的考量，部分实施例一中描述过的内容在本实施例中不再赘述。

实施例四：

本申请实施例提供了一种电子设备，参见图7所示，其包括处理器701、存储器702以及通信总线703。其中：

通信总线703用于实现处理器701和存储器702之间的连接通信。

处理器701用于执行存储器702中存储的一个或多个程序，以实现上述实施例一中提供的车辆监控方法。

可以理解，图7所示的结构仅为示意，电子设备还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。

可以理解，本申请实施例中所述的电子设备可以是具有与车辆进行通信的功能且具有数据处理功能的主机、服务器等设备，但不作为限制。

此外，本申请实施例中也可以由多个电子设备构成的集群来作为一个整体，共同实现上述实施例一中提供的车辆监控方法。

本申请实施例还提供了一种可读存储介质，如软盘、光盘、硬盘、闪存、U盘、SD(Secure Digital Memory Card，安全数码卡)卡、MMC(Multimedia Card，多媒体卡)卡等，在该可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述实施例一中的一种车辆监控方法所执行的各步骤。在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

在本文中，多个是指两个或两个以上。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。