一、BACnet协议概述

1.1 BACnet的起源与发展

说起BACnet的起源，得回到1987年。那时候楼宇自控市场乱得很——各家厂商都有自己的协议，霍尼韦尔用一套，江森自控用另一套，西门子又搞了一套。你想想看，一个大型建筑里，暖通、照明、消防、安防，每个子系统都可能来自不同厂家，它们之间根本没法对话。

我当时刚入行，就碰到过这种尴尬事。一个项目里，冷机是A家的，空调箱是B家的，为了让他们能通信，硬是加了三个网关，调试了两个月。嗯，那滋味真不好受。

所以美国暖通空调工程师协会（ASHRAE）坐不住了。他们牵头成立了一个委员会，目标很明确：搞一个开放的、标准的楼宇自控通信协议。这就是BACnet的由来——Building Automation and Control Networks。

1995年，BACnet正式成为ANSI标准。之后一路发展：

• 2003年：成为ISO国际标准（ISO 16484-5）
• 2012年：加入BACnet/IP，支持互联网通信
• 2016年：引入BACnet/SC（安全连接），解决网络安全问题
• 2020年至今：持续演进，支持Web服务、物联网集成

我个人觉得，BACnet能活到现在，靠的就是「开放」二字。它不依赖任何一家公司，由ASHRAE持续维护更新。说白了，这是行业共同的孩子。

1.2 BACnet在楼宇自控中的地位

现在楼宇自控领域，主流协议就那么几个：BACnet、Modbus、KNX、LonWorks。但要说谁最「正统」，我首推BACnet。

为什么？

第一，覆盖面广。 BACnet定义了从物理层到应用层的完整协议栈。不像Modbus，只定义了通信层面，数据怎么组织、设备怎么管理，全靠厂商自己发挥。我见过太多Modbus项目，同一个点位表，两家厂商能给你整出三种不同的数据格式。

第二，对象模型强大。 BACnet把楼宇设备抽象成标准对象——模拟输入、数字输出、命令对象、趋势日志……你想想看，一个空调箱，用BACnet描述就是一组标准对象的集合。换任何一家厂商的设备，只要遵循BACnet标准，上位机软件不用改一行代码。

第三，互操作性认证。 这是BACnet最狠的一招。设备要通过BTL（BACnet Testing Laboratories）认证，才能打上BACnet标志。我做过一个项目，甲方指定所有设备必须通过BTL认证。结果呢？不同品牌的DDC、传感器、执行器，接上就能用，调试时间缩短了40%。

当然，BACnet也不是万能的。它偏重楼宇自控领域，对工业控制场景支持不够。但话说回来，术业有专攻嘛。

1.3 BACnet协议栈架构概览

BACnet的协议栈，我习惯把它比作「四层蛋糕」。从下往上分别是：

这里有个关键点：BACnet的应用层是独立于底层通信的。什么意思呢？就是不管你是用RS-485线缆，还是走以太网，甚至用Wi-Fi，应用层的数据结构完全一样。

我刚开始学BACnet时，总搞不清这个关系。后来做了个项目，现场用的是BACnet MS/TP（基于RS-485），而控制中心用的是BACnet/IP（基于以太网）。中间加个BACnet路由器，两边数据无缝对接。那一刻我才真正理解——底层通信只是载体，核心是应用层的对象和服务。

再往下说，BACnet的应用层里，核心是两样东西：

• 对象（Object）：描述设备的数据结构。比如一个温度传感器，就是一个模拟输入对象（Analog Input Object）。
• 服务（Service）：对对象进行操作的动作。比如读取温度值，用的是ReadProperty服务。

举个例子，你手机上的天气App，要获取当前温度：

// BACnet请求报文（简化版）
服务类型：ReadProperty
对象类型：Analog Input (0)
对象实例：101          // 假设温度传感器实例号为101
属性ID：Present_Value (85)  // 当前值属性

// BACnet响应报文
服务类型：ReadProperty Ack
属性值：23.5          // 当前温度23.5°C

你看，就这么简单。一个读请求，一个响应，温度就拿到了。但背后，BACnet定义了上百种对象类型、几十种服务，覆盖了楼宇自控的方方面面。

我个人觉得，理解BACnet协议栈，关键就一句话：底层管通信，上层管数据。你不需要关心数据是怎么从RS-485线缆上传过来的，只需要知道怎么用对象和服务去操作设备。

好了，这一章就聊到这儿。下一章我们深入讲讲BACnet的核心——对象模型。到时候我会拿几个实际项目中的例子，带你看看BACnet对象到底长什么样。