LLRP（Low Level Reader Protocol）之所以存在，是因为此前的每台固定式 UHF 读写器都说自己的方言。在它之前，集成三家厂商意味着三套 SDK、三套连接语义、三种表达"用这个过滤条件读这四路天线"的方式。LLRP 用一个 TCP 上的二进制协议取代了这些。
LLRP 究竟标准化了什么
LLRP 定义了客户端发给读写器的消息，以及读写器回传的报告：能力发现、读写器配置、盘点与访问规格、标签访问命令、事件通知。2007 年通过的 1.0.1 版仍是部署最广的版本；2.0 版增加了 Gen2 v2 命令。
它并不标准化你的业务逻辑、数据模型或天线命名。这些仍属于你自己，而把"协议"误当成"集成"，正是大多数项目走偏的原因。
- 能力发现：天线数量、功率范围、支持的空中协议。
- 配置：射频模式、发射功率、天线权重、GPI/GPO 行为。
- 盘点：ROSpec 与 AISpec 定义哪几路天线工作、上报什么。
- 访问：对选定标签集执行读、写、锁定与灭活。
哪些配置应该放在中间件而不是固件里
任何在两个站点之间会不同的设置，都必须放在中间件里，并与集成代码一起版本化。读写器侧的默认值是不可见的、未版本化的，负责的工程师离职后就再也无法审计。
- 盘点 session、target 与标签数量估计。
- 每路天线的发射功率，以及天线到区域的映射。
- 过滤条件（EPC 前缀、TID 掩码），决定读写器被允许上报什么。
- 读写器模式：最大吞吐、密集读取或混合。
- 传送带或门磁的 GPI 触发与防抖窗口。
ROSpec、AISpec 与 AccessSpec 该怎么建模？
ROSpec 是容器：它把天线、一份盘点规格、可选的访问规格和一份上报规格组合在一起，并在 disabled、inactive、active 三种状态间迁移。AISpec 说明哪几路天线用哪套盘点参数；AccessSpec 说明对符合过滤条件的标签读什么、写什么。
按物理区域建 ROSpec，而不是按天线建。这样一个月台门就是一个可以启停、可以监控的单一对象，天线映射则退化为配置细节，而不是代码改动。
- 每个区域一个 ROSpec：月台门、产线、库房。
- 通道上报间隔 200–1,000 毫秒；只有低流量读取才用立即上报。
- AccessSpec 只用于写入；只读区域不要带访问命令。
LLRP 项目通常在哪里失败
协议本身很少是问题，失败都发生在运维层面。
- 连接处理：读写器会重启、断 TCP、并集中重连；没有退避的客户端会同时压垮读写器和网络。
- 重复读取：同一标签两秒内被看到十二次，是一个事件，不是十二笔库存变动。
- 缓冲区溢出：通道处 800 个标签的突发流量会冲垮同步处理的客户端。
- 固件差异：可选字段与能力在不同型号、不同版本间不一致，能力发现结果必须当作数据而不是假设。
- 职责不分离：埋在读写器配置里的业务规则无法测试。
事件应该如何进入 Odoo？
干净的路径是：读写器事件 → 归一化 → 去重 → 业务事件 → ERP 调用。每一步只承担一个职责，并可独立记录日志。
- 读写器事件：EPC、天线、时间戳、读取次数、RSSI。
- 归一化：EPC 映射为产品，天线映射为库位，读写器映射为作业类型。
- 去重：按 EPC 与区域设置 3–10 秒的防抖窗口。
- 业务事件：入库、调拨、盘点或调整——每次物理移动只产生一个。
- Odoo 调用：更新 stock.quant、创建 stock.move 或库存调整，并用 EPC、区域与时间窗构成幂等键。
监控与故障切换应该怎么做？
把读写器当网络设备对待。每 30 秒轮询心跳与 GPI 状态，对读取速率的骤降告警，而不是对单条错误告警；当 ERP 或网络不可用时，在本地缓存事件。
在"漏读一次月台门、三周后变成库存差异"的仓库里，断点续传不是可选项。缓存的容量至少按峰值读取速率覆盖四小时，并以原始时间戳重放，让 ERP 看到正确的顺序。
结论
LLRP 给你的只是"多厂商读写器共用一套协议"，仅此而已。把配置、过滤与缓存放进中间件，按区域建 ROSpec，在触碰 ERP 之前完成去重，并像对待网络设备那样监控读写器。
