CN110989977A - 一种面向残疾人的智能家居环境个性化定制方法 - Google Patents

Abstract

本发明属于智能家居技术领域，具体为一种面向残疾人的智能家居环境个性化定制方法。本发明方法包括：设计事件触发规则范式，设计事件触发规则模型，设计事件触发规则引擎，构建服务组件模型；本发明通过设计基于唯一事件源的事件触发规则引擎，为用户提供一种贴近自然语言的家居自动化服务编辑方法，降低家居自动化服务的编辑难度；同时根据服务组件的设备类型和功能类型，对服务组件进行了封装和抽象，进一步屏蔽不同软硬件设备底层实现的复杂性，保证服务组件统一简洁的用户体验。本发明可满足向残疾人的智能家居个性化定制服务需求。

Description

一种面向残疾人的智能家居环境个性化定制方法

技术领域

本发明属于智能家居技术领域，具体涉及一种面向残疾人的智能家居环境个性化定制方法。

背景技术

智能家居技术的发展对改善残疾人的家居生活具有重要意义。借助于残疾人智能辅具和环境交互技术，智能家居系统可以在一定程度上弥补残疾的身体缺陷，帮助他们独立进行日常生活。然而，相对于残疾人群体的复杂性而言，目前的智能家居系统仍然存在诸多不足。首先，这些智能家居系统所提供的服务相对单一，个性化支持程度不高。残疾人相对于正常人而言，由于残疾类型、残疾程度以及家庭环境因素的不同，他们对于智能家居系统的需求差异更加明显，而这些智能家居系统所提供的服务大多由系统开发商制定，用户无法进行修改。虽然部分系统提供预定义规则和人工智能预测等技术，尝试为用户提供一些个性化的支持，但是用户的定制化程度仍然极其有限。其次，智能家居系统服务开发周期长，迭代难度大，很难适应残疾人随时间不断变化的实时性需求。由于智能家居系统服务的开发具备很强的技术因素，往往都是由计算机技术人员根据具体需求，通过计算机编程语言实现，所以从需求确定到编程实现以及测试维护都需要很长的开发周期，用户的实时性需求难以满足。

发明内容

为了让智能家居系统能够满足残疾人复杂多变的实际需求，本发明提出了一种面向残疾人的智能家居环境个性化定制方法。

本发明提出的面向残疾人的智能家居环境个性化定制方法，是基于终端用户开发相关技术的。该方法不仅能够让残疾人及其家人根据残疾人的实际需求定制家居自动化方案，而且通过服务组件封装的方法屏蔽了软硬件设备的复杂性，降低残疾人及其家人编辑家居自动化服务的难度。

本发明提出的面向残疾人的智能家居环境个性化定制方法，具体步骤包括：

（一）设计事件触发规则范式

长期以来，无论是普通的智能家居系统还是残疾人智能家居系统，它们所提供的家居服务方案都是由开发商制定，并由拥有丰富经验的计算机开发人员实现，具备很强的技术元素。如果将家居服务的设计从开发者手中移交到残疾人及其家人手中，那么面临的主要问题是这些最终用户往往缺少计算机知识背景，无法使用计算机语音完成家居服务的开发。因此，为了让残疾人及其家人能够根据家庭的实际状况定制符合实时需求的家居自动化方案，需要为他们提供一种便于理解和操作的家居自动化定制方法。

终端用户开发相关技术就是为了解决这一需求的有效途径，它被用来解决软件设计在实际生产生活中面临的主要问题：软件使用情况不断变化，现实环境复杂多变以及未来需求的不可预测。通过对以往的终端用户开发工具进行分析，可以发现基于事件触发规则的终端用户开发工具具备较高的优势，能够以易于理解的方式将一些自动化的服务表现出来，使得普通的非计算机用户也可以参与到服务方案的设计和开发中。

基于终端用户开发相关技术，结合残疾人智能家居环境的实际需求，本发明权衡了规则的表达性和易用性，并从稳定性和性能角度触发，对已有的事件触发规则方式进行扩充和调整，设计了以唯一事件源为核心的事件触发规则范式：

Once Event, match <Condition1, Condition2…>, take <Action1, Action2…>

Event: 事件源，触发规则范式执行的事件源，事件源唯一；

Condition: 条件上下文，规则范式被触发时需要进行条件上下文校验，条件可以有多个；

Action: 执行单元，规则范式需要执行的所有操作，执行单元可以有多个；

基于该范式，可以将事件与条件进行明确区分，这样做有两点好处。其一，通过明确区分事件与条件，可以减少最终用户在设计服务方案时因为概念模糊而导致服务的最终结果与预期不同；其二，基于唯一事件源可以降低系统性能消耗，每个服务不再需要为每个条件设置后台监听对象，而是由系统统一管理和反馈，减少了系统的后台监听线程数量。

（二） 设计事件触发规则模型

基于唯一事件源触发规则范式，本发明根据家居服务的活动状态分别设计了服务的存储模型和执行模型。其中，存储模型是为了便于服务的存储和编辑，简化用户在设计服务方案时的过程，执行模型是为了保证服务方案可以被事件触发规则引擎正确调度，提高系统的执行效率。

存储模型

基于唯一事件源触发规则范式，本发明将残疾人的家居自动化服务描述为一个包含事件、条件、操作以及控制信息的对象模型Project，结构如下：

Project = <name, event, conditions, operations, isActive, isLopp>

name ：用于区分服务方案的唯一标识，在服务存储和管理过程中，需要根据该标识进行检索。

event ：是触发自动化服务的唯一事件源，是事件对象的数据对象，包含事件的比较逻辑和数据。系统根据该数据对象可以查找到对应的事件组件，并注册事件监听单元，执行服务监听。

conditions： 是服务需要认证环境信息，是判定操作是否执行服务操作的辅助信息，理论上可以设置任意数量，甚至不设置。每个 Condition 是一个条件组件的数据对象，包含条件比较逻辑和数据。

operations ：对应于设备的具体操作，可能是控制家居设备，也可能是警报或者其他操作，一个服务方案理论上可以包含多个操作，至少有一个。每个 Operation 对应一个操作组件的数据对象，包含操作组件名称和操作类型。

isActive： 是作为判断当前服务是否激活的标志，未激活的服务不会被转换为对应的执行模型，不会被规则引擎调度，所以永远不会被执行。

isLoop ：定义当前任务一次执行完毕后是否继续保持激活状态，如果设置为false，那么当前的任务只会被执行一次，如果想要继续执行就必须重新手动激活; 如果设置为 true，那么当前的任务会被重复监听并执行。

执行模型

由于自动化服务需要设置对事件源的状态监听，因此在服务的调度和执行过程中必须与对应的事件组件进行数据通信，来保证任务的正确触发和执行。因此，在实际任务执行过程中，需要将自动化服务的存储模型 Project 转换为 执行模型 Lotus，其类结构如下：

Lotus = <project, uri, lotusIntent, unsatisfiedLotusIntent, slot,receiver>

uri ：是可执行对象标识，格式为 lotus://hashcode。每个 Lotus 拥有唯一的 uri，保证广播发送和接收时对象唯一，能够正确连接事件监听器，条件验证列表以及操作列表中的不同服务组件。

lotusIntent： 是正常数据的通信对象。该对象是为了响应事件监听器正常被触发后发回的反馈信息，包含当前 Lotus 的标识信息。

unsatisfiedLotusIntent： 是异常数据的通信对象。当事件组件异常，如断开连接后，该对象会反馈相应的异常消息，通知执行器关闭当前执行组件 Lotus。

slot ：是事件组件监听单元，用于监听设备或服务的状态数据。在创建过程中，lotusIntent 和unsatisfiedLotusIntent会一起被注册的到slot中，从而实现slot与Lotus之间的数据通信。

receiver ：是广播接收者，用于响应事件组件的反馈信息，并在处理分析后采取对应的措施，目前主要包括两种类型，分别是正常触发和组件异常。

project ：是原任务对象。当事件监听器返回消息后，如果是正常触发，那么Lotus会读取当前的 Project 对象中的 Condition 列表，并一一验证是否满足，不满足则过滤此次事件响应，反之执行服务的所有 Operation。

（三）设计事件触发规则引擎

基于唯一事件源触发规则范式，本发明的规则引擎主要分为五个部分，分别是核心调度器、模型管理器、事件管理器、条件管理器和操作管理器。

核心调度器，主要负责规则模型的转换以及各个管理之间的通信调度。核心调度器通过读取服务的存储模型Project，并将其转换为操作模型Lotus，在转换的过程中将服务的事件源event注册到事件管理器中，生成事件监听对象实现服务的后台监听。

模型管理器，主要负责存储模型的存取，在用户编辑完服务后会被封装成存储模型对象，由模型管理器负责其转换成文件对象进行物理存储。本发明的文件存储格式为json。当引擎启动后，模型管理器将这些json格式的文件，转换成服务存储模型，等待核心调度器的转换。

事件管理器，主要负责管理事件监听单元，包括事件监听单元的生成和生命周期管理。事件监听单元是监听具体设备的执行单元，主要负责与具体设备之间的数据通信，当事件监听单元设置的任务得到反馈时，会通过观察者模式将反馈信息传递给核心调度器。

条件管理器，主要负责管理所有的条件组件，实时获取相关的上下文信息。区别于事件管理器，条件管理器是统一管理所有组件与设备之间的通信，并根据核心调度器的请求信息实时反馈结果，而不是单独生成执行单元进行验证和反馈。

操作管理器，主要负责管理和调度操作组件，实现最终任务的控制。操作管理根据核心调度器的控制请求数据，生成对应的设备操作单元，并由该操作单元通过数据通信方式实现对设备的控制。

（四）构建服务组件模型

由于智能家居系统的物理设备复杂多样，结合网络服务以及系统可能本身具备的一些基础功能，导致了智能家居系统的服务定制难度大，需要开发者了解不同设备的通信方式。基于事件触发规则范式，虽然可以便于最终用户理解和设计自动化服务，但是实际的配置过程仍然会虽则物理设备和服务功能的增加而不断复杂化，最终导致用户无法控制。因此本发明将所有的物理设备和功能服务都抽象成服务组件模型，并为用户提供统一的编辑和控制方式，保证用户操作的简洁性。

不同的物理设备和服务功能在组件的实现方式上一定会存在不同，但是通过本发明的模型设计，可以保证这些提供给最终用户的服务组件在编辑方式上是一致的，屏蔽了物理设备的复杂性。具体的服务组件模型包含四个组成部分，即组件定义模型、组件数据模型、组件UI模型和组件执行模型，服务组件的提供者只需要实现服务组件的模型，就可以将组件以统一简洁的方式呈现个最终用户。

组件定义模型，包含组件的定义信息，如名称、权限、数据、UI等等的声明信息。

组件数据模型，包含物理设备或功能服务的状态类型或可控制逻辑等等。

组件UI模型，是展示给最终用户的界面模型，该模型是最终用户编辑过程中的操作UI。

组件执行模型，是组件执行单元，根据组件类型可以划分为事件、条件和操作三类，每种组件模型的执行单元各不相同，但主要功能都是与物理设备或者网络服务进行数据通信。

本发明中，基于事件触发规则范式，为用户提供一种贴近自然语言的家居自动化服务编辑方法，实现残疾人家居自动化服务可以根据残疾人家庭的实际需求进行个性化定制，且通过服务组件模型抽象设计，降低了用户的编辑难度。

本发明中，针对事件触发规则中条件与事件概念的模糊性，提出基于唯一事件源的事件触发规则范式，保证了规则范式的简单性和表达性。

本发明中，基于唯一事件源的事件触发规则范式构建事件触发规则引擎，并根据服务在规则引擎中的活动状态，分别设计服务的存储模型和执行模型。

本发明中，根据软硬件设备类型和组件功能类型，构建服务组件的模型结构，为用户屏蔽软硬设备底层实现的复杂性，保证组件的使用过程简洁统一。

附图说明

图1是事件触发规则引擎的结构图。

图2是服务组件模型的类图。

具体实施方式

为了使本发明所要解决的技术问题、技术方案及有益效果更加清楚明白，以下结合附图及实施实例，对本发明进行详细的说明。应当说明的是，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

实施例：采用智能手机作为残疾人家庭用户的终端设备，以Windows平台下的Android Studio作为应用开发工具，采用Java语言进行开发，研究开发了基于终端用户开发的残疾人智能家居系统，包括家居自动化服务编辑功能、设备管理功能以及服务控制功能。

图1展示了事件触发规则引擎的执行过程和数据流向。首先，模型管理器将 json文件保 存的服务方案转化为存储模型 Project，并依次加载到系统中;当引擎启动后会遍历所有的 Project，将激活的 Project 转化为执行模型 Lotus，并将 Project 中的Event 转换为事件监听单元 slot 注册到事件管理器中;当某个事件被触发后，slot 会触发广播发送者发送认证消息给对应的执行模型 Lotus;Lotus 在接收到正确的广 播消息后，会将需要验证的条件传入条件管理器中，等待验证结果;当条件管理 器验证完所有条件后，会将验证结果反馈给对应的执行模型 Lotus;如果验证通 过，Lotus 会遍历所有的操作列表 Operation，通过操作管理器生成相应的 Operation 组件，并执行操作。

图2 展示了服务组件的类图结构，通过图中的接口设计可以发现，所有的组件都被设计成包括四个组成部分的模型集合，每个部分的设计在服务组件模型中已经详细介绍。总体而言，通过类图中的接口抽象可以将物理设备的复杂性隐藏在组件的实现过程中，主要集中在组件的执行模型实现上，而用户在编辑过程中调度的接口，即UI、数据和定义接口基本都是一致的，且较为简单的，能够更加符合终端用户的实际知识背景。

Claims (1)

1. 一种面向残疾人的智能家居环境个性化定制方法，其特征在于，具体步骤包括：

（一）设计事件触发规则范式

基于终端用户开发相关技术，结合残疾人智能家居环境的实际需求，权衡了规则的表达性和易用性，并从稳定性和性能角度触发，对已有的事件触发规则方式进行扩充和调整，设计如下以唯一事件源为核心的事件触发规则范式：

Once Event, match <Condition1, Condition2…>, take <Action1, Action2…>

Event：事件源，触发规则范式执行的事件源，事件源唯一；

Condition：条件上下文，规则范式被触发时需要进行条件上下文校验，条件可以有多个；

Action：执行单元，规则范式需要执行的所有操作，执行单元可以有多个；

（二） 设计事件触发规则模型

基于唯一事件源触发规则范式，根据家居服务的活动状态分别设计了服务的存储模型和执行模型；其中，存储模型是为了便于服务的存储和编辑，简化用户在设计服务方案时的过程，执行模型是为了保证服务方案可以被事件触发规则引擎正确调度，提高系统的执行效率；

存储模型，基于唯一事件源触发规则范式，将残疾人的家居自动化服务描述为一个包含事件、条件、操作以及控制信息的对象模型Project，结构如下：

Project = <name, event, conditions, operations, isActive, isLopp>

name ：用于区分服务方案的唯一标识，在服务存储和管理过程中，需要根据该标识进行检索；

event ：是触发自动化服务的唯一事件源，是事件对象的数据对象，包含事件的比较逻辑和数据；系统根据该数据对象可以查找到对应的事件组件，并注册事件监听单元，执行服务监听；

conditions ：是服务需要认证环境信息，是判定操作是否执行服务操作的辅助信息，可以设置任意数量，或者不设置；每个 Condition 是一个条件组件的数据对象，包含条件比较逻辑和数据；

operations ：对应于设备的具体操作，具体是控制家居设备操作，或者是警报或者其他操作，一个服务方案可以包含多个操作，至少有一个；每个 Operation 对应一个操作组件的数据对象，包含操作组件名称和操作类型；

isActive ：是作为判断当前服务是否激活的标志，未激活的服务不会被转换为对应的执行模型，不会被规则引擎调度，所以永远不会被执行；

isLoop ：定义当前任务一次执行完毕后是否继续保持激活状态，如果设置为 false，那么当前的任务只会被执行一次，如果继续执行就必须重新手动激活; 如果设置为 true，那么当前的任务会被重复监听并执行；

执行模型，在实际任务执行过程中，需要将自动化服务的存储模型 Project 转换为执行模型 Lotus，其类结构如下:

Lotus = <project, uri, lotusIntent, unsatisfiedLotusIntent, slot,receiver>

uri ：是可执行对象标识，格式为 lotus://hashcode；每个 Lotus 拥有唯一的 uri，保证广播发送和接收时对象唯一，能够正确连接事件监听器、条件验证列表以及操作列表中的不同服务组件；

lotusIntent：是正常数据的通信对象；该对象是为了响应事件监听器正常被触发后发回的反馈信息，包含当前 Lotus 的标识信息；

unsatisfiedLotusIntent：是异常数据的通信对象；当事件组件异常，该对象反馈相应的异常消息，通知执行器关闭当前执行组件 Lotus；

slot ：是事件组件监听单元，用于监听设备或服务的状态数据；在创建过程中，lotusIntent 和unsatisfiedLotusIntent一起被注册的到slot中，从而实现slot与Lotus之间的数据通信；

receiver ：是广播接收者，用于响应事件组件的反馈信息，并在处理分析后采取对应的措施，主要包括两种类型：正常触发和组件异常；

project ：是原任务对象；当事件监听器返回消息后，如果是正常触发，那么Lotus读取当前的 Project 对象中的 Condition 列表，并一一验证是否满足，不满足则过滤此次事件响应，反之执行服务的所有 Operation；

（三）设计事件触发规则引擎

基于唯一事件源触发规则范式，规则引擎主要分为五个部分，分别是核心调度器、模型管理器、事件管理器、条件管理器和操作管理器；

核心调度器主要负责规则模型的转换以及各个管理之间的通信调度；核心调度器通过读取服务的存储模型Project，并将其转换为操作模型Lotus，在转换的过程中将服务的事件源event注册到事件管理器中，生成事件监听对象实现服务的后台监听

模型管理器主要负责存储模型的存取，在用户编辑完服务后被封装成存储模型对象，由模型管理器负责其转换成文件对象进行物理存储；文件存储格式为json；当引擎启动后，模型管理器将这些json格式的文件，转换成服务存储模型，等待核心调度器的转换；

事件管理器主要负责管理事件监听单元，包括事件监听单元的生成和生命周期管理；事件监听单元是监听具体设备的执行单元，主要负责与具体设备之间的数据通信，当事件监听单元设置的任务得到反馈时，通过观察者模式将反馈信息传递给核心调度器；

条件管理器主要负责管理所有的条件组件，实时获取相关的上下文信息；条件管理器统一管理所有组件与设备之间的通信，并根据核心调度器的请求信息实时反馈结果；

操作管理器主要负责管理和调度操作组件，实现最终任务的控制；操作管理根据核心调度器的控制请求数据，生成对应的设备操作单元，并由该操作单元通过数据通信方式实现对设备的控制；

（四）构建服务组件模型

服务组件模型包含四个组成部分：组件定义模型、组件数据模型、组件UI模型和组件执行模型；

组件定义模型包含组件的定义信息，所述信息包括名称、权限、数据、UI等；

组件数据模型包含物理设备或功能服务的状态类型或可控制逻辑；

组件UI模型是展示给最终用户的界面模型，该模型是最终用户编辑过程中的操作UI；

组件执行模型是组件执行单元，根据组件类型划分为事件、条件和操作三类，每种组件模型的执行单元各不相同，但主要功能都与物理设备或者网络服务进行数据通信。

Images