云平台定制：接口先谈，界面后谈

核心答案

县级养老项目的平台定制，客户通常先提界面需求：大屏要什么样、颜色要什么。真正决定成败的是接口：消防监管平台要什么字段、民政报表要什么口径、机构原有系统怎么对接。界面改起来是几天的事，接口对不上要重做数据模型。先谈接口，再谈界面。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04机构画像：评级不是为了排名，是为了排班

“机构画像”容易被做成一张打分表，评完发个红黄绿就结束了。它的真正用途是决定检查频次和值守资源怎么分配。

合理的维度大致四组：

风险基础：建筑年代、层数、住养人数、失能比例、是否与其他功能合建；
设施状态：报警系统是否完好、电气线路年限、消防水源、疏散条件；
管理执行：巡查完成率、隐患整改率、培训演练次数、告警确认及时率；
历史事件：近一年告警次数、误报占比、真实火情、被督办次数。

四组里，前三组是静态或半静态的，第四组是动态的。如果评级只看前三组，一年评一次就够了；要让它指导日常，第四组必须实时进模型，否则永远是“去年那个分数”。

权重能不能自定义，是这类平台的分水岭。甲方对“失能比例”和“电气年限”的重视程度，各地不一样；写死权重的产品，第一次评审就会被要求改，改一次要动代码。

评级结果怎么用：至少要和检查频次挂钩——A 级季度抽查、C 级月度上门。只评级不挂钩，机构很快就不在意了。

05自查清单：12 项

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

0 / 12

06常见问题

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

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

时延的三段分别是什么？

主机火警到传输装置采集、传输装置到平台入库、平台入库到责任人手机。第一段取决于主机接口和轮询周期，第二段取决于网络与平台并发，第三段取决于推送通道。只报一个总数，说明不了问题在哪。

工单闭环必须有哪几个节点？

预警产生、机构确认、处置反馈、销号归档，四个节点对应四个时间戳。缺任何一个，“响应时长”“处置率”这类指标都算不出来。另外升级规则要可配置，白天夜间、不同机构不该用同一个阈值。

超时未确认怎么处理？

自动升级：先升到机构负责人，再超时升到县级中心，中心有权直接联系 119 并记录。关键是这条链路要在系统里自动跑，不能靠中心值守人员盯屏幕手动打电话。

兼容主机品牌写“主流品牌”行不行？

不行。要报具体品牌名和协议名。养老机构存量主机品牌杂，每个县的实际构成都不同，接入前还得现场确认型号与固件版本。写“兼容主流品牌”在评审时基本等于没答。

水压水位多久上报一次？

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

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

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

到场时限怎么写才可信？

分两级：县城与乡镇分别承诺最长时限，最远的那个机构单独列出来承诺。笼统写“全县 4 小时”很容易被追问，分开写反而显得做过功课。

适用范围与本页说明

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

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

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