自动驾驶车辆的自检方法、装置、系统及电子设备与流程

1.本技术涉及自动驾驶技术领域，尤其涉及一种自动驾驶车辆的自检方法、装置、系统及电子设备。


背景技术：

2.自动驾驶功能的研发人员在进行业务需求研发的同时，还需要保证交付项目的稳定性和解决问题的时效性，在现有的自动驾驶车辆无自检模块的环境下，研发人员需要长时间乘坐在自动驾驶车辆上，准备电脑数据线等多个联调设备，且由于自动驾驶路段需要进行多种速度及环境的测试，无法保证车辆平稳行驶的驾驶环境，因此在较为不稳定的驾驶环境下，研发人员即要顾及自身安全，又要及时查看问题日志，是一个非常耗时、且相对不安全的状态。
3.自动驾驶车辆的行驶需要保证良好的连接状态，才能保证自动驾驶车辆的安全、稳定运行以及驾驶过程中的业务能力支持。自动驾驶车辆的连接状态主要包括车端应用与车端工控机的连接状态、车端应用与云端的连接状态以及车端工控机与云端的连接状态，任意一个数据传输链路的连接异常都可能对自动驾驶车辆的行驶过程造成较大影响。但现有技术中缺少一种对于自动驾驶车辆的连接状态进行高效检测的方案，如果自动驾驶车辆在行驶过程中，某个数据传输链路的连接出现问题，往往需要技术人员跟车查询、复现、定位、解决，整个过程不仅耗时，而且人力成本高。
4.此外，自动驾驶车辆在行驶过程中，如果自动驾驶功能突然出现异常，驾驶员或其他非技术人员无法对错误节点及时进行有效排查，需要异常车辆的相关技术人员到场，进行复杂的复现流程沟通以及代码日志跟踪，尤其在多车协作过程中，技术人员数量有限，无法做到及时有效的问题跟踪，进而导致目前的自动驾驶车辆的检测方案低效、成本高。


技术实现要素：

5.本技术实施例提供了一种自动驾驶车辆的自检方法、装置、系统及电子设备，以提高自动驾驶车辆的自检效率，节省故障排查时间。
6.本技术实施例采用下述技术方案：
7.第一方面，本技术实施例提供一种自动驾驶车辆的自检方法，其中，所述方法由车端执行，所述方法包括：
8.获取自动驾驶车辆的连接状态检测任务；
9.根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果，所述连接状态检测结果包括车端应用与车端工控机的连接状态检测结果、车端应用与云端的连接状态检测结果以及车端工控机与云端的连接状态检测结果；
10.在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务；
11.根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果；
12.根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果。
13.可选地，所述根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果包括：
14.根据所述连接状态检测任务，检测所述自动驾驶车辆的连接状态，得到所述连接状态检测结果；和/或，
15.根据所述连接状态检测任务，接收云端反馈的自动驾驶车辆的连接状态检测结果。
16.可选地，在根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果之后，所述方法还包括：
17.在所述连接状态检测结果为正常连接状态的情况下，通过所述车端应用与车端工控机的连接，在所述车端应用与所述车端工控机之间进行第一数据的传输；
18.在所述连接状态检测结果为正常连接状态的情况下，通过所述车端应用与云端的连接，在所述车端应用与所述云端之间进行第二数据的传输；
19.在所述连接状态检测结果为正常连接状态的情况下，通过所述车端工控机与云端的连接，在所述车端工控机与所述云端之间进行第三数据的传输。
20.可选地，所述在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务包括：
21.在所述车端应用与车端工控机的连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务。
22.可选地，所述获取对应的节点状态检测任务包括：
23.确定所述自动驾驶车辆的驾驶状态；
24.在所述自动驾驶车辆的驾驶状态为自动驾驶状态时，获取第一节点状态检测任务，所述第一节点状态检测任务包含第一节点状态检测频率；
25.在所述自动驾驶车辆的驾驶状态为非自动驾驶状态时，获取第二节点状态检测任务，所述第二节点状态检测任务包含第二节点状态检测频率；
26.其中，所述第一节点状态检测频率大于所述第二节点状态检测频率。
27.可选地，所述根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果包括：
28.按照第一预设显示策略，将所述连接状态检测结果在所述车端进行显示，所述第一预设显示策略包含连接类型和连接状态检测结果的描述信息；
29.按照第二预设显示策略，将所述节点状态检测结果在所述车端进行显示，所述第二预设显示策略包含节点类型、节点名称和节点状态检测结果的描述信息。
30.可选地，所述节点状态检测结果包括异常节点，在根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果之后，所述方法还包括：
31.确定所述异常节点的节点类型；
32.根据所述异常节点的节点类型，确定对应的故障处理策略，以通过所述故障处理策略对所述异常节点进行处理。
33.可选地，在根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节
点状态检测结果，确定所述自动驾驶车辆的自检结果之后，所述方法还包括：
34.获取所述自动驾驶车辆的自检结果上报任务；
35.根据自检结果上报任务，将所述自动驾驶车辆的自检结果上报至所述云端。
36.第二方面，本技术实施例还提供一种自动驾驶车辆的自检装置，其中，所述装置应用于车端，所述装置包括：
37.第一获取单元，用于获取自动驾驶车辆的连接状态检测任务；
38.连接状态检测单元，用于根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果，所述连接状态检测结果包括车端应用与车端工控机的连接状态检测结果、车端应用与云端的连接状态检测结果以及车端工控机与云端的连接状态检测结果；
39.第二获取单元，用于在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务；
40.节点状态检测单元，用于根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果；
41.第一确定单元，用于根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果。
42.第三方面，本技术实施例还提供一种自动驾驶车辆的自检系统，其中，所述系统包括车端和云端，所述车端包括车端应用和车端工控机，所述车端用于执行前述之任一所述方法。
43.第四方面，本技术实施例还提供一种电子设备，包括：
44.处理器；以及
45.被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行前述之任一所述方法。
46.第五方面，本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行前述之任一所述方法。
47.本技术实施例采用的上述至少一个技术方案能够达到以下有益效果：本技术实施例的自动驾驶车辆的自检方法由车端执行，先获取自动驾驶车辆的连接状态检测任务；根据连接状态检测任务，获取自动驾驶车辆的连接状态检测结果，连接状态检测结果包括车端应用与车端工控机的连接状态检测结果、车端应用与云端的连接状态检测结果以及车端工控机与云端的连接状态检测结果；在连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务；根据节点状态检测任务，确定自动驾驶车辆的节点状态检测结果；根据自动驾驶车辆的连接状态检测结果和自动驾驶车辆的节点状态检测结果，确定自动驾驶车辆的自检结果。本技术实施例的自动驾驶车辆的自检方法基于自动驾驶场景的特殊性，对车端应用-工控机-云端三端的连接状态以及自动驾驶车辆中的各节点状态进行了高效检测，节省了故障排查时间，满足了自动驾驶场景对于高效性、安全性和可靠性的要求。
附图说明
48.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本申
请的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
49.图1为本技术实施例中一种自动驾驶车辆的自检方法的流程示意图；
50.图2为本技术实施例中一种自动驾驶车辆的连接状态检测结果的显示界面示意图；
51.图3为本技术实施例中一种硬件节点的节点状态检测结果的显示界面示意图；
52.图4为本技术实施例中一种软件节点的节点状态检测结果的显示界面示意图
53.图5为本技术实施例中一种自动驾驶车辆的自检装置的结构示意图；
54.图6为本技术实施例中一种自动驾驶车辆的自检系统的架构示意图；
55.图7为本技术实施例中一种电子设备的结构示意图。
具体实施方式
56.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
57.以下结合附图，详细说明本技术各实施例提供的技术方案。
58.本技术实施例提供了一种自动驾驶车辆的自检方法，如图1所示，提供了本技术实施例中一种自动驾驶车辆的自检方法的流程示意图，所述方法由车端执行，所述方法至少包括如下的步骤s110至步骤s140：
59.步骤s110，获取自动驾驶车辆的连接状态检测任务。
60.本技术实施例的自动驾驶车辆的自检方法可以由车端也即自动驾驶车辆来执行，本技术实施例的车端主要包括车端应用(如鹰眼app)和车端工控机两部分，车端应用主要发挥的作用是基础数据的接收、渲染以及云端预警能力的呈现，车端工控机可以看作是车端的核心系统，用于负责对车端应用一些业务能力的支持以及作为一些核心数据的中间传输者。
61.由于自动驾驶车辆的连接状态是实现大部分自动驾驶功能的基础，因此本技术实施例在进行自动驾驶车辆的自检时，需要先获取自动驾驶车辆的连接状态检测任务，该连接状态检测任务具体可以由车端应用来创建和执行，连接状态检测任务的具体检测频率可以根据实际业务场景和实际需求灵活设置，在此不作具体限定。
62.步骤s120，根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果，所述连接状态检测结果包括车端应用与车端工控机的连接状态检测结果、车端应用与云端的连接状态检测结果以及车端工控机与云端的连接状态检测结果。
63.本技术实施例检测的自动驾驶车辆的连接状态主要包括车端应用与车端工控机的连接状态、车端应用与云端的连接状态以及车端工控机与云端的连接状态，即三端连接状态。
64.具体地，车端应用与车端工控机处于时刻互联的状态，主要用于完成车端应用的感知数据、定位数据的传输、接收，以及业务场景能力反控的支持，如车端应用触发、结束自动驾驶等。因此，车端应用与车端工控机两端的连接，保证了基本数据的支持，比如路侧识别物的类别，会频繁通过车端应用进行渲染，或者行人预警；高精定位信息也会频繁回传到
车端应用，通过车端应用的定位apk上传至云端，以接收云端业务预警能力的下发等。几乎所有业务能力及高精地图的准确渲染都离不开两端的正常连接状态。
65.车端应用与云端(如ai云)的互联主要涉及到业务层的能力支持，比如：云端时刻下发道路预警等v2x预警事件，交警任务下发等演示能力的支持，根据自车的特殊性实现红绿灯状态呈现以及红绿灯的控灯能力的支持等。例如，如果自车属于vip车辆，当前经过的路口红灯可以变为绿灯，让当前车辆优先通行。因此，车端应用在三端中主要发挥的作用是基础数据的接收、渲染，及云端预警能力的呈现，云端预警能力的准确下发需要车端应用与云端的连接是有效的、可靠的，如果两端连接异常，云端无法根据自车位置进行路侧预警任务下发，也无法进行云端交警任务的下发。
66.车端工控机与云端的互联主要涉及到车端工控机定频上报高精定位信息、航向信息等基本车辆信息，也含有对自动驾驶节点监控的多个节点状态信息等。因此，如果车端工控机与云端连接异常，车端工控机监测的数据无法上报到云端，车侧安全员也无法及时获取节点状态，如果自动驾驶异常，驾驶人员无法快速进行人工接管；部分业务场景需要车端工控机与车端应用形成匹配关系，如果车端工控机与云端连接异常，则车端工控机与车端应用就无法形成有效的匹配关系，进而无法正常支持多个业务场景。
67.基于此，本技术实施例的车端需要通过连接状态检测任务来及时检测并获取自动驾驶车辆的三端连接状态。
68.另外需要说明的是，有些应用场景并不完全依赖三端连接状态均处于正常连接状态的情况，例如某些业务场景只需要车端应用与车端工控机的连接正常即可，因此具体如何检测或者依赖哪些连接状态实现自动驾驶功能，本领域技术人员可以根据实际需求灵活调整，在此不作具体限定。
69.步骤s130，在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务。
70.当自动驾驶车辆的连接状态正常时，可以进一步获取对应的节点状态检测任务，节点状态检测任务主要用于对自动驾驶车辆的各功能节点包括软件节点和硬件节点的状态等进行检测，从而保证自动驾驶功能的稳定运行。
71.步骤s140，根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果。
72.在获取到节点状态检测任务后，车端可以通过执行节点状态检测任务进行节点状态的自检，从而得到节点状态检测结果，这里的节点状态检测结果包括正常节点和异常节点，对于异常节点，还可以包括异常节点的状态描述等信息。
73.步骤s150，根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果的一部分，每完成一个环节的检测，就对应输出一个环节的检测结果，最终可以对检测结果进行汇总生成相应的自检报告，以便留档查看以及故障溯源等。
74.本技术实施例的自动驾驶车辆的自检方法基于自动驾驶场景的特殊性，对车端应用-工控机-云端三端的连接状态以及自动驾驶车辆中的各节点状态进行了高效检测，节省了故障排查时间，满足了自动驾驶场景对于高效性、安全性和可靠性的要求。
75.在本技术的一个实施例中，所述根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果包括：根据所述连接状态检测任务，检测所述自动驾驶车辆的连接状
态，得到所述连接状态检测结果；和/或，根据所述连接状态检测任务，接收云端反馈的自动驾驶车辆的连接状态检测结果。
76.自动驾驶车辆的连接状态检测结果的获取主要可以包括车端和云端两个来源，车端具体又可以分为车端应用和车端工控机这两个来源。对于第一个主要来源，车端应用和车端工控机可互相检测与对方的连接状态，两端有自己的检测时机和日志输出。此外，车端应用和车端工控机可以通过短链或者长链的方式分别检测自己与云端的连接状态。
77.对于第二个主要来源，云端可以通过车机的在线状态判断车侧两端包括车端应用和车端工控机与云端连接状态的正常与否，因为车端应用和车端工控机建立了绑定关系，基于该绑定关系会被云端认定为一组活动设备，同时云端又可以通过细节的业务流程来判断是具体是哪一端与云端断开了连接，比如：长时间无自动驾驶服务状态监控上报，云端则视为与车端工控机断开连接，查询接口验证车辆不在线，则视为与车端应用断开连接。
78.因此，三端随时都可以知晓自身与另外两端的连接状态并通过一定形式进行管理和维护。
79.在本技术的一个实施例中，所述车端应用与车端工控机之间基于车端应用标识与工控机标识进行匹配并存储在云端，所述连接状态检测任务包括所述车端应用标识，以使所述云端反馈与所述车端应用标识对应的自动驾驶车辆的连接状态。
80.本技术实施例的车端应用具有车端应用标识(serial number，简称sn)，可以用来唯一标识车端应用，车端工控机也具有唯一识别码。自动驾驶车辆在启动或者上电后，车端应用与车端工控机通电启动并连接车内的同一wifi，车端工控机会被定义固定ip地址，车端应用可以主动连接车端工控机的ip地址，两者互联并互相保存车端应用标识和车端工控机的唯一识别码，同时上报云端，云端把持有相同的一组车端应用标识和唯一识别码的车端工控机和车端应用识别为同一组活动设备，也就是对应同一辆自动驾驶车辆，从而完成车端应用与车端工控机之间的匹配，便于后续云端进行任务下发以及各个业务场景的业务支持等。
81.基于此，本技术实施例的车端应用在向云端下发连接状态检测任务时，就可以携带自己的车端应用标识，这样云端就可以根据该车端应用标识找到与之匹配的车端工控机的唯一识别码，进而确定三端的连接状态并反馈给车端应用。
82.在本技术的一个实施例中，在根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果之后，所述方法还包括：在所述连接状态检测结果为正常连接状态的情况下，通过所述车端应用与车端工控机的连接，在所述车端应用与所述车端工控机之间进行第一数据的传输；在所述连接状态检测结果为正常连接状态的情况下，通过所述车端应用与云端的连接，在所述车端应用与所述云端之间进行第二数据的传输；在所述连接状态检测结果为正常连接状态的情况下，通过所述车端工控机与云端的连接，在所述车端工控机与所述云端之间进行第三数据的传输。
83.如果获取到的自动驾驶车辆的三端连接状态均正常，说明三端之间可以进行正常的数据传输了。根据三端实现功能的不同，具体传输的数据也不同，例如，车端应用与车端工控机之间主要用于完成车端应用的感知数据、定位数据的传输、接收，以及业务场景能力反控的支持，如车端应用触发、结束自动驾驶等。车端应用与云端的互联主要涉及到业务层的能力支持，比如：云端时刻下发道路预警等v2x预警事件，交警任务下发等演示能力的支
持，根据自车的特殊性实现红绿灯状态呈现以及红绿灯的控灯能力的支持等。车端工控机与云端的互联主要涉及到车端工控机定频上报高精定位信息、航向信息等基本车辆信息，也含有对自动驾驶节点监控的多个节点状态信息等。
84.因此，上述“第一数据”、“第二数据”和“第三数据”主要用于区分三端之间相互传输的数据。
85.在本技术的一个实施例中，所述在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务包括：在所述车端应用与车端工控机的连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务。
86.为了提高车端的自检效率，节点状态检测任务的执行只需要保证车端应用与车端工控机互联即连接状态正常即可，从而可以减少云端的存储节点，同时可以节省节点状态检测结果获取的时间。
87.具体地，自动驾驶车辆启动或者上电后，车端工控机和车端应用启动，车端工控机和车端互联的前提条件是在同一wifi网络下，车端应用先向车端工控机发起socket长连接请求，两端互联，车端应用sn与车端工控机唯一标识互绑。然后，车端工控机、车端应用互绑后分别与云端发起socket连接请求，并上传绑定信息。之后，车端工控机定频自检节点状态，生成预设数据类型的数据回传给车端应用，也即车端应用的节点状态检测结果完全来自于车端工控机。这里的预设数据类型例如可以是protocol buffer类型，其写入和解析效率均较高。当然，本领域技术人员也可以灵活采用其他数据类型。
88.在本技术的一个实施例中，所述获取对应的节点状态检测任务包括：确定所述自动驾驶车辆的驾驶状态；在所述自动驾驶车辆的驾驶状态为自动驾驶状态时，获取第一节点状态检测任务，所述第一节点状态检测任务包含第一节点状态检测频率；在所述自动驾驶车辆的驾驶状态为非自动驾驶状态时，获取第二节点状态检测任务，所述第二节点状态检测任务包含第二节点状态检测频率；其中，所述第一节点状态检测频率大于所述第二节点状态检测频率。
89.实际场景下，自动驾驶车辆的驾驶状态可能有多种状态，例如自动驾驶状态和非自动驾驶状态等，不同驾驶状态下车辆的安全性和稳定性要求可能不同，那么相应地对于节点状态检测的需求也就不同。
90.基于此，本技术实施例的车端针对不同的自动驾驶车辆的驾驶状态创建了不同的节点状态检测任务，在获取当前的节点状态检测任务时，可以结合自动驾驶车辆当前的驾驶状态来获取，从而满足不同自动驾驶场景的需求。如前所述，本技术实施例的自动驾驶车辆的驾驶状态可以划分为自动驾驶状态和非自动驾驶状态等，自动驾驶状态下，由于人为控制程度低，一旦出现连接状态异常的情况，需要及时进行故障处理，相比之下，非自动驾驶状态下，人为控制程度高，当出现节点状态异常的情况，短时间内还可以人为控制车辆的行驶。
91.基于此，不同的驾驶状态对于自动驾驶车辆的节点状态检测频率的需求是不同的，在自动驾驶状态下，可以设置较高的节点状态检测频率即上述第一节点状态检测频率，在非自动驾驶状态下，可以设置较低的节点状态检测频率即上述第二节点状态检测频率。例如，自动驾驶状态下30秒自检一次，非自动驾驶状态下60秒自检一次。
92.当然，需要说明的是，本技术实施例划分的驾驶状态不限于上述两种，本领域技术
人员可以根据实际需求灵活划分更多的驾驶状态，如半自动驾驶状态等等，在此不一一列举。
93.此外，自动驾驶状态的不同除了影响节点状态的检测频率，还可以影响前述实施例中的连接状态的检测频率，因此可以根据不同的自动驾驶状态设置不同的连接状态的检测频率。
94.在本技术的一个实施例中，所述根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果包括：按照第一预设显示策略，将所述连接状态检测结果在所述车端进行显示，所述第一预设显示策略包含连接类型和连接状态检测结果的描述信息；按照第二预设显示策略，将所述节点状态检测结果在所述车端进行显示，所述第二预设显示策略包含节点类型、节点名称和节点状态检测结果的描述信息。
95.为了节省自动驾驶车辆的故障排查时间，本技术实施例还可以在车端显示自动驾驶车辆的连接状态检测结果和节点状态检测结果，从而便于及时提醒相关人员对异常检测结果进行处理。
96.一方面，本技术实施例可以采取第一预设显示策略将连接状态检测结果在车端进行显示，这里的第一预设显示策略可以是当获取到的连接状态中存在异常的连接状态时，可以直接将自动驾驶车辆的连接状态在车端界面上进行弹窗提醒，也即显示的连接状态中既包括异常的连接状态，也可以包括正常的连接状态。如图2所示，提供了本技术实施例中一种自动驾驶车辆的连接状态检测结果的显示界面示意图，具体呈现了连接类型和连接状态检测结果的描述信息等。
97.之所以在存在异常的连接状态时将自动驾驶车辆的连接状态全部显示在车端界面上，是因为可以便于相关人员结合其他端的连接状态来进行故障排查，例如，如果车端界面上显示车端应用与车端工控机之间的连接状态异常，车端工控机与云端的连接状态也异常，但车端应用与云端的连接状态是正常的，那么说明故障节点很有可能出现在车端工控机上。当然，除了上述显示方式，本领域技术人员也可以根据实际需求仅对异常的连接状态进行显示。
98.另一方面，本技术实施例可以采用第二预设显示策略将节点状态检测结果在车端进行显示，这里的第二预设显示策略具体可以包含节点类型、节点名称和节点状态检测结果的描述信息等，如下表1所示，提供了一种节点状态检测结果的显示内容的示例。
99.表1
[0100][0101][0102]
如上表1，对于iinit初始化(自检)信息这一节点类别来说，其对应有三个具体节点，iinit_time_sync、iinit_sensor_normal和iinit_version，在进行节点状态检测结果的呈现时，可以不区分正常节点或异常节点的检测结果，即均统一进行细粒度展示。
[0103]
还有一种策略是，可以根据各个节点类别下对应的各个节点的节点状态检测结果灵活调整所呈现的粒度，例如，一方面可以对异常节点进行细粒度展示，从而便于相关人员快速定位问题节点并进行故障处理，另一方面可以对某一正常节点类别的检测结果进行粗粒度呈现，省去正常节点的细节信息，从而保证展示内容的直观性和简洁性。
[0104]
上述展示的节点状态检测结果主要是基于节点实现的功能进行的划分，本技术实施例还可以根据节点属性的不同划分为硬件节点和软件节点，硬件节点例如可以包括gnss、imu、激光雷达、摄像头以及obu等传感器节点，路由器等网络节点，以及cpu等内存节
点等，软件节点例如可以包括/telematics_node即远程信息节点，/sensor/gnss/drivers_gnss即定位驱动节点，以及/perception即感知服务节点等等。因此，本技术实施例可以针对不同属性的节点类型创建不同的节点状态检测任务，并将相应的节点状态检测结果分别在车端进行展示。
[0105]
如图3所示，提供了本技术实施例中一种硬件节点的节点状态检测结果的显示界面示意图，如图4所示，提供了本技术实施例中一种软件节点的节点状态检测结果的显示界面示意图。
[0106]
通过上述显示策略实现了对不同类型节点进行不同细粒度的检测结果的展示，满足了实际应用场景的检测需求。当然，具体如何划分节点类型，本领域技术人员可以根据实际需求灵活调整，在此不作具体限定。
[0107]
此外，还需要说明的是，除了在车端界面上进行弹窗提醒，还可以发出告警并将异常信息发送给故障排查等相关人员，以便及时进行故障处理。
[0108]
在本技术的一个实施例中，所述节点状态检测结果包括异常节点，在根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果之后，所述方法还包括：确定所述异常节点的节点类型；根据所述异常节点的节点类型，确定对应的故障处理策略，以通过所述故障处理策略对所述异常节点进行处理。
[0109]
现有技术中当自动驾驶功能出现异常情况时，最常用的修复方案是重启，断点重启车机或者重启车端应用，或者经过多个人员节点才能找到真正能解决问题的人员，相对耗时，而且每次重启需要将所有的服务重新启动，即包括未发生异常的服务节点，这种操作非常低效。
[0110]
基于此，本技术实施例的自检方案得到的自检结果可以直接定位到细粒度的异常节点，可以根据异常节点的类型确定对应的故障处理策略，然后再通过启动单个异常节点的方式，或者直接联系与该异常节点相关的技术人员或者运维人员的方式对异常节点进行故障处理，从而能快速定位、解决异常节点断开的问题，也保证了其他服务节点的有效运行。
[0111]
不同类型的异常节点反映了不同的问题，因此往往需要采取不同的故障处理策略，如下表2所示，提供了一种异常节点与对应的故障处理策略的对照表。在可视化呈现异常节点的问题的同时，针对不同异常节点，表2中给出了详细的节点异常分析和明确的解决方案。
[0112]
实际应用时，可以针对不同类型的节点划分相应的故障等级，然后根据相应的故障等级确定不同节点的故障处理优先级，进而可以基于不同节点的故障处理优先级，依次利用各异常节点对应的故障处理策略进行故障处理。节点的故障等级越高，说明该节点出现异常时对自动驾驶功能的整体实现影响越大，因此越需要被优先处理。
[0113]
当然，当各异常节点功能独立，且对应的故障处理策略在同时执行时对自动驾驶功能的正常运行影响较小时，也可以对各异常节点同时进行故障处理。
[0114]
表2
[0115]
[0116]
[0117][0118]
在本技术的一个实施例中，在根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果之后，所述方法还包括：将所述自动驾驶车辆的自检结果存储至自动驾驶车辆的自检结果数据库中；基于所述自检结果数据库重新创建连接状态检测任务和/或节点状态检测任务。
[0119]
本技术实施例可以通过自动驾驶车辆的自检结果数据库统一维护自动驾驶车辆在一段时间内的自检结果数据，一方面可以保证历史自检结果的可溯源，另一方面也可以便于通过历史自检结果数据优化自动驾驶车辆的功能实现。
[0120]
基于自检结果数据库中存储的多次历史自检结果，能够统计分析出自动驾驶车辆在过去一段时间内的整体运行状态，例如，在过去10天中，自动驾驶车辆的连接状态检测结果中有3次出现异常，节点状态检测结果中有4次出现异常，说明该自动驾驶车辆的异常频
率较高，因此后续需要设置更高的连接状态检测频率和节点状态检测频率，也即可以基于统计分析结果动态调整创建的连接状态检测任务和节点状态检测任务，以便于使检测任务灵活适应于实际的检测场景。当然，具体如何调整，本领域技术人员可以根据实际需求灵活设置，在此不作具体限定。
[0121]
在本技术的一个实施例中，在根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果之后，所述方法还包括：获取所述自动驾驶车辆的自检结果上报任务；根据自检结果上报任务，将所述自动驾驶车辆的自检结果上报至所述云端。
[0122]
本技术实施例在得到自动驾驶车辆的自检结果之后，还可以根据自检结果上报任务将自动驾驶车辆的自检结果上报给云端进行统一存储和管理。这里的自检结果上报任务中具体可以包括车端应用sn或者车端工控机的唯一标识，从而便于云端确定是哪个自动驾驶车辆的自检结果。
[0123]
本技术的自动驾驶车辆的自检方法至少取得了如下的技术效果：
[0124]
1)数据有效性：自动驾驶过程，通过车端应用、车端工控机、云端三端连接状态的检测保证了连接正常，进而保证了数据的有效传输。
[0125]
2)数据准确性：数据在有效传输后，通过节点状态的检测确保了数据的正确性，保证了自动驾驶过程业务能力的稳定、准确执行。
[0126]
3)安全性：自动驾驶过程，如出现节点异常，及时提示安全员结束自动驾驶状态改为人工驾驶，避免了安全问题的发生。
[0127]
4)可靠性：大到模块，小到模块中的每个重要节点，都可以清晰呈现，做到异常节点的精准定位。
[0128]
5)高效性：自动驾驶过程产生的问题无需通过日志查询或者长时间联调的过程检查发生异常的节点，能够快速定位问题，快速解决问题。
[0129]
本技术实施例还提供了一种自动驾驶车辆的自检装置500，所述装置应用于车端，如图5所示，提供了本技术实施例中一种自动驾驶车辆的自检装置的结构示意图，所述装置500包括：第一获取单元510、连接状态检测单元520、第二获取单元530、节点状态检测单元540以及第一确定单元550，其中：
[0130]
第一获取单元510，用于获取自动驾驶车辆的连接状态检测任务；
[0131]
连接状态检测单元520，用于根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果，所述连接状态检测结果包括车端应用与车端工控机的连接状态检测结果、车端应用与云端的连接状态检测结果以及车端工控机与云端的连接状态检测结果；
[0132]
第二获取单元530，用于在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务；
[0133]
节点状态检测单元540，用于根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果；
[0134]
第一确定单元550，用于根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果。
[0135]
在本技术的一个实施例中，所述连接状态检测单元520具体用于：根据所述连接状态检测任务，检测所述自动驾驶车辆的连接状态，得到所述连接状态检测结果；和/或，根据
所述连接状态检测任务，接收云端反馈的自动驾驶车辆的连接状态检测结果。
[0136]
在本技术的一个实施例中，所述装置还包括：第一传输单元，用于在所述连接状态检测结果为正常连接状态的情况下，通过所述车端应用与车端工控机的连接，在所述车端应用与所述车端工控机之间进行第一数据的传输；第二传输单元，用于在所述连接状态检测结果为正常连接状态的情况下，通过所述车端应用与云端的连接，在所述车端应用与所述云端之间进行第二数据的传输；第三传输单元，用于在所述连接状态检测结果为正常连接状态的情况下，通过所述车端工控机与云端的连接，在所述车端工控机与所述云端之间进行第三数据的传输。
[0137]
在本技术的一个实施例中，所述第二获取单元530具体用于：在所述车端应用与车端工控机的连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务。
[0138]
在本技术的一个实施例中，所述第二获取单元530：确定所述自动驾驶车辆的驾驶状态；在所述自动驾驶车辆的驾驶状态为自动驾驶状态时，获取第一节点状态检测任务，所述第一节点状态检测任务包含第一节点状态检测频率；在所述自动驾驶车辆的驾驶状态为非自动驾驶状态时，获取第二节点状态检测任务，所述第二节点状态检测任务包含第二节点状态检测频率；其中，所述第一节点状态检测频率大于所述第二节点状态检测频率。
[0139]
在本技术的一个实施例中，所述第一确定单元550具体用于：按照第一预设显示策略，将所述连接状态检测结果在所述车端进行显示，所述第一预设显示策略包含连接类型和连接状态检测结果的描述信息；按照第二预设显示策略，将所述节点状态检测结果在所述车端进行显示，所述第二预设显示策略包含节点类型、节点名称和节点状态检测结果的描述信息。
[0140]
在本技术的一个实施例中，所述节点状态检测结果包括异常节点，所述装置还包括：第二确定单元，用于确定所述异常节点的节点类型；第三确定单元，用于根据所述异常节点的节点类型，确定对应的故障处理策略，以通过所述故障处理策略对所述异常节点进行处理。
[0141]
在本技术的一个实施例中，所述装置还包括：第三获取单元，用于获取所述自动驾驶车辆的自检结果上报任务；上报单元，用于根据自检结果上报任务，将所述自动驾驶车辆的自检结果上报至所述云端。
[0142]
能够理解，上述自动驾驶车辆的自检装置，能够实现前述实施例中提供的自动驾驶车辆的自检方法的各个步骤，关于自动驾驶车辆的自检方法的相关阐释均适用于自动驾驶车辆的自检装置，此处不再赘述。
[0143]
本技术实施例还提供一种自动驾驶车辆的自检系统，如图6所示，提供了本技术实施例中一种自动驾驶车辆的自检系统的架构示意图，所述系统包括车端和云端，所述车端包括车端应用和车端工控机/域控制器，所述车端用于执行前述之任一所述方法。
[0144]
通过本技术实施例的自动驾驶车辆的自检系统可以随时知晓系统中任意一端与另外两端的连接状态并通过一定形式进行管理和维护，满足了自动驾驶场景对于高效性、安全性和可靠性的要求。
[0145]
图7是本技术的一个实施例电子设备的结构示意图。请参考图7，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-access memory，ram)，也可能还包括非易失性存储
器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
[0146]
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component interconnect，外设部件互连标准)总线或eisa(extended industry standard architecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
[0147]
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
[0148]
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成自动驾驶车辆的自检装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
[0149]
获取自动驾驶车辆的连接状态检测任务；
[0150]
根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果，所述连接状态检测结果包括车端应用与车端工控机的连接状态检测结果、车端应用与云端的连接状态检测结果以及车端工控机与云端的连接状态检测结果；
[0151]
在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务；
[0152]
根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果；
[0153]
根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果。
[0154]
上述如本技术图1所示实施例揭示的自动驾驶车辆的自检装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field－programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
[0155]
该电子设备还可执行图1中自动驾驶车辆的自检装置执行的方法，并实现自动驾驶车辆的自检装置在图1所示实施例的功能，本技术实施例在此不再赘述。
[0156]
本技术实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一
个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图1所示实施例中自动驾驶车辆的自检装置执行的方法，并具体用于执行：
[0157]
获取自动驾驶车辆的连接状态检测任务；
[0158]
根据所述连接状态检测任务，获取自动驾驶车辆的连接状态检测结果，所述连接状态检测结果包括车端应用与车端工控机的连接状态检测结果、车端应用与云端的连接状态检测结果以及车端工控机与云端的连接状态检测结果；
[0159]
在所述连接状态检测结果为正常连接状态的情况下，获取对应的节点状态检测任务；
[0160]
根据所述节点状态检测任务，确定所述自动驾驶车辆的节点状态检测结果；
[0161]
根据所述自动驾驶车辆的连接状态检测结果和所述自动驾驶车辆的节点状态检测结果，确定所述自动驾驶车辆的自检结果。
[0162]
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0163]
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0164]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0165]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0166]
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
[0167]
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
[0168]
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动
态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0169]
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0170]
本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0171]
以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。