恺乐 RFID 布草洗涤追踪系统：从收脏到出货的全链路方案

商业洗涤的痛点

商业洗涤是个脏活累活，但利润就藏在流程细节里。酒店、医院、餐饮每天几百上千公斤布草进出，收脏、分类、洗涤、烘干、熨烫、入库、发货——每个环节都在丢东西。丢一条毛巾赔不了多少钱，但一个月丢几百条，年底一算账就是十几万的窟窿。更头疼的是和客户对账：酒店说少了 50 条床单，洗涤厂说只收了 40 条，差的那 10 条谁赔？

传统做法是人工点数、手写单据。工人戴着手套数布草，数错是常态。单据传到手里已经皱巴巴的，字迹模糊，对不上就扯皮。有些洗涤厂上了条码系统，比手写强一些，但条码必须看见才能扫——一车布草叠在一起，得逐件翻出来找条码，效率比人工还低。

恺乐 RFID 布草洗涤追踪系统（内部代号 SmartTag）解决的就是这个问题。给每条布草缝一枚 RFID 标签，从回收到出货全程自动采集，不用人盯、不用人数。下面拆解这套系统的硬件架构、软件设计和落地经验。

系统架构：四层结构

整套系统分四层：标签层、采集层、服务层、终端层。

标签层是缝在每条布草上的 RFID 标签，内含唯一的 EPC 编码（96bit，支持 12 位或 24 位编码规则）。洗涤场景用的标签必须耐高温（150°C 以上洗涤温度）、耐水洗（几百次洗涤循环）、耐化学腐蚀（洗涤剂、漂白剂）。标签芯片选 Impinj E710 或 NXP UCODE 系列，灵敏度好，读取距离稳定。

采集层是分布在各工位的读写器。分拣台、入库通道装固定式读写器，自动识别经过的每一件布草。PDA（手持终端）用于移动盘点和异常处理。所有读写器通过局域网连接到服务端。

服务层是一台本地服务器（Windows 10/11 或 Server），运行 SmartTag.Service 数据服务（端口 8088）和 MySQL 8 数据库。服务端负责标签绑定、状态流转、批次管理、订单跟踪、并发控制。选择 MySQL 而不是 SQLite 是因为实际场景要支持 6 台以上 PDA 同时在线操作——SQLite 扛不住这个并发量。

终端层包括桌面管理端（SmartTag.Desktop）和 PDA 手持端。桌面端给管理员用，做主数据维护、设备管理、报表查看。PDA 给一线工人用，做扫描、盘点、交接、入库确认。PDA 支持离线模式——WiFi 断了也能继续扫，联网后自动同步。

标签绑定：写死 ID，不可篡改

布草洗涤追踪的第一步是给每条布草绑定标签。绑定流程：把空白标签放到读写器上 → 系统生成 EPC → 写入标签 → 数据库记录绑定关系。

这里有一个关键设计：写完后锁卡。标签的 EPC 存储区被永久锁定，后续无法改写。这不是软件层面的限制，是硬件级别的锁定——即使把标签取下来重新放到读写器上，改写请求也会被硬件拒绝。

为什么要锁？因为布草洗涤场景里标签就是布草的身份证。如果 EPC 可以随意改写，工人不小心扫错标签、或者标签被恶意替换，整个追溯链就断了。锁死 EPC 之后，标签和布草就是一对一绑定的，不可伪造、不可篡改。

桌面端批量发卡时默认不锁卡（LockAfterWrite=false），因为批量写号阶段可能需要调整。标签投入实际使用后，改写 EPC 不需要解锁——只需要提供正确的访问密码（AccessPwd），系统在设备设置里统一管理这个密码。改密码保存后热生效，不需要重启。

通道读写器：批量入库的核心

洗涤完成后的布草入库是效率瓶颈。传统做法是工人逐件扫描，几百条布草要扫半小时。恺乐的方案是通道读写器（KL9700 系列）：布草放在传送带上推过通道，读写器自动批量读取所有标签，几秒钟完成入库。

通道读写器内置 Impinj E710 模块，配 3 根天线（左、右、顶部），覆盖通道截面。工作方式是 TCP 长连接——读写器作为 Server 监听 4001 端口，PC 端的 factory-client 程序作为 Client 连接。读写器持续扫描，读到标签就推送给 factory-client，factory-client 攒批（每 500ms 或满 20 条）调服务端 API 写入数据库。

天线配置用快速切换盘点模式：三根天线轮流工作，每根 100ms，循环扫描。这样不管布草从哪个方向通过通道，至少有一根天线能读到标签。

入库流程是两段式的：通道读写器自动采集标签数据，批次状态为 pending（待确认）。工人拿着 PDA 到入库页面，拉取待确认批次，系统自动和本地台账比对——这条标签是不是属于这个部门的？是不是洗涤完成的？有没有异常？确认无误后点确认，批次状态变为 confirmed，布草状态从 WASH_OUT 流转为 WASH_IN（在库可用）。

两段式设计的目的是把「自动采集」和「人工确认」分开。通道读写器只管读，不管业务逻辑；PDA 做最终确认，但不用逐件扫——读几百条标签的工作已经由通道完成了。

布草生命周期：四个状态节点

每条布草在系统里有四个状态节点，对应洗涤业务的完整循环：

1. 1

   RECV_IN（收脏入库）

   酒店把脏布草打包送到洗涤厂，PDA 扫描接收，状态变为 RECV_IN。系统记录来源酒店、接收时间、数量。

2. 2

   WASH_IN（洗净入库）

   分拣、洗涤、烘干、熨烫。洗涤完成后通过通道读写器入库，状态从 RECV_IN 变为 WASH_IN。

3. 3

   WASH_OUT（洗涤发出）

   洗净的布草按订单分拣、打包，PDA 扫描发货，状态变为 WASH_OUT。

4. 4

   SHIP_OUT（发货出库）

   装车发往客户，状态最终变为 SHIP_OUT。整个生命周期里，每条布草的流转记录都保存在数据库中。

任何时候拿 PDA 扫一下标签，就能看到这条布草什么时候收的、什么时候洗的、经过哪些工位、什么时候发的货。这就是 RFID 追溯的价值——不是知道某一批布草在哪，是知道每一条布草在哪。

部门流转：谁经手、什么时候

洗涤厂内部通常分多个部门：收货部、洗涤部、熨烫部、发货部。布草在部门之间流转时，需要记录交接信息——A 部门交给 B 部门多少件，什么时候交的，谁签的字。

系统设计了部门流转模块：每个部门绑定一台 PDA（或一个固定读写器工位），布草流转到某个部门时扫一下，系统自动记录「部门 A → 部门 B，时间 T，操作人 X」。如果数量对不上（比如 A 说发了 100 件，B 只收到 98 件），系统自动标记差异，触发异常处理。

这个模块解决了洗涤厂最常见的扯皮问题：布草在哪个环节丢的。以前靠人记，现在靠系统记。数据不会撒谎。

PDA 离线模式：WiFi 断了也能干活

洗涤厂的环境对网络不太友好：高温、高湿、金属设备多，WiFi 覆盖经常有死角。如果 PDA 必须实时联网才能工作，网络一断整个产线就停了。

恺乐 PDA 端设计了完整的离线模式。PDA 本地有 SQLite 数据库，缓存了主数据（标签信息、SKU、部门、订单）。WiFi 断了，PDA 自动切换到离线模式，扫描数据存在本地。WiFi 恢复后，SyncService 自动把离线期间的批次上传到服务端。

上传是幂等的——同一个批次上传两次，服务端只处理一次（按 batchId 判重）。batchId 的格式是 ANDROIDID_yyyyMMddHHmmssSSS，精确到毫秒，同一分钟保存两次是两个独立批次，不会冲突。

网络状态在 PDA 屏幕顶部有实时显示：在线/离线、待上传批次数、最后同步时间。工人一眼就知道数据有没有同步成功。

并发控制：6 台 PDA 同时操作

一个中型洗涤厂可能同时有 6 台 PDA 在不同工位工作。如果两台 PDA 同时扫描同一条标签（比如交接时 A 扫了一次、B 又扫了一次），数据库会不会冲突？

服务端用条件 UPDATE 解决并发问题。更新标签状态时，SQL 里带条件：WHERE epc = ? AND status = ?。如果另一台 PDA 已经改过状态，这条 UPDATE 影响行数为 0，服务端返回 CONFLICT 错误码，PDA 提示「该标签已被其他设备处理，请刷新后重试」。

这不是理论设计，是实测过的。并发验证 17 项断言全部通过——6 台 PDA 同时绑定、同时解绑、同时交接，没有出现数据不一致。

订单管理：按单发货

洗涤厂的客户（酒店、医院）每次下单都是具体品类和数量：100 条床单、200 条毛巾、50 个枕套。洗涤完成后按订单分拣发货。

系统支持订单管理：创建订单 → 关联 SKU 和数量 → 发货时 PDA 扫描标签 → 系统自动匹配订单 → 发完一个订单自动核对数量。如果订单要求 100 条床单，实际扫到 98 条，系统提示差异，工人可以补扫或标记异常。

订单数据和服务端数据库实时同步，PDA 端缓存订单列表。离线状态下也能按订单扫描，联网后同步。

安全加固与编码规则

系统面向的是洗涤厂的实际使用场景，安全设计不能省。登录防爆破：连续失败 5 次，账号锁定 10 分钟（按「账号+IP」计数）。强制改密：首次登录必须修改默认密码，强度要求 8 位以上。设备审核：新 PDA 首次登录时，如果 device.approve.mode=manual，需要管理员审批后才能使用。会话管理：管理员可以查看所有在线设备，踢掉异常设备，Token 有效期 24 小时。

编码规则引擎支持灵活配置：前缀 + 日期 + 流水号的组合，每段的前缀、长度、起始值都可以配置。比如酒店布草编码为 HTL2026100200001（酒店 prefix + 日期 + 5 位流水），服装编码为 GMT00001（服装 prefix + 5 位流水）。规则启用后，PDA 和桌面端写号时自动按规则生成 EPC，不需要人工输入。

项目落地数据

这套系统不是纸上谈兵的设计，是完整开发并经过验证的。24 张数据库表，覆盖标签、SKU、部门、订单、流转记录、设备、配置、审计日志。70+ 个 API 路由（阶段 1-6 累计），覆盖标签管理、主数据、部门流转、订单、安全、会话、编码规则。6 个批次冒烟测试，累计 130+ 项断言全部通过。并发测试 17 项、重启测试 7 项、全接口回归 34 项。PDA 端 9 个同步模块文件，支持在线/离线双模式、增量同步、发件箱重放。

和固定资产管理的区别

恺乐还有一套 RFID 固定资产管理系统。两套系统都基于 RFID 技术，但业务逻辑完全不同。

固定资产管理关注「在位」——这台设备在不在机房里。盘点频率低（每月/每季度一次），标签不需要移动，读取以固定式为主。布草洗涤追踪关注「流转」——这条布草到了哪个环节。盘点频率极高（每天多次），标签随布草移动，读取以通道式和手持式为主。标签要耐高温、耐水洗、耐化学腐蚀。

两套系统的硬件有重叠（都用 KL9005U 读写器、都用 Impinj E710 芯片标签），但软件是完全独立的两套。布草洗涤系统（SmartTag）是专门为洗涤业务设计的，包含洗涤特有的生命周期状态机、部门流转、通道入库、订单发货等功能。

选型建议

如果你的场景是商业洗涤（酒店、医院、餐饮布草），或者需要追踪物品在多个工位之间的流转，SmartTag 系统是对的方向。几个前置条件：布草材质要能缝标签（绝大多数棉、涤混纺都可以缝耐高温 RFID 标签）；现场要有局域网（PDA 通过 WiFi 连接服务端，通道读写器通过有线网络连接 PC）；并发规模决定数据库选型（1-2 台 PDA 用 SQLite 就够，3 台以上建议 MySQL，SmartTag 默认配 MySQL 8）。

恺乐提供从标签选型、读写器部署到系统开发的一站式服务。不确定适不适合的话，可以先聊聊场景需求。