CN115705225A - 一种场景任务的执行系统 - Google Patents

Abstract

本申请提供一种场景任务的执行系统，包括：多个场景域，场景域中包括多个执行域以及多个公共键；执行域中包括至少一个待执行任务，待执行任务通过对至少一个作用域中的模态数据进行模态编排而生成；同一作用域中的各模态数据具有相同或相关联的数据类型；脚本解释器，用于从多个场景域中确定出目标场景域，并加载目标场景域的脚本，以生成第一场景脚本，目标场景域的脚本通过对目标场景域的各执行域以及各公共键进行逻辑编排而生成；场景编译器，用于编译第一场景脚本，以生成第二场景脚本；场景执行引擎，用于执行第二场景脚本，以实现目标场景。本申请的技术方案可以把多变的对话逻辑与不变的执行引擎做天然的隔离，方便对话逻辑的快速迭代。

Description

一种场景任务的执行系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种场景任务的执行系统。

背景技术

相关技术中，通过将对话逻辑通过硬编码的方式写入系统中，从而实现车端语音对话场景。例如，需要实现语音对话的导航，那么就将语音对话及车辆组件的执行逻辑写入系统中。如果执行逻辑有更新，那么需要更新整个系统。如果需要新增对话场景，那么需要再重新编排新的对话逻辑再写入系统，并更新系统。这种方式的灵活性很差，且不能够快速更新迭代。

发明内容

本申请实施例提供一种场景任务的执行系统，以解决相关技术存在的问题，技术方案如下：

一种场景任务的执行系统包括：

多个场景域，场景域中包括多个执行域以及多个公共键；其中，执行域中包括至少一个待执行任务，待执行任务通过对至少一个作用域中的模态数据进行模态编排而生成；其中，同一作用域中的各模态数据具有相同或相关联的数据类型；

脚本解释器，用于从多个场景域中确定出目标场景域，并加载目标场景域的脚本，以生成第一场景脚本，其中，目标场景域的脚本通过对目标场景域的各执行域以及各公共键进行逻辑编排而生成；

场景编译器，用于编译第一场景脚本，以生成第二场景脚本；

场景执行引擎，用于执行第二场景脚本，以实现目标场景。

在一种实施方式中，执行域包括：

第一执行域，包括至少一个第一待执行任务，第一待执行任务用于实现单轮对话业务；

第二执行域，包括至少一个第二待执行任务，第二待执行任务用于实现多轮对话业务；

第三执行域，包括至少一个第一待执行任务和至少一个第二待执行任务。

在一种实施方式中，公共键包括第三待执行任务，第三待执行任务根据相应场景域对第三待执行任务的复用次数而设置。

在一种实施方式中，公共键包括原子操作模块，用于封装车辆信号调用操作。

在一种实施方式中，公共键包括时间轴模块、自然语言生成模块、引导模块中的至少一个。

在一种实施方式中，作用域包括信号域，用于承载车辆感知设备的模态数据、环境感知设备的模态数据、可穿戴设备的模态数据。

在一种实施方式中，作用域包括服务域，用于封装系统内服务和/或系统外服务的调用细节。

在一种实施方式中，作用域包括参数域，用于存储场景域、执行域、待执行任务在跨区块调度运行时所传输的参数。

在一种实施方式中，作用域包括请求域、隐藏域和应答域，其中，请求域中的模态数据基于用户的单次语义输入生成，并由编码器编码为隐藏域可编排的数据；隐藏域用于承载与当前语义输入对应的对话上下文；应答域用于承载由解码器根据隐藏域中的模态数据解码生成的应答结果。

在一种实施方式中，作用域包括沙箱域，每一个沙箱域用于一个设备或一个用户的全局对话上下文。

上述技术方案中的优点或有益效果至少包括：可以把多变的对话逻辑与不变的执行引擎做天然的隔离，方便对话逻辑的快速迭代。

上述概述仅仅是为了说明书的目的，并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外，通过参考附图和以下的详细描述，本申请进一步的方面、实施方式和特征将会是容易明白的。

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请公开的一些实施方式，而不应将其视为是对本申请范围的限制。

图1为根据本申请实施例的执行系统中的任务编排原理示意图；

图2为根据本申请实施例的执行系统中的场景域的示意图；

图3为根据本申请实施例的执行系统的示意图。

具体实施方式

在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的精神或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的而非限制性的。

本申请实施提供一种场景任务的执行系统。该执行系统包括多个场景域、脚本解释器、场景编译器和场景执行引擎。

本申请实施例中，场景可以为车端对话场景，例如车控场景下的对话、驾驶场景下的对话、影音娱乐场景下的对话、导航场景下的对话等。其中，车控可以理解为对车身组件的控制，如打开车门、打开车窗、打开车灯、调节座椅等。驾驶场景可以理解为车辆驾驶相关的场景，如调节悬架、控制电子驻车制动系统(Electrical Park Brake，EPB)、换挡等。

可以为每个场景分别预设场景域。场景域中包括多个执行域以及多个公共键；其中，执行域中包括至少一个待执行任务，待执行任务通过对至少一个作用域中的模态数据进行模态编排而生成；同一作用域中的各模态数据具有相同或相关联的数据类型。

(1)作用域

作用域可以包括参数域(Param)、标签域(Tag)、信号域(Signal)、服务域(Service)、请求域(Request)、隐藏域(Mask)、应答域(Response)和沙箱域(Sandbox)等。

示例性地，参数域可以用于存储场景域、执行域、待执行任务等在跨区块调度运行时所传输的参数。标签域可以用于承载以数据为中心的用户大数据画像，如年龄、性别、爱好、嗜好、行为习惯等标签，是一种由若干标签构成用户标签池。标签域可以有多个，一个用户对应一个标签域，以缓存该用户的大数据画像。

信号域可以用于承载车辆感知设备的模态数据、环境感知(Vehicle toEverything，V2X)设备的模态数据、可穿戴设备的模态数据等，是一种可编排、可观察(监测或监听)、可调度的信号池。信号域可以有多个，一个设备对应一个信号域，用于缓存该设备的信号模态数据。

因此，信号域是海量信号的容器，信号的生产者(设备)不断的向信号池注册信号，信号的观察者(监听器/主动式对话/被动式对话)从信号域中订阅感兴趣的信号。其中，观察可以理解为监测或监听。例如：车速作为一种模态数据，车速不断变化，注册过该信号的执行域可以监测到车速变化，或者，在注册该信号时，预设车速变化的触发条件，当车速变化满足该触发条件时，该执行域就会被通知。

情景式对话和交互式场景脚本需调用系统内应用的应用程序接口(ApplicationProgramming Interface，API)，以及系统外的服务，而服务域用于封装服务的调用细节，编排服务返回的数据。其中，系统内应用可以包括导航、多媒体、收音机(FrequencyModulation，FM)、账号、数字车等，系统外服务可以为车企的场景服务，如极客世界，也可以为第三方服务，如人工智能(Artificial Intelligence，AI)服务irobot。

请求域可以用于被动式对话中，基于用户的单次语义输入，生成一个请求域。请求域的模态数据可以由编码器编码为隐藏域可编排的数据。隐藏域可以用于承载与当前语义输入对应的对话上下文，由对话和交互式场景按需复用或重新生成，而隐藏域与执行域是绑定的，每个执行域都会绑定一个隐藏域，用于承载该执行域的对话上下文。应答域可以用于承载由解码器根据与执行域绑定的隐藏域中的模态数据解码生成主动式对话、被动式对话、交互式对话、时间轴、监听器等业务的应答结果。沙箱域可以承载某一设备或某一个用户的全局对话上下文，用于隔离不同设备或不同用户的可编排数据，是一种超级上下文。

可以理解的是，在执行域的任务执行过程中会产生数据，这些数据作为对话上下文被存储于隐藏域中，并将该隐藏域与该执行域进行绑定，以记录此次对话。沙箱域中存储全局对话上下文，包括所有的对话上下文。

其中，用户的全局对话上下文存储于该用户的沙箱域中，每一次对话都会对应有一个对话上下文，该对话上下文存储于相应的隐藏域中。根据印迹可以从用户的沙箱域中搜索与该印迹对应的隐藏域。印迹由引擎生成，并与隐藏域存在一一绑定的关系，因此，印迹是引擎查找隐藏域的口令，根据印迹可以从当前用户的沙箱域中搜索与该印迹对应的隐藏域。

进一步地，沙箱域中还包括印迹队列，用于存储交互式执行域的准入口令，包含被动式和主动式，该队列存储的口令，可作为跨执行域或跨场景域跳转的参考和决策依据(跳入策略和跳出策略)。进一步地，沙箱域中还包括每个隐藏域的语义队列，用于存储被动语音输入的用户语义，该队列是有界的，结合印迹队列及隐藏域的语义队列，可作为跨执行域或跨场景域跳转的参考和决策依据(跳入策略和跳出策略)。

(2)执行域

待执行任务通过对至少一个作用域中的模态数据进行模态编排而生成。示例性地，如图1所示，通过模态编排可以决定如何运行作用域中的模态数据，运算符可以包括比较运算、包含运算、赋值运算等。各运算符可以供生成待执行任务时调用。在模态编排(运算)过程中，可以预设调用各作用域中的模态数据的符号，如参数域中的模态数据可通过(：)来调用，标签域中的模态数据可通过(！)来调用，信号域中的模态数据可通过(～)来调用，服务域中的模态数据可通过(@)来调用，请求域中的模态数据可通过(％)来调用，隐藏域中的模态数据可通过($)来调用，应答域中的模态数据可通过(^)来调用，沙箱域中的模态数据可通过(*)来调用。

待执行任务为基本的对话或业务场景单元，不支持独立执行，是构成执行域的最小单元。待执行任务可以为标准任务，即由条件组和执行组构成的任务，也可以为逻辑任务，即由if,elseif,else及foreach等逻辑条件构成的逻辑块任务，还可以包括简单任务，即通过键(key)快速找到赋值(value)，状态变为结束(END)或返回(RETURN)的任务。

从而，业务开发人员可以根据业务需求确定待执行任务，并根据该待执行任务的任务需求调用相应作用域中的模态数据，并进行运算，以生成该待执行任务。进一步地，对一个或多个待执行任务进行逻辑编排，可以生成一个执行域。

示例性地，如图1所示，逻辑编排可以包括引用(using)待执行任务或在执行域中内嵌(embed)待执行任务。根据逻辑编排形式不同，执行域可以包括第一执行域、第二执行域和第三执行域。

第一执行域包括一个或多个第一待执行任务，其中，第一待执行任务用于实现单轮对话业务，也就是说第一执行域可以理解为简单域，用于承载可执行的单轮对话或简单的主动业务场景或被动业务场景。

第二执行域包括一个或多个第二待执行任务，第二待执行任务用于实现多轮对话业务，也就是说，第二执行域可以理解为复杂域，用于承载可执行的多轮情景式对话，或复杂的交互式业务场景。

第三执行域包括一个或多个第一待执行任务以及一个或多个第二待执行任务，也就是说，第二执行域可以理解为聚合域，用于承载可执行的多轮、跨域及聚合情景式对话，或由若干单一的、孤立的、不连贯的能力点、业务点、业务片段、场景片段等聚合而成的交互式业务场景。

因此，执行域可以对一个待执行任务进行编排，也可以对多个待执行任务进行编排，即图1中，n为大于等于1的正整数。

(3)场景域

如图2所示，场景域中包括多个执行域以及多个公共键，其中的执行域可以为第一执行域(简单域)和/或第二执行域(复杂域)和/或第三执行域(聚合域)。

在一种实施方式中，公共键包括第三待执行任务，第三待执行任务根据相应场景域对第三待执行任务的复用次数而设置。示例性地，第三待执行任务可以为第一待执行任务，也可以为第二待执行任务。例如，根据某一场景域的业务需求，对某一第一待执行任务的复用次数超过了预设次数，那么可以在该场景域中，将该第一待执行任务作为公共键直接放置在该场景域中。如图2所示中的“任务(Atomic)”即为第三待执行任务。

在一种实施方式中，公共键可以包括原子操作模块，原子操作模块用于封装车辆信号调用操作。公共键还可以包括时间轴模块、自然语言生成模块、引导模块中的至少一个。

其中，通过调用时间轴模块，可以生成或执行带时间轴的任务。通过调用自然语音生成(NLG)模块，可以生成面向用户的对话结果。通过调用引导模块，可以生成面向用户的引导界面，如导航设置过程中的“下一步”。

公共键可以包括服务模块，通过调用服务模块可调用系统内应用的API以及系统外的服务。公共键可以包括信号模块，以监听与该场景域非常相关或使用频率超过预设频率的信号模态数据。

公共键可以包括跳转器，在跳转器中配置了其所在的场景域的重入策略，包括跳出策略和跳入策略。基于跳出策略，可以判断是否能够从该场景域跳出，即停止该场景域的任务执行过程。基于跳入策略，可以判断是否能够从进入该场景域。

另外，公共键还可以包括配置、模板、宏等，而每个场景域还对应有一个可解释的脚本。每个场景域的脚本通过对该场景域的各执行域以及各公共键进行逻辑编排而生成。

也就是说，场景域可以理解为由一类具有一定相关性的若干配置、模版、宏、信号、时间轴、编解码器、原子操作、任务、执行域等要素松散耦合在一起所形成的可编排的逻辑区域。

进一步地，脚本解释器用于从多个场景域中确定出目标场景域，并加载该目标场景域的脚本，以生成第一场景脚本。第一场景脚本为可编译的脚本。场景编译器用于编译第一场景脚本，以生成第二场景脚本，第二场景脚本为可执行的脚本。场景执行引擎用于执行第二场景脚本，以实现目标场景。

本申请实施例中，场景可以为车端对话场景，例如车控场景下的对话、驾驶场景下的对话、影音娱乐场景下的对话、导航场景下的对话等。其中，车控可以理解为对车身组件的控制，如打开车门、打开车窗、打开车灯、调节座椅等。驾驶场景可以理解为车辆驾驶相关的场景，如调节悬架、控制电子驻车制动系统(Electrical Park Brake，EPB)、换挡等。

示例性地，如图3所示，该系统可以从应用层获得各种数据，其中的应用层包括系统内应用，如导航、多媒体、FM、账号、数字车等，也可以包括系统外应用，如车企服务极客世界，还可以包括第三方服务，如人工智能服务irobot。数据的表现形式可以为时钟数据、用户数据(User)、服务数据(Service)、车辆数据(Vehicle)、环境感知数据(Environment)。系统具有时钟同步的能力、能力编排能力、原子操作能力等。

该系统包括模型层，用于全面获得车辆使用过程中的各项数据(如车辆数据、用户数据、环境数据等)，将其抽象化后(以模态数据的形式)分类(可读、可写、可读写)保存在作用域中。其中，M1、M2……Mn表示不同数据类型的模态数据，通过对模态数据的编排可生成待执行任务，对待执行任务的编排可生成执行域。其中，Gs1、Gs2……Gsn表示不同的待执行任务，Gm1、Gm2……Gmn表示不同的执行域。对执行域的编排可生成场景域，其中，S1、S2……Sn表示不同的执行域。

该系统还包括引擎层，即多模态AI感知引擎(AIMS)，包括脚本解释器、场景编译器、作业调度、场景执行引擎。

根据本申请实施的系统，把多变的对话逻辑(业务场景)与不变的执行引擎，做天然的隔离，对话逻辑的迭代与执行引擎之间互不影响，从而可以方便对话逻辑的快速迭代。

基于该系统，业务开发人员可以根据实际需求，对作用域中的模态数据进行编排，产生功能单元(待执行任务)；多个功能单元编排/组合形成相对完整的业务单元，再分类存放在执行域中。由此，业务开发人员可以方便地根据实际需求编排各种对话逻辑，以实现相应的对话场景。

相较于现有技术中的将对话逻辑硬编码写死或通过表单来配置，本申请实施例的执行方法中，由于对业务单元(对话逻辑)的设计过程进行了拆解、抽象和建模，可以得到基于XML的脚本语言，进而基于该脚本语言可在线快速开发迭代出适合用户使用习惯的人机对话过程，使得业务单元的设计可完全由开发者在线完成，并通过数加的热更新运营通道，快速部署到车机端。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

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

Claims (10)

1.一种场景任务的执行系统，其特征在于，包括：

多个场景域，所述场景域中包括多个执行域以及多个公共键；其中，所述执行域中包括至少一个待执行任务，所述待执行任务通过对至少一个作用域中的模态数据进行模态编排而生成；其中，同一作用域中的各模态数据具有相同或相关联的数据类型；

脚本解释器，用于从多个场景域中确定出目标场景域，并加载所述目标场景域的脚本，以生成第一场景脚本，其中，所述目标场景域的脚本通过对所述目标场景域的各执行域以及各公共键进行逻辑编排而生成；

场景编译器，用于编译所述第一场景脚本，以生成第二场景脚本；

场景执行引擎，用于执行所述第二场景脚本，以实现所述目标场景。

2.根据权利要求1所述的系统，其特征在于，所述执行域包括：

第一执行域，包括至少一个第一待执行任务，所述第一待执行任务用于实现单轮对话业务；

第二执行域，包括至少一个第二待执行任务，所述第二待执行任务用于实现多轮对话业务；

第三执行域，包括至少一个所述第一待执行任务和至少一个所述第二待执行任务。

3.根据权利要求1所述的系统，其特征在于，所述公共键包括第三待执行任务，所述第三待执行任务根据相应场景域对第三待执行任务的复用次数而设置。

4.根据权利要求1所述的系统，其特征在于，所述公共键包括原子操作模块，用于封装车辆信号调用操作。

5.根据权利要求1所述的系统，其特征在于，所述公共键包括时间轴模块、自然语言生成模块、引导模块中的至少一个。

6.根据权利要求1至5任一项所述的系统，其特征在于，所述作用域包括信号域，用于承载车辆感知设备的模态数据、环境感知设备的模态数据、可穿戴设备的模态数据。

7.根据权利要求1至5任一项所述的系统，其特征在于，所述作用域包括服务域，用于封装系统内服务和/或系统外服务的调用细节。

8.根据权利要求1至5任一项所述的系统，其特征在于，所述作用域包括参数域，用于存储所述场景域、所述执行域、所述待执行任务在跨区块调度运行时所传输的参数。

9.根据权利要求1至5任一项所述的系统，其特征在于，所述作用域包括请求域、隐藏域和应答域，其中，所述请求域中的模态数据基于用户的单次语义输入生成，并由编码器编码为所述隐藏域可编排的数据；所述隐藏域用于承载与当前语义输入对应的对话上下文；所述应答域用于承载由解码器根据隐藏域中的模态数据解码生成的应答结果。

10.根据权利要求9所述的系统，其特征在于，所述作用域包括沙箱域，每一个沙箱域用于一个设备或一个用户的全局对话上下文。

Images