logo资料库

RFID心得体会.doc

第1页 / 共9页
第2页 / 共9页
第3页 / 共9页
第4页 / 共9页
第5页 / 共9页
第6页 / 共9页
第7页 / 共9页
第8页 / 共9页
资料共9页,剩余部分请下载后查看
进入这行已经有 3 年半了,到 09 年 7 月份刚好工作了 4 年,4 年以来一直专心于 RFID 应用开发,实际参与过不下 20 个项目实施和二次开发,07 年跟着市场人员对广州深圳的一 些厂家有过登门拜访,今年年初,进了这个在东莞最有影响力的 RFID 开发公司,一直工作 到现在,这一年来参与了几个重要系统的改进和新产品的设计,也参与了和金蝶用友的合作 适宜。在这些实践的过程中,对所处的这行有所了解和认识,特次总结一下积累的经验和行 业认识,最后规划下自己对未来 RFID 系统的设想。 发卡设备 通用类型 实用类型 复合类型 硬件特点 通讯方式 设计要点 考勤机 标准类型 扩展类型 硬件特点 通讯方式 设计要点 消费机器 标准类型 硬件特点 通讯方式 设计要点 按照芯片协议,实现硬件接口 如 MFS50 卡,提供写一个扇区信息的接口函 数 按照应用协议,实现自定义的应用接口, 如 参数为 姓名、卡号、金额等 同时提供了上述两种类型的接口函数 无存储、无显示、指示灯、喇叭、不能独立 工作 232 为主,485、TCP 为辅助 控制成本、功能单一、性能稳定 功能简单,大存储、显示屏、带键盘、电池 主要扩展简易门禁功能 功能简单 232、485、TCP、CAN、无线、USB 外观时尚 性能稳定 安装方便 功能相对复杂、硬件特点同考勤设备,屏幕 一般为双屏,增加消费控制、消费统计、消 费参数设置 存储适中 程序复杂度中等 可靠性要求比考 勤高比门禁低,防水防潮要求高 232/485 TCP CAN 外观时尚 操作方便 防水防潮 可靠性高
门禁机 标准类型 特点 通讯方式 设计要点 一卡通自助终端 功能 特点 设计要点 补贴机 功能 特点 设计要点 圈存机 功能 特点 设计要点 非实时系统复杂度高,读头和控制器分离, 存储、显示要求不高,有多门门禁和单门门 禁区分 稳定性高 专业要求高 3C 认证 外设丰富 232/485 TCP CAN 安全性 外设接口丰富 逻辑复杂 稳定性要 求高 自动挂失、解挂、补贴领取、信息查询 解决一卡通数据透明问题 提高自动化管理水平、减小管理压力和成本 解决传统补贴的弊端 功能复杂,多有系统支持、成本高、外观时 尚、可靠性一般 实现自动补助(和充值有区别,这个不要钱) 减小管理压力 一般用于 IC 消费系统,设计比较复杂,操作 流程上比较烦琐、协同的难度比较大、只能 用于小规模的系统,不在可持续发展的产品 协同流程一定要考虑完善,功能、稳定性要 求不高,使用频率少 实现银行卡和消费卡的绑定,自动充值、自 动结算 内部功能复杂,类似 POS 机和银联终端 TCP 通信,直接和前置机通信 显示屏幕和键盘输入、功能菜单 自动冲正和自动对仗功能 1 流程完整 2 硬件稳定性 3 外观时尚 操 作方便 4 功能复杂,需要仔细规划接口和应 用 5 配件多,接口丰富(IC 读头、银行卡读 头、打印机、TCP 模块)
前置机——准确的说 前置机软件 功能 特点 设计要点 订餐机 功能 特点 设计要点 手持机 功能 设计要点 常见问题 管理圈存机、连接银行后台,承上启下,实 现圈存 规范通讯协议、管理冲正和对仗功能 稳定性要求高 安全性要求高(多为专线通讯,并且加密) 7*24 小时的持续工作能力 实现预定餐,才容许消费 非实时系统功能复杂,对灵活性和可操作性 有相当的要求,配合软件、消费机一起工作, 协同难度大 外观时尚 操作方便 灵活性要求高 稳定要 求一般 方便携带,一般为采集终端,常见有条码手 持机 携带方便 操作方便 功能不能过于复杂 外观时尚 续航能力 功能设计过于烦琐,操作不方便 屏幕很暗,看不清楚 电池问题多多,使用不了多久 质量问题多,键盘死机,丢失存储
服装 RFID 应用 功能 系统设计 系统优点 系统缺点 设计难点 通过在生产环节注入 RFID 识别,采用实时数 据采集的方式来提高生产管理水平 PC 后台 采集设备 刷卡设备的三级网络 1 TCP 通讯+485 通讯组合,实现有效的组网能 力和通讯速度保证 2 支持容量为 3000 左右的刷卡终端 3 支持数据采集的同时,也支持数据的下行 4 有屏幕\键盘\灯控制,支持汉字 5 速度快 响应时间为 2S 内,实际速度为 1 分 钟 40 次. 6 通讯有心跳检测和自动修复的异常通讯 1 没有存储功能,网络不正常的情况下无法使 用. 2 终端体积比较大,不便于实施. 3 整个系统严重以来后台服务. 1 持续工作能力和低故障率 在工业应用中, 产品最好达到工业级别的应用水准. 2 PC 后台软件的稳定性要求高,处理数据的 性能瓶颈. 3 必须走可循环利用的标签使用方式 标签量大,投入昂贵.
典型应用场景分析 ID 实时消费 环境分析 系统原理 现有问题 改进目标 改进思路 改进后的效果 PC、数据库服务器、15-20 台消费机器、企 业规模:2000 左右 PC 后台开启消费服务,通过 485 轮巡机制来 实时控制多台消费机的刷卡反馈。 为加快后台处理数据速度,采用本地文本方 式,将数据放在本地,直接应用。 实现 7*24 小时连续工作能力 1 仅支持 1 个后台,无法扩容 2 单后台的容量最多为 20 台上下,限制其适 用场景。 3 在消费时,对关键数据的修改有限制,兼 容带来的问题很多,不好控制 1 支持 5000 人以上规模应用 2 支持多点操作 3 支持 50-100 台机器容量 4 改动小,属于维护扩展功能 在后台服务中增加同步处理,按照以数据库 为唯一中心,本地文件为消费依据的原则, 实现消费数据在 5S 内同步到本地的功能。 1 扩容,将单机变成了网络版本,容量几乎 可以满足所有的应用。 2 管理方便 原有模式下,在消费时对关键数据进行了 锁定,不能在其它地方地方进行操作。否则 会带来严重后果。改进后,没有了此限制, 操作自由。 3 热备份成为现实 原由模式下不能进行热备份,后台出故障 后必须重起服务才能恢复。改进后,可以采 用两台 PC 同时管理一个网络,一台实际应 用,一台备份,一旦出现问题,切换线路即 可恢复正常,将故障损失降低到最低。
UHF 门禁应用 系统组成 优点 缺点 特点 UHF 货舱门应用 系统组成 优点 缺点 总结 915M 标签和阅读器 红外感应 摄像头 报警 器 距离远,感应自动化 识别率不能达到可接受的范围 外来影响严重, 投入成本高 UHF 门禁的系统目前已有不少,但相对于 HF 和 LF 的门禁,稳定性和成熟度来说,差距不小. 915M 标签和阅读器,货舱系统 能够批量识别标签 有漏读现象 UHF 的产品应用有 2 个要突破: 1 标签成本 2 识别率提高
规模应用脱机系统带来的负面影响分析 应用场景 系统原理 实际应用 系统评估 系统缺陷 大型企业 5000 人以上规模,应用考勤机器 50 台、 门禁机器 100 台、消费机:100。工作一周六天, 有 4 餐消费。 一卡通软件一套,有采集功能,采用黑名单管理 利用 TCP 和 485 网络管理,大致分为 8 个 485 网 络 采用手动发卡、充值、数据采集、挂失等管理硬 件 软件分析报表 日工作量分析: 1 充值 按照每个月一人充值一次,5000/30 =160 人次 2 挂失和消卡 5000/250= 20,下载量为: 20*(50+100+100)= 5000 次/台 3 记录量,依次为 消费 考勤 门禁 5000*3+5000*4+5000*6 = 65000 4 报表统计 10-20 张 5 系统故障处理 按照 1 年返修 1 次,平均每天接近 250/356=0.7 台 实际配备: 1 专职一卡通操作人员 1 名,后备人员 1 名 2 流程协同人员三名,工作量约为 30%。 3 硬件维护处理 0.5 人,软件和系统维护 0.5 人。 1 充值 按照 1 人 1 次 15-30 秒,时间为 40 分钟 到 80 分钟 2 挂失 按照 1 次/台 1S 的速度,大约要 1.5 小时 3 采集数据 按照 1 秒/5 条处理速度 3-4 小时。 1 人力成本比较高,虽然一卡通的实施带来很大 的经济效益,但提高的余地依然不小 2 才名单控制的方式,是有缺陷的,缺陷在于 每 台机器都必须存储那么黑名单,效率及其低下, 传统模式在此规模的应用中,弊端很多。 3 使用人员的体验依然不够,自动化程度低
以下介绍几种常见的 RFID 开发方式 金蝶模式 细节描叙 优点 缺点 特点总结 用友模式 细节描叙 优点 缺点 特点总结 普通模式 细节描叙 优点 特点总结 1 在其系统中增加一个发卡模块,进行资料 和卡的绑定。 2 将设备管理和数据采集采用成熟的独立的 应用程序来管理。 3 仅支持数据接口,多为文本级别或数据库 表级别。 实现简单,方便,各个系统独立,责任和分 工明确 集成度不高,风险控制力比较弱 系统分散,流程上跨越多系统 程序的扩展和交互能力弱 半开半闭,相对灵活简易 全面在系统中集成各个功能,如发卡、数据 采集、硬件管理等,与原有系统全面融合。 系统集成度高,功能融合好,易扩展,风险 控制比较好 难度大,周期长,需要专业人员辅助开发 全封闭开发,高集成度,适合专业级别的开 发 根据厂家的 DLL 和开发说明,编写对应的控 制软件,实现软件、硬件的融合 对厂家:标准的二次开发方式,工作量比较 小,难度低。 对开发商:难度高,很难通过 DLL 和开发说 明,对整个系统进行优化,开发的结果也是 良莠不齐,风险比较难控制。 全开放的开发方式,与用友模式的区别在于, 他们开发时有专业的技术人员指导,因此能 够扬长避短。普通模式的后续开发能力往往 不足!
分享到:
收藏