简介：SimpleIoTSimulator-master是一套面向边缘计算研究与物联网开发者的轻量级仿真平台，用于在本地模拟IoT设备与边缘节点的协同行为，帮助验证任务卸载、资源调度与网络性能等关键问题，适合具备一定Node.js基础、希望快速搭建实验环境的学生和工程师。压缩包共6个文件，以2个JavaScript源码文件和2个JSON配置为主，另含说明文档与忽略规则文件，整体仅16KB，结构精简、开箱即用。平台围绕设备模拟、边缘节点建模、网络条件设定、负载均衡与资源调度、安全隐私测试及实时性能分析等方向提供可扩展的模块化设计，便于按需添加新设备模型或算法。已有1066人学习下载，读者可借此理解边缘计算架构的复杂度，开展小规模性能评估与策略对比，为后续算法优化和场景扩展提供可复用的实验基础。
1. 边缘计算仿真平台到底在仿什么：从 SimpleIoTSimulator 说起
边缘计算（EC）这个词这几年被工业互联网和 5G 场景反复提及，但真正动手时你会发现一个尴尬的现实：手头没有网关、没有传感器阵列、没有现场总线，怎么验证自己的边缘侧调度逻辑、数据聚合策略、断网续传机制到底能不能跑？SimpleIoTSimulator 这类仿真平台就是冲着这个缺口来的。它把边缘节点上常见的设备接入、数据采集、协议转换、本地决策这几层用软件模拟出来，让你在一台笔记本上就能搭出一个「缩小版边缘现场」。这个方案适合两类人：一是做边缘网关固件或边缘应用开发的工程师，需要在不依赖真实硬件的前提下反复调试逻辑；二是做工业互联网实训或教学的人，需要一套可复现、可拆解的实验环境。它不能替代真实硬件的时序验证和电磁兼容测试，但在功能验证和逻辑推演阶段，能省掉大量「等设备到货」的时间。
2. SimpleIoTSimulator 的仿真架构与核心组件拆解
2.1 边缘侧仿真的三层结构：设备层、网关层、云侧对接层
SimpleIoTSimulator 的仿真逻辑并不复杂，但分层很清晰。设备层负责模拟各类传感器和执行器，比如温度、湿度、振动、开关量，每个虚拟设备有自己的数据生成策略——可以是恒定值、正弦波动、随机游走，也可以按预设脚本触发突变。网关层是核心，它模拟边缘节点的行为：接收设备数据、做协议适配（常见的是 MQTT、Modbus TCP、CoAP 之间的转换）、执行本地规则引擎、决定哪些数据上报、哪些本地留存。云侧对接层则模拟一个轻量级的云端接收端，通常就是一个 MQTT Broker 加一个简单的数据落盘或可视化面板。
这种三层结构的价值在于：你可以单独替换某一层来验证假设。比如你怀疑网关的规则引擎在设备数量超过 50 个时会出现消息积压，那就在设备层把虚拟设备数调到 50 以上，观察网关层的队列深度和云侧接收延迟。又比如你想验证断网续传，直接在网关层切断上行链路，看本地缓存策略是否按预期工作。
2.2 设备模拟与数据生成：虚拟传感器的参数怎么设
设备模拟的配置通常落在一个 YAML 或 JSON 文件里，每个虚拟设备定义自己的类型、采样周期、数据范围、上报协议。下面是一个典型的设备配置文件片段：
devices: - id: temp_sensor_01 type: temperature protocol: mqtt topic: edge/sensor/temp/01 interval_ms: 1000 generator: mode: sine base: 25.0 amplitude: 5.0 period_s: 60 qos: 1 - id: vibration_sensor_01 type: vibration protocol: modbus_tcp slave_id: 1 register: 40001 interval_ms: 500 generator: mode: random_walk start: 0.5 step: 0.05 min: 0.0 max: 10.0这段配置里几个参数值得展开说。interval_ms决定采样和上报频率，设得太密会压垮网关的消息队列，设得太疏又可能漏掉瞬态事件。我一般会按真实场景的 1/10 到 1/5 来设，比如真实传感器 100ms 上报一次，仿真里先设 500ms 到 1s，跑通逻辑后再逐步收紧。generator.mode决定数据形态，sine适合模拟环境量的周期性变化，random_walk适合模拟缓慢漂移的振动或压力信号。qos只在 MQTT 协议下有效，0 表示最多一次、1 表示至少一次、2 表示恰好一次，仿真阶段用 1 就够了，2 会引入额外的握手开销，拖慢整体节奏。
2.3 网关侧规则引擎：本地决策逻辑的仿真方式
网关层的规则引擎是 SimpleIoTSimulator 里最值得花时间调的部分。它通常支持条件触发和定时聚合两类规则。条件触发比如「温度超过 30 度且持续 5 秒，则上报告警并触发本地风扇控制信号」；定时聚合比如「每 10 秒把过去 10 秒内的振动数据取最大值和均值，打包上报」。
规则一般用类 SQL 或类 JSON 的 DSL 来描述，下面是一个条件触发的例子：
{ "rule_id": "high_temp_alert", "trigger": { "condition": "temp_sensor_01.value > 30.0", "duration_s": 5, "cooldown_s": 30 }, "actions": [ {"type": "publish", "topic": "edge/alert/temp", "payload": "{{temp_sensor_01.value}}"}, {"type": "local_control", "target": "fan_01", "command": "on"} ] }duration_s表示条件需要持续满足多久才触发，这个参数是防抖的关键。没有它，温度在阈值附近抖动时会疯狂触发告警。cooldown_s是冷却时间，避免同一告警在短时间内重复上报。这两个参数在真实边缘网关里也常见，仿真阶段把它们的值调小（比如 duration 设 2 秒、cooldown 设 10 秒），可以加快调试循环。
2.4 云侧对接与数据落盘：MQTT Broker 和时序库的最小配置
云侧对接层通常就是一个 MQTT Broker（比如 Mosquitto 或 EMQX 的轻量模式）加一个订阅客户端，把数据写到本地文件或时序数据库。仿真阶段不需要上重型时序库，用 SQLite 或 CSV 就够。下面是一个 Python 订阅端的骨架：
import paho.mqtt.client as mqtt import sqlite3 import json from datetime import datetime conn = sqlite3.connect('edge_sim_data.db') cur = conn.cursor() cur.execute('''CREATE TABLE IF NOT EXISTS sensor_data (ts TEXT, device_id TEXT, value REAL, topic TEXT)''') def on_message(client, userdata, msg): payload = json.loads(msg.payload.decode()) cur.execute("INSERT INTO sensor_data VALUES (?,?,?,?)", (datetime.now().isoformat(), payload.get('id'), payload.get('value'), msg.topic)) conn.commit() client = mqtt.Client() client.on_message = on_message client.connect("localhost", 1883, 60) client.subscribe("edge/sensor/#") client.loop_forever()这段代码的关键在于订阅通配符edge/sensor/#和落盘时的字段映射。仿真阶段数据量不大，直接同步写 SQLite 没问题；但如果虚拟设备超过 100 个、上报间隔小于 500ms，建议改成批量提交或换用写入更快的存储。另外注意payload的解析要跟设备配置里的数据格式对齐，否则会出现字段缺失或类型错误。
3. 从零跑通一个边缘仿真场景：环境搭建与最小闭环
3.1 环境准备：Python 版本、依赖包与 Broker 安装
SimpleIoTSimulator 这类工具通常以 Python 项目形式组织，对版本有一定要求。我一般用 Python 3.9 到 3.11 之间的版本，太新的版本有时会遇到依赖包兼容问题。核心依赖包括paho-mqtt（MQTT 通信）、pymodbus（Modbus TCP 仿真）、pyyaml（配置文件解析）、sqlite3（Python 内置，无需额外安装）。Broker 用 Mosquitto 最省事，Windows 和 Linux 都有现成安装包。
安装命令如下：
# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装核心依赖 pip install paho-mqtt pymodbus pyyaml # 启动 Mosquitto（Linux 示例） mosquitto -c /etc/mosquitto/mosquitto.conf -d这里有个容易翻车的点：Mosquitto 默认配置只监听本地回环地址，如果你把仿真程序跑在另一台机器上，需要改配置文件里的listener和allow_anonymous设置。仿真阶段为了省事，可以直接用mosquitto -p 1883启动一个允许匿名连接的实例，但别把这个配置带到任何对外的环境里。
3.2 启动设备模拟器与网关进程：命令行参数与日志观察
设备模拟器和网关通常是两个独立进程，可以分开启动、分开观察日志。设备模拟器的启动命令一般长这样：
python device_simulator.py --config devices.yaml --broker localhost --port 1883 --log-level INFO网关进程的启动类似：
python edge_gateway.py --config gateway.yaml --broker localhost --port 1883 --rules rules.json --log-level DEBUG启动后重点看三类日志：设备侧的上报计数、网关侧的规则触发记录、云侧的接收确认。如果设备侧显示上报成功但云侧收不到，优先检查 topic 是否匹配、QoS 是否一致、Broker 是否真的在监听。我习惯在网关日志里加一行「当前队列深度」的输出，跑起来后盯着这个数字，如果它持续增长不回落，说明消费速度跟不上生产速度，需要调大网关的 worker 数或降低设备上报频率。
3.3 验证数据链路：从虚拟传感器到本地库的端到端检查
最小闭环跑通的标准是：虚拟传感器产生数据 → 网关接收并执行规则 → 云侧订阅端落盘 → 数据库里能查到符合预期的记录。验证时不要只看「有没有数据」，要看数据的时间戳间隔是否稳定、数值范围是否在配置的区间内、告警规则是否在正确的时间点触发。
一个实用的检查脚本是直接查 SQLite：
import sqlite3 conn = sqlite3.connect('edge_sim_data.db') cur = conn.cursor() cur.execute("SELECT device_id, COUNT(*), MIN(value), MAX(value) FROM sensor_data GROUP BY device_id") for row in cur.fetchall(): print(f"设备 {row[0]}: 记录数 {row[1]}, 最小值 {row[2]:.2f}, 最大值 {row[3]:.2f}")如果某个设备的记录数明显少于预期，先查它的interval_ms和网关的规则是否把它过滤掉了。如果最大值或最小值超出配置范围，检查generator的参数是否写错，尤其是min和max的边界。
4. 仿真参数调优与典型场景配置
4.1 设备数量与上报频率的平衡：队列积压的临界点在哪
仿真环境里最容易失控的两个变量就是设备数量和上报频率。它们对网关的压力是乘积关系：50 个设备、每个 1 秒上报一次，网关每秒要处理 50 条消息；如果设备数不变、频率提到 100ms，压力直接变成 500 条/秒。我在一台 4 核 8G 的笔记本上实测，用 Python 写的网关进程处理 MQTT 消息，单 worker 的舒适区大概在 200 到 300 条/秒，超过这个量级队列深度就会开始爬升。
调优的顺序建议是：先固定设备数，逐步收紧上报间隔，找到队列深度开始持续增长的临界点；然后固定上报间隔，逐步增加设备数，找到另一个临界点。两个临界点里较小的那个，就是你当前硬件和代码结构下的安全上限。仿真阶段没必要追求高吞吐，重点是让逻辑在可控压力下暴露问题。
4.2 断网续传与本地缓存：仿真里怎么模拟网络抖动
断网续传是边缘计算的核心价值之一，仿真里模拟这个场景有两种做法。一种是直接在网关进程里加一个「上行开关」，通过信号或配置文件动态切断 MQTT 发布；另一种是用系统防火墙规则临时阻断 Broker 端口。前者更可控，推荐用前者。
模拟逻辑大致是：网关检测到上行不可用后，把待上报数据写入本地队列（内存队列或 SQLite 表），同时启动一个重试定时器；上行恢复后，按时间顺序把缓存数据补发出去。仿真时重点观察三个指标：缓存是否溢出、补发是否有序、补发期间新数据是否被阻塞。我见过最常见的翻车是缓存队列设了固定长度，断网时间一长就丢数据，而真实边缘网关通常会设一个磁盘缓存兜底。
4.3 多协议混合场景：MQTT 与 Modbus TCP 共存时的配置要点
工业现场很少只用一种协议，仿真平台通常也支持 MQTT 和 Modbus TCP 混合。配置时的关键点是协议适配层要统一数据模型：Modbus 的寄存器地址和 MQTT 的 topic 最终都要映射到同一个内部数据结构上，否则规则引擎没法统一处理。
一个常见的配置错误是 Modbus 的slave_id和register地址跟真实设备对不上。仿真阶段虽然没有真实设备，但如果你打算把仿真配置直接迁移到现场，地址映射必须提前对齐。我一般会在配置文件里加一列注释，写明每个寄存器对应的物理量，迁移时直接照抄。
5. 避坑与排查：仿真跑不起来时先查这几处
5.1 现象：设备日志显示上报成功，云侧一条数据都收不到
原因通常有三个：topic 不匹配、QoS 不一致、Broker 监听地址不对。设备发到edge/sensor/temp/01，云侧订阅的是edge/sensor/temperature/#，这种拼写差异在日志里不会报错，但数据就是到不了。QoS 不一致的情况少一些，但如果设备用 QoS 2、云侧用 QoS 0，某些 Broker 实现下会出现消息被丢弃。Broker 监听地址的问题更隐蔽：设备连的是localhost，云侧连的是127.0.0.1，在大多数系统上等价，但在某些容器或虚拟网络环境下会解析到不同接口。
解决步骤：先用mosquitto_sub -t '#' -v订阅所有 topic，看设备消息到底发到了哪个 topic 上；然后核对云侧订阅表达式；最后确认 Broker 的listener配置和两端连接地址。
5.2 现象：规则引擎频繁触发告警，日志被刷屏
这是典型的防抖参数没设好。duration_s设成 0 或太小，温度在阈值附近抖动时就会反复触发。另一个可能是cooldown_s缺失，同一告警在短时间内重复上报。
解决：把duration_s调到至少 2 到 3 个采样周期，cooldown_s设成告警恢复后预期稳定时间的 1.5 倍左右。仿真阶段可以先用大一点的值把逻辑跑通，再逐步收紧到接近真实场景。
5.3 现象：网关进程内存持续增长，跑几小时就崩
原因通常是消息队列没有上限，或者本地缓存只写不清理。Python 的queue.Queue()默认是无界的，生产速度大于消费速度时内存会一直涨。本地 SQLite 缓存如果没有定期归档或删除策略，文件也会越来越大。
解决：给队列设maxsize，满了之后要么阻塞生产、要么丢弃最旧数据（取决于业务容忍度）；本地缓存加一个按时间或条数的清理任务，仿真阶段可以设成保留最近 1 小时数据。
5.4 现象：Modbus 仿真设备连不上，报超时或非法地址
先查slave_id和register地址是否在合法范围内。Modbus TCP 的寄存器地址通常从 0 或 1 开始，不同库的约定不一样，pymodbus里用0基地址，而有些配置文件写的是40001这种 1 基地址，直接混用就会报非法地址。另外确认仿真器监听的端口没有被其他进程占用，Modbus TCP 默认是 502，这个端口在 Linux 上需要 root 权限才能绑定。
解决：统一地址基准，在配置文件里注明用的是 0 基还是 1 基；端口换成 5020 或更高的非特权端口做仿真。
5.5 现象：数据落盘后发现时间戳乱序或重复
时间戳乱序通常是因为多个设备或网关的 worker 并发写入，没有做全局排序。重复则可能是 QoS 1 的「至少一次」语义导致的，Broker 重发时消费端没有做去重。
解决：落盘时加一个自增主键或联合唯一索引（设备 ID + 时间戳 + 序列号）；消费端维护一个最近消息 ID 的滑动窗口做去重。仿真阶段如果对顺序不敏感，可以先用单 worker 串行消费来规避。
6. 进阶：用仿真平台做边缘侧规则引擎的压力测试与回归验证
仿真平台的价值不止于「跑通」，更在于「反复跑、换着法子跑」。我后来养成了一个习惯：每次改完网关的规则引擎代码，先不急着上真实硬件，而是在 SimpleIoTSimulator 里跑一轮回归。具体做法是准备三套设备配置——一套正常负载、一套高频突发、一套断网恢复——每套跑 10 分钟，对比规则触发次数、消息延迟分布、缓存命中率这三个指标。如果某套配置下指标跟上一版差异超过 10%，就说明改动可能引入了回归。
压力测试的另一个技巧是「阶梯加压」：从 10 个设备开始，每 2 分钟增加 10 个，直到队列深度持续超过 1000 或进程内存超过设定上限。记录下崩溃前的最大设备数和对应吞吐量，这个数字就是你当前代码结构的真实天花板。我自己的经验是，Python 写的规则引擎在单进程下很难撑过 500 条/秒的持续吞吐，真要往上走，要么换语言，要么把规则引擎拆成多进程按设备 ID 分片。
还有一个容易被忽略的验证点是「规则冲突」。当多条规则同时命中同一个设备数据时，执行顺序和副作用需要明确。仿真里可以故意配置两条互相矛盾的规则（比如一条让风扇开、一条让风扇关），观察最终状态是否可预期。这种测试在真实硬件上代价很高，但在仿真里就是改几行配置的事。
最后说个我踩过的坑：仿真跑得太顺，容易让人产生「真实环境也这样」的错觉。真实边缘网关的 CPU 是 ARM 低功耗核、内存可能只有 512MB、磁盘是 eMMC，这些约束在笔记本上完全感受不到。所以我的习惯是，仿真验证逻辑，真机验证资源。仿真里把规则引擎的 worker 数设成 1、队列上限设成 1000，提前感受一下「紧巴巴」的滋味，迁移到真机时心里才有底。希望帮到你。
本文还有配套的精品资源，点击获取
