纯内网部署:指挥、刷卡、闸机都可按需本地化
纯内网是部署方式,不是某一个版本的专属能力;指挥版、刷卡版和闸机版都可以按学校网络、安全和设备条件评估纯内网部署。
纯内网优先解决数据安全和现场稳定性
部分学校不希望放学主流程依赖外部网络,或希望把指挥操作、老师刷卡、学生离校、闸机通行、校内显示和后台日志留在校内环境中。纯内网是部署方式,可以和指挥版、刷卡版、闸机版组合。
纯内网版|本地化部署方案在统一平台中的位置
方案组成
统一平台 + 校内网络部署 + 已选终端与模块 + 本地运维边界
共同底座
学校组织、角色权限、放学任务、四态同步、通知分发和操作记录由青鸽放学协同平台统一管理。
组合边界
纯内网是部署方式,不是独立业务系统;公众号、短信及其他外部通知端需要结合学校网络边界单独确认。
指挥、刷卡、闸机都可以进入纯内网放学流程
老师刷卡
刷一下放学、刷两下留堂、刷三下完成,具体规则可按学校配置。
学生卡与 UHF-RFID
支持学生卡及 UHF-RFID 设备接入,学生刷卡可形成个人出校事件,用于离校记录、通知和后续查询。
平板指挥
指挥版也可按学校条件部署在校内环境,支持单班、多班、年级和全校操作。
闸机联动
完成设备接口与身份事件联调后,可在纯内网条件下记录学生出校、入校和等待区离开事件。
纯内网运行
适合校内网络闭环、本地化部署和数据安全要求较高的学校。
大屏与播报
校内大屏和语音播报可按批次、范围和模板同步更新。
公办学校评估纯内网放学系统时看什么?
| 评估项 | 建议关注 | 对应能力 |
|---|---|---|
| 网络条件 | 是否需要校内闭环或私有化 | 纯内网/本地化部署 |
| 版本组合 | 需要指挥、刷卡、闸机中的哪些能力 | 按现场组合部署 |
| 刷卡规则 | 老师和学生刷卡动作是否可配置 | 刷卡规则配置 |
| 权限范围 | 谁能操作哪些班级或年级 | 身份与权限校验 |
| 日志要求 | 是否能查前后状态和失败原因 | 黑匣子日志 |
| 运维要求 | 是否便于长期稳定使用 | 后台查询与应急处理 |
三类能力都可以按纯内网方式组合
| 部署组合 | 适合学校 | 纯内网下保留的能力 |
|---|---|---|
| 指挥版 + 纯内网 | 大型小学、多校门学校、集团校 | 平板指挥、大屏状态、批次规则、语音播报、后台日志 |
| 刷卡版 + 纯内网 | 已有校牌或刷卡设备的学校 | 老师刷卡、学生卡/UHF-RFID、回刷记录、校内闭环、后台查询 |
| 闸机版 + 纯内网 | 封闭式校园、已有闸机学校 | 人脸/刷卡出校、等待区离开、通行事件、异常追溯 |
| 组合部署 | 既要调度又要身份核验的学校 | 指挥、刷卡、闸机、大屏、播报和日志按现场组合 |
哪些学校更适合优先看纯内网部署?
适合
公办学校、重视数据安全的学校、已有校内设备和网络条件的学校、希望主要流程在校内闭环运行的学校。
不一定适合
只需要轻量家长通知、没有校内设备、预算和运维条件暂不支持本地化的学校,可以先从小程序或轻量方案开始。
需要评估
如果既要纯内网,又要公众号或短信通知家长,需要单独确认通知链路、权益配置和学校网络边界。
咨询纯内网方案前,建议先准备这些信息
纯内网方案进入实施前,需要先确认这些边界
| 检查项 | 需要学校确认 | 影响 |
|---|---|---|
| 网络边界 | 系统是否只在校内访问,是否允许外部通知链路 | 决定通知、后台和运维方式 |
| 设备接入 | 校牌、刷卡器、闸机、大屏、广播是否已有接口 | 决定实施周期和联调成本 |
| 数据准备 | 班级、学生、老师、接送人、权限范围是否完整 | 决定试运行质量 |
| 运维角色 | 谁负责后台配置、异常处理和日志查询 | 决定系统能否长期稳定使用 |
常见问题
纯内网是否等于不能通知家长?
不等于。纯内网通常指校内主流程和核心数据在校内运行;若还需要公众号、短信等外部通知,应单独设计受控出口、数据字段、失败降级和安全责任,并由学校确认网络边界。
刷卡规则能否按学校调整?
可以在产品支持范围内配置,例如操作身份、适用班级、有效时段和对应状态。具体刷卡次数、撤销与异常处理规则应先用学校真实流程验证,并写入实施方案。
指挥版和闸机版能否纯内网部署?
两者都可以按学校条件评估纯内网部署。指挥版侧重平板调度、大屏和播报,闸机版侧重身份与通行事件;能否落地仍取决于服务器、网络、设备接口、通知出口和运维条件。
纯内网部署前最需要确认什么?
最先确认网络边界、已有设备、是否需要家长外部通知、后台查询要求和学校运维条件。
纯内网部署是否是一套独立系统?
不是。纯内网部署是青鸽放学协同平台面向特定学校场景形成的常用方案入口,与其他终端和模块共享学校、任务、权限、状态、通知与审计数据。