简介：这是一份BACnet模拟器及配套源码工具包，面向楼宇自控工程师、系统集成商及BACnet协议初学者，用于在没有实体设备的情况下完成设备模拟、网络调试、协议验证与故障排查。资源共1650个文件，总大小约103.61MB，核心为Python源码（1072个py与423个pyc），辅以rst/txt说明文档、exe可执行程序和xml配置等，既可直接运行，也可阅读二次开发。其中包含Windows版BACnet Explorer安装包与BACpypes项目源码，后者是Python实现的BACnet协议栈，方便开发者对接设备、构造报文并验证标准一致性。该包还涵盖虚拟环境、脚本及构建配置，适合搭建本地测试台，开展网络流量、设备故障和恢复等情景模拟。目前已有400人学习下载，对备考、研发调试和教学演示都具有较高参考价值。 做楼宇自控系统集成的朋友，应该都有过这种体验：项目现场设备还没到齐，BMS平台却急着联调，第三方冷机、电表、水表的协议文档倒是给了一堆，真机却连影子都见不着。等设备到了再测逻辑，现场施工时间早就被压缩得所剩无几。我的解决办法是自己动手写了一个 BACnet 设备模拟器，用软件把现场要对接的虚拟设备跑起来，先让平台侧把点位、报警、时间表全部调通。这篇文章就把这个模拟器的设计思路、核心实现和我在实战中踩过的坑完整记录下来，给同样被调试逼疯的人一个可以直接抄作业的参考。
1. 先搞清楚：BACnet模拟器到底在模拟什么
1.1 楼宇自控调试的真实痛点
BACnet 在楼宇自控领域的标准地位不需要我多讲，ISO 16484-5，几乎所有主流的 BMS 平台、DDC 控制器、冷机群控系统都支持。但协议标准归标准，实际集成调试的时候，问题从来不出在协议文档里，而出在设备交付节奏上。
我经常遇到的情况是：BMS 平台的组态画面、历史趋势、报警联动全部做完了，结果对接的冷机厂家告诉我设备还在海上漂。平台工程师只能对着空气调画面。这时候如果有几个虚拟 BACnet 设备，把 AI 温度点、BI 运行状态、MSV 模式切换全部模拟出来，平台侧就能把点表核对、报警阈值、联动逻辑完整跑一遍，等真机上电直接换 IP 就能无缝切换。
所以模拟器解决的第一个问题，是把调试工作从真机交付中解耦出来。你不是在仿真某个品牌的冷机内部算法，你是在模拟一个标准 BACnet 设备对外呈现的所有交互行为。
1.2 模拟器的核心要素：设备、对象、属性、服务
BACnet 协议虽然术语多，但落到模拟器实现上就四个词：设备、对象、属性、服务。
- 设备（Device）：网络中一个可寻址的 BACnet 节点，用 Device Instance 唯一标识，比如 4000001。
- 对象（Object）：设备内部的数据单元，常见的有 AI（模拟输入）、AO（模拟输出）、AV（模拟值）、BI（二进制输入）、BO（二进制输出）、BV（二进制值）、MSV（多态值）等。每个对象用 Object Identifier 唯一标识。
- 属性（Property）：对象的特征数据，最核心的是 Present_Value（当前值），其次是 Object_Name、Status_Flags、Out_Of_Service 等。
- 服务（Service）：设备之间交互的指令集。模拟器至少要支持 Read Property（读属性）、Write Property（写属性）、I-Am（响应询问）、Who-Is（设备发现）这几种。
关系很清晰：一个设备包含多个对象，每个对象挂多个属性，外部通过服务读写这些属性。
1.3 模拟器不是仿真器，别搞混了
这里要划个边界：BACnet 模拟器模拟的是设备对外通信行为，不是内部物理过程。你可以模拟一个温度传感器 Present_Value 从 23.5 升到 28.0，但你不必真的去计算空气焓湿量。模拟器关心的是：收到 Read Property 请求后，回什么数据类型、什么精度、什么错误码；收到 Write Property 请求后，把值存到哪里、要不要反向触发布尔点的状态翻转。
把这个边界搞清楚，实现逻辑就能直线推进，不给自己加戏。
2. 技术选型：三种路线对比与最终选择
2.1 常用协议栈方案对比
把 BACnet 协议从零实现一遍不是不能做，但协议栈的 APDU、NPDU、BVLL 分层处理很繁琐，没必要重复造轮子。目前主流开源方案有三类：
| 路线 | 语言 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| bacpypes | Python | 开发效率高，协议完整度高 | 性能一般，异步模型偏复杂 | 工具类、测试类模拟器 |
| bacnet-stack | C | 性能好，贴近嵌入式环境 | 需要手写内存管理和回调 | 嵌入式 DDC 仿真、边缘网关 |
| 半自实现 | 任意 | 完全可控，轻量级 | 协议边界问题多，调试成本高 | 自定义特殊需求、学习协议 |
我最终选的是 Python 的 bacpypes。原因很直接：模拟器这个场景不需要追求极致的吞吐性能，但需要快速迭代协议行为。我今天要模拟一台支持告警的设备，明天要模拟一台带时间表的设备，用 Python 改起来就是几十行代码的事，用 C 改要重新编一轮。
2.2 模拟器整体架构
我设计的模拟器分三层：
- 通信层：基于 UDP，监听 47808（0xBAC0）端口。BACnet/IP 的本质就是往这个端口发 UDP 报文，BACnet 报文都封装在 BVLL 里。
- 协议层：交给 bacpypes 处理 APDU 的编解码、网络层路由、报文分段。
- 设备模拟层：这是核心，维护一张对象表，每个对象有自己独立的属性字典和值更新逻辑。外部请求进来时，设备模拟层负责查表、读写、返回响应或错误。
实际代码里，我习惯把对象表做成一个 Python dict，key 是 (object_type, instance)，value 是一个 dict 保存该对象的所有属性。
device_objects = { ("analogInput", 0): {"presentValue": 23.5, "statusFlags": [0, 0, 0, 0], "units": 62}, ("binaryInput", 0): {"presentValue": "active", "statusFlags": [0, 0, 0, 0]}, ("multiStateValue", 0): {"presentValue": 1, "numberOfStates": 4}, }这里 units 的值 62 代表摄氏度，BACnet 的工程单位是有标准编码表的，模拟器如果单位字段乱填，BMS 画面上显示的单位就会是错的。很多新手在这上面翻车。
2.3 为什么不用现成的商业模拟器
市面上确实有商业 BACnet 模拟工具，功能也不差，但我自己写有几个好处：
- 商业工具按节点数收费，我需要在测试环境跑 50 个模拟设备，自己写零成本。
- 商业工具很难模拟异常行为——比如设备重启后延迟响应、故意返回内部错误、丢包，这些在验证 BMS 容错逻辑时非常关键，而自研模拟器可以随意注入异常。
- 自定义点表导入导出、批量启动、脚本化控制，这些需求商业工具往往不支持或支持得很别扭。
一句话总结：现成的工具够用但不好用，要真正贴合调试场景，还是得自己造。
3. 核心实现：让模拟器里的设备"活"起来
3.1 最小可运行环境
用 bacpypes 搭建一个最小模拟器，环境准备其实很简单：
pip install bacpypes不过在 Windows 上有个小坑：bacpypes 的依赖 lxml 如果没有预编译包，安装会报错。建议直接用 Python 3.8-3.10 版本，并优先在 Linux 环境跑，现场调试带一台 Ubuntu 小主机或者树莓派足够。
3.2 定义本地设备与对象
模拟器启动前，先要创建一个本地设备对象。设备实例号必须和现场规划的地址表一致，比如现场约定冷机是设备实例 4000001，模拟器就配 4000001。
from bacpypes.app import BIPSimpleApplication from bacpypes.local.device import LocalDeviceObject this_device = LocalDeviceObject( objectName="Simulated Chiller", objectIdentifier=4000001, maxApduLengthAccepted=1476, segmentationSupported="segmentedBoth", vendorIdentifier=15, ) app = BIPSimpleApplication(this_device, "0.0.0.0")注意 maxApduLengthAccepted 这个参数。BACnet 报文标准以太网环境下通常能到 1476 字节，如果设备字段支持分段，甚至可以接收更大的报文。但部分 BMS 平台实现比较保守，发送的读属性请求会主动切成小包。如果模拟器配置的分段能力不对，平台侧会报"响应超时"甚至"读失败"。
3.3 定义对象并挂到设备上
对象定义的核心是继承 bacpypes 的对象类型，覆写 Read 和 Write 方法。下面这段代码定义了一个 AI 点：
from bacpypes.object import AnalogInputObject class MyAI(AnalogInputObject): def __init__(self, instance, name, initial_value): AnalogInputObject.__init__( self, objectIdentifier=("analogInput", instance), objectName=name, presentValue=initial_value, )但这里有个容易被忽略的细节：对象的属性变化不会自动推送给外部订阅方。要让 BMS 平台实时感知到值变化，需要主动触发 COV 通知，或者让模拟器周期性广播。后面第 4 节我会专门讲。
3.4 启动服务并验证报文
设备、对象、协议栈都就绪后，启动应用层事件循环：
app.run()跑起来以后，用任意 BACnet 扫描工具（我用的是 Barton 发布的 BACnet Explorer，开源免费）发一个 Who-Is 广播，模拟器会回 I-Am，扫描工具里就能看到设备实例 4000001，展开后能看到所有定义的对象。再双击 AI 点读一下属性，Present_Value 就会返回 23.5。
如果验证不过，优先级最高的排查手段是 Wireshark 抓包，过滤bacnet，一眼就能看到应答报文的 APDU 类型和返回的值。BACnet 协议是明文 UDP，没有加密，报文结构清晰，抓包是定位模拟器问题的最佳方式。
4. 让模拟器更像真设备：处理 BMS 订阅、告警和异常
4.1 COV 订阅：值变化主动推给平台
真实 DDC 控制器最常用的通信机制是 COV（Change of Value）：平台上订阅了一个 AI 点，设备端一旦检测到值变化超过增量阈值，就主动往平台推报文，不需要平台反复轮询。模拟器要实现这个行为，需要两步：
- 响应订阅请求：bacpypes 自带 COV 接口，在对象上注册订阅者列表即可。
- 值变化时触发通知：修改对象 Present_Value 后，调用 COV 通知逻辑，协议栈会自动把通知报文发给订阅端。
我实测过，BACnet COV 的触发增量（covIncrement）如果设得太小——比如温度点增量设 0.01——平台侧的报文堆积会非常严重，真实设备一般设 0.5 到 1.0。这个参数直接影响了模拟器运行时平台的负载表现，值得认真填写。
# 模拟器脚本中动态更新 AI 点的值并触发 COV 通知 ai_object.presentValue = new_value ai_object.NotifySubscribers()4.2 时间表和告警：模拟冷机群控的完整交互
纯数字量的读写只是基本功。冷机群控场景里，BMS 平台经常要往设备写时间表、读告警记录。模拟器至少要支持：
- Schedule 对象：内部维护一组时间区间与对应值。平台写入 schedule 后，模拟器按本地时间自动切换输出值。
- Notification Class 对象：告警的投递配置。当某个 AI 点越限，模拟器能按 notification class 的配置向平台发送告警报文。
- 事件检测：设置 AI 点的高限/低限，模拟器自身判断越限事件，置位 Event_State。
我现在跑的模拟器里挂了一个 Notification Class 500，当 AI0 的值超过 30 度时，设备会主动上报 Alarm。BMS 平台通过这种机制做冷机高水温报警联动，联调时用模拟器反复触发几次，平台侧的报警去重和恢复逻辑都能验证到位。
4.3 注入异常：模拟器真正的价值所在
如果说前面是"模拟器的常规功能"，那注入异常就是"模拟器的高级玩法"。真实设备在现场一定会有不听话的时候，而 BMS 平台能不能扛住设备异常，必须在调试阶段验证。
我在模拟器里做了一套故障注入机制：
- 模拟设备离线：停止响应任何请求，平台会显示设备超时，验证平台的心跳超时报警逻辑。
- 模拟响应延迟：在响应处理函数里加 sleep(2)，模拟链路拥塞或设备处理慢，验证平台的超时设置是否合理。
- 模拟对象不可访问：对 Read Property 请求返回 "object not found" 错误，验证平台点表配置错误时的表现。
- 模拟值越限或状态抖动：周期性在正常值和高报警值之间来回切换，验证平台的报警去抖逻辑。
这套故障注入机制帮我在联调现场找出了不少问题，当然也包括平台侧的报警风暴这类问题，让平台方提前做了限流优化。
5. 实战避坑：几次撞墙之后的经验总结
5.1 设备实例号分配：全楼一栋楼只能有一套
模拟器最容易埋雷的地方是最基础的设备实例号。BACnet 网络里Device Instance 是全网唯一的，如果模拟器和现场某台真机用了同一个号，平台在自动扫描时就会只识别到一台设备，隐藏的问题非常难排查。我踩过一次：模拟器用了 4000001，现场一台水表恰好也是 4000001，平台侧冷机点位显示正常，但水表怎么都搜不到，排查了一下午才定位到是设备号冲突。
建议：在配置里做一个地址规划表，模拟器脚本启动时先读取分配表，避免手改代码里写死的实例号。
5.2 APDU 大小与分段：报错总在细节处
BACnet 报文在以太网环境下 APDU 大小通常为 1476，这是去掉 UDP/IP 头和 BACnet/IP 的 BVLL 头之后剩下的空间。但如果模拟器通过路由器工作在 non-BACnet 网络里，或者平台侧配置了较小的 Max APDU Length，模拟器需要根据请求里的 Max APDU Length 字段自适应返回数据长度。
我第一次做批量点位读取测试时，问了 30 个 AV 点，模拟器一股脑把数据塞在一个报文里，结果平台那边收包超时。后来加了对端 APDU 长度解析，超过限制就切片成多个响应或返回分段报文，才彻底解决。这提醒我一个重要经验：做模拟器，越标准的实现越要在字段级别抠细节。
5.3 响应速度不是越快越好
模拟器的响应速度要控制在合理范围。真实 DDC 从收到请求到发出响应的典型延迟在 20-100ms 之间，而我的模拟器本地回包经常在 1ms 内。这会带来一个隐患：平台工程师在调试时，会把轮询间隔设得很激进——比如 500ms 读一次，真实设备根本扛不住。等替换成真机后，平台的点位刷新率一塌糊涂。
后来我在模拟器里加入了随机抖动延迟，区间设在 10-50ms，尽量逼近真实设备的响应特征。模拟器不只是造数据，还在帮平台侧校正预期。
5.4 批量启动与场景编排
最后分享一个扩展方向：我做的模拟器脚本支持从 CSV 导入点表，一次性创建上百个对象；也支持按场景批量启动多个模拟器进程，每个进程监听不同的端口，通过 nacl 或者 iptables 做端口映射，模拟整个设备群。这样在项目验收演示时，我可以一键启动整个虚拟冷站系统，数据实时跳动，比拿 PPT 演示直观得多。
无论你是做 BMS 平台开发、DDC 应用编程，还是做系统集成调试，BACnet 模拟器都能让很多原本需要等设备的问题提前暴露并解决。如果你也在被设备交付节奏困扰，建议从本文的参数配置开始试一下这个方案，先把点表造起来，联调效率提升绝对不是一星半点。
本文还有配套的精品资源，点击获取
