CN117472536A

CN117472536A - 车载入侵检测系统的资源调度方法、装置、设备及介质

Info

Publication number: CN117472536A
Application number: CN202311489642.8A
Authority: CN
Inventors: 林明
Original assignee: Guoqi Intelligent Control Beijing Technology Co Ltd
Current assignee: Guoqi Intelligent Control Beijing Technology Co Ltd
Priority date: 2023-11-09
Filing date: 2023-11-09
Publication date: 2024-01-30

Abstract

本申请提供一种车载入侵检测系统的资源调度方法、装置、设备及介质，该方法包括：获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限；在后处理阶段的一个或多个检测模块存在待处理数据时，实时基于线程资源和后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数；基于若干检测模块各自的当前线程数及其对应的调度权重上限按照可分配线程数确定各个检测模块的分配权重；基于分配权重为各个检测模块分配对应的线程数。通过上述方法，可以有效解决车载入侵检测系统的资源分配不均衡的问题，并达到提升入侵检测性能，同时不影响其他功能的正常使用的技术效果。

Description

车载入侵检测系统的资源调度方法、装置、设备及介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种车载入侵检测系统的资源调度方法、装置、设备及介质。

背景技术

随着智能化、网联化的发展，汽车系统面临越来越严重的信息安全问题，入侵检测系统在车载控制器的应用也越来越广泛，入侵检测系统(Intrusion Detection System，IDS)是一种可以保护汽车安全的技术，其工作原理是对汽车联网进行监控，检测并拦截其中的恶意行为。

尽管入侵检测系统可以有效检测并拦截恶意行为，但是目前入侵检测系统没有合理的资源调度方案，导致系统资源分配不均衡，其需要通过占用大量的系统资源，来提高安全检测的运行性能，这可能影响其他车载功能的正常运转。

因此，如何在车载系统有限的系统资源下，合理调度入侵检测系统资源，以满足车辆入侵检测的高性能处理同时不影响其他功能的正常运转，成为目前亟待解决的问题。

发明内容

本申请提供一种车载入侵检测系统的资源调度方法、装置、设备及介质，用以解决车载入侵检测系统的系统资源分配不均衡的问题。

第一方面，本申请提供一种车载入侵检测系统的资源调度方法，所述车载入侵检测系统包括用于执行不同车载入侵检测阶段的若干检测模块，所述车载入侵检测阶段包括初始检测阶段和后处理阶段，所述方法包括：

获取所述若干检测模块进行入侵检测所需的线程资源以及所述若干检测模块各自关于线程资源的调度权重上限；

在所述后处理阶段的一个或多个检测模块存在待处理数据时，实时基于所述线程资源和所述后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数；

基于所述若干检测模块各自的当前线程数及其对应的调度权重上限按照所述可分配线程数确定各个检测模块的分配权重；

基于所述分配权重为各个检测模块分配对应的线程数，所述线程数用于处理对应检测模块进行入侵检测的待处理数据。

在一种实施方式中，所述初始检测阶段的检测模块包括用于采集行为数据的初检模块；所述后处理阶段的检测模块包括用于识别所述行为数据对应的行为是否为入侵行为的二次确认模块、用于获取所述入侵行为的入侵数据的数据收集模块以及用于根据所述入侵数据生成入侵响应策略的数据处理模块。

在一种实施方式中，所述车载入侵检测系统还包括分别连接所述后处理阶段中各个检测模块的若干缓存队列，所述若干缓存队列分别用于存储对应检测模块中的待处理数据。

在一种实施方式中，所述获取所述若干检测模块进行入侵检测所需的线程资源以及所述若干检测模块各自关于线程资源的调度权重上限，包括：

基于所述若干检测模块各自的运行时长获取所述若干检测模块之间的关于线程资源的调度权重比例；

基于所述调度权重比例获取所述若干检测模块进行入侵检测所需的线程资源以及所述若干检测模块各自关于线程资源的调度权重上限。

在一种实施方式中，所述基于所述若干检测模块各自的当前线程数及其对应的调度权重上限按照所述可分配线程数确定各个检测模块的分配权重，包括：

基于所述若干检测模块各自的当前线程数及其对应的调度权重上限判断各个检测模块的当前线程数是否达到所述调度权重上限对应的线程数；

在存在检测模块的当前线程数达到所述调度权重上限对应的线程数的情况下，将所述检测模块的分配权重确定为零。

在一种实施方式中，所述初始检测阶段的检测模块的调度权重上限为无限大，

在获取所述若干检测模块进行入侵检测所需的线程资源以及所述若干检测模块各自关于线程资源的调度权重上限之后，还包括：

在所述后处理阶段的所有检测模块均不存在待处理数据且所述所有检测模块的当前线程数之和为零时，直接基于所述线程资源为所述初始检测阶段的检测模块分配对应的线程数。

在一种实施方式中，在基于所述分配权重为各个检测模块分配对应的线程数之前，所述方法还包括：

基于所述后处理阶段中各个检测模块的待处理数据的处理顺序确定所述若干缓存队列的优先级，其中，所述处理顺序是基于所述后处理阶段中各检测模块之间的数据流向确定的；

基于所述若干缓存队列的优先级确定所述若干检测模块的调度优先级；

所述基于所述分配权重为各个检测模块分配对应的线程数，包括：基于所述若干检测模块的调度优先级和所述分配权重为各个检测模块分配对应的线程数。

在一种实施方式中，所述方法还包括：

在为初始检测阶段的检测模块分配对应的线程数时，基于令桶牌控制算法控制所述初始检测阶段中检测模块的待处理数据的接收数量。

第二方面，本申请提供一种车载入侵检测系统的资源调度装置，所述车载入侵检测系统包括用于执行不同车载入侵检测阶段的若干检测模块，所述车载入侵检测阶段包括初始检测阶段和后处理阶段，所述装置包括：

获取模块，其设置为获取所述若干检测模块进行入侵检测所需的线程资源以及所述若干检测模块各自关于线程资源的调度权重上限；

第一确定模块，其设置为在所述后处理阶段的一个或多个检测模块存在待处理数据时，实时基于所述线程资源和所述后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数；

第二确定模块，其设置为基于所述若干检测模块各自的当前线程数及其对应的调度权重上限按照所述可分配线程数确定各个检测模块的分配权重；

分配模块，其设置为基于所述分配权重为各个检测模块分配对应的线程数，所述线程数用于处理对应检测模块进行入侵检测的待处理数据。

第三方面，提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现所述的车载入侵检测系统的资源调度方法。

第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现所述的车载入侵检测系统的资源调度方法。

本申请提供的车载入侵检测系统的资源调度方法、装置、设备及介质，通过获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限；在后处理阶段的一个或多个检测模块存在待处理数据时，实时基于线程资源和后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数；基于若干检测模块各自的当前线程数及其对应的调度权重上限按照可分配线程数确定各个检测模块的分配权重；基于分配权重为各个检测模块分配对应的线程数，可以有效解决车载入侵检测系统的资源分配不均衡的问题，并达到提升入侵检测性能，同时不影响其他功能的正常使用的技术效果。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的一种可能的场景示意图；

图2为本申请实施例提供的一种车载入侵检测系统的资源调度方法的流程图；

图3为本申请实施例中车载入侵检测系统的一种可能的架构图；

图4为本申请实施例提供的另一种车载入侵检测系统的资源调度方法的流程图；

图5为本申请实施例提供的又一种车载入侵检测系统的资源调度方法的流程图；

图6a为本申请实施例提供的车载入侵检测系统的资源调度方法对应的动态加权调度模型的实例图之一；

图6b为相关技术中流水线模型的实例图；

图6c为相关技术中全并行模型的实例图；

图6d为本申请实施例提供的车载入侵检测系统的资源调度方法对应的动态加权调度模型的实例图之二；

图7为本申请实施例提供的车载入侵检测系统的资源调度装置的结构示意图；

图8为本申请实施例提供的一种电子设备的示意图；

图9是本申请一个示例性实施例示出的一种终端设备的框图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

下面对结合应用场景对本申请实施例进行解释，本申请实施例提供的车载入侵检测系统的资源调度方法可以应用于自动驾驶的应用场景下，更具体地，可以应用于基于车云计算的自动驾驶应用场景下，示例性地，本申请实施例提供的方法的执行主体可以为智能汽车，更具体地，例如为智能汽车的域控制器、中心控制器，下面以域控制器为本申请实施例提供的方法的执行主体进行介绍。图1为本申请实施例提供的一种车载入侵检测系统的资源调度方法示意图，如图1所示，智能汽车101的域控制器可以主动检测扫描运行程序和运行配置有无发生变更，运行程序如导航程序、自动驾驶程序等，运行配置是智能汽车101在行使过程中产生的配置文件，进一步的，在域控制器确定运行程序和运行配置发生变更后，则收集可能的疑似入侵行为，疑似入侵行为为运行程序和运行配置发生变更等行为，如自动驾驶程序被篡改的行为，疑似入侵行为对应有行为数据，进一步的，域控制器对疑似入侵行为进行处理，确定汽车域控制器是否发生车载入侵。

相关技术中，对于疑似入侵行为的检测过程，通常由车载入侵检测系统基于接收到的新消息，并提取新消息的标识和时间戳，根据标识确定对应的时间信息，然后根据时间戳和时间信息按照预设的检测条件，检测新消息是否发生异常，以此判断是否发生车载入侵。此过程中，由于车载系统有限的系统资源，上述车载入侵检测系统没有对各个阶段的资源进行合理分配，容易导致系统资源不均衡，如导致部分检测功能无法获取系统资源运行，甚至导致部分功能不可用，从而影响车载系统在安全方面的性能。

目前的系统调度分配方案一般有串行模型，流水线模型，全并行模型。其中串行模型就是只有1个线程每次只处理1个消息，执行效率极低；全并行模型就是分配N个线程每次同时处理N个消息，但是如果有访问互斥的共享资源会导致性能急剧下降，并且如果分配太多线程，性能有可能不增反降。流水线模型则是将执行流分为多个模块阶段，每个阶段占整个执行的运行比例分配相应线程，从而尽量降低了全并行模型访问互斥的共享资源导致性能急剧下降的影响。比如入侵检测系统可划分为4个阶段，每个阶段运行时长占比为1:1:2:1，这样分配5m个线程按照m/m/2m/m分配就是流水线模型的分配方案。这样访问互斥资源的冲突就会减少到只有N/5个，降低了访问互斥的共享资源的性能下降。

流水线模型尽管优化了资源分配，但是其对线程资源必须按照运行比例数分配的方式，对于估算准确性要求太高。如果估算的比例不正确，会导致执行长的模块分配线程不够，最终整个流水线都会因此而降低处理性能。如每个阶段运行时长占比估算为1:1:1:1，但是实际是1:1:2:1，按照估算分配只有按最优分配性能的50％。反之，如果分配了多余线程给模块，又会导致线程空转浪费。如每个阶段运行时长占比估算为1:1:2:1，但是实际是1:1:1:1，有一个线程实际是在空转浪费的。因此，流水线模型对于运行估算的准确率要求极高，对于开发人员的要求过高。性能稳定性也较差，如同一套配置在某个场景表现良好，在另一个场景表现可能很差，原因就是每个阶段的调度比例出现变化而无法自适应。

为解决上述问题，本实施例的车载入侵检测系统划分为初始检测阶段和后处理阶段，在域控制器在对疑似入侵行为处理过程中，利用不同检测阶段的检测模块依次对行为数据及行为数据衍生的数据(以下称为待处理数据)进行处理。并通过获取各个检测模块所需的线程资源以及各个检测模块的调度权重上限，实时根据线程资源和后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数，然后根据各个检测模块的当前线程数及其对应的调度权重上限按照可分配线程数确定各个检测模块的分配权重，并利用该分配权重为各个检测模块分配对应的线程数，用于处理各个模块的待处理数据。此过程中，动态调整模块权重，并通过加权调度分配线程资源给入侵检测的各个检测模块，使得调度方法可以自适应各个检测模块变化的影响，入侵检测系统可以高效利用分配的线程资源，高性能的完成车辆入侵检测处理，有效减少车载入侵检测的线程资源浪费，达成合理资源消耗和检测效率平衡。

可选地，智能汽车101和终端设备102电连接，若确定智能汽车101发生车载入侵，可以生成相应的安全策略，以使智能汽车101执行该安全策略，减少危险的发生，同时，还可以将本次车载入侵检测结果及对应的过程数据发送给终端设备102，以便终端设备102进行数据分析，或者利用本次车载入侵检测结果生成告警信息发送至终端设备102进行显示，以使用户及时了解智能汽车101运行情况。可以理解的，终端设备102可以包括但不限于，电脑、智能手机、平板电脑、电子书阅读器、动态影像专家压缩标准音频层面3(MovingPicture experts group audio layer III，简称MP3)播放器、动态影像专家压缩标准音频层面4(Moving Picture experts group audio layer IV，简称MP4)播放器、便携计算机、车载电脑、可穿戴设备、台式计算机、机顶盒、智能电视等等。

可选地，该车载入侵检测系统也可以部署在终端设备102，或者外部服务器中，通过网络实时收集智能汽车101发送的行为数据并确定可能的入侵行为，对其进行处理，判断有无发生车载入侵，进而发送消息指令控制智能汽车101，本申请实施例对车载入侵检测系统的部署位置不做具体限定，其可以部署在智能汽车内部，也可以部署在智能汽车外部。

下面结合附图和具体的实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。需要说明的是，这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

图2为本申请一个实施例提供的车载入侵检测系统的资源调度方法的流程图，本实施例的车载检测入侵系统包括用于执行不同车载入侵检测阶段的若干检测模块，车载入侵检测阶段包括初始检测阶段和后处理阶段，如图2所示，本实施例提供的车载入侵检测系统的资源调度方法包括以下步骤S201-S204。

本实施例中，初始检测阶段的检测模块包括用于采集行为数据的初检模块；后处理阶段的检测模块包括用于识别行为数据对应的行为是否为入侵行为的二次确认模块、用于获取入侵行为的入侵数据的数据收集模块以及用于根据入侵数据生成入侵响应策略的数据处理模块。

在一可实现中，不同车载入侵检测阶段及其检测模块和具体功能示例如下表1：

表1

在一些实施例中，车载入侵检测阶段除了初始检测阶段和后处理阶段之外，还可以根据实际应用增加对应的检测阶段，例如校验阶段，可用于对后处理阶段中生成的数据进行校验等；相应的，初始检测阶段以及后处理阶段的检测模块也可以不限于上述检测模块，可以根据实际应用增加对应的检测模块，此处不再赘述。

进一步地，车载入侵检测系统还包括分别连接后处理阶段中各个检测模块的若干缓存队列，若干缓存队列分别用于存储对应检测模块中的待处理数据。

本实施例中，后处理阶段中的各个检测模块分别连接有对应的缓存队列，各个阶段的缓存队列的长度可以根据实际应用进行适应性设定，利用缓存队列可以有效限制后处理阶段中各个检测模块的待处理数据的队列，实现控制整个检测系统对运行资源占用。

示例性的，初始检测阶段中的检测模块不设置对应的缓存队列，以避免行为数据过多时造成的数据堵塞或者数据丢失，而是结合令牌桶控制进入初始检测阶段中的行为数据，来避免过多的资源占用。结合图3所示，可以进行动态加权调度的车载入侵检测系统由4个检测模块、3个缓存队列、以及令牌桶组成。其中4个检测模块是针对不同阶段进行入侵行为处理的划分，3个缓存队列是负责存储对应模块待处理的消息。在一些实施例中，上述检测模块划分可以根据实际需要重新划分及调整。

示例性的，入侵检测系统中各个组件间关系，可以参考下表2：

表2

步骤S201、获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限。

相关技术中，入侵检测系统在进行入侵检测时直接占用车载系统的系统资源进行入侵检测，容易造成占用过多资源影响车载系统的其他功能的正常使用，本实施例在进行资源调度之前，首先获取入侵检测所需的线程资源以及各检测模块的调度权重上限，并在该线程资源和对应的调度权重上限下对各检测模块进行实时资源调度，在提高入侵检测效率的同时，有效减少资源消耗或者不足的情况。

可以理解的，线程，又称为轻量进程(Lightweight Process，简称LWP)，是程序执行流的最小单元。本实施例中的入侵检测所需的线程资源即车载入侵检测系统入侵检测所需的调度线程总数。

在一种实施方式中，为了进一步提高入侵检测效率，并减少资源消耗或不足的情况，根据各检测模块的运行时长获取线程资源和各检测模块的调度权重上限。具体地，步骤S201获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限，可以包括以下步骤：

基于若干检测模块各自的运行时长获取若干检测模块之间的关于线程资源的调度权重比例；

基于调度权重比例获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限。

本实施例中，检测模块的运行时长可以根据初始调度分配和正式运行中的调度分配适应性计算获得，例如，在初始分配时按照经验估算各个运行模块的运行时长；在正式运行后，通过累计各个模块的本身实际运行时间，估算出模块平均运行时长。

在一可实现中，通过获取各个检测模块的运行时长，并获取各个检测模块的运行时长占比，如比例为1/W2/W3/W4(1表示初检模块；2表示二次确认模块；3表示数据收集模块；4表示处理模块；其中1对应的各检测模块的比例是以初始检测阶段的调度权重为单位，也可以表示为W1)，即对应各个检测模块的调度权重比例。

可以理解的，本实施例以权重和线程1:1进行示例，即线程数对应权重数，在一些复杂案例(线程数过多)中时可以按照调度权重比例进行缩放。

本实施例中的调度线程总数的计算规则可以为，线程总数＝规则floor(1+W2+W3+W4)*m(floor表示向下取整，m≥1)＝Wt*m(Wt表示权重总数，每个线程组的线程总数)，本实施例以m＝1，一个线程组的调度过程为例，在一些实施例中，可以将线程分为m个线程组，每个线程组分别调度，线程组间独立调度。

本实施例中各个检测模块的调度权重上限W_{i_max}的计算规则可以为，在当前调度权重数的基础上增加一个权重数，如按照比例1:1:2.3:1计算各个模块的调度权重上限:X/2/3/2(X表示不限制)，具体如下：

W_{1_max}＝X(X表示不限制；i＝1)

W_{i_max}＝ceil(W_i+1)(ceil表示向上取整；i！＝1)

可以理解的，本实施例对初检模块的调度权重上限可以设置为无限大，这样可以在其它检测模块没有待处理数据需要处理时，可以将所有线程资源在初始检测模块中进行调度，以实时高效检测接收到的行为数据，再数据进入到后处理阶段的各检测模块时，再进行可分配线程的实时调度，达到高效利用有限的线程资源的技术效果；在一些实施例中，对于初始检测阶段中的检测模块不止一个检测模块的情况，可以对该初始检测阶段中的所有模块的调度权重上限设置为X。

可以理解的，对于后处理阶段中的各个检测模块的调度权重上限为允许多分配1个权重数(线程)，在一可实现中，可以结合各个检测模块的调度优先级统一考虑，例如给后一个调度优先级的前提是当前模块的缓存队列存在消息积压，只有分配更多资源给流程的尾部模块(例如数据处理模块或者数据收集模块)，才可能加速尾部流程处理，否则该线程将会用于流程的前部模块(如初检模块)，导致积压更多消息等待尾部流程处理。同时，又不能分配太多流程前部模块资源，否则会出现线程集中分配给流程后部模块或前部模块线程，导致流水线无法完全错开，因此，本实施例允许后部模块在积压时多占用1个线程，在一些实施例中，根据实际应用的线程资源也可以对多分配的权重数进行调整。

本实施例根据各个检测模块的运行开销获取入侵检测系统进行入侵检测所需的线程资源及对应的调度权重上限，可以有效提高入侵检测系统的检测效率，同时不占用过多的线程资源。

步骤S202、在后处理阶段的一个或多个检测模块存在待处理数据时，实时基于线程资源和后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数。

本实施例中，考虑到在整个入侵检测过程中，作为数据处理的尾部模块的数据堆积，更加容易导致整个入侵检测流程陷入滞纳，导致系统运转困难，本实施例通过在后处理阶段中的一个或多个检测模块存在待处理数据时，根据总线程数和后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数，实现线程资源的动态分配。其中，后处理阶段的一个或多个检测模块可以根据后处理阶段中的模块数量和/或总线程数进行确定，例如后处理阶段的模块较少，如本实施例中示例的后处理阶段中的3个检测模块，该一个或多个检测模块确定为2个，分别为数据收集模块和数据处理模块。在一些实施例中，还可以为其他方式，此处不再多作赘述。

上述过程中，可分配线程数的确定方式相当于，将初检模块和二次确认模块(也可以仅为初检模块)作为流程前部模块，数据收集模块和数据处理模块作为流程后部模块，在后部模块存在待处理数据时，根据总线程数以及前部模块占用线程进行重新分配，同时检查每个检测模块是否已达到调度权重上限，达到调度权重上限的检测模块则不参与本次重分配资源过程。此过程中，可以实现前部资源和后部资源的灵活均衡调度，并有效避免尾部模块的数据堵塞问题。可以理解的，当前线程数即，进行资源调度的当前时刻的线程数。

在一可实现中，可以首先检测当前线程资源的占用状态，进而确定可分配线程数。具体地，在车载入侵检测系统的运行过程中，如果当前总线程数占用率为百分之百，即可以自由调度或者闲置的线程数为0，即总分配权重(当前可分配线程数)Wc≤0(通常不会出现Wc<0的情况，此处为考虑了编码中的容错写法)，执行上述过程确定可分配线程数。

步骤S203、基于若干检测模块各自的当前线程数及其对应的调度权重上限按照可分配线程数确定各个检测模块的分配权重。

本实施例中，根据各个检测模块的当前线程数、调度权重上线按照可分配线程数确定各个检测模块的分配权重，可以实现对各个检测模块的动态权重调度。

在一种实施方式中，通过将当前线程数达到调度权重上线的模块的分配权重确定为零，以避免对应模块占用过多线程，导致其它检测模块的可调度线程资源较少，进而影响车载入侵检测效率。具体地，步骤S203基于若干检测模块各自的当前线程数及其对应的调度权重上限按照可分配线程数确定各个检测模块的分配权重，包括：

基于若干检测模块各自的当前线程数及其对应的调度权重上限判断各个检测模块的当前线程数是否达到调度权重上限对应的线程数；

在存在检测模块的当前线程数达到调度权重上限对应的线程数的情况下，将检测模块的分配权重确定为零。

示例性的，可分配线程数为10，各个检测模块的调度权重上限为3/2/3/2，当前各个检测模块的当前线程数为2/2/2/2，说明二次确认模块和数据处理模块的权重调度上限，权重上限的检测模块确定其分配权重为0，其它检测模块的分配权重可以为1:1的比例，在一些实施例中，还可以结合实际应用设置为其他比例。

步骤S204、基于分配权重为各个检测模块分配对应的线程数，线程数用于处理对应检测模块进行入侵检测的待处理数据。

本实施例中的分配权重和分配线程数按照1:1，即分配权重(数)等于分配线程数，在一些实施例中，分配权重可与分配线程数不相同，分配权重对应于分配线程数的比例。

示例性的，在当前的总分配权重Wc≤0时，确定可分配线程数Wc＝Wt-C3-C4，将所有检测模块加入到可分配列表{1,2,3,4}，比较检测模块分配线程数C1/C2/C3/C4和调度权重上限W1_max/W2_max/W3_max/W4_max，并将达到调度权重上限的模块从可分配列表移除，对于没有达到调度权重上限的检测模块，分配调度权重同比例，并按照可分配线程数，根据各个检测模块的调度优先级高到低开始(SP3>SP2>SP1)遍历可分配列表(每次可基于1个线程进行遍历)，执行如下步骤：如缓存队列为空，跳过；如缓存队列中有待处理数据，则分配该线程执行队列对应检测模块，在一些情况下，如非特定检测模块(待处理数据较多，线程需求量大)，例如初始检测模块或者二次确认模块则从可分配列表移除对应的检测模块，并设置Wc＝Wc–1。

在一些实施例中，为了进一步保障资源调度的有效性，还可以通过设置调度预设时长，在调度间隔时间达到预设阈值时，重新计算每个检测模块的时长占比，并基于上述步骤中重新计算调度权重；在调度间隔时间未达到预设阈值时，则可以基于上述分配过程继续进行线程调度。

进一步地，为了避免过多数据进入到车载入侵检测系统，同时避免过多的线程资源占用，本申请实施例结合令牌桶算法控制进入到初检模块中的数据量。具体地，方法还可以包括以下步骤：在为初始检测阶段的检测模块分配对应的线程数时，基于令桶牌控制算法控制初始检测阶段中检测模块的待处理数据的接收数量。

可以理解的，令牌桶算法是网络流量整形(Traffic Shaping)和速率限制(RateLimiting)中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。本实施例通过令牌桶算法，控制入侵检测资源消耗，以达成资源消耗和检测性能平衡的技术效果。

在一可实现中，如线程分配到初检模块，执行如下步骤：A、令牌桶令牌不足则睡眠等待，直到获取足够通行的令牌；B、消费通行令牌。如果线程没有分配到初检模块，按照当前的实际令牌数进行数据处理。

本实施例中，通过在检测模块间进行动态加权调度，可以有效改进流水线模型中线程资源固定难以保障各阶段高效运行及资源浪费等问题，通过定时收集每个检测模块的运行时长，以此作为依据计算出每个检测模块的最佳调度权重，动态调整每个模块分配比例。在每轮调度中，每个检测模块分配的线程数都不会超过检测模块的最佳调度权重，可以有效保证每个检测模块按照最佳比例运行，使得入侵检测系统能够高性能的完成车辆入侵检测处理，并有效减少车载入侵检测的线程资源浪费，达成合理资源消耗和检测效率平衡。

请参照图4，图4为本申请实施例提供的另一种车载入侵检测方法的流程示意图，在上述实施例的基础上，本实施例考虑到在入侵检测阶段中不同检测模块中的数据量的差异性，尾部模块如果更快处理完数据，将会产生线程空闲的情况，为了进一步合理利用线程资源，本实施例将初始检测阶段的检测模块的调度权重上限为无限大，并在除了上述实施例对应的步骤S201-S204之外，在步骤S201获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限之后，还设置步骤S401。

步骤S401、在后处理阶段的所有检测模块均不存在待处理数据且所有检测模块的当前线程数之和为零时，直接基于线程资源为初始检测阶段的检测模块分配对应的线程数。

示例性的，在对线程资源进行调度时，首先统计线程组各个检测模块的当前线程数C₁/C₂/C₃/C₄，如果C₂+C₃+C₄＝0且SP1、SP2和SP3队列为空(没有待处理数据)时可进入调度准备阶段，此时设置W_c＝0，并基于线程资源为初检模块分配线程数，例如此时C1也为0，可以将全部线程资源分配给C1，例如此时C1为1，则为初检模块分配(线程资源-1)个线程数。

本实施例中，在其它检测模块没有待处理数据需要处理时，可以将所有线程资源在初始检测模块中进行调度，以实时高效检测接收到的行为数据，在数据进入到后处理阶段的各检测模块时，再进行可分配线程的实时调度，达到高效利用有限的线程资源的技术效果。

在一些实施例中，考虑到二次确认模块为初检模块的后部模块，即将处理来自处理模块的数据，为使二次确认模块快速进入处理流程，在C₃+C₄＝0，且SP2和SP3队列为空，且SP1不为空时，先为二次确认模块分配一个(或者更多个)线程资源，然后根据剩余的线程资源分配给初检模块。

请参照图5，图5为本申请实施例提供的又一种车载入侵检测方法的流程示意图，在上述实施例的基础上，本实施例通过确定各个检测模块的调度优先级，并根据该调度优先级和对应的分配权重为检测模块分配线程数，可提高线程调度的灵活性，使得重要模块获得更多的线程资源，以提高车载入侵检测的检测性能。具体的，除了上述步骤S201-S204之外，本实施例在步骤S204基于所述分配权重为各个检测模块分配对应的线程数之前，还包括步骤S501和步骤S502，并将步骤S204进一步划分为步骤S204a。

步骤S501、基于后处理阶段中各个检测模块的待处理数据的处理顺序确定若干缓存队列的优先级，其中，处理顺序是基于后处理阶段中各检测模块之间的数据流向确定的。

步骤S502、基于若干缓存队列的优先级确定若干检测模块的调度优先级。

步骤S204a、基于若干检测模块的调度优先级和分配权重为各个检测模块分配对应的线程数。

可以理解的，本实施例中的数据流向为初检模块→二次确认模块→数据收集模块→数据处理模块，其中缓存队列的优先级在上文已提及，SP1队列<SP2队列<SP3队列。在一可实现中，初检模块未设置调度优先级，其调度优先级可以为各个检测模块中最低的优先级，利用令牌桶控制数据的写入量。

下面结合图6a-图6d，展示本实施例对应的动态加权调度模型、相关技术中流水线模型、全并行模型的调度实例，以进一步区别本实施例与相关技术中调度过程及效果。图示例子假定各检测模块的运行时长比为1:1:2.5:1，分配5个线程，不同模型处理相同数量的消息(待处理数据)的调度过程，其中，a、b、c、d分别表示初检模块、二次确认模块、数据收集模块和数据处理模块，a、b、c、d框的粗细程度分别代表对应的5个线程。

其中，图6a、图6b和图6c分别展示动态加权调度模型和流水线模型、全并行模型在相同的5个线程资源下，动态加权调度模型处理21个消息的最优调度过程。动态加权调度模型处理21个消息只需要25.5T，流水线模型需要30.5T，全并行模型需要27.5T。

从图6a、图6b和图6c的例子可知，动态加权调度模型和全并行模型优于流水线模型。动态加权调度模型和全并行模型性能交替领先，可理解为基本相当。

图6d则展示动态加权调度模型在相同的5个线程资源下，处理26个消息调度过程，共需31T。对比图6a动态加权调度模型处理21个消息调度过程，明显看出调度已经处于类似流水线调度。每隔5.5个周期完成5个消息，并且消息间执行的模块都是错开的，能够极大减少同一模块访问互斥资源串行等待的概率。

流水线模型优于全并行模型的地方主要是调度过程中如出现访问互斥资源时的表现。流水线模型是尽量将各个线程执行的任务错开，极大减少了线程等待互斥资源访问的空转浪费，线程可以一直都是高效工作，不会出现长时间阻塞。但流水线模型对于模块运行效率变化或初始评估模块效率有偏差时，无法动态调整线程分配，没办法达到流水线的最佳性能。

动态加权调度模型在流水线模型的基础上，首先获取线程资源对应的调度权重上限，并定时采集各个模块的运行情况，定时调整线程资源分配，使其能满足流水线的最佳配比。而在无法完全满足流水线最佳配比时，优先分配资源给最靠近消息完成的阶段模块(即数据处理模块>数据收集模块>二次确认模块>初检模块)，防止消息积压，保证整体消息处理的处理性能，同时降低单个消息的处理时延。

从上述实例可以看出，本实施例对应的动态加权调度模型明显优于相关技术中的流水线模型和全并行模型。

请参照图7，图7为本申请实施例提供的一种车载入侵检测系统的资源调度装置的结构示意图，车载入侵检测系统包括用于执行不同车载入侵检测阶段的若干检测模块，车载入侵检测阶段包括初始检测阶段和后处理阶段，如图7所示，装置包括：

获取模块71，其设置为获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限；

第一确定模块72，其设置为在后处理阶段的一个或多个检测模块存在待处理数据时，实时基于线程资源和后处理阶段中的一个或多个检测模块的当前线程数之和确定可分配线程数；

第二确定模块73，其设置为基于若干检测模块各自的当前线程数及其对应的调度权重上限按照可分配线程数确定各个检测模块的分配权重；

分配模块74，其设置为基于分配权重为各个检测模块分配对应的线程数，线程数用于处理对应检测模块进行入侵检测的待处理数据。

在一种实施方式中，初始检测阶段的检测模块包括用于采集行为数据的初检模块；后处理阶段的检测模块包括用于识别行为数据对应的行为是否为入侵行为的二次确认模块、用于获取入侵行为的入侵数据的数据收集模块以及用于根据入侵数据生成入侵响应策略的数据处理模块。

在一种实施方式中，车载入侵检测系统还包括分别连接后处理阶段中各个检测模块的若干缓存队列，若干缓存队列分别用于存储对应检测模块中的待处理数据。

在一种实施方式中，获取模块71，包括：

第一获取单元，其设置为基于若干检测模块各自的运行时长获取若干检测模块之间的关于线程资源的调度权重比例；

第二获取单元，其设置为基于调度权重比例获取若干检测模块进行入侵检测所需的线程资源以及若干检测模块各自关于线程资源的调度权重上限。

在一种实施方式中，第二确定模块73，包括：

判断单元，其设置为基于若干检测模块各自的当前线程数及其对应的调度权重上限判断各个检测模块的当前线程数是否达到调度权重上限对应的线程数；

权重确定单元，其设置为在存在检测模块的当前线程数达到调度权重上限对应的线程数的情况下，将检测模块的分配权重确定为零。

在一种实施方式中，初始检测阶段的检测模块的调度权重上限为无限大，

线程分配模块74还设置为，在后处理阶段的所有检测模块均不存在待处理数据且所有检测模块的当前线程数之和为零时，直接基于线程资源为初始检测阶段的检测模块分配对应的线程数。

在一种实施方式中，装置还包括：

优先级确定模块，基于后处理阶段中各个检测模块的待处理数据的处理顺序确定若干缓存队列的优先级，其中，处理顺序是基于后处理阶段中各检测模块之间的数据流向确定的；以及，基于若干缓存队列的优先级确定若干检测模块的调度优先级；

分配模块74具体设置为，基于若干检测模块的调度优先级和分配权重为各个检测模块分配对应的线程数。

在一种实施方式中，装置还包括：

数据控制模块，其设置为在为初始检测阶段的检测模块分配对应的线程数时，基于令桶牌控制算法控制初始检测阶段中检测模块的待处理数据的接收数量。

相较于现有技术中车载入侵检测系统主要是照搬或裁剪传统计算机行业的入侵检测系统到车端，而并未区分不同的入侵行为对车载系统的影响，同时也未区别优化处理，因此在入侵行为洪水攻击时通常容易造成系统崩溃等情况，本申请实施例基于动态加权调度，对入侵检测模块化，通过动态加权算法分配资源提高整体检测性能，同时通过令牌桶算法，控制入侵检测资源消耗，达成资源消耗和检测性能平衡，即使在面对入侵行为洪水攻击时，也能够进行有效检测。

相关说明可以对应参见图2-图5所对应的实施例中的步骤所对应的相关描述和效果进行理解，此处不做过多赘述。

请参照图8，图8为本申请实施例提供的电子设备的示意图，如图8所示，本实施例提供的电子设备8包括：处理器81，以及与处理器81通信连接的存储器82。

其中，存储器82存储计算机执行指令；

处理81执行存储器82存储的计算机执行指令，以实现本申请图2-图5所对应的实施例中任一实施例提供的车载入侵检测系统的资源调度方法。

其中，存储器82和处理器81通过总线83连接。

本申请实施例相应还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行以实现本申请图2-图5所对应的实施例中任一实施例提供的车载入侵检测系统的资源调度方法。

其中，计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本申请一个实施例提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现本申请图2-图5所对应的实施例中任一实施例提供的车载入侵检测系统的资源调度方法。

图9是本申请一个示例性实施例示出的一种终端设备的框图，该终端设备900可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

终端设备900可以包括以下一个或多个组件：处理组件902，存储器904，电源组件906，多媒体组件908，音频组件910，输入/输出(I/O)接口912，传感器组件914，以及通信组件916。

处理组件902通常控制终端设备900的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件902可以包括一个或多个处理器920来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件902可以包括一个或多个模块，便于处理组件902和其他组件之间的交互。例如，处理组件902可以包括多媒体模块，以方便多媒体组件908和处理组件902之间的交互。

存储器904被配置为存储各种类型的数据以支持在终端设备900的操作。这些数据的示例包括用于在终端设备900上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器904可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件906为终端设备900的各种组件提供电力。电源组件906可以包括电源管理系统，一个或多个电源，及其他与为终端设备900生成、管理和分配电力相关联的组件。

多媒体组件908包括在终端设备900和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件908包括一个前置摄像头和/或后置摄像头。当终端设备900处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件910被配置为输出和/或输入音频信号。例如，音频组件910包括一个麦克风(MIC)，当终端设备900处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器904或经由通信组件916发送。在一些实施例中，音频组件910还包括一个扬声器，用于输出音频信号。

I/O接口912为处理组件902和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件914包括一个或多个传感器，用于为终端设备900提供各个方面的状态评估。例如，传感器组件914可以检测到终端设备900的打开/关闭状态，组件的相对定位，例如组件为终端设备900的显示器和小键盘，传感器组件914还可以检测终端设备900或终端设备900一个组件的位置改变，用户与终端设备900接触的存在或不存在，终端设备900方位或加速/减速和终端设备900的温度变化。传感器组件914可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件914还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件914还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件916被配置为便于终端设备900和其他设备之间有线或无线方式的通信。终端设备900可以接入基于通信标准的无线网络，如WiFi，3G、4G、5G或其他标准通信网络，或它们的组合。在一个示例性实施例中，通信组件916经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件916还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，终端设备900可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述本申请图2-图5所对应的实施例中任一实施例提供的方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器904，上述指令可由终端设备900的处理器920执行以完成上述方法。例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本申请实施例还提供了一种非临时性计算机可读存储介质，当该存储介质中的指令由终端设备的处理器执行时，使得终端设备900能够执行上述本申请图2-图5所对应的实施例中任一实施例提供的方法。

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

本领域技术人员在考虑说明书及实践这里公开的申请后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims

1.一种车载入侵检测系统的资源调度方法，其特征在于，所述车载入侵检测系统包括用于执行不同车载入侵检测阶段的若干检测模块，所述车载入侵检测阶段包括初始检测阶段和后处理阶段，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述初始检测阶段的检测模块包括用于采集行为数据的初检模块；所述后处理阶段的检测模块包括用于识别所述行为数据对应的行为是否为入侵行为的二次确认模块、用于获取所述入侵行为的入侵数据的数据收集模块以及用于根据所述入侵数据生成入侵响应策略的数据处理模块。

3.根据权利要求1或2所述的方法，其特征在于，所述车载入侵检测系统还包括分别连接所述后处理阶段中各个检测模块的若干缓存队列，所述若干缓存队列分别用于存储对应检测模块中的待处理数据。

4.根据权利要求1所述的方法，其特征在于，所述获取所述若干检测模块进行入侵检测所需的线程资源以及所述若干检测模块各自关于线程资源的调度权重上限，包括：

5.根据权利要求1所述的方法，其特征在于，所述基于所述若干检测模块各自的当前线程数及其对应的调度权重上限按照所述可分配线程数确定各个检测模块的分配权重，包括：

6.根据权利要求1所述的方法，其特征在于，所述初始检测阶段的检测模块的调度权重上限为无限大，

7.根据权利要求3所述的方法，其特征在于，在基于所述分配权重为各个检测模块分配对应的线程数之前，还包括：

8.根据权利要求1所述的方法，其特征在于，还包括：

9.一种车载入侵检测系统的资源调度装置，其特征在于，所述车载入侵检测系统包括用于执行不同车载入侵检测阶段的若干检测模块，所述车载入侵检测阶段包括初始检测阶段和后处理阶段，所述装置包括：

10.一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至8中任一项所述的车载入侵检测系统的资源调度方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至8中任一项所述的车载入侵检测系统的资源调度方法。