SOS 按钮和烟感，响应逻辑不一样

核心答案

SOS 呼叫和火灾告警在系统里经常被混在一个队列里，其实优先级逻辑不同：SOS 是“有人需要帮助”，要的是就近响应；火警是“这栋楼有危险”，要的是立即疏散并上报。混在一起会出现两种错——火警被当成求助慢慢处理，或者老人误按 SOS 引发全场疏散。队列要分开，升级路径也要分开。

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

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

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

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

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

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

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

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

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

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

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

03断网之后：缓存、补传、和对不上的账

乡镇养老机构的宽带和 4G 都不稳，断网是常态不是异常。所以“断网了怎么办”不是加分项，是必答题。

完整的答案要包含四件事：

断网时本地存多少条——写具体条数，不是“可缓存大量数据”。条数要和实际告警量匹配：一家机构一天最多几十条事件，缓存 1000 条能撑很久；但如果把状态心跳也算进去，1000 条可能只够几小时。
复网后怎么补——按时间戳顺序补传，还是按优先级（火警优先、故障其次）？前者简单，后者更符合实际需要。
平台怎么校验完整性——靠设备端的序号连续性判断，还是靠平台侧对账？只有设备端带序号，平台才能发现“中间缺了几条”。
什么情况下会真丢——缓存写满、断电、设备被拆。这三种要如实写，写“绝不丢失”反而不可信。

最危险的不是断网，是断网期间着了火而没人知道。所以断网本身必须产生一条告警（“设备离线”），并且这条告警要推到人，不能只在平台上变灰。很多方案把离线当状态、不当事件，结果设备停了三天没人发现。

04AI 视频：七个算法里，哪几个真能用

方案里的算法清单通常很长，但落地效果差别极大。按“目标是否规整”排一下，实用性从高到低大致是：

算法	判断依据	落地难度
消控室脱岗 / 睡岗	画面里有没有人、姿势是否异常	低——场景固定、机位固定
疏散通道 / 消防通道占用	指定区域有没有堆放物	低——区域可画框
电动自行车违规充电	画面里有没有车、是否在充电位	中——车型多、遮挡多
烟火识别	火焰颜色纹理、烟雾扩散	中——受光照与蒸汽干扰
违规用火用气	明火、灶具状态	中高——厨房油烟干扰大
人员跌倒	人体姿态突变	高——遮挡、多人、误报多
夜间离床	床区人体位置	高——被子、护栏干扰

规律很清楚：目标越规整、场景越固定，越靠谱。前三类（脱岗、通道占用、违规充电）装在固定机位、盯着固定区域，效果稳定；后两类涉及人体姿态，误报率高，只能当辅助线索，不能当单独依据。

应答准确率时，必须带三个限定：测试集是什么、测试环境是什么、最小可识别目标多少像素。脱离这三个条件的“准确率 95%”，在验收时无法复现。

部署位置怎么选：摄像机内置算法省带宽、响应快，但升级要逐台刷；平台侧解析利旧摄像机，但占服务器算力、传视频费流量；边缘盒子介于两者之间。三家机构以内用前两种都行，机构多了要算总带宽账。

05自查清单：12 项

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

0 / 12

06常见问题

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

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

断网时告警会丢吗？

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

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

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

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

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

县级中心要对接哪几个平台？

三个方向：消防救援机构监管平台（通常 RESTful API、GB/T 26875.3 或地方标准）、民政部门的统计口径（报表或接口）、全国养老服务信息系统（预留）。三者的字段口径完全不同，不能一套字段打天下。

项目数据归谁？

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

等保三级是必须的吗？

政务与公共服务类平台通常要求过等保三级（GB/T 22239）。应答时要说明是否已测评、测评机构与时间；未测评的要说明具备测评条件及配合甲方测评的工作内容，包括数据加密、身份鉴别、访问控制、日志留存期限。

本地服务能力怎么证明？

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

适用范围与本页说明

本页面向养老与居家场景做方法参考。机构消防管理适用另一套规范，与居家设备不能混用；文中关于分级响应、台账与验收的写法属方法层面，落地时请结合本地服务能力与住养人群特点调整。

机构与居家场景的响应能力不同，方案不要互相套用；机构重"夜间有人盯"，居家重"到人"。

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