APP 推送：半夜那条通知，谁会被吵醒

核心答案

告警推送常见的设计错误是“广播”：机构负责人、值班员、护理主管全推一遍。半夜三点，所有人被吵醒，所有人都以为别人会处理。正确做法是分级路由：第一顺位推当班人，超时未确认再推负责人，再超时推中心。每一级都要能看到“上一条推给了谁”。

01中心与机构，责任线要画在哪

建中心最容易埋的坑，是责任界面模糊。设备装上了、平台通了，真出事时“谁先动”说不清，这套系统就等于没有。

环节	机构端责任	县级中心责任
初次确认	接到告警后在约定时限内到现场核实	看平台、打电话催办、记录时间
处置	现场处置、拍照上传	判断是否需要外部救援、是否升级
升级	无力处置时立即上报	逐级上报民政与消防救援机构
归档	补充整改记录	销号、纳入机构画像

这张表要在合同里写死，尤其是“机构未按时确认，中心怎么办”这一行。合理的设计是：超时未确认自动升级到机构负责人，再超时升级到县级中心，中心有权直接联系 119——而不是中心只能看着屏幕上的红点。

一个常见误解：以为中心是“监管机构”，可以对机构下指令。实际上中心多数是民政委托的服务方，没有执法权。它的手段只有三个：催办、上报、记录。把这三个做扎实，比给它“权力”更有效。

02告警时延：三段路，各花多久

“端到端时延”这个词在方案里经常出现，但它其实由三段组成，每段的瓶颈完全不同。

段	从 → 到	瓶颈在哪
第一段	消防主机火警 → 传输装置采集到	主机有没有标准接口、轮询周期设多长
第二段	传输装置 → 县级平台入库	4G 信号、平台并发、鉴权与入库排队
第三段	平台入库 → 责任人手机响	推送通道（短信 / APP / 电话）、运营商网关

三段里最容易失控的是第一段。老主机没有标准串口，只能靠开关量或外加探头，采集延迟取决于轮询周期；有的方案为了降低误报，把确认时间设成 30 秒以上，端到端时延立刻被拉长。这一段不谈清楚，只报一个“平均 3 秒”是没有意义的。

所以应答时延类问题时，正确写法是三段分列 + 测试条件：网络条件（有线 / 4G / 弱信号）、接入设备数量、并发告警数、测试次数。同一套系统在 5 家机构和 50 家机构下，第二段的数字会差一个量级。

评审怎么判：看的是三个数是否自洽——最短 ≤ 平均 ≤ 最长，且最长值有解释（比如“弱信号下 12 秒”）。只给一个数的应答，通常会被要求补充说明。

03本地服务：滇西这类地方，路程就是指标

县域项目谈服务能力，不谈“7×24 响应”这种口号，谈三件事：谁在当地、多久能到、能做几组。

能力项	要给出什么
本地服务主体	合作服务商全称、注册地、成立时间、社保人数、原厂授权书
到场时效	勘测响应、远程响应、现场到场分别承诺；县城与乡镇分别写最长时限
技术团队	常驻省内工程师人数与所在地；是否有注册消防工程师
实施经验	近三年省内同类项目数量、单机构平均工期、单日可并行施工组数
质保与备件	质保年限、备件库所在地、故障件更换时限、续保费用标准

这几项里最实的是“单日可并行施工组数”。它直接决定工期：5 家机构、每组一天装一家，一组要 5 天，三组并行两天收工。写“工期 30 天”但只有一组人的，属于自我暴露。

另一个现实约束是施工窗口。西南山区 11 月到次年 4 月多雨雾，乡镇道路条件差，加上年底考核节点，实际可用工期比合同期短得多。方案里应该把“雨季备选方案”“设备提前到场”“分批验收”写进去，而不是只写总天数。

到场时限要分两级写：县城 2 小时、乡镇 4 小时是常见承诺，但“乡镇”里还有更远的村点。把最远的那个机构单独列出来承诺，比笼统写“全县 4 小时”可信。

04自查清单：12 项

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

0 / 12

05常见问题

一个县一般要接入多少家机构？

试点通常选正常运营的机构全覆盖，5 家到十几家都常见。规模直接影响架构：10 家以内一套标准部署就够，超过 30 家要考虑分片区值守和账号权限分级。先定规模，再定功能。

平台一定要按团体标准做吗？

T/QDAS 146-2025 是养老机构智慧消防管理数字化平台的建设技术规范，属于团体标准。项目文件把它列为技术依据时，平台功能就要逐条对照并给出实现方式与界面截图；引用时写全标准号与年份，不要写成国家标准。

断网本身要不要报警？

要，而且必须推送到人。很多人把设备离线当状态、不当事件，结果设备停了三天没人发现。离线应该产生一条独立告警，走和火警类似的通知链路，只是级别可以低一些。

AI 视频里哪几个算法比较靠谱？

目标越规整、场景越固定越靠谱。消控室脱岗睡岗、通道占用、电动自行车违规充电这三类装在固定机位盯固定区域，效果稳定；烟火识别受光照和蒸汽影响；跌倒、夜间离床涉及人体姿态，误报率高，只能当辅助线索。

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

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

水压水位多久上报一次？

这两种都是缓变量，5 分钟一次足够。设成 10 秒一次，电池撑不住、流量也浪费。合理做法是平时低频、异常时自动转高频，并在本地可配阈值。

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

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

本地服务能力怎么证明？

四样东西：本地服务主体的营业执照与社保人数、原厂授权书、常驻省内工程师名单与所在地、近三年省内同类项目的合同关键页与验收证明。没有证明的业绩一般不计入评审。

适用范围与本页说明

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

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

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