41、利用语义多智能体系统解决物联网级联故障困境

利用语义多智能体系统解决物联网级联故障困境

1. 引言

物联网（IoT）在医疗、交通等多个领域日益普及。物联网创造价值的关键在于物联网设备，它们能在最少人工干预的情况下执行任务。为确保物联网的顺利运行，对这些设备进行监控和管理至关重要，这就是物联网设备管理（DM）。

如今的物联网系统中，DM由不同的参与者提供，如运营商、服务提供商或设备制造商，他们各自拥有独立的DM平台，例如亚马逊网络服务（AWS）和Orange Live Objects。这些DM平台集成了不同制造商生产的设备，以执行关键的DM功能，如固件更新和故障管理（FM）。然而，它们在管理级联故障困境方面存在很大局限性。当一个设备发生故障引发依赖它的其他设备和应用程序出现故障时，就会产生级联故障，而不同的DM参与者往往难以应对这种情况。

级联故障会导致更多客户致电DM参与者的客户服务应用程序，通常需要人工干预来缓解，这增加了客户服务成本。例如，Orange公司报告称，一次客户致电的成本为20欧元，派遣技术人员的成本为100欧元，客户每周会进行100次致电以请求物联网设备恢复。此外，故障也是互联环境中能源浪费的主要原因之一，研究表明，25 - 45%的暖通空调能源消耗因故障而浪费。

为解决这一问题，我们提出了一种基于合作多智能体系统（MAS）的实用解决方案，该方案结合了语义网和数字孪生技术。具体来说，我们使用协作级联故障管理智能体（OSAMA），这是一种语义智能体，可集成到传统的DM平台中，帮助它们理解、协作并就级联故障管理（CFM）做出有效决策。

1.1 相关缩写说明

缩写	含义
BDI	信念 - 愿望 - 意图
CFM	级联故障管理
DKG	依赖知识图
DM	物联网设备管理
DMP	设备管理平台提供商
FKB	故障知识库
FM	故障管理
FMEA	故障模式影响分析
MAS	多智能体系统
MN	设备制造商
OSAMA	协作级联故障管理智能体
SP	服务提供商

2. 背景

2.1 传统解决方案概述

当前的物联网系统由多个参与者管理，每个参与者都有自己的传统解决方案来管理其物联网设备的故障。通过市场研究，我们确定了具有不同FM能力的以下角色：
- 设备制造商（MN） ：制造并向最终用户和物联网供应商交付物联网设备。大多数MN没有DM平台来执行其物联网设备的DM操作，但可能提供基于移动应用程序的解决方案，允许最终用户执行基本的DM操作，如固件更新。此外，他们可能获取有关物联网设备故障、原因、影响和恢复操作的信息，这些信息通常在设计和测试阶段使用故障模式影响分析（FMEA）等方法进行风险评估时确定，并可能以表格形式呈现，供客户服务手动恢复故障或构建支持页面以帮助最终用户管理设备故障。
- DM平台提供商（DMP） ：提供DM平台，允许进行多种DM操作，如固件更新和设备重启。这些DM平台为最终用户和企业提供DM服务，集成了不同MN制造的物联网设备。一些DM平台使用机器学习（ML）或基于警报的系统来提供故障检测功能，它们可以远程恢复物联网设备的基本故障，但在故障跨不同DM平台的设备传播时，缺乏端到端的自动FM解决方案。
- 服务提供商（SP） ：确保物联网连接并通过各种设备提供物联网服务，如Orange的LiveBox用于连接，三星的SmartThings集线器用于家庭自动化服务。每个SP都有自己的专有DM平台来管理其设备，这些平台提供的功能与DMP的DM平台类似，并且SP拥有其提供设备的故障信息。

2.2 复杂的物联网设备依赖关系

物联网设备之间的依赖关系会导致故障在它们之间传播。我们之前的工作提供了物联网设备之间依赖关系的分类，这些依赖关系会加剧级联故障的传播：
- 直接依赖 ：当物联网设备相互利用彼此的服务时产生（服务依赖）。
- 间接依赖 ：由于传感器和执行器通过物理环境进行交互而产生（基于环境的依赖），或者由运行在物联网设备上的应用程序创建，例如应用程序根据其他设备的状态对一组设备进行操作（基于状态的依赖），或者在它们之间转发数据流（基于数据的依赖）。这些依赖关系丰富且动态。

2.3 物联网故障

物联网将物理过程与数字连接相结合，通常涉及设备、连接协议和云平台三个组件。虽然任何组件都可能发生故障，但由于物联网设备的计算资源有限等因素，设备故障更为常见。物联网设备的故障主要分为两类：
- 故障停止故障 ：当物联网设备对外部请求无响应时发生。
- 非故障停止故障 ：当物联网设备的响应与正确响应不一致时发生，这种故障响应在文献中分为五类：
- 高方差 ：设备在状态之间的振荡速度比环境要求的快。
- 卡住 ：设备预期改变状态但未能改变。
- 尖峰 ：设备的数值状态增加或减少的速度比环境确定的速度快。
- 异常值 ：设备在单次轮询中报告错误状态。
- 校准 ：传感器数据显示偏移，即其增益与实际真值不同。

当一个设备的故障（故障停止或非故障停止）通过依赖关系传播到其他设备时，就会发生级联故障。

3. 激励用例

3.1 智能家居场景架构

我们考虑一个由五个DM参与者管理的智能家居场景，它展示了市场上的DM解决方案难以克服的级联故障场景。该智能家居场景包括三个智能系统，部署在一个包含客厅和厨房的家中：
- 灯光管理系统 ：依赖于光传感器、存在检测传感器、安装在客厅和厨房的灯泡以及灯光控制单元。灯光控制单元使用光传感器提供的光测量服务、存在传感器的存在检测服务和灯泡的服务来控制灯光。
- 温度管理系统 ：使用温度传感器和空调来控制家庭温度，主要基于表3中描述的自动化规则1 - 3。
- 安全控制系统 ：当检测到入侵者、火灾或泄漏时触发警报。它包括一个警报器，使用存在传感器提供的存在检测服务来检测入侵者，还使用温度、烟雾和泄漏传感器的服务进行火灾和泄漏检测，该系统由规则4 - 7加强。

一个网关将客厅的设备连接到互联网，而Wi - Fi中继器连接厨房的设备。三星的SmartThings平台通过SmartThings集线器实现表3中描述的自动化规则。智能家居中的设备由五个不同角色的DM参与者管理，每个参与者都有自己的解决方案来管理集成到其系统中的设备，具体信息如下表所示：
| DM参与者 | 角色 | 管理的设备 |
| — | — | — |
| Orange | DMP：泄漏检测器、水阀、温度传感器、窗户门；SP：网关、WI - FI中继器 | |
| Samsung | SP | SmartThings集线器 |
| Amazon | DMP | 警报器、灯泡、空调、烟雾传感器、灯光控制单元 |
| Philips | MN | 运动传感器、灯泡、灯光控制单元、窗户、门、警报器 |
| Kelvin | MN | 温度传感器、空调、泄漏检测器、水阀 |

3.2 级联故障困境示例

由于物联网设备之间的依赖关系，一个设备的故障可能会引发多个级联故障。以场景01为例，泄漏检测器发生高方差故障，该故障影响了警报器和水阀，因为它们在状态上依赖于泄漏检测器（见表3中的规则5）。此外，灯泡也受到影响，因为它们在状态上依赖于警报器（见表3中的规则7）。这种级联故障给DM参与者带来了巨大挑战。在这种情况下，警报器和灯泡由亚马逊DM平台管理，而水阀和泄漏检测器由Orange DM平台管理，这些独立的DM参与者无法识别故障的根本原因。此外，故障恢复信息分布在不同的设备制造商（Kelvin和Philips）之间，进一步加剧了问题的复杂性。

以下是智能家居的自动化规则：
| 编号 | 类型 | 自动化规则 |
| — | — | — |
| 1 | 舒适 | 根据温度传感器返回的温度调整空调 |
| 2 | 舒适 | 当空调停用，打开两扇窗户 |
| 3 | 舒适 | 当温度超过阈值，关闭两扇窗户并打开空调 |
| 4 | 安全 | 检测到火灾时，打开警报器，解锁门和两扇窗户 |
| 5 | 安全 | 检测到泄漏时，打开警报器并关闭水阀 |
| 6 | 安全 | 当检测到入侵者且用户不在家时，通知用户，关闭窗户，关闭门并打开警报器 |
| 7 | 安全 | 警报器激活时，将灯泡设置为红色 |

下面是一些级联故障场景的示例：
| 场景 | 根本原因 | 受影响的设备 | 检测位置 |
| — | — | — | — |
| 1 | 泄漏检测器高方差故障 | 警报器、水阀、灯泡 | 灯泡 |
| 2 | 烟雾传感器高方差故障 | 警报器、灯泡、门、窗户 | 门 |
| 3 | 运动传感器无运动卡住故障 | 灯光控制单元、灯泡 | 灯泡 |
| 4 | 温度传感器异常值故障 | 窗户、空调 | 空调 |
| 5 | 烟雾传感器检测到烟雾卡住故障 | 警报器、灯泡、门、窗户 | 警报器 |
| 6 | 温度传感器尖峰故障 | 窗户、空调 | 空调 |
| 7 | WIFI中继器故障停止 | 警报器、灯泡、烟雾传感器、水阀 | 警报器 |
| 8 | 泄漏检测器检测到泄漏卡住故障 | 警报器、水阀、灯泡 | 水阀 |

4. 用于协作级联故障管理的语义多OSAMA

MAS通过在多个传统系统周围开发智能体包装器，使它们能够参与协作问题解决和决策过程，从而实现这些系统的集成。基于这一优势，我们提出了一个MAS来帮助传统的DM解决方案自动管理级联故障困境。我们的解决方案包括一组名为OSAMA的合作智能体，DM参与者可将其集成到他们的传统解决方案中。这些OSAMA采用信念 - 愿望 - 意图（BDI）模型来处理级联故障，并根据协作CFM协议进行协作，以从跨不同参与者管理的设备传播的级联故障中恢复。

在它们的共享环境中，OSAMA可以使用四个工件来简化CFM：
1. 监控工件 ：允许使用传统DM平台监控物联网设备并检测故障。
2. 诊断工件 ：允许使用故障知识库（FKB）识别故障类型及其补偿措施。
3. 依赖工件 ：借助语义数字孪生，该工件允许自动访问物联网设备之间动态依赖关系的准确视图，以便于级联故障根本原因的识别。
4. 恢复工件 ：允许使用传统DM平台对物联网设备执行恢复操作。

4.1 OSAMA BDI模型

OSAMA的设计遵循BDI模型，该模型因其灵活性、鲁棒性和透明度，在开发各种领域的自主智能体时非常有用。BDI智能体模型基于人类的信念、愿望和意图等心理态度来编程理性智能体。信念对应于智能体对其周围环境、其他智能体和自身的理解；愿望是智能体希望实现的条件；意图是实现这些愿望的承诺。

为了实现其愿望，智能体利用在特定上下文环境中执行的一组计划。这些计划由一系列行动组成，智能体必须根据其信念库所暗示的条件来执行这些行动。信念库根据智能体从周围环境感知到的事件进行更新。

OSAMA的内部和外部行动如下表所示：
| 行动 | 类型 | 描述 |
| — | — | — |
| sendCFMRequest(devicei, OSAMAk) | 内部 | 由发起检测到的级联故障场景恢复的OSAMA发送，请求OSAMAk检查并恢复设备devicei |
| responseCFMRequest(device, OSAMAk) | 内部 | 由参与涉及设备devicei的级联故障场景恢复的OSAMA发送给级联故障恢复的发起者OSAMAk |
| requestDiagnosis(OSAMAk, devicei, S) | 内部 | 当OSAMA无法自行执行诊断时，向OSAMAk请求设备devicei具有症状S的诊断信息 |
| getDiagnosisAgent(devicei) | 外部 | 当OSAMA无法自行执行诊断时，允许其获取能够对设备devicei进行诊断的候选OSAMAd |
| getDeviceState(devicei) | 外部 | 允许OSAMA通过访问监控工件检查设备devicei是否发生故障 |
| getDeviceSymptoms(devicei) | 外部 | 允许OSAMA通过访问监控工件获取设备devicei的症状 |
| getDependency(devicei) | 外部 | 允许OSAMA通过访问依赖工件获取设备devicei依赖的设备列表 |
| recover(recoveryAction, devicei) | 外部 | 允许OSAMA通过访问恢复工件对设备devicei执行恢复操作 |
| diagnosis(devicei, symptoms) | 外部 | 允许OSAMA通过访问诊断工件根据一组症状获取故障设备devicei的诊断信息，如建议的恢复操作 |

基于上述BDI模型术语，我们将OSAMA定义为一个元组 ，其中：Evt = {evt1, evt2, …, evtn} 表示OSAMA通过监控工件感知到的或在CFM期间由其他OSAMA报告的一组故障事件。

4.2 协作CFM协议

协作CFM协议是OSAMA智能体之间协作的关键，旨在实现级联故障的自动恢复。当一个OSAMA检测到级联故障时，会触发以下流程：
1. 故障检测与请求发起 ：检测到故障的OSAMA通过监控工件发现故障设备，发起 sendCFMRequest 请求，通知其他相关的OSAMA参与故障恢复。
2. 响应与信息收集 ：接收到请求的OSAMA通过 responseCFMRequest 进行响应，并开始收集故障设备的相关信息，如通过 getDeviceSymptoms 获取症状，通过 getDependency 获取依赖设备列表。
3. 诊断请求与执行 ：如果无法自行诊断，OSAMA会通过 requestDiagnosis 向其他有能力的OSAMA请求诊断信息，或者通过 getDiagnosisAgent 获取候选诊断智能体。
4. 恢复操作执行 ：根据诊断结果，OSAMA通过 recover 操作对故障设备执行恢复操作。

以下是该协议的mermaid流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([故障检测]):::startend --> B(发起sendCFMRequest):::process
    B --> C{收到响应?}:::decision
    C -->|是| D(收集信息):::process
    C -->|否| B
    D --> E{能否自行诊断?}:::decision
    E -->|是| F(执行诊断):::process
    E -->|否| G(请求诊断信息):::process
    F --> H(执行恢复操作):::process
    G --> F
    H --> I([故障恢复完成]):::startend

4.3 解决方案的贡献

我们的解决方案具有以下重要贡献：
1. IoT - F本体 ：描述了物联网设备故障及其恢复操作，为故障信息的标准化和交换提供了基础。
2. OSAMA智能体 ：利用BDI模型实现协作级联故障管理，使不同的DM平台能够协同工作。
3. 协作CFM协议 ：定义了OSAMA智能体之间的协作流程，确保级联故障能够得到及时有效的处理。
4. 概念验证 ：通过实际案例展示了该解决方案在减少故障修复时间、节省客户服务成本和降低物联网基础设施资源消耗方面的潜力。

5. 评估结果与未来展望

5.1 评估结果

我们对提出的解决方案进行了评估，结果表明该方案在实际应用中具有显著的优势：
- 减少故障修复时间 ：通过自动识别故障根源和协同恢复操作，大大缩短了故障修复的时间。
- 节省客户服务成本 ：减少了客户因级联故障而致电客户服务的次数，降低了人工干预的成本。
- 降低资源消耗 ：有效减少了因故障导致的能源浪费，提高了物联网基础设施的资源利用率。

以下是评估结果的对比表格：
| 评估指标 | 传统解决方案 | 我们的解决方案 |
| — | — | — |
| 故障修复时间 | 较长 | 显著缩短 |
| 客户服务成本 | 高 | 大幅降低 |
| 资源消耗 | 高 | 明显减少 |

5.2 相关工作对比

与现有的物联网故障管理解决方案相比，我们的方案具有独特的优势：
- 传统DM平台 ：缺乏对级联故障的有效管理能力，无法实现不同平台之间的协同工作。
- 其他多智能体系统 ：未充分利用语义网和数字孪生技术，在故障信息理解和动态依赖关系处理方面存在不足。

5.3 未来研究方向

尽管我们的解决方案取得了一定的成果，但仍有一些领域值得进一步研究：
- 大规模应用 ：探索如何将该解决方案扩展到大规模的物联网环境中，应对更多设备和更复杂的依赖关系。
- 智能决策优化 ：进一步优化OSAMA智能体的决策机制，提高故障管理的效率和准确性。
- 与新兴技术融合 ：研究如何将该方案与人工智能、区块链等新兴技术相结合，提升物联网的安全性和可靠性。

综上所述，我们提出的基于语义多智能体系统的解决方案为解决物联网级联故障困境提供了一种有效的途径。通过OSAMA智能体的协作和语义技术的应用，能够实现不同DM平台之间的协同工作，提高故障管理的效率和效果，为物联网的发展提供有力支持。