超级会员免费看
解决物联网级联故障困境
1. 基本概念
-
故障事件
：故障事件
evti = (devicek, sourceType, source)，其中sourceType表示故障是由监测工件或source指定的其他 OSAMA 检测到的。故障事件使 OSAMA 能够更新其信念库并采取行动处理故障。 -
信念库（Blf）
：
Blf = {blf1, blf2, ..., blfn}表示一阶逻辑语言中的正基础文字，用于描述物联网设备的状态。例如，如果设备devicei发生故障，blf i j = failed(devicei)；否则为recovered(devicei)。当接收到故障事件或恢复故障设备时，信念库会更新。 - 动作集（Act） ：代表 OSAMA 为故障管理（CFM）执行的一组内部和外部动作。内部动作由 OSAMA 执行，而外部动作访问抽象部署在 OSAMA 环境中的外部服务的共享工件。
-
计划集（Pl）
：
Pl = {p1, p2, ..., pn}表示 OSAMA 计划。计划pi ≡ evt → Acti有一个事件evt，包括添加或删除故障信念以及接收 CFM 请求。这样的事件会触发 OSAMA 动作的一个子集Acti来处理故障和 CFM 请求。
2. 诊断工件
诊断工件嵌入了一个故障知识库（FKB），借助 SPARQL 查询，OSAMA 可以根据监测工件提供的一组故障症状获取故障信息，如可能的补偿动作。
-
FKB 的生成
：每个 DM 参与者生成一个包含其管理的故障信息的 FKB。这些 FKB 使用名为 IoT - F 的本体构建。
-
IoT - F 本体
：
-
目的
：允许 OSAMA 对异构和分布式故障信息有一个全局的理解，还可协助 DM 参与者构建其故障信息。
-
架构
：
-
顶层
：基于 FMEA 概念，为任何感兴趣的领域提供故障描述的通用模型。
-
特定应用层
：表示物联网系统中的故障。构建该层时，重用了一组非本体资源，如物联网故障、故障原因和恢复动作的文献分类法，以及主要的市场 DM 模型（如 Matter 和 TR - 181）。
-
主要概念
：
IoT - F:FailureMode
表示与物联网设备类型
IoT - F:DeviceType
相关的物联网故障，由一组症状
IoT - F:Symptom
、原因
IoT - F:FailureCause
、影响
IoT - F:FailureEffect
和可能的补偿动作
IoT - F:CompensatoryAction
描述。
3. 依赖工件
依赖工件允许 OSAMA 通过分析物联网设备之间的依赖关系来识别故障根源。它包含一个框架，可使用语义数字孪生自动推断和分析物联网设备之间的动态依赖关系。依赖关系表示为物联网依赖知识图（DKG）。
-
框架概念
：包含名为 IoT - D 的本体，用于在异构 DM 解决方案中实现物联网依赖的共享表示。该本体扩展了标准化本体 SAREF，描述了一组界定设备之间直接和间接依赖关系的上下文数据。
-
DKG 构建步骤
：
1.
上下文提取
：从孤立的 DM 解决方案中检索 IoT - D 本体中描述的上下文数据，并将其转换为知识图（KGs）。
2.
实体解析（ER）
：聚合提取的上下文 KGs 中发现的重复实体，如具有不同表示的设备。此步骤依赖于 SHACL 标准的高级功能，即 SHACL 规则和 SHACL 函数。使用 SHACL 规则推断提取 KGs 中重复实体之间的
owl:sameAs
关系，SHACL 函数计算两个实体属性之间的相似度指标，然后决定是否推断它们之间的
owl:sameAs
关系。
3.
依赖推断
：通过推断聚合 KGs 中的依赖关系来构建 DKG。利用一组 SHACL 规则，根据聚合上下文 KGs 中提供的上下文关系推断物联网设备表示之间的依赖关系。
-
注解与通信
：在 DKG 中，物联网设备表示使用
FOAF:Agent
类标注管理它们的 OSAMA 的信息，如 OSAMA 通信方式。这允许 OSAMA 在探索 DKG 以识别故障根源时相互通信。从技术角度看，依赖工件集成到 Orange 数字孪生平台 Thing in the future(Thing’in)中，该平台提供了一组 API，供 OSAMA 在识别故障根源时查询 DKG。
4. 监测和恢复工件
这些工件嵌入了传统 DM 平台的监测和恢复功能，使 OSAMA 能够监测物联网设备、检测故障并执行恢复动作。
-
监测工件
：主动向其关联的 OSAMA 发送故障事件。
-
恢复工件
：由于传统 DM 平台的远程管理功能，允许 OSAMA 远程执行恢复动作。选择重用传统 DM 平台进行监测和恢复，是因为大多数平台都提供此类功能，这样可以提高可用性并节省集成成本，避免从头开发解决方案。
5. 协作 CFM 协议
使用上述工件，OSAMAs 根据协作 CFM 协议相互协作，以解决级联故障困境。
-
OSAMA 配置文件
：
-
OSAMA - SP
：具有完整的故障管理能力，可管理其设备上的故障，并与其他 OSAMA - SP 和 OSAMA - DMP 协作进行 CFM。
-
OSAMA - DMP
：与 OSAMA - MN 协作管理故障，通过请求它们拥有的故障信息来处理故障。
-
OSAMA - MN
：为其他 OSAMA 提供故障信息。
-
协作 CFM 协议算法
：
Algorithm 1. Collaborative CFM Protocol
1: BEGIN
2: if failure event evt = (devicei, sourceT ype, source) arrives then
3:
Update the belief base Blf with predicate failed(devicei)
4:
[Local Failure Plan]
5:
S ←getDeviceSymptoms(devicei)
6:
if Profile=SP then
7:
recovery←diagnosis(devicei, S)
8:
end if
9:
if Profile=DMP then
10:
OSAMAd←getDiagnosisAgent(devicei)
11:
requestDiagnosis(OSAMAd, devicei, S)
12:
Wait for proposed recovery action recovery from OSAMAd.
13:
end if
14:
recover(recovery, devicei)
15:
if
getDeviceState(devicei) = failed then
16:
[Cascading Failure Plan]
17:
DKG ←getDependency(devicei)
18:
for (devicek, OSAMAk) in DKG do
19:
sendCF MRequest(devicek, OSAMAk)
20:
Wait for response OSAMAk
21:
end for
22:
recover(recovery, devicei)
23:
if
getDeviceState(devicei) = failed then
24:
Notify customer care service
25:
end if
26:
Update the belief base Blf with predicate recovered(devicei)
27:
if sourceT ype = OSAMA then
28:
responseCF MRequest(devicei, source)
29:
end if
30:
end if
31: end if
32: END
- 场景示例 ：在 Scenario 01 中，亚马逊的 OSAMA 检测到灯泡出现高方差故障。亚马逊 OSAMA 向飞利浦 OSAMA 请求协助诊断并获取恢复动作。执行恢复计划后，灯泡仍有故障。亚马逊 OSAMA 假设是级联故障，检索灯泡依赖的设备的 DKG，发现与警报设备有关，该设备由亚马逊 OSAMA 管理。亚马逊和飞利浦 OSAMA 协作诊断并执行恢复计划，但警报设备仍有故障。亚马逊 OSAMA 继续检索警报设备的 DKG，发现与由 Orange OSAMA 管理的泄漏检测器有关。亚马逊 OSAMA 请求 Orange OSAMA 协助，Orange OSAMA 与 Kelvin OSAMA 协作诊断并恢复泄漏检测器。之后，警报和灯泡恢复正常，成功完成 CFM 请求。
下面用 mermaid 流程图展示协作 CFM 协议的主要流程：
graph TD;
A[故障事件到达] --> B[更新信念库];
B --> C[获取设备症状];
C --> D{Profile = SP?};
D -- 是 --> E[自行诊断];
D -- 否 --> F{Profile = DMP?};
F -- 是 --> G[请求其他 OSAMA 诊断];
F -- 否 --> H[未知情况];
E --> I[执行恢复动作];
G --> I;
I --> J{设备仍故障?};
J -- 是 --> K[检索 DKG];
K --> L[向 DKG 中设备的 OSAMA 发送 CFM 请求];
L --> M[等待响应];
M --> N[执行恢复动作];
N --> O{设备仍故障?};
O -- 是 --> P[通知客户服务];
O -- 否 --> Q[更新信念库为已恢复];
Q --> R{sourceType = OSAMA?};
R -- 是 --> S[响应 CFM 请求];
R -- 否 --> T[结束];
6. 评估
- 实现环境 ：使用 JaCaMo 框架（版本 1.1）实现 OSAMAs，该框架允许在复杂环境中进行自适应和可扩展的多智能体系统（MAS）管理和协调。在 JaCaMo 框架内，使用 Jason BDI 技术实现算法 1 描述的 CFM 协议，允许 OSAMA 代理以并行和连贯的方式处理故障事件。OSAMA 工件使用 Cartago 技术实现，允许代理访问其共享环境中的资源和服务。诊断工件中的推理使用 Apache Jena（版本 3.4.0）实现。将与激励用例相关的 OSAMAs 部署在 Orange 云基础设施中，资源配置为 1000 MIPS 的 CPU 和 2GB 请求内存。
-
评估类型
：
- 定性评估 ：在智能家居用例上进行，检查 OSAMAs 在级联故障场景中的表现。智能家居包含 17 个由五个 DM 参与者管理的物联网设备，通过 DKG 描述的 46 个依赖关系相互连接。每个 DM 参与者关联一个 OSAMA 代理。实验包括向 OSAMA 代理的信念库中注入故障，让它们协作执行 CFM。
-
定量评估
：
- 性能评估 ：测量协作 CFM 协议在涉及不同依赖深度设备的级联故障场景中的完成时间。发现平均需要 5 秒，与 Orange 传统解决方案的 15 - 20 分钟相比，这个时间是可以接受的。可以通过使用机器学习能力（如预测级联故障的根源）或卸载到边缘以减少延迟，来减少 OSAMAs 之间的消息交换，从而进一步提高性能。DKG 也可以部署在边缘，因为 Thing’in 平台支持此功能。
- 资源消耗评估 ：使用 FMSim 模拟器比较由 OSAMAs 管理的物联网基础设施和由 Orange 传统 DM 解决方案管理的物联网基础设施的资源消耗。FMSim 是 iFogSim 模拟器的扩展，允许对物联网设备进行故障注入和恢复模拟。在不同配置的模拟物联网基础设施中注入级联故障，测量两种情况下的资源消耗：一是将删除故障的时间设置为 OSAMA 恢复时间；二是将删除故障的时间设置为传统解决方案的恢复时间（Orange 传统解决方案的平均故障恢复时间为 15 - 20 分钟）。资源消耗由能源消耗、网络使用、物联网应用执行时间和在云端执行物联网应用的成本表示。在配置 4 中，观察到能源消耗节省 16 Mjoule，网络使用节省 650 字节。这些收益归因于 OSAMAs 比传统解决方案更快的修复时间，从而减少了物联网基础设施中的资源损失。
评估结果总结如下表：
|评估类型|评估指标|OSAMA 解决方案|Orange 传统解决方案|
| ---- | ---- | ---- | ---- |
|性能评估|CFM 完成时间|平均 5 秒|15 - 20 分钟|
|资源消耗评估|能源消耗节省|16 Mjoule（配置 4）|无|
|资源消耗评估|网络使用节省|650 字节（配置 4）|无|
7. 相关工作
- 物联网故障管理步骤 ：包括故障检测、故障诊断（识别故障类型和根源）和故障恢复。
-
现有方法
：
- 故障检测 ：大多数工作集中在物联网故障检测上，通常只是通知用户自行处理。
-
故障诊断
：
- 模型 - 基于方法 ：早期解决方案提出基于数学模型描述设备运行行为，然后用该模型估计设备输出，通过监测估计和测量输出之间的差异来检测故障并确定类型。但这种方法需要适应复杂的物联网系统。
- 数据 - 驱动方法 ：使用机器学习方法从信号或操作数据中分析故障，利用传感器设备数据构建模型进行故障识别和表征。但对于大规模物联网系统，所有可能故障类型的学习数据的可用性和质量可能无法保证。
- 知识 - 基于方法 ：适用于复杂或多参与者系统，依赖于包含专家在设备设计或操作层面提供的故障诊断信息的 FKB。虽然有一些生成 FKB 的本体被提出，但现有的物联网故障诊断方法缺乏对物联网故障行为、恢复动作和故障症状的有效分类，也没有解决自动故障根源识别问题。
- 故障恢复 ：一些技术框架主要依赖设备复制和替换来恢复故障，成本高且效率低。而且所有现有解决方案都没有考虑到物联网由多个参与者使用孤立和异构的 DM 平台管理，设备和故障信息由不同 DM 参与者管理的实际情况。
8. 结论与未来计划
- 解决方案总结 ：提出了一组名为 OSAMAs 的协作代理，帮助市场 DM 参与者解决物联网级联故障困境，使孤立的 DM 参与者能够自动和协调地管理级联故障。
- 优势 ：语义 Web 标准（如本体和 SHACL）解决了物联网级联故障困境中的几个挑战，如有效存储、查询和推理与物联网设备依赖和故障相关的大量异构数据。评估结果显示，该解决方案通过减少故障修复时间和最小化连接环境中的资源浪费，具有显著影响和潜在的商业节省。
-
设计选择
：
- 采用 BDI 模型，反映人类行为，便于 DM 参与者集成解决方案。
- 使用 FMEA 模型设计 IoT - F 本体，在文献中显示出良好的可用性。
- 在 OSAMA 代理中重用传统平台的监测和恢复功能，节省成本并加速集成工作。
- 未来计划 ：主要计划是根据进一步的实验和用户反馈完善解决方案，以实现该解决方案在设备管理市场的大规模部署和采用。
解决物联网级联故障困境
9. 技术优势分析
-
语义 Web 标准的应用
- 本体的作用 ：物联网 - F（IoT - F）和物联网 - D（IoT - D）本体在整个解决方案中起到了核心作用。IoT - F 本体使得不同的 OSAMA 能够对异构和分布式的故障信息有全局的理解，为故障诊断提供了标准化的知识表示。例如，在故障信息的共享和交流中，各个 OSAMA 可以基于 IoT - F 本体准确地识别和处理不同类型的故障。IoT - D 本体则为物联网设备之间的依赖关系提供了共享表示，通过它可以自动构建物联网依赖知识图（DKG），帮助 OSAMA 识别故障的根源。
-
SHACL 标准的优势
：在依赖工件的实体解析步骤中，SHACL 标准的规则和函数发挥了重要作用。SHACL 规则可以推断重复实体之间的
owl:sameAs关系，而 SHACL 函数能够计算实体属性之间的相似度指标，从而准确地聚合重复实体。这种技术使得 DKG 的构建更加准确和高效，为故障根源的识别提供了可靠的基础。
-
多智能体系统（MAS）的优势
- 协作能力 ：OSAMAs 作为多智能体系统，能够相互协作解决级联故障困境。不同配置文件的 OSAMA（如 OSAMA - SP、OSAMA - DMP 和 OSAMA - MN）根据各自的任务和能力进行分工协作。例如，OSAMA - SP 可以独立管理自身设备的故障，并与其他 OSAMA 协作解决复杂问题；OSAMA - DMP 则可以请求其他 OSAMA 的故障信息，共同处理故障。
- 可扩展性和适应性 ：使用 JaCaMo 框架实现 OSAMAs，使得系统具有可扩展性和适应性。在复杂的物联网环境中，随着设备数量和故障类型的增加，OSAMAs 可以通过调整和扩展来适应新的情况。Jason BDI 技术允许 OSAMA 代理以并行和连贯的方式处理故障事件，提高了系统的处理效率。
10. 应用场景与案例分析
- 智能家居场景 ：在智能家居场景中，物联网设备众多且相互依赖，级联故障的发生可能会影响整个家居系统的正常运行。例如，在前面提到的 Scenario 01 中，灯泡的故障可能会引发警报设备和泄漏检测器的故障。通过 OSAMAs 的协作 CFM 协议，可以逐步排查故障根源，最终恢复所有设备的正常运行。这种应用场景展示了该解决方案在实际生活中的实用性和有效性。
- 工业物联网场景 ：在工业物联网场景中，大量的传感器和执行器设备协同工作，任何一个设备的故障都可能导致生产过程的中断。OSAMAs 可以实时监测设备状态，及时发现故障并进行诊断和恢复。例如，在一个工厂的生产线上，如果某个传感器出现故障，OSAMA 可以通过 DKG 快速识别与该传感器相关的其他设备，判断是否存在级联故障，并采取相应的恢复措施，减少生产损失。
11. 操作步骤总结
-
故障处理流程
-
故障事件触发
：当监测工件检测到故障时，会向关联的 OSAMA 发送故障事件
evti = (devicek, sourceType, source)。 -
信念库更新
：OSAMA 接收到故障事件后，更新信念库
Blf，将故障设备标记为failed(devicei)。 -
获取设备症状
：OSAMA 从监测工件获取故障设备的症状
S。 - 诊断过程 ：根据 OSAMA 的配置文件，进行不同的诊断操作。如果是 OSAMA - SP，则自行诊断；如果是 OSAMA - DMP，则请求其他 OSAMA 进行诊断。
-
恢复动作执行
：根据诊断结果，OSAMA 通过恢复工件执行恢复动作
recover(recovery, devicei)。 - 级联故障检查 ：如果设备仍然故障，OSAMA 检索该设备的 DKG，向 DKG 中设备的 OSAMA 发送 CFM 请求，等待响应后再次执行恢复动作。
-
结果处理
：如果设备恢复正常，更新信念库为
recovered(devicei)；如果仍然故障，通知客户服务。
-
故障事件触发
：当监测工件检测到故障时，会向关联的 OSAMA 发送故障事件
-
DKG 构建流程
- 上下文提取 ：从孤立的 DM 解决方案中检索 IoT - D 本体中描述的上下文数据，并将其转换为知识图（KGs）。
-
实体解析（ER）
：使用 SHACL 规则和函数聚合提取的上下文 KGs 中发现的重复实体，推断
owl:sameAs关系。 - 依赖推断 ：利用一组 SHACL 规则，根据聚合上下文 KGs 中提供的上下文关系推断物联网设备表示之间的依赖关系，构建 DKG。
12. 总结与展望
- 总结 ：通过提出 OSAMAs 协作代理和相关的 CFM 协议，有效地解决了物联网级联故障困境。该解决方案结合了语义 Web 标准、多智能体系统等技术，具有高效、可扩展和适应性强的特点。评估结果表明，该解决方案在减少故障修复时间和资源浪费方面具有显著优势，为物联网设备管理提供了一种有效的方法。
- 展望 ：未来可以进一步完善该解决方案，例如利用机器学习能力提高故障根源的预测准确性，将 DKG 部署到边缘以减少延迟。同时，可以扩大应用范围，将该解决方案应用到更多的物联网场景中，如智能城市、医疗物联网等。此外，还可以根据用户反馈不断优化系统，提高用户体验，促进该解决方案在设备管理市场的大规模部署和采用。
下面用 mermaid 流程图展示整个故障处理的宏观流程：
graph TD;
A[故障检测] --> B[故障事件发送];
B --> C[OSAMA 接收事件];
C --> D[更新信念库];
D --> E[获取设备症状];
E --> F{诊断方式};
F -- 自行诊断 --> G[OSAMA - SP 诊断];
F -- 请求诊断 --> H[OSAMA - DMP 请求];
G --> I[执行恢复动作];
H --> I;
I --> J{设备是否恢复};
J -- 是 --> K[更新信念库为已恢复];
J -- 否 --> L[检索 DKG];
L --> M[发送 CFM 请求];
M --> N[等待响应];
N --> I;
K --> O[结束];
| 操作流程 | 具体步骤 |
|---|---|
| 故障处理流程 | 故障事件触发、信念库更新、获取设备症状、诊断过程、恢复动作执行、级联故障检查、结果处理 |
| DKG 构建流程 | 上下文提取、实体解析、依赖推断 |
扫一扫
720
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
