语义智能辅助代理与以人为中心的网络物理系统
1. 语义智能辅助代理
1.1 基本原理
语义数据具有机器可理解和可处理的特性,这使得辅助系统能够借助智能代理自动解读情境数据,从而实现活动识别。辅助代理的主要职责是解读感知数据的意义,并为即时的日常生活活动(ADL)提供决策支持。它会依据领域知识进行推理,然后为居住者提供相应的行动建议。
在情境感知的辅助生活环境中,像ADL和用户配置文件这样的领域知识会被形式化为基于描述逻辑(DL)的公式,以主谓宾三元组的形式呈现。例如,“火灾警报”事件会“导致”“拨打999”的行动。这些知识可以用本体关系来描述,并以RDF或OWL的形式表示。
感知到一个事件或检测到传感器信号,就相当于识别出一个类的具体实例。例如,杯子里的接触传感器被激活,意味着作为容器类实例的杯子正在被用于ADL。如果容器类是“hasContainer”属性的范围,那么就可以推断出“hasContainer”属性的值为杯子。若“hasContainer”属性用于描述“制作饮料”类,那么就可以进一步推断出发生了“制作饮料”的ADL。
1.2 辅助代理的内部结构
辅助代理的核心在于其对情境的理解和推理能力。根据智能家居(SH)情境的性质,辅助代理可以设计成两层框架:
-
反应层
:用于处理紧急情况,如火灾警报响起或在特定时间执行预设动作(如按时服药)。这类情况通常涉及较少的传感器数据,但需要快速响应。
-
审议层
:负责识别涉及多个传感器输入的复杂非紧急情况。例如,在短时间内,牛奶瓶、水壶和杯子上的传感器都被激活,此时需要判断情境,并协助居住者完成正在进行的ADL。
1.3 情境理解与推理
辅助代理通过将感知到的情境数据与本体上下文(即本体)进行对比来理解这些数据。例如,客厅里的烟雾传感器可以用两个属性 - 值对进行语义描述:[hasConsequence, fire]和[hasLocation, lounge]。当传感器被激活时,代理可以根据本体中的语义上下文解读这一事件,识别出“客厅发生火灾”的情境。
识别出情境后,代理可以预测SH的未来状态,并通过推理和推断提供ADL协助。例如,火灾事件可以用三个属性 - 值对进行语义描述:[takeAction, toEvacuate]、[takeAction, callFireEngine]和[hasEffect, homeEvacuated]。当检测到火灾事件时,代理可以根据这些知识建议居住者撤离家中并拨打消防车。
1.4 多传感器数据处理
单个传感器输入有时可以决定特定情境,尤其是在紧急情况下。但大多数情况下,情境可能涉及多个来源的感知输入。此时,需要联合形成和解释多个感知到的传感器数据。例如,在短时间内,牛奶瓶、茶包和杯子上的传感器都被激活,通过关联这些事件,可以合理假设这是一个涉及杯子、糖、牛奶和茶的情境,即发生了“泡茶”的ADL。
为了让软件代理像人类一样识别这种情境,需要对这些情境进行明确表示,并建立推理机制。推理机制会将所有传感器输入结合起来,通过将聚合的感知数据与抽象知识表示进行对比,推导出相应的情境。
1.5 语义ADL建模
ADL可以看作是沿着时间维度的一系列情境。因此,可以通过语义ADL建模来对情境进行建模,即构建ADL本体。ADL本体由ADL层次结构组成,每个节点(也称为类)表示一种类型的ADL。每个ADL类由多个属性描述,子类可以继承其父类的所有属性。
属性通过指定其定义域和值域来定义。定义域指的是可以由该属性描述的所有类,值域指的是其实例可以分配给该属性的所有类。属性可以使用文字或另一个类的实例作为其值来描述一个类,从而将两个类联系起来。
1.6 推理过程
代理通过定期从语义存储库中检索语义情境数据来监控和收集感知到的传感器输入。这些情境数据已经丰富了本体关系,随时可以进行推理。代理在审议层进行推理,以推导出情境及其对应的ADL。具体过程如下:
1. 传感器输入用于识别参与ADL的具体物品。这些物品应该已经在SH本体中被指定为类的实例。
2. 根据属性的值域范围,可以推断出以识别出的物品为值的属性。
3. 根据属性的定义域范围,可以识别出可以由推断出的属性描述的ADL。
4. 由于属性可以从超类(更高级别的抽象ADL)继承到子类(更具体的ADL),ADL类树中类的层次越低,其属性就越多。这意味着可用的传感器数据越多,ADL的识别就越准确。
这个过程从概念上讲,相当于在特定时间收集多个传感器数据以形成一个情境。然后使用该情境来识别相应的ADL,并进一步识别这些物品以完成正在进行的ADL。这实际上是基于DL的包含推理,其理论基础、算法和实现可以在相关资料中找到。
1.7 示例案例研究
以厨房ADL类层次结构为例,KitchenADL是厨房ADL的顶级类,具有两个属性:inLocation和HasActor。它有两个子类:MakeDrink和MakeMeal。除了继承的属性外,MakeDrink还有一个容器类属性,该容器可以是杯子、马克杯或碗。MakeDrink又有两个子类:MakeHotDrink和MakeColdDrink,每个子类还有更多属性。
例如,MakeHotDrink ADL有两个属性,分别是HotDrinkType和Addings。HotDrinkType可以是茶、咖啡或巧克力,Addings可以是糖和牛奶。情境识别以相应的ADL表示,具体过程如下:
- 开发了一个功能丰富的原型辅助系统来实现情境感知的ADL辅助生活方法。该系统使用C#作为脚本语言,前端使用ASP.NET开发,并支持Ajax和Silverlight以提供更好的用户体验。
- 使用SemWeb语义库来读写RDF、在持久存储中管理RDF、通过简单图匹配和SPARQL查询持久存储,并向远程端点发出SPARQL查询。虽然SemWeb提供了内置的通用推理功能,但使用Euler证明机制进行推理。Euler是一个支持基于逻辑证明的推理引擎,是一个增强了Euler路径检测的反向链推理器。
系统的工作流程如下:
1. 用户首先登录系统,并从“BASE ONTOLOGY”面板上传SH本体。通过注册和登录页面,用户建立自己的身份。这样,用户可以在“USER PREFERENCES”面板中浏览自己的ADL偏好。
2. 加载SH本体后,系统可以显示经过语义描述的传感器。此时,系统可以在两种模式下运行:模拟和实时ADL监控。
3. 在模拟场景中,系统不需要连接到传感器。通过在“SENSOR SOCIETY”面板中选择一个传感器(如KitchenDoor),并在“SENSOR STATE”面板中设置传感器为开启状态,来模拟传感器激活。这相当于真实传感器的激活和感知。
4. 一旦观察到传感器激活(无论是模拟还是实时触发),就会使用该信息形成一个情境,并根据语义ADL描述进行推理。“LEARNING OUTPUT”面板会显示辅助代理在传感器激活和事件感知时的推理过程。“RECOGNISED ACTIVITIES”面板会以ADL树结构显示识别出的ADL及其位置。
当KitchenDoor传感器被激活时,只能推断出高级别的ADL,如“制作餐食”和“制作饮料”。当ChinaCup和ChineseTea传感器依次被激活时,可以动态形成具有更多上下文细节的情境。通过对这些情境进行推理,辅助代理可以逐步更详细地识别正在进行的ADL,例如最初识别为“制作饮料”,然后识别为“泡茶”。
如果用户有预先定义的、经过语义描述的偏好ADL(如“泡茶”),辅助代理可以通过将用户的“泡茶”配置文件与感知到的情境进行比较,推断出下一步需要做什么来完成正在进行的ADL,从而为用户提供情境感知的ADL协助。例如,如果“abashrawi - 偏好茶”的ADL中包含糖,而在预定义的时间段内没有检测到糖容器的传感器激活,代理可能会提醒用户添加糖。
1.8 优势分析
语义增强的情境感知ADL协助具有以下显著优势:
|优势|描述|
|----|----|
|可扩展性|情境建模的可扩展性一直是有效情境感知应用的瓶颈。基于本体的ADL建模作为一种情境建模方法,克服了这一问题。本体工程提供了广泛的技术支持,包括工具、API、存储和推理器。在其他领域已经开发了包含数千个类的本体,而智能家居中的ADL类和相关实例规模相对较小。|
|语义丰富|语义ADL模型包含明确的丰富语义和内置的逻辑蕴含规则。这不仅允许人类,也允许辅助软件代理对语义情境数据进行解释、理解和推理。因此,情境监控和ADL识别可以在更高的自动化水平上实现。|
|动态构建|基于描述的推理提供了一种机制,可以通过解释有限或不完整的传感器数据来动态构建情境,最终实现对相应ADL的逐步识别。这种能力尤为重要,因为辅助系统需要在有限的传感器数据下提供提醒或建议性的协助。|
1.9 实验验证
为了评估该方法和系统在模拟场景中的性能,设计了一个实验。在智能家居环境中,将接触传感器附着在茶包、糖、水壶、牛奶和杯子容器上,然后通过Tynetec无线接收器将原型ADL辅助系统连接到这些传感器。
实验过程中,用户按照上述场景进行泡茶活动,即先进入厨房,然后拿起杯子等。每次用户采取行动或拿起物品时,传感器的激活信息都会被感知并传递给辅助系统。系统的运行结果与模拟场景中的结果几乎相同,这证明了该方法和系统在现实应用场景中的适用性。
下面是辅助代理推理过程的mermaid流程图:
graph TD;
A[传感器输入] --> B[识别参与ADL的物品];
B --> C[推断属性];
C --> D[识别ADL];
D --> E[完成ADL协助];
2. 以人为中心的网络物理系统
2.1 系统概述
为了测试和评估相关研究成果,开发了四个用于辅助生活的以人为中心的网络物理系统(CPS)原型。这些系统采用了不同的架构和技术,以满足不同的需求和场景。
2.2 第一个系统:SMART
- 系统架构 :SMART系统采用独立系统架构,通过直接的传感器接口连接到智能家居环境,并使用基于Web的人机界面,采用dotNet编程语言开发。
-
功能模块
:该系统由六个功能类组成,具体如下表所示:
|功能类|描述|
|----|----|
|语音核心|当触发协助时,向用户输出预录制的音频消息,也支持预录制的个性化消息。|
|推理核心|根据用户偏好推断用户的活动。|
|偏好核心|管理用户的偏好,通过基本或高级学习方法进行管理。|
|通信核心|存储传感器的激活数据,并从数据库管理核心中检索数据。|
|模拟记录核心|记录传感器激活数据和推理得出的活动数据,这些数据可以导出到用户的本地磁盘或存储在存储库数据库中作为历史日志。|
|数据库管理核心|管理传感器激活数据的存储。|
2.3 第二个系统:代理介导的AR系统
- 系统目标 :该系统旨在识别复合活动,如交错和并发活动。它将单一活动和复合活动的识别整合到一个统一的框架中。
-
技术方法
:
- 结合本体和时间知识建模形式,以支持复合活动建模。
- 利用本体推理进行简单活动识别,利用定性时间推理支持复合活动识别。
- 采用多代理系统架构,允许同时监控和跟踪多个活动。
2.4 第三个系统:基于SOA的系统
- 系统架构 :该系统采用面向服务的架构(SOA),遵循客户端 - 服务器模式。核心系统使用Java编程语言编写,以摆脱独立环境、有限的社区支持和专有组件的限制。
-
系统特点
:
- 允许一个或多个客户端同时与SMART系统通信,而不受其操作系统平台的限制。
- 利用云计算提高可扩展性和资源利用率,能够在更短的时间内执行复杂的推理或计算任务。
- 将源代码逻辑上分离为三个Web服务,并使用企业服务总线(ESB)将这些服务绑定在一起,提高了系统的可维护性、可重用性和可调试性。
- 系统仍然具有基于Web的界面,使用JavaScript、异步JavaScript和XML(AJAX)功能从ESB请求和加载数据。同时,使用简单对象访问协议(SOAP)和超文本传输协议(HTTP)在不同设备之间交换数据。
- 系统缺点 :该系统有多个Web服务和ESB,需要在网络上托管,可能会给系统带来不必要的开销和延迟。
2.5 第四个系统:多层系统架构
- 系统架构 :该系统扩展了基于SOA的SMART实现,提出了多层系统架构和基于REST的Web服务。
-
系统特点
:
- 基于REST的Web服务允许客户端或传感设备之间以较低的开销和能耗进行通信。
- 多层Web服务使组件能够解耦,并作为单个实例部署在服务器上,提高了组件的可重用性和可维护性。
- 与第三个系统中使用传统关系数据库管理系统(RDBMS)存储传感器事件或结果不同,该系统使用基于图的数据库。基于图的数据库可以无限扩展新的连接和属性,而无需修改现有表结构和重新定义表之间的实体关系。
- 第三个系统中的传感器事件处理采用连续查询方法并结合RDBMS,然后执行语义推理任务;而该系统在传感器事件处理方面可能有不同的优化策略。
2.6 系统对比
| 系统名称 | 架构类型 | 编程语言 | 主要特点 | 缺点 |
|---|---|---|---|---|
| SMART | 独立系统架构 | dotNet | 功能丰富的Web界面,直接连接传感器 | 无明显缺点提及 |
| 代理介导的AR系统 | 多代理系统 | 未提及 | 统一识别单一和复合活动,结合本体和时间知识建模 | 无明显缺点提及 |
| 基于SOA的系统 | 客户端 - 服务器模式 | Java | 支持多客户端通信,利用云计算,逻辑分离为Web服务 | 多个Web服务和ESB带来开销和延迟 |
| 多层系统架构 | 多层架构 | 未提及 | 基于REST的Web服务,使用图数据库 | 无明显缺点提及 |
2.7 总结与展望
语义智能辅助代理通过利用语义数据和本体推理,实现了情境感知的ADL协助。其在可扩展性、语义丰富性和动态构建情境方面具有显著优势,并且通过实验验证了在现实应用中的适用性。
以人为中心的网络物理系统的四个原型分别采用了不同的架构和技术,从独立系统到分布式系统,不断解决在智能家居环境中构建辅助系统的技术挑战。每个系统都有其独特的特点和优势,为辅助生活提供了多样化的解决方案。
未来的工作可以进一步解决时间相关的问题,如并行/并发ADL识别。同时,可以扩展现有辅助系统的功能,使其能够通过执行器采取行动,如播放音频/视频或开关设备/电器。
下面是四个系统架构的mermaid流程图:
graph LR;
A[SMART系统] --> B[代理介导的AR系统];
B --> C[基于SOA的系统];
C --> D[多层系统架构];
超级会员免费看
895

被折叠的 条评论
为什么被折叠?



