车辆安全检测方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及数据处理、车联网、自动驾驶、车辆安全等技术领域，具体涉及一种车辆安全检测方法、装置、电子设备及存储介质。

背景技术

随着车联网和自动驾驶的快速发展，不仅汽车电子系统的组成日益复杂化，其软件控制功能也在不断优化和完善。这不仅会增加车端的资源消耗量，同时，还会增加汽车电子系统所面临的风险数量和严重性，降低目标车辆的安全性能。

发明内容

本公开提供了一种车辆安全检测方法、装置、电子设备及存储介质。

根据本公开的一方面，提供了一种车辆安全检测方法，包括：

获取针对目标车辆的安全检测数据；

在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，确定与目标检测模式对应的当前车辆风险；其中，检测模式集中包括至少一个检测模式、且检测模式用于表征需要被匹配的至少一个检测事件集；

生成与当前车辆风险对应的告警信息。

根据本公开的另一方面，提供了一种车辆安全检测装置，包括：

数据获取单元，用于获取针对目标车辆的安全检测数据；

风险确定单元，用于在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，确定与目标检测模式对应的当前车辆风险；其中，检测模式集中包括至少一个检测模式、且检测模式用于表征需要被匹配的至少一个检测事件集；

信息生成单元，用于生成与当前车辆风险对应的告警信息。

根据本公开的另一方面，提供了一种电子设备，包括：

至少一个处理器；

与该至少一个处理器通信连接的存储器；

该存储器存储有可被该至少一个处理器执行的指令，该指令被该至少一个处理器执行，以使该至少一个处理器能够执行本公开实施例中任一的方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，该计算机指令用于使该计算机执行根据本公开实施例中任一的方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现根据本公开实施例中任一的方法。

采用本公开可以减少车端的资源消耗量，同时，通过提高车辆安全检测的可靠性，提高目标车辆的安全性能。

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

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为本公开实施例提供的一种车辆安全检测方法的流程示意图；

图2～图6为本公开实施例提供的一种检测模式的示意图；

图7为本公开实施例提供的一种参考模式的示意图；

图8和图9为本公开实施例提供的一种补充检测模式的示意图；

图10为本公开实施例提供的一种车辆安全检测方法的流程辅助说明图；

图11为本公开实施例提供的一种车辆安全检测方法的场景示意图；

图12为本公开实施例提供的一种车辆安全检测装置的示意性结构框图；

图13为本公开实施例提供的一种电子设备的示意性结构框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本公开实施例提供了一种车辆安全检测方法，其可以应用于电子设备上部署的车辆安全运营中心(Vehicle Security Operation Center，VSOC)，其中，电子设备可以是服务器。以下，将结合图1所示流程示意图，对本公开实施例提供的一种车辆安全检测方法进行说明。需要说明的是，虽然在流程示意图中示出了逻辑顺序，但是，在某些情况下，也可以以其它顺序执行所示出或描述的步骤。

步骤S101，获取针对目标车辆的安全检测数据；

步骤S102，在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，确定与目标检测模式对应的当前车辆风险；其中，检测模式集中包括至少一个检测模式、且检测模式用于表征需要被匹配的至少一个检测事件集；

步骤S103，生成与当前车辆风险对应的告警信息。

其中，目标车辆可以是能够接入网络的任意车辆，包括小型汽车、重型汽车、货车等，本公开实施例对此不作具体限定。

其中，安全检测数据可以通过目标车辆的各个安全检测部件上安装的车辆入侵检测与防御系统(Intrusion Detection&Prevention System，IDPS)采集、处理获得，并发送给应用车载安全检测方法的电子设备。在一具体示例中，安全检测数据可以包括每个安全检测部件的相关检测数据，例如，可以包括中央处理器(Central Processing Unit，CPU)使用率、内存占用率、磁盘占用率等、基于空中下载技术(Over-The-Air technology，OTA)实现部件系统升级时的过程表征数据等。

本公开实施例中，检测模式集中包括至少一个检测模式、且每个检测模式用于表征需要被匹配的至少一个检测事件集。其中，检测事件集可以包括至少一个规则事件，例如，可以包括某安全检测部件的CPU超负荷事件、车辆解锁事件、车辆上锁事件中的一者，也可以同时包括针对某部件系统的OTA请求成功事件、OTA下载事件、OTA升级开始事件、OTA升级结束事件等，具体可以根据需要检测的车辆风险配置，本公开实施例对此不作具体限定。

本公开实施例中，每个检测模式用于检测一项车辆风险，基于此，在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，可以进一步确定与目标检测模式对应的当前车辆风险，再生成与当前车辆风险对应的告警信息。

采用本公开实施例提供的车辆安全检测方法，可以获取针对目标车辆的安全检测数据；在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，确定与目标检测模式对应的当前车辆风险；生成与当前车辆风险对应的告警信息。一方面，由于相对于传统方案而言，本公开实施例提供的车辆安全检测方法并非应用于目标车辆，因此，可以减少车端的资源消耗量；另一方面，由于检测模式集中包括至少一个检测模式、且检测模式用于表征需要被匹配的至少一个检测事件集，也即，每个检测模式并非仅用于表征单个事件，因此，可以通过相对全面的检测模式配置，实现对车辆风险的精准判别，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

本公开实施例中，目标车辆的安全检测部件可以包括车机、车载远程信息处理器(Telematics BOX，T-BOX)、网关控制器和域控制器中至少一者，也即，安全检测数据可以包括目标车辆的车机、T-BOX、网关控制器和域控制器中至少一者的相关检测数据。

其中，域控制器可以包括车辆的动力域、车身域、底盘域、座舱域和自动驾驶域等多区域的控制器。

通过以上设置，本公开实施例中，可以获取到相对全面的安全检测数据，从而提高车辆风险检测方法的覆盖面，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

此外，请结合图2～图6，本公开实施例中，检测模式集中包括至少一个检测模式(例如，可以包括图2～图6的检测模式I、检测模式II、检测模式III、检测模式IV和检测模式V)、且检测模式用于表征需要被匹配的至少一个检测事件集。也即，本公开实施例中，检测模式集中的至少一个检测模式可以包括至少一个单因子检测模式和/或至少一个多因子检测模式。其中，单因子检测模式用于表征需要被匹配的一个检测事件集(如图3和图4所示)，多因子检测模式用于表征需要被匹配的多个检测事件集，该多个检测事件集可以串行连接，也即，针对该多个检测事件集的匹配可以按照该串行连接顺序依次执行(如图2、图5和图6所示)。此外，本公开实施例中，每个检测模式还具有对应的检测方式。其中，检测方式可以包括检测周期和检测时间段中的至少一者，例如，检测周期可以是每5分钟(min)检测一次，检测时间段可以是00:00:00～23:59:59。

以下，再对检测模式的配置作进一步说明。

(1)检测模式所表征的至少一个检测事件集的设置

每个检测事件集可以包括至少一个规则事件、且检测事件集中包括多个规则事件时，多个规则事件之间的事件关联关系可以是或关系。也即，针对某个检测事件集，在该检测事件集中包括多个规则事件时，该多个规则事件中任一规则事件被命中，则可以认为该检测事件集被成功匹配。

此外，本公开实施例中，针对每个检测事件集，还可以设置该检测事件集中规则事件的命中频次。例如，设置该检测事件集中规则事件的命中频次>＝3次，则在该检测事件集中规则事件被命中的次数大于等于3次时，才认为该检测事件集被成功匹配。

(2)对于多因子检测模式，其包括的多个检测事件集中两个相邻检测事件集之间的集合关联关系设置

STRICT：严格连续，也即，在第一检测事件集与第二检测事件集被成功匹配的中间时段，不允许出现其它事件集被成功匹配的情况(检测模式中，第二检测事件集位于第一检测事件集之后)；

SKIP_TILL_NEXT：松散连续，也即，在第一检测事件集与第二检测事件集被成功匹配的中间时段，允许出现其它事件集被成功匹配的情况(检测模式中，第二检测事件集位于第一检测事件集之后)；

NOT_NEXT：紧接着被命中的规则事件不属于下一检测事件集，也即，在第一检测事件集被成功匹配之后，紧接着被命中的规则事件不属于第二检测事件集(检测模式中，第二检测事件集位于第一检测事件集之后)；

NOT_FOLLOW：某指定的特定事件后续不出现，也即，在第一检测事件集被成功匹配之后，第二检测事件集中的规则事件(指定的特定事件)不再被命中(检测模式中，第二检测事件集位于第一检测事件集之后)。

通过以上设置，本公开实施例中，可以在确定需要检测的车辆风险之后，通过相对全面的检测模式配置，实现对车辆风险的精准判别，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

请结合图5，假设，需要检测的车辆风险为车机资源消耗量超负荷，那么，可以配置检测模式IV，用于表征需要被匹配的至少一个检测事件集中包括第一检测事件和第二检测事件、且第一检测事件和第二检测时间之间的集合关联关系为STRICT，其中，第一检测事件可以包括车机应用启动事件，第二检测事件集可以包括三个规则事件，分别为车机CPU超负荷事件、车机内存超负荷事件和车机磁盘超负荷事件。因此，在第一检测事件被成功匹配之后，若在第一检测事件和第二检测时间之间的集合关联关系符合STRICT的前提下，检测到第二检测事件也被成功匹配，则可以认为检测模式IV被成功匹配，也即，出现车机资源消耗量超负荷的车辆风险。这相对于现有技术中，每个检测模式仅用于表征单个事件的方案而言，可以通过相对全面的检测模式配置，实现对车辆风险的精准判别，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

此外，本公开实施例中，规则事件可以是特定事件或开放事件，开放事件包括具有相同特征的多个特定事件、且开放事件具有对应的事件语义。

其中，特定事件可以是基于安全检测数据确定的具体车辆上报事件，包括状态检测事件和异常事件等。其中，状态检测事件可以包括CPU超负荷事件、内存超负荷事件和磁盘超负荷事件等，异常事件可以包括控制器局域网络(Controller Area Network，CAN)报文长度异常事件、CAN信号值异常事件、CAN信号周期异常事件等。

其中，开放事件基于包括具有相同特征的多个特定事件，而具有相同特征可以是具有相同的事件对象，例如，事件对象可以是某安全检测部件的CAN，也即，开放事件可以包括与该安全检测部件的CAN相关的多个特定事件；再例如，事件对象可以是针对某部件系统的OTA，也即，开放事件可以包括针对该部件系统的OTA请求成功事件、OTA下载事件、OTA升级开始事件、OTA升级结束事件等。此外，本公开实施例中，事件语义用于定义开放事件的命中规则。

在一具体示例中，开放事件可以包括：

任意特定事件(ANY)；

预定义的多个特定事件，其事件语义可以包括：IN、NOT_IN；

基于VSOC自定义的多个特定事件，其事件语义可以包括：IN、NOT_IN。

例如，存在某开放事件，其包括OTA请求成功事件、OTA下载事件、OTA升级开始事件和OTA升级结束事件这四个特定事件，那么，IN(OTA请求成功事件or OTA下载事件or OTA升级开始事件or OTA升级结束事件)用于表征当前事件可以是这个集合中的任一事件；NOT_IN(OTA请求成功事件or OTA下载事件or OTA升级开始事件or OTA升级结束事件)用于表征当前事件不能这个集合中的任一事件。

通过以上步骤，本公开实施例中，可以在确定需要检测的车辆风险之后，通过相对全面的检测模式配置，尤其通过特定事件和开放事件的结合，实现对车辆风险的精准判别，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

如图6所示的，假设，需要检测的车辆风险为针对某部件系统的OTA升级变砖，那么，可以配置检测模式V，用于表征需要被匹配的至少一个检测事件集中包括第一检测事件集和第二检测事件集、且第一检测事件集和第二检测事件集之间的集合关联关系为NOT_NEXT，其中，第一检测事件集可以包括特定事件——OTA升级开始事件，第二检测事件集可以包括开放事件——任意特定事件(ANY)。因此，在第一检测事件集被成功匹配之后，若在第一检测事件和第二检测事件之间的集合关联关系符合NOT_NEXT的前提下，检测到第二检测事件集也被成功匹配，则可以认为检测模式V被成功匹配，也即，出现针对某部件系统的OTA升级变砖的车辆风险。这相对于现有技术中，每个检测模式仅用于表征单个事件的方案而言，可以通过相对全面的检测模式配置，尤其通过特定事件和开放事件的结合，实现对车辆风险的精准判别，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

此外，本公开实施例中，还可以针对指定的特定事件，设置事件特征字段的内容匹配，包括阈值匹配、数值范围匹配、数组包含匹配等，以丰富事件的命中判断标准。例如，车机CPU超负荷事件是通过车机CPU使用率判断是否命中的，此处可以设置，针对车机CPU超负荷事件，需要车机CPU使用率>＝90％，才认为车机CPU超负荷事件被命中；再例如，车机内存超负荷事件是通过车机内存使用率判断是否命中的，此处可以设置，针对车机内存超负荷事件，需要车机内存使用率>＝90％，才认为车机内存超负荷事件被命中；又例如，车机磁盘超负荷事件是通过车机磁盘使用率判断是否命中的，此处可以设置，针对车机磁盘超负荷事件，需要车机磁盘使用率>＝90％，才认为车机磁盘超负荷事件被命中。

基于检测模式的以上配置，在一些可选的实施方式中“基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式”，可以包括以下步骤：

针对每个单因子检测模式，在基于安全检测数据，确定单因子检测模式所表征的检测事件集被成功匹配的情况下，将单因子检测模式确定为目标检测模式，以确定检测模式集中存在被成功匹配的目标检测模式；

针对每个多因子检测模式，在基于安全检测数据，以及与多因子检测模式对应的预设匹配时长，确定多因子检测模式所表征的多个检测事件集被成功匹配的情况下，将多因子检测模式确定为目标检测模式，以确定检测模式集中存在被成功匹配的目标检测模式。

在一具体示例中，检测模式集中包括五个检测模式，分别为第一单因子检测模式、第二单因子检测模式、第一双因子检测模式、第二双因子检测模式和第三双因子检测模式，那么，在任一单因子检测模式被成功匹配的情况下，可以将该单因子检测模式确定为目标检测模式，以确定检测模式集中存在被成功匹配的目标检测模式，同样，在任一多因子检测模式被成功匹配的情况下，也可以将该多因子检测模式确定为目标检测模式，以确定检测模式集中存在被成功匹配的目标检测模式。

此外，本公开实施例中，每个多因子检测模式都具有对应的预设匹配时长，例如，5min。也即，针对某个多因子检测模式，其所表征的多个检测事件集若在5min内未被成功匹配，则停止次轮匹配，并进入等待下一轮匹配的流程。

通过以上步骤，本公开实施例中，针对每个单因子检测模式，在基于安全检测数据，确定单因子检测模式所表征的检测事件集被成功匹配的情况下，将单因子检测模式确定为目标检测模式，以简化单因子检测模式的匹配流程，从而减少匹配耗时，同时，针对每个多因子检测模式，在基于安全检测数据，以及与多因子检测模式对应的预设匹配时长，确定多因子检测模式所表征的多个检测事件集被成功匹配的情况下，将多因子检测模式确定为目标检测模式，从而避免匹配过程出现长时间等待的情况，一方面，可以减少匹配耗时，另一方面，可以提高车辆安全检测的可靠性。

需要说明的是，本公开实施例中，为进一步减少匹配耗时，同时，提高匹配准确率，在执行“基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式”的步骤之前，还可以对安全检测数据进行清洗，以删除非规范化数据。其中，非规范化数据可以是格式出错数据、乱码数据等。

还需要说明的是，本公开实施例中，“基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式”，以及对安全检测数据进行清洗可以通过Flink分布式计算策略实现。基于此，在一些可选的实施方式中，“基于安全检测数据，以及与多因子检测模式对应的预设匹配时长，确定多因子检测模式所表征的多个检测事件集被成功匹配”，可以包括以下步骤：

在基于安全检测数据，确定多因子检测模式所表征的多个检测事件集中的头部事件集被成功匹配的情况下，开始计算模式匹配时长；

获取与多因子检测模式对应的预设匹配时长；

在模式匹配时长达到预设匹配时长之前，若基于安全检测数据，确定多因子检测模式所表征的多个检测事件集中除头部事件集之外的每个非头部事件集被成功匹配，则确定多因子检测模式所表征的多个检测事件集被成功匹配。

其中，头部事件集为多个检测事件集中的首个检测事件集。

以图5所示检测模式IV为例，在基于安全检测数据，确定检测模式IV所表征的两个检测事件集中的头部事件集，也即，第一检测事件集被成功匹配的情况下，开始计算模式匹配时长，并获取与检测模式IV对应的预设匹配时长，在模式匹配时长达到预设匹配时长之前，若基于安全检测数据，确定检测模式IV所表征的两个检测事件集中除第一检测事件集之外的第二检测事件集被成功匹配，则确定检测模式IV所表征的两个检测事件集被成功匹配。

通过以上步骤，本公开实施例中，可以在基于安全检测数据，确定多因子检测模式所表征的多个检测事件集中的头部事件集被成功匹配的情况下，开始计算模式匹配时长，以及在模式匹配时长达到与多因子检测模式对应的预设匹配时长之前，在基于安全检测数据，确定多因子检测模式所表征的多个检测事件集中除头部事件集之外的每个非头部事件集被成功匹配的情况下，确定多因子检测模式所表征的多个检测事件集被成功匹配，从而避免匹配过程的长时间等待。一方面，可以减少匹配耗时，另一方面，可以通过预设匹配时长的设置，增强多因子检测模式所表征的多个检测事件集之间的上下文关联性，提高匹配准确率，最终，提高车辆安全检测的可靠性。

本公开实施例中，对于多因子检测模式，其包括的多个检测事件集中，两个相邻检测事件集之间还会设置对应的集合关联关系。基于此，在一些可选的实施方式中，“基于安全检测数据，确定多因子检测模式所表征的多个检测事件集中除头部事件集之外的每个非头部事件集被成功匹配”可以包括以下步骤：

针对多因子检测模式所表征的多个检测事件集中除头部事件集之外的每个非头部事件集，确定非头部事件集与非头部事件集的上一事件集之间的集合关联关系；

在基于安全检测数据，确定非头部事件集的事件发生情况符合集合关联关系的情况下，确定非头部事件集被成功匹配。

如前所述的，本公开实施例中，集合关联关系可以是STRICT、SKIP_TILL_NEXT、NOT_NEXT和NOT_FOLLOW中的一者。

以图5所示检测模式IV为例，其所表征的至少一个检测事件集中包括作为头部事件集的第一检测事件集，以及作为非头部事件集的第二检测事件集，也即，第一检测事件集为第二检测事件集的上一事件集。第二检测事件集与第一检测事件集之间的集合关联关系为STRICT，因此，在基于安全检测数据，确定第二检测事件集的事件发生情况符合STRICT的情况下，确定第二检测事件集被成功匹配。也即，在第一检测事件集被成功匹配之后，第二检测事件集也被成功匹配、且在第一检测事件集与第二检测事件集被成功匹配的中间时段，未出现其它事件集被成功匹配，则确定检测模式IV被成功匹配。

在以图6所示检测模式V为例，其所表征的至少一个检测事件集中包括作为头部事件集的第一检测事件集，以及作为非头部事件集的第二检测事件集，也即，第一检测事件集为第二检测事件集的上一事件集。第二检测事件集与第一检测事件集之间的集合关联关系为NOT_NEXT，因此，在基于安全检测数据，确定第二检测事件集的事件发生情况符合NOT_NEXT的情况下，确定第二检测事件集被成功匹配。也即，在第一检测事件集被成功匹配之后，下一被命中的规则事件不属于第二检测事件集，则确定检测模式V被成功匹配。由于第二检测事件集中包括的规则事件为开放事件、且具体为任意特定事件(ANY)，因此，此处对于下一被命中的规则事件不属于第二检测事件集的理解可以是，未命中任何一个特定事件。

通过以上步骤，本公开实施例中，针对多因子检测模式所表征的多个检测事件集中除头部事件集之外的每个非头部事件集，可以确定非头部事件集与非头部事件集的上一事件集之间的集合关联关系，再在基于安全检测数据，确定非头部事件集的事件发生情况符合集合关联关系的情况下，确定非头部事件集被成功匹配，以丰富非头部事件集的命中判断标准，实现对车辆风险的精准判别，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

本公开实施例中，每个检测模式都具有对应的检测方式。基于此，在一些可选的实施方式中，“基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式”可以包括以下步骤：

针对每个检测模式，获取与检测模式对应的检测方式；其中，检测方式包括检测周期和检测时间段中的至少一者；

按照检测方式，基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式。

其中，检测方式可以由安全运营人员基于VSOC的Web前端配置，并通过Web后端，发送到数据管理系统(例如，Mysql)进行存储。其中，检测方式可以包括检测周期和检测时间段中的至少一者，例如，检测周期可以是每5min检测一次，检测时间段可以是00:00:00～23:59:59。

通过以上步骤，针对每个检测模式，可以获取与检测模式对应的检测方式，再按照检测方式，基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式。其中，检测方式包括检测周期和检测时间段中的至少一者。如此，可以实现检测频次的有效控制，同时，降低无效检测的次数，以减少电子设备的资源消耗量。

此外，本公开实施例中，检测模式集中包括的至少一个检测模式可以包括通过人工配置的原始检测模式，也可以包括自动配置的补充检测模式。其中，原始检测模式可以由安全运营人员基于VSOC的Web前端配置，并通过Web后端，发送到数据管理系统进行存储。而对于补充检测模式，在一些可选的实施方式中，车辆安全检测方法还可以包括以下步骤，用于配置补充检测模式，并据此创建检测模式集：

获取自动配置逻辑；

按照自动配置逻辑，配置补充检测模式；

利用补充检测模式，创建检测模式集。

其中，自动配置逻辑可以预先设定，并存储于数据管理系统。

本公开实施例中，可以在将车辆安全检测方法应用到电子设备之前，获取自动配置逻辑，再按照自动配置逻辑，配置补充检测模式，并利用补充检测模式，创建检测模式集；也可以在车辆安全检测方法的应用过程中，获取自动配置逻辑，再按照自动配置逻辑，配置补充检测模式，并利用补充检测模式，创建检测模式集，此处，创建检测模式集可以理解为对检测模式集进行更新。

通过以上步骤，本公开实施例中，可以获取自动配置逻辑，再按照自动配置逻辑，配置补充检测模式，并利用补充检测模式，创建检测模式集，从而实现检测模式集的半自动化创建，以降低车辆安全检测方法的开发难度，以提升车辆安全检测方法的开发效率。

此外，本公开实施例中，在将包括原始检测模式和补充检测模式的检测模式集存储于数据管理系统之后，还可以由安全运营人员基于VSOC的Web前端，对其中的原始检测模式和补充检测模式进行修改、关闭、删除、版本升级等处理，同时，也可以新增其它检测模式。

在一些可选的实施方式中，“按照自动配置逻辑，配置补充检测模式”可以包括以下步骤：

获取预设安全规范；其中，预设安全规范包括多条安全检测项目；

针对每条安全检测项目，确定需要被匹配的至少一个检测事件集；

基于需要被匹配的至少一个检测事件集，配置补充检测模式。

其中，预设安全规范可以是车联网标准R155。

在获取到预设安全规范之后，可以针对预设安全规范中的每条检测项目，确定需要被匹配的至少一个检测事件集，再基于需要被匹配的至少一个检测事件集，配置补充检测模式。

例如，预设安全规范中存在第一检测项目，具体为：升级文件完整性检测。因此，可以确定需要被匹配的至少一个检测事件集中包括升级文件完整性检测事件这一规则事件(具体为指定的特定事件)。该升级文件完整性检测事件可以通过从安全检测数据中提取的升级文件完整性检测校验数据判断是否被命中。

再例如，预设安全规范中存在第二检测项目，具体为：升级服务连接审计。因此，可以确定需要被匹配的至少一个检测事件集中包括升级服务连接审计事件这一规则事件(具体为指定的特定事件)。该升级服务连接审计事件可以通过从安全检测数据中提取的升级服务连接信息判断是否被命中。

通过以上步骤，本公开实施例中，可以获取预设安全规范，再针对预设安全规范中的每条安全检测项目，确定需要被匹配的至少一个检测事件集，并基于需要被匹配的至少一个检测事件集，配置补充检测模式。如此，即可实现检测模式集对预设安全检测规范的相对性覆盖，避免对预设安全规范中部分安全检测项目的漏检，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

在一些可选的实施方式中，“按照自动配置逻辑，配置补充检测模式”可以包括以下步骤：

获取参考模式；其中，参考模式用于表征需要被匹配的结果事件集，以及与结果事件集相关的候选因子事件集，候选因子事件集中包括多个候选因子事件；

基于安全检测数据，对参考模式进行多次匹配，以从多个候选因子事件中确定引发结果事件集的至少一个因子事件；

利用至少一个因子事件，构建因子事件集；

基于因子事件集和结果事件集，配置补充检测模式。

其中，参考模式可以由安全运营人员基于VSOC的Web前端配置，并通过Web后端，发送到数据管理系统进行存储。其中，结果事件集可以包括至少一个规则事件、且该规则事件具体为某指定的特定事件。例如，结果事件集可以包括三个规则事件，分别为车机CPU超负荷事件、车机内存超负荷事件和车机磁盘超负荷事件；候选因子事件集可以包括多个候选因子事件，其中，多个候选因子事件可以是多个规则事件，也可以是某开放事件，例如，任意特定事件(ANY)表征。结合该示例，可以获得如图7所示的参考模式Ⅵ。

此后，可以基于安全检测数据，对参考模式进行多次匹配，以从多个候选因子事件中确定引发结果事件集的至少一个因子事件。具体地，针对参考模式的每次成功匹配经历，都可以从多个候选因子事件中确定一个初选事件，组成初选事件集，最后，从初选事件集中选取数量比例最大的指定数量个初选事件，作为因子事件，以确定至少一个因子事件，并利用至少一个因子事件，构建因子事件集。

在一具体示例中，针对参考模式的100次成功匹配经历中，有80次是从多个候选因子事件中确定初选事件A1，有15次是从多个候选因子事件中确定初选事件A2，有5次是从多个候选因子事件中确定初选事件A3。那么，在指定数量为1时，可以选取数量比例最大的初选事件A1，作为因子事件，并构建因子事件集，最终，可以基于因子事件集和结果事件集，配置如图8所示的补充检测模式Ⅶ；在指定数量为2时，可以选取数量比例最大的初选事件A1和初选事件A2，作为因子事件，并构建因子事件集，最终，可以基于因子事件集和结果事件集，配置如图9所示的补充检测模式Ⅷ。

通过以上步骤，本公开实施例中，可以获取参考模式，再基于安全检测数据，对参考模式进行多次匹配，以从多个候选因子事件中确定引发结果事件集的至少一个因子事件，并利用至少一个因子事件，构建因子事件集，以及基于因子事件集和结果事件集，配置补充检测模式。其中，参考模式用于表征需要被匹配的结果事件集，以及与结果事件集相关的候选因子事件集，候选因子事件集中包括多个候选因子事件，从而实现补充检测模式的智能化配置，且能够保证补充检测模式的可靠性，以提高车辆安全检测的可靠性，从而提高目标车辆的安全性能。

在一些可选的实施方式中，车辆安全检测方法还可以包括以下步骤：

确定当前车辆风险的风险类型；

在风险类型表征当前车辆风险属于可修复风险的情况下，获取与告警信息对应的修复处理策略；

将修复处理策略发送给目标车辆，以使目标车辆根据修复处理策略进行风险处理。

其中，风险类型可以是需修复类型，也可以是提醒类型。例如，如图3所示的检测模式II，其所针对的车辆风险是需要进行修复(例如，可以进行车机CPU减负处理)的，因此，该车辆风险的风险类型为需修复类型；再例如，如图4所示的检测模式III，其所针对的车辆风险是无需进行修复，因此，该车辆风险的风险类型为提醒类型。

在风险类型表征当前车辆风险属于可修复风险的情况下，可以获取与告警信息对应的修复处理策略、且该修复处理策略可以是预设的，并在与对应车辆风险建立对应关系之后，存储数据管理系统。

通过以上步骤，本公开实施例中，可以确定当前车辆风险的风险类型，再在风险类型表征当前车辆风险属于可修复风险的情况下，获取与告警信息对应的修复处理策略，并将修复处理策略发送给目标车辆，以使目标车辆根据修复处理策略进行风险处理，从而实现车辆风险的自动修复处理，提高了车辆安全检测方法的可用性。

以下，将结合图10，对本公开实施例提供的一种车辆安全检测方法的完整性流程进行说明。

首先，安全检测数据可以通过目标车辆的各个安全检测部件上安装的IDPS采集、处理获得，并发送给应用车载安全检测方法的电子设备，具体可以通过电子设备上设置的车端应用程序编程接口(Application Programming Interface，API)接收安全检测数据。其中，电子设备可以是服务器。

此后，车端API通过预设通信协议(例如，Kafka协议)将安全检测数据发送给封装有Flink分布式计算策略的模式匹配模块，以对安全检测数据进行清洗，同时，生成数据清洗日志，再通过预设通信协议(例如，Kafka协议)存储于第一数据库(例如，Elasticsearch数据服务器)中。

对于经过清洗的安全检测数据，可以从数据管理系统中获取最新的检测数据集，以通过动态匹配的方式，在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，确定与目标检测模式对应的当前车辆风险，并生成与当前车辆风险对应的告警信息，实现实时告警，例如，可以通过短信、邮件等方式发送给指定终端设备。同时，可以将告警信息存储于第二数据库(例如，ClickHouse数据库)，以便告警信息通过VSOC的Web后端传输到Web前端，供安全运营人员通过Web前端查看告警信息。

其中，Web后端和Web前端用于对接安全运营人员，以实现以下功能：

(1)资产管理：支持车型管理、车辆管理、零件管理等；

(2)事件中心：支持告警列表(包括漏洞列表)等信息查看；

(3)检测模式：支持检测模式的配置(包括单因子检测模式和多因子检测模式的配置)、删除、修改、查询、关闭；

(4)应急响应：支持工单管理、工单编排等；

(5)用户管理：支持用户管理和角色管理，限定用户的平台访问权限、接口访问权限，支持特定API级别的读、写权限鉴权。

请参阅图11，为本公开实施例提供的一种车辆安全检测方法的场景示意图。

如前所述的，本公开实施例提供的车辆安全检测方法应用于电子设备。电子设备旨在表示各种形式的数字计算机，诸如，服务器、刀片式服务器、大型计算机或其它适合的计算机。

电子设备可以用于：

获取针对目标车辆的安全检测数据；

在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，确定与目标检测模式对应的当前车辆风险；其中，检测模式集中包括至少一个检测模式、且检测模式用于表征需要被匹配的至少一个检测事件集；

生成与当前车辆风险对应的告警信息。

其中，安全检测数据可以通过目标车辆的各个安全检测部件上安装的IDPS采集、处理获得，并发送给应用车载安全检测方法的电子设备。

此外，本公开实施例中，在生成与当前车辆风险对应的告警信息之后，还可以确定当前车辆风险的风险类型；在风险类型表征当前车辆风险属于可修复风险的情况下，获取与告警信息对应的修复处理策略；将修复处理策略发送给目标车辆，以使目标车辆根据修复处理策略进行风险处理。

需要说明的是，本公开实施例中，图11所示的场景示意图仅为示意性而非限制性的，本领域技术人员可以基于图11示例进行各种显而易见的变化和/或替换，获得的技术方案仍属于本公开实施例的公开范围。

为了更好地实施车辆安全检测方法，本公开实施例还提供一种车辆安全检测装置，其具体可以集成在电子设备中。以下，将结合图12所示结构示意图，对公开实施例提供的一种车辆安全检测装置1200进行说明。

数据获取单元1201，用于获取针对目标车辆的安全检测数据；

风险确定单元1202，用于在基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式的情况下，确定与目标检测模式对应的当前车辆风险；其中，检测模式集中包括至少一个检测模式、且检测模式用于表征需要被匹配的至少一个检测事件集；

信息生成单元1203，用于生成与当前车辆风险对应的告警信息。

在一些可选的实施方式中，检测模式集中包括至少一个单因子检测模式和/或至少一个多因子检测模式，单因子检测模式用于表征需要被匹配的一个检测事件集，多因子检测模式用于表征需要被匹配的多个检测事件集；风险确定单元1202用于：

针对每个单因子检测模式，在基于安全检测数据，确定单因子检测模式所表征的检测事件集被成功匹配的情况下，将单因子检测模式确定为目标检测模式，以确定检测模式集中存在被成功匹配的目标检测模式；

针对每个多因子检测模式，在基于安全检测数据，以及与多因子检测模式对应的预设匹配时长，确定多因子检测模式所表征的多个检测事件集被成功匹配的情况下，将多因子检测模式确定为目标检测模式，以确定检测模式集中存在被成功匹配的目标检测模式。

在一些可选的实施方式中，风险确定单元1202用于：

在基于安全检测数据，确定多因子检测模式所表征的多个检测事件集中的头部事件集被成功匹配的情况下，开始计算模式匹配时长；

获取与多因子检测模式对应的预设匹配时长；

在模式匹配时长达到预设匹配时长之前，若基于安全检测数据，确定多因子检测模式所表征的多个检测事件集中除头部事件集之外的每个非头部事件集被成功匹配，则确定多因子检测模式所表征的多个检测事件集被成功匹配。

在一些可选的实施方式中，风险确定单元1202用于：

针对多因子检测模式所表征的多个检测事件集中除头部事件集之外的每个非头部事件集，确定非头部事件集与非头部事件集的上一事件集之间的集合关联关系；

在基于安全检测数据，确定非头部事件集的事件发生情况符合集合关联关系的情况下，确定非头部事件集被成功匹配。

在一些可选的实施方式中，检测事件集中包括至少一个规则事件、且检测事件集中包括多个规则事件时，多个规则事件之间的事件关联关系为或关系。

在一些可选的实施方式中，规则事件为特定事件或开放事件；其中，开放事件包括具有相同特征的多个特定事件、且开放事件具有对应的事件语义。

在一些可选的实施方式中，风险确定单元1202用于：

针对每个检测模式，获取与检测模式对应的检测方式；其中，检测方式包括检测周期和检测时间段中的至少一者；

按照检测方式，基于安全检测数据，确定检测模式集中存在被成功匹配的目标检测模式。

在一些可选的实施方式中，车辆安全检测装置1200还包括：

逻辑获取单元，用于获取自动配置逻辑；

模式配置单元，用于按照自动配置逻辑，配置补充检测模式；

模式集创建单元，用于利用补充检测模式，创建检测模式集。

在一些可选的实施方式中，模式配置单元用于：

获取预设安全规范；其中，预设安全规范包括至少一条安全检测项目；

针对每条安全检测项目，确定需要被匹配的至少一个检测事件集；

基于需要被匹配的至少一个检测事件集，配置补充检测模式。

在一些可选的实施方式中，模式配置单元用于：

获取参考模式；其中，参考模式用于表征需要被匹配的结果事件集，以及与结果事件集相关的候选因子事件集，候选因子事件集中包括多个候选因子事件；

基于安全检测数据，对参考模式进行多次匹配，以从多个候选因子事件中确定引发结果事件集的至少一个因子事件；

利用至少一个因子事件，构建因子事件集；

基于因子事件集和结果事件集，配置补充检测模式。

在一些可选的实施方式中，安全检测数据包括目标车辆的车机、车载远程信息处理器、网关控制器和域控制器中至少一者的相关检测数据。

在一些可选的实施方式中，车辆安全检测装置1200还包括：

风险类型确定单元，用于确定当前车辆风险的风险类型；

策略获取单元，用于在风险类型表征当前车辆风险属于可修复风险的情况下，获取与告警信息对应的修复处理策略；

策略发送单元，用于将修复处理策略发送给目标车辆，以使目标车辆根据修复处理策略进行风险处理。

本公开实施例的装置的各单元的具体功能和示例的描述，可以参见上述方法实施例中对应步骤的相关描述，在此不作赘述。

本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图13示出了可以用来实施本公开的实施例的示例电子设备1300的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字助理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或要求的本公开的实现。

如图13所示，设备1300包括计算单元1301，其可以根据存储在只读存储器(Read-Only Memory，ROM)1302中的计算机程序或从存储单元1308加载到随机访问存储器(RandomAccess Memory，RAM)1303中的计算机程序，来执行各种适当的动作和处理。在RAM 1303中，还可存储设备1300操作所需的各种程序和数据。计算单元1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(Input/Output，I/O)接口1305也连接至总线1304。

设备1300中的多个部件连接至I/O接口1305，包括：输入单元1306，例如键盘、鼠标等；输出单元1307，例如各种类型的显示器、扬声器等；存储单元1308，例如磁盘、光盘等；以及通信单元1309，例如网卡、调制解调器、无线通信收发机等。通信单元1309允许设备1300通过诸如因特网的计算机网络和/或各种电信网络与其它设备交换信息/数据。

计算单元1301可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1301的一些示例包括但不限于中央处理单元(Central Processing Unit，CPU)、图形处理单元(Graphics Processing Unit，GPU)、各种专用的人工智能(ArtificialIntelligence，AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(Digital Signal Process，DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1301执行上文所描述的各个方法和处理，例如，车辆安全检测方法。例如，在一些实施例中，车辆安全检测方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1308。在一些实施例中，计算机程序的部分或全部可以经由ROM 1302和/或通信单元1309而被载入和/或安装到设备1300上。当计算机程序加载到RAM 1303并由计算单元1301执行时，可以执行上文描述的车辆安全检测方法的一个或多个步骤。备选地，在其它实施例中，计算单元1301可以通过其它任何适当的方式(例如，借助于固件)而被配置为执行车辆安全检测方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、现场可编程门阵列(Field Programmable Gate Array，FPGA)、专用集成电路(Application Specific Integrated Circuit，ASIC)、专用标准产品(ApplicationSpecific Standard Product，ASSP)、芯片上系统的系统(System On Chip，SOC)、负载可编程逻辑设备(Complex Programmable Logic Device，CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或多个计算机程序中，该一个或多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、RAM、ROM、可擦除可编程只读存储器(Erasable Programmable Read-OnlyMemory，EPROM)或快闪存储器、光纤、便捷式紧凑盘只读存储器(Compact Disc Read-OnlyMemory，CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，阴极射线管(Cathode Ray Tube，CRT)显示器或液晶显示器(Liquid Crystal Display，LCD))；以及键盘和指向装置(例如，鼠标或轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或触觉反馈)；并且可以用任何形式(包括声输入、语音输入、或触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或包括中间件部件的计算系统(例如，应用服务器)、或包括前端部件的计算系统(例如，具有图形用户界面或网络浏览器的用户计算机，用户可以通过该图形用户界面或该网络浏览器来与此处描述的系统和技术的实施方式交互)、或包括这种后台部件、中间件部件、或前端部件的任何组合的计算系统中。可以通过任何形式或介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(Local AreaNetwork，LAN)、广域网(Wide Area Network，WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或是结合了区块链的服务器。

本公开实施例还提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行车辆安全检测方法。

本公开实施例还提供了一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现车辆安全检测方法。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。此外，本公开中，诸如“第一”、“第二”等之类的关系术语仅仅用来将一个实体或操作与另一个实体或操作区分开来，而不一定要求或暗示这些实体或操作之间存在任何这种实际的关系或顺序。此外，本公开中“多个”，可以理解为至少两个，本公开中“任一”，可以理解为任意一个。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其它因素，可以进行各种修改、组合、子组合和替代。任何在本公开的原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。