简介：iFogSim-master.zip 是一份面向边缘计算研究场景的开源仿真平台源码包，适合需要低成本验证边缘任务调度、资源分配与网络拓扑策略的开发者、研究生及相关工程师。压缩包共353个文件，约29.58MB，主体是289个Java源文件，承担仿真核心逻辑；另有30张PNG图片用于拓扑与结果可视化、7个JAR运行依赖库、6个XLSX实验数据表，整体目录结构清晰，可直接导入Eclipse或IntelliJ IDEA开展二次开发。项目基于Java构建，支持自定义节点类型、服务策略与仿真参数，便于复现边缘计算场景并评估性能；包内还包含实验拓扑定义、示例场景与结果记录，能够帮助使用者快速理解边缘计算建模、任务调度与资源分配效果。目前已有1498人学习，对入门边缘计算仿真、基准实验复现或扩展自有算法均有参考价值。

1. 边缘计算仿真平台是什么，以及 iFogSim 能解决什么问题

边缘计算项目最尴尬的阶段，不是选型也不是部署，而是“算不清楚”。边缘节点数量一多，消息路径就复杂，设备间延迟、模块放置位置、网络带宽占用、功耗成本这些指标互相牵制。真机验证当然最准，但硬件没到位、现场环境不可控、两三台设备的数据又很难代表整体行为，这时候就需要一个边缘计算仿真平台先把方案跑通。iFogSim 正是这类工具里最常见的一个选择，它由 CloudSim 扩展而来，在离散事件模拟内核上增加了边缘设备、传感器、执行器、应用模块和数据流模型，适合在拿到硬件之前回答三个问题：模块放在哪一层、任务端到端延迟大概多少、整套资源消耗和费用是什么水平。本文围绕 iFogSim-master.zip 这个开源工程，讲清楚它的核心模型、本地跑通方式、负载与调度实验方法，以及判断仿真结果是否可信的边界。

2. iFogSim 的核心模型：事件内核、三层拓扑与模块放置

2.1 离散事件驱动内核：为什么仿真结果可以复现

iFogSim 继承自 CloudSim，底层是一个离散事件模拟器。真实边缘环境里，CPU 抢占、网络拥塞、散热降频这些噪声混在一起，同样的指令在不同时刻执行时长不一样；离散事件模拟则把时间切成带时间戳的事件，仿真时钟按照事件顺序往前推进，而不是按真实 CPU 时间流动。

这个设计带来的好处是可控性。iFogSim 里的每个节点都是一个 SimEntity，实体之间通过消息传递交互，消息在仿真时钟的驱动下排队、转发、处理。实验跑出来的延迟、能耗、费用完全由配置参数决定，同样的输入一定得到同样的输出。对比真机压测，这种方式牺牲了一部分真实性，换来了可重复的对照实验能力。做边缘计算仿真平台选型时，事件驱动是第一个要确认的架构特征；没有这个内核，后面所有调度对比都没有统计意义。

2.2 物理拓扑中的核心类：FogDevice、Pe、Sensor 与 Actuator

在 iFogSim 中，物理拓扑由一组设备节点组成。云端数据中心和边缘节点统一建模为 FogDevice，它们之间的差异只体现在资源配置和网络参数上。FogDevice 内部包含多个 Pe（Processing Element），每个 Pe 有独立的 MIPS 计算能力；设备本身有内存、存储、带宽上限，还挂着一个功率模型。Sensor 负责产生数据流，Actuator 负责接收最终结果。

类名	对应职责	常见配置关注点
FogDevice	云或边缘节点	MIPS、内存、上行下行带宽、功耗模型
FogDeviceCharacteristics	设备静态特征	架构、操作系统、单位计费价格
Pe	处理单元	MIPS 大小，决定模块执行速度
Sensor	数据源	发送间隔、tuple 长度、目标模块
Actuator	结果接收端	绑定输出 tuple，标记仿真终点
Sensor 与 Actuator 对应数据流入口和出口

设备之间的网络用带宽和延迟建模。创建 FogDevice 时需要指定上行带宽与下行带宽，连接关系决定数据从 Sensor 出发后经过哪些节点才能到达目标模块。在使用这个边缘计算仿真平台时，最容易犯的错误是只调 MIPS 不调带宽，导致仿真结果里瓶颈永远在计算侧，真实系统里常见的网络拥塞完全没有体现。

2.3 逻辑拓扑与 ModuleMapping：模块放置策略的入口

物理拓扑描述有哪些设备，逻辑拓扑描述应用由哪些模块组成。一个典型的视频分析应用可以拆成摄像头采集模块、图像预处理模块、识别分析模块、结果存储模块。iFogSim 用 AppModule 表示这些模块，AppEdge 表示模块之间的数据流向。

真正决定系统行为的是模块被放到哪台设备上。ModuleMapping 负责维护这个映射关系，它也是调度策略最直接的入口。常见的做法是先创建一个 ModuleMapping 实例，然后把模块绑定到指定设备：

ModuleMapping moduleMapping = ModuleMapping.createModuleMapping();
moduleMapping.addModuleToDevice("camera-preprocess", "edge-gateway");
moduleMapping.addModuleToDevice("video-analysis", "cloud");
moduleMapping.addModuleToDevice("video-storage", "cloud");

这段代码把预处理模块放在边缘网关，把分析模块和存储模块放到云端。 addModuleToDevice 的第一个参数是应用内模块名，第二个参数是物理拓扑中 FogDevice 的名字。需要特别注意的是，模块名必须和 Application 中定义的 AppModule 名称完全一致，否则 iFogSim 在构建仿真时会直接抛异常。

模块放置位置直接决定链路长度。预处理放边缘，摄像头到预处理这一跳延迟低；分析放云端，预处理到云端的路径要经过边缘网关，延迟就会被上行带宽和中间节点数量影响。所以做优化实验时，ModuleMapping 就是最常改动的对象。

2.4 能耗与费用模型：仿真报告里的数字怎么来的

边缘计算仿真平台除了算延迟，还要回答“这套方案耗多少电、花多少钱”。iFogSim 的能耗模型由功率模型提供，设备根据当前 CPU 利用率计算功耗。常见的线性模型假设空转功率和满载功率之间存在线性关系，负载越高功耗越大，这是一种近似，但对方案对比足够用。

费用模型则拆成计算、内存、存储、带宽四部分，分别按单位时间或单位容量计价。FogDeviceCharacteristics 里可以设置每 MIPS 单价、每 MB 内存单价等参数，仿真结束后统计各设备的使用量并汇总费用。

这里要提醒一点：iFogSim 默认能耗与费用模型都比较粗糙，线性功耗模型不包含散热、风扇、网络设备功耗。把仿真输出的费用当预算是可以的，拿它和云厂商账单逐一核对就过度解读了。相对比较才是这类模型的价值。

3. 把 iFogSim-master.zip 跑通：最小拓扑、资源参数与输出解读

3.1 环境准备：解压工程与 Maven 构建

iFogSim-master.zip 解压后是一个标准 Maven 工程，整个构建流程可以这样完成：

unzip iFogSim-master.zip
cd iFogSim-master
mvn -q clean package -DskipTests

构建成功后，目标目录下会生成可执行的 jar 包。运行官方示例时，我一般直接用 Maven exec 插件，让它自动装配 classpath：

mvn exec:java -Dexec.mainClass="examples.TestFogSimulation"

这里 exec.mainClass 指向官方示例的入口类。不同版本示例类名可能不同，如果运行报类找不到，先检查 examples 目录下实际有哪些类，再替换类名。

环境方面需要特别注意 JDK 版本。iFogSim 依赖的 CloudSim 调度代码大量使用 Java 反射和默认类加载机制，JDK 17 下可能出现模块化访问报错。我一般直接使用 JDK 8 或 JDK 11 构建和运行，省去一堆兼容性麻烦。如果遇到 IllegalAccessError 或者 ClassNotFoundException，先确认当前 JDK 版本，再决定是降级还是加 JVM 参数。

3.2 修改官方示例：建立两设备一模块的最小拓扑

跑通官方示例只是第一步，真正做事时要把它改造成自己的拓扑。iFogSim 官方示例通常包含三个方法： createFogDevices 创建设备， createApplications 创建应用， createModuleMapping 建立放置映射。最小实验只需要一台云设备、一台边缘设备和一个分析模块。

ModuleMapping moduleMapping = ModuleMapping.createModuleMapping();
moduleMapping.addModuleToDevice("analysis", "edge");

注意这里 "edge" 必须和物理拓扑里 FogDevice 的名称一致。如果创建设备时命名为 edge-node ，这里写成 edge ，仿真会在启动阶段直接失败。我实际排查过这类问题，日志里通常会出现 “cannot find device” 之类的信息，但还是建议把设备名集中在常量类里维护，避免拓扑变大后映射散落各处难以检查。

设备资源配置是实验的关键。下面表格列出我在最小实验里常用的初始参数，单位参考 iFogSim 默认设定：

参数	云节点	边缘节点	调整影响
MIPS	40000	12000	影响模块执行时间
内存	4096 MB	2048 MB	内存不足时任务排队或失败
上行带宽	10000 Mbps	1000 Mbps	影响数据上云延迟
下行带宽	10000 Mbps	1000 Mbps	影响结果回传延迟
功耗模型	高功耗	低功耗	影响总能耗

从边缘节点到云端节点的链路延迟也需要设定，iFogSim 在构建设备连接时通过链路参数传入。这个值直接影响端到端延迟输出，我建议根据真实网络环境做估算，别拍脑袋乱填。

3.3 输出结果怎么读：延迟、执行时间和费用

运行仿真后，控制台会输出设备间延迟、执行时间、能耗和费用等指标。iFogSim 的输出项很多，但边缘计算实验真正需要优先看的是下面几个：

• DDT（Device to Device Time）：数据从源设备到目标设备的传输时间，衡量网络路径质量
• 执行时间：模块实际处理任务消耗的仿真时间，衡量计算资源配置是否合理
• 总能耗：所有设备功耗累积值，决定方案是否“绿色”
• 总费用：资源占用计费总和，决定方案是否“划算”

需要注意的是，输出里的“执行时间”和真实系统的响应时间不是一回事。iFogSim 的输出时间是仿真时钟时间，只反映模型内的事件处理顺序，不包含操作系统调度、JVM GC 等真实开销。做方案对比时，用同一个仿真平台、同样的网络模型，对比结果才有意义；把输出值直接当作生产环境 P99 延迟来用，会让后续决策失真。

4. 用 iFogSim 做负载实验：改发送间隔、调放置策略、读对指标

4.1 负载注入：改变 Sensor 发送间隔与 tuple 规格

很多刚接触这个边缘计算仿真平台的人，会把精力全花在改设备参数上，忽略了负载本身才是影响系统行为的主要变量。Sensor 产生数据流的频率和大小直接决定模块排队长度和网络占用。

调整负载的常用手段是修改 Sensor 的发送间隔和 tuple 规格：

sensor.setTupleSendingInterval(500);
sensor.setTupleCpuLength(2000);

第一行把发送间隔设为 500 个仿真时间单位，数值越小，单位时间内进入系统的数据越多。第二行设置每个 tuple 所需的 CPU 长度，单位是 MIPS，数值越大，每个模块实例处理单个数据要消耗的计算资源越多。

模拟真实边缘场景时，固定间隔并不够。传感器采集频率往往有突发性，车辆检测、工业质检这类负载在事件发生时会出现短期峰值。更真实的做法是创建多个不同发送间隔的 Sensor，指向同一个模块，用不同频率叠加出负载波动。

4.2 调度策略对比：硬编码映射与放置策略扩展

负载确定之后，调度策略是下一个实验变量。最直接的方式是改 ModuleMapping：

moduleMapping.addModuleToDevice("analysis", "edge");

把 "edge" 改成 "cloud" ，就能得到“全部模块放云端”的对照数据。这个改动最小，适合快速验证模块位置的影响。

但如果想实现更细的放置策略，比如“边缘节点剩余 CPU 够用就放边缘，否则放云端”，就需要动放置策略逻辑。iFogSim 的模块放置决策发生在 PlacementPolicy 实现类中，系统在仿真开始时根据当前资源状态决定每个模块的最终部署位置。

我一般不建议新手直接从策略类下手，因为放置逻辑依赖设备资源初始状态，改不好会影响整个拓扑构建。更稳的做法是保留默认策略，通过多组 ModuleMapping 硬编码映射做对比实验。等对照数据积累到一定程度，确认问题出在“不知道该放哪”而不是“策略执行有 Bug”，再进入策略层改造。

4.3 一组成体系的实验：云上放置与边缘放置的指标对比

实验环境准备完成后，设计一组最简单的对照实验。应用包含一个 analysis 模块，数据源固定，分别运行两组仿真：第一组把模块映射到云端，第二组映射到边缘节点。实验记录指标如下：

实验组	映射位置	端到端延迟	总能耗	总费用
基线 A	cloud	偏高，受上行带宽限制	云节点功耗占比大	高，云端资源单价高
实验 B	edge	偏低，减少一次网络传输	边缘节点功耗占比大	低，边缘资源更便宜

真实结果会因为 MIPS、带宽和功耗模型参数不同而波动，但趋势通常是：全部放云端的方案延迟高、能耗集中、费用高；放边缘的方案延迟低，但边缘设备资源有限，负载一高就会排队。这两组数据拉开后，就能进一步分析需要多少个边缘节点才能满足延迟约束，这就是从“能不能跑”进入“容量规划”阶段的关键一步。

4.4 常见问题排查：从日志顺藤摸瓜

跑仿真时最容易遇到几类问题。拓扑不连通导致的模块访问失败可以通过检查设备名称是否一致来排查；MIPS 配置过低导致的模块处理能力不足，日志里会有任务等待时间过长的现象；仿真时间异常短或异常长，要检查是否有模块没有接到任何数据流。

我常用的排查路径是先确认日志数据源是否已经连上目标模块，再看目标模块所在设备资源是否足够，最后到 ModuleMapping 确认路径上没被网络参数卡住。iFogSim 日志不像生产系统那么完善，经常要靠加打印或简化拓扑来定位问题。

5. 批量跑参数与结果可信性检查：把仿真当决策辅助而不是真理

当实验从“跑通一次”进入“调整参数反复验证”阶段，逐条改配置再手动跑的方式会消耗大量精力。一个可行的做法是写一个简单的循环脚本，把关键参数传进去，批量运行并收集结果。

Maven exec 插件可以结合命令行参数使用：

for edge_mips in 4000 8000 12000; do
  mvn -q exec:java -Dexec.mainClass="examples.TestFogSimulation" \
    -Dexec.args="$edge_mips" > "logs/edge_${edge_mips}.log" 2>&1
done

这个脚本循环调用三次仿真，分别把边缘节点 MIPS 设为 4000、8000、12000，输出写入不同日志文件。 exec.args 会把参数传给主函数，主函数内可以用 args[0] 读取并传给 createFogDevices 方法。批量日志准备好之后，就可以用脚本抽取关键指标：

grep -h "total execution time" logs/*.log | awk '{print $NF}' > execution_time.csv

把每次实验的执行时间汇总到 CSV 文件，后续用 Excel 或任意文本工具都能画趋势线。

拿到这些指标后，下一步是验证数据可查的 95 分位延迟等统计量。iFogSim 默认输出并不是一个个独立延迟样本，而是汇总值，所以不能直接算分位数。为了拿到分布，需要在代码里把每条 tuple 的端到端时间记录下来，再导出文本文件。Python 处理这种文本很顺手：

import sys

vals = [float(x) for x in open(sys.argv[1]).read().split()]
vals.sort()
p95 = vals[int(len(vals) * 0.95)]
print(f"p95 latency: {p95:.2f}")

这段代码把文件里的延迟数值读取、排序，并按排序位置取 95 分位。注意这只是近似算法，样本量小时会略有偏差，但对方案比较足够。

结果可信性检查有三条原则。第一条是空负载基线：先跑一个没有任何数据源的仿真，确认系统自身开销不会影响结果。第二条是对照链路延迟：手算一下数据包大小和带宽的比值，对比仿真输出的传输时间是否在同一数量级。第三条是相对比较优先于绝对比较：iFogSim 输出的能耗数字只能和同平台其他实验对比，不能直接等同于真实电表读数。

边缘计算仿真平台的价值不在于给出精确预测，而在于把“模块放边缘还是云端”这类问题变成一个可以快速重复验证的决策流程。先用官方示例定基线，再逐项加负载，折腾的是指标而不是服务器，这才是仿真最值得花时间的地方。

本文还有配套的精品资源，点击获取