CN115237510A - 用于车辆的建议提供设备、系统和方法 - Google Patents

Abstract

本发明提供了用于车辆的建议提供设备、系统和方法。所述设备包括：第一接口，配置成能够与车载的人机交互APP通信；第二接口，配置成接收来自于车载的人机交互界面、车载通信单元和车载传感器中任一项的数据；以及处理模块，配置成基于接收到的数据计算出针对用户可能提出问询的预测；并且还配置成在从APP接收到包含用户的非具象输入的问询消息的情况下，向提出问询的APP输出对应于用户的非具象输入的操作建议，或者主动地向相关APP输出基于计算出的预测的操作建议。

Description

用于车辆的建议提供设备、系统和方法

技术领域

本发明主要涉及一种用于车辆的解决方案，尤其涉及一种用于车辆的建议提供设备、系统和方法。

背景技术

随着汽车朝着智能化、电动化、网联化和共享化的方向发展，数字座舱为汽车价值链带来了新机遇。数字座舱对车内人机交互提出了较高要求，因为为数字座舱的重点发展方向是乐享的用户体验。

在现有技术中，已经开发了多种车辆人机交互的方式以及相应的应用程序(APP)，它们实现了人与车的交互功能。车辆的用户(例如，车辆中的驾乘人员)可以通过与车机的交互而了解诸如车状、路况之类的信息，并执行诸如定速巡航、蓝牙免提、空调、音响之类的设置。

但是，这些人机交互提供的服务依然存在一些不尽如人意的方面。例如，在车辆中，现有的人机交互应用程序在接收到用户输入之后，可能无法准确并快速地理解用户期望，由此导致用户需要与车机进行多次交互才能实现或者部分实现其期望。

发明内容

下文给出对一个或多个方面的简要总结，以便提供对这样方面的基本理解。这个总结不是对全部方面的泛泛概括，以及不旨在标识全部方面的关键或重要元素，也不旨在描绘任意或全部方面的范围。其唯一的目的是以简化的形式给出一个或多个方面的一些实现，作为对后文所给出的更详细描述的序言。

根据本发明的一个方面，提供了一种用于车辆的建议提供设备，其包括：第一接口，配置成能够与车载的人机交互APP通信；第二接口，配置成从接收来自于所述第一接口、车载传感器以及车辆通信单元中的至少一项的数据；以及处理模块，其被配置成：基于接收到的数据计算出针对用户可能提出问询的预测；并且在从人机交互APP接收到包含用户的非具象输入的问询消息的情况下向提出问询的人机交互APP输出对应于用户的非具象输入的操作建议，或者主动地向相关人机交互APP输出基于计算出的预测的操作建议，以使得用户与人机交互APP的交互轮次最小化。

根据一实施方式，接收到的数据包含与人机交互、车辆状况和环境相关的历史数据以及与人机交互、车辆状况和环境相关的实时数据。

根据一实施方式，所述非具象输入包含需要多次或多轮人机交互才能确定用户期望的模糊用户输入；并且所述预测包含基于类别的预测，所述类别是可扩展的和/或可调整的。

根据一实施方式，在所述处理模块经由第一接口从人机交互APP接收到包含非具象输入的问询消息时，从计算出的各类预测中查找出符合用户期望的预测，作为所述操作建议。

根据一实施方式，所述查找包括：根据基于所述预测类别的多级索引，逐级地查找出符合用户期望的预测；或者根据问询消息中的关键词与计算出的分类预测的类目关键词的匹配结果确定出符合用户期望的预测。

根据一实施方式，所述处理模块在计算出所述预测之后，基于获得的实时用户数据推算出用户期望和与该期望相应的车辆操作，并向相关人机交互APP广播推算出的用户期望和车辆操作，以便人机交互APP主动与用户建立交互。

根据一实施方式，所述处理模块还配置成将响应于所述操作建议的用户操作以及相应的车况和环境作为更新的历史数据存储到所述数据库中。

根据一实施方式，所述处理模块还配置成：对接收到的数据进行处理以使得由包含车载传感器在内的车辆硬件引起的数据精度的差异和/或由包含人机交互APP在内的车辆软件引起的预测偏差被降低到最小程度。

根据一实施方式，车辆硬件引起的差异包括：硬件的不同生产商、不同型号、不同精度或不同工作状态引起的差异；车辆软件引起的差异包括：不同的车辆软件操作系统、不同的软件版本引起的差异。

根据一实施方式，所述预测的类别包含以下一项或多项：

-车辆状态，包含车辆异常状态和车辆健康状态；

-车辆控制，包含驾驶模式和电子功能；

-舒适性设置，包含空调设置和加热设置；

-用户偏好，包含导航偏好和搜索偏好；以及

-用户信息，包含行程建议。

根据一实施方式，所述建议提供设备设置在车辆的域控制器或中央控制器或电子控制单元中。

根据本发明的另一个方面，提供了一种用于车辆的预测提供系统，包括设置于车辆中的数据库、传感器、通信单元以及如上所述的建议提供设备，其中，所述数据库设置在车辆运算单元中，用于存储与环境、车辆状况和人机相互相关的历史数据；所述传感器和所述通信单元用于采集与环境、车辆状况和人机相互相关的实时数据，所述通信单元能够与车辆的外部设备有线和/或无线通信，所述传感器包括环境传感器和车辆状态传感器；所述建议提供设备用于基于历史数据和实时数据计算出用户可能问询的各类预测，并向车载的人机交互APP输出基于计算出的预测的操作建议，从而使得用户与人机交互APP的交互轮次最小化。

根据本发明的再一个方面，提供了一种用于车辆的建议提供方法，可选地，所述方法由如上所述的设备和/或如上所述的系统执行，所述方法包括：从设置于车辆运算单元中的数据库接收与人机交互、车辆状况和环境相关的历史数据；从车载的传感器和通信单元接收与人机交互、车辆状况和环境相关的实时数据；基于接收到的历史数据和实时数据计算出针对用户可能提出问询的预测；以及在从车载的人机交互APP接收到包含用户的非具象输入的问询消息的情况下向提出问询的人机交互APP输出对应于用户的非具象输入的操作建议，或者主动地向相关的人机交互APP输出基于计算出的预测的操作建议，以使得用户与人机交互APP的交互轮次最小化。

根据本发明的又一个方面，提供了一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行如上所述的方法。

附图说明

从结合附图的以下详细说明中，将会使本发明的技术方案更加清楚。可以理解的是，这些附图仅用于说明的目的，而并非意在对本发明的保护范围进行限制。

图1是可以在其中实施本发明的一些实施方式的示例性环境。

图2是根据本发明的一可行实施方式的用于车辆的建议提供系统的示意性框图。

图3示出了根据本发明的一可行实施方式的建议提供过程。

图4是根据本发明的一可行实施方式的车辆，其设置有如图2所示的建议提供系统。

图5是根据本发明的一可行实施方式的用于车辆的建议提供方法的流程图。

具体实施方式

本发明主要涉及一种用于车辆的解决方案，其从数据源获取元数据，借助于部署在车辆中的深度神经网络对获取的数据执行数据处理，并向车辆的人机交互应用程序提供操作建议，从而使得车辆用户与车辆人机交互界面HMI(Human Machine Interface)之间的交互轮次最小化，提升了车辆用户与车辆HMI之间的交互效率。

根据本发明实施例的解决方案，其能够以数据驱动的方式为车辆用户提供智能服务，尤其是为用户提供符合用户预期的精准建议，从而能够在车辆中实现针对用户的“量身定制”化服务。

根据本发明实施例的解决方案，在车辆中集中管理来自多种数据源的元数据，并对这些元数据执行统一的处理(例如，过滤、分类、融合)，由此车内不同的人机交互应用程序能够为用户提供高度一致的建议。

根据本发明实施例的解决方案，来自数据源的车辆数据以及用户数据保存在车辆本地，并且向人机交互应用程序直接输出经过对这些数据在本地完成加工和处理之后服务(建议)。由此，根据本发明实施例的解决方案具备数据安全性和私密性的优点。而且，根据本发明实施例的解决方案不存在需要与车辆外部设备多次通信握手而引起的延时。

根据本发明实施例的解决方案，随着该解决方案在车辆中的使用而积累和更新的数据能够成为算法模型再学习和再训练的数据。因此该解决方案的性能会随着其使用而不断提升。

下面，结合附图描述本发明的具体实施方式。

图1示意性示出了可以在其中实施本发明的一些实施方式的示例性环境，其主要包括建议提供系统100、人机交互应用程序200和数据源300。可以理解的是，图1所示的环境可以是根据本发明实施例的建议提供系统100的一个典型应用环境，但本发明并不限于该特定架构。

建议提供系统100设置在车辆上，也可以称为车载系统。关于系统100的构成和工作原理将在下文中具体介绍。

人机交互应用程序200(以下，可以简称为“人机交互APP 200”或“APP 200”)设置在车辆上。人机交互应用程序200是车辆HMI(即，车辆中的人机接口)的应用程序。车辆HMI可以包括多种人机交互方式，例如，触屏、语音、按键，等等。这些交互方式可以通过车辆中诸如中控面板、按钮、仪表盘之类的交互介质来实现。在车辆中，人机交互应用程序200可以为用户实现多种功能，例如，音乐、导航、周边查、车身控制，等等。

数据源300可以多种数据源，它们可以位于车辆中，可以位于车辆外部；它们可以是车辆的构成部分，也可以不是车辆的构成部件。例如，数据源300以包括车内人机接口、车载传感器、路侧设施中的环境传感器、云端服务器中的计算设备、车辆用户的智能设备、其他车辆，等等。

建议提供系统100可以从数据源300获得传感器数据(例如，车辆状态、环境状态)、用户随身携带的设备中的数据(例如，车辆中的驾乘人员手机中的日程表)、用户在车里面产生的数据(例如，车辆中的驾乘人员通过诸如微信、支付宝之类的生态产生交易数据)、用户偏好/历史数据(例如，用户踩刹车的历史行为以及由此获得的踩刹车习惯、调整座椅的历史行为以及由此获得的座椅调整偏好、设置空调温度的历史行为以及由此获得的空调温度设置偏好)。

如图1所示，根据本发明实施例的架构，采用建议提供系统100作为中间层，将人机交互应用程序200与数据源300隔离开。基于这样的架构，人机交互应用程序200并不获取元数据，而是获取建议提供系统100吐出的服务(尤其是，建议提供系统100对元数据进行加工和处理之后输出的操作建议)，由此保护了车辆数据和用户数据的私密性，提升了数据安全性。

图2示出了根据本发明的一实施方式的建议提供系统100，其主要包括数据库10、传感器20、通信单元30和建议提供设备40。

数据库10可以设置在车辆的运算单元中。例如，在车辆的中央控制器、域控制器或信息娱乐系统中创建一个或多个数据库。数据库10可以存储历史数据，例如，历史人机交互数据、历史车辆数据和历史环境数据。

历史人机交互数据可以包含用户在与车辆中人机交互界面进行交互的过程中产生的数据。例如，在通过触屏的交互中，历史人机交互数据可以包含这样的内容：用户通过触屏设定的空调温度、风量、风向和空调运行模式，以及在触屏每次接收到用户输入之后向用户呈现的信息。例如，在通过语音的交互中，历史人机交互数据可以包含一对或多对问答数据。

历史人机交互数据还可以包含在车辆中发生的用户操作数据。例如，在车辆中发生的用户操作数据可以包含用户踩刹车的行为记录以及由该行为记录推算出的用户踩刹车习惯/风格数据；用户调整座椅的行为记录以及有该行为记录推算出的座椅调整习惯/偏好数据。

历史车辆数据可以包含用于记录车辆状态的历史数据。例如，历史车辆数据包含车辆的动力总成在不同环境/不同工况/不同路况/不同路线下的能量消耗曲线；车辆的动力电池在不同能量状态/不同环境/不同工况/不同路况/不同路线下的充放电曲线，等等。

历史环境数据可以包含表示车辆周围环境状况的历史数据。例如，历史环境数据可以包含对象状态历史数据、场景历史数据、天气历史数据，等等。

在一些情况下，多种历史数据之间可能存在关联性，例如，用户交互数据是在特定的车辆状态和特定的环境状态下产生的，对于这样存在关联性的数据，可以采用关系型数据库来存储，以便充分保留历史数据的关联性。

在一些情况下，多种历史数据可能数据量十分庞大，超过关系型数据库的存储阈值。这时，可以采用分布式数据库集群来存储，以便具备扩展能力，并减少数据处理的延迟。

在一些情况下，可以采用关系型数据库与分布式数据库集群的混合存储模型来存储历史数据。

当然，本发明的实施例可以根据具体应用情况而采用任意适合的存储模型，不限于此。

传感器20设置在车辆上，因此也可以称为车载传感器。传感器20采集实时数据，其采集的实时数据(例如，经由车辆总线)直接传送给建议提供设备40或者经过预处理之后传送给建议提供设备40，以便参与后续的数据处理。

传感器20可以包括设置在车辆上的环境传感器21和车辆状态传感器22。

环境传感器21用于捕捉车辆周围的环境信息。环境传感器21可以包括摄像头(例如，单目标、多目标、环视)和/或雷达器(例如，激光雷达器、超声波雷达器、毫米波雷达)。摄像头可以通过图像或者视频分析得到车辆周围的环境信息，例如可以得到车辆距离路侧或障碍物的相对距离。雷达器可以通过对点云的分析得到车辆距离路侧或障碍物的相对距离。环境传感器可以包括设置于车身周边的多个环境传感器，并且该设置考虑了安全冗余性，即，确保车辆周围的环境状况能够被充分地采集。

车辆状态传感器22用于捕捉车辆状态信息。车辆状态传感器可以包括直接或间接测量车辆状态参数的传感器，例如，轮速传感器、悬架位移传感器、加速度传感器、转向角传感器，等等。

通信接口30能够提供车辆与外部设备之间的通信连接。车辆能够经由通信接口30从外部设备接收实时数据。车辆与外部设备之间可以采用有线和/或无线通信。无线通信方式例如实现为3G/4G/5G，C-V2X，DSRC，Wi-Fi或Bluetooth以及它们中多项的组合。外部设备可以包括位于车辆外部的设备以及虽然位于车内但不属于车辆构成部分的设备，例如，车内乘员携带的智能手机。外部设备例如是云端服务器(例如，云端服务器经由5G蜂窝网络与车辆通信)、边缘服务器(例如，边缘服务器经由5G蜂窝网络与车辆通信)、路侧设施(例如，路侧设施经由C-V2X与车辆通信)、能够与车辆无线通信的其他车辆(例如，其他车辆经由C-V2X与车辆100通信)、能够与车辆无线通信的电子设备(例如，车辆的驾乘人员随身携带的智能手机、智能手表)。

经由通信接口30从外部设备接收的实时数据可以包含：环境状况数据、车辆状况数据、地图和导航数据。

环境状况数据可以包含车辆周围对象的对象数据，例如，对象的运动速度，运动趋势、位置(例如，对象的绝对位置或者与一参照物的相对位置)、尺寸。环境状况数据还可以包含气候和天气数据。气候和天气数据可以包含气候和天气状况参数，例如，季节、有雾、冰雹、阴天、下雨、可见度、照明度、降雨量，等等。环境状况数据还可以包含场景数据。例如，场景数据可以包含高速、交叉路口、单行道，等等。

车辆状态数据可以包含车辆的行驶方向、速度和加速度；车辆当前行驶车道以及相对于该车道的位置；车辆的运动趋势，等等。

地图和导航数据可以包含车辆行驶路段的地图数据和导航路线。地图和车辆导航数据可以基于外部设备对车辆的定位而自动地发送至车辆，也可以基于车辆向外部设备的请求而发送至车辆。

可以理解的是，通过传感器20或通信接口30获得的实时数据可以直接参与后续的数据处理，也可以经过预处理之后再参与后续的数据处理。该预处理可以包含对获得的元数据进行过滤、分析和加工，从而得到能够在后续数据处理中直接使用的数据。例如，对通过传感器采集的车辆动力总成在多个路况下的能量消耗数据进行预处理，从而得到分别表示车辆动力总成在各路况下的能量消耗随时间变化的多条曲线。这样的预处理可以在建议提供设备40中执行，也可以在建议提供设备40外部执行，例如，在车辆的运算单元中或在与传感器集成在一起的处理芯片中执行。

建议提供设备40与数据库10、传感器20和通信单元30分别通信连接。建议提供设备40从数据库10获得的历史数据以及经由传感器20和通信单元30获得的实时数据进行综合处理，得到针对用户可能提出问询的各类预测，并在从人机交互APP接收到包含用户的非具象输入的问询消息的情况下或者主动地向人机交互APP提供建议。

建议提供设备40主要包括第一接口41、第二接口42和处理模块43。第一接口41构造成能够与人机交互APP 200通信。第二接口42构造成能够从数据库10获取历史数据以及从传感器20和通信单元30获取实时数据。处理模块43基于历史数据和实时数据计算出用户可能问询的各类预测。接着，经由第一接口41并向人机交互APP 200输出基于计算出的预测的建议，从而使得用户与人机交互APP 200的交互轮次最小化，提高交互效率。

建议提供设备40及其各构成部分可以采用硬件或者软件或者软件与硬件相结合的方式来实现。对于硬件实现的部分，可以在一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数据信号处理器件(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计以执行其功能的电子单元、或它们的组合中实现。对于以软件实现的部分，可以借助于微代码、程序代码或代码段来实现，还可以将它们存储在诸如存储组件之类的机器可读存储介质中。

可以理解的是，建议提供设备40及其各部分的命名应当被理解为逻辑上(功能上)的描述，而不应理解为物理形态或设置方式的限定。换言之，建议提供设备40可以实现在同一芯片或电路中，也可以按照逻辑或功能划分成多个部分，分别设置于不同的芯片或电路中，本发明对此不进行限定。

在一实现方式中，建议提供设备40可以实现为包括存储器和处理器。存储器包含指令，该指令在被处理器执行时使得处理器执行根据本发明实施例的建议提供方法。

在一实现方式中，建议提供设备40实现为车载软件，例如，设置在车辆的域控制器或中央控制器或运算单元中。

图3示出了根据本发明的一实施方式的建议提供过程300。该过程300可以借助于上述建议提供系统100来实现，因此以上相关描述同样适用于此。如图3所示，建议提供过程300主要包括三个过程，即，数据收集过程310、数据处理过程320和再学习过程330。以下，具体介绍每个过程。

首先，执行数据收集(框310)。

在框312中，在创建于车辆运算单元中的数据库10中存储历史数据。历史数据可以包含历史人机交互数据、历史车辆数据和历史环境数据。关于历史数据所包含的内容及其存储方式的一些例子参见以上相关描述。

在框314中，通过传感器20或通信接口30采集实时数据。实时数据可以包含实时车辆数据、实时用户数据和实时环境数据。关于实时数据所述包含的内容及其采集方式的一些例子参见以上相关描述。

可以理解的是，本发明不限定框312和框314的执行顺序，它们可以同时执行，或者按照预定周期执行，或者响应于特定信号或特定指令而触发框312或框314。

接着，执行数据处理(框320)。数据处理过程可以在建议提供设备40中实现。

在框321中，通过第二接口42从数据库10获取历史数据以及从传感器20和通信接口30获取实时数据。

在框322中，处理模块43基于获取的历史数据和实时数据计算出针对用户可能提出的问询的各类预测。计算出的预测类别可以进一步包含一级或多级子类别。在计算出的预测中，这些类别或子类别可以包含多级索引，以便后续的查询。

在如下表1中，以示例的方式列出了计算的预测类别及其子类别。

表1

在一实施例中，预测类别和/或子类别是可扩展的。可以根据在车辆行驶过程中陆续获得到的新信息而增加相应的预测类别。例如，检测到车辆经常进入或离开自动驾驶的地理围栏区域，则可以相应地增加关于车辆处于地理围栏区域内或外的驾驶建议。

预测类别和/或子类别是可调整的。可以根据车辆用户的用车习惯或偏好而调整预测类别。例如，根据车辆用户的出行规律得知用户出行周期以上午或下午来规划比较更合理，则可以将表1中的“下一天行程”调整为“上午行程”以及“下午行程”。

在计算出基于类别的预测之后，一种情形是响应于来自APP的问询消息而向提出问询的APP输出对应于问询的建议。另一种情形是主动向APP广播计算出的预测。

框323-框325描述了响应于问询消息而输出建议的情形。

在框323中，处理模块43经由第一接口41从人机交互APP 200接收到问询消息。该问询消息包含对用户向的APP的非具象输入的描述。

非具象输入是指用户需要与人机交互界面进行多次或多轮交互，人机交互APP才能确定用户期望的模糊输入。换言之，非具象输入包含不够具体的用户输入，以使得人机交互APP无法仅通过一次或者较少次数的用户交互就能够提供用户期望的反馈。为了清楚性，下面描述几个“非具象输入”的例子。

例如，在语音交互中，用户说“太热了”，语音APP无法得知用户是想打开车窗还是打开空调，也不知道用户期望设置的空调温度或模式。这时，语音APP经由第一接口41向建议提供设备40发送问询消息，该问询消息包含用户的模糊输入“太热了”。

例如，在触屏交互中，用户通过点击触控屏而打开了周边查的美食界面，触屏APP并不知道用户期望的美食种类或具体餐厅。这时，触屏APP经由第一接口41向建议提供设备40发送问询消息，该问询消息包含用户的模糊输入“周边美食”。

在框324中，处理模块43根据接收到的问询消息从计算出的预测中确定出对应于用户期望的操作建议。

在一实施例中，处理模块43借助于计算出的预测的多级索引查找出对应于用户期望的操作建议。例如，处理模块43可以按照多级索引的从上至下的层级，逐级地确定出与问询消息相对应的操作建议；或者，处理模块43可以将问询消息中的关键词与计算出的分类预测的类目关键词(例如，索引中的关键词)的相匹配，并根据匹配结果确定出与问询消息相对应的操作建议。

在框325中，经由第一接口41将确定出的操作建议发送给提出问询的APP。

可以理解的是，处理模块43可能经由第一接口41从多个人机交互APP接收到多个问询消息。在这种情况下，处理模块43针对每个问询消息分别执行上述处理，分别给出操作建议。

框326和框327描述了主动向人机交互APP广播计算出的预测的情形。

在框326中，处理模块43在计算出基于类别的预测之后，根据实时用户数据预测出用户期望或者计划以及相应的车辆操作。

在框327中，经由第一接口41向相关APP广播操作建议。APP在接收到操作建议之后，基于该操作建议主动与用户交互或者执行车辆操作，以起到使得与用户交互轮次最小化的作用。

接着，执行再学习330。

在框331中，经由第一接口41从APP 200获取响应于操作建议的用户输入，即，在APP 200向用户提供了接收到的操作建议之后，用户向APP 200的输入。同时，记录与用户输入相应的车况和环境。

在一实施例，语音APP接收到的操作建议是“将空调温度设置为26度”。在语音APP向用户播报“是否将空调温度设置为26度”之后，用户回答“是”。在该实施例中，用户的回答“是”即为上述响应于操作建议的用户输入，并且，用户回答“是”时的车况和环境即为与用户输入相应的车况和环境。

在框332中，将响应于操作建议的用户输入以及相应的车况和环境作为更新的历史数据存储到数据库10中。例如，将响应于操作建议的用户输入作为更新的历史用户交互数据存储到所述数据库10中。将相应的车况和环境作为与更新的历史用户数据相关联的更新的历史车辆数据和历史环境数据存储到所述数据库10中。

在更新的历史数据存储到数据库中的情况下，这些数据可以用于后续轮次的建议提供，还可以用于算法模型的再学习，起到数据反哺算法的作用。

根据本发明实施例的解决方案，经过实车上的用户交互测试，针对相同的用户期望，相对比现有解决方案能够极大程度地减少交互轮次。根据统计数据，至少能够省略50％以上的无效交互，改善了用户体验。

下面，以用户通过车内的语音APP或者空调控制APP设置空调温度为例，描述根据本发明实施例的解决方案。

首先，在车辆运算单元(例如，中央控制器、域控制器、信息娱乐系统)中建立关系型数据库。在用户每次进行空调设定时，在数据库中存储如下数据，作为历史数据：a)季节和时间；b)车内和车外的环境温度；c)车辆所在位置的环境状况和空气质量；d)车辆搭乘的成员数；e)车窗开闭状态；f)车辆行驶速度；g)用户设定的空调温度、风量、风向、空调运行模式(例如，内循环/外循环)。

接着，通过车辆上搭载的传感器(例如，环境传感器、GPS模块)以及通信单元(例如，车联网模块)获取以下实时数据：a)通过传感器获得车内、车外的实时温度；b)通过空调控制器获得当前的空调设置，包括温度、风量、风向、空调运行模式等；c)通过车内传感获得车内所搭乘成员的数量；d)通过国际标准时计算出当前季节和昼夜状态；e)通过网络和GPS获得车辆当前所在地的实时天气状况和空气质量状况。

接着，处理模块43基于在上述步骤中获得的历史数据以及实时数据推算出基于当前环境状况用户可能进行的空调设置操作。

接着，在一种情况下，在语音助手APP或空调控制APP接收到用户关于空调设置的非具象输入时，可以经由第一接口41向建议提供设备40发送问询消息。建议提供设备40响应于问询消息将推算出的空调设置操作作为操作建议发送给提出问询的APP。

在另一种情况下，建议提供设备40将推算出的空调设置操作进行广播，通知相关APP(例如，语音助手APP、空调控制APP或其他APP)用户可能进行的空调设置操作(设置变更)。由接收到的广播的APP主动与用户建立交互，确认是否需要为用户重新设置空调。

接着，在用户进行空调设置操作后，将用户操作、车况以及环境作为更新的历史数据存储到数据库10中。

下面，以为用户下一段行程所必要的准备活动给出建议为例，描述根据本发明实施例的解决方案。

首先，在车辆的多个运算单元中建立多个数据库，以便记录下述数据：a)车辆的动力总成在不同环境/不同工况/不同路况/不同路线下的能量消耗模型；b)车辆的动力电池在不同能量状态/不同环境/不同工况/不同路况/不同路线下的最佳充放电曲线模型；c)用户的行程设计偏好(例如，在剩余行驶里程小于某阈值后进行能量补充；习惯在出发前进行能量补充；习惯在途中进行能量补充；习惯到达目的地之后进行能量补充)；d)用户的日常用车偏好(例如，提前预热/预冷车辆的习惯、驾驶风格、路线选择偏好)。

接着，经由第二接口42读取以下实时数据：a)从用户的日程表读取用户下一段行程安排；b)通过传感器获得当前车辆剩余能量和车辆工况；c)通过GPS和网络连接获取当前车辆位置和周围环境状况。

接着，处理模块43基于获取的数据计算出：a)下一行程的预计能量开销和预计行驶时长；b)当前剩余能源是否能够支持用户完成下一行程。

接着，基于计算结果，经由第一接口41向相关APP输出操作建议，供APP与用户建立主动交互。操作建议可以包括：a)确定当前能量是否支持完成下一行程；b)能源补充建议；c)建议的出发时间以确保准时赴约；d)在什么时间为用户开启提前预热/预冷。

另外，现有的解决方案存在当用户在车内采用不同的交互方式进行相同的问询时，可能无法获得一致的反馈的问题，即，根据现有的解决方案，针对相同的用户问询，车内不同的人机交互应用会作出不同的反馈。该问题主要是由各APP实现为相互独立所引起。具体而言，各人机交互APP的数据源不一样，它们的处理逻辑不透明，不通用，它们基于各自能够获得的元数据和处理逻辑与用户交互。

对此，如上所述那样的，根据本发明实施例的解决方案，由建议提供系统100与数据源300通信，而不是由各个APP直接与数据源300通信，从而确保了参与数据处理的元数据是相同的。进一步，根据本发明实施例的解决方案，在获得了相同元数据的情况下，对元数据进行统一地处理(例如，以相同的处理逻辑进行数据处理)，而不是由各个APP单独处理，从而能够为各个APP提供具备一致性的操作建议。

另外，处理模块还可以对接收到的数据进行处理以使得由包含车载传感器在内的车辆硬件引起的数据精度的差异和/或由包含人机交互APP在内的车辆软件引起的预测偏差被降低到最小程度。

一方面，车辆硬件的差异也可能对建议操作的准确性和一致性造成影响。例如，不同的车型采用不同的元器件，相同车型在不同生产周期采用不同的元器件，这些可能导致建议提供设备40获得的元数据的精度不一致，从而引起提供的有偏差的操作建议的问题。对此，根据本发明实施例的解决方案，对硬件的差异进行吸收，使得获得元数据的精度与硬件的生产商、型号、精度等无关。关于吸收硬件差异的方式，可以采用多种方式实现。例如，对接收到的精度不一致的元数据进行加工，使得它们成为精度一致数据之后再参与后续的数据处理；或者，首先对元器件需要提供的内容进行定义，以便元器件供应商对接该定义，从而使得车辆采用的元器件能够提供符合统一要求的元数据。

另一方面，车辆软件的差异也可能对建议操作的准确性和一致性造成影响。车辆软件引起的差异包括：不同的车辆软件操作系统、不同的软件版本引起的差异。根据本发明实施例的解决方案，对软件差异的吸收可以包括多种方式，例如，设置不同操作系统的切换参数，设计用于兼容不同软件版本的api参数或者动态调整适用于不同软件版本的api参数。

下面，描述根据本发明实施例的解决方案，采用不同的APP能够提供一致性操作建议的例子。

例如，车辆的驾驶员通过语音APP询问当前天气状况，并且车辆上的一乘员通过车内大屏上的Climate APP询问当前天气状况。根据现有的解决方案，这两个APP可能向用户反馈不一样的天气状况，因为这两个APP是独立实现的，它们获得的元数据和处理逻辑可能都不一样。根据本发明实施例的解决方案，这两个APP均从建议提供设备40获得对应于用户问询的建议，而建议提供设备40基于相同的元数据和处理逻辑来回答该问询，因为能够向这两个APP提供一致性的建议。

图4示出了根据本发明实施例的车辆400。该车辆400设置有上述建议提供设备40或上述建议提供系统100，并且设置于车上的设备40或系统100与车辆400的人机交互APP200通信连接，以便向APP200输出服务。根据本发明实施的车辆400具备上述设备40或系统100的优点。

图5示出了根据本发明实施例的建议提供方法500。该方法500可以由上述建议提供设备40执行，也可以由上述建议提供系统100执行，因此以上相关描述同样适用于此。

在步骤502中，接收来自于车载的人机交互界面、车载通信单元和车载传感器中任一项的数据。

在一实施例中，接收数据可以包括：经由第一接口从设置于车辆运算单元中的数据库接收历史数据，所述历史数据包含历史人机交互数据、历史车辆数据和历史环境数据；和/或经由第二接口从车辆的传感器和通信单元接收实时数据，所述实时数据包含实时人机交互数据、实时车辆数据和实时环境数据。

在步骤504中，处理模块基于接收到的历史数据和实时数据计算出针对用户可能提出问询的预测。

在步骤506中，在从APP接收到包含用户的非具象输入的问询消息的情况下，经由第一接口向提出问询的APP输出对应于用户的非具象输入的操作建议，以使得用户与APP的交互轮次最小化。

在步骤508中，经由第一接口主动地向相关APP输出基于计算出的预测的操作建议，以使得用户与APP的交互轮次最小化。

本发明还提供机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行上述方法500。

可以理解的是，以上描述的所有模块都可以通过各种方式来实施。这些模块可以被实施为硬件、软件、或其组合。此外，这些模块中的任何模块可以在功能上被进一步划分成子模块或组合在一起。

可以理解的是，处理器可以使用电子硬件、计算机软件或其任意组合来实施。这些处理器是实施为硬件还是软件将取决于具体的应用以及施加在系统上的总体设计约束。作为示例，本发明中给出的处理器、处理器的任意部分、或者处理器的任意组合可以实施为微处理器、微控制器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑器件(PLD)、状态机、门逻辑、分立硬件电路、以及配置用于执行在本公开中描述的各种功能的其它适合的处理部件。本发明给出的处理器、处理器的任意部分、或者处理器的任意组合的功能可以实施为由微处理器、微控制器、DSP或其它适合的平台所执行的软件。

可以理解的是，软件应当被广泛地视为表示指令、指令集、代码、代码段、程序代码、程序、子程序、软件模块、应用、软件应用、软件包、例程、子例程、对象、运行线程、过程、函数等。软件可以驻留在计算机可读介质中。计算机可读介质可以包括例如存储器，存储器可以例如为磁性存储设备(如，硬盘、软盘、磁条)、光盘、智能卡、闪存设备、随机存取存储器(RAM)、只读存储器(ROM)、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、寄存器或者可移动盘。尽管在本发明给出的多个方面中将存储器示出为是与处理器分离的，但是存储器也可以位于处理器内部(如，缓存或寄存器)。

虽然前面描述了一些实施方式，这些实施方式仅以示例的方式给出，而不意于限制本发明的范围。所附的权利要求及其等同替换意在涵盖本发明范围和主旨内做出的所有修改、替代和改变。

Claims (13)

1.一种用于车辆的建议提供设备，包括：

第一接口，配置成能够与车载的人机交互APP通信；

第二接口，配置成接收来自于所述第一接口、车载通信单元以及车载传感器中的至少之一的数据；以及

处理模块，其被配置成：

基于接收到的数据计算出针对用户可能提出问询的预测；并且

在从人机交互APP接收到包含用户的非具象输入的问询消息的情况下向提出问询的人机交互APP输出对应于用户的非具象输入的操作建议，或者主动地向相关人机交互APP输出基于计算出的预测的操作建议，以使得用户与人机交互APP的交互轮次最小化。

2.如权利要求1所述的建议提供设备，其中，所接收的数据包含与人机交互、车辆状况和环境相关的历史数据，以及与人机交互、车辆状况和环境相关的实时数据。

3.如权利要求1或2所述的建议提供设备，其中，所述非具象输入包含需要多次或多轮人机交互才能确定用户期望的模糊用户输入；并且

所述预测包含基于类别的预测，所述类别是可扩展的和/或可调整的。

4.如权利要求3所述的建议提供设备，其中，在所述处理模块经由第一接口从人机交互APP接收到包含非具象输入的问询消息时，从计算出的各类预测中查找出符合用户期望的预测，作为所述操作建议。

5.如权利要求4所述的建议提供设备，其中，所述查找包括：

根据基于所述预测类别的多级索引，逐级地查找出符合用户期望的预测；或者

根据问询消息中的关键词与计算出的分类预测的类目关键词的匹配结果确定出符合用户期望的预测。

6.如权利要求1所述的建议提供设备，其中，所述处理模块在计算出所述预测之后，基于获得的实时用户数据推算出用户期望和与该期望相应的车辆操作，并向相关人机交互APP广播推算出的用户期望和车辆操作，以便人机交互APP主动与用户建立交互。

7.如权利要求1-6中任一项所述的建议提供设备，其中，所述处理模块还配置成将响应于所述操作建议的用户操作以及相应的车况和环境作为更新的历史数据存储到所述数据库中。

8.如权利要求1-7中任一项所述的建议提供设备，其中，所述处理模块还配置成：对接收到的数据进行处理以使得由包含车载传感器在内的车辆硬件引起的数据精度的差异和/或由包含人机交互APP在内的车辆软件引起的预测偏差被降低到最小程度；

可选地，车辆硬件引起的差异包括：硬件的不同生产商、不同型号、不同精度或不同工作状态引起的差异；车辆软件引起的差异包括：不同的车辆软件操作系统、不同的软件版本引起的差异。

9.如权利要求1-8中任一项所述的建议提供设备，其中，所述预测的类别包含以下一项或多项：

-车辆状态，包含车辆异常状态和车辆健康状态；

-车辆控制，包含驾驶模式和电子功能；

-舒适性设置，包含空调设置和加热设置；

-用户偏好，包含导航偏好和搜索偏好；以及

-用户信息，包含行程建议。

10.如权利要求1-9中任一项所述的建议提供设备，其中，所述建议提供设备设置在车辆的域控制器或中央控制器或电子控制单元中。

11.一种用于车辆的预测提供系统，包括设置于车辆中的数据库、传感器、通信单元以及如权利要求1-10中任一项所述的建议提供设备，其中，

所述数据库设置在车辆运算单元中，用于存储与环境、车辆状况和人机交互相关的历史数据；

所述传感器和所述通信单元用于采集与环境、车辆状况和人机交互相关的实时数据，所述通信单元能够与车辆的外部设备有线和/或无线通信，所述传感器包括环境传感器和车辆状态传感器；

所述建议提供设备用于基于历史数据和实时数据计算出用户可能问询的各类预测，并向车载的人机交互APP输出基于计算出的预测的操作建议，从而使得用户与人机交互APP的交互轮次最小化。

12.一种用于车辆的建议提供方法，可选地，所述方法由如权利要求1-10中任一项所述的设备和/或如权利要求11所述的系统执行，所述方法包括：

接收来自于车载的人机交互界面、车载通信单元和车载传感器中任一项的数据；

基于接收到的数据计算出针对用户可能提出问询的预测；以及

在从车载的人机交互APP接收到包含用户的非具象输入的问询消息的情况下向提出问询的人机交互APP输出对应于用户的非具象输入的操作建议，或者主动地向相关的人机交互APP输出基于计算出的预测的操作建议，以使得用户与人机交互APP的交互轮次最小化。

13.一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行如权利要求12所述的方法。

Images