杭州市居所出入(智能门禁)服务管理平台接入规范v1.0.5.docx

杭州市居所出入（智能门禁）服务管理平台接入规范杭州市居所出入（智能门禁）服务管理平台接入规范（V 1.0.5）2015年10月目录1 背景目标31.1 项目背景31.2 项目目标31.3 适用范围32 规范性引用文件和术语定义42.1 规范性引用文件42.2 术语定义53 第三方接入规范63.1 接入原则63.2 接入流程63.2.1 接入流程图63.2.2 设备接入流程73.2.3 平台接入流程114 第三方接入接口协议144.1 设备接入接口协议144.1.1 设备接入要求144.1.2 设备管理机制154.1.3 设备通信机制194.1.4 通信协议244.1.5 协议字段定义684.2 平台接入接口协议834.2.1 协议概述834.2.2 通讯方式854.2.3 接口协议854.2.4 数据安全854.2.5 报文总体格式854.2.6 业务接口89108 / 1081 背景目标1.1 项目背景我市流动人口的涌入，不仅为杭州城市建设、经济发展提供了充足的人力资源，做出积极的贡献，但与此同时，流动人口的大量聚集以及流动性和不确定性，给城市带来了社会治安、文化教育、计划生育等一系列管理难题。依据涉密略（浙委办20145号）、涉密略（杭委办201475号）、杭州市流动人口服务管理条例、杭州市人民政府办公厅关于组织申报杭州市2014年政府系统政府投资信息化建设项目的通知、关于印发“智慧杭州”建设总体规划(2012-2015)的通知等条例和文件要求，提出流动人口动态信息（居所出入智能门禁）管控平台建设需求。1.2 项目目标以动态信息中的“住”信息采集为目标，采用物联网技术，通过居所智能门禁前端对流动人口相关信息的实时和动态采集，建立流动人口“住”信息数据库，通过对本项目平台的建设及应用，提高流动人口居所的安全性，规范流动人口信息采集的流程，促进流动人口居住信息登记质量，提升政府相关部门服务管理水平。1.3 适用范围本规范是杭州市居所出入（智能门禁）服务管理平台（以下简称“市平台”）的接入规范指导，是杭州市范围内各类智能门禁系统的数据、设备接入市平台基本依据。本规范适用于杭州市范围内所有已建智能门禁项目改造和新建智能门禁项目。本规范适用于杭州市范围内具有智能门禁管理要求的住宅小区、出租屋、企业以及其他形式的社区和场所，包含老旧居所改造、新建居所等场景。2 规范性引用文件和术语定义2.1 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。本规范引用的文件均不注日期，其最新版本适用于本标准。DB3301/T0007 流动人口信息 居所出入服务管理系统建设规范GB/T 2260 中华人民共和国行政区划代码GB/T 2261.1 人的性别代码GB/T 3304 中国各民族名称的罗马字母拼写法和代码GB/T 4766 婚姻状况代码GB/T 10114 县级以下行政区划代码编制规则GB/T 14916 识别卡 物理特性GB/T 16260 软件工程 产品质量GB/T 22239 信息安全技术 信息系统安全等级保护基本要求 GB/T 23705 数字城市地址信息公共平台地名/地址编码规则GB/Z 28828 信息安全技术 公共及商用服务信息系统个人信息保护指南GB 50348 安全防范工程技术规范GB 50396 出入口控制系统工程设计规范GA 56.2 暂住人口基本信息管理标准GA 374 电子防盗锁国家标准2.2 术语定义下列术语和定义适用于本规范。1、 流动人口指在本市区居住的非本市区户籍的人员，以及其他县（市）居住的非本县（市）户籍的人员，不包括境外人员。2、 流动人口居所出入信息主要包括流动人口姓名、性别、民族、出生日期、公民身份号码、户籍地址、现居住地址、历史居住记录、实时开门记录等信息。3、 流动人口综合信息平台在专网或VPN上运行，汇集、整合城乡建设、公安、民政、人力社保、教育、计生等部门采集的流动人口信息，并实现共享的信息系统。4、 流动人口居所出入服务管理系统流动人口居所出入服务管理系统由居所出入平台、传输网络、前端设备、出入卡、密钥管理系统等部分组成，以下简称“居所出入系统”。5、 居所出入平台在专网或VPN上运行的信息系统，具有流动人口居所出入信息采集、管理、应用和居所出入卡管理、用户权限分类设定和管理、报警管理等功能。6、 前端设备指特定用于流动人口居所出入信息采集，由识读设备、管理控制设备、执行设备和传输设备等组成的安装在门端的设备集合。7、 居所出入卡指应用于居所出入系统，具有个人信息存储、门禁认证及附加应用功能的非接触集成电路卡，以下简称“出入卡”（包含集成居所出入功能的“市民卡”等）。3 第三方接入规范3.1 接入原则1、 已建设项目杭州市范围内需要接入市平台的所有已建设完成的智能门禁项目，使用现有平台接入市平台，依据规范上传数据至市平台。2、 建设中项目杭州市范围内需要接入市平台的所有建设中的智能门禁项目，根据项目建设情况，酌情选择使用平台接入或者设备直接接入市平台，依据规范上传数据至市平台。3、 待建设项目杭州市范围内需要接入市平台的所有待建设的智能门禁项目，使用门禁设备或平台直接接入市平台，依据规范上传数据至市平台，同时使用市平台实现逐级管理相关门禁设备。3.2 接入流程3.2.1 接入流程图3.2.2 设备接入流程3.2.2.1 接入申请提交、审核1、 申请资料提交杭州市范围内需要使用门禁设备直接接入市平台的智能门禁项目，项目业主或者承建单位需要书面提交接入申请和相关资料，资料包括但不限于：接入申请书、项目概况、项目周期、承建单位概况、接入技术实现方案、接入规模、联系人、联系方式等。2、 市平台承建单位验证测试市平台承建单位根据接入申请资料中技术方案对接入方案进行验证测试，出具验证测试报告提供市流口办参考。3、 市流口办审核市流口办依据相关规范流程、接入申请资料和验证测试报告对接入方进行审核。4、 发布审核结论市流口办对接入方审核完成后，通过规定的途径发布审核结论，对于审核通过的接入方，分配接入所需的市平台账号密码、厂商代码等资料，对于审核未通过的接入方，反馈相关问题给接入方，督促尽快完善相关资料。3.2.2.2 接入调试、评估1、 接入方产品开发接入方依据市平台接入规范相关要求开发待接入市平台的产品。2、 技术联调接入方产品开发完成后，依据市平台接入规范相关要求与市平台承建单位进行技术联调，确认产品各项参数是否符合要求，是否能够正常的接入市平台。3、 接入产品完善若接入方产品经过联调，发现相关问题影响产品接入市平台，需对产品进行完善。4、 接入试运行接入方认为产品完全满足市平台接入规范相关要求，同时确认产品可正常稳定的接入市平台后，接入方选取一定数量的产品接入至市平台试运行一段时间（具体试运行数量和时间由市流口办确定）。5、 市平台承建单位验证测试市平台承建单位从技术角度、上传数据角度等对接入方进行验证测试，并出具验证测试报告供市流口办参考。6、 市流口办评估并发布结果市流口办依据相关规范流程、验证测试报告等对接入方进行评估，并通过规定的途径发布评估结果，对于评估通过的接入方，流口办书面下发准入证明，准予正式接入市平台，对于评估未通过的接入方，反馈相关问题给接入方，督促尽快完成技术整改。3.2.2.3 正式接入、定期评估1、 正式接入接入方依据市平台接入规范相关要求，提供接入产品的详细信息，包括但不限于：出品商、生产日期、产品序列号、产品MAC地址等，接入方接入相关产品时，市流口办或者市平台承建单位依据相关信息，验证每一个接入市平台产品的合法性。2、 流口办定期发起评估要求在市平台正常运行期间，流口办可定期发起接入产品评估要求，抽查若干产品进行评估，确保所有接入产品符合市平台接入规范。3、 市平台承建单位验证测试市平台承建单位从技术角度、上传数据角度等对抽查产品进行验证测试，并出具验证测试报告供市流口办参考。4、 市流口办评估并发布结果市流口办依据相关规范流程、验证测试报告等对抽查产品进行评估，并通过规定的途径发布评估结果，对于通过评估的产品接入方，流口办书面下发验收通过报告，对于未通过评估的产品接入方，暂停其接入资格，反馈相关问题给接入方，督促尽快完成技术整改。3.2.3 平台接入流程3.2.3.1 接入申请提交、审核1、 申请资料提交杭州市范围内需要使用现有平台接入市平台的智能门禁项目，项目业主或者承建单位需要书面提交接入申请和相关资料，资料包括但不限于：接入申请书、项目概况、项目周期、承建单位概况、接入技术实现方案、接入规模、联系人、联系方式等。2、 市平台承建单位验证测试市平台承建单位根据接入申请资料中技术方案对接入方案进行验证测试，出具验证测试报告提供市流口办参考。3、 市流口办审核市流口办依据相关规范流程、接入申请资料和验证测试报告对接入方进行审核。4、 发布审核结论市流口办对接入方审核完成后，通过规定的途径发布审核结论，对于审核通过的接入方，分配接入所需的接口地址、接口账号密码、厂商代码等资料，对于审核未通过的接入方，反馈相关问题给接入方，督促尽快完善相关资料。3.2.3.2 接入调试、评估1、 接入方平台改造接入方依据市平台接入规范相关要求对待接入市平台的平台进行改造，新增市平台接入相关功能。2、 技术联调接入方平台改造完成后，依据市平台接入规范相关要求与市平台承建单位进行技术联调，确认平台各项功能是否符合要求，是否能够正常的接入市平台。3、 接入产品完善若接入方平台经过联调，发现相关问题影响平台接入市平台，需对平台进行完善。4、 接入试运行接入方认为平台完全满足市平台接入规范相关要求，同时确认平台可正常稳定的接入市平台后，接入方将平台接入至市平台试运行一段时间（具体试运行时间由市流口办确定）。5、 市平台承建单位验证测试市平台承建单位从技术角度、上传数据角度等对接入方进行验证测试，并出具验证测试报告供市流口办参考。6、 市流口办评估并发布结果市流口办依据相关规范流程、验证测试报告等对接入方进行评估，并通过规定的途径发布评估结果，对于评估通过的接入方，流口办书面下发准入证明，准予正式接入市平台，对于评估未通过的接入方，反馈相关问题给接入方，督促尽快完成技术整改。3.2.3.3 正式接入、定期评估1、 正式接入接入方依据市平台接入规范相关要求，提供接入平台的详细信息，包括但不限于：出品商、公网IP、服务器网络MAC地址等，接入方接入相关平台时，市流口办或者市平台承建单位依据相关信息，验证每一个接入市平台的平台合法性。2、 流口办定期发起评估要求在市平台正常运行期间，流口办可定期发起接入平台评估要求，抽查若干平台进行评估，确保所有接入平台符合市平台接入规范。3、 市平台承建单位验证测试市平台承建单位从技术角度、上传数据角度等对抽查平台进行验证测试，并出具验证测试报告供市流口办参考。4、 市流口办评估并发布结果市流口办依据相关规范流程、验证测试报告等对抽查平台进行评估，并通过规定的途径发布评估结果，对于通过评估的平台接入方，流口办书面下发验收通过报告，对于未通过评估的平台接入方，暂停其接入资格，反馈相关问题给接入方，督促尽快完成技术整改。4 第三方接入接口协议4.1 设备接入接口协议4.1.1 设备接入要求4.1.1.1 设计原则与目标简化通信协议形式（减少冗余）节约GPRS流量数据安全可扩展性兼容Internet/GPRS方案4.1.1.2 物理连接GPRS/3G网接入宽带接入4.1.1.3 通信方式TCP短连接，承载业务命令UDP长连接，实现唤醒通知机制（可选）SMS短信通道，实现唤醒通知机制（可选）UDP高速数据通道4.1.2 设备管理机制4.1.2.1 设备状态管理4.1.2.1.1 主控器状态主控器的工作状态可以从uploadStatus或者queryStatus等指令中获得，工作状态是一个字节，0代表主控器正常工作，其他数字代表异常状态码主控器的联机状态，主要由唤醒通道的可用性和TCP安全信道的可用性两者组成。假设用1个字节来表达联机状态。Bit0-bit3：低半字节代表主控器唤醒通道（UDP/短信）的可用性0000 代表不可用0001 代表短信通道可用0010 代表UDP通道可用Bit4：是否建立了TCP安全信道连接0代表NOT CONNECTED1代表CONNECTED如果主控器异常无法连接中心服务器（比如主控器断电、无法上网等），服务器是没有办法主动得知这种状态的。所以只能设定主控器定期上传一个“活跃”事件，当服务器超出一定时间后没有获得“活跃”事件，就可以标记这一主控器处于异常状态，以便发出告警，让管理人员人工干预（比如现场检查）。4.1.2.1.2 门锁状态门锁的状态，包括门锁的联机状态（是否与主控器正常的建立了连接），门锁自身的工作状态、门锁电池电量、温度等参数组成。门锁没有TCP连接状态，但是和主控器一样，也要根据最后一次状态更新的时间戳，如果长时间没有更新状态，则可以判定门锁异常。4.1.2.2 设备密钥管理4.1.2.2.1 主控器密钥在主控器上保存了多组密钥，每组密钥做不同的用途。密钥编号算法类型长度密钥用途使用频率（无）DES/3DES16临时会话密钥，在建立TCP安全信道的时候协商产生，不允许通过SetupKey指令修改频繁0x01DES/3DES16认证密钥，在建立安全通道的时候使用，用于客户端和服务端相互认证身份。允许通过SetupKey指令修改。中0x02DES/3DES16DEK密钥，加密敏感数据，在SetupKey指令中，用于加密新密钥。允许通过SetupKey指令修改。低0x03DES/3DES16短信通知密钥，只能用于加密唤醒通知短信中16字节的密钥，在DES运算中，只取用前8字节。4.1.2.2.2 PSAM卡密钥PSAM卡上保存了SM1加解密用的SM1密钥，具体细节参考PSAM卡规范。4.1.2.2.3 临时会话密钥临时会话密钥在TCP安全信道建立的时候协商而来，只有在session生命周期内有效。4.1.2.3 时间同步机制主控器与门锁等设备有时需要相对精确的时间，为了获得标准时间，本协议提供两种时间同步机制。1、 通过在主控器上配置公共NTP/SNTP服务器地址，从INTERNET上获得标准时间。2、 提供一种简单的内部校时机制，从协议服务器上获得时间。如果允许的话，建议使用公共NTP/SNTP服务器做时间同步。第二种内部较时方案只是作为备选。内部较时的原理如下：服务器提供一条获取时间的指令。假设客户端，在本地时间a这个时间点上，发出读时间指令，在本地时间点b获得了指令放回，返回值是服务器时间值x；假设客户端与标准时间（即服务器时间）相差t（即标准时间=客户端时间+t）。那么：指令上行延迟up = x - (a+t)指令下行延迟down = (b+t) - x指令总共消耗的时间是total =up +down = b - a上下行延迟主要决定于网络延迟，上下行延迟的比例主要决定于网络延迟网络上下行速率比例，这一参数和具体的网络状况有关，比如GPRS一般下行速率比上行速率大。假设比例参数 k =down/total，在同一时段、同一网络环境下是一个相对稳定的数字。k =down/total = (b+t) - x) / (b - a)t = x - b + k * (b - a)k的取值范围在(0, 1)区间内，考虑极限值：k = 0的情况下：t_min = x - b k = 1的情况下：t_max = x - b + (b-a) = x - a在延迟很小的情况下（例如b-a C)WELCOME:version服务器支持的最高协议版本号random1服务端随机数 8 bytesStep 2. 客户端选定协议版本号，生成随机数，发送INIT命令给服务器(C-S) INIT_REQ: DUID, 客户端设备唯一识别码random2, 客户端生成的随机数 8 bytesversion协议版本号authenticateData客户端认证数据（根据random1计算）(S-C) INIT_RESP: status错误码（0代表成功）authenticateData服务端认证数据（根据random2计算）sessionId会话Id，8字节* 约定临时会话密钥sessionKey的生成算法：使用认证密钥（主控器上存储的密钥编号为0x01）对明文数据 (random1 xor random2) + (byte)0x12 + (byte)0x28+ 6个(byte)0x00) 进行3DES_CBC加密，生成16字节结果，作为临时会话密钥。* 客户端认证数据的生成算法：第一步，使用会话密钥对明文数据 (random1 + (byte)0x13 +(byte)0x29 + 6个(byte)0x00 +8字节的设备唯一识别码) 进行进行3DES_CBC加密（如果输入数据长度不足8个字节的整数倍，则填充0x00）第二步，将第一步的输出结果，做MD5哈希计算，输出的16个字节作为客户端认证数据数据。* 服务端认证数据的生成算法：第一步，使用会话密钥对明文数据 (random2 + (byte)0x14 +(byte)0x30 + 6个(byte)0x00 +8字节的设备唯一识别码) 进行进行3DES_CBC加密（如果输入数据长度不足8个字节的整数倍，则填充0x00）第二步，将第一步的输出结果，做MD5哈希计算，输出的16个字节作为客户端认证数据数据。客户端和服务器端双方相互认证合法性后，session正式建立。4.1.3.7 重用安全信道会话在会话有效期内，会话可以重用。Step 1. 建立TCP连接后，服务器告知客户端，自己支持的最高协议版本号，并生成通信随机数(S-C)WELCOME:protocolVersion服务器支持的最高协议版本号random1服务端随机数 8 bytesStep 2. 客户端跳过INIT命令，直接发送控制命令，同时携带session验证数据。(C-S) COMMAND WITH SESSION_DATA ：sessionId会话Id，8字节authenticateData客户端认证数据（对random1进行加密，以供服务器验证合法性）(S-C) COMMAND RESPONSE: status错误码（0代表成功）如果sessionId过期或者非法，status提示ERROR_INVALID_SESSION。客户端应该重新走INIT流程，建立安全通道后，重发这个控制命令。4.1.3.8 SM1-LV分组机制假设分组长度为N，加密过程是：首先把原始数据切分成长度为(N-1)的一个个分组，在每组数据前面加上本组长度字节L，分别进行SM1_ECB运算，如果长度不足，填充80 00 00 .；再把各组加密结果拼接在一起就组成了加密输出。解密过程则相反：首先把密文数据切分成长度为N的一个个分组，分别进行SM1_ECB解密，去除头一个字节L后，去除填充字节，把有效数据拼接组成原始明文。一般分组长度N=192 (0xC0)。4.1.3.9 CRC算法协议中使用到了CRC16/CRC32算法。CRC16使用多项式：1 + x2 + x15 + x16CRC32使用多项式：1 + x + x2 + x4 + x5 + x7 + x8 + x10 + x11 + x12 + x16 + x22 + x23 + x26 样例：CRC16(123456789): bb3dCRC32(123456789): cbf439264.1.4 通信协议4.1.4.1 通信协议格式定义4.1.4.1.1 数据类型Integer指定长度的无符号字节数，采用网络字节序（Big Endian）编码String由可读字符组成的字符串Bytes固定长度的字节数组TLV简单TLV数据对象Bits比特位。bit0代表最低位，bit1.bit7依次，Bit8是第二字节的最低位，以此类推。TLV格式采用“简单TLV数据对象”的约定： 标记字段T由1个字节或2个字节组成，一个字节的Tag取值范围0x01-0xEF，两个字节Tag，前一个字节取值范围0xF0-0xFE，后一个字节的取值范围是0x00-0xFF。首字节0xFF保留做扩展用途 长度字段由1个字节或3个连续字节组成。如果长度字段的首字节处于从OO至FE的范围内，则长度字段由单个字节组成，该字节编码从0至254中的一个整数L。如果首字节等于FF，则长度字段后续2个字节使用从0至65535中的值编码了一个整数L。如果L不为空，则值字段V由L个连续字节组成。如果L为空，则数据对象为空:不存在有效字段。4.1.4.1.2 安全报文格式通用安全报文格式字段名长度描述必选/可选Packet Length2报文总长度（包括自身）M报文头Head Length1头长度（包括自身，从Head Length到Head Extension的长度）MSPI1SPIMPADDING1加密填充字节数，如果有加密，则存在此字段OCRC2CRC16校验值OHead ExtensionX多个TLV构成的报文头扩展数据（明文）OUser DataX多个TLV构成的用户数据（或其密文）M4.1.4.1.3 SPI字段编码b7b6b5b4b3b2b1b0RFU是否存在CRC16字段0：不存在1：存在密钥选择 00：默认密钥 01：指定密钥1 10：指定密钥2 11：其他密钥（保留用作扩展用途，比如可以在头扩展里面指定密钥）用户数据的加密方法000：不加密001：用DES-CBC加密010：用3DES-CBC加密011：用SM1-CBC加密100：用SM1-LV分组加密，分组长度为192字节（ECB）其它数值保留默认密钥在TCP安全会话中，指的是临时会话密钥。指定密钥由通信双方约定，比如对于主控器而言，密钥1代表了主控器上存储的通信密钥，其他值暂时不用。在支持SM1加密的门锁上（由PSAM卡提供SM1算法API），默认密钥代表PSAM卡内存储的加密密钥。在短信通道上，默认密钥代表短信通知密钥（密钥类型03）4.1.4.1.4 CRC校验采用CRC32或者CRC16算法，对原始用户数据UserData（不包括填充字节）明文进行校验。除非对字节数极端敏感（比如门锁和主控器之间，需要控制通信的包长度和数量，以节约电池电量），否则建议用CRC32。4.1.4.1.5 报文头扩展报文头扩展数据必然是明文的，不参与加密。只有一些特殊参数才需要放在报文头扩展里面，比如在重用安全会话时声明sessionId等。本文中需要放在报文头扩展中的特殊参数，会专门指出，没有做专门声明的可选或者必选参数，都是作为用户数据存在的。4.1.4.1.6 填充与校验安全报文的组包过程，先计算明文的CRC，再填充字节0，再加密。4.1.4.1.7 welcome报文格式Welcome报文是服务器发给每一个刚刚建立TCP连接的客户端的，不需要回复，不包含敏感数据，所以建议SPI = 0，不需要CRC校验，也不需要加密。报文参数（放在用户数据）：TagLength描述必选/可选M_request1commandID = WELCOME，无流水号MM_version1服务器支持的最高协议版本号，版本号的高半字节代表主版本号，低半字节代表次版本号（下同）MM_random8服务器生成的随机数M4.1.4.1.8 重用信道报文格式主控器建立TCP连接以后，第一个上行控制命令中，在头扩展里面，携带以下信息，可以实现重用安全信道会话。头扩展参数：TagLength描述必选/可选M_sessionId8要重用的会话ID，服务器可以用这个会话ID，获得对应的设备地址。MM_authData16客户端认证数据 *M4.1.4.2 上行控制命令主控器发给服务器的控制命令称为上行命令。4.1.4.2.1 会话初始化初始化命令用于主控器建立安全通道会话。这条指令的请求报文是明文数据（不加密）。如果认证通过，则回复报文用协商出来的会话密钥加密（客户端以此验证服务器端的合法性）；如果认证失败，则回复报文已明文数据返回。命令名称：Initialize Session请求参数：TagLength描述必选/可选M_request5指令+流水号commandID = INITIALIZEMM_version1协议版本号MM_random8客户端生成的随机数MD_DUID8设备唯一识别码MM_authData16客户端认证数据 *M回复参数：TagLength描述必选/可选M_response6指令+流水号+错误码MM_sessionId8会话ID，如果不成功，此字段不存在O注1：临时会话密钥sessionKey的生成算法注2：客户端认证数据算法注3：M_features客户端支持的特性主控器是否支持DES/3DES加密主控器是否支持SM1加密是否支持UDP唤醒通道是否支持短信唤醒门锁是否支持SM1加密4.1.4.2.2 时间同步时间同步命令提供了一种精度到秒的简单时间同步机制，将中心服务器作为主控器时间同步的源。具体的原理和算法，参考“时间同步机制”这一章节的描述。这条指令的请求和回复报文都是明文（不加密）。命令名称：Time Synchronize请求参数：TagLength描述必选/可选M_request5指令+流水号commandID = TIME_SYNCM回复参数：TagLength描述必选/可选M_response6指令+流水号+错误码MM_time4时间，与UTC时间1970年时间差，以秒为单位M4.1.4.2.3 上线通知控制器发给服务器的设备上线通知。设备上线，或者重启时，需要发送此通知命令。在没有UDP长连接通道的情况下，主控器定期更新服务器上的设备工作状态，也可以用这条命令。服务器通过短信或者UDP通道唤醒主控器，主控器如果要重用安全信道会话，并且没有其他的控制命令要上传的话，也可以用这条命令做为建立TCP连接后的第一条控制命令。（携带sessionId及认证数据）命令名称：Online Notify请求参数：TagLength描述必选/可选M_request5指令+流水号commandID = ONLINE_NOTIFYMD_deviceInfo*x * n设备描述信息M回复参数：TagLength描述必选/可选M_response6指令+流水号+错误码MD_deviceInfo详细数据（子TAG）：TagLength描述必选/可选D_code2设备编码MD_workStatus1设备工作状态0：正常工作1：脱机2-0xff：其他异常状态码O4.1.4.2.4 状态上传控制器主动上发设备（包括主控器自身及门锁、传感器等子设备）状态信息的命令。门锁、传感器等子设备状态由控制器采集并保存，关键状态变更通过Upload Status命令主动上传。设备的各个状态字段作为可选项目，可以只上传数值变更的字段。命令名称：Upload Status请求参数：TagLength描述必选/可选M_request5指令+流水号commandID = UPLOAD_STATUSMD_statusInfo*x * n设备状态信息M回复参数：TagLength描述必选/可选M_response6指令+流水号+错误码M请求报文中D_statusInfo的详细数据和设备类型有关系。主控器的设备状态TagLength描述必选/可选D_code2设备编码，0代表主控器自身MM_time4状态采集时间MD_workStatus1设备工作状态0：正常工作1-255：其他异常状态码OD_version2主控器程序版本号，高字节代表主版本号，低字节代表次版本号，下同。OD_hardware2主控器硬件版本号，高字节代表主版本号，低字节代表次版本号，下同。OL_battery1主控器备用电池电量OL_gsmSignal1GSM信号(1-99)OL_networkMode1网络制式0:未知1:GPRS2:3G3:有线O门锁的设备状态TagLength描述必选/可选D_code2设备编码，MD_addressstring设备物理地址OD_workStatus1门锁工作状态0：正常工作1：脱机（没有与主控器建立连接）2-0xff：其他异常状态码OL_lockerFlags2门锁标志：低字节代表门锁状态Bit0：门开合（1是开，0是合）Bit1：锁开关Bit2：保险开关Bit3：自动上锁开关（关门后自动上锁）Bit4-Bit7 保留高字节代表门锁报警状态量：Bit8：强行开门报警Bit9：门未关好报警Bit10：门锁防拆报警Bit11：电池低电量报警（预警）Bit12：SAM卡即将过期报警（预警）Bit13：SAM卡过期或者错误（如果 Bit12为1则代表过期，为0则代表错误）Bit14：（指纹）身份验证未响应/验证错误报警（连续N次提示指纹验证后，但是都没有响应或者验证错误）OL_battery1门锁电池电量OL_temperature2门锁温度（需乘以0.0625）OL_signal1门锁信号强度（100-值）OM_time4状态采集时间MD_version2门锁程序版本号OD_hardware2门锁硬件版本号OL_popedomCapacity2门锁上的权限条目最大容量（card only）OL_popedomCount2门锁上的权限条目个数（card only）OL_fingerCapacity2门锁上的指纹数据最大容量OL_fingerCount2门锁上的指纹数据个数O拍照器的设备状态：TagLength描述必选/可选D_code2设备编码MM_time4状态采集时间MD_workStatus1设备工作状态（摄像头状态）0：正常工作1-255：其他异常状态码OD_version2拍照器模块程序版本号，高字节代表主版本号，低字节代表次版本号，下同。OD_hardware2拍照器模块硬件版本号，高字节代表主版本号，低字节代表次版本号，下同。OL_SdCapacity4SD卡总容量（单位：KB）OL_SdFreeSpace4SD卡空闲空间（单位：KB）O4.1.4.2.5 记录上传控制器上传记录数据的命令，主要指开门记录、告警记录。记录信息有可能是子设备（如门锁）缓存在控制器端的数据，也有可能是控制器自己生成的记录数据，具体来源由设备编码D_code来区分。命令名称：Upload Record请求参数：TagLength描述必选/可选M_request5指令+流水号commandID = UPLOAD_RECORDMD_record*x * n记录数据M回复参数：TagLength描述必选/可选M_response6指令+流水号+错误码M请求报文中D_record详细数据：TagLength描述必选/可选D_code2设备编码MM_secureHead1-xSPI/PADDING/CRC/Head Extension参考安全报文格式中，报文头部分的说明。MM_secureDatax报文用户数据（如果是加密数据，加密算法和密钥由SPI指定）M数据域D_secureData（解包后）里面携带TLVs：TagLength描述必选/可选L_openRecord3*开门或巡更记录OL_alertRecord3*告警记录OL_fileRecord3*（拍照器）照片文件记录O如果是L_openRecord3，为开门或巡更或者指纹验证记录。为了减少通信字节数（在门锁电池供电的条件下，可以有效的节约电池电量），L_openRecord3的内容详情采用更加高效的紧凑格式，而不是直接采用嵌套TLV。字段名长度描述必选/可选Record Type1记录类型：Bit0-bit2： 000 （未知） 001 开门 010 巡更 011 身份验证 100 关门其他数值保留Bit3： 0 软信号组合 1 其它自定义当Bit3 = 0时，高半字节代表软信号模式组合 Bit4 刷卡 Bit5 PIN/密码 Bit6 指纹 Bit7 RFU当Bit3 = 1时。Bit4-bit7： 0001 机械钥匙开门 0010 出门按钮开门 0011 把手开门 0100 外部信号（对讲机）开门 0101 远程命令开门 0110 强行闯入开门MResult Code1刷卡/开门/巡更/身份验证的结果。0 代表成功，其它数值代表错误代码。门锁使用状态码范围0x81-0xAF。未知错误使用0xFF。（具体的错误定义，参考5.2.2章节）MTimestamp4时间戳，与 UTC 1970年时间差，以秒为单位MLocker Status1门锁状态，低半字节代表开门前，高半字节代表开门后。Bit0/Bit4：门开合（1是开，0是合）Bit1/Bit5：锁开关Bit2/Bit6：保险开关Bit3/Bit7：自动上锁开关（关门后自动上锁）MAlarm Flags1门锁报警状态量：Bit0：强行开门报警Bit1：门未关好报警Bit2：门锁防拆报警Bit3：电池低电量报警（预警）Bit4-5： 00 SAM卡正常 01 SAM卡即将过期（预警） 10 SAM卡错误 11 SAM卡已过期Bit6：（指纹）身份验证未响应/验证错误报警（连续N次提示指纹验证后，但是都没有响应或者验证错误）MOptional Identifier1可选字段描述：Bit0：Card Type 是否存在Bit1：Card Number 是否存在Bit2：Card Extension是否存在Bit3：Finger ID是否存在OCard Type1（刷卡时存在）卡片类型：0x01：规范的CPU卡0x02：MIFARE卡0x03：市民卡0x11：工程测试卡0x21：超级卡OCard Number1+8卡片序列号（