CN111002996A - 车载语音交互方法、服务器、车辆和存储介质 - Google Patents

Abstract

本发明实施例提供了一种车载语音交互方法、服务器、车辆、计算机可读存储介质，其中，方法包括：服务器接收场景的自定义信息并生成脚本并存储在服务器上；车辆转发用户的语音请求给服务器；服务器解析语音请求并确定符合场景触发条件后向客户端下发脚本；车辆通过客户端接收并解析脚本后执行对应的指令。本发明可以支持用户在手机等终端对车载语音交互场景进行自定义配置，全程不需要用户输入代码，通过服务器的处理形成可在车辆本地运行的脚本，并且针对同一个组合指令内不同实体的指令可能存在冲突甚至影响着行车安全的情况，通过状态回调或者插入延时等不同处理方式，保证了方案实现车规级安全。

Description

车载语音交互方法、服务器、车辆和存储介质

技术领域

本发明涉及语音技术领域，特别是涉及一种车载语音交互方法、服务器、车辆、计算机可读存储介质。

背景技术

随着语音技术和车辆智能化的快速发展，在车辆中运用语音技术服务于车内用户的方式大幅提高了用户体验。同时，语音技术在智能家居和智能音箱中也得到和车辆类似的深度结合。从智能家居的语音助手和智能音箱的语音助手当前使用现状来看，已经发展出了一部分语音助手基于使用场景的自定义配置方案。

但是车载场景下尚未有语音助手支持基于使用场景的自定义配置方案。如果将智能家居和智能音箱中的方案迁移到车载场景，成本和难度非常高，主要原因在于：

(1)车载场景下的自定义配置会涉及到大量的车载硬件及车机信号等的配套关联与支持，与传统家居场景互相独立的硬件情况差别很大，需要有特定的技术方案来支持车载场景的情况。

(2)由于车载场景的复杂性和特殊性，同一个组合指令内不同实体的指令可能存在冲突、甚至影响着行车安全，需要充分详细的技术方案和产品策略来解决该问题，这是传统的智能家居相关语音技术方案所未考虑和遇到的问题。

发明内容

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种车载语音交互方法、服务器、车辆、计算机可读存储介质和交互系统。

为了解决上述问题，本发明实施例公开了一种车载语音交互方法，其特征在于，该方法包括：

接收场景的自定义信息；其中，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

根据该自定义信息生成脚本并存储在服务器上；

接收并解析车辆客户端转发的用户的语音请求；

根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本，以便客户端解析该脚本后在车辆中执行脚本中包括的待执行指令。

本发明还提出另外一种车载语音交互方法，其特征在于，该方法包括：

接收并转发用户的语音请求给服务器；其中，服务器上预先存储有根据接收的场景的自定义信息生成的脚本，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

接收服务器根据触发信息确定该语音请求符合场景触发条件后下发的脚本；

解析该脚本后在车辆中执行脚本中包括的待执行指令。

本发明还提出再一种车载语音交互方法，其特征在于，该方法包括：

服务器接收场景的自定义信息；其中，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

服务器根据该自定义信息生成脚本并存储在服务器上；

车辆通过客户端接收并转发用户的语音请求给服务器；

服务器接收并解析车辆客户端转发的用户的语音请求；

服务器根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本；

车辆通过客户端接收并解析服务器下发的脚本；

车辆通过客户端执行脚本中包括的待执行指令。

本发明还提出一种服务器，其特征在于，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述的车载语音交互方法的步骤。

本发明还提出一种车辆，其特征在于，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上述的车载语音交互方法的步骤。

本发明还提出一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如上述的车载语音交互方法的步骤。

本发明实施例包括以下优点：

随着智能汽车标配手机应用程序来控制车载硬件，本发明可以支持用户在手机、平板电脑、个人电脑等终端上对车载语音交互场景进行自定义配置，全程不需要用户输入代码，通过服务器的处理形成可在车辆本地运行的脚本，并且针对同一个组合指令内不同实体的指令可能存在冲突甚至影响着行车安全的情况，通过状态回调或者插入延时等不同处理方式，保证了方案实现车规级安全。

附图说明

图1是本发明的一种车载语音交互方法实施例的步骤流程图；

图2是本发明的一种车载语音交互方法实施例中用户在手机上输入场景的自定义信息的一个示意图；

图3a至图3b是本发明的一种车载语音交互方法实施例中说法配置的示意图；

图4是本发明的一种车载语音交互方法实施例中用户设置TTS播报、显示文本和待执行指令的示意图；

图5是本发明的又一种车载语音交互方法实施例的步骤流程图；

图6是本发明的一种车载语音交互装置实施例的结构框图；

图7是本发明的又一种车载语音交互装置实施例的结构框图；

图8是本发明的一种服务器实施例的结构框图；

图9是本发明的一种车辆实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图1，示出了本发明的一种车载语音交互方法实施例的步骤流程图，该方法的执行主体是服务器，具体可以包括如下步骤：

S1，接收场景的自定义信息；其中，自定义信息包括场景名称、场景的触发信息和跟该场景对应的待执行指令。

S2，根据该自定义信息生成脚本并存储在服务器上。其中，本方案的示例脚本以TPL(Transaction Processing Language，事务处理语言)脚本为例，当然本发明也可以使用其他脚本，在此不做限定。

S3，接收并解析车辆客户端转发的用户的语音请求。

S4，根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本，以便客户端解析该脚本后在车辆中执行脚本中包括的待执行指令。即客户端接收到服务器下发的TPL脚本后，在车辆中解析后执行。

本发明实施例的核心构思之一在于，让用户通过终端自行配置场景的自定义信息然后上传至服务器生成脚本，在用户发出语音请求后触发该自定义场景，由服务器下发脚本至车辆执行。

具体地，S1这个步骤包括：

接收终端发送的由用户在终端上输入的场景的自定义信息。

则根据该自定义信息生成脚本并存储在服务器上，包括：根据该自定义信息生成脚本，将该脚本和用户的车辆登录账号设置为映射关系后存储在服务器上。

用户通过手机、平板、PC或者Mac此类个人电脑等终端，藉由预先设置好的场景配置界面，实现场景配置的自定义。

如图2所示，图2是用户在手机上输入场景的自定义信息的图示之一。用户在终端上输入的场景的自定义信息包括场景的触发信息和跟该场景对应的待执行指令。用户还可以根据需要确定是否需要输入场景名称，该场景名称用来区别个性化场景，避免重复的场景产生冲突不可用的问题。用户还可以使用包括平板电脑、PC或Mac等个人电脑、智能手表、虚拟现实眼镜或头显等不同类型的终端来输入需要配置的场景的自定义信息，以便将配置好的内容用于车载环境中。

其中，触发信息包括若干条语音识别后用于触发场景的说法。如图3a和图3b所示，图3a和图3b是说法配置的示意图。通常至少配置一条说法用于触发场景，不能为空。但可以配置特定字数特定语种特定格式的多条说法，例如要求字数在100字以内，说法的语种为中文，格式要求为不支持标点符号和空格。配置多条说法可以给语音识别(ASR，AutomaticSpeech Recognition)一定的容错。本示例中，默认一条说法，并在输入框内提供字数提醒，让用户配置说法时感受到交互简洁和直观。

待执行指令包括流媒体控制指令、车辆控制指令中的一种或多种。

流媒体控制指令，具体指如TTS播报、url的音频播报、音乐播报、指令所带播报如导航声音播报、系统的提示音控制等和流媒体控制相关的指令。

车辆控制指令，具体指如座椅调节、空调调节、或车灯、摄像头等和车辆控制相关的指令。

上述都是车载语音交互场景下，语音助手可执行的操作内容。

语音交互过程中会使用TTS播报结合文字显示来给予用户反馈，本发明中，自定义信息还包括该场景对应的TTS播报文本和/或可在车辆显示部件上显示的显示文本。如图4所示，图4是用户设置TTS播报文本、显示文本和待执行指令的示意图。设置了TTS播报文本后，自定义信息的待执行指令将自动包括“TTS播报”的指令，该播报的内容即为TTS播报文本的内容。车辆显示部件可以是车辆中控平台的显示屏、仪表屏、位于方向盘上的小型显示屏、位于副驾的显示屏、位于后座的显示屏中的任意一个或多个，本方案中涉及的车辆显示部件不限于此，任何能够为车内用户提供显示文本功能的显示部件都属于本方案请求保护的范围，在此不再赘述。

用户通过终端编辑完的场景的自定义信息将通过终端藉由有线/无线的网络连接发送至服务器，再由服务器根据该自定义信息生成脚本，将该脚本和用户的车辆登录账号相关联，即将脚本和用户账号在数据库中设置为映射关系后存储在服务器上。

在整个场景的自定义信息的编辑过程中，用户所见即所得。用户配置的是流媒体控制指令或车辆控制指令，可以直接被用户感知；不需要用户了解软件/网络接口、服务器/服务器等概念，即可直观、简单地进行自定义场景的配置。

S4中，服务器根据触发信息确定该语音请求符合场景触发条件，包括：

判断语音请求是否和触发信息中的任意一条说法匹配；

若语音请求是和任意一条说法匹配，则确定该语音请求符合场景触发条件。

以高频上班场景为例，用户预先配置的场景的自定义信息包括：

场景1

说法(即场景的触发信息)：出发去上班

TTS播报文本：好的，小P和你一起去上班

显示文本：小P和你一起去上班

待执行指令：

指令1-TTS播报：好的，小P和你一起去上班指令2-播放音频：爸爸路上注意安全～

指令3-空调设为23度

指令4-风量设为3档

当用户上车向车内的语音助手或者AI(Artificial Intelligence，人工智能)助手说出“出发去上班”作为语音请求的内容，车辆的中控平台可以作为客户端接收该语音请求并转发至服务器，服务器先判断语音请求是否和触发信息中的任意一条说法匹配，确认语音请求是和任意一条说法匹配后认定该语音请求符合场景触发条件，向客户端下发脚本，客户端接收下发的脚本解析后，将依次执行播报TTS、播报音频、将车内空调设为23度并将风量设为3档等操作。

再以车辆上休息为例，用户预先配置的场景的自定义信息包括：

场景2

说法：

说法1-我想小睡一下

说法2-我想睡一会儿

TTS播报文本：好的，安心休息一会儿吧

显示文本：安心休息一会儿吧

待执行指令：

指令5-TTS播报：好的，安心休息一会儿吧指令6-风量设为2档

指令7-座椅靠背向后调至最后

指令8-座椅位置调至最后

当用户上车向车内的语音助手说出“我想睡一会儿”，车辆通过客户端和服务器交互后，在服务器确认语音请求是和说法2匹配后认定该语音请求符合场景触发条件，向客户端下发脚本，客户端将依次执行播报TTS、将车内空调风量设为2档，并完成座椅靠背和座椅位置的调节。

由于车载场景的复杂性和特殊性，同一个组合指令内不同实体的指令可能存在冲突、甚至影响着行车安全，需要充分详细的技术方案和产品策略来解决该问题。本发明针对该问题，结合流媒体控制指令执行的播放持续性进行及车辆控制指令的即时性下发执行，对持续性车辆控制指令进行执行时长计算，并自动设置延时，保证延时若干时间后再进行下一个指令下发，克服了很多技术难点，有效保证了指令的无冲突下发及流畅的用户体验。持续性车辆控制指令，从指令下发到指令执行结束，被操作实体是持续变化的，而不是只有开始和结束两个瞬间态。持续性车辆控制指令如打开车窗、调节座椅、摄像头转向等。非持续性车辆控制指令如打开车灯、打开空调和风量设为3档等，只有指令下发前后瞬时态。

下面继续以前文2个典型场景来说明指令冲突处理的解决过程：

在场景1中，根据流媒体播放的特性易知，依序执行指令时会发生TTS播报当中，要播放音频的情况，届时指令1和指令2两个指令将产生冲突。同样的，比如录制音频的播放和歌曲的播放之间的冲突，是目前如家居智能音箱晓雅、小度都没解决的问题(因为智能音箱只能支持一类播报，不支持不同类的先后播报)。本方案创新性地采用状态回调的方式，在上条TTS播报结束后，再播报下一条音频。

即S4这个步骤中，向客户端下发脚本，以便客户端解析该脚本后在车辆中执行脚本中包括的待执行指令，包括：

向客户端下发脚本，以便客户端解析该脚本后按时序先执行第一流媒体控制指令，然后状态回调再执行第二流媒体控制指令。

以第一流媒体控制指令为TTS播报，第二流媒体控制指令为播放音频为例，客户端先按时序执行TTS播报，确定“TTS播报”已执行完毕然后状态回调再执行“播放音频”。即遭遇到流媒体播报间的时序冲突处理时，通过前一条播报结束后状态回调后继续播报下一条音频。状态回调是指通过事件检测到对象Object的状态变化，首先调用回调通知观察器Observer，然后更改对象Object的状态标记。本发明中，服务器只需要下发一次TPL脚本，将所有需要判断的逻辑封装在该脚本中，然后客户端根据第一条流媒体控制指令结束(即执行完毕)来执行第二条，客户端执行这些指令时不需要再持续连接服务器，以便解决多次网络请求带来的连接稳定性和连接时延问题。

进一步地，当待执行指令之间不存在时序冲突，也可以让客户端并行执行多个指令，例如某个场景指令A至指令D之间4个指令不存在时序冲突的问题，可以由客户端并行同时执行指令A和指令D这4个指令；又或者上述场景1中，可以允许指令1、指令3和指令4并行执行，然后指令1执行结束再执行指令2。

在场景2中，座椅调节是持续性的，所以指令7和指令8依次执行时，会出现座椅靠背调整的同时要向后调整，这样会造成指令冲突，座椅无法调节。本方案预先将该车辆控制对应的动作完成的时间存储在服务器，涉及到持续性车辆控制指令时，由服务器预判时间，并进行延时插入处理，高效地解决了延续性指令冲突的问题。

即待执行指令包括多个存在时序冲突的持续性车辆控制指令，该方法还包括：

读取所有持续性车辆控制指令；

根据每个持续性车辆控制指令执行完毕所需的时间，对该持续性车辆控制指令增加延时插入处理；

在自定义信息中存储已插入延时的持续性车辆控制指令。

具体地，服务器读取用户配置的场景的自定义信息，通过类似“车控数据输入操作和操作完成时间的对应表格”等方式，对该持续性车辆控制指令增加延时插入处理。例如，对指令6“风量设为2档”增加delay 0s，delay表示该指令执行时对应的延时，delay后面表示具体的延时的时间，因为风量调节和座椅调节不冲突所以不需要延时，或者说可以延时0秒。再例如将指令7“座椅靠背向后调至最后”增加delay 6s，表示该指令执行时需要再延时6秒才能继续执行下一个指令，在这6秒内“座椅靠背向后调至最后”可以执行完毕，不和下一条座椅调整相关指令发生冲突。对应地，将指令8“座椅位置前后调至最后”增加delay3s，表示该指令执行时需要再延时3秒才能继续执行下一个指令。

由于车载场景的复杂性和特殊性，除了不同指令间的冲突外，还有更为重要的行车安全，需要详细的相应技术方案来支持和解决。

以座椅调节为例，服务器下发TPL脚本到客户端，客户端再解析服务器下发的TPL脚本。客户端执行指令前，会先判断指令是否是影响行车安全的指令，不属于影响行车安全的指令则直接执行。通常先根据多个车载系统原生(native)接口和/或预先设置的API(Application Programming Interface，应用程序接口)接口查询到的车辆状态，判断是否符合执行指令的安全条件，如果符合安全条件则执行指令。不符合，则跳过该条指令，继续下一条指令。

具体地，以场景2包括指令7“座椅靠背向后调至最后”为例，客户端在执行本条指令时，调用预设接口查询车辆是否在P档。如果查询到车辆在P档(停车档)，视为符合执行座椅调整的安全调节，则执行“座椅靠背向后调至最后”的指令；不在P档，则跳过该条指令，继续下一条指令。此处车辆在P档只是车辆中客户端执行的指令符合安全条件的具体示例，安全条件还可以是道路环境较为简单并且车辆低速行驶的状态，这个情况也适合执行一些车辆控制指令并且不影响行车安全，除上述示例外，本方案还可以选择其他安全条件来进行判断，在此不做限制。

进一步地，客户端执行指令的过程中，车辆中控平台可以配合显示每条指令的执行状态，给用户反馈。反馈可以是滚动显示文字的方式，也可以是其他反馈方式，在此不做限制，滚动文字反馈如：

“好的，安心休息一会儿吧”

“风量已设为2档”

“车辆不在P档，不调节座椅”

即跳过当前的待执行指令，包括：通过客户端向用户反馈当前的待执行指令已被跳过。通过“车辆不在P档，不调节座椅”的方式，向用户反馈当前的座椅调节指令已被跳过。

参照图5，示出了本发明的一种车载语音交互方法实施例的步骤流程图，该方法的执行主体是车辆，具体可以包括如下步骤：

S5，接收并转发用户的语音请求给服务器；其中，服务器上预先存储有根据接收的场景的自定义信息生成的脚本，自定义信息包括场景的触发信息和跟该场景对应的待执行指令。

S6，接收服务器根据触发信息确定该语音请求符合场景触发条件后下发的脚本。

S7，解析该脚本后在车辆中执行脚本中包括的待执行指令。

用户通过使用包括手机、平板电脑、PC或Mac等个人电脑、智能手表、虚拟现实眼镜或头显等不同类型的终端，藉由预先设置好的场景配置界面，实现场景配置的自定义。

如图2所示，图2是用户在手机上输入场景名称的图示之一。用户在终端上输入的场景的自定义信息包括场景的触发信息和跟该场景对应的待执行指令。用户还可以根据需要确定是否需要输入场景名称，该场景名称用来区别个性化场景，避免重复的场景产生冲突不可用的问题。

其中，触发信息包括若干条语音识别后用于触发场景的说法。如图3a和图3b所示，图3a和图3b是说法配置的示意图。通常至少配置一条说法用于触发场景，不能为空。但可以配置特定字数特定语种特定格式的多条说法，例如要求字数在100字以内，说法的语种为中文，格式要求为不支持标点符号和空格。配置多条说法可以给语音识别(ASR，AutomaticSpeech Recognition)一定的容错。本发明中，默认一条说法，并在输入框内提供字数提醒，让用户配置说法时感受到交互简洁和直观。

待执行指令包括流媒体控制指令、车辆控制指令中的一种或多种。

流媒体控制指令，具体指如TTS播报、url的音频播报、音乐播报、指令所带播报如导航声音播报、系统的提示音控制等和流媒体控制相关的指令。

车辆控制指令，具体指如座椅调节、空调调节、或车灯、摄像头等和车辆控制相关的指令。

上述都是车载语音交互场景下，语音助手可执行的操作内容。

语音交互过程中会使用TTS播报结合文字显示来给予用户反馈，本发明中，自定义信息还包括该场景对应的TTS播报文本和/或可在车辆显示部件上显示的显示文本。如图4所示，图4是用户设置TTS播报文本、显示文本和待执行指令的示意图。设置了TTS播报文本后，自定义信息的待执行指令将自动包括“TTS播报”的指令，该播报的内容即为TTS播报文本的内容。车辆显示部件可以是车辆中控的显示屏、仪表屏、位于方向盘上的小型显示屏、位于副驾的显示屏、位于后座的显示屏中的任意一个或多个，本方案中涉及的车辆显示部件不限于此，任何能够为车内用户提供显示文本功能的显示部件都属于本方案请求保护的范围，在此不再赘述。

用户通过终端编辑完的场景的自定义信息将通过终端藉由有线/无线的网络连接发送至服务器，再由服务器根据该自定义信息生成脚本，将该脚本和用户的车辆登录账号相关联，即将脚本和用户账号在数据库中设置为映射关系后存储在服务器上。

在整个场景的自定义信息的编辑过程中，用户所见即所得。用户配置的是流媒体控制指令或车辆控制指令，可以直接被用户感知；不需要用户了解软件/网络接口、服务器/服务器等概念，即可直观、简单地进行自定义场景的配置。

以前文的场景1为例，在S5中，用户上车向车内的语音助手说出“出发去上班”，车辆的中控平台可以作为客户端接收该语音请求并转发至服务器，服务器先判断语音请求是否和触发信息中的任意一条说法匹配，确认语音请求是和任意一条说法匹配后认定该语音请求符合场景触发条件，向客户端下发脚本。

在S6中，客户端接收下发的脚本，然后在S7中对脚本进行解析后，依次执行播报TTS、播报音频、将车内空调设为23度并将风量设为3档等操作。

类似地，以前文的场景2为例，当用户上车向车内的语音助手说出“我想睡一会儿”，车辆通过客户端和服务器交互后，在服务器确认语音请求是和说法2匹配后认定该语音请求符合场景触发条件，向客户端下发脚本。客户端接收下发的脚本并对脚本进行解析后，依次执行播报TTS、将车内空调风量设为2档，并完成座椅靠背和座椅位置的调节。

针对指令冲突等问题，本方案解决方式如下：

在场景1中，根据流媒体播放的特性易知，依序执行指令时会发生TTS播报当中，要播放音频的情况，届时指令1和指令2两个指令将产生冲突。本方案创新性地采用状态回调的方式，在上条TTS播报结束后，再播报下一条音频。

即S7这个步骤包括：

通过客户端解析该脚本后按时序执行第一流媒体控制指令，然后状态回调再执行第二流媒体控制指令。

以第一流媒体控制指令为TTS播报，第二流媒体控制指令为播放音频为例，车辆解析脚本后，通过客户端按时序执行TTS播报，确定“TTS播报”已执行完毕然后状态回调执行“播放音频”。即遭遇到流媒体播报间的时序冲突处理时，通过前一条播报结束后状态回调后继续播报下一条音频。

在场景2中，座椅调节是持续性的，所以指令7和指令8依次执行时，会出现座椅靠背调整的同时要向后调整，这样会造成指令冲突，座椅无法调节。本方案预先将该车辆控制对应的动作完成的时间存储在服务器，涉及到持续性车辆控制指令时，由服务器预判时间，并进行延时插入处理，高效地解决了延续性指令冲突的问题。

即待执行指令包括多个存在时序冲突的持续性车辆控制指令，该方法还包括：

通过客户端执行已插入延时的持续性车辆控制指令；其中，已插入延时的持续性车辆控制指令由服务器根据每个持续性车辆控制指令执行完毕所需的时间，对该持续性车辆控制指令增加延时插入处理后获得。

具体地，服务器读取用户配置的场景的自定义信息，通过类似“车控数据输入操作和操作完成时间的对应表格”等方式，对该持续性车辆控制指令增加延时插入处理。例如，对指令6“风量设为2档”增加delay 0s，delay表示该指令执行时对应的延时，delay后面表示具体的延时的时间，因为风量调节和座椅调节不冲突所以不需要延时，或者说可以延时0秒。再例如将指令7“座椅靠背向后调至最后”增加delay 6s，表示该指令在客户端执行时需要再延时6秒才能继续执行下一个指令，在这6秒内“座椅靠背向后调至最后”可以执行完毕，不和下一条座椅调整相关指令发生冲突。对应地，将指令8“座椅位置前后调至最后”增加delay 3s，表示该指令在客户端执行时需要再延时3秒才能继续执行下一个指令。

通过上述延时处理，客户端执行已插入延时的持续性车辆控制指令，解决了指令冲突的问题，使得座椅靠背调整和座椅位置要向后调整都能够不冲突地实现。

由于车载场景的复杂性和特殊性，除了不同指令间的冲突外，还有更为重要的行车安全，需要详细的相应技术方案来支持和解决。

以座椅调节为例，服务器下发TPL脚本到客户端，客户端再解析服务器下发的TPL脚本。客户端执行指令前，会先判断指令是否是影响行车安全的指令，不属于影响行车安全的指令则直接执行。如果是影响行车安全的指令，则根据多个车载系统原生(native)接口和/或预先设置的API(Application Programming Interface，应用程序接口)接口查询到的车辆状态，判断是否符合执行指令的安全条件，如果符合安全条件则执行指令。不符合，则跳过该条指令，继续下一条指令。此处车辆在P档只是车辆中客户端执行的指令符合安全条件的具体示例，安全条件还可以是道路环境较为简单并且车辆低速行驶的状态，这个情况也适合执行一些车辆控制指令并且不影响行车安全，除上述示例外，本方案还可以选择其他安全条件来进行判断，在此不做限制。

具体地，以场景2包括指令7“座椅靠背向后调至最后”为例，如果车辆以100km/h的速度高速行驶，调节座椅可能会影响行车安全，所以指令7“座椅靠背向后调至最后”属于影响行车安全的指令。客户端在执行本条指令时，调用预设接口查询车辆是否在P档。如果查询到车辆在P档(停车档)，视为符合执行座椅调整的安全调节，则执行“座椅靠背向后调至最后”的指令；不在P档，则跳过该条指令，继续下一条指令。

进一步地，客户端执行指令的过程中，车辆中控平台可以配合显示每条指令的执行状态，给用户反馈。反馈可以是滚动显示文字的方式，也可以是其他反馈方式，在此不做限制，滚动文字反馈如：

“好的，安心休息一会儿吧”

“风量已设为2档”

“车辆不在P档，不调节座椅”

即跳过当前的待执行指令，包括：通过客户端向用户反馈当前的待执行指令已被跳过。通过类似“车辆不在P档，不调节座椅”的反馈方式，向用户反馈当前的座椅调节指令已被跳过。

其中，本实施例和前文中服务器为动作主体的实施例基本相似，可以参见该实施例的部分说明。

本发明还提出一种车载语音交互方法，包括：

服务器接收场景的自定义信息；其中，自定义信息包括场景名称、场景的触发信息和跟该场景对应的待执行指令。

服务器根据该自定义信息生成脚本并存储在服务器上。

车辆通过客户端接收并转发用户的语音请求给服务器。

服务器接收并解析车辆客户端转发的用户的语音请求。

服务器根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本。

车辆通过客户端接收并解析服务器下发的脚本。

车辆通过客户端执行脚本中包括的待执行指令。

进一步地，车辆通过客户端执行脚本中包括的待执行指令，包括：

车辆通过客户端判断当前的待执行指令是否为影响行车安全的指令；

若当前的待执行指令是影响行车安全的指令，则客户端根据车辆的行驶状态判断车辆是否符合执行该待执行指令的安全条件，若符合安全条件则由客户端执行当前的待执行指令，否则由客户端跳过当前的待执行指令继续执行下一条待执行指令。

其中，服务器和车辆的完整交互过程和前文中服务器、车辆各自的实施例基本相似，可以参见这两个实施例的部分说明。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

参照图6，示出了本发明的一种车载语音交互装置实施例的结构框图，该车载语音交互装置设置于服务器上，具体可以包括如下模块：

第一接收模块，用于接收场景的自定义信息；其中，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

脚本生成模块，用于根据该自定义信息生成脚本并存储在服务器上；

第二接收模块，用于接收并解析车辆客户端转发的用户的语音请求；

脚本下发模块，用于根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本，以便客户端解析该脚本后在车辆中执行脚本中包括的待执行指令。

车载语音交互装置中，触发信息包括若干条语音识别后用于触发场景的说法。

车载语音交互装置中，待执行指令包括流媒体控制指令、车辆控制指令中的一种或多种。

车载语音交互装置中，自定义信息还包括该场景对应的TTS播报文本和/或可在车辆显示部件上显示的显示文本。

接收模块，具体用于接收终端发送的由用户在终端上输入的场景的自定义信息；根据该自定义信息生成脚本并存储在服务器上，包括：根据该自定义信息生成脚本，将该脚本和用户的车辆登录账号设置为映射关系后存储在服务器上。

待执行指令包括第一流媒体控制指令和第二流媒体控制指令在内的多个存在时序冲突的流媒体控制指令，脚本下发模块具体用于根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本，以便客户端解析该脚本后按时序先执行第一流媒体控制指令，然后状态回调再执行第二流媒体控制指令。

待执行指令包括多个存在时序冲突的持续性车辆控制指令，该车载语音交互装置还包括：

读取模块，用于读取所有持续性车辆控制指令；

延时插入模块，用于根据每个持续性车辆控制指令执行完毕所需的时间，对该持续性车辆控制指令增加延时插入处理；

存储模块，用于在自定义信息中存储已插入延时的持续性车辆控制指令。

参照图7，示出了本发明的另一种车载语音交互装置实施例的结构框图，具体可以包括如下模块：

接收模块，用于接收并转发用户的语音请求给服务器；其中，服务器上预先存储有根据接收的场景的自定义信息生成的脚本，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

接收模块，还用于接收服务器根据触发信息确定该语音请求符合场景触发条件后下发的脚本；

解析执行模块，用于解析该脚本后在车辆中执行脚本中包括的待执行指令。

车载语音交互装置中，触发信息包括若干条语音识别后用于触发场景的说法。

车载语音交互装置中，待执行指令包括流媒体控制指令、车辆控制指令中的一种或多种。

车载语音交互装置中，自定义信息还包括该场景对应的TTS播报文本和/或可在车辆显示部件上显示的显示文本。

其中，服务器包括：

服务器接收模块，用于接收终端发送的由用户在终端上输入的场景的自定义信息；

服务器脚本生成模块，用于根据该自定义信息生成脚本，将该脚本和用户的车辆登录账号设置为映射关系后存储在服务器上。

上述接收模块，具体用于由服务器先判断语音请求是否和触发信息中的任意一条说法匹配，并在确定语音请求是和任意一条说法匹配后，根据该语音请求符合场景触发条件的情况下发对应的脚本给客户端；通过客户端接收该脚本。

待执行指令包括第一流媒体控制指令和第二流媒体控制指令在内的多个存在时序冲突的流媒体控制指令，解析执行模块具体用于通过客户端解析该脚本后按时序执行第一流媒体控制指令，然后状态回调再执行第二流媒体控制指令。

待执行指令包括多个存在时序冲突的持续性车辆控制指令，该车载语音交互装置还包括：

延时执行模块，用于通过客户端执行已插入延时的持续性车辆控制指令；其中，已插入延时的持续性车辆控制指令由服务器根据每个持续性车辆控制指令执行完毕所需的时间，对该持续性车辆控制指令增加延时插入处理后获得。

解析执行模块还包括：

指令判断单元，用于解析脚本并判断当前的待执行指令是否为影响行车安全的指令；

指令处理单元，用于若当前的待执行指令是影响行车安全的指令，则根据车辆的行驶状态判断车辆是否符合执行该待执行指令的安全条件，若符合安全条件则执行当前的待执行指令，否则跳过当前的待执行指令继续执行下一条待执行指令。

指令处理单元，还用于通过客户端向用户反馈当前的待执行指令已被跳过。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

参照图8，本发明实施例还提供了一种服务器，包括：包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述车载语音交互方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

参照图9，本发明实施例还提供了一种车辆，包括：包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述车载语音交互方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现上述车载语音交互方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种车载语音交互方法、服务器、车辆、计算机可读存储介质，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (23)

1.一种车载语音交互方法，其特征在于，该方法包括：

接收场景的自定义信息；其中，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

根据该自定义信息生成脚本并存储在服务器上；

接收并解析车辆客户端转发的用户的语音请求；

根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本，以便客户端解析该脚本后在车辆中执行脚本中包括的待执行指令。

2.如权利要求1所述车载语音交互方法，其特征在于，触发信息包括若干条语音识别后用于触发场景的说法。

3.如权利要求2所述车载语音交互方法，其特征在于，待执行指令包括流媒体控制指令、车辆控制指令中的一种或多种。

4.如权利要求3所述车载语音交互方法，其特征在于，自定义信息还包括该场景对应的TTS播报文本和/或可在车辆显示部件上显示的显示文本。

5.如权利要求1所述车载语音交互方法，其特征在于，接收场景的自定义信息，包括：

接收终端发送的由用户在终端上输入的场景的自定义信息；

则根据该自定义信息生成脚本并存储在服务器上，包括：根据该自定义信息生成脚本，将该脚本和用户的车辆登录账号设置为映射关系后存储在服务器上。

6.如权利要求2所述车载语音交互方法，其特征在于，根据触发信息确定该语音请求符合场景触发条件，包括：

判断语音请求是否和触发信息中的任意一条说法匹配；

若语音请求是和任意一条说法匹配，则确定该语音请求符合场景触发条件。

7.如权利要求3所述车载语音交互方法，其特征在于，待执行指令包括第一流媒体控制指令和第二流媒体控制指令在内的多个存在时序冲突的流媒体控制指令，则向客户端下发脚本，以便客户端解析该脚本后在车辆中执行脚本中包括的待执行指令，包括：

向客户端下发脚本，以便客户端解析该脚本后按时序先执行第一流媒体控制指令，然后状态回调再执行第二流媒体控制指令。

8.如权利要求3所述车载语音交互方法，其特征在于，待执行指令包括多个存在时序冲突的持续性车辆控制指令，该方法还包括：

读取所有持续性车辆控制指令；

根据每个持续性车辆控制指令执行完毕所需的时间，对该持续性车辆控制指令增加延时插入处理；

在自定义信息中存储已插入延时的持续性车辆控制指令。

9.一种车载语音交互方法，其特征在于，该方法包括：

接收并转发用户的语音请求给服务器；其中，服务器上预先存储有根据接收的场景的自定义信息生成的脚本，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

接收服务器根据触发信息确定该语音请求符合场景触发条件后下发的脚本；

解析该脚本后在车辆中执行脚本中包括的待执行指令。

10.如权利要求9所述车载语音交互方法，其特征在于，触发信息包括若干条语音识别后用于触发场景的说法。

11.如权利要求10所述车载语音交互方法，其特征在于，待执行指令包括流媒体控制指令、车辆控制指令中的一种或多种。

12.如权利要求11所述车载语音交互方法，其特征在于，自定义信息还包括该场景对应的TTS播报文本和/或可在车辆显示部件上显示的显示文本。

13.如权利要求9所述车载语音交互方法，其特征在于，服务器上预先存储有根据接收的场景的自定义信息生成的脚本，包括：

服务器接收终端发送的由用户在终端上输入的场景的自定义信息；

服务器根据该自定义信息生成脚本，将该脚本和用户的车辆登录账号设置为映射关系后存储在服务器上。

14.如权利要求10所述车载语音交互方法，其特征在于，接收服务器根据触发信息确定该语音请求符合场景触发条件后下发的脚本，包括：

由服务器先判断语音请求是否和触发信息中的任意一条说法匹配，并在确定语音请求是和任意一条说法匹配后，根据该语音请求符合场景触发条件的情况下发对应的脚本给客户端；

通过客户端接收该脚本。

15.如权利要求11所述车载语音交互方法，其特征在于，待执行指令包括第一流媒体控制指令和第二流媒体控制指令在内的多个存在时序冲突的流媒体控制指令，则解析该脚本后在车辆中执行脚本中包括的待执行指令，包括：

通过客户端解析该脚本后按时序执行第一流媒体控制指令，然后状态回调再执行第二流媒体控制指令。

16.如权利要求11所述车载语音交互方法，其特征在于，待执行指令包括多个存在时序冲突的持续性车辆控制指令，该方法还包括：

通过客户端执行已插入延时的持续性车辆控制指令；其中，已插入延时的持续性车辆控制指令由服务器根据每个持续性车辆控制指令执行完毕所需的时间，对该持续性车辆控制指令增加延时插入处理后获得。

17.如权利要求9所述车载语音交互方法，其特征在于，解析该脚本后在车辆中执行脚本中包括的待执行指令，包括：

解析脚本并判断当前的待执行指令是否为影响行车安全的指令；

若当前的待执行指令是影响行车安全的指令，则根据车辆的行驶状态判断车辆是否符合执行该待执行指令的安全条件，若符合安全条件则执行当前的待执行指令，否则跳过当前的待执行指令继续执行下一条待执行指令。

18.如权利要求17所述车载语音交互方法，其特征在于，跳过当前的待执行指令，包括：

通过客户端向用户反馈当前的待执行指令已被跳过。

19.一种车载语音交互方法，其特征在于，该方法包括：

服务器接收场景的自定义信息；其中，自定义信息包括场景的触发信息和跟该场景对应的待执行指令；

服务器根据该自定义信息生成脚本并存储在服务器上；

车辆通过客户端接收并转发用户的语音请求给服务器；

服务器接收并解析车辆客户端转发的用户的语音请求；

服务器根据触发信息确定该语音请求符合场景触发条件，则向客户端下发脚本；

车辆通过客户端接收并解析服务器下发的脚本；

车辆通过客户端执行脚本中包括的待执行指令。

20.如权利要求19所述车载语音交互方法，其特征在于，车辆通过客户端执行脚本中包括的待执行指令，包括：

车辆通过客户端判断当前的待执行指令是否为影响行车安全的指令；

若当前的待执行指令是影响行车安全的指令，则客户端根据车辆的行驶状态判断车辆是否符合执行该待执行指令的安全条件，若符合安全条件则由客户端执行当前的待执行指令，否则由客户端跳过当前的待执行指令继续执行下一条待执行指令。

21.一种服务器，其特征在于，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1-8中任一项所述的车载语音交互方法的步骤。

22.一种车辆，其特征在于，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求9-18中任一项所述的车载语音交互方法的步骤。

23.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如权利要求1至18中任一项所述的车载语音交互方法的步骤。

Images