《智慧校园一卡通综合管理系统设计规范》

ICS35.240.15

CCSL67

T/HEBQIA

团体标准

T/HEBQIAXXXX—XXXX

智慧校园一卡通综合管理系统设计规范

Designspecificationofsmartcampuscardintegratedmanagementsystem

（征求意见稿）

XXXX-XX-XX发布XXXX-XX-XX实施

河北省质量信息协会发布

T/HEBQIAXXXX—XXXX

目  次

前言..................................................................................II

1范围.................................................................................1

2规范性引用文件.......................................................................1

3术语和定义...........................................................................1

4缩略语...............................................................................1

5原则.................................................................................2

5.1智能性...........................................................................2

5.2安全性...........................................................................2

5.3可实施性.........................................................................2

5.4开放性和可扩展性.................................................................2

5.5可维护性.........................................................................2

6系统总体架构.........................................................................2

6.1系统架构设计要求.................................................................2

6.2系统架构.........................................................................3

6.3物理部署方式.....................................................................3

7系统功能要求.........................................................................4

7.1核心系统.........................................................................4

7.2应用系统.........................................................................7

7.3系统运维管理....................................................................12

8系统性能要求........................................................................13

8.1系统容量........................................................................13

8.2系统运行处理能力................................................................13

8.3系统运行环境....................................................................13

8.4系统资金清算....................................................................14

8.5系统特性........................................................................14

I

T/HEBQIAXXXX—XXXX

前  言

本文件按照GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定

起草。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

本文件由河北赫烁科技有限公司提出。

本文件由河北省质量信息协会归口。

本文件起草单位：河北赫烁科技有限公司、XXX。

本文件主要起草人：高福盛、牛立明、赵更新、崔金龙、袁长青、XXX。

II

T/HEBQIAXXXX—XXXX

智慧校园一卡通综合管理系统设计规范

1范围

本文件规定了智慧校园一卡通综合管理系统设计规范的缩略语、原则、系统总体架构、系统功能要

求和系统性能要求。

本文件适用于智慧校园一卡通综合管理系统设计规范。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

GB/T22239信息安全技术网络安全等级保护基本要求

3术语和定义

下列术语和定义适用于本文件。

3.1

智慧校园一卡通综合管理系统smartcampuscardintegratedmanagementsystem

通过移动互联网技术，以关联系统、核心系统、应用系统、终端和介质为架构，涵盖消费、圈存、

缴费、水控、门禁、请假、宿舍、门锁、报修和公众号管理等功能，实现学校对教职工和学生全方位管

理的系统。

注：本文件以下简称系统。

4缩略语

下列缩略语适用于本文件。

4G——第四代移动通信技术（The4thGenerationMobileCommunicationTechnology）

5G——第五代移动通信技术（The5thGenerationMobileCommunicationTechnology）

AIX——AIX操作系统（AdvancedInteractiveeXecutive）

B/S——浏览器/服务器模式（Browser/Server）

CAN——控制器局域网总线（ControllerAreaNetwork）

CPU——中央处理器（CentralProcessingUnit）

J2EE——Java2平台企业版（Java2PlatformEnterpriseEdition）

HTTP——超文本传输协议（HyperTextTransferProtocol）

IC——集成电路（IntegratedCircuit）

ID——身份标识号（IdentityDocument）

IP——网际互连协议（InternetProtocol）

M1——狭义货币（NarrowMoney）

MAC——消息鉴别码（MessageAuthenticationCode）

1

T/HEBQIAXXXX—XXXX

MD5——信息-摘要算法（Message-digestAlgorithm5）

MQ——消息队列（MessageQueue）

NFC——近场通信（NearFieldCommunication）

PC——个人计算机（PersonalComputer）

POS——销售终端（PointofSale）

RAID——分布式奇偶校验的独立磁盘结构（RedundantArrayofIndependentDisks）

Redis——远程字典服务（RemoteDictionaryServer）

RJ45——注册插孔（RegisteredJack45）

RS232——异步传输标准接口（RecommendedStandard232）

SAAS——软件运营服务（SoftwareasaService）

TCP——传输控制协议（TransmissionControlProtocol）

TCP/IP——传输控制协议/因特网互联协议（TransmissionControlProtocol/InternetProtocol）

URL——统一资源定位系统（UniformResourceLocator）

WEB——全球广域网（WorldWideWeb）

5原则

5.1智能性

5.1.1系统的通讯平台应依托内部网，采用专网，应用有线和无线相结合的通讯方式，实现卡、二维

码、人脸识别在身份认证、消费、移动互联中的三大基本功能。

5.1.2系统的建设应采用智能卡技术、互联网技术、软件技术和安全技术，消除地域的限制。

5.2安全性

5.2.1系统应符合GB/T22239规定的网络安全等级共性化保护要求。

5.2.2系统的建设应保证学校、商户、用户的资金安全。

5.3可实施性

系统的建设应适应不断变化的学校的规模和管理模式，与其他系统进行良好对接，实现一卡通用和

资源共享。

5.4开放性和可扩展性

系统的建设应采用“1个平台+N个应用子系统”的模式。平台建立后，所有公共信息应一次建立，

向所有子系统开放，其他系统不用重复建立。

5.5可维护性

系统的建设应考虑系统维护的简便、快捷和成本，特别是一致性管理和维护。

6系统总体架构

6.1系统架构设计要求

6.1.1系统应采用SAAS架构设计，支持云平台和单客户两种部署模式，支持多客户、多级权限体系

管理。

2

T/HEBQIAXXXX—XXXX

6.1.2系统应包括核心系统和应用系统。

6.1.3系统应支持对称、非对称两种密钥管理体系，保证系统中卡片、通讯、数据存储等环节的安全。

6.1.4系统应支持在线和脱机两种交易模式，以在线交易为主，系统可手动或自动切换到脱机模式。

6.1.5系统应支持M1、CPU、金融IC卡、NFC手机、二维码、人脸等多种支付介质。

6.1.6系统应采取复式会计记账方式，会计科目可自定义，与财务系统实现无缝对接，资产负债表应

清晰地反映系统财务状况。

6.2系统架构

智慧校园一卡通综合管理系统架构可参考图1。

图1智慧校园一卡通综合管理系统架构

6.3物理部署方式

3

T/HEBQIAXXXX—XXXX

6.3.1在校园网中，资金数据传输应采用独立专网进行，普通数据传输应采用虚拟专网进行，保证一

卡通资金数据安全。

6.3.2中心机房与楼栋之间，应采取光纤布线方式。

6.3.3所有系统接入核心系统，应经过防火墙隔离。

6.3.4系统前置服务器与银行系统之间应通过专线连接，保证与银行系统对接安全。

6.3.5应部署在集中场合的消费终端，采用CAN专用网络进行数据传输。

7系统功能要求

7.1核心系统

7.1.1密钥管理

应实现系统内需要的所有证书/密钥的注入、生成、导出、备份、恢复、更新和销毁。

7.1.2证卡管理

应具有管理客户信息的功能，同一主卡可以绑定多张副卡，可查看绑定的副卡。

应支持配置管理中可对人员信息进行脱敏设置，至少包括人员编号、姓名、证件号码、银行

卡号、手机号码、账户地址、邮箱等字段的脱敏设置。

应具有在线更新卡功能，可更新个人编号（即学号），更新卡类型，更新消费次限额，更新

消费次限额、日限额，以及限额更新的验证。

应具有客户登录密码、消费密码重置功能。

应具有对校园卡用户身份、人员类型、账户信息和不同介质状态等卡务管理数据的综合查询

功能。

应支持纯B/S方式交互，包括卡片数据读写操作等，保障系统管理及维护的便捷性和访问的

时效性。

卡务管理操作可以根据对校园卡账户的多种条件组合查询结果批量执行。

应支持师生办理个人业务时，人脸识别自动调取个人信息进行人工或自助业务办理。

应具有编辑客户信息的功能，可编辑卡类型、编辑次消费限额、编辑日消费限额等信息。

0应具有批量发卡的功能，密钥、发卡和打印可批量操作，密钥灌装、发卡及证卡打印操作一

体化，可以同时对不少于两个部门的、多人进行操作。

1应具有自动发卡功能，系统选择数据信息，并下发制卡指令，由发卡机自动发卡。

2应具有批量挂失、销户的功能。

3应具有消费失效期设置功能。

4应具有人脸比对功能，上传人脸照片，用于和手机、消费机等终端设备端取得的人脸照片时

进行基准比对。

7.1.3运营管理

应具有扩展钱包的功能，支持5个以上在线账户、5个以上脱机预授权钱包。

应具有查看“系统允许脱机金额”信息的功能。

应具有设置支付渠道的开启、停用的功能，可编制相应支付渠道参数配置值。

应具有生成二维码的功能。

应具有设置“电子账户参数”参数值的功能。

4

T/HEBQIAXXXX—XXXX

应具有商户综合管理功能，可提供商户账户开立与撤销、支付终端配置、账户管理、口令重

置、交易查询、结算对账、生成导出静态收款二维码等。

水控模式可同时支持用户刷卡、扫码（用水码、三方支付码、校园码）或无卡输密码方式用

水。

应具有收费设置功能，可设置每生每天免费取水额度，超过设置额度后按照正常水价收费。

应具有设置消费限额功能，支持用户灵活设置消费限额和消费时长，防止消费结束后遗忘取

卡造成损失。

0应支持刷卡和账号密码扣费方式。

1应支持预约模式，学生通过手机APP进行浴室预约，只有预约成功才可进行淋浴消费。

7.1.4资金清算

应支持明细查询，使用微信、支付宝、银联等第三方原生付款码支付后，交易明细表中可体

现用户校园身份信息的个人编号、姓名、部门。

消费机脱机时，可形成支付二维码，包括金额、终端编号、时间等信息，用户可使用手机扫

码支付。

商户报表可以按照查询日期，查询每天商户交易明细汇总数据，包括子商户报表，了解商户

每日收益。

应支持多收款账号、多商户管理。

7.1.5数据分析

数据分析平台应基于校园卡数据进行深度挖掘分析，提供多个维度为卡中心、后勤、学生处、财务

处部门服务。

7.1.6数据交换

数据交换平台应部署在系统的前置服务器，负责与校内不同部门、不同通信方式应用的接入。

7.1.7集中监控

集中监控平台应为终端设备提供统一的监视和控制平台，并为采集服务提供人机交互界面。

7.1.8聚合支付

应具有报表功能，一张报表中可体现聚合支付中包含的所有的支付方式的相应报表。

支持当前主流的微服务及J2EE技术架构体系模式。

支持国密SM31)、SM42)等加密签名算法。

应具有通过“聚合支付-明细报表”查看支付明细的功能，支持手机终端通过公众号相应功能

查看消费明细。

应支持脱机交易的风险控制管理，支持系统级、终端级、个人级三级控制。

应具有副卡管理功能，一个用户可拥有一张主卡，同时可以领取多张副卡。

应支持学号、卡类别、密码、消费限额等信息后台更新，消费终端自动登卡处理。

应支持根据设置不同的功能业务流程，记录业务处理过程中的状态，便于异常发生时流程的

断点续传和日志记录。

1)SM3是中华人民共和国政府采用的一种密码散列函数标准。

2)SM4是中华人民共和国政府采用的一种分组密码标准。

5

T/HEBQIAXXXX—XXXX

系统软件应与批量发卡机硬件配合，完成用户卡的批量制作，中间过程无需人为干预，信息

准确，速度快。

0应具有自动化业务处理的功能。

1应支持银联标准二维码、微信及支付宝等原生付款码直接消费支付，具有实名认证功能。

2应支持统一结算平台、对账平台，可在一张报表中统计各种支付渠道的交易、对账情况；支

持不同校区分别设置三方支付资金归集的银行账户。

3可为不同的餐饮承包商或终端设备生成固定收款码。

7.1.9虚拟卡管理

虚拟卡管理应实现虚拟卡电子账户生成、虚拟卡充值、虚拟卡支付、虚拟卡身份识别，以及

相关的数据报表和查询等功能。

7.1.10能力开放平台

应给第三方系统开放核心接口权限，支持为第三方系统开放入口、用户、数据等资源，分配

平台中提供的各大类接口，构建多方协作、资源共同分享的服务平台。

应具有系统管理能力，包括接入者账号权限、配置不同加密方式（支持国密SM4）、配置

签名方式（支持MD5和国密算法SM3）、IP白名单地址（支持多IP绑定）。

开发者（合作者）可在平台查看系统对外开放申请的服务接口及接口描述、申请调用后的审

核状态。经审核后，开发者（合作者）可查看已申请服务接口信息，包含服务接口简介、接入示例以及

相关实例。

应支持管理员在管理页面直接为开发者（合作者）分配接口及权限授权/授禁，可视化操作、

所见即所得。

应支持合作者和管理者两种视图模式，管理者视图首页可展示已注册合作者、合作者调用数

据（今日使用最多接口、今日最活跃接口、接口耗时等）等。

应具有开放平台角色管理服务入口的功能，包含角色列表信息查询、添加角色、角色编辑、

角色删除等角色管理服务。

应具有开放平台操作员管理服务入口，包含操作员列表查询、编辑操作员身份信息、操作员

密码、操作员角色、操作员状态、添加操作员等服务。

应支持管理开放平台内封装的接口管理服务，包含查询接口列表、添加接口、接口编辑服务，

为了便于系统管理员接口管理维护，列表应显示接口名称、接口简介、接口URL、接口入参示例等信

息。

应支持开放平台接口分类管理服务入口，为三方系统对接服务，以满足对接需要，包含查询

接口分类列表，列表可显示接口分类名称、接口分类编码、启用状态等信息，支持添加接口分类、编辑

接口分类服务。

0应具有开放平台接入系统管理服务入口的功能，包含查询接入者信息，可显示接入者账号、

名称、邮箱、ClientID、SecretID、签名方式、签名密钥、加密方式、IP地址、前置接入等信息，便于

接入系统管理，同时可编辑接入系统、添加接入系统等，可编辑接入者邮箱、Token有效期3)、选择签

名方式、选择加密方式、IP地址等综合服务管理。

1应具有为三方接入系统分配接口功能，包含查询接口、添加接口分配，为合作者提供接口

分配，让合作者具有调用接口能力，支持从接口菜单中选择对应的联动接口，完成接口分配。

3)Token的有效期可以根据不同的应用场景和安全需求而有所不同。

6

T/HEBQIAXXXX—XXXX

2应支持接口克隆，管理者使用原有服务接口快速创建同类接口，可控制同样业务接口入参

与出参的字段不同。

7.1.11人脸识别平台

应支持同时接入多种人脸识别算法，支持按算法设置不同的参数组。

应支持接入多种类型的人脸识别终端。

应支持多介质认证管理，可对用户和应用统一认证授权。所有介质关联同一账户，实现统一

管理、权限管控等内容，实现卡、码、脸、密码等多种介质身份统一管理。

应支持从三方系统同步用户照片，支持WEB或HTML5应用自助上传照片，用户照片采集

后根据不同算法提取人脸特征，支持活体检测。

为保证人脸照片的安全性，导出的人脸图片可添加水印。

应支持照片批量上传、批量审核，支持人员黑名单管理和生物特征值管理。

对新生的入学资格及照片应支持联网二次审查支持以人名搜图、以图搜人等查询功能，可上

传人脸照片由系统自动比对搜索，筛选并显示出与其相似度较高的记录照片，以相似度排序展示并关联

通行记录。

应支持用户照片采集后根据不同算法提取人脸特征，可根据业务系统设置自动更新下发人员

特征，支持向各业务系统推送人脸识别记录，支持活体检测，可有效防御纸质照片、电子照片、视频、

面具等作弊方式。

应具有不合格人脸库稽核的功能，可汇总展示当前系统内对应算法下的不合格人脸库，稽核

维度包括：人脸不全、多个人脸、相似人脸照、人脸模糊、亮度不符、人脸照检测失败、提取特征码失

败等。

可展示全校师生的基本信息及其所有使用中的介质，可打开用户详情展示用户及每个介质的详细信息，

包括用户人脸照、虚拟卡、介质变更日志记录（包括对所有师生的人脸照、二维码、实体卡的所有的操

作）。

7.1.12移动服务管理平台

移动服务管理平台功能模块包括用户管理、角色管理、公众号功能管理、公众号角色类型授权管理、

微信消息模板管理、手机号白名单授权管理、学生管理、充值管理、通告管理、白名单/黑名单访问管

理、数据分析服务、移动商户管理、移动用户管理等。

7.2应用系统

7.2.1消费管理

应支持人员信息脱敏、消费数据统计查询、终端信息查询、终端内已下发的有效人脸信息数

量查询、交易记录上传记录查询。

应具有消费模式（码、卡、脸）、餐别定额设置。

应支持本地退款（可选择刷卡、扫码、人脸识别等退款认证方式）。

应支持设备音量调节、屏幕亮度调节、商户静态码展示。

应具有校园实体卡刷卡支付、校园二维码扫码支付、校内人脸支付等支付功能。

消费机正常工况下应采取联机工作模式，交易数据实时上传至系统；网络故障时支持脱机工

作模式，恢复联机后交易数据及时上传至系统。

应支持可选以太网、4G/5G、WIFI等多种通信方式，支持以太网和4G/5G、WIFI自动切换模

式，优先使用以太网，检测到以太网连接中断即自动切换至4G/5G、WIFI连接。

7

T/HEBQIAXXXX—XXXX

应支持限制单个支付终端的可消费人员身份类型，可设置单个校园卡账户的单次、单日支付

额度限制，支持按额度进行小额免密支付、验证交易密码支付和禁止支付。

应支持数字人民币、银联码、各个银行码、微信、支付宝原生码聚合支付。

0应具有后备电池续航功能，标称值如下：

a)电池容量：5500mAh；

b)续航时间：3h～5h。

1通过2个RJ45、1个RS232和2个USB2.0接口，可进行通信。

2设备通讯方式支持TCP/IP有线通讯，支持蓝牙、WiFi、4G、5G等无线通讯。

7.2.2圈存管理

应具有银行卡的注册、签约、解约、换卡等功能，并支持对账、转账查询等。

应支持网银、微信、支付宝、云闪付转款功能，支持脱机钱包转款、圈存补领款功能。

应支持补助账户向电子钱包转款。

应具有自助圈存、挂失、改密、查询等功能。

应具有自助转账、自动转账、签约解约、对账、网银转账提供通信转发的功能。

7.2.3缴费管理

应支持管理员审批，支持账单缴费和自助缴费两种模式。

应支持大型数据库、支持Linux4)或Unix5)、WINDOWS、AIX6)等操作系统。

应支持跨平台的部署。同时可兼容校内现有用户体系（如统一身份认证系统）且提供独立的

用户体系（校外用户）的管理。

应支持退款管理，用户发起退款申请流程，管理员审批后生效，支持原路退款。

应具有票据管理的功能，可设置开票权限，收费部门和财务部门可根据操作权限，打印相应

收费项目的票据，支持不同格式的票据，可提供票据格式设计。

应支持导入缴费名单，账单推送至用户手机端，包括网费充值、电费充值、自助缴费、图书

馆欠缴费、党费、校友捐赠等生活缴费服务。

应支持包括查询缴费收费模型、名单导入类模型、通用类模型、报名费类模型、会议费类模

型、场景收费类模型。

应支持多种支付渠道，可选网银、微信、支付宝、云闪付、电子校园卡等方式缴费。

7.2.4水控管理

应支持DC12V～24V宽电压输入方式。

应支持刷卡消费、扫码消费、按键验证联机消费。

应支持防水键盘，包括数字键+功能键（标称按键寿命80万次～100万次）。

应支持分辨率128×64的2英寸液晶屏，可显示二维码等。

应支持在线升级。

应支持CAN或4G通信方式。

4)Linux，LinuxIsNotUniX的缩写，一般指GNU/Linux，是一套免费使用和自由传播的类Unix操作系统，是一

个遵循POSIX的多用户、多任务、支持多线程和多CPU的操作系统。

5)UNIX系统是一个分时系统。

6)AIX是IBM基于AT&TUnixSystemV开发的一套类UNIX操作系统，运行在IBM专有的Power系列芯片设计

的小型机硬件系统之上。

8

T/HEBQIAXXXX—XXXX

7.2.5门禁管理

应支持部门授权、组织机构授权、批量授权、导入授权等功能。

应具有授权管理的功能，系统自动生成授权名单给相应门禁。

应支持多种终端集成管理，集中授权、统一管控，包括门禁终端、通道闸机等。

应支持实名认证绑定下的电子校园卡二维码实现门禁、通道、考勤等识别功能。

应支持常开模式、首卡开门、多卡开门、多门互锁、反潜回等。

以下情况应具有报警功能：

a)对于没有授权的卡、人脸、二维码，连续5次非法识别，系统记录日志并报警；

b)系统对强制开门的情况进行记录并报警；

c)控制器电压低于正常值的85%，系统进行记录并报警。

应具有实时监控的功能，支持实时监控通行人员信息，包括姓名、学号、照片等。

应具有导入预约访客信息的功能，当被访人完成审批操作后，该访客将会接收到预约提醒推

送，系统提供PC端和移动端预约功能。访客审批之后，系统可将访客权限自动下发至人脸识别平板和

手持机中，支持在人脸通道上刷卡、刷脸、扫码（访客码）或手持机上刷卡、刷脸、扫码（访客码）刷

身份证（手持机）进行身份核验。

7.2.6请假管理

应具有请假信息管理的功能，请假通过审批后，同步信息给所有门禁。

应具有请假查询功能，学生获准离校后，消息直接反馈班主任及学生家长，同时校内可通过

电子班牌或手机APP进行展示与查看，并关联宿舍归寝结果统计；发送消息内容包括请假时长、离校

时间、请假事由、审批人及其联系方式。

应具有信息推送的功能，请假到期以后，对于没有按时返校的学生，系统自动将请假未归信

息推送给辅导员（家长），并提醒学生返校。

7.2.7宿舍管理

应具有管理值班员的功能，可查看、添加、删除值班员信息和排班等。

应具有添加房间类型、房间类型管理、添加楼房地理位置、楼房地理位置管理、楼房登记、

楼房信息、新增楼房单元、楼房单元管理、添加房间信息、房间基本信息、房态图查看、添加床位信息、

房间床位信息、办理入住、入住信息、住宿信息导入、调房管理、迁出信息等功能。

应具有入住管理功能，可登记入住学生详细信息，以及支持批量导入新生入住信息操作。

应具有调宿管理功能，可对调宿学生调宿前与调宿后信息进行管理。

应具有退宿管理的功能，可对退宿学生信息与退宿记录进行统一管理。

应具有迁出管理的功能，可对迁出学生信息与迁出记录进行统一管理。

应支持对学校的基础信息管理，包括但不限于校历信息、组织机构信息、专业信息、班级信

息、教职工信息、宿舍资源信息、学生信息。

应支持班/年级管理，对学生班/年级信息进行统一管理。

应支持建立具备层级关系的房间住宿资源，可建立包括但不限于以下层级：校区、园区、楼

栋、单元、层、房间、床位。

0应支持为楼栋设置住宿学生性别；支持设置房间用途、类型、床位数、标签、面积；支持设

置房间示意图；支持零星和批量设置床位标签；支持相关数据的导出。

1应支持按照楼栋权限（包括但不限于系统管理员、校区管理员、园区管理员、楼栋管理员、

楼层管理员）和院系权限（包括但不限于学院书记、学工处、辅导员）灵活配置相应的管理角色。

9

T/HEBQIAXXXX—XXXX

2应支持设置公寓预分方案，方案包括但不限于：按学年、是否允许学院二次预分、是否允许

学生自选宿舍、启用日期、资源回收日期，以及预分的学生范围。

3应支持假期留校，可设定假期留校计划，设定假期留校申请或登记的起止时间。

4应支持按照校区、园区、楼栋等条件进行查询，展示校区、园区的区域概况，包括但不限于：

园区数、楼栋数、房间数、床位总数、空床位数、入住人数。

5应支持入住、调宿、退缩功能，包括但不限于床位对调、房间对调、批量调宿、毕业生批量

退宿。

6应支持非学生人员的临时住宿安排。

7应支持卫生检查和纪律检查，可分别设置卫生和纪律检查项，可设置检查频次。

8应支持学生预警提醒。可设置预警等级和预警规则，根据学生每日考勤情况和在寝/离寝时

长自动生成预警名单，并推送给管理员。

9应支持统计预警学生数量，对晚归、夜不归宿等异常行为进行展示。

0应支持混寝房间统计。对于同一个宿舍住的不同学院的学生，支持统计混合宿舍中的各个学

院人数。

1应具有学生信息管理的功能，可对学校学生信息进行统一管理，实现对学生信息的增加、删

除、编辑与实时同步操作。

2应具有学生信息导入的功能，可对学生信息批量导入操作。

3应支持学生通过手机自己选择宿舍、床位。

4可查看宿舍区域内入住人员的归宿状态、入住区域等信息。

5应支持为不同的学生群体设置不同的考勤规则，支持设置每日晚归、夜不归宿和晚出时间，

可对周一到周日7天的考勤时间设置进行细化.可提供考勤报表。

6应具有评比管理的功能，支持评比信息管理、违章类型管理、违章信息管理、评比规则管理、

检查组织管理、评比等级管理、卫生信息管理。

7应具有自动断电的功能，即最后一名学生离开宿舍，宿舍可自动断电；第一名学生回到宿舍，

宿舍应自动送电。

7.2.8门锁管理

应具有无线充电功能，支持无线通信。

用户可查看自己权限下的门锁状态（电量、开关锁状态、联机状态、维修状态）、可修改门

锁名称以及是否常用、可设置和修改密码、可对门锁修改报修申请、可对门锁进行远程开关、可查看个

人开门记录。

应支持刷卡、密码、指纹、扫码、机械钥匙等开门方式。

应内置密码芯片，当门锁处于脱网状态时，仍可通过手机端申请的动态密码验证开门。

7.2.9报修管理

系统应包含后台管理端及手机端两部分，手机端分别支持管理员、用户、维修工三类人员登

录，且不同类型人员登录展示不同功能。

应支持报修单分配管理（支持智能调度算法，可实现自动派单功能）。

应支持师生选填区域、位置、描述、图片、联系人等信息上报维修。

应具有工种设置功能。

应具有工单管理功能，管理员可管理本区域下的所有单子，管理员和维修工可转单。

维修信息上报之后会根据报修区域查找该区域下的所有维修工，分发微信消息通知进行抢单。

应支持管理员驳回工单。

10

T/HEBQIAXXXX—XXXX

应具有服务评价维度功能设置，包括服务态度、服务质量、服务时效等。

根据管理区域统计报修量，管理员可查看区域下的所有工单信息及状态（未处理单、完成单、

待审批和已审批）。

0应支持超时催促设置，可设置超时时长，以分钟为单位。

1应支持对维修工信息进行维护，可设置维修工的部门、职位、手机端账号、密码等信息。

2应支持维修工绩效评定，对维修工维修项目可按星级进行评定。

3应支持预约报修功能，维修工可按预约时间上门维修。

4应具有值班管理功能，在周末或节假日时，报修的任务会自动分配给在值班的维修工。

5管理端应支持对工单挂起申请、工单转单申请、超时工单申请等操作进行审批，并可以展示

维修工的工单详情信息。

6应支持数据统计功能，包含报修单汇总、维修工工单详情、维修响应时间统计、报修项目汇

总、日报修单统计等。

7维修工移动端应支持展示该维修工未处理的工单、完成工单、挂起工单和转单工单，维修工

可对个人工单进行完成、挂起、转单等操作。

8报修项目管理应支持故障标签定义，可按照项目分类定义故障标签，用户在手机端可通过选

择故障标签进行报修。

9维修工在受理单件后应支持在线群聊，报修人可及时在线与维修工线上沟通。

0维修完工，应支持拍照、输入物料和收费金额，支持维修件的暂停、驳回维修、打回重派等

操作，支持手机端操作。

1应具有物料收费功能，支持维修件收费管理，包括现场收费，记录费用后同意收费等方式。

2应具有逐级预警功能，可查看未处理、已处理预警件列表。根据预警类型“超时未接单”“超

时未到现场”“超时未完工”，预警级别“班长”“科长”“分管处长”“分管校长”，进行排列组合

式查看。

3应具有调度策略功能，支持“自动调度策略”的设定。按维修部门、维修工、维修区域、维

修事项、执行周期、工作模式（工作日、节假日）、自动派单时间等，自由组合维修调度策略；支持维

修工在不同部门之间的借调。

4应具有统计功能，手机端可查看部门工作量、个人工作量、校区工作量、楼栋工作量、维修

分类、维修事项、个人返修量，维修用料的统计。

5应具有数据分析功能，可按小时、按日来分析报修量。支持以年月周末单位、按项目、按区

域、按来源、按评价来分析报修情况；支持手机端分析操作。

6应支持自动化配置设定，包括一键开启自动审核、自动调度派工、自动受理、确认到达现场

等。

7应具有地图实时显示楼栋维修状态功能，点击正在维修的楼栋可以查询楼栋报修状况，包括

维修事项分布周报修量趋势、日报修量时间分布，以及维修工当前统计及工作状态等。

7.2.10公众号

应具有订餐功能，可选择餐别、食堂、套餐等。

应具有访客预约功能，访客通过公众号的“访客预约”功能进行预约，审批通过后，预约审

批结果推送消息给预约的访客，可自动生成访客二维码，下发人脸识别信息，同步授权信息给所有门禁

系统。

应具有场馆类型管理的功能，场馆类型包括图书馆、浴室、研修间、体育馆、艺术馆、琴房

等。

11

T/HEBQIAXXXX—XXXX

应具有报修管理功能，管理员或维修工可在公众号进行转单，同时推送消息给被转单人，被

转单人在公众号的消息通知里进行接单，若被转单人不接单，管理员可再转单。

应具有浴室预约功能，支持预约、取消、查询、预约扣费等。

应具有请假功能，请假通过审批后，推送消息给学生和审批节点老师，请假学生和审批老师

接收推送的消息。

应具有宿舍管理功能。

应具有实名认证的功能，使用微信、支付宝、银行、银联二维码支付前必须通过实名认证。

应具有虚拟卡管理功能。

0应具有缴费管理功能。

1应具有权鉴管理功能。

7.3系统运维管理

7.3.1应支持系统检测、设备监控、业务监控、安全检测、性能检测和拓扑图展示。

7.3.2应实现提供告警信息汇总报告、运维稽核统计报告、运维监控周期报告和告警处理汇总报告等

功能。

7.3.3应支持按时间段查看各数据库和服务器的运行状态。

7.3.4应具有移动端使用量分析的功能。

7.3.5应实现大屏显示考勤服务、采集服务、门禁服务、统计服务使用次数的功能。

7.3.6应支持按时间段查询终端、中间件、服务器、数据库告警信息。

7.3.7应支持以图形可视化方式展示服务器、数据库、程序、设备运行状态的汇总信息。

7.3.8应实现提供异常交易、异常账户、系统账目的报表的功能。

7.3.9应具有弱密码检测的功能。

7.3.10应具有查看操作日志的功能。

7.3.11应具有查看拓扑图中节点运行状态信息的功能。

7.3.12应具有增加、修改、删除告警等级的功能。

7.3.13应具有增加、修改、删除、查询、设置告警规则的功能。

7.3.14应具有增加、修改、删除、查询、设置消费类终端和水控器的告警阈值的功能。

7.3.15应具有增加、修改、删除、刷新联系人组的功能。

7.3.16应具有管理发送通知的功能。

7.3.17应支持规则引擎，可自定义数据转发规则，包括设备事件触发、运行状态上传、业务系统命令

下发等。

7.3.18应具有对运维监控模块体检基本信息、权限、联系人组及通知信息的设置功能。

7.3.19应支持拖拽、缩放、逐级展开方式展示系统拓扑图，支持实时查看节点运行状态信息。

7.3.20应支持集群部署和负载均衡。

7.3.21应支持自动、批量触发终端设备的应用程序和固件程序的自动升级。

7.3.22应兼容主流的物联设备，具有三方硬件接入前的沙箱调试服务。

7.3.23支持多种第三方数据联动标准接口，包括HTTP、Redis7)、MQ、MongoDB8)等。

7.3.24可配置地理位置、运维单位、运维人员、拓扑配置等；可查看产品分类、产品型号、事件定义、

事件等级等；可配置支付终端、控水终端、门禁终端等；可操作事件规则、告警规则、监控规则等。

7)Redis是一个使用ANSIC编写的、开源的、支持网络的、基于内存的、可选持久化的键值对存储系统。

8)MongoDB是一个基于分布式文件存储的数据库.

12

T/HEBQIAXXXX—XXXX

7.3.25应对一卡通（消费类、身份识别类）终端机具、服务器（数据库服务器、业务服务器）、网络

信息点、部署的软件服务进行有效的状态监控及预警。支持将这些运行状态集中投放在大屏设备上，管

理人员可以直观获悉一卡通整体业务运行状况。

7.3.26应提供运维服务的系统设置服务功能，含操作员管理、角色管理、告警类别管理服务、发送类

型管理、参数管理等服务。

7.3.27大屏显示内容可以按照时间段查询和统计设备运行情况，数据回溯，可以同比历史对比，图表

化，可单独拉出一个屏幕，管理员能够更快地进行定位故障。

7.3.28支持设定推送管理员或管理员组，支持短信、邮件或根据要求与三方消息系统对接，及时发送

消息提醒来保障运维工作的时效性；支持对维修事项进行登记，系统中所产生的各类运维记录将作为对

维护人员的考核依据。

8系统性能要求

8.1系统容量

表1系统容量

指标项目技术要求

系统账户容量≥20万户

持卡人卡片类型32种

注：系统账户容量可扩至100万户。

8.2系统运行处理能力

表2系统运行处理能力

指标项目技术要求

实时交易处理能力≥1万笔/分

转账金额生效时间实时

账户信息生效时间（包括挂失/解挂）<30s

8.3系统运行环境

表3系统运行环境

指标项目技术要求

中心数据库兼容ORACLE11g及以上版本以及国产数据库达梦数据

数据安全带MAC校验，双机热备，RAID5

中心主机操作系统WindowsServer2008或更高版本

密钥控制体系准金融级/金融级加密

卡片密钥体系一应用一密/一区一密

加密签名算法3DES/HASH/RSA

注1：中心主机操作系统可双机热备。

注2：卡片密钥体系可选非对称体系。

13

T/HEBQIAXXXX—XXXX

8.4系统资金清算

表4系统资金清算

指标项目技术要求