黑龙江：供暖季的电气火灾，比明火多

核心答案

黑龙江供暖期长，养老机构里电暖器、电热毯、小太阳几乎人手一个，加上老楼线路年限长，电气原因引发的火情占比明显高于其他季节。这类风险靠烟感只能“着了才报”，要靠电气火灾监测提前发现过载、过热、漏电。所以方案里电气监测和独立烟感要一起上，只装一种等于漏掉一半场景。

01养老机构为什么值得单独建一套

养老机构在消防上是个特殊场景，特殊在三点，而且这三点都不靠“加强管理”能解决。

一、人搬不动

医院有平车、有电梯、有护工轮班；养老机构里大量是失能半失能老人，卧床的占相当比例。同样一场初期火灾，医院能在三分钟内把一层人转走，养老机构可能连把人扶起来都需要两个人。这决定了报警必须更早，处置必须更快——不是“重视程度”问题，是物理条件决定的。

二、夜里没人

多数中小型养老机构夜间只有 1–2 人值班，有的甚至只有门卫。夜间恰恰是火灾亡人高发时段：人处于睡眠状态，发现晚、反应慢。所以夜间值守不能只靠机构自己，县级中心的 7×24 小时值守正是补这一段的。

三、火源在家里

养老机构的火灾，电气原因与卧床吸烟是两条主线。电热毯、电暖器、私拉插排、老人自己带的充电器，这些在家里是小事，在集中住宿环境里是隐患叠加。传统火灾报警只报“着了”，报不出“哪儿在过载”——所以电气火灾监测和独立烟感要一起上，不能只装一种。

这三条对应的技术选择：更早 → 独立烟感 + 视频复核；更快 → 告警直推责任人手机，不等值班室转达；火源 → 电气火灾监测 + 可燃气体探测。选型时如果只买了火灾报警主机联网，前面三条一条都没解决。

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

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

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

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

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

03一院一档：六类台账，先想清楚谁填

“一院一档”是这类项目的标准动作，但做出来经常是一堆空表格。问题不在系统，在没想清楚谁填、什么时候填、填了有什么用。

台账	谁填	触发时机
机构基本信息	县级中心建档	接入时一次性
责任人与岗位责任清单	机构	人员变动时更新
日常巡查 / 电子巡更	机构值班人员	每班次
培训与演练记录	机构	每次活动后
设施维保与检测	维保单位	按合同周期
隐患库	中心 + 机构	发现即录入，整改后销项

六类里最容易烂尾的是日常巡查：纸质表改成手机打卡，形式上完成了，内容全是“正常”。要让它有价值，得让巡查项和隐患库联动——发现的问题必须落成隐患条目，隐患条目必须能统计出“哪类问题反复出现”。

另一条经验：台账字段不要一次做全。先上机构信息、责任人、隐患库三类，跑三个月，再按实际使用补其余三类。一次做齐的系统，通常有一半字段永远空着。

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

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

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

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

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

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

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

05自查清单：12 项

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

0 / 12

06常见问题

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

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

火灾告警端到端时延一般要求多少？

行业没有统一的强制值，问询清单通常要求分别填最短、平均、最长三个实测值，并注明测试方法（网络条件、接入设备数量、并发告警数）。评审看的是三个数是否自洽、最长值是否有合理解释，而不是单个数字多小。

断网时告警会丢吗？

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

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

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

传输装置一体机好还是分体好？

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

摄像机能利旧吗？

能，但要先摸底。把每家机构的摄像机品牌、型号、固件版本、IP 段、是否 POE 全部抄一遍，再决定要不要买接入网关、买几台、要不要换线。跳过这一步直接报价，后期一定超支。

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

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

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

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

适用范围与本页说明

本页面向属地项目做规模测算与建设内容对照。文中引用的文件号与标准号（云民发〔2026〕81 号及附件《县级养老机构消防安全管理中心建设参考方案》、T/QDAS 146-2025、GB 26875 系列）均按公开文本表述，具体条款以正式文本为准；各地试点范围、时间节点与补贴口径以属地民政与消防救援部门口径为准。

落地前先与属地民政、消防救援部门确认试点范围、接入机构名单与时间节点，再按机构数定平台规模。

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