CN116800805A - 一种备车方法、装置及车辆 - Google Patents

Abstract

本申请实施例公开了一种备车方法、装置及车辆，其中，所述方法包括：响应于用户发出的备车请求，确定用车时刻；基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

Description

一种备车方法、装置及车辆

技术领域

本申请涉及但不限于汽车领域，尤其涉及一种备车方法、装置及车辆。

背景技术

人们对于车辆的舒适性要求越来越高，同时也期望可以获得更智能的驾乘体验。比如在出行前提前对汽车进行备车，使用户在上车时即可使用最佳状态的汽车。随着汽车智能化的推进，越来越多的汽车设有备车模式。但是现有的备车模式仅能实现对动力电池进行加热、开启空调等，而不能根据用户的喜好和用车目的，自动优化备车逻辑，给用户提供更优质的备车服务。

发明内容

有鉴于此，本申请实施例至少提供一种备车方法、装置及车辆。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种备车方法，包括：响应于用户发出的备车请求，确定用车时刻；基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

第二方面，本申请实施例提供一种备车装置，包括：

第一确定模块，用于响应于用户发出的备车请求，确定用车时刻；

第二确定模块，用于基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；

第三确定模块，用于确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；

调整模块，用于在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；

控制模块，用于基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

第三方面，本申请实施例提供一种车辆，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的部分或全部步骤。

本申请实施例中，首先，响应于用户发出的备车请求，确定用车时刻；其次，基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；再次，确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；然后，在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；最后，基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

可以看出，基于用车时刻，通过备车计划表确定初始备车参数集合，这样，通过初始备车参数集合中的备车参数可以生成相应的初始备车逻辑，以为车主提供备车服务；然后，比较车辆的剩余电量与初始备车参数集合中的备车参数的备车耗电量和用车耗电量的大小，以确定是否需要通过调整初始备车参数集合来得到目标备车参数集合，这样，结合车辆剩余电量与备车参数总耗电量，对备车参数做相应的调整，可以优化备车逻辑，得到目标备车参数集合，进而根据目标备车参数集合，控制车辆执行所述备车操作，以为车主提供更优质的备车服务。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本公开的技术方案。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。

图1为本申请实施例提供的一种备车方法的实现流程示意图；

图2为本申请实施例提供的一种备车计划表生成方法的实现流程示意图；

图3为本申请实施例提供的一种步骤S105的实现流程示意图；

图4为本申请实施例提供的一种车端和云端服务系统的架构图；

图5为本申请实施例提供的一种备车装置的组成结构示意图；

图6为本申请实施例提供的一种车辆的硬件实体示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和实施例对本申请的技术方案进一步详细阐述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请的目的，不是旨在限制本申请。

图1为本申请实施例提供的一种备车方法的实现流程示意图，如图1所示，该方法包括如下步骤S101至步骤S105：

步骤S101：响应于用户发出的备车请求，确定用车时刻；

这里，用户可以包括车主、驾驶员或者乘客等。用车时刻为备车结束后，用户实际开始用车的时间。

在一些实施例中，步骤S101的实施可以包括：当用户在家里、办公室或者在其他地方有用车需求时，则用户可以通过手机向云端发送备车请求，以确定用车时刻。

步骤S102：基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；

这里，备车计划表可以是未来一周的备车计划、十天的备车计划或者半个月的备车计划等，本申请实施例对备车计划的时间不做限制。在实施时，备车计划表是云端根据用户的用车模型统计出来的。

在一些实施例中，初始备车参数集合可以包括：目标温度、目标亮度、方向盘位置、座椅位置、香氛种类、香氛的开启或关闭、座椅加热的开启或关闭、消毒的开启或关闭，车内外灯光的开启或关闭等中的任意几项或全部。

在初始备车参数集合包括目标温度和/或目标亮度的情况下，步骤S102“所述基于所述用车时刻，通过备车计划表确定初始备车参数集合”的实施可以包括：基于所述用车时刻和当前的环境温度，通过备车计划表确定所述目标温度；和/或，基于所述用车时刻和当前的环境亮度，通过备车计划表确定所述目标亮度。

这里，当前的环境温度可以通过云端直接获取当前的天气来得到；当前的环境亮度可以通过车上的阳光雨量传感器直接得到，也可以通过云端获取的当前的天气来间接得到。目标温度指的是：用户上车时，车内的温度。目标亮度可以通过车内外灯光的开启或关闭来实现。

针对目标温度，实施时，在用户用车之前，基于用户用车时刻和当前的环境温度，通过备车计划表将车内的温度调整至目标温度。例如：若环境温度是18摄氏度(℃)，用户感觉的舒适温度为22℃，则目标温度为22℃；若环境温度是30℃，用户感觉的舒适温度为24℃，则目标温度为24℃。

针对目标亮度，实施时，根据用户对车内外灯光上车前、用车时和下车后一段时间的需求，并基于用车时刻和当前的环境亮度，通过备车计划表确定用户对车内外灯光上车前、用车时和下车后灯光开关状态。例如：如果用户在晚上下车后，需要步行一段路程才能到家，而该路段夜晚没有路灯或路灯的亮度不够，这时，车辆的大灯延时关闭，给用户提供照亮回家的功能。

在一些实施例中，步骤S102的实施可以包括：当云端获取足够多的用户的历史备车数据时，云端通过机器学习的方法构建用户的用车模型，以从用户的用车模型中得到用户的备车信息。例如：每周几的什么时间从哪里到哪里、每次的耗电量、不同环境温度下的舒适温度，不同环境亮度对车内外灯光上车前、用车时和下车后一段时间的需求。

在一些实施例中，参考图2，步骤S102“备车计划表”的生成方法可以包括如下步骤S1021至步骤S1024：

步骤S1021：响应于所述用户发出的备车请求集合中的每一备车请求，确定用车的起始位置和起始时刻；

这里，用车的起始位置指的是：备车完成后，用户实际开始用车时车辆的具体位置；用车的起始时刻指的是：备车完成后，用户实际开始用车的起始时间。在实施时，用户每一次有用车需求时，用户通过手机向云端发送每一备车请求，以确定用车的起始位置和起始时刻。

在一些实施例中，步骤S1021的实施可以包括：当云端没有获取足够的用户数据时，用户需要通过手动点击备车开关，以开启备车功能。在用户开启备车功能之后，云端的数据中心将记录当前车辆的位置、环境温度。

步骤S1022：获取所述用户针对预设备车参数集合中的每一预设备车参数的设置值；

这里，每一预设备车参数的设置值指的是：用户可以根据自己的喜好和本次用车目的在手机上对备车参数设定设置值。通过用户对备车参数设定设置值，从而得到每一预设备车参数的设置值，进而得到预设备车参数集合。

在一些实施例中，步骤S1022的实施可以包括：在用户对备车参数设定设置值完成之后，云端会获取并存储用户针对预设备车参数集合中的每一预设备车参数的设置值。

步骤S1023：确定用车的结束位置和结束时刻；

这里，用车的结束位置指的是：用户实际结束本次用车时车辆的具体位置；用车的结束时刻指的是：用户实际结束本次用车的结束时间。

步骤S1024：针对所述每一备车请求，基于所述起始位置、所述起始时刻、所述设置值、所述结束位置和所述结束时刻，通过机器学习的方法生成所述备车计划表。

通过获取每一备车请求对应的起始位置、起始时刻、设置值、结束位置和结束时刻，利用机器学习的方法，可以学习到用户的备车习惯，从而得到备车计划表。

在一些实施例中，若预设备车参数中包括车外灯光的开启，且车外灯光的开启用于提醒用户车辆的位置的情况下，还可以在用户用车之前，确定用户是否寻车及寻车时车辆与用户之间的距离，进而得出在用户与车辆之间的距离达到一定值的情况下，设置车外灯光开启。本申请实施例对提醒用户车辆的位置的方式不做限定，在用户采用其他方式提醒车辆位置的情况下，也可以在用户与车辆之间的距离达到一定值的情况下，执行其他提醒方式，以使生成的备车计划表中包括寻车的提醒方式。

步骤S103：确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；

这里，车辆的剩余电量指的是：车辆备车之前的电池电量。备车耗电量可以通过用户开启备车后和用户上车后，云端数据中心记录车辆的电池电量得到；用车耗电量可以通过用户上车后和用户结束本次用车后，云端数据中心记录车辆的电池电量得到，该方法计算得到的电池电量为实际耗电量。

在一些实施例中，还可以获取备车和用车的时长，以及执行备车参数对应设备的功率，计算理论耗电量，通过对比理论耗电量和上述实际耗电量，来对备车和用车耗电量进行调整，以得到更加准确的耗电量，具体调整耗电量的方法可参见相关技术。

在一些实施例中，为了使得用户到达车上时，备车参数已经达到目标值(例如已经达到目标温度)，需要提前确定车辆的剩余电量和总耗电量，使得在剩余电量满足总耗电量的情况下，有足够的时间执行备车参数。

在一些实施例中，提前的时间需要大于等于备车参数达到目标值的时间。而备车参数执行完成时间与环境温度和备车参数有关，例如：车辆所处的环境温度是10℃，要让车内温度达到20℃，与车辆所处的环境温度是-10℃，要让车内温度达到20℃所需要的备车时间是不同的。因此，可以通过备车参数和环境温来确定提前确定车辆的剩余电量和总耗电量的时间。

步骤S104：在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；

在实施时，若车辆的剩余电量小于备车耗电量和用车耗电量时，用户可以调整初始备车参数集合中的备车参数的设置值，得到目标备车参数集合，以使目标备车参数集合中的目标备车参数的备车耗电量和用车耗电量小于或等于车辆的剩余电量。

在一些实施例中，步骤S104“所述在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合”的实施可以包括：在所述剩余电量不满足所述总耗电量的情况下，基于所述初始备车参数集合中备车参数的优先级和可降低幅度，调整所述初始备车参数集合中的备车参数，至所述剩余电量满足调整后的备车参数对应的所述总耗电量，得到所述目标备车参数集合。

这里，备车参数的优先级可以为座椅加热开关、方向盘加热开关、空调最高，消毒开关、香氛的种类和开关稍低，灯光开关、座椅的位置、方向盘的位置最低。本申请实施例对备车参数的优先级不做限制。备车参数的可降低幅度可以为空调的最高温度为30℃，空调的最低温度为20℃；座椅的位置可以为90度(°)到135°等。在实施时，若车辆的剩余电量小于总耗电量，可以将空调的设置值从27℃调整为25℃，确定调整后的备车耗电量和用车耗电量；若调整后的备车耗电量与用车耗电量之和小于或等于总耗电量，将调整后的备车参数确定为目标备车参数，以得到目标备车集合。

步骤S105：基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

在一些实施例中，参考图3，步骤S105“基于所述目标备车参数集合，控制所述车辆执行所述备车操作”的实施可以包括如下步骤S1051和步骤S1052：

步骤S1051：获取基于所述目标备车参数集合生成的备车脚本；

这里，云端根据目标备车参数集合，生成相应的备车脚本。备车脚本中包含备车执行的逻辑。在实施时，若根据备车参数的优先级和可降低幅度，调整所述初始备车参数集合中的备车参数，至剩余电量满足调整后的备车参数对应的所述总耗电量，这时，备车脚本中可以增加用户上车后提醒用户调整备车参数的降低原因。

步骤S1052：基于所述备车脚本，控制所述车辆执行所述备车操作。

这里，云端将生成的备车脚本通过车端的脚本管理接口发送给车端，车端的脚本调度模块调度车辆的控制器执行相应的备车逻辑，以控制车辆执行备车操作。

本申请实施例中，首先，响应于用户发出的备车请求，确定用车时刻；其次，基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；再次，确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；然后，在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；最后，基于所述目标备车参数集合，控制所述车辆执行所述备车操作。可以看出，基于用车时刻，通过备车计划表确定初始备车参数集合，这样，初始备车参数集合中的备车参数可以为车主提供备车服务；然后，比较车辆的剩余电量与初始备车参数集合中的备车参数的备车耗电量和用车耗电量的大小，以确定是否需要通过调整初始备车参数集合来得到目标备车参数集合，这样，结合车辆剩余电量与备车参数总耗电量的情况，对备车参数做相应的调整，可以实现优化备车逻辑，得到目标备车参数集合的功能，进而根据目标备车参数集合，控制车辆执行所述备车操作，以为车主提供更优质的备车服务。

在一些实施例中，所述方法还包括：在所述剩余电量满足所述总耗电量的情况下，将所述初始备车参数集合确定为所述目标备车参数集合。

这里，若车辆的剩余电量大于或等于备车耗电量和用车耗电量，则用户不需要对初始备车参数集合中的备车参数进行调整，而是直接将初始备车参数集合确定为目标备车参数集合。

在一些实施例中，所述方法还可以包括如下步骤S401和步骤S402：

步骤S401：在所述剩余电量不能满足调整后的备车参数对应的总耗电量的情况下，输出第一提示信息，其中，所述第一提示信息用于提示用户电量不足不建议备车；

这里，若调整后的备车参数的备车耗电量和用车耗电量大于车辆的剩余电量，则云端向用户发送第一提示信息，以提醒用户电量不足不建议备车。

步骤S402：在确定所述剩余电量不满足所述用车耗电量情况下，对所述车辆进行充电。

这里，若用户本次出行前不选择备车，且车辆的剩余电量小于用车耗电量时，则云端向用户发送用于提醒用户对车辆进行充电的消息，用于对车辆进行充电，以避免用户在用车过程中车辆突然出现没有电量的情况，防止用户用车过程中安全事故的发生。

在一些实施例中，所述方法还包括如下步骤S501至步骤S504：

步骤S501：在所述剩余电量不满足所述用车耗电量的情况下，获取当前时刻；

这里，当前时刻指的是：用户通过手机向云端发送备车请求的时间。

步骤S502：基于所述当前时刻和所述用车时刻，确定可充电时长；

这里，通过用户开始对车辆进行充电的时间和用户实际开始用车的时间，可以确定本次车辆的充电时长。

步骤S503：确定利用所述可充电时长充电后的电量是否满足所述用车耗电量；

这里，通过云端对本次车辆充电后的电量是否满足用车耗电量进行判断。

步骤S504：在所述充电后的电量不满足所述用车耗电量的情况下，输出第二提示信息，其中，所述第二提示信息用于提示用户充电后不能满足用车需求。

这里，若本次车辆充电后的电量小于用车耗电量，则云端向用户发送第二提示信息，用于提醒用户本次车辆充电后的电量不能满足用车需求，以供用户用户选择是否需要对车辆进行充电。

基于现有技术不能根据用户的喜好和用车目的，自动优化备车逻辑，给用户提供更优质的备车服务，本申请实施例提供了一种备车方法，包括：

一键备车的主要作用是在用户用车前让车辆处于最佳状态。一键备车的具体实施过程是：初期根据初始备车逻辑执行备车功能，同时构建车主行为模型和车辆行驶大数据(即上述用户的历史备车数据)，基于大数据和机器学习，通过一段时间的建模和学习后，不断的自动优化备车逻辑，以为车主提供更优质的备车服务。

为了实施上述方案，如图4左图所示，车端除了传统的传感器和执行器以外，增加了脚本管理接口，用于云端调用接口管理下发脚本(即上述备车脚本)(例如：备车执行的逻辑脚本)，触发脚本，删除脚本；还增加了脚本调度模块，用于在合适的时间和状态执行脚本。

如图4右图所示，云端服务系统分为数据中心和管理中心两部分，数据中心主要用于获取和存储车辆和用户的数据(包括上述用户的历史备车数据)，管理中心主要用于执行备车逻辑的条件判断部分和向车端下发脚本(即上述备车脚本)、触发脚本、删除车端脚本。

本申请实施例提供另一种备车方法，该方法包括如下步骤711至步骤715：

步骤711：生成初始备车逻辑。

车辆初始内置备车逻辑，备车设置变量(即上述预设备车参数)包含最低电量，目标温度，座椅加热开关，香氛开关和种类，消毒开关，灯光开关(即上述灯光开关状态)，屏幕亮度，最长备车时间，方向盘位置，方向盘加热开关。用户可以根据自己的喜好和本次用车目的，在手机上设定这些备车设置变量，云端服务系统会存储设定值，并根据设定值来推送到车辆执行备车逻辑。

步骤712：生成智能备车逻辑。

用户开启备车后，云端数据中心记录当前车辆位置(即上述起始位置)、环境温度和电池电量，用户上车后，云端数据中心记录用户实际用车时间(即上述起始时刻)、用户上车后对上述备车设置变量的调整值(即上述预设备车参数的设置值)和电池电量，用户结束本次用车后，云端数据中心记录当前车辆位置(即上述结束位置)、电池电量。

用户每次出行，云端数据中心均会记录出行时间(即上述起始时刻)、结束时间(即上述结束时刻)、起点(即上述起始位置)、终点(即上述结束位置)和用户上车后对各备车设置变量的调整值和电池电量。

在用户开启智能备车后，执行下述步骤713或步骤714：

步骤713：当没有足够的用户数据(即上述用户的历史备车数据)支撑时，用户仍旧需要手动点击备车开关，云端根据当前车辆位置的环境温度推送空调、方向盘加热开关、座椅加热开关的设置项给用户，由用户确认下发车辆。

步骤714：当云端获取到足够的用户数据，通过机器学习方法构建出用户的用车模型，如每周几的什么时间从哪里到哪里和每次的耗电量，不同环境温度下的舒适温度，不同环境亮度对车内外灯光上车前，用车时和下车后一段时间的需求，不同地点用车前是否需要寻车等。用户不需要点击备车开关，云端管理中心会根据用户用车模型和当前车辆所在地区的天气预报，排出一周的备车计划表。

每次根据计划表执行备车前(该时间会根据备车具体执行目标(即上述备车参数)和当前温度(即上述环境温度)反推出所需的备车时间)或出行前2小时，查询车辆电量是否足以支撑本次备车计划和用户用车计划，若电量不足以支撑本次备车计划加用户用车计划的耗电量，则根据各目标的优先级和降低允许幅度(即上述备车参数的优先级和可降低幅度)降低备车目标，降低目标预估可达成，则根据本次备车计划生成备车脚本，脚本中增加用户上车后提醒用户目标降低原因，并向通过调用车辆端的脚本管理接口下发备车脚本，脚本调度模块会根据备车脚本调度车辆控制器执行相应的备车逻辑。若不可达成则不备车，在用户主动选择备车功能时提醒用户电量不足不建议备车；若电量不足以支撑用户用车计划，则立刻提醒用户及时充电；若电量可以支撑备车计划和用户用车计划，则根据本次备车计划生成备车脚本，并向通过调用车辆端的脚本管理接口下发备车脚本，脚本调度模块会根据备车脚本调度车辆控制器执行相应的备车逻辑。

步骤715：删除用户数据。

经过安全认证，用户可以完全删除云端数据中心存储的私人数据和用户模型。

基于前述的实施例，本申请实施例提供一种备车装置，该装置包括所包括的各模块、各模块所包括的各子模块、各子模块所包括的各单元以及各单元所包括的各子单元，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(Central Processing Unit，CPU)、微处理器(Microprocessor Unit，MPU)、数字信号处理器(Digital Signal Processor，DSP)或现场可编程门阵列(Field Programmable Gate Array，FPGA)等。

图5为本申请实施例提供的一种备车装置的组成结构示意图，如图5所示，备车装置500包括：第一确定模块510、第二确定模块520、第三确定模块530、调整模块540和控制模块550，其中：

第一确定模块510，用于响应于用户发出的备车请求，确定用车时刻；

第二确定模块520，用于基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；

第三确定模块530，用于确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；

调整模块540，用于在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；

控制模块550，用于基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

在一些实施例中，备车装置500还包括：

第四确定模块，用于响应于所述用户发出的备车请求集合中的每一备车请求，确定用车的起始位置和起始时刻；

第一获取模块，用于获取所述用户针对预设备车参数集合中的每一预设备车参数的设置值；

第五确定模块，用于确定用车的结束位置和结束时刻；

生成模块，用于针对所述每一备车请求，基于所述起始位置、所述起始时刻、所述设置值、所述结束位置和所述结束时刻，通过机器学习的方法生成所述备车计划表。

在一些实施例中，所述初始备车参数集合包括目标温度和/或目标亮度，第二确定模块520：还用于基于所述用车时刻和当前的环境温度，通过备车计划表确定所述目标温度；和/或，基于所述用车时刻和当前的环境亮度，通过备车计划表确定所述目标亮度。

在一些实施例中，备车装置500还包括：

第六确定模块，用于在所述剩余电量满足所述总耗电量的情况下，将所述初始备车参数集合确定为所述目标备车参数集合。

在一些实施例中，调整模块540，还用于在所述剩余电量不满足所述总耗电量的情况下，基于所述初始备车参数集合中备车参数的优先级和可降低幅度，调整所述初始备车参数集合中的备车参数，至所述剩余电量满足调整后的备车参数对应的所述总耗电量，得到所述目标备车参数集合。

在一些实施例中，备车装置500还包括：

第一输出模块，用于在所述剩余电量不能满足调整后的备车参数对应的总耗电量的情况下，输出第一提示信息，其中，所述第一提示信息用于提示用户电量不足不建议备车；

充电模块，用于在确定所述剩余电量不满足所述用车耗电量情况下，对所述车辆进行充电。

在一些实施例中，备车装置500还包括：

第二获取模块，用于在所述剩余电量不满足所述用车耗电量的情况下，获取当前时刻；

第七确定模块，用于基于所述当前时刻和所述用车时刻，确定可充电时长；

第八确定模块，用于确定利用所述可充电时长充电后的电量是否满足所述用车耗电量；

第二输出模块，用于在所述充电后的电量不满足所述用车耗电量的情况下，输出第二提示信息，其中，所述第二提示信息用于提示用户充电后不能满足用车需求。

在一些实施例中，控制模块550包括：

生成子模块，用于获取基于所述目标备车参数集合生成的备车脚本；

控制子模块，用于基于所述备车脚本，控制所述车辆执行所述备车操作。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。在一些实施例中，本公开实施例提供的装置具有的功能或包含的模块可以用于执行上述方法实施例描述的方法，对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的备车方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件、软件或固件，或者硬件、软件、固件三者之间的任意结合。

本申请实施例提供一种车辆，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的部分或全部步骤。

本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的部分或全部步骤。所述计算机可读存储介质可以是瞬时性的，也可以是非瞬时性的。

本申请实施例提供一种计算机程序，包括计算机可读代码，在所述计算机可读代码在计算机设备中运行的情况下，所述计算机设备中的处理器执行用于实现上述方法中的部分或全部步骤。

本申请实施例提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序被计算机读取并执行时，实现上述方法中的部分或全部步骤。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一些实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一些实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

这里需要指出的是：上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考。以上设备、存储介质、计算机程序及计算机程序产品实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请设备、存储介质、计算机程序及计算机程序产品实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，图6为本申请实施例中车辆的一种硬件实体示意图，如图6所示，该车辆600的硬件实体包括：处理器601、通信接口602和存储器603，其中：

处理器601通常控制车辆600的总体操作。

通信接口602可以使车辆通过网络与其他终端或服务器通信。

存储器603配置为存储由处理器601可执行的指令和应用，还可以缓存待处理器601以及车辆600中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。处理器601、通信接口602和存储器603之间可以通过总线604进行数据传输。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各步骤/过程的序号的大小并不意味着执行顺序的先后，各步骤/过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

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

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

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims (10)

1.一种备车方法，其特征在于，包括：

响应于用户发出的备车请求，确定用车时刻；

基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；

确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；

在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；

基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

2.根据权利要求1所述的方法，其特征在于，所述备车计划表的生成方法包括：

响应于所述用户发出的备车请求集合中的每一备车请求，确定用车的起始位置和起始时刻；

获取所述用户针对预设备车参数集合中的每一预设备车参数的设置值；

确定用车的结束位置和结束时刻；

针对所述每一备车请求，基于所述起始位置、所述起始时刻、所述设置值、所述结束位置和所述结束时刻，通过机器学习的方法生成所述备车计划表。

3.根据权利要求1所述的方法，其特征在于，所述初始备车参数集合包括目标温度和/或目标亮度，所述基于所述用车时刻，通过备车计划表确定初始备车参数集合，包括：

基于所述用车时刻和当前的环境温度，通过备车计划表确定所述目标温度；和/或，基于所述用车时刻和当前的环境亮度，通过备车计划表确定所述目标亮度。

4.根据权利要求1至3任一项所述的方法，其特征在于，还包括：

在所述剩余电量满足所述总耗电量的情况下，将所述初始备车参数集合确定为所述目标备车参数集合。

5.根据权利要求1至3任一项所述的方法，其特征在于，所述在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合，包括：

在所述剩余电量不满足所述总耗电量的情况下，基于所述初始备车参数集合中备车参数的优先级和可降低幅度，调整所述初始备车参数集合中的备车参数，至所述剩余电量满足调整后的备车参数对应的所述总耗电量，得到所述目标备车参数集合。

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

在所述剩余电量不能满足调整后的备车参数对应的总耗电量的情况下，输出第一提示信息，其中，所述第一提示信息用于提示用户电量不足不建议备车；

在确定所述剩余电量不满足所述用车耗电量情况下，对所述车辆进行充电。

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

在所述剩余电量不满足所述用车耗电量的情况下，获取当前时刻；

基于所述当前时刻和所述用车时刻，确定可充电时长；

确定利用所述可充电时长充电后的电量是否满足所述用车耗电量；

在所述充电后的电量不满足所述用车耗电量的情况下，输出第二提示信息，其中，所述第二提示信息用于提示用户充电后不能满足用车需求。

8.根据权利要求1至3任一项所述的方法，其特征在于，所述基于所述目标备车参数集合，控制所述车辆执行所述备车操作，包括：

获取基于所述目标备车参数集合生成的备车脚本；

基于所述备车脚本，控制所述车辆执行所述备车操作。

9.一种备车装置，其特征在于，包括：

第一确定模块，用于响应于用户发出的备车请求，确定用车时刻；

第二确定模块，用于基于所述用车时刻，通过备车计划表确定初始备车参数集合，其中，所述备车计划表为利用所述用户的历史备车数据通过机器学习的方法得到的所述用户的备车信息；

第三确定模块，用于确定车辆的剩余电量和总耗电量，其中，所述总耗电量包括执行所述初始备车参数集合中的备车参数的备车耗电量和用车耗电量；

调整模块，用于在所述剩余电量不满足所述总耗电量的情况下，将所述初始备车参数集合调整为目标备车参数集合；

控制模块，用于基于所述目标备车参数集合，控制所述车辆执行所述备车操作。

10.一种车辆，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至8任一项所述方法中的步骤。