边缘计算在应急管理系统中的建模与评估

基于复杂边缘计算系统的建模与评估：一个应急管理支持系统的案例研究

摘要

边缘计算范式通过提供克服关键应用在响应性、带宽需求、隐私性和可用性方面限制的手段，从而增强了云计算的可利用性。通过将系统的一些组件移至需要及时获得结果的物理位置，可以支持任务关键型应用，并借助云提供的灵活性、资源可用性和可扩展性对其进行支持，同时使任务成本低于传统方法（并提高响应效率）。将云与边缘组件融合的主要挑战在于实现二者之间的正确平衡，以在最低成本下取得最佳效果。这意味着面向性能的评估模型在系统生命周期的设计、部署和执行阶段至关重要。本文中，我们提出了一种基于复杂关键边缘计算系统的建模方法，该方法依赖于排队网络的应用，针对一种新型架构，旨在支持中大规模事故发生时应急阶段应急响应者之间互操作性的操作。所提出的架构能够协调配备有传感器和增强现实设备的消防队，以最小化任务问题，并及时利用本地和外部信息，同时支持与其他第一响应者的协同操作。结果表明，即使采用标准的建模方法，这些系统也极具吸引力，并表现出非平凡行为。文中还讨论了所提出架构的安全性和可靠性问题。

关键词 ：性能评估, 边缘计算, 危机管理系统, 物联网, 云计算, 关键系统, 核生化放射响应, 应急管理

1. 引言

云基础设施在计算架构中引入了重大的范式转变，因为它们提供了以按使用付费、按需获取的方式访问大量计算能力和存储空间的机会。然而，尽管自主访问计算资源带来了前所未有的灵活性（即可以在需要时获得所需资源），但基于云的方法也存在一个固有局限性：对网络的高度依赖。

事实上，得益于高度集中的架构和规模，用户可以获得所需的大量资源，但集中化意味着远程处理。这导致将基于按需的资源访问范式转化为基于按需的性能范式变得非常困难。确实，对于批处理类工作负载或常见的以用户交互为导向的应用而言，访问（潜在无限的）按使用付费、按需获取的资源可能实现性能的并行扩展；但对于关键任务应用来说，由于同时需要计算能力以及极短的通信往返时间（或高数据吞吐量、连接连续性或数据安全），这种机会可能难以充分利用。对于这类应用而言，传统而可靠的本地计算架构在设计、开发和维护成本方面优于基于云的架构。拥有本地始终可用的高性能计算资源可确保可控的性能水平；但这要求所有功能均在本地执行，并且系统必须能够无问题地应对（通常不频繁的）工作负载峰值。然而，本地资源可能等同于难以承受的成本，因为在购置和维护方面的费用远高于基于云的解决方案所提供的成本。

为了避免总体拥有成本（TCO）成为重大限制，边缘计算和雾计算范式提供了一种折中方案，它们通过在用户边缘添加资源（如固定或移动计算、本地服务器，甚至小型现场数据中心）来克服基于云的架构的局限性。

此类方法的优势在于，可以在云中执行非关键工作负载，而在边缘处理那些可能受网络性能影响或具有严格可用性和连续性约束的任务。本质上，边缘计算和雾计算范式背后的理念是在将大量数据发送到云端之前，在本地进行预处理

将数据传输到云，最终目的是降低带宽需求。这是紧急情况下的典型场景，其中本地决策者需要访问本地收集并快速处理的数据以应对紧急情况，而远程决策者则需要及时了解事故的演变情况，从而为本地（第一）应急人员高效行动创造条件（例如，向他们派遣更多资源，或阻止交通流向事故区域）。在这种典型情况下，本地传感器会产生大量数据（例如，通过无人机、可穿戴传感器和网络传感器收集的数据）。这些数据需要在本地快速处理，以提供有助于决定如何应对当前场景动态演化有用的结果。例如，可以根据天气条件提供有毒气体云的动态演化信息，这些数据可通过边缘资源进行处理。另一方面，远程决策者对相同结果的需求紧迫性要低得多，因为他们的决策时间尺度远长于本地决策者（例如，以小时计而非分钟计）。

在此背景下，边缘计算范式非常适用，因为数据可以在本地收集和处理（服务于本地决策者），然后通过云基础设施远程共享（满足远程决策者的需求）。这是一个优化方案：以有毒气体云演化这一具体示例而言，需要远程发送以更新显示给远程决策者的等浓度曲线形状的数据量，远小于计算等浓度曲线所需的数据量，从而避免网络相关约束成为阻碍。从复杂性角度来看，根据计算需求、收集的数据量以及非功能性需求，边缘子系统本身可能就是一个异构分布式系统，并且最终可能部分由智能和非智能移动节点实现。

在此背景下，需要定义相关的系统级和子系统级性能指标，以及用于设计和性能预测的模型。由于边缘子系统可能较为复杂，且一个系统可能包含多个此类子系统，因此性能指标应能充分描述系统及其子系统的实际服务水平，并涵盖依赖于具体应用的各种不同需求。系统可扩展性也是一个重要的指标，必须考虑应用的特性，以匹配系统在超出基本工作负载后可能的扩展方式。本文中，我们提出了一种

一种支持复杂紧急情况支持系统设计的性能评估方法。该系统由高性能、高可用的关键边缘前端（包括本地服务器、移动节点、传感器网络和实时增强现实（AR）设备）以及高负载云后端组成，两者持续交互以实现应急管理信息系统。我们致力于为每个子系统的各个组件以及整个系统定义和评估性能指标及相关的设计与评估模型。本文所采用的系统架构借鉴了意大利消防员最近一项研究[1]，该研究提出了一种物联网模块，用于在复杂紧急场景中管理设备。我们通过使用多类排队模型对其行为进行了分析，得到的结果并非显而易见，尽管采用了常规的建模方法，但仍证明了性能预测模型的必要性。

本文通过提供对提出系统的更详细描述、对架构的安全性和可靠性的评估，以及对性能评估的更深入分析，扩展了之前发表的一篇短篇论文[2]。

本文的结构如下：第2节介绍相关工作，第3节引入与案例研究相关的主要主题，第4节描述待评估边缘系统的参考架构，第5节分析该参考架构的安全性，第7节详细说明建模方法并展示结果，结论部分在第8节中给出。

2. 相关工作

边缘计算能够整合云计算、移动计算和物联网（IoT）这三个重要领域所提供的潜力。其目标是在由云产生的朝向庞大且远程的计算系统的向心力、朝向在私有、强大且廉价的移动设备上实现计算本地化的离心力，以及物联网典型的碎片化与分散性之间找到一种平衡。这种平衡必须通过灵活且可访问的解决方案来实现，以支持对这一平衡的有利可图的利用，从而设计和调整最佳分布以满足复杂规范。[3]和[4]对该主题进行了很好的介绍。主要参数包括响应性、可扩展性、隐私性和容错性，这些参数已被深入分析并呈现于相关研究中。

在[5]和[6]中接近度。关于架构、性能、通信协议、系统和软件管理等方面，边缘计算与物联网相关应用的研究挑战在[7]（该文献还提供了有用的图表以及关于基于容器的实现的有趣讨论）、[8]（介绍了复杂应用及雾计算视角）、[9]（引入了通信性能问题并面向物联网集成）、[10]（专注于软件架构）、[11]（关注边缘计算的自主式方法）中进行了描述。在[12]中，作者提出了一种范式的演进，即渗透计算。

有关解决方案、架构和性能约束的一些实现及相关经验教训在[13],[14]和[15]中有所报道。就本文而言，我们在[16]中发现了有关AR问题的有趣提示。

边缘架构的一个重要方面涉及安全风险及相关法律问题：[17]和[18]中提供了对该主题的介绍。

本文中提出的案例研究以及第4节介绍的参考架构，是在考虑了大量关于CBRN（化学、生物、放射性和核）应用领域的文献贡献和实践经验的基础上形成的。文中讨论了图1所示队内和队间网络所带来的复杂性，[19]中作者提出了为公共安全目的部署专用高容量网络的方案，以应对高流量负载。据作者目前所知，基于高度集成且高效的信息/软件工具的信息与协调系统，在科学文献以及实际应用中仍然缺失。例如，在[20]中，作者报告了一种能够描述火灾蔓延与控制的确定性离散时间模型，但该解决方案的复杂性较为有限，仅聚焦于单一火灾事件，并未涉及任何队间协调需求。相反地，在[21]中强调了第一响应者的态势感知的重要性，这种感知可通过基于混合通信方法的智能（可穿戴）设备支持下的协调与信息流程加以增强；而在[22]中则展示了智慧城市情景下响应者定位所提供的可能性，以提高响应的有效性。如图1所示的此类复杂信息系统容易导致个体活动的任务中断风险，该风险源于信息过载，这会带来

导致信息泛滥，并可能破坏指挥与控制链。在[23]和[24]中，作者分析并评估了这一风险，建议通过小型团队工作来维护指挥与控制结构，同时提升干预性能。最后，[25]讨论了救援队伍之间协调的主要障碍以及导致这些障碍出现的因果关系。这些问题相当重要，在设计和实施本文中提出的信息解决方案时应予以充分考虑。

3. 化学、生物、放射性和核紧急情况下的及时响应通信系统

为了应对中大规模事故，无论是由肇事者（例如恐怖分子）引发的还是自然灾害（例如自然灾害）造成的，第一响应者都需要及时获取有关当前情况的最新信息，以实现快速且高度协调的应急响应。事实上，为了有效（且高效）地开展行动，第一响应者必须在组织内部进行“内部”协调（即内部协调），以及在不同组织之间进行“外部”协调（即外部协调）。

当防御系统旨在应对高影响事件（例如涉及化学、生物或放射性物质释放的事件，即化学、生物、放射性和核事件）以保护人口和环境时，这一原则尤为重要。此类场景的解决通常不能依赖单一行动方，而必须依靠多个行动方能力的总和（即多部门应急响应系统），并在统一协调下进行。

然而，要实现这一目标，一个实时的最新信息系统至关重要。举一个实际例子，需要确定的首要参数是危险源的影响范围。在发生工业事故和/或恐怖袭击并涉及潜在释放CBRN物质（如气体）的情况下，影响范围由危险云团的大小决定，该范围需在道路图上通过等值线进行图形化表示，以反映与毒性或浓度等驱动参数相关的危险程度水平。这一信息极为重要，因为它决定了整个响应链：消防员根据该信息划定准入区域（红区、黄区和绿区），而这些划定的区域又会影响其他应急人员的行动（例如急救人员的检伤分类、警察的交通分流）

由官员向人口提供信息）。至关重要的是，必须及时、安全地向操作人员提供有关有毒气体云或扩散区域边界的信息，并在整个应急响应活动中保持信息的实时更新。这项活动极为复杂，因为它涉及通过传感器进行实时数据采集的系统，旨在保障首批救援人员的安全。特别是考虑到该情况会因天气条件等变量而发生变化，因此需要定期更新信息。危害模型还应涵盖区域内人口及其动态的影响，因为这些参数会影响应急响应[26]。

通过在和平时期（即灾难或恐怖袭击发生之前）使用计算流体动力学模拟来计算，可以预估危险区域可能的范围。然而，这些模拟的结果对于应急准备非常有用，即可用于培训应急人员应对可能发生的各种情景，但在实际灾难发生时作用有限，甚至可能产生误导，因为它们极不可能准确反映正在发生的实际情况。通常情况下，良好的准备工作应训练应急人员应对特定类型的情景，并针对每一种具体情景进行演练。因此，高级响应系统应能够将实时动态信息汇聚到位于高级指挥所的数据处理单元，并配备模拟工具，以预测情景的可能发展趋势。应急响应团队应当利用的实时信息包括气象相关参数（风速、风向、一天中的时间、云量）、CBRN物质的浓度水平、现场及周边温度、救援资源的地理位置（车辆、人员、设备、目标等）。这些参数可能来自不同的来源和设备。例如，关于CBRN制剂扩散及其相关浓度的信息可能来自固定检测装置（部署在灾难现场附近或理想情况下就在现场，或在整个区域布设的检测系统网络）、移动检测装置（如地面操作人员或配备探测器的无人机），并由提供位置、图像或天气预报等数据的卫星支持。

除了这些系统之外，可能还存在其他传感器，这些传感器与危险源的影响范围评估无关，而是与操作人员及其设备的性能（例如，他们的安全）有关。

以及在热区内操作时传输和接收这些信息的需求。所设计的手持设备旨在引导并同步每位第一响应者（或根据配置的小型团队）的行动。根据所使用的算法，这些设备可用于描述当前情况（例如，绘制由某种CBRN制剂产生的风险分布图），并协助第一响应者完成始终充满挑战的任务，即协调地解除危险源并挽救生命。然而，这些设备位于现场，需要接收和发送信息。因此，在传统的配置中，该设置将需要大量的计算时间，尤其是需要高带宽传输，以向远程计算节点发送信息并从中接收信息。而边缘计算则相反，它能够利用小型便携式设备（包括手持设备和笔记本电脑）日益增强的计算能力。

图1描述了上述先进的多部门应急响应系统所需的信息交换复杂性。

该图可视化了SFM项目[1]提出的架构，该架构由物联网控制台以及安装在无人机和地面人员上的传感器生态系统组成，旨在通过多部门协作的方式对受影响区域的化学、生物、放射性和核风险进行绘图。

4. 一个参考架构

我们提出了一种系统，用于在大规模复杂紧急情况（如CBRN场景）中支持消防队的行动。该系统旨在支持多个小队在大型关键场景中开展协作，并与其它当局（如国家安全、警察、医疗队、反恐、特种部队）进行松散协调，同时借助技术设备（如增强现实支持、物联网传感器、无人机、智能眼镜，以及通常部署在现场周围的常规安防摄像头、机器人、智能服装）提供辅助。该系统通过可穿戴、可部署和移动传感器，对每个小队及每位消防员的现场作业情况进行监控，包括其健康状况，并对作业环境进行实时分析。这使得系统能够利用额外的数据、警告、警报和指引来增强消防员对环境的感知能力（例如，系统可检测到墙壁后方存在的有毒气体或火灾爆炸风险，从而防止小队受到伤害；或通过分析环境信息以及来自智能眼镜和其他可穿戴传感器的数据，定位附近隐藏的受困人员）。

但小队无法看到）。该系统将现场数据与外部信息（如地图、情报信息、航拍图像、智慧城市数据源、与其他服务的交互）以及额外生成的内部信息（如对聚合现场数据进行高工作负载分析的结果、小队之间的协调、任务指挥与控制）相集成。

系统架构根据边缘计算范式划分为四个主要子系统：云后端(CB)、边缘前端(EF)、个人支持(PS)和传感网络(SN)。系统的配置是参数化的，并且取决于具体任务：最小配置包括一个CB、一个EF、一个PS和一个SN，而标准配置则包括一个CB、每个班组一个EF、每个班组中的每名消防员配备一个PS，以及每个EF对应数量可变的SN。

指挥中心负责提供计算能力和外部数据收集，并对数据进行高强度分析，以支持任务策略。此外，指挥中心运行任务管理系统，任务指挥员可通过该系统在任何位置管理任务并与其它当局进行交互。工作负载可能取决于连接的边缘前端数量、由传感器节点和个人站产生并由连接的边缘前端预处理的数据的体积和性质，以及外部

数据源以及用于任务战略支持的应用的性质（这些性质可能因任务而异）。

由于工作负载由不同的部分组成，每个部分具有不同的特征和性能表现，并且在任务持续期间可能发生变化，因此该子系统可以极大地受益于云的弹性。结果的战略性质意味着，向EF的反馈可以容忍一定程度的传输延迟或连接丢失。在云中执行有助于保持工作负载中最可变且潜在繁重部分的成本可持续性，同时不会威胁系统对任务支持的有效性。

EF负责为一个或多个小队的战术操作提供支持。每个EF必须与小队成员的所有PS以及一个或多个SN保持密切且定期的联系。EF实时处理所有现场信息，并及时向PS和SN发出指令和输出，以确保消防员的安全和操作的高效性。当在同一任务中使用多个EF时，它们可直接相互交互，以实现不同小队之间的战术协调。EF还减少需发送至CB的现场数据量，并从CB接收影响战术操作的战略指挥控制输入。考虑到所连接的PS和SN配置，EF的工作负载预计较为规律，但必须保证时效性，以维持与PS和SN在操作和通信上的一致性。因此，EF应物理上靠近作业区域（例如安装在车辆上）。EF还运行班组管理系统，使小队指挥员能够亲自管理小队操作，并与任务指挥员及消防员进行交互。EF可通过高性能计算节点实现。

类似的方法见于[27]。

PS负责管理消防员所配备的设备。这些设备可能包括用作第一人称视角传感器和增强现实界面的智能眼镜、位置传感器、健康监测传感器、环境传感器以及额外的可部署传感器。PS运行个人区域网络支持应用，用于处理和管理所有

这些设备，并管理与小队其他成员以及前端站的通信，前端站实时接收所有可用数据，并传输指令和进一步的增强现实实时信息。个人站的工作负载是稳定的，个人站可被视为嵌入式系统。个人站子系统类似于[28]中介绍的训练系统。

传感器节点（SN）可被视为一种传统的移动传感器网络（MSN），其节点可以是简单部署的传感器或设备，例如远程可控的自主机器人和无人机，具体取决于应用场景。传感器网络（SN）节点的数量可能会随时间变化（例如，在运行过程中可能会部署额外的传感器，或有传感器被毁坏或耗尽电量：该主题在[29]和[30]中进行了更详细的讨论）。该传感器网络（SN）由前端站（EF）控制。

5. 计算机安全考虑事项

由于所提出的架构具有关键性，可能影响任务的成功及操作人员的生命安全，因此有必要对计算机安全方面进行分析，以确保引入更复杂的任务支持系统（该系统通过替代人工通信来增强态势感知以及可用数据的数量和类型）不会显著引入安全威胁。其他安全方面的因素，包括操作人员的物理安全，以及相关国际或国家标准所规定的各项要求，在此参考架构的实施中也具有重要作用，但不在本文讨论范围之内。鉴于本文所提出的解决方案属于参考架构性质，本分析将仅限于适用于所提出模型的计算机安全方面的总体考虑。

攻击者背后的主要合理动机可能是纵火事件，或更广泛攻击行动（如恐怖主义行动或制造混乱以掩盖其他活动的转移手段）的后果：我们认为，在正常运行条件下，即发生意外火灾时，与计算机安全相关的担忧相对于其他问题（例如在嘈杂环境中现场通信信道的可用性）而言将是次要问题。

基于边缘计算的物联网安全问题空间[31]通过按层次（物联网设备、边缘、云）、攻击目标（传输、存储、计算）和防御机制（检测、防护、响应）进行分类，为粗粒度分析提供了参考指南。对于所提出的架构而言，存在一个

云层与边缘和物联网设备层之间存在显著分离。

关于云层，存储和计算中的漏洞由云基础设施提供商（即第三方）负责，并涉及一个主体联合体，包括参与任务支持和规划流程战略组成部分的所有当局。这些主体提供来自由其自身拥有或管理的安全关键系统的数据，此类数据可被视为安全且可信的。因此，主要威胁在于数据向云端传输以及云与边缘组件之间的传输和云端计算。然而，云层对系统核心功能的贡献并不关键，因为与现场活动相关的核心任务在边缘层运行，操作可回退到当前以人为中心的协调程序和传统通信；此外，系统的云层不会影响核心决策，因为它仅向现场状态提供附加信息。例如，云中或云与边缘之间的通信被篡改可能导致操作人员接收到有关建筑物布局或与其他力量在场地上协调的恶意信息，但操作人员的专业培训和交叉验证可降低使用错误信息的风险，因为当前战术操作的组织基于健全的政策，提供了备用程序。在此情况下，可通过采用成熟的安保方法（如移动目标防御[32]）来实施针对基于云的软件子系统的防御机制。

关于边缘层，由于系统基本对外部用户封闭，在任务期间可能发生的唯一云粒交换形式仅为将任务卸载到云端（例如图像或信号处理），因此针对计算和存储目标的攻击可能性主要取决于传输攻击的可能性，并可通过应用校验和与自验证技术加以最小化。此外，对于云层而言，部分软件组件的操作寿命可能跨越多个任务，而边缘层的任务时间限制了攻击者威胁系统完整性的有效时间窗口：只需在每次任务结束后进行重置（例如通过彻底更新或软件子系统的完全重建，这也有助于简化每次任务所需的重新配置过程），即可将威胁限制为仅能在巡逻进行期间发起并完成的基于传输的攻击。

在事故现场。我们假设系统可能会遭受拒绝服务攻击（例如，使用干扰器阻断传输），但此类攻击容易被检测到，并且可以立即采用传统的备用程序。只有端到端云卸载或迁移的情况可能带来重大风险，但目前为避免此风险，参考架构中并未使用该机制。

关于物联网层，主要威胁仍然是针对传输目标，可能通过向边缘服务器传输错误数据，破坏现场状态认知的完整性，从而危及任务。考虑到分配给前端站的所有设备在任务开始前均已知，可通过在将个人站和传感器节点组件与前端站配对时采用强认证机制，并对通信进行加密，以降低此类风险：为减少配置时间，配对过程可在巡逻队前往事故现场途中完成，或提前定义适当的准备流程，实现与具体任务无关的通用化预配置。由于本文提出的是参考架构和建模方法，详细的数值分析安全研究不在本文范围内，因为这需要对各组件提供详细规格。但总体而言，我们认为拒绝服务攻击并不关键，同样地，使个人站或传感器节点组件脱离系统的攻击也不严重，因为个人站和传感器节点组件可能因其他原因发生故障，而这并不会影响任务执行，传统消防程序作为可靠且成熟的备用服务级别，足以应对这种情况：在此情形下，拒绝服务攻击的效果等同于个人站和传感器节点的大范围失效，其后果和应对措施相同。至于更复杂的攻击，例如试图通过破解加密密钥来非法接入通信信道，则需考虑以下两点：首先，攻破其中一个组件只会导致单个被篡改的信息流，该信息流与其他正常信息不一致，易被前端站（必要时可由指挥中心协助）检测到；而针对前端站的威胁则与任何暴露在关键环境中的计算机所面临的威胁相同，因此可采用文献中的解决方案加以应对；其次，若攻击旨在篡改来自个人站和传感器节点的数据，则必须在远短于任务持续时间的时间内，成功地对每个个人站和传感器节点组件分别实施攻击，才能避免数据异常被检测出来，而此类攻击的影响还将受到为各个人站和传感器节点组件供电的电池寿命或操作过程中设备更换的限制。

任务期间进一步部署组件：我们认为这可以降低与计算机安全相关的风险，并将在未来工作中详细研究该问题。

6. 可靠性考虑

提出的系统（及其架构）是基于用户需求（即第一响应者）进行概念设计的，因此必须通过严谨的风险工程活动对其进行测试，并主要依据该活动的结果进行改进（相关论文将随后发表）。然而，目前已有部分思考旨在初步揭示一些潜在的关键问题，这些问题应被设计排除，以使提出的系统具备内在的安全性和可靠性。首先，是带宽问题。实际上，该系统要实现正确但尚未达到最优的运行（即有效支持应急人员和决策者），必须依赖于理想且稳定的带宽，否则其整体功能将受到损害。这一假设在偏远地区（例如远离高度城市化地区的小城市）可能并不现实。另一方面，当我们进入高度城市化地区时，物理屏蔽和电磁屏蔽也可能成为影响因素。

具有厚重墙体的老旧建筑，或采用创新建筑设计、使用厚实钢结构框架的现代新建筑，可能会阻碍通信信号在基础设施中的顺畅传输（即法拉第笼效应），从而影响整个系统的正常运行。另一个关键假设在于基于便携式电池的中央控制单元的正常工作，其可靠性可能远低于固定线路电力连接，因此需要配备不间断电源（UPS），而这可能带来一系列后果（如高成本和物流延迟）。除了这些与基础设施相关的潜在缺陷外，还可能存在与为整个系统提供数据的（边缘）传感器有关的问题，尤其是由第一响应者佩戴的传感器。在紧急情况下，第一响应者通常面临恶劣环境，高温和潮湿条件可能成为传感器暴露的常态。此外，传感器甚至可能遭遇强烈的机械环境（如高/低压力和扭转），而普通传感器（或未采用加固型外壳封装的传感器）未必能够承受这些条件。这可能导致系统接收到部分信息（

比完全缺乏信息更糟糕的情况是，它可能会轻易误导决策者。此外，还可能存在一种更为隐蔽且极其危险的情况，即由于电源故障（电压错误）导致传感器传输错误数据，进而传递粗大误差，也就是异常值。

除了这些基础设施限制外，还可能存在由恶意行为（例如恐怖分子、狂热分子和/或极端分子所实施的行为）导致的其他限制。系统频率受到干扰可能是其中的一种情景。因此，应通过抗干扰无线电围栏或有线解决方案（或两者结合）使系统具备抗干扰能力。从网络安全漏洞的角度考虑，有人可能会认为图2中提出的配置由于接入点数量较多而存在较大风险。

这一漏洞可能促使人们重新思考系统架构，转而采用更注重网络安全的方法，例如设置一个聚合PC，该PC在本地收集数据，并仅将远程决策者严格所需的信息发送至云。这种方案有可能一举两得：既提升了整体架构的安全性（因为只有一个接入点），又降低了对网络带宽的需求。

7. 性能建模与评估

7.1. 案例研究

所提出的案例研究是基于图2所示架构的系统。该基础设施能够映射大规模紧急事件的各个方面，通过第一响应者携带的传感器、远程操作车辆或网络传感器收集并传输数据。这些数据用于监测单个个体或单位难以直接测量的现象。所产生的信息经过实时处理和整合后，共享给在事故现场工作的所有专业人员，并传送给可能不在现场的决策者。通过这种方式，决策者能够在决策过程中获得更清晰、更安全的成效。特别是，我们的工作重点是第一响应者团队应对中大型事件的情况，例如CBRN场景所代表的事件。

来自不同组织（例如消防队、医疗援助、警察）的第一响应者同时参与应急响应的情况。通过赋予集中控制单元权力，负责管理并分配应对此类紧急情况所需的所有资源，我们相信响应效率将得到显著提升。现场数据由两类传感器采集：一类由专业人员佩戴（如佩戴传感器的消防员或第一响应者），包括健康传感器和反馈设备；另一类则部署在场景内部或周边的固定位置。第一类传感器可借助人类的智能与移动性，采集语义复杂的数据，否则这些数据可能需要复杂的硬件和软件处理算法才能获取。第二类传感器则是指已存在于建筑物中，或属于智慧城市或智能建筑系统的传感器，也可由消防队在行动过程中布置于关键位置，或远程操作的设备，例如无人机

或其他移动设备。在紧急情况中作业的专业人员也配备了增强现实显示器，使他们能够持续接收来自这两类传感器的关键信息。这些传感器设计为自主运行，即无需消防员采取任何操作即可工作。个人传感器对于团队负责人管理团队成员的安全和监控其性能至关重要。而环境传感器则对于绘制危险分布并预测其动态演化至关重要。最后一类信息可能对位于远程控制室的利益相关者和决策者更为重要。因此，在任务的不同阶段，这两类信息的重要性可能有所不同。

从传感器收集的数据与靠近事故现场的计算单元进行交换。这些服务器可以安装在支援车上并从中操作（即所谓的高级指挥所），并通过启发式方法和专门开发的算法对传感器原始输出进行适当汇总处理，最终生成风险图。

许多不同的设备与提出的系统交换数据。在图3中，我们给出了可用于应对复杂紧急情况的传感器生态系统的组织视图。

7.2. 建模与分析

我们使用图4所示的多类排队网络对所考虑的系统进行了建模。

该模型在不失一般性的前提下，考虑了一个包含单个前端站（EF）的场景。图4的左侧表示与前端站（EF）相连的传感器节点（SN）和个人站（PS）组件，而三个队列则代表系统的计算部分，由前端站（EF）、将前端站（EF）连接到其指挥中心（CB）的网络（Net），以及协调单元在云端执行的计算任务组成。所有由传感器节点（SN）和个人站（PS）产生的输入均由前端站（EF）处理，并生成云粒（cloudlets）：一部分云粒在本地执行，并导致与传感器节点（SN）和个人站（PS）的进一步交互；另一部分云粒需要访问云端，从而在网络中产生流量，并在指挥中心（CB）上产生工作负载，这可能由于协调单元的介入而在云端或前端站（EF）触发进一步的云粒执行。

由于结构简单及指令可能较为简单，传感器节点（SN）和个人站（PS）能够即时处理可能的指令，而协调单元则在云端作为黑盒进行处理，其运行特征化

因此，该行为应被视为引入请求与回复之间延迟的某些任务之一。

为了捕捉所有这些细节，我们考虑三类不同的任务：SN表示环境传感器，PS表示消防员佩戴的传感器，CC表示所有参与行动协调的力量在云服务器上的访问。我们将这三类的任务数量分别记为NSN、NPS和NCC。

无限服务器站点Sensor Network和Personal Support分别具有平均服务时间TSN和TPS，用于建模每个传感器读取、压缩并将数据发送到边缘服务器所需的时间，如模型的一般描述所述。同样地，Coordination Units建模了每个参与力量的平均时间TCC

操作需要在执行下一次查询之前分析从云读取的数据。排队站点Edge Frontend(EF)、Edge Network(Net)和Cloud Backend(CB)表示表征该系统的主组件，其排队行为可以详细描述，并有助于实际实现的规格定义。所有队列均采用处理器共享服务规则；Edge Network为单服务器，用于建模通信信道的共享，而Edge Frontend和Cloud Backend为多服务器。前者中，服务器数量CEF表示被部署到操作区域的边缘服务器数量，而后者中，服务器数量CCB表示支持应用云端部分的已配置虚拟机数量。

每个类别仅限通过其对应的无限服务器站点（即SN仅通过Sensor Network节点，依此类推）；此外，CC类只能通过Cloud Backend服务器。边缘服务器可以通过网络将部分读数发送到云：我们分别用pSN和pPS表示来自环境或可穿戴传感器的读数被路由到后端的概率。我们认为这两类均具有平均网络传输时间

TNet，而对于另一个站点，我们称Tx@y为类别x的作业在站点y所需的平均服务时间。

模型已通过平均值分析法(MVA)求解，在英特尔酷睿i5 2016款MacBook Pro上对所考虑的参数化进行计算仅需几秒钟。接下来，我们将在不同情景下研究该模型。表1汇总了模型参数的默认值：这些值由专家选定，以符合所考虑场景的典型值。

表1：默认模型参数

NSN= 15 CEF= 1 TSN = 0.1 s TSN@EF = 40毫秒 TSN@CB = 0.4 s pSN= 0.3	NPS= 5 CCB= 4 TPS= 0.1s TPS@EF = 80毫秒 T Net TPS@CB = 0.25 s pPS= 0.3	NCC= 12 TCC = 2 s = 15毫秒 TCC@CB = 0.6 s

在图5中，我们研究了如何为不同数量的传感器确定边缘前端服务器CEF=[1… 3]的数量，同时观察每个组件的吞吐量以及利用率（系统组件实际处于忙碌状态的时间比例）。为了简化研究，我们设定NSN= 3·NPS并改变NPS=[1… 10]。由于协调流量的存在，云计算节点几乎始终处于完全利用状态，但这似乎对边缘节点的性能影响不大，因为只有一小部分请求需要到达虚拟机。网络从未成为瓶颈。当救援团队成员数量超过NPS> 5时，边缘前端在CEF= 1情况下会成为瓶颈；而当边缘后端服务器数量增加时，该限制便不再存在。这表明，一个边缘服务器仅足以支持最多5名成员的团队。

接下来，我们研究可穿戴传感器和环境传感器数量比例对系统性能的影响。在图6中，我们设定NSN+ NPS= 20，并探索作为NPS=[1… 20]函数的所有可能配置。可穿戴传感器对边缘的处理需求更高，而环境传感器在云中的服务时间更长。因此，当NSN = 14和NPS = 6时，系统会出现瓶颈切换。这表明当NPS > 6时，

可以通过增加边缘服务器的数量来改进该系统，而当需要提供更多的虚拟机以提高吞吐量时。

然后我们在图7中研究了在边缘和云上分析的数据比例 pSN和pPS的影响。具体而言，我们设定pSN= pPS=[0.05… 0.95]，并考虑两种配置：I，其中NSN= 15和·NPS= 5，以及II，其中NSN= 5和NPS= 15。在此研究中，我们还考虑了网络的影响，分别设定了TNet= 15 ms（图7ab）和TNet= 150 ms（图7cd）。当网络延迟较低时，通信从不会成为瓶颈：随着边缘无法处理请求的概率增加，我们可以再次观察到瓶颈从边缘向云的转移。切换点受请求的服务需求影响显著：在配置I中，该切换发生得更早，因为该配置中有更多的传感器表现出对云服务器的高服务需求。当网络具有较高的传输时间时，在配置II中，瓶颈切换发生在边缘与网络之间，而在配置I中，仍发生在边缘与云之间。这导致了一些非常特殊的行为，例如非单调行为。

II配置下SN类吞吐量 我们通过考虑先前研究中使用的两种配置I和II下已配置的虚拟机数量CCB=[1… 8]的影响来继续我们的研究。在这两种情况下，超过某一阈值后增加虚拟机数量对系统性能的提升非常有限。该阈值取决于传感器生成的工作负载类型，并对应于边缘和云同时达到最大利用率的点：情况I为CCB= 4，情况II为CCB= 4。通过此类研究，可以确定虚拟机的最优数量。

我们最后研究了具有不同类型环境传感器（其特征在于不同的资源需求）的影响（图9）。具体而言，我们将类别SN拆分为SN1和SN2。类别SN1具有与之前研究中类别SN相同的特征，而TSN2@EF = 90 ms和TSN@CB = 15 ms。这两个类别的总数量为NSN1 + NSN2 = 15，且NPS = 5。为了更好地评估拆分环境传感器类别的影响，我们进行了两个不同访问概率的实验

云：I) pSNx= pPS= 0.1，以及II) pSNx= pPS= 0.7。同样，在边缘和云之间可能会发生瓶颈切换，但在这种情况下仅针对配置II，其中云的负载更高。图9a中的曲线NS1和NS2还显示了两类传感器对边缘利用率的各自贡献。少量2型传感器就能迅速增加对边缘服务器利用率的贡献：这表明在添加此类设备时应谨慎，因为它们可能迅速使系统的边缘组件达到饱和。

)

8. 结论

本文中，我们展示了一个有趣的边缘计算应用实例，该应用基于一种在复杂紧急情况管理中具有重要意义的物联网架构。由于其作为关键系统的特性，本文首先讨论了所提出解决方案的安全性和可靠性，以提供支持进一步探索和更详细分析该设计可行性的依据。尽管从建模角度来看，该系统并未带来新的挑战，且可使用传统技术进行分析，但其具有非常独特的运行行为，因此必须采用性能评估技术来正确配置和扩展该架构。本文展示了如何使用多类排队模型进行分析：未来的工作将研究多种数据带来的影响，并通过采用不同的建模技术来考虑更大规模的系统。