从需求变化看门禁一卡通系统的发展 - RFID新闻中心

详情

从需求变化看门禁一卡通系统的发展

作者:王琰汪迎春

时间:2009-10-23 10:25:30

门禁控制管理系统（以下简称门禁系统）作为安防系统中的一个专业领域，在经历了构想、研发、生产、销售、使用、服务多个阶段后，现已发展成多元化、网络化、智能化、开放性的系统，也逐渐成为安全防范领域不可或缺的，且持续、迅猛发展的系统之一。

关键词: 门禁门禁一卡通智能卡

     中国的安全防范事业始于20世纪的70年代末期，发展至此，已有近30年。门禁控制管理系统（以下简称门禁系统）作为安防系统中的一个专业领域，在经历了构想、研发、生产、销售、使用、服务多个阶段后，现已发展成多元化、网络化、智能化、开放性的系统，也逐渐成为安全防范领域不可或缺的，且持续、迅猛发展的系统之一。近些年来，业主的使用范畴已不限于“安全”二字，更多地表现在人机结合，以人为主的综合的“智能化管理”环节，甚至成为节能环保管理的主体。

    门禁一卡通系统

    智能卡系统的实质是通过智能卡的认证，完成设备控制的系统。智能卡管理系统从最初的门禁系统，逐渐成为广泛应用的一卡通系统，几乎无所不能地涉及到单位运作管理的各个方面，从目前的应用来看，已经衍生出考勤、访客、巡更、会议签到、消费、物品流通、停车场出入、电梯控制等多个子系统模块，而且随着人员身份认证、物品认证等需求的拓展，智能卡系统的应用领域还在不断扩展。

    建设一卡通系统首先是界定系统的应用范围和功能，确立应用子系统，进而选择统一的认证介质，即智能卡的选型，并架设统一的一卡通管理平台。这样，才能保证多个应用子系统共用同一张智能卡，在一个平台、一个数据库中完成系统内所有人员的基本资料、各子系统的读卡信息的运作、存储和共享，以实现门禁、考勤、消费等子系统模块的应用功能。与智能卡介质统一一样，统一的系统平台也是一卡通系统建设的重要指标。

    一卡通系统平台集中保存着持卡人员的基本资料信息和一卡通系统运行数据，集中处理一卡通的系统运作，在整个系统中的地位显得极为重要。作为智能化系统集成的一个组成部分，一卡通系统应该是一个开放系统，系统平台通过OPC、SOCKET等标准的接口协议，可挂接与捆绑在IBMS、BAS、OA等系统中，实现相应的功能整合，实现与监控系统、消防系统、设备管理系统联动，并实现与OA、HR等单位运作管理系统的人员数据同步，例如：通过系统间的数据整合，一卡通系统中持卡人员基本数据可以随着人力资源部门相关数据的变化而及时更新；ERP系统可以及时获取一卡通系统中持卡人员考勤信息数据等。

    门禁一卡通系统的发展

    门禁是一卡通系统中应用最为广泛的子系统，从引进国内至今，系统的发展随着应用而扩展，使用者对门禁系统认知的深入，经历多个阶段。目前用户对门禁系统的要求主要体现在以下几个方面，如：系统是否稳定、是否能支持多类卡片、是否支持各种认证形式、与第三方系统的兼容性、通信反应时间的快慢、系统架构如何等几大方面。

    系统稳定性要求

    门禁系统初入市场时，由于技术欠缺等多种因素，导致门禁系统稳定性经常得不到保证，而作为直接融入日常管理的系统，因系统故障频发，使很多已建成的门禁系统成为摆设，没有有效发挥预想的作用，所以门禁系统的稳定性是系统建设的关键性需求之一。

    入侵报警、监控系统主要是从内外空间对保护区域进行监视，其安防作用有相当的被动性。而门禁系统与其不同，它目的是对出入保护区域的人员进行合法性认证，其具有相当的主动防卫性，要求是将危险源杜绝在外。这就要求门禁系统每年365天，每天24小时都必须连续不断地稳定运行，所以任何故障点都可能造成受控通道无法正常管控，进而造成安防上的漏洞。所以，门禁系统的特性之一是要求系统必须具有极高的可靠性。

     以单一受控点故障为例，同样是1%的故障率，10个门禁点的系统每10天出现一次故障；100点的门禁系统，系统故障每天都将发生；一个1000点的系统，物管人员每天都将面对受控门无法受控的尴尬，更不要说几千点的超大型系统了。

    从以上故障率的简单计算可以看出，一卡通系统的稳定性对用户日常的运作至关重要。而且，随着一卡通系统建设规模的日益庞大，系统复杂程度和系统对上层智能化系统，以及对下层子系统集成要求的日益提高，目前，门禁系统的稳定性和数据安全性指标依然是系统建设者必须面对的重点和难点。

    智能卡多样性要求

    随着系统的完善，智能卡从只读序列号的ID卡，升级到可读写卡片扇区内容的逻辑加密的IC卡，再到目前类似电脑存储信息模式的CPU卡，以及直接由手机 RF-SIM卡代替普通的智能卡；从几厘米的认证距离升级到几米，甚至几十米、几百米。智能卡的国际标准也陆续推出，目前常用的智能卡标准包括 ISO14443A/B、ISO15693、ISO18000-6X等。

    CPU卡的安全性和强大性能是业界公认的，迄今为止在通常的智能卡应用领域，CPU卡文件读取认证模式是最安全的智能卡应用方式。自从2009年初 Mifare1卡密钥被破解事件的披露，使智能卡的升级得以加速，如果说Mifare1、Legic这类逻辑加密卡是“硬盘”的话，那么目前真正意义上的自主加密，具有卡片独立数据运算能力的CPU卡就是一台计算机。

    另外，复合卡的出现让使用者更加觉得人性化、简捷化。比如CPU卡与18000-6B/C的复合卡等，既兼顾了近距离的门禁、消费等系统需求，又满足了停车场、通道管理等系统中远距离智能卡认证的需求。

    认证多样性要求

    随着用户需求和多种智能卡类型应用的发展，一卡通系统的智能认证模式也得到了迅速发展。智能卡认证已经涵盖了ID、IC、CPU卡，手机RF-SIM卡认证也作为一种新型的认证模式，纳入到门禁认证的范畴中来。

    CPU卡认证一般有两种，一种采用读取序列号的形式，这是变相的ID卡模式，完全不能发挥CPU卡的安全性和扩展性优势。另一种认证是通过读取CPU卡内部文件的模式，这种方式才能最大程度地运用CPU卡强大的性能，上海世博会的门禁系统均采用了CPU卡内部文件认证模式。

    生物认证作为“便携”和“唯一”的认证介质，与智能卡介质一起，在一卡通系统应用中也得到了发展，根据系统常规及高端应用的不同，目前指纹、掌形、面像、虹膜等生物识别认证，根据不同的要求和应用场合，均得到了广泛的采用。不过，生物认证模式由于技术发展的瓶颈，在稳定性、应用成本和系统构建难度等方面还存在一定的问题和实际应用的难度。

    此外，智能卡多重认证、智能卡+密码认证和生物识别+卡片认证等复合认证模式，也根据不用的安全等级和环境要求得以应用。

    还有一些比较特殊的认证模式被用户提出，并逐步形成产品，如：短信临时认证和语音信箱认证。

    1、短信临时认证：内部用户在门禁读卡器上输入特定号码，系统服务器确认后，自动生成一个随机码，以短信的方式发送到用户手机，用户再使用这个临时卡号实现身份验证、开门等功能，而临时卡号在使用一次之后就自动失效。
    2、语音信箱认证：用户通过电话拨打一卡通控制中心特服号，根据语音提示操作，系统判断用户的特定编码以及输入的密码，来实现身份验证，在系统中记录相关事件以备今后查询。

    另外，认证设备及读卡器的传输方式也随着系统的应用发展而变化着，从最初单一的Wiegand通信，逐步发展出T2、RS232等。大型、超大型门禁系统（200点以上、上千点）的建设，对系统构建又提出了新的要求，为了方便大型系统的调试和日常运行的设备维护，用户一般要求门禁控制器集中安装在弱电间，这就意味着面积较大的建筑内的读卡器与控制器距离会超过100米，甚至更远。传输距离有限的Wiegand、T2等通讯协议的读卡器只能望而却步，应运而生的即是传输距离可达1200米的RS485读卡器。

    系统兼容性

    在门禁一卡通系统建设时，为了达到业主完善，以及个性化的功能和管理需求，经常需要与第三方系统进行整合，如IBMS、BA、CCTV、消防系统等，整合方式有软件和硬件两种模式。

    门禁系统与消防系统集成、协同运作，当紧急情况发生时，受控门应自动打开电锁，根据消防要求，此动作一般采取断电开锁的硬件方式。以某美国品牌的系统架构为例，其将DI/DO联动模块直接接入门禁控制器ACUD的RS485总线，以完成硬件联动功能。

    软件模式主要是运用标准的通讯协议，实现各系统间的整合。标准的通讯接口协议包括ODBC、OPC、SOA、SOCKET等，通过这些标准接口，系统间互换数据信息，以实现相关的功能联动。如一卡通系统（考勤子系统）可作为企业、事业单位管理系统的辅助系统，需要与人事管理、财务管理相融合，与MIS、 ERP系统整合。在医疗单位，一卡通系统（消费子系统）可与就诊卡系统、病例、处方、住院管理、医用品管理系统融合，与HIS系统整合等等，这样的功能整合需求不胜枚举。

    系统架构分析

    目前一卡通系统的规模越来越大，建筑面积几十万平方米的大型、超大型建筑群的系统、跨地域的集团性企业统一数据库管理整合型系统、超大型连锁企业的系统，这些庞大系统的控制点往往都在一千点以上，甚至三、四千点，门禁一卡通系统的结构也随着这些系统的需求发生着构架建设革命和控制设备升级。

    RS485总线系统存在传输距离、通信速率、总线效率等诸多方面的问题，已经不能满足大型化系统建设的要求。

    适应大型、超大型的，基于TCP/IP的门禁架构已逐渐成为市场的主流。此架构一般嫁接于建筑内的局域网，采用事件触发机制，用双绞网线和光纤保证传输速率、传输距离，为了保证系统的安全性，可独立架设网络，或者通过VLAN划分专用网段的方式。

    在此选用某美国品牌的系统架构为例进行详述。该品牌的TCP/IP门禁系统由管理层、控制层与终端层的三层架构组成，且支持Internet、RS- 485等不同通讯协议的硬件接入，其管理层、控制层间采用TCP/IP网络、控制层与终端层间采用RS-485结构，参见图1。

620)this.style.width=620;" border=0>

多栋建筑组成的门禁系统只需通过TCP/IP即可实现传输、共享相关的数据。传输的数据要采用加密形式，保护敏感信息，防止非法截取、破译，Internet、RS-485、WIFI等通讯协议的硬件搭配保证了超大终端容量的一卡通系统。

由于TCP/IP和RS-485架构的应用环境和网络架构等的不同，所以它们的性能差别较大，表1是两种网络架构的性能对比表，供参考。

620)this.style.width=620;" border=0>

数据通讯速率

基于TCP/IP的门禁架构的优越性体现在很多方面，包括数据通讯的速率。此节继续以某美国品牌的系统架构为例，参见图2重点讲述通讯速率。

620)this.style.width=620;" border=0>

     某美国品牌的门禁系统为实时系统，当门禁控制点数在500点以上时，图控报警的反应时间和与CCTV系统联动的反应时间，经实测基于TCP/IP及RS485混合架构的系统约在200毫秒左右，而基于全RS485架构的往往在数秒钟。

    数据量计算

    1、读卡器与门禁控制器ACU的通讯

    下层读卡器对ACU每发送一次信息最多需要传送14Bytes，ACU对下层读卡器每发送一次信息最多需要传送6Bytes，合计20Bytes。每个ACU下面最多接4个读卡器，ACU和每个读卡器各通讯一次，总共需要传送20×4=80Bytes。

    ACU到下层读卡器的默认通讯速度为19200BPS，在此方式下每秒钟可传送19200/8=2400Bytes，考虑信息量每次都是最多而且设备也最多的情况下，ACU对下挂的每个读卡器，每秒钟可以完成2400/80=30次通讯，即表示读卡的理论响应时间从通讯上考虑一般会在约1/30秒。

    2、门禁控制器ACU与网络控制器NCU的通讯

    下层设备（ACU）对NCU每发送一次信息最多需要传送14Bytes。NCU对下层设备（ACU）每发送一次信息最多需要传送6Bytes，对数据加密后长度不会产生变化，还是6Bytes，合计20Bytes，那么完成这样一次通讯最多需要传送14+6=20Bytes。每个NCU下面最多接15个下层设备（ACU），NCU和所有15个下层设备各通讯一次，总共需要传送20×15=300Bytes。

     综合上述ACU与读卡器、NCU与ACU的通信响应时间，如果有人刷卡，则响应时间要以NCU与ACU的通信响应时间为准进行计算，即约1/8秒（0.125秒）。以上是理想的理论计算，实际可能还会稍稍有点折扣。

    3、从刷卡到图控显示的理论通讯反应时间

    读卡器对上层ACU的通讯反应时间约为1/30秒（0.033秒）；ACU运算及发出的反应时间为1/100秒（0.01秒）；ACU对上层NCU的通讯反应时间为1/8秒（0.125秒）；NCU运算及发出的反应时间为1/200秒（0.005秒）；NCU对计算机的通讯反应时间为1/500秒（0.002秒）；即可推算出刷卡后到图控显示的反应时间肯定要小于0.2秒（以最长ACU与NCU的通讯反应时间为准计算）。

    再考虑到通讯的延时和等待，在最坏的情况下，任何系统事件产生的反应时间约在300ms（0.3秒）。NCU把事件传输到计算机上是采用100M网络方式，这个时间非常少可以忽略不计，就是说任何事件发生以后，到计算机上有反应只要0.3秒时间。

    而平时正常情况下的通讯，并不会每次都是数据量最大且通讯最坏的情况，所以实际上事件到计算机的响应时间，肯定要小于200ms（0.2秒）。

    结语

    随着用户对系统了解的深入，系统功能的需求正向着大型化、管理型系统变化，一卡通系统也在智能卡应用类型、认证方式、应用子系统扩展和系统构架等各方面得到了全面发展。期望未来的门禁一卡通系统可以做得完美无缺，为安防增添薄力，使中国的智能化事业更上一层楼。(作者:王琰汪迎春现任职于汉军智能系统（上海）有限公司)

上一篇：ASK发布新款非接触 USB 阅读器LoGO 下一篇：杭州采荷街道采用电子标签防止电动车被窃

劳动力管理厂商 Kronos 签约艾默生过程控制

10/20

我司新款ID读卡模块降价！

10/10

宁波捷思特电子科技有限公司关于涉及人权隐私方面的声明

09/29

首都机场启用面相识别门禁错误率仅为0.01%

09/29

日本发布新智能考勤系统监视？管理？

09/22

关于我们联系我们电脑端