1.本技术涉及自动驾驶技术领域，特别涉及一种车辆传感器故障诊断方法、装置、车辆及存储介质。
背景技术：2.随着自动驾驶技术如火如荼的发展，各种自动驾驶的相关技术也层出不穷。想要实现真正的无人驾驶，车辆的感知装备必不可少，这些感知传感器就相当于自动驾驶车辆的眼睛用于感知周围的环境，可以通过对当前环境的检测后进行下一步的决策规划与控制。
3.随着当前交通环境的复杂性、变化性，自动驾驶车辆所装备的感知传感器的种类越来越多，包括：摄像头(前置、环视以及单目、双目或三目摄像头)、激光雷达(单线/4/16/32/64线等)、毫米波雷达、超声波雷达(多个数量)等等。为了在复杂的交通路况中更好的实现车辆的自动驾驶功能，往往需要将上述的传感器进行融合使用。
4.随着传感器的增加，往往也使自动驾驶车辆的感知融合算法以及控制系统的复杂度增加。更重要的是当这些传感器出现故障时，如果不能及时发现是何种故障的话，便对整个自动驾驶车辆产生影响，可能会导致一些安全问题。然而，相关技术中对于自动驾驶车辆的这些感知传感器的各种故障，并没有一套完整的诊断体系来进行监测或提醒。
技术实现要素：5.本技术提供一种车辆传感器故障诊断方法、装置、车辆及存储介质，以解决相关技术中无法对自动驾驶车辆的感知传感器进行统一管理，降低故障诊断的实时性和准确性，降低自动驾驶的安全性和可靠性等问题。
6.本技术第一方面实施例提供一种车辆传感器故障诊断方法，包括以下步骤：获取车辆的一个或多个感知传感器的实际运行参数；基于所述一个或多个感知传感器的实际运行参数，由所述车辆的autosar架构规定的标准规范识别所述车辆的当前故障，生成故障信息；根据所述故障信息定位所述一个或多个感知传感器中至少一个故障传感器，并基于所述故障信息匹配对应的实际故障类型和/或当前故障等级，根据所述实际故障类型和/或所述当前故障等级控制所述车辆执行目标动作。
7.进一步地，所述autosar架构包括驱动层、服务层和应用层，其中，所述驱动层中封装有所有传感器的硬件驱动，所述服务层中设置有诊断模块，所述应用层中设置有所述车辆的控制算法和规划算法。
8.进一步地，所述当前故障等级包括第一至第三故障等级，根据所述当前故障等级所述车辆执行目标动作，包括：当所述故障等级为第一故障等级时，控制所述车辆进行故障报警提醒的同时，控制所述车辆停车，并限制所述车辆启动直到故障排除；当所述故障等级为第二故障等级时，控制所述车辆进行故障报警提醒的同时，在车辆停车后进行维修提醒；当所述故障等级为第三故障等级时，控制所述车辆进行故障报警提醒。
9.可选地，所述实际故障类型可以包括硬件驱动故障、外在环境干扰故障、接口故障和/或感知算法调度故障。
10.本技术第二方面实施例提供一种车辆传感器故障诊断装置，包括：获取模块，用于获取车辆的一个或多个感知传感器的实际运行参数；识别模块，用于基于所述一个或多个感知传感器的实际运行参数，由所述车辆的autosar架构规定的标准规范识别所述车辆的当前故障，生成故障信息；诊断模块，用于根据所述故障信息定位所述一个或多个感知传感器中至少一个故障传感器，并基于所述故障信息匹配对应的实际故障类型和/或当前故障等级，根据所述实际故障类型和/或所述当前故障等级控制所述车辆执行目标动作。
11.进一步地，所述autosar架构包括驱动层、服务层和应用层，其中，所述驱动层中封装有所有传感器的硬件驱动，所述服务层中设置有所述诊断模块，所述应用层中设置有所述车辆的控制算法和规划算法。
12.进一步地，所述当前故障等级包括第一至第三故障等级，所述诊断模块进一步用于：当所述故障等级为第一故障等级时，控制所述车辆进行故障报警提醒的同时，控制所述车辆停车，并限制所述车辆启动直到故障排除；当所述故障等级为第二故障等级时，控制所述车辆进行故障报警提醒的同时，在车辆停车后进行维修提醒；当所述故障等级为第三故障等级时，控制所述车辆进行故障报警提醒。
13.可选地，所述实际故障类型可以包括硬件驱动故障、外在环境干扰故障、接口故障和/或感知算法调度故障。
14.本技术第三方面实施例提供一种车辆，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如上述实施例所述的车辆传感器故障诊断方法。
15.本技术第四方面实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以用于实现如上述实施例所述的车辆传感器故障诊断方法。
16.由此，本技术至少具有如下有益效果：
17.可以基于autosar架构规定的标准规范对自动驾驶车辆的感知传感器进行统一管理，提升故障诊断的实时性和准确性，可以在传感器出现故障时，能够更加方便的进行故障的确认和修复，提升自动驾驶的安全性和可靠性。由此，解决了相关技术中无法对自动驾驶车辆的感知传感器进行统一管理，降低故障诊断的实时性和准确性，降低自动驾驶的安全性和可靠性等技术问题。
18.本技术附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本技术的实践了解到。
附图说明
19.本技术上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
20.图1为根据本技术实施例提供的车辆传感器故障诊断方法的流程示意图；
21.图2为根据本技术实施例提供的车辆传感器故障诊断系统的结构示意图；
22.图3为根据本技术一个实施例提供的车辆传感器故障诊断方法的流程示意图；
23.图4为根据本技术实施例提供的车辆传感器故障诊断装置的方框示意图；
24.图5为根据本技术实施例提供的车辆的结构示意图。
具体实施方式
25.下面详细描述本技术的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本技术，而不能理解为对本技术的限制。
26.下面参考附图描述本技术实施例的车辆传感器故障诊断方法、装置、车辆及存储介质。针对上述背景技术中提到的相关技术中无法对自动驾驶车辆的感知传感器进行统一管理，降低故障诊断的实时性和准确性，降低自动驾驶的安全性和可靠性的问题，本技术提供了一种车辆传感器故障诊断方法，在该方法中，可以基于autosar架构规定的标准规范对自动驾驶车辆的感知传感器进行统一管理，提升故障诊断的实时性和准确性，可以在传感器出现故障时，能够更加方便的进行故障的确认和修复，提升自动驾驶的安全性和可靠性。由此，解决了相关技术中无法对自动驾驶车辆的感知传感器进行统一管理，降低故障诊断的实时性和准确性，降低自动驾驶的安全性和可靠性等技术问题。
27.具体而言，图1为本技术实施例所提供的一种车辆传感器故障诊断方法的流程示意图。
28.如图1所示，该车辆传感器故障诊断方法包括以下步骤：
29.在步骤s101中，获取车辆的一个或多个感知传感器的实际运行参数。
30.其中，本技术实施例的车辆可以指自动驾驶车辆；自动驾驶车辆感知传感器可以包括摄像头、毫米波雷达、超声波雷达、激光雷达等，传感器的数量可以根据自动驾驶车辆实现功能所需具体设置，不做具体限定。以下实施例中以摄像头、毫米波雷达、超声波雷达、激光雷达等感知传感器为例进行阐述。
31.在步骤s102中，基于一个或多个感知传感器的实际运行参数，由车辆的autosar架构规定的标准规范识别车辆的当前故障，生成故障信息。
32.可以理解的是，本技术实施例可以通过对上面的提及的各种感知传感器进行归纳整理(硬件驱动、故障类型)，并将其融合到autosar架构中，这样能够提供一种统一的架构标准来对自动驾驶车辆的感知传感器的接口使用，故障诊断进行规范化，从而可以基于autosar架构下自动驾驶车辆感知传感器的故障诊断，autosar架构提供了接口的标准化，方便应用功能集成与转换，以及网络的优化。
33.在本技术实施例中，autosar架构包括驱动层、服务层和应用层，其中，驱动层中封装有所有传感器的硬件驱动，服务层中设置有诊断模块，应用层中设置有车辆的控制算法和规划算法。
34.可以理解的是，如图2所示，自动驾驶车辆的autosar架构需要在一个特定的硬件平台上实现，autosar架构包括：微控制器层、基础软件层(微控制器抽象层、ecu抽象层、服务层、复杂设备驱动)、运行环境、应用软件层等。本技术实施例可以将感知传感器的硬件驱动的管理放置于autosar的复杂驱动层中，在复杂驱动中对感知传感器进行驱动初始化，接口调用函数等功能封装；自动驾驶车辆感知传感器的诊断模块位于autosar架构中的服务层中，用于故障诊断。
35.具体而言，如图2所示，本技术实施例涉及感知传感器的统一调度的autosar软件
架构平台、涉及不同感知传感器的故障单元等，且自动驾驶车辆的所有的算法功能、各传感器调用以及autosar架构的布置均需通过固定的硬件平台来实现。其中，
36.(1)自动驾驶车辆的功能、控制、规划算法等均可以放置于autosar架构下的应用层中来实现；
37.(2)复杂驱动层统一放置自动驾驶车辆的感知传感器的驱动相关的初始化、接口调用，调用函数规范化等内容，具体地：将自动驾驶车辆的感知传感器的硬件驱动归纳进autosar的基础软件层中的复杂设备驱动中进行统一，包括各感知传感器的初始化、驱动的调用接口、调用函数的标准统一等；
38.(3)将前面所提及的各感知传感器的故障的诊断服务放在基础软件层中的服务层中，当感知传感器发生故障后，就需要通过服务层中的总线通信管理服务将故障类型发送出去，传输方式为can通信发送。
39.在步骤s103中，根据故障信息定位一个或多个感知传感器中至少一个故障传感器，并基于故障信息匹配对应的实际故障类型和/或当前故障等级，根据实际故障类型和/或当前故障等级控制车辆执行目标动作。
40.其中，自动驾驶车辆的各感知传感器的故障需要进行故障类型分类，故障类型包括：硬件驱动故障、外在环境干扰(如温度、辐射、异物遮挡等)、接口故障、感知算法调度故障等，更多的感知传感器的故障类型可以在具体的自动驾驶过程中来进行更加详细地划分，对此不作具体限定；当前故障等级包括第一至第三故障等级，故障的优先级越高表明当前故障对自动驾驶车辆功能影响越大，第一故障等级可以设置为最高优先级故障。
41.可以理解的是，本技术实施例可以利用位于autosar架构中的服务层中的诊断模块对自动驾驶车辆的感知传感器的故障类型实行划分，并对自动驾驶车辆的各感知传感器的故障进行故障优先级划分，按照故障对整个自动驾驶功能造成的影响来确定故障事件的等级，造成的影响越大，则故障事件优先级越高，然后可以根据实际故障类型和/或当前故障等级控制车辆进行报警提醒、停车、限速等，以提升自动驾驶车辆的安全性和稳定性，并可以使得用户及时获取车辆的故障信息，提升用户的使用体验。
42.在本技术实施例中，根据当前故障等级控制车辆执行目标动作，包括：当故障等级为第一故障等级时，控制车辆进行故障报警提醒的同时，控制车辆停车，并限制车辆启动直到故障排除；当故障等级为第二故障等级时，控制车辆进行故障报警提醒的同时，在车辆停车后进行维修提醒；当故障等级为第三故障等级时，控制车辆进行故障报警提醒。
43.具体而言，如图3所示，感知传感器的故障类型划分过后，需要对每种故障类型进行相对应的故障优先级划分，故障优先级划分为三个等级，分别为ⅰ级、ⅱ级、ⅲ级，其中ⅰ级为优先级最高的故障事件等级，一次类推，ⅰ级故障事件是指当感知传感器发生故障后，严重影响到自动驾驶车辆的正常行驶或严重影响到自动驾驶车辆的安全性，需要自动驾驶车辆终端服务器做出迅速的响应，如人工接管或远程进行安全靠边停车等待人工故障排除等。ⅱ级故障事件指当某个感知传感器或多个感知传感器发生故障时，自动驾驶车辆的正常功能不受影响，但是会造成潜在的安全影响，这种故障的发生不需要立即进行排除，可以是在某一次行动完成后再去排除该故障。ⅲ级故障事件是指那些轻微的感知传感器的故障，该故障发生时，在很短的时间内可以完全自动消除，且对自动驾驶车辆的功能不造成影响。
44.在对感知传感器的故障的优先级进行划分过后，当自动驾驶车辆在正常行驶过程中出现某个或多个传感器的故障后，根据图2中的诊断模块的判断，确认当前感知传感器的故障类型与故障优先等级，通过通信模块发送给自动驾驶车辆的终端车辆控制服务器平台进行报警提醒，同时与显示屏模块进行通信进行报警提醒，显示相关感知传感器的故障类型和优先级，便于感知传感器故障的修复以及自动驾驶车辆的正常维护，提高自动驾驶车辆的形式的安全性与稳定性。
45.综上，本技术实施例提供了提供便于自动驾驶车辆传感器故障诊断及管理的方案，通过统一的架构标准，对自动驾驶车辆的各传感器所出现的故障类型以及产生的故障事件的优先级进行了统一规划管理。由于引入了autosar架构，各感知传感器的接口调用、初始化等以及故障事件显示函数更加规范化，便于代码管理，因此当感知传感器出现故障时，能够通过总线通信对传感器的故障进行诊断并能够进行报警，有利于后续故障的排查修复，同时提高了自动驾驶车辆的行驶的安全性与稳定性。
46.其次参照附图描述根据本技术实施例提出的车辆传感器故障诊断装置。
47.图4是本技术实施例的车辆传感器故障诊断装置的方框示意图。
48.如图4所示，该车辆传感器故障诊断装置10包括：获取模块100、识别模块200和诊断模块300。
49.其中，获取模块100用于获取车辆的一个或多个感知传感器的实际运行参数；识别模块200用于基于一个或多个感知传感器的实际运行参数，由车辆的autosar架构规定的标准规范识别车辆的当前故障，生成故障信息；诊断模块300用于根据故障信息定位一个或多个感知传感器中至少一个故障传感器，并基于故障信息匹配对应的实际故障类型和/或当前故障等级，根据实际故障类型和/或当前故障等级控制车辆执行目标动作。
50.在本技术实施例中，autosar架构包括驱动层、服务层和应用层，其中，驱动层中封装有所有传感器的硬件驱动，服务层中设置有诊断模块，应用层中设置有车辆的控制算法和规划算法。
51.在本技术实施例中，当前故障等级包括第一至第三故障等级，诊断模块300进一步用于：当故障等级为第一故障等级时，控制车辆进行故障报警提醒的同时，控制车辆停车，并限制车辆启动直到故障排除；当故障等级为第二故障等级时，控制车辆进行故障报警提醒的同时，在车辆停车后进行维修提醒；当故障等级为第三故障等级时，控制车辆进行故障报警提醒。
52.在本技术实施例中，实际故障类型可以包括硬件驱动故障、外在环境干扰故障、接口故障和/或感知算法调度故障。
53.需要说明的是，前述对车辆传感器故障诊断方法实施例的解释说明也适用于该实施例的车辆传感器故障诊断装置，此处不再赘述。
54.根据本技术实施例提出的车辆传感器故障诊断装置，可以基于autosar架构规定的标准规范对自动驾驶车辆的感知传感器进行统一管理，提升故障诊断的实时性和准确性，可以在传感器出现故障时，能够更加方便的进行故障的确认和修复，提升自动驾驶的安全性和可靠性。
55.图5为本技术实施例提供的车辆的结构示意图。该车辆可以包括：
56.存储器501、处理器502及存储在存储器501上并可在处理器502上运行的计算机程
序。
57.处理器502执行程序时实现上述实施例中提供的车辆传感器故障诊断方法。
58.进一步地，车辆还包括：
59.通信接口503，用于存储器501和处理器502之间的通信。
60.存储器501，用于存放可在处理器502上运行的计算机程序。
61.存储器501可能包含高速ram(random access memory，随机存取存储器)存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。
62.如果存储器501、处理器502和通信接口503独立实现，则通信接口503、存储器501和处理器502可以通过总线相互连接并完成相互间的通信。总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component，外部设备互连)总线或eisa(extended industry standard architecture，扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
63.可选的，在具体实现上，如果存储器501、处理器502及通信接口503，集成在一块芯片上实现，则存储器501、处理器502及通信接口503可以通过内部接口完成相互间的通信。
64.处理器502可能是一个cpu(central processing unit，中央处理器)，或者是asic(application specific integrated circuit，特定集成电路)，或者是被配置成实施本技术实施例的一个或多个集成电路。
65.本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的车辆传感器故障诊断方法。
66.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或n个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
67.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本技术的描述中，“n个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
68.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更n个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本技术的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本技术的实施例所属技术领域的技术人员所理解。
69.应当理解，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，n个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技
术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列，现场可编程门阵列等。
70.本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。