县域平台：一张图要能下钻到房间

核心答案

县域消防平台的大屏，常见问题是只有第一层——全县机构点位分布。真正有用的是能下钻：点县看机构、点机构看楼层、点楼层看房间和点位状态。下钻层级做不出来，往往不是前端问题，是数据模型里没有“机构—建筑—楼层—房间—点位”这条层级链。

01接口：三张网，三种口径

县级中心的数据要往外送，方向有三个，口径完全不同。

对接对象	常用方式	难点
消防救援机构监管平台	RESTful API、GB/T 26875.3 或地方消防物联网标准	字段范围与推送频率由对方定，要先拿到接口文档
民政部门的统计口径	报表导出或接口	民政看的是“机构、床位、住养人数、隐患整改率”，不是设备在线率
全国养老服务信息系统	预留接口	接口未开放时要说明预留方式与工作量

三张网里，第一张是硬要求，第二张是软要求，第三张是预留。很多方案把三张写成一样，评审时一问“民政的报表按什么口径统计”就答不上来。

推送模式上，实时推送和 T+1 批量各有用途：火警必须实时，统计类可以批量。要做的是两种都支持，并按数据类型自动选择。只有一种的系统，要么浪费带宽，要么报表不及时。

还有两个容易被忽略的条款：推送失败后的重传策略与每日对账机制。没有对账，丢了数据双方都不知道；有了对账，才能算出真实的丢包率。

数据权属要写在合同里：告警记录、机构台账、视频影像归甲方所有；供应商退出时按约定格式完整导出，并给出迁移周期。含糊其辞的，验收时会被卡。

02县级中心，是一个县一个，不是一院一个

县级养老机构消防安全管理中心的形态，容易被想成“每家大一点的养老院装一套”。不是。它是县级建一个中心，把全县正常运营的养老机构连进来——中心在县里，机构端只放感知设备和传输设备。

层级	放什么	谁值守
县级中心	平台、大屏、值守席位、值班电话	民政部门委托的值守方（自建或购买服务）
机构端	传输装置、独立烟感、水压水位、AI 摄像机、门磁	机构自己的值班人员
监管端	数据接口，不落地设备	消防救援机构、民政上级部门

这个结构决定了三件事：平台只需要一套（不是每家机构一套）；告警要跨过两层人（机构值班室 → 县级中心 → 责任人）；网络是薄弱环节（机构多在乡镇，宽带质量参差）。后面所有技术选择，都是被这三件事推出来的。

先定规模再定功能。一个县 5 家机构和 40 家机构，平台架构完全不同：前者一套标准 SaaS 就够，后者必须考虑分片区、分批值守、账号权限树。规模没定就比功能清单，比出来的结论没有意义。

03工单闭环：四个节点，一个都不能省

“中心预警—机构确认—处置反馈—销号归档”，这四步听起来像流程描述，实际上是四个时间戳。系统里没有这四个时间戳，这条流程就是纸上的。

节点	系统要记什么	为什么必须记
预警产生	告警时间、来源设备、原始值	后面所有时长的起点
机构确认	确认人、确认时间、是否属实	算“响应时长”；区分误报与真实
处置反馈	处置人、措施、现场照片	验收时要看凭证，不能只有文字
销号归档	销号人、销号时间、归档编号	形成可追溯的闭环

四个节点之外，还有一条最容易漏：升级规则要可配置。不同类型、不同时段、不同机构的超时阈值不该一样——白天 15 分钟、夜间 5 分钟是常见设置；失能老人多的机构阈值应该更短。写死一个统一值的系统，用半年就会被要求改。

处置凭证只收文字等于没收。现场照片要带时间和定位，整改记录要能关联到具体隐患条目。验收时抽查十条工单，如果三条以上只有一句“已处理”，这套闭环就是不合格的。

04传输装置：GB 26875 与那五个品牌

用户信息传输装置是整套系统的咽喉——它不通，后面所有功能都是零。选型看四件事。

一、标准与认证

要符合 GB 26875 系列（城市消防远程监控系统）的要求，并提供强制性产品认证（CCCF）证书或型式检验报告编号。这一条是硬门槛：没有证书的，在评审时直接判不满足，不给解释机会。

二、接口够不够

至少要有 RS232、RS485、开关量、网络接口 四种。听起来是冗余，实际上四种对应四类现场：新主机走 RS232/485 读协议；老主机没串口，只能取开关量；有的主机只给网络口。少一种，就有一类机构接不进来。

三、兼容几个品牌

常见要求是“不少于 5 家”，实际要报出品牌名 + 协议名。这一栏不能写“兼容主流品牌”——养老机构的存量主机品牌五花八门，海湾、利达、北大青鸟、泰和安、泛海三江这类是常见的一批，但每个县的实际构成都不同，接入前必须现场确认型号与固件版本。

四、链路与备电

上行要 4G 与以太网双链路，一条断了走另一条；备用电源续航要写具体小时数；工作温度与防护等级要写具体值——装在楼梯间、配电间还是室外箱，选型完全不同。

一体机还是分体：传输装置与 DTU 一体集成省事，但 4G 模块坏了要整机返修；分体式坏哪个换哪个，代价是现场多一个盒子、多一组接线。机构分散、维修路程远的县，建议分体。

05自查清单：12 项

逐条打勾。勾选状态保存在本机浏览器，下次打开接着用；本页不上传任何数据。

0 / 12

06常见问题

县级中心和机构的智慧消防系统是什么关系？

两层。县级中心是全县一套平台，负责汇聚、值守、督办、统计；机构端只装感知设备和传输设备，不重复建平台。机构如果已有火灾报警主机，通过传输装置接进来，不拆不改。

断网时告警会丢吗？

要看设备有没有本地缓存、缓存多少条、复网后怎么补。完整答案是四件事：缓存条数、补传顺序（按时间还是按优先级）、平台侧完整性校验方式、以及在什么情形下仍会丢（缓存写满、断电、设备被拆）。写“绝不丢失”反而不可信。

算法放摄像机里还是放平台？

摄像机内置省带宽、响应快，但升级要逐台刷；平台侧解析能利旧摄像机，但占服务器算力、传视频费流量；边缘盒子介于两者之间。机构少时前两种都行，机构多了要算总带宽和总存储账。

用户信息传输装置要看什么？

四件事：是否符合 GB 26875 系列并有 CCCF 证书或型式检验报告编号；接口是否齐（RS232、RS485、开关量、网络）；兼容主机品牌是否报得出品牌名与协议名；上行是否 4G 与以太网双链路，备电续航多久。

GB/T 28181 要写到什么程度？

要写具体版本和 ONVIF 的 Profile。只写“支持 GB28181”不写版本，联调时经常对不上。存储周期也要写死是 30 天还是 90 天，容量按路数×码率×天数算，不要按“约”估。

推送实时和批量要都支持吗？

要。火警必须实时，统计类可以 T+1 批量。只有一种的系统，要么浪费带宽，要么报表不及时。配套还要有推送失败重传策略和每日对账机制，否则丢包率算不出来。

项目数据归谁？

归甲方。告警记录、机构台账、视频影像都属于甲方数据；供应商退出或合同终止时要按约定格式完整导出并给迁移周期，不能有“数据回流原厂”或“用于其他项目”的条款。这条要写进合同。

试点验收最容易被卡在哪？

三处：接入机构数或点位数与计划不符；工单只有文字没有凭证；断网测试时离线告警没产生或复网数据没补齐。这三条都是现场能测的，提前自测一遍就能过。

适用范围与本页说明

本页面向平台需求编写与验收指标设定。"告警时延、响应时长、处置率、整改率"这些指标的分子分母要在需求阶段一并定义，否则报表无法用于考核；涉及与消防救援机构、民政部门的数据对接，字段范围与推送频率需以对方接口文档为准。

平台上线前先跑通一条完整链路：告警产生→推送→确认→处置→销号，五个时间点都要能取到并导出。

本页内容随政策与标准更新可能调整，具体条款请以正式文本为准；涉及具体项目的建设内容、接入范围与验收要求，请以属地主管部门口径与合同约定为准。