车辆的控制方法及装置与流程

文档序号:16993982发布日期:2019-03-02 01:12阅读:158来源:国知局
车辆的控制方法及装置与流程

本发明涉及车辆控制技术领域,具体而言,涉及一种车辆的控制方法及装置。



背景技术:

现有的汽车的锁车方案,存在一种失效模式,在终端与电子控制单元ecu(electroniccontrolunit)之间如果握手失败,将导致后续向ecu发送的指令,ecu将不会再执行,最直接的后果就是车辆不受控制。相关技术中,只有上述握手成功后,ecu才会继续执行接收的指令,在现有的锁车方案中,只有握手成功之后,下次修改参数和解绑指令才可以正常执行。在握手失败的情况下,会导致车辆不受控制。

针对上述的问题,目前尚未提出有效的解决方案。



技术实现要素:

本发明实施例提供了一种车辆的控制方法及装置,以至少解决相关技术中握手校验失败时,车辆控制器不再接收任何控制指令,导致车辆不受控制的技术问题。

根据本发明实施例的一个方面,提供了一种车辆的控制方法,包括:与控制终端进行握手校验,其中,所述握手校验包括对控制终端进行验证;握手校验结束后,接收控制终端发出的控制指令,所述控制指令包括发出所述控制指令的控制终端的验证信息;根据所述验证信息对所述控制指令进行验证;在所述控制指令验证通过的情况下,根据所述控制指令控制车辆动作。

可选的,与控制终端进行握手校验包括:向控制终端发出握手请求;接收所述控制终端响应于所述握手请求发送的加密数据,其中,所述加密数据包括所述控制终端的验证信息;验证所述验证信息是否正确。

可选的,验证所述验证信息是否正确包括:在所述验证信息正确的情况下,确定握手校验成功,继续执行接收的所述控制终端发出的控制指令;在所述验证信息不正确的情况下,确定握手校验失败,对接收的所述控制终端的控制指令不予执行。

可选的,握手校验失败之后包括:对所述控制终端重新进行握手校验;在握手校验多次失败后,触发防拆机制。

可选的,所述验证信息包括所述控制终端的id信息,和/或密钥信息。

可选的,在上电前的预定时间,进行握手校验。

根据本发明实施例的另一方面,还提供了一种车辆控制装置,包括:握手模块,用于与控制终端进行握手校验,其中,所述握手校验包括对控制终端进行验证;接收模块,用于握手校验结束后,接收控制终端发出的控制指令,所述控制指令包括发出所述控制指令的控制终端的验证信息;验证模块,用于根据所述验证信息对所述控制指令进行验证;控制模块,用于在所述控制指令验证通过的情况下,根据所述控制指令控制车辆动作。

可选的,所述握手模块包括:发送单元,用于向控制终端发出握手请求;接收单元,用于接收所述控制终端响应于所述握手请求发送的加密数据,其中,所述加密数据包括所述控制终端的验证信息;验证单元,用于验证所述验证信息是否正确。

根据本发明实施例的另一方面,还提供了一种存储介质,所述存储介质包括存储的程序,其中,在所述程序运行时控制所述存储介质所在设备执行上述中任意一项所述的方法。

根据本发明实施例的另一方面,还提供了一种处理器,所述处理器用于运行程序,其中,所述程序运行时执行上述中任意一项所述的方法。

在本发明实施例中,采用与控制终端进行握手校验,其中,所述握手校验包括对控制终端进行验证;握手校验结束后,接收控制终端发出的控制指令,所述控制指令包括发出所述控制指令的控制终端的验证信息;根据所述验证信息对所述控制指令进行验证;在所述控制指令验证通过的情况下,根据所述控制指令控制车辆动作的方式,通过将检测信号转化为数字信号,达到了根据检测信号的状态持续时间确定负载故障状态的持续时间的目的,从而实现了对负载的故障状态的持续时间进行有效检测的技术效果,进而解决了相关技术中握手校验失败时,车辆控制器不再接收任何控制指令,导致车辆不受控制的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:

图1是根据现有技术的锁车方法示意图;

图2是根据本发明实施例的一种车辆控制方法的流程图;

图3是根据本发明实施方式的一种锁车方法的示意图;

图4是根据本发明实施方式的握手校验时终端的加密数据的示意图;

图5是根据本发明实施方式的握手校验后指令中的终端的加密数据的示意图;

图6是根据本发明实施例的一种车辆控制装置的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。

需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

图1是根据现有技术的一种锁车方法流程图,如图1所示,针对现行的锁车方案,存在一种失效模式,即终端与ecu之间在上电的前5秒如果握手失败,将导致平台后续下发任何的指令,ecu将不会再执行。最直接的后果是车辆将不受控制。在旧的锁车方案中,只有握手成功之后,下次修改参数和解绑指令才可以正常执行,如果握手失败,ecu只能执行防拆。

根据本发明实施例,提供了一种负载故障检测方法的方法实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。

图2是根据本发明实施例的一种车辆控制方法的流程图,如图2所示,该方法包括如下步骤:

步骤s202,与控制终端进行握手校验,其中,握手校验包括对控制终端进行验证;

步骤s204,握手校验结束后,接收控制终端发出的控制指令,控制指令包括发出控制指令的控制终端的验证信息;

步骤s206,根据验证信息对控制指令进行验证;

步骤s208,在控制指令验证通过的情况下,根据控制指令控制车辆动作。

通过上述步骤,可以采用与控制终端进行握手校验,其中,握手校验包括对控制终端进行验证;握手校验结束后,接收控制终端发出的控制指令,控制指令包括发出控制指令的控制终端的验证信息;根据验证信息对控制指令进行验证;在控制指令验证通过的情况下,根据控制指令控制车辆动作的方式,通过将检测信号转化为数字信号,达到了根据检测信号的状态持续时间确定负载故障状态的持续时间的目的,从而实现了对负载的故障状态的持续时间进行有效检测的技术效果,进而解决了相关技术中握手校验失败时,车辆控制器不再接收任何控制指令,导致车辆不受控制的技术问题。

上述步骤执行的主体可以是车辆控制器。上述握手校验在握手失败的情况下,车辆控制器将不会执行接收的任何控制指令。由于握手校验是为了验证发送控制指令的终端的合法性,在验证该控制终端合法后,车辆控制器与上述控制终端建立连接,接收并执行其后续发送的控制指令。

上述握手校验结束,可以认为是握手校验结果确定之后,不论该校验结果是成功还是失败,都认为握手校验结束。即使上述握手校验失败,车载控制器还是会继续接收控制指令,只不过不予执行。上述控制指令带有发送该控制指令的验证信息,该验证信息用于验证该控制终端的合法性。

在接收到上述包括验证信息的控制指令之后,对该控制指令中的验证信息进行验证,验证发送该控制指令的控制终端的合法性,从而决定是否执行该控制指令。

在发送上述控制指令的控制终端的合法性验证通过之后,根据该控制指令进行执行。

可选的,与控制终端进行握手校验包括:向控制终端发出握手请求;接收控制终端响应于握手请求发送的加密数据,其中,加密数据包括控制终端的验证信息;验证验证信息是否正确。

上述与控制终端进行握手校验,可以是车辆控制器先向控制终端发出握手请求,也可以是控制终端先向车辆控制器发送握手请求,根据实际需求进行确定。在车辆控制器发出握手请求后,还可以包括:接收控制终端发送的随机数请求,并向控制终端发送随机数反馈,通过上述随机数请求和反馈的步骤,可以使控制终端和车辆控制器之间具有相同的随机数,上述随机数用于车辆控制器之后对终端的验证。

在上述车辆控制向控制终端发送握手请求后,控制终端向车在控制发送表明自己身份的验证信息,上述验证信息可以是经过一定加密处理的加密数据。上述验证信息可以包括终端的id,密钥信息,随机数信息,校验码等,上述验证信息还可以包括一些基础运行参数,例如,最高转速,最大速度等。

可选的,验证该验证信息是否正确包括:在验证信息正确的情况下,确定握手校验成功,继续执行接收的控制终端发出的控制指令;在验证信息不正确的情况下,确定握手校验失败,对接收的控制终端的控制指令不予执行。

在上述车辆控制接收到控制终端发送的验证信息后,根据该验证信息对控制终端的合法性进行确定。并且,在验证信息正确的情况下,确定握手校验成功,继续执行接收的控制终端发出的控制指令;在验证信息不正确的情况下,确定握手校验失败,对接收的控制终端的控制指令不予执行。上述确定握手校验成功和确定握手校验失败均为握手校验结束。

可选的,握手校验失败之后包括:对控制终端重新进行握手校验;在握手校验多次失败后,触发上述车辆的防拆机制。

由于握手校验失败的原因有很多,可能是由于验证信息在发送的过程中出现了数据遗失或者数据篡改,也可能在验证信息加密的情况下,解密机制存在故障,无法正确解密,等多种原因均会导致握手校验失败,为了提高握手校验的验证准确率,因此在首次握手校验失败的情况下,再次进行握手校验,可以进行多次,进行握手校验的次数越多,上述控制终端的误识别率越小。可选的,本实施例中的握手校验进行两次,也即是在首次握手校验失败后,再次发送一次握手校验,如果握手校验两次均失败,则确定上述控制终端不合法,从而触发车辆的防拆机制。

上述防拆机制是防止非法操作对设备进行拆卸的机制,例如,某款汽车产品的内部设计企业的商业机密,为了保护汽车内部的需要保护的设备的保密性,设置防拆机制,根据该防拆机制,对汽车是否被拆卸进行监测,在检测到汽车被拆卸,自动触发防拆操作,例如,对保密的信息进行销毁,对保护的部件进行永久锁死,等等。

可选的,验证信息包括控制终端的id信息,和/或密钥信息。上述验证信息可以包括终端的id,密钥信息,随机数信息,校验码等,上述验证信息还可以包括一些基础运行参数,例如,最高转速,最大速度等。

可选的,在上电前的预定时间,进行握手校验。在车辆控制器上电前进行校验,不会影响车辆控制器上电之后的工作执行,选择预定时间,是方便对握手校验的结果进行确认,例如,上述在首次握手校验失败的情况下,在次发送握手校验,以降低握手校验的验证错误率。

图3是根据本发明实施方式的一种锁车方法的示意图,如图3所示,本申请实施例还提供了一种电子控制器的故障诊断方法作为本实施例的优选实施方式,下面对该优选实施方式进行详细说明。

针对现行的锁车方案,锁车的具体实现流程如下:首先终端和ecu要在上电的前5秒进行握手校验,握手校验过程终端16自己的加密数据如图4所示,其中的加密数据包括了终端的id和密钥。图4是根据本发明实施方式的握手校验时终端的加密数据的示意图。

终端和ecu完成握手校验之后,对终端id和密钥校验成功之后,才可以进行修改参数操作,修改参数的报文数据内容如下图5所示。从图中可以看出修改参数报文中,没有对终端的id和密钥进行校验,因此修改参数只有握手校验通过之后才可以进行修改参数操作。图5是根据本发明实施方式的握手校验后指令中的终端的加密数据的示意图。

针对这种失效模式,提出一种新的解决方案。由于旧的锁车策略在下次修改参数指令中没有校验终端的合法性,只是在车辆上电的前5秒,握手校验过程中对终端的合法性进行了验证,因此如果t-box和ecu之间握手失败,平台下发下次修改参数指令,ecu将不再执行。针对这种失效模式,提出在下次修改参数中增加对终端的合法性校验,如图3所示,在车辆上电前5秒无论握手失败成功与否,只要握手流程结束,平台就可以下发二次修改参数指令而且ecu可以正常执行二次修改参数指令,平台下发的二次修改参数指令将不再受握手校验的影响。

新的锁车逻辑是终端和ecu仍是上电的前5秒进行握手校验,但是无论握手成功或者失败都不再影响修改参数指令的下发。新的锁车逻辑握手加密报文和修改参数加密报文如表1和表2所示。表1是握手校验中终端的加密报文表,表2是修改参数时终端的加密报文表。

表1

表2

从表1和表2第三列可以看出,终端id在修改参数中也进行了校验,所以修改参数指令不再依据握手校验来对终端的合法性进行校验了,修改参数指令中也对终端的合法性进行校验。

图6是根据本发明实施例的一种车辆控制装置的结构示意图,如图6所示,提供了一种车辆控制装置,该装置包括:握手模块62,接收模块64,验证模块66和控制模块68,下面对该装置进行详细说明。

握手模块62,用于与控制终端进行握手校验,其中,握手校验包括对控制终端进行验证;接收模块64,与上述握手模块62相连,用于握手校验结束后,接收控制终端发出的控制指令,控制指令包括发出控制指令的控制终端的验证信息;验证模块66,与上述接收模块64相连,用于根据验证信息对控制指令进行验证;控制模块68,与上述验证模块66相连,用于在控制指令验证通过的情况下,根据控制指令控制车辆动作。

通过上述装置,采用握手模块62与控制终端进行握手校验,其中,握手校验包括对控制终端进行验证;接收模块64握手校验结束后,接收控制终端发出的控制指令,控制指令包括发出控制指令的控制终端的验证信息;验证模块66根据验证信息对控制指令进行验证;控制模块68在控制指令验证通过的情况下,根据控制指令控制车辆动作的方式,通过将检测信号转化为数字信号,达到了根据检测信号的状态持续时间确定负载故障状态的持续时间的目的,从而实现了对负载的故障状态的持续时间进行有效检测的技术效果,进而解决了相关技术中握手校验失败时,车辆控制器不再接收任何控制指令,导致车辆不受控制的技术问题。

可选的,上述握手模块62包括:发送单元,用于向控制终端发出握手请求;接收单元,用于接收控制终端响应于握手请求发送的加密数据,其中,加密数据包括控制终端的验证信息;验证单元,用于验证验证信息是否正确。

根据本发明实施例的另一方面,还提供了一种存储介质,存储介质包括存储的程序,其中,在程序运行时控制存储介质所在设备执行上述中任意一项的方法。

根据本发明实施例的另一方面,还提供了一种处理器,处理器用于运行程序,其中,程序运行时执行上述中任意一项的方法。

上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。

在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。

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

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

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括:u盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1