用于升级车辆中既有软件的方法、装置、车辆和介质与流程

    专利查询2023-08-21  101



    1.本公开涉及计算机技术领域,特别涉及一种用于升级车辆中既有软件的方法、装置、车辆和介质。


    背景技术:

    2.随着社会的进步,汽车几乎成为每家每户所必须的交通工具,使得人们的生活越来越便捷。而且随着汽车领域内各种先进技术的发展,越来越智能的各种装置和功能被集成到汽车里,这些装置和功能通常会通过相应的ecu(electronic control unit,电子控制单元)来控制。
    3.ota技术(over the air technology,即空中系统升级技术或空中下载技术)的出现,使得汽车用户无需前往经销商或修理厂处,就能对汽车上相应的ecu进行升级刷新,因而能够使得用户具有较好的体验,且对于汽车开发商来说成本也较低,因此逐渐成为车载电子设备的软件升级的趋势。
    4.然而,新软件下载后,其运行表现难以预计,如果在未对新软件表现进行评估的情况对车辆的既有软件进行升级的话,将有可能导致车辆无法正常使用,甚至可能导致发生严重的交通事故。
    5.在此部分中描述的方法不一定是之前已经设想到或采用的方法。除非另有指明,否则不应假定此部分中描述的任何方法仅因其包括在此部分中就被认为是现有技术。类似地,除非另有指明,否则此部分中提及的问题不应认为在任何现有技术中已被公认。


    技术实现要素:

    6.根据本公开的一个方面,提供一种用于升级车辆中既有软件的方法,包括:获取更新包,所述更新包用于升级车辆中的既有软件和验证升级后的软件在车辆上的有效性;接收验证输入信号,所述验证输入信号包括新增功能验证输入信号和原有功能验证输入信号;基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果;根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件。
    7.根据本公开的另一个方面,提供一种用于升级车辆中软件的装置,包括:获取单元,被配置为获取更新包,所述更新包用于升级车辆中的既有软件和验证升级后的软件在车辆上的有效性;接收单元,被配置为接收验证输入信号,所述验证输入信号包括新增功能验证输入信号和原有功能验证输入信号;验证单元,被配置为基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果;升级单元,被配置为根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件。
    8.根据本公开的另一个方面,提供一种电子设备,包括:处理器,和存储程序的存储器,所述程序包括指令,所述指令在由所述处理器执行时使所述处理器执行本公开中所述的方法。
    9.根据本公开的另一个方面,提供一种车辆,包括:本公开中所述的装置或电子设备。
    10.根据本公开的另一个方面,提供一种存储程序的非暂态计算机可读存储介质,所述程序包括指令,所述指令在由一个或者多个处理器执行时,致使所述一个或者多个处理器执行本公开中所述的方法。
    11.根据本公开的一个或多个实施例,本公开提供的用于升级车辆中既有软件的方法、装置、车辆和介质,能够提高车辆软件升级的安全性。
    附图说明
    12.附图示例性地示出了实施例并且构成说明书的一部分,与说明书的文字描述一起用于讲解实施例的示例性实施方式。所示出的实施例仅出于例示的目的,并不限制权利要求的范围。在所有附图中,相同的附图标记指代类似但不一定相同的要素。
    13.图1是示出根据示例性实施例的用于升级车辆中既有软件的方法100的流程图;
    14.图2是示出根据示例性实施例的用于升级车辆中既有软件的装置200的结构框图;以及
    15.图3是根据本公开的示例性实施例的机动车辆的应用场景示意图。
    具体实施方式
    16.在本公开中,除非另有说明,否则使用术语“第一”、“第二”等来描述各种要素不意图限定这些要素的位置关系、时序关系或重要性关系,这种术语只是用于将一个元件与另一元件区分开。在一些示例中,第一要素和第二要素可以指向该要素的同一实例,而在某些情况下,基于上下文的描述,它们也可以指代不同实例。
    17.在本公开中对各种所述示例的描述中所使用的术语只是为了描述特定示例的目的,而并非旨在进行限制。除非上下文另外明确地表明,如果不特意限定要素的数量,则该要素可以是一个也可以是多个。此外,本公开中所使用的术语“和/或”涵盖所列出的项目中的任何一个以及全部可能的组合方式。
    18.在车辆软件升级过程中,原始设备制造商测试了他们的新软件后,会将新软件发布给专用用户(例如,目标车辆),新软件可以通过ota被下载到用户的车辆。
    19.对于大量的用户来说,每个用户的车辆之间可能存在差异,例如,车辆的型号不同导致车辆的硬件配置存在一定的差异,或者某些用户对车辆进行了改造导致改造后的车辆与其他出厂车辆存在一定的差异,又或者由于使用频率的不同导致车辆新旧的差异进而导致硬件配置上的差异等等,这会为通过ota技术进行既有软件的升级带来许多麻烦。
    20.并且,在通过一些专用的无线技术从云端下载软件的过程中,还需要保证数据传输的安全性,因此,需要对下载到车辆的升级软件进行车辆上有效性的验证,否则如果升级软件被其他黑客攻击,将其下载到车辆上并直接进行升级而不加验证的话,会带来很多安全问题。
    21.图1示出了根据本公开的一个实施例的用于升级车辆中既有软件的方法100的流程图。
    22.在步骤101处,获取更新包,所述更新包用于升级车辆中的既有软件和验证升级后的软件在车辆上的有效性。
    23.示例性地,更新包包括安装程序,安装程序能够修改一些系统配置以适应新版本的功能,比如注册com组件,修改注册表等。
    24.例如,通过http协议来检测是否有既有软件的新版本,具体地,把本地版本号发给服务器,服务器会返回一个配置文件以表明是否有既有软件的新版本,并且带有新版本的下载地址,更新程序按照url下载新版本的安装程序,然后执行这个安装程序。示例性地,随着更新包越来越大,更新下载和安装的时间也越来越长,造成用户长时间等待,因此可以采用后台下载后台更新的方式。
    25.示例性地,可以采用双目录更新方式,将更新包包括的既有软件的新版本复制到另一个目录,然后在该目录下更新这份新复制既有软件的新版本。示例性地,可以用版本号做目录名,既有软件的旧版本在另一个目录下运行不受影响。因此,更新包中包含的既有软件的新版本可以用于升级车辆中的既有软件,也可以在升级车辆中既有软件之前用来验证升级后的软件在车辆上的有效性。
    26.在步骤102处,接收验证输入信号,所述验证输入信号包括新增功能验证输入信号和原有功能验证输入信号。
    27.在对既有软件进行升级时,升级后的软件,往往只有一部分功能发生了变化,这些功能一般有其专用的输入信号和预期的输出信号,并且为了保证升级后的软件能够实现原有功能,还需要提供原有功能的输入信号和预期的输出信号。
    28.例如,当既有软件的新版本安装在车辆的ecu上之后,从can总线或flexray总线等总线系统中得到输入信号,如车辆速度、加速度等。
    29.在步骤103处,基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果。
    30.在步骤104处,根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件。
    31.基于图1所示出的用于升级车辆中既有软件的方法能够对升级后的软件进行验证,提高车辆软件升级的安全性。
    32.根据一些实施例,在步骤103处,所述基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,包括:基于所述更新包计算所述新增功能验证输入信号对应的新增功能验证输出信号,比较所述新增功能验证输出信号与预期验证输出信号以生成新增功能验证结果。
    33.示例性地,为了对发生变化的功能验证从而实现“车辆上验证”功能,则需要计算新增功能进行信号验证,具体地,对应于新增功能的验证输入信号,计算得到新增功能的验证输出信号,将得到的新增功能验证输出信号与预期的验证输出信号进行比较,可以得到对应的新增功能的验证结果。
    34.因此,通过验证新增功能是否达到预期,能够提升升级后的软件的有效性。
    35.根据一些实施例,在步骤103处,在生成新增功能的验证结果的过程中,包括:根据第一数量的新增功能验证输入信号中的第一新增功能验证输入信号计算第一新增功能验证输出信号;比较第一新增功能验证输出信号和对应于所述第一新增功能验证输入信号的预期输出信号,当第一新增功能验证输出信号和对应于所述第一新增功能验证输入信号的预期输出信号一致时,视为验证成功一次。
    36.示例性地,准备第一数量的新增功能验证输入信号,基于其中的第一新增功能验证输入信号得到对应的第一新增功能输出信号,并对该第一新增功能输出信号进行判断,如果其符合预期,则认定此次验证成功。
    37.通过对第一数量的新增功能输入信号的设置和选择,能够有针对性地提升升级后的软件的有效性。
    38.进一步地,根据一些实施例,在步骤103处,所述基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,包括:统计验证成功的次数,当验证成功累计次数超过阈值或连续验证成功次数超过阈值时,则新增功能验证结果为成功。
    39.示例性地,往往需要多次验证才能保证新增功能在车辆上能够有效地运行,例如,可以设置累计成功次数阈值,或连续成功次数阈值。
    40.示例性地,对前述验证成功的次数进行统计,例如,当第一数量为10000次时,设置累计成功次数阈值为9995次,即要求成功率超过万分之五,则认为新增功能的验证结果为成功。在其他可替换的实施例中,设置连续成功次数阈值为2000次,满足该条件时,则认为新增功能的验证结果为成功,上述数值仅为示例性说明,其并不构成对本公开的限定。
    41.通过设置累计成功次数阈值或连续成功次数阈值对升级后的软件进行验证能够提升验证的效率。
    42.为了更有效地理解前述方案,下面将结合acc(adaptive cruise control,自适应巡航控制)中的一个具体功能来描述新增功能的验证过程。
    43.例如,在升级软件中,只有一个功能发生了变化,我们以一个acc功能为例,假设既有软件的acc功能只能在车辆速度大于50km/h时来设置,升级软件的该acc功能可在车速大于30km/h时来设置。
    44.当升级软件安装在ecu后,升级后的软件的acc功能还会从can总线或flexray总线等总线系统中得到它们的输入信号,如车辆速度、加速度等。
    45.对于这个“车辆上验证”的功能,测试acc功能的条件,将被设置在车辆速度超过30公里,如果在一个安装有升级后的软件的车辆上,当车辆速度是每小时35公里时,将有一个新增功能验证的“成功计数器”,该成功计数器将会对验证的成功次数进行计数,且每验证成功一次,将由该计数器计数一次。
    46.示例性地,针对不同的功能会有不同的成功阈值,这是由于不同的功能有不同的危险级别,对于危险级别较高的功能,需要设置较高的成功阈值次数,对于危险级别较低的功能呢,需要设置相对较低的成功阈值次数,如此设置可以在保证验证效果的同时还能兼顾到验证效率。
    47.例如,acc的新功能的累计成功次数阈值或者连续成功次数阈值设置为100次,那么一旦成功计数器的数值超过100,则意味着具备这个新功能的升级软件可以取代既有软
    件。
    48.继续在步骤103处,根据一些实施例,所述基于所述原有功能验证输入信号判断原有功能是否与既有软件一致以生成原有功能验证结果,包括:基于所述更新包计算原有功能验证输入信号生成的升级软件原有功能验证输出信号,基于既有软件计算原有功能验证输入信号生成的既有软件原有功能输出信号,比较升级软件原有功能输出信号和既有软件原有功能输出信号以生成原有功能验证结果。
    49.示例性地,为了对没有发生变化的功能验证从而实现“车辆上验证”功能,则需要计算原有功能进行信号验证,具体地,对应于原有功能的验证输入信号,计算得到原有功能的验证输出信号,将得到的原有功能验证输出信号与预期的原有功能呢验证输出信号进行比较,可以得到对应的原有功能的验证结果。
    50.因此,可以实现对原有功能的验证,以避免升级后的软件引入新的不安全因素。
    51.进一步地,在步骤103处,所述基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果,包括:根据第二数量的原有功能验证输入信号中的第一原有功能验证输入信号计算第一原有功能验证输出信号;比较升级软件的第一原有功能验证输出信号和既有软件的第一原有功能输出信号,当升级软件的第一原有功能验证输出信号和既有软件的第一原有功能输出信号不一致时,视为验证失败一次。
    52.示例性地,准备第二数量的原有功能验证输入信号,基于其中的第一原有功能验证输入信号得到对应的第一原有功能输出信号,并对该第一原有功能输出信号进行判断,如果其不符合预期,则认定此次验证失败。
    53.通过对第二数量原有功能输入信号的设置和选择,能够有针对性地提升升级后软件的有效性。
    54.进一步地,在步骤103处,所述基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果,包括:统计验证失败的次数,当累计验证失败次数为零时,则原有功能验证结果为成功。
    55.示例性地,只要有一次原有功能的验证结果为失败,则认为升级后的软件无法实现原有功能,无法使用该升级软件对车辆进行升级。
    56.这是因为具有新功能的升级后的软件需要完成既有软件的原有功能,在具体地应用中,需要对升级后的软件和既有软件针对原有功能进行比较,从而保证它们的输出是否与既有软件对应的功能相同。
    57.其中,如果有一次升级后的软件产生的输出信号不是预期的,或者在所有的“车辆上验证”的过程中(收集100次成功的测试),但是只有一次原有功能中产生了与既有软件不同的输出,那么则认为原有功能验证结果为失败。
    58.示例性地,如果失败,在那个测试用例中,车辆中所有必要的信号将被收集并自动发送回生产厂商的服务器,将有工程师对其进行调试,直到工程师找出问题,并对更新包作出新一步的修改,然后再将修改后的更新包再次发布到这个专用用户的车辆,以进行下一步的验证。
    59.通过对升级后的软件的原有功能进行验证能够提升升级后的软件的有效性,并且通过该验证步骤能够知道工作人员进一步修改更新包,以使其使用特定的车辆,提升更新
    包的适用范围。
    60.根据本公开的一些实施方式,所述更新包中所包含的升级后的软件与车辆中的既有软件能够同时运行。
    61.示例性地,升级软件下载到车辆ecu后,不会覆盖旧版本的软件,车辆仍将按照旧版本软件的预期运行。直到经过验证后,系统发现对升级后的软件新版本像预期的那样工作,才认为更新后的软件具备了替换旧版本软件的基础。
    62.由于升级后的软件和车辆中的既有软件能够同时运行,因此,验证软件的同时不影响既有软件的运行,提升了验证过程的兼容性。
    63.进一步地,所述根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件,包括:当新增功能验证结果和所述原有功能验证结果均为验证成功时,则基于所述更新包升级车辆中的既有软件。
    64.一旦新增功能验证结果和原有功能结果均为成功,则表明更新包中所包含的升级软件是符合预期的,在车辆上运行表现符合预期,通过全面验证,能够提升升级后的软件的稳定性。
    65.根据本公开的一些实施方式,所述根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件,包括:当新增功能验证结果和所述原有功能验证结果任一项不为验证成功时,则不升级车辆中的既有软件。
    66.一旦新增功能验证结果和原有功能结果有一项不为成功,则表明更新包中所包含的升级软件是不符合预期的,在车辆上运行表现不符合预期,无法通过验证,避免不安全的软件升级而导致的不良后果。
    67.由于升级后的软件的验证是在车辆上进行的,那么其验证结果与车辆的客观情况例如,车辆的型号,车辆被修改的硬件系统等等紧密连接,其得到的验证结果是针对具体车辆而得到的,能够充分保证升级后的软件在特定车辆上的性能,大幅提升升级后的软件的有效性和安全性。
    68.根据本公开的一些实施方式,还包括:在基于所述更新包升级车辆中的既有软件之前,接收用户指示,根据用户指示基于所述更新包升级车辆中的既有软件。
    69.示例性地,在真正替换既有软件之前,为了提升人机交互体验,可以在适当的时间弹出一条消息,例如在下一个引擎启动时,显示“汽车中有一个经过验证的新版本软件,您要更新吗?”,然后再根据用户的指示消息,选择继续更新或者忽略本次更新。
    70.图2是示出根据示例性实施例的用于升级车辆中既有软件的装置200的结构框图。如图2所示,提供一种用于升级车辆中既有软件的装置200,包括:
    71.获取单元210,被配置为获取更新包,所述更新包用于升级车辆中的既有软件和验证升级后的软件在车辆上的有效性;
    72.接收单元220,被配置为接收验证输入信号,所述验证输入信号包括新增功能验证输入信号和原有功能验证输入信号;
    73.验证单元230,被配置为基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果;
    74.升级单元240,被配置为根据所述新增功能验证结果和所述原有功能验证结果,判
    断是否基于所述更新包升级车辆中的既有软件。
    75.基于图2所示出的用于升级车辆中既有软件的装置200,其能够对升级后的软件进行验证,提高车辆软件升级的安全性。
    76.另外,虽然上面参考特定模块讨论了特定功能,但是应当注意,本文讨论的各个模块的功能可以分为多个模块,和/或多个模块的至少一些功能可以组合成单个模块。本文讨论的特定模块执行动作包括该特定模块本身执行该动作,或者替换地该特定模块调用或以其他方式访问执行该动作的另一个组件或模块(或结合该特定模块一起执行该动作)。因此,执行动作的特定模块可以包括执行动作的该特定模块本身和/或该特定模块调用或以其他方式访问的、执行动作的另一模块。
    77.更一般地,本文可以在软件硬件元件或程序模块的一般上下文中描述各种技术。上面关于图2描述的各个模块可以在硬件中或在结合软件和/或固件的硬件中实现。例如,这些模块可以被实现为计算机程序代码/指令,该计算机程序代码/指令被配置为在一个或多个处理器中执行并存储在计算机可读存储介质中。可替换地,这些模块可以被实现为硬件逻辑/电路。例如,在一些实施例中,获取单元210、接收单元220、验证单元230和升级单元240中的一个或多个可以一起被实现在片上系统(soc)中。soc可以包括集成电路芯片(其包括处理器(例如,中央处理单元(cpu)、微控制器、微处理器、数字信号处理器(dsp)等)、存储器、一个或多个通信接口、和/或其他电路中的一个或多个部件),并且可以可选地执行所接收的程序代码和/或包括嵌入式固件以执行功能。
    78.根据本公开的一个方面,提供一种电子设备。电子设备包括:处理器,和存储程序的存储器,所述程序包括指令,所述指令在由所述处理器执行时使所述处理器执行前述用于升级车辆中既有软件的方法。
    79.根据本公开的一个方面,提供车辆。车辆包括前述用于升级车辆中软件的装置或电子设备。
    80.根据本公开的一个方面,提供存储介质。例如,存储介质为一种存储程序的非暂态计算机可读存储介质,程序包括指令,指令在由一个或者多个处理器执行时,致使所述一个或者多个处理器执行前述用于升级车辆中既有软件的方法。图3示出了包括机动车辆2010及用于该机动车辆2010的通信和控制系统的一个应用场景示意图。要注意的是,图3所示出的车辆2010的结构和功能仅是一个示例,根据具体的实现形式,本公开的车辆可以包括图3所示车辆2010的结构和功能中的一种或多种。根据一些实施例,车辆2010可以是上面关于图1描述的用于升级车辆中既有软件中所涉及的车辆。
    81.机动车辆2010可以包括传感器2110用于感知周围环境。传感器2110可以包括下列传感器中的一个或多个:超声波传感器、毫米波雷达、激光雷达(lidar)、视觉摄像头以及红外摄像头。不同的传感器可以提供不同的检测精度和范围。超声波传感器可以安装在车辆的四周,用于利用超声波方向性强等特点来测量车外物体距车辆的距离。毫米波雷达可以安装在车辆的前方、后方或其他位置,用于利用电磁波的特性测量车外物体距车辆的距离。激光雷达可以安装在车辆的前方、后方或其他位置,用于检测物体边缘、形状信息,从而进行物体识别和追踪。由于多普勒效应,雷达装置还可以测量车辆与移动物体的速度变化。摄像头可以安装在车辆的前方、后方或其他位置。视觉摄像头可以实时捕获车辆内外的情况并呈现给驾驶员和/或乘客。此外,通过对视觉摄像头捕获的画面进行分析,可以获取诸如
    交通信号灯指示、交叉路口情况、其他车辆运行状态等信息。红外摄像头可以在夜视情况下捕捉物体。
    82.机动车辆2010还可以包括输出设备2120。输出设备2120例如包括显示器和扬声器等,以呈现各种输出或者指令。此外,显示器可以实现为触摸屏,从而还可以不同的方式检测输入。可以在触摸屏上呈现用户图形界面,以使用户能够访问控制相应的控件。
    83.机动车辆2010还可以包括一个或多个控制器2130。控制器2130可以包括与各种类型的计算机可读存储装置或介质通信的处理器,例如中央处理单元(cpu)或图形处理单元(gpu),或者其他的专用处理器等。计算机可读存储装置或介质可以包括任何非暂时性存储设备,非暂时性存储设备可以是非暂时性的并且可以实现数据存储的任何存储设备,并且可以包括但不限于磁盘驱动器、光学存储设备、固态存储器、软盘、柔性盘、硬盘、磁带或任何其他磁介质,光盘或任何其他光学介质、只读存储器(rom)、随机存取存储器(ram)、高速缓冲存储器和/或任何其他存储器芯片或盒、和/或计算机可从其读取数据、指令和/或代码的任何其他介质。计算机可读存储装置或介质中的一些数据表示由控制器2130用于控制车辆的可执行指令。控制器2130可以包括用于自动控制车辆中的各种致动器的自动驾驶系统。自动驾驶系统被配置为经由多个致动器响应来自多个传感器2110或者其他输入设备的输入而控制机动车辆2010的动力总成、转向系统以及制动系统等以分别控制加速、转向和制动,而无需人为干预或者有限的人为干预。控制器2130的部分处理功能可以通过云计算实现。例如,可以使用车载处理器执行某一些处理,而同时可以利用云端的计算资源执行其他一些处理。根据一些实施例,处理器可以被配置以执行结合图1所描述的方法。处理器及其相关联的计算机可读存储装置为上面图2的装置200的一个示例。与处理器相关联的计算机可读存储装置可以为上面描述的非暂态计算机可读存储介质的一个示例。处理器及其相关联的计算机可读存储装置可以构成为电子设备的一个示例。
    84.机动车辆2010还包括通信装置2140。通信装置2140包括能够从卫星2012接收卫星定位信号并且基于这些信号产生坐标的卫星定位模块。通信装置2140还包括与移动通信网络2013进行通信的模块,移动通信网络可以实施任何适合的通信技术,例如gsm/gprs、cdma、lte等当前或正在不断发展的无线通信技术(例如5g技术)。通信装置2140还可以具有车联网或车联万物(vehicle-to-everything,v2x)模块,被配置用于实现例如与其它车辆2011进行车对车(vehicle-to-vehicle,v2v)通信和与基础设施进行车辆到基础设施(vehicle-to-infrastructure,v2i)通信的车与外界的通信。此外,通信装置2140还可以具有被配置为例如通过使用ieee802.11标准的无线局域网或蓝牙与用户终端2014(包括但不限于智能手机、平板电脑或诸如手表等可佩戴装置)进行通信的模块。利用通信装置2140,机动车辆2010可以经由无线通信系统接入在线服务器2015或者云端服务器2016,该在线服务器或云端服务器被配置用于为机动车辆提供相应的数据处理、数据存储和数据传输等服务。
    85.此外,机动车辆2010还包括图3中未示出的用于实现机动车驾驶功能的动力总成、转向系统以及制动系统等。
    86.虽然已经参照附图描述了本公开的实施例或示例,但应理解,上述的方法、系统和设备仅仅是示例性的实施例或示例,本发明的范围并不由这些实施例或示例限制,而是仅由授权后的权利要求书及其等同范围来限定。实施例或示例中的各种要素可以被省略或者
    可由其等同要素替代。此外,可以通过不同于本公开中描述的次序来执行各步骤。进一步地,可以以各种方式组合实施例或示例中的各种要素。重要的是随着技术的演进,在此描述的很多要素可以由本公开之后出现的等同要素进行替换。

    技术特征:
    1.一种用于升级车辆中既有软件的方法,包括:获取更新包,所述更新包用于升级车辆中的既有软件和验证升级后的软件在车辆上的有效性;接收验证输入信号,所述验证输入信号包括新增功能验证输入信号和原有功能验证输入信号;基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果;根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件。2.如权利要求1所述的方法,其中,所述基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,包括:基于所述更新包计算所述新增功能验证输入信号对应的新增功能验证输出信号,比较所述新增功能验证输出信号与预期验证输出信号以生成新增功能验证结果。3.如权利要求2所述的方法,其中,所述基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,包括:根据第一数量的新增功能验证输入信号中的第一新增功能验证输入信号计算第一新增功能验证输出信号;比较第一新增功能验证输出信号和对应于所述第一新增功能验证输入信号的预期输出信号,当第一新增功能验证输出信号和对应于所述第一新增功能验证输入信号的预期输出信号一致时,视为验证成功一次。4.如权利要求3所述的方法,其中,所述基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,包括:统计验证成功的次数,当验证成功累计次数超过阈值或连续验证成功次数超过阈值时,则新增功能验证结果为成功。5.如权利要求1所述的方法,其中,所述基于所述原有功能验证输入信号判断原有功能是否与既有软件一致以生成原有功能验证结果,包括:基于所述更新包计算原有功能验证输入信号生成的升级软件原有功能验证输出信号,基于既有软件计算原有功能验证输入信号生成的既有软件原有功能输出信号,比较升级软件原有功能输出信号和既有软件原有功能输出信号以生成原有功能验证结果。6.如权利要求5所述的方法,其中,所述基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果,包括:根据第二数量的原有功能验证输入信号中的第一原有功能验证输入信号计算第一原有功能验证输出信号;
    比较升级软件的第一原有功能验证输出信号和既有软件的第一原有功能输出信号,当升级软件的第一原有功能验证输出信号和既有软件的第一原有功能输出信号不一致时,视为验证失败一次。7.如权利要求6所述的方法,其中,所述基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果,包括:统计验证失败的次数,当累计验证失败次数为零时,则原有功能验证结果为成功。8.如权利要求1至7任一项所述的方法,其中,所述更新包中所包含的升级后的软件与车辆中的既有软件能够同时运行。9.如权利要求8所述的方法,其中,所述根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件,包括:当新增功能验证结果和所述原有功能验证结果均为验证成功时,则基于所述更新包升级车辆中的既有软件。10.如权利要求9所述的方法,还包括:在基于所述更新包升级车辆中的既有软件之前,接收用户指示,根据用户指示基于所述更新包升级车辆中的既有软件。11.如权利要求8所述的方法,其中,所述根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件,包括:当新增功能验证结果和所述原有功能验证结果任一项不为验证成功时,则不升级车辆中的既有软件。12.一种用于升级车辆中既有软件的装置,包括:获取单元,被配置为获取更新包,所述更新包用于升级车辆中的既有软件和验证升级后的软件在车辆上的有效性;接收单元,被配置为接收验证输入信号,所述验证输入信号包括新增功能验证输入信号和原有功能验证输入信号;验证单元,被配置为基于所述新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,基于所述原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果;升级单元,被配置为根据所述新增功能验证结果和所述原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件。13.一种电子设备,包括:处理器,和存储程序的存储器,所述程序包括指令,所述指令在由所述处理器执行时使所述处理器执行根据权利要求1至11中任一项所述的方法。14.一种车辆,包括:如权利要求12所述的装置或如权利要求13所述的电子设备。15.一种存储程序的非暂态计算机可读存储介质,所述程序包括指令,所述指令在由一
    个或者多个处理器执行时,致使所述一个或者多个处理器执行根据权利要求1至11中任一项所述的方法。

    技术总结
    提供一种用于升级车辆中既有软件的方法、装置、车辆和介质。用于升级车辆中既有软件的方法包括:获取更新包,更新包用于升级车辆中的既有软件和验证升级后的软件在车辆上的有效性;接收验证输入信号,验证输入信号包括新增功能验证输入信号和原有功能验证输入信号;基于新增功能验证输入信号判断升级后的软件的新增功能是否与预期一致以生成新增功能验证结果,基于原有功能验证输入信号判断升级后的软件的原有功能是否与既有软件一致以生成原有功能验证结果;根据新增功能验证结果和原有功能验证结果,判断是否基于所述更新包升级车辆中的既有软件。车辆中的既有软件。车辆中的既有软件。


    技术研发人员:杨岳 唐帅 曲彤
    受保护的技术使用者:奥迪股份公司
    技术研发日:2020.11.23
    技术公布日:2022/5/25
    转载请注明原文地址:https://tc.8miu.com/read-18262.html

    最新回复(0)