为什么我们构建了一个开源工业BLE协议（AltessaBeacon）

发布: 5天前 (2026年2月4日 GMT+8 00:14)

7 分钟阅读

原文: Dev.to

Source: Dev.to

Bluetooth Low Energy (BLE) 是一种被广泛采用的低功耗、短距离无线通信标准。它的广播机制简单且灵活，这也是许多信标格式（如 iBeacon 或 Eddystone）基于它构建的原因。

然而，在构建真实系统——工业追踪、协同设备网络或长期部署时——我们发现现有的信标格式过于受限。它们定义狭窄，侧重于简单识别，几乎没有为演进提供结构。这种协议不明确导致随着系统复杂度提升，保持一致实现变得困难。

为了解决这些问题，我们开发并开源了 AltessaBeacon：一种具有清晰规范、显式版本控制、结构化负载以及明确扩展策略的 BLE 广播协议。

为什么标准信标格式对我们不起作用

在实际使用中，常见的信标格式非常死板。它们的负载是固定的，版本控制选项有限，且在不破坏兼容性的前提下进行扩展十分困难。安全性往往完全缺失，这使得伪造和重放变得轻而易举。与此同时，缺乏对设备状态、优先级或受控行为变化的正式概念——一切仅仅是重复广播。

在工业环境中，这些限制更加突出。干扰、密集部署、金属结构以及严格的电池约束意味着数据包丢失是常态而非例外。一旦信标开始携带结构化数据而不是简单的 ID，这些问题就会转化为运营风险。

AltessaBeacon 将 BLE 广播视为一种受限但严肃的通信通道。该协议假设会出现丢失、重复和部分接收，并且在这些条件下仍保持可解析且有意义。

在核心上，AltessaBeacon 使用 基于 TLV 的帧模型。这使得负载能够随时间演进而不破坏现有接收器。显式的版本控制支持混合部署和渐进式升级，这对长期运行的工业系统至关重要。

安全性被视为协议设计的一部分，而不是可选的附加功能。帧模型允许对负载进行身份验证和加密，并实现重放保护，从而能够一致地实现这些安全特性。

AltessaBeacon 不是特定厂商的格式或松散定义的帧布局。它是一个有文档的协议，规定了广告数据的结构、字段的标识方式以及接收方应如何解释这些数据。

该规范强调可预测性。帧被明确标记版本，字段被正式定义，扩展规则也有文档记录。这使得独立实现能够在不依赖未文档化假设或隐式约定的情况下互操作。

例如，穿戴式安全设备在检测到跌倒时可以从周期性状态广播切换到高优先级紧急警报——接收方知道如何在没有自定义逻辑的情况下解释这种状态变化。

EET (Extended Event Transmission) – 定义协议数据如何与广告事件关联，允许接收方将相关传输视为单一逻辑上下文的一部分，而不是孤立的包。
BAIS (Beacon Adaptive Information Set) – 定义广告信息集合如何根据设备状态或运行上下文变化，同时保持结构的一致性。
SCF (Structured Control Fields) – 定义负载内部的标准化控制和信令字段，提供明确的协议层语义，而非应用层特定解释。

这些机制共同使 AltessaBeacon 能够描述不仅是广告数据，还包括该数据应如何解释。

AltessaBeacon 明确将协议版本与负载内容分离。这使得在保持帧层向后兼容的同时，能够随时间演进协议。

扩展受公共注册表和策略的管理，规定了新字段的引入和文档化方式。接收方可以安全地忽略未知字段，同时继续处理已知字段，这对于长期部署至关重要。

AltessaBeacon 完全开放且供应商中立。该仓库包括：

该规范旨在独立实现，不依赖于单一协议栈或产品。这种开放性促进了互操作性、审查以及长期维护。

BLE 广播常被视为一种最小的广播机制。AltessaBeacon 采用了不同的方式，将广播视为具有定义语义和演进规则的结构化通信通道。

该协议是开放的、已文档化的，并且在范围上有意保持保守。如果您需要一个清晰且可扩展的结构化 BLE 广播数据基线，AltessaBeacon 旨在提供正是如此的方案。