超级会员免费看
智能系统中多代理与服务导向架构的应用解析
在智能系统的发展进程中，为了实现更高效、灵活且智能的功能，多代理系统和服务导向架构的应用显得尤为重要。下面我们将深入探讨相关系统的原理、实现及优势。
基于代理的复合活动识别系统
在复合活动识别方面，涉及到多种代理的协同工作。
代理类型及工作机制
- SARA 代理（简单活动识别代理） ：在运行时，可根据需要创建零个或多个 SARA 代理，每个代理对应一个活动描述。当在特定时间间隔内并行执行活动时，会生成多个活动描述，相应的 SARA 代理将被执行，从而实现对相关活动的识别。这些多个 SARA 代理的结果将作为复合活动识别的输入。
- AAA 代理（活动分析代理） ：其主要作用是管理推理规则的执行并推断复合活动。它从 CARA 代理接收活动数据，执行推理规则以确定活动间的依赖关系，如顺序或并发关系。只有当确定存在活动间依赖关系时，才会发出复合活动存在的信号。最后，将简单或复合活动标签的结果传达给 CARA 代理。
多代理系统的实现
多代理系统采用 Java 代理开发框架（JADE）实现。JADE 是一个符合智能物理代理基础（FIPA）标准的代理开发环境，FIPA 的基本标准涵盖代理通信、代理管理以及代理/软件集成。
-
代理管理标准
：允许代理进行注册、注销、搜索和修改操作。
-
代理通信标准
：涉及消息传输协议、消息内容和通信语言。
系统共开发了四种类型的代理，每个代理通过在 JADE 的目录促进器中注册来宣传其功能，以便其他代理能够搜索到它。代理之间通过交换表示为序列化对象的消息进行通信，每个代理决定特定消息的接收代理类型。此外，多代理系统使用交际行为理论来管理代理之间的对话。
ADL 本体使用 OWL 2 在 Protégé 本体编辑器中设计，其中包含将蕴含规则实现为语义网规则语言（SWRL）规则作为 ADL 本体的一部分。原型系统使用基于 Java 的应用程序编程接口（APIs）与 Pellet OWL 推理器进行交互以进行本体推理。为了便于推理规则的执行，将 ADL 本体和 SWRL 规则转换为 Java 专家系统外壳（JESS）的事实和规则库，使用基于 Mei 和 Bontas 提供的指南的 OWL2Jess 和 SWRL2Jess 转换器。在原型中，JESS 事实和规则库由 JESS 规则引擎访问和处理，该规则引擎由负责汇总简单活动识别结果的 AAA 代理访问和操作。
多代理系统接口
多代理辅助生活系统的接口可通过相关图形界面查看。例如，从传感器观测数据中，CARA 代理会生成各种代理来监控正在进行的活动，并将它们启动在代理容器中。当用户处于厨房时，CARA 会启动多个 SARA 代理来监控基于厨房的活动，如泡茶、做汤、做意大利面等；当检测到用户进入浴室时，会启动更多 SARA 代理来监控基于浴室的活动，如刷牙、洗澡、洗手等。只要持续获取传感器数据，这个过程就会持续进行。
下面用 mermaid 流程图展示多代理系统的工作流程：
graph LR
A[传感器观测] --> B[CARA 代理]
B --> C{SARA 代理}
C --> D[活动识别]
D --> E[AAA 代理]
E --> F[复合活动推断]
F --> G[结果传达给 CARA 代理]
面向服务的基于 SOAP 的智能系统
原有的 SMART 系统存在一些不足，主要是其基于单台计算机系统的整体式 dotNET 软件结构，这是传统的可通过网络访问系统的部署方式。为了克服这些问题，提出了将 SMART 系统功能分离为一组通过标准 Web 服务通信技术进行通信的 Web 服务器的解决方案。
服务导向系统架构
基于 SOA 的 SMART 系统架构使用企业服务总线（ESB）在三个基于 Java 的 Web 服务节点和基于 AJAX 的 Web 接口之间提供接口，通信使用 SOAP 消息。系统的所有服务节点、ESB 和 HTML 接口都设计为分别部署在单个专用服务器上，但这种分布式部署具有灵活性，可通过修改 ESB 配置将所有元素部署在共享的单个服务器上。
-
表示服务节点
：与系统中的其他节点进行交互，以 HTML 格式将请求提交给其他节点并呈现返回的数据，供人类阅读。例如，Web 接口向表示服务发送语义本体完整性检查请求，表示服务接收请求后联系推理服务进行检查，推理服务执行检查并返回响应，该响应通常是一个供其他计算机代理使用的信号（如真、假或错误），表示服务处理这些信号以生成有意义的人类可读消息，并将其传达给 Web 接口。
-
推理服务节点
：集成语义知识工具（PELLET），托管语义存储库（JENA），并包含执行所有必要的 SMART 系统操作所需的支持逻辑，如设置传感器状态、确定活动等。该服务是 SMART 系统重新实现的核心，它消耗数据服务并通过 ESB 与表示服务交互，数据服务主要用于在请求之间提供语义推理操作的持久记录和日志操作。
-
数据服务节点
：为系统提供存储、修改和访问非语义信息的机制，并提供在 Web 服务请求之间保持操作状态的功能。它不消耗其他服务，通过 ESB 与表示服务和推理服务进行交互，存储的非语义信息包括活动日志、活动偏好和系统偏好的非语义表示。
下面是服务节点的功能对比表格：
| 服务节点 | 功能 | 交互对象 |
| ---- | ---- | ---- |
| 表示服务节点 | 与其他节点交互，处理请求和响应并以 HTML 格式呈现数据 | 推理服务、数据服务 |
| 推理服务节点 | 集成语义工具，执行系统操作 | 数据服务、表示服务 |
| 数据服务节点 | 存储和管理非语义信息，保持操作状态 | 表示服务、推理服务 |
系统实现
系统利用高性能 H2 关系数据库管理系统的嵌入式实现，通过 SQL 查询方便地存储、操作和检索数据。数据服务还提供了一个与 H2 关系数据库的接口，允许以唯一键对的形式存储和检索任何数据，为未来的 Web 服务提供了可扩展的存储方案。Web 接口使用 HTML、JavaScript、图像文件和 CSS 实现，无需服务器端编程技术，降低了部署的复杂性。接口使用 AJAX 技术仅与表示服务发送和接收 SOAP 请求，目前部分完成，提供了智能采样器、历史记录和偏好设置等接口。
系统接口
- 智能采样器页面 ：显示当前注册传感器的状态，提供手动触发传感器激活的功能，以检查智能家居系统的推理功能。用户可以激活单个传感器并查看识别的活动。
- 历史记录视图 ：允许查看和修改在设置记录传感器交互时创建的日志，这些历史记录可用于未来重放一系列传感器交互，记录存储在数据服务中，通过表示服务和 ESB 返回给 Web 接口。
- 活动偏好设置接口 ：使用户能够添加和更新新的活动偏好，活动偏好用于 SMART 系统中的活动识别。例如，制作绿茶的活动偏好指定了执行该活动的参数，如通常需要在 210 秒内完成，发生时间为 08:20，涉及激活的传感器包括 #ChinaCup、#GreenTea 和 #KitchenBoiler。这些偏好以非语义形式存储在数据服务节点，以语义形式存储在推理服务节点，数据服务中的记录用于查看偏好，更新操作时会从语义服务存储中完全移除原始语义偏好列表，并根据数据服务存储中的必要修改进行重建。
系统的优缺点
-
优点
：
- 资源扩展 ：分布式 Web 服务实现可以将资源密集型操作转移到独立的专用计算机主机，避免系统性能瓶颈，使整个系统保持响应性。
- 资源共享 ：分布式 Web 服务节点组成的系统允许多个进程使用这些服务节点访问其提供的功能，多个智能家居实例可以由单个或减少的计算机系统提供支持，无需为每个实例复制功能或硬件要求。
- 技术集成 ：可以使用多种技术开发单个组件，通过 Web 服务消息集成基于不同且原本不兼容技术的系统组件，使系统能够潜在地使用任何已开发的工具。
- 独立维护和修改 ：由于组件解耦，系统组件通过 Web 服务消息进行交互，除非对对等 Web 服务节点的 Web 服务功能的预期操作接口进行更改，否则不会直接受到对等组件服务内部操作和代码更改的影响，这使得 Web 服务组件的开发可以更独立和隔离，减少了协调和兼容性测试的工作量，提高了开发效率并降低了出错概率。
- 功能演进 ：基于 Web 服务开发框架开发的系统，在需要扩展系统功能时，有现有的服务和工具生态系统支持，使开发更容易。例如，未来可能需要添加分析服务组件来分析智能家居环境中消耗品的使用情况，通过该框架可以以较少的额外努力实现服务的开发和集成。
- 缺点 ：相较于传统的单台计算机系统部署，分布式系统的架构和配置更为复杂，需要更多的技术和管理资源来维护和优化。
多层面向服务的基于 REST 的智能系统
该系统延续了 SOA 方法，但使用轻量级的表示状态传输（REST）协议开发 Web 服务，而不是 SOAP。
系统特点
- 通信优势 ：REST 协议使客户端能够在不需要持续连接或数据报中额外信息层的情况下向 Web 服务检索和提交信息，特别适用于智能家居环境中的传感设备更高效地提交数据。
- 架构改进 ：单个 Web 服务采用设计模式组合进行分层，与第三个原型相比，ESB 变得多余，通信开销进一步降低。
- 数据库替换 ：使用基于图的数据库（三元组存储）代替关系数据库管理系统（RDMS）来保存语义数据，选择 Apache Jena Fuseki 服务器作为三元组存储，它可以与 Web 服务嵌入并部署在单个服务器上或外部云服务器上，以提高可扩展性和可重用性，有助于链接数据的语义内容，并支持语义融合和自动推理。
多层 SOA 框架
多层 SOA 框架独立于独立的 SMART 系统，由四种类型的参与者组成：客户端设备、基于 REST 的 Web 服务、三元组存储和智能家居环境。
-
客户端设备
：运行在不同平台上的客户端设备通过 HTTP 与 Web 服务进行交互。该人机界面通过构建移动应用程序和基于浏览器的界面增强了原始 SMART 系统。移动应用程序支持患者、护理人员和其他利益相关者在移动中进行连接，它可以利用内置传感器作为传感设备或作为其他传感设备的聚合器。开发了基于 Android 操作系统的应用程序，因其可用性、普及性和大量社区支持，但其他具有互联网访问功能的操作系统也兼容，因为数据使用标准消息格式进行通信。Android 应用程序采用简单的模型 - 视图 - 控制器（MVC）设计模式来组织类，以可视化 Web 服务的内容并使其具有交互性。
-
SOA 五层架构
：
-
REST Web 服务 API
：公开服务，使外部客户端设备能够使用 HTTP 异步消费功能/数据。
-
外观层
：包含执行高级命令以进行复杂操作的类，通过利用多个存储库类实现，包括数据访问和推理组件。数据访问组件执行与三元组存储的多个操作以回答简单或复杂的问题，但不编写执行“创建、读取、更新和删除”（CRUD）操作的查询，该任务委托给存储库层；推理组件利用存储库层的推理功能执行活动识别任务。
-
存储库层
：是核心组件，执行 CRUD 操作，解析从三元组存储检索的结果，并提供推理存储库的功能，以使用规则和不同的推理器进行推理。
-
领域层
：包含一组可以在运行时实例化的类，用于临时存储数据，在四层之间传递数据，并帮助数据在多种格式之间进行映射。
-
实用程序层
：执行低级过程，通过 HTTP 连接直接与三元组存储通信，从传感环境中的设备收集数据，并支持加载、操作和推理本体模型。
下面用 mermaid 流程图展示多层 SOA 框架的工作流程：
graph LR
A[客户端设备] --> B[REST Web 服务 API]
B --> C[外观层]
C --> D[存储库层]
D --> E[领域层]
E --> F[实用程序层]
F --> G[三元组存储]
C --> H[活动识别等操作]
该系统还可以添加用于协助养老院居民独立生活的应用程序，如管理药物剂量、医生预约、尿床协助和检测不活动等。已经实现了实时 ADL 推理和模拟引擎以及偏好管理和药物剂量管理接口来演示该架构。
综上所述，不同的智能系统架构各有其特点和优势，在实际应用中可以根据具体需求和场景选择合适的架构来实现高效、智能的功能。
智能系统中多代理与服务导向架构的应用解析
不同架构系统的综合对比
为了更清晰地了解上述三种智能系统架构的差异，下面通过表格进行综合对比：
| 系统类型 | 代理/服务基础 | 通信协议 | 数据库类型 | 主要优势 | 主要劣势 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| 基于代理的复合活动识别系统 | 多代理（SARA、AAA 等） | 基于 JADE 通信标准 | 结合 ADL 本体和 JESS 规则库 | 能有效识别复合活动，代理间协作灵活 | 系统逻辑相对复杂，对代理管理要求高 |
| 面向服务的基于 SOAP 的智能系统 | 服务节点（表示、推理、数据） | SOAP | H2 关系数据库 | 可扩展性强，资源可共享，支持多技术集成 | 分布式架构配置复杂，维护成本高 |
| 多层面向服务的基于 REST 的智能系统 | REST 服务 | REST | 图数据库（三元组存储） | 通信高效，架构简洁，适合传感设备 | 对三元组存储管理和维护有一定难度 |
各系统在实际场景中的应用操作步骤
基于代理的复合活动识别系统操作步骤
- 传感器数据收集 ：通过各种传感器（如接近传感器、触摸传感器等）收集环境中的活动数据。
- CARA 代理接收与处理 ：CARA 代理接收传感器数据，根据数据情况生成相应的 SARA 代理。
- SARA 代理活动识别 ：每个 SARA 代理对应一个活动描述，执行活动识别任务。
- AAA 代理复合活动推断 ：AAA 代理接收 SARA 代理的识别结果，执行推理规则，推断复合活动。
- 结果反馈 ：AAA 代理将推断结果（简单或复合活动标签）传达给 CARA 代理。
面向服务的基于 SOAP 的智能系统操作步骤
- Web 接口发起请求 ：用户通过 Web 接口向表示服务节点发送请求，如语义本体完整性检查请求。
- 表示服务节点处理 ：表示服务节点接收请求，根据请求类型联系相应的服务节点（如推理服务节点）。
- 推理服务节点执行任务 ：推理服务节点执行具体任务（如完整性检查），并返回响应。
- 表示服务节点处理响应 ：表示服务节点处理推理服务节点返回的响应，生成人类可读的消息。
- 消息传达给 Web 接口 ：表示服务节点将处理后的消息传达给 Web 接口，更新本地日志。
多层面向服务的基于 REST 的智能系统操作步骤
- 客户端设备发起请求 ：客户端设备（如移动应用程序、浏览器）通过 HTTP 向 REST Web 服务 API 发起请求。
- REST Web 服务 API 接收请求 ：API 接收请求并将其传递给外观层。
- 外观层处理请求 ：外观层根据请求类型调用相应的组件（数据访问、推理），并与存储库层交互。
- 存储库层操作 ：存储库层执行 CRUD 操作，与三元组存储进行数据交互。
- 结果返回 ：处理结果通过各层返回给客户端设备。
未来发展趋势与潜在应用领域
发展趋势
- 融合多种技术 ：未来的智能系统可能会融合更多的技术，如人工智能、机器学习等，以提高系统的智能水平和自动化程度。
- 增强安全性 ：随着智能系统的广泛应用，安全性将成为一个重要的关注点。未来的系统可能会采用更先进的安全技术，如加密、身份验证等，以保障数据的安全。
- 提高用户体验 ：更加注重用户体验，开发更加友好、便捷的人机界面，使系统更容易被用户接受和使用。
潜在应用领域
- 智能家居 ：进一步优化智能家居系统，实现更智能的家居控制和管理，如自动调节温度、灯光等。
- 医疗保健 ：在医疗保健领域，可用于监测患者的健康状况、提醒用药等，提高医疗服务的质量和效率。
- 智能交通 ：应用于智能交通系统，实现交通流量的智能管理、自动驾驶等，提高交通安全性和效率。
总结
本文详细介绍了三种智能系统架构：基于代理的复合活动识别系统、面向服务的基于 SOAP 的智能系统和多层面向服务的基于 REST 的智能系统。每种架构都有其独特的特点和优势，适用于不同的应用场景。在实际应用中，需要根据具体需求和场景选择合适的架构，并结合未来的发展趋势和潜在应用领域，不断优化和完善系统，以实现更高效、智能的功能。
下面用 mermaid 流程图总结三种系统的应用流程及未来发展关系：
graph LR
A[基于代理的复合活动识别系统] --> B[应用场景选择]
C[面向服务的基于 SOAP 的智能系统] --> B
D[多层面向服务的基于 REST 的智能系统] --> B
B --> E[实际应用]
E --> F[技术融合]
E --> G[增强安全性]
E --> H[提高用户体验]
F --> I[智能家居应用]
F --> J[医疗保健应用]
F --> K[智能交通应用]
通过对这些系统的深入研究和应用，我们可以更好地推动智能系统的发展，为人们的生活和工作带来更多的便利和价值。
扫一扫
1408
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
