CN107948231A - 基于场景的服务提供方法、系统和操作系统 - Google Patents

Abstract

本申请实施例提供了一种基于场景的服务提供方法、系统和操作系统，以提高操作的便捷性。所述的方法包括：获取各类型的场景服务数据，所述场景服务数据的类型至少包括信号类和服务类；采用不同类型的场景服务数据集成场景逻辑单元，所述场景逻辑单元与场景服务功能对应；通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例；所述场景逻辑单元用于定义场景服务功能，所述场景服务实例在设定参数下提供场景服务功能。

Description

基于场景的服务提供方法、系统和操作系统

技术领域

本申请涉及终端技术领域，特别是涉及一种基于场景的服务提供方法、一种基于场景的服务提供系统，以及一种基于场景服务的操作系统。

背景技术

随着终端技术的发展，越来越多的用户使用终端，而终端也提供了越来越丰富的功能服务。目前终端上提供的服务通常是通过APP(Application，应用程序)方式提供的，提供服务功能的入口通常设置在桌面上。

用户所需执行的各种服务功能通常是由不同APP提供的，例如聊天通过即时通讯APP提供，购物通过购物APP提供，用户在不同场景下需要开启不同的APP，具体场景功能的实现需要用户切换APP实现，操作不便捷。

发明内容

本申请实施例所要解决的技术问题是提供一种基于场景的服务提供方法，以提高操作的便捷性。

相应的，本申请实施例还提供了一种基于场景的服务提供系统、一种基于场景服务的操作系统，用以保证上述方法的实现及应用。

为了解决上述问题，本申请实施例公开了一种基于场景的服务提供方法，包括：获取各类型的场景服务数据，所述场景服务数据的类型至少包括信号类和服务类；采用不同类型的场景服务数据集成场景逻辑单元，所述场景逻辑单元与场景服务功能对应；通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例；所述场景逻辑单元用于定义场景服务功能，所述场景服务实例在设定参数下提供场景服务功能。

本申请实施例还公开了一种基于场景的服务提供系统，包括：收集模块，用于获取各类型的场景服务数据，所述场景服务数据的类型至少包括信号类和服务类；集成模块，用于采用不同类型的场景服务数据集成场景逻辑单元，所述场景逻辑单元与场景服务功能对应；绑定模块，用于通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例；所述场景逻辑单元用于定义场景服务功能，所述场景服务实例在设定参数下提供场景服务功能。

本申请实施例公开了一种基于场景服务的操作系统，包括：场景框架，依据获取的系统信号确定场景信息；场景解析引擎，运行所述场景信息对应的目标场景应用，所述目标场景应用至少包括一个场景逻辑单元，其中，所述场景逻辑单元采用不同类型的场景服务数据集成，所述场景服务数据的类型至少包括信号类和服务类；场景应用层，采用所述目标场景应用执行对应的操作。

与现有技术相比，本申请实施例包括以下优点：

在本申请实施例中，可以获取各种类型的场景服务数据，类型包括信号类和服务类，从而能够基于不同类型的场景服务数据集成场景逻辑单元，场景逻辑单元用于定义场景服务功能，使得能够基于接收的信号提供场景服务，然后可以通过场景逻辑单元和设定参数的绑定构成对应的场景服务实例，从而基于设定参数的场景服务功能，适配于各种设备以及用户需求提供场景化的自动服务，提高操作的便捷性。

附图说明

图1是本申请实施例的一种场景感知服务的主体框架示意图；

图2A是本申请实施例的一种场景感知服务的主体框架中各模块的交互示意图；

图2B是本申请实施例的一个场景应用的结构示意图；

图2C是本申请实施例的场景应用框架的结构示意图；

图2D是本申请实施例的场景应用的生命周期示意图；

图2E是本申请实施例的场景解析引擎管理示意图；

图2F是本申请实施例中Page间相互关系的示意图；

图2G是本申请实施例中的一种Page状态转换示意图；

图2H是本申请实施例中的另一种Page状态转换示意图；

图3是本申请实施例的一种场景感知服务系统的处理示意图；

图4是本申请的一种基于场景的应用操作方法实施例的步骤流程图；

图5是本申请实施例一种场景感知系统的服务环境示意图；

图6是本申请的一种基于场景的应用操作方法中场景开发实施例的步骤流程图；

图7是本申请一种示例的场景化服务处理示意图；

图8A、图8B是本申请的一种基于场景的应用操作方法中场景服务提供示例的示意图；

图9是本申请一种基于场景的应用操作装置实施例的结构框图；

图10是本申请一实施例提供的终端设备的硬件结构示意图；

图11是本申请另一实施例提供的终端设备的硬件结构示意图；

图12是本申请实施例中一种基于场景感知服务的操作系统示意图。

具体实施方式

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

本申请实施例中，智能终端指的是具有多媒体功能的终端设备，这些设备支持音频、视频、数据等方面的功能。本实施例中该智能终端具有触摸屏，包括智能移动终端如智能手机、平板电脑能、智能穿戴设备，也可以是具有触摸屏的智能电视、个人计算机等设备。该智能终端可以采用各种智能操作系统，如IOS、Android、云OS等。

本申请实施例可以应用于物联网(Internet of Things，IOT)技术，“物联网”指的是将各种信息传感设备，如射频识别装置、红外感应器、全球定位系统、激光扫描器等种种装置与互联网结合起来而形成的一个巨大网络。其目的是让所有的物品都与网络连接在一起，方便识别和管理。在万物互联的时代，用户的设备越来越多样化，包括有屏设备、无屏设备、家居设备、穿戴设备等等，本申请实施例在系统层面打造一种场景引擎的基础设施，提供场景感知和场景服务的能力，联通各种设备，并串联服务，以此给用户一种主动的、自动化的服务形态。

本申请实施例在常规的应用模型上扩展出一种新的应用开发模型，在系统层面打造场景引擎基础设施和场景开发框架，在系统底层提供场景感知能力，在动态语言(Javascript)基础上提供反应式编程模型(Reactive Programming)，并以统一的协议接入IOT设备。主体框架如下图1所示：

主体框架主要包括三个模块：Context Agent Host、Context Agent Framework和Context Agent Engine，上述三个模块的关系如图2A所示，Context Agent Engine管理上层场景应用(ContextAgentHost)，ContextAgentHost依赖于Context Agent Framework。其中：

ContextAgentHost指的是具备场景感知能力的应用容器，它继承于最基本的应用单元(Page)，开发者可以通过它组织一个应用场景，并作为一个应用在系统中运行。

Context Agent Framework指的是场景引擎应用框架，系统底层通过此框架给上层应用(ContextAgentHost)提供场景感知和场景服务能力。

Context Agent Engine指的是场景引擎系统服务，它是系统内置的独立服务，负责管理上层场景应用(ContextAgentHost)。

其中，ContextAgentHost包括各种场景应用如ContextAgentA、B、C。

Context Agent Framework包括：SignalStream、Subscription、Actuator、AgentInstance，上述各模块基于JavaScript实现处理逻辑。

Context Agent Engine包括：Agent Management(场景管理)、ExecutionScheduling(任务调度管理)、Security Gatekeeper(安全监控)、Stream Management(信号流管理)、Subscription Management(订阅管理)和Actuator Management(任务管理)。

开发者基于Context Agent Host开发各个场景应用，一个场景应用可以包括如下组成部分，如图2B所示：

Cloud App Package：是一个场景应用的整个应用包，可以通过domain来标识。

Page：是应用的最基本单元，Context Agent Host继承于它，代表一个具有场景化感知和服务能力的服务组件。

Page Cover：是应用中的视图模块，在场景服务中负责人机交互的部分。

Page Link：是应用之间交互的协议，通过Page Link可以唤起场景应用，也可以连接其他类型应用。

从而基于Cloud App Package下载到智能终端本地后，在感知响应应用场景后启动场景应用提供相应的服务，并且可以提供人机交互界面，便于用户进行控制。

本实施例中，Context Agent Framework给上层提供场景感知和服务能力，具体分为SignalStream、Subscription、Actuator、Agent和Agent Instance，以上各个组成部分之间的关系如图2C所示，其中：

Agent：是一个完整场景的逻辑单元，通过Agent来描述一个场景的感知以及逻辑处理。

Agent Instance：是一个Agent在具体设备和环境绑定后的实例。

SignalStream：代表信号流，它负责收集和处理各种设备或者系统信号，通过信号的各种操作，给上层应用提供场景感知的能力，Agent通过SignalStream组织关于场景感知的逻辑。

Subscription：代表在一个场景里对各种信号的订阅关系，通过Subscription来连接场景感知和服务。

Actuator：代表在场景服务里可以使用的具体执行任务，它是场景感知和逻辑处理后实际的服务任务，比如感知到天气闷热后，控制空调启动。

Context Agent Engine负责管理各个场景应用，并维护应用的生命周期，一个应用的生命周期如下图2D所示，其中：

Created：代表应用的已创建状态，表征用户目标机器上已安装了此场景应用。

Running：代表运行中状态，处于此状态的应用会按Agent组织的逻辑来运转。

Froze：代表冻结状态，处于此状态的应用不会占用系统资源，也不会运行场景服务，但可以被Context Agent Engine重新唤起和运行。

Disposed：代表完结和停止状态。

各状态间的流转由Context Agent Engine控制，如图2E所示，其中包括：依据Context Agent Engine和Agent Control UI创建Context Agent Host；Context AgentEngine控制Context Agent Host为冻结状态，以及恢复Context Agent Host的运行状态；Context Agent Engine控制Context Agent Host完结，并且DPMS停止服务。其中，DPMS(Dynamic Page Manager Service，动态页面管理服务)，是Page运行期实例的管理的服务端，一般是指服务进程。

在开发出Context Agent后，可以基于上述框架提供自动化的场景服务。例如可以在接收到信号后Context Agent Framework感知该信号对应的应用场景，并且确定该应用场景的处理逻辑，从而调用Context Agent Host运行场景应用进行处理。例如通过手机感知到气温超过30°，可以控制家中的空调启动运行，又如通过安保系统信号感知到家中已锁门无人，可以控制关闭家中的电灯等电器，防止资源浪费。

以下实施例均以YunOS为例，描述基于YunOS的Page管理，其中：

(1)Page

Page也可以称为服务组件，是对本地服务和远程服务的抽象，也即应用服务的基本单元，通过对数据和方法的封装，可以提供各种服务。一个服务场景可以包括多个Page。举例来说，一个Page可以是UI(用户界面)、拍照等服务，也可以是后台服务，如账户认证。运行态Page称为Page实例，是本地服务或远程服务的运行载体，可由DPMS创建(比如DPMS收到PageA发送的指向PageB的PageLink后可创建PageB的实例)、调度、管理，DPMS可维护Page实例的生命周期。

每个Page可以在YunOS中被唯一标识，比如可以使用URI(Uniform ResourceIdentifier，唯一资源标识符)对Page进行标识。URI可以通过各种方式生成，只要可以保证唯一性即可，本申请并不对URI的生成方式进行限制。

URI可以理解为一个地址链接，通过该URI可以唯一地确定出其对应的Page。例如，为了便于区分Page提供的服务，为该Page分配的URI中可以选择性地包括该服务的相关信息，例如：服务名称、服务内容、服务提供方等。

例如：A公司提供的日历服务，为其对应的Page分配的URI可以如下：

Page://calendar.a.com

其中：“Page://”用于区分该地址为Page对应的地址，以和其他类型的地址区分；“calendar”表示提供的服务名称；“a”表示该服务的提供方。

根据场景需求，一个Page可能需要创建多个Page实例，为便于区分同一Page的不同实例，可以进一步为每个Page实例分配唯一的Page ID进行标识，该标识可以在Page实例被创建时分配。Page实例是指Page的运行态，即本地或远程服务的运行载体，由DPMS(Dynamic Page Manager Service，动态Page管理服务)创建调度并管理其生命周期。进一步地，该Page ID可以被携带在信息实体PageLink中传递。

Page之间可以传递事件和/或数据，Page可以通过UI与用户进行交互，以提供服务，如图2F所示，PageA可以向PageB发送事件(Event)，并从PageB获取返回的数据(Data)，PageA可以通过UI与用户交互。其中，PageA可以提供服务A，PageB可以提供服务B。进一步地，PageA还可以以UI方式向用户提供显示界面，通过该界面为用户展示服务以及接收用户的各种输入，PageB可以主要在后台运行，可以为其他Page提供服务支持。

Page可被创建和销毁。Page从创建到销毁有三种状态：

Created(建立)状态：表示Page被创建，Page被创建(即被实例化)后首先进入Created状态；

Running(运行)状态：Page被激活后进入Running状态，Running状态下的Page之间能够传递事件和/或数据，以及能够处理其他Running状态的Page传递来的事件和/或数据；

Stopped(停止)状态：Page被去激活后进入Stopped状态，Stopped状态下的Page不能够与其他Page进行事件和/或数据的传递。

Page可在上述不同状态之间进行转换，并在转换的时接收到生命事件通知，该生命事件通知用于指示Page转换后的状态。其中，Page的状态转换以及生命事件通知可以由DPMS控制。图2G示出了Page状态转换示意图，如图2G所示，当Page从Created状态进入Running状态时，会收到onStart事件，当Page从Running状态进入Stopped状态时，会收到onStop事件，Page在Running状态下，可以通过onLink接口接收到其他Page发来的Pagelink。。其中，onStart事件是用于指示Page开始进入Running状态的生命事件通知，onStop事件是用于指示Page开始进入Stopped状态的生命事件通知。

若Page具有用UI(用户界面)，则Running状态可以扩展成为以下三种状态中的一种：

Hided(隐藏)状态：Hided状态下的Page能够在后台运行，对于用户来说不可见；

Showed-inactive(可见地非交互)状态：Showed-inactive状态下的Page对于用户来说可见，但是不响应用户输入；

Showed-active(可见地交互)状态：Showed-active状态下的Page对用户来说可见，并且可以响应用户输入。

例如：PageA为全屏窗口，PageB为非全屏窗口，当PageB在PageA之上显示时，PageA是Showed-inactive状态，PageB是Showed-active状态。

通过生命事件通知，Page可在上述不同状态之间进行转换。图2H示出了Page状态转换示意图，如图所示，Hided状态下的Page收到onShow事件后进入Showed-inactive状态，Showed-inactive状态下的Page收到onHide事件后进入Hided状态；Showed-inactive状态下的Page收到onActive事件后进入Showed-active状态，Showed-active状态下的Page收到onInactive事件后进入Showed-inactive状态。

(2)PageLink

PageLink是Page之间流转的信息实体，可以在Page间传递信息，例如，事件和/或数据等。具体传递数据可以使用设定的API(Application Programming Interface，应用程序编程接口)，YunOS以此为基础记录服务组件之间的关联关系。PageLink可以指定目标Page的URI，并且可以包含事件、数据、服务等信息中的一种或多种。

Page通过PageLink以更加灵活的方式的组合，可以实现丰富的服务场景。

(3)DPMS

DPMS是Dynamic Page Manager Service的英文简称，中文称为动态Page管理服务，可以被看作是服务组件管理实体，是一种系统服务。DPMS可以管理Page生命周期以及运行时调度，Page从创建到销毁的生命周期管理，以及Page间经PageLink的交互都可以通过DPMS实现。

基于以上描述，本申请实施例提供了一种服务组件管理系统，该系统可包括服务组件管理实体以及N个(N为大于1的整数)服务组件。基于该架构，服务组件管理实体可接收一个服务组件(为方便描述，此处称为第一服务组件)发送的指向另一个服务组件(为方便描述，此处称为第二服务组件的信息实体)，并发送该信息实体给第二服务组件进行处理。

基于上述架构和概述，本申请实施例可以结合上述架构论述场景感知服务的方法，感知用户所需的场景，为用户提供所需的各种服务。

参照图3，示出了本申请实施例的一种场景感知服务系统的处理示意图。

本申请实施例可以构建一个场景感知服务系统，可以开发场景服务所需的各种场景服务数据，包括信号、服务以及逻辑处理等，从而可以收集各种场景服务数据，从而丰富系统中信号和服务，为场景服务的开发提供更加丰富的数据基础。从而可以采用不同类型的场景服务数据集成场景逻辑单元，该场景逻辑单元用于定义场景服务功能，即场景逻辑单元中定义了其对应应用场景所需的系统信号以及服务信息，但是该场景逻辑单元是通用的服务单元，具体执行的设定参数是未限定的，其中场景逻辑单元可以设置分别适配于不同设备的代码等信息，依据实际运行设备确定，还可以依据用户具体需求场景逻辑单元具体执行服务的相关参数，例如空调自动运行场景是室温超过30°才运行，电灯是安防系统确认家中无人才自动关闭等。在集成开发出场景逻辑单元后，可以通过对场景服务数据和设定参数的绑定，构成再设备中执行的场景服务实例，从而能够为用户提供场景化服务。则该场景服务实例提供基于设定参数的场景服务功能，即在某一设备运行时在何种用户需求状态下提供场景服务等。

基于上述架构和概述，本申请实施例可以结合开发的场景逻辑单元感知用户所需的场景，为用户提供所需的各种服务。在开发出Context Agent后，可以基于上述框架提供自动化的场景服务。例如可以在接收到信号后Context Agent Framework感知该信号对应的场景信息，并且确定该场景信息的处理逻辑，从而调用Context Agent Host运行场景应用进行处理。例如通过手机感知到气温超过30°，可以控制家中的空调启动运行，又如通过安保系统信号感知到家中已锁门无人，可以控制关闭家中的电灯等电器，防止资源浪费。

本申请实施例在系统层面打造从网络侧(云端)到设备侧的场景服务开放平台，接入各种设备的系统信号和服务，并提供一整套开放和编程模型，各种开发者(信号收集、设备控制、场景服务集成)都能接入系统平台，并互相集成。从而给用户提供一种主动的、自动化的服务形态。

其中基于场景的应用操作过程可以通过如下步骤实现：

参照图4，示出了本申请的一种基于场景的应用操作方法实施例的步骤流程图，具体可以包括如下步骤：

步骤402，获取各类型的场景服务数据。

开发者可以基于设备、用户需求等开发各种场景服务，生成对应的场景服务数据，然后将场景服务数据上传到系统。从而系统可以收集开发的各类型的场景服务数据，本申请实施例的场景服务可以基于信号感知应用场景并提供相应的服务，因此所述场景服务数据的类型至少包括信号类和服务类，从而基于信号和服务提供场景化服务。

其中，智能终端等设备可以提供系统信号，但是仅依据设备的系统信号能够提供的场景服务比较限定，因此本实施例可以收集开发的信号类场景服务数据如系统信号，对于系统信号的开发可以包括定义信号的类型、信号名称以及信号的来源等各种信息，还可以收集设备、操作系统等提供的标准系统信号，从而丰富系统信号的来源，便于开发场景化服务。并且开发者还可以开发能够提供的服务功能信息，该服务功能信息用于定义为用户提供的该服务。

步骤404，采用不同类型的场景服务数据集成场景逻辑单元。

通过不同类型的场景服务数据定义了能够为用户提供场景服务的各种基础数据，从而可以采用不同类型的场景服务数据集成场景逻辑单元，所述场景逻辑单元与场景服务功能对应，从而能够为用户提供场景服务。例如上述收集了定义的系统信号以及提供的服务等各类型的场景服务数据，将信号类和服务类的场景服务数据进行集成，可以得到场景逻辑单元，该场景逻辑单元定义了场景服务功能，即针对某种系统信号提供相应的场景服务。

步骤406，通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例。

上述场景逻辑单元定义了通用的场景服务功能，但是运行环境以及使用用户的区别会导致该场景逻辑单元对应场景提供的服务存在一定区别，例如有些用户在室温超出30°开启空调，而有些用户在室温超出33°开空调，又如在iOS系统和Android系统的处理逻辑不同，因此本实施例还基于设定参数配置场景逻辑单元，将场景逻辑单元和设定参数进行绑定，生成相应的场景服务实例Agent Instance。从而场景服务实例Agent Instance对应确定上层应用的服务组件Page，在设备中运行该Page实例来提供服务功能。

其中，不同设备的操作系统、处理逻辑等存在区别，因此该场景逻辑单元中可以配置针对不同设备的处理信息，例如针对不同设备的代码、处理逻辑以及关联信息等，从而针对不同的设备运行不同的代码、执行不同的处理逻辑、调用不同的关联信息，因此可以基于设备配置设备参数作为设定参数。而不同用户在安装应用后，由于用户需求不同可以设置不同的用户参数，用户参数作为设定参数之一也可以设置场景逻辑单元，从而得到场景服务实例。

综上，可以获取各种类型的场景服务数据，类型包括信号类和服务类，从而能够基于不同类型的场景服务数据集成场景逻辑单元，场景逻辑单元用于定义场景服务功能，使得能够基于接收的信号提供场景服务，然后可以通过场景逻辑单元和设定参数的绑定构成对应的场景服务实例，从而基于设定参数的场景服务功能，适配于各种设备以及用户需求提供场景化的自动服务，提高操作的便捷性。

本申请实施例可以基于上述架构搭建开放的生态开发、集成、服务环境，如图5所示。

其中包括：设备和服务平台(Devices and Services)，系统服务平台(YunOS IoTinfra)和网络侧云端的应用平台(Cloud APP Platform)，系统服务平台中可以配置信号平台(Signal Platform)和服务功能平台(Actuator Platform)。在开发出应用(ContextAgent)后可以上传到应用平台中。

其中，Cloud App Platform、Context Agent是场景解析引擎运行的基础模块。业务逻辑由Agent模块来组织，场景感知由Signal模块来处理，场景服务由Actuator模块来处理，开放平台要构建Agent Platform、Signal Platform、Actuator Platform分别将Agent、Signal和Actuator开放出来，服务于Context Agent Developer、Signal Developer和Actuator Developer，并集成Device Maker和Service Developer提供的系统基础服务。

因此，信号开发者Signal Developer可以开发系统信号的相关信息，从而可以收集系统信号到信号平台；任务开发者Actuator Develop可以开发服务功能信息，定义提供的服务功能，可以收集服务功能信息到服务功能平台；应用开发者Context AgentDeveloper可以开发应用的业务逻辑，从而服务开发者Service Developer基于系统进行应用的开发，基于上述系统信号、服务功能信息、业务逻辑等开发场景应用，得到场景逻辑单元，设备制造商Device Maker可以在设备中配置该场景逻辑单元。

基于上述环境可以开发场景应用，并且基于场景应用为用户提供服务。

其中，不同开发者可以开发不同类型的场景服务数据，因此收集开发的各类型的场景服务数据，具体可以接收开发后上传的各类型的场景服务数据，按照所属类型对场景服务数据进行分类存储。即在接收到场景服务数据后可以确定该场景服务数据的类型，从而按照类型对场景服务数据进行分类存储。本实施例中类型包括：信号类、服务类逻辑类，对应信号类为系统信号、服务类为服务功能信息、逻辑类为场景逻辑信息。预先可以设置各类型的场景服务平台，其中，所述场景服务平台包括：信号平台和服务功能平台，还包括应用平台，可以将场景逻辑信息存储到云端，将系统信号存储到所述信号平台，服务功能信息存储到所述服务平台服务功能平台。

针对Signal Platform：Signal Developer基于Signal Platform开发各种信号接入模块，比如手环的记步数据接入，空气净化器的空气质量数据接入等等。可以通过以下格式来描述和暴露一个系统信号的实体，其中：naming-authority：是信号命名空间，用于逻辑组织同一类型的信号，可以选填，也可以选择默认值；signal-name：是信号的名称，用于标识一个信号；signal-specific-part：是信号的具体参数。基于上述格式可以定义各种信号，例如设备上的耳机信号，指定设备上的耳机插拔信号，航班订票信息流，恶劣天气报警信号等。

一旦开发者将信息通过以上格式暴露信号服务，在Agent里即可通过以下API取得信号，从而通过以上方式的开放，开发者可以在信号收集这个细分领域开发垂直化服务，有利于各种设备的接入，很好的扩大场景信号覆盖的范围。

针对Actuator Platform：Actuator Developer基于Actuator Platform开发各种在场景中可以触发的动作和服务即服务功能信息，比如向通知栏发通知提醒，打开智能空调等等。通过以下格式来描述和暴露一个动作的实体：naming-authority：是服务动作的命名空间，用于逻辑组织同一类型的服务动作，可以选填，也可以选择默认值；actuator-type-name：是服务动作的名称，用于标识一个服务动作；actuator-type-specific-part：是服务动作的具体参数。例如智能汽车的媒体中心、编号为mypepper的机器人、微博、点评的订餐服务等。

针对Agent Platform：Agent Developer是基于Agent Platform利用SignalPlatform和Actuator Platform提供的能力，开发一个个服务于用户的场景。通过场景引擎基础框架提供的Reactive运行环境，Agent Developer基于Javascript脚本语言编写业务逻辑，通过Agent Platform发布Agent。Agent需要通过以下格式来标识：agent-identity：是具体一个agent的标识，通过guid来描述，并且可以规定guid的格式。

在开发场景逻辑单元时，可以依据系统信号和服务功能信息确定应用场景，集成所述应用场景对应的场景逻辑单元，即配置每个应用场景下所需的系统信号以及对应提供的服务功能，从而采用系统信号和服务功能信息集成该应用场景对应的场景逻辑单元。其中，集成所述应用场景对应的场景逻辑单元，包括：依据所述应用场景确定场景逻辑信息；采用所述场景逻辑信息集成系统信号和服务功能信息，生成对应的场景逻辑单元。

通过上述标识，开发者可以唯一标识一个Agent，便于在场景服务中直接引用。发布Agent需要在应用的配置单(manifest)中进行声明。在Agent Developer发布Agent时，具体的机器人型号和ID是未知的，即设备以及用户是未知的，可以通过通用声明标识，然后用户在实际使用中进行参数绑定。即用户选择和使用某个Agent Developer发布的Agent时，会根据实际的环境绑定具体的设定参数，Agent通过绑定具体的参数，转变为AgentInstance，供用户实际使用。

本申请实施例中，Agent是整个场景开发的核心实体，描述了一个场景的逻辑单元，通过Signal和Actuator的接入和整合，开发者可以很方便地监听各种信号并调用各种场景服务，从而集成各种设备的能力，给用户提供主动的、自动化的场景服务。

通过以上的动作服务描述，可以在Agent中引入到动作服务的实体，并通过起提供的API，进行实际的服务动作。通过以上方式的开放，开发者可以在服务动作这个细分领域开发垂直化服务，有利于各种场景服务能力的接入，很好的扩大服务能力能覆盖的范围。

参照图6，示出了本申请的一种基于场景的应用操作方法中场景开发实施例的步骤流程图，具体可以包括如下步骤：

步骤602，接收开发后上传的各类型的场景服务数据。

步骤604，将所述系统信号存储到所述信号平台，以及将所述服务功能信息存储到所述服务平台服务功能平台。

开发者在开发出场景服务数据后可以上传，平台在接收到场景服务数据后可以确定该数据的类型，包括系统信号、场景功能信息、场景逻辑信息等，然后可以将系统信号存储到所述信号平台，将所述服务功能信息存储到所述服务平台服务功能平台，将场景逻辑信息存储到云端或者存储到场景逻辑平台。

步骤606，依据系统信号和服务功能信息确定应用场景。

步骤608，依据所述应用场景确定场景逻辑信息。

步骤610，采用所述场景逻辑信息集成系统信号和服务功能信息，生成对应的场景逻辑单元。

在开发场景逻辑单元时，可以依据信号平台的系统信号和服务功能平台的服务功能信息，可以基于系统信号和服务功能信息确定要开发的应用场景，然后确定该应用场景下对应场景逻辑信息，然后采用场景逻辑信息对系统信号和服务功能信息进行集成，设置信号对应服务的处理逻辑，生成对应的场景逻辑单元。

步骤612，依据设备参数确定设备类型，获取与所述设备类型对应的场景逻辑单元。

步骤614，依据设定参数设置对应的系统信号和服务功能信息，构成对应的场景服务实例。

场景逻辑单元规定了通用的对于系统信号的场景服务，而没有设置具有用户使用的相关信息，因此可以将场景逻辑单元和设定参数进行绑定得到场景服务实例，设定参数包括设备参数和/或用户参数，设备参数是设备的软、硬件参数，例如硬件的芯片、处理器等，软件的操作系统等参数，用户参数包括依据用户需求设定的各种参数。因此可以依据设备参数确定设备类型，获取与所述设备类型对应的场景逻辑单元，然后按照设定参数设置对应的系统信号和服务功能信息，即基于设备参数设置该设备对应的系统信号，以及服务功能信息，也可以依据用户需求设置该用户所需的系统信号，以及服务功能信息，从而得到相应的场景服务实例。

例如A用户在安防系统检测到家中无人时关闭所有电灯，而B用户在在安防系统检测到家中无人时仅开启门口等廊灯。

在开发出场景逻辑单元并且集成场景服务实例后，可以采用场景服务实例为用户提供场景服务。在接收系统信号进行信号的分发，然后基于系统信号感知应用场景，运行应用场景对应的场景服务实例。

因此本实施例可以采用依据所述场景服务平台生成信号路由，可以基于系统平台收集的系统信号和服务功能平台收集的服务功能信息确定信号对应的服务功能，所述信号路由用于分发接收的系统信号。

本申请实施例设置了场景关联参数，该场景关联参数提供感知场景逻辑处理数据，所述场景关联参数包括以下至少一类：知识图谱类、逻辑判断类、算法处理类。因此可以依据所述场景服务平台和场景关联参数生成场景感知引擎，所述场景感知引擎用于决策系统信号对应的应用场景，从而该场景感知引擎可以基于知识图谱、逻辑判断以及算法等感知应用场景。其中，信号路由、可以场景感知引擎可以关联有订阅关系Subscription，从而确定订阅该系统信号的应用场景以及服务功能。本实施例中还设置有场景决策信息，该场景决策信息用于决策应用场景对应运行的场景服务实例。

从而本实施例中可以采用信号路由进行系统信号的分发，采用场景感知引擎感知系统信号的应用场景，然后采用决策该应用场景确定对应的场景应用。如图7所示，为一种示例的场景化服务处理示意图。

其中，按照来源划分系统信号包括以下至少一类：设备信号、用户信号和服务信号。其中，设备信号指的是来源于设备处理的系统信号，例如传感器信号如位置记录，无线信号如WiFi连接记录、蓝牙连接记录，设备硬件信号如内存使用状态，外设连接信号如耳机插入状态等。用户信号指的是来源于用户交互的系统信号，例如应用使用记录如应用打开记录、浏览器浏览记录、淘宝活动记录等，还可以包括O+C使用记录，扫一扫记录，用户反馈记录，短信、邮件记录，人机对话记录，输入法记录等。服务信号指的是来源于网络服务侧的系统信号，例如天气预警信号、股票动态信号、航班状态信号、轻服务数据更新信号等。

场景感知引擎可以基于用户需求推理用户偏好的应用场景，得到特定用户的应用场景。其中，可以基于知识图谱、逻辑判断以及算法等感知，例如知识图谱包括世界知识图谱、用户知识图谱、应用知识图谱等。

场景化服务决策系统可以采用场景决策信息进行决策，基于推荐引擎、场景解析引擎、搜索引擎进行决策，以及基于场景调节引擎进行综合调整和运行策略调整来调整决策，最终实现对场景服务实例的决策。然后对于决策结果、感知的应用场景可以基于各种编程语言、应用程序、系统服务以及周边信息等唤起对应的服务，即唤起场景应用以及场景服务实例等，从而为用户提供场景服务的动作。还可以基于用户的反馈更新场景感知引擎。

具体提供场景服务的过程如下：

参照图8A，示出了本申请的一种基于场景的应用操作方法中场景服务提供实施例的步骤流程图，具体可以包括如下步骤：

步骤802，采用所述信号路由确定接收的系统信号对应的服务功能信息。

步骤804，采用确定的服务功能信息查询场景感知引擎，确定对应的应用场景。

步骤806，依据所述应用场景调用对应的场景服务实例。

对于接收的系统信号，可以采用信号路由进行系统信号的分发，确定系统信号对应的服务功能信息，再采用确定的服务功能信息查询场景感知引擎，感知对应的应用场景，可以信号路由和场景感知引擎查询订阅关系，确定系统信号对应的应用场景，然后调用该应用场景调用对应的场景服务实例，当检测到本地未下载所述场景服务实例后，下载所述场景服务实例，即当本地不存在该场景应用实例时，可以向服务端请求来获取场景场景逻辑单元并绑定设定参数得到对应的场景服务实例。

其中，依据所述应用场景调用对应的场景服务实例，包括：依据场景决策信息确定所述应用场景对应的场景服务实例；运行所述场景服务实例对应应用单元执行对应的场景服务操作。在调用场景服务实例时，可以依据场景决策信息基于各种策略和引擎确定所述应用场景对应的场景服务实例，然后运行该场景服务实例对应的场景应用，采用场景应用的场景逻辑单元执行相应的操作。

基于上述主体框架，各设备以及设备交互执行基于场景的应用操作过程的一种示例如下：设备的Context Agent Framework中SignalStream收集和处理各种设备或者系统信号，然后查询各种信号的订阅关系Subscription，通过Subscription来连接场景感知和服务，然后基于逻辑单元Agent确定一个场景的感知以及逻辑处理，确定出场景感知和逻辑处理后实际的服务任务Actuator，再执行具体设备和环境绑定后的实例Agent Instance。基于Agent Instance可以依据应用之间交互的协议Page Link可以唤起上层的场景应用Context Agent，运行Context Agent中服务组件Page执行该应用场景的操作。其中，当需要用户交互时通过视图模块Page Cover显示应用界面，从而Page Cover执行该场景应用的人机交互。并且Page Link还可以连接其他类型应用，便于实现多设备、多应用的交互场景操作。在场景感知且提供服务的过程中，采用场景引擎Context Agent Engine管理ContextAgentHost，即管理上层场景应用，维护场景应用的生命周期。可以结合各种信号管理、维护场景应用在各状态将流转。

其中，场景信息用于确定应用场景的处理逻辑，一个应用场景对应一个服务功能，因此可以采用场景信息标识一个服务功能的处理逻辑，包括所需要的系统信号、逻辑处理任务，对应调用的场景应用等。系统信号指的是设备中数据的载体，该系统信号可以包括设备数据和设备接收数据，设备数据包括设备内的软硬件数据，如设备软件交互的指令数据、传感器信号、各种接口数据等，设备接收数据包括设备接收的各种指令数据、硬件、接口数据等。例如设备接收到插入耳机的接口数据可以调用播放应用播放歌曲等音频数据，又如设备感知到外部的蓝牙信号则连接对应的蓝牙耳机或其他蓝牙设备，又如设备感知到天气应用的温度数据，可以通知空调开启等。从而能够对设备的各种数据进行接收并感知相应的应用场景来提供服务功能给用户。

从而设备可以接收到各种系统信号，例如来电信号、各种传感器的信号等，在接收到系统信号后，可以采用该系统信号感知应用场景，即每个场景应用所支持的应用场景都订阅有相关的系统信号，例如空调控制场景订阅了温度信号、电灯系统订阅了亮度信号、监控信号等。然后运行该应用场景对应的目标场景应用，其中，目标场景应用至少包括一个场景逻辑单元page。再采用该目标场景应用执行所述应用场景对应的操作，例如调用空调开冷风27°，又如关闭电灯等。

本申请实施例可以应用于物联网技术，可以是物理网中系统设备对自身的控制，或者对其他系统设备的控制。可以接收、整合物联网的各种系统信号，然后感知系统信号的场景并进行处理。例如家庭网络中灯光系统、安防系统的系统信号、各种智能家居设备、智能厨电设备的系统信号等，上述系统信号可以通过服务器统一分发，例如采用智能手机监控家庭网络，则可以将家庭网络中的各种系统信号发送给智能手机，然后采用智能手机感知系统信号对应的应用场景并进行分发和处理。本实施例可以开发系统信号的各种应用场景，从而可以整合各种设备的应用场景，通过设备对自身或是其他设备进行控制，构成统一开发、控制、管理、维护的系统平台，便于自动化执行场景需求。

预先将系统信号和应用场景进行绑定，采用订阅关系记录每个应用场景订阅的系统信号。因此设备在接收到系统信号后，可以查询订阅关系确定出订阅该系统信号的至少一个应用场景。即采用所述系统信号查询订阅关系，确定与所述系统信号具有订阅关系的至少一个应用场景。其中，该设备可以是各种物联网设备，如灯光系统的设备、各种智能设备等。本申请实施例中，每个应用场景可以订阅一个或多个系统信号，并且可以设置其他的场景条件，例如系统信号的门限等，因此还可以按照应用场景的场景条件，对所述应用场景进行筛选。即在确定订阅该系统信号的一个或多个应用场景后，还可以判断是否接收到该应用场景订阅的其他系统信号，以及该应用场景对应其他场景条件是否满足。

例如智能手机若接收到气温信号，且气温信号对应温度大于30°，符合开启空调冷风的应用场景，可以控制空调开启冷风以及设定问题等。又如智能手机导航路线且接收到车辆启动的信号，可以开启车载系统并对之前手机导航的路线进行导航。又如接收到智能手机插入耳机的系统信号，可以在智能手机中运行播放应用进行歌曲音频数据的播放。

即可以整合接收的一个或多个系统信号，从而确定出符合该系统信号的应用场景，例如针对家庭网络，在接收到温度超出预设温度的信号、电视开启信号后，判断用户在电视所在的客厅看电视，因此可以开启客厅的空调。又如检测到家中烤箱正在运行的系统信号，以及煤气灶和抽油烟机运行的系统信号，可以判断出该用户正在做饭，可以采用智能冰箱的操作系统播放音乐。即基于一个或多个系统信号判断订阅的应用场景，从而自动执行在该应用场景下的操作，给用户提供自动化的服务。

然后依据设备确定所述应用场景对应目标场景应用，载入运行所述目标场景应用。对于同一应用场景，不同设备运行的场景应用也可以相同或不同，例如针对温度超过30需要降温的应用场景均是开启空调冷风，但是空调的型号以及冷风温度等可以不同，具体的在家庭网络中启动家用空调降温，而在用户开车时启动车用空调降温，对于办公环境也可以调整办公室的中央空调。

在目标场景应用的过程中，还可以显示场景应用的人机交互界面即显示所述目标场景应用的应用界面，以告知用户应用场景对应的操作，以及与用户进行交互。因此可以在该应用界面接收用户的操作信息，即接收用户在应用界面执行操作对应的操作信息，并且依据该操作信息进行反馈。例如界面显示空调开启冷风，温度为27°，用户可以调整关闭空调或者调整空调的温度。又如依据安防系统确定家中无人时将家中灯关闭，用户可以通过应用界面控制开启门口的廊灯。

基于与设定参数的绑定可以构成Agent Instance，从而在设备中Page Link唤起Agent Instance对应服务组件Page执行该应用场景的操作。本申请实施例在确定出应用场景所需的一个或多个Page后，可以调用DPMS运行Page，DPMS从SPMS获取Page，其中，若本地磁盘存在Page package，则当SPMS从本地获取Page；若本地不存在该Page，则SPMS从PageCenter获取Page。再将Page反馈给DPMS，DPMS运行Pageprocess(即page运行进程)，显示相应的用户界面为用户提供服务。

本申请实施例中，基于服务组件Page为用户提供各种服务功能，从而在终端设备中可以基于各个Page的组合构成场景应用为用户提供所需功能，场景应用中各Page基于DPMS时间Page间跳转，并运行相应的Page。如图8B示例性地示出了两种应用场景下，Page的关联情况示意图。其中，在应用场景1下，用户在该业务的UI界面上的操作触发Page1生成指向Page2的PageLink并通过DPMS发送给Page2，Page2收到Page1发送的PageLink后进行处理并生成指向Page3的PageLink，并通过DPMS发送给Page3，Page3收到该PageLink后进行处理，一方面生成指向Page4的PageLink并通过DPMA发送给Page4处理，另一方面生成指向Page9的PageLink并通过DPMS发送给Page9处理，Page4收到PageLink后进行处理并返回处理结果给Page3。

在场景2下，用户在该业务的UI界面上的操作触发Page5生成指向Page2的PageLink并通过DPMS发送给Page2，Page2收到Page5发送的PageLink后进行处理并生成指向Page6的PageLink，并通过DPMS发送给Page6处理，Page6收到PageLink后进行处理并生成指向Page7的PageLink，并通过DPMS发送给Page6处理，Page7收到PageLink后进行处理并生成指向Page10的PageLink，并通过DPMS发送给Page10处理，Page10收到PageLink后进行处理并返回处理结果给Page7。

例如，基于用户旅游出行攻略服务Page的系统信号感知出用户需要旅游出行的应用场景时，可以基于该用用场景调用所需的Page来提供出应用服务功能，包括机票酒店查询服务、支付服务、天气查询服务等，通过各个Page之间的跳转为用户提供各种功能服务。

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

本申请实施例还提供了一种基于场景的服务提供系统。

参照图9，示出了本申请一种基于场景的服务提供系统实施例的结构框图，具体可以包括如下模块：

收集模块902，用于收集开发的各类型的场景服务数据，所述场景服务数据的类型至少包括信号类和服务类。

集成模块904，用于采用不同类型的场景服务数据集成场景逻辑单元。

绑定模块906，用于通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例。

其中，所述场景逻辑单元用于定义通用的场景服务功能，所述场景服务实例提供基于设定参数的场景服务功能。

其中，收集模块902，用于接收开发后上传的各类型的场景服务数据，按照所属类型对场景服务数据进行分类存储。所述场景服务数据包括：系统信号和服务功能信息。

绑定模块906，用于依据设定参数设置对应的系统信号和服务功能信息，构成对应的场景服务实例。所述设定参数包括：设备参数和/或用户参数。

绑定模块906，还用于依据设备参数确定设备类型，获取与所述设备类型对应的场景逻辑单元。

还包括：平台确定模块，用于预先确定各类型的场景服务平台，其中，所述场景服务平台包括：信号平台和服务功能平台。

收集模块902，用于将所述系统信号存储到所述信号平台，以及将所述服务功能信息存储到所述服务平台服务功能平台。

集成模块904，用于依据系统信号和服务功能信息确定应用场景，集成所述应用场景对应的场景逻辑单元。

其中，所述场景服务数据的类型还包括：逻辑类，所述场景服务数据还包括：场景逻辑信息。所述集成模块904，用于采用所述场景逻辑信息集成系统信号和服务功能信息，生成对应的场景逻辑单元。

还包括：信号路由生成模块，用于依据所述场景服务平台生成信号路由，所述信号路由用于分发接收的系统信号。

感知引擎生成模块，用于依据所述场景服务平台和场景关联参数生成场景感知引擎，所述场景感知引擎用于决策系统信号对应的应用场景。

其中，所述系统信号包括以下至少一类：设备信号、用户信号和服务信号。所述场景关联参数包括以下至少一类：知识图谱类、逻辑判断类、算法处理类。

还包括：场景感知处理模块，用于采用所述信号路由确定接收的系统信号对应的服务功能信息；采用确定的服务功能信息查询场景感知引擎，确定对应的应用场景；依据所述应用场景调用对应的场景服务实例。

所述场景感知处理模块，用于依据场景决策信息确定所述应用场景对应的场景服务实例；唤醒所述场景服务实例执行对应的场景服务操作。

所述场景感知处理模块，还用于当检测到本地未下载所述场景服务实例后，下载所述场景服务实例。

可以收集各种类型的场景服务数据，类型包括信号类和服务类，从而能够基于不同类型的场景服务数据集成场景逻辑单元，场景逻辑单元用于定义通用的场景服务功能，使得能够基于接收的信号提供场景服务，然后可以通过场景逻辑单元和设定参数的绑定构成对应的场景服务实例，从而基于设定参数的场景服务功能，适配于各种设备以及用户需求提供场景化的自动服务，提高操作的便捷性。

本申请实施例还提供了一种非易失性可读存储介质，该存储介质中存储有一个或多个模块(programs)，该一个或多个模块被应用在终端设备时，可以使得该终端设备执行本申请实施例中各方法步骤的指令(instructions)。

图10为本申请一实施例提供的终端设备的硬件结构示意图。如图10所示，该终端设备可以包括输入设备80、处理器81、输出设备82、存储器83和至少一个通信总线84。通信总线84用于实现元件之间的通信连接。存储器83可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，存储器83中可以存储各种程序，用于完成各种处理功能以及实现本实施例的方法步骤。

可选的，上述处理器81例如可以为中央处理器(Central Processing Unit，简称CPU)、应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，该处理器81通过有线或无线连接耦合到上述输入设备80和输出设备82。

可选的，上述输入设备80可以包括多种输入设备，例如可以包括面向用户的用户接口、面向设备的设备接口、软件的可编程接口、摄像头、传感器中至少一种。可选的，该面向设备的设备接口可以是用于设备与设备之间进行数据传输的有线接口、还可以是用于设备与设备之间进行数据传输的硬件插入接口(例如USB接口、串口等)；可选的，该面向用户的用户接口例如可以是面向用户的控制按键、用于接收语音输入的语音输入设备以及用户接收用户触摸输入的触摸感知设备(例如具有触摸感应功能的触摸屏、触控板等)；可选的，上述软件的可编程接口例如可以是供用户编辑或者修改程序的入口，例如芯片的输入引脚接口或者输入接口等；可选的，上述收发信机可以是具有通信功能的射频收发芯片、基带处理芯片以及收发天线等。麦克风等音频输入设备可以接收语音数据。输出设备82可以包括显示器、音响等输出设备。

在本实施例中，该终端设备的处理器包括用于执行各设备中数据处理装置各模块的功能，具体功能和技术效果参照上述实施例即可，此处不再赘述。

图11为本申请另一实施例提供的终端设备的硬件结构示意图。图11是对图10在实现过程中的一个具体的实施例。如图11所示，本实施例的终端设备包括处理器91以及存储器92。

处理器91执行存储器92所存放的计算机程序代码，实现上述实施例中图1至图8的处理方法。

存储器92被配置为存储各种类型的数据以支持在终端设备的操作。这些数据的示例包括用于在终端设备上操作的任何应用程序或方法的指令，例如消息，图片，视频等。存储器92可能包含随机存取存储器(random access memory，简称RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

可选地，处理器91设置在处理组件90中。该终端设备还可以包括：通信组件93，电源组件94，多媒体组件95，音频组件96，输入/输出接口97和/或传感器组件98。终端设备具体所包含的组件等依据实际需求设定，本实施例对此不作限定。

处理组件90通常控制终端设备的整体操作。处理组件90可以包括一个或多个处理器91来执行指令，以完成上述图1至图8方法的全部或部分步骤。此外，处理组件90可以包括一个或多个模块，便于处理组件90和其他组件之间的交互。例如，处理组件90可以包括多媒体模块，以方便多媒体组件95和处理组件90之间的交互。

电源组件94为终端设备的各种组件提供电力。电源组件94可以包括电源管理系统，一个或多个电源，及其他与为终端设备生成、管理和分配电力相关联的组件。

多媒体组件95包括在终端设备和用户之间的提供一个输出接口的显示屏。在一些实施例中，显示屏可以包括液晶显示器(LCD)和触摸面板(TP)。如果显示屏包括触摸面板，显示屏可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

音频组件96被配置为输出和/或输入音频信号。例如，音频组件96包括一个麦克风(MIC)，当终端设备处于操作模式，如语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器92或经由通信组件93发送。在一些实施例中，音频组件96还包括一个扬声器，用于输出音频信号。

输入/输出接口97为处理组件90和外围接口模块之间提供接口，上述外围接口模块可以是点击轮，按钮等。这些按钮可包括但不限于：音量按钮、启动按钮和锁定按钮。

传感器组件98包括一个或多个传感器，用于为终端设备提供各个方面的状态评估。例如，传感器组件98可以检测到终端设备的打开/关闭状态，组件的相对定位，用户与终端设备接触的存在或不存在。传感器组件98可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在，包括检测用户与终端设备间的距离。在一些实施例中，该传感器组件98还可以包括摄像头等。

通信组件93被配置为便于终端设备和其他设备之间有线或无线方式的通信。终端设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个实施例中，该终端设备中可以包括SIM卡插槽，该SIM卡插槽用于插入SIM卡，使得终端设备可以登录GPRS网络，通过互联网与服务器建立通信。

由上可知，在图11实施例中所涉及的通信组件93、音频组件96以及输入/输出接口97、传感器组件98均可以作为图10实施例中的输入设备的实现方式。

在本实施例的一种终端设备中，所述通信组件，耦合至所述处理器，接收系统信号，将所述系统信号发送给处理器；所述处理器，采用所述信号路由确定接收的系统信号对应的服务功能信息；采用确定的服务功能信息查询场景感知引擎，确定对应的应用场景；依据所述应用场景调用对应的场景服务实例。

本申请实施例还提供一种基于场景感知服务的操作系统，如图12所示，该终端设备的操作系统包括：场景框架1202、场景解析引擎1204和场景应用层1206。

场景框架1202，依据获取的系统信号确定场景信息。

场景解析引擎1204，运行所述场景信息对应的目标场景应用，所述目标场景应用至少包括一个场景逻辑单元，其中，所述场景逻辑单元采用不同类型的场景服务数据集成，所述场景服务数据的类型至少包括信号类和服务类。

场景应用层1206，采用所述目标场景应用执行对应的操作。

一种示例为应用于上述图1的主题框架，则场景框架为Context AgentFramework；场景解析引擎为Context Agent Engine；场景应用层为Context Agent Host。

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

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

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

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

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

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

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

以上对本申请所提供的一种基于场景的服务提供方法、一种基于场景的服务提供系统，以及一种基于场景感知服务的操作系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (20)

1.一种基于场景的服务提供方法，其特征在于，包括：

获取各类型的场景服务数据，所述场景服务数据的类型至少包括信号类和服务类；

采用不同类型的场景服务数据集成场景逻辑单元，所述场景逻辑单元与场景服务功能对应；

通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例；

所述场景逻辑单元用于定义场景服务功能，所述场景服务实例在设定参数下提供场景服务功能。

2.根据权利要求1所述的方法，其特征在于，所述获取各类型的场景服务数据，包括：

接收开发后上传的各类型的场景服务数据，按照所属类型对场景服务数据进行分类存储。

3.根据权利要求1所述的方法，其特征在于，所述场景服务数据包括：系统信号和服务功能信息。

4.根据权利要求3所述的方法，其特征在于，通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例，包括：

依据设定参数设置对应的系统信号和服务功能信息，构成对应的场景服务实例。

5.根据权利要求4所述的方法，其特征在于，所述设定参数包括：设备参数和/或用户参数。

6.根据权利要求5所述的方法，其特征在于，通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例，还包括：

依据设备参数确定设备类型，获取与所述设备类型对应的场景逻辑单元。

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

预先确定各类型的场景服务平台，其中，所述场景服务平台包括：信号平台和服务功能平台。

8.根据权利要求7所述的方法，其特征在于，按照所属类型对场景服务数据进行分类存储，包括：

将所述系统信号存储到所述信号平台，以及将所述服务功能信息存储到所述服务平台服务功能平台。

9.根据权利要求3所述的方法，其特征在于，采用不同类型的场景服务数据集成场景逻辑单元，包括：

依据系统信号和服务功能信息确定应用场景，集成所述应用场景对应的场景逻辑单元。

10.根据权利要求3所述的方法，其特征在于，所述场景服务数据的类型还包括：逻辑类，所述场景服务数据还包括：场景逻辑信息。

11.根据权利要求10所述的方法，其特征在于，集成所述应用场景对应的场景逻辑单元，包括：

依据所述应用场景确定场景逻辑信息；

采用所述场景逻辑信息集成系统信号和服务功能信息，生成对应的场景逻辑单元。

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

依据所述场景服务平台生成信号路由，所述信号路由用于分发接收的系统信号。

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

依据所述场景服务平台和场景关联参数生成场景感知引擎，所述场景感知引擎用于决策系统信号对应的应用场景。

14.根据权利要求1-13任一所述的方法，其特征在于，所述系统信号包括以下至少一类：设备信号、用户信号和服务信号。

15.根据权利要求14任一所述的方法，其特征在于，所述场景关联参数包括以下至少一类：知识图谱类、逻辑判断类、算法处理类。

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

采用所述信号路由确定接收的系统信号对应的服务功能信息；

采用确定的服务功能信息查询场景感知引擎，确定对应的应用场景信息；

依据所述应用场景信息调用对应的场景服务实例。

17.根据权利要求16所述的方法，其特征在于，依据所述应用场景调用对应的场景服务实例，包括：

依据场景决策信息确定所述应用场景对应的场景服务实例；

运行所述场景服务实例对应应用单元执行对应的场景服务操作。

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

当检测到本地未下载所述场景服务实例后，下载所述场景服务实例。

19.一种基于场景的服务提供系统，其特征在于，包括：

收集模块，用于获取各类型的场景服务数据，所述场景服务数据的类型至少包括信号类和服务类；

集成模块，用于采用不同类型的场景服务数据集成场景逻辑单元，所述场景逻辑单元与场景服务功能对应；

绑定模块，用于通过所述场景逻辑单元和设定参数的绑定构成对应的场景服务实例；

所述场景逻辑单元用于定义场景服务功能，所述场景服务实例在设定参数下提供场景服务功能。

20.一种基于场景服务的操作系统，其特征在于，包括：

场景框架，依据获取的系统信号确定场景信息；

场景解析引擎，运行所述场景信息对应的目标场景应用，所述目标场景应用至少包括一个场景逻辑单元，其中，所述场景逻辑单元采用不同类型的场景服务数据集成，所述场景服务数据的类型至少包括信号类和服务类；

场景应用层，采用所述目标场景应用执行对应的操作。