论文阅读“HealthFog: An Ensemble Deep Learning based Smart Healthcare System for AutomaticDiagnosis of ”

概要

这篇论文提出了一个名为HealthFog的框架，它结合了物联网和雾计算，通过在边缘计算设备中集成深度学习来实现心脏病的自动诊断。该框架旨在解决云计算在处理大数据时的延迟问题，通过将计算资源靠近用户，提供更快、更准确的医疗保健服务。HealthFog可以根据不同的需求调整其配置，以实现最佳的服务质量或预测准确性。

论文的主要贡献包括：

1. 为雾计算开发集成深度学习的通用系统架构。
2. 使用集成深度学习开发名为 HealthFog 的轻量级自动心脏病患者数据诊断系统。
3. 使用 FogBus 框架部署 HealthFog，以实现物联网-边缘-云的集成，用于实时数据分析。
4. 从多个性能指标（如功耗、网络带宽、延迟、抖动、准确性和执行时间）来展示和分析 HealthFog 的部署情况。

---

略读

摘要

面临的问题：这些云框架目前面临的主要瓶颈是其可扩展性有限，因此无法满足基于集中式物联网 (IoT) 的计算环境的要求。造成这种情况的主要原因是，健康监测和监视系统等对延迟敏感的应用程序现在需要对传输到集中式数据库以及从数据库传输到云数据中心的大量数据（大数据）进行计算，这导致此类系统的性能下降。

而当前的雾模型仍然存在许多局限性，并且从有限的角度关注结果的准确性或缩短响应时间，但不能同时关注两者。我们提出了一种名为 HealthFog 的新颖框架，用于将集成深度学习集成到边缘计算设备中，并将其部署到自动心脏病分析的现实应用中。 HealthFog 使用物联网设备将医疗保健作为雾服务提供，并根据用户请求有效管理心脏病患者的数据。

支持雾的云框架 FogBus 用于部署和测试所提出模型在功耗、网络带宽、延迟、抖动、准确性和执行时间方面的性能。 HealthFog 可配置为各种操作模式，根据需要在不同的雾计算场景和不同的用户需求中提供最佳的服务质量或预测精度。

集中式物联网（Centralized IoT）是一种物联网架构模式，在这种模式中，所有的设备（或称为节点）和数据都通过一个或多个中央服务器进行连接和管理。在集中式物联网中，数据通常从各种传感器和设备收集，然后传输到中央服务器上进行处理和分析。

 引言

通过雾计算，我们使资源更接近用户，从而减少延迟，从而提高安全措施。更快获得结果意味着危重心脏病患者要快速采取行动。但更快地交付结果还不够，因为对于如此微妙的数据，我们不能在结果的准确性上妥协。获得高精度的一种方法是使用最先进的分析软件，通常是那些采用深度学习及其变体在大型数据集上训练的软件。近年来，从计算机视觉到语音识别等领域都出现了指数级增长，但最近被证明在自然语言处理、序列预测和混合模态数据设置中很有用。此外，集成学习用于充分利用多个分类器。其中一种集成方法称为装袋分类器，其中估计器拟合在数据的随机子集上训练基本分类器，然后通过投票或平均来聚合各个预测以获得最终预测。通过将随机化引入数据集分布过程，与单个估计器相比，此类估计器有助于减少方差。

这项工作的基本目标之一是弥合这一差距，并提供一个计算平台，该平台不仅可以利用边缘资源提供低延迟结果，而且还能够使用基于深度学习的框架来提供高度准确的结果。

通常，检测心脏问题很困难 [49, 50]，很多时候人们甚至不知道自己处于危急状态，直到出现心动过速甚至中风等心脏相关问题。传统上，心脏问题的症状很难识别，需要有经验的医生观察患者以确定他/她是否患有心脏问题。由于医生短缺，这实际上很难做到，因为大多数国家仍然不相信计算机系统能够以所需的准确性和可解释性检测心脏问题 。

1. 两种主要的数据收集方案：

   • 小数据（Little data）：这种类型的数据通常是通过物联网传感器收集的，并在雾节点（fog nodes）上进行处理。这些数据通常涉及到实时监测和分析，例如心率、血压等参数的实时监控。
   • 大数据（Big data）：这种类型的数据通常涉及到大量的历史医疗记录和复杂的数据分析，需要在云数据中心（Cloud Data Centers, CDC）进行处理。这些数据可能包括病人的历史病例、影像学数据、基因组数据等。

2. 现有框架的局限性：目前的一些医疗健康框架可能无法灵活地处理这两种类型的数据场景。一方面，它们可能缺乏在雾节点上实时处理小数据的能力；另一方面，它们可能无法有效地处理和分析存储在云中的大数据。

3. 利用边缘和云资源：为了解决这些问题，有必要利用边缘计算和云计算的资源。通过在边缘节点上处理小数据，可以实现低延迟和实时分析，从而快速响应紧急情况。同时，通过在云数据中心处理大数据，可以利用强大的计算能力来进行深入的数据分析和挖掘。这样，就可以在不同的场景中根据数据的特点和处理需求，灵活地选择合适的计算资源。

4. 前人研究工作：

   • 物联网和健康监测：前人研究集中在使用物联网技术进行健康监测，例如使用传感器收集健康数据，并通过智能设备进行处理和传输。
   • 雾计算和边缘计算的应用：研究人员探讨了雾计算和边缘计算在处理实时数据、减少延迟以及提高数据处理效率方面的应用。这些技术通过将计算资源和数据存储更靠近用户，改善了服务响应时间和系统效率。
   • 云计算的集成：云计算因其强大的数据处理能力被用来处理大量的医疗数据和进行复杂的分析，如大数据分析和长期数据存储。

5. 前人研究的局限性：

   • 规模扩展性：虽然云计算在处理大规模数据方面表现优异，但在实时数据处理和响应方面存在局限，特别是对于延迟敏感的应用如健康监测。
   • 实时数据处理：现有的云计算模型在处理来自物联网设备的实时数据时，可能因网络延迟而无法满足实时性要求。
   • 资源优化和能效：雾计算和边缘计算模型在资源管理和能效方面还有待优化，尤其是在如何有效分配计算任务和管理不同类型数据处理的策略方面。

在这项工作中，我们提出了一种基于雾的智能医疗保健系统，用于使用深度学习和物联网自动诊断心脏病，称为 HealthFog。 HealthFog 以轻量级雾服务的形式提供医疗保健，并有效管理来自不同物联网设备的心脏病患者的数据。 HealthFog 通过使用 FogBus 框架 [27] 提供此服务，并演示了利用雾资源实现相同目的的应用程序支持和工程简单性。

本文《HealthFog: An Ensemble Deep Learning Based Smart Healthcare System for Automatic Diagnosis of Heart Diseases in Integrated IoT and Fog Computing Environments》提出了一种结合物联网、雾计算和深度学习技术的创新医疗解决方案，用于心脏病的自动诊断。本文的主要创新和改进包括：

1. **集成深度学习与雾计算**：
   - **创新架构**：本文提出了HealthFog框架，该框架在雾计算节点上集成了深度学习模型，能够在接近用户的地方进行高效的数据处理和分析。这种集成提高了处理速度和响应时间，适合对延迟敏感的医疗应用。
   - **实时和精准的诊断**：通过在边缘设备上运行深度学习模型，HealthFog能够提供实时的医疗诊断和决策支持，对于急性心脏病患者特别关键。

2. **集成 IoT 和深度学习的框架**：
   - **数据处理优化**：HealthFog优化了数据的收集与处理流程，通过智能地在雾节点和云数据中心之间分配任务，处理各种规模的数据（包括小数据和大数据），充分利用了雾计算的低延迟优势与云计算的强大处理能力。
   - **动态资源管理**：通过FogBus框架，HealthFog实现了动态的资源管理和任务调度，可以根据当前的网络状态和系统负载自动优化资源配置。

3. **性能和服务质量（QoS）的平衡**：
   - **多方面性能评估**：HealthFog不仅关注诊断的准确性，还综合考虑了网络带宽、功耗、延迟和抖动等多个性能指标，通过详尽的实验评估了不同配置下的性能表现。
   - **质量服务保证**：HealthFog通过调整雾节点和云资源的使用，为用户提供了可定制的服务质量保证，满足不同用户和应用场景的需求。

4. **开源和可扩展性**：
   - **软件可用性**：HealthFog将其实现开源，支持社区合作和进一步的技术迭代，促进了科研和实际应用的发展。
   - **适用性广泛**：虽然主要针对心脏病诊断，但HealthFog的架构具有良好的可扩展性，可以适应更多类型的健康监测和其他智能医疗应用。

总体来看，HealthFog通过将深度学习、物联网技术与雾计算相结合，实现了在医疗健康监测和诊断领域的创新，提高了服务的实时性、准确性和可靠性，同时也展示了在现代医疗信息系统中处理复杂数据的先进方法。

路由器和网关都是网络设备，它们有一些功能是相似的，但也有区别。在一些情况下，路由器可以被认为是一种特定类型的网关，而在其他情况下，它们的功能和用途则有所区分。

网关是连接两个不同网络系统以便它们可以通信的设备，它主要处理不同协议、数据格式或者环境间的转换。它可以连接不同类型的网络，如连接一个局域网（LAN）到一个广域网（WAN），或者连接基于不同协议的网络。因此，网关的角色是作为不同网络或不同协议环境之间的“翻译官”。

路由器主要用于在网络间转发数据包，选择最佳路径来传输这些数据。在大多数情况下，路由器工作在网络层，主要处理相同协议环境下的数据传输。路由器可以在不同网络之间转发数据包，这使得它在功能上与网关相似。

在现代网络环境中，一个设备可能同时扮演多个角色。例如，一台家用路由器可能同时具有路由器、交换机和网关的功能，它连接家庭网络到互联网（作为网关），在内部网络中转发数据（作为路由器），并且管理内部设备之间的通信（作为交换机）。

集成学习是一种机器学习策略，其核心理念是结合多个学习算法建立更强大、更稳健的模型。在集成学习中，多个分类器（即基学习器）被训练来解决同一个问题，并以某种方式合并它们的预测结果，以便得到一个整体上更优的最终预测。这个过程基于一个简单的想法：一群专家集体做出的决定往往比单个专家做出的决定更可靠。

---

装袋（Bagging，Bootstrap Aggregating的缩写）分类器是一种常见的集成方法。它包含以下步骤：

1. **随机子集的创建**：通过有放回抽样（bootstrap），从原始数据集中随机选取多个子集。这些子集可以有重复的样本，每个子集的大小可以和原始数据集相同或更小。

2. **基分类器的训练**：每个数据子集用来独立训练一个基分类器。基分类器通常都是同一种类型的模型，比如决策树。

3. **预测的聚合**：每个基分类器对新的数据实例给出预测，这些预测通过投票（对于分类问题）或平均（对于回归问题）的方式合并，以产生最终的预测结果。

装袋方法之所以有效，是因为它通过引入数据集的随机化来减少模型的方差。方差是指模型由于对训练数据中的随机波动过于敏感而导致的预测误差。高方差通常与过拟合（overfitting）相关——即模型在训练数据上表现良好，但在新未见过的数据上表现不佳。通过装袋，每个模型都在略有不同的数据子集上训练，使得它们各自的过拟合误差被整体上平均掉，从而增强了模型在新数据上的泛化能力。

总结起来，装袋是一种有效的集成学习方法，它通过结合多个在数据的不同子集上训练出的基分类器的预测来减少模型的方差，从而提高模型的稳定性和准确性。

相关工作

1. Gia等人提出的低成本健康监测模型（LCHM）：

   • 该模型通过传感器节点监控和分析心电图（ECG），以实时方式处理心脏病患者数据。尽管LCHM提高了数据收集的效率，但响应时间较长，这限制了其性能。

2. He等人提出的基于物联网的健康管理模型FogCepCare：

   • 该模型集成了云层和传感器层，以识别心脏病患者的健康状况并减少作业处理的执行时间。FogCepCare使用分区和聚类方法以及通信和并行处理策略来优化执行时间。

3. Ali和Ghazal提出的基于SDN的物联网电子健康服务应用：

   • 通过智能手机以语音控制形式收集数据，并通过移动应用基于概念模型找出心脏病发类型。然而，该应用在云环境中的表现未进行评估。

4. Akrivopoulos等人提出的基于ECG的健康系统（ECGH）：

   • 该系统使用ECG诊断心脏异常，但由于直接抓取数据且未使用数据分析或其他特征提取技术，其检测异常事件的准确性低且响应时间长。

5. Manikandan等人提出的为医疗物联网（IoMT）提供的自动监控系统（AMS）：

   • 设计了一个基于奖励的机制，使用分析层次过程（AHP）公平分配节点间能量。尽管AMS模型在能耗方面表现更好，但节点间的通信时间导致处理患者请求的延迟增加。

技术特征或性能参数是否优化——使用技术及性能

• 雾计算（Fog Computing）
• 物联网（IoT）
• 深度学习（Deep Learning）
• 集成学习（Ensemble Learning）
• 心脏病预测系统（Heart Disease Prediction System）
• 能耗（Power Consumption）
• 延迟（Latency）
• 执行时间（Execution Time）
• 仲裁时间（Arbitration Time）
• 网络带宽（Network Bandwidth）
• 抖动（Jitter）
• 测试准确性（Testing Accuracy）
• 训练准确性（Training Accuracy）

技术背景

1. FogBus框架：

   • 作用：FogBus是一个用于开发和部署整合雾计算和云计算环境的框架，它支持结构化通信和跨平台的应用执行。
   • 连接性：FogBus能够连接各种物联网传感器（包括医疗传感器）和网关设备，负责将数据和任务发送到雾计算节点。
   • 资源管理：在雾代理节点上进行资源管理和任务启动。
   • 安全性：为了确保数据完整性、隐私和安全，FogBus采用了区块链、认证和加密技术，增强了雾计算环境的可靠性和鲁棒性。
   • 通信方式：FogBus使用HTTP RESTful API进行通信，并通过Aneka软件平台无缝整合雾计算设置与云计算资源。

2. Aneka平台：

   • 作用：Aneka是一个便于开发和部署分布式应用至云环境的软件平台。
   • API提供：Aneka为开发者提供了一套API，用于在云上利用虚拟资源。
   • 设计理念：Aneka的核心组件是以面向服务的方式设计和实现的。
   • 动态配置：Aneka能够动态地获取资源，并将它们集成到现有的基础架构和软件系统中。这些资源通常是从基础设施即服务（IaaS）云提供商那里获取的虚拟机（VM）。
   • 资源分配：通过调度服务和资源配置服务的互动，Aneka在“织物服务”中提供用于从公共云提供商分配虚拟节点的配置服务，以补充本地资源。
   • 编程模型：Aneka支持四种不同的编程模型：任务包模型、分布式线程模型、MapReduce模型和参数扫描模型。在HealthFog中，使用任务包模型跨云VM分配任务。

总之，FogBus和Aneka共同提供了一个强大的平台，可以满足各种数据处理需求——从边缘设备的快速响应到云基础设施的大规模计算，这对于需要实时处理和大量数据分析的医疗应用尤为重要。在HealthFog系统中，这种综合的技术架构确保了既快速又准确地处理心脏病诊断任务。

这张图片展示了通过FogBus框架整合物联网（IoT）、雾计算和云计算的高层次视图。图中描绘了三个主要部分：IoT设备、雾计算基础设施和云计算基础设施。

1. IoT设备：

   • 这些是智能设备或传感器，它们负责收集数据并将数据传送到雾计算网关。这些设备可以是可穿戴设备、家庭自动化系统、健康监控设备等。

2. 雾计算基础设施：

   • 雾网关节点（Fog Gateway Nodes）：这些是连接IoT设备和雾计算基础设施的中间设备，它们通常位于用户附近，以减少数据传输的延迟。
   • 代理节点（Broker Nodes）：这些节点在雾计算基础设施内部管理资源和调度任务，充当协调器的角色，以确保任务的有效执行。
   • 雾计算节点（Fog Computational Nodes）：
     • 通用计算节点（General Computing Nodes）：它们执行由代理节点调度的计算任务，可能包括数据处理、分析等。
     • 存储节点（Repository Nodes）：用于存储从IoT设备收集的数据和处理结果，便于进一步的分析或长期存储。

3. 云计算基础设施：

   • 这是一组远程服务器，通常拥有大量的计算和存储资源。云计算基础设施用于处理大规模的数据集和复杂的计算任务。

Aneka是一个在上面部署云开发应用程序的平台。它提供了运行时环境和一组允许开发人员构建的api。利用公共或私有云计算的网络应用程序。Aneka的一个关键特征是支持多个编程模型的能力,这些模型都是使用特定的抽象来表达应用程序的执行逻辑的方法。这是通过创建一个可定制的、可扩展的服务导向运行时环境来实现的,该环境是由一个连接在一起的软件容器集合所代表的。通过利用这些架构高级服务,包括资源保留、持久性、存储管理、安全性和性能监控。在此基础设施上,可以插入不同的编程模型,以提供对不同场景的支持,如工程、生命科学和行业应用。

HealthFog架构

HealthFog模型是一种基于物联网的雾化医疗保健云计算模型，可以有效管理心脏病患者的数据并诊断健康状况以识别心脏病的严重程度。 HealthFog 通过软件组件集成了各种硬件仪器，并允许 Edge-FogCloud 进行结构化和无缝的端到端集成，以快速准确地交付结果。

这张图显示了HealthFog架构，它是一个基于雾计算和云计算的医疗数据处理和分析系统。下面详细介绍每个部分：

1. 患者和医生：

   • 患者使用多种传感器监测生理数据。
   • 医生收集患者的样本数据和结果，以进行进一步的分析。

2. 传感器：

   • 多个传感器监测不同的生理指标，如血氧、心率、呼吸率、EEG、ECG、EMG、血压、血糖水平和活动水平。
   • 这些传感器收集的数据被发送到网关设备。

3. 网关设备：

   • 手机或其他智能设备作为网关，接收传感器数据并将其传输到雾计算环境。

4. 雾计算环境：

   • 雾代理（FogBus Broker）：
     • 负责任务请求和结果的仲裁，决定将任务发送到哪个雾工作节点。
     • 管理系统的安全性，保证数据传输的加密和认证。
     • 数据管理器组织和转发数据。
     • 资源管理器负责分配和监控计算资源。
     • 云集成器负责将任务和数据整合到云计算资源中。
   • 雾工作节点（FogBus Worker 1 至 n）：
     • 每个节点都有资源监视器来跟踪性能。
     • 节点内部有深度学习模型用于处理和分析数据。
     • 可以同时处理两种工作负载：训练（1）和测试（2）。

5. 云计算环境：

   • 通过Aneka平台，雾计算环境与公共云服务（如Azure和AWS）相连。
   • 提供额外的计算资源，可用于执行大规模的数据处理任务。

6. 训练和测试：

   • 训练（标记为1）：使用已知的样本数据来训练深度学习模型。
   • 测试（标记为2）：使用新的数据来评估模型的诊断性能。

7. 数据知识库：

   • 心脏病患者数据知识库存储所有的样本数据，以供深度学习模型训练和测试使用。

8. 工作负载统计：

   • 信息流在各个节点之间传递，包括工作负载统计，帮助系统评估和优化资源分配。

9. 模型更新：

   • 当模型通过训练得到更新时，信息会被发送回雾代理，以便在雾工作节点中更新模型。

10. 云服务：

    • 根据需要，任务可以被发送到云端进行处理，结果会被送回雾计算环境或直接反馈给医生和患者。

HealthFog架构是一个综合医疗数据处理平台，使用传感器收集关于患者的关键生理参数，通过智能设备作为网关将数据传输到雾计算节点进行实时处理。雾代理（FogBus Broker）在这些节点中协调任务，确保数据安全，并将需要更多计算能力的任务发送到云计算服务。在雾和云环境中，通过深度学习模型对数据进行分析和学习，以支持医疗诊断的训练和测试。为医生和患者提供迅速、准确的健康监测和评估服务。

HealthFog Design

5.1. 心脏病患者数据预处理

• 从脉搏血氧仪或心电图（ECG）设备获得的数据通常是图形格式的，需要预处理以提取深度学习模型输入的多个特征值。
• 这一步骤需要将特定领域的知识输入系统。
• 年龄数据由于略微偏斜，进行了标准化处理，如图4所示。
• 休息时血压（BPS）数据也有偏斜，心脏病患者与非心脏病患者相比，血压更高。
• 胆固醇水平在健康和患病患者间也显示出特定行为，健康患者的分布是瘦尾的。
• 即使是最大心率，健康人的最大心率（约160）也比心脏病患者（约150）要高。
• 其他特征，如胸痛和空腹血糖，需要从连续值转换为分类值。
• 还有运动ST段峰值的斜率和铊试验检索的心脏状态。

5.2. 集成深度学习应用

• 使用了一个深度神经网络集合作为预测分析模型，模型用于二分类问题。
• 首先在Cleveland数据集上的心脏病患者数据和已知的输出类别上训练模型，然后用训练好的模型预测实时数据输入的结果，如图5所示。
• 数据分为70:10:20的比例划分为训练集、验证集和测试集。
• 训练集用于模型训练，验证集用于调整模型，测试集用于测试模型对新数据的表现。
• 训练好的模型可以存储在所有能够处理的节点中，首先存储在一个公共数据库中。另一种方法是通过在不同模型中分配训练数据点来单独训练模型。
• 在分布式训练中，数据分布使用了像提升（boosting）这样的技术，它随机抽样数据并替换，然后发送到不同的边缘节点进行单独模型的训练。
• 在诊断时，每个节点分配任务，获取13维大小的患者数据。这些数据作为输入送入模型，进行前向传播，并输出1或0，即患者是否有心脏病。
• 使用装袋（Bagging）集成方法结合多个模型的结果，以提供更准确的结果。获得输入数据的工作节点会将其多播到其他工作节点。每个节点将此添加到其队列中，并将每个工作节点的预测结果发送回负责此任务的节点。然后，通过装袋获得的多数预测类别将发送给网关设备。
• HealthFog允许用户在结果需要低延迟时禁用此功能。第7节展示了集成学习提供了更好的准确性，但也带来了更高的响应时间和网络开销。

5.3. Android界面和通信

• 在网关设备中使用了名为FastHeartTest的安卓可执行文件来向Broker/Worker节点发送数据。
• 应用界面如图6所示。此应用允许网关充当身体传感器网络和工作节点之间的中介。
• 通信是通过HTTP RESTful API实现的。使用HTTP POST从网关设备上上传输入数据和下载结果。
• 每个工作节点、代理节点和CDC包含一个预先训练好的深度学习模型和预处理软件

实施(Implementation)

在实施部分，论文描述了HealthFog的不同组件是如何用多种编程语言实现的。其中，数据预处理和集成深度学习组件使用Python语言实现。预处理模块基于数据集中的字段参数的最大最小值和分布来标准化数据。

集成深度学习应用程序使用了SciKit learn库来实现投票机制。BaggingClassifier用于训练不同的分类器，并在诊断时结合各个模型的预测结果输出最终的主要预测类别。此外，使用MIT的App Inventor构建了一个名为FastHeartTest的Android应用程序，它通过HTTP RESTful APIs与FogBus代理节点通信，将数据作为.csv文件上传到代理节点 。

性能评估(Performance Evaluation)

性能评估部分通过实际的雾计算设备部署HealthFog模型，展示了该模型的可行性和有效性。论文指出，HealthFog模型能在雾计算环境中实现实时心脏问题检测，使用了最新的深度学习技术。实验环境包括Samsung Galaxy S7作为网关设备，Dell XPS 13作为代理/主节点，Raspberry Pi 3B+作为工作节点，以及Microsoft Azure B1s机器作为公共云。实验使用了Cleveland心脏病数据库。

实验结果表明，HealthFog模型在准确性和响应时间以及网络和能源开销方面表现良好。特别是，集成学习方法提供了更高的准确性，但同时也带来了更高的响应时间和网络开销。论文还提出了根据不同应用和用户需求使用HealthFog的建议配置 。

基于实验结果，论文建议在以下设置中使用HealthFog：

• 对于延迟敏感且轻量级任务或能源受限环境，应使用工作节点。这提供了非常低的结果传递时间，因为工作节点靠近用户。
• 对于重型和延迟容忍的任务，应使用CDC配置，否则这些任务将无法在资源受限的边缘工作节点上成功完成。

为了测量HealthFog模型的性能，观察并分析了以下特征:

1. 预测精度:数据集由1807个示例组成，其中1355个用于训练模型，452个用于测试。训练样例在所有worker/broker节点上平均分配，以获得各自的训练深度学习模型。随着雾节点数量的增加，使用所有资源来训练数据集示例将不得不分布到所有节点。这减少了训练时间，也提高了测试的准确性。为了观察这种效果，对训练精度和测试精度进行了分析。我们更正式地将准确率定义为模型正确预测的患者是否患有心脏病的百分比。我们通过改变边缘节点的数量以及是否集成结果来比较不同雾设置的准确性。

2. 时间特征:还观察和研究了图3所示的不同时序参数的代表性子集。这些包括仲裁时间、延迟、执行时间和抖动。我们通过没有边缘节点或最多2个边缘节点(有或没有集成)或只有云计算基础设施来比较不同雾设置的这些定时参数。

3. 网络带宽使用情况:由于只有Broker、Workers或Cloud以及Worker节点的数量会影响网络消耗，因此研究了不同情况下的网络使用情况。与时序参数的实验类似，我们比较了不同雾场景下的网络带宽消耗。这样做是为了找出带宽消耗与HealthFog提供的不同雾配置之间的依赖关系。

4. 功耗:功耗是云域向雾域转变的一个重要原因，我们还研究了不同场景下的功耗。根据前面描述的功耗研究和其他实验，我们将讨论如何将不同的HealthFog配置用于不同的用户和应用程序需求

Figure 12显示了在不同的雾计算场景下，Broker节点的仲裁时间变化情况：(1) 仅Broker，(2) 单个Worker节点，(3) 两个Worker节点和(4) 云。我们可以看到，当任务直接发送到Broker/Master或云时，仲裁时间几乎可以忽略不计（约为115毫秒）。随着边缘节点数量的增加，Broker需要检查每个Worker节点的负载并找到负载最小的Worker节点来发送任务，因此随着边缘节点数量的增加，仲裁时间也会增加。当数据发送到Worker节点进行集成学习时，Broker也不需要进行任何负载检查，因为大多数类别的选择需要由其中一个Worker节点完成，因此仲裁时间与不进行集成的情况类似。                  

Figure 13显示了延迟的变化，根据Figure 3的说明，延迟是通信时间和排队延迟的总和。我们可以看到，如果任务发送到Broker或任何边缘节点，则延迟几乎与所有通信都通过单跳数据传输相同。在集成情况下，延迟略高。对于云设置，延迟非常高，这是由于数据在LAN之外进行多跳传输造成的。抖动是连续作业请求的响应时间变化。对于包括健康数据分析在内的大多数实时应用程序来说，这是一个关键参数。

Figure 14（对数垂直刻度）显示了抖动随着雾计算配置的变化。我们观察到，与将任务发送到工作节点的情况相比，仅Broker的情况下抖动较高。这是因为Broker还执行其他任务，包括仲裁、资源管理和安全检查。随着工人数量的增加，由于工人负载的差异，与单个边缘节点相比，两个边缘节点的抖动略微增加。在集成情况下，抖动也很高。当任务发送到CDC时，抖动非常高。

Figure 15显示了执行时间的变化。如预期的那样，在云设置中，由于资源可用性更高，执行时间非常短。Broker的执行时间小于工作节点，因为HealthFog工作节点是具有低时钟频率处理器的树莓派。此外，当启用集成预测时，执行时间较长，因为工作节点现在需要检查所有预测类别中哪个类别占多数。

• 网络带宽使用特性：图16显示了不同场景下所有边缘节点的网络带宽使用情况变化。随着工作节点数量的增加，网络使用量也会增加，因为需要更多的心跳包、安全检查和数据传输（与云端）。在集成情况下，由于数据发送到所有工作节点，网络带宽消耗最高。
• 功耗特性：我们还测试了不同场景下HealthFog的能耗特性。与Broker节点（笔记本电脑）或工作节点（树莓派）相比，CDC的功耗非常高。与边缘情况相比，这导致云端情况下的功耗非常高。随着工作节点数量的增加，HealthFog框架的功耗也会增加。

---

HealthFog 系统的性能评估详细介绍了包括仲裁时间、抖动、延迟、执行时间、网络使用情况和功耗在内的各种指标，每个指标都通过图表和数据进行了说明。

1. 仲裁时间：该指标在文档中的图表 12 中显示，表示在不同 Fog 配置下 Broker 节点的仲裁时间。仲裁时间随着参与的工作节点数量的变化而变化，当任务直接发送到 Broker/主节点或云时，时间最少，随着边缘节点数量的增加而增加，因为需要检查每个节点的负载。

2. 抖动：图表 14 描述了抖动，即连续作业请求的响应时间变化。抖动随配置而异；仅使用 Broker 时抖动较高，因为 Broker 还执行其他任务，如仲裁和资源管理。随着工作节点数量的增加，由于工作节点负载的差异，抖动略有增加。

3. 延迟：如图表 13 所示，延迟包括通信时间和排队延迟。在涉及 Broker 或边缘节点的配置中，由于数据通过单跳传输，延迟相似，但在云配置中由于跨 LAN 进行多跳数据传输，延迟显著增加。

4. 执行时间：不同设置下的执行时间差异很大，通常云配置由于资源更丰富，提供最低的时间。图表 15 详细说明了这种变化，注意到启用集成预测时执行时间会增加，因为这需要额外的数据检查。

5. 网络使用情况：图表 16 探讨了不同 fog 配置下网络带宽使用情况的变化。随着更多工作节点的添加，由于数据传输、安全检查和心跳包更加频繁，网络使用量增加。

6. 功耗：图表 17 显示了功耗特性，表明云配置消耗最多的能源，边缘场景观察到的消耗较低。随着工作节点数量的增加，系统的功耗也增加。

这些评估综合提供了对 HealthFog 在处理不同计算负载和配置下的实时数据处理性能的全面了解，展示了其在集成 IoT 和 fog 计算环境中诊断心脏病的效率和可扩展性。

1. Master Only（仅主节点）：

   • 任务直接在 Broker 或 Master 节点上处理，不涉及其他边缘（Edge）节点。这种情况通常适用于计算需求较低或数据局部性很重要的场景。

2. 1 Edge Node（1个边缘节点）：

   • 任务分配给一个边缘节点处理。这反映了一个基本的分布式处理场景，其中一个节点负责执行任务，可以减少数据在网络中的传输。

3. 2 Edge Nodes（2个边缘节点）：

   • 任务可以在两个边缘节点之间分配。这种配置提高了并行处理的能力，有助于提高系统的处理效率和冗余，增强系统的容错性。

4. 2 Nodes (ensemble)（2个节点（集成））：

   • 任务在两个边缘节点上执行，并使用集成学习方法来提高预测的准确性。这种配置利用多个模型的预测结果，通过投票或其他方法综合这些结果，以期达到更高的准确率。

5. Cloud（云）：

   • 任务被发送到云服务器处理。这通常适用于资源需求较高的任务，云服务器因具有更强大的计算和存储能力而被利用。尽管带来了更高的延迟，但可以处理更复杂或计算量更大的任务。

在分布式计算和网络架构中，Broker 或 Master 节点扮演着管理和协调的角色，特别是在涉及多个计算节点（如边缘设备）的环境中。具体到 HealthFog 系统，Broker 或 Master 节点的作用和职责如下：

1. 任务调度与仲裁：

   • Broker 节点负责接收来自不同客户端的请求，并基于当前系统的负载和资源可用性，决定这些任务应该被发送到哪个边缘节点（Worker Node）进行处理。这包括计算哪个节点有足够的资源来最有效地执行给定的任务。

2. 资源管理：

   • 管理和监控所有连接节点的资源状况，如 CPU 使用率、内存使用情况、存储空间和网络带宽。这些信息帮助 Broker 节点做出更明智的调度决策。

3. 数据路由：

   • 在接收到数据或处理请求后，Broker 节点负责将数据正确地路由到适当的边缘节点进行进一步处理。这一过程可能涉及数据的初步处理或过滤，以优化网络流量和提高整体系统效率。

4. 安全和隐私：

   • 在多节点通信系统中，Broker 节点还可能负责维护数据传输的安全性和隐私，确保所有传输都通过安全的通道进行，并且数据在传输过程中不被未授权访问。

5. 负载平衡：

   • 通过智能地在多个边缘节点之间分配任务，Broker 节点还可以帮助系统维持负载平衡，避免任何单个节点过载，从而提高系统的整体性能和响应速度。

在具体的实施中，Broker 或 Master 节点的设计至关重要，因为它直接影响到系统的效率、响应时间、可扩展性和可靠性。在 HealthFog 这样的基于 Fog 计算的智能健康监护系统中，Broker 节点尤为关键，因为它直接处理来自 IoT 设备的大量实时数据，并确保这些数据能够快速且准确地处理，以便及时做出医疗决策。

1. Edge Node（边缘节点）： 边缘节点通常位于网络的边缘，靠近数据的产生源（例如 IoT 设备）。这些节点的主要目的是处理数据，以减少必须发送到云端的数据量，从而减少延迟并提高效率。在 HealthFog 系统中，边缘节点可能承担执行实际数据分析和处理的任务，比如运行深度学习模型来诊断心脏病。

2. 1 Edge Node / 2 Edge Nodes： 这些配置表示系统中参与数据处理的边缘节点的数量。例如，“1 Edge Node”指单个边缘节点在处理请求，而“2 Edge Nodes”则表示有两个节点并行处理数据。增加边缘节点的数量可以提高系统的处理能力和容错性，但也可能增加管理和协调的复杂性。

3. Ensemble (集成学习)： 在使用“2 Nodes (ensemble)”配置时，系统不仅在两个节点上处理数据，还采用了集成学习技术来提高预测的准确性。集成学习通过结合多个模型的预测结果来提高整体的预测性能。在 HealthFog 系统中，这可能涉及将同一数据集在不同节点上的处理结果进行综合，以得出最终的诊断结果。

4. Cloud（云）： 云配置指的是数据被发送到远程服务器（云）进行处理。这通常适用于计算需求非常高的任务，或者当边缘节点的资源不足以处理复杂的计算任务时。使用云计算可以利用其强大的计算资源，但可能会增加通信延迟。

系统负载是衡量计算系统（如服务器、网络或多节点环境）当前正在处理或等待处理的工作量的指标。它通常用来描述系统在特定时间内的性能状态和资源使用情况。系统负载涉及多个方面，包括但不限于以下几点：

1. CPU负载：

   • CPU负载指的是处理器处理任务的程度。高CPU负载意味着处理器正在积极执行指令，而低CPU负载则表示处理器闲置或者处理的任务较少。CPU负载过高可能导致处理速度下降，系统响应变慢。

2. 内存负载：

   • 内存负载是指系统中当前使用的内存量。当大量的应用程序或服务运行时，系统的内存负载会增加。内存不足（或内存压力高）可能导致系统使用虚拟内存，这会降低系统性能。

3. 磁盘负载：

   • 磁盘负载涉及到读写磁盘操作的频率和数量。高磁盘负载意味着磁盘操作非常频繁，可能会导致数据访问速度下降和响应延迟。

4. 网络负载：

   • 网络负载是指通过网络接口传输的数据量。网络负载过高可能导致网络拥堵，影响数据传输速度和网络服务质量。

系统负载的监控对于维护和优化计算环境的性能至关重要。通过监控系统负载，管理员可以识别潜在的瓶颈问题，合理分配资源，并确保系统的稳定运行。在分布式系统或云计算环境中，系统负载还可以帮助决定何时需要扩展资源或者重新分配任务，以保证系统的高效运行和可靠性。在 HealthFog 系统中，例如，Broker 节点需要根据系统负载来决定任务如何在不同的边缘节点之间分配，以实现负载均衡和优化整体性能。

Conclusions and Future Work

作为未来工作的一部分，我们建议扩展HealthFog，以便在给定不同的QoS特征和雾云成本模型的情况下实现成本最优的执行。此外，目前使用的模型训练策略在每个工作节点上使用单独的训练。每个节点的训练模型使用不同的套袋集成模型进行组合。可以部署更智能的集成模型来进一步提高准确性。此外，拟议的架构可以变得强大和通用，以结合其他雾计算应用，如农业、医疗保健、天气预报、交通管理和智慧城市。HealthFog还可以扩展到其他重要的医疗保健领域，如糖尿病、癌症和肝炎，可以为相应的患者提供高效的服务。